cube: Re-record command buffers each frame

Rerecord command buffers every frame, as command buffer recording isn't
slow, and outside of trivial samples (like vkcube) isn't a practical
architecture for organizing a Vulkan renderer. This makes vkcube and
vkcubepp reflect typical Vulkan renderer architecture and serves as a
better sample.

Create structs to organize objects into distinct synchronization scopes,
one for submissions and the other for swapchains. Resources associated
with a swapchain image such, as image views, framebuffers, and
presentation semaphores, must be duplicated as many times as there are
swapchain images. This number is dependent on the runtime, so can't be
pre-determined. The submission resources, which are the command buffers,
fences, descriptor sets, device memory, and uniform buffers, only needs
duplication for the pipelining. Specifically, this allows the GPU to
execute a command buffer while the CPU record the next frame's command
buffer. The FRAME_LAG constant dictates the pipeline depth, commonly
called double buffering, and is set to 2 since that is sufficient for a
vast majority of use cases.

Swapchain resizing now only re-creates the bare necessity of resources:
Swapchain, image views, framebuffers, presentation semaphores, and the
depth buffer. Presentation semaphores are recreated to prevent state
from an old swapchain from polluting a new swapchain. The depth buffer
is re-created since its size is dependent on the window size. All other
objects, such as pipelines and renderpasses, do not need recreation as
they either are not liable to change during resizing, or have mutable
state that can be flexibly updated, such as dynamic pipeline viewport
and scissors. The code for dynamic viewports and scissors was already
present but wasn't taken advantage of until now.

0 files changed, 0 insertions, 0 deletions