Multiple X connections for multithreaded rendering?

[Kristian_Spangsege]

Hi,

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

[jide]

First, no you should not have several different X connections. But only if you really need it (as if you weren’t in multithreading).

I really advise to synchronize the glx context, and even some X functions if you use them in more than one thread.
The glx spec should help you.

For GL, it depends on how you do multithreading: you cannot draw with 2 threads in one window without having any problem. Some synchronization will surely be needed. However, I cannot tell you more on that.

Hope this helps;

[zen]

Why are seperate X connections bad? Time overhead shouldn’t be a problem as it happens once at startup and doesn’t take much time. Is space overhead that bad?

[jide]

Originally posted by zen:
Why are seperate X connections bad? Time overhead shouldn’t be a problem as it happens once at startup and doesn’t take much time. Is space overhead that bad?
This was not what I meant, my english isn’t really good yet…

I was telling that it’s not necessary to have more than one X display connection in a multithreading program. If they are necessary (in the case of having several windows for example), then there will need for them, then synchronize them with XLockDisplay() or other means.

Really hope this helps

[jide]

Originally posted by jide:

I really advise to synchronize the glx context, and even some X functions if you use them in more than one thread.
…
Oups. Not the context that cannot get threw one thread to another, but with creating new one and sharing an existing context.

You’ll need to synchronize the glx drawable (if any) or the X Window then.
You’ll have to synchronize with others if you need to do more than rendering.