From patchwork Mon Apr 24 09:02:18 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: "Sharma, Shashank" X-Patchwork-Id: 9695875 Return-Path: Received: from mail.wl.linuxfoundation.org (pdx-wl-mail.web.codeaurora.org [172.30.200.125]) by pdx-korg-patchwork.web.codeaurora.org (Postfix) with ESMTP id 1D04D601AE for ; Mon, 24 Apr 2017 08:59:31 +0000 (UTC) Received: from mail.wl.linuxfoundation.org (localhost [127.0.0.1]) by mail.wl.linuxfoundation.org (Postfix) with ESMTP id 0E3E4223C7 for ; Mon, 24 Apr 2017 08:59:31 +0000 (UTC) Received: by mail.wl.linuxfoundation.org (Postfix, from userid 486) id 02EB426530; Mon, 24 Apr 2017 08:59:30 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on pdx-wl-mail.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.2 required=2.0 tests=BAYES_00, RCVD_IN_DNSWL_MED autolearn=unavailable version=3.3.1 Received: from gabe.freedesktop.org (gabe.freedesktop.org [131.252.210.177]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.wl.linuxfoundation.org (Postfix) with ESMTPS id 80247223C7 for ; Mon, 24 Apr 2017 08:59:30 +0000 (UTC) Received: from gabe.freedesktop.org (localhost [127.0.0.1]) by gabe.freedesktop.org (Postfix) with ESMTP id 033AD6E1C4; Mon, 24 Apr 2017 08:59:28 +0000 (UTC) X-Original-To: dri-devel@lists.freedesktop.org Delivered-To: dri-devel@lists.freedesktop.org Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by gabe.freedesktop.org (Postfix) with ESMTPS id 6ACD76E1B7; Mon, 24 Apr 2017 08:59:26 +0000 (UTC) Received: from orsmga005.jf.intel.com ([10.7.209.41]) by fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 24 Apr 2017 01:59:25 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.37,243,1488873600"; d="scan'208";a="91417938" Received: from shashanks-linuxbox.iind.intel.com ([10.223.26.29]) by orsmga005.jf.intel.com with ESMTP; 24 Apr 2017 01:59:20 -0700 From: Shashank Sharma To: dri-devel@lists.freedesktop.org, intel-gfx@lists.freedesktop.org Subject: [PATCH] RFC: Design: DRM: Blending pipeline using DRM plane properties Date: Mon, 24 Apr 2017 14:32:18 +0530 Message-Id: <1493024538-17149-1-git-send-email-shashank.sharma@intel.com> X-Mailer: git-send-email 2.7.4 In-Reply-To: <20170421135203.GN30290@intel.com> References: <20170421135203.GN30290@intel.com> Cc: Liviu.Dudau@arm.com, jsarha@ti.com, tomi.valkeinen@ti.com, laurent.pinchart@ideasonboard.com X-BeenThere: dri-devel@lists.freedesktop.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: Direct Rendering Infrastructure - Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , MIME-Version: 1.0 Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" X-Virus-Scanned: ClamAV using ClamSMTP 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 --- 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 ?