Point of WebGPU on Native
kvark.github.io
Point of WebGPU on Native
1–10 of 98 posts
Re: Point of WebGPU on Native
#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 WIP.
Wow. Has Vulkan failed as a standard then? I'm interested in this area but came away from the article feeling extremely confused about what the future of portable graphics programming looks like.
I know despite the hopes for WebGPU there's NWIH I will invest time learning it while everything is so up in the air.
OpenGL is great despite its warts, I've had a lot of fun programming with it over all the years.
Re: Point of WebGPU on Native
#3Sounds promising — would be great to know the history on why the other people who tried to make the one graphics api to rule them all failed? Seems like that could be helpful in the whole “learning from the past thing”.
Re: Point of WebGPU on Native
#4> 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.
Re: Point of WebGPU on Native
#5I'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 necessary.
Example size for compiling "Hello Triangle" on macOS before and after stripping, both using the Metal backend:
- with sokol-gfx: 95 KB, 91 KB
- with Google Dawn: 5.2 MB, 4.0 MB
I bet that most of that 4 MB overhead is coming from the integrated shader validation and translation code. I haven't tested with wgpu-native, but I guess the size overhead will be similar.
Since native applications don't need the strict shader validation of the web platform, this probably would also speed up pipeline creation a bit :)
PS: clarification, the executable size for Dawn is also using sokol-gfx but using its new WebGPU backend and statically linked against Dawn (which in turn is using its own Metal backend), so not a 'Hello Triangle' built directly on top of the webgpu.h API. The size difference should be negligible though (at most a few Kbytes more).
Re: Point of WebGPU on Native
#6[deleted]
Re: Point of WebGPU on Native
#7Web and client-side WebAPI has security first in mind. The conception of WASM and WebGPU is pushing Web into wider audiences and influence, taking up what used to be OS' market.
On the OS side, Google the capability-based OS Fuchsia. Someone in Google understands that user's consent over their computation resource (file/directory, network) is more important than ever.
And then there's WASI where it will enable OS to directly host WASM while allowing controllable gates over computation resources. WASI might be an important endeavor in the future and I think WebGPU design should have WASI in mind.
Those may have conflicts of space and market in the future, but all are moving into the same interest, the balance of user's consent over resources, security, and performance. It seems these standards are in good hands.
Re: Point of WebGPU on Native
#8> 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…
TBH (and IMHO of course) both OpenGL and Vulkan aren't all that great APIs to work with.
OpenGL was a nice API up until early 2.x versions, after that the move away from the fixed-function-pipeline would have needed a clear cut instead of the gradual stacking of new features, and since then two or three other of such "clear cuts" would also have helped, similar to how each new D3D version was incompatible with the previous version (but still supported for a long time).
Vulkan had a problem right from the start that it had to wrap an explicit low-level API over very different GPU architectures. And without the "wiggle room" of more abstract APIs this ended up in a complex API and high number of vendor-specific extensions in a very short time. As a result Vulkan was already bigger and more complex right from the start than OpenGL was after two decades.
Re: Point of WebGPU on Native
#9I'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…
> 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).
I'm feeling the same way, I'm interested in getting into doing a little graphics programming as a beginner, but the whole thing does feel impenetrable.
Re: Point of WebGPU on Native
#10I'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…
> 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). I'm feeling the same way, I'm interested in getting into doing a little graphics programming as a beginner, but the whole thing does feel impenetrable.
I don't think getting into OpenGL is actually that hard. There are wrapper libraries, e.g. for Java, and tons of tutorials.
The hardest part for beginners is probably wrapping their head around the concept of the rendering pipeline, with it's various stages. Once this is settled, it becomes much clearer what the various shaders do and how they interact with each other. So I'd higly recommend spending some time to understand rendering pipelines first.