There's a regression in recent git master when running the Second Life viewer on the r600 driver. Objects flash in and out of existence continuously, making Second Life unusable. git bisect points to the commit 055750fafba58fd2ee0f5611b566a71ab0f22984 "Enable hardware mipmap generation for radeon" on the 24th of May, which is plausible since Second Life generates all mipmaps at runtime. I'm using a 2600XT card, Linux 2.6.34, latest libdrm master, and the latest unofficial Imprudence client release (since the official client isn't available in an x86_64 version).
This is probably a dupe of bug 28284
Well, I can confirm that the patch Will Dyson attached to bug 28284 does *not* fix this issue for me. Reverting 055750fafba58fd2ee0f5611b566a71ab0f22984, on the other hand, does seem to. Also, the commit in question smells somewhat fishy: as far as I can tell, if anything it *disables* hardware mipmap generation and forces the use of the software path.
Small additional detail: the mipmaps themselves appear to be generated fine as far as I can tell, and everything works so long as no mipmap generation is happening. However, when a mipmap is generated the next frame rendered by the viewer reliably fails to render a lot of the in-world objects. In fact, whilst textures are being loaded rapidly enough that at least one mipmap is generated per frame, the same affected objects are consistently not rendered on every frame. It appears that hardware mipmap generation and rendering are interacting badly somehow. Given that Second Life relies heavily on streaming textures, this is enough to make it unusable. (Oh, and the patch pointed to by git bisect does indeed force hardware mipmap generation rather than software as it claims).
Note: classic r600 driver has been abandoned. Please use r600g (gallium driver) instead. Is this still an issue with a newer driver/kernel?
Nope, doesn't affect r600g and I don't think it ever actually did (though I wasn't using it at the time because it had - and still has - other unrelated rendering issues that're harder to work around). Guess this probably wants closing?
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.