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

11–20 of 98 posts

Re: Point of WebGPU on Native

#11

Post by DagAgren »

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…

OpenGL in 2020 is basically all warts, if you want it to actually be performant at all.

Re: Point of WebGPU on Native

#12

Post by speedgoose »

mouldysammich wrote: post #9
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'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.

Yes, it's overly complex for beginners.

I wanted to play with Nvidia's real-time raytracing. They have a nice tutorial to show a triangle.

https://developer.nvidia.com/rtx/raytracing/dxr/DX12-Raytrac...

https://developer.nvidia.com/rtx/raytracing/dxr/DX12-Raytrac...

Re: Point of WebGPU on Native

#13

Post by flohofwoe »

mouldysammich wrote: post #9
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'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.

Might I shamelessly plug my sokol_gfx.h library (assuming your language of choice is C or C++). These are WASM samples written in C or C++, a link to the source code is in each sample:

https://floooh.github.io/sokol-html5/

A complete Hello Triangle fits in a single source file of about 80 lines, and the API structure of sokol-gfx is close enough to modern 3D-APIs that it also serves as a useful starting point if you want to move on to Metal, D3D12 or Vulkan (or even WebGPU) later.

Re: Point of WebGPU on Native

#14

Post by gmueckl »

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…

Sadly, OpenGL is dead for a lot of use cases.

The medium term future will certainly be competing abstraction layers over varying subsets of D3D, Metal, Vulkan, OpenGL and OpenGL ES. Libraries like bgfx and game engines lead the way. Direct programming against low level APIs is too complex for mere mortals who want to create an actual application without an army of devs just for porting their graphics rendering to different devices (e.g. Vulkan allows for tons of subtle and hard to handle variations in device behaviour and these happen in practice).

Re: Point of WebGPU on Native

#15

Post by saurik »

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 a GUI toolkit, and the only parts that are really connected to the GUI toolkit are a handful of presentation functions at the very top: the headers and libraries for OpenGL are abstract/common no matter what toolkit you are using. I want to use WebGPU in all the same contexts I use OpenGL: to do accelerated rendering operations, not merely to display graphics. I would thereby expect that I would have bindings for WebGL/WebGPU (with all of its safety/security transformations) at a lower level that can target a JavaScript engine API and then I can build whatever GUI I wanted at a higher layer. Where is the impedance mismatch in what I am thinking vs. how this always seems to be implemented?

Re: Point of WebGPU on Native

#16

Post by jameshiew »

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…

Absolutely this. I wish I had spent more time learning about the rendering pipeline before jumping into trying out so much as a "Hello Triangle" tutorial.

It's also worth getting familiar with terminology early on, because common terms in the context of graphics programming have different meanings to their common usage. e.g. I've found it helpful to think of a "vertex" first and foremost as an element of an array, which is processed SIMD-style by the "vertex shader". In most cases it is the co-ordinates of a polygon vertex, but usually with other data bundled in the element as well such as texture co-ordinates. The term "shader" seems to be used for any program that runs on the GPU, regardless of whether it does shading of any kind.

Re: Point of WebGPU on Native

#17

Post by peteforde »

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 success train. After all, if this were true, everyone would just be using ThreeJS. And don't get me wrong - ThreeJS has a massive and well-deserved user base, but few see it as a serious platform.

Unity is crushing it because they provide an almost VB6-like canvas to paint on; because they have the most outrageously comprehensive asset-store ecosystem I've seen for any platform period; and because they frequently support the cool new toys like ARKit the day that they are announced.

Unity is hands-down my favourite way to introduce day-one noobs to programming. I can take someone who has never programmed before and lead them through creating a VR experience where they can fight a giant spider with a burning sword in about an hour.

The idea to payoff pathway Unity offers someone who is deciding whether to pursue programming in real time is crazy.

Re: Point of WebGPU on Native

#18

Post by thinkloop »

This touches on apps vs. web a little. Fundamentally what's the difference between mobile apps and the web? Is one naturally faster? Smoother? More cross-platform? Better at sensors? Offline mode? Not at all, not fundamentally at least. They are both just code on a machine. Either of them can make their runtimes do whatever they like whenever they like. If the web dedicated all it's resources to performance they would be smooth as native - there is no physical law prohibiting that. And vice versa for cross-platform compatibility. The fundamental difference is philosophical. The web consortium starts with consensus and cross-platform compatibility as a core tenant, while native pumps out proprietary features. They both strive for the same point but approach from opposite ends of the spectrum. As time goes on they might converge on the same point - which philosophy will win?

Re: Point of WebGPU on Native

#19

Post by whywhywhywhy »

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…

Watching Unity progress is amazing how it is spanning out from being a game engine into a whole technology and art canvas. Pretty confident we'll be seeing Unity rendering effects in at least one Hollywood movie in the next 5 years.

Re: Point of WebGPU on Native

#20

Post by greggman3 »

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…

There's no Vulkan on MacOS/iOS (though there may be some 3rd party library that will translate to Metal).
Post reply on HN