Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

It wasn't a technical decision. Apple decided to veto the use of any Khronos IP such as SPIR-V or GLSL due to a private legal dispute which was never elaborated on. That left the committee with no choice but to reinvent the wheel, and now we're stuck with WGSL forever.

It's not the end of the world for web-only projects which can just target WGSL exclusively, but it's a pain in the ass for cross platform engines which now need to support Yet Another Shader Backend. From the old minutes:

> Eric B (Adobe): Creating a new high level language is a cardinal sin. Don’t. Do. That. Don’t want to rewrite all my shaders AGAIN.

> Jesse B (Unity): If we can transcode to HLSL to whatever you need, great. If we can’t, we may not support your platform at all.

> Eric B: Would really not like even to write another transcoder. If there’s an existing tool to get to an intermediate representation, that’s good. Would suggest SPIRV is an EXCELLENT existing intermediate representation.



From a previous thread on this topic: https://news.ycombinator.com/item?id=23089745

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


So apple's making graphics apis worse this time around :)


The 'bad' parts in WebGPU (anything related to BindGroups) are actually coming from Vulkan 1.0, while the 'good parts' are taken mostly from Metal.

WGSL vs SPIRV is really just a side issue that people want to focus on but doesn't really matter much in the bigger picture.


Modern Vulkan code doesn't even use bind groups anymore. For buffers you just push the device address as a push constant and for textures you push the index of a single large texture array


> Vulkan 1.0 Possibly even from Vulkan's Mantle days?


IIRC AMDs hardware had already adopted a fully bindless model by the time they were developing Mantle, so probably not. Vulkan 1.0 had to go backwards in terms of complexity to accommodate a wider range of hardware, with mobile causing the most pain.


As far we are aware, it goes back to how Khronos managed OpenCL after Apple gave it to the group, and also one of the reasons Metal came to be.




Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: