GPU compute in the browser at the speed of native: WebGPU marching cubes
1–10 of 55 posts
Re: GPU compute in the browser at the speed of native: WebGPU marching cubes
#2You 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.
Re: GPU compute in the browser at the speed of native: WebGPU marching cubes
#3You 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.
This is the eternal browserbros. attempt to make us think native has zero value now that we have a completely captured and bloated browser.
The browser is dead, the only thing you can use it for is filling out HTML forms and maybe some light inventory management.
The final app is C+Java where you put the right stuff where it is needed. Just like the browser used to be before Oracle did it's magic on the applet.
Re: GPU compute in the browser at the speed of native: WebGPU marching cubes
#4You 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.
shhh... you might cause their reality distortion field to fail!
Re: GPU compute in the browser at the speed of native: WebGPU marching cubes
#5You 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.
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.
Re: GPU compute in the browser at the speed of native: WebGPU marching cubes
#6You 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.
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.
Re: GPU compute in the browser at the speed of native: WebGPU marching cubes
#7You 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.
shhh... you might cause their reality distortion field to fail!
The demo doesn't work on mobile Chrome. Worse, the blog post crashes the embedded browser in the HN app. May I suggest just linking to the demo instead?
Re: GPU compute in the browser at the speed of native: WebGPU marching cubes
#8You 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.
This is the eternal browserbros. attempt to make us think native has zero value now that we have a completely captured and bloated browser. The browser is dead, the only thing you can use it for is filling out HTML forms and maybe some light inventory management. The final app is C+Java where you put the right stuff where it is needed. Just like the browser used to be before Oracle did it's magic on the applet.
So you're telling me you write Java professionally?
Re: GPU compute in the browser at the speed of native: WebGPU marching cubes
#9Earlier quoted context omitted.
This is the eternal browserbros. attempt to make us think native has zero value now that we have a completely captured and bloated browser. The browser is dead, the only thing you can use it for is filling out HTML forms and maybe some light inventory management. The final app is C+Java where you put the right stuff where it is needed. Just like the browser used to be before Oracle did it's magic on the applet.
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.
Re: GPU compute in the browser at the speed of native: WebGPU marching cubes
#10Earlier quoted context omitted.
This is the eternal browserbros. attempt to make us think native has zero value now that we have a completely captured and bloated browser. The browser is dead, the only thing you can use it for is filling out HTML forms and maybe some light inventory management. The final app is C+Java where you put the right stuff where it is needed. Just like the browser used to be before Oracle did it's magic on the applet.
So you're telling me you write Java professionally?
It's pretty much the only professional language you can write.
If you consider respect and responsibility.