<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - [gallium] glCopyPixels is affected by enabled texture state" href="https://bugs.freedesktop.org/show_bug.cgi?id=96943#c1">Comment # 1</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - [gallium] glCopyPixels is affected by enabled texture state" href="https://bugs.freedesktop.org/show_bug.cgi?id=96943">bug 96943</a> from <a class="email" href="mailto:sroland@vmware.com" title="Roland Scheidegger <sroland@vmware.com>"> Roland Scheidegger</a> <pre>(In reply to Ilia Mirkin from <a href="show_bug.cgi?id=96943#c0">comment #0</a>) > 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.</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>