I’m thinking of building a dedicated Linux box with a couple GT280s in it. But most often I’ll be working on my main machine.
Is it feasible to use a tool like VNC to access and control the Linux box remotely and do CUDA development… compiling and running CUDA apps? It’d be especially nice to have the box at work and still be able to fully access it over the internet from home.
I worry about the effects of CUDA on the VNC display (probably no problem) but even more about the effects of crashes from my app bugs locking up or rebooting the Linux box… would that cause problems, especially any lockups that would need a physical reset or power cycle?
I could ask the same thing about using a Windows box the same way, but there I think blue screen crashes will lock the PC and it needs a physical reboot. (or maybe there’s a way to make bluescreens power cycle?)
Don’t you know about ssh ? You don’t need such thing as VNC to compile or to run some CUDA programs. Of course, this may be an issue if you want to display things, but as long it’s for computation …
Concerning the remote reboot thing, if you have several machines, you can configure IPMI to get a remote console.
Generally even if you manage to do something very bad that hangs the driver it will remain accessible via ssh, so you should definitely at least be able to reboot it remotely. It’s theoretically possible to solve the problem sometimes with some rmmod -f/modprobe trickery, but generally a reboot is a much better idea.
Of course, if you have a reproducible hang, tell us ASAP because we are trying to squash those as fast as possible.
Excellent, that’s good news, since it’s a different behavior than Windows, where blue-screen errors hang the whole machine.
So Linux is perfect for remote development… thanks for the verification!
I can second this. I’ve crashed the CUDA driver and X hard more than once while sitting at my desktop, making it unaccessible. A simple ssh in from the laptop and I can reboot the system without any problems. I have only experienced problems where a physical power down was needed a few times, and the last was over 6 months ago.
As for VNC vs. ssh, you can use both! Securely tunnel VNC over ssh so nobody snoops on you and you’ll have a GUI for a nicer programming environment. Although, I recently discovered nomachine (http://www.nomachine.com/) from a CUDA forum post and I find it vastly superior to VNC in performance on slow connections so I would recommend that instead of VNC.
NX starts a separate X server on the target box, and runs MESA, on DISPLAYs like :1000. Perfect for running a couple xterms, editors, debuggers and other flatland tools. Performance will obviously be rather bad for GL/X apps, as the rendering is done in software. When you set DISPLAY to :0, you can access the hardware directly, I do this to run my good old GLSL GPGPU code remotely. As soon as you’re opening up a window for rendering on the remote device, you obviously won’t see it. Cuda console apps do not have to redirect X DISPLAY. My bet is that Cuda GL interop apps WILL not run over NX, but I haven’t really tried.
As long as your apps are console only, you can use ssh or ssh+NX or ssh+VNC or anything to use your linux cuda box from anywhere in the world.
A rogue host-device memcpy can really mess up your day, if you are using the machine you are running the CUDA code on for development also. Tried that a few times myself.
For the initial development, especially when messing with memory allocation and host-device, device-host copying I use another machine to run the code on.
A makefile target for copying the executable to the test machine such as this