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

21–30 of 54 posts

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

#21

Post by pythops »

pjmlp wrote: post #18
pythops wrote: post #12

Earlier quoted context omitted.

if you any suggestion about articles to read about wgpu plz share. I kind of struggle to find good articles with good examples for beginners to get started with wgpu

Have you already been here? https://webgpufundamentals.org/ https://webgpu.github.io/webgpu-samples

Thanks so much This one https://webgpufundamentals.org/ is amazing.

I wish there was more about compute shading instead and not JS centered.

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

#22

Post by hutzlibu »

pythops wrote: post #12
Jasper_ wrote: post #6

I'm a graphics programmer who has quite a bit of experience with WebGL, and (disclaimer) I've also contributed to the WebGPU spec. > Quite honestly, I have no idea how ThreeJS manages to be so robust, but it does manage somehow. > To be clear, me not being able to internalize WebGL is probably a shortcoming of my own. People smarter than me have been able to build amazing stuff with WebGL (and OpenGL outside the web)…

if you any suggestion about articles to read about wgpu plz share. I kind of struggle to find good articles with good examples for beginners to get started with wgpu

Did you gave this article a try?

I found it very helpful for me to get started. And it is not really outdated, only the first example does not work anymore right away, but if you go to the next step, it all works and then you progresd to a small working physics simulation.

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

#23

Post by TazeTSchnitzel »

29athrowaway wrote: post #8
Jasper_ wrote: post #6

I'm a graphics programmer who has quite a bit of experience with WebGL, and (disclaimer) I've also contributed to the WebGPU spec. > Quite honestly, I have no idea how ThreeJS manages to be so robust, but it does manage somehow. > To be clear, me not being able to internalize WebGL is probably a shortcoming of my own. People smarter than me have been able to build amazing stuff with WebGL (and OpenGL outside the web)…

Can you elaborate more on this? It seems interesting > if you are using gl.enable(gl.BLEND) in your core render loop, you have basically already failed.

As Jasper said, you write a library to manage GL state for you, rather than calling GL functions directly to manage state (like glEnable and glDisable, among countless others). The risk is simply that you will forget to change things back and one drawing operation will accidentally affect the next.

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

#24

Post by TazeTSchnitzel »

tim1994 wrote: post #16
29athrowaway wrote: post #8

Earlier quoted context omitted.

Can you elaborate more on this? It seems interesting > if you are using gl.enable(gl.BLEND) in your core render loop, you have basically already failed.

I'd also be interested in details on this but I assume the gl.enable() API changes fundamental things about the rendering pipeline. It allows enabling things like depth testing and stencil (both involve an extra buffer) and face culling (additional tests after vertex shader). For blending in particular I think it requires the fragment shader to first read the previous value from the frame buffer. Changes this stuff i…

> Changes this stuff is probably not a trivial operation and requires a lot of communication with the GPU which is slow (just a guess).

The GPU underneath looks a lot more like Vulkan than it does like OpenGL. Changing state should, in general, not require communicating with the GPU at all, that happens once you draw stuff (or do other operations like compiling shaders or creating textures).

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

#25

Post by hutzlibu »

Following the article, you build a simple 2D physic simulation (only for balls). Did by chance anyone expand on that to include boxes, or know of a different approach to build a physic engine in WebGPU?

I experiemented a bit with it and implemented raycasting, but it is really not trivial getting the data in and out. (Limiting it to boxes and circles would satisfy my use case and seems doable, but getting polygons would be very hard, as then you have a dynamic size of their edges to account for and that gives me headache)

A 3D physic engine on the GPU would be the obvious dream goal to get maximum performance for more advanced stuff, but that is really not an easy thing to do.

Right now I am using a Box2D for wasm and it has good performance, but it could be better.

https://github.com/Birch-san/box2d-wasm

The main problem with all this is the overhead of getting data into the gpu and back. Once it is on the gpu it is amazingly fast. But the back and forth can really make your framerates drop - so to make it worth it, most of the simulation data has to remain on the gpu and you only put small chanks of data that have changed in and out. And ideally render it all on the gpu in the next step.

(The performance bottleneck of this simulation is exactly that, it gets simulated on the gpu, then retrieved and drawn with the normal canvasAPI which is slow)

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

#26

Post by TazeTSchnitzel »

nevi-me wrote: post #15

My disappointment with WebGPU has been limited data type support. I wanted to write some compute stuff with it, but the limitation of not supporting a lot of integer sizes made it undesirable. Does anyone know if the spec is likely to be revised to add more support over time?

What kinds of integer sizes? Depending on the target GPU, 64-bit integers are likely to not be available at all, or be quite slow. If you need 8-bit or 16-bit integers, on the other hand, those can be trivially emulated with 32-bit operations.

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

#27

Post by flohofwoe »

29athrowaway wrote: post #8
Jasper_ wrote: post #6

I'm a graphics programmer who has quite a bit of experience with WebGL, and (disclaimer) I've also contributed to the WebGPU spec. > Quite honestly, I have no idea how ThreeJS manages to be so robust, but it does manage somehow. > To be clear, me not being able to internalize WebGL is probably a shortcoming of my own. People smarter than me have been able to build amazing stuff with WebGL (and OpenGL outside the web)…

Can you elaborate more on this? It seems interesting > if you are using gl.enable(gl.BLEND) in your core render loop, you have basically already failed.

One reason is that small innocent changes like this can cause a large wave of dependent changes inside the GL implementation, shaders may be patched or recompiled, internal 'state group objects' discarded and recreated, and those expensive actions might happen at a random point further down in another GL call. Also those details differ between GPU vendor drivers, and sometimes even driver versions. This is what makes GL extremely unpredictable when it comes to profiling the CPU overhead, and why modern 3D APIs prefer bundling state into immuntable state-group-objects.

For other things, specifically WebGL may need to run expensive input validation which might also trigger at more or less random places.

Also: it's very easy to forget one tiny state change out of dozens, which then mess up rendering in more or less subtle ways, not just for the rest of the frame, but the rest of the application lifetime.

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

#30

Post by andrewstuart »

flohofwoe wrote: post #29
andrewstuart wrote: post #28

Will there be better typography in WEbGPU?

WebGPU is completely separate from the browser's text rendering engine (unfortunately).

I ask because WebGL almost never has typography. I assume there are technical reasons.
Post reply on HN