Update to wgpu-native v29.0.0.0 (includes updated headers!)

[Vipitis]

as usual... still in progress but I am happy to get into this again and enjoy my free time.

There was a release for v27 with just the header updated, but there were quite a few missing symbols etc, so that release won't really work. So one PR to do both. The headers are also now considered stable. So this might be last major update for a long while.

I will put quite a few code comments in for things I feel like could be improved in the codegen, these are also meant for discussion.

more to come, I will try to keep the commits tidy and topic, since it's quite helpful to look at the individual diffs

TODOs:

• tests green
• examples green
• mem tests green
• instance flags extras changed quite a bit
• changelog explaining the breaking changes
• copy the issue template here?
• try joined cleaned header
• the backend extras documentation needs to be updated
  • for immediates
  • the instance extras

[Vipitis]

I get test failure locally in tests_mem/test_gui_qt.py but CI seems to be happy. I am on rendercanvas main, and there were quite a few changes since. CI seems to have installed 2.6.3 so I guess it's fine. I suspect these test are outdated anyway.

[Vipitis]

apart from a new instance extra WGPUNativeDisplayHandle this should be ready.

The "combined" header is nice for avoiding code duplication and it should theoretically be faster and thinner. I haven't updated the packing or contributor instructions (you need to run codegen locally after downloading the via the script I believe). There could be other problems with people bringing in a custom lib dir etc

[Vipitis]

so the mappings point to the enums from webgpu.h which don't work correctly in wgpu-native. While the wgpu.h enums do actually work. I filed this as an upstream issue: gfx-rs/wgpu-native#596

we could adjust the codegen to use old mappings over the new mappings, or include both (but we generally strip the native prefix. Or just ignore it and wait for an upstream fix. I think it might even have worked correctly prior to this update...

[Vipitis]

even on main you can use r16unorm if you request the feature TextureFormat16bitNorm but you can't use the enum or string because they weren't mapped before. The enum value of 0x00030001 does work.

What changes here is that we now have them mapped - but that way won't work.
Plus it looks like you can't use them as render targets just yet (eventhough that should work).

As wgpu30 is releasing like this week or soon, I expect to get it with wgpu-native too with the improvements being made there. Otherwise I will find some time to clean up the old mappings so it works for us once we upgrade to v30 too

[Vipitis]

gfx-rs/wgpu-native#600 should make it easier for us

[almarklein]

Maybe the easiest path forwards is to get that merged, relese wgpu-native, and rebase on that new release. What do you think?

[Vipitis]

Either is fine.
I think the current state of the PR is as functional as it gets, there is no regression. So we could merge this here and have a good version for v29.0.0.0
The wgpu-native improvements are just simplifications and additions. I haven't tried a local build for of wgpu-native but there is a couple new things I want to test first.
I am slightly in favor of doing it in two steps, eventhough some of the changes made here will change again directly after.

So perhaps we just have a wgpu-py release after both are done?

[almarklein]

Ok, let's merge this and improve later with new upstream fixes.

I did add a commit to fix the wrong texture-format int to be selected. It involves a tweak to the codegen, which will simply not be activated once gfx-rs/wgpu-native#600 is included.

[almarklein]

16bit norm nearly working in PyGfx: pygfx/pygfx#1305.

[Vipitis]

I had a patch Similar to this which I threw away. But if this one works out, that alright from my end!