# glRotate vs D3DXRotationX

This topic is 4834 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hi friends, I made some perfomance tests comparing D3DX functions with my own functions. I noticed that D3DX functions are faster, probably because I used only C/C++ (no assembly). OK, my questions are: Are OpenGL/GLUT functions as fast as D3DX functions? For example: glRotate's performance == D3DXRotationX's performance? Is there some other free library as good as D3DX? Thanks in advance

##### Share on other sites
Technically, OpenGL is more low level, so it might actually be glRotate is faster, but that's just a guess if no one else helps.

##### Share on other sites
They don't do the same thing so you can't compare them. However, you could compare:
    glRotate();
vs.
    D3DXMatrixRotationX();    glMultMatrix();
1. The second is probably faster but maybe not. You must profile to get the real answer.
2. It probably doesn't matter which one is faster, so choose the cleanest solution.

##### Share on other sites
Ops, sorry... I meant D3DXMatrixRotationX instead of D3DXRotationX. Thanks for the answers.

Please, could you say me if there is some assembly code in glRotate function?
Would it be possible to use the math functions of D3DX with OpenGL on Linux?

Thanks again.

##### Share on other sites
the Matrix-operations are definitely faster when the proper codepath has been chosen (that is - after the first function-pointer has been dereferd) since both AMD and INTEL has been optimized the routines with SSE/SSE2/SSE3 and 3DNow/E-3Dnow

##### Share on other sites
Quote:
 Original post by Metusthe Matrix-operations are definitely faster when the proper codepath has been chosen (that is - after the first function-pointer has been dereferd) since both AMD and INTEL has been optimized the routines with SSE/SSE2/SSE3 and 3DNow/E-3Dnow

Very interesting, Metus. How could I choose the proper codepath? Is there some link where I could understand it better, see the code, etc?

Thanks again

##### Share on other sites
I think they are not different because a matrix rotation is the same operation.
The driver however can implement it in different ways; for example a driver can request the operation to the GPU or compute it using processor extensions.
In other words: DX and GL are API and these API can be implemented in different ways on different system. So we can have a bad GL implementation as well as a bad DX one!!!

If you want take a look at optimized CPU code you can download Mesa3D source code!

##### Share on other sites
Looking at http://msdn.microsoft.com/archive/default.asp?url=/archive/en-us/directx9_c_dec_2004/directx/graphics/programmingguide/FixedFunction/Transforms/transforms.asp it appears that glRotate has the potential to be faster.

While the implementation of D3DXMatrixRotationX is optimal for creating a rotation matrix, you then need to do two additional things when actually using that matrix:
1 - Multiply that rotation matrix by the current ModelView matrix
2 - Update any internally maintained auxiliary matrices (inverse ModelView, etc), if applicable to the current state.

Having glRotate as part of the core API allows a few further optimizations to be made to address those two points: Notice there are quite a few 1.0 and 0.0s in the rotation matrix. You can apply the sin and cos terms directly to the current modelview matrix without actually doing multiplies in the 1.0 and 0.0 cases. Further, you can also hardcode a form of the inverse matrices in exactly the same way as you would do for the rotation matrix, saving additional CPU time (doing a general 4x4 matrix inversion is EXPENSIVE).

If you just used glMultMatrix in place of glRotate, then OpenGL needs to do the general-form of matrix inversion (probably guass-jordan), rather than just multiplying by a pre-constructed inverse rotation matrix.

Moral of the story:
glRotate is better than glMultMatrix (you give GL more useful info)
How you get that matrix, D3DX or hand-rolled, is fairly straightforward (SSE will not help much here, there isn't much parallelism to be had).

##### Share on other sites
One additional note: The key to creating a rotation matrix really fast is that fsincos() function. sin() and cos() calculate a lot of common itermediate values, and if you do
sin(x);
cos(x);
then you're doing a lot of repeat work.

##### Share on other sites
Quote:
 Original post by RichardSOne additional note: The key to creating a rotation matrix really fast is that fsincos() function. sin() and cos() calculate a lot of common itermediate values, and if you dosin(x);cos(x);then you're doing a lot of repeat work.

Good information, RichardS. I didn't know fsincos() function.

Some days ago I made one test comparing D3DXVec3Normalize() with something like this (I wrote it just now):

D3DXVECTOR3 NormalizeVec(D3DXVECTOR3 *v){    FLOAT vLength = sqrt( v->x*v->x + v->y*v->y + v->z*v->z );    return D3DXVECTOR3 ( v->x/vLength, v->y/vLength, v->z/vLength ); }

and D3DXVec3Normalize() was much faster. How could I re-code it to get more efficiency?

Thanks again

1. 1
Rutin
40
2. 2
3. 3
4. 4
5. 5

• 18
• 20
• 12
• 14
• 9
• ### Forum Statistics

• Total Topics
633363
• Total Posts
3011511
• ### Who's Online (See full list)

There are no registered users currently online

×