Question

I have a lighting system in my xna game that loops through each light, and adds these lights to a final light map, which contains all the lights.

The process to create these lights involves many functions that have to do with the graphics device, such as using effects / shaders and drawing to render targets, and using graphics.device.clear to clear the render target, etc

So my question is, would it be possible to multi thread each light? Or would this not be possible because there is only 1 graphics device, and only 1 thread can use it at a time? If it is possible, would it improve performance?

Answer 1

Basically no. The GraphicsDevice in XNA is single-threaded for rendering. You can send resources (textures, vertex buffers, etc) to the GPU from multiple threads. But you can only call Draw (and other rendering functions like Present) from your main thread.

I have heard of people having success doing rendering-type-things from multiple threads with the appropriate locking in place. But that seems like “bad voodoo”. As the linked post says: “the XNA Framework documentation doesn’t make any promises here“. Not to mention: even getting the locking right is tricky.

I’m not really sure about making multiple graphics devices – I’ve not tried it myself. I think that it is possible, but that you can’t share resources between the devices – making it fairly useless. Probably not worth the effort.

As jalf mentioned in a comment on your question – once you get to the GPU everything is handled in parallel already. So this would only be useful if you are CPU limited due to hitting the batch limit (because almost everything that isn’t your batches can be moved to another thread). And in that case there are many optimisations to consider first to reduce the number of batches – before trying a crazy scheme like this. (And you have measured your performance, right?)

It sounds like what you might be trying to do is render a fairly complicated scene to a render target in the background, and spreading the load across many frames. In that case – if performance requirements dictate it – you could perhaps render across multiple frames, on the main thread, scheduling it manually. Don’t forget to set RenderTargetUsage.PreserveContents so it doesn’t get cleared each time you put it on the graphics device.