Microsoft Has Another Go At Their DirectX Linux Kernel Driver

[Quackdoc]

This makes me wonder why microsoft doesn't just emulate an existing virtual GPU implementation. We now have existing mainline drivers for both opengl and vulkan ones. Then all the nastiness for converting to directx can just live in windows-land where nobody has to deal with it.

2 possible answers, I think both are accurate

1. better integration. since WDDM 1.3 or so, all gpu drivers have support for para-virtualization at the driver level. theoretically this should mean near native preformance across all kinds of scenarios. as long as it can utilize the API, it should be near native. (this technically includes vulkan should microsoft ever choose to support it but... doubt)

2. that would require them supporting something open source that other people besides Microsoft could benefit from.

[torsionbar28]

2. that would require them supporting something open source that other people besides Microsoft could benefit from.

This part is key. All of Microsoft's FOSS contributions. All of it. 100%. Is for the express purpose of driving customers towards Microsoft products and services. They like to play the warm n fuzzy FOSS community card, but make no mistake, they are doing nothing, zero, in the name of fostering Linux community. They are leveraging Linux to drive Microsoft ecosystem growth. For example, more than half of all Azure instances are Linux. I don't blame them, after all, Linux is a direct competitor to their core products in the internet servers, embedded market, and in mobile. But lets not pretend Microsoft is a friend.

[Quackdoc]

This part is key. All of Microsoft's FOSS contributions. All of it. 100%. Is for the express purpose of driving customers towards Microsoft products and services. They like to play the warm n fuzzy FOSS community card, but make no mistake, they are doing nothing, zero, in the name of fostering Linux community. They are leveraging Linux to drive Microsoft ecosystem growth. For example, more than half of all Azure instances are Linux. I don't blame them, after all, Linux is a direct competitor to their core products in the internet servers, embedded market, and in mobile. But lets not pretend Microsoft is a friend.

I think both reasons heavily factor into it. It's easy to say microsoft bad, but in the end microsoft is still made of people. the technical benefits of doing it their way are undeniable (when done right anyways). the geeks working at microsoft probably pitched it to the assholes, then the assholes took it from there, and made it into a useable product.

[WorBlux]

It sounds like Christoph Hellwig is saying that MS has to make DirectX operate under native Linux or it's a non-starter for mainline inclusion. And that seems reasonable to me. I'd prefer an all-Vulkan world but it's not going to happen overnight, so if MS wants to make DirectX work under native Linux that's fine.

If it worked for GL or Vk too, but DX just worked better, that might even be cool. (At that point intel, amd, and others in the DRM subsystem could update their windows drivers and this module to tune performance.) The problem is more political than technical, why would mainline support and maintain a module that only benefits Microsoft?

[muncrief]

If it worked for GL or Vk too, but DX just worked better, that might even be cool. (At that point intel, amd, and others in the DRM subsystem could update their windows drivers and this module to tune performance.) The problem is more political than technical, why would mainline support and maintain a module that only benefits Microsoft?

Well, I assumed the result would be the ability to run DirectX directly under Linux, which would mean a lot less emulation would be required for games, etc.

However I don't know anything about the Linux graphics stack or other relevant technical details, so if it would only benefit MS when using hypervisors then I see no reason for burdening mainline developers with it, and MS should maintain it themselves.

[Quackdoc]

However I don't know anything about the Linux graphics stack or other relevant technical details, so if it would only benefit MS when using hypervisors then I see no reason for burdening mainline developers with it, and MS should maintain it themselves.

it would benefit everyone running on MS systems. Hyper-v and WSL2. Linux developers have zero issues with Linux being run within the confines of microsoft, people who use linux in a VM, are still linux users afterall. doesn't matter if it's qemu or hyper-v or WSL2

[WorBlux]

Well, I assumed the result would be the ability to run DirectX directly under Linux, which would mean a lot less emulation would be required for games, etc.

However I don't know anything about the Linux graphics stack or other relevant technical details, so if it would only benefit MS when using hypervisors then I see no reason for burdening mainline developers with it, and MS should maintain it themselves.

If Microsoft directly supported and licensed Dxvk that would likely be a satisfactory compromise, application built to directly leverage the paravirtualization would have something to fall back on that was still supported.

