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

[Marek Olšák]

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

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.

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.

Marek
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20241218/ce8c2e18/attachment.htm>