Current state and solutions for OpenGL over Windows Remote [closed]

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

Bartonbartosch

-DGLFW_USE_OSMESA seems to be Linux only based on glfw CMakeLists.txt file... – Brazee

You can now use OpenGL over remote desktop also on nvidia consumer GPUs. reddit.com/r/nvidia/comments/fx202t/… – Overthrust

Answer 1

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.

Eternity

Does that map to an actual registry key? – Luxate

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services, REG_DWORD:bEnumerateHWBeforeSW=1 – Luxate

Note: the name of the group policy appears to be "Use hardware graphics adapters for all Remote Desktop Services sessions" rather than "Use the hardware default graphics adapter for all Remote Desktop Services sessions" but I didn't want to change the answer without being 100% certain that I'm not looking at the wrong key. – Raddatz

@WaiHaLee that is totally possible. Right now I don't own any en-us Windows, and what I wrote was a translation from my native language, backed by some quick googling to double-check the group policy's name. If you do have a en-us or en-gb version of Windows, I'd be grateful if you could check that and update the text with what you see in EN version. The default word there could make a difference (there is a notion of "default graphics adapter" in the OS), but I'm pretty sure that I saw none similarly-named policies, so whatever you see there - most probably is the same policy I wrote about – Eternity

Okay - thanks for confirming. I've updated the answer with the string as it appears on my en-gb machine - and added the url for a screenshot (also from my machine) to the edit summary. – Raddatz

Does this group policy send opengl operations to the client computer for rendering on the client's hardware or does it require opengl (virtual?) hardware be present somehow in the VM we're connected to via rdp? – Ensoll

@Ensoll no idea, really, but I guess it's the latter one. When connecting via RDP, host-Windows injects itself a RDP-display-driver and that display driver is used for rendering the remote session on the host/server, and the group policy controls whever that driver advertises itself as opengl-compliant or not. That's all I know. I dont know whever that display driver forwards operations to a normal graphic driver and somehow capture the videostream, or whever it software-renders everything. Here, the latter would totally collide with how the policy is named, so I guess it's the former. – Eternity

It turns out (as far as I can tell without much effort) that a local hardware device is used to render and the resulting framebuffer content is sent to the client for display. – Ensoll

Wow, Nvidia took a good step in the Corona crisis: since driver version 440 RDP with hardware acceleration is supported also on consumer Geforce GPUs, not only Quadro hardware! And together with the "Use hardware graphics adapters for all Remote Desktop Services sessions" policy this finally got my RDP working as I need it: with full OpenGL support, on a normal consumer Geforce card! – Jolenejolenta

@rvjr: I don't have Quadro-class card, my laptop has integrated GeForce GTX 1050 and I had no problems with OpenGL after enabling "Use hardware graphics adapters(...)" - Repetier-Host on remote machine reported OpenGL 4.6.. I know I wrote this answer on May and driver pack 440 you mentioned was released a month earlier, but I'm pretty sure I wasn't (and am still not) running the latest drivers. NVIDIA Control Panel shows 417.35. Are you sure this wasn't done earlier? – Eternity

@quetzalcoatl: I found this driver revision on khronos.org/news/permalink/…, as palfi also mentioned in a comment below. I don't know if this is the exact version, but I was coming from a way older revision and it started working right after the driver upgrade, even without reboot. – Jolenejolenta

If you are using an nVidia card you will need to install Nvidia-opengl-rdp (may require nvidia account). khronos.org/news/permalink/…. I have an rtx 2080 and after installing this I can spawn openGL contexts / windows in my RDP. – Gilliam

I tried, and it is disabled for a reason. You can initiate the session only once in Windows 10, after that the server needs reboot. At least it was in Autumn 2020. The things may have changed when you are reading this. – Chibcha

For future readers: Note that the policy is kept in the bEnumerateHWBeforeSW value, but is not read from there. You cannot change the setting by changing the registry value. From Windows registry changes does not reflect on the Group Policy.: "Group policy engine does one-way processing: settings defined in GPO are applied to registry, file system, etc., overwriting whatever values that you set locally." – Raddatz

Answer 2

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.

Manxman

Agreed, this combined with updating RDC settings works. > nvidia-smi -g {card number} -dm 0. – Adaline

Answer 3

Some people recommend using "tscon.exe" if you can: https://mcmap.net/q/470108/-opengl-and-remote-desktop or using a scheduler to do it on native hardware: https://mcmap.net/q/470108/-opengl-and-remote-desktop 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

Brazee

Thank you very much! Mesa3D for Windows works perfectly (which is provided in your last link). – Snatch

Answer 4

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.

Explore