it would benefit everyone running on MS systems. Hyper-v and WSL2. Linux developers have zero issues with Linux being run within the confines of Microsoft, people who use linux in a VM, are still linux users afterall. doesn't matter if it's qemu or hyper-v or WSL2

And what do you do when Microsoft pushes and update that changes WDDM and existing acceleration users are forced into azure or a long-term-support contract to keep thier application working? Nobody with a lick of sense and familiarity with Microsoft history and operations is going to build against dxgkrnl / libdx12 directly without some alternate/backup.

The other hyper-v para-virtualization were accepted into mainline, from the application level you just see better performance on the same API. They don't rely on some Microsoft proprietary API.

[Quackdoc]

And what do you do when Microsoft pushes and update that changes WDDM and existing acceleration users are forced into azure or a long-term-support contract to keep thier application working? Nobody with a lick of sense and familiarity with Microsoft history and operations is going to build against dxgkrnl / libdx12 directly without some alternate/backup.

The other hyper-v para-virtualization were accepted into mainline, from the application level you just see better performance on the same API. They don't rely on some Microsoft proprietary API.

I don't see what this has to do with the kernel. as long as the kernel bits get updated, and there is an open source userspace use for it. it doesn't matter for the kernel developers.

also with this primairly being used in WSL2, hyper-v and should these get mainlined WSA, I doubt what you say here will happen. it would be more profitable for it to not happen. not impossible sure. but I don't really see that being an issue.

[muncrief]

it would benefit everyone running on MS systems. Hyper-v and WSL2. Linux developers have zero issues with Linux being run within the confines of microsoft, people who use linux in a VM, are still linux users afterall. doesn't matter if it's qemu or hyper-v or WSL2

I'd prefer that large closed source companies like MS, who have a vested interest in Linux, maintain their own code. However Linux mainline already contains a lot of vendor specific code, like that for VMWare, so if the developers accept it so be it.

I understand and support the reasons for developing and maintaining smaller projects like drivers though, as most hardware companies only distribute MS and Apple drivers. But companies that depend upon Linux should invest in it. And, amazingly, MS is now part of that club. And it seems what they're asking for is a significant change and commitment.

But hey, what the heck do I know?

I'm just an old retired embedded systems designer, and the last CPU I designed that was actually produced was a pitiful single core 8 bit. Though I did create a much more advanced CISC processor later in VHDL with a programmable word size, that executed every instruction in one clock cycle.

In any case I must admit I have an inherent mistrust of companies like MS and Intel for all the horrible things they've done. But like I said, if the Linux developers accept it I'll know I'm wrong.

Although it will be the first time ever! I swear!

[Quackdoc]

I'd prefer that large closed source companies like MS, who have a vested interest in Linux, maintain their own code. However Linux mainline already contains a lot of vendor specific code, like that for VMWare, so if the developers accept it so be it.

I understand and support the reasons for developing and maintaining smaller projects like drivers though, as most hardware companies only distribute MS and Apple drivers. But companies that depend upon Linux should invest in it. And, amazingly, MS is now part of that club. And it seems what they're asking for is a significant change and commitment.

But hey, what the heck do I know?

I'm just an old retired embedded systems designer, and the last CPU I designed that was actually produced was a pitiful single core 8 bit. Though I did create a much more advanced CISC processor later in VHDL with a programmable word size, that executed every instruction in one clock cycle.

In any case I must admit I have an inherent mistrust of companies like MS and Intel for all the horrible things they've done. But like I said, if the Linux developers accept it I'll know I'm wrong.

Although it will be the first time ever! I swear!

well, the primairy issue right now is that it doesn't seem like the MS devs know how to submit a patch. Ill reserve comment on how much of a change the patch series is. have you seen the criticism of the patches? it's pretty bad. before debating on the merits of including it, there appear to be quite a few... both technical design issues. and just overall bad patch issues. (v3 and they don't even have the right copyright year) now, Im a pretty shit developer. good for only basic hacks. so on that merit, maybe I shouldn't comment. but I feel like MS should at least have the basics of the patch down before submitting it for review.