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

101–110 of 137 posts

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

#101

Post by raphlinus »

______-_-______ wrote: post #99
raphlinus wrote: post #84

Earlier quoted context omitted.

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

By "work with somebody", do you mean your team at Google is hiring for this, or are you looking for community contributors?

At the moment, I am talking about community contributors. But if you have a credible plan for getting this done and the thing that would hold it back is funding, let's talk.

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

#102

Post by ajconway »

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.

I’ve always been interested in CG. Back in the day, I played with OpenGL 1.x, D3D5, lived through the introduction of shaders. Now I’m toying with Vulkan and it’s incredible how simple it feels compared to the old-school APIs. Everything basically reflects what the GPU is really doing, you just acquire a drawing surface, set the state, bind some buffers and execute the shaders. There is very little hidden state.

I admit this is a little bit more involved than calling glClear followed by glDrawTriangles, but once you reach the stage where you’re ready to apply textures and write shader code, the new way seems much more straightforward.

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

#103

Post by ______-_-______ »

raphlinus wrote: post #101
______-_-______ wrote: post #99

Earlier quoted context omitted.

By "work with somebody", do you mean your team at Google is hiring for this, or are you looking for community contributors?

At the moment, I am talking about community contributors. But if you have a credible plan for getting this done and the thing that would hold it back is funding, let's talk.

I have no credible plan and I would need some mentoring before I could even be productive. Sounds like you probably want someone with more relevant experience.

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

#105

Post by moralestapia »

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.

>The advantages of WebGPU vs WebGL probably make sense to experts in this area

Think of it as going much lower level like doing your stuff in x86 assembly language, so, sure it's going to be a PITA to get something running but for that very special need where every bit of performance matters it's going to work well.

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

#106

Post by modeless »

raphlinus wrote: post #84
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.

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

I wouldn't start a browser from scratch, it's too big and compatibility is a never ending quagmire. I think it would be cool to do a new portable app platform with bits and pieces of the web platform like WebGPU, combined with new stuff, kind of like how deno is using web APIs outside the web. Maybe combined with the ideas from the redbean server.

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

#107

Post by gmiller123456 »

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.

    I still find most of it to be completely impenetrable at first glance as a relative novice
There's a lot of boilerplate code involved in setting up even the simplest of programs. I think one descent way to get started learning is to skip the boilerplate at the start and just play with the GPU part, like shadertoy.com lets you do.

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

#108

Post by astrange »

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.

GPUs aren't particularly good at vector graphics rendering especially at smaller sizes. You'd want a CPU emulator of the GPU code and that seems strictly worse than doing it native.

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

#109

Post by astrange »

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 main difference is that it's a lot easier to crash GPU drivers (eg with a 100% busy loop) or slow down UI rendering. There are shader verifiers to avoid some of this.

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

#110

Post by modeless »

astrange wrote: post #108
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.

GPUs aren't particularly good at vector graphics rendering especially at smaller sizes. You'd want a CPU emulator of the GPU code and that seems strictly worse than doing it native.

https://sluglibrary.com/ says otherwise
Post reply on HN