diff mbox

arb_program_interface_query: update and fix arrays of arrays tests

Message ID 1435360454-3621-1-git-send-email-t_arceri@yahoo.com.au
State New
Headers show

Commit Message

'Timothy Arceri' via Patchwork Forward June 26, 2015, 11:14 p.m. UTC
Add a 3D array test and fix the expected result for an array without
a subscript attached to the name.

The arb_program_interface_query spec says:

"If <name> exactly matches the name string of one of the active resources
for <programInterface>, the index of the matched resource is returned.
Additionally, if <name> would exactly match the name string of an active
resource if "[0]" were appended to <name>, the index of the matched
resource is returned."

So the index should not be INVALID_INDEX when there is no subscript.

Cc: Martin Peres <martin.peres@linux.intel.com>
Cc: Tapani Pälli <tapani.palli@intel.com>
---
 .../arb_program_interface_query/getprogramresourceindex.c    | 12 +++++++++++-
 1 file changed, 11 insertions(+), 1 deletion(-)

Comments

'Timothy Arceri' via Patchwork Forward June 30, 2015, 9:48 a.m. UTC | #1
On Mon, 2015-06-29 at 13:49 +0300, Tapani Pälli wrote:
> On 06/27/2015 02:14 AM, Timothy Arceri wrote:
> > Add a 3D array test and fix the expected result for an array 
> > without
> > a subscript attached to the name.
> > 
> > The arb_program_interface_query spec says:
> > 
> > "If <name> exactly matches the name string of one of the active 
> > resources
> > for <programInterface>, the index of the matched resource is 
> > returned.
> > Additionally, if <name> would exactly match the name string of an 
> > active
> > resource if "[0]" were appended to <name>, the index of the matched
> > resource is returned."
> > 
> > So the index should not be INVALID_INDEX when there is no 
> > subscript.
> 
> Did you check if these changes pass on nvidia/amd?
> 
> Shouldn't one give 'vs_input2[0]' as parameter? Then it would 
> definitely 
> qualify because 'vs_input2[0][0]' is ok but having only 'vs_input2' 
> means name check against 'vs_input2' and 'vs_input2[0]' which would 
> not 
> qualify (?)
> 
> This was my understanding when writing the code. So how I interpret 
> the 
> spec is that if you have multiple levels, you'll need to specify 
> until 
> the last level and optionally [0] for that last one.

Yes you are right its all defined in Issues 7 & 8 at the bottom of the
spec. I'll send a V2 that covers more AoA combinations, I'm working on
some fixes for ARB_program_interface_query in Mesa as part of my AoA
work I hope to have a new series out at the end of the week.
'Timothy Arceri' via Patchwork Forward June 30, 2015, 10:47 a.m. UTC | #2
On Tue, 2015-06-30 at 13:24 +0300, Tapani Pälli wrote:
> 
> On 06/30/2015 12:48 PM, Timothy Arceri wrote:
> > On Mon, 2015-06-29 at 13:49 +0300, Tapani Pälli wrote:
> > > On 06/27/2015 02:14 AM, Timothy Arceri wrote:
> > > > Add a 3D array test and fix the expected result for an array
> > > > without
> > > > a subscript attached to the name.
> > > > 
> > > > The arb_program_interface_query spec says:
> > > > 
> > > > "If <name> exactly matches the name string of one of the active
> > > > resources
> > > > for <programInterface>, the index of the matched resource is
> > > > returned.
> > > > Additionally, if <name> would exactly match the name string of 
> > > > an
> > > > active
> > > > resource if "[0]" were appended to <name>, the index of the 
> > > > matched
> > > > resource is returned."
> > > > 
> > > > So the index should not be INVALID_INDEX when there is no
> > > > subscript.
> > > 
> > > Did you check if these changes pass on nvidia/amd?
> > > 
> > > Shouldn't one give 'vs_input2[0]' as parameter? Then it would
> > > definitely
> > > qualify because 'vs_input2[0][0]' is ok but having only 
> > > 'vs_input2'
> > > means name check against 'vs_input2' and 'vs_input2[0]' which 
> > > would
> > > not
> > > qualify (?)
> > > 
> > > This was my understanding when writing the code. So how I 
> > > interpret
> > > the
> > > spec is that if you have multiple levels, you'll need to specify
> > > until
> > > the last level and optionally [0] for that last one.
> > 
> > Yes you are right its all defined in Issues 7 & 8 at the bottom of 
> > the
> > spec. I'll send a V2 that covers more AoA combinations, I'm working 
> > on
> > some fixes for ARB_program_interface_query in Mesa as part of my 
> > AoA
> > work I hope to have a new series out at the end of the week.
> 
> Great to hear that! I've noticed several failures within OpenGL ES 
> 3.1 
> conformance tests for ARB_program_interface_query and I think some of 
> 
> those were AoA subtests.

