From patchwork Thu Nov 25 15:38:29 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: 12639417 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 4538AC433F5 for ; Thu, 25 Nov 2021 15:40:06 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 61EA46E9EE; Thu, 25 Nov 2021 15:39:53 +0000 (UTC) Received: from NAM04-DM6-obe.outbound.protection.outlook.com (mail-dm6nam08on2058.outbound.protection.outlook.com [40.107.102.58]) by gabe.freedesktop.org (Postfix) with ESMTPS id 224646EA09; Thu, 25 Nov 2021 15:39:46 +0000 (UTC) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Dr67slwP75gorn+vhurzu7alq20x1qAkK1klWpD9YVkQucILjJtvGmao6XiaMJewfuz+1emjWsJs/iG5q0wHKhk06qFRhzm5AnRfUmvqnKDKMHS0epOwClahOcfSjmkAVXr162pcSP+G0wnQvOYek9LQV7CArvHG6QcnzXA3m5Q+IpS+8GNDs1HGjC1kJ9IkO93TKomJB01lkcbhLBz8ilLBjOf+YdsoQucP6aNPU+Qc8FS2evN/6cm/ByS1/IsBZ6HV6jsKwT8mOTWszrfLcwQAMciiv3shE0gy/m4qYkim51PQpImRl5yeimtdqXk/EhdhBnkZKPwi2J7xWoVX0Q== 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=6IRU5XVBoB2ckYgrNalUU6mjHxIxY7qzdnVx6FS6Gbg=; b=JG5wQpv4TYcSWyIUJIzKLG2EnniSP+UBEcXSH8ppdjbL/LnWcQwE3UTjLxzED5n/RGHgRzqbTWCnu4IYMlLp5LC8N/MEECnN2F6RHoZK5m6pMA6pbeW/lRb0bNX+21/R80GL9qF7bQKRY199g3tkbS8YTwOjZDpWFkn2UJzxxZKTAwZgb2/ouRMdESLkBsgn+/PLuOaO+oYz3FtOOuKxeVE1U6Y7AWsKdcONlUMIRGwfoQe+F3Tf1LbgVVs53NFyvME76xLInpqxdCgzOoaJVS6kOohftxS4yNPcAqCU75o/hHBZ7M3MKq+AkKiL/ip5Fx48c3NvncrrJtEdN/pGhw== 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=6IRU5XVBoB2ckYgrNalUU6mjHxIxY7qzdnVx6FS6Gbg=; b=3vUeQjIrEQ8Y+nwwEGRWd11zZf6e22kA8yD4+y8NFqtr4YtUnbjggmsaWsSy6rvusA5TOEEuwBH0cQAoakBHylSzqnObTOn59htMgr8fsyFDuHR1EIhXN85gxfh3uC7gesvGSpufcnXgWgDIVE8VTcCEU4Db3Ux5Se/9ncj+tPw= Received: from BN0PR04CA0201.namprd04.prod.outlook.com (2603:10b6:408:e9::26) by DM5PR12MB1417.namprd12.prod.outlook.com (2603:10b6:3:73::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4734.22; Thu, 25 Nov 2021 15:39:40 +0000 Received: from BN8NAM11FT052.eop-nam11.prod.protection.outlook.com (2603:10b6:408:e9:cafe::c8) by BN0PR04CA0201.outlook.office365.com (2603:10b6:408:e9::26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4713.21 via Frontend Transport; Thu, 25 Nov 2021 15:39:40 +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; Received: from SATLEXMB04.amd.com (165.204.84.17) by BN8NAM11FT052.mail.protection.outlook.com (10.13.177.210) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.20.4734.22 via Frontend Transport; Thu, 25 Nov 2021 15:39:40 +0000 Received: from atma2.hitronhub.home (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.17; Thu, 25 Nov 2021 09:39:38 -0600 From: Rodrigo Siqueira To: Simon Ser , =?utf-8?q?Michel_D=C3=A4nzer?= , Bas Nieuwenhuizen , =?utf-8?b?TWFyZWsgT2zFocOhaw==?= , Roman Gilg , Nicholas Kazlauskas , "Harry Wentland" , Mark Yacoub , Sean Paul , Pekka Paalanen Subject: [PATCH 5/6] Documentation/gpu: Add basic overview of DC pipeline Date: Thu, 25 Nov 2021 10:38:29 -0500 Message-ID: <20211125153830.1352994-6-Rodrigo.Siqueira@amd.com> X-Mailer: git-send-email 2.25.1 In-Reply-To: <20211125153830.1352994-1-Rodrigo.Siqueira@amd.com> References: <20211125153830.1352994-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 SATLEXMB04.amd.com (10.181.40.145) X-EOPAttributedMessage: 0 X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: d6694c28-d113-4655-468c-08d9b029cbb8 X-MS-TrafficTypeDiagnostic: DM5PR12MB1417: X-Microsoft-Antispam-PRVS: X-MS-Oob-TLC-OOBClassifiers: OLM:10000; X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: 1pJzDDh8XS5zoie6xO0DKOSroq3foywhk9qCuhQ3MjqVNyvLN1gpB5uZhCQYSiUBVRvyiARYOVNEebNjnVUx05bCHQqnuDe8L0ple0kPmHq/U7fIyMV1Tz6Et1tsvuSUO/fr4P3vrrw/Vfwz2H1eNxv7n14KI0aRPF5liqtyVif2CBkF7IlJofFbYFzedsQDE669CWcYDZFGJDvE8sdSFFkai0fKn1GC+xvPP2dNIeAnqMh/DH1XjeSWShwxDQnD0iV5835D1bnl1ytJESq+ViU9hJeIY/WZwQRLY1NerIrX29oxIVxphjVbws7Rtt1SJq0+LDL9+oCtBRjq6b+76wxL1p5OIB9aDrgDFcs/lWzUfA2P3tHhfYBDk6wPm5pGrll7f2wa4xe18VMqUa05OSgfHvjo4OtlHApbG5Mt6LSAYvVZb0oi5BNM1NlUfwGcTLtuWzwH5dQxOjPsXDBu+EBuinBXvyN52Mv628wJ4pNdrrwNhmXgs10jD0BTHdMWgJ8HHMWGHcUe9VGBBrqn32O4rwdDnasMSd7I9Hm3L47EdcYtRTgNlg6sHWxUnYD4pm5fXIqRMEXHl8gRnFxI01b7McM29pqmoDr9DzyopRC0YwMA0qM9gDSS1cTsLfp7F61vcLwyrXfZXq0bGe72P1jDLvetMPrMo8nVYNvZq9G9GAAso3QYiqUgLl+4ZOhfv33UNmz2bg2wS1yZLN7WWw/bbpGs0LOTuhndARKlpxMxgIM9kY4muEi3celJQ3Bb8/38F1ZlZM6N1a0AuJf/dsQEeL5IU4z0TsTc7jcZNyAKAzQlgn0sjw7GdnTCe2RrYw+M6ji2S4RSs4t9t6cCeQnZ2+jsRWBx3xQv/jx8UCCUCMDFqJd0U+sIEAjT+BhTn9CKHq2ECdZ88IUvFN7wZw== 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:(4636009)(36840700001)(46966006)(82310400004)(426003)(36860700001)(86362001)(7416002)(83380400001)(5660300002)(16526019)(508600001)(47076005)(30864003)(186003)(36756003)(336012)(2616005)(4326008)(356005)(70586007)(26005)(2906002)(19273905006)(8676002)(70206006)(81166007)(6666004)(316002)(8936002)(1076003)(921005)(54906003)(110136005)(36900700001)(579004)(559001)(563064011); DIR:OUT; SFP:1101; X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Nov 2021 15:39:40.7185 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d6694c28-d113-4655-468c-08d9b029cbb8 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: BN8NAM11FT052.eop-nam11.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR12MB1417 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, =?utf-8?q?Christian_K=C3=B6nig?= 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. Signed-off-by: Rodrigo Siqueira --- Documentation/gpu/amdgpu-dc/amdgpu-dc.rst | 22 +- .../gpu/amdgpu-dc/amdgpu-dcn-overview.rst | 168 +++ .../gpu/amdgpu-dc/config_example.svg | 414 ++++++ .../gpu/amdgpu-dc/dc_pipeline_overview.svg | 1125 +++++++++++++++++ .../gpu/amdgpu-dc/global_sync_vblank.svg | 485 +++++++ 5 files changed, 2203 insertions(+), 11 deletions(-) create mode 100644 Documentation/gpu/amdgpu-dc/amdgpu-dcn-overview.rst create mode 100644 Documentation/gpu/amdgpu-dc/config_example.svg create mode 100644 Documentation/gpu/amdgpu-dc/dc_pipeline_overview.svg create mode 100644 Documentation/gpu/amdgpu-dc/global_sync_vblank.svg diff --git a/Documentation/gpu/amdgpu-dc/amdgpu-dc.rst b/Documentation/gpu/amdgpu-dc/amdgpu-dc.rst index 3685b3b1ad64..2e45e83d9a2a 100644 --- a/Documentation/gpu/amdgpu-dc/amdgpu-dc.rst +++ b/Documentation/gpu/amdgpu-dc/amdgpu-dc.rst @@ -2,28 +2,28 @@ 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:: + amdgpu-dcn-overview.rst amdgpu-dm.rst amdgpu-dc-debug.rst -``Display Core initialized with `` diff --git a/Documentation/gpu/amdgpu-dc/amdgpu-dcn-overview.rst b/Documentation/gpu/amdgpu-dc/amdgpu-dcn-overview.rst new file mode 100644 index 000000000000..47e9a70de8ae --- /dev/null +++ b/Documentation/gpu/amdgpu-dc/amdgpu-dcn-overview.rst @@ -0,0 +1,168 @@ +======================= +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. + +* **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 updated 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-dc/config_example.svg b/Documentation/gpu/amdgpu-dc/config_example.svg new file mode 100644 index 000000000000..cdac9858601c --- /dev/null +++ b/Documentation/gpu/amdgpu-dc/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-dc/dc_pipeline_overview.svg b/Documentation/gpu/amdgpu-dc/dc_pipeline_overview.svg new file mode 100644 index 000000000000..9adecebfe65b --- /dev/null +++ b/Documentation/gpu/amdgpu-dc/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-dc/global_sync_vblank.svg b/Documentation/gpu/amdgpu-dc/global_sync_vblank.svg new file mode 100644 index 000000000000..48f5dc4fd5d3 --- /dev/null +++ b/Documentation/gpu/amdgpu-dc/global_sync_vblank.svg @@ -0,0 +1,485 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + To + VStartup Period + VUpdateWidth + VReadyOffset + VUpdateOffset + VSTARTUP_START + VSYNC + VBlank + VStartup + VUpdate + VReady + + + + + + + + + +