WebGPU – All of the cores, none of the canvas • Hacker News Board

Re: WebGPU – All of the cores, none of the canvas

#61

Post by brrrrrm » Tue, Mar 08, 2022, 5:23 PM UTC

assbuttbuttass wrote: post #46

Am I understanding this right, that websites can now run a crypto miner in the background when I visit them?

If you're using Chrome Canary with the "Unsafe WebGPU" flag turned on, yes. And it'll be a lot faster/more power hungry than before. Otherwise, nothing beyond the normal CPU based miners have been enabled.

Adaptation is the cost of progress. Browser vendors will almost certainly implement a way to prevent unauthorized use of such hardware (either by prompt like webcams or automatic detection) before this stuff becomes publicly available.

Re: WebGPU – All of the cores, none of the canvas

#62

Post by Ruphin » Tue, Mar 08, 2022, 5:24 PM UTC

dassurma wrote: post #35

beaugunderson wrote: post #21

One request for the author: Please don't hide the scroll bars on websites you make like this!

I am not! I have no styles that should affect scrollbar visibility. What browser & OS are you on?

Hi Surma. Thanks a lot for this writeup. I have been trying to get into WebGPU but good introductory material was sorely lacking some time ago.

I have one question: I have had trouble finding a combination of browser/OS/GPU that would allow WebGPU access at the time, what setup did you use and do you have any recommendations? Particularly looking for options on Linux. (Sorry for hijacking this thread)

Re: WebGPU – All of the cores, none of the canvas

#63

Post by chompychop » Tue, Mar 08, 2022, 5:34 PM UTC

danielvaughn wrote: post #45

raphlinus wrote: post #30

Earlier quoted context omitted.

I think one of WebGPU's greatest strengths is learning, as you can get started pretty easily, and you actually learn a modern approach to GPU. Vulkan requires a significant amount of boilerplate just to establish a connection to the GPU and set up basic resources like the ability to allocate buffers. In WebGPU, the latter is one or two lines of code. That said, there are some really nice learning resources for Vulkan…

So I just went through this process and I have to slightly disagree. I'm coming from literally no knowledge of low-level graphics programming. My most relevant experience is writing against Canvas2D, which is not relevant at all. I first tried WebGPU, and was so overwhelmed with detail that it was nearly impossible to connect the dots. So I went back and decided to learn WebGL first. I know that it's very different,…

Could you share what resources you used to learn the essentials of WebGL enough to tackle WebGPU?

Re: WebGPU – All of the cores, none of the canvas

#64

Post by TurningCanadian » Tue, Mar 08, 2022, 5:36 PM UTC

shadowgovt wrote: post #7

Is this API going to have a permissions lock, like access to the video camera or microphone APIs do? If it doesn't, I'm not looking forward to the future where every website I visit tries to pull a big chunk of my graphics card to mine cryptocurrencies without my explicit authorization.

Couldn't you make the same argument about being able to perform computation on the CPU?

Re: WebGPU – All of the cores, none of the canvas

#65

Post by secondcoming » Tue, Mar 08, 2022, 5:40 PM UTC

assbuttbuttass wrote: post #46

Am I understanding this right, that websites can now run a crypto miner in the background when I visit them?

We'll also have to start measuring websites by how much power they consume.

Re: WebGPU – All of the cores, none of the canvas

#66

Post by neogodless » Tue, Mar 08, 2022, 5:40 PM UTC

modeless wrote: post #22

faeyanpiraat wrote: post #2

Question for someone with gpu programming experience: is it feasible to analyze time series data (eg.: run a trading algorithm through a series of stock prices) in parallel (with the algorithms receiving different parameters in each core)? If not then what is the limiting factor?

Yes, in fact GPUs are perfect for this. Here is a Monte Carlo financial simulation I built in WebGL 2. https://james.darpinian.com/money/ (Warning, programmer UI) It performs one million Monte Carlo runs instantly every time you move a slider. Each run is one execution of a pixel shader and they all happen in parallel. WebGPU will make this kind of thing more accessible. It's kind of a pain to do it in WebGL, but eve…

Hmm the UI is super unresponsive for me. As in, I try to move a slider, I can't tell where it's moving to... then I let go and it's somewhere I didn't expect.

Latest Firefox, Windows 10, Radeon RX 6700XT 16GB.

Re: WebGPU – All of the cores, none of the canvas

#67

Post by slimsag » Tue, Mar 08, 2022, 5:42 PM UTC

rektide wrote: post #33

eole666 wrote: post #27

