Hacker News Reader

Comment by flohofwoe | Hacker News Reader

WGPU (https://wgpu.rs/) is one of currently three implementations of the WebGPU specification (the other two being Google's Dawn library used in Chrome, and the implementation in WebKit used in Safari).

The main purpose of WebGPU is to specify a 3D API over the common subset of Metal/D3D12/Vulkan features (e.g. doing an 'on-the-fly translation' of WebGPU API calls to Metal/D3D12/Vulkan API calls, very similar to how (a part of) Proton does an on-the-fly translation of the various D3D API versions to Vulkan.

View on HN

You're describing the WebGPU spec and its different implementations.

OP claimed WGPU had native support for VK, DX and others. But as far as I know, WGPU just supports WebGPU being translated on the fly to those other backends, with the obvious performance hit. If I'm wrong, I'd be interested to know, as this would make WGPU a more interesting choice for many if, in reality, the code was native instead of translation.

Edit: https://docs.rs/wgpu/latest/wgpu/#backends it seems they indeed support native code in almost every backend?

I don't understand the question...

Those three WebGPU implementation libraries are compiled to native code (they are written in Rust or C/C++), and at least WGPU and Dawn are usable as native libraries outside the browser in regular native apps that want to use WebGPU as a cross-platform 3D API.

Yet still, those native libraries do a runtime translation of WebGPU API calls to DX/Vk/Metal API calls (and also a runtime translation of either WGSL or SPIRV to the respective 3D backend API shading languages) - in that sense, quite similar to what Proton does, just for a different 'frontend API'.

Then performance of WGPU will always be problematic, below that of the native APIs (DX, vk and Metal), and constrained within the limits of the WebGPU spec.

Within the constrains of the browser sandbox and 10 year old hardware, which is when its design started.

I think it's more about low-end mobile GPUs which WebGPU needs to support too (which is also the main reason why Vulkan is such a mess). The feature gap between the low- and high-end is bigger than ever before and will most likely continue to grow.

I am yet to see anyone deliver in WebGL something at the level of Infinity Blade that Apple used to demo OpenGL ES 3.0 capabilities of their 2011 iPhone model, a mobile phone GPU from almost 15 years ago.

Unless we are talking about cool shadertoy examples.

That's more a business problem than a technical problem. Web games are in a local maximum of minimal production cost (via 2D assets) versus maximized profits (via free-2-play), and as long as this works well there won't be an Infinity Blade because it's too expensive to produce.

Yeah, but then what do we want this technology for, besides visualisations and shadertoy demos?

Streaming solves the business case, with native APIs using server side rendering.

At least it breaks up a chicken-egg problem, and the most interesting use cases are the ones that nobody was expecting anyway.

> Streaming solves the business case, with native APIs using server side rendering.

And yet history is littered with the dead husks of game streaming services ;)

The chicken egg problem caused by killing Flash games, and that nowadays no one cares about the browser, because everyone doing Flash moved into mobile phones or Steam, with better APIs?

Game Pass, GeForce Now, are doing alright.

Stadia failed, because Google doesn't get games industry.

Tiny Glade? https://store.steampowered.com/app/2198150/Tiny_Glade/

Where is the URL for the game on the browser?

Tiny Glade is Vulkan, not WebGPU. Not sure which library though

Try this Unreal Engine 5 WebGPU demo: https://play.spacelancers.com/

Demo, not game.

Shadertoy is full of impressive demos.

Reply on news.ycombinator.com