As noted in email, this currently loads the xcb symbols into every apps symbol namespace. A more correct approach is to only do so when we see an xcb symbol used, which requires we build the full xcb_connection_t* -> Display * hash at that time.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This has been implemented in trunk, but in a slightly different way. The code in trunk (2.5 alpha) makes the following major changes:
(1) It attempts to load "real" X11/XCB/OpenGL/GLX function symbols as needed instead of all at once in vglfaker::init(). XCB symbols are loaded directly from the respective XCB libraries (/usr/lib*/libxcb*) instead of using RTLD_NEXT, and the name of each of the XCB libraries can be overridden with an environment variable.
(2) The necessary XCB headers are included in the source tree, so VGL can be built with the XCB interposer enabled, even on machines that don't have XCB (RHEL 5.) VGL_FAKEXCB now defaults to TRUE in the build.
(3) Because the XCB interposer should now be less intrusive and more universal, it is also enabled by default at run time (but can be disabled with 'vglrun -xcb'.)
(4) If invoked with 'vglrun -nodl', the faker will no longer load libGL into the 3D application process at all until the first time an OpenGL or GLX function is called. This is implemented by way of a second interposer (vglfaker-nodl) that is not linked with libGL. This also serves as a sanity check on the build, ensuring that no OpenGL/GLX functions are linked directly from libGL.
It is unknown whether this will fix any real application issues, but in the past, there have been issues with specific 3D applications caused by libGL being loaded too early, so my thought was that having a separate interposer for -nodl will minimally serve as a good troubleshooting tool.
(5) All OpenGL/GLX functions are now loaded using glXGetProcAddress() instead of dlsym() (except for glXGetProcAddress() itself, which is still loaded with dlsym().) This is mainly to prevent issues such as in Viewperf, where an application could override one of the OpenGL/GLX function symbols and cause VirtualGL to load the application's symbol instead of the one in libGL. This also maintains a workaround I had for the AMD drivers under Ubuntu-- certain versions of those drivers have an incomplete mapfile/version script in libGL.so.1, so you can load certain functions with glXProcAddress() that are not loadable using dlsym().
(6) Both trunk and branches/2.4.x now contain a patch that fixes a deadlock I discovered while running the multi-threaded tests in fakerut with vglrun +xcb. This was caused by VirtualGL handling XCB events even if XCB didn't own the event queue. Now VGL will only handle XCB events if the application assigns control of the event queue to XCB.
(7) Removed the old fallback mechanism that was formerly used to work around the bug in nVidia 18x.xx that broke RTLD_NEXT. I don't think anyone should still be on 18x.xx, but if they are, the bug can still be worked around by explicitly setting VGL_GLLIB.
Any feedback on the new code would be appreciated.
Last edit: DRC 2015-05-27
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As noted in email, this currently loads the xcb symbols into every apps symbol namespace. A more correct approach is to only do so when we see an xcb symbol used, which requires we build the full xcb_connection_t* -> Display * hash at that time.
This has been implemented in trunk, but in a slightly different way. The code in trunk (2.5 alpha) makes the following major changes:
(1) It attempts to load "real" X11/XCB/OpenGL/GLX function symbols as needed instead of all at once in vglfaker::init(). XCB symbols are loaded directly from the respective XCB libraries (/usr/lib*/libxcb*) instead of using RTLD_NEXT, and the name of each of the XCB libraries can be overridden with an environment variable.
(2) The necessary XCB headers are included in the source tree, so VGL can be built with the XCB interposer enabled, even on machines that don't have XCB (RHEL 5.) VGL_FAKEXCB now defaults to TRUE in the build.
(3) Because the XCB interposer should now be less intrusive and more universal, it is also enabled by default at run time (but can be disabled with 'vglrun -xcb'.)
(4) If invoked with 'vglrun -nodl', the faker will no longer load libGL into the 3D application process at all until the first time an OpenGL or GLX function is called. This is implemented by way of a second interposer (vglfaker-nodl) that is not linked with libGL. This also serves as a sanity check on the build, ensuring that no OpenGL/GLX functions are linked directly from libGL.
It is unknown whether this will fix any real application issues, but in the past, there have been issues with specific 3D applications caused by libGL being loaded too early, so my thought was that having a separate interposer for -nodl will minimally serve as a good troubleshooting tool.
(5) All OpenGL/GLX functions are now loaded using glXGetProcAddress() instead of dlsym() (except for glXGetProcAddress() itself, which is still loaded with dlsym().) This is mainly to prevent issues such as in Viewperf, where an application could override one of the OpenGL/GLX function symbols and cause VirtualGL to load the application's symbol instead of the one in libGL. This also maintains a workaround I had for the AMD drivers under Ubuntu-- certain versions of those drivers have an incomplete mapfile/version script in libGL.so.1, so you can load certain functions with glXProcAddress() that are not loadable using dlsym().
(6) Both trunk and branches/2.4.x now contain a patch that fixes a deadlock I discovered while running the multi-threaded tests in fakerut with vglrun +xcb. This was caused by VirtualGL handling XCB events even if XCB didn't own the event queue. Now VGL will only handle XCB events if the application assigns control of the event queue to XCB.
(7) Removed the old fallback mechanism that was formerly used to work around the bug in nVidia 18x.xx that broke RTLD_NEXT. I don't think anyone should still be on 18x.xx, but if they are, the bug can still be worked around by explicitly setting VGL_GLLIB.
Any feedback on the new code would be appreciated.
Last edit: DRC 2015-05-27