Remote program uses local GPU?

I’m trying to let a machine with a limited Intel GPU run an advanced OpenGL program by running it remotely on a machine with a much better NVIDIA GPU.

However, when I run the program in an SSH shell provided by XWin32, the glGetString(GL_VENDOR) prints out Intel, as if it’s trying to use the local GPU even though I’m running it remotely.

Is there any way around this?

ssh is often configured to automatically forward X11 connections from the remote machine to the client terminal. Look up the command line parameters to disable this.

Or maybe you just need to set your “DISPLAY” environment variable to the address of the remote machine.

Yes, exactly.

export DISPLAY=:0

will force use of the GPU for screen 0 on the box you’re logged into.

This presumes you have write access to the X display on that box
(Remote X Apps mini-HOWTO: Telling the Server).

That worked to a point, but now I’m getting:

NVIDIA: could not open the device file /dev/nvidiactl (Permission denied).
NVIDIA: Direct rendering failed; attempting indirect rendering.

What permissions do I need to change, exactly, to get this working?

You may need to be in sudoers when running the program.

That would be silly, I’d think.

Haven’t actually needed to do this in years, but you basically need to convince the X server on the “better GPU” box that you, a remote user, should be allowed to write to it. This obstacle is to prevent what was decades ago a problem: anybody being able to connect to, mess with, and monitor your X display, including your keystrokes.

Question: are you logged into X on the server box (the box with the better GPU)? If so, you own the display, and your ~/.Xauthority cookie can write to the display. That should make things simple. Then you won’t need to transfer X magic cookies (xauth extract - boxa:0 | ssh userb@boxb xauth merge -) between whoever is logged into X on the server and your account in order to be able to open an X connection. If the server is intended to be unattended, you can set X (via kdm/xdm) to auto-login on boot to a specific user so that X is up and ready to go for your preferred user, ready for you to use, local or remotely.

And I’ll bet there’s an X config option somewhere to disable all access controls (xhost/xauth/etc.) and leave the server open to write perms by all users. One of these:

xhost +
xhost +localhost
xhost +boxb

in the X server start script (or run from a shell on the server after log in) may be just what you need, but I bet there’s a mirror setting in an X config file. Possibly an xdmrc or kdmrc file.

See the URL I posted above for details and the man pages for xauth/xhost. Google will likely turn up more tutorial material.

Also, following up on the root issue mentioned above, I doubt that’ll do it unless you’ve already disabled access permissions or are sharing home dirs over NFS, but you might try ssh root@boxb; export DISPLAY=:0; runapp just to verify that.