In my implementation I decide to record command buffer only when the number of geometries changes or are switched.
let say I have 3 cubes then as long as I only have the SAME 3 cubes I will just present the VkCommandBuffer[image_index].
However if one cube is let say temporary destroyed and has to reappear after a little while I have 2 Ideas now to do it but I don’t know about performance:
1/ all cubes are in geometries_map. if I have to hide a cube i just remove it from the map and record the command-buffers and submit it again.
2/ I change nothing else than the uniform value of that cube to scale it to vec3(0.0f) so it is invisible.
the second is easier to implement and on CPU side it looks faster than updating geometries_map. But I have no idea of what is happening on GPU side… I hope that a scaled vec3(0.0f) object is just ignored.
At the present moment I use 2 but I don’t like the fact that I don’t know about performances. I may need to hide thousand of more complex objects.
How do you do that? If you’re changing memory, that would require a full CPU/GPU synchronization, since you can’t modify GPU-accessible memory that the GPU is potentially reading from. And if you’re double-buffering memory (so that you’re modifying one while the other is being read from), you’d also need to be double-buffering command buffers.
There are no “uniforms” in Vulkan. There are UBOs, and there are push constants. UBOs are memory resources, and while you can change the underlying memory, you cannot modify that memory while a command buffer using that range of memory is being executed by the GPU. And push constant values are baked into the command buffer, so you cannot modify them without modifying the CB.
It there something wrong with what I am doing here? the only thing I can say is at least it’s show/hide my object when I scale 1.0f/0.0f.
But based on your previous answers looks like I should modify also the command buffer !?
This is not a function you use if CPU performance matters to you. Not unless you have run out of anything else your thread could possibly be doing. And even then, you should not be waiting on a fence for a batch you just submitted; you want CPU/GPU execution overlap.
You should unmap a piece of memory exactly once: when you are about to delete it. Vulkan is not OpenGL; you can (and should) keep memory mapped indefinitely (and modern OpenGL lets you do that).
So as I said: you need to double-buffer your memory, so that you don’t do a full CPU/GPU sync every frame. But that means double-buffering your command buffers too.