[Lima] [PATCH v2] drm/fourcc: add ARM GPU tile format

[Qiang Yu]

On Tue, Mar 12, 2019 at 11:41 PM Ayan Halder <Ayan.Halder at arm.com> wrote:
>
> On Mon, Mar 11, 2019 at 09:39:28AM -0700, Alyssa Rosenzweig wrote:
> > > You might want to re-use the exisiting modifier
> > > AFBC_FORMAT_MOD_BLOCK_SIZE_16x16.
> > >
> > > I would suggest you to have a look at the exisiting AFBC modifiers
> > > (denoted by AFBC_FORMAT_MOD_XXX ) and let us know if there is
> > > something you cannot reuse.
> >
> > So, the "tiled" format in question (that Qiang needs to import/export
> > BOs in) is *uncompressed* but tiled with an Arm-internal format (for the
> > GPUs).  Here's a software implementation for encoding this format:
> > https://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/drivers/panfrost/pan_swizzle.c
> >
> ok I understood now. In this case, please ignore my suggestion.
>
> > For Midgard/Bifrost, we use this tiling internally for uploading bitmap
> > textures, but we only render to AFBC (or linear). So for Panfrost, we'll
> > always be importing/exporting AFBC buffers, never uncompressed tiled.
>
> I am not a gpu guy so can't comment at the moment.
>
> > But Utgard does not seem to support AFBC (?), so Qiang needs the
> > uncompressed tiled for the same purpose Panfrost uses AFBC.
> >
> > Is it possible that this is the same tiling used internally by
> > AFBC_FORMAT_MOD_BLOCK_SIZE_16x16, only without any compression? AFBC is
> > blackbox for us, so this isn't something we can figure out ourselves,
> > but that influences whether it's appropriate to reuse the modifier. If
> > this is the same tiling scheme, perhaps that's the answer. If it's not
> > (I don't know how AFBC tiling works), we probably do need a separate
> > modifier to avoid confusion.
> >
> AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 denotes the superblock size to be
> used only in case of AFBC buffers.
> For non compressed tiled format, none of the AFBC_FORMAT_MOD_XXX
> should be used.

I still haven't get a clear answer. The question is:

1. Does AFBC_FORMAT_MOD_BLOCK_SIZE_16x16 without any
AFBC_FORMAT_MOD_XXX uncompressed format just reorder the pixels
in one 16x16 block same way as GPU "tiled" format? Or just no reorder (linear)?

2. Is there any unreleased AFBC_FORMAT_MOD_XXX bit for this GPU
"tiled" format?

3. If the answer to 1&2 is no, seems Mali GPU formats and Mali Display
formats are in different systems, do Mali Display guys agree to divide
these two different format systems by the MSB bits of format field in this
patch?

>
> However, I would like you to review my patch series
> (https://patchwork.freedesktop.org/series/53395/) to
> see if we have the same understanding.
>
To be honest, I find no answer in this patch series for the above questions.

Thanks,
Qiang

>
>
>
> > _______________________________________________
> > dri-devel mailing list
> > dri-devel at lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel
>