Multiple X connections for multithreaded rendering?


I’m working on some code for handling multi-threaded OpenGL rendering through the use of multiple GLXContext’s (X Windows/UNIX).

My question is, if I should use a separate X server connection for each thread, and thus for each GLXContext - or if I would be better off using one shared connection.

As I see it, there are two issues affecting the decision. One issue is the overhead in terms of time and space from creating multiple X server connections.

The other issue is that of concurrent access through a single X server connection. As far as I know, if you have several threads accessing X through a single connection (Display-structure), then you need to apply thread synchronization primitives (eg. XLockDisplay/XUnlockDisplay) to wrap all Xlib calls (especially those relating to the shared X server connection). On the other hand, if you use a separate X connection for each thread, I believe you may leave out the synchronization primitives and possibly gain something in performance.

Assuming that I choose to use a single shared X connection, there is still a question about which library-functions should be protected by synchronization primitives. As I see it, there are three libraries to consider in this context:

Library   Functions                       Need thread sync*
Xlib      XMapWindow, XWarpPointer        YES?
GLX       glXMakeCurrent glXSwapBuffers   ?????
GL        glVertex, glMultMatrix          NO?
  • when several threads use a single shared X connection:

Xlib calls must be protected, since that is the reason for the existence of XLockDisplay/XUnlockDisplay. OpenGL calls should not, I think, since they are relayed through the GLX rendering context. Is this true???

But what about calls to GLX, should they be protected by synchronization primitives? That is, are they like Xlib calls, or like GL calls. My best guess is, that they are line Xlib calls, and thus need synchronization, since they have a Display-argument, just like the Xlib calls. Could someone confirm or dismiss this assumption?

So, If any of you could give me some guidelines in terms of the issues outlined above (and possible some issues that I’m not aware off) it would help me a lot - and I would be very thankful.

Cheers folks

– Kristian

Your problem of drawing from a single thread to multiple displays is not the same as drawing from multiple threads to a single display and you seem to be confusing the two problems in some of the things you’ve posted.

What’s your physical setup? You’re not doing this over the network are you? Creating an entirely separate direct rendering context on different displays in separate threads is probably the best way to go but it may depend on the number of processors you have.

If you’re over the network then the answer will be different and would probably be “don’t do that”.

If you have a distributed system then run a rendering thread on the distributed nodes and synchronize things like viewing matrix over the network. It is actually simpler to implement than you seem to be assuming, at least until you get into detailed synchronization issues.