You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I had an issue where creating a Vulkan feature struct ended up with a rounded alignment (32 bytes), but the same structure created in another context was not aligned (28 bytes).
This made the resulting detail::GenericFeaturesPNextNodes different.
I was trying to use PhysicalDevice::are_extension_features_present with the 28-byte version as a parameter, and the function returned an unexpected result as the stored feature had been aligned to 32 bytes.
Based on the differing "last" 4 bytes I got the result that the requested feature is not supported, whereas this is not true.
Compiled with:
Clang version 17.0.6
Target x86_64-w64-windows-gnu
The text was updated successfully, but these errors were encountered:
I didn't forget about this - I just had other priorities since this issue was created.
The real solution is to generate all the struct comparisons. I cannot see a way to do generic struct comparisons that ultimately doesn't leave the code liable to padding concerns. sizeof cannot be trusted to yield useful values.
I started working on a branch which does the codegen, but it became a bigger task than I could finish in a day and had to put it to the side for the time being.
I had an issue where creating a Vulkan feature struct ended up with a rounded alignment (32 bytes), but the same structure created in another context was not aligned (28 bytes).
This made the resulting
detail::GenericFeaturesPNextNode
s different.I was trying to use
PhysicalDevice::are_extension_features_present
with the 28-byte version as a parameter, and the function returned an unexpected result as the stored feature had been aligned to 32 bytes.Based on the differing "last" 4 bytes I got the result that the requested feature is not supported, whereas this is not true.
Compiled with:
Clang version 17.0.6
Target x86_64-w64-windows-gnu
The text was updated successfully, but these errors were encountered: