| Summary: | [OpenGL CTS] KHR-GL45.transform_feedback.draw_xfb_test fails | ||
|---|---|---|---|
| Product: | Mesa | Reporter: | Juan A. Suarez <jasuarez> |
| Component: | Drivers/DRI/i965 | Assignee: | Intel 3D Bugs Mailing List <intel-3d-bugs> |
| Status: | RESOLVED FIXED | QA Contact: | Intel 3D Bugs Mailing List <intel-3d-bugs> |
| Severity: | normal | ||
| Priority: | medium | CC: | idr, itoral, jasuarez, kenneth |
| Version: | git | ||
| Hardware: | Other | ||
| OS: | All | ||
| Whiteboard: | |||
| i915 platform: | i915 features: | ||
| Bug Depends on: | |||
| Bug Blocks: | 102590 | ||
|
Description
Juan A. Suarez
2017-09-08 08:19:21 UTC
This failure only happens in Broadwell. In Skylake works fine. Seems it is a regression caused by commit b96313c0e1289b296d7a2ea7f74687fc2ef66e78 Author: Kenneth Graunke <kenneth@whitecape.org> Date: Wed Aug 16 13:18:26 2017 -0700 i965: Drop BRW_NEW_BLORP from SURFACE_STATE setup code. BLORP invalidates the binding tables, but it doesn't destroy any of the existing SURFACE_STATE entries in the statebuffer. We can reuse those. Reviewed-by: Jason Ekstrand <jason@jlekstrand.net> src/mesa/drivers/dri/i965/brw_gs_surface_state.c | 4 ---- src/mesa/drivers/dri/i965/brw_tcs_surface_state.c | 4 ---- src/mesa/drivers/dri/i965/brw_tes_surface_state.c | 4 ---- src/mesa/drivers/dri/i965/brw_vs_surface_state.c | 4 ---- src/mesa/drivers/dri/i965/brw_wm_surface_state.c | 14 +------------- 5 files changed, 1 insertion(+), 29 deletions(-) I have posted a patch for review that fixes this: https://lists.freedesktop.org/archives/mesa-dev/2017-September/169305.html Patch doesn't seem right to me...I'll try and look into this soon. Disabling fast clears also works. It looks like the difference in the batches is that one has AUX_MCS and the other has AUX_NONE... 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... The test fails on Skylake and later if you run with INTEL_DEBUG=norbc - normally, we allocate the (CCS_E) auxiliary buffer up front, so it always exists, even in the initial surface state. With INTEL_DEBUG=norbc, we fall back to CCS_D, where we defer the allocation. Thanks for figuring this out Ken! I posted an RFC series based on this: https://lists.freedesktop.org/archives/mesa-dev/2017-September/169638.html Fixed by: commit 3d9cb39fd0c5895bd9774413e03c95c5b40bf030 Author: Iago Toral Quiroga <itoral@igalia.com> Date: Fri Sep 15 09:13:07 2017 +0200 i965: emit BRW_NEW_AUX_STATE on aux state changes Thanks Iago! |
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.