I ran around in circles for a couple of weeks now trying to figure out why a certain change in my shader caused everything to go haywire. I've nailed now the problem and it looks to me like it's a driver bug not me understanding some specs wrong. I would like to confirm with others here if this is the case or if something slipped me.

I found this bug on ATI 12.6_beta_pre897:legacy as well as 13.1_beta_pre897:legacy . The graphic card is a Radeon 4870 HD.

The bug happens with uniform buffer objects in connection with row-major oriented matrices. The test shader looks like this (fragment shader only, vertex shader is basic in-out position):

precision highp float; precision highp int; layout (std140, row_major) uniform TestParameters{ mat4x3 pMatrix1; mat3 pMatrix2; }; out vec3 outColor; void main( void ){ mat4x3 indirectAccess = pMatrix1; vec3 normal = indirectAccess * vec4( vec3( 0.0, 0.0, 1.0 ), 1.0 ); outColor = normal * vec3( 0.5 ) + vec3( 0.5 ); }

This test is run on a 1x1 screen so the result can be easily verfied by testing the result of a single pixel. The UBO in question is laid out like this with each [X] being one float value aligned in rows to 4 floats for readability:

[ a11 ][ a12 ][ a13 ][ a14 ] [ a21 ][ a22 ][ a23 ][ a24 ] [ a31 ][ a32 ][ a33 ][ a34 ] [ b11 ][ b12 ][ b13 ][ 0 ] [ b21 ][ b22 ][ b23 ][ 0 ] [ b31 ][ b32 ][ b33 ][ 0 ]

aXY refers to matrix1[X][Y] and bXY to matrix2[X][Y] both in row-major order. For testing the following values are written in the UBO:

[ 0 ][ 0 ][ 0 ][ 0 ] [ 0 ][ 0 ][ 0 ][ 0 ] [ 0 ][ 0 ][ 0 ][ 1 ] [ 1 ][ 0 ][ 0 ][ 0 ] [ 0 ][ 0 ][ 0 ][ 0 ] [ 0 ][ 0 ][ 0 ][ 0 ]

You can verify that if the data is read as row-major you end up with a matrix producing the output vector (0,0,1) while in colon-major you end up with (1,0,0).

If I run this shader I should get (0,0,1) but I get actually (1,0,0) hence the matrix is incorrectly read as colon-major if copied first to a matrix of the same type ( indirectAccess == pMatrix1 ). If the shader is changed to this (using pMatrix1 directly):

precision highp float; precision highp int; layout (std140, row_major) uniform TestParameters{ mat4x3 pMatrix1; mat3 pMatrix2; }; out vec3 outColor; void main( void ){ vec3 normal = pMatrix1 * vec4( vec3( 0.0, 0.0, 1.0 ), 1.0 ); // ****************** outColor = normal * vec3( 0.5 ) + vec3( 0.5 ); }

the output is (0,0,1) as it should be. I ended up with this bug as I had to multiply two matrices together in the shader to do a bunch of calculations. The result never had been right because the driver reads the matrix incorrectly from the UBO data storage.

So my questions are not these:

1) Can somebody else confirm this bug using this simple test-case?

2) Or do I misunderstand something about the specs stating that accessing a matrix directly uses the row-major qualifier while using the matrix indirectly ignores it?

EDIT:

I should note that UBO is working properly so far. The problem started when I tried doing a more complex shader where I had to access matrices indirectly. So far I wrote all my shaders to access matrices directly so the bug never showed before.

**Edited by RPTD, 03 March 2013 - 10:41 AM.**