8 ms·

There's mostly not a reason why we couldn't have a single API other than politics. My opinionated takes (opinions mine and not those of my employer, etc.): Vul

There's mostly not a reason why we couldn't have a single API other than politics. My opinionated takes (opinions mine and not those of my employer, etc.): Vulkan: Standardized by a standards body (Khronos). In an ideal world we would all be using this. D3D12: Microsoft likes Direct3D and has the market power to be able to push its own API. However, the situation on Windows isn't as bad as on macOS/iOS because drivers generally support Vulkan as well. Metal: This mostly exists because Apple refuses to support anything Khronos related, for not-particularly-compelling reasons. It does have the excuse that it was being developed before Vulkan, but in 2021 its existence is not particularly well-motivated. WebGPU: As an API, WebGPU in some form has to exist because Vulkan is not safe (in the memory-safe sense). For untrusted content on the Web, you need a somewhat higher-level API than Vulkan that automatically inserts barriers, more like Metal (though Metal is not particularly principled about this and is unsafe in some ways as well). That being said, Web Shading Language is just Apple playing politics again regarding Khronos, as the rest of the committee wanted to use SPIR-V. There's no compelling reason why Web Shading Language needs to exist.

sircastor 5y ago
My theory about Metal is that Apple wanted to own the whole stack, and controlling the API meant they could plan ahead for their own silicon. Instead of being limited to the way a standards body planned around existing silicon and ISAs, Apple gets to explicitly determine their own future.
enos_feedler 5y ago
Politics only plays such a strong role because at the end of the day having a single API doesn't solve a real problem. It's desirable because it reduces the surface area of new things developers have to learn if they want to target all these systems. However, mostly different people work on different targets and it really just helps with learning. In terms of actual building, deploying etc it's probably best to have proprietary things that wrap themselves cleanly around the systems they are operate in.
- pcwalton 5y ago
  Strong disagree as someone who spent years on a cross-platform accelerated vector graphics library in industry. Dealing with API differences and differences in tooling (Metal's tooling is far behind RenderDoc for example) took an enormous amount of my time, time that could otherwise have been spent fixing bugs and adding features.
  - enos_feedler 5y ago
    I don't disagree you had these problems. I'm just saying the market of developers in your pool is not very big. Most people are happy just learning a single platform, chip, etc and getting a job writing code against it. I get the allure of "if only every target spoke the language I Know.. then I could target all the things.." but in practice it's not really a problem
    - ncmncm 5y ago
      The sheer quantity of things not even started because of the excess cost of targeting everything absolutely dwarfs the sum total of what is now built for this or that target. We have seen this dynamic play out over and over again, in the past six+ decades, going all the way back to FORTRAN. A standard target would multiply the size of this "market" many times over, generating additional demand for implementations throughout multiple industries. Balkanization has always been a debilitating tax on everyone, not excepting "market leaders" scrapping over the artificially reduced pie. Everyone made way more money after FORTRAN than before.
      - enos_feedler 5y ago
        if the cost is attributed to "targeting everything" as you say, then wouldn't those things just get started by targeting one thing? Neither you or I can prove there are things not invented because of this, so nothing to debate here. The reason why pcwalton spent lots of effort jumping through hoops building a vector graphics library that targets lots of platforms is because we already know that vector graphics is something we had on a single platform. It is really hard for to imagine something not being invented/created at all because there isn't a single language that can express its computation everywhere simultaneously.
echelon 5y ago
Apple doesn't want the web to be a viable alternative to the app store. They'll continue to choose strategies that hold it back.
- slimsag 5y ago
  It's not so clear-cut, they're pouring a lot of resources into WebGPU and Safari.
  - astlouis44 5y ago
    This, they literally posted a TON of engineering WebGPU jobs just recently for their WebKit team.
- pcwalton 5y ago
  For what it's worth, I do not believe that this is Apple's strategy. Squabbles with Khronos suffice to explain everything.
- mensetmanusman 5y ago
  This is true, there is so much more that Safari could be capable of if it gave developers lower level hardware capabilities, but that would hurt the bottom line…
slimsag 5y ago
I agree with you about Web Shading Language not needing to exist. But I also don't think it's the end of the world, either. Google's Tint can translate between SPIR-V/GLSL/etc -> WGSL and vice-versa pretty well. If that's what it takes for Apple to be on board with WebGPU and we get an extension later to load SPIR-V (or some other WGSL binary form) later for optimization I'm cool with that.
- pcwalton 5y ago
  Yeah, the silver lining is that the amount of effort folks have gone to in order to ensure some level of interoperability has been amazing. Khronos developers working on SPIRV-Cross, wgpu-rs folks like kvark, MoltenVK people, Wine devs, etc. are unsung heroes of the graphics industry and deserve tons of support.
- kvark 5y ago
  Even if SPIRV input becomes available as an extension at some point, don’t expect it to be any kind of optimization. Both Tint and Naga’s IRs are close to WGSL, so parsing it is really easy and fast. Processing SPIRV’s control flow graph, images/samplers, atomics, is quite painful in comparison.
  - slimsag 5y ago
    From kvark himself, big fan of your work :) Very interesting, thanks for saying this, I wouldn't have thought SPIRV->Target could be faster than or near the same speed as WGSL->Target. I guess with compression probably being quite good, as well, there isn't much point of a SPIRV extension for download times or processing times?
