[viogpu3d] Virtio GPU 3D acceleration for windows #943
Conversation
|
@max8rr8 Thank for a very impressive work you've done. Nice work! |
viogpu/viogpu3d/BUILDING.md
Outdated
| 5. Build and install mesa binaries: `ninja install` | ||
| 6. Go to `viogpu` directory of this repository | ||
| 7. Run: `.\build_AllNoSdv.bat` | ||
| 8. Compiled drivers will be available in `viogpu\viogpu3d\objfre_win10_amd64\amd64\viogpu3d` |
There was a problem hiding this comment.
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:
- What is
%MESA_PREFIX%and where it defined? - Can we use any precompiled MESA for Windows (for example https://fdossena.com/?p=mesa/index.frag)
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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.
- Acquire source code
git clone --branch viogpu_win https://gitlab.freedesktop.org/max8rr8/virglrenderer && cd virglrenderer - Create install directory
mkdir installand build directory:mkdir build && cd build - Configure build
meson --prefix=$(pwd)/../install(we set prefix to install libvirglrenderer not globally but to previously created dir install) - Compile and install
ninja install
Now ensure that qemu loads libvirglrenderer from install directory, this can be done by settingLD_LIBRARY_PATHto 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):
- Create mesa prefix dir
mkdir mesa_prefixand set envMESA_PREFIXto its path:$env:MESA_PREFIX="$PWD\mesa_prefix" - Get patched mesa source code
git clone --depth 10 --branch viogpu_win https://gitlab.freedesktop.org/max8rr8/mesaand then cd into itcd mesa - Create build directory
mkdir build && cd build - 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_PREFIXset installation path to dir created in step 1-Dgallium-drivers=virglbuild only virgl driver-Dgallium-d3d10umd=truebuild DirectX 10 user-mode driver (opengl one is build by default)-Dgallium-d3d10-dll-name=viogpu_d3d10name of generated d3d10 dll toviogpu_d3d10.dll-Dgallium-wgl-dll-name=viogpu_wglname of generated wgl dll toviogpu_wgl.dll-Db_vscrt=mtuse static c runtime (see this comment)
- 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)
- Acquire source code
git clone --branch viogpu_win https://github.com/max8rr8/kvm-guest-drivers-windowsand cd into itcd kvm-guest-drivers-windows - Go to viogpu
cd viogpu - (optional, but very useful) setup test code signning from visual studio
- 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
|
Changes:
|
|
Changes:
Pre-built driver provided in description was updated with these changes. |
|
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) envguest os: host os: qemu command line-display egl-headless,rendernode=/dev/dri/card1 -device virtio-vga-gl -trace enable="virtio_gpu*" -D qemu.log virglrenderer.loggl_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: 22qemu_strace.logvirtio_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 |
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. |
|
What versions of windows does it go down to? |
|
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 |
|
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. |
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.
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.
Nothing seems wrong in attached |
|
That's great @max8rr8!
For the retro direction, above was mentioned Win7 and in addition I think such virgl/venus GPU will be very useful also for:
|
|
I compiled and tried it, but I got the BSOD First, I compiled QEMU in MSYS2 like this: 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): It outputs to my root folder ( I signed the output in 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. |
|
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. |
|
Hi @RedGreenBlue09, it seems that kernel crash happened during driver unloading ( 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 This windbg command should add backtrace logging to all errors happening in dxgkrnl. After you ran that command continue kernel execution with windbg command |
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" |
|
... Network debug also hangs like serial. Interestingly that doesn't happen with ReactOS. |
|
I have no luck with live kernel debug. I tried using accel tcg, official qemu, none of these helps. If Edit: Even ditching OVMF for SeaBIOS, it still freezes. |
|
@max8rr8 Okay, I'm sorry for the rant. It doesn't hang forever, just 30 minutes :((. I tried your command and got an error: |
|
After reloading symbols, the error is gone. Here is the new log. |
Based on #943 Signed-off-by: Max Ramanouski <max8rr8@gmail.com> Signed-off-by: Kostiantyn Kostiuk <konstantin@daynix.com>
Based on #943 Signed-off-by: Max Ramanouski <max8rr8@gmail.com> Signed-off-by: Kostiantyn Kostiuk <konstantin@daynix.com>
Based on #943 Signed-off-by: Max Ramanouski <max8rr8@gmail.com> Signed-off-by: Kostiantyn Kostiuk <konstantin@daynix.com>
Based on #943 Signed-off-by: Max Ramanouski <max8rr8@gmail.com> Signed-off-by: Kostiantyn Kostiuk <konstantin@daynix.com>
Based on #943 Signed-off-by: Max Ramanouski <max8rr8@gmail.com> Signed-off-by: Kostiantyn Kostiuk <konstantin@daynix.com>
This changes will be used in 3D driver. Based on #943 Signed-off-by: Max Ramanouski <max8rr8@gmail.com> Signed-off-by: Kostiantyn Kostiuk <konstantin@daynix.com>
|
Are there any time frames when this might be a usable published driver? |
Unfortunately driver with mesa might not be the right production solution. |
|
I wonder if windows guets can make use of virtio-native-contex? Cause you know, the contexts are DRM ioctls, meanwhile windows has something different. |
I suspect that Mesa is the only reasonable solution. In particular, it is mandatory for GPU virtualization with untrusted guests on consumer hardware. This is because the shader compiler must run in the guest (not the host), and Mesa is the only open-source shader compiler available. |
I would like this being ported to Windows 7. |
There is also Proton (Steam solution to play Windows games on Linux) that works fine and can convert DX12 API to Vulkan and it will be more simple than implementing DX12 UMD on top of MESA. |
First of all, Windows 7 is dead. For the second one, we dropped Windows 7 support from all other drivers. In the end, GPU drivers for Win7 and Win10 are different from an infrastructure point of view. |
would user be able to play games on Windows 11 arm running under UTM on macOS arm64 (utmapp/UTM#4028)? HansKristian-Work/vkd3d-proton#1889 suggests it's not possible, so perhaps |
|
also https://github.com/microsoft?q=directx not sure if and how useful https://github.com/microsoft/DirectXShaderCompiler could be for this driver |
|
Ermm, in terms of shader compilers, to clear stuff up, there’s actually multiple separate issues wrt the need to use the mesa driver in the guest:
So yes, it really does seem like using mesa in the guest is the most straightforward path |
dxcompiler.dll seem to support both SPIRV and DXIL with HSLS as a go-between language https://github.com/microsoft/DirectXShaderCompiler/blob/main/docs/SPIR-V.rst. readme says dxcompiler.dll is also part of windows sdk |
https://github.com/microsoft/wslg/blob/main/README.md#opengl-accelerated-rendering-in-wslg WSLg also seem to be using mesa to run Linux GUI applications, so that's another +1. mesa is a submodule in that repo. the solution is not lightweight tho |
Proton is just wine fork with a bunch of haphazardly implemented hacks, most of which will never go upstream. And wine has a bunch of fundamental problems (ironically, pretty much all of them non-graphics related) that obliterate performance or even ability for an app to work at all. Such as atrocious sync implementation, replacement for which is being continuously sandbagged by kernel's bureaucrats. It may take decades or never to fix entire list of fundamental compatibility issues. And if you need a working application now, running mostly Windows native stack is the only option. But running that crap on bare hardware is lunacy. So, no, running broken wine and waiting for years for maintainers to wake up and approve patches, that may or may not appear, is neither simple or fast. It really either this or for everyone to build their hardware with dual GPUs just to passthrough the main one to Windows for native driver to take over. |
Which hacks are you referring to? |
|
another practical example: godotengine/godot#70315 they used a variant of https://gitlab.freedesktop.org/mesa/mesa/-/tree/main/src/microsoft/spirv_to_dxil after trying out the alternative HansKristian-Work/dxil-spirv#103 (comment). we can learn from their experiences and stay put with mesa choice to complete this pr |
|
Another example of driver using Mesa is SoftGPU:
SoftGPU supports Win9x/NT4 and maybe can be extended to XP (which may cover Vista/7 as well? But it's not a WDDM driver) |
Vista might be able to work with the older driver model but it won't provide the composition features in such case. |
|
Latest drivers from VirtualBox Guest Additions currently work fine (including DWM acceleration) in both Vista and 7, so you may want to look into the source of that. |
|
I'm a mesa developer watching this PR for a while. My opinion is you need a DX to VK translation layer anyway, either in host or guest because host (Linux) only provide Vulkan API. Do this in guest would be much simpler. You just need to implement a virtio-gpu based vulkan driver (either venus or native context), then use DXVK and VKD3D for DX API, Zink for OpenGL API, RustiCL for OpenCL API (these translation layers are build on top of Vulkan). All these components don't need to build from scratch, just need to adopt to the windows environment. This way you get all GPU APIs at once with reasonable effort. Otherwise you have to implement every API UMD from scratch for guest which is a big dev and maintain effort. Windows WSLg uses a native context way (WDDM level) to run DX12 UMD as guest UMD on top of host windows KMD first, then uses translation layer in guest (DZN for Vulkan and D3D12 for OpenGL) to translate Vulkan/OpenGL to DX12. |
Hi, Would you be able to implement something like that? |
I think so. |
|
bottom line: this is not the first time this problem is being solved. this pr is using mesa in its current state, is it the best approach? maybe not, but if multiple similar projects are using mesa, it's the one which works. pragmatic way is to move this pr forward and merged. first version doesn't have to be perfect, it (like any software) can improve later on |
Like, all of them. If it wasn't mostly made up from un-upstream'able hacks then it wouldn't be a fork of an active massive project. But it does use vkd3d/dxvk, just like vanilla wine, which would have to be used with Mesa anyway. Pretty much the only part that is relevant and relatively polished out. So ironic that with wine the graphics are fine yet everything else may fatally glitch out for your app but with qemu/kvm it's the exact opposite: you run "stable" native stack but graphics are even worse than running CPU-only (Mesa's llvmpipe) dxvk under vanilla wine. And, yes, I've tested that. |
Hello! This series of changes spanning across multiple repositories introduce support for 3d accelerated virtiogpu windows guests.
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.
viogpu_winKnown issues
FIXED:
Frames displayed on screen are lagging behindFIXED:
D3d10 clearing color is not supportedFIXED:
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