From: Eric Anholt Date: Tue, 24 Dec 2013 23:11:54 +0000 (-0800) Subject: i965: Don't do the temporary-and-blit-copy for INVALIDATE_RANGE maps. X-Git-Url: https://git.libre-soc.org/?a=commitdiff_plain;h=f46563fe1c8a5560e4de0adf03e3d8770b7fc734;p=mesa.git i965: Don't do the temporary-and-blit-copy for INVALIDATE_RANGE maps. We definitely want to fall through to the unsynchronized map case, instead of wasting bandwidth on a copy. Prevents a -43.2407% +/- 1.06113% (n=49) performance regression on aa10perf when teaching glamor to provide the GL_INVALIDATE_RANGE_BIT information. This is a performance fix, which I usually wouldn't cherry-pick to stable. But this was really was just a bug in the code, its presence would discourage developers from giving us the best information they can, and I think we've got fairly high confidence in the unsynchronized map path already. Cc: 10.0 9.2 Reviewed-by: Kenneth Graunke --- diff --git a/src/mesa/drivers/dri/i965/intel_buffer_objects.c b/src/mesa/drivers/dri/i965/intel_buffer_objects.c index cab805acf00..84bc29d9c9d 100644 --- a/src/mesa/drivers/dri/i965/intel_buffer_objects.c +++ b/src/mesa/drivers/dri/i965/intel_buffer_objects.c @@ -357,7 +357,8 @@ intel_bufferobj_map_range(struct gl_context * ctx, * BO, and we'll copy what they put in there out at unmap or * FlushRange time. */ - if ((access & GL_MAP_INVALIDATE_RANGE_BIT) && + if (!(access & GL_MAP_UNSYNCHRONIZED_BIT) && + (access & GL_MAP_INVALIDATE_RANGE_BIT) && drm_intel_bo_busy(intel_obj->buffer)) { if (access & GL_MAP_FLUSH_EXPLICIT_BIT) { intel_obj->range_map_buffer = malloc(length);