From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934554AbdBQPRV (ORCPT ); Fri, 17 Feb 2017 10:17:21 -0500 Received: from mga11.intel.com ([192.55.52.93]:33115 "EHLO mga11.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S934159AbdBQPRU (ORCPT ); Fri, 17 Feb 2017 10:17:20 -0500 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.35,172,1484035200"; d="scan'208";a="1130325698" Date: Fri, 17 Feb 2017 17:16:56 +0200 From: Ville =?iso-8859-1?Q?Syrj=E4l=E4?= To: Lionel Landwerlin Cc: Brian Starkey , Daniel Stone , Daniel Vetter , dri-devel , Linux Kernel Mailing List , Jani Nikula , Sean Paul Subject: Re: [PATCH v2] drm/color: Document CTM eqations Message-ID: <20170217151656.GV31595@intel.com> References: <20170131151828.GU31595@intel.com> <20170131153928.GB11506@e106950-lin.cambridge.arm.com> <20170131172215.GV31595@intel.com> <20170215113959.GT31595@intel.com> <20170217135451.GA18487@e106950-lin.cambridge.arm.com> <20170217145643.GU31595@intel.com> <492eec8f-a45e-190c-469f-018c82053f7f@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <492eec8f-a45e-190c-469f-018c82053f7f@intel.com> User-Agent: Mutt/1.5.24 (2015-08-30) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Feb 17, 2017 at 03:05:28PM +0000, Lionel Landwerlin wrote: > On 17/02/17 14:56, Ville Syrjälä wrote: > > On Fri, Feb 17, 2017 at 02:42:26PM +0000, Lionel Landwerlin wrote: > >> On 17/02/17 13:54, Brian Starkey wrote: > >>> What's the verdict? We've got [1] which is about to become another > >>> (driver) implementation - better to change before that merges than > >>> after I guess. > >>> > >>> -Brian > >>> > >>> [1] https://lkml.org/lkml/2017/2/13/304 > >>> > >>> On Wed, Feb 15, 2017 at 11:56:55AM +0000, Daniel Stone wrote: > >>>> Hi, > >>>> > >>>> On 15 February 2017 at 11:39, Ville Syrjälä > >>>> wrote: > >>>>> On Tue, Jan 31, 2017 at 06:46:39PM +0100, Daniel Vetter wrote: > >>>>>> On Tue, Jan 31, 2017 at 6:22 PM, Ville Syrjälä > >>>>>> wrote: > >>>>>>> Hmm. Two's complement is what I was thinking it is. Which shows that > >>>>>>> I never managed to read the code in any detail. Definitely needs to > >>>>>>> be documented properly. > >>>>>> That sounds supremely backwards. I guess we can't fix this anymore? > >>>>> I have no idea. Anyone else? > >>>> I don't know of any implementation using this; maybe closed Intel > >>>> Android stuff? Certainly GitHub showed no-one using it, and neither X > >>>> nor Weston/Mutter are using it yet. > >>>> > >>>> Cheers, > >>>> Daniel > >> If we're talking fixed point reprsentation, ChromeOS is using this : > >> > >> https://cs.chromium.org/chromium/src/ui/ozone/platform/drm/gpu/drm_device.cc?q=DrmDevice&l=209 > > So it's already using the sign+magnitude stuff. Which presumably > > means we can't change it to two's complement anymore :( Maybe we add a > > CTM2 property ;) > > > > Using sign+magnitude definitely looks rather inefficient since there's > > a branch inside the loop. With two's complement you wouldn't need that > > thing slowing you down. > > > If you're seriously considering that, you might also want to bump struct > drm_color_lut to use 32bits fields. Which is what I thought we had already agreed to do when we started planning this color management stuff. But I guess that plan got somehow scrapped after I was no longer part of the discussions. > It seems some people have concerned about HDR. HDR is definitely something I'd like to have a look at. -- Ville Syrjälä Intel OTC