libdrm is inconsistent between returning -1 with an errno set
and just returning -errno as the return value. Figuring out which
behavior a given libdrm function has require reading the source :/
As it turns out, there *are* in fact hardware vendors dumb enough
to ship V4L2 decoders that output buffers which are unsupported by
any plane on their display hardware. By checking modifiers, we can
still fall back to GLES on GL_IS_SLOW=1 builds in this case.
It doesn't work well in practice for a few major reasons:
- It can result in the decoder writing on DMA-BUFs being used by the display
- It can generate page flip events that collide with Qt/SDL
- It can stall the decoder if the DMA-BUF has a fence on it from the display driver
This significantly hurts performance on slower GPUs by preventing
the pipelining required when frametimes exceed the video frame
interval.
This reverts commit c26e437f40.
The platforms that would most benefit (embedded V4L2 decoders)
either don't use frame pooling or don't synchronize with
modified DMA-BUFs unless eglCreateImage() is called each time.
Every renderer except SDL had opted-in for testing due to various
quirks discovered over the years, so just do away with this option
and test all renderers.
We can avoid disabling EGL entirely by forcing Qt to use GLES,
which is not impacted by the black window issue. This lets us
simplify back to EGL everywhere.
The latter will still match on a hybrid system when the iGPU's EGL
implementation is in use. This scenario works properly with EGL
rendering in Qt and SDL, so we want to allow that.
Sharing these directly is fraught with concurrency issues that
require extreme care on both sides to avoid spurious X11 errors,
hangs, and other nasty stuff. We can't necessarily depend on SDL,
libva, or the underlying VA drivers to do the right thing here.
Using a new Display (as FFmpeg does for VAAPI and VDPAU) avoids
all these problems.
Uniforms are attached to the program object, so they don't need to
be set each time we swap between the YUV shader and the overlay
shader.
Since 0 overlays is by far the most common case and > 1 is highly
unlikely, move the glViewport() call into renderOverlay() to let
us skip it in the common case (and be no worse than today in the
2nd most common case of 1 overlay).
