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

41–50 of 186 posts

Re: WebGPU and WSL in Safari

#41

Post by magicalist »

Jasper_ wrote: post #33
magicalist wrote: post #30

Earlier quoted context omitted.

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.

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.

Re: WebGPU and WSL in Safari

#42

Post by banachtarski »

I trust nothing from Apple when it comes to graphics. My years of pain as a graphics engineer trying to support their hardware and get good performance has created this deepseated mistrust, especially given their track record of abandoning open source standards, including the ones they started! (I'm looking at you, OpenCL).

Re: WebGPU and WSL in Safari

#43

Post by pixelhorse »

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/WebGL you would've gotten 95% of the performance benefit without adapting a whole new rendering API (and shading language). Unfortunately, AMD could never get a proper OpenGL driver going so they pushed for Mantle which ultimately turned into Vulkan.

Re: WebGPU and WSL in Safari

#44

Post by jacobolus »

berdon wrote: post #34
flohofwoe wrote: post #25

Earlier quoted context omitted.

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.

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 the pipeline is created, outside of the core rendering loop. As a result, we can avoid performing expensive state analysis inside the draw call. Also, setting an entire pipeline state is a single function call, reducing the amount of “chatting” between Javascript and WebKit’s C++ browser engine.

> Resources have a similar story. Most rendering algorithms require a set of resources in order to draw a particular material. In WebGL, each resource would be bound one-by-one. However, in WebGPU, resources are batched up into “bind groups”. [... In both APIs] multiple objects are gathered up together and baked into a hardware-dependent format, which is when the browser performs validation. Being able to separate object validation from object use means the application author has more control over when expensive operations occur in the lifecycle of their application.

The clear point in both of these comparisons is that the same operations must be done in both APIs, but the WebGPU version allows much of the work to be pre-computed, allowing the draw calls (where the performance bottleneck lies) to have as little overhead as possible.

Re: WebGPU and WSL in Safari

#45

Post by billconan »

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…

by "network", what they really mean is interprocess communication, right?

Re: WebGPU and WSL in Safari

#46

Post by berdon »

berdon wrote: post #34
flohofwoe wrote: post #25

Earlier quoted context omitted.

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.

And clear and unambiguous to me:

  gl.UseProgram(program1);
  gl.frontFace(gl.CW);
  gl.cullFace(gl.FRONT);
  gl.blendEquationSeparate(gl.FUNC_ADD, gl.FUNC_MIN);
  gl.blendFuncSeparate(gl.SRC_COLOR, gl.ZERO, gl.SRC_ALPHA, gl.ZERO);
  gl.colorMask(true, false, true, true);
  gl.depthMask(true);
  gl.stencilMask(1);
  gl.depthFunc(gl.GREATER);
  gl.drawArrays(gl.TRIANGLES, 0, count);
>>> On the other hand, rendering a single object in WebGPU might look like:

  encoder.setPipeline(renderPipeline);
  encoder.draw(count, 1, 0, 0);

Re: WebGPU and WSL in Safari

#47

Post by dekimir »

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…

> it's not clear to me why GLSL-to-SPIRV would be so slow. Would be great to hear back from Google.

Off the top of my head:

- glslang supports all previous GLSL versions and profiles, which adds many checks and corner cases throughout the code

- it's tricky to generate correct SPIR-V; for instance, it took me a while to properly understand the constraints around basic-block ordering

Disclaimer: I left Google in 2016 and haven't looked at glslang/shaderc since. I am only offering personal opinions here.

Re: WebGPU and WSL in Safari

#48

Post by kvark »

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.

well, one of the points to go with SPIR-V is to not standardize higher level languages that translate into it

Re: WebGPU and WSL in Safari

#49

Post by berdon »

jacobolus wrote: post #44
berdon wrote: post #34

Earlier quoted context omitted.

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.

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.

Post reply on HN