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 04:42:42 +07:00
|
|
|
/*
|
|
|
|
* Copyright © 2011-2012 Intel Corporation
|
|
|
|
*
|
|
|
|
* Permission is hereby granted, free of charge, to any person obtaining a
|
|
|
|
* copy of this software and associated documentation files (the "Software"),
|
|
|
|
* to deal in the Software without restriction, including without limitation
|
|
|
|
* the rights to use, copy, modify, merge, publish, distribute, sublicense,
|
|
|
|
* and/or sell copies of the Software, and to permit persons to whom the
|
|
|
|
* Software is furnished to do so, subject to the following conditions:
|
|
|
|
*
|
|
|
|
* The above copyright notice and this permission notice (including the next
|
|
|
|
* paragraph) shall be included in all copies or substantial portions of the
|
|
|
|
* Software.
|
|
|
|
*
|
|
|
|
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
|
|
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
|
|
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
|
|
|
|
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
|
|
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
|
|
|
|
* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
|
|
|
|
* IN THE SOFTWARE.
|
|
|
|
*
|
|
|
|
* Authors:
|
|
|
|
* Ben Widawsky <ben@bwidawsk.net>
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* 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 20:40:26 +07: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 04:42:42 +07: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 21:05:16 +07:00
|
|
|
#include <linux/log2.h>
|
2012-10-03 00:01:07 +07:00
|
|
|
#include <drm/i915_drm.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 04:42:42 +07:00
|
|
|
#include "i915_drv.h"
|
2019-03-06 04:38:30 +07:00
|
|
|
#include "i915_globals.h"
|
2014-11-10 20:44:31 +07:00
|
|
|
#include "i915_trace.h"
|
2019-03-22 16:23:23 +07:00
|
|
|
#include "i915_user_extensions.h"
|
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 16:50:31 +07:00
|
|
|
#include "intel_lrc_reg.h"
|
2018-04-10 23:12:47 +07:00
|
|
|
#include "intel_workarounds.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 04:42:42 +07:00
|
|
|
|
2019-03-27 17:58:14 +07:00
|
|
|
#define I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE (1 << 1)
|
|
|
|
#define I915_CONTEXT_PARAM_VM 0x9
|
|
|
|
|
2016-04-28 15:56:41 +07:00
|
|
|
#define ALL_L3_SLICES(dev) (1 << NUM_L3_SLICES(dev)) - 1
|
|
|
|
|
2019-03-08 20:25:19 +07:00
|
|
|
static struct i915_global_gem_context {
|
2019-03-06 04:38:30 +07:00
|
|
|
struct i915_global base;
|
2019-02-28 17:20:34 +07: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 15:52:08 +07:00
|
|
|
static void lut_close(struct i915_gem_context *ctx)
|
2017-06-16 21:05:16 +07:00
|
|
|
{
|
2017-08-16 15:52:08 +07:00
|
|
|
struct i915_lut_handle *lut, *ln;
|
|
|
|
struct radix_tree_iter iter;
|
|
|
|
void __rcu **slot;
|
|
|
|
|
|
|
|
list_for_each_entry_safe(lut, ln, &ctx->handles_list, ctx_link) {
|
|
|
|
list_del(&lut->obj_link);
|
2019-02-28 17:20:34 +07:00
|
|
|
i915_lut_handle_free(lut);
|
2017-06-16 21:05:16 +07:00
|
|
|
}
|
2019-03-22 16:23:23 +07:00
|
|
|
INIT_LIST_HEAD(&ctx->handles_list);
|
2017-06-16 21:05:16 +07:00
|
|
|
|
2017-10-26 20:00:32 +07:00
|
|
|
rcu_read_lock();
|
2017-08-16 15:52:08 +07:00
|
|
|
radix_tree_for_each_slot(slot, &ctx->handles_vma, &iter, 0) {
|
|
|
|
struct i915_vma *vma = rcu_dereference_raw(*slot);
|
2017-06-16 21:05:16 +07:00
|
|
|
|
2017-08-16 15:52:08 +07:00
|
|
|
radix_tree_iter_delete(&ctx->handles_vma, &iter, slot);
|
2019-03-22 16:23:23 +07:00
|
|
|
|
|
|
|
vma->open_count--;
|
2017-11-09 15:55:40 +07:00
|
|
|
__i915_gem_object_release_unless_active(vma->obj);
|
2017-06-16 21:05:16 +07:00
|
|
|
}
|
2017-10-26 20:00:32 +07:00
|
|
|
rcu_read_unlock();
|
2017-06-16 21:05:16 +07:00
|
|
|
}
|
|
|
|
|
2018-09-04 22:31:17 +07:00
|
|
|
static inline int new_hw_id(struct drm_i915_private *i915, gfp_t gfp)
|
|
|
|
{
|
|
|
|
unsigned int max;
|
|
|
|
|
|
|
|
lockdep_assert_held(&i915->contexts.mutex);
|
|
|
|
|
|
|
|
if (INTEL_GEN(i915) >= 11)
|
|
|
|
max = GEN11_MAX_CONTEXT_HW_ID;
|
|
|
|
else if (USES_GUC_SUBMISSION(i915))
|
|
|
|
/*
|
|
|
|
* When using GuC in proxy submission, GuC consumes the
|
|
|
|
* highest bit in the context id to indicate proxy submission.
|
|
|
|
*/
|
|
|
|
max = MAX_GUC_CONTEXT_HW_ID;
|
|
|
|
else
|
|
|
|
max = MAX_CONTEXT_HW_ID;
|
|
|
|
|
|
|
|
return ida_simple_get(&i915->contexts.hw_ida, 0, max, gfp);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int steal_hw_id(struct drm_i915_private *i915)
|
|
|
|
{
|
|
|
|
struct i915_gem_context *ctx, *cn;
|
|
|
|
LIST_HEAD(pinned);
|
|
|
|
int id = -ENOSPC;
|
|
|
|
|
|
|
|
lockdep_assert_held(&i915->contexts.mutex);
|
|
|
|
|
|
|
|
list_for_each_entry_safe(ctx, cn,
|
|
|
|
&i915->contexts.hw_id_list, hw_id_link) {
|
|
|
|
if (atomic_read(&ctx->hw_id_pin_count)) {
|
|
|
|
list_move_tail(&ctx->hw_id_link, &pinned);
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
|
|
|
|
GEM_BUG_ON(!ctx->hw_id); /* perma-pinned kernel context */
|
|
|
|
list_del_init(&ctx->hw_id_link);
|
|
|
|
id = ctx->hw_id;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Remember how far we got up on the last repossesion scan, so the
|
|
|
|
* list is kept in a "least recently scanned" order.
|
|
|
|
*/
|
|
|
|
list_splice_tail(&pinned, &i915->contexts.hw_id_list);
|
|
|
|
return id;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int assign_hw_id(struct drm_i915_private *i915, unsigned int *out)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
lockdep_assert_held(&i915->contexts.mutex);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We prefer to steal/stall ourselves and our users over that of the
|
|
|
|
* entire system. That may be a little unfair to our users, and
|
|
|
|
* even hurt high priority clients. The choice is whether to oomkill
|
|
|
|
* something else, or steal a context id.
|
|
|
|
*/
|
|
|
|
ret = new_hw_id(i915, GFP_KERNEL | __GFP_RETRY_MAYFAIL | __GFP_NOWARN);
|
|
|
|
if (unlikely(ret < 0)) {
|
|
|
|
ret = steal_hw_id(i915);
|
|
|
|
if (ret < 0) /* once again for the correct errno code */
|
|
|
|
ret = new_hw_id(i915, GFP_KERNEL);
|
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
*out = ret;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void release_hw_id(struct i915_gem_context *ctx)
|
|
|
|
{
|
|
|
|
struct drm_i915_private *i915 = ctx->i915;
|
|
|
|
|
|
|
|
if (list_empty(&ctx->hw_id_link))
|
|
|
|
return;
|
|
|
|
|
|
|
|
mutex_lock(&i915->contexts.mutex);
|
|
|
|
if (!list_empty(&ctx->hw_id_link)) {
|
|
|
|
ida_simple_remove(&i915->contexts.hw_ida, ctx->hw_id);
|
|
|
|
list_del_init(&ctx->hw_id_link);
|
|
|
|
}
|
|
|
|
mutex_unlock(&i915->contexts.mutex);
|
|
|
|
}
|
|
|
|
|
2017-06-20 18:05:46 +07:00
|
|
|
static void i915_gem_context_free(struct i915_gem_context *ctx)
|
2012-06-05 04:42:43 +07:00
|
|
|
{
|
2019-03-08 20:25:19 +07:00
|
|
|
struct intel_context *it, *n;
|
2012-06-05 04:42:43 +07:00
|
|
|
|
2016-07-05 16:40:23 +07:00
|
|
|
lockdep_assert_held(&ctx->i915->drm.struct_mutex);
|
2016-12-31 18:20:11 +07:00
|
|
|
GEM_BUG_ON(!i915_gem_context_is_closed(ctx));
|
2019-03-08 20:25:16 +07:00
|
|
|
GEM_BUG_ON(!list_empty(&ctx->active_engines));
|
2014-11-10 20:44:31 +07:00
|
|
|
|
2018-09-04 22:31:17 +07:00
|
|
|
release_hw_id(ctx);
|
2014-08-06 20:04:53 +07:00
|
|
|
i915_ppgtt_put(ctx->ppgtt);
|
|
|
|
|
2019-03-08 20:25:19 +07:00
|
|
|
rbtree_postorder_for_each_entry_safe(it, n, &ctx->hw_contexts, node)
|
2019-03-19 04:23:47 +07:00
|
|
|
intel_context_put(it);
|
2016-05-24 20:53:41 +07:00
|
|
|
|
2019-03-22 16:23:25 +07:00
|
|
|
if (ctx->timeline)
|
|
|
|
i915_timeline_put(ctx->timeline);
|
|
|
|
|
2016-10-28 19:58:54 +07:00
|
|
|
kfree(ctx->name);
|
2016-08-15 16:49:08 +07:00
|
|
|
put_pid(ctx->pid);
|
2017-06-16 21:05:16 +07:00
|
|
|
|
drm/i915: Add VM to context
Pretty straightforward so far except for the bit about the refcounting.
The PPGTT will potentially be shared amongst multiple contexts. Because
contexts themselves have a refcounted lifecycle, the easiest way to
manage this will be to refcount the PPGTT. To acheive this, we piggy
back off of the existing context refcount, and will increment and
decrement the PPGTT refcount with context creation, and destruction.
To put it more clearly, if context A, and context B both use PPGTT 0, we
can't free the PPGTT until both A, and B are destroyed.
Note that because the PPGTT is permanently pinned (for now), it really
just matters for the PPGTT destruction, as opposed to making space under
memory pressure.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-07 05:11:15 +07:00
|
|
|
list_del(&ctx->link);
|
2019-03-08 20:25:16 +07:00
|
|
|
mutex_destroy(&ctx->mutex);
|
2016-04-28 15:56:51 +07:00
|
|
|
|
2017-06-20 18:05:47 +07:00
|
|
|
kfree_rcu(ctx, rcu);
|
2012-06-05 04:42:43 +07:00
|
|
|
}
|
|
|
|
|
2017-06-20 18:05:46 +07:00
|
|
|
static void contexts_free(struct drm_i915_private *i915)
|
|
|
|
{
|
|
|
|
struct llist_node *freed = llist_del_all(&i915->contexts.free_list);
|
2017-07-01 06:05:17 +07:00
|
|
|
struct i915_gem_context *ctx, *cn;
|
2017-06-20 18:05:46 +07:00
|
|
|
|
|
|
|
lockdep_assert_held(&i915->drm.struct_mutex);
|
|
|
|
|
2017-07-01 06:05:17 +07:00
|
|
|
llist_for_each_entry_safe(ctx, cn, freed, free_link)
|
2017-06-20 18:05:46 +07:00
|
|
|
i915_gem_context_free(ctx);
|
|
|
|
}
|
|
|
|
|
2017-07-05 21:26:34 +07:00
|
|
|
static void contexts_free_first(struct drm_i915_private *i915)
|
|
|
|
{
|
|
|
|
struct i915_gem_context *ctx;
|
|
|
|
struct llist_node *freed;
|
|
|
|
|
|
|
|
lockdep_assert_held(&i915->drm.struct_mutex);
|
|
|
|
|
|
|
|
freed = llist_del_first(&i915->contexts.free_list);
|
|
|
|
if (!freed)
|
|
|
|
return;
|
|
|
|
|
|
|
|
ctx = container_of(freed, typeof(*ctx), free_link);
|
|
|
|
i915_gem_context_free(ctx);
|
|
|
|
}
|
|
|
|
|
2017-06-20 18:05:46 +07:00
|
|
|
static void contexts_free_worker(struct work_struct *work)
|
|
|
|
{
|
|
|
|
struct drm_i915_private *i915 =
|
|
|
|
container_of(work, typeof(*i915), contexts.free_work);
|
|
|
|
|
|
|
|
mutex_lock(&i915->drm.struct_mutex);
|
|
|
|
contexts_free(i915);
|
|
|
|
mutex_unlock(&i915->drm.struct_mutex);
|
|
|
|
}
|
|
|
|
|
|
|
|
void i915_gem_context_release(struct kref *ref)
|
|
|
|
{
|
|
|
|
struct i915_gem_context *ctx = container_of(ref, typeof(*ctx), ref);
|
|
|
|
struct drm_i915_private *i915 = ctx->i915;
|
|
|
|
|
|
|
|
trace_i915_context_free(ctx);
|
|
|
|
if (llist_add(&ctx->free_link, &i915->contexts.free_list))
|
|
|
|
queue_work(i915->wq, &i915->contexts.free_work);
|
|
|
|
}
|
|
|
|
|
2016-08-04 13:52:46 +07:00
|
|
|
static void context_close(struct i915_gem_context *ctx)
|
|
|
|
{
|
2016-12-31 18:20:11 +07:00
|
|
|
i915_gem_context_set_closed(ctx);
|
2017-08-16 15:52:08 +07:00
|
|
|
|
2018-09-04 22:31:17 +07:00
|
|
|
/*
|
|
|
|
* This context will never again be assinged to HW, so we can
|
|
|
|
* reuse its ID for the next context.
|
|
|
|
*/
|
|
|
|
release_hw_id(ctx);
|
|
|
|
|
2017-11-09 15:55:40 +07: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 15:52:08 +07:00
|
|
|
lut_close(ctx);
|
|
|
|
|
2016-08-04 13:52:46 +07:00
|
|
|
ctx->file_priv = ERR_PTR(-EBADF);
|
|
|
|
i915_gem_context_put(ctx);
|
|
|
|
}
|
|
|
|
|
2017-02-09 21:40:36 +07:00
|
|
|
static u32 default_desc_template(const struct drm_i915_private *i915,
|
|
|
|
const struct i915_hw_ppgtt *ppgtt)
|
2017-01-27 20:03:09 +07:00
|
|
|
{
|
2017-02-09 21:40:36 +07:00
|
|
|
u32 address_mode;
|
2017-01-27 20:03:09 +07:00
|
|
|
u32 desc;
|
|
|
|
|
2017-02-09 21:40:36 +07:00
|
|
|
desc = GEN8_CTX_VALID | GEN8_CTX_PRIVILEGE;
|
2017-01-27 20:03:09 +07:00
|
|
|
|
2017-02-09 21:40:36 +07:00
|
|
|
address_mode = INTEL_LEGACY_32B_CONTEXT;
|
2019-03-15 05:38:38 +07:00
|
|
|
if (ppgtt && i915_vm_is_4lvl(&ppgtt->vm))
|
2017-02-09 21:40:36 +07:00
|
|
|
address_mode = INTEL_LEGACY_64B_CONTEXT;
|
|
|
|
desc |= address_mode << GEN8_CTX_ADDRESSING_MODE_SHIFT;
|
|
|
|
|
drm/i915: replace IS_GEN<N> with IS_GEN(..., N)
Define IS_GEN() similarly to our IS_GEN_RANGE(). but use gen instead of
gen_mask to do the comparison. Now callers can pass then gen as a parameter,
so we don't require one macro for each gen.
The following spatch was used to convert the users of these macros:
@@
expression e;
@@
(
- IS_GEN2(e)
+ IS_GEN(e, 2)
|
- IS_GEN3(e)
+ IS_GEN(e, 3)
|
- IS_GEN4(e)
+ IS_GEN(e, 4)
|
- IS_GEN5(e)
+ IS_GEN(e, 5)
|
- IS_GEN6(e)
+ IS_GEN(e, 6)
|
- IS_GEN7(e)
+ IS_GEN(e, 7)
|
- IS_GEN8(e)
+ IS_GEN(e, 8)
|
- IS_GEN9(e)
+ IS_GEN(e, 9)
|
- IS_GEN10(e)
+ IS_GEN(e, 10)
|
- IS_GEN11(e)
+ IS_GEN(e, 11)
)
v2: use IS_GEN rather than GT_GEN and compare to info.gen rather than
using the bitmask
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181212181044.15886-2-lucas.demarchi@intel.com
2018-12-13 01:10:43 +07:00
|
|
|
if (IS_GEN(i915, 8))
|
2017-01-27 20:03:09 +07:00
|
|
|
desc |= GEN8_CTX_L3LLC_COHERENT;
|
|
|
|
|
|
|
|
/* TODO: WaDisableLiteRestore when we start using semaphore
|
|
|
|
* signalling between Command Streamers
|
|
|
|
* ring->ctx_desc_template |= GEN8_CTX_FORCE_RESTORE;
|
|
|
|
*/
|
|
|
|
|
|
|
|
return desc;
|
|
|
|
}
|
|
|
|
|
2016-05-24 20:53:34 +07:00
|
|
|
static struct i915_gem_context *
|
2019-03-21 21:07:08 +07:00
|
|
|
__create_context(struct drm_i915_private *dev_priv)
|
2012-06-05 04:42:43 +07:00
|
|
|
{
|
2016-05-24 20:53:34 +07:00
|
|
|
struct i915_gem_context *ctx;
|
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 19:21:52 +07:00
|
|
|
int i;
|
2012-06-05 04:42:43 +07:00
|
|
|
|
2012-11-11 01:56:04 +07:00
|
|
|
ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
|
2019-03-21 21:07:08 +07:00
|
|
|
if (!ctx)
|
2012-06-30 00:30:39 +07:00
|
|
|
return ERR_PTR(-ENOMEM);
|
2012-06-05 04:42:43 +07:00
|
|
|
|
2013-04-30 17:30:33 +07:00
|
|
|
kref_init(&ctx->ref);
|
2017-06-20 18:05:45 +07:00
|
|
|
list_add_tail(&ctx->link, &dev_priv->contexts.list);
|
2015-05-05 15:17:29 +07:00
|
|
|
ctx->i915 = dev_priv;
|
2018-10-01 19:32:03 +07:00
|
|
|
ctx->sched.priority = I915_USER_PRIORITY(I915_PRIORITY_NORMAL);
|
2019-03-08 20:25:16 +07:00
|
|
|
INIT_LIST_HEAD(&ctx->active_engines);
|
|
|
|
mutex_init(&ctx->mutex);
|
2012-06-05 04:42:43 +07:00
|
|
|
|
2019-03-08 20:25:19 +07:00
|
|
|
ctx->hw_contexts = RB_ROOT;
|
|
|
|
spin_lock_init(&ctx->hw_contexts_lock);
|
2018-05-18 04:26:32 +07:00
|
|
|
|
2017-08-16 15:52:08 +07:00
|
|
|
INIT_RADIX_TREE(&ctx->handles_vma, GFP_KERNEL);
|
|
|
|
INIT_LIST_HEAD(&ctx->handles_list);
|
2018-09-04 22:31:17 +07:00
|
|
|
INIT_LIST_HEAD(&ctx->hw_id_link);
|
2017-06-16 21:05:16 +07: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 09:03:18 +07: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. */
|
2016-04-28 15:56:41 +07:00
|
|
|
ctx->remap_slice = ALL_L3_SLICES(dev_priv);
|
2012-06-05 04:42:43 +07:00
|
|
|
|
2016-12-31 18:20:11 +07:00
|
|
|
i915_gem_context_set_bannable(ctx);
|
2019-02-18 17:58:21 +07:00
|
|
|
i915_gem_context_set_recoverable(ctx);
|
|
|
|
|
2016-06-16 19:07:01 +07:00
|
|
|
ctx->ring_size = 4 * PAGE_SIZE;
|
2017-02-09 21:40:36 +07:00
|
|
|
ctx->desc_template =
|
|
|
|
default_desc_template(dev_priv, dev_priv->mm.aliasing_ppgtt);
|
2014-12-24 23:13:39 +07: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 19:21:52 +07:00
|
|
|
for (i = 0; i < ARRAY_SIZE(ctx->hang_timestamp); i++)
|
|
|
|
ctx->hang_timestamp[i] = jiffies - CONTEXT_FAST_HANG_JIFFIES;
|
|
|
|
|
2012-06-30 00:30:39 +07:00
|
|
|
return ctx;
|
2017-02-09 18:34:25 +07:00
|
|
|
}
|
|
|
|
|
2019-03-22 16:23:23 +07:00
|
|
|
static struct i915_hw_ppgtt *
|
|
|
|
__set_ppgtt(struct i915_gem_context *ctx, struct i915_hw_ppgtt *ppgtt)
|
|
|
|
{
|
|
|
|
struct i915_hw_ppgtt *old = ctx->ppgtt;
|
|
|
|
|
|
|
|
ctx->ppgtt = i915_ppgtt_get(ppgtt);
|
|
|
|
ctx->desc_template = default_desc_template(ctx->i915, ppgtt);
|
|
|
|
|
|
|
|
return old;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void __assign_ppgtt(struct i915_gem_context *ctx,
|
|
|
|
struct i915_hw_ppgtt *ppgtt)
|
|
|
|
{
|
|
|
|
if (ppgtt == ctx->ppgtt)
|
|
|
|
return;
|
|
|
|
|
|
|
|
ppgtt = __set_ppgtt(ctx, ppgtt);
|
|
|
|
if (ppgtt)
|
|
|
|
i915_ppgtt_put(ppgtt);
|
|
|
|
}
|
|
|
|
|
2016-05-24 20:53:34 +07:00
|
|
|
static struct i915_gem_context *
|
2019-03-22 16:23:25 +07:00
|
|
|
i915_gem_create_context(struct drm_i915_private *dev_priv, 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 04:42:42 +07:00
|
|
|
{
|
2016-05-24 20:53:34 +07:00
|
|
|
struct i915_gem_context *ctx;
|
2012-06-05 04:42:43 +07:00
|
|
|
|
2016-12-01 21:16:38 +07:00
|
|
|
lockdep_assert_held(&dev_priv->drm.struct_mutex);
|
2012-06-05 04:42:43 +07:00
|
|
|
|
2019-03-27 17:58:14 +07:00
|
|
|
BUILD_BUG_ON(I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE &
|
|
|
|
~I915_CONTEXT_CREATE_FLAGS_UNKNOWN);
|
2019-03-22 16:23:25 +07:00
|
|
|
if (flags & I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE &&
|
|
|
|
!HAS_EXECLISTS(dev_priv))
|
|
|
|
return ERR_PTR(-EINVAL);
|
|
|
|
|
2017-07-05 21:26:34 +07:00
|
|
|
/* Reap the most stale context */
|
|
|
|
contexts_free_first(dev_priv);
|
2017-07-05 21:26:32 +07:00
|
|
|
|
2019-03-21 21:07:08 +07:00
|
|
|
ctx = __create_context(dev_priv);
|
2012-06-30 00:30:39 +07:00
|
|
|
if (IS_ERR(ctx))
|
2013-12-07 05:11:05 +07:00
|
|
|
return ctx;
|
2012-06-05 04:42:43 +07:00
|
|
|
|
2018-09-27 03:12:22 +07:00
|
|
|
if (HAS_FULL_PPGTT(dev_priv)) {
|
2016-10-28 19:58:58 +07:00
|
|
|
struct i915_hw_ppgtt *ppgtt;
|
2013-12-07 05:11:18 +07:00
|
|
|
|
2019-03-21 21:07:08 +07:00
|
|
|
ppgtt = i915_ppgtt_create(dev_priv);
|
2016-05-24 20:53:38 +07:00
|
|
|
if (IS_ERR(ppgtt)) {
|
2013-12-07 05:11:19 +07:00
|
|
|
DRM_DEBUG_DRIVER("PPGTT setup failed (%ld)\n",
|
|
|
|
PTR_ERR(ppgtt));
|
2019-03-21 21:07:08 +07:00
|
|
|
context_close(ctx);
|
2016-05-24 20:53:38 +07:00
|
|
|
return ERR_CAST(ppgtt);
|
2014-08-06 20:04:53 +07:00
|
|
|
}
|
|
|
|
|
2019-03-22 16:23:23 +07:00
|
|
|
__assign_ppgtt(ctx, ppgtt);
|
|
|
|
i915_ppgtt_put(ppgtt);
|
2014-08-06 20:04:53 +07:00
|
|
|
}
|
2013-12-07 05:11:18 +07:00
|
|
|
|
2019-03-22 16:23:25 +07:00
|
|
|
if (flags & I915_CONTEXT_CREATE_FLAGS_SINGLE_TIMELINE) {
|
|
|
|
struct i915_timeline *timeline;
|
|
|
|
|
|
|
|
timeline = i915_timeline_create(dev_priv, NULL);
|
|
|
|
if (IS_ERR(timeline)) {
|
|
|
|
context_close(ctx);
|
|
|
|
return ERR_CAST(timeline);
|
|
|
|
}
|
|
|
|
|
|
|
|
ctx->timeline = timeline;
|
|
|
|
}
|
|
|
|
|
2014-11-10 20:44:31 +07:00
|
|
|
trace_i915_context_create(ctx);
|
|
|
|
|
2013-12-07 05:11:05 +07: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 04:42:42 +07:00
|
|
|
}
|
|
|
|
|
2016-06-16 19:07:05 +07:00
|
|
|
/**
|
|
|
|
* i915_gem_context_create_gvt - create a GVT GEM context
|
|
|
|
* @dev: drm device *
|
|
|
|
*
|
|
|
|
* This function is used to create a GVT specific GEM context.
|
|
|
|
*
|
|
|
|
* Returns:
|
|
|
|
* pointer to i915_gem_context on success, error pointer if failed
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
struct i915_gem_context *
|
|
|
|
i915_gem_context_create_gvt(struct drm_device *dev)
|
|
|
|
{
|
|
|
|
struct i915_gem_context *ctx;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (!IS_ENABLED(CONFIG_DRM_I915_GVT))
|
|
|
|
return ERR_PTR(-ENODEV);
|
|
|
|
|
|
|
|
ret = i915_mutex_lock_interruptible(dev);
|
|
|
|
if (ret)
|
|
|
|
return ERR_PTR(ret);
|
|
|
|
|
2019-03-22 16:23:25 +07:00
|
|
|
ctx = i915_gem_create_context(to_i915(dev), 0);
|
2016-06-16 19:07:05 +07:00
|
|
|
if (IS_ERR(ctx))
|
|
|
|
goto out;
|
|
|
|
|
2019-03-11 09:37:47 +07:00
|
|
|
ret = i915_gem_context_pin_hw_id(ctx);
|
|
|
|
if (ret) {
|
|
|
|
context_close(ctx);
|
|
|
|
ctx = ERR_PTR(ret);
|
|
|
|
goto out;
|
|
|
|
}
|
|
|
|
|
2017-01-06 22:20:13 +07:00
|
|
|
ctx->file_priv = ERR_PTR(-EBADF);
|
2016-12-31 18:20:11 +07:00
|
|
|
i915_gem_context_set_closed(ctx); /* not user accessible */
|
|
|
|
i915_gem_context_clear_bannable(ctx);
|
|
|
|
i915_gem_context_set_force_single_submission(ctx);
|
2017-12-06 20:53:12 +07:00
|
|
|
if (!USES_GUC_SUBMISSION(to_i915(dev)))
|
2017-02-16 13:36:40 +07:00
|
|
|
ctx->ring_size = 512 * PAGE_SIZE; /* Max ring buffer size */
|
2017-01-06 22:20:13 +07:00
|
|
|
|
|
|
|
GEM_BUG_ON(i915_gem_context_is_kernel(ctx));
|
2016-06-16 19:07:05 +07:00
|
|
|
out:
|
|
|
|
mutex_unlock(&dev->struct_mutex);
|
|
|
|
return ctx;
|
|
|
|
}
|
|
|
|
|
2018-09-04 22:31:17 +07: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 21:26:33 +07:00
|
|
|
struct i915_gem_context *
|
|
|
|
i915_gem_context_create_kernel(struct drm_i915_private *i915, int prio)
|
2017-10-04 03:34:48 +07:00
|
|
|
{
|
|
|
|
struct i915_gem_context *ctx;
|
2018-09-04 22:31:17 +07:00
|
|
|
int err;
|
2017-10-04 03:34:48 +07:00
|
|
|
|
2019-03-22 16:23:25 +07:00
|
|
|
ctx = i915_gem_create_context(i915, 0);
|
2017-10-04 03:34:48 +07:00
|
|
|
if (IS_ERR(ctx))
|
|
|
|
return ctx;
|
|
|
|
|
2018-09-04 22:31:17 +07:00
|
|
|
err = i915_gem_context_pin_hw_id(ctx);
|
|
|
|
if (err) {
|
|
|
|
destroy_kernel_context(&ctx);
|
|
|
|
return ERR_PTR(err);
|
|
|
|
}
|
|
|
|
|
2017-10-04 03:34:48 +07:00
|
|
|
i915_gem_context_clear_bannable(ctx);
|
2018-10-01 19:32:03 +07:00
|
|
|
ctx->sched.priority = I915_USER_PRIORITY(prio);
|
2017-10-04 03:34:48 +07:00
|
|
|
ctx->ring_size = PAGE_SIZE;
|
|
|
|
|
|
|
|
GEM_BUG_ON(!i915_gem_context_is_kernel(ctx));
|
|
|
|
|
|
|
|
return ctx;
|
|
|
|
}
|
|
|
|
|
2018-09-04 22:31:17 +07:00
|
|
|
static void init_contexts(struct drm_i915_private *i915)
|
2017-10-04 03:34:48 +07:00
|
|
|
{
|
2018-09-04 22:31:17 +07:00
|
|
|
mutex_init(&i915->contexts.mutex);
|
|
|
|
INIT_LIST_HEAD(&i915->contexts.list);
|
2017-10-04 03:34:48 +07:00
|
|
|
|
2018-09-04 22:31:17 +07:00
|
|
|
/* Using the simple ida interface, the max is limited by sizeof(int) */
|
|
|
|
BUILD_BUG_ON(MAX_CONTEXT_HW_ID > INT_MAX);
|
|
|
|
BUILD_BUG_ON(GEN11_MAX_CONTEXT_HW_ID > INT_MAX);
|
|
|
|
ida_init(&i915->contexts.hw_ida);
|
|
|
|
INIT_LIST_HEAD(&i915->contexts.hw_id_list);
|
2017-10-04 03:34:48 +07:00
|
|
|
|
2018-09-04 22:31:17 +07:00
|
|
|
INIT_WORK(&i915->contexts.free_work, contexts_free_worker);
|
|
|
|
init_llist_head(&i915->contexts.free_list);
|
2017-10-04 03:34:48 +07:00
|
|
|
}
|
|
|
|
|
2018-02-08 04:05:44 +07:00
|
|
|
static bool needs_preempt_context(struct drm_i915_private *i915)
|
|
|
|
{
|
2019-03-29 20:40:24 +07:00
|
|
|
return HAS_EXECLISTS(i915);
|
2018-02-08 04:05:44 +07:00
|
|
|
}
|
|
|
|
|
2017-06-20 18:05:45 +07:00
|
|
|
int i915_gem_contexts_init(struct drm_i915_private *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 04:42:42 +07:00
|
|
|
{
|
2016-05-24 20:53:34 +07: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 04:42:42 +07:00
|
|
|
|
2018-02-08 04:05:44 +07:00
|
|
|
/* Reassure ourselves we are only called once */
|
2017-10-04 03:34:48 +07:00
|
|
|
GEM_BUG_ON(dev_priv->kernel_context);
|
2018-02-08 04:05:44 +07:00
|
|
|
GEM_BUG_ON(dev_priv->preempt_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 04:42:42 +07:00
|
|
|
|
2019-03-06 01:03:30 +07:00
|
|
|
intel_engine_init_ctx_wa(dev_priv->engine[RCS0]);
|
2018-09-04 22:31:17 +07:00
|
|
|
init_contexts(dev_priv);
|
2016-04-28 15:56:51 +07:00
|
|
|
|
2017-10-04 03:34:48 +07:00
|
|
|
/* lowest priority; idle task */
|
2017-11-10 21:26:33 +07:00
|
|
|
ctx = i915_gem_context_create_kernel(dev_priv, I915_PRIORITY_MIN);
|
2014-04-09 15:07:36 +07:00
|
|
|
if (IS_ERR(ctx)) {
|
2017-10-04 03:34:48 +07:00
|
|
|
DRM_ERROR("Failed to create default global context\n");
|
2018-02-08 04:05:44 +07: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 04:42:42 +07:00
|
|
|
}
|
2017-10-04 03:34:48 +07:00
|
|
|
/*
|
|
|
|
* For easy recognisablity, we want the kernel context to be 0 and then
|
2018-09-04 22:31:17 +07:00
|
|
|
* all user contexts will have non-zero hw_id. Kernel contexts are
|
|
|
|
* permanently pinned, so that we never suffer a stall and can
|
|
|
|
* use them from any allocation context (e.g. for evicting other
|
|
|
|
* contexts and from inside the shrinker).
|
2017-01-23 18:31:31 +07:00
|
|
|
*/
|
|
|
|
GEM_BUG_ON(ctx->hw_id);
|
2018-09-04 22:31:17 +07:00
|
|
|
GEM_BUG_ON(!atomic_read(&ctx->hw_id_pin_count));
|
2016-01-20 02:02:54 +07:00
|
|
|
dev_priv->kernel_context = ctx;
|
2013-12-07 05:11:01 +07:00
|
|
|
|
2017-10-04 03:34:48 +07:00
|
|
|
/* highest priority; preempting task */
|
2018-02-08 04:05:44 +07:00
|
|
|
if (needs_preempt_context(dev_priv)) {
|
|
|
|
ctx = i915_gem_context_create_kernel(dev_priv, INT_MAX);
|
|
|
|
if (!IS_ERR(ctx))
|
|
|
|
dev_priv->preempt_context = ctx;
|
|
|
|
else
|
|
|
|
DRM_ERROR("Failed to create preempt context; disabling preemption\n");
|
2017-10-04 03:34:48 +07:00
|
|
|
}
|
2017-01-06 22:20:13 +07:00
|
|
|
|
2014-07-24 23:04:12 +07:00
|
|
|
DRM_DEBUG_DRIVER("%s context support initialized\n",
|
2018-07-06 17:14:41 +07:00
|
|
|
DRIVER_CAPS(dev_priv)->has_logical_contexts ?
|
|
|
|
"logical" : "fake");
|
2013-11-06 22:56:29 +07: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 04:42:42 +07:00
|
|
|
}
|
|
|
|
|
2017-06-20 18:05:45 +07:00
|
|
|
void i915_gem_contexts_lost(struct drm_i915_private *dev_priv)
|
2016-04-28 15:56:41 +07:00
|
|
|
{
|
|
|
|
struct intel_engine_cs *engine;
|
drm/i915: Allocate intel_engine_cs structure only for the enabled engines
With the possibility of addition of many more number of rings in future,
the drm_i915_private structure could bloat as an array, of type
intel_engine_cs, is embedded inside it.
struct intel_engine_cs engine[I915_NUM_ENGINES];
Though this is still fine as generally there is only a single instance of
drm_i915_private structure used, but not all of the possible rings would be
enabled or active on most of the platforms. Some memory can be saved by
allocating intel_engine_cs structure only for the enabled/active engines.
Currently the engine/ring ID is kept static and dev_priv->engine[] is simply
indexed using the enums defined in intel_engine_id.
To save memory and continue using the static engine/ring IDs, 'engine' is
defined as an array of pointers.
struct intel_engine_cs *engine[I915_NUM_ENGINES];
dev_priv->engine[engine_ID] will be NULL for disabled engine instances.
There is a text size reduction of 928 bytes, from 1028200 to 1027272, for
i915.o file (but for i915.ko file text size remain same as 1193131 bytes).
v2:
- Remove the engine iterator field added in drm_i915_private structure,
instead pass a local iterator variable to the for_each_engine**
macros. (Chris)
- Do away with intel_engine_initialized() and instead directly use the
NULL pointer check on engine pointer. (Chris)
v3:
- Remove for_each_engine_id() macro, as the updated macro for_each_engine()
can be used in place of it. (Chris)
- Protect the access to Render engine Fault register with a NULL check, as
engine specific init is done later in Driver load sequence.
v4:
- Use !!dev_priv->engine[VCS] style for the engine check in getparam. (Chris)
- Kill the superfluous init_engine_lists().
v5:
- Cleanup the intel_engines_init() & intel_engines_setup(), with respect to
allocation of intel_engine_cs structure. (Chris)
v6:
- Rebase.
v7:
- Optimize the for_each_engine_masked() macro. (Chris)
- Change the type of 'iter' local variable to enum intel_engine_id. (Chris)
- Rebase.
v8: Rebase.
v9: Rebase.
v10:
- For index calculation use engine ID instead of pointer based arithmetic in
intel_engine_sync_index() as engine pointers are not contiguous now (Chris)
- For appropriateness, rename local enum variable 'iter' to 'id'. (Joonas)
- Use for_each_engine macro for cleanup in intel_engines_init() and remove
check for NULL engine pointer in cleanup() routines. (Joonas)
v11: Rebase.
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Akash Goel <akash.goel@intel.com>
Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Signed-off-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/1476378888-7372-1-git-send-email-akash.goel@intel.com
2016-10-14 00:14:48 +07:00
|
|
|
enum intel_engine_id id;
|
2016-04-28 15:56:41 +07:00
|
|
|
|
2016-07-05 16:40:23 +07:00
|
|
|
lockdep_assert_held(&dev_priv->drm.struct_mutex);
|
2016-05-24 20:53:35 +07:00
|
|
|
|
2018-05-18 04:26:31 +07:00
|
|
|
for_each_engine(engine, dev_priv, id)
|
|
|
|
intel_engine_lost_context(engine);
|
2016-04-28 15:56:41 +07:00
|
|
|
}
|
|
|
|
|
2017-06-20 18:05:46 +07:00
|
|
|
void i915_gem_contexts_fini(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 04:42:42 +07:00
|
|
|
{
|
2017-06-20 18:05:46 +07:00
|
|
|
lockdep_assert_held(&i915->drm.struct_mutex);
|
2017-01-06 22:20:13 +07:00
|
|
|
|
2018-02-08 04:05:44 +07:00
|
|
|
if (i915->preempt_context)
|
|
|
|
destroy_kernel_context(&i915->preempt_context);
|
2017-10-04 03:34:48 +07:00
|
|
|
destroy_kernel_context(&i915->kernel_context);
|
2016-04-28 15:56:51 +07:00
|
|
|
|
2017-06-20 18:05:46 +07:00
|
|
|
/* Must free all deferred contexts (via flush_workqueue) first */
|
2018-09-04 22:31:17 +07:00
|
|
|
GEM_BUG_ON(!list_empty(&i915->contexts.hw_id_list));
|
2017-06-20 18:05:46 +07:00
|
|
|
ida_destroy(&i915->contexts.hw_ida);
|
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 04:42:42 +07:00
|
|
|
}
|
|
|
|
|
2012-06-05 04:42:43 +07:00
|
|
|
static int context_idr_cleanup(int id, void *p, void *data)
|
|
|
|
{
|
2019-03-21 21:07:09 +07:00
|
|
|
context_close(p);
|
2012-06-05 04:42:43 +07: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 04:42:42 +07:00
|
|
|
}
|
|
|
|
|
2019-03-22 16:23:23 +07:00
|
|
|
static int vm_idr_cleanup(int id, void *p, void *data)
|
|
|
|
{
|
|
|
|
i915_ppgtt_put(p);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-03-21 21:07:08 +07:00
|
|
|
static int gem_context_register(struct i915_gem_context *ctx,
|
|
|
|
struct drm_i915_file_private *fpriv)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
ctx->file_priv = fpriv;
|
|
|
|
if (ctx->ppgtt)
|
|
|
|
ctx->ppgtt->vm.file = fpriv;
|
|
|
|
|
|
|
|
ctx->pid = get_task_pid(current, PIDTYPE_PID);
|
|
|
|
ctx->name = kasprintf(GFP_KERNEL, "%s[%d]",
|
|
|
|
current->comm, pid_nr(ctx->pid));
|
|
|
|
if (!ctx->name) {
|
|
|
|
ret = -ENOMEM;
|
|
|
|
goto err_pid;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* And finally expose ourselves to userspace via the idr */
|
2019-03-21 21:07:09 +07:00
|
|
|
mutex_lock(&fpriv->context_idr_lock);
|
2019-03-21 21:07:10 +07:00
|
|
|
ret = idr_alloc(&fpriv->context_idr, ctx, 0, 0, GFP_KERNEL);
|
2019-03-21 21:07:09 +07:00
|
|
|
mutex_unlock(&fpriv->context_idr_lock);
|
2019-03-21 21:07:10 +07:00
|
|
|
if (ret >= 0)
|
|
|
|
goto out;
|
2019-03-21 21:07:08 +07:00
|
|
|
|
|
|
|
kfree(fetch_and_zero(&ctx->name));
|
|
|
|
err_pid:
|
|
|
|
put_pid(fetch_and_zero(&ctx->pid));
|
2019-03-21 21:07:10 +07:00
|
|
|
out:
|
2019-03-21 21:07:08 +07:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2017-06-20 18:05:45 +07:00
|
|
|
int i915_gem_context_open(struct drm_i915_private *i915,
|
|
|
|
struct drm_file *file)
|
2013-12-07 05:10:58 +07:00
|
|
|
{
|
|
|
|
struct drm_i915_file_private *file_priv = file->driver_priv;
|
2016-05-24 20:53:34 +07:00
|
|
|
struct i915_gem_context *ctx;
|
2019-03-21 21:07:08 +07:00
|
|
|
int err;
|
2013-12-07 05:10:58 +07:00
|
|
|
|
2019-03-21 21:07:09 +07:00
|
|
|
mutex_init(&file_priv->context_idr_lock);
|
2019-03-22 16:23:23 +07: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 05:10:58 +07:00
|
|
|
|
2017-06-20 18:05:45 +07:00
|
|
|
mutex_lock(&i915->drm.struct_mutex);
|
2019-03-22 16:23:25 +07:00
|
|
|
ctx = i915_gem_create_context(i915, 0);
|
2019-03-21 21:07:09 +07:00
|
|
|
mutex_unlock(&i915->drm.struct_mutex);
|
2014-05-22 20:13:38 +07:00
|
|
|
if (IS_ERR(ctx)) {
|
2019-03-21 21:07:08 +07:00
|
|
|
err = PTR_ERR(ctx);
|
|
|
|
goto err;
|
2013-12-07 05:11:19 +07:00
|
|
|
}
|
|
|
|
|
2019-03-21 21:07:08 +07:00
|
|
|
err = gem_context_register(ctx, file_priv);
|
2019-03-21 21:07:10 +07:00
|
|
|
if (err < 0)
|
2019-03-21 21:07:08 +07:00
|
|
|
goto err_ctx;
|
|
|
|
|
2017-07-05 21:26:31 +07:00
|
|
|
GEM_BUG_ON(i915_gem_context_is_kernel(ctx));
|
2019-03-21 21:07:10 +07:00
|
|
|
GEM_BUG_ON(err > 0);
|
2017-07-05 21:26:31 +07:00
|
|
|
|
2013-12-07 05:10:58 +07:00
|
|
|
return 0;
|
2019-03-21 21:07:08 +07:00
|
|
|
|
|
|
|
err_ctx:
|
2019-03-21 21:07:09 +07:00
|
|
|
mutex_lock(&i915->drm.struct_mutex);
|
2019-03-21 21:07:08 +07:00
|
|
|
context_close(ctx);
|
|
|
|
mutex_unlock(&i915->drm.struct_mutex);
|
2019-03-21 21:07:09 +07:00
|
|
|
err:
|
2019-03-22 16:23:23 +07:00
|
|
|
idr_destroy(&file_priv->vm_idr);
|
2019-03-21 21:07:08 +07:00
|
|
|
idr_destroy(&file_priv->context_idr);
|
2019-03-22 16:23:23 +07:00
|
|
|
mutex_destroy(&file_priv->vm_idr_lock);
|
|
|
|
mutex_destroy(&file_priv->context_idr_lock);
|
2019-03-25 16:03:52 +07:00
|
|
|
return err;
|
2013-12-07 05:10:58 +07:00
|
|
|
}
|
|
|
|
|
2017-06-20 18:05:45 +07: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 04:42:42 +07:00
|
|
|
{
|
2012-06-05 04:42:43 +07:00
|
|
|
struct drm_i915_file_private *file_priv = file->driver_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 04:42:42 +07:00
|
|
|
|
2017-06-20 18:05:45 +07:00
|
|
|
lockdep_assert_held(&file_priv->dev_priv->drm.struct_mutex);
|
2016-05-24 20:53:35 +07:00
|
|
|
|
2012-06-20 01:27:39 +07:00
|
|
|
idr_for_each(&file_priv->context_idr, context_idr_cleanup, NULL);
|
2012-06-05 04:42:43 +07:00
|
|
|
idr_destroy(&file_priv->context_idr);
|
2019-03-21 21:07:09 +07:00
|
|
|
mutex_destroy(&file_priv->context_idr_lock);
|
2019-03-22 16:23:23 +07: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);
|
|
|
|
}
|
|
|
|
|
|
|
|
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;
|
|
|
|
struct i915_hw_ppgtt *ppgtt;
|
|
|
|
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;
|
|
|
|
|
|
|
|
err = idr_alloc(&file_priv->vm_idr, ppgtt, 0, 0, GFP_KERNEL);
|
|
|
|
if (err < 0)
|
|
|
|
goto err_unlock;
|
|
|
|
|
|
|
|
GEM_BUG_ON(err == 0); /* reserved for default/unassigned ppgtt */
|
|
|
|
ppgtt->user_handle = err;
|
|
|
|
|
|
|
|
mutex_unlock(&file_priv->vm_idr_lock);
|
|
|
|
|
|
|
|
args->vm_id = err;
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
err_unlock:
|
|
|
|
mutex_unlock(&file_priv->vm_idr_lock);
|
|
|
|
err_put:
|
|
|
|
i915_ppgtt_put(ppgtt);
|
|
|
|
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;
|
|
|
|
struct i915_hw_ppgtt *ppgtt;
|
|
|
|
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;
|
|
|
|
|
|
|
|
ppgtt = idr_remove(&file_priv->vm_idr, id);
|
|
|
|
if (ppgtt) {
|
|
|
|
GEM_BUG_ON(ppgtt->user_handle != id);
|
|
|
|
ppgtt->user_handle = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
mutex_unlock(&file_priv->vm_idr_lock);
|
|
|
|
if (!ppgtt)
|
|
|
|
return -ENOENT;
|
|
|
|
|
|
|
|
i915_ppgtt_put(ppgtt);
|
|
|
|
return 0;
|
2012-06-05 04:42:43 +07:00
|
|
|
}
|
|
|
|
|
2018-05-02 23:38:39 +07:00
|
|
|
static struct i915_request *
|
|
|
|
last_request_on_engine(struct i915_timeline *timeline,
|
|
|
|
struct intel_engine_cs *engine)
|
2016-12-29 21:40:37 +07:00
|
|
|
{
|
2018-05-02 23:38:39 +07:00
|
|
|
struct i915_request *rq;
|
2016-12-29 21:40:37 +07:00
|
|
|
|
2018-05-24 15:11:35 +07:00
|
|
|
GEM_BUG_ON(timeline == &engine->timeline);
|
2016-12-29 21:40:37 +07:00
|
|
|
|
drm/i915: Pull i915_gem_active into the i915_active family
Looking forward, we need to break the struct_mutex dependency on
i915_gem_active. In the meantime, external use of i915_gem_active is
quite beguiling, little do new users suspect that it implies a barrier
as each request it tracks must be ordered wrt the previous one. As one
of many, it can be used to track activity across multiple timelines, a
shared fence, which fits our unordered request submission much better. We
need to steer external users away from the singular, exclusive fence
imposed by i915_gem_active to i915_active instead. As part of that
process, we move i915_gem_active out of i915_request.c into
i915_active.c to start separating the two concepts, and rename it to
i915_active_request (both to tie it to the concept of tracking just one
request, and to give it a longer, less appealing name).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190205130005.2807-5-chris@chris-wilson.co.uk
2019-02-05 20:00:05 +07:00
|
|
|
rq = i915_active_request_raw(&timeline->last_request,
|
|
|
|
&engine->i915->drm.struct_mutex);
|
2019-03-22 16:23:25 +07:00
|
|
|
if (rq && rq->engine->mask & engine->mask) {
|
2019-03-21 21:07:11 +07:00
|
|
|
GEM_TRACE("last request on engine %s: %llx:%llu\n",
|
|
|
|
engine->name, rq->fence.context, rq->fence.seqno);
|
2018-05-24 15:11:35 +07:00
|
|
|
GEM_BUG_ON(rq->timeline != timeline);
|
2018-05-02 23:38:39 +07:00
|
|
|
return rq;
|
2018-05-24 15:11:35 +07:00
|
|
|
}
|
2018-05-02 23:38:39 +07:00
|
|
|
|
|
|
|
return NULL;
|
|
|
|
}
|
2016-12-29 21:40:37 +07:00
|
|
|
|
2019-03-09 23:02:50 +07:00
|
|
|
struct context_barrier_task {
|
|
|
|
struct i915_active base;
|
|
|
|
void (*task)(void *data);
|
|
|
|
void *data;
|
|
|
|
};
|
|
|
|
|
|
|
|
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-01 23:26:39 +07:00
|
|
|
I915_SELFTEST_DECLARE(static intel_engine_mask_t context_barrier_inject_fault);
|
2019-03-09 23:02:50 +07:00
|
|
|
static int context_barrier_task(struct i915_gem_context *ctx,
|
2019-04-01 23:26:39 +07:00
|
|
|
intel_engine_mask_t engines,
|
2019-03-22 16:23:23 +07:00
|
|
|
int (*emit)(struct i915_request *rq, void *data),
|
2019-03-09 23:02:50 +07:00
|
|
|
void (*task)(void *data),
|
|
|
|
void *data)
|
|
|
|
{
|
|
|
|
struct drm_i915_private *i915 = ctx->i915;
|
|
|
|
struct context_barrier_task *cb;
|
2019-03-22 16:23:23 +07:00
|
|
|
struct intel_context *ce, *next;
|
2019-03-09 23:02:50 +07:00
|
|
|
intel_wakeref_t wakeref;
|
|
|
|
int err = 0;
|
|
|
|
|
|
|
|
lockdep_assert_held(&i915->drm.struct_mutex);
|
|
|
|
GEM_BUG_ON(!task);
|
|
|
|
|
|
|
|
cb = kmalloc(sizeof(*cb), GFP_KERNEL);
|
|
|
|
if (!cb)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
|
|
|
i915_active_init(i915, &cb->base, cb_retire);
|
|
|
|
i915_active_acquire(&cb->base);
|
|
|
|
|
|
|
|
wakeref = intel_runtime_pm_get(i915);
|
2019-03-22 16:23:23 +07:00
|
|
|
rbtree_postorder_for_each_entry_safe(ce, next, &ctx->hw_contexts, node) {
|
2019-03-09 23:02:50 +07:00
|
|
|
struct intel_engine_cs *engine = ce->engine;
|
|
|
|
struct i915_request *rq;
|
|
|
|
|
2019-03-22 16:23:23 +07:00
|
|
|
if (!(engine->mask & engines))
|
2019-03-09 23:02:50 +07:00
|
|
|
continue;
|
|
|
|
|
|
|
|
if (I915_SELFTEST_ONLY(context_barrier_inject_fault &
|
|
|
|
engine->mask)) {
|
|
|
|
err = -ENXIO;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
|
|
|
rq = i915_request_alloc(engine, ctx);
|
|
|
|
if (IS_ERR(rq)) {
|
|
|
|
err = PTR_ERR(rq);
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2019-03-22 16:23:23 +07:00
|
|
|
err = 0;
|
|
|
|
if (emit)
|
|
|
|
err = emit(rq, data);
|
|
|
|
if (err == 0)
|
|
|
|
err = i915_active_ref(&cb->base, rq->fence.context, rq);
|
|
|
|
|
2019-03-09 23:02:50 +07:00
|
|
|
i915_request_add(rq);
|
|
|
|
if (err)
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
intel_runtime_pm_put(i915, wakeref);
|
|
|
|
|
|
|
|
cb->task = err ? NULL : task; /* caller needs to unwind instead */
|
|
|
|
cb->data = data;
|
|
|
|
|
|
|
|
i915_active_release(&cb->base);
|
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2019-03-08 16:36:56 +07:00
|
|
|
int i915_gem_switch_to_kernel_context(struct drm_i915_private *i915,
|
2019-04-01 23:26:39 +07:00
|
|
|
intel_engine_mask_t mask)
|
2016-07-15 20:56:19 +07:00
|
|
|
{
|
|
|
|
struct intel_engine_cs *engine;
|
|
|
|
|
2018-05-31 15:22:43 +07:00
|
|
|
GEM_TRACE("awake?=%s\n", yesno(i915->gt.awake));
|
2018-05-24 15:11:35 +07:00
|
|
|
|
2018-05-15 21:31:49 +07:00
|
|
|
lockdep_assert_held(&i915->drm.struct_mutex);
|
2018-05-24 15:11:35 +07:00
|
|
|
GEM_BUG_ON(!i915->kernel_context);
|
2016-10-28 19:58:47 +07:00
|
|
|
|
2019-03-08 16:36:54 +07:00
|
|
|
/* Inoperable, so presume the GPU is safely pointing into the void! */
|
|
|
|
if (i915_terminally_wedged(i915))
|
|
|
|
return 0;
|
|
|
|
|
2019-03-08 16:36:56 +07:00
|
|
|
for_each_engine_masked(engine, i915, mask, mask) {
|
2018-05-15 21:31:49 +07:00
|
|
|
struct intel_ring *ring;
|
2018-02-21 16:56:36 +07:00
|
|
|
struct i915_request *rq;
|
2016-07-15 20:56:19 +07:00
|
|
|
|
2018-05-15 21:31:49 +07:00
|
|
|
rq = i915_request_alloc(engine, i915->kernel_context);
|
2018-02-21 16:56:36 +07:00
|
|
|
if (IS_ERR(rq))
|
|
|
|
return PTR_ERR(rq);
|
2016-07-15 20:56:19 +07:00
|
|
|
|
2016-10-28 19:58:47 +07:00
|
|
|
/* Queue this switch after all other activity */
|
2018-05-15 21:31:49 +07:00
|
|
|
list_for_each_entry(ring, &i915->gt.active_rings, active_link) {
|
2018-02-21 16:56:36 +07:00
|
|
|
struct i915_request *prev;
|
2016-10-28 19:58:47 +07:00
|
|
|
|
2018-05-15 21:31:49 +07:00
|
|
|
prev = last_request_on_engine(ring->timeline, engine);
|
2018-05-24 15:11:35 +07:00
|
|
|
if (!prev)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (prev->gem_context == i915->kernel_context)
|
|
|
|
continue;
|
|
|
|
|
2018-12-07 19:34:28 +07:00
|
|
|
GEM_TRACE("add barrier on %s for %llx:%lld\n",
|
2018-05-24 15:11:35 +07:00
|
|
|
engine->name,
|
|
|
|
prev->fence.context,
|
|
|
|
prev->fence.seqno);
|
|
|
|
i915_sw_fence_await_sw_fence_gfp(&rq->submit,
|
|
|
|
&prev->submit,
|
|
|
|
I915_FENCE_GFP);
|
2016-10-28 19:58:47 +07:00
|
|
|
}
|
|
|
|
|
2018-06-12 17:51:35 +07:00
|
|
|
i915_request_add(rq);
|
2016-07-15 20:56:19 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-03-30 17:03:49 +07:00
|
|
|
static int get_ppgtt(struct drm_i915_file_private *file_priv,
|
|
|
|
struct i915_gem_context *ctx,
|
2019-03-22 16:23:23 +07:00
|
|
|
struct drm_i915_gem_context_param *args)
|
|
|
|
{
|
|
|
|
struct i915_hw_ppgtt *ppgtt;
|
|
|
|
int ret;
|
|
|
|
|
2019-03-27 17:58:14 +07:00
|
|
|
return -EINVAL; /* nothing to see here; please move along */
|
|
|
|
|
2019-03-22 16:23:23 +07:00
|
|
|
if (!ctx->ppgtt)
|
|
|
|
return -ENODEV;
|
|
|
|
|
|
|
|
/* XXX rcu acquire? */
|
|
|
|
ret = mutex_lock_interruptible(&ctx->i915->drm.struct_mutex);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
ppgtt = i915_ppgtt_get(ctx->ppgtt);
|
|
|
|
mutex_unlock(&ctx->i915->drm.struct_mutex);
|
|
|
|
|
|
|
|
ret = mutex_lock_interruptible(&file_priv->vm_idr_lock);
|
|
|
|
if (ret)
|
|
|
|
goto err_put;
|
|
|
|
|
|
|
|
if (!ppgtt->user_handle) {
|
|
|
|
ret = idr_alloc(&file_priv->vm_idr, ppgtt, 0, 0, GFP_KERNEL);
|
|
|
|
GEM_BUG_ON(!ret);
|
|
|
|
if (ret < 0)
|
|
|
|
goto err_unlock;
|
|
|
|
|
|
|
|
ppgtt->user_handle = ret;
|
|
|
|
i915_ppgtt_get(ppgtt);
|
|
|
|
}
|
|
|
|
|
|
|
|
args->size = 0;
|
|
|
|
args->value = ppgtt->user_handle;
|
|
|
|
|
|
|
|
ret = 0;
|
|
|
|
err_unlock:
|
|
|
|
mutex_unlock(&file_priv->vm_idr_lock);
|
|
|
|
err_put:
|
|
|
|
i915_ppgtt_put(ppgtt);
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static void set_ppgtt_barrier(void *data)
|
|
|
|
{
|
|
|
|
struct i915_hw_ppgtt *old = data;
|
|
|
|
|
|
|
|
if (INTEL_GEN(old->vm.i915) < 8)
|
|
|
|
gen6_ppgtt_unpin_all(old);
|
|
|
|
|
|
|
|
i915_ppgtt_put(old);
|
|
|
|
}
|
|
|
|
|
|
|
|
static int emit_ppgtt_update(struct i915_request *rq, void *data)
|
|
|
|
{
|
|
|
|
struct i915_hw_ppgtt *ppgtt = rq->gem_context->ppgtt;
|
|
|
|
struct intel_engine_cs *engine = rq->engine;
|
2019-04-05 19:38:31 +07:00
|
|
|
u32 base = engine->mmio_base;
|
2019-03-22 16:23:23 +07:00
|
|
|
u32 *cs;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
if (i915_vm_is_4lvl(&ppgtt->vm)) {
|
|
|
|
const dma_addr_t pd_daddr = px_dma(&ppgtt->pml4);
|
|
|
|
|
|
|
|
cs = intel_ring_begin(rq, 6);
|
|
|
|
if (IS_ERR(cs))
|
|
|
|
return PTR_ERR(cs);
|
|
|
|
|
|
|
|
*cs++ = MI_LOAD_REGISTER_IMM(2);
|
|
|
|
|
2019-04-05 19:38:31 +07:00
|
|
|
*cs++ = i915_mmio_reg_offset(GEN8_RING_PDP_UDW(base, 0));
|
2019-03-22 16:23:23 +07:00
|
|
|
*cs++ = upper_32_bits(pd_daddr);
|
2019-04-05 19:38:31 +07:00
|
|
|
*cs++ = i915_mmio_reg_offset(GEN8_RING_PDP_LDW(base, 0));
|
2019-03-22 16:23:23 +07:00
|
|
|
*cs++ = lower_32_bits(pd_daddr);
|
|
|
|
|
|
|
|
*cs++ = MI_NOOP;
|
|
|
|
intel_ring_advance(rq, cs);
|
|
|
|
} else if (HAS_LOGICAL_RING_CONTEXTS(engine->i915)) {
|
|
|
|
cs = intel_ring_begin(rq, 4 * GEN8_3LVL_PDPES + 2);
|
|
|
|
if (IS_ERR(cs))
|
|
|
|
return PTR_ERR(cs);
|
|
|
|
|
|
|
|
*cs++ = MI_LOAD_REGISTER_IMM(2 * GEN8_3LVL_PDPES);
|
|
|
|
for (i = GEN8_3LVL_PDPES; i--; ) {
|
|
|
|
const dma_addr_t pd_daddr = i915_page_dir_dma_addr(ppgtt, i);
|
|
|
|
|
2019-04-05 19:38:31 +07:00
|
|
|
*cs++ = i915_mmio_reg_offset(GEN8_RING_PDP_UDW(base, i));
|
2019-03-22 16:23:23 +07:00
|
|
|
*cs++ = upper_32_bits(pd_daddr);
|
2019-04-05 19:38:31 +07:00
|
|
|
*cs++ = i915_mmio_reg_offset(GEN8_RING_PDP_LDW(base, i));
|
2019-03-22 16:23:23 +07:00
|
|
|
*cs++ = lower_32_bits(pd_daddr);
|
|
|
|
}
|
|
|
|
*cs++ = MI_NOOP;
|
|
|
|
intel_ring_advance(rq, cs);
|
|
|
|
} else {
|
|
|
|
/* ppGTT is not part of the legacy context image */
|
|
|
|
gen6_ppgtt_pin(ppgtt);
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-03-30 17:03:49 +07:00
|
|
|
static int set_ppgtt(struct drm_i915_file_private *file_priv,
|
|
|
|
struct i915_gem_context *ctx,
|
2019-03-22 16:23:23 +07:00
|
|
|
struct drm_i915_gem_context_param *args)
|
|
|
|
{
|
|
|
|
struct i915_hw_ppgtt *ppgtt, *old;
|
|
|
|
int err;
|
|
|
|
|
2019-03-27 17:58:14 +07:00
|
|
|
return -EINVAL; /* nothing to see here; please move along */
|
|
|
|
|
2019-03-22 16:23:23 +07:00
|
|
|
if (args->size)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (!ctx->ppgtt)
|
|
|
|
return -ENODEV;
|
|
|
|
|
|
|
|
if (upper_32_bits(args->value))
|
|
|
|
return -ENOENT;
|
|
|
|
|
|
|
|
err = mutex_lock_interruptible(&file_priv->vm_idr_lock);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
|
|
|
|
ppgtt = idr_find(&file_priv->vm_idr, args->value);
|
|
|
|
if (ppgtt) {
|
|
|
|
GEM_BUG_ON(ppgtt->user_handle != args->value);
|
|
|
|
i915_ppgtt_get(ppgtt);
|
|
|
|
}
|
|
|
|
mutex_unlock(&file_priv->vm_idr_lock);
|
|
|
|
if (!ppgtt)
|
|
|
|
return -ENOENT;
|
|
|
|
|
|
|
|
err = mutex_lock_interruptible(&ctx->i915->drm.struct_mutex);
|
|
|
|
if (err)
|
|
|
|
goto out;
|
|
|
|
|
|
|
|
if (ppgtt == ctx->ppgtt)
|
|
|
|
goto unlock;
|
|
|
|
|
|
|
|
/* Teardown the existing obj:vma cache, it will have to be rebuilt. */
|
|
|
|
lut_close(ctx);
|
|
|
|
|
|
|
|
old = __set_ppgtt(ctx, ppgtt);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* 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,
|
|
|
|
emit_ppgtt_update,
|
|
|
|
set_ppgtt_barrier,
|
|
|
|
old);
|
|
|
|
if (err) {
|
|
|
|
ctx->ppgtt = old;
|
|
|
|
ctx->desc_template = default_desc_template(ctx->i915, old);
|
|
|
|
i915_ppgtt_put(ppgtt);
|
|
|
|
}
|
|
|
|
|
|
|
|
unlock:
|
|
|
|
mutex_unlock(&ctx->i915->drm.struct_mutex);
|
|
|
|
|
|
|
|
out:
|
|
|
|
i915_ppgtt_put(ppgtt);
|
|
|
|
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 16:50:31 +07: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 +
|
|
|
|
(CTX_R_PWR_CLK_STATE + 1) * 4;
|
|
|
|
|
|
|
|
*cs++ = MI_STORE_DWORD_IMM_GEN4 | MI_USE_GGTT;
|
|
|
|
*cs++ = lower_32_bits(offset);
|
|
|
|
*cs++ = upper_32_bits(offset);
|
|
|
|
*cs++ = gen8_make_rpcs(rq->i915, &sseu);
|
|
|
|
|
|
|
|
intel_ring_advance(rq, cs);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
2019-03-08 20:25:22 +07: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 16:50:31 +07:00
|
|
|
{
|
2019-03-08 20:25:22 +07:00
|
|
|
struct drm_i915_private *i915 = ce->engine->i915;
|
2019-04-08 16:17:03 +07: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 16:50:31 +07:00
|
|
|
intel_wakeref_t wakeref;
|
|
|
|
int ret;
|
|
|
|
|
2019-03-08 20:25:22 +07: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 16:50:31 +07:00
|
|
|
|
2019-03-08 20:25:22 +07: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 16:50:31 +07:00
|
|
|
|
|
|
|
/* Submitting requests etc needs the hw awake. */
|
|
|
|
wakeref = intel_runtime_pm_get(i915);
|
|
|
|
|
2019-03-08 20:25:22 +07:00
|
|
|
rq = i915_request_alloc(ce->engine, i915->kernel_context);
|
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 16:50:31 +07:00
|
|
|
if (IS_ERR(rq)) {
|
|
|
|
ret = PTR_ERR(rq);
|
|
|
|
goto out_put;
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Queue this switch after all other activity by this context. */
|
2019-04-08 16:17:03 +07:00
|
|
|
ret = i915_active_request_set(&ce->ring->timeline->last_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 16:50:31 +07:00
|
|
|
if (ret)
|
|
|
|
goto out_add;
|
|
|
|
|
|
|
|
ret = gen8_emit_rpcs_config(rq, ce, sseu);
|
|
|
|
if (ret)
|
|
|
|
goto out_add;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Guarantee context image and the timeline remains pinned until the
|
|
|
|
* modifying request is retired by setting the ce activity tracker.
|
|
|
|
*
|
|
|
|
* But we only need to take one pin on the account of it. Or in other
|
|
|
|
* words transfer the pinned ce object to tracked active request.
|
|
|
|
*/
|
drm/i915: Pull i915_gem_active into the i915_active family
Looking forward, we need to break the struct_mutex dependency on
i915_gem_active. In the meantime, external use of i915_gem_active is
quite beguiling, little do new users suspect that it implies a barrier
as each request it tracks must be ordered wrt the previous one. As one
of many, it can be used to track activity across multiple timelines, a
shared fence, which fits our unordered request submission much better. We
need to steer external users away from the singular, exclusive fence
imposed by i915_gem_active to i915_active instead. As part of that
process, we move i915_gem_active out of i915_request.c into
i915_active.c to start separating the two concepts, and rename it to
i915_active_request (both to tie it to the concept of tracking just one
request, and to give it a longer, less appealing name).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190205130005.2807-5-chris@chris-wilson.co.uk
2019-02-05 20:00:05 +07:00
|
|
|
if (!i915_active_request_isset(&ce->active_tracker))
|
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 16:50:31 +07:00
|
|
|
__intel_context_pin(ce);
|
drm/i915: Pull i915_gem_active into the i915_active family
Looking forward, we need to break the struct_mutex dependency on
i915_gem_active. In the meantime, external use of i915_gem_active is
quite beguiling, little do new users suspect that it implies a barrier
as each request it tracks must be ordered wrt the previous one. As one
of many, it can be used to track activity across multiple timelines, a
shared fence, which fits our unordered request submission much better. We
need to steer external users away from the singular, exclusive fence
imposed by i915_gem_active to i915_active instead. As part of that
process, we move i915_gem_active out of i915_request.c into
i915_active.c to start separating the two concepts, and rename it to
i915_active_request (both to tie it to the concept of tracking just one
request, and to give it a longer, less appealing name).
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190205130005.2807-5-chris@chris-wilson.co.uk
2019-02-05 20:00:05 +07:00
|
|
|
__i915_active_request_set(&ce->active_tracker, 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 16:50:31 +07:00
|
|
|
|
|
|
|
out_add:
|
|
|
|
i915_request_add(rq);
|
|
|
|
out_put:
|
|
|
|
intel_runtime_pm_put(i915, wakeref);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
2019-02-05 16:50:32 +07:00
|
|
|
__i915_gem_context_reconfigure_sseu(struct i915_gem_context *ctx,
|
|
|
|
struct intel_engine_cs *engine,
|
|
|
|
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 16:50:31 +07:00
|
|
|
{
|
2019-03-08 20:25:19 +07:00
|
|
|
struct intel_context *ce;
|
2019-02-05 16:50:32 +07:00
|
|
|
int ret = 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 16:50:31 +07:00
|
|
|
|
|
|
|
GEM_BUG_ON(INTEL_GEN(ctx->i915) < 8);
|
2019-03-06 01:03:30 +07:00
|
|
|
GEM_BUG_ON(engine->id != RCS0);
|
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 16:50:31 +07:00
|
|
|
|
2019-03-08 20:25:22 +07:00
|
|
|
ce = intel_context_pin_lock(ctx, engine);
|
2019-03-08 20:25:19 +07: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 16:50:31 +07:00
|
|
|
/* Nothing to do if unmodified. */
|
|
|
|
if (!memcmp(&ce->sseu, &sseu, sizeof(sseu)))
|
2019-03-08 20:25:22 +07: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 16:50:31 +07:00
|
|
|
|
2019-03-08 20:25:22 +07: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 16:50:31 +07:00
|
|
|
if (!ret)
|
|
|
|
ce->sseu = sseu;
|
|
|
|
|
2019-03-08 20:25:22 +07:00
|
|
|
unlock:
|
|
|
|
intel_context_pin_unlock(ce);
|
2019-02-05 16:50:32 +07:00
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
|
|
|
i915_gem_context_reconfigure_sseu(struct i915_gem_context *ctx,
|
|
|
|
struct intel_engine_cs *engine,
|
|
|
|
struct intel_sseu sseu)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = mutex_lock_interruptible(&ctx->i915->drm.struct_mutex);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
ret = __i915_gem_context_reconfigure_sseu(ctx, engine, 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 16:50:31 +07:00
|
|
|
mutex_unlock(&ctx->i915->drm.struct_mutex);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
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;
|
|
|
|
struct intel_engine_cs *engine;
|
|
|
|
struct intel_sseu sseu;
|
|
|
|
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;
|
|
|
|
|
|
|
|
if (user_sseu.flags || user_sseu.rsvd)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
engine = intel_engine_lookup_user(i915,
|
|
|
|
user_sseu.engine_class,
|
|
|
|
user_sseu.engine_instance);
|
|
|
|
if (!engine)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
/* Only render engine supports RPCS configuration. */
|
|
|
|
if (engine->class != RENDER_CLASS)
|
|
|
|
return -ENODEV;
|
|
|
|
|
|
|
|
ret = user_to_context_sseu(i915, &user_sseu, &sseu);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
ret = i915_gem_context_reconfigure_sseu(ctx, engine, sseu);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
args->size = sizeof(user_sseu);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-03-30 17:03:49 +07:00
|
|
|
static int ctx_setparam(struct drm_i915_file_private *fpriv,
|
|
|
|
struct i915_gem_context *ctx,
|
2019-03-22 16:23:24 +07:00
|
|
|
struct drm_i915_gem_context_param *args)
|
2014-12-24 23:13:40 +07:00
|
|
|
{
|
2018-09-11 20:22:06 +07:00
|
|
|
int ret = 0;
|
2014-12-24 23:13:40 +07:00
|
|
|
|
|
|
|
switch (args->param) {
|
2015-05-20 21:00:13 +07:00
|
|
|
case I915_CONTEXT_PARAM_NO_ZEROMAP:
|
2018-09-11 20:22:06 +07:00
|
|
|
if (args->size)
|
2015-05-20 21:00:13 +07:00
|
|
|
ret = -EINVAL;
|
2018-09-11 20:22:06 +07: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 14:08:39 +07:00
|
|
|
break;
|
2019-03-22 16:23:24 +07:00
|
|
|
|
2016-07-04 14:08:39 +07:00
|
|
|
case I915_CONTEXT_PARAM_NO_ERROR_CAPTURE:
|
2016-12-31 18:20:11 +07:00
|
|
|
if (args->size)
|
2016-07-04 14:08:39 +07:00
|
|
|
ret = -EINVAL;
|
2016-12-31 18:20:11 +07: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 21:00:13 +07:00
|
|
|
break;
|
2019-03-22 16:23:24 +07:00
|
|
|
|
2016-11-16 22:20:32 +07:00
|
|
|
case I915_CONTEXT_PARAM_BANNABLE:
|
|
|
|
if (args->size)
|
|
|
|
ret = -EINVAL;
|
|
|
|
else if (!capable(CAP_SYS_ADMIN) && !args->value)
|
|
|
|
ret = -EPERM;
|
2016-12-31 18:20:11 +07:00
|
|
|
else if (args->value)
|
|
|
|
i915_gem_context_set_bannable(ctx);
|
2016-11-16 22:20:32 +07:00
|
|
|
else
|
2016-12-31 18:20:11 +07:00
|
|
|
i915_gem_context_clear_bannable(ctx);
|
2016-11-16 22:20:32 +07: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 03:34:53 +07:00
|
|
|
|
2019-02-18 17:58:21 +07: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 03:34:53 +07:00
|
|
|
case I915_CONTEXT_PARAM_PRIORITY:
|
|
|
|
{
|
2018-02-08 15:51:51 +07: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 03:34:53 +07:00
|
|
|
|
|
|
|
if (args->size)
|
|
|
|
ret = -EINVAL;
|
2019-03-22 16:23:24 +07: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 03:34:53 +07: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 19:32:03 +07: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 03:34:53 +07:00
|
|
|
}
|
|
|
|
break;
|
2019-03-22 16:23:23 +07: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 16:50:31 +07:00
|
|
|
case I915_CONTEXT_PARAM_SSEU:
|
|
|
|
ret = set_sseu(ctx, args);
|
|
|
|
break;
|
2019-03-22 16:23:23 +07:00
|
|
|
|
|
|
|
case I915_CONTEXT_PARAM_VM:
|
2019-03-30 17:03:49 +07:00
|
|
|
ret = set_ppgtt(fpriv, ctx, args);
|
2019-03-22 16:23:23 +07:00
|
|
|
break;
|
|
|
|
|
|
|
|
case I915_CONTEXT_PARAM_BAN_PERIOD:
|
2014-12-24 23:13:40 +07:00
|
|
|
default:
|
|
|
|
ret = -EINVAL;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2019-03-22 16:23:24 +07: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 17:03:49 +07:00
|
|
|
return ctx_setparam(arg->fpriv, arg->ctx, &local.param);
|
2019-03-22 16:23:24 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
static const i915_user_extension_fn create_extensions[] = {
|
|
|
|
[I915_CONTEXT_CREATE_EXT_SETPARAM] = create_setparam,
|
|
|
|
};
|
|
|
|
|
|
|
|
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;
|
|
|
|
|
|
|
|
ret = i915_terminally_wedged(i915);
|
|
|
|
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",
|
|
|
|
current->comm,
|
|
|
|
pid_nr(get_task_pid(current, PIDTYPE_PID)));
|
|
|
|
return -EIO;
|
|
|
|
}
|
|
|
|
|
|
|
|
ret = i915_mutex_lock_interruptible(dev);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2019-03-22 16:23:25 +07:00
|
|
|
ext_data.ctx = i915_gem_create_context(i915, args->flags);
|
2019-03-22 16:23:24 +07:00
|
|
|
mutex_unlock(&dev->struct_mutex);
|
|
|
|
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:
|
|
|
|
mutex_lock(&dev->struct_mutex);
|
|
|
|
context_close(ext_data.ctx);
|
|
|
|
mutex_unlock(&dev->struct_mutex);
|
|
|
|
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;
|
|
|
|
|
|
|
|
mutex_lock(&dev->struct_mutex);
|
|
|
|
context_close(ctx);
|
|
|
|
mutex_unlock(&dev->struct_mutex);
|
|
|
|
|
|
|
|
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_engine_cs *engine;
|
|
|
|
struct intel_context *ce;
|
|
|
|
|
|
|
|
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;
|
|
|
|
|
|
|
|
if (user_sseu.flags || user_sseu.rsvd)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
engine = intel_engine_lookup_user(ctx->i915,
|
|
|
|
user_sseu.engine_class,
|
|
|
|
user_sseu.engine_instance);
|
|
|
|
if (!engine)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
ce = intel_context_pin_lock(ctx, engine); /* serialises with set_sseu */
|
|
|
|
if (IS_ERR(ce))
|
|
|
|
return PTR_ERR(ce);
|
|
|
|
|
|
|
|
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;
|
|
|
|
|
|
|
|
intel_context_pin_unlock(ce);
|
|
|
|
|
|
|
|
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;
|
|
|
|
if (ctx->ppgtt)
|
|
|
|
args->value = ctx->ppgtt->vm.total;
|
|
|
|
else if (to_i915(dev)->mm.aliasing_ppgtt)
|
|
|
|
args->value = to_i915(dev)->mm.aliasing_ppgtt->vm.total;
|
|
|
|
else
|
|
|
|
args->value = to_i915(dev)->ggtt.vm.total;
|
|
|
|
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 17:03:49 +07:00
|
|
|
ret = get_ppgtt(file_priv, ctx, args);
|
2019-03-22 16:23:24 +07:00
|
|
|
break;
|
|
|
|
|
|
|
|
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 17:03:49 +07:00
|
|
|
ret = ctx_setparam(file_priv, ctx, args);
|
2019-03-22 16:23:24 +07:00
|
|
|
|
2017-06-20 18:05:47 +07:00
|
|
|
i915_gem_context_put(ctx);
|
2014-12-24 23:13:40 +07:00
|
|
|
return ret;
|
|
|
|
}
|
2016-05-13 17:57:19 +07:00
|
|
|
|
|
|
|
int i915_gem_context_reset_stats_ioctl(struct drm_device *dev,
|
|
|
|
void *data, struct drm_file *file)
|
|
|
|
{
|
2016-07-04 17:34:36 +07:00
|
|
|
struct drm_i915_private *dev_priv = to_i915(dev);
|
2016-05-13 17:57:19 +07:00
|
|
|
struct drm_i915_reset_stats *args = data;
|
2016-05-24 20:53:34 +07:00
|
|
|
struct i915_gem_context *ctx;
|
2016-05-13 17:57:19 +07:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (args->flags || args->pad)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2017-06-20 18:05:47 +07: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 17:57:19 +07:00
|
|
|
|
2017-06-20 18:05:47 +07: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 17:57:19 +07:00
|
|
|
|
|
|
|
if (capable(CAP_SYS_ADMIN))
|
|
|
|
args->reset_count = i915_reset_count(&dev_priv->gpu_error);
|
|
|
|
else
|
|
|
|
args->reset_count = 0;
|
|
|
|
|
2017-07-21 19:32:30 +07:00
|
|
|
args->batch_active = atomic_read(&ctx->guilty_count);
|
|
|
|
args->batch_pending = atomic_read(&ctx->active_count);
|
2016-05-13 17:57:19 +07:00
|
|
|
|
2017-06-20 18:05:47 +07:00
|
|
|
ret = 0;
|
|
|
|
out:
|
|
|
|
rcu_read_unlock();
|
|
|
|
return ret;
|
2016-05-13 17:57:19 +07:00
|
|
|
}
|
2017-02-14 00:15:19 +07:00
|
|
|
|
2018-09-04 22:31:17 +07:00
|
|
|
int __i915_gem_context_pin_hw_id(struct i915_gem_context *ctx)
|
|
|
|
{
|
|
|
|
struct drm_i915_private *i915 = ctx->i915;
|
|
|
|
int err = 0;
|
|
|
|
|
|
|
|
mutex_lock(&i915->contexts.mutex);
|
|
|
|
|
|
|
|
GEM_BUG_ON(i915_gem_context_is_closed(ctx));
|
|
|
|
|
|
|
|
if (list_empty(&ctx->hw_id_link)) {
|
|
|
|
GEM_BUG_ON(atomic_read(&ctx->hw_id_pin_count));
|
|
|
|
|
|
|
|
err = assign_hw_id(i915, &ctx->hw_id);
|
|
|
|
if (err)
|
|
|
|
goto out_unlock;
|
|
|
|
|
|
|
|
list_add_tail(&ctx->hw_id_link, &i915->contexts.hw_id_list);
|
|
|
|
}
|
|
|
|
|
|
|
|
GEM_BUG_ON(atomic_read(&ctx->hw_id_pin_count) == ~0u);
|
|
|
|
atomic_inc(&ctx->hw_id_pin_count);
|
|
|
|
|
|
|
|
out_unlock:
|
|
|
|
mutex_unlock(&i915->contexts.mutex);
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2017-02-14 00:15:19 +07:00
|
|
|
#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
|
|
|
|
#include "selftests/mock_context.c"
|
2017-02-14 00:15:49 +07:00
|
|
|
#include "selftests/i915_gem_context.c"
|
2017-02-14 00:15:19 +07:00
|
|
|
#endif
|
2019-02-28 17:20:34 +07:00
|
|
|
|
2019-03-08 20:25:19 +07:00
|
|
|
static void i915_global_gem_context_shrink(void)
|
2019-02-28 17:20:34 +07:00
|
|
|
{
|
2019-03-06 04:38:30 +07:00
|
|
|
kmem_cache_shrink(global.slab_luts);
|
2019-02-28 17:20:34 +07:00
|
|
|
}
|
|
|
|
|
2019-03-08 20:25:19 +07:00
|
|
|
static void i915_global_gem_context_exit(void)
|
2019-02-28 17:20:34 +07:00
|
|
|
{
|
2019-03-06 04:38:30 +07:00
|
|
|
kmem_cache_destroy(global.slab_luts);
|
2019-02-28 17:20:34 +07:00
|
|
|
}
|
|
|
|
|
2019-03-08 20:25:19 +07:00
|
|
|
static struct i915_global_gem_context global = { {
|
|
|
|
.shrink = i915_global_gem_context_shrink,
|
|
|
|
.exit = i915_global_gem_context_exit,
|
2019-03-06 04:38:30 +07:00
|
|
|
} };
|
|
|
|
|
2019-03-08 20:25:19 +07:00
|
|
|
int __init i915_global_gem_context_init(void)
|
2019-02-28 17:20:34 +07:00
|
|
|
{
|
2019-03-06 04:38:30 +07: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 17:20:34 +07:00
|
|
|
}
|