Varying Vectors issue with X1550


We have a problem with an ATI X1550 card and the PowerVR OpenGL ES 2.0 Emulation.

glGetIntegerv(GL_MAX_VARYING_VECTORS, &value) claims that the card supports 8 varying vectors - which is the minimum requirement regarding the OpenGL ES 2.0 specification.
In fact, there seem to be only 7 vectors (or even varying variables) supported. If using more than 7 varying parameters, the shader linker reports an error:
Failed to link: Fragment shader(s) failed to link,  vertex shader(s) linked.
 Fragment shader(s) failed to link,  vertex shader(s) linked.
 Fragment shader(s) failed to link,  vertex shader(s) linked.
 Fragment shader(s) failed to link,  vertex shader(s) linked.

Everything works fine if only using 7 varying parameters again.

Imagination Technologies states, "The SDK has been successfully tested with ATI Radeon X1000 series and
newer graphics cards, and NVIDIA GeForce 6 series and newer graphics
cards." but this looks as if its a bug since
a) GL_MAX_VARYING_VECTORS seems to be returned wrong and
b) an OpenGL ES 2.0 implementation has to support at least 8 vectors.

Is this a known problem? Will it be fixed? If so, when? Will we be able to use and support an X1550 or is it also a hardware limitation?

Here are the varying variables we're using in the shader:
varying lowp vec4 v_color;
varying highp vec2 v_texCoord;
varying highp vec3 v_normal;
varying highp vec3 v_light_direction;
varying highp vec3 v_eye_direction;
varying highp float v_light_attenuation;
varying lowp vec3 v_ambient;
varying lowp vec3 v_diffuse;
varying lowp vec3 v_specular;

It only works if removing the last two of them (v_diffuse and v_specular).
Does it matter in which order they're declared?

ThM2011-03-24 12:40:02

This is a real problem for our product. If we cannot retrieve correct information about the capabilities of those graphics cards we are not able to adjust our shaders on initialization.

Is there any recommendation about this? Any patch planned?

Thanks for reporting the issue. This is now in our bug tracker as BRN33293.





As a temporary workaround, I would suggest querying the hardware name through glGetString() and only allowing 7 varying’s on machine’s with this setup. Have you experienced the issue on any other cards? Are you distributing PVRVFrame, rather than just using it for development?


It may also be worth trying to use native OpenGL ES 2.0 drivers if they are available (as they are in newer AMD/ATI cards: http://support.amd.com/us/kbarticles/Pages/GPU74ATICat107PreviewDriver.aspx).





An engineer will be looking into a solution to this today. If we find a solution, we will post again in this topic and will get an updated binary to you.

Hi,

Thanks for your post. Issue that having 8 varyings do not work for you is a hardware limitation of the mentioned graphics card.  X1550 is fine for OpenGL ES 1.1 but for OpenGL ES 2.0 got slightly higher requirements(OpenGL 2.1). MAX_VARYING_VECTORS is related to host MAX_VARYING_FLOATS so if underneath hardware is not capable enough then  this condition of having MAX_VARYING_VECTORS at least 8 is not met. Our SDK for ES 2.0 is not using shaders with 8+ varying vectors  so it works on slighly less capable underneath graphics hardware (not supporting desktop  Open GL 2.1 ).

We do apologize for not precise release notes for our prerelase 2.8 .




Thanks for your effort.

I think querying the name of the card would work for us. Then we could check if it's an X1550 and use other shaders for that.

We experienced this problem at X1550 but also on lower X-cards.