CUDA devices not detected when logged in through Remote Desktop

[mart0258]

In Windows Vista on x64:

Connecting to a system via Remote Desktop (rather than through the primary display) and launching the Boinc Manager (as is normally done on said login) prevents BOINC from detecting any CUDA devices.

[Nicolas]

When you connect through remote desktop, the graphics adapter is a virtual one for remote desktop, not your real CUDA-enabled graphics card. There is no way for BOINC to work around it.

[mart0258]

Replying to Nicolas:

Windows allows logging in locally while you are connected to remote desktop, thus changing the display from a virtual to a physical one. As such, I probably would recommend redetecting CUDA devices when CPU benchmarks are run.

This may be messy if you rerun CPU benchmarks after switching from local to remote. As such, I'm changing the type from defect to enhancement.

[Ageless]

The remote desktop function in Windows uses its own (built-in) graphics drivers. These aren't CUDA enabled. The only way around it is to use a third party app such as VNC (there are free versions such as OpenVNC available), which uses the graphics driver of the computer instead of its own built-in one.

And even if you can go around it by logging in locally on a remote desktop, then you are using the graphics driver of the machine you are using to look at the remote machine. BOINC won't be able to detect this driver, it can only detect the driver on the machine it is used on.

[JimKleine]

This problem description can be refined. My experience suggests this behaviour should be able to be resolved, or at least improved, in BOINC. Note: I am running BOINC as a service, not interactively.

My configuration

Windows XP x64 edition; using BOINC x64. nVidia 9800GT. Running BOINC as a service. This host is my primary workstation, so I'm usually logged on locally, but I regularly log in via Remote Desktop from off-site.

Starting BOINC client version 6.6.36 for windows_x86_64
Libraries: libcurl/7.19.4 OpenSSL/0.9.8j zlib/1.2.3
Running as a daemon
Running under account boinc_master
Processor: 2 GenuineIntel Intel(R) Core(TM)2 Duo CPU     E8200  @ 2.66GHz
OS: Microsoft Windows XP: Professional x64 Edition, Service Pack 1, (05.02.3790.00)
CUDA device: GeForce 9800 GT (driver version 19038, compute capability 1.1, 512MB, est. 65GFLOPS)

Observed behaviour

1. Boot host; service starts; CUDA hardware detected; GPU tasks will start; OK.

2. Login locally; GPU task continues to run; new GPU tasks will start and run; OK.

3. Login remotely via Remote Desktop; existing GPU task continues to run; OK.

4. Login remotely via Remote Desktop; a new GPU task will start, but it will immediately fail with the error:

Failed to set low-cpu sync mode
# Using CUDA device 0
# Device 0: "Device Emulation (CPU)"
# Clock rate: 1.35 GHz
#  Total amount of global memory:                 -1 bytes
#  Number of multiprocessors:                     16
#  Number of cores:                               128
Cuda error in file '..\cuda/cutil.h' in line 968 : no CUDA-capable device is available.
Memory usage: host:  bytes   device:  bytes
Assertion failed: 0, file ..\cuda/cutil.h, line 968

Comments & Implications

1. The CUDA hardware is clearly "available" to the task when BOINC is running as a service, even when the host is accessed via Remote Desktop (as evidenced by the fact that an existing task will continue to run). I understand the issue regarding the RDP video driver raised by Ageless, but I'm not sure that it is actually relevant.

2. The assertion at cutil.h, near line 968 seems to be "broken" (Note: I haven't looked at the code yet). The immediate cause of the problem is the assertion failure, but perhaps the assertion test isn't valid/correct/complete.

3. There is a nasty corollary to the current behaviour that needs to be resolved ASAP. Once the assertion has failed (e.g. a new task starts during a Remote Desktop session), this will:

a) Continue to error out tasks until the daily limit for the host is reached. This is bad for the project (tasks return a compute error) and uses host/project bandwidth inefficiently, since it downloads tasks that will immediately error out; and

b) Starve the host of work even when the issue is resolved; both immediately (daily limit reached) and in the longer term (reduced future daily limits, since the host is deemed "unreliable"), which is bad for the project and not good for volunteer morale.

I am a programmer (although not C++) and can provide testing resources for this issue if required. I will have a look at cutil.h as time permits, to see if I can suggest a fix.

[romw]

This is now fixed in the 6.10 version of the BOINC client.