> 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.
Alright, understood. Thank you for the clarification :)
___
> 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?
I
On Tue, Mar 12, 2019 at 11:41 PM Ayan Halder 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
>
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
> 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
Alyssa did a very good description of our needs. Since I can't open the
cgit mesa link and give you a clear view of this format:
https://gitlab.freedesktop.org/mesa/mesa/blob/master/src/gallium/drivers/panfrost/pan_swizzle.c
On Sat, Mar 09, 2019 at 10:09:02PM +0800, Qiang Yu wrote:
Hi Qiang,
Apologies for jumping to the very initial patch. I wanted to have some
understanding of the newly proposed modifiers since they seem to me a
duplicate of the existing AFBC modifiers.
> v2: seperate AFBC and GPU encoding
>
>
> +/*
> + * Arm Device code
> + *
> + * Arm has multiple devices which do not share buffer format,
> + * so add a device field at the MSB of the format field to seperate
> + * each device's encoding.
> + */
> +#define DRM_FORMAT_MOD_ARM_DEVICE_AFBC 0x00
> +#define DRM_FORMAT_MOD_ARM_DEVICE_GPU
> If you think Midgard/Bifrost is compatible with AFBC and don't have it's
> own format, and name "device" is improper, I can rename
> DRM_FORMAT_MOD_ARM_DEVICE_AFBC to DRM_FORMAT_MOD_ARM_TYPE_AFBC
> DRM_FORMAT_MOD_ARM_DEVICE_GPU to DRM_FORMAT_MOD_ARM_TYPE_UTGARD
That name is misleading, too.
> Then DRM_FORMAT_MOD_ARM_TYPE_GPU? I really don't know what's the
> official name for this kind of format, so have to name it with the
> device. Any better
> suggestion?
Maybe DRM_FORMAT_MOD_ARM_TYPE_TILED? I wonder if the Mali-DP folks have
a suggestion.
> Is tiled buffer rendering not reverse
On Sun, Mar 10, 2019 at 10:53 AM Alyssa Rosenzweig wrote:
>
> > If you think Midgard/Bifrost is compatible with AFBC and don't have it's
> > own format, and name "device" is improper, I can rename
> > DRM_FORMAT_MOD_ARM_DEVICE_AFBC to DRM_FORMAT_MOD_ARM_TYPE_AFBC
> >
On Sun, Mar 10, 2019 at 10:08 AM Alyssa Rosenzweig wrote:
>
> > +/*
> > + * Arm Device code
> > + *
> > + * Arm has multiple devices which do not share buffer format,
> > + * so add a device field at the MSB of the format field to seperate
> > + * each device's encoding.
> > + */
> > +#define
12 matches
Mail list logo
