intel-gfx.lists.freedesktop.org archive mirror
 help / color / mirror / Atom feed
From: Chris Wilson <chris@chris-wilson.co.uk>
To: intel-gfx@lists.freedesktop.org
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Subject: [Intel-gfx] [PATCH 13/36] drm/i915: Relinquish forcewake immediately after manual grouping
Date: Mon,  1 Jun 2020 08:24:23 +0100	[thread overview]
Message-ID: <20200601072446.19548-13-chris@chris-wilson.co.uk> (raw)
In-Reply-To: <20200601072446.19548-1-chris@chris-wilson.co.uk>

Our forcewake utilisation is split into categories: automatic and
manual. Around bare register reads, we look up the right forcewake
domain and automatically acquire and release [upon a timer] the
forcewake domain. For other access, where we know we require the
forcewake across a group of register reads, we manually acquire the
forcewake domain and release it at the end. Again, this currently arms
the domain timer for a later release.

However, looking at some energy utilisation profiles, we have tried to
avoid using forcewake [and rely on the natural wake up to post register
updates] due to that even keep the fw active for a brief period
contributes to a significant power draw [i.e. when the gpu is sleeping
with rc6 at high clocks]. But as it turns out, not posting the writes
immediately also has unintended consequences, such as not reducing the
clocks and so conserving power while busy.

As a compromise, let us only arm the domain timer for automatic
forcewake usage around bare register access, but immediately release the
forcewake when manually acquired by intel_uncore_forcewake_get/_put.

The corollary to this is that we may instead have to take forcewake more
often, and so incur a latency penalty in doing so. For Sandybridge this
was significant, and even on the latest machines, taking forcewake at
interrupt frequency is a huge impact. [So we don't do that anymore!
Hopefully, this will spare us from still needing the mitigation of the
timer for steady state execution.]

Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
---
 drivers/gpu/drm/i915/intel_uncore.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/i915/intel_uncore.c b/drivers/gpu/drm/i915/intel_uncore.c
index a61cb8ca4d50..7d6b9ae7403c 100644
--- a/drivers/gpu/drm/i915/intel_uncore.c
+++ b/drivers/gpu/drm/i915/intel_uncore.c
@@ -709,7 +709,7 @@ static void __intel_uncore_forcewake_put(struct intel_uncore *uncore,
 			continue;
 		}
 
-		fw_domain_arm_timer(domain);
+		uncore->funcs.force_wake_put(uncore, domain->mask);
 	}
 }
 
-- 
2.20.1

