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

91–100 of 186 posts

Re: WebGPU and WSL in Safari

#91

Post by The_rationalist »

aseipp wrote: post #39
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…

This is not about being a Vulkan fan. Not even about portability.

The real issue is the one no one talk about. Webgpu is the intersection of features from Vulkan, directX 12 and metal. Which means that webGPU is a subset of Vulkan, metal and DX, by design it is less powerful than metal, less powerful than DX and less powerful than metal. By being an intersection, by design they've created a sub-par, non evolutive api. As a consequence, performance reachable on desktop, and expressivity of possible software and graphical features will be inferior on the web which is deeply sad

Nobody understanding and stating that is another sad thing.

Re: WebGPU and WSL in Safari

#93

Post by wffurr »

markdog12 wrote: post #75
wffurr wrote: post #58

In the meantime, they never added support for WebGL2 and MSAA on Framebuffer Objects. Blargh.

https://twitter.com/gfxprogrammer/status/1171553288681996288 "We're collaborating with Dean and the WebKit team to use ANGLE for WebGL's backend in WebKit, which will allow an easy upgrade to WebGL 2.0 on all platforms. Follow https://bugs.webkit.org/show_bug.cgi?id=198948 for updates on the work."

That's great news! Thank you!

Re: WebGPU and WSL in Safari

#94

Post by om2 »

xigency wrote: post #84
om2 wrote: 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 strangely hasn’t been seriously considered but it might not be a bad option (though it may need a more rigorous reformilation of the spec).

Re: WebGPU and WSL in Safari

#95

Post by om2 »

xigency wrote: post #65
om2 wrote: post #53

Earlier quoted context omitted.

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 appli…

Our collaboration with Babylon.js happened after most of the spec proposal work. It was inspired by Google’s similar collaboration with Babylon.js prompting Google’s own SPIR-V based implementation of WebGL. This makes the comparison more apples-to-apples.

WebGPU itself is guided by input from many framework and engine developers.

Re: WebGPU and WSL in Safari

#97

Post by grovesNL »

om2 wrote: post #79
Jasper_ wrote: post #72

Earlier quoted context omitted.

Google has a well-defined SPIR-V execution environment they have been championing: https://github.com/gpuweb/spirv-execution-env/blob/master/ex...

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.

Re: WebGPU and WSL in Safari

#98

Post by TazeTSchnitzel »

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…

> A bigger question though that needs to be resolved is how to specialize SPIR-V shaders.

Is the OpSpecConstant family not enough? Those exist specifically for specialisation.

Re: WebGPU and WSL in Safari

#99

Post by TazeTSchnitzel »

mehmetoguzderin wrote: post #81

The course of development with WebGPU initiative is breathtaking. The effort poured into the API is producing content that will be consumed by people that desire to study GPGPU applications. Included in the final specification or not, a well-tailored shading language is only of benefit to the GPGPU community, similar to how simultaneous existence of DirectX, Metal, Vulkan has been to the robustness of the abstraction…

We already have the ultimate shading language: SPIR-V.

Re: WebGPU and WSL in Safari

#100

Post by devwastaken »

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…

That sounds more like implimentation details of how opengl is used, rather than something 'different' from webgl. Wouldn't it be possible to just modify the webgl implimentation or flavor it for the performance seen here?
Post reply on HN