Seemingly senseless double transpose

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Try a GLSL vertex shader with the following code
   uniform mat4 erp_matrix[5];
   attribute vec4 erp_position;
   main() {
   gl_position = erp_matrix_[0] * erp_position;
   }

   and a GL program which loads the matrix via glUniformMatrix4fv.

2. Observe that:
     The corresponding line in the translated HLSL code is
        gl_Position = mul(transpose(_erp_matrix[0]), _erp_position);

3. Observe that:
     ProgramBinary::setUniformMatrix4fv (and all other
     setUniformMatrix variants) calls transposeMatrix on the matrix
     array passed from the application.

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

It would seem that the transposes could be eliminated completely in this simple 
example. It may be that the matrix is being transposed on loading to facilitate 
the GLSL shader indexing the matrix, e.g vec4 foo = vec4(erp_matrix[0][0]). In 
that case the transpose in the shader could still be eliminated by using 
another variant of mul: mul(_erp_position, _erp_matrix[0]); It would certainly 
be nice to avoid a matrix transpose on every vertex.

What version of the product are you using? On what operating system?
dx11 branch; Windows 7.

Original issue reported on code.google.com by callow.m...@artspark.co.jp on 5 Jun 2013 at 8:01

[GoogleCodeExporter]

The transpose is indeed required to have correct indexing semantics. But it is 
essentially free, because the HLSL compiler recognizes that it can replace dot4 
instructions on matrix rows, with mad instructions on matrix columns, or 
vice-versa.

Original comment by nico...@transgaming.com on 10 Jun 2013 at 8:51

• Changed state: Invalid

[GoogleCodeExporter]

Thanks for confirming why the matrix is transposed during loading.

You have a lot more faith in compilers than I do. I would use mul(vec, matrix).

Original comment by callow.m...@artspark.co.jp on 11 Jun 2013 at 4:27