Workaround: simply add support for vulkan and opengl support

[simonlsp]

Problem:

• Vulkan and opengl are not supported while streaming.

Cause:

• Parsec virtual monitor, idd monitor and usbmidd monitor are all connected to indirect display driver, which is NOT CONNECTED to PV GPU.
• The hyper-V monitor is connected to the hyper-v display driver, which is CONNECTED to PV GPU.
• Hyper-V moitor is off while host hyper-v manager disconnects from the VM.
• Without connected monitor, serveal PV gpu functions, including vulkan and opengl, were disabled.

Solution:

• Enable hyper-V display driver in device manager.
• Open display setting while streaming.
• Click "detect" in multi monitor menu.
• Hyper-v monitor should be detected (without need for host hyper-v manager connection).
• GPU-PV vulkan and opengl will be available for BOTH monitor now.

Known problems and workarounds

• Vulkan and opengl will only work if Hyper-V monitor is on, if you set the display mod to "only display on the other monitor", vulkan and opengl will be disabled again.
  • Solution: set your display mode to "extend", and arrange monitor layout like this, so your mouse pointer would not fly away.
• Parser / idd / usbmidd monitor is the 1st (and only) monitor before detection, but Hyper-V monitor will be the 1st monitor after detection. If the streaming monitor is set to DISPLAY1, Hyper-V monitor will be used after detection.
  •  Solution: use autohotkey and MultiMonitorTool to create a hotkey to swith primary monitor, and use sunshine for streaming. Sunshine use primary monitor for streaming if no streaming monitor is set. Then you could change streaming monitor with hotkey anytime (moonlight reconnection is needed after switching primary monitor).

Result

All following results were captured while sunshine streaming.

[simonlsp]

@Kodikuu With this workaround, I think it is time to change this line in the readme notes.

Vulkan renderer is unavailable and GL games may or may not work.

Yuzu emu and minecraft were tested, they worked flawlessly.

[KenZync]

I can't run blender with this solution

[ichinoboy]

Hi @simonlsp ,

I tried this in Windows 11 and it won't allow me to extend my monitor to 2nd one (Hyper-V) as it is not active. Do you have a workaround for this?

[iso2013]

When I change the display settings on my instance of Parsec, the parsec connection hangs (completely unresponsive) and I have to restart my PC (killing Parsec from task manager freezes the rest of the PC. Not really sure why)

Edit: Tried connecting via Parsec from a different computer (I was connecting from the same computer that hosts the VM) and the crashing issue is no longer there, but I can't extend the displays - it immediately switches back to 'Show only on x' every time on its own.

[djblue]

In trying out the above, I ran into some issues but found what seems to be an optimal solution for myself. I have no idea why this is working for me, but here are the tweaked steps that seem to work:

• Connect via Parsec / Moonlight
• Install the extra display with IddSampleDriver via scoop.
  • Not sure if this is only needed because I'm using Sunshine
• Install FurMark to help detect if OpenGL and Vulkan are available
  • Running it at this point should fail
• Re-enable the Microsoft Hyper-V Video Display adapter in Device manager
• Connect to the vm display via Hyper-V, while still connected via (Parsec / Moonlight)
  • Windows should now register two displays
• FurMark should now be able to open and you can confirm OpenGL is working
  • Vulkan doesn't work at this point for me
• Close the display for Hyper-V
• Now windows should only register a single display, but OpenGL and Vulkan should both be working in FurMark 🤯
• Never close FurMark, just keep it running in the background, not even running benchmarks, just open

If I ever close FurMark, things go back to broken, not sure why. I would assume that it is somehow keeping the graphics context up and available 🤔

Anyway, now I can freely disconnect/connect and not have to worry about juggling multiple monitors or ensuring the the graphics APIs are available and all my apps seem to work just fine 🎉 Hope this helps for those running into similar issues.

[TimotheFCN]

In trying out the above, I ran into some issues but found what seems to be an optimal solution for myself. I have no idea why this is working for me, but here are the tweaked steps that seem to work:

