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

31–40 of 186 posts

Re: WebGPU and WSL in Safari

#31

Post by flohofwoe »

Jasper_ wrote: post #24
flohofwoe wrote: post #20

Earlier quoted context omitted.

The performance comes mainly from a different programming model, not primarily from direct access to GPU resources (although the access is more direct than before). The potentially expensive stuff has basically been moved out of the render loop, and into the initialization phase. For instance, when you create a shader in WebGL, that shader may be patched and recompiled internally when it is used for different situati…

If you are 100% careful, you can get equal performance with a good WebGL implementation, like ANGLE, and good user code. But this is very difficult, and requires very careful programming. I built a WebGPU-like layer [0] for my 3D web application https://noclip.website , so I get some of the performance benefits today, under ANGLE, but WebGPU has these best-practices baked in, so everyone will see an increase. [0] htt…

Yes, WebGL requires some of the same tricks needed in the D3D9 era (batching and avoiding redundant state changes).

I'm quite confident that WebGPU will still provide a nice performance boost compared to carefully written WebGL, because the API is a better match to the underlying native APIs (D3D12, Vulkan and Metal), while ANGLE is basically a GLES2/3 "emulator" on top of D3D, and D3D11 is quite different from the GL programming model.

Re: WebGPU and WSL in Safari

#32

Post by monkin »

kvark wrote: post #27

The article is pretty good at explaining why WebGPU is needed for the Web. It could probably be more clear about the fact that all browser vendors are developing this API (i.e. it's not Apple's thing, and never been, if you don't count the name borrowed from their earlier prototype) and have implementations in the works. For shading languages, it's not clear to me why GLSL-to-SPIRV would be so slow. Would be great to…

> The article is pretty good at explaining why WebGPU is needed for the Web. It could probably be more clear about the fact that all browser vendors are developing this API (i.e. it's not Apple's thing, and never been, if you don't count the name borrowed from their earlier prototype) and have implementations in the works.

The first thing you read is: "WebGPU is a new API being developed by Apple and others in the W3C which enables high-performance 3D graphics and data-parallel computation on the Web."

Re: WebGPU and WSL in Safari

#33

Post by Jasper_ »

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?

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.

Re: WebGPU and WSL in Safari

#34

Post by berdon »

flohofwoe wrote: post #25
berdon wrote: post #23

Earlier quoted context omitted.

My point was the post is misleadingly saying: "These 15 lines go away and are replaced by this 1 line". That's not what's happening (unless I'm mistaken) and the code examples are comparing apples to oranges.

Well, yeah ok, the lines move from the drawFrame() function into the init() function basically. It may not be less code to type, but it's much less code to run :)

I re-read the article - and that's just not what the article implies. They make the implication that there's a reduction in "code to type".

I suppose this is just an exercise in pedantry though. I'm excited, regardless, for any API simplification.

Re: WebGPU and WSL in Safari

#35

Post by pizlonator »

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 member of the WSL team and an expert on dominator analysis.)

Re: WebGPU and WSL in Safari

#36

Post by mattmar96 »

Jasper_ wrote: post #24
flohofwoe wrote: post #20

Earlier quoted context omitted.

The performance comes mainly from a different programming model, not primarily from direct access to GPU resources (although the access is more direct than before). The potentially expensive stuff has basically been moved out of the render loop, and into the initialization phase. For instance, when you create a shader in WebGL, that shader may be patched and recompiled internally when it is used for different situati…

If you are 100% careful, you can get equal performance with a good WebGL implementation, like ANGLE, and good user code. But this is very difficult, and requires very careful programming. I built a WebGPU-like layer [0] for my 3D web application https://noclip.website , so I get some of the performance benefits today, under ANGLE, but WebGPU has these best-practices baked in, so everyone will see an increase. [0] htt…

Unbelievable performance. Bravo. You don't happen to be using WASM, do you?

Re: WebGPU and WSL in Safari

#37

Post by swypych »

monkin wrote: post #32
kvark wrote: post #27

The article is pretty good at explaining why WebGPU is needed for the Web. It could probably be more clear about the fact that all browser vendors are developing this API (i.e. it's not Apple's thing, and never been, if you don't count the name borrowed from their earlier prototype) and have implementations in the works. For shading languages, it's not clear to me why GLSL-to-SPIRV would be so slow. Would be great to…

> The article is pretty good at explaining why WebGPU is needed for the Web. It could probably be more clear about the fact that all browser vendors are developing this API (i.e. it's not Apple's thing, and never been, if you don't count the name borrowed from their earlier prototype) and have implementations in the works. The first thing you read is: "WebGPU is a new API being developed by Apple and others in the W3…

right?! short of listing all the browsers and renders out there I think they did ok.

Re: WebGPU and WSL in Safari

#38

Post by Jasper_ »

mattmar96 wrote: post #36
Jasper_ wrote: post #24

Earlier quoted context omitted.

If you are 100% careful, you can get equal performance with a good WebGL implementation, like ANGLE, and good user code. But this is very difficult, and requires very careful programming. I built a WebGPU-like layer [0] for my 3D web application https://noclip.website , so I get some of the performance benefits today, under ANGLE, but WebGPU has these best-practices baked in, so everyone will see an increase. [0] htt…

Unbelievable performance. Bravo. You don't happen to be using WASM, do you?

I use a limited version of WASM for decompression and texture decoding. Everything else is just being very careful to not create any objects in the hot path.

Re: WebGPU and WSL in Safari

#39

Post by aseipp »

The_rationalist wrote: post #26

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

It wasn't just Apple, even several Google engineers working on WebGPU agreed that simply mimicking Vulkan wasn't the right model. There are some notes here: https://docs.google.com/document/d/1-lAvR9GXaNJiqUIpm3N2XuGU...

The bit about network transparency is the most interesting one IME (which, in this case, assumes the "network" is essentially a collection of intercommunicating system processes, not nodes), as well as the bits about how Vulkan exposes too much of the vendor model to the programmer, which also isn't their goal. But it's a very sensible goal for Vulkan itself on the desktop.

If anything, the work on the gfx-rs means that WebGPU might actually end up as a more low-ish-level "portable" graphics API than Vulkan itself if you want to target every major platform + the web. In particular, gfx-hal is a non-Vulkan abstraction layer on top of D3D12/Metal/Vulkan, and webgpu-native/wgpu-rs provide WebGPU APIs for desktop platforms (in C/Rust) based on gfx-hal. Eventually you should be able to target WebGPU+WebAssembly too. I just ran a wgpu-rs demo yesterday on my mac with Metal and on my Windows desktop with DX12 with no changes! Pretty good stuff so far. And if you're a die hard Vulkan fan and don't care about WebGPU, then gfx-portability will let you program against Vulkan while building on gfx-hal, all the same, so you can still target Windows/Mac. (It would be interesting to ask how gfx-rs overcomes the problems outlined in the above design doc.)

The shading language will probably end up being the most contentious point in the end, but ultimately I think the overall tool quality/available for desktop is impressive, and WebGPU will probably end up as a good offering in the design space.

Re: WebGPU and WSL in Safari

#40

Post by Jasper_ »

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…

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 model.

re: dominator analysis, it was brought up by an Apple WebGPU developer (Myles C. Maxfield) as a complexity of parsing SPIR-V. David Neto had to explain it to Myles. https://docs.google.com/document/d/1wG9BRLUSw4FbpnvqieK--jTW...

Post reply on HN