As some of the replies on the LKML suggest ( https://lkml.org/lkml/2020/5/19/742 https://lkml.org/lkml/2020/5/19/742 ) having this as a simple accelerator pipe,

As some of the replies on the LKML suggest ( https://lkml.org/lkml/2020/5/19/742 https://lkml.org/lkml/2020/5/19/742 ) having this as a simple accelerator pipe, but simple in the Linux perspective of re-using as many conventions and existing infrastructure as possible, and living _not_ as a display adapter (which will surely become far more complex later) would probably work for everyone; right now. The question is strongly dependent on future developments. With this being contributed as a GPU driver and the likely hope of this being used to run Linux applications within another OS, the question might be re-framed: How is this addition to the Linux Kernel API going to benefit _all_ users of Linux, not just users of WSL? Were Microsoft trying to provide a thin abstraction layer, so that drawing to a vGPU shard from windows on the application facing side of the Linux Kernel API looked like any other standard GPU under Linux, I feel it very likely everyone would feel positively about the changes. If this were about contributing Microsoft's vGPU driver for Linux, and in so doing also implementing only Freely Implementable Industry Standards (like Vulcan, OpenGL, or maybe others that Microsoft made/makes similarly free), while also not neglecting the expected core standards for other GPU drivers, then that also seems logically acceptable for everyone. Though my above suppositions are purely my opinion and guesses about the opinions of the maintainers for the software, while trying to think about how they approach their inherent responsibility for the long term maintenance and stability of a project they are clearly passionate about.