From ace9429bb58fd418f0c81d4c2835699bddf6bde6 Mon Sep 17 00:00:00 2001 From: Daniel Baumann Date: Thu, 11 Apr 2024 10:27:49 +0200 Subject: Adding upstream version 6.6.15. Signed-off-by: Daniel Baumann --- .../gpu/amdgpu/display/config_example.svg | 414 ++++++ Documentation/gpu/amdgpu/display/dc-debug.rst | 77 + Documentation/gpu/amdgpu/display/dc-glossary.rst | 237 +++ .../gpu/amdgpu/display/dc_pipeline_overview.svg | 1125 ++++++++++++++ Documentation/gpu/amdgpu/display/dcn-overview.rst | 230 +++ .../gpu/amdgpu/display/dcn2_cm_drm_current.svg | 1370 ++++++++++++++++++ .../gpu/amdgpu/display/dcn3_cm_drm_current.svg | 1529 ++++++++++++++++++++ .../gpu/amdgpu/display/display-manager.rst | 183 +++ .../gpu/amdgpu/display/global_sync_vblank.svg | 485 +++++++ Documentation/gpu/amdgpu/display/index.rst | 32 + Documentation/gpu/amdgpu/display/mpo-cursor.svg | 435 ++++++ Documentation/gpu/amdgpu/display/mpo-overview.rst | 242 ++++ .../multi-display-hdcp-mpo-less-pipe-ex.svg | 220 +++ .../gpu/amdgpu/display/multi-display-hdcp-mpo.svg | 171 +++ .../gpu/amdgpu/display/pipeline_4k_no_split.svg | 958 ++++++++++++ .../gpu/amdgpu/display/pipeline_4k_split.svg | 1062 ++++++++++++++ .../display/single-display-mpo-multi-video.svg | 339 +++++ .../gpu/amdgpu/display/single-display-mpo.svg | 266 ++++ 18 files changed, 9375 insertions(+) create mode 100644 Documentation/gpu/amdgpu/display/config_example.svg create mode 100644 Documentation/gpu/amdgpu/display/dc-debug.rst create mode 100644 Documentation/gpu/amdgpu/display/dc-glossary.rst 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/dcn2_cm_drm_current.svg create mode 100644 Documentation/gpu/amdgpu/display/dcn3_cm_drm_current.svg create mode 100644 Documentation/gpu/amdgpu/display/display-manager.rst create mode 100644 Documentation/gpu/amdgpu/display/global_sync_vblank.svg create mode 100644 Documentation/gpu/amdgpu/display/index.rst 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/pipeline_4k_no_split.svg create mode 100644 Documentation/gpu/amdgpu/display/pipeline_4k_split.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 (limited to 'Documentation/gpu/amdgpu/display') diff --git a/Documentation/gpu/amdgpu/display/config_example.svg b/Documentation/gpu/amdgpu/display/config_example.svg new file mode 100644 index 0000000000..cdac985860 --- /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-debug.rst b/Documentation/gpu/amdgpu/display/dc-debug.rst new file mode 100644 index 0000000000..40c55a6189 --- /dev/null +++ b/Documentation/gpu/amdgpu/display/dc-debug.rst @@ -0,0 +1,77 @@ +======================== +Display Core Debug tools +======================== + +DC Visual Confirmation +====================== + +Display core provides a feature named visual confirmation, which is a set of +bars added at the scanout time by the driver to convey some specific +information. In general, you can enable this debug option by using:: + + echo > /sys/kernel/debug/dri/0/amdgpu_dm_visual_confirm + +Where `N` is an integer number for some specific scenarios that the developer +wants to enable, you will see some of these debug cases in the following +subsection. + +Multiple Planes Debug +--------------------- + +If you want to enable or debug multiple planes in a specific user-space +application, you can leverage a debug feature named visual confirm. For +enabling it, you will need:: + + echo 1 > /sys/kernel/debug/dri/0/amdgpu_dm_visual_confirm + +You need to reload your GUI to see the visual confirmation. When the plane +configuration changes or a full update occurs there will be a colored bar at +the bottom of each hardware plane being drawn on the screen. + +* The color indicates the format - For example, red is AR24 and green is NV12 +* The height of the bar indicates the index of the plane +* Pipe split can be observed if there are two bars with a difference in height + covering the same plane + +Consider the video playback case in which a video is played in a specific +plane, and the desktop is drawn in another plane. The video plane should +feature one or two green bars at the bottom of the video depending on pipe +split configuration. + +* There should **not** be any visual corruption +* There should **not** be any underflow or screen flashes +* There should **not** be any black screens +* There should **not** be any cursor corruption +* Multiple plane **may** be briefly disabled during window transitions or + resizing but should come back after the action has finished + +Pipe Split Debug +---------------- + +Sometimes we need to debug if DCN is splitting pipes correctly, and visual +confirmation is also handy for this case. Similar to the MPO case, you can use +the below command to enable visual confirmation:: + + echo 1 > /sys/kernel/debug/dri/0/amdgpu_dm_visual_confirm + +In this case, if you have a pipe split, you will see one small red bar at the +bottom of the display covering the entire display width and another bar +covering the second pipe. In other words, you will see a bit high bar in the +second pipe. + +DTN Debug +========= + +DC (DCN) provides an extensive log that dumps multiple details from our +hardware configuration. Via debugfs, you can capture those status values by +using Display Test Next (DTN) log, which can be captured via debugfs by using:: + + cat /sys/kernel/debug/dri/0/amdgpu_dm_dtn_log + +Since this log is updated accordingly with DCN status, you can also follow the +change in real-time by using something like:: + + sudo watch -d cat /sys/kernel/debug/dri/0/amdgpu_dm_dtn_log + +When reporting a bug related to DC, consider attaching this log before and +after you reproduce the bug. diff --git a/Documentation/gpu/amdgpu/display/dc-glossary.rst b/Documentation/gpu/amdgpu/display/dc-glossary.rst new file mode 100644 index 0000000000..0b0ffd428d --- /dev/null +++ b/Documentation/gpu/amdgpu/display/dc-glossary.rst @@ -0,0 +1,237 @@ +=========== +DC Glossary +=========== + +On this page, we try to keep track of acronyms related to the display +component. If you do not find what you are looking for, look at the +'Documentation/gpu/amdgpu/amdgpu-glossary.rst'; if you cannot find it anywhere, +consider asking in the amdgfx and update this page. + +.. glossary:: + + ABM + Adaptive Backlight Modulation + + APU + Accelerated Processing Unit + + ASIC + Application-Specific Integrated Circuit + + ASSR + Alternate Scrambler Seed Reset + + AZ + Azalia (HD audio DMA engine) + + BPC + Bits Per Colour/Component + + BPP + Bits Per Pixel + + Clocks + * PCLK: Pixel Clock + * SYMCLK: Symbol Clock + * SOCCLK: GPU Engine Clock + * DISPCLK: Display Clock + * DPPCLK: DPP Clock + * DCFCLK: Display Controller Fabric Clock + * REFCLK: Real Time Reference Clock + * PPLL: Pixel PLL + * FCLK: Fabric Clock + * MCLK: Memory Clock + + CRC + Cyclic Redundancy Check + + CRTC + Cathode Ray Tube Controller - commonly called "Controller" - Generates + raw stream of pixels, clocked at pixel clock + + CVT + Coordinated Video Timings + + DAL + Display Abstraction layer + + DC (Software) + Display Core + + DC (Hardware) + Display Controller + + DCC + Delta Colour Compression + + DCE + Display Controller Engine + + DCHUB + Display Controller HUB + + ARB + Arbiter + + VTG + Vertical Timing Generator + + DCN + Display Core Next + + DCCG + Display Clock Generator block + + DDC + Display Data Channel + + DIO + Display IO + + DPP + Display Pipes and Planes + + DSC + Display Stream Compression (Reduce the amount of bits to represent pixel + count while at the same pixel clock) + + dGPU + discrete GPU + + DMIF + Display Memory Interface + + DML + Display Mode Library + + DMCU + Display Micro-Controller Unit + + DMCUB + Display Micro-Controller Unit, version B + + DPCD + DisplayPort Configuration Data + + DPM(S) + Display Power Management (Signaling) + + DRR + Dynamic Refresh Rate + + DWB + Display Writeback + + FB + Frame Buffer + + FBC + Frame Buffer Compression + + FEC + Forward Error Correction + + FRL + Fixed Rate Link + + GCO + Graphical Controller Object + + GSL + Global Swap Lock + + iGPU + integrated GPU + + ISR + Interrupt Service Request + + ISV + Independent Software Vendor + + KMD + Kernel Mode Driver + + LB + Line Buffer + + LFC + Low Framerate Compensation + + LTTPR + Link Training Tunable Phy Repeater + + LUT + Lookup Table + + MALL + Memory Access at Last Level + + MC + Memory Controller + + MPC/MPCC + Multiple pipes and plane combine + + MPO + Multi Plane Overlay + + MST + Multi Stream Transport + + NBP State + Northbridge Power State + + NBIO + North Bridge Input/Output + + ODM + Output Data Mapping + + OPM + Output Protection Manager + + OPP + Output Plane Processor + + OPTC + Output Pipe Timing Combiner + + OTG + Output Timing Generator + + PCON + Power Controller + + PGFSM + Power Gate Finite State Machine + + PSR + Panel Self Refresh + + SCL + Scaler + + SDP + Scalable Data Port + + SLS + Single Large Surface + + SST + Single Stream Transport + + TMDS + Transition-Minimized Differential Signaling + + TMZ + Trusted Memory Zone + + TTU + Time to Underflow + + VRR + Variable Refresh Rate + + UVD + Unified Video Decoder 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 0000000000..9adecebfe6 --- /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 0000000000..9fea650044 --- /dev/null +++ b/Documentation/gpu/amdgpu/display/dcn-overview.rst @@ -0,0 +1,230 @@ +======================= +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. + +AMD Hardware Pipeline +--------------------- + +When discussing graphics on Linux, the **pipeline** term can sometimes be +overloaded with multiple meanings, so it is important to define what we mean +when we say **pipeline**. In the DCN driver, we use the term **hardware +pipeline** or **pipeline** or just **pipe** as an abstraction to indicate a +sequence of DCN blocks instantiated to address some specific configuration. DC +core treats DCN blocks as individual resources, meaning we can build a pipeline +by taking resources for all individual hardware blocks to compose one pipeline. +In actuality, we can't connect an arbitrary block from one pipe to a block from +another pipe; they are routed linearly, except for DSC, which can be +arbitrarily assigned as needed. We have this pipeline concept for trying to +optimize bandwidth utilization. + +.. kernel-figure:: pipeline_4k_no_split.svg + +Additionally, let's take a look at parts of the DTN log (see +'Documentation/gpu/amdgpu/display/dc-debug.rst' for more information) since +this log can help us to see part of this pipeline behavior in real-time:: + + HUBP: format addr_hi width height ... + [ 0]: 8h 81h 3840 2160 + [ 1]: 0h 0h 0 0 + [ 2]: 0h 0h 0 0 + [ 3]: 0h 0h 0 0 + [ 4]: 0h 0h 0 0 + ... + MPCC: OPP DPP ... + [ 0]: 0h 0h ... + +The first thing to notice from the diagram and DTN log it is the fact that we +have different clock domains for each part of the DCN blocks. In this example, +we have just a single **pipeline** where the data flows from DCHUB to DIO, as +we intuitively expect. Nonetheless, DCN is flexible, as mentioned before, and +we can split this single pipe differently, as described in the below diagram: + +.. kernel-figure:: pipeline_4k_split.svg + +Now, if we inspect the DTN log again we can see some interesting changes:: + + HUBP: format addr_hi width height ... + [ 0]: 8h 81h 1920 2160 ... + ... + [ 4]: 0h 0h 0 0 ... + [ 5]: 8h 81h 1920 2160 ... + ... + MPCC: OPP DPP ... + [ 0]: 0h 0h ... + [ 5]: 0h 5h ... + +From the above example, we now split the display pipeline into two vertical +parts of 1920x2160 (i.e., 3440x2160), and as a result, we could reduce the +clock frequency in the DPP part. This is not only useful for saving power but +also to better handle the required throughput. The idea to keep in mind here is +that the pipe configuration can vary a lot according to the display +configuration, and it is the DML's responsibility to set up all required +configuration parameters for multiple scenarios supported by our hardware. + +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/dcn2_cm_drm_current.svg b/Documentation/gpu/amdgpu/display/dcn2_cm_drm_current.svg new file mode 100644 index 0000000000..315ffc5a1a --- /dev/null +++ b/Documentation/gpu/amdgpu/display/dcn2_cm_drm_current.svg @@ -0,0 +1,1370 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Matrix + 1D LUT + 3D LUT + Unpacking + Other + drm_framebuffer + format + drm_plane + drm_crtc + Stream + MPC + DPP + + Blender + Degamma + CTM + Gamma + format + bias_and_scale + color space matrix + input_csc_color_matrix + in_transfer_func + hdr_mult + gamut_remap_matrix + in_shaper_func + lut3d_func + blend_tf + Blender + gamut_remap_matrix + func_shaper + lut3d_func + out_transfer_func + csc_color_matrix + bit_depth_param + clamping + output_color_space + Plane + Legend + DCN 2.0 + DC Interface + DRM Interface + + CNVC + Input CSC + DeGammaRAM and ROM(sRGB, BT2020 + HDR Multiply + Gamut Remap + Shaper LUTRAM + 3D LUTRAM + Blend Gamma + Blender + GammaRAM + OCSC + + + color_encoding + + pixel_blend_mode + + color_range + + + + + + + + + + + + + + diff --git a/Documentation/gpu/amdgpu/display/dcn3_cm_drm_current.svg b/Documentation/gpu/amdgpu/display/dcn3_cm_drm_current.svg new file mode 100644 index 0000000000..7299ee9b6d --- /dev/null +++ b/Documentation/gpu/amdgpu/display/dcn3_cm_drm_current.svg @@ -0,0 +1,1529 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Matrix + 1D LUT + 3D LUT + Unpacking + Other + drm_framebuffer + format + drm_plane + drm_crtc + Stream + MPC + DPP + + Blender + Degamma + CTM + Gamma + format + bias_and_scale + color space matrix + input_csc_color_matrix + in_transfer_func + hdr_mult + gamut_remap_matrix + in_shaper_func + lut3d_func + blend_tf + Blender + gamut_remap_matrix + func_shaper + lut3d_func + out_transfer_func + csc_color_matrix + bit_depth_param + clamping + output_color_space + Plane + Legend + DCN 3.0 + DC Interface + DRM Interface + + CNVC + Input CSC + DeGammaROM(sRGB, BT2020, Gamma 2.2,PQ, HLG) + Post CSC + Gamma Correction + HDR Multiply + Gamut Remap + Shaper LUTRAM + 3D LUTRAM + Blend Gamma + Blender + Gamut Remap + Shaper LUTRAM + 3D LUTRAM + GammaRAM + OCSC + + + color_encoding + + pixel_blend_mode + + color_range + + + + + + + + + + + + + + + + + + diff --git a/Documentation/gpu/amdgpu/display/display-manager.rst b/Documentation/gpu/amdgpu/display/display-manager.rst new file mode 100644 index 0000000000..be2651ecdd --- /dev/null +++ b/Documentation/gpu/amdgpu/display/display-manager.rst @@ -0,0 +1,183 @@ +====================== +AMDgpu Display Manager +====================== + +.. contents:: Table of Contents + :depth: 3 + +.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c + :doc: overview + +.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.h + :internal: + +Lifecycle +========= + +.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c + :doc: DM Lifecycle + +.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c + :functions: dm_hw_init dm_hw_fini + +Interrupts +========== + +.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c + :doc: overview + +.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_irq.c + :internal: + +.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c + :functions: register_hpd_handlers dm_crtc_high_irq dm_pflip_high_irq + +Atomic Implementation +===================== + +.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c + :doc: atomic + +.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm.c + :functions: amdgpu_dm_atomic_check amdgpu_dm_atomic_commit_tail + +Color Management Properties +=========================== + +.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c + :doc: overview + +.. kernel-doc:: drivers/gpu/drm/amd/display/amdgpu_dm/amdgpu_dm_color.c + :internal: + + +DC Color Capabilities between DCN generations +--------------------------------------------- + +DRM/KMS framework defines three CRTC color correction properties: degamma, +color transformation matrix (CTM) and gamma, and two properties for degamma and +gamma LUT sizes. AMD DC programs some of the color correction features +pre-blending but DRM/KMS has not per-plane color correction properties. + +In general, the DRM CRTC color properties are programmed to DC, as follows: +CRTC gamma after blending, and CRTC degamma pre-blending. Although CTM is +programmed after blending, it is mapped to DPP hw blocks (pre-blending). Other +color caps available in the hw is not currently exposed by DRM interface and +are bypassed. + +.. kernel-doc:: drivers/gpu/drm/amd/display/dc/dc.h + :doc: color-management-caps + +.. kernel-doc:: drivers/gpu/drm/amd/display/dc/dc.h + :internal: + +The color pipeline has undergone major changes between DCN hardware +generations. What's possible to do before and after blending depends on +hardware capabilities, as illustrated below by the DCN 2.0 and DCN 3.0 families +schemas. + +**DCN 2.0 family color caps and mapping** + +.. kernel-figure:: dcn2_cm_drm_current.svg + +**DCN 3.0 family color caps and mapping** + +.. kernel-figure:: dcn3_cm_drm_current.svg + +Blend Mode Properties +===================== + +Pixel blend mode is a DRM plane composition property of :c:type:`drm_plane` used to +describes how pixels from a foreground plane (fg) are composited with the +background plane (bg). Here, we present main concepts of DRM blend mode to help +to understand how this property is mapped to AMD DC interface. See more about +this DRM property and the alpha blending equations in :ref:`DRM Plane +Composition Properties `. + +Basically, a blend mode sets the alpha blending equation for plane +composition that fits the mode in which the alpha channel affects the state of +pixel color values and, therefore, the resulted pixel color. For +example, consider the following elements of the alpha blending equation: + +- *fg.rgb*: Each of the RGB component values from the foreground's pixel. +- *fg.alpha*: Alpha component value from the foreground's pixel. +- *bg.rgb*: Each of the RGB component values from the background. +- *plane_alpha*: Plane alpha value set by the **plane "alpha" property**, see + more in :ref:`DRM Plane Composition Properties `. + +in the basic alpha blending equation:: + + out.rgb = alpha * fg.rgb + (1 - alpha) * bg.rgb + +the alpha channel value of each pixel in a plane is ignored and only the plane +alpha affects the resulted pixel color values. + +DRM has three blend mode to define the blend formula in the plane composition: + +* **None**: Blend formula that ignores the pixel alpha. + +* **Pre-multiplied**: Blend formula that assumes the pixel color values in a + plane was already pre-multiplied by its own alpha channel before storage. + +* **Coverage**: Blend formula that assumes the pixel color values were not + pre-multiplied with the alpha channel values. + +and pre-multiplied is the default pixel blend mode, that means, when no blend +mode property is created or defined, DRM considers the plane's pixels has +pre-multiplied color values. On IGT GPU tools, the kms_plane_alpha_blend test +provides a set of subtests to verify plane alpha and blend mode properties. + +The DRM blend mode and its elements are then mapped by AMDGPU display manager +(DM) to program the blending configuration of the Multiple Pipe/Plane Combined +(MPC), as follows: + +.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h + :doc: mpc-overview + +.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h + :functions: mpcc_blnd_cfg + +Therefore, the blending configuration for a single MPCC instance on the MPC +tree is defined by :c:type:`mpcc_blnd_cfg`, where +:c:type:`pre_multiplied_alpha` is the alpha pre-multiplied mode flag used to +set :c:type:`MPCC_ALPHA_MULTIPLIED_MODE`. It controls whether alpha is +multiplied (true/false), being only true for DRM pre-multiplied blend mode. +:c:type:`mpcc_alpha_blend_mode` defines the alpha blend mode regarding pixel +alpha and plane alpha values. It sets one of the three modes for +:c:type:`MPCC_ALPHA_BLND_MODE`, as described below. + +.. kernel-doc:: drivers/gpu/drm/amd/display/dc/inc/hw/mpc.h + :functions: mpcc_alpha_blend_mode + +DM then maps the elements of `enum mpcc_alpha_blend_mode` to those in the DRM +blend formula, as follows: + +* *MPC pixel alpha* matches *DRM fg.alpha* as the alpha component value + from the plane's pixel +* *MPC global alpha* matches *DRM plane_alpha* when the pixel alpha should + be ignored and, therefore, pixel values are not pre-multiplied +* *MPC global gain* assumes *MPC global alpha* value when both *DRM + fg.alpha* and *DRM plane_alpha* participate in the blend equation + +In short, *fg.alpha* is ignored by selecting +:c:type:`MPCC_ALPHA_BLEND_MODE_GLOBAL_ALPHA`. On the other hand, (plane_alpha * +fg.alpha) component becomes available by selecting +:c:type:`MPCC_ALPHA_BLEND_MODE_PER_PIXEL_ALPHA_COMBINED_GLOBAL_GAIN`. And the +:c:type:`MPCC_ALPHA_MULTIPLIED_MODE` defines if the pixel color values are +pre-multiplied by alpha or not. + +Blend configuration flow +------------------------ + +The alpha blending equation is configured from DRM to DC interface by the +following path: + +1. When updating a :c:type:`drm_plane_state `, DM calls + :c:type:`amdgpu_dm_plane_fill_blending_from_plane_state()` that maps + :c:type:`drm_plane_state ` attributes to + :c:type:`dc_plane_info ` struct to be handled in the + OS-agnostic component (DC). + +2. On DC interface, :c:type:`struct mpcc_blnd_cfg ` programs the + MPCC blend configuration considering the :c:type:`dc_plane_info + ` input from DPP. 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 0000000000..48f5dc4fd5 --- /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 new file mode 100644 index 0000000000..f8a4f53d70 --- /dev/null +++ b/Documentation/gpu/amdgpu/display/index.rst @@ -0,0 +1,32 @@ +.. _amdgpu-display-core: + +=================================== +drm/amd/display - Display Core (DC) +=================================== + +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. + +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: + +1. Read frame information from memory; +2. Perform required transformation; +3. Send pixel data to sink devices. + +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 + 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 0000000000..9d9de76847 --- /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 0000000000..59a4f54a3a --- /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 +userspace 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 0000000000..6d06b39e83 --- /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 0000000000..84d53a558b --- /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/pipeline_4k_no_split.svg b/Documentation/gpu/amdgpu/display/pipeline_4k_no_split.svg new file mode 100644 index 0000000000..5fa289d99f --- /dev/null +++ b/Documentation/gpu/amdgpu/display/pipeline_4k_no_split.svg @@ -0,0 +1,958 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + DCHUB + + DPP(0) + + + + + HUBP(0) + + + + + + HUBP(1) + + + + + + HUBP(5) + + + + + ... + + ... + + + MPC(0) + + + + OPP(0) + + + ... + + + + OPTC + + + + ... + + SDP + + + + DPPCLK535.916Mhz + DISPCLK541.275 Mhz + DCFCLK506 Mhz + SymCLK + + DIO + + + + VirtualPCLK + + + diff --git a/Documentation/gpu/amdgpu/display/pipeline_4k_split.svg b/Documentation/gpu/amdgpu/display/pipeline_4k_split.svg new file mode 100644 index 0000000000..b43119e7eb --- /dev/null +++ b/Documentation/gpu/amdgpu/display/pipeline_4k_split.svg @@ -0,0 +1,1062 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + DCHUB + + DPP(0) + + + + + HUBP(0) + + + + + + HUBP(1) + + + + + + HUBP(5) + + + + + ... + + DPP(5) + + + + + ... + + + MPC(0) + + + + MPC(5) + + + + OPP(0) + + + ... + + + + + OPP(0) + + + + + OPTC + + + + + ... + + SDP + + + + DPPCLK267.958Mhz + DISPCLK541.275 Mhz + DCFCLK506 Mhz + SymCLK + + DIO + + + + VirtualPCLK + + + 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 0000000000..fa807115cf --- /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 0000000000..fb53b0920c --- /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 + + + + -- cgit v1.2.3