[PATCH 2/2] drm/i915: Limit calling mark-busy only for potential scanouts

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Thu, May 03, 2012 at 12:35:21PM +0100, Chris Wilson wrote:
> The principle of intel_mark_busy() is that we want to spot the
> transition of when the display engine is being used in order to bump
> powersaving modes and increase display clocks. As such it is only
> important when the display is changing, i.e. when rendering to the
> scanout or other sprite/plane, and these are characterised by being
> pinned.
> 
> Signed-off-by: Chris Wilson <chris at chris-wilson.co.uk>
> ---
>  drivers/gpu/drm/i915/i915_gem_execbuffer.c |    3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/gpu/drm/i915/i915_gem_execbuffer.c b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> index 451efa3..10bb075 100644
> --- a/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> +++ b/drivers/gpu/drm/i915/i915_gem_execbuffer.c
> @@ -979,7 +979,8 @@ i915_gem_execbuffer_move_to_active(struct list_head *objects,
>  			obj->pending_gpu_write = true;
>  			list_move_tail(&obj->gpu_write_list,
>  				       &ring->gpu_write_list);
> -			intel_mark_busy(ring->dev, obj);
> +			if (obj->pin_count) /* check for potential scanout */
> +				intel_mark_busy(ring->dev, obj);

intel_mark_busy also controls ips power sharing on ilk, so if we have
loads of batchbuffers not rendering to the a framebuffer, this might hurt
performance. Another thing I've noticed is that we fail to call
intel_mark_busy on pageflips, and I presume running the display at a low
refresh rate instead of the expected high when e.g. displaying videos
could decently confuse userspace.

Care to throw in that fix, too?
-Daniel
-- 
Daniel Vetter
Mail: daniel at ffwll.ch
Mobile: +41 (0)79 365 57 48


[Index of Archives]     [Linux USB Devel]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]
  Powered by Linux