[Bug 779146] dmabuf: be able to negotiate tiled surfaces

[GStreamer (GNOME Bugzilla)]

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

--- Comment #48 from Nicolas Dufresne (stormer) <nicolas at ndufresne.ca> ---
(In reply to Daniel Stone from comment #47)
> The model that KMS, Wayland, EGL, Vulkan, X11 DRI3, etc are built around, is
> that stride is determined (for each individual plane) in a device-specific
> way by whoever performs the allocation, attached to the plane, and passed to
> any consumers of the plane. 

In practice, during kmssink dev we found that most display driver does not
gives this liberty to the allocating party, resulting in hard failure (or
miss-rendering) if the expected stride and alignment is not met (also
type/location of physical memory, but that is just invisible to userpace, so I
keep it quite and hope that we have sys/iommus).

> Unfortunately GStreamer seems to have created
> stride exactly backwards - specific stride demanded by consumer which
> allocator must respect; attached to the logical image/framebuffer rather
> than each individual plane memory allocation - and that is unfortunate, but
> we can't change our model because it just won't work on hardware if we do.

This is a miss-interpretation of what GStreamer do with strides, and a
miss-understanding of the problems we are facing in user space today. The
problem with stride passing is that some (call them legacy) driver interface
provides 1 stride, regardless of the number of planes, and other passes (or
receive) multiple strides. This duality affects both DRM and V4L2 interface,
and probably other driver interface I'm not familiar with. So far, we handle
this in userpace because we know the format well enough that we can extrapolate
the other strides values, and that makes things works a lot more. GStreamer is
also stride/offset/alignment aware for a reason, it implements a large set of
software filters. These software filters are not always too slow, an example,
STM used the software renderers for sub-titles instead of dedicated plane. That
saved previous planes that could then be used by their compositor for other
tasks. But for that part, Olivier's protocol make sense, as these format are
not well known, they should not be considered raw formats in the GStreamer
sense.

When this interpolation is not possible or uncertain (requires too much
guessing), we end up with a support that can fail or miss-render on one system
and works on another. This is just a sample of the possible issues we keep
facing. If we just enable all this, it will fail in application it didn't fail
before.

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