drm/i915: preliminary context support
Very basic code for context setup/destruction in the driver.
Adds the file i915_gem_context.c This file implements HW context
support. On gen5+ a HW context consists of an opaque GPU object which is
referenced at times of context saves and restores. With RC6 enabled,
the context is also referenced as the GPU enters and exists from RC6
(GPU has it's own internal power context, except on gen5). Though
something like a context does exist for the media ring, the code only
supports contexts for the render ring.
In software, there is a distinction between contexts created by the
user, and the default HW context. The default HW context is used by GPU
clients that do not request setup of their own hardware context. The
default context's state is never restored to help prevent programming
errors. This would happen if a client ran and piggy-backed off another
clients GPU state. The default context only exists to give the GPU some
offset to load as the current to invoke a save of the context we
actually care about. In fact, the code could likely be constructed,
albeit in a more complicated fashion, to never use the default context,
though that limits the driver's ability to swap out, and/or destroy
other contexts.
All other contexts are created as a request by the GPU client. These
contexts store GPU state, and thus allow GPU clients to not re-emit
state (and potentially query certain state) at any time. The kernel
driver makes certain that the appropriate commands are inserted.
There are 4 entry points into the contexts, init, fini, open, close.
The names are self-explanatory except that init can be called during
reset, and also during pm thaw/resume. As we expect our context to be
preserved across these events, we do not reinitialize in this case.
As Adam Jackson pointed out, The cutoff of 1MB where a HW context is
considered too big is arbitrary. The reason for this is even though
context sizes are increasing with every generation, they have yet to
eclipse even 32k. If we somehow read back way more than that, it
probably means BIOS has done something strange, or we're running on a
platform that wasn't designed for this.
v2: rename load/unload to init/fini (daniel)
remove ILK support for get_size() (indirectly daniel)
add HAS_HW_CONTEXTS macro to clarify supported platforms (daniel)
added comments (Ben)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-05 05:42:42 +08:00
|
|
|
/*
|
2019-05-28 17:29:49 +08:00
|
|
|
* SPDX-License-Identifier: MIT
|
drm/i915: preliminary context support
Very basic code for context setup/destruction in the driver.
Adds the file i915_gem_context.c This file implements HW context
support. On gen5+ a HW context consists of an opaque GPU object which is
referenced at times of context saves and restores. With RC6 enabled,
the context is also referenced as the GPU enters and exists from RC6
(GPU has it's own internal power context, except on gen5). Though
something like a context does exist for the media ring, the code only
supports contexts for the render ring.
In software, there is a distinction between contexts created by the
user, and the default HW context. The default HW context is used by GPU
clients that do not request setup of their own hardware context. The
default context's state is never restored to help prevent programming
errors. This would happen if a client ran and piggy-backed off another
clients GPU state. The default context only exists to give the GPU some
offset to load as the current to invoke a save of the context we
actually care about. In fact, the code could likely be constructed,
albeit in a more complicated fashion, to never use the default context,
though that limits the driver's ability to swap out, and/or destroy
other contexts.
All other contexts are created as a request by the GPU client. These
contexts store GPU state, and thus allow GPU clients to not re-emit
state (and potentially query certain state) at any time. The kernel
driver makes certain that the appropriate commands are inserted.
There are 4 entry points into the contexts, init, fini, open, close.
The names are self-explanatory except that init can be called during
reset, and also during pm thaw/resume. As we expect our context to be
preserved across these events, we do not reinitialize in this case.
As Adam Jackson pointed out, The cutoff of 1MB where a HW context is
considered too big is arbitrary. The reason for this is even though
context sizes are increasing with every generation, they have yet to
eclipse even 32k. If we somehow read back way more than that, it
probably means BIOS has done something strange, or we're running on a
platform that wasn't designed for this.
v2: rename load/unload to init/fini (daniel)
remove ILK support for get_size() (indirectly daniel)
add HAS_HW_CONTEXTS macro to clarify supported platforms (daniel)
added comments (Ben)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-05 05:42:42 +08:00
|
|
|
*
|
2019-05-28 17:29:49 +08:00
|
|
|
* Copyright © 2011-2012 Intel Corporation
|
drm/i915: preliminary context support
Very basic code for context setup/destruction in the driver.
Adds the file i915_gem_context.c This file implements HW context
support. On gen5+ a HW context consists of an opaque GPU object which is
referenced at times of context saves and restores. With RC6 enabled,
the context is also referenced as the GPU enters and exists from RC6
(GPU has it's own internal power context, except on gen5). Though
something like a context does exist for the media ring, the code only
supports contexts for the render ring.
In software, there is a distinction between contexts created by the
user, and the default HW context. The default HW context is used by GPU
clients that do not request setup of their own hardware context. The
default context's state is never restored to help prevent programming
errors. This would happen if a client ran and piggy-backed off another
clients GPU state. The default context only exists to give the GPU some
offset to load as the current to invoke a save of the context we
actually care about. In fact, the code could likely be constructed,
albeit in a more complicated fashion, to never use the default context,
though that limits the driver's ability to swap out, and/or destroy
other contexts.
All other contexts are created as a request by the GPU client. These
contexts store GPU state, and thus allow GPU clients to not re-emit
state (and potentially query certain state) at any time. The kernel
driver makes certain that the appropriate commands are inserted.
There are 4 entry points into the contexts, init, fini, open, close.
The names are self-explanatory except that init can be called during
reset, and also during pm thaw/resume. As we expect our context to be
preserved across these events, we do not reinitialize in this case.
As Adam Jackson pointed out, The cutoff of 1MB where a HW context is
considered too big is arbitrary. The reason for this is even though
context sizes are increasing with every generation, they have yet to
eclipse even 32k. If we somehow read back way more than that, it
probably means BIOS has done something strange, or we're running on a
platform that wasn't designed for this.
v2: rename load/unload to init/fini (daniel)
remove ILK support for get_size() (indirectly daniel)
add HAS_HW_CONTEXTS macro to clarify supported platforms (daniel)
added comments (Ben)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-05 05:42:42 +08:00
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This file implements HW context support. On gen5+ a HW context consists of an
|
|
|
|
* opaque GPU object which is referenced at times of context saves and restores.
|
|
|
|
* With RC6 enabled, the context is also referenced as the GPU enters and exists
|
|
|
|
* from RC6 (GPU has it's own internal power context, except on gen5). Though
|
|
|
|
* something like a context does exist for the media ring, the code only
|
|
|
|
* supports contexts for the render ring.
|
|
|
|
*
|
|
|
|
* In software, there is a distinction between contexts created by the user,
|
|
|
|
* and the default HW context. The default HW context is used by GPU clients
|
|
|
|
* that do not request setup of their own hardware context. The default
|
|
|
|
* context's state is never restored to help prevent programming errors. This
|
|
|
|
* would happen if a client ran and piggy-backed off another clients GPU state.
|
|
|
|
* The default context only exists to give the GPU some offset to load as the
|
|
|
|
* current to invoke a save of the context we actually care about. In fact, the
|
|
|
|
* code could likely be constructed, albeit in a more complicated fashion, to
|
|
|
|
* never use the default context, though that limits the driver's ability to
|
|
|
|
* swap out, and/or destroy other contexts.
|
|
|
|
*
|
|
|
|
* All other contexts are created as a request by the GPU client. These contexts
|
|
|
|
* store GPU state, and thus allow GPU clients to not re-emit state (and
|
|
|
|
* potentially query certain state) at any time. The kernel driver makes
|
|
|
|
* certain that the appropriate commands are inserted.
|
|
|
|
*
|
|
|
|
* The context life cycle is semi-complicated in that context BOs may live
|
|
|
|
* longer than the context itself because of the way the hardware, and object
|
|
|
|
* tracking works. Below is a very crude representation of the state machine
|
|
|
|
* describing the context life.
|
|
|
|
* refcount pincount active
|
|
|
|
* S0: initial state 0 0 0
|
|
|
|
* S1: context created 1 0 0
|
|
|
|
* S2: context is currently running 2 1 X
|
|
|
|
* S3: GPU referenced, but not current 2 0 1
|
|
|
|
* S4: context is current, but destroyed 1 1 0
|
|
|
|
* S5: like S3, but destroyed 1 0 1
|
|
|
|
*
|
|
|
|
* The most common (but not all) transitions:
|
|
|
|
* S0->S1: client creates a context
|
|
|
|
* S1->S2: client submits execbuf with context
|
|
|
|
* S2->S3: other clients submits execbuf with context
|
|
|
|
* S3->S1: context object was retired
|
|
|
|
* S3->S2: clients submits another execbuf
|
|
|
|
* S2->S4: context destroy called with current context
|
|
|
|
* S3->S5->S0: destroy path
|
|
|
|
* S4->S5->S0: destroy path on current context
|
|
|
|
*
|
|
|
|
* There are two confusing terms used above:
|
|
|
|
* The "current context" means the context which is currently running on the
|
2013-08-30 21:40:26 +08:00
|
|
|
* GPU. The GPU has loaded its state already and has stored away the gtt
|
drm/i915: preliminary context support
Very basic code for context setup/destruction in the driver.
Adds the file i915_gem_context.c This file implements HW context
support. On gen5+ a HW context consists of an opaque GPU object which is
referenced at times of context saves and restores. With RC6 enabled,
the context is also referenced as the GPU enters and exists from RC6
(GPU has it's own internal power context, except on gen5). Though
something like a context does exist for the media ring, the code only
supports contexts for the render ring.
In software, there is a distinction between contexts created by the
user, and the default HW context. The default HW context is used by GPU
clients that do not request setup of their own hardware context. The
default context's state is never restored to help prevent programming
errors. This would happen if a client ran and piggy-backed off another
clients GPU state. The default context only exists to give the GPU some
offset to load as the current to invoke a save of the context we
actually care about. In fact, the code could likely be constructed,
albeit in a more complicated fashion, to never use the default context,
though that limits the driver's ability to swap out, and/or destroy
other contexts.
All other contexts are created as a request by the GPU client. These
contexts store GPU state, and thus allow GPU clients to not re-emit
state (and potentially query certain state) at any time. The kernel
driver makes certain that the appropriate commands are inserted.
There are 4 entry points into the contexts, init, fini, open, close.
The names are self-explanatory except that init can be called during
reset, and also during pm thaw/resume. As we expect our context to be
preserved across these events, we do not reinitialize in this case.
As Adam Jackson pointed out, The cutoff of 1MB where a HW context is
considered too big is arbitrary. The reason for this is even though
context sizes are increasing with every generation, they have yet to
eclipse even 32k. If we somehow read back way more than that, it
probably means BIOS has done something strange, or we're running on a
platform that wasn't designed for this.
v2: rename load/unload to init/fini (daniel)
remove ILK support for get_size() (indirectly daniel)
add HAS_HW_CONTEXTS macro to clarify supported platforms (daniel)
added comments (Ben)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-05 05:42:42 +08:00
|
|
|
* offset of the BO. The GPU is not actively referencing the data at this
|
|
|
|
* offset, but it will on the next context switch. The only way to avoid this
|
|
|
|
* is to do a GPU reset.
|
|
|
|
*
|
|
|
|
* An "active context' is one which was previously the "current context" and is
|
|
|
|
* on the active list waiting for the next context switch to occur. Until this
|
|
|
|
* happens, the object must remain at the same gtt offset. It is therefore
|
|
|
|
* possible to destroy a context, but it is still active.
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
|
2017-06-16 22:05:16 +08:00
|
|
|
#include <linux/log2.h>
|
drm/i915: Load balancing across a virtual engine
Having allowed the user to define a set of engines that they will want
to only use, we go one step further and allow them to bind those engines
into a single virtual instance. Submitting a batch to the virtual engine
will then forward it to any one of the set in a manner as best to
distribute load. The virtual engine has a single timeline across all
engines (it operates as a single queue), so it is not able to concurrently
run batches across multiple engines by itself; that is left up to the user
to submit multiple concurrent batches to multiple queues. Multiple users
will be load balanced across the system.
The mechanism used for load balancing in this patch is a late greedy
balancer. When a request is ready for execution, it is added to each
engine's queue, and when an engine is ready for its next request it
claims it from the virtual engine. The first engine to do so, wins, i.e.
the request is executed at the earliest opportunity (idle moment) in the
system.
As not all HW is created equal, the user is still able to skip the
virtual engine and execute the batch on a specific engine, all within the
same queue. It will then be executed in order on the correct engine,
with execution on other virtual engines being moved away due to the load
detection.
A couple of areas for potential improvement left!
- The virtual engine always take priority over equal-priority tasks.
Mostly broken up by applying FQ_CODEL rules for prioritising new clients,
and hopefully the virtual and real engines are not then congested (i.e.
all work is via virtual engines, or all work is to the real engine).
- We require the breadcrumb irq around every virtual engine request. For
normal engines, we eliminate the need for the slow round trip via
interrupt by using the submit fence and queueing in order. For virtual
engines, we have to allow any job to transfer to a new ring, and cannot
coalesce the submissions, so require the completion fence instead,
forcing the persistent use of interrupts.
- We only drip feed single requests through each virtual engine and onto
the physical engines, even if there was enough work to fill all ELSP,
leaving small stalls with an idle CS event at the end of every request.
Could we be greedy and fill both slots? Being lazy is virtuous for load
distribution on less-than-full workloads though.
Other areas of improvement are more general, such as reducing lock
contention, reducing dispatch overhead, looking at direct submission
rather than bouncing around tasklets etc.
sseu: Lift the restriction to allow sseu to be reconfigured on virtual
engines composed of RENDER_CLASS (rcs).
v2: macroize check_user_mbz()
v3: Cancel virtual engines on wedging
v4: Commence commenting
v5: Replace 64b sibling_mask with a list of class:instance
v6: Drop the one-element array in the uabi
v7: Assert it is an virtual engine in to_virtual_engine()
v8: Skip over holes in [class][inst] so we can selftest with (vcs0, vcs2)
Link: https://github.com/intel/media-driver/pull/283
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190521211134.16117-6-chris@chris-wilson.co.uk
2019-05-22 05:11:30 +08:00
|
|
|
#include <linux/nospec.h>
|
2019-04-25 01:48:39 +08:00
|
|
|
|
2012-10-03 01:01:07 +08:00
|
|
|
#include <drm/i915_drm.h>
|
2019-04-25 01:48:39 +08:00
|
|
|
|
2019-10-23 21:31:07 +08:00
|
|
|
#include "gt/intel_engine_heartbeat.h"
|
2019-11-25 18:58:56 +08:00
|
|
|
#include "gt/intel_engine_pm.h"
|
2019-08-06 20:43:00 +08:00
|
|
|
#include "gt/intel_engine_user.h"
|
2019-10-24 18:03:44 +08:00
|
|
|
#include "gt/intel_lrc_reg.h"
|
|
|
|
#include "gt/intel_ring.h"
|
2019-04-25 01:48:39 +08:00
|
|
|
|
2019-05-28 17:29:49 +08:00
|
|
|
#include "i915_gem_context.h"
|
2019-03-06 05:38:30 +08:00
|
|
|
#include "i915_globals.h"
|
2014-11-10 21:44:31 +08:00
|
|
|
#include "i915_trace.h"
|
2019-03-22 17:23:23 +08:00
|
|
|
#include "i915_user_extensions.h"
|
drm/i915: preliminary context support
Very basic code for context setup/destruction in the driver.
Adds the file i915_gem_context.c This file implements HW context
support. On gen5+ a HW context consists of an opaque GPU object which is
referenced at times of context saves and restores. With RC6 enabled,
the context is also referenced as the GPU enters and exists from RC6
(GPU has it's own internal power context, except on gen5). Though
something like a context does exist for the media ring, the code only
supports contexts for the render ring.
In software, there is a distinction between contexts created by the
user, and the default HW context. The default HW context is used by GPU
clients that do not request setup of their own hardware context. The
default context's state is never restored to help prevent programming
errors. This would happen if a client ran and piggy-backed off another
clients GPU state. The default context only exists to give the GPU some
offset to load as the current to invoke a save of the context we
actually care about. In fact, the code could likely be constructed,
albeit in a more complicated fashion, to never use the default context,
though that limits the driver's ability to swap out, and/or destroy
other contexts.
All other contexts are created as a request by the GPU client. These
contexts store GPU state, and thus allow GPU clients to not re-emit
state (and potentially query certain state) at any time. The kernel
driver makes certain that the appropriate commands are inserted.
There are 4 entry points into the contexts, init, fini, open, close.
The names are self-explanatory except that init can be called during
reset, and also during pm thaw/resume. As we expect our context to be
preserved across these events, we do not reinitialize in this case.
As Adam Jackson pointed out, The cutoff of 1MB where a HW context is
considered too big is arbitrary. The reason for this is even though
context sizes are increasing with every generation, they have yet to
eclipse even 32k. If we somehow read back way more than that, it
probably means BIOS has done something strange, or we're running on a
platform that wasn't designed for this.
v2: rename load/unload to init/fini (daniel)
remove ILK support for get_size() (indirectly daniel)
add HAS_HW_CONTEXTS macro to clarify supported platforms (daniel)
added comments (Ben)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-05 05:42:42 +08:00
|
|
|
|
2016-04-28 16:56:41 +08:00
|
|
|
#define ALL_L3_SLICES(dev) (1 << NUM_L3_SLICES(dev)) - 1
|
|
|
|
|
2019-03-08 21:25:19 +08:00
|
|
|
static struct i915_global_gem_context {
|
2019-03-06 05:38:30 +08:00
|
|
|
struct i915_global base;
|
2019-02-28 18:20:34 +08:00
|
|
|
struct kmem_cache *slab_luts;
|
|
|
|
} global;
|
|
|
|
|
|
|
|
struct i915_lut_handle *i915_lut_handle_alloc(void)
|
|
|
|
{
|
|
|
|
return kmem_cache_alloc(global.slab_luts, GFP_KERNEL);
|
|
|
|
}
|
|
|
|
|
|
|
|
void i915_lut_handle_free(struct i915_lut_handle *lut)
|
|
|
|
{
|
|
|
|
return kmem_cache_free(global.slab_luts, lut);
|
|
|
|
}
|
|
|
|
|
2017-08-16 16:52:08 +08:00
|
|
|
static void lut_close(struct i915_gem_context *ctx)
|
2017-06-16 22:05:16 +08:00
|
|
|
{
|
2017-08-16 16:52:08 +08:00
|
|
|
struct radix_tree_iter iter;
|
|
|
|
void __rcu **slot;
|
|
|
|
|
2019-06-06 19:23:20 +08:00
|
|
|
lockdep_assert_held(&ctx->mutex);
|
2017-06-16 22:05:16 +08:00
|
|
|
|
2017-10-26 21:00:32 +08:00
|
|
|
rcu_read_lock();
|
2017-08-16 16:52:08 +08:00
|
|
|
radix_tree_for_each_slot(slot, &ctx->handles_vma, &iter, 0) {
|
|
|
|
struct i915_vma *vma = rcu_dereference_raw(*slot);
|
2019-06-06 19:23:20 +08:00
|
|
|
struct drm_i915_gem_object *obj = vma->obj;
|
|
|
|
struct i915_lut_handle *lut;
|
|
|
|
|
|
|
|
if (!kref_get_unless_zero(&obj->base.refcount))
|
|
|
|
continue;
|
2017-06-16 22:05:16 +08:00
|
|
|
|
2019-06-06 19:23:20 +08:00
|
|
|
rcu_read_unlock();
|
|
|
|
i915_gem_object_lock(obj);
|
|
|
|
list_for_each_entry(lut, &obj->lut_list, obj_link) {
|
|
|
|
if (lut->ctx != ctx)
|
|
|
|
continue;
|
2019-03-22 17:23:23 +08:00
|
|
|
|
2019-06-06 19:23:20 +08:00
|
|
|
if (lut->handle != iter.index)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
list_del(&lut->obj_link);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
i915_gem_object_unlock(obj);
|
|
|
|
rcu_read_lock();
|
|
|
|
|
|
|
|
if (&lut->obj_link != &obj->lut_list) {
|
|
|
|
i915_lut_handle_free(lut);
|
|
|
|
radix_tree_iter_delete(&ctx->handles_vma, &iter, slot);
|
|
|
|
if (atomic_dec_and_test(&vma->open_count) &&
|
|
|
|
!i915_vma_is_ggtt(vma))
|
|
|
|
i915_vma_close(vma);
|
|
|
|
i915_gem_object_put(obj);
|
|
|
|
}
|
|
|
|
|
|
|
|
i915_gem_object_put(obj);
|
2017-06-16 22:05:16 +08:00
|
|
|
}
|
2017-10-26 21:00:32 +08:00
|
|
|
rcu_read_unlock();
|
2017-06-16 22:05:16 +08:00
|
|
|
}
|
|
|
|
|
2019-04-27 00:33:32 +08:00
|
|
|
static struct intel_context *
|
drm/i915: Allow a context to define its set of engines
Over the last few years, we have debated how to extend the user API to
support an increase in the number of engines, that may be sparse and
even be heterogeneous within a class (not all video decoders created
equal). We settled on using (class, instance) tuples to identify a
specific engine, with an API for the user to construct a map of engines
to capabilities. Into this picture, we then add a challenge of virtual
engines; one user engine that maps behind the scenes to any number of
physical engines. To keep it general, we want the user to have full
control over that mapping. To that end, we allow the user to constrain a
context to define the set of engines that it can access, order fully
controlled by the user via (class, instance). With such precise control
in context setup, we can continue to use the existing execbuf uABI of
specifying a single index; only now it doesn't automagically map onto
the engines, it uses the user defined engine map from the context.
v2: Fixup freeing of local on success of get_engines()
v3: Allow empty engines[]
v4: s/nengine/num_engines/
v5: Replace 64 limit on num_engines with a note that execbuf is
currently limited to only using the first 64 engines.
v6: Actually use the engines_mutex to guard the ctx->engines.
Testcase: igt/gem_ctx_engines
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190521211134.16117-2-chris@chris-wilson.co.uk
2019-05-22 05:11:26 +08:00
|
|
|
lookup_user_engine(struct i915_gem_context *ctx,
|
|
|
|
unsigned long flags,
|
|
|
|
const struct i915_engine_class_instance *ci)
|
|
|
|
#define LOOKUP_USER_INDEX BIT(0)
|
2019-04-27 00:33:32 +08:00
|
|
|
{
|
drm/i915: Allow a context to define its set of engines
Over the last few years, we have debated how to extend the user API to
support an increase in the number of engines, that may be sparse and
even be heterogeneous within a class (not all video decoders created
equal). We settled on using (class, instance) tuples to identify a
specific engine, with an API for the user to construct a map of engines
to capabilities. Into this picture, we then add a challenge of virtual
engines; one user engine that maps behind the scenes to any number of
physical engines. To keep it general, we want the user to have full
control over that mapping. To that end, we allow the user to constrain a
context to define the set of engines that it can access, order fully
controlled by the user via (class, instance). With such precise control
in context setup, we can continue to use the existing execbuf uABI of
specifying a single index; only now it doesn't automagically map onto
the engines, it uses the user defined engine map from the context.
v2: Fixup freeing of local on success of get_engines()
v3: Allow empty engines[]
v4: s/nengine/num_engines/
v5: Replace 64 limit on num_engines with a note that execbuf is
currently limited to only using the first 64 engines.
v6: Actually use the engines_mutex to guard the ctx->engines.
Testcase: igt/gem_ctx_engines
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190521211134.16117-2-chris@chris-wilson.co.uk
2019-05-22 05:11:26 +08:00
|
|
|
int idx;
|
2019-04-27 00:33:32 +08:00
|
|
|
|
drm/i915: Allow a context to define its set of engines
Over the last few years, we have debated how to extend the user API to
support an increase in the number of engines, that may be sparse and
even be heterogeneous within a class (not all video decoders created
equal). We settled on using (class, instance) tuples to identify a
specific engine, with an API for the user to construct a map of engines
to capabilities. Into this picture, we then add a challenge of virtual
engines; one user engine that maps behind the scenes to any number of
physical engines. To keep it general, we want the user to have full
control over that mapping. To that end, we allow the user to constrain a
context to define the set of engines that it can access, order fully
controlled by the user via (class, instance). With such precise control
in context setup, we can continue to use the existing execbuf uABI of
specifying a single index; only now it doesn't automagically map onto
the engines, it uses the user defined engine map from the context.
v2: Fixup freeing of local on success of get_engines()
v3: Allow empty engines[]
v4: s/nengine/num_engines/
v5: Replace 64 limit on num_engines with a note that execbuf is
currently limited to only using the first 64 engines.
v6: Actually use the engines_mutex to guard the ctx->engines.
Testcase: igt/gem_ctx_engines
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190521211134.16117-2-chris@chris-wilson.co.uk
2019-05-22 05:11:26 +08:00
|
|
|
if (!!(flags & LOOKUP_USER_INDEX) != i915_gem_context_user_engines(ctx))
|
2019-04-27 00:33:32 +08:00
|
|
|
return ERR_PTR(-EINVAL);
|
|
|
|
|
drm/i915: Allow a context to define its set of engines
Over the last few years, we have debated how to extend the user API to
support an increase in the number of engines, that may be sparse and
even be heterogeneous within a class (not all video decoders created
equal). We settled on using (class, instance) tuples to identify a
specific engine, with an API for the user to construct a map of engines
to capabilities. Into this picture, we then add a challenge of virtual
engines; one user engine that maps behind the scenes to any number of
physical engines. To keep it general, we want the user to have full
control over that mapping. To that end, we allow the user to constrain a
context to define the set of engines that it can access, order fully
controlled by the user via (class, instance). With such precise control
in context setup, we can continue to use the existing execbuf uABI of
specifying a single index; only now it doesn't automagically map onto
the engines, it uses the user defined engine map from the context.
v2: Fixup freeing of local on success of get_engines()
v3: Allow empty engines[]
v4: s/nengine/num_engines/
v5: Replace 64 limit on num_engines with a note that execbuf is
currently limited to only using the first 64 engines.
v6: Actually use the engines_mutex to guard the ctx->engines.
Testcase: igt/gem_ctx_engines
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190521211134.16117-2-chris@chris-wilson.co.uk
2019-05-22 05:11:26 +08:00
|
|
|
if (!i915_gem_context_user_engines(ctx)) {
|
|
|
|
struct intel_engine_cs *engine;
|
|
|
|
|
|
|
|
engine = intel_engine_lookup_user(ctx->i915,
|
|
|
|
ci->engine_class,
|
|
|
|
ci->engine_instance);
|
|
|
|
if (!engine)
|
|
|
|
return ERR_PTR(-EINVAL);
|
|
|
|
|
2019-08-08 19:06:12 +08:00
|
|
|
idx = engine->legacy_idx;
|
drm/i915: Allow a context to define its set of engines
Over the last few years, we have debated how to extend the user API to
support an increase in the number of engines, that may be sparse and
even be heterogeneous within a class (not all video decoders created
equal). We settled on using (class, instance) tuples to identify a
specific engine, with an API for the user to construct a map of engines
to capabilities. Into this picture, we then add a challenge of virtual
engines; one user engine that maps behind the scenes to any number of
physical engines. To keep it general, we want the user to have full
control over that mapping. To that end, we allow the user to constrain a
context to define the set of engines that it can access, order fully
controlled by the user via (class, instance). With such precise control
in context setup, we can continue to use the existing execbuf uABI of
specifying a single index; only now it doesn't automagically map onto
the engines, it uses the user defined engine map from the context.
v2: Fixup freeing of local on success of get_engines()
v3: Allow empty engines[]
v4: s/nengine/num_engines/
v5: Replace 64 limit on num_engines with a note that execbuf is
currently limited to only using the first 64 engines.
v6: Actually use the engines_mutex to guard the ctx->engines.
Testcase: igt/gem_ctx_engines
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190521211134.16117-2-chris@chris-wilson.co.uk
2019-05-22 05:11:26 +08:00
|
|
|
} else {
|
|
|
|
idx = ci->engine_instance;
|
|
|
|
}
|
|
|
|
|
|
|
|
return i915_gem_context_get_engine(ctx, idx);
|
2019-04-27 00:33:32 +08:00
|
|
|
}
|
|
|
|
|
2019-11-06 17:13:12 +08:00
|
|
|
static struct i915_address_space *
|
|
|
|
context_get_vm_rcu(struct i915_gem_context *ctx)
|
|
|
|
{
|
|
|
|
GEM_BUG_ON(!rcu_access_pointer(ctx->vm));
|
|
|
|
|
|
|
|
do {
|
|
|
|
struct i915_address_space *vm;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We do not allow downgrading from full-ppgtt [to a shared
|
|
|
|
* global gtt], so ctx->vm cannot become NULL.
|
|
|
|
*/
|
|
|
|
vm = rcu_dereference(ctx->vm);
|
|
|
|
if (!kref_get_unless_zero(&vm->ref))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This ppgtt may have be reallocated between
|
|
|
|
* the read and the kref, and reassigned to a third
|
|
|
|
* context. In order to avoid inadvertent sharing
|
|
|
|
* of this ppgtt with that third context (and not
|
|
|
|
* src), we have to confirm that we have the same
|
|
|
|
* ppgtt after passing through the strong memory
|
|
|
|
* barrier implied by a successful
|
|
|
|
* kref_get_unless_zero().
|
|
|
|
*
|
|
|
|
* Once we have acquired the current ppgtt of ctx,
|
|
|
|
* we no longer care if it is released from ctx, as
|
|
|
|
* it cannot be reallocated elsewhere.
|
|
|
|
*/
|
|
|
|
|
|
|
|
if (vm == rcu_access_pointer(ctx->vm))
|
|
|
|
return rcu_pointer_handoff(vm);
|
|
|
|
|
|
|
|
i915_vm_put(vm);
|
|
|
|
} while (1);
|
|
|
|
}
|
|
|
|
|
2019-04-27 00:33:34 +08:00
|
|
|
static void __free_engines(struct i915_gem_engines *e, unsigned int count)
|
2012-06-05 05:42:43 +08:00
|
|
|
{
|
2019-04-27 00:33:34 +08:00
|
|
|
while (count--) {
|
|
|
|
if (!e->engines[count])
|
|
|
|
continue;
|
|
|
|
|
|
|
|
intel_context_put(e->engines[count]);
|
|
|
|
}
|
|
|
|
kfree(e);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void free_engines(struct i915_gem_engines *e)
|
|
|
|
{
|
|
|
|
__free_engines(e, e->num_engines);
|
|
|
|
}
|
|
|
|
|
2019-06-06 19:23:20 +08:00
|
|
|
static void free_engines_rcu(struct rcu_head *rcu)
|
drm/i915: Allow a context to define its set of engines
Over the last few years, we have debated how to extend the user API to
support an increase in the number of engines, that may be sparse and
even be heterogeneous within a class (not all video decoders created
equal). We settled on using (class, instance) tuples to identify a
specific engine, with an API for the user to construct a map of engines
to capabilities. Into this picture, we then add a challenge of virtual
engines; one user engine that maps behind the scenes to any number of
physical engines. To keep it general, we want the user to have full
control over that mapping. To that end, we allow the user to constrain a
context to define the set of engines that it can access, order fully
controlled by the user via (class, instance). With such precise control
in context setup, we can continue to use the existing execbuf uABI of
specifying a single index; only now it doesn't automagically map onto
the engines, it uses the user defined engine map from the context.
v2: Fixup freeing of local on success of get_engines()
v3: Allow empty engines[]
v4: s/nengine/num_engines/
v5: Replace 64 limit on num_engines with a note that execbuf is
currently limited to only using the first 64 engines.
v6: Actually use the engines_mutex to guard the ctx->engines.
Testcase: igt/gem_ctx_engines
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190521211134.16117-2-chris@chris-wilson.co.uk
2019-05-22 05:11:26 +08:00
|
|
|
{
|
2019-06-06 19:23:20 +08:00
|
|
|
free_engines(container_of(rcu, struct i915_gem_engines, rcu));
|
drm/i915: Allow a context to define its set of engines
Over the last few years, we have debated how to extend the user API to
support an increase in the number of engines, that may be sparse and
even be heterogeneous within a class (not all video decoders created
equal). We settled on using (class, instance) tuples to identify a
specific engine, with an API for the user to construct a map of engines
to capabilities. Into this picture, we then add a challenge of virtual
engines; one user engine that maps behind the scenes to any number of
physical engines. To keep it general, we want the user to have full
control over that mapping. To that end, we allow the user to constrain a
context to define the set of engines that it can access, order fully
controlled by the user via (class, instance). With such precise control
in context setup, we can continue to use the existing execbuf uABI of
specifying a single index; only now it doesn't automagically map onto
the engines, it uses the user defined engine map from the context.
v2: Fixup freeing of local on success of get_engines()
v3: Allow empty engines[]
v4: s/nengine/num_engines/
v5: Replace 64 limit on num_engines with a note that execbuf is
currently limited to only using the first 64 engines.
v6: Actually use the engines_mutex to guard the ctx->engines.
Testcase: igt/gem_ctx_engines
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190521211134.16117-2-chris@chris-wilson.co.uk
2019-05-22 05:11:26 +08:00
|
|
|
}
|
|
|
|
|
2019-04-27 00:33:34 +08:00
|
|
|
static struct i915_gem_engines *default_engines(struct i915_gem_context *ctx)
|
|
|
|
{
|
2019-08-08 19:06:12 +08:00
|
|
|
const struct intel_gt *gt = &ctx->i915->gt;
|
2019-04-27 00:33:34 +08:00
|
|
|
struct intel_engine_cs *engine;
|
|
|
|
struct i915_gem_engines *e;
|
|
|
|
enum intel_engine_id id;
|
|
|
|
|
|
|
|
e = kzalloc(struct_size(e, engines, I915_NUM_ENGINES), GFP_KERNEL);
|
|
|
|
if (!e)
|
|
|
|
return ERR_PTR(-ENOMEM);
|
|
|
|
|
2019-06-06 19:23:20 +08:00
|
|
|
init_rcu_head(&e->rcu);
|
2019-08-08 19:06:12 +08:00
|
|
|
for_each_engine(engine, gt, id) {
|
2019-04-27 00:33:34 +08:00
|
|
|
struct intel_context *ce;
|
|
|
|
|
2019-10-18 00:18:52 +08:00
|
|
|
if (engine->legacy_idx == INVALID_ENGINE)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
GEM_BUG_ON(engine->legacy_idx >= I915_NUM_ENGINES);
|
|
|
|
GEM_BUG_ON(e->engines[engine->legacy_idx]);
|
|
|
|
|
2019-04-27 00:33:34 +08:00
|
|
|
ce = intel_context_create(ctx, engine);
|
|
|
|
if (IS_ERR(ce)) {
|
2019-10-18 00:18:52 +08:00
|
|
|
__free_engines(e, e->num_engines + 1);
|
2019-04-27 00:33:34 +08:00
|
|
|
return ERR_CAST(ce);
|
|
|
|
}
|
2012-06-05 05:42:43 +08:00
|
|
|
|
2019-10-18 00:18:52 +08:00
|
|
|
e->engines[engine->legacy_idx] = ce;
|
|
|
|
e->num_engines = max(e->num_engines, engine->legacy_idx);
|
2019-04-27 00:33:34 +08:00
|
|
|
}
|
2019-10-18 00:18:52 +08:00
|
|
|
e->num_engines++;
|
2019-04-27 00:33:34 +08:00
|
|
|
|
|
|
|
return e;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void i915_gem_context_free(struct i915_gem_context *ctx)
|
|
|
|
{
|
2016-12-31 19:20:11 +08:00
|
|
|
GEM_BUG_ON(!i915_gem_context_is_closed(ctx));
|
2014-11-10 21:44:31 +08:00
|
|
|
|
2019-10-04 21:40:09 +08:00
|
|
|
spin_lock(&ctx->i915->gem.contexts.lock);
|
|
|
|
list_del(&ctx->link);
|
|
|
|
spin_unlock(&ctx->i915->gem.contexts.lock);
|
|
|
|
|
2019-04-27 00:33:34 +08:00
|
|
|
free_engines(rcu_access_pointer(ctx->engines));
|
|
|
|
mutex_destroy(&ctx->engines_mutex);
|
2016-05-24 21:53:41 +08:00
|
|
|
|
2019-03-22 17:23:25 +08:00
|
|
|
if (ctx->timeline)
|
2019-06-21 15:08:10 +08:00
|
|
|
intel_timeline_put(ctx->timeline);
|
2019-03-22 17:23:25 +08:00
|
|
|
|
2016-08-15 17:49:08 +08:00
|
|
|
put_pid(ctx->pid);
|
2019-03-08 21:25:16 +08:00
|
|
|
mutex_destroy(&ctx->mutex);
|
2016-04-28 16:56:51 +08:00
|
|
|
|
2017-06-20 19:05:47 +08:00
|
|
|
kfree_rcu(ctx, rcu);
|
2012-06-05 05:42:43 +08:00
|
|
|
}
|
|
|
|
|
2019-10-04 21:40:09 +08:00
|
|
|
static void contexts_free_all(struct llist_node *list)
|
2017-06-20 19:05:46 +08:00
|
|
|
{
|
2017-07-01 07:05:17 +08:00
|
|
|
struct i915_gem_context *ctx, *cn;
|
2017-06-20 19:05:46 +08:00
|
|
|
|
2019-10-04 21:40:09 +08:00
|
|
|
llist_for_each_entry_safe(ctx, cn, list, free_link)
|
2017-06-20 19:05:46 +08:00
|
|
|
i915_gem_context_free(ctx);
|
|
|
|
}
|
|
|
|
|
2019-10-04 21:40:09 +08:00
|
|
|
static void contexts_flush_free(struct i915_gem_contexts *gc)
|
2017-07-05 22:26:34 +08:00
|
|
|
{
|
2019-10-04 21:40:09 +08:00
|
|
|
contexts_free_all(llist_del_all(&gc->free_list));
|
2017-07-05 22:26:34 +08:00
|
|
|
}
|
|
|
|
|
2017-06-20 19:05:46 +08:00
|
|
|
static void contexts_free_worker(struct work_struct *work)
|
|
|
|
{
|
2019-10-04 21:40:09 +08:00
|
|
|
struct i915_gem_contexts *gc =
|
|
|
|
container_of(work, typeof(*gc), free_work);
|
2017-06-20 19:05:46 +08:00
|
|
|
|
2019-10-04 21:40:09 +08:00
|
|
|
contexts_flush_free(gc);
|
2017-06-20 19:05:46 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
void i915_gem_context_release(struct kref *ref)
|
|
|
|
{
|
|
|
|
struct i915_gem_context *ctx = container_of(ref, typeof(*ctx), ref);
|
2019-10-04 21:40:09 +08:00
|
|
|
struct i915_gem_contexts *gc = &ctx->i915->gem.contexts;
|
2017-06-20 19:05:46 +08:00
|
|
|
|
|
|
|
trace_i915_context_free(ctx);
|
2019-10-04 21:40:09 +08:00
|
|
|
if (llist_add(&ctx->free_link, &gc->free_list))
|
|
|
|
schedule_work(&gc->free_work);
|
2017-06-20 19:05:46 +08:00
|
|
|
}
|
|
|
|
|
2019-10-23 21:31:07 +08:00
|
|
|
static inline struct i915_gem_engines *
|
|
|
|
__context_engines_static(const struct i915_gem_context *ctx)
|
|
|
|
{
|
|
|
|
return rcu_dereference_protected(ctx->engines, true);
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool __reset_engine(struct intel_engine_cs *engine)
|
|
|
|
{
|
|
|
|
struct intel_gt *gt = engine->gt;
|
|
|
|
bool success = false;
|
|
|
|
|
|
|
|
if (!intel_has_reset_engine(gt))
|
|
|
|
return false;
|
|
|
|
|
|
|
|
if (!test_and_set_bit(I915_RESET_ENGINE + engine->id,
|
|
|
|
>->reset.flags)) {
|
|
|
|
success = intel_engine_reset(engine, NULL) == 0;
|
|
|
|
clear_and_wake_up_bit(I915_RESET_ENGINE + engine->id,
|
|
|
|
>->reset.flags);
|
|
|
|
}
|
|
|
|
|
|
|
|
return success;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void __reset_context(struct i915_gem_context *ctx,
|
|
|
|
struct intel_engine_cs *engine)
|
|
|
|
{
|
|
|
|
intel_gt_handle_error(engine->gt, engine->mask, 0,
|
|
|
|
"context closure in %s", ctx->name);
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool __cancel_engine(struct intel_engine_cs *engine)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Send a "high priority pulse" down the engine to cause the
|
|
|
|
* current request to be momentarily preempted. (If it fails to
|
|
|
|
* be preempted, it will be reset). As we have marked our context
|
|
|
|
* as banned, any incomplete request, including any running, will
|
|
|
|
* be skipped following the preemption.
|
|
|
|
*
|
|
|
|
* If there is no hangchecking (one of the reasons why we try to
|
|
|
|
* cancel the context) and no forced preemption, there may be no
|
|
|
|
* means by which we reset the GPU and evict the persistent hog.
|
|
|
|
* Ergo if we are unable to inject a preemptive pulse that can
|
|
|
|
* kill the banned context, we fallback to doing a local reset
|
|
|
|
* instead.
|
|
|
|
*/
|
2019-10-25 21:59:42 +08:00
|
|
|
if (IS_ACTIVE(CONFIG_DRM_I915_PREEMPT_TIMEOUT) &&
|
|
|
|
!intel_engine_pulse(engine))
|
2019-10-23 21:31:07 +08:00
|
|
|
return true;
|
|
|
|
|
|
|
|
/* If we are unable to send a pulse, try resetting this engine. */
|
|
|
|
return __reset_engine(engine);
|
|
|
|
}
|
|
|
|
|
2019-10-31 17:01:04 +08:00
|
|
|
static struct intel_engine_cs *__active_engine(struct i915_request *rq)
|
2019-10-23 21:31:07 +08:00
|
|
|
{
|
|
|
|
struct intel_engine_cs *engine, *locked;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Serialise with __i915_request_submit() so that it sees
|
|
|
|
* is-banned?, or we know the request is already inflight.
|
|
|
|
*/
|
|
|
|
locked = READ_ONCE(rq->engine);
|
|
|
|
spin_lock_irq(&locked->active.lock);
|
|
|
|
while (unlikely(locked != (engine = READ_ONCE(rq->engine)))) {
|
|
|
|
spin_unlock(&locked->active.lock);
|
|
|
|
spin_lock(&engine->active.lock);
|
|
|
|
locked = engine;
|
|
|
|
}
|
|
|
|
|
|
|
|
engine = NULL;
|
|
|
|
if (i915_request_is_active(rq) && !rq->fence.error)
|
|
|
|
engine = rq->engine;
|
|
|
|
|
|
|
|
spin_unlock_irq(&locked->active.lock);
|
|
|
|
|
|
|
|
return engine;
|
|
|
|
}
|
|
|
|
|
2019-10-31 17:01:04 +08:00
|
|
|
static struct intel_engine_cs *active_engine(struct intel_context *ce)
|
|
|
|
{
|
|
|
|
struct intel_engine_cs *engine = NULL;
|
|
|
|
struct i915_request *rq;
|
|
|
|
|
|
|
|
if (!ce->timeline)
|
|
|
|
return NULL;
|
|
|
|
|
2019-11-29 23:18:45 +08:00
|
|
|
mutex_lock(&ce->timeline->mutex);
|
2019-10-31 17:01:04 +08:00
|
|
|
list_for_each_entry_reverse(rq, &ce->timeline->requests, link) {
|
|
|
|
if (i915_request_completed(rq))
|
|
|
|
break;
|
|
|
|
|
|
|
|
/* Check with the backend if the request is inflight */
|
|
|
|
engine = __active_engine(rq);
|
|
|
|
if (engine)
|
|
|
|
break;
|
|
|
|
}
|
2019-11-29 23:18:45 +08:00
|
|
|
mutex_unlock(&ce->timeline->mutex);
|
2019-10-31 17:01:04 +08:00
|
|
|
|
|
|
|
return engine;
|
|
|
|
}
|
|
|
|
|
2019-10-23 21:31:07 +08:00
|
|
|
static void kill_context(struct i915_gem_context *ctx)
|
|
|
|
{
|
|
|
|
struct i915_gem_engines_iter it;
|
|
|
|
struct intel_context *ce;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If we are already banned, it was due to a guilty request causing
|
|
|
|
* a reset and the entire context being evicted from the GPU.
|
|
|
|
*/
|
|
|
|
if (i915_gem_context_is_banned(ctx))
|
|
|
|
return;
|
|
|
|
|
|
|
|
i915_gem_context_set_banned(ctx);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Map the user's engine back to the actual engines; one virtual
|
|
|
|
* engine will be mapped to multiple engines, and using ctx->engine[]
|
|
|
|
* the same engine may be have multiple instances in the user's map.
|
|
|
|
* However, we only care about pending requests, so only include
|
|
|
|
* engines on which there are incomplete requests.
|
|
|
|
*/
|
|
|
|
for_each_gem_engine(ce, __context_engines_static(ctx), it) {
|
|
|
|
struct intel_engine_cs *engine;
|
|
|
|
|
2019-10-31 17:01:04 +08:00
|
|
|
/*
|
|
|
|
* Check the current active state of this context; if we
|
|
|
|
* are currently executing on the GPU we need to evict
|
|
|
|
* ourselves. On the other hand, if we haven't yet been
|
|
|
|
* submitted to the GPU or if everything is complete,
|
|
|
|
* we have nothing to do.
|
|
|
|
*/
|
|
|
|
engine = active_engine(ce);
|
2019-10-23 21:31:07 +08:00
|
|
|
|
|
|
|
/* First attempt to gracefully cancel the context */
|
|
|
|
if (engine && !__cancel_engine(engine))
|
|
|
|
/*
|
|
|
|
* If we are unable to send a preemptive pulse to bump
|
|
|
|
* the context from the GPU, we have to resort to a full
|
|
|
|
* reset. We hope the collateral damage is worth it.
|
|
|
|
*/
|
|
|
|
__reset_context(ctx, engine);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2019-11-11 19:43:21 +08:00
|
|
|
static void set_closed_name(struct i915_gem_context *ctx)
|
|
|
|
{
|
|
|
|
char *s;
|
|
|
|
|
|
|
|
/* Replace '[]' with '<>' to indicate closed in debug prints */
|
|
|
|
|
|
|
|
s = strrchr(ctx->name, '[');
|
|
|
|
if (!s)
|
|
|
|
return;
|
|
|
|
|
|
|
|
*s = '<';
|
|
|
|
|
|
|
|
s = strchr(s + 1, ']');
|
|
|
|
if (s)
|
|
|
|
*s = '>';
|
|
|
|
}
|
|
|
|
|
2016-08-04 14:52:46 +08:00
|
|
|
static void context_close(struct i915_gem_context *ctx)
|
|
|
|
{
|
2019-10-04 21:40:09 +08:00
|
|
|
struct i915_address_space *vm;
|
drm/i915: Pull i915_vma_pin under the vm->mutex
Replace the struct_mutex requirement for pinning the i915_vma with the
local vm->mutex instead. Note that the vm->mutex is tainted by the
shrinker (we require unbinding from inside fs-reclaim) and so we cannot
allocate while holding that mutex. Instead we have to preallocate
workers to do allocate and apply the PTE updates after we have we
reserved their slot in the drm_mm (using fences to order the PTE writes
with the GPU work and with later unbind).
In adding the asynchronous vma binding, one subtle requirement is to
avoid coupling the binding fence into the backing object->resv. That is
the asynchronous binding only applies to the vma timeline itself and not
to the pages as that is a more global timeline (the binding of one vma
does not need to be ordered with another vma, nor does the implicit GEM
fencing depend on a vma, only on writes to the backing store). Keeping
the vma binding distinct from the backing store timelines is verified by
a number of async gem_exec_fence and gem_exec_schedule tests. The way we
do this is quite simple, we keep the fence for the vma binding separate
and only wait on it as required, and never add it to the obj->resv
itself.
Another consequence in reducing the locking around the vma is the
destruction of the vma is no longer globally serialised by struct_mutex.
A natural solution would be to add a kref to i915_vma, but that requires
decoupling the reference cycles, possibly by introducing a new
i915_mm_pages object that is own by both obj->mm and vma->pages.
However, we have not taken that route due to the overshadowing lmem/ttm
discussions, and instead play a series of complicated games with
trylocks to (hopefully) ensure that only one destruction path is called!
v2: Add some commentary, and some helpers to reduce patch churn.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191004134015.13204-4-chris@chris-wilson.co.uk
2019-10-04 21:39:58 +08:00
|
|
|
|
2019-10-04 21:40:09 +08:00
|
|
|
i915_gem_context_set_closed(ctx);
|
2019-11-11 19:43:21 +08:00
|
|
|
set_closed_name(ctx);
|
drm/i915: Pull i915_vma_pin under the vm->mutex
Replace the struct_mutex requirement for pinning the i915_vma with the
local vm->mutex instead. Note that the vm->mutex is tainted by the
shrinker (we require unbinding from inside fs-reclaim) and so we cannot
allocate while holding that mutex. Instead we have to preallocate
workers to do allocate and apply the PTE updates after we have we
reserved their slot in the drm_mm (using fences to order the PTE writes
with the GPU work and with later unbind).
In adding the asynchronous vma binding, one subtle requirement is to
avoid coupling the binding fence into the backing object->resv. That is
the asynchronous binding only applies to the vma timeline itself and not
to the pages as that is a more global timeline (the binding of one vma
does not need to be ordered with another vma, nor does the implicit GEM
fencing depend on a vma, only on writes to the backing store). Keeping
the vma binding distinct from the backing store timelines is verified by
a number of async gem_exec_fence and gem_exec_schedule tests. The way we
do this is quite simple, we keep the fence for the vma binding separate
and only wait on it as required, and never add it to the obj->resv
itself.
Another consequence in reducing the locking around the vma is the
destruction of the vma is no longer globally serialised by struct_mutex.
A natural solution would be to add a kref to i915_vma, but that requires
decoupling the reference cycles, possibly by introducing a new
i915_mm_pages object that is own by both obj->mm and vma->pages.
However, we have not taken that route due to the overshadowing lmem/ttm
discussions, and instead play a series of complicated games with
trylocks to (hopefully) ensure that only one destruction path is called!
v2: Add some commentary, and some helpers to reduce patch churn.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191004134015.13204-4-chris@chris-wilson.co.uk
2019-10-04 21:39:58 +08:00
|
|
|
|
2019-06-06 19:23:20 +08:00
|
|
|
mutex_lock(&ctx->mutex);
|
|
|
|
|
2019-10-04 21:40:09 +08:00
|
|
|
vm = i915_gem_context_vm(ctx);
|
|
|
|
if (vm)
|
|
|
|
i915_vm_close(vm);
|
|
|
|
|
2019-06-06 19:23:20 +08:00
|
|
|
ctx->file_priv = ERR_PTR(-EBADF);
|
2017-08-16 16:52:08 +08:00
|
|
|
|
2017-11-09 16:55:40 +08:00
|
|
|
/*
|
|
|
|
* The LUT uses the VMA as a backpointer to unref the object,
|
|
|
|
* so we need to clear the LUT before we close all the VMA (inside
|
|
|
|
* the ppgtt).
|
|
|
|
*/
|
2017-08-16 16:52:08 +08:00
|
|
|
lut_close(ctx);
|
|
|
|
|
2019-06-06 19:23:20 +08:00
|
|
|
mutex_unlock(&ctx->mutex);
|
2019-10-23 21:31:07 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* If the user has disabled hangchecking, we can not be sure that
|
|
|
|
* the batches will ever complete after the context is closed,
|
|
|
|
* keeping the context and all resources pinned forever. So in this
|
|
|
|
* case we opt to forcibly kill off all remaining requests on
|
|
|
|
* context close.
|
|
|
|
*/
|
drm/i915/gem: Make context persistence optional
Our existing behaviour is to allow contexts and their GPU requests to
persist past the point of closure until the requests are complete. This
allows clients to operate in a 'fire-and-forget' manner where they can
setup a rendering pipeline and hand it over to the display server and
immediately exit. As the rendering pipeline is kept alive until
completion, the display server (or other consumer) can use the results
in the future and present them to the user.
The compute model is a little different. They have little to no buffer
sharing between processes as their kernels tend to operate on a
continuous stream, feeding the results back to the client application.
These kernels operate for an indeterminate length of time, with many
clients wishing that the kernel was always running for as long as they
keep feeding in the data, i.e. acting like a DSP.
Not all clients want this persistent "desktop" behaviour and would prefer
that the contexts are cleaned up immediately upon closure. This ensures
that when clients are run without hangchecking (e.g. for compute kernels
of indeterminate runtime), any GPU hang or other unexpected workloads
are terminated with the process and does not continue to hog resources.
The default behaviour for new contexts is the legacy persistence mode,
as some desktop applications are dependent upon the existing behaviour.
New clients will have to opt in to immediate cleanup on context
closure. If the hangchecking modparam is disabled, so is persistent
context support -- all contexts will be terminated on closure.
We expect this behaviour change to be welcomed by compute users, who
have often been caught between a rock and a hard place. They disable
hangchecking to avoid their kernels being "unfairly" declared hung, but
have also experienced true hangs that the system was then unable to
clean up. Naturally, this leads to bug reports.
Testcase: igt/gem_ctx_persistence
Link: https://github.com/intel/compute-runtime/pull/228
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Jon Bloomfield <jon.bloomfield@intel.com>
Reviewed-by: Jon Bloomfield <jon.bloomfield@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: Jason Ekstrand <jason@jlekstrand.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20191029202338.8841-1-chris@chris-wilson.co.uk
2019-10-30 04:23:38 +08:00
|
|
|
if (!i915_gem_context_is_persistent(ctx) ||
|
|
|
|
!i915_modparams.enable_hangcheck)
|
2019-10-23 21:31:07 +08:00
|
|
|
kill_context(ctx);
|
|
|
|
|
2016-08-04 14:52:46 +08:00
|
|
|
i915_gem_context_put(ctx);
|
|
|
|
}
|
|
|
|
|
drm/i915/gem: Make context persistence optional
Our existing behaviour is to allow contexts and their GPU requests to
persist past the point of closure until the requests are complete. This
allows clients to operate in a 'fire-and-forget' manner where they can
setup a rendering pipeline and hand it over to the display server and
immediately exit. As the rendering pipeline is kept alive until
completion, the display server (or other consumer) can use the results
in the future and present them to the user.
The compute model is a little different. They have little to no buffer
sharing between processes as their kernels tend to operate on a
continuous stream, feeding the results back to the client application.
These kernels operate for an indeterminate length of time, with many
clients wishing that the kernel was always running for as long as they
keep feeding in the data, i.e. acting like a DSP.
Not all clients want this persistent "desktop" behaviour and would prefer
that the contexts are cleaned up immediately upon closure. This ensures
that when clients are run without hangchecking (e.g. for compute kernels
of indeterminate runtime), any GPU hang or other unexpected workloads
are terminated with the process and does not continue to hog resources.
The default behaviour for new contexts is the legacy persistence mode,
as some desktop applications are dependent upon the existing behaviour.
New clients will have to opt in to immediate cleanup on context
closure. If the hangchecking modparam is disabled, so is persistent
context support -- all contexts will be terminated on closure.
We expect this behaviour change to be welcomed by compute users, who
have often been caught between a rock and a hard place. They disable
hangchecking to avoid their kernels being "unfairly" declared hung, but
have also experienced true hangs that the system was then unable to
clean up. Naturally, this leads to bug reports.
Testcase: igt/gem_ctx_persistence
Link: https://github.com/intel/compute-runtime/pull/228
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Jon Bloomfield <jon.bloomfield@intel.com>
Reviewed-by: Jon Bloomfield <jon.bloomfield@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: Jason Ekstrand <jason@jlekstrand.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20191029202338.8841-1-chris@chris-wilson.co.uk
2019-10-30 04:23:38 +08:00
|
|
|
static int __context_set_persistence(struct i915_gem_context *ctx, bool state)
|
|
|
|
{
|
|
|
|
if (i915_gem_context_is_persistent(ctx) == state)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
if (state) {
|
|
|
|
/*
|
|
|
|
* Only contexts that are short-lived [that will expire or be
|
|
|
|
* reset] are allowed to survive past termination. We require
|
|
|
|
* hangcheck to ensure that the persistent requests are healthy.
|
|
|
|
*/
|
|
|
|
if (!i915_modparams.enable_hangcheck)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
i915_gem_context_set_persistence(ctx);
|
|
|
|
} else {
|
|
|
|
/* To cancel a context we use "preempt-to-idle" */
|
|
|
|
if (!(ctx->i915->caps.scheduler & I915_SCHEDULER_CAP_PREEMPTION))
|
|
|
|
return -ENODEV;
|
|
|
|
|
|
|
|
i915_gem_context_clear_persistence(ctx);
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2016-05-24 21:53:34 +08:00
|
|
|
static struct i915_gem_context *
|
2019-06-11 17:12:37 +08:00
|
|
|
__create_context(struct drm_i915_private *i915)
|
2012-06-05 05:42:43 +08:00
|
|
|
{
|
2016-05-24 21:53:34 +08:00
|
|
|
struct i915_gem_context *ctx;
|
2019-04-27 00:33:34 +08:00
|
|
|
struct i915_gem_engines *e;
|
|
|
|
int err;
|
drm/i915: Use time based guilty context banning
Currently, we accumulate each time a context hangs the GPU, offset
against the number of requests it submits, and if that score exceeds a
certain threshold, we ban that context from submitting any more requests
(cancelling any work in flight). In contrast, we use a simple timer on
the file, that if we see more than a 9 hangs faster than 60s apart in
total across all of its contexts, we will ban the client from creating
any more contexts. This leads to a confusing situation where the file
may be banned before the context, so lets use a simple timer scheme for
each.
If the context submits 3 hanging requests within a 120s period, declare
it forbidden to ever send more requests.
This has the advantage of not being easy to repair by simply sending
empty requests, but has the disadvantage that if the context is idle
then it is forgiven. However, if the context is idle, it is not
disrupting the system, but a hog can evade the request counting and
cause much more severe disruption to the system.
Updating ban_score from request retirement is dubious as the retirement
is purposely not in sync with request submission (i.e. we try and batch
retirement to reduce overhead and avoid latency on submission), which
leads to surprising situations where we can forgive a hang immediately
due to a backlog of requests from before the hang being retired
afterwards.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190219122215.8941-2-chris@chris-wilson.co.uk
2019-02-19 20:21:52 +08:00
|
|
|
int i;
|
2012-06-05 05:42:43 +08:00
|
|
|
|
2012-11-11 02:56:04 +08:00
|
|
|
ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
|
2019-03-21 22:07:08 +08:00
|
|
|
if (!ctx)
|
2012-06-30 01:30:39 +08:00
|
|
|
return ERR_PTR(-ENOMEM);
|
2012-06-05 05:42:43 +08:00
|
|
|
|
2013-04-30 18:30:33 +08:00
|
|
|
kref_init(&ctx->ref);
|
2019-06-11 17:12:37 +08:00
|
|
|
ctx->i915 = i915;
|
2018-10-01 20:32:03 +08:00
|
|
|
ctx->sched.priority = I915_USER_PRIORITY(I915_PRIORITY_NORMAL);
|
2019-03-08 21:25:16 +08:00
|
|
|
mutex_init(&ctx->mutex);
|
2012-06-05 05:42:43 +08:00
|
|
|
|
2019-04-27 00:33:34 +08:00
|
|
|
mutex_init(&ctx->engines_mutex);
|
|
|
|
e = default_engines(ctx);
|
|
|
|
if (IS_ERR(e)) {
|
|
|
|
err = PTR_ERR(e);
|
|
|
|
goto err_free;
|
|
|
|
}
|
|
|
|
RCU_INIT_POINTER(ctx->engines, e);
|
2018-05-18 05:26:32 +08:00
|
|
|
|
2017-08-16 16:52:08 +08:00
|
|
|
INIT_RADIX_TREE(&ctx->handles_vma, GFP_KERNEL);
|
2017-06-16 22:05:16 +08:00
|
|
|
|
drm/i915: Do remaps for all contexts
On both Ivybridge and Haswell, row remapping information is saved and
restored with context. This means, we never actually properly supported
the l3 remapping because our sysfs interface is asynchronous (and not
tied to any context), and the known faulty HW would be reused by the
next context to run.
Not that due to the asynchronous nature of the sysfs entry, there is no
point modifying the registers for the existing context. Instead we set a
flag for all contexts to load the correct remapping information on the
next run. Interested clients can use debugfs to determine whether or not
the row has been remapped.
One could propose at this point that we just do the remapping in the
kernel. I guess since we have to maintain the sysfs interface anyway,
I'm not sure how useful it is, and I do like keeping the policy in
userspace; (it wasn't my original decision to make the
interface the way it is, so I'm not attached).
v2: Force a context switch when we have a remap on the next switch.
(Ville)
Don't let userspace use the interface with disabled contexts.
v3: Don't force a context switch, just let it nop
Improper context slice remap initialization, 1<<1 instead of 1<<i, but I
rewrote it to avoid a second round of confusion.
Error print moved to error path (All Ville)
Added a comment on why the slice remap initialization happens.
CC: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-09-19 10:03:18 +08:00
|
|
|
/* NB: Mark all slices as needing a remap so that when the context first
|
|
|
|
* loads it will restore whatever remap state already exists. If there
|
|
|
|
* is no remap info, it will be a NOP. */
|
2019-06-11 17:12:37 +08:00
|
|
|
ctx->remap_slice = ALL_L3_SLICES(i915);
|
2012-06-05 05:42:43 +08:00
|
|
|
|
2016-12-31 19:20:11 +08:00
|
|
|
i915_gem_context_set_bannable(ctx);
|
2019-02-18 18:58:21 +08:00
|
|
|
i915_gem_context_set_recoverable(ctx);
|
drm/i915/gem: Make context persistence optional
Our existing behaviour is to allow contexts and their GPU requests to
persist past the point of closure until the requests are complete. This
allows clients to operate in a 'fire-and-forget' manner where they can
setup a rendering pipeline and hand it over to the display server and
immediately exit. As the rendering pipeline is kept alive until
completion, the display server (or other consumer) can use the results
in the future and present them to the user.
The compute model is a little different. They have little to no buffer
sharing between processes as their kernels tend to operate on a
continuous stream, feeding the results back to the client application.
These kernels operate for an indeterminate length of time, with many
clients wishing that the kernel was always running for as long as they
keep feeding in the data, i.e. acting like a DSP.
Not all clients want this persistent "desktop" behaviour and would prefer
that the contexts are cleaned up immediately upon closure. This ensures
that when clients are run without hangchecking (e.g. for compute kernels
of indeterminate runtime), any GPU hang or other unexpected workloads
are terminated with the process and does not continue to hog resources.
The default behaviour for new contexts is the legacy persistence mode,
as some desktop applications are dependent upon the existing behaviour.
New clients will have to opt in to immediate cleanup on context
closure. If the hangchecking modparam is disabled, so is persistent
context support -- all contexts will be terminated on closure.
We expect this behaviour change to be welcomed by compute users, who
have often been caught between a rock and a hard place. They disable
hangchecking to avoid their kernels being "unfairly" declared hung, but
have also experienced true hangs that the system was then unable to
clean up. Naturally, this leads to bug reports.
Testcase: igt/gem_ctx_persistence
Link: https://github.com/intel/compute-runtime/pull/228
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Jon Bloomfield <jon.bloomfield@intel.com>
Reviewed-by: Jon Bloomfield <jon.bloomfield@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: Jason Ekstrand <jason@jlekstrand.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20191029202338.8841-1-chris@chris-wilson.co.uk
2019-10-30 04:23:38 +08:00
|
|
|
__context_set_persistence(ctx, true /* cgroup hook? */);
|
2019-02-18 18:58:21 +08:00
|
|
|
|
drm/i915: Use time based guilty context banning
Currently, we accumulate each time a context hangs the GPU, offset
against the number of requests it submits, and if that score exceeds a
certain threshold, we ban that context from submitting any more requests
(cancelling any work in flight). In contrast, we use a simple timer on
the file, that if we see more than a 9 hangs faster than 60s apart in
total across all of its contexts, we will ban the client from creating
any more contexts. This leads to a confusing situation where the file
may be banned before the context, so lets use a simple timer scheme for
each.
If the context submits 3 hanging requests within a 120s period, declare
it forbidden to ever send more requests.
This has the advantage of not being easy to repair by simply sending
empty requests, but has the disadvantage that if the context is idle
then it is forgiven. However, if the context is idle, it is not
disrupting the system, but a hog can evade the request counting and
cause much more severe disruption to the system.
Updating ban_score from request retirement is dubious as the retirement
is purposely not in sync with request submission (i.e. we try and batch
retirement to reduce overhead and avoid latency on submission), which
leads to surprising situations where we can forgive a hang immediately
due to a backlog of requests from before the hang being retired
afterwards.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190219122215.8941-2-chris@chris-wilson.co.uk
2019-02-19 20:21:52 +08:00
|
|
|
for (i = 0; i < ARRAY_SIZE(ctx->hang_timestamp); i++)
|
|
|
|
ctx->hang_timestamp[i] = jiffies - CONTEXT_FAST_HANG_JIFFIES;
|
|
|
|
|
2019-10-04 21:40:09 +08:00
|
|
|
spin_lock(&i915->gem.contexts.lock);
|
|
|
|
list_add_tail(&ctx->link, &i915->gem.contexts.list);
|
|
|
|
spin_unlock(&i915->gem.contexts.lock);
|
|
|
|
|
2012-06-30 01:30:39 +08:00
|
|
|
return ctx;
|
2019-04-27 00:33:34 +08:00
|
|
|
|
|
|
|
err_free:
|
|
|
|
kfree(ctx);
|
|
|
|
return ERR_PTR(err);
|
2017-02-09 19:34:25 +08:00
|
|
|
}
|
|
|
|
|
2019-08-10 02:25:17 +08:00
|
|
|
static void
|
|
|
|
context_apply_all(struct i915_gem_context *ctx,
|
|
|
|
void (*fn)(struct intel_context *ce, void *data),
|
|
|
|
void *data)
|
|
|
|
{
|
|
|
|
struct i915_gem_engines_iter it;
|
|
|
|
struct intel_context *ce;
|
|
|
|
|
|
|
|
for_each_gem_engine(ce, i915_gem_context_lock_engines(ctx), it)
|
|
|
|
fn(ce, data);
|
|
|
|
i915_gem_context_unlock_engines(ctx);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void __apply_ppgtt(struct intel_context *ce, void *vm)
|
|
|
|
{
|
|
|
|
i915_vm_put(ce->vm);
|
|
|
|
ce->vm = i915_vm_get(vm);
|
|
|
|
}
|
|
|
|
|
2019-06-11 17:12:37 +08:00
|
|
|
static struct i915_address_space *
|
|
|
|
__set_ppgtt(struct i915_gem_context *ctx, struct i915_address_space *vm)
|
2019-03-22 17:23:23 +08:00
|
|
|
{
|
2019-10-04 21:40:09 +08:00
|
|
|
struct i915_address_space *old = i915_gem_context_vm(ctx);
|
2019-03-22 17:23:23 +08:00
|
|
|
|
2019-07-30 21:30:26 +08:00
|
|
|
GEM_BUG_ON(old && i915_vm_is_4lvl(vm) != i915_vm_is_4lvl(old));
|
|
|
|
|
2019-10-04 21:40:09 +08:00
|
|
|
rcu_assign_pointer(ctx->vm, i915_vm_open(vm));
|
2019-08-10 02:25:17 +08:00
|
|
|
context_apply_all(ctx, __apply_ppgtt, vm);
|
2019-07-30 22:32:09 +08:00
|
|
|
|
2019-03-22 17:23:23 +08:00
|
|
|
return old;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void __assign_ppgtt(struct i915_gem_context *ctx,
|
2019-06-11 17:12:37 +08:00
|
|
|
struct i915_address_space *vm)
|
2019-03-22 17:23:23 +08:00
|
|
|
{
|
2019-10-04 21:40:09 +08:00
|
|
|
if (vm == rcu_access_pointer(ctx->vm))
|
2019-03-22 17:23:23 +08:00
|
|
|
return;
|
|
|
|
|
2019-06-11 17:12:37 +08:00
|
|
|
vm = __set_ppgtt(ctx, vm);
|
|
|
|
if (vm)
|
drm/i915: Pull i915_vma_pin under the vm->mutex
Replace the struct_mutex requirement for pinning the i915_vma with the
local vm->mutex instead. Note that the vm->mutex is tainted by the
shrinker (we require unbinding from inside fs-reclaim) and so we cannot
allocate while holding that mutex. Instead we have to preallocate
workers to do allocate and apply the PTE updates after we have we
reserved their slot in the drm_mm (using fences to order the PTE writes
with the GPU work and with later unbind).
In adding the asynchronous vma binding, one subtle requirement is to
avoid coupling the binding fence into the backing object->resv. That is
the asynchronous binding only applies to the vma timeline itself and not
to the pages as that is a more global timeline (the binding of one vma
does not need to be ordered with another vma, nor does the implicit GEM
fencing depend on a vma, only on writes to the backing store). Keeping
the vma binding distinct from the backing store timelines is verified by
a number of async gem_exec_fence and gem_exec_schedule tests. The way we
do this is quite simple, we keep the fence for the vma binding separate
and only wait on it as required, and never add it to the obj->resv
itself.
Another consequence in reducing the locking around the vma is the
destruction of the vma is no longer globally serialised by struct_mutex.
A natural solution would be to add a kref to i915_vma, but that requires
decoupling the reference cycles, possibly by introducing a new
i915_mm_pages object that is own by both obj->mm and vma->pages.
However, we have not taken that route due to the overshadowing lmem/ttm
discussions, and instead play a series of complicated games with
trylocks to (hopefully) ensure that only one destruction path is called!
v2: Add some commentary, and some helpers to reduce patch churn.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191004134015.13204-4-chris@chris-wilson.co.uk
2019-10-04 21:39:58 +08:00
|
|
|
i915_vm_close(vm);
|
2019-03-22 17:23:23 +08:00
|
|
|
}
|
|
|
|
|
2019-08-10 02:25:18 +08:00
|
|
|
static void __set_timeline(struct intel_timeline **dst,
|
|
|
|
struct intel_timeline *src)
|
|
|
|
{
|
|
|
|
struct intel_timeline *old = *dst;
|
|
|
|
|
|
|
|
*dst = src ? intel_timeline_get(src) : NULL;
|
|
|
|
|
|
|
|
if (old)
|
|
|
|
intel_timeline_put(old);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void __apply_timeline(struct intel_context *ce, void *timeline)
|
|
|
|
{
|
|
|
|
__set_timeline(&ce->timeline, timeline);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void __assign_timeline(struct i915_gem_context *ctx,
|
|
|
|
struct intel_timeline *timeline)
|
|
|
|
{
|
|
|
|
__set_timeline(&ctx->timeline, timeline);
|
|
|
|
context_apply_all(ctx, __apply_timeline, timeline);
|
|
|
|
}
|
|
|
|
|
2016-05-24 21:53:34 +08:00
|
|
|
static struct i915_gem_context *
|
2019-10-04 21:40:09 +08:00
|
|
|
i915_gem_create_context(struct drm_i915_private *i915, unsigned int flags)
|
drm/i915: preliminary context support
Very basic code for context setup/destruction in the driver.
Adds the file i915_gem_context.c This file implements HW context
support. On gen5+ a HW context consists of an opaque GPU object which is
referenced at times of context saves and restores. With RC6 enabled,
the context is also referenced as the GPU enters and exists from RC6
(GPU has it's own internal power context, except on gen5). Though
something like a context does exist for the media ring, the code only
supports contexts for the render ring.
In software, there is a distinction between contexts created by the
user, and the default HW context. The default HW context is used by GPU
clients that do not request setup of their own hardware context. The
default context's state is never restored to help prevent programming
errors. This would happen if a client ran and piggy-backed off another
clients GPU state. The default context only exists to give the GPU some
offset to load as the current to invoke a save of the context we
actually care about. In fact, the code could likely be constructed,
albeit in a more complicated fashion, to never use the default context,
though that limits the driver's ability to swap out, and/or destroy
other contexts.
All other contexts are created as a request by the GPU client. These
contexts store GPU state, and thus allow GPU clients to not re-emit
state (and potentially query certain state) at any time. The kernel
driver makes certain that the appropriate commands are inserted.
There are 4 entry points into the contexts, init, fini, open, close.
The names are self-explanatory except that init can be called during
reset, and also during pm thaw/resume. As we expect our context to be
preserved across these events, we do not reinitialize in this case.
As Adam Jackson pointed out, The cutoff of 1MB where a HW context is
considered too big is arbitrary. The reason for this is even though
context sizes are increasing with every generation, they have yet to
eclipse even 32k. If we somehow read back way more than that, it
probably means BIOS has done something strange, or we're running on a
platform that wasn't designed for this.
v2: rename load/unload to init/fini (daniel)
remove ILK support for get_size() (indirectly daniel)
add HAS_HW_CONTEXTS macro to clarify supported platforms (daniel)
added comments (Ben)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-05 05:42:42 +08:00
|
|
|
{
|
2016-05-24 21:53:34 +08:00
|
|
|
struct i915_gem_context *ctx;
|
2012-06-05 05:42:43 +08:00
|
|
|
|
2019-03-22 17:23:25 +08:00
|
|
|
if (flags & I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE &&
|
2019-10-04 21:40:09 +08:00
|
|
|
!HAS_EXECLISTS(i915))
|
2019-03-22 17:23:25 +08:00
|
|
|
return ERR_PTR(-EINVAL);
|
|
|
|
|
2019-10-04 21:40:09 +08:00
|
|
|
/* Reap the stale contexts */
|
|
|
|
contexts_flush_free(&i915->gem.contexts);
|
2017-07-05 22:26:32 +08:00
|
|
|
|
2019-10-04 21:40:09 +08:00
|
|
|
ctx = __create_context(i915);
|
2012-06-30 01:30:39 +08:00
|
|
|
if (IS_ERR(ctx))
|
2013-12-07 06:11:05 +08:00
|
|
|
return ctx;
|
2012-06-05 05:42:43 +08:00
|
|
|
|
2019-10-04 21:40:09 +08:00
|
|
|
if (HAS_FULL_PPGTT(i915)) {
|
2019-06-11 17:12:38 +08:00
|
|
|
struct i915_ppgtt *ppgtt;
|
2013-12-07 06:11:18 +08:00
|
|
|
|
2019-10-04 21:40:09 +08:00
|
|
|
ppgtt = i915_ppgtt_create(i915);
|
2016-05-24 21:53:38 +08:00
|
|
|
if (IS_ERR(ppgtt)) {
|
2013-12-07 06:11:19 +08:00
|
|
|
DRM_DEBUG_DRIVER("PPGTT setup failed (%ld)\n",
|
|
|
|
PTR_ERR(ppgtt));
|
2019-03-21 22:07:08 +08:00
|
|
|
context_close(ctx);
|
2016-05-24 21:53:38 +08:00
|
|
|
return ERR_CAST(ppgtt);
|
2014-08-06 21:04:53 +08:00
|
|
|
}
|
|
|
|
|
2019-10-04 21:40:09 +08:00
|
|
|
mutex_lock(&ctx->mutex);
|
2019-06-11 17:12:37 +08:00
|
|
|
__assign_ppgtt(ctx, &ppgtt->vm);
|
2019-10-04 21:40:09 +08:00
|
|
|
mutex_unlock(&ctx->mutex);
|
|
|
|
|
2019-06-11 17:12:37 +08:00
|
|
|
i915_vm_put(&ppgtt->vm);
|
2014-08-06 21:04:53 +08:00
|
|
|
}
|
2013-12-07 06:11:18 +08:00
|
|
|
|
2019-03-22 17:23:25 +08:00
|
|
|
if (flags & I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE) {
|
2019-06-21 15:08:10 +08:00
|
|
|
struct intel_timeline *timeline;
|
2019-03-22 17:23:25 +08:00
|
|
|
|
2019-10-04 21:40:09 +08:00
|
|
|
timeline = intel_timeline_create(&i915->gt, NULL);
|
2019-03-22 17:23:25 +08:00
|
|
|
if (IS_ERR(timeline)) {
|
|
|
|
context_close(ctx);
|
|
|
|
return ERR_CAST(timeline);
|
|
|
|
}
|
|
|
|
|
2019-08-10 02:25:18 +08:00
|
|
|
__assign_timeline(ctx, timeline);
|
|
|
|
intel_timeline_put(timeline);
|
2019-03-22 17:23:25 +08:00
|
|
|
}
|
|
|
|
|
2014-11-10 21:44:31 +08:00
|
|
|
trace_i915_context_create(ctx);
|
|
|
|
|
2013-12-07 06:11:05 +08:00
|
|
|
return ctx;
|
drm/i915: preliminary context support
Very basic code for context setup/destruction in the driver.
Adds the file i915_gem_context.c This file implements HW context
support. On gen5+ a HW context consists of an opaque GPU object which is
referenced at times of context saves and restores. With RC6 enabled,
the context is also referenced as the GPU enters and exists from RC6
(GPU has it's own internal power context, except on gen5). Though
something like a context does exist for the media ring, the code only
supports contexts for the render ring.
In software, there is a distinction between contexts created by the
user, and the default HW context. The default HW context is used by GPU
clients that do not request setup of their own hardware context. The
default context's state is never restored to help prevent programming
errors. This would happen if a client ran and piggy-backed off another
clients GPU state. The default context only exists to give the GPU some
offset to load as the current to invoke a save of the context we
actually care about. In fact, the code could likely be constructed,
albeit in a more complicated fashion, to never use the default context,
though that limits the driver's ability to swap out, and/or destroy
other contexts.
All other contexts are created as a request by the GPU client. These
contexts store GPU state, and thus allow GPU clients to not re-emit
state (and potentially query certain state) at any time. The kernel
driver makes certain that the appropriate commands are inserted.
There are 4 entry points into the contexts, init, fini, open, close.
The names are self-explanatory except that init can be called during
reset, and also during pm thaw/resume. As we expect our context to be
preserved across these events, we do not reinitialize in this case.
As Adam Jackson pointed out, The cutoff of 1MB where a HW context is
considered too big is arbitrary. The reason for this is even though
context sizes are increasing with every generation, they have yet to
eclipse even 32k. If we somehow read back way more than that, it
probably means BIOS has done something strange, or we're running on a
platform that wasn't designed for this.
v2: rename load/unload to init/fini (daniel)
remove ILK support for get_size() (indirectly daniel)
add HAS_HW_CONTEXTS macro to clarify supported platforms (daniel)
added comments (Ben)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-05 05:42:42 +08:00
|
|
|
}
|
|
|
|
|
2018-09-04 23:31:17 +08:00
|
|
|
static void
|
|
|
|
destroy_kernel_context(struct i915_gem_context **ctxp)
|
|
|
|
{
|
|
|
|
struct i915_gem_context *ctx;
|
|
|
|
|
|
|
|
/* Keep the context ref so that we can free it immediately ourselves */
|
|
|
|
ctx = i915_gem_context_get(fetch_and_zero(ctxp));
|
|
|
|
GEM_BUG_ON(!i915_gem_context_is_kernel(ctx));
|
|
|
|
|
|
|
|
context_close(ctx);
|
|
|
|
i915_gem_context_free(ctx);
|
|
|
|
}
|
|
|
|
|
2017-11-10 22:26:33 +08:00
|
|
|
struct i915_gem_context *
|
|
|
|
i915_gem_context_create_kernel(struct drm_i915_private *i915, int prio)
|
2017-10-04 04:34:48 +08:00
|
|
|
{
|
|
|
|
struct i915_gem_context *ctx;
|
|
|
|
|
2019-03-22 17:23:25 +08:00
|
|
|
ctx = i915_gem_create_context(i915, 0);
|
2017-10-04 04:34:48 +08:00
|
|
|
if (IS_ERR(ctx))
|
|
|
|
return ctx;
|
|
|
|
|
|
|
|
i915_gem_context_clear_bannable(ctx);
|
drm/i915/gem: Make context persistence optional
Our existing behaviour is to allow contexts and their GPU requests to
persist past the point of closure until the requests are complete. This
allows clients to operate in a 'fire-and-forget' manner where they can
setup a rendering pipeline and hand it over to the display server and
immediately exit. As the rendering pipeline is kept alive until
completion, the display server (or other consumer) can use the results
in the future and present them to the user.
The compute model is a little different. They have little to no buffer
sharing between processes as their kernels tend to operate on a
continuous stream, feeding the results back to the client application.
These kernels operate for an indeterminate length of time, with many
clients wishing that the kernel was always running for as long as they
keep feeding in the data, i.e. acting like a DSP.
Not all clients want this persistent "desktop" behaviour and would prefer
that the contexts are cleaned up immediately upon closure. This ensures
that when clients are run without hangchecking (e.g. for compute kernels
of indeterminate runtime), any GPU hang or other unexpected workloads
are terminated with the process and does not continue to hog resources.
The default behaviour for new contexts is the legacy persistence mode,
as some desktop applications are dependent upon the existing behaviour.
New clients will have to opt in to immediate cleanup on context
closure. If the hangchecking modparam is disabled, so is persistent
context support -- all contexts will be terminated on closure.
We expect this behaviour change to be welcomed by compute users, who
have often been caught between a rock and a hard place. They disable
hangchecking to avoid their kernels being "unfairly" declared hung, but
have also experienced true hangs that the system was then unable to
clean up. Naturally, this leads to bug reports.
Testcase: igt/gem_ctx_persistence
Link: https://github.com/intel/compute-runtime/pull/228
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Jon Bloomfield <jon.bloomfield@intel.com>
Reviewed-by: Jon Bloomfield <jon.bloomfield@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: Jason Ekstrand <jason@jlekstrand.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20191029202338.8841-1-chris@chris-wilson.co.uk
2019-10-30 04:23:38 +08:00
|
|
|
i915_gem_context_set_persistence(ctx);
|
2018-10-01 20:32:03 +08:00
|
|
|
ctx->sched.priority = I915_USER_PRIORITY(prio);
|
2017-10-04 04:34:48 +08:00
|
|
|
|
|
|
|
GEM_BUG_ON(!i915_gem_context_is_kernel(ctx));
|
|
|
|
|
|
|
|
return ctx;
|
|
|
|
}
|
|
|
|
|
2019-10-04 21:40:09 +08:00
|
|
|
static void init_contexts(struct i915_gem_contexts *gc)
|
2017-10-04 04:34:48 +08:00
|
|
|
{
|
2019-10-04 21:40:09 +08:00
|
|
|
spin_lock_init(&gc->lock);
|
|
|
|
INIT_LIST_HEAD(&gc->list);
|
2017-10-04 04:34:48 +08:00
|
|
|
|
2019-10-04 21:40:09 +08:00
|
|
|
INIT_WORK(&gc->free_work, contexts_free_worker);
|
|
|
|
init_llist_head(&gc->free_list);
|
2017-10-04 04:34:48 +08:00
|
|
|
}
|
|
|
|
|
2019-10-04 21:40:09 +08:00
|
|
|
int i915_gem_init_contexts(struct drm_i915_private *i915)
|
drm/i915: preliminary context support
Very basic code for context setup/destruction in the driver.
Adds the file i915_gem_context.c This file implements HW context
support. On gen5+ a HW context consists of an opaque GPU object which is
referenced at times of context saves and restores. With RC6 enabled,
the context is also referenced as the GPU enters and exists from RC6
(GPU has it's own internal power context, except on gen5). Though
something like a context does exist for the media ring, the code only
supports contexts for the render ring.
In software, there is a distinction between contexts created by the
user, and the default HW context. The default HW context is used by GPU
clients that do not request setup of their own hardware context. The
default context's state is never restored to help prevent programming
errors. This would happen if a client ran and piggy-backed off another
clients GPU state. The default context only exists to give the GPU some
offset to load as the current to invoke a save of the context we
actually care about. In fact, the code could likely be constructed,
albeit in a more complicated fashion, to never use the default context,
though that limits the driver's ability to swap out, and/or destroy
other contexts.
All other contexts are created as a request by the GPU client. These
contexts store GPU state, and thus allow GPU clients to not re-emit
state (and potentially query certain state) at any time. The kernel
driver makes certain that the appropriate commands are inserted.
There are 4 entry points into the contexts, init, fini, open, close.
The names are self-explanatory except that init can be called during
reset, and also during pm thaw/resume. As we expect our context to be
preserved across these events, we do not reinitialize in this case.
As Adam Jackson pointed out, The cutoff of 1MB where a HW context is
considered too big is arbitrary. The reason for this is even though
context sizes are increasing with every generation, they have yet to
eclipse even 32k. If we somehow read back way more than that, it
probably means BIOS has done something strange, or we're running on a
platform that wasn't designed for this.
v2: rename load/unload to init/fini (daniel)
remove ILK support for get_size() (indirectly daniel)
add HAS_HW_CONTEXTS macro to clarify supported platforms (daniel)
added comments (Ben)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-05 05:42:42 +08:00
|
|
|
{
|
2016-05-24 21:53:34 +08:00
|
|
|
struct i915_gem_context *ctx;
|
drm/i915: preliminary context support
Very basic code for context setup/destruction in the driver.
Adds the file i915_gem_context.c This file implements HW context
support. On gen5+ a HW context consists of an opaque GPU object which is
referenced at times of context saves and restores. With RC6 enabled,
the context is also referenced as the GPU enters and exists from RC6
(GPU has it's own internal power context, except on gen5). Though
something like a context does exist for the media ring, the code only
supports contexts for the render ring.
In software, there is a distinction between contexts created by the
user, and the default HW context. The default HW context is used by GPU
clients that do not request setup of their own hardware context. The
default context's state is never restored to help prevent programming
errors. This would happen if a client ran and piggy-backed off another
clients GPU state. The default context only exists to give the GPU some
offset to load as the current to invoke a save of the context we
actually care about. In fact, the code could likely be constructed,
albeit in a more complicated fashion, to never use the default context,
though that limits the driver's ability to swap out, and/or destroy
other contexts.
All other contexts are created as a request by the GPU client. These
contexts store GPU state, and thus allow GPU clients to not re-emit
state (and potentially query certain state) at any time. The kernel
driver makes certain that the appropriate commands are inserted.
There are 4 entry points into the contexts, init, fini, open, close.
The names are self-explanatory except that init can be called during
reset, and also during pm thaw/resume. As we expect our context to be
preserved across these events, we do not reinitialize in this case.
As Adam Jackson pointed out, The cutoff of 1MB where a HW context is
considered too big is arbitrary. The reason for this is even though
context sizes are increasing with every generation, they have yet to
eclipse even 32k. If we somehow read back way more than that, it
probably means BIOS has done something strange, or we're running on a
platform that wasn't designed for this.
v2: rename load/unload to init/fini (daniel)
remove ILK support for get_size() (indirectly daniel)
add HAS_HW_CONTEXTS macro to clarify supported platforms (daniel)
added comments (Ben)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-05 05:42:42 +08:00
|
|
|
|
2018-02-08 05:05:44 +08:00
|
|
|
/* Reassure ourselves we are only called once */
|
2019-10-04 21:40:09 +08:00
|
|
|
GEM_BUG_ON(i915->kernel_context);
|
drm/i915: preliminary context support
Very basic code for context setup/destruction in the driver.
Adds the file i915_gem_context.c This file implements HW context
support. On gen5+ a HW context consists of an opaque GPU object which is
referenced at times of context saves and restores. With RC6 enabled,
the context is also referenced as the GPU enters and exists from RC6
(GPU has it's own internal power context, except on gen5). Though
something like a context does exist for the media ring, the code only
supports contexts for the render ring.
In software, there is a distinction between contexts created by the
user, and the default HW context. The default HW context is used by GPU
clients that do not request setup of their own hardware context. The
default context's state is never restored to help prevent programming
errors. This would happen if a client ran and piggy-backed off another
clients GPU state. The default context only exists to give the GPU some
offset to load as the current to invoke a save of the context we
actually care about. In fact, the code could likely be constructed,
albeit in a more complicated fashion, to never use the default context,
though that limits the driver's ability to swap out, and/or destroy
other contexts.
All other contexts are created as a request by the GPU client. These
contexts store GPU state, and thus allow GPU clients to not re-emit
state (and potentially query certain state) at any time. The kernel
driver makes certain that the appropriate commands are inserted.
There are 4 entry points into the contexts, init, fini, open, close.
The names are self-explanatory except that init can be called during
reset, and also during pm thaw/resume. As we expect our context to be
preserved across these events, we do not reinitialize in this case.
As Adam Jackson pointed out, The cutoff of 1MB where a HW context is
considered too big is arbitrary. The reason for this is even though
context sizes are increasing with every generation, they have yet to
eclipse even 32k. If we somehow read back way more than that, it
probably means BIOS has done something strange, or we're running on a
platform that wasn't designed for this.
v2: rename load/unload to init/fini (daniel)
remove ILK support for get_size() (indirectly daniel)
add HAS_HW_CONTEXTS macro to clarify supported platforms (daniel)
added comments (Ben)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-05 05:42:42 +08:00
|
|
|
|
2019-10-04 21:40:09 +08:00
|
|
|
init_contexts(&i915->gem.contexts);
|
2016-04-28 16:56:51 +08:00
|
|
|
|
2017-10-04 04:34:48 +08:00
|
|
|
/* lowest priority; idle task */
|
2019-10-04 21:40:09 +08:00
|
|
|
ctx = i915_gem_context_create_kernel(i915, I915_PRIORITY_MIN);
|
2014-04-09 16:07:36 +08:00
|
|
|
if (IS_ERR(ctx)) {
|
2017-10-04 04:34:48 +08:00
|
|
|
DRM_ERROR("Failed to create default global context\n");
|
2018-02-08 05:05:44 +08:00
|
|
|
return PTR_ERR(ctx);
|
drm/i915: preliminary context support
Very basic code for context setup/destruction in the driver.
Adds the file i915_gem_context.c This file implements HW context
support. On gen5+ a HW context consists of an opaque GPU object which is
referenced at times of context saves and restores. With RC6 enabled,
the context is also referenced as the GPU enters and exists from RC6
(GPU has it's own internal power context, except on gen5). Though
something like a context does exist for the media ring, the code only
supports contexts for the render ring.
In software, there is a distinction between contexts created by the
user, and the default HW context. The default HW context is used by GPU
clients that do not request setup of their own hardware context. The
default context's state is never restored to help prevent programming
errors. This would happen if a client ran and piggy-backed off another
clients GPU state. The default context only exists to give the GPU some
offset to load as the current to invoke a save of the context we
actually care about. In fact, the code could likely be constructed,
albeit in a more complicated fashion, to never use the default context,
though that limits the driver's ability to swap out, and/or destroy
other contexts.
All other contexts are created as a request by the GPU client. These
contexts store GPU state, and thus allow GPU clients to not re-emit
state (and potentially query certain state) at any time. The kernel
driver makes certain that the appropriate commands are inserted.
There are 4 entry points into the contexts, init, fini, open, close.
The names are self-explanatory except that init can be called during
reset, and also during pm thaw/resume. As we expect our context to be
preserved across these events, we do not reinitialize in this case.
As Adam Jackson pointed out, The cutoff of 1MB where a HW context is
considered too big is arbitrary. The reason for this is even though
context sizes are increasing with every generation, they have yet to
eclipse even 32k. If we somehow read back way more than that, it
probably means BIOS has done something strange, or we're running on a
platform that wasn't designed for this.
v2: rename load/unload to init/fini (daniel)
remove ILK support for get_size() (indirectly daniel)
add HAS_HW_CONTEXTS macro to clarify supported platforms (daniel)
added comments (Ben)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-05 05:42:42 +08:00
|
|
|
}
|
2019-10-04 21:40:09 +08:00
|
|
|
i915->kernel_context = ctx;
|
2013-12-07 06:11:01 +08:00
|
|
|
|
2014-07-25 00:04:12 +08:00
|
|
|
DRM_DEBUG_DRIVER("%s context support initialized\n",
|
2019-10-04 21:40:09 +08:00
|
|
|
DRIVER_CAPS(i915)->has_logical_contexts ?
|
2018-07-06 18:14:41 +08:00
|
|
|
"logical" : "fake");
|
2013-11-06 23:56:29 +08:00
|
|
|
return 0;
|
drm/i915: preliminary context support
Very basic code for context setup/destruction in the driver.
Adds the file i915_gem_context.c This file implements HW context
support. On gen5+ a HW context consists of an opaque GPU object which is
referenced at times of context saves and restores. With RC6 enabled,
the context is also referenced as the GPU enters and exists from RC6
(GPU has it's own internal power context, except on gen5). Though
something like a context does exist for the media ring, the code only
supports contexts for the render ring.
In software, there is a distinction between contexts created by the
user, and the default HW context. The default HW context is used by GPU
clients that do not request setup of their own hardware context. The
default context's state is never restored to help prevent programming
errors. This would happen if a client ran and piggy-backed off another
clients GPU state. The default context only exists to give the GPU some
offset to load as the current to invoke a save of the context we
actually care about. In fact, the code could likely be constructed,
albeit in a more complicated fashion, to never use the default context,
though that limits the driver's ability to swap out, and/or destroy
other contexts.
All other contexts are created as a request by the GPU client. These
contexts store GPU state, and thus allow GPU clients to not re-emit
state (and potentially query certain state) at any time. The kernel
driver makes certain that the appropriate commands are inserted.
There are 4 entry points into the contexts, init, fini, open, close.
The names are self-explanatory except that init can be called during
reset, and also during pm thaw/resume. As we expect our context to be
preserved across these events, we do not reinitialize in this case.
As Adam Jackson pointed out, The cutoff of 1MB where a HW context is
considered too big is arbitrary. The reason for this is even though
context sizes are increasing with every generation, they have yet to
eclipse even 32k. If we somehow read back way more than that, it
probably means BIOS has done something strange, or we're running on a
platform that wasn't designed for this.
v2: rename load/unload to init/fini (daniel)
remove ILK support for get_size() (indirectly daniel)
add HAS_HW_CONTEXTS macro to clarify supported platforms (daniel)
added comments (Ben)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-05 05:42:42 +08:00
|
|
|
}
|
|
|
|
|
2019-10-04 21:40:09 +08:00
|
|
|
void i915_gem_driver_release__contexts(struct drm_i915_private *i915)
|
drm/i915: preliminary context support
Very basic code for context setup/destruction in the driver.
Adds the file i915_gem_context.c This file implements HW context
support. On gen5+ a HW context consists of an opaque GPU object which is
referenced at times of context saves and restores. With RC6 enabled,
the context is also referenced as the GPU enters and exists from RC6
(GPU has it's own internal power context, except on gen5). Though
something like a context does exist for the media ring, the code only
supports contexts for the render ring.
In software, there is a distinction between contexts created by the
user, and the default HW context. The default HW context is used by GPU
clients that do not request setup of their own hardware context. The
default context's state is never restored to help prevent programming
errors. This would happen if a client ran and piggy-backed off another
clients GPU state. The default context only exists to give the GPU some
offset to load as the current to invoke a save of the context we
actually care about. In fact, the code could likely be constructed,
albeit in a more complicated fashion, to never use the default context,
though that limits the driver's ability to swap out, and/or destroy
other contexts.
All other contexts are created as a request by the GPU client. These
contexts store GPU state, and thus allow GPU clients to not re-emit
state (and potentially query certain state) at any time. The kernel
driver makes certain that the appropriate commands are inserted.
There are 4 entry points into the contexts, init, fini, open, close.
The names are self-explanatory except that init can be called during
reset, and also during pm thaw/resume. As we expect our context to be
preserved across these events, we do not reinitialize in this case.
As Adam Jackson pointed out, The cutoff of 1MB where a HW context is
considered too big is arbitrary. The reason for this is even though
context sizes are increasing with every generation, they have yet to
eclipse even 32k. If we somehow read back way more than that, it
probably means BIOS has done something strange, or we're running on a
platform that wasn't designed for this.
v2: rename load/unload to init/fini (daniel)
remove ILK support for get_size() (indirectly daniel)
add HAS_HW_CONTEXTS macro to clarify supported platforms (daniel)
added comments (Ben)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-05 05:42:42 +08:00
|
|
|
{
|
2017-10-04 04:34:48 +08:00
|
|
|
destroy_kernel_context(&i915->kernel_context);
|
2019-11-12 23:00:51 +08:00
|
|
|
flush_work(&i915->gem.contexts.free_work);
|
drm/i915: preliminary context support
Very basic code for context setup/destruction in the driver.
Adds the file i915_gem_context.c This file implements HW context
support. On gen5+ a HW context consists of an opaque GPU object which is
referenced at times of context saves and restores. With RC6 enabled,
the context is also referenced as the GPU enters and exists from RC6
(GPU has it's own internal power context, except on gen5). Though
something like a context does exist for the media ring, the code only
supports contexts for the render ring.
In software, there is a distinction between contexts created by the
user, and the default HW context. The default HW context is used by GPU
clients that do not request setup of their own hardware context. The
default context's state is never restored to help prevent programming
errors. This would happen if a client ran and piggy-backed off another
clients GPU state. The default context only exists to give the GPU some
offset to load as the current to invoke a save of the context we
actually care about. In fact, the code could likely be constructed,
albeit in a more complicated fashion, to never use the default context,
though that limits the driver's ability to swap out, and/or destroy
other contexts.
All other contexts are created as a request by the GPU client. These
contexts store GPU state, and thus allow GPU clients to not re-emit
state (and potentially query certain state) at any time. The kernel
driver makes certain that the appropriate commands are inserted.
There are 4 entry points into the contexts, init, fini, open, close.
The names are self-explanatory except that init can be called during
reset, and also during pm thaw/resume. As we expect our context to be
preserved across these events, we do not reinitialize in this case.
As Adam Jackson pointed out, The cutoff of 1MB where a HW context is
considered too big is arbitrary. The reason for this is even though
context sizes are increasing with every generation, they have yet to
eclipse even 32k. If we somehow read back way more than that, it
probably means BIOS has done something strange, or we're running on a
platform that wasn't designed for this.
v2: rename load/unload to init/fini (daniel)
remove ILK support for get_size() (indirectly daniel)
add HAS_HW_CONTEXTS macro to clarify supported platforms (daniel)
added comments (Ben)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-05 05:42:42 +08:00
|
|
|
}
|
|
|
|
|
2012-06-05 05:42:43 +08:00
|
|
|
static int context_idr_cleanup(int id, void *p, void *data)
|
|
|
|
{
|
2019-03-21 22:07:09 +08:00
|
|
|
context_close(p);
|
2012-06-05 05:42:43 +08:00
|
|
|
return 0;
|
drm/i915: preliminary context support
Very basic code for context setup/destruction in the driver.
Adds the file i915_gem_context.c This file implements HW context
support. On gen5+ a HW context consists of an opaque GPU object which is
referenced at times of context saves and restores. With RC6 enabled,
the context is also referenced as the GPU enters and exists from RC6
(GPU has it's own internal power context, except on gen5). Though
something like a context does exist for the media ring, the code only
supports contexts for the render ring.
In software, there is a distinction between contexts created by the
user, and the default HW context. The default HW context is used by GPU
clients that do not request setup of their own hardware context. The
default context's state is never restored to help prevent programming
errors. This would happen if a client ran and piggy-backed off another
clients GPU state. The default context only exists to give the GPU some
offset to load as the current to invoke a save of the context we
actually care about. In fact, the code could likely be constructed,
albeit in a more complicated fashion, to never use the default context,
though that limits the driver's ability to swap out, and/or destroy
other contexts.
All other contexts are created as a request by the GPU client. These
contexts store GPU state, and thus allow GPU clients to not re-emit
state (and potentially query certain state) at any time. The kernel
driver makes certain that the appropriate commands are inserted.
There are 4 entry points into the contexts, init, fini, open, close.
The names are self-explanatory except that init can be called during
reset, and also during pm thaw/resume. As we expect our context to be
preserved across these events, we do not reinitialize in this case.
As Adam Jackson pointed out, The cutoff of 1MB where a HW context is
considered too big is arbitrary. The reason for this is even though
context sizes are increasing with every generation, they have yet to
eclipse even 32k. If we somehow read back way more than that, it
probably means BIOS has done something strange, or we're running on a
platform that wasn't designed for this.
v2: rename load/unload to init/fini (daniel)
remove ILK support for get_size() (indirectly daniel)
add HAS_HW_CONTEXTS macro to clarify supported platforms (daniel)
added comments (Ben)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-05 05:42:42 +08:00
|
|
|
}
|
|
|
|
|
2019-03-22 17:23:23 +08:00
|
|
|
static int vm_idr_cleanup(int id, void *p, void *data)
|
|
|
|
{
|
2019-06-11 17:12:37 +08:00
|
|
|
i915_vm_put(p);
|
2019-03-22 17:23:23 +08:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-03-21 22:07:08 +08:00
|
|
|
static int gem_context_register(struct i915_gem_context *ctx,
|
|
|
|
struct drm_i915_file_private *fpriv)
|
|
|
|
{
|
2019-10-04 21:40:09 +08:00
|
|
|
struct i915_address_space *vm;
|
2019-03-21 22:07:08 +08:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
ctx->file_priv = fpriv;
|
2019-10-04 21:40:09 +08:00
|
|
|
|
|
|
|
mutex_lock(&ctx->mutex);
|
|
|
|
vm = i915_gem_context_vm(ctx);
|
|
|
|
if (vm)
|
|
|
|
WRITE_ONCE(vm->file, fpriv); /* XXX */
|
|
|
|
mutex_unlock(&ctx->mutex);
|
2019-03-21 22:07:08 +08:00
|
|
|
|
|
|
|
ctx->pid = get_task_pid(current, PIDTYPE_PID);
|
2019-11-11 19:43:20 +08:00
|
|
|
snprintf(ctx->name, sizeof(ctx->name), "%s[%d]",
|
|
|
|
current->comm, pid_nr(ctx->pid));
|
2019-03-21 22:07:08 +08:00
|
|
|
|
|
|
|
/* And finally expose ourselves to userspace via the idr */
|
2019-03-21 22:07:09 +08:00
|
|
|
mutex_lock(&fpriv->context_idr_lock);
|
2019-03-21 22:07:10 +08:00
|
|
|
ret = idr_alloc(&fpriv->context_idr, ctx, 0, 0, GFP_KERNEL);
|
2019-03-21 22:07:09 +08:00
|
|
|
mutex_unlock(&fpriv->context_idr_lock);
|
2019-03-21 22:07:10 +08:00
|
|
|
if (ret >= 0)
|
|
|
|
goto out;
|
2019-03-21 22:07:08 +08:00
|
|
|
|
|
|
|
put_pid(fetch_and_zero(&ctx->pid));
|
2019-03-21 22:07:10 +08:00
|
|
|
out:
|
2019-03-21 22:07:08 +08:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2017-06-20 19:05:45 +08:00
|
|
|
int i915_gem_context_open(struct drm_i915_private *i915,
|
|
|
|
struct drm_file *file)
|
2013-12-07 06:10:58 +08:00
|
|
|
{
|
|
|
|
struct drm_i915_file_private *file_priv = file->driver_priv;
|
2016-05-24 21:53:34 +08:00
|
|
|
struct i915_gem_context *ctx;
|
2019-03-21 22:07:08 +08:00
|
|
|
int err;
|
2013-12-07 06:10:58 +08:00
|
|
|
|
2019-03-21 22:07:09 +08:00
|
|
|
mutex_init(&file_priv->context_idr_lock);
|
2019-03-22 17:23:23 +08:00
|
|
|
mutex_init(&file_priv->vm_idr_lock);
|
|
|
|
|
|
|
|
idr_init(&file_priv->context_idr);
|
|
|
|
idr_init_base(&file_priv->vm_idr, 1);
|
2013-12-07 06:10:58 +08:00
|
|
|
|
2019-03-22 17:23:25 +08:00
|
|
|
ctx = i915_gem_create_context(i915, 0);
|
2014-05-22 21:13:38 +08:00
|
|
|
if (IS_ERR(ctx)) {
|
2019-03-21 22:07:08 +08:00
|
|
|
err = PTR_ERR(ctx);
|
|
|
|
goto err;
|
2013-12-07 06:11:19 +08:00
|
|
|
}
|
|
|
|
|
2019-03-21 22:07:08 +08:00
|
|
|
err = gem_context_register(ctx, file_priv);
|
2019-03-21 22:07:10 +08:00
|
|
|
if (err < 0)
|
2019-03-21 22:07:08 +08:00
|
|
|
goto err_ctx;
|
|
|
|
|
2017-07-05 22:26:31 +08:00
|
|
|
GEM_BUG_ON(i915_gem_context_is_kernel(ctx));
|
2019-03-21 22:07:10 +08:00
|
|
|
GEM_BUG_ON(err > 0);
|
2017-07-05 22:26:31 +08:00
|
|
|
|
2013-12-07 06:10:58 +08:00
|
|
|
return 0;
|
2019-03-21 22:07:08 +08:00
|
|
|
|
|
|
|
err_ctx:
|
|
|
|
context_close(ctx);
|
2019-03-21 22:07:09 +08:00
|
|
|
err:
|
2019-03-22 17:23:23 +08:00
|
|
|
idr_destroy(&file_priv->vm_idr);
|
2019-03-21 22:07:08 +08:00
|
|
|
idr_destroy(&file_priv->context_idr);
|
2019-03-22 17:23:23 +08:00
|
|
|
mutex_destroy(&file_priv->vm_idr_lock);
|
|
|
|
mutex_destroy(&file_priv->context_idr_lock);
|
2019-03-25 17:03:52 +08:00
|
|
|
return err;
|
2013-12-07 06:10:58 +08:00
|
|
|
}
|
|
|
|
|
2017-06-20 19:05:45 +08:00
|
|
|
void i915_gem_context_close(struct drm_file *file)
|
drm/i915: preliminary context support
Very basic code for context setup/destruction in the driver.
Adds the file i915_gem_context.c This file implements HW context
support. On gen5+ a HW context consists of an opaque GPU object which is
referenced at times of context saves and restores. With RC6 enabled,
the context is also referenced as the GPU enters and exists from RC6
(GPU has it's own internal power context, except on gen5). Though
something like a context does exist for the media ring, the code only
supports contexts for the render ring.
In software, there is a distinction between contexts created by the
user, and the default HW context. The default HW context is used by GPU
clients that do not request setup of their own hardware context. The
default context's state is never restored to help prevent programming
errors. This would happen if a client ran and piggy-backed off another
clients GPU state. The default context only exists to give the GPU some
offset to load as the current to invoke a save of the context we
actually care about. In fact, the code could likely be constructed,
albeit in a more complicated fashion, to never use the default context,
though that limits the driver's ability to swap out, and/or destroy
other contexts.
All other contexts are created as a request by the GPU client. These
contexts store GPU state, and thus allow GPU clients to not re-emit
state (and potentially query certain state) at any time. The kernel
driver makes certain that the appropriate commands are inserted.
There are 4 entry points into the contexts, init, fini, open, close.
The names are self-explanatory except that init can be called during
reset, and also during pm thaw/resume. As we expect our context to be
preserved across these events, we do not reinitialize in this case.
As Adam Jackson pointed out, The cutoff of 1MB where a HW context is
considered too big is arbitrary. The reason for this is even though
context sizes are increasing with every generation, they have yet to
eclipse even 32k. If we somehow read back way more than that, it
probably means BIOS has done something strange, or we're running on a
platform that wasn't designed for this.
v2: rename load/unload to init/fini (daniel)
remove ILK support for get_size() (indirectly daniel)
add HAS_HW_CONTEXTS macro to clarify supported platforms (daniel)
added comments (Ben)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-05 05:42:42 +08:00
|
|
|
{
|
2012-06-05 05:42:43 +08:00
|
|
|
struct drm_i915_file_private *file_priv = file->driver_priv;
|
2019-10-04 21:40:09 +08:00
|
|
|
struct drm_i915_private *i915 = file_priv->dev_priv;
|
drm/i915: preliminary context support
Very basic code for context setup/destruction in the driver.
Adds the file i915_gem_context.c This file implements HW context
support. On gen5+ a HW context consists of an opaque GPU object which is
referenced at times of context saves and restores. With RC6 enabled,
the context is also referenced as the GPU enters and exists from RC6
(GPU has it's own internal power context, except on gen5). Though
something like a context does exist for the media ring, the code only
supports contexts for the render ring.
In software, there is a distinction between contexts created by the
user, and the default HW context. The default HW context is used by GPU
clients that do not request setup of their own hardware context. The
default context's state is never restored to help prevent programming
errors. This would happen if a client ran and piggy-backed off another
clients GPU state. The default context only exists to give the GPU some
offset to load as the current to invoke a save of the context we
actually care about. In fact, the code could likely be constructed,
albeit in a more complicated fashion, to never use the default context,
though that limits the driver's ability to swap out, and/or destroy
other contexts.
All other contexts are created as a request by the GPU client. These
contexts store GPU state, and thus allow GPU clients to not re-emit
state (and potentially query certain state) at any time. The kernel
driver makes certain that the appropriate commands are inserted.
There are 4 entry points into the contexts, init, fini, open, close.
The names are self-explanatory except that init can be called during
reset, and also during pm thaw/resume. As we expect our context to be
preserved across these events, we do not reinitialize in this case.
As Adam Jackson pointed out, The cutoff of 1MB where a HW context is
considered too big is arbitrary. The reason for this is even though
context sizes are increasing with every generation, they have yet to
eclipse even 32k. If we somehow read back way more than that, it
probably means BIOS has done something strange, or we're running on a
platform that wasn't designed for this.
v2: rename load/unload to init/fini (daniel)
remove ILK support for get_size() (indirectly daniel)
add HAS_HW_CONTEXTS macro to clarify supported platforms (daniel)
added comments (Ben)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-05 05:42:42 +08:00
|
|
|
|
2012-06-20 02:27:39 +08:00
|
|
|
idr_for_each(&file_priv->context_idr, context_idr_cleanup, NULL);
|
2012-06-05 05:42:43 +08:00
|
|
|
idr_destroy(&file_priv->context_idr);
|
2019-03-21 22:07:09 +08:00
|
|
|
mutex_destroy(&file_priv->context_idr_lock);
|
2019-03-22 17:23:23 +08:00
|
|
|
|
|
|
|
idr_for_each(&file_priv->vm_idr, vm_idr_cleanup, NULL);
|
|
|
|
idr_destroy(&file_priv->vm_idr);
|
|
|
|
mutex_destroy(&file_priv->vm_idr_lock);
|
2019-10-04 21:40:09 +08:00
|
|
|
|
|
|
|
contexts_flush_free(&i915->gem.contexts);
|
2019-03-22 17:23:23 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
int i915_gem_vm_create_ioctl(struct drm_device *dev, void *data,
|
|
|
|
struct drm_file *file)
|
|
|
|
{
|
|
|
|
struct drm_i915_private *i915 = to_i915(dev);
|
|
|
|
struct drm_i915_gem_vm_control *args = data;
|
|
|
|
struct drm_i915_file_private *file_priv = file->driver_priv;
|
2019-06-11 17:12:38 +08:00
|
|
|
struct i915_ppgtt *ppgtt;
|
2019-03-22 17:23:23 +08:00
|
|
|
int err;
|
|
|
|
|
|
|
|
if (!HAS_FULL_PPGTT(i915))
|
|
|
|
return -ENODEV;
|
|
|
|
|
|
|
|
if (args->flags)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
ppgtt = i915_ppgtt_create(i915);
|
|
|
|
if (IS_ERR(ppgtt))
|
|
|
|
return PTR_ERR(ppgtt);
|
|
|
|
|
|
|
|
ppgtt->vm.file = file_priv;
|
|
|
|
|
|
|
|
if (args->extensions) {
|
|
|
|
err = i915_user_extensions(u64_to_user_ptr(args->extensions),
|
|
|
|
NULL, 0,
|
|
|
|
ppgtt);
|
|
|
|
if (err)
|
|
|
|
goto err_put;
|
|
|
|
}
|
|
|
|
|
|
|
|
err = mutex_lock_interruptible(&file_priv->vm_idr_lock);
|
|
|
|
if (err)
|
|
|
|
goto err_put;
|
|
|
|
|
2019-06-11 17:12:37 +08:00
|
|
|
err = idr_alloc(&file_priv->vm_idr, &ppgtt->vm, 0, 0, GFP_KERNEL);
|
2019-03-22 17:23:23 +08:00
|
|
|
if (err < 0)
|
|
|
|
goto err_unlock;
|
|
|
|
|
2019-04-25 13:43:33 +08:00
|
|
|
GEM_BUG_ON(err == 0); /* reserved for invalid/unassigned ppgtt */
|
2019-03-22 17:23:23 +08:00
|
|
|
|
|
|
|
mutex_unlock(&file_priv->vm_idr_lock);
|
|
|
|
|
|
|
|
args->vm_id = err;
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
err_unlock:
|
|
|
|
mutex_unlock(&file_priv->vm_idr_lock);
|
|
|
|
err_put:
|
2019-06-11 17:12:37 +08:00
|
|
|
i915_vm_put(&ppgtt->vm);
|
2019-03-22 17:23:23 +08:00
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
int i915_gem_vm_destroy_ioctl(struct drm_device *dev, void *data,
|
|
|
|
struct drm_file *file)
|
|
|
|
{
|
|
|
|
struct drm_i915_file_private *file_priv = file->driver_priv;
|
|
|
|
struct drm_i915_gem_vm_control *args = data;
|
2019-06-11 17:12:37 +08:00
|
|
|
struct i915_address_space *vm;
|
2019-03-22 17:23:23 +08:00
|
|
|
int err;
|
|
|
|
u32 id;
|
|
|
|
|
|
|
|
if (args->flags)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (args->extensions)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
id = args->vm_id;
|
|
|
|
if (!id)
|
|
|
|
return -ENOENT;
|
|
|
|
|
|
|
|
err = mutex_lock_interruptible(&file_priv->vm_idr_lock);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
2019-06-11 17:12:37 +08:00
|
|
|
vm = idr_remove(&file_priv->vm_idr, id);
|
2019-03-22 17:23:23 +08:00
|
|
|
|
|
|
|
mutex_unlock(&file_priv->vm_idr_lock);
|
2019-06-11 17:12:37 +08:00
|
|
|
if (!vm)
|
2019-03-22 17:23:23 +08:00
|
|
|
return -ENOENT;
|
|
|
|
|
2019-06-11 17:12:37 +08:00
|
|
|
i915_vm_put(vm);
|
2019-03-22 17:23:23 +08:00
|
|
|
return 0;
|
2012-06-05 05:42:43 +08:00
|
|
|
}
|
|
|
|
|
2019-03-10 00:02:50 +08:00
|
|
|
struct context_barrier_task {
|
|
|
|
struct i915_active base;
|
|
|
|
void (*task)(void *data);
|
|
|
|
void *data;
|
|
|
|
};
|
|
|
|
|
2019-10-04 21:39:59 +08:00
|
|
|
__i915_active_call
|
2019-03-10 00:02:50 +08:00
|
|
|
static void cb_retire(struct i915_active *base)
|
|
|
|
{
|
|
|
|
struct context_barrier_task *cb = container_of(base, typeof(*cb), base);
|
|
|
|
|
|
|
|
if (cb->task)
|
|
|
|
cb->task(cb->data);
|
|
|
|
|
|
|
|
i915_active_fini(&cb->base);
|
|
|
|
kfree(cb);
|
|
|
|
}
|
|
|
|
|
2019-04-02 00:26:39 +08:00
|
|
|
I915_SELFTEST_DECLARE(static intel_engine_mask_t context_barrier_inject_fault);
|
2019-03-10 00:02:50 +08:00
|
|
|
static int context_barrier_task(struct i915_gem_context *ctx,
|
2019-04-02 00:26:39 +08:00
|
|
|
intel_engine_mask_t engines,
|
2019-06-04 23:24:08 +08:00
|
|
|
bool (*skip)(struct intel_context *ce, void *data),
|
2019-03-22 17:23:23 +08:00
|
|
|
int (*emit)(struct i915_request *rq, void *data),
|
2019-03-10 00:02:50 +08:00
|
|
|
void (*task)(void *data),
|
|
|
|
void *data)
|
|
|
|
{
|
|
|
|
struct context_barrier_task *cb;
|
2019-04-27 00:33:34 +08:00
|
|
|
struct i915_gem_engines_iter it;
|
|
|
|
struct intel_context *ce;
|
2019-03-10 00:02:50 +08:00
|
|
|
int err = 0;
|
|
|
|
|
|
|
|
GEM_BUG_ON(!task);
|
|
|
|
|
|
|
|
cb = kmalloc(sizeof(*cb), GFP_KERNEL);
|
|
|
|
if (!cb)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
2019-10-04 21:40:00 +08:00
|
|
|
i915_active_init(&cb->base, NULL, cb_retire);
|
2019-06-22 02:38:00 +08:00
|
|
|
err = i915_active_acquire(&cb->base);
|
|
|
|
if (err) {
|
|
|
|
kfree(cb);
|
|
|
|
return err;
|
|
|
|
}
|
2019-03-10 00:02:50 +08:00
|
|
|
|
2019-04-27 00:33:34 +08:00
|
|
|
for_each_gem_engine(ce, i915_gem_context_lock_engines(ctx), it) {
|
2019-03-10 00:02:50 +08:00
|
|
|
struct i915_request *rq;
|
|
|
|
|
|
|
|
if (I915_SELFTEST_ONLY(context_barrier_inject_fault &
|
2019-04-27 00:33:34 +08:00
|
|
|
ce->engine->mask)) {
|
2019-03-10 00:02:50 +08:00
|
|
|
err = -ENXIO;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2019-06-04 23:24:08 +08:00
|
|
|
if (!(ce->engine->mask & engines))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (skip && skip(ce, data))
|
2019-04-29 17:07:35 +08:00
|
|
|
continue;
|
|
|
|
|
2019-04-27 00:33:34 +08:00
|
|
|
rq = intel_context_create_request(ce);
|
2019-03-10 00:02:50 +08:00
|
|
|
if (IS_ERR(rq)) {
|
|
|
|
err = PTR_ERR(rq);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2019-03-22 17:23:23 +08:00
|
|
|
err = 0;
|
|
|
|
if (emit)
|
|
|
|
err = emit(rq, data);
|
|
|
|
if (err == 0)
|
drm/i915: Mark i915_request.timeline as a volatile, rcu pointer
The request->timeline is only valid until the request is retired (i.e.
before it is completed). Upon retiring the request, the context may be
unpinned and freed, and along with it the timeline may be freed. We
therefore need to be very careful when chasing rq->timeline that the
pointer does not disappear beneath us. The vast majority of users are in
a protected context, either during request construction or retirement,
where the timeline->mutex is held and the timeline cannot disappear. It
is those few off the beaten path (where we access a second timeline) that
need extra scrutiny -- to be added in the next patch after first adding
the warnings about dangerous access.
One complication, where we cannot use the timeline->mutex itself, is
during request submission onto hardware (under spinlocks). Here, we want
to check on the timeline to finalize the breadcrumb, and so we need to
impose a second rule to ensure that the request->timeline is indeed
valid. As we are submitting the request, it's context and timeline must
be pinned, as it will be used by the hardware. Since it is pinned, we
know the request->timeline must still be valid, and we cannot submit the
idle barrier until after we release the engine->active.lock, ergo while
submitting and holding that spinlock, a second thread cannot release the
timeline.
v2: Don't be lazy inside selftests; hold the timeline->mutex for as long
as we need it, and tidy up acquiring the timeline with a bit of
refactoring (i915_active_add_request)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190919111912.21631-1-chris@chris-wilson.co.uk
2019-09-19 19:19:10 +08:00
|
|
|
err = i915_active_add_request(&cb->base, rq);
|
2019-03-22 17:23:23 +08:00
|
|
|
|
2019-03-10 00:02:50 +08:00
|
|
|
i915_request_add(rq);
|
|
|
|
if (err)
|
|
|
|
break;
|
|
|
|
}
|
2019-04-27 00:33:34 +08:00
|
|
|
i915_gem_context_unlock_engines(ctx);
|
2019-03-10 00:02:50 +08:00
|
|
|
|
|
|
|
cb->task = err ? NULL : task; /* caller needs to unwind instead */
|
|
|
|
cb->data = data;
|
|
|
|
|
|
|
|
i915_active_release(&cb->base);
|
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2019-03-30 18:03:49 +08:00
|
|
|
static int get_ppgtt(struct drm_i915_file_private *file_priv,
|
|
|
|
struct i915_gem_context *ctx,
|
2019-03-22 17:23:23 +08:00
|
|
|
struct drm_i915_gem_context_param *args)
|
|
|
|
{
|
2019-06-11 17:12:37 +08:00
|
|
|
struct i915_address_space *vm;
|
2019-03-22 17:23:23 +08:00
|
|
|
int ret;
|
|
|
|
|
2019-10-04 21:40:09 +08:00
|
|
|
if (!rcu_access_pointer(ctx->vm))
|
2019-03-22 17:23:23 +08:00
|
|
|
return -ENODEV;
|
|
|
|
|
2019-10-04 21:40:09 +08:00
|
|
|
rcu_read_lock();
|
2019-11-06 17:13:12 +08:00
|
|
|
vm = context_get_vm_rcu(ctx);
|
2019-10-04 21:40:09 +08:00
|
|
|
rcu_read_unlock();
|
2019-03-22 17:23:23 +08:00
|
|
|
|
|
|
|
ret = mutex_lock_interruptible(&file_priv->vm_idr_lock);
|
|
|
|
if (ret)
|
|
|
|
goto err_put;
|
|
|
|
|
2019-06-11 17:12:37 +08:00
|
|
|
ret = idr_alloc(&file_priv->vm_idr, vm, 0, 0, GFP_KERNEL);
|
2019-04-25 13:43:33 +08:00
|
|
|
GEM_BUG_ON(!ret);
|
|
|
|
if (ret < 0)
|
|
|
|
goto err_unlock;
|
2019-03-22 17:23:23 +08:00
|
|
|
|
drm/i915: Pull i915_vma_pin under the vm->mutex
Replace the struct_mutex requirement for pinning the i915_vma with the
local vm->mutex instead. Note that the vm->mutex is tainted by the
shrinker (we require unbinding from inside fs-reclaim) and so we cannot
allocate while holding that mutex. Instead we have to preallocate
workers to do allocate and apply the PTE updates after we have we
reserved their slot in the drm_mm (using fences to order the PTE writes
with the GPU work and with later unbind).
In adding the asynchronous vma binding, one subtle requirement is to
avoid coupling the binding fence into the backing object->resv. That is
the asynchronous binding only applies to the vma timeline itself and not
to the pages as that is a more global timeline (the binding of one vma
does not need to be ordered with another vma, nor does the implicit GEM
fencing depend on a vma, only on writes to the backing store). Keeping
the vma binding distinct from the backing store timelines is verified by
a number of async gem_exec_fence and gem_exec_schedule tests. The way we
do this is quite simple, we keep the fence for the vma binding separate
and only wait on it as required, and never add it to the obj->resv
itself.
Another consequence in reducing the locking around the vma is the
destruction of the vma is no longer globally serialised by struct_mutex.
A natural solution would be to add a kref to i915_vma, but that requires
decoupling the reference cycles, possibly by introducing a new
i915_mm_pages object that is own by both obj->mm and vma->pages.
However, we have not taken that route due to the overshadowing lmem/ttm
discussions, and instead play a series of complicated games with
trylocks to (hopefully) ensure that only one destruction path is called!
v2: Add some commentary, and some helpers to reduce patch churn.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191004134015.13204-4-chris@chris-wilson.co.uk
2019-10-04 21:39:58 +08:00
|
|
|
i915_vm_open(vm);
|
2019-03-22 17:23:23 +08:00
|
|
|
|
|
|
|
args->size = 0;
|
2019-04-25 13:43:33 +08:00
|
|
|
args->value = ret;
|
2019-03-22 17:23:23 +08:00
|
|
|
|
|
|
|
ret = 0;
|
|
|
|
err_unlock:
|
|
|
|
mutex_unlock(&file_priv->vm_idr_lock);
|
|
|
|
err_put:
|
2019-06-11 17:12:37 +08:00
|
|
|
i915_vm_put(vm);
|
2019-03-22 17:23:23 +08:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void set_ppgtt_barrier(void *data)
|
|
|
|
{
|
2019-06-11 17:12:37 +08:00
|
|
|
struct i915_address_space *old = data;
|
2019-03-22 17:23:23 +08:00
|
|
|
|
2019-06-11 17:12:37 +08:00
|
|
|
if (INTEL_GEN(old->i915) < 8)
|
|
|
|
gen6_ppgtt_unpin_all(i915_vm_to_ppgtt(old));
|
2019-03-22 17:23:23 +08:00
|
|
|
|
drm/i915: Pull i915_vma_pin under the vm->mutex
Replace the struct_mutex requirement for pinning the i915_vma with the
local vm->mutex instead. Note that the vm->mutex is tainted by the
shrinker (we require unbinding from inside fs-reclaim) and so we cannot
allocate while holding that mutex. Instead we have to preallocate
workers to do allocate and apply the PTE updates after we have we
reserved their slot in the drm_mm (using fences to order the PTE writes
with the GPU work and with later unbind).
In adding the asynchronous vma binding, one subtle requirement is to
avoid coupling the binding fence into the backing object->resv. That is
the asynchronous binding only applies to the vma timeline itself and not
to the pages as that is a more global timeline (the binding of one vma
does not need to be ordered with another vma, nor does the implicit GEM
fencing depend on a vma, only on writes to the backing store). Keeping
the vma binding distinct from the backing store timelines is verified by
a number of async gem_exec_fence and gem_exec_schedule tests. The way we
do this is quite simple, we keep the fence for the vma binding separate
and only wait on it as required, and never add it to the obj->resv
itself.
Another consequence in reducing the locking around the vma is the
destruction of the vma is no longer globally serialised by struct_mutex.
A natural solution would be to add a kref to i915_vma, but that requires
decoupling the reference cycles, possibly by introducing a new
i915_mm_pages object that is own by both obj->mm and vma->pages.
However, we have not taken that route due to the overshadowing lmem/ttm
discussions, and instead play a series of complicated games with
trylocks to (hopefully) ensure that only one destruction path is called!
v2: Add some commentary, and some helpers to reduce patch churn.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191004134015.13204-4-chris@chris-wilson.co.uk
2019-10-04 21:39:58 +08:00
|
|
|
i915_vm_close(old);
|
2019-03-22 17:23:23 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static int emit_ppgtt_update(struct i915_request *rq, void *data)
|
|
|
|
{
|
2019-07-30 22:32:09 +08:00
|
|
|
struct i915_address_space *vm = rq->hw_context->vm;
|
2019-03-22 17:23:23 +08:00
|
|
|
struct intel_engine_cs *engine = rq->engine;
|
2019-04-05 20:38:31 +08:00
|
|
|
u32 base = engine->mmio_base;
|
2019-03-22 17:23:23 +08:00
|
|
|
u32 *cs;
|
|
|
|
int i;
|
|
|
|
|
2019-06-11 17:12:37 +08:00
|
|
|
if (i915_vm_is_4lvl(vm)) {
|
2019-06-11 17:12:38 +08:00
|
|
|
struct i915_ppgtt *ppgtt = i915_vm_to_ppgtt(vm);
|
2019-06-15 00:43:42 +08:00
|
|
|
const dma_addr_t pd_daddr = px_dma(ppgtt->pd);
|
2019-03-22 17:23:23 +08:00
|
|
|
|
|
|
|
cs = intel_ring_begin(rq, 6);
|
|
|
|
if (IS_ERR(cs))
|
|
|
|
return PTR_ERR(cs);
|
|
|
|
|
|
|
|
*cs++ = MI_LOAD_REGISTER_IMM(2);
|
|
|
|
|
2019-04-05 20:38:31 +08:00
|
|
|
*cs++ = i915_mmio_reg_offset(GEN8_RING_PDP_UDW(base, 0));
|
2019-03-22 17:23:23 +08:00
|
|
|
*cs++ = upper_32_bits(pd_daddr);
|
2019-04-05 20:38:31 +08:00
|
|
|
*cs++ = i915_mmio_reg_offset(GEN8_RING_PDP_LDW(base, 0));
|
2019-03-22 17:23:23 +08:00
|
|
|
*cs++ = lower_32_bits(pd_daddr);
|
|
|
|
|
|
|
|
*cs++ = MI_NOOP;
|
|
|
|
intel_ring_advance(rq, cs);
|
|
|
|
} else if (HAS_LOGICAL_RING_CONTEXTS(engine->i915)) {
|
2019-06-11 17:12:38 +08:00
|
|
|
struct i915_ppgtt *ppgtt = i915_vm_to_ppgtt(vm);
|
2019-08-23 22:14:21 +08:00
|
|
|
int err;
|
|
|
|
|
|
|
|
/* Magic required to prevent forcewake errors! */
|
|
|
|
err = engine->emit_flush(rq, EMIT_INVALIDATE);
|
|
|
|
if (err)
|
|
|
|
return err;
|
2019-06-11 17:12:37 +08:00
|
|
|
|
2019-03-22 17:23:23 +08:00
|
|
|
cs = intel_ring_begin(rq, 4 * GEN8_3LVL_PDPES + 2);
|
|
|
|
if (IS_ERR(cs))
|
|
|
|
return PTR_ERR(cs);
|
|
|
|
|
2019-08-23 22:14:21 +08:00
|
|
|
*cs++ = MI_LOAD_REGISTER_IMM(2 * GEN8_3LVL_PDPES) | MI_LRI_FORCE_POSTED;
|
2019-03-22 17:23:23 +08:00
|
|
|
for (i = GEN8_3LVL_PDPES; i--; ) {
|
|
|
|
const dma_addr_t pd_daddr = i915_page_dir_dma_addr(ppgtt, i);
|
|
|
|
|
2019-04-05 20:38:31 +08:00
|
|
|
*cs++ = i915_mmio_reg_offset(GEN8_RING_PDP_UDW(base, i));
|
2019-03-22 17:23:23 +08:00
|
|
|
*cs++ = upper_32_bits(pd_daddr);
|
2019-04-05 20:38:31 +08:00
|
|
|
*cs++ = i915_mmio_reg_offset(GEN8_RING_PDP_LDW(base, i));
|
2019-03-22 17:23:23 +08:00
|
|
|
*cs++ = lower_32_bits(pd_daddr);
|
|
|
|
}
|
|
|
|
*cs++ = MI_NOOP;
|
|
|
|
intel_ring_advance(rq, cs);
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-06-04 23:24:08 +08:00
|
|
|
static bool skip_ppgtt_update(struct intel_context *ce, void *data)
|
|
|
|
{
|
2019-12-06 18:55:26 +08:00
|
|
|
if (!test_bit(CONTEXT_ALLOC_BIT, &ce->flags))
|
|
|
|
return true;
|
|
|
|
|
2019-06-04 23:24:08 +08:00
|
|
|
if (HAS_LOGICAL_RING_CONTEXTS(ce->engine->i915))
|
2019-12-06 18:55:26 +08:00
|
|
|
return false;
|
|
|
|
|
|
|
|
if (!atomic_read(&ce->pin_count))
|
|
|
|
return true;
|
|
|
|
|
|
|
|
/* ppGTT is not part of the legacy context image */
|
|
|
|
if (gen6_ppgtt_pin(i915_vm_to_ppgtt(ce->vm)))
|
|
|
|
return true;
|
|
|
|
|
|
|
|
return false;
|
2019-06-04 23:24:08 +08:00
|
|
|
}
|
|
|
|
|
2019-03-30 18:03:49 +08:00
|
|
|
static int set_ppgtt(struct drm_i915_file_private *file_priv,
|
|
|
|
struct i915_gem_context *ctx,
|
2019-03-22 17:23:23 +08:00
|
|
|
struct drm_i915_gem_context_param *args)
|
|
|
|
{
|
2019-06-11 17:12:37 +08:00
|
|
|
struct i915_address_space *vm, *old;
|
2019-03-22 17:23:23 +08:00
|
|
|
int err;
|
|
|
|
|
|
|
|
if (args->size)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2019-10-04 21:40:09 +08:00
|
|
|
if (!rcu_access_pointer(ctx->vm))
|
2019-03-22 17:23:23 +08:00
|
|
|
return -ENODEV;
|
|
|
|
|
|
|
|
if (upper_32_bits(args->value))
|
|
|
|
return -ENOENT;
|
|
|
|
|
2019-08-31 02:03:25 +08:00
|
|
|
rcu_read_lock();
|
2019-06-11 17:12:37 +08:00
|
|
|
vm = idr_find(&file_priv->vm_idr, args->value);
|
2019-08-31 02:03:25 +08:00
|
|
|
if (vm && !kref_get_unless_zero(&vm->ref))
|
|
|
|
vm = NULL;
|
|
|
|
rcu_read_unlock();
|
2019-06-11 17:12:37 +08:00
|
|
|
if (!vm)
|
2019-03-22 17:23:23 +08:00
|
|
|
return -ENOENT;
|
|
|
|
|
2019-10-04 21:40:09 +08:00
|
|
|
err = mutex_lock_interruptible(&ctx->mutex);
|
2019-03-22 17:23:23 +08:00
|
|
|
if (err)
|
|
|
|
goto out;
|
|
|
|
|
2019-10-04 21:40:09 +08:00
|
|
|
if (i915_gem_context_is_closed(ctx)) {
|
|
|
|
err = -ENOENT;
|
2019-11-06 22:41:55 +08:00
|
|
|
goto unlock;
|
2019-10-04 21:40:09 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
if (vm == rcu_access_pointer(ctx->vm))
|
2019-03-22 17:23:23 +08:00
|
|
|
goto unlock;
|
|
|
|
|
|
|
|
/* Teardown the existing obj:vma cache, it will have to be rebuilt. */
|
|
|
|
lut_close(ctx);
|
|
|
|
|
2019-06-11 17:12:37 +08:00
|
|
|
old = __set_ppgtt(ctx, vm);
|
2019-03-22 17:23:23 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* We need to flush any requests using the current ppgtt before
|
|
|
|
* we release it as the requests do not hold a reference themselves,
|
|
|
|
* only indirectly through the context.
|
|
|
|
*/
|
|
|
|
err = context_barrier_task(ctx, ALL_ENGINES,
|
2019-06-04 23:24:08 +08:00
|
|
|
skip_ppgtt_update,
|
2019-03-22 17:23:23 +08:00
|
|
|
emit_ppgtt_update,
|
|
|
|
set_ppgtt_barrier,
|
|
|
|
old);
|
|
|
|
if (err) {
|
drm/i915: Pull i915_vma_pin under the vm->mutex
Replace the struct_mutex requirement for pinning the i915_vma with the
local vm->mutex instead. Note that the vm->mutex is tainted by the
shrinker (we require unbinding from inside fs-reclaim) and so we cannot
allocate while holding that mutex. Instead we have to preallocate
workers to do allocate and apply the PTE updates after we have we
reserved their slot in the drm_mm (using fences to order the PTE writes
with the GPU work and with later unbind).
In adding the asynchronous vma binding, one subtle requirement is to
avoid coupling the binding fence into the backing object->resv. That is
the asynchronous binding only applies to the vma timeline itself and not
to the pages as that is a more global timeline (the binding of one vma
does not need to be ordered with another vma, nor does the implicit GEM
fencing depend on a vma, only on writes to the backing store). Keeping
the vma binding distinct from the backing store timelines is verified by
a number of async gem_exec_fence and gem_exec_schedule tests. The way we
do this is quite simple, we keep the fence for the vma binding separate
and only wait on it as required, and never add it to the obj->resv
itself.
Another consequence in reducing the locking around the vma is the
destruction of the vma is no longer globally serialised by struct_mutex.
A natural solution would be to add a kref to i915_vma, but that requires
decoupling the reference cycles, possibly by introducing a new
i915_mm_pages object that is own by both obj->mm and vma->pages.
However, we have not taken that route due to the overshadowing lmem/ttm
discussions, and instead play a series of complicated games with
trylocks to (hopefully) ensure that only one destruction path is called!
v2: Add some commentary, and some helpers to reduce patch churn.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191004134015.13204-4-chris@chris-wilson.co.uk
2019-10-04 21:39:58 +08:00
|
|
|
i915_vm_close(__set_ppgtt(ctx, old));
|
|
|
|
i915_vm_close(old);
|
2019-03-22 17:23:23 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
unlock:
|
2019-10-04 21:40:09 +08:00
|
|
|
mutex_unlock(&ctx->mutex);
|
2019-03-22 17:23:23 +08:00
|
|
|
out:
|
2019-06-11 17:12:37 +08:00
|
|
|
i915_vm_put(vm);
|
2019-03-22 17:23:23 +08:00
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only)
We want to allow userspace to reconfigure the subslice configuration on a
per context basis.
This is required for the functional requirement of shutting down non-VME
enabled sub-slices on Gen11 parts.
To do so, we expose a context parameter to allow adjustment of the RPCS
register stored within the context image (and currently not accessible via
LRI).
If the context is adjusted before first use or whilst idle, the adjustment
is for "free"; otherwise if the context is active we queue a request to do
so (using the kernel context), following all other activity by that
context, which is also marked as barrier for all following submission
against the same context.
Since the overhead of device re-configuration during context switching can
be significant, especially in multi-context workloads, we limit this new
uAPI to only support the Gen11 VME use case. In this use case either the
device is fully enabled, and exactly one slice and half of the subslices
are enabled.
Example usage:
struct drm_i915_gem_context_param_sseu sseu = { };
struct drm_i915_gem_context_param arg = {
.param = I915_CONTEXT_PARAM_SSEU,
.ctx_id = gem_context_create(fd),
.size = sizeof(sseu),
.value = to_user_pointer(&sseu)
};
/* Query device defaults. */
gem_context_get_param(fd, &arg);
/* Set VME configuration on a 1x6x8 part. */
sseu.slice_mask = 0x1;
sseu.subslice_mask = 0xe0;
gem_context_set_param(fd, &arg);
v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu()
(Lionel)
v3: Add ability to program this per engine (Chris)
v4: Move most get_sseu() into i915_gem_context.c (Lionel)
v5: Validate sseu configuration against the device's capabilities (Lionel)
v6: Change context powergating settings through MI_SDM on kernel context
(Chris)
v7: Synchronize the requests following a powergating setting change using
a global dependency (Chris)
Iterate timelines through dev_priv.gt.active_rings (Tvrtko)
Disable RPCS configuration setting for non capable users
(Lionel/Tvrtko)
v8: s/union intel_sseu/struct intel_sseu/ (Lionel)
s/dev_priv/i915/ (Tvrtko)
Change uapi class/instance fields to u16 (Tvrtko)
Bump mask fields to 64bits (Lionel)
Don't return EPERM when dynamic sseu is disabled (Tvrtko)
v9: Import context image into kernel context's ppgtt only when
reconfiguring powergated slice/subslices (Chris)
Use aliasing ppgtt when needed (Michel)
Tvrtko Ursulin:
v10:
* Update for upstream changes.
* Request submit needs a RPM reference.
* Reject on !FULL_PPGTT for simplicity.
* Pull out get/set param to helpers for readability and less indent.
* Use i915_request_await_dma_fence in add_global_barrier to skip waits
on the same timeline and avoid GEM_BUG_ON.
* No need to explicitly assign a NULL pointer to engine in legacy mode.
* No need to move gen8_make_rpcs up.
* Factored out global barrier as prep patch.
* Allow to only CAP_SYS_ADMIN if !Gen11.
v11:
* Remove engine vfunc in favour of local helper. (Chris Wilson)
* Stop retiring requests before updates since it is not needed
(Chris Wilson)
* Implement direct CPU update path for idle contexts. (Chris Wilson)
* Left side dependency needs only be on the same context timeline.
(Chris Wilson)
* It is sufficient to order the timeline. (Chris Wilson)
* Reject !RCS configuration attempts with -ENODEV for now.
v12:
* Rebase for make_rpcs.
v13:
* Centralize SSEU normalization to make_rpcs.
* Type width checking (uAPI <-> implementation).
* Gen11 restrictions uAPI checks.
* Gen11 subslice count differences handling.
Chris Wilson:
* args->size handling fixes.
* Update context image from GGTT.
* Postpone context image update to pinning.
* Use i915_gem_active_raw instead of last_request_on_engine.
v14:
* Add activity tracker on intel_context to fix the lifetime issues
and simplify the code. (Chris Wilson)
v15:
* Fix context pin leak if no space in ring by simplifying the
context pinning sequence.
v16:
* Rebase for context get/set param locking changes.
* Just -ENODEV on !Gen11. (Joonas)
v17:
* Fix one Gen11 subslice enablement rule.
* Handle error from i915_sw_fence_await_sw_fence_gfp. (Chris Wilson)
v18:
* Update commit message. (Joonas)
* Restrict uAPI to VME use case. (Joonas)
v19:
* Rebase.
v20:
* Rebase for ce->active_tracker.
v21:
* Rebase for IS_GEN changes.
v22:
* Reserve uAPI for flags straight away. (Chris Wilson)
v23:
* Rebase for RUNTIME_INFO.
v24:
* Added some headline docs for the uapi usage. (Joonas/Chris)
v25:
* Renamed class/instance to engine_class/engine_instance to avoid clash
with C++ keyword. (Tony Ye)
v26:
* Rebased for runtime pm api changes.
v27:
* Rebased for intel_context_init.
* Wrap commit msg to 75.
v28:
(Chris Wilson)
* Use i915_gem_ggtt.
* Use i915_request_await_dma_fence to show a better example.
v29:
* i915_timeline_set_barrier can now fail. (Chris Wilson)
v30:
* Capture some acks.
v31:
* Drop the WARN_ON from use controllable paths. (Chris Wilson)
* Use overflows_type for all checks.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100899
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107634
Issue: https://github.com/intel/media-driver/issues/267
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Zhipeng Gong <zhipeng.gong@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tony Ye <tony.ye@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: Timo Aaltonen <timo.aaltonen@canonical.com>
Acked-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Stéphane Marchesin <marcheu@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190205095032.22673-4-tvrtko.ursulin@linux.intel.com
2019-02-05 17:50:31 +08:00
|
|
|
static int gen8_emit_rpcs_config(struct i915_request *rq,
|
|
|
|
struct intel_context *ce,
|
|
|
|
struct intel_sseu sseu)
|
|
|
|
{
|
|
|
|
u64 offset;
|
|
|
|
u32 *cs;
|
|
|
|
|
|
|
|
cs = intel_ring_begin(rq, 4);
|
|
|
|
if (IS_ERR(cs))
|
|
|
|
return PTR_ERR(cs);
|
|
|
|
|
|
|
|
offset = i915_ggtt_offset(ce->state) +
|
|
|
|
LRC_STATE_PN * PAGE_SIZE +
|
2019-09-24 22:59:50 +08:00
|
|
|
CTX_R_PWR_CLK_STATE * 4;
|
drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only)
We want to allow userspace to reconfigure the subslice configuration on a
per context basis.
This is required for the functional requirement of shutting down non-VME
enabled sub-slices on Gen11 parts.
To do so, we expose a context parameter to allow adjustment of the RPCS
register stored within the context image (and currently not accessible via
LRI).
If the context is adjusted before first use or whilst idle, the adjustment
is for "free"; otherwise if the context is active we queue a request to do
so (using the kernel context), following all other activity by that
context, which is also marked as barrier for all following submission
against the same context.
Since the overhead of device re-configuration during context switching can
be significant, especially in multi-context workloads, we limit this new
uAPI to only support the Gen11 VME use case. In this use case either the
device is fully enabled, and exactly one slice and half of the subslices
are enabled.
Example usage:
struct drm_i915_gem_context_param_sseu sseu = { };
struct drm_i915_gem_context_param arg = {
.param = I915_CONTEXT_PARAM_SSEU,
.ctx_id = gem_context_create(fd),
.size = sizeof(sseu),
.value = to_user_pointer(&sseu)
};
/* Query device defaults. */
gem_context_get_param(fd, &arg);
/* Set VME configuration on a 1x6x8 part. */
sseu.slice_mask = 0x1;
sseu.subslice_mask = 0xe0;
gem_context_set_param(fd, &arg);
v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu()
(Lionel)
v3: Add ability to program this per engine (Chris)
v4: Move most get_sseu() into i915_gem_context.c (Lionel)
v5: Validate sseu configuration against the device's capabilities (Lionel)
v6: Change context powergating settings through MI_SDM on kernel context
(Chris)
v7: Synchronize the requests following a powergating setting change using
a global dependency (Chris)
Iterate timelines through dev_priv.gt.active_rings (Tvrtko)
Disable RPCS configuration setting for non capable users
(Lionel/Tvrtko)
v8: s/union intel_sseu/struct intel_sseu/ (Lionel)
s/dev_priv/i915/ (Tvrtko)
Change uapi class/instance fields to u16 (Tvrtko)
Bump mask fields to 64bits (Lionel)
Don't return EPERM when dynamic sseu is disabled (Tvrtko)
v9: Import context image into kernel context's ppgtt only when
reconfiguring powergated slice/subslices (Chris)
Use aliasing ppgtt when needed (Michel)
Tvrtko Ursulin:
v10:
* Update for upstream changes.
* Request submit needs a RPM reference.
* Reject on !FULL_PPGTT for simplicity.
* Pull out get/set param to helpers for readability and less indent.
* Use i915_request_await_dma_fence in add_global_barrier to skip waits
on the same timeline and avoid GEM_BUG_ON.
* No need to explicitly assign a NULL pointer to engine in legacy mode.
* No need to move gen8_make_rpcs up.
* Factored out global barrier as prep patch.
* Allow to only CAP_SYS_ADMIN if !Gen11.
v11:
* Remove engine vfunc in favour of local helper. (Chris Wilson)
* Stop retiring requests before updates since it is not needed
(Chris Wilson)
* Implement direct CPU update path for idle contexts. (Chris Wilson)
* Left side dependency needs only be on the same context timeline.
(Chris Wilson)
* It is sufficient to order the timeline. (Chris Wilson)
* Reject !RCS configuration attempts with -ENODEV for now.
v12:
* Rebase for make_rpcs.
v13:
* Centralize SSEU normalization to make_rpcs.
* Type width checking (uAPI <-> implementation).
* Gen11 restrictions uAPI checks.
* Gen11 subslice count differences handling.
Chris Wilson:
* args->size handling fixes.
* Update context image from GGTT.
* Postpone context image update to pinning.
* Use i915_gem_active_raw instead of last_request_on_engine.
v14:
* Add activity tracker on intel_context to fix the lifetime issues
and simplify the code. (Chris Wilson)
v15:
* Fix context pin leak if no space in ring by simplifying the
context pinning sequence.
v16:
* Rebase for context get/set param locking changes.
* Just -ENODEV on !Gen11. (Joonas)
v17:
* Fix one Gen11 subslice enablement rule.
* Handle error from i915_sw_fence_await_sw_fence_gfp. (Chris Wilson)
v18:
* Update commit message. (Joonas)
* Restrict uAPI to VME use case. (Joonas)
v19:
* Rebase.
v20:
* Rebase for ce->active_tracker.
v21:
* Rebase for IS_GEN changes.
v22:
* Reserve uAPI for flags straight away. (Chris Wilson)
v23:
* Rebase for RUNTIME_INFO.
v24:
* Added some headline docs for the uapi usage. (Joonas/Chris)
v25:
* Renamed class/instance to engine_class/engine_instance to avoid clash
with C++ keyword. (Tony Ye)
v26:
* Rebased for runtime pm api changes.
v27:
* Rebased for intel_context_init.
* Wrap commit msg to 75.
v28:
(Chris Wilson)
* Use i915_gem_ggtt.
* Use i915_request_await_dma_fence to show a better example.
v29:
* i915_timeline_set_barrier can now fail. (Chris Wilson)
v30:
* Capture some acks.
v31:
* Drop the WARN_ON from use controllable paths. (Chris Wilson)
* Use overflows_type for all checks.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100899
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107634
Issue: https://github.com/intel/media-driver/issues/267
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Zhipeng Gong <zhipeng.gong@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tony Ye <tony.ye@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: Timo Aaltonen <timo.aaltonen@canonical.com>
Acked-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Stéphane Marchesin <marcheu@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190205095032.22673-4-tvrtko.ursulin@linux.intel.com
2019-02-05 17:50:31 +08:00
|
|
|
|
|
|
|
*cs++ = MI_STORE_DWORD_IMM_GEN4 | MI_USE_GGTT;
|
|
|
|
*cs++ = lower_32_bits(offset);
|
|
|
|
*cs++ = upper_32_bits(offset);
|
2019-04-24 17:51:34 +08:00
|
|
|
*cs++ = intel_sseu_make_rpcs(rq->i915, &sseu);
|
drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only)
We want to allow userspace to reconfigure the subslice configuration on a
per context basis.
This is required for the functional requirement of shutting down non-VME
enabled sub-slices on Gen11 parts.
To do so, we expose a context parameter to allow adjustment of the RPCS
register stored within the context image (and currently not accessible via
LRI).
If the context is adjusted before first use or whilst idle, the adjustment
is for "free"; otherwise if the context is active we queue a request to do
so (using the kernel context), following all other activity by that
context, which is also marked as barrier for all following submission
against the same context.
Since the overhead of device re-configuration during context switching can
be significant, especially in multi-context workloads, we limit this new
uAPI to only support the Gen11 VME use case. In this use case either the
device is fully enabled, and exactly one slice and half of the subslices
are enabled.
Example usage:
struct drm_i915_gem_context_param_sseu sseu = { };
struct drm_i915_gem_context_param arg = {
.param = I915_CONTEXT_PARAM_SSEU,
.ctx_id = gem_context_create(fd),
.size = sizeof(sseu),
.value = to_user_pointer(&sseu)
};
/* Query device defaults. */
gem_context_get_param(fd, &arg);
/* Set VME configuration on a 1x6x8 part. */
sseu.slice_mask = 0x1;
sseu.subslice_mask = 0xe0;
gem_context_set_param(fd, &arg);
v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu()
(Lionel)
v3: Add ability to program this per engine (Chris)
v4: Move most get_sseu() into i915_gem_context.c (Lionel)
v5: Validate sseu configuration against the device's capabilities (Lionel)
v6: Change context powergating settings through MI_SDM on kernel context
(Chris)
v7: Synchronize the requests following a powergating setting change using
a global dependency (Chris)
Iterate timelines through dev_priv.gt.active_rings (Tvrtko)
Disable RPCS configuration setting for non capable users
(Lionel/Tvrtko)
v8: s/union intel_sseu/struct intel_sseu/ (Lionel)
s/dev_priv/i915/ (Tvrtko)
Change uapi class/instance fields to u16 (Tvrtko)
Bump mask fields to 64bits (Lionel)
Don't return EPERM when dynamic sseu is disabled (Tvrtko)
v9: Import context image into kernel context's ppgtt only when
reconfiguring powergated slice/subslices (Chris)
Use aliasing ppgtt when needed (Michel)
Tvrtko Ursulin:
v10:
* Update for upstream changes.
* Request submit needs a RPM reference.
* Reject on !FULL_PPGTT for simplicity.
* Pull out get/set param to helpers for readability and less indent.
* Use i915_request_await_dma_fence in add_global_barrier to skip waits
on the same timeline and avoid GEM_BUG_ON.
* No need to explicitly assign a NULL pointer to engine in legacy mode.
* No need to move gen8_make_rpcs up.
* Factored out global barrier as prep patch.
* Allow to only CAP_SYS_ADMIN if !Gen11.
v11:
* Remove engine vfunc in favour of local helper. (Chris Wilson)
* Stop retiring requests before updates since it is not needed
(Chris Wilson)
* Implement direct CPU update path for idle contexts. (Chris Wilson)
* Left side dependency needs only be on the same context timeline.
(Chris Wilson)
* It is sufficient to order the timeline. (Chris Wilson)
* Reject !RCS configuration attempts with -ENODEV for now.
v12:
* Rebase for make_rpcs.
v13:
* Centralize SSEU normalization to make_rpcs.
* Type width checking (uAPI <-> implementation).
* Gen11 restrictions uAPI checks.
* Gen11 subslice count differences handling.
Chris Wilson:
* args->size handling fixes.
* Update context image from GGTT.
* Postpone context image update to pinning.
* Use i915_gem_active_raw instead of last_request_on_engine.
v14:
* Add activity tracker on intel_context to fix the lifetime issues
and simplify the code. (Chris Wilson)
v15:
* Fix context pin leak if no space in ring by simplifying the
context pinning sequence.
v16:
* Rebase for context get/set param locking changes.
* Just -ENODEV on !Gen11. (Joonas)
v17:
* Fix one Gen11 subslice enablement rule.
* Handle error from i915_sw_fence_await_sw_fence_gfp. (Chris Wilson)
v18:
* Update commit message. (Joonas)
* Restrict uAPI to VME use case. (Joonas)
v19:
* Rebase.
v20:
* Rebase for ce->active_tracker.
v21:
* Rebase for IS_GEN changes.
v22:
* Reserve uAPI for flags straight away. (Chris Wilson)
v23:
* Rebase for RUNTIME_INFO.
v24:
* Added some headline docs for the uapi usage. (Joonas/Chris)
v25:
* Renamed class/instance to engine_class/engine_instance to avoid clash
with C++ keyword. (Tony Ye)
v26:
* Rebased for runtime pm api changes.
v27:
* Rebased for intel_context_init.
* Wrap commit msg to 75.
v28:
(Chris Wilson)
* Use i915_gem_ggtt.
* Use i915_request_await_dma_fence to show a better example.
v29:
* i915_timeline_set_barrier can now fail. (Chris Wilson)
v30:
* Capture some acks.
v31:
* Drop the WARN_ON from use controllable paths. (Chris Wilson)
* Use overflows_type for all checks.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100899
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107634
Issue: https://github.com/intel/media-driver/issues/267
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Zhipeng Gong <zhipeng.gong@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tony Ye <tony.ye@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: Timo Aaltonen <timo.aaltonen@canonical.com>
Acked-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Stéphane Marchesin <marcheu@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190205095032.22673-4-tvrtko.ursulin@linux.intel.com
2019-02-05 17:50:31 +08:00
|
|
|
|
|
|
|
intel_ring_advance(rq, cs);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
2019-03-08 21:25:22 +08:00
|
|
|
gen8_modify_rpcs(struct intel_context *ce, struct intel_sseu sseu)
|
drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only)
We want to allow userspace to reconfigure the subslice configuration on a
per context basis.
This is required for the functional requirement of shutting down non-VME
enabled sub-slices on Gen11 parts.
To do so, we expose a context parameter to allow adjustment of the RPCS
register stored within the context image (and currently not accessible via
LRI).
If the context is adjusted before first use or whilst idle, the adjustment
is for "free"; otherwise if the context is active we queue a request to do
so (using the kernel context), following all other activity by that
context, which is also marked as barrier for all following submission
against the same context.
Since the overhead of device re-configuration during context switching can
be significant, especially in multi-context workloads, we limit this new
uAPI to only support the Gen11 VME use case. In this use case either the
device is fully enabled, and exactly one slice and half of the subslices
are enabled.
Example usage:
struct drm_i915_gem_context_param_sseu sseu = { };
struct drm_i915_gem_context_param arg = {
.param = I915_CONTEXT_PARAM_SSEU,
.ctx_id = gem_context_create(fd),
.size = sizeof(sseu),
.value = to_user_pointer(&sseu)
};
/* Query device defaults. */
gem_context_get_param(fd, &arg);
/* Set VME configuration on a 1x6x8 part. */
sseu.slice_mask = 0x1;
sseu.subslice_mask = 0xe0;
gem_context_set_param(fd, &arg);
v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu()
(Lionel)
v3: Add ability to program this per engine (Chris)
v4: Move most get_sseu() into i915_gem_context.c (Lionel)
v5: Validate sseu configuration against the device's capabilities (Lionel)
v6: Change context powergating settings through MI_SDM on kernel context
(Chris)
v7: Synchronize the requests following a powergating setting change using
a global dependency (Chris)
Iterate timelines through dev_priv.gt.active_rings (Tvrtko)
Disable RPCS configuration setting for non capable users
(Lionel/Tvrtko)
v8: s/union intel_sseu/struct intel_sseu/ (Lionel)
s/dev_priv/i915/ (Tvrtko)
Change uapi class/instance fields to u16 (Tvrtko)
Bump mask fields to 64bits (Lionel)
Don't return EPERM when dynamic sseu is disabled (Tvrtko)
v9: Import context image into kernel context's ppgtt only when
reconfiguring powergated slice/subslices (Chris)
Use aliasing ppgtt when needed (Michel)
Tvrtko Ursulin:
v10:
* Update for upstream changes.
* Request submit needs a RPM reference.
* Reject on !FULL_PPGTT for simplicity.
* Pull out get/set param to helpers for readability and less indent.
* Use i915_request_await_dma_fence in add_global_barrier to skip waits
on the same timeline and avoid GEM_BUG_ON.
* No need to explicitly assign a NULL pointer to engine in legacy mode.
* No need to move gen8_make_rpcs up.
* Factored out global barrier as prep patch.
* Allow to only CAP_SYS_ADMIN if !Gen11.
v11:
* Remove engine vfunc in favour of local helper. (Chris Wilson)
* Stop retiring requests before updates since it is not needed
(Chris Wilson)
* Implement direct CPU update path for idle contexts. (Chris Wilson)
* Left side dependency needs only be on the same context timeline.
(Chris Wilson)
* It is sufficient to order the timeline. (Chris Wilson)
* Reject !RCS configuration attempts with -ENODEV for now.
v12:
* Rebase for make_rpcs.
v13:
* Centralize SSEU normalization to make_rpcs.
* Type width checking (uAPI <-> implementation).
* Gen11 restrictions uAPI checks.
* Gen11 subslice count differences handling.
Chris Wilson:
* args->size handling fixes.
* Update context image from GGTT.
* Postpone context image update to pinning.
* Use i915_gem_active_raw instead of last_request_on_engine.
v14:
* Add activity tracker on intel_context to fix the lifetime issues
and simplify the code. (Chris Wilson)
v15:
* Fix context pin leak if no space in ring by simplifying the
context pinning sequence.
v16:
* Rebase for context get/set param locking changes.
* Just -ENODEV on !Gen11. (Joonas)
v17:
* Fix one Gen11 subslice enablement rule.
* Handle error from i915_sw_fence_await_sw_fence_gfp. (Chris Wilson)
v18:
* Update commit message. (Joonas)
* Restrict uAPI to VME use case. (Joonas)
v19:
* Rebase.
v20:
* Rebase for ce->active_tracker.
v21:
* Rebase for IS_GEN changes.
v22:
* Reserve uAPI for flags straight away. (Chris Wilson)
v23:
* Rebase for RUNTIME_INFO.
v24:
* Added some headline docs for the uapi usage. (Joonas/Chris)
v25:
* Renamed class/instance to engine_class/engine_instance to avoid clash
with C++ keyword. (Tony Ye)
v26:
* Rebased for runtime pm api changes.
v27:
* Rebased for intel_context_init.
* Wrap commit msg to 75.
v28:
(Chris Wilson)
* Use i915_gem_ggtt.
* Use i915_request_await_dma_fence to show a better example.
v29:
* i915_timeline_set_barrier can now fail. (Chris Wilson)
v30:
* Capture some acks.
v31:
* Drop the WARN_ON from use controllable paths. (Chris Wilson)
* Use overflows_type for all checks.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100899
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107634
Issue: https://github.com/intel/media-driver/issues/267
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Zhipeng Gong <zhipeng.gong@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tony Ye <tony.ye@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: Timo Aaltonen <timo.aaltonen@canonical.com>
Acked-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Stéphane Marchesin <marcheu@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190205095032.22673-4-tvrtko.ursulin@linux.intel.com
2019-02-05 17:50:31 +08:00
|
|
|
{
|
2019-04-08 17:17:03 +08:00
|
|
|
struct i915_request *rq;
|
drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only)
We want to allow userspace to reconfigure the subslice configuration on a
per context basis.
This is required for the functional requirement of shutting down non-VME
enabled sub-slices on Gen11 parts.
To do so, we expose a context parameter to allow adjustment of the RPCS
register stored within the context image (and currently not accessible via
LRI).
If the context is adjusted before first use or whilst idle, the adjustment
is for "free"; otherwise if the context is active we queue a request to do
so (using the kernel context), following all other activity by that
context, which is also marked as barrier for all following submission
against the same context.
Since the overhead of device re-configuration during context switching can
be significant, especially in multi-context workloads, we limit this new
uAPI to only support the Gen11 VME use case. In this use case either the
device is fully enabled, and exactly one slice and half of the subslices
are enabled.
Example usage:
struct drm_i915_gem_context_param_sseu sseu = { };
struct drm_i915_gem_context_param arg = {
.param = I915_CONTEXT_PARAM_SSEU,
.ctx_id = gem_context_create(fd),
.size = sizeof(sseu),
.value = to_user_pointer(&sseu)
};
/* Query device defaults. */
gem_context_get_param(fd, &arg);
/* Set VME configuration on a 1x6x8 part. */
sseu.slice_mask = 0x1;
sseu.subslice_mask = 0xe0;
gem_context_set_param(fd, &arg);
v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu()
(Lionel)
v3: Add ability to program this per engine (Chris)
v4: Move most get_sseu() into i915_gem_context.c (Lionel)
v5: Validate sseu configuration against the device's capabilities (Lionel)
v6: Change context powergating settings through MI_SDM on kernel context
(Chris)
v7: Synchronize the requests following a powergating setting change using
a global dependency (Chris)
Iterate timelines through dev_priv.gt.active_rings (Tvrtko)
Disable RPCS configuration setting for non capable users
(Lionel/Tvrtko)
v8: s/union intel_sseu/struct intel_sseu/ (Lionel)
s/dev_priv/i915/ (Tvrtko)
Change uapi class/instance fields to u16 (Tvrtko)
Bump mask fields to 64bits (Lionel)
Don't return EPERM when dynamic sseu is disabled (Tvrtko)
v9: Import context image into kernel context's ppgtt only when
reconfiguring powergated slice/subslices (Chris)
Use aliasing ppgtt when needed (Michel)
Tvrtko Ursulin:
v10:
* Update for upstream changes.
* Request submit needs a RPM reference.
* Reject on !FULL_PPGTT for simplicity.
* Pull out get/set param to helpers for readability and less indent.
* Use i915_request_await_dma_fence in add_global_barrier to skip waits
on the same timeline and avoid GEM_BUG_ON.
* No need to explicitly assign a NULL pointer to engine in legacy mode.
* No need to move gen8_make_rpcs up.
* Factored out global barrier as prep patch.
* Allow to only CAP_SYS_ADMIN if !Gen11.
v11:
* Remove engine vfunc in favour of local helper. (Chris Wilson)
* Stop retiring requests before updates since it is not needed
(Chris Wilson)
* Implement direct CPU update path for idle contexts. (Chris Wilson)
* Left side dependency needs only be on the same context timeline.
(Chris Wilson)
* It is sufficient to order the timeline. (Chris Wilson)
* Reject !RCS configuration attempts with -ENODEV for now.
v12:
* Rebase for make_rpcs.
v13:
* Centralize SSEU normalization to make_rpcs.
* Type width checking (uAPI <-> implementation).
* Gen11 restrictions uAPI checks.
* Gen11 subslice count differences handling.
Chris Wilson:
* args->size handling fixes.
* Update context image from GGTT.
* Postpone context image update to pinning.
* Use i915_gem_active_raw instead of last_request_on_engine.
v14:
* Add activity tracker on intel_context to fix the lifetime issues
and simplify the code. (Chris Wilson)
v15:
* Fix context pin leak if no space in ring by simplifying the
context pinning sequence.
v16:
* Rebase for context get/set param locking changes.
* Just -ENODEV on !Gen11. (Joonas)
v17:
* Fix one Gen11 subslice enablement rule.
* Handle error from i915_sw_fence_await_sw_fence_gfp. (Chris Wilson)
v18:
* Update commit message. (Joonas)
* Restrict uAPI to VME use case. (Joonas)
v19:
* Rebase.
v20:
* Rebase for ce->active_tracker.
v21:
* Rebase for IS_GEN changes.
v22:
* Reserve uAPI for flags straight away. (Chris Wilson)
v23:
* Rebase for RUNTIME_INFO.
v24:
* Added some headline docs for the uapi usage. (Joonas/Chris)
v25:
* Renamed class/instance to engine_class/engine_instance to avoid clash
with C++ keyword. (Tony Ye)
v26:
* Rebased for runtime pm api changes.
v27:
* Rebased for intel_context_init.
* Wrap commit msg to 75.
v28:
(Chris Wilson)
* Use i915_gem_ggtt.
* Use i915_request_await_dma_fence to show a better example.
v29:
* i915_timeline_set_barrier can now fail. (Chris Wilson)
v30:
* Capture some acks.
v31:
* Drop the WARN_ON from use controllable paths. (Chris Wilson)
* Use overflows_type for all checks.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100899
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107634
Issue: https://github.com/intel/media-driver/issues/267
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Zhipeng Gong <zhipeng.gong@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tony Ye <tony.ye@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: Timo Aaltonen <timo.aaltonen@canonical.com>
Acked-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Stéphane Marchesin <marcheu@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190205095032.22673-4-tvrtko.ursulin@linux.intel.com
2019-02-05 17:50:31 +08:00
|
|
|
int ret;
|
|
|
|
|
2019-03-08 21:25:22 +08:00
|
|
|
lockdep_assert_held(&ce->pin_mutex);
|
drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only)
We want to allow userspace to reconfigure the subslice configuration on a
per context basis.
This is required for the functional requirement of shutting down non-VME
enabled sub-slices on Gen11 parts.
To do so, we expose a context parameter to allow adjustment of the RPCS
register stored within the context image (and currently not accessible via
LRI).
If the context is adjusted before first use or whilst idle, the adjustment
is for "free"; otherwise if the context is active we queue a request to do
so (using the kernel context), following all other activity by that
context, which is also marked as barrier for all following submission
against the same context.
Since the overhead of device re-configuration during context switching can
be significant, especially in multi-context workloads, we limit this new
uAPI to only support the Gen11 VME use case. In this use case either the
device is fully enabled, and exactly one slice and half of the subslices
are enabled.
Example usage:
struct drm_i915_gem_context_param_sseu sseu = { };
struct drm_i915_gem_context_param arg = {
.param = I915_CONTEXT_PARAM_SSEU,
.ctx_id = gem_context_create(fd),
.size = sizeof(sseu),
.value = to_user_pointer(&sseu)
};
/* Query device defaults. */
gem_context_get_param(fd, &arg);
/* Set VME configuration on a 1x6x8 part. */
sseu.slice_mask = 0x1;
sseu.subslice_mask = 0xe0;
gem_context_set_param(fd, &arg);
v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu()
(Lionel)
v3: Add ability to program this per engine (Chris)
v4: Move most get_sseu() into i915_gem_context.c (Lionel)
v5: Validate sseu configuration against the device's capabilities (Lionel)
v6: Change context powergating settings through MI_SDM on kernel context
(Chris)
v7: Synchronize the requests following a powergating setting change using
a global dependency (Chris)
Iterate timelines through dev_priv.gt.active_rings (Tvrtko)
Disable RPCS configuration setting for non capable users
(Lionel/Tvrtko)
v8: s/union intel_sseu/struct intel_sseu/ (Lionel)
s/dev_priv/i915/ (Tvrtko)
Change uapi class/instance fields to u16 (Tvrtko)
Bump mask fields to 64bits (Lionel)
Don't return EPERM when dynamic sseu is disabled (Tvrtko)
v9: Import context image into kernel context's ppgtt only when
reconfiguring powergated slice/subslices (Chris)
Use aliasing ppgtt when needed (Michel)
Tvrtko Ursulin:
v10:
* Update for upstream changes.
* Request submit needs a RPM reference.
* Reject on !FULL_PPGTT for simplicity.
* Pull out get/set param to helpers for readability and less indent.
* Use i915_request_await_dma_fence in add_global_barrier to skip waits
on the same timeline and avoid GEM_BUG_ON.
* No need to explicitly assign a NULL pointer to engine in legacy mode.
* No need to move gen8_make_rpcs up.
* Factored out global barrier as prep patch.
* Allow to only CAP_SYS_ADMIN if !Gen11.
v11:
* Remove engine vfunc in favour of local helper. (Chris Wilson)
* Stop retiring requests before updates since it is not needed
(Chris Wilson)
* Implement direct CPU update path for idle contexts. (Chris Wilson)
* Left side dependency needs only be on the same context timeline.
(Chris Wilson)
* It is sufficient to order the timeline. (Chris Wilson)
* Reject !RCS configuration attempts with -ENODEV for now.
v12:
* Rebase for make_rpcs.
v13:
* Centralize SSEU normalization to make_rpcs.
* Type width checking (uAPI <-> implementation).
* Gen11 restrictions uAPI checks.
* Gen11 subslice count differences handling.
Chris Wilson:
* args->size handling fixes.
* Update context image from GGTT.
* Postpone context image update to pinning.
* Use i915_gem_active_raw instead of last_request_on_engine.
v14:
* Add activity tracker on intel_context to fix the lifetime issues
and simplify the code. (Chris Wilson)
v15:
* Fix context pin leak if no space in ring by simplifying the
context pinning sequence.
v16:
* Rebase for context get/set param locking changes.
* Just -ENODEV on !Gen11. (Joonas)
v17:
* Fix one Gen11 subslice enablement rule.
* Handle error from i915_sw_fence_await_sw_fence_gfp. (Chris Wilson)
v18:
* Update commit message. (Joonas)
* Restrict uAPI to VME use case. (Joonas)
v19:
* Rebase.
v20:
* Rebase for ce->active_tracker.
v21:
* Rebase for IS_GEN changes.
v22:
* Reserve uAPI for flags straight away. (Chris Wilson)
v23:
* Rebase for RUNTIME_INFO.
v24:
* Added some headline docs for the uapi usage. (Joonas/Chris)
v25:
* Renamed class/instance to engine_class/engine_instance to avoid clash
with C++ keyword. (Tony Ye)
v26:
* Rebased for runtime pm api changes.
v27:
* Rebased for intel_context_init.
* Wrap commit msg to 75.
v28:
(Chris Wilson)
* Use i915_gem_ggtt.
* Use i915_request_await_dma_fence to show a better example.
v29:
* i915_timeline_set_barrier can now fail. (Chris Wilson)
v30:
* Capture some acks.
v31:
* Drop the WARN_ON from use controllable paths. (Chris Wilson)
* Use overflows_type for all checks.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100899
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107634
Issue: https://github.com/intel/media-driver/issues/267
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Zhipeng Gong <zhipeng.gong@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tony Ye <tony.ye@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: Timo Aaltonen <timo.aaltonen@canonical.com>
Acked-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Stéphane Marchesin <marcheu@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190205095032.22673-4-tvrtko.ursulin@linux.intel.com
2019-02-05 17:50:31 +08:00
|
|
|
|
2019-03-08 21:25:22 +08:00
|
|
|
/*
|
|
|
|
* If the context is not idle, we have to submit an ordered request to
|
|
|
|
* modify its context image via the kernel context (writing to our own
|
|
|
|
* image, or into the registers directory, does not stick). Pristine
|
|
|
|
* and idle contexts will be configured on pinning.
|
|
|
|
*/
|
|
|
|
if (!intel_context_is_pinned(ce))
|
|
|
|
return 0;
|
drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only)
We want to allow userspace to reconfigure the subslice configuration on a
per context basis.
This is required for the functional requirement of shutting down non-VME
enabled sub-slices on Gen11 parts.
To do so, we expose a context parameter to allow adjustment of the RPCS
register stored within the context image (and currently not accessible via
LRI).
If the context is adjusted before first use or whilst idle, the adjustment
is for "free"; otherwise if the context is active we queue a request to do
so (using the kernel context), following all other activity by that
context, which is also marked as barrier for all following submission
against the same context.
Since the overhead of device re-configuration during context switching can
be significant, especially in multi-context workloads, we limit this new
uAPI to only support the Gen11 VME use case. In this use case either the
device is fully enabled, and exactly one slice and half of the subslices
are enabled.
Example usage:
struct drm_i915_gem_context_param_sseu sseu = { };
struct drm_i915_gem_context_param arg = {
.param = I915_CONTEXT_PARAM_SSEU,
.ctx_id = gem_context_create(fd),
.size = sizeof(sseu),
.value = to_user_pointer(&sseu)
};
/* Query device defaults. */
gem_context_get_param(fd, &arg);
/* Set VME configuration on a 1x6x8 part. */
sseu.slice_mask = 0x1;
sseu.subslice_mask = 0xe0;
gem_context_set_param(fd, &arg);
v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu()
(Lionel)
v3: Add ability to program this per engine (Chris)
v4: Move most get_sseu() into i915_gem_context.c (Lionel)
v5: Validate sseu configuration against the device's capabilities (Lionel)
v6: Change context powergating settings through MI_SDM on kernel context
(Chris)
v7: Synchronize the requests following a powergating setting change using
a global dependency (Chris)
Iterate timelines through dev_priv.gt.active_rings (Tvrtko)
Disable RPCS configuration setting for non capable users
(Lionel/Tvrtko)
v8: s/union intel_sseu/struct intel_sseu/ (Lionel)
s/dev_priv/i915/ (Tvrtko)
Change uapi class/instance fields to u16 (Tvrtko)
Bump mask fields to 64bits (Lionel)
Don't return EPERM when dynamic sseu is disabled (Tvrtko)
v9: Import context image into kernel context's ppgtt only when
reconfiguring powergated slice/subslices (Chris)
Use aliasing ppgtt when needed (Michel)
Tvrtko Ursulin:
v10:
* Update for upstream changes.
* Request submit needs a RPM reference.
* Reject on !FULL_PPGTT for simplicity.
* Pull out get/set param to helpers for readability and less indent.
* Use i915_request_await_dma_fence in add_global_barrier to skip waits
on the same timeline and avoid GEM_BUG_ON.
* No need to explicitly assign a NULL pointer to engine in legacy mode.
* No need to move gen8_make_rpcs up.
* Factored out global barrier as prep patch.
* Allow to only CAP_SYS_ADMIN if !Gen11.
v11:
* Remove engine vfunc in favour of local helper. (Chris Wilson)
* Stop retiring requests before updates since it is not needed
(Chris Wilson)
* Implement direct CPU update path for idle contexts. (Chris Wilson)
* Left side dependency needs only be on the same context timeline.
(Chris Wilson)
* It is sufficient to order the timeline. (Chris Wilson)
* Reject !RCS configuration attempts with -ENODEV for now.
v12:
* Rebase for make_rpcs.
v13:
* Centralize SSEU normalization to make_rpcs.
* Type width checking (uAPI <-> implementation).
* Gen11 restrictions uAPI checks.
* Gen11 subslice count differences handling.
Chris Wilson:
* args->size handling fixes.
* Update context image from GGTT.
* Postpone context image update to pinning.
* Use i915_gem_active_raw instead of last_request_on_engine.
v14:
* Add activity tracker on intel_context to fix the lifetime issues
and simplify the code. (Chris Wilson)
v15:
* Fix context pin leak if no space in ring by simplifying the
context pinning sequence.
v16:
* Rebase for context get/set param locking changes.
* Just -ENODEV on !Gen11. (Joonas)
v17:
* Fix one Gen11 subslice enablement rule.
* Handle error from i915_sw_fence_await_sw_fence_gfp. (Chris Wilson)
v18:
* Update commit message. (Joonas)
* Restrict uAPI to VME use case. (Joonas)
v19:
* Rebase.
v20:
* Rebase for ce->active_tracker.
v21:
* Rebase for IS_GEN changes.
v22:
* Reserve uAPI for flags straight away. (Chris Wilson)
v23:
* Rebase for RUNTIME_INFO.
v24:
* Added some headline docs for the uapi usage. (Joonas/Chris)
v25:
* Renamed class/instance to engine_class/engine_instance to avoid clash
with C++ keyword. (Tony Ye)
v26:
* Rebased for runtime pm api changes.
v27:
* Rebased for intel_context_init.
* Wrap commit msg to 75.
v28:
(Chris Wilson)
* Use i915_gem_ggtt.
* Use i915_request_await_dma_fence to show a better example.
v29:
* i915_timeline_set_barrier can now fail. (Chris Wilson)
v30:
* Capture some acks.
v31:
* Drop the WARN_ON from use controllable paths. (Chris Wilson)
* Use overflows_type for all checks.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100899
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107634
Issue: https://github.com/intel/media-driver/issues/267
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Zhipeng Gong <zhipeng.gong@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tony Ye <tony.ye@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: Timo Aaltonen <timo.aaltonen@canonical.com>
Acked-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Stéphane Marchesin <marcheu@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190205095032.22673-4-tvrtko.ursulin@linux.intel.com
2019-02-05 17:50:31 +08:00
|
|
|
|
2019-11-25 18:58:56 +08:00
|
|
|
rq = intel_engine_create_kernel_request(ce->engine);
|
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 04:07:17 +08:00
|
|
|
if (IS_ERR(rq))
|
|
|
|
return PTR_ERR(rq);
|
drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only)
We want to allow userspace to reconfigure the subslice configuration on a
per context basis.
This is required for the functional requirement of shutting down non-VME
enabled sub-slices on Gen11 parts.
To do so, we expose a context parameter to allow adjustment of the RPCS
register stored within the context image (and currently not accessible via
LRI).
If the context is adjusted before first use or whilst idle, the adjustment
is for "free"; otherwise if the context is active we queue a request to do
so (using the kernel context), following all other activity by that
context, which is also marked as barrier for all following submission
against the same context.
Since the overhead of device re-configuration during context switching can
be significant, especially in multi-context workloads, we limit this new
uAPI to only support the Gen11 VME use case. In this use case either the
device is fully enabled, and exactly one slice and half of the subslices
are enabled.
Example usage:
struct drm_i915_gem_context_param_sseu sseu = { };
struct drm_i915_gem_context_param arg = {
.param = I915_CONTEXT_PARAM_SSEU,
.ctx_id = gem_context_create(fd),
.size = sizeof(sseu),
.value = to_user_pointer(&sseu)
};
/* Query device defaults. */
gem_context_get_param(fd, &arg);
/* Set VME configuration on a 1x6x8 part. */
sseu.slice_mask = 0x1;
sseu.subslice_mask = 0xe0;
gem_context_set_param(fd, &arg);
v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu()
(Lionel)
v3: Add ability to program this per engine (Chris)
v4: Move most get_sseu() into i915_gem_context.c (Lionel)
v5: Validate sseu configuration against the device's capabilities (Lionel)
v6: Change context powergating settings through MI_SDM on kernel context
(Chris)
v7: Synchronize the requests following a powergating setting change using
a global dependency (Chris)
Iterate timelines through dev_priv.gt.active_rings (Tvrtko)
Disable RPCS configuration setting for non capable users
(Lionel/Tvrtko)
v8: s/union intel_sseu/struct intel_sseu/ (Lionel)
s/dev_priv/i915/ (Tvrtko)
Change uapi class/instance fields to u16 (Tvrtko)
Bump mask fields to 64bits (Lionel)
Don't return EPERM when dynamic sseu is disabled (Tvrtko)
v9: Import context image into kernel context's ppgtt only when
reconfiguring powergated slice/subslices (Chris)
Use aliasing ppgtt when needed (Michel)
Tvrtko Ursulin:
v10:
* Update for upstream changes.
* Request submit needs a RPM reference.
* Reject on !FULL_PPGTT for simplicity.
* Pull out get/set param to helpers for readability and less indent.
* Use i915_request_await_dma_fence in add_global_barrier to skip waits
on the same timeline and avoid GEM_BUG_ON.
* No need to explicitly assign a NULL pointer to engine in legacy mode.
* No need to move gen8_make_rpcs up.
* Factored out global barrier as prep patch.
* Allow to only CAP_SYS_ADMIN if !Gen11.
v11:
* Remove engine vfunc in favour of local helper. (Chris Wilson)
* Stop retiring requests before updates since it is not needed
(Chris Wilson)
* Implement direct CPU update path for idle contexts. (Chris Wilson)
* Left side dependency needs only be on the same context timeline.
(Chris Wilson)
* It is sufficient to order the timeline. (Chris Wilson)
* Reject !RCS configuration attempts with -ENODEV for now.
v12:
* Rebase for make_rpcs.
v13:
* Centralize SSEU normalization to make_rpcs.
* Type width checking (uAPI <-> implementation).
* Gen11 restrictions uAPI checks.
* Gen11 subslice count differences handling.
Chris Wilson:
* args->size handling fixes.
* Update context image from GGTT.
* Postpone context image update to pinning.
* Use i915_gem_active_raw instead of last_request_on_engine.
v14:
* Add activity tracker on intel_context to fix the lifetime issues
and simplify the code. (Chris Wilson)
v15:
* Fix context pin leak if no space in ring by simplifying the
context pinning sequence.
v16:
* Rebase for context get/set param locking changes.
* Just -ENODEV on !Gen11. (Joonas)
v17:
* Fix one Gen11 subslice enablement rule.
* Handle error from i915_sw_fence_await_sw_fence_gfp. (Chris Wilson)
v18:
* Update commit message. (Joonas)
* Restrict uAPI to VME use case. (Joonas)
v19:
* Rebase.
v20:
* Rebase for ce->active_tracker.
v21:
* Rebase for IS_GEN changes.
v22:
* Reserve uAPI for flags straight away. (Chris Wilson)
v23:
* Rebase for RUNTIME_INFO.
v24:
* Added some headline docs for the uapi usage. (Joonas/Chris)
v25:
* Renamed class/instance to engine_class/engine_instance to avoid clash
with C++ keyword. (Tony Ye)
v26:
* Rebased for runtime pm api changes.
v27:
* Rebased for intel_context_init.
* Wrap commit msg to 75.
v28:
(Chris Wilson)
* Use i915_gem_ggtt.
* Use i915_request_await_dma_fence to show a better example.
v29:
* i915_timeline_set_barrier can now fail. (Chris Wilson)
v30:
* Capture some acks.
v31:
* Drop the WARN_ON from use controllable paths. (Chris Wilson)
* Use overflows_type for all checks.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100899
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107634
Issue: https://github.com/intel/media-driver/issues/267
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Zhipeng Gong <zhipeng.gong@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tony Ye <tony.ye@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: Timo Aaltonen <timo.aaltonen@canonical.com>
Acked-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Stéphane Marchesin <marcheu@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190205095032.22673-4-tvrtko.ursulin@linux.intel.com
2019-02-05 17:50:31 +08:00
|
|
|
|
2019-07-17 05:34:43 +08:00
|
|
|
/* Serialise with the remote context */
|
|
|
|
ret = intel_context_prepare_remote_request(ce, rq);
|
|
|
|
if (ret == 0)
|
|
|
|
ret = gen8_emit_rpcs_config(rq, ce, sseu);
|
drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only)
We want to allow userspace to reconfigure the subslice configuration on a
per context basis.
This is required for the functional requirement of shutting down non-VME
enabled sub-slices on Gen11 parts.
To do so, we expose a context parameter to allow adjustment of the RPCS
register stored within the context image (and currently not accessible via
LRI).
If the context is adjusted before first use or whilst idle, the adjustment
is for "free"; otherwise if the context is active we queue a request to do
so (using the kernel context), following all other activity by that
context, which is also marked as barrier for all following submission
against the same context.
Since the overhead of device re-configuration during context switching can
be significant, especially in multi-context workloads, we limit this new
uAPI to only support the Gen11 VME use case. In this use case either the
device is fully enabled, and exactly one slice and half of the subslices
are enabled.
Example usage:
struct drm_i915_gem_context_param_sseu sseu = { };
struct drm_i915_gem_context_param arg = {
.param = I915_CONTEXT_PARAM_SSEU,
.ctx_id = gem_context_create(fd),
.size = sizeof(sseu),
.value = to_user_pointer(&sseu)
};
/* Query device defaults. */
gem_context_get_param(fd, &arg);
/* Set VME configuration on a 1x6x8 part. */
sseu.slice_mask = 0x1;
sseu.subslice_mask = 0xe0;
gem_context_set_param(fd, &arg);
v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu()
(Lionel)
v3: Add ability to program this per engine (Chris)
v4: Move most get_sseu() into i915_gem_context.c (Lionel)
v5: Validate sseu configuration against the device's capabilities (Lionel)
v6: Change context powergating settings through MI_SDM on kernel context
(Chris)
v7: Synchronize the requests following a powergating setting change using
a global dependency (Chris)
Iterate timelines through dev_priv.gt.active_rings (Tvrtko)
Disable RPCS configuration setting for non capable users
(Lionel/Tvrtko)
v8: s/union intel_sseu/struct intel_sseu/ (Lionel)
s/dev_priv/i915/ (Tvrtko)
Change uapi class/instance fields to u16 (Tvrtko)
Bump mask fields to 64bits (Lionel)
Don't return EPERM when dynamic sseu is disabled (Tvrtko)
v9: Import context image into kernel context's ppgtt only when
reconfiguring powergated slice/subslices (Chris)
Use aliasing ppgtt when needed (Michel)
Tvrtko Ursulin:
v10:
* Update for upstream changes.
* Request submit needs a RPM reference.
* Reject on !FULL_PPGTT for simplicity.
* Pull out get/set param to helpers for readability and less indent.
* Use i915_request_await_dma_fence in add_global_barrier to skip waits
on the same timeline and avoid GEM_BUG_ON.
* No need to explicitly assign a NULL pointer to engine in legacy mode.
* No need to move gen8_make_rpcs up.
* Factored out global barrier as prep patch.
* Allow to only CAP_SYS_ADMIN if !Gen11.
v11:
* Remove engine vfunc in favour of local helper. (Chris Wilson)
* Stop retiring requests before updates since it is not needed
(Chris Wilson)
* Implement direct CPU update path for idle contexts. (Chris Wilson)
* Left side dependency needs only be on the same context timeline.
(Chris Wilson)
* It is sufficient to order the timeline. (Chris Wilson)
* Reject !RCS configuration attempts with -ENODEV for now.
v12:
* Rebase for make_rpcs.
v13:
* Centralize SSEU normalization to make_rpcs.
* Type width checking (uAPI <-> implementation).
* Gen11 restrictions uAPI checks.
* Gen11 subslice count differences handling.
Chris Wilson:
* args->size handling fixes.
* Update context image from GGTT.
* Postpone context image update to pinning.
* Use i915_gem_active_raw instead of last_request_on_engine.
v14:
* Add activity tracker on intel_context to fix the lifetime issues
and simplify the code. (Chris Wilson)
v15:
* Fix context pin leak if no space in ring by simplifying the
context pinning sequence.
v16:
* Rebase for context get/set param locking changes.
* Just -ENODEV on !Gen11. (Joonas)
v17:
* Fix one Gen11 subslice enablement rule.
* Handle error from i915_sw_fence_await_sw_fence_gfp. (Chris Wilson)
v18:
* Update commit message. (Joonas)
* Restrict uAPI to VME use case. (Joonas)
v19:
* Rebase.
v20:
* Rebase for ce->active_tracker.
v21:
* Rebase for IS_GEN changes.
v22:
* Reserve uAPI for flags straight away. (Chris Wilson)
v23:
* Rebase for RUNTIME_INFO.
v24:
* Added some headline docs for the uapi usage. (Joonas/Chris)
v25:
* Renamed class/instance to engine_class/engine_instance to avoid clash
with C++ keyword. (Tony Ye)
v26:
* Rebased for runtime pm api changes.
v27:
* Rebased for intel_context_init.
* Wrap commit msg to 75.
v28:
(Chris Wilson)
* Use i915_gem_ggtt.
* Use i915_request_await_dma_fence to show a better example.
v29:
* i915_timeline_set_barrier can now fail. (Chris Wilson)
v30:
* Capture some acks.
v31:
* Drop the WARN_ON from use controllable paths. (Chris Wilson)
* Use overflows_type for all checks.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100899
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107634
Issue: https://github.com/intel/media-driver/issues/267
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Zhipeng Gong <zhipeng.gong@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tony Ye <tony.ye@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: Timo Aaltonen <timo.aaltonen@canonical.com>
Acked-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Stéphane Marchesin <marcheu@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190205095032.22673-4-tvrtko.ursulin@linux.intel.com
2019-02-05 17:50:31 +08:00
|
|
|
|
|
|
|
i915_request_add(rq);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
2019-10-04 21:40:02 +08:00
|
|
|
intel_context_reconfigure_sseu(struct intel_context *ce, struct intel_sseu sseu)
|
drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only)
We want to allow userspace to reconfigure the subslice configuration on a
per context basis.
This is required for the functional requirement of shutting down non-VME
enabled sub-slices on Gen11 parts.
To do so, we expose a context parameter to allow adjustment of the RPCS
register stored within the context image (and currently not accessible via
LRI).
If the context is adjusted before first use or whilst idle, the adjustment
is for "free"; otherwise if the context is active we queue a request to do
so (using the kernel context), following all other activity by that
context, which is also marked as barrier for all following submission
against the same context.
Since the overhead of device re-configuration during context switching can
be significant, especially in multi-context workloads, we limit this new
uAPI to only support the Gen11 VME use case. In this use case either the
device is fully enabled, and exactly one slice and half of the subslices
are enabled.
Example usage:
struct drm_i915_gem_context_param_sseu sseu = { };
struct drm_i915_gem_context_param arg = {
.param = I915_CONTEXT_PARAM_SSEU,
.ctx_id = gem_context_create(fd),
.size = sizeof(sseu),
.value = to_user_pointer(&sseu)
};
/* Query device defaults. */
gem_context_get_param(fd, &arg);
/* Set VME configuration on a 1x6x8 part. */
sseu.slice_mask = 0x1;
sseu.subslice_mask = 0xe0;
gem_context_set_param(fd, &arg);
v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu()
(Lionel)
v3: Add ability to program this per engine (Chris)
v4: Move most get_sseu() into i915_gem_context.c (Lionel)
v5: Validate sseu configuration against the device's capabilities (Lionel)
v6: Change context powergating settings through MI_SDM on kernel context
(Chris)
v7: Synchronize the requests following a powergating setting change using
a global dependency (Chris)
Iterate timelines through dev_priv.gt.active_rings (Tvrtko)
Disable RPCS configuration setting for non capable users
(Lionel/Tvrtko)
v8: s/union intel_sseu/struct intel_sseu/ (Lionel)
s/dev_priv/i915/ (Tvrtko)
Change uapi class/instance fields to u16 (Tvrtko)
Bump mask fields to 64bits (Lionel)
Don't return EPERM when dynamic sseu is disabled (Tvrtko)
v9: Import context image into kernel context's ppgtt only when
reconfiguring powergated slice/subslices (Chris)
Use aliasing ppgtt when needed (Michel)
Tvrtko Ursulin:
v10:
* Update for upstream changes.
* Request submit needs a RPM reference.
* Reject on !FULL_PPGTT for simplicity.
* Pull out get/set param to helpers for readability and less indent.
* Use i915_request_await_dma_fence in add_global_barrier to skip waits
on the same timeline and avoid GEM_BUG_ON.
* No need to explicitly assign a NULL pointer to engine in legacy mode.
* No need to move gen8_make_rpcs up.
* Factored out global barrier as prep patch.
* Allow to only CAP_SYS_ADMIN if !Gen11.
v11:
* Remove engine vfunc in favour of local helper. (Chris Wilson)
* Stop retiring requests before updates since it is not needed
(Chris Wilson)
* Implement direct CPU update path for idle contexts. (Chris Wilson)
* Left side dependency needs only be on the same context timeline.
(Chris Wilson)
* It is sufficient to order the timeline. (Chris Wilson)
* Reject !RCS configuration attempts with -ENODEV for now.
v12:
* Rebase for make_rpcs.
v13:
* Centralize SSEU normalization to make_rpcs.
* Type width checking (uAPI <-> implementation).
* Gen11 restrictions uAPI checks.
* Gen11 subslice count differences handling.
Chris Wilson:
* args->size handling fixes.
* Update context image from GGTT.
* Postpone context image update to pinning.
* Use i915_gem_active_raw instead of last_request_on_engine.
v14:
* Add activity tracker on intel_context to fix the lifetime issues
and simplify the code. (Chris Wilson)
v15:
* Fix context pin leak if no space in ring by simplifying the
context pinning sequence.
v16:
* Rebase for context get/set param locking changes.
* Just -ENODEV on !Gen11. (Joonas)
v17:
* Fix one Gen11 subslice enablement rule.
* Handle error from i915_sw_fence_await_sw_fence_gfp. (Chris Wilson)
v18:
* Update commit message. (Joonas)
* Restrict uAPI to VME use case. (Joonas)
v19:
* Rebase.
v20:
* Rebase for ce->active_tracker.
v21:
* Rebase for IS_GEN changes.
v22:
* Reserve uAPI for flags straight away. (Chris Wilson)
v23:
* Rebase for RUNTIME_INFO.
v24:
* Added some headline docs for the uapi usage. (Joonas/Chris)
v25:
* Renamed class/instance to engine_class/engine_instance to avoid clash
with C++ keyword. (Tony Ye)
v26:
* Rebased for runtime pm api changes.
v27:
* Rebased for intel_context_init.
* Wrap commit msg to 75.
v28:
(Chris Wilson)
* Use i915_gem_ggtt.
* Use i915_request_await_dma_fence to show a better example.
v29:
* i915_timeline_set_barrier can now fail. (Chris Wilson)
v30:
* Capture some acks.
v31:
* Drop the WARN_ON from use controllable paths. (Chris Wilson)
* Use overflows_type for all checks.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100899
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107634
Issue: https://github.com/intel/media-driver/issues/267
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Zhipeng Gong <zhipeng.gong@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tony Ye <tony.ye@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: Timo Aaltonen <timo.aaltonen@canonical.com>
Acked-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Stéphane Marchesin <marcheu@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190205095032.22673-4-tvrtko.ursulin@linux.intel.com
2019-02-05 17:50:31 +08:00
|
|
|
{
|
2019-04-27 00:33:32 +08:00
|
|
|
int ret;
|
drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only)
We want to allow userspace to reconfigure the subslice configuration on a
per context basis.
This is required for the functional requirement of shutting down non-VME
enabled sub-slices on Gen11 parts.
To do so, we expose a context parameter to allow adjustment of the RPCS
register stored within the context image (and currently not accessible via
LRI).
If the context is adjusted before first use or whilst idle, the adjustment
is for "free"; otherwise if the context is active we queue a request to do
so (using the kernel context), following all other activity by that
context, which is also marked as barrier for all following submission
against the same context.
Since the overhead of device re-configuration during context switching can
be significant, especially in multi-context workloads, we limit this new
uAPI to only support the Gen11 VME use case. In this use case either the
device is fully enabled, and exactly one slice and half of the subslices
are enabled.
Example usage:
struct drm_i915_gem_context_param_sseu sseu = { };
struct drm_i915_gem_context_param arg = {
.param = I915_CONTEXT_PARAM_SSEU,
.ctx_id = gem_context_create(fd),
.size = sizeof(sseu),
.value = to_user_pointer(&sseu)
};
/* Query device defaults. */
gem_context_get_param(fd, &arg);
/* Set VME configuration on a 1x6x8 part. */
sseu.slice_mask = 0x1;
sseu.subslice_mask = 0xe0;
gem_context_set_param(fd, &arg);
v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu()
(Lionel)
v3: Add ability to program this per engine (Chris)
v4: Move most get_sseu() into i915_gem_context.c (Lionel)
v5: Validate sseu configuration against the device's capabilities (Lionel)
v6: Change context powergating settings through MI_SDM on kernel context
(Chris)
v7: Synchronize the requests following a powergating setting change using
a global dependency (Chris)
Iterate timelines through dev_priv.gt.active_rings (Tvrtko)
Disable RPCS configuration setting for non capable users
(Lionel/Tvrtko)
v8: s/union intel_sseu/struct intel_sseu/ (Lionel)
s/dev_priv/i915/ (Tvrtko)
Change uapi class/instance fields to u16 (Tvrtko)
Bump mask fields to 64bits (Lionel)
Don't return EPERM when dynamic sseu is disabled (Tvrtko)
v9: Import context image into kernel context's ppgtt only when
reconfiguring powergated slice/subslices (Chris)
Use aliasing ppgtt when needed (Michel)
Tvrtko Ursulin:
v10:
* Update for upstream changes.
* Request submit needs a RPM reference.
* Reject on !FULL_PPGTT for simplicity.
* Pull out get/set param to helpers for readability and less indent.
* Use i915_request_await_dma_fence in add_global_barrier to skip waits
on the same timeline and avoid GEM_BUG_ON.
* No need to explicitly assign a NULL pointer to engine in legacy mode.
* No need to move gen8_make_rpcs up.
* Factored out global barrier as prep patch.
* Allow to only CAP_SYS_ADMIN if !Gen11.
v11:
* Remove engine vfunc in favour of local helper. (Chris Wilson)
* Stop retiring requests before updates since it is not needed
(Chris Wilson)
* Implement direct CPU update path for idle contexts. (Chris Wilson)
* Left side dependency needs only be on the same context timeline.
(Chris Wilson)
* It is sufficient to order the timeline. (Chris Wilson)
* Reject !RCS configuration attempts with -ENODEV for now.
v12:
* Rebase for make_rpcs.
v13:
* Centralize SSEU normalization to make_rpcs.
* Type width checking (uAPI <-> implementation).
* Gen11 restrictions uAPI checks.
* Gen11 subslice count differences handling.
Chris Wilson:
* args->size handling fixes.
* Update context image from GGTT.
* Postpone context image update to pinning.
* Use i915_gem_active_raw instead of last_request_on_engine.
v14:
* Add activity tracker on intel_context to fix the lifetime issues
and simplify the code. (Chris Wilson)
v15:
* Fix context pin leak if no space in ring by simplifying the
context pinning sequence.
v16:
* Rebase for context get/set param locking changes.
* Just -ENODEV on !Gen11. (Joonas)
v17:
* Fix one Gen11 subslice enablement rule.
* Handle error from i915_sw_fence_await_sw_fence_gfp. (Chris Wilson)
v18:
* Update commit message. (Joonas)
* Restrict uAPI to VME use case. (Joonas)
v19:
* Rebase.
v20:
* Rebase for ce->active_tracker.
v21:
* Rebase for IS_GEN changes.
v22:
* Reserve uAPI for flags straight away. (Chris Wilson)
v23:
* Rebase for RUNTIME_INFO.
v24:
* Added some headline docs for the uapi usage. (Joonas/Chris)
v25:
* Renamed class/instance to engine_class/engine_instance to avoid clash
with C++ keyword. (Tony Ye)
v26:
* Rebased for runtime pm api changes.
v27:
* Rebased for intel_context_init.
* Wrap commit msg to 75.
v28:
(Chris Wilson)
* Use i915_gem_ggtt.
* Use i915_request_await_dma_fence to show a better example.
v29:
* i915_timeline_set_barrier can now fail. (Chris Wilson)
v30:
* Capture some acks.
v31:
* Drop the WARN_ON from use controllable paths. (Chris Wilson)
* Use overflows_type for all checks.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100899
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107634
Issue: https://github.com/intel/media-driver/issues/267
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Zhipeng Gong <zhipeng.gong@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tony Ye <tony.ye@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: Timo Aaltonen <timo.aaltonen@canonical.com>
Acked-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Stéphane Marchesin <marcheu@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190205095032.22673-4-tvrtko.ursulin@linux.intel.com
2019-02-05 17:50:31 +08:00
|
|
|
|
2019-07-31 00:34:41 +08:00
|
|
|
GEM_BUG_ON(INTEL_GEN(ce->engine->i915) < 8);
|
drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only)
We want to allow userspace to reconfigure the subslice configuration on a
per context basis.
This is required for the functional requirement of shutting down non-VME
enabled sub-slices on Gen11 parts.
To do so, we expose a context parameter to allow adjustment of the RPCS
register stored within the context image (and currently not accessible via
LRI).
If the context is adjusted before first use or whilst idle, the adjustment
is for "free"; otherwise if the context is active we queue a request to do
so (using the kernel context), following all other activity by that
context, which is also marked as barrier for all following submission
against the same context.
Since the overhead of device re-configuration during context switching can
be significant, especially in multi-context workloads, we limit this new
uAPI to only support the Gen11 VME use case. In this use case either the
device is fully enabled, and exactly one slice and half of the subslices
are enabled.
Example usage:
struct drm_i915_gem_context_param_sseu sseu = { };
struct drm_i915_gem_context_param arg = {
.param = I915_CONTEXT_PARAM_SSEU,
.ctx_id = gem_context_create(fd),
.size = sizeof(sseu),
.value = to_user_pointer(&sseu)
};
/* Query device defaults. */
gem_context_get_param(fd, &arg);
/* Set VME configuration on a 1x6x8 part. */
sseu.slice_mask = 0x1;
sseu.subslice_mask = 0xe0;
gem_context_set_param(fd, &arg);
v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu()
(Lionel)
v3: Add ability to program this per engine (Chris)
v4: Move most get_sseu() into i915_gem_context.c (Lionel)
v5: Validate sseu configuration against the device's capabilities (Lionel)
v6: Change context powergating settings through MI_SDM on kernel context
(Chris)
v7: Synchronize the requests following a powergating setting change using
a global dependency (Chris)
Iterate timelines through dev_priv.gt.active_rings (Tvrtko)
Disable RPCS configuration setting for non capable users
(Lionel/Tvrtko)
v8: s/union intel_sseu/struct intel_sseu/ (Lionel)
s/dev_priv/i915/ (Tvrtko)
Change uapi class/instance fields to u16 (Tvrtko)
Bump mask fields to 64bits (Lionel)
Don't return EPERM when dynamic sseu is disabled (Tvrtko)
v9: Import context image into kernel context's ppgtt only when
reconfiguring powergated slice/subslices (Chris)
Use aliasing ppgtt when needed (Michel)
Tvrtko Ursulin:
v10:
* Update for upstream changes.
* Request submit needs a RPM reference.
* Reject on !FULL_PPGTT for simplicity.
* Pull out get/set param to helpers for readability and less indent.
* Use i915_request_await_dma_fence in add_global_barrier to skip waits
on the same timeline and avoid GEM_BUG_ON.
* No need to explicitly assign a NULL pointer to engine in legacy mode.
* No need to move gen8_make_rpcs up.
* Factored out global barrier as prep patch.
* Allow to only CAP_SYS_ADMIN if !Gen11.
v11:
* Remove engine vfunc in favour of local helper. (Chris Wilson)
* Stop retiring requests before updates since it is not needed
(Chris Wilson)
* Implement direct CPU update path for idle contexts. (Chris Wilson)
* Left side dependency needs only be on the same context timeline.
(Chris Wilson)
* It is sufficient to order the timeline. (Chris Wilson)
* Reject !RCS configuration attempts with -ENODEV for now.
v12:
* Rebase for make_rpcs.
v13:
* Centralize SSEU normalization to make_rpcs.
* Type width checking (uAPI <-> implementation).
* Gen11 restrictions uAPI checks.
* Gen11 subslice count differences handling.
Chris Wilson:
* args->size handling fixes.
* Update context image from GGTT.
* Postpone context image update to pinning.
* Use i915_gem_active_raw instead of last_request_on_engine.
v14:
* Add activity tracker on intel_context to fix the lifetime issues
and simplify the code. (Chris Wilson)
v15:
* Fix context pin leak if no space in ring by simplifying the
context pinning sequence.
v16:
* Rebase for context get/set param locking changes.
* Just -ENODEV on !Gen11. (Joonas)
v17:
* Fix one Gen11 subslice enablement rule.
* Handle error from i915_sw_fence_await_sw_fence_gfp. (Chris Wilson)
v18:
* Update commit message. (Joonas)
* Restrict uAPI to VME use case. (Joonas)
v19:
* Rebase.
v20:
* Rebase for ce->active_tracker.
v21:
* Rebase for IS_GEN changes.
v22:
* Reserve uAPI for flags straight away. (Chris Wilson)
v23:
* Rebase for RUNTIME_INFO.
v24:
* Added some headline docs for the uapi usage. (Joonas/Chris)
v25:
* Renamed class/instance to engine_class/engine_instance to avoid clash
with C++ keyword. (Tony Ye)
v26:
* Rebased for runtime pm api changes.
v27:
* Rebased for intel_context_init.
* Wrap commit msg to 75.
v28:
(Chris Wilson)
* Use i915_gem_ggtt.
* Use i915_request_await_dma_fence to show a better example.
v29:
* i915_timeline_set_barrier can now fail. (Chris Wilson)
v30:
* Capture some acks.
v31:
* Drop the WARN_ON from use controllable paths. (Chris Wilson)
* Use overflows_type for all checks.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100899
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107634
Issue: https://github.com/intel/media-driver/issues/267
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Zhipeng Gong <zhipeng.gong@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tony Ye <tony.ye@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: Timo Aaltonen <timo.aaltonen@canonical.com>
Acked-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Stéphane Marchesin <marcheu@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190205095032.22673-4-tvrtko.ursulin@linux.intel.com
2019-02-05 17:50:31 +08:00
|
|
|
|
2019-04-27 00:33:32 +08:00
|
|
|
ret = intel_context_lock_pinned(ce);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
2019-03-08 21:25:19 +08:00
|
|
|
|
drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only)
We want to allow userspace to reconfigure the subslice configuration on a
per context basis.
This is required for the functional requirement of shutting down non-VME
enabled sub-slices on Gen11 parts.
To do so, we expose a context parameter to allow adjustment of the RPCS
register stored within the context image (and currently not accessible via
LRI).
If the context is adjusted before first use or whilst idle, the adjustment
is for "free"; otherwise if the context is active we queue a request to do
so (using the kernel context), following all other activity by that
context, which is also marked as barrier for all following submission
against the same context.
Since the overhead of device re-configuration during context switching can
be significant, especially in multi-context workloads, we limit this new
uAPI to only support the Gen11 VME use case. In this use case either the
device is fully enabled, and exactly one slice and half of the subslices
are enabled.
Example usage:
struct drm_i915_gem_context_param_sseu sseu = { };
struct drm_i915_gem_context_param arg = {
.param = I915_CONTEXT_PARAM_SSEU,
.ctx_id = gem_context_create(fd),
.size = sizeof(sseu),
.value = to_user_pointer(&sseu)
};
/* Query device defaults. */
gem_context_get_param(fd, &arg);
/* Set VME configuration on a 1x6x8 part. */
sseu.slice_mask = 0x1;
sseu.subslice_mask = 0xe0;
gem_context_set_param(fd, &arg);
v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu()
(Lionel)
v3: Add ability to program this per engine (Chris)
v4: Move most get_sseu() into i915_gem_context.c (Lionel)
v5: Validate sseu configuration against the device's capabilities (Lionel)
v6: Change context powergating settings through MI_SDM on kernel context
(Chris)
v7: Synchronize the requests following a powergating setting change using
a global dependency (Chris)
Iterate timelines through dev_priv.gt.active_rings (Tvrtko)
Disable RPCS configuration setting for non capable users
(Lionel/Tvrtko)
v8: s/union intel_sseu/struct intel_sseu/ (Lionel)
s/dev_priv/i915/ (Tvrtko)
Change uapi class/instance fields to u16 (Tvrtko)
Bump mask fields to 64bits (Lionel)
Don't return EPERM when dynamic sseu is disabled (Tvrtko)
v9: Import context image into kernel context's ppgtt only when
reconfiguring powergated slice/subslices (Chris)
Use aliasing ppgtt when needed (Michel)
Tvrtko Ursulin:
v10:
* Update for upstream changes.
* Request submit needs a RPM reference.
* Reject on !FULL_PPGTT for simplicity.
* Pull out get/set param to helpers for readability and less indent.
* Use i915_request_await_dma_fence in add_global_barrier to skip waits
on the same timeline and avoid GEM_BUG_ON.
* No need to explicitly assign a NULL pointer to engine in legacy mode.
* No need to move gen8_make_rpcs up.
* Factored out global barrier as prep patch.
* Allow to only CAP_SYS_ADMIN if !Gen11.
v11:
* Remove engine vfunc in favour of local helper. (Chris Wilson)
* Stop retiring requests before updates since it is not needed
(Chris Wilson)
* Implement direct CPU update path for idle contexts. (Chris Wilson)
* Left side dependency needs only be on the same context timeline.
(Chris Wilson)
* It is sufficient to order the timeline. (Chris Wilson)
* Reject !RCS configuration attempts with -ENODEV for now.
v12:
* Rebase for make_rpcs.
v13:
* Centralize SSEU normalization to make_rpcs.
* Type width checking (uAPI <-> implementation).
* Gen11 restrictions uAPI checks.
* Gen11 subslice count differences handling.
Chris Wilson:
* args->size handling fixes.
* Update context image from GGTT.
* Postpone context image update to pinning.
* Use i915_gem_active_raw instead of last_request_on_engine.
v14:
* Add activity tracker on intel_context to fix the lifetime issues
and simplify the code. (Chris Wilson)
v15:
* Fix context pin leak if no space in ring by simplifying the
context pinning sequence.
v16:
* Rebase for context get/set param locking changes.
* Just -ENODEV on !Gen11. (Joonas)
v17:
* Fix one Gen11 subslice enablement rule.
* Handle error from i915_sw_fence_await_sw_fence_gfp. (Chris Wilson)
v18:
* Update commit message. (Joonas)
* Restrict uAPI to VME use case. (Joonas)
v19:
* Rebase.
v20:
* Rebase for ce->active_tracker.
v21:
* Rebase for IS_GEN changes.
v22:
* Reserve uAPI for flags straight away. (Chris Wilson)
v23:
* Rebase for RUNTIME_INFO.
v24:
* Added some headline docs for the uapi usage. (Joonas/Chris)
v25:
* Renamed class/instance to engine_class/engine_instance to avoid clash
with C++ keyword. (Tony Ye)
v26:
* Rebased for runtime pm api changes.
v27:
* Rebased for intel_context_init.
* Wrap commit msg to 75.
v28:
(Chris Wilson)
* Use i915_gem_ggtt.
* Use i915_request_await_dma_fence to show a better example.
v29:
* i915_timeline_set_barrier can now fail. (Chris Wilson)
v30:
* Capture some acks.
v31:
* Drop the WARN_ON from use controllable paths. (Chris Wilson)
* Use overflows_type for all checks.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100899
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107634
Issue: https://github.com/intel/media-driver/issues/267
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Zhipeng Gong <zhipeng.gong@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tony Ye <tony.ye@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: Timo Aaltonen <timo.aaltonen@canonical.com>
Acked-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Stéphane Marchesin <marcheu@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190205095032.22673-4-tvrtko.ursulin@linux.intel.com
2019-02-05 17:50:31 +08:00
|
|
|
/* Nothing to do if unmodified. */
|
|
|
|
if (!memcmp(&ce->sseu, &sseu, sizeof(sseu)))
|
2019-03-08 21:25:22 +08:00
|
|
|
goto unlock;
|
drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only)
We want to allow userspace to reconfigure the subslice configuration on a
per context basis.
This is required for the functional requirement of shutting down non-VME
enabled sub-slices on Gen11 parts.
To do so, we expose a context parameter to allow adjustment of the RPCS
register stored within the context image (and currently not accessible via
LRI).
If the context is adjusted before first use or whilst idle, the adjustment
is for "free"; otherwise if the context is active we queue a request to do
so (using the kernel context), following all other activity by that
context, which is also marked as barrier for all following submission
against the same context.
Since the overhead of device re-configuration during context switching can
be significant, especially in multi-context workloads, we limit this new
uAPI to only support the Gen11 VME use case. In this use case either the
device is fully enabled, and exactly one slice and half of the subslices
are enabled.
Example usage:
struct drm_i915_gem_context_param_sseu sseu = { };
struct drm_i915_gem_context_param arg = {
.param = I915_CONTEXT_PARAM_SSEU,
.ctx_id = gem_context_create(fd),
.size = sizeof(sseu),
.value = to_user_pointer(&sseu)
};
/* Query device defaults. */
gem_context_get_param(fd, &arg);
/* Set VME configuration on a 1x6x8 part. */
sseu.slice_mask = 0x1;
sseu.subslice_mask = 0xe0;
gem_context_set_param(fd, &arg);
v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu()
(Lionel)
v3: Add ability to program this per engine (Chris)
v4: Move most get_sseu() into i915_gem_context.c (Lionel)
v5: Validate sseu configuration against the device's capabilities (Lionel)
v6: Change context powergating settings through MI_SDM on kernel context
(Chris)
v7: Synchronize the requests following a powergating setting change using
a global dependency (Chris)
Iterate timelines through dev_priv.gt.active_rings (Tvrtko)
Disable RPCS configuration setting for non capable users
(Lionel/Tvrtko)
v8: s/union intel_sseu/struct intel_sseu/ (Lionel)
s/dev_priv/i915/ (Tvrtko)
Change uapi class/instance fields to u16 (Tvrtko)
Bump mask fields to 64bits (Lionel)
Don't return EPERM when dynamic sseu is disabled (Tvrtko)
v9: Import context image into kernel context's ppgtt only when
reconfiguring powergated slice/subslices (Chris)
Use aliasing ppgtt when needed (Michel)
Tvrtko Ursulin:
v10:
* Update for upstream changes.
* Request submit needs a RPM reference.
* Reject on !FULL_PPGTT for simplicity.
* Pull out get/set param to helpers for readability and less indent.
* Use i915_request_await_dma_fence in add_global_barrier to skip waits
on the same timeline and avoid GEM_BUG_ON.
* No need to explicitly assign a NULL pointer to engine in legacy mode.
* No need to move gen8_make_rpcs up.
* Factored out global barrier as prep patch.
* Allow to only CAP_SYS_ADMIN if !Gen11.
v11:
* Remove engine vfunc in favour of local helper. (Chris Wilson)
* Stop retiring requests before updates since it is not needed
(Chris Wilson)
* Implement direct CPU update path for idle contexts. (Chris Wilson)
* Left side dependency needs only be on the same context timeline.
(Chris Wilson)
* It is sufficient to order the timeline. (Chris Wilson)
* Reject !RCS configuration attempts with -ENODEV for now.
v12:
* Rebase for make_rpcs.
v13:
* Centralize SSEU normalization to make_rpcs.
* Type width checking (uAPI <-> implementation).
* Gen11 restrictions uAPI checks.
* Gen11 subslice count differences handling.
Chris Wilson:
* args->size handling fixes.
* Update context image from GGTT.
* Postpone context image update to pinning.
* Use i915_gem_active_raw instead of last_request_on_engine.
v14:
* Add activity tracker on intel_context to fix the lifetime issues
and simplify the code. (Chris Wilson)
v15:
* Fix context pin leak if no space in ring by simplifying the
context pinning sequence.
v16:
* Rebase for context get/set param locking changes.
* Just -ENODEV on !Gen11. (Joonas)
v17:
* Fix one Gen11 subslice enablement rule.
* Handle error from i915_sw_fence_await_sw_fence_gfp. (Chris Wilson)
v18:
* Update commit message. (Joonas)
* Restrict uAPI to VME use case. (Joonas)
v19:
* Rebase.
v20:
* Rebase for ce->active_tracker.
v21:
* Rebase for IS_GEN changes.
v22:
* Reserve uAPI for flags straight away. (Chris Wilson)
v23:
* Rebase for RUNTIME_INFO.
v24:
* Added some headline docs for the uapi usage. (Joonas/Chris)
v25:
* Renamed class/instance to engine_class/engine_instance to avoid clash
with C++ keyword. (Tony Ye)
v26:
* Rebased for runtime pm api changes.
v27:
* Rebased for intel_context_init.
* Wrap commit msg to 75.
v28:
(Chris Wilson)
* Use i915_gem_ggtt.
* Use i915_request_await_dma_fence to show a better example.
v29:
* i915_timeline_set_barrier can now fail. (Chris Wilson)
v30:
* Capture some acks.
v31:
* Drop the WARN_ON from use controllable paths. (Chris Wilson)
* Use overflows_type for all checks.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100899
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107634
Issue: https://github.com/intel/media-driver/issues/267
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Zhipeng Gong <zhipeng.gong@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tony Ye <tony.ye@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: Timo Aaltonen <timo.aaltonen@canonical.com>
Acked-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Stéphane Marchesin <marcheu@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190205095032.22673-4-tvrtko.ursulin@linux.intel.com
2019-02-05 17:50:31 +08:00
|
|
|
|
2019-03-08 21:25:22 +08:00
|
|
|
ret = gen8_modify_rpcs(ce, sseu);
|
drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only)
We want to allow userspace to reconfigure the subslice configuration on a
per context basis.
This is required for the functional requirement of shutting down non-VME
enabled sub-slices on Gen11 parts.
To do so, we expose a context parameter to allow adjustment of the RPCS
register stored within the context image (and currently not accessible via
LRI).
If the context is adjusted before first use or whilst idle, the adjustment
is for "free"; otherwise if the context is active we queue a request to do
so (using the kernel context), following all other activity by that
context, which is also marked as barrier for all following submission
against the same context.
Since the overhead of device re-configuration during context switching can
be significant, especially in multi-context workloads, we limit this new
uAPI to only support the Gen11 VME use case. In this use case either the
device is fully enabled, and exactly one slice and half of the subslices
are enabled.
Example usage:
struct drm_i915_gem_context_param_sseu sseu = { };
struct drm_i915_gem_context_param arg = {
.param = I915_CONTEXT_PARAM_SSEU,
.ctx_id = gem_context_create(fd),
.size = sizeof(sseu),
.value = to_user_pointer(&sseu)
};
/* Query device defaults. */
gem_context_get_param(fd, &arg);
/* Set VME configuration on a 1x6x8 part. */
sseu.slice_mask = 0x1;
sseu.subslice_mask = 0xe0;
gem_context_set_param(fd, &arg);
v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu()
(Lionel)
v3: Add ability to program this per engine (Chris)
v4: Move most get_sseu() into i915_gem_context.c (Lionel)
v5: Validate sseu configuration against the device's capabilities (Lionel)
v6: Change context powergating settings through MI_SDM on kernel context
(Chris)
v7: Synchronize the requests following a powergating setting change using
a global dependency (Chris)
Iterate timelines through dev_priv.gt.active_rings (Tvrtko)
Disable RPCS configuration setting for non capable users
(Lionel/Tvrtko)
v8: s/union intel_sseu/struct intel_sseu/ (Lionel)
s/dev_priv/i915/ (Tvrtko)
Change uapi class/instance fields to u16 (Tvrtko)
Bump mask fields to 64bits (Lionel)
Don't return EPERM when dynamic sseu is disabled (Tvrtko)
v9: Import context image into kernel context's ppgtt only when
reconfiguring powergated slice/subslices (Chris)
Use aliasing ppgtt when needed (Michel)
Tvrtko Ursulin:
v10:
* Update for upstream changes.
* Request submit needs a RPM reference.
* Reject on !FULL_PPGTT for simplicity.
* Pull out get/set param to helpers for readability and less indent.
* Use i915_request_await_dma_fence in add_global_barrier to skip waits
on the same timeline and avoid GEM_BUG_ON.
* No need to explicitly assign a NULL pointer to engine in legacy mode.
* No need to move gen8_make_rpcs up.
* Factored out global barrier as prep patch.
* Allow to only CAP_SYS_ADMIN if !Gen11.
v11:
* Remove engine vfunc in favour of local helper. (Chris Wilson)
* Stop retiring requests before updates since it is not needed
(Chris Wilson)
* Implement direct CPU update path for idle contexts. (Chris Wilson)
* Left side dependency needs only be on the same context timeline.
(Chris Wilson)
* It is sufficient to order the timeline. (Chris Wilson)
* Reject !RCS configuration attempts with -ENODEV for now.
v12:
* Rebase for make_rpcs.
v13:
* Centralize SSEU normalization to make_rpcs.
* Type width checking (uAPI <-> implementation).
* Gen11 restrictions uAPI checks.
* Gen11 subslice count differences handling.
Chris Wilson:
* args->size handling fixes.
* Update context image from GGTT.
* Postpone context image update to pinning.
* Use i915_gem_active_raw instead of last_request_on_engine.
v14:
* Add activity tracker on intel_context to fix the lifetime issues
and simplify the code. (Chris Wilson)
v15:
* Fix context pin leak if no space in ring by simplifying the
context pinning sequence.
v16:
* Rebase for context get/set param locking changes.
* Just -ENODEV on !Gen11. (Joonas)
v17:
* Fix one Gen11 subslice enablement rule.
* Handle error from i915_sw_fence_await_sw_fence_gfp. (Chris Wilson)
v18:
* Update commit message. (Joonas)
* Restrict uAPI to VME use case. (Joonas)
v19:
* Rebase.
v20:
* Rebase for ce->active_tracker.
v21:
* Rebase for IS_GEN changes.
v22:
* Reserve uAPI for flags straight away. (Chris Wilson)
v23:
* Rebase for RUNTIME_INFO.
v24:
* Added some headline docs for the uapi usage. (Joonas/Chris)
v25:
* Renamed class/instance to engine_class/engine_instance to avoid clash
with C++ keyword. (Tony Ye)
v26:
* Rebased for runtime pm api changes.
v27:
* Rebased for intel_context_init.
* Wrap commit msg to 75.
v28:
(Chris Wilson)
* Use i915_gem_ggtt.
* Use i915_request_await_dma_fence to show a better example.
v29:
* i915_timeline_set_barrier can now fail. (Chris Wilson)
v30:
* Capture some acks.
v31:
* Drop the WARN_ON from use controllable paths. (Chris Wilson)
* Use overflows_type for all checks.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100899
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107634
Issue: https://github.com/intel/media-driver/issues/267
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Zhipeng Gong <zhipeng.gong@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tony Ye <tony.ye@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: Timo Aaltonen <timo.aaltonen@canonical.com>
Acked-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Stéphane Marchesin <marcheu@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190205095032.22673-4-tvrtko.ursulin@linux.intel.com
2019-02-05 17:50:31 +08:00
|
|
|
if (!ret)
|
|
|
|
ce->sseu = sseu;
|
|
|
|
|
2019-03-08 21:25:22 +08:00
|
|
|
unlock:
|
2019-04-27 00:33:32 +08:00
|
|
|
intel_context_unlock_pinned(ce);
|
2019-02-05 17:50:32 +08:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only)
We want to allow userspace to reconfigure the subslice configuration on a
per context basis.
This is required for the functional requirement of shutting down non-VME
enabled sub-slices on Gen11 parts.
To do so, we expose a context parameter to allow adjustment of the RPCS
register stored within the context image (and currently not accessible via
LRI).
If the context is adjusted before first use or whilst idle, the adjustment
is for "free"; otherwise if the context is active we queue a request to do
so (using the kernel context), following all other activity by that
context, which is also marked as barrier for all following submission
against the same context.
Since the overhead of device re-configuration during context switching can
be significant, especially in multi-context workloads, we limit this new
uAPI to only support the Gen11 VME use case. In this use case either the
device is fully enabled, and exactly one slice and half of the subslices
are enabled.
Example usage:
struct drm_i915_gem_context_param_sseu sseu = { };
struct drm_i915_gem_context_param arg = {
.param = I915_CONTEXT_PARAM_SSEU,
.ctx_id = gem_context_create(fd),
.size = sizeof(sseu),
.value = to_user_pointer(&sseu)
};
/* Query device defaults. */
gem_context_get_param(fd, &arg);
/* Set VME configuration on a 1x6x8 part. */
sseu.slice_mask = 0x1;
sseu.subslice_mask = 0xe0;
gem_context_set_param(fd, &arg);
v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu()
(Lionel)
v3: Add ability to program this per engine (Chris)
v4: Move most get_sseu() into i915_gem_context.c (Lionel)
v5: Validate sseu configuration against the device's capabilities (Lionel)
v6: Change context powergating settings through MI_SDM on kernel context
(Chris)
v7: Synchronize the requests following a powergating setting change using
a global dependency (Chris)
Iterate timelines through dev_priv.gt.active_rings (Tvrtko)
Disable RPCS configuration setting for non capable users
(Lionel/Tvrtko)
v8: s/union intel_sseu/struct intel_sseu/ (Lionel)
s/dev_priv/i915/ (Tvrtko)
Change uapi class/instance fields to u16 (Tvrtko)
Bump mask fields to 64bits (Lionel)
Don't return EPERM when dynamic sseu is disabled (Tvrtko)
v9: Import context image into kernel context's ppgtt only when
reconfiguring powergated slice/subslices (Chris)
Use aliasing ppgtt when needed (Michel)
Tvrtko Ursulin:
v10:
* Update for upstream changes.
* Request submit needs a RPM reference.
* Reject on !FULL_PPGTT for simplicity.
* Pull out get/set param to helpers for readability and less indent.
* Use i915_request_await_dma_fence in add_global_barrier to skip waits
on the same timeline and avoid GEM_BUG_ON.
* No need to explicitly assign a NULL pointer to engine in legacy mode.
* No need to move gen8_make_rpcs up.
* Factored out global barrier as prep patch.
* Allow to only CAP_SYS_ADMIN if !Gen11.
v11:
* Remove engine vfunc in favour of local helper. (Chris Wilson)
* Stop retiring requests before updates since it is not needed
(Chris Wilson)
* Implement direct CPU update path for idle contexts. (Chris Wilson)
* Left side dependency needs only be on the same context timeline.
(Chris Wilson)
* It is sufficient to order the timeline. (Chris Wilson)
* Reject !RCS configuration attempts with -ENODEV for now.
v12:
* Rebase for make_rpcs.
v13:
* Centralize SSEU normalization to make_rpcs.
* Type width checking (uAPI <-> implementation).
* Gen11 restrictions uAPI checks.
* Gen11 subslice count differences handling.
Chris Wilson:
* args->size handling fixes.
* Update context image from GGTT.
* Postpone context image update to pinning.
* Use i915_gem_active_raw instead of last_request_on_engine.
v14:
* Add activity tracker on intel_context to fix the lifetime issues
and simplify the code. (Chris Wilson)
v15:
* Fix context pin leak if no space in ring by simplifying the
context pinning sequence.
v16:
* Rebase for context get/set param locking changes.
* Just -ENODEV on !Gen11. (Joonas)
v17:
* Fix one Gen11 subslice enablement rule.
* Handle error from i915_sw_fence_await_sw_fence_gfp. (Chris Wilson)
v18:
* Update commit message. (Joonas)
* Restrict uAPI to VME use case. (Joonas)
v19:
* Rebase.
v20:
* Rebase for ce->active_tracker.
v21:
* Rebase for IS_GEN changes.
v22:
* Reserve uAPI for flags straight away. (Chris Wilson)
v23:
* Rebase for RUNTIME_INFO.
v24:
* Added some headline docs for the uapi usage. (Joonas/Chris)
v25:
* Renamed class/instance to engine_class/engine_instance to avoid clash
with C++ keyword. (Tony Ye)
v26:
* Rebased for runtime pm api changes.
v27:
* Rebased for intel_context_init.
* Wrap commit msg to 75.
v28:
(Chris Wilson)
* Use i915_gem_ggtt.
* Use i915_request_await_dma_fence to show a better example.
v29:
* i915_timeline_set_barrier can now fail. (Chris Wilson)
v30:
* Capture some acks.
v31:
* Drop the WARN_ON from use controllable paths. (Chris Wilson)
* Use overflows_type for all checks.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100899
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107634
Issue: https://github.com/intel/media-driver/issues/267
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Zhipeng Gong <zhipeng.gong@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tony Ye <tony.ye@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: Timo Aaltonen <timo.aaltonen@canonical.com>
Acked-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Stéphane Marchesin <marcheu@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190205095032.22673-4-tvrtko.ursulin@linux.intel.com
2019-02-05 17:50:31 +08:00
|
|
|
static int
|
|
|
|
user_to_context_sseu(struct drm_i915_private *i915,
|
|
|
|
const struct drm_i915_gem_context_param_sseu *user,
|
|
|
|
struct intel_sseu *context)
|
|
|
|
{
|
|
|
|
const struct sseu_dev_info *device = &RUNTIME_INFO(i915)->sseu;
|
|
|
|
|
|
|
|
/* No zeros in any field. */
|
|
|
|
if (!user->slice_mask || !user->subslice_mask ||
|
|
|
|
!user->min_eus_per_subslice || !user->max_eus_per_subslice)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
/* Max > min. */
|
|
|
|
if (user->max_eus_per_subslice < user->min_eus_per_subslice)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Some future proofing on the types since the uAPI is wider than the
|
|
|
|
* current internal implementation.
|
|
|
|
*/
|
|
|
|
if (overflows_type(user->slice_mask, context->slice_mask) ||
|
|
|
|
overflows_type(user->subslice_mask, context->subslice_mask) ||
|
|
|
|
overflows_type(user->min_eus_per_subslice,
|
|
|
|
context->min_eus_per_subslice) ||
|
|
|
|
overflows_type(user->max_eus_per_subslice,
|
|
|
|
context->max_eus_per_subslice))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
/* Check validity against hardware. */
|
|
|
|
if (user->slice_mask & ~device->slice_mask)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (user->subslice_mask & ~device->subslice_mask[0])
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (user->max_eus_per_subslice > device->max_eus_per_subslice)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
context->slice_mask = user->slice_mask;
|
|
|
|
context->subslice_mask = user->subslice_mask;
|
|
|
|
context->min_eus_per_subslice = user->min_eus_per_subslice;
|
|
|
|
context->max_eus_per_subslice = user->max_eus_per_subslice;
|
|
|
|
|
|
|
|
/* Part specific restrictions. */
|
|
|
|
if (IS_GEN(i915, 11)) {
|
|
|
|
unsigned int hw_s = hweight8(device->slice_mask);
|
|
|
|
unsigned int hw_ss_per_s = hweight8(device->subslice_mask[0]);
|
|
|
|
unsigned int req_s = hweight8(context->slice_mask);
|
|
|
|
unsigned int req_ss = hweight8(context->subslice_mask);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Only full subslice enablement is possible if more than one
|
|
|
|
* slice is turned on.
|
|
|
|
*/
|
|
|
|
if (req_s > 1 && req_ss != hw_ss_per_s)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If more than four (SScount bitfield limit) subslices are
|
|
|
|
* requested then the number has to be even.
|
|
|
|
*/
|
|
|
|
if (req_ss > 4 && (req_ss & 1))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* If only one slice is enabled and subslice count is below the
|
|
|
|
* device full enablement, it must be at most half of the all
|
|
|
|
* available subslices.
|
|
|
|
*/
|
|
|
|
if (req_s == 1 && req_ss < hw_ss_per_s &&
|
|
|
|
req_ss > (hw_ss_per_s / 2))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
/* ABI restriction - VME use case only. */
|
|
|
|
|
|
|
|
/* All slices or one slice only. */
|
|
|
|
if (req_s != 1 && req_s != hw_s)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Half subslices or full enablement only when one slice is
|
|
|
|
* enabled.
|
|
|
|
*/
|
|
|
|
if (req_s == 1 &&
|
|
|
|
(req_ss != hw_ss_per_s && req_ss != (hw_ss_per_s / 2)))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
/* No EU configuration changes. */
|
|
|
|
if ((user->min_eus_per_subslice !=
|
|
|
|
device->max_eus_per_subslice) ||
|
|
|
|
(user->max_eus_per_subslice !=
|
|
|
|
device->max_eus_per_subslice))
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int set_sseu(struct i915_gem_context *ctx,
|
|
|
|
struct drm_i915_gem_context_param *args)
|
|
|
|
{
|
|
|
|
struct drm_i915_private *i915 = ctx->i915;
|
|
|
|
struct drm_i915_gem_context_param_sseu user_sseu;
|
2019-04-27 00:33:32 +08:00
|
|
|
struct intel_context *ce;
|
drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only)
We want to allow userspace to reconfigure the subslice configuration on a
per context basis.
This is required for the functional requirement of shutting down non-VME
enabled sub-slices on Gen11 parts.
To do so, we expose a context parameter to allow adjustment of the RPCS
register stored within the context image (and currently not accessible via
LRI).
If the context is adjusted before first use or whilst idle, the adjustment
is for "free"; otherwise if the context is active we queue a request to do
so (using the kernel context), following all other activity by that
context, which is also marked as barrier for all following submission
against the same context.
Since the overhead of device re-configuration during context switching can
be significant, especially in multi-context workloads, we limit this new
uAPI to only support the Gen11 VME use case. In this use case either the
device is fully enabled, and exactly one slice and half of the subslices
are enabled.
Example usage:
struct drm_i915_gem_context_param_sseu sseu = { };
struct drm_i915_gem_context_param arg = {
.param = I915_CONTEXT_PARAM_SSEU,
.ctx_id = gem_context_create(fd),
.size = sizeof(sseu),
.value = to_user_pointer(&sseu)
};
/* Query device defaults. */
gem_context_get_param(fd, &arg);
/* Set VME configuration on a 1x6x8 part. */
sseu.slice_mask = 0x1;
sseu.subslice_mask = 0xe0;
gem_context_set_param(fd, &arg);
v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu()
(Lionel)
v3: Add ability to program this per engine (Chris)
v4: Move most get_sseu() into i915_gem_context.c (Lionel)
v5: Validate sseu configuration against the device's capabilities (Lionel)
v6: Change context powergating settings through MI_SDM on kernel context
(Chris)
v7: Synchronize the requests following a powergating setting change using
a global dependency (Chris)
Iterate timelines through dev_priv.gt.active_rings (Tvrtko)
Disable RPCS configuration setting for non capable users
(Lionel/Tvrtko)
v8: s/union intel_sseu/struct intel_sseu/ (Lionel)
s/dev_priv/i915/ (Tvrtko)
Change uapi class/instance fields to u16 (Tvrtko)
Bump mask fields to 64bits (Lionel)
Don't return EPERM when dynamic sseu is disabled (Tvrtko)
v9: Import context image into kernel context's ppgtt only when
reconfiguring powergated slice/subslices (Chris)
Use aliasing ppgtt when needed (Michel)
Tvrtko Ursulin:
v10:
* Update for upstream changes.
* Request submit needs a RPM reference.
* Reject on !FULL_PPGTT for simplicity.
* Pull out get/set param to helpers for readability and less indent.
* Use i915_request_await_dma_fence in add_global_barrier to skip waits
on the same timeline and avoid GEM_BUG_ON.
* No need to explicitly assign a NULL pointer to engine in legacy mode.
* No need to move gen8_make_rpcs up.
* Factored out global barrier as prep patch.
* Allow to only CAP_SYS_ADMIN if !Gen11.
v11:
* Remove engine vfunc in favour of local helper. (Chris Wilson)
* Stop retiring requests before updates since it is not needed
(Chris Wilson)
* Implement direct CPU update path for idle contexts. (Chris Wilson)
* Left side dependency needs only be on the same context timeline.
(Chris Wilson)
* It is sufficient to order the timeline. (Chris Wilson)
* Reject !RCS configuration attempts with -ENODEV for now.
v12:
* Rebase for make_rpcs.
v13:
* Centralize SSEU normalization to make_rpcs.
* Type width checking (uAPI <-> implementation).
* Gen11 restrictions uAPI checks.
* Gen11 subslice count differences handling.
Chris Wilson:
* args->size handling fixes.
* Update context image from GGTT.
* Postpone context image update to pinning.
* Use i915_gem_active_raw instead of last_request_on_engine.
v14:
* Add activity tracker on intel_context to fix the lifetime issues
and simplify the code. (Chris Wilson)
v15:
* Fix context pin leak if no space in ring by simplifying the
context pinning sequence.
v16:
* Rebase for context get/set param locking changes.
* Just -ENODEV on !Gen11. (Joonas)
v17:
* Fix one Gen11 subslice enablement rule.
* Handle error from i915_sw_fence_await_sw_fence_gfp. (Chris Wilson)
v18:
* Update commit message. (Joonas)
* Restrict uAPI to VME use case. (Joonas)
v19:
* Rebase.
v20:
* Rebase for ce->active_tracker.
v21:
* Rebase for IS_GEN changes.
v22:
* Reserve uAPI for flags straight away. (Chris Wilson)
v23:
* Rebase for RUNTIME_INFO.
v24:
* Added some headline docs for the uapi usage. (Joonas/Chris)
v25:
* Renamed class/instance to engine_class/engine_instance to avoid clash
with C++ keyword. (Tony Ye)
v26:
* Rebased for runtime pm api changes.
v27:
* Rebased for intel_context_init.
* Wrap commit msg to 75.
v28:
(Chris Wilson)
* Use i915_gem_ggtt.
* Use i915_request_await_dma_fence to show a better example.
v29:
* i915_timeline_set_barrier can now fail. (Chris Wilson)
v30:
* Capture some acks.
v31:
* Drop the WARN_ON from use controllable paths. (Chris Wilson)
* Use overflows_type for all checks.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100899
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107634
Issue: https://github.com/intel/media-driver/issues/267
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Zhipeng Gong <zhipeng.gong@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tony Ye <tony.ye@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: Timo Aaltonen <timo.aaltonen@canonical.com>
Acked-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Stéphane Marchesin <marcheu@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190205095032.22673-4-tvrtko.ursulin@linux.intel.com
2019-02-05 17:50:31 +08:00
|
|
|
struct intel_sseu sseu;
|
2019-05-22 05:11:27 +08:00
|
|
|
unsigned long lookup;
|
drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only)
We want to allow userspace to reconfigure the subslice configuration on a
per context basis.
This is required for the functional requirement of shutting down non-VME
enabled sub-slices on Gen11 parts.
To do so, we expose a context parameter to allow adjustment of the RPCS
register stored within the context image (and currently not accessible via
LRI).
If the context is adjusted before first use or whilst idle, the adjustment
is for "free"; otherwise if the context is active we queue a request to do
so (using the kernel context), following all other activity by that
context, which is also marked as barrier for all following submission
against the same context.
Since the overhead of device re-configuration during context switching can
be significant, especially in multi-context workloads, we limit this new
uAPI to only support the Gen11 VME use case. In this use case either the
device is fully enabled, and exactly one slice and half of the subslices
are enabled.
Example usage:
struct drm_i915_gem_context_param_sseu sseu = { };
struct drm_i915_gem_context_param arg = {
.param = I915_CONTEXT_PARAM_SSEU,
.ctx_id = gem_context_create(fd),
.size = sizeof(sseu),
.value = to_user_pointer(&sseu)
};
/* Query device defaults. */
gem_context_get_param(fd, &arg);
/* Set VME configuration on a 1x6x8 part. */
sseu.slice_mask = 0x1;
sseu.subslice_mask = 0xe0;
gem_context_set_param(fd, &arg);
v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu()
(Lionel)
v3: Add ability to program this per engine (Chris)
v4: Move most get_sseu() into i915_gem_context.c (Lionel)
v5: Validate sseu configuration against the device's capabilities (Lionel)
v6: Change context powergating settings through MI_SDM on kernel context
(Chris)
v7: Synchronize the requests following a powergating setting change using
a global dependency (Chris)
Iterate timelines through dev_priv.gt.active_rings (Tvrtko)
Disable RPCS configuration setting for non capable users
(Lionel/Tvrtko)
v8: s/union intel_sseu/struct intel_sseu/ (Lionel)
s/dev_priv/i915/ (Tvrtko)
Change uapi class/instance fields to u16 (Tvrtko)
Bump mask fields to 64bits (Lionel)
Don't return EPERM when dynamic sseu is disabled (Tvrtko)
v9: Import context image into kernel context's ppgtt only when
reconfiguring powergated slice/subslices (Chris)
Use aliasing ppgtt when needed (Michel)
Tvrtko Ursulin:
v10:
* Update for upstream changes.
* Request submit needs a RPM reference.
* Reject on !FULL_PPGTT for simplicity.
* Pull out get/set param to helpers for readability and less indent.
* Use i915_request_await_dma_fence in add_global_barrier to skip waits
on the same timeline and avoid GEM_BUG_ON.
* No need to explicitly assign a NULL pointer to engine in legacy mode.
* No need to move gen8_make_rpcs up.
* Factored out global barrier as prep patch.
* Allow to only CAP_SYS_ADMIN if !Gen11.
v11:
* Remove engine vfunc in favour of local helper. (Chris Wilson)
* Stop retiring requests before updates since it is not needed
(Chris Wilson)
* Implement direct CPU update path for idle contexts. (Chris Wilson)
* Left side dependency needs only be on the same context timeline.
(Chris Wilson)
* It is sufficient to order the timeline. (Chris Wilson)
* Reject !RCS configuration attempts with -ENODEV for now.
v12:
* Rebase for make_rpcs.
v13:
* Centralize SSEU normalization to make_rpcs.
* Type width checking (uAPI <-> implementation).
* Gen11 restrictions uAPI checks.
* Gen11 subslice count differences handling.
Chris Wilson:
* args->size handling fixes.
* Update context image from GGTT.
* Postpone context image update to pinning.
* Use i915_gem_active_raw instead of last_request_on_engine.
v14:
* Add activity tracker on intel_context to fix the lifetime issues
and simplify the code. (Chris Wilson)
v15:
* Fix context pin leak if no space in ring by simplifying the
context pinning sequence.
v16:
* Rebase for context get/set param locking changes.
* Just -ENODEV on !Gen11. (Joonas)
v17:
* Fix one Gen11 subslice enablement rule.
* Handle error from i915_sw_fence_await_sw_fence_gfp. (Chris Wilson)
v18:
* Update commit message. (Joonas)
* Restrict uAPI to VME use case. (Joonas)
v19:
* Rebase.
v20:
* Rebase for ce->active_tracker.
v21:
* Rebase for IS_GEN changes.
v22:
* Reserve uAPI for flags straight away. (Chris Wilson)
v23:
* Rebase for RUNTIME_INFO.
v24:
* Added some headline docs for the uapi usage. (Joonas/Chris)
v25:
* Renamed class/instance to engine_class/engine_instance to avoid clash
with C++ keyword. (Tony Ye)
v26:
* Rebased for runtime pm api changes.
v27:
* Rebased for intel_context_init.
* Wrap commit msg to 75.
v28:
(Chris Wilson)
* Use i915_gem_ggtt.
* Use i915_request_await_dma_fence to show a better example.
v29:
* i915_timeline_set_barrier can now fail. (Chris Wilson)
v30:
* Capture some acks.
v31:
* Drop the WARN_ON from use controllable paths. (Chris Wilson)
* Use overflows_type for all checks.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100899
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107634
Issue: https://github.com/intel/media-driver/issues/267
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Zhipeng Gong <zhipeng.gong@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tony Ye <tony.ye@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: Timo Aaltonen <timo.aaltonen@canonical.com>
Acked-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Stéphane Marchesin <marcheu@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190205095032.22673-4-tvrtko.ursulin@linux.intel.com
2019-02-05 17:50:31 +08:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (args->size < sizeof(user_sseu))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (!IS_GEN(i915, 11))
|
|
|
|
return -ENODEV;
|
|
|
|
|
|
|
|
if (copy_from_user(&user_sseu, u64_to_user_ptr(args->value),
|
|
|
|
sizeof(user_sseu)))
|
|
|
|
return -EFAULT;
|
|
|
|
|
2019-05-22 05:11:27 +08:00
|
|
|
if (user_sseu.rsvd)
|
drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only)
We want to allow userspace to reconfigure the subslice configuration on a
per context basis.
This is required for the functional requirement of shutting down non-VME
enabled sub-slices on Gen11 parts.
To do so, we expose a context parameter to allow adjustment of the RPCS
register stored within the context image (and currently not accessible via
LRI).
If the context is adjusted before first use or whilst idle, the adjustment
is for "free"; otherwise if the context is active we queue a request to do
so (using the kernel context), following all other activity by that
context, which is also marked as barrier for all following submission
against the same context.
Since the overhead of device re-configuration during context switching can
be significant, especially in multi-context workloads, we limit this new
uAPI to only support the Gen11 VME use case. In this use case either the
device is fully enabled, and exactly one slice and half of the subslices
are enabled.
Example usage:
struct drm_i915_gem_context_param_sseu sseu = { };
struct drm_i915_gem_context_param arg = {
.param = I915_CONTEXT_PARAM_SSEU,
.ctx_id = gem_context_create(fd),
.size = sizeof(sseu),
.value = to_user_pointer(&sseu)
};
/* Query device defaults. */
gem_context_get_param(fd, &arg);
/* Set VME configuration on a 1x6x8 part. */
sseu.slice_mask = 0x1;
sseu.subslice_mask = 0xe0;
gem_context_set_param(fd, &arg);
v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu()
(Lionel)
v3: Add ability to program this per engine (Chris)
v4: Move most get_sseu() into i915_gem_context.c (Lionel)
v5: Validate sseu configuration against the device's capabilities (Lionel)
v6: Change context powergating settings through MI_SDM on kernel context
(Chris)
v7: Synchronize the requests following a powergating setting change using
a global dependency (Chris)
Iterate timelines through dev_priv.gt.active_rings (Tvrtko)
Disable RPCS configuration setting for non capable users
(Lionel/Tvrtko)
v8: s/union intel_sseu/struct intel_sseu/ (Lionel)
s/dev_priv/i915/ (Tvrtko)
Change uapi class/instance fields to u16 (Tvrtko)
Bump mask fields to 64bits (Lionel)
Don't return EPERM when dynamic sseu is disabled (Tvrtko)
v9: Import context image into kernel context's ppgtt only when
reconfiguring powergated slice/subslices (Chris)
Use aliasing ppgtt when needed (Michel)
Tvrtko Ursulin:
v10:
* Update for upstream changes.
* Request submit needs a RPM reference.
* Reject on !FULL_PPGTT for simplicity.
* Pull out get/set param to helpers for readability and less indent.
* Use i915_request_await_dma_fence in add_global_barrier to skip waits
on the same timeline and avoid GEM_BUG_ON.
* No need to explicitly assign a NULL pointer to engine in legacy mode.
* No need to move gen8_make_rpcs up.
* Factored out global barrier as prep patch.
* Allow to only CAP_SYS_ADMIN if !Gen11.
v11:
* Remove engine vfunc in favour of local helper. (Chris Wilson)
* Stop retiring requests before updates since it is not needed
(Chris Wilson)
* Implement direct CPU update path for idle contexts. (Chris Wilson)
* Left side dependency needs only be on the same context timeline.
(Chris Wilson)
* It is sufficient to order the timeline. (Chris Wilson)
* Reject !RCS configuration attempts with -ENODEV for now.
v12:
* Rebase for make_rpcs.
v13:
* Centralize SSEU normalization to make_rpcs.
* Type width checking (uAPI <-> implementation).
* Gen11 restrictions uAPI checks.
* Gen11 subslice count differences handling.
Chris Wilson:
* args->size handling fixes.
* Update context image from GGTT.
* Postpone context image update to pinning.
* Use i915_gem_active_raw instead of last_request_on_engine.
v14:
* Add activity tracker on intel_context to fix the lifetime issues
and simplify the code. (Chris Wilson)
v15:
* Fix context pin leak if no space in ring by simplifying the
context pinning sequence.
v16:
* Rebase for context get/set param locking changes.
* Just -ENODEV on !Gen11. (Joonas)
v17:
* Fix one Gen11 subslice enablement rule.
* Handle error from i915_sw_fence_await_sw_fence_gfp. (Chris Wilson)
v18:
* Update commit message. (Joonas)
* Restrict uAPI to VME use case. (Joonas)
v19:
* Rebase.
v20:
* Rebase for ce->active_tracker.
v21:
* Rebase for IS_GEN changes.
v22:
* Reserve uAPI for flags straight away. (Chris Wilson)
v23:
* Rebase for RUNTIME_INFO.
v24:
* Added some headline docs for the uapi usage. (Joonas/Chris)
v25:
* Renamed class/instance to engine_class/engine_instance to avoid clash
with C++ keyword. (Tony Ye)
v26:
* Rebased for runtime pm api changes.
v27:
* Rebased for intel_context_init.
* Wrap commit msg to 75.
v28:
(Chris Wilson)
* Use i915_gem_ggtt.
* Use i915_request_await_dma_fence to show a better example.
v29:
* i915_timeline_set_barrier can now fail. (Chris Wilson)
v30:
* Capture some acks.
v31:
* Drop the WARN_ON from use controllable paths. (Chris Wilson)
* Use overflows_type for all checks.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100899
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107634
Issue: https://github.com/intel/media-driver/issues/267
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Zhipeng Gong <zhipeng.gong@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tony Ye <tony.ye@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: Timo Aaltonen <timo.aaltonen@canonical.com>
Acked-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Stéphane Marchesin <marcheu@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190205095032.22673-4-tvrtko.ursulin@linux.intel.com
2019-02-05 17:50:31 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
2019-05-22 05:11:27 +08:00
|
|
|
if (user_sseu.flags & ~(I915_CONTEXT_SSEU_FLAG_ENGINE_INDEX))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
lookup = 0;
|
|
|
|
if (user_sseu.flags & I915_CONTEXT_SSEU_FLAG_ENGINE_INDEX)
|
|
|
|
lookup |= LOOKUP_USER_INDEX;
|
|
|
|
|
|
|
|
ce = lookup_user_engine(ctx, lookup, &user_sseu.engine);
|
2019-04-27 00:33:32 +08:00
|
|
|
if (IS_ERR(ce))
|
|
|
|
return PTR_ERR(ce);
|
drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only)
We want to allow userspace to reconfigure the subslice configuration on a
per context basis.
This is required for the functional requirement of shutting down non-VME
enabled sub-slices on Gen11 parts.
To do so, we expose a context parameter to allow adjustment of the RPCS
register stored within the context image (and currently not accessible via
LRI).
If the context is adjusted before first use or whilst idle, the adjustment
is for "free"; otherwise if the context is active we queue a request to do
so (using the kernel context), following all other activity by that
context, which is also marked as barrier for all following submission
against the same context.
Since the overhead of device re-configuration during context switching can
be significant, especially in multi-context workloads, we limit this new
uAPI to only support the Gen11 VME use case. In this use case either the
device is fully enabled, and exactly one slice and half of the subslices
are enabled.
Example usage:
struct drm_i915_gem_context_param_sseu sseu = { };
struct drm_i915_gem_context_param arg = {
.param = I915_CONTEXT_PARAM_SSEU,
.ctx_id = gem_context_create(fd),
.size = sizeof(sseu),
.value = to_user_pointer(&sseu)
};
/* Query device defaults. */
gem_context_get_param(fd, &arg);
/* Set VME configuration on a 1x6x8 part. */
sseu.slice_mask = 0x1;
sseu.subslice_mask = 0xe0;
gem_context_set_param(fd, &arg);
v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu()
(Lionel)
v3: Add ability to program this per engine (Chris)
v4: Move most get_sseu() into i915_gem_context.c (Lionel)
v5: Validate sseu configuration against the device's capabilities (Lionel)
v6: Change context powergating settings through MI_SDM on kernel context
(Chris)
v7: Synchronize the requests following a powergating setting change using
a global dependency (Chris)
Iterate timelines through dev_priv.gt.active_rings (Tvrtko)
Disable RPCS configuration setting for non capable users
(Lionel/Tvrtko)
v8: s/union intel_sseu/struct intel_sseu/ (Lionel)
s/dev_priv/i915/ (Tvrtko)
Change uapi class/instance fields to u16 (Tvrtko)
Bump mask fields to 64bits (Lionel)
Don't return EPERM when dynamic sseu is disabled (Tvrtko)
v9: Import context image into kernel context's ppgtt only when
reconfiguring powergated slice/subslices (Chris)
Use aliasing ppgtt when needed (Michel)
Tvrtko Ursulin:
v10:
* Update for upstream changes.
* Request submit needs a RPM reference.
* Reject on !FULL_PPGTT for simplicity.
* Pull out get/set param to helpers for readability and less indent.
* Use i915_request_await_dma_fence in add_global_barrier to skip waits
on the same timeline and avoid GEM_BUG_ON.
* No need to explicitly assign a NULL pointer to engine in legacy mode.
* No need to move gen8_make_rpcs up.
* Factored out global barrier as prep patch.
* Allow to only CAP_SYS_ADMIN if !Gen11.
v11:
* Remove engine vfunc in favour of local helper. (Chris Wilson)
* Stop retiring requests before updates since it is not needed
(Chris Wilson)
* Implement direct CPU update path for idle contexts. (Chris Wilson)
* Left side dependency needs only be on the same context timeline.
(Chris Wilson)
* It is sufficient to order the timeline. (Chris Wilson)
* Reject !RCS configuration attempts with -ENODEV for now.
v12:
* Rebase for make_rpcs.
v13:
* Centralize SSEU normalization to make_rpcs.
* Type width checking (uAPI <-> implementation).
* Gen11 restrictions uAPI checks.
* Gen11 subslice count differences handling.
Chris Wilson:
* args->size handling fixes.
* Update context image from GGTT.
* Postpone context image update to pinning.
* Use i915_gem_active_raw instead of last_request_on_engine.
v14:
* Add activity tracker on intel_context to fix the lifetime issues
and simplify the code. (Chris Wilson)
v15:
* Fix context pin leak if no space in ring by simplifying the
context pinning sequence.
v16:
* Rebase for context get/set param locking changes.
* Just -ENODEV on !Gen11. (Joonas)
v17:
* Fix one Gen11 subslice enablement rule.
* Handle error from i915_sw_fence_await_sw_fence_gfp. (Chris Wilson)
v18:
* Update commit message. (Joonas)
* Restrict uAPI to VME use case. (Joonas)
v19:
* Rebase.
v20:
* Rebase for ce->active_tracker.
v21:
* Rebase for IS_GEN changes.
v22:
* Reserve uAPI for flags straight away. (Chris Wilson)
v23:
* Rebase for RUNTIME_INFO.
v24:
* Added some headline docs for the uapi usage. (Joonas/Chris)
v25:
* Renamed class/instance to engine_class/engine_instance to avoid clash
with C++ keyword. (Tony Ye)
v26:
* Rebased for runtime pm api changes.
v27:
* Rebased for intel_context_init.
* Wrap commit msg to 75.
v28:
(Chris Wilson)
* Use i915_gem_ggtt.
* Use i915_request_await_dma_fence to show a better example.
v29:
* i915_timeline_set_barrier can now fail. (Chris Wilson)
v30:
* Capture some acks.
v31:
* Drop the WARN_ON from use controllable paths. (Chris Wilson)
* Use overflows_type for all checks.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100899
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107634
Issue: https://github.com/intel/media-driver/issues/267
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Zhipeng Gong <zhipeng.gong@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tony Ye <tony.ye@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: Timo Aaltonen <timo.aaltonen@canonical.com>
Acked-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Stéphane Marchesin <marcheu@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190205095032.22673-4-tvrtko.ursulin@linux.intel.com
2019-02-05 17:50:31 +08:00
|
|
|
|
|
|
|
/* Only render engine supports RPCS configuration. */
|
2019-04-27 00:33:32 +08:00
|
|
|
if (ce->engine->class != RENDER_CLASS) {
|
|
|
|
ret = -ENODEV;
|
|
|
|
goto out_ce;
|
|
|
|
}
|
drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only)
We want to allow userspace to reconfigure the subslice configuration on a
per context basis.
This is required for the functional requirement of shutting down non-VME
enabled sub-slices on Gen11 parts.
To do so, we expose a context parameter to allow adjustment of the RPCS
register stored within the context image (and currently not accessible via
LRI).
If the context is adjusted before first use or whilst idle, the adjustment
is for "free"; otherwise if the context is active we queue a request to do
so (using the kernel context), following all other activity by that
context, which is also marked as barrier for all following submission
against the same context.
Since the overhead of device re-configuration during context switching can
be significant, especially in multi-context workloads, we limit this new
uAPI to only support the Gen11 VME use case. In this use case either the
device is fully enabled, and exactly one slice and half of the subslices
are enabled.
Example usage:
struct drm_i915_gem_context_param_sseu sseu = { };
struct drm_i915_gem_context_param arg = {
.param = I915_CONTEXT_PARAM_SSEU,
.ctx_id = gem_context_create(fd),
.size = sizeof(sseu),
.value = to_user_pointer(&sseu)
};
/* Query device defaults. */
gem_context_get_param(fd, &arg);
/* Set VME configuration on a 1x6x8 part. */
sseu.slice_mask = 0x1;
sseu.subslice_mask = 0xe0;
gem_context_set_param(fd, &arg);
v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu()
(Lionel)
v3: Add ability to program this per engine (Chris)
v4: Move most get_sseu() into i915_gem_context.c (Lionel)
v5: Validate sseu configuration against the device's capabilities (Lionel)
v6: Change context powergating settings through MI_SDM on kernel context
(Chris)
v7: Synchronize the requests following a powergating setting change using
a global dependency (Chris)
Iterate timelines through dev_priv.gt.active_rings (Tvrtko)
Disable RPCS configuration setting for non capable users
(Lionel/Tvrtko)
v8: s/union intel_sseu/struct intel_sseu/ (Lionel)
s/dev_priv/i915/ (Tvrtko)
Change uapi class/instance fields to u16 (Tvrtko)
Bump mask fields to 64bits (Lionel)
Don't return EPERM when dynamic sseu is disabled (Tvrtko)
v9: Import context image into kernel context's ppgtt only when
reconfiguring powergated slice/subslices (Chris)
Use aliasing ppgtt when needed (Michel)
Tvrtko Ursulin:
v10:
* Update for upstream changes.
* Request submit needs a RPM reference.
* Reject on !FULL_PPGTT for simplicity.
* Pull out get/set param to helpers for readability and less indent.
* Use i915_request_await_dma_fence in add_global_barrier to skip waits
on the same timeline and avoid GEM_BUG_ON.
* No need to explicitly assign a NULL pointer to engine in legacy mode.
* No need to move gen8_make_rpcs up.
* Factored out global barrier as prep patch.
* Allow to only CAP_SYS_ADMIN if !Gen11.
v11:
* Remove engine vfunc in favour of local helper. (Chris Wilson)
* Stop retiring requests before updates since it is not needed
(Chris Wilson)
* Implement direct CPU update path for idle contexts. (Chris Wilson)
* Left side dependency needs only be on the same context timeline.
(Chris Wilson)
* It is sufficient to order the timeline. (Chris Wilson)
* Reject !RCS configuration attempts with -ENODEV for now.
v12:
* Rebase for make_rpcs.
v13:
* Centralize SSEU normalization to make_rpcs.
* Type width checking (uAPI <-> implementation).
* Gen11 restrictions uAPI checks.
* Gen11 subslice count differences handling.
Chris Wilson:
* args->size handling fixes.
* Update context image from GGTT.
* Postpone context image update to pinning.
* Use i915_gem_active_raw instead of last_request_on_engine.
v14:
* Add activity tracker on intel_context to fix the lifetime issues
and simplify the code. (Chris Wilson)
v15:
* Fix context pin leak if no space in ring by simplifying the
context pinning sequence.
v16:
* Rebase for context get/set param locking changes.
* Just -ENODEV on !Gen11. (Joonas)
v17:
* Fix one Gen11 subslice enablement rule.
* Handle error from i915_sw_fence_await_sw_fence_gfp. (Chris Wilson)
v18:
* Update commit message. (Joonas)
* Restrict uAPI to VME use case. (Joonas)
v19:
* Rebase.
v20:
* Rebase for ce->active_tracker.
v21:
* Rebase for IS_GEN changes.
v22:
* Reserve uAPI for flags straight away. (Chris Wilson)
v23:
* Rebase for RUNTIME_INFO.
v24:
* Added some headline docs for the uapi usage. (Joonas/Chris)
v25:
* Renamed class/instance to engine_class/engine_instance to avoid clash
with C++ keyword. (Tony Ye)
v26:
* Rebased for runtime pm api changes.
v27:
* Rebased for intel_context_init.
* Wrap commit msg to 75.
v28:
(Chris Wilson)
* Use i915_gem_ggtt.
* Use i915_request_await_dma_fence to show a better example.
v29:
* i915_timeline_set_barrier can now fail. (Chris Wilson)
v30:
* Capture some acks.
v31:
* Drop the WARN_ON from use controllable paths. (Chris Wilson)
* Use overflows_type for all checks.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100899
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107634
Issue: https://github.com/intel/media-driver/issues/267
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Zhipeng Gong <zhipeng.gong@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tony Ye <tony.ye@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: Timo Aaltonen <timo.aaltonen@canonical.com>
Acked-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Stéphane Marchesin <marcheu@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190205095032.22673-4-tvrtko.ursulin@linux.intel.com
2019-02-05 17:50:31 +08:00
|
|
|
|
|
|
|
ret = user_to_context_sseu(i915, &user_sseu, &sseu);
|
|
|
|
if (ret)
|
2019-04-27 00:33:32 +08:00
|
|
|
goto out_ce;
|
drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only)
We want to allow userspace to reconfigure the subslice configuration on a
per context basis.
This is required for the functional requirement of shutting down non-VME
enabled sub-slices on Gen11 parts.
To do so, we expose a context parameter to allow adjustment of the RPCS
register stored within the context image (and currently not accessible via
LRI).
If the context is adjusted before first use or whilst idle, the adjustment
is for "free"; otherwise if the context is active we queue a request to do
so (using the kernel context), following all other activity by that
context, which is also marked as barrier for all following submission
against the same context.
Since the overhead of device re-configuration during context switching can
be significant, especially in multi-context workloads, we limit this new
uAPI to only support the Gen11 VME use case. In this use case either the
device is fully enabled, and exactly one slice and half of the subslices
are enabled.
Example usage:
struct drm_i915_gem_context_param_sseu sseu = { };
struct drm_i915_gem_context_param arg = {
.param = I915_CONTEXT_PARAM_SSEU,
.ctx_id = gem_context_create(fd),
.size = sizeof(sseu),
.value = to_user_pointer(&sseu)
};
/* Query device defaults. */
gem_context_get_param(fd, &arg);
/* Set VME configuration on a 1x6x8 part. */
sseu.slice_mask = 0x1;
sseu.subslice_mask = 0xe0;
gem_context_set_param(fd, &arg);
v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu()
(Lionel)
v3: Add ability to program this per engine (Chris)
v4: Move most get_sseu() into i915_gem_context.c (Lionel)
v5: Validate sseu configuration against the device's capabilities (Lionel)
v6: Change context powergating settings through MI_SDM on kernel context
(Chris)
v7: Synchronize the requests following a powergating setting change using
a global dependency (Chris)
Iterate timelines through dev_priv.gt.active_rings (Tvrtko)
Disable RPCS configuration setting for non capable users
(Lionel/Tvrtko)
v8: s/union intel_sseu/struct intel_sseu/ (Lionel)
s/dev_priv/i915/ (Tvrtko)
Change uapi class/instance fields to u16 (Tvrtko)
Bump mask fields to 64bits (Lionel)
Don't return EPERM when dynamic sseu is disabled (Tvrtko)
v9: Import context image into kernel context's ppgtt only when
reconfiguring powergated slice/subslices (Chris)
Use aliasing ppgtt when needed (Michel)
Tvrtko Ursulin:
v10:
* Update for upstream changes.
* Request submit needs a RPM reference.
* Reject on !FULL_PPGTT for simplicity.
* Pull out get/set param to helpers for readability and less indent.
* Use i915_request_await_dma_fence in add_global_barrier to skip waits
on the same timeline and avoid GEM_BUG_ON.
* No need to explicitly assign a NULL pointer to engine in legacy mode.
* No need to move gen8_make_rpcs up.
* Factored out global barrier as prep patch.
* Allow to only CAP_SYS_ADMIN if !Gen11.
v11:
* Remove engine vfunc in favour of local helper. (Chris Wilson)
* Stop retiring requests before updates since it is not needed
(Chris Wilson)
* Implement direct CPU update path for idle contexts. (Chris Wilson)
* Left side dependency needs only be on the same context timeline.
(Chris Wilson)
* It is sufficient to order the timeline. (Chris Wilson)
* Reject !RCS configuration attempts with -ENODEV for now.
v12:
* Rebase for make_rpcs.
v13:
* Centralize SSEU normalization to make_rpcs.
* Type width checking (uAPI <-> implementation).
* Gen11 restrictions uAPI checks.
* Gen11 subslice count differences handling.
Chris Wilson:
* args->size handling fixes.
* Update context image from GGTT.
* Postpone context image update to pinning.
* Use i915_gem_active_raw instead of last_request_on_engine.
v14:
* Add activity tracker on intel_context to fix the lifetime issues
and simplify the code. (Chris Wilson)
v15:
* Fix context pin leak if no space in ring by simplifying the
context pinning sequence.
v16:
* Rebase for context get/set param locking changes.
* Just -ENODEV on !Gen11. (Joonas)
v17:
* Fix one Gen11 subslice enablement rule.
* Handle error from i915_sw_fence_await_sw_fence_gfp. (Chris Wilson)
v18:
* Update commit message. (Joonas)
* Restrict uAPI to VME use case. (Joonas)
v19:
* Rebase.
v20:
* Rebase for ce->active_tracker.
v21:
* Rebase for IS_GEN changes.
v22:
* Reserve uAPI for flags straight away. (Chris Wilson)
v23:
* Rebase for RUNTIME_INFO.
v24:
* Added some headline docs for the uapi usage. (Joonas/Chris)
v25:
* Renamed class/instance to engine_class/engine_instance to avoid clash
with C++ keyword. (Tony Ye)
v26:
* Rebased for runtime pm api changes.
v27:
* Rebased for intel_context_init.
* Wrap commit msg to 75.
v28:
(Chris Wilson)
* Use i915_gem_ggtt.
* Use i915_request_await_dma_fence to show a better example.
v29:
* i915_timeline_set_barrier can now fail. (Chris Wilson)
v30:
* Capture some acks.
v31:
* Drop the WARN_ON from use controllable paths. (Chris Wilson)
* Use overflows_type for all checks.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100899
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107634
Issue: https://github.com/intel/media-driver/issues/267
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Zhipeng Gong <zhipeng.gong@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tony Ye <tony.ye@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: Timo Aaltonen <timo.aaltonen@canonical.com>
Acked-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Stéphane Marchesin <marcheu@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190205095032.22673-4-tvrtko.ursulin@linux.intel.com
2019-02-05 17:50:31 +08:00
|
|
|
|
2019-04-27 00:33:32 +08:00
|
|
|
ret = intel_context_reconfigure_sseu(ce, sseu);
|
drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only)
We want to allow userspace to reconfigure the subslice configuration on a
per context basis.
This is required for the functional requirement of shutting down non-VME
enabled sub-slices on Gen11 parts.
To do so, we expose a context parameter to allow adjustment of the RPCS
register stored within the context image (and currently not accessible via
LRI).
If the context is adjusted before first use or whilst idle, the adjustment
is for "free"; otherwise if the context is active we queue a request to do
so (using the kernel context), following all other activity by that
context, which is also marked as barrier for all following submission
against the same context.
Since the overhead of device re-configuration during context switching can
be significant, especially in multi-context workloads, we limit this new
uAPI to only support the Gen11 VME use case. In this use case either the
device is fully enabled, and exactly one slice and half of the subslices
are enabled.
Example usage:
struct drm_i915_gem_context_param_sseu sseu = { };
struct drm_i915_gem_context_param arg = {
.param = I915_CONTEXT_PARAM_SSEU,
.ctx_id = gem_context_create(fd),
.size = sizeof(sseu),
.value = to_user_pointer(&sseu)
};
/* Query device defaults. */
gem_context_get_param(fd, &arg);
/* Set VME configuration on a 1x6x8 part. */
sseu.slice_mask = 0x1;
sseu.subslice_mask = 0xe0;
gem_context_set_param(fd, &arg);
v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu()
(Lionel)
v3: Add ability to program this per engine (Chris)
v4: Move most get_sseu() into i915_gem_context.c (Lionel)
v5: Validate sseu configuration against the device's capabilities (Lionel)
v6: Change context powergating settings through MI_SDM on kernel context
(Chris)
v7: Synchronize the requests following a powergating setting change using
a global dependency (Chris)
Iterate timelines through dev_priv.gt.active_rings (Tvrtko)
Disable RPCS configuration setting for non capable users
(Lionel/Tvrtko)
v8: s/union intel_sseu/struct intel_sseu/ (Lionel)
s/dev_priv/i915/ (Tvrtko)
Change uapi class/instance fields to u16 (Tvrtko)
Bump mask fields to 64bits (Lionel)
Don't return EPERM when dynamic sseu is disabled (Tvrtko)
v9: Import context image into kernel context's ppgtt only when
reconfiguring powergated slice/subslices (Chris)
Use aliasing ppgtt when needed (Michel)
Tvrtko Ursulin:
v10:
* Update for upstream changes.
* Request submit needs a RPM reference.
* Reject on !FULL_PPGTT for simplicity.
* Pull out get/set param to helpers for readability and less indent.
* Use i915_request_await_dma_fence in add_global_barrier to skip waits
on the same timeline and avoid GEM_BUG_ON.
* No need to explicitly assign a NULL pointer to engine in legacy mode.
* No need to move gen8_make_rpcs up.
* Factored out global barrier as prep patch.
* Allow to only CAP_SYS_ADMIN if !Gen11.
v11:
* Remove engine vfunc in favour of local helper. (Chris Wilson)
* Stop retiring requests before updates since it is not needed
(Chris Wilson)
* Implement direct CPU update path for idle contexts. (Chris Wilson)
* Left side dependency needs only be on the same context timeline.
(Chris Wilson)
* It is sufficient to order the timeline. (Chris Wilson)
* Reject !RCS configuration attempts with -ENODEV for now.
v12:
* Rebase for make_rpcs.
v13:
* Centralize SSEU normalization to make_rpcs.
* Type width checking (uAPI <-> implementation).
* Gen11 restrictions uAPI checks.
* Gen11 subslice count differences handling.
Chris Wilson:
* args->size handling fixes.
* Update context image from GGTT.
* Postpone context image update to pinning.
* Use i915_gem_active_raw instead of last_request_on_engine.
v14:
* Add activity tracker on intel_context to fix the lifetime issues
and simplify the code. (Chris Wilson)
v15:
* Fix context pin leak if no space in ring by simplifying the
context pinning sequence.
v16:
* Rebase for context get/set param locking changes.
* Just -ENODEV on !Gen11. (Joonas)
v17:
* Fix one Gen11 subslice enablement rule.
* Handle error from i915_sw_fence_await_sw_fence_gfp. (Chris Wilson)
v18:
* Update commit message. (Joonas)
* Restrict uAPI to VME use case. (Joonas)
v19:
* Rebase.
v20:
* Rebase for ce->active_tracker.
v21:
* Rebase for IS_GEN changes.
v22:
* Reserve uAPI for flags straight away. (Chris Wilson)
v23:
* Rebase for RUNTIME_INFO.
v24:
* Added some headline docs for the uapi usage. (Joonas/Chris)
v25:
* Renamed class/instance to engine_class/engine_instance to avoid clash
with C++ keyword. (Tony Ye)
v26:
* Rebased for runtime pm api changes.
v27:
* Rebased for intel_context_init.
* Wrap commit msg to 75.
v28:
(Chris Wilson)
* Use i915_gem_ggtt.
* Use i915_request_await_dma_fence to show a better example.
v29:
* i915_timeline_set_barrier can now fail. (Chris Wilson)
v30:
* Capture some acks.
v31:
* Drop the WARN_ON from use controllable paths. (Chris Wilson)
* Use overflows_type for all checks.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100899
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107634
Issue: https://github.com/intel/media-driver/issues/267
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Zhipeng Gong <zhipeng.gong@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tony Ye <tony.ye@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: Timo Aaltonen <timo.aaltonen@canonical.com>
Acked-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Stéphane Marchesin <marcheu@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190205095032.22673-4-tvrtko.ursulin@linux.intel.com
2019-02-05 17:50:31 +08:00
|
|
|
if (ret)
|
2019-04-27 00:33:32 +08:00
|
|
|
goto out_ce;
|
drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only)
We want to allow userspace to reconfigure the subslice configuration on a
per context basis.
This is required for the functional requirement of shutting down non-VME
enabled sub-slices on Gen11 parts.
To do so, we expose a context parameter to allow adjustment of the RPCS
register stored within the context image (and currently not accessible via
LRI).
If the context is adjusted before first use or whilst idle, the adjustment
is for "free"; otherwise if the context is active we queue a request to do
so (using the kernel context), following all other activity by that
context, which is also marked as barrier for all following submission
against the same context.
Since the overhead of device re-configuration during context switching can
be significant, especially in multi-context workloads, we limit this new
uAPI to only support the Gen11 VME use case. In this use case either the
device is fully enabled, and exactly one slice and half of the subslices
are enabled.
Example usage:
struct drm_i915_gem_context_param_sseu sseu = { };
struct drm_i915_gem_context_param arg = {
.param = I915_CONTEXT_PARAM_SSEU,
.ctx_id = gem_context_create(fd),
.size = sizeof(sseu),
.value = to_user_pointer(&sseu)
};
/* Query device defaults. */
gem_context_get_param(fd, &arg);
/* Set VME configuration on a 1x6x8 part. */
sseu.slice_mask = 0x1;
sseu.subslice_mask = 0xe0;
gem_context_set_param(fd, &arg);
v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu()
(Lionel)
v3: Add ability to program this per engine (Chris)
v4: Move most get_sseu() into i915_gem_context.c (Lionel)
v5: Validate sseu configuration against the device's capabilities (Lionel)
v6: Change context powergating settings through MI_SDM on kernel context
(Chris)
v7: Synchronize the requests following a powergating setting change using
a global dependency (Chris)
Iterate timelines through dev_priv.gt.active_rings (Tvrtko)
Disable RPCS configuration setting for non capable users
(Lionel/Tvrtko)
v8: s/union intel_sseu/struct intel_sseu/ (Lionel)
s/dev_priv/i915/ (Tvrtko)
Change uapi class/instance fields to u16 (Tvrtko)
Bump mask fields to 64bits (Lionel)
Don't return EPERM when dynamic sseu is disabled (Tvrtko)
v9: Import context image into kernel context's ppgtt only when
reconfiguring powergated slice/subslices (Chris)
Use aliasing ppgtt when needed (Michel)
Tvrtko Ursulin:
v10:
* Update for upstream changes.
* Request submit needs a RPM reference.
* Reject on !FULL_PPGTT for simplicity.
* Pull out get/set param to helpers for readability and less indent.
* Use i915_request_await_dma_fence in add_global_barrier to skip waits
on the same timeline and avoid GEM_BUG_ON.
* No need to explicitly assign a NULL pointer to engine in legacy mode.
* No need to move gen8_make_rpcs up.
* Factored out global barrier as prep patch.
* Allow to only CAP_SYS_ADMIN if !Gen11.
v11:
* Remove engine vfunc in favour of local helper. (Chris Wilson)
* Stop retiring requests before updates since it is not needed
(Chris Wilson)
* Implement direct CPU update path for idle contexts. (Chris Wilson)
* Left side dependency needs only be on the same context timeline.
(Chris Wilson)
* It is sufficient to order the timeline. (Chris Wilson)
* Reject !RCS configuration attempts with -ENODEV for now.
v12:
* Rebase for make_rpcs.
v13:
* Centralize SSEU normalization to make_rpcs.
* Type width checking (uAPI <-> implementation).
* Gen11 restrictions uAPI checks.
* Gen11 subslice count differences handling.
Chris Wilson:
* args->size handling fixes.
* Update context image from GGTT.
* Postpone context image update to pinning.
* Use i915_gem_active_raw instead of last_request_on_engine.
v14:
* Add activity tracker on intel_context to fix the lifetime issues
and simplify the code. (Chris Wilson)
v15:
* Fix context pin leak if no space in ring by simplifying the
context pinning sequence.
v16:
* Rebase for context get/set param locking changes.
* Just -ENODEV on !Gen11. (Joonas)
v17:
* Fix one Gen11 subslice enablement rule.
* Handle error from i915_sw_fence_await_sw_fence_gfp. (Chris Wilson)
v18:
* Update commit message. (Joonas)
* Restrict uAPI to VME use case. (Joonas)
v19:
* Rebase.
v20:
* Rebase for ce->active_tracker.
v21:
* Rebase for IS_GEN changes.
v22:
* Reserve uAPI for flags straight away. (Chris Wilson)
v23:
* Rebase for RUNTIME_INFO.
v24:
* Added some headline docs for the uapi usage. (Joonas/Chris)
v25:
* Renamed class/instance to engine_class/engine_instance to avoid clash
with C++ keyword. (Tony Ye)
v26:
* Rebased for runtime pm api changes.
v27:
* Rebased for intel_context_init.
* Wrap commit msg to 75.
v28:
(Chris Wilson)
* Use i915_gem_ggtt.
* Use i915_request_await_dma_fence to show a better example.
v29:
* i915_timeline_set_barrier can now fail. (Chris Wilson)
v30:
* Capture some acks.
v31:
* Drop the WARN_ON from use controllable paths. (Chris Wilson)
* Use overflows_type for all checks.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100899
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107634
Issue: https://github.com/intel/media-driver/issues/267
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Zhipeng Gong <zhipeng.gong@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tony Ye <tony.ye@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: Timo Aaltonen <timo.aaltonen@canonical.com>
Acked-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Stéphane Marchesin <marcheu@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190205095032.22673-4-tvrtko.ursulin@linux.intel.com
2019-02-05 17:50:31 +08:00
|
|
|
|
|
|
|
args->size = sizeof(user_sseu);
|
|
|
|
|
2019-04-27 00:33:32 +08:00
|
|
|
out_ce:
|
|
|
|
intel_context_put(ce);
|
|
|
|
return ret;
|
drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only)
We want to allow userspace to reconfigure the subslice configuration on a
per context basis.
This is required for the functional requirement of shutting down non-VME
enabled sub-slices on Gen11 parts.
To do so, we expose a context parameter to allow adjustment of the RPCS
register stored within the context image (and currently not accessible via
LRI).
If the context is adjusted before first use or whilst idle, the adjustment
is for "free"; otherwise if the context is active we queue a request to do
so (using the kernel context), following all other activity by that
context, which is also marked as barrier for all following submission
against the same context.
Since the overhead of device re-configuration during context switching can
be significant, especially in multi-context workloads, we limit this new
uAPI to only support the Gen11 VME use case. In this use case either the
device is fully enabled, and exactly one slice and half of the subslices
are enabled.
Example usage:
struct drm_i915_gem_context_param_sseu sseu = { };
struct drm_i915_gem_context_param arg = {
.param = I915_CONTEXT_PARAM_SSEU,
.ctx_id = gem_context_create(fd),
.size = sizeof(sseu),
.value = to_user_pointer(&sseu)
};
/* Query device defaults. */
gem_context_get_param(fd, &arg);
/* Set VME configuration on a 1x6x8 part. */
sseu.slice_mask = 0x1;
sseu.subslice_mask = 0xe0;
gem_context_set_param(fd, &arg);
v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu()
(Lionel)
v3: Add ability to program this per engine (Chris)
v4: Move most get_sseu() into i915_gem_context.c (Lionel)
v5: Validate sseu configuration against the device's capabilities (Lionel)
v6: Change context powergating settings through MI_SDM on kernel context
(Chris)
v7: Synchronize the requests following a powergating setting change using
a global dependency (Chris)
Iterate timelines through dev_priv.gt.active_rings (Tvrtko)
Disable RPCS configuration setting for non capable users
(Lionel/Tvrtko)
v8: s/union intel_sseu/struct intel_sseu/ (Lionel)
s/dev_priv/i915/ (Tvrtko)
Change uapi class/instance fields to u16 (Tvrtko)
Bump mask fields to 64bits (Lionel)
Don't return EPERM when dynamic sseu is disabled (Tvrtko)
v9: Import context image into kernel context's ppgtt only when
reconfiguring powergated slice/subslices (Chris)
Use aliasing ppgtt when needed (Michel)
Tvrtko Ursulin:
v10:
* Update for upstream changes.
* Request submit needs a RPM reference.
* Reject on !FULL_PPGTT for simplicity.
* Pull out get/set param to helpers for readability and less indent.
* Use i915_request_await_dma_fence in add_global_barrier to skip waits
on the same timeline and avoid GEM_BUG_ON.
* No need to explicitly assign a NULL pointer to engine in legacy mode.
* No need to move gen8_make_rpcs up.
* Factored out global barrier as prep patch.
* Allow to only CAP_SYS_ADMIN if !Gen11.
v11:
* Remove engine vfunc in favour of local helper. (Chris Wilson)
* Stop retiring requests before updates since it is not needed
(Chris Wilson)
* Implement direct CPU update path for idle contexts. (Chris Wilson)
* Left side dependency needs only be on the same context timeline.
(Chris Wilson)
* It is sufficient to order the timeline. (Chris Wilson)
* Reject !RCS configuration attempts with -ENODEV for now.
v12:
* Rebase for make_rpcs.
v13:
* Centralize SSEU normalization to make_rpcs.
* Type width checking (uAPI <-> implementation).
* Gen11 restrictions uAPI checks.
* Gen11 subslice count differences handling.
Chris Wilson:
* args->size handling fixes.
* Update context image from GGTT.
* Postpone context image update to pinning.
* Use i915_gem_active_raw instead of last_request_on_engine.
v14:
* Add activity tracker on intel_context to fix the lifetime issues
and simplify the code. (Chris Wilson)
v15:
* Fix context pin leak if no space in ring by simplifying the
context pinning sequence.
v16:
* Rebase for context get/set param locking changes.
* Just -ENODEV on !Gen11. (Joonas)
v17:
* Fix one Gen11 subslice enablement rule.
* Handle error from i915_sw_fence_await_sw_fence_gfp. (Chris Wilson)
v18:
* Update commit message. (Joonas)
* Restrict uAPI to VME use case. (Joonas)
v19:
* Rebase.
v20:
* Rebase for ce->active_tracker.
v21:
* Rebase for IS_GEN changes.
v22:
* Reserve uAPI for flags straight away. (Chris Wilson)
v23:
* Rebase for RUNTIME_INFO.
v24:
* Added some headline docs for the uapi usage. (Joonas/Chris)
v25:
* Renamed class/instance to engine_class/engine_instance to avoid clash
with C++ keyword. (Tony Ye)
v26:
* Rebased for runtime pm api changes.
v27:
* Rebased for intel_context_init.
* Wrap commit msg to 75.
v28:
(Chris Wilson)
* Use i915_gem_ggtt.
* Use i915_request_await_dma_fence to show a better example.
v29:
* i915_timeline_set_barrier can now fail. (Chris Wilson)
v30:
* Capture some acks.
v31:
* Drop the WARN_ON from use controllable paths. (Chris Wilson)
* Use overflows_type for all checks.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100899
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107634
Issue: https://github.com/intel/media-driver/issues/267
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Zhipeng Gong <zhipeng.gong@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tony Ye <tony.ye@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: Timo Aaltonen <timo.aaltonen@canonical.com>
Acked-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Stéphane Marchesin <marcheu@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190205095032.22673-4-tvrtko.ursulin@linux.intel.com
2019-02-05 17:50:31 +08:00
|
|
|
}
|
|
|
|
|
drm/i915: Allow a context to define its set of engines
Over the last few years, we have debated how to extend the user API to
support an increase in the number of engines, that may be sparse and
even be heterogeneous within a class (not all video decoders created
equal). We settled on using (class, instance) tuples to identify a
specific engine, with an API for the user to construct a map of engines
to capabilities. Into this picture, we then add a challenge of virtual
engines; one user engine that maps behind the scenes to any number of
physical engines. To keep it general, we want the user to have full
control over that mapping. To that end, we allow the user to constrain a
context to define the set of engines that it can access, order fully
controlled by the user via (class, instance). With such precise control
in context setup, we can continue to use the existing execbuf uABI of
specifying a single index; only now it doesn't automagically map onto
the engines, it uses the user defined engine map from the context.
v2: Fixup freeing of local on success of get_engines()
v3: Allow empty engines[]
v4: s/nengine/num_engines/
v5: Replace 64 limit on num_engines with a note that execbuf is
currently limited to only using the first 64 engines.
v6: Actually use the engines_mutex to guard the ctx->engines.
Testcase: igt/gem_ctx_engines
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190521211134.16117-2-chris@chris-wilson.co.uk
2019-05-22 05:11:26 +08:00
|
|
|
struct set_engines {
|
|
|
|
struct i915_gem_context *ctx;
|
|
|
|
struct i915_gem_engines *engines;
|
|
|
|
};
|
|
|
|
|
drm/i915: Load balancing across a virtual engine
Having allowed the user to define a set of engines that they will want
to only use, we go one step further and allow them to bind those engines
into a single virtual instance. Submitting a batch to the virtual engine
will then forward it to any one of the set in a manner as best to
distribute load. The virtual engine has a single timeline across all
engines (it operates as a single queue), so it is not able to concurrently
run batches across multiple engines by itself; that is left up to the user
to submit multiple concurrent batches to multiple queues. Multiple users
will be load balanced across the system.
The mechanism used for load balancing in this patch is a late greedy
balancer. When a request is ready for execution, it is added to each
engine's queue, and when an engine is ready for its next request it
claims it from the virtual engine. The first engine to do so, wins, i.e.
the request is executed at the earliest opportunity (idle moment) in the
system.
As not all HW is created equal, the user is still able to skip the
virtual engine and execute the batch on a specific engine, all within the
same queue. It will then be executed in order on the correct engine,
with execution on other virtual engines being moved away due to the load
detection.
A couple of areas for potential improvement left!
- The virtual engine always take priority over equal-priority tasks.
Mostly broken up by applying FQ_CODEL rules for prioritising new clients,
and hopefully the virtual and real engines are not then congested (i.e.
all work is via virtual engines, or all work is to the real engine).
- We require the breadcrumb irq around every virtual engine request. For
normal engines, we eliminate the need for the slow round trip via
interrupt by using the submit fence and queueing in order. For virtual
engines, we have to allow any job to transfer to a new ring, and cannot
coalesce the submissions, so require the completion fence instead,
forcing the persistent use of interrupts.
- We only drip feed single requests through each virtual engine and onto
the physical engines, even if there was enough work to fill all ELSP,
leaving small stalls with an idle CS event at the end of every request.
Could we be greedy and fill both slots? Being lazy is virtuous for load
distribution on less-than-full workloads though.
Other areas of improvement are more general, such as reducing lock
contention, reducing dispatch overhead, looking at direct submission
rather than bouncing around tasklets etc.
sseu: Lift the restriction to allow sseu to be reconfigured on virtual
engines composed of RENDER_CLASS (rcs).
v2: macroize check_user_mbz()
v3: Cancel virtual engines on wedging
v4: Commence commenting
v5: Replace 64b sibling_mask with a list of class:instance
v6: Drop the one-element array in the uabi
v7: Assert it is an virtual engine in to_virtual_engine()
v8: Skip over holes in [class][inst] so we can selftest with (vcs0, vcs2)
Link: https://github.com/intel/media-driver/pull/283
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190521211134.16117-6-chris@chris-wilson.co.uk
2019-05-22 05:11:30 +08:00
|
|
|
static int
|
|
|
|
set_engines__load_balance(struct i915_user_extension __user *base, void *data)
|
|
|
|
{
|
|
|
|
struct i915_context_engines_load_balance __user *ext =
|
|
|
|
container_of_user(base, typeof(*ext), base);
|
|
|
|
const struct set_engines *set = data;
|
|
|
|
struct intel_engine_cs *stack[16];
|
|
|
|
struct intel_engine_cs **siblings;
|
|
|
|
struct intel_context *ce;
|
|
|
|
u16 num_siblings, idx;
|
|
|
|
unsigned int n;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
if (!HAS_EXECLISTS(set->ctx->i915))
|
|
|
|
return -ENODEV;
|
|
|
|
|
|
|
|
if (USES_GUC_SUBMISSION(set->ctx->i915))
|
|
|
|
return -ENODEV; /* not implement yet */
|
|
|
|
|
|
|
|
if (get_user(idx, &ext->engine_index))
|
|
|
|
return -EFAULT;
|
|
|
|
|
|
|
|
if (idx >= set->engines->num_engines) {
|
|
|
|
DRM_DEBUG("Invalid placement value, %d >= %d\n",
|
|
|
|
idx, set->engines->num_engines);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
idx = array_index_nospec(idx, set->engines->num_engines);
|
|
|
|
if (set->engines->engines[idx]) {
|
|
|
|
DRM_DEBUG("Invalid placement[%d], already occupied\n", idx);
|
|
|
|
return -EEXIST;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (get_user(num_siblings, &ext->num_siblings))
|
|
|
|
return -EFAULT;
|
|
|
|
|
|
|
|
err = check_user_mbz(&ext->flags);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
|
|
|
err = check_user_mbz(&ext->mbz64);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
|
|
|
siblings = stack;
|
|
|
|
if (num_siblings > ARRAY_SIZE(stack)) {
|
|
|
|
siblings = kmalloc_array(num_siblings,
|
|
|
|
sizeof(*siblings),
|
|
|
|
GFP_KERNEL);
|
|
|
|
if (!siblings)
|
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (n = 0; n < num_siblings; n++) {
|
|
|
|
struct i915_engine_class_instance ci;
|
|
|
|
|
|
|
|
if (copy_from_user(&ci, &ext->engines[n], sizeof(ci))) {
|
|
|
|
err = -EFAULT;
|
|
|
|
goto out_siblings;
|
|
|
|
}
|
|
|
|
|
|
|
|
siblings[n] = intel_engine_lookup_user(set->ctx->i915,
|
|
|
|
ci.engine_class,
|
|
|
|
ci.engine_instance);
|
|
|
|
if (!siblings[n]) {
|
|
|
|
DRM_DEBUG("Invalid sibling[%d]: { class:%d, inst:%d }\n",
|
|
|
|
n, ci.engine_class, ci.engine_instance);
|
|
|
|
err = -EINVAL;
|
|
|
|
goto out_siblings;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
ce = intel_execlists_create_virtual(set->ctx, siblings, n);
|
|
|
|
if (IS_ERR(ce)) {
|
|
|
|
err = PTR_ERR(ce);
|
|
|
|
goto out_siblings;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (cmpxchg(&set->engines->engines[idx], NULL, ce)) {
|
|
|
|
intel_context_put(ce);
|
|
|
|
err = -EEXIST;
|
|
|
|
goto out_siblings;
|
|
|
|
}
|
|
|
|
|
|
|
|
out_siblings:
|
|
|
|
if (siblings != stack)
|
|
|
|
kfree(siblings);
|
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2019-05-22 05:11:33 +08:00
|
|
|
static int
|
|
|
|
set_engines__bond(struct i915_user_extension __user *base, void *data)
|
|
|
|
{
|
|
|
|
struct i915_context_engines_bond __user *ext =
|
|
|
|
container_of_user(base, typeof(*ext), base);
|
|
|
|
const struct set_engines *set = data;
|
|
|
|
struct i915_engine_class_instance ci;
|
|
|
|
struct intel_engine_cs *virtual;
|
|
|
|
struct intel_engine_cs *master;
|
|
|
|
u16 idx, num_bonds;
|
|
|
|
int err, n;
|
|
|
|
|
|
|
|
if (get_user(idx, &ext->virtual_index))
|
|
|
|
return -EFAULT;
|
|
|
|
|
|
|
|
if (idx >= set->engines->num_engines) {
|
|
|
|
DRM_DEBUG("Invalid index for virtual engine: %d >= %d\n",
|
|
|
|
idx, set->engines->num_engines);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
idx = array_index_nospec(idx, set->engines->num_engines);
|
|
|
|
if (!set->engines->engines[idx]) {
|
|
|
|
DRM_DEBUG("Invalid engine at %d\n", idx);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
virtual = set->engines->engines[idx]->engine;
|
|
|
|
|
|
|
|
err = check_user_mbz(&ext->flags);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
|
|
|
for (n = 0; n < ARRAY_SIZE(ext->mbz64); n++) {
|
|
|
|
err = check_user_mbz(&ext->mbz64[n]);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (copy_from_user(&ci, &ext->master, sizeof(ci)))
|
|
|
|
return -EFAULT;
|
|
|
|
|
|
|
|
master = intel_engine_lookup_user(set->ctx->i915,
|
|
|
|
ci.engine_class, ci.engine_instance);
|
|
|
|
if (!master) {
|
|
|
|
DRM_DEBUG("Unrecognised master engine: { class:%u, instance:%u }\n",
|
|
|
|
ci.engine_class, ci.engine_instance);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (get_user(num_bonds, &ext->num_bonds))
|
|
|
|
return -EFAULT;
|
|
|
|
|
|
|
|
for (n = 0; n < num_bonds; n++) {
|
|
|
|
struct intel_engine_cs *bond;
|
|
|
|
|
|
|
|
if (copy_from_user(&ci, &ext->engines[n], sizeof(ci)))
|
|
|
|
return -EFAULT;
|
|
|
|
|
|
|
|
bond = intel_engine_lookup_user(set->ctx->i915,
|
|
|
|
ci.engine_class,
|
|
|
|
ci.engine_instance);
|
|
|
|
if (!bond) {
|
|
|
|
DRM_DEBUG("Unrecognised engine[%d] for bonding: { class:%d, instance: %d }\n",
|
|
|
|
n, ci.engine_class, ci.engine_instance);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* A non-virtual engine has no siblings to choose between; and
|
|
|
|
* a submit fence will always be directed to the one engine.
|
|
|
|
*/
|
|
|
|
if (intel_engine_is_virtual(virtual)) {
|
|
|
|
err = intel_virtual_engine_attach_bond(virtual,
|
|
|
|
master,
|
|
|
|
bond);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
drm/i915: Allow a context to define its set of engines
Over the last few years, we have debated how to extend the user API to
support an increase in the number of engines, that may be sparse and
even be heterogeneous within a class (not all video decoders created
equal). We settled on using (class, instance) tuples to identify a
specific engine, with an API for the user to construct a map of engines
to capabilities. Into this picture, we then add a challenge of virtual
engines; one user engine that maps behind the scenes to any number of
physical engines. To keep it general, we want the user to have full
control over that mapping. To that end, we allow the user to constrain a
context to define the set of engines that it can access, order fully
controlled by the user via (class, instance). With such precise control
in context setup, we can continue to use the existing execbuf uABI of
specifying a single index; only now it doesn't automagically map onto
the engines, it uses the user defined engine map from the context.
v2: Fixup freeing of local on success of get_engines()
v3: Allow empty engines[]
v4: s/nengine/num_engines/
v5: Replace 64 limit on num_engines with a note that execbuf is
currently limited to only using the first 64 engines.
v6: Actually use the engines_mutex to guard the ctx->engines.
Testcase: igt/gem_ctx_engines
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190521211134.16117-2-chris@chris-wilson.co.uk
2019-05-22 05:11:26 +08:00
|
|
|
static const i915_user_extension_fn set_engines__extensions[] = {
|
drm/i915: Load balancing across a virtual engine
Having allowed the user to define a set of engines that they will want
to only use, we go one step further and allow them to bind those engines
into a single virtual instance. Submitting a batch to the virtual engine
will then forward it to any one of the set in a manner as best to
distribute load. The virtual engine has a single timeline across all
engines (it operates as a single queue), so it is not able to concurrently
run batches across multiple engines by itself; that is left up to the user
to submit multiple concurrent batches to multiple queues. Multiple users
will be load balanced across the system.
The mechanism used for load balancing in this patch is a late greedy
balancer. When a request is ready for execution, it is added to each
engine's queue, and when an engine is ready for its next request it
claims it from the virtual engine. The first engine to do so, wins, i.e.
the request is executed at the earliest opportunity (idle moment) in the
system.
As not all HW is created equal, the user is still able to skip the
virtual engine and execute the batch on a specific engine, all within the
same queue. It will then be executed in order on the correct engine,
with execution on other virtual engines being moved away due to the load
detection.
A couple of areas for potential improvement left!
- The virtual engine always take priority over equal-priority tasks.
Mostly broken up by applying FQ_CODEL rules for prioritising new clients,
and hopefully the virtual and real engines are not then congested (i.e.
all work is via virtual engines, or all work is to the real engine).
- We require the breadcrumb irq around every virtual engine request. For
normal engines, we eliminate the need for the slow round trip via
interrupt by using the submit fence and queueing in order. For virtual
engines, we have to allow any job to transfer to a new ring, and cannot
coalesce the submissions, so require the completion fence instead,
forcing the persistent use of interrupts.
- We only drip feed single requests through each virtual engine and onto
the physical engines, even if there was enough work to fill all ELSP,
leaving small stalls with an idle CS event at the end of every request.
Could we be greedy and fill both slots? Being lazy is virtuous for load
distribution on less-than-full workloads though.
Other areas of improvement are more general, such as reducing lock
contention, reducing dispatch overhead, looking at direct submission
rather than bouncing around tasklets etc.
sseu: Lift the restriction to allow sseu to be reconfigured on virtual
engines composed of RENDER_CLASS (rcs).
v2: macroize check_user_mbz()
v3: Cancel virtual engines on wedging
v4: Commence commenting
v5: Replace 64b sibling_mask with a list of class:instance
v6: Drop the one-element array in the uabi
v7: Assert it is an virtual engine in to_virtual_engine()
v8: Skip over holes in [class][inst] so we can selftest with (vcs0, vcs2)
Link: https://github.com/intel/media-driver/pull/283
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190521211134.16117-6-chris@chris-wilson.co.uk
2019-05-22 05:11:30 +08:00
|
|
|
[I915_CONTEXT_ENGINES_EXT_LOAD_BALANCE] = set_engines__load_balance,
|
2019-05-22 05:11:33 +08:00
|
|
|
[I915_CONTEXT_ENGINES_EXT_BOND] = set_engines__bond,
|
drm/i915: Allow a context to define its set of engines
Over the last few years, we have debated how to extend the user API to
support an increase in the number of engines, that may be sparse and
even be heterogeneous within a class (not all video decoders created
equal). We settled on using (class, instance) tuples to identify a
specific engine, with an API for the user to construct a map of engines
to capabilities. Into this picture, we then add a challenge of virtual
engines; one user engine that maps behind the scenes to any number of
physical engines. To keep it general, we want the user to have full
control over that mapping. To that end, we allow the user to constrain a
context to define the set of engines that it can access, order fully
controlled by the user via (class, instance). With such precise control
in context setup, we can continue to use the existing execbuf uABI of
specifying a single index; only now it doesn't automagically map onto
the engines, it uses the user defined engine map from the context.
v2: Fixup freeing of local on success of get_engines()
v3: Allow empty engines[]
v4: s/nengine/num_engines/
v5: Replace 64 limit on num_engines with a note that execbuf is
currently limited to only using the first 64 engines.
v6: Actually use the engines_mutex to guard the ctx->engines.
Testcase: igt/gem_ctx_engines
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190521211134.16117-2-chris@chris-wilson.co.uk
2019-05-22 05:11:26 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
static int
|
|
|
|
set_engines(struct i915_gem_context *ctx,
|
|
|
|
const struct drm_i915_gem_context_param *args)
|
|
|
|
{
|
|
|
|
struct i915_context_param_engines __user *user =
|
|
|
|
u64_to_user_ptr(args->value);
|
|
|
|
struct set_engines set = { .ctx = ctx };
|
|
|
|
unsigned int num_engines, n;
|
|
|
|
u64 extensions;
|
|
|
|
int err;
|
|
|
|
|
|
|
|
if (!args->size) { /* switch back to legacy user_ring_map */
|
|
|
|
if (!i915_gem_context_user_engines(ctx))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
set.engines = default_engines(ctx);
|
|
|
|
if (IS_ERR(set.engines))
|
|
|
|
return PTR_ERR(set.engines);
|
|
|
|
|
|
|
|
goto replace;
|
|
|
|
}
|
|
|
|
|
|
|
|
BUILD_BUG_ON(!IS_ALIGNED(sizeof(*user), sizeof(*user->engines)));
|
|
|
|
if (args->size < sizeof(*user) ||
|
|
|
|
!IS_ALIGNED(args->size, sizeof(*user->engines))) {
|
|
|
|
DRM_DEBUG("Invalid size for engine array: %d\n",
|
|
|
|
args->size);
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Note that I915_EXEC_RING_MASK limits execbuf to only using the
|
|
|
|
* first 64 engines defined here.
|
|
|
|
*/
|
|
|
|
num_engines = (args->size - sizeof(*user)) / sizeof(*user->engines);
|
|
|
|
|
|
|
|
set.engines = kmalloc(struct_size(set.engines, engines, num_engines),
|
|
|
|
GFP_KERNEL);
|
|
|
|
if (!set.engines)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
2019-06-06 19:23:20 +08:00
|
|
|
init_rcu_head(&set.engines->rcu);
|
drm/i915: Allow a context to define its set of engines
Over the last few years, we have debated how to extend the user API to
support an increase in the number of engines, that may be sparse and
even be heterogeneous within a class (not all video decoders created
equal). We settled on using (class, instance) tuples to identify a
specific engine, with an API for the user to construct a map of engines
to capabilities. Into this picture, we then add a challenge of virtual
engines; one user engine that maps behind the scenes to any number of
physical engines. To keep it general, we want the user to have full
control over that mapping. To that end, we allow the user to constrain a
context to define the set of engines that it can access, order fully
controlled by the user via (class, instance). With such precise control
in context setup, we can continue to use the existing execbuf uABI of
specifying a single index; only now it doesn't automagically map onto
the engines, it uses the user defined engine map from the context.
v2: Fixup freeing of local on success of get_engines()
v3: Allow empty engines[]
v4: s/nengine/num_engines/
v5: Replace 64 limit on num_engines with a note that execbuf is
currently limited to only using the first 64 engines.
v6: Actually use the engines_mutex to guard the ctx->engines.
Testcase: igt/gem_ctx_engines
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190521211134.16117-2-chris@chris-wilson.co.uk
2019-05-22 05:11:26 +08:00
|
|
|
for (n = 0; n < num_engines; n++) {
|
|
|
|
struct i915_engine_class_instance ci;
|
|
|
|
struct intel_engine_cs *engine;
|
2019-08-10 02:25:17 +08:00
|
|
|
struct intel_context *ce;
|
drm/i915: Allow a context to define its set of engines
Over the last few years, we have debated how to extend the user API to
support an increase in the number of engines, that may be sparse and
even be heterogeneous within a class (not all video decoders created
equal). We settled on using (class, instance) tuples to identify a
specific engine, with an API for the user to construct a map of engines
to capabilities. Into this picture, we then add a challenge of virtual
engines; one user engine that maps behind the scenes to any number of
physical engines. To keep it general, we want the user to have full
control over that mapping. To that end, we allow the user to constrain a
context to define the set of engines that it can access, order fully
controlled by the user via (class, instance). With such precise control
in context setup, we can continue to use the existing execbuf uABI of
specifying a single index; only now it doesn't automagically map onto
the engines, it uses the user defined engine map from the context.
v2: Fixup freeing of local on success of get_engines()
v3: Allow empty engines[]
v4: s/nengine/num_engines/
v5: Replace 64 limit on num_engines with a note that execbuf is
currently limited to only using the first 64 engines.
v6: Actually use the engines_mutex to guard the ctx->engines.
Testcase: igt/gem_ctx_engines
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190521211134.16117-2-chris@chris-wilson.co.uk
2019-05-22 05:11:26 +08:00
|
|
|
|
|
|
|
if (copy_from_user(&ci, &user->engines[n], sizeof(ci))) {
|
|
|
|
__free_engines(set.engines, n);
|
|
|
|
return -EFAULT;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (ci.engine_class == (u16)I915_ENGINE_CLASS_INVALID &&
|
|
|
|
ci.engine_instance == (u16)I915_ENGINE_CLASS_INVALID_NONE) {
|
|
|
|
set.engines->engines[n] = NULL;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
engine = intel_engine_lookup_user(ctx->i915,
|
|
|
|
ci.engine_class,
|
|
|
|
ci.engine_instance);
|
|
|
|
if (!engine) {
|
|
|
|
DRM_DEBUG("Invalid engine[%d]: { class:%d, instance:%d }\n",
|
|
|
|
n, ci.engine_class, ci.engine_instance);
|
|
|
|
__free_engines(set.engines, n);
|
|
|
|
return -ENOENT;
|
|
|
|
}
|
|
|
|
|
2019-08-10 02:25:17 +08:00
|
|
|
ce = intel_context_create(ctx, engine);
|
|
|
|
if (IS_ERR(ce)) {
|
drm/i915: Allow a context to define its set of engines
Over the last few years, we have debated how to extend the user API to
support an increase in the number of engines, that may be sparse and
even be heterogeneous within a class (not all video decoders created
equal). We settled on using (class, instance) tuples to identify a
specific engine, with an API for the user to construct a map of engines
to capabilities. Into this picture, we then add a challenge of virtual
engines; one user engine that maps behind the scenes to any number of
physical engines. To keep it general, we want the user to have full
control over that mapping. To that end, we allow the user to constrain a
context to define the set of engines that it can access, order fully
controlled by the user via (class, instance). With such precise control
in context setup, we can continue to use the existing execbuf uABI of
specifying a single index; only now it doesn't automagically map onto
the engines, it uses the user defined engine map from the context.
v2: Fixup freeing of local on success of get_engines()
v3: Allow empty engines[]
v4: s/nengine/num_engines/
v5: Replace 64 limit on num_engines with a note that execbuf is
currently limited to only using the first 64 engines.
v6: Actually use the engines_mutex to guard the ctx->engines.
Testcase: igt/gem_ctx_engines
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190521211134.16117-2-chris@chris-wilson.co.uk
2019-05-22 05:11:26 +08:00
|
|
|
__free_engines(set.engines, n);
|
2019-08-10 02:25:17 +08:00
|
|
|
return PTR_ERR(ce);
|
drm/i915: Allow a context to define its set of engines
Over the last few years, we have debated how to extend the user API to
support an increase in the number of engines, that may be sparse and
even be heterogeneous within a class (not all video decoders created
equal). We settled on using (class, instance) tuples to identify a
specific engine, with an API for the user to construct a map of engines
to capabilities. Into this picture, we then add a challenge of virtual
engines; one user engine that maps behind the scenes to any number of
physical engines. To keep it general, we want the user to have full
control over that mapping. To that end, we allow the user to constrain a
context to define the set of engines that it can access, order fully
controlled by the user via (class, instance). With such precise control
in context setup, we can continue to use the existing execbuf uABI of
specifying a single index; only now it doesn't automagically map onto
the engines, it uses the user defined engine map from the context.
v2: Fixup freeing of local on success of get_engines()
v3: Allow empty engines[]
v4: s/nengine/num_engines/
v5: Replace 64 limit on num_engines with a note that execbuf is
currently limited to only using the first 64 engines.
v6: Actually use the engines_mutex to guard the ctx->engines.
Testcase: igt/gem_ctx_engines
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190521211134.16117-2-chris@chris-wilson.co.uk
2019-05-22 05:11:26 +08:00
|
|
|
}
|
2019-08-10 02:25:17 +08:00
|
|
|
|
|
|
|
set.engines->engines[n] = ce;
|
drm/i915: Allow a context to define its set of engines
Over the last few years, we have debated how to extend the user API to
support an increase in the number of engines, that may be sparse and
even be heterogeneous within a class (not all video decoders created
equal). We settled on using (class, instance) tuples to identify a
specific engine, with an API for the user to construct a map of engines
to capabilities. Into this picture, we then add a challenge of virtual
engines; one user engine that maps behind the scenes to any number of
physical engines. To keep it general, we want the user to have full
control over that mapping. To that end, we allow the user to constrain a
context to define the set of engines that it can access, order fully
controlled by the user via (class, instance). With such precise control
in context setup, we can continue to use the existing execbuf uABI of
specifying a single index; only now it doesn't automagically map onto
the engines, it uses the user defined engine map from the context.
v2: Fixup freeing of local on success of get_engines()
v3: Allow empty engines[]
v4: s/nengine/num_engines/
v5: Replace 64 limit on num_engines with a note that execbuf is
currently limited to only using the first 64 engines.
v6: Actually use the engines_mutex to guard the ctx->engines.
Testcase: igt/gem_ctx_engines
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190521211134.16117-2-chris@chris-wilson.co.uk
2019-05-22 05:11:26 +08:00
|
|
|
}
|
|
|
|
set.engines->num_engines = num_engines;
|
|
|
|
|
|
|
|
err = -EFAULT;
|
|
|
|
if (!get_user(extensions, &user->extensions))
|
|
|
|
err = i915_user_extensions(u64_to_user_ptr(extensions),
|
|
|
|
set_engines__extensions,
|
|
|
|
ARRAY_SIZE(set_engines__extensions),
|
|
|
|
&set);
|
|
|
|
if (err) {
|
|
|
|
free_engines(set.engines);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
replace:
|
|
|
|
mutex_lock(&ctx->engines_mutex);
|
|
|
|
if (args->size)
|
|
|
|
i915_gem_context_set_user_engines(ctx);
|
|
|
|
else
|
|
|
|
i915_gem_context_clear_user_engines(ctx);
|
2019-09-24 06:22:15 +08:00
|
|
|
set.engines = rcu_replace_pointer(ctx->engines, set.engines, 1);
|
drm/i915: Allow a context to define its set of engines
Over the last few years, we have debated how to extend the user API to
support an increase in the number of engines, that may be sparse and
even be heterogeneous within a class (not all video decoders created
equal). We settled on using (class, instance) tuples to identify a
specific engine, with an API for the user to construct a map of engines
to capabilities. Into this picture, we then add a challenge of virtual
engines; one user engine that maps behind the scenes to any number of
physical engines. To keep it general, we want the user to have full
control over that mapping. To that end, we allow the user to constrain a
context to define the set of engines that it can access, order fully
controlled by the user via (class, instance). With such precise control
in context setup, we can continue to use the existing execbuf uABI of
specifying a single index; only now it doesn't automagically map onto
the engines, it uses the user defined engine map from the context.
v2: Fixup freeing of local on success of get_engines()
v3: Allow empty engines[]
v4: s/nengine/num_engines/
v5: Replace 64 limit on num_engines with a note that execbuf is
currently limited to only using the first 64 engines.
v6: Actually use the engines_mutex to guard the ctx->engines.
Testcase: igt/gem_ctx_engines
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190521211134.16117-2-chris@chris-wilson.co.uk
2019-05-22 05:11:26 +08:00
|
|
|
mutex_unlock(&ctx->engines_mutex);
|
|
|
|
|
2019-06-06 19:23:20 +08:00
|
|
|
call_rcu(&set.engines->rcu, free_engines_rcu);
|
drm/i915: Allow a context to define its set of engines
Over the last few years, we have debated how to extend the user API to
support an increase in the number of engines, that may be sparse and
even be heterogeneous within a class (not all video decoders created
equal). We settled on using (class, instance) tuples to identify a
specific engine, with an API for the user to construct a map of engines
to capabilities. Into this picture, we then add a challenge of virtual
engines; one user engine that maps behind the scenes to any number of
physical engines. To keep it general, we want the user to have full
control over that mapping. To that end, we allow the user to constrain a
context to define the set of engines that it can access, order fully
controlled by the user via (class, instance). With such precise control
in context setup, we can continue to use the existing execbuf uABI of
specifying a single index; only now it doesn't automagically map onto
the engines, it uses the user defined engine map from the context.
v2: Fixup freeing of local on success of get_engines()
v3: Allow empty engines[]
v4: s/nengine/num_engines/
v5: Replace 64 limit on num_engines with a note that execbuf is
currently limited to only using the first 64 engines.
v6: Actually use the engines_mutex to guard the ctx->engines.
Testcase: igt/gem_ctx_engines
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190521211134.16117-2-chris@chris-wilson.co.uk
2019-05-22 05:11:26 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static struct i915_gem_engines *
|
|
|
|
__copy_engines(struct i915_gem_engines *e)
|
|
|
|
{
|
|
|
|
struct i915_gem_engines *copy;
|
|
|
|
unsigned int n;
|
|
|
|
|
|
|
|
copy = kmalloc(struct_size(e, engines, e->num_engines), GFP_KERNEL);
|
|
|
|
if (!copy)
|
|
|
|
return ERR_PTR(-ENOMEM);
|
|
|
|
|
2019-06-06 19:23:20 +08:00
|
|
|
init_rcu_head(©->rcu);
|
drm/i915: Allow a context to define its set of engines
Over the last few years, we have debated how to extend the user API to
support an increase in the number of engines, that may be sparse and
even be heterogeneous within a class (not all video decoders created
equal). We settled on using (class, instance) tuples to identify a
specific engine, with an API for the user to construct a map of engines
to capabilities. Into this picture, we then add a challenge of virtual
engines; one user engine that maps behind the scenes to any number of
physical engines. To keep it general, we want the user to have full
control over that mapping. To that end, we allow the user to constrain a
context to define the set of engines that it can access, order fully
controlled by the user via (class, instance). With such precise control
in context setup, we can continue to use the existing execbuf uABI of
specifying a single index; only now it doesn't automagically map onto
the engines, it uses the user defined engine map from the context.
v2: Fixup freeing of local on success of get_engines()
v3: Allow empty engines[]
v4: s/nengine/num_engines/
v5: Replace 64 limit on num_engines with a note that execbuf is
currently limited to only using the first 64 engines.
v6: Actually use the engines_mutex to guard the ctx->engines.
Testcase: igt/gem_ctx_engines
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190521211134.16117-2-chris@chris-wilson.co.uk
2019-05-22 05:11:26 +08:00
|
|
|
for (n = 0; n < e->num_engines; n++) {
|
|
|
|
if (e->engines[n])
|
|
|
|
copy->engines[n] = intel_context_get(e->engines[n]);
|
|
|
|
else
|
|
|
|
copy->engines[n] = NULL;
|
|
|
|
}
|
|
|
|
copy->num_engines = n;
|
|
|
|
|
|
|
|
return copy;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
get_engines(struct i915_gem_context *ctx,
|
|
|
|
struct drm_i915_gem_context_param *args)
|
|
|
|
{
|
|
|
|
struct i915_context_param_engines __user *user;
|
|
|
|
struct i915_gem_engines *e;
|
|
|
|
size_t n, count, size;
|
|
|
|
int err = 0;
|
|
|
|
|
|
|
|
err = mutex_lock_interruptible(&ctx->engines_mutex);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
|
|
|
e = NULL;
|
|
|
|
if (i915_gem_context_user_engines(ctx))
|
|
|
|
e = __copy_engines(i915_gem_context_engines(ctx));
|
|
|
|
mutex_unlock(&ctx->engines_mutex);
|
|
|
|
if (IS_ERR_OR_NULL(e)) {
|
|
|
|
args->size = 0;
|
|
|
|
return PTR_ERR_OR_ZERO(e);
|
|
|
|
}
|
|
|
|
|
|
|
|
count = e->num_engines;
|
|
|
|
|
|
|
|
/* Be paranoid in case we have an impedance mismatch */
|
|
|
|
if (!check_struct_size(user, engines, count, &size)) {
|
|
|
|
err = -EINVAL;
|
|
|
|
goto err_free;
|
|
|
|
}
|
|
|
|
if (overflows_type(size, args->size)) {
|
|
|
|
err = -EINVAL;
|
|
|
|
goto err_free;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (!args->size) {
|
|
|
|
args->size = size;
|
|
|
|
goto err_free;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (args->size < size) {
|
|
|
|
err = -EINVAL;
|
|
|
|
goto err_free;
|
|
|
|
}
|
|
|
|
|
|
|
|
user = u64_to_user_ptr(args->value);
|
|
|
|
if (!access_ok(user, size)) {
|
|
|
|
err = -EFAULT;
|
|
|
|
goto err_free;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (put_user(0, &user->extensions)) {
|
|
|
|
err = -EFAULT;
|
|
|
|
goto err_free;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (n = 0; n < count; n++) {
|
|
|
|
struct i915_engine_class_instance ci = {
|
|
|
|
.engine_class = I915_ENGINE_CLASS_INVALID,
|
|
|
|
.engine_instance = I915_ENGINE_CLASS_INVALID_NONE,
|
|
|
|
};
|
|
|
|
|
|
|
|
if (e->engines[n]) {
|
|
|
|
ci.engine_class = e->engines[n]->engine->uabi_class;
|
2019-08-06 20:43:00 +08:00
|
|
|
ci.engine_instance = e->engines[n]->engine->uabi_instance;
|
drm/i915: Allow a context to define its set of engines
Over the last few years, we have debated how to extend the user API to
support an increase in the number of engines, that may be sparse and
even be heterogeneous within a class (not all video decoders created
equal). We settled on using (class, instance) tuples to identify a
specific engine, with an API for the user to construct a map of engines
to capabilities. Into this picture, we then add a challenge of virtual
engines; one user engine that maps behind the scenes to any number of
physical engines. To keep it general, we want the user to have full
control over that mapping. To that end, we allow the user to constrain a
context to define the set of engines that it can access, order fully
controlled by the user via (class, instance). With such precise control
in context setup, we can continue to use the existing execbuf uABI of
specifying a single index; only now it doesn't automagically map onto
the engines, it uses the user defined engine map from the context.
v2: Fixup freeing of local on success of get_engines()
v3: Allow empty engines[]
v4: s/nengine/num_engines/
v5: Replace 64 limit on num_engines with a note that execbuf is
currently limited to only using the first 64 engines.
v6: Actually use the engines_mutex to guard the ctx->engines.
Testcase: igt/gem_ctx_engines
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190521211134.16117-2-chris@chris-wilson.co.uk
2019-05-22 05:11:26 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
if (copy_to_user(&user->engines[n], &ci, sizeof(ci))) {
|
|
|
|
err = -EFAULT;
|
|
|
|
goto err_free;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
args->size = size;
|
|
|
|
|
|
|
|
err_free:
|
2019-06-06 19:23:20 +08:00
|
|
|
free_engines(e);
|
drm/i915: Allow a context to define its set of engines
Over the last few years, we have debated how to extend the user API to
support an increase in the number of engines, that may be sparse and
even be heterogeneous within a class (not all video decoders created
equal). We settled on using (class, instance) tuples to identify a
specific engine, with an API for the user to construct a map of engines
to capabilities. Into this picture, we then add a challenge of virtual
engines; one user engine that maps behind the scenes to any number of
physical engines. To keep it general, we want the user to have full
control over that mapping. To that end, we allow the user to constrain a
context to define the set of engines that it can access, order fully
controlled by the user via (class, instance). With such precise control
in context setup, we can continue to use the existing execbuf uABI of
specifying a single index; only now it doesn't automagically map onto
the engines, it uses the user defined engine map from the context.
v2: Fixup freeing of local on success of get_engines()
v3: Allow empty engines[]
v4: s/nengine/num_engines/
v5: Replace 64 limit on num_engines with a note that execbuf is
currently limited to only using the first 64 engines.
v6: Actually use the engines_mutex to guard the ctx->engines.
Testcase: igt/gem_ctx_engines
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190521211134.16117-2-chris@chris-wilson.co.uk
2019-05-22 05:11:26 +08:00
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
drm/i915/gem: Make context persistence optional
Our existing behaviour is to allow contexts and their GPU requests to
persist past the point of closure until the requests are complete. This
allows clients to operate in a 'fire-and-forget' manner where they can
setup a rendering pipeline and hand it over to the display server and
immediately exit. As the rendering pipeline is kept alive until
completion, the display server (or other consumer) can use the results
in the future and present them to the user.
The compute model is a little different. They have little to no buffer
sharing between processes as their kernels tend to operate on a
continuous stream, feeding the results back to the client application.
These kernels operate for an indeterminate length of time, with many
clients wishing that the kernel was always running for as long as they
keep feeding in the data, i.e. acting like a DSP.
Not all clients want this persistent "desktop" behaviour and would prefer
that the contexts are cleaned up immediately upon closure. This ensures
that when clients are run without hangchecking (e.g. for compute kernels
of indeterminate runtime), any GPU hang or other unexpected workloads
are terminated with the process and does not continue to hog resources.
The default behaviour for new contexts is the legacy persistence mode,
as some desktop applications are dependent upon the existing behaviour.
New clients will have to opt in to immediate cleanup on context
closure. If the hangchecking modparam is disabled, so is persistent
context support -- all contexts will be terminated on closure.
We expect this behaviour change to be welcomed by compute users, who
have often been caught between a rock and a hard place. They disable
hangchecking to avoid their kernels being "unfairly" declared hung, but
have also experienced true hangs that the system was then unable to
clean up. Naturally, this leads to bug reports.
Testcase: igt/gem_ctx_persistence
Link: https://github.com/intel/compute-runtime/pull/228
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Jon Bloomfield <jon.bloomfield@intel.com>
Reviewed-by: Jon Bloomfield <jon.bloomfield@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: Jason Ekstrand <jason@jlekstrand.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20191029202338.8841-1-chris@chris-wilson.co.uk
2019-10-30 04:23:38 +08:00
|
|
|
static int
|
|
|
|
set_persistence(struct i915_gem_context *ctx,
|
|
|
|
const struct drm_i915_gem_context_param *args)
|
|
|
|
{
|
|
|
|
if (args->size)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
return __context_set_persistence(ctx, args->value);
|
|
|
|
}
|
|
|
|
|
2019-03-30 18:03:49 +08:00
|
|
|
static int ctx_setparam(struct drm_i915_file_private *fpriv,
|
|
|
|
struct i915_gem_context *ctx,
|
2019-03-22 17:23:24 +08:00
|
|
|
struct drm_i915_gem_context_param *args)
|
2014-12-25 00:13:40 +08:00
|
|
|
{
|
2018-09-11 21:22:06 +08:00
|
|
|
int ret = 0;
|
2014-12-25 00:13:40 +08:00
|
|
|
|
|
|
|
switch (args->param) {
|
2015-05-20 22:00:13 +08:00
|
|
|
case I915_CONTEXT_PARAM_NO_ZEROMAP:
|
2018-09-11 21:22:06 +08:00
|
|
|
if (args->size)
|
2015-05-20 22:00:13 +08:00
|
|
|
ret = -EINVAL;
|
2018-09-11 21:22:06 +08:00
|
|
|
else if (args->value)
|
|
|
|
set_bit(UCONTEXT_NO_ZEROMAP, &ctx->user_flags);
|
|
|
|
else
|
|
|
|
clear_bit(UCONTEXT_NO_ZEROMAP, &ctx->user_flags);
|
2016-07-04 15:08:39 +08:00
|
|
|
break;
|
2019-03-22 17:23:24 +08:00
|
|
|
|
2016-07-04 15:08:39 +08:00
|
|
|
case I915_CONTEXT_PARAM_NO_ERROR_CAPTURE:
|
2016-12-31 19:20:11 +08:00
|
|
|
if (args->size)
|
2016-07-04 15:08:39 +08:00
|
|
|
ret = -EINVAL;
|
2016-12-31 19:20:11 +08:00
|
|
|
else if (args->value)
|
|
|
|
i915_gem_context_set_no_error_capture(ctx);
|
|
|
|
else
|
|
|
|
i915_gem_context_clear_no_error_capture(ctx);
|
2015-05-20 22:00:13 +08:00
|
|
|
break;
|
2019-03-22 17:23:24 +08:00
|
|
|
|
2016-11-16 23:20:32 +08:00
|
|
|
case I915_CONTEXT_PARAM_BANNABLE:
|
|
|
|
if (args->size)
|
|
|
|
ret = -EINVAL;
|
|
|
|
else if (!capable(CAP_SYS_ADMIN) && !args->value)
|
|
|
|
ret = -EPERM;
|
2016-12-31 19:20:11 +08:00
|
|
|
else if (args->value)
|
|
|
|
i915_gem_context_set_bannable(ctx);
|
2016-11-16 23:20:32 +08:00
|
|
|
else
|
2016-12-31 19:20:11 +08:00
|
|
|
i915_gem_context_clear_bannable(ctx);
|
2016-11-16 23:20:32 +08:00
|
|
|
break;
|
drm/i915/scheduler: Support user-defined priorities
Use a priority stored in the context as the initial value when
submitting a request. This allows us to change the default priority on a
per-context basis, allowing different contexts to be favoured with GPU
time at the expense of lower importance work. The user can adjust the
context's priority via I915_CONTEXT_PARAM_PRIORITY, with more positive
values being higher priority (they will be serviced earlier, after their
dependencies have been resolved). Any prerequisite work for an execbuf
will have its priority raised to match the new request as required.
Normal users can specify any value in the range of -1023 to 0 [default],
i.e. they can reduce the priority of their workloads (and temporarily
boost it back to normal if so desired).
Privileged users can specify any value in the range of -1023 to 1023,
[default is 0], i.e. they can raise their priority above all overs and
so potentially starve the system.
Note that the existing schedulers are not fair, nor load balancing, the
execution is strictly by priority on a first-come, first-served basis,
and the driver may choose to boost some requests above the range
available to users.
This priority was originally based around nice(2), but evolved to allow
clients to adjust their priority within a small range, and allow for a
privileged high priority range.
For example, this can be used to implement EGL_IMG_context_priority
https://www.khronos.org/registry/egl/extensions/IMG/EGL_IMG_context_priority.txt
EGL_CONTEXT_PRIORITY_LEVEL_IMG determines the priority level of
the context to be created. This attribute is a hint, as an
implementation may not support multiple contexts at some
priority levels and system policy may limit access to high
priority contexts to appropriate system privilege level. The
default value for EGL_CONTEXT_PRIORITY_LEVEL_IMG is
EGL_CONTEXT_PRIORITY_MEDIUM_IMG."
so we can map
PRIORITY_HIGH -> 1023 [privileged, will failback to 0]
PRIORITY_MED -> 0 [default]
PRIORITY_LOW -> -1023
They also map onto the priorities used by VkQueue (and a VkQueue is
essentially a timeline, our i915_gem_context under full-ppgtt).
v2: s/CAP_SYS_ADMIN/CAP_SYS_NICE/
v3: Report min/max user priorities as defines in the uapi, and rebase
internal priorities on the exposed values.
Testcase: igt/gem_exec_schedule
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171003203453.15692-9-chris@chris-wilson.co.uk
2017-10-04 04:34:53 +08:00
|
|
|
|
2019-02-18 18:58:21 +08:00
|
|
|
case I915_CONTEXT_PARAM_RECOVERABLE:
|
|
|
|
if (args->size)
|
|
|
|
ret = -EINVAL;
|
|
|
|
else if (args->value)
|
|
|
|
i915_gem_context_set_recoverable(ctx);
|
|
|
|
else
|
|
|
|
i915_gem_context_clear_recoverable(ctx);
|
|
|
|
break;
|
|
|
|
|
drm/i915/scheduler: Support user-defined priorities
Use a priority stored in the context as the initial value when
submitting a request. This allows us to change the default priority on a
per-context basis, allowing different contexts to be favoured with GPU
time at the expense of lower importance work. The user can adjust the
context's priority via I915_CONTEXT_PARAM_PRIORITY, with more positive
values being higher priority (they will be serviced earlier, after their
dependencies have been resolved). Any prerequisite work for an execbuf
will have its priority raised to match the new request as required.
Normal users can specify any value in the range of -1023 to 0 [default],
i.e. they can reduce the priority of their workloads (and temporarily
boost it back to normal if so desired).
Privileged users can specify any value in the range of -1023 to 1023,
[default is 0], i.e. they can raise their priority above all overs and
so potentially starve the system.
Note that the existing schedulers are not fair, nor load balancing, the
execution is strictly by priority on a first-come, first-served basis,
and the driver may choose to boost some requests above the range
available to users.
This priority was originally based around nice(2), but evolved to allow
clients to adjust their priority within a small range, and allow for a
privileged high priority range.
For example, this can be used to implement EGL_IMG_context_priority
https://www.khronos.org/registry/egl/extensions/IMG/EGL_IMG_context_priority.txt
EGL_CONTEXT_PRIORITY_LEVEL_IMG determines the priority level of
the context to be created. This attribute is a hint, as an
implementation may not support multiple contexts at some
priority levels and system policy may limit access to high
priority contexts to appropriate system privilege level. The
default value for EGL_CONTEXT_PRIORITY_LEVEL_IMG is
EGL_CONTEXT_PRIORITY_MEDIUM_IMG."
so we can map
PRIORITY_HIGH -> 1023 [privileged, will failback to 0]
PRIORITY_MED -> 0 [default]
PRIORITY_LOW -> -1023
They also map onto the priorities used by VkQueue (and a VkQueue is
essentially a timeline, our i915_gem_context under full-ppgtt).
v2: s/CAP_SYS_ADMIN/CAP_SYS_NICE/
v3: Report min/max user priorities as defines in the uapi, and rebase
internal priorities on the exposed values.
Testcase: igt/gem_exec_schedule
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171003203453.15692-9-chris@chris-wilson.co.uk
2017-10-04 04:34:53 +08:00
|
|
|
case I915_CONTEXT_PARAM_PRIORITY:
|
|
|
|
{
|
2018-02-08 16:51:51 +08:00
|
|
|
s64 priority = args->value;
|
drm/i915/scheduler: Support user-defined priorities
Use a priority stored in the context as the initial value when
submitting a request. This allows us to change the default priority on a
per-context basis, allowing different contexts to be favoured with GPU
time at the expense of lower importance work. The user can adjust the
context's priority via I915_CONTEXT_PARAM_PRIORITY, with more positive
values being higher priority (they will be serviced earlier, after their
dependencies have been resolved). Any prerequisite work for an execbuf
will have its priority raised to match the new request as required.
Normal users can specify any value in the range of -1023 to 0 [default],
i.e. they can reduce the priority of their workloads (and temporarily
boost it back to normal if so desired).
Privileged users can specify any value in the range of -1023 to 1023,
[default is 0], i.e. they can raise their priority above all overs and
so potentially starve the system.
Note that the existing schedulers are not fair, nor load balancing, the
execution is strictly by priority on a first-come, first-served basis,
and the driver may choose to boost some requests above the range
available to users.
This priority was originally based around nice(2), but evolved to allow
clients to adjust their priority within a small range, and allow for a
privileged high priority range.
For example, this can be used to implement EGL_IMG_context_priority
https://www.khronos.org/registry/egl/extensions/IMG/EGL_IMG_context_priority.txt
EGL_CONTEXT_PRIORITY_LEVEL_IMG determines the priority level of
the context to be created. This attribute is a hint, as an
implementation may not support multiple contexts at some
priority levels and system policy may limit access to high
priority contexts to appropriate system privilege level. The
default value for EGL_CONTEXT_PRIORITY_LEVEL_IMG is
EGL_CONTEXT_PRIORITY_MEDIUM_IMG."
so we can map
PRIORITY_HIGH -> 1023 [privileged, will failback to 0]
PRIORITY_MED -> 0 [default]
PRIORITY_LOW -> -1023
They also map onto the priorities used by VkQueue (and a VkQueue is
essentially a timeline, our i915_gem_context under full-ppgtt).
v2: s/CAP_SYS_ADMIN/CAP_SYS_NICE/
v3: Report min/max user priorities as defines in the uapi, and rebase
internal priorities on the exposed values.
Testcase: igt/gem_exec_schedule
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171003203453.15692-9-chris@chris-wilson.co.uk
2017-10-04 04:34:53 +08:00
|
|
|
|
|
|
|
if (args->size)
|
|
|
|
ret = -EINVAL;
|
2019-03-22 17:23:24 +08:00
|
|
|
else if (!(ctx->i915->caps.scheduler & I915_SCHEDULER_CAP_PRIORITY))
|
drm/i915/scheduler: Support user-defined priorities
Use a priority stored in the context as the initial value when
submitting a request. This allows us to change the default priority on a
per-context basis, allowing different contexts to be favoured with GPU
time at the expense of lower importance work. The user can adjust the
context's priority via I915_CONTEXT_PARAM_PRIORITY, with more positive
values being higher priority (they will be serviced earlier, after their
dependencies have been resolved). Any prerequisite work for an execbuf
will have its priority raised to match the new request as required.
Normal users can specify any value in the range of -1023 to 0 [default],
i.e. they can reduce the priority of their workloads (and temporarily
boost it back to normal if so desired).
Privileged users can specify any value in the range of -1023 to 1023,
[default is 0], i.e. they can raise their priority above all overs and
so potentially starve the system.
Note that the existing schedulers are not fair, nor load balancing, the
execution is strictly by priority on a first-come, first-served basis,
and the driver may choose to boost some requests above the range
available to users.
This priority was originally based around nice(2), but evolved to allow
clients to adjust their priority within a small range, and allow for a
privileged high priority range.
For example, this can be used to implement EGL_IMG_context_priority
https://www.khronos.org/registry/egl/extensions/IMG/EGL_IMG_context_priority.txt
EGL_CONTEXT_PRIORITY_LEVEL_IMG determines the priority level of
the context to be created. This attribute is a hint, as an
implementation may not support multiple contexts at some
priority levels and system policy may limit access to high
priority contexts to appropriate system privilege level. The
default value for EGL_CONTEXT_PRIORITY_LEVEL_IMG is
EGL_CONTEXT_PRIORITY_MEDIUM_IMG."
so we can map
PRIORITY_HIGH -> 1023 [privileged, will failback to 0]
PRIORITY_MED -> 0 [default]
PRIORITY_LOW -> -1023
They also map onto the priorities used by VkQueue (and a VkQueue is
essentially a timeline, our i915_gem_context under full-ppgtt).
v2: s/CAP_SYS_ADMIN/CAP_SYS_NICE/
v3: Report min/max user priorities as defines in the uapi, and rebase
internal priorities on the exposed values.
Testcase: igt/gem_exec_schedule
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171003203453.15692-9-chris@chris-wilson.co.uk
2017-10-04 04:34:53 +08:00
|
|
|
ret = -ENODEV;
|
|
|
|
else if (priority > I915_CONTEXT_MAX_USER_PRIORITY ||
|
|
|
|
priority < I915_CONTEXT_MIN_USER_PRIORITY)
|
|
|
|
ret = -EINVAL;
|
|
|
|
else if (priority > I915_CONTEXT_DEFAULT_PRIORITY &&
|
|
|
|
!capable(CAP_SYS_NICE))
|
|
|
|
ret = -EPERM;
|
|
|
|
else
|
2018-10-01 20:32:03 +08:00
|
|
|
ctx->sched.priority =
|
|
|
|
I915_USER_PRIORITY(priority);
|
drm/i915/scheduler: Support user-defined priorities
Use a priority stored in the context as the initial value when
submitting a request. This allows us to change the default priority on a
per-context basis, allowing different contexts to be favoured with GPU
time at the expense of lower importance work. The user can adjust the
context's priority via I915_CONTEXT_PARAM_PRIORITY, with more positive
values being higher priority (they will be serviced earlier, after their
dependencies have been resolved). Any prerequisite work for an execbuf
will have its priority raised to match the new request as required.
Normal users can specify any value in the range of -1023 to 0 [default],
i.e. they can reduce the priority of their workloads (and temporarily
boost it back to normal if so desired).
Privileged users can specify any value in the range of -1023 to 1023,
[default is 0], i.e. they can raise their priority above all overs and
so potentially starve the system.
Note that the existing schedulers are not fair, nor load balancing, the
execution is strictly by priority on a first-come, first-served basis,
and the driver may choose to boost some requests above the range
available to users.
This priority was originally based around nice(2), but evolved to allow
clients to adjust their priority within a small range, and allow for a
privileged high priority range.
For example, this can be used to implement EGL_IMG_context_priority
https://www.khronos.org/registry/egl/extensions/IMG/EGL_IMG_context_priority.txt
EGL_CONTEXT_PRIORITY_LEVEL_IMG determines the priority level of
the context to be created. This attribute is a hint, as an
implementation may not support multiple contexts at some
priority levels and system policy may limit access to high
priority contexts to appropriate system privilege level. The
default value for EGL_CONTEXT_PRIORITY_LEVEL_IMG is
EGL_CONTEXT_PRIORITY_MEDIUM_IMG."
so we can map
PRIORITY_HIGH -> 1023 [privileged, will failback to 0]
PRIORITY_MED -> 0 [default]
PRIORITY_LOW -> -1023
They also map onto the priorities used by VkQueue (and a VkQueue is
essentially a timeline, our i915_gem_context under full-ppgtt).
v2: s/CAP_SYS_ADMIN/CAP_SYS_NICE/
v3: Report min/max user priorities as defines in the uapi, and rebase
internal priorities on the exposed values.
Testcase: igt/gem_exec_schedule
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171003203453.15692-9-chris@chris-wilson.co.uk
2017-10-04 04:34:53 +08:00
|
|
|
}
|
|
|
|
break;
|
2019-03-22 17:23:23 +08:00
|
|
|
|
drm/i915: Expose RPCS (SSEU) configuration to userspace (Gen11 only)
We want to allow userspace to reconfigure the subslice configuration on a
per context basis.
This is required for the functional requirement of shutting down non-VME
enabled sub-slices on Gen11 parts.
To do so, we expose a context parameter to allow adjustment of the RPCS
register stored within the context image (and currently not accessible via
LRI).
If the context is adjusted before first use or whilst idle, the adjustment
is for "free"; otherwise if the context is active we queue a request to do
so (using the kernel context), following all other activity by that
context, which is also marked as barrier for all following submission
against the same context.
Since the overhead of device re-configuration during context switching can
be significant, especially in multi-context workloads, we limit this new
uAPI to only support the Gen11 VME use case. In this use case either the
device is fully enabled, and exactly one slice and half of the subslices
are enabled.
Example usage:
struct drm_i915_gem_context_param_sseu sseu = { };
struct drm_i915_gem_context_param arg = {
.param = I915_CONTEXT_PARAM_SSEU,
.ctx_id = gem_context_create(fd),
.size = sizeof(sseu),
.value = to_user_pointer(&sseu)
};
/* Query device defaults. */
gem_context_get_param(fd, &arg);
/* Set VME configuration on a 1x6x8 part. */
sseu.slice_mask = 0x1;
sseu.subslice_mask = 0xe0;
gem_context_set_param(fd, &arg);
v2: Fix offset of CTX_R_PWR_CLK_STATE in intel_lr_context_set_sseu()
(Lionel)
v3: Add ability to program this per engine (Chris)
v4: Move most get_sseu() into i915_gem_context.c (Lionel)
v5: Validate sseu configuration against the device's capabilities (Lionel)
v6: Change context powergating settings through MI_SDM on kernel context
(Chris)
v7: Synchronize the requests following a powergating setting change using
a global dependency (Chris)
Iterate timelines through dev_priv.gt.active_rings (Tvrtko)
Disable RPCS configuration setting for non capable users
(Lionel/Tvrtko)
v8: s/union intel_sseu/struct intel_sseu/ (Lionel)
s/dev_priv/i915/ (Tvrtko)
Change uapi class/instance fields to u16 (Tvrtko)
Bump mask fields to 64bits (Lionel)
Don't return EPERM when dynamic sseu is disabled (Tvrtko)
v9: Import context image into kernel context's ppgtt only when
reconfiguring powergated slice/subslices (Chris)
Use aliasing ppgtt when needed (Michel)
Tvrtko Ursulin:
v10:
* Update for upstream changes.
* Request submit needs a RPM reference.
* Reject on !FULL_PPGTT for simplicity.
* Pull out get/set param to helpers for readability and less indent.
* Use i915_request_await_dma_fence in add_global_barrier to skip waits
on the same timeline and avoid GEM_BUG_ON.
* No need to explicitly assign a NULL pointer to engine in legacy mode.
* No need to move gen8_make_rpcs up.
* Factored out global barrier as prep patch.
* Allow to only CAP_SYS_ADMIN if !Gen11.
v11:
* Remove engine vfunc in favour of local helper. (Chris Wilson)
* Stop retiring requests before updates since it is not needed
(Chris Wilson)
* Implement direct CPU update path for idle contexts. (Chris Wilson)
* Left side dependency needs only be on the same context timeline.
(Chris Wilson)
* It is sufficient to order the timeline. (Chris Wilson)
* Reject !RCS configuration attempts with -ENODEV for now.
v12:
* Rebase for make_rpcs.
v13:
* Centralize SSEU normalization to make_rpcs.
* Type width checking (uAPI <-> implementation).
* Gen11 restrictions uAPI checks.
* Gen11 subslice count differences handling.
Chris Wilson:
* args->size handling fixes.
* Update context image from GGTT.
* Postpone context image update to pinning.
* Use i915_gem_active_raw instead of last_request_on_engine.
v14:
* Add activity tracker on intel_context to fix the lifetime issues
and simplify the code. (Chris Wilson)
v15:
* Fix context pin leak if no space in ring by simplifying the
context pinning sequence.
v16:
* Rebase for context get/set param locking changes.
* Just -ENODEV on !Gen11. (Joonas)
v17:
* Fix one Gen11 subslice enablement rule.
* Handle error from i915_sw_fence_await_sw_fence_gfp. (Chris Wilson)
v18:
* Update commit message. (Joonas)
* Restrict uAPI to VME use case. (Joonas)
v19:
* Rebase.
v20:
* Rebase for ce->active_tracker.
v21:
* Rebase for IS_GEN changes.
v22:
* Reserve uAPI for flags straight away. (Chris Wilson)
v23:
* Rebase for RUNTIME_INFO.
v24:
* Added some headline docs for the uapi usage. (Joonas/Chris)
v25:
* Renamed class/instance to engine_class/engine_instance to avoid clash
with C++ keyword. (Tony Ye)
v26:
* Rebased for runtime pm api changes.
v27:
* Rebased for intel_context_init.
* Wrap commit msg to 75.
v28:
(Chris Wilson)
* Use i915_gem_ggtt.
* Use i915_request_await_dma_fence to show a better example.
v29:
* i915_timeline_set_barrier can now fail. (Chris Wilson)
v30:
* Capture some acks.
v31:
* Drop the WARN_ON from use controllable paths. (Chris Wilson)
* Use overflows_type for all checks.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=100899
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=107634
Issue: https://github.com/intel/media-driver/issues/267
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: Dmitry Rogozhkin <dmitry.v.rogozhkin@intel.com>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Zhipeng Gong <zhipeng.gong@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Tony Ye <tony.ye@intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: Timo Aaltonen <timo.aaltonen@canonical.com>
Acked-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Stéphane Marchesin <marcheu@chromium.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190205095032.22673-4-tvrtko.ursulin@linux.intel.com
2019-02-05 17:50:31 +08:00
|
|
|
case I915_CONTEXT_PARAM_SSEU:
|
|
|
|
ret = set_sseu(ctx, args);
|
|
|
|
break;
|
2019-03-22 17:23:23 +08:00
|
|
|
|
|
|
|
case I915_CONTEXT_PARAM_VM:
|
2019-03-30 18:03:49 +08:00
|
|
|
ret = set_ppgtt(fpriv, ctx, args);
|
2019-03-22 17:23:23 +08:00
|
|
|
break;
|
|
|
|
|
drm/i915: Allow a context to define its set of engines
Over the last few years, we have debated how to extend the user API to
support an increase in the number of engines, that may be sparse and
even be heterogeneous within a class (not all video decoders created
equal). We settled on using (class, instance) tuples to identify a
specific engine, with an API for the user to construct a map of engines
to capabilities. Into this picture, we then add a challenge of virtual
engines; one user engine that maps behind the scenes to any number of
physical engines. To keep it general, we want the user to have full
control over that mapping. To that end, we allow the user to constrain a
context to define the set of engines that it can access, order fully
controlled by the user via (class, instance). With such precise control
in context setup, we can continue to use the existing execbuf uABI of
specifying a single index; only now it doesn't automagically map onto
the engines, it uses the user defined engine map from the context.
v2: Fixup freeing of local on success of get_engines()
v3: Allow empty engines[]
v4: s/nengine/num_engines/
v5: Replace 64 limit on num_engines with a note that execbuf is
currently limited to only using the first 64 engines.
v6: Actually use the engines_mutex to guard the ctx->engines.
Testcase: igt/gem_ctx_engines
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190521211134.16117-2-chris@chris-wilson.co.uk
2019-05-22 05:11:26 +08:00
|
|
|
case I915_CONTEXT_PARAM_ENGINES:
|
|
|
|
ret = set_engines(ctx, args);
|
|
|
|
break;
|
|
|
|
|
drm/i915/gem: Make context persistence optional
Our existing behaviour is to allow contexts and their GPU requests to
persist past the point of closure until the requests are complete. This
allows clients to operate in a 'fire-and-forget' manner where they can
setup a rendering pipeline and hand it over to the display server and
immediately exit. As the rendering pipeline is kept alive until
completion, the display server (or other consumer) can use the results
in the future and present them to the user.
The compute model is a little different. They have little to no buffer
sharing between processes as their kernels tend to operate on a
continuous stream, feeding the results back to the client application.
These kernels operate for an indeterminate length of time, with many
clients wishing that the kernel was always running for as long as they
keep feeding in the data, i.e. acting like a DSP.
Not all clients want this persistent "desktop" behaviour and would prefer
that the contexts are cleaned up immediately upon closure. This ensures
that when clients are run without hangchecking (e.g. for compute kernels
of indeterminate runtime), any GPU hang or other unexpected workloads
are terminated with the process and does not continue to hog resources.
The default behaviour for new contexts is the legacy persistence mode,
as some desktop applications are dependent upon the existing behaviour.
New clients will have to opt in to immediate cleanup on context
closure. If the hangchecking modparam is disabled, so is persistent
context support -- all contexts will be terminated on closure.
We expect this behaviour change to be welcomed by compute users, who
have often been caught between a rock and a hard place. They disable
hangchecking to avoid their kernels being "unfairly" declared hung, but
have also experienced true hangs that the system was then unable to
clean up. Naturally, this leads to bug reports.
Testcase: igt/gem_ctx_persistence
Link: https://github.com/intel/compute-runtime/pull/228
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Jon Bloomfield <jon.bloomfield@intel.com>
Reviewed-by: Jon Bloomfield <jon.bloomfield@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: Jason Ekstrand <jason@jlekstrand.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20191029202338.8841-1-chris@chris-wilson.co.uk
2019-10-30 04:23:38 +08:00
|
|
|
case I915_CONTEXT_PARAM_PERSISTENCE:
|
|
|
|
ret = set_persistence(ctx, args);
|
|
|
|
break;
|
|
|
|
|
2019-03-22 17:23:23 +08:00
|
|
|
case I915_CONTEXT_PARAM_BAN_PERIOD:
|
2014-12-25 00:13:40 +08:00
|
|
|
default:
|
|
|
|
ret = -EINVAL;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2019-03-22 17:23:24 +08:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
struct create_ext {
|
|
|
|
struct i915_gem_context *ctx;
|
|
|
|
struct drm_i915_file_private *fpriv;
|
|
|
|
};
|
|
|
|
|
|
|
|
static int create_setparam(struct i915_user_extension __user *ext, void *data)
|
|
|
|
{
|
|
|
|
struct drm_i915_gem_context_create_ext_setparam local;
|
|
|
|
const struct create_ext *arg = data;
|
|
|
|
|
|
|
|
if (copy_from_user(&local, ext, sizeof(local)))
|
|
|
|
return -EFAULT;
|
|
|
|
|
|
|
|
if (local.param.ctx_id)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2019-03-30 18:03:49 +08:00
|
|
|
return ctx_setparam(arg->fpriv, arg->ctx, &local.param);
|
2019-03-22 17:23:24 +08:00
|
|
|
}
|
|
|
|
|
2019-05-22 05:11:29 +08:00
|
|
|
static int clone_engines(struct i915_gem_context *dst,
|
|
|
|
struct i915_gem_context *src)
|
|
|
|
{
|
|
|
|
struct i915_gem_engines *e = i915_gem_context_lock_engines(src);
|
|
|
|
struct i915_gem_engines *clone;
|
|
|
|
bool user_engines;
|
|
|
|
unsigned long n;
|
|
|
|
|
|
|
|
clone = kmalloc(struct_size(e, engines, e->num_engines), GFP_KERNEL);
|
|
|
|
if (!clone)
|
|
|
|
goto err_unlock;
|
|
|
|
|
2019-06-06 19:23:20 +08:00
|
|
|
init_rcu_head(&clone->rcu);
|
2019-05-22 05:11:29 +08:00
|
|
|
for (n = 0; n < e->num_engines; n++) {
|
drm/i915: Load balancing across a virtual engine
Having allowed the user to define a set of engines that they will want
to only use, we go one step further and allow them to bind those engines
into a single virtual instance. Submitting a batch to the virtual engine
will then forward it to any one of the set in a manner as best to
distribute load. The virtual engine has a single timeline across all
engines (it operates as a single queue), so it is not able to concurrently
run batches across multiple engines by itself; that is left up to the user
to submit multiple concurrent batches to multiple queues. Multiple users
will be load balanced across the system.
The mechanism used for load balancing in this patch is a late greedy
balancer. When a request is ready for execution, it is added to each
engine's queue, and when an engine is ready for its next request it
claims it from the virtual engine. The first engine to do so, wins, i.e.
the request is executed at the earliest opportunity (idle moment) in the
system.
As not all HW is created equal, the user is still able to skip the
virtual engine and execute the batch on a specific engine, all within the
same queue. It will then be executed in order on the correct engine,
with execution on other virtual engines being moved away due to the load
detection.
A couple of areas for potential improvement left!
- The virtual engine always take priority over equal-priority tasks.
Mostly broken up by applying FQ_CODEL rules for prioritising new clients,
and hopefully the virtual and real engines are not then congested (i.e.
all work is via virtual engines, or all work is to the real engine).
- We require the breadcrumb irq around every virtual engine request. For
normal engines, we eliminate the need for the slow round trip via
interrupt by using the submit fence and queueing in order. For virtual
engines, we have to allow any job to transfer to a new ring, and cannot
coalesce the submissions, so require the completion fence instead,
forcing the persistent use of interrupts.
- We only drip feed single requests through each virtual engine and onto
the physical engines, even if there was enough work to fill all ELSP,
leaving small stalls with an idle CS event at the end of every request.
Could we be greedy and fill both slots? Being lazy is virtuous for load
distribution on less-than-full workloads though.
Other areas of improvement are more general, such as reducing lock
contention, reducing dispatch overhead, looking at direct submission
rather than bouncing around tasklets etc.
sseu: Lift the restriction to allow sseu to be reconfigured on virtual
engines composed of RENDER_CLASS (rcs).
v2: macroize check_user_mbz()
v3: Cancel virtual engines on wedging
v4: Commence commenting
v5: Replace 64b sibling_mask with a list of class:instance
v6: Drop the one-element array in the uabi
v7: Assert it is an virtual engine in to_virtual_engine()
v8: Skip over holes in [class][inst] so we can selftest with (vcs0, vcs2)
Link: https://github.com/intel/media-driver/pull/283
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190521211134.16117-6-chris@chris-wilson.co.uk
2019-05-22 05:11:30 +08:00
|
|
|
struct intel_engine_cs *engine;
|
|
|
|
|
2019-05-22 05:11:29 +08:00
|
|
|
if (!e->engines[n]) {
|
|
|
|
clone->engines[n] = NULL;
|
|
|
|
continue;
|
|
|
|
}
|
drm/i915: Load balancing across a virtual engine
Having allowed the user to define a set of engines that they will want
to only use, we go one step further and allow them to bind those engines
into a single virtual instance. Submitting a batch to the virtual engine
will then forward it to any one of the set in a manner as best to
distribute load. The virtual engine has a single timeline across all
engines (it operates as a single queue), so it is not able to concurrently
run batches across multiple engines by itself; that is left up to the user
to submit multiple concurrent batches to multiple queues. Multiple users
will be load balanced across the system.
The mechanism used for load balancing in this patch is a late greedy
balancer. When a request is ready for execution, it is added to each
engine's queue, and when an engine is ready for its next request it
claims it from the virtual engine. The first engine to do so, wins, i.e.
the request is executed at the earliest opportunity (idle moment) in the
system.
As not all HW is created equal, the user is still able to skip the
virtual engine and execute the batch on a specific engine, all within the
same queue. It will then be executed in order on the correct engine,
with execution on other virtual engines being moved away due to the load
detection.
A couple of areas for potential improvement left!
- The virtual engine always take priority over equal-priority tasks.
Mostly broken up by applying FQ_CODEL rules for prioritising new clients,
and hopefully the virtual and real engines are not then congested (i.e.
all work is via virtual engines, or all work is to the real engine).
- We require the breadcrumb irq around every virtual engine request. For
normal engines, we eliminate the need for the slow round trip via
interrupt by using the submit fence and queueing in order. For virtual
engines, we have to allow any job to transfer to a new ring, and cannot
coalesce the submissions, so require the completion fence instead,
forcing the persistent use of interrupts.
- We only drip feed single requests through each virtual engine and onto
the physical engines, even if there was enough work to fill all ELSP,
leaving small stalls with an idle CS event at the end of every request.
Could we be greedy and fill both slots? Being lazy is virtuous for load
distribution on less-than-full workloads though.
Other areas of improvement are more general, such as reducing lock
contention, reducing dispatch overhead, looking at direct submission
rather than bouncing around tasklets etc.
sseu: Lift the restriction to allow sseu to be reconfigured on virtual
engines composed of RENDER_CLASS (rcs).
v2: macroize check_user_mbz()
v3: Cancel virtual engines on wedging
v4: Commence commenting
v5: Replace 64b sibling_mask with a list of class:instance
v6: Drop the one-element array in the uabi
v7: Assert it is an virtual engine in to_virtual_engine()
v8: Skip over holes in [class][inst] so we can selftest with (vcs0, vcs2)
Link: https://github.com/intel/media-driver/pull/283
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190521211134.16117-6-chris@chris-wilson.co.uk
2019-05-22 05:11:30 +08:00
|
|
|
engine = e->engines[n]->engine;
|
2019-05-22 05:11:29 +08:00
|
|
|
|
drm/i915: Load balancing across a virtual engine
Having allowed the user to define a set of engines that they will want
to only use, we go one step further and allow them to bind those engines
into a single virtual instance. Submitting a batch to the virtual engine
will then forward it to any one of the set in a manner as best to
distribute load. The virtual engine has a single timeline across all
engines (it operates as a single queue), so it is not able to concurrently
run batches across multiple engines by itself; that is left up to the user
to submit multiple concurrent batches to multiple queues. Multiple users
will be load balanced across the system.
The mechanism used for load balancing in this patch is a late greedy
balancer. When a request is ready for execution, it is added to each
engine's queue, and when an engine is ready for its next request it
claims it from the virtual engine. The first engine to do so, wins, i.e.
the request is executed at the earliest opportunity (idle moment) in the
system.
As not all HW is created equal, the user is still able to skip the
virtual engine and execute the batch on a specific engine, all within the
same queue. It will then be executed in order on the correct engine,
with execution on other virtual engines being moved away due to the load
detection.
A couple of areas for potential improvement left!
- The virtual engine always take priority over equal-priority tasks.
Mostly broken up by applying FQ_CODEL rules for prioritising new clients,
and hopefully the virtual and real engines are not then congested (i.e.
all work is via virtual engines, or all work is to the real engine).
- We require the breadcrumb irq around every virtual engine request. For
normal engines, we eliminate the need for the slow round trip via
interrupt by using the submit fence and queueing in order. For virtual
engines, we have to allow any job to transfer to a new ring, and cannot
coalesce the submissions, so require the completion fence instead,
forcing the persistent use of interrupts.
- We only drip feed single requests through each virtual engine and onto
the physical engines, even if there was enough work to fill all ELSP,
leaving small stalls with an idle CS event at the end of every request.
Could we be greedy and fill both slots? Being lazy is virtuous for load
distribution on less-than-full workloads though.
Other areas of improvement are more general, such as reducing lock
contention, reducing dispatch overhead, looking at direct submission
rather than bouncing around tasklets etc.
sseu: Lift the restriction to allow sseu to be reconfigured on virtual
engines composed of RENDER_CLASS (rcs).
v2: macroize check_user_mbz()
v3: Cancel virtual engines on wedging
v4: Commence commenting
v5: Replace 64b sibling_mask with a list of class:instance
v6: Drop the one-element array in the uabi
v7: Assert it is an virtual engine in to_virtual_engine()
v8: Skip over holes in [class][inst] so we can selftest with (vcs0, vcs2)
Link: https://github.com/intel/media-driver/pull/283
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190521211134.16117-6-chris@chris-wilson.co.uk
2019-05-22 05:11:30 +08:00
|
|
|
/*
|
|
|
|
* Virtual engines are singletons; they can only exist
|
|
|
|
* inside a single context, because they embed their
|
|
|
|
* HW context... As each virtual context implies a single
|
|
|
|
* timeline (each engine can only dequeue a single request
|
|
|
|
* at any time), it would be surprising for two contexts
|
|
|
|
* to use the same engine. So let's create a copy of
|
|
|
|
* the virtual engine instead.
|
|
|
|
*/
|
|
|
|
if (intel_engine_is_virtual(engine))
|
|
|
|
clone->engines[n] =
|
|
|
|
intel_execlists_clone_virtual(dst, engine);
|
|
|
|
else
|
|
|
|
clone->engines[n] = intel_context_create(dst, engine);
|
|
|
|
if (IS_ERR_OR_NULL(clone->engines[n])) {
|
2019-05-22 05:11:29 +08:00
|
|
|
__free_engines(clone, n);
|
|
|
|
goto err_unlock;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
clone->num_engines = n;
|
|
|
|
|
|
|
|
user_engines = i915_gem_context_user_engines(src);
|
|
|
|
i915_gem_context_unlock_engines(src);
|
|
|
|
|
2019-11-15 06:57:36 +08:00
|
|
|
/* Serialised by constructor */
|
|
|
|
free_engines(__context_engines_static(dst));
|
2019-05-22 05:11:29 +08:00
|
|
|
RCU_INIT_POINTER(dst->engines, clone);
|
|
|
|
if (user_engines)
|
|
|
|
i915_gem_context_set_user_engines(dst);
|
|
|
|
else
|
|
|
|
i915_gem_context_clear_user_engines(dst);
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
err_unlock:
|
|
|
|
i915_gem_context_unlock_engines(src);
|
|
|
|
return -ENOMEM;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int clone_flags(struct i915_gem_context *dst,
|
|
|
|
struct i915_gem_context *src)
|
|
|
|
{
|
|
|
|
dst->user_flags = src->user_flags;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int clone_schedattr(struct i915_gem_context *dst,
|
|
|
|
struct i915_gem_context *src)
|
|
|
|
{
|
|
|
|
dst->sched = src->sched;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int clone_sseu(struct i915_gem_context *dst,
|
|
|
|
struct i915_gem_context *src)
|
|
|
|
{
|
|
|
|
struct i915_gem_engines *e = i915_gem_context_lock_engines(src);
|
|
|
|
struct i915_gem_engines *clone;
|
|
|
|
unsigned long n;
|
|
|
|
int err;
|
|
|
|
|
2019-11-15 06:57:36 +08:00
|
|
|
/* no locking required; sole access under constructor*/
|
|
|
|
clone = __context_engines_static(dst);
|
2019-05-22 05:11:29 +08:00
|
|
|
if (e->num_engines != clone->num_engines) {
|
|
|
|
err = -EINVAL;
|
|
|
|
goto unlock;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (n = 0; n < e->num_engines; n++) {
|
|
|
|
struct intel_context *ce = e->engines[n];
|
|
|
|
|
|
|
|
if (clone->engines[n]->engine->class != ce->engine->class) {
|
|
|
|
/* Must have compatible engine maps! */
|
|
|
|
err = -EINVAL;
|
|
|
|
goto unlock;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* serialises with set_sseu */
|
|
|
|
err = intel_context_lock_pinned(ce);
|
|
|
|
if (err)
|
|
|
|
goto unlock;
|
|
|
|
|
|
|
|
clone->engines[n]->sseu = ce->sseu;
|
|
|
|
intel_context_unlock_pinned(ce);
|
|
|
|
}
|
|
|
|
|
|
|
|
err = 0;
|
|
|
|
unlock:
|
|
|
|
i915_gem_context_unlock_engines(src);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int clone_timeline(struct i915_gem_context *dst,
|
|
|
|
struct i915_gem_context *src)
|
|
|
|
{
|
2019-08-10 02:25:18 +08:00
|
|
|
if (src->timeline)
|
|
|
|
__assign_timeline(dst, src->timeline);
|
2019-05-22 05:11:29 +08:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int clone_vm(struct i915_gem_context *dst,
|
|
|
|
struct i915_gem_context *src)
|
|
|
|
{
|
2019-06-11 17:12:37 +08:00
|
|
|
struct i915_address_space *vm;
|
2019-10-04 21:40:09 +08:00
|
|
|
int err = 0;
|
2019-05-22 05:11:29 +08:00
|
|
|
|
2019-11-06 17:13:12 +08:00
|
|
|
if (!rcu_access_pointer(src->vm))
|
|
|
|
return 0;
|
2019-05-22 05:11:29 +08:00
|
|
|
|
2019-11-06 17:13:12 +08:00
|
|
|
rcu_read_lock();
|
|
|
|
vm = context_get_vm_rcu(src);
|
2019-05-22 05:11:29 +08:00
|
|
|
rcu_read_unlock();
|
|
|
|
|
2019-11-06 17:13:12 +08:00
|
|
|
if (!mutex_lock_interruptible(&dst->mutex)) {
|
|
|
|
__assign_ppgtt(dst, vm);
|
|
|
|
mutex_unlock(&dst->mutex);
|
|
|
|
} else {
|
|
|
|
err = -EINTR;
|
2019-05-22 05:11:29 +08:00
|
|
|
}
|
|
|
|
|
2019-11-06 17:13:12 +08:00
|
|
|
i915_vm_put(vm);
|
2019-10-04 21:40:09 +08:00
|
|
|
return err;
|
2019-05-22 05:11:29 +08:00
|
|
|
}
|
|
|
|
|
|
|
|
static int create_clone(struct i915_user_extension __user *ext, void *data)
|
|
|
|
{
|
|
|
|
static int (* const fn[])(struct i915_gem_context *dst,
|
|
|
|
struct i915_gem_context *src) = {
|
|
|
|
#define MAP(x, y) [ilog2(I915_CONTEXT_CLONE_##x)] = y
|
|
|
|
MAP(ENGINES, clone_engines),
|
|
|
|
MAP(FLAGS, clone_flags),
|
|
|
|
MAP(SCHEDATTR, clone_schedattr),
|
|
|
|
MAP(SSEU, clone_sseu),
|
|
|
|
MAP(TIMELINE, clone_timeline),
|
|
|
|
MAP(VM, clone_vm),
|
|
|
|
#undef MAP
|
|
|
|
};
|
|
|
|
struct drm_i915_gem_context_create_ext_clone local;
|
|
|
|
const struct create_ext *arg = data;
|
|
|
|
struct i915_gem_context *dst = arg->ctx;
|
|
|
|
struct i915_gem_context *src;
|
|
|
|
int err, bit;
|
|
|
|
|
|
|
|
if (copy_from_user(&local, ext, sizeof(local)))
|
|
|
|
return -EFAULT;
|
|
|
|
|
|
|
|
BUILD_BUG_ON(GENMASK(BITS_PER_TYPE(local.flags) - 1, ARRAY_SIZE(fn)) !=
|
|
|
|
I915_CONTEXT_CLONE_UNKNOWN);
|
|
|
|
|
|
|
|
if (local.flags & I915_CONTEXT_CLONE_UNKNOWN)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (local.rsvd)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
rcu_read_lock();
|
|
|
|
src = __i915_gem_context_lookup_rcu(arg->fpriv, local.clone_id);
|
|
|
|
rcu_read_unlock();
|
|
|
|
if (!src)
|
|
|
|
return -ENOENT;
|
|
|
|
|
|
|
|
GEM_BUG_ON(src == dst);
|
|
|
|
|
|
|
|
for (bit = 0; bit < ARRAY_SIZE(fn); bit++) {
|
|
|
|
if (!(local.flags & BIT(bit)))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
err = fn[bit](dst, src);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-03-22 17:23:24 +08:00
|
|
|
static const i915_user_extension_fn create_extensions[] = {
|
|
|
|
[I915_CONTEXT_CREATE_EXT_SETPARAM] = create_setparam,
|
2019-05-22 05:11:29 +08:00
|
|
|
[I915_CONTEXT_CREATE_EXT_CLONE] = create_clone,
|
2019-03-22 17:23:24 +08:00
|
|
|
};
|
|
|
|
|
|
|
|
static bool client_is_banned(struct drm_i915_file_private *file_priv)
|
|
|
|
{
|
|
|
|
return atomic_read(&file_priv->ban_score) >= I915_CLIENT_SCORE_BANNED;
|
|
|
|
}
|
|
|
|
|
|
|
|
int i915_gem_context_create_ioctl(struct drm_device *dev, void *data,
|
|
|
|
struct drm_file *file)
|
|
|
|
{
|
|
|
|
struct drm_i915_private *i915 = to_i915(dev);
|
|
|
|
struct drm_i915_gem_context_create_ext *args = data;
|
|
|
|
struct create_ext ext_data;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (!DRIVER_CAPS(i915)->has_logical_contexts)
|
|
|
|
return -ENODEV;
|
|
|
|
|
|
|
|
if (args->flags & I915_CONTEXT_CREATE_FLAGS_UNKNOWN)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2019-07-13 03:29:53 +08:00
|
|
|
ret = intel_gt_terminally_wedged(&i915->gt);
|
2019-03-22 17:23:24 +08:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
ext_data.fpriv = file->driver_priv;
|
|
|
|
if (client_is_banned(ext_data.fpriv)) {
|
|
|
|
DRM_DEBUG("client %s[%d] banned from creating ctx\n",
|
2019-12-18 01:09:33 +08:00
|
|
|
current->comm, task_pid_nr(current));
|
2019-03-22 17:23:24 +08:00
|
|
|
return -EIO;
|
|
|
|
}
|
|
|
|
|
2019-03-22 17:23:25 +08:00
|
|
|
ext_data.ctx = i915_gem_create_context(i915, args->flags);
|
2019-03-22 17:23:24 +08:00
|
|
|
if (IS_ERR(ext_data.ctx))
|
|
|
|
return PTR_ERR(ext_data.ctx);
|
|
|
|
|
|
|
|
if (args->flags & I915_CONTEXT_CREATE_FLAGS_USE_EXTENSIONS) {
|
|
|
|
ret = i915_user_extensions(u64_to_user_ptr(args->extensions),
|
|
|
|
create_extensions,
|
|
|
|
ARRAY_SIZE(create_extensions),
|
|
|
|
&ext_data);
|
|
|
|
if (ret)
|
|
|
|
goto err_ctx;
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = gem_context_register(ext_data.ctx, ext_data.fpriv);
|
|
|
|
if (ret < 0)
|
|
|
|
goto err_ctx;
|
|
|
|
|
|
|
|
args->ctx_id = ret;
|
|
|
|
DRM_DEBUG("HW context %d created\n", args->ctx_id);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
err_ctx:
|
|
|
|
context_close(ext_data.ctx);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
int i915_gem_context_destroy_ioctl(struct drm_device *dev, void *data,
|
|
|
|
struct drm_file *file)
|
|
|
|
{
|
|
|
|
struct drm_i915_gem_context_destroy *args = data;
|
|
|
|
struct drm_i915_file_private *file_priv = file->driver_priv;
|
|
|
|
struct i915_gem_context *ctx;
|
|
|
|
|
|
|
|
if (args->pad != 0)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (!args->ctx_id)
|
|
|
|
return -ENOENT;
|
|
|
|
|
|
|
|
if (mutex_lock_interruptible(&file_priv->context_idr_lock))
|
|
|
|
return -EINTR;
|
|
|
|
|
|
|
|
ctx = idr_remove(&file_priv->context_idr, args->ctx_id);
|
|
|
|
mutex_unlock(&file_priv->context_idr_lock);
|
|
|
|
if (!ctx)
|
|
|
|
return -ENOENT;
|
|
|
|
|
|
|
|
context_close(ctx);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int get_sseu(struct i915_gem_context *ctx,
|
|
|
|
struct drm_i915_gem_context_param *args)
|
|
|
|
{
|
|
|
|
struct drm_i915_gem_context_param_sseu user_sseu;
|
|
|
|
struct intel_context *ce;
|
2019-05-22 05:11:27 +08:00
|
|
|
unsigned long lookup;
|
2019-04-27 00:33:32 +08:00
|
|
|
int err;
|
2019-03-22 17:23:24 +08:00
|
|
|
|
|
|
|
if (args->size == 0)
|
|
|
|
goto out;
|
|
|
|
else if (args->size < sizeof(user_sseu))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (copy_from_user(&user_sseu, u64_to_user_ptr(args->value),
|
|
|
|
sizeof(user_sseu)))
|
|
|
|
return -EFAULT;
|
|
|
|
|
2019-05-22 05:11:27 +08:00
|
|
|
if (user_sseu.rsvd)
|
2019-03-22 17:23:24 +08:00
|
|
|
return -EINVAL;
|
|
|
|
|
2019-05-22 05:11:27 +08:00
|
|
|
if (user_sseu.flags & ~(I915_CONTEXT_SSEU_FLAG_ENGINE_INDEX))
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
lookup = 0;
|
|
|
|
if (user_sseu.flags & I915_CONTEXT_SSEU_FLAG_ENGINE_INDEX)
|
|
|
|
lookup |= LOOKUP_USER_INDEX;
|
|
|
|
|
|
|
|
ce = lookup_user_engine(ctx, lookup, &user_sseu.engine);
|
2019-03-22 17:23:24 +08:00
|
|
|
if (IS_ERR(ce))
|
|
|
|
return PTR_ERR(ce);
|
|
|
|
|
2019-04-27 00:33:32 +08:00
|
|
|
err = intel_context_lock_pinned(ce); /* serialises with set_sseu */
|
|
|
|
if (err) {
|
|
|
|
intel_context_put(ce);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2019-03-22 17:23:24 +08:00
|
|
|
user_sseu.slice_mask = ce->sseu.slice_mask;
|
|
|
|
user_sseu.subslice_mask = ce->sseu.subslice_mask;
|
|
|
|
user_sseu.min_eus_per_subslice = ce->sseu.min_eus_per_subslice;
|
|
|
|
user_sseu.max_eus_per_subslice = ce->sseu.max_eus_per_subslice;
|
|
|
|
|
2019-04-27 00:33:32 +08:00
|
|
|
intel_context_unlock_pinned(ce);
|
|
|
|
intel_context_put(ce);
|
2019-03-22 17:23:24 +08:00
|
|
|
|
|
|
|
if (copy_to_user(u64_to_user_ptr(args->value), &user_sseu,
|
|
|
|
sizeof(user_sseu)))
|
|
|
|
return -EFAULT;
|
|
|
|
|
|
|
|
out:
|
|
|
|
args->size = sizeof(user_sseu);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
int i915_gem_context_getparam_ioctl(struct drm_device *dev, void *data,
|
|
|
|
struct drm_file *file)
|
|
|
|
{
|
|
|
|
struct drm_i915_file_private *file_priv = file->driver_priv;
|
|
|
|
struct drm_i915_gem_context_param *args = data;
|
|
|
|
struct i915_gem_context *ctx;
|
|
|
|
int ret = 0;
|
|
|
|
|
|
|
|
ctx = i915_gem_context_lookup(file_priv, args->ctx_id);
|
|
|
|
if (!ctx)
|
|
|
|
return -ENOENT;
|
|
|
|
|
|
|
|
switch (args->param) {
|
|
|
|
case I915_CONTEXT_PARAM_NO_ZEROMAP:
|
|
|
|
args->size = 0;
|
|
|
|
args->value = test_bit(UCONTEXT_NO_ZEROMAP, &ctx->user_flags);
|
|
|
|
break;
|
|
|
|
|
|
|
|
case I915_CONTEXT_PARAM_GTT_SIZE:
|
|
|
|
args->size = 0;
|
2019-10-04 21:40:09 +08:00
|
|
|
rcu_read_lock();
|
|
|
|
if (rcu_access_pointer(ctx->vm))
|
|
|
|
args->value = rcu_dereference(ctx->vm)->total;
|
2019-03-22 17:23:24 +08:00
|
|
|
else
|
|
|
|
args->value = to_i915(dev)->ggtt.vm.total;
|
2019-10-04 21:40:09 +08:00
|
|
|
rcu_read_unlock();
|
2019-03-22 17:23:24 +08:00
|
|
|
break;
|
|
|
|
|
|
|
|
case I915_CONTEXT_PARAM_NO_ERROR_CAPTURE:
|
|
|
|
args->size = 0;
|
|
|
|
args->value = i915_gem_context_no_error_capture(ctx);
|
|
|
|
break;
|
|
|
|
|
|
|
|
case I915_CONTEXT_PARAM_BANNABLE:
|
|
|
|
args->size = 0;
|
|
|
|
args->value = i915_gem_context_is_bannable(ctx);
|
|
|
|
break;
|
|
|
|
|
|
|
|
case I915_CONTEXT_PARAM_RECOVERABLE:
|
|
|
|
args->size = 0;
|
|
|
|
args->value = i915_gem_context_is_recoverable(ctx);
|
|
|
|
break;
|
|
|
|
|
|
|
|
case I915_CONTEXT_PARAM_PRIORITY:
|
|
|
|
args->size = 0;
|
|
|
|
args->value = ctx->sched.priority >> I915_USER_PRIORITY_SHIFT;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case I915_CONTEXT_PARAM_SSEU:
|
|
|
|
ret = get_sseu(ctx, args);
|
|
|
|
break;
|
|
|
|
|
|
|
|
case I915_CONTEXT_PARAM_VM:
|
2019-03-30 18:03:49 +08:00
|
|
|
ret = get_ppgtt(file_priv, ctx, args);
|
2019-03-22 17:23:24 +08:00
|
|
|
break;
|
|
|
|
|
drm/i915: Allow a context to define its set of engines
Over the last few years, we have debated how to extend the user API to
support an increase in the number of engines, that may be sparse and
even be heterogeneous within a class (not all video decoders created
equal). We settled on using (class, instance) tuples to identify a
specific engine, with an API for the user to construct a map of engines
to capabilities. Into this picture, we then add a challenge of virtual
engines; one user engine that maps behind the scenes to any number of
physical engines. To keep it general, we want the user to have full
control over that mapping. To that end, we allow the user to constrain a
context to define the set of engines that it can access, order fully
controlled by the user via (class, instance). With such precise control
in context setup, we can continue to use the existing execbuf uABI of
specifying a single index; only now it doesn't automagically map onto
the engines, it uses the user defined engine map from the context.
v2: Fixup freeing of local on success of get_engines()
v3: Allow empty engines[]
v4: s/nengine/num_engines/
v5: Replace 64 limit on num_engines with a note that execbuf is
currently limited to only using the first 64 engines.
v6: Actually use the engines_mutex to guard the ctx->engines.
Testcase: igt/gem_ctx_engines
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190521211134.16117-2-chris@chris-wilson.co.uk
2019-05-22 05:11:26 +08:00
|
|
|
case I915_CONTEXT_PARAM_ENGINES:
|
|
|
|
ret = get_engines(ctx, args);
|
|
|
|
break;
|
|
|
|
|
drm/i915/gem: Make context persistence optional
Our existing behaviour is to allow contexts and their GPU requests to
persist past the point of closure until the requests are complete. This
allows clients to operate in a 'fire-and-forget' manner where they can
setup a rendering pipeline and hand it over to the display server and
immediately exit. As the rendering pipeline is kept alive until
completion, the display server (or other consumer) can use the results
in the future and present them to the user.
The compute model is a little different. They have little to no buffer
sharing between processes as their kernels tend to operate on a
continuous stream, feeding the results back to the client application.
These kernels operate for an indeterminate length of time, with many
clients wishing that the kernel was always running for as long as they
keep feeding in the data, i.e. acting like a DSP.
Not all clients want this persistent "desktop" behaviour and would prefer
that the contexts are cleaned up immediately upon closure. This ensures
that when clients are run without hangchecking (e.g. for compute kernels
of indeterminate runtime), any GPU hang or other unexpected workloads
are terminated with the process and does not continue to hog resources.
The default behaviour for new contexts is the legacy persistence mode,
as some desktop applications are dependent upon the existing behaviour.
New clients will have to opt in to immediate cleanup on context
closure. If the hangchecking modparam is disabled, so is persistent
context support -- all contexts will be terminated on closure.
We expect this behaviour change to be welcomed by compute users, who
have often been caught between a rock and a hard place. They disable
hangchecking to avoid their kernels being "unfairly" declared hung, but
have also experienced true hangs that the system was then unable to
clean up. Naturally, this leads to bug reports.
Testcase: igt/gem_ctx_persistence
Link: https://github.com/intel/compute-runtime/pull/228
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Cc: Michał Winiarski <michal.winiarski@intel.com>
Cc: Jon Bloomfield <jon.bloomfield@intel.com>
Reviewed-by: Jon Bloomfield <jon.bloomfield@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Acked-by: Jason Ekstrand <jason@jlekstrand.net>
Link: https://patchwork.freedesktop.org/patch/msgid/20191029202338.8841-1-chris@chris-wilson.co.uk
2019-10-30 04:23:38 +08:00
|
|
|
case I915_CONTEXT_PARAM_PERSISTENCE:
|
|
|
|
args->size = 0;
|
|
|
|
args->value = i915_gem_context_is_persistent(ctx);
|
|
|
|
break;
|
|
|
|
|
2019-03-22 17:23:24 +08:00
|
|
|
case I915_CONTEXT_PARAM_BAN_PERIOD:
|
|
|
|
default:
|
|
|
|
ret = -EINVAL;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
i915_gem_context_put(ctx);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
int i915_gem_context_setparam_ioctl(struct drm_device *dev, void *data,
|
|
|
|
struct drm_file *file)
|
|
|
|
{
|
|
|
|
struct drm_i915_file_private *file_priv = file->driver_priv;
|
|
|
|
struct drm_i915_gem_context_param *args = data;
|
|
|
|
struct i915_gem_context *ctx;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
ctx = i915_gem_context_lookup(file_priv, args->ctx_id);
|
|
|
|
if (!ctx)
|
|
|
|
return -ENOENT;
|
|
|
|
|
2019-03-30 18:03:49 +08:00
|
|
|
ret = ctx_setparam(file_priv, ctx, args);
|
2019-03-22 17:23:24 +08:00
|
|
|
|
2017-06-20 19:05:47 +08:00
|
|
|
i915_gem_context_put(ctx);
|
2014-12-25 00:13:40 +08:00
|
|
|
return ret;
|
|
|
|
}
|
2016-05-13 18:57:19 +08:00
|
|
|
|
|
|
|
int i915_gem_context_reset_stats_ioctl(struct drm_device *dev,
|
|
|
|
void *data, struct drm_file *file)
|
|
|
|
{
|
2019-10-04 21:40:09 +08:00
|
|
|
struct drm_i915_private *i915 = to_i915(dev);
|
2016-05-13 18:57:19 +08:00
|
|
|
struct drm_i915_reset_stats *args = data;
|
2016-05-24 21:53:34 +08:00
|
|
|
struct i915_gem_context *ctx;
|
2016-05-13 18:57:19 +08:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (args->flags || args->pad)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2017-06-20 19:05:47 +08:00
|
|
|
ret = -ENOENT;
|
|
|
|
rcu_read_lock();
|
|
|
|
ctx = __i915_gem_context_lookup_rcu(file->driver_priv, args->ctx_id);
|
|
|
|
if (!ctx)
|
|
|
|
goto out;
|
2016-05-13 18:57:19 +08:00
|
|
|
|
2017-06-20 19:05:47 +08:00
|
|
|
/*
|
|
|
|
* We opt for unserialised reads here. This may result in tearing
|
|
|
|
* in the extremely unlikely event of a GPU hang on this context
|
|
|
|
* as we are querying them. If we need that extra layer of protection,
|
|
|
|
* we should wrap the hangstats with a seqlock.
|
|
|
|
*/
|
2016-05-13 18:57:19 +08:00
|
|
|
|
|
|
|
if (capable(CAP_SYS_ADMIN))
|
2019-10-04 21:40:09 +08:00
|
|
|
args->reset_count = i915_reset_count(&i915->gpu_error);
|
2016-05-13 18:57:19 +08:00
|
|
|
else
|
|
|
|
args->reset_count = 0;
|
|
|
|
|
2017-07-21 20:32:30 +08:00
|
|
|
args->batch_active = atomic_read(&ctx->guilty_count);
|
|
|
|
args->batch_pending = atomic_read(&ctx->active_count);
|
2016-05-13 18:57:19 +08:00
|
|
|
|
2017-06-20 19:05:47 +08:00
|
|
|
ret = 0;
|
|
|
|
out:
|
|
|
|
rcu_read_unlock();
|
|
|
|
return ret;
|
2016-05-13 18:57:19 +08:00
|
|
|
}
|
2017-02-14 01:15:19 +08:00
|
|
|
|
2019-04-27 00:33:34 +08:00
|
|
|
/* GEM context-engines iterator: for_each_gem_engine() */
|
|
|
|
struct intel_context *
|
|
|
|
i915_gem_engines_iter_next(struct i915_gem_engines_iter *it)
|
|
|
|
{
|
|
|
|
const struct i915_gem_engines *e = it->engines;
|
|
|
|
struct intel_context *ctx;
|
|
|
|
|
|
|
|
do {
|
|
|
|
if (it->idx >= e->num_engines)
|
|
|
|
return NULL;
|
|
|
|
|
|
|
|
ctx = e->engines[it->idx++];
|
|
|
|
} while (!ctx);
|
|
|
|
|
|
|
|
return ctx;
|
|
|
|
}
|
|
|
|
|
2017-02-14 01:15:19 +08:00
|
|
|
#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
|
|
|
|
#include "selftests/mock_context.c"
|
2017-02-14 01:15:49 +08:00
|
|
|
#include "selftests/i915_gem_context.c"
|
2017-02-14 01:15:19 +08:00
|
|
|
#endif
|
2019-02-28 18:20:34 +08:00
|
|
|
|
2019-03-08 21:25:19 +08:00
|
|
|
static void i915_global_gem_context_shrink(void)
|
2019-02-28 18:20:34 +08:00
|
|
|
{
|
2019-03-06 05:38:30 +08:00
|
|
|
kmem_cache_shrink(global.slab_luts);
|
2019-02-28 18:20:34 +08:00
|
|
|
}
|
|
|
|
|
2019-03-08 21:25:19 +08:00
|
|
|
static void i915_global_gem_context_exit(void)
|
2019-02-28 18:20:34 +08:00
|
|
|
{
|
2019-03-06 05:38:30 +08:00
|
|
|
kmem_cache_destroy(global.slab_luts);
|
2019-02-28 18:20:34 +08:00
|
|
|
}
|
|
|
|
|
2019-03-08 21:25:19 +08:00
|
|
|
static struct i915_global_gem_context global = { {
|
|
|
|
.shrink = i915_global_gem_context_shrink,
|
|
|
|
.exit = i915_global_gem_context_exit,
|
2019-03-06 05:38:30 +08:00
|
|
|
} };
|
|
|
|
|
2019-03-08 21:25:19 +08:00
|
|
|
int __init i915_global_gem_context_init(void)
|
2019-02-28 18:20:34 +08:00
|
|
|
{
|
2019-03-06 05:38:30 +08:00
|
|
|
global.slab_luts = KMEM_CACHE(i915_lut_handle, 0);
|
|
|
|
if (!global.slab_luts)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
i915_global_register(&global.base);
|
|
|
|
return 0;
|
2019-02-28 18:20:34 +08:00
|
|
|
}
|