Jump to content
  • Advertisement
Sign in to follow this  
JMab

16 byte aligned member variables, HOW!?!?!?

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

If you intended to correct an error in the post then please contact us.

Recommended Posts

OK, I've got my 16-byte aligned matrix, derived from D3DXMATRIXA16. If I declare it locally, it retains it's 16-byte alignment. If I declare it as a static member variable, it retains it's 16-byte alignment. However, if I declare it as a instance member variable, it loses it's 16-byte alignment (I suspect because I am "new"-ing the Camera class that contains a number of my matrices. I've tried declaring __declspec(align(16)) on each member variable, i.e. struct __declspec(align(16)) Matrix4 : public D3DXMATRIXA16 { }; class Camera { private: __declspec(align(16)) Matrix4 m_MatSkyBox; }; But it doesn't work. PLEASE HELP! Is there any way to use 16-byte aligned, instance member variables in a class that has been "new"-ed?

Share this post


Link to post
Share on other sites
Advertisement
Quote:
Original post by JMab
PLEASE HELP! Is there any way to use 16-byte aligned, instance member variables in a class that has been "new"-ed?
Not that I know of. You'd have to allocate the matrix with an aligned version of new (or malloc), or have a 31-byte array as a member instead, and initialise a pointer to point into that array pretending it's an aligned matrix (If that makes any sense...).

__declspec(align) only has any effect for members allocated on the stack (Or as a static var)

Share this post


Link to post
Share on other sites
Alternatively, you can overload the new and delete operators so that they allocate memory that is aligned to some value:


void *operator new(size_t sz)
{
return _aligned_malloc(sz, MEMORY_ALIGNMENT);
}

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

void *operator new[] (size_t sz)
{
return _aligned_malloc(sz, MEMORY_ALIGNMENT);
}

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




change MEMORY_ALIGNMENT to 16, as per the OP.

Share this post


Link to post
Share on other sites
Thanks for the quick replies.

While I was busy overriding my new and delete, I checked and realised that I wasn't actually "new"-ing my Camera class, but I was "new"-ing the Scene class that contained it. By making my Scene class an instance member variable of my Application class, I get 16-byte aligned matrices everywhere, lovely.

Share this post


Link to post
Share on other sites
I'd be hesitant about overloading global operators new and delete; that'd cause all allocations to be 16-byte aligned, which might be overkill. Member operator new would be a better solution.

Share this post


Link to post
Share on other sites
Absolutely. Although I am overriding new and delete globally, they call into my (static) MemoryManager::Alloc method with a parameter of ALIGN_DEFAULT, which ends up being ALIGN_NONE by default. For a class to be 16-byte aligned, it needs to override new and delete in the class and call MemoryManager::Alloc passing ALIGN_16.

I have an implementation of Thatcher Ulrich's chunked LOD terrain system. I have a ChunkTerrainSection class, which is a TerrainSection class, which is a SceneObject class, which is a SceneNode class which contains 3 Matrix4 instances (local, world and inverse-world transforms).

The ChunkTerrainSections are instantiated on the fly. Unfortunately (I think), I haven't tried it yet, but I believe in this implementation I would have to override new and delete in ChunkTerrainSection and 16-byte align it and everything it contains to get 16-byte aligned Matrix4's.

This does seem like overkill, but I'm currently writing a code profiler to test if it really is. I've been toying with the idea of assigning a non 16-byte aligned matrix to a local 16-byte aligned matrix in my MatrixMultiply, etc methods. I also need to profile this, but it could be faster.

Anyone has experience with the above issues?

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!