Ran across a problem the other day with a customer who was running a “bleeding edge” Microsoft VDI configuration without a cookbook.

They had a nicely spec’d Dell R730 server running Server 2012R2 Datacenter with Hyper-V/RD-Virtualization, 2 nVidia M60 GPGPU cards and Windows 10 Virtual Desktops.  His initial complaint was that when watching YouTube videos on the Virtual Desktops (VD), the video was choppy and stuttery over Internet Explorer, as if the GPGPU cards weren’t working well, but secondarily – Chrome & Firefox were having severe display problems all on their own, rendering those browsers completely useless.

The customer admitted that they didn’t build out the solution from a cookbook or working document, it was just pieced together based on what his Salesperson had sold him.  We sat down and worked through the configuration of the environment.  Everything looked OK:  Hyper-V installed, RD-Virtualization installed, NIC/nVidia drivers up to date, RemoteFX video enabled on the VD’s.

After having a colleague do some issue reproduction work with the M60’s, we found a problem with the re-engineering and design of the nVidia M60 and GRID 2.0 capabilities.  nVidia was very much ahead of the game with their K1 & K2 GPGPU video cards, being the first to market with something like this, working with OpenGL, Cuda & some DirectX, but unfortunately, it would seem that someone in the Marketing department decided that they were leaving money on the table somewhere.

So, with the release of the new GRID 2.0 generation of GPGPU cards, nVidia had separated the hardware and software functions of the GPGPU cards.  In better terms, the card itself with all it’s processing capabilities, can be purchased and dropped into a server/workstation and used for Compute processing, right out of the box.  However, the GRID 2.0 software piece that manages splitting the very large GPGPU card into smaller WDDM video card slices (via vGPU Profiles) will require a per seat license – meaning that you will have to pay extra for every user that will be leveraging a GRID 2.0 GPGPU.  So, your per seat cost for Graphics Enhanced VDI just went up – exactly how much is still yet to be seen, but initial numbers are around $250-300/seat.  Again, this is only for VDI use of the new nVidia cards.

Unfortunately, the customer’s sales rep wasn’t aware of the new GRID 2.0 licensing and the equipment went out the door with the expectation that everything would work like GRID 1.0.

Research into the Chrome and Firefox issue found some additional interesting problems.  What the customer (and us) saw was the presentation of websites with Chrome & Firefox while leveraging Remote FX/GPGPU was: really bad display, images were chopped up and pieces displayed all over the page, frames to infinity (like when you have two opposing mirrors that are pointed at each other) and just an overall unusable experience.  After doing repro of that issue, to make sure it wasn’t the customer’s installation, we were able to reproduce the same issue.  Doing some checking off the FAQ’s from Chrome & Mozilla, we found that there are problems with the latest versions Chrome & Firefox leveraging the RemoteFX video driver.  There are plans to fix this in their base code, but the only workaround is to disable Video Graphics Acceleration in the browsers, which totally defeats the usefulness (read as: expense) of a vGPU.  So, if you are doing some sort of VDI implementation with Remote FX & video acceleration – stick with Internet Explorer or Edge browsers for the time being.

Chrome display issues with Remote FX discussion thread is here.