_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx

  parent reply	other threads:[~2020-06-01  7:25 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-01  7:24 [Intel-gfx] [PATCH 01/36] drm/i915: Handle very early engine initialisation failure Chris Wilson
2020-06-01  7:24 ` [Intel-gfx] [PATCH 02/36] drm/i915/gt: Split low level gen2-7 CS emitters Chris Wilson
2020-06-02  9:04   ` Mika Kuoppala
2020-06-01  7:24 ` [Intel-gfx] [PATCH 03/36] drm/i915/gt: Move legacy context wa to intel_workarounds Chris Wilson
2020-06-02  9:05   ` Mika Kuoppala
2020-06-01  7:24 ` [Intel-gfx] [PATCH 04/36] drm/i915: Trim the ironlake+ irq handler Chris Wilson
2020-06-01 11:49   ` Mika Kuoppala
2020-06-01 12:00     ` Chris Wilson
2020-06-01 12:08       ` Chris Wilson
2020-06-01  7:24 ` [Intel-gfx] [PATCH 05/36] Restore "drm/i915: drop engine_pin/unpin_breadcrumbs_irq" Chris Wilson
2020-06-01  7:24 ` [Intel-gfx] [PATCH 06/36] drm/i915/gt: Couple tasklet scheduling for all CS interrupts Chris Wilson
2020-06-01  7:24 ` [Intel-gfx] [PATCH 07/36] drm/i915/gt: Support creation of 'internal' rings Chris Wilson
2020-06-01  7:24 ` [Intel-gfx] [PATCH 08/36] drm/i915/gt: Use client timeline address for seqno writes Chris Wilson
2020-06-01  7:24 ` [Intel-gfx] [PATCH 09/36] drm/i915: Support inter-engine semaphores on gen6/7 Chris Wilson
2020-06-01  7:24 ` [Intel-gfx] [PATCH 10/36] drm/i915/gt: Infrastructure for ring scheduling Chris Wilson
2020-06-01  7:24 ` [Intel-gfx] [PATCH 11/36] drm/i915/gt: Enable busy-stats for ring-scheduler Chris Wilson
2020-06-01  8:03   ` [Intel-gfx] [PATCH] " Chris Wilson
2020-06-01  7:24 ` [Intel-gfx] [PATCH 12/36] drm/i915/gt: Track if an engine requires forcewake w/a Chris Wilson
2020-06-01 12:17   ` Mika Kuoppala
2020-06-01  7:24 ` Chris Wilson [this message]
2020-06-01 12:20   ` [Intel-gfx] [PATCH 13/36] drm/i915: Relinquish forcewake immediately after manual grouping Mika Kuoppala
2020-06-01  7:24 ` [Intel-gfx] [PATCH 14/36] drm/i915/gt: Implement ring scheduler for gen6/7 Chris Wilson
2020-06-01  7:24 ` [Intel-gfx] [PATCH 15/36] drm/i915/gt: Enable ring scheduling " Chris Wilson
2020-06-01  7:24 ` [Intel-gfx] [PATCH 16/36] drm/i915/gem: Mark the buffer pool as active for the cmdparser Chris Wilson
2020-06-01  7:24 ` [Intel-gfx] [PATCH 17/36] drm/i915/gem: Async GPU relocations only Chris Wilson
2020-06-01  7:24 ` [Intel-gfx] [PATCH 18/36] drm/i915: Add list_for_each_entry_safe_continue_reverse Chris Wilson
2020-06-01  7:24 ` [Intel-gfx] [PATCH 19/36] drm/i915/gem: Separate reloc validation into an earlier step Chris Wilson
2020-06-01  7:24 ` [Intel-gfx] [PATCH 20/36] drm/i915/gem: Lift GPU relocation allocation Chris Wilson
2020-06-01  7:24 ` [Intel-gfx] [PATCH 21/36] drm/i915/gem: Build the reloc request first Chris Wilson
2020-06-01  7:24 ` [Intel-gfx] [PATCH 22/36] drm/i915/gem: Add all GPU reloc awaits/signals en masse Chris Wilson
2020-06-01  7:24 ` [Intel-gfx] [PATCH 23/36] dma-buf: Proxy fence, an unsignaled fence placeholder Chris Wilson
2020-06-01  7:24 ` [Intel-gfx] [PATCH 24/36] drm/i915: Unpeel awaits on a proxy fence Chris Wilson
2020-06-01  7:24 ` [Intel-gfx] [PATCH 25/36] drm/i915/gem: Make relocations atomic within execbuf Chris Wilson
2020-06-01  7:24 ` [Intel-gfx] [PATCH 26/36] drm/syncobj: Allow use of dma-fence-proxy Chris Wilson
2020-06-01  7:24 ` [Intel-gfx] [PATCH 27/36] drm/i915/gem: Teach execbuf how to wait on future syncobj Chris Wilson
2020-06-01  7:24 ` [Intel-gfx] [PATCH 28/36] drm/i915/gem: Allow combining submit-fences with syncobj Chris Wilson
2020-06-01  7:24 ` [Intel-gfx] [PATCH 29/36] drm/i915/gt: Declare when we enabled timeslicing Chris Wilson
2020-06-01  7:24 ` [Intel-gfx] [PATCH 30/36] drm/i915: Drop I915_IDLE_ENGINES_TIMEOUT Chris Wilson
2020-06-01  7:24 ` [Intel-gfx] [PATCH 31/36] drm/i915: Always defer fenced work to the worker Chris Wilson
2020-06-01  7:24 ` [Intel-gfx] [PATCH 32/36] drm/i915/gem: Assign context id for async work Chris Wilson
2020-06-01  7:24 ` [Intel-gfx] [PATCH 33/36] drm/i915: Export a preallocate variant of i915_active_acquire() Chris Wilson
2020-06-01  7:24 ` [Intel-gfx] [PATCH 34/36] drm/i915/gem: Separate the ww_mutex walker into its own list Chris Wilson
2020-06-01  7:24 ` [Intel-gfx] [PATCH 35/36] drm/i915/gem: Asynchronous GTT unbinding Chris Wilson
2020-06-01  7:24 ` [Intel-gfx] [PATCH 36/36] drm/i915/gem: Bind the fence async for execbuf Chris Wilson
2020-06-01  7:34 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/36] drm/i915: Handle very early engine initialisation failure Patchwork
2020-06-01  7:36 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2020-06-01  7:56 ` [Intel-gfx] ✗ Fi.CI.BAT: failure " Patchwork
2020-06-01  8:30 ` [Intel-gfx] ✗ Fi.CI.CHECKPATCH: warning for series starting with [01/36] drm/i915: Handle very early engine initialisation failure (rev2) Patchwork
2020-06-01  8:31 ` [Intel-gfx] ✗ Fi.CI.SPARSE: " Patchwork
2020-06-01  8:51 ` [Intel-gfx] ✓ Fi.CI.BAT: success " Patchwork
2020-06-01 11:00 ` [Intel-gfx] ✗ Fi.CI.IGT: failure " Patchwork
2020-06-01 11:39   ` Chris Wilson
2020-06-01 11:31 ` [Intel-gfx] [PATCH 01/36] drm/i915: Handle very early engine initialisation failure Mika Kuoppala

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200601072446.19548-13-chris@chris-wilson.co.uk \
    --to=chris@chris-wilson.co.uk \
    --cc=intel-gfx@lists.freedesktop.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).