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. On 3/18/19 2:47 PM, Jason wrote: > > 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: > > > 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 [email protected] > <mailto:[email protected]>. > 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>. > 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/26cc51ec-dccd-6d77-0680-cecf37ee00e5%40virtualgl.org. For more options, visit https://groups.google.com/d/optout.
