Skip to content

Relax overly strict maxInterStageShaderVariables validation for fragment stage inputs #8792

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
andyleiserson merged 5 commits into from
Jan 5, 2026
Merged

Relax overly strict maxInterStageShaderVariables validation for fragment stage inputs #8792

andyleiserson merged 5 commits into from
Jan 5, 2026

Conversation

@ErichDonGubler
Copy link
Member

@ErichDonGubler ErichDonGubler commented Dec 28, 2025 •
edited
Loading

Connections

Description

Thankfully, these issues are "only" too strict. None of these caused major issues with incorrect commands getting to platforms.

Testing

CTS paths have been added.

Squash or Rebase?

rebase plz

Checklist

  • If this contains user-facing changes, add a CHANGELOG.md entry.

@ErichDonGubler ErichDonGubler added type: bug Something isn't working area: validation Issues related to validation, diagnostics, and error handling area: cts Issues stemming from the WebGPU Conformance Test Suite labels Dec 28, 2025
@ErichDonGubler ErichDonGubler changed the title Some fixes for maxInterStageShaderVariables validation Relax overly strict maxInterStageShaderVariables validation for fragment stage inputs Dec 28, 2025
ErichDonGubler added a commit to erichdongubler-mozilla/firefox that referenced this pull request Dec 31, 2025
@ErichDonGubler
Bug 2007791 - chore(webgpu): update wgpu to a2c8c0de7cdb57a74070ce70b…
a3ec9c6 
…9912e853893d502 r=#webgpu-reviewers!

Notes:

- Most changes in expected permanent outcomes are driven by migration of wgpu to the next `maxInterStageShaderVariables` limit, dropping the old `maxInterStageShaderComponents` limit.
  - Some of CTS' tests for this limit are actually incorrect, while wgpu is correct. I'm filing up (and have even landed in CTS upstream) some work to correct them. See [gpuweb/cts#4538](gpuweb/cts#4538) for more details.
  - CTS isn't entirely to blame; I did make one check for fragment built-in inputs too restrictive. This has been corrected with [wgpu#8792](gfx-rs/wgpu#8792).
- I decided to roll a `spirv` upgrade into this: 0.3.0+sdk-1.3.268.0 → 0.3.0+sdk-1.4.309.0@git:89ce4d0e64c91b0635f617409dc57cb031749a39

  …since it's only used by this, and most changes should go away after the `spirv` releases its current mainline history.

Differential Revision: https://phabricator.services.mozilla.com/D277553
lando-prod-mozilla bot pushed a commit to mozilla-firefox/firefox that referenced this pull request Jan 5, 2026
@ErichDonGubler
Bug 2007791 - chore(webgpu): update wgpu to a2c8c0de7cdb57a74070ce70b…
64788e6 
…9912e853893d502 r=webgpu-reviewers,supply-chain-reviewers,nical

Notes:

- Most changes in expected permanent outcomes are driven by migration of wgpu to the next `maxInterStageShaderVariables` limit, dropping the old `maxInterStageShaderComponents` limit.
  - Some of CTS' tests for this limit are actually incorrect, while wgpu is correct. I'm filing up (and have even landed in CTS upstream) some work to correct them. See [gpuweb/cts#4538](gpuweb/cts#4538) for more details.
  - CTS isn't entirely to blame; I did make one check for fragment built-in inputs too restrictive. This has been corrected with [wgpu#8792](gfx-rs/wgpu#8792).
- I decided to roll a `spirv` upgrade into this: 0.3.0+sdk-1.3.268.0 → 0.3.0+sdk-1.4.309.0@git:89ce4d0e64c91b0635f617409dc57cb031749a39

  …since it's only used by this, and most changes should go away after the `spirv` releases its current mainline history.

Differential Revision: https://phabricator.services.mozilla.com/D277553
@andyleiserson andyleiserson merged commit 611daca into gfx-rs:trunk Jan 5, 2026
51 checks passed
andyleiserson pushed a commit that referenced this pull request Jan 5, 2026
@ErichDonGubler @andyleiserson
docs(CHANGELOG): add #8792 to entry for maxInterStageShaderVariable…
605b8a2 
… migration
0323pin pushed a commit to 0323pin/wgpu that referenced this pull request Jan 6, 2026
@ErichDonGubler @0323pin
docs(CHANGELOG): add gfx-rs#8792 to entry for `maxInterStageShaderVar…
90ccaa6 
…iable` migration
i3roly pushed a commit to i3roly/firefox-dynasty that referenced this pull request Jan 6, 2026
@ErichDonGubler
Bug 2007791 - chore(webgpu): update wgpu to a2c8c0de7cdb57a74070ce70b…
0d84351 
…9912e853893d502 r=webgpu-reviewers,supply-chain-reviewers,nical

Notes:

- Most changes in expected permanent outcomes are driven by migration of wgpu to the next `maxInterStageShaderVariables` limit, dropping the old `maxInterStageShaderComponents` limit.
  - Some of CTS' tests for this limit are actually incorrect, while wgpu is correct. I'm filing up (and have even landed in CTS upstream) some work to correct them. See [gpuweb/cts#4538](gpuweb/cts#4538) for more details.
  - CTS isn't entirely to blame; I did make one check for fragment built-in inputs too restrictive. This has been corrected with [wgpu#8792](gfx-rs/wgpu#8792).
- I decided to roll a `spirv` upgrade into this: 0.3.0+sdk-1.3.268.0 → 0.3.0+sdk-1.4.309.0@git:89ce4d0e64c91b0635f617409dc57cb031749a39

  …since it's only used by this, and most changes should go away after the `spirv` releases its current mainline history.

Differential Revision: https://phabricator.services.mozilla.com/D277553
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified-and-comments-removed that referenced this pull request Jan 7, 2026
@marco-c
Bug 2007791 - chore(webgpu): update wgpu to a2c8c0de7cdb57a74070ce70b…
86481c5 
…9912e853893d502 r=webgpu-reviewers,supply-chain-reviewers,nical

Notes:

- Most changes in expected permanent outcomes are driven by migration of wgpu to the next `maxInterStageShaderVariables` limit, dropping the old `maxInterStageShaderComponents` limit.
  - Some of CTS' tests for this limit are actually incorrect, while wgpu is correct. I'm filing up (and have even landed in CTS upstream) some work to correct them. See [gpuweb/cts#4538](gpuweb/cts#4538) for more details.
  - CTS isn't entirely to blame; I did make one check for fragment built-in inputs too restrictive. This has been corrected with [wgpu#8792](gfx-rs/wgpu#8792).
- I decided to roll a `spirv` upgrade into this: 0.3.0+sdk-1.3.268.0 → 0.3.0+sdk-1.4.309.0git:89ce4d0e64c91b0635f617409dc57cb031749a39

  …since it's only used by this, and most changes should go away after the `spirv` releases its current mainline history.

Differential Revision: https://phabricator.services.mozilla.com/D277553

UltraBlame original commit: 138a2a6a3bc91543f3e0fca301e2363dd2427b46
gecko-dev-updater pushed a commit to marco-c/gecko-dev-wordified that referenced this pull request Jan 7, 2026
@marco-c
Bug 2007791 - chore(webgpu): update wgpu to a2c8c0de7cdb57a74070ce70b…
71ec913 
…9912e853893d502 r=webgpu-reviewers,supply-chain-reviewers,nical

Notes:

- Most changes in expected permanent outcomes are driven by migration of wgpu to the next `maxInterStageShaderVariables` limit, dropping the old `maxInterStageShaderComponents` limit.
  - Some of CTS' tests for this limit are actually incorrect, while wgpu is correct. I'm filing up (and have even landed in CTS upstream) some work to correct them. See [gpuweb/cts#4538](gpuweb/cts#4538) for more details.
  - CTS isn't entirely to blame; I did make one check for fragment built-in inputs too restrictive. This has been corrected with [wgpu#8792](gfx-rs/wgpu#8792).
- I decided to roll a `spirv` upgrade into this: 0.3.0+sdk-1.3.268.0 → 0.3.0+sdk-1.4.309.0git:89ce4d0e64c91b0635f617409dc57cb031749a39

  …since it's only used by this, and most changes should go away after the `spirv` releases its current mainline history.

Differential Revision: https://phabricator.services.mozilla.com/D277553

UltraBlame original commit: 138a2a6a3bc91543f3e0fca301e2363dd2427b46
gecko-dev-updater pushed a commit to marco-c/gecko-dev-comments-removed that referenced this pull request Jan 7, 2026
@marco-c
Bug 2007791 - chore(webgpu): update wgpu to a2c8c0de7cdb57a74070ce70b…
496a6cd 
…9912e853893d502 r=webgpu-reviewers,supply-chain-reviewers,nical

Notes:

- Most changes in expected permanent outcomes are driven by migration of wgpu to the next `maxInterStageShaderVariables` limit, dropping the old `maxInterStageShaderComponents` limit.
  - Some of CTS' tests for this limit are actually incorrect, while wgpu is correct. I'm filing up (and have even landed in CTS upstream) some work to correct them. See [gpuweb/cts#4538](gpuweb/cts#4538) for more details.
  - CTS isn't entirely to blame; I did make one check for fragment built-in inputs too restrictive. This has been corrected with [wgpu#8792](gfx-rs/wgpu#8792).
- I decided to roll a `spirv` upgrade into this: 0.3.0+sdk-1.3.268.0 → 0.3.0+sdk-1.4.309.0git:89ce4d0e64c91b0635f617409dc57cb031749a39

  …since it's only used by this, and most changes should go away after the `spirv` releases its current mainline history.

Differential Revision: https://phabricator.services.mozilla.com/D277553

UltraBlame original commit: 138a2a6a3bc91543f3e0fca301e2363dd2427b46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@andyleiserson andyleiserson andyleiserson approved these changes

Assignees

No one assigned

Labels

area: cts Issues stemming from the WebGPU Conformance Test Suite area: validation Issues related to validation, diagnostics, and error handling type: bug Something isn't working

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@ErichDonGubler @andyleiserson