lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Fri, 17 Feb 2017 15:05:28 +0000 From: Lionel Landwerlin <lionel.g.landwerlin@...el.com> To: Ville Syrjälä <ville.syrjala@...ux.intel.com> Cc: Brian Starkey <brian.starkey@....com>, Daniel Stone <daniel@...ishbar.org>, Daniel Vetter <daniel.vetter@...ll.ch>, dri-devel <dri-devel@...ts.freedesktop.org>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Jani Nikula <jani.nikula@...ux.intel.com>, Sean Paul <seanpaul@...omium.org> Subject: Re: [PATCH v2] drm/color: Document CTM eqations 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ä >>>> <ville.syrjala@...ux.intel.com> 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ä >>>>>> <ville.syrjala@...ux.intel.com> 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. It seems some people have concerned about HDR.
Powered by blists - more mailing lists