*echo $LD_PRELOAD* returns empty, so something is up. But my main measure
of failure was that glxspheres64 (and glmark2) say that they render with
llvmpipe. Given that I am using the default xstartup.turboscript, am I
supposed to do something other than run *vncserver -wm ~/gnome -vgl* (I use
a script as I can't figure out how else to pass "dbus-launch gnome-session"
to -wm)?
Some more benchmarks. I'm quite new to OpenGL so these were just found
after some web searches. If there's obvious and useful ones I should do
please let me know.
gputest on host: 2600fps
gputest via VNC: 370fps
vglrun -sp gputest via VNC: 400fps
gfxbench (car chase) on host: 44fps
gfxbench (car chase) via VNC: won't run on llvmpipe
vglrun gfxbench (car chase) via VNC: 28fps
On Friday, 17 April 2020 21:37:08 UTC+1, DRC wrote:
>
> Bear in mind that passing -wm and -vgl to the vncserver script does
> nothing but set environment variables (TVNC_WM and TVNC_VGL) that are
> picked up by the default xstartup.turbovnc script, so make sure you are
> using the default xstartup.turbovnc script. It's easy to verify whether
> the window manager is using VirtualGL. Just open a terminal in the
> TurboVNC session and echo the value of $LD_PRELOAD. It should contain
> something like "libdlfaker.so:libvglfaker.so" if VirtualGL is active, and
> you should be able to run OpenGL applications in the session without
> vglrun, and those applications should show that they are using the Intel
> OpenGL renderer.
>
> As far as the performance, you haven't mentioned any other benchmarks you
> have tested, other than glmark2. I've explained why that benchmark may be
> demonstrating lackluster performance. If you have other data points, then
> please share them.
> On 4/17/20 2:34 PM, Shak wrote:
>
> I ran the commands you suggested (I went with -p 1m) and am still seeing a
> big difference. I just find it strange to see it clearly working with
> glxspheres64, but not much else.
>
> $ *glxspheres64 -p 1000000*
> Polygons in scene: 999424 (61 spheres * 16384 polys/spheres)
> GLX FB config ID of window: 0xfe (8/8/8/0)
> Visual ID of window: 0x2bf
> Context is Direct
> OpenGL Renderer: llvmpipe (LLVM 9.0.1, 256 bits)
> 3.292760 frames/sec - 2.370366 Mpixels/sec
> 3.317006 frames/sec - 2.387820 Mpixels/sec
> $ *vglrun -sp glxspheres64 -p 1000000*
> Polygons in scene: 999424 (61 spheres * 16384 polys/spheres)
> GLX FB config ID of window: 0x6b (8/8/8/0)
> Visual ID of window: 0x288
> Context is Direct
> OpenGL Renderer: Mesa DRI Intel(R) HD Graphics P4600/P4700 (HSW GT2)
> 62.859812 frames/sec - 45.251019 Mpixels/sec
> 59.975806 frames/sec - 43.174903 Mpixels/sec
>
> BTW, GNOME is now working (where I ran the above). I'm trying to run the
> whole desktop in VGL, but *vncserver -wm ~/gnome -vgl* doesn't seem to do
> anything differently than it does without -vgl. Again, my gnome script is:
>
> #!/bin/sh
> dbus-launch gnome-session
>
> That said, the desktop isn't broken now so that's an improvement on KDE.
> But how can I run the whole of GNOME under VGL?
>
> I think if I can get the desktop running in VGL and still not see the
> performance in apps that I do locally (apart from in glxspheres!) I will
> take that as the most I can do with my system over VNC (unless you find it
> helpful for me to debug further).
>
> Thanks,
>
>
> On Friday, 17 April 2020 19:04:48 UTC+1, DRC wrote:
>>
>> 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
>>> exec vglrun +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
>>>
>>> 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
>>>
>>>
>>> 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].
>>> 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].
>> 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] <javascript:>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/virtualgl-users/16cd2e22-2380-447c-b3ca-a494a17e324f%40googlegroups.com
>
> <https://groups.google.com/d/msgid/virtualgl-users/16cd2e22-2380-447c-b3ca-a494a17e324f%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/8a38e956-d7fa-4dbc-8063-350c22c97a88%40googlegroups.com.
