[PATCH] drm/fourcc: add LINEAR modifiers with an exact pitch alignment

[Daniel Stone]

On Thu, 19 Dec 2024 at 02:54, Marek Olšák <maraeo at gmail.com> wrote:
> On Wed, Dec 18, 2024 at 5:32 AM Brian Starkey <brian.starkey at arm.com> wrote:
>> On Wed, Dec 18, 2024 at 11:24:58AM +0000, Simona Vetter wrote:
>> > For that reason I think linear modifiers with explicit pitch/size
>> > alignment constraints is a sound concept and fits into how modifiers work
>> > overall.
>>
>> Could we make it (more) clear that pitch alignment is a "special"
>> constraint (in that it's really a description of the buffer layout),
>> and that constraints in-general shouldn't be exposed via modifiers?
>
>
> Modifiers uniquely identify image layouts. That's why they exist and it's their only purpose.
>
> It doesn't matter how many modifiers we have. No app should ever parse the modifier bits. All apps must treat modifiers as opaque numbers. Likewise, documentation of all modifiers in drm_fourcc.h is only meant for driver developers. No developers of apps should ever use the documentation. There can be a million modifiers and a million different devices, and the whole system of modifiers would fall apart if every app developer had to learn all of them.

I'm afraid linear _is_ special. And we've never had a delineation
between 'applications' and 'clients' for uAPI purposes; I mean, if
it's OK for Mesa and AMDVLK and ROCm to know exactly how to deal with
AMD tiling modes for HIC, why is it not OK for apps to know that
themselves too? Mostly because it's immaterial to the kernel: if it
breaks one, it's going to break the other too.

> The only thing applications are allowed to do is query modifier lists from all clients, compute their intersection, and pass it to one of the clients for allocation. All clients must allocate the exact same layout, otherwise the whole system of modifiers would fall apart. If the modifier dictates that the pitch and alignment are not variables, but fixed values derived from width/height/bpp, then that's what all clients must allocate.
>
> If any app uses DRM_FORMAT_MOD_LINEAR directly instead of querying supported modifiers from clients, it's a misuse of the API.

Yes, but it's _not_ a misuse of the API for the app to query supported
modifiers, see that LINEAR is supported, know that its input is linear
(because it created it, or because the subsystem it gets it from only
supports linear layouts, or because they have another flag for linear
with a non-modifier API, or), and use LINEAR with that. That's exactly
what happens for anyone who wants to do interop with e.g. V4L2.

> DRM_FORMAT_MOD_LINEAR will be deprecated because it's the only modifier that is generally non-functional (it's only functional in special cases). After new linear modifiers land, drivers will stop supporting DRM_FORMAT_MOD_LINEAR if they can't support all pitches and alignments because we only want to have functional software.

You're extrapolating way too far. Linear works totally fine for
everyone except AMD. The special case is that it doesn't work on AMD
because AMD imposes really weird constraints.

LINEAR cannot be removed any time soon/ever. You'd have to change all
the clients who clearly and correctly use it without breaking the
rules today, wait for them to phase out, wait to make sure that no-one
would have them in an old container image or want to bisect into them,
and only then kill it.

Cheers,
Daniel