• Connect via Parsec / Moonlight

• Install the extra display with IddSampleDriver via scoop.

  • Not sure if this is only needed because I'm using Sunshine

• Install FurMark to help detect if OpenGL and Vulkan are available

  • Running it at this point should fail

• Re-enable the Microsoft Hyper-V Video Display adapter in Device manager

• Connect to the vm display via Hyper-V, while still connected via (Parsec / Moonlight)

  • Windows should now register two displays

• FurMark should now be able to open and you can confirm OpenGL is working

  • Vulkan doesn't work at this point for me

• Close the display for Hyper-V

• Now windows should only register a single display, but OpenGL and Vulkan should both be working in FurMark 🤯

• Never close FurMark, just keep it running in the background, not even running benchmarks, just open

If I ever close FurMark, things go back to broken, not sure why. I would assume that it is somehow keeping the graphics context up and available 🤔

Anyway, now I can freely disconnect/connect and not have to worry about juggling multiple monitors or ensuring the the graphics APIs are available and all my apps seem to work just fine 🎉 Hope this helps for those running into similar issues.

Since this works, it might be possible to create a simple script that runs at startup which enables the hyper-v display, launches a sample blank app requiring vulkan/opengl (but not rendering anything), then turns off the display driver I will be looking into that

[mikrofyr]

This seems to work. I do see some stuttering in vulkan applications though. Same applications run smoothly outside hyper-v.

Wondering if there is some performance hit related to the workaround, or if it is just in general a performance issue with the hyper-v VM.

Several other graphics applications runs very smooth in the hyper-v VM. (they are not using opengl/vulkan as far as I know)

[nenkoru]

Have you fixed/encountered a problem with a Sunshine when it takes 3-10 times to actually connect without having an error about no video stream incoming or just pitch black screen?

update: I managed to fix the black screen issue by basically increasing the timeout to 60 seconds in the source of Moonlight-qt

[rooftopdandelion]

Hi can anyone post their windows version while getting this working? I'm running into the same issue as @ichinoboy . I've worked through different possible solutions (including @djblue 's) but the hyper-v display never becomes active. Thanks in advance!

[waltmannz]

Can't seem to get vulkan working with this setup, running win11 a 4090 and driver 555.85, tried a lot of variations of the setup above but the FurMark vulkan test never worked.

[csitangelo]

Thanks for this, Vulkan worked straight away after re-enabling Hyper-V Display Driver. Sunshine selects idd automatically :)

Fixed Yuzu, Stardew Valley, DOOM Eternal and any other game that couldn't detect a GPU

[timminator]

Do any of you who have managed to get it working have any more insights? I'm facing the same problem as @waltmannz . Opengl works right away after enabling the Hyper-V-Monitor, but i am not able to get vulkan working, even after testing many variations. The tips mentioned by @djblue also didn't help. A question at @simonlsp: Where you using a specific Windows version on you host or in the virtual machine? I've noticed you alco commentated in this thread, where a Windows Insider Build was mentioned for the VM.

[timminator]

I were able to get quite a bit further over the last week. I did quite a lot of testing with different Nvidia drivers as im using a GTX 1660 TI. First of all i noticed that Nvidia seems to have added Vulkan support via GPU Paravirtualization in driver version 545.84, atleast for consumer graphics cards. The vkcube demo included in the VulkanSDK runs starting with this driver version. Since driver version 551.23 you can also successfully run vulkaninfo inside the VM. This indicates that Vulkan applications should be working in theory. Now it gets interesting: I noticed that the included demos in GPU Caps Viewer run aswell as shown in the first post by @simonlsp. But the Geexlab demos in standalone were crashing. This seemed odd to me. The only difference between them were there architecture as GPU Caps Viewer is a 32-bit application. So i tried running the Furmark 32-bit version instead - and it ran perfectly fine:

