Documentation/gpu/amdgpu/display/mpo-overview.rst

Source file repositories/reference/linux-study-clean/Documentation/gpu/amdgpu/display/mpo-overview.rst

File Facts

System
Linux kernel
Corpus path
Documentation/gpu/amdgpu/display/mpo-overview.rst
Extension
.rst
Size
10692 bytes
Lines
243
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

========================
Multiplane Overlay (MPO)
========================

.. note:: You will get more from this page if you have already read the
   'Documentation/gpu/amdgpu/display/dcn-overview.rst'.


Multiplane Overlay (MPO) allows for multiple framebuffers to be composited via
fixed-function hardware in the display controller rather than using graphics or
compute shaders for composition. This can yield some power savings if it means
the graphics/compute pipelines can be put into low-power states. In summary,
MPO can bring the following benefits:

* Decreased GPU and CPU workload - no composition shaders needed, no extra
  buffer copy needed, GPU can remain idle.
* Plane independent page flips - No need to be tied to global compositor
  page-flip present rate, reduced latency, independent timing.

.. note:: Keep in mind that MPO is all about power-saving; if you want to learn
   more about power-save in the display context, check the link:
   `Power <https://gitlab.freedesktop.org/pq/color-and-hdr/-/blob/main/doc/power.rst>`__.

Multiplane Overlay is only available using the DRM atomic model. The atomic
model only uses a single userspace IOCTL for configuring the display hardware
(modesetting, page-flipping, etc) - drmModeAtomicCommit. To query hardware
resources and limitations userspace also calls into drmModeGetResources which
reports back the number of planes, CRTCs, and connectors. There are three types
of DRM planes that the driver can register and work with:

* ``DRM_PLANE_TYPE_PRIMARY``: Primary planes represent a "main" plane for a
  CRTC, primary planes are the planes operated upon by CRTC modesetting and
  flipping operations.
* ``DRM_PLANE_TYPE_CURSOR``: Cursor planes represent a "cursor" plane for a
  CRTC. Cursor planes are the planes operated upon by the cursor IOCTLs
* ``DRM_PLANE_TYPE_OVERLAY``: Overlay planes represent all non-primary,
  non-cursor planes. Some drivers refer to these types of planes as "sprites"
  internally.

To illustrate how it works, let's take a look at a device that exposes the
following planes to userspace:

* 4 Primary planes (1 per CRTC).
* 4 Cursor planes (1 per CRTC).
* 1 Overlay plane (shared among CRTCs).

.. note:: Keep in mind that different ASICs might expose other numbers of
   planes.

For this hardware example, we have 4 pipes (if you don't know what AMD pipe
means, look at 'Documentation/gpu/amdgpu/display/dcn-overview.rst', section
"AMD Hardware Pipeline"). Typically most AMD devices operate in a pipe-split
configuration for optimal single display output (e.g., 2 pipes per plane).

A typical MPO configuration from userspace - 1 primary + 1 overlay on a single
display - will see 4 pipes in use, 2 per plane.

At least 1 pipe must be used per plane (primary and overlay), so for this
hypothetical hardware that we are using as an example, we have an absolute
limit of 4 planes across all CRTCs. Atomic commits will be rejected for display
configurations using more than 4 planes. Again, it is important to stress that
every DCN has different restrictions; here, we are just trying to provide the
concept idea.

Plane Restrictions
==================

AMDGPU imposes restrictions on the use of DRM planes in the driver.

Atomic commits will be rejected for commits which do not follow these

Annotation

Implementation Notes