Re: [VirtualGL-Users] VirtualGL 2.4.1 has been released

[Morgan R. <mor...@ro...>]

Have you considered migrating to github from sourceforge, in light of their
recent behavior? Sorry if this has already been addressed.

On Fri, Jun 12, 2015 at 8:19 AM, DRC <dco...@us...>
wrote:

> http://sourceforge.net/projects/virtualgl/files/2.4.1/
>
> Packaging changes:
> These packages were built with libjpeg-turbo 1.4.1:
> http://sourceforge.net/projects/libjpeg-turbo/files/1.4.1/
> This improves performance on 64-bit Mac clients, relative to VirtualGL 2.4.
>
> Significant changes since 2.4:
>
> [1] When an application doesn't explicitly specify its visual
> requirements by calling glXChooseVisual()/glXChooseFBConfig(), the
> default GLX framebuffer config that VirtualGL assigns to it now contains
> a stencil buffer.  This eliminates the need to specify
> VGL_DEFAULTFBCONFIG=GLX_STENCIL_SIZE,8 with certain applications
> (previously necessary when running Abaqus v6 and MAGMA5.)
>
> [2] VirtualGL will no longer advertise that it supports the
> GLX_ARB_create_context and GLX_ARB_create_context_profile extensions
> unless the underlying OpenGL library exports the
> glXCreateContextAttribsARB() function.
>
> [3] Fixed "Invalid MIT-MAGIC-COOKIE-1" errors that would prevent
> VirtualGL from working when vglconnect was used to connect to a
> VirtualGL server from a client running Cygwin/X.
>
> [4] If a 3D application is rendering to the front buffer and one of the
> end-of-frame trigger functions (glFlush()/glFinish()/glXWaitGL()) is
> called, VirtualGL will no longer read back the framebuffer unless the
> render mode is GL_RENDER.  Reading back the front buffer when the render
> mode is GL_SELECT or GL_FEEDBACK is not only unnecessary, but it was
> known to cause a GLXBadContextState error with newer nVidia drivers
> (340.xx and later) in certain cases.
>
> [5] Fixed a deadlock that occurred in the multi-threaded rendering test
> of fakerut when it was run with the XCB interposer enabled.  This was
> due to VirtualGL attempting to handle XCB events when Xlib owned the
> event queue.  It is possible that this issue affected or would have
> affected real-world applications as well.
>
> [6] Fixed an issue that caused certain 3D applications (observed with
> CAESES/FFW, although others were possibly affected as well) to abort
> with "ERROR: in TempContext-- Could not bind OpenGL context to window
> (window may may have disappeared)".  When the 3D application called
> glXChooseVisual(), VirtualGL was choosing a corresponding FB config with
> GLX_DRAWABLE_TYPE=GLX_PBUFFER_BIT (assuming that VGL_DRAWABLE=pbuffer,
> which is the default.)  This is incorrect, however, because regardless
> of the value of VGL_DRAWABLE, VirtualGL still uses Pixmaps on the 3D X
> server to represent GLX Pixmaps (necessary in order to make
> GLX_EXT_texture_from_pixmap work properly.)  Thus, VGL needs to choose
> an FB config that supports both Pbuffers and Pixmaps.  This was
> generally only a problem with nVidia drivers, because they export
> different FB configs for GLX_PBUFFER_BIT and
> GLX_PBUFFER_BIT|GLX_PIXMAP_BIT.
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> VirtualGL-Users mailing list
> Vir...@li...
> https://lists.sourceforge.net/lists/listinfo/virtualgl-users
>