Live data from Hacker News

Chrome ships WebGPU

developer.chrome.com

101–110 of 405 posts

Re: Chrome ships WebGPU

#101

Is it practical to run machine learning algorithms in parallel with this? I could imagine people loading a webpage to take part in a massive open source training exercise by donating their Gpu time.

Looks like no -- there appears to be no tensor core or similar support and this SGEMM (fp32 matrix multiply) benchmark gets awful results (my laptop gets 330 gflops on this when it should be capable of 13000 gflops fp32 and probably 100000 gflops fp16).

https://github.com/milhidaka/webgpu-blas

Re: Chrome ships WebGPU

#102
post #69

Earlier quoted context omitted.

No SPIR-V was the cost of getting Apple on board.

Getting Apple on board? Wasn't Apple the originators of the propsal? https://webkit.org/blog/7380/next-generation-3d-graphics-on-... https://webkit.org/wp-content/uploads/webgpu-api-proposal.ht...

Apple has a Khronos allergy, and both SPIRV and GLSL are Khronos standards.

Also the original 3D API proposal from Apple was essentially a 1:1 Javascript shim for Metal, which looked quite different from WebGPU.

Apple also originally proposed a custom shading language which looked like - but wasn't quite - HLSL. Compared to that, WGSL is the saner solution (because translation from and to SPIRV is relatively straightforward).

Re: Chrome ships WebGPU

#103
post #65
post #62

Earlier quoted context omitted.

It's possible to have the runtime execute the computations in fixed time across platforms.

Could you explain what techniques would make this possible? I can see how it's possible in principle, if you, say, compile JS down to bytecode and then have the interpreter time the execution of every instruction. I don't immediately see a way to do it that's compatible with any kind of efficient execution model.

The rest would be optimization while keeping the timing sidechannel constraint in mind, hard to say what the performance possibilities are. For example not all computations have externally observable side effects, so those parts could be executed conventionally if the runtime could guarantee it. Or the program-visible clock APIs might be keeping virtual time that makes it seem from timing POV that operations are slower than they are, combined with network API checkpoints that halt execution until virtual time catches up with real time. Etc. Seems like a interesting research area.

Re: Chrome ships WebGPU

#105

Soon, there will be no need to install softwares to the computer. A modern browser will cover it all. What scares me is browsers getting bloated with all kinds of features while webapps getting bigger and bigger in size for no reason. Note, I am all for this feature getting widely adopted.

Except for being less capable.

WebGL 2.0 is basically a PS3 / XBox 360 kind of graphics, and WebGPU would be PS4, and that is about it.

All the other cool things, Mesh Shaders, Ray Tracing, Nanite... forget about it, with luck in the next 10 years, if it follows WebGL 2.0 improvements rate.

Re: Chrome ships WebGPU

#106
post #87

Chrome and Firefox have supported WebGL since 2011 and WebAssembly since 2017. What is the reason we don't have at early-2010s quality AAA game experiences running in the browser?

That is always my example why WebGL is only usefull for ecommerce stores, shader toy and little else.

We still don't have any debugger quality like Renderdoc, Instruments, PIX, and there is nothing with the quality of Infinity Blade, the game Unreal and Apple used to demo iPhone's GL ES 3.0 capabilties.

Streaming like XBox Cloud seems to be the only path for "AAA game experiences running in the browser".

Re: Chrome ships WebGPU

#107
post #99

Earlier quoted context omitted.

These differences are smaller than the differences between desktop GL and WebGL though. It's just another option in the low-level vs high-level 3D API zoo. As far as wrapper APIs go, the native WebGPU implementation libraries are a pretty good option, because being also used in browsers there's a ton of testing and driver bug workarounds going into them which other 3D API wrapper projects simply can't afford to do.

Not at all. First of all, if one depends on SPIR being present, then a SPIR to WGSL compiler needs to be present when deploying to the Web part of WebGPU. Secondly, it will be yet another extension spaghetti that plagues any API that Khronos has some relation to.

It already made sense to have a SPIRV- and SPIRVCross-based shader pipeline in cross-platform engines with WebGL support though (because you'd want to author shaders in one shading language only, and then translate them to various target languages, like some desktop GLSL version, then separate versions for GLES2/WebGL and GLES3/WebGL2, and finally HLSL and MSL, WGSL is just another output option in such an asset pipeline).

Re: Chrome ships WebGPU

#108
post #47

Earlier quoted context omitted.

I'm surprised people accept non-bit-identical output. Intel did a lot of damage here with their wacky 80-bit floating point implementation, but really it should be the norm for all languages.

Why would I want bit-identical output? Genuinely curious. I see there's some increase in confidence perhaps, although the result can still be deterministically wrong...

It's very hard to do tests of the form assert(result == expected) if they're not identical every time.

And it can waste a horrendous amount of time if something is non-bit-identical only on a customer machine and not when you try to reproduce it ...

Re: Chrome ships WebGPU

#109

Earlier quoted context omitted.

Google are the people paying for Chrome, they do not benefit in any way from this kind of fingerprinting. To the contrary, it decreases the value of their browser monopoly.

> Google are the people paying for Chrome, they do not benefit in any way from this kind of fingerprinting. The largest ad company in the world 80% of whose money comes from online advertising does not benefit from tracking...

They don't benefit from fingerprinting, because the browser has all sorts of easier to track mechanisms available by default. Fingerprinting is for browsers that don't actively enable tracking.

Re: Chrome ships WebGPU

#110
post #56

Earlier quoted context omitted.

> Google are the people paying for Chrome, they do not benefit in any way from this kind of fingerprinting. The largest ad company in the world 80% of whose money comes from online advertising does not benefit from tracking...

Even supposing that Google do benefit from it in that manner, there would be far simpler ways for them to make fingerprinting easier. It's extremely unlikely that this is a significant motivation for adding WebGPU. Not to mention that a lot of the fingerprinting you can potentially do with WebGPU can already be done with WebGL.

Google has many hands in many pots. It's not that they are necessarily looking for easier ways to do fingerprinting. But they sure as hell wouldn't put up a fight to make it harder.
Post reply on HN