I’ve found that win32\64 OpenCL programs can’t run through Remote Desktop Connection using latest Nvidia OpenCL Driver (196.34). But it’s very useful when we want use powerful remote server.
Tested on win7, but I think it’s applied to all win versions.
Mac OS X also has a problem with this whereby if you aren’t logged in to the window server the GPU won’t be recognized. I suspect this will be fixed as the technology matures.
I believe this is a Windows issue, not a Nvidia problem, if the remote login is implemented through a Service on the remote machine. A while back, I was trying to make calls to a HTTP server, Jetty, and have it execute OpenCL kernels. Jetty is normally run on Windows as a service, however when doing so no devices are found.
I also tried with an ATI GPU installed and it found only the CPU. I isolated the problem to running as a service, because I could run Jetty inside a command window, and everything can be found & executed. Good enough for my development needs. Linux server is my deployment OS.
This thread discusses thishttp://forums.nvidia.com/index.php?showtopic=153313
No. This is not Windows issue and login to console may by not acceptable for many reasons. For example old versions of GPU-Z have same issue, but new versions works normally.
Problem is, that under terminal Graphics API defaults to RDPDD Device Driver, which even do not supports D3D. GPU-Z proves that it`s not a problem, especially besause GPU driver have kernel part and can do anything. Also opencl tend to be calculation API, not graphics, so it must be not depend on RDPDD Graphics Device Driver issue.
There no barrier to communicate between opencl dll and Nvidia driver directly.
I hope Nvida reads this post and take care of problem.
Great reply! Not to rehash everything, but that crude work around caused me to quit too early. When I saw that post, I immediately remembered (it seemed weird) that there is a “Allow service to interact with desktop” checkbox on a the “Log On” tab of a service’s properties.
I checked it & restarted. I still get an error on an OpenCL call, return code -64, which is not listed, but that is long after I had gotten a GPU device. The error is still troubling though. Running in a command window, I do not get any OpenCL bad calls. I do not have time right now to investigate further. My servlet code is out of date. This needs to wait.
Could this be useful to you? I see a “Remote Desktop Configuration” & “Remote Desktop Services” services. Both do not have this checked. As far as NVidia “fixing” this, I am not sure what a RDPDD Driver is, but it seems like what you suggest is for a components vendor making some kind of back door. Couldn’t this have unintended consequences, and wouldn’t every OpenCL vendor need to also do it? I think it might be better for Microsoft to address. They have their Direct Compute, which is probably also affected.
Well, I re-built my HTTP servlet with the latest source, and am sorry to report that I get this -64 error actually with the very first call, clGetPlatformIDs. A little detective work on my server log file shows the Nvidia Driver (195.nn) returned a valid platform (without any devs found) on the morning of 2/19. That afternoon, I was pulling out an ATI 4890 to sell on Craigslist. While I was at it, I updated to 196.21. A restart later that Day shows the first -64 exception in the log. I had just not been paying attention.
I only thought I was getting further, because I got an actual exception. Before I was getting a well formed message generated when 0 devs were found. It looks like NVidia might now be actively blocking this kind of usage, or I would have expected an official listed error code.
That checkbox thing may have some true effect on 195.nn, but I am not going back to find out. My work around is good enough for me. Does you no good though.
I think it’s a windows issue. It’s the same problem with openGL as well.
with VNC for example everything works fine
Actually my HTTP servlet has regressed since 196.21 on Windows. Since my last post on this topic, I have been finalizing the actual kernels. With them being about 99% production ready, I changed from a simple HTTP feasibility test, where the client held the socket open till the results were ready.
At the end of June, I had 2 fast HTTP calls, a submit and retrieve results. The client calls the 2nd with a delay till the results are available. Tried to test this servlet with Jetty just as an app in a command window, not a service, using a GTX 480 on 257.21. The platform was found, the 480 was found, context created, buffers created & loaded, but I get a InvalidBinary return from first clBuildProgram() with “Considering profile ‘compute_20’ for gpu=‘sm_20’ in ‘cuModuleLoadDataEx_5’” in the log. Same kernels called from similar code inside a Java app runs fine.
I do not care a about Windows. Linux is my deployment platform. I now have a Ubuntu 10.4 desktop on the same machine. Running 256.22 (Jetty not yet started from init though), the servlet only gets as far as a InvalidBinary return from clCreateContext(). This is not a valid return code for this call.
I have held back reporting the Linux problem to NVIDIA, as I tried running the Java Application with OpenCL 1.1 Beta 1 (258.19), and completely failed ( http://forums.nvidia.com/index.php?showtopic=171684 ). I am hoping Beta 2 will at least let me run as a Java app, so I can file any bugs against 1.1, not 1.0.
Tried with GTX680 and 301.42 drivers - problem remains.
Not good for so called GPU calculation platform.