Bug 17327 - [915 classic] Mip-maps are corrupted when resizing a window
Summary: [915 classic] Mip-maps are corrupted when resizing a window
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i915 (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Default DRI bug account
QA Contact:
Depends on:
Reported: 2008-08-27 08:04 UTC by Chris Lord
Modified: 2009-08-24 12:30 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:

Test-case that demonstrates the breakage (1.26 KB, text/x-csrc)
2008-08-27 08:04 UTC, Chris Lord
Patch to dump the pick buffer to /tmp when receiving unexpected results (3.44 KB, patch)
2008-10-07 03:38 UTC, Chris Lord
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Chris Lord 2008-08-27 08:04:31 UTC
Created attachment 18549 [details]
Test-case that demonstrates the breakage

Unfortunately, I can't be very specific about this bug, but it seems that when the associated X window to a GL context is resized, mip-maps are almost always corrupted.

This does not seem to affect GLUT applications (thus the difficulty I'm having in producing a test case), but it does affect Clutter ( http://clutter-project.org/ ) projects.

Attached is a small, annotated clutter application that demonstrates this breakage. This doesn't happen in Mesa 7.0.
Comment 1 Eric Anholt 2008-10-06 13:36:09 UTC
Works with GEM, fails on classic mode.

clutter did emit a bunch of assertions.  I'd feel more secure if we could get a plain GL testcase.
(./clutter-mipmap:20847): Clutter-CRITICAL **: clutter_id_pool_lookup: assertion `id < id_pool->array->len' failed
Comment 2 Chris Lord 2008-10-07 03:37:56 UTC
I think this assertion is showing up another bug or odd behaviour in the driver (it doesn't happen on ATI or nvidia, and some versions of the Intel driver don't show it). The assertion means that when we draw the pick buffer (to detect what actor the mouse is over), we're getting a colour back from glReadPixels that doesn't correspond to any actor on the stage - i.e. a colour that we didn't draw. Perhaps it could be related to this?

I used to get this assertion, but since updating to git drivers, I can't reproduce it (but I've not updated in the last few weeks, as tracking git X bits and packaging them is a huge pain and I've not been working on things that are critically affected by these bugs).

Attached is a patch (applies against 0.8 branch) that dumps the pick buffer to /tmp when this assertion is fired. This may help to debug that problem; if I can reproduce it on any of my machines, I'll see what I can find out.
Comment 3 Chris Lord 2008-10-07 03:38:53 UTC
Created attachment 19432 [details] [review]
Patch to dump the pick buffer to /tmp when receiving unexpected results
Comment 4 Keith Packard 2008-10-07 07:40:19 UTC
Oh. You're using glReadPixels which is known to be broken at present. We're working on a fix for that.
Comment 5 Chris Lord 2008-10-07 08:42:16 UTC
Just to clarify, glReadPixels is only used for picking, that does not affect this bug (unless using glReadPixels causes corruption in other things?)
Comment 6 Eric Anholt 2008-12-08 14:05:09 UTC
At this point the q3 release has been out for long enough that we're not working on classic mode bugfixes any more.  Just confirmed that the testcase displays correctly still (and the assertion failure also doesn't occur) with the current GEM-based code.
Comment 7 Adam Jackson 2009-08-24 12:30:49 UTC
Mass version move, cvs -> git

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.