Wow! Microsoft DirectX Adopting SPIR-V Moving Forward

[Daktyl198]

On the contrary, it is very widely used.

Almost all mobile devices, most embedded devices (Embedded Linux and QNX), WebGL, and so on.

The only real contenders for the next generations are Vulkan (for devices) and WebGPU for browsers.

Correct, it is used in Android mobile devices... and that's pretty much it. iOS deprecated it in version 12 (AKA 6 years ago). That is still a lot of devices, technically, but not really what I was talking about. Historically on desktop, OpenGL was utilized on Linux and macOS only. Almost every single application written for Windows used Direct3D. These days, Apple has moved on to Metal (after being so fed up with Khronos and the OpenGL situation) and Linux (desktop and embedded) has mostly moved on to Vulkan, with a few exceptions. On browser, it's also technically used but WebGL is extremely rare to run across in the wild, so it's usage might as well not be counted.

The unfortunate thing is that Vulkan is going the same route as OpenGL. As more and more versions/extensions get released, fewer and fewer applications running on Windows are using Vulkan, opting instead for the better experience and stability of Direct3D. It's mainly cross-platform apps meant to run on both Windows and macOS that use Vulkan, and MoltenVK is doing a hell of a lot of work in keeping Vulkan as "the cross-platform API". I'd be willing to put money on the fact that if anybody developed a similar Direct3D to Metal layer, Vulkan usage on both Windows and macOS would plummet and Linux would be left all alone.

What's annoying is that there have been projects showing that not only is it possible and fairly easy to implement Direct3D into the Linux graphics stack, there are performance and stability benefits for doing so. But because people hate Microsoft so much, we all rely on a good but never perfect translation layer. We'll forever have overhead converting to an API that barely anybody else uses.

[Artim]

On the other hand, I could also see them getting fined for anti-competitive behaviour if they don't sign the driver.

I don't. It could be seen as anti-competitive if they write their own driver and force everyone to use it. But from what I can tell from the discussions around Crowstrike - and the lies MS spread during that - they have previously only been forced to allow competitors the same access to the system - or more precisely give access to the documentation and testing tools they - they use internally. So if MS would ban all Kernel-level drivers and instead provide new APIs to get the same level of functionality without having to gain the same dangerous level of access, it would work. So MS just needs to do what Apple already did with macOS during their change to ARM. And since MS is already implementing eBPF - which the Linux version of Crowdstrike also can use instead of Kernel modules - my guess is that's what their new APIs will be based on. I don't know enough about eBPF, but I'd guess if the same happens inside an eBPF program that cause Crowdstrike to bootloop Windows, it might not cause the same issues, but just fail with an error message.

[Artim]

What's annoying is that there have been projects showing that not only is it possible and fairly easy to implement Direct3D into the Linux graphics stack, there are performance and stability benefits for doing so. But because people hate Microsoft so much, we all rely on a good but never perfect translation layer. We'll forever have overhead converting to an API that barely anybody else uses.

Sure, because the proprietary license of Direct3D has nothing to do with it and implementing and maintaining D3D in Linux would be so much of a breeze, that even Valve doesn't bother to go that route...

[Steffo]

My assumption is, that the long-term goal of MS is to migrate to Linux, because Windows is a maintenance burden and their cash cow nowadays is Office, Cloud and services in general.

[MillionToOne]

There is a law thing happening so we have something yes..

https://edgebit.io/regulations/

There is a new consideration for Microsoft. Microsoft signs a driver it get used in system exploiting then USA government, Australian Government and the EU government so far comes along with a please explain and hits Microsoft for fines for not maintaining software supply chain. So the money Microsoft gets to sign a driver could be vastly less than the amount Microsoft could get fined.

There's something called Windows Hardware Quality Labs testing, where for example graphics drivers are signed etc. The same could be used for verifying kernel level drivers. Up until 2014 WHQL tesing costed money.

[oiaohm]

On the other hand, I could also see them getting fined for anti-competitive behaviour if they don't sign the driver.

This is why Microsoft is doing

https://blogs.windows.com/windowsexperience/2024/09/12/taking-steps-that-drive-resiliency-and-security-for-windows-customers/

these conferences with other vendors. Do notice something anti-cheat vendors were not invited.

There is question with anti-competitive you need to answer that Microsoft has not need to answer while they were not on the hook for supply chain. Lets say vendor wants to a fake product as in what people would call snake oil and you government or company forbid it sale is this anti-competitive? That answer is no it not anti-competitive.

