[PATCH v3] drm/plane: Add documentation about software color conversion.
Pekka Paalanen
ppaalanen at gmail.com
Mon Aug 28 07:35:46 UTC 2023
On Fri, 25 Aug 2023 16:04:18 +0200
Jocelyn Falempe <jfalempe at redhat.com> wrote:
> After discussions on IRC, the consensus is that the DRM drivers should
> avoid software color conversion, and only advertise the formats supported
> by hardware.
> Update the doc accordingly so that the rule and exceptions are clear for
> everyone.
>
> Acked-by: Simon Ser <contact at emersion.fr>
> Signed-off-by: Jocelyn Falempe <jfalempe at redhat.com>
> ---
> drivers/gpu/drm/drm_plane.c | 24 ++++++++++++++++++++++++
> 1 file changed, 24 insertions(+)
>
> diff --git a/drivers/gpu/drm/drm_plane.c b/drivers/gpu/drm/drm_plane.c
> index 24e7998d1731..d05642033202 100644
> --- a/drivers/gpu/drm/drm_plane.c
> +++ b/drivers/gpu/drm/drm_plane.c
> @@ -140,6 +140,30 @@
> * DRM_FORMAT_MOD_LINEAR. Before linux kernel release v5.1 there have been
> * various bugs in this area with inconsistencies between the capability
> * flag and per-plane properties.
> + *
> + * All drivers should support XRGB8888, even if the hardware cannot support
> + * it. This has become the de-facto standard and a lot of user-space assume
> + * it will be present. If XRGB8888 is not natively supported, then it
> + * shouldn't be the default for preferred depth or fbdev emulation.
> + *
> + * DRM drivers should not do software color conversion, and
> + * only advertise the formats they support in hardware. This is for
> + * performance reason, and to avoid multiple conversions in userspace and
> + * kernel space. KMS page flips are generally expected to be very cheap
> + * operations.
> + *
> + * But there are two exceptions only for dumb buffers:
> + * * To support XRGB8888 if it's not supported by the hardware.
> + * * Any driver is free to modify its internal representation of the format,
> + * as long as it doesn't alter the visible content in any way, and doesn't
> + * modify the user-provided buffer. An example would be to drop the
> + * padding component from a format to save some memory bandwidth.
> + * On most hardware, VRAM read access are slow, so when doing the software
> + * conversion, the dumb buffer should be allocated in system RAM in order to
> + * have decent performance.
> + * Extra care should be taken when doing software conversion with
> + * DRM_CAP_DUMB_PREFER_SHADOW, there are more detailed explanations here:
> + * https://lore.kernel.org/dri-devel/20230818162415.2185f8e3@eldfell/
> */
Acked-by: Pekka Paalanen <pekka.paalanen at collabora.com>
Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/dri-devel/attachments/20230828/162ced88/attachment.sig>
More information about the dri-devel
mailing list