6 ms·

Apple has had many years after Vulkan came out to support it alongside Metal or phase out Metal with MoltenVk but we all know that’s not going to happen.

jjtheblunt 5y ago
Why would it happen if Metal is meant to support optimal performance on Apple hardware? I say that bearing in mind we're talking about battery powered hardware, which can not spend any extra cpu cycles on anything, period, without being berated in the press for short battery life compared to some competitor.
- gjsman-1000 5y ago
  Besides that, remember that if you use Vulkan, you will almost certainly end-up with something that is very optimized for one platform, but won't immediately run well on alternative platforms (see games with their frequent updates for new CPU and GPU architectures). Apple runs Metal on AMD GPUs, Intel iGPUs, and their own in-house Apple GPUs. If you used Metal, you didn't really have to do much optimization to get close-to-the-best-possible performance on all three of these very-different architectures.
- kcb 5y ago
  Many "native" Mac OS games are using MoltenVK. Obviously a translation layer is already not optimal for performance or efficiency.
giantrobot 5y ago
> Apple has had many years after Vulkan came out to support it alongside Metal Why would they do that? By the time Vulcan came out they had years of engineering effort in Metal.
- kcb 5y ago
  If Apple supported Vulkan it would pretty quickly be at parity with Linux for gaming. Proton/Wine/DXVK would actually make a new Macbook Pro a viable option for gaming.
  - giantrobot 5y ago
    Metal is not just about gaming. The entire graphics stack on all their platforms is drawn with Metal. Had they decided to switch from Metal to Vulkan when it was released they would have had to rewrite not just the low level Metal drawing but port everything (CoreAnimation etc) to it obviating all the work they'd been putting in for Metal. With Metal they've got an API whose design goes exactly where they want it to go and is developed hand in hand with their GPUs and NPUs. Since it's the base of the graphics stack every person hour spend improving Metal improves non-game apps as well as games. It's the same calculus as Microsoft investing in DirectX.
    - kcb 5y ago
      I'm not suggesting they drop Metal to support Vulkan.
      - dmitriid 5y ago
        So you're suggesting they support two different graphics stacks? Why? Or, rather, what for?
        deleted 5y ago
        [deleted]
        smoldesu 5y ago
        Because there's no reason not to, quite literally every other GPU vendor has supported Vulkan alongside DirectX. Metal has clear and obvious shortcomings, so Apple continuing to expect developers to "just use it" won't ever get them the support that they desperately need, especially now that they're on Apple Silicon. Porting things to ARM is hard, but doable. Creating a second version of your software just to run on Apple devices, that needs to be bug-fixed and maintained separately is a suicide mission. So yes, I am suggesting that they support two different graphics stacks. Apple has the most liquid cash out of any company in the world right now, they've got the resources to do it, especially as opposed to the developers who'd need to maintain two different versions of their software to compensate.
my123 5y ago
> phase out Metal From the GPU compute perspective: Vulkan has a subset of the features that Metal has. Metal uses a device programming language that is C++ based, has pointers... and uses AIR (an LLVM IR dialect) as the bytecode. Vulkan would be a big downgrade in feature levels from that. While it is very much possible (and done) to have a compliant OpenCL implementation over Metal or D3D12, such a thing isn't possible at all for Vulkan.
- pcwalton 5y ago
  Metal is also a subset of Vulkan. As Raph Levien points out here [1], there are certain important algorithms (decoupled lookback) that can't be implemented at all on Metal. [1]: https://raphlinus.github.io/gpu/2021/11/17/prefix-sum-portable.html https://raphlinus.github.io/gpu/2021/11/17/prefix-sum-portab...
  - my123 5y ago
    > One controversial aspect of the original decoupled look-back algorithm is that it depends a forward progress guarantee from the GPU Apple GPUs aren't very amenable to implementing recursion or giving forward progress guarantees within a SIMD group by design. I'll have to check if a device-wide barrier type even exists on that TBDR... It isn't like NVIDIA hardware (since Volta) where you have a separate instruction pointer for each (SIMT-but-not-quite) thread.
  - my123 5y ago
    Ok checked more... With #define _AIR_MEM_SCOPE_DEVICE 0x2 and: typedef enum __air_mem_flags { mem_flags_global = 0x1, mem_flags_local = 0x2, mem_flags_texture = 0x4 } __air_mem_flags; and __attribute__((__no_duplicate__)) void _air_llvm_mem_barrier(__air_mem_flags flags, int scope) __asm("air.mem_barrier"); what does _air_llvm_mem_barrier((__air_mem_flags)mem_flags_global, _AIR_MEM_SCOPE_DEVICE) result in for you? Some things in that make me go hmmmmm though, will ask Apple for some answers.
    - raphlinus 5y ago
      While this might work on your specific device, it is an undocumented interface and there is no guarantee at all for future compatibility. If you do get a definitive answer from Apple you can share, please follow up here, as I would like to be able to cite it. I would be quite shocked if it's different than what I just said, though.

jjtheblunt 5y ago

Why would it happen if Metal is meant to support optimal performance on Apple hardware? I say that bearing in mind we're talking about battery powered hardware, which can not spend any extra cpu cycles on anything, period, without being berated in the press for short battery life compared to some competitor.

gjsman-1000 5y ago
Besides that, remember that if you use Vulkan, you will almost certainly end-up with something that is very optimized for one platform, but won't immediately run well on alternative platforms (see games with their frequent updates for new CPU and GPU architectures). Apple runs Metal on AMD GPUs, Intel iGPUs, and their own in-house Apple GPUs. If you used Metal, you didn't really have to do much optimization to get close-to-the-best-possible performance on all three of these very-different architectures.
kcb 5y ago
Many "native" Mac OS games are using MoltenVK. Obviously a translation layer is already not optimal for performance or efficiency.

giantrobot 5y ago

> Apple has had many years after Vulkan came out to support it alongside Metal Why would they do that? By the time Vulcan came out they had years of engineering effort in Metal.

kcb 5y ago
If Apple supported Vulkan it would pretty quickly be at parity with Linux for gaming. Proton/Wine/DXVK would actually make a new Macbook Pro a viable option for gaming.
- giantrobot 5y ago
  Metal is not just about gaming. The entire graphics stack on all their platforms is drawn with Metal. Had they decided to switch from Metal to Vulkan when it was released they would have had to rewrite not just the low level Metal drawing but port everything (CoreAnimation etc) to it obviating all the work they'd been putting in for Metal. With Metal they've got an API whose design goes exactly where they want it to go and is developed hand in hand with their GPUs and NPUs. Since it's the base of the graphics stack every person hour spend improving Metal improves non-game apps as well as games. It's the same calculus as Microsoft investing in DirectX.
  - kcb 5y ago
    I'm not suggesting they drop Metal to support Vulkan.
    - dmitriid 5y ago
      So you're suggesting they support two different graphics stacks? Why? Or, rather, what for?
      - deleted 5y ago
        [deleted]
      - smoldesu 5y ago
        Because there's no reason not to, quite literally every other GPU vendor has supported Vulkan alongside DirectX. Metal has clear and obvious shortcomings, so Apple continuing to expect developers to "just use it" won't ever get them the support that they desperately need, especially now that they're on Apple Silicon. Porting things to ARM is hard, but doable. Creating a second version of your software just to run on Apple devices, that needs to be bug-fixed and maintained separately is a suicide mission. So yes, I am suggesting that they support two different graphics stacks. Apple has the most liquid cash out of any company in the world right now, they've got the resources to do it, especially as opposed to the developers who'd need to maintain two different versions of their software to compensate.

my123 5y ago

> phase out Metal From the GPU compute perspective: Vulkan has a subset of the features that Metal has. Metal uses a device programming language that is C++ based, has pointers... and uses AIR (an LLVM IR dialect) as the bytecode. Vulkan would be a big downgrade in feature levels from that. While it is very much possible (and done) to have a compliant OpenCL implementation over Metal or D3D12, such a thing isn't possible at all for Vulkan.

pcwalton 5y ago
Metal is also a subset of Vulkan. As Raph Levien points out here [1], there are certain important algorithms (decoupled lookback) that can't be implemented at all on Metal. [1]: https://raphlinus.github.io/gpu/2021/11/17/prefix-sum-portable.html https://raphlinus.github.io/gpu/2021/11/17/prefix-sum-portab...
- my123 5y ago
  > One controversial aspect of the original decoupled look-back algorithm is that it depends a forward progress guarantee from the GPU Apple GPUs aren't very amenable to implementing recursion or giving forward progress guarantees within a SIMD group by design. I'll have to check if a device-wide barrier type even exists on that TBDR... It isn't like NVIDIA hardware (since Volta) where you have a separate instruction pointer for each (SIMT-but-not-quite) thread.
- my123 5y ago
  Ok checked more... With #define _AIR_MEM_SCOPE_DEVICE 0x2 and: typedef enum __air_mem_flags { mem_flags_global = 0x1, mem_flags_local = 0x2, mem_flags_texture = 0x4 } __air_mem_flags; and __attribute__((__no_duplicate__)) void _air_llvm_mem_barrier(__air_mem_flags flags, int scope) __asm("air.mem_barrier"); what does _air_llvm_mem_barrier((__air_mem_flags)mem_flags_global, _AIR_MEM_SCOPE_DEVICE) result in for you? Some things in that make me go hmmmmm though, will ask Apple for some answers.
  - raphlinus 5y ago
    While this might work on your specific device, it is an undocumented interface and there is no guarantee at all for future compatibility. If you do get a definitive answer from Apple you can share, please follow up here, as I would like to be able to cite it. I would be quite shocked if it's different than what I just said, though.