[viogpu3d] Virtio GPU 3D acceleration for windows

[max8rr8]

Hello! This series of changes spanning across multiple repositories introduce support for 3d accelerated virtiogpu windows guests.

Wglgears window is rendered with wgl on virgl and window below it is cube rendered with d3d10umd on virgl.

How to test

NOTE: This driver does have some rendering glitches and might crash. Try at your own risk.
0. Create qemu windows VM with VirtIO GPU with 3d acceleration enabled. It is highly recommended to use "disposable" virtual machine to test, loss of data might occur.

1. Use patched version of virglrenderer from this repo branch viogpu_win
2. Compile from source OR download pre-built drivers.
3. Install drivers on target VM. Note: if drivers were not signed you need to manually select them in device manager.

Known issues

• FIXED: Frames displayed on screen are lagging behind

• FIXED: D3d10 clearing color is not supported

• FIXED: D3d10 applications using DXGI_SWAP_EFFECT_DISCARD and DXGI_SWAP_EFFECT_SEQUENTIAL are not displayed.

• Rendering glitches in WinUI3 apps.

  There are some rendering glitches in apps based on WinUI3 (maybe other apps too), best way to see them is to install WinUI3 Gallery from microsoft store and navigate around it. Haven't yet invistigated.

• Vscode (possibly other electron apps) does not render

  Black window. Requires implementation of PIPE_QUERY_TIMESTAMP_DISJOINT in virglrenderer.

• No preemption

  Kernel-mode driver does not implement preemption, and i am very confised about how to implement it in WDDM. VioGpu3D disables preemption systemwide to workaround lack of preemption implementation, but this is not ideal. Would appreciate some help.

Siblings

• Mesa: https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24223
• kvm-guest-drivers: [viogpu3d] Virtio GPU 3D acceleration for windows #943
• virglrenderer: https://gitlab.freedesktop.org/virgl/virglrenderer/-/merge_requests/1185

[vrozenfe]

@max8rr8
Hi Max,

Thank for a very impressive work you've done.
Please give us some time to go through your code and
see how to integrate it into our upstream repository.

Nice work!
All the best,
Vadim.

[kostyanf14]

Hi @max8rr8,

