* maybe this isn't required for us in particular.
*/
+ if (brw->gen >= 6) {
+ const unsigned dc_flush =
+ brw->gen >= 7 ? PIPE_CONTROL_DATA_CACHE_FLUSH : 0;
+
+ /* Emit a render target cache flush.
+ *
+ * This isn't documented anywhere in the PRM. However, it seems to be
+ * necessary prior to changing the surface state base adress. We've
+ * seen issues in Vulkan where we get GPU hangs when using multi-level
+ * command buffers which clear depth, reset state base address, and then
+ * go render stuff.
+ *
+ * Normally, in GL, we would trust the kernel to do sufficient stalls
+ * and flushes prior to executing our batch. However, it doesn't seem
+ * as if the kernel's flushing is always sufficient and we don't want to
+ * rely on it.
+ */
+ brw_emit_pipe_control_flush(brw,
+ PIPE_CONTROL_RENDER_TARGET_FLUSH |
+ PIPE_CONTROL_DEPTH_CACHE_FLUSH |
+ dc_flush |
+ PIPE_CONTROL_NO_WRITE |
+ PIPE_CONTROL_CS_STALL);
+ }
+
if (brw->gen >= 8) {
uint32_t mocs_wb = brw->gen >= 9 ? SKL_MOCS_WB : BDW_MOCS_WB;
int pkt_len = brw->gen >= 9 ? 19 : 16;
ADVANCE_BATCH();
}
+ if (brw->gen >= 6) {
+ brw_emit_pipe_control_flush(brw,
+ PIPE_CONTROL_INSTRUCTION_INVALIDATE |
+ PIPE_CONTROL_STATE_CACHE_INVALIDATE |
+ PIPE_CONTROL_TEXTURE_CACHE_INVALIDATE);
+ }
+
/* According to section 3.6.1 of VOL1 of the 965 PRM,
* STATE_BASE_ADDRESS updates require a reissue of:
*
assert(batch->blorp->driver_ctx == batch->driver_batch);
struct brw_context *brw = batch->driver_batch;
struct gl_context *ctx = &brw->ctx;
- const uint32_t estimated_max_batch_usage = GEN_GEN >= 8 ? 1920 : 1500;
+ const uint32_t estimated_max_batch_usage = GEN_GEN >= 8 ? 1920 : 1700;
bool check_aperture_failed_once = false;
/* Flush the sampler and render caches. We definitely need to flush the