Hacker News Reader

Comment by dman | Hacker News Reader

The important question is - are the graphics and platform vendors onboard? Does webgpu sit directly on top of graphics drivers or is this just a MoltenVK/Angle style abstraction layer that abstracts away OpenGL / Vulkan / Metal? Has someone done the hard work of getting Apple onboard for using this outside the browser (ie as a Metal replacement).

View on HN

Apple (arguably) initiated the WebGPU API development effort. Surprisingly, Apple is pushing for a shader language based on Microsoft's HLSL. Some of the others are pushing for a lower-level, non-human-readable shader binary format instead (which is what Vulkan takes in).

https://webkit.org/blog/8482/web-high-level-shading-language...

Apple started opencl too, and that didn't last very long.

> Apple (arguably) initiated the WebGPU API development effort.

That's not correct as far as I'm aware. All of us (Mozilla, Google, Apple) had prototypes in the works for the new API, and WebGPU just happened to be the name of the Apple one, which we borrowed later.

Ultimately, it doesn't matter at this point. If the API is usable and popular, hardware vendors may later decide to pave the way from it directly to the driver. For now, layering on top of the existing native graphics APIs is fine.

And yes, Apple is clearly on board :)

I dont care about what API wins, but the current stalemate is very disappointing. For all its flaws OpenGL was lingua franca for the longest time, now that Apple has deprecated it, I hope it gets replaced by a single credible alternative. The current fragmentation where every platform is pushing its own graphics API is wasteful when it comes to developer productivity.

And that's why we are excited about gfx-rs in this thread.

I would be more excited if there was evidence that graphics card vendors and platform vendors were onboard. Ie some commitment that webgpu is the replacement for Vulkan / Metal / DirectX / OpenGL (with backers of each of these APIs communicating an intent to deprecate it in favor of webgpu). In this case it would be a very exciting move because the amount of entropy in the world would reduce greatly. On the other hand if webgpu is an abstract API with Vulkan/Metal/DirectX/OpenGL backends then the net entropy in the world is actually increasing and now there is one new additional thing for people to debug / port to.

Apple aren't known for collaborating on common APIs. They prefer to push NIHs everywhere they can. I suppose a common API could win, if developers would be pressuring Apple more to start following standards.

Except that in this case, Apple is the entity that actually launched the standardisation process.

Good, but they didn't do anything to help the lower level. I.e. they push Metal only and don't support Vulkan on their systems. That would require those who implement WebGPU to duplicate their work.

I've been reminded that Apple's webgpu prototype is distinct from the standardisation process. And yes, implementors get to write separate metal, vulkan, and probably directx backends.

I strongly agree. We tried really, really hard to not invent a new standard. We proposed Obsidian API based on Vulkan, and we invested into Vulkan Portability initiative...

But at the end of the day it became clear that Vulkan is simply not fit for many things, including the Web. It can't be the new lingua franca simply because it's too complex for users to pick up.

I think Vulkan is a good example that a one-size-fits-all 3D API (spanning all GPU vendors, platforms and low-/high-power GPUs) only results in a mess.

And OpenGL was a mess too to be honest, at least after 30 years of development. Vulkan started right off with an even bigger API complexity.

It might actually be a good idea to have a handful of low-level, small-ish GPU-vendor and/or platform-specific 3D-APIs, each of those is most likely less complex and has less design-compromises than Vulkan.

Reply on news.ycombinator.com