Jump to content

  • Log In with Google      Sign In   
  • Create Account


D3D11 XMVECTOR - Is it safe to always keep loaded?


Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
6 replies to this topic

#1 Muzzy A   Members   -  Reputation: 621

Like
0Likes
Like

Posted 06 December 2013 - 03:58 PM

I'm making a math library to make doing the XMVECTOR and XMMATRIX math a bit simpler, I want it optimized as much as possible so I want to load the vector as few times as possible... unless it's fast enough I don't have to worry about it?

 

Is it safe to always have data loaded for SIMD instructions? If not, is it going to slow the process down if I Load the XMVECTOR every time I do an operation?

 

I haven't messed with SIMD instructions much..



Sponsor:

#2 Zaoshi Kaba   Crossbones+   -  Reputation: 3403

Like
0Likes
Like

Posted 07 December 2013 - 04:17 AM

XMVECTOR and XMMATRIX are already easy to use. Even if you make own library it won't differ much and most likely will be slower.

 

 

 

Is it safe to always have data loaded for SIMD instructions? If not, is it going to slow the process down if I Load the XMVECTOR every time I do an operation?

 

What do you mean by "always have data loaded"?


Edited by Zaoshi Kaba, 07 December 2013 - 04:18 AM.


#3 Muzzy A   Members   -  Reputation: 621

Like
0Likes
Like

Posted 07 December 2013 - 09:15 AM

if i do this

 

XMVECTOR someVec = XMLoadFloat3( XMFLOAT3( 1,1,1 ) );

 

is it safe to store that as a data member?



#4 Adam_42   Crossbones+   -  Reputation: 2353

Like
2Likes
Like

Posted 07 December 2013 - 01:54 PM

It's safe to store it as a member as long as the thing it's a member of is allocated on a 16-byte boundary.

 

If it's heap allocated, that means you need to override global operator new and delete to get that alignment right. Unfortunately the standard Windows heap allocation functions only align to 8 bytes.



#5 Muzzy A   Members   -  Reputation: 621

Like
0Likes
Like

Posted 07 December 2013 - 02:18 PM

ok I see thanks for the help.

 

I wish I understood how aligning bytes worked better, I didn't learn much about it in school and it seems confusing as hell when I look online lol.



#6 Adam_42   Crossbones+   -  Reputation: 2353

Like
2Likes
Like

Posted 07 December 2013 - 08:03 PM

You just need to declare four new functions at global scope:

void* operator new (size_t size)
{
return _aligned_malloc(size, 16);
}

void operator delete (void *p)
{
_aligned_free(p);
}

void *operator new[](std::size_t size)
{
return _aligned_malloc(size, 16);
}

void operator delete[](void *p)
{
_aligned_free(p);
}

There's a slight complication that for completeness you'll probably want to overload the nothrow versions too, so you need 8 functions in total.
 
You may also want to make new throw appropriate exceptions, if you use them.


Edited by Adam_42, 07 December 2013 - 08:04 PM.


#7 Zaoshi Kaba   Crossbones+   -  Reputation: 3403

Like
0Likes
Like

Posted 08 December 2013 - 04:05 AM


is it safe to store that as a data member?

 

Load and Save operation are pretty much same as the ones in games; unless you save value it'll never get changed.

These functions exist because of data alignment. As Adam_42 mentioned you can overload new/delete operators.

This problem doesn't exist on 64 bit programs because alignment is suitable there, therefore you don't need Load/Save operations.






Old topic!
Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.



PARTNERS