Just a quickie
Just a small Oxidizer CVS update.
You can now lock the scale of the image to the height of the image. i.e. if you toggle the lock on, change the height of the image (and the width), and hit preview, the new preview will look the same as it did before rather than zooming in/out of the flame.
5 Comments:
That's a good feature, thanks for keeping up the development. Another similar feature that I had on my wish list was a button to lock the image aspect ratio in x/y, so that if you change one the other is automatically adjusted.
In addition, I was wondering about some details here..
You said before that the multi-threaded still rendering was slower than a single thread - how many threads did you try, and how many (physical) cpu cores did you have available for testing with? Is it possible to keep the still-rendering multi-threading as an option in the preferences? There could be performance gains as you go to more cores (apropos the clovertown quad-cores released this week)
Also, which parts of the rendering were you multi-threading? I do not know the layout of the flam3 code, but I assume it has a few distinct parts, like maybe the main rendering, oversampling and filtering? I'm asking because I was playing around with the oversampling parameter and noticed that I could get significant quality improvements in hires images, but at an exponentially growing computation time. Maybe that's something that could be multi-threaded too?
Just asking out of curiosity, no pressure.. :)
(and because I'm getting my Mac Pro soon!)
Locking the image aspect is on the list of things to do, just go fed up of having to change the scale first :-)
I'm working on a dual core mac, and I ran tests against 1, 2 and 4 threads.
The lack it actually saving time was more due to the way I tried to implement the threading. I did not want to do any low
level changes to the flam3 library, as it makes it easier to keep up to date, so I basically rendered the
still in strips (as in env strips=3 flam3_render < flam3.xml) and rendered each strip in a thread.
The results where.....
1 thread, 10 strips: Time for render: 212.919917 seconds
2 thread, 10 strips: Time for render: 135.297466 seconds
1 thread, 2 strips: Time for render: 46.244126 seconds
2 threads, 2 strips: Time for render: 29.138267 seconds
1 thread, 1 strip: Time for render: 26.204779 seconds
2 threads, 2 strips: Time for render: 29.138267 seconds
I asked Scott about it and he said they were reasonable results.
Any multithreading will have to be at a pretty low level to get a decent result.
Any multithreading will have to be at a pretty low level to get a decent result.
Yeah, I was afraid of that....would probably have to try some loop splitting in the flam3 code, using posix threads or smth. Have the Flam3 consortium really not tried this at some point already? I would sort of half expect that there's an old multi-threaded (though maybe slightly unstable..) build of flam3 lying around somewhere gathering dust :)
Oh well. Thanks for the info anyway!
Something else that just ocurred to me, how about batches and temporal samples? Aren't those completely independent renderings that are just summed up at the end (before filtering)? If they are, they should be trivial to parallelize. Hmm.
The batches are probably the right place to parallelise the code, although I'm not an expert on the flam3 code. My main concern would be the large amounts a shared memory that would be used, accessing shared memory used to be an automatic pipeline flush on Intel CPU's, and whether attempting the code not to use so much would lose so much benefit it would not be worth it.
Post a Comment
Links to this post:
Create a Link
<< Home