The version of TurboVNC is TurboVNC Server v2.2.90 (build 20211222) I had however tried version 3 and had encountered the same issues.
Hmm. So far none of the suggested steps helped. Running vglrun glxspheres64, glxgears, etc results in a blank output window. I'm currently trying to run vglrun +tr glxinfo to see if it gives any useful output On Wednesday, April 27, 2022 at 6:34:26 PM UTC-4 DRC wrote: > Your message ended up in my spam folder for some reason, and I was out of > the office last week anyhow. Unfortunately I've never encountered those > symptoms, so I have no good ideas. The only symptoms I've observed that > are even remotely similar are due to nVidia's HardDPMS feature, which > causes 3D applications to run at 1 frame/second with VirtualGL if the > screen saver is active on the 3D X server. (Add > > Option "HardDPMS" "false" > > under the "Device" or "Screen" section in xorg.conf to work around that > issue.) > > Other shots in the dark: > > - Double check that 'vglrun -d :0 glxinfo' reports a direct OpenGL > context. "Back in the day" (15 years ago), I seem to recall that, on some > systems, insufficient 3D X server permissions resulted in an indirect > OpenGL context rather than an error. I can't imagine why that would cause > a 25-minute delay, but it would almost certainly cause a delay. > > - Try removing ~/.Xauthority and restarting the system, in case there is > some cruft in that file that is causing problems. > > - Try running 'vglrun /opt/VirtualGL/bin/glxspheres64' instead of 'vglrun > glxgears' and observing whether the behavior is different. That may > provide a clue. > > - Try running 'vglrun /opt/VirtualGL/bin/glxspheres64' and then 'vglrun > -sp /opt/VirtualGL/bin/glxspheres64' and observing whether the behavior is > different. That may also provide a clue. > > - On the off-hand chance that this is a TurboVNC problem, which version of > TurboVNC are you using on the host and the client? Can you provide more > details about your network connection? Try requesting a screen refresh > from the TurboVNC Server (using Ctrl-Alt-Shift-R or the toolbar button.) > - Try setting VGL_PROBEGLX=0 in the environment prior to invoking vglrun, > on the off-hand chance that VirtualGL's 2D X server GLX probing (which is > unnecessary in a TurboVNC session) is causing issues. (TurboVNC 3.0 will > set that environment variable by default.) > > DRC > On 4/27/22 4:17 PM, Ryan Salomon wrote: > > bump! Anyone have at least an ideal direction to look in for more > information? > > On Thursday, April 21, 2022 at 2:22:10 PM UTC-4 Ryan Salomon wrote: > >> Hello! I have a Linux GPU server upon which I'm testing logging into via >> a TurboVNC session and running 3D apps via VirtualGL, which I've >> configured. >> >> I've tested vglrun -d :0 glxinfo and vglrun -d :0 glxgears , and both run >> perfectly fine as the root user, but run fine as me but with an insaaane 25 >> minute delay before they output anything. >> >> When running vglserver_config , I answered No to all of the questions >> because this host is sequestered sufficiently from the rest of our network >> (not to discuss security concerns, but to give background of the setup). >> >> Also for background of the setup, this is a CentOS 7.9 host, that is AD >> bound to our ActiveDirectory domain, and my user account that I tested >> with, as well as client accounts, are AD bound. >> I add this in case it is at all likely that the delay is from AD doing >> something silly. >> > -- 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/97c1def1-da01-44e0-ae32-0e6a1f459d87n%40googlegroups.com.
