jamesstringerparsec / Easy-GPU-PV

A Project dedicated to making GPU Partitioning on Windows easier!
4.42k stars 443 forks source link

Workaround: simply add support for vulkan and opengl support #342

Open simonlsp opened 1 year ago

simonlsp commented 1 year ago

Problem:

Cause:

Solution:

Known problems and workarounds

Result

All following results were captured while sunshine streaming.

image image

simonlsp commented 1 year ago

@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 commented 11 months ago

I can't run blender with this solution

ichinoboy commented 11 months ago

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 commented 11 months ago

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 commented 8 months ago

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:

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 commented 7 months ago

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 commented 7 months ago

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 commented 6 months ago

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 commented 6 months ago

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 commented 5 months ago

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 commented 5 months ago

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 commented 4 months ago

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 commented 3 months ago

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:

Screenshot 2024-08-09 012923 - Copy

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):

timminator commented 3 months ago

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 commented 3 months ago

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 image_2024-08-21_011700842

timminator commented 3 months ago

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 commented 2 months ago

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:

Screenshot 2024-08-09 012923 - Copy

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 commented 2 months ago

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.

image

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)

Am-ilcar commented 2 months ago

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.

wow! this worked for me! using parsec, but I had to first disconnect from Parsec, connect via HyperV, open FurMark and then close the HyperV window and connect again with Parsec! image

Thanks so much!

Mancitiss commented 1 month ago

I struggled to make FurMark works. After some hours I noticed that when connect using Hyper-V my screen was so small, so I think enhanced mode for Hyper-V was disabled somehow (it was enabled when it first created), so I turn on Enhanced Session Mode for Hyper-V and then connect again and it prompts me to choose a window size instead of the small window I had, and after that FurMark (32bit) runs successfully in Hyper-V. After that I connect with Parsec and it works (maybe after a restart, but it needs both Hyper-V and Parsec for Parsec to works as if Parsec is just taking the result from Hyper-V display).

If the Hyper-V screen is closed after connecting with Parsec, it forces quit Parsec.

Also there is a difference between Hper-V Enhanced Session Mode and connecting using Parsec is that when I connect using Parsec I can enter PIN (I set that up after finishing VM) to login, but Enhanced Session Mode can only use password.

Having to open and maintain 2 tabs at the same time is a bit more work but at least Vulkan does run now, I can open my game that didn't let me before because Vulkan didn't work before this.

I'm using RTX 4060 Laptop GPU, driver version 560.94, I also disabled integrated graphics just for this