Re: [Intel-gfx] [PATCH 0/4] Adding support for plane alpha/color blending through drm property
On Fri, Mar 21, 2014 at 07:23:31PM +, 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 +, Damien Lespiau wrote:
> > > On Thu, Mar 20, 2014 at 02:11:40PM +, 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 multip
Re: [Intel-gfx] [PATCH 0/4] Adding support for plane alpha/color blending through drm property
On Tue, Mar 25, 2014 at 11:51:57AM +0100, Daniel Vetter wrote: > On Tue, Mar 25, 2014 at 03:33:42PM +0530, Sagar Arun Kamble wrote: > > Hi Damien, > > > > Could you please clarify following queries. > > He did, in a reply to your mail ... In case you cannot find it: http://lists.freedesktop.org/archives/intel-gfx/2014-March/042136.html -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/4] Adding support for plane alpha/color blending through drm property
On Tue, Mar 25, 2014 at 03:33:42PM +0530, Sagar Arun Kamble wrote: > Hi Damien, > > Could you please clarify following queries. He did, in a reply to your mail ... -Daniel > > Thanks, > Sagar > On Fri, 2014-03-21 at 19:06 +0530, Sagar Arun Kamble wrote: > > Hi Damien, > > > > On Thu, 2014-03-20 at 14:45 +, Damien Lespiau wrote: > > > On Thu, Mar 20, 2014 at 02:11:40PM +, 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? > > > > 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 > > > > Kindly clarify. > > > > thanks, > > Sagar > > > > > > > ___ > Intel-gfx mailing list > Intel-gfx@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/intel-gfx -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/4] Adding support for plane alpha/color blending through drm property
Hi Damien, Could you please clarify following queries. Thanks, Sagar On Fri, 2014-03-21 at 19:06 +0530, Sagar Arun Kamble wrote: > Hi Damien, > > On Thu, 2014-03-20 at 14:45 +, Damien Lespiau wrote: > > On Thu, Mar 20, 2014 at 02:11:40PM +, 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? > > 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 > > Kindly clarify. > > thanks, > Sagar > > ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/4] Adding support for plane alpha/color blending through drm property
On Fri, Mar 21, 2014 at 07:06:46PM +0530, Sagar Arun Kamble wrote: > Hi Damien, > > On Thu, 2014-03-20 at 14:45 +, Damien Lespiau wrote: > > On Thu, Mar 20, 2014 at 02:11:40PM +, 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 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). I would just proceed with a premultipled FB format and the alpha plane property. Let's wait until Ville returns, I may be totally not getting what he meant. -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/4] Adding support for plane alpha/color blending through drm property
Hi Damien, On Thu, 2014-03-20 at 14:45 +, Damien Lespiau wrote: > On Thu, Mar 20, 2014 at 02:11:40PM +, 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? 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 Kindly clarify. thanks, Sagar ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/4] Adding support for plane alpha/color blending through drm property
On Thu, Mar 20, 2014 at 02:11:40PM +, 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) -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 0/4] Adding support for plane alpha/color blending through drm property
On Sat, Mar 08, 2014 at 01:51:15PM +0530, sagar.a.kam...@intel.com wrote: > From: Sagar Kamble > > This patch series introduces drm property modelled after glBlendFuc function. > For i915 > constant alpha is exposed through this property to start with. Additional new > property > value for controlling pre-multiplied alpha is added. > i-g-t test case is to be added. > > These patches are based on following patches which are already under > review/reviewed: > > 4ae74f3 Documentation: drm: describing drm properties exposed by various > drivers > 134bdfe Propagate the error from intel_update_plane() up through > intel_plane_restore() to the caller. > a6ad21c Make drm_property_create_bitmask() a bit more generic by allowing the > caller to specify which bits are in fact supported. > > Sagar Kamble (4): > drm: Added plane alpha and color blending property > drm/i915: Enabling constant alpha drm property > drm/i915: Enabling pre-multiplied alpha drm property > Documentation: drm: describing plane alpha and color blending property I'm not sure I follow what's being done with the GL blending equation here. If we want to support a global alpha on the source plane (ie the plane that is going to be blended into the "render target", what's already there), the blending equation looks like: (source is non-premultiplied, note the use of glBlendFuncSeparate()) RGB = ADD(SRC_COLOR*SRC_ALPHA, DST_COLOR*ONE_MINUS_SRC_ALPHA) A = ADD(SRC_COLOR, DST_COLOR*ONE_MINUS_SRC_ALPHA) (source is premultiplied) RGBA = ADD(SRC_COLOR*SRC_ALPHA, DST_COLOR*ONE_MINUS_SRC_ALPHA) The gl blending stuff doesn't know anything about the premultiplied nature of the incoming source color, it has to be programmed accordingly. -- Damien ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] [PATCH 0/4] Adding support for plane alpha/color blending through drm property
From: Sagar Kamble This patch series introduces drm property modelled after glBlendFuc function. For i915 constant alpha is exposed through this property to start with. Additional new property value for controlling pre-multiplied alpha is added. i-g-t test case is to be added. These patches are based on following patches which are already under review/reviewed: 4ae74f3 Documentation: drm: describing drm properties exposed by various drivers 134bdfe Propagate the error from intel_update_plane() up through intel_plane_restore() to the caller. a6ad21c Make drm_property_create_bitmask() a bit more generic by allowing the caller to specify which bits are in fact supported. Sagar Kamble (4): drm: Added plane alpha and color blending property drm/i915: Enabling constant alpha drm property drm/i915: Enabling pre-multiplied alpha drm property Documentation: drm: describing plane alpha and color blending property Documentation/DocBook/drm.tmpl | 13 +++- drivers/gpu/drm/drm_crtc.c | 33 + drivers/gpu/drm/i915/i915_dma.c | 11 ++- drivers/gpu/drm/i915/i915_drv.h | 1 + drivers/gpu/drm/i915/i915_reg.h | 2 + drivers/gpu/drm/i915/intel_drv.h| 8 +++ drivers/gpu/drm/i915/intel_sprite.c | 132 +++- include/drm/drm_crtc.h | 25 +++ 8 files changed, 222 insertions(+), 3 deletions(-) -- 1.8.5 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
