Results 1 to 1 of 1
Hi, I'm working on some code for handling multi-threaded OpenGL rendering through the use of multiple GLXContext's. My question is, if I should use a separate X server connection for ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
- 05-30-2004 #1
- Join Date
- May 2004
- Denmark, Copenhagen
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.
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?
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.