[PATCH 0/2] Document how userspace should use plane format list and IN_FORMATS

[Daniel Vetter]

On Thu, Apr 08, 2021 at 07:24:30PM -0300, Leandro Ribeiro wrote:
> 
> 
> On 4/8/21 8:35 AM, Daniel Vetter wrote:
> > On Tue, Apr 06, 2021 at 04:21:16PM -0300, Leandro Ribeiro wrote:
> >> This patch is to emphasize how userspace should use the plane format list and
> >> the IN_FORMATS blob. The plane format list contains the formats that do not
> >> require modifiers, and the blob property has the formats that support
> >> modifiers.
> >
> > Uh this is a very strong statement that I don't think is supported by
> > kernel driver code. Where is this from.
> >
> >> Note that these are not disjoint sets. If a format supports modifiers but the
> >> driver can also handle it without a modifier, it should be present in both the
> >> IN_FORMATS blob property and the plane format list.
> > 
> > Same here ...
> > 
> 
> Yes, sorry. The wording was not good. To clarify:

Ok I think this context helps.

> I'm trying to document a good approach that userspace *can* (not must)
> take to be able to tell if a certain format can be used in the
> pre-modifier kernel uAPI or if it only works with modifiers.

I think the short summary is "use modifiers everywhere you can".

> The background is that we are reworking the way that Weston stores the
> formats and modifiers supported by the planes, and there were some wrong
> assumptions in the code related to what we can assume that the KMS
> driver supports.
> 
> We've discussed and decided to send a patch to raise a discussion and
> check if the conclusions that we've made were reasonable. And if not,
> what would be a better approach.
> 
> This is part of a MR in which we add support for the dmabuf-hints
> protocol extension in Weston. In sort, in Weston we store the formats
> and modifiers supported by the planes. Then we send them to the client
> and it may pick one of these format/modifier pairs to allocate its
> buffers, increasing the chances of its surface ending up in a plane.
> 
> Here are two commits of the MR that are related to this discussion:
> 
> https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/544/diffs?commit_id=de6fc18bc35c2e43dff936dd85f310d1f778a7b8

  - drmModePlane's format list (the older, which does not advertise
    modifiers). Formats exposed through this support implicit modifiers.

The above isn't an accurate statement imo. Implied modifiers is a pretty
good mess:
- On most SoC platforms addfb1 actually implies linear. Except mesa got
  that wrong in a bunch of cases, and now everyone is unhappy.
- On i915/amdgpu/radeon there's implicit modifiers. Maybe also on nouveau
  I guess, not sure about any of the others. These don't generally work
  across device instances.
- On the kernel side, for drivers supporting modifiers, figuring out which
  implied modifier to pick is driver specific. There's bugs where
  essentially depending upon use case things wont work out.
- There are currently at least formats which never work with untiled
  modifier, so essentiall useless on addfb1. This applies to some afbc
  compressed formats.

In short: implied modifier is best effort trying to make stuff work,
somewhat, no guarantees.

The real recommendation is to not use implied modifiers if you can, so
also not use addfb1.

> https://gitlab.freedesktop.org/wayland/weston/-/merge_requests/544/diffs?commit_id=75363bdb121bda2f326109afca5f4c3259423b7d

Again this isn't reflecting current reality. Right now the kernel puts the
same list into both. There is no meaning attached to these two lists being
different, they are not. Userspace starting to attach meaning pretty much
means we cannot, ever, make them different, and any additional hints would
need to be conveyed through new uapi somewhere else, maybe entire new list
of formats.

Some more fun things around modifiers:
- Some formats don't work at all with untile, so useless with addfb1.
  These got mostly added for afbc support I think.
- What's even more fun and I don't think documented anywhere: The modifier
  list is treated as a bitmask for some drivers, e.g. afbc drivers
  generally don't list all combinations, but just the flags they support.
  So you might get a format+modifier combo that's not even in the list you
  have, and it will actually work (with addfb2)

I think before we add new meaning to these two lists and somehow imply
they can be different (right now they are never different, in any kernel
that shipped ever since modifier support landed) is to document the
current modifier rules.

Cheers, Daniel

> 
> Thanks!
> 
> > I thought these two lists are 100% consistent. If not sounds like driver
> > bugs that we need to maybe validate in drm_plane_init.
> > 
> >> This is important for userspace, as there are situations in which we need to
> >> find out if the KMS driver can handle a certain format without any modifiers.
> > 
> > I don't think you can rely on this. No modifiers means implicit modifier,
> > and the only thing that can give you such buffers is defacto mesa
> > userspace drivers (since that all depends upon driver private magic, with
> > maybe some kernel metadata passed around in private ioctls on the render
> > node).
> > 
> > Maybe for more context, what's the problem you've hit and trying to
> > clarify here?
> > -Daniel
> > 
> >>
> >> Leandro Ribeiro (2):
> >>   drm/doc: document drm_mode_get_plane
> >>   drm/doc: emphasize difference between plane formats and IN_FORMATS
> >>     blob
> >>
> >>  drivers/gpu/drm/drm_plane.c |  4 ++++
> >>  include/uapi/drm/drm_mode.h | 22 ++++++++++++++++++++++
> >>  2 files changed, 26 insertions(+)
> >>
> >> -- 
> >> 2.31.1
> >>
> > 

-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch