diff options
| -rw-r--r-- | drivers/gpu/drm/i915/i915_gem.c | 16 |
1 files changed, 16 insertions, 0 deletions
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index b0186b8567e5..2865b44dfab2 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -2520,6 +2520,11 @@ i915_find_fence_reg(struct drm_device *dev, return avail; } +static void i915_gem_write_fence__ipi(void *data) +{ + wbinvd(); +} + /** * i915_gem_object_get_fence - set up a fence reg for an object * @obj: object to map through a fence reg @@ -2640,6 +2645,17 @@ update: switch (INTEL_INFO(dev)->gen) { case 7: case 6: + /* In order to fully serialize access to the fenced region and + * the update to the fence register we need to take extreme + * measures on SNB+. In theory, the write to the fence register + * flushes all memory transactions before, and coupled with the + * mb() placed around the register write we serialise all memory + * operations with respect to the changes in the tiler. Yet, on + * SNB+ we need to take a step further and emit an explicit wbinvd() + * on each processor in order to manually flush all memory + * transactions before updating the fence register. + */ + on_each_cpu(i915_gem_write_fence__ipi, NULL, 1); ret = sandybridge_write_fence_reg(obj, pipelined); break; case 5: |