[Mesa-dev] [Bug 96943] [gallium] glCopyPixels is affected by enabled texture state

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Fri Jul 15 18:09:44 UTC 2016


--- Comment #1 from Roland Scheidegger <sroland at vmware.com> ---
(In reply to Ilia Mirkin from comment #0)
> The recently rewritten copy-pixels test has exposed some failures in
> st/mesa. When there's an overlapping copy (among other conditions), the
> operation becomes a fb read + draw of that texture with the current fragment
> shader modified in the same way as glDrawPixels does it. (So this problem
> might extend itself to glDrawPixels as well).
> Doing a glDisable(GL_TEXTURE_2D) before the glCopyPixels() call in the
> piglit fixes the issue. Effectively that texture is being multiplied with
> the copied data, whereas from what I can tell, it shouldn't be. I think the
> multiplication comes from the ff-generated shader.
> [An alternative is that the piglit test and i965 are wrong and what gallium
> is doing is correct. I don't think that's the case, since the only
> disagreement is on the overlapped copy.]

The piglit test is probably wrong (I didn't really look), at least different
results based on enabled texturing don't surprise me. This is one of the more
weird "features" of glCopyPixels(), glDrawPixels() and friends.
>From the respective man pages:
"Texture mapping, fog, and all the fragment operations are applied before the
fragments are written to the frame buffer." So if you don't disable texturing,
you'll get texturing on top of your copied pixels (which just represent the
primary color), in whatever way the shader specified (albeit the texture coords
should be constant IIRC).

Near certainly this actually isn't what an app wants to do... And yes I'd be
very surprised if mesa (or any other implementation) actually gets it right all
the time.

You are receiving this mail because:
You are the assignee for the bug.
You are the QA Contact for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/mesa-dev/attachments/20160715/ddeae2e9/attachment.html>

More information about the mesa-dev mailing list