[RFC] drm/amdgpu: Add macros and documentation for format modifiers.

[Daniel Vetter]

On Tue, Sep 04, 2018 at 12:44:19PM +0200, Christian König wrote:
> Am 04.09.2018 um 12:15 schrieb Daniel Stone:
> > Hi,
> > 
> > On Tue, 4 Sep 2018 at 11:05, Daniel Vetter <daniel.vetter at ffwll.ch> wrote:
> > > On Tue, Sep 4, 2018 at 3:00 AM, Bas Nieuwenhuizen <bas at basnieuwenhuizen.nl> wrote:
> > > > +/* The chip this is compatible with.
> > > > + *
> > > > + * If compression is disabled, use
> > > > + *   - AMDGPU_CHIP_TAHITI for GFX6-GFX8
> > > > + *   - AMDGPU_CHIP_VEGA10 for GFX9+
> > > > + *
> > > > + * With compression enabled please use the exact chip.
> > > > + *
> > > > + * TODO: Do some generations share DCC format?
> > > > + */
> > > > +#define AMDGPU_MODIFIER_CHIP_GEN_SHIFT                 40
> > > > +#define AMDGPU_MODIFIER_CHIP_GEN_MASK                  0xff
> > > Do you really need all the combinations here of DCC + gpu gen + tiling
> > > details? When we had the entire discussion with nvidia folks they
> > > eventually agreed that they don't need the massive pile with every
> > > possible combination. Do you really plan to share all these different
> > > things?
> > > 
> > > Note that e.g. on i915 we spec some of the tiling depending upon
> > > buffer size and buffer format (because that's how the hw works), not
> > > using explicit modifier flags for everything.
> > Right. The conclusion, after people went through and started sorting
> > out the kinds of formats for which they would _actually_ export real
> > colour buffers for, that most vendors definitely have fewer than
> > 115,792,089,237,316,195,423,570,985,008,687,907,853,269,984,665,640,564,039,457,584,007,913,129,639,936
> > possible formats to represent, very likely fewer than
> > 340,282,366,920,938,463,463,374,607,431,768,211,456 formats, probably
> > fewer than 72,057,594,037,927,936 formats, and even still generally
> > fewer than 281,474,976,710,656 if you want to be generous and leave 8
> > bits of the 56 available.
> 
> The problem here is that at least for some parameters we actually don't know
> which formats are actually used.
> 
> The following are not real world examples, but just to explain the general
> problem.
> 
> The memory configuration for example can be not ASIC specific, but rather
> determined by whoever took the ASIC and glued it together with VRAM on a
> board. It is not likely that somebody puts all the VRAM chips on one
> channel, but it is still perfectly possible.
> 
> Same is true for things like harvesting, e.g. of 16 channels halve of them
> could be bad and we need to know which to actually use.

For my understanding: This leaks outside the chip when sharing buffers?
All the information you only need locally to a given amdgpu instance
don't really need to be encoded in modifiers.

Pointers to code where this is all decided (kernel and radeonsi would be
good starters I guess) would be really good here.
-Daniel

> 
> Regards,
> Christian.
> 
> > 
> > If you do use 256 bits in order to represent
> > 115,792,089,237,316,195,423,570,985,008,687,907,853,269,984,665,640,564,039,457,584,007,913,129,639,936
> > modifiers per format, userspace would start hitting OOM pretty quickly
> > as it attempted to enumerate and negotiate acceptable modifiers.
> > Either that or we need to replace the fixed 64-bit modifier tokens
> > with some kind of eBPF script.
> > 
> > Cheers,
> > Daniel
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
> 

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