Some devices like Android smartphones have displays which are
rotated, meaning the compositor needs to rotate its output.
Add support for this to the compute compositor by rotating the
contents of the textures it uses for distortion lookups. This
requires postponing the calculation of that texture and adding
code to recreate it if the rotation changes (which is allowed,
but unlikely to happen in practice.)
Currently, there is a single command pool in the vk bundle, shared by
everyone. Since command pools (and command buffers allocated from those
pools) can only be used on one thread at a time, this requires locking.
However, the main point of having these annoying command pool things in
the first place is that you can use one for each thread/lifetime/area in
the app and avoid the overhead of the locks (both computational and
cognitive).
In this change I have given the rendering bits of the compositor its own
command pool. Instead of allocating and freeing a command buffer every
frame, a single command buffer is allocated from the pool during
initialization, and the pool is reset at the beginning of each frame.
Normally, multiple pools would need to be used, but this is not
necessary in monado because frames are serialized. The `TRANSIENT` and
`ONE_TIME_SUBMIT` flags have been added, which can allow for some driver
optimizations. The render code no longer takes out the command pool
mutex. The shared command pool is still there for a few remaining
places where vulkan work needs to be done outside the compositor.
I used the command buffer vulkan helpers when possible, but I would
maybe propose the idea of removing them, since they aren't really
wrapping much at this point. The `C` macro helps a lot and it's a bit
easier to see the Vulkan details in front of you instead of needing to
switch back and forth between the helper.
Later, I think it would be cool to apply and document some constraints
like "the queue is only accessed in functions XYZ, the render_resources
command pool must only be accessed in layer_commit from 1 thread" etc.
`queue_upload_for_first_level_and_layer` uploads pixels to an image.
It performs a layout transition, does the copy, and does another layout
transition. There is an execution dependency between the the copy and
the second layout transition, but the memory dependency was missing.
Caught/tested via enabling synchronization validation.
Fixes validation error when calling render_buffer_init_exportable
VUID-vkBindBufferMemory-memory-02726(ERROR / SPEC): msgNum: -168767885 - Validation Error: [ VUID-vkBindBufferMemory-memory-02726 ] Object 0: handle = 0xe88693000000000c, type = VK_OBJECT_TYPE_BUFFER; Object 1: handle = 0xcad092000000000d, type = VK_OBJECT_TYPE_DEVICE_MEMORY; | MessageID = 0xf5f0ce73 | vkBindBufferMemory(): The VkDeviceMemory (VkDeviceMemory 0xcad092000000000d[]) has an external handleType of VK_EXTERNAL_MEMORY_HANDLE_TYPE_OPAQUE_FD_BIT which does not include at least one handle from VkBuffer (VkBuffer 0xe88693000000000c[]) handleType Unhandled VkExternalMemoryHandleTypeFlagBits. The Vulkan spec states: If the value of VkExportMemoryAllocateInfo::handleTypes used to allocate memory is not 0, it must include at least one of the handles set in VkExternalMemoryBufferCreateInfo::handleTypes when buffer was created (https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-vkBindBufferMemory-memory-02726)
Objects: 2
[0] 0xe88693000000000c, type: 9, name: NULL
[1] 0xcad092000000000d, type: 8, name: NULL
Some downstream user might want to use the very handy comp_buffer_init()
helper to create buffers, but the latter does not cover the case when
the buffer needs to be exportable for API interoperability.
Add a new comp_buffer_init_exportable() helper to cover that case, this
is done in a way that is not particularly invasive for existing users of
comp_buffer_init(), as all the logic about the exportability is handled
by the new function.
The size field in comp_buffer was never assigned, and also never used as
all comp_buffer users rely on the allocation_size field.
Use the size field to store the size originally requested when creating
the buffer which could be different from the value returned in the
allocation_size field.
Having both sizes available allows a user to check if allocation_size is
in fact different from the requested size.
