Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WebGPU and WSL in Safari

webkit.org

Post reply on HN
Print view View original

61–70 of 186 posts

Re: WebGPU and WSL in Safari

#61

Post by pcwalton »

om2 wrote: post #59
pcwalton wrote: post #55

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…

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.

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.

Re: WebGPU and WSL in Safari

#62

Post by Jasper_ »

pizlonator wrote: post #60
Jasper_ wrote: post #40

Earlier quoted context omitted.

WSL tells you very little about how the language is actually executed. I do not see any explanation of, say, waves and quads, which will need to be spelled out explicitly when these things are added. It's a requirement for proper LOD selection for texturing, along with ddx/ddy. Simple branching in shaders is notoriously under-defined as well because of complications related to divergence/convergence and the SIMT mode…

> WSL tells you very little about how the language is actually executed. I do not see any explanation of, say, waves and quads, which will need to be spelled out explicitly when these things are added. It's a requirement for proper LOD selection for texturing, along with ddx/ddy. The spec has a semantics that describes that the language does when executed in great detail. It seems that your complaint is that there is…

> The spec has a semantics that describes that the language does when executed in great detail.

Here's what the WSL specification says about loading a texture, one of the simplest possible features of a shading language, but one that introduces a lot of complexity (again, to load a texture requires calculating an LOD, which requires talking about derivatives and scheduling pixels and shader execution in terms of quads):

> Todo: fill this section Sample, Load, Gather, etc..

That's it.

Now, your Babylon.JS demo clearly samples textures. So you have some semantics implemented, but what semantics are they? Note that these things are baked pretty heavily in hardware, so if you get the semantics wrong, you can't really fix the hardware. Your semantics have to model reality as it exists. Your automated tests can say that the spec is correct, but might break on a real GPU after translation to SPIR-V/Metal/HLSL.

The WebGPU working group does not currently have any participation from AMD or NVIDIA. Khronos and the SPIR-V working group do. I trust them to get these details right.

Fun fact: The current modelling of "discard" of as OpKill instead of OpDemoteToHelperInvocation is incorrect for Metal's "discard", which I presume is one of your backends right now.

Re: WebGPU and WSL in Safari

#63

Post by jraph »

iameli wrote: post #3

The Web Shading Language is going to have to pick a new acronym; I did a double take when I saw that Windows Subsystem for Linux was coming to Safari

When two bad names collide in funny ways, creating a "No, this cannot possibly be true" moment.

Re: WebGPU and WSL in Safari

#64

Post by banachtarski »

pizlonator wrote: post #35
Jasper_ wrote: 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…

The WSL specification is a single document that tells you how the language executed and how it ensures security. SPIR-V simply does not have this. I don’t get your argument here. It’s really funny to say that we had to have dominator analysis patiently explained to them. I don’t have a clue what you are talking about there. In one meeting I remember having to explain dominator analysis to SPIR-V folks. (I am both a m…

What I don't understand about this logic is why you don't opt to augment SPIR-V with the aspects required as opposed to branching off on an entirely different standard. I'm sure there are politics I'm not privy to, but here I am watching 48 processors pegged on compiling shaders and I really don't care to deal with another instruction set.

Re: WebGPU and WSL in Safari

#65

Post by xigency »

om2 wrote: post #53
magicalist wrote: post #30

Earlier quoted context omitted.

The wire size comparison is also weird. Are they comparing serving WSL directly (depending on a WSL compiler they went ahead and built into the Safari preview) vs GLSL plus a compiler to convert to SPIR-V because that's not built into any browser (yet)? Why would that be an interesting comparison?

Others have explained why it's relevant (this is the recommended solution for online shader generation from SPIR-V advocates.) But there's also a direct comparison of WSL vs SPIR-V wire size in he same graph, for cases where SPIR-V would be generated in advance.

It seems like there would be alternate ways to do online shader generation than concatenating strings and compiling if there were a well-formed binary standard. Maybe it is the easiest conceptually, but I don't see that as being a performance target in that case.

Edit: Also seems like they are leaning pretty heavily into Babylon.js. I don't think a standard should be developed that closely with any one specific application or framework.

Re: WebGPU and WSL in Safari

#66

Post by dman »

pcwalton wrote: post #55

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…

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.

Re: WebGPU and WSL in Safari

#68

Post by kevingadd »

om2 wrote: post #59
pcwalton wrote: post #55

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…

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.

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.

Re: WebGPU and WSL in Safari

#69

Post by mooman219 »

dman wrote: post #66
pcwalton wrote: post #55

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…

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.

This really. I'm still using OpenGL and it's worth so much to have an adequate truly cross platform graphics API. The gfx-hal people are doing good work in Rust for a cross platform vulkan like api, but it's not there yet.

Re: WebGPU and WSL in Safari

#70

Post by kevingadd »

berdon wrote: post #19

The helmet gif is breathtaking. The eliding over abstractions as an API simplification is a bit disingenuous. gl.Foo(...) gl.Bar(...) gl.Baz(...) into encoder.setPipeline(pipeline) Unless they're intuiting what needs to be done, those Far, Boo, and Baz calls are still happening somewhere. That's not to say abstraction isn't a useful way of separating out code. And OpenGL/WebGL's pipeline setup has always been a bit a…

For years if not decades, imperative OpenGL calls like the ones above have been internally building state objects and command buffers. APIs like Vulkan and WebGPU just expose the state objects and command buffers directly. Part of the issue with OpenGL is that the state is hidden behind the driver (due to how much things have changed since the APIs were specified) and you build the state with a massive number of API calls that often need to get RPC'd into a sandbox or what have you.

A carefully specified API like WebGPU that exposes state objects can allow those to be built outside the sandbox (in user content) and efficiently RPCd in a smaller set of calls.

It is realistic to say those calls go away, even if similar calls have to happen "once". In comparison, when I port native apps over to WebGL I'm invoking dozens of WebGL API calls every time I draw some tris and it's SUPER SLOW. Compared to that the cost of doing some basic setup is a rounding error.

Post reply on HN