The problem is that they built an entirely independent graphics stack. It does not co-exist at all with any of the graphics subsystem which has been built up for many drivers and use-cases over the past 5-10 years.

What they should have done is approached the community with their idea and sought input on how to design their approach. We would have discussed solutions which integrated better into the existing stack. But, then they would be robbed of the chance to do a big announcement and get ahead of the press cycle with their bad driver.

I mean, the were actively asking how to better integrate it before it had gotten to the point of displaying graphics, with some mainline kernel devs questioning if it should be integrated with the graphics stack at all, and be pushed back into the hyperv side of things.

It's very clearly an RFC with an eye for "how can we better collaborate and who should we collaborate with?"

I think they need to better document and support a more opensource stack on the user side of things (maybe a vulkan or mesa targeting the WDDM ioctl interface rather than on the dx12 UAPI), but those are surmountable issues, and makes it look like the amdgpu side of the house.

It had gotten to the point where you can do machine learning and other CUDA applications, and that brings a lot more money than graphics.

WSL is definitely pulling an Embrace Extend Extinguish. I am not saying the new Microsoft is the same as Ballmer's, but still.

Full graphics is on the roadmap, basic compute was just an MVP.

Linus has said that he doesn't want discussions without code for the reasons I've stated.

All the complaints I've heard about how WSL didn't do the right thing make it sound like there is no right way, despite passthrough graphics drivers for otherwise totally proprietary stacks on hypervisor stacks from companies with blatant GPL violations ending up mainlined with praise (cough VMWare). And despite the fact that the only way that's been proven to virtualize graphics cards without 2stage MMUs is to replicate the host's ioctl layer into the guest. There's a reason why Virgl isn't used by anyone serious about perf, it's the fundamentally wrong architecture.

CUDA may be an MVP, but it's a damn useful and lucrative MVP.

Also, VFIO mdev can be used to virtualize graphics cards to virtual machines, both nVidia and Intel. Note this is not device assignment (that's "plain" VFIO); it's the host driver exposing a partly pass-through, partly emulated device that virtualizes the host device. mdev's design was initially a Red Hat-nVidia collaboration with input from Intel (I had a small role from the Red Hat side, mostly coming up with the name :-)) and implemented by nVidia, and is used in production with both Windows and Linux guests.

It's not full VFIO, but it still takes hardware support. It's not really a comparable solution.

Not necessarily. Nvidia doesn't have hardware support, rather the guest driver communicates changes to the page tables to the host driver in such a way that the host can establish shadow page tables that merge the guest and host translations.

That's not a great example though, because mdev on Nvidia is proprietary kernel module->proprietary guest kernel module->proprietary user driver.

And in that case too, the ioctl layer is almost entirely maintained across the boundaries like the scheme I'm saying. You need to do that or you almost certainly get a weird impedance mismatch between guest and host that destroys perf.

Even if nVidia's driver has a more lightweight abstraction compared to Intel's, and puts more stuff in userspace, that is not particularly relevant in my opinion: mdev only sits between host and guest driver and by design the host driver only emulates the bare minimum and multiplexes hardware resources instead. What happens in the guest between the driver and userspace does not matter to mdev.

It is relevant, because NVidia's binary driver looks like WDDM on every platform.

And Intel needs something like this either way because their hardware arch is different, and their GPU is heavily integrated with the main IOMMU.