Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

WebGPU – All of the cores, none of the canvas

surma.dev

Post reply on HN
Print view View original

131–137 of 137 posts

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

#131

Post by kannanvijayan »

whatever_dude wrote: post #90
bob1029 wrote: post #76

I've busted my ass on webgl a few times, and I am not really seeing how WebGPU is a substantially better API looking at the samples in the wild: https://webkit.org/demos/webgpu/scripts/hello-triangle.js The advantages of WebGPU vs WebGL probably make sense to experts in this area, but I still find most of it to be completely impenetrable at first glance as a relative novice.

WebGPU is better in many dimensions, but also worse in others people might care about. More appropriately, in this case, WebGPU is in many ways less approachable for novices. One of the expected advantages of WebGPU is exposing the inner workings of the hardware's GPU support in a more explicit manner. This leads to really verbose code. This is similar to API movements seen in DirectX, Vulkan, and Metal. WebGL was ne…

Anecdotally, I had the opposite experience. I've wanted to dabble in parallel/gpu programming for a while but the fact that all the material forced me to care about triangles and matrix transforms for nontrivial case examples turned me off.

I've recently been playing with WebGPU and while it's still a bit of a boilerplate nightmare (which I wouldn't presume to know how to do better).. it was far more approachable.

Wrapping my head around buffers and layouts, and the fact that wgsl is a huge pain in the neck to debug, took a while.

I've built myself a really rudimentary perlin noise generator using compute shaders, and managed to pipe that into a rendering shader that uses two triangles to render part of the noise field onto a canvas really smoothly.

Trying to do some fancier compute stuff now, and overall the primitives are relatively straightforward. It's just that the documentation around the binding types and layouts, resource limits, and command-encoder/pipeline operational semantics are poor right now.

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

#132

Post by chris37879 »

TheRealNGenius wrote: post #120
astlouis44 wrote: post #88

Earlier quoted context omitted.

For any developers interested, our team at Wonder Interactive is working on WebGPU support for Unreal Engine 4 and Unreal Engine 5. Games and real-time 3D applications in the browser will form the basis of the open metaverse. You can register here on our website for early access - https://theimmersiveweb.com/

just so you know, images don't even work on your site. Using safari

I'm going to bet you're using a mac running an older version of OSX, I ran into this exact issue, only Safari on macos 11+ supports webp.

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

#133

Post by modshatereality »

TazeTSchnitzel wrote: post #53
superkuh wrote: post #9

WebGPU, all the bare metal crashes/exploits and none of the broad support. Browsers should not be operating systems and the move to make them so will end up making them just as exploitable as your host OS only much slower due to the additional abstraction layers.

There's very little that GPUs can do that CPUs can't do so far as exploitation is concerned. The GPU driver runs in a sandboxed userland process just like the browser engine does, and the GPU respects process isolation just like the CPU does. There is no “bare metal” here! Now, sure, there must be plenty of memory-safety issues in GPU drivers, but why find an exploit in a driver only some users have installed, when y…

The driver runs in ring 0, and talks over PCI bus to some blackbox that is running random source code your web browser just compiled...

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

#134

Post by flohofwoe »

kvark wrote: post #130
flohofwoe wrote: post #50

Earlier quoted context omitted.

Minor nitpick: this translation happens in separate libraries/tools which just make use of the SPIRVTools library for some SPIRV processing tasks, but not the actual translation to WGSL. Tint (Google, implemented in C++): https://dawn.googlesource.com/tint/ Naga (Mozilla(?), implemented mostly in Rust): https://github.com/gfx-rs/naga Both are a bit similar to SPIRV-Cross, except that they also support WGSL.

Naga (a community project) translates GLSL directly into WGSL, unlike other tools.

Ah alright, thanks for the correction :)

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

#135

Post by astrange »

modeless wrote: post #117
astrange wrote: post #116

Earlier quoted context omitted.

> Browsers implement their own copy/paste, accessibility, and translation. WebGPU being used for rendering affects none of that. That's why I said skipping the DOM, as in using canvas or WebGPU yourself. Browsers do handle that properly but unfortunately games or game-like apps don't even if they display lots of text. > Subpixel AA is a technology of the past and a new forward looking browser should not bother suppor…

In the comment you're replying to I did not propose skipping the DOM, I proposed rendering the DOM via WebGPU. As an implementation detail of the browser, not as something websites should do themselves. Um, Apple is far from the only vendor of high res displays. And not all OLEDs are PenTile. The trend in all displays is to higher resolution where subpixel AA is unnecessary complexity, and especially on mobile which…

> In the comment you're replying to I did not propose skipping the DOM, I proposed rendering the DOM via WebGPU. As an implementation detail of the browser, not as something websites should do themselves.

Hmm, I guess so, but writing the browser based on WebGPU seems limiting? You can use native code there.

> Um, Apple is far from the only vendor of high res displays.

There's stories on here every day about how they are.

https://news.ycombinator.com/item?id=30604375

https://news.ycombinator.com/item?id=30631288

> And not all OLEDs are PenTile.

Meant to say "mobile OLEDs" if you insist. There's no desktop OLEDs, people don't seem to enjoy using RGBW TVs as displays. Couldn't say why.

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

#136

Post by dragonwriter »

astrange wrote: post #135
modeless wrote: post #117

Earlier quoted context omitted.

In the comment you're replying to I did not propose skipping the DOM, I proposed rendering the DOM via WebGPU. As an implementation detail of the browser, not as something websites should do themselves. Um, Apple is far from the only vendor of high res displays. And not all OLEDs are PenTile. The trend in all displays is to higher resolution where subpixel AA is unnecessary complexity, and especially on mobile which…

> In the comment you're replying to I did not propose skipping the DOM, I proposed rendering the DOM via WebGPU. As an implementation detail of the browser, not as something websites should do themselves. Hmm, I guess so, but writing the browser based on WebGPU seems limiting? You can use native code there. > Um, Apple is far from the only vendor of high res displays. There's stories on here every day about how they…

> There's stories on here every day about how they are.

There's stores about their high res displays, but to the extent they claim Apple is the only vendor that's just plain false.

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

#137

Post by beaugunderson »

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?

Chrome, macOS--I see the issue. The scrollbar does not show up against the lighter segments (e.g. the code examples).
Post reply on HN