Microsoft Has Another Go At Their DirectX Linux Kernel Driver

[chithanh]

Also as I intimated, I just have a bad feeling about Microsoft and Intel. Every time I've thought they were changing for the better they've remained the same, or become worse than before.

when Intel publishes something foss, I have a feeling that it will be beneficial (if they don't just wind up drop working on it with meaningful capacity like they seemingly did with GVT-G). even if they do scummy shit, it feels... separate to to speak

Microsoft is worse, but I think the MKL situation showed that the old corporate Intel still very much exists and is in control.

And it is not limited completely to the non-FOSS parts. I remember how i915 maintainers refused integration of reverse engineered Poulsbo code, and insisted on the separate gma500 driver despite extensive amount of code duplication between the drivers.

[Quackdoc]

Since I'm not at all familiar with the low level Linux graphics architecture the major issue I gleaned was that the patch didn't fit into the current API, and therefore couldn't be utilized by current native programs. As a hardware/firmware/software designer I'm familiar with arguments of strategy and style though, and observed them in this thread as well, but like I said I don't know enough about the architecture to evaluate them.

Also as I intimated, I just have a bad feeling about Microsoft and Intel. Every time I've thought they were changing for the better they've remained the same, or become worse than before.

I don't feel so bad about intel, I feel like a lot of foss projects with Intel, they just throw their money to divisions and says "make us look good" and lets the tech guys go free willy to an extent. or goes to a team and says, "hey we need this, go do it" and then again gives them some anonymity as to how to go about it. when Intel publishes something foss, I have a feeling that it will be beneficial (if they don't just wind up drop working on it with meaningful capacity like they seemingly did with GVT-G). even if they do scummy shit, it feels... separate to to speak

MS on the other hand does feels like they make their projects intentionally to fuck with people. open source or not. it always winds up feeling malicious.

[muncrief]

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.

Since I'm not at all familiar with the low level Linux graphics architecture the major issue I gleaned was that the patch didn't fit into the current API, and therefore couldn't be utilized by current native programs. As a hardware/firmware/software designer I'm familiar with arguments of strategy and style though, and observed them in this thread as well, but like I said I don't know enough about the architecture to evaluate them.

Also as I intimated, I just have a bad feeling about Microsoft and Intel. Every time I've thought they were changing for the better they've remained the same, or become worse than before.

[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.

[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]

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.

[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]

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

[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.

[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?