dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Shashank Sharma <shashank.sharma@intel.com>
To: dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org
Cc: Liviu.Dudau@arm.com, jsarha@ti.com, tomi.valkeinen@ti.com,
	laurent.pinchart@ideasonboard.com
Subject: [PATCH] RFC: Design: DRM: Blending pipeline using DRM plane properties
Date: Mon, 24 Apr 2017 14:32:18 +0530	[thread overview]
Message-ID: <1493024538-17149-1-git-send-email-shashank.sharma@intel.com> (raw)
In-Reply-To: <20170421135203.GN30290@intel.com>

This patch proposes a RFC design to handle blending of various
framebuffers with different color spaces, using the DRM color
properties.

Signed-off-by: Shashank Sharma <shashank.sharma@intel.com>
---
 drivers/gpu/drm/rfc-design-blending.txt | 52 +++++++++++++++++++++++++++++++++
 1 file changed, 52 insertions(+)
 create mode 100644 drivers/gpu/drm/rfc-design-blending.txt

diff --git a/drivers/gpu/drm/rfc-design-blending.txt b/drivers/gpu/drm/rfc-design-blending.txt
new file mode 100644
index 0000000..55d96e9
--- /dev/null
+++ b/drivers/gpu/drm/rfc-design-blending.txt
@@ -0,0 +1,52 @@
+Hi all,
+
+I wanted to send this design in a separate thread, but then I realized we can use this thread itself as many of the
+stakeholders are already active here.
+
+As you all know, we will be dealing with the complex situations of blending of two(or more) different buffers
+in the pipeline, which are in different format and different color space.
+(PS: This ascii block design is best visible in a widescreen monitor, or in HTML page)
+
+=====================================================================================================================================================
+
+	   property 1 = CSC	       property 2 = Degamma	 property 3 = Gamut	     property 4 = palette
+          +------------------+        +-------------------+      +------------------+       +-------------------+  RGB REC 2020 buffer
+YUV       |color space       |        |Linearizion        |      |Gamut mapping     |       |Non-Linearizion    +-------------------+
+REC709--> |conversion        +------->+(Degamma)          +----->+(REC709->REC2020) +-------+(Gamma)            |                   |
+          |(YUV->RGB)        |        |                   |      |                  |       |                   |            +------v---------------+
+          +------------------+        +-------------------+      +------------------+       +-------------------+            |                      |
+                                                                                                                             |                      |
+                                                                                                                             | Blending unit        |
+                                                                                                                             |                      |------> blended output
+RGB REC 2020 buffer (Bypass everything)                                                                                      |                      |
+  +--------------------------------------------------------------------------------------------------------------------->    |                      |
+                                                                                                                             |                      |
+                                                                                                                             +----------------------+
+=====================================================================================================================================================
+
+This is a design proposal of a blending pipeline, using a sequence of plane level DRM properties.
+The description of the block is:
+- Input buffers are two different streams for example
+	- YCBCR buffer in REC709 colorspace
+	- RGB buffer in BT2020 colorspace
+- Aim is to make bending accurate by providing similar input to the blending unit (same in format as well as color space).
+- Every block here represents a plane level DRM property, with specific task to do.
+	- first block is CSC property, which is for conversion from YCBCR->RGB only (This doesnt do gamut mapping)
+	- second block is the property which will linearize the input, a degamma kind of property
+	- third block is a Gamut mapping proprty, which will do a gamut conversion (ex 709->2020)
+	- forth block is a Non-Linearizion block, which will apply back the curve (like Gamma) required
+	- The output of this pipeline is a RGB buffer in REC2020 color space
+	- Any driver can map its HW's plane level color correction capabilities to these properties.
+	- Once blending is done, driver can apply any post blending CRTC level color property, to:
+		- Change output type (ex. changing RGB->YUV using CRTC level CSC property)
+		- Apply a curve on the blended output (using CRTC level gamma/LUT property)
+
+- Important points:
+	- The sequence of the properties has to be fixed (almost in this order), considering the linear data requirement of Gamut mapping
+	- The color space of blending needs to be decided in the userspace, by UI manager, with some policies like (examples):
+		- If any of the buffer is REC2020, all buffers should be converted into 2020, before blending.
+		- Always blend in Higher/Wider color space.
+		- Always blend in RGB.
+
+- Opens:
+	- Is there a need to communicate HW's capabilities to UI manager/userspace ?
-- 
2.7.4

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel

  parent reply	other threads:[~2017-04-24  9:02 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-21  9:51 [PATCH RFC 0/6] drm: Add properties to control YCbCr to RGB conversion Jyri Sarha
2017-04-21  9:51 ` [PATCH RFC 1/6] drm: drm_color_mgmt.h needs struct drm_crtc declaration Jyri Sarha
2017-04-21 11:46   ` Laurent Pinchart
2017-04-21  9:51 ` [PATCH RFC 2/6] drm: Make drm_atomic_replace_property_blob_from_id() more generic Jyri Sarha
2017-04-21 11:47   ` Laurent Pinchart
2017-05-02  8:31     ` Daniel Vetter
2017-04-21  9:51 ` [PATCH RFC 3/6] drm: Plane YCbCr to RGB conversion related properties Jyri Sarha
2017-04-21 11:17   ` Ville Syrjälä
2017-04-21 12:10     ` Laurent Pinchart
2017-04-21 13:08       ` Ville Syrjälä
2017-04-21 12:58     ` Sharma, Shashank
2017-04-21 13:39     ` Jyri Sarha
2017-04-21 13:52       ` Ville Syrjälä
2017-04-21 14:53         ` Brian Starkey
2017-04-21 15:21           ` Ville Syrjälä
2017-04-21 15:34             ` Brian Starkey
2017-04-21 16:49               ` Ville Syrjälä
2017-04-24 12:58                 ` Brian Starkey
2017-04-24  9:02         ` Shashank Sharma [this message]
2017-04-24 13:21         ` Jyri Sarha
2017-04-24 15:13           ` Ville Syrjälä
2017-04-24 15:49             ` Jyri Sarha
2017-04-24 16:55               ` Ville Syrjälä
2017-04-26 12:56                 ` Jyri Sarha
2017-04-26 13:28                   ` Sharma, Shashank
2017-04-26 17:22                   ` Ville Syrjälä
2017-05-02  8:33   ` Daniel Vetter
2017-05-02  9:29     ` Jyri Sarha
2017-04-21  9:51 ` [PATCH RFC 4/6] drm/omap: cleanup color space conversion Jyri Sarha
2017-04-21 11:53   ` Laurent Pinchart
2017-04-21  9:51 ` [PATCH RFC 5/6] drm/omap: csc full range support Jyri Sarha
2017-04-21 11:55   ` Laurent Pinchart
2017-04-21  9:51 ` [PATCH RFC 6/6] drm/omap: Enable ycbcr_to_rgb_properties for omapdrm planes REVISIT Jyri Sarha
2017-04-21 12:53 ` [PATCH RFC 0/6] drm: Add properties to control YCbCr to RGB conversion Sharma, Shashank
2017-04-21 13:50 ` Liviu Dudau

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1493024538-17149-1-git-send-email-shashank.sharma@intel.com \
    --to=shashank.sharma@intel.com \
    --cc=Liviu.Dudau@arm.com \
    --cc=dri-devel@lists.freedesktop.org \
    --cc=intel-gfx@lists.freedesktop.org \
    --cc=jsarha@ti.com \
    --cc=laurent.pinchart@ideasonboard.com \
    --cc=tomi.valkeinen@ti.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox