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

91–98 of 98 posts

Re: Point of WebGPU on Native

#91

Post by pjmlp »

fulafel wrote: post #75
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.

Missing Sony and Nintendo (Switch main API is NVN) there.

Re: Point of WebGPU on Native

#92

Post by pjmlp »

peteforde wrote: post #86
flohofwoe wrote: post #22

Earlier quoted context omitted.

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

That is a common Khronos approach to learning, one should learn everything from ground up, including hunting for libraries that handle math, images, fonts, shader loading,...

I agree with you, this is not the way to bring people up to speed with graphics programming.

Re: Point of WebGPU on Native

#93

Post by pjmlp »

kllrnohj wrote: post #82
jfkebwjsbx wrote: post #33

Earlier quoted context omitted.

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

Sony and Nintendo definitely make hardware.

Microsoft not only does not support Vulkan, ICD drivers aren't allowed in Win32 and UWP sandbox models.

NVidia designs their hardware in collaboration with Microsoft, giving first class support to DirectX, and only afterwards they port the features as extensions to Vulkan/OpenGL.

Latest two examples, Ray Tracing and MeshShaders.

Re: Point of WebGPU on Native

#94

Post by fulafel »

pjmlp wrote: post #91
fulafel wrote: post #75

Earlier quoted context omitted.

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.

Missing Sony and Nintendo (Switch main API is NVN) there.

Kind of.. Consoles always use proprietary APIs.

Re: Point of WebGPU on Native

#95

Post by flohofwoe »

peteforde wrote: post #86
flohofwoe wrote: post #22

Earlier quoted context omitted.

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

"Photoshop for game creation" in the sense of: Unity has become the standard tool for creating games, and definitely has "democratized" and standardized creating games. But with this standardization also came a loss of diversity. Just as all drawing programs more or less became Photoshop clones, all integrated game development solutions eventually became Unity clones because that's exactly what users expect nowadays.

The under-the-hood technology in Unity is definitely bleeding edge, but the user-facing workflows aren't anymore, they simply cannot "revolutionize" their workflows again as they did a decade ago, because that would alienate their own user base. Being the "industry standard" also has its downsides.

Re: Point of WebGPU on Native

#96

Post by valand »

jfkebwjsbx wrote: post #69
valand wrote: post #7

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

Capability-based systems have been a thing for decades but never took off for lack of interest and complexity. What I am missing is not a Web replacing operating systems, but better operating systems!

Non-technical users are driven to rely more and more on the web app than direct-to-OS-apps due to how easy to build they are.

> What I am missing is not a Web replacing operating systems, but better operating systems!

But, that I cannot argue.

Re: Point of WebGPU on Native

#97

Post by monocasa »

kvark wrote: post #66
raphlinus wrote: post #61

Earlier quoted context omitted.

It is, but that won't do anything about overeager lawyers.

Lawyers know how to fight corporate entities. This tech doesn't have to be a corporate product. It could be a separate community repository somewhere, used only by those native gfx/wgpu users who opt into it.

Lawyers have no problem fighting non corporate entities. If anything they thrice in that power imbalance.

Re: Point of WebGPU on Native

#98

Post by skocznymroczny »

mmis1000 wrote: post #88
jfkebwjsbx wrote: post #81

Earlier quoted context omitted.

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.

OpenGL wasn't designed with multithreading/parallel execution in mind. Before running any OpenGL call, you have to bind the application-wide context to a specific thread. Vulkan, DX12 work differently - they allow you to create command lists from separate threads, but in exchange you have to work on the synchronization yourself via semaphores and fences.
Post reply on HN