Surely i3 is a window manager and not a display manager? As such, I can't imagine how it would interfere with the MIT-SHM extension. That extension is controlled by the underlying X server, not the window manager. Generally display managers live on the 3D X server, and the issue you were encountering was related to the 2D X server. It sounds like maybe the streams got crossed somewhere (https://www.youtube.com/watch?v=wyKQe_i9yyo).
You shouldn't ever use vglconnect in an X proxy such as FastX, unless the X proxy is located on a different machine than the VirtualGL server (refer to the VirtualGL User's Guide.) That may be why you observed poor performance with the VGL Transport. If you tried to run vglconnect within the X proxy session, then the VirtualGL Client was actually running on the server machine, so you were just adding a useless layer of compression/decompression within that machine. vglconnect, in general, should only be used if the 2D X server is not located on the same machine as the VirtualGL server. That configuration is not common these days, and as such, the VGL Transport is also not very common. Most people just use the X11 Transport with an X proxy. The VGL Transport performs fine on a LAN as long as you are using JPEG compression. It is only *without* JPEG compression-- using VGL_COMPRESS=rgb or '-c rgb'-- that gigabit is required for the VGL Transport. If you are using a WAN, then you should always use an X proxy. TurboVNC is the only one of those that I personally support. DRC On 3/15/19 11:28 AM, Jason wrote: > Good Afternoon, > > Wonderful! The VGL_USEXSHM=0 certainly fixed the issue. I believe > what may have been contributing to the issue might have been the > particular Display manager (i3) I was using to perform the runs. I > suspect this since the other tests I have performed on other machines > with different configurations (namely, an Nvidia card on a Debian > machine with Wine applications), similar errors would crop up and could > be resolved by using non-i3 desktops (it's probably due to some missing > X-based packages that i3 does not typically install). To further this > confirmation, I ran the command in a FastX session (which is similar to > Xephyr, but has more GUI wrapping, server/client management, etc., said > to natively support VirtualGL) using MATE desktop and was able to > minimize the command to: "VGL_FORCEALPHA=1 vglrun -d :1 <cmd args>" and > had it work successfully, both with "-c 0" and "vglconnect" options. > Ironically, when I tested the difference between the proxy and JPEG > methods on the Nvidia machine, I had far better performance using the > proxy than I did with the vglclient/vglconnect methods (if I understood > correctly, the docs <https://virtualgl.org/vgldoc/2_2_1/#hd008002> > stated that the proxy method could potentially work better over Gigabit > networks). In either case, we are rather excited to finally utilize the > AMD cards. > > Thanks for all the help, > > - Jason > > On Thursday, March 14, 2019 at 2:14:47 PM UTC-4, Jason wrote: > > Good Afternoon all, > > I am trying to debug an issue with using VirtualGL with an AMD > card. Running the command "vglrun +v -c 0 -d :1 > /opt/VirtualGL/bin/glxinfo" (and other subsequent commands) produces > the following error: > > [VGL] Shared memory segment ID for vglconfig: 28704793 > [VGL] VirtualGL v2.6.1 64-bit (Build 20190101) > name of display: localhost:10.0 > [VGL] Opening connection to 3D X server :1 > [VGL] NOTICE: Replacing dlopen("libGL.so.1") with > dlopen("libvglfaker.so") > [VGL] NOTICE: Replacing dlopen("libGL.so.1") with > dlopen("libvglfaker.so") > [VGL] WARNING: Could not load function "glXSwapIntervalEXT" > [VGL] WARNING: Could not load function "glXBindSwapBarrierNV" > [VGL] WARNING: Could not load function "glXJoinSwapGroupNV" > [VGL] WARNING: Could not load function "glXQueryFrameCountNV" > [VGL] WARNING: Could not load function "glXQueryMaxSwapGroupsNV" > [VGL] WARNING: Could not load function "glXQuerySwapGroupNV" > [VGL] WARNING: Could not load function "glXResetFrameCountNV" > [VGL] Using Pbuffers for rendering > failed to create drawable > X Error of failed request: BadValue (integer parameter out of range > for operation) > Major opcode of failed request: 53 (X_CreatePixmap) > Value in failed request: 0x1e > Serial number of failed request: 30 > Current serial number in output stream: 31 > > > Some details: > > * OS: 4.15.0-46-generic #49~16.04.1-Ubuntu SMP x86_64 GNU/Linux > * GPU: > o 65:00.0 VGA compatible controller: Advanced Micro Devices, > Inc. [AMD/ATI] Vega 10 XT [Radeon PRO WX 9100] (prog-if 00 > [VGA controller]) > Subsystem: Advanced Micro Devices, Inc. [AMD/ATI] > Device 0c1e > Flags: bus master, fast devsel, latency 0, IRQ 155 > Memory at 3a000000000 (64-bit, prefetchable) [size=16G] > Memory at 3a400000000 (64-bit, prefetchable) [size=2M] > I/O ports at 4000 [size=256] > Memory at c4400000 (32-bit, non-prefetchable) > [size=512K] > [virtual] Expansion ROM at c44a0000 [disabled] > [size=128K] > Capabilities: <access denied> > Kernel driver in use: amdgpu > Kernel modules: amdgpu > * The connection is over SSH with X forwarding > * The AMD proprietary driver is installed (although, I'm skeptical > whether it is in use or not) > * We are using a custom xorg file to keep our headless > configuration separate: > o Section "Device" > ### Available Driver options are:- > ### Values: <i>: integer, <f>: float, <bool>: > "True"/"False", > ### <string>: "String", <freq>: "<f> Hz/kHz/MHz", > ### <percent>: "<f>%" > ### [arg]: arg optional > #Option "ShadowFB" # [<bool>] > #Option "DefaultRefresh" # [<bool>] > #Option "ModeSetClearScreen" # [<bool>] > Identifier "Card1" > Driver "amdgpu" > BusID "PCI:101:0:0" > EndSection > * There is a separate graphics card installed for ensuing that we > can attach a display to the machine if all else fails. > * The VirtualGL config was setup with proper access > > Please let me know if there are any further details that you need. > We appreciate the help with this issue. > > Thanks, > Jason > > -- > You received this message because you are subscribed to the Google > Groups "VirtualGL User Discussion/Support" group. > To unsubscribe from this group and stop receiving emails from it, send > an email to [email protected] > <mailto:[email protected]>. > To view this discussion on the web visit > https://groups.google.com/d/msgid/virtualgl-users/91b7a71f-1da1-4033-98b2-9b2dcb2e7877%40googlegroups.com > <https://groups.google.com/d/msgid/virtualgl-users/91b7a71f-1da1-4033-98b2-9b2dcb2e7877%40googlegroups.com?utm_medium=email&utm_source=footer>. > For more options, visit https://groups.google.com/d/optout. -- You received this message because you are subscribed to the Google Groups "VirtualGL User Discussion/Support" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/virtualgl-users/80c2987a-294a-c06d-9882-7f2422b2c9c0%40virtualgl.org. For more options, visit https://groups.google.com/d/optout.
