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

41–50 of 98 posts

Re: Point of WebGPU on Native

#41

Post by grovesNL »

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…

It might be really difficult to avoid runtime shader translation without some other solution (e.g. populating pipeline caches ahead of time).

For example, to provide MSL, there needs to be assumptions about exactly which MSL version is supported, all possible values of specialization constants if the MSL version is less than 1.2, all the details of which pipeline layouts will be used at runtime, etc. and all of these also have to match the internal logic used in Dawn or wgpu.

There's some more discussion about this in gfx and wgpu, e.g. https://github.com/gfx-rs/gfx/issues/3117#issuecomment-57045...

Re: Point of WebGPU on Native

#42

Post by kvark »

jfkebwjsbx wrote: post #30
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…

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

My recent talk at Fosdem started with a rant about OpenGL/WebGL. Cant express this better still:

https://fosdem.org/2020/schedule/event/rust_webgpu/

Re: Point of WebGPU on Native

#43

Post by kangz »

saurik wrote: post #15

Is there an easy way to get Dawn or wgpu attached to v8 or SpiderMonkey without having to involve the entire rest of a web browser? I see there are a number of language bindings for wgpu in the wgpu-native repository, but surprisingly not JavaScript. I found commits placing it in servo, but I don't see why the vast majority of the API surface should be reliant on a browser :(. As an analogy, I can use OpenGL without…

Browsers are Javascript bindings to WebGPU :) But more seriously, there is a https://github.com/maierfelix/webgpu that implements node bindings for Felix's Dawn fork. The fork is close to upstream and Dawn is close to "webgpu.h" so it should be easy to repurpose.

Re: Point of WebGPU on Native

#44

Post by kvark »

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 certain threshold in order to succeed.

Re: Point of WebGPU on Native

#45

Post by DagAgren »

vetinari wrote: post #21
DagAgren wrote: post #11

Earlier quoted context omitted.

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

That is the exact thing that is "all warts". It is bending the OpenGL API far beyond its breaking point to desperately try to get it to match what the GPU actually wants.

Re: Point of WebGPU on Native

#46

Post by flohofwoe »

kvark wrote: post #40
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…

Shipping compiled shaders is a feature request that pops up from time to time in gfx-rs land [1]. So far, we have been skeptical about this. Something like a serializable pipeline cache would help, but not entirely solve the shipping binary size. Although, is it really important? "Hello Triangle" may be a few megs, but the code for shader translation is a constant addition to it, so extrapolating this 5.2Mb value is…

Yeah it will be interesting to see whether a different set of libraries for the shader translation will cut down the size a bit.

Of course in a "big" application like a 3D modeller or many games, 4..5 MB added to the exe size isn't critical, but for smaller applications it seems a bit excessive TBH.

And if there's already an offline shader compilation step in a game-engine's asset pipeline anyway, why not do the whole backend-specific shader preprocessing there as well.

Not a show-stopper of any kind of course ;)

Re: Point of WebGPU on Native

#47

Post by kevingadd »

kvark wrote: post #36
kevingadd wrote: post #23

Earlier quoted context omitted.

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…

That paints Apple in a wrong light. They agreed on the WebGPU Shading Language proposed by Google (!) (previously called "Tint"). This is something Google is interested in, as well.

It's literally in past WebGPU meeting minutes: Apple objected to SPIR-V due to disputes with Khronos. Tint is a compromise, it doesn't matter who proposed it.

"MS: Apple is not comfortable working under Khronos IP framework, because of dispute between Apple Legal & Khronos which is private. Can’t talk about the substance of this dispute. Can’t make any statement for Apple to agree to Khronos IP framework. So we’re discussing, what if we don’t fork? We can’t say whether we’re (Apple) happy with that. NT: nobody is forced to come into Khronos’ IP framework."

https://docs.google.com/document/d/1F6ns6I3zs-2JL_dT9hOkX_25...

Re: Point of WebGPU on Native

#48

Post by pjmlp »

jfkebwjsbx wrote: post #34
pjmlp wrote: post #32

Earlier quoted context omitted.

Those kind of advises would make sense if they were parallel APIs, however neither WebGL 3.0 nor OpenGL 5.0 will happen.

They say they are not making an AAA engine. They are looking for a simple way to get into graphics. They have no need for parallel, low-level APIs.

Except going forward, those are going to be the only APIs available, regardless of one is doing AAA or not.

It would be the same as using SVAlib or Allegro nowadays.

They are still there, but not longer map to existing graphics hardware.

Re: Point of WebGPU on Native

#49

Post by flohofwoe »

jfkebwjsbx wrote: post #30
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…

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

WebGL follows the OpenGL programming model, which isn't "simple" either, we just got used to it over time.

Also, there's a lot of room for sane APIs between GLES2 and Vulkan, so much room that a single "standard" 3D-API doesn't make much sense TBH since there are many different opinions on where the "sweet spot" for a 3D-API lies between ease-of-use, feature coverage and acceptable layering overhead.

Re: Point of WebGPU on Native

#50

Post by blcArmadillo »

blauditore wrote: post #10
mouldysammich wrote: post #9

Earlier quoted context omitted.

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

I agree. I recently started exploring OpenGL and found it pretty approachable. If someone is looking for a resource to help learn OpenGL, I found https://learnopengl.com/ extremely helpful.
Post reply on HN