If the Mach team can pull off this whole "Zig as a cross-3D-API shader compiler" and make it work as smoothly as "Zig as a cross-compilation toolchain", then this would be pretty much the biggest thing in computer graphics since 1995 or so :)

And a major boost for Zig -- both as a language and a toolchain.

Why not? Doesn't that just mean that nobody has implemented it yet?

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

Aren't those source code for those dlls?

There's actually a carveout in config.guess's license that lets you redistribute it under whatever license you want but only if you're actually using an autoconf-based build. The LLVM version this is based off of only uses config.guess and not anything else from autoconf, so that carveout doesn't apply. Instead LLVM just relied on the fact that config.guess is only getting called via the command line, so the GPL's "virality" doesn't apply; LLVM (and now Microsoft) just distributed config.guess separately licensed as GPL alongside their code.

That's a completely different program. GPL doesn't jump across programs.

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.

Yes. Yes I want my GPU, wifi and bluetooth to work. Get over yourselves and leave that checkbox checked by default.

Many video games already do this with all the proprietary middleware they use (Bink, SpeedTree, PhysX, etc). Most launchers (Steam, GOG, Epic, etc) also require their respective .DLLs. Many games also use D3D11On12. Many shipping games in my list have dxil.dll amongst their installed files.

Therefore, an honest question: what's the problem with shipping an additional DLL? The work done here to reverse-engineer and re-implement the code-signing is fantastic—especially the fact that it is bitwise equal to dxil.dll's output. But I am ridiculously lazy and prefer to take the easier way out, and would've just shipped the DLL.

In addition, even for AAA games (but also for other games and software, this adds extra dependencies that may be broken outside your control. At a company i worked several years ago, we spent more effort upgrading Visual Studio because for some middle we only had DLLs (and their libraries) to link against and had to obtain new versions (part of the effort was that the company that wrote said middleware hadn't upgraded their own so we also became QA for their compatibility with the newer VS, though i don't remember if there were any issues in practice).

Of course having the code doesn't mean updates will be frictionless, but there will certainly be way less friction and you wont need to wait for someone else.

(btw i think Visual Studio has tried to be backwards compatible in recent versions with binary C++ libraries, but i don't think this is something you can rely on in the long term)

Also all that are with the assumption that the requirement is that your code remain on the same platform and targets. But at some point you may want to work with another platform (be it as host or target) and not having source code can make that from incredibly difficult to impossible. This may not seem much of an issue for something as platform-specific as DXIL - but actually notice the article mentioning that the binary blobbiness of DXIL made it impossible to precompile shaders on platforms outside specific Windows and Linux architectures for which the DLL was provided by Microsoft.

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

Anyone paying attention in the article to that point knew it had to be some basic hash or similar, where even in your worst case someone has to reverse engineer some assembly.

After all that effort, just out Microsoft, particularly when we're talking about opensource code that anyone that cares to can just dig through and find (thanks for that, msk!).

I think it's for plausible deniability in case M$ ever comes after them for RE reasons. They probably want to be able to say that they didn't use the proprietary blob in order to implement their own code signing.

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

It sort of works if your signing tool is part of a private console SDK, but the DirectX SDK was always freely available.

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

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

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

From my experience, it's been disappointing. Big, complex to setup, not convinced about many tradeoffs.

https://wgpu.rs/

In vkd3d (from wine), I think you have a DXIL->SPIR-V translater (much more robust than any high level shading language converter since it is a much more simple intermediate language).

That said, apart from this abomination of llvm, is there a HLSL->DXIL compiler written in plain and simple C99 (namely which require NOT gcc or clang to compile)?

That said, vkd3d(wine) is plain and simple C, and I suspect that mesa tool to be part of microsoft "push" in mesa, dirtying it with c++.

Also to answer your question, no. The hlsl to dxil translation is basically owned by microsoft. There's been little effort to move away from that

I am perfectly aware this will require a bit more upfront work to write shaders, but due to their life cycle, it should be benign and we should get all the benefits (not even mentioning to free the SDK dependency from a massive and complex high level shading language compiler).

I am going to give it a try. I need first a SPIR-V assembler, the one from the khronos spriv tools and the one from llvm are c++ diarrhea then a definitive nono, have to write my own. Let's think long run here: we don't have a _REAL_ standard very high level language yet (python? lua? javascript? perl5? ruby? so_many_others?), I'll go rv64 assembly then (I'll write a mini rv64 interpreter for x86_64).

That above is the real magic. Since he won't comment on the how, I guess he took a swing at poping the hood underneath, and did exactly what Wine developers did 2 decades ago. Any old timers here remembering that scandal? Smart kid to not comment on the how, this way Microsoft won't have any legal leg and since times have changed with all that "Microsoft loves Linux" shit they yell at all corners (not that I believe that for a single second), then it will be swept all under the rug and FOSS wins. For now.

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

https://news.ycombinator.com/item?id=39325654

The way signing is done is already public knowledge that can be found using google as other open source projects have implemented it.

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

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

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

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

Porting games from Android/NDK into GNU/Linux is relatively a child's play.

Playstation OS is also POSIX friendly.

Finally every serious middleware engine supports GNU/Linux.

Still the amount of studios that care about GNU/Linux is almost zero.

With Valve, there are no reasons to bother at all as a studio, target Windows/DirectX, let Valve do the work, collect the money with zero additional effort.

Now with Windows based handhelds, Valve will learn what happened to netbooks.

What do I need to make a video game? Input, sound, graphics. What use is a shell, a userland, or even a C library (if I'm not writing in C) for making a video game?

Android is _not_ GNU/Linux. It doesn't need to provide a shell or userland as part of the platform, and its C library is bionic not glibc. It also provides a lot of things GNU doesn't*, like input, sound, and graphics. It's also not designed to run on a desktop, and the differences between mobile and desktop are non-trivial and slowly growing.

Windows and macOS are full graphical operating systems. Linux is just a kernel. GNU/Linux is just a command-line operating system. Great for servers, terrible for video games.

Moreover, commercial video games are distributed in binary format, not source. Even if input, sound, and graphics were solved on Linux in a consistent way, the developers** can't help but break ABI compatibility every couple of years. Many apps from Windows 3.1 days can still run on Windows 11. What binary from Linux's early days can still run today, never mind with graphics or sound?

* = You could include GLib/GTK+/GNOME but then you're targeting a specific desktop environment and not simply "Linux" or even "GNU/Linux" anymore

** = Except for the kernel developers, upon whom Linus forces "never break userspace" as a hard rule

I believe pjmlp's point (although it requires a fair bit of reading between the lines) is that Windows already has fantastic backwards compatibility (as you elaborated on), and Valve's work has created a situation such that all developers need to do is target and build for only Windows, release Windows-only binaries; then, Valve/WINE will do the hard work in ensuring they run seamlessly on Linux. This means developers don't need to care about building natively for Linux (à la Factorio and a tiny handful of other games). In other words as another commenter said, the real stable ABI on Linux is Win32 + WINE.

Furthermore, Valve's work also negates the work of open-source engine and game developers who have ported their engines and games to native Linux. This is because developing for Windows is a known quantity, and there is an overwhelming volume of resources, effort, and experience in writing games for Windows.

pjmlp concludes with 'Now with Windows based handhelds, Valve will learn what happened to netbooks', which I gather to mean that the Steam Deck will lose popularity to Asus and MSI's (and soon, other manufacturers too) handheld systems, since running most games directly on Windows is still easier than the occasional faff that someone has to do when running games on WINE/Proton.

Honestly, somebody could have done something like this for "native" Linux but the incentives never really fell into place. It could even have been Valve, but I would guess they weighed the options and found this to be the one that gave them the widest compatibility without expecting too much of the game developers, many of whom were reluctant to make their games available on Steam at all.

It's a riff on only stable OS API on Linux is Win32.

The comparison with OS/2 only applies at a very surface level - and isn't even the whole reason why OS/2 failed when it had to compete with Windows. Among other things:

1. OS/2 could only run 16bit Windows applications at a time when Windows was switching to 32bit. Even the 16bit Windows applications were not 100% compatible and that is despite using Microsoft's code.

2. OS/2 had much worse hardware support than Windows as everyone was targeting Windows. On the other hand IBM as a whole never put much effort towards OS/2.

3. OS/2 Windows support had applications either run inside an isolated environment or they looked "alien" next to OS/2 applications at a time when GUIs were still trying to look consistent. While this is also the case with Wine/Proton, the focus on games makes this point moot (and people do not seem to care as much about GUI consistency these days).

> Now with Windows based handhelds, Valve will learn what happened to netbooks.

So far every single Windows handheld review i've seen that compares it to Steam Deck mentions both how the UX is worse than Steam Deck and games are -ironically- more likely to have issues on the Windows-based one. The only two saving graces for Windows handhelds is that they tend to be faster (but only when running at full throttle which limits their battery lifetime - Steam Deck runs faster at lower watts for better battery lifetime) and that anticheat rootkits work on the Windows handhelds whereas they do not work on Steam.

And you also forget that Valve did try to get game developers target Linux and put a lot of effort in the ecosystem for literally years before making Proton, yet developers largely ignored that.

Microsoft is already half way there with WSL, as soon as they realised folks rather buy Apple gear for UNIX experience, instead of supporting Linux OEMs.

"Runs Windows better than Windows" didn't work last time, and won't now.

And if XBox really goes full speed ahead as cross platform brand, as the console rumor mill has been discussing, lets see how many Microsoft owned studios stuff keep landing on Steam.

Windows is going to end up as the 2030s version of dosbox

edit: as in Windows ends up with the same fate as MS-DOS: replaced with a piece of software analogous to dosbox

Imagine games that dynamically link some library (or glibc). They wouldn’t run on other Linux distributions with mismatching dependencies (or a different libc).

Sure, 100% statically linked binaries might work. But wine also runs on non-Linux.

Windows is a sufficiently homogeneous target, and wine works well enough. Heck, some games run better in Linux+Wine than they do in windows.

'Most' just want their browser to behave like always anyway.

Microsoft uses this software to make their own video games. They have a very vested interest in making any software they use better.

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

Are you saying this as a qualitative statement, or as an emotional and irrational outpouring of hate?

By qualitative, I mean things like performance, compatibility, UI/UX, programmability, software design, etc.

Somehow I doubt it's the former...