Whats weird is that the vkcube demo however is a 64 bit application. The 64 bit version of Furmark reports as a error message: "VK_ERROR_INITIALIZATION_FAILED (-3), unable to create the swapchain for GPU 0". I tried to investigate this further and created my own little Vulkan script that created a swapchain, but it worked compiled as a 32-bit and 64-bit application aswell. Maybe the issue is related to a certain Vulkan extension that is required by Furmark but not by the vkcube demo? But it looks a lot like a driver issue. I've also noticed another driver problem. The Geexlab demos and Furmark 32-bit only ran on a indirect display via virtual display driver or Parsec with Hyper-V display still enabled. Starting these two programs on the Hyper-V display resulted in a error message "VK_ERROR_DEVICE_LOST (-4)." In short: It looks like only 32-bit Vulkan applications, which are more complex than just a spinning cube, work at the moment, .

Below is a brief summary of my driver tests (I've always did a clean driver install via DDU on the host and created a fresh VM for consistent results):

• 537.58: No Vulkan support, no Vulkan extensions in GPU Caps Viewer, vulkaninfo throws error

• 545.84 (October 17th, 2023): Vkcube demo runs, GPU Caps Viewer lists Vulkan extensions, GPU Caps Viewer demo and Furmark 32-bit run on second display, vulkaninfo throws error

• 551.23: Vulkaninfo can be executed in terminal

• 555.85: GPU is registered in GPU Caps Viewer instead of just an empty window

• 560.70: Didn't notice any difference

[timminator]

Thanks for this, Vulkan worked straight away after re-enabling Hyper-V Display Driver. Sunshine selects idd automatically :)

Fixed Yuzu, Stardew Valley, DOOM Eternal and any other game that couldn't detect a GPU

@csitangelo What kind of GPU are you using? That really interests me because it works flawlessly for you. I would be grateful for an answer.

[UnstructuredFF]

In trying out the above, I ran into some issues but found what seems to be an optimal solution for myself. I have no idea why this is working for me, but here are the tweaked steps that seem to work:

• Connect via Parsec / Moonlight

• Install the extra display with IddSampleDriver via scoop.

  • Not sure if this is only needed because I'm using Sunshine

• Install FurMark to help detect if OpenGL and Vulkan are available

  • Running it at this point should fail

• Re-enable the Microsoft Hyper-V Video Display adapter in Device manager

• Connect to the vm display via Hyper-V, while still connected via (Parsec / Moonlight)

  • Windows should now register two displays

• FurMark should now be able to open and you can confirm OpenGL is working

  • Vulkan doesn't work at this point for me

• Close the display for Hyper-V

• Now windows should only register a single display, but OpenGL and Vulkan should both be working in FurMark 🤯

• Never close FurMark, just keep it running in the background, not even running benchmarks, just open

If I ever close FurMark, things go back to broken, not sure why. I would assume that it is somehow keeping the graphics context up and available 🤔

Anyway, now I can freely disconnect/connect and not have to worry about juggling multiple monitors or ensuring the the graphics APIs are available and all my apps seem to work just fine 🎉 Hope this helps for those running into similar issues.

I thank you greatly for this tutorial, I have Minecraft running in a VM with a smooth FPS of 300-500

[timminator]

I want to update my findings once more. I've tested quite a few vulkan applications with interesting results. Some seem to be crashing like Furmark 64 bit, whereas other application run just fine. These are my results on a GTX 1660 TI:

Runs: Detroit Become Human Wolfenstein II: The New Colossus Ghost Recon Breakpoint Counter Strike 2 Dota 2 Geekbench 6 Furmark 32 bit

Doesnt run: Quake 2 RTX Doom 2016 Doom Eternal The Crew Motorfest Rainbox Six Extraction GravityMark GPU Benchmark 3DMark Furmark 64 bit

Games that support more than one API where explicitly tested with the Vulkan API. This does not help narrowing it down, but it reflects the current state. It is interesting that Doom Eternal did not run on my setup, whereas @csitangelo mentioned that he was able to get it running. I am still really interested about the GPU you are using :-)

[nenkoru]

