We have a VNC + VirtualGL setup on machines with dual AMD FirePro V9800 ATI cards. The machines are running
Fedora 20 AMD Catalyst 3.11.10 (rpm fusion package) VirtualGL 2.3.3 (fedora package) If Xorg is configured with a single device section, so it only used a single card, everything works fine. $ DISPLAY=:0 glxinfo name of display: :0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: ATI server glx version string: 1.4 ... and $ vglrun -c proxy glxinfo name of display: 2607:fd78:30a:101:21f:29ff:fe04:29aa:1 display: 2607:fd78:30a:101:21f:29ff:fe04:29aa:1 screen: 0 direct rendering: Yes server glx vendor string: VirtualGL server glx version string: 1.4 ... This is non-ideal though as this means OpenCL applications are only able to use a single GPU. Configuring Xorg with two device sections, so it uses two cards, causes VirtualGL to fail $ DISPLAY=:0 glxinfo name of display: :0 display: :0 screen: 0 direct rendering: Yes server glx vendor string: ATI server glx version string: 1.4 ... display: :0 screen: 1 direct rendering: Yes server glx vendor string: ATI server glx version string: 1.4 ... but $ vglrun -c proxy glxinfo X Error of failed request: BadValue (integer parameter out of range for operation) Major opcode of failed request: 149 (GLX) Minor opcode of failed request: 21 (X_GLXGetFBConfigs) Value in failed request: 0x1 Serial number of failed request: 16 Current serial number in output stream: 16 name of display: 2607:fd78:30a:101:21f:29ff:fe04:b8cc:1 Running it under gdb (with _Xdebug to 1 and a breakpoint on _XDefaultError) gives the following backtrace #0 _XDefaultError (dpy=0x616460, event=0x7fffffffddb0) at XlibInt.c:1412 #1 0x0000003c558450bb in _XError (dpy=dpy@entry=0x616460, rep=rep@entry=0x7be110) at XlibInt.c:1463 #2 0x0000003c558420b7 in handle_error (dpy=dpy@entry=0x616460, err=0x7be110, in_XReply=in_XReply@entry=1) at xcb_io.c:213 #3 0x0000003c5584320b in _XReply (dpy=0x616460, rep=0x7fffffffe240, extra=0, discard=0) at xcb_io.c:699 #4 0x00000033e743ecf4 in ?? () from /usr/lib64/catalyst/libGL.so.1 #5 0x00000033e7439963 in glXGetConfig () from /usr/lib64/catalyst/libGL.so.1 #6 0x00007ffff7ba376e in _glXGetConfig (value=0x7bc0c8, attrib=5, vis=0x7ba2a0, dpy=0x616460) at /usr/src/debug/VirtualGL-2.3.3/server/faker-sym.h:164 #7 buildVisAttribTable (dpy=dpy@entry=0x616460, screen=screen@entry=0) at /usr/src/debug/VirtualGL-2.3.3/server/glxvisual.cpp:132 #8 0x00007ffff7ba4bdf in __vglMatchVisual (dpy=dpy@entry=0x616460, screen=screen@entry=0, depth=24, c_class=4, level=0, stereo=0, trans=0) at /usr/src/debug/VirtualGL-2.3.3/server/glxvisual.cpp:350 #9 0x00007ffff7b8605a in glXChooseVisual (dpy=dpy@entry=0x616460, screen=screen@entry=0, attrib_list=attrib_list@entry=0x607200 <attribs.28806>) at /usr/src/debug/VirtualGL-2.3.3/server/faker-glx.cpp:376 #10 0x0000000000401721 in mesa_hack (scrnum=0, dpy=0x616460) at glxinfo.c:1589 #11 main (argc=<optimized out>, argv=<optimized out>) at glxinfo.c:1730 Strangely enough, it seems it dies while enumerating the visuals on the VNC X server. Specifically, while fetching GL properties. Digging through the VirtualGL code revealed the VGL_PROBEGLX=0 hack can be used to disable fetching GL properties during this enumeration. This seems to work $ VGL_PROBEGLX=0 vglrun -c proxy glxinfo name of display: 2607:fd78:30a:101:21f:29ff:fe04:29aa:1 display: 2607:fd78:30a:101:21f:29ff:fe04:29aa:1 screen: 0 direct rendering: Yes server glx vendor string: VirtualGL server glx version string: 1.4 ... I'm presuming this maybe means the AMD GLX implementation has some sort of buggy shared state between displays that is tripping it up when the number of screens differs? Any thoughts? Thanks! -Tyson PS: One other big of strangeness I noticed was that under the single card configuration all the "tc" visuals from "DISPLAY=:0 glxinfo" have id 0x0a3 81 GLX Visuals ... 0x0a3 32 tc 0 32 0 r . . 8 8 8 8 . . 0 24 0 0 0 91 GLXFBConfigs ... 0x0a3 32 tc 0 32 0 r . . 8 8 8 8 . . 0 24 0 0 0 0x0a3 32 tc 0 32 0 r y . 8 8 8 8 . . 0 24 0 0 0 0x0a3 32 tc 0 32 0 r y . 8 8 8 8 . . 0 24 8 0 0 0x0a3 32 tc 0 32 0 r . . 8 8 8 8 . . 0 24 8 0 0 0x0a3 32 tc 0 32 0 r . . 8 8 8 8 . . 0 0 0 0 0 0x0a3 0 tc 0 128 0 y . 32 32 32 32 . . 0 24 0 0 0 0x0a3 0 tc 0 128 0 . . 32 32 32 32 . . 0 24 0 0 0 0x0a3 0 tc 0 64 0 y . 16 16 16 16 . . 0 24 0 0 0 0x0a3 0 tc 0 64 0 . . 16 16 16 16 . . 0 24 0 0 0 0x0a3 0 tc 0 32 0 y . 11 11 10 0 . . 0 24 0 0 0 0x0a3 0 tc 0 32 0 . . 11 11 10 0 . . 0 24 0 0 0 but this changes to id 0x122 under the dual card configuration 81 GLX Visuals ... 0x122 32 tc 0 32 0 r . . 8 8 8 8 . . 0 24 0 0 0 91 GLXFBConfigs ... 0x122 32 tc 0 32 0 r . . 8 8 8 8 . . 0 24 0 0 0 0x122 32 tc 0 32 0 r y . 8 8 8 8 . . 0 24 0 0 0 0x122 32 tc 0 32 0 r y . 8 8 8 8 . . 0 24 8 0 0 0x122 32 tc 0 32 0 r . . 8 8 8 8 . . 0 24 8 0 0 0x122 32 tc 0 32 0 r . . 8 8 8 8 . . 0 0 0 0 0 0x122 0 tc 0 128 0 y . 32 32 32 32 . . 0 24 0 0 0 0x122 0 tc 0 128 0 . . 32 32 32 32 . . 0 24 0 0 0 0x122 0 tc 0 64 0 y . 16 16 16 16 . . 0 24 0 0 0 0x122 0 tc 0 64 0 . . 16 16 16 16 . . 0 24 0 0 0 0x122 0 tc 0 32 0 y . 11 11 10 0 . . 0 24 0 0 0 0x122 0 tc 0 32 0 . . 11 11 10 0 . . 0 24 0 0 0 ------------------------------------------------------------------------------ Rapidly troubleshoot problems before they affect your business. Most IT organizations don't have a clear picture of how application performance affects their revenue. With AppDynamics, you get 100% visibility into your Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro! http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk _______________________________________________ VirtualGL-Users mailing list VirtualGL-Users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/virtualgl-users
