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/username/.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/f422c5c2-b81b-401d-aecb-0e6ee066b548n%40googlegroups.com.
