Sounds all good, some more comments and details below.
Hey guys,
Thanks for the discussion. I may not be able to immediately answer all of your questions, but I'll do my best 😊.
drivers/hyperv sounds like it could be a better location. We weren't too sure where to put this, we though /drivers/gpu would be appropriate given this deal with GPUs, but I get your point... this is a vGPU driver that really only works when being run under Hyper-V, so drivers/hyperv is likely more appropriate.
I think "it's a virtual gpu" is the wrong sales pitch, as is "only runs on $platform". We have lots of drm drivers in drivers/gpu that fit that bill. The better pitch I think is "it's a not a gpu, it's a dx12 protocol pipe" and "we actually do not want to integrate with the linux gpu ecosystem and primitives, we want to integrate with dx12 ecosystem and primitives to make the seamless rdp/rail/vail stuff work nicely". Below some more thoughts on the technical said.
In term of presentation, I need to clarify a few things. We announced today that we're also adding support for Linux GUI applications. The way this will work is roughly as follow. We're writing a Wayland compositor that will essentially bridge over RDP-RAIL (RAIL=Remote Application Integrated Locally). We're starting from a Weston base. Weston already has an RDP Backend, but that's for a full desktop remoting scheme. Weston draws a desktop and remote it over RDP... and then you can peek at that desktop using an rdp client on the Windows side. RAIL works differently. In that case our wayland compositor no longer paint a desktop... instead it simply forward individual visual / wl_surface over the RDP RAIL channel such that these visual can be displayed on the Windows desktop. The RDP client create proxy window for each of these top level visual and their content is filled with the data coming over the RDP channel. All pixels are owned by the RDP server/WSL... so these windows looks different than native window are they are painted and themed by WSL. The proxy window on the host gather input and inject back over RDP... This is essentially how application remoting works on windows and this is all publicly documented as part of the various RDP protocol specification. As a matter of fact, for the RDP server on the Weston side we are looking at continue to leverage FreeRDP (and provide fixes/enhancement as needed to the public project). Further, we're looking at further improvement down this path to avoid having to copy the content over the RAIL channel and instead just share/swap buffer between the guest and the host. We have extension to the RDP protocol, called VAIL (Virtualized Application Integrated Locally) which does that today. Today this is only use in Windows on Windows for very specific scenario. We're looking at extending the public RDP protocol with these VAIL extension to make this an official Microsoft supported protocol which would allow us to target this in WSL. We have finished designing this part in details. Our goal would be to leverage something along the line of wl_drm, dma-buf, dma-fence, etc... This compositor and all our contribution to FreeRDP will be fully open source, including our design doc. We're not quite sure yet whether this will be offered as a separate project entirely distinct from it's Weston root... or if we'll propose an extension to Weston to operate in this mode. We would like to build it such that in theory any Wayland compositor could add support for this mode of operation if they want to remote application to a Windows host (over the network, or on the same box).
Sounds like a solid plan for presentation. I think this is all up to wayland/weston folks to figure out with you, from the kernel side I have only one concern (and I discussed that with a few folks already on irc, I think they're at least on this thread involved within microsoft too in some form): If we do integrate with linux concepts like wl_drm/dma-buf/fence and so on then we end up with a normal gpu driver, with with lots of blobby components all around that can't be opened (since large chunks written by hw vendors, so nothing microsoft can do about them). That's the awkward exception (why microsoft but not other gpu hw vendors/plaforms/whatever?) that we need to avoid.
But wayland doesn't really need dma-buf and the wl_drm protocols afaiui, as long as the egl extensions work you can have whatever private wayland protocol in your winsys code you want to shovel the buffers and syncobj from client to the wayland-rdp-rail compositor. If that uses dx12 native handles for these things we side-step the awkward exception question for linux gpu stack since it all stays 100% contained in drivers/hv. Just try to avoid the nvidia fail of insisting that you need your own set of egl extensions (egl_streams and egl_drm_kms_reinvented_but_badly and a few others iirc) for everything, that makes it very painful for all the compositor projects since they need duplicated code for no good reason :-)
Also looking at the fun the virtio folks have right now trying to get virgl dma-buf handles in the guest shared with other virtio devices or virgl instance in some other guest and getting it working ... If you avoid the dma-buf integration that might also sidestep a lot of technical headaches and be the simpler solution. At least as long as we're talking about wsl2 only.
We see /dev/dxg really as a projection of the GPU when running in WSL such that the GPU can be shared between WSL and the host... not something that would coexist "at the same time" with a real DRM GPU.
We have consider the possibility of bringing DX to Linux with no Windows cord attached. I'm not ready to discuss this at this time 😊... but in the hypothetical that we were do this, DX would be running on top of DRI/DRM on native Linux. We likely would be contributing some changes to DRM to address area of divergence and get better mapping for our user mode driver, but we wouldn't try to shoehorn /dev/dxg into the picture. In that hypothetical world, we would essentially have DX target DRM on native Linux and DX continue to target DXG in WSL to share the GPU with the host. I think this further reinforce the point you guys were making that the right place for our current dxgkrnl driver to live in would be /drivers/hyperv/dxgkrnl. In insight, I totally agree 😊.
Â
We had a pile of discussions on irc about some of the ideas floating
around for extending drm with some of the newer memory/sync concepts. So
very much interested, but that's indeed a different fish and most
likely will look a lot different to the dxgkrnl interface, while ofc
still aiming to give the same power to apps. At least that's the goal,
but aside from some prototype in some place this really doesn't exist
yet anywhere.
I think this cover all questions, let me know if I missed anything.
I think it's all good.