<p>There is no reason using two sets in this manner should be an efficiency issue unless they are being used in &quot;unusual&quot; ways like constantly switch the bindings(ie doing 10,000 draw calls and switching sets 10,000 times...but if that is true the code likely has bigger problems).</p>
<p>It has the potential to help with efficiency by making it easier for sets to be updated asynchronously, and work to be submitted asynchronously. VK_EXT_descriptor_indexing does allow a single set to be used very efficiently and is the reason you see a lot of code that only uses a single set.</p>
<p>But there are good reasons to keep multiple sets, and VK_EXT_descriptor_indexing updates can enhance those scenarios as well. I believe Valve in particular has a multi-set scheme used for updating sets. (My info on this is from a paper a couple years ago though and may have changed in the mean time)</p>
<p>The place you can get into trouble is creating many sets, and then juggling them and/or allocating vast resources inside the sets that go unused. Allocating to many resources inside a set is more common to single set use scenarios because it can be difficult to manage resources on a set that is continually in use. Also, programmers that use multiple sets seem to be more aware of the limitations. (but that is just anecdotal observations on my part)</p>
<p>Basically, keep the number of sets low, don't go crazy updating or rebinding things that don't need it, and be mindful of how many resources the sets are using.</p>

CC BY-SA 4.0
2024-07-11T13:51:07.093Z
Okay, will explore more in this topic in practice. Thanks.
Ciborg
CC BY-SA 4.0
2024-07-11T13:46:49.760Z
2024-07-11T13:46:49.760Z
pmw1234
<p>I am learning Vulkan, and through the process of developing a renderer by Vulkan guide(extra-engine sample), I got questioned whether I should use different sets for uniform buffers (camera data/global/etc..) and storage buffers(objects data) or one set for all these buffers is optimal. In Vulkan guide extra-engine, there are two sets in scene renderer for camera buffer and object data. What is optimal?</p>
<p>Are there any efficiency problems with using 1 set for global UBO data and storage buffers? Maybe it's a bottleneck or the wrong usage of the set. Or it's okay to do so?</p>

<c++><vulkan>
Set usage efficiensy and problems in VUlkan
Ciborg
# Set usage efficiensy and problems in VUlkan

(Asked by: username_0 on 2024-07-11)

I am learning Vulkan, and through the process of developing a renderer by Vulkan guide(extra-engine sample), I got questioned whether I should use different sets for uniform buffers (camera data/global/etc..) and storage buffers(objects data) or one set for all these buffers is optimal. In Vulkan guide extra-engine, there are two sets in scene renderer for camera buffer and object data. What is optimal?

Are there any efficiency problems with using 1 set for global UBO data and storage buffers? Maybe it's a bottleneck or the wrong usage of the set. Or it's okay to do so?

**Tags:** c++, vulkan


---

## 1 answers

### Answer by username_1 on 2024-07-11. Score: 0 | Accepted answer

There is no reason using two sets in this manner should be an efficiency issue unless they are being used in "unusual" ways like constantly switch the bindings(ie doing 10,000 draw calls and switching sets 10,000 times...but if that is true the code likely has bigger problems).

It has the potential to help with efficiency by making it easier for sets to be updated asynchronously, and work to be submitted asynchronously. VK\_EXT\_descriptor\_indexing does allow a single set to be used very efficiently and is the reason you see a lot of code that only uses a single set.

But there are good reasons to keep multiple sets, and VK\_EXT\_descriptor\_indexing updates can enhance those scenarios as well. I believe Valve in particular has a multi-set scheme used for updating sets. (My info on this is from a paper a couple years ago though and may have changed in the mean time)

The place you can get into trouble is creating many sets, and then juggling them and/or allocating vast resources inside the sets that go unused. Allocating to many resources inside a set is more common to single set use scenarios because it can be difficult to manage resources on a set that is continually in use. Also, programmers that use multiple sets seem to be more aware of the limitations. (but that is just anecdotal observations on my part)

Basically, keep the number of sets low, don't go crazy updating or rebinding things that don't need it, and be mindful of how many resources the sets are using.

> **Comments:**
> **username_0**: Okay, will explore more in this topic in practice. Thanks.  

---

