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 09:12:25 +1000 Message-ID: <CAPM=9tx4wh-Lk6Dffsdh-7mYvXx+GX2AxhrGqFgyN8-AWJvP6A@mail.gmail.com> (raw) In-Reply-To: <CAPM=9txZpiCGkv3jiBC1F8pTe4A2pqWpQDyjRBXk2roFqw+0+Q@mail.gmail.com> On Wed, 20 May 2020 at 08:42, Dave Airlie <email@example.com> wrote: > > 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. 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.
next prev parent reply index Thread overview: 20+ 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-05-19 22:42 ` Dave Airlie 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-05-19 23:12 ` Dave Airlie [this message] 2020-05-20 7:10 ` Thomas Zimmermann 2020-05-20 7:42 ` [EXTERNAL] " Steve Pronovost 2020-05-20 11:06 ` Thomas Zimmermann
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=9tx4wh-Lk6Dffsdh-7mYvXx+GX2AxhrGqFgyN8-AWJvP6A@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