i have install virtuql GL in 32 and 64bits.
it works good in 64 bit.
it was very slow in 32 Bits
any idea ?
thnks a lot
SLES 11 SP2 / NVIDIA TESLA M2075 / TURBO VNC
Most likely, you haven't installed the 32-bit libraries for the nVidia driver.
The first thing to check whenever you have performance issues with VirtualGL is whether the issue exists without VirtualGL as well, which of course indicates that it isn't a VirtualGL problem. I'm sure that if you run the 32-bit version of GLXspheres on the display to which your nVidia adapter is attached, it will run slow there as well, even though VirtualGL is not being used.
Please re-open this issue if the above does not address the problem.
Thanks for your reactivity...
Unfortunately, it is not so simple:
- 32bits part of Nvidia has been installed.
- glxspheres / glxspheres64 work in "direct" mode (glxspheres?? thought SSH - X because it is on a server and no monitor can be plugged on tesla)
- glxspheres remains slow compared glxsphere64 thought vnc/vglrun
My contact at SGI (my cluster manufacturer) thinks it 's due to SLES SP2. He has done same kind of installation on previous SLES version and it worked.
Could i provide any useful information to you ?
When you run the 32-bit version of GLXspheres on the root display and then using VirtualGL, what does it report as the renderer string? To put this another way, is the renderer different when it runs slow vs. when it runs fast?
In fact running on the root display is not possible because it is a tesla GPU :
a hardware without output connector.
I could provide you several output I've made with vglrun glxsphere (but because the case is closed, i can't) :
output of perf top during run
perf.32.txt (the nvidia is on top)
perf.64.txt (the nvidia driver does not commume much)(
output of strace -f
strace.32.txt the system call sched_yield is call very often strace.64.txt nothing special
output with vglrun +pr +v
trace.32.txt allmost not GL activitie !!
version.txt output of file /usr/lib*/libGL.so.295.59
We also performed test on other computer with :
- same OS (SLES 11SP2 with same updates)
- cpu intel E5430 instead of E5-2670
- Nvidia Quadro FX 3700 instead of TESLA M2075
it works !!!
Re-opened so you can post your logs.
Even though you're running on a Tesla, you can still do:
xauth merge /etc/opt/VirtualGL/vgl_xauth_key
and look at the renderer string that it outputs. It should be the same renderer string as when you run
Then you should run both the 32-bit and 64-bit versions of GLXspheres with 'vglrun +tr' and verify that approximately the same set of tracing messages appear in each. That indicates that VirtualGL is active and working.
If VirtualGL is active and working in both cases, and if the renderer string indicates that both cases are using the nVidia drivers, then I have no explanation. Other people are successfully using VirtualGL with Tesla cards.
Note that running glxspheres/glxspheres64 through SSH without vglrun is not a relevant test, as this causes the 3D rendering to be done by the client machine.
Are you still experiencing this problem?
Closed due to lack of response from user
sorry for delayed answer (on holidays).
We have perfomed same tests on the same server with Quadro FX 4000 to obtain same problem.
You never did answer my question below regarding what GLXspheres reports as the renderer string when running the 32-bit vs. the 64-bit version. Is it the same?
Finally the problem has been solved. It had nothing to do with VirtualGL but with the NVIDIA driver in 32bit mode.
The problem did also appear on a console connected on the NVIDIA card output.
We solved the problem with the BIOS settings :
Advanced->PCI Subsystem Settings->PCI 64bit Resources Handing:Above 4G Decoding ==> Disabled