[Bf-committers] Re: Re: Re: Thoughts on speeding up...

GSR - FR famrom at infernal-iceberg.com
Fri Mar 25 06:27:57 CET 2005


Hi,
desoto at blender.spaceisbig.com (2005-03-24 at 2004.54 -0500):
> Conceptually this would be similar to rendering an image in parts no? 
> Only two or more parts rendering simultaneously?

Yes, same idea behind Xparts/Yparts. Which I just tested, and it seems
the system does radiosity once, then renders the parts one by one, so
it seems feasible in that front, there is no serious time difference
when compared to all in one. And so I wonder why the current approach
was chosen instead of one around areas of the image.

> It would seem to me, however, that this would unfairly separate the work 
> load. One part of the image could take *far* longer to render than 
> another. Does one thread end up responsible for 90% of the heavy lifting 
> while the other twiddles its thumbs? Or is there some fundamental way 

Make enough parts so no thread is idling until the end. Using 64*64
tiles, a 640*480 image requires 80 units of work (assuming parts that
are smaller than 64*64 count as one). Make them 16*32, or 100*100,
that is just a detail, the important is to have enough units to keep
all threads busy in most balanced way possible. Worst case is mimimal
improvement over single cpu, best case divides time (plain render
part, not radiosity, etc) by nearly as many threads.

> the computation can be split up that would make this concept much more 
> efficient i.e. one thread performing a specific set of tasks completely 
> different from the purpose of the other. Say.. for example (and not a 
> technically accurate example) one thread is responsible for doing 
> shading calculus while another thread performs the math for raytracing?

That mode could be possible, but I doubt the complexity is worth the
effort. The other is not perfect (not all threads will end at the same
time) but what would do the shading thread while the raytracing one is
computing a call? Keep on shading somewhere else and remember the N
pixels where it is waiting for a raytracing result? And when
raytracing requires a shade result? What if the image has no
raytracing at all? What if you have 4 execution units instead of 2?

Or in general terms, what happens when the task plan does not suit the
image at all? The problems with choosing how to partition tasks (and
the high overhead of threads talking to each other in some cases) do
not seem better than plain split by area.

GSR
 


More information about the Bf-committers mailing list