Re: [PATCH 0/4] Adding support for plane alpha/color blending through drm property

["Ville Syrjälä" <ville.syrjala@linux.intel.com>]

On Fri, Mar 21, 2014 at 07:23:31PM +0000, Damien Lespiau wrote:
> On Fri, Mar 21, 2014 at 07:06:46PM +0530, Sagar Arun Kamble wrote:
> > Hi Damien,
> > 
> > On Thu, 2014-03-20 at 14:45 +0000, Damien Lespiau wrote:
> > > On Thu, Mar 20, 2014 at 02:11:40PM +0000, Damien Lespiau wrote:
> > > > (source is premultiplied)
> > > > 
> > > > RGBA = ADD(SRC_COLOR*SRC_ALPHA, DST_COLOR*ONE_MINUS_SRC_ALPHA)
> > > 
> > > Grr, copy/paste error. If the source is already premultiplied:
> > > 
> > > RGBA = ADD(SRC_COLOR, DST_COLOR*ONE_MINUS_SRC_ALPHA)
> > > 
> > 
> > 1. Currently there is no interface to advertise the DRM_FORMATS plane
> > supportes to user mode? Should we add new IOCTL for that and include
> > pre-multiplied alpha formats while advertising? Or am I missing any such
> > API already available?
> 
> There's a 'formats' array in drmModePlane.
> 
> > 2. About constant alpha property - when we program constant alpha
> > register will hardware be able to take care of the blending as per
> > equations you have specified for non-premultiplied-alpha and
> > premultiplied-alpha cases or we have to do any additional setting?
> > Confusion is because of two combinations:
> > a. pre-multiplied alpha+constant alpha
> > b. non-pre-multiplied alpha+constant alpha
> 
> The first part of the question should be in the spec. I really do expect
> the hw to work correctly with any combination of (premul, non-premult) x
> (plane alpha, no plane alpha)
> 
> To be more clear: I don't think the glBlendFunc constants can represent
> everything we want:
> 
> - It'd need to differentiate what we want do to between RGB and A (the
>   same reason glBlendFuncSeparate was introduced).

We won't be writing out the alpha anywhere so I'm thinking we don't need
to worry about it.

> 
> - We can't represent blending of an unpremultied fb with a plane-global
>   alpha with just the GL blending equation as it needs two
>   multiplications (so in GL, you would do one of them in the fragment
>   shader).

If I'm interpreting the docs correctly these are the kind of blend equations
we will have soonish:

Sc = Sc
Dc = Sc * Ca + (1-Ca) * Dc

Sc = Sc
Dc = Sc * 1 + (1-Sa) * Dc

premultiplied?
 0: Sc = Sc * Sa
 1: Sc = Sc
Dc = Sc * Sa*Ca + (1-Sa*Ca) * Dc

premultiplied?
 0: Sc = Sc * Sa
 1: Sc = Sc
Dc = Sc * 1 + (1-Sa) * Dc


For reference OMAP36xx was something like this I think:
premultiplied?
 0: Sc = Sc * Sa
 1: Sc = Sc
Dc = Sc * Ca + (1-Sa*Ca) * Dc

and OMAP34xx was something like this:
Sc = Sc
Dc = Sc * Sa*Ca + (1-Sa*Ca) * Dc


So we have src factors of:
1, Ca, Sa*Ca

and dst factors of:
0, 1-Ca, 1-Sa, 1-Sa*Ca

If we add the missing Sa src factor we have a fairly sensible looking
set. Obviously the constant alpha related factors aren't part of GL,
but I don't think we need to worry about that, we're not implementing
GL here after all, just something that resembles it a bit to make it
easier for people to grasp it.

So to make stuff easier for userspace to figure out what we actually
support, I'm thinking it could be just an enum property with the values
being something like '(dstf << 32) | (srcf << 0)' with the factors
defined something like so:

enum {
 ZERO,
 ONE,
 SRC_ALPHA,
 ONE_MINUS_SRC_ALPHA,
 CONST_ALPHA,
 ONE_MINUS_CONST_ALPHA,
 SRC_CONST_ALPHA,
 ONE_MINUS_SRC_CONST_ALPHA,
};

If it's an enum then the user can just pick out one of the
supported blend equations.

> I would just proceed with a premultipled FB format and the alpha plane
> property.

I'm not very enthusiastic about adding the pre-multiplied info to
the FB. That means adding new versions of all the alpha formats we
already have. I almost regret making the A vs. X distinction already.
Might have been neater to leave it entirely up to the blending
properties to figure out whether there's alpha or not.

The one not so annoying option would be to snatch one of the remaining
high bits and use that to indicate premult or not. But we still need to
figure out whether we make the already existing formats be the
premultiplied or non-premultiplied ones. That could have some implication
for user space as we probably can't radically change which formats we
accept to keep existing userspace functional.

So the other option is to not think of it as a property of the
framebuffer, but rather think of it in terms of what operations the
hardware will perform during blending. That way we could just add a flag
which says "yes please, premultiply the data for me".

One thing I didn't much think about is whether we need per-plane blend
functions. That would be the more flexible option, but at least the
current hardware doesn't seem to allow such flexibility. I guess being
future proof shouldn't hurt. We do have the option of per-plane
premultiplication at least. Hmm, actually I have to take that back as
the first two example functions I listed can appear simultaneosly
AFAICS. So this does make things a bit more complicated for userspace
as it can't freely pick blend functions when dealing with multiple
planes. Oh and also for OMAPs the bottom plane wouldn't be blended with
the background AFAICS, so it would always have a blend function of
ONE,ZERO.

OK, so that's my thoughts on the matter. Pardon me if I repeated some
nonsense that has already been shot down. I didn't have time to look at
the actual patches yet.

-- 
Ville Syrjälä
Intel OTC