Live data from Hacker News

WebGPU and WSL in Safari

webkit.org

101–110 of 186 posts

Re: WebGPU and WSL in Safari

#101
post #90

As a cross-platform graphics developer who is currently knee-deep in papering over platform incompatibilities, what I mostly care about at this point is compatibility . I don't care about shader size or compilation time, as long as both are reasonable. I do care about having yet another shading language to cross-compile to. Please, everyone, just use something that already exists. It is frustrating how the big player…

> Please, everyone, just use something that already exists. Says one "who is currently knee-deep in papering over platform incompatibilities", instead of using one of the solutions that do it for you.

I wasn't referring to pathfinder_gpu. :)

(I didn't downvote you.)

Re: WebGPU and WSL in Safari

#102
post #87
post #66

Earlier quoted context omitted.

I miss the years where inspite of all its flaws, OpenGL was a non deprecated option on all the platforms. I know it left performance on the table, I know the drivers for some vendors were iffy and I know reasoning about performance across different vendors / drivers / platforms was difficult - but it worked most of the time and allowed me to have a mostly unified codebase everywhere.

Only when "all platforms" leaves out game consoles, which never had full support for OpenGL, besides a timid attempt with GL ES 1.0 + Cg on PS2.

It's true, but for most applications, games consoles are not even a consideration. There's a mountain of programs that only target Windows, Linux, macOS, Android, and iOS or some subset thereof.

Re: WebGPU and WSL in Safari

#103

As a cross-platform graphics developer who is currently knee-deep in papering over platform incompatibilities, what I mostly care about at this point is compatibility . I don't care about shader size or compilation time, as long as both are reasonable. I do care about having yet another shading language to cross-compile to. Please, everyone, just use something that already exists. It is frustrating how the big player…

> There is almost no cost to the platform developers to add new APIs

To anyone who has ever spent time working on a platform API this is deeply insulting.

> …the costs are borne by the application developers.

Yes, whereas with cross-platform, least common denominator APIs the cost is borne by end users.

This is literally the attitude that lead to Java applets and then Flash, then later mistakes like Web SQL and (P)NaCL.

Re: WebGPU and WSL in Safari

#104
post #103

As a cross-platform graphics developer who is currently knee-deep in papering over platform incompatibilities, what I mostly care about at this point is compatibility . I don't care about shader size or compilation time, as long as both are reasonable. I do care about having yet another shading language to cross-compile to. Please, everyone, just use something that already exists. It is frustrating how the big player…

> There is almost no cost to the platform developers to add new APIs To anyone who has ever spent time working on a platform API this is deeply insulting. > …the costs are borne by the application developers. Yes, whereas with cross-platform, least common denominator APIs the cost is borne by end users. This is literally the attitude that lead to Java applets and then Flash, then later mistakes like Web SQL and (P)Na…

> To anyone who has ever spent time working on a platform API this is deeply insulting.

I've worked on platform APIs too. Maybe "almost no cost" wasn't the right phrase, but there's certainly less cost for the platform vendor.

> Yes, whereas with cross-platform, least common denominator APIs the cost is borne by end users.

It's a tradeoff that has to be evaluated on a case-by-case basis. So far I haven't seen arguments for WSL that are compelling enough.

Re: WebGPU and WSL in Safari

#105
post #84
post #59

Earlier quoted context omitted.

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.

Are there any technical obstacles to using GLSL with WebGPU? It's popular with some people. See: https://www.shadertoy.com/

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.

Re: WebGPU and WSL in Safari

#106
post #79

Earlier quoted context omitted.

Is there a test suite?

I don't see why it should be relevant at this point, although there are several large test suites (including fuzzers) for common libraries in the SPIR-V ecosystem. Shader language tests should be added to the WebGPU conformance test suite regardless of the language.

But no tests for the web safety layer afaik.

Re: WebGPU and WSL in Safari

#107

As a cross-platform graphics developer who is currently knee-deep in papering over platform incompatibilities, what I mostly care about at this point is compatibility . I don't care about shader size or compilation time, as long as both are reasonable. I do care about having yet another shading language to cross-compile to. Please, everyone, just use something that already exists. It is frustrating how the big player…

What are you working on? I have no experience in graphics development, only a cursory familiarity with some concepts, but can I help? Typical Frontend has kind of become boring now that everything is abstracted and the harder stuff mostly resides in graphics or on the edge. Just haven't really found a way to make that change yet.

Re: WebGPU and WSL in Safari

#108
post #103

As a cross-platform graphics developer who is currently knee-deep in papering over platform incompatibilities, what I mostly care about at this point is compatibility . I don't care about shader size or compilation time, as long as both are reasonable. I do care about having yet another shading language to cross-compile to. Please, everyone, just use something that already exists. It is frustrating how the big player…

> There is almost no cost to the platform developers to add new APIs To anyone who has ever spent time working on a platform API this is deeply insulting. > …the costs are borne by the application developers. Yes, whereas with cross-platform, least common denominator APIs the cost is borne by end users. This is literally the attitude that lead to Java applets and then Flash, then later mistakes like Web SQL and (P)Na…

They have to implement the existing API or their own. The cost will be the same for both cases. For big platform vendors, almost no(extra) cost.

On the other hand, we, the ordinary developer must pay the cost of supporting N APIs on M platforms. Every APIs carelessly invented by vendors just because almost no extra cost burden us all.

Re: WebGPU and WSL in Safari

#109
post #106

Earlier quoted context omitted.

I don't see why it should be relevant at this point, although there are several large test suites (including fuzzers) for common libraries in the SPIR-V ecosystem. Shader language tests should be added to the WebGPU conformance test suite regardless of the language.

But no tests for the web safety layer afaik.

I think we should focus more on the advantages and disadvantages of WSL and SPIR-V, and their relevance to existing or future ecosystems -- not debate over which language had the first web tests.

Re: WebGPU and WSL in Safari

#110
post #14

Web Shading Language is a non-starter. I looked quite closely at the specification. Apple has argued in the WebGPU WG that SPIR-V is not defined enough, semantically, to be meaningful, but WSL is even worse. Sometimes, it's even explained in terms of SPIR-V, like in the case of discard, where it was hastily explained in terms of SPIR-V's OpKill after we identified it was completely missing. Apple has blocked any poss…

If we can compile GLSL, GLSL ES, HLSL and OpenCL C to SPIR-V, and we can use SPIR-V in OpenGL, Vulkan and OpenCL, then why on earth can't WebGPU just use SPIR-V? If it's not safe enough, then define a safe subset or safety extensions with strict validation. If it's not Appley enough, then write a Metal Shading Language to SPIR-V compiler (the reverse has already been done). Hell, if SPIR-V really is too low-level, GL…

Because Apple hates Khronos
Post reply on HN