It seems to be an issue with the ATI drivers. You can reproduce it simply by running glxinfo without even getting VirtualGL involved. I've reproduced it using the latest (v8.773) Catalyst drivers on RHEL 4 and with several different types of remote X server and X proxy configurations. It seems that a seg fault always occurs in XF86DriQueryVersion() when GLX commands are issued from a system running the ATI drivers to an X server that has GLX support but isn't running the ATI drivers. Googling it reveals that apparently a lot of other people are experiencing this as well.
The only way to work around it at the moment is to use a 2D X Server without GLX support (TurboVNC, for instance, or disable GLX on your client machine.) The bug is so pervasive that you can't even use, for instance, TigerVNC or NX, because those X proxies both have software GLX support. Any 2D X Server with GLX support will cause the crash to occur, unless the X server is also using the ATI drivers. VirtualGL normally would not issue remote GLX commands, since its job is to intercept all GLX calls and hand them off to the 3D X Server. However, when the VGL Transport (vglconnect) is being used, VGL will issue a few remote calls to glXGetConfig() if it detects that the 2D X server supports GLX. These calls are used to probe for the existence of stereo visuals. Many applications allow you to dynamically enable stereo, and VirtualGL allows you to dynamically change between quad-buffered, red/cyan, and other stereo modes, so VGL needs to know at startup whether the 2D X Server supports quad-buffered stereo visuals so it can determine whether it will allow the application or the user to dynamically enable that mode later on. A possible workaround for this would be to implement a hidden environment variable called VGL_NOREMOTEGLX, which will simply cause VirtualGL to avoid making remote GLX calls. I really don't like implementing features to fix other people's bugs, though. If this were an esoteric bug that just affected VirtualGL, that would be one thing, but this is a very fundamental issue with the underlying driver stack, and it needs to be fixed by AMD. On 2/27/11 4:47 AM, Samu Niveri wrote: > Hello! > > I do not know how to correctly use this app. I was able to use VirtualGL > whit 32-bit server and 64-bit-client. When I tried to use it another way > round(64-bit server and 32-bit client) I get segmentation fault when > running: > > cd /opt/VirtualGL/bin > vglconnect myusername@myserver > > cd /opt/VirtualGL/bin > vglrun ./glxspheres > > in /opt/VirtualGL/bin > > In 32-bit machine I have i945 intel graphics and in 64-bit machine I > have ATI Radeon HD2600. Both machines has Ubuntu 10.10 and in 64-bit > there is installed latest ATI-Radeon drivers from AMD site: > > Catalyst version:11.2 > OpenGL version:3.3.10524 > > And if i try to run it with: > > cd /opt/VirtualGL/bin > vglconnect -x myusername@myserver > > cd /opt/VirtualGL/bin > vglrun ./glxspheres > > Then it says "cannot not open display" or something similar. > > Output of vglrun +tr ./glxspheres is: > > Polygons in scene: 62464 > [VGL] XOpenDisplay (name=NULL dpy=0x09a91588(localhost:10.0) ) 32.973028 ms > [VGL] glXChooseVisual (dpy=0x09a91588(localhost:10.0) screen=0 > attrib_list=[0x0004 0x0008=0x0008 0x0009=0x0008 0x000a=0x0008 > 0x000c=0x0001 0x0005 ] [VGL] dlopen (filename=libGL.so.1 flag=258 > retval=0xf76eeca0) > [VGL] dlopen (filename=/usr/X11R6/lib/modules/dri/fglrx_dri.so flag=2 > retval=0x00000000) > [VGL] dlopen (filename=/usr/lib/dri/fglrx_dri.so flag=2 retval=0x00000000) > [VGL] dlopen (filename=/usr/X11R6/lib32/modules/dri/fglrx_dri.so flag=2 > retval=0x00000000) > [VGL] dlopen (filename=/usr/lib32/dri/fglrx_dri.so flag=2 retval=0x00000000) > Segmentation fault > > So is this something related to ATI or user fault? > > - Samu > > > > > > > > ------------------------------------------------------------------------------ > Free Software Download: Index, Search & Analyze Logs and other IT data in > Real-Time with Splunk. Collect, index and harness all the fast moving IT data > generated by your applications, servers and devices whether physical, virtual > or in the cloud. Deliver compliance at lower cost and gain new business > insights. http://p.sf.net/sfu/splunk-dev2dev > > > > _______________________________________________ > VirtualGL-Users mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/virtualgl-users ------------------------------------------------------------------------------ Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar _______________________________________________ VirtualGL-Users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/virtualgl-users
