2019-03-08 20:25:19 +07:00
|
|
|
/*
|
|
|
|
* SPDX-License-Identifier: MIT
|
|
|
|
*
|
|
|
|
* Copyright © 2019 Intel Corporation
|
|
|
|
*/
|
|
|
|
|
|
|
|
#include "i915_drv.h"
|
|
|
|
#include "i915_gem_context.h"
|
|
|
|
#include "i915_globals.h"
|
2019-04-25 00:48:39 +07:00
|
|
|
|
2019-03-08 20:25:19 +07:00
|
|
|
#include "intel_context.h"
|
2019-04-25 00:48:39 +07:00
|
|
|
#include "intel_engine.h"
|
drm/i915: Invert the GEM wakeref hierarchy
In the current scheme, on submitting a request we take a single global
GEM wakeref, which trickles down to wake up all GT power domains. This
is undesirable as we would like to be able to localise our power
management to the available power domains and to remove the global GEM
operations from the heart of the driver. (The intent there is to push
global GEM decisions to the boundary as used by the GEM user interface.)
Now during request construction, each request is responsible via its
logical context to acquire a wakeref on each power domain it intends to
utilize. Currently, each request takes a wakeref on the engine(s) and
the engines themselves take a chipset wakeref. This gives us a
transition on each engine which we can extend if we want to insert more
powermangement control (such as soft rc6). The global GEM operations
that currently require a struct_mutex are reduced to listening to pm
events from the chipset GT wakeref. As we reduce the struct_mutex
requirement, these listeners should evaporate.
Perhaps the biggest immediate change is that this removes the
struct_mutex requirement around GT power management, allowing us greater
flexibility in request construction. Another important knock-on effect,
is that by tracking engine usage, we can insert a switch back to the
kernel context on that engine immediately, avoiding any extra delay or
inserting global synchronisation barriers. This makes tracking when an
engine and its associated contexts are idle much easier -- important for
when we forgo our assumed execution ordering and need idle barriers to
unpin used contexts. In the process, it means we remove a large chunk of
code whose only purpose was to switch back to the kernel context.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190424200717.1686-5-chris@chris-wilson.co.uk
2019-04-25 03:07:17 +07:00
|
|
|
#include "intel_engine_pm.h"
|
2019-03-08 20:25:19 +07:00
|
|
|
|
|
|
|
static struct i915_global_context {
|
|
|
|
struct i915_global base;
|
|
|
|
struct kmem_cache *slab_ce;
|
|
|
|
} global;
|
|
|
|
|
2019-04-26 23:33:34 +07:00
|
|
|
static struct intel_context *intel_context_alloc(void)
|
2019-03-08 20:25:19 +07:00
|
|
|
{
|
|
|
|
return kmem_cache_zalloc(global.slab_ce, GFP_KERNEL);
|
|
|
|
}
|
|
|
|
|
|
|
|
void intel_context_free(struct intel_context *ce)
|
|
|
|
{
|
|
|
|
kmem_cache_free(global.slab_ce, ce);
|
|
|
|
}
|
|
|
|
|
|
|
|
struct intel_context *
|
2019-04-26 23:33:34 +07:00
|
|
|
intel_context_create(struct i915_gem_context *ctx,
|
2019-03-08 20:25:19 +07:00
|
|
|
struct intel_engine_cs *engine)
|
|
|
|
{
|
2019-04-26 23:33:34 +07:00
|
|
|
struct intel_context *ce;
|
2019-03-08 20:25:19 +07:00
|
|
|
|
|
|
|
ce = intel_context_alloc();
|
|
|
|
if (!ce)
|
|
|
|
return ERR_PTR(-ENOMEM);
|
|
|
|
|
|
|
|
intel_context_init(ce, ctx, engine);
|
2019-04-26 23:33:34 +07:00
|
|
|
return ce;
|
2019-03-08 20:25:19 +07:00
|
|
|
}
|
|
|
|
|
2019-04-26 23:33:29 +07:00
|
|
|
int __intel_context_do_pin(struct intel_context *ce)
|
|
|
|
{
|
|
|
|
int err;
|
2019-03-08 20:25:22 +07:00
|
|
|
|
|
|
|
if (mutex_lock_interruptible(&ce->pin_mutex))
|
2019-04-26 23:33:29 +07:00
|
|
|
return -EINTR;
|
2019-03-08 20:25:22 +07:00
|
|
|
|
|
|
|
if (likely(!atomic_read(&ce->pin_count))) {
|
drm/i915: Invert the GEM wakeref hierarchy
In the current scheme, on submitting a request we take a single global
GEM wakeref, which trickles down to wake up all GT power domains. This
is undesirable as we would like to be able to localise our power
management to the available power domains and to remove the global GEM
operations from the heart of the driver. (The intent there is to push
global GEM decisions to the boundary as used by the GEM user interface.)
Now during request construction, each request is responsible via its
logical context to acquire a wakeref on each power domain it intends to
utilize. Currently, each request takes a wakeref on the engine(s) and
the engines themselves take a chipset wakeref. This gives us a
transition on each engine which we can extend if we want to insert more
powermangement control (such as soft rc6). The global GEM operations
that currently require a struct_mutex are reduced to listening to pm
events from the chipset GT wakeref. As we reduce the struct_mutex
requirement, these listeners should evaporate.
Perhaps the biggest immediate change is that this removes the
struct_mutex requirement around GT power management, allowing us greater
flexibility in request construction. Another important knock-on effect,
is that by tracking engine usage, we can insert a switch back to the
kernel context on that engine immediately, avoiding any extra delay or
inserting global synchronisation barriers. This makes tracking when an
engine and its associated contexts are idle much easier -- important for
when we forgo our assumed execution ordering and need idle barriers to
unpin used contexts. In the process, it means we remove a large chunk of
code whose only purpose was to switch back to the kernel context.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190424200717.1686-5-chris@chris-wilson.co.uk
2019-04-25 03:07:17 +07:00
|
|
|
intel_wakeref_t wakeref;
|
|
|
|
|
|
|
|
err = 0;
|
|
|
|
with_intel_runtime_pm(ce->engine->i915, wakeref)
|
|
|
|
err = ce->ops->pin(ce);
|
2019-03-08 20:25:20 +07:00
|
|
|
if (err)
|
2019-03-08 20:25:22 +07:00
|
|
|
goto err;
|
2019-03-08 20:25:20 +07:00
|
|
|
|
2019-04-26 23:33:35 +07:00
|
|
|
i915_gem_context_get(ce->gem_context); /* for ctx->ppgtt */
|
2019-03-08 20:25:20 +07:00
|
|
|
|
2019-03-19 04:23:47 +07:00
|
|
|
intel_context_get(ce);
|
2019-03-08 20:25:22 +07:00
|
|
|
smp_mb__before_atomic(); /* flush pin before it is visible */
|
2019-03-08 20:25:20 +07:00
|
|
|
}
|
|
|
|
|
2019-03-08 20:25:22 +07:00
|
|
|
atomic_inc(&ce->pin_count);
|
|
|
|
GEM_BUG_ON(!intel_context_is_pinned(ce)); /* no overflow! */
|
|
|
|
|
|
|
|
mutex_unlock(&ce->pin_mutex);
|
2019-04-26 23:33:29 +07:00
|
|
|
return 0;
|
2019-03-08 20:25:20 +07:00
|
|
|
|
2019-03-08 20:25:22 +07:00
|
|
|
err:
|
|
|
|
mutex_unlock(&ce->pin_mutex);
|
2019-04-26 23:33:29 +07:00
|
|
|
return err;
|
2019-03-08 20:25:20 +07:00
|
|
|
}
|
|
|
|
|
2019-03-08 20:25:22 +07:00
|
|
|
void intel_context_unpin(struct intel_context *ce)
|
|
|
|
{
|
|
|
|
if (likely(atomic_add_unless(&ce->pin_count, -1, 1)))
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* We may be called from inside intel_context_pin() to evict another */
|
2019-03-19 04:23:47 +07:00
|
|
|
intel_context_get(ce);
|
2019-03-08 20:25:22 +07:00
|
|
|
mutex_lock_nested(&ce->pin_mutex, SINGLE_DEPTH_NESTING);
|
|
|
|
|
2019-03-19 04:23:46 +07:00
|
|
|
if (likely(atomic_dec_and_test(&ce->pin_count))) {
|
2019-03-08 20:25:22 +07:00
|
|
|
ce->ops->unpin(ce);
|
|
|
|
|
2019-03-19 04:23:46 +07:00
|
|
|
i915_gem_context_put(ce->gem_context);
|
2019-03-19 04:23:47 +07:00
|
|
|
intel_context_put(ce);
|
2019-03-19 04:23:46 +07:00
|
|
|
}
|
|
|
|
|
2019-03-08 20:25:22 +07:00
|
|
|
mutex_unlock(&ce->pin_mutex);
|
2019-03-19 04:23:47 +07:00
|
|
|
intel_context_put(ce);
|
2019-03-08 20:25:22 +07:00
|
|
|
}
|
|
|
|
|
2019-03-08 20:25:19 +07:00
|
|
|
static void intel_context_retire(struct i915_active_request *active,
|
|
|
|
struct i915_request *rq)
|
|
|
|
{
|
|
|
|
struct intel_context *ce =
|
|
|
|
container_of(active, typeof(*ce), active_tracker);
|
|
|
|
|
|
|
|
intel_context_unpin(ce);
|
|
|
|
}
|
|
|
|
|
|
|
|
void
|
|
|
|
intel_context_init(struct intel_context *ce,
|
|
|
|
struct i915_gem_context *ctx,
|
|
|
|
struct intel_engine_cs *engine)
|
|
|
|
{
|
2019-04-26 23:33:34 +07:00
|
|
|
GEM_BUG_ON(!engine->cops);
|
|
|
|
|
2019-03-19 04:23:47 +07:00
|
|
|
kref_init(&ce->ref);
|
|
|
|
|
2019-03-08 20:25:19 +07:00
|
|
|
ce->gem_context = ctx;
|
|
|
|
ce->engine = engine;
|
|
|
|
ce->ops = engine->cops;
|
2019-04-24 16:51:34 +07:00
|
|
|
ce->sseu = engine->sseu;
|
drm/i915: Disable semaphore busywaits on saturated systems
Asking the GPU to busywait on a memory address, perhaps not unexpectedly
in hindsight for a shared system, leads to bus contention that affects
CPU programs trying to concurrently access memory. This can manifest as
a drop in transcode throughput on highly over-saturated workloads.
The only clue offered by perf, is that the bus-cycles (perf stat -e
bus-cycles) jumped by 50% when enabling semaphores. This corresponds
with extra CPU active cycles being attributed to intel_idle's mwait.
This patch introduces a heuristic to try and detect when more than one
client is submitting to the GPU pushing it into an oversaturated state.
As we already keep track of when the semaphores are signaled, we can
inspect their state on submitting the busywait batch and if we planned
to use a semaphore but were too late, conclude that the GPU is
overloaded and not try to use semaphores in future requests. In
practice, this means we optimistically try to use semaphores for the
first frame of a transcode job split over multiple engines, and fail if
there are multiple clients active and continue not to use semaphores for
the subsequent frames in the sequence. Periodically, we try to
optimistically switch semaphores back on whenever the client waits to
catch up with the transcode results.
With 1 client, on Broxton J3455, with the relative fps normalized by %cpu:
x no semaphores
+ drm-tip
* patched
+------------------------------------------------------------------------+
| * |
| *+ |
| **+ |
| **+ x |
| x * +**+ x |
| x x * * +***x xx |
| x x * * *+***x *x |
| x x* + * * *****x *x x |
| + x xx+x* + *** * ********* x * |
| + x xx+x* * *** +** ********* xx * |
| * + ++++* + x*x****+*+* ***+*************+x* * |
|*+ +** *+ + +* + *++****** *xxx**********x***+*****************+*++ *|
| |__________A_____M_____| |
| |_______________A____M_________| |
| |____________A___M________| |
+------------------------------------------------------------------------+
N Min Max Median Avg Stddev
x 120 2.60475 3.50941 3.31123 3.2143953 0.21117399
+ 120 2.3826 3.57077 3.25101 3.1414161 0.28146407
Difference at 95.0% confidence
-0.0729792 +/- 0.0629585
-2.27039% +/- 1.95864%
(Student's t, pooled s = 0.248814)
* 120 2.35536 3.66713 3.2849 3.2059917 0.24618565
No difference proven at 95.0% confidence
With 10 clients over-saturating the pipeline:
x no semaphores
+ drm-tip
* patched
+------------------------------------------------------------------------+
| ++ ** |
| ++ ** |
| ++ ** |
| ++ ** |
| ++ xx *** |
| ++ xx *** |
| ++ xxx*** |
| ++ xxx*** |
| +++ xxx*** |
| +++ xx**** |
| +++ xx**** |
| +++ xx**** |
| +++ xx**** |
| ++++ xx**** |
| +++++ xx**** |
| +++++ x x****** |
| ++++++ xxx******* |
| ++++++ xxx******* |
| ++++++ xxx******* |
| ++++++ xx******** |
| ++++++ xxxx******** |
| ++++++ xxxx******** |
| ++++++++ xxxxx********* |
|+ + + + ++++++++ xxx*xx**********x* *|
| |__A__| |
| |__AM__| |
| |__A_| |
+------------------------------------------------------------------------+
N Min Max Median Avg Stddev
x 120 2.47855 2.8972 2.72376 2.7193402 0.074604933
+ 120 1.17367 1.77459 1.71977 1.6966782 0.085850697
Difference at 95.0% confidence
-1.02266 +/- 0.0203502
-37.607% +/- 0.748352%
(Student's t, pooled s = 0.0804246)
* 120 2.57868 3.00821 2.80142 2.7923878 0.058646477
Difference at 95.0% confidence
0.0730476 +/- 0.0169791
2.68622% +/- 0.624383%
(Student's t, pooled s = 0.0671018)
Indicating that we've recovered the regression from enabling semaphores
on this saturated setup, with a hint towards an overall improvement.
Very similar, but of smaller magnitude, results are observed on both
Skylake(gt2) and Kabylake(gt4). This may be due to the reduced impact of
bus-cycles, where we see a 50% hit on Broxton, it is only 10% on the big
core, in this particular test.
One observation to make here is that for a greedy client trying to
maximise its own throughput, using semaphores is the right choice. It is
only the holistic system-wide view that semaphores of one client
impacts another and reduces the overall throughput where we would choose
to disable semaphores.
The most noticeable negactive impact this has is on the no-op
microbenchmarks, which are also very notable for having no cpu bus load.
In particular, this increases the runtime and energy consumption of
gem_exec_whisper.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
Cc: Dmitry Ermilov <dmitry.ermilov@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190504070707.30902-1-chris@chris-wilson.co.uk
2019-05-04 14:07:07 +07:00
|
|
|
ce->saturated = 0;
|
2019-03-08 20:25:19 +07:00
|
|
|
|
|
|
|
INIT_LIST_HEAD(&ce->signal_link);
|
|
|
|
INIT_LIST_HEAD(&ce->signals);
|
|
|
|
|
2019-03-08 20:25:22 +07:00
|
|
|
mutex_init(&ce->pin_mutex);
|
|
|
|
|
2019-03-08 20:25:19 +07:00
|
|
|
i915_active_request_init(&ce->active_tracker,
|
|
|
|
NULL, intel_context_retire);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void i915_global_context_shrink(void)
|
|
|
|
{
|
|
|
|
kmem_cache_shrink(global.slab_ce);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void i915_global_context_exit(void)
|
|
|
|
{
|
|
|
|
kmem_cache_destroy(global.slab_ce);
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct i915_global_context global = { {
|
|
|
|
.shrink = i915_global_context_shrink,
|
|
|
|
.exit = i915_global_context_exit,
|
|
|
|
} };
|
|
|
|
|
|
|
|
int __init i915_global_context_init(void)
|
|
|
|
{
|
|
|
|
global.slab_ce = KMEM_CACHE(intel_context, SLAB_HWCACHE_ALIGN);
|
|
|
|
if (!global.slab_ce)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
i915_global_register(&global.base);
|
|
|
|
return 0;
|
|
|
|
}
|
2019-04-25 03:07:15 +07:00
|
|
|
|
|
|
|
void intel_context_enter_engine(struct intel_context *ce)
|
|
|
|
{
|
drm/i915: Invert the GEM wakeref hierarchy
In the current scheme, on submitting a request we take a single global
GEM wakeref, which trickles down to wake up all GT power domains. This
is undesirable as we would like to be able to localise our power
management to the available power domains and to remove the global GEM
operations from the heart of the driver. (The intent there is to push
global GEM decisions to the boundary as used by the GEM user interface.)
Now during request construction, each request is responsible via its
logical context to acquire a wakeref on each power domain it intends to
utilize. Currently, each request takes a wakeref on the engine(s) and
the engines themselves take a chipset wakeref. This gives us a
transition on each engine which we can extend if we want to insert more
powermangement control (such as soft rc6). The global GEM operations
that currently require a struct_mutex are reduced to listening to pm
events from the chipset GT wakeref. As we reduce the struct_mutex
requirement, these listeners should evaporate.
Perhaps the biggest immediate change is that this removes the
struct_mutex requirement around GT power management, allowing us greater
flexibility in request construction. Another important knock-on effect,
is that by tracking engine usage, we can insert a switch back to the
kernel context on that engine immediately, avoiding any extra delay or
inserting global synchronisation barriers. This makes tracking when an
engine and its associated contexts are idle much easier -- important for
when we forgo our assumed execution ordering and need idle barriers to
unpin used contexts. In the process, it means we remove a large chunk of
code whose only purpose was to switch back to the kernel context.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190424200717.1686-5-chris@chris-wilson.co.uk
2019-04-25 03:07:17 +07:00
|
|
|
intel_engine_pm_get(ce->engine);
|
2019-04-25 03:07:15 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
void intel_context_exit_engine(struct intel_context *ce)
|
|
|
|
{
|
drm/i915: Disable semaphore busywaits on saturated systems
Asking the GPU to busywait on a memory address, perhaps not unexpectedly
in hindsight for a shared system, leads to bus contention that affects
CPU programs trying to concurrently access memory. This can manifest as
a drop in transcode throughput on highly over-saturated workloads.
The only clue offered by perf, is that the bus-cycles (perf stat -e
bus-cycles) jumped by 50% when enabling semaphores. This corresponds
with extra CPU active cycles being attributed to intel_idle's mwait.
This patch introduces a heuristic to try and detect when more than one
client is submitting to the GPU pushing it into an oversaturated state.
As we already keep track of when the semaphores are signaled, we can
inspect their state on submitting the busywait batch and if we planned
to use a semaphore but were too late, conclude that the GPU is
overloaded and not try to use semaphores in future requests. In
practice, this means we optimistically try to use semaphores for the
first frame of a transcode job split over multiple engines, and fail if
there are multiple clients active and continue not to use semaphores for
the subsequent frames in the sequence. Periodically, we try to
optimistically switch semaphores back on whenever the client waits to
catch up with the transcode results.
With 1 client, on Broxton J3455, with the relative fps normalized by %cpu:
x no semaphores
+ drm-tip
* patched
+------------------------------------------------------------------------+
| * |
| *+ |
| **+ |
| **+ x |
| x * +**+ x |
| x x * * +***x xx |
| x x * * *+***x *x |
| x x* + * * *****x *x x |
| + x xx+x* + *** * ********* x * |
| + x xx+x* * *** +** ********* xx * |
| * + ++++* + x*x****+*+* ***+*************+x* * |
|*+ +** *+ + +* + *++****** *xxx**********x***+*****************+*++ *|
| |__________A_____M_____| |
| |_______________A____M_________| |
| |____________A___M________| |
+------------------------------------------------------------------------+
N Min Max Median Avg Stddev
x 120 2.60475 3.50941 3.31123 3.2143953 0.21117399
+ 120 2.3826 3.57077 3.25101 3.1414161 0.28146407
Difference at 95.0% confidence
-0.0729792 +/- 0.0629585
-2.27039% +/- 1.95864%
(Student's t, pooled s = 0.248814)
* 120 2.35536 3.66713 3.2849 3.2059917 0.24618565
No difference proven at 95.0% confidence
With 10 clients over-saturating the pipeline:
x no semaphores
+ drm-tip
* patched
+------------------------------------------------------------------------+
| ++ ** |
| ++ ** |
| ++ ** |
| ++ ** |
| ++ xx *** |
| ++ xx *** |
| ++ xxx*** |
| ++ xxx*** |
| +++ xxx*** |
| +++ xx**** |
| +++ xx**** |
| +++ xx**** |
| +++ xx**** |
| ++++ xx**** |
| +++++ xx**** |
| +++++ x x****** |
| ++++++ xxx******* |
| ++++++ xxx******* |
| ++++++ xxx******* |
| ++++++ xx******** |
| ++++++ xxxx******** |
| ++++++ xxxx******** |
| ++++++++ xxxxx********* |
|+ + + + ++++++++ xxx*xx**********x* *|
| |__A__| |
| |__AM__| |
| |__A_| |
+------------------------------------------------------------------------+
N Min Max Median Avg Stddev
x 120 2.47855 2.8972 2.72376 2.7193402 0.074604933
+ 120 1.17367 1.77459 1.71977 1.6966782 0.085850697
Difference at 95.0% confidence
-1.02266 +/- 0.0203502
-37.607% +/- 0.748352%
(Student's t, pooled s = 0.0804246)
* 120 2.57868 3.00821 2.80142 2.7923878 0.058646477
Difference at 95.0% confidence
0.0730476 +/- 0.0169791
2.68622% +/- 0.624383%
(Student's t, pooled s = 0.0671018)
Indicating that we've recovered the regression from enabling semaphores
on this saturated setup, with a hint towards an overall improvement.
Very similar, but of smaller magnitude, results are observed on both
Skylake(gt2) and Kabylake(gt4). This may be due to the reduced impact of
bus-cycles, where we see a 50% hit on Broxton, it is only 10% on the big
core, in this particular test.
One observation to make here is that for a greedy client trying to
maximise its own throughput, using semaphores is the right choice. It is
only the holistic system-wide view that semaphores of one client
impacts another and reduces the overall throughput where we would choose
to disable semaphores.
The most noticeable negactive impact this has is on the no-op
microbenchmarks, which are also very notable for having no cpu bus load.
In particular, this increases the runtime and energy consumption of
gem_exec_whisper.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
Cc: Dmitry Ermilov <dmitry.ermilov@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190504070707.30902-1-chris@chris-wilson.co.uk
2019-05-04 14:07:07 +07:00
|
|
|
ce->saturated = 0;
|
drm/i915: Invert the GEM wakeref hierarchy
In the current scheme, on submitting a request we take a single global
GEM wakeref, which trickles down to wake up all GT power domains. This
is undesirable as we would like to be able to localise our power
management to the available power domains and to remove the global GEM
operations from the heart of the driver. (The intent there is to push
global GEM decisions to the boundary as used by the GEM user interface.)
Now during request construction, each request is responsible via its
logical context to acquire a wakeref on each power domain it intends to
utilize. Currently, each request takes a wakeref on the engine(s) and
the engines themselves take a chipset wakeref. This gives us a
transition on each engine which we can extend if we want to insert more
powermangement control (such as soft rc6). The global GEM operations
that currently require a struct_mutex are reduced to listening to pm
events from the chipset GT wakeref. As we reduce the struct_mutex
requirement, these listeners should evaporate.
Perhaps the biggest immediate change is that this removes the
struct_mutex requirement around GT power management, allowing us greater
flexibility in request construction. Another important knock-on effect,
is that by tracking engine usage, we can insert a switch back to the
kernel context on that engine immediately, avoiding any extra delay or
inserting global synchronisation barriers. This makes tracking when an
engine and its associated contexts are idle much easier -- important for
when we forgo our assumed execution ordering and need idle barriers to
unpin used contexts. In the process, it means we remove a large chunk of
code whose only purpose was to switch back to the kernel context.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190424200717.1686-5-chris@chris-wilson.co.uk
2019-04-25 03:07:17 +07:00
|
|
|
intel_engine_pm_put(ce->engine);
|
2019-04-25 03:07:15 +07:00
|
|
|
}
|
2019-04-26 23:33:34 +07:00
|
|
|
|
|
|
|
struct i915_request *intel_context_create_request(struct intel_context *ce)
|
|
|
|
{
|
|
|
|
struct i915_request *rq;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
err = intel_context_pin(ce);
|
|
|
|
if (unlikely(err))
|
|
|
|
return ERR_PTR(err);
|
|
|
|
|
|
|
|
rq = i915_request_create(ce);
|
|
|
|
intel_context_unpin(ce);
|
|
|
|
|
|
|
|
return rq;
|
|
|
|
}
|