- 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.
When a memory block is used for host-visible memory, its mapped pointer
is tracked with the block. If that memory is freed and later re-used
for some non-mappable memory, the pointer never gets cleared, and so
code thinks the memory is mappable and tries to use the pointer.
- Check for layers before enabling
- Check for instance/device extensions before enabling
Fixes unfriendly errors when running on a system without validation layers
installed.
Uses same table approach as OpenXR code.
Fixes easily-encounterable GPU OOM on discrete cards.
Currently when mapping CPU-accessible GPU memory, there are only two
types of memory: write and read.
The "write" allocations try to use the special 256MB pinned memory
region, with the thought that since this memory is usually for vertices,
uniforms, etc. it should be fast.
However, this memory is also used for staging buffers for buffers and
textures, which can easily exceed the 256MB (or 246MB on NV) limit upon
creating a handful of large textures.
To fix this, we're going to separate WRITE mappings into STREAM and
STAGING. STREAM will act like the old CPU_WRITE mapping type and use
the same memory type. STAGING will use plain host-visible memory and
avoid hogging the precious 256MB memory region.
STAGING also uses a different allocation strategy. Instead of creating
a big buffer with a zone for each tick, it's a more traditional linear
allocator that allocates in 4MB chunks and condemns the chunk if it ever
fills up. This is a better fit for staging buffer lifetimes since there's
usually a bunch of them at startup and then a small/sporadic amount
afterwards. The buffer doesn't need to double in size, and it doesn't
need to be kept around after the transfers are issued. The memory
really is single-use and won't roll over from frame to frame like the
other scratchpads.
There's a "portability enumeration" extension and flag you have to set
to get Vulkan to work on macOS. If you don't set it, Vulkan hides the
MoltenVK runtime since it's not 100% conformant. The flag was added
unconditionally, but it needs to only be added when the extension is
active.
- When a memory block was freed, any allocators that were using it need
to null out their memory blocks. Otherwise it would just keep using
the freed block.
- The emergency morgue expunge doesn't work. It would be nice if it
did, but if the emergency expunge deletes an object that exists in a
command buffer that's still being recorded, it causes all kinds of
problems and corrupts the command buffer. You'd either need to submit
these command buffers early before deleting the object (this is super
tricky) or just prevent this entirely, maybe by growing the morgue
infinitely or throwing an error if it fills up. Either way, creating
and releasing textures in a loop without submitting work will
eventually throw an 'out of memory' error. None of this is
satisfactory and I'm not sure how to solve this well yet.
- To compromise, increase the size of the morgue a bit so emergency
flushes happen slightly less often.
When multiview is not supported (although technically lovr requires it),
the renderSize limit for array layers was zero, which meant no render
passes would work. Instead, make sure it's at least 1, which is more
correct.
