summaryrefslogtreecommitdiffstats
path: root/src/mesa/drivers/dri/common
diff options
context:
space:
mode:
authorKenneth Graunke <[email protected]>2012-08-10 10:26:03 -0700
committerKenneth Graunke <[email protected]>2012-08-12 20:12:13 -0700
commit9da50667f490ba2c6240f4c91c9707e3f181adae (patch)
treecaae15ed5579ce228c0a5c8fc30c65738a1aee69 /src/mesa/drivers/dri/common
parent006c1a3c652803e2ff8d5f7ea55c9cb5d8353279 (diff)
intel: Move finish_batch() call before MI_BATCH_BUFFER_END and padding.
On Gen4+, brw_finish_batch() calls brw_emit_query_end(), which emits some extra PIPE_CONTROLs to capture the current occlusion query data. Unfortunately, it was being called *after* _intel_batchbuffer_flush added the MI_BATCH_BUFFER_END, meaning those PIPE_CONTROLs didn't get inside the batch. Not only does this likely cause bogus occlusion query values, it can also cause crashes: with the recent change to use 64-bit depth count writes on Gen6+, we started emitting an odd-length PIPE_CONTROL, which happened after the MI_NOOP padding. This resulted in an odd-length batch buffer, which resulted in execbuf2 returning -EINVAL and the application dying with an intel_do_flush_locked failure. On older generations, finish_batch() doesn't emit any state, so this change shouldn't have any effect. Huge thanks to Chris Wilson for helping me figure this out. NOTE: This is a candidate for stable release branches. Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=53311 Signed-off-by: Kenneth Graunke <[email protected]> Reviewed-by: Chris Wilson <[email protected]> Reviewed-by: Eric Anholt <[email protected]>
Diffstat (limited to 'src/mesa/drivers/dri/common')
0 files changed, 0 insertions, 0 deletions