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

51–54 of 54 posts

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

#51

Post by Jasper_ »

amelius wrote: post #32
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)…

> WebGL (and OpenGL) are awful APIs (...) What would a good graphics API look like?

Most people that want to keep using OpenGL would be better served by a cross-platform D3D11. WebGPU is similar-ish to that.

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

#52

Post by Jasper_ »

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.

Basically, if you have one piece of codebase call gl.enable(gl.BLEND), then either that needs to reset it at the end with gl.disable(gl.BLEND) and you have some vague ambiguous default state that everything enters and leaves. If you don't, then either your code up ahead needs to unset any possible state added while outside and call gl.disable(gl.BLEND) before it renders, or it's dependent on state set from around it.

That latter issue is a real problem, because it makes the frame a lot harder to refactor. One of the biggest stumbling blocks for any new graphics programmer that started on OpenGL is implementing something like a Z-prepass or a shadow map, where you have the same object drawing to two passes, because the GL state machine makes it very easy to accidentally depend on some hidden piece of state you didn't know you were using.

The right answer is to have a state tracker that knows the current state, and some combination of object/pass/material know the state intended to switch to.

And gl.BLEND is the easy case. Things like VAOs and FBOs are dangerous to have bound latently, because of GL's brutal bind-to-modify API design. Bind-to-modify was optionally dropped when EXT_direct_state_access was added, but that never made its way to GLES/WebGL, unfortunately.

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

#53

Post by dwaite »

bowsamic wrote: post #47
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)…

> WebGL (and OpenGL) are awful APIs that can give you a very backwards impression about how to use them, and are very state-sensitive. It is not your fault for getting stuck here. Basically one of the first things everybody does is build a sane layer on top of OpenGL; if you are using gl.enable(gl.BLEND) in your core render loop, you have basically already failed. I really don't understand this. Why the need for rele…

(Based a bit on older OGL usage)

> I really don't understand this. Why the need for relentless abstraction? Just learn the ways that OpenGL is weird and use it anyway. Most people who work on these things will need to understand OpenGL anyway.

OpenGL/WebGL have a global state that affects drawing and which introduces side effects. Direct-written drawing code tends to make assumptions, which then makes it blow up when drawing code next to it makes different assumptions.

The API abstraction means you don't really know how expensive it is to make state changes.

So you tend to have either a thin abstraction that manages to set states appropriately for all your drawing code before use, flushing prior state, or you build a full local state manager that understands the 'delta' between old and new state.

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

#54

Post by pythops »

hutzlibu wrote: post #22
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

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.

yes I did, and I loved it that's why I shared it here :)
Post reply on HN