I meant to compare abstract-ish stuff (like these monkeys) vs actual low-level within the GPU realm, i.e. thinking in GPU architecture terms. E.g. appropriately

I meant to compare abstract-ish stuff (like these monkeys) vs actual low-level within the GPU realm, i.e. thinking in GPU architecture terms. E.g. appropriately choosing a workgroup[0] size, optimizing your buffer layouts for specific access patterns, knowing when and how to read/write from/to VRAM, when to (or if) split into multiple stages, etc. I see space for abstractions over this mess of complexity[1] but there's not a lot of room for simplification. It's almost like thinking in bare-metal terms but the GPU driver is your interface (and the browser's sandbox of course). Although WGSL is not low-level itself (in the sense that you're not writing SPIR-V) that's for a good reason because it needs to be portable and each vendor does their own things so it's often hardware dependent. Going native will still help with performance AFAIK (the aforementioned sandbox has a cost for example) but I agree with you. I love the web as a platform. [0] https://gpuweb.github.io/gpuweb/wgsl/#compute-shader-workgroups https://gpuweb.github.io/gpuweb/wgsl/#compute-shader-workgro... [1] https://developer.chrome.com/docs/capabilities/web-apis/gpu-compute#commands-submission https://developer.chrome.com/docs/capabilities/web-apis/gpu-...