Live data from Hacker News

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

willusher.io

51–55 of 55 posts

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

#51
post #2

You absolutely cannot implement stream compaction “at the speed of native” as WebGPU is missing the wave/subgroup intrinsics and globally coherent memory necessary to do that efficiently as possible.

I think compilers should be smart enough to substitute group-shared atomics with horizontal ops. If it's not already doing it, it should be!

But anyways, Histogram Pyramids is a more efficient algorithm for implementing parallel scan anyways. It essentially builds a series of 3D buffers, each having half the dimension of the previous level, and each value containing the sum of the amounts in each underlying cells, with the top cube being just a single value, the total amount of cells.

Then instead of doing the second pass where you figure out what index thread is supposed to write to, and writing it to a buffer, you just simply drill down into said cubes and figure out the index at the invocation of the meshing part by looking at your thread index (lets say 1526), and looking at the 8 smaller cubes (okay, cube 1 has 516 entries, so 1100 to go, cube 2 has 1031 entries, so 69 to go, cube 3 has 225 entries, so we go to cube 3), and recursively repeat until you find the index. Since all threads in a group tend go into the same cubes, all threads tend to read the same bits of memory until getting down to the bottom levels, making it very GPU cache friendly (divergent reads kill GPGPU perf).

Forgive me if I got the technical terminology wrong, I haven't actually worked on GPGPU in more than a decade, but it's fun to not that something that I did cca 2011 as an undergrad is suddenly relevant again (in which I implemented HistoPyramids from a 2007ish paper, and Marching Cubes, an 1980s algorithm). Everything old is new again.

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

#52
post #37

Earlier quoted context omitted.

There’s an advanced setting in Safari to enable it, but I can’t say how well it works. In this instance it doesn’t.

It doesn't work at all. Doesn't even exist in Safari anymore because they ditched the old implementation and are rewriting everything.

Multiple engineers are working on adding it back: https://github.com/WebKit/WebKit/pulls?q=is%3Apr+is%3Aclosed...

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

#53
post #11
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.

Corrective upvote from me - the comment is too funny

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

#54
post #11

Earlier quoted context omitted.

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.

Corrective upvote from me - the comment is too funny

[dead]
Post reply on HN