If I understand correctly, a VM that connects directly to a GPU using GPU passthrough will use the driver associated with the GPU to generate the output, but still needs some sort of local video configuration to be able to create the output plus in cases where there is no support for the protocol, the local instance has to take over the job itself of creating and displaying the video output. Or is no local video driver involved if the GPU is leveraged directly?
With something like a XenApp server using a GPU, it would appear to be a similar case, but since the connection is being brokered in a sense by the XenApp server, could someone please explain the path the data take and what differences, if any, exist in the process of creating and ultimately producing the display on the client side? I am trying to sort out what differences may exist in the data flow and where efficiencies differ. Thanks in advance!
It’s a question that’s best answered by the different VDI vendors, as how they handle the information once it’s lifted from the FrameBuffer will depend on their protocols, encoders etc.
At the top level though
Citrix and VMware can (and do) both read pixels directly from the framebuffer bypassing the need to draw the display and scrape it, this gives them an increase in performance since this takes around 1ms to complete. This is available to any vendor that wants to make use of the GRID SDK btw, so it’s not proprietary.
XenApp does shim the driver with a Citrix adapter allowing them to offer their additional functionality but again they can read directly from the framebuffer, whereas RDP/RemoteFX doesn’t read from the FB it handles the flow differently (they publish their spec here [MS-RDPRFX]: Remote Desktop Protocol: RemoteFX Codec Extension | Microsoft Docs )
I don’t believe that either Citrix or Teradici (owners of PCoIP) publish the details of exactly how their protocols capture images and the flow out from there.
Thank you, Jason. I ask because we seem to not be able to get the following to work:
XenServer 6.2
XenApp 7.5 or 7.6 running on Windows 2012 R2 (neither one works)
GRID K1 or K2 (same error on eithe ror) in GPU passrthrough mode (*)
Windows 8.1 VM client talking to XenApp running on the XS 6.2 server
The Unigine "Heaven" benchmark runs great under openGL on the Windows client, but starts up and bombs shortly thereafter with either DirectX 9 or 11. Is this an OS support question or some sort of misconfiguration? I really believe we had this working before under Windows 2008 R2. I can try to capture the error message. There was some discussion about this at https://gridforums.nvidia.com/default/topic/315/nvidia-grid-drivers/xendesktop-grid-environment-blue-screening-on-directx-driver/ and I didn’t see a resolution.
Thank you again,
*) Only one of these is installed at any given time in the server, of course.
Very odd as it 's exactly what I had running in the lab when I took that screen capture.
Unfortunately my lab server is out having a replacement mainboard fitted so it’ll be a while before I can get to checking again, but my config is the one I used to record the config checks video, so you can use that for comparison to your environment.
It’s possible something’s gone awry in the install of Unigene, and you also have to specify the resolution you want to run at to match that of the client display, some of which the app doesn’t seem to like, so I often run it windowed instead as in the screenshot.
I’ve got some video of Unigene Heaven running in XenApp on 2012 though I’ve not posted it as I’ve not had the time to do the voice over yet, but if you really need to see it working I’ll post it without audio.
Great video, Jason!
So if I try to run Direct11 in any resolution, full screen or not, in any imagineable combination, I get errors like these:
D3D11Render:D3D11Render(): Unknown GPU
D3D11RenderSTate: flushStates(): can't create rasterized state
... and a number of additional can't create this or that errors ...
Direct3D11: error: create2D(): can't create RGBA8 1280x720 2D texture
and so on. Things work fine with openGL, so it’s something specific to DirectX (fails with both 9 and 11).
We will review the settings, just to be sure. The Heaven 4.0 benchmark works fine in any openGL configuration and worked fine before coming from the same VM, so I don’t think it is a factor. Sounds like a server setting that’s buried somewhere. Thanks again!
Added note: It works fine running with DirectX if you launch the application on the XenApp server itself via VNC, just not from the client. Dxdiag shows Direct11 enabled properly on the VM Windows 8.1 client.
Update: We checked settings all over the place yesterday and everything looks to be correct. The fact that it runs fine directly on the XenApp VM itself must mean something is getting filtered out or some functionality is missing on the client side, but it’s baffling what that might be.
Might there be some oddity specific to XenApp 7.6? DirectX most definitely did work before with an older version of XenApp running on a Windows 2008 R2 server.
I’ve been out at a conference all week so no chance to look at this, Citrix is a good first starting point to see why it’s not working.
One thing to quickly check if you haven’t already is whether it runs as expected at the console. Since you’re in a VM you’ll need to connect via VNC to a console session as it’s blocked in XenCenter.
Hi, Jason:
Fully understood, we’re all busy! :-)
As mentioned above, yes, this works fine directly on the XenApp console. The issue arises only when another VM client is trying to start up the session and only with DirectX 9 or 11 (and irrespective of frame size, windowing choice or any other setting). OpenGL works fine in all imaginable ways on the client VMs. We wll probably get in touch with Citrix coming Monday to do a preliminary shakedown, but nothing obvious seems any different from the setting in your comprehensive video. If you think of anything else meanwhile, give me a shout! Thanks much again, we’ll get this licked yet.
As an aside, we are finding that performance and image quality with HDX 3D Pro enabled is worse than with standard HDX. These are LAN connections with plenty of available bandwidth and so I am wondering how much the choice of client matters. Even with a client that seems to support HDX well, it’s not as crisp as with standard HDX. You would think that it’d not worry about bandwidth optimization if plenty of bandwidth is available, or should we think about dealing with VMs differently depending on whether they are local or WAN-based connections?
I agree that the client can make quite a difference, and when using h264 from XenApp the CPU load will increase for each session due to each session having a HDX encoder active.
Interesting comment about bandwidth and one I’ve raised with Citrix a few times, if I’ve got 100Mb/s or even 1Gb/s to the client why doesn’t it use it all…
I get my lab back next week, so I’ll be able to try a few more things out and see if I can recreate your issue.
Hello, Jason:
Alas, my coworker who had contacted Citrix last week is out today and was also out part of last week, as well, so no initial feedback from Citrix yet. Have you per chance had a chance to get your lab set up again? There’s got to be a setting somewhere that’s off pertaining to the VM connection, otherwise if it were a question of it being supported at all, it would fail on the native XenApp VM (which it does not).
Thanks much again in advance,
Much obliged for your testing once again, Jason! I bet you’re right – hopefully it will not as bad as the equivalent of "oops, I forgot to plug it in…" :-) Glad your system is evidently running once more!
Will keep you posted of course and many thanks again,
Hi, Jason:
So, here is the situation: I worked with Citrix this afternoon for quite some time and we were able to install Google Earth and successfully run it both on XenApp 7.6 (installed as Server 2012 R2) running on a XenServer 6.2 box and the Windows 8.1 VM running as a client on a XenServer 6.2 box with both OpenGL and DirectX. Yes! So, good it does work and the nvidia-smi.exe program shows the engine at work on the XenApp server, as it should, for all cases. The support engineer did discover in the process that the Receiver on the Windows 8.1 VM is outdated, but that is a side issue.
However, what now seems to be the case is that Unigine Heaven benchmark – while running fine on both XenApp and on the VM client in openGL mode – fails both for running directly on XenApp as well as on the client VM with DirectX, with similar errors.
Citrix said to find out if this is a known issue or not with The Unigine Heaven 4.0 benchmark being possibly incompatible with Windows 2012 R2 server or if there was possibly something about the install that went wrong or the like. It is clearly related to that one application, and as indicated above it acts as if certain libraries are missing or cannot be found. I think we already tried re-installing both the GRID software and the benchmark program, to no avail.
What would you suggest at this point? Is your working instance on XenApp running on server 2012 or 2012 R2, just to make sure that this is not the big difference in the environment?
Unigene, both Heaven & Valley, will run in DirectX mode in both a Desktop VM and a XenApp session so I’d question the answer from Citrix on this.
I’ll send you a link via DM shortly where you can download a video of my lab system running Unigene in a XenApp session in DirectX mode. Feel free to share it with your Citrix contact as well to show it should work.
Mine’s on 2012R2, has the latest VDA and the couple of registry modifications for WPF as in the Citrix eDoc here
BTW, the host is the same host as I made the config checks video from.
Many thanks, Jason. Maybe you or a colleague could remote in at some point and take a look (via GoTo Meeting)? Even though the ticket is closed, I passed your information back to Citrix support. Very mysterious. I have since tested Google Earth using DirectX on numerous Receiver clients (thin, Mac iBook, PC) and everything works great, so there must be something very subtle going on specifically with the Unigine benchmark routine.
Dependent on your OS you may need to set a policy for the adapter which should be used for rendering DirectX content in RDS/XenApp Sessions as well
Remote Desktop Services (RDS) sessions on the RD Session Host server use the Microsoft Basic Render Driver as the default adapter. To use the GPU in RDS sessions on Windows Server 2012, enable the Use the hardware default graphics adapter for all Remote Desktop Services sessions setting in the group policy
Ron,
Thanks very much for that feedback. We will definitely check this out. Not sure why it would work OK for some apps with DirectX (like Google Earth), but not others (like Unigine Heaven). But also, what if you didn’t want all apps made available in Storefront to make use of the GRID? Shouldn’t it fall back to the default then, anyway?