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
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.
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
At best, it doesn't do anything other than some queue some viewport
changes via SDL_RendererEventWatch(). At worst, it can race with
the render thread and cause trouble.
- Avoids requiring a hardcoded number of frames (and creating surfaces ourselves)
- Removes a ton of unnecessary code that's duplicated in FFmpeg
- Supports dynamic frame sizes, formats, and color conversion
- Supports frame cropping in FFmpeg
Cameron Gutman