[PATCH 6/7] etnaviv: apply non-alpha workaround for reduced masks

[Russell King]

On Tue, Nov 22, 2016 at 01:53:58PM +0100, Lucas Stach wrote:
> Am Dienstag, den 22.11.2016, 12:17 +0000 schrieb Russell King:
> > On Tue, Nov 22, 2016 at 12:44:19PM +0100, Lucas Stach wrote:
> > > If accel_reduce_mask() succeeded in replacing the mask by constant
> > > alpha the source format still needs to be switched to an alpha one
> > > to get correct swizzles. We only want to avoid clobbering the alpha
> > > mode setup done by accel_reduce_mask().
> > 
> > Definitely not.  You're correct that the test order is important, and
> > the test order is intentionally the way it is, so that
> > etnaviv_accel_reduce_mask() works.
> > 
> > The effect that your patch will have is to corrupt all the state which
> > etnaviv_accel_reduce_mask() has computed to effect the combining of the
> > constant A8 mask with the source - overriding its alpha with a constant
> > 255.
> > 
> No. We are only switching the format to the alpha one in
> etnaviv_workaround_nonalpha(). Replacing the alpha channel with constant
> 255 is only done if etnaviv_blend_src_alpha_normal() returns true, which
> isn't the case if etnaviv_accel_reduce_mask() changed the alpha op
> already.

No.

If we have a constant A8 alpha mask, then etnaviv_accel_reduce_mask()
sets the source alpha mode according to whether the source has alpha
or not.

If the source has no alpha, we switch to global source alpha mode,
which means we override whatever alpha was obtained from the source.
This override happens _after_ the buggy hardware - which is the
fetching of the alpha.

If the source has alpha, then we use scaled source alpha mode, so
that the constant alpha scales the source alpha which will be correctly
read by the GPU.

This logic is here to handle exactly the case you are purportedly
trying to fix - it's been tested to work.

If you think otherwise, please supply a test case which fails, so that
I can reproduce it here.

-- 
Russell King