Live data from Hacker News

WebGPU Fundamentals

webgpufundamentals.org

31–40 of 211 posts

Re: WebGPU Fundamentals

#31
post #2

I have been trying to add WebGPU support to https://www.fciv.net - however the Three.js 3D engine I'm using isn't ready for WebGPU yet, and no current browsers support WebGPU yet.

The Three.js people have been working on WebGPU support for several years now. I'm not how far they've got but there were already some cool demos a year or more ago.

Re: WebGPU Fundamentals

#32
post #19

Question for discussion: when have we reached the point where the Browser Feature-creep is too much and we say "okay, a browser probably doesn't need this"? Because after seeing WebUSB and WebGPU I think my personal limit has been reached.

Why does it bother you that browsers have many features? At this point browsers are essentially a cross-platform VM and it really seems like this trend will only accentuate in the future.

Re: WebGPU Fundamentals

#33
post #19

Question for discussion: when have we reached the point where the Browser Feature-creep is too much and we say "okay, a browser probably doesn't need this"? Because after seeing WebUSB and WebGPU I think my personal limit has been reached.

> Because after seeing WebUSB and WebGPU I think my personal limit has been reached.

Sure, but where do you draw the line really? For me, having WebUSB and WebMIDI for example is useful, I want to be able to interact with synths over MIDI in the browser, or be able to access other accessories. I also love the idea of GPU access, so my personal limit has not been reached.

Multiply this by every vendor, developer and user of every browser who contributes to the specifications, and you end up with probably 1000 different directions everyone wants to move in. How do you decide which is the right direction?

Right now, the choice you have is which browser you use. If you don't want WebUSB or WebGPU or anything else "new and fancy", choose a browser that doesn't implement those things.

Re: WebGPU Fundamentals

#34

How do I render text with GPU? Do I render text on texture with CPU and then send that texture to GPU? Do I vectorize it and draw millions of tiny triangles to approximate those vectors? It's interesting for me to explore WebGPU as a canvas for app development, but it's not obvious to me how to draw text and text is everywhere.

> Do I vectorize it and draw millions of tiny triangles to approximate those vectors That is becoming feasible, using something called mesh shaders. The millions of tiny triangles will only be created on the fly inside the GPU, you will just send the vector geometry.

This is true, but there is a lot more to the story. For one, WebGPU does not (yet) support mesh shaders, though it may later as an extension. For two, consider a glyph such as "o" that has two contours. Real triangulation generates a mesh that only generates triangles between the outer and inner contours, and mesh shaders aren't good at that. There are techniques compatible with mesh shaders (cover and stencil) that draw twice, incrementing and decrementing a winding number stored in the stencil buffer (see contrast renderer[1] for a clean modern implementation), but it does require nontrivial tracking on the CPU side, and can result in lots of draw calls to switch between the cover and stencil stages unless sophisticated batching is done. (The outer contour is drawn as a disc with winding number +1, and the inner contour is drawn as a smaller disc with winding number -1, so the inner part ends up as 0)

Compute shaders avoid all these problems and work on WebGPU 1.0 today.

[1]: https://github.com/Lichtso/contrast_renderer

Re: WebGPU Fundamentals

#35

Earlier quoted context omitted.

Eh, AFAIK the WebGPU teams for Chrome, Firefox and Safari have been working closely together. Neither Firefox nor Safari are first, but I don't expect them to be much behind either. And as far as Chrome is concerned: WebGPU support for Android "isn't existent" either so far, currently it only works on desktop.

> Neither Firefox nor Safari are first, WebGPU is literally built in top of work done by Safari and Firefox.

Apple and Mozilla were the first to have prototypes (one "inspired" by Metal, the other by Vulkan), both looked quite different from the final WebGPU spec though.

Re: WebGPU Fundamentals

#36
post #30
post #20

Earlier quoted context omitted.

I don't see a problem you don't have to use it

the more important question is whether the browser's surface area for bugs and perhaps security vulnerabilities are worth the marginal increase in features that most people might not use!

[dead]

Re: WebGPU Fundamentals

#37

Earlier quoted context omitted.

> Do I vectorize it and draw millions of tiny triangles to approximate those vectors That is becoming feasible, using something called mesh shaders. The millions of tiny triangles will only be created on the fly inside the GPU, you will just send the vector geometry.

This is true, but there is a lot more to the story. For one, WebGPU does not (yet) support mesh shaders, though it may later as an extension. For two, consider a glyph such as "o" that has two contours. Real triangulation generates a mesh that only generates triangles between the outer and inner contours, and mesh shaders aren't good at that. There are techniques compatible with mesh shaders (cover and stencil) that…

> Real triangulation generates a mesh that only generates triangles between the outer and inner contours, and mesh shaders aren't good at that.

I'm a bit confused. Can't you send the shape of O as a low res rough band (a closed wide loop) and enhance it in the mesh shader? This is how previous generation tessellation shaders and sub-division surfaces worked.

Re: WebGPU Fundamentals

#39
post #19

Question for discussion: when have we reached the point where the Browser Feature-creep is too much and we say "okay, a browser probably doesn't need this"? Because after seeing WebUSB and WebGPU I think my personal limit has been reached.

I tend to feel that way mainly towards new features that are very similar to ones that already exist. eg. WebGPU being a more advanced form of WebGL. Yes they work differently, but they generally solve the same problem.

Eventually I'd like to see WebGL deprecated, and perhaps an extension released to reimplement it. Or it could be adapted to translate calls to WebGPU, rather than having a completely separate implementation.

Is that realistic? No, of course not. Browser vendors take backwards compatibility pretty seriously, and WebGL is used on a ton of websites. Still, that'd be my preferred solution for avoiding said feature creep.

Re: WebGPU Fundamentals

#40
post #32
post #19

Question for discussion: when have we reached the point where the Browser Feature-creep is too much and we say "okay, a browser probably doesn't need this"? Because after seeing WebUSB and WebGPU I think my personal limit has been reached.

Why does it bother you that browsers have many features? At this point browsers are essentially a cross-platform VM and it really seems like this trend will only accentuate in the future.

At some point we're going to have to drop the pretense of running an operating system underneath because the browser is the operating system.
Post reply on HN