- When destroyed, Pass should only recycle its buffer if it actually has one.
- When resetting, chain all of the buffers at once instead of one-by-one (N^2)
Basically it's somewhat common for depth-stencil formats to not support
linear filtering and that is kind of annoying because you can't create
depth textures with the `sample` usage. Instead we'll just ignore the
LINEAR format feature bit for now.
In the future I'd like to fix this by silently demoting individual
texture's filtering to nearest when linear is not supported for the
format, but this requires per-texture sampler settings which isn't done
yet.
This shaves 20 bytes off of each model vertex, or around 40% savings.
The vertex size is also a power of two which results in extreme amounts
of style points.
Currently pipeline compilation accesses the render pass cache, which
presents thread safety challenges. The framebuffer and render pass
caches are also slow and gross.
This adds a `gpu_pass` object which is basically just a VkRenderPass
object. The graphics module creates and caches these in
`lovrPassSetCanvas`. They are used when compiling pipelines and
beginning render passes.
Framebuffers are no longer cached but are just created and immediately
condemned dynamically when beginning a render pass. This is fine,
because framebuffers are super cheap.
There's still technically a thread safety issue with the `gpu_pass`
object caching, but it's much easier to solve that with a lock in
`lovrPassSetCanvas` compared to trying to make core/gpu's render pass
cache thread safe.
This is all still a temporary measure until we can use a more
"ergonomic" render pass API like dynamic rendering.
Oh also we stopped using automatic layout transitions because they seem
to be pessimistic in drivers and require tying render pass objects to
texture usage which is annoying. So now we do attachment layout
transitions manually before/after beginning/ending a render pass, which
isn't so bad.