Hacker News Reader

Comment by ericflo | Hacker News Reader

It's driven by Apple hating Khronos, so we all have to come up with a new, non-Khronos thing if it's to be used in browsers made by Apple.

View on HN

Apple should stop messing things up and should support SPIR-V, sure.

But to generate SPIR-V you still need a high level language. So is this useful for it?

Lots of languages _already_ compile to SPIR-V - GLSL and HLSL for a start. Why add _another_ syntax?

I suppose current options aren't optimal. Or at least that could be a valid motivation to create one.

If the motivation is to replace SPIR-V itself, then it's not valid.

Except it wasn't designed to be an "optimal target for SPIR-V" -- it was designed by Apple according to Metal's semantics, to promote Metal over Vulkan, and had to be rejiggered. It's worse, by your standard, than existing, battle-proven GLSL/HLSL toolchains.

This is not correct. The WGSL is renamed from Tint, which is a Google's proposal for a shading language, in agreement with all parties.

They're on record that their motive is disputes with Khronos, it's in some past meeting notes.

Then this should be rejected.

reject it and there will be no WebGPU for 1.5 billion iOS devices just like there is no WebGL2 for 1.5 billion iOS devices.

Why should Apple dictate their approach to everyone else then? If they are so resolved to remain outsiders technology wise because they are crazy bent on NIH, let them be outsiders.

I'd say everyone else should take a hard stance on this and show Apple to the door, instead of dancing under their tune.

It's called a "standards process" for a reason. Even if you personally have a different opinion the point of a standard is to get everyone implementing it on-board with that standard.

Releasing a standard that a major member opposes and won't implement is a pointless exercise.

So if there won't be any consensus, then what? I see no reason to oblige Apple in this case then.

When Apple adopts some technology, they don't care whether others can do the same, or what problems that will cause to others.

They might use the same medicine.

The motivation is to salvage SPIR-V in a way that makes Apple happy.

Apple and Microsoft investigated the possibility of specifying WebHLSL tightly. The main concern was that it's a ton of work in terms of semantics.

At the same time, SPIR-V semantics is fairly well specified, so we as a group figured that the familiar syntax of HLSL is not as important as the proper GPU behavior and our time specifying it. We've yet to see if it was the right decision - we might as well get stuck with discussing the syntax :)

From a technical standpoint a subset of SPIR-V that is safe to use in web browsers is exactly what is needed. However, there are IP problems that prevent direct usage of SPIR-V. [0] In short W3C needs full ownership of the spec so that it can be completely independent from Khronos. A textual representation of SPIR-V basically sidesteps these problems while still maintaining the ability to have a trivial SPIRV -> WSGL and WSGL -> SPIRV compiler.

[0] https://news.ycombinator.com/item?id=22539633

They refused to explain what IP problems there are, and given it's Apple, I doubt they are valid.

It's not driven by Apple, please double check your sources.

It absolutely is driven by Apple. I've been following this for a while. I actually like having a text based shader format since I do a lot of dynamic shader generation and compilation at runtime, but I don't quite understand why it has to be something entirely different to existing shader languages.

Err, WGSL is essentially renamed from Tint, which was developed and proposed by Google. Where do you see Apple the driver?

Apple refused to support SPIRV, which Chrome (and Firefox?) already implemented, and lobbied for a text based language. Please read the minutes, I'm not going to look it up for you.

I was in the minutes. Just because it's text doesn't mean it's driven by Apple.

Apple clearly says it's not an option because of a legal dispute. If everyone else is at the negotiating table, but Apple says absolutely NO, how is that decision not driven by Apple?

Apple vetoes SPIR-V binary as an option. Google develops a language based on SPIR-V semantics that we agree on. It's clear that at least today, Google is mainly driving WGSL. They also see the value in WGSL outside of WebGPU context. Claiming the Apple primary role in this is ridiculous.

So how is it supposed to work in practice? Pages will ship SPIR-V and will be converted to WGSL just for Apple on the fly, or pages will ship WGSL, and it will be converted to SPIR-V on the fly for everyone else?

I surely hope not the later, let Apple pay performance price for being the root of the problem.

Many Web applications will just ship WGSL. This includes everything going through Three.js, Babylon.js, and hand-written web apps.

It's not even clear if Chrome or Firefox will accept SPIR-V binary as an extension at this point.

Anyway, conversion to and from SPIR-V is supposed to be straightforward and light. Our (speaking for gfx-rs community) Rust-based shader infrastructure will handle that , and the converter should be easily compilable to wasm (when it's ready).

Anyway x2, most of the time in the whole picture of creating pipelines will be spent in the driver, so whatever parsing performance difference WGSL brings to the table, be it 5% or 10%, doesn't matter, you aren't going to see that in benchmarks because of that other stuff that's going on when you are creating a pipeline.

It would still be good for Firefox and Chrome to accept SPIR-V bytecode (in addition to WGSL). This way you can write some client side library, that converts SPIR-V on the fly to WGSL for crippled browsers (Apple) and use SPIR-V directly for everyone else.

I hope Mozilla and Google won't cave that way to this Apple's idiotic behavior.

I don't think there will be a significant performance problem because the generated machine code can be cached.

> Claiming the Apple primary role in this is ridiculous.

It's apple that didn't want SPIRV and insisted on something else, preferably text based. Doesn't matter who is doing that something else now, it's done because of Apple... Which I'm not entirely a fan of because I don't think apple's history in WebGL, OpenGL and graphics makes them deserve the leverage they're getting.

That seems a bit harsh. Isn't WebGPU to WebGL what Vulkan is OpenGL? It's the next generation of more efficient 3D rendering pipeline.

Vulkan itself supports both GLSL and HLSL (and any other shading language that can compile to SPIR-V), so you'd still usually end up writing GLSL anyway.

Yes, but if you follow the discussions, the clear consensus was to use SPIR-V. Except Apple, who came up with all kinds of technical reasons not to use it, before eventually admitting they have a legal dispute with Khronos group. Now we get this weird language that is SPIR-V in text form but not by Khronos, and suddenly there is consensus.

> before eventually admitting they have a legal dispute with Khronos group.

Interesting, that's the first time I hear about it. Do you have some links on the topic? What is the essence of the dispute?

From the meeting notes [1]:

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

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

Weird, but at least it explains why they are causing a problem.

Apparently it goes back to how Apple wanted to evolve OpenCL after releasing it to Khronos.

Reply on news.ycombinator.com