Bug 96943

(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.

(In reply to Roland Scheidegger from comment #1)
> 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).

OK, so in that case, any time that a texture unit is enabled, we should be falling back to the drawpixels-style shader? (The multiply, btw, is coming from the texture combine logic, which defaults to "combine" aka "multiply".)

(In reply to Ilia Mirkin from comment #2)
> (In reply to Roland Scheidegger from comment #1)
> > 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).
> 
> OK, so in that case, any time that a texture unit is enabled, we should be
> falling back to the drawpixels-style shader? (The multiply, btw, is coming
> from the texture combine logic, which defaults to "combine" aka "multiply".)

Technically I think yes. I don't know if the results are actually really correct, though in any case (is it using the current tex coord etc.). And just like this piglit test, I don't think any app ever expects this behavior - most likely if they do this it's an app bug... So might just want to fix the piglit test and pretend it's undefined behavior...

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/mesa/mesa/issues/1005.