WSL 2 runs on a subset of Hyper-V, and on a hypervisor, so basically yes.
However, there's some interesting things going on in WSL 2 versus a "normal" Hyper-V virtual machine. For example, a Linux distro running on WSL can (and will) use GPU partitioning (aka PCI/GPU passthrough) and a special implementation of DirectX enabling the installed video card to accelerate graphics within X and/or Wayland.
Although this feature can be enabled with a lot of hacking in both the Linux guest and vanilla Hyper-V on the host (the latter through Powershell) it is officially unsupported on Windows 10 and Windows 11, and is only supported on Windows Server.
Oh, I thought GPU passthrough was enabled on vanilla Windows 11, but I didn't delve into that feature enough. It's still extremely impressive of course. Perhaps I should write another article about graphical features.
No, PCI-E passthrough is not enabled on non-Server, and you arguably wouldn't do this on a Windows hypervisor. anyways, you'd do it with a Linux+KVM hypervisor for either Linux or Windows guests.
Using GPU passthrough, however, is allowed. WSL2 does this by using the existing Mesa/DRI/DRM open source stack, but instead of a GPU-specific DRM driver, it is one that speaks WDDM (the DRM equivalent in the Windows driver stack), and only requires a GPU-specific ennoblement package (provided by the vendor, and matches the Windows driver it is talking to; AMD, Nvidia, and Intel all ship one inside of WSL2).
> No, PCI-E passthrough is not enabled on non-Server, and you arguably wouldn't do this on a Windows hypervisor. anyways, you'd do it with a Linux+KVM hypervisor for either Linux or Windows guests.
If it was enabled on Pro, I would use PCI passthrough. I use hyper-v for a Linux dev environment on a windows workstation. My NIC supports virtual functions, so if I could passthrough one to the dev VM, I wouldn't need software bridging and that might be nice. (OTOH, I don't know if my motherboard has reasonable passthrough groups and all the other stuff that makes passthrough never work for me)
I don't want two computers for work, and I'm not getting paid enough to fight with Linux GUI. I can do all the work without Linux GUI and have a working desktop (still W10 for now). I just need a VM to get a close enough match to prod VM.
I think part of the answer is that if you're going to use both it's nicer to use Windows with Linux as the guest than the reverse. MS clearly put a lot of effort to make the integration nice and it shows. Like how Parallels on macOS makes Windows a very nice guest.
If there was software that made Windows as seamless on Linux I bet it would get a lot of use.
It relies upon SR-IOV and only several server-specific Nvidia GPUs are listed as supported.
Intel's Flex dGPUs and Arc iGPUs have supported SR-IOV for years now, but they aren't listed there. It would be super awesome if Microsoft could add it for Intel Arc iGPUs, desktop versions of Windows, and WSL2! Intel's GPU SR-IOV already works with KVM on Linux!
> For example, a Linux distro running on WSL can (and will) use GPU partitioning (aka PCI/GPU passthrough) and a special implementation of DirectX
That is still just a normal VM, but it's nice that it's automated.
> enabling the installed video card to accelerate graphics within X and/or Wayland.
nit: X and/or Wayland is not involved in application rendering at all - its applications themselves that use the GPU and its acceleration directly.
Wayland and/or X is only involved when the apps are all done rendering[0], and the display servers own rendering is the comparatively simple task of stitching windows together[1], and sometimes not even that.
0: You can send buffers early over Wayland if you also send a sync fence, but this is just forwarded as a render dependency that the GPU scheduler will patiently wait for.
1: well also dealing with stuff like color transforms which can be complex to understand, but are computationally cheap and for fullscreen content possibly entirely free.
Contributing to display servers and following kernel KMS/drm stuff, but #wayland on OFTC or #sway on libera chat are both very helpful.
Also https://wayland.app to see the current Wayland protocols (the Wayland core protocol is mainly some common primitives, most stuff is across the other protocols). For example, the sync object stuff is in https://wayland.app/protocols/linux-drm-syncobj-v1 (in many cases handled by your toolkit or WSI of choice).
Don't WSL2 and the WinNT kernel both run on top of Hyper-V, on (very approximately) equal footing? The NT kernel, of course, has all the hardware access, not necessarily granted to other VMs, such as WSL2.
There are a variety of applications that it's not really possible to run natively on Linux, for example Widevine L1. I don't think there are any applications that can't run through WSL.
Thus far I have found the native WSL2 graphics integration to be pretty disappointing in comparison to what I used to get with X-server setup. Unfortunately the legacy X implementation doesn’t have the modern API and application developers are tapering their interest in it. Hopefully the groundswell of WSL2 support will improve this in time …
As an end user, the out of the box experience of getting a blurry window with the wrong content size isn't very useful. And I've never tried to actually configure it properly.
I wonder if it's a decent experience even when configured properly. In that case, why do all the IDEs come with remote development / WSL integrations that involve running the client on the Windows side?
Agreed. No way to really test WebGPU, for instance. You can't really test GPU drivers under Linux or using the native Windows browsers. Lots of incomplete attempts to make this work, none of which are reliable or easy to use.
However, there's some interesting things going on in WSL 2 versus a "normal" Hyper-V virtual machine. For example, a Linux distro running on WSL can (and will) use GPU partitioning (aka PCI/GPU passthrough) and a special implementation of DirectX enabling the installed video card to accelerate graphics within X and/or Wayland.
Although this feature can be enabled with a lot of hacking in both the Linux guest and vanilla Hyper-V on the host (the latter through Powershell) it is officially unsupported on Windows 10 and Windows 11, and is only supported on Windows Server.