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

81–90 of 137 posts

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

#81

Post by modeless »

dmitriid wrote: post #31

So now there are three incompatible graphics APIs in the browsers which are also incomplete in different ways. Each of them is a huge chunk of code that needs to maintained and updated.

If I was developing a new browser today, my graphics abstraction would be WebGPU and all other graphics would be built on it. WebGL, Canvas 2D, SVG, and even DOM rendering would be unprivileged libraries on top and only WebGPU would be able to touch the actual hardware. I wouldn't be surprised if some browsers moved that way in the long term.

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

#82

Post by danielvaughn »

chompychop wrote: post #63
danielvaughn wrote: post #45

Earlier quoted context omitted.

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?

I read so many different articles that it's difficult to remember exactly which ones. One very good resource is this person: https://www.youtube.com/watch?v=9WW5-0N1DsI

The video is more about shaders in Unity, but she explains the context behind what shaders are so much more clearly than anyone else I've come across.

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

#83

Post by shadowgovt »

TurningCanadian wrote: post #64
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?

You definitely could (and, indeed, I can imagine beneficial use cases for a "renice" feature in a browser like Chrome with its Task Manager).

But there's less of a significant need for it. Main CPU performance is too poor on hashing datasets to much benefit from salami-slicing user CPU at scale. That trick is much likelier to get you a solved block in the blockchain if you can tap user GPUs on a couple million users.

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

#84

Post by raphlinus »

modeless wrote: post #81
dmitriid wrote: post #31

So now there are three incompatible graphics APIs in the browsers which are also incomplete in different ways. Each of them is a huge chunk of code that needs to maintained and updated.

If I was developing a new browser today, my graphics abstraction would be WebGPU and all other graphics would be built on it. WebGL, Canvas 2D, SVG, and even DOM rendering would be unprivileged libraries on top and only WebGPU would be able to touch the actual hardware. I wouldn't be surprised if some browsers moved that way in the long term.

I find your ideas intriguing and I wish to subscribe to your newsletter.

More seriously, yes, if you were starting a browser completely from scratch, this would probably be a good approach. There are some subtleties, but probably nothing that couldn't be solved with some elbow grease.

If anyone is seriously interested in exploring this direction, one thing that would be very interesting is a port of piet-gpu to run on top of WebGPU (it's currently running on Vulkan, Metal, and DX12). I've done quite a bit of pre-work to understand what would be involved, but don't personally have the bandwidth to code up the WebGPU port. I would be more than happy to work with somebody who does.

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

#85

Post by Narishma »

modeless wrote: post #81
dmitriid wrote: post #31

So now there are three incompatible graphics APIs in the browsers which are also incomplete in different ways. Each of them is a huge chunk of code that needs to maintained and updated.

If I was developing a new browser today, my graphics abstraction would be WebGPU and all other graphics would be built on it. WebGL, Canvas 2D, SVG, and even DOM rendering would be unprivileged libraries on top and only WebGPU would be able to touch the actual hardware. I wouldn't be surprised if some browsers moved that way in the long term.

Doesn't WebGPU require a DX12-level GPU? If so, that would make your browser incompatible with a ton of systems out there.

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

#86

Post by Jasper_ »

j-pb wrote: post #69
dassurma wrote: post #32

Earlier quoted context omitted.

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 SPI…

This is a very inaccurate summary of what happened. And I say this as someone who does not particularly like WGSL. Mozilla, Google and Apple are all working to help design WGSL.

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

#87

Post by Jasper_ »

cma wrote: post #41
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 whole purpose of Vulkan was an open API that could work on all vendors. I'm not sure why they based WebGPU on Metal over the Mozilla proposal. Now Apple can control the future evolution of it by saying "metal 1.X does it this way." With a Vulkan based webgpu Khronos could do the same, but their "vulkan 1.X does it this way" would have already been the result of a cross-vendor standards committee instead of from a…

The modern WebGPU spec was more or less based on Google's NXT proposal, rather than Apple's WebGPU prototype.

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

#88

Post by astlouis44 »

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

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/

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

#89

Post by modeless »

Narishma wrote: post #85
modeless wrote: post #81

Earlier quoted context omitted.

If I was developing a new browser today, my graphics abstraction would be WebGPU and all other graphics would be built on it. WebGL, Canvas 2D, SVG, and even DOM rendering would be unprivileged libraries on top and only WebGPU would be able to touch the actual hardware. I wouldn't be surprised if some browsers moved that way in the long term.

Doesn't WebGPU require a DX12-level GPU? If so, that would make your browser incompatible with a ton of systems out there.

Writing a new browser would take many years and those systems would be obsolete :) But there's also an intention to produce a more compatible restricted subset of WebGPU at some point.

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

#90

Post by whatever_dude »

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 never exactly easy to read either, but you could get started more easily. It tried being something in-betweenm though, and ended up never being the best at either providing explicit behavior, nor being friendly.

The idea of WebGPU going forward is that it will make it easier for other libraries to use it in a more deterministic fashion. If you know how the metal works, you'll be able to optimize the sh*t out of it. But for novices, you'll end up using some library or engine that abstracts away a lot of the hardcore functionality like "let's get an adapter that supports this specific texture extension" or "let's reuse a binding group layout to save 2ns when binding uniforms". In the same way most people on the web use Three.js (instead of WebGL), you'll see libraries like Babylon or Three.js making use of WebGPU without really having to know about all that stuff. And that's the right solution.

Post reply on HN