Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Point of WebGPU on Native

kvark.github.io

Post reply on HN
Print view View original

71–80 of 98 posts

Re: Point of WebGPU on Native

#71

Post by jfkebwjsbx »

davedx wrote: 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 is fine and major games are shipping with it, but you should never expect any 3D API to become standard. Hardware and software vendors will never agree on one, at least for 10 years.

Vulkan is supported on macOS through MoltenVK, provided by Khronos.

Re: Point of WebGPU on Native

#72

Post by jfkebwjsbx »

gnulinux wrote: post #53
flohofwoe wrote: post #8

Earlier quoted context omitted.

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 pr…

I'm personally pretty comfortable with OpenCL and "old" OpenGL (i.e. using immediate point API which is deprecated now, I didn't do any graphics coding for ~a decade). But I found Vulkan impenetrable . The boilerplate code was absolute insanity. I tried to find some libraries that'll implement the boilerplate for me, but couldn't find anything good enough. Maybe I didn't look hard enough, idk, but Vulkan didn't seem…

To understand Vulkan, Metal or Direct3D 12, you first need to understand modern high-level APIs like OpenGL 4 or Direct3D 11. The fixed-function pipeline is nothing like the new way of doing things.

Then you can move to low-level ones, if you really want to spend a few weeks on it! But if it is a hobby, I suggest you stay with a high-level one.

Re: Point of WebGPU on Native

#73

Post by FpUser »

kvark wrote: post #44
FpUser wrote: post #31

The author states something like: Use XXX API and deal with bugs, incompatibilities, etc. etc. What makes him think that this new API will be free of any of things he mentions above? As far as I can see this whole high performance graphics area has always been a wasps nest of various vendors each trying to pull the blanket to their side. I doubt adding "Web" to it will make life any easier.

At some point, it comes down to the amount of momentum behind the API. In case of WebGPU, we have strong support from Intel and Apple, which are hardware vendors, as well as Google, who can influence mobile hardware vendors. We are making the specification and have resources to appropriately test it and develop the necessary workarounds. It's the quantity to quality transition that sometimes just needs to cross a cer…

"It's the quantity to quality transition that sometimes just needs to cross a certain threshold in order to succeed."

So until that happens it is still: Use XXX API and deal with bugs, incompatibilities, etc. etc. We are back to square one.

I would really love it if we have some decent multiplatform high performance graphics API (with single shader language). I would also love said API to not require one possess PhD. However looking back the last 20 years does not inspire much optimism.

Wish you luck anyways

Re: Point of WebGPU on Native

#74

Post by mmis1000 »

jfkebwjsbx wrote: post #65
skocznymroczny wrote: post #55

Earlier quoted context omitted.

No, WebGPU will be easier to use than WebGL, because it doesn't have the global state. Global state is the worst thing about OpenGL and requires a lot of code to get it under control.

WebGL is different than legacy OpenGL from 20 years ago. WebGL is pretty easy to work with. WebGPU is a low-level API is more flexible than WebGL, which means more complexity. That is why it is being introduced, after all!

However It still use global state, you need to flush state everywhere when switch scenes.

Run another filter? good, switch everything on global state. Render another scene with different texture? Set everything again.

Moreover... if you forgot to reset something after change it. You got weird bug that only happen under some specific order of operation. Because everything share a global state.

And it is full sync. A shader takes long time for render also makes your whole page non responsive, which is a pain. (open the list page of shadertoy, you will know what am I saying)

Re: Point of WebGPU on Native

#75

Post by fulafel »

davedx wrote: 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 is very successful as standards go, most never get near the coverage.

But from the early days it was clear that MS and Apple will bet on their own proprietary APIs so the current situation is not news.

Re: Point of WebGPU on Native

#76

Post by kvark »

jfkebwjsbx wrote: post #71
davedx wrote: 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 is fine and major games are shipping with it, but you should never expect any 3D API to become standard. Hardware and software vendors will never agree on one, at least for 10 years. Vulkan is supported on macOS through MoltenVK, provided by Khronos.

MoltenVK is not a Khronos product. It's a product of Brenwill Workshop that is one of the many member companies under Khronos. It moved the code under Khronos github. There is quite a few community / other companies contributions. But it's still just a library out there.

Re: Point of WebGPU on Native

#77

Post by meheleventyone »

tenaciousDaniel wrote: post #58
flohofwoe wrote: post #5

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…

I've been playing Dreams on PS4 a lot recently, and it's kind of like "game development for the rest of us". I'd love to see a Dreams-like web application that allows anyone to create and share small-scale interactive experiences. Seems like WebGPU is a step in that direction.

We're actually building something along these lines, currently in pre-alpha: https://www.dotbigbang.com

Re: Point of WebGPU on Native

#78

Post by fluffything »

kevingadd wrote: post #23
greggman3 wrote: post #20

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…

Apple created Metal waaay before Vulkan existed and moved their whole ecosystem to it before Vulkan was production ready.

While moving from OpenGL to Metal was a significant technical upgrade for them, moving all their ecosystem from Metal to Vulkan is just a lot of work for very little benefit.

But yeah, sure, maybe they are just sticking with Metal to mess around with people.

Re: Point of WebGPU on Native

#79

Post by jfkebwjsbx »

kvark wrote: post #76
jfkebwjsbx wrote: post #71

Earlier quoted context omitted.

Vulkan is fine and major games are shipping with it, but you should never expect any 3D API to become standard. Hardware and software vendors will never agree on one, at least for 10 years. Vulkan is supported on macOS through MoltenVK, provided by Khronos.

MoltenVK is not a Khronos product. It's a product of Brenwill Workshop that is one of the many member companies under Khronos. It moved the code under Khronos github. There is quite a few community / other companies contributions. But it's still just a library out there.

It is provided by Khronos in the sense that they control the repository and they provide it as a permissive, open, free license, which is the important bit for end users of Vulkan.

Whoever develops it is not really important for managers deciding on technologies to use.

Re: Point of WebGPU on Native

#80

Post by kllrnohj »

davedx wrote: 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…

> 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.

Other than MacOS/iOS Vulkan's future looks just fine.

Windows UWP has failed so incredibly hard that the Windows Store has begun allowing win32 app distribution, so what UWP supports is irrelevant. And Microsoft's game division has even given up on the Windows Store and releases their games on Steam now as well. So UWP is doubly irrelevant currently.

Intel's Skylake & newer support Vulkan 1.1 (which are 4 years old now). Not supporting Haswell/Broadwell is annoying as those do support D3D12, but that's the only API gap in Intel's lineup, and that's obviously something that's on a clock to stop mattering at some point. After all, Intel's iGPU primarily matters on laptops, and laptops tend to have a shorter lifespan than desktops as things other than the CPU show their age a lot more quickly.

The 50% on Android is also a thing that'll be solved with time. If Khronos doesn't do a new OpenGL ES, then eventually the driver priority on mobile will shift over to Vulkan as that's what benchmarks will begin prioritizing, and that's what sells hardware. Android's latency to supporting something new is incredibly long, but it does also keep moving forwards fairly reliably.

So MacOS/iOS is currently the only real question mark on Vulkan's future. But then again, Apple seems to only want Metal on their platform, which doesn't work anywhere else, so no "standard" will matter. You'll be forced onto a compatibility layer of some kind to work on Apple - be it MoltenVK, bgfx/sokol-gfx, or WebGPU. The article dresses up WebGPU as being superior because it's backed by a standard, but that's nonsense. The quality of the implementation is the only thing that matters, and bgfx/sokol-gfx already have quite the head-start there. There's no particular reason to think a couple of people on Firefox are going to be "strictly superior" to the couple of people on bgfx/sokol-gfx. Maybe WebGPU will end up better, in which case great! But it's the same basic thing as what already exists today. It's very firmly in the "compatibility layer" camp here, despite the article trying desperately to dress it up as something else. There's no driver support for it, there's no influence on hardware road-maps, etc...

So right now if you could only target a single driver API then Vulkan would cover more platforms than any other driver-native standard. Which is no small feat.

Post reply on HN