Bug 96943 - [gallium] glCopyPixels is affected by enabled texture state
Summary: [gallium] glCopyPixels is affected by enabled texture state
Status: RESOLVED MOVED
Alias: None
Product: Mesa
Classification: Unclassified
Component: Mesa core (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: mesa-dev
QA Contact: mesa-dev
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-07-15 17:12 UTC by Ilia Mirkin
Modified: 2019-09-18 20:25 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ilia Mirkin 2016-07-15 17:12:28 UTC
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.]
Comment 1 Roland Scheidegger 2016-07-15 18:09:44 UTC
(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.
Comment 2 Ilia Mirkin 2016-07-15 18:20:32 UTC
(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".)
Comment 3 Roland Scheidegger 2016-07-15 18:48:10 UTC
(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...
Comment 4 GitLab Migration User 2019-09-18 20:25:27 UTC
-- 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.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.