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/08592e95-bd05-5a7d-688c-4dd7691d7892%40virtualgl.org.
