Hacker News Reader

Comment by om2 | Hacker News Reader

The only thing that already exists that is provably web-safe is the WebGL dialect of GLSL (which no one seems to like). WebSPIR-V would be based on SPIR-V but in many ways has to be a new thing as well.

Edit: I originally said "WebGPU dialect of GLSL" which is not a thing. I meant "WebGL dialect of GLSL", which is a thing and which works ok in practice.

View on HN

I don't see any way in which it won't be way more work to migrate to this proposed WSL than to get my existing SPIR-V tooling working with Web SPIR-V.

The actual functionality exposed is close enough that cross-compiling is a solvable problem. But fair point.

(On the flip side, having two syntactically very similar but actually different things can be dangerous, as it may lead devs to think some tooling works when it actually doesn't.)

Are there any technical obstacles to using GLSL with WebGPU? It's popular with some people.

See: https://www.shadertoy.com/

It strangely hasn’t been seriously considered but it might not be a bad option (though it may need a more rigorous reformilation of the spec).

It might be that browser vendors would be better at writing compilers than GPU vendors, but there were a lot of bugs in GLSL compilers. SPIR-V was introduced to be a simpler format for GPUs to ingest, letting you do the complex parsing up front on your machine (where it's easier to identify and fix problems).

The other benefit was that changes could be made to improve the usability of the shading language without having to wait on all vendors to update their compilers. If the change was just syntactic sugar, it could be made without changing the SPIR-V. It's kind of like how you don't need an operating system update to move from C++98 to C++11.

Browser vendors are a lot better at writing compilers than GPU vendors. Also there are fewer different browser engines than different GPU drivers so that also helps.

Hilariously, Apple actually considers the shift from C++98 to C++11 something that required an operating system upgrade (they purposefully shipped an ancient version of libstdc++ while disingenuously doing comparisons against only what they shipped, not what had come from upstream, for as long as they could until libc++ was reasonable, which debuted on macOS 10.7--where I will note it was horribly broken due to an LLVM optimizer bug in the specific clang build they used to compile it, so really it wasn't available until macOS 10.8--and as Apple does not believe in static linking, their SDK doesn't have a way to work around this; of course, you can, and I did--by getting the code for libc++, modifying it to use an underlying libstdc++ as the moral equivalent of libc++abi, and statically linking that, which worked great and is frankly what Apple should have done themselves during the transition period :/--it is notable that Apple didn't want people to: they really do mentally model that as an operating system upgrade, which to me is an amazing demonstration of how little they understand of the power and potential of decoupled toolchains).

> Apple does not believe in static linking, their SDK doesn't have a way to work around this

Apple isn’t alone this regard; as far as I can tell Windows does this too because they don’t commit to a stable syscall interface like Linux does. That being said, you may find Apple’s official stance on statically linking your binaries amusing: https://developer.apple.com/library/archive/qa/qa1118/_index...

In general, Apple links a lot of things to their OS releases: while their toolchains are distributed separately they’re practically tied to one or two major OSes unless you engage in hacks to make them continue working. And the languages which they exercise significant control over (namely Swift and Objective-C) are often tied to OS versions.

You can always just cross compile your SPIR-V to GLSL or something. People have been cross compiling between HLSL and GLSL for ages, it's a solved problem even if there are sharp edges.

There is no WebGPU dialect of GLSL, only a SPIR-V execution environment for WebGPU. Lnaguages in themselves aren't "safe" or "unsafe", their implementations are.

Also please stop trying to influence a technical debate in a standardization group by putting blog posts on top of Hacker News.

You're absolutely wrong here. A language must specify its semantics. Those semantics describe the safety properties of that language.

Sorry, I meant WebGL, simply mistyped.

As far as posting blog posts, we think this is just as fair as the Chrome team's communication about their own WebGPU implementation, which included a public demo and sessions at Google I/O which were widely reported.

As for the post getting upvoted to the top of Hacker News, that's the community's choice, not ours. The initial poster wasn't even an Apple person (afaik). If you are insinuating some kind of vote manipulation then that is inaccurate.

Reply on news.ycombinator.com