Updated: May 5, 2020
vGPU technology from Nvidia gives you the capability to share videocard resources in an environment on a very interesting scale. The Nvidia GRID cards were available in K1 and K2, capable of hosting respectively 32 and 16 VM's on a dual width PCI-E card. With the new M10, M6 and M60 these numbers have even doubled. The windows OS however has also been coming out in new versions, and changing the necessary resources. Initially, these new cards were very interesting as they doubled the amount of VM's per desktop. The Windows OS requirements however, certainly with Windows 10, are becoming graphically intensive. The big difference is the GUI itself, this now expects DirectX acceleration to be available. Windows 7 and Windows 8 did not have a shell that really took benefit from graphical acceleration.
Not too long ago, Nvidia posted a very interesting blog entry about the sizing of your vGPU profiles in combination with Windows 10 based VDI desktops. To clarify, the vGPU profile is related to the virtual hardware (the videocard) you add to your virtual machines. This profile gives a VM access to the GPU on the hypervisor below, and grants a certain amount of vRAM, depending on the profile used. This vRAM is dedicated to the specific VM, while the GPU usage itself is based on a timesharing principle. In the screenshot below, A grid_k120q profile is added to a vm, granting 512 MB vRAM based on the Nvidia GRID K1 card in the concerning server:
These vGPU profiles on all the GRID cards have a minimum of 512 MB, this constitutes the smallest profile available. Sizingwise, this is the most interesting one, as it allows you a maximum number of desktops per Nvidia GRID graphics card. There is however a serious caveat when using Windows 10 in this combination, as it is quite vRAM hungry, especially when you use more than 1 monitor.
The Nvidia Blog entry states a couple of situations in which the smallest profile granting 512MB would not be enough for a descently working desktop:
More than approx. 5 applications; WebGL content, video streaming, and flash applications
Higher than 1920 x 1080p resolution
2 or more monitors
In the vgpu-profile-sizing-guidance-for-windows-10, there is also mention of this, as well as a table showing the difference in framebuffer (vRAM) usage between the two lowest profiles of the GRID M10 card. One with 512MB (the M10-0B), and one with 1GB (the M10-1B). Depending on the application load, the dual screen setup uses more than the 512 MB available in the lowest profile, which could potentially lead to issues:
What is also clear from this test scenario, is the huge difference between Windows 7 and Windows 10. The real problem starts when you apply some load in the form of application usage to the desktop with the M10-1B profile using 2 monitors; the load goes way above the available vRAM in the lowest profile (664 MB) and could have an impact on the applications.
I will be testing this in our own environment and will be continuing this post when I have some more real world information. To be continued...
So, in contrary to the documentation which clearly stated 2 display heads, both on the K140Q and K120Q:
Our Windows 10 installation (1607 ltbs) in combination with a K120q profile is in fact limited to 1 display head. This setup is based on the newest vGPU driver pack available, Windows Display Driver (370.12) and GRID vGPU Manager (367.106). When trying to start the VMware view session in multimonitor mode, this results in a black screen on both monitors. When reconnecting with a full screen option, the desktop connects fine and was apparently already running, since it reconnected to the already running session. When adding a K140q profile to the same desktop, the multimonitor setup works like it should.
The framebuffer usage when idle isn't very high and doesn't go that much higher on use. Below is the timeline of opening a fullscreen youtube video in Chrome, a couple of Microsoft Office applications and some other assorted programs such as a PDF viewer application:
The same test, but with the programs spread out over the two screens gives us the following:
What is noticeable from the start, is that in the desktop with 2 monitors, the GPU usage is roughly twice as high as the one with the normal desktop. This would seem logical, as there are twice as many pixels to process.
Although the test is a fairly simple comparison, based upon what i'm seeing I'm still convinced that in certain light use cases such as normal office work, the 512 MB profiles should be a good fit for the use case, either with one or two monitors. The use cases for applications that are really GPU hungry such as CAD/CAM and other 3D or rendering programs is of course very different and have no place in an office desktop. Here's to hoping that this limitation is based on the fact that the card in my test is an older GRID 1.0 version, the K1 and that the Grid 2.0 M10 does not have the same limitation. To be continued...
What is now confirmed, Nvidia have taken the dual screen capability away from vGPU and Windows 10 when using the 512 MB framebuffer, due to the fact that they have seen to many problems arise from it. In fact, the new Pascal based cards do not even have a 512 MB framebuffer size available, the smallest profile will be 1GB.
This does have a serious impact on sizing your desktop environment, especially if you were expecting to migrate to windows 10 on the same hardware. If you are still on the K1 cards, you are looking at a maximum of 16 w10 desktops per card. In case of the M10 card this would be 32 instead of 64, so be very careful if you are sizing your environment with vGPU's and Windows 10!
There is a workaround for a testing/non production environment. There are a number of undocumented options you can add to the advanced options of a VM, enabling this like the disabling of the framerate limiter (which is not supported anymore), but can be found in the grid release notes from a while back: http://docs.nvidia.com/grid/4.0/pdf/grid-vgpu-release-notes-vmware-vsphere.pdf One of them does allow you to use dualscreen setup for a small vgpu combined with Windows 10. If you add a configuration parameter to the VM with the following string:
pciPassthru0.cfg.enable_win10_dual_heads_for_small_vgpu = 1
You can test whether you have framebuffer issues or not in this setup. I have not run into issues for the specific desktop we are testing, which is a fairly straightforward officeworker desktop using only Microsoft Office, a few internet browsers and some CRM software. Testing continues...