Water Transparency test and multithreading results

Started by Saurav, April 01, 2008, 07:55:50 PM

Previous topic - Next topic

Xpleet

This is incredible, 3min -> 50 sec?!  :o

I suppose your Q6600 is @stock.

I'm gonna get mine q6700 very soon so I can start of with this =D , can't wait until they make the multithreading version public!

osmose

do you mean 1.5 hours WITH multithreading for a 800 pxiel image ?

it seems not very quick for a small image ??

i may have not understand

PG

Quote from: Mr_Lamppost on April 02, 2008, 05:19:39 PM
Thanks for showing. 
Actually I take that back; I am going to have to change into a clean shirt there is drool all down this one.  ;D
Quote from: moodflow on April 02, 2008, 02:54:46 PM
This is something I've been curious about too.  "Transparent materials" were mentioned, so I am hoping to see some crystal formations and such with this...and/or maybe some ice formations. 
And we just know some fool will try a glass planet. 

That'd be me :D
Figured out how to do clicky signatures

Marcos Silveira


Xpleet

Quote from: ro-nin on April 22, 2008, 04:35:59 PM
Didn't understand...
what does mean Q6600???

Saurav's intel quadcore cpu.



I really wanna hear more about the new rendertimes with new multithreading!!!!!!!!!!

Marcos Silveira

#35
There has been a couple of years now that I've been watching all this talking and talking about the so called Multithreading process, but what is it at all???

Mohawk20

Quote from: osmose on April 22, 2008, 03:22:46 PM
do you mean 1.5 hours WITH multithreading for a 800 pxiel image ?

it seems not very quick for a small image ??

i may have not understand
Water renders slow anyways, and I imagine even slower with transparency, so 1.5 hours is really fast in my oppinion.
Howgh!

Harvey Birdman

#37
-

mr-miley

I love the smell of caffine in the morning

Matt

#39
In TG2 we haven't yet been able to completely separate the GUI thread from all other heavy computation, but we have separated the main bulk of rendering into separate threads. This helps keep the GUI fast when it's in the middle of a render or rendering a preview pass, but there are still parts of the renderer and other CPU-heavy stuff executing in the main thread (with the GUI) so it's not ideal yet. We'll continue to work on that after 2.0 release.

The main improvement that you'll see with multi-threaded TG2 is that rendering completes in a much shorter time if you have multiple CPUs or multiple cores. That also applies to the 3D Preview because it uses the same renderer. I concentrated on the main bulk of the renderer - everything that happens while a single bucket (tile) is rendering - and moved that into separate threads. Now multiple buckets can render in parallel, so if there are multiple processors/cores the render will complete much sooner. Initialisation and cleanup at the start and end of a render still happens in the main thread, as do other things like population calculation, heightfield operators, etc. so there's no improvement there. There's much to work on in the future.

Matt
Just because milk is white doesn't mean that clouds are made of milk.

Mohawk20

Quote from: Matt on April 23, 2008, 01:14:40 PM
...everything that happens while a single bucket (tile) is rendering...

Hmm, so one render tile, is a bucket size... now I understand. But what defines the bucket size, is it standard per application, or is it affected by the system? For example, if I install more memory, will the rendered tiles be bigger? I have noticed the tile size changes relative to the total images' size or resolution...
Howgh!

Matt

#41
Bucket is probably a strange word when 'tile' is more appropriate. I call them buckets simply because that's what they are called in some other renderers, even though their reasons for bucketing are quite different from those in Terragen and their buckets are usually much smaller. In PRMan, for example, the term 'bucket' makes more sense because it's motivated by the desire to keep only a small number of micropolygons in play at any one time (I think). For PRMan the bucket refers more to the bucketing of the render data rather than the image. For Terragen, larger buckets mean faster rendering but they use more memory for the anti-aliasing buffer and need to be reduced when the AA is high.

In build 1.9.04.1 the bucket size depends on the anti-aliasing setting. For higher anti-aliasing levels it uses a smaller bucket so that the anti-aliasing buffer is always 1000x1000 or less. This means that with anti-aliasing level 5 the buckets are 200x200 pixels or smaller.

With multi-threading Terragen uses other criteria to decide how large a bucket can be. Generally it uses smaller buckets when there are more threads to take advantage of the parallelism. You don't really get to control it I'm afraid ;)

Matt
Just because milk is white doesn't mean that clouds are made of milk.

Mohawk20

Wow, thanks for that. It makes sense...

So when not using the multithreading option, I can increase the bucket size, or tile size, by using low AA. So basicly, low AA increases renderspeed...
Nice!

Still, I rather have high AA...  ;D
Howgh!

moodflow

Many thanks for the explanations Matt.  This is very interesting stuff for sure! 8)
http://www.moodflow.com
mood-inspiring images and music

Marcos Silveira