Microsoft's Hyper-V DRM Display Driver Will Land For Linux 5.14

[phoronix]

Phoronix: Microsoft's Hyper-V DRM Display Driver Will Land For Linux 5.14

Last summer Microsoft engineers posted a DRM kernel display driver for their Hyper-V synthetic video device. One year later after going through a few rounds of code review, this Hyper-V DRM driver will be going mainline with the upcoming Linux 5.14 kernel cycle...

https://www.phoronix.com/scan.php?page=news_item&px=Linux-5.14-Hyper-V-Display

[Quackdoc]

I wonder if this will get the OGL passthrough on hyper-v, might be nice if it does. but at the same time, not a fan of windows only stuff in the kernel at all.

[flower]

I wonder if this will get the OGL passthrough on hyper-v, might be nice if it does. but at the same time, not a fan of windows only stuff in the kernel at all.

same

this is just ms trying to push their "server" os.
same with wsl for dev workstations.

[microcode]

not a fan of windows only stuff in the kernel at all.

I get it, but think of it like all the hardware the kernel supports: literally none of the chips that you can run Linux on right now have both a publicly developed design and a publicly developed manufacturing process, nor do any of the hardware devices supported by the DRM. Linux hardware platforms are all proprietary, and most firmware that desktop Linux runs on is proprietary... so aside from being a software layer, Hyper-V SVD doesn't differ much from other platforms.

[kpedersen]

Possibly a little childish but I would get some smug satisfaction that the Linux kernel accepts VMware, VBox, Parallels, etc, drivers into the kernel but excluding anything from Microsoft.

To be fair, if the Linux kernel was a business, it wouldn't be unheard of for them to cease doing business with a company that has publicly called them "A cancer" and other derogative nonsense.

[Quackdoc]

I get it, but think of it like all the hardware the kernel supports: literally none of the chips that you can run Linux on right now have both a publicly developed design and a publicly developed manufacturing process, nor do any of the hardware devices supported by the DRM. Linux hardware platforms are all proprietary, and most firmware that desktop Linux runs on is proprietary... so aside from being a software layer, Hyper-V SVD doesn't differ much from other platforms.

I understand why, and acknowledge that it is the way it needs to be, but it doesn't mean I like it lol

[plan-g]

I tried this out briefly last night with Fedora 34 + Gnome 40. It automatically used wayland + llvmpipe and now resolution switching works. It is not locked to the resolution set in GRUB’s coming.

[Quackdoc]

I tried this out briefly last night with Fedora 34 + Gnome 40. It automatically used wayland + llvmpipe and now resolution switching works. It is not locked to the resolution set in GRUB’s coming.

has the kernel vgpu paravirt stuff been pushed to the kernel yet? GPUPV should work on hyper-v soon if so. I know the WSL2 opengl accel is quite similar to GPUPV, but not the same if I remeber right

[plan-g]

I'm not too sure about the GPU paravirtualization. I still need to dig in a bit more. Here's how I understand it right now:

The WSL2 stuff has 2 parts.
- paravirtualization, based on some sort of directx passthrough (/dev/dxg) rather than PCI (SR-IOV or passthrough). This allows GPU access, and from my understanding does not provide a framebuffer
- The actual framebuffer is in Linux-managed memory, then remoted from wayland (weston specifically) over a network-based protocol (RDP/RAIL)
(edit: here's a better overview WSLg Architecture | Windows Command Line (microsoft.com))

This driver (DRM-Hyper-V) is just a framebuffer device, it does not offer any GPU functionality. If there was support to create a /dev/dxg for a regular VM, then I suppose a gallium driver could replace llvmpipe to take advantage of those GPU resources and render into a Wayland-managed buffer. From there the Wayland compositor (Gnome or KDE probably) would render that into the actual framebuffer (DRM-Hyper-V). That would give you some sort of accelerated graphics path for the VMs emulated console.

The other option is to use the same gallium + /dev/dxg approach to accelerate off-screen FBs, then remote those using Gnome's desktop sharing and skip this new framebuffer driver altogether. Personally I don't want to depend on a running desktop environment to do the remoting so I'm not going to pursue that route

[plan-g]

I posted a quick video comparison here - the new driver with the wayland stack feels faster and looks smoother.

Testing drm-hyperv driver in Fedora 34 (github.com)