On 4/17/20 10:36 AM, Shak wrote:
> I ran glmark on the host display normally and then with software
> rendering. I've attached the results at the end of this message. I've
> attached this for completion rather than to contradict your hunch, but
> they do tie up with the numbers I see via VGL so I don't think this is
> a CPU/VNC issue.
Hmmm... Well, you definitely are seeing a much greater speedup with
glmark2 absent VirtualGL, so I can only guess that the benchmark is
fine-grained enough that it's being affected by VGL's per-frame
overhead. A more realistic way to compare the two drivers would be
using '[vglrun -sp] /opt/VirtualGL/bin/glxspheres -p {n}', where {n} is
a fairly high number of polygons (at least 100,000.)
> I've tried repeating my experiments using gnome, in case the issue is
> with KDE. However I get the following when trying to run vglrun:
>
> $ *vglrun glxspheres64*
> /usr/bin/vglrun: line 191: hostname: command not found
> [VGL] NOTICE: Automatically setting VGL_CLIENT environment variable to
> [VGL] 10.10.7.1, the IP address of your SSH client.
> Polygons in scene: 62464 (61 spheres * 1024 polys/spheres)
> libGL error: failed to authenticate magic 1
> libGL error: failed to load driver: i965
> GLX FB config ID of window: 0x6b (8/8/8/0)
> Visual ID of window: 0x21
> Context is Direct
> OpenGL Renderer: llvmpipe (LLVM 9.0.1, 256 bits)
> 17.228616 frames/sec - 17.859872 Mpixels/sec
> 16.580449 frames/sec - 17.187957 Mpixels/sec
You need to install whatever package provides /usr/bin/hostname for your
Linux distribution. That will eliminate the vglrun error, although it's
probably unrelated to this problem. (Because of the error, vglrun is
falsely detecting an X11-forward SSH environment and setting VGL_CLIENT,
which would normally be used for the VGL Transport. However, since
VirtualGL auto-detects an X11 proxy environment and enables the X11
Transport, the value of VGL_CLIENT should be ignored in this case.)
I honestly have no clue how to proceed. I haven't observed these
problems in any of the distributions I officially support, and I have no
way to test Arch.
> I'm not sure what to make of these. I am using *vncserver -wm
> ~/gnome*, where gnome is the following script.
>
> |
> #!/bin/sh
> dbus-launch gnome-session
> |
>
> I feel that I am close but still a way off.
>
> FWIW I have previously tried using nomachine which is able to give me
> the perceived GL acceleration by "mirroring" my host display, but that
> just feels like the wrong way to achieve this (not least because it
> requires a monitor attached to use).
>
> Thanks,
>
> ==== RENDER TESTS ====
>
> $ *glmark2*
> =======================================================
> glmark2 2017.07
> =======================================================
> OpenGL Information
> GL_VENDOR: Intel Open Source Technology Center
> GL_RENDERER: Mesa DRI Intel(R) HD Graphics P4600/P4700 (HSW GT2)
> GL_VERSION: 3.0 Mesa 20.0.4
> =======================================================
> [build] use-vbo=false: FPS: 2493 FrameTime: 0.401 ms
> =======================================================
> glmark2 Score: 2493
> =======================================================
>
> $ *LIBGL_ALWAYS_SOFTWARE=1 glmark2*
> ** GLX does not support GLX_EXT_swap_control or GLX_MESA_swap_control!
> ** Failed to set swap interval. Results may be bounded above by
> refresh rate.
> =======================================================
> glmark2 2017.07
> =======================================================
> OpenGL Information
> GL_VENDOR: VMware, Inc.
> GL_RENDERER: llvmpipe (LLVM 9.0.1, 256 bits)
> GL_VERSION: 3.1 Mesa 20.0.4
> =======================================================
> ** GLX does not support GLX_EXT_swap_control or GLX_MESA_swap_control!
> ** Failed to set swap interval. Results may be bounded above by
> refresh rate.
> [build] use-vbo=false: FPS: 420 FrameTime: 2.381 ms
> =======================================================
> glmark2 Score: 420
> =======================================================
>
>
> On Thursday, 16 April 2020 23:21:59 UTC+1, DRC wrote:
>
> On 4/16/20 3:19 PM, Shak wrote:
>> Thank you for the quick tips. I have posted some results at the
>> end of this post, but they seem inconsistent. glxspheres64 shows
>> the correct renderer respectively and the performance shows the
>> 6x results I was expecting. However I do not see the same gains
>> in glmark2, even though it also reports the correct renderer in
>> each case. Again, I see a glmark of 2000+ when running it in
>> display :0.
> I don't know much about glmark2, but as with any benchmark,
> Amdahl's Law applies. That means that the total speedup from any
> enhancement (such as a GPU) is limited by the percentage of clock
> time during which that enhancement is used. Not all OpenGL
> workloads are GPU-bound in terms of performance. If the geometry
> and window size are both really small, then the performance could
> very well be CPU-bound. That's why, for instance, GLXgears is a
> poor OpenGL benchmark. Real-world applications these days assume
> the presence of a GPU, so they're going to have no qualms about
> trying to render geometries with hundreds of thousands or even
> millions of polygons. When you try to do that with software
> OpenGL, you'll see a big difference vs. GPU acceleration-- a
> difference that won't necessarily show up with tiny geometries.
>
> You can confirm that that's the case by running glmark2 on your
> local display without VirtualGL and forcing the use of the swrast
> driver. I suspect that the difference between swrast and i965
> won't be very great in that scenario, either. (I should also
> mention that Intel GPUs aren't the fastest in the world, so you're
> never going to see as much of a speedup-- nor as large of a
> speedup in as many cases-- as you would see with AMD or nVidia.)
>
> The other thing is, if the benchmark is attempting to measure
> unrealistic frame rates-- like hundreds or thousands of frames per
> second-- then there is a small amount of per-frame overhead
> introduced by VirtualGL that may be limiting that frame rate. But
> the reality is that human vision can't usually detect more than 60
> fps anyhow, so the difference between, say, 200 fps and 400 fps is
> not going to matter to an application user. At more realistic
> frame rates, VGL's overhead won't be noticeable.
>
> Performance measurement in a VirtualGL environment is more
> complicated than performance measurement in a local display
> environment, which is why there's a whole section of the VirtualGL
> User's Guide dedicated to it. Basically, since VGL introduces a
> small amount of per-frame overhead but no per-vertex overhead, at
> realistic frame rates and with modern server and client hardware,
> it will not appear any slower than a local display. However, some
> synthetic benchmarks may record slower performance due to the
> aforementioned overhead.
>
>
>> In the meantime I have been trying to get the DE as a whole to
>> run under acceleration. I record my findings here as a possible
>> clue to my VGL issues above. In my .vnc/xstartup.turbovnc I use
>> the following command:
>>
>> |
>> #normal start - works with llvmpipe and vglrun
>> #exec startplasma-x11
>>
>> #VGL start
>> execvglrun +wm startplasma-x11
>> |
>>
>> And I also start tvnc with:
>>
>> |
>> $vncserver -3dwm
>> |
>>
>> I'm not sure if vglrun, +wm or -3dwm are redundant or working
>> against each other, but I've also tried various combinations to
>> no avail.
>
> Just use the default xstartup.turbovnc script ('rm
> ~/.vnc/xstartup.turbovnc' and re-run /opt/TurboVNC/bin/vncserver
> to create it) and start TurboVNC with '-wm startplasma-x11 -vgl'.
>
> * -3dwm is deprecated. Use -vgl instead. -3dwm/-vgl (or setting
> '$useVGL = 1;' in /etc/turbovncserver.conf or
> ~/.vnc/turbovncserver.conf) simply instructs xstartup.turbovnc to
> run the window manager startup script using 'vglrun +wm'.
>
> * Passing -wm to /opt/TurboVNC/bin/vncserver (or setting '$wm =
> {script};' in turbovncserver.conf) instructs xstartup.turbovnc to
> execute the specified window manager startup script rather than
> /etc/X11/xinit/xinitrc.
>
> * +wm is a feature of VirtualGL, not TurboVNC. Normally, if
> VirtualGL detects that an OpenGL application is not monitoring
> StructureNotify events, VGL will monitor those events on behalf of
> the application (which allows VGL to be notified when the window
> changes size, thus allowing VGL to change the size of the
> corresponding Pbuffer.) This is, however, unnecessary with window
> managers and interferes with some of them (compiz, specifically),
> so +wm disables that behavior in VirtualGL. It's also a
> placeholder in case future issues are discovered that are specific
> to compositing window managers (+wm could easily be extended to
> handle those issues as well.)
>
>
>> Interestingly I had to update the vglrun script to have the full
>> paths to /usr/lib/libdlfaker.so and the others otherwise I see
>> the following in the TVNC logs:
>>
>> ERROR: ld.so: object 'libdlfaker.so' from LD_PRELOAD cannot be
>> preloaded (cannot open shared object file): ignored.
>> ERROR: ld.so: object 'libvglfaker.so' from LD_PRELOAD cannot be
>> preloaded (cannot open shared object file): ignored.
>>
>> That said, my desktop is still broken even when these errors
>> disappear.
>>
>> Could my various issues be to do with KDE?
>
> The LD_PRELOAD issues can be fixed as described here:
>
> https://cdn.rawgit.com/VirtualGL/virtualgl/2.6.3/doc/index.html#hd0012
> <https://cdn.rawgit.com/VirtualGL/virtualgl/2.6.3/doc/index.html#hd0012>
>
> All of that aside, I have not personally tested the bleeding-edge
> KDE Plasma release, which is what Arch presumably ships, so I have
> no idea whether it works with VirtualGL or TurboVNC. The window
> managers I have tested are listed here:
>
> https://turbovnc.org/Documentation/Compatibility22
> <https://turbovnc.org/Documentation/Compatibility22>
>
>
>> On Thursday, 16 April 2020 20:02:13 UTC+1, DRC wrote:
>>
>> You can't really determine which OpenGL renderer is in use by
>> just looking at dlopen() calls. In a TurboVNC environment,
>> swrast will be used for any GLX/OpenGL commands sent to the
>> TurboVNC X server (the "2D X server"), and VirtualGL does
>> send a couple of GLX/OpenGL commands to the 2D X server to
>> probe its capabilities. That's probably why swrast is being
>> loaded, but if everything is working properly, the OpenGL
>> renderer string should still report that the Intel driver is
>> in use for actual rendering. Compare the output of
>> /opt/VirtualGL/bin/glxinfo on the local display with 'vglrun
>> /opt/VirtualGL/bin/glxinfo' in TurboVNC, or just run
>> /opt/VirtualGL/bin/glxspheres64 (using vglrun in TurboVNC),
>> which reports the OpenGL renderer string as well.
>>
>>
>> On 4/16/20 10:34 AM, Shak wrote:
>>> I am trying to set up VirtualGL + TurboVNC on Arch with the
>>> Plasma KDE desktop. The host is itself a VM using an passed
>>> through Intel P4600 IGD. I believe that the passthrough
>>> itself is successful as I see GL performance when running a
>>> desktop on display :0.
>>>
>>> I am using glmark2 to check what is happening. As a measure,
>>> I get a score of around 2000 on the host, and 300 when using
>>> llvmpipe and similar when using vglrun. vglrun glinfo is
>>> reporting that its using the Intel Mesa driver (vs
>>> llvmpipe), so the set up at least looks okay, but it seems
>>> that vglrun is still using software rendering.
>>>
>>> Passing +v +tr to vglrun in both cases shows me the traces
>>> at the end of this post, which aligns with what I am seeing
>>> (highlighted yellow). I've also highlighted green some other
>>> lines which confuse me.
>>>
>>> I read this
>>> <https://sourceforge.net/p/virtualgl/mailman/message/31296895/>
>>> that indicated that Mesa isn't supported and in the docs
>>> that Arch's VirtiualGL package might be broken. I do not
>>> know if these apply here (or are still valid).
>>>
>>> Also when trying to accelerate the whole DE using exec
>>> vglrun plasmastart-x11 in my xstartup.turbovnc, I seem to
>>> get a broken desktop. I am not sure if this is related to
>>> the above but have mentioned it at as another data point (if
>>> its unrelated then tips to fix would be appreciated!).
>>>
>>> Thanks,
>>>
>>> vglrun traces:
>>>
>>> ==== on host ====
>>>
>>> [VGL] NOTICE: Added /usr/lib to LD_LIBRARY_PATH
>>> [VGL] Shared memory segment ID for vglconfig: 131106
>>> [VGL] VirtualGL v2.6.3 64-bit (Build 20200214)
>>> [VGL 0x92aa5780] XOpenDisplay (name=NULL
>>> dpy=0x557453a35740(:0) ) 0.335932 ms
>>> [VGL] dlopen (filename=libGL.so flag=4098[VGL] NOTICE:
>>> Replacing dlopen("libGL.so") with dlopen("libvglfaker.so")
>>> retval=0x7f2c935804f0)
>>> [VGL] Opening connection to 3D X server :0
>>> [VGL] dlopen (filename=libGLX_mesa.so.0 flag=1
>>> retval=0x557453a53170)
>>> [VGL] dlopen (filename=libGLX_mesa.so.0 flag=258
>>> retval=0x557453a53170)
>>> [VGL] dlopen (filename=/usr/lib/dri/tls/i965_dri.so flag=258
>>> retval=0x00000000)
>>> [VGL] dlopen (filename=/usr/lib/dri/i965_dri.so flag=258
>>> retval=0x557453a69340)
>>> [VGL 0x92aa5780] glXGetProcAddressARB ((char
>>> *)procName=glXSwapIntervalEXT [INTERPOSED]) 0.005960 ms
>>> [VGL 0x92aa5780] glXChooseFBConfig (dpy=0x557453a35740(:0)
>>> screen=0 attrib_list=[0x8012=0x0001 0x8010=0x0001
>>> 0x8011=0x0001 0x0022=0x8002 0x0008=0x0001 0x0009=0x0001
>>> 0x000a=0x0001 0x000b=0x0001 0x000c=0x0001 0x000d=0x0000
>>> 0x0002=0x0001 0x0005=0x0001 ] glxattribs=[0x8010=0x0001
>>> 0x000c=0x0001 0x000d=0x0000 0x0002=0x0001 0x0005=0x0001
>>> 0x0008=0x0001 0x0009=0x0001 0x000a=0x0001 0x000b=0x0001
>>> 0x8011=0x0001 0x0022=0x8002 ] [VGL] dlopen
>>> (filename=libGLX_mesa.so.0 flag=258 retval=0x557453a53170)
>>> [VGL] dlopen (filename=/usr/lib/dri/tls/i965_dri.so flag=258
>>> retval=0x00000000)
>>> [VGL] dlopen (filename=/usr/lib/dri/i965_dri.so flag=258
>>> retval=0x557453a69340)
>>> configs[0]=0x557453b9a040(0x67)
>>> configs[1]=0x557453b9a7c0(0x6f)
>>> configs[2]=0x557453b9af40(0x77)
>>> configs[3]=0x557453b9b300(0x7b)
>>> configs[4]=0x557453b9bc60(0x85)
>>> configs[5]=0x557453b9c3e0(0x8d)
>>> configs[6]=0x557453b9bd50(0x86)
>>> configs[7]=0x557453b9c4d0(0x8e)
>>> configs[8]=0x557453b9b030(0x78)
>>> configs[9]=0x557453b9b3f0(0x7c)
>>> configs[10]=0x557453b9fa40(0xc7)
>>> configs[11]=0x557453b9fe00(0xcb)
>>> configs[12]=0x557453b9ffe0(0xcd)
>>> configs[13]=0x557453ba00d0(0xce) *nelements=14 ) 6.473064 ms
>>> [VGL 0x92aa5780] glXGetFBConfigAttrib
>>> (dpy=0x557453a35740(:0) config=0x557453b9a040(0x67)
>>> attribute=2(0x2) *value=32(0x20) ) 0.008106 ms
>>>
>>>
>>> ==== on tvnc ====
>>>
>>> [VGL] NOTICE: Added /usr/lib to LD_LIBRARY_PATH
>>> [VGL] Shared memory segment ID for vglconfig: 131076
>>> [VGL] VirtualGL v2.6.3 64-bit (Build 20200214)
>>> [VGL 0x9f624780] XOpenDisplay (name=NULL
>>> dpy=0x555b28562740(:1) ) 2.894163 ms
>>> [VGL] dlopen (filename=libGL.so flag=4098[VGL] NOTICE:
>>> Replacing dlopen("libGL.so") with dlopen("libvglfaker.so")
>>> retval=0x7f90a00ff4f0)
>>> [VGL] Opening connection to 3D X server :0
>>> [VGL] dlopen (filename=libGLX_mesa.so.0 flag=1
>>> retval=0x555b28583a20)
>>> [VGL] dlopen (filename=libGLX_mesa.so.0 flag=258
>>> retval=0x555b28583a20)
>>> [VGL] dlopen (filename=/usr/lib/dri/tls/i965_dri.so flag=258
>>> retval=0x00000000)
>>> [VGL] dlopen (filename=/usr/lib/dri/i965_dri.so flag=258
>>> retval=0x555b285964a0)
>>> [VGL 0x9f624780] glXGetProcAddressARB ((char
>>> *)procName=glXSwapIntervalEXT [INTERPOSED]) 0.045061 ms
>>> [VGL 0x9f624780] glXChooseFBConfig (dpy=0x555b28562740(:1)
>>> screen=0 attrib_list=[0x8012=0x0001 0x8010=0x0001
>>> 0x8011=0x0001 0x0022=0x8002 0x0008=0x0001 0x0009=0x0001
>>> 0x000a=0x0001 0x000b=0x0001 0x000c=0x0001 0x000d=0x0000
>>> 0x0002=0x0001 0x0005=0x0001 ] glxattribs=[0x8010=0x0001
>>> 0x000c=0x0001 0x000d=0x0000 0x0002=0x0001 0x0005=0x0001
>>> 0x0008=0x0001 0x0009=0x0001 0x000a=0x0001 0x000b=0x0001
>>> 0x8011=0x0001 0x0022=0x8002 ] [VGL] dlopen
>>> (filename=libGLX_mesa.so.0 flag=258 retval=0x555b28583a20)
>>> [VGL] dlopen (filename=/usr/lib/dri/tls/swrast_dri.so
>>> flag=258 retval=0x00000000)
>>> [VGL] dlopen (filename=/usr/lib/dri/swrast_dri.so flag=258
>>> retval=0x555b28705370)
>>> configs[0]=0x555b286c7170(0x67)
>>> configs[1]=0x555b286c78f0(0x6f)
>>> configs[2]=0x555b286c8070(0x77)
>>> configs[3]=0x555b286c8430(0x7b)
>>> configs[4]=0x555b286c8d90(0x85)
>>> configs[5]=0x555b286c9510(0x8d)
>>> configs[6]=0x555b286c8e80(0x86)
>>> configs[7]=0x555b286c9600(0x8e)
>>> configs[8]=0x555b286c8160(0x78)
>>> configs[9]=0x555b286c8520(0x7c)
>>> configs[10]=0x555b286ccb70(0xc7)
>>> configs[11]=0x555b286ccf30(0xcb)
>>> configs[12]=0x555b286cd110(0xcd)
>>> configs[13]=0x555b286cd200(0xce) *nelements=14 ) 44.402122 ms
>>> [VGL 0x9f624780] glXGetFBConfigAttrib
>>> (dpy=0x555b28562740(:1) config=0x555b286c7170(0x67)
>>> attribute=2(0x2) *value=32(0x20) ) 0.003815 ms
>>> --
>>> 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/ada84490-cfbe-41c7-8919-c0f00241ba82%40googlegroups.com
>>>
>>> <https://groups.google.com/d/msgid/virtualgl-users/ada84490-cfbe-41c7-8919-c0f00241ba82%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] <javascript:>.
>> To view this discussion on the web visit
>>
>> https://groups.google.com/d/msgid/virtualgl-users/f462fa23-9363-43f1-9001-ced5eae3f925%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/virtualgl-users/f462fa23-9363-43f1-9001-ced5eae3f925%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]
> <mailto:[email protected]>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/virtualgl-users/bd7beb3a-2cfe-4f2b-8440-4ddd2dd812a8%40googlegroups.com
> <https://groups.google.com/d/msgid/virtualgl-users/bd7beb3a-2cfe-4f2b-8440-4ddd2dd812a8%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/caae173b-7e2a-b246-b65e-3175c9c4b7b9%40virtualgl.org.
