Carl Worth <cwo...@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.
pgpRMntobihMj.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
