naga 28 update

[ChristopherBiscardi]

This is a working naga 28 update. I noticed some tests haven't passed (specifically cargo test --all-features) since before 0.14, so this PR doesn't attempt to make them pass.

enumerate_adaptors

instance.enumerate_adapters is async now (and available on webgpu): gfx-rs/wgpu#8230 . more details in the wgpu release notes.

ControlBarrier & MemoryBarrier

Barrier was split in two to support MemoryBarriers: gfx-rs/wgpu#7630

From the PR, it seems like falling back to ControlBarrier is fine so that's what I did.

Ray Query enable

ray queries require enable wgpu_ray_query;: gfx-rs/wgpu#8545

This doesn't currently seem to make it through, and the relevant test fails.

ImageAtomic

Image atomics were added in gfx-rs/wgpu#6706

Mesh Shaders

Mesh shaders are a major feature of wgpu 28, but I've set their fields to None here in the interest of doing an upgrade and not a feature add at the same time

https://github.com/gfx-rs/wgpu/releases/tag/v28.0.0

update: I found some time and built a wgpu mesh/task shader demo and used that to validate some of the mesh shader functionality. I've used this to successfully compile a task shader with naga-oil and run it, but there's still something missing from the mesh shader module output here.

[ChristopherBiscardi]

oh actually, cargo test --all-features doesn't pass on master and hasn't even been able to compile since 0.15. 0.14 (7031ca1) fails the test in the same way.

I'm going to back up a bit and just get cargo test to work instead.

[ChristopherBiscardi]

wgsl directive support was added in #123 and actually works for the ray queries, as long as the add_composable_module function is not used. (so a single file with all the content works)

This seems like a pattern solari actually uses at the moment, so I'm not modifying the test to make it pass, but #123 mentions that trying to make this work got complicated.

Other than that (and no actual implementation for mesh shaders) this seems like the v28 upgrade completed.

[ChristopherBiscardi]

I was able to fix the rayquery test.

for composable modules, the enable extension needs to be below the #define_import_path like this:

#define_import_path test_module

enable wgpu_ray_query;

If it is not, the error will indicate that the extension is not enabled.

called Result::unwrap() on an Err value: ComposerError { inner: WgslParseError(ParseError { message: "the wgpu_ray_query enable extension is not enabled", labels: [(Span { start: 67, end: 89 }, "the wgpu_ray_query "Enable Extension" is needed for this functionality, but it is not currently enabled.")], notes: ["You can enable this extension by adding enable wgpu_ray_query; at the top of the shader, before any other items."] }), source: Module { name: "test_module", offset: 0, defs: {} } }

[robtfm]

i think image atomic support should be added before releasing, people are probably using this already.
it shouldn't be difficult - i can try if you want.

sorry i see this is only in prune, not necessary then.

[robtfm]

doesn't build on windows, seems to be conflicting versions of the windows crate.

first error of many:

error[E0308]: mismatched types
   --> [...]\.cargo\registry\src\index.crates.io-1949cf8c6b5b557f\wgpu-hal-28.0.0\src\dx12\suballocation.rs:83:71
    |
 83 | ...ice: gpu_allocator::d3d12::ID3D12DeviceVersion::Device(raw.clone()),        
    |         ------------------------------------------------- ^^^^^^^^^^^ expected `ID3D12Device`, found `Direct3D12::ID3D12Device`
    |         |
    |         arguments to this enum variant are incorrect
    |
note: there are multiple different versions of crate `windows` in the dependency graph

cargo tree -i windows@0.58.0:

windows v0.58.0
└── gpu-allocator v0.28.0
    └── wgpu-hal v28.0.0
        ├── wgpu v28.0.0
        │   [dev-dependencies]
        │   └── naga_oil v0.21.0 (C:\Users\robfm\Documents\gamedev\lno\naga_oil)
        ├── wgpu-core v28.0.0
        │   └── wgpu v28.0.0 (*)
        └── wgpu-core-deps-windows-linux-android v28.0.0
            └── wgpu-core v28.0.0 (*)

cargo tree -i windows@0.62.2:

windows v0.62.2
└── wgpu-hal v28.0.0
    ├── wgpu v28.0.0
    │   [dev-dependencies]
    │   └── naga_oil v0.21.0 (C:\Users\robfm\Documents\gamedev\lno\naga_oil)
    ├── wgpu-core v28.0.0
    │   └── wgpu v28.0.0 (*)
    └── wgpu-core-deps-windows-linux-android v28.0.0
        └── wgpu-core v28.0.0 (*)

[robtfm]

cargo update fixed it... my bad

[robtfm]

for the wgpu_ray_query extension issue, the solution is to add the enable directive to both the module that uses it, and the top level module it's included from. this makes sense when you consider how naga oil works, it builds each module in isolation first (so it requires the directive for the module), then generates a single shader from the top containing all the includes (so it requires the directive for the top-level shader).

if we accept that as the way to do it, we don't need the extra feature.

[ChristopherBiscardi]

for the wgpu_ray_query extension issue, the solution is to add the enable directive to both the module that uses it, and the top level module it's included from. this makes sense when you consider how naga oil works, it builds each module in isolation first (so it requires the directive for the module), then generates a single shader from the top containing all the includes (so it requires the directive for the top-level shader).

if we accept that as the way to do it, we don't need the extra feature.

This works for the test, but doesn't work in practice when considering solari's real-world usage.

[robtfm]

Can you link it pls

[ChristopherBiscardi]

bevyengine/bevy#22265 under the "old explanations" for solari's enable-related issue.

In composable modules, if we put the wgsl directive before the declare it gets stripped out, and if we put it after it seems like it ends up in the final file causing other issues.

The flag is only meant as a temporary measure, since Bevy seems to be moving to wesl and this unblocks wgpu 28 by not breaking solari on ray query capable devices.

[atlv24]

why todo?

[ChristopherBiscardi]

• The tests for this module do not pass and have not passed since at least 0.14
• It is undocumented according to the README
• It is behind a non-default feature flag

As far as I'm aware, "todo" is the state of the module itself, not just these snippets.

[superdump]

If the tests that did pass still pass, and examples and bevy work on top of it then looks ok to me.

@robtfm do you want to finish a review?

[robtfm]

i made a pr to your branches (here and on the bevy wgpu pr) to make the directives work properly.

it has a couple caveats:

• enable wgpu_ray_query has to be first (above #define_import_path or #import ... or anything else)
• the directive has to be enabled for all modules including the code that needs it, e,g. if a imports b and b imports c and c uses a directive, it must be enabled in a, b and c

but it avoids the feature and works for all the extensions (wgpu_mesh_shader, wgpu_ray_query, wgpu_ray_query_vertex_return, dual_source_blending, f16, clip_distances, plus any they add in future)

[ChristopherBiscardi]

confirmed solari working in the bevy repo with the flag removal. (Happy to have the flag gone)