zlacker

Building the DirectX shader compiler better than Microsoft?

submitted by emidoo+(OP) on 2024-02-10 09:22:33 | 327 points 108 comments
[view article] [source] [go to bottom]

NOTE: showing posts with links only show all posts
1. mcraih+c7[view] [source] 2024-02-10 11:02:34
>>emidoo+(OP)
This is also related to Godot "The reason to make it optional is that Direct3D 12 support currently relies on the proprietary dxil.dll library from the DirectX Shader Compiler being shipped together with Godot, and shipping proprietary software goes against the mission of the Godot project." https://godotengine.org/article/dev-snapshot-godot-4-3-dev-3...
7. msk-ly+Md[view] [source] 2024-02-10 12:24:02
>>emidoo+(OP)
So the signing[1] DXIL.dll does is just a modified MD5?

1: https://github.com/hexops/DirectXShaderCompiler/blob/4190bb0...

◧◩◪
11. nptelj+bh[view] [source] [discussion] 2024-02-10 12:59:19
>>lukan+eg
>Assuming they have even something to switch for.

This one hits the nail on the head, and the reason why not just Microsoft, but a lot of large software players are not incentivized to create better software.

At the end of the day, people like power, to make money, and the people at Microsoft are no exception. And businesses are businesses, enterprises to make money, not altruistic benefactors of humanity, or optimizers of a specific domain, like software. So what business will do are their original thing AND business tactics, and the larger the business, the more tactics they have to employ, otherwise they won't be as large, or even simply won't be, at all. So, on the top, it's all ruthless business tactics. As Microsoft is a large player for a long time, they have quite the rep sheet[0], but they are not unique in doing this. It's the name of the game.

[0] https://en.wikipedia.org/wiki/Criticism_of_Microsoft

◧◩◪◨
16. timlat+pk[view] [source] [discussion] 2024-02-10 13:41:56
>>pjmlp+kh
Apologies if I'm misreading your intention, but are you suggesting that Valve's work on Wine is somehow worse than asking game developers to target Linux/other OSes natively? As a Linux desktop enthusiast, I much prefer the Valve's approach: the library of existing Windows-only games that are unlikely to be ever ported is too vast, and the benefits of targeting a disjointed[1] platform with <2% market share[2] for new games are not at all clear. It's only thanks to Valve that I (and hopefully many other Linux users) do not need to maintain a second Windows system for fun, as the majority of games run perfectly fine on Linux and require nothing more than clicking Install then Play in the Steam client.

[1] Case in point: glibc's compatibility guarantees are weaker than what you get on Windows. (For instance, your system's glibc cannot be older than what a game is built against, which may present problems for devs using Fedora/Arch and players on Debian/LTS Ubuntu, something I've experienced first-hand for my apps.) The X11 to Wayland migration is also still underway. (Though things are getting better, the attitudes of some Wayland maintainers are a bit concerning: "I don't [care] what you think is normal behavior for games. You get certain guarantees with wayland. Deal with it. If clients decide to do exactly what they do on windows or X11 they won't work correctly." [3] I'm not sure game developers would enjoy such reception.)

[2] https://store.steampowered.com/hwsurvey

[3] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/18...

