From patchwork Thu Dec 9 14:20:46 2021 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Rodrigo Siqueira Jordao X-Patchwork-Id: 12667459 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 09CE0C433FE for ; Thu, 9 Dec 2021 17:00:54 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 310B910EB96; Thu, 9 Dec 2021 16:54:31 +0000 (UTC) Received: from NAM12-MW2-obe.outbound.protection.outlook.com (mail-mw2nam12on2048.outbound.protection.outlook.com [40.107.244.48]) by gabe.freedesktop.org (Postfix) with ESMTPS id 1015D10E120; Thu, 9 Dec 2021 14:21:20 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=SMHTVwnfMVwtjzMo7GGgAEhtr6zflU9orz9VlJYr2HvZl0PFKaneJZRpG0ZcpnktAkptBSrBJnBXYX23iArm1JTTHPM8iF5IhymtJWUiUjgwMzinC6J2pNVPQTextBvATZBkIWtKN70QBA/sPBbnK7K5BwDirRxsurkAhdyMEIGFrcLNu1FzfThY4tdGthf3ZG20GESn1izNFMQopJbk+hBvf07KQzKcqCr8kb28djXtiVx1rz1D/Rzk9type+4SHFlklRRQ8eaY0M7+sHl25uf7f540VRgtDM7mijfgfzqK6kJNz9tvzq1NGLNjFaT9n/5+hpwdENnTXI+tEC5ooA== 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=g7mXo/pbuMzSncxMXVuY90BL+fDdox4ZR4si2VYoGGE=; b=H+VPItc0j4Ey4qcNRGjAnbPTvBP9JQFQb2housYVgD39aB6HTw3d/FfAtIl8KT/gGa1HZ+sM7FgRlMbJooBcMhnOCfjsyR0QDLZODU0vcVT9ql1KIHiJB9ITl3XT0dHMbh/7SNHGTlTn2SRfYaSRv/AHoEcVRrm2s1MULimE5i7TgUI8Xhq3hWkX5SeoFsVTed9zoNvEKLrx+t3SfVsOCLttlV+L/1G8uXXjHqVVRtWUGrrWdMJOHnKhbXBklPbr+I52amOktnu+fO7EcVoG3WMp5L3V55kTzBdWkotYjxoKQOr/Gu9iKdDJyoJMzoEPyiLFbEHh7RUt+HpkS0Wn4Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass (sender ip is 165.204.84.17) smtp.rcpttodomain=emersion.fr 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=g7mXo/pbuMzSncxMXVuY90BL+fDdox4ZR4si2VYoGGE=; b=XgVnN8xcZ08FFd9G9qW0GMvRPJbUbFslJrmIUiFbwYZ6bzeszy7YoYrJTTDBcDuvoymPxiB2bCEHch9bECfVeM4vDcv19p8TlJkW9z55QR296oy0g1EjMNCBv9Uz3hrCDsb9O5BnlXgMo+MC+nyjalX7uEr7t1HqDMQVTBRTFFA= Received: from MWHPR1401CA0020.namprd14.prod.outlook.com (2603:10b6:301:4b::30) by BYAPR12MB3157.namprd12.prod.outlook.com (2603:10b6:a03:130::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4755.21; Thu, 9 Dec 2021 14:21:11 +0000 Received: from CO1NAM11FT017.eop-nam11.prod.protection.outlook.com (2603:10b6:301:4b:cafe::51) by MWHPR1401CA0020.outlook.office365.com (2603:10b6:301:4b::30) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4778.12 via Frontend Transport; Thu, 9 Dec 2021 14:21:11 +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=SATLEXMB03.amd.com; Received: from SATLEXMB03.amd.com (165.204.84.17) by CO1NAM11FT017.mail.protection.outlook.com (10.13.175.108) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.4755.13 via Frontend Transport; Thu, 9 Dec 2021 14:21:10 +0000 Received: from atma2.hitronhub.home (10.180.168.240) by SATLEXMB03.amd.com (10.181.40.144) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.17; Thu, 9 Dec 2021 08:21:07 -0600 From: Rodrigo Siqueira To: Simon Ser , Michel Daenzer , "Bas Nieuwenhuizen" , Marek Olsak , Roman Gilg , Nicholas Kazlauskas , Harry Wentland , "Mark Yacoub" , Sean Paul , "Pekka Paalanen" , Yann Dirson , Daniel Vetter Subject: [PATCH v4 5/6] Documentation/gpu: Add basic overview of DC pipeline Date: Thu, 9 Dec 2021 09:20:46 -0500 Message-ID: <20211209142047.728572-6-Rodrigo.Siqueira@amd.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20211209142047.728572-1-Rodrigo.Siqueira@amd.com> References: <20211209142047.728572-1-Rodrigo.Siqueira@amd.com> MIME-Version: 1.0 X-Originating-IP: [10.180.168.240] X-ClientProxiedBy: SATLEXMB04.amd.com (10.181.40.145) To SATLEXMB03.amd.com (10.181.40.144) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: e9d30b75-ff8d-40fa-e96a-08d9bb1f2641 X-MS-TrafficTypeDiagnostic: BYAPR12MB3157:EE_ X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:13; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: B14/tD2FFLytr0lB8snO5hUPYgKgjaz2fXWqSgVQVncom3/3zcskYvmzNpwbN1TBmXuLL47Zssx3zDhU3QDNiCryRzhG2yIRIcc67Qlz3E2wW74Cx/hZ+EFiLuw5dM/yeiLclYY8qpXesmqMzDUyFIsL+PpiP9xS9S3UXVnEfw51QmlM5LusVQTCULDwj58gY82v034KxymydrjE33kjsHywXdbkodCFLH8DXiSbxqu0hvOtFOBM1BIHfIQdT4WAGOqq39ijB0sWBASt+I4bf+2OVC1yxj8uO+0rDoNARW48a1zo+kKFJh46CT1zUy8WKErGxgvhclf6XRuqZImXnlK/WJPFE8qlp3/Fk7PGq+WRKgDO9FI45d0wdFSXpGLUGDshetL9XnDXDqqRU9QvRGW3lbX5tCx6uyHbBBGNUZ2QqzP9lGHkMbu1WEgj/a2J7XZz2UdAwnoSkZHw+1kkGB+ubEkLmm67C5EmBLbPLd6lEUKvrSUKA3f/GbnQbu7r4YR+U/+ddPQUEt1QR4a8QU0bApKoZSKLMSS2YZXTeSOHVd0QeAk/W9JRhfO1dIm5rsuJofwwjULm9hGSTUn9bSKK+IEIHG7LwtWUD7B7+z6+Vve7Wa5wVvl8zKbLg7VQ1Yot4hbedH3sSuD29vtGg3mmcS/64cVmlrUbt6+rVSgEQvTxCPHdkMtxNgStCFLXFGOOvXLjPj1Cz1JjGpy72Y6V8Z3HLXkjsDEDG0GhWGPnOLBp+sfQzGzr/20HiPIIR/PuPZS48WHtnoot3J8aZO/ccNXTWbeVq1ni64Tx8gzeqcgErtDmkwfZieeslrkaNCrqs22v8cF1QM37Zz8o5i8bZplGpEnPM7SJfVxvH0lWdcB2X6faMPFbEAjc4m2W7CMsCfr3pJYHBtFAZbfy6TuOkNuHMywdC//haN0X0gqEg9bF4dn7CVwKaJp9zR8GF+3CfRb2lw3BBjpHYW4rwA== X-Forefront-Antispam-Report: CIP:165.204.84.17; CTRY:US; LANG:en; SCL:1; SRV:; IPV:CAL; SFV:NSPM; H:SATLEXMB03.amd.com; PTR:InfoDomainNonexistent; CAT:NONE; SFS:(4636009)(36840700001)(46966006)(40470700001)(83380400001)(19273905006)(316002)(5660300002)(4326008)(47076005)(921005)(1076003)(54906003)(2906002)(30864003)(36860700001)(8676002)(26005)(36756003)(110136005)(508600001)(81166007)(336012)(8936002)(70586007)(86362001)(70206006)(356005)(186003)(16526019)(2616005)(426003)(82310400004)(7416002)(40460700001)(6666004)(36900700001)(559001)(579004)(563064011); DIR:OUT; SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Dec 2021 14:21:10.8307 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: e9d30b75-ff8d-40fa-e96a-08d9bb1f2641 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=[SATLEXMB03.amd.com] X-MS-Exchange-CrossTenant-AuthSource: CO1NAM11FT017.eop-nam11.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR12MB3157 X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: linux-doc@vger.kernel.org, qingqing.zhuo@amd.com, roman.li@amd.com, amd-gfx@lists.freedesktop.org, aurabindo.pillai@amd.com, nicholas.choi@amd.com, dri-devel@lists.freedesktop.org, Alex Deucher , bhawanpreet.lakha@amd.com, Christian Koenig Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" This commit describes how DCN works by providing high-level diagrams with an explanation of each component. In particular, it details the Global Sync signals. Change since V2: - Add a comment about MMHUBBUB. Signed-off-by: Rodrigo Siqueira --- .../gpu/amdgpu/display/config_example.svg | 414 ++++++ .../amdgpu/display/dc_pipeline_overview.svg | 1125 +++++++++++++++++ .../gpu/amdgpu/display/dcn-overview.rst | 171 +++ .../gpu/amdgpu/display/global_sync_vblank.svg | 485 +++++++ Documentation/gpu/amdgpu/display/index.rst | 23 +- 5 files changed, 2206 insertions(+), 12 deletions(-) create mode 100644 Documentation/gpu/amdgpu/display/config_example.svg create mode 100644 Documentation/gpu/amdgpu/display/dc_pipeline_overview.svg create mode 100644 Documentation/gpu/amdgpu/display/dcn-overview.rst create mode 100644 Documentation/gpu/amdgpu/display/global_sync_vblank.svg diff --git a/Documentation/gpu/amdgpu/display/config_example.svg b/Documentation/gpu/amdgpu/display/config_example.svg new file mode 100644 index 000000000000..cdac9858601c --- /dev/null +++ b/Documentation/gpu/amdgpu/display/config_example.svg @@ -0,0 +1,414 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + Configurations + A + B + C + + + + + + A + B + C + C + Old config + Old config + + + VUpdate + UpdateLock + Register updatePending Status + Buf 0 + Buf 1 + + diff --git a/Documentation/gpu/amdgpu/display/dc_pipeline_overview.svg b/Documentation/gpu/amdgpu/display/dc_pipeline_overview.svg new file mode 100644 index 000000000000..9adecebfe65b --- /dev/null +++ b/Documentation/gpu/amdgpu/display/dc_pipeline_overview.svg @@ -0,0 +1,1125 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + DCHUB + HUBP(n) + + + DPP(n) + + + + MPC + + + + OPTC + + + + DIO + + + + DCCG + + + + DMU + + + + + AZ + + + + MMHUBBUB + + + + DWB(n) + + + + + + + + + + + + + Global sync + Pixel data + Sideband signal + Config. Bus + + SDP + + Monitor + + OPP + + + + + + + + + + + + + dc_plane + dc_stream + + + + dc_state + + + + Code struct + + + + dc_link + + + + Floating pointcalculation + + + + bit-depthreduction/dither + } + Notes + + diff --git a/Documentation/gpu/amdgpu/display/dcn-overview.rst b/Documentation/gpu/amdgpu/display/dcn-overview.rst new file mode 100644 index 000000000000..f98624d7828e --- /dev/null +++ b/Documentation/gpu/amdgpu/display/dcn-overview.rst @@ -0,0 +1,171 @@ +======================= +Display Core Next (DCN) +======================= + +To equip our readers with the basic knowledge of how AMD Display Core Next +(DCN) works, we need to start with an overview of the hardware pipeline. Below +you can see a picture that provides a DCN overview, keep in mind that this is a +generic diagram, and we have variations per ASIC. + +.. kernel-figure:: dc_pipeline_overview.svg + +Based on this diagram, we can pass through each block and briefly describe +them: + +* **Display Controller Hub (DCHUB)**: This is the gateway between the Scalable + Data Port (SDP) and DCN. This component has multiple features, such as memory + arbitration, rotation, and cursor manipulation. + +* **Display Pipe and Plane (DPP)**: This block provides pre-blend pixel + processing such as color space conversion, linearization of pixel data, tone + mapping, and gamut mapping. + +* **Multiple Pipe/Plane Combined (MPC)**: This component performs blending of + multiple planes, using global or per-pixel alpha. + +* **Output Pixel Processing (OPP)**: Process and format pixels to be sent to + the display. + +* **Output Pipe Timing Combiner (OPTC)**: It generates time output to combine + streams or divide capabilities. CRC values are generated in this block. + +* **Display Output (DIO)**: Codify the output to the display connected to our + GPU. + +* **Display Writeback (DWB)**: It provides the ability to write the output of + the display pipe back to memory as video frames. + +* **Multi-Media HUB (MMHUBBUB)**: Memory controller interface for DMCUB and DWB + (Note that DWB is not hooked yet). + +* **DCN Management Unit (DMU)**: It provides registers with access control and + interrupts the controller to the SOC host interrupt unit. This block includes + the Display Micro-Controller Unit - version B (DMCUB), which is handled via + firmware. + +* **DCN Clock Generator Block (DCCG)**: It provides the clocks and resets + for all of the display controller clock domains. + +* **Azalia (AZ)**: Audio engine. + +The above diagram is an architecture generalization of DCN, which means that +every ASIC has variations around this base model. Notice that the display +pipeline is connected to the Scalable Data Port (SDP) via DCHUB; you can see +the SDP as the element from our Data Fabric that feeds the display pipe. + +Always approach the DCN architecture as something flexible that can be +configured and reconfigured in multiple ways; in other words, each block can be +setup or ignored accordingly with userspace demands. For example, if we +want to drive an 8k@60Hz with a DSC enabled, our DCN may require 4 DPP and 2 +OPP. It is DC's responsibility to drive the best configuration for each +specific scenario. Orchestrate all of these components together requires a +sophisticated communication interface which is highlighted in the diagram by +the edges that connect each block; from the chart, each connection between +these blocks represents: + +1. Pixel data interface (red): Represents the pixel data flow; +2. Global sync signals (green): It is a set of synchronization signals composed + by VStartup, VUpdate, and VReady; +3. Config interface: Responsible to configure blocks; +4. Sideband signals: All other signals that do not fit the previous one. + +These signals are essential and play an important role in DCN. Nevertheless, +the Global Sync deserves an extra level of detail described in the next +section. + +All of these components are represented by a data structure named dc_state. +From DCHUB to MPC, we have a representation called dc_plane; from MPC to OPTC, +we have dc_stream, and the output (DIO) is handled by dc_link. Keep in mind +that HUBP accesses a surface using a specific format read from memory, and our +dc_plane should work to convert all pixels in the plane to something that can +be sent to the display via dc_stream and dc_link. + +Front End and Back End +---------------------- + +Display pipeline can be broken down into two components that are usually +referred as **Front End (FE)** and **Back End (BE)**, where FE consists of: + +* DCHUB (Mainly referring to a subcomponent named HUBP) +* DPP +* MPC + +On the other hand, BE consist of + +* OPP +* OPTC +* DIO (DP/HDMI stream encoder and link encoder) + +OPP and OPTC are two joining blocks between FE and BE. On a side note, this is +a one-to-one mapping of the link encoder to PHY, but we can configure the DCN +to choose which link encoder to connect to which PHY. FE's main responsibility +is to change, blend and compose pixel data, while BE's job is to frame a +generic pixel stream to a specific display's pixel stream. + +Data Flow +--------- + +Initially, data is passed in from VRAM through Data Fabric (DF) in native pixel +formats. Such data format stays through till HUBP in DCHUB, where HUBP unpacks +different pixel formats and outputs them to DPP in uniform streams through 4 +channels (1 for alpha + 3 for colors). + +The Converter and Cursor (CNVC) in DPP would then normalize the data +representation and convert them to a DCN specific floating-point format (i.e., +different from the IEEE floating-point format). In the process, CNVC also +applies a degamma function to transform the data from non-linear to linear +space to relax the floating-point calculations following. Data would stay in +this floating-point format from DPP to OPP. + +Starting OPP, because color transformation and blending have been completed +(i.e alpha can be dropped), and the end sinks do not require the precision and +dynamic range that floating points provide (i.e. all displays are in integer +depth format), bit-depth reduction/dithering would kick in. In OPP, we would +also apply a regamma function to introduce the gamma removed earlier back. +Eventually, we output data in integer format at DIO. + +Global Sync +----------- + +Many DCN registers are double buffered, most importantly the surface address. +This allows us to update DCN hardware atomically for page flips, as well as +for most other updates that don't require enabling or disabling of new pipes. + +(Note: There are many scenarios when DC will decide to reserve extra pipes +in order to support outputs that need a very high pixel clock, or for +power saving purposes.) + +These atomic register updates are driven by global sync signals in DCN. In +order to understand how atomic updates interact with DCN hardware, and how DCN +signals page flip and vblank events it is helpful to understand how global sync +is programmed. + +Global sync consists of three signals, VSTARTUP, VUPDATE, and VREADY. These are +calculated by the Display Mode Library - DML (drivers/gpu/drm/amd/display/dc/dml) +based on a large number of parameters and ensure our hardware is able to feed +the DCN pipeline without underflows or hangs in any given system configuration. +The global sync signals always happen during VBlank, are independent from the +VSync signal, and do not overlap each other. + +VUPDATE is the only signal that is of interest to the rest of the driver stack +or userspace clients as it signals the point at which hardware latches to +atomically programmed (i.e. double buffered) registers. Even though it is +independent of the VSync signal we use VUPDATE to signal the VSync event as it +provides the best indication of how atomic commits and hardware interact. + +Since DCN hardware is double-buffered the DC driver is able to program the +hardware at any point during the frame. + +The below picture illustrates the global sync signals: + +.. kernel-figure:: global_sync_vblank.svg + +These signals affect core DCN behavior. Programming them incorrectly will lead +to a number of negative consequences, most of them quite catastrophic. + +The following picture shows how global sync allows for a mailbox style of +updates, i.e. it allows for multiple re-configurations between VUpdate +events where only the last configuration programmed before the VUpdate signal +becomes effective. + +.. kernel-figure:: config_example.svg diff --git a/Documentation/gpu/amdgpu/display/global_sync_vblank.svg b/Documentation/gpu/amdgpu/display/global_sync_vblank.svg new file mode 100644 index 000000000000..48f5dc4fd5d3 --- /dev/null +++ b/Documentation/gpu/amdgpu/display/global_sync_vblank.svg @@ -0,0 +1,485 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + To + VStartup Period + VUpdateWidth + VReadyOffset + VUpdateOffset + VSTARTUP_START + VSYNC + VBlank + VStartup + VUpdate + VReady + + + + + + + + + + diff --git a/Documentation/gpu/amdgpu/display/index.rst b/Documentation/gpu/amdgpu/display/index.rst index a443866332ac..fe2ecad8df81 100644 --- a/Documentation/gpu/amdgpu/display/index.rst +++ b/Documentation/gpu/amdgpu/display/index.rst @@ -2,28 +2,27 @@ drm/amd/display - Display Core (DC) =================================== -*placeholder - general description of supported platforms, what dc is, etc.* - -Because it is partially shared with other operating systems, the Display Core -Driver is divided in two pieces. +AMD display engine is partially shared with other operating systems; for this +reason, our Display Core Driver is divided into two pieces: 1. **Display Core (DC)** contains the OS-agnostic components. Things like hardware programming and resource management are handled here. 2. **Display Manager (DM)** contains the OS-dependent components. Hooks to the amdgpu base driver and DRM are implemented here. -It doesn't help that the entire package is frequently referred to as DC. But -with the context in mind, it should be clear. +The display pipe is responsible for "scanning out" a rendered frame from the +GPU memory (also called VRAM, FrameBuffer, etc.) to a display. In other words, +it would: -When CONFIG_DRM_AMD_DC is enabled, DC will be initialized by default for -supported ASICs. To force disable, set `amdgpu.dc=0` on kernel command line. -Likewise, to force enable on unsupported ASICs, set `amdgpu.dc=1`. +1. Read frame information from memory; +2. Perform required transformation; +3. Send pixel data to sink devices. -To determine if DC is loaded, search dmesg for the following entry: +If you want to learn more about our driver details, take a look at the below +table of content: .. toctree:: display-manager.rst dc-debug.rst - -``Display Core initialized with `` + dcn-overview.rst