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

[GStreamer (GNOME Bugzilla)]

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

--- Comment #47 from Daniel Stone <daniel at fooishbar.org> ---
(In reply to Nicolas Dufresne (stormer) from comment #46)
> The mains problem remains the stride and other memory related. The thing
> that comes out is that it's given back at allocation time. With this
> proposal, there is no possible to fallback because GST does not have the
> knowledge. So everything has to be in the caps (stride, size, alignment,
> number of memory segment, etc) if you want any guarantee that the buffer
> exchange to work. Allocating for every format to get the info make no sense
> and asking for API will just never happen. So how do we make it work, not
> just sometimes and by chance ?

Sorry, I don't really understand the question: what is not working today, that
you would like to 'make work'?

If you're looking for a generic formula which will let you calculate the stride
for some given configuration in a totally generic way, no, we just don't have
that. (Though the work on the 'allocator' project is intended to provide this
to client applications, provided you can reason about producer/consumer devices
when allocating.)

Display _hardware_ (again, this is not an arbitrary rule invented for fun in
drivers because hate our users - this is literally what the hardware demands)
requires varying stride alignments, depending on all of format, usage, vendor,
generation, etc. Often 32px is fine if it's linear. But sometimes it's 512px,
or 512 bytes. If you want accelerated rotation on OMAP, it's a fixed 4096
bytes. But try not to be too generous with over-allocation, because everyone
has stride _limits_, which can be surprisingly low.

Obviously these requirements and restrictions change with the modifier, as you
discovered with NV12MT where you need to factor tile size into account as well
as alignment requirements.

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

I'm sorry I don't have better news for you, but hardware does not allow us to
tell you up front what stride will be, and we do not (yet) have a library with
the algorithms for every known piece of hardware which you can interrogate.

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