DX11 fullscreen weird output on console


I tested Unigine’s Heaven Benchmark on vGPU/K1. I am getting weird output on cosole only in DX11 fullscreen (tried various resolution and benchmark options). 3Dmark11 works ok. I tested both drivers 340.34/340.69 or 340.57/341.08.

Is there problem with driver or benchmark (all DX11 games affected) ?


Attached images - DX11 windowed (ok), DX9 fullscreen (ok) and 2x DX11 fullsceen (bad).

Looks like a application issue in fullscreen mode. Have you tested with 3Dmark11, if so does it replicate in full screen mode?

3Dmark11 (Basic) is ok in all tests.
The same error is in Unigine’s Valley Benchmark.
I sent mail to Unigine support.


What virtualisation stack and protocols are you using?

  • Xen 4.5 RC4 4.5 final
  • device model "qemu-xen" qemu version 2.0.2 (qemu-xen-4.5.0)
  • dom0 kernel-3.10.41-299.380404
  • vGPU Nvidia Grid K1 with grid_k140q profile (VBIOS 80.07.DC.00.0*)
  • output taken directly in Dom0 from framebuffer vmiop_presentation_put_message/vmiop_dt_frame
  • drivers dom0/domU - 340.34/340.69 340.57/341.08
  • domU is windows 7 64 bit

Can you try this out on Citrix XenServer? We don’t currently support vGPU on open source Xen, so lets see if you can replicate the issue on XenServer.

If you can replicate the issue, we can move to get a bug raised.


Yes, I confirm the error on supported XenServer.

  • XenServer 6.5 + XS65E002 + "Desktop+" license
  • drivers dom0/domU 340.57/341.08
  • another nvidia K1 with different firmware (VBIOS 80.07.6D.00.0*)
  • domU fresh install of windows 7
  • screenshots from vnc console (setup, loading and running screenshots)

I reported bug on XenServer: https://bugs.xenserver.org/browse/XSO-212
Where to report bug to Nvidia ?


It’s possibly down to the way VNC grabs the display and transmits it (fullscreen is drawn differently to a windowed app).

VNC, as far as I’m aware, doesn’t leverage the GRID SDK, so is scraping the screen not reading directly from the frame buffer.

I’d suspect it’s the protocol at fault here.

Console vnc viewer is NOT backed by standard DomU installed vnc server.
Console vnc is generated by Dom0 qemu with nvidia+xenserver integration (nvidia "libnvidia-vgx.so" api and "vgpu" io server).

(If you try to use standard DomU installed vnc server you see only "black screen" in gpu accelerated fullscreen appliaction).


I still suspect it’s the protocol at fault.

I can replicate this with VNC, but neither ICA/HDX or PCoIP are affected which strongly indicate the VNC protocol itself.

Do you have another protocol you can test with?

No, official XenServer/Dom0/qemu does not allow to change "wire" protocol (vnc).
But I have the same issue was if I encode buffer (to jpeg) accessed directly from Nvidia vgpu hypervisor API vmiop_presentation_put_message/vmiop_dt_frame.
This should be bug in Nvidia vgpu hypervisor (eg. libnvidia-vgx.so and nvidia Dom0 driver) if DomU transfers works.

There are more unresolved bugs in Nvidia vgpu hypervisor


Based on what I think your trying to do, I’m moving this thread to the API’s forum.

You may find what you’re looking for in the SDK, which contains the means to develop your own h264 encoded stream.



Thanks for your answer. But I dislike to move to DomU SDK for streaming video only (with many windows API complications).

Dom0 streaming is platform independent works with all DomU operating systems and modes (for example emulated VGA mode (very typical and often "safe mode" for windows)). Also all other streams (usb,audio) works perfectly and transparently in Dom0. Security is also higher (out-of-band separated ethernet ports).

I will be very pleased if Nvidia corrects this issues to frambebuffer output in Dom0 and/or add "Grid Gaming SDK" for h264 to dom0 and/or at least "Cuda" to dom0 for mjpeg offloading or disclosure config how to use "other" (non K1/K2) Nvidia card for this support in dom0.

Thanks, M.C>

New drivers 340.78/341.44 - nothing changes :-(

New drivers 352.46/354.13 - nothing changes :-(

The K2 instead K1 does not help.
I found workaround - simply minimize and restore (or switch task) 3D application window and all is ok.

After year and 6 released WHQL certified drivers the problem still exists. This seems to be fail of MSFT certification process and NVidia DX11 driver developers.
XenServer team closed ticket as solely NVidia error https://bugs.xenserver.org/browse/XSO-212.

I attached video if you try to switch Witcher3 to DX11-fullscreen on vGPU. This is the same problem with the same NVidia error.
dx11_error_witcher_on_vgpu.mov (18.8 MB)

not surprisingly still buggy Dom0 driver - 352.70, 352.83, 361.40, 361.45.09, 352.97, 367.43/369.17 (Grid4.0), 367.64/369.71 (Grid4.1), 367.92/369.95 (Grid4.2), 367.106/370.12 (Grid4.3), 367.12/370.16 (Grid4.4)…

05/31/2016 - Let us celebrate 500 days without resolving this bug !
01/17/2017 - Let us celebrate 2 years without resolving this bug !

10/12/2017 - Let us celebrate 1000 days without resolving this bug !

This depends on how the VNC screen is sent and how it is sent on Windowsized the whole screen is drawn differently. As far as I know, VNC does not use the Grid SDK. That is, the screen is not read directly from the framebuffer when scraping. Adobe Zii 2020

This is special case for NVIDIA vGPU SW. NVIDIA software presents vGPU "console" as framebuffer to shared memory in host (not in guest! there is no VNC software in guest!). This framebuffer is encoded by qemu with VNC protocol (not any other VNC software).

So your note is irrelevant.

This is pure problem of NVIDIA vGPU internal capture with interfacing to M$ Windows composer and it never have been resolved. You should study images and captured video more carefully - the problem is with some 3d/postprocessing layer in NVIDIA rendering stack. It is not possible do this garbage with VNC or other remoting protocol (I use h264 streaming with the same garbage).

Grid 4.x (last for K1/K2) is now EOL/unsupported. So this is bug forever.

This problem still persists in newer drivers (vGPU SW > 4.x) but with different behavior (see https://gridforums.nvidia.com/default/topic/8762/#12670 ). This bug has impact to encoder (garbage is very hard to compress) and connection bandwidth. Due to this problems NVIDIA completely abandoned NVFBC (“console” framebuffer capture in guest) and forces to use M$ Windows DDUPL API that is unusable too (see https://forums.developer.nvidia.com/t/how-can-ddupl-replace-nvfbc/126249 ). So goodbye reasonable UX for VDI !

NVIDIA is incompetent to repair this bug. Quality of NVIDIA software is very low.