summaryrefslogtreecommitdiffstats
path: root/tests/cross-compile/sv-coverage.slang
Commit message (Collapse)AuthorAge
* SPIRV `Block` decoration fixes. (#4303)Yong He2024-06-08
| | | | | | | | | | | | | | | * SPIRV `Block` decoration fixes. - SPIRV does not allow duplicate `Block` decorations. So we shouldn't be generating them. - Also fixes duplication of OpName. - SPIRV and HLSL do not allow ConstantBuffer with trailing unsized arrays. Added a check in the front-end against such code. * Convert failing cross-compile tests to filecheck. --------- Co-authored-by: Jay Kwak <82421531+jkwak-work@users.noreply.github.com>
* [SPIRV] fix code gen for `SV_Coverage`. (#3718)Yong He2024-03-08
| | | | | | | * [SPIRV] fix code gen for `SV_Coverage`. * Fix #3714, #3699. * Fix.
* Fix support for SV_Coverage on GLSL path (#1239)Tim Foley2020-02-24
There were two overlapping issues here: 1. We always mapped `SV_Coverage` to `gl_SampleMask`, even though `gl_SampleMaskIn` is the correct built-in variable to use for an input varying. 2. We treated `gl_SampleMask` like it was a scalar shader input, when it and `gl_SampleMaskIn` are actually arrays of indeterminate size (as a byproduct of trying to future-proof for implementations that might support hundreds or thousands of samples per pixel...) The fix here is simple: map to either `gl_SampleMask[0]` or `gl_SampleMaskIn[0]` as appropriate. I suppose that this approach doesn't handle the possibility of eventually supporting >32 samples per pixel by having something like `uint2 coverage : SV_Coverage`, but I think we can cross that bridge when we come to it.