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

[Daniel Stone]

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.

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