From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: [PATCH 3/4] drm/i915: Enabling pre-multiplied alpha drm property Date: Thu, 20 Mar 2014 14:51:20 +0100 Message-ID: <20140320135120.GN30571@phenom.ffwll.local> References: <1394266879-20522-1-git-send-email-sagar.a.kamble@intel.com> <1394266879-20522-4-git-send-email-sagar.a.kamble@intel.com> <20140319151008.GB27717@strange.amr.corp.intel.com> <1395309582.2740.9.camel@sagar-desktop> <20140320113818.GL6912@strange.amr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-ee0-f45.google.com (mail-ee0-f45.google.com [74.125.83.45]) by gabe.freedesktop.org (Postfix) with ESMTP id 1B60C6E094 for ; Thu, 20 Mar 2014 06:51:24 -0700 (PDT) Received: by mail-ee0-f45.google.com with SMTP id d17so682988eek.18 for ; Thu, 20 Mar 2014 06:51:24 -0700 (PDT) Content-Disposition: inline In-Reply-To: <20140320113818.GL6912@strange.amr.corp.intel.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Damien Lespiau Cc: "Srinivas, Vidya" , David Airlie , Daniel Vetter , intel-gfx@lists.freedesktop.org, Sagar Arun Kamble List-Id: intel-gfx@lists.freedesktop.org On Thu, Mar 20, 2014 at 11:38:18AM +0000, Damien Lespiau wrote: > On Thu, Mar 20, 2014 at 03:29:42PM +0530, Sagar Arun Kamble wrote: > > Hi Damien, > > > > On Wed, 2014-03-19 at 15:10 +0000, Damien Lespiau wrote: > > > On Sat, Mar 08, 2014 at 01:51:18PM +0530, sagar.a.kamble@intel.com wrote: > > > > From: Sagar Kamble > > > > > > > > This patch enables property for changin the pixel format > > > > of plane to enable/disable pre-multiplied alpha format. > > > > Client has to set BIT(DRM_BLEND_PREMULTIPLIED_ALPHA) | 0x0/0x1 > > > > to disable/enable pre-multiplied alpha format. > > > > > > > > Cc: Daniel Vetter > > > > Cc: Jani Nikula > > > > Cc: David Airlie > > > > Signed-off-by: Srinivas, Vidya > > > > Signed-off-by: Sagar Kamble > > > > > > Huum, the alpha being premultiplied or not seems to be a property of the > > > framebuffer to me, not of the plane. It seems to me that we should > > > define alternative premultiplied DRM_FORMATs and make the sprite planes > > > advertise support for premultiplied fbs in the format list when the > > > hardware indeed supports them. > > This is what i think of usage of this property: > > > > Composer/user mode starts using plane with XRGB format and then it wants > > to add transparency to the plane. So it will set the format to ARGB > > format and provide buffer for that plane that will have pixels with > > pre-multiplied alpha (a*r, a*g, a*b, a). > > This can be done with primary plane(CRTC) as well, however I have > > not added this as CRTC property since CRTCs are going to be drm_plane > > soon. > > > > Will this kind of interface for usermode to toggle the pixel format's > > alpha be useful? > > I don't think so, nop. > > Besides being a convoluted apocalyptic scenario, one cannot simply > change the format of the FB without re-adding it with AddFB2(). > > There's a usage model for the compositor to add a plane-global alpha to > a plane (fades the client provided render target) and that's indeed a > plane property. > > As far I as can tell, the premultiplied alpha format ban be sued support > scanning out OpenGL blended fbs. I'm not sure I follow this discussion completely, but in my opinion may _never_ change the pixel format of a drm framebuffer object. Think of a drm framebuffer as a view of the underlying object(s) with strides, pixel format, dimensions and other stuff specified. If you need a different view, simply create a new drm framebuffer object. Note that drm framebuffer objects are never shared (as opposed to the underlying gem backing storage which can be shared with flink or dma-buf), so this doesn't need any synchronization outside of the compositor itself. I don't really have a decent opinion on the pre-multiplied vs non-premultiplied ARGB formats issue at hand. In case of doubt I think we should follow what gl does. But I have no clue how that's handled in gl ;-) And maybe I'm completely missing the point here ;-) -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch