Do your users need to run Google Earth from a virtual desktop? If so, then you need to download and test the new Google Earth Optimization Pack for XenDesktop 5.5.  The Google Earth Optimization Pack is available to all Enterprise and Platinum XenDesktop 5.5 users.  The best part about this Optimization Pack is that it has no server and no client side GPU requirements!  It will work on XenServer, Hyper-V, and vSphere and will work with any Citrix Receiver (ICA Client) that can connect to XenDesktop 5.5 You can download it from the link below.

http://support.citrix.com/article/CTX131167.

So why do we need an Optimization Pack for Google Earth?

First, if you are using an HDX 3D Pro enabled virtual machine or RemoteFX, then you do not need the Optimization Pack for Google Earth as you already have a dedicated GPU for rendering.  However, HDX 3D Pro is currently a one GPU to one virtual desktop solution and RemoteFX requires Hyper-V and Windows 7 end points.  Using HDX 3D Pro, if you are a school and plan on having hundreds of students accessing virtual desktops, you would need a dedicated GPU for each desktop.  Do you want to run 50 virtual desktops on a single server? Then you would need to find a way to connect 50 GPUs to that server!  HDX 3D Pro is a great solution for high end 3D users, but it can be a costly solution if all you want to do is deliver Google Earth to a large number of users.  For some more info on HDX 3D Pro, check out the recent blog from Derek Thorslund.

http://blogs.citrix.com/2011/09/06/hdx-3d-pro-takes-another-leap-forward/

Google Earth is a graphically intense application that needs to be able to perform 3D rendering.  There are two different rendering modes available when running Google Earth; Open GL and DirectX.  The preferred and most efficient method for running Google Earth is DirectX.  In DirectX mode, Google Earth will pass all of its rendering commands to the DirectX subsystem, which will automatically make the most effective use of the graphics card to perform rendering operations.  If you run Google Earth in OpenGL mode, you often end up emulating all of the OpenGL commands in software on the CPU; unless of course you actually have a high end GPU that truly and fully supports OpenGL.

Excluding the HDX 3D Pro scenario, when we run Google Earth inside of a virtual desktop hosted on a hypervisor, there is no GPU to use, thus all rendering ends up taking place on the CPU of the hypervisor.  Since Windows has a built capability for rendering OpenGL using the CPU (opengl32.dll), this is the method in which Google Earth must be run inside of a virtual machine.  Needless to say, trying to use Microsoft’s generic software based implementation of OpenGL on the CPU of a Windows virtual machine does not perform all that well.  It does not mean that it will not work; it only means that its performance is limited.  We have many customers that have successfully run Google Earth in OpenGL mode. In fact, I wrote a recent blog about how HDX Progressive Display can improve Google Earth and other graphically intensive applications.

http://blogs.citrix.com/2011/05/30/hdx-progressive-display-dont-forget-to-turn-it-on/

So why can’t we open Google Earth in DirectX mode on a virtual machine?  The short answer is that most emulated hypervisor video drivers do not support the DirectDraw or Direct3D APIs. Although I must admit that VMware with the recent release of vSphere 5 has enhanced its guest graphics driver to support DirectX 9.  However, at this time we cannot broker ICA connections to guest operating systems that use their new driver.   This means that we are limited to running Google Earth in OpenGL mode.

SwiftShader to the Rescue!

Just as OpenGL commands can be emulated in software on a CPU, it is also possible to emulate DirectX in software on a CPU.  In fact there is a company called TransGaming that has produced some extremely efficient and multi-threaded/parallel processing emulators for DirectX.  Citrix has partnered with TransGaming to make their advanced DirectX9 SwiftShader engine available for use with Google Earth.  By simply placing the D3D9.dll into the directory where GoogleEarth.exe is located, it will enable Google Earth to be opened in DirectX mode from any virtual desktop.  The rendering of the 3D within Google Earth will still be occurring in software running inside of the guest operating system and therefore on the CPU of the hypervisor.  However, this software renderer is highly optimized and provides significantly better performance when compared to the software based OpenGL renderer.

Configuring SwiftShader

Installing and enabling SwiftShader couldn’t be easier as all you need to do is copy the D3D9.dll file into the same directory as Google Earth and configure Google Earth to open in DirectX mode.  You can configure Google Earth to use DirectX mode by launching the “Start Google earth in DirectX mode” shortcut from the Google Earth folder on the Start Menu or by selecting Tools/Options from the menu after Google Earth is open and enabling DirectX as shown below.

There are several configurable options for how the DLL handles rendering.  The configuration for the DLL is located in a file called SwiftShader.ini, which will be located in the same directory as the DLL.  You do not need to manually create or install the ini file.  When you download the Optimization Pack, you will notice that there is no INI file included in the download.  This is because once the SwiftShader engine is engaged; it will automatically create the INI file using default values if it does not already exist.  One thing to keep in mind is that if the user running Google Earth does not have change permission to the Google Earth directory and the file does not already exist, then the file will not be created and the DLL will just operate with the preprogrammed default configuration.  Of course, if you are delivering Google Earth as a Streamed Application, the INI file will get created in the user’s RadeCache folder.

There are two methods for configuring the INI file with the first being the good old fashion method of editing it with notepad.  The second way to configure the INI file is to use a built in web utility that the DLL runs when it has been engaged.  This means that once Google Earth has been opened in DirectX mode, you can open a browser and connect to http://127.0.0.1:8080/swiftconfig. A screen shot is below.

There are two key values that are of note as highlighted in the screen shot below.

If you do not want this GUI web configuration applet to run when SwiftShader is in use, then you can check the box for “Disable SwiftConfig server”.  If your users have multiple monitors and you want Google Earth to be able to run on monitors other then the primary monitor, then you must change the “Frame-buffer API” from DirectDraw to GDI.  If you just want to manually pre-configure these two options by editing the INI file, then you would locate and edit the two lines under the Testing section as follows:

DisableServer=1

FrameBufferAPI=1

As a final consideration, you need to give your virtual desktop 2 vCPUs in order to effectively use the Google Earth Optimization Pack.  It will technically work in a VM with 1 vCPU, but it will perform poorly.

Bandwidth Considerations

Google Earth is a graphically intense application and as such it does require quite a bit more bandwidth than the traditional 20 – 40 Kbps that you typically need for office productivity applications.  Also, because the SwiftShader DLL is able to push higher frame rates then the OpenGL emulator, Google Earth in DirectX mode will be generating a greater amount of pixels that need to be sent over ICA.   For this reason, users will get the best performance when on a LAN or high speed WAN.  However, it can be successfully deployed over more modest WAN links such as DSL when the proper Progressive Display or new Adaptive Display policies are configured.  I will be posting a new blog on Adaptive Display and how it can benefit Google Earth after I present on the topic at Synergy in Barcelona next week, so stay tuned!

Finally, I have recorded an 8 minute side-by-side demo and posted it to YouTube that shows two virtual machines running Google Earth; one with the Optimization Pack and one without.  Keep in mind that the video conversion process does not fully show the true fidelity that was display on my laptop when I recorded it, but it still shows the contrast between the two fairly well.  It is best viewed full screen and at 720p.

http://www.youtube.com/watch?v=pcB_S828bQk

Not only does the Google Earth Optimization Pack make Google Earth look better, it also makes it much more responsive.   When you are spinning the globe or manually scrolling around a zoomed in map, the performance is significantly smoother.

If you are a XenDesktop 5.5 customer and need to use Google Earth then I highly recommend that you download the use the Google Earth Optimization Pack!  Let me know how it works for you!

Cheers,

-Dan Allen