Bug 17327

Summary: [915 classic] Mip-maps are corrupted when resizing a window
Product: Mesa Reporter: Chris Lord <chrislord.net>
Component: Drivers/DRI/i915Assignee: Default DRI bug account <dri-devel>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: medium CC: keithp
Version: git   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:
Attachments: Test-case that demonstrates the breakage
Patch to dump the pick buffer to /tmp when receiving unexpected results

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.