I am working on an instancing test and my objects were not showing up correctly. I looked at the d3d10 Instancing sample and noticed they prefix row_major for their instanced matrix:
row_major float4x4 mTransform : mTransform;
Adding this prefix fixed my code. How come this is necessary? I do not need this prefix for my global shader float4x4 variables. I do row-vector-matrix style ordered multiplication: mul(vector, matrix).
row_major
I am working on an instancing test and my objects were not showing up correctly. I looked at the d3d10 Instancing sample and noticed they prefix row_major for their instanced matrix:
row_major float4x4 mTransform : mTransform;
Adding this prefix fixed my code. How come this is necessary? I do not need this prefix for my global shader float4x4 variables. I do row-vector-matrix style ordered multiplication: mul(vector, matrix).
Shaders default to column-major packing in constant buffers, unless you pass D3D10_SHADER_PACK_MATRIX_ROW_MAJOR when compiling them. They do this because vector-matrix transformation can be expressed a bit more efficiently with column-major matrices. If you use the effects framework, it will automatically transpose matrices for you when you set them so that they patch the packing order. For instancing it makes more sense to use row-major packing, so that you can memcpy all of your matrices into your constant buffer without needing to transpose them.
I am sorry for posting it here, but the topic is quite close to what I would like to ask.
If shaders prefer to work with column-major matrices (so that the vector-matrix multiplication can be done with 4 dot-products) why does D3DX use row-major matrices?
For my engine I am now thinking of using column-major matrices for system memory, but since both Direct3D and OpenGL prefer "translation in 12, 13, 14" matrix layout instead of "translation in 3, 7, 11" one, there seems to be a hidden reason behind storing matrices as "12,13,14" in the system memory and as "3,7,11" in the video memory.
Is there really a serious performance-related reason for that or is that just a legacy from the software vertex processing times?
If shaders prefer to work with column-major matrices (so that the vector-matrix multiplication can be done with 4 dot-products) why does D3DX use row-major matrices?
For my engine I am now thinking of using column-major matrices for system memory, but since both Direct3D and OpenGL prefer "translation in 12, 13, 14" matrix layout instead of "translation in 3, 7, 11" one, there seems to be a hidden reason behind storing matrices as "12,13,14" in the system memory and as "3,7,11" in the video memory.
Is there really a serious performance-related reason for that or is that just a legacy from the software vertex processing times?
For instancing it makes more sense to use row-major packing, so that you can memcpy all of your matrices into your constant buffer without needing to transpose them.
Why we can't memcpy() column-major matrices? It's still simply 64 bytes in the memory, just in different order.
why does D3DX use row-major matrices?
I'm not exactly sure, but I think DirectX9 was row-major (or maybe previous versions). Changing math in the update would mess up a lot of code which assumes row-major order, therefore they couldn't do it. (random guess, not actually an information)
Furidan:
I couldn't really tell you why math libraries typically use row-major matrices, it's not really my area of expertise. If I recall correctly CPU SIMD instruction sets like SSE didn't have dot product support so that may have been a factor.
Ripiz:
I wasn't saying you can't memcpy column-major matrices, I was saying that you can't memcpy row-major matrices into a buffer that expects column-major matrices. You would have to transpose each matrix individually as you copy it in.
I couldn't really tell you why math libraries typically use row-major matrices, it's not really my area of expertise. If I recall correctly CPU SIMD instruction sets like SSE didn't have dot product support so that may have been a factor.
Ripiz:
I wasn't saying you can't memcpy column-major matrices, I was saying that you can't memcpy row-major matrices into a buffer that expects column-major matrices. You would have to transpose each matrix individually as you copy it in.
Furidan:
I couldn't really tell you why math libraries typically use row-major matrices, it's not really my area of expertise. If I recall correctly CPU SIMD instruction sets like SSE didn't have dot product support so that may have been a factor.
Thank you for the info. I will just use column-major matrices everywhere then
.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
