Skip to content

Reject user locations and return types for compute shaders - #10026

Open
ErichDonGubler wants to merge 3 commits into
gfx-rs:trunkfrom
erichdongubler-mozilla:reject-user-locations-for-compute-shaders/valid
Open

Reject user locations and return types for compute shaders#10026
ErichDonGubler wants to merge 3 commits into
gfx-rs:trunkfrom
erichdongubler-mozilla:reject-user-locations-for-compute-shaders/valid

Conversation

@ErichDonGubler

@ErichDonGubler ErichDonGubler commented Aug 7, 2026

Copy link
Copy Markdown
Member

Connections

Testing

Test coverage has been added to the wgsl_errors test group.

Squash or Rebase?

Rebase, please.

Checklist

  • I self-reviewed and fully understand this PR.
  • WebGPU implementations built with wgpu may be affected behaviorally.
  • Validation and feature gates are in place to confine behavioral changes.
  • Tests demonstrate the validation and altered logic works.
  • CHANGELOG.md entries for the user-facing effects of this change are present.
  • The PR is minimal, and doesn't make sense to land as multiple PRs.
  • Commits are logically scoped and individually reviewable.
  • The PR description has enough context to understand the motivation and solution implemented.

@ErichDonGubler ErichDonGubler added area: correctness We're behaving incorrectly naga Shader Translator area: naga processing Passes over IR in the middle labels Aug 7, 2026
Comment on lines +5683 to +5693
naga::valid::ValidationError::EntryPoint {
stage: naga::ShaderStage::Compute,
source: naga::valid::EntryPointError::Argument(
0,
naga::valid::VaryingError::InvalidAttributeInStage(
"location",
naga::ShaderStage::Compute
),
),
..
},

@ErichDonGubler ErichDonGubler Aug 7, 2026

Copy link
Copy Markdown
Member Author

Choose a reason for hiding this comment

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

thought: It'd be nice to have errors that actually point to the offending front-end span. I have some WGSL front-end changes that can do this, but it would be redundant with the validation added here, and I'm concerned that duplication might cause more problems than it would solve for us.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I thought we had a bug for this, but couldn't immediately find it in 30 seconds of searching.

There have been some times that I've added redundant errors in the front end to give diagnostics, but I think that's mostly when it was directly adjacent to things I had to do in the front end anyways.

Even if getting good diagnostics from validation is hard, it seems better to invest time in that than in duplicating things in the front-end.

For entrypoint errors specifically, there's hopefully not too much uncertainty about where in the code the problem occurs.

@ErichDonGubler ErichDonGubler added the type: bug Something isn't working label Aug 7, 2026
@ErichDonGubler
ErichDonGubler force-pushed the reject-user-locations-for-compute-shaders/valid branch from 480950c to 20142d0 Compare August 7, 2026 14:07

@andyleiserson andyleiserson left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Nice!

Looks like you could also enable the CTS test webgpu:shader,validation,shader_io,locations:stage_inout:*.

}
Ok(())
};
reject_location_binding(fa.binding.as_ref())?;

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

It might make sense to put this in validate_impl? That is more directly for validating bindings, and I think is already called once per binding, so the check could be simplified to something like this in the section for Binding::Location:

if self.stage == crate::ShaderStage::Compute {
    return Err(VaryingError::InvalidAttributeInStage(...));
}

if ep.stage == crate::ShaderStage::Mesh {
return Err(EntryPointError::UnexpectedMeshShaderEntryResult.with_span());
match ep.stage {
crate::ShaderStage::Vertex => {

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

nit: Since we're rewriting the lines anyways, maybe change to nt?

Comment on lines +5683 to +5693
naga::valid::ValidationError::EntryPoint {
stage: naga::ShaderStage::Compute,
source: naga::valid::EntryPointError::Argument(
0,
naga::valid::VaryingError::InvalidAttributeInStage(
"location",
naga::ShaderStage::Compute
),
),
..
},

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I thought we had a bug for this, but couldn't immediately find it in 30 seconds of searching.

There have been some times that I've added redundant errors in the front end to give diagnostics, but I think that's mostly when it was directly adjacent to things I had to do in the front end anyways.

Even if getting good diagnostics from validation is hard, it seems better to invest time in that than in duplicating things in the front-end.

For entrypoint errors specifically, there's hopefully not too much uncertainty about where in the code the problem occurs.

Comment thread CHANGELOG.md
#### DX12

- Make sure padding bytes are 0 in the destination buffer after a `copy_texture_to_buffer` when `UnrestrictedBufferTextureCopyPitchSupported` is not available. By @teoxoy in [#10005](https://github.com/gfx-rs/wgpu/pull/10005).
- Reject result types in compute shaders. By @ErichDonGubler in [#10026](https://github.com/gfx-rs/wgpu/pull/10026).

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Suggested change
- Reject result types in compute shaders. By @ErichDonGubler in [#10026](https://github.com/gfx-rs/wgpu/pull/10026).
- Reject return types on compute shader entrypoints. By @ErichDonGubler in [#10026](https://github.com/gfx-rs/wgpu/pull/10026).

I gave UnexpectedComputeShaderEntryResult a pass since EntryResult was already used by other variants, but I think matching the spec language "return type" is clearer.

@inner-daemons inner-daemons left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

One nit

ctx.validate(ep, fa.ty, fa.binding.as_ref())
.map_err_inner(|e| EntryPointError::Argument(index as u32, e).with_span())?;
match ep.stage {
nt::ShaderStage::Compute => {

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

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

This should also apply to mesh & task shaders, plus maybe some ray tracing stages.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

area: correctness We're behaving incorrectly area: naga processing Passes over IR in the middle naga Shader Translator type: bug Something isn't working

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Return types should be rejected in compute shaders User-defined locations should be rejected in compute shaders

3 participants