From: Dave Airlie <firstname.lastname@example.org> To: Sasha Levin <email@example.com> Cc: "Deucher, Alexander" <firstname.lastname@example.org>, "Chris Wilson" <email@example.com>, "Ville Syrjälä" <firstname.lastname@example.org>, "Hawking Zhang" <Hawking.Zhang@amd.com>, "Ursulin, Tvrtko" <email@example.com>, firstname.lastname@example.org, email@example.com, "Greg Kroah-Hartman" <firstname.lastname@example.org>, email@example.com, LKML <firstname.lastname@example.org>, dri-devel <email@example.com>, firstname.lastname@example.org, email@example.com, "Linux Fbdev development list" <firstname.lastname@example.org>, email@example.com, firstname.lastname@example.org Subject: Re: [RFC PATCH 0/4] DirectX on Linux Date: Wed, 20 May 2020 08:42:43 +1000 Message-ID: <CAPM=9txZpiCGkv3jiBC1F8pTe4A2pqWpQDyjRBXk2roFqw+0+Q@mail.gmail.com> (raw) In-Reply-To: <email@example.com> On Wed, 20 May 2020 at 02:33, Sasha Levin <firstname.lastname@example.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. Dave.
next prev parent reply index Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-05-19 16:32 Sasha Levin 2020-05-19 16:32 ` [RFC PATCH 2/4] gpu: dxgkrnl: hook up dxgkrnl Sasha Levin 2020-05-19 16:32 ` [RFC PATCH 3/4] Drivers: hv: vmbus: " Sasha Levin 2020-05-19 16:32 ` [RFC PATCH 4/4] gpu: dxgkrnl: create a MAINTAINERS entry Sasha Levin [not found] ` <email@example.com> 2020-05-19 17:19 ` [RFC PATCH 1/4] gpu: dxgkrnl: core code Greg KH 2020-05-19 17:21 ` Greg KH 2020-05-19 17:45 ` Sasha Levin 2020-05-20 6:13 ` Greg KH 2020-05-19 17:27 ` Greg KH 2020-05-19 19:21 ` [RFC PATCH 0/4] DirectX on Linux Daniel Vetter 2020-05-19 20:36 ` Sasha Levin 2020-05-20 10:37 ` Jan Engelhardt 2020-06-28 23:39 ` James Hilliard 2020-05-19 22:42 ` Dave Airlie [this message] 2020-05-19 23:01 ` Daniel Vetter 2020-05-20 3:47 ` [EXTERNAL] " Steve Pronovost [not found] ` <CAKMK7uFubAxtMEeCOYtvgjGYtmDVJeXcPFzmRD7t5BUm_GPP0w@mail.gmail.com> [not found] ` <MWHPR21MB02870909F08EBA08EB903635C7B60@MWHPR21MB0287.namprd21.prod.outlook.com> 2020-05-20 15:34 ` Steve Pronovost 2020-06-16 10:51 ` Pavel Machek 2020-05-19 23:12 ` Dave Airlie 2020-06-16 10:51 ` Pavel Machek 2020-06-16 13:21 ` Sasha Levin 2020-05-20 7:10 ` Thomas Zimmermann 2020-05-20 7:42 ` [EXTERNAL] " Steve Pronovost 2020-05-20 11:06 ` Thomas Zimmermann 2020-06-16 10:51 ` Pavel Machek 2020-06-16 13:28 ` Sasha Levin 2020-06-16 14:41 ` Pavel Machek 2020-06-16 16:00 ` Sasha Levin
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to='CAPM=9txZpiCGkv3jiBC1F8pTe4A2pqWpQDyjRBXk2roFqw+0+Q@mail.gmail.com' \ --firstname.lastname@example.org \ --cc=Hawking.Zhang@amd.com \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ --email@example.com \ --firstname.lastname@example.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
Linux-HyperV Archive on lore.kernel.org Archives are clonable: git clone --mirror https://lore.kernel.org/linux-hyperv/0 linux-hyperv/git/0.git # If you have public-inbox 1.1+ installed, you may # initialize and index your mirror using the following commands: public-inbox-init -V2 linux-hyperv linux-hyperv/ https://lore.kernel.org/linux-hyperv \ email@example.com public-inbox-index linux-hyperv Example config snippet for mirrors Newsgroup available over NNTP: nntp://nntp.lore.kernel.org/org.kernel.vger.linux-hyperv AGPL code for this site: git clone https://public-inbox.org/public-inbox.git