One of the major announcements from Microsoft last week was that the technology they acquired from Calista back in 2008 would be known as "RemoteFX" and released via Service Pack 1 for Windows 7 and Windows Server 2008 R2. Last week I wrote an overview and recorded a video demo of RemoteFX, but those two pieces just started to scratch the surface. In today's article I'll dig deeper into RemoteFX, focusing specifically on the role the CPU, GPU, and custom chips play in host, client, TS, and VDI scenarios.
Microsoft designed RemoteFX to be flexible, allowing a combination of CPU, GPU, and custom chip-based encoding and decoding. Any combination of host and client encoders and decoders are inter-compatible, and there's absolutely no difference on the network between the different methods of encoding or decoding.
RemoteFX on the host
Since RemoteFX is just an enhancement to RDP, it stands to reason that Microsoft will enable it in both of their major RDP host scenarios: RD Virtualization Host (VDI) and RD Session Host (Terminal Server).
RDVH / VDI
For the VDI scenario, RemoteFX requires a GPU on the server. This GPU is then virtualized (a new capability of Hyper-V in 2008 R2 SP1) and presented to each VM just like any physical hardware component. What we don't know at this point is how many VMs a single GPU will be able to support. Microsoft has said that they'll eventually come out with sizing guidance and pointed out that the sizing is not based on VMs but rather the number of screens and pixels a specific GPU can support. And of course you'll be able to add multiple GPUs to each physical server, either via the PCI riser card in the server chassis or via external PCI chassis that could house lots of cards.
One advantage of the GPU add-in card is that it allows RemoteFX encoding on remote hosts that doesn't have a major negative impact on the performance of individual VMs or overall server density. (Certainly this was evident in the video where we saw six simultaneous Windows 7 VMs running video via RemoteFX with almost no practical impact on server CPU.)
In addition to the pure GPU(s)-based encoding option, Microsoft has also built a hardware design for a custom chip that could land in a server via an add-in card that's specifically built for RemoteFX encoding. (More on this custom chip later.) What's not clear to me at this point is if the custom add-in card is in addition to a GPU or replaces it. Either way we can assume that the custom card will provide more bang for the buck than the GPU option (since that's kind of the whole point of custom silicon).
RDSH / TS
For RDSH /TS use case, a GPU is still required, but Hyper-V not. (interesting!) We can only assume this is due to the fact that every RDSH session has access to the physical hardware, so you don't need to virtualize the GPU to make it available to more than one session. (If that's true then we can probably also assume you can only get RemoteFX on virtual RDSH servers if they're running on Hyper-V since other hypervisors wouldn't present the GPU to the VM.)
By the way, Citrix has gone on record to say that they will support RemoteFX on RDSH via HDX to XenApp, although they're not able to provide any more details at this time other than saying, "yes we're planning to support this."
It's not known whether Microsoft will support RemoteFX on physical hosts with GPUs. At first you'd think "Who cares? What's the use case for that?" But in addition to being a sweet home media center solution, supporting a "standalone" RemoteFX will potentially open the door to people running Windows 7 RemoteFX hosts on VMware ESX if VMware ever decides to virtualize the GPU.
RemoteFX on the client
RemoteFX clients can come in many different forms. Right off the bat there will be a new version of the RDP client which will enable RemoteFX for Win32 clients, including full PCs and Windows XP Embedded "thin" clients. We also saw clients with the custom chips—one based on WinCE and one based on Linux. All the major thin client vendors (including HP, Wyse, and DevonIT) have expressed support for the protocol.
Understanding the RemoteFX "custom chip" ASIC
We've mentioned that RemoteFX can use a custom chip (called an "ASIC") on both the encoder and decoder side. This is conceptually similar to Teradici's implementation of PC-over-IP but with one main difference. Teradici sells chips to hardware partners that they put into their own products. Microsoft has merely designed the chips which they'll license to partners to be implemented in whatever ways the partners see fit.
In practical purposes this means that while Teradici PC-over-IP chips are dedicated standalone chips, RemoteFX hardware will probably end up being built-in to other things, like System-on-a-Chip (SoC) products.
In the microchip world, it's all about gates. (Like how many gates does this take or does that take.) Chip manufacturers know how big their gates are and how big their chips are, so a SoC vendor might say, "Hey, we have enough extra real estate on our chip to add the additional gates needed to let it do hardware RemoteFX decoding." So ultimately RemoteFX is NOT another chip—it's just the manufacturing process of engraving some more parts into SOCs that probably have the room anyway.
By the way, Microsoft doesn't come out and say that RemoteFX needs x number of gates because the actual number can vary drastically based on implementation. So a SoC that supports two displays will need more chips than one that supports a single display. And that's really the cool thing about the RemoteFX chips. How many sessions will a RemoteFX card support? How many displays and pixels? Is it built-in to a TV, a SoC, or a standalone card? Is it built-in to a server? This is all up to the specific implementation choices of the hardware vendors.
Differences between RemoteFX and VMware's PC-over-IP
The main difference is on the host side, since RemoteFX requires a GPU or custom plug-in card. This is something that VMware blogger Mike Coleman jumped on immediately, claiming that customers don't want to install GPUs into their servers. This is something that remains to be seen. I mean sure, no one has GPUs in their servers today, but that's because there's never been a reason too. And VMware's software-based host encoder for PC-over-IP is CPU intensive and affects user density in a big way. (i.e. If you enable it, you get fewer users per server.) So in VMware's world you don't have to install GPUs in your servers, but you have to build extra servers to make up for the density you lose by encoding PC-over-IP on the CPU?!?
At this point we don't know which will ending up being the biggest impact in terms of cost, power, and rack space, but I'm sure we'll know soon enough.