KhronosGroup / Vulkan-Portability

Apache License 2.0
40 stars 4 forks source link

MoltenVK Vulkan 1.0: Metal shares binding count for constant buffers (uniform buffers) and device buffers (storage buffers) #64

Open aitor-lunarg opened 6 months ago

aitor-lunarg commented 6 months ago

Failing CTS test:

dEQP-VK.pipeline.monolithic.descriptor_limits.compute_shader.uniform_buffers_31

Vulkan provides VkPhysicalDeviceLimits::maxDescriptorSetUniformBuffers and VkPhysicalDeviceLimits::maxDescriptorSetStorageBuffers which lets the user know how many uniform/storage buffers (respectively) can be bound per stage. However, Metal has a shared binding count for both uniform (constant) and storage (device) buffers.

Now, MoltenVK sets both VkPhysicalDeviceLimits::maxDescriptorSetUniformBuffers and VkPhysicalDeviceLimits::maxDescriptorSetStorageBuffers to the maximum value Metal provides for buffer bindings. This is an issue because if the user decides to max uniform bindings (for example), and then bind one storage buffer, the storage buffer will go out of the allowed binding range for buffers leading to an error. This is what happens in the test.

A few potential approaches to fix the issue come to mind:

  1. Assign values to VkPhysicalDeviceLimits::maxDescriptorSetUniformBuffers and VkPhysicalDeviceLimits::maxDescriptorSetStorageBuffers such that the addition of both does not go beyond what Metal allows.
  2. Create a flag in the portability extension to let the user know the amount of buffer bindings are allowed, both uniform and storage in total.
  3. Request a waiver (not my preference).

Let me know if I missed something that would render my conclusion obsolete. Let me know if there's a preferred approach for the issue.