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
It's interesting that the delay occurs in the body of glXMakeCurrent(). Can you ascertain whether the delay occurs in the backend::makeCurrent() method (which, when using the GLX back end, is just a wrapper for glXMakeContextCurrent())?
DRC
--
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/fbe4168f-480b-40f3-b061-6d193bdd09d3n%40googlegroups.com.
Seems like it may be an issue with nVidia's shader cache. Try deleting ~/.nv or setting _GL_SHADER_DISK_CACHE=0 in the environment.
DRC
Hmm, I'm not sure how to do that.
All I did was run vglrun +tr glxinfo
Ok, I tried running the same command but with strace at the start, and found something interesting during the start of the wait:
poll([{fd=4, events=POLLIN}], 1, -1) = 1 ([{fd=4, revents=POLLIN}])
recvmsg(4, {msg_name=NULL, msg_namelen=0, msg_iov=[{iov_base="\1\0023\0\0\0\0\0H\2@\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0", iov_len=4096}], msg_iovlen=1, msg_controllen=0, msg_flags=0}, 0) = 32
getpid() = 16364
getpid() = 16364
getpid() = 16364
getpid() = 16364
getuid() = 37869
geteuid() = 37869
getgid() = 37869
getegid() = 37869
getuid() = 37869
geteuid() = 37869
getgid() = 37869
getegid() = 37869
stat("/home/username/.nv/GLCache", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
mkdir("/home/username/.nv/", 0700) = -1 EEXIST (File exists)
mkdir("/home/username/.nv/GLCache", 0700) = -1 EEXIST (File exists)
mkdir("/home/username/.nv/GLCache/9f7e9a18c64449cd7a0049bdadc5d015/", 0700) = -1 EEXIST (File exists)
mkdir("/home/username/.nv/GLCache/9f7e9a18c64449cd7a0049bdadc5d015/cf07cf62221389dd/", 0700) = -1 EEXIST (File exists)
open("/home/rsalomon/.nv/GLCache/9f7e9a18c64449cd7a0049bdadc5d015/cf07cf62221389dd/c1b003dd27d07ca9.toc", O_RDWR|O_CLOEXEC) = 15
fcntl(15, F_SETLK, {l_type=F_WRLCK, l_whence=SEEK_CUR, l_start=0, l_len=1}) = -1 EIO (Input/output error)
close(15) = 0
getuid() = 37869
geteuid() = 37869
getgid() = 37869
getegid() = 37869
getuid() = 37869
geteuid() = 37869
getgid() = 37869
getegid() = 37869
stat("/home/username/.nv/GLCache", {st_mode=S_IFDIR|0700, st_size=4096, ...}) = 0
mkdir("/home/username/.nv/", 0700) = -1 EEXIST (File exists)
mkdir("/home/username/.nv/GLCache", 0700) = -1 EEXIST (File exists)
mkdir("/home/username/.nv/GLCache/9f7e9a18c64449cd7a0049bdadc5d015/", 0700) = -1 EEXIST (File exists)
mkdir("/home/username/.nv/GLCache/9f7e9a18c64449cd7a0049bdadc5d015/cf07cf62221389dd/", 0700) = -1 EEXIST (File exists)
open("/home/username/.nv/GLCache/9f7e9a18c64449cd7a0049bdadc5d015/cf07cf62221389dd/c1b003dd27d07caa.toc", O_RDWR|O_CLOEXEC) = 15
fcntl(15, F_SETLK, {l_type=F_WRLCK, l_whence=SEEK_CUR, l_start=0, l_len=1}) = -1 EIO (Input/output error)
and it repeats from there
home directory edited here since this is public
On Thursday, April 28, 2022 at 4:49:02 PM UTC-4 DRC wrote:
To view this discussion on the web visit https://groups.google.com/d/msgid/virtualgl-users/074bade4-49cb-4d2e-b198-0c6c14a1f919n%40googlegroups.com.
That really seems like a driver bug. Did
setting __GL_SHADER_DISK_CACHE=0
in the environment have any effect? (Note that I typoed below.
There should be two underscores preceding the environment
variable.)
DRC
To view this discussion on the web visit https://groups.google.com/d/msgid/virtualgl-users/4db8ba2c-4023-4a12-9bd7-c7b5140838fan%40googlegroups.com.
I'm not sure
why the shader cache is so slow on your particular machine, but if your home directory is NFS-mounted,
then that could be part of the problem. You can use the __GL_SHADER_DISK_CACHE_PATH
environment variable to relocate the cache to a local volume. I've never
seen this particular issue before, and nVidia would be better
equipped to explain what is happening. Note that there are
also xorg.conf settings for disabling the shader disk cache,
so perhaps enabling one of those settings on the 3D X server
would fix this system-wide.