From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 22449C433EF for ; Mon, 13 Jun 2022 20:02:01 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 9FD7D10F720; Mon, 13 Jun 2022 20:02:00 +0000 (UTC) Received: from NAM04-DM6-obe.outbound.protection.outlook.com (mail-dm6nam04on2067.outbound.protection.outlook.com [40.107.102.67]) by gabe.freedesktop.org (Postfix) with ESMTPS id ED19910F786 for ; Mon, 13 Jun 2022 20:01:58 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=axT+Foc13HfeqqCvk/kyJaFpFyT+H7JPfrGECQGW3RdBoU57Nym7CR4r2H+x6k3wGkLrMcWHANxFWjX/x2egOlZRiNZMWOlp6TkzLTe0Cua6RPdI98FSZJLnqLU5xqhp6RowQ4bfZ/xtc2WqmS9jwZ0njUcdQlhHpaWqNNl2M7Rv8MUxHGpBV2HE16SZGCeQkBNAV5kkHlLIyS4jlFghrwwBZZ1sX655qx89fRll6w3U7XLol2H19pguFPIuU4sCxwhkpPM22s8oElxX7cV4TcTjh5QWy7SntdFTkZt3AhSxlTMdfLqAv6qHBuMu1WrdAb/2wnFEo2MaIzTNBGsX9w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=9MyH75ou8uimCrcv7QFa4pPbbom3yVVM7uvltqyza6c=; b=oMt9bV3QQgpFwsp7t1E3aJMUFtDalocHNS7VBUCTamwWIUEqoqlVKwMhy5cZWbVNRzumxFOaRC+BlfXb//Q4L/373aNZc87uh8RHK4UFlmtUsDm/fkjPVxZWbScR0SVcFVG6lKUWTPlq9JJKo/DmVtGh9z1SlVDVmtnZZ4/6kw6QmxsciqCXAGZoNr1JJOrMsE7ipWQdxq7JTlqyo74uIjXq47mTk0VxU1mQRyTsj4SWC5M5hzpdp6YrB2+uof4MQBhQYDNSLTBAfmnsCuAJEnCwEoQXavzAxdC2AOdM9EkzxueWH1Mscam4koclljA53Uxhr+7R6p5RZC+GCAAMFQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=lists.freedesktop.org smtp.mailfrom=amd.com; dmarc=pass (p=quarantine sp=quarantine pct=100) action=none header.from=amd.com; dkim=none (message not signed); arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9MyH75ou8uimCrcv7QFa4pPbbom3yVVM7uvltqyza6c=; b=rxW8Pu82I0dpJENCLF28//yYgS56PkXCYkgVq6N6Wtx/KEyGjOQVzpCYy9QfnAdnw0aevlYGsCSWL+gK/fZqIZqMO+3zIVe13r/5NfzaTOlPx/vTbPrYx5Te2XiXTqfsL5L2b/kQcyiPOEsLSwTwJkA3h2Pl/iCEgMEQ1IGgs6c= Received: from DS7PR03CA0239.namprd03.prod.outlook.com (2603:10b6:5:3ba::34) by PH7PR12MB5618.namprd12.prod.outlook.com (2603:10b6:510:134::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5332.20; Mon, 13 Jun 2022 20:01:56 +0000 Received: from DM6NAM11FT006.eop-nam11.prod.protection.outlook.com (2603:10b6:5:3ba:cafe::cd) by DS7PR03CA0239.outlook.office365.com (2603:10b6:5:3ba::34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5332.12 via Frontend Transport; Mon, 13 Jun 2022 20:01:55 +0000 X-MS-Exchange-Authentication-Results: spf=pass (sender IP is 165.204.84.17) smtp.mailfrom=amd.com; dkim=none (message not signed) header.d=none;dmarc=pass action=none header.from=amd.com; Received-SPF: Pass (protection.outlook.com: domain of amd.com designates 165.204.84.17 as permitted sender) receiver=protection.outlook.com; client-ip=165.204.84.17; helo=SATLEXMB04.amd.com; pr=C Received: from SATLEXMB04.amd.com (165.204.84.17) by DM6NAM11FT006.mail.protection.outlook.com (10.13.173.104) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.5332.12 via Frontend Transport; Mon, 13 Jun 2022 20:01:55 +0000 Received: from atma2.amd.com (10.180.168.240) by SATLEXMB04.amd.com (10.181.40.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.28; Mon, 13 Jun 2022 15:01:53 -0500 From: Rodrigo Siqueira To: Subject: [PATCH 3/3] Documentation/gpu: Add Multiplane Overlay doc Date: Mon, 13 Jun 2022 16:01:12 -0400 Message-ID: <20220613200112.3377638-4-Rodrigo.Siqueira@amd.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20220613200112.3377638-1-Rodrigo.Siqueira@amd.com> References: <20220613200112.3377638-1-Rodrigo.Siqueira@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB04.amd.com (10.181.40.145) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 928d8417-0677-453f-cc65-08da4d77910b X-MS-TrafficTypeDiagnostic: PH7PR12MB5618:EE_ X-Microsoft-Antispam-PRVS: X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: MnkXR//sb4FVMXHCzkP5v3I6HrfLjO/ZTtyZlGS0Xde0hqhIvwCX+asDlwpuo32xQPbUCe6cisToMU8bUqruYa5s3tzIcvMs/Ie1kUNLnJVCW/RGWQccspt2FdXkjQVgQCMPVnSlXr2v5FAMmq5EiB0dT5SAhqCPd1uSyO14oqYjQys6CfWJWnzpOvs03JiIcI/d5bhUV53DIY4WW7yH78VS2yhc8dBPrWR8GNbE2x5BUiN6Q9NUULTr/CNeffgwF0Ssk05W/sNO3QAWZeYWBu4Npoyih64oyp1sqqOJ3tu4+O4EtVEcK1QlklXqEEv8ulIy/obKULv71V4ggzYv1VpGd5r8D3lpQcOYjKK0J2gtNJaVoe6FHdvtKYtPxTtslSBwHTm7NA+xos4ovuhY/ghS1tuCl5D9512EuqYySUpOSaOYnHFMi1qvWJIg2rXQodb72vZrOuWzNdxu9JDxCLa4WWhDXChcWdfZV2nxVS96wCk+e5DWomb9zqVspr3Qn0dxcEavwiAvVdbxphrsKDMy6ZxTaBZExzWfK+TsaKJ9TTCoYH2IcoI+oi5UqOPZgJ/6+L+QFQdTQdbLLhNavhVD4TyoVwyuBOx+zjcVBcMCq86DKm7qL/encUM3BQ9Rfo/pJ1Ey/o6FKRm/tD2Zvv89bgr9bl8yDKYKi0LU7D9bniaZAAHS+bv+K7UUaSsQ9eeVrynbfJuXfliVo+3UqzgycdkjN5H3Fxtw76cWDGBflGERl2/GyngcfFfhOi0r5miR2lHXSsti3H6jVqwXZd+e0dKn/VYxCHSBVdZ04NcYb5p1CyjMrTbdC2rVipoIWD23rc9JsYoLFvBrFrCAU9rEaoOz1ZwHS/yNxG/uIUc= X-Forefront-Antispam-Report: CIP:165.204.84.17; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:SATLEXMB04.amd.com; PTR:InfoDomainNonexistent; CAT:NONE; SFS:(13230016)(4636009)(36840700001)(46966006)(40470700004)(36756003)(2906002)(356005)(7696005)(26005)(81166007)(186003)(30864003)(7416002)(86362001)(8936002)(40460700003)(36860700001)(5660300002)(70586007)(4326008)(966005)(1076003)(508600001)(6666004)(2616005)(70206006)(426003)(47076005)(66574015)(336012)(19273905006)(82310400005)(8676002)(83380400001)(16526019)(6916009)(316002)(54906003)(36900700001)(559001)(579004)(563064011); DIR:OUT; SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Jun 2022 20:01:55.5169 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 928d8417-0677-453f-cc65-08da4d77910b X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d; Ip=[165.204.84.17]; Helo=[SATLEXMB04.amd.com] X-MS-Exchange-CrossTenant-AuthSource: DM6NAM11FT006.eop-nam11.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR12MB5618 X-BeenThere: amd-gfx@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussion list for AMD gfx List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Pierre-Eric Pelloux-Prayer , Mark Yacoub , Pekka Paalanen , Simon Ser , =?UTF-8?q?Michel=20D=C3=A4nzer?= , Alex Hung , maira.canal@usp.br, mwen@igalia.com, Leo Li , Bhawanpreet Lakha , Hersen Wu , tales.aparecida@gmail.com, Sean Paul , isabbasso@riseup.net, andrealmeid@riseup.net, Harry Wentland , Nicholas Kazlauskas , Pierre-Loup Errors-To: amd-gfx-bounces@lists.freedesktop.org Sender: "amd-gfx" Multiple plane overlay is a feature supported by AMD hardware, but it has specific details that deserve proper documentation. This commit introduces a documentation that describes some of the features, limitations, and use cases for this feature. Part of this documentation came from some discussion in the public upstream [1][2]. [1]. https://lore.kernel.org/amd-gfx/3qY-QeukF_Q_MJeIXAuBjO4szbS4jRtqkTifXnbnN3bp88SxVodFQRpah3mIIVJq24DUkF6g0rOGdCmSqTvVxx9LCGEItmzLw8uWU44jtXE=@emersion.fr/ [2]. https://lore.kernel.org/amd-gfx/864e45d0-c14b-3b12-0f5b-9d26a9cb41bd@amd.com/ Cc: Harry Wentland Cc: Nicholas Kazlauskas Cc: Bhawanpreet Lakha Cc: Hersen Wu Cc: Alex Hung Cc: Pierre-Eric Pelloux-Prayer Cc: Simon Ser Cc: Pekka Paalanen Cc: Sean Paul Cc: Mark Yacoub Cc: Leo Li Cc: Pierre-Loup Cc: Michel Dänzer Signed-off-by: Rodrigo Siqueira --- Documentation/gpu/amdgpu/display/index.rst | 1 + .../gpu/amdgpu/display/mpo-cursor.svg | 435 ++++++++++++++++++ .../gpu/amdgpu/display/mpo-overview.rst | 242 ++++++++++ .../multi-display-hdcp-mpo-less-pipe-ex.svg | 220 +++++++++ .../amdgpu/display/multi-display-hdcp-mpo.svg | 171 +++++++ .../single-display-mpo-multi-video.svg | 339 ++++++++++++++ .../gpu/amdgpu/display/single-display-mpo.svg | 266 +++++++++++ 7 files changed, 1674 insertions(+) create mode 100644 Documentation/gpu/amdgpu/display/mpo-cursor.svg create mode 100644 Documentation/gpu/amdgpu/display/mpo-overview.rst create mode 100644 Documentation/gpu/amdgpu/display/multi-display-hdcp-mpo-less-pipe-ex.svg create mode 100644 Documentation/gpu/amdgpu/display/multi-display-hdcp-mpo.svg create mode 100644 Documentation/gpu/amdgpu/display/single-display-mpo-multi-video.svg create mode 100644 Documentation/gpu/amdgpu/display/single-display-mpo.svg diff --git a/Documentation/gpu/amdgpu/display/index.rst b/Documentation/gpu/amdgpu/display/index.rst index c1fb2fb3c710..f8a4f53d70d8 100644 --- a/Documentation/gpu/amdgpu/display/index.rst +++ b/Documentation/gpu/amdgpu/display/index.rst @@ -28,4 +28,5 @@ table of content: display-manager.rst dc-debug.rst dcn-overview.rst + mpo-overview.rst dc-glossary.rst diff --git a/Documentation/gpu/amdgpu/display/mpo-cursor.svg b/Documentation/gpu/amdgpu/display/mpo-cursor.svg new file mode 100644 index 000000000000..9d9de76847c3 --- /dev/null +++ b/Documentation/gpu/amdgpu/display/mpo-cursor.svg @@ -0,0 +1,435 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + Cursor + + + + Plane 1 + + + + Plane 2 + + + + + CRTC + + + + Cursor + + + + Plane 1 + + + + Plane 2 + + + + CRTC + + DRM + AMD Hardware + + + + + + + + + diff --git a/Documentation/gpu/amdgpu/display/mpo-overview.rst b/Documentation/gpu/amdgpu/display/mpo-overview.rst new file mode 100644 index 000000000000..0499aa92d08d --- /dev/null +++ b/Documentation/gpu/amdgpu/display/mpo-overview.rst @@ -0,0 +1,242 @@ +======================== +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 `__. + +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 +restrictions: + +* Overlay planes must be in ARGB8888 or XRGB8888 format +* Planes cannot be placed outside of the CRTC destination rectangle +* Planes cannot be downscaled more than 1/4x of their original size +* Planes cannot be upscaled more than 16x of their original size + +Not every property is available on every plane: + +* Only primary planes have color-space and non-RGB format support +* Only overlay planes have alpha blending support + +Cursor Restrictions +=================== + +Before we start to describe some restrictions around cursor and MPO, see the +below image: + +.. kernel-figure:: mpo-cursor.svg + +The image on the left side represents how DRM expects the cursor and planes to +be blended. However, AMD hardware handles cursors differently, as you can see +on the right side; basically, our cursor cannot be drawn outside its associated +plane as it is being treated as part of the plane. Another consequence of that +is that cursors inherit the color and scale from the plane. + +As a result of the above behavior, do not use legacy API to set up the cursor +plane when working with MPO; otherwise, you might encounter unexpected +behavior. + +In short, AMD HW has no dedicated cursor planes. A cursor is attached to +another plane and therefore inherits any scaling or color processing from its +parent plane. + +Use Cases +========= + +Picture-in-Picture (PIP) playback - Underlay strategy +----------------------------------------------------- + +Video playback should be done using the "primary plane as underlay" MPO +strategy. This is a 2 planes configuration: + +* 1 YUV DRM Primary Plane (e.g. NV12 Video) +* 1 RGBA DRM Overlay Plane (e.g. ARGB8888 desktop). The compositor should + prepare the framebuffers for the planes as follows: + - The overlay plane contains general desktop UI, video player controls, and video subtitles + - Primary plane contains one or more videos + +.. note:: Keep in mind that we could extend this configuration to more planes, + but that is currently not supported by our driver yet (maybe if we have a + userspace request in the future, we can change that). + +See below a single-video example: + +.. kernel-figure:: single-display-mpo.svg + +.. note:: We could extend this behavior to more planes, but that is currently + not supported by our driver. + +The video buffer should be used directly for the primary plane. The video can +be scaled and positioned for the desktop using the properties: CRTC_X, CRTC_Y, +CRTC_W, and CRTC_H. The primary plane should also have the color encoding and +color range properties set based on the source content: + +* ``COLOR_RANGE``, ``COLOR_ENCODING`` + +The overlay plane should be the native size of the CRTC. The compositor must +draw a transparent cutout for where the video should be placed on the desktop +(i.e., set the alpha to zero). The primary plane video will be visible through +the underlay. The overlay plane's buffer may remain static while the primary +plane's framebuffer is used for standard double-buffered playback. + +The compositor should create a YUV buffer matching the native size of the CRTC. +Each video buffer should be composited onto this YUV buffer for direct YUV +scanout. The primary plane should have the color encoding and color range +properties set based on the source content: ``COLOR_RANGE``, +``COLOR_ENCODING``. However, be mindful that the source color space and +encoding match for each video since it affect the entire plane. + +The overlay plane should be the native size of the CRTC. The compositor must +draw a transparent cutout for where each video should be placed on the desktop +(i.e., set the alpha to zero). The primary plane videos will be visible through +the underlay. The overlay plane's buffer may remain static while compositing +operations for video playback will be done on the video buffer. + +This kernel interface is validated using IGT GPU Tools. The following tests can +be run to validate positioning, blending, scaling under a variety of sequences +and interactions with operations such as DPMS and S3: + +- ``kms_plane@plane-panning-bottom-right-pipe-*-planes`` +- ``kms_plane@plane-panning-bottom-right-suspend-pipe-*-`` +- ``kms_plane@plane-panning-top-left-pipe-*-`` +- ``kms_plane@plane-position-covered-pipe-*-`` +- ``kms_plane@plane-position-hole-dpms-pipe-*-`` +- ``kms_plane@plane-position-hole-pipe-*-`` +- ``kms_plane_multiple@atomic-pipe-*-tiling-`` +- ``kms_plane_scaling@pipe-*-plane-scaling`` +- ``kms_plane_alpha_blend@pipe-*-alpha-basic`` +- ``kms_plane_alpha_blend@pipe-*-alpha-transparant-fb`` +- ``kms_plane_alpha_blend@pipe-*-alpha-opaque-fb`` +- ``kms_plane_alpha_blend@pipe-*-constant-alpha-min`` +- ``kms_plane_alpha_blend@pipe-*-constant-alpha-mid`` +- ``kms_plane_alpha_blend@pipe-*-constant-alpha-max`` + +Multiple Display MPO +-------------------- + +AMDGPU supports display MPO when using multiple displays; however, this feature +behavior heavily relies on the compositor implementation. Keep in mind that +usespace can define different policies. For example, some OSes can use MPO to +protect the plane that handles the video playback; notice that we don't have +many limitations for a single display. Nonetheless, this manipulation can have +many more restrictions for a multi-display scenario. The below example shows a +video playback in the middle of two displays, and it is up to the compositor to +define a policy on how to handle it: + +.. kernel-figure:: multi-display-hdcp-mpo.svg + +Let's discuss some of the hardware limitations we have when dealing with +multi-display with MPO. + +Limitations +~~~~~~~~~~~ + +For simplicity's sake, for discussing the hardware limitation, this +documentation supposes an example where we have two displays and video playback +that will be moved around different displays. + +* **Hardware limitations** + +From the DCN overview page, each display requires at least one pipe and each +MPO plane needs another pipe. As a result, when the video is in the middle of +the two displays, we need to use 2 pipes. See the example below where we avoid +pipe split: + +- 1 display (1 pipe) + MPO (1 pipe), we will use two pipes +- 2 displays (2 pipes) + MPO (1-2 pipes); we will use 4 pipes. MPO in the + middle of both displays needs 2 pipes. +- 3 Displays (3 pipes) + MPO (1-2 pipes), we need 5 pipes. + +If we use MPO with multiple displays, the userspace has to decide to enable +multiple MPO by the price of limiting the number of external displays supported +or disable it in favor of multiple displays; it is a policy decision. For +example: + +* When ASIC has 3 pipes, AMD hardware can NOT support 2 displays with MPO +* When ASIC has 4 pipes, AMD hardware can NOT support 3 displays with MPO + +Let's briefly explore how userspace can handle these two display configurations +on an ASIC that only supports three pipes. We can have: + +.. kernel-figure:: multi-display-hdcp-mpo-less-pipe-ex.svg + +- Total pipes are 3 +- User lights up 2 displays (2 out of 3 pipes are used) +- User launches video (1 pipe used for MPO) +- Now, if the user moves the video in the middle of 2 displays, one part of the + video won't be MPO since we have used 3/3 pipes. + +* **Scaling limitation** + +MPO cannot handle scaling less than 0.25 and more than x16. For example: + +If 4k video (3840x2160) is playing in windowed mode, the physical size of the +window cannot be smaller than (960x540). + +.. note:: These scaling limitations might vary from ASIC to ASIC. + +* **Size Limitation** + +The minimum MPO size is 12px. diff --git a/Documentation/gpu/amdgpu/display/multi-display-hdcp-mpo-less-pipe-ex.svg b/Documentation/gpu/amdgpu/display/multi-display-hdcp-mpo-less-pipe-ex.svg new file mode 100644 index 000000000000..6d06b39e83fa --- /dev/null +++ b/Documentation/gpu/amdgpu/display/multi-display-hdcp-mpo-less-pipe-ex.svg @@ -0,0 +1,220 @@ + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + ProtectedMPO plane + + + #1 + #2 + Desktop + Desktop + #3 + SoftwareComposited Video + Video will not be displayed + + diff --git a/Documentation/gpu/amdgpu/display/multi-display-hdcp-mpo.svg b/Documentation/gpu/amdgpu/display/multi-display-hdcp-mpo.svg new file mode 100644 index 000000000000..84d53a558b05 --- /dev/null +++ b/Documentation/gpu/amdgpu/display/multi-display-hdcp-mpo.svg @@ -0,0 +1,171 @@ + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + ProtectedMPO plane + + + Desktop + Desktop + Video + + diff --git a/Documentation/gpu/amdgpu/display/single-display-mpo-multi-video.svg b/Documentation/gpu/amdgpu/display/single-display-mpo-multi-video.svg new file mode 100644 index 000000000000..fa807115cfe2 --- /dev/null +++ b/Documentation/gpu/amdgpu/display/single-display-mpo-multi-video.svg @@ -0,0 +1,339 @@ + + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + Video Buffer (YUV) + CRTC Output + + Hardware Composition + + + + + + + + + + + + + + + + + + + + + + + + + + + Desktop Buffer (ARGB) + + diff --git a/Documentation/gpu/amdgpu/display/single-display-mpo.svg b/Documentation/gpu/amdgpu/display/single-display-mpo.svg new file mode 100644 index 000000000000..fb53b0920c87 --- /dev/null +++ b/Documentation/gpu/amdgpu/display/single-display-mpo.svg @@ -0,0 +1,266 @@ + + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + + Video Buffer (YUV)DRM PRIMARY PLANE + + Desktop Buffer (ARGB)DRM OVERLAY PLANE + + + + + + + + CRTC Output + + HardwareComposition + + + + -- 2.25.1