RDP and PCoIP graphics accelerated virtualization solutions
This blog post is authored by Ivan Mladenov, Senior Program Manager, RDS/WDG.
Once upon a time getting the content of a computer screen and putting it on the network for a remote access was done entirely in software. The CPU was solely responsible for making sure the app content is rendered, encoded into a video frame, and shipped over the network so a remote user on the other end of the wire can access their desktop and work remotely. The desktops evolution added graphics acceleration, but for a while accelerated graphics was not available to the remote users in a virtual environment. The remote desktop users were restricted to set of productivity applications that did not require GPU.
The advances in the GPU technologies in the past decades changed that. Graphics acceleration became available to desktops and high-end PCs so users can have spectacular gameplay experiences or increased productivity while using high-end computer-aided design applications. The prices for the gamers PCs and CAD workstations rocketed into the sky while more advanced GPUs with more cores and infinitely higher capabilities took over the market. Inevitably democratization of the GPU prices drove the cost down and the GPUs in the desktops became prevalent. Now every app on a modern desktop, laptop, or even a mobile phone can take advantage of a GPU acceleration.
GPU advances completely changed how apps are written and vastly improved the app experiences, however, apps running in virtualized environments were not able to benefit of the presence of a GPU as fast as their desktop counterparts. Many blog posts were written with instruction how to tune apps to run efficiently in virtualized environments. To ensure scalability and performance of the virtual machine many of these posts recommended turning off animations, transparency, clear type and other features that required GPU acceleration. This ultimately achieved the performance and scalability requirements but impaired the user experience. Virtualized apps provided sub-par, and sometimes quite painful, user experience when compared with the same app running on a desktop.
The evolution of the GPUs has advanced enough that a virtual machine can be configured to provide access to physical GPU capabilities to any virtualized application that needs access to an actual physical GPU. There are many different technologies and protocols that can do that, and most of them are already deployed in popular cloud services on Azure, AWS and other hosting providers. However, there are not very many articles that compare the virtualization, remoting, technologies, and protocols that take advantage of graphics acceleration. There are many good reasons for that; remoting technologies are complex to deploy, require quite a bit of knowledge in the space to successfully test, takes quite a bit of time to diligently prepare, properly measure and create a comprehensive report.
Thankfully two experts in the space decided to spend the time and effort to do just that. It has been quite a while since there was an article like that, but Benny Tritsch and Kristin Griffin did an excellent job of comparing two very popular and successful protocols that provide solutions to run virtualized graphics accelerated applications, RDP and PCoIP. Check out the results of their tests and view some of the recorded videos.
The article provides an exhaustive description of the testing methodology and illustrates the findings with text and videos. It does require familiarity with the used remoting technologies and the apps used in the test cases. It is a great illustration of two state of the art remoting technologies available today. The article goes into great details to argue the advantages of the compared protocols and solutions. The tests are done in lab environment with network simulator to isolate Internet unpredictability and create predictable and easy to replicate network conditions. A user can use the prescribed methodology and apps in cloud services like Azure or AWS and make conclusions for themselves in their own test environment.
Source: EM+S Blog Feed