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
