[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

[Nikoos]

My builds keep failing due to a few bugs in VS community 2022 and the fact that I this is my first time compiling on windows. Is it possible to upload the precompiled binary once again? (The one in your comment has expired) Thanks.

I was able to write a more detailed instruction guide.

I will be able to provide you info on monday

Nikos

[Usulyre]

Hi, can we get the pre compiled drivers link updated, can't download viogpu3d.zip

[Nikoos]

My builds keep failing due to a few bugs in VS community 2022 and the fact that I this is my first time compiling on windows. Is it possible to upload the precompiled binary once again? (The one in your comment has expired) Thanks.

Please find my notes to compile driver :

Build virtual machine (really on a VM, not on production machine or your own machine) requirements:

• Windows 10 VM (x64)
• 8GB Ram
• 20GB storage
• Internet Access

1. Install Visual Studio 2022 Community Edition (12.85 GB): https://visualstudio.microsoft.com/vs/community/ with the following components enabled:
   1. Check (or enable) Dekstop development with C++
   2. In individual components, check (or enable) MSVC v143 - VS 2022 C++ x64/x86 Spectre-mitigated libs latest
   3. In individual components, check Git for Windows
   4. In the Installation details in left side, check (or enable) Windows 10 SDK latest version.
2. Install Windows Driver SDK (enable windows driver kit in vstudio) : https://learn.microsoft.com/en-us/windows-hardware/drivers/download-the-wdk#download-icon-for-wdk-step-3-install-wdk (note: you must register Windows Driver SDK in VS 2022, it will be perform automatically when asked).
3. Install Python 3 (3.11.8) for Windows 10 : https://www.python.org/ftp/python/3.11.8/python-3.11.8-amd64.exe
   1. Enable Add python.exe to PATH
   2. in customize installation, check Install Python 3.11 for all users
   3. Disable path length limit
4. Install meson & ninja via MSI package (from github repo) : https://github.com/mesonbuild/meson/releases
5. Download winflex bison from https://github.com/lexxmark/winflexbison/releases to c:\winflex
   1. Rename winflex.exe and winbison.exe to flex.exe and bison.exe
   2. Add c:\winflex to your environment PATH (Start menu, search for Edit environment variables from your account
   3. Add a new environment variable MESA_PREFIX, its value must be set to c:\temp\mesa_prefix
6. Time to compile dlls, Open the Developer Command Prompt for VS 2022 from your start menu and,
   1. Install python mako module with the following command: pip install mako
   2. Edit again your environment PATH by adding the provided path once the pip install mako command run
   3. Close and start the Developer Command Prompt for VS 2022.
   4. Then perform the following commands:

echo %MESA_PREFIX%
mkdir %MESA_PREFIX%
cd \temp
git clone --depth 10 --branch viogpu_win https://gitlab.freedesktop.org/max8rr8/mesa
cd mesa
mkdir build
cd build
meson .. --prefix=%MESA_PREFIX% -Dgallium-drivers=virgl -Dgallium-d3d10umd=true -Dgallium-wgl-dll-name=viogpu_wgl -Dgallium-d3d10-dll-name=viogpu_d3d10 -Db_vscrt=mt
ninja install

cd \temp
git clone --branch viogpu3d https://github.com/max8rr8/kvm-guest-drivers-windows

7. Now, in your Windows Explorer, go to c:\temp\kvm-guest-drivers-windows\viogpu and open the file named: viogpu.sln (Error should raised, we'll manage them later, mostly related to ARM64 setup).
   1. In the Solution Explorer panel (right side, right click on Solution 'viogpu' and select Properties.
   2. In the Properties window, select Configuration Properties it will enable two dropbox (Configuration and Platform), change the dropbox named Platform from Active(ARM64) to x64, ensure that viogpu3d build checkbox is checked. (note : a popup will appear with the following message: Do you want to save your changes you've made to this platform through the property pages? click on Yes)
   3. In the main Window, you can still see ARM64 in the toolbar (next to Windows release : Win10 Release), select x64.
   4. To launch compilation, go to menu Build, then click on Build solution.
   5. Note : it should failed, in my case, Visual Studio was not able to find the file named z.dll in c:\temp\mesa_prefix\bin. I had to rename the existing file named z-1.dll to z.dll
   6. Then restart compilation. (At this moment, we did not set certificate to sign or driver), it should complete, once done you must close your VS code, next step will require admin privileges to allow VS code to create and sign driver with a test certificate.

Open VS code 2022 with admin privileges, reopen your previous project and select the viogpu3d projet in the Solution explorer and go to properties.

1. Open Driver Signing and on the right side, by default, Sign mode is set to Off, change to Test Sign.
2. In the Test Certificate option (just below), select <Create Test Certificate…>, this will automatically create a test certificate and use it to sign your driver (note: this certificate has 1 day validity).
3. Validate and relaunch compilation (Build menu, then Build solution).

Once compiled, your driver will be available in c:\temp\kvm](c:\temp\kvm-guest-drivers-windows\viogpu)-guest-drivers-windows\viogpu\Install\Win10\amd64

Note : I was able to install driver with bcdedit commands, however, I have an error with code 43 (not really sure if this is the right code).

Note 2 : I 'm no Windows expert nor driver developer, only a simple tech guy following this project and trying to understand this project.

Hope this will help you.

Best regards

[Usulyre]

My builds keep failing due to a few bugs in VS community 2022 and the fact that I this is my first time compiling on windows. Is it possible to upload the precompiled binary once again? (The one in your comment has expired) Thanks.

Please find my notes to compile driver :

Build virtual machine (really on a VM, not on production machine or your own machine) requirements:

• Windows 10 VM (x64)
• 8GB Ram
• 20GB storage
• Internet Access

1. Install Visual Studio 2022 Community Edition (12.85 GB): https://visualstudio.microsoft.com/vs/community/ with the following components enabled:

   1. Check (or enable) Dekstop development with C++
   2. In individual components, check (or enable) MSVC v143 - VS 2022 C++ x64/x86 Spectre-mitigated libs latest
   3. In individual components, check Git for Windows
   4. In the Installation details in left side, check (or enable) Windows 10 SDK latest version.

2. Install Windows Driver SDK (enable windows driver kit in vstudio) : https://learn.microsoft.com/en-us/windows-hardware/drivers/download-the-wdk#download-icon-for-wdk-step-3-install-wdk (note: you must register Windows Driver SDK in VS 2022, it will be perform automatically when asked).

3. Install Python 3 (3.11.8) for Windows 10 : https://www.python.org/ftp/python/3.11.8/python-3.11.8-amd64.exe

   1. Enable Add python.exe to PATH
   2. in customize installation, check Install Python 3.11 for all users
   3. Disable path length limit

4. Install meson & ninja via MSI package (from github repo) : https://github.com/mesonbuild/meson/releases

5. Download winflex bison from https://github.com/lexxmark/winflexbison/releases to c:\winflex

   1. Rename winflex.exe and winbison.exe to flex.exe and bison.exe
   2. Add c:\winflex to your environment PATH (Start menu, search for Edit environment variables from your account
   3. Add a new environment variable MESA_PREFIX, its value must be set to c:\temp\mesa_prefix

6. Time to compile dlls, Open the Developer Command Prompt for VS 2022 from your start menu and,

   1. Install python mako module with the following command: pip install mako
   2. Edit again your environment PATH by adding the provided path once the pip install mako command run
   3. Close and start the Developer Command Prompt for VS 2022.
   4. Then perform the following commands:

echo %MESA_PREFIX%
mkdir %MESA_PREFIX%
cd \temp
git clone --depth 10 --branch viogpu_win https://gitlab.freedesktop.org/max8rr8/mesa
cd mesa
mkdir build
cd build
meson .. --prefix=%MESA_PREFIX% -Dgallium-drivers=virgl -Dgallium-d3d10umd=true -Dgallium-wgl-dll-name=viogpu_wgl -Dgallium-d3d10-dll-name=viogpu_d3d10 -Db_vscrt=mt
ninja install

cd \temp
git clone --branch viogpu3d https://github.com/max8rr8/kvm-guest-drivers-windows

7. Now, in your Windows Explorer, go to c:\temp\kvm-guest-drivers-windows\viogpu and open the file named: viogpu.sln (Error should raised, we'll manage them later, mostly related to ARM64 setup).

   1. In the Solution Explorer panel (right side, right click on Solution 'viogpu' and select Properties.
   2. In the Properties window, select Configuration Properties it will enable two dropbox (Configuration and Platform), change the dropbox named Platform from Active(ARM64) to x64, ensure that viogpu3d build checkbox is checked. (note : a popup will appear with the following message: Do you want to save your changes you've made to this platform through the property pages? click on Yes)
   3. In the main Window, you can still see ARM64 in the toolbar (next to Windows release : Win10 Release), select x64.
   4. To launch compilation, go to menu Build, then click on Build solution.
   5. Note : it should failed, in my case, Visual Studio was not able to find the file named z.dll in c:\temp\mesa_prefix\bin. I had to rename the existing file named z-1.dll to z.dll
   6. Then restart compilation. (At this moment, we did not set certificate to sign or driver), it should complete, once done you must close your VS code, next step will require admin privileges to allow VS code to create and sign driver with a test certificate.

Open VS code 2022 with admin privileges, reopen your previous project and select the viogpu3d projet in the Solution explorer and go to properties.

1. Open Driver Signing and on the right side, by default, Sign mode is set to Off, change to Test Sign.
2. In the Test Certificate option (just below), select <Create Test Certificate…>, this will automatically create a test certificate and use it to sign your driver (note: this certificate has 1 day validity).
3. Validate and relaunch compilation (Build menu, then Build solution).

Once compiled, your driver will be available in c:\temp\kvm](c:\temp\kvm-guest-drivers-windows\viogpu)-guest-drivers-windows\viogpu\Install\Win10\amd64

Note : I was able to install driver with bcdedit commands, however, I have an error with code 43 (not really sure if this is the right code).

Note 2 : I 'm no Windows expert nor driver developer, only a simple tech guy following this project and trying to understand this project.

Hope this will help you.

Best regards

Hi, if it is possible, would you be able to upload a prebuilt version of the driver files?

[Usulyre]

Download link in this issue:

(#1076)

Also, has anybody tried to cross compile it in Linux like debian bookworm?

I'm getting an error regarding "d3dkmthk.h: No such file or directory"

"Compiling C object src/gallium/auxiliary/libgallium.a.p/gdikmt_gdikmt_d3dkmt.c.obj
FAILED: src/gallium/auxiliary/libgallium.a.p/gdikmt_gdikmt_d3dkmt.c.obj "

"In file included from ../src/gallium/auxiliary/gdikmt/gdikmt_d3dkmt.c:2:
../src/gallium/auxiliary/gdikmt/gdikmt.h:9:10: fatal error: d3dkmthk.h: No such file or directory
9 | #include <d3dkmthk.h>"

[kostyanf14]

Download link in this issue:

(#1076)

Also, has anybody tried to cross compile it in Linux like debian bookworm?

I'm getting an error regarding "d3dkmthk.h: No such file or directory"

"Compiling C object src/gallium/auxiliary/libgallium.a.p/gdikmt_gdikmt_d3dkmt.c.obj FAILED: src/gallium/auxiliary/libgallium.a.p/gdikmt_gdikmt_d3dkmt.c.obj "

"In file included from ../src/gallium/auxiliary/gdikmt/gdikmt_d3dkmt.c:2: ../src/gallium/auxiliary/gdikmt/gdikmt.h:9:10: fatal error: d3dkmthk.h: No such file or directory 9 | #include <d3dkmthk.h>"

Our team tried driver cross-compilation in the past. Unfortunately, WDK in MinGW headers is too old and a lot of functions are missing. Currently, we expect to compile drivers with WDK for Server 2022 with a lot of new APIs (like memory management). "d3dkmthk.h" is a WDK header (https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/d3dkmthk/) that just missing in MinGW headers.

[Usulyre]

Download link in this issue:
(#1076)
Also, has anybody tried to cross compile it in Linux like debian bookworm?
I'm getting an error regarding "d3dkmthk.h: No such file or directory"
"Compiling C object src/gallium/auxiliary/libgallium.a.p/gdikmt_gdikmt_d3dkmt.c.obj FAILED: src/gallium/auxiliary/libgallium.a.p/gdikmt_gdikmt_d3dkmt.c.obj "
"In file included from ../src/gallium/auxiliary/gdikmt/gdikmt_d3dkmt.c:2: ../src/gallium/auxiliary/gdikmt/gdikmt.h:9:10: fatal error: d3dkmthk.h: No such file or directory 9 | #include <d3dkmthk.h>"

Our team tried driver cross-compilation in the past. Unfortunately, WDK in MinGW headers is too old and a lot of functions are missing. Currently, we expect to compile drivers with WDK for Server 2022 with a lot of new APIs (like memory management). "d3dkmthk.h" is a WDK header (https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/d3dkmthk/) that just missing in MinGW headers.

If compiling in windows one stills needs those header files from WDK right?

Is there a way when cross compiling in linux to make MinGW locate those header files?

[kostyanf14]

Download link in this issue:
(#1076)
Also, has anybody tried to cross compile it in Linux like debian bookworm?
I'm getting an error regarding "d3dkmthk.h: No such file or directory"
"Compiling C object src/gallium/auxiliary/libgallium.a.p/gdikmt_gdikmt_d3dkmt.c.obj FAILED: src/gallium/auxiliary/libgallium.a.p/gdikmt_gdikmt_d3dkmt.c.obj "
"In file included from ../src/gallium/auxiliary/gdikmt/gdikmt_d3dkmt.c:2: ../src/gallium/auxiliary/gdikmt/gdikmt.h:9:10: fatal error: d3dkmthk.h: No such file or directory 9 | #include <d3dkmthk.h>"

Our team tried driver cross-compilation in the past. Unfortunately, WDK in MinGW headers is too old and a lot of functions are missing. Currently, we expect to compile drivers with WDK for Server 2022 with a lot of new APIs (like memory management). "d3dkmthk.h" is a WDK header (https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/d3dkmthk/) that just missing in MinGW headers.

If compiling in windows one stills needs those header files from WDK right?

Yes, you must install SDK and WDK.

Is there a way when cross compiling in linux to make MinGW locate those header files?

Yes, but very complicated. Install WDK on Windows and copy everything that is needed for compilation (lib, dll, pdb, header, etc) to Linux MinGW headers directory. Don't forget that MinGW uses *so instead of *dll, *a instead of *lib, so you also need to rename files and maybe strip or something else.

[Usulyre]

Download link in this issue:
(#1076)
Also, has anybody tried to cross compile it in Linux like debian bookworm?
I'm getting an error regarding "d3dkmthk.h: No such file or directory"
"Compiling C object src/gallium/auxiliary/libgallium.a.p/gdikmt_gdikmt_d3dkmt.c.obj FAILED: src/gallium/auxiliary/libgallium.a.p/gdikmt_gdikmt_d3dkmt.c.obj "
"In file included from ../src/gallium/auxiliary/gdikmt/gdikmt_d3dkmt.c:2: ../src/gallium/auxiliary/gdikmt/gdikmt.h:9:10: fatal error: d3dkmthk.h: No such file or directory 9 | #include <d3dkmthk.h>"

Our team tried driver cross-compilation in the past. Unfortunately, WDK in MinGW headers is too old and a lot of functions are missing. Currently, we expect to compile drivers with WDK for Server 2022 with a lot of new APIs (like memory management). "d3dkmthk.h" is a WDK header (https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/d3dkmthk/) that just missing in MinGW headers.

If compiling in windows one stills needs those header files from WDK right?

Yes, you must install SDK and WDK.

Is there a way when cross compiling in linux to make MinGW locate those header files?

Yes, but very complicated. Install WDK on Windows and copy everything that is needed for compilation (lib, dll, pdb, header, etc) to Linux MinGW headers directory. Don't forget that MinGW uses *so instead of *dll, *a instead of *lib, so you also need to rename files and maybe strip or something else.

Where would MinGW headers directory be located in debian or Ubuntu?

[Xalares]

Hi @Usulyre, firstly thanks for your guide ! It was really helpful, and I managed to compile the driver, even if they needed specter library, idk why... Can you tell me what was your method to install the drivers, please ? Thank you !

[davispuh]

Also, has anybody tried to cross compile it in Linux like debian bookworm?
I'm getting an error regarding "d3dkmthk.h: No such file or directory"

Our team tried driver cross-compilation in the past. Unfortunately, WDK in MinGW headers is too old and a lot of functions are missing. Currently, we expect to compile drivers with WDK for Server 2022 with a lot of new APIs (like memory management). "d3dkmthk.h" is a WDK header (https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/d3dkmthk/) that just missing in MinGW headers.

Few months ago I tried this aswell and came to same conclusion.

Is there a way when cross compiling in linux to make MinGW locate those header files?

Yes, but very complicated. Install WDK on Windows and copy everything that is needed for compilation (lib, dll, pdb, header, etc) to Linux MinGW headers directory. Don't forget that MinGW uses *so instead of *dll, *a instead of *lib, so you also need to rename files and maybe strip or something else.

Yep I tried this and unfortunately it's not really doable without a lot of work.
The issue is that Windows SDK/WDK headers depend on MSVC features and GCC fails to compile with them. So essentially you need to edit Window's header files to make them work with GCC... And that work will be kinda wasted anyway because you can't really redistribute those because of Microsoft copyright. Basically we really need MinGW headers to be updated.

Another way might be to try and get MSVC build with Wine or something like that.

Where would MinGW headers directory be located in debian or Ubuntu?

Don't know but in Arch they are in /usr/x86_64-w64-mingw32/include

[stuaxo]

Is there an upstream bug in MinGW for this, while it won't help in the short term, in the longer term it gives a chance for it to be resolved.

[YusufKhan-gamedev]

I beleive there is a mingw-directx-headers package somewhere...it may be inside mingw iirc.

[Marietto2008]

https://gitlab.freedesktop.org/uploads/195b600a19ee5dacdf9f217066b99505/viogpu3d.zip = 404

[sharkautarch]

I think that there's also a version of the d3dkmthk.h header in the mesa repo here: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/include/drm-uapi/d3dkmthk.h?ref_type=heads
Tho I'm not sure if it might be missing some of the stuff defined in the windows documentation https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/d3dkmthk/

The issue is that Windows SDK/WDK headers depend on MSVC features and GCC fails to compile with them. So essentially you need to edit Window's header files to make them work with GCC... And that work will be kinda wasted anyway because you can't really redistribute those because of Microsoft copyright. Basically we really need MinGW headers to be updated.

Instead of trying to compile on linux using gcc, I think you may want to try compiling using either clang or this custom version of llvm patched to be more compatible with msvc features: https://github.com/backengineering/llvm-msvc

Note that this custom version of llvm is more meant for windows users who want llvm to work more like msvc, but according to the README:

Q: Can it run on linux?
A: Yes.

[Marietto2008]

I'm not a coder. To be able to compile the whole thing will take ages for me. Can some one point me to a pre compiled version that I can test out of the box ? thanks.

[Usulyre]

I'm not a coder. To be able to compile the whole thing will take ages for me. Can some one point me to a pre compiled version that I can test out of the box ? thanks.

Here is one but I am not sure it is up to date.

https://gitlab.freedesktop.org/mesa/mesa/uploads/195b600a19ee5dacdf9f217066b99505/viogpu3d.zip

[Usulyre]

Hi @Usulyre, firstly thanks for your guide ! It was really helpful, and I managed to compile the driver, even if they needed specter library, idk why... Can you tell me what was your method to install the drivers, please ? Thank you !

Hi, did you cross compile it successfully in linux? If you did, is it the most up to date version?

If so, can you show the steps for that? Or do you have a upload link to share with others?

I haven't yet installed the current version because I didn't get it to compile correctly.

[Usulyre]

I think that there's also a version of the d3dkmthk.h header in the mesa repo here: https://gitlab.freedesktop.org/mesa/mesa/-/blob/main/include/drm-uapi/d3dkmthk.h?ref_type=heads Tho I'm not sure if it might be missing some of the stuff defined in the windows documentation https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/d3dkmthk/

The issue is that Windows SDK/WDK headers depend on MSVC features and GCC fails to compile with them. So essentially you need to edit Window's header files to make them work with GCC... And that work will be kinda wasted anyway because you can't really redistribute those because of Microsoft copyright. Basically we really need MinGW headers to be updated.

Instead of trying to compile on linux using gcc, I think you may want to try compiling using either clang or this custom version of llvm patched to be more compatible with msvc features: https://github.com/backengineering/llvm-msvc

Note that this custom version of llvm is more meant for windows users who want llvm to work more like msvc, but according to the README:

Q: Can it run on linux?
A: Yes.

Might try this as well.

[Marietto2008]

I'm not a coder. To be able to compile the whole thing will take ages for me. Can some one point me to a pre compiled version that I can test out of the box ? thanks.

Here is one but I am not sure it is up to date.

https://gitlab.freedesktop.org/mesa/mesa/uploads/195b600a19ee5dacdf9f217066b99505/viogpu3d.zip

It is dated : 24.07.2023 16:05 ; is it up to date ? if not,can someone upload an up to date precompiled version ? thanks.

[Marietto2008]

I'm not a coder. To be able to compile the whole thing will take ages for me. Can some one point me to a pre compiled version that I can test out of the box ? thanks.

Here is one but I am not sure it is up to date.

https://gitlab.freedesktop.org/mesa/mesa/uploads/195b600a19ee5dacdf9f217066b99505/viogpu3d.zip

I'm trying to install it,but it won't. Can you explain what should I do to install it ? (on Windows 7 x64 bit)

This is the error that it gives :

translation : the selected INF does not support this installation method.

It can't be installed neither using the traditional method :

Translation :

The folder does not contains a driver compatible with the device. Please be sure that it is compatible with Windows 64 bit.

Yes,I'm using Windows 7 x64 bit.

[RedGreenBlue09]

That driver is built for Windows 10. No support for Windows 7 yet.

[Marietto2008]

That driver is built for Windows 10. No support for Windows 7 yet.

:-(

[SimoneN64]

I followed all the instructions and did not change anything in the source / Visual Studio project files, and I get this compilation error:

[kostyanf14]

I followed all the instructions and did not change anything in the source / Visual Studio project files, and I get this compilation error:

Looks like you use the latest EWDK/WDK. Microsoft changed the requirements for driver in it. You should use this instruction for building virtio-win drivers https://virtio-win.github.io/Development/Building-the-drivers-using-Windows-11-21H2-EWDK

[Burinis]

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

[Segment0895]

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!

[Marietto2008]

If there is a driver that's compatible with windows xp,maybe there is one compatible with windows 7 ?