Mesa commit: 44ac54a
vk-gl-cts commit: dfcb8e870
"Draw XFB have failed."
This failure only happens in Broadwell. In Skylake works fine.
Seems it is a regression caused by
Author: Kenneth Graunke <firstname.lastname@example.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 <email@example.com>
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:
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:
Author: Iago Toral Quiroga <firstname.lastname@example.org>
Date: Fri Sep 15 09:13:07 2017 +0200
i965: emit BRW_NEW_AUX_STATE on aux state changes