Jump to content

  • Log In with Google      Sign In   
  • Create Account

#ActualRPTD

Posted 03 March 2013 - 10:41 AM

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.


#4RPTD

Posted 03 March 2013 - 10:39 AM

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?


#3RPTD

Posted 03 March 2013 - 10:38 AM

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 multiple 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?


#2RPTD

Posted 03 March 2013 - 10:37 AM

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 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 multiple 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?


#1RPTD

Posted 03 March 2013 - 10:36 AM

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 the version is ATI 12.6_beta_pre897:legacy as well as 13.1_beta_pre897:legacy . The graphic card 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 multiple 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?


PARTNERS