Re: [PATCH 3/4] drm/i915: Enabling pre-multiplied alpha drm property

[Daniel Vetter <daniel@ffwll.ch>]

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 <sagar.a.kamble@intel.com>
> > > > 
> > > > 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 <daniel.vetter@ffwll.ch>
> > > > Cc: Jani Nikula <jani.nikula@linux.intel.com>
> > > > Cc: David Airlie <airlied@linux.ie>
> > > > Signed-off-by: Srinivas, Vidya <vidya.srinivas@intel.com>
> > > > Signed-off-by: Sagar Kamble <sagar.a.kamble@intel.com>
> > > 
> > > 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