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

[Bas Nieuwenhuizen]

+everyone again
On Tue, Sep 4, 2018 at 2:39 PM Bas Nieuwenhuizen
<bas at basnieuwenhuizen.nl> wrote:
>
> On Tue, Sep 4, 2018 at 2:22 PM Daniel Stone <daniel at fooishbar.org> wrote:
> >
> > Hi,
> >
> > On Tue, 4 Sep 2018 at 11:44, Christian König
> > <ckoenig.leichtzumerken at gmail.com> wrote:
> > > Am 04.09.2018 um 12:15 schrieb Daniel Stone:
> > > > 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.
> >
> > Sure, that's fine, but I'm not sure why, for instance, 'half of the
> > memory channels are bad and must be avoided' would be attached to a
> > format in the same way that macrotile size/depth would be? Similarly,
> > what happens if you encode a channel or lane blacklist mask into a
> > modifier, and then you import a buffer with that modifier into a
> > client API on another device. Does that also apply to the other device
> > or only the source device?
> >
> > How then do you handle the capability query between them: is it
> > relevant to device B attempting to import and sample from an image
> > that device A only has a 128-bit memory bus because of SKU
> > configuration? How does generic userspace look at a token which
> > encodes all of this information and know that the buffer is
> > interchangeable between devices?
>
> So my idea here is to encode all the bits that determine format in a
> way that as much as possible if it
> results in the same layout it should get the same modifier(i.e. remove
> useless info):
>
> https://lists.freedesktop.org/archives/dri-devel/2018-September/188418.html
>
> An example of the per-chip things is the PIPE_CONFIG, which is used
> for address calculation in the macro-tiled mode:
>
> https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/amd/addrlib/r800/siaddrlib.cpp#L666
>
> two chips with different PIPE_CONFIG will have different texture
> layouts, as the address swizzles are different.
>
> So it gets included in the modifier (the PIPE_CONFIG is pretty much
> constant per chip but multiple chips might have the same PIPE_CONFIG).
>
> >
> > Cheers,
> > Daniel
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel