3 ms·

From what I understand you're saying that Apple should provide 2 things: (1) Vulkan drivers and (2) backwards compatibility forever. I don't really know enough

From what I understand you're saying that Apple should provide 2 things: (1) Vulkan drivers and (2) backwards compatibility forever. I don't really know enough about graphics to discuss point (1). From what I understand, Apple GPUs don't really fit the Vulkan model too cleanly, and the Asahi Vulkan drivers are significantly less performant than Metal (how much of that is due to beta/community status vs. architectural bottleneck I have no idea). But let's say they provide (1). Providing (2) would simply be a big mistake. It is a huge mistake of Windows, of the C++ programming language and of the x86 ISA (none of which are very good). Linux distros do not provide this either, beyond the core kernel syscalls and glibc. It is certainly a very big ask and not something trivial.

bigyabai 16d ago
I'm only asking for (1); Apple can keep breaking APIs forever as long as they support the libraries that enable Proton. (2) is precisely the reason why nobody can port games to macOS anymore, and largely why ARM is a second-class citizen in PC gaming too. You cannot depreciate things like AVX or 32-bit library execution modes, and then demand native builds get made to 20-year-old games. Apple Silicon's ISA extensions like AMX are not a replacement for x86's SIMD extensions, it's not standardized through Arm or supported in Asahi either. Native Mac games need to incorporate Apple's proprietary and unstable tech like Metal and the Apple Silicon microarchitecture, which makes their games unstable and difficult to support in the long term. Translation is Apple Silicon's only choice for game preservation and mainstream game support. > Apple GPUs don't really fit the Vulkan model too cleanly This is a misconception that stems from Metal's preference for tile-based deferred rendering pipelines. Vulkan 1.3 is fully viable on the M1 onward, which is enough to support DirectX 12 translation in Proton. The performance of Asahi's drivers are not any worse than the official Vulkan drivers that Arm provides for TBDR-optimized GPUs like the Mali line.
- serbuvlad 16d ago
  Everything you said about (2) is wrong imo. Games should simply not be written for a particular architecture. The rendering part of the game engine should already be abstracted away from the particular rendering API (there are other significant platforms which do not support Vulkan: PS5 and Xbox, which your game should be capable of targeting). And the math library should have fallbacks to standard C (or standard C++ etc.) and then specialized implementations for AVX, NEON, SVE, etc. Nothing else needs to be architecture specific. Now, sure, NEON is slower than AVX-256/512. But backending to NEON or even standard C is certainly going to be faster than running stuff over an x86-to-ARM translation layer. Sooner or later the Steam Deck 2 will release, probably on an ARM platform (if the Steam Frame compatibility layers go well), and millions upon millions upon millions of dollars of electricity will simply be wasted running x86-to-ARM, Win32-to-Linux and Direct3D-to-Vulkan dynamic compatibility layers when, if the games were well written in the first place, they could simply be trivially recompiled. > 32-bit library execution modes If your application assumes pointers are 32-bits, or any particular size, or even any set of particular sizes, it's completely broken. As for (1), if Asahi Vulkan drivers are really good, that just goes to show why Apple isn't supporting Vulkan. Metal applications seem to be faster, and Apple wants to push devs to make their apps for the faster API.
  - bigyabai 15d ago
    You're welcome to disagree with me about (2), I don't care what macOS picks in this regard. It's not going to help games get ported to macOS or Apple Silicon any faster. There are hundreds of thousands of video games that will never be updated again, macOS will never support these games without translation. Your ideal world where programmers support and recompile games 3 decades after release does not exist in reality. This is why efforts like WoW64 and FEX exist in the first place; you will never recompile the majority of Windows games. Ever. (1) is just common sense. Go ask your favorite LLM; does hardware-level TBDR optimization degrade basic Vulkan support? No, it doesn't, and we have dozens of mobile GPUs that support Vulkan to prove it. Metal is not "faster" and it's architecture does not preclude high-performance Vulkan drivers in any way. If you don't believe me, ask anyone else. > millions upon millions upon millions of dollars of electricity will simply be wasted running x86-to-ARM, Win32-to-Linux and Direct3D-to-Vulkan dynamic compatibility layers when x86-to-ARM doesn't have to be slow. Accelerators like Apple's AMX can leverage autovectorization during translation, which is significantly faster than NEON and potentially more efficient than x86 SIMD. D3D-to-Vulkan and Win32-to-Linux is almost always more power-efficient for most GPUs/games. Wine is much thinner than a full-fat Windows runtime, and DXVK can translate DirectX code into batched calls with a shader cache even if the game itself doesn't support it. Do you think the Steam Deck runs games better on Windows, somehow?
    - serbuvlad 14d ago
      Why are you deltaing to windows? You should be deltaing to native. Obviously an IBM 704 program will run faster on an IBM 704 emulator than on a hardware IBM 704. That's not an argument to keep writing apps for the IBM 704 and "just translate them". > Your ideal world where programmers support and recompile games 3 decades after release does not exist in reality. Happens in literally every other programming industry though. The reason this cannot happen in the games industry is that game developers are not good software developers. They are much more akin to physics-numerical-methods people who can write some magic spaghetti-Fortran that runs really fast and does black magic, but no one can maintain, debug or integrate.

bigyabai 16d ago

I'm only asking for (1); Apple can keep breaking APIs forever as long as they support the libraries that enable Proton. (2) is precisely the reason why nobody can port games to macOS anymore, and largely why ARM is a second-class citizen in PC gaming too. You cannot depreciate things like AVX or 32-bit library execution modes, and then demand native builds get made to 20-year-old games. Apple Silicon's ISA extensions like AMX are not a replacement for x86's SIMD extensions, it's not standardized through Arm or supported in Asahi either. Native Mac games need to incorporate Apple's proprietary and unstable tech like Metal and the Apple Silicon microarchitecture, which makes their games unstable and difficult to support in the long term. Translation is Apple Silicon's only choice for game preservation and mainstream game support. > Apple GPUs don't really fit the Vulkan model too cleanly This is a misconception that stems from Metal's preference for tile-based deferred rendering pipelines. Vulkan 1.3 is fully viable on the M1 onward, which is enough to support DirectX 12 translation in Proton. The performance of Asahi's drivers are not any worse than the official Vulkan drivers that Arm provides for TBDR-optimized GPUs like the Mali line.

serbuvlad 16d ago
Everything you said about (2) is wrong imo. Games should simply not be written for a particular architecture. The rendering part of the game engine should already be abstracted away from the particular rendering API (there are other significant platforms which do not support Vulkan: PS5 and Xbox, which your game should be capable of targeting). And the math library should have fallbacks to standard C (or standard C++ etc.) and then specialized implementations for AVX, NEON, SVE, etc. Nothing else needs to be architecture specific. Now, sure, NEON is slower than AVX-256/512. But backending to NEON or even standard C is certainly going to be faster than running stuff over an x86-to-ARM translation layer. Sooner or later the Steam Deck 2 will release, probably on an ARM platform (if the Steam Frame compatibility layers go well), and millions upon millions upon millions of dollars of electricity will simply be wasted running x86-to-ARM, Win32-to-Linux and Direct3D-to-Vulkan dynamic compatibility layers when, if the games were well written in the first place, they could simply be trivially recompiled. > 32-bit library execution modes If your application assumes pointers are 32-bits, or any particular size, or even any set of particular sizes, it's completely broken. As for (1), if Asahi Vulkan drivers are really good, that just goes to show why Apple isn't supporting Vulkan. Metal applications seem to be faster, and Apple wants to push devs to make their apps for the faster API.
- bigyabai 15d ago
  You're welcome to disagree with me about (2), I don't care what macOS picks in this regard. It's not going to help games get ported to macOS or Apple Silicon any faster. There are hundreds of thousands of video games that will never be updated again, macOS will never support these games without translation. Your ideal world where programmers support and recompile games 3 decades after release does not exist in reality. This is why efforts like WoW64 and FEX exist in the first place; you will never recompile the majority of Windows games. Ever. (1) is just common sense. Go ask your favorite LLM; does hardware-level TBDR optimization degrade basic Vulkan support? No, it doesn't, and we have dozens of mobile GPUs that support Vulkan to prove it. Metal is not "faster" and it's architecture does not preclude high-performance Vulkan drivers in any way. If you don't believe me, ask anyone else. > millions upon millions upon millions of dollars of electricity will simply be wasted running x86-to-ARM, Win32-to-Linux and Direct3D-to-Vulkan dynamic compatibility layers when x86-to-ARM doesn't have to be slow. Accelerators like Apple's AMX can leverage autovectorization during translation, which is significantly faster than NEON and potentially more efficient than x86 SIMD. D3D-to-Vulkan and Win32-to-Linux is almost always more power-efficient for most GPUs/games. Wine is much thinner than a full-fat Windows runtime, and DXVK can translate DirectX code into batched calls with a shader cache even if the game itself doesn't support it. Do you think the Steam Deck runs games better on Windows, somehow?
  - serbuvlad 14d ago
    Why are you deltaing to windows? You should be deltaing to native. Obviously an IBM 704 program will run faster on an IBM 704 emulator than on a hardware IBM 704. That's not an argument to keep writing apps for the IBM 704 and "just translate them". > Your ideal world where programmers support and recompile games 3 decades after release does not exist in reality. Happens in literally every other programming industry though. The reason this cannot happen in the games industry is that game developers are not good software developers. They are much more akin to physics-numerical-methods people who can write some magic spaghetti-Fortran that runs really fast and does black magic, but no one can maintain, debug or integrate.