I have a question regarding viewing openGL graphics from one of CUDA’s demo program on a remote machine (like fluidsGL). I can run fluidsGL locally, but whenever I try to run it on a remote machine using X-window or VNC, I got the following error:
freeglut (./simpleGL): Unable to create direct context rendering for window ‘Cuda GL interop’
This may hurt performance.
ERROR: Support for necessary OpenGL extensions missing.
Press ENTER to exit…
My environment is Fedora Core 6; most of the CUDA demos/tests work fine.
Does anyone know how to solve this problem? Many thanks!!!
What do you mean by “X-window or VNC” ? These are two different concepts for running an application on a remote machine.
“X-window”: you ssh -X into the machine and start the app. All OpenGL stuff then gets forwarded to your local machine and OpenGL renders locally. That means you need to have the GPU resources locally. Just the CPU is used on the remote machine.
“VNC”: the VNC server can be run in several modes. The most common one is that the remote machine does a screenshot of the changed screen content and sends it to you. With this setting, it uses all resources on the remote machine. No need to have any OpenGL locally. This is what you want for the CUDA demos.
Thanks for your quick reply. My remote machine has the GPU (NVIDIA 8800) , but locally I use a laptop. I would like to run CUDA demos on the remote machine using its resource, but viewing the results on my laptop. I tried ssh -X into the remote but get the error message; I also tried VNC but it doesn’t work either. In VNC I got the following message:
freeglut (./fluidsGL): OpenGLX extension not supported by display ‘:1.0’
When you run graphics applications remotely, the X server rendering the applications is your local X server. I.e., it is YOUR graphics card the one that renders the GL scene, not the remote graphics card. Moreover, if the OpenGL application cannot access to the hardware directly (e.g., when running remotely) you get messages like “Unable to create direct context rendering”. On the other hand, as CUDA needs no X server, you can run CUDA applications remotely on the remote graphics card. That’s why you can run CUDA applications on the remote GPU but your OpenGL applications are failing to allocate a valid context.
Anyway, using VNC you should not be experiencing any problems. VNC runs all the graphics stuff remotely and sends you the resulting image. How is your VNC server configured?
That is exactly the problem. This connection does not use vnc. You are routing all OpenGL calls to display 1, which is a virtual display on the remote machine (which produces this message) opened by the ssh server. On your local machine the ssh client then forwards it to your local display. If your local display does not have the capabilities, it doesn’t work.
I don’t know how to tunnel the vnc communication through ssh. Are your running a port forwarder for the vnc port 5900 ? Or is there a misunderstanding as the above error you sent has nothing to do with vnc actually.
Do you need to tunnel it ? You could protect the vnc access with a password.
so what were the steps to get vnc or NX for that matter to render graphics remotely?
I have a machine that I want to turn into a dedicated Cuda node without anything attached to it (KVM, etc). I just want to access it via VNC or NX, but have all GL stuff done remotely.
I was lazy when setting this up - I am running OpenSuSE 10.2 - and there you just start Yast and enable the VNC (remote desktop administration) feature. Then there is the krdc client program to connect. It has the nice feature that you can zoom the remote desktop window, so you can put miniature remote desktops of you entire cluster and watch them together… :)
If you need to do it the hard way: make sure the remote X server loads the vnc module and the screen section has an option that lists the vnc password file. Create a password and restart the remote X.
Kewl thanks. I did just that, but still noticed performance a bit off…but ahha topic for another day! :o) In usual HPC designs I could give a rats a** how fast the GL performance is, but…