| HN Mirror

From the sound of things, it is really more that microsoft has little interest in setting up some form of standards comittee over the API. They could potentially provide the source for the linux version of DirectX Core and Direct X 12, but realistically that does little good.

Long story short (read on for details), there is a LOT of work needed beyond just releasing the source of the DirectX libraries to make anything usable on Linux. Microsoft would need to be able to justify to shareholders the spending of all the time and effort needed, which means they need to get something of value. Since the Linux port of DirectX libraries shares the source with the windows version, it seems risky for them to accept outside contributions, since that will either fork the codebase, or pull those changes into the windows version, which feels like a potentially massive hole for people to try to get Patent technologies into the windows implementation, and then sue Microsoft. I'm not sure the advantage in enabling the game studios to more easily port their games to Linux (the main other benefit to Microsoft I see) is worth it, especially since Proton exists, making "porting" mostly a QA exercise, and possibly adding some proton specific optimizations.

The existing DirectX libraries communicate with the DirectX User Mode Driver over a custom interface. Without the GPU makers officially compiling and supporting the User Mode Driver, nothing useful happens. Further it uses an interface to the kernel that is totally alien to linux. Proper kernel drivers that understand this interface and can drive the physical device would be needed, or the libraries changed to communicate over the existing DRM interfaces.

One major problem is that for a non-exclusive mode, the code would need to interoperate with the GL/Vulkin user mode drivers.

On Windows my understanding is that alternate APIs are implemented by having the surface creation code call into DirectX's version, but after that point remaining calls are basically directed to very same DirectX User Mode Driver, which has extra code specific to those APIs to convert those calls into whatever underlying commands need to be sent to the GPU, and sends them along to the hardware exactly as it does for DirectX. The low level commands for the GPU are basically a black box to the DirectX stack, so it does not care what triggered the User Mode Driver to issue them.

For open source drivers, I'm not sure that the MESA/Gallium stack is designed to be able to handle a fully separate user mode driver also talking directly to the GPU via DRI. My very strong suspicion is most such drivers are not designed for that, so the MESA/Gallium driver would need to become unified with the DirectX User Mode driver for an open source route. While possible since Gallium was designed to be able to support multiple APIs, it is basically certain that the way that is approached will not mesh perfectly with the way the DirectX libraries try to interface with the User Mode Driver.

For the NVIDIA proprietary blob driver route, things might be easier, as it is probably feasible to merge the DirectX User Mode Driver with the user mode portions of the existing driver, given that NVidia can unilaterally change the internal architecture of their proprietary drivers without needing to coordinate with anyone, as long as they maintain the CUDA/OpenGl/Vulkan/etc ABIs that apps directly interface with.