Lines Matching +full:can +full:- +full:primary

6    'Documentation/gpu/amdgpu/display/dcn-overview.rst'.
10 fixed-function hardware in the display controller rather than using graphics or
11 compute shaders for composition. This can yield some power savings if it means
12 the graphics/compute pipelines can be put into low-power states. In summary,
13 MPO can bring the following benefits:
15 * Decreased GPU and CPU workload - no composition shaders needed, no extra
16 buffer copy needed, GPU can remain idle.
17 * Plane independent page flips - No need to be tied to global compositor
18 page-flip present rate, reduced latency, independent timing.
20 .. note:: Keep in mind that MPO is all about power-saving; if you want to learn
21 more about power-save in the display context, check the link:
22 `Power <https://gitlab.freedesktop.org/pq/color-and-hdr/-/blob/main/doc/power.rst>`__.
26 (modesetting, page-flipping, etc) - drmModeAtomicCommit. To query hardware
29 of DRM planes that the driver can register and work with:
31 * ``DRM_PLANE_TYPE_PRIMARY``: Primary planes represent a "main" plane for a
32 CRTC, primary planes are the planes operated upon by CRTC modesetting and
36 * ``DRM_PLANE_TYPE_OVERLAY``: Overlay planes represent all non-primary,
37 non-cursor planes. Some drivers refer to these types of planes as "sprites"
43 * 4 Primary planes (1 per CRTC).
51 means, look at 'Documentation/gpu/amdgpu/display/dcn-overview.rst', section
52 "AMD Hardware Pipeline"). Typically most AMD devices operate in a pipe-split
55 A typical MPO configuration from userspace - 1 primary + 1 overlay on a single
56 display - will see 4 pipes in use, 2 per plane.
58 At least 1 pipe must be used per plane (primary and overlay), so for this
80 * Only primary planes have color-space and non-RGB format support
89 .. kernel-figure:: mpo-cursor.svg
92 be blended. However, AMD hardware handles cursors differently, as you can see
108 Picture-in-Picture (PIP) playback - Underlay strategy
109 -----------------------------------------------------
111 Video playback should be done using the "primary plane as underlay" MPO
114 * 1 YUV DRM Primary Plane (e.g. NV12 Video)
117 - The overlay plane contains general desktop UI, video player controls, and video subtitles
118 - Primary plane contains one or more videos
122 userspace request in the future, we can change that).
124 See below a single-video example:
126 .. kernel-figure:: single-display-mpo.svg
131 The video buffer should be used directly for the primary plane. The video can
133 CRTC_W, and CRTC_H. The primary plane should also have the color encoding and
140 (i.e., set the alpha to zero). The primary plane video will be visible through
141 the underlay. The overlay plane's buffer may remain static while the primary
142 plane's framebuffer is used for standard double-buffered playback.
146 scanout. The primary plane should have the color encoding and color range
153 (i.e., set the alpha to zero). The primary plane videos will be visible through
157 This kernel interface is validated using IGT GPU Tools. The following tests can
161 - ``kms_plane@plane-panning-bottom-right-pipe-*-planes``
162 - ``kms_plane@plane-panning-bottom-right-suspend-pipe-*-``
163 - ``kms_plane@plane-panning-top-left-pipe-*-``
164 - ``kms_plane@plane-position-covered-pipe-*-``
165 - ``kms_plane@plane-position-hole-dpms-pipe-*-``
166 - ``kms_plane@plane-position-hole-pipe-*-``
167 - ``kms_plane_multiple@atomic-pipe-*-tiling-``
168 - ``kms_plane_scaling@pipe-*-plane-scaling``
169 - ``kms_plane_alpha_blend@pipe-*-alpha-basic``
170 - ``kms_plane_alpha_blend@pipe-*-alpha-transparant-fb``
171 - ``kms_plane_alpha_blend@pipe-*-alpha-opaque-fb``
172 - ``kms_plane_alpha_blend@pipe-*-constant-alpha-min``
173 - ``kms_plane_alpha_blend@pipe-*-constant-alpha-mid``
174 - ``kms_plane_alpha_blend@pipe-*-constant-alpha-max``
177 --------------------
181 userspace can define different policies. For example, some OSes can use MPO to
183 many limitations for a single display. Nonetheless, this manipulation can have
184 many more restrictions for a multi-display scenario. The below example shows a
188 .. kernel-figure:: multi-display-hdcp-mpo.svg
191 multi-display with MPO.
207 - 1 display (1 pipe) + MPO (1 pipe), we will use two pipes
208 - 2 displays (2 pipes) + MPO (1-2 pipes); we will use 4 pipes. MPO in the
210 - 3 Displays (3 pipes) + MPO (1-2 pipes), we need 5 pipes.
217 * When ASIC has 3 pipes, AMD hardware can NOT support 2 displays with MPO
218 * When ASIC has 4 pipes, AMD hardware can NOT support 3 displays with MPO
220 Let's briefly explore how userspace can handle these two display configurations
221 on an ASIC that only supports three pipes. We can have:
223 .. kernel-figure:: multi-display-hdcp-mpo-less-pipe-ex.svg
225 - Total pipes are 3
226 - User lights up 2 displays (2 out of 3 pipes are used)
227 - User launches video (1 pipe used for MPO)
228 - Now, if the user moves the video in the middle of 2 displays, one part of the