drm/i915: Simplify flush_cpu_write_domain
authorDaniel Vetter <daniel.vetter@ffwll.ch>
Wed, 21 Jan 2015 13:53:48 +0000 (14:53 +0100)
committerDaniel Vetter <daniel.vetter@ffwll.ch>
Tue, 27 Jan 2015 08:51:08 +0000 (09:51 +0100)
commite62b59e4132fc73494f33eec3de9667bc135060e
treee783d7c83fcdae9d750dd93151e93ba938d39b42
parentd9806c9fd31920a13f4c5b4d4352ffe286d8787c
drm/i915: Simplify flush_cpu_write_domain

We can push down the decision whether to force flushing into the
implementation since in all places that matter obj->pin_display is
accurate already. The only place where the optimization really matters
is the sw_finish_ioctl, and that already checks for obj->pin_display
on its own.

I suspect that this was simply an artifact of how

commit 2c22569bba8af6c2976d5f9479fe54a53a39966b
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Fri Aug 9 12:26:45 2013 +0100

    drm/i915: Update rules for writing through the LLC with the cpu

evolved - only v2 added the pin_display tracking.

Note that we still retain the gist of this logic from the above commit
with the explicit force argument for the low-level clflush function.

Ville noted in his review that there's a slight behavioural change in
the set_to_gtt_domain function, which now also will flush display
plane data. This opens-open the potential for userspace to start doing
buggy things by omitting the sw_finish_ioctl, which is why I've
rejected a functional equivalent patch from Ville a while ago:

http://lists.freedesktop.org/archives/intel-gfx/2013-November/036421.html

But on second consideration it's not that evil, and in any case the
justification here is more clarity, not allowing crazy userspace.

Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
drivers/gpu/drm/i915/i915_gem.c
This page took 0.027195 seconds and 5 git commands to generate.