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

51–60 of 98 posts

Re: Point of WebGPU on Native

#51

Post by kvark »

kevingadd wrote: post #47
kvark wrote: post #36

Earlier quoted context omitted.

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

I know, I was there. I also think that objection to SPIR-V wasn't completely unfounded. SPIR-V is a nice binary representation of shaders, but it has problems in the context of WebGPU adoption:

1. It's so low level that generating HLSL and MSL from it is more painful than it could be. For example, it represents branching in the form of a Control Flow Graph (which is typical for an IR). This is lower level than either a source language people would use (e.g. GLSL), or the destination backend language we need to produce (e.g. HLSL or MSL). This is unnecessary complexity for translation.

2. It has a lot of instructions, covering wide range of hardware (somewhat similar to Vulkan). In contrast, for WebGPU it would make sense to have fewer instructions for the ease of securing it and translating to other representations.

3. Friction in the features we need, vs features Khronos needs.

There is also a situation where there is no single well specified and tested textual shading language. HLSL doesn't have a spec. MSL has documentation, but not enough for a spec, and it's not portable. GLSL kinda has a few specs, but realistically it's just specified by the implementation of glslValidator.

Re: Point of WebGPU on Native

#52

Post by pjmlp »

kvark wrote: post #35
dangerbird2 wrote: post #25

Earlier quoted context omitted.

MoltenVK is the most prominent Vulkan to Metal translation library. Technically, it's a 1st party library, since it's the core of the Khronos Group's Vulkan SDK on mac/iOS. https://github.com/KhronosGroup/MoltenVK

It's not 1st party. Up to the very recent, the whole SDK was a "LunarG SDK" for a reason - it wasn't 1st party either. It's basically just somebody packing up a bunch of useful libraries together.

This is my main pain point on how Khronos deals with their APIs.

Naturally for those of us around since the ARB days it hardly matters, but for teaching beginners into 3D world, or nowadays 2D was well, those bunch of useful libraries still lack the tooling experience of proprietary APIs.

And the OEM SDKs are hardly better, because they also provide better tooling for the proprietary APIs.

So in the end it all turns out into a rite of passage for everyone, getting to know which set of useful libraries, useful GPU debugging tools are to be used.

Hence why I just advise most beginners to start with middleware and only afterwards dive into the low level details.

Hopefully WebGPU can also help there.

Re: Point of WebGPU on Native

#53

Post by gnulinux »

flohofwoe wrote: post #8
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…

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 like something an OpenGL engineer could pick up in one afternoon.

Re: Point of WebGPU on Native

#54

Post by skocznymroczny »

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…

OpenGL isn't hard, but it's API is outdated and full of surprises. Error reporting is bad (glGetError), debug context works somewhat better (error callbacks), but I had errors that reproduce on debug context only. C API is very weakly typed, so it's easy to pass GL_RGBA to a function which expects GL_RGBA8. But the worst part of OpenGL is the state machine. OpenGL is the only graphical API still remaining that has the concept of state machine, and it causes a lot of trouble when rendering. You basically have to abstract the entire state machine on your side of code, or defensively back out all state changes that you do. Modern APIs are more stateless, and state object is passed along with the drawcall, more or less, without affecting any other drawcalls in the commandbuffer.

Re: Point of WebGPU on Native

#55

Post by skocznymroczny »

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!

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.

Re: Point of WebGPU on Native

#56

Post by greggman3 »

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…

Given that any most implementations of WebGPU will be open source it should be trivial for you to add a way to use pre-compiled native shaders to whatever implementation you choose to use.

Re: Point of WebGPU on Native

#57

Post by Jasper_ »

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…

AIR is not a documented or supported endpoint. MSL is the supported endpoint. You will hear from Apple's lawyers if toy reverse engineer AIR, as one of my colleagues knows from experience.

Re: Point of WebGPU on Native

#58

Post by tenaciousDaniel »

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.

Re: Point of WebGPU on Native

#59

Post by monocasa »

Jasper_ wrote: post #57
kvark wrote: post #40

Earlier quoted context omitted.

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…

AIR is not a documented or supported endpoint. MSL is the supported endpoint. You will hear from Apple's lawyers if toy reverse engineer AIR, as one of my colleagues knows from experience.

I thought AIR was just LLVM bitcode.

Re: Point of WebGPU on Native

#60

Post by jfkebwjsbx »

pjmlp wrote: post #48
jfkebwjsbx wrote: post #34

Earlier quoted context omitted.

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.

> Except going forward, those are going to be the only APIs available

That is false. There are already library implementations of legacy OpenGL, modern OpenGL, OpenGL ES, WebGL, legacy Direct3D, Direct3D 10/11, Direct3D 12, Vulkan and others.

Major players like Microsoft, AMD, Khronos, Valve and others already depend and employ people on providing those APIs and libraries long-term.

Those APIs are not going anywhere, even if a hardware vendor decides to only provide a low-level one (which is understandable, by the way...).

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

They have never mapped to hardware, so there is no real difference between now and then.

Post reply on HN