| An up-close review of Microsoft RemoteFX in Windows Server 2008 R2 SP1 / Windows 7 SP1 |
| Wednesday, 13 October 2010 by Michel Roth | |||
|
In the upcoming Windows Server 2008 R2 Service Pack 1 and Windows 7 Service Pack 1 Microsoft is introducing a technology called RemoteFX which will prove to be groundbreaking for anyone that knows RDP (which is probably everyone that reads this). In this article we will have a look at what RemoteFX exactly is, what it can do and what it cannot do and how it works under the covers.
Introduction
About 2.5 years ago Microsoft announced that they had acquired a company called Calista Technologies. This company was pioneering the science of virtualizing the GPU. It was very early days, so early even that Calista did not have a shipping product yet. Regardless, Microsoft decided to pick them up to, as it shows today, take RDP to a whole new level.
In March 2010 Microsoft announced a bunch of stuff around desktop virtualization. One of these announcements was the fact that Microsoft will introduce a technology called RemoteFX in Windows Server 2008 R2 Service Pack 1 and Windows 7 SP1. At the core of this RemoteFX is the technology from the Calista acquisition.
What exactly is RemoteFX?
The most common misconception that exists today is that RemoteFX is a new display protocol that will replace RDP. This is not true. RemoteFX is an umbrella term for a set of technologies that will enhance RDP. RemoteFX for example also includes USB redirection technology but that is out of scope in this article. In this article we will focus on the graphical user experience enhancements that RemoteFX brings to RDP 7.1 (the RDP version in Windows Server 2008 R2 Service Pack 1 and Windows 7 SP1).
When we’re talking about the user experience enhancements of RemoteFX, it’s important to distinguish between two distinct scenarios. That’s because there will be an implementation of the user experience enhancements of RemoteFX for VDI and one for Remote Desktop Session Hosts (RDSH). As we discuss these scenarios you will find out why they need to be treated separately somewhat.
RemoteFX for VDI (RD Virtualization Host)
This typically is what people are referring to when they talk about “RemoteFX”. At the core of RemoteFX for VDI is the ability to virtualize the GPU and share it among many users (or more accurately, virtual desktops). This ability to virtualize and share the GPU allows RemoteFX to deliver an unprecedented user experience with RDP unlike anything you have ever seen before with RDP. With RemoteFX the entire “content” of the desktop is rendered on the host utilizing that virtualized and shared GPU (and CPU/ ASIC as I will explain later). This “content” I am referring to is everything that is displayed during your Windows session, the desktop, web pages, HD movies, CAD, Silverlight, Flash and basically anything else you can think of.
There are three key aspects to RemoteFX for VDI that you need to keep in mind.
- The virtualization and sharing of the GPU is a feature that is only available on Windows Server 2008 R2 Service Pack 1 with Hyper-V Role enabled. Actually, it is a new part of the RD Virtualization Host role. So given the current incarnation of RemoteFX, RemoteFX will not work on other hypervisors – that means no VMware ESX and no XenServer.
- RemoteFX for VDI does require a physical GPU in the physical Hyper-V R2 SP1 host.
- Windows 7 SP1 is the only supported Guest OS (the virtual desktop) if you want to use the user experience enhancements of RemoteFX.
RemoteFX for Remote Desktop Session Hosts
What is very special about the graphical user experience enhancements of RemoteFX is that they also will be available for Remote Desktop Session Hosts (RDSH). The big difference is that this will not require a GPU. In fact, the whole GPU virtualization and sharing technology is absent in this implementation. The way content will be rendered and encoded is by means of the CPU (or an ASIC).
How does it work?
Now that we know that RemoteFX is able to deliver an extremely rich user experience with RDP by rendering all content on the host, let’s take a look at how this works under the hood.
RemoteFX for VDI
First, let’s take a look at RemoteFX for VDI since this is the implementation with the most “moving parts”. This is the architectural diagram of RemoteFX for VDI:
In this architectural diagram there are the following components:
(1) A VGPU driver. This driver presents the GPU to the virtual desktop. The virtual desktop (or more accurately the application in the desktop) does not know any better than that it has a dedicated GPU. The applications just send display commands to the GPU like they would on a regular physical desktop that is equipped with a GPU. The vGPU driver then takes these commands and sends them to the RCC via the VMBUS and Shared Memory. This is the GPU that you will see inside the virtual desktop:
(2) The RCC component is a process that runs in the parent partition per RemoteFX enabled virtual desktop that is responsible to actually process the content request from the applications. RCC stands for Render, Capture and Compress and this is exactly what it does:
- First the “raw display instructions” are received from the vGPU driver and the content is rendered on the GPU (â¸)
- Second the rendered content is captured. This means that RemoteFX will actually look at the frames that are being generated. It does so by dividing the screen into rectangles and watching which rectangles have changed and only selects those for transport. What is also very interesting is that the capture process also communicates with RDP to see if the client is able to process all of the display information. It might not be able to “take in” all of this display information because of limitations such as the network, client buffers, etc. If this is determined, the capture process will adjust accordingly and will actually send fewer frames. This happens all the time so you could call RemoteFX auto-optimizing in that sense.
- Finally, after it has been decided which frames to send, the content is compressed and encoded. There are two ways to this. One is what Microsoft refers to as the software solution and this is using a combination of the GPU (3) and the CPU. The second way is to offload this to something called an ASIC (â4). This is a special chip specifically built to encode the display data coming from the RCC. The ASIC can provide offload capabilities for the encoding, but it is not mandatory; in contrast, since the GPU is used for rendering, it is mandatory. The big advantage of having an ASIC is that it relieves the GPU and CPU from encoding tasks, thus improving the scalability of the Hyper-V VDI host.
RemoteFX for Remote Desktop Session Hosts (RDSH)
When we look at RemoteFX for Remote Desktop Session Hosts (RDSH) it is a little different. As I mentioned earlier, this incarnation of RemoteFX does not support using a GPU in the Remote Desktop Session Host. Instead, this work is done by the CPU. Here’s how things work from an architectural perspective on a Remote Desktop Session Host:
Also the in the RDSH RemoteFX scenario, an ASIC can be used. In fact, it makes a lot more sense to consider investing in the ASIC in the RDSH scenario to offload the encoding because the CPU is generally much more heavily loaded than for VDI because of the higher number of sessions per host and lack of GPU which is used to offload the CPU for encoding in the case of VDI.
Client Devices
As I stated earlier, RemoteFX is not a replacement for RDP but rather different content in the RDP display channel. This is clearly shown in this overview of the RemoteFX architecture from a client perspective:
So, if you want to enjoy the richness of a RemoteFX experience you will need a RDP Client that is capable of decoding the RemoteFX payload. As the architecture shows, there’s two ways to go about this.
The Ecosystem
Don’t worry; I am not trying to make a case about our changing climate. I am referring to the ecosystem around RemoteFX. Let me explain. Previous iterations of Remote Desktop Services, or RDP more specifically, traditionally have had a relatively low impact on the RDP ecosystem of partners. With RemoteFX this is significantly different and Microsoft is very aware of this. There are a couple of reasons why it is different when it comes to RemoteFX:
Miicrosoft wants to make sure that it is easy as possible to get a RemoteFX-capable piece of hardware. Whether that is a server with a proper GPU and potentially an ASIC or whether it is a client device with a RemoteFX ASIC, it needs to be perfectly normal.
In theory this means that in the RemoteFX timeframe (when SP1 is released) when you order a new server you will just be able to check a box that will add a RemoteFX capable GPU and potentially an ASIC.
It is even cooler for client devices – all you really need is a RemoteFX decoder. These hardware decoders (ASIC) are relatively cheap to produce and have a very low system footprint. They enable a whole new line of client devices. One new type of client device is called an “Ultra Lightweight Thin Clients” (no I did not make that up but it made me think, what’s next, Sub-Zero Clients?). These are very interesting devices that can use as little as 3 Watts of power and are rumored to be available at as low as $100 when launched! Imagine that – a full fidelity user experience on a $100 device! It does not stop at Thin Clients. The ASIC could easily be embedded in other devices as well. Think about monitors, TVs, tablets, phones… heck, even an XBOX could have such an encoder.
Of course a lot of the success of RemoteFX enabled client devices depends on acceptance by hardware manufacturers. Microsoft knows this and has made a very clever move in my mind: anyone can make an ASIC. Let me explain that: if you sign up as a RemoteFX partner you can get the specifications of the RemoteFX decoder and create your own ASIC. The key thing is that this is royalty free. Where other comparable solutions ask for a fee for every ASIC sold this is not the case with RemoteFX.
What can it do?
Anything! Well, from a display perspective at least. This is the really cool part. Since to the virtual desktop and its applications it appears that a “normal” GPU is available, almost all content can be rendered. RemoteFX is like a catch-all. Basically all kinds of “desktop content” can be viewed in near full fidelity in your virtual desktop.
For reference, these are examples of content that currently aren’t able to be delivered in full fidelity in today’s RDP version (7.0):
RemoteFX solves all that … if you have the bandwidth. Again, because it is catch-all you can deliver almost any content type using RemoteFX. Think of content like this:
What’s less cool?
Of course RemoteFX isn’t the most brilliant thing since the seedless watermelon but it is pretty darn close! There are a couple of characteristics – I would not call them drawbacks – which you have to be aware of though:
Conclusion
Many people complained that Microsoft took too long to implement the Calista technologies into what was clear from the first minute- RDP. I personally think that Microsoft wanted to wait until all the pieces were in place to start yet another game of chess (or a more violent sport) with their good friends VMware. These pieces are not only assimilating the Calista technologies into Windows but also building the RemoteFX Ecosystem. They even decided to include a major feature as big as RemoteFX into a service pack which is pretty uncommon for Microsoft.
If it wasn’t clear, RemoteFX is (in many ways) Microsoft’s answer to PCoIP. In fact, in the same announcement that talked about RemoteFX, Microsoft also announced another feature of Service Pack 1 called “Dynamic Memory”. Dynamic Memory could be perceived to be as a countermove against VMware’s “memory overcommit”, which many people agree is one of the big things lacking in Hyper-V today. The comparison is very interesting, but beyond the scope of this piece.
Regardless of what Microsoft wants to achieve with RemoteFX (or Service Pack 1 as a whole) RemoteFX will have a great impact on desktop virtualization. It will change the way we buy servers, it will change the client devices we buy (and why we buy them) and it will change the “RDP user experience”. I am not saying it will happen overnight but in time it will happen.
A question that I get a lot as well is if I think if RemoteFX will replace all other remote display protocols such as Quest EOP or Citrix HDX. I think RemoteFX will not replace these protocols. Even though there is some overlap – in particular, RemoteFX is similar to Citrix HDX 3D Pro – Microsoft has created an ecosystem around RemoteFX that allows for partners to embrace and extend RemoteFX. It is much more likely that RemoteFX will be supported by protocols from these, and other, vendors, who will continue to extend and enhance Microsoft’s Remote Desktop platforms.
Show/Hide comment form
|
|||
