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
next prev 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