Wow! Microsoft DirectX Adopting SPIR-V Moving Forward

[HEL88]

Lets just say countries are kind of getting sick of their core operations being effected by OS allowing something at kernel level that has no real reason to be there. .

M$ already wanted to throw such drivers out of the kernel 15 years ago. It created a corresponding api. But it was the EU that didn't agree to it. The anti-malware producers protested, and the EU supported them. That's why divers with dynamically loaded code and data are still sitting in the kernel.

And not only in the WIndows kernel, but Linux too.

[_ONH_]

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.

I think the same Windows 14 will be a Linux distribution with MS GUI.

[Artim]

M$ already wanted to throw such drivers out of the kernel 15 years ago. It created a corresponding api. But it was the EU that didn't agree to it. The anti-malware producers protested, and the EU supported them. That's why divers with dynamically loaded code and data are still sitting in the kernel.

And not only in the WIndows kernel, but Linux too.

Wrong. They could have done it 15 years ago if they had actually wanted to. What they were not allowed was to force their competitors to use inferior tech than what they were using, i.e. as long as Microsofts own solutions were using the same API, they could have done so. I know, MS loves to spread that lie, but fact is the documents in which the EU declares the rules they enforce on MS are public, and with not a single word they force MS to allow third parties Kernel level access to anything. E.g. the document in question is linked here: https://www.neowin.net/news/microsof...-down-windows/

And what on earth has that to do with Linux? The EU never made such rules about Linux.

[avis]

It would be extremely naive to think that Microsoft now loves open source more than their own solutions, and the only reason this has been done is to ... actually save Microsoft money.

They couldn't care less about SPIR-V because they continue to push DirectX, which is the only API in Xbox and the only supported 3D API in Windows.

The only reason to celebrate this is that now DXVK and Wine will probably have fewer issues translating D3D to Vulkan.

Wake me up when Microsoft adopts Vulkan as a first-class API in Windows.

[mlau]

Mlau was probably listing it under Windows (as afaik it does run Windows). But yes, at least according to statcounter, XBox has over 60 % marketshare and thus is quite relevant.

Yes, xbox is windows for me. I was thinking along the following path: With Vulkan/OpenGL4.6 (which has a spirv-interop extension) you can basically cover Android and Windows (and Linux, but that target group is more or less irrelevant too). xbox is moving away from dedicated hardware it seems (stadia was ahead of its time), which leaves desktop windows the sole consumer of d3d/dxil; of course I don't know any non-game applications that use D3D, but the majority are games, which can switch to other backends in their game engines if need be. finally, d3d is a ms-only effort (with heavy input from nvidia/amd) while vulkan/gl has broader industry support. sure at the moment d3d seems to reign supreme, but I think that's just inertia, alternatives with broader platform support do exist and will make it irrelevant, it just takes time.

[oiaohm]

M$ already wanted to throw such drivers out of the kernel 15 years ago. It created a corresponding api. But it was the EU that didn't agree to it. The anti-malware producers protested, and the EU supported them. That's why divers with dynamically loaded code and data are still sitting in the kernel.

There is a issue the old EU old ruling did not say that.
https://www.neowin.net/news/microsof...-down-windows/ Yes Microsoft pointed their finger to it and complained at the time.

The ruling says security vendors must be giving API access to-do their job.. Remember what is good for the goose is good for the gander. Microsoft cannot anti-malware vendor drivers because anti-malware drivers API documentation with test suite is not being provided to Microsoft.

Software supply chain rules are new in the EU after the Crowdstrike disaster.

And not only in the WIndows kernel, but Linux too.

Do note the EU has not attempted to force the Linux kernel to provide anti-malware vendors with a stable kernel mode API to write their drivers against.

There is a very interest split between Linux and Windows on anti-malware vendors. Linux kernel has very functional ebpf that is a byte code that audit before being run in kernel space and has a stack rules to prevent it from causing kernel failures. Yes you see parties like ESET they have a driver for windows written in C/C++ but for Linux they use ebpf bytecode that is not as problematic..

