I've been using D3D11_APPEND_ALIGNED_ELEMENT in my vertex declarations (D3D11_INPUT_ELEMENT_DESC) for a long while with no issues. While chasing down some rendering skinning issues, it led me to scrutinize my input layouts as a potential source of error. As has been brought up in numerous places (including here), there is some ambiguous text in the documentation for D3D11_APPEND_ALIGNED_ELEMENT, which states:

“Use D3D11_APPEND_ALIGNED_ELEMENT for convenience to define the current element directly after the previous one, including any packing if necessary.”

I have yet to find any definitive answer to what “necessary packing” implicates insofar as element layout/size is concerned. To date, I have been using the default padding/packing (as far as Visual Studio/C++ is concerned) for my vertex data, and this seems to have been working fine. But now I am questioning if I have perhaps constructed a layout that is introducing some packing/padding that might be tripping things up.

Does anyone know what D3D11_APPEND_ALIGNED_ELEMENT is doing/expects with regards to packing?

I tracked down my issue, which ended up not being anything to do with the input element descriptions. However, the question still remains as to what packing the documentation is referring to. My only reasonable guess is that it's talking about packing/padding that may be implicitly present as part of a weird DXGI_FORMAT (like if, hypothetically, there was some oddball format like R9G10B9, that would actually take up 32 bits to fit on a word boundary or the like).