[Bf-committers] Multi-Threading for Render API
early at respower.com
Thu Jun 28 04:31:46 CEST 2007
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...
More information about the Bf-committers