Live data from Hacker News

Point of WebGPU on Native

kvark.github.io

21–30 of 98 posts

Re: Point of WebGPU on Native

#21
post #2

> Besides, real Vulkan isn’t everywhere. More specifically, there are no drivers for Intel Haswell/Broadwell iGPUs on Windows, it’s forbidden on Windows UWP (including ARM), it’s below 50% on Android, and totally absent on macOS and iOS. Vulkan Portability aims to solve it, but it’s another fairly complex layer for your application, especially considering the shader translation logic of SPIRV-Cross, and it’s still a…

OpenGL in 2020 is basically all warts, if you want it to actually be performant at all.

AZDO is pretty nice, if you are OK that your app won't run on some devices (which include all these running macOS).

Re: Point of WebGPU on Native

#22

Most of this is "head-adjacent" for me, but there's one point where I'm confident the author is not seeing the whole forest, and that is the comparison to Unity. I'm sympathetic that someone working so hard to make WebGPU amazing would perceive the value of Unity through the lens of not having to worry about arcane device compatibility concerns. However, that's just a tiny slice of the reasons driving Unity's runaway…

That is definitely (mostly) true, but integrated engines like Unity or UE4 also heavily nudge you in doing things their way and come with a non-trivial size overhead (e.g. it is complete overkill to use Unity for your next Tetris clone).

And let's be honest, if you sit beginners in front of Unity they don't learn programming, instead they learn "Unity problem solving", e.g. "Unity trivia" which is hardly applicable to other contexts.

In my opinion, Unity is the Photoshop for game creation, you work on a very high level, but it's also very convenient (if you actually follow the rules and workflows).

But there are quite a few commercial games which use Unity only as a 'cross-platform wrapper', because their game client is more or less just a dumb input+rendering client, and the actual gameplay stuff all happens server-side.

It would be awfully nice if Unity could be split into a couple of standalone products (however that probably won't happen because it doesn't make much commercial sense):

- a low-level platform-abstraction library which contains all the driver-bug workarounds and behind-the-scene-fixes that have been accumulated over the years

- a 'bring-your-own-engine' asset pipeline and editor

- and finally, the actual Unity runtime engine, split into modules

Re: Point of WebGPU on Native

#23
post #2

> Besides, real Vulkan isn’t everywhere. More specifically, there are no drivers for Intel Haswell/Broadwell iGPUs on Windows, it’s forbidden on Windows UWP (including ARM), it’s below 50% on Android, and totally absent on macOS and iOS. Vulkan Portability aims to solve it, but it’s another fairly complex layer for your application, especially considering the shader translation logic of SPIRV-Cross, and it’s still a…

There's no Vulkan on MacOS/iOS (though there may be some 3rd party library that will translate to Metal).

While true this boils down to "Apple won't support anything it doesn't have control over", as demonstrated by them using veto power to pick WebGPU's shader language (a custom one) instead of using the shader IR literally everyone else wanted. It doesn't make a ton of sense to evaluate the success of APIs and standards this way because Apple has a long track record of refusing to implement stuff or deprecating it once they had an interest in promoting a proprietary alternative.

Re: Point of WebGPU on Native

#24
Fantastic blog, I've devoured its few articles describing the whole history of WebGPU from the WebMetal prototype in 2016 until where we are today.

It definitely got me excited for this new piece of technology.

Re: Point of WebGPU on Native

#25
post #2

> Besides, real Vulkan isn’t everywhere. More specifically, there are no drivers for Intel Haswell/Broadwell iGPUs on Windows, it’s forbidden on Windows UWP (including ARM), it’s below 50% on Android, and totally absent on macOS and iOS. Vulkan Portability aims to solve it, but it’s another fairly complex layer for your application, especially considering the shader translation logic of SPIRV-Cross, and it’s still a…

There's no Vulkan on MacOS/iOS (though there may be some 3rd party library that will translate to Metal).

MoltenVK is the most prominent Vulkan to Metal translation library. Technically, it's a 1st party library, since it's the core of the Khronos Group's Vulkan SDK on mac/iOS.

https://github.com/KhronosGroup/MoltenVK

Re: Point of WebGPU on Native

#26
post #4
post #2

> Besides, real Vulkan isn’t everywhere. More specifically, there are no drivers for Intel Haswell/Broadwell iGPUs on Windows, it’s forbidden on Windows UWP (including ARM), it’s below 50% on Android, and totally absent on macOS and iOS. Vulkan Portability aims to solve it, but it’s another fairly complex layer for your application, especially considering the shader translation logic of SPIRV-Cross, and it’s still a…

Vulkan was not well supported in android until around android 9. In android 10 I believe it can run skia using vulkan (somehow). And broadly vulkan is still in the adoption curve — so seems too early to say vulkan is failing —it’s still quite new.

Vulkan started as optional API on Android and its support is so bad outside Google and Samsung flagship devices, that with Android 10 Google made it a required API with respective OEM acceptance tests.

Yet, the numbers are so tiny that Google has yet to bother to list them on Android Dashboard,

https://developer.android.com/about/dashboards

Last update was on May 1, 2020.

Re: Point of WebGPU on Native

#27

Earlier quoted context omitted.

There's no Vulkan on MacOS/iOS (though there may be some 3rd party library that will translate to Metal).

While true this boils down to "Apple won't support anything it doesn't have control over", as demonstrated by them using veto power to pick WebGPU's shader language (a custom one) instead of using the shader IR literally everyone else wanted. It doesn't make a ton of sense to evaluate the success of APIs and standards this way because Apple has a long track record of refusing to implement stuff or deprecating it once…

[deleted]

Re: Point of WebGPU on Native

#28
post #2

> Besides, real Vulkan isn’t everywhere. More specifically, there are no drivers for Intel Haswell/Broadwell iGPUs on Windows, it’s forbidden on Windows UWP (including ARM), it’s below 50% on Android, and totally absent on macOS and iOS. Vulkan Portability aims to solve it, but it’s another fairly complex layer for your application, especially considering the shader translation logic of SPIRV-Cross, and it’s still a…

Game consoles also don't support Khronos standards.

Switch has Vulkan, but it has its own NVN, which is what middleware engines and most Switch titles actually take advantage of.

Given that Unity has shared numbers that they are responsible for 50% of the Switch titles, and there is also other middleware, there aren't many titles left.

Re: Point of WebGPU on Native

#29

Most of this is "head-adjacent" for me, but there's one point where I'm confident the author is not seeing the whole forest, and that is the comparison to Unity. I'm sympathetic that someone working so hard to make WebGPU amazing would perceive the value of Unity through the lens of not having to worry about arcane device compatibility concerns. However, that's just a tiny slice of the reasons driving Unity's runaway…

Agreed, middleware engines are the way to go.

Unity, Unreal, Xenko/Stride, CryEngine, Unigine

Re: Point of WebGPU on Native

#30

I'm really rooting for WebGPU as the "cross-platform 3D-API for the rest of us" (where "rest of us" is everybody who isn't a highly specialized rendering engineer in an AAA-game engine team). There's "one small thing" I'd like to see in WebGPU for the native use case: an optional compile-time configuration feature which allows to pass in "backend-native" shaders so that all the runtime-shader-translation code isn't n…

> where "rest of us" is everybody who isn't a highly specialized rendering engineer in an AAA-game engine team

Then you should be looking at WebGL, not WebGPU!

Post reply on HN