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

41–50 of 137 posts

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

#41

Post by cma »

j-pb wrote: post #26

WebGPU is a textbook case of Embrace Extend Extinguish performed by Apple to kill Kronos and SPIRV, and everybody is cheering it on. Crazy.

The whole purpose of Vulkan was an open API that could work on all vendors. I'm not sure why they based WebGPU on Metal over the Mozilla proposal. Now Apple can control the future evolution of it by saying "metal 1.X does it this way." With a Vulkan based webgpu Khronos could do the same, but their "vulkan 1.X does it this way" would have already been the result of a cross-vendor standards committee instead of from a private Apple initiative with many conflicting goals around lock-in.

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

#42

Post by techdragon »

skywal_l wrote: post #23
shadowgovt wrote: post #12

Earlier quoted context omitted.

True, but this API will make that use case simple and obvious. Given the tradeoffs, probably worth it for user agents to permission-gate it.

You can always disable hardware acceleration in your browser.

I don’t want to disable it, I want websites to have to ask permission before they get access to even more hardware resources.

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

#45

Post by danielvaughn »

raphlinus wrote: post #30
dataangel wrote: post #25

If I'm already familiar with Rust, how is WebGPU as an introduction to graphics programming if you aren't already familiar with any of the backends that it wraps? Should I try just learning Vulcan first? Is the abstraction layer just going to introduce additional confusion for a newbie?

I think one of WebGPU's greatest strengths is learning, as you can get started pretty easily, and you actually learn a modern approach to GPU. Vulkan requires a significant amount of boilerplate just to establish a connection to the GPU and set up basic resources like the ability to allocate buffers. In WebGPU, the latter is one or two lines of code. That said, there are some really nice learning resources for Vulkan…

So I just went through this process and I have to slightly disagree. I'm coming from literally no knowledge of low-level graphics programming. My most relevant experience is writing against Canvas2D, which is not relevant at all.

I first tried WebGPU, and was so overwhelmed with detail that it was nearly impossible to connect the dots. So I went back and decided to learn WebGL first. I know that it's very different, but the whole state machine thing makes it so much easier to understand, at a conceptual level, what you're trying to do.

It didn't even take that long, just a couple of weekends and I was already familiar with the basics. I'm not going to waste time trying to become super proficient, but it gives me enough context to go back and try WebGPU again.

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

#48

Post by Tojiro »

cma wrote: post #41
j-pb wrote: post #26

WebGPU is a textbook case of Embrace Extend Extinguish performed by Apple to kill Kronos and SPIRV, and everybody is cheering it on. Crazy.

The whole purpose of Vulkan was an open API that could work on all vendors. I'm not sure why they based WebGPU on Metal over the Mozilla proposal. Now Apple can control the future evolution of it by saying "metal 1.X does it this way." With a Vulkan based webgpu Khronos could do the same, but their "vulkan 1.X does it this way" would have already been the result of a cross-vendor standards committee instead of from a…

WebGPU is not based on Metal. Apple did an experiment several years back in Safari which they called WebGPU at the time. It was effectively a thin wrapper around Metal, and so that's caused some confusion, but the actual W3C WebGPU spec has nothing in common with that experiment. It's a carefully selected set of features that are feasible to run effectively on Vulkan, Metal, and D3D12 and structured to feel like a web-native API.

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

#49

Post by hutzlibu »

rektide wrote: post #38
hutzlibu wrote: post #28

Earlier quoted context omitted.

"Is the abstraction layer just going to introduce additional confusion for a newbie?" As a newbie you probably don't want to deal with WebGPU directly, but rather use (wait for) a framework, that takes care of the details.

depends on your objective, doesnt it? if you eant to learn how things work & what the fundamnetals are, im not sure that a big engine or framework "taking care of the details" is going to be as illuminating. also, from the article, some poditive reinforcement about trying WebGPU: > I got my feet wet and found that I didn’t find WebGPU significantly more boilerplate-y than WebGL, but actually to be an API I am much mo…

"depends on your objective, doesnt it? "

Sure, thats why I said "probably".

Anyone who wants the most performance and raw power needs to get to the source.

But most people using WebGPU are probably fine with a framework, that hides all the details. Like threejs did for webGL.

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

#50

Post by flohofwoe »

dassurma wrote: post #13
pjmlp wrote: post #10

With the "fun" to rewrite all WebGL shaders into WGSL.

You can use the SPIR-V compiler toolchain to just transpile from GLSL to WGSL :)

Minor nitpick: this translation happens in separate libraries/tools which just make use of the SPIRVTools library for some SPIRV processing tasks, but not the actual translation to WGSL.

Tint (Google, implemented in C++): https://dawn.googlesource.com/tint/

Naga (Mozilla(?), implemented mostly in Rust): https://github.com/gfx-rs/naga

Both are a bit similar to SPIRV-Cross, except that they also support WGSL.

Post reply on HN