On Wed, 20 May 2020 at 08:42, Dave Airlie airlied@gmail.com wrote:
On Wed, 20 May 2020 at 02:33, Sasha Levin sashal@kernel.org wrote:
There is a blog post that goes into more detail about the bigger picture, and walks through all the required pieces to make this work. It is available here: https://devblogs.microsoft.com/directx/directx-heart-linux . The rest of this cover letter will focus on the Linux Kernel bits.
Overview
This is the first draft of the Microsoft Virtual GPU (vGPU) driver. The driver exposes a paravirtualized GPU to user mode applications running in a virtual machine on a Windows host. This enables hardware acceleration in environment such as WSL (Windows Subsystem for Linux) where the Linux virtual machine is able to share the GPU with the Windows host.
The projection is accomplished by exposing the WDDM (Windows Display Driver Model) interface as a set of IOCTL. This allows APIs and user mode driver written against the WDDM GPU abstraction on Windows to be ported to run within a Linux environment. This enables the port of the D3D12 and DirectML APIs as well as their associated user mode driver to Linux. This also enables third party APIs, such as the popular NVIDIA Cuda compute API, to be hardware accelerated within a WSL environment.
Only the rendering/compute aspect of the GPU are projected to the virtual machine, no display functionality is exposed. Further, at this time there are no presentation integration. So although the D3D12 API can be use to render graphics offscreen, there is no path (yet) for pixel to flow from the Linux environment back onto the Windows host desktop. This GPU stack is effectively side-by-side with the native Linux graphics stack.
Okay I've had some caffiene and absorbed some more of this.
This is a driver that connects a binary blob interface in the Windows kernel drivers to a binary blob that you run inside a Linux guest. It's a binary transport between two binary pieces. Personally this holds little of interest to me, I can see why it might be nice to have this upstream, but I don't forsee any other Linux distributor ever enabling it or having to ship it, it's purely a WSL2 pipe. I'm not saying I'd be happy to see this in the tree, since I don't see the value of maintaining it upstream, but it probably should just exists in a drivers/hyperv type area.
Having said that, I hit one stumbling block: "Further, at this time there are no presentation integration. "
If we upstream this driver as-is into some hyperv specific place, and you decide to add presentation integration this is more than likely going to mean you will want to interact with dma-bufs and dma-fences. If the driver is hidden away in a hyperv place it's likely we won't even notice that feature landing until it's too late.
I would like to see a coherent plan for presentation support (not code, just an architectural diagram), because I think when you contemplate how that works it will change the picture of how this driver looks and intergrates into the rest of the Linux graphics ecosystem.
As-is I'd rather this didn't land under my purview, since I don't see the value this adds to the Linux ecosystem at all, and I think it's important when putting a burden on upstream that you provide some value.
I also have another concern from a legal standpoint I'd rather not review the ioctl part of this. I'd probably request under DRI developers abstain as well.
This is a Windows kernel API being smashed into a Linux driver. I don't want to be tainted by knowledge of an API that I've no idea of the legal status of derived works. (it this all covered patent wise under OIN?)
I don't want to ever be accused of designing a Linux kernel API with illgotten D3DKMT knowledge, I feel tainting myself with knowledge of a properietary API might cause derived work issues.
Dave.