7 replies to this topic

[rektide]

has anyone here used OpenSG? its an opengl scene graph that boasts a quite a number of features. I dont really know what scope the "multithreaded" scene graph really extends to: how much added and how much opengl is inherently mutli-threaded anyways, but i'm curious to find out, and interested in hearing others stories on multi-threaded opengl! i'm just scoutting it out, i do a lot of server side .net work and am looking to build a solid opengl platform in C#, and was thinking of using openSG as the basis.

rektide

[Reedbeta]

Regarding OpenGL and multithreading, each GL render context is local to a thread and you can't share render-context resources (texture objects, buffer objects, etc) across threads. Basically a single application's use of OpenGL itself will not be multithreaded; there will be just one thread that owns the context and is responsible for dispatching all rendering commands (and executing any CPU-side driver code associated with those commands). The multithreading they refer to in OpenSG has to do with the management of scene data on the CPU, before OpenGL ever touches it. It is useful to separate physics, AI, etc into separate threads from the rendering thread.

[rektide]

that sounds like a pretty unequivocal "no multi-threading in opengl" statement, which from what i've seen of opengl could very well be the case. oi. :yes: for the help, and :no: to the particular answer. any other takers? :whistle:

there is no way to interact between different rendering contexts?

[rektide]

its not that opengl would protest being used by different threads, its just that each gl context expects only a single "stream of input", no? for example, glBegin() in one thread, then pass off to a second thread that fills in the glVertex3f()'s, then go back to the original thread and glEnd()... since there's no concurrency in play, would it work? this would be useful/necessary for a scene graph where you might have actor model in the scene graph, and objects are thread bound.

thanks
rektide

[Nils Pipenbrinck]

Consult the OpenGL spec for this particular use-case.

I can only tell you that in OpenGL/ES, which is a stripped down version of OpenGL for mobile devices, you can't simply share a context from multiple threads. Each glXXXX call will first get the current ThreadID and gets the gl-context "current" or associated with that thread.

The caveat is, that a context can only be current to one single thread. In a proper GL/ES implementation calls from the second thread will just be ignored, or if two contexts are made current to two threads, each thread only talks to its own OpenGL context.

I'm pretty sure that the Desktop-OpenGL behaves exactly the same.

[Reedbeta]

As far as I know the behavior Nils described is the same for desktop OpenGL. You can render from multiple threads if you are rendering to multiple viewports, each with their own state. Render contexts are thread owned and I'm not sure if you can even transfer a context from one thread to another, because the driver likely keeps the state in some thread-local storage that wouldn't be accessible to another thread.

Why would you want to have multithreaded access to one OpenGL state, anyway? It wouldn't improve performance or anything as far as I can tell. The CPU-side driver doesn't do very much work, it just queues up commands and DMAs and things to the GPU and sends them. The GPU has its own parallel execution and is orthogonal to any CPU threading.

Quote

this would be useful/necessary for a scene graph where you might have actor model in the scene graph, and objects are thread bound.

A better way to do this would be to have the actors' persistent data stored in a monitor, which serializes access to the data (or a more sophisticated one allows simultaneous reads but serializes writes), and have the rendering thread and the actor updating thread both access that data through the monitor.

[karligula]

You might want to have multithreaded access to the same context if you want your loading thread to build display lists of whatever got loaded, to subsequently be used in the rendering thread. I tried doing that once... it didn't like it AT ALL. I also tried having a context for each thread and then sharing objects between contexts, but it didn't like that much either. It would be nice if there were some GL command that would allow you to copy stuff from one context to another inside a critical section, perhaps. I doubt that would ever happen though.

GL just isn't thread safe. It's such a shame...

[Reedbeta]

karligula said:

GL just isn't thread safe. It's such a shame...

I think you've misunderstood. It's completely thread-safe, that's why you can use OpenGL from two different applications simultaneously without them messing each other up.

In the case you mentioned, you could have the loading thread store data in memory buffers and let the rendering thread create the display lists. This is a better architectural approach IMHO, because the use of display lists (or vertex buffers, or whatever) is an aspect of the rendering implementation, and therefore the loading code shouldn't be aware of it (information hiding, low coupling).

You can share data between two contexts owned by the same thread, but not between different threads. While it would be possible for OpenGL to support data/state copying from one context to another owned by a different thread, I just don't see that there's any need or desire for this feature compelling enough for it to be worth implementing.