Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline

On Thu, 25 Nov 2021 20:43:19 +0000 "Shankar, Uma" uma.shankar@intel.com wrote:

...

-----Original Message----- From: Harry Wentland harry.wentland@amd.com Sent: Tuesday, November 23, 2021 8:35 PM To: Shankar, Uma uma.shankar@intel.com; intel-gfx@lists.freedesktop.org; dri- devel@lists.freedesktop.org Cc: ville.syrjala@linux.intel.com; ppaalanen@gmail.com; brian.starkey@arm.com; sebastian@sebastianwick.net; Shashank.Sharma@amd.com Subject: Re: [RFC v2 01/22] drm: RFC for Plane Color Hardware Pipeline

On 2021-09-06 17:38, Uma Shankar wrote:

...

This is a RFC proposal for plane color hardware blocks. It exposes the property interface to userspace and calls out the details or interfaces created and the intended purpose.

Credits: Ville Syrjälä ville.syrjala@linux.intel.com Signed-off-by: Uma Shankar uma.shankar@intel.com

---

Documentation/gpu/rfc/drm_color_pipeline.rst | 167 +++++++++++++++++++ 1 file changed, 167 insertions(+) create mode 100644 Documentation/gpu/rfc/drm_color_pipeline.rst

diff --git a/Documentation/gpu/rfc/drm_color_pipeline.rst b/Documentation/gpu/rfc/drm_color_pipeline.rst new file mode 100644 index 000000000000..0d1ca858783b --- /dev/null +++ b/Documentation/gpu/rfc/drm_color_pipeline.rst @@ -0,0 +1,167 @@ +================================================== +Display Color Pipeline: Proposed DRM Properties +==================================================

+This is how a typical display color hardware pipeline looks like:

• +-------------------------------------------+
• | RAM |
• | +------+ +---------+ +---------+ |
• | | FB 1 | | FB 2 | | FB N | |
• | +------+ +---------+ +---------+ |
• +-------------------------------------------+

•   |  Plane Color Hardware Block |
  

• +--------------------------------------------+
• | +---v-----+ +---v-------+ +---v------+ |
• | | Plane A | | Plane B | | Plane N | |
• | | DeGamma | | Degamma | | Degamma | |
• | +---+-----+ +---+-------+ +---+------+ |
• | | | | |
• | +---v-----+ +---v-------+ +---v------+ |
• | |Plane A | | Plane B | | Plane N | |
• | |CSC/CTM | | CSC/CTM | | CSC/CTM | |
• | +---+-----+ +----+------+ +----+-----+ |
• | | | | |
• | +---v-----+ +----v------+ +----v-----+ |
• | | Plane A | | Plane B | | Plane N | |
• | | Gamma | | Gamma | | Gamma | |
• | +---+-----+ +----+------+ +----+-----+ |
• | | | | |
• +--------------------------------------------+

++------v--------------v---------------v-------| +|| || +|| Pipe Blender || ++--------------------+------------------------+ +| | | +| +-----------v----------+ | +| | Pipe DeGamma | | +| | | | +| +-----------+----------+ | +| | Pipe Color | +| +-----------v----------+ Hardware | +| | Pipe CSC/CTM | | +| | | | +| +-----------+----------+ | +| | | +| +-----------v----------+ | +| | Pipe Gamma | | +| | | | +| +-----------+----------+ | +| | | ++---------------------------------------------+

•                 |
  

•                 v
  

•           Pipe Output
  

This diagram defines what happens before and after the blending space but did where does scaling fit into it? Scaling can look different when performed in linear or non-linear space so I think it is important to define where in the pipeline it sits.

In my view scaling would happen between plane degamma and plane CSC.

Yeah we can add scaling as well to make it clear. Scaling ideally should happen after Degamma. In intel's case it is after the CSC.

Btw. are you aware that if a plane has an alpha channel which is used for pixel coverage (i.e. shape anti-aliasing), then non-nearest sampling and therefore also scaling must operate on alpha pre-multiplied optical (linear) values?

For the best results, of course.

So after degamma indeed, but you cannot degamma with pre-multiplied alpha, yet scaling should use pre-multiplied alpha.

Thanks, pq