diff mbox series

[2/2] drm/doc: Document that userspace should utilize CRTCs bottom up

Message ID 20240612141903.17219-2-ville.syrjala@linux.intel.com (mailing list archive)
State New, archived
Headers show
Series [1/2] drm/doc: Document drm_get_encoder ioctl more thoroughly | expand

Commit Message

Ville Syrjälä June 12, 2024, 2:19 p.m. UTC 
From: Ville Syrjälä <ville.syrjala@linux.intel.com>

At leat on Intel GPUs it is best to allocate CRTCs bottom up
as it will generally lead to lower power consumption. Recommend
userspace does so.

Not sure if this is strictly the best order for other hardware,
but drivers could always rearrange the CRTC list into some kind
of priority order to make it work. Should that turn out to be
insufficient we might need some kind of more complex priority
scheme.

Probably the ideal solution would be to have the driver be
responsible for resource allocation entirely. Ie. the CRTCs
visible via uapi would be virtual and the driver could make
the final choice on which hardware CRTC to use for each.
Unfortunately the kms uapi is geared towards exposing hardware
directly. Eg. when CRTCs are non-uniform in hardware there is
no good way to expose their capabilities. The virtual CRTCs
would more or less either have to expose a superset or a subset
of the capabilities across all hardware CRTCs. Also the
crtc->encoder->connector routing information exposed in the
uapi is all about the actual hardware signal routing. I think
robust virtualized CRTCs would require some new form of uapi
where userspace could declare ahead of time which features
wants on the CRTC (even if not enabling all of them from
the start), and the driver would then have enough information
to make the optimal choice.

Cc: Simon Ser <contact@emersion.fr>
Cc: Daniel Stone <daniels@collabora.com>
Signed-off-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
---
 include/uapi/drm/drm_mode.h | 3 +++
 1 file changed, 3 insertions(+)

Comments

Simon Ser Aug. 20, 2024, 8:27 p.m. UTC | #1 
Sorry for the huge delay. Generally this looks good but maybe we
could explain a bit more what "bottom up" means exactly since it
may not be super obvious.

Maybe something among these lines?

    Bottom up means that the first CRTCs in the array should be used
    first. For instance, if the driver exposes 4 CRTCs and user-space
    needs 2, it should prioritize CRTCs with indices 0 and 1.
Simon Ser Oct. 15, 2024, 4:50 p.m. UTC | #2 
On Tuesday, August 20th, 2024 at 22:27, Simon Ser <contact@emersion.fr> wrote:

> Sorry for the huge delay. Generally this looks good but maybe we
> could explain a bit more what "bottom up" means exactly since it
> may not be super obvious.
> 
> Maybe something among these lines?
> 
> Bottom up means that the first CRTCs in the array should be used
> first. For instance, if the driver exposes 4 CRTCs and user-space
> needs 2, it should prioritize CRTCs with indices 0 and 1.

Gentle ping - what do you think, Ville?
diff mbox series

Patch

diff --git a/include/uapi/drm/drm_mode.h b/include/uapi/drm/drm_mode.h
index fe5e210396b2..aa90f11950d6 100644
--- a/include/uapi/drm/drm_mode.h
+++ b/include/uapi/drm/drm_mode.h
@@ -386,6 +386,9 @@  struct drm_mode_get_encoder {
 
 	/**
 	 * @possible_crtcs: Bitmask of CRTCs compatible with the encoder.
+	 * If multiple CRTCs are possible userspace should generally try
+	 * to utilize CRTCs bottom up as that may result in lower power
+	 * consumption on some systems.
 	 * CRTCs are created and they receive an index, which corresponds
 	 * to their position in the bitmask. Bit N corresponds to
 	 * :ref:`CRTC index<crtc_index>` N.