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

31–40 of 54 posts

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

#31

Post by flohofwoe »

andrewstuart wrote: post #30
flohofwoe wrote: post #29

Earlier quoted context omitted.

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.

Because text rendering is (very) hard, and most 3D rendering people are not text rendering experts, but just want to get some text on screen even if it looks ugly. Unfortunately the browser lacks a proper layered API design with low level APIs at the bottom (like WebGL and WebGPU), medium level APIs in the middle (like text rendering and layout), and high level APIs at the top (like the DOM and CSS) - so if you want to render text in WebGL or WebGPU, you are entirely on your own.

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

#32

Post by amelius »

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?

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

#33

Post by [deleted] »

ReactiveJelly wrote: post #3

> The most popular of the next-gen GPU APIs are Vulkan by the Khronos Group, Metal by Apple and DirectX 12 by Microsoft. ... (WebGPU) introduces its own abstractions and doesn’t directly mirror any of these native APIs. Huh. I was wondering about that. Until now I just figured every "Web*" thing was browsers exposing (to JS alone) something that they already compiled in: - WebRTC is ffmpeg - Canvas is Skia - WebGL is…

[deleted]

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

#34

Post by flohofwoe »

nl wrote: post #4
ReactiveJelly wrote: post #3

> The most popular of the next-gen GPU APIs are Vulkan by the Khronos Group, Metal by Apple and DirectX 12 by Microsoft. ... (WebGPU) introduces its own abstractions and doesn’t directly mirror any of these native APIs. Huh. I was wondering about that. Until now I just figured every "Web*" thing was browsers exposing (to JS alone) something that they already compiled in: - WebRTC is ffmpeg - Canvas is Skia - WebGL is…

I think all of these are wrong. > WebRTC is ffmpeg No. WebRTC is a transport protocol for media communications. > Canvas is Skia Skia is a graphics engine you can build a Canvas implementation on top of > WebGL is ANGLE I don't know what ANGLE is, but WebGL is based on OpenGL. As this article says "WebGL’s API is really just OpenGL ES 2.0" > WebCodecs is also ffmpeg Both allow conceptually similar things (low level a…

> I don't know what ANGLE is, but WebGL is based on OpenGL

ANGLE is a GLES implementation on top of D3D9, D3D11, GL, Vulkan or Metal.

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

#35

Post by flohofwoe »

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?

D3D11, Metal and WebGPU are all pretty good in that they are much less brittle than the OpenGL programming model while still being usable by mere humans without 20 years experience of writing GPU drivers - which is pretty much what's expected to make any sense of Vulkan ;)

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

#36

Post by still_grokking »

CMCDragonkai wrote: post #20
still_grokking wrote: post #10

Earlier quoted context omitted.

> > WebTransport is QUIC > No it is an API to expose lower level parts of HTTP/3 to developers. HTTP/3 uses QUIC as a transport protocol, but it is very wrong to say it "is" QUIC. Well, that's the only thing the parent got almost right. (The rest was obvious nonsense, though. I agree.) WebTransport is of course not QUIC. But it allows to use QUIC streams almost directly . There are no "lower parts" of HTTP/3 other th…

I was looking into this but are you sure web transport will expose bidirectional binary quic streams and datagrams to the browser? If so please link so I can start hacking!

Yes, I'm quite sure this works this way. I was looking into a few implementations and the specs:

https://datatracker.ietf.org/doc/html/draft-ietf-webtrans-ov...

https://www.w3.org/TR/webtransport/

https://github.com/w3c/webtransport

https://github.com/w3c/webtransport/blob/main/explainer.md

https://github.com/aiortc/aioquic/blob/main/examples/http3_s...

WebTransport just landed in Firefox release versions and is available since some time in Chromium so it's indeed ready for hacking! :-D

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

#37

Post by flohofwoe »

pjmlp wrote: post #11
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)…

That is what I hate on Khronos APIs, it is almost a rite of passage into adulthood to create our own mini-engine on top of their APIs to make them usable. I already have my toolbox, but that doesn't mean I am fine with them being like that.

IME it almost always makes sense to wrap system APIs with your own wrapper which 'massages' the low level APIs into a (usually) much smaller API that's specialized for your use case. Gives you more wiggle room to experiment and optimize without having to rewrite large parts of your higher level code.

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

#38

Post by flohofwoe »

TazeTSchnitzel wrote: post #24
tim1994 wrote: post #16

Earlier quoted context omitted.

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).

Yeah, but the problem specifically with GL is that it is almost unpredictable what actually happens at 'draw time', because small GL state changes can be amplified into big GPU state changs.

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

#39

Post by flohofwoe »

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?

The current WebGPU spec is basically the common feature subset across desktop and mobile GPUs, and what of those hardware features are actually exposed by D3D12, Metal and Vulkan. If something is missing then it's most likely the fault of some random mobile GPU.

Such missing features might be added later via optional extensions, but the focus was to get the thing out of the door first.

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

#40

Post by TazeTSchnitzel »

flohofwoe wrote: post #38
TazeTSchnitzel wrote: post #24

Earlier quoted context omitted.

> 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).

Yeah, but the problem specifically with GL is that it is almost unpredictable what actually happens at 'draw time', because small GL state changes can be amplified into big GPU state changs.

Yeah, that's definitely an issue. Vulkan has some of the same issues, they're just moved to the pipeline creation stage.
Post reply on HN