Bug 98223 - dEQP GLES3.1 program_interface_query failures w/ error "could not find target resource"
Summary: dEQP GLES3.1 program_interface_query failures w/ error "could not find target...
Status: RESOLVED FIXED
Alias: None
Product: Mesa
Classification: Unclassified
Component: glsl-compiler (show other bugs)
Version: git
Hardware: All All
: medium major
Assignee: mesa-dev
QA Contact: Intel 3D Bugs Mailing List
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: i965-deqp
  Show dependency treegraph
 
Reported: 2016-10-13 05:23 UTC by Randy
Modified: 2019-03-14 08:40 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Randy 2016-10-13 05:23:45 UTC
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());
}
Comment 1 Kenneth Graunke 2016-10-13 05:59:16 UTC
Unclear whether the tests or the driver are wrong.  Need to discuss ARB_program_interface_query issue 16 with Khronos.
Comment 2 Randy 2016-10-13 06:28:26 UTC
(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
Comment 3 Randy 2016-10-13 06:38:11 UTC
(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
Comment 4 Alejandro Piñeiro (freenode IRC: apinheiro) 2016-10-13 07:58:07 UTC
(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).
Comment 5 Randy 2016-10-13 14:39:46 UTC
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.
Comment 6 Alejandro Piñeiro (freenode IRC: apinheiro) 2016-10-13 16:10:09 UTC
(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.
Comment 7 Randy 2016-10-14 03:05:33 UTC
(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.
Comment 8 Kenneth Graunke 2017-01-25 15:58:53 UTC
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.