I've been traveling the world the past few months delivering seminars on desktop virtualization, and one question that's popped up a few times is about Citrix HDX 3D versus Microsoft RemoteFX. People want to know which one is better? The answer is (of course) "it depends," because while HDX 3D and RemoteFX both leverage host-side GPUs, they're actually different technologies used for different purposes. So in today's post, we'll dig into how they each work and why you'd choose one or the other.
Let's first take a look at each of the technologies:
Citrix HDX 3D Pro
Citrix HDX 3D Pro is a technology that's used to deliver high-end graphics applications running in the datacenter to normal users out in the field. HDX 3D was first released in 2009, with a 1.1 update released earlier this year. The current version of HDX 3D Pro supports host-side apps on XenDesktop that require either OpenGL or DirectX. These apps use the host-side GPU for their normal activities just like they would in any regular workstation environment. The idea with HDX 3D Pro is that after the app uses the host-side GPU and renders its final output, HDX 3D kicks in to compress the rendered output and send it down to the client.
This is similar to the way that normal HDX works, although HDX 3D Pro actually hooks in a bit later in the pixel pipeline process to let the app and the GPU do what they need to do. (In this case the HDX 3D engine is a bit more like true "screen scraping" versus normal HDX which hooks into the window manager a bit earlier.) Now what's interesting is that because compressing pre-rendered graphics is pretty intense, HDX 3D also has the option to use that same GPU to help with the HDX compression process. (So in this case, the host-side GPU is working double-duty, both for the app to generate its output and for the HDX 3D process to compress the pixels.)
Then on the client side, if you have a Win32 client with Citrix Receiver online plug-in 12.0 or greater, the client receives the GPU-compressed screen updates and renders them like normal.
The Citrix Receiver for Linux client also supports HDX 3D, although it doesn't support GPU-based HDX 3D Pro compression. So when a Linux client is used, HDX 3D Pro still works, it's just that the actual pixel compression is done via the CPU on the host and not the GPU. So with the Linux client, you still need a GPU on the host, but that GPU is only used for the normal OpenGL/DirectX app stuff, and the CPU is used for the compression.
In other words with HDX 3D Pro, you always need a GPU in the host for the OpenGL / DirectX stuff, and then with Windows clients the GPU also helps with rendering.
The other interesting aspect of HDX 3D Pro is that there's currently no way for a server to share a single physical GPU across multiple VMs, so up to this point, HDX 3D Pro is limited to blade or rack-mounted workstations that each have their own physical GPU. XenServer 5.6 introduced experimental support for GPU passthrough, however that's limited to a one-to-one physical-to-virtual passthrough. (So if you have a server that can take four GPUs, you can run four VMs with HDX 3D, each with its own physical GPU.)
I'm sure we'll see a point in the future where a GPU in a physical host can be sliced up to provide a virtual GPU to multiple VMs, thereby tricking each VM into thinking it has a GPU and thus the ability to run OpenGL and Direct3D apps, but we're not there yet. So the bottom line is that with HDX 3D today, it's really a solution for delivering OpenGL / Direct3D apps via HDX to remote users. It's not a general-purpose solution.
HDX 3D Pro 1.1 supports 32-bit and x64 hosts running Windows XP SP2 or Windows 7. Citrix claims a "usable" experience with 1.5mbps and 300ms latency. In LAN environments they claim that HDX 3D Pro can deliver a full experience in 1/10th the bandwidth as competing solutions. (I think they mean "PCoIP" when they say "competing solutions.) If you want to also use the GPU for compression (i.e. with Windows clients), then you need an Nvidia graphics card with at least 96 cores with CUDA support.
We've written quite a bit about RemoteFX over the past year. You probably know that RemoteFX (a new feature of Windows 7 Service Pack 1 and Windows Server 2008 R2 Service Pack 1) also uses host-side GPUs to render pixels on the host to provide good graphics to clients. In the case of RemoteFX, Microsoft is using the hosts GPU as a super fast compression engine to allow them to deliver a full local-like experience from remote Windows 7 hosts running on Hyper-V. RemoteFX is a general-purpose thing that applies to all applications--it has nothing to do with OpenGL or Direct3D.
Enabling of RemoteFX on a remote host is a feature of Hyper-V running on 2008 R2 SP1. It's not available on other hypervisors or physical desktops. (Well, there's also a software-only version of RemoteFX for Terminal Server 2008 R2 SP1 hosts, and I guess you could deploy one Terminal Server per user if you wanted to "hack" it for physical access.) RemoteFX also requires the guest to by Windows 7.
The other thing to keep in mind about RemoteFX is that it's a platform feature which will be available to Microsoft partners. We've already played with a pre-release version of Quest vWorkspace running RemoteFX (video), and Citrix will support RemoteFX via XenDesktop as well. Of course that doesn't change the fact that RemoteFX is Hyper-V only, so if you want your vWorkspace or XenDesktop environment to use RemoteFX, then it's got to be running on Hyper-V. (It's too bad that Citrix is also releasing some cool XenServer-only features like IntelliCache, as that will make it more difficult for customers to choose their hypervisor.)
Right now RemoteFX is a LAN-only solution, although companies like Quest (and perhaps Citrix?) will enhance it to work over certain WAN connections.
Choosing HDX 3D Pro or RemoteFX
Now that we've laid out the ins and outs of each technology, the use case for each should be clear. HDX 3D Pro is really about delivering good 3D and specialized app (OpenGL, etc.) performance from physical hosts in the datacenter across a LAN or WAN, whereas RemoteFX is meant for general purpose use (Aero, videos, etc.) from virtual desktops running on Hyper-V over a LAN.
Of course since XenDesktop also runs on Hyper-V, if you use it then you'll be able to mix-and-match both HDX 3D Pro and RemoteFX as needed
What about PC-over-IP?
Even though this article is about HDX 3D Pro versus RemoteFX, we should also address how these both compare to PC-over-IP. (Well, in the context of this conversation, we're talking about using VMware View with PC-over-IP.)
From an architectural standpoint, PC-over-IP is more like RemoteFX than it is HDX 3D. Like RemoteFX, PC-over-IP is meant for general purpose use (videos, etc.) with virtual machines, although unlike RemoteFX, PC-over-IP doesn't require a GPU in your VM host. [Clarification update: no GPU in your remote VM means that PCoIP doesn't work with apps that require GPUs for VM-based remote desktops.] And PC-over-IP is also supported for WAN connections, whereas RemoteFX will be LAN-only in this first release.
But PC-over-IP shares some similarities with HDX 3D Pro too, since you can also put a Teradici card into a physical blade or workstation PC which can then be integrated into your View environment.
Of course since PC-over-IP on a VM is limited to VMware View, that means it's also limited to VM hosts running on vSphere / ESX.
So really the choice is clear in terms of requirements. The requirements matrix can get pretty complex (based on specific remote host, VM host, and hardware requirements), but hopefully this gets you pointed in the right direction. It's also worth noting that the whole notion of delivering great graphics remotely is a fast-changing area. RemoteFX is not even out yet. Teradici has started demoing hardware cards that can share Terachips across multiple VMs. And all three hypervisor vendors are working on solutions to share GPUs among multiple guests. I guess the only thing we know for sure is that this area will change fast, so stay tuned!