[Mesa-dev] [PATCH] i965: Avoid blending with destination alpha when RB format has no alpha bits

[Carl Worth]

Carl Worth <cworth at cworth.org> writes:
> This commit fixes one portion of the following es3conform test:
>
> 	rgb8_rgba8_rgb
>
> (The test still fails due to a similar problem when copying from the
> renderbuffer to a texture.)

I was wrong on this second point. My commit actually does make the test
pass. (I had actually introduced a bug into a standalone near-copy of
the test and that was triggering the failure.)

So, I'll still write that piglit test I promised to demonstrate the bug,
and then, with review, this can be pushed and that will be one more es3
conformance result passed.

-Carl

PS. This test exercises RGB-format renderbuffer targets in 3 ways:

  1. Using glReadPixels and verifying that the resulting alpha channel
     is 1.0 everywhere.

  2. Using DST_ALPHA blending and ensuring that all blending occurred as
     if the original destination alpha is 1.0 everywhere.

  3. Using glCopyTexImage to a texture, and then drawing with that
     texture and ensuring that alpha is 1.0 everywhere.

For (1), I've found the code in core mesa that smashes result alpha values
to 1.0.

For (2), my commit above fixes the bug in the Intel driver.

For (3), the particular code in this test case appears to be going
through a slow path (_mesa_meta_CopyTexSubImage) that calls into the
driver's ReadPixels and then TexSubImage implementation. So this is
effectively reduced to the same testing as in (1). But I did at least
read the code in the fast path (intel_copy_texsubimage) which appears to
be aware of this case:

	   /* Converting XRGB8888 to ARGB8888 requires setting the alpha
	   bits to 1.0 */

So I'm comfortable that there aren't a lot of obvious, related bugs in
this area.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/mesa-dev/attachments/20130111/bb128afa/attachment.pgp>