pjmlp 5y ago
You missed LibGNM and NVN. DirectX and Metal are great with high level bindings, and much more productive shading languages, instead of "C way" that Khronos keeps pushing for.
- roblabla 5y ago
  Khronos is pushing for SPIR-V, which isn't a language but a bytecode. There are a lot of good reasons to do this: It allows innovation for shading languages to take place as anyone can build their own language and compile it down to SPIR-V, and it's much easier to parse than, say, GLSL, making it easier the proprietary drivers aren't doing something stupid. The DirectX shading language (HLSL) and the metal shading language (MSL) could both compile down to SPIR-V, other than the occasional missing feature that's not standardized yet.
  - kvark 5y ago
    Right, SPIRV is a good format as the destination of your shader pipeline. But it can only be that on Vulkan. With other backends, SPIRV doesn’t help, and instead stands in the way. https://kvark.github.io/spirv/2021/05/01/spirv-horrors.html https://kvark.github.io/spirv/2021/05/01/spirv-horrors.html
amelius 5y ago
> There's mostly not a reason why we couldn't have a single API other than politics. If you follow Apple's logic, this is totally wrong. Everything has to be integrated in order to achieve the best possible experience, and public APIs would be a bottleneck that make things inflexible for the company that tries to exploit the technology.
- hermitdev 5y ago
  I don't know, I feel like you could do a few name substitutions from this 16yr old comic [1] and it would perfectly fit this situation (of course Sony becomes Apple). [1] https://cad-comic.com/comic/doing-business/ https://cad-comic.com/comic/doing-business/
  - antifa 5y ago
    The difference is that Apple actually does achieve some minimal base line of quality while Sony just pretends it does.
RantyDave 5y ago
> There's no compelling reason why Web Shading Language needs to exist. I'm pretty sure it basically doesn't. WebGPU is supporting WGSL whose #1 goal is to be "trivially convertible to SPIR-V" (https://www.w3.org/TR/WGSL/#goals https://www.w3.org/TR/WGSL/#goals). In other words, it's text SPIR-V.
- kvark 5y ago
  It’s only talking about one way: WGSL->SPIRV, not the reverse. It also has to be trivially convertible to MSL and HLSL. So WGSL is a separate language now, most ties to SPIRV are cut off.
vimy 5y ago
Metal isn’t just a graphics api but also becoming a CUDA alternative. It’s a very important api for Apple.
nextweek2 5y ago
> It does have the excuse that it was being developed before Vulkan This is not true, Mantle was first. AMD donated the code to khronos and it became/was developed in public. Half way through Apple announced it would do its own thing and beat Vulkan to v1.0.0. Apple might have had a v1 before Vulkan but they're still dicks for not helping build a unified standard around AMDs generous once a generation offer.

sircastor 5y ago

My theory about Metal is that Apple wanted to own the whole stack, and controlling the API meant they could plan ahead for their own silicon. Instead of being limited to the way a standards body planned around existing silicon and ISAs, Apple gets to explicitly determine their own future.

enos_feedler 5y ago

Politics only plays such a strong role because at the end of the day having a single API doesn't solve a real problem. It's desirable because it reduces the surface area of new things developers have to learn if they want to target all these systems. However, mostly different people work on different targets and it really just helps with learning. In terms of actual building, deploying etc it's probably best to have proprietary things that wrap themselves cleanly around the systems they are operate in.

pcwalton 5y ago
Strong disagree as someone who spent years on a cross-platform accelerated vector graphics library in industry. Dealing with API differences and differences in tooling (Metal's tooling is far behind RenderDoc for example) took an enormous amount of my time, time that could otherwise have been spent fixing bugs and adding features.
- enos_feedler 5y ago
  I don't disagree you had these problems. I'm just saying the market of developers in your pool is not very big. Most people are happy just learning a single platform, chip, etc and getting a job writing code against it. I get the allure of "if only every target spoke the language I Know.. then I could target all the things.." but in practice it's not really a problem
  - ncmncm 5y ago
    The sheer quantity of things not even started because of the excess cost of targeting everything absolutely dwarfs the sum total of what is now built for this or that target. We have seen this dynamic play out over and over again, in the past six+ decades, going all the way back to FORTRAN. A standard target would multiply the size of this "market" many times over, generating additional demand for implementations throughout multiple industries. Balkanization has always been a debilitating tax on everyone, not excepting "market leaders" scrapping over the artificially reduced pie. Everyone made way more money after FORTRAN than before.
    - enos_feedler 5y ago
      if the cost is attributed to "targeting everything" as you say, then wouldn't those things just get started by targeting one thing? Neither you or I can prove there are things not invented because of this, so nothing to debate here. The reason why pcwalton spent lots of effort jumping through hoops building a vector graphics library that targets lots of platforms is because we already know that vector graphics is something we had on a single platform. It is really hard for to imagine something not being invented/created at all because there isn't a single language that can express its computation everywhere simultaneously.

echelon 5y ago

Apple doesn't want the web to be a viable alternative to the app store. They'll continue to choose strategies that hold it back.

slimsag 5y ago
It's not so clear-cut, they're pouring a lot of resources into WebGPU and Safari.
- astlouis44 5y ago
  This, they literally posted a TON of engineering WebGPU jobs just recently for their WebKit team.
pcwalton 5y ago
For what it's worth, I do not believe that this is Apple's strategy. Squabbles with Khronos suffice to explain everything.
mensetmanusman 5y ago
This is true, there is so much more that Safari could be capable of if it gave developers lower level hardware capabilities, but that would hurt the bottom line…

slimsag 5y ago

I agree with you about Web Shading Language not needing to exist. But I also don't think it's the end of the world, either. Google's Tint can translate between SPIR-V/GLSL/etc -> WGSL and vice-versa pretty well. If that's what it takes for Apple to be on board with WebGPU and we get an extension later to load SPIR-V (or some other WGSL binary form) later for optimization I'm cool with that.

pcwalton 5y ago
Yeah, the silver lining is that the amount of effort folks have gone to in order to ensure some level of interoperability has been amazing. Khronos developers working on SPIRV-Cross, wgpu-rs folks like kvark, MoltenVK people, Wine devs, etc. are unsung heroes of the graphics industry and deserve tons of support.
kvark 5y ago
Even if SPIRV input becomes available as an extension at some point, don’t expect it to be any kind of optimization. Both Tint and Naga’s IRs are close to WGSL, so parsing it is really easy and fast. Processing SPIRV’s control flow graph, images/samplers, atomics, is quite painful in comparison.
- slimsag 5y ago
  From kvark himself, big fan of your work :) Very interesting, thanks for saying this, I wouldn't have thought SPIRV->Target could be faster than or near the same speed as WGSL->Target. I guess with compression probably being quite good, as well, there isn't much point of a SPIRV extension for download times or processing times?

pjmlp 5y ago

You missed LibGNM and NVN. DirectX and Metal are great with high level bindings, and much more productive shading languages, instead of "C way" that Khronos keeps pushing for.

roblabla 5y ago
Khronos is pushing for SPIR-V, which isn't a language but a bytecode. There are a lot of good reasons to do this: It allows innovation for shading languages to take place as anyone can build their own language and compile it down to SPIR-V, and it's much easier to parse than, say, GLSL, making it easier the proprietary drivers aren't doing something stupid. The DirectX shading language (HLSL) and the metal shading language (MSL) could both compile down to SPIR-V, other than the occasional missing feature that's not standardized yet.
- kvark 5y ago
  Right, SPIRV is a good format as the destination of your shader pipeline. But it can only be that on Vulkan. With other backends, SPIRV doesn’t help, and instead stands in the way. https://kvark.github.io/spirv/2021/05/01/spirv-horrors.html https://kvark.github.io/spirv/2021/05/01/spirv-horrors.html

amelius 5y ago

> There's mostly not a reason why we couldn't have a single API other than politics. If you follow Apple's logic, this is totally wrong. Everything has to be integrated in order to achieve the best possible experience, and public APIs would be a bottleneck that make things inflexible for the company that tries to exploit the technology.

hermitdev 5y ago
I don't know, I feel like you could do a few name substitutions from this 16yr old comic [1] and it would perfectly fit this situation (of course Sony becomes Apple). [1] https://cad-comic.com/comic/doing-business/ https://cad-comic.com/comic/doing-business/
- antifa 5y ago
  The difference is that Apple actually does achieve some minimal base line of quality while Sony just pretends it does.

RantyDave 5y ago

> There's no compelling reason why Web Shading Language needs to exist. I'm pretty sure it basically doesn't. WebGPU is supporting WGSL whose #1 goal is to be "trivially convertible to SPIR-V" (https://www.w3.org/TR/WGSL/#goals https://www.w3.org/TR/WGSL/#goals). In other words, it's text SPIR-V.

kvark 5y ago
It’s only talking about one way: WGSL->SPIRV, not the reverse. It also has to be trivially convertible to MSL and HLSL. So WGSL is a separate language now, most ties to SPIRV are cut off.

vimy 5y ago

Metal isn’t just a graphics api but also becoming a CUDA alternative. It’s a very important api for Apple.

nextweek2 5y ago

> It does have the excuse that it was being developed before Vulkan This is not true, Mantle was first. AMD donated the code to khronos and it became/was developed in public. Half way through Apple announced it would do its own thing and beat Vulkan to v1.0.0. Apple might have had a v1 before Vulkan but they're still dicks for not helping build a unified standard around AMDs generous once a generation offer.