Thanks for pointing this out I'll be sure to run the
ARB_program_interface_query conformance tests over my changes.

Tim

> 
> // Tapani
diff mbox

Patch

diff --git a/tests/spec/arb_program_interface_query/getprogramresourceindex.c b/tests/spec/arb_program_interface_query/getprogramresourceindex.c
index 889b5e1..18bb1af 100755
--- a/tests/spec/arb_program_interface_query/getprogramresourceindex.c
+++ b/tests/spec/arb_program_interface_query/getprogramresourceindex.c
@@ -170,11 +170,21 @@  static const struct subtest_index_t index_subtests[] = {
  ST(vs_array,                    GL_UNIFORM,        "sa[0].world",  0, GL_NO_ERROR),
  ST(vs_array,                    GL_UNIFORM,     "sa[0].world[0]",  0, GL_NO_ERROR),
  ST(vs_array,                    GL_UNIFORM,        "sa[1].hello", -1, GL_NO_ERROR),
- ST( vs_aofa,              GL_PROGRAM_INPUT,          "vs_input2", -1, GL_NO_ERROR),
+ ST( vs_aofa,              GL_PROGRAM_INPUT,          "vs_input2",  0, GL_NO_ERROR),
  ST( vs_aofa,              GL_PROGRAM_INPUT,       "vs_input2[0]",  0, GL_NO_ERROR),
  ST( vs_aofa,              GL_PROGRAM_INPUT,    "vs_input2[0][0]",  0, GL_NO_ERROR),
  ST( vs_aofa,              GL_PROGRAM_INPUT,    "vs_input2[1][0]", -1, GL_NO_ERROR),
  ST( vs_aofa,              GL_PROGRAM_INPUT,    "vs_input2[0][1]", -1, GL_NO_ERROR),
+ ST( vs_aofa,              GL_PROGRAM_INPUT,          "vs_input3",  0, GL_NO_ERROR),
+ ST( vs_aofa,              GL_PROGRAM_INPUT,       "vs_input3[0]",  0, GL_NO_ERROR),
+ ST( vs_aofa,              GL_PROGRAM_INPUT,    "vs_input3[0][0]",  0, GL_NO_ERROR),
+ ST( vs_aofa,              GL_PROGRAM_INPUT, "vs_input3[0][0][0]",  0, GL_NO_ERROR),
+ ST( vs_aofa,              GL_PROGRAM_INPUT, "vs_input3[0][0][1]", -1, GL_NO_ERROR),
+ ST( vs_aofa,              GL_PROGRAM_INPUT, "vs_input3[0][1][0]", -1, GL_NO_ERROR),
+ ST( vs_aofa,              GL_PROGRAM_INPUT, "vs_input3[1][0][0]", -1, GL_NO_ERROR),
+ ST( vs_aofa,              GL_PROGRAM_INPUT, "vs_input3[1][0][1]", -1, GL_NO_ERROR),
+ ST( vs_aofa,              GL_PROGRAM_INPUT, "vs_input3[1][1][0]", -1, GL_NO_ERROR),
+ ST( vs_aofa,              GL_PROGRAM_INPUT, "vs_input3[1][1][1]", -1, GL_NO_ERROR),
  ST(  vs_sub,          GL_VERTEX_SUBROUTINE,                "vss",  0, GL_NO_ERROR),
  ST(vs_empty, GL_TRANSFORM_FEEDBACK_VARYING,      "gl_NextBuffer", -1, GL_NO_ERROR),
  ST(vs_empty, GL_TRANSFORM_FEEDBACK_VARYING, "gl_SkipComponents1", -1, GL_NO_ERROR),