Bug 59439 - glCopyPixels generates no fragments (occlusion_query_meta_fragments test fails)
Summary: glCopyPixels generates no fragments (occlusion_query_meta_fragments test fails)
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Ian Romanick
QA Contact:
Depends on:
Reported: 2013-01-15 21:49 UTC by Carl Worth
Modified: 2013-05-21 23:10 UTC (History)
0 users

See Also:
i915 platform:
i915 features:


Note You need to log in before you can comment on or make changes to this bug.
Description Carl Worth 2013-01-15 21:49:30 UTC
[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.

Comment 1 Eric Anholt 2013-05-21 23:10:36 UTC
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.