By chance have you tried the latest code in subversion trunk? I think this may be another symptom of a bug I already fixed, but it was fixed after the 2.3.3 release.
On 12/20/13 2:40 PM, Tyson Whitehead wrote: > 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 > ------------------------------------------------------------------------------ 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
