PDA

View Full Version : OpenGL equivalent to DX11 render contexts



Anteru
10-04-2009, 07:48 AM
I'm working on some DX10 graphics app, and I recently switched to DX11 to take advantage of multiple contexts, in particular, I want to update textures on multiple threads and also prepare draw commands.

The question is now how to map this to OpenGL, if possible at all, as I'm thinking to bring up an OpenGL renderer as well to eventually allow porting to other platforms. I'm more or less an OpenGL beginner, having used OGL2 a bit, and I wonder whether there is something similar to DX11 DeviceContext in GL (maybe via an extension?) Any ideas on how to get similar functionality?

todayman
10-04-2009, 11:59 AM
OpenGL does not manage it's own context. The windowing system and the OS actually create the contexts and manage them. There's nothing in the OpenGL spec that stops you from creating more than one context. There are ways to share thinks like display lists and textures between context; this will depend on the API you use. OpenGL is not thread-safe, so you'll need to be careful.

sqrt[-1]
10-05-2009, 02:45 AM
Preparing draw commands on different threads might be difficult.
You might be able to update textures on different threads. (assuming it is just a data load)
This might be possible with multiple contexts on different threads that have resource sharing enabled, or at the very least you should be able to use something like PBO to lock the texture memory on your main thread, update it on another thread, and then unlock the texture on the main thread.

Ilian Dinev
10-05-2009, 03:15 AM
Afaik, commands to the GPU are sequential. Uploading of buffers like textures can be commanded to be done via DMA. One interface to do that are the PBOs, another is simply the glMapBuffer. Generally you have to make your own code to handle the async stuff and its unlocking in custom FIFOs. I have no experience in this on modern silicon, so corrections may be necessary.

About draw-commands:
nVidia drivers provide multithreaded execution (which is stable since 190.xx) : your glXX calls take a dozen or two cpu cycles, getting appended on yet another internal FIFO. (otherwise same commands would take 200-450+ cycles). ATi might need to do the same.

*a wish-list of easily possible things to come*
Compilation of shaders can be assisted like that, too (without API changes) - but needs some slight async-style changes in engines' code. Internally-managed binary-shader blobs could be also transparently handled by the drivers.

Anteru
10-06-2009, 01:03 AM
Hmm I see, so I should be able to update textures with some work, but the multi-threaded draw command dispatch is not so easy ... this is unfortunate. I know that the nvidia drivers are multi-threaded, but I'd simply execute the draw calls from multiple threads as well, so I can traverse my scene graph more quickly (for instance, run over it to generate the draw calls for shadow rendering concurrently with the draw calls for normal rendering), and then executing one after the other.

Re locking from main thread and PBOs, is there some code out there which does this?