◧◩◪
18. NekkoD+6l[view] [source] [discussion] 2024-02-10 13:50:02
>>noahwh+Qh
Well... they are rewriting & upstreaming DXC to LLVM main (https://github.com/microsoft/DirectXShaderCompiler/wiki/Cont...) and want to kinda deprecate DXC. IIRC currently only compute shaders are supported but I may be very wrong.
◧◩
49. rofrol+j21[view] [source] [discussion] 2024-02-10 18:21:46
>>unnoui+lP
> So the signing[1] DXIL.dll does is just a modified MD5?

[1] https://github.com/hexops/DirectXShaderCompiler/blob/4190bb0...

>>39325654

◧◩◪◨
51. EMIREL+391[view] [source] [discussion] 2024-02-10 19:05:31
>>msk-ly+Hq
From the commit message[1]:

"dxil.dll is closed-source, so we cannot simply patch it in the same way. To fix this, we outright disable runtime loading of dxil.dll and silence warnings related to it not being present / the final binary not being code signed. Instead, once the compiler would emit a compiled shader blob, we perform our own code signing algorithm (Mach Siegbert Vogt DXCSA) which results in a bitwise identical compiled shader, and thus dxil.dll is no longer needed to perform code signing of shaders."

[1] https://github.com/hexops/DirectXShaderCompiler/commit/7a013...

52. chrsig+jb1[view] [source] 2024-02-10 19:20:57
>>emidoo+(OP)
> DXC’s fork of LLVM removed and/or damaged much of the code generation layer and infrastructure [of LLVM]. Given that, supporting DXBC generation in DXC would be a massive task to fix and restore broken LLVM functionality. Due to the large scale of this issue and resource constraints on our team we’re not going to address this issue in [the new] DXC [compiler] ever. > > We may support DXBC generation in Clang in the future (we mentioned that in the original proposal to LLVM). That work is unlikely to begin for a few years as our focus will be on supporting DXIL and SPIR-V generation first.

I appreciate this quote[0] from the microsoft camp. Setting clear expectations that something will not be done is a nice bit of fresh air.

[0] https://github.com/microsoft/DirectXShaderCompiler/issues/57...

◧◩
55. charci+7e1[view] [source] [discussion] 2024-02-10 19:42:24
>>msk-ly+Md
Renderdoc, who has had code to do this since 2021 has a good comment that explains it.

https://github.com/baldurk/renderdoc/blob/4a620bb5a16b4de4e2...

◧◩◪
58. amluto+mf1[view] [source] [discussion] 2024-02-10 19:52:22
>>charci+7e1
Not quite:

https://github.com/baldurk/renderdoc/blob/81b4d3d804c1974b0b...

◧◩◪
60. yazzku+kw1[view] [source] [discussion] 2024-02-10 22:03:15
>>malkia+fJ
No, it's C++, based on LLVM. https://github.com/microsoft/DirectXShaderCompiler

Edit: apparently dxil.dll is not part of DXC (the classic move to make "open source" software dependent on external proprietary garbage, apparently.) But I'd still doubt it's a managed DLL.

◧◩
61. yazzku+zw1[view] [source] [discussion] 2024-02-10 22:05:33
>>mcraih+c7
Which part of dxil/dxc is proprietary exactly? Trying to make sense of the license barf at https://github.com/microsoft/DirectXShaderCompiler
◧◩◪
63. yazzku+yy1[view] [source] [discussion] 2024-02-10 22:26:21
>>cholli+9q
It is not absurd at all. Just look and how every PC ships with Windows (and lately doesn't even allow you to boot an alternative OS unless you fiddle with Secure Boot in the BIOS). There is consequently little incentive to make Windows better, and we all know what a complete piece of utter garbage it is. Their next milestone is shoving ads in Outlook and your start menu.

And then the same can be said about a lot of Microsoft products. DirectX is no different; it's the canonical Microsoft piece of shit, and that goes all the way back to the OpenGL days [1].

[1] https://www.gamedeveloper.com/programming/why-you-should-use...

◧◩◪◨
80. nextac+FS1[view] [source] [discussion] 2024-02-11 02:01:36
>>zerocr+gz1
On the latest release https://github.com/microsoft/DirectXShaderCompiler/releases/...

There are "source code" files in zip and tar.gz

Aren't those source code for those dlls?

◧◩◪◨⬒
82. Cloude+V42[view] [source] [discussion] 2024-02-11 05:09:08
>>timlat+pk
That mesa issue reminded me of wayland issue thats been open for 3 years now where apps crash if theres even a slight stall due to the wayland socket becoming full. Instead of providing quick fix for actual app devs and users who are affected most, they have been designing this perfect solution for apps and compositor to agree on the socket size for 3 years now. Its similar crap with the server size decorations where they finally had to admit people want them and merged the protocol but don't implement it in gnome compositor :) I'd say wayland really was barebones when it was being pushed and major contributions to actually get it usable on desktop was from outsiders.

I'd say win32/flatpak/libretro are the only sane way for games to target linux right now. The fact that linux doesn't have real "runtime" and major components required by games link against libc is what makes linux really unstable for anything that needs to open window, draw stuff using GPU and play audio. It's possible to create static binaries for linux that work for eternity, thanks to kernel being actually stable. But link against something in /usr/lib and it all goes to hell. If the GPU drivers and libs that provided basic window / audio did not depend on libc and were standalone, the situation would be much better. Here's good video about this problem space btw https://www.youtube.com/watch?v=pq1XqP4-qOo

◧◩◪◨⬒
95. kvark+dl3[view] [source] [discussion] 2024-02-11 19:14:37
>>jshear+Ts
And wgpu has been doing this for years. Things like descriptor indexing are not exposed to the web but used by Rust (mostly) engines on native.

https://wgpu.rs/

[go to top]