This instruction is not clear to me. Can you please describe it more with directory examples? What dependencies should be installed and how configured? (Example: https://github.com/virtio-win/kvm-guest-drivers-windows/wiki/Building-the-drivers-using-Windows-11-21H2-EWDK).
I looked into the mesa compilation guide and it looks completely different.

meson setup builddir/
meson compile -C builddir/
sudo meson install -C builddir/

Several questions:

1. What is %MESA_PREFIX% and where it defined?
2. Can we use any precompiled MESA for Windows (for example https://fdossena.com/?p=mesa/index.frag)

[max8rr8]

What is %MESA_PREFIX% and where it defined?

%MESA_PREFIX% environment variable is set during build process, it points to directory where mesa installs its files.

Can we use any precompiled MESA for Windows

I don't think so, as pointed out in mesa MR when building user-mode driver we have to build it with specific mesa flags to build only virgl driver (to avoid conflicts)

[max8rr8]

Building instruction

NOTE 1: this is valid for now, until changes are not in upstream repositories
NOTE 2: this assumes that all build dependencies(meson, WDK, ninja, etc...) are installed

Part 1: Virglrenderer

On host machine it is required that patched version of virglrenderer is used.

1. Acquire source code git clone --branch viogpu_win https://gitlab.freedesktop.org/max8rr8/virglrenderer && cd virglrenderer
2. Create install directory mkdir install and build directory: mkdir build && cd build
3. Configure build meson --prefix=$(pwd)/../install (we set prefix to install libvirglrenderer not globally but to previously created dir install)
4. Compile and install ninja install
   Now ensure that qemu loads libvirglrenderer from install directory, this can be done by setting LD_LIBRARY_PATH to something like /some/path/to/starter_dir/virglrenderer/install

Part 2: Build mesa

Now inside virtual machine with build tools installed create working directory, then inside it (this assumes use of Powershell):

1. Create mesa prefix dir mkdir mesa_prefix and set env MESA_PREFIX to its path: $env:MESA_PREFIX="$PWD\mesa_prefix"
2. Get patched mesa source code git clone --depth 10 --branch viogpu_win https://gitlab.freedesktop.org/max8rr8/mesa and then cd into it cd mesa
3. Create build directory mkdir build && cd build
4. Configure build meson .. --prefix=$env:MESA_PREFIX -Dgallium-drivers=virgl -Dgallium-d3d10umd=true -Dgallium-wgl-dll-name=viogpu_wgl -Dgallium-d3d10-dll-name=viogpu_d3d10 -Db_vscrt=mt, build options explained:

• --prefix=$env:MESA_PREFIX set installation path to dir created in step 1
• -Dgallium-drivers=virgl build only virgl driver
• -Dgallium-d3d10umd=true build DirectX 10 user-mode driver (opengl one is build by default)
• -Dgallium-d3d10-dll-name=viogpu_d3d10 name of generated d3d10 dll to viogpu_d3d10.dll
• -Dgallium-wgl-dll-name=viogpu_wgl name of generated wgl dll to viogpu_wgl.dll
• -Db_vscrt=mt use static c runtime (see this comment)

5. Build and install (to mesa prefix): ninja install

Part 3: Build driver

Now that mesa is build and installed into %MESA_PREFIX% viogpu3d will be built (in case %MESA_PREFIX is not set viogpu3d inf generation is skipped)

1. Acquire source code git clone --branch viogpu_win https://github.com/max8rr8/kvm-guest-drivers-windows and cd into it cd kvm-guest-drivers-windows
2. Go to viogpu cd viogpu
3. (optional, but very useful) setup test code signning from visual studio
4. Call build .\build_AllNoSdv.bat

Part 4: Installation

Now copy kvm-guest-drivers-windows\viogpu\viogpu3d\objfre_win10_amd64\amd64\viogpu3d to target VM and install it.

EDIT: Added gallium-windows-dll-name to mesa parameters.
EDIT2: More changes related to dll naming in mesa parameters

[max8rr8]

Changes:

• Fixed crash caused by use of PAGED_CODE at DISPATCH_LEVEL in flip timer. Instead of using ExTimer, separate flipping thread is used.
• Building system now checks for viogpu related dll's specifically when deciding whether to compile viogpu3d
• Renamed DLL's and updated build instructions due to changes requested by mesa

[max8rr8]

Changes:

• Re-implemented RotateResourceIdentites. This fixed biggest issue of frames lagging behind, now using driver becomes pretty smooth experience.
• Implemented clear_render_target similarly to i915
• Implemented support for staging resources and kernel-mode Present BLT which fixes window display in applications using DXGI_SWAP_EFFECT_DISCARD and DXGI_SWAP_EFFECT_DISCARD.

Pre-built driver provided in description was updated with these changes.

[mincore]

I've tested the driver on win10, and got a black screen. But if change the guest os to ubuntu(same qemu command line), glxgears performs well. (glxinfo shows that the renderer is NVIDIA gpu)

env

guest os:
win 10 enterprise ltsc + viogpu3d

host os:
fedora38, qemu 8.0.3 with virglrenderer

qemu command line

-display egl-headless,rendernode=/dev/dri/card1 -device virtio-vga-gl -trace enable="virtio_gpu*" -D qemu.log

virglrenderer.log

gl_version 46 - core profile enabled
GLSL feature level 460
vrend_check_no_error: context error reported 3 "" Unknown 1282
context 3 failed to dispatch DRAW_VBO: 22
vrend_decode_ctx_submit_cmd: context error reported 3 "" Illegal command buffer 786440
GLSL feature level 460
vrend_check_no_error: context error reported 5 "" Unknown 1282
context 5 failed to dispatch DRAW_VBO: 22
vrend_decode_ctx_submit_cmd: context error reported 5 "" Illegal command buffer 786440
GLSL feature level 460
GLSL feature level 460
GLSL feature level 460
GLSL feature level 460
GLSL feature level 460
vrend_check_no_error: context error reported 9 "" Unknown 1282
context 9 failed to dispatch DRAW_VBO: 22

qemu_strace.log

virtio_gpu_features virgl 0
virtio_gpu_features virgl 0
virtio_gpu_cmd_get_edid scanout 0
virtio_gpu_cmd_get_display_info
virtio_gpu_cmd_ctx_create ctx 0x1, name
virtio_gpu_cmd_ctx_create ctx 0x2, name
virtio_gpu_cmd_res_create_3d res 0x1, fmt 0x1, w 1280, h 1024, d 1
virtio_gpu_cmd_ctx_res_attach ctx 0x2, res 0x1
virtio_gpu_cmd_res_back_attach res 0x1
virtio_gpu_cmd_res_create_3d res 0x2, fmt 0x1, w 1280, h 1024, d 1
virtio_gpu_cmd_ctx_res_attach ctx 0x2, res 0x2
virtio_gpu_cmd_res_create_2d res 0x3, fmt 0x2, w 1280, h 1024
virtio_gpu_cmd_res_back_attach res 0x3
virtio_gpu_cmd_set_scanout id 0, res 0x1, w 1280, h 1024, x 0, y 0
virtio_gpu_cmd_res_flush res 0x1, w 1280, h 1024, x 0, y 0
virtio_gpu_cmd_set_scanout id 0, res 0x1, w 1280, h 1024, x 0, y 0
virtio_gpu_cmd_res_flush res 0x1, w 1280, h 1024, x 0, y 0
virtio_gpu_cmd_ctx_create ctx 0x3, name
virtio_gpu_cmd_ctx_destroy ctx 0x3
virtio_gpu_cmd_ctx_create ctx 0x3, name
virtio_gpu_cmd_res_create_3d res 0x4, fmt 0xb1, w 48, h 1, d 1
virtio_gpu_cmd_ctx_res_attach ctx 0x3, res 0x4
virtio_gpu_cmd_res_create_3d res 0x5, fmt 0xb1, w 4000, h 1, d 1
virtio_gpu_cmd_ctx_res_attach ctx 0x3, res 0x5
virtio_gpu_cmd_res_create_3d res 0x6, fmt 0xb1, w 16, h 1, d 1
virtio_gpu_cmd_ctx_res_attach ctx 0x3, res 0x6
virtio_gpu_cmd_res_create_3d res 0x7, fmt 0xb1, w 48, h 1, d 1
virtio_gpu_cmd_ctx_res_attach ctx 0x3, res 0x7
virtio_gpu_cmd_res_create_3d res 0x8, fmt 0xb1, w 240012, h 1, d 1
virtio_gpu_cmd_ctx_res_attach ctx 0x3, res 0x8
virtio_gpu_cmd_res_create_3d res 0x9, fmt 0xb1, w 102400, h 1, d 1
virtio_gpu_cmd_ctx_res_attach ctx 0x3, res 0x9
virtio_gpu_cmd_res_create_3d res 0xa, fmt 0xb1, w 144, h 1, d 1
virtio_gpu_cmd_ctx_res_attach ctx 0x3, res 0xa
virtio_gpu_cmd_res_create_3d res 0xb, fmt 0xb1, w 160000, h 1, d 1
virtio_gpu_cmd_ctx_res_attach ctx 0x3, res 0xb
virtio_gpu_cmd_res_create_3d res 0xc, fmt 0xb1, w 16000, h 1, d 1
virtio_gpu_cmd_ctx_res_attach ctx 0x3, res 0xc
virtio_gpu_cmd_res_create_3d res 0xd, fmt 0xb1, w 240000, h 1, d 1
virtio_gpu_cmd_ctx_res_attach ctx 0x3, res 0xd
virtio_gpu_cmd_res_create_3d res 0xe, fmt 0xb1, w 192, h 1, d 1
virtio_gpu_cmd_ctx_res_attach ctx 0x3, res 0xe
virtio_gpu_cmd_res_create_3d res 0xf, fmt 0xb1, w 16, h 1, d 1
virtio_gpu_cmd_ctx_res_attach ctx 0x3, res 0xf
virtio_gpu_cmd_res_create_3d res 0x10, fmt 0xb1, w 272, h 1, d 1
virtio_gpu_cmd_ctx_res_attach ctx 0x3, res 0x10
virtio_gpu_cmd_res_create_3d res 0x11, fmt 0xb1, w 240, h 1, d 1
virtio_gpu_cmd_ctx_res_attach ctx 0x3, res 0x11
virtio_gpu_cmd_res_create_3d res 0x12, fmt 0xb1, w 272, h 1, d 1
virtio_gpu_cmd_ctx_res_attach ctx 0x3, res 0x12
virtio_gpu_cmd_res_create_3d res 0x13, fmt 0x1, w 50, h 50, d 1
virtio_gpu_cmd_ctx_res_attach ctx 0x3, res 0x13
virtio_gpu_cmd_ctx_create ctx 0x4, name
virtio_gpu_cmd_res_back_attach res 0x13
virtio_gpu_cmd_res_back_attach res 0x4
virtio_gpu_cmd_res_back_attach res 0x5
virtio_gpu_cmd_res_back_attach res 0x6
virtio_gpu_cmd_res_back_attach res 0xa
virtio_gpu_cmd_res_back_attach res 0xe
virtio_gpu_cmd_res_back_attach res 0xf
virtio_gpu_cmd_res_back_attach res 0x10
virtio_gpu_cmd_res_back_attach res 0x11
virtio_gpu_cmd_res_back_attach res 0x12
virtio_gpu_cmd_ctx_submit ctx 0x3, size 74220

[max8rr8]

I've tested the driver on win10, and got a black screen. But if change the guest os to ubuntu(same qemu command line), glxgears performs well. (glxinfo shows that the renderer is NVIDIA gpu)

It seems to be an bug in virglrenderer on nvidia related to GL_PRIMITIVE_RESTART_NV. You can try to apply this diff to fix it, but it's a bit hacky solution.

[CE1CECL]

What versions of windows does it go down to?
In my case, I am experimenting with https://github.com/CE1CECL/qemu-vmvga and it works with vista (no 3d yet), trying to get 3D to work right now.

[foxlet]

I tried the pre-built driver on Windows 10 22H2 and it only showed a black screen before hard-locking and resetting. Also tested the same config with Ubuntu which had working virgl.

Using -display gtk,gl=on -device virtio-vga-gl on an AMD R9 6900HS + RX 6700S host.
virglrenderer was compiled from git (considering that it's already been merged in).
qemu is version 7.2.4

qemu.log

[Conan-Kudo]

Can we validate that this works with Windows 7 too? It's a fairly common virtualization guest for playing older games, and it's still WDDM class.

[max8rr8]

What versions of windows does it go down to?

Current driver theoretically supports windows 8.1, but it is built for and tested only on Windows 10 22H2. But it is important to note that support for blob resources which are required to improve performance and support vulkan will require using WDDM 2 which lift minimum windows version to 10.

Can we validate that this works with Windows 7 too?

I doubt it will work with current code, it might be possible to adapt it for windows 7, but i do not have interest in doing that (though wouldn't mind if someone else will adapt code). Plus at some point driver will have to use WDDM 2 which will splitting codebases or more likely require either dropping support for older OS.

I tried the pre-built driver on Windows 10 22H2 and it only showed a black screen before hard-locking and resetting. Also tested the same config with Ubuntu which had working virgl.

Nothing seems wrong in attached qemu.log. I don't see any lines like GLSL feature level 460 that should be printed to stdout, can you also attach stdout of qemu.
Although it could be issue in kernel driver then the only way to know what's wrong is to attach kernel debugger to vm.

[Torinde]

That's great @max8rr8!
It seems your focus is on modern software (Win8.1/10) and you plan going upwards in support (D3D12/Vulkan/venus). In that regards - do you plan adding:

• video encoding/decoding acceleration
• lvp/llvmpipe/softpipe - fallback when no compatible GPU is present on the host or to run the graphics on a high-corecount CPU instead of its weak integrated GPU? Or if possible to combine the two (augment the performance of a weak GPU with llvmpipe running on the CPU cores)

For the retro direction, above was mentioned Win7 and in addition I think such virgl/venus GPU will be very useful also for:

• QEMU with Win9x to run JHRobotics/softgpu
• DOSbox-X with Win9x, where it may help run the driver JHRobotics/softgpu
• 86box/PCbox with Win9x, WinXP and maybe even Vista, OS/2, BeOS, etc.

[RedGreenBlue09]

I compiled and tried it, but I got the BSOD DRIVER_CORRUPTED_EXPOOL.
Host: Windows 11 Pro (10.0.22621.2070), NVIDIA driver 536.67
Guest: Windows 10 Enterprise (10.0.16299.15)

First, I compiled QEMU in MSYS2 like this:

cp /c/Program\ Files\ \(x86\)/Windows\ Kits/10/Include/10.0.22621.0/um/WinHv*\
 /ucrt64/x86_64-w64-mingw32/include/

./configure \
--target-list=x86_64-softmmu,i386-softmmu,arm-softmmu \
--cpu=x86_64 \
--enable-lto \
--enable-malloc=jemalloc \
--enable-avx2 \
--enable-dsound \
--enable-hax \
--enable-iconv \
--enable-lzo \
--enable-opengl \
--enable-png \
--enable-sdl \
--enable-sdl-image \
--enable-spice \
--enable-spice-protocol \
--enable-tcg \
--enable-whpx \
--enable-virglrenderer \
--disable-docs 

I compiled virglrenderer (upstream) like your comment above, then replaced the dll in QEMU dir with the newly built one.

Then I compiled mesa with VS (MinGW GCC prints a bunch of errors related to the WDK headers, so I gave up):

meson setup build/ -Dgallium-drivers=virgl -Dgallium-d3d10umd=true -Dgallium-wgl-dll-name=viogpu_wgl -Dgallium-d3d10-dll-name=viogpu_d3d10 --backend=vs

It outputs to my root folder (C:\) so I copied bin to a directory named mesa_prefix.
I opened cmd, set MESA_PREFIX to the mesa_prefix directory then compiled viogpu.sln with msbuild (Configuration="Win10 Release", Platform=x64).

I signed the output in viogpu\viogpu3d\objfre_win10_amd64\amd64\viogpu3d:

for /R . %a in (*.exe, *.sys, *.dll) do signtool sign /f "Surface.pfx" /t "http://timestamp.sectigo.com" /fd certHash "%a"

Then I booted up the VM, enabled test signing and then install the driver. The screen instantly went black and Windows crashes.

WinDBG, qemu logs and VM command line attached. I tried using serial kernel debug but it just hangs forever at boot so I analyzed the dump file instead.

windbg.txt
qemu.log
cmdline.txt

[RedGreenBlue09]

Additionally, I tried booting Linux Mint 20.2 live cd but QEMU itself crashed on some heap corruption issue. I replaced the original MSYS2 virglrenderer dll which fixed it. The Windows 10 guest BSOD remains.

[max8rr8]

Hi @RedGreenBlue09, it seems that kernel crash happened during driver unloading (VioGpu3DRemoveDevice in backtrace) and while it is a problem, it is not the root cause for driver not working on your system as for some unknown reason windows triggers driver unload.

You should try to attach windbg to running vm (try to use network debugging instead of serial, it works for me). Additionally when connecting to vm from windbg enable break on connection and run following command

bp  watchdog!WdLogEvent5_WdError "k; g"

This windbg command should add backtrace logging to all errors happening in dxgkrnl. After you ran that command continue kernel execution with windbg command g or a button in gui. Then get full log and send it there, so we can analyze what actually went wrong (why does unload happen).

[RedGreenBlue09]

Hi @RedGreenBlue09, it seems that kernel crash happened during driver unloading (VioGpu3DRemoveDevice in backtrace) and while it is a problem, it is not the root cause for driver not working on your system as for some unknown reason windows triggers driver unload.

You should try to attach windbg to running vm (try to use network debugging instead of serial, it works for me). Additionally when connecting to vm from windbg enable break on connection and run following command

bp  watchdog!WdLogEvent5_WdError "k; g"

This windbg command should add backtrace logging to all errors happening in dxgkrnl. After you ran that command continue kernel execution with windbg command g or a button in gui. Then get full log and send it there, so we can analyze what actually went wrong (why does unload happen).

I will test again later. Also, if I use VGA + virtio-gpu-gl setup the driver don't load and it have error 49 in device manager. The error message is something like "Windows unloaded the driver because it has reported problems"

[RedGreenBlue09]

... Network debug also hangs like serial. Interestingly that doesn't happen with ReactOS.

[RedGreenBlue09]

I have no luck with live kernel debug. I tried using accel tcg, official qemu, none of these helps. If
I enable boot debug, Windows boot manager itself freezes. Absolutely no idea.

Edit: Even ditching OVMF for SeaBIOS, it still freezes.

[RedGreenBlue09]

@max8rr8 Okay, I'm sorry for the rant. It doesn't hang forever, just 30 minutes :((. I tried your command and got an error:

0: kd> bp  watchdog!WdLogEvent5_WdError "k; g"
Bp expression 'watchdog!WdLogEvent5_WdError ' could not be resolved, adding deferred bp

[RedGreenBlue09]

After reloading symbols, the error is gone. Here is the new log.

windbg2.txt

[nefarius]

I changed a bit to let in support Windows 10 I can’t the use driver even I disable driver signature enforcement and enable test mode after I install the driver It will show “Windows cannot verify the digital signature for the drivers required for this device”, error code 52.

The mentioned article will never work, you can not self/test-sign a kernel driver for Windows 10 and load it without TESTMODE ON and SecureBoot OFF.

[Kitchannel2010]

I changed a bit to let in support Windows 10 I can’t the use driver even I disable driver signature enforcement and enable test mode after I install the driver It will show “Windows cannot verify the digital signature for the drivers required for this device”, error code 52.

The mentioned article will never work, you can not self/test-sign a kernel driver for Windows 10 and load it without TESTMODE ON and SecureBoot OFF.

Then what should I do because device manager doesn’t let me install it without signing.

[nefarius]

I changed a bit to let in support Windows 10 I can’t the use driver even I disable driver signature enforcement and enable test mode after I install the driver It will show “Windows cannot verify the digital signature for the drivers required for this device”, error code 52.

The mentioned article will never work, you can not self/test-sign a kernel driver for Windows 10 and load it without TESTMODE ON and SecureBoot OFF.

Then what should I do because device manager doesn’t let me install it without signing.

Use test mode, as I said. Test mode accepts any signature on kernel binaries. That's the way to go. Tons of info about it online.

[Kitchannel2010]

After I success install the driver after enable test mode and disable driver enforcement, but I encountered another problem (Error Code 32),

Device PCI\VEN_1AF4&DEV_1050&SUBSYS_11001AF4&REV_01\3&11583659&0&08 had a problem starting.

Driver Name: oem2.inf
Class Guid: {4d36e968-e325-11ce-bfc1-08002be10318}
Service: VioGpu3D
Lower Filters:
Upper Filters:
Problem: 0x15
Problem Status: 0x0

[Marietto2008]

Does virgl-server exists for Android ?

[codenyte]

Does virgl-server exists for Android ?

This thread is probably not the right place to ask this question

[zhuowp]

It seems that it does not support webgl on Chrome or Edge.
Is there any way to make webgl enable?

[Burinis]

I have a question for you: is this driver compatible with Windows XP? Is there any third party driver for this Windows?

Guys/gals come on don't overhead the development. Stop asking stuff unless you have something helpful to add. And no, this driver is not compatible with XP -- the model for 3D graphics changed considerably on Windows Vista onwards. AFAIK. I think I saw a XP compatible one somewhere on this repo. I suggest you create a topic on LinuxQuestions and post here the thread URL so we can redirect the chit-chat. Thanks!

Thanks! I already reported this in LinuxQuestions.

[lightyisreal]

Is this getting worked on?

[darkbasic]

Latest commit is two weeks old...

[volkertb]

I really hope this makes it past the finish line. The person who created this PR put a lot of work in it and having 3D acceleration in Windows guests through Virtio is really a big deal. I know I'm not contributing much by just commenting, but I'm not the only one who hates to see this whither on the vine.

[vrozenfe]

FYI,
Konstantin is working on this https://issues.redhat.com/browse/RHEL-64314

[finch71]

anyone get webgl in chrome working?