MultiThread Rendering

8 views
Skip to first unread message

Pete

unread,
Nov 26, 2009, 8:58:54 AM11/26/09
to G3D Users
Hi all,

At the moment I haven't actually tried this, but I'm just about too
and was just curious to see if anyone has any thoughts, or pointers,
as I don't really know what will happen...

To explain.. .. ..

I have so far, been working only on a single thread, but am now about
to look at moving a set of code out onto a separate thread. The code
to be moved loads/discards and pre-processes the data to be displayed.
The concern i have, is that part of the pre-processing involves
performing off-screen rendering using the gpu. I really don't know how/
if this is going to effect the normal rendering cycle, but I'm
assuming I need to put some locking in place such that only one thread
at a time can render.
Is there a better way of doing this? Not sure what G3D/OpenGL does
behind the scenes regarding multi-threaded access, do i even need to
worry about locking and leave it to sort itself out?

Any thoughts would be welcome.. .

Pete

Morgan McGuire

unread,
Nov 26, 2009, 10:13:11 AM11/26/09
to g3d-...@googlegroups.com
Most of my G3D programs are multithreaded these days. GThread,
GMutex, and ThreadSet are big helpers for this. Also note that G3D
and GApp allow you to make RenderDevice calls from anywhere. I often
have GApp::onSimulation methods that invoke off-screen rendering.

OpenGL is not threadsafe. It is up to you to ensure that you do not
invoke OpenGL calls (which generally means RenderDevice calls or
Texture creation) on multiple threads simultaneously. I think that if
you are rendering to multiple contexts this might be relaxed slightly,
but I don't recommend rendering to multiple contexts.

The fact that OpenGL is not threadsafe isn't very important, though,
since most OpenGL calls don't block. The GPU is a separate processor,
and an OpenGL call tells it to launch a thread. So if you have one
CPU thread that issues OpenGL calls, that thread will almost never
block (unless you're performing some kind of readback). This means
that you can use as many CPU threads as you want, and just ensure that
only one communicates with OpenGL.

You could alternatively protect RenderDevice with a GMutex, but the
overhead of doing that for every call is fairly high and since OpenGL
is a state machine, you'd have to synchronize at a higher level to
avoid confusing your state across threads.

-m
> --
>
> You received this message because you are subscribed to the Google Groups "G3D Users" group.
> To post to this group, send email to g3d-...@googlegroups.com.
> To unsubscribe from this group, send email to g3d-users+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/g3d-users?hl=en.
>
>
>
Reply all
Reply to author
Forward
0 new messages