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.
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.
Fixes a validation layer, and may result in performance improvement. I
think this technically means you can't do discard/FragDepth to adjust
depth buffer values, but that's kinda niche.
Goal is to support more combinations of shader stages, both for
vertex-only shaders and mesh/raytracing shaders in the future. In
general most of the logic that conflated "stage count" with "shader
type" has been changed to look at individual shader stages.
Arrays of bindings is really bad for API usability so the existing
single-descriptor API remains backwards compatible -- if you specify a
count of zero then the old "by-value" union entry is used, but you can
specify a count > 0 and then it will use an array of bindings.
The morgue is a fixed-size queue for GPU resources that are waiting to
be destroyed. There's been an annoying issue with it for a while where
destroying too many objects at once will trigger a "Morgue overflow!"
error. Even innocuous projects that create more than 1024 textures will
see this during a normal quit.
One way to solve this problem is to make the queue unbounded instead of
bounded. However, this can hide problems and lead to more catastrophic
failure modes.
A better solution is to add "backpressure", where we avoid putting
things in the queue if it's full, or find some way to deal with them.
In this case it means finding a way to destroy stuff in the morgue when
it's full, to make space for more victims.
We weren't able to add backpressure reliably before, because command
buffers could have commands that reference the condemned resources.
This was mostly a problem for texture transfers -- if you create
thousands of textures in a loop, we'd have a giant command buffer with
commands to transfer pixels to the textures. If these textures were
destroyed before submitting anything, the morgue would fill up, and we
wouldn't have any way to clear space because there was still a pending
command buffer that needs to act on the textures!
A simple change is to flush all pending transfers whenever a buffer or
texture is destroyed. This lets us add backpressure to the morgue
because we can guarantee that there are no pending command buffers that
refer to an object in the morgue.
For backpressure, we try to destroy the oldest object in the morgue if
the GPU is done using it. If that doesn't work, we'll wait on the fence
for its tick and destroy it. This *should* always work, although in an
extreme case you could vkDeviceWaitIdle and clear out the entire morgue.
It should also be noted that in general command buffers need to be
flushed when destroying objects that they refer to. However, for our
particular usage patterns, we only need to flush state.stream when a
buffer or texture is destroyed. Pass objects already refcount their
buffers and textures and their commands are software command buffers, so
they don't require any special handling. Other objects like shaders,
pipelines, descriptor set layouts, etc. all survive until shutdown, so
those don't impact anything either.
There were numerous problems with the previous effort to add support for
linear views of sRGB storage textures. Here's another attempt:
- Images are always created with the linear version of their format.
- The default texture view uses the sRGB format if the parent is sRGB.
- Use ImageViewUsageCreateInfo to specify the usage for render/storage views.
- sRGB image views always have their storage bit forcibly cleared.
The storage view now behaves more like the existing renderView -- if we
detect that you couldn't use the default texture view for storage, we'll
create one that is guaranteed to be usable for storage bindings (by
clearing the sRGB flag on it).
- Cubemaps can have any layer count that is a multiple of 6.
- A cubemap with more than 6 layers will be a cubemap array image view.
- This isn't perfect because it conflates regular cubemaps with
6-layer cubemap arrays.
- Enable the vk feature, handle the spv feature, add getPixel helper.
- 'sample' now implies both sample and linear filtering (practically always
true for all formats lovr supports)
- 'render' now includes 'blend' for color formats (also practically
always true except for r32f on some old mobile GPUs)
- 'blit' now includes 'blitsrc'/'blitdst' because lovr doesn't support
blitting between textures with different formats
- 'atomic' is removed because lovr doesn't really support atomic images yet
- rm :getTallyData, it's totally lame, just do a readback
- rm gpu_tally_get_data too, webgpu doesn't support it anyway
- Clamp tally copy count so it doesn't overflow buffer
- Tally buffer offset's gotta be a multiple of 4
- Return nil instead of 2 values when tally buffer isn't set
- Copy correct number of tallies (multiply by view count instead of max
view count)
- Skip occlusion queries entirely if no tally buffer was set
Restores ability to open window after initializing graphics module.
Surface is created lazily instead of being required upfront.
Use native platorm handles instead of GLFW's callbacks.
Some minor reorganization around core/gpu present API and xr transitions.
Linux links against libxcb/libX11/libX11-xcb for XGetXCBConnection.
This reverts commit b7a00c82d1.
I think srgb-encoded rgb10a2 swapchains require manual gamma correction
in shaders (?!), which we aren't quite ready for yet because shaders don't
know the "color space" of their canvas textures.
Pass stores draw commands rather than sending them to Vulkan
immediately.
The main motivation is to allow more flexibility in the Lua API. Passes
are now regular objects, aren't invalidated whenever submit is called,
and can cache their draws across multiple frames. Draws can also be
internally culled, sorted, and batched.
Some API methods (tallies) are missing, and there are still some bugs to
fix, notably with background color.
- Add Buffer:newReadback
- Add Buffer:getData
- Buffer:getPointer works with permanent buffers
- Buffer:setData works with permanent buffers
- Buffer:clear works with permanent buffers
- Add Texture:newReadback
- Add Texture:getPixels
- Add Texture:setPixels
- Add Texture:clear
- Add Texture:generateMipmaps
- Buffer readbacks can now return tables in addition to Blobs using Readback:getData
Tally is coming back soon with an improved API, it's temporarily removed
since it made the transfer rework a bit easier.
Note that synchronous readbacks (Buffer:getData, Texture:getPixels)
internally call lovr.graphics.submit, so they invalidate existing Pass
objects. This will be improved soon.
If the target index is missing, the state will apply to all targets.
Fixes undefined behavior when setting color state in a pass with
multiple color attachments.
- Allow multisampled render pass to have a single-sample depth attachment
- Add a new depthResolve feature, indicating whether it's supported
- Fix stencil load/save
- Minor changes to render pass caching
- Currently the depth resolve is done using the first sample. A future
improvement would be to expose/use the min/max/average resolve modes.
