Skip to content

Disallow mixing command encoding APIs #8373

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Merged
cwfitzgerald merged 1 commit into from
Oct 22, 2025
Merged

Disallow mixing command encoding APIs #8373

cwfitzgerald merged 1 commit into from
Oct 22, 2025

Conversation

@andyleiserson
Copy link
Contributor

@andyleiserson andyleiserson commented Oct 17, 2025 •
edited
Loading

Follow-up to #8220. @Vecvec pointed out that the behavior when mixing calls to the two APIs was changed by that PR. Since we don't have any tests for behavior when mixing the APIs, and don't know of use cases, it seems simplest to disallow it entirely.

Testing
Adds wgpu-validation tests.

Squash or Rebase? Squash

Checklist

  • Run cargo fmt.
  • Run taplo format.
  • Run cargo clippy --tests. If applicable, add:
    • --target wasm32-unknown-unknown
  • Run cargo xtask test to run tests.
  • Adds a CHANGELOG.md entry.

cwfitzgerald
cwfitzgerald approved these changes Oct 17, 2025
View reviewed changes
Copy link
Member

@cwfitzgerald cwfitzgerald left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice, thanks for the tests! This honestly makes things a lot less complicated with encoding.

@andyleiserson
Copy link
Contributor Author

andyleiserson commented Oct 20, 2025 •
edited
Loading

I think that raw encoding may be broken since the encode-on-finish changes and fixed by this change, because of the assertion I added in CommandEncoderStatus::finish that the encoder has not yet been opened. That is the case for wgpu encoding, but not for raw encoding. Possibly we want to backport some form of this:

https://github.com/gfx-rs/wgpu/pull/8373/files#diff-1fe34f06c0c0bd67a41a9cb8aa26cae0a2a4b58028ce5e064abb6f8ad23b84cfR367-R371

CC @Vecvec

@Vecvec
Copy link
Contributor

Vecvec commented Oct 20, 2025

Possibly we want to backport some form of this

I think that that probably should be backported (especially since it is fairly early in the release cycle).

Should I also review this?

@andyleiserson
Copy link
Contributor Author

andyleiserson commented Oct 20, 2025

@Vecvec

Should I also review this?

If you have a minute to study whether the doc comment changes I made on mark_acceleration_structure_built makes sense, that would be useful. Other than that, I don't think you need to review the rest of it, IMO it pretty straightforwardly does what the title says. If you have test cases for raw encoding that I could use to check whether it is working on the v27 branch and on trunk, that would be useful.

@Vecvec
Copy link
Contributor

Vecvec commented Oct 20, 2025

It definitely is broken on v27, it hits assertion failed: !inner.encoder.is_open in my tests.

