Summary: | Regression running Second Life viewer on r600 (mipmap generation issue?) | ||
---|---|---|---|
Product: | Mesa | Reporter: | Aidan Thornton <makosoft> |
Component: | Drivers/DRI/R600 | Assignee: | Default DRI bug account <dri-devel> |
Status: | RESOLVED FIXED | QA Contact: | |
Severity: | normal | ||
Priority: | medium | ||
Version: | git | ||
Hardware: | x86-64 (AMD64) | ||
OS: | Linux (All) | ||
Whiteboard: | |||
i915 platform: | i915 features: |
Description
Aidan Thornton
2010-06-02 11:29:48 UTC
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.