X Create Pixmap Error 53 when using VGLRUN

[Jason]

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:
• 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:
• 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

[DRC]

Try setting VGL_FORCEALPHA=1 in the environment. That seems to be a
standard remedy for the broken amdgpu drivers.

> * 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 virtualgl-use...@googlegroups.com
> <mailto:virtualgl-use...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/virtualgl-users/d7121db9-ee84-46c0-87d6-eebadbc23028%40googlegroups.com
> <https://groups.google.com/d/msgid/virtualgl-users/d7121db9-ee84-46c0-87d6-eebadbc23028%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.

[Jason]

Good Morning,

    That solution worked splendidly for bypassing the opcode 53. Unfortunately, I am now faced with another similar-looking error:

[VGL] Shared memory segment ID for vglconfig: 63406084

[VGL] VirtualGL v2.6.1 64-bit (Build 20190101)

[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")

Visual ID of window: 0x21
Context is Direct

[VGL] Using Pbuffers for rendering

OpenGL Renderer: Radeon Pro WX 9100 (VEGA10, DRM 3.27.0, 4.15.0-46-generic, LLVM 7.0.1)
X Error of failed request:  BadRequest (invalid request code or no such operation)
  Major opcode of failed request:  130 (MIT-SHM)
  Minor opcode of failed request:  1 (X_ShmAttach)
  Serial number of failed request:  13
  Current serial number in output stream:  14

Here are a few of the steps I've tried to bypass this new issue:

• https://bbs.archlinux.org/viewtopic.php?pid=1508298#p1508298

• export QT_X11_NO_MITSHM=1

• (I know this isn't a QT issue, but it was worth a shot)
• https://lists.centos.org/pipermail/centos/2006-February/018416.html

• X11UseLocahost yes

• (This modifies the /etc/ssh/sshd_config file)
• https://github.com/jessfraz/dockerfiles/issues/359#issuecomment-395371557

• Section "Extensions"
      Option "MIT-SHM" "Disable"
  EndSection

• (This was the more promising option, but had no effect)

I greatly appreciate the help!

- Jason

[DRC]

VirtualGL is designed to be used either with:

- an X proxy, which is a virtual X server (such as TurboVNC or TigerVNC
or FreeNX or Xpra, etc.) that renders X11 drawing commands into images
in main memory and then sends compressed image updates to a client or
clients. In this mode, VirtualGL uses its built-in "X11 Transport" to
draw OpenGL-rendered frames into the X proxy using the MIT-SHM X11
extension.

... or ...

- remote X (an X server running on the client machine.) In this mode,
VirtualGL uses its built-in "VGL Transport" to compress OpenGL-rendered
frames as JPEG images and send them to the client machine, where they
are received by the VirtualGL Client application, decompressed, and
drawn into the 2D X server using the MIT-SHM X11 extension.

(This is all in the User's Guide, BTW.)

The problem appears to be that you are trying to use the X11 Transport
with remote X. In fact, you are forcing it to be used by passing -c 0
to vglrun, which is almost never a good idea. VirtualGL will, by
default, automatically detect whether the 2D X server connection is
remote or local and activate the appropriate transport. Forcing the X11
Transport when using SSH with X11 forwarding is far from optimal, since
it will result in OpenGL-rendered frames being sent over the network in
uncompressed form. I recommend either installing TurboVNC on the server
and client machines and using that along with VirtualGL, or installing
the VirtualGL Client on the client machine and using vglconnect to
connect to the server (vglconnect is a wrapper script for starting the
VirtualGL Client and connecting to the server with SSH.)

The X11 Transport in VirtualGL *should* detect that MIT-SHM doesn't work
(which is expected when using a remote X connection) and fall back to a
slower X11 drawing method, so I'm not sure why you're getting an MIT-SHM
error. It may be due to a problem with the 2D X server (stranger things
have happened), or maybe SSH is interfering somehow with VirtualGL's
ability to trap the MIT-SHM error. You can try setting VGL_USEXSHM=0 in
the environment (on the server, prior to invoking vglrun) to force the
X11 Transport not to use the MIT-SHM extension. Again, however,
performance is going to suck unless you use an X proxy or the VGL
Transport, so I really recommend that you do that rather than trying to
work around this issue.

On 3/15/19 8:49 AM, Jason wrote:
> Good Morning,
>
>     That solution worked splendidly for bypassing the opcode 53.
> Unfortunately, I am now faced with another similar-looking error:
>
> [VGL] Shared memory segment ID for vglconfig: 63406084
> [VGL] VirtualGL v2.6.1 64-bit (Build 20190101)
> [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")
> Visual ID of window: 0x21
> Context is Direct
> [VGL] Using Pbuffers for rendering
> OpenGL Renderer: Radeon Pro WX 9100 (VEGA10, DRM 3.27.0,
> 4.15.0-46-generic, LLVM 7.0.1)
> X Error of failed request:  BadRequest (invalid request code or no such
> operation)
>   Major opcode of failed request:  130 (MIT-SHM)
>   Minor opcode of failed request:  1 (X_ShmAttach)
>   Serial number of failed request:  13
>   Current serial number in output stream:  14
>
>
> Here are a few of the steps I've tried to bypass this new issue:
>

> * https://bbs.archlinux.org/viewtopic.php?pid=1508298#p1508298
> o
>
> |export QT_X11_NO_MITSHM=1|
>
> o (I know this isn't a QT issue, but it was worth a shot)
> * https://lists.centos.org/pipermail/centos/2006-February/018416.html
> o
>
> X11UseLocahost yes
>
> o (This modifies the /etc/ssh/sshd_config file)
> * https://github.com/jessfraz/dockerfiles/issues/359#issuecomment-395371557
> o

>
> |Section "Extensions" Option "MIT-SHM" "Disable" EndSection|
>

> o (This was the more promising option, but had no effect)

> * 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 virtualgl-use...@googlegroups.com
> <mailto:virtualgl-use...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/virtualgl-users/08d31580-77af-4efb-add3-9734d5d22abb%40googlegroups.com
> <https://groups.google.com/d/msgid/virtualgl-users/08d31580-77af-4efb-add3-9734d5d22abb%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Jason]

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 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:

[DRC]

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>

> * 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 virtualgl-use...@googlegroups.com
> <mailto:virtualgl-use...@googlegroups.com>.
> 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>.

[Jason]

Good Afternoon,

My mistake, i3 is a window manager (I get them mixed up from time to time :) ); LightDM is the display manager. Here is (to my knowledge) the layout of the environments:

• Cases 1, 2, 4, and 5 do not work well when used with an i3 desktop (but well for MATE, KDE, etc.).

• Cases 1 and 2 with i3 requires XFree86 to be disabled

• Cases 4 and 5 with i3 requires the VGL_USEXSHM=0 to be used

• Cases 1, 2, and 3 requires the VGL_FORCEALPHA=1 to be used

• Case 4 seemed to work better than Case 5 in performance (increasing the compression core count helped, but was still slower)

• Case 6 works when running vglrun in a terminal, but not when launching the desktop environment with "vglrun +wm" (audio is lost)

(Understandably, cases 3 and 6 are not supported like TurboVNC is, but I included them for completeness sake)

In no case is the scope going wider than CAN (while there is potential for WAN, we are focusing currently on the LAN-CAN performance).

In all, I am slowly, but surely understanding how Xorg, GLX and SSH all tie together. That being said, I appreciate your time helping us out with all of this.

Thanks,

   Jason

[DRC]

Ah, OK.  It makes much more sense now.  Some notes:

Case 1, 4:

This is using the X11 Transport over SSH, which is never a good idea.  Even with gigabit, the most you could ever hope to stream with uncompressed XPutImage() requests is in the neighborhood of 30 Megapixels/second (bearing in mind that each pixel is a full 32 bits in this case.)  Also, the overhead of SSH is likely going to reduce the throughput somewhat because of the immense size of the data stream (and thus the CPU cycles required to encrypt it.)  Perceptually lossless JPEG (Q95, 4:4:4) over 100 Megabit can easily do > 50 Megapixels/second, by comparison.  In short, this configuration is not something that should ever be used in production.

Case 2, 5:

Assuming you're already running vglclient on the client machine, this is the equivalent of using vglconnect (Note that '-c jpeg' is superfluous, because VGL will automatically select the VGL Transport w/ JPEG if it detects this configuration.)  This configuration should work fine if you're running a regular application over the gigabit CAN, but running a window manager is a different story.  Window managers do a lot of very image-intensive operations and require a lot of back & forth with the X server, so in general, it's not a good idea to run them without an X proxy.  It could simply be that i3 is less well-tuned for a remote X connection-- window managers in general aren't designed to be run over remote X.  Even on a gigabit CAN, there is going to be some network latency and overhead, and that can add up if the application (the WM, in this case) is issuing a lot of fine-grained X requests.

Cases 1, 2:

Not sure what you mean by "Cases 1 and 2 with i3 requires XFree86 to be disabled."  XFree86 hasn't been used by any Linux distribution in quite some time.

Case 3, 6:

This is an X proxy, so the actual connection to the X server is entirely within the server machine.  Thus, window managers are appropriate in this configuration.

Cases 1, 2, 3:

VGL_FORCEALPHA was required because of the amdgpu drivers, as previously noted.

Cases 4, 5:

Still very odd that VGL_USEXSHM=0 was required here, but the fact that Cases 1 and 2 didn't require that points to an issue with the server machine.

--

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 virtualgl-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/virtualgl-users/3174c035-7240-4a74-9b15-860f770f39f0%40googlegroups.com.

[DRC]

Note also: I have no real explanation for why Case 4 was faster than
Case 5, particularly if that wasn't the case for Case 1 and 2. However,
one important clue is the fact that VGL_USEXSHM=0 was required for Case
5. If in fact you were using the VGL Transport with JPEG encoding, then
VGL_USEXSHM could not have had any effect unless you set it on the
client machine (VGL_USEXSHM only affects the X11 Transport or
vglclient.) I'm not 100% convinced that you were using the VGL
Transport in Case 5. But regardless, like I said below, running a
window manager with Cases 1, 2, 4, or 5 is not a good idea.

>> VGL_Env.png
>>
>>
>> *

>>
>> Cases 1, 2, 4, and 5 do not work well when used with an i3 desktop
>> (but well for MATE, KDE, etc.).
>>

>> *

>>
>> Cases 1 and 2 with i3 requires XFree86 to be disabled
>>

>> *

>>
>> Cases 4 and 5 with i3 requires the VGL_USEXSHM=0 to be used
>>

>> *

>>
>> Cases 1, 2, and 3 requires the VGL_FORCEALPHA=1 to be used
>>

>> *

>>
>> Case 4 seemed to work better than Case 5 in performance
>> (increasing the compression core count helped, but was still slower)
>>

>> *

>>
>> Case 6 works when running vglrun in a terminal, but not when
>> launching the desktop environment with "vglrun +wm" (audio is lost)
>>
>> (Understandably, cases 3 and 6 are not supported like TurboVNC is, but
>> I included them for completeness sake)
>>
>>
>> In no case is the scope going wider than CAN (while there is potential
>> for WAN, we are focusing currently on the LAN-CAN performance).
>>
>> In all, I am slowly, but surely understanding how Xorg, GLX and SSH
>> all tie together. That being said, I appreciate your time helping us
>> out with all of this.
>>
>>
>> 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 virtualgl-use...@googlegroups.com

>> <mailto:virtualgl-use...@googlegroups.com>.

>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/virtualgl-users/3174c035-7240-4a74-9b15-860f770f39f0%40googlegroups.com

>> <https://groups.google.com/d/msgid/virtualgl-users/3174c035-7240-4a74-9b15-860f770f39f0%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Jason]

Good Afternoon,

    I ran a few more tests to apply these principles. To start (and only as a test), I ran SSH using the '-Y' option so see if there was any appreciable performance difference; it was marginal, but noticeable. The issue of disabling XFree86 applies to the cases where I was testing a few WINE applications. As before, I believe that several of these errors was a matter of the client Window Manager being i3, where it was missing some packages or other functionality necessary for rendering an application from the X-Forwarded SSH session. With cases 1, 2, 4 and 5: we are not directly running a window manager; we are only running individual applications. Only in cases 3 and 6 is there a window manager being started. In those cases, we have had issues propagating the vglrun functionality to the commands run within the session (i.e. using "vglrun mate-session" or the like in FastX to use VirtualGL for the window manager and all programs running within it). This could just be a case of mixing 2D and 3D X servers and/or misusing the command, given that it is all running on the same server. The good news is, I gave the jpeg-compression method another shot and received better results (perhaps a good day for the server?). It runs very well, and with the addition of the -fps <num> option, I can stabilize the rendering so that it is more in sync with the X inputs (mice, keyboards, etc.). And always, thanks for the clarifications.

Best Regards,

    Jason

[Richard]

On Mon, 18 Mar 2019 22:54:37 -0500
DRC <d...@virtualgl.org> wrote:

> Cases 1, 2, 3:
>
> VGL_FORCEALPHA was required because of the amdgpu drivers, as previously
> noted.

I thought I should mention that I have uncovered another workaround for amdgpu and mesa which has been working for me as effectively as the VGL_FORCEALPHA method. I used the mesa DRIconf program to set the option: "Create all visuals with a depth buffer" and clear the option "Allow exposure of visuals and fbconfigs with RGB10A2 formats" because if that is set too then the fix doesn't work. Note that this is applied to the Mesa configuration and not to VGL.
--
Richard <richard....@ntlworld.com>

[DRC]

Thanks for the update. I really need to get access to an
amdgpu-compatible card sooner rather than later, since the only AMD GPU
I have requires the old fglrx drivers. If some benevolent soul reading
this would be interested in helping out this project, a donation of such
a GPU would help ensure VirtualGL's platform neutrality.

DRC