The reality Microsoft has not provide with the Windows kernel a platform like ebpf on Linux so that third party security vendors don't have to roll their own.

https://opensource.microsoft.com/blog/2021/05/10/making-ebpf-work-on-windows/

Yes Microsoft added ebpf support to windows in 2021 but it only has the network stack interface from ebpf not the complete OS internal access as Linux kernel ebpf has.

We are at a very interesting time. Something to understand Supply chain rules of duty of care percentages of responsibility. This remove pointing finger to remove liability. Yes Microsoft points to the old EU ruling and attempts to say that why we have problem under the percentages of responsibility that is at max 10% there is still a greater percentage of responsibility left on Microsoft head. Like why only now is Microsoft demanding conferences with anti-malware vendors to discus API requirements they need to-do their job. There is a lot of things Microsoft could have been doing it reduce the risk of a Crowdstrike class issue without breaching the prior EU ruling that they have not done. The fun of supply chain rules when you get audited after a disaster that percentage of responsibility is handed out. Yes not my problem it was someone else problem does not work under this system. Its not your problem if there was no action you could have done to mitigate the defect. This supply chain rules basically a guilty until innocent model not the normal of innocent until proven guilty model. This is why supply chain coming to software is a big thing.

[Espionage724]

Mlau was probably listing it under Windows (as afaik it does run Windows). But yes, at least according to statcounter, XBox has over 60 % marketshare and thus is quite relevant.

Question is what APIs the PlayStation supports. So for games that are meant to run at least on both, Studio may just opt to use an API that they can use on both instead of D3D. But that's the question to be answered. How many of the XBox games actually use D3D and how many opt for other APIs?

Dang, this is starting to sound like people not wanting to put in extra effort for unique stuff (DX) and instead all gathering under one thing as a convenience. That's how systemd and Wayland became stars.

Like, I guess it's cool to be going for an open-source standard, but how long until the main project does something "gross" and causes people to splinter-off into other things/fork?

[STiAT]

MS needs DX12 to always stay one step ahead of Vulkan. Work graphs? DirectML? These things have existed for a fair time, but their Vulkan equivalents are still nowhere to be seen.

MSFT simply made the same mistake Khronos made with SPIR. SPIR was based on LLVM IR 3.4 making it increasingly harder to produce it from newer front-ends, hence came SPIR-V, which was independent of LLVM. DXIL is LLVM IR 3.7 and suffered the same fate.

This news is good not just for Proton and the likes, but purely for Vulkan, OpenCL and SYCL as well, as MSFT will be contributing to the SPIR-V ecosystem, improving it for all APIs that consume it.

As I know there are at least experimental versions for Work graphs. DirectML I agree is still nowhere to be seen.

And yes, if Microsoft wants to continue to dominate that market they need to stay a step ahead. Which is not a bad thing in my opinion. It's competition.

[Daktyl198]

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

If the proprietary license was an issue, then both DXVK and Gallium Nine wouldn't exist. Only code and implementations can be copyrighted, not APIs.

[oiaohm]

It would be extremely naive to think that Microsoft now loves open source more than their own solutions, and the only reason this has been done is to ... actually save Microsoft money.

They couldn't care less about SPIR-V because they continue to push DirectX, which is the only API in Xbox and the only supported 3D API in Windows.

The only reason to celebrate this is that now DXVK and Wine will probably have fewer issues translating D3D to Vulkan.

Wake me up when Microsoft adopts Vulkan as a first-class API in Windows.

No you missed something.

https://www.gamingonlinux.com/2022/12/intel-using-dxvk-part-of-steam-proton-for-their-windows-arc-gpu-dx-9-drivers/

I know this might be kind of surprising but if you go by number of systems in wild Intel is the largest GPU vendor and not by a small margin.

What is the point of Microsoft pushing forwards with DXIL when all the GPU vendors/driver makers are going todo is translate to SPIR-V anyhow. I see this recent change is Microsoft kind of seeing the writing on the wall that GPU vendors are not going to spend time doing specialist things in hardware for Microsoft direct x.