This reveals some major breakage in the kernel.
---
src/mesa/drivers/dri/intel/intel_context.c | 22 ----------------------
1 files changed, 0 insertions(+), 22 deletions(-)
diff --git a/src/mesa/drivers/dri/intel/intel_context.c b/src/mesa/drivers/dri/intel/intel_context.c
index 377bcbc..573346da23 100644
--- a/src/mesa/drivers/dri/intel/intel_context.c
+++ b/src/mesa/drivers/dri/intel/intel_context.c
@@ -411,28 +411,6 @@ intel_prepare_render(struct intel_context *intel)
*/
if (intel->is_front_buffer_rendering)
intel->front_buffer_dirty = true;
-
- /* Wait for the swapbuffers before the one we just emitted, so we
- * don't get too many swaps outstanding for apps that are GPU-heavy
- * but not CPU-heavy.
- *
- * We're using intelDRI2Flush (called from the loader before
- * swapbuffer) and glFlush (for front buffer rendering) as the
- * indicator that a frame is done and then throttle when we get
- * here as we prepare to render the next frame. At this point for
- * round trips for swap/copy and getting new buffers are done and
- * we'll spend less time waiting on the GPU.
- *
- * Unfortunately, we don't have a handle to the batch containing
- * the swap, and getting our hands on that doesn't seem worth it,
- * so we just us the first batch we emitted after the last swap.
- */
- if (intel->need_throttle && intel->first_post_swapbuffers_batch) {
- drm_intel_bo_wait_rendering(intel->first_post_swapbuffers_batch);
- drm_intel_bo_unreference(intel->first_post_swapbuffers_batch);
- intel->first_post_swapbuffers_batch = NULL;
- intel->need_throttle = false;
- }
}
static void
--
1.7.9
