[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.
Author: Eric Anholt <firstname.lastname@example.org>
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.
Reviewed-by: Kenneth Graunke <email@example.com>
Reviewed-by: Ian Romanick <firstname.lastname@example.org>
on Jan 24, 2017 at 11:14:30.
(provided by the Example extension).