3 ms·

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

by 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.
- banachtarski 7y ago
  > Apple does all their driver and API development in house Not OP but the games and film industry believe this here is the problem. The additional effort to support common APIs is an artificial self-imposed problem resulting in worse software.
  - dagmx 7y ago
    I'll definitely agree here that it's got its share of pros and cons, and having worked in both realtime and film work, it is difficult. But on the flip side, it does fit in with apples ability to develop very tailored platforms and make very easy to use APIs. So while I often find myself on the wrong side of the double edged sword, I do also feel their decisions make sense as well. And honestly, having done dx9-12, OpenGL and Vulkan, I won't argue against how easy to use metal is.
    - banachtarski 7y ago
      I'm sort of mixed on how easy Metal is. Having to support Objective-C and/or Swift as part of the build toolchain is sort of a headache and Metal actually isn't low-level enough for me to support a lot of the optimizations I can do in DX12/Vulkan and especially doesn't come close to console APIs (which you'd think should be possible given that they can specialize for their hardware). My feeling is that for driver APIs, it's ok for the API to be lower level since users (and other developers) generally won't need to deal with that anyways.
  - pjmlp 7y ago
    Given what was shown at WWDC regarding software support and hardware for live 8K HD editing, I don't think film industry is that much worried. As for games, the sales speak for themselves.
- bangonkeyboard 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. How does this jibe with your position that Apple isn't performing lock-in, particularly when Apple is now specifically refusing to approve previously-available Nvidia drivers and thereby preventing them from being used in external GPUs for Macs?
  - dagmx 7y ago
    The details of that aren't public other than both companies want control of the driver stack and neither is willing to budge. The driver breakage happened between major operating system versions that had significant graphics systems overhauls so would not be compatible as is. I don't classify that as lock in. It's an unfortunate side effect of business dealings between two immovable companies. However apple does work with AMD and Intel GPUs, and still allow AMD external GPUs.
- shmerl 7y ago
  > Supporting Vulkan would mean a lot more effort on their part. Unlike windows and Linux where support is handled by the GPU vendor instead. First of all, who exactly prevents GPU vendors from doing it for Apple? Apple. Secondly, with Apple's resources I don't buy the excuse of "it's too hard" or "we can't spend on it". Apple are very happily spending piles of money, when it helps them hamper interoperability in result. So being cheap here is just another lame excuse for lock-in.
  - dagmx 7y ago
    It's simple policy. Apple do their own dev and don't use third party companies for the development. This is for a variety of reasons including providing a tailored platform to their specifications, and meeting the level of secrecy required internally. Whether you agree or not with the policy, it's not one motivated by lock in. And again it's not a matter of being cheap. It's a matter of perspective. Apple believe metal is worth using and that it delivers needed performance, optimization and features for their stack. Apple also believe in very straightforward developer stories within their own platform. Vulkan doesn't provide value above and beyond what metal does from apples perspective, and it complicates their developer story.
    - shmerl 7y ago
      > It's a matter of perspective. That's my point too - their perspective is lock-in. Not just in graphics APIs but in many things. So this issue falls into the common picture with many other similar ones. I.e. Apple could easily implement it. They don't for political reasons, and I don't buy any lame excuses like "that's better for developers" and such.
      - dagmx 7y ago
        No , your perspective is lock in. You're trying to fit all their rationale into one convenient box and ignoring the nuance of the situation.
        shmerl 7y ago
pjmlp 7y ago
Google is the company currently driving WebGPU efforts and has shown the fruits of their labour at Google IO. To the point that what Intel has contributed to WebGL 2.0 compute shaders implementation on Chrome might be thrown away, as Google now considers it needless in presence of WebGPU. Which by the way is based on HLSL, just as Khronos is also finding out on their Vulkan PR efforts, is the favourite shading language among professional game devs. Which is why Samsung and Google are the two biggest contributors to HLSL to SPIR-V compiler.
- shmerl 7y ago
  Shader language shouldn't matter as long as it's compiled to standard SPIR-V. There is no point to limit it to one language.
  - pjmlp 7y ago
    It matters if the available tooling isn't practical.
    - erikpukinskis 7y ago
      What do you mean tooling? Like Unity?
      - pjmlp 7y ago
        IDE like support for shader development, something that all proprietary APIs support out of the box, and both OpenGL and now Vulkan have always been lacking. Usually what gets thrown by OEMs or FOSS devs looks more like sample apps, are OEM specific thus making the API not as portable as advertised, or feel short. For example you can pinpoint specific pixels and trace back to which code lines from each shader were involved in rendering the pixel. Check the Metal debugging talk at WWDC 2019.

by shmerl 7y ago

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.

banachtarski 7y ago
> Apple does all their driver and API development in house Not OP but the games and film industry believe this here is the problem. The additional effort to support common APIs is an artificial self-imposed problem resulting in worse software.
- dagmx 7y ago
  I'll definitely agree here that it's got its share of pros and cons, and having worked in both realtime and film work, it is difficult. But on the flip side, it does fit in with apples ability to develop very tailored platforms and make very easy to use APIs. So while I often find myself on the wrong side of the double edged sword, I do also feel their decisions make sense as well. And honestly, having done dx9-12, OpenGL and Vulkan, I won't argue against how easy to use metal is.
  - banachtarski 7y ago
    I'm sort of mixed on how easy Metal is. Having to support Objective-C and/or Swift as part of the build toolchain is sort of a headache and Metal actually isn't low-level enough for me to support a lot of the optimizations I can do in DX12/Vulkan and especially doesn't come close to console APIs (which you'd think should be possible given that they can specialize for their hardware). My feeling is that for driver APIs, it's ok for the API to be lower level since users (and other developers) generally won't need to deal with that anyways.
- pjmlp 7y ago
  Given what was shown at WWDC regarding software support and hardware for live 8K HD editing, I don't think film industry is that much worried. As for games, the sales speak for themselves.
bangonkeyboard 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. How does this jibe with your position that Apple isn't performing lock-in, particularly when Apple is now specifically refusing to approve previously-available Nvidia drivers and thereby preventing them from being used in external GPUs for Macs?
- dagmx 7y ago
  The details of that aren't public other than both companies want control of the driver stack and neither is willing to budge. The driver breakage happened between major operating system versions that had significant graphics systems overhauls so would not be compatible as is. I don't classify that as lock in. It's an unfortunate side effect of business dealings between two immovable companies. However apple does work with AMD and Intel GPUs, and still allow AMD external GPUs.
shmerl 7y ago
> Supporting Vulkan would mean a lot more effort on their part. Unlike windows and Linux where support is handled by the GPU vendor instead. First of all, who exactly prevents GPU vendors from doing it for Apple? Apple. Secondly, with Apple's resources I don't buy the excuse of "it's too hard" or "we can't spend on it". Apple are very happily spending piles of money, when it helps them hamper interoperability in result. So being cheap here is just another lame excuse for lock-in.
- dagmx 7y ago
  It's simple policy. Apple do their own dev and don't use third party companies for the development. This is for a variety of reasons including providing a tailored platform to their specifications, and meeting the level of secrecy required internally. Whether you agree or not with the policy, it's not one motivated by lock in. And again it's not a matter of being cheap. It's a matter of perspective. Apple believe metal is worth using and that it delivers needed performance, optimization and features for their stack. Apple also believe in very straightforward developer stories within their own platform. Vulkan doesn't provide value above and beyond what metal does from apples perspective, and it complicates their developer story.
  - shmerl 7y ago
    > It's a matter of perspective. That's my point too - their perspective is lock-in. Not just in graphics APIs but in many things. So this issue falls into the common picture with many other similar ones. I.e. Apple could easily implement it. They don't for political reasons, and I don't buy any lame excuses like "that's better for developers" and such.
    - dagmx 7y ago
      No , your perspective is lock in. You're trying to fit all their rationale into one convenient box and ignoring the nuance of the situation.
      - shmerl 7y ago

pjmlp 7y ago

Google is the company currently driving WebGPU efforts and has shown the fruits of their labour at Google IO. To the point that what Intel has contributed to WebGL 2.0 compute shaders implementation on Chrome might be thrown away, as Google now considers it needless in presence of WebGPU. Which by the way is based on HLSL, just as Khronos is also finding out on their Vulkan PR efforts, is the favourite shading language among professional game devs. Which is why Samsung and Google are the two biggest contributors to HLSL to SPIR-V compiler.

shmerl 7y ago
Shader language shouldn't matter as long as it's compiled to standard SPIR-V. There is no point to limit it to one language.
- pjmlp 7y ago
  It matters if the available tooling isn't practical.
  - erikpukinskis 7y ago
    What do you mean tooling? Like Unity?
    - pjmlp 7y ago
      IDE like support for shader development, something that all proprietary APIs support out of the box, and both OpenGL and now Vulkan have always been lacking. Usually what gets thrown by OEMs or FOSS devs looks more like sample apps, are OEM specific thus making the API not as portable as advertised, or feel short. For example you can pinpoint specific pixels and trace back to which code lines from each shader were involved in rendering the pixel. Check the Metal debugging talk at WWDC 2019.