5 ms·

I guess some will see this as good news, but further entrenching Metal is just sad in my opinion. So much wasted effort just because they can't admit they lost

I guess some will see this as good news, but further entrenching Metal is just sad in my opinion. So much wasted effort just because they can't admit they lost the standards game and won't move to Vulkan. The generous interpretation is they just don't want to invest into that if it isn't "broken" but the cynic in me can't help but think at least part of the motivation is being different and maintaining the wall around the garden.

user-the-name 5y ago
Vulkan isn't a viable alternative for Apple. Apple wants to give developer an easy to use API to encourage them to use it as much as possible. Vulkan does not offer that.
- smoldesu 5y ago
  Why didn't they just build a higher-level API on top of Vulkan then? Surely it's not a lack of developers, interest or resources, is it?
  - pjmlp 5y ago
    If they have to build their own snowflake on top of others API, specially since Khronos doesn't care about C++ as shading language, why bother?
- cma 5y ago
  Nah they want lock in, in the Epic Suit Epic used almost none of their libs but had to use Metal to function, and they were about to extract leverage by pulling a dev license for desktop. All POSIX and Vulkan/OpenGL and they could have stayed safe.
Encounter 5y ago
Metal is by far a much friendlier API than Vulkan. Its approach with opt-in complexity is arguably the correct one. (Ever tried writing a Vulkan "Hello triangle" from scratch?) It's also gaining some nice features that are usable out of the gate, rather than waiting on Vulkan extension standardization and adoption. It simply makes the most sense for Apple.
- capableweb 5y ago
  > Metal is by far a much friendlier API than Vulkan Sure, but that was hardly the point of Vulkan in the first place. The point is to have cross-platform 3D grahipcs, but since Apple never gave a shit about anything cross-platform, they chose to write their own stuff. And if they actually did care, they could have modeled the same API as they have with Metal, but over Vulkan, so the engine is the same but the API is "much friendlier". It simply makes the most business sense for Apple, but as is tradition, the whole software ecosystem is worse off because of their choices.
  - Encounter 5y ago
    Well you can use Vulkan over Metal with MoltenVK, so that point is a bit moot. Opinion time: WebGPU will become the standard graphics API to target for cross-platform. gfx-rs/wgpu already works over Vulkan/Metal/D3D12/D3D11/OpenGL/WebGL & WebGPU in browsers. Much better than simply Vulkan, unless performance is your primary sticking point.
    - pjmlp 5y ago
      First they have to sort out what that frankenstein merge of C++, HLSL and Rust named WGSL is supposed to look like.
    - capableweb 5y ago
      How is the point of Apple pushing Metal instead of Vulkan when the change request submitted to Blender is not using the MoltenVK stuff you're talking about? If anything it proves my point
xenadu02 5y ago
I don't know why we have to keep having this discussion but Metal pre-dates Vulkan. It shipped to developers in June 2014. Vulkan didn't ship until Feb 2016. Metal is the reason Vulkan exists: Apple announced Metal in June 2014 and the first Khronos meeting about a replacement for OpenGL was hosted at Valve in July 2014 so they could rush to announce an "open standard" under development at SIGGRAPH later that year. The only reason it managed to ship a final spec in 2016 was because AMD donated Mantle to boot-strap the process. When you make your own GPUs and have sufficient scale to get developer adoption owning your own API can let you move much faster than others while avoiding vendor extension hell (that turns into a bespoke API-within-an-API at the extreme end). Besides which MoltenVK effectively allows Vulkan software to run against Metal anyway. In that sense it's also better for Vulkan because it can ship API updates whenever Khronos feels like it.
- hvis 5y ago
  > Metal is the reason Vulkan exists That seems to give way too little credit to Mantle. Which was released in 2013 and became the basis for Vulkan.
  - xenadu02 5y ago
    Please re-read my parent comment. A few weeks after Apple announced Metal at WWDC Khronos members met for the first time ever to kickoff then project to replace OpenGL. I don't believe that is a coincidence. Maybe Metal was the straw that broke the Camel's back, maybe not. I also noted that AMD donated Mantle as the starting point which is why Vulkan didn't take 5 years to finalize. In any case claiming that Apple is somehow at fault for not adopting Vulkan doesn't make sense.
    - hvis 5y ago
      > Please re-read my parent comment. I just said that it's severely overstating the case. > In any case claiming that Apple is somehow at fault for not adopting Vulkan doesn't make sense. Why not? They could have adopted Mantle instead, for example. It came out a year earlier. Or it could have replaced Metal with Vulkan later (as it is often a reasonable choice to replace your custom solution with the industry's standard). Or it could have chosen to officially support Vulkan alongside it. Apple has lots of money in the bank, and with that, lots of options.
lonjil 5y ago
For Cycles, Vulkan is simply not an option. Metal compute is capable of everything OpenCL is, but is more modern / nicer / whatever, while Vulkan Compute is pretty crap and definitely can't be used as a replacement for OpenCL. The only cross platform alternative that actually works is OpenCL, but Blender is moving away from OpenCL, mostly because literally every GPU vendor is doing so as well.
- zozbot234 5y ago
  AIUI, Vulkan Compute is just missing a few math-focused extensions compared to OpenCL. The OpenCL memory model is also more full-featured (i.e. it allows for general pointers) but that can be addressed via other Vulkan extensions. The more annoying variation between the two is the need to refactor the code from using "kernels" to "compute shaders", but that's just a difference in the underlying programming model.
  - pjmlp 5y ago
    Yeah, and is also "just" misses having an ecosystem like SYSCL or CUDA for C++, with polyglot infrastructure targeting the GPU. Yes, there is SPIR-V, yet few care to target it in practice, besides typical shading languages.

user-the-name 5y ago

Vulkan isn't a viable alternative for Apple. Apple wants to give developer an easy to use API to encourage them to use it as much as possible. Vulkan does not offer that.

smoldesu 5y ago
Why didn't they just build a higher-level API on top of Vulkan then? Surely it's not a lack of developers, interest or resources, is it?
- pjmlp 5y ago
  If they have to build their own snowflake on top of others API, specially since Khronos doesn't care about C++ as shading language, why bother?
cma 5y ago
Nah they want lock in, in the Epic Suit Epic used almost none of their libs but had to use Metal to function, and they were about to extract leverage by pulling a dev license for desktop. All POSIX and Vulkan/OpenGL and they could have stayed safe.

Encounter 5y ago

Metal is by far a much friendlier API than Vulkan. Its approach with opt-in complexity is arguably the correct one. (Ever tried writing a Vulkan "Hello triangle" from scratch?) It's also gaining some nice features that are usable out of the gate, rather than waiting on Vulkan extension standardization and adoption. It simply makes the most sense for Apple.

capableweb 5y ago
> Metal is by far a much friendlier API than Vulkan Sure, but that was hardly the point of Vulkan in the first place. The point is to have cross-platform 3D grahipcs, but since Apple never gave a shit about anything cross-platform, they chose to write their own stuff. And if they actually did care, they could have modeled the same API as they have with Metal, but over Vulkan, so the engine is the same but the API is "much friendlier". It simply makes the most business sense for Apple, but as is tradition, the whole software ecosystem is worse off because of their choices.
- Encounter 5y ago
  Well you can use Vulkan over Metal with MoltenVK, so that point is a bit moot. Opinion time: WebGPU will become the standard graphics API to target for cross-platform. gfx-rs/wgpu already works over Vulkan/Metal/D3D12/D3D11/OpenGL/WebGL & WebGPU in browsers. Much better than simply Vulkan, unless performance is your primary sticking point.
  - pjmlp 5y ago
    First they have to sort out what that frankenstein merge of C++, HLSL and Rust named WGSL is supposed to look like.
  - capableweb 5y ago
    How is the point of Apple pushing Metal instead of Vulkan when the change request submitted to Blender is not using the MoltenVK stuff you're talking about? If anything it proves my point

xenadu02 5y ago

I don't know why we have to keep having this discussion but Metal pre-dates Vulkan. It shipped to developers in June 2014. Vulkan didn't ship until Feb 2016. Metal is the reason Vulkan exists: Apple announced Metal in June 2014 and the first Khronos meeting about a replacement for OpenGL was hosted at Valve in July 2014 so they could rush to announce an "open standard" under development at SIGGRAPH later that year. The only reason it managed to ship a final spec in 2016 was because AMD donated Mantle to boot-strap the process. When you make your own GPUs and have sufficient scale to get developer adoption owning your own API can let you move much faster than others while avoiding vendor extension hell (that turns into a bespoke API-within-an-API at the extreme end). Besides which MoltenVK effectively allows Vulkan software to run against Metal anyway. In that sense it's also better for Vulkan because it can ship API updates whenever Khronos feels like it.

hvis 5y ago
> Metal is the reason Vulkan exists That seems to give way too little credit to Mantle. Which was released in 2013 and became the basis for Vulkan.
- xenadu02 5y ago
  Please re-read my parent comment. A few weeks after Apple announced Metal at WWDC Khronos members met for the first time ever to kickoff then project to replace OpenGL. I don't believe that is a coincidence. Maybe Metal was the straw that broke the Camel's back, maybe not. I also noted that AMD donated Mantle as the starting point which is why Vulkan didn't take 5 years to finalize. In any case claiming that Apple is somehow at fault for not adopting Vulkan doesn't make sense.
  - hvis 5y ago
    > Please re-read my parent comment. I just said that it's severely overstating the case. > In any case claiming that Apple is somehow at fault for not adopting Vulkan doesn't make sense. Why not? They could have adopted Mantle instead, for example. It came out a year earlier. Or it could have replaced Metal with Vulkan later (as it is often a reasonable choice to replace your custom solution with the industry's standard). Or it could have chosen to officially support Vulkan alongside it. Apple has lots of money in the bank, and with that, lots of options.

lonjil 5y ago

For Cycles, Vulkan is simply not an option. Metal compute is capable of everything OpenCL is, but is more modern / nicer / whatever, while Vulkan Compute is pretty crap and definitely can't be used as a replacement for OpenCL. The only cross platform alternative that actually works is OpenCL, but Blender is moving away from OpenCL, mostly because literally every GPU vendor is doing so as well.

zozbot234 5y ago
AIUI, Vulkan Compute is just missing a few math-focused extensions compared to OpenCL. The OpenCL memory model is also more full-featured (i.e. it allows for general pointers) but that can be addressed via other Vulkan extensions. The more annoying variation between the two is the need to refactor the code from using "kernels" to "compute shaders", but that's just a difference in the underlying programming model.
- pjmlp 5y ago
  Yeah, and is also "just" misses having an ecosystem like SYSCL or CUDA for C++, with polyglot infrastructure targeting the GPU. Yes, there is SPIR-V, yet few care to target it in practice, besides typical shading languages.