8 ms·

They don't need to. Also Metal isn't really 1:1 comparable to Vulkan in terms of abstraction level.

shmerl 7y ago
Same way MS didn't need to support common HTML/JavaScript since they had ActiveX? If Apple would have acted properly, instead of their usual "eat our lock-in" mentality, they could provide Vulkan support, and then build higher Metal-style abstractions on top of it. But no, it's Apple for you. Eat Apple only Metal or get lost.
- dmitriid 7y ago
  Apple has all the right to not think about Vulkan and invest in their own implementation. - First release of Metal is June 2014. The Khronos Group began a project to create a next generation graphics API in July 2014. First release of Vulkan is 2016. - Metal is C++. Vulkan is C. Yes, that may matter - Metal is specifically optimised for a specific set of hardware with known capabilities. Vulkan aims at everything under the Sun - Vulkan is headed by a consortium that wasn't known for its great decisions in the past, and Apple might want a faster turnaround on features and capabilities - It's just business
  - flohofwoe 7y ago
    > Metal is C++. Vulkan is C. Yes, that may matter The Metal API is Obj-C or Swift, only the shading language is a C++ variant. A C-API (not C++) would actually be nice. While ARC is quite convenient it also adds a significant overhead. Most of this overhead can be prevented with quite a lot of handholding, but this also reduces the benefits of high-level languages like Objective-C or Swift, I'd even argue that this handholding is more hassle than having a more explicit C-API to begin with.
  - shmerl 7y ago
    All of that is not a justification for their sick lock-in. - It was explained above, that Apple knew well all along, that there was an effort to make a common low level API. Well before they started Metal. So they purposefully refused to participate. - C was a proper choice for Vulkan (short of choosing Rust let's say), since it makes it easier to provide bindings from any language than let's say using C++, making bindings to which is way more painful. - Optimization for hardware happens on low level compilation, so it's a lame excuse not to support Vulkan. - Faster or not, Apple could observe the result (which was good) once it was ready, and support it. They refused (because Apple). - Business or not, lock-in is a nasty attitude that's aimed at taxing developers. There is no no need for development tools lock-in, it's a sick anti-competitive methodology, for which Apple is quite infamous.
    - dagmx 7y ago
      When Metal was initially developed and even when it was released, Vulkan wasn't even a proposed project yet. The only comparable thing was Mantle from AMD (which later evolved into Vulkan). At the time NVidia were still saying use OpenGL with AZDO techniques and on mobile, you were stuck with OpenGL ES, with a multitude of issues. Optimization of existing code happens at a lower level but if you can gear an API for optimal use of your hardware and existing APIs, you make it easier for developers to write code that will have a better shot at being optimized. Not all code optimizes the same way. Also what you view as taxing developers, can also be flipped around as being able to make an API that is a lot easier for the developers on their platform. And indeed, metal is probably the easiest of the modern graphics APIs to get started with, with a very light learning curve even compared to OpenGL. All while not sacrificing performance and expressiveness for more involved development. Vulkan meanwhile remains very inaccessible to many developers even with graphics backgrounds. Let's not also forget that apple isn't an outlier for lockin, and actually are quite open. OpenCL, Clang, webgpu, swift etc are all very open and cross platform. Meanwhile even things like directx are locked to windows. The real goal isn't lockin. It's providing the best API to developers to let them get in quickly while also optimizing for their hardware. Lockin is an unfortunate side effect but they're also completely succesful in meeting their actual goals.
      - shmerl 7y ago
        > The real goal isn't lockin. That's an excuse, since the result is lock-in. I.e. if Apple so much wanted Metal - let them have it. But how does that prevent them from supporting Vulkan, for those who don't want to waste resources on duplicating work and want to reuse their existing Vulkan codebase on Apple systems? But no, Apple forces you to use Metal. So the claim that it's for developers' benefit won't fly. It's for Apple's benefit very clearly. WebGPU is also a counter example, since Apple there try to prevent adoption of common formats like SPIR-V. When it comes to sabotaging interoperability, Apple are always among the first.
        dagmx 7y ago
        Apple does all their driver and API development in house. Supporting Vulkan would mean a lot more effort on their part. Unlike windows and Linux where support is handled by the GPU vendor instead. Why support Vulkan, which is arguably harder to use and takes more resources of their internal development teams, when they have an API that provides all the benefits and is arguably a better API? Especially when the major off the shelf engines already support metal. It's diminishing returns at this point. Personally I'd be quite happy to have Vulkan support on mac, but if you take a step back from your inalienable position that it's a conspiracy, there's actually very sound reasoning behind it. You may not agree with the decision, but you weaken your argument when you're trying to force everything to fit a black and white narrative. The reality is much more nuanced.
  - deleted 7y ago
    [deleted]
- olliej 7y ago
  What’s the story with Microsoft support Vulkan? Oh that’s right they only support direct3d. Because tying an OS cycle to a standards body causes significant problems in terms of feature lag, validation, etc
  - shmerl 7y ago
    Is MS being a lock-in jerk an excuse for Apple being one? This thread is about Apple, but if you want to bring MS in it - they at least don't force you to use DX on Windows. I.e. you can use Vulkan there. They do on Xbox though. Which is a similar problem.
    - pjmlp 7y ago
      Vulkan only works on the classical Win32 subsystem. Win32/UWP store sandbox does not support OpenGL ICDs, which is the mechanism used by Vulkan drivers on Windows.
      - shmerl 7y ago
        UWP is dead, luckily MS understood they want too far with it and dropped that lock-in nonsense.
        pjmlp 7y ago
        UWP is pretty much alive, that narrative keeps being spread by people that don't have any clue about Windows programming. The only thing from UWP that is dead is an UWP only store. The store, now as a mix Win32/UWP sandbox and the ongoing replacement of Win32 legacy APIs by UWP ones is pretty much alive. In fact React Native for Windows is being rewritten to use UWP APIs, using WinUI 3.0, which is also the official MFC replacement for C++ devs.
        shmerl 7y ago
        Alive as any MS dead end. Of course they won't just drop it, they need to support existing stuff that's using it. But MS buried their plans to make it a mandatory requirement. That's the end of it in essence. Which is good, we don't need this lock-in forced on developers.
SomeOldThrow 7y ago
They don’t need to do anything. It would be a more attractive platform to develop for with a modern cross platform graphics api.

Same way MS didn't need to support common HTML/JavaScript since they had ActiveX? If Apple would have acted properly, instead of their usual "eat our lock-in" mentality, they could provide Vulkan support, and then build higher Metal-style abstractions on top of it. But no, it's Apple for you. Eat Apple only Metal or get lost.

dmitriid 7y ago
Apple has all the right to not think about Vulkan and invest in their own implementation. - First release of Metal is June 2014. The Khronos Group began a project to create a next generation graphics API in July 2014. First release of Vulkan is 2016. - Metal is C++. Vulkan is C. Yes, that may matter - Metal is specifically optimised for a specific set of hardware with known capabilities. Vulkan aims at everything under the Sun - Vulkan is headed by a consortium that wasn't known for its great decisions in the past, and Apple might want a faster turnaround on features and capabilities - It's just business
- flohofwoe 7y ago
  > Metal is C++. Vulkan is C. Yes, that may matter The Metal API is Obj-C or Swift, only the shading language is a C++ variant. A C-API (not C++) would actually be nice. While ARC is quite convenient it also adds a significant overhead. Most of this overhead can be prevented with quite a lot of handholding, but this also reduces the benefits of high-level languages like Objective-C or Swift, I'd even argue that this handholding is more hassle than having a more explicit C-API to begin with.
- shmerl 7y ago
  All of that is not a justification for their sick lock-in. - It was explained above, that Apple knew well all along, that there was an effort to make a common low level API. Well before they started Metal. So they purposefully refused to participate. - C was a proper choice for Vulkan (short of choosing Rust let's say), since it makes it easier to provide bindings from any language than let's say using C++, making bindings to which is way more painful. - Optimization for hardware happens on low level compilation, so it's a lame excuse not to support Vulkan. - Faster or not, Apple could observe the result (which was good) once it was ready, and support it. They refused (because Apple). - Business or not, lock-in is a nasty attitude that's aimed at taxing developers. There is no no need for development tools lock-in, it's a sick anti-competitive methodology, for which Apple is quite infamous.
  - dagmx 7y ago
    When Metal was initially developed and even when it was released, Vulkan wasn't even a proposed project yet. The only comparable thing was Mantle from AMD (which later evolved into Vulkan). At the time NVidia were still saying use OpenGL with AZDO techniques and on mobile, you were stuck with OpenGL ES, with a multitude of issues. Optimization of existing code happens at a lower level but if you can gear an API for optimal use of your hardware and existing APIs, you make it easier for developers to write code that will have a better shot at being optimized. Not all code optimizes the same way. Also what you view as taxing developers, can also be flipped around as being able to make an API that is a lot easier for the developers on their platform. And indeed, metal is probably the easiest of the modern graphics APIs to get started with, with a very light learning curve even compared to OpenGL. All while not sacrificing performance and expressiveness for more involved development. Vulkan meanwhile remains very inaccessible to many developers even with graphics backgrounds. Let's not also forget that apple isn't an outlier for lockin, and actually are quite open. OpenCL, Clang, webgpu, swift etc are all very open and cross platform. Meanwhile even things like directx are locked to windows. The real goal isn't lockin. It's providing the best API to developers to let them get in quickly while also optimizing for their hardware. Lockin is an unfortunate side effect but they're also completely succesful in meeting their actual goals.
    - shmerl 7y ago
      > The real goal isn't lockin. That's an excuse, since the result is lock-in. I.e. if Apple so much wanted Metal - let them have it. But how does that prevent them from supporting Vulkan, for those who don't want to waste resources on duplicating work and want to reuse their existing Vulkan codebase on Apple systems? But no, Apple forces you to use Metal. So the claim that it's for developers' benefit won't fly. It's for Apple's benefit very clearly. WebGPU is also a counter example, since Apple there try to prevent adoption of common formats like SPIR-V. When it comes to sabotaging interoperability, Apple are always among the first.
      - dagmx 7y ago
        Apple does all their driver and API development in house. Supporting Vulkan would mean a lot more effort on their part. Unlike windows and Linux where support is handled by the GPU vendor instead. Why support Vulkan, which is arguably harder to use and takes more resources of their internal development teams, when they have an API that provides all the benefits and is arguably a better API? Especially when the major off the shelf engines already support metal. It's diminishing returns at this point. Personally I'd be quite happy to have Vulkan support on mac, but if you take a step back from your inalienable position that it's a conspiracy, there's actually very sound reasoning behind it. You may not agree with the decision, but you weaken your argument when you're trying to force everything to fit a black and white narrative. The reality is much more nuanced.
- deleted 7y ago
  [deleted]
olliej 7y ago
What’s the story with Microsoft support Vulkan? Oh that’s right they only support direct3d. Because tying an OS cycle to a standards body causes significant problems in terms of feature lag, validation, etc
- shmerl 7y ago
  Is MS being a lock-in jerk an excuse for Apple being one? This thread is about Apple, but if you want to bring MS in it - they at least don't force you to use DX on Windows. I.e. you can use Vulkan there. They do on Xbox though. Which is a similar problem.
  - pjmlp 7y ago
    Vulkan only works on the classical Win32 subsystem. Win32/UWP store sandbox does not support OpenGL ICDs, which is the mechanism used by Vulkan drivers on Windows.
    - shmerl 7y ago
      UWP is dead, luckily MS understood they want too far with it and dropped that lock-in nonsense.
      - pjmlp 7y ago
        UWP is pretty much alive, that narrative keeps being spread by people that don't have any clue about Windows programming. The only thing from UWP that is dead is an UWP only store. The store, now as a mix Win32/UWP sandbox and the ongoing replacement of Win32 legacy APIs by UWP ones is pretty much alive. In fact React Native for Windows is being rewritten to use UWP APIs, using WinUI 3.0, which is also the official MFC replacement for C++ devs.
        shmerl 7y ago
        Alive as any MS dead end. Of course they won't just drop it, they need to support existing stuff that's using it. But MS buried their plans to make it a mandatory requirement. That's the end of it in essence. Which is good, we don't need this lock-in forced on developers.

SomeOldThrow 7y ago

They don’t need to do anything. It would be a more attractive platform to develop for with a modern cross platform graphics api.