WebGPU bindings are broken in 2.21.0

[smoogipoo]

Summary

As far as I can tell, the WebGPU bindings are not correctly marshalling RenderPassColorAttachment.LoadOp (and possibly others, like StoreOp).

On 2.20.0, it works as expected.

On 2.21.0, the WGPU implementation panics with:

thread '<unnamed>' panicked at src/lib.rs:1184:38:
invalid load op for render pass color attachment: 0
stack backtrace:
   0: _rust_begin_unwind
   1: core::panicking::panic_fmt
   2: core::result::unwrap_failed
   3: <core::iter::adapters::map::Map<I,F> as core::iter::traits::iterator::Iterator>::fold
   4: <alloc::vec::Vec<T> as alloc::vec::spec_from_iter::SpecFromIter<T,I>>::from_iter
   5: _wgpuCommandEncoderBeginRenderPass
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
fatal runtime error: failed to initiate panic, error 5

Steps to reproduce

Here is a minimal reproduction, which is supposed to clear the backbuffer with a magenta colour: https://gist.github.com/smoogipoo/0e248fe961cc3f42930c6091eb1bd18e

• Platform: macOS, desktop
• Framework Version: .NET Core 8
• API: WebGPU / WGPU

[Perksey]

This is due to a mismatch between the headers and the implementation in WGPU. Should be fixed by new binaries + a regen.

[smoogipoo]

Is there any schedule on releases? We're trying to implement WGPU in our project to test the viability of Silk.NET going forward and this is a blocker because the 2.20 impl appears to be causing shader/uniform validation errors (not Silk.NET's fault) which look to not be happening in 2.21.

[Beyley]

Is there any schedule on releases? We're trying to implement WGPU in our project to test the viability of Silk.NET going forward and this is a blocker because the 2.20 impl appears to be causing shader/uniform validation errors (not Silk.NET's fault) which look to not be happening in 2.21.

We try to release monthly, and its almost been a month since the last release, so if everything goes to plan, we'll try to get a release out this week

[Perksey]

Is there any schedule on releases?

So the answer to this question is very complicated and I don't think I've put this on GitHub before (only Discord) so I'll do it now. Silk.NET originally aimed to have an update every Patch Tuesday (used to be every 1st Friday before that, but this resulted in us releasing too early to get the latest of some dependencies e.g. the Vulkan headers). However, the first month we did this we discovered some generator issues that essentially rendered everything but the Khronos bindings unmaintainable except on one blessed VM image where it works correctly which is in Beyley's possession.

Essentially, libclang made some breaking changes which we are not prepared to adapt to which resulted in us abstaining from migrating to the latest ClangSharp. All was fine for a while. Then, the MSVC headers updated to prevent usage on anything but the latest clang. Not ideal. This was worsened by the fact that people's dev machines seemed to be updating at random intervals, resulting in basically all maintainers and our selfhosted CI runner being unable to regenerate anything but the Khronos bindings (which generate from XML files instead of C header files).

Beyley's VM isn't online long enough to update, and is basically what we're reliant upon atm. It's possible that we could figure out a way to get this uploaded onto Azure so it's not just Beyley's dev machine that has this VM.

As a result, we're trying to focus all maintainer effort towards 3.0. However, maintainer effort is basically non-existent. We don't have enough people for the amount of time each person can commit.

I've been working hard on our new generator, which is based on ClangSharp P/Invoke Generator (which is subject to the same breaking changes but has an easier time adapting to them due to its architecture), but this is just one part of a very large library.

So the TLDR is: supposed to be monthly, but the entire project is resting on a single person's shoulders and the effort to rectify that is also resting on a single person's shoulders. We're maintaining as much as we need to such that the library remains in a usable and recommendable state, but anything more is building on sand at this point.

This has been discussed at length in our coffee & codes and API reviews on the .NET Foundation YouTube channel.

Aside: I have other commitments starting 1st June that could possibly tie me up for 6 months, so that would reduce all maintenance effort down to just Beyley. My aim now that 3.0 OpenGL codegen is basically finished is to prototype my ideas for everything else such that the community can hopefully take over.

We're stable for now and still updating, and will aim to have a release out as soon as possible. I have a personal commitment to not let this library rot, so that's not at risk of happening, but multi-month periods of no updates wouldn't be entirely unexpected given that we tend to release once enough changes have piled up or we have users blocked on something. This would constitute the latter, and thankfully we're both in a position to make this specific blocker right at this current moment :)