Dawn, a WebGPU Implementation in C++ | Hacker News Reader

Dawn, a WebGPU Implementation in C++

dawn.googlesource.com

82 pointsgardaani29 comments

I was curious what shader language would be used for WebGPU and couldn't find an answer. From [1] it seems to be undecided for now.

[1] https://gpuweb.github.io/gpuweb/#typedefdef-gpushadercode > Note: While the choice of shader language is undecided, GPUShaderModuleDescriptor will temporarily accept both text and binary input.

I think not specifying the shader language / byte-code makes at least sense for those native WebGPU implementation libraries (of course not for the WebGPU standard itself).

For instance, currently Dawn comes with a lot of code to translate and validate SPIRV to the underlying shader languages or byte-codes. When using Dawn as a native library to get a friendlier cross-platform API over Metal, Vulkan and D3D12, it might make sense to do the shader translation offline, and feed Dawn directly with Metal and D3D12 shader bytecode. The strict validation isn't really needed in such a use case, the shader translation doesn't need to happen at run time, and the executable can be a lot slimmer.

Ideally I'd like to see both in web backend, SPIRV as base, but also have a quasi-standard textual language (might be WHLSL, I don't care, but just don't offer WHLSL as the only way to get shaders into WebGPU).

Both D3D12 and Metal allow to either feed shader bytecode to the API, or translate from shader source during run time.

Dawn, used offline, will almost certainly accept SPIR-V. Even if the WebGPU WG chooses an alternate approach, Google plans to use this internally for other projects, and I expect SPIR-V will remain a supported shader ingestion format.

WebGPU is the hot thing right now. This could be the start of a cross platform revolution; So exciting.

Yes!

Part of the cross-platform story here is an Emscripten port of webgpu.h,

https://github.com/emscripten-core/emscripten/pull/10218

So you can write an application and run it either natively (using Dawn or wgpu-native) or on the Web (as WebAssembly + JavaScript).

Genuine question from someone looking at toying with graphics programming who had never heard of WebGPU before today: does this mean I should hold off on learning WebGL? How different are the two?

If you don't have any kind of experience, you are better off starting with WebGL.

It is more beginner friendly and it is here now.

You can either start from scratch:

https://webglfundamentals.org/

Or use one of the two most developer friendly frameworks.

https://threejs.org/

https://www.babylonjs.com/

If you have zero experience in graphics, another approach is to learn about 3D software rendering in first place.

https://www.davrous.com/2013/06/13/tutorial-series-learning-...

Leave WebGPU for when you feel comfortable with 3D programming.

Thanks! I'd actually been looking for that software rendering article for a while as well and couldn't find it.

Anything that reduces Vulkan boilerplate is welcomed.

For those of us who haven't been following C++, what year's language dialect / C++ standard version is this?

Most likely Google's internal C++ coding standard.

Right, found at https://google.github.io/styleguide/cppguide.html - it doesn't really answer the question though, very "it depends" there.

From CMakeLists.txt

    set(CMAKE_CXX_STANDARD "14")

Dawn also offers a plain C API (IMHO that's much cleaner than the C++ API, but YMMV of course).

https://github.com/webgpu-native/webgpu-headers/blob/master/...

Someone write QuickJS bindings for this and we’ll have the new best game development platform!

You could just use nvk instead.

https://github.com/maierfelix/nvk

Vulkan is too low level for most people and use cases I guess. The idea is to reduce that boilerplate.

Agreed, although being able to use JavaScript already allows for more developer friendly approach than the bare bones C API.

Khronos doesn't seem interested into making Vulkan developer friendly, like Apple, Microsoft, Sony and Nintendo do with their APIs.

So it is either "build your own engine while searching for math, image loading, fonts and mesh libraries" or getting something like Unity/Unreal/Godot, which then again turns Vulkan into just yet another API to choose from thanks to being API agnostic.

The fact that WebGPU is being driven by browser engines, without Khronos contribution, is quite telling.

> The fact that WebGPU is being driven by browser engines, without Khronos contribution, is quite telling.

Officially, on paper, this is because Apple started the WG inside the W3C, since they have an ongoing legal battle with Khronos that makes them reluctant to choose them to host the WebGPU group (it was originally started there, and Apple said they couldn't do that). But some contributors from other companies have also been contributors to Khronos specifications, including Vulkan.

> Khronos doesn't seem interested into making Vulkan developer friendly, like Apple, Microsoft, Sony and Nintendo do with their APIs.

The thing that makes Vulkan more finnicky than the other options, currently, is the fact that it has to ship on mobile. And lots of mobile Android GPU vendors are basically awful. If you cut that restriction out, you can use a subset of Vulkan that is way more like than the others.

Thanks for that clarification.

Regarding Android, from the point of view of a beginner (in low level 3D) getting into Vulkan, compare how to use MetalKit or DirectTK, versus the official NDK support for Vulkan.

You get told to clone a GitHub repo, compile shaderc, go to download LunarG SDK, and this is just the beginning.

Now you still need to go get GLM, DevIL, glTF loader, write code to loader shaders, and it is finally time for getting the first triangle ready.

Whereas you get all of that from a set of IDE templates, and integrated debugging tools.

So something like WebGPU, is pretty much welcomed.

The Android development experience is a piece of garbage, but that's not Khronos's fault necessarily.

> Now you still need to go get GLM, DevIL, glTF loader, write code to loader shaders, and it is finally time for getting the first triangle ready.

MetalKit is a higher-level scene graph toolkit. I don't really think it's appropriate for Khronos to specify a higher-level scene graph (remember VRML? OpenInventor?). DirectXTK is not that either, DirectXTK is effectively a bunch of helper-ish math stuff.

If you want a higher-level scene graph toolkit, there are plenty to choose from.

I know what MetalKit and DirectXTK are.

Neither ARB or Khronos had nothing to do with VRML, OpenInventor.

Yes I do believe that it is appropriate for Khronos to specify something, specially for beginners.

I did my first GL serious application porting a particles visualization engine from NeXTSTEP into Windows, ironically what is a basic feature in any modern graphics engine.

Yet, whatever is coming out of Khronos has already changed since then, other than now we have Khronos instead of ARB and get some PDFs with overview of APIs.

It appears there is a certain culture that every beginner has to through the same rite of passage to be worthy of using Khronos APIs.

It is like only IP would be standard, and after learning how to send an ICMP package, one would need to go out and get libraries for UDP, TCP, or do their own protocol on top of IP.

Based on my interests, I tend to look at this in the opposite direction. Vulkan is the correct level of abstraction for an API targeting high performance utilization of CPU/GPU rendering/compute resources. But I don't do any web based programming (other than pushing results of large data formatting to simple forms for my office). I don't care what uses a front or back end dev finds simple or low-boiler-plate, I want maximum control with as much cross-platform portability as possible. But I do get that other developers want something different. So I'm all for Khronos staying away from WebGPU and focusing on the things I care about.

Yeah, there are both use cases. Having a low level, very flexible API and a higher level, more opinionated and probably easier to use API. Having only one doesn't cut it in my opinion. There must be two levels of use.

are there rust bindings?

Rust has its own stuff going on:

https://github.com/gfx-rs/wgpu-rs

This doesn't mean that wgpu-rs will necessarily be the choice for all rust users of course.

wgpu-rs and Dawn have already started to implement a common "webgpu-native" header (https://github.com/webgpu-native/webgpu-headers/blob/master/...) which would allow native implementations to be swapped

Discussed @ https://news.ycombinator.com/item?id=22248702 fwiw.

Reply on news.ycombinator.com