On Tue, Feb 23, 2021 at 03:29:13PM +0000, Daniel Stone wrote: > On Tue, 23 Feb 2021 at 14:58, Brian Starkey <brian.starkey@xxxxxxx> wrote: > > On Tue, Feb 23, 2021 at 02:27:11PM +0000, Daniel Stone wrote: > > > Mark, or others from Rockchip, can you please: > > > - explain if there is a way to enable/disable the YTR transform in the > > > VOP's AFBC decoder, similar to the split-block control bit? > > > - ack this patch which correctly declares that the YTR transform is in > > > use in order to make Panfrost work, so it can be merged through > > > drm-misc, or provide another solution which fixes this API mistake? > > > - if VOP does have a hidden YTR-disable bit, add support to disable > > > YTR so rockchip-drm can continue advertising the non-YTR modifier, and > > > Cc this patch for backporting to every kernel tree which declares AFBC > > > modifier support? > > > > Drive-by $0.02: > > > > As described in https://www.kernel.org/doc/Documentation/gpu/afbc.rst, > > YTR is only valid for "BGR" component order, so this shouldn't be set > > or used for "RGB" order (or YUV) formats. For BGR-order formats, it's > > best to always enable YTR to get the best compression ratio. > > > > In an ideal world, there wouldn't be hardware/drivers which > > support/allow non-standard encodings, but we don't live in that world > > :-( > > This implies that RGB component ordering cannot be used together with > AFBC on RK3399, no? If YTR can't be turned off, then according to the AFBC spec - correct. If the hardware allows it to be configured to use YTR with other component orders, I don't know exactly what the impact would be - maybe nothing. I raised some of these concerns when the patches were first sent: https://lore.kernel.org/dri-devel/20190925093913.z4vduybwcokn3awi@DESKTOP-E1NTVVP.localdomain/ We wrote the .rst doc to try and avoid incompatibilities between different drivers and parts of the stack. BGR is Arm's preferred order for AFBC. Unfortunately amongst shifting organisations and priorities, AFBC in upstream hasn't got much attention. Cheers, -Brian > > Cheers, > Daniel _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
