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

[GStreamer (GNOME Bugzilla)]

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

--- Comment #49 from Daniel Stone <daniel at fooishbar.org> ---
(In reply to Nicolas Dufresne (stormer) from comment #48)
> (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).

If you're using dumb buffers, then you do not get to even try to specify the
stride: stride is an out-value only, along with the handle. For other buffers,
the drivers I've worked with fail when required stride alignment is not met. If
you find drivers which accept buffers with particular stride values but fail to
display them correctly, please do file bugs.

> > 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.

Where does it affect it with DRM? When creating dumb buffers in DRM, there is a
single stride and a single handle: dumb buffers only support single-planar
formats, and only linear (no modifiers). This is by design of dumb buffers.
drmModeAddFB takes a single stride token, but again, it only supports
single-planar formats. drmModeAddFB2 and drmModeAddFB2WithModifiers take
per-plane stride/offset/handle.

Wayland's dmabuf interface has per-plane stride/offset/fd, as do the EGL and
Vulkan dmabuf import interfaces. So I don't know of anywhere in the graphics
world where stride is magically inferred from one plane to the other, except
for X11 Xv.

> 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.

That makes sense, again as long as you a) ensure the buffers are linear, or b)
implement detiling/decompression for whatever modifiers you receive.

> 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.

I still don't really understand the problem. Is it just that some unnamed KMS
drivers display the wrong content when stride alignment does not meet their
expectations?

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