Hello,
On 2016-01-11 16:22, Ville Syrjälä wrote:
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
I also found this patch: http://patchwork.freedesktop.org/patch/23000/
However I still don't get a complete picture how it would work. If I got it
right, the real blending function is defined by a pair of the values
from the
proposed enums, where one applies to the background (the blending result of
deeper planes) and the second applies to the processed plane. Some
combinations of the proposed enums doesn't make much sense (and especially
changing the constant zero and one means simply changing the order of the
planes), so I wonder if it might be easier to simply create an enum with
all sane values for blending and document it really well? This way drivers
will simply initialize only the supported blending modes.
I assume that this way also the separate enums can be defined for straight
and pre-multiplied alpha blending modes.
The other problem mentioned somewhere is where to attach the blending
property. Some parameters (like straight/pre-multiplied or enabling global
alpha) can be set on per-plane basis, but I can imagine that some parameters
are global for the given crtc.
The another item related to blending is color keying. It was not mentioned
in the above proposal at all, but some hardware can do that. I've noticed
that some hardware also is able to do color keying only for exact RGB(A)
values and some have separate registers to set RGB tolerance. This also
need to be standardized somehow.
Best regards
--
Marek Szyprowski, PhD
Samsung R&D Institute Poland
_______________________________________________
dri-devel mailing list
dri-devel@xxxxxxxxxxxxxxxxxxxxx
http://lists.freedesktop.org/mailman/listinfo/dri-devel
