§ ¶3D graphics acceleration over Remote Desktop
A friend of mine tipped me off to an interesting post on DIRECTXDEV about GPU acceleration over Remote Desktop. After some investigation with a couple of machines, I discovered that yes, it is actually true that you can run 3D apps over Remote Desktop (Terminal Server). The key is that the machine you are remoting into must be running Windows Vista with a WDDM driver. Beyond that, it actually works as expected, although a bit slow. Some details:
- Again, the machine you are logging into must be running Windows Vista.
- The machine you are remoting from (running mstsc.exe) does not have to run Windows Vista.
- You do not have to use version 6 of the terminal services client -- version 5 that comes with Windows XP works fine.
- This doesn't appear to have anything to do with Avalon remoting, which allows Aero Glass to be shown over RDP. Supposedly you need both machines to be running Vista to do that, and you definitely need at least Ultimate or Enterprise on the target machine do it (I tried it with Business and it didn't work). 3D acceleration works fine with XP to Vista Business.
- You do not need any of the "experience" options enabled -- bitmap caching, desktop composition, effects, etc. They can all be disabled.
- Both OpenGL and Direct3D 9 work. Regular D3D9 is fine; D3D9Ex is not necessary.
- Direct3D 7 does not appear to work. I tried the old "I've got some balls" standby, and the only D3D driver that showed up was the software renderer (RGBRast).
- All 3D acceleration takes place on the server; only the image is sent to the client.
- Pretty much all D3D9 caps are intact, just as if the app were running locally. Even scanline queries work (!), although I'm not sure what it actually reads.
Now, the downside: it's slow. Really slow. So slow that I'd say it's basically unusable unless you're on a LAN, and a fast one at that. It looks like Terminal Services tries to send over the data from every Present(), and it blocks the app until that happens, instead of just skipping frames. It eats a lot of CPU in the process, too, instead of just waiting. I was just barely able to push 640x360 video at 24 fps with VirtualDub's D3D9 display minidriver, which was throwing about 10MB/sec across the gigabit LAN here -- probably about the best that the consumer-level hub can do. Readback doesn't seem to be a problem, at least not on the GeForce 6 and 8 cards I have here, because everything speeds back up if you cover enough of the 3D window.
Basically, this means that 3D support is usable with apps that just use it for 2D acceleration or otherwise static rendering, but anything dynamic like a video player or a game is going to be far too slow. It might be more viable if Microsoft had implemented frame dropping, but it looks like VNC may still be better for that. What this is definitely good for, though, is running GPU accelerated apps remotely. On XP, this isn't possible over Remote Desktop because as soon as you log in all your apps are pushed onto the software-only driver. On Vista, though, they could continue to run on the server-side GPU, and performance isn't a problem if the app isn't displaying the result continuously.
Comments
Comments posted:
hehe, same is possbile with teamviewer, but slow
10 mb/sec on gigabit lan, did you try enable jumbo Frames in the nic driver for you cards on both machines?
have a nice day
tommy
Tommy - 08 06 08 - 15:57
Hard to tell about the current version 3, but it looks like TeamViewer started as a VNC clone, and was compatible up to 2.x. Not too surprising, since a lot of other products are structured that way, like Fog Creek Copilot. VNC reads the screen via GetDC/BitBlt(), which works with 3D even in XP, but is slow and also requires the console to be unlocked as well. The really bad part is detecting what parts of the screen have changed; polling is the default, but it's very CPU intensive and particularly sucks for console windows. Some versions of VNC can use a mirror driver to detect screen changes to optimize this (UltraVNC), but that kills all DirectX acceleration. The ultimate remote configuration I've found is to have two machines that both have Remote Desktop and TightVNC enabled; RDP is for regular usage, VNC for 3D, and if one of the machines gets wedged the other one can be used to unwedge it....
Didn't try the jumbo frame optimization. CPU usage on the client was pretty high, but it's only a 1.4GHz P-M laptop with a mediocre network card.
Phaeron - 08 06 08 - 16:09
Over 100 mbit lan the limiting factor could be the cpu power. Try to load a still image in a video player at 30 or 60 fps and maximize the window, network traffic stays low but cpu goes up on the client. On my old p4 notebook the cpu is the bottleneck, about at quater screen it gets maxed out, while the incoming data is only 2-3 mb/s.
Gabest - 08 06 08 - 18:58
If CPU usage on the client is indeed a problem (I somewhat doubt it), you could try some alternative client like rdesktop on Linux, it might or might not work better.
Reimar - 09 06 08 - 04:17
This is good since without it it was difficult to justify using 3D in desktop applications, even if they did not require high framerates (or animation at all). Hopefully it, and DX10's improvements on sharing the 3D hardware between apps, will mean it isn't just games that take advantage of 3D hardware in the future. I don't expect much to use it until Vista is the baseline, though.
On this subject, I wish Remote Desktop would detect when parts of the screen are changing rapidly (e.g. a movie playback window) and start sending those rectangles using lossy compression, with a suitable bitrate chosen for the server's CPU and the network's bandwidth. If the region stopped changing the protocol could then update it with a lossless version, but for video I'd much rather have a good framerate than see lossless copies of every Nth frame.
Leo Davidson (link) - 09 06 08 - 09:14
Uhm, some time ago I ran one of my OpenGL apps remotely via 1Mbit DSL on that nice WinXP dual Opteron in Lab - slow, but usable.
So at least for OGL there is no need for Vista.
Daniel - 16 06 08 - 16:48
A friend of mine has been developing VNC client/server with OpenGL 3D. No need for Vista or DirectX 10 either.
Igor Levicki (link) - 22 06 08 - 00:57
It's true that graphics applications can run very slowly in Terminal Services, particularly over a WAN. However, there is a way to improve the display of graphics for remote users. Ericom Blaze is a software-based RDP acceleration AND compression product that provides a superior end-user experience over WAN and congested LANs. Besides delivering higher frame rates and reducing screen freezes and choppiness, Ericom Blaze accelerates RDP performance by up to 10-25 times higher, while significantly reducing network bandwidth consumption over low-bandwidth/high latency connections.
Ericom Blaze works with any standard RDP host, including VDI, Terminal Servers and remote physical machines.
You can read more about Blaze at:
http://www.ericom.com/ericom_blaze.asp?U..
Or view a video demo at:
http://www.ericom.com/blaze_youtube.asp?..
Adam
Ericom Software
AdamG (link) - 14 12 09 - 01:02
Dear Phaeron,
with much interest, I read your report of GPU-accelerated OpenGL support
in MS Windows Vista (or greater) remote desktop sessions in
http://www.virtualdub.org/blog/pivot/ent..
With high expectations I immediately tried to run a little OpenGL test
application I did not succeed in creating a GPU-accelerated OpenGL context in a remote session. It always drops back to software OpenGL emulation.
In addtion, I could not find any other OpenGL application/demo that could make use of GPU-acceleration in RDP sessions.
The only thing that I could confirm to work was that non-fullscreen
Direct3D 10 works WITH GPU-acceleration in RDP sessions.
Here my setup:
- NVIDIA Quadro FX 3700, driver version 197.03
- Administrator login via RDP
Are there any further hints from your side what we could try to still get OpenGL to make use of GPU-acceleration in an RDP session?
In addition, could you maybe point me to the original DIRECTXDEV
article that you are referencing in the posting? I tried hard but could not find it.
Thanks a lot in advance!
Markus
Markus Neff - 24 06 10 - 21:17
Comment form
Please keep comments on-topic for this entry. If you have unrelated comments about VirtualDub, the forum is a better place to post them.
