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

21–30 of 186 posts

Re: WebGPU and WSL in Safari

#21

Post by flohofwoe »

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…

...it's the exact same difference like GL to modern 3D-APIs (like Metal, Vulkan or D3D12, or even D3D11). The cost for those Foo, Bar and Baz calls is paid once during the creation of the pipeline object which usually happens at the start of the application.

Making that pipeline object active during rendering is very cheap (about as cheap as one of those gl.Foo() calls).

Re: WebGPU and WSL in Safari

#22

Post by Jasper_ »

Klathmon wrote: post #16
a13n wrote: post #8

Not really interesting until Chrome adopts it

Chrome is adopting it! They've signaled "intent to implement", and have started work on it in chrome for mac. https://github.com/gpuweb/gpuweb/wiki/Implementation-Status

Note that Chrome has not signaled adoption for WSL (formerly WHLSL), instead preferring to use a profile of SPIR-V. They also put out a demo with the Babylon.js team for this as well.

https://medium.com/@babylonjs/webgpu-is-coming-to-babylon-js...

Re: WebGPU and WSL in Safari

#23

Post by berdon »

flohofwoe wrote: post #21
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…

...it's the exact same difference like GL to modern 3D-APIs (like Metal, Vulkan or D3D12, or even D3D11). The cost for those Foo, Bar and Baz calls is paid once during the creation of the pipeline object which usually happens at the start of the application. Making that pipeline object active during rendering is very cheap (about as cheap as one of those gl.Foo() calls).

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.

Re: WebGPU and WSL in Safari

#24

Post by Jasper_ »

flohofwoe wrote: post #20
devwastaken wrote: post #7

I'm unsure how they're getting better performance. Webgl is using opengl in a sort of sandboxed manner, does this webgpu approach bypass some checks or find different performant ways to do them? Afaik the biggest problem with gpu access from browsers is that the you instructions are not at all hardware secure. So everything has to be managed.

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] https://github.com/magcius/noclip.website/blob/master/src/gf...

Re: WebGPU and WSL in Safari

#25

Post by flohofwoe »

berdon wrote: post #23
flohofwoe wrote: post #21

Earlier quoted context omitted.

...it's the exact same difference like GL to modern 3D-APIs (like Metal, Vulkan or D3D12, or even D3D11). The cost for those Foo, Bar and Baz calls is paid once during the creation of the pipeline object which usually happens at the start of the application. Making that pipeline object active during rendering is very cheap (about as cheap as one of those gl.Foo() calls).

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 :)

Re: WebGPU and WSL in Safari

#27

Post by kvark »

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 hear back from Google. Side note: we are currently experimenting [1] with Rust-based SPIR-V generation, and the transformation is looking to be mostly trivial - there is no reason it should be slow.

A bigger question though that needs to be resolved is how to specialize SPIR-V shaders. Without this, there is no good alternative to text-based cut-and-paste that the blog argues to be the best approach.

[1] https://github.com/jrmuizel/glsl-to-spirv

Re: WebGPU and WSL in Safari

#28

Post by Rusky »

berdon wrote: post #23
flohofwoe wrote: post #21

Earlier quoted context omitted.

...it's the exact same difference like GL to modern 3D-APIs (like Metal, Vulkan or D3D12, or even D3D11). The cost for those Foo, Bar and Baz calls is paid once during the creation of the pipeline object which usually happens at the start of the application. Making that pipeline object active during rendering is very cheap (about as cheap as one of those gl.Foo() calls).

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.

Misleading if the point were that the API got smaller or easier, maybe.

But the point is instead that the amount of work done in the main render loop is smaller. Those 15 lines do go away in that sense- they only happen once on startup under the new API.

Re: WebGPU and WSL in Safari

#30

Post by magicalist »

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?
Post reply on HN