For those looking for a complete 3D engine already supporting WebGPU and with a WebGL fallback if needed, there is BabylonJs (you'll need the 5.0 version still in the release candidate state) : https://doc.babylonjs.com/advanced_topics/webGPU/webGPUStatu... ThreeJs is alwo working on its WebGPU renderer

Im excited for Bevy engine too. It uses wgpu, which has many backends, including webgpu. https://bevyengine.org https://hn.algolia.com/?q=bevy

I've only heard great things about Bevy, and their community is awesome. Highly recommend looking into it if you like Rust! They also just had a huge gamejam with something like ~70 submissions. Impressive stuff!

I'm super excited about WebGPU and think it will be a winning strategy for game engines going forward.

I'm working on a (very early stages) game engine in Zig called Mach[0] and am using Google Chrome's implementation of WebGPU as the native graphics abstraction layer, so Zig's C++ compiler builds it all, you get cross-compilation out of the box. It's quite fun!

[0] https://devlog.hexops.com/2021/mach-engine-the-future-of-gra...

Re: WebGPU – All of the cores, none of the canvas

#68

Post by raphlinus » Tue, Mar 08, 2022, 5:45 PM UTC

mwcampbell wrote: post #58

raphlinus wrote: post #4

Earlier quoted context omitted.

This depends on the algorithm. If it has lots of branching and control flow, then it's unlikely to run well. If it's based on something like FFT or any sort of linear algebra really, then it should run really well. WebGPU is accessible enough maybe you should try it! You'll learn a lot either way, and it can be fun.

Since you mentioned FFT, I wondered whether GPU-based computation would be useful for audio DSP. But then, lots of audio DSP operations run perfectly well even on a low-end CPU. Also, as one tries to reduce latency, the buffer size decreases, thus reducing the potential to exploit parallelism, and I'm guessing that going to the GPU and back adds latency. Still, I guess GPU-based audio DSP could be useful for batch pr…

Yes. Probably the single most effective use of the GPU for audio is convolutional reverb, for which a number of plugins exist. However, the problem is that GPUs are optimized for throughput rather than latency, and it gets worse when multiple applications (including the display compositor) are contending for the same GPU resource - it's not uncommon for dispatches to have to wait multiple milliseconds just to be scheduled.

I think there's potential for interesting things in the future. There's nothing inherently preventing a more latency-optimized GPU implementation, and I personally would love to see that for a number of reasons. That would unlock vastly more computational power for audio applications.

There's also machine learning, of course. You'll definitely be seeing (and hearing) more of that in the future.

Re: WebGPU – All of the cores, none of the canvas

#69

Post by j-pb » Tue, Mar 08, 2022, 5:54 PM UTC

dassurma wrote: post #32

j-pb wrote: post #26

WebGPU is a textbook case of Embrace Extend Extinguish performed by Apple to kill Kronos and SPIRV, and everybody is cheering it on. Crazy.

The WebGPU spec is currently edited by two Google employees and one Mozilla employee. I am not sure how to make sense of your accusation.

The author list and W3C document are pretty much irrelevant, the actual working group is what counts.

After thinking about it some more, I've come to the conclusion that I've actually not been strong enough in my initial accusation, and that Apple is trying to smother any threat that WebGPU poses to its native App supremacy.

The story is essentially:

Apple wants SPIRV dead. Mozilla wants SPIRV alive. Google wants SPIRV alive.

Google developed a human readable text version for SPIRV, which is isomorphic to the binary version, akin to WASM WAT.

Mozilla wants SPIRV, which Apple fully rejects (because of some legal dispute with Chronos, where Apple probably tries to get a patent for something that Chronos has as prior art or something), but they are open to googles proposal of a textural intermediary, which is isomorphic.

Mozilla and Google agree, because they'll all compile down to SPIRV anyways, except for Apple which will target Metal.

This decision is captured in the W3C proposal which to this day contains the Isomorphism property.

That's the Embrace, WGSL is born.

Apple convinces Mozilla and Google that WGSL should be even more human readable, since user readable formats are the backbone of the open web. But for more convenience WGSL will need more features. Extend.

Apple convinces Mozilla and Google that now that the language has grown anyways they should make it much more compatible with other shading languages in general, SPIRV will not be the only target, so while it should be compilable to SPIRV, that's by no means a primary goal. Isomorphism is abandoned. Google tries a last ditch effort to keep the isomorphism with a proposal literally called: "Preserving developer trust via careful conversion between SPIR-V and WGSL".

The proposal is rejected, the working group decides that the isomorphism property will no longer hold (I can only assume malevolence that they haven't removed it from the spec yet, probably to keep dev support.). Extinguished.

https://docs.google.com/presentation/d/1ybmnmmzsZZTA0Y9awTDU...

Why is that isomorphism so important? Because it's near impossible to develop truly high performance shaders with a load of compiler optimisations between your hardware and your tooling. Apple is successfully giving us GLSL in new clothes, and developers are cheering them on, because they just read the W3C spec and ignore the realities of the standard.

---

Apple: "Having an isolated focus on SPIR-V is not a good perspective, we have MSL etc. to consider too"

...

Apple: "Extreme A is no interaction with SPIRV?, extreme B is very tightly coupled to SPIRV, we should find a middle point"

...

Google: "We take all targets into consideration. We can allow developers do runtime probing and maybe branch according to that. Optimization occurs in existence of uncertainty. Dealing with fuzziness is a fact of life and we should give the tools to developers to determine in runtime."

From https://docs.google.com/document/d/15Pi1fYzr5F-aP92mosOLtRL4...

Re: WebGPU – All of the cores, none of the canvas

#70

Post by modeless » Tue, Mar 08, 2022, 5:55 PM UTC

assbuttbuttass wrote: post #46

Am I understanding this right, that websites can now run a crypto miner in the background when I visit them?

No. Crypto miners have always been possible and WebGPU does not make them faster than they would be in WebGL 2 which has been available for a long time already.