yes, I know about Hyper-V and I know that WSL is virtualized, but a standalone Linux VM is just Linux. It isn't WSL. WSL isn't just a name, it's the "Windows Subsystem for Linux" which is worded weird, but it's an NT Kernel subsystem which provides Linux compatibility. WSL v1 used syscall translation from Linux to Windows, meaning it was not a VM, and WSL 2 uses a Hyper-V virtual machine (two, actually) along with some glue to pull it together into a nice feature for Windows.
If you remove Windows, it's just a Linux VM. Just Linux. Azure already offer this as do all other cloud providers.
> yes, I know about Hyper-V and I know that WSL is virtualized, but a standalone Linux VM is just Linux. It isn't WSL. WSL isn't just a name, it's the "Windows Subsystem for Linux" which is worded weird, but it's an NT Kernel subsystem which provides Linux compatibility. WSL v1 used syscall translation from Linux to Windows, meaning it was not a VM, and WSL 2 uses a Hyper-V virtual machine (two, actually) along with some glue to pull it together into a nice feature for Windows.
I'm probably not being that clear with the terminology, I'm referring to WSL2(WSL v1 is the legacy translation layer that isn't important here, I was always referring to WSL2).
> If you remove Windows, it's just a Linux VM. Just Linux. Azure already offer this as do all other cloud providers.
Different VM hypervisors have the ability to expose additional features to guest operating systems, in this case a Hyper-V/WSL2 host like Azure can provide critical functionality to the guest Linux VM that other hypervisors are not able to provide.
If you remove the Hyper-V/WSL2 host you lose the ability for the Linux guest userspace applications to make use of libraries like libd3d12.so and libdirectml.so.
The fundamental issue is that the WSL2 Linux userspace(which is basically a port of a number of Windows userspace components to Linux) has closed source libraries like libd3d12.so and libdirectml.so which have a hard requirement on dxgkrnl and a compatible Hyper-V hypervisor/Windows based VM host. If Linux applications are developed targeting these closed source libraries they will not function on normal non-WSL2/Hyper-V VM's.
> Over the last few Windows releases, we have been busy developing client GPU virtualization technology. This technology is integrated into WDDM (Windows Display Driver Model) and all WDDMv2.5 or later drivers have native support for GPU virtualization. This technology is referred to as WDDM GPU Paravirtualization, or GPU-PV for short. GPU-PV is now a foundational part of Windows and is used in scenarios like Windows Defender Application Guard, the Windows Sandbox or the Hololens 2 emulator. Today this technology is limited to Windows guests, i.e. Windows running inside of a VM or container.
> To bring support for GPU acceleration to WSL 2, WDDMv2.9 will expand the reach of GPU-PV to Linux guests. This is achieved through a new Linux kernel driver that leverages the GPU-PV protocol to expose a GPU to user mode Linux. The projected abstraction of the GPU follows closely the WDDM GPU abstraction model, allowing API and drivers built against that abstraction to be easily ported for use in a Linux environment.
> Projecting a WDDM compatible abstraction for the GPU inside of Linux allowed us to recompile and bring our premiere graphics API to Linux when running in WSL.
> This is the real and full D3D12 API, no imitations, pretender or reimplementation here… this is the real deal. libd3d12.so is compiled from the same source code as d3d12.dll on Windows but for a Linux target.
If you remove Windows, it's just a Linux VM. Just Linux. Azure already offer this as do all other cloud providers.