cancel
Showing results for 
Search instead for 
Did you mean: 

Archives Discussions

dravisher
Journeyman III

Powershell remoting together with GPU not working

Kind of exotic problem, but any ideas are welcome

I'm having trouble launching OpenCL programs using Windows Powershell remoting. Basically the remoting is working fine with all programs (including OpenCL programs targeting the CPU), but when I target the GPU the error code -1 is returned, which corresponds to device not found. So this returns with error code -1:

context = cl::Context::Context(CL_DEVICE_TYPE_GPU, cprops, NULL, NULL, &err);

While this works fine:

context = cl::Context::Context(CL_DEVICE_TYPE_CPU, cprops, NULL, NULL, &err);

Running exactly the same command locally on the PC in question works fine, so the GPU is correctly found and used except if the program is launced remotely.

I have made absolutely sure I am actually executing the commands remotely (so I'm not mistakenly running the commands on my laptop which has no GPU). When running on the CPU the program is actually running on my PC, not my laptop.

I think maybe it's too much to hope someone has the answer (is anyone even using Powershell remoting?), but any suggestions on what may be wrong would be welcome.

0 Likes
10 Replies
cjang
Journeyman III

This sounds like an environment issue in the manager that runs/fork/execs the program. I don't have any experience with Powershell. But I've seen this kind of thing often on Unix systems with some sort of daemonized service. When you run locally, the parent process is your shell which naturally has the right environment settings. When you run remotely, the parent process is Powershell which may have different settings.

Just a guess.

0 Likes

Yeah probably something like that, though this is the first time I've experienced any problems with it. Normal environment variables like path and atistreamsdkroot have correct values (i.e. the values of the computer I'm logged in to remotely), but I guess something a bit deeper could be wrong.

It sure is annoying not being able to run my programs remotely though, major pain actually 😕

0 Likes

Never used powershell but I have another experience with remote access. When using Windows 7 build-in remote access it isn't possible to use any GPU installed at host we're connecting to simply because Windows changing video driver once remote session activated. No matter what GPU presents at system it won't be visible as it won't be attached to current desktop.

May be you're facing totally different problem, so just FYI.

0 Likes

Originally posted by: empty_knapsack Never used powershell but I have another experience with remote access. When using Windows 7 build-in remote access it isn't possible to use any GPU installed at host we're connecting to simply because Windows changing video driver once remote session activated. No matter what GPU presents at system it won't be visible as it won't be attached to current desktop.

 

May be you're facing totally different problem, so just FYI.



I'm not sure what you mean by build-in remote access as Powershell and everything needed for remoting is part of a standard install of Windows 7, so I thought it was the standard way. But Windows Powershell remoting uses Windows Remote Management (WinRM), so perhaps it is related? Do you know if WinRM was the culprit in your case as well?

0 Likes

when you log in remotely via built in remote desktop your program can get access only to the virtual graphic card. no DX,OGL,OCL. you must use VNC which takes real desktop. it is same for services too. services can't gain access to graphic HW.

0 Likes

Well WinRM is a service. But while a service can't access the GPU, a service can launch another application (i.e. the OpenCL program) which does use a GPU, right?

Perhaps it was Remote Desktop empty_knapsack was talking about. However powershell is not graphical (it's basically the analogue of using ssh on *nix to run remote commands), so it sounds like it's a different problem after all.

0 Likes

You might try Cygwin and ssh instead of Powershell. You can then launch your binaries from a bash shell (or whatever else you choose). Even with the issues around randomized address spaces (i.e. rebaseall), this will probably still work as you are launching native win32 binaries that don't need the Cygwin compatibility layer.

I'm not surprised if Powershell tries to virtualize the platform somehow with a side-effect of disabling the GPU device.

0 Likes

Originally posted by: cjang You might try Cygwin and ssh instead of Powershell. You can then launch your binaries from a bash shell (or whatever else you choose). Even with the issues around randomized address spaces (i.e. rebaseall), this will probably still work as you are launching native win32 binaries that don't need the Cygwin compatibility layer.

 

I'm not surprised if Powershell tries to virtualize the platform somehow with a side-effect of disabling the GPU device.



Indeed, I didn't think of Cygwin and that is certainly an option if I can't figure out the Powershell problems. It does feel ... unoptimal having to use Cygwin to do something as simple as launching a program remotely on Windows 7 though!

Btw. I couldn't even find out what rebaseall is, a search only returns people having trouble with it :-P. Guess I'll have to learn if I wind up using Cygwin.

0 Likes

Vista introduced strong address space randomization that broke Cygwin. Three years ago, the workaround was "rebaseall". I found it to be very unreliable as the ASLR could happen at any time. The reason this was not a bigger issue then is that many users (especially corporate ones) were happy with XP and stayed with it.

From the Wikipedia page about ASLR (http://en.wikipedia.org/wiki/Address_space_layout_randomization😞 "A registry setting is available to forcibly enable or disable ASLR for all executables and libraries" and from this Cygwin thread (http://cygwin.com/ml/cygwin/2009-06/msg00223.html😞 "...this workaround seems to do the job" - it looks like the situation is better today.

I wouldn't worry about it. There's a pretty good chance what you need to do will just work.

0 Likes
En-you
Journeyman III

I have the same as you problems!

0 Likes