Fix ordering of descriptor set bindings
The Vulkan spec states that for vkCmdBindDescriptorSets():
"If any of the sets being bound include dynamic uniform or storage
buffers, then pDynamicOffsets includes one element for each array
element in each dynamic descriptor type binding in each set. Values are
taken from pDynamicOffsets in an order such that all entries for set N
come before set N+1; within a set, entries are ordered by the binding
numbers in the descriptor set layouts; and within a binding array,
elements are in order."
Using a direct-mapped array of bindings ensures we can easily compute
which descriptor each dynamic offset applies to. This is also supported
by the spec:
"The above layout definition allows the descriptor bindings to be
specified sparsely such that not all binding numbers between 0 and the
maximum binding number need to be specified in the pBindings array.
Bindings that are not specified have a descriptorCount and stageFlags of
zero, and the value of descriptorType is undefined. However, all binding
numbers between 0 and the maximum binding number in the
VkDescriptorSetLayoutCreateInfo::pBindings array may consume memory in
the descriptor set layout even if not all descriptor bindings are used,
though it should not consume additional memory from the descriptor pool.
The maximum binding number specified should be as compact as possible
to avoid wasted memory."
In addition, the spec states that for vkUpdateDescriptorSets():
"If the dstBinding has fewer than descriptorCount array elements
remaining starting from dstArrayElement, then the remainder will be used
to update the subsequent binding - dstBinding+1 starting at array
element zero."
Which also demands that the bindings in the descriptor set are sorted
by binding number.
Bug: b/154241029
Change-Id: Iae550a02bc9fa1132473c6ba4c5840440f970155
Reviewed-on: https://swiftshader-review.googlesource.com/c/SwiftShader/+/44308
Presubmit-Ready: Nicolas Capens <nicolascapens@google.com>
Tested-by:
Nicolas Capens <nicolascapens@google.com>
Reviewed-by:
Alexis Hétu <sugoi@google.com>
Kokoro-Result: kokoro <noreply+kokoro@google.com>
Showing
This diff is collapsed.
Click to expand it.
Please
register
or
sign in
to comment