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-04 21:42:42 +00: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 13:40:26 +00: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-04 21:42:42 +00: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.
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
|
2012-10-02 17:01:07 +00:00
|
|
|
#include <drm/drmP.h>
|
|
|
|
#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-04 21:42:42 +00:00
|
|
|
#include "i915_drv.h"
|
2014-11-10 13:44:31 +00:00
|
|
|
#include "i915_trace.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-04 21:42:42 +00:00
|
|
|
|
2016-04-28 08:56:41 +00:00
|
|
|
#define ALL_L3_SLICES(dev) (1 << NUM_L3_SLICES(dev)) - 1
|
|
|
|
|
2012-06-04 21:42:43 +00:00
|
|
|
/* This is a HW constraint. The value below is the largest known requirement
|
|
|
|
* I've seen in a spec to date, and that was a workaround for a non-shipping
|
|
|
|
* part. It should be safe to decrease this, but it's more future proof as is.
|
|
|
|
*/
|
2013-12-06 22:10:59 +00:00
|
|
|
#define GEN6_CONTEXT_ALIGN (64<<10)
|
2017-01-10 14:47:34 +00:00
|
|
|
#define GEN7_CONTEXT_ALIGN I915_GTT_MIN_ALIGNMENT
|
2012-06-04 21:42:43 +00:00
|
|
|
|
2016-05-06 14:40:21 +00:00
|
|
|
static size_t get_context_alignment(struct drm_i915_private *dev_priv)
|
2013-12-06 22:10:59 +00:00
|
|
|
{
|
2016-05-06 14:40:21 +00:00
|
|
|
if (IS_GEN6(dev_priv))
|
2013-12-06 22:10:59 +00:00
|
|
|
return GEN6_CONTEXT_ALIGN;
|
|
|
|
|
|
|
|
return GEN7_CONTEXT_ALIGN;
|
|
|
|
}
|
|
|
|
|
2016-05-06 14:40:21 +00:00
|
|
|
static int get_context_size(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-04 21:42:42 +00:00
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
u32 reg;
|
|
|
|
|
2016-05-06 14:40:21 +00:00
|
|
|
switch (INTEL_GEN(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-04 21:42:42 +00:00
|
|
|
case 6:
|
|
|
|
reg = I915_READ(CXT_SIZE);
|
|
|
|
ret = GEN6_CXT_TOTAL_SIZE(reg) * 64;
|
|
|
|
break;
|
|
|
|
case 7:
|
2012-07-18 17:10:09 +00:00
|
|
|
reg = I915_READ(GEN7_CXT_SIZE);
|
2016-05-06 14:40:21 +00:00
|
|
|
if (IS_HASWELL(dev_priv))
|
2013-06-26 04:53:40 +00:00
|
|
|
ret = HSW_CXT_TOTAL_SIZE;
|
2012-07-25 03:47:30 +00:00
|
|
|
else
|
|
|
|
ret = GEN7_CXT_TOTAL_SIZE(reg) * 64;
|
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-04 21:42:42 +00:00
|
|
|
break;
|
2013-11-03 04:07:05 +00:00
|
|
|
case 8:
|
|
|
|
ret = GEN8_CXT_TOTAL_SIZE;
|
|
|
|
break;
|
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-04 21:42:42 +00:00
|
|
|
default:
|
|
|
|
BUG();
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2013-04-30 10:30:33 +00:00
|
|
|
void i915_gem_context_free(struct kref *ctx_ref)
|
2012-06-04 21:42:43 +00:00
|
|
|
{
|
2016-05-24 13:53:34 +00:00
|
|
|
struct i915_gem_context *ctx = container_of(ctx_ref, typeof(*ctx), ref);
|
2016-05-24 13:53:41 +00:00
|
|
|
int i;
|
2012-06-04 21:42:43 +00:00
|
|
|
|
2016-07-05 09:40:23 +00:00
|
|
|
lockdep_assert_held(&ctx->i915->drm.struct_mutex);
|
2014-11-10 13:44:31 +00:00
|
|
|
trace_i915_context_free(ctx);
|
2016-12-31 11:20:11 +00:00
|
|
|
GEM_BUG_ON(!i915_gem_context_is_closed(ctx));
|
2014-11-10 13:44:31 +00:00
|
|
|
|
2014-08-06 13:04:53 +00:00
|
|
|
i915_ppgtt_put(ctx->ppgtt);
|
|
|
|
|
2016-05-24 13:53:41 +00:00
|
|
|
for (i = 0; i < I915_NUM_ENGINES; i++) {
|
|
|
|
struct intel_context *ce = &ctx->engine[i];
|
|
|
|
|
|
|
|
if (!ce->state)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
WARN_ON(ce->pin_count);
|
2016-08-02 21:50:20 +00:00
|
|
|
if (ce->ring)
|
2016-08-02 21:50:21 +00:00
|
|
|
intel_ring_free(ce->ring);
|
2016-05-24 13:53:41 +00:00
|
|
|
|
2016-10-28 12:58:29 +00:00
|
|
|
__i915_gem_object_release_unless_active(ce->state->obj);
|
2016-05-24 13:53:41 +00:00
|
|
|
}
|
|
|
|
|
2016-10-28 12:58:54 +00:00
|
|
|
kfree(ctx->name);
|
2016-08-15 09:49:08 +00:00
|
|
|
put_pid(ctx->pid);
|
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-06 22:11:15 +00:00
|
|
|
list_del(&ctx->link);
|
2016-04-28 08:56:51 +00:00
|
|
|
|
|
|
|
ida_simple_remove(&ctx->i915->context_hw_ida, ctx->hw_id);
|
2012-06-04 21:42:43 +00:00
|
|
|
kfree(ctx);
|
|
|
|
}
|
|
|
|
|
2016-11-23 10:49:15 +00:00
|
|
|
static struct drm_i915_gem_object *
|
2016-12-01 14:16:38 +00:00
|
|
|
alloc_context_obj(struct drm_i915_private *dev_priv, u64 size)
|
2014-07-03 15:27:58 +00:00
|
|
|
{
|
|
|
|
struct drm_i915_gem_object *obj;
|
|
|
|
int ret;
|
|
|
|
|
2016-12-01 14:16:38 +00:00
|
|
|
lockdep_assert_held(&dev_priv->drm.struct_mutex);
|
2016-05-24 13:53:35 +00:00
|
|
|
|
2016-12-01 14:16:37 +00:00
|
|
|
obj = i915_gem_object_create(dev_priv, size);
|
2016-04-25 12:32:13 +00:00
|
|
|
if (IS_ERR(obj))
|
|
|
|
return obj;
|
2014-07-03 15:27:58 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Try to make the context utilize L3 as well as LLC.
|
|
|
|
*
|
|
|
|
* On VLV we don't have L3 controls in the PTEs so we
|
|
|
|
* shouldn't touch the cache level, especially as that
|
|
|
|
* would make the object snooped which might have a
|
|
|
|
* negative performance impact.
|
2015-12-08 17:38:52 +00:00
|
|
|
*
|
|
|
|
* Snooping is required on non-llc platforms in execlist
|
|
|
|
* mode, but since all GGTT accesses use PAT entry 0 we
|
|
|
|
* get snooping anyway regardless of cache_level.
|
|
|
|
*
|
|
|
|
* This is only applicable for Ivy Bridge devices since
|
|
|
|
* later platforms don't have L3 control bits in the PTE.
|
2014-07-03 15:27:58 +00:00
|
|
|
*/
|
2016-12-01 14:16:37 +00:00
|
|
|
if (IS_IVYBRIDGE(dev_priv)) {
|
2014-07-03 15:27:58 +00:00
|
|
|
ret = i915_gem_object_set_cache_level(obj, I915_CACHE_L3_LLC);
|
|
|
|
/* Failure shouldn't ever happen this early */
|
|
|
|
if (WARN_ON(ret)) {
|
2016-07-20 12:31:53 +00:00
|
|
|
i915_gem_object_put(obj);
|
2014-07-03 15:27:58 +00:00
|
|
|
return ERR_PTR(ret);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
return obj;
|
|
|
|
}
|
|
|
|
|
2016-08-04 06:52:46 +00:00
|
|
|
static void context_close(struct i915_gem_context *ctx)
|
|
|
|
{
|
2016-12-31 11:20:11 +00:00
|
|
|
i915_gem_context_set_closed(ctx);
|
2016-08-04 06:52:46 +00:00
|
|
|
if (ctx->ppgtt)
|
|
|
|
i915_ppgtt_close(&ctx->ppgtt->base);
|
|
|
|
ctx->file_priv = ERR_PTR(-EBADF);
|
|
|
|
i915_gem_context_put(ctx);
|
|
|
|
}
|
|
|
|
|
2016-04-28 08:56:51 +00:00
|
|
|
static int assign_hw_id(struct drm_i915_private *dev_priv, unsigned *out)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = ida_simple_get(&dev_priv->context_hw_ida,
|
|
|
|
0, MAX_CONTEXT_HW_ID, GFP_KERNEL);
|
|
|
|
if (ret < 0) {
|
|
|
|
/* Contexts are only released when no longer active.
|
|
|
|
* Flush any pending retires to hopefully release some
|
|
|
|
* stale contexts and try again.
|
|
|
|
*/
|
2016-05-06 14:40:21 +00:00
|
|
|
i915_gem_retire_requests(dev_priv);
|
2016-04-28 08:56:51 +00:00
|
|
|
ret = ida_simple_get(&dev_priv->context_hw_ida,
|
|
|
|
0, MAX_CONTEXT_HW_ID, GFP_KERNEL);
|
|
|
|
if (ret < 0)
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
*out = ret;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2017-02-09 14:40:36 +00:00
|
|
|
static u32 default_desc_template(const struct drm_i915_private *i915,
|
|
|
|
const struct i915_hw_ppgtt *ppgtt)
|
2017-01-27 13:03:09 +00:00
|
|
|
{
|
2017-02-09 14:40:36 +00:00
|
|
|
u32 address_mode;
|
2017-01-27 13:03:09 +00:00
|
|
|
u32 desc;
|
|
|
|
|
2017-02-09 14:40:36 +00:00
|
|
|
desc = GEN8_CTX_VALID | GEN8_CTX_PRIVILEGE;
|
2017-01-27 13:03:09 +00:00
|
|
|
|
2017-02-09 14:40:36 +00:00
|
|
|
address_mode = INTEL_LEGACY_32B_CONTEXT;
|
|
|
|
if (ppgtt && i915_vm_is_48bit(&ppgtt->base))
|
|
|
|
address_mode = INTEL_LEGACY_64B_CONTEXT;
|
|
|
|
desc |= address_mode << GEN8_CTX_ADDRESSING_MODE_SHIFT;
|
|
|
|
|
|
|
|
if (IS_GEN8(i915))
|
2017-01-27 13:03:09 +00: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 13:53:34 +00:00
|
|
|
static struct i915_gem_context *
|
2016-12-01 14:16:38 +00:00
|
|
|
__create_hw_context(struct drm_i915_private *dev_priv,
|
2014-08-06 13:04:45 +00:00
|
|
|
struct drm_i915_file_private *file_priv)
|
2012-06-04 21:42:43 +00:00
|
|
|
{
|
2016-05-24 13:53:34 +00:00
|
|
|
struct i915_gem_context *ctx;
|
2013-02-28 01:04:10 +00:00
|
|
|
int ret;
|
2012-06-04 21:42:43 +00:00
|
|
|
|
2012-11-10 18:56:04 +00:00
|
|
|
ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
|
2012-06-29 17:30:39 +00:00
|
|
|
if (ctx == NULL)
|
|
|
|
return ERR_PTR(-ENOMEM);
|
2012-06-04 21:42:43 +00:00
|
|
|
|
2016-04-28 08:56:51 +00:00
|
|
|
ret = assign_hw_id(dev_priv, &ctx->hw_id);
|
|
|
|
if (ret) {
|
|
|
|
kfree(ctx);
|
|
|
|
return ERR_PTR(ret);
|
|
|
|
}
|
|
|
|
|
2013-04-30 10:30:33 +00:00
|
|
|
kref_init(&ctx->ref);
|
2014-04-09 08:07:36 +00:00
|
|
|
list_add_tail(&ctx->link, &dev_priv->context_list);
|
2015-05-05 08:17:29 +00:00
|
|
|
ctx->i915 = dev_priv;
|
2012-06-04 21:42:43 +00:00
|
|
|
|
2016-06-24 13:55:53 +00:00
|
|
|
ctx->ggtt_alignment = get_context_alignment(dev_priv);
|
|
|
|
|
2014-04-09 08:07:36 +00:00
|
|
|
if (dev_priv->hw_context_size) {
|
2016-08-15 09:48:54 +00:00
|
|
|
struct drm_i915_gem_object *obj;
|
|
|
|
struct i915_vma *vma;
|
|
|
|
|
2016-12-01 14:16:38 +00:00
|
|
|
obj = alloc_context_obj(dev_priv, dev_priv->hw_context_size);
|
2014-07-03 15:27:58 +00:00
|
|
|
if (IS_ERR(obj)) {
|
|
|
|
ret = PTR_ERR(obj);
|
2013-04-08 13:28:40 +00:00
|
|
|
goto err_out;
|
2014-04-09 08:07:36 +00:00
|
|
|
}
|
2016-08-15 09:48:54 +00:00
|
|
|
|
2017-01-16 15:21:30 +00:00
|
|
|
vma = i915_vma_instance(obj, &dev_priv->ggtt.base, NULL);
|
2016-08-15 09:48:54 +00:00
|
|
|
if (IS_ERR(vma)) {
|
|
|
|
i915_gem_object_put(obj);
|
|
|
|
ret = PTR_ERR(vma);
|
|
|
|
goto err_out;
|
|
|
|
}
|
|
|
|
|
|
|
|
ctx->engine[RCS].state = vma;
|
2014-04-09 08:07:36 +00:00
|
|
|
}
|
2012-06-04 21:42:43 +00:00
|
|
|
|
|
|
|
/* Default context will never have a file_priv */
|
2016-10-28 12:58:54 +00:00
|
|
|
ret = DEFAULT_CONTEXT_HANDLE;
|
|
|
|
if (file_priv) {
|
2014-04-09 08:07:36 +00:00
|
|
|
ret = idr_alloc(&file_priv->context_idr, ctx,
|
drm/i915: Emphasize that ctx->id is merely a user handle
This is an Execlists preparatory patch, since they make context ID become an
overloaded term:
- In the software, it was used to distinguish which context userspace was
trying to use.
- In the BSpec, the term is used to describe the 20-bits long field the
hardware uses to it to discriminate the contexts that are submitted to
the ELSP and inform the driver about their current status (via Context
Switch Interrupts and Context Status Buffers).
Initially, I tried to make the different meanings converge, but it proved
impossible:
- The software ctx->id is per-filp, while the hardware one needs to be
globally unique.
- Also, we multiplex several backing states objects per intel_context,
and all of them need unique HW IDs.
- I tried adding a per-filp ID and then composing the HW context ID as:
ctx->id + file_priv->id + ring->id, but the fact that the hardware only
uses 20-bits means we have to artificially limit the number of filps or
contexts the userspace can create.
The ctx->user_handle renaming bits are done with this Cocci patch (plus
manual frobbing of the struct declaration):
@@
struct intel_context c;
@@
- (c).id
+ c.user_handle
@@
struct intel_context *c;
@@
- (c)->id
+ c->user_handle
Also, while we are at it, s/DEFAULT_CONTEXT_ID/DEFAULT_CONTEXT_HANDLE and
change the type to unsigned 32 bits.
v2: s/handle/user_handle and change the type to uint32_t as suggested by
Chris Wilson.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v1)
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-07-03 15:28:00 +00:00
|
|
|
DEFAULT_CONTEXT_HANDLE, 0, GFP_KERNEL);
|
2014-04-09 08:07:36 +00:00
|
|
|
if (ret < 0)
|
|
|
|
goto err_out;
|
2016-10-28 12:58:54 +00:00
|
|
|
}
|
|
|
|
ctx->user_handle = ret;
|
2013-04-30 10:30:33 +00:00
|
|
|
|
|
|
|
ctx->file_priv = file_priv;
|
2016-10-28 12:58:54 +00:00
|
|
|
if (file_priv) {
|
2016-08-15 09:49:08 +00:00
|
|
|
ctx->pid = get_task_pid(current, PIDTYPE_PID);
|
2016-10-28 12:58:54 +00:00
|
|
|
ctx->name = kasprintf(GFP_KERNEL, "%s[%d]/%x",
|
|
|
|
current->comm,
|
|
|
|
pid_nr(ctx->pid),
|
|
|
|
ctx->user_handle);
|
|
|
|
if (!ctx->name) {
|
|
|
|
ret = -ENOMEM;
|
|
|
|
goto err_pid;
|
|
|
|
}
|
|
|
|
}
|
2016-08-15 09:49:08 +00: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 02:03:18 +00: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 08:56:41 +00:00
|
|
|
ctx->remap_slice = ALL_L3_SLICES(dev_priv);
|
2012-06-04 21:42:43 +00:00
|
|
|
|
2016-12-31 11:20:11 +00:00
|
|
|
i915_gem_context_set_bannable(ctx);
|
2016-06-16 12:07:01 +00:00
|
|
|
ctx->ring_size = 4 * PAGE_SIZE;
|
2017-02-09 14:40:36 +00:00
|
|
|
ctx->desc_template =
|
|
|
|
default_desc_template(dev_priv, dev_priv->mm.aliasing_ppgtt);
|
2016-06-16 12:07:03 +00:00
|
|
|
ATOMIC_INIT_NOTIFIER_HEAD(&ctx->status_notifier);
|
2014-12-24 16:13:39 +00:00
|
|
|
|
2016-12-23 23:56:21 +00:00
|
|
|
/* GuC requires the ring to be placed above GUC_WOPCM_TOP. If GuC is not
|
|
|
|
* present or not in use we still need a small bias as ring wraparound
|
|
|
|
* at offset 0 sometimes hangs. No idea why.
|
|
|
|
*/
|
|
|
|
if (HAS_GUC(dev_priv) && i915.enable_guc_loading)
|
|
|
|
ctx->ggtt_offset_bias = GUC_WOPCM_TOP;
|
|
|
|
else
|
2017-01-10 14:47:34 +00:00
|
|
|
ctx->ggtt_offset_bias = I915_GTT_PAGE_SIZE;
|
2016-12-23 23:56:21 +00:00
|
|
|
|
2012-06-29 17:30:39 +00:00
|
|
|
return ctx;
|
2012-06-04 21:42:43 +00:00
|
|
|
|
2016-10-28 12:58:54 +00:00
|
|
|
err_pid:
|
|
|
|
put_pid(ctx->pid);
|
|
|
|
idr_remove(&file_priv->context_idr, ctx->user_handle);
|
2012-06-04 21:42:43 +00:00
|
|
|
err_out:
|
2016-08-04 06:52:46 +00:00
|
|
|
context_close(ctx);
|
2012-06-29 17:30:39 +00:00
|
|
|
return ERR_PTR(ret);
|
2012-06-04 21:42:43 +00:00
|
|
|
}
|
|
|
|
|
2017-02-09 11:34:25 +00:00
|
|
|
static void __destroy_hw_context(struct i915_gem_context *ctx,
|
|
|
|
struct drm_i915_file_private *file_priv)
|
|
|
|
{
|
|
|
|
idr_remove(&file_priv->context_idr, ctx->user_handle);
|
|
|
|
context_close(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-04 21:42:42 +00:00
|
|
|
/**
|
|
|
|
* The default context needs to exist per ring that uses contexts. It stores the
|
|
|
|
* context state of the GPU for applications that don't utilize HW contexts, as
|
|
|
|
* well as an idle case.
|
|
|
|
*/
|
2016-05-24 13:53:34 +00:00
|
|
|
static struct i915_gem_context *
|
2016-12-01 14:16:38 +00:00
|
|
|
i915_gem_create_context(struct drm_i915_private *dev_priv,
|
2014-08-06 13:04:54 +00:00
|
|
|
struct drm_i915_file_private *file_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-04 21:42:42 +00:00
|
|
|
{
|
2016-05-24 13:53:34 +00:00
|
|
|
struct i915_gem_context *ctx;
|
2012-06-04 21:42:43 +00:00
|
|
|
|
2016-12-01 14:16:38 +00:00
|
|
|
lockdep_assert_held(&dev_priv->drm.struct_mutex);
|
2012-06-04 21:42:43 +00:00
|
|
|
|
2016-12-01 14:16:38 +00:00
|
|
|
ctx = __create_hw_context(dev_priv, file_priv);
|
2012-06-29 17:30:39 +00:00
|
|
|
if (IS_ERR(ctx))
|
2013-12-06 22:11:05 +00:00
|
|
|
return ctx;
|
2012-06-04 21:42:43 +00:00
|
|
|
|
2016-12-01 14:16:38 +00:00
|
|
|
if (USES_FULL_PPGTT(dev_priv)) {
|
2016-10-28 12:58:58 +00:00
|
|
|
struct i915_hw_ppgtt *ppgtt;
|
2013-12-06 22:11:18 +00:00
|
|
|
|
2016-12-01 14:16:38 +00:00
|
|
|
ppgtt = i915_ppgtt_create(dev_priv, file_priv, ctx->name);
|
2016-05-24 13:53:38 +00:00
|
|
|
if (IS_ERR(ppgtt)) {
|
2013-12-06 22:11:19 +00:00
|
|
|
DRM_DEBUG_DRIVER("PPGTT setup failed (%ld)\n",
|
|
|
|
PTR_ERR(ppgtt));
|
2017-02-09 11:34:25 +00:00
|
|
|
__destroy_hw_context(ctx, file_priv);
|
2016-05-24 13:53:38 +00:00
|
|
|
return ERR_CAST(ppgtt);
|
2014-08-06 13:04:53 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
ctx->ppgtt = ppgtt;
|
2017-02-09 14:40:36 +00:00
|
|
|
ctx->desc_template = default_desc_template(dev_priv, ppgtt);
|
2014-08-06 13:04:53 +00:00
|
|
|
}
|
2013-12-06 22:11:18 +00:00
|
|
|
|
2014-11-10 13:44:31 +00:00
|
|
|
trace_i915_context_create(ctx);
|
|
|
|
|
2013-12-06 22:11:05 +00: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-04 21:42:42 +00:00
|
|
|
}
|
|
|
|
|
2016-06-16 12:07:05 +00: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);
|
|
|
|
|
2017-01-06 15:20:13 +00:00
|
|
|
ctx = __create_hw_context(to_i915(dev), NULL);
|
2016-06-16 12:07:05 +00:00
|
|
|
if (IS_ERR(ctx))
|
|
|
|
goto out;
|
|
|
|
|
2017-01-06 15:20:13 +00:00
|
|
|
ctx->file_priv = ERR_PTR(-EBADF);
|
2016-12-31 11:20:11 +00: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-02-16 06:36:40 +00:00
|
|
|
if (!i915.enable_guc_submission)
|
|
|
|
ctx->ring_size = 512 * PAGE_SIZE; /* Max ring buffer size */
|
2017-01-06 15:20:13 +00:00
|
|
|
|
|
|
|
GEM_BUG_ON(i915_gem_context_is_kernel(ctx));
|
2016-06-16 12:07:05 +00:00
|
|
|
out:
|
|
|
|
mutex_unlock(&dev->struct_mutex);
|
|
|
|
return ctx;
|
|
|
|
}
|
|
|
|
|
2016-12-01 14:16:38 +00:00
|
|
|
int i915_gem_context_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-04 21:42:42 +00:00
|
|
|
{
|
2016-05-24 13:53:34 +00: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-04 21:42:42 +00:00
|
|
|
|
drm/i915: Split context enabling from init
We **need** to do this for exactly 1 reason, because we want to embed a
PPGTT into the context, but we don't want to special case the default
context.
To achieve that, we must be able to initialize contexts after the GTT is
setup (so we can allocate and pin the default context's BO), but before
the PPGTT and rings are initialized. This is because, currently, context
initialization requires ring usage. We don't have rings until after the
GTT is setup. If we split the enabling part of context initialization,
the part requiring the ringbuffer, we can untangle this, and then later
embed the PPGTT
Incidentally this allows us to also adhere to the original design of
context init/fini in future patches: they were only ever meant to be
called at driver load and unload.
v2: Move hw_contexts_disabled test in i915_gem_context_enable() (Chris)
v3: BUG_ON after checking for disabled contexts. Or else it blows up pre
gen6 (Ben)
v4: Forward port
Modified enable for each ring, since that patch is earlier in the series
Dropped ring arg from create_default_context so it can be used by others
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-06 22:11:04 +00:00
|
|
|
/* Init should only be called once per module load. Eventually the
|
|
|
|
* restriction on the context_disabled check can be loosened. */
|
2016-01-19 19:02:54 +00:00
|
|
|
if (WARN_ON(dev_priv->kernel_context))
|
2013-11-06 15:56:29 +00: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-04 21:42:42 +00:00
|
|
|
|
2016-05-06 14:40:21 +00:00
|
|
|
if (intel_vgpu_active(dev_priv) &&
|
|
|
|
HAS_LOGICAL_RING_CONTEXTS(dev_priv)) {
|
2015-08-28 07:41:16 +00:00
|
|
|
if (!i915.enable_execlists) {
|
|
|
|
DRM_INFO("Only EXECLIST mode is supported in vgpu.\n");
|
|
|
|
return -EINVAL;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2016-04-28 08:56:51 +00:00
|
|
|
/* Using the simple ida interface, the max is limited by sizeof(int) */
|
|
|
|
BUILD_BUG_ON(MAX_CONTEXT_HW_ID > INT_MAX);
|
|
|
|
ida_init(&dev_priv->context_hw_ida);
|
|
|
|
|
2014-07-24 16:04:12 +00:00
|
|
|
if (i915.enable_execlists) {
|
|
|
|
/* NB: intentionally left blank. We will allocate our own
|
|
|
|
* backing objects as we need them, thank you very much */
|
|
|
|
dev_priv->hw_context_size = 0;
|
2016-05-06 14:40:21 +00:00
|
|
|
} else if (HAS_HW_CONTEXTS(dev_priv)) {
|
|
|
|
dev_priv->hw_context_size =
|
2017-01-10 14:47:34 +00:00
|
|
|
round_up(get_context_size(dev_priv),
|
|
|
|
I915_GTT_PAGE_SIZE);
|
2014-04-09 08:07:36 +00:00
|
|
|
if (dev_priv->hw_context_size > (1<<20)) {
|
|
|
|
DRM_DEBUG_DRIVER("Disabling HW Contexts; invalid size %d\n",
|
|
|
|
dev_priv->hw_context_size);
|
|
|
|
dev_priv->hw_context_size = 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-04 21:42:42 +00:00
|
|
|
}
|
|
|
|
|
2016-12-01 14:16:38 +00:00
|
|
|
ctx = i915_gem_create_context(dev_priv, NULL);
|
2014-04-09 08:07:36 +00:00
|
|
|
if (IS_ERR(ctx)) {
|
|
|
|
DRM_ERROR("Failed to create default global context (error %ld)\n",
|
|
|
|
PTR_ERR(ctx));
|
|
|
|
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-04 21:42:42 +00:00
|
|
|
}
|
|
|
|
|
2017-01-23 11:31:31 +00:00
|
|
|
/* For easy recognisablity, we want the kernel context to be 0 and then
|
|
|
|
* all user contexts will have non-zero hw_id.
|
|
|
|
*/
|
|
|
|
GEM_BUG_ON(ctx->hw_id);
|
|
|
|
|
2016-12-31 11:20:11 +00:00
|
|
|
i915_gem_context_clear_bannable(ctx);
|
2016-11-14 20:41:04 +00:00
|
|
|
ctx->priority = I915_PRIORITY_MIN; /* lowest priority; idle task */
|
2016-01-19 19:02:54 +00:00
|
|
|
dev_priv->kernel_context = ctx;
|
2013-12-06 22:11:01 +00:00
|
|
|
|
2017-01-06 15:20:13 +00:00
|
|
|
GEM_BUG_ON(!i915_gem_context_is_kernel(ctx));
|
|
|
|
|
2014-07-24 16:04:12 +00:00
|
|
|
DRM_DEBUG_DRIVER("%s context support initialized\n",
|
|
|
|
i915.enable_execlists ? "LR" :
|
|
|
|
dev_priv->hw_context_size ? "HW" : "fake");
|
2013-11-06 15:56:29 +00: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-04 21:42:42 +00:00
|
|
|
}
|
|
|
|
|
2016-04-28 08:56:41 +00:00
|
|
|
void i915_gem_context_lost(struct drm_i915_private *dev_priv)
|
|
|
|
{
|
|
|
|
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-13 17:14:48 +00:00
|
|
|
enum intel_engine_id id;
|
2016-04-28 08:56:41 +00:00
|
|
|
|
2016-07-05 09:40:23 +00:00
|
|
|
lockdep_assert_held(&dev_priv->drm.struct_mutex);
|
2016-05-24 13:53:35 +00:00
|
|
|
|
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-13 17:14:48 +00:00
|
|
|
for_each_engine(engine, dev_priv, id) {
|
drm/i915: Unify active context tracking between legacy/execlists/guc
The requests conversion introduced a nasty bug where we could generate a
new request in the middle of constructing a request if we needed to idle
the system in order to evict space for a context. The request to idle
would be executed (and waited upon) before the current one, creating a
minor havoc in the seqno accounting, as we will consider the current
request to already be completed (prior to deferred seqno assignment) but
ring->last_retired_head would have been updated and still could allow
us to overwrite the current request before execution.
We also employed two different mechanisms to track the active context
until it was switched out. The legacy method allowed for waiting upon an
active context (it could forcibly evict any vma, including context's),
but the execlists method took a step backwards by pinning the vma for
the entire active lifespan of the context (the only way to evict was to
idle the entire GPU, not individual contexts). However, to circumvent
the tricky issue of locking (i.e. we cannot take struct_mutex at the
time of i915_gem_request_submit(), where we would want to move the
previous context onto the active tracker and unpin it), we take the
execlists approach and keep the contexts pinned until retirement.
The benefit of the execlists approach, more important for execlists than
legacy, was the reduction in work in pinning the context for each
request - as the context was kept pinned until idle, it could short
circuit the pinning for all active contexts.
We introduce new engine vfuncs to pin and unpin the context
respectively. The context is pinned at the start of the request, and
only unpinned when the following request is retired (this ensures that
the context is idle and coherent in main memory before we unpin it). We
move the engine->last_context tracking into the retirement itself
(rather than during request submission) in order to allow the submission
to be reordered or unwound without undue difficultly.
And finally an ulterior motive for unifying context handling was to
prepare for mock requests.
v2: Rename to last_retired_context, split out legacy_context tracking
for MI_SET_CONTEXT.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161218153724.8439-3-chris@chris-wilson.co.uk
2016-12-18 15:37:20 +00:00
|
|
|
engine->legacy_active_context = NULL;
|
|
|
|
|
|
|
|
if (!engine->last_retired_context)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
engine->context_unpin(engine, engine->last_retired_context);
|
|
|
|
engine->last_retired_context = NULL;
|
2016-04-28 08:56:41 +00:00
|
|
|
}
|
|
|
|
|
2016-06-24 13:55:54 +00:00
|
|
|
/* Force the GPU state to be restored on enabling */
|
|
|
|
if (!i915.enable_execlists) {
|
2016-06-24 13:55:55 +00:00
|
|
|
struct i915_gem_context *ctx;
|
|
|
|
|
|
|
|
list_for_each_entry(ctx, &dev_priv->context_list, link) {
|
|
|
|
if (!i915_gem_context_is_default(ctx))
|
|
|
|
continue;
|
|
|
|
|
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-13 17:14:48 +00:00
|
|
|
for_each_engine(engine, dev_priv, id)
|
2016-06-24 13:55:55 +00:00
|
|
|
ctx->engine[engine->id].initialised = false;
|
|
|
|
|
|
|
|
ctx->remap_slice = ALL_L3_SLICES(dev_priv);
|
|
|
|
}
|
|
|
|
|
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-13 17:14:48 +00:00
|
|
|
for_each_engine(engine, dev_priv, id) {
|
2016-06-24 13:55:54 +00:00
|
|
|
struct intel_context *kce =
|
|
|
|
&dev_priv->kernel_context->engine[engine->id];
|
|
|
|
|
|
|
|
kce->initialised = true;
|
|
|
|
}
|
|
|
|
}
|
2016-04-28 08:56:41 +00:00
|
|
|
}
|
|
|
|
|
2016-12-01 14:16:39 +00:00
|
|
|
void i915_gem_context_fini(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-04 21:42:42 +00:00
|
|
|
{
|
2016-05-24 13:53:34 +00:00
|
|
|
struct i915_gem_context *dctx = dev_priv->kernel_context;
|
2016-04-28 08:56:41 +00:00
|
|
|
|
2016-12-01 14:16:39 +00:00
|
|
|
lockdep_assert_held(&dev_priv->drm.struct_mutex);
|
2016-05-24 13:53:35 +00:00
|
|
|
|
2017-01-06 15:20:13 +00:00
|
|
|
GEM_BUG_ON(!i915_gem_context_is_kernel(dctx));
|
|
|
|
|
2016-08-04 06:52:46 +00:00
|
|
|
context_close(dctx);
|
2016-01-19 19:02:54 +00:00
|
|
|
dev_priv->kernel_context = NULL;
|
2016-04-28 08:56:51 +00:00
|
|
|
|
|
|
|
ida_destroy(&dev_priv->context_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-04 21:42:42 +00:00
|
|
|
}
|
|
|
|
|
2012-06-04 21:42:43 +00:00
|
|
|
static int context_idr_cleanup(int id, void *p, void *data)
|
|
|
|
{
|
2016-05-24 13:53:34 +00:00
|
|
|
struct i915_gem_context *ctx = p;
|
2012-06-04 21:42:43 +00:00
|
|
|
|
2016-08-04 06:52:46 +00:00
|
|
|
context_close(ctx);
|
2012-06-04 21:42:43 +00: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-04 21:42:42 +00:00
|
|
|
}
|
|
|
|
|
2013-12-06 22:10:58 +00:00
|
|
|
int i915_gem_context_open(struct drm_device *dev, struct drm_file *file)
|
|
|
|
{
|
|
|
|
struct drm_i915_file_private *file_priv = file->driver_priv;
|
2016-05-24 13:53:34 +00:00
|
|
|
struct i915_gem_context *ctx;
|
2013-12-06 22:10:58 +00:00
|
|
|
|
|
|
|
idr_init(&file_priv->context_idr);
|
|
|
|
|
2013-12-06 22:11:19 +00:00
|
|
|
mutex_lock(&dev->struct_mutex);
|
2016-12-01 14:16:38 +00:00
|
|
|
ctx = i915_gem_create_context(to_i915(dev), file_priv);
|
2013-12-06 22:11:19 +00:00
|
|
|
mutex_unlock(&dev->struct_mutex);
|
|
|
|
|
2017-01-06 15:20:13 +00:00
|
|
|
GEM_BUG_ON(i915_gem_context_is_kernel(ctx));
|
|
|
|
|
2014-05-22 13:13:38 +00:00
|
|
|
if (IS_ERR(ctx)) {
|
2013-12-06 22:11:19 +00:00
|
|
|
idr_destroy(&file_priv->context_idr);
|
2014-05-22 13:13:38 +00:00
|
|
|
return PTR_ERR(ctx);
|
2013-12-06 22:11:19 +00:00
|
|
|
}
|
|
|
|
|
2013-12-06 22:10:58 +00: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-04 21:42:42 +00:00
|
|
|
void i915_gem_context_close(struct drm_device *dev, struct drm_file *file)
|
|
|
|
{
|
2012-06-04 21:42:43 +00: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-04 21:42:42 +00:00
|
|
|
|
2016-05-24 13:53:35 +00:00
|
|
|
lockdep_assert_held(&dev->struct_mutex);
|
|
|
|
|
2012-06-19 18:27:39 +00:00
|
|
|
idr_for_each(&file_priv->context_idr, context_idr_cleanup, NULL);
|
2012-06-04 21:42:43 +00:00
|
|
|
idr_destroy(&file_priv->context_idr);
|
|
|
|
}
|
|
|
|
|
2012-06-04 21:42:46 +00:00
|
|
|
static inline int
|
2015-05-29 16:43:52 +00:00
|
|
|
mi_set_context(struct drm_i915_gem_request *req, u32 hw_flags)
|
2012-06-04 21:42:46 +00:00
|
|
|
{
|
2016-05-06 14:40:21 +00:00
|
|
|
struct drm_i915_private *dev_priv = req->i915;
|
2016-03-16 11:00:38 +00:00
|
|
|
struct intel_engine_cs *engine = req->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-13 17:14:48 +00:00
|
|
|
enum intel_engine_id id;
|
2017-02-14 11:32:42 +00:00
|
|
|
u32 *cs, flags = hw_flags | MI_MM_SPACE_GTT;
|
drm/i915: Disable PSMI sleep messages on all rings around context switches
There exists a current workaround to prevent a hang on context switch
should the ring go to sleep in the middle of the restore,
WaProgramMiArbOnOffAroundMiSetContext (applicable to all gen7+). In
spite of disabling arbitration (which prevents the ring from powering
down during the critical section) we were still hitting hangs that had
the hallmarks of the known erratum. That is we are still seeing hangs
"on the last instruction in the context restore". By comparing -nightly
(broken) with requests (working), we were able to deduce that it was the
semaphore LRI cross-talk that reproduced the original failure. The key
was that requests implemented deferred semaphore signalling, and
disabling that, i.e. emitting the semaphore signal to every other ring
after every batch restored the frequent hang. Explicitly disabling PSMI
sleep on the RCS ring was insufficient, all the rings had to be awake to
prevent the hangs. Fortunately, we can reduce the wakelock to the
MI_SET_CONTEXT operation itself, and so should be able to limit the extra
power implications.
Since the MI_ARB_ON_OFF workaround is listed for all gen7 and above
products, we should apply this extra hammer for all of the same
platforms despite so far that we have only been able to reproduce the
hang on certain ivb and hsw models. The last question is whether we want
to always use the extra hammer or only when we know semaphores are in
operation. At the moment, we only use LRI on non-RCS rings for
semaphores, but that may change in the future with the possibility of
reintroducing this bug under subtle conditions.
v2: Make it explicit that the PSMI LRI are an extension to the original
workaround for the other rings.
v3: Bikeshedding variable names and whitespacing
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80660
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83677
Cc: Simon Farnsworth <simon@farnz.org.uk>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Peter Frühberger <fritsch@xbmc.org>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2014-12-16 10:02:27 +00:00
|
|
|
const int num_rings =
|
|
|
|
/* Use an extended w/a on ivb+ if signalling from other rings */
|
2016-07-20 12:31:57 +00:00
|
|
|
i915.semaphores ?
|
2016-08-10 15:22:10 +00:00
|
|
|
INTEL_INFO(dev_priv)->num_rings - 1 :
|
drm/i915: Disable PSMI sleep messages on all rings around context switches
There exists a current workaround to prevent a hang on context switch
should the ring go to sleep in the middle of the restore,
WaProgramMiArbOnOffAroundMiSetContext (applicable to all gen7+). In
spite of disabling arbitration (which prevents the ring from powering
down during the critical section) we were still hitting hangs that had
the hallmarks of the known erratum. That is we are still seeing hangs
"on the last instruction in the context restore". By comparing -nightly
(broken) with requests (working), we were able to deduce that it was the
semaphore LRI cross-talk that reproduced the original failure. The key
was that requests implemented deferred semaphore signalling, and
disabling that, i.e. emitting the semaphore signal to every other ring
after every batch restored the frequent hang. Explicitly disabling PSMI
sleep on the RCS ring was insufficient, all the rings had to be awake to
prevent the hangs. Fortunately, we can reduce the wakelock to the
MI_SET_CONTEXT operation itself, and so should be able to limit the extra
power implications.
Since the MI_ARB_ON_OFF workaround is listed for all gen7 and above
products, we should apply this extra hammer for all of the same
platforms despite so far that we have only been able to reproduce the
hang on certain ivb and hsw models. The last question is whether we want
to always use the extra hammer or only when we know semaphores are in
operation. At the moment, we only use LRI on non-RCS rings for
semaphores, but that may change in the future with the possibility of
reintroducing this bug under subtle conditions.
v2: Make it explicit that the PSMI LRI are an extension to the original
workaround for the other rings.
v3: Bikeshedding variable names and whitespacing
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80660
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83677
Cc: Simon Farnsworth <simon@farnz.org.uk>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Peter Frühberger <fritsch@xbmc.org>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2014-12-16 10:02:27 +00:00
|
|
|
0;
|
2017-02-14 15:29:01 +00:00
|
|
|
int len;
|
2012-06-04 21:42:46 +00:00
|
|
|
|
2014-08-18 17:35:28 +00:00
|
|
|
/* These flags are for resource streamer on HSW+ */
|
2016-05-06 14:40:21 +00:00
|
|
|
if (IS_HASWELL(dev_priv) || INTEL_GEN(dev_priv) >= 8)
|
2015-06-16 10:39:41 +00:00
|
|
|
flags |= (HSW_MI_RS_SAVE_STATE_EN | HSW_MI_RS_RESTORE_STATE_EN);
|
2016-05-06 14:40:21 +00:00
|
|
|
else if (INTEL_GEN(dev_priv) < 8)
|
2014-08-18 17:35:28 +00:00
|
|
|
flags |= (MI_SAVE_EXT_STATE_EN | MI_RESTORE_EXT_STATE_EN);
|
|
|
|
|
drm/i915: Disable PSMI sleep messages on all rings around context switches
There exists a current workaround to prevent a hang on context switch
should the ring go to sleep in the middle of the restore,
WaProgramMiArbOnOffAroundMiSetContext (applicable to all gen7+). In
spite of disabling arbitration (which prevents the ring from powering
down during the critical section) we were still hitting hangs that had
the hallmarks of the known erratum. That is we are still seeing hangs
"on the last instruction in the context restore". By comparing -nightly
(broken) with requests (working), we were able to deduce that it was the
semaphore LRI cross-talk that reproduced the original failure. The key
was that requests implemented deferred semaphore signalling, and
disabling that, i.e. emitting the semaphore signal to every other ring
after every batch restored the frequent hang. Explicitly disabling PSMI
sleep on the RCS ring was insufficient, all the rings had to be awake to
prevent the hangs. Fortunately, we can reduce the wakelock to the
MI_SET_CONTEXT operation itself, and so should be able to limit the extra
power implications.
Since the MI_ARB_ON_OFF workaround is listed for all gen7 and above
products, we should apply this extra hammer for all of the same
platforms despite so far that we have only been able to reproduce the
hang on certain ivb and hsw models. The last question is whether we want
to always use the extra hammer or only when we know semaphores are in
operation. At the moment, we only use LRI on non-RCS rings for
semaphores, but that may change in the future with the possibility of
reintroducing this bug under subtle conditions.
v2: Make it explicit that the PSMI LRI are an extension to the original
workaround for the other rings.
v3: Bikeshedding variable names and whitespacing
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80660
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83677
Cc: Simon Farnsworth <simon@farnz.org.uk>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Peter Frühberger <fritsch@xbmc.org>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2014-12-16 10:02:27 +00:00
|
|
|
|
|
|
|
len = 4;
|
2016-05-06 14:40:21 +00:00
|
|
|
if (INTEL_GEN(dev_priv) >= 7)
|
2016-04-13 16:35:10 +00:00
|
|
|
len += 2 + (num_rings ? 4*num_rings + 6 : 0);
|
drm/i915: Disable PSMI sleep messages on all rings around context switches
There exists a current workaround to prevent a hang on context switch
should the ring go to sleep in the middle of the restore,
WaProgramMiArbOnOffAroundMiSetContext (applicable to all gen7+). In
spite of disabling arbitration (which prevents the ring from powering
down during the critical section) we were still hitting hangs that had
the hallmarks of the known erratum. That is we are still seeing hangs
"on the last instruction in the context restore". By comparing -nightly
(broken) with requests (working), we were able to deduce that it was the
semaphore LRI cross-talk that reproduced the original failure. The key
was that requests implemented deferred semaphore signalling, and
disabling that, i.e. emitting the semaphore signal to every other ring
after every batch restored the frequent hang. Explicitly disabling PSMI
sleep on the RCS ring was insufficient, all the rings had to be awake to
prevent the hangs. Fortunately, we can reduce the wakelock to the
MI_SET_CONTEXT operation itself, and so should be able to limit the extra
power implications.
Since the MI_ARB_ON_OFF workaround is listed for all gen7 and above
products, we should apply this extra hammer for all of the same
platforms despite so far that we have only been able to reproduce the
hang on certain ivb and hsw models. The last question is whether we want
to always use the extra hammer or only when we know semaphores are in
operation. At the moment, we only use LRI on non-RCS rings for
semaphores, but that may change in the future with the possibility of
reintroducing this bug under subtle conditions.
v2: Make it explicit that the PSMI LRI are an extension to the original
workaround for the other rings.
v3: Bikeshedding variable names and whitespacing
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80660
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83677
Cc: Simon Farnsworth <simon@farnz.org.uk>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Peter Frühberger <fritsch@xbmc.org>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2014-12-16 10:02:27 +00:00
|
|
|
|
2017-02-14 11:32:42 +00:00
|
|
|
cs = intel_ring_begin(req, len);
|
|
|
|
if (IS_ERR(cs))
|
|
|
|
return PTR_ERR(cs);
|
2012-06-04 21:42:46 +00:00
|
|
|
|
2014-04-28 11:31:09 +00:00
|
|
|
/* WaProgramMiArbOnOffAroundMiSetContext:ivb,vlv,hsw,bdw,chv */
|
2016-05-06 14:40:21 +00:00
|
|
|
if (INTEL_GEN(dev_priv) >= 7) {
|
2017-02-14 11:32:42 +00:00
|
|
|
*cs++ = MI_ARB_ON_OFF | MI_ARB_DISABLE;
|
drm/i915: Disable PSMI sleep messages on all rings around context switches
There exists a current workaround to prevent a hang on context switch
should the ring go to sleep in the middle of the restore,
WaProgramMiArbOnOffAroundMiSetContext (applicable to all gen7+). In
spite of disabling arbitration (which prevents the ring from powering
down during the critical section) we were still hitting hangs that had
the hallmarks of the known erratum. That is we are still seeing hangs
"on the last instruction in the context restore". By comparing -nightly
(broken) with requests (working), we were able to deduce that it was the
semaphore LRI cross-talk that reproduced the original failure. The key
was that requests implemented deferred semaphore signalling, and
disabling that, i.e. emitting the semaphore signal to every other ring
after every batch restored the frequent hang. Explicitly disabling PSMI
sleep on the RCS ring was insufficient, all the rings had to be awake to
prevent the hangs. Fortunately, we can reduce the wakelock to the
MI_SET_CONTEXT operation itself, and so should be able to limit the extra
power implications.
Since the MI_ARB_ON_OFF workaround is listed for all gen7 and above
products, we should apply this extra hammer for all of the same
platforms despite so far that we have only been able to reproduce the
hang on certain ivb and hsw models. The last question is whether we want
to always use the extra hammer or only when we know semaphores are in
operation. At the moment, we only use LRI on non-RCS rings for
semaphores, but that may change in the future with the possibility of
reintroducing this bug under subtle conditions.
v2: Make it explicit that the PSMI LRI are an extension to the original
workaround for the other rings.
v3: Bikeshedding variable names and whitespacing
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80660
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83677
Cc: Simon Farnsworth <simon@farnz.org.uk>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Peter Frühberger <fritsch@xbmc.org>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2014-12-16 10:02:27 +00:00
|
|
|
if (num_rings) {
|
|
|
|
struct intel_engine_cs *signaller;
|
|
|
|
|
2017-02-14 11:32:42 +00:00
|
|
|
*cs++ = MI_LOAD_REGISTER_IMM(num_rings);
|
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-13 17:14:48 +00:00
|
|
|
for_each_engine(signaller, dev_priv, id) {
|
2016-03-16 11:00:36 +00:00
|
|
|
if (signaller == engine)
|
drm/i915: Disable PSMI sleep messages on all rings around context switches
There exists a current workaround to prevent a hang on context switch
should the ring go to sleep in the middle of the restore,
WaProgramMiArbOnOffAroundMiSetContext (applicable to all gen7+). In
spite of disabling arbitration (which prevents the ring from powering
down during the critical section) we were still hitting hangs that had
the hallmarks of the known erratum. That is we are still seeing hangs
"on the last instruction in the context restore". By comparing -nightly
(broken) with requests (working), we were able to deduce that it was the
semaphore LRI cross-talk that reproduced the original failure. The key
was that requests implemented deferred semaphore signalling, and
disabling that, i.e. emitting the semaphore signal to every other ring
after every batch restored the frequent hang. Explicitly disabling PSMI
sleep on the RCS ring was insufficient, all the rings had to be awake to
prevent the hangs. Fortunately, we can reduce the wakelock to the
MI_SET_CONTEXT operation itself, and so should be able to limit the extra
power implications.
Since the MI_ARB_ON_OFF workaround is listed for all gen7 and above
products, we should apply this extra hammer for all of the same
platforms despite so far that we have only been able to reproduce the
hang on certain ivb and hsw models. The last question is whether we want
to always use the extra hammer or only when we know semaphores are in
operation. At the moment, we only use LRI on non-RCS rings for
semaphores, but that may change in the future with the possibility of
reintroducing this bug under subtle conditions.
v2: Make it explicit that the PSMI LRI are an extension to the original
workaround for the other rings.
v3: Bikeshedding variable names and whitespacing
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80660
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83677
Cc: Simon Farnsworth <simon@farnz.org.uk>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Peter Frühberger <fritsch@xbmc.org>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2014-12-16 10:02:27 +00:00
|
|
|
continue;
|
|
|
|
|
2017-02-14 11:32:42 +00:00
|
|
|
*cs++ = i915_mmio_reg_offset(
|
|
|
|
RING_PSMI_CTL(signaller->mmio_base));
|
|
|
|
*cs++ = _MASKED_BIT_ENABLE(
|
|
|
|
GEN6_PSMI_SLEEP_MSG_DISABLE);
|
drm/i915: Disable PSMI sleep messages on all rings around context switches
There exists a current workaround to prevent a hang on context switch
should the ring go to sleep in the middle of the restore,
WaProgramMiArbOnOffAroundMiSetContext (applicable to all gen7+). In
spite of disabling arbitration (which prevents the ring from powering
down during the critical section) we were still hitting hangs that had
the hallmarks of the known erratum. That is we are still seeing hangs
"on the last instruction in the context restore". By comparing -nightly
(broken) with requests (working), we were able to deduce that it was the
semaphore LRI cross-talk that reproduced the original failure. The key
was that requests implemented deferred semaphore signalling, and
disabling that, i.e. emitting the semaphore signal to every other ring
after every batch restored the frequent hang. Explicitly disabling PSMI
sleep on the RCS ring was insufficient, all the rings had to be awake to
prevent the hangs. Fortunately, we can reduce the wakelock to the
MI_SET_CONTEXT operation itself, and so should be able to limit the extra
power implications.
Since the MI_ARB_ON_OFF workaround is listed for all gen7 and above
products, we should apply this extra hammer for all of the same
platforms despite so far that we have only been able to reproduce the
hang on certain ivb and hsw models. The last question is whether we want
to always use the extra hammer or only when we know semaphores are in
operation. At the moment, we only use LRI on non-RCS rings for
semaphores, but that may change in the future with the possibility of
reintroducing this bug under subtle conditions.
v2: Make it explicit that the PSMI LRI are an extension to the original
workaround for the other rings.
v3: Bikeshedding variable names and whitespacing
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80660
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83677
Cc: Simon Farnsworth <simon@farnz.org.uk>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Peter Frühberger <fritsch@xbmc.org>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2014-12-16 10:02:27 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2012-06-04 21:42:48 +00:00
|
|
|
|
2017-02-14 11:32:42 +00:00
|
|
|
*cs++ = MI_NOOP;
|
|
|
|
*cs++ = MI_SET_CONTEXT;
|
|
|
|
*cs++ = i915_ggtt_offset(req->ctx->engine[RCS].state) | flags;
|
2014-01-22 19:32:43 +00:00
|
|
|
/*
|
|
|
|
* w/a: MI_SET_CONTEXT must always be followed by MI_NOOP
|
|
|
|
* WaMiSetContext_Hang:snb,ivb,vlv
|
|
|
|
*/
|
2017-02-14 11:32:42 +00:00
|
|
|
*cs++ = MI_NOOP;
|
2012-06-04 21:42:46 +00:00
|
|
|
|
2016-05-06 14:40:21 +00:00
|
|
|
if (INTEL_GEN(dev_priv) >= 7) {
|
drm/i915: Disable PSMI sleep messages on all rings around context switches
There exists a current workaround to prevent a hang on context switch
should the ring go to sleep in the middle of the restore,
WaProgramMiArbOnOffAroundMiSetContext (applicable to all gen7+). In
spite of disabling arbitration (which prevents the ring from powering
down during the critical section) we were still hitting hangs that had
the hallmarks of the known erratum. That is we are still seeing hangs
"on the last instruction in the context restore". By comparing -nightly
(broken) with requests (working), we were able to deduce that it was the
semaphore LRI cross-talk that reproduced the original failure. The key
was that requests implemented deferred semaphore signalling, and
disabling that, i.e. emitting the semaphore signal to every other ring
after every batch restored the frequent hang. Explicitly disabling PSMI
sleep on the RCS ring was insufficient, all the rings had to be awake to
prevent the hangs. Fortunately, we can reduce the wakelock to the
MI_SET_CONTEXT operation itself, and so should be able to limit the extra
power implications.
Since the MI_ARB_ON_OFF workaround is listed for all gen7 and above
products, we should apply this extra hammer for all of the same
platforms despite so far that we have only been able to reproduce the
hang on certain ivb and hsw models. The last question is whether we want
to always use the extra hammer or only when we know semaphores are in
operation. At the moment, we only use LRI on non-RCS rings for
semaphores, but that may change in the future with the possibility of
reintroducing this bug under subtle conditions.
v2: Make it explicit that the PSMI LRI are an extension to the original
workaround for the other rings.
v3: Bikeshedding variable names and whitespacing
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80660
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83677
Cc: Simon Farnsworth <simon@farnz.org.uk>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Peter Frühberger <fritsch@xbmc.org>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2014-12-16 10:02:27 +00:00
|
|
|
if (num_rings) {
|
|
|
|
struct intel_engine_cs *signaller;
|
2016-04-13 16:35:10 +00:00
|
|
|
i915_reg_t last_reg = {}; /* keep gcc quiet */
|
drm/i915: Disable PSMI sleep messages on all rings around context switches
There exists a current workaround to prevent a hang on context switch
should the ring go to sleep in the middle of the restore,
WaProgramMiArbOnOffAroundMiSetContext (applicable to all gen7+). In
spite of disabling arbitration (which prevents the ring from powering
down during the critical section) we were still hitting hangs that had
the hallmarks of the known erratum. That is we are still seeing hangs
"on the last instruction in the context restore". By comparing -nightly
(broken) with requests (working), we were able to deduce that it was the
semaphore LRI cross-talk that reproduced the original failure. The key
was that requests implemented deferred semaphore signalling, and
disabling that, i.e. emitting the semaphore signal to every other ring
after every batch restored the frequent hang. Explicitly disabling PSMI
sleep on the RCS ring was insufficient, all the rings had to be awake to
prevent the hangs. Fortunately, we can reduce the wakelock to the
MI_SET_CONTEXT operation itself, and so should be able to limit the extra
power implications.
Since the MI_ARB_ON_OFF workaround is listed for all gen7 and above
products, we should apply this extra hammer for all of the same
platforms despite so far that we have only been able to reproduce the
hang on certain ivb and hsw models. The last question is whether we want
to always use the extra hammer or only when we know semaphores are in
operation. At the moment, we only use LRI on non-RCS rings for
semaphores, but that may change in the future with the possibility of
reintroducing this bug under subtle conditions.
v2: Make it explicit that the PSMI LRI are an extension to the original
workaround for the other rings.
v3: Bikeshedding variable names and whitespacing
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80660
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83677
Cc: Simon Farnsworth <simon@farnz.org.uk>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Peter Frühberger <fritsch@xbmc.org>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2014-12-16 10:02:27 +00:00
|
|
|
|
2017-02-14 11:32:42 +00:00
|
|
|
*cs++ = MI_LOAD_REGISTER_IMM(num_rings);
|
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-13 17:14:48 +00:00
|
|
|
for_each_engine(signaller, dev_priv, id) {
|
2016-03-16 11:00:36 +00:00
|
|
|
if (signaller == engine)
|
drm/i915: Disable PSMI sleep messages on all rings around context switches
There exists a current workaround to prevent a hang on context switch
should the ring go to sleep in the middle of the restore,
WaProgramMiArbOnOffAroundMiSetContext (applicable to all gen7+). In
spite of disabling arbitration (which prevents the ring from powering
down during the critical section) we were still hitting hangs that had
the hallmarks of the known erratum. That is we are still seeing hangs
"on the last instruction in the context restore". By comparing -nightly
(broken) with requests (working), we were able to deduce that it was the
semaphore LRI cross-talk that reproduced the original failure. The key
was that requests implemented deferred semaphore signalling, and
disabling that, i.e. emitting the semaphore signal to every other ring
after every batch restored the frequent hang. Explicitly disabling PSMI
sleep on the RCS ring was insufficient, all the rings had to be awake to
prevent the hangs. Fortunately, we can reduce the wakelock to the
MI_SET_CONTEXT operation itself, and so should be able to limit the extra
power implications.
Since the MI_ARB_ON_OFF workaround is listed for all gen7 and above
products, we should apply this extra hammer for all of the same
platforms despite so far that we have only been able to reproduce the
hang on certain ivb and hsw models. The last question is whether we want
to always use the extra hammer or only when we know semaphores are in
operation. At the moment, we only use LRI on non-RCS rings for
semaphores, but that may change in the future with the possibility of
reintroducing this bug under subtle conditions.
v2: Make it explicit that the PSMI LRI are an extension to the original
workaround for the other rings.
v3: Bikeshedding variable names and whitespacing
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80660
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83677
Cc: Simon Farnsworth <simon@farnz.org.uk>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Peter Frühberger <fritsch@xbmc.org>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2014-12-16 10:02:27 +00:00
|
|
|
continue;
|
|
|
|
|
2016-04-13 16:35:10 +00:00
|
|
|
last_reg = RING_PSMI_CTL(signaller->mmio_base);
|
2017-02-14 11:32:42 +00:00
|
|
|
*cs++ = i915_mmio_reg_offset(last_reg);
|
|
|
|
*cs++ = _MASKED_BIT_DISABLE(
|
|
|
|
GEN6_PSMI_SLEEP_MSG_DISABLE);
|
drm/i915: Disable PSMI sleep messages on all rings around context switches
There exists a current workaround to prevent a hang on context switch
should the ring go to sleep in the middle of the restore,
WaProgramMiArbOnOffAroundMiSetContext (applicable to all gen7+). In
spite of disabling arbitration (which prevents the ring from powering
down during the critical section) we were still hitting hangs that had
the hallmarks of the known erratum. That is we are still seeing hangs
"on the last instruction in the context restore". By comparing -nightly
(broken) with requests (working), we were able to deduce that it was the
semaphore LRI cross-talk that reproduced the original failure. The key
was that requests implemented deferred semaphore signalling, and
disabling that, i.e. emitting the semaphore signal to every other ring
after every batch restored the frequent hang. Explicitly disabling PSMI
sleep on the RCS ring was insufficient, all the rings had to be awake to
prevent the hangs. Fortunately, we can reduce the wakelock to the
MI_SET_CONTEXT operation itself, and so should be able to limit the extra
power implications.
Since the MI_ARB_ON_OFF workaround is listed for all gen7 and above
products, we should apply this extra hammer for all of the same
platforms despite so far that we have only been able to reproduce the
hang on certain ivb and hsw models. The last question is whether we want
to always use the extra hammer or only when we know semaphores are in
operation. At the moment, we only use LRI on non-RCS rings for
semaphores, but that may change in the future with the possibility of
reintroducing this bug under subtle conditions.
v2: Make it explicit that the PSMI LRI are an extension to the original
workaround for the other rings.
v3: Bikeshedding variable names and whitespacing
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80660
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83677
Cc: Simon Farnsworth <simon@farnz.org.uk>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Peter Frühberger <fritsch@xbmc.org>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2014-12-16 10:02:27 +00:00
|
|
|
}
|
2016-04-13 16:35:10 +00:00
|
|
|
|
|
|
|
/* Insert a delay before the next switch! */
|
2017-02-14 11:32:42 +00:00
|
|
|
*cs++ = MI_STORE_REGISTER_MEM | MI_SRM_LRM_GLOBAL_GTT;
|
|
|
|
*cs++ = i915_mmio_reg_offset(last_reg);
|
|
|
|
*cs++ = i915_ggtt_offset(engine->scratch);
|
|
|
|
*cs++ = MI_NOOP;
|
drm/i915: Disable PSMI sleep messages on all rings around context switches
There exists a current workaround to prevent a hang on context switch
should the ring go to sleep in the middle of the restore,
WaProgramMiArbOnOffAroundMiSetContext (applicable to all gen7+). In
spite of disabling arbitration (which prevents the ring from powering
down during the critical section) we were still hitting hangs that had
the hallmarks of the known erratum. That is we are still seeing hangs
"on the last instruction in the context restore". By comparing -nightly
(broken) with requests (working), we were able to deduce that it was the
semaphore LRI cross-talk that reproduced the original failure. The key
was that requests implemented deferred semaphore signalling, and
disabling that, i.e. emitting the semaphore signal to every other ring
after every batch restored the frequent hang. Explicitly disabling PSMI
sleep on the RCS ring was insufficient, all the rings had to be awake to
prevent the hangs. Fortunately, we can reduce the wakelock to the
MI_SET_CONTEXT operation itself, and so should be able to limit the extra
power implications.
Since the MI_ARB_ON_OFF workaround is listed for all gen7 and above
products, we should apply this extra hammer for all of the same
platforms despite so far that we have only been able to reproduce the
hang on certain ivb and hsw models. The last question is whether we want
to always use the extra hammer or only when we know semaphores are in
operation. At the moment, we only use LRI on non-RCS rings for
semaphores, but that may change in the future with the possibility of
reintroducing this bug under subtle conditions.
v2: Make it explicit that the PSMI LRI are an extension to the original
workaround for the other rings.
v3: Bikeshedding variable names and whitespacing
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80660
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83677
Cc: Simon Farnsworth <simon@farnz.org.uk>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Peter Frühberger <fritsch@xbmc.org>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2014-12-16 10:02:27 +00:00
|
|
|
}
|
2017-02-14 11:32:42 +00:00
|
|
|
*cs++ = MI_ARB_ON_OFF | MI_ARB_ENABLE;
|
drm/i915: Disable PSMI sleep messages on all rings around context switches
There exists a current workaround to prevent a hang on context switch
should the ring go to sleep in the middle of the restore,
WaProgramMiArbOnOffAroundMiSetContext (applicable to all gen7+). In
spite of disabling arbitration (which prevents the ring from powering
down during the critical section) we were still hitting hangs that had
the hallmarks of the known erratum. That is we are still seeing hangs
"on the last instruction in the context restore". By comparing -nightly
(broken) with requests (working), we were able to deduce that it was the
semaphore LRI cross-talk that reproduced the original failure. The key
was that requests implemented deferred semaphore signalling, and
disabling that, i.e. emitting the semaphore signal to every other ring
after every batch restored the frequent hang. Explicitly disabling PSMI
sleep on the RCS ring was insufficient, all the rings had to be awake to
prevent the hangs. Fortunately, we can reduce the wakelock to the
MI_SET_CONTEXT operation itself, and so should be able to limit the extra
power implications.
Since the MI_ARB_ON_OFF workaround is listed for all gen7 and above
products, we should apply this extra hammer for all of the same
platforms despite so far that we have only been able to reproduce the
hang on certain ivb and hsw models. The last question is whether we want
to always use the extra hammer or only when we know semaphores are in
operation. At the moment, we only use LRI on non-RCS rings for
semaphores, but that may change in the future with the possibility of
reintroducing this bug under subtle conditions.
v2: Make it explicit that the PSMI LRI are an extension to the original
workaround for the other rings.
v3: Bikeshedding variable names and whitespacing
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=80660
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83677
Cc: Simon Farnsworth <simon@farnz.org.uk>
Cc: Daniel Vetter <daniel@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Tested-by: Peter Frühberger <fritsch@xbmc.org>
Reviewed-by: Daniel Vetter <daniel@ffwll.ch>
Cc: stable@vger.kernel.org
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2014-12-16 10:02:27 +00:00
|
|
|
}
|
2012-06-04 21:42:48 +00:00
|
|
|
|
2017-02-14 11:32:42 +00:00
|
|
|
intel_ring_advance(req, cs);
|
2012-06-04 21:42:46 +00:00
|
|
|
|
2017-02-14 15:29:01 +00:00
|
|
|
return 0;
|
2012-06-04 21:42:46 +00:00
|
|
|
}
|
|
|
|
|
2016-04-28 08:56:44 +00:00
|
|
|
static int remap_l3(struct drm_i915_gem_request *req, int slice)
|
2016-04-28 08:56:42 +00:00
|
|
|
{
|
2017-02-14 11:32:42 +00:00
|
|
|
u32 *cs, *remap_info = req->i915->l3_parity.remap_info[slice];
|
|
|
|
int i;
|
2016-04-28 08:56:42 +00:00
|
|
|
|
2016-04-28 08:56:43 +00:00
|
|
|
if (!remap_info)
|
2016-04-28 08:56:42 +00:00
|
|
|
return 0;
|
|
|
|
|
2017-02-14 11:32:42 +00:00
|
|
|
cs = intel_ring_begin(req, GEN7_L3LOG_SIZE/4 * 2 + 2);
|
|
|
|
if (IS_ERR(cs))
|
|
|
|
return PTR_ERR(cs);
|
2016-04-28 08:56:42 +00:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Note: We do not worry about the concurrent register cacheline hang
|
|
|
|
* here because no other code should access these registers other than
|
|
|
|
* at initialization time.
|
|
|
|
*/
|
2017-02-14 11:32:42 +00:00
|
|
|
*cs++ = MI_LOAD_REGISTER_IMM(GEN7_L3LOG_SIZE/4);
|
2016-04-28 08:56:43 +00:00
|
|
|
for (i = 0; i < GEN7_L3LOG_SIZE/4; i++) {
|
2017-02-14 11:32:42 +00:00
|
|
|
*cs++ = i915_mmio_reg_offset(GEN7_L3LOG(slice, i));
|
|
|
|
*cs++ = remap_info[i];
|
2016-04-28 08:56:42 +00:00
|
|
|
}
|
2017-02-14 11:32:42 +00:00
|
|
|
*cs++ = MI_NOOP;
|
|
|
|
intel_ring_advance(req, cs);
|
2016-04-28 08:56:42 +00:00
|
|
|
|
2016-04-28 08:56:43 +00:00
|
|
|
return 0;
|
2016-04-28 08:56:42 +00:00
|
|
|
}
|
|
|
|
|
2016-04-28 08:56:45 +00:00
|
|
|
static inline bool skip_rcs_switch(struct i915_hw_ppgtt *ppgtt,
|
|
|
|
struct intel_engine_cs *engine,
|
2016-05-24 13:53:34 +00:00
|
|
|
struct i915_gem_context *to)
|
2015-03-16 16:00:55 +00:00
|
|
|
{
|
drm/i915: Track page table reload need
This patch was formerly known as, "Force pd restore when PDEs change,
gen6-7." I had to change the name because it is needed for GEN8 too.
The real issue this is trying to solve is when a new object is mapped
into the current address space. The GPU does not snoop the new mapping
so we must do the gen specific action to reload the page tables.
GEN8 and GEN7 do differ in the way they load page tables for the RCS.
GEN8 does so with the context restore, while GEN7 requires the proper
load commands in the command streamer. Non-render is similar for both.
Caveat for GEN7
The docs say you cannot change the PDEs of a currently running context.
We never map new PDEs of a running context, and expect them to be
present - so I think this is okay. (We can unmap, but this should also
be okay since we only unmap unreferenced objects that the GPU shouldn't
be tryingto va->pa xlate.) The MI_SET_CONTEXT command does have a flag
to signal that even if the context is the same, force a reload. It's
unclear exactly what this does, but I have a hunch it's the right thing
to do.
The logic assumes that we always emit a context switch after mapping new
PDEs, and before we submit a batch. This is the case today, and has been
the case since the inception of hardware contexts. A note in the comment
let's the user know.
It's not just for gen8. If the current context has mappings change, we
need a context reload to switch
v2: Rebased after ppgtt clean up patches. Split the warning for aliasing
and true ppgtt options. And do not break aliasing ppgtt, where to->ppgtt
is always null.
v3: Invalidate PPGTT TLBs inside alloc_va_range.
v4: Rename ppgtt_invalidate_tlbs to mark_tlbs_dirty and move
pd_dirty_rings from i915_address_space to i915_hw_ppgtt. Fixes when
neither ctx->ppgtt and aliasing_ppgtt exist.
v5: Removed references to teardown_va_range.
v6: Updated needs_pd_load_pre/post.
v7: Fix pd_dirty_rings check in needs_pd_load_post, and update/move
comment about updated PDEs to object_pin/bind (Mika).
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Michel Thierry <michel.thierry@intel.com> (v2+)
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-19 12:53:28 +00:00
|
|
|
if (to->remap_slice)
|
|
|
|
return false;
|
|
|
|
|
2016-05-24 13:53:41 +00:00
|
|
|
if (!to->engine[RCS].initialised)
|
2016-04-13 16:35:14 +00:00
|
|
|
return false;
|
|
|
|
|
2016-04-28 08:56:45 +00:00
|
|
|
if (ppgtt && (intel_engine_flag(engine) & ppgtt->pd_dirty_rings))
|
2016-04-13 16:35:14 +00:00
|
|
|
return false;
|
2015-03-16 16:00:55 +00:00
|
|
|
|
drm/i915: Unify active context tracking between legacy/execlists/guc
The requests conversion introduced a nasty bug where we could generate a
new request in the middle of constructing a request if we needed to idle
the system in order to evict space for a context. The request to idle
would be executed (and waited upon) before the current one, creating a
minor havoc in the seqno accounting, as we will consider the current
request to already be completed (prior to deferred seqno assignment) but
ring->last_retired_head would have been updated and still could allow
us to overwrite the current request before execution.
We also employed two different mechanisms to track the active context
until it was switched out. The legacy method allowed for waiting upon an
active context (it could forcibly evict any vma, including context's),
but the execlists method took a step backwards by pinning the vma for
the entire active lifespan of the context (the only way to evict was to
idle the entire GPU, not individual contexts). However, to circumvent
the tricky issue of locking (i.e. we cannot take struct_mutex at the
time of i915_gem_request_submit(), where we would want to move the
previous context onto the active tracker and unpin it), we take the
execlists approach and keep the contexts pinned until retirement.
The benefit of the execlists approach, more important for execlists than
legacy, was the reduction in work in pinning the context for each
request - as the context was kept pinned until idle, it could short
circuit the pinning for all active contexts.
We introduce new engine vfuncs to pin and unpin the context
respectively. The context is pinned at the start of the request, and
only unpinned when the following request is retired (this ensures that
the context is idle and coherent in main memory before we unpin it). We
move the engine->last_context tracking into the retirement itself
(rather than during request submission) in order to allow the submission
to be reordered or unwound without undue difficultly.
And finally an ulterior motive for unifying context handling was to
prepare for mock requests.
v2: Rename to last_retired_context, split out legacy_context tracking
for MI_SET_CONTEXT.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161218153724.8439-3-chris@chris-wilson.co.uk
2016-12-18 15:37:20 +00:00
|
|
|
return to == engine->legacy_active_context;
|
2015-03-16 16:00:55 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
static bool
|
2016-04-28 08:56:45 +00:00
|
|
|
needs_pd_load_pre(struct i915_hw_ppgtt *ppgtt,
|
|
|
|
struct intel_engine_cs *engine,
|
2016-05-24 13:53:34 +00:00
|
|
|
struct i915_gem_context *to)
|
2015-03-16 16:00:55 +00:00
|
|
|
{
|
2016-04-28 08:56:45 +00:00
|
|
|
if (!ppgtt)
|
2015-03-16 16:00:55 +00:00
|
|
|
return false;
|
|
|
|
|
2016-04-28 08:56:45 +00:00
|
|
|
/* Always load the ppgtt on first use */
|
drm/i915: Unify active context tracking between legacy/execlists/guc
The requests conversion introduced a nasty bug where we could generate a
new request in the middle of constructing a request if we needed to idle
the system in order to evict space for a context. The request to idle
would be executed (and waited upon) before the current one, creating a
minor havoc in the seqno accounting, as we will consider the current
request to already be completed (prior to deferred seqno assignment) but
ring->last_retired_head would have been updated and still could allow
us to overwrite the current request before execution.
We also employed two different mechanisms to track the active context
until it was switched out. The legacy method allowed for waiting upon an
active context (it could forcibly evict any vma, including context's),
but the execlists method took a step backwards by pinning the vma for
the entire active lifespan of the context (the only way to evict was to
idle the entire GPU, not individual contexts). However, to circumvent
the tricky issue of locking (i.e. we cannot take struct_mutex at the
time of i915_gem_request_submit(), where we would want to move the
previous context onto the active tracker and unpin it), we take the
execlists approach and keep the contexts pinned until retirement.
The benefit of the execlists approach, more important for execlists than
legacy, was the reduction in work in pinning the context for each
request - as the context was kept pinned until idle, it could short
circuit the pinning for all active contexts.
We introduce new engine vfuncs to pin and unpin the context
respectively. The context is pinned at the start of the request, and
only unpinned when the following request is retired (this ensures that
the context is idle and coherent in main memory before we unpin it). We
move the engine->last_context tracking into the retirement itself
(rather than during request submission) in order to allow the submission
to be reordered or unwound without undue difficultly.
And finally an ulterior motive for unifying context handling was to
prepare for mock requests.
v2: Rename to last_retired_context, split out legacy_context tracking
for MI_SET_CONTEXT.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161218153724.8439-3-chris@chris-wilson.co.uk
2016-12-18 15:37:20 +00:00
|
|
|
if (!engine->legacy_active_context)
|
2016-04-28 08:56:45 +00:00
|
|
|
return true;
|
|
|
|
|
|
|
|
/* Same context without new entries, skip */
|
drm/i915: Unify active context tracking between legacy/execlists/guc
The requests conversion introduced a nasty bug where we could generate a
new request in the middle of constructing a request if we needed to idle
the system in order to evict space for a context. The request to idle
would be executed (and waited upon) before the current one, creating a
minor havoc in the seqno accounting, as we will consider the current
request to already be completed (prior to deferred seqno assignment) but
ring->last_retired_head would have been updated and still could allow
us to overwrite the current request before execution.
We also employed two different mechanisms to track the active context
until it was switched out. The legacy method allowed for waiting upon an
active context (it could forcibly evict any vma, including context's),
but the execlists method took a step backwards by pinning the vma for
the entire active lifespan of the context (the only way to evict was to
idle the entire GPU, not individual contexts). However, to circumvent
the tricky issue of locking (i.e. we cannot take struct_mutex at the
time of i915_gem_request_submit(), where we would want to move the
previous context onto the active tracker and unpin it), we take the
execlists approach and keep the contexts pinned until retirement.
The benefit of the execlists approach, more important for execlists than
legacy, was the reduction in work in pinning the context for each
request - as the context was kept pinned until idle, it could short
circuit the pinning for all active contexts.
We introduce new engine vfuncs to pin and unpin the context
respectively. The context is pinned at the start of the request, and
only unpinned when the following request is retired (this ensures that
the context is idle and coherent in main memory before we unpin it). We
move the engine->last_context tracking into the retirement itself
(rather than during request submission) in order to allow the submission
to be reordered or unwound without undue difficultly.
And finally an ulterior motive for unifying context handling was to
prepare for mock requests.
v2: Rename to last_retired_context, split out legacy_context tracking
for MI_SET_CONTEXT.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161218153724.8439-3-chris@chris-wilson.co.uk
2016-12-18 15:37:20 +00:00
|
|
|
if (engine->legacy_active_context == to &&
|
2016-04-28 08:56:45 +00:00
|
|
|
!(intel_engine_flag(engine) & ppgtt->pd_dirty_rings))
|
2016-04-13 16:35:13 +00:00
|
|
|
return false;
|
|
|
|
|
|
|
|
if (engine->id != RCS)
|
2015-03-16 16:00:55 +00:00
|
|
|
return true;
|
|
|
|
|
2016-05-06 14:40:21 +00:00
|
|
|
if (INTEL_GEN(engine->i915) < 8)
|
2015-03-16 16:00:55 +00:00
|
|
|
return true;
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
static bool
|
2016-04-28 08:56:45 +00:00
|
|
|
needs_pd_load_post(struct i915_hw_ppgtt *ppgtt,
|
2016-05-24 13:53:34 +00:00
|
|
|
struct i915_gem_context *to,
|
2016-04-28 08:56:45 +00:00
|
|
|
u32 hw_flags)
|
2015-03-16 16:00:55 +00:00
|
|
|
{
|
2016-04-28 08:56:45 +00:00
|
|
|
if (!ppgtt)
|
2015-03-16 16:00:55 +00:00
|
|
|
return false;
|
|
|
|
|
2016-04-13 16:35:14 +00:00
|
|
|
if (!IS_GEN8(to->i915))
|
2015-03-16 16:00:55 +00:00
|
|
|
return false;
|
|
|
|
|
drm/i915: Initialize all contexts
The problem is we're going to switch to a new context, which could be
the default context. The plan was to use restore inhibit, which would be
fine, except if we are using dynamic page tables (which we will). If we
use dynamic page tables and we don't load new page tables, the previous
page tables might go away, and future operations will fault.
CTXA runs.
switch to default, restore inhibit
CTXA dies and has its address space taken away.
Run CTXB, tries to save using the context A's address space - this
fails.
The general solution is to make sure every context has it's own state,
and its own address space. For cases when we must restore inhibit, first
thing we do is load a valid address space. I thought this would be
enough, but apparently there are references within the context itself
which will refer to the old address space - therefore, we also must
reinitialize.
v2: to->ppgtt is only valid in full ppgtt.
v3: Rebased.
v4: Make post PDP update clearer.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Michel Thierry <michel.thierry@intel.com> (v2+)
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-16 16:00:58 +00:00
|
|
|
if (hw_flags & MI_RESTORE_INHIBIT)
|
2015-03-16 16:00:55 +00:00
|
|
|
return true;
|
|
|
|
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
2016-04-13 16:35:13 +00:00
|
|
|
static int do_rcs_switch(struct drm_i915_gem_request *req)
|
2012-06-04 21:42:46 +00:00
|
|
|
{
|
2016-05-24 13:53:34 +00:00
|
|
|
struct i915_gem_context *to = req->ctx;
|
2016-03-16 11:00:38 +00:00
|
|
|
struct intel_engine_cs *engine = req->engine;
|
2016-04-28 08:56:45 +00:00
|
|
|
struct i915_hw_ppgtt *ppgtt = to->ppgtt ?: req->i915->mm.aliasing_ppgtt;
|
drm/i915: Unify active context tracking between legacy/execlists/guc
The requests conversion introduced a nasty bug where we could generate a
new request in the middle of constructing a request if we needed to idle
the system in order to evict space for a context. The request to idle
would be executed (and waited upon) before the current one, creating a
minor havoc in the seqno accounting, as we will consider the current
request to already be completed (prior to deferred seqno assignment) but
ring->last_retired_head would have been updated and still could allow
us to overwrite the current request before execution.
We also employed two different mechanisms to track the active context
until it was switched out. The legacy method allowed for waiting upon an
active context (it could forcibly evict any vma, including context's),
but the execlists method took a step backwards by pinning the vma for
the entire active lifespan of the context (the only way to evict was to
idle the entire GPU, not individual contexts). However, to circumvent
the tricky issue of locking (i.e. we cannot take struct_mutex at the
time of i915_gem_request_submit(), where we would want to move the
previous context onto the active tracker and unpin it), we take the
execlists approach and keep the contexts pinned until retirement.
The benefit of the execlists approach, more important for execlists than
legacy, was the reduction in work in pinning the context for each
request - as the context was kept pinned until idle, it could short
circuit the pinning for all active contexts.
We introduce new engine vfuncs to pin and unpin the context
respectively. The context is pinned at the start of the request, and
only unpinned when the following request is retired (this ensures that
the context is idle and coherent in main memory before we unpin it). We
move the engine->last_context tracking into the retirement itself
(rather than during request submission) in order to allow the submission
to be reordered or unwound without undue difficultly.
And finally an ulterior motive for unifying context handling was to
prepare for mock requests.
v2: Rename to last_retired_context, split out legacy_context tracking
for MI_SET_CONTEXT.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161218153724.8439-3-chris@chris-wilson.co.uk
2016-12-18 15:37:20 +00:00
|
|
|
struct i915_gem_context *from = engine->legacy_active_context;
|
2016-04-13 16:35:14 +00:00
|
|
|
u32 hw_flags;
|
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 02:03:18 +00:00
|
|
|
int ret, i;
|
2012-06-04 21:42:46 +00:00
|
|
|
|
drm/i915: Unify active context tracking between legacy/execlists/guc
The requests conversion introduced a nasty bug where we could generate a
new request in the middle of constructing a request if we needed to idle
the system in order to evict space for a context. The request to idle
would be executed (and waited upon) before the current one, creating a
minor havoc in the seqno accounting, as we will consider the current
request to already be completed (prior to deferred seqno assignment) but
ring->last_retired_head would have been updated and still could allow
us to overwrite the current request before execution.
We also employed two different mechanisms to track the active context
until it was switched out. The legacy method allowed for waiting upon an
active context (it could forcibly evict any vma, including context's),
but the execlists method took a step backwards by pinning the vma for
the entire active lifespan of the context (the only way to evict was to
idle the entire GPU, not individual contexts). However, to circumvent
the tricky issue of locking (i.e. we cannot take struct_mutex at the
time of i915_gem_request_submit(), where we would want to move the
previous context onto the active tracker and unpin it), we take the
execlists approach and keep the contexts pinned until retirement.
The benefit of the execlists approach, more important for execlists than
legacy, was the reduction in work in pinning the context for each
request - as the context was kept pinned until idle, it could short
circuit the pinning for all active contexts.
We introduce new engine vfuncs to pin and unpin the context
respectively. The context is pinned at the start of the request, and
only unpinned when the following request is retired (this ensures that
the context is idle and coherent in main memory before we unpin it). We
move the engine->last_context tracking into the retirement itself
(rather than during request submission) in order to allow the submission
to be reordered or unwound without undue difficultly.
And finally an ulterior motive for unifying context handling was to
prepare for mock requests.
v2: Rename to last_retired_context, split out legacy_context tracking
for MI_SET_CONTEXT.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161218153724.8439-3-chris@chris-wilson.co.uk
2016-12-18 15:37:20 +00:00
|
|
|
GEM_BUG_ON(engine->id != RCS);
|
|
|
|
|
2016-04-28 08:56:45 +00:00
|
|
|
if (skip_rcs_switch(ppgtt, engine, to))
|
2012-07-15 11:34:24 +00:00
|
|
|
return 0;
|
|
|
|
|
2016-04-28 08:56:45 +00:00
|
|
|
if (needs_pd_load_pre(ppgtt, engine, to)) {
|
2016-04-13 16:35:14 +00:00
|
|
|
/* Older GENs and non render rings still want the load first,
|
|
|
|
* "PP_DCLV followed by PP_DIR_BASE register through Load
|
|
|
|
* Register Immediate commands in Ring Buffer before submitting
|
|
|
|
* a context."*/
|
|
|
|
trace_switch_mm(engine, to);
|
2016-04-28 08:56:45 +00:00
|
|
|
ret = ppgtt->switch_mm(ppgtt, req);
|
2016-04-13 16:35:14 +00:00
|
|
|
if (ret)
|
drm/i915: Unify active context tracking between legacy/execlists/guc
The requests conversion introduced a nasty bug where we could generate a
new request in the middle of constructing a request if we needed to idle
the system in order to evict space for a context. The request to idle
would be executed (and waited upon) before the current one, creating a
minor havoc in the seqno accounting, as we will consider the current
request to already be completed (prior to deferred seqno assignment) but
ring->last_retired_head would have been updated and still could allow
us to overwrite the current request before execution.
We also employed two different mechanisms to track the active context
until it was switched out. The legacy method allowed for waiting upon an
active context (it could forcibly evict any vma, including context's),
but the execlists method took a step backwards by pinning the vma for
the entire active lifespan of the context (the only way to evict was to
idle the entire GPU, not individual contexts). However, to circumvent
the tricky issue of locking (i.e. we cannot take struct_mutex at the
time of i915_gem_request_submit(), where we would want to move the
previous context onto the active tracker and unpin it), we take the
execlists approach and keep the contexts pinned until retirement.
The benefit of the execlists approach, more important for execlists than
legacy, was the reduction in work in pinning the context for each
request - as the context was kept pinned until idle, it could short
circuit the pinning for all active contexts.
We introduce new engine vfuncs to pin and unpin the context
respectively. The context is pinned at the start of the request, and
only unpinned when the following request is retired (this ensures that
the context is idle and coherent in main memory before we unpin it). We
move the engine->last_context tracking into the retirement itself
(rather than during request submission) in order to allow the submission
to be reordered or unwound without undue difficultly.
And finally an ulterior motive for unifying context handling was to
prepare for mock requests.
v2: Rename to last_retired_context, split out legacy_context tracking
for MI_SET_CONTEXT.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161218153724.8439-3-chris@chris-wilson.co.uk
2016-12-18 15:37:20 +00:00
|
|
|
return ret;
|
2016-04-13 16:35:14 +00:00
|
|
|
}
|
|
|
|
|
2016-05-24 13:53:41 +00:00
|
|
|
if (!to->engine[RCS].initialised || i915_gem_context_is_default(to))
|
drm/i915: Initialize all contexts
The problem is we're going to switch to a new context, which could be
the default context. The plan was to use restore inhibit, which would be
fine, except if we are using dynamic page tables (which we will). If we
use dynamic page tables and we don't load new page tables, the previous
page tables might go away, and future operations will fault.
CTXA runs.
switch to default, restore inhibit
CTXA dies and has its address space taken away.
Run CTXB, tries to save using the context A's address space - this
fails.
The general solution is to make sure every context has it's own state,
and its own address space. For cases when we must restore inhibit, first
thing we do is load a valid address space. I thought this would be
enough, but apparently there are references within the context itself
which will refer to the old address space - therefore, we also must
reinitialize.
v2: to->ppgtt is only valid in full ppgtt.
v3: Rebased.
v4: Make post PDP update clearer.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Michel Thierry <michel.thierry@intel.com> (v2+)
Reviewed-by: Mika Kuoppala <mika.kuoppala@intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-03-16 16:00:58 +00:00
|
|
|
/* NB: If we inhibit the restore, the context is not allowed to
|
|
|
|
* die because future work may end up depending on valid address
|
|
|
|
* space. This means we must enforce that a page table load
|
|
|
|
* occur when this occurs. */
|
2016-04-13 16:35:14 +00:00
|
|
|
hw_flags = MI_RESTORE_INHIBIT;
|
2016-04-28 08:56:45 +00:00
|
|
|
else if (ppgtt && intel_engine_flag(engine) & ppgtt->pd_dirty_rings)
|
2016-04-13 16:35:14 +00:00
|
|
|
hw_flags = MI_FORCE_RESTORE;
|
|
|
|
else
|
|
|
|
hw_flags = 0;
|
2012-06-04 21:42:46 +00:00
|
|
|
|
2016-04-13 16:35:14 +00:00
|
|
|
if (to != from || (hw_flags & MI_FORCE_RESTORE)) {
|
|
|
|
ret = mi_set_context(req, hw_flags);
|
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 02:03:18 +00:00
|
|
|
if (ret)
|
drm/i915: Unify active context tracking between legacy/execlists/guc
The requests conversion introduced a nasty bug where we could generate a
new request in the middle of constructing a request if we needed to idle
the system in order to evict space for a context. The request to idle
would be executed (and waited upon) before the current one, creating a
minor havoc in the seqno accounting, as we will consider the current
request to already be completed (prior to deferred seqno assignment) but
ring->last_retired_head would have been updated and still could allow
us to overwrite the current request before execution.
We also employed two different mechanisms to track the active context
until it was switched out. The legacy method allowed for waiting upon an
active context (it could forcibly evict any vma, including context's),
but the execlists method took a step backwards by pinning the vma for
the entire active lifespan of the context (the only way to evict was to
idle the entire GPU, not individual contexts). However, to circumvent
the tricky issue of locking (i.e. we cannot take struct_mutex at the
time of i915_gem_request_submit(), where we would want to move the
previous context onto the active tracker and unpin it), we take the
execlists approach and keep the contexts pinned until retirement.
The benefit of the execlists approach, more important for execlists than
legacy, was the reduction in work in pinning the context for each
request - as the context was kept pinned until idle, it could short
circuit the pinning for all active contexts.
We introduce new engine vfuncs to pin and unpin the context
respectively. The context is pinned at the start of the request, and
only unpinned when the following request is retired (this ensures that
the context is idle and coherent in main memory before we unpin it). We
move the engine->last_context tracking into the retirement itself
(rather than during request submission) in order to allow the submission
to be reordered or unwound without undue difficultly.
And finally an ulterior motive for unifying context handling was to
prepare for mock requests.
v2: Rename to last_retired_context, split out legacy_context tracking
for MI_SET_CONTEXT.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161218153724.8439-3-chris@chris-wilson.co.uk
2016-12-18 15:37:20 +00:00
|
|
|
return ret;
|
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 02:03:18 +00:00
|
|
|
|
drm/i915: Unify active context tracking between legacy/execlists/guc
The requests conversion introduced a nasty bug where we could generate a
new request in the middle of constructing a request if we needed to idle
the system in order to evict space for a context. The request to idle
would be executed (and waited upon) before the current one, creating a
minor havoc in the seqno accounting, as we will consider the current
request to already be completed (prior to deferred seqno assignment) but
ring->last_retired_head would have been updated and still could allow
us to overwrite the current request before execution.
We also employed two different mechanisms to track the active context
until it was switched out. The legacy method allowed for waiting upon an
active context (it could forcibly evict any vma, including context's),
but the execlists method took a step backwards by pinning the vma for
the entire active lifespan of the context (the only way to evict was to
idle the entire GPU, not individual contexts). However, to circumvent
the tricky issue of locking (i.e. we cannot take struct_mutex at the
time of i915_gem_request_submit(), where we would want to move the
previous context onto the active tracker and unpin it), we take the
execlists approach and keep the contexts pinned until retirement.
The benefit of the execlists approach, more important for execlists than
legacy, was the reduction in work in pinning the context for each
request - as the context was kept pinned until idle, it could short
circuit the pinning for all active contexts.
We introduce new engine vfuncs to pin and unpin the context
respectively. The context is pinned at the start of the request, and
only unpinned when the following request is retired (this ensures that
the context is idle and coherent in main memory before we unpin it). We
move the engine->last_context tracking into the retirement itself
(rather than during request submission) in order to allow the submission
to be reordered or unwound without undue difficultly.
And finally an ulterior motive for unifying context handling was to
prepare for mock requests.
v2: Rename to last_retired_context, split out legacy_context tracking
for MI_SET_CONTEXT.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161218153724.8439-3-chris@chris-wilson.co.uk
2016-12-18 15:37:20 +00:00
|
|
|
engine->legacy_active_context = to;
|
2012-06-04 21:42:46 +00:00
|
|
|
}
|
|
|
|
|
2016-04-13 16:35:14 +00:00
|
|
|
/* GEN8 does *not* require an explicit reload if the PDPs have been
|
|
|
|
* setup, and we do not wish to move them.
|
|
|
|
*/
|
2016-04-28 08:56:45 +00:00
|
|
|
if (needs_pd_load_post(ppgtt, to, hw_flags)) {
|
2016-04-13 16:35:14 +00:00
|
|
|
trace_switch_mm(engine, to);
|
2016-04-28 08:56:45 +00:00
|
|
|
ret = ppgtt->switch_mm(ppgtt, req);
|
2016-04-13 16:35:14 +00:00
|
|
|
/* The hardware context switch is emitted, but we haven't
|
|
|
|
* actually changed the state - so it's probably safe to bail
|
|
|
|
* here. Still, let the user know something dangerous has
|
|
|
|
* happened.
|
|
|
|
*/
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2016-04-28 08:56:45 +00:00
|
|
|
if (ppgtt)
|
|
|
|
ppgtt->pd_dirty_rings &= ~intel_engine_flag(engine);
|
2016-04-13 16:35:14 +00:00
|
|
|
|
|
|
|
for (i = 0; i < MAX_L3_SLICES; i++) {
|
|
|
|
if (!(to->remap_slice & (1<<i)))
|
|
|
|
continue;
|
|
|
|
|
2016-04-28 08:56:44 +00:00
|
|
|
ret = remap_l3(req, i);
|
2016-04-13 16:35:14 +00:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
to->remap_slice &= ~(1<<i);
|
|
|
|
}
|
|
|
|
|
2016-05-24 13:53:41 +00:00
|
|
|
if (!to->engine[RCS].initialised) {
|
2016-03-16 11:00:36 +00:00
|
|
|
if (engine->init_context) {
|
|
|
|
ret = engine->init_context(req);
|
2014-08-26 13:44:50 +00:00
|
|
|
if (ret)
|
2016-04-13 16:35:14 +00:00
|
|
|
return ret;
|
2014-08-26 13:44:50 +00:00
|
|
|
}
|
2016-05-24 13:53:41 +00:00
|
|
|
to->engine[RCS].initialised = true;
|
2014-05-21 16:01:06 +00:00
|
|
|
}
|
|
|
|
|
2012-06-04 21:42:46 +00:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* i915_switch_context() - perform a GPU context switch.
|
2015-05-29 16:43:41 +00:00
|
|
|
* @req: request for which we'll execute the context switch
|
2012-06-04 21:42:46 +00:00
|
|
|
*
|
|
|
|
* The context life cycle is simple. The context refcount is incremented and
|
|
|
|
* decremented by 1 and create and destroy. If the context is in use by the GPU,
|
2014-08-20 15:29:24 +00:00
|
|
|
* it will have a refcount > 1. This allows us to destroy the context abstract
|
2012-06-04 21:42:46 +00:00
|
|
|
* object while letting the normal object tracking destroy the backing BO.
|
2014-08-20 15:29:24 +00:00
|
|
|
*
|
|
|
|
* This function should not be used in execlists mode. Instead the context is
|
|
|
|
* switched by writing to the ELSP and requests keep a reference to their
|
|
|
|
* context.
|
2012-06-04 21:42:46 +00:00
|
|
|
*/
|
2015-05-29 16:43:41 +00:00
|
|
|
int i915_switch_context(struct drm_i915_gem_request *req)
|
2012-06-04 21:42:46 +00:00
|
|
|
{
|
2016-03-16 11:00:38 +00:00
|
|
|
struct intel_engine_cs *engine = req->engine;
|
2012-06-04 21:42:46 +00:00
|
|
|
|
2016-07-05 09:40:23 +00:00
|
|
|
lockdep_assert_held(&req->i915->drm.struct_mutex);
|
2016-08-02 21:50:38 +00:00
|
|
|
if (i915.enable_execlists)
|
|
|
|
return 0;
|
2013-12-06 22:11:19 +00:00
|
|
|
|
2016-05-24 13:53:41 +00:00
|
|
|
if (!req->ctx->engine[engine->id].state) {
|
2016-05-24 13:53:34 +00:00
|
|
|
struct i915_gem_context *to = req->ctx;
|
2016-04-28 08:56:45 +00:00
|
|
|
struct i915_hw_ppgtt *ppgtt =
|
|
|
|
to->ppgtt ?: req->i915->mm.aliasing_ppgtt;
|
2016-04-13 16:35:13 +00:00
|
|
|
|
2016-04-28 08:56:45 +00:00
|
|
|
if (needs_pd_load_pre(ppgtt, engine, to)) {
|
2016-04-13 16:35:13 +00:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
trace_switch_mm(engine, to);
|
2016-04-28 08:56:45 +00:00
|
|
|
ret = ppgtt->switch_mm(ppgtt, req);
|
2016-04-13 16:35:13 +00:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2016-04-28 08:56:45 +00:00
|
|
|
ppgtt->pd_dirty_rings &= ~intel_engine_flag(engine);
|
2016-04-13 16:35:13 +00:00
|
|
|
}
|
|
|
|
|
2013-12-06 22:11:20 +00:00
|
|
|
return 0;
|
2014-03-14 14:22:10 +00:00
|
|
|
}
|
2013-12-06 22:11:20 +00:00
|
|
|
|
2016-04-13 16:35:13 +00:00
|
|
|
return do_rcs_switch(req);
|
2012-06-04 21:42:46 +00:00
|
|
|
}
|
2012-06-04 21:42:54 +00:00
|
|
|
|
2016-12-29 14:40:37 +00:00
|
|
|
static bool engine_has_kernel_context(struct intel_engine_cs *engine)
|
|
|
|
{
|
|
|
|
struct i915_gem_timeline *timeline;
|
|
|
|
|
|
|
|
list_for_each_entry(timeline, &engine->i915->gt.timelines, link) {
|
|
|
|
struct intel_timeline *tl;
|
|
|
|
|
|
|
|
if (timeline == &engine->i915->gt.global_timeline)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
tl = &timeline->engine[engine->id];
|
|
|
|
if (i915_gem_active_peek(&tl->last_request,
|
|
|
|
&engine->i915->drm.struct_mutex))
|
|
|
|
return false;
|
|
|
|
}
|
|
|
|
|
|
|
|
return (!engine->last_retired_context ||
|
|
|
|
i915_gem_context_is_kernel(engine->last_retired_context));
|
|
|
|
}
|
|
|
|
|
2016-07-15 13:56:19 +00:00
|
|
|
int i915_gem_switch_to_kernel_context(struct drm_i915_private *dev_priv)
|
|
|
|
{
|
|
|
|
struct intel_engine_cs *engine;
|
2016-10-28 12:58:47 +00:00
|
|
|
struct i915_gem_timeline *timeline;
|
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-13 17:14:48 +00:00
|
|
|
enum intel_engine_id id;
|
2016-07-15 13:56:19 +00:00
|
|
|
|
2016-10-28 12:58:47 +00:00
|
|
|
lockdep_assert_held(&dev_priv->drm.struct_mutex);
|
|
|
|
|
2016-12-29 14:40:37 +00:00
|
|
|
i915_gem_retire_requests(dev_priv);
|
|
|
|
|
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-13 17:14:48 +00:00
|
|
|
for_each_engine(engine, dev_priv, id) {
|
2016-07-15 13:56:19 +00:00
|
|
|
struct drm_i915_gem_request *req;
|
|
|
|
int ret;
|
|
|
|
|
2016-12-29 14:40:37 +00:00
|
|
|
if (engine_has_kernel_context(engine))
|
|
|
|
continue;
|
|
|
|
|
2016-07-15 13:56:19 +00:00
|
|
|
req = i915_gem_request_alloc(engine, dev_priv->kernel_context);
|
|
|
|
if (IS_ERR(req))
|
|
|
|
return PTR_ERR(req);
|
|
|
|
|
2016-10-28 12:58:47 +00:00
|
|
|
/* Queue this switch after all other activity */
|
|
|
|
list_for_each_entry(timeline, &dev_priv->gt.timelines, link) {
|
|
|
|
struct drm_i915_gem_request *prev;
|
|
|
|
struct intel_timeline *tl;
|
|
|
|
|
|
|
|
tl = &timeline->engine[engine->id];
|
|
|
|
prev = i915_gem_active_raw(&tl->last_request,
|
|
|
|
&dev_priv->drm.struct_mutex);
|
|
|
|
if (prev)
|
|
|
|
i915_sw_fence_await_sw_fence_gfp(&req->submit,
|
|
|
|
&prev->submit,
|
|
|
|
GFP_KERNEL);
|
|
|
|
}
|
|
|
|
|
2016-08-02 21:50:38 +00:00
|
|
|
ret = i915_switch_context(req);
|
2016-07-15 13:56:19 +00:00
|
|
|
i915_add_request_no_flush(req);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2014-07-24 16:04:18 +00:00
|
|
|
static bool contexts_enabled(struct drm_device *dev)
|
2014-04-09 08:07:36 +00:00
|
|
|
{
|
2014-07-24 16:04:18 +00:00
|
|
|
return i915.enable_execlists || to_i915(dev)->hw_context_size;
|
2014-04-09 08:07:36 +00:00
|
|
|
}
|
|
|
|
|
2016-11-18 13:10:47 +00:00
|
|
|
static bool client_is_banned(struct drm_i915_file_private *file_priv)
|
|
|
|
{
|
|
|
|
return file_priv->context_bans > I915_MAX_CLIENT_CONTEXT_BANS;
|
|
|
|
}
|
|
|
|
|
2012-06-04 21:42:54 +00:00
|
|
|
int i915_gem_context_create_ioctl(struct drm_device *dev, void *data,
|
|
|
|
struct drm_file *file)
|
|
|
|
{
|
|
|
|
struct drm_i915_gem_context_create *args = data;
|
|
|
|
struct drm_i915_file_private *file_priv = file->driver_priv;
|
2016-05-24 13:53:34 +00:00
|
|
|
struct i915_gem_context *ctx;
|
2012-06-04 21:42:54 +00:00
|
|
|
int ret;
|
|
|
|
|
2014-07-24 16:04:18 +00:00
|
|
|
if (!contexts_enabled(dev))
|
2012-06-19 15:16:01 +00:00
|
|
|
return -ENODEV;
|
|
|
|
|
2016-02-05 16:45:59 +00:00
|
|
|
if (args->pad != 0)
|
|
|
|
return -EINVAL;
|
|
|
|
|
2016-11-18 13:10:47 +00:00
|
|
|
if (client_is_banned(file_priv)) {
|
|
|
|
DRM_DEBUG("client %s[%d] banned from creating ctx\n",
|
|
|
|
current->comm,
|
|
|
|
pid_nr(get_task_pid(current, PIDTYPE_PID)));
|
|
|
|
|
|
|
|
return -EIO;
|
|
|
|
}
|
|
|
|
|
2012-06-04 21:42:54 +00:00
|
|
|
ret = i915_mutex_lock_interruptible(dev);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2016-12-01 14:16:38 +00:00
|
|
|
ctx = i915_gem_create_context(to_i915(dev), file_priv);
|
2012-06-04 21:42:54 +00:00
|
|
|
mutex_unlock(&dev->struct_mutex);
|
2012-07-17 06:44:49 +00:00
|
|
|
if (IS_ERR(ctx))
|
|
|
|
return PTR_ERR(ctx);
|
2012-06-04 21:42:54 +00:00
|
|
|
|
2017-01-06 15:20:13 +00:00
|
|
|
GEM_BUG_ON(i915_gem_context_is_kernel(ctx));
|
|
|
|
|
drm/i915: Emphasize that ctx->id is merely a user handle
This is an Execlists preparatory patch, since they make context ID become an
overloaded term:
- In the software, it was used to distinguish which context userspace was
trying to use.
- In the BSpec, the term is used to describe the 20-bits long field the
hardware uses to it to discriminate the contexts that are submitted to
the ELSP and inform the driver about their current status (via Context
Switch Interrupts and Context Status Buffers).
Initially, I tried to make the different meanings converge, but it proved
impossible:
- The software ctx->id is per-filp, while the hardware one needs to be
globally unique.
- Also, we multiplex several backing states objects per intel_context,
and all of them need unique HW IDs.
- I tried adding a per-filp ID and then composing the HW context ID as:
ctx->id + file_priv->id + ring->id, but the fact that the hardware only
uses 20-bits means we have to artificially limit the number of filps or
contexts the userspace can create.
The ctx->user_handle renaming bits are done with this Cocci patch (plus
manual frobbing of the struct declaration):
@@
struct intel_context c;
@@
- (c).id
+ c.user_handle
@@
struct intel_context *c;
@@
- (c)->id
+ c->user_handle
Also, while we are at it, s/DEFAULT_CONTEXT_ID/DEFAULT_CONTEXT_HANDLE and
change the type to unsigned 32 bits.
v2: s/handle/user_handle and change the type to uint32_t as suggested by
Chris Wilson.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v1)
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-07-03 15:28:00 +00:00
|
|
|
args->ctx_id = ctx->user_handle;
|
2016-11-21 11:31:09 +00:00
|
|
|
DRM_DEBUG("HW context %d created\n", args->ctx_id);
|
2012-06-04 21:42:54 +00:00
|
|
|
|
2012-07-17 06:44:49 +00:00
|
|
|
return 0;
|
2012-06-04 21:42:54 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
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;
|
2016-05-24 13:53:34 +00:00
|
|
|
struct i915_gem_context *ctx;
|
2012-06-04 21:42:54 +00:00
|
|
|
int ret;
|
|
|
|
|
2016-02-05 16:45:59 +00:00
|
|
|
if (args->pad != 0)
|
|
|
|
return -EINVAL;
|
|
|
|
|
drm/i915: Emphasize that ctx->id is merely a user handle
This is an Execlists preparatory patch, since they make context ID become an
overloaded term:
- In the software, it was used to distinguish which context userspace was
trying to use.
- In the BSpec, the term is used to describe the 20-bits long field the
hardware uses to it to discriminate the contexts that are submitted to
the ELSP and inform the driver about their current status (via Context
Switch Interrupts and Context Status Buffers).
Initially, I tried to make the different meanings converge, but it proved
impossible:
- The software ctx->id is per-filp, while the hardware one needs to be
globally unique.
- Also, we multiplex several backing states objects per intel_context,
and all of them need unique HW IDs.
- I tried adding a per-filp ID and then composing the HW context ID as:
ctx->id + file_priv->id + ring->id, but the fact that the hardware only
uses 20-bits means we have to artificially limit the number of filps or
contexts the userspace can create.
The ctx->user_handle renaming bits are done with this Cocci patch (plus
manual frobbing of the struct declaration):
@@
struct intel_context c;
@@
- (c).id
+ c.user_handle
@@
struct intel_context *c;
@@
- (c)->id
+ c->user_handle
Also, while we are at it, s/DEFAULT_CONTEXT_ID/DEFAULT_CONTEXT_HANDLE and
change the type to unsigned 32 bits.
v2: s/handle/user_handle and change the type to uint32_t as suggested by
Chris Wilson.
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org> (v1)
Signed-off-by: Oscar Mateo <oscar.mateo@intel.com>
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2014-07-03 15:28:00 +00:00
|
|
|
if (args->ctx_id == DEFAULT_CONTEXT_HANDLE)
|
2013-12-25 00:02:54 +00:00
|
|
|
return -ENOENT;
|
2013-12-06 22:11:19 +00:00
|
|
|
|
2012-06-04 21:42:54 +00:00
|
|
|
ret = i915_mutex_lock_interruptible(dev);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2016-05-24 13:53:36 +00:00
|
|
|
ctx = i915_gem_context_lookup(file_priv, args->ctx_id);
|
2014-01-03 05:50:27 +00:00
|
|
|
if (IS_ERR(ctx)) {
|
2012-06-04 21:42:54 +00:00
|
|
|
mutex_unlock(&dev->struct_mutex);
|
2014-01-03 05:50:27 +00:00
|
|
|
return PTR_ERR(ctx);
|
2012-06-04 21:42:54 +00:00
|
|
|
}
|
|
|
|
|
2017-02-09 11:34:25 +00:00
|
|
|
__destroy_hw_context(ctx, file_priv);
|
2012-06-04 21:42:54 +00:00
|
|
|
mutex_unlock(&dev->struct_mutex);
|
|
|
|
|
2016-11-21 11:31:09 +00:00
|
|
|
DRM_DEBUG("HW context %d destroyed\n", args->ctx_id);
|
2012-06-04 21:42:54 +00:00
|
|
|
return 0;
|
|
|
|
}
|
2014-12-24 16:13:40 +00:00
|
|
|
|
|
|
|
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;
|
2016-05-24 13:53:34 +00:00
|
|
|
struct i915_gem_context *ctx;
|
2014-12-24 16:13:40 +00:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = i915_mutex_lock_interruptible(dev);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2016-05-24 13:53:36 +00:00
|
|
|
ctx = i915_gem_context_lookup(file_priv, args->ctx_id);
|
2014-12-24 16:13:40 +00:00
|
|
|
if (IS_ERR(ctx)) {
|
|
|
|
mutex_unlock(&dev->struct_mutex);
|
|
|
|
return PTR_ERR(ctx);
|
|
|
|
}
|
|
|
|
|
|
|
|
args->size = 0;
|
|
|
|
switch (args->param) {
|
|
|
|
case I915_CONTEXT_PARAM_BAN_PERIOD:
|
2016-11-16 15:20:32 +00:00
|
|
|
ret = -EINVAL;
|
2014-12-24 16:13:40 +00:00
|
|
|
break;
|
2015-05-20 14:00:13 +00:00
|
|
|
case I915_CONTEXT_PARAM_NO_ZEROMAP:
|
|
|
|
args->value = ctx->flags & CONTEXT_NO_ZEROMAP;
|
|
|
|
break;
|
2015-10-14 13:17:11 +00:00
|
|
|
case I915_CONTEXT_PARAM_GTT_SIZE:
|
|
|
|
if (ctx->ppgtt)
|
|
|
|
args->value = ctx->ppgtt->base.total;
|
|
|
|
else if (to_i915(dev)->mm.aliasing_ppgtt)
|
|
|
|
args->value = to_i915(dev)->mm.aliasing_ppgtt->base.total;
|
|
|
|
else
|
2016-03-18 08:42:57 +00:00
|
|
|
args->value = to_i915(dev)->ggtt.base.total;
|
2015-10-14 13:17:11 +00:00
|
|
|
break;
|
2016-07-04 07:08:39 +00:00
|
|
|
case I915_CONTEXT_PARAM_NO_ERROR_CAPTURE:
|
2016-12-31 11:20:11 +00:00
|
|
|
args->value = i915_gem_context_no_error_capture(ctx);
|
2016-07-04 07:08:39 +00:00
|
|
|
break;
|
2016-11-16 15:20:32 +00:00
|
|
|
case I915_CONTEXT_PARAM_BANNABLE:
|
2016-12-31 11:20:11 +00:00
|
|
|
args->value = i915_gem_context_is_bannable(ctx);
|
2016-11-16 15:20:32 +00:00
|
|
|
break;
|
2014-12-24 16:13:40 +00:00
|
|
|
default:
|
|
|
|
ret = -EINVAL;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
mutex_unlock(&dev->struct_mutex);
|
|
|
|
|
|
|
|
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;
|
2016-05-24 13:53:34 +00:00
|
|
|
struct i915_gem_context *ctx;
|
2014-12-24 16:13:40 +00:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
ret = i915_mutex_lock_interruptible(dev);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2016-05-24 13:53:36 +00:00
|
|
|
ctx = i915_gem_context_lookup(file_priv, args->ctx_id);
|
2014-12-24 16:13:40 +00:00
|
|
|
if (IS_ERR(ctx)) {
|
|
|
|
mutex_unlock(&dev->struct_mutex);
|
|
|
|
return PTR_ERR(ctx);
|
|
|
|
}
|
|
|
|
|
|
|
|
switch (args->param) {
|
|
|
|
case I915_CONTEXT_PARAM_BAN_PERIOD:
|
2016-11-16 15:20:32 +00:00
|
|
|
ret = -EINVAL;
|
2014-12-24 16:13:40 +00:00
|
|
|
break;
|
2015-05-20 14:00:13 +00:00
|
|
|
case I915_CONTEXT_PARAM_NO_ZEROMAP:
|
|
|
|
if (args->size) {
|
|
|
|
ret = -EINVAL;
|
|
|
|
} else {
|
|
|
|
ctx->flags &= ~CONTEXT_NO_ZEROMAP;
|
|
|
|
ctx->flags |= args->value ? CONTEXT_NO_ZEROMAP : 0;
|
2016-07-04 07:08:39 +00:00
|
|
|
}
|
|
|
|
break;
|
|
|
|
case I915_CONTEXT_PARAM_NO_ERROR_CAPTURE:
|
2016-12-31 11:20:11 +00:00
|
|
|
if (args->size)
|
2016-07-04 07:08:39 +00:00
|
|
|
ret = -EINVAL;
|
2016-12-31 11:20:11 +00: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 14:00:13 +00:00
|
|
|
break;
|
2016-11-16 15:20:32 +00:00
|
|
|
case I915_CONTEXT_PARAM_BANNABLE:
|
|
|
|
if (args->size)
|
|
|
|
ret = -EINVAL;
|
|
|
|
else if (!capable(CAP_SYS_ADMIN) && !args->value)
|
|
|
|
ret = -EPERM;
|
2016-12-31 11:20:11 +00:00
|
|
|
else if (args->value)
|
|
|
|
i915_gem_context_set_bannable(ctx);
|
2016-11-16 15:20:32 +00:00
|
|
|
else
|
2016-12-31 11:20:11 +00:00
|
|
|
i915_gem_context_clear_bannable(ctx);
|
2016-11-16 15:20:32 +00:00
|
|
|
break;
|
2014-12-24 16:13:40 +00:00
|
|
|
default:
|
|
|
|
ret = -EINVAL;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
mutex_unlock(&dev->struct_mutex);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
2016-05-13 10:57:19 +00:00
|
|
|
|
|
|
|
int i915_gem_context_reset_stats_ioctl(struct drm_device *dev,
|
|
|
|
void *data, struct drm_file *file)
|
|
|
|
{
|
2016-07-04 10:34:36 +00:00
|
|
|
struct drm_i915_private *dev_priv = to_i915(dev);
|
2016-05-13 10:57:19 +00:00
|
|
|
struct drm_i915_reset_stats *args = data;
|
2016-05-24 13:53:34 +00:00
|
|
|
struct i915_gem_context *ctx;
|
2016-05-13 10:57:19 +00:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
if (args->flags || args->pad)
|
|
|
|
return -EINVAL;
|
|
|
|
|
|
|
|
if (args->ctx_id == DEFAULT_CONTEXT_HANDLE && !capable(CAP_SYS_ADMIN))
|
|
|
|
return -EPERM;
|
|
|
|
|
2016-05-13 10:57:20 +00:00
|
|
|
ret = i915_mutex_lock_interruptible(dev);
|
2016-05-13 10:57:19 +00:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2016-05-24 13:53:36 +00:00
|
|
|
ctx = i915_gem_context_lookup(file->driver_priv, args->ctx_id);
|
2016-05-13 10:57:19 +00:00
|
|
|
if (IS_ERR(ctx)) {
|
|
|
|
mutex_unlock(&dev->struct_mutex);
|
|
|
|
return PTR_ERR(ctx);
|
|
|
|
}
|
|
|
|
|
|
|
|
if (capable(CAP_SYS_ADMIN))
|
|
|
|
args->reset_count = i915_reset_count(&dev_priv->gpu_error);
|
|
|
|
else
|
|
|
|
args->reset_count = 0;
|
|
|
|
|
2016-11-16 15:20:34 +00:00
|
|
|
args->batch_active = ctx->guilty_count;
|
|
|
|
args->batch_pending = ctx->active_count;
|
2016-05-13 10:57:19 +00:00
|
|
|
|
|
|
|
mutex_unlock(&dev->struct_mutex);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
2017-02-13 17:15:19 +00:00
|
|
|
|
|
|
|
#if IS_ENABLED(CONFIG_DRM_I915_SELFTEST)
|
|
|
|
#include "selftests/mock_context.c"
|
2017-02-13 17:15:49 +00:00
|
|
|
#include "selftests/i915_gem_context.c"
|
2017-02-13 17:15:19 +00:00
|
|
|
#endif
|