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.
Previously this was using math_quat_len which was always 1 for
these unit quaternions. This commit assumes math_quat_ln works properly which is
not exactly true at the moment and the returned angle will be twice as large.
Previously, math_pose_invert would apply a multiplication in the wrong
order. This lead to the position of the 'original' pose being rotated.
This patch fixes that, and adds a unit test to check this case.
An isometry is a rigid body transform. In this context I'm using the term to
refer to 4x4 homogeneous matrices in SE(3). I.e., matrices comprised of a
3x3 rotation, a 3x1 translation, and a [0,0,0,1] last row.
This matrix represent both rigid body transforms.
Isometry3f is a 4x4 matrix transform that performs only rotation and translation
(an SE(3) matrix). Its inverse can be computed trivially by Eigen compared to a
regular 4x4 transform.
