[RFC] drm/amdgpu: Add macros and documentation for format modifiers.
Bas Nieuwenhuizen
bas at basnieuwenhuizen.nl
Tue Sep 4 12:21:34 UTC 2018
On Tue, Sep 4, 2018 at 12:04 PM Daniel Vetter <daniel.vetter at ffwll.ch> wrote:
>
> On Tue, Sep 4, 2018 at 3:00 AM, Bas Nieuwenhuizen
> <bas at basnieuwenhuizen.nl> wrote:
> > This is an initial proposal for format modifiers for AMD hardware.
> >
> > It uses 48 bits including a chip generation, leaving 8 bits for
> > a format version number.
> >
> > On gfx6-gfx8 we have all the fields influencing sample locations
> > in memory.
> >
> > Tile split bytes are optional for single sample buffers as no
> > hardware reaches the split size with 1 sample and hence the actual
> > size does not matter.
> >
> > The macrotile fields are duplicated for images with multiple planes.
> > If the planes have different bitdepth they need different macro
> > tile fields and different tile split bytes if multisample.
> >
> > I could not fit multiple copies in for tile split bytes, but
> > multisample & multiplane images are very rare. Overall, I think
> > we should punt on multisample for a later format version since
> > they are generally not shared on any modifier aware windowing
> > system, and we have more issues like fmask & cmask.
> >
> > We need these copies because the drm modifier of all planes in an
> > image needs to be equal, so we need to fit these together.
> >
> > This adds fields for compression support, using metadata that is
> > compatible with AMDVLK and for which radv and radeonsi can
> > reasonably be extended.
> >
> > The big open question for compression is between which generations
> > the format changed to see if we can share more.
> >
> > This explicitly does not try to solve the linear stride alignment
> > issue, thoguh we could internally just use the tiling modes for
> > the linear modes to indicate linear images with the stride for the
> > given chip.
> >
> > Signed-off-by: Bas Nieuwenhuizen <bas at basnieuwenhuizen.nl>
> > CC: Chad Versace <chadversary at chromium.org>
> > CC: Dave Airlie <airlied at redhat.com>
> > CC: Marek Olšák <marek.olsak at amd.com>
> > CC: Nicolai Hähnle <nicolai.haehnle at amd.com>
> > CC: Alex Deucher <alexander.deucher at amd.com>
> > CC: Daniel Vetter <daniel.vetter at ffwll.ch>
> > ---
> > include/uapi/drm/amdgpu_drm.h | 130 ++++++++++++++++++++++++++++++++++
> > 1 file changed, 130 insertions(+)
> >
> > diff --git a/include/uapi/drm/amdgpu_drm.h b/include/uapi/drm/amdgpu_drm.h
> > index 94444eeba55b..4e1452161dbf 100644
> > --- a/include/uapi/drm/amdgpu_drm.h
> > +++ b/include/uapi/drm/amdgpu_drm.h
> > @@ -990,6 +990,136 @@ struct drm_amdgpu_info_vce_clock_table {
> > #define AMDGPU_FAMILY_AI 141 /* Vega10 */
> > #define AMDGPU_FAMILY_RV 142 /* Raven */
> >
> > +#define AMDGPU_CHIP_TAHITI 0
> > +#define AMDGPU_CHIP_PITCAIRN 1
> > +#define AMDGPU_CHIP_VERDE 2
> > +#define AMDGPU_CHIP_OLAND 3
> > +#define AMDGPU_CHIP_HAINAN 4
> > +#define AMDGPU_CHIP_BONAIRE 5
> > +#define AMDGPU_CHIP_KAVERI 6
> > +#define AMDGPU_CHIP_KABINI 7
> > +#define AMDGPU_CHIP_HAWAII 8
> > +#define AMDGPU_CHIP_MULLINS 9
> > +#define AMDGPU_CHIP_TOPAZ 10
> > +#define AMDGPU_CHIP_TONGA 11
> > +#define AMDGPU_CHIP_FIJI 12
> > +#define AMDGPU_CHIP_CARRIZO 13
> > +#define AMDGPU_CHIP_STONEY 14
> > +#define AMDGPU_CHIP_POLARIS10 15
> > +#define AMDGPU_CHIP_POLARIS11 16
> > +#define AMDGPU_CHIP_POLARIS12 17
> > +#define AMDGPU_CHIP_VEGAM 18
> > +#define AMDGPU_CHIP_VEGA10 19
> > +#define AMDGPU_CHIP_VEGA12 20
> > +#define AMDGPU_CHIP_VEGA20 21
> > +#define AMDGPU_CHIP_RAVEN 22
> > +
> > +/* Format for GFX6-GFX8 DRM format modifiers. These are intentionally the same
> > + * as AMDGPU_TILING_*. However, the the rules as to when to set them are
> > + * different.
> > + *
> > + * Do not use linear ARRAY_MODEs or SWIZZLE_MODEs. Use DRM_FORMAT_MOD_LINEAR
> > + * instead.
> > + *
> > + * If ARRAY_MODE is 1D, only the micro tile mode and the pipe config should be
> > + * set.
> > + *
> > + * For other ARRAY_MODEs:
> > + * - Only set TILE_SPLIT if the image is multisample.
> > + *
> > + * We have 1 extra bit for the micro tile mode, as GFX6 and GFX7+ have 1
> > + * different value there. The values are
> > + * - depth : 0
> > + * - displayable : 1
> > + * - thin : 2
> > + * - thick (GFX6) : 3
> > + * - rotated (GFX7+) : 4
> > + *
> > + * TODO: What to do with multisample multi plane images? More tile split
> > + * fields don't fit if we want to keep a few bits for a format version.
> > + */
> > +#define AMDGPU_MODIFIER_GFX8_ARRAY_MODE_SHIFT 0
> > +#define AMDGPU_MODIFIER_GFX8_ARRAY_MODE_MASK 0xf
> > +#define AMDGPU_MODIFIER_GFX8_PIPE_CONFIG_SHIFT 4
> > +#define AMDGPU_MODIFIER_GFX8_PIPE_CONFIG_MASK 0x1f
> > +#define AMDGPU_MODIFIER_GFX8_TILE_SPLIT_SHIFT 9
> > +#define AMDGPU_MODIFIER_GFX8_TILE_SPLIT_MASK 0x7
> > +#define AMDGPU_MODIFIER_GFX8_MICRO_TILE_MODE_SHIFT 12
> > +#define AMDGPU_MODIFIER_GFX8_MICRO_TILE_MODE_MASK 0x7
> > +#define AMDGPU_MODIFIER_GFX8_BANK_WIDTH_SHIFT 15
> > +#define AMDGPU_MODIFIER_GFX8_BANK_WIDTH_MASK 0x3
> > +#define AMDGPU_MODIFIER_GFX8_BANK_HEIGHT_SHIFT 17
> > +#define AMDGPU_MODIFIER_GFX8_BANK_HEIGHT_MASK 0x3
> > +#define AMDGPU_MODIFIER_GFX8_MACRO_TILE_ASPECT_SHIFT 19
> > +#define AMDGPU_MODIFIER_GFX8_MACRO_TILE_ASPECT_MASK 0x3
> > +#define AMDGPU_MODIFIER_GFX8_NUM_BANKS_SHIFT 21
> > +#define AMDGPU_MODIFIER_GFX8_NUM_BANKS_MASK 0x3
> > +
> > +/* Macrotile parameters for a second plane if existing */
> > +#define AMDGPU_MODIFIER_GFX8_BANK_WIDTH_1_SHIFT 23
> > +#define AMDGPU_MODIFIER_GFX8_BANK_WIDTH_1_MASK 0x3
> > +#define AMDGPU_MODIFIER_GFX8_BANK_HEIGHT_1_SHIFT 25
> > +#define AMDGPU_MODIFIER_GFX8_BANK_HEIGHT_1_MASK 0x3
> > +#define AMDGPU_MODIFIER_GFX8_MACRO_TILE_ASPECT_1_SHIFT 27
> > +#define AMDGPU_MODIFIER_GFX8_MACRO_TILE_ASPECT_1_MASK 0x3
> > +#define AMDGPU_MODIFIER_GFX8_NUM_BANKS_1_SHIFT 29
> > +#define AMDGPU_MODIFIER_GFX8_NUM_BANKS_1_MASK 0x3
> > +
> > +/* Macrotile parameters for a third plane if existing */
> > +#define AMDGPU_MODIFIER_GFX8_BANK_WIDTH_2_SHIFT 31
> > +#define AMDGPU_MODIFIER_GFX8_BANK_WIDTH_2_MASK 0x3
> > +#define AMDGPU_MODIFIER_GFX8_BANK_HEIGHT_2_SHIFT 33
> > +#define AMDGPU_MODIFIER_GFX8_BANK_HEIGHT_2_MASK 0x3
> > +#define AMDGPU_MODIFIER_GFX8_MACRO_TILE_ASPECT_2_SHIFT 35
> > +#define AMDGPU_MODIFIER_GFX8_MACRO_TILE_ASPECT_2_MASK 0x3
> > +#define AMDGPU_MODIFIER_GFX8_NUM_BANKS_2_SHIFT 37
> > +#define AMDGPU_MODIFIER_GFX8_NUM_BANKS_2_MASK 0x3
> > +
> > +#define AMDGPU_MODIFIER_GFX9_SWIZZLE_MODE_SHIFT 0
> > +#define AMDGPU_MODIFIER_GFX9_SWIZZLE_MODE_MASK 0x1f
> > +
> > +/* Whether to enable DCC compression.
> > + *
> > + * If enabled, exporting the surface results in three
> > + * planes:
> > + * - color data
> > + * - DCC data
> > + * - a 64-byte block with
> > + * - a 16 byte 0/1 bool as to whether the surface is currently DCC compressed.
> > + * - a 16-byte 0/1 bool as to whether the surface has fastclear data
> > + * - a 8-byte chunk with the current fastclear colors
> > + *
> > + * To ensure we do not keep compressing and decompressing the surface, once it
> > + * has been decompressed no party may recompress again.
> > + *
> > + * Applications should not hand over images with fastclear data as not
> > + * all users can support it, however, to help both Vulkan implementations
> > + * with the allocation we keep it in the 64-byte block.
> > + *
> > + * TODO: Can scanout really not support fastclear data?
> > + * TODO: What to do with multiplane images?
> > + */
> > +#define AMDGPU_MODIFIER_COMPRESSION_SHIFT 39
> > +#define AMDGPU_MODIFIER_COMPRESSION_MASK 0x1
>
> Summary of the irc discussion with my 2 recommendations:
>
> - Make it clear in the spec here that all consumers must follow the 16
> byte boolean to control actual DCC usage (using a conditional register
> write in the command buffer). On intel we've put that into the
> modifier itself, along the lines of "I don't like compressed anymore,
> pls give me something else". Not that runtime renogiation works well
> (or well, at all).
>
> - If you have consumers which can't handle fastclear, make it a
> separate modifier.
>
> > +
> > +/* 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?
So GPU gen is based on the fact that GFX6-GFX8 and GFX9 had a
significant change in tiling modes that are not compatible.
Furthermore, DCC formats have seen changes between chips in the same
generation and without more documentation on when those are compatible
I'd like to be conservative and for DCC put every chip in its own
class.
For whether to enable DCC: there are basically a bunch of conditions
in image creation parameters on when we can use it, so I'd like to
keep non-DCC versions available even for HW that supports DCC.
Tling on GFX9+ is only 5 bits so that is easy. For GFX6-GFX8 it is complicated.
Each chip has a configurable system-wide 32-entry table of tiling
modes (GFX7-GFX8 have the components split in two tables, but in
practice given a format there is only one choice for the second
table). The kernel has different settings for each chip to put in
there.
So if we do not want to enable sharing between GPUs we can just do a
precise chip + tiling mode index and be done with it. However, since
the entries are different between chips we have to either:
1) make some kind of mapping from (chip, tiling index) to a canonical
value based on compatiblity. Which means for backwards compatibility
reasons we're never going to be able to change the table config in the
kernel again.
2) include the value of the table entry in the modifier.
I chose solution 2 here. This means that while there is a lot of data
in here in practice the tiling mode only has ~32 options per chip per
format/bitdepth.
There are some blocks not bound by this table (mostly scanout), but in
practice the GL/vulkan driver just allocates from the tiling table
anyway so kernel driver is just going to have to expose the modifiers
corresponding to the tiling table to keep the amount limited.
So as far as fields go, we have
ARRAY_MODE = is this linear, micro-tiling, macro-tiling or thick-macro
tiling (for 3d textures, various thicknesses), sparse texture.
linear is not relevant here. micro-tiling is relevant for cross-GPU
sharing if macro-tiling is not compatible. macro-tiling is optimal for
2d, sparse-texture could probably be aliased/out of scope.
MICRO_TILE = normal, display, depth, rotated display
I think these are obviously worth keeping
PIPE_CONFIG = pretty much something constant over a chip but important
for everything that is not linear
TILE_SPLIT = relevant for multisample images. I think in practice
constant for pretty much everything except GFX6, where it is format
specific
BANK_WIDTH,BANK_HEIGHT,MACRO_TILE_ASPEC,NUM_BANKS = for macro tiles,
pretty much specific to chip + format, mostly independent of
everything else.
because of the bitdepth dependence we have to have multiple for
multiplane images as some are e.g. one R plane + one GB plane.
>
> 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.
> -Daniel
>
> > +
> > +#define AMDGPU_MODIFIER_SET(field, value) \
> > + (((__u64)(value) & AMDGPU_MODIFIER_##field##_MASK) << AMDGPU_MODIFIER_##field##_SHIFT)
> > +#define AMDGPU_MODIFIER_GET(value, field) \
> > + (((__u64)(value) >> AMDGPU_MODIFIER_##field##_SHIFT) & AMDGPU_MODIFIER_##field##_MASK)
> > +
> > /*
> > * Definition of free sync enter and exit signals
> > * We may have more options in the future
> > --
> > 2.18.0
> >
>
>
>
> --
> Daniel Vetter
> Software Engineer, Intel Corporation
> +41 (0) 79 365 57 48 - http://blog.ffwll.ch
More information about the dri-devel
mailing list