
Dawn, a WebGPU Implementation in C++ - gardaani
https://dawn.googlesource.com/dawn
======
speps
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](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.

~~~
flohofwoe
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.

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

~~~
Pete_D
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?

~~~
pjmlp
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/](https://webglfundamentals.org/)

Or use one of the two most developer friendly frameworks.

[https://threejs.org/](https://threejs.org/)

[https://www.babylonjs.com/](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-...](https://www.davrous.com/2013/06/13/tutorial-series-learning-how-
to-write-a-3d-soft-engine-from-scratch-in-c-typescript-or-javascript/)

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

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

------
pjmlp
Anything that reduces Vulkan boilerplate is welcomed.

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

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

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

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

~~~
pjmlp
You could just use nvk instead.

[https://github.com/maierfelix/nvk](https://github.com/maierfelix/nvk)

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

~~~
throwaway17_17
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.

~~~
rafaelvasco
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.

------
rough-sea
are there rust bindings?

~~~
bschwindHN
Rust has its own stuff going on:

[https://github.com/gfx-rs/wgpu-rs](https://github.com/gfx-rs/wgpu-rs)

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

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

