I have trouble using OpenGL over Remote Desktop Connection (RDC) on a Windows 10 computer.
The server has an NVIDIA GEFORCE 8600 GT.
Yet, OpenGL reports the card is a GDI Generic Device.
The driver is up to date v342.01
I know for sure OpenGL over RDC is possible for I am able to do so with another server equipped with a Quadro.
Do I need to enable an option in Windows for it to work? Or is it jus not possible with this graphic card?
Is MS Remote Desktop necessary in your case?
If it is - you can try to use scheduler to start OpenGL app. Here is a simple powershell script to do this remotely (it assumes you enabled powershell remoting).
If not - try some other remote access software (VNC, TeamViewer or something similar)
Dude i know there is a solution, but for now i only know that works with admin users, and you jhay to instal de pstools, here es the code, of the bat, also create a shortcut for the bat and run it as an admin.
setlocal EnableDelayedExpansion
FOR /F %%A in ('qwinsta') do (
set tempSessionName=%%A
if "!tempSessionName:~0,1!"==">" (
psexec -s tscon.exe !tempSessionName:~1! /dest:console
)
)
this code will take you out of your session, you will need to add a line to open your software at the end, you need to recconect again and will open the software that you need included the opengl
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 2 years ago.
The community reviewed whether to reopen this question 5 months ago and left it closed:
Original close reason(s) were not resolved
Improve this question
OpenGL and Windows Remote don't play along nicely.
Solutions for this are dependent on the use case and answers are fragmented across the vast depths of the net.
This is a write-up I wish existed when I started researching this, both for coders and non-coders.
Problem:
A RDP session of Windows does not expose the graphics card, at least not directly. For instance you cannot change the desktop resolution and GraphicsCard drivers usually just disable their setting menus. Starting a OpenGL context higher than v1.1 fails because of this. The, especially in support IRCs, often suggested "Don't use WindowsRemote" is unfortunately not an option for many. In many corporate environments Windows Remote is a constantly used tool and an app has to work there as well.
Non-Coder workarounds
You can start the OpenGL program, allowing it to see the graphics card, create an opengl context and then connect via WindowsRemote. This always works, as Windows remote just transfers the window content. This can be accomplished by:
A batch script, that closes the session and starts the program, allowing you to connect to the program already running. (Source)
Using VNC or other to remote into the machine, start the program and then switch to Windows Remote. (Simple VNC programm, also with a portable client)
Coder workarounds
(Only for OpenGL ES)Translate OpenGL to DirectX. DirectX works under Windows Remote flawselly and even has a Software rendering fallback built into DX11 if something fails.
Use the ANGLE Project to do this at run-time. This is what QT officially suggests you do and how Chrome and Firefox implement WebGL. (Source)
Switch to software rendering as a fall back. Some CAD software like 3dsMax does this for instance:
Under SDL2 you can use SDL_CreateSoftwareRenderer (Source)
Under GLFW version 3.3 will release OSMesa (Mesa's off screen rendering), in the mean time you can build the Github version with -DGLFW_USE_OSMESA=TRUE, but I personally still struggle to get that running (Source)
Directly use Mesa's LLVM pipe for a fast OpenGL implementation. (Source)
Misc:
Use OpenGL 1.1: Windows has a built in implementation of OpenGL 1.1 and
earlier. Some game engines have a built in fall back to this and thus
work under Windows Remote.
Apparently there is a middle-ware, that allows for even OpenGL 4 over Windows Remote, but it's part of a bigger package and is a commercial solution. (Source)
Any other solutions or corrections are greatly appreciated.
[10] Nvidia -> https://www.khronos.org/news/permalink/nvidia-provides-opengl-accelerated-remote-desktop-for-geforce-5e88fc2035e342.98417181
According to this article it seems that now RDP handles newer versions of Direct3D and OpenGL on Windows 10 and Windows Server 2016, but by default it is disabled by Group Policy.
I suppose that for performance reasons, using a hardware graphics card is disabled, and RDP uses a software-emulated graphics card driver that provides only some baseline features.
I stumbled upon this problem when trying to run Ultimaker CURA over standard Remote Desktop from a Windows 10 client to a Windows 10 host. Cura shouted "cannot initialize OpenGL 2.0 context". I also noticed that Repetier Host's "preview" window runs terribly slow, and Repetier detects only an OpenGL 1.1 card. Pretty much fits the "only baseline features" description.
By running gpedit.msc then navigating to
Local Computer Policy\Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Remote Session Environment
and changing the value of
Use hardware graphics adapters for all Remote Desktop Services sessions
I was able to successfully run Ultimaker CURA via with no issues, and Repetier-Host now displays OpenGL 4.6, and everything finally runs fast as it should.
Note from genpfault:
As usual, this Policy is kept in the HKLM registry group in
HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services
Set REG_DWORD:bEnumerateHWBeforeSW to 1 to turn ON using GPUs in RDP.
OpenGL works great by RDP with professional Nvidia cards without anything like virtual machines and RemoteFX. For Quadro (Quadro 4000 tested) you need driver 377.xx. For M60 you can use the same driver. If you want to use last driver with M60, you have to change the driver mode to WDDM mode (see c:\Program Files\NVIDIA Corporation\NVSMI\nvidia-smi.1.pdf). It is possible that there are some problems with licensing in this last case.
Some people recommend using "tscon.exe" if you can: https://stackoverflow.com/a/45723167/32453 or using a scheduler to do it on native hardware: https://stackoverflow.com/a/41839102/32453 or creating a group policy:
https://community.esri.com/thread/225251-enabling-gpu-rendering-on-windows-server-2016-windows-10-rdp
maybe copy opengl32.dll (or opengl64.dll) to your executable's dir: https://blender.stackexchange.com/a/73014 and newer version of the dll: https://fdossena.com/?p=mesa/index.frag
Remote Desktop and OpenGL does not play very well. When you connect to a Windows box the OpenGL Driver is unloaded and you end up with software emulation of OpenGL.
When you disconnect from the Windows box the OpenGL driver is not reloaded. This causes issues when you are running tests on the machine as you have to physically login to the machine to reset the drivers.
The solution I ended up using was to:
Disable Remote Desktop.
Delete all other software for remote desktop access. Because if it's used for logging in remotely the current set of drivers loaded may be messed up.
Install NoMachine
NoMachine is my personal favourite (when it does not play up) for a number of reasons:
Hardware acceleration of compression (video of desktop).
Works on Windows and Linux.
Works well on low-bandwidth connections especially if the client and server have the necessary hardware for compression of the data stream.
On Linux you get your desktop as you last left it when you were sitting in front of the machine.
On Windows it does not affect OpenGL.
currently free for personal and commercial use. Do check the licence in case it's changed.
When NoMachine plays up it hogs the CPU but this happens rarely. It is however in active development
Others to consider:
TurboVNC
TightVNC
TeamViewer - only free for personal use.
I compiled a C++ code under Linux (Ubuntu) and everything is fine as far as I connect a monitor to my PC.
My code shows some graphics and then it saves their screenshots. The runtime graphic is not important to me but the screenshots.
But if I run the code remotely, I face with the following runtime error:
freeglut (something): failed to open display ''
If I forward x (ssh -v -X) everything would be find. But what if I don't do that?!
How to get around it? I don't care if anything is displayed or not.
Is it possible to define a temporary virtual screen on the remote computer or get around this problem in any other way? I just need the screenshot files.
I suggest you try XVFD as your X server on the remote machine
Quote form this answer: Does using Xvfb to run OpenGL effects version?
Xvfb is an X server which whole purpose is to provide X11 services without having dedicated graphics hardware
This allows you to have both a GL context and a window without using a GPU
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 8 years ago.
Improve this question
I connect the remote Ubuntu 12.04 64bit by vncviewer application. But when I run a OpenGL application, it shows the exception information:
Caught exception GLShader::GLShader: GL_ARB_shader_objects not supported while initializing rendering windows
But if I connect the monitor with the remote computer, it works well and could show the OpenGL application.
Is there any solution to make the OpenGL application run in the remote window by vncviewer? Thanks!
UPDATED:
In the remote Ubuntu 12.04 64bit server, the ~/.vnc/xstartup file is as follows:
.
And the VNC Viewer client in a Windows 7 32bit system is as follows:
Usually on Linux the VNC server is a dedicated variant of the Xorg X11 server (Xvnc) that uses a software based renderer backend and has not GPU acceleration. I guess you're using a NVidia GPU and the NVidia proprietary drivers, or AMD GPU with AMD proprietary drivers, because otherwise the Mesa softpipe implementation would have kicked in.
If you really want to use the GPU you'll have to VNC into a running X11 session into which you start the x11vnc server.
Update
First things first, for the GPU to work a X server must be running and have its output be sent to the display connectors. Sorry, the current driver model doesn't allow for a purely off-screen GPU accelerated X11 sever; this is not a limitation of the hardware, but just the Xorg X11 server implementation. This also means, that whatever you're doing will be visible to whoever connects a monitor to the screen. At least we can take care of, that nobody messes with mouse and keyboard.
First things first create a custom /etc/X11/xorg.vnc.conf consisting of this
Section "ServerFlags"
Option "AllowEmptyInput" "true"
Option "AutoAddDevices" "off"
Option "DontZap" "false"
Option "DontVTSwitch" "true"
Option "HandleSpecialKeys" "Never"
EndSection
Section "Device"
Identifier "DeviceGPU"
Driver "nvidia"
EndSection
Next implement a script stat starts everything you want to run in that particular X11 session. Most of the time this would be something that launches the x11vnc server and then execs into the desktop envinronment, e.g.
#!/bin/sh
x11vnc -display $DISPLAY &
exec startxfce4 # or whatever
I refer you to the manpage of x11vnc on how to configure the authentication to use.
Lastly you should check that the Xorg server binary is SUID root; the NVidia driver is still not making full use of KMS and depends on the X server being started with full privileges.
Once these prerequsites are met you can start a X11 session that supports VNC using
xinit $FULL_PATH_TO_YOUR_SESSION_SCRIPT -- $DISPLAY -config xorg.vnc.conf
where $DISPLAY is a free X11 display number.
OK, first I shall point that I am completely new to Windows Apps Development, which is good, since I am trying to develop a Windows Store App for PC to use a PrimeSense Scanner connected via USB. I have asked a more specific question about this here.
This time I have a more generic question, which is more related to Windows Store app development. I am using VS2013 Express and compiling for Win32.
When I compile my application for VS2012 and run it as an execcutable file, I can connect to the scanner perfectly. But I can't do the same with VS2013 and running it as a Store app.
I know the device is connected and the drivers are updated and all dlls file placed in the Widnows System 32 directory.
I have also added all Capabilities to the App Manifest and also added the following Device Capability
<m2:DeviceCapability Name="usb">
<!--OSRFX2 Device-->
<m2:Device Id="vidpid:1d27 0609">
<m2:Function Type="classId:ff * *" />
<m2:Function Type="name:vendorSpecific" />
</m2:Device>
</m2:DeviceCapability>
The vid and pid, obviously match the corresponding codes of the device.
One of the errors I recieve when trying to conenct to the scanner using OpenNI is:
Could not open to "\\?\usb#vid_1d27&pid_0609&mi_00#7&1601586a&0&0000#{c3b5f022-5a42-1980-1909-ea72095601b1}" USB Device not found
This error is quite frustrating since I know the device is connected. So I tend to think that there is some level os specificity on the Windows Store App side of the game that is not enabling my to connect to the device. As I said, I am compiling for Win32.
Is there a chance that the drivers will not work for a Windows Store App. Is there some extra stuff I should do inside the Windows Store App logic that I am not doing and that is necessary to connect the USB device? I am sorry, but I am completely new to Windows Store App development.
Thank you.
You can't do that from metro apps.
You typically create a handle to that usb device by calling CreateFile with that object mananger path as the file to 'create'. CreateFile is not allowed in metro apps - "desktop apps only" - and its 'replacement', CreateFile2, specifically doesn't allow opening object manager objects.
Furthermore, the documentation for CreateFile2 states that in metro apps this function can only open files and directories (and not things like pipes, mailslots, consoles, etc.).
See also this post on social.msdn
Unless I missed something, I don't think this is possible.
I'm taking an introductory OpenGL development course with a Surface Pro, and was hoping to connect to my more powerful desktop for development through the native Windows remote desktop tool. I'm having trouble with the shaders on my first test program, which leads to my question. Will the shader work be done by the graphics card on my Surface (RDP client) or my desktop (RDP host)?
That depends on your remote system's configuration. Your usual consumer GPU with standard drivers will not provide any HW acceleration for the RDP whatsoever and you'll drop into a SW emulation mode. However there are special visualization server GPUs and drivers which hook into the RDP server implementation and provide GPU acceleration for it; very likely you don't have that though.
Note that it's ultimately just a driver issue. With the right drivers every GPU could do that. But HW vendors want to sell their special purpose devices, so they're locking that functionality to a specific product line.
I'm hoping, that the advances of the Linux open source graphics ecosystem will, as a sideshow, enable implementing such visualization servers with commodity hardware in the near future. As much as I disregard the Wayland protocol and condept, as much do I like the advances its development promotes toward the lower levels of the Linux graphics stack. Which may likely put some pressure on the Windows world to catch up with that.
If you run your software from RDP session, you lose HW acceleration.
But, some QnA sites notice that RDP client will work with hardware accelerated graphics if the application is started from the local session before the connection.
https://social.technet.microsoft.com/Forums/windowsserver/en-US/c8295ef8-3711-4576-9293-2c4965280165/opengl-and-remote-desktop?forum=winserverTS
So, the following trick is proposed.
Run a batch file which disconnects the current RDP session and starts the application which needs HW accelerated graphics
Wait several seconds till the application has started
Reconnect to RDP.
The application will be started from the local session and will use HW accelerated graphics.
Here is a sample of the batch file, from my answer on the linked page:
#echo off
echo.
echo Remote Desktop will be temporarily disconnected . . . please reconnect after a few seconds.
echo.
pause
#echo on
REM The active session has an arrow as the first character
setlocal EnableDelayedExpansion
FOR /F %%A in ('qwinsta') do (
set tempSessionName=%%A
if "!tempSessionName:~0,1!"==">" (
#echo on
tscon.exe !tempSessionName:~1! /v /dest:console
#echo off
)
)
#echo off
echo.
echo Starting MyProgram.exe . . .
#echo on
start MyProgram.exe
#echo off
echo.
pause
I came through nvidia developers page and found this exe files which will allow rdp connection to use graphic acceleration.
https://developer.nvidia.com/designworks
Check list:
Driver version should be above r440+
2.Run the openglrdb.exe as administrator
3.Restart the machine.