Fixes for dual-source blending validation#9200
Open
andyleiserson wants to merge 5 commits intogfx-rs:trunkfrom
Open
Fixes for dual-source blending validation#9200andyleiserson wants to merge 5 commits intogfx-rs:trunkfrom
andyleiserson wants to merge 5 commits intogfx-rs:trunkfrom
Conversation
- Validate `@blend_src` structs in type validation. The spec requires validating any struct with `@blend_src` attributes, whether or not it is used by an entry point. - Remove `@blend_src`-related interface validation that is redundant with the type validation. - Dual-source blending requires that there be a single color attachment.
Including a regression test for gfx-rs#9111.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Supersedes #8939. Fixes #9111.
@blend_srcstructs in type validation. The spec requires validating any struct with@blend_srcattributes, whether or not it is used by an entry point.@blend_src-related interface validation that is redundant with the type validation.Re:
IO_SHAREABLE: The concept of "I/O shareable" was removed from the spec at some point. A type flag is mostly unnecessary here, we could instead use ais_numeric_scalar_or_vectorhelper.@blend_srcstructs seem to be the only case where it is still useful (to be able to mark structs that passed@blend_srcvalidation in type validation). For that purpose naming the flagBLEND_SRCmight be clearer, although using up one of 8 type flags just for@blend_srcstructs seems a bit unfortunate. (I was initially going to add a new type flag forBLEND_SRC, until I realized it's only au8and doesn't have any free bits.) As of this change, a struct consisting of only@location-bound members is no longer marked IO_SHAREABLE. We validate the members individually in interface validation anyways, there isn't a check anywhere of something like "this struct appears in I/O so must be IO_SHAREABLE". While we could use that strategy to check the members once in type validation instead of during interface validation, (1) any savings from doing so is negligible, (2)@locationbindings within the struct still need to be inspected during interface validation for conflicts among all of the I/O. @jimblandy this paragraph seems like it might interest you even if you don't review the whole PR.Testing
Enables CTS tests and adds/updates wgsl_errors tests.
Squash or Rebase? Probably squash the last three commits and then rebase.
Checklist
cargo fmt.taplo format.cargo clippy --tests. If applicable, add:--target wasm32-unknown-unknowncargo xtask testto run tests.CHANGELOG.mdentry, or there may already be one in this release for dual-source blending that can be updated.