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

21–30 of 55 posts

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

#22

Post by jsheard »

worik wrote: post #21

Exciting! But: "Error: Your browser does not support WebGPU" Sigh

Chrome and Chromelikes are still the only browsers shipping stable WebGPU, on Firefox it's behind a flag, and on Safari it's only on the TP branch. Then on Chrome it's not available on Linux yet, only Windows and Android, and only on a subset of Android GPUs.

We have a way to go yet.

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

#23

Post by littlestymaar »

pjmlp wrote: post #18
FL33TW00D wrote: post #12

Earlier quoted context omitted.

Oh look it's subgroup support landing last week: https://github.com/gfx-rs/wgpu/pull/5301

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

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

#24

Post by littlestymaar »

jsheard wrote: post #6
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.

The answer to that for any given feature is "can untrusted code be trusted with that?". Wave intrinsics are probably doable. Bindless maybe, but expect a bunch of bounds checking overhead. Pointers/BDA, absolutely not. Native libraries like wgpu can do whatever they want in extensions, safety be damned, but you're stepping outside of the WebGPU spec in that case.

What's BDA in that context, please? I can only confidently assume it's not “battle damage assessment”.

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

#25

Post by jsheard »

littlestymaar wrote: post #24
jsheard wrote: post #6

Earlier quoted context omitted.

The answer to that for any given feature is "can untrusted code be trusted with that?". Wave intrinsics are probably doable. Bindless maybe, but expect a bunch of bounds checking overhead. Pointers/BDA, absolutely not. Native libraries like wgpu can do whatever they want in extensions, safety be damned, but you're stepping outside of the WebGPU spec in that case.

What's BDA in that context, please? I can only confidently assume it's not “battle damage assessment”.

Buffer Device Address, the Vulkan name for raw pointers in shaders.

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

#26

Post by littlestymaar »

jsheard wrote: post #25
littlestymaar wrote: post #24

Earlier quoted context omitted.

What's BDA in that context, please? I can only confidently assume it's not “battle damage assessment”.

Buffer Device Address, the Vulkan name for raw pointers in shaders.

Thx

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

#30

Post by capitainenemo »

jsheard wrote: post #22
worik wrote: post #21

Exciting! But: "Error: Your browser does not support WebGPU" Sigh

Chrome and Chromelikes are still the only browsers shipping stable WebGPU, on Firefox it's behind a flag, and on Safari it's only on the TP branch. Then on Chrome it's not available on Linux yet, only Windows and Android, and only on a subset of Android GPUs. We have a way to go yet.

I was trying it out in nightly firefox, and regardless of the webgpu flags I tried, it still errored:

    Shader '' parsing error: the type of `SCAN_BLOCK_SIZE` is expected to be `u32`, but got `i32`
    10 │ @id(0) override SCAN_BLOCK_SIZE: u32 = 512;
       │                 ^^^^^^^^^^^^^^^ definition of `SCAN_BLOCK_SIZE`
Post reply on HN