MoltenVK does a lazy fetch of the drawable only when it's being modified, so waitToRender() is completely ineffective as is. Rendering a small empty overlay in waitToRender() forces the next drawable wait to happen in waitToRender(), before we pick the current frame to render. This removes one display refresh period of latency when using V-sync.
Direct-to-display mode on some Macs (M4 Mac Mini) can retain our drawables, which cuts the frame rate in half if we're in double-buffered mode.
We don't want to use triple-buffered mode all the time because it increases latency when used if not required, so detect delayed presentation and enable it on the fly if needed.
Whatever dGPU/eGPU rendering issues existed at the time I wrote that check seem to no longer happen on my RX 480 eGPU test setup running Ventura (our oldest supported OS).
It seems safe enough to enable now, especially since 7d6ce0b4c should catch broken systems and transparently fall back to AVSampleBufferDisplayLayer.
Fixes#1885
This causes POLLERR when decoding from meson-vdec on the Libre
Computer Alta (and likely other Amlogic boards). Our requried buffer
counts were already lower than the default 16/20 configuration that
FFmpeg uses, so overriding them was just a memory usage optimization.
AMDGPU disallows commits that would leave a CRTC active without
the primary plane enabled. Instead of disabling the primary plane,
simply restore the original state of the plane to avoid this.
This can be overriden with GL_IS_SLOW=0 at runtime
for systems with a fast GPU, though it doesn't make
much difference either way for non-KMSDRM cases.
For slower GPUs, this enables important scaling and
rendering optimizations that can substantially
improve performance (especially on fillrate-limited
GPUs common in SBCs).
We only need to do this on a SDL_RENDER_DEVICE_RESET where we lose the whole device.
This also reverts a56efe5 since this change is not needed when handling the reset events properly.
This significantly improves performance on Ryzen 3300U and should generally perform equal or better everywhere.
This decoder->SRV path has been prone to driver bugs, so we may need to adjust this logic if driver issues crop up.
- Waiting on this fence prior to rendering introduces pipeline bubbles which can impact rendering performance on low-end GPUs
- Pacer simply waiting to release the previous frame until after the current frame is rendered already means any decoder stall should be very short
Cameron Gutman