glGetActiveUniform returns without "[0]" for a uniform array of size one

[GoogleCodeExporter]

What steps will reproduce the problem?
1.
2.
3.

What is the expected output? What do you see instead?

For a shader variable

uniform vec4 xxx[1];

glGetActiveUniform should return name "xxx[0]".  Right now it returns "xxx" 
instead.

What version of the product are you using? On what operating system?

Please provide any additional information below.

Original issue reported on code.google.com by zmo@chromium.org on 24 Mar 2011 at 10:05

[GoogleCodeExporter]

Original comment by z...@google.com on 24 Mar 2011 at 10:06

[GoogleCodeExporter]

Original comment by kbr@chromium.org on 24 Mar 2011 at 10:40

[GoogleCodeExporter]

Certain other OpenGL ES 2.0 implementations don't append any obsolete "[0]" 
either when the array size is 1.

Although the spec does appear to expect "[0]" to be appended for this case, I 
don't think omitting it can ever possibly lead to any real-world issues. 
Certain conformance tests could flag it as an error, but in my humble opinion 
these would be overly stringent.

Part of the reason for my resistance is that D3D also makes no distinction 
between non-array variables and 1-element arrays. Probably the 'simplest' way 
to convey the arrayness would be to tag the variable names in the GLSL to HLSL 
translation phase, but I'm not sure if this is worth the complication.

Original comment by nicolas....@gmail.com on 25 Mar 2011 at 7:49

[GoogleCodeExporter]

I agree this is a corner case, however, this is the same issue as issue 136, 
and WebGL conformance suites 1.00 is failing due to it.  Without this fixed, 
both Chrome and Firefox won't ever be able to pass that suites.

Original comment by z...@google.com on 25 Mar 2011 at 3:22

[GoogleCodeExporter]

I don't think this needs to be fixed in angle the d3d part, it needs to be 
fixed only in the translator/validator part. The command buffer already gets 
types and sizes from the translator/validator. If the translator/validator 
correctly returns [0] for 1 element arrays the command buffer will hide the 
fact that the OpenGL implementation underneath is not spec compliant.

That's a better fix because it will work for non angle cases as well.

Original comment by g...@google.com on 25 Mar 2011 at 4:17

[GoogleCodeExporter]

The validator/translator should correctly append [0] to 1-element array names. 
If it does not in this case, please file a bug, I will fix it.

Also I do not think there is any harm in fixing the ANGLE implementation as 
long as it is not too complicated. After all it does not conform to the spec.

Original comment by alokp@chromium.org on 25 Mar 2011 at 4:25

[GoogleCodeExporter]

validator/translator's behavior is correct.

Original comment by z...@google.com on 25 Mar 2011 at 5:01

[GoogleCodeExporter]

I agree it should be fixed in ANGLE as well.  Is there a specific conformance 
test that is failing because of it at the moment?

Original comment by dan...@transgaming.com on 25 Mar 2011 at 5:38

[GoogleCodeExporter]

Sorry, just realized I made a typo in comment 4, I meant issue 133 instead of 
issue 136.

Both issues are the same cause: fail to distinguish a non-array uniform and 
size-of-one uniform array.  Issue 133 causes one webgl conformance test to 
fail.  Maybe we could fix the two issues together because they are closely 
related.

Original comment by z...@google.com on 25 Mar 2011 at 5:44

[GoogleCodeExporter]

Ah right. I think they likely are the same underlying problem then, since we do 
allow extra data for arrays with size > 1

Original comment by dan...@transgaming.com on 25 Mar 2011 at 5:49

[GoogleCodeExporter]

Issue 133 has been merged into this issue.

Original comment by z...@google.com on 29 Mar 2011 at 8:30

[GoogleCodeExporter]

Original comment by nicolas....@gmail.com on 29 Apr 2011 at 9:13

• Changed state: Started

[GoogleCodeExporter]

Fixed in r760.

Original comment by nicolas....@gmail.com on 20 Sep 2011 at 4:38

[GoogleCodeExporter]

Original comment by nicolas....@gmail.com on 20 Sep 2011 at 4:38

• Changed state: Fixed