Hacker News Reader

Comment by fulafel | Hacker News Reader

It's quite late into the text that this mentions WebGPU isn't shipping yet and doesn't mention at all that the spec isn't ready. And in fact WebGL just recently got caught up in Safari to WebGL 2 many years after the spec, has new extensions getting specced and implemented all the time etc. Shiny chasing danger here vs actually shipping something.

View on HN

What I hate on the 3D Web APIs, is how out of date they happen to be.

WebGL 2.0 is locked into OpenGL ES 3.0, when they rebooted work to finally catch up with OpenGL ES 3.1 set of APIs, and already existing protoytpe from Intel[0] for compute, Google dropped their support for WebGPU because anyone that cares should migrate to WebGPU instead [1]. Two years later still no WebGPU.

So WebGL 2.0 is stuck in what we could consider iPhone 5S 3D capabilities, with no known game that is capable of matching Infinity Blade 3 [2].

In similar vein when WebGPU finally comes out this year (they were targeting 2022), we will have an API designed as MVP 1.0, with the capabilities from Metal/DirectX 12/Vulkan when they were at version 1.0 in 2015, while asking everyone to rewrite their GLSL shaders into WGSL.

No wonder that with fast Internet connections, game studios are more interested into adopting pixel streaming technologies using latest 3D APIs than investing into pure Web technologies.

Usually the community talks are all about 3D models for ecommerce shops, tile rendering for online maps and the return of Flash like tooling.

Something like Nanite or mesh shaders on WebGPU? It will never happen.

[0] - https://registry.khronos.org/webgl/specs/latest/2.0-compute/ [1] - https://bugs.chromium.org/p/chromium/issues/detail?id=113199... [2] - https://www.polygon.com/2013/9/10/4715534/infinity-blade-3-c...

If mobile support is important, the Vulkan 1.0 feature set is basically all you can hope for unfortunately, with or without WebGPU inbetween.

For WebGPU it was the right decision to select the base feature set for the biggest possible reach. Desktop-GPU extensions can still be added on top when the need arises.

Android Baseline profile is Vulkan 1.1.

Just like it happened with WebGL, I bet WebGPU will stay at 1.0, and maybe around 2032 we might eventually get WebGPU 2.0 with the native capabilites available 2023.

How many Android versions does this go back though? (I can only find the baseline profiles for 2021 and 2022).

The ones that matter when Vulkan became a required API on Android, Android 10 onwards.

https://source.android.com/docs/core/graphics/implement-vulk...

You are painting WebGL2 progress much more rosy than it actually is ;)

For instance the WebGL2 compute extension was put on hold exactly because WebGPU solves this better and is "just around the corner".

Didn't mean to imply WebGL2 is getting feature parity. But WebGPU for cross-browser apps is easy to beat as long as it's unfinished and bugfixed to usable state and laggard implementations caught up which can take years based on how it went with WebGL.

That's fair, but if you're looking at say, coding up many many lines of Vulkan boilerplate for a new project, it does kinda make sense to look into WebGPU

Looking into middleware is a much more sane option.

WebGPU's native libraries are essentially middleware to abstract over the common subset of Vulkan, D3D12 and Metal.

That is a wrapper library, middleware means more richer tooling and development experience.

At very minimum something like Ogre3d or Open Inventor.

...which is then often too opinionated and bloated for specific use cases. E.g. nobody in their right mind would use Unity for a simple 3D viewer application.

You would be surprised.

No one outside AAA studios cares about Vulkan, and Khronos had to come up with ANARI to try to move visualization companies out of OpenGL/DirectX into Vulkan.

Nobody in their right mind would use 'raw' Vulkan either for a simple 3D viewer. But that's exactly why thin wrapper libraries are important.

A simple 3d viewer should just use WebGL. Low level APIs are targeted at large game engine developers.

Author here, I wrote at the begining of the text that it isn't fully supported yet :)

"WebGPU was first published in mid-2021 (super new!), so it isn’t fully supported on browsers (also shows how you can enable it) yet".

My main goal is to bring this new technology into attention, I don't intend nor do I have any incentive to recommend people using it in production. Sorry if that wasn't completely clear.

What do you mean by "Published in mid-2021"? It's still in draft and is undergoing changes. From the Github repo it seems the first (presumably public) commits were in 2019: https://github.com/gpuweb/gpuweb/commit/c325725d5e2b50dcd9e5...

Edit: I imagine it comes from here: https://www.w3.org/standards/history/webgpu - the first time a working draft was published on the w3c site, instead of only at the github repo, was then. But is it a meaningful date to mention?

Don't know current status but the stated target is to ship something in April with Chrome M113

https://groups.google.com/a/chromium.org/g/blink-dev/c/VomzP...

Reply on news.ycombinator.com