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

51–60 of 186 posts

Re: WebGPU and WSL in Safari

#51

Post by kvark »

pixelhorse wrote: post #43
The_rationalist wrote: post #26

Such a shame that webGPU is not Vulkan based... Thanks Apple.

Yes, thanks Apple. Vulkan is rather awful to use, compared to D3D12 and especially compared to Metal. Metal, in my opinion, strikes the best balance between performance and low-level control. With Vulkan the intention is that you have multiple codepaths for every vendor for good performance. This is way too much effort for an API that is already of little relevance. I think that with AZDO-style extensions to OpenGL/W…

Metal also is quite different between mobile and desktop, so it's not solving this portability issue completely. It has the benefit of standardizing more of the limits/capabilities in the feature tables as a part of the "spec". This is much better than querying everything about the physical device at run/init time and making decisions from there.

Where Metal is really different, in a good way, is that it has progressive complexity. You can use the basic commands and get pretty far, allowing the driver to manage lifetimes for you and not caring about multi-threading too hard. But then there are ways to get more control, gradually, which you can opt into later. This is very different from Vulkan's all-or-nothing approach.

For the Web, it seems to me that having the same property would work best.

Re: WebGPU and WSL in Safari

#52

Post by [deleted] »

berdon wrote: post #49
jacobolus wrote: post #44

Earlier quoted context omitted.

This seems pretty clear and unambiguous to me > Most 3D applications render more than a single object. In WebGL, each of those objects requires a collection of state-changing calls before that object could be rendered. [...] All the pieces of state in the WebGL example are wrapped up into a single object in WebGPU, named a “pipeline state object.” Though validating state is expensive, with WebGPU it is done once when…

That's neither clear nor unambiguous. The text I highlighted including their summary of it states there is a reduction of code. Not only that, the "both APIs" part you're mentioning isn't even pertaining to the code but rather the execution of the pipeline. My point is, and has been, that they should focus on the perf gains and reduce the misleading sentiment that it has simplified the API footprint.

[deleted]

Re: WebGPU and WSL in Safari

#53

Post by om2 »

magicalist wrote: post #30
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 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.

Re: WebGPU and WSL in Safari

#54

Post by om2 »

magicalist wrote: post #41
Jasper_ wrote: post #33

Earlier quoted context omitted.

GLSL+glslang+SPIR-V was one of the suggested approaches for developers that want to compile GLSL at runtime on the web. Google has been working on getting a minimal form of glslang out the door, but they're having trouble because glslang is a pretty big beast.

But presumably if that was the eventually standardized format the compiler could ship with browsers, though, right? It just seems weird to compare against another format that hasn't been agreed to either but they shipped the compiler with the browser preview so people can test it. It should either be comparing sources or comparing (source + compiler to get it working in a shipping stable browser), not mixing the two.

The proposal from SPIR-V advocates is to not ship any high level language compiler with the browser. That could change, but currently no one is excited about accepting both a binary language and a text-based language.

Re: WebGPU and WSL in Safari

#55

Post by pcwalton »

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 players constantly use new and incompatible graphics APIs to try to obtain some sort of competitive advantage, adding to the workload we developers have to deal with. There is almost no cost to the platform developers to add new APIs; instead, the costs are borne by the application developers. It's a classic case of negative externalities.

Re: WebGPU and WSL in Safari

#56

Post by om2 »

Jasper_ wrote: post #40
pizlonator wrote: post #35

Earlier quoted context omitted.

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…

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…

I was there for one of the times that Phil (from Apple) explained dominator analysis and why it's an added complexity of a binary language. Phil is the architect of our JS VM and one of the main designers of WSL so I think he knows!

Your claim that the WSL spec tells you very little seems off to me. The spec includes formal semantics for everything. If some things aren't in the spec yet they can be added. There is also a pretty extensive test suite. To me the level of specification rigor is considerably higher than SPIR-V, which has an informal spec with separate documents for adding web safety.

Re: WebGPU and WSL in Safari

#57

Post by om2 »

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…

You may not like it but it's pretty clear that WSL is at least a starter. It has a spec, a test suite, and an implementation (which fully implements safety). And the implementation is pretty fast, and should at least dispel WSL vs SPIR-V performance concerns.

This is arguably ahead of the proposed web dialect of SPIR-V (which needs to subset the language, add validation steps, and insert safety checks).

Re: WebGPU and WSL in Safari

#59

Post by om2 »

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.

Re: WebGPU and WSL in Safari

#60

Post by pizlonator »

Jasper_ wrote: post #40
pizlonator wrote: post #35

Earlier quoted context omitted.

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…

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 some thing that you think that SPIR-V describes better than WSL - waves and quads in this case.

I was there when we brought up dominators. You are right that we brought it up as a complexity of SPIR-V, but not because we didn't know what dominators are. We do know what they are, and because we do know, we know that it's complex. We're not saying "it's so complex that we don't understand it". We are saying "we understand it and we know it's complex". In particular, an early argument against text-based languages is that you have to specify and then validate variable scoping. Dominator analysis is a variable scoping rule, just a very complicated one for a wire format to have.

Post reply on HN