kangz

The WebGPU samples you pointed out are a good resource, but this article is a decent introduction to GPU compute and should be up to date [1].

[1] https://github.com/GoogleChrome/web.dev/pull/7827

WebGPU is enabled by default in Chrome on Mac as part of the WebGPU Origin Trial (https://web.dev/gpu). We didn't really test on M1 Macs but several people reported it just works.

Other comments explain how that's challenging/impossible in the general case because GPU don't have as good preemption as CPUs and because of the halting problem. However for the VRChat use case you could imagine disallowing unbounded loops so you can estimate the number of instructions and put a reasonable cap on them. This would take care of the DOS and the WebGPU runtime would take care of the rest of the security (OOB, uninitialized data, etc)

I think you meant WebKit on Windows (used for other browsers than Safari). Once Dawn is integrated in WebKit for one OS, it should be easy to extend WebKit to use it on other OSes so maybe it will be a quick way to have WebGPU implemented in Safari?

Browsers are Javascript bindings to WebGPU :) But more seriously, there is a https://github.com/maierfelix/webgpu that implements node bindings for Felix's Dawn fork. The fork is close to upstream and Dawn is close to "webgpu.h" so it should be easy to repurpose.

WebGPU is extremely different from Vulkan. They have similar concepts because they're both from the same family of "explicit APIs" (that also contains Metal and D3D12).

Vulkan is hard to validate because it was designed assuming it trusts the developers to follow the valid usage rules. For example it is the developer's responsibility to only destroy GPU resources after they are done being used. Validation layers have to track for each submission the link from vkCmdBindDescriptorSets to descriptor sets to texture views to textures just to validate there is no use after frees, and that's just one of the many many valid usage rules.

In contrast a guiding principle in the design of WebGPU is that it should be fully validated at a reasonable cost. Keeping the same example, calling texture.destroy() in WebGPU will make the browser destroy the texture after all previous execution completes, and prevents any further usage of that texture. The Web Platform Tests (WPT) is a test suite that ensures browsers are interoperable. WebGPU's tests in WPT will contain test cases for all validation rules and corner cases, including overflows like the one you mentioned (and check it produces an error that is handled gracefully).

Yes, so does WebGL and with the same efficiency.

Partial hash inversion is an embarrassingly parallel problem: computing a hash from a random number is independent from the other random numbers you want to compute hashes for, also it is a computation bound problem and not memory bound. It means you can build a fairly efficient partial inverse finder by running many fragment shaders ("pixels") in parallel and only drawing the one that finds it. This is doable in WebGL today.

A key feature of WebGPU is compute shaders which sound like they can compute stuff so they would be better at hashing. But actually compute shaders give more flexibility which makes it possible to handle problems that are a bit less parallel, and they help optimize memory-bound programs (but don't help for computation bound programs). So compute shaders make it slightly less code to do a partial inverse finder, but do not make it dramatically more efficient.

So to answer your implicit point: no WebGPU won't unlock capabilities that will lead to a rise in ads mining Bitcoin. (though it could maybe help for Ethereum mining)

The SPIR-V for WebGPU has the subsetting of the language at [1], validation is fully implemented in spirv-val and as are the safety checks in spirv-opt.

SPIR-V is also proven to compile to all the target APIs for WebGPU, while WSL only has a MSL transpiler right now.

[1] https://github.com/gpuweb/spirv-execution-env/blob/master/ex...

There is no WebGPU dialect of GLSL, only a SPIR-V execution environment for WebGPU. Lnaguages in themselves aren't "safe" or "unsafe", their implementations are.

Also please stop trying to influence a technical debate in a standardization group by putting blog posts on top of Hacker News.

> To clarify though, that requires an external attacker-controlled process to monitor the GPU, yes?

Yes, they do it with high-speed probing of the amount allocated GPU memory. This requires access to native APIs (specific OpenGL extensions in this case). Like you said there seems there would be simpler ways to achieve this, but the demonstration of this side-channel is still very interesting.

Varying the size of the textboxes might not help because the rendering engine of browsers can have a memory allocation per letter for example.