http://sourceforge.net/projects/virtualgl/files/2.4/
Significant changes since 2.4 beta1: [1] Fixed an issue that prevented recent versions of Google Chrome/Chromium from running properly in VirtualGL. [2] VGL_SYNC now affects glFlush(). Although this does not strictly conform to the OpenGL spec (glFlush() is supposed to be an asynchronous command), it was necessary in order to make certain features of Cadence Allegro work properly. Since virtually no applications require VGL_SYNC, it is believed that this change is innocuous. [3] Fixed a bug in vglconnect introduced in VirtualGL 2.3 that prevented 'vglconnect -x' from working properly if the user did not have access to the current directory (vglconnect was erroneously creating a temporary file in the current directory instead of in /tmp.) [4] GLXspheres now warns if the specified polygon count would exceed the limit of 57600 polygons per sphere imposed by GLU and prints the actual polygon count with this limit taken into account. Also, a new option (-n) has been introduced to increase the sphere count. [5] VirtualGL will now only enable color index rendering emulation if a color index context is current. This specifically fixes an interaction issue with MSC Mentat, which occasionally calls glIndexi() when an RGBA context is current, but the fix may affect other applications as well. [6] VirtualGL can now interpose enough of the XCB API to make Qt 5 work properly. Qt 5 does not use XCB to perform 3D rendering (there is no suitable XCB replacement for GLX yet), but it does use XCB to detect whether the GLX extension is available and to handle the application's event queue(s). Thus, when attempting to run Qt 5 applications in VirtualGL, previously the OpenGL portion of the window would fail to resize when the window was resized, or the application would complain that OpenGL was not available and fail to start, or the application would fall back to non-OpenGL rendering. Currently, enabling XCB support in VirtualGL requires building VirtualGL from source and adding -DVGL_FAKEXCB=1 to the CMake command line. The XCB interposer is also disabled by default at run time. It must be enabled by setting the VGL_FAKEXCB environment variable to 1 or passing +xcb to vglrun. [7] Fixed a deadlock that occurred when running compiz 0.9.11 (and possibly other versions as well) with VirtualGL. The issue occurred when compiz called XGrabServer(), followed by glXCreatePixmap() and glXDestroyPixmap(). In VirtualGL, a GLX pixmap resides on the 3D X server, but the corresponding X11 pixmap resides on the 2D X server. Thus, VirtualGL has to synchronize pixels between the two pixmaps in response to certain operations, such as XCopyArea() and XGetImage(), or when the GLX pixmap is destroyed. VirtualGL was previously opening a new connection to the 2D X server in order to perform this synchronization, and because the 2D X server was grabbed, compiz locked up when VirtualGL called XCloseDisplay() on the new display connection. In fact, however, the new display connection was unnecessary, since the GLX/X11 pixmap synchronization occurs within the 3D rendering thread. Thus, VirtualGL now simply reuses the same display connection that is passed to glXCreate[GLX]Pixmap(). [8] NetTest and TCBench for Windows are now supplied in a package called VirtualGL-Utils, which can be built from the VirtualGL source. When the VirtualGL Client for Exceed was discontinued, these utilities ceased to have a home, but they are still useful tools to have, irrespective of the thin client solution that is being used. The Windows build of TCBench was temporarily moved into the Windows TurboVNC Viewer packages, but it proved to be a pain to keep the source code synchronized between the two projects. The VirtualGL-Utils package additionally contains a WGL version of GLXspheres, which is a useful tool to have when benchmarking Windows virtual machines that are running in a VirtualGL environment. [9] Worked around an issue in recent versions of SPECviewperf and FEMFAT visualizer that caused them to segfault when used with VirtualGL. Those applications apparently use a dynamic loading mechanism for OpenGL extension functions, and this mechanism defines symbols such as "glGenBuffers" at file scope. Any symbol exported by an application will override a symbol of the same name exported by a shared library, so when VirtualGL tried to call glGenBuffers(), glBindBuffer(), etc., it was picking up the symbols from the application, not from libGL (and those symbols from the application were not necessarily defined.) VirtualGL now obtains the function pointers it needs for PBO readback directly from libGL using glXProcAddress() rather than relying on the dynamic linker to resolve them. Note that this issue could be worked around in previous versions of VirtualGL by setting VGL_READBACK=sync. ------------------------------------------------------------------------------ Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/ _______________________________________________ VirtualGL-Devel mailing list VirtualGL-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-devel
