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:
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
On 4/28/22 2:54 PM, Ryan Salomon wrote:
Direct rendering says Yes.
I ran vglrun +tr glxinfo, here's a snippet of the result,
with a large gap that I had added manually by pressing
enter when there was the extremely long delay.
This might not help but it was my first thought in terms of
possibly getting more visibility
vglrun +tr glxinfo
[VGL 0x88d75800] XOpenDisplay (name=NULL
dpy=0x00db5b00(:1.0) ) 2.102852 ms
name of display: :1.0
[VGL 0x88d75800] glXChooseVisual (dpy=0x00db5b00(:1.0)
screen=0 attrib_list=[0x0004 0x0008=0x0001 0x0009=0x0001
0x000a=0x0001 0x000c=0x0001 0x000d=0x0001 0x000e=0x0001
0x000f=0x0001 0x0010=0x0001 0x0011=0x0001 0x0005 ]
glxattribs=[0x000c=0x0001 0x000d=0x0001 0x000e=0x0001
0x000f=0x0001 0x0010=0x0001 0x0011=0x0001 0x0005=0x0001
0x0008=0x0001 0x0009=0x0001 0x000a=0x0001 0x8011=0x0001
0x8010=0x0006 ] [VGL] dlopen (filename=libGLX_nvidia.so.0
flag=1 retval=0x00dd2f30)
[VGL] dlopen (filename=libX11-xcb.so.1 flag=1
retval=0x00e392b0)
[VGL] dlopen (filename=libxcb.so.1 flag=1
retval=0x7fb888d78000)
[VGL] dlopen (filename=libxcb-glx.so.0 flag=1
retval=0x00e39290)
[VGL] dlopen (filename=libGLX_mesa.so.0 flag=1
retval=0x00e4ddc0)
[VGL] dlopen (filename=libGLX_mesa.so.0 flag=258
retval=0x00e4ddc0)
[VGL] dlopen (filename=/usr/lib64/dri/tls/swrast_dri.so
flag=258 retval=0x00000000)
[VGL] dlopen (filename=/usr/lib64/dri/swrast_dri.so
flag=258 retval=0x00e973b0)
vis=0x00e68f50(0x21) config=0x00e3bdd0(0x79) ) 117.562056 ms
[VGL 0x88d75800] glXChooseFBConfig (dpy=0x00db5b00(:1.0)
screen=0 attrib_list=[0x8011=0x0001 0x0008=0x0001
0x0009=0x0001 0x000a=0x0001 0x0005=0x0000 ]
glxattribs=[0x0005=0x0000 0x0008=0x0001 0x0009=0x0001
0x000a=0x0001 0x8011=0x0001 ] configs[0]=0x00e9dfc0(0x7f)
configs[1]=0x00e9c520(0xab) configs[2]=0x00e66930(0x7b)
configs[3]=0x00e65cc0(0xa7) configs[4]=0x00e5a340(0x83)
configs[5]=0x00de8d90(0xaf) configs[6]=0x00ed1d60(0x89)
configs[7]=0x00ea34c0(0xb5) configs[8]=0x00e37130(0x91)
configs[9]=0x00dd4830(0xbd) configs[10]=0x00e9ef00(0x8b)
configs[11]=0x00ea0ac0(0xb7) configs[12]=0x00e9e1a0(0x93)
configs[13]=0x00e9c700(0xbf) configs[14]=0x00e9ae00(0x97)
configs[15]=0x00e65ea0(0xc3) configs[16]=0x00e65270(0x9b)
configs[17]=0x00e64640(0xc7) configs[18]=0x00e639e0(0x9f)
configs[19]=0x00e62f50(0xcb) configs[20]=0x00e62360(0xa3)
configs[21]=0x00e60a00(0xcf) configs[22]=0x00e5fd00(0x80)
configs[23]=0x00e5f110(0xac) configs[24]=0x00e5e4a0(0x7c)
configs[25]=0x00e5d840(0xa8) configs[26]=0x00e5cbe0(0x84)
configs[27]=0x00e5bd80(0xb0) configs[28]=0x00e5b170(0x8a)
configs[29]=0x00e5a520(0xb6) configs[30]=0x00e59820(0x92)
configs[31]=0x00e39960(0xbe) configs[32]=0x00ea36b0(0x8c)
configs[33]=0x00ea29a0(0xb8) configs[34]=0x00ea1d10(0x94)
configs[35]=0x00e38060(0xc0) configs[36]=0x00e36760(0x98)
configs[37]=0x00de9cb0(0xc4) configs[38]=0x00de8f70(0x9c)
configs[39]=0x00e9ec90(0xc8) configs[40]=0x00e9d0d0(0xa0)
configs[41]=0x00e9b810(0xcc) configs[42]=0x00e614e0(0xa4)
configs[43]=0x00e9bac0(0xd0) *nelements=44 ) 0.370026 ms
[VGL 0x88d75800] glXGetProcAddressARB ((char
*)procName=glXCreateContextAttribsARB [INTERPOSED]) 0.004768 ms
[VGL 0x88d75800] glXCreateContextAttribsARB
(dpy=0x00db5b00(:1.0) config=0x00e9dfc0(0x7f)
share_context=0x00000000 direct=1 attribs=[0x2091=0x0004
0x2092=0x0006 0x9126=0x0001 ] [VGL] dlopen (filename=NULL
flag=1 retval=0x7fb888d9b150)
[VGL] dlopen (filename=NULL flag=1 retval=0x7fb888d9b150)
[VGL] dlopen (filename=libdbus-1.so.3 flag=1 retval=0x00f780f0)
[VGL] dlopen (filename=libdrm.so.2 flag=1 retval=0x00e57b70)
[VGL] dlopen (filename=liballocator.so.0 flag=1
retval=0x00000000)
ctx=0x00e80b48 ) 77.847004 ms
[VGL 0x88d75800] glXIsDirect (dpy=0x00db5b00(:1.0)
ctx=0x00e80b48 direct=1 ) 0.001192 ms
[VGL 0x88d75800] glXGetVisualFromFBConfig
(dpy=0x00db5b00(:1.0) config=0x00e9dfc0(0x7f)
vis=0x0118e810(0x21) ) 0.023842 ms
[VGL 0x88d75800] XCreateWindow (dpy=0x00db5b00(:1.0)
parent=0x000003af x=0 y=0 width=100 height=100 depth=24
c_class=1 visual=0x00dc1e70(0x21) win=0x02000002 ) 0.020027 ms
[VGL 0x88d75800] glXMakeCurrent (dpy=0x00db5b00(:1.0)
drawable=0x02000002 ctx=0x00e80b48 [VGL] dlopen
(filename=liballocator.so.0 flag=1 retval=0x00000000)
config=0x00e9dfc0(0x7f) drawable=0x00600002 renderer=NVIDIA
A30/PCIe/SSE2 ) 1540881.658077 ms
[VGL 0x88d75800] glXGetProcAddressARB ((char
*)procName=glGetProgramivARB [passed through]) 0.017166 ms
[VGL 0x88d75800] glXGetProcAddressARB ((char
*)procName=glGetStringi [INTERPOSED]) 0.007868 ms
[VGL 0x88d75800] glXGetProcAddressARB ((char
*)procName=glGetConvolutionParameteriv [passed through])
0.009060 ms
display: :1 screen: 0
[VGL 0x88d75800] glXIsDirect (dpy=0x00db5b00(:1.0)
ctx=0x00e80b48 direct=1 ) 0.003099 ms
direct rendering: Yes
server glx vendor string: VirtualGL
server glx version string: 1.4
server glx extensions:
On Thursday, April 28, 2022 at 10:59:13 AM UTC-4 Ryan
Salomon wrote:
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/fbe4168f-480b-40f3-b061-6d193bdd09d3n%40googlegroups.com
<https://groups.google.com/d/msgid/virtualgl-users/fbe4168f-480b-40f3-b061-6d193bdd09d3n%40googlegroups.com?utm_medium=email&utm_source=footer>.
--
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/074bade4-49cb-4d2e-b198-0c6c14a1f919n%40googlegroups.com
<https://groups.google.com/d/msgid/virtualgl-users/074bade4-49cb-4d2e-b198-0c6c14a1f919n%40googlegroups.com?utm_medium=email&utm_source=footer>.
