I think we saw a similar issue when we first started testing the ATI cards.
For this and other reasons, we run one xserver for each ATI card.
On Fri, Dec 20, 2013 at 3:40 PM, Tyson Whitehead <twhiteh...@gmail.com>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
>
--
Kevin Van Workum, PhD
Sabalcore Computing Inc.
"Where Data Becomes Discovery"
http://www.sabalcore.com
877-492-8027 ext. 11
--
------------------------------------------------------------------------------
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
