drm/i915: preliminary context support
Very basic code for context setup/destruction in the driver.
Adds the file i915_gem_context.c This file implements HW context
support. On gen5+ a HW context consists of an opaque GPU object which is
referenced at times of context saves and restores. With RC6 enabled,
the context is also referenced as the GPU enters and exists from RC6
(GPU has it's own internal power context, except on gen5). Though
something like a context does exist for the media ring, the code only
supports contexts for the render ring.
In software, there is a distinction between contexts created by the
user, and the default HW context. The default HW context is used by GPU
clients that do not request setup of their own hardware context. The
default context's state is never restored to help prevent programming
errors. This would happen if a client ran and piggy-backed off another
clients GPU state. The default context only exists to give the GPU some
offset to load as the current to invoke a save of the context we
actually care about. In fact, the code could likely be constructed,
albeit in a more complicated fashion, to never use the default context,
though that limits the driver's ability to swap out, and/or destroy
other contexts.
All other contexts are created as a request by the GPU client. These
contexts store GPU state, and thus allow GPU clients to not re-emit
state (and potentially query certain state) at any time. The kernel
driver makes certain that the appropriate commands are inserted.
There are 4 entry points into the contexts, init, fini, open, close.
The names are self-explanatory except that init can be called during
reset, and also during pm thaw/resume. As we expect our context to be
preserved across these events, we do not reinitialize in this case.
As Adam Jackson pointed out, The cutoff of 1MB where a HW context is
considered too big is arbitrary. The reason for this is even though
context sizes are increasing with every generation, they have yet to
eclipse even 32k. If we somehow read back way more than that, it
probably means BIOS has done something strange, or we're running on a
platform that wasn't designed for this.
v2: rename load/unload to init/fini (daniel)
remove ILK support for get_size() (indirectly daniel)
add HAS_HW_CONTEXTS macro to clarify supported platforms (daniel)
added comments (Ben)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-05 04:42:42 +07:00
|
|
|
/*
|
|
|
|
* Copyright © 2011-2012 Intel Corporation
|
|
|
|
*
|
|
|
|
* Permission is hereby granted, free of charge, to any person obtaining a
|
|
|
|
* copy of this software and associated documentation files (the "Software"),
|
|
|
|
* to deal in the Software without restriction, including without limitation
|
|
|
|
* the rights to use, copy, modify, merge, publish, distribute, sublicense,
|
|
|
|
* and/or sell copies of the Software, and to permit persons to whom the
|
|
|
|
* Software is furnished to do so, subject to the following conditions:
|
|
|
|
*
|
|
|
|
* The above copyright notice and this permission notice (including the next
|
|
|
|
* paragraph) shall be included in all copies or substantial portions of the
|
|
|
|
* Software.
|
|
|
|
*
|
|
|
|
* THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
|
|
|
|
* IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
|
|
|
|
* FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
|
|
|
|
* THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
|
|
|
|
* LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
|
|
|
|
* FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS
|
|
|
|
* IN THE SOFTWARE.
|
|
|
|
*
|
|
|
|
* Authors:
|
|
|
|
* Ben Widawsky <ben@bwidawsk.net>
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
|
|
|
|
/*
|
|
|
|
* This file implements HW context support. On gen5+ a HW context consists of an
|
|
|
|
* opaque GPU object which is referenced at times of context saves and restores.
|
|
|
|
* With RC6 enabled, the context is also referenced as the GPU enters and exists
|
|
|
|
* from RC6 (GPU has it's own internal power context, except on gen5). Though
|
|
|
|
* something like a context does exist for the media ring, the code only
|
|
|
|
* supports contexts for the render ring.
|
|
|
|
*
|
|
|
|
* In software, there is a distinction between contexts created by the user,
|
|
|
|
* and the default HW context. The default HW context is used by GPU clients
|
|
|
|
* that do not request setup of their own hardware context. The default
|
|
|
|
* context's state is never restored to help prevent programming errors. This
|
|
|
|
* would happen if a client ran and piggy-backed off another clients GPU state.
|
|
|
|
* The default context only exists to give the GPU some offset to load as the
|
|
|
|
* current to invoke a save of the context we actually care about. In fact, the
|
|
|
|
* code could likely be constructed, albeit in a more complicated fashion, to
|
|
|
|
* never use the default context, though that limits the driver's ability to
|
|
|
|
* swap out, and/or destroy other contexts.
|
|
|
|
*
|
|
|
|
* All other contexts are created as a request by the GPU client. These contexts
|
|
|
|
* store GPU state, and thus allow GPU clients to not re-emit state (and
|
|
|
|
* potentially query certain state) at any time. The kernel driver makes
|
|
|
|
* certain that the appropriate commands are inserted.
|
|
|
|
*
|
|
|
|
* The context life cycle is semi-complicated in that context BOs may live
|
|
|
|
* longer than the context itself because of the way the hardware, and object
|
|
|
|
* tracking works. Below is a very crude representation of the state machine
|
|
|
|
* describing the context life.
|
|
|
|
* refcount pincount active
|
|
|
|
* S0: initial state 0 0 0
|
|
|
|
* S1: context created 1 0 0
|
|
|
|
* S2: context is currently running 2 1 X
|
|
|
|
* S3: GPU referenced, but not current 2 0 1
|
|
|
|
* S4: context is current, but destroyed 1 1 0
|
|
|
|
* S5: like S3, but destroyed 1 0 1
|
|
|
|
*
|
|
|
|
* The most common (but not all) transitions:
|
|
|
|
* S0->S1: client creates a context
|
|
|
|
* S1->S2: client submits execbuf with context
|
|
|
|
* S2->S3: other clients submits execbuf with context
|
|
|
|
* S3->S1: context object was retired
|
|
|
|
* S3->S2: clients submits another execbuf
|
|
|
|
* S2->S4: context destroy called with current context
|
|
|
|
* S3->S5->S0: destroy path
|
|
|
|
* S4->S5->S0: destroy path on current context
|
|
|
|
*
|
|
|
|
* There are two confusing terms used above:
|
|
|
|
* The "current context" means the context which is currently running on the
|
2013-08-30 20:40:26 +07:00
|
|
|
* GPU. The GPU has loaded its state already and has stored away the gtt
|
drm/i915: preliminary context support
Very basic code for context setup/destruction in the driver.
Adds the file i915_gem_context.c This file implements HW context
support. On gen5+ a HW context consists of an opaque GPU object which is
referenced at times of context saves and restores. With RC6 enabled,
the context is also referenced as the GPU enters and exists from RC6
(GPU has it's own internal power context, except on gen5). Though
something like a context does exist for the media ring, the code only
supports contexts for the render ring.
In software, there is a distinction between contexts created by the
user, and the default HW context. The default HW context is used by GPU
clients that do not request setup of their own hardware context. The
default context's state is never restored to help prevent programming
errors. This would happen if a client ran and piggy-backed off another
clients GPU state. The default context only exists to give the GPU some
offset to load as the current to invoke a save of the context we
actually care about. In fact, the code could likely be constructed,
albeit in a more complicated fashion, to never use the default context,
though that limits the driver's ability to swap out, and/or destroy
other contexts.
All other contexts are created as a request by the GPU client. These
contexts store GPU state, and thus allow GPU clients to not re-emit
state (and potentially query certain state) at any time. The kernel
driver makes certain that the appropriate commands are inserted.
There are 4 entry points into the contexts, init, fini, open, close.
The names are self-explanatory except that init can be called during
reset, and also during pm thaw/resume. As we expect our context to be
preserved across these events, we do not reinitialize in this case.
As Adam Jackson pointed out, The cutoff of 1MB where a HW context is
considered too big is arbitrary. The reason for this is even though
context sizes are increasing with every generation, they have yet to
eclipse even 32k. If we somehow read back way more than that, it
probably means BIOS has done something strange, or we're running on a
platform that wasn't designed for this.
v2: rename load/unload to init/fini (daniel)
remove ILK support for get_size() (indirectly daniel)
add HAS_HW_CONTEXTS macro to clarify supported platforms (daniel)
added comments (Ben)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-05 04:42:42 +07:00
|
|
|
* offset of the BO. The GPU is not actively referencing the data at this
|
|
|
|
* offset, but it will on the next context switch. The only way to avoid this
|
|
|
|
* is to do a GPU reset.
|
|
|
|
*
|
|
|
|
* An "active context' is one which was previously the "current context" and is
|
|
|
|
* on the active list waiting for the next context switch to occur. Until this
|
|
|
|
* happens, the object must remain at the same gtt offset. It is therefore
|
|
|
|
* possible to destroy a context, but it is still active.
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
|
2012-10-03 00:01:07 +07: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-05 04:42:42 +07:00
|
|
|
#include "i915_drv.h"
|
|
|
|
|
2012-06-05 04:42:43 +07: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-07 05:10:59 +07:00
|
|
|
#define GEN6_CONTEXT_ALIGN (64<<10)
|
|
|
|
#define GEN7_CONTEXT_ALIGN 4096
|
2012-06-05 04:42:43 +07:00
|
|
|
|
2013-12-07 05:11:01 +07:00
|
|
|
static int do_switch(struct intel_ring_buffer *ring,
|
|
|
|
struct i915_hw_context *to);
|
2012-06-05 04:42:43 +07:00
|
|
|
|
2014-02-21 02:47:07 +07:00
|
|
|
static void do_ppgtt_cleanup(struct i915_hw_ppgtt *ppgtt)
|
2014-02-21 02:47:06 +07:00
|
|
|
{
|
|
|
|
struct drm_device *dev = ppgtt->base.dev;
|
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
|
|
|
struct i915_address_space *vm = &ppgtt->base;
|
|
|
|
|
|
|
|
if (ppgtt == dev_priv->mm.aliasing_ppgtt ||
|
|
|
|
(list_empty(&vm->active_list) && list_empty(&vm->inactive_list))) {
|
|
|
|
ppgtt->base.cleanup(&ppgtt->base);
|
|
|
|
return;
|
|
|
|
}
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Make sure vmas are unbound before we take down the drm_mm
|
|
|
|
*
|
|
|
|
* FIXME: Proper refcounting should take care of this, this shouldn't be
|
|
|
|
* needed at all.
|
|
|
|
*/
|
|
|
|
if (!list_empty(&vm->active_list)) {
|
|
|
|
struct i915_vma *vma;
|
|
|
|
|
|
|
|
list_for_each_entry(vma, &vm->active_list, mm_list)
|
|
|
|
if (WARN_ON(list_empty(&vma->vma_link) ||
|
|
|
|
list_is_singular(&vma->vma_link)))
|
|
|
|
break;
|
|
|
|
|
|
|
|
i915_gem_evict_vm(&ppgtt->base, true);
|
|
|
|
} else {
|
|
|
|
i915_gem_retire_requests(dev);
|
|
|
|
i915_gem_evict_vm(&ppgtt->base, false);
|
|
|
|
}
|
|
|
|
|
|
|
|
ppgtt->base.cleanup(&ppgtt->base);
|
|
|
|
}
|
|
|
|
|
2014-02-21 02:47:07 +07:00
|
|
|
static void ppgtt_release(struct kref *kref)
|
|
|
|
{
|
|
|
|
struct i915_hw_ppgtt *ppgtt =
|
|
|
|
container_of(kref, struct i915_hw_ppgtt, ref);
|
|
|
|
|
|
|
|
do_ppgtt_cleanup(ppgtt);
|
|
|
|
kfree(ppgtt);
|
|
|
|
}
|
|
|
|
|
2013-12-07 05:10:59 +07:00
|
|
|
static size_t get_context_alignment(struct drm_device *dev)
|
|
|
|
{
|
|
|
|
if (IS_GEN6(dev))
|
|
|
|
return GEN6_CONTEXT_ALIGN;
|
|
|
|
|
|
|
|
return GEN7_CONTEXT_ALIGN;
|
|
|
|
}
|
|
|
|
|
drm/i915: preliminary context support
Very basic code for context setup/destruction in the driver.
Adds the file i915_gem_context.c This file implements HW context
support. On gen5+ a HW context consists of an opaque GPU object which is
referenced at times of context saves and restores. With RC6 enabled,
the context is also referenced as the GPU enters and exists from RC6
(GPU has it's own internal power context, except on gen5). Though
something like a context does exist for the media ring, the code only
supports contexts for the render ring.
In software, there is a distinction between contexts created by the
user, and the default HW context. The default HW context is used by GPU
clients that do not request setup of their own hardware context. The
default context's state is never restored to help prevent programming
errors. This would happen if a client ran and piggy-backed off another
clients GPU state. The default context only exists to give the GPU some
offset to load as the current to invoke a save of the context we
actually care about. In fact, the code could likely be constructed,
albeit in a more complicated fashion, to never use the default context,
though that limits the driver's ability to swap out, and/or destroy
other contexts.
All other contexts are created as a request by the GPU client. These
contexts store GPU state, and thus allow GPU clients to not re-emit
state (and potentially query certain state) at any time. The kernel
driver makes certain that the appropriate commands are inserted.
There are 4 entry points into the contexts, init, fini, open, close.
The names are self-explanatory except that init can be called during
reset, and also during pm thaw/resume. As we expect our context to be
preserved across these events, we do not reinitialize in this case.
As Adam Jackson pointed out, The cutoff of 1MB where a HW context is
considered too big is arbitrary. The reason for this is even though
context sizes are increasing with every generation, they have yet to
eclipse even 32k. If we somehow read back way more than that, it
probably means BIOS has done something strange, or we're running on a
platform that wasn't designed for this.
v2: rename load/unload to init/fini (daniel)
remove ILK support for get_size() (indirectly daniel)
add HAS_HW_CONTEXTS macro to clarify supported platforms (daniel)
added comments (Ben)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-05 04:42:42 +07:00
|
|
|
static int get_context_size(struct drm_device *dev)
|
|
|
|
{
|
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
|
|
|
int ret;
|
|
|
|
u32 reg;
|
|
|
|
|
|
|
|
switch (INTEL_INFO(dev)->gen) {
|
|
|
|
case 6:
|
|
|
|
reg = I915_READ(CXT_SIZE);
|
|
|
|
ret = GEN6_CXT_TOTAL_SIZE(reg) * 64;
|
|
|
|
break;
|
|
|
|
case 7:
|
2012-07-19 00:10:09 +07:00
|
|
|
reg = I915_READ(GEN7_CXT_SIZE);
|
2012-07-25 10:47:30 +07:00
|
|
|
if (IS_HASWELL(dev))
|
2013-06-26 11:53:40 +07:00
|
|
|
ret = HSW_CXT_TOTAL_SIZE;
|
2012-07-25 10:47:30 +07: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-05 04:42:42 +07:00
|
|
|
break;
|
2013-11-03 11:07:05 +07: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-05 04:42:42 +07:00
|
|
|
default:
|
|
|
|
BUG();
|
|
|
|
}
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2013-04-30 17:30:33 +07:00
|
|
|
void i915_gem_context_free(struct kref *ctx_ref)
|
2012-06-05 04:42:43 +07:00
|
|
|
{
|
2013-04-30 17:30:33 +07:00
|
|
|
struct i915_hw_context *ctx = container_of(ctx_ref,
|
|
|
|
typeof(*ctx), ref);
|
drm/i915: Add VM to context
Pretty straightforward so far except for the bit about the refcounting.
The PPGTT will potentially be shared amongst multiple contexts. Because
contexts themselves have a refcounted lifecycle, the easiest way to
manage this will be to refcount the PPGTT. To acheive this, we piggy
back off of the existing context refcount, and will increment and
decrement the PPGTT refcount with context creation, and destruction.
To put it more clearly, if context A, and context B both use PPGTT 0, we
can't free the PPGTT until both A, and B are destroyed.
Note that because the PPGTT is permanently pinned (for now), it really
just matters for the PPGTT destruction, as opposed to making space under
memory pressure.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-07 05:11:15 +07:00
|
|
|
struct i915_hw_ppgtt *ppgtt = NULL;
|
2012-06-05 04:42:43 +07:00
|
|
|
|
drm/i915: Add VM to context
Pretty straightforward so far except for the bit about the refcounting.
The PPGTT will potentially be shared amongst multiple contexts. Because
contexts themselves have a refcounted lifecycle, the easiest way to
manage this will be to refcount the PPGTT. To acheive this, we piggy
back off of the existing context refcount, and will increment and
decrement the PPGTT refcount with context creation, and destruction.
To put it more clearly, if context A, and context B both use PPGTT 0, we
can't free the PPGTT until both A, and B are destroyed.
Note that because the PPGTT is permanently pinned (for now), it really
just matters for the PPGTT destruction, as opposed to making space under
memory pressure.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-07 05:11:15 +07:00
|
|
|
/* We refcount even the aliasing PPGTT to keep the code symmetric */
|
2014-01-28 14:07:00 +07:00
|
|
|
if (USES_PPGTT(ctx->obj->base.dev))
|
2013-12-07 05:11:19 +07:00
|
|
|
ppgtt = ctx_to_ppgtt(ctx);
|
drm/i915: Add VM to context
Pretty straightforward so far except for the bit about the refcounting.
The PPGTT will potentially be shared amongst multiple contexts. Because
contexts themselves have a refcounted lifecycle, the easiest way to
manage this will be to refcount the PPGTT. To acheive this, we piggy
back off of the existing context refcount, and will increment and
decrement the PPGTT refcount with context creation, and destruction.
To put it more clearly, if context A, and context B both use PPGTT 0, we
can't free the PPGTT until both A, and B are destroyed.
Note that because the PPGTT is permanently pinned (for now), it really
just matters for the PPGTT destruction, as opposed to making space under
memory pressure.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-07 05:11:15 +07:00
|
|
|
|
|
|
|
/* XXX: Free up the object before tearing down the address space, in
|
|
|
|
* case we're bound in the PPGTT */
|
2012-06-05 04:42:43 +07:00
|
|
|
drm_gem_object_unreference(&ctx->obj->base);
|
drm/i915: Add VM to context
Pretty straightforward so far except for the bit about the refcounting.
The PPGTT will potentially be shared amongst multiple contexts. Because
contexts themselves have a refcounted lifecycle, the easiest way to
manage this will be to refcount the PPGTT. To acheive this, we piggy
back off of the existing context refcount, and will increment and
decrement the PPGTT refcount with context creation, and destruction.
To put it more clearly, if context A, and context B both use PPGTT 0, we
can't free the PPGTT until both A, and B are destroyed.
Note that because the PPGTT is permanently pinned (for now), it really
just matters for the PPGTT destruction, as opposed to making space under
memory pressure.
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-07 05:11:15 +07:00
|
|
|
|
|
|
|
if (ppgtt)
|
|
|
|
kref_put(&ppgtt->ref, ppgtt_release);
|
|
|
|
list_del(&ctx->link);
|
2012-06-05 04:42:43 +07:00
|
|
|
kfree(ctx);
|
|
|
|
}
|
|
|
|
|
2013-12-07 05:11:18 +07:00
|
|
|
static struct i915_hw_ppgtt *
|
|
|
|
create_vm_for_ctx(struct drm_device *dev, struct i915_hw_context *ctx)
|
|
|
|
{
|
|
|
|
struct i915_hw_ppgtt *ppgtt;
|
|
|
|
int ret;
|
|
|
|
|
|
|
|
ppgtt = kzalloc(sizeof(*ppgtt), GFP_KERNEL);
|
|
|
|
if (!ppgtt)
|
|
|
|
return ERR_PTR(-ENOMEM);
|
|
|
|
|
|
|
|
ret = i915_gem_init_ppgtt(dev, ppgtt);
|
|
|
|
if (ret) {
|
|
|
|
kfree(ppgtt);
|
|
|
|
return ERR_PTR(ret);
|
|
|
|
}
|
|
|
|
|
2014-03-19 20:45:45 +07:00
|
|
|
ppgtt->ctx = ctx;
|
2013-12-07 05:11:18 +07:00
|
|
|
return ppgtt;
|
|
|
|
}
|
|
|
|
|
2012-06-30 00:30:39 +07:00
|
|
|
static struct i915_hw_context *
|
2013-12-07 05:11:19 +07:00
|
|
|
__create_hw_context(struct drm_device *dev,
|
2012-06-30 00:30:39 +07:00
|
|
|
struct drm_i915_file_private *file_priv)
|
2012-06-05 04:42:43 +07:00
|
|
|
{
|
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
2012-06-30 00:30:39 +07:00
|
|
|
struct i915_hw_context *ctx;
|
2013-02-28 08:04:10 +07:00
|
|
|
int ret;
|
2012-06-05 04:42:43 +07:00
|
|
|
|
2012-11-11 01:56:04 +07:00
|
|
|
ctx = kzalloc(sizeof(*ctx), GFP_KERNEL);
|
2012-06-30 00:30:39 +07:00
|
|
|
if (ctx == NULL)
|
|
|
|
return ERR_PTR(-ENOMEM);
|
2012-06-05 04:42:43 +07:00
|
|
|
|
2013-04-30 17:30:33 +07:00
|
|
|
kref_init(&ctx->ref);
|
2012-06-30 00:30:39 +07:00
|
|
|
ctx->obj = i915_gem_alloc_object(dev, dev_priv->hw_context_size);
|
2013-09-18 11:12:45 +07:00
|
|
|
INIT_LIST_HEAD(&ctx->link);
|
2012-06-30 00:30:39 +07:00
|
|
|
if (ctx->obj == NULL) {
|
|
|
|
kfree(ctx);
|
2012-06-05 04:42:43 +07:00
|
|
|
DRM_DEBUG_DRIVER("Context object allocated failed\n");
|
2012-06-30 00:30:39 +07:00
|
|
|
return ERR_PTR(-ENOMEM);
|
2012-06-05 04:42:43 +07:00
|
|
|
}
|
|
|
|
|
2013-04-08 20:28:40 +07:00
|
|
|
if (INTEL_INFO(dev)->gen >= 7) {
|
|
|
|
ret = i915_gem_object_set_cache_level(ctx->obj,
|
2013-08-06 19:17:02 +07:00
|
|
|
I915_CACHE_L3_LLC);
|
2013-05-26 02:26:38 +07:00
|
|
|
/* Failure shouldn't ever happen this early */
|
|
|
|
if (WARN_ON(ret))
|
2013-04-08 20:28:40 +07:00
|
|
|
goto err_out;
|
|
|
|
}
|
|
|
|
|
2013-09-18 11:12:45 +07:00
|
|
|
list_add_tail(&ctx->link, &dev_priv->context_list);
|
2012-06-05 04:42:43 +07:00
|
|
|
|
|
|
|
/* Default context will never have a file_priv */
|
|
|
|
if (file_priv == NULL)
|
2012-06-30 00:30:39 +07:00
|
|
|
return ctx;
|
2012-06-05 04:42:43 +07:00
|
|
|
|
2013-12-07 05:11:19 +07:00
|
|
|
ret = idr_alloc(&file_priv->context_idr, ctx, DEFAULT_CONTEXT_ID, 0,
|
2013-02-28 08:04:10 +07:00
|
|
|
GFP_KERNEL);
|
|
|
|
if (ret < 0)
|
2012-06-05 04:42:43 +07:00
|
|
|
goto err_out;
|
2013-04-30 17:30:33 +07:00
|
|
|
|
|
|
|
ctx->file_priv = file_priv;
|
2013-02-28 08:04:10 +07:00
|
|
|
ctx->id = 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 09:03:18 +07:00
|
|
|
/* NB: Mark all slices as needing a remap so that when the context first
|
|
|
|
* loads it will restore whatever remap state already exists. If there
|
|
|
|
* is no remap info, it will be a NOP. */
|
|
|
|
ctx->remap_slice = (1 << NUM_L3_SLICES(dev)) - 1;
|
2012-06-05 04:42:43 +07:00
|
|
|
|
2012-06-30 00:30:39 +07:00
|
|
|
return ctx;
|
2012-06-05 04:42:43 +07:00
|
|
|
|
|
|
|
err_out:
|
2013-04-30 17:30:33 +07:00
|
|
|
i915_gem_context_unreference(ctx);
|
2012-06-30 00:30:39 +07:00
|
|
|
return ERR_PTR(ret);
|
2012-06-05 04:42:43 +07:00
|
|
|
}
|
|
|
|
|
drm/i915: preliminary context support
Very basic code for context setup/destruction in the driver.
Adds the file i915_gem_context.c This file implements HW context
support. On gen5+ a HW context consists of an opaque GPU object which is
referenced at times of context saves and restores. With RC6 enabled,
the context is also referenced as the GPU enters and exists from RC6
(GPU has it's own internal power context, except on gen5). Though
something like a context does exist for the media ring, the code only
supports contexts for the render ring.
In software, there is a distinction between contexts created by the
user, and the default HW context. The default HW context is used by GPU
clients that do not request setup of their own hardware context. The
default context's state is never restored to help prevent programming
errors. This would happen if a client ran and piggy-backed off another
clients GPU state. The default context only exists to give the GPU some
offset to load as the current to invoke a save of the context we
actually care about. In fact, the code could likely be constructed,
albeit in a more complicated fashion, to never use the default context,
though that limits the driver's ability to swap out, and/or destroy
other contexts.
All other contexts are created as a request by the GPU client. These
contexts store GPU state, and thus allow GPU clients to not re-emit
state (and potentially query certain state) at any time. The kernel
driver makes certain that the appropriate commands are inserted.
There are 4 entry points into the contexts, init, fini, open, close.
The names are self-explanatory except that init can be called during
reset, and also during pm thaw/resume. As we expect our context to be
preserved across these events, we do not reinitialize in this case.
As Adam Jackson pointed out, The cutoff of 1MB where a HW context is
considered too big is arbitrary. The reason for this is even though
context sizes are increasing with every generation, they have yet to
eclipse even 32k. If we somehow read back way more than that, it
probably means BIOS has done something strange, or we're running on a
platform that wasn't designed for this.
v2: rename load/unload to init/fini (daniel)
remove ILK support for get_size() (indirectly daniel)
add HAS_HW_CONTEXTS macro to clarify supported platforms (daniel)
added comments (Ben)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-05 04:42:42 +07:00
|
|
|
/**
|
|
|
|
* 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.
|
|
|
|
*/
|
2013-12-07 05:11:05 +07:00
|
|
|
static struct i915_hw_context *
|
2013-12-07 05:11:19 +07:00
|
|
|
i915_gem_create_context(struct drm_device *dev,
|
|
|
|
struct drm_i915_file_private *file_priv,
|
|
|
|
bool create_vm)
|
drm/i915: preliminary context support
Very basic code for context setup/destruction in the driver.
Adds the file i915_gem_context.c This file implements HW context
support. On gen5+ a HW context consists of an opaque GPU object which is
referenced at times of context saves and restores. With RC6 enabled,
the context is also referenced as the GPU enters and exists from RC6
(GPU has it's own internal power context, except on gen5). Though
something like a context does exist for the media ring, the code only
supports contexts for the render ring.
In software, there is a distinction between contexts created by the
user, and the default HW context. The default HW context is used by GPU
clients that do not request setup of their own hardware context. The
default context's state is never restored to help prevent programming
errors. This would happen if a client ran and piggy-backed off another
clients GPU state. The default context only exists to give the GPU some
offset to load as the current to invoke a save of the context we
actually care about. In fact, the code could likely be constructed,
albeit in a more complicated fashion, to never use the default context,
though that limits the driver's ability to swap out, and/or destroy
other contexts.
All other contexts are created as a request by the GPU client. These
contexts store GPU state, and thus allow GPU clients to not re-emit
state (and potentially query certain state) at any time. The kernel
driver makes certain that the appropriate commands are inserted.
There are 4 entry points into the contexts, init, fini, open, close.
The names are self-explanatory except that init can be called during
reset, and also during pm thaw/resume. As we expect our context to be
preserved across these events, we do not reinitialize in this case.
As Adam Jackson pointed out, The cutoff of 1MB where a HW context is
considered too big is arbitrary. The reason for this is even though
context sizes are increasing with every generation, they have yet to
eclipse even 32k. If we somehow read back way more than that, it
probably means BIOS has done something strange, or we're running on a
platform that wasn't designed for this.
v2: rename load/unload to init/fini (daniel)
remove ILK support for get_size() (indirectly daniel)
add HAS_HW_CONTEXTS macro to clarify supported platforms (daniel)
added comments (Ben)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-05 04:42:42 +07:00
|
|
|
{
|
2014-01-24 02:40:02 +07:00
|
|
|
const bool is_global_default_ctx = file_priv == NULL;
|
2013-12-07 05:11:18 +07:00
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
2012-06-05 04:42:43 +07:00
|
|
|
struct i915_hw_context *ctx;
|
2013-12-07 05:11:18 +07:00
|
|
|
int ret = 0;
|
2012-06-05 04:42:43 +07:00
|
|
|
|
2013-12-07 05:10:59 +07:00
|
|
|
BUG_ON(!mutex_is_locked(&dev->struct_mutex));
|
2012-06-05 04:42:43 +07:00
|
|
|
|
2013-12-07 05:11:19 +07:00
|
|
|
ctx = __create_hw_context(dev, file_priv);
|
2012-06-30 00:30:39 +07:00
|
|
|
if (IS_ERR(ctx))
|
2013-12-07 05:11:05 +07:00
|
|
|
return ctx;
|
2012-06-05 04:42:43 +07:00
|
|
|
|
2014-01-24 02:40:02 +07:00
|
|
|
if (is_global_default_ctx) {
|
|
|
|
/* We may need to do things with the shrinker which
|
|
|
|
* require us to immediately switch back to the default
|
|
|
|
* context. This can cause a problem as pinning the
|
|
|
|
* default context also requires GTT space which may not
|
|
|
|
* be available. To avoid this we always pin the default
|
|
|
|
* context.
|
|
|
|
*/
|
|
|
|
ret = i915_gem_obj_ggtt_pin(ctx->obj,
|
2014-02-14 20:01:11 +07:00
|
|
|
get_context_alignment(dev), 0);
|
2014-01-24 02:40:02 +07:00
|
|
|
if (ret) {
|
|
|
|
DRM_DEBUG_DRIVER("Couldn't pin %d\n", ret);
|
|
|
|
goto err_destroy;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-12-07 05:11:18 +07:00
|
|
|
if (create_vm) {
|
|
|
|
struct i915_hw_ppgtt *ppgtt = create_vm_for_ctx(dev, ctx);
|
|
|
|
|
|
|
|
if (IS_ERR_OR_NULL(ppgtt)) {
|
2013-12-07 05:11:19 +07:00
|
|
|
DRM_DEBUG_DRIVER("PPGTT setup failed (%ld)\n",
|
|
|
|
PTR_ERR(ppgtt));
|
2013-12-07 05:11:18 +07:00
|
|
|
ret = PTR_ERR(ppgtt);
|
2014-01-24 02:40:02 +07:00
|
|
|
goto err_unpin;
|
2013-12-07 05:11:18 +07:00
|
|
|
} else
|
|
|
|
ctx->vm = &ppgtt->base;
|
|
|
|
|
|
|
|
/* This case is reserved for the global default context and
|
|
|
|
* should only happen once. */
|
2014-01-24 02:40:02 +07:00
|
|
|
if (is_global_default_ctx) {
|
2013-12-07 05:11:18 +07:00
|
|
|
if (WARN_ON(dev_priv->mm.aliasing_ppgtt)) {
|
|
|
|
ret = -EEXIST;
|
2014-01-24 02:40:02 +07:00
|
|
|
goto err_unpin;
|
2013-12-07 05:11:18 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
dev_priv->mm.aliasing_ppgtt = ppgtt;
|
|
|
|
}
|
2014-01-28 14:07:00 +07:00
|
|
|
} else if (USES_PPGTT(dev)) {
|
2013-12-07 05:11:18 +07:00
|
|
|
/* For platforms which only have aliasing PPGTT, we fake the
|
|
|
|
* address space and refcounting. */
|
|
|
|
ctx->vm = &dev_priv->mm.aliasing_ppgtt->base;
|
2013-12-07 05:11:26 +07:00
|
|
|
kref_get(&dev_priv->mm.aliasing_ppgtt->ref);
|
|
|
|
} else
|
2013-12-07 05:11:18 +07:00
|
|
|
ctx->vm = &dev_priv->gtt.base;
|
|
|
|
|
2013-12-07 05:11:05 +07:00
|
|
|
return ctx;
|
2012-07-15 18:34:24 +07:00
|
|
|
|
2014-01-24 02:40:02 +07:00
|
|
|
err_unpin:
|
|
|
|
if (is_global_default_ctx)
|
|
|
|
i915_gem_object_ggtt_unpin(ctx->obj);
|
2012-07-15 18:34:24 +07:00
|
|
|
err_destroy:
|
2013-04-30 17:30:33 +07:00
|
|
|
i915_gem_context_unreference(ctx);
|
2013-12-07 05:11:05 +07:00
|
|
|
return ERR_PTR(ret);
|
drm/i915: preliminary context support
Very basic code for context setup/destruction in the driver.
Adds the file i915_gem_context.c This file implements HW context
support. On gen5+ a HW context consists of an opaque GPU object which is
referenced at times of context saves and restores. With RC6 enabled,
the context is also referenced as the GPU enters and exists from RC6
(GPU has it's own internal power context, except on gen5). Though
something like a context does exist for the media ring, the code only
supports contexts for the render ring.
In software, there is a distinction between contexts created by the
user, and the default HW context. The default HW context is used by GPU
clients that do not request setup of their own hardware context. The
default context's state is never restored to help prevent programming
errors. This would happen if a client ran and piggy-backed off another
clients GPU state. The default context only exists to give the GPU some
offset to load as the current to invoke a save of the context we
actually care about. In fact, the code could likely be constructed,
albeit in a more complicated fashion, to never use the default context,
though that limits the driver's ability to swap out, and/or destroy
other contexts.
All other contexts are created as a request by the GPU client. These
contexts store GPU state, and thus allow GPU clients to not re-emit
state (and potentially query certain state) at any time. The kernel
driver makes certain that the appropriate commands are inserted.
There are 4 entry points into the contexts, init, fini, open, close.
The names are self-explanatory except that init can be called during
reset, and also during pm thaw/resume. As we expect our context to be
preserved across these events, we do not reinitialize in this case.
As Adam Jackson pointed out, The cutoff of 1MB where a HW context is
considered too big is arbitrary. The reason for this is even though
context sizes are increasing with every generation, they have yet to
eclipse even 32k. If we somehow read back way more than that, it
probably means BIOS has done something strange, or we're running on a
platform that wasn't designed for this.
v2: rename load/unload to init/fini (daniel)
remove ILK support for get_size() (indirectly daniel)
add HAS_HW_CONTEXTS macro to clarify supported platforms (daniel)
added comments (Ben)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-05 04:42:42 +07:00
|
|
|
}
|
|
|
|
|
2013-12-07 05:11:03 +07:00
|
|
|
void i915_gem_context_reset(struct drm_device *dev)
|
|
|
|
{
|
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
|
|
|
struct intel_ring_buffer *ring;
|
|
|
|
int i;
|
|
|
|
|
|
|
|
if (!HAS_HW_CONTEXTS(dev))
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* Prevent the hardware from restoring the last context (which hung) on
|
|
|
|
* the next switch */
|
|
|
|
for (i = 0; i < I915_NUM_RINGS; i++) {
|
|
|
|
struct i915_hw_context *dctx;
|
|
|
|
if (!(INTEL_INFO(dev)->ring_mask & (1<<i)))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
/* Do a fake switch to the default context */
|
|
|
|
ring = &dev_priv->ring[i];
|
|
|
|
dctx = ring->default_context;
|
|
|
|
if (WARN_ON(!dctx))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (!ring->last_context)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (ring->last_context == dctx)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (i == RCS) {
|
|
|
|
WARN_ON(i915_gem_obj_ggtt_pin(dctx->obj,
|
2014-02-14 20:01:11 +07:00
|
|
|
get_context_alignment(dev), 0));
|
2013-12-07 05:11:03 +07:00
|
|
|
/* Fake a finish/inactive */
|
|
|
|
dctx->obj->base.write_domain = 0;
|
|
|
|
dctx->obj->active = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
i915_gem_context_unreference(ring->last_context);
|
|
|
|
i915_gem_context_reference(dctx);
|
|
|
|
ring->last_context = dctx;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-11-06 22:56:29 +07:00
|
|
|
int i915_gem_context_init(struct drm_device *dev)
|
drm/i915: preliminary context support
Very basic code for context setup/destruction in the driver.
Adds the file i915_gem_context.c This file implements HW context
support. On gen5+ a HW context consists of an opaque GPU object which is
referenced at times of context saves and restores. With RC6 enabled,
the context is also referenced as the GPU enters and exists from RC6
(GPU has it's own internal power context, except on gen5). Though
something like a context does exist for the media ring, the code only
supports contexts for the render ring.
In software, there is a distinction between contexts created by the
user, and the default HW context. The default HW context is used by GPU
clients that do not request setup of their own hardware context. The
default context's state is never restored to help prevent programming
errors. This would happen if a client ran and piggy-backed off another
clients GPU state. The default context only exists to give the GPU some
offset to load as the current to invoke a save of the context we
actually care about. In fact, the code could likely be constructed,
albeit in a more complicated fashion, to never use the default context,
though that limits the driver's ability to swap out, and/or destroy
other contexts.
All other contexts are created as a request by the GPU client. These
contexts store GPU state, and thus allow GPU clients to not re-emit
state (and potentially query certain state) at any time. The kernel
driver makes certain that the appropriate commands are inserted.
There are 4 entry points into the contexts, init, fini, open, close.
The names are self-explanatory except that init can be called during
reset, and also during pm thaw/resume. As we expect our context to be
preserved across these events, we do not reinitialize in this case.
As Adam Jackson pointed out, The cutoff of 1MB where a HW context is
considered too big is arbitrary. The reason for this is even though
context sizes are increasing with every generation, they have yet to
eclipse even 32k. If we somehow read back way more than that, it
probably means BIOS has done something strange, or we're running on a
platform that wasn't designed for this.
v2: rename load/unload to init/fini (daniel)
remove ILK support for get_size() (indirectly daniel)
add HAS_HW_CONTEXTS macro to clarify supported platforms (daniel)
added comments (Ben)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-05 04:42:42 +07:00
|
|
|
{
|
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
2013-12-07 05:11:01 +07:00
|
|
|
struct intel_ring_buffer *ring;
|
2013-12-07 05:11:05 +07:00
|
|
|
int i;
|
drm/i915: preliminary context support
Very basic code for context setup/destruction in the driver.
Adds the file i915_gem_context.c This file implements HW context
support. On gen5+ a HW context consists of an opaque GPU object which is
referenced at times of context saves and restores. With RC6 enabled,
the context is also referenced as the GPU enters and exists from RC6
(GPU has it's own internal power context, except on gen5). Though
something like a context does exist for the media ring, the code only
supports contexts for the render ring.
In software, there is a distinction between contexts created by the
user, and the default HW context. The default HW context is used by GPU
clients that do not request setup of their own hardware context. The
default context's state is never restored to help prevent programming
errors. This would happen if a client ran and piggy-backed off another
clients GPU state. The default context only exists to give the GPU some
offset to load as the current to invoke a save of the context we
actually care about. In fact, the code could likely be constructed,
albeit in a more complicated fashion, to never use the default context,
though that limits the driver's ability to swap out, and/or destroy
other contexts.
All other contexts are created as a request by the GPU client. These
contexts store GPU state, and thus allow GPU clients to not re-emit
state (and potentially query certain state) at any time. The kernel
driver makes certain that the appropriate commands are inserted.
There are 4 entry points into the contexts, init, fini, open, close.
The names are self-explanatory except that init can be called during
reset, and also during pm thaw/resume. As we expect our context to be
preserved across these events, we do not reinitialize in this case.
As Adam Jackson pointed out, The cutoff of 1MB where a HW context is
considered too big is arbitrary. The reason for this is even though
context sizes are increasing with every generation, they have yet to
eclipse even 32k. If we somehow read back way more than that, it
probably means BIOS has done something strange, or we're running on a
platform that wasn't designed for this.
v2: rename load/unload to init/fini (daniel)
remove ILK support for get_size() (indirectly daniel)
add HAS_HW_CONTEXTS macro to clarify supported platforms (daniel)
added comments (Ben)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-05 04:42:42 +07:00
|
|
|
|
2013-11-06 22:56:29 +07:00
|
|
|
if (!HAS_HW_CONTEXTS(dev))
|
|
|
|
return 0;
|
drm/i915: preliminary context support
Very basic code for context setup/destruction in the driver.
Adds the file i915_gem_context.c This file implements HW context
support. On gen5+ a HW context consists of an opaque GPU object which is
referenced at times of context saves and restores. With RC6 enabled,
the context is also referenced as the GPU enters and exists from RC6
(GPU has it's own internal power context, except on gen5). Though
something like a context does exist for the media ring, the code only
supports contexts for the render ring.
In software, there is a distinction between contexts created by the
user, and the default HW context. The default HW context is used by GPU
clients that do not request setup of their own hardware context. The
default context's state is never restored to help prevent programming
errors. This would happen if a client ran and piggy-backed off another
clients GPU state. The default context only exists to give the GPU some
offset to load as the current to invoke a save of the context we
actually care about. In fact, the code could likely be constructed,
albeit in a more complicated fashion, to never use the default context,
though that limits the driver's ability to swap out, and/or destroy
other contexts.
All other contexts are created as a request by the GPU client. These
contexts store GPU state, and thus allow GPU clients to not re-emit
state (and potentially query certain state) at any time. The kernel
driver makes certain that the appropriate commands are inserted.
There are 4 entry points into the contexts, init, fini, open, close.
The names are self-explanatory except that init can be called during
reset, and also during pm thaw/resume. As we expect our context to be
preserved across these events, we do not reinitialize in this case.
As Adam Jackson pointed out, The cutoff of 1MB where a HW context is
considered too big is arbitrary. The reason for this is even though
context sizes are increasing with every generation, they have yet to
eclipse even 32k. If we somehow read back way more than that, it
probably means BIOS has done something strange, or we're running on a
platform that wasn't designed for this.
v2: rename load/unload to init/fini (daniel)
remove ILK support for get_size() (indirectly daniel)
add HAS_HW_CONTEXTS macro to clarify supported platforms (daniel)
added comments (Ben)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-05 04:42:42 +07:00
|
|
|
|
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-07 05:11:04 +07:00
|
|
|
/* Init should only be called once per module load. Eventually the
|
|
|
|
* restriction on the context_disabled check can be loosened. */
|
|
|
|
if (WARN_ON(dev_priv->ring[RCS].default_context))
|
2013-11-06 22:56:29 +07:00
|
|
|
return 0;
|
drm/i915: preliminary context support
Very basic code for context setup/destruction in the driver.
Adds the file i915_gem_context.c This file implements HW context
support. On gen5+ a HW context consists of an opaque GPU object which is
referenced at times of context saves and restores. With RC6 enabled,
the context is also referenced as the GPU enters and exists from RC6
(GPU has it's own internal power context, except on gen5). Though
something like a context does exist for the media ring, the code only
supports contexts for the render ring.
In software, there is a distinction between contexts created by the
user, and the default HW context. The default HW context is used by GPU
clients that do not request setup of their own hardware context. The
default context's state is never restored to help prevent programming
errors. This would happen if a client ran and piggy-backed off another
clients GPU state. The default context only exists to give the GPU some
offset to load as the current to invoke a save of the context we
actually care about. In fact, the code could likely be constructed,
albeit in a more complicated fashion, to never use the default context,
though that limits the driver's ability to swap out, and/or destroy
other contexts.
All other contexts are created as a request by the GPU client. These
contexts store GPU state, and thus allow GPU clients to not re-emit
state (and potentially query certain state) at any time. The kernel
driver makes certain that the appropriate commands are inserted.
There are 4 entry points into the contexts, init, fini, open, close.
The names are self-explanatory except that init can be called during
reset, and also during pm thaw/resume. As we expect our context to be
preserved across these events, we do not reinitialize in this case.
As Adam Jackson pointed out, The cutoff of 1MB where a HW context is
considered too big is arbitrary. The reason for this is even though
context sizes are increasing with every generation, they have yet to
eclipse even 32k. If we somehow read back way more than that, it
probably means BIOS has done something strange, or we're running on a
platform that wasn't designed for this.
v2: rename load/unload to init/fini (daniel)
remove ILK support for get_size() (indirectly daniel)
add HAS_HW_CONTEXTS macro to clarify supported platforms (daniel)
added comments (Ben)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-05 04:42:42 +07:00
|
|
|
|
2013-02-08 04:34:19 +07:00
|
|
|
dev_priv->hw_context_size = round_up(get_context_size(dev), 4096);
|
drm/i915: preliminary context support
Very basic code for context setup/destruction in the driver.
Adds the file i915_gem_context.c This file implements HW context
support. On gen5+ a HW context consists of an opaque GPU object which is
referenced at times of context saves and restores. With RC6 enabled,
the context is also referenced as the GPU enters and exists from RC6
(GPU has it's own internal power context, except on gen5). Though
something like a context does exist for the media ring, the code only
supports contexts for the render ring.
In software, there is a distinction between contexts created by the
user, and the default HW context. The default HW context is used by GPU
clients that do not request setup of their own hardware context. The
default context's state is never restored to help prevent programming
errors. This would happen if a client ran and piggy-backed off another
clients GPU state. The default context only exists to give the GPU some
offset to load as the current to invoke a save of the context we
actually care about. In fact, the code could likely be constructed,
albeit in a more complicated fashion, to never use the default context,
though that limits the driver's ability to swap out, and/or destroy
other contexts.
All other contexts are created as a request by the GPU client. These
contexts store GPU state, and thus allow GPU clients to not re-emit
state (and potentially query certain state) at any time. The kernel
driver makes certain that the appropriate commands are inserted.
There are 4 entry points into the contexts, init, fini, open, close.
The names are self-explanatory except that init can be called during
reset, and also during pm thaw/resume. As we expect our context to be
preserved across these events, we do not reinitialize in this case.
As Adam Jackson pointed out, The cutoff of 1MB where a HW context is
considered too big is arbitrary. The reason for this is even though
context sizes are increasing with every generation, they have yet to
eclipse even 32k. If we somehow read back way more than that, it
probably means BIOS has done something strange, or we're running on a
platform that wasn't designed for this.
v2: rename load/unload to init/fini (daniel)
remove ILK support for get_size() (indirectly daniel)
add HAS_HW_CONTEXTS macro to clarify supported platforms (daniel)
added comments (Ben)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-05 04:42:42 +07:00
|
|
|
|
2013-02-08 04:34:19 +07:00
|
|
|
if (dev_priv->hw_context_size > (1<<20)) {
|
2013-05-26 02:26:38 +07:00
|
|
|
DRM_DEBUG_DRIVER("Disabling HW Contexts; invalid size\n");
|
2013-11-06 22:56:29 +07:00
|
|
|
return -E2BIG;
|
drm/i915: preliminary context support
Very basic code for context setup/destruction in the driver.
Adds the file i915_gem_context.c This file implements HW context
support. On gen5+ a HW context consists of an opaque GPU object which is
referenced at times of context saves and restores. With RC6 enabled,
the context is also referenced as the GPU enters and exists from RC6
(GPU has it's own internal power context, except on gen5). Though
something like a context does exist for the media ring, the code only
supports contexts for the render ring.
In software, there is a distinction between contexts created by the
user, and the default HW context. The default HW context is used by GPU
clients that do not request setup of their own hardware context. The
default context's state is never restored to help prevent programming
errors. This would happen if a client ran and piggy-backed off another
clients GPU state. The default context only exists to give the GPU some
offset to load as the current to invoke a save of the context we
actually care about. In fact, the code could likely be constructed,
albeit in a more complicated fashion, to never use the default context,
though that limits the driver's ability to swap out, and/or destroy
other contexts.
All other contexts are created as a request by the GPU client. These
contexts store GPU state, and thus allow GPU clients to not re-emit
state (and potentially query certain state) at any time. The kernel
driver makes certain that the appropriate commands are inserted.
There are 4 entry points into the contexts, init, fini, open, close.
The names are self-explanatory except that init can be called during
reset, and also during pm thaw/resume. As we expect our context to be
preserved across these events, we do not reinitialize in this case.
As Adam Jackson pointed out, The cutoff of 1MB where a HW context is
considered too big is arbitrary. The reason for this is even though
context sizes are increasing with every generation, they have yet to
eclipse even 32k. If we somehow read back way more than that, it
probably means BIOS has done something strange, or we're running on a
platform that wasn't designed for this.
v2: rename load/unload to init/fini (daniel)
remove ILK support for get_size() (indirectly daniel)
add HAS_HW_CONTEXTS macro to clarify supported platforms (daniel)
added comments (Ben)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-05 04:42:42 +07:00
|
|
|
}
|
|
|
|
|
2013-12-07 05:11:18 +07:00
|
|
|
dev_priv->ring[RCS].default_context =
|
2014-01-28 14:07:00 +07:00
|
|
|
i915_gem_create_context(dev, NULL, USES_PPGTT(dev));
|
2013-12-07 05:11:05 +07:00
|
|
|
|
|
|
|
if (IS_ERR_OR_NULL(dev_priv->ring[RCS].default_context)) {
|
|
|
|
DRM_DEBUG_DRIVER("Disabling HW Contexts; create failed %ld\n",
|
|
|
|
PTR_ERR(dev_priv->ring[RCS].default_context));
|
|
|
|
return PTR_ERR(dev_priv->ring[RCS].default_context);
|
drm/i915: preliminary context support
Very basic code for context setup/destruction in the driver.
Adds the file i915_gem_context.c This file implements HW context
support. On gen5+ a HW context consists of an opaque GPU object which is
referenced at times of context saves and restores. With RC6 enabled,
the context is also referenced as the GPU enters and exists from RC6
(GPU has it's own internal power context, except on gen5). Though
something like a context does exist for the media ring, the code only
supports contexts for the render ring.
In software, there is a distinction between contexts created by the
user, and the default HW context. The default HW context is used by GPU
clients that do not request setup of their own hardware context. The
default context's state is never restored to help prevent programming
errors. This would happen if a client ran and piggy-backed off another
clients GPU state. The default context only exists to give the GPU some
offset to load as the current to invoke a save of the context we
actually care about. In fact, the code could likely be constructed,
albeit in a more complicated fashion, to never use the default context,
though that limits the driver's ability to swap out, and/or destroy
other contexts.
All other contexts are created as a request by the GPU client. These
contexts store GPU state, and thus allow GPU clients to not re-emit
state (and potentially query certain state) at any time. The kernel
driver makes certain that the appropriate commands are inserted.
There are 4 entry points into the contexts, init, fini, open, close.
The names are self-explanatory except that init can be called during
reset, and also during pm thaw/resume. As we expect our context to be
preserved across these events, we do not reinitialize in this case.
As Adam Jackson pointed out, The cutoff of 1MB where a HW context is
considered too big is arbitrary. The reason for this is even though
context sizes are increasing with every generation, they have yet to
eclipse even 32k. If we somehow read back way more than that, it
probably means BIOS has done something strange, or we're running on a
platform that wasn't designed for this.
v2: rename load/unload to init/fini (daniel)
remove ILK support for get_size() (indirectly daniel)
add HAS_HW_CONTEXTS macro to clarify supported platforms (daniel)
added comments (Ben)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-05 04:42:42 +07:00
|
|
|
}
|
|
|
|
|
2013-12-07 05:11:01 +07:00
|
|
|
for (i = RCS + 1; i < I915_NUM_RINGS; i++) {
|
|
|
|
if (!(INTEL_INFO(dev)->ring_mask & (1<<i)))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
ring = &dev_priv->ring[i];
|
|
|
|
|
|
|
|
/* NB: RCS will hold a ref for all rings */
|
|
|
|
ring->default_context = dev_priv->ring[RCS].default_context;
|
|
|
|
}
|
|
|
|
|
drm/i915: preliminary context support
Very basic code for context setup/destruction in the driver.
Adds the file i915_gem_context.c This file implements HW context
support. On gen5+ a HW context consists of an opaque GPU object which is
referenced at times of context saves and restores. With RC6 enabled,
the context is also referenced as the GPU enters and exists from RC6
(GPU has it's own internal power context, except on gen5). Though
something like a context does exist for the media ring, the code only
supports contexts for the render ring.
In software, there is a distinction between contexts created by the
user, and the default HW context. The default HW context is used by GPU
clients that do not request setup of their own hardware context. The
default context's state is never restored to help prevent programming
errors. This would happen if a client ran and piggy-backed off another
clients GPU state. The default context only exists to give the GPU some
offset to load as the current to invoke a save of the context we
actually care about. In fact, the code could likely be constructed,
albeit in a more complicated fashion, to never use the default context,
though that limits the driver's ability to swap out, and/or destroy
other contexts.
All other contexts are created as a request by the GPU client. These
contexts store GPU state, and thus allow GPU clients to not re-emit
state (and potentially query certain state) at any time. The kernel
driver makes certain that the appropriate commands are inserted.
There are 4 entry points into the contexts, init, fini, open, close.
The names are self-explanatory except that init can be called during
reset, and also during pm thaw/resume. As we expect our context to be
preserved across these events, we do not reinitialize in this case.
As Adam Jackson pointed out, The cutoff of 1MB where a HW context is
considered too big is arbitrary. The reason for this is even though
context sizes are increasing with every generation, they have yet to
eclipse even 32k. If we somehow read back way more than that, it
probably means BIOS has done something strange, or we're running on a
platform that wasn't designed for this.
v2: rename load/unload to init/fini (daniel)
remove ILK support for get_size() (indirectly daniel)
add HAS_HW_CONTEXTS macro to clarify supported platforms (daniel)
added comments (Ben)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-05 04:42:42 +07:00
|
|
|
DRM_DEBUG_DRIVER("HW context support initialized\n");
|
2013-11-06 22:56:29 +07:00
|
|
|
return 0;
|
drm/i915: preliminary context support
Very basic code for context setup/destruction in the driver.
Adds the file i915_gem_context.c This file implements HW context
support. On gen5+ a HW context consists of an opaque GPU object which is
referenced at times of context saves and restores. With RC6 enabled,
the context is also referenced as the GPU enters and exists from RC6
(GPU has it's own internal power context, except on gen5). Though
something like a context does exist for the media ring, the code only
supports contexts for the render ring.
In software, there is a distinction between contexts created by the
user, and the default HW context. The default HW context is used by GPU
clients that do not request setup of their own hardware context. The
default context's state is never restored to help prevent programming
errors. This would happen if a client ran and piggy-backed off another
clients GPU state. The default context only exists to give the GPU some
offset to load as the current to invoke a save of the context we
actually care about. In fact, the code could likely be constructed,
albeit in a more complicated fashion, to never use the default context,
though that limits the driver's ability to swap out, and/or destroy
other contexts.
All other contexts are created as a request by the GPU client. These
contexts store GPU state, and thus allow GPU clients to not re-emit
state (and potentially query certain state) at any time. The kernel
driver makes certain that the appropriate commands are inserted.
There are 4 entry points into the contexts, init, fini, open, close.
The names are self-explanatory except that init can be called during
reset, and also during pm thaw/resume. As we expect our context to be
preserved across these events, we do not reinitialize in this case.
As Adam Jackson pointed out, The cutoff of 1MB where a HW context is
considered too big is arbitrary. The reason for this is even though
context sizes are increasing with every generation, they have yet to
eclipse even 32k. If we somehow read back way more than that, it
probably means BIOS has done something strange, or we're running on a
platform that wasn't designed for this.
v2: rename load/unload to init/fini (daniel)
remove ILK support for get_size() (indirectly daniel)
add HAS_HW_CONTEXTS macro to clarify supported platforms (daniel)
added comments (Ben)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-05 04:42:42 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
void i915_gem_context_fini(struct drm_device *dev)
|
|
|
|
{
|
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
2013-04-30 17:30:33 +07:00
|
|
|
struct i915_hw_context *dctx = dev_priv->ring[RCS].default_context;
|
2013-12-07 05:11:01 +07:00
|
|
|
int i;
|
drm/i915: preliminary context support
Very basic code for context setup/destruction in the driver.
Adds the file i915_gem_context.c This file implements HW context
support. On gen5+ a HW context consists of an opaque GPU object which is
referenced at times of context saves and restores. With RC6 enabled,
the context is also referenced as the GPU enters and exists from RC6
(GPU has it's own internal power context, except on gen5). Though
something like a context does exist for the media ring, the code only
supports contexts for the render ring.
In software, there is a distinction between contexts created by the
user, and the default HW context. The default HW context is used by GPU
clients that do not request setup of their own hardware context. The
default context's state is never restored to help prevent programming
errors. This would happen if a client ran and piggy-backed off another
clients GPU state. The default context only exists to give the GPU some
offset to load as the current to invoke a save of the context we
actually care about. In fact, the code could likely be constructed,
albeit in a more complicated fashion, to never use the default context,
though that limits the driver's ability to swap out, and/or destroy
other contexts.
All other contexts are created as a request by the GPU client. These
contexts store GPU state, and thus allow GPU clients to not re-emit
state (and potentially query certain state) at any time. The kernel
driver makes certain that the appropriate commands are inserted.
There are 4 entry points into the contexts, init, fini, open, close.
The names are self-explanatory except that init can be called during
reset, and also during pm thaw/resume. As we expect our context to be
preserved across these events, we do not reinitialize in this case.
As Adam Jackson pointed out, The cutoff of 1MB where a HW context is
considered too big is arbitrary. The reason for this is even though
context sizes are increasing with every generation, they have yet to
eclipse even 32k. If we somehow read back way more than that, it
probably means BIOS has done something strange, or we're running on a
platform that wasn't designed for this.
v2: rename load/unload to init/fini (daniel)
remove ILK support for get_size() (indirectly daniel)
add HAS_HW_CONTEXTS macro to clarify supported platforms (daniel)
added comments (Ben)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-05 04:42:42 +07:00
|
|
|
|
2013-11-06 22:56:29 +07:00
|
|
|
if (!HAS_HW_CONTEXTS(dev))
|
drm/i915: preliminary context support
Very basic code for context setup/destruction in the driver.
Adds the file i915_gem_context.c This file implements HW context
support. On gen5+ a HW context consists of an opaque GPU object which is
referenced at times of context saves and restores. With RC6 enabled,
the context is also referenced as the GPU enters and exists from RC6
(GPU has it's own internal power context, except on gen5). Though
something like a context does exist for the media ring, the code only
supports contexts for the render ring.
In software, there is a distinction between contexts created by the
user, and the default HW context. The default HW context is used by GPU
clients that do not request setup of their own hardware context. The
default context's state is never restored to help prevent programming
errors. This would happen if a client ran and piggy-backed off another
clients GPU state. The default context only exists to give the GPU some
offset to load as the current to invoke a save of the context we
actually care about. In fact, the code could likely be constructed,
albeit in a more complicated fashion, to never use the default context,
though that limits the driver's ability to swap out, and/or destroy
other contexts.
All other contexts are created as a request by the GPU client. These
contexts store GPU state, and thus allow GPU clients to not re-emit
state (and potentially query certain state) at any time. The kernel
driver makes certain that the appropriate commands are inserted.
There are 4 entry points into the contexts, init, fini, open, close.
The names are self-explanatory except that init can be called during
reset, and also during pm thaw/resume. As we expect our context to be
preserved across these events, we do not reinitialize in this case.
As Adam Jackson pointed out, The cutoff of 1MB where a HW context is
considered too big is arbitrary. The reason for this is even though
context sizes are increasing with every generation, they have yet to
eclipse even 32k. If we somehow read back way more than that, it
probably means BIOS has done something strange, or we're running on a
platform that wasn't designed for this.
v2: rename load/unload to init/fini (daniel)
remove ILK support for get_size() (indirectly daniel)
add HAS_HW_CONTEXTS macro to clarify supported platforms (daniel)
added comments (Ben)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-05 04:42:42 +07:00
|
|
|
return;
|
2012-06-05 04:42:43 +07:00
|
|
|
|
2012-06-20 02:55:32 +07:00
|
|
|
/* The only known way to stop the gpu from accessing the hw context is
|
|
|
|
* to reset it. Do this as the very last operation to avoid confusing
|
|
|
|
* other code, leading to spurious errors. */
|
|
|
|
intel_gpu_reset(dev);
|
|
|
|
|
2013-05-03 20:29:08 +07:00
|
|
|
/* When default context is created and switched to, base object refcount
|
|
|
|
* will be 2 (+1 from object creation and +1 from do_switch()).
|
|
|
|
* i915_gem_context_fini() will be called after gpu_idle() has switched
|
|
|
|
* to default context. So we need to unreference the base object once
|
|
|
|
* to offset the do_switch part, so that i915_gem_context_unreference()
|
|
|
|
* can then free the base object correctly. */
|
2013-10-15 00:01:37 +07:00
|
|
|
WARN_ON(!dev_priv->ring[RCS].last_context);
|
|
|
|
if (dev_priv->ring[RCS].last_context == dctx) {
|
|
|
|
/* Fake switch to NULL context */
|
|
|
|
WARN_ON(dctx->obj->active);
|
2013-12-07 05:10:55 +07:00
|
|
|
i915_gem_object_ggtt_unpin(dctx->obj);
|
2013-10-15 00:01:37 +07:00
|
|
|
i915_gem_context_unreference(dctx);
|
2013-12-07 05:11:01 +07:00
|
|
|
dev_priv->ring[RCS].last_context = NULL;
|
|
|
|
}
|
|
|
|
|
|
|
|
for (i = 0; i < I915_NUM_RINGS; i++) {
|
|
|
|
struct intel_ring_buffer *ring = &dev_priv->ring[i];
|
|
|
|
if (!(INTEL_INFO(dev)->ring_mask & (1<<i)))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
if (ring->last_context)
|
|
|
|
i915_gem_context_unreference(ring->last_context);
|
|
|
|
|
|
|
|
ring->default_context = NULL;
|
2013-12-07 05:11:02 +07:00
|
|
|
ring->last_context = NULL;
|
2013-10-15 00:01:37 +07:00
|
|
|
}
|
|
|
|
|
2013-12-07 05:10:55 +07:00
|
|
|
i915_gem_object_ggtt_unpin(dctx->obj);
|
2013-04-30 17:30:33 +07:00
|
|
|
i915_gem_context_unreference(dctx);
|
2013-12-07 05:11:18 +07:00
|
|
|
dev_priv->mm.aliasing_ppgtt = NULL;
|
drm/i915: preliminary context support
Very basic code for context setup/destruction in the driver.
Adds the file i915_gem_context.c This file implements HW context
support. On gen5+ a HW context consists of an opaque GPU object which is
referenced at times of context saves and restores. With RC6 enabled,
the context is also referenced as the GPU enters and exists from RC6
(GPU has it's own internal power context, except on gen5). Though
something like a context does exist for the media ring, the code only
supports contexts for the render ring.
In software, there is a distinction between contexts created by the
user, and the default HW context. The default HW context is used by GPU
clients that do not request setup of their own hardware context. The
default context's state is never restored to help prevent programming
errors. This would happen if a client ran and piggy-backed off another
clients GPU state. The default context only exists to give the GPU some
offset to load as the current to invoke a save of the context we
actually care about. In fact, the code could likely be constructed,
albeit in a more complicated fashion, to never use the default context,
though that limits the driver's ability to swap out, and/or destroy
other contexts.
All other contexts are created as a request by the GPU client. These
contexts store GPU state, and thus allow GPU clients to not re-emit
state (and potentially query certain state) at any time. The kernel
driver makes certain that the appropriate commands are inserted.
There are 4 entry points into the contexts, init, fini, open, close.
The names are self-explanatory except that init can be called during
reset, and also during pm thaw/resume. As we expect our context to be
preserved across these events, we do not reinitialize in this case.
As Adam Jackson pointed out, The cutoff of 1MB where a HW context is
considered too big is arbitrary. The reason for this is even though
context sizes are increasing with every generation, they have yet to
eclipse even 32k. If we somehow read back way more than that, it
probably means BIOS has done something strange, or we're running on a
platform that wasn't designed for this.
v2: rename load/unload to init/fini (daniel)
remove ILK support for get_size() (indirectly daniel)
add HAS_HW_CONTEXTS macro to clarify supported platforms (daniel)
added comments (Ben)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-05 04:42:42 +07:00
|
|
|
}
|
|
|
|
|
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-07 05:11:04 +07:00
|
|
|
int i915_gem_context_enable(struct drm_i915_private *dev_priv)
|
|
|
|
{
|
|
|
|
struct intel_ring_buffer *ring;
|
|
|
|
int ret, i;
|
|
|
|
|
|
|
|
if (!HAS_HW_CONTEXTS(dev_priv->dev))
|
|
|
|
return 0;
|
|
|
|
|
2013-12-07 05:11:18 +07:00
|
|
|
/* This is the only place the aliasing PPGTT gets enabled, which means
|
|
|
|
* it has to happen before we bail on reset */
|
|
|
|
if (dev_priv->mm.aliasing_ppgtt) {
|
|
|
|
struct i915_hw_ppgtt *ppgtt = dev_priv->mm.aliasing_ppgtt;
|
|
|
|
ppgtt->enable(ppgtt);
|
|
|
|
}
|
|
|
|
|
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-07 05:11:04 +07:00
|
|
|
/* FIXME: We should make this work, even in reset */
|
|
|
|
if (i915_reset_in_progress(&dev_priv->gpu_error))
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
BUG_ON(!dev_priv->ring[RCS].default_context);
|
2013-12-07 05:11:18 +07: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-07 05:11:04 +07:00
|
|
|
for_each_ring(ring, dev_priv, i) {
|
|
|
|
ret = do_switch(ring, ring->default_context);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2012-06-05 04:42:43 +07:00
|
|
|
static int context_idr_cleanup(int id, void *p, void *data)
|
|
|
|
{
|
2012-06-20 01:27:39 +07:00
|
|
|
struct i915_hw_context *ctx = p;
|
2012-06-05 04:42:43 +07:00
|
|
|
|
2013-12-07 05:11:19 +07:00
|
|
|
/* Ignore the default context because close will handle it */
|
2014-01-30 21:05:48 +07:00
|
|
|
if (i915_gem_context_is_default(ctx))
|
2013-12-07 05:11:19 +07:00
|
|
|
return 0;
|
2012-06-05 04:42:43 +07:00
|
|
|
|
2013-04-30 17:30:33 +07:00
|
|
|
i915_gem_context_unreference(ctx);
|
2012-06-05 04:42:43 +07:00
|
|
|
return 0;
|
drm/i915: preliminary context support
Very basic code for context setup/destruction in the driver.
Adds the file i915_gem_context.c This file implements HW context
support. On gen5+ a HW context consists of an opaque GPU object which is
referenced at times of context saves and restores. With RC6 enabled,
the context is also referenced as the GPU enters and exists from RC6
(GPU has it's own internal power context, except on gen5). Though
something like a context does exist for the media ring, the code only
supports contexts for the render ring.
In software, there is a distinction between contexts created by the
user, and the default HW context. The default HW context is used by GPU
clients that do not request setup of their own hardware context. The
default context's state is never restored to help prevent programming
errors. This would happen if a client ran and piggy-backed off another
clients GPU state. The default context only exists to give the GPU some
offset to load as the current to invoke a save of the context we
actually care about. In fact, the code could likely be constructed,
albeit in a more complicated fashion, to never use the default context,
though that limits the driver's ability to swap out, and/or destroy
other contexts.
All other contexts are created as a request by the GPU client. These
contexts store GPU state, and thus allow GPU clients to not re-emit
state (and potentially query certain state) at any time. The kernel
driver makes certain that the appropriate commands are inserted.
There are 4 entry points into the contexts, init, fini, open, close.
The names are self-explanatory except that init can be called during
reset, and also during pm thaw/resume. As we expect our context to be
preserved across these events, we do not reinitialize in this case.
As Adam Jackson pointed out, The cutoff of 1MB where a HW context is
considered too big is arbitrary. The reason for this is even though
context sizes are increasing with every generation, they have yet to
eclipse even 32k. If we somehow read back way more than that, it
probably means BIOS has done something strange, or we're running on a
platform that wasn't designed for this.
v2: rename load/unload to init/fini (daniel)
remove ILK support for get_size() (indirectly daniel)
add HAS_HW_CONTEXTS macro to clarify supported platforms (daniel)
added comments (Ben)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-05 04:42:42 +07:00
|
|
|
}
|
|
|
|
|
2013-12-07 05:10:58 +07:00
|
|
|
int i915_gem_context_open(struct drm_device *dev, struct drm_file *file)
|
|
|
|
{
|
|
|
|
struct drm_i915_file_private *file_priv = file->driver_priv;
|
2013-12-07 05:11:20 +07:00
|
|
|
struct drm_i915_private *dev_priv = dev->dev_private;
|
2013-12-07 05:10:58 +07:00
|
|
|
|
2013-12-07 05:11:20 +07:00
|
|
|
if (!HAS_HW_CONTEXTS(dev)) {
|
|
|
|
/* Cheat for hang stats */
|
|
|
|
file_priv->private_default_ctx =
|
|
|
|
kzalloc(sizeof(struct i915_hw_context), GFP_KERNEL);
|
2014-01-31 22:00:28 +07:00
|
|
|
|
|
|
|
if (file_priv->private_default_ctx == NULL)
|
|
|
|
return -ENOMEM;
|
|
|
|
|
2013-12-07 05:11:20 +07:00
|
|
|
file_priv->private_default_ctx->vm = &dev_priv->gtt.base;
|
2013-12-07 05:10:58 +07:00
|
|
|
return 0;
|
2013-12-07 05:11:20 +07:00
|
|
|
}
|
2013-12-07 05:10:58 +07:00
|
|
|
|
|
|
|
idr_init(&file_priv->context_idr);
|
|
|
|
|
2013-12-07 05:11:19 +07:00
|
|
|
mutex_lock(&dev->struct_mutex);
|
|
|
|
file_priv->private_default_ctx =
|
2013-12-07 05:11:26 +07:00
|
|
|
i915_gem_create_context(dev, file_priv, USES_FULL_PPGTT(dev));
|
2013-12-07 05:11:19 +07:00
|
|
|
mutex_unlock(&dev->struct_mutex);
|
|
|
|
|
|
|
|
if (IS_ERR(file_priv->private_default_ctx)) {
|
|
|
|
idr_destroy(&file_priv->context_idr);
|
|
|
|
return PTR_ERR(file_priv->private_default_ctx);
|
|
|
|
}
|
|
|
|
|
2013-12-07 05:10:58 +07:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
drm/i915: preliminary context support
Very basic code for context setup/destruction in the driver.
Adds the file i915_gem_context.c This file implements HW context
support. On gen5+ a HW context consists of an opaque GPU object which is
referenced at times of context saves and restores. With RC6 enabled,
the context is also referenced as the GPU enters and exists from RC6
(GPU has it's own internal power context, except on gen5). Though
something like a context does exist for the media ring, the code only
supports contexts for the render ring.
In software, there is a distinction between contexts created by the
user, and the default HW context. The default HW context is used by GPU
clients that do not request setup of their own hardware context. The
default context's state is never restored to help prevent programming
errors. This would happen if a client ran and piggy-backed off another
clients GPU state. The default context only exists to give the GPU some
offset to load as the current to invoke a save of the context we
actually care about. In fact, the code could likely be constructed,
albeit in a more complicated fashion, to never use the default context,
though that limits the driver's ability to swap out, and/or destroy
other contexts.
All other contexts are created as a request by the GPU client. These
contexts store GPU state, and thus allow GPU clients to not re-emit
state (and potentially query certain state) at any time. The kernel
driver makes certain that the appropriate commands are inserted.
There are 4 entry points into the contexts, init, fini, open, close.
The names are self-explanatory except that init can be called during
reset, and also during pm thaw/resume. As we expect our context to be
preserved across these events, we do not reinitialize in this case.
As Adam Jackson pointed out, The cutoff of 1MB where a HW context is
considered too big is arbitrary. The reason for this is even though
context sizes are increasing with every generation, they have yet to
eclipse even 32k. If we somehow read back way more than that, it
probably means BIOS has done something strange, or we're running on a
platform that wasn't designed for this.
v2: rename load/unload to init/fini (daniel)
remove ILK support for get_size() (indirectly daniel)
add HAS_HW_CONTEXTS macro to clarify supported platforms (daniel)
added comments (Ben)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-05 04:42:42 +07:00
|
|
|
void i915_gem_context_close(struct drm_device *dev, struct drm_file *file)
|
|
|
|
{
|
2012-06-05 04:42:43 +07:00
|
|
|
struct drm_i915_file_private *file_priv = file->driver_priv;
|
drm/i915: preliminary context support
Very basic code for context setup/destruction in the driver.
Adds the file i915_gem_context.c This file implements HW context
support. On gen5+ a HW context consists of an opaque GPU object which is
referenced at times of context saves and restores. With RC6 enabled,
the context is also referenced as the GPU enters and exists from RC6
(GPU has it's own internal power context, except on gen5). Though
something like a context does exist for the media ring, the code only
supports contexts for the render ring.
In software, there is a distinction between contexts created by the
user, and the default HW context. The default HW context is used by GPU
clients that do not request setup of their own hardware context. The
default context's state is never restored to help prevent programming
errors. This would happen if a client ran and piggy-backed off another
clients GPU state. The default context only exists to give the GPU some
offset to load as the current to invoke a save of the context we
actually care about. In fact, the code could likely be constructed,
albeit in a more complicated fashion, to never use the default context,
though that limits the driver's ability to swap out, and/or destroy
other contexts.
All other contexts are created as a request by the GPU client. These
contexts store GPU state, and thus allow GPU clients to not re-emit
state (and potentially query certain state) at any time. The kernel
driver makes certain that the appropriate commands are inserted.
There are 4 entry points into the contexts, init, fini, open, close.
The names are self-explanatory except that init can be called during
reset, and also during pm thaw/resume. As we expect our context to be
preserved across these events, we do not reinitialize in this case.
As Adam Jackson pointed out, The cutoff of 1MB where a HW context is
considered too big is arbitrary. The reason for this is even though
context sizes are increasing with every generation, they have yet to
eclipse even 32k. If we somehow read back way more than that, it
probably means BIOS has done something strange, or we're running on a
platform that wasn't designed for this.
v2: rename load/unload to init/fini (daniel)
remove ILK support for get_size() (indirectly daniel)
add HAS_HW_CONTEXTS macro to clarify supported platforms (daniel)
added comments (Ben)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-05 04:42:42 +07:00
|
|
|
|
2013-12-07 05:11:20 +07:00
|
|
|
if (!HAS_HW_CONTEXTS(dev)) {
|
|
|
|
kfree(file_priv->private_default_ctx);
|
2013-12-07 05:10:58 +07:00
|
|
|
return;
|
2013-12-07 05:11:20 +07:00
|
|
|
}
|
2013-12-07 05:10:58 +07:00
|
|
|
|
2012-06-20 01:27:39 +07:00
|
|
|
idr_for_each(&file_priv->context_idr, context_idr_cleanup, NULL);
|
2013-12-07 05:11:19 +07:00
|
|
|
i915_gem_context_unreference(file_priv->private_default_ctx);
|
2012-06-05 04:42:43 +07:00
|
|
|
idr_destroy(&file_priv->context_idr);
|
|
|
|
}
|
|
|
|
|
drm/i915: Get context early in execbuf
We need to have the address space when reserving space for the objects.
Since the address space and context are tied together, and reserve
occurs before context switch (for good reason), we must lookup our
context earlier in the process.
This leaves some room for optimizations where we no longer need to use
ctx_id in certain places. This will be addressed in a subsequent patch.
Important tricky bit:
Because slow relocations during execbuffer drop struct_mutex
Perhaps it would be best to acquire the reference when we get the
context, but I'll save that for another day (note I have written the
patch before, and I found the changes required to be uglier than this).
Note that since we currently access everything via context id, and not
the data structure this is fine, though not desirable. The next change
attempts to get the context only once via the context ID idr lookup, and
as such, the following can happen:
CTX-A is created, refcount = 1
CTX-A execbuf, mutex dropped
close IOCTL called on CTX-A, refcount = 0
CTX-A resumes in execbuf.
v2: Rebased on top of
commit b6359918b885da7c7b58c050674278dbd06020ab
Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Date: Wed Oct 30 15:44:16 2013 +0200
drm/i915: add i915_get_reset_stats_ioctl
v3: Rebased on top of
commit 25b3dfc87bff80317d67ddd2cd4cfb91e6fe7d79
Author: Mika Westerberg <mika.westerberg@linux.intel.com>
Date: Tue Nov 12 11:57:30 2013 +0200
Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Date: Tue Nov 26 16:14:33 2013 +0200
drm/i915: check context reset stats before relocations
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-07 05:11:21 +07:00
|
|
|
struct i915_hw_context *
|
2012-06-05 04:42:43 +07:00
|
|
|
i915_gem_context_get(struct drm_i915_file_private *file_priv, u32 id)
|
|
|
|
{
|
2014-01-03 12:50:27 +07:00
|
|
|
struct i915_hw_context *ctx;
|
|
|
|
|
drm/i915: Get context early in execbuf
We need to have the address space when reserving space for the objects.
Since the address space and context are tied together, and reserve
occurs before context switch (for good reason), we must lookup our
context earlier in the process.
This leaves some room for optimizations where we no longer need to use
ctx_id in certain places. This will be addressed in a subsequent patch.
Important tricky bit:
Because slow relocations during execbuffer drop struct_mutex
Perhaps it would be best to acquire the reference when we get the
context, but I'll save that for another day (note I have written the
patch before, and I found the changes required to be uglier than this).
Note that since we currently access everything via context id, and not
the data structure this is fine, though not desirable. The next change
attempts to get the context only once via the context ID idr lookup, and
as such, the following can happen:
CTX-A is created, refcount = 1
CTX-A execbuf, mutex dropped
close IOCTL called on CTX-A, refcount = 0
CTX-A resumes in execbuf.
v2: Rebased on top of
commit b6359918b885da7c7b58c050674278dbd06020ab
Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Date: Wed Oct 30 15:44:16 2013 +0200
drm/i915: add i915_get_reset_stats_ioctl
v3: Rebased on top of
commit 25b3dfc87bff80317d67ddd2cd4cfb91e6fe7d79
Author: Mika Westerberg <mika.westerberg@linux.intel.com>
Date: Tue Nov 12 11:57:30 2013 +0200
Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Date: Tue Nov 26 16:14:33 2013 +0200
drm/i915: check context reset stats before relocations
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-07 05:11:21 +07:00
|
|
|
if (!HAS_HW_CONTEXTS(file_priv->dev_priv->dev))
|
|
|
|
return file_priv->private_default_ctx;
|
|
|
|
|
2014-01-03 12:50:27 +07:00
|
|
|
ctx = (struct i915_hw_context *)idr_find(&file_priv->context_idr, id);
|
|
|
|
if (!ctx)
|
|
|
|
return ERR_PTR(-ENOENT);
|
|
|
|
|
|
|
|
return ctx;
|
drm/i915: preliminary context support
Very basic code for context setup/destruction in the driver.
Adds the file i915_gem_context.c This file implements HW context
support. On gen5+ a HW context consists of an opaque GPU object which is
referenced at times of context saves and restores. With RC6 enabled,
the context is also referenced as the GPU enters and exists from RC6
(GPU has it's own internal power context, except on gen5). Though
something like a context does exist for the media ring, the code only
supports contexts for the render ring.
In software, there is a distinction between contexts created by the
user, and the default HW context. The default HW context is used by GPU
clients that do not request setup of their own hardware context. The
default context's state is never restored to help prevent programming
errors. This would happen if a client ran and piggy-backed off another
clients GPU state. The default context only exists to give the GPU some
offset to load as the current to invoke a save of the context we
actually care about. In fact, the code could likely be constructed,
albeit in a more complicated fashion, to never use the default context,
though that limits the driver's ability to swap out, and/or destroy
other contexts.
All other contexts are created as a request by the GPU client. These
contexts store GPU state, and thus allow GPU clients to not re-emit
state (and potentially query certain state) at any time. The kernel
driver makes certain that the appropriate commands are inserted.
There are 4 entry points into the contexts, init, fini, open, close.
The names are self-explanatory except that init can be called during
reset, and also during pm thaw/resume. As we expect our context to be
preserved across these events, we do not reinitialize in this case.
As Adam Jackson pointed out, The cutoff of 1MB where a HW context is
considered too big is arbitrary. The reason for this is even though
context sizes are increasing with every generation, they have yet to
eclipse even 32k. If we somehow read back way more than that, it
probably means BIOS has done something strange, or we're running on a
platform that wasn't designed for this.
v2: rename load/unload to init/fini (daniel)
remove ILK support for get_size() (indirectly daniel)
add HAS_HW_CONTEXTS macro to clarify supported platforms (daniel)
added comments (Ben)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
2012-06-05 04:42:42 +07:00
|
|
|
}
|
2012-06-05 04:42:46 +07:00
|
|
|
|
|
|
|
static inline int
|
|
|
|
mi_set_context(struct intel_ring_buffer *ring,
|
|
|
|
struct i915_hw_context *new_context,
|
|
|
|
u32 hw_flags)
|
|
|
|
{
|
|
|
|
int ret;
|
|
|
|
|
2012-06-05 04:42:50 +07:00
|
|
|
/* w/a: If Flush TLB Invalidation Mode is enabled, driver must do a TLB
|
|
|
|
* invalidation prior to MI_SET_CONTEXT. On GEN6 we don't set the value
|
|
|
|
* explicitly, so we rely on the value at ring init, stored in
|
|
|
|
* itlb_before_ctx_switch.
|
|
|
|
*/
|
|
|
|
if (IS_GEN6(ring->dev) && ring->itlb_before_ctx_switch) {
|
2012-10-01 20:27:04 +07:00
|
|
|
ret = ring->flush(ring, I915_GEM_GPU_DOMAINS, 0);
|
2012-06-05 04:42:50 +07:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2012-06-05 04:42:48 +07:00
|
|
|
ret = intel_ring_begin(ring, 6);
|
2012-06-05 04:42:46 +07:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2013-05-04 00:48:11 +07:00
|
|
|
/* WaProgramMiArbOnOffAroundMiSetContext:ivb,vlv,hsw */
|
2012-06-05 04:42:48 +07:00
|
|
|
if (IS_GEN7(ring->dev))
|
|
|
|
intel_ring_emit(ring, MI_ARB_ON_OFF | MI_ARB_DISABLE);
|
|
|
|
else
|
|
|
|
intel_ring_emit(ring, MI_NOOP);
|
|
|
|
|
2012-06-05 04:42:46 +07:00
|
|
|
intel_ring_emit(ring, MI_NOOP);
|
|
|
|
intel_ring_emit(ring, MI_SET_CONTEXT);
|
2013-07-06 04:41:04 +07:00
|
|
|
intel_ring_emit(ring, i915_gem_obj_ggtt_offset(new_context->obj) |
|
2012-06-05 04:42:46 +07:00
|
|
|
MI_MM_SPACE_GTT |
|
|
|
|
MI_SAVE_EXT_STATE_EN |
|
|
|
|
MI_RESTORE_EXT_STATE_EN |
|
|
|
|
hw_flags);
|
2014-01-23 02:32:43 +07:00
|
|
|
/*
|
|
|
|
* w/a: MI_SET_CONTEXT must always be followed by MI_NOOP
|
|
|
|
* WaMiSetContext_Hang:snb,ivb,vlv
|
|
|
|
*/
|
2012-06-05 04:42:46 +07:00
|
|
|
intel_ring_emit(ring, MI_NOOP);
|
|
|
|
|
2012-06-05 04:42:48 +07:00
|
|
|
if (IS_GEN7(ring->dev))
|
|
|
|
intel_ring_emit(ring, MI_ARB_ON_OFF | MI_ARB_ENABLE);
|
|
|
|
else
|
|
|
|
intel_ring_emit(ring, MI_NOOP);
|
|
|
|
|
2012-06-05 04:42:46 +07:00
|
|
|
intel_ring_advance(ring);
|
|
|
|
|
|
|
|
return ret;
|
|
|
|
}
|
|
|
|
|
2013-12-07 05:11:01 +07:00
|
|
|
static int do_switch(struct intel_ring_buffer *ring,
|
|
|
|
struct i915_hw_context *to)
|
2012-06-05 04:42:46 +07:00
|
|
|
{
|
drm/i915: Create bind/unbind abstraction for VMAs
To sum up what goes on here, we abstract the vma binding, similarly to
the previous object binding. This helps for distinguishing legacy
binding, versus modern binding. To keep the code churn as minimal as
possible, I am leaving in insert_entries(). It serves as the per
platform pte writing basically. bind_vma and insert_entries do share a
lot of similarities, and I did have designs to combine the two, but as
mentioned already... too much churn in an already massive patchset.
What follows are the 3 commits which existed discretely in the original
submissions. Upon rebasing on Broadwell support, it became clear that
separation was not good, and only made for more error prone code. Below
are the 3 commit messages with all their history.
drm/i915: Add bind/unbind object functions to VMA
drm/i915: Use the new vm [un]bind functions
drm/i915: reduce vm->insert_entries() usage
drm/i915: Add bind/unbind object functions to VMA
As we plumb the code with more VM information, it has become more
obvious that the easiest way to deal with bind and unbind is to simply
put the function pointers in the vm, and let those choose the correct
way to handle the page table updates. This change allows many places in
the code to simply be vm->bind, and not have to worry about
distinguishing PPGTT vs GGTT.
Notice that this patch has no impact on functionality. I've decided to
save the actual change until the next patch because I think it's easier
to review that way. I'm happy to squash the two, or let Daniel do it on
merge.
v2:
Make ggtt handle the quirky aliasing ppgtt
Add flags to bind object to support above
Don't ever call bind/unbind directly for PPGTT until we have real, full
PPGTT (use NULLs to assert this)
Make sure we rebind the ggtt if there already is a ggtt binding. This
happens on set cache levels.
Use VMA for bind/unbind (Daniel, Ben)
v3: Reorganize ggtt_vma_bind to be more concise and easier to read
(Ville). Change logic in unbind to only unbind ggtt when there is a
global mapping, and to remove a redundant check if the aliasing ppgtt
exists.
v4: Make the bind function a bit smarter about the cache levels to avoid
unnecessary multiple remaps. "I accept it is a wart, I think unifying
the pin_vma / bind_vma could be unified later" (Chris)
Removed the git notes, and put version info here. (Daniel)
v5: Update the comment to not suck (Chris)
v6:
Move bind/unbind to the VMA. It makes more sense in the VMA structure
(always has, but I was previously lazy). With this change, it will allow
us to keep a distinct insert_entries.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
drm/i915: Use the new vm [un]bind functions
Building on the last patch which created the new function pointers in
the VM for bind/unbind, here we actually put those new function pointers
to use.
Split out as a separate patch to aid in review. I'm fine with squashing
into the previous patch if people request it.
v2: Updated to address the smart ggtt which can do aliasing as needed
Make sure we bind to global gtt when mappable and fenceable. I thought
we could get away without this initialy, but we cannot.
v3: Make the global GTT binding explicitly use the ggtt VM for
bind_vma(). While at it, use the new ggtt_vma helper (Chris)
At this point the original mailing list thread diverges. ie.
v4^:
use target_obj instead of obj for gen6 relocate_entry
vma->bind_vma() can be called safely during pin. So simply do that
instead of the complicated conditionals.
Don't restore PPGTT bound objects on resume path
Bug fix in resume path for globally bound Bos
Properly handle secure dispatch
Rebased on vma bind/unbind conversion
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
drm/i915: reduce vm->insert_entries() usage
FKA: drm/i915: eliminate vm->insert_entries()
With bind/unbind function pointers in place, we no longer need
insert_entries. We could, and want, to remove clear_range, however it's
not totally easy at this point. Since it's used in a couple of place
still that don't only deal in objects: setup, ppgtt init, and restore
gtt mappings.
v2: Don't actually remove insert_entries, just limit its usage. It will
be useful when we introduce gen8. It will always be called from the vma
bind/unbind.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v1)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-07 05:10:56 +07:00
|
|
|
struct drm_i915_private *dev_priv = ring->dev->dev_private;
|
2013-05-02 20:48:07 +07:00
|
|
|
struct i915_hw_context *from = ring->last_context;
|
2013-12-07 05:11:26 +07:00
|
|
|
struct i915_hw_ppgtt *ppgtt = ctx_to_ppgtt(to);
|
2012-06-05 04:42:46 +07:00
|
|
|
u32 hw_flags = 0;
|
drm/i915: Do remaps for all contexts
On both Ivybridge and Haswell, row remapping information is saved and
restored with context. This means, we never actually properly supported
the l3 remapping because our sysfs interface is asynchronous (and not
tied to any context), and the known faulty HW would be reused by the
next context to run.
Not that due to the asynchronous nature of the sysfs entry, there is no
point modifying the registers for the existing context. Instead we set a
flag for all contexts to load the correct remapping information on the
next run. Interested clients can use debugfs to determine whether or not
the row has been remapped.
One could propose at this point that we just do the remapping in the
kernel. I guess since we have to maintain the sysfs interface anyway,
I'm not sure how useful it is, and I do like keeping the policy in
userspace; (it wasn't my original decision to make the
interface the way it is, so I'm not attached).
v2: Force a context switch when we have a remap on the next switch.
(Ville)
Don't let userspace use the interface with disabled contexts.
v3: Don't force a context switch, just let it nop
Improper context slice remap initialization, 1<<1 instead of 1<<i, but I
rewrote it to avoid a second round of confusion.
Error print moved to error path (All Ville)
Added a comment on why the slice remap initialization happens.
CC: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-09-19 09:03:18 +07:00
|
|
|
int ret, i;
|
2012-06-05 04:42:46 +07:00
|
|
|
|
2013-12-07 05:11:01 +07:00
|
|
|
if (from != NULL && ring == &dev_priv->ring[RCS]) {
|
|
|
|
BUG_ON(from->obj == NULL);
|
|
|
|
BUG_ON(!i915_gem_obj_is_pinned(from->obj));
|
|
|
|
}
|
2012-06-05 04:42:46 +07:00
|
|
|
|
2013-12-07 05:11:02 +07:00
|
|
|
if (from == to && from->last_ring == ring && !to->remap_slice)
|
2012-07-15 18:34:24 +07:00
|
|
|
return 0;
|
|
|
|
|
2013-12-07 05:11:26 +07:00
|
|
|
/* Trying to pin first makes error handling easier. */
|
|
|
|
if (ring == &dev_priv->ring[RCS]) {
|
|
|
|
ret = i915_gem_obj_ggtt_pin(to->obj,
|
2014-02-14 20:01:11 +07:00
|
|
|
get_context_alignment(ring->dev), 0);
|
2013-12-07 05:11:26 +07:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
2013-12-07 05:11:01 +07:00
|
|
|
}
|
|
|
|
|
2013-12-05 21:42:34 +07:00
|
|
|
/*
|
|
|
|
* Pin can switch back to the default context if we end up calling into
|
|
|
|
* evict_everything - as a last ditch gtt defrag effort that also
|
|
|
|
* switches to the default context. Hence we need to reload from here.
|
|
|
|
*/
|
|
|
|
from = ring->last_context;
|
|
|
|
|
2013-12-07 05:11:26 +07:00
|
|
|
if (USES_FULL_PPGTT(ring->dev)) {
|
|
|
|
ret = ppgtt->switch_mm(ppgtt, ring, false);
|
|
|
|
if (ret)
|
|
|
|
goto unpin_out;
|
|
|
|
}
|
|
|
|
|
|
|
|
if (ring != &dev_priv->ring[RCS]) {
|
|
|
|
if (from)
|
|
|
|
i915_gem_context_unreference(from);
|
|
|
|
goto done;
|
|
|
|
}
|
|
|
|
|
2013-12-05 21:42:34 +07:00
|
|
|
/*
|
|
|
|
* Clear this page out of any CPU caches for coherent swap-in/out. Note
|
2012-07-15 18:34:22 +07:00
|
|
|
* that thanks to write = false in this call and us not setting any gpu
|
|
|
|
* write domains when putting a context object onto the active list
|
|
|
|
* (when switching away from it), this won't block.
|
2013-12-05 21:42:34 +07:00
|
|
|
*
|
|
|
|
* XXX: We need a real interface to do this instead of trickery.
|
|
|
|
*/
|
2012-07-15 18:34:22 +07:00
|
|
|
ret = i915_gem_object_set_to_gtt_domain(to->obj, false);
|
2013-12-07 05:11:26 +07:00
|
|
|
if (ret)
|
|
|
|
goto unpin_out;
|
2012-07-15 18:34:22 +07:00
|
|
|
|
drm/i915: Create bind/unbind abstraction for VMAs
To sum up what goes on here, we abstract the vma binding, similarly to
the previous object binding. This helps for distinguishing legacy
binding, versus modern binding. To keep the code churn as minimal as
possible, I am leaving in insert_entries(). It serves as the per
platform pte writing basically. bind_vma and insert_entries do share a
lot of similarities, and I did have designs to combine the two, but as
mentioned already... too much churn in an already massive patchset.
What follows are the 3 commits which existed discretely in the original
submissions. Upon rebasing on Broadwell support, it became clear that
separation was not good, and only made for more error prone code. Below
are the 3 commit messages with all their history.
drm/i915: Add bind/unbind object functions to VMA
drm/i915: Use the new vm [un]bind functions
drm/i915: reduce vm->insert_entries() usage
drm/i915: Add bind/unbind object functions to VMA
As we plumb the code with more VM information, it has become more
obvious that the easiest way to deal with bind and unbind is to simply
put the function pointers in the vm, and let those choose the correct
way to handle the page table updates. This change allows many places in
the code to simply be vm->bind, and not have to worry about
distinguishing PPGTT vs GGTT.
Notice that this patch has no impact on functionality. I've decided to
save the actual change until the next patch because I think it's easier
to review that way. I'm happy to squash the two, or let Daniel do it on
merge.
v2:
Make ggtt handle the quirky aliasing ppgtt
Add flags to bind object to support above
Don't ever call bind/unbind directly for PPGTT until we have real, full
PPGTT (use NULLs to assert this)
Make sure we rebind the ggtt if there already is a ggtt binding. This
happens on set cache levels.
Use VMA for bind/unbind (Daniel, Ben)
v3: Reorganize ggtt_vma_bind to be more concise and easier to read
(Ville). Change logic in unbind to only unbind ggtt when there is a
global mapping, and to remove a redundant check if the aliasing ppgtt
exists.
v4: Make the bind function a bit smarter about the cache levels to avoid
unnecessary multiple remaps. "I accept it is a wart, I think unifying
the pin_vma / bind_vma could be unified later" (Chris)
Removed the git notes, and put version info here. (Daniel)
v5: Update the comment to not suck (Chris)
v6:
Move bind/unbind to the VMA. It makes more sense in the VMA structure
(always has, but I was previously lazy). With this change, it will allow
us to keep a distinct insert_entries.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
drm/i915: Use the new vm [un]bind functions
Building on the last patch which created the new function pointers in
the VM for bind/unbind, here we actually put those new function pointers
to use.
Split out as a separate patch to aid in review. I'm fine with squashing
into the previous patch if people request it.
v2: Updated to address the smart ggtt which can do aliasing as needed
Make sure we bind to global gtt when mappable and fenceable. I thought
we could get away without this initialy, but we cannot.
v3: Make the global GTT binding explicitly use the ggtt VM for
bind_vma(). While at it, use the new ggtt_vma helper (Chris)
At this point the original mailing list thread diverges. ie.
v4^:
use target_obj instead of obj for gen6 relocate_entry
vma->bind_vma() can be called safely during pin. So simply do that
instead of the complicated conditionals.
Don't restore PPGTT bound objects on resume path
Bug fix in resume path for globally bound Bos
Properly handle secure dispatch
Rebased on vma bind/unbind conversion
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
drm/i915: reduce vm->insert_entries() usage
FKA: drm/i915: eliminate vm->insert_entries()
With bind/unbind function pointers in place, we no longer need
insert_entries. We could, and want, to remove clear_range, however it's
not totally easy at this point. Since it's used in a couple of place
still that don't only deal in objects: setup, ppgtt init, and restore
gtt mappings.
v2: Don't actually remove insert_entries, just limit its usage. It will
be useful when we introduce gen8. It will always be called from the vma
bind/unbind.
Reviewed-by: Chris Wilson <chris@chris-wilson.co.uk> (v1)
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-07 05:10:56 +07:00
|
|
|
if (!to->obj->has_global_gtt_mapping) {
|
|
|
|
struct i915_vma *vma = i915_gem_obj_to_vma(to->obj,
|
|
|
|
&dev_priv->gtt.base);
|
|
|
|
vma->bind_vma(vma, to->obj->cache_level, GLOBAL_BIND);
|
|
|
|
}
|
2012-06-14 05:08:32 +07:00
|
|
|
|
2014-01-30 21:05:48 +07:00
|
|
|
if (!to->is_initialized || i915_gem_context_is_default(to))
|
2012-06-05 04:42:46 +07:00
|
|
|
hw_flags |= MI_RESTORE_INHIBIT;
|
|
|
|
|
|
|
|
ret = mi_set_context(ring, to, hw_flags);
|
2013-12-07 05:11:26 +07:00
|
|
|
if (ret)
|
|
|
|
goto unpin_out;
|
2012-06-05 04:42:46 +07:00
|
|
|
|
drm/i915: Do remaps for all contexts
On both Ivybridge and Haswell, row remapping information is saved and
restored with context. This means, we never actually properly supported
the l3 remapping because our sysfs interface is asynchronous (and not
tied to any context), and the known faulty HW would be reused by the
next context to run.
Not that due to the asynchronous nature of the sysfs entry, there is no
point modifying the registers for the existing context. Instead we set a
flag for all contexts to load the correct remapping information on the
next run. Interested clients can use debugfs to determine whether or not
the row has been remapped.
One could propose at this point that we just do the remapping in the
kernel. I guess since we have to maintain the sysfs interface anyway,
I'm not sure how useful it is, and I do like keeping the policy in
userspace; (it wasn't my original decision to make the
interface the way it is, so I'm not attached).
v2: Force a context switch when we have a remap on the next switch.
(Ville)
Don't let userspace use the interface with disabled contexts.
v3: Don't force a context switch, just let it nop
Improper context slice remap initialization, 1<<1 instead of 1<<i, but I
rewrote it to avoid a second round of confusion.
Error print moved to error path (All Ville)
Added a comment on why the slice remap initialization happens.
CC: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-09-19 09:03:18 +07:00
|
|
|
for (i = 0; i < MAX_L3_SLICES; i++) {
|
|
|
|
if (!(to->remap_slice & (1<<i)))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
ret = i915_gem_l3_remap(ring, i);
|
|
|
|
/* If it failed, try again next round */
|
|
|
|
if (ret)
|
|
|
|
DRM_DEBUG_DRIVER("L3 remapping failed\n");
|
|
|
|
else
|
|
|
|
to->remap_slice &= ~(1<<i);
|
|
|
|
}
|
|
|
|
|
2012-06-05 04:42:46 +07:00
|
|
|
/* The backing object for the context is done after switching to the
|
|
|
|
* *next* context. Therefore we cannot retire the previous context until
|
|
|
|
* the next context has already started running. In fact, the below code
|
|
|
|
* is a bit suboptimal because the retiring can occur simply after the
|
|
|
|
* MI_SET_CONTEXT instead of when the next seqno has completed.
|
|
|
|
*/
|
2013-05-02 20:48:07 +07:00
|
|
|
if (from != NULL) {
|
|
|
|
from->obj->base.read_domains = I915_GEM_DOMAIN_INSTRUCTION;
|
2013-09-24 23:57:58 +07:00
|
|
|
i915_vma_move_to_active(i915_gem_obj_to_ggtt(from->obj), ring);
|
2012-06-05 04:42:46 +07:00
|
|
|
/* As long as MI_SET_CONTEXT is serializing, ie. it flushes the
|
|
|
|
* whole damn pipeline, we don't need to explicitly mark the
|
|
|
|
* object dirty. The only exception is that the context must be
|
|
|
|
* correct in case the object gets swapped out. Ideally we'd be
|
|
|
|
* able to defer doing this until we know the object would be
|
|
|
|
* swapped, but there is no way to do that yet.
|
|
|
|
*/
|
2013-05-02 20:48:07 +07:00
|
|
|
from->obj->dirty = 1;
|
|
|
|
BUG_ON(from->obj->ring != ring);
|
|
|
|
|
2013-08-27 05:50:53 +07:00
|
|
|
/* obj is kept alive until the next request by its active ref */
|
2013-12-07 05:10:55 +07:00
|
|
|
i915_gem_object_ggtt_unpin(from->obj);
|
2013-05-02 20:48:07 +07:00
|
|
|
i915_gem_context_unreference(from);
|
2012-06-05 04:42:46 +07:00
|
|
|
}
|
|
|
|
|
2013-12-29 04:31:49 +07:00
|
|
|
to->is_initialized = true;
|
|
|
|
|
2013-12-07 05:11:01 +07:00
|
|
|
done:
|
2013-05-02 20:48:07 +07:00
|
|
|
i915_gem_context_reference(to);
|
|
|
|
ring->last_context = to;
|
2013-12-07 05:11:02 +07:00
|
|
|
to->last_ring = ring;
|
2012-06-05 04:42:46 +07:00
|
|
|
|
|
|
|
return 0;
|
2013-12-07 05:11:26 +07:00
|
|
|
|
|
|
|
unpin_out:
|
|
|
|
if (ring->id == RCS)
|
|
|
|
i915_gem_object_ggtt_unpin(to->obj);
|
|
|
|
return ret;
|
2012-06-05 04:42:46 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* i915_switch_context() - perform a GPU context switch.
|
|
|
|
* @ring: ring for which we'll execute the context switch
|
|
|
|
* @file_priv: file_priv associated with the context, may be NULL
|
2014-03-04 06:57:24 +07:00
|
|
|
* @to: the context to switch to
|
2012-06-05 04:42:46 +07: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,
|
|
|
|
* it will have a refoucnt > 1. This allows us to destroy the context abstract
|
|
|
|
* object while letting the normal object tracking destroy the backing BO.
|
|
|
|
*/
|
|
|
|
int i915_switch_context(struct intel_ring_buffer *ring,
|
|
|
|
struct drm_file *file,
|
drm/i915: Get context early in execbuf
We need to have the address space when reserving space for the objects.
Since the address space and context are tied together, and reserve
occurs before context switch (for good reason), we must lookup our
context earlier in the process.
This leaves some room for optimizations where we no longer need to use
ctx_id in certain places. This will be addressed in a subsequent patch.
Important tricky bit:
Because slow relocations during execbuffer drop struct_mutex
Perhaps it would be best to acquire the reference when we get the
context, but I'll save that for another day (note I have written the
patch before, and I found the changes required to be uglier than this).
Note that since we currently access everything via context id, and not
the data structure this is fine, though not desirable. The next change
attempts to get the context only once via the context ID idr lookup, and
as such, the following can happen:
CTX-A is created, refcount = 1
CTX-A execbuf, mutex dropped
close IOCTL called on CTX-A, refcount = 0
CTX-A resumes in execbuf.
v2: Rebased on top of
commit b6359918b885da7c7b58c050674278dbd06020ab
Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Date: Wed Oct 30 15:44:16 2013 +0200
drm/i915: add i915_get_reset_stats_ioctl
v3: Rebased on top of
commit 25b3dfc87bff80317d67ddd2cd4cfb91e6fe7d79
Author: Mika Westerberg <mika.westerberg@linux.intel.com>
Date: Tue Nov 12 11:57:30 2013 +0200
Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Date: Tue Nov 26 16:14:33 2013 +0200
drm/i915: check context reset stats before relocations
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-07 05:11:21 +07:00
|
|
|
struct i915_hw_context *to)
|
2012-06-05 04:42:46 +07:00
|
|
|
{
|
|
|
|
struct drm_i915_private *dev_priv = ring->dev->dev_private;
|
|
|
|
|
2013-12-07 05:11:19 +07:00
|
|
|
WARN_ON(!mutex_is_locked(&dev_priv->dev->struct_mutex));
|
|
|
|
|
drm/i915: Get context early in execbuf
We need to have the address space when reserving space for the objects.
Since the address space and context are tied together, and reserve
occurs before context switch (for good reason), we must lookup our
context earlier in the process.
This leaves some room for optimizations where we no longer need to use
ctx_id in certain places. This will be addressed in a subsequent patch.
Important tricky bit:
Because slow relocations during execbuffer drop struct_mutex
Perhaps it would be best to acquire the reference when we get the
context, but I'll save that for another day (note I have written the
patch before, and I found the changes required to be uglier than this).
Note that since we currently access everything via context id, and not
the data structure this is fine, though not desirable. The next change
attempts to get the context only once via the context ID idr lookup, and
as such, the following can happen:
CTX-A is created, refcount = 1
CTX-A execbuf, mutex dropped
close IOCTL called on CTX-A, refcount = 0
CTX-A resumes in execbuf.
v2: Rebased on top of
commit b6359918b885da7c7b58c050674278dbd06020ab
Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Date: Wed Oct 30 15:44:16 2013 +0200
drm/i915: add i915_get_reset_stats_ioctl
v3: Rebased on top of
commit 25b3dfc87bff80317d67ddd2cd4cfb91e6fe7d79
Author: Mika Westerberg <mika.westerberg@linux.intel.com>
Date: Tue Nov 12 11:57:30 2013 +0200
Author: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Date: Tue Nov 26 16:14:33 2013 +0200
drm/i915: check context reset stats before relocations
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2013-12-07 05:11:21 +07:00
|
|
|
BUG_ON(file && to == NULL);
|
2012-06-05 04:42:46 +07:00
|
|
|
|
2014-03-14 21:22:10 +07:00
|
|
|
/* We have the fake context */
|
|
|
|
if (!HAS_HW_CONTEXTS(ring->dev)) {
|
|
|
|
ring->last_context = to;
|
2013-12-07 05:11:20 +07:00
|
|
|
return 0;
|
2014-03-14 21:22:10 +07:00
|
|
|
}
|
2013-12-07 05:11:20 +07:00
|
|
|
|
2013-12-07 05:11:01 +07:00
|
|
|
return do_switch(ring, to);
|
2012-06-05 04:42:46 +07:00
|
|
|
}
|
2012-06-05 04:42:54 +07: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;
|
|
|
|
struct i915_hw_context *ctx;
|
|
|
|
int ret;
|
|
|
|
|
2013-11-06 22:56:29 +07:00
|
|
|
if (!HAS_HW_CONTEXTS(dev))
|
2012-06-19 22:16:01 +07:00
|
|
|
return -ENODEV;
|
|
|
|
|
2012-06-05 04:42:54 +07:00
|
|
|
ret = i915_mutex_lock_interruptible(dev);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2013-12-07 05:11:26 +07:00
|
|
|
ctx = i915_gem_create_context(dev, file_priv, USES_FULL_PPGTT(dev));
|
2012-06-05 04:42:54 +07:00
|
|
|
mutex_unlock(&dev->struct_mutex);
|
2012-07-17 13:44:49 +07:00
|
|
|
if (IS_ERR(ctx))
|
|
|
|
return PTR_ERR(ctx);
|
2012-06-05 04:42:54 +07:00
|
|
|
|
|
|
|
args->ctx_id = ctx->id;
|
|
|
|
DRM_DEBUG_DRIVER("HW context %d created\n", args->ctx_id);
|
|
|
|
|
2012-07-17 13:44:49 +07:00
|
|
|
return 0;
|
2012-06-05 04:42:54 +07: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;
|
|
|
|
struct i915_hw_context *ctx;
|
|
|
|
int ret;
|
|
|
|
|
2013-12-07 05:11:19 +07:00
|
|
|
if (args->ctx_id == DEFAULT_CONTEXT_ID)
|
2013-12-25 07:02:54 +07:00
|
|
|
return -ENOENT;
|
2013-12-07 05:11:19 +07:00
|
|
|
|
2012-06-05 04:42:54 +07:00
|
|
|
ret = i915_mutex_lock_interruptible(dev);
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
|
|
|
ctx = i915_gem_context_get(file_priv, args->ctx_id);
|
2014-01-03 12:50:27 +07:00
|
|
|
if (IS_ERR(ctx)) {
|
2012-06-05 04:42:54 +07:00
|
|
|
mutex_unlock(&dev->struct_mutex);
|
2014-01-03 12:50:27 +07:00
|
|
|
return PTR_ERR(ctx);
|
2012-06-05 04:42:54 +07:00
|
|
|
}
|
|
|
|
|
2013-04-30 17:30:33 +07:00
|
|
|
idr_remove(&ctx->file_priv->context_idr, ctx->id);
|
|
|
|
i915_gem_context_unreference(ctx);
|
2012-06-05 04:42:54 +07:00
|
|
|
mutex_unlock(&dev->struct_mutex);
|
|
|
|
|
|
|
|
DRM_DEBUG_DRIVER("HW context %d destroyed\n", args->ctx_id);
|
|
|
|
return 0;
|
|
|
|
}
|