[Bf-committers] Multi-Threading for Render API
lynx at aspect-design.de
Thu Jun 21 22:52:11 CEST 2007
The fun of threading...
Aaron Moore wrote:
> 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.
Sure, multiple renderings concurrently would be nice, but i'd
say don't make your task too hard right now...
> 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.
Thread safe pretty much means don't share non-constant data
among threads, and if you have to, prevent concurrent manipulation.
I'm not sure what thread local would mean, rendering activities
belonging to different renderings obviously should have separate
contexts, no matter if running in parallel or not, and threads using
the same context should get identical results IMHO...
> 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?
Software (usually) does not assume anything about which processor
executes code, it is only aware of individual threads, each being of
strictly serial nature...
so the question is, may a rendering context be used by multiple threads
concurrently or not, and if, what restrictions apply. I don't think we
desperately need the ability to render frames in arbitrary order
concurrently. Distributed rendering with inter-process communication
is a totally different beast, i'm not even aware of any package allowing
multiple frames concurrently on multiple machines while directly
communicating with a single process.
So in my opinion you may safely assume that one context proceeds to the
next frame only after it has finished the previous one.
> 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?
yes, to my knowledge interface drawing *must* be done by one
specific thread, due to some OpenGL stuff i don't know anything about :)
I had to change the new yafray code to trigger the interface update from
the thread that initiated the export again, otherwise blender just quits
in panic. Would be great if this could be overcome somehow...
Not only could blender have multiple renderings in progress, but
the render engines themselves would be more free with organizing
But this might be a bit of work, you better ask an interface expert there.
More information about the Bf-committers