default value for wgpu::BufferBindingLayout::type is Uniform?

[William Candillon]

I am not sure yet if I should file a bug report, as I might be missing something.

Did the default value of `wgpu::BufferBindingLayout::type` change from Uniform to Undefined (or vice versa)? I am using Dawn Chromium/6591, and all default values from the `dawn/webgpu_cpp.h` header appear to match those in Google Chrome so far. For instance, examples from https://webgpu.github.io/webgpu-samples work out of the box.

The only discrepancy I've encountered so far is that `BufferBindingLayout::type` is Uniform by default, but in Dawn, it is Undefined.

Kind regards,

William

[Corentin Wallez]

Hey William,

This is the expected behavior, even if it doesn't match 100% what's done in JS. See my more detailed answer in your issue.

Cheers,

Corentin

--
You received this message because you are subscribed to the Google Groups "Dawn Graphics" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dawn-graphic...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/dawn-graphics/bbf1a6e4-5a86-4f7f-87ca-ca1b040322d0n%40googlegroups.com.

[William Candillon]

Thanks Corentin for the explanation. This is very sensible.
In the node binding, I couldn't find where this is handled in the interop layer.
Just out of curiosity and for us to keep symmetry in our implementation.

Kind regards,

William

[Corentin Wallez]

In the dawn.node it is handled here. IIRC interop::GPUBindGroupLayoutEntry contains a bunch of std::optional like std::optional<interop::GPUBufferBindingLayout> which cause Convert to skip the conversion if it is std::nullopt. When converting the interop::GPUBufferBindingLayout the defaulting is done for its type, and the defaulted value copied over to wgpu::BufferBindingLayout.

You mentioned your implementation. Are you implementing another JS binding layer for WebGPU on top of Dawn? Why not use dawn.node directly?

Cheers,

Corentin

[William Candillon]

Thank you for asking, Corentin :)

Unfortunately, React Native does not support NodeAPI. We didn't want
to reinvent the wheel, so we did the following:

1. We codegen the bindings from the @types/webgpu. This gives us
something very similar to interop:: (we also use C++ templates; there
are some differences here and there, but nothing too big). It looks
like generating from webidl would have been less work in the end, but
I was confused about where to find/how to process these files.
2. We are using Converter.cpp from the Node bindings. Again, there are
some small differences here and there, but overall it's the same code.
3. We did something really fun. We run our JS test suite against
Google Chrome to generate the reference results and then run it on
iOS/Android: https://x.com/wcandillon/status/1815853573583827447

So yes, we didn't use the Node binding directly, but we didn't go too
much off-script either, which I think is good. I would love to reduce
these differences as much as possible. There are probably lots of
things we could refine there.

This is how it looks: https://x.com/wcandillon/status/1817552920193237398
We will open-source it in two weeks or so.

Kind regards,

William

[Corentin Wallez]

That's a pretty cool project :D WebGPU is definitely useful in more than just Web but keeping the same API for JS in React-Native is cool!

Thanks for the answers, it makes sense. A few years ago I remember that there was some hope that Napi would become a portable API to target multiple JS engines, but it seems that it never happened. It's a bit unfortunate because now we know of at least 3 different out-of browser JS bindings for Dawn (plus a couple on wgpu-rs).

Have you considered running the full WebGPU CTS on your bindings? We do that to test dawn.node which gives us great confidence that most things are handled, and it passes most tests (with a couple known issues).

Anyways, I'm looking forward to the open-sourcing!

Cheers,

Corentin

[William Candillon]

Indeed the idea of having React Native support NodeAPI has been
floating around since a while now but as of today there was nothing we
could use there.
I would love to know about the other JS bindings for Dawn. I am only
aware of Blink and dawn.node at the moment.

I would love to run the binding against the CTS. Having a quick look
at the repo, I was confused about how I could achieve it, but I could
take a deeper look and ask questions.
We would really love to be able to do that.
Are the JS test generated from a specification file? that would be
easy for us to run. Or we really need to run some JS specific
packages? I'm very curious on how this works.

Kind regards,

William

[Corentin Wallez]

Cloudflare workers support WebGPU and have their own bindings also inspired from dawn.node from what I understand. They have the added difficulty that they use the dawn::wire remoting implementation for security purposes (we do the same in Blink), which has slight differences and some quirks compared to using dawn::native directly.

The CTS supports running in a browser, but also from the command line with the cmdline.ts entry file. I don't know anything about react native, but if require statements work (with dynamic strings), then it should be possible to use that to run the CTS in react-native. Dawn has a fancy run-cts script that spawns multiple workers with server.ts instead and uses some HTTP requests to tell the server to run some tests. That would probably be more difficult to set up with react-native but would factor out the setup cost for React-Native and navigator.gpu.

The JS tests in the CTS are handwritten to check all the statements of the WebGPU and WGSL CTS and various rendering scenarios. So you'd really need to run the JS packages.

Cheers,

Corentin