Bring immediate api in line with spec#8724
Conversation
ce1b27b to
e20cf9b
Compare
|
Does this fix #5683 ? |
|
@JMS55 no, but I'll add that to the tracking issue. |
c52d0b8 to
7348c48
Compare
There was a problem hiding this comment.
Pull request overview
This PR brings the immediate data API (formerly known as push constants) in line with the WebGPU specification. The changes simplify the API by removing per-stage configuration in favor of a unified size, and eliminate the stages parameter from upload functions.
Key changes:
- Replaced
immediates_ranges: &[ImmediateRange]withimmediate_size: u32inPipelineLayoutDescriptor - Removed
stages: ShaderStagesparameter from allset_immediates()function calls - Renamed
IMMEDIATES_ALIGNMENTtoIMMEDIATE_DATA_ALIGNMENTthroughout the codebase
Reviewed changes
Copilot reviewed 100 out of 100 changed files in this pull request and generated 7 comments.
Show a summary per file
| File | Description |
|---|---|
wgpu/src/api/pipeline_layout.rs |
Updated descriptor to use single size field instead of ranges |
wgpu/src/api/render_pass.rs |
Simplified set_immediates API, removed stage parameter |
wgpu/src/api/render_bundle_encoder.rs |
Updated set_immediates signature |
wgpu/src/util/encoder.rs |
Updated trait definition for set_immediates |
wgpu/src/lib.rs |
Removed ImmediateRange export, renamed constant |
wgpu-types/src/lib.rs |
Removed ImmediateRange struct, renamed constant |
wgpu-core/src/binding_model.rs |
Simplified validation logic and error types |
wgpu-core/src/device/resource.rs |
Updated pipeline layout creation and validation |
wgpu-core/src/command/*.rs |
Updated command encoding to use new API |
wgpu-hal/src/*/device.rs |
Updated backend implementations for new descriptor |
wgpu-hal/src/*/command.rs |
Removed stages parameter from hal command encoders |
tests/**/*.rs |
Updated all test code to use new API |
examples/**/*.rs |
Updated all example code to use new API |
CHANGELOG.md |
Added migration guide for the API change |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
7348c48 to
ab62833
Compare
ab62833 to
a153db7
Compare
There was a problem hiding this comment.
Pull request overview
Copilot reviewed 100 out of 100 changed files in this pull request and generated no new comments.
Comments suppressed due to low confidence (1)
wgpu/src/backend/webgpu.rs:1
- Corrected spelling of 'multi_draw_indexed_indirect' to 'set_immediates' in panic message.
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
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>
Connections
#8556
Description
This brings the api in line with the spec. Notably we still do zeroing, which is not spec compliant. This will be fixed in a future change.
Diff is great.
Mac setup is a bit wasteful as we upload to all stages, even ones not part of the current pipeline, but we would have to refactor our handling of immediates quite a bit to get stage information in wgpu-hal as the set_immediate call would need to always happen after we know the pipeline we're referring to, and it's not clear to me that this is worth bothering with.
Testing
See Eye, Locally
Squash or Rebase?
COMMIT
TODO