I were able to get quite a bit further over the last week. I did quite a lot of testing with different Nvidia drivers as im using a GTX 1660 TI. First of all i noticed that Nvidia seems to have added Vulkan support via GPU Paravirtualization in driver version 545.84, atleast for consumer graphics cards. The vkcube demo included in the VulkanSDK runs starting with this driver version. Since driver version 551.23 you can also successfully run vulkaninfo inside the VM. This indicates that Vulkan applications should be working in theory. Now it gets interesting: I noticed that the included demos in GPU Caps Viewer run aswell as shown in the first post by @simonlsp. But the Geexlab demos in standalone were crashing. This seemed odd to me. The only difference between them were there architecture as GPU Caps Viewer is a 32-bit application. So i tried running the Furmark 32-bit version instead - and it ran perfectly fine:

Whats weird is that the vkcube demo however is a 64 bit application. The 64 bit version of Furmark reports as a error message: "VK_ERROR_INITIALIZATION_FAILED (-3), unable to create the swapchain for GPU 0". I tried to investigate this further and created my own little Vulkan script that created a swapchain, but it worked compiled as a 32-bit and 64-bit application aswell. Maybe the issue is related to a certain Vulkan extension that is required by Furmark but not by the vkcube demo? But it looks a lot like a driver issue. I've also noticed another driver problem. The Geexlab demos and Furmark 32-bit only ran on a indirect display via virtual display driver or Parsec with Hyper-V display still enabled. Starting these two programs on the Hyper-V display resulted in a error message "VK_ERROR_DEVICE_LOST (-4)." In short: It looks like only 32-bit Vulkan applications, which are more complex than just a spinning cube, work at the moment, .

Below is a brief summary of my driver tests (I've always did a clean driver install via DDU on the host and created a fresh VM for consistent results):

• 537.58: No Vulkan support, no Vulkan extensions in GPU Caps Viewer, vulkaninfo throws error
• 545.84 (October 17th, 2023): Vkcube demo runs, GPU Caps Viewer lists Vulkan extensions, GPU Caps Viewer demo and Furmark 32-bit run on second display, vulkaninfo throws error
• 551.23: Vulkaninfo can be executed in terminal
• 555.85: GPU is registered in GPU Caps Viewer instead of just an empty window
• 560.70: Didn't notice any difference

Reproduced the same behaviour. Furmark x86 Vulkan works fine, but the x64.

Seems more like a driver issue according to different issues on github concerning the same error log about a swapchain . I am pretty much sure then those games executables that you mentioned are x86. And the others are x64. OpenGL works fine tho on both.

Host: Windows Server 2022 Guest: Windows 10 22H2 GPU: RTX 4090 Driver: 560.94

[nenkoru]

It's worth noting that this whole thing with the pass through works because of WDDM and Microsoft forcing vendors to create drivers complying with it. Here is a good comment on Reddit.

https://www.reddit.com/r/VFIO/comments/1300rlk/comment/k6wvkd1

edit1: And I guess it also boils down to the version of WDDMs on the host and guest machines. Perhaps users from above were using some version of a WDDM that is allowing to use Vulcan normally.

edit2: For me WDDM version from dxdiag(display 1) on the host shows 2.9 and according to the Wikipedia there been some changes to the stack since the version of mine. https://en.wikipedia.org/wiki/Windows_Display_Driver_Model

upd3: Okay ye, I installed Windows 11_23H2(August 2024 upd) as a host OS and Elden Ring started to run, even though the Furmark VK x64 still fails to run with the same instant exit. Dxdiag reports WDDM 3.1. Going to try Windows 11 as a guest now.

upd4: Well no, even with Windows 11 guest Furmark x64 fails to run, even though the x86 work just fine.

So TL;DR Vulkan only works for x86 executables at the moment of writing this comment. Which is sad as there are more and more games running x64 executables.

upd5: idk how I was able to run Elden Ring, now whenever I try to run it I always get the white screen at the start

upd6: nvm, it was related to my proxmox host settings for the hypervisor VM which is hosting the actual gaming VM. (had to tinker with hyper-v enlightenments and kvm paravirtualization stuff)