merge queue: checking #10430 on trunk (0c7c121), stacked on #10719 and #10630 by mergify[bot] · Pull Request #10740 · gfx-rs/wgpu

mergify · 2026-10-26T19:55:20Z

Note

This is a merge queue draft opened by Mergify. Nobody needs to act on it.
Mergify opened it for batch printed-kouign-4bh82j of the rebase queue, to test #10430 before it merges into trunk.

What this draft tests

Mergify checks that #10430 still passes CI once combined with everything queued ahead of it. CI runs on this draft's code, built in this order:

trunk at 0c7c121
the 2 pull requests queued ahead of this batch, listed below, which bring the tip to cb23ca4
#10430, the pull request of this batch

The check is speculative: it assumes the pull requests ahead will merge, so it starts without waiting for them.

✨ Where it stands: closed

Pull request #10630 ahead in the queue was removed (reason: checks interrupted).

Follow the rebase queue in the dashboard

What happens next

Mergify closes this draft.
#10430 is still in the queue.

Tip

A red check is not necessarily caused by this batch. These checks run on a tip that also carries the commits of the 2 pull requests ahead, so a failure here can come from them as much as from #10430. See only this batch's changes.

Queued ahead of this batch

These pull requests entered the queue before this batch and are not part of it.

Metadata for CI tooling, read by mergify ci

---
all_scopes: false
checking_base_sha: cb23ca4ee0eef55230325c4f03a096967a9b873a
previous_check_retries: []
previous_failed_batches: []
pull_requests:
  - number: 10430
    scopes: []
scopes: []
...

Required conditions of queue rule rebase for merge

Required conditions to stay in the queue

Rename the `ShaderMetaData::Interface` variant to `NagaModule`, and make it a struct-like variant. Delete `ShaderMetaData::interface`, and update its call sites to use a `match` expression directly on the enum instead. This makes the use sites clearer, by making it apparent which style of module we're processing.

Slightly reorder the sites that consume `ShaderMetaData` values, so that the code for the `NagaModule` and `Passthrough` cases can be gathered into `match` statements.

Move the definitions of `ShaderMetaData` and `PassthroughInterface` from `wgpu_core::validation`, which does not use them, to `wgpu_core::pipeline`, where they are used in `ShaderModuleState`, and created.

In `wgpu_core::pipeline`, delete `ShaderMetaData` and turn `ShaderModuleState` into the equivalent enum, giving both the `NagaModule` and `Passthrough` variants their own `raw` field. Arrange for uses of `ShaderModuleState` to extract the raw `wgpu_hal` module in the `match` expression that handles the two variants. In isolation, this change looks like mere rearrangement, not a cleanup, but hopefully either way it's easy to see that it has no effect on behavior. Subsequent commits will remove `raw` from the `NagaModule` variant; this refactor will allow that to affect only the `NagaModule` `match` arms, leaving the passthrough code unaffected.

In `wgpu_core/src/device/resource.rs`, in the function `Device::create_render_pipeline_or_error_inner`, remove the leading `_` from the following local variables' names, and simply leave them uninitialized in their declaration: - `_vertex_entry_point_name` - `_task_entry_point_name` - `_mesh_entry_point_name` Rust is smart enough to see that these are always initialized before they are used, and thus don't need to be initialized at their declaration.

Gather the state that `Interface::check_stage` accumulates across all of a pipeline's stages (the bind group layouts, minimum binding sizes, and immediate data usage) into a new `PipelineResources` struct, which `check_stage` takes by `&mut`. Remove `immediates` from `StageIo`, so that `StageIo` holds only the information one stage passes to the next. Use `layout` to refer to the `BindingLayoutSource`, not `layouts`, since that value describes a single pipeline layout. In the derived case, it does hold an array of bind group layouts, but that is only one variant; the value's name should make sense regardless which variant is present.

Introduce `StageCompiler`, in the new `wgpu_core::device::stage_compiler` module, which performs the per-stage work that `create_compute_pipeline_or_error_inner` and `create_render_pipeline_or_error_inner` previously repeated for each stage: checking the shader module's validity and device, choosing the entry point, checking the stage against the module's interface, and tracking which stages were validated. `StageCompiler::compile` returns a `CompiledStage`, which borrows the module the stage should use, and records the entry point name. From this we can build a `hal::ProgrammableStage` to use when creating the hal pipeline. Have `StageCompiler::compile` reject a passthrough stage immediately if the pipeline's layout is being derived. `ImplicitLayoutError::Passthrough` now names only that stage, rather than every passthrough stage in the pipeline. Remove `ImplicitLayoutError::ReflectionError`, along with the check that reported it. The condition it was concerned with, deriving a layout from a stage we couldn't reflect, is already rejected as `ImplicitLayoutError::Passthrough`. The only way left to reach it was a bug: for mesh pipelines without a fragment stage, it expected the last stage to be a vertex stage, and so rejected them incorrectly. In this commit, `StageCompiler` only does validation, but by the end of this pull request, it will be compiling shader modules. Having its name overstate its role for one commit seems clearer than introducing everything in one commit and renaming it in the next. The comments, however, are accurate in each commit. This commit also changes compute pipelines to report errors in the same way as render pipelines: an invalid shader module is now reported as a `CreatePipelineError::Stage` error, and the shader module is checked after the pipeline layout, not before.

The WebGPU specification requires pipeline creation to validate properties of shader stages, like workgroup sizes, that may depend on the values of pipeline-overridable constants. Previously, wgpu-core validated stages using an `Interface` built from the module before overrides were applied, with results contrary to spec. Override processing was then carried out by `wgpu_hal`, after all validation had supposedly been taken care of. This commit has `create_shader_module` save the validated Naga module instead of creating a `wgpu_hal` shader module. At pipeline creation time, `StageCompiler::compile` now applies the stage's override values with `process_overrides`, validates the stage using an `Interface` built from the result, and, if that validation succeeds, returns a `CompiledStage` holding the `wgpu_hal` `ShaderModule` created from it. Dropping the `CompiledStage` destroys that module once the pipeline has been created. Since the override values have already been applied, we pass `wgpu_hal` empty sets of constants for these modules. Since the `naga::back::pipeline_constants` module is now used by `wgpu_core` rather than `wgpu_hal` backends, it can't be conditionally available based on Naga's backend features. Include it unconditionally. This change removes `Interface::finalize_entry_point_name`, since we no longer build an `Interface` at shader module creation. Instead, we choose entry points from the `naga::Module` directly. Add new tests: `tests/tests/wgpu-validation/api/overrides.rs` Fixes #9774.

samoylenkodmitry and others added 14 commits October 15, 2026 04:29

perf(metal): Copy only vertex buffer ids on pipeline switch

2f5d839

perf(metal): Share vertex buffer mappings through an Arc

a65e995

[core] Refactor ShaderMetaData use sites to use match.

c8e5014

Slightly reorder the sites that consume `ShaderMetaData` values, so that the code for the `NagaModule` and `Passthrough` cases can be gathered into `match` statements.

[core] Move ShaderMetaData, PassthroughInterface to pipeline.rs.

fdd3523

Move the definitions of `ShaderMetaData` and `PassthroughInterface` from `wgpu_core::validation`, which does not use them, to `wgpu_core::pipeline`, where they are used in `ShaderModuleState`, and created.

Update cts digest to b009414

92cf310

Merge of #10719

fc57ab0

Merge of #10630

cb23ca4

Merge of #10430

aa67b86

github-project-automation Bot added this to Triage Oct 26, 2026

github-project-automation Bot moved this to To triage in Triage Oct 26, 2026

mergify Bot closed this Oct 26, 2026

mergify Bot deleted the mergify/merge-queue/af8e25aae3 branch October 26, 2026 19:55

github-project-automation Bot moved this from To triage to Done in Triage Oct 26, 2026

Navigation Menu

Repository navigation

merge queue: checking #10430 on trunk (0c7c121), stacked on #10719 and #10630 - #10740

merge queue: checking #10430 on trunk (0c7c121), stacked on #10719 and #10630#10740
mergify[bot] wants to merge 14 commits into
trunkfrom
mergify/merge-queue/af8e25aae3

mergify Bot commented Oct 26, 2026 •

edited

Loading

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Conversation

mergify Bot commented Oct 26, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

What this draft tests

✨ Where it stands: closed

What happens next

Queued ahead of this batch

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

mergify Bot commented Oct 26, 2026 •

edited

Loading