[Bf-committers] Multi-Threading for Render API

[Early Ehlinger]

Mathias Wein wrote:
>> Also, should the API not assume, for
>> example, that the same processor that rendered frame 200 will render
>> frame 201? This assumption could be used to optimize: including
>> information as to what changed from the last frame to the next frame,
>> but what if the last frame was done by a totally different computer?
>>   
>>     
>
> So in my opinion you may safely assume that one context proceeds to the
> next frame only after it has finished the previous one.
>   
This should be obvious, but I'll state it to make sure it's out there.  
You should be able to handle the case where the previous frame was not 
rendered at all.  e.g., if the user jumps to frame 201 and starts 
rendering, you cannot assume that 200 was run.  So it's okay to use 
optimizations where possible, but must gracefully handle the cases where 
they don't make sense.

Having this capability means that if another processor (or computer) 
renders frame 200, you'll still get the right answer for frame 201, it 
just won't render as quickly as if both frames were rendered on the same 
computer.  Although presumably, you would be doing this because you 
could render both in parallel, so you would still see a speedup...

-- Early Ehlinger, President, ResPower, Inc.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.blender.org/pipermail/bf-committers/attachments/20070627/07905eb6/attachment.htm