'ello everyone.
I've been spending some time researching the approaches to
multi-threading in OpenGL with SDL 1.3. I think it’s sufficient to say that
there’s little to no documentation on such techniques, and if there is…
is not very easy to find. I’m hoping that some (or at least one) of you can
help me out on this bit, in order to get multi-threading working nicely
with OpenGL.
From what I've learned, in order to share my OpenGL data, I'll need
to share my OpenGL context. On my main thread, I’ve created my context, but
I’m not sure how to share it with any other worker threads
On Win32, wglShareLists(),
On X11, glXCreateContext().
As far as I know (and I’m not 100% on SDL 1.3’s new features), it doesn’t
support multiple shared contexts, so you must do your own OpenGL
initialization. You might be able to hack around it if you don’t mind
getting your hands dirty with SDL/platform specific code.
Currently, my
library’s logic is handled in a worker thread, but such logic could include
mapping/unmapping of VBOs or something of the sort. In short, it could
include some OpenGL functions that will need to be knowledgeable of the
current OpenGL state, as set by the main thread.
Can’t happen. Sorry. OpenGL allows 1 thread to access 1 context; it is
always a 1-to-1 relationship. Sharing between contexts does not share
states, only objects such as textures, vbos, etc. There is a very distinct
different there.
According to some, this is entirely possible across threads. What
about across windows/threads? Would I be able to create another window on a
separate thread and share the main thread’s OpenGL context?
No, because sharing an OpenGL context with two threads is illegal. You can
have one context in one thread that renders to two windows, two contexts in
two threads that render to two windows, but never two threads one context.
If any of these
are possible, may I please have the functions required to accomplish it, or
maybe a code snippet?
I’ll appreciate any answers I can get.
Thanks,
Jeaye
SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org
You seem to be in the “threads a good” mindset, which isn’t invalid
considering the ever increasing number of cores available in computers. The
problem however is that a graphics card does not simultaneously execute two
different rendering commands with different rendering states, it must stop,
save the state of the graphics card, load the new state, render, etc. It
performs context switching, in effect. This is the reason that OpenGL only
allows 1 thread to submit data via 1 context.
From an API perspective, there are some things which aren’t always state
dependent, such as creating textures/vbos etc which is why the platform
specific APIs allow shared objects (not shared state). You can use
multithreading to load texture/vbo data from a different thread while one
thread renders, which can be useful for streaming data or generating
procedural content, but largely isn’t a real dual-core super performance
win.
Direct3D 11’s “multithreading” consists of simply recording the commands on
secondary threads (into structures called “state blocks”) and then playing
them back on the main thread at a different time. In effect, 2+ threads can
submit draw calls, but in the end, one thread executes them serially. Again,
the reason is that the hardware itself doesn’t actually do two dramatically
different things at once, it does one, stops, context switches, restarts,
and so on.
Even if you could render from two threads simulatenously via driver hacks,
the resulting performance would be < 1/2, which really begs the question of
usefulness.
PatrickOn Sat, May 14, 2011 at 1:02 PM, wrote: