webgpu/api/validation: Fix vertex_shader_input_location_limit test #767
Conversation
| const success = { | ||
| // [[location(n)]] decoration must be a "non-negative i32 literal" | ||
| // TODO: Dawn raises a "Attribute location (N) over limits" error at | ||
| // shader creation time for N>15. Is this right? |
There was a problem hiding this comment.
@Kangz - It seems to me that Dawn might be validating too early here. Please can you advise?
There was a problem hiding this comment.
... restricted the locations themselves to be under the limit after some discussion that that was most likely sufficient, and forward-compatible with relaxing the restriction.
There was a problem hiding this comment.
Thanks. Made both the shader and pipeline conditions both dependent on the location being [0..kMaxVertexAttributes)
|
Previews, as seen when this build job started (cd2eac6): |
Shader compilation / validation will fail for vertex attributes that are out of bounds.
ben-clayton
force-pushed
the
fix-vs-input-limit
branch
from
cd2eac6
to
9317e7c
Compare
|
Previews, as seen when this build job started (9317e7c): |
| let vsModule: GPUShaderModule | undefined; | ||
|
|
||
| this.expectValidationError(() => { | ||
| vsModule = this.device.createShaderModule({ code: vertexShader }); | ||
| }, !success.shader); | ||
|
|
||
| if (vsModule === undefined) { | ||
| return; | ||
| } |
There was a problem hiding this comment.
Allowing vsModule to be undefined isn't actually necessary here (checked locally). It's technically still unsound (as is an as cast) because I don't think the compiler knows the callback of expectValidationError is always called, or that it didn't throw a caught exception. But it works anyway.
| let vsModule: GPUShaderModule | undefined; | |
| this.expectValidationError(() => { | |
| vsModule = this.device.createShaderModule({ code: vertexShader }); | |
| }, !success.shader); | |
| if (vsModule === undefined) { | |
| return; | |
| } | |
| let vsModule: GPUShaderModule; | |
| this.expectValidationError(() => { | |
| vsModule = this.device.createShaderModule({ code: vertexShader }); | |
| }, !success.shader); |
| this.expectValidationError(() => { | ||
| this.device.createRenderPipeline({ | ||
| vertex: { | ||
| module: vsModule, | ||
| module: vsModule as GPUShaderModule, |
There was a problem hiding this comment.
| module: vsModule as GPUShaderModule, | |
| module: vsModule, |
| const success = testLocation < kMaxVertexAttributes; | ||
| const success = { | ||
| shader: testLocation >= 0 && testLocation < kMaxVertexAttributes, | ||
| pipeline: testLocation >= 0 && testLocation < kMaxVertexAttributes, |
There was a problem hiding this comment.
In this case the pipeline creation would actually fail for either of two separate reasons: shader module was invalid, and shaderLocation was out of bounds. We can't tell which one.
If it's allowed for a shader to have a subset of the attributes defined by the pipeline (I'm not sure, but I think it is allowed), only the shaderLocation being out of bounds should be tested here.
| @@ -396,7 +413,10 @@ g.test('vertex_shader_input_location_limit') | |||
| }, | |||
| ]; | |||
|
|
|||
| const success = testLocation < kMaxVertexAttributes; | |||
| const success = { | |||
| shader: testLocation >= 0 && testLocation < kMaxVertexAttributes, | |||
There was a problem hiding this comment.
The fact that this is only used in one test kind of indicates this test should be somewhere else - it's a test of createShaderModule and not of the vertex state setup in createRenderPipeline.
If indeed this should fail in createShaderModule, then I think it's really a shader validation test (src/webgpu/shader/validation/)
The WGSL spec states that the
[[location(n)]]decoration must be a "non-negative i32 literal".