<html>
    <head>
      <base href="https://bugs.freedesktop.org/">
    </head>
    <body>
      <p>
        <div>
            <b><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#c2">Comment # 2</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 <span class="vcard"><a class="email" href="mailto:imirkin@alum.mit.edu" title="Ilia Mirkin <imirkin@alum.mit.edu>"> <span class="fn">Ilia Mirkin</span></a>
</span></b>
        <pre>(In reply to Roland Scheidegger from <a href="show_bug.cgi?id=96943#c1">comment #1</a>)
<span class="quote">> 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).</span >

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".)</pre>
        </div>
      </p>


      <hr>
      <span>You are receiving this mail because:</span>

      <ul>
          <li>You are the QA Contact for the bug.</li>
          <li>You are the assignee for the bug.</li>
      </ul>
    </body>
</html>