[PATCH v3] drm/fourcc: document modifier uniqueness requirements

[Alex Deucher]

On Fri, May 29, 2020 at 9:58 AM Daniel Stone <daniel at fooishbar.org> wrote:
>
> Hi Alex,
>
> On Fri, 29 May 2020 at 14:29, Alex Deucher <alexdeucher at gmail.com> wrote:
> > On Fri, May 29, 2020 at 4:59 AM Simon Ser <contact at emersion.fr> wrote:
> > > OK. In this case I think it's fine to make the DMA-BUF import fail, as
> > > we've suggested on IRC. The more-or-less planned fix for these buffer
> > > sharing issues is to revive the buffer constraints proposal from the
> > > allocator project. It's a lot of work though.
> >
> > I get that, but why explicitly limit modifiers then?  Shouldn't we try
> > and do the best we can with what we have now?  If not the situation is
> > not much better than what we have now.  Why go through the effort or
> > adding modifer support in the first place if they are mostly useless?
>
> Well sure, we could add pitch alignment in there. And height
> alignment. And starting byte offset. And acceptable byte distance
> between planes. And physical contiguity / number of backing pages. And
> placement (system vs. GTT vs. local), which also implies adding a
> device-unique identifier whilst we're at it. And acceptable
> width/height bounds. All of those are perfectly valid constraints
> which could cause imports to fail, and not even an exhaustive list.
>
> How does Navi ensure that every single linear dmabuf source it can
> ever receive is aligned to 256 bytes today? How does adding support
> for modifiers - something which does solve other problems, like 'every
> three months I wearily review a patch forcing all winsys buffers to be
> allocated for scanout usage for a new random reason, regressing
> performance for a lot of other vendors' - make Navi's situation worse?
>
> > I don't quite get what we are trying to do with them.  What does this
> > mean "Modifiers must uniquely encode buffer layout"?  We have a number
> > of buffer layouts that are the same from a functional standpoint, but
> > they have different alignment requirements depending on the chip and
> > the number of memory channels, etc.  Would those be considered the
> > same modifer?  If not, then we are sort of implicitly encoding
> > alignment requirements into the modifier.
>
> Yes, of course some requirements are implicit. Given that tiles are
> indivisible, it makes no sense to have a 64x64 tiled buffer with a
> 32-pixel stride. But that isn't the same thing as encoding an
> arbitrary constraint, it's just a requirement of the encoding.
>
> The reason why modifiers have been successful and adopted by every
> other vendor apart from IMG, is exactly because they _don't_ attempt
> to boil the ocean, but are the most practical realisation of improving
> performance within a complex ecosystem. The allocator is the complete
> and exhaustive solution to all our problems, but it's not exactly
> going to be done tomorrow.

Maybe I'm over thinking this.  I just don't want to get into a
situation where we go through a lot of effort to add modifier support
and then performance ends up being worse than it is today in a lot of
cases.

Alex

>
> Playing a single video today could easily involve a V4L2 codec source
> into a V4L2 postprocessor into Chromium's Wayland host compositor
> through Chromium itself into the host Wayland compositor and finally
> into EGL and/or Vulkan and/or KMS. If you want to figure out what the
> V4L2/DRM/KMS, GStreamer/VA-API/Kodi, EGL/Vulkan, and Wayland/X11 APIs
> look for negotiating a totally optimal layout across at least three
> different hardware classes from at least three different vendors, then
> I'm all for it. I'll be cheering you on from the sidelines and doing
> what I can to help. But the only reason we've got to this point today
> is because Allwinner, AmLogic, Arm, Broadcom, Intel, NVIDIA, NXP,
> Qualcomm, Rockchip, Samsung, and VeriSilicon, have all spent the last
> few years trying to avoid perfection being the enemy of good. (And
> those are just the hardware vendors - obviously Collabora and others
> like us have also put not-inconsiderable effort into getting at least
> this far.)
>
> Cheers,
> Daniel