Lines Matching +full:quality +full:- +full:of +full:- +full:service

9 in DC is shared with other OSes; for this reason, DC provides a set of
11 configuration. See DC as a service available for a Display Manager (amdgpu_dm)
12 to access and configure DCN/DCE hardware (DCE is also part of DC, but for
22 problem is well-defined, it will probably be implemented at the hardware level.
23 On the other hand, when there are multiple ways of achieving something without
24 a very well-defined scope, the solution is usually implemented as a policy at
26 (resource management, power optimization, image quality, etc.), and the others
29 In terms of hardware management, DCN has multiple instances of the same block
31 necessary to use some of these instances. The core has policies in place for
35 easier to maneuver if the hardware resource is still used for the same set of
40 Another area of influence for DC is power optimization, which has a myriad of
44 Unfortunately, there is no straight-forward analytic way to determine if a
45 configuration is the best one for the context due to the enormous variety of
49 is possible to support it or not. This type of policy is extremely complex to
53 In summary, DC must deal with the complexity of handling multiple scenarios and
54 determine policies to manage them. All of the above information is conveyed to
55 give the reader some idea about the complexity of driving a display from the
62 The diagram below provides an overview of the display driver architecture;
65 .. kernel-figure:: dc-components.svg
67 The first layer of the diagram is the high-level DC API represented by the
70 the`hw_sequencer.h`, where the implementation of the callbacks can be found in
72 API (`dc/inc/hw`), which represents each DCN low-level block, such as HUBP,
73 DPP, MPC, OPTC, etc. Notice on the left side of the diagram that we have a
74 different set of layers representing the interaction with the DMUB
78 -------------
84 .. kernel-figure:: dc-arch-overview.svg
92 is a low-level abstraction for the connector. One interesting aspect of the
93 image is that connectors are not part of the DCN block; they are defined by the
94 platform/board and not by the SoC. The `dc_link` struct is the high-level data
112 `dc_state` is composed of `dc_stream` and `dc_plane`. The `dc_stream` is the DC
113 version of `drm_crtc` and represents the post-blending pipeline.
115 Speaking of the `dc_plane` data structure (first part of the diagram), you can
117 pre-blending portion of the pipeline. This image was probably processed by GFX
123 ----------------
125 Now that we have covered the basic objects, it is time to examine some of the
129 preparing for enabling other parts of the API. It is important to highlight
137 for the hardware-specific initialization, whereas `dc_hardware_init` does the
142 on the device; this is required since this information is not part of the SoC
144 initialized, it is useful to figure out if any of them are already connected to
158 the best-case scenario, you might be able to turn the display on with a black