Author
I've been looking at xnamath, and just wanted to confirm if my understanding at a high-level is correct.
Basically, there are two core types: XMVECTOR and XMMATRIX. These are the optimized hardware representations of vectors and matrices.
Because these types are implemented specially for hardware, you should not access the raw data directly. Instead, you are supposed to use the accessor, load, and store functions.
Other than that, it seems pretty much the same as the old D3DX library--just calling the XM* math functions (like XMVector3Cross).
The only thing that sort of bothers me and is cumbersome is having to convert to the XM types back and forth and use funny accessor syntax. This conversion also is necessary when submitting vectors/matrices as shader parameters in constant buffers. So I'm wondering for situations where you are not doing a lot of math calculations on the CPU, if xnamath doesn't benefit (due to conversion overhead). Also it looks like a lot of the DirectX11 samples use both xnamath and the old D3DX math types.
Also, I thought that the old D3DX math library also did CPU hardware optimizations. So why was there a need for a new library (other than also working on XBOX 360)? In other words, will a PC program see any gains with xnamath over D3DX?
The load and store methods for vectors seem to compile into efficient load and store instructions so it's probably not inefficient. And D3DX math functions probably use those loads and stores anyway so they can use sse math, it's just that you don't see them...
Hmm, I'm just casting my XMMATRIX to (float*) to pass to shaders, that seems to work reliably. Am I missing something?
Hmm, I'm just casting my XMMATRIX to (float*) to pass to shaders, that seems to work reliably. Am I missing something?
I don't know what microsoft's motivation for a new library was, but for me it has the huge advantage of being independent of the version of directx so I can use the math types in my main code that is supposed to be independant from a specific version of direct3d.
XNAMath does several good things. It works on PC and xbox supporting optimizations in both. It also allows dev and test effort to be put into 1 library instead of 2. It fragments the community less, and is overall less confusing. It will take time to change over all of the samples, if that is even a goal.
Try to keep your data in the XMVector and XMMatrix types as much as possible. As jbb pointed out, there are SSE intrinsics for copying data into the special registers -- so using these is the preferred choice for performance.
Accessing data in the special types for non-SIMD calculations will result in the CPU having to first move the data out of the special SIMD registers and into the serial CPU registers -- which results in performance loss. If you look at SSE code, some instructions do odd things with the reasoning being to keep the data in SIMD registers and making it possible to do further calculations in SIMD. Doing a dot product without the special SSE4.x intrinsic is a simple example of this.
Converting the types to float* or int* for loading into cbuffers is the best thing to do otherwise you'd have to do 2 data copies instead of 1.
If storage space is a problem, then storing things like a matrix 3x3, or a smaller vector type in your code makes sense since the XMVector and XMatrix are 4 and 16 respectively in size. If you ensure data alignment in your own types, then the loads/stores will be just as fast as if they were already in XMVector or XMMatrix.
Try to keep your data in the XMVector and XMMatrix types as much as possible. As jbb pointed out, there are SSE intrinsics for copying data into the special registers -- so using these is the preferred choice for performance.
Accessing data in the special types for non-SIMD calculations will result in the CPU having to first move the data out of the special SIMD registers and into the serial CPU registers -- which results in performance loss. If you look at SSE code, some instructions do odd things with the reasoning being to keep the data in SIMD registers and making it possible to do further calculations in SIMD. Doing a dot product without the special SSE4.x intrinsic is a simple example of this.
Converting the types to float* or int* for loading into cbuffers is the best thing to do otherwise you'd have to do 2 data copies instead of 1.
If storage space is a problem, then storing things like a matrix 3x3, or a smaller vector type in your code makes sense since the XMVector and XMatrix are 4 and 16 respectively in size. If you ensure data alignment in your own types, then the loads/stores will be just as fast as if they were already in XMVector or XMMatrix.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
