<html> <head> <base href="https://bugs.freedesktop.org/"> </head> <body> <div> <a class="bz_bug_link bz_status_NEW " title="NEW - [OpenGL CTS] KHR-GL45.transform_feedback.draw_xfb_test fails" href="https://bugs.freedesktop.org/show_bug.cgi?id=102611#c5">Comment # 5</a> on <a class="bz_bug_link bz_status_NEW " title="NEW - [OpenGL CTS] KHR-GL45.transform_feedback.draw_xfb_test fails" href="https://bugs.freedesktop.org/show_bug.cgi?id=102611">bug 102611</a> from <a class="email" href="mailto:kenneth@whitecape.org" title="Kenneth Graunke <kenneth@whitecape.org>"> Kenneth Graunke</a> <pre>Jason and I figured this one out on #intel-3d tonight. 1. We emit the SURFACE_STATE for the renderbuffer. It has no auxiliary surface. 2. We fast clear the renderbuffer, which causes a delayed CCS_D buffer allocation. 3. The next use of the renderbuffer needs a new SURFACE_STATE because it's gained an auxiliary surface. In the broken driver, we fail to notice this and reuse the old SURFACE_STATE. Not every BLORP operation needs to emit new surface state. But, when we change auxiliary state (which usually involves a BLORP operation), we do need to. I'm not even sure every change needs to trigger an update, maybe just transitions to/from AUX_USAGE_NONE... Jason suggested renaming BRW_NEW_FAST_CLEAR_COLOR to BRW_NEW_AUX_STATE, and flagging it in more cases. I think this is a good idea, we'll just need to figure out which spots need to trigger it...</pre> </div> <hr> You are receiving this mail because: <ul> <li>You are the assignee for the bug.</li> <li>You are the QA Contact for the bug.</li> </ul> </body> </html>