I am trying to understand the better way to deal with descriptor set.
In my understanding, it is not a good idea to change the binding (I mean a changement of uniform buffer) a lot of times (say thousand times per frame).
However, when I think about “dynamic uniform buffer”, I did not really change the binding, but just the offset. So maybe the driver could optimize without making the binding change (even if the offset changement is done via vkCmdBindDescriptorSets).
So my question is : Does call a lot of times (thousands or tens of thousands times perf frame) vkCmdBindDescriptorSets with only the offset that change between each call is good for performance? I think yes because otherwise I don’t see the usefulness of dynamic uniform buffer…
[QUOTE=qnoper;42527]I am trying to understand the better way to deal with descriptor set.
In my understanding, it is not a good idea to change the binding (I mean a changement of uniform buffer) a lot of times (say thousand times per frame).
However, when I think about “dynamic uniform buffer”, I did not really change the binding, but just the offset. So maybe the driver could optimize without making the binding change (even if the offset changement is done via vkCmdBindDescriptorSets).
So my question is : Does call a lot of times (thousands or tens of thousands times perf frame) vkCmdBindDescriptorSets with only the offset that change between each call is good for performance? I think yes because otherwise I don’t see the usefulness of dynamic uniform buffer…[/QUOTE]
I don’t think it has too much impact in preformance, I think you will find the uniform buffer data limit (The limit thats unique to each GPU) would become a issue well before the amount of calls you pass through. Also make sure you construct your command buffers once and only update them when a object is added or removed from the scene, otherwise this will be a large drain on preformance (When creating your command buffers also make sure to use VK_COMMAND_BUFFER_USAGE_SIMULTANEOUS_USE_BIT to allow it to be passed multiple times).
Hope this helps but im quite new to Vulkan and this is from what I have seen myself, im not sure if there is a better buffer for large requests as i have not came across it yet.
Dynamic UBO changes will be at least no slower than non-dynamic ones. So if you’re going to have to change UBO data anyway, it’s best to do it with a dynamic offset than with a static descriptor.
I find many of these ideas for performance to be… dubious. Especially the “construct your command buffers once” thing, where you rebuild them when objects are added or removed. A system where you always rebuild your CBs, or a system where you never rebuild your CBs, would be better than one where you’re mostly not rebuilding them except sometimes you are.
If you’re always rebuilding your CBs, then you should be threading your rendering system, so as to spread the cost of CB construction across as many cores as possible. Here, you can use the most efficient form of CBs (ie: not having simultaneous use, which potentially imposes some overhead at submit time).
If you’re never rebuilding them, then you’re drawing objects based on indirect rendering data stored in GPU accessible memory. You stop drawing an an object by not giving it an indirect rendering command, not by rebuilding the command buffer.
But rebuilding simultaneous use CBs is pretty much the wrong way to go. Worst-case performance will always be worst than the worst-case for always-rebuild systems. And it will never be as fast as never-rebuild systems.