Hacker News Reader

Comment by greggman3 | Hacker News Reader

There's no Vulkan on MacOS/iOS (though there may be some 3rd party library that will translate to Metal).

While true this boils down to "Apple won't support anything it doesn't have control over", as demonstrated by them using veto power to pick WebGPU's shader language (a custom one) instead of using the shader IR literally everyone else wanted. It doesn't make a ton of sense to evaluate the success of APIs and standards this way because Apple has a long track record of refusing to implement stuff or deprecating it once they had an interest in promoting a proprietary alternative.

That paints Apple in a wrong light. They agreed on the WebGPU Shading Language proposed by Google (!) (previously called "Tint"). This is something Google is interested in, as well.

It's literally in past WebGPU meeting minutes: Apple objected to SPIR-V due to disputes with Khronos. Tint is a compromise, it doesn't matter who proposed it.

"MS: Apple is not comfortable working under Khronos IP framework, because of dispute between Apple Legal & Khronos which is private. Can’t talk about the substance of this dispute. Can’t make any statement for Apple to agree to Khronos IP framework. So we’re discussing, what if we don’t fork? We can’t say whether we’re (Apple) happy with that. NT: nobody is forced to come into Khronos’ IP framework."

https://docs.google.com/document/d/1F6ns6I3zs-2JL_dT9hOkX_25...

I know, I was there. I also think that objection to SPIR-V wasn't completely unfounded. SPIR-V is a nice binary representation of shaders, but it has problems in the context of WebGPU adoption:

1. It's so low level that generating HLSL and MSL from it is more painful than it could be. For example, it represents branching in the form of a Control Flow Graph (which is typical for an IR). This is lower level than either a source language people would use (e.g. GLSL), or the destination backend language we need to produce (e.g. HLSL or MSL). This is unnecessary complexity for translation.

2. It has a lot of instructions, covering wide range of hardware (somewhat similar to Vulkan). In contrast, for WebGPU it would make sense to have fewer instructions for the ease of securing it and translating to other representations.

3. Friction in the features we need, vs features Khronos needs.

There is also a situation where there is no single well specified and tested textual shading language. HLSL doesn't have a spec. MSL has documentation, but not enough for a spec, and it's not portable. GLSL kinda has a few specs, but realistically it's just specified by the implementation of glslValidator.

I think this is actually something that might be deserving of a blog post itself, if you had the time.

There’s a lot of opinions from people outside the working group for WGSL as to why it exists.

I think most of the PR damage right now comes from those people not having enough context and thus framing it in a negative light.

A blog post with more context and information would probably help imho

Apple created Metal waaay before Vulkan existed and moved their whole ecosystem to it before Vulkan was production ready.

While moving from OpenGL to Metal was a significant technical upgrade for them, moving all their ecosystem from Metal to Vulkan is just a lot of work for very little benefit.

But yeah, sure, maybe they are just sticking with Metal to mess around with people.

MoltenVK is the most prominent Vulkan to Metal translation library. Technically, it's a 1st party library, since it's the core of the Khronos Group's Vulkan SDK on mac/iOS.

https://github.com/KhronosGroup/MoltenVK

It's not 1st party. Up to the very recent, the whole SDK was a "LunarG SDK" for a reason - it wasn't 1st party either. It's basically just somebody packing up a bunch of useful libraries together.

This is my main pain point on how Khronos deals with their APIs.

Naturally for those of us around since the ARB days it hardly matters, but for teaching beginners into 3D world, or nowadays 2D was well, those bunch of useful libraries still lack the tooling experience of proprietary APIs.

And the OEM SDKs are hardly better, because they also provide better tooling for the proprietary APIs.

So in the end it all turns out into a rite of passage for everyone, getting to know which set of useful libraries, useful GPU debugging tools are to be used.

Hence why I just advise most beginners to start with middleware and only afterwards dive into the low level details.

Hopefully WebGPU can also help there.

Reply on news.ycombinator.com