-
Notifications
You must be signed in to change notification settings - Fork 402
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Need to correctly handle vertex attribute alignment (vec3, potentially more) #2182
Comments
More detailed information on the issue: Test allocates a buffer to store 2 attributes that will use later when drawing. The first attribute's type is short3 (in Vulkan terms The other changes other than padding the buffer that make the test also pass are:
Which raises the question of why do those 2 changes make the test work (haven't found any answer to those yet). The way to fix this from MoltenVK would be to add the padding ourselves whenever the user does not. This would require tracking buffers to understand when those are written to and reallocate and fill them with padding before usage. The change would imply a hit on performance due to the extra work required to be done by MoltenVK. Additionally, we could create a similar flag, or modify the existing flag I personally would like MoltenVK to take the first approach in the long run, but it may be interesting to pursue second option in the short term and come back to this issue once there's more time to invest here. Thoughts @billhollings |
Affected CTS tests:
Vulkan states (https://registry.khronos.org/vulkan/specs/1.3-extensions/html/vkspec.html#fxvertex-input-extraction):
If format is a packed format, attribAddress must be a multiple of the size in bytes of the whole attribute data type as described in Packed Formats. Otherwise, attribAddress must be a multiple of the size in bytes of the component type indicated by format (see Formats)
However, Metal has tighter requirements (Metal Shading Language Specification part 2.2)
The CTS test caught vec3 issues.
As an example, we need to modifyfloat3
topacked_float3
in the translation to MSL instead of trying to read it asfloat3
since that type requires 16 byte alignment when the buffer does not follow that. Unsure if SpirV-Cross changes may be needed.packed_float3
are not allowed as attributes so an alternative solution needs to be found.Ideally we also verify if there's any other affected case CTS testing does not catch.
Potentially related #1609
The text was updated successfully, but these errors were encountered: