[Bf-committers] Multi-Threading for Render API
two.a.ron at gmail.com
Thu Jun 21 18:24:34 CEST 2007
The render API needs to interact with threaded code because blender's
internal renderer is threaded and because we want to be able to
process more than one render at the same time, for example: hitting
the render button in the middle of rendering a preview.
However, the API itself will obviously not be creating threads, it
merely has to be thread safe I suppose, and in some places perhaps it
has to have the ability to be thread local? I have to confess, I
haven't done threading myself. I'm familiar with the basic concepts,
but trying to work out how it will impact the design and
implementation of this API is difficult for me.
First of all, a render job can be broken down into multiple
successively smaller parts. The frame, the buffers, and the parts.
Should the API provide access to the input and output for each of
these divisions in capsules so that they may easily be passed to
separate threads for processing? 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?
Also, it appears to me that currently blender can only focus on
drawing one thing at a time. For example, even if two renders were
processing in parallel, only one could be drawn, and then the other.
This can be observed between the material preview and the preview
window and also between the preview window and the render window. In
order to see the result of using threads to do multiple renders at
once, this would need to change perhaps? Or are these the results of
some other problem?
Any advice or feedback on this issue is helpful because I'm currently
at a bit of a loss with respect to it.
More information about the Bf-committers