@andyleiserson andyleiserson mentioned this pull request Oct 20, 2025
Merged
6 tasks
@cwfitzgerald cwfitzgerald self-assigned this Oct 22, 2025
@cwfitzgerald cwfitzgerald merged commit d575c02 into gfx-rs:trunk Oct 22, 2025
41 checks passed
@andyleiserson andyleiserson deleted the push-wwumxlspmtzv branch October 22, 2025 15:46
This was referenced Dec 25, 2025
Merged
Merged
alice-i-cecile pushed a commit to bevyengine/dlss_wgpu that referenced this pull request Jan 16, 2026
@ChristopherBiscardi @JMS55
wgpu 28 (#17)
56c158f 
~currently broken, caused by gfx-rs/wgpu#8373

---------

Co-authored-by: JMS55 <47158642+JMS55@users.noreply.github.com>
github-merge-queue bot pushed a commit to bevyengine/bevy that referenced this pull request Jan 22, 2026
@ChristopherBiscardi @robtfm
Upgrade to wgpu 28 (#22265)
543b305 
Upgrade to wgpu 28

> [!important]
> This can't merge until bevyengine/naga_oil#132
does, and the dependency is updated from my fork to the release.
> 
> Also requires wgpu 28 in dlss_wgpu:
bevyengine/dlss_wgpu#17

> [!note]
> This does not enable mesh shaders, and neither does the naga_oil PR. I
chose to do an upgrade first, then go back and see about mesh shaders.

Here's a general list of changes and what I did. Commits are grouped by
feature except for the last one, which enabled solari when I ran the
solari example.

## MipmapFilterMode is split from FilterMode

- Split MipmapFilterMode from FilterMode #8314:
gfx-rs/wgpu#8314

solution: implement From for `MipmapFilterMode`/`ImageFilterMode` since
the values are the same. The split was because the spec indicates they
are different types, even though they have the same values.

## Push Constants are now Immediates

- gfx-rs/wgpu#8724

immediate_size is [a
u32](https://docs.rs/wgpu/28.0.0/wgpu/struct.PipelineLayoutDescriptor.html#structfield.immediate_size)
so use that instead of `PushConstantRange`

## Capabilities name changes

- gfx-rs/wgpu#8671

Got new list from
https://github.com/gfx-rs/wgpu/blob/trunk/wgpu-core/src/device/mod.rs#L449
and copied it in.

## subgroup_{min,max}_size moved from Limits to AdapterInfo

- gfx-rs/wgpu#8609

Update the limits to have the fields they have now, mirror the logic
from the other limits calls.

## multiview_mask

- gfx-rs/wgpu#8206

set to None because we don't use it currently. Its vaguely for VR.

## error scope is now a guard

- gfx-rs/wgpu#8685

retain guard and then pop() it later


---

I made one mistake during the PR, thinking set_immediates was going to
be the size of the immediates and not the offset. I'd like reviewers to
take a look at immediates offset and size sites specifically just in
case I missed something.

Here's a bunch of examples running

<img width="1470" height="1040" alt="screenshot-2025-12-24-at-16 47
22@2x"
src="https://github.com/user-attachments/assets/83dcf4c8-69f5-480a-b724-86598530f25a"
/>
<img width="1470" height="1040" alt="screenshot-2025-12-24-at-16 48
44@2x"
src="https://github.com/user-attachments/assets/46d897fa-1ab2-44ef-8055-fe2fce740dbc"
/>
<img width="1470" height="1040" alt="screenshot-2025-12-24-at-16 49
10@2x"
src="https://github.com/user-attachments/assets/6ae7a9bf-0473-4800-8dfc-233a6a41d6df"
/>
<img width="1470" height="1040" alt="screenshot-2025-12-24-at-16 49
31@2x"
src="https://github.com/user-attachments/assets/89f84a26-cfbd-4196-bca8-111c3d20ba7b"
/>


## Known Issues

> [!NOTE]
> 
> There are no current known issues. Everything previous has been
solved.

- [x] enable extensions can not be written in naga oil in a way that
allows them to be used in composed modules.

Update: this was fixed by introducing a flag in naga-oil to force
shaders to allow ray queries in composed modules when using bevy_solari.
This is temporary and will be different in WESL-future.

<details><summary>old explanation</summary>
This is blocking solari from working on nvidia (solari runs successfully
on macos m1) because it needs `enable wgpu_ray_query;`. Putting the
declaration before `#define_import_path` means it gets stripped out
(afaict), and putting it after results in

```
error: expected global declaration, but found a global directive
  ┌─ embedded://bevy_solari/scene/raytracing_scene_bindings.wgsl:3:1
  │
3 │ enable wgpu_ray_query;
  │ ^^^^^^ written after first global declaration
  │
  = expected global declaration, but found a global directive
```

</details>

- [x] dlss_wgpu mixes apis which [causes panics
now](bevyengine/dlss_wgpu#17 (comment)).

<details><summary>Previous notes as dlss_wgpu was being fixed
here</summary>

The wgpu release notes don't mention which PR this was introduced in,
only saying:

> Using both the wgpu command encoding APIs and
CommandEncoder::as_hal_mut on the same encoder will now result in a
panic.

It was caused by gfx-rs/wgpu#8373 which claimed
to not know of any use cases

> With record on finish, the actual ordering on the command buffer is
deeply counter intuitive (all as_hal would come first) and I think it
additionally was just flat out broken in some ways
> -
https://discord.com/channels/691052431525675048/743663924229963868/1453786307099758683

Possible path forward is using multiple command buffers:
https://discord.com/channels/691052431525675048/743663924229963868/1453795633503670415

</summary>

---------

Co-authored-by: robtfm <50659922+robtfm@users.noreply.github.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@cwfitzgerald cwfitzgerald cwfitzgerald approved these changes

Assignees

@cwfitzgerald cwfitzgerald

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

3 participants

@andyleiserson @Vecvec @cwfitzgerald