[Bug 779146] dmabuf: be able to negotiate tiled surfaces
GStreamer (GNOME Bugzilla)
bugzilla at gnome.org
Fri Jan 19 08:19:22 UTC 2018
https://bugzilla.gnome.org/show_bug.cgi?id=779146
--- Comment #45 from Daniel Stone <daniel at fooishbar.org> ---
What about 'the state of stride' is terrible? For linear buffers, stride is the
number of bytes between (x,y) and (x,y+1).
As devices often have hard requirements on stride alignment, when you use an
allocator you often do not get to specify stride yourself. For dumb buffers,
there is a field in the ioctl which is filled out (along with the buffer
handle) with the stride value you must use for a given width.
As you've noted, this applies separately to each plane of a multi-plane image.
Stride being a buffer-storage property, this makes sense. Consider the
definition of the I915_FORMAT_MOD_Y_CCS modifier, where one plane is 32bpp with
supertiling, meaning you need quite a bit of padding. The other plane
represents 128 pixels horizontally in a _single byte_. You could in theory
probably have a single stride value for the overall combined image, but this
would require overallocation of the auxiliary plane by a factor of 512.
Random drivers don't create random rules, they don't disagree on what stride
means, and they're not desperate to create some random avant-garde
interpretation of it. They _do_ have their own hard requirements on how stride
must be aligned, which comes very directly from their hardware. If you ever do
find inconsistencies between drivers or random values, or anything else which
makes you think GPU drivers treat stride as a PRNG, then please let me know.
Tiling _is_ more difficult to think about, especially supertiling. But the
definition above holds; it might be easier to invert what you said about
converting to linear, and instead just imagine linear as a 1x1 tiling format.
In that case, the rule becomes 'from (x,y) to (x,y+TH), where TH is the
greatest/outer tile height in the format'.
This isn't inconsistent or even an issue that should bother GSt. If you know
the tiling format, then you know how to lay the data out including stride (as
with NV12MT). If you don't, then you don't ever see the data, and stride is
another piece of data to transfer without needing to inspect. If you have a
pipeline involving conversions from one layout to another (e.g. linear for
software processing, converted to tiled on GPU upload), then you will have
differing strides at different points in your pipeline, which is fine: the
buffers you're addressing have fundamentally different properties, and the two
strides are no more comparable than the buffers themselves.
--
You are receiving this mail because:
You are the QA Contact for the bug.
You are the assignee for the bug.
More information about the gstreamer-bugs
mailing list