-
Notifications
You must be signed in to change notification settings - Fork 453
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
KHR_vulkan_glsl: Does not recognize interface block array differences. #514
Comments
I've investigated how glslangValidator generates code for this. The shader:
Becomes:
This clearly creates a single binding point, which is an array of But it doesn't match with section 4.4.5 of the GLSL specification, which KHR_vulkan_glsl does not modify:
|
Should be fixed in the 1.0.56 spec update. |
In OpenGL's GLSL, arrays of interface blocks take up sequential binding indices. In Vulkan however, arrays of interface block only take up one binding point in SPIR-V. Or at least, they are allowed to.
The KHR_vulkan_glsl extension recognizes that arrays of opaque types are stored in one binding point. But it never changes the paragraph in 4.4.5 that discusses arrays of interface blocks (UBOs/SSBOs). By a strict reading of the specification, this means that an array of uniform blocks:
This array should take up binding points 2, 3, 4, 5, and 6. in the descriptor set. But while this is valid, it is not necessary, as both SPIR-V and Vulkan have provisions for allowing such a uniform block to take up just one binding point. There does not appear to be anything in the Vulkan specification which prevents a descriptor set layout from specifying a
descriptorCount
greater than 1 for descriptors of typeUNIFORM_BUFFER
. And there is nothing in the SPIR-V specification which prevents a Block-decorated object from having an array count.I have not investigated how glslangValidator compiles arrays of uniform/storage blocks.
The text was updated successfully, but these errors were encountered: