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

81–90 of 98 posts

Re: Point of WebGPU on Native

#81

Post by jfkebwjsbx »

mmis1000 wrote: post #74
jfkebwjsbx wrote: post #65

Earlier quoted context omitted.

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

You don't need to reset everything, only whatever you change. Yeah, other APIs allow you to keep the state pre-packaged and switch from what appears a single command, but the state is still there nevertheless.

The full sync is a problem of how WebGL is provided. They could easily change it to allow parallel rendering as long it is to independent contexts.

Re: Point of WebGPU on Native

#82

Post by kllrnohj »

jfkebwjsbx wrote: post #33
xt00 wrote: post #3

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

Because hardware vendors don't want one. Lock-in when you are leading your particular niche gives big profits, so companies go for it. That is why Microsoft, Sony, NVIDIA, Apple, Xilinx, etc. create their own platforms and APIs.

> Because hardware vendors don't want one. Lock-in when you are leading your particular niche gives big profits, so companies go for it.

Complete nonsense. All the hardware vendors except Apple support Vulkan and contributed towards it.

NVIDIA hasn't created their own graphics API since... ever, actually. They have their own APIs, of course (cuda being an obvious one, but there's also NVAPI), but they don't do graphics. Because hardware vendors have no interest or motivation in making more drivers than they need to, because drivers are hard & expensive. So much so that driver quality is a better lock-in for them.

Consoles use exclusives to drive lock-in, not APIs. Consoles have their own APIs, but historically that's always been a performance thing. They want to give game devs the rawest access they can, to make the best looking games they can. Maybe low-level APIs like Vulkan will end up changing that, maybe it won't, but it's not a "lock-in" thing. OS's use APIs to do lock-in, but they don't make hardware (Apple being the exception here, of course).

Re: Point of WebGPU on Native

#83

Post by rezmason »

jfkebwjsbx wrote: post #81
mmis1000 wrote: post #74

Earlier quoted context omitted.

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

You don't need to reset everything, only whatever you change. Yeah, other APIs allow you to keep the state pre-packaged and switch from what appears a single command, but the state is still there nevertheless. The full sync is a problem of how WebGL is provided. They could easily change it to allow parallel rendering as long it is to independent contexts.

I'd like to chime in by pointing you fine folks to http://regl.party — a functional, partial-application, "stateless WebGL" library that lets you model rendering commands as nested little scopes. It offers "the rest of us" a graphics programming foundation that's lower level than three.js, and I can't recommend it enough.

IMO, WebGL's implementation has some glaring wrinkles that REGL-like libraries can't smooth away, but at least REGL does a decent job of tackling the state problems you're discussing, while offering a more flexible approach (I think?) than the out-of-the-box WebGPU API's render pass command encoder.

Re: Point of WebGPU on Native

#84

Post by sansnomme »

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…

Another great usage option would be for GTK Broadway. Right now Broadway does not support any form of OpenGL so pretty much any CAD or design tool written in GTK would not work with Broadway. It is quite a disadvantage if you are running heavy workloads on a compute cluster and have to resort to VNC/Xpra which is much, much more slower than Broadway. This is especially if you are doing instrumentation or ML work and your charting tool uses OpenGL for performance.

Fun challenge for HN: rewrite Xpra in Rust, it is currently implemented in AOT-compiled Python (Cython)

Re: Point of WebGPU on Native

#85

Post by tenaciousDaniel »

meheleventyone wrote: post #77
tenaciousDaniel wrote: post #58

Earlier quoted context omitted.

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

Love it! Looks very promising.

Re: Point of WebGPU on Native

#86

Post by peteforde »

flohofwoe wrote: post #22
peteforde wrote: post #17

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

I dunno. This is all so subjective. I don't think Day 1 of programming is about picking up programming. It's about seeing if there's going to be a Day 2-4.

And if Unity isn't in the picture, they sure as fuck aren't going to be hearing about WebGPU for the first 3-5 years of their journey.

Photoshop for game creation is a little bit loaded. I'll take it in good faith but point aggressively to how wrong you are because it's possible you just don't realize how much cutting edge engineering is being deployed.

For example, there's currently a major push towards moving everyone over to a job scheduled, burst-compiled data-driven architecture so that you can have tens of thousands of actors on screen at once. I stand by what I said about a VB6-like UI experience, but nobody is building anything real without learning a ton of C#, Quaternion math and shader language.

Re: Point of WebGPU on Native

#87

Post by eschaton »

A web page is for presenting structured text with embedded media, and optionally associated—and user-replaceable—style information.

A web page does not need direct or even indirect access to your GPU, and it does not need to run a Turing-complete language.

Re: Point of WebGPU on Native

#88

Post by mmis1000 »

jfkebwjsbx wrote: post #81
mmis1000 wrote: post #74

Earlier quoted context omitted.

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

You don't need to reset everything, only whatever you change. Yeah, other APIs allow you to keep the state pre-packaged and switch from what appears a single command, but the state is still there nevertheless. The full sync is a problem of how WebGL is provided. They could easily change it to allow parallel rendering as long it is to independent contexts.

I am not sure it is easy to change opengl to run parallelly given it all shares a global state. How do you not mess up anything when render two scene at same time if two pipeline shares the same variable but you want to fill it with different value? And if you really want to change it so hard to give pipelines standalone context. Why not use the webgpu? It seems just designed in a stateless way that I just described.

Re: Point of WebGPU on Native

#89

Post by pjmlp »

kllrnohj wrote: post #80
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 div…

Another one that doesn't understand UWP is also the future of Windows APIs.

Also as information the WIn32 sandbox model also only allows DirectX, and Microsoft way forward is to support OpenGL on top of DirectX.

https://devblogs.microsoft.com/directx/in-the-works-opencl-a...

Expect Vulkan to get a similar treatment, the OpenGL 1.1 ICD driver model won't exist forever.

Vulkan on Android is still so meaningless that the dashboard, updated this month, still doesn't show Vulkan support.

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

And then there are the game consoles.

Re: Point of WebGPU on Native

#90

Post by [deleted] »

DagAgren wrote: post #45
vetinari wrote: post #21

Earlier quoted context omitted.

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.

[deleted]
Post reply on HN