Current version

v1.10.4 (stable)

Navigation

Main page
Archived news
Downloads
Documentation
   Capture
   Compiling
   Processing
   Crashes
Features
Filters
Plugin SDK
Knowledge base
Contact info
Forum
 
Other projects
   Altirra

Search

Archives

01 Dec - 31 Dec 2013
01 Oct - 31 Oct 2013
01 Aug - 31 Aug 2013
01 May - 31 May 2013
01 Mar - 31 Mar 2013
01 Feb - 29 Feb 2013
01 Dec - 31 Dec 2012
01 Nov - 30 Nov 2012
01 Oct - 31 Oct 2012
01 Sep - 30 Sep 2012
01 Aug - 31 Aug 2012
01 June - 30 June 2012
01 May - 31 May 2012
01 Apr - 30 Apr 2012
01 Dec - 31 Dec 2011
01 Nov - 30 Nov 2011
01 Oct - 31 Oct 2011
01 Sep - 30 Sep 2011
01 Aug - 31 Aug 2011
01 Jul - 31 Jul 2011
01 June - 30 June 2011
01 May - 31 May 2011
01 Apr - 30 Apr 2011
01 Mar - 31 Mar 2011
01 Feb - 29 Feb 2011
01 Jan - 31 Jan 2011
01 Dec - 31 Dec 2010
01 Nov - 30 Nov 2010
01 Oct - 31 Oct 2010
01 Sep - 30 Sep 2010
01 Aug - 31 Aug 2010
01 Jul - 31 Jul 2010
01 June - 30 June 2010
01 May - 31 May 2010
01 Apr - 30 Apr 2010
01 Mar - 31 Mar 2010
01 Feb - 29 Feb 2010
01 Jan - 31 Jan 2010
01 Dec - 31 Dec 2009
01 Nov - 30 Nov 2009
01 Oct - 31 Oct 2009
01 Sep - 30 Sep 2009
01 Aug - 31 Aug 2009
01 Jul - 31 Jul 2009
01 June - 30 June 2009
01 May - 31 May 2009
01 Apr - 30 Apr 2009
01 Mar - 31 Mar 2009
01 Feb - 29 Feb 2009
01 Jan - 31 Jan 2009
01 Dec - 31 Dec 2008
01 Nov - 30 Nov 2008
01 Oct - 31 Oct 2008
01 Sep - 30 Sep 2008
01 Aug - 31 Aug 2008
01 Jul - 31 Jul 2008
01 June - 30 June 2008
01 May - 31 May 2008
01 Apr - 30 Apr 2008
01 Mar - 31 Mar 2008
01 Feb - 29 Feb 2008
01 Jan - 31 Jan 2008
01 Dec - 31 Dec 2007
01 Nov - 30 Nov 2007
01 Oct - 31 Oct 2007
01 Sep - 30 Sep 2007
01 Aug - 31 Aug 2007
01 Jul - 31 Jul 2007
01 June - 30 June 2007
01 May - 31 May 2007
01 Apr - 30 Apr 2007
01 Mar - 31 Mar 2007
01 Feb - 29 Feb 2007
01 Jan - 31 Jan 2007
01 Dec - 31 Dec 2006
01 Nov - 30 Nov 2006
01 Oct - 31 Oct 2006
01 Sep - 30 Sep 2006
01 Aug - 31 Aug 2006
01 Jul - 31 Jul 2006
01 June - 30 June 2006
01 May - 31 May 2006
01 Apr - 30 Apr 2006
01 Mar - 31 Mar 2006
01 Feb - 29 Feb 2006
01 Jan - 31 Jan 2006
01 Dec - 31 Dec 2005
01 Nov - 30 Nov 2005
01 Oct - 31 Oct 2005
01 Sep - 30 Sep 2005
01 Aug - 31 Aug 2005
01 Jul - 31 Jul 2005
01 June - 30 June 2005
01 May - 31 May 2005
01 Apr - 30 Apr 2005
01 Mar - 31 Mar 2005
01 Feb - 29 Feb 2005
01 Jan - 31 Jan 2005
01 Dec - 31 Dec 2004
01 Nov - 30 Nov 2004
01 Oct - 31 Oct 2004
01 Sep - 30 Sep 2004
01 Aug - 31 Aug 2004

Stuff

Powered by Pivot  
XML: RSS feed 
XML: Atom feed 

§ 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:

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.
Name:  
Remember personal info?

Email (Optional):
Your email address is only revealed to the blog owner and is not shown to the public.
URL (Optional):
Comment: /

An authentication dialog may appear when you click Post Comment. Simply type in "post" as the user and "now" as the password. I have had to do this to stop automated comment spam.



Small print: All html tags except <b> and <i> will be removed from your comment. You can make links by just typing the url or mail-address.