Earlier quoted context omitted.
It really should be WebSL like everything else in its space (WebGL, WebAssembly, etc.)
It's a bit weird that they talk bout WebGPU and WebGL and then name it WSL instead of WebSL.
[deleted]
WebGPU and WSL in Safari
11–20 of 186 posts
Re: WebGPU and WSL in Safari
#12I'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.
It's mentioned in the article, GPU calls (and validation) are done up front instead of in the draw loop. If the gallery is accurate though, looks like there isn't any validation right now.
Re: WebGPU and WSL in Safari
#13The 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
It really should be WebSL like everything else in its space (WebGL, WebAssembly, etc.)
It's probably following after GLSL (OpenGL Shading Language), which is admittedly an even worse name.
Re: WebGPU and WSL in Safari
#14Web 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 possibility of using a SPIR-V profile, sometimes with bad-faith arguments, despite it being the suggestion of all other vendors and the graphics community participating in the WG.
The team working on the WSL compiler had to have dominator analysis patiently explained to them, and then told us it was too complex of a concept, despite being something learned about in Compilers 101.
Re: WebGPU and WSL in Safari
#15I'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.
I just assumed that Apple exposed some API functionality in Webkit that allowed more efficient low-level usage of the GPU hardware. This leads me to believe that adoption of the WebGPU technology will probably fail to break out of the Apple ecosystem.
No, the other browser vendors are on board too. In the case of Apple, the API backend will be Metal. It'll be Vulkan or DX12 on other systems.
Re: WebGPU and WSL in Safari
#16Not 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.
Re: WebGPU and WSL in Safari
#17The 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
Web Scraping Language here. It's just a nice sounding acronym.
Re: WebGPU and WSL in Safari
#18I'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.
It seems to be structured more like Metal, DirectX 12 or Vulkan, so it's probably lower-level than WebGL, and reduces CPU load by lowering the cost of draw calls. These lower level APIs also make better use of multi core CPUs, and look at the huge performance differential between the other Macs and the likely high-core-count iMac Pro.
Their performance chart only lists Mac computers, so I assume under the hood this specific implementation is either translating WebGPU calls to Metal calls or at least the implementation is more like Metal. I suppose on other platforms, replace Metal with Vulkan or DirectX 12.
I just like reading about this stuff, I am not a graphics programmer, so I may be wildly off base.
Re: WebGPU and WSL in Safari
#19The helmet gif is breathtaking. The eliding over abstractions as an API simplification is a bit disingenuous.
gl.Foo(...)
gl.Bar(...)
gl.Baz(...)
encoder.setPipeline(pipeline)
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 archaic. This is definitely progress - it's just not really being presented directly in the article.
Re: WebGPU and WSL in Safari
#20I'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 situations (for instance different render target pixel formats). And "last minute" changes like this happen all over the place in GL and WebGL, because the GL model has so many flexible "knobs" that can be pressed at any time.
In WebGPU everything is "baked" at creation time. You may need to create more "state objects" upfront for all possible state combinations you need, and this creation may be more expensive than in the GL model, but once those state objects are created they are very efficient to use, and more importantly, they wont be "recompiled" during use.
It's a similar effect like having an unpredictable GC which can kick in at any time and produce frame spikes (like Javascript), versus not having a garbage collector at all (like WASM).
WebGPU also needs a lot fewer calls in the "hot path" compared to WebGL. When in WebGL you may need dozens of calls to change state between draw calls, in WebGPU it's only a handful.