The supply chain change means Microsoft on signing driver need to answer the question if blocking this driver is anti-competitive or not. Not allowing the driver will not do what it promises in sales to customers(that include game companies) is not anti-competitive and will be required by supply chain security.

Yes lot of games have kernel mode anti-cheat software with no evidence that they are in fact truly preventing cheats from playing the game.

Basically the Software Supply Chain Security laws really do change the game. Its not longer lets just allow everything so we cannot be hit with anti-competitive law suites. There is now a duty of care to make sure that what you are signing at least fit for purpose so is a truly competitive production. As I said some parties will find they will no longer be able to get signed drivers from Microsoft and instead get told to use the user space provided interfaces.

We will have to wait to see how this exactly shakes out. What is for sure is not as many parties will be able to make kernel mode drivers for windows because many will not be able to prove that what they want to do is a real product and is not fake/snake old product.

Anti-competitive behavior is why I suspect Microsoft may not be able to block all third party kernel mode drivers for security but there will be high quality standards for these parties still allowed to make windows kernel drivers.

The rules have changed a lot.

[oiaohm]

There's something called Windows Hardware Quality Labs testing, where for example graphics drivers are signed etc. The same could be used for verifying kernel level drivers. Up until 2014 WHQL tesing costed money.

There is issue here. For a driver microsoft can take there generic test suite for X driver and apply it and check if the hardware driver in fact behaves correctly.

Lot of the individual security and anti-cheat vendor drivers do not have a test suite Microsoft can have or openly documented interfaces so Microsoft can write test suite.

This is why Microsoft is needing now to have sit down conferences with the anti-malware vendors and the like.

The Windows Hardware Certification program (formerly Windows Hardware Quality Labs Testing, WHQL Testing, or Windows Logo Testing) is Microsoft's testing process which involves running a series of tests on third-party device drivers, and then submitting the log files from these tests to Microsoft for review.

https://en.wikipedia.org/wiki/WHQL_Testing

The key part WHQL is having a test suite that cover drivers functionality.

WHQL has been great at reducing the number of hardware device drivers that cause the OS to malfunction. WHQL has not be effective on the non hardware device drivers because the test suits that WHQL has really does not cover those drivers correctly.

Yes particular parties have been unable to make their hardware device drivers for versions of Windows that require WHQL for signing because their drivers fail to pass the test suite. We have already had hardware vendors weed out here. Yes this saw GPUs stop doing as many vendor unique driver alterations because doing a minor driver alteration could cause them being stuck in a loop of send to to Microsoft be rejected because their code had some bug..

You are on the right track point to the WHQL. That going forward we can expect at some point everything that is a kernel mode driver to have a test suite that Microsoft can run against it to make sure its functional as it promising to customers. I can see parties who want to keep there interface from kernel space to user-space a trade secret have a major issue with this.

Things will change basically. As WHQL test suite expand to better cover non hardware drivers particular driver vendors will not survive the change and users will truly be better of for system stability without them. And some driver vendors will do the same as GPU vendors did of ok lets just use the single upstream and call it good so reducing down having to deal with Microsoft over and over again.

[Artim]

My assumption is, that the long-term goal of MS is to migrate to Linux, because Windows is a maintenance burden and their cash cow nowadays is Office, Cloud and services in general.

One can only hope that this piece of garbage finally dies...

[Artim]

There's something called Windows Hardware Quality Labs testing, where for example graphics drivers are signed etc. The same could be used for verifying kernel level drivers. Up until 2014 WHQL tesing costed money.

I think the Crowdstrike incident showed well enough how well that works. The driver was signed and supposedly tested, yet a file consisting only of zeros was enough to crash it. That begs the question of how something that simple has not been tested.

[Quackdoc]

I think this is more to keep d3d a bit longer relevant. Outside of windows (android/ios/osx/game console/...) it's irrelevant, developers may come to see d3d as a burden with its (suddenly odd/nonstandard) shader binary format.
Also, for example the Qualcomm X1E windows opengl driver is basically a fork of mesa; maybe this is also to ease integration of the mesa drivers into windows-arm?

what? D3D is literally the major API of the xbox consoles... Now I may be mistaken, but last time I checked Xbox was one of the most popular consoles... I would hardly say it's irrelevant inside the console space.