Validation fixes for dual-source blending, depth bias, and frag_depth

[andyleiserson]

Several validation fixes. The only reason the dual-source blending fix is related is that both it and the frag_depth fix add fields to ShaderStageForValidation::Fragment that @ErichDonGubler added recently.

• If the pipeline uses dual-source blending, then the shader must configure appropriate I/O, but it is not an error to use a shader that defines the I/O in a pipeline that only uses one blend source. Fixes dual source blending is forced if enabled (wgpu being overly strict?) #8592.
• Depth bias is only supported with triangle topologies. Fixes Point and line primitives must not have depth bias #6071.
• If the shader outputs frag_depth, then the pipeline must have a depth attachment. (No bug.)

This change will conflict with #8840, which needs more discussion, so I expect #8840 will be rebased on this one. Whichever lands second should enable the entire depth_stencil_state suite.

Testing
Enables relevant CTS tests.

Squash or Rebase? Rebase

Checklist

• Run cargo fmt.
• Run taplo format.
• Run cargo clippy --tests. If applicable, add:
  • --target wasm32-unknown-unknown
• Run cargo xtask test to run tests.
• Add CHANGELOG.md entries.

[dhardy]

This doesn't solve my issue (should have been an issue not a discussion): #8798

wgpu error: Validation Error

Caused by:
  In Device::create_render_pipeline, label = 'text subpixel mask pipe'
    Error matching ShaderStages(FRAGMENT) shader requirements against the pipeline
      Pipeline uses dual-source blending, but the shader does not support it

This is using a GLSL shader which works correctly if I hack wgpu to disable this validation completely.

[andyleiserson]

This doesn't solve my issue (should have been an issue not a discussion): #8798

It's not related to this change, but I filed #8864 from your discussion, and opened #8865 and kas-gui/kas#635.

[Wumpf]

very nice, thanks for the logical commit split

[Wumpf]

would be nice if those types would be Eq so we could just do a contains, any reason why not?

[andyleiserson]

I don't see why not. Depending on how tightly the enums get packed, the Varying::Local { location: u32, iv: InterfaceVar } variant could be one or two words, or could be a handful more than that, but it's not so much that it seems inappropriate to implement Eq.

[andyleiserson]

The push of c20c23a is a rebase plus a new commit to implement (and use) Eq for Varying.

The push of bc4b44e was an incorrect (partial) attempt to squash the new commit, and the push of 75180c3 actually squashes the commit.

Sorry for the noise.