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@arm.com 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-E1...
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