Re: [PATCH] doc: gpu: Add document describing buffer exchange

[Daniel Vetter <daniel@ffwll.ch>]

On Mon, Nov 08, 2021 at 04:21:04PM -0800, James Jones wrote:
> On 9/8/21 2:44 AM, Simon Ser wrote:
> > > stride
> > > 	????
> > 
> > I think what's clear is:
> > 
> > - Per-plane property
> > - In bytes
> > - Offset between two consecutive rows
> > 
> > How that applies to weird YUV formats is the tricky question…
> > 
> > > Btw. there was a fun argument whether the same modifier value could
> > > mean different things on different devices. There were also arguments
> > > that a certain modifier could reference additional implicit memory on
> > > the device - memory that can only be accessed by very specific devices.
> > > 
> > > I think AMLOGIC_FBC_LAYOUT_SCATTER was one of those.
> > 
> > A recent exmaple of this is [1].
> > 
> > [1]: https://patchwork.freedesktop.org/patch/452461/
> 
> What was the resolution to that argument?  It took some fiddling to get the
> NV format modifiers to be robust enough that they actually do differentiate
> "identical" layouts that actually mismatch between devices (E.g., some of
> our SoC GPUs interpret layouts differently than our discrete GPUs, so that's
> reflected in the format modifier-building macro and hence applications can
> properly deduce that they can *not* share images directly between these
> devices, but can share between two similar discrete GPUs), so I hope the
> modifier definition allows that. Cross-device sharing using tiled formats in
> machines with multiple similar NV GPUs was an important use case for
> modifiers on our side.

Imo it boils down to "past mistakes don't justify continued screw-ups" or
so :-) As in, we really should make sure we make them unique if they
differ between platforms.

I think the only ok exception is if the compression uses some special
memory/buffer and hence the buffer simply cannot be exported to another
device. Or at least not any device which doesn't have access to that
special memory (and hence by necessity of being part of the same SoC or
interconnect probably knows what's going on anyway).

Another one is r/ed drivers, especially when baked into a given soc, were
it's just a bit too hard to fully figure out the layout everywhere (and
also kinda a waste of time).

But yeah it would be good to document in drm_fourcc.h that a) we screwed
up in the past and b) we shouldn't, at least not for anything that can be
used in discrete gpus.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch