Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GPU compute in the browser at the speed of native: WebGPU marching cubes

willusher.io

Post reply on HN
Print view View original

41–50 of 55 posts

Re: GPU compute in the browser at the speed of native: WebGPU marching cubes

#41

Post by cageface »

adfm wrote: post #32
spxneo wrote: post #27

but somebody told me a while back on here that WebGPU was outdated? whats the consensus ?

WebGPU is most definitely not outdated. It's a unified interface for all things floating point. From the datacenter to the watch on your wrist. However, most folks not deep into the inner workings will ever touch it. What it does do is close the door on the App Store model. Apple already knows this, which is why we have the AVP.

Now that persistent filesystem permissions have landed the domain of apps that really need to be native desktop apps is narrower than ever:

https://developer.chrome.com/blog/persistent-permissions-for...

Re: GPU compute in the browser at the speed of native: WebGPU marching cubes

#42

Post by pjmlp »

littlestymaar wrote: post #23
pjmlp wrote: post #18

Earlier quoted context omitted.

Native extensions unusable on Web browsers don't count.

Then nothing involving WebGPU counts since it's not implemented on other browsers than Chromium and not on Linux even in Chromium… WebGPU is brand new, and the paint is still wet. It doesn't make sense to dismiss things that haven't landed in browsers yet as “unusable on the web”.

Welcome to Web standards, and Google's ChromeOS transformation of the Web, with help of many Web developers out there.

Doesn't change the fact that is a Web standard, for Web browsers.

Re: GPU compute in the browser at the speed of native: WebGPU marching cubes

#43

Post by pjmlp »

tormeh wrote: post #33
masspro wrote: post #5

Earlier quoted context omitted.

You seem knowledgeable, and I’m possibly going back into a GPGPU project after many years out of the game, so: overall do you see a good future for filling these compute-related gaps in the WebGPU API? Really I’m wondering whether wgpu is an okay choice versus raw Vulkan for native GPGPU outside the browser.

Don't know about GPGPU, but can give you a probably correct answer: Compared to "native" APIs you trade features for compatibility. It's always going to lag behind Vulkan/DX/Metal. Are you ok with excluding platforms? Vulkan/Metal/DX. If not, then I'd give wgpu a chance. Wgpu is also higher-level than Vulkan, which is borh a pro and a con.

Middleware, the portability, latest features of native APIs, and nice GPGPU tooling.

Re: GPU compute in the browser at the speed of native: WebGPU marching cubes

#44

Post by pjmlp »

pdpi wrote: post #9
teaearlgraycold wrote: post #8

Earlier quoted context omitted.

So you're telling me you write Java professionally?

Funnily enough, in a world with WASM, we might actually have Java in the backend and C in the frontend rather than vice versa as it would've been likelier in the 90s.

The irony of half world backed by VC money, trying to reinvent Erlang, Java and .NET application servers, while pretending to be innovative.

Re: GPU compute in the browser at the speed of native: WebGPU marching cubes

#45

Post by pjmlp »

spxneo wrote: post #31
ramon156 wrote: post #28

Earlier quoted context omitted.

Why would wGPU be outdated if it was in the middle of being supported for browsers?

this is what I want to know but someone said it was not suitable for running GPU powered games on here i will see if i can dig up the thread

Depends on how much GB you want to force into users browsers, plan to work around browser blacklists and deep variation in API support, and protect the game code.

There is a reason why in 2024, there is yet to exist a WebGL 2.0 game that can match Infinity Blade from 2011, the game used by Apple to demo iPhone's OpenGL ES 3.0 capabilities.

WebGPU on top of that, is Chrome only for the time being, still years away from a sound 1.0 release on Safari and Firefox.

Re: GPU compute in the browser at the speed of native: WebGPU marching cubes

#46

Post by lukan »

spxneo wrote: post #31
ramon156 wrote: post #28

Earlier quoted context omitted.

Why would wGPU be outdated if it was in the middle of being supported for browsers?

this is what I want to know but someone said it was not suitable for running GPU powered games on here i will see if i can dig up the thread

It sounds like that someone is really just "someone". And people online have lots of opinions. Not all worth reading.

But that someone probably just said, that with WebGPU you do not get the power you would have with a native feature set and this is true. So we likely won't see AAA games anytime soon in the browser. But it is definitely suitable for games in general.

Re: GPU compute in the browser at the speed of native: WebGPU marching cubes

#47

Post by littlestymaar »

pjmlp wrote: post #42
littlestymaar wrote: post #23

Earlier quoted context omitted.

Then nothing involving WebGPU counts since it's not implemented on other browsers than Chromium and not on Linux even in Chromium… WebGPU is brand new, and the paint is still wet. It doesn't make sense to dismiss things that haven't landed in browsers yet as “unusable on the web”.

Welcome to Web standards, and Google's ChromeOS transformation of the Web, with help of many Web developers out there. Doesn't change the fact that is a Web standard, for Web browsers.

It is a WIP web standard. And the spec is still evolving most things are stable at that points, but new features are still being added, like this one!).

And that's how the web works, it was the same for WebRTC which spent 2-3 years in such a state, same for MSE, etc.

Re: GPU compute in the browser at the speed of native: WebGPU marching cubes

#50

Post by junon »

spintin wrote: post #11
pdpi wrote: post #9

Earlier quoted context omitted.

Funnily enough, in a world with WASM, we might actually have Java in the backend and C in the frontend rather than vice versa as it would've been likelier in the 90s.

WASM is adding GC... recreating the wheel of the applet but without escaping the problem of javascript glue. Go is just Java without the WM. Rust is just a native compiler that creates slow programs and complains a lot.

You had me all the way up until the rust bit.
Post reply on HN