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

Chris Burt desoto at blender.spaceisbig.com
Fri Mar 25 02:04:54 CET 2005

Conceptually this would be similar to rendering an image in parts no? 
Only two or more parts rendering simultaneously?

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 
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?

Is this sort of approach feasible? Clearly there exists precedent for it 
being done with modern computer systems. Certainly the GPU of a modern 
computer performs a totally different set of tasks than the CPU does. 
Could this behavior be mimicked between two separate processors? Or are 
there things fundamentally wrong with the idea that the work can be 
divided up this way?


GSR - FR wrote:
> Hi,
> jlp at nerim.net (2005-03-25 at 0015.09 +0100):
>>Hmm.  In this case Hyper Toasting is appropriate, as with a single 
>>point unit, both threads will compete for it and often result in not 
>>or even worse rendering times. Dont trust Intel Marketers ;)
> I thought the issue was not the number of units, but the absurd level
> of stages to be able to keep the clock rate high. So they figured they
> could feed something to an unit when the previous thing has moved to
> the next stages instead of causing a bubble. But yes, I have not
> checked if it would work or not for this case, so the "could *".
>>As for supporting more than 2 cores, yes that can be fine, but the 
>>  solution for render is to launch more than one instance, each rendering
>>at its own path its own frame. No scheduling problem this way nor coding
> That is nice for animations, but not for stills. Of course, it can be
> focused in other way: make each render a fixed part of a frame without
> having to pay attention to others, and then combine later. So a
> dispatcher goes assigning works, and each one goes on itself to only
> report back periodically, knowing that the resources it has been
> assigned are for itself only.
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at projects.blender.org
> http://projects.blender.org/mailman/listinfo/bf-committers

More information about the Bf-committers mailing list