Bug 102611 - [OpenGL CTS] KHR-GL45.transform_feedback.draw_xfb_test fails
Summary: [OpenGL CTS] KHR-GL45.transform_feedback.draw_xfb_test fails
Alias: None
Product: Mesa
Classification: Unclassified
Component: Drivers/DRI/i965 (show other bugs)
Version: git
Hardware: Other All
: medium normal
Assignee: Intel 3D Bugs Mailing List
QA Contact: Intel 3D Bugs Mailing List
Depends on:
Blocks: 102590
  Show dependency treegraph
Reported: 2017-09-08 08:19 UTC by Juan A. Suarez
Modified: 2017-09-20 21:33 UTC (History)
4 users (show)

See Also:
i915 platform:
i915 features:


Description Juan A. Suarez 2017-09-08 08:19:21 UTC
Hardware: Broadwell
Mesa commit: 44ac54a
vk-gl-cts commit: dfcb8e870

KHR-GL45.transform_feedback.draw_xfb_test fails:

"Draw XFB have failed."
Comment 1 Juan A. Suarez 2017-09-08 08:23:14 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(-)
Comment 2 Iago Toral 2017-09-12 12:13:14 UTC
I have posted a patch for review that fixes this:
Comment 3 Kenneth Graunke 2017-09-13 08:45:07 UTC
Patch doesn't seem right to me...I'll try and look into this soon.
Comment 4 Kenneth Graunke 2017-09-14 01:47:17 UTC
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...
Comment 5 Kenneth Graunke 2017-09-14 05:29:52 UTC
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...
Comment 6 Kenneth Graunke 2017-09-14 05:35:05 UTC
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.
Comment 7 Iago Toral 2017-09-14 11:44:10 UTC
Thanks for figuring this out Ken!

I posted an RFC series based on this:
Comment 8 Kenneth Graunke 2017-09-20 21:33:57 UTC
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.