[Bug 793339] kmssink: Renders at half my display refresh rate

[GStreamer (GNOME Bugzilla)]

https://bugzilla.gnome.org/show_bug.cgi?id=793339

Daniel Stone <daniel at fooishbar.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |daniel at fooishbar.org

--- Comment #13 from Daniel Stone <daniel at fooishbar.org> ---
(In reply to Nicolas Dufresne (ndufresne) from comment #9)
> After rethinking this, if this patches is needed, it means that KMS Atomic
> drivers are simply not backward compatible peformance whise. At the same
> time, I'm pretty sure Devarsh is getting full frame rate with this patch,
> and I also see full framerate on i915. I'm wondering what would triggers
> this on Rockchip ...

It's not a matter of atomic vs. non-atomic drivers, it's that there is
absolutely no specification of what SetPlane does. Some drivers block until the
next vblank to apply, and some do no blocking at all - even to the point of
generating pagefaults and display glitches if you destroy a buffer which is
still active on a plane.

Most atomic drivers wait until vblank, but not all (e.g. amdgpu still does it
async, although I believe only on older hardware, and newer hardware has the
blocking behaviour). Most non-atomic drivers are non-blocking, but some are
blocking. Many drivers (e.g. exynos and I believe also rockchip) changed their
behaviour with different kernel versions.

The only way to get predictable and reliable behaviour from KMS planes is to
use the atomic API. This has always been the case, and is the reason why Weston
never used planes unless the user explicitly enabled them with a magic key
combination. On the other hand, using atomic allows us to enable use of overlay
planes by default.

As an aside, the scaling behaviour is also completely unspecified when using
SetPlane. If the hardware cannot apply the requested scaling factor, drivers
may clip or enlarge either source or destination bounds completely arbitrarily
in order to get _some_ kind of image on screen. This becomes an error in
atomic, so it's possible that flipping the client cap on just exposes this
rather than silent clipping or rounding.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.