| Summary: | dEQP GLES3.1 program_interface_query failures w/ error "could not find target resource" | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Randy <randy.xu> |
| Component: | glsl-compiler | Assignee: | mesa-dev |
| Status: | RESOLVED FIXED | QA Contact: | Intel 3D Bugs Mailing List <intel-3d-bugs> |
| Severity: | major | ||
| Priority: | medium | CC: | apinheiro |
| Version: | git | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Bug Depends on: | |||
| Bug Blocks: | 94448 | ||
Unclear whether the tests or the driver are wrong. Need to discuss ARB_program_interface_query issue 16 with Khronos. (In reply to Kenneth Graunke from comment #1) > Unclear whether the tests or the driver are wrong. Need to discuss > ARB_program_interface_query issue 16 with Khronos. Thanks, besides ARB_program_interface_query, we also need check ARB_program_interface_query (In reply to Randy from comment #2) > (In reply to Kenneth Graunke from comment #1) > > Unclear whether the tests or the driver are wrong. Need to discuss > > ARB_program_interface_query issue 16 with Khronos. > > Thanks, besides ARB_program_interface_query, we also need check > ARB_program_interface_query Sorry, my typo, another extension is https://www.khronos.org/registry/gles/extensions/EXT/EXT_shader_io_blocks.txt (In reply to Randy from comment #2) > (In reply to Kenneth Graunke from comment #1) > > Unclear whether the tests or the driver are wrong. Need to discuss > > ARB_program_interface_query issue 16 with Khronos. > > Thanks, besides ARB_program_interface_query, we also need check > ARB_program_interface_query FWIW, in relation with Issue 16, I opened the following public khronos bug some time ago: https://www.khronos.org/bugzilla/show_bug.cgi?id=1655 Don't know if there are an equivalent internal bug tracking the issue (I don't have access to the internal tracker). We can use the patch (in https://lists.freedesktop.org/archives/mesa-dev/2016-August/124910.html) to workaround the name issue, while some cases still fail due to wrong property, like ARRAY_SIZE in TargetInterface { highp vec4 target[3]; } targetInstance[2]; the expected ARRAY_SIZE of TargetInterface.target[0] is 3, while the actual return value is 2. (In reply to Randy from comment #5) > We can use the patch (in > https://lists.freedesktop.org/archives/mesa-dev/2016-August/124910.html) to > workaround the name issue, while some cases still fail due to wrong > property, like ARRAY_SIZE The problem is that the spec is contradictory. The patch on that link (that btw, the author is Kenneth, that wrote comment 1) fixes some deqp and CTS tests. But it causes some regressions on others, like you mention below. So at this point, I really think that it would be better to wait for a resolution from Khronos on relation to the text of the spec, issue 16 in particular, and then fix the tests. > > in TargetInterface > { > highp vec4 target[3]; > } targetInstance[2]; > > the expected ARRAY_SIZE of TargetInterface.target[0] is 3, while the actual > return value is 2. (In reply to Alejandro Piñeiro (freenode IRC: apinheiro) from comment #6) > > The problem is that the spec is contradictory. The patch on that link (that > btw, the author is Kenneth, that wrote comment 1) fixes some deqp and CTS > tests. But it causes some regressions on others, like you mention below. > > So at this point, I really think that it would be better to wait for a > resolution from Khronos on relation to the text of the spec, issue 16 in > particular, and then fix the tests. > Thanks and agree. Fixed by: commit 4c4d9e4f032d5753034361ee70aa88d16d3a04b4 Author: Kenneth Graunke <kenneth@whitecape.org> Date: Fri Dec 16 17:03:15 2016 -0800 glsl: Fix program interface queries relating to interface blocks. This fixes 555 dEQP tests (using the nougat-cts-dev branch), Piglit's arb_program_interface_query/arb_program_interface_query-resource-query, and GL45-CTS.program_interface_query.separate-programs-{tess-control, tess-eval,geometry}. Only one dEQP program interface failure remains. |
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.
In dEQP GLES3.1 test suite, there are about 500 failures in dEQP-GLES31.functional.program_interface_query.program_input* and dEQP-GLES31.functional.program_interface_query.program_output*. The signature is similar: <Result StatusCode="Fail">could not find target resource</Result> Take the case "dEQP-GLES31.functional.program_interface_query.program_input.is_per_patch.interface_blocks.in.block_array.var_array" for example The dEQP test case query the shader variable "target" through "TargetInterface.target[0]", while the name in GLSL type is "TargetInterface[2].target" The shader code is: #version 310 es #extension GL_EXT_shader_io_blocks : require in TargetInterface { highp vec4 target[3]; } targetInstance[2]; highp vec4 readInputs() { highp vec4 retValue = vec4(0.0); retValue += vec4(targetInstance[0].target[0].xyxy); retValue += vec4(targetInstance[0].target[1].xyxy); retValue += vec4(targetInstance[0].target[2].xyxy); retValue += vec4(targetInstance[1].target[0].xyxy); retValue += vec4(targetInstance[1].target[1].xyxy); retValue += vec4(targetInstance[1].target[2].xyxy); return retValue; } void writeOutputs(in highp vec4 dummyValue) { gl_FragDepth = dot(dummyValue.xy, dummyValue.xw); } void main() { writeOutputs(readInputs()); }