[Note: I discovered this bug while testing with the i965 driver, but it's certainly possible that it's actually a general bug in mesa.] The OpenGL specification indicates (indirectly) that the glCopyPixels operation should generate fragments. It says: The groups of elements so obtained are then written to the framebuffer just as if DrawPixels had been given width and height, beginning with final conversion of elements. [OpenGL 3.0 § 4.3.3] And for DrawPixels it says: Rectangles of color, depth, and certain other values may be converted to fragments using the DrawPixels command. [OpenGL 3.0 § 3.7] I recently added the occlusion_query_meta_fragments test to piglit to ensure this behavior. It executed a glCopyPixels operation within an occlusion query, expecting a result of the same number as pixels in the copied region. This test currently fails, (the occlusion query reports 0 fragments rather than the expected 4 fragments for a 2x2 region copied). Note that the test performs a similar query around a glDrawPixels operation and that query does provide the expected result of 4. -Carl
commit 7a74808d7856e9749895afeb14125c463b2f4fd0 Author: Eric Anholt <eric@anholt.net> Date: Mon May 6 15:24:12 2013 -0700 i965: Count occlusion query samples for CopyPixels using the 2D engine. We accidentally "fixed" the piglit test for this when introducing Y tiling, since this path stopped being executed. In reenabling this path for Y tiling, we ended up regressing it again, so just fix it. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=59439 Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
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.