Forums - Vertex shader issue with array uniform Adreno 200/320

10 posts / 0 new
Last post
Vertex shader issue with array uniform Adreno 200/320
DevDot
Join Date: 28 Jan 12
Location: Apeldoorn
Posts: 5
Posted: Sun, 2013-11-10 09:11

Hi,

I have a vertex shader that uses 2 array uniforms, and a for loop to iterate them:

uniform mediump vec4 pt[5];
uniform vec4 ptpos[5];
 
......
 
   for (int i = 0; i < 5; i++) {
      if (pt[i].w == 0.0)  // this line gives trouble 
         break;
         ......

   }

This shader runs flawless on a variety of devices, except "some" (mostly Galaxy S4 / ACE, the common factor is being adreno 200/320 GPU) where the line with pt[i] gives error during compile/link:

1. In some cases there is no error message text at-all
2. In other cases there is error text "SEMANTIC-20 (line 33) Indexing with an integral constant expression greater than declared size"

3. (this seems to be the exception rather than the rule) on some S4 models it runs without issue (maybe a driver difference); which is a pitty, since I am unable to reproduct the issue on Samsung Remote Test labs device (hampering my effort to find a workaround).

OpenGL ES 2.0 shader language spec says that for Uniforms, array indexes can be "Any integer"; the for loop also is within spec AFAIK.

Please advice on how to work around this? (willing to share entire shader code if so required)

Thank you in advance, any help would be greatly appreciated.

 

[EDIT:

Worked around issue by unrolling the loop manually, eliminating the 'for' construct; so far no more reports of the issue.

]

 

 

 

 

 

 

  • Up0
  • Down0
mhfeldma Moderator
Join Date: 29 Nov 12
Posts: 312
Posted: Wed, 2013-11-13 08:00

Hi..I believe this is the problem you are encountering.

The GLES shading language spec says that uniform arrays need to be indexed with constant integral expressions (not variables).

http://www.khronos.org/files/opengles_shading_language.pdf   p 103

 

-mark

 

  • Up0
  • Down0
DevDot
Join Date: 28 Jan 12
Location: Apeldoorn
Posts: 5
Posted: Wed, 2013-11-13 11:01

Hi,

Tank you for responding,

This is only for fragment shader (granted, the spec is being non-specific enough in chapter 4.1.9 Arrays, but very clear in chapter 12, appendix A section 5)

See (same PDF link): 

Chapter 12, Appendix A, section 5 "Limitations for ES 2.0"
 
[Quote]
 
Array Indexing
 
Uniforms (excluding samplers):
In the vertex shader, support for all forms of array indexing is mandated. In the fragment shader, support 
for indexing is only mandated for constant integral expressions.


[Quote end]

Also see the table at page 103.

That explains (to me at least) why it works on each and every gpu (except aforementioned cases...)

 

 

  • Up1
  • Down0
Rajveer
Join Date: 6 Dec 13
Posts: 7
Posted: Fri, 2013-12-06 03:44

I too am facing this issue, on an Adreno 330 (Nexus 5) with an OpenGL ES 3.0 context. I am doing GPU skinning and need to reference bone matrices with a bone index vector attribute.

 

...

uniform mat4 boneMatrices[30];

...

in vec3 boneWeights;

in ivec4 boneIndices;

...

mat4 matTransform = boneMatrices[boneIndices[0]] * boneWeights[0];
matTransform += boneMatrices[boneIndices[1]] * boneWeights[1];
matTransform += boneMatrices[boneIndices[2]] * boneWeights[2];
float finalWeight = 1.0 - (boneWeights[0] + boneWeights[1] + boneWeights[2]);
matTransform += boneMatrices[boneIndices[3]] * finalWeight;
 
vec4 positionSkinned = matTransform * vec4(position, 1.0);
 
The only workaround I can think of is defining 30 separate boneMatrices sequentially, then if possible referencing a specific matrix by using the location of the first one with the bone index as an offset. I don't know if this is possible. Really, what I'm trying to do should be supported, as it states in the spec that the one area where all types of array indexing should be supported is with uniform arrays in vertex shaders...
  • Up0
  • Down0
mhfeldma Moderator
Join Date: 29 Nov 12
Posts: 312
Posted: Mon, 2013-12-09 08:56

GPU skinning should work..

1) Could you confirm exactly what message you're getting?

2) It could be that the number of uniforms is not large enough to store the bone matrices..  (try reducing the count and see if it works).

3) Take a look at our Adreno SDK.  We have two complex gpu skinning examples in the OpenGLES2 section.

https://developer.qualcomm.com/mobile-development/mobile-technologies/ga...

 

 

  • Up0
  • Down0
Visual6502
Join Date: 10 Dec 13
Posts: 1
Posted: Tue, 2013-12-10 02:28

I've also hit this exact issue with Adreno 320, Android GLES20.  I'm happy to provide a simple repro APK

On the system detailed below, the bug results in a hard app death on calling glLinkProgram() with the problematic vertex shader.  There are no exceptions, no gl errors or gl log information, and no messages through logcat.  If I remove the vertex shader line that indexes a uniform by an int variable in a loop, everything renders as expected.  

I've been runnning the code that indexes a uniform without any trouble on a Nexus 7 with Tegra.

My big concern with this is that, in my case, the whole app is taken down with no indicators and no information through the GLES API.  If your implementation does not support indexing by variable (which GPU vertex shader programs have supported since GeForce3 / NV20 in 2001), then you should fail with a gl error from glCompileShader, set the proper values for glGetShaderiv( .. GL_COMPILE_STATUS), and put something visible from glGetShaderInfoLog.

I have not seen this debug spew line that DevDot mentioned, but I think it leads to an important clue:

"2. In other cases there is error text "SEMANTIC-20 (line 33) Indexing with an integral constant expression greater than declared size""

There migth be a problem with the array declaration in the compiled assembly, specifically in the header for the assembly if your implementation goes the old arb program route.

Android version 4.4

kernel version  3.4.0-gdb0eacf3

android-build@vpbs1.mtv.corp.google.com #1

Wed Oct 23 17.41.58 PDT 2013

build number KRT16S

EglContextClientVersion 2
GL_VERSION  OpenGL ES 3.0 V@53.0 AU@  (CL@3776187)
GL_VENDOR   Qualcomm
GL_RENDERER Adreno (TM) 320
GL_VERSION  OpenGL ES 3.0 V@53.0 AU@  (CL@3776187)
GL_SHADING_LANGUAGE_VERSION OpenGL ES GLSL ES 3.00

 

  • Up0
  • Down0
Rajveer
Join Date: 6 Dec 13
Posts: 7
Posted: Tue, 2013-12-10 03:23

Thanks mhfeldma for pointing me to the SDK, that solved my issues :) In the end I used a uniform array of vec4s as is done in the SDK, however I still think that the spec should be followed and a uniform array of any type be indexable with a non-constant integer. Will we perhaps see this implemented in future driver versions?

  • Up0
  • Down0
pontomedon
Join Date: 26 Jul 13
Posts: 5
Posted: Wed, 2013-12-18 05:53

my 2 cents: the linked spec is not even the latest version. if you browse through the khronos pages (OpenGL ES -> Specs & Headers -> OpenGL ES 2.0 Specifications) you end up with this version, which is revision 17, compared to revision 14, in the first link. From revision 16 to 17, allowed array indexing has changed significantly: indexing with loop indices and expressions of loop indices and constants is now explicitly allowed for all kinds of arrays (p. 110).

Is there any information about which GPUs/Drivers implement which revision of the spec? Is there any way to find out programmatically (except for trying to compile and retry with a simpler shader)?

  • Up0
  • Down0
mhfeldma Moderator
Join Date: 29 Nov 12
Posts: 312
Posted: Thu, 2014-01-02 08:58

If you do have an apk that reproduces the glLinkProgram crash, that would be great to have to both verify the existing problem on Adreno 320, and make sure it's fixed in current drivers..  Addtionally if you have the shader source code, that would be valueable to look at.

  • Up0
  • Down0
david.elahee
Join Date: 6 Dec 13
Posts: 1
Posted: Tue, 2014-07-22 08:31

I stumbled on a same as this one suing matrix palettes, as a fallback I use 

mat4 mx = m[index.x];

p = mx * ws * vec;

instead of 

p = m[index.x] * ws * vec;

and it works beautifully, it woulkd be better if the bug is fixed :)

  • Up0
  • Down0
or Register

Opinions expressed in the content posted here are the personal opinions of the original authors, and do not necessarily reflect those of Qualcomm Incorporated or its subsidiaries (“Qualcomm”). The content is provided for informational purposes only and is not meant to be an endorsement or representation by Qualcomm or any other party. This site may also provide links or references to non-Qualcomm sites and resources. Qualcomm makes no representations, warranties, or other commitments whatsoever about any non-Qualcomm sites or third-party resources that may be referenced, accessible from, or linked to this site.