Re: [RFC] handling of alpha mode (pre-multiplied/straight) in ARGB modes

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

On Mon, Jan 11, 2016 at 04:07:50PM +0100, Daniel Vetter wrote:
> On Mon, Jan 11, 2016 at 03:18:44PM +0100, Marek Szyprowski wrote:
> > Dear All,
> > 
> > I would like to add support for configuring alpha modes: straight and
> > pre-multiplied for blending to Exynos DRM driver. For those who see those
> > terms for the first time:
> > 1. straight alpha mode means means that all A and RGB values are from full
> > 0.255 range,
> > 2. pre-multiplied alpha mode means that A is from 0..255 range and RGB
> > values are scaled to 0..ALPHA range (where ALPHA is the A value for the
> > given pixel).
> > The pre-multiplied mode is quite common in texture processing.
> > 
> > I did a little research and found that there is no common approach for
> > defining straight or pre-multiplied alpha modes for ARGB framebuffers.
> > 
> > From reading the sources and the register names I found that following
> > drivers use pre-multiplied modes for ARGB framebuffers:
> > radeon (at least for ARGB cursors),
> > amdgpu (cursor),
> > intel (all ARGB planes),
> > rock chip.
> > 
> > On the other hand, there are drm drivers which support ARGB modes and use
> > straight alpha modes:
> > omap,
> > msm.
> > 
> > For the rest of drivers, which might deal with per-pixel alpha, I was not
> > able to determine from the code if the pixel RGB values are interpreted as
> > per-multiplied or straight:
> > atmel_hlcdc,
> > sti,
> > mdp5,
> > shmobile,
> > rcar,
> > vc4,
> > imx.
> 
> Imo in case of doubt/mixed definitions the semantics of the big desktop
> drivers should win. True generic userspace is most likely developed on
> those, everything else should just adjust. And in most cases we can get
> away with that on arm drivers since they tend to ship userspace and kernel
> in lockstep. At least where it really matters.
> 
> > Exynos DRM driver now mixes pre-multiplied and straight modes, depending on
> > the CRTC sub-driver.
> > 
> > While checking the code I found a following comment in
> > drm/i915/intel_display.c in skl_plane_ctl_format() function:
> > /*
> >  * XXX: For ARBG/ABGR formats we default to expecting scanout buffers
> >  * to be already pre-multiplied. We need to add a knob (or a different
> >  * DRM_FORMAT) for user-space to configure that.
> >  */
> > 
> > The question is how to cleanup this ambiguities and let generic userspace to
> > properly use ARGB/ARGB modes with proper blending mode. I came up with the
> > following 3 solutions:
> > 
> > 1. Define new fourcc values for pre-multiplied (or/and straight) alpha
> > modes,
> > 2. Introduce a new framebuffer flag for pre-multiplied or straight alpha (or
> > both),
> > 3. Introduce a new plane property for controlling alpha blending mode.
> > 
> > The first solution has serious compatibility problem, because we can either
> > map existing fourcc to pre-multiplied (to follow radeon/amdgpu, intel and
> > rockchip behavior) or straight mode. Both ways it will break some existing
> > applications. To avoid compatibility problem we would need to add 2 more
> > sets of fourcc and leave existing ARGB modes as 'driver dependent'.
> > 
> > The second solution is probably a bit less intrusive, but it suffers for the
> > similar compatibility problem. To make this feature compatible with existing
> > code, probably 2 flags will be needed: DRM_MODE_FB_ALPHA_FORCE_PREMULTIPLIED
> > and DRM_MODE_FB_ALPHA_FORCE_STRAIGHT. This way when userspace provides no
> > flag, the driver can use its default mode.
> > 
> > Third solution (additional plane property) has been already proposed:
> > https://lkml.org/lkml/2015/6/19/330, however I found no follow-up nor
> > comments. Separate property lets at least drivers to notify userspace about
> > driver's default alpha mode and lets generic application to properly set the
> > requested mode. The only problem is that the alpha mode is not directly
> > configured on the framebuffer object, where in my opinion it should be
> > stored.
> > 
> > Please let me know which approach You like best and which should I take for
> > introducing generic way of configuring alpha mode.
> 
> One idea that was tossed around a few times is to go full generic and
> implement something like glBlendFunc for planes, except that we'd also
> pre-multiplied/straight versions where it makes sense. For drivers that
> can't support pre-multiplied alpha they could simply leave out these
> values from the blend-func property (like we already allow with e.g.
> rotation, when a driver can't do 90/270°).
> 
> Wrt backwards compat a property would work well too: If it's not there
> then userspace should assume old behaviour (which should be pre-multiplied
> really, but might be somewhat broken on some drivers/kernel).
> 
> Damien had some RFC about all this way back, but can't find it right now.

I remembe he said he wanted to work on it, but I don't remember seeing
anything come out of that. I guess he got swallowed by patchwork, or I
just missed the patch.

This mail might include some of my more recent thoughts on this matter
http://lists.freedesktop.org/archives/intel-gfx/2014-April/042956.html

-- 
Ville Syrjälä
Intel OTC
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel