2010-05-22 03:26:39 +07:00
|
|
|
/*
|
|
|
|
* Copyright © 2008-2010 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:
|
|
|
|
* Eric Anholt <eric@anholt.net>
|
|
|
|
* Zou Nan hai <nanhai.zou@intel.com>
|
|
|
|
* Xiang Hai hao<haihao.xiang@intel.com>
|
|
|
|
*
|
|
|
|
*/
|
|
|
|
|
2015-12-06 17:26:30 +07:00
|
|
|
#include <linux/log2.h>
|
2017-11-10 21:26:34 +07:00
|
|
|
|
2012-10-03 00:01:07 +07:00
|
|
|
#include <drm/i915_drm.h>
|
2017-11-10 21:26:34 +07:00
|
|
|
|
2019-05-28 16:29:49 +07:00
|
|
|
#include "gem/i915_gem_context.h"
|
|
|
|
|
2017-11-10 21:26:34 +07:00
|
|
|
#include "i915_drv.h"
|
2010-05-22 03:26:39 +07:00
|
|
|
#include "i915_trace.h"
|
2019-05-28 16:29:49 +07:00
|
|
|
#include "intel_context.h"
|
2019-07-04 16:19:25 +07:00
|
|
|
#include "intel_gt.h"
|
2019-08-12 04:06:33 +07:00
|
|
|
#include "intel_gt_irq.h"
|
2019-08-11 21:28:00 +07:00
|
|
|
#include "intel_gt_pm_irq.h"
|
2019-04-25 00:48:39 +07:00
|
|
|
#include "intel_reset.h"
|
2018-04-10 23:12:46 +07:00
|
|
|
#include "intel_workarounds.h"
|
2010-05-22 03:26:39 +07:00
|
|
|
|
2016-04-29 15:07:05 +07:00
|
|
|
/* Rough estimate of the typical request size, performing a flush,
|
|
|
|
* set-context and then emitting the batch.
|
|
|
|
*/
|
|
|
|
#define LEGACY_REQUEST_SIZE 200
|
|
|
|
|
2017-05-04 20:08:45 +07:00
|
|
|
unsigned int intel_ring_update_space(struct intel_ring *ring)
|
2014-11-27 18:22:49 +07:00
|
|
|
{
|
2017-05-04 20:08:45 +07:00
|
|
|
unsigned int space;
|
|
|
|
|
|
|
|
space = __intel_ring_space(ring->head, ring->emit, ring->size);
|
|
|
|
|
|
|
|
ring->space = space;
|
|
|
|
return space;
|
2014-11-27 18:22:49 +07:00
|
|
|
}
|
|
|
|
|
2011-01-05 00:34:02 +07:00
|
|
|
static int
|
2018-02-21 16:56:36 +07:00
|
|
|
gen2_render_ring_flush(struct i915_request *rq, u32 mode)
|
2012-04-18 17:12:11 +07:00
|
|
|
{
|
2018-12-07 20:40:37 +07:00
|
|
|
unsigned int num_store_dw;
|
2017-02-14 18:32:42 +07:00
|
|
|
u32 cmd, *cs;
|
2012-04-18 17:12:11 +07:00
|
|
|
|
|
|
|
cmd = MI_FLUSH;
|
2018-12-07 20:40:37 +07:00
|
|
|
num_store_dw = 0;
|
2016-08-03 04:50:25 +07:00
|
|
|
if (mode & EMIT_INVALIDATE)
|
2012-04-18 17:12:11 +07:00
|
|
|
cmd |= MI_READ_FLUSH;
|
2018-12-07 20:40:37 +07:00
|
|
|
if (mode & EMIT_FLUSH)
|
|
|
|
num_store_dw = 4;
|
2012-04-18 17:12:11 +07:00
|
|
|
|
2018-12-07 20:40:37 +07:00
|
|
|
cs = intel_ring_begin(rq, 2 + 3 * num_store_dw);
|
2017-02-14 18:32:42 +07:00
|
|
|
if (IS_ERR(cs))
|
|
|
|
return PTR_ERR(cs);
|
2012-04-18 17:12:11 +07:00
|
|
|
|
2017-02-14 18:32:42 +07:00
|
|
|
*cs++ = cmd;
|
2018-12-07 20:40:37 +07:00
|
|
|
while (num_store_dw--) {
|
|
|
|
*cs++ = MI_STORE_DWORD_IMM | MI_MEM_VIRTUAL;
|
2019-07-09 19:33:43 +07:00
|
|
|
*cs++ = intel_gt_scratch_offset(rq->engine->gt,
|
|
|
|
INTEL_GT_SCRATCH_FIELD_DEFAULT);
|
2018-12-07 20:40:37 +07:00
|
|
|
*cs++ = 0;
|
|
|
|
}
|
|
|
|
*cs++ = MI_FLUSH | MI_NO_WRITE_FLUSH;
|
|
|
|
|
2018-02-21 16:56:36 +07:00
|
|
|
intel_ring_advance(rq, cs);
|
2012-04-18 17:12:11 +07:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
2018-02-21 16:56:36 +07:00
|
|
|
gen4_render_ring_flush(struct i915_request *rq, u32 mode)
|
2010-05-22 03:26:39 +07:00
|
|
|
{
|
2017-02-14 18:32:42 +07:00
|
|
|
u32 cmd, *cs;
|
2018-11-05 16:43:05 +07:00
|
|
|
int i;
|
2010-08-07 17:01:22 +07:00
|
|
|
|
2011-03-20 05:26:49 +07:00
|
|
|
/*
|
|
|
|
* read/write caches:
|
|
|
|
*
|
|
|
|
* I915_GEM_DOMAIN_RENDER is always invalidated, but is
|
|
|
|
* only flushed if MI_NO_WRITE_FLUSH is unset. On 965, it is
|
|
|
|
* also flushed at 2d versus 3d pipeline switches.
|
|
|
|
*
|
|
|
|
* read-only caches:
|
|
|
|
*
|
|
|
|
* I915_GEM_DOMAIN_SAMPLER is flushed on pre-965 if
|
|
|
|
* MI_READ_FLUSH is set, and is always flushed on 965.
|
|
|
|
*
|
|
|
|
* I915_GEM_DOMAIN_COMMAND may not exist?
|
|
|
|
*
|
|
|
|
* I915_GEM_DOMAIN_INSTRUCTION, which exists on 965, is
|
|
|
|
* invalidated when MI_EXE_FLUSH is set.
|
|
|
|
*
|
|
|
|
* I915_GEM_DOMAIN_VERTEX, which exists on 965, is
|
|
|
|
* invalidated with every MI_FLUSH.
|
|
|
|
*
|
|
|
|
* TLBs:
|
|
|
|
*
|
|
|
|
* On 965, TLBs associated with I915_GEM_DOMAIN_COMMAND
|
|
|
|
* and I915_GEM_DOMAIN_CPU in are invalidated at PTE write and
|
|
|
|
* I915_GEM_DOMAIN_RENDER and I915_GEM_DOMAIN_SAMPLER
|
|
|
|
* are flushed at any MI_FLUSH.
|
|
|
|
*/
|
|
|
|
|
2016-08-03 04:50:18 +07:00
|
|
|
cmd = MI_FLUSH;
|
2016-08-03 04:50:25 +07:00
|
|
|
if (mode & EMIT_INVALIDATE) {
|
2011-03-20 05:26:49 +07:00
|
|
|
cmd |= MI_EXE_FLUSH;
|
drm/i915: replace IS_GEN<N> with IS_GEN(..., N)
Define IS_GEN() similarly to our IS_GEN_RANGE(). but use gen instead of
gen_mask to do the comparison. Now callers can pass then gen as a parameter,
so we don't require one macro for each gen.
The following spatch was used to convert the users of these macros:
@@
expression e;
@@
(
- IS_GEN2(e)
+ IS_GEN(e, 2)
|
- IS_GEN3(e)
+ IS_GEN(e, 3)
|
- IS_GEN4(e)
+ IS_GEN(e, 4)
|
- IS_GEN5(e)
+ IS_GEN(e, 5)
|
- IS_GEN6(e)
+ IS_GEN(e, 6)
|
- IS_GEN7(e)
+ IS_GEN(e, 7)
|
- IS_GEN8(e)
+ IS_GEN(e, 8)
|
- IS_GEN9(e)
+ IS_GEN(e, 9)
|
- IS_GEN10(e)
+ IS_GEN(e, 10)
|
- IS_GEN11(e)
+ IS_GEN(e, 11)
)
v2: use IS_GEN rather than GT_GEN and compare to info.gen rather than
using the bitmask
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181212181044.15886-2-lucas.demarchi@intel.com
2018-12-13 01:10:43 +07:00
|
|
|
if (IS_G4X(rq->i915) || IS_GEN(rq->i915, 5))
|
2016-08-03 04:50:18 +07:00
|
|
|
cmd |= MI_INVALIDATE_ISP;
|
|
|
|
}
|
2010-11-30 21:07:47 +07:00
|
|
|
|
2018-11-05 16:43:05 +07:00
|
|
|
i = 2;
|
|
|
|
if (mode & EMIT_INVALIDATE)
|
|
|
|
i += 20;
|
|
|
|
|
|
|
|
cs = intel_ring_begin(rq, i);
|
2017-02-14 18:32:42 +07:00
|
|
|
if (IS_ERR(cs))
|
|
|
|
return PTR_ERR(cs);
|
2011-01-05 00:34:02 +07:00
|
|
|
|
2017-02-14 18:32:42 +07:00
|
|
|
*cs++ = cmd;
|
2018-11-05 16:43:05 +07:00
|
|
|
|
|
|
|
/*
|
|
|
|
* A random delay to let the CS invalidate take effect? Without this
|
|
|
|
* delay, the GPU relocation path fails as the CS does not see
|
|
|
|
* the updated contents. Just as important, if we apply the flushes
|
|
|
|
* to the EMIT_FLUSH branch (i.e. immediately after the relocation
|
|
|
|
* write and before the invalidate on the next batch), the relocations
|
|
|
|
* still fail. This implies that is a delay following invalidation
|
|
|
|
* that is required to reset the caches as opposed to a delay to
|
|
|
|
* ensure the memory is written.
|
|
|
|
*/
|
|
|
|
if (mode & EMIT_INVALIDATE) {
|
|
|
|
*cs++ = GFX_OP_PIPE_CONTROL(4) | PIPE_CONTROL_QW_WRITE;
|
2019-07-09 19:33:43 +07:00
|
|
|
*cs++ = intel_gt_scratch_offset(rq->engine->gt,
|
|
|
|
INTEL_GT_SCRATCH_FIELD_DEFAULT) |
|
2019-06-21 14:08:11 +07:00
|
|
|
PIPE_CONTROL_GLOBAL_GTT;
|
2018-11-05 16:43:05 +07:00
|
|
|
*cs++ = 0;
|
|
|
|
*cs++ = 0;
|
|
|
|
|
|
|
|
for (i = 0; i < 12; i++)
|
|
|
|
*cs++ = MI_FLUSH;
|
|
|
|
|
|
|
|
*cs++ = GFX_OP_PIPE_CONTROL(4) | PIPE_CONTROL_QW_WRITE;
|
2019-07-09 19:33:43 +07:00
|
|
|
*cs++ = intel_gt_scratch_offset(rq->engine->gt,
|
|
|
|
INTEL_GT_SCRATCH_FIELD_DEFAULT) |
|
2019-06-21 14:08:11 +07:00
|
|
|
PIPE_CONTROL_GLOBAL_GTT;
|
2018-11-05 16:43:05 +07:00
|
|
|
*cs++ = 0;
|
|
|
|
*cs++ = 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
*cs++ = cmd;
|
|
|
|
|
2018-02-21 16:56:36 +07:00
|
|
|
intel_ring_advance(rq, cs);
|
2011-01-05 00:34:02 +07:00
|
|
|
|
|
|
|
return 0;
|
2010-05-21 08:08:55 +07:00
|
|
|
}
|
|
|
|
|
2018-02-08 18:12:20 +07:00
|
|
|
/*
|
2011-10-16 15:23:31 +07:00
|
|
|
* Emits a PIPE_CONTROL with a non-zero post-sync operation, for
|
|
|
|
* implementing two workarounds on gen6. From section 1.4.7.1
|
|
|
|
* "PIPE_CONTROL" of the Sandy Bridge PRM volume 2 part 1:
|
|
|
|
*
|
|
|
|
* [DevSNB-C+{W/A}] Before any depth stall flush (including those
|
|
|
|
* produced by non-pipelined state commands), software needs to first
|
|
|
|
* send a PIPE_CONTROL with no bits set except Post-Sync Operation !=
|
|
|
|
* 0.
|
|
|
|
*
|
|
|
|
* [Dev-SNB{W/A}]: Before a PIPE_CONTROL with Write Cache Flush Enable
|
|
|
|
* =1, a PIPE_CONTROL with any non-zero post-sync-op is required.
|
|
|
|
*
|
|
|
|
* And the workaround for these two requires this workaround first:
|
|
|
|
*
|
|
|
|
* [Dev-SNB{W/A}]: Pipe-control with CS-stall bit set must be sent
|
|
|
|
* BEFORE the pipe-control with a post-sync op and no write-cache
|
|
|
|
* flushes.
|
|
|
|
*
|
|
|
|
* And this last workaround is tricky because of the requirements on
|
|
|
|
* that bit. From section 1.4.7.2.3 "Stall" of the Sandy Bridge PRM
|
|
|
|
* volume 2 part 1:
|
|
|
|
*
|
|
|
|
* "1 of the following must also be set:
|
|
|
|
* - Render Target Cache Flush Enable ([12] of DW1)
|
|
|
|
* - Depth Cache Flush Enable ([0] of DW1)
|
|
|
|
* - Stall at Pixel Scoreboard ([1] of DW1)
|
|
|
|
* - Depth Stall ([13] of DW1)
|
|
|
|
* - Post-Sync Operation ([13] of DW1)
|
|
|
|
* - Notify Enable ([8] of DW1)"
|
|
|
|
*
|
|
|
|
* The cache flushes require the workaround flush that triggered this
|
|
|
|
* one, so we can't use it. Depth stall would trigger the same.
|
|
|
|
* Post-sync nonzero is what triggered this second workaround, so we
|
|
|
|
* can't use that one either. Notify enable is IRQs, which aren't
|
|
|
|
* really our business. That leaves only stall at scoreboard.
|
|
|
|
*/
|
|
|
|
static int
|
2018-12-28 22:31:14 +07:00
|
|
|
gen6_emit_post_sync_nonzero_flush(struct i915_request *rq)
|
2011-10-16 15:23:31 +07:00
|
|
|
{
|
2019-06-21 14:08:11 +07:00
|
|
|
u32 scratch_addr =
|
2019-07-09 19:33:43 +07:00
|
|
|
intel_gt_scratch_offset(rq->engine->gt,
|
|
|
|
INTEL_GT_SCRATCH_FIELD_RENDER_FLUSH);
|
2017-02-14 18:32:42 +07:00
|
|
|
u32 *cs;
|
|
|
|
|
2018-02-21 16:56:36 +07:00
|
|
|
cs = intel_ring_begin(rq, 6);
|
2017-02-14 18:32:42 +07:00
|
|
|
if (IS_ERR(cs))
|
|
|
|
return PTR_ERR(cs);
|
|
|
|
|
|
|
|
*cs++ = GFX_OP_PIPE_CONTROL(5);
|
|
|
|
*cs++ = PIPE_CONTROL_CS_STALL | PIPE_CONTROL_STALL_AT_SCOREBOARD;
|
|
|
|
*cs++ = scratch_addr | PIPE_CONTROL_GLOBAL_GTT;
|
|
|
|
*cs++ = 0; /* low dword */
|
|
|
|
*cs++ = 0; /* high dword */
|
|
|
|
*cs++ = MI_NOOP;
|
2018-02-21 16:56:36 +07:00
|
|
|
intel_ring_advance(rq, cs);
|
2017-02-14 18:32:42 +07:00
|
|
|
|
2018-02-21 16:56:36 +07:00
|
|
|
cs = intel_ring_begin(rq, 6);
|
2017-02-14 18:32:42 +07:00
|
|
|
if (IS_ERR(cs))
|
|
|
|
return PTR_ERR(cs);
|
|
|
|
|
|
|
|
*cs++ = GFX_OP_PIPE_CONTROL(5);
|
|
|
|
*cs++ = PIPE_CONTROL_QW_WRITE;
|
|
|
|
*cs++ = scratch_addr | PIPE_CONTROL_GLOBAL_GTT;
|
|
|
|
*cs++ = 0;
|
|
|
|
*cs++ = 0;
|
|
|
|
*cs++ = MI_NOOP;
|
2018-02-21 16:56:36 +07:00
|
|
|
intel_ring_advance(rq, cs);
|
2011-10-16 15:23:31 +07:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
2018-02-21 16:56:36 +07:00
|
|
|
gen6_render_ring_flush(struct i915_request *rq, u32 mode)
|
2011-10-16 15:23:31 +07:00
|
|
|
{
|
2019-06-21 14:08:11 +07:00
|
|
|
u32 scratch_addr =
|
2019-07-09 19:33:43 +07:00
|
|
|
intel_gt_scratch_offset(rq->engine->gt,
|
|
|
|
INTEL_GT_SCRATCH_FIELD_RENDER_FLUSH);
|
2017-02-14 18:32:42 +07:00
|
|
|
u32 *cs, flags = 0;
|
2011-10-16 15:23:31 +07:00
|
|
|
int ret;
|
|
|
|
|
2012-08-18 04:35:42 +07:00
|
|
|
/* Force SNB workarounds for PIPE_CONTROL flushes */
|
2018-12-28 22:31:14 +07:00
|
|
|
ret = gen6_emit_post_sync_nonzero_flush(rq);
|
2012-08-18 04:35:42 +07:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2011-10-16 15:23:31 +07:00
|
|
|
/* Just flush everything. Experiments have shown that reducing the
|
|
|
|
* number of bits based on the write domains has little performance
|
|
|
|
* impact.
|
|
|
|
*/
|
2016-08-03 04:50:25 +07:00
|
|
|
if (mode & EMIT_FLUSH) {
|
2012-08-10 16:18:10 +07:00
|
|
|
flags |= PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH;
|
|
|
|
flags |= PIPE_CONTROL_DEPTH_CACHE_FLUSH;
|
|
|
|
/*
|
|
|
|
* Ensure that any following seqno writes only happen
|
|
|
|
* when the render cache is indeed flushed.
|
|
|
|
*/
|
2012-06-28 14:48:42 +07:00
|
|
|
flags |= PIPE_CONTROL_CS_STALL;
|
2012-08-10 16:18:10 +07:00
|
|
|
}
|
2016-08-03 04:50:25 +07:00
|
|
|
if (mode & EMIT_INVALIDATE) {
|
2012-08-10 16:18:10 +07:00
|
|
|
flags |= PIPE_CONTROL_TLB_INVALIDATE;
|
|
|
|
flags |= PIPE_CONTROL_INSTRUCTION_CACHE_INVALIDATE;
|
|
|
|
flags |= PIPE_CONTROL_TEXTURE_CACHE_INVALIDATE;
|
|
|
|
flags |= PIPE_CONTROL_VF_CACHE_INVALIDATE;
|
|
|
|
flags |= PIPE_CONTROL_CONST_CACHE_INVALIDATE;
|
|
|
|
flags |= PIPE_CONTROL_STATE_CACHE_INVALIDATE;
|
|
|
|
/*
|
|
|
|
* TLB invalidate requires a post-sync write.
|
|
|
|
*/
|
2012-10-26 02:15:47 +07:00
|
|
|
flags |= PIPE_CONTROL_QW_WRITE | PIPE_CONTROL_CS_STALL;
|
2012-08-10 16:18:10 +07:00
|
|
|
}
|
2011-10-16 15:23:31 +07:00
|
|
|
|
2018-02-21 16:56:36 +07:00
|
|
|
cs = intel_ring_begin(rq, 4);
|
2017-02-14 18:32:42 +07:00
|
|
|
if (IS_ERR(cs))
|
|
|
|
return PTR_ERR(cs);
|
2011-10-16 15:23:31 +07:00
|
|
|
|
2017-02-14 18:32:42 +07:00
|
|
|
*cs++ = GFX_OP_PIPE_CONTROL(4);
|
|
|
|
*cs++ = flags;
|
|
|
|
*cs++ = scratch_addr | PIPE_CONTROL_GLOBAL_GTT;
|
|
|
|
*cs++ = 0;
|
2018-02-21 16:56:36 +07:00
|
|
|
intel_ring_advance(rq, cs);
|
2011-10-16 15:23:31 +07:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-01-25 17:05:20 +07:00
|
|
|
static u32 *gen6_rcs_emit_breadcrumb(struct i915_request *rq, u32 *cs)
|
2018-12-28 22:31:14 +07:00
|
|
|
{
|
|
|
|
/* First we do the gen6_emit_post_sync_nonzero_flush w/a */
|
|
|
|
*cs++ = GFX_OP_PIPE_CONTROL(4);
|
|
|
|
*cs++ = PIPE_CONTROL_CS_STALL | PIPE_CONTROL_STALL_AT_SCOREBOARD;
|
|
|
|
*cs++ = 0;
|
|
|
|
*cs++ = 0;
|
|
|
|
|
|
|
|
*cs++ = GFX_OP_PIPE_CONTROL(4);
|
|
|
|
*cs++ = PIPE_CONTROL_QW_WRITE;
|
2019-07-09 19:33:43 +07:00
|
|
|
*cs++ = intel_gt_scratch_offset(rq->engine->gt,
|
|
|
|
INTEL_GT_SCRATCH_FIELD_DEFAULT) |
|
2019-06-21 14:08:11 +07:00
|
|
|
PIPE_CONTROL_GLOBAL_GTT;
|
2018-12-28 22:31:14 +07:00
|
|
|
*cs++ = 0;
|
|
|
|
|
|
|
|
/* Finally we can flush and with it emit the breadcrumb */
|
|
|
|
*cs++ = GFX_OP_PIPE_CONTROL(4);
|
|
|
|
*cs++ = (PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH |
|
|
|
|
PIPE_CONTROL_DEPTH_CACHE_FLUSH |
|
|
|
|
PIPE_CONTROL_DC_FLUSH_ENABLE |
|
|
|
|
PIPE_CONTROL_QW_WRITE |
|
|
|
|
PIPE_CONTROL_CS_STALL);
|
drm/i915: Mark i915_request.timeline as a volatile, rcu pointer
The request->timeline is only valid until the request is retired (i.e.
before it is completed). Upon retiring the request, the context may be
unpinned and freed, and along with it the timeline may be freed. We
therefore need to be very careful when chasing rq->timeline that the
pointer does not disappear beneath us. The vast majority of users are in
a protected context, either during request construction or retirement,
where the timeline->mutex is held and the timeline cannot disappear. It
is those few off the beaten path (where we access a second timeline) that
need extra scrutiny -- to be added in the next patch after first adding
the warnings about dangerous access.
One complication, where we cannot use the timeline->mutex itself, is
during request submission onto hardware (under spinlocks). Here, we want
to check on the timeline to finalize the breadcrumb, and so we need to
impose a second rule to ensure that the request->timeline is indeed
valid. As we are submitting the request, it's context and timeline must
be pinned, as it will be used by the hardware. Since it is pinned, we
know the request->timeline must still be valid, and we cannot submit the
idle barrier until after we release the engine->active.lock, ergo while
submitting and holding that spinlock, a second thread cannot release the
timeline.
v2: Don't be lazy inside selftests; hold the timeline->mutex for as long
as we need it, and tidy up acquiring the timeline with a bit of
refactoring (i915_active_add_request)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190919111912.21631-1-chris@chris-wilson.co.uk
2019-09-19 18:19:10 +07:00
|
|
|
*cs++ = i915_request_active_timeline(rq)->hwsp_offset |
|
|
|
|
PIPE_CONTROL_GLOBAL_GTT;
|
2019-01-29 01:18:11 +07:00
|
|
|
*cs++ = rq->fence.seqno;
|
|
|
|
|
2018-12-28 22:31:14 +07:00
|
|
|
*cs++ = MI_USER_INTERRUPT;
|
|
|
|
*cs++ = MI_NOOP;
|
|
|
|
|
|
|
|
rq->tail = intel_ring_offset(rq, cs);
|
|
|
|
assert_ring_tail_valid(rq->ring, rq->tail);
|
2019-01-25 17:05:20 +07:00
|
|
|
|
|
|
|
return cs;
|
2018-12-28 22:31:14 +07:00
|
|
|
}
|
|
|
|
|
drm/i915: add workarounds to gen7_render_ring_flush
From Bspec, Vol 2a, Section 1.9.3.4 "PIPE_CONTROL", intro section
detailing the various workarounds:
"[DevIVB {W/A}, DevHSW {W/A}]: Pipe_control with CS-stall bit
set must be issued before a pipe-control command that has the State
Cache Invalidate bit set."
Note that public Bspec has different numbering, it's Vol2Part1,
Section 1.10.4.1 "PIPE_CONTROL" there.
There's also a second workaround for the PIPE_CONTROL command itself:
"[DevIVB, DevVLV, DevHSW] {WA}: Every 4th PIPE_CONTROL command, not
counting the PIPE_CONTROL with only read-cache-invalidate bit(s) set,
must have a CS_STALL bit set"
For simplicity we simply set the CS_STALL bit on every pipe_control on
gen7+
Note that this massively helps on some hsw machines, together with the
following patch to unconditionally set the CS_STALL bit on every
pipe_control it prevents a gpu hang every few seconds.
This is a regression that has been introduced in the pipe_control
cleanup:
commit 6c6cf5aa9c583478b19e23149feaa92d01fb8c2d
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Fri Jul 20 18:02:28 2012 +0100
drm/i915: Only apply the SNB pipe control w/a to gen6
It looks like the massive snb pipe_control workaround also papered
over any issues on ivb and hsw.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: squashed both workarounds together, pimped commit message
with Bsepc citations, regression commit citation and changed the
comment in the code a bit to clarify that we unconditionally set
CS_STALL to avoid being hurt by trying to be clever.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-18 04:35:43 +07:00
|
|
|
static int
|
2018-02-21 16:56:36 +07:00
|
|
|
gen7_render_ring_cs_stall_wa(struct i915_request *rq)
|
drm/i915: add workarounds to gen7_render_ring_flush
From Bspec, Vol 2a, Section 1.9.3.4 "PIPE_CONTROL", intro section
detailing the various workarounds:
"[DevIVB {W/A}, DevHSW {W/A}]: Pipe_control with CS-stall bit
set must be issued before a pipe-control command that has the State
Cache Invalidate bit set."
Note that public Bspec has different numbering, it's Vol2Part1,
Section 1.10.4.1 "PIPE_CONTROL" there.
There's also a second workaround for the PIPE_CONTROL command itself:
"[DevIVB, DevVLV, DevHSW] {WA}: Every 4th PIPE_CONTROL command, not
counting the PIPE_CONTROL with only read-cache-invalidate bit(s) set,
must have a CS_STALL bit set"
For simplicity we simply set the CS_STALL bit on every pipe_control on
gen7+
Note that this massively helps on some hsw machines, together with the
following patch to unconditionally set the CS_STALL bit on every
pipe_control it prevents a gpu hang every few seconds.
This is a regression that has been introduced in the pipe_control
cleanup:
commit 6c6cf5aa9c583478b19e23149feaa92d01fb8c2d
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Fri Jul 20 18:02:28 2012 +0100
drm/i915: Only apply the SNB pipe control w/a to gen6
It looks like the massive snb pipe_control workaround also papered
over any issues on ivb and hsw.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: squashed both workarounds together, pimped commit message
with Bsepc citations, regression commit citation and changed the
comment in the code a bit to clarify that we unconditionally set
CS_STALL to avoid being hurt by trying to be clever.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-18 04:35:43 +07:00
|
|
|
{
|
2017-02-14 18:32:42 +07:00
|
|
|
u32 *cs;
|
drm/i915: add workarounds to gen7_render_ring_flush
From Bspec, Vol 2a, Section 1.9.3.4 "PIPE_CONTROL", intro section
detailing the various workarounds:
"[DevIVB {W/A}, DevHSW {W/A}]: Pipe_control with CS-stall bit
set must be issued before a pipe-control command that has the State
Cache Invalidate bit set."
Note that public Bspec has different numbering, it's Vol2Part1,
Section 1.10.4.1 "PIPE_CONTROL" there.
There's also a second workaround for the PIPE_CONTROL command itself:
"[DevIVB, DevVLV, DevHSW] {WA}: Every 4th PIPE_CONTROL command, not
counting the PIPE_CONTROL with only read-cache-invalidate bit(s) set,
must have a CS_STALL bit set"
For simplicity we simply set the CS_STALL bit on every pipe_control on
gen7+
Note that this massively helps on some hsw machines, together with the
following patch to unconditionally set the CS_STALL bit on every
pipe_control it prevents a gpu hang every few seconds.
This is a regression that has been introduced in the pipe_control
cleanup:
commit 6c6cf5aa9c583478b19e23149feaa92d01fb8c2d
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Fri Jul 20 18:02:28 2012 +0100
drm/i915: Only apply the SNB pipe control w/a to gen6
It looks like the massive snb pipe_control workaround also papered
over any issues on ivb and hsw.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: squashed both workarounds together, pimped commit message
with Bsepc citations, regression commit citation and changed the
comment in the code a bit to clarify that we unconditionally set
CS_STALL to avoid being hurt by trying to be clever.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-18 04:35:43 +07:00
|
|
|
|
2018-02-21 16:56:36 +07:00
|
|
|
cs = intel_ring_begin(rq, 4);
|
2017-02-14 18:32:42 +07:00
|
|
|
if (IS_ERR(cs))
|
|
|
|
return PTR_ERR(cs);
|
drm/i915: add workarounds to gen7_render_ring_flush
From Bspec, Vol 2a, Section 1.9.3.4 "PIPE_CONTROL", intro section
detailing the various workarounds:
"[DevIVB {W/A}, DevHSW {W/A}]: Pipe_control with CS-stall bit
set must be issued before a pipe-control command that has the State
Cache Invalidate bit set."
Note that public Bspec has different numbering, it's Vol2Part1,
Section 1.10.4.1 "PIPE_CONTROL" there.
There's also a second workaround for the PIPE_CONTROL command itself:
"[DevIVB, DevVLV, DevHSW] {WA}: Every 4th PIPE_CONTROL command, not
counting the PIPE_CONTROL with only read-cache-invalidate bit(s) set,
must have a CS_STALL bit set"
For simplicity we simply set the CS_STALL bit on every pipe_control on
gen7+
Note that this massively helps on some hsw machines, together with the
following patch to unconditionally set the CS_STALL bit on every
pipe_control it prevents a gpu hang every few seconds.
This is a regression that has been introduced in the pipe_control
cleanup:
commit 6c6cf5aa9c583478b19e23149feaa92d01fb8c2d
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Fri Jul 20 18:02:28 2012 +0100
drm/i915: Only apply the SNB pipe control w/a to gen6
It looks like the massive snb pipe_control workaround also papered
over any issues on ivb and hsw.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: squashed both workarounds together, pimped commit message
with Bsepc citations, regression commit citation and changed the
comment in the code a bit to clarify that we unconditionally set
CS_STALL to avoid being hurt by trying to be clever.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-18 04:35:43 +07:00
|
|
|
|
2017-02-14 18:32:42 +07:00
|
|
|
*cs++ = GFX_OP_PIPE_CONTROL(4);
|
|
|
|
*cs++ = PIPE_CONTROL_CS_STALL | PIPE_CONTROL_STALL_AT_SCOREBOARD;
|
|
|
|
*cs++ = 0;
|
|
|
|
*cs++ = 0;
|
2018-02-21 16:56:36 +07:00
|
|
|
intel_ring_advance(rq, cs);
|
drm/i915: add workarounds to gen7_render_ring_flush
From Bspec, Vol 2a, Section 1.9.3.4 "PIPE_CONTROL", intro section
detailing the various workarounds:
"[DevIVB {W/A}, DevHSW {W/A}]: Pipe_control with CS-stall bit
set must be issued before a pipe-control command that has the State
Cache Invalidate bit set."
Note that public Bspec has different numbering, it's Vol2Part1,
Section 1.10.4.1 "PIPE_CONTROL" there.
There's also a second workaround for the PIPE_CONTROL command itself:
"[DevIVB, DevVLV, DevHSW] {WA}: Every 4th PIPE_CONTROL command, not
counting the PIPE_CONTROL with only read-cache-invalidate bit(s) set,
must have a CS_STALL bit set"
For simplicity we simply set the CS_STALL bit on every pipe_control on
gen7+
Note that this massively helps on some hsw machines, together with the
following patch to unconditionally set the CS_STALL bit on every
pipe_control it prevents a gpu hang every few seconds.
This is a regression that has been introduced in the pipe_control
cleanup:
commit 6c6cf5aa9c583478b19e23149feaa92d01fb8c2d
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Fri Jul 20 18:02:28 2012 +0100
drm/i915: Only apply the SNB pipe control w/a to gen6
It looks like the massive snb pipe_control workaround also papered
over any issues on ivb and hsw.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: squashed both workarounds together, pimped commit message
with Bsepc citations, regression commit citation and changed the
comment in the code a bit to clarify that we unconditionally set
CS_STALL to avoid being hurt by trying to be clever.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-18 04:35:43 +07:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2012-08-18 04:35:41 +07:00
|
|
|
static int
|
2018-02-21 16:56:36 +07:00
|
|
|
gen7_render_ring_flush(struct i915_request *rq, u32 mode)
|
2012-08-18 04:35:41 +07:00
|
|
|
{
|
2019-06-21 14:08:11 +07:00
|
|
|
u32 scratch_addr =
|
2019-07-09 19:33:43 +07:00
|
|
|
intel_gt_scratch_offset(rq->engine->gt,
|
|
|
|
INTEL_GT_SCRATCH_FIELD_RENDER_FLUSH);
|
2017-02-14 18:32:42 +07:00
|
|
|
u32 *cs, flags = 0;
|
2012-08-18 04:35:41 +07:00
|
|
|
|
drm/i915: add workarounds to gen7_render_ring_flush
From Bspec, Vol 2a, Section 1.9.3.4 "PIPE_CONTROL", intro section
detailing the various workarounds:
"[DevIVB {W/A}, DevHSW {W/A}]: Pipe_control with CS-stall bit
set must be issued before a pipe-control command that has the State
Cache Invalidate bit set."
Note that public Bspec has different numbering, it's Vol2Part1,
Section 1.10.4.1 "PIPE_CONTROL" there.
There's also a second workaround for the PIPE_CONTROL command itself:
"[DevIVB, DevVLV, DevHSW] {WA}: Every 4th PIPE_CONTROL command, not
counting the PIPE_CONTROL with only read-cache-invalidate bit(s) set,
must have a CS_STALL bit set"
For simplicity we simply set the CS_STALL bit on every pipe_control on
gen7+
Note that this massively helps on some hsw machines, together with the
following patch to unconditionally set the CS_STALL bit on every
pipe_control it prevents a gpu hang every few seconds.
This is a regression that has been introduced in the pipe_control
cleanup:
commit 6c6cf5aa9c583478b19e23149feaa92d01fb8c2d
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Fri Jul 20 18:02:28 2012 +0100
drm/i915: Only apply the SNB pipe control w/a to gen6
It looks like the massive snb pipe_control workaround also papered
over any issues on ivb and hsw.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: squashed both workarounds together, pimped commit message
with Bsepc citations, regression commit citation and changed the
comment in the code a bit to clarify that we unconditionally set
CS_STALL to avoid being hurt by trying to be clever.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-18 04:35:43 +07:00
|
|
|
/*
|
|
|
|
* Ensure that any following seqno writes only happen when the render
|
|
|
|
* cache is indeed flushed.
|
|
|
|
*
|
|
|
|
* Workaround: 4th PIPE_CONTROL command (except the ones with only
|
|
|
|
* read-cache invalidate bits set) must have the CS_STALL bit set. We
|
|
|
|
* don't try to be clever and just set it unconditionally.
|
|
|
|
*/
|
|
|
|
flags |= PIPE_CONTROL_CS_STALL;
|
|
|
|
|
2012-08-18 04:35:41 +07:00
|
|
|
/* Just flush everything. Experiments have shown that reducing the
|
|
|
|
* number of bits based on the write domains has little performance
|
|
|
|
* impact.
|
|
|
|
*/
|
2016-08-03 04:50:25 +07:00
|
|
|
if (mode & EMIT_FLUSH) {
|
2012-08-18 04:35:41 +07:00
|
|
|
flags |= PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH;
|
|
|
|
flags |= PIPE_CONTROL_DEPTH_CACHE_FLUSH;
|
2016-01-14 09:59:39 +07:00
|
|
|
flags |= PIPE_CONTROL_DC_FLUSH_ENABLE;
|
2015-08-21 22:08:41 +07:00
|
|
|
flags |= PIPE_CONTROL_FLUSH_ENABLE;
|
2012-08-18 04:35:41 +07:00
|
|
|
}
|
2016-08-03 04:50:25 +07:00
|
|
|
if (mode & EMIT_INVALIDATE) {
|
2012-08-18 04:35:41 +07:00
|
|
|
flags |= PIPE_CONTROL_TLB_INVALIDATE;
|
|
|
|
flags |= PIPE_CONTROL_INSTRUCTION_CACHE_INVALIDATE;
|
|
|
|
flags |= PIPE_CONTROL_TEXTURE_CACHE_INVALIDATE;
|
|
|
|
flags |= PIPE_CONTROL_VF_CACHE_INVALIDATE;
|
|
|
|
flags |= PIPE_CONTROL_CONST_CACHE_INVALIDATE;
|
|
|
|
flags |= PIPE_CONTROL_STATE_CACHE_INVALIDATE;
|
2014-12-16 15:44:31 +07:00
|
|
|
flags |= PIPE_CONTROL_MEDIA_STATE_CLEAR;
|
2012-08-18 04:35:41 +07:00
|
|
|
/*
|
|
|
|
* TLB invalidate requires a post-sync write.
|
|
|
|
*/
|
|
|
|
flags |= PIPE_CONTROL_QW_WRITE;
|
2013-02-15 02:53:51 +07:00
|
|
|
flags |= PIPE_CONTROL_GLOBAL_GTT_IVB;
|
drm/i915: add workarounds to gen7_render_ring_flush
From Bspec, Vol 2a, Section 1.9.3.4 "PIPE_CONTROL", intro section
detailing the various workarounds:
"[DevIVB {W/A}, DevHSW {W/A}]: Pipe_control with CS-stall bit
set must be issued before a pipe-control command that has the State
Cache Invalidate bit set."
Note that public Bspec has different numbering, it's Vol2Part1,
Section 1.10.4.1 "PIPE_CONTROL" there.
There's also a second workaround for the PIPE_CONTROL command itself:
"[DevIVB, DevVLV, DevHSW] {WA}: Every 4th PIPE_CONTROL command, not
counting the PIPE_CONTROL with only read-cache-invalidate bit(s) set,
must have a CS_STALL bit set"
For simplicity we simply set the CS_STALL bit on every pipe_control on
gen7+
Note that this massively helps on some hsw machines, together with the
following patch to unconditionally set the CS_STALL bit on every
pipe_control it prevents a gpu hang every few seconds.
This is a regression that has been introduced in the pipe_control
cleanup:
commit 6c6cf5aa9c583478b19e23149feaa92d01fb8c2d
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Fri Jul 20 18:02:28 2012 +0100
drm/i915: Only apply the SNB pipe control w/a to gen6
It looks like the massive snb pipe_control workaround also papered
over any issues on ivb and hsw.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: squashed both workarounds together, pimped commit message
with Bsepc citations, regression commit citation and changed the
comment in the code a bit to clarify that we unconditionally set
CS_STALL to avoid being hurt by trying to be clever.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-18 04:35:43 +07:00
|
|
|
|
2014-12-16 15:44:32 +07:00
|
|
|
flags |= PIPE_CONTROL_STALL_AT_SCOREBOARD;
|
|
|
|
|
drm/i915: add workarounds to gen7_render_ring_flush
From Bspec, Vol 2a, Section 1.9.3.4 "PIPE_CONTROL", intro section
detailing the various workarounds:
"[DevIVB {W/A}, DevHSW {W/A}]: Pipe_control with CS-stall bit
set must be issued before a pipe-control command that has the State
Cache Invalidate bit set."
Note that public Bspec has different numbering, it's Vol2Part1,
Section 1.10.4.1 "PIPE_CONTROL" there.
There's also a second workaround for the PIPE_CONTROL command itself:
"[DevIVB, DevVLV, DevHSW] {WA}: Every 4th PIPE_CONTROL command, not
counting the PIPE_CONTROL with only read-cache-invalidate bit(s) set,
must have a CS_STALL bit set"
For simplicity we simply set the CS_STALL bit on every pipe_control on
gen7+
Note that this massively helps on some hsw machines, together with the
following patch to unconditionally set the CS_STALL bit on every
pipe_control it prevents a gpu hang every few seconds.
This is a regression that has been introduced in the pipe_control
cleanup:
commit 6c6cf5aa9c583478b19e23149feaa92d01fb8c2d
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date: Fri Jul 20 18:02:28 2012 +0100
drm/i915: Only apply the SNB pipe control w/a to gen6
It looks like the massive snb pipe_control workaround also papered
over any issues on ivb and hsw.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
[danvet: squashed both workarounds together, pimped commit message
with Bsepc citations, regression commit citation and changed the
comment in the code a bit to clarify that we unconditionally set
CS_STALL to avoid being hurt by trying to be clever.]
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2012-08-18 04:35:43 +07:00
|
|
|
/* Workaround: we must issue a pipe_control with CS-stall bit
|
|
|
|
* set before a pipe_control command that has the state cache
|
|
|
|
* invalidate bit set. */
|
2018-02-21 16:56:36 +07:00
|
|
|
gen7_render_ring_cs_stall_wa(rq);
|
2012-08-18 04:35:41 +07:00
|
|
|
}
|
|
|
|
|
2018-02-21 16:56:36 +07:00
|
|
|
cs = intel_ring_begin(rq, 4);
|
2017-02-14 18:32:42 +07:00
|
|
|
if (IS_ERR(cs))
|
|
|
|
return PTR_ERR(cs);
|
2012-08-18 04:35:41 +07:00
|
|
|
|
2017-02-14 18:32:42 +07:00
|
|
|
*cs++ = GFX_OP_PIPE_CONTROL(4);
|
|
|
|
*cs++ = flags;
|
|
|
|
*cs++ = scratch_addr;
|
|
|
|
*cs++ = 0;
|
2018-02-21 16:56:36 +07:00
|
|
|
intel_ring_advance(rq, cs);
|
2012-08-18 04:35:41 +07:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-01-25 17:05:20 +07:00
|
|
|
static u32 *gen7_rcs_emit_breadcrumb(struct i915_request *rq, u32 *cs)
|
2018-12-28 22:31:14 +07:00
|
|
|
{
|
|
|
|
*cs++ = GFX_OP_PIPE_CONTROL(4);
|
|
|
|
*cs++ = (PIPE_CONTROL_RENDER_TARGET_CACHE_FLUSH |
|
|
|
|
PIPE_CONTROL_DEPTH_CACHE_FLUSH |
|
|
|
|
PIPE_CONTROL_DC_FLUSH_ENABLE |
|
|
|
|
PIPE_CONTROL_FLUSH_ENABLE |
|
|
|
|
PIPE_CONTROL_QW_WRITE |
|
|
|
|
PIPE_CONTROL_GLOBAL_GTT_IVB |
|
|
|
|
PIPE_CONTROL_CS_STALL);
|
drm/i915: Mark i915_request.timeline as a volatile, rcu pointer
The request->timeline is only valid until the request is retired (i.e.
before it is completed). Upon retiring the request, the context may be
unpinned and freed, and along with it the timeline may be freed. We
therefore need to be very careful when chasing rq->timeline that the
pointer does not disappear beneath us. The vast majority of users are in
a protected context, either during request construction or retirement,
where the timeline->mutex is held and the timeline cannot disappear. It
is those few off the beaten path (where we access a second timeline) that
need extra scrutiny -- to be added in the next patch after first adding
the warnings about dangerous access.
One complication, where we cannot use the timeline->mutex itself, is
during request submission onto hardware (under spinlocks). Here, we want
to check on the timeline to finalize the breadcrumb, and so we need to
impose a second rule to ensure that the request->timeline is indeed
valid. As we are submitting the request, it's context and timeline must
be pinned, as it will be used by the hardware. Since it is pinned, we
know the request->timeline must still be valid, and we cannot submit the
idle barrier until after we release the engine->active.lock, ergo while
submitting and holding that spinlock, a second thread cannot release the
timeline.
v2: Don't be lazy inside selftests; hold the timeline->mutex for as long
as we need it, and tidy up acquiring the timeline with a bit of
refactoring (i915_active_add_request)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190919111912.21631-1-chris@chris-wilson.co.uk
2019-09-19 18:19:10 +07:00
|
|
|
*cs++ = i915_request_active_timeline(rq)->hwsp_offset;
|
2019-01-29 01:18:11 +07:00
|
|
|
*cs++ = rq->fence.seqno;
|
|
|
|
|
2018-12-28 22:31:14 +07:00
|
|
|
*cs++ = MI_USER_INTERRUPT;
|
|
|
|
*cs++ = MI_NOOP;
|
|
|
|
|
|
|
|
rq->tail = intel_ring_offset(rq, cs);
|
|
|
|
assert_ring_tail_valid(rq->ring, rq->tail);
|
2019-01-25 17:05:20 +07:00
|
|
|
|
|
|
|
return cs;
|
2018-12-28 22:31:14 +07:00
|
|
|
}
|
|
|
|
|
2019-01-25 17:05:20 +07:00
|
|
|
static u32 *gen6_xcs_emit_breadcrumb(struct i915_request *rq, u32 *cs)
|
2018-12-28 22:31:14 +07:00
|
|
|
{
|
drm/i915: Mark i915_request.timeline as a volatile, rcu pointer
The request->timeline is only valid until the request is retired (i.e.
before it is completed). Upon retiring the request, the context may be
unpinned and freed, and along with it the timeline may be freed. We
therefore need to be very careful when chasing rq->timeline that the
pointer does not disappear beneath us. The vast majority of users are in
a protected context, either during request construction or retirement,
where the timeline->mutex is held and the timeline cannot disappear. It
is those few off the beaten path (where we access a second timeline) that
need extra scrutiny -- to be added in the next patch after first adding
the warnings about dangerous access.
One complication, where we cannot use the timeline->mutex itself, is
during request submission onto hardware (under spinlocks). Here, we want
to check on the timeline to finalize the breadcrumb, and so we need to
impose a second rule to ensure that the request->timeline is indeed
valid. As we are submitting the request, it's context and timeline must
be pinned, as it will be used by the hardware. Since it is pinned, we
know the request->timeline must still be valid, and we cannot submit the
idle barrier until after we release the engine->active.lock, ergo while
submitting and holding that spinlock, a second thread cannot release the
timeline.
v2: Don't be lazy inside selftests; hold the timeline->mutex for as long
as we need it, and tidy up acquiring the timeline with a bit of
refactoring (i915_active_add_request)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190919111912.21631-1-chris@chris-wilson.co.uk
2019-09-19 18:19:10 +07:00
|
|
|
GEM_BUG_ON(i915_request_active_timeline(rq)->hwsp_ggtt != rq->engine->status_page.vma);
|
|
|
|
GEM_BUG_ON(offset_in_page(i915_request_active_timeline(rq)->hwsp_offset) != I915_GEM_HWS_SEQNO_ADDR);
|
2019-01-29 01:18:11 +07:00
|
|
|
|
|
|
|
*cs++ = MI_FLUSH_DW | MI_FLUSH_DW_OP_STOREDW | MI_FLUSH_DW_STORE_INDEX;
|
|
|
|
*cs++ = I915_GEM_HWS_SEQNO_ADDR | MI_FLUSH_DW_USE_GTT;
|
|
|
|
*cs++ = rq->fence.seqno;
|
|
|
|
|
2018-12-28 22:31:14 +07:00
|
|
|
*cs++ = MI_USER_INTERRUPT;
|
|
|
|
|
|
|
|
rq->tail = intel_ring_offset(rq, cs);
|
|
|
|
assert_ring_tail_valid(rq->ring, rq->tail);
|
2019-01-25 17:05:20 +07:00
|
|
|
|
|
|
|
return cs;
|
2018-12-28 22:31:14 +07:00
|
|
|
}
|
|
|
|
|
2018-12-29 00:16:39 +07:00
|
|
|
#define GEN7_XCS_WA 32
|
2019-01-25 17:05:20 +07:00
|
|
|
static u32 *gen7_xcs_emit_breadcrumb(struct i915_request *rq, u32 *cs)
|
2018-12-29 00:16:39 +07:00
|
|
|
{
|
|
|
|
int i;
|
|
|
|
|
drm/i915: Mark i915_request.timeline as a volatile, rcu pointer
The request->timeline is only valid until the request is retired (i.e.
before it is completed). Upon retiring the request, the context may be
unpinned and freed, and along with it the timeline may be freed. We
therefore need to be very careful when chasing rq->timeline that the
pointer does not disappear beneath us. The vast majority of users are in
a protected context, either during request construction or retirement,
where the timeline->mutex is held and the timeline cannot disappear. It
is those few off the beaten path (where we access a second timeline) that
need extra scrutiny -- to be added in the next patch after first adding
the warnings about dangerous access.
One complication, where we cannot use the timeline->mutex itself, is
during request submission onto hardware (under spinlocks). Here, we want
to check on the timeline to finalize the breadcrumb, and so we need to
impose a second rule to ensure that the request->timeline is indeed
valid. As we are submitting the request, it's context and timeline must
be pinned, as it will be used by the hardware. Since it is pinned, we
know the request->timeline must still be valid, and we cannot submit the
idle barrier until after we release the engine->active.lock, ergo while
submitting and holding that spinlock, a second thread cannot release the
timeline.
v2: Don't be lazy inside selftests; hold the timeline->mutex for as long
as we need it, and tidy up acquiring the timeline with a bit of
refactoring (i915_active_add_request)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190919111912.21631-1-chris@chris-wilson.co.uk
2019-09-19 18:19:10 +07:00
|
|
|
GEM_BUG_ON(i915_request_active_timeline(rq)->hwsp_ggtt != rq->engine->status_page.vma);
|
|
|
|
GEM_BUG_ON(offset_in_page(i915_request_active_timeline(rq)->hwsp_offset) != I915_GEM_HWS_SEQNO_ADDR);
|
2019-01-29 01:18:11 +07:00
|
|
|
|
|
|
|
*cs++ = MI_FLUSH_DW | MI_FLUSH_DW_OP_STOREDW | MI_FLUSH_DW_STORE_INDEX;
|
|
|
|
*cs++ = I915_GEM_HWS_SEQNO_ADDR | MI_FLUSH_DW_USE_GTT;
|
|
|
|
*cs++ = rq->fence.seqno;
|
|
|
|
|
2018-12-29 00:16:39 +07:00
|
|
|
for (i = 0; i < GEN7_XCS_WA; i++) {
|
|
|
|
*cs++ = MI_STORE_DWORD_INDEX;
|
2019-01-29 01:18:11 +07:00
|
|
|
*cs++ = I915_GEM_HWS_SEQNO_ADDR;
|
|
|
|
*cs++ = rq->fence.seqno;
|
2018-12-29 00:16:39 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
*cs++ = MI_FLUSH_DW;
|
|
|
|
*cs++ = 0;
|
|
|
|
*cs++ = 0;
|
|
|
|
|
|
|
|
*cs++ = MI_USER_INTERRUPT;
|
2019-05-08 15:06:25 +07:00
|
|
|
*cs++ = MI_NOOP;
|
2018-12-29 00:16:39 +07:00
|
|
|
|
|
|
|
rq->tail = intel_ring_offset(rq, cs);
|
|
|
|
assert_ring_tail_valid(rq->ring, rq->tail);
|
2019-01-25 17:05:20 +07:00
|
|
|
|
|
|
|
return cs;
|
2018-12-29 00:16:39 +07:00
|
|
|
}
|
|
|
|
#undef GEN7_XCS_WA
|
|
|
|
|
2018-12-18 17:27:12 +07:00
|
|
|
static void set_hwstam(struct intel_engine_cs *engine, u32 mask)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* Keep the render interrupt unmasked as this papers over
|
|
|
|
* lost interrupts following a reset.
|
|
|
|
*/
|
|
|
|
if (engine->class == RENDER_CLASS) {
|
|
|
|
if (INTEL_GEN(engine->i915) >= 6)
|
|
|
|
mask &= ~BIT(0);
|
|
|
|
else
|
|
|
|
mask &= ~I915_USER_INTERRUPT;
|
|
|
|
}
|
|
|
|
|
|
|
|
intel_engine_set_hwsp_writemask(engine, mask);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void set_hws_pga(struct intel_engine_cs *engine, phys_addr_t phys)
|
2013-07-03 17:56:54 +07:00
|
|
|
{
|
2016-05-06 21:40:21 +07:00
|
|
|
struct drm_i915_private *dev_priv = engine->i915;
|
2013-07-03 17:56:54 +07:00
|
|
|
u32 addr;
|
|
|
|
|
2018-09-03 22:23:04 +07:00
|
|
|
addr = lower_32_bits(phys);
|
2016-05-06 21:40:21 +07:00
|
|
|
if (INTEL_GEN(dev_priv) >= 4)
|
2018-09-03 22:23:04 +07:00
|
|
|
addr |= (phys >> 28) & 0xf0;
|
|
|
|
|
2013-07-03 17:56:54 +07:00
|
|
|
I915_WRITE(HWS_PGA, addr);
|
|
|
|
}
|
|
|
|
|
2019-01-28 17:23:55 +07:00
|
|
|
static struct page *status_page(struct intel_engine_cs *engine)
|
2018-12-18 17:27:12 +07:00
|
|
|
{
|
2019-01-28 17:23:55 +07:00
|
|
|
struct drm_i915_gem_object *obj = engine->status_page.vma->obj;
|
2018-12-18 17:27:12 +07:00
|
|
|
|
2019-01-28 17:23:55 +07:00
|
|
|
GEM_BUG_ON(!i915_gem_object_has_pinned_pages(obj));
|
|
|
|
return sg_page(obj->mm.pages->sgl);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void ring_setup_phys_status_page(struct intel_engine_cs *engine)
|
|
|
|
{
|
|
|
|
set_hws_pga(engine, PFN_PHYS(page_to_pfn(status_page(engine))));
|
2018-12-18 17:27:12 +07:00
|
|
|
set_hwstam(engine, ~0u);
|
|
|
|
}
|
|
|
|
|
|
|
|
static void set_hwsp(struct intel_engine_cs *engine, u32 offset)
|
2015-02-11 02:32:17 +07:00
|
|
|
{
|
2016-05-06 21:40:21 +07:00
|
|
|
struct drm_i915_private *dev_priv = engine->i915;
|
2018-12-18 17:27:12 +07:00
|
|
|
i915_reg_t hwsp;
|
2015-02-11 02:32:17 +07:00
|
|
|
|
2018-12-18 17:27:12 +07:00
|
|
|
/*
|
|
|
|
* The ring status page addresses are no longer next to the rest of
|
2015-02-11 02:32:17 +07:00
|
|
|
* the ring registers as of gen7.
|
|
|
|
*/
|
drm/i915: replace IS_GEN<N> with IS_GEN(..., N)
Define IS_GEN() similarly to our IS_GEN_RANGE(). but use gen instead of
gen_mask to do the comparison. Now callers can pass then gen as a parameter,
so we don't require one macro for each gen.
The following spatch was used to convert the users of these macros:
@@
expression e;
@@
(
- IS_GEN2(e)
+ IS_GEN(e, 2)
|
- IS_GEN3(e)
+ IS_GEN(e, 3)
|
- IS_GEN4(e)
+ IS_GEN(e, 4)
|
- IS_GEN5(e)
+ IS_GEN(e, 5)
|
- IS_GEN6(e)
+ IS_GEN(e, 6)
|
- IS_GEN7(e)
+ IS_GEN(e, 7)
|
- IS_GEN8(e)
+ IS_GEN(e, 8)
|
- IS_GEN9(e)
+ IS_GEN(e, 9)
|
- IS_GEN10(e)
+ IS_GEN(e, 10)
|
- IS_GEN11(e)
+ IS_GEN(e, 11)
)
v2: use IS_GEN rather than GT_GEN and compare to info.gen rather than
using the bitmask
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181212181044.15886-2-lucas.demarchi@intel.com
2018-12-13 01:10:43 +07:00
|
|
|
if (IS_GEN(dev_priv, 7)) {
|
2016-03-16 18:00:37 +07:00
|
|
|
switch (engine->id) {
|
2017-08-31 01:01:15 +07:00
|
|
|
/*
|
|
|
|
* No more rings exist on Gen7. Default case is only to shut up
|
|
|
|
* gcc switch check warning.
|
|
|
|
*/
|
|
|
|
default:
|
|
|
|
GEM_BUG_ON(engine->id);
|
2019-03-06 01:03:30 +07:00
|
|
|
/* fallthrough */
|
|
|
|
case RCS0:
|
2018-12-18 17:27:12 +07:00
|
|
|
hwsp = RENDER_HWS_PGA_GEN7;
|
2015-02-11 02:32:17 +07:00
|
|
|
break;
|
2019-03-06 01:03:30 +07:00
|
|
|
case BCS0:
|
2018-12-18 17:27:12 +07:00
|
|
|
hwsp = BLT_HWS_PGA_GEN7;
|
2015-02-11 02:32:17 +07:00
|
|
|
break;
|
2019-03-06 01:03:30 +07:00
|
|
|
case VCS0:
|
2018-12-18 17:27:12 +07:00
|
|
|
hwsp = BSD_HWS_PGA_GEN7;
|
2015-02-11 02:32:17 +07:00
|
|
|
break;
|
2019-03-06 01:03:30 +07:00
|
|
|
case VECS0:
|
2018-12-18 17:27:12 +07:00
|
|
|
hwsp = VEBOX_HWS_PGA_GEN7;
|
2015-02-11 02:32:17 +07:00
|
|
|
break;
|
|
|
|
}
|
drm/i915: replace IS_GEN<N> with IS_GEN(..., N)
Define IS_GEN() similarly to our IS_GEN_RANGE(). but use gen instead of
gen_mask to do the comparison. Now callers can pass then gen as a parameter,
so we don't require one macro for each gen.
The following spatch was used to convert the users of these macros:
@@
expression e;
@@
(
- IS_GEN2(e)
+ IS_GEN(e, 2)
|
- IS_GEN3(e)
+ IS_GEN(e, 3)
|
- IS_GEN4(e)
+ IS_GEN(e, 4)
|
- IS_GEN5(e)
+ IS_GEN(e, 5)
|
- IS_GEN6(e)
+ IS_GEN(e, 6)
|
- IS_GEN7(e)
+ IS_GEN(e, 7)
|
- IS_GEN8(e)
+ IS_GEN(e, 8)
|
- IS_GEN9(e)
+ IS_GEN(e, 9)
|
- IS_GEN10(e)
+ IS_GEN(e, 10)
|
- IS_GEN11(e)
+ IS_GEN(e, 11)
)
v2: use IS_GEN rather than GT_GEN and compare to info.gen rather than
using the bitmask
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181212181044.15886-2-lucas.demarchi@intel.com
2018-12-13 01:10:43 +07:00
|
|
|
} else if (IS_GEN(dev_priv, 6)) {
|
2018-12-18 17:27:12 +07:00
|
|
|
hwsp = RING_HWS_PGA_GEN6(engine->mmio_base);
|
2015-02-11 02:32:17 +07:00
|
|
|
} else {
|
2018-12-18 17:27:12 +07:00
|
|
|
hwsp = RING_HWS_PGA(engine->mmio_base);
|
2018-08-08 17:51:00 +07:00
|
|
|
}
|
2017-08-19 01:37:01 +07:00
|
|
|
|
2018-12-18 17:27:12 +07:00
|
|
|
I915_WRITE(hwsp, offset);
|
|
|
|
POSTING_READ(hwsp);
|
|
|
|
}
|
2015-02-11 02:32:17 +07:00
|
|
|
|
2018-12-18 17:27:12 +07:00
|
|
|
static void flush_cs_tlb(struct intel_engine_cs *engine)
|
|
|
|
{
|
|
|
|
struct drm_i915_private *dev_priv = engine->i915;
|
|
|
|
|
|
|
|
if (!IS_GEN_RANGE(dev_priv, 6, 7))
|
|
|
|
return;
|
|
|
|
|
|
|
|
/* ring should be idle before issuing a sync flush*/
|
2019-03-26 04:49:40 +07:00
|
|
|
WARN_ON((ENGINE_READ(engine, RING_MI_MODE) & MODE_IDLE) == 0);
|
|
|
|
|
|
|
|
ENGINE_WRITE(engine, RING_INSTPM,
|
|
|
|
_MASKED_BIT_ENABLE(INSTPM_TLB_INVALIDATE |
|
|
|
|
INSTPM_SYNC_FLUSH));
|
|
|
|
if (intel_wait_for_register(engine->uncore,
|
|
|
|
RING_INSTPM(engine->mmio_base),
|
|
|
|
INSTPM_SYNC_FLUSH, 0,
|
2018-12-18 17:27:12 +07:00
|
|
|
1000))
|
|
|
|
DRM_ERROR("%s: wait for SyncFlush to complete for TLB invalidation timed out\n",
|
|
|
|
engine->name);
|
|
|
|
}
|
2015-02-11 02:32:17 +07:00
|
|
|
|
2018-12-18 17:27:12 +07:00
|
|
|
static void ring_setup_status_page(struct intel_engine_cs *engine)
|
|
|
|
{
|
2019-01-28 17:23:55 +07:00
|
|
|
set_hwsp(engine, i915_ggtt_offset(engine->status_page.vma));
|
2018-12-18 17:27:12 +07:00
|
|
|
set_hwstam(engine, ~0u);
|
2015-02-11 02:32:17 +07:00
|
|
|
|
2018-12-18 17:27:12 +07:00
|
|
|
flush_cs_tlb(engine);
|
2015-02-11 02:32:17 +07:00
|
|
|
}
|
|
|
|
|
2016-03-16 18:00:37 +07:00
|
|
|
static bool stop_ring(struct intel_engine_cs *engine)
|
2010-05-21 08:08:55 +07:00
|
|
|
{
|
2016-05-06 21:40:21 +07:00
|
|
|
struct drm_i915_private *dev_priv = engine->i915;
|
2010-05-21 08:08:55 +07:00
|
|
|
|
2016-08-15 16:49:11 +07:00
|
|
|
if (INTEL_GEN(dev_priv) > 2) {
|
2019-03-26 04:49:40 +07:00
|
|
|
ENGINE_WRITE(engine,
|
|
|
|
RING_MI_MODE, _MASKED_BIT_ENABLE(STOP_RING));
|
|
|
|
if (intel_wait_for_register(engine->uncore,
|
2016-06-30 21:33:30 +07:00
|
|
|
RING_MI_MODE(engine->mmio_base),
|
|
|
|
MODE_IDLE,
|
|
|
|
MODE_IDLE,
|
|
|
|
1000)) {
|
2016-03-16 18:00:37 +07:00
|
|
|
DRM_ERROR("%s : timed out trying to stop ring\n",
|
|
|
|
engine->name);
|
2019-03-26 04:49:40 +07:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Sometimes we observe that the idle flag is not
|
2014-08-11 15:21:35 +07:00
|
|
|
* set even though the ring is empty. So double
|
|
|
|
* check before giving up.
|
|
|
|
*/
|
2019-03-26 04:49:40 +07:00
|
|
|
if (ENGINE_READ(engine, RING_HEAD) !=
|
|
|
|
ENGINE_READ(engine, RING_TAIL))
|
2014-08-11 15:21:35 +07:00
|
|
|
return false;
|
2014-04-02 22:36:07 +07:00
|
|
|
}
|
|
|
|
}
|
2012-06-04 16:18:15 +07:00
|
|
|
|
2019-03-26 04:49:40 +07:00
|
|
|
ENGINE_WRITE(engine, RING_HEAD, ENGINE_READ(engine, RING_TAIL));
|
2017-10-27 16:43:11 +07:00
|
|
|
|
2019-03-26 04:49:40 +07:00
|
|
|
ENGINE_WRITE(engine, RING_HEAD, 0);
|
|
|
|
ENGINE_WRITE(engine, RING_TAIL, 0);
|
2010-05-21 08:08:55 +07:00
|
|
|
|
2017-10-27 16:43:11 +07:00
|
|
|
/* The ring must be empty before it is disabled */
|
2019-03-26 04:49:40 +07:00
|
|
|
ENGINE_WRITE(engine, RING_CTL, 0);
|
2017-10-27 16:43:11 +07:00
|
|
|
|
2019-03-26 04:49:40 +07:00
|
|
|
return (ENGINE_READ(engine, RING_HEAD) & HEAD_ADDR) == 0;
|
2014-04-02 22:36:07 +07:00
|
|
|
}
|
2010-05-21 08:08:55 +07:00
|
|
|
|
drm/i915: Invert the GEM wakeref hierarchy
In the current scheme, on submitting a request we take a single global
GEM wakeref, which trickles down to wake up all GT power domains. This
is undesirable as we would like to be able to localise our power
management to the available power domains and to remove the global GEM
operations from the heart of the driver. (The intent there is to push
global GEM decisions to the boundary as used by the GEM user interface.)
Now during request construction, each request is responsible via its
logical context to acquire a wakeref on each power domain it intends to
utilize. Currently, each request takes a wakeref on the engine(s) and
the engines themselves take a chipset wakeref. This gives us a
transition on each engine which we can extend if we want to insert more
powermangement control (such as soft rc6). The global GEM operations
that currently require a struct_mutex are reduced to listening to pm
events from the chipset GT wakeref. As we reduce the struct_mutex
requirement, these listeners should evaporate.
Perhaps the biggest immediate change is that this removes the
struct_mutex requirement around GT power management, allowing us greater
flexibility in request construction. Another important knock-on effect,
is that by tracking engine usage, we can insert a switch back to the
kernel context on that engine immediately, avoiding any extra delay or
inserting global synchronisation barriers. This makes tracking when an
engine and its associated contexts are idle much easier -- important for
when we forgo our assumed execution ordering and need idle barriers to
unpin used contexts. In the process, it means we remove a large chunk of
code whose only purpose was to switch back to the kernel context.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190424200717.1686-5-chris@chris-wilson.co.uk
2019-04-25 03:07:17 +07:00
|
|
|
static int xcs_resume(struct intel_engine_cs *engine)
|
2014-04-02 22:36:07 +07:00
|
|
|
{
|
2016-05-06 21:40:21 +07:00
|
|
|
struct drm_i915_private *dev_priv = engine->i915;
|
2019-08-10 01:25:18 +07:00
|
|
|
struct intel_ring *ring = engine->legacy.ring;
|
2014-04-02 22:36:07 +07:00
|
|
|
int ret = 0;
|
|
|
|
|
drm/i915: Invert the GEM wakeref hierarchy
In the current scheme, on submitting a request we take a single global
GEM wakeref, which trickles down to wake up all GT power domains. This
is undesirable as we would like to be able to localise our power
management to the available power domains and to remove the global GEM
operations from the heart of the driver. (The intent there is to push
global GEM decisions to the boundary as used by the GEM user interface.)
Now during request construction, each request is responsible via its
logical context to acquire a wakeref on each power domain it intends to
utilize. Currently, each request takes a wakeref on the engine(s) and
the engines themselves take a chipset wakeref. This gives us a
transition on each engine which we can extend if we want to insert more
powermangement control (such as soft rc6). The global GEM operations
that currently require a struct_mutex are reduced to listening to pm
events from the chipset GT wakeref. As we reduce the struct_mutex
requirement, these listeners should evaporate.
Perhaps the biggest immediate change is that this removes the
struct_mutex requirement around GT power management, allowing us greater
flexibility in request construction. Another important knock-on effect,
is that by tracking engine usage, we can insert a switch back to the
kernel context on that engine immediately, avoiding any extra delay or
inserting global synchronisation barriers. This makes tracking when an
engine and its associated contexts are idle much easier -- important for
when we forgo our assumed execution ordering and need idle barriers to
unpin used contexts. In the process, it means we remove a large chunk of
code whose only purpose was to switch back to the kernel context.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190424200717.1686-5-chris@chris-wilson.co.uk
2019-04-25 03:07:17 +07:00
|
|
|
GEM_TRACE("%s: ring:{HEAD:%04x, TAIL:%04x}\n",
|
|
|
|
engine->name, ring->head, ring->tail);
|
|
|
|
|
2019-03-26 04:49:40 +07:00
|
|
|
intel_uncore_forcewake_get(engine->uncore, FORCEWAKE_ALL);
|
2014-04-02 22:36:07 +07:00
|
|
|
|
2019-08-08 14:41:52 +07:00
|
|
|
/* WaClearRingBufHeadRegAtInit:ctg,elk */
|
2016-03-16 18:00:37 +07:00
|
|
|
if (!stop_ring(engine)) {
|
2014-04-02 22:36:07 +07:00
|
|
|
/* G45 ring initialization often fails to reset head to zero */
|
2018-02-07 18:15:45 +07:00
|
|
|
DRM_DEBUG_DRIVER("%s head not reset to zero "
|
|
|
|
"ctl %08x head %08x tail %08x start %08x\n",
|
|
|
|
engine->name,
|
2019-03-26 04:49:40 +07:00
|
|
|
ENGINE_READ(engine, RING_CTL),
|
|
|
|
ENGINE_READ(engine, RING_HEAD),
|
|
|
|
ENGINE_READ(engine, RING_TAIL),
|
|
|
|
ENGINE_READ(engine, RING_START));
|
2010-05-21 08:08:55 +07:00
|
|
|
|
2016-03-16 18:00:37 +07:00
|
|
|
if (!stop_ring(engine)) {
|
2010-12-06 03:42:33 +07:00
|
|
|
DRM_ERROR("failed to set %s head to zero "
|
|
|
|
"ctl %08x head %08x tail %08x start %08x\n",
|
2016-03-16 18:00:37 +07:00
|
|
|
engine->name,
|
2019-03-26 04:49:40 +07:00
|
|
|
ENGINE_READ(engine, RING_CTL),
|
|
|
|
ENGINE_READ(engine, RING_HEAD),
|
|
|
|
ENGINE_READ(engine, RING_TAIL),
|
|
|
|
ENGINE_READ(engine, RING_START));
|
2014-04-02 22:36:07 +07:00
|
|
|
ret = -EIO;
|
|
|
|
goto out;
|
2010-12-06 03:42:33 +07:00
|
|
|
}
|
2010-05-21 08:08:55 +07:00
|
|
|
}
|
|
|
|
|
2016-08-18 02:30:56 +07:00
|
|
|
if (HWS_NEEDS_PHYSICAL(dev_priv))
|
2016-03-16 18:00:37 +07:00
|
|
|
ring_setup_phys_status_page(engine);
|
2016-08-18 02:30:56 +07:00
|
|
|
else
|
2018-12-18 17:27:12 +07:00
|
|
|
ring_setup_status_page(engine);
|
2014-04-02 22:36:07 +07:00
|
|
|
|
2016-10-07 13:53:26 +07:00
|
|
|
intel_engine_reset_breadcrumbs(engine);
|
2016-09-09 20:11:53 +07:00
|
|
|
|
2014-08-07 21:29:53 +07:00
|
|
|
/* Enforce ordering by reading HEAD register back */
|
2019-08-08 14:41:52 +07:00
|
|
|
ENGINE_POSTING_READ(engine, RING_HEAD);
|
2014-08-07 21:29:53 +07:00
|
|
|
|
2019-08-08 14:41:52 +07:00
|
|
|
/*
|
|
|
|
* Initialize the ring. This must happen _after_ we've cleared the ring
|
2012-08-07 14:54:14 +07:00
|
|
|
* registers with the above sequence (the readback of the HEAD registers
|
|
|
|
* also enforces ordering), otherwise the hw might lose the new ring
|
2019-08-08 14:41:52 +07:00
|
|
|
* register values.
|
|
|
|
*/
|
2019-03-26 04:49:40 +07:00
|
|
|
ENGINE_WRITE(engine, RING_START, i915_ggtt_offset(ring->vma));
|
2014-08-07 21:39:54 +07:00
|
|
|
|
2018-06-11 18:08:45 +07:00
|
|
|
/* Check that the ring offsets point within the ring! */
|
|
|
|
GEM_BUG_ON(!intel_ring_offset_valid(ring, ring->head));
|
|
|
|
GEM_BUG_ON(!intel_ring_offset_valid(ring, ring->tail));
|
2016-09-09 20:11:53 +07:00
|
|
|
intel_ring_update_space(ring);
|
2018-11-26 19:28:21 +07:00
|
|
|
|
|
|
|
/* First wake the ring up to an empty/idle ring */
|
2019-03-26 04:49:40 +07:00
|
|
|
ENGINE_WRITE(engine, RING_HEAD, ring->head);
|
|
|
|
ENGINE_WRITE(engine, RING_TAIL, ring->head);
|
|
|
|
ENGINE_POSTING_READ(engine, RING_TAIL);
|
2014-08-07 21:39:54 +07:00
|
|
|
|
2019-03-26 04:49:40 +07:00
|
|
|
ENGINE_WRITE(engine, RING_CTL, RING_CTL_SIZE(ring->size) | RING_VALID);
|
2010-05-21 08:08:55 +07:00
|
|
|
|
|
|
|
/* If the head is still not zero, the ring is dead */
|
2019-03-26 04:49:40 +07:00
|
|
|
if (intel_wait_for_register(engine->uncore,
|
2019-03-26 04:49:39 +07:00
|
|
|
RING_CTL(engine->mmio_base),
|
2017-04-11 17:13:40 +07:00
|
|
|
RING_VALID, RING_VALID,
|
|
|
|
50)) {
|
2010-11-09 17:16:56 +07:00
|
|
|
DRM_ERROR("%s initialization failed "
|
2016-09-09 20:11:53 +07:00
|
|
|
"ctl %08x (valid? %d) head %08x [%08x] tail %08x [%08x] start %08x [expected %08x]\n",
|
2016-03-16 18:00:37 +07:00
|
|
|
engine->name,
|
2019-03-26 04:49:40 +07:00
|
|
|
ENGINE_READ(engine, RING_CTL),
|
|
|
|
ENGINE_READ(engine, RING_CTL) & RING_VALID,
|
|
|
|
ENGINE_READ(engine, RING_HEAD), ring->head,
|
|
|
|
ENGINE_READ(engine, RING_TAIL), ring->tail,
|
|
|
|
ENGINE_READ(engine, RING_START),
|
2016-08-15 16:49:07 +07:00
|
|
|
i915_ggtt_offset(ring->vma));
|
2012-06-04 16:18:15 +07:00
|
|
|
ret = -EIO;
|
|
|
|
goto out;
|
2010-05-21 08:08:55 +07:00
|
|
|
}
|
|
|
|
|
2017-10-13 20:12:17 +07:00
|
|
|
if (INTEL_GEN(dev_priv) > 2)
|
2019-03-26 04:49:40 +07:00
|
|
|
ENGINE_WRITE(engine,
|
|
|
|
RING_MI_MODE, _MASKED_BIT_DISABLE(STOP_RING));
|
2017-10-13 20:12:17 +07:00
|
|
|
|
2018-11-26 19:28:21 +07:00
|
|
|
/* Now awake, let it get started */
|
|
|
|
if (ring->tail != ring->head) {
|
2019-03-26 04:49:40 +07:00
|
|
|
ENGINE_WRITE(engine, RING_TAIL, ring->tail);
|
|
|
|
ENGINE_POSTING_READ(engine, RING_TAIL);
|
2018-11-26 19:28:21 +07:00
|
|
|
}
|
|
|
|
|
2018-08-14 17:40:56 +07:00
|
|
|
/* Papering over lost _interrupts_ immediately following the restart */
|
drm/i915: Replace global breadcrumbs with per-context interrupt tracking
A few years ago, see commit 688e6c725816 ("drm/i915: Slaughter the
thundering i915_wait_request herd"), the issue of handling multiple
clients waiting in parallel was brought to our attention. The
requirement was that every client should be woken immediately upon its
request being signaled, without incurring any cpu overhead.
To handle certain fragility of our hw meant that we could not do a
simple check inside the irq handler (some generations required almost
unbounded delays before we could be sure of seqno coherency) and so
request completion checking required delegation.
Before commit 688e6c725816, the solution was simple. Every client
waiting on a request would be woken on every interrupt and each would do
a heavyweight check to see if their request was complete. Commit
688e6c725816 introduced an rbtree so that only the earliest waiter on
the global timeline would woken, and would wake the next and so on.
(Along with various complications to handle requests being reordered
along the global timeline, and also a requirement for kthread to provide
a delegate for fence signaling that had no process context.)
The global rbtree depends on knowing the execution timeline (and global
seqno). Without knowing that order, we must instead check all contexts
queued to the HW to see which may have advanced. We trim that list by
only checking queued contexts that are being waited on, but still we
keep a list of all active contexts and their active signalers that we
inspect from inside the irq handler. By moving the waiters onto the fence
signal list, we can combine the client wakeup with the dma_fence
signaling (a dramatic reduction in complexity, but does require the HW
being coherent, the seqno must be visible from the cpu before the
interrupt is raised - we keep a timer backup just in case).
Having previously fixed all the issues with irq-seqno serialisation (by
inserting delays onto the GPU after each request instead of random delays
on the CPU after each interrupt), we can rely on the seqno state to
perfom direct wakeups from the interrupt handler. This allows us to
preserve our single context switch behaviour of the current routine,
with the only downside that we lose the RT priority sorting of wakeups.
In general, direct wakeup latency of multiple clients is about the same
(about 10% better in most cases) with a reduction in total CPU time spent
in the waiter (about 20-50% depending on gen). Average herd behaviour is
improved, but at the cost of not delegating wakeups on task_prio.
v2: Capture fence signaling state for error state and add comments to
warm even the most cold of hearts.
v3: Check if the request is still active before busywaiting
v4: Reduce the amount of pointer misdirection with list_for_each_safe
and using a local i915_request variable inside the loops
v5: Add a missing pluralisation to a purely informative selftest message.
References: 688e6c725816 ("drm/i915: Slaughter the thundering i915_wait_request herd")
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190129205230.19056-2-chris@chris-wilson.co.uk
2019-01-30 03:52:29 +07:00
|
|
|
intel_engine_queue_breadcrumbs(engine);
|
2012-06-04 16:18:15 +07:00
|
|
|
out:
|
2019-03-26 04:49:40 +07:00
|
|
|
intel_uncore_forcewake_put(engine->uncore, FORCEWAKE_ALL);
|
2012-06-04 16:18:15 +07:00
|
|
|
|
|
|
|
return ret;
|
2010-05-21 08:08:55 +07:00
|
|
|
}
|
|
|
|
|
2019-01-25 20:22:28 +07:00
|
|
|
static void reset_prepare(struct intel_engine_cs *engine)
|
2016-09-09 20:11:53 +07:00
|
|
|
{
|
2019-07-16 19:49:28 +07:00
|
|
|
struct intel_uncore *uncore = engine->uncore;
|
|
|
|
const u32 base = engine->mmio_base;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* We stop engines, otherwise we might get failed reset and a
|
|
|
|
* dead gpu (on elk). Also as modern gpu as kbl can suffer
|
|
|
|
* from system hang if batchbuffer is progressing when
|
|
|
|
* the reset is issued, regardless of READY_TO_RESET ack.
|
|
|
|
* Thus assume it is best to stop engines on all gens
|
|
|
|
* where we have a gpu reset.
|
|
|
|
*
|
|
|
|
* WaKBLVECSSemaphoreWaitPoll:kbl (on ALL_ENGINES)
|
|
|
|
*
|
|
|
|
* WaMediaResetMainRingCleanup:ctg,elk (presumably)
|
|
|
|
*
|
|
|
|
* FIXME: Wa for more modern gens needs to be validated
|
|
|
|
*/
|
|
|
|
GEM_TRACE("%s\n", engine->name);
|
|
|
|
|
|
|
|
if (intel_engine_stop_cs(engine))
|
|
|
|
GEM_TRACE("%s: timed out on STOP_RING\n", engine->name);
|
|
|
|
|
|
|
|
intel_uncore_write_fw(uncore,
|
|
|
|
RING_HEAD(base),
|
|
|
|
intel_uncore_read_fw(uncore, RING_TAIL(base)));
|
|
|
|
intel_uncore_posting_read_fw(uncore, RING_HEAD(base)); /* paranoia */
|
|
|
|
|
|
|
|
intel_uncore_write_fw(uncore, RING_HEAD(base), 0);
|
|
|
|
intel_uncore_write_fw(uncore, RING_TAIL(base), 0);
|
|
|
|
intel_uncore_posting_read_fw(uncore, RING_TAIL(base));
|
|
|
|
|
|
|
|
/* The ring must be empty before it is disabled */
|
|
|
|
intel_uncore_write_fw(uncore, RING_CTL(base), 0);
|
|
|
|
|
|
|
|
/* Check acts as a post */
|
|
|
|
if (intel_uncore_read_fw(uncore, RING_HEAD(base)))
|
|
|
|
GEM_TRACE("%s: ring head [%x] not parked\n",
|
|
|
|
engine->name,
|
|
|
|
intel_uncore_read_fw(uncore, RING_HEAD(base)));
|
2018-05-17 01:33:51 +07:00
|
|
|
}
|
|
|
|
|
2019-01-25 20:22:28 +07:00
|
|
|
static void reset_ring(struct intel_engine_cs *engine, bool stalled)
|
2018-05-17 01:33:51 +07:00
|
|
|
{
|
2019-01-25 20:22:28 +07:00
|
|
|
struct i915_request *pos, *rq;
|
|
|
|
unsigned long flags;
|
2018-06-11 18:08:44 +07:00
|
|
|
u32 head;
|
2018-05-17 01:33:51 +07:00
|
|
|
|
2019-01-25 20:22:28 +07:00
|
|
|
rq = NULL;
|
2019-06-14 23:46:06 +07:00
|
|
|
spin_lock_irqsave(&engine->active.lock, flags);
|
|
|
|
list_for_each_entry(pos, &engine->active.requests, sched.link) {
|
2019-01-29 01:18:11 +07:00
|
|
|
if (!i915_request_completed(pos)) {
|
2019-01-25 20:22:28 +07:00
|
|
|
rq = pos;
|
|
|
|
break;
|
|
|
|
}
|
2018-06-11 18:08:44 +07:00
|
|
|
}
|
2017-10-09 18:03:01 +07:00
|
|
|
|
|
|
|
/*
|
2019-01-25 20:22:28 +07:00
|
|
|
* The guilty request will get skipped on a hung engine.
|
2017-02-07 22:24:37 +07:00
|
|
|
*
|
2019-01-25 20:22:28 +07:00
|
|
|
* Users of client default contexts do not rely on logical
|
|
|
|
* state preserved between batches so it is safe to execute
|
|
|
|
* queued requests following the hang. Non default contexts
|
|
|
|
* rely on preserved state, so skipping a batch loses the
|
|
|
|
* evolution of the state and it needs to be considered corrupted.
|
|
|
|
* Executing more queued batches on top of corrupted state is
|
|
|
|
* risky. But we take the risk by trying to advance through
|
|
|
|
* the queued requests in order to make the client behaviour
|
|
|
|
* more predictable around resets, by not throwing away random
|
|
|
|
* amount of batches it has prepared for execution. Sophisticated
|
|
|
|
* clients can use gem_reset_stats_ioctl and dma fence status
|
|
|
|
* (exported via sync_file info ioctl on explicit fences) to observe
|
|
|
|
* when it loses the context state and should rebuild accordingly.
|
2017-02-07 22:24:37 +07:00
|
|
|
*
|
2019-01-25 20:22:28 +07:00
|
|
|
* The context ban, and ultimately the client ban, mechanism are safety
|
|
|
|
* valves if client submission ends up resulting in nothing more than
|
|
|
|
* subsequent hangs.
|
2017-02-07 22:24:37 +07:00
|
|
|
*/
|
2019-01-25 20:22:28 +07:00
|
|
|
|
2018-06-11 18:08:44 +07:00
|
|
|
if (rq) {
|
2019-01-25 20:22:28 +07:00
|
|
|
/*
|
|
|
|
* Try to restore the logical GPU state to match the
|
|
|
|
* continuation of the request queue. If we skip the
|
|
|
|
* context/PD restore, then the next request may try to execute
|
|
|
|
* assuming that its context is valid and loaded on the GPU and
|
|
|
|
* so may try to access invalid memory, prompting repeated GPU
|
|
|
|
* hangs.
|
|
|
|
*
|
|
|
|
* If the request was guilty, we still restore the logical
|
|
|
|
* state in case the next request requires it (e.g. the
|
|
|
|
* aliasing ppgtt), but skip over the hung batch.
|
|
|
|
*
|
|
|
|
* If the request was innocent, we try to replay the request
|
|
|
|
* with the restored context.
|
|
|
|
*/
|
2019-07-13 02:29:53 +07:00
|
|
|
__i915_request_reset(rq, stalled);
|
2019-01-25 20:22:28 +07:00
|
|
|
|
2019-08-10 01:25:18 +07:00
|
|
|
GEM_BUG_ON(rq->ring != engine->legacy.ring);
|
2019-01-25 20:22:28 +07:00
|
|
|
head = rq->head;
|
|
|
|
} else {
|
2019-08-10 01:25:18 +07:00
|
|
|
head = engine->legacy.ring->tail;
|
2017-02-07 22:24:37 +07:00
|
|
|
}
|
2019-08-10 01:25:18 +07:00
|
|
|
engine->legacy.ring->head = intel_ring_wrap(engine->legacy.ring, head);
|
2019-01-25 20:22:28 +07:00
|
|
|
|
2019-06-14 23:46:06 +07:00
|
|
|
spin_unlock_irqrestore(&engine->active.lock, flags);
|
2016-09-09 20:11:53 +07:00
|
|
|
}
|
|
|
|
|
2018-05-17 01:33:51 +07:00
|
|
|
static void reset_finish(struct intel_engine_cs *engine)
|
|
|
|
{
|
|
|
|
}
|
|
|
|
|
drm/i915: Invert the GEM wakeref hierarchy
In the current scheme, on submitting a request we take a single global
GEM wakeref, which trickles down to wake up all GT power domains. This
is undesirable as we would like to be able to localise our power
management to the available power domains and to remove the global GEM
operations from the heart of the driver. (The intent there is to push
global GEM decisions to the boundary as used by the GEM user interface.)
Now during request construction, each request is responsible via its
logical context to acquire a wakeref on each power domain it intends to
utilize. Currently, each request takes a wakeref on the engine(s) and
the engines themselves take a chipset wakeref. This gives us a
transition on each engine which we can extend if we want to insert more
powermangement control (such as soft rc6). The global GEM operations
that currently require a struct_mutex are reduced to listening to pm
events from the chipset GT wakeref. As we reduce the struct_mutex
requirement, these listeners should evaporate.
Perhaps the biggest immediate change is that this removes the
struct_mutex requirement around GT power management, allowing us greater
flexibility in request construction. Another important knock-on effect,
is that by tracking engine usage, we can insert a switch back to the
kernel context on that engine immediately, avoiding any extra delay or
inserting global synchronisation barriers. This makes tracking when an
engine and its associated contexts are idle much easier -- important for
when we forgo our assumed execution ordering and need idle barriers to
unpin used contexts. In the process, it means we remove a large chunk of
code whose only purpose was to switch back to the kernel context.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190424200717.1686-5-chris@chris-wilson.co.uk
2019-04-25 03:07:17 +07:00
|
|
|
static int rcs_resume(struct intel_engine_cs *engine)
|
2010-05-21 08:08:55 +07:00
|
|
|
{
|
2016-05-06 21:40:21 +07:00
|
|
|
struct drm_i915_private *dev_priv = engine->i915;
|
2010-08-30 15:12:42 +07:00
|
|
|
|
drm/i915: Enable render context support for gen4 (Broadwater to Cantiga)
Broadwater and the rest of gen4 do support being able to saving and
reloading context specific registers between contexts, providing isolation
of the basic GPU state (as programmable by userspace). This allows
userspace to assume that the GPU retains their state from one batch to the
next, minimising the amount of state it needs to reload and manually save
across batches.
v2: CONSTANT_BUFFER woes
Running through piglit turned up an interesting issue, a GPU hang inside
the context load. The context image includes the CONSTANT_BUFFER command
that loads an address into a on-gpu buffer, and the context load was
executing that immediately. However, since it was reading from the GTT
there is no guarantee that the GTT retains the same configuration as
when the context was saved, resulting in stray reads and a GPU hang.
Having tried issuing a CONSTANT_BUFFER (to disable the command) from the
ring before saving the context to no avail, we resort to patching out
the instruction inside the context image before loading.
This does impose that gen4 always reissues CONSTANT_BUFFER commands on
each batch, but due to the use of a shared GTT that was and will remain
a requirement.
v3: ECOSKPD to the rescue
Ville found the magic bit in the ECOSKPD to disable saving and restoring
the CONSTANT_BUFFER from the context image, thereby completely avoiding
the GPU hangs from chasing invalid pointers. This appears to be the
default behaviour for gen5, and so we just need to tweak gen4 to match.
v4: Fix spelling of ECOSKPD and discover it already exists
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20190419172720.5462-1-chris@chris-wilson.co.uk
2019-04-20 00:27:20 +07:00
|
|
|
/*
|
|
|
|
* Disable CONSTANT_BUFFER before it is loaded from the context
|
|
|
|
* image. For as it is loaded, it is executed and the stored
|
|
|
|
* address may no longer be valid, leading to a GPU hang.
|
|
|
|
*
|
|
|
|
* This imposes the requirement that userspace reload their
|
|
|
|
* CONSTANT_BUFFER on every batch, fortunately a requirement
|
|
|
|
* they are already accustomed to from before contexts were
|
|
|
|
* enabled.
|
|
|
|
*/
|
|
|
|
if (IS_GEN(dev_priv, 4))
|
|
|
|
I915_WRITE(ECOSKPD,
|
|
|
|
_MASKED_BIT_ENABLE(ECO_CONSTANT_BUFFER_SR_DISABLE));
|
|
|
|
|
2014-03-25 19:31:50 +07:00
|
|
|
/* WaTimedSingleVertexDispatch:cl,bw,ctg,elk,ilk,snb */
|
2018-12-13 01:10:42 +07:00
|
|
|
if (IS_GEN_RANGE(dev_priv, 4, 6))
|
2012-04-24 19:04:12 +07:00
|
|
|
I915_WRITE(MI_MODE, _MASKED_BIT_ENABLE(VS_TIMER_DISPATCH));
|
2013-01-20 23:11:20 +07:00
|
|
|
|
|
|
|
/* We need to disable the AsyncFlip performance optimisations in order
|
|
|
|
* to use MI_WAIT_FOR_EVENT within the CS. It should already be
|
|
|
|
* programmed to '1' on all products.
|
2013-05-04 00:48:11 +07:00
|
|
|
*
|
2015-06-02 19:37:37 +07:00
|
|
|
* WaDisableAsyncFlipPerfMode:snb,ivb,hsw,vlv
|
2013-01-20 23:11:20 +07:00
|
|
|
*/
|
2018-12-13 01:10:42 +07:00
|
|
|
if (IS_GEN_RANGE(dev_priv, 6, 7))
|
2013-01-20 23:11:20 +07:00
|
|
|
I915_WRITE(MI_MODE, _MASKED_BIT_ENABLE(ASYNC_FLIP_PERF_DISABLE));
|
|
|
|
|
2013-01-20 23:33:32 +07:00
|
|
|
/* Required for the hardware to program scanline values for waiting */
|
2014-03-25 00:30:04 +07:00
|
|
|
/* WaEnableFlushTlbInvalidationMode:snb */
|
drm/i915: replace IS_GEN<N> with IS_GEN(..., N)
Define IS_GEN() similarly to our IS_GEN_RANGE(). but use gen instead of
gen_mask to do the comparison. Now callers can pass then gen as a parameter,
so we don't require one macro for each gen.
The following spatch was used to convert the users of these macros:
@@
expression e;
@@
(
- IS_GEN2(e)
+ IS_GEN(e, 2)
|
- IS_GEN3(e)
+ IS_GEN(e, 3)
|
- IS_GEN4(e)
+ IS_GEN(e, 4)
|
- IS_GEN5(e)
+ IS_GEN(e, 5)
|
- IS_GEN6(e)
+ IS_GEN(e, 6)
|
- IS_GEN7(e)
+ IS_GEN(e, 7)
|
- IS_GEN8(e)
+ IS_GEN(e, 8)
|
- IS_GEN9(e)
+ IS_GEN(e, 9)
|
- IS_GEN10(e)
+ IS_GEN(e, 10)
|
- IS_GEN11(e)
+ IS_GEN(e, 11)
)
v2: use IS_GEN rather than GT_GEN and compare to info.gen rather than
using the bitmask
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181212181044.15886-2-lucas.demarchi@intel.com
2018-12-13 01:10:43 +07:00
|
|
|
if (IS_GEN(dev_priv, 6))
|
2013-01-20 23:33:32 +07:00
|
|
|
I915_WRITE(GFX_MODE,
|
2014-03-22 00:18:54 +07:00
|
|
|
_MASKED_BIT_ENABLE(GFX_TLB_INVALIDATE_EXPLICIT));
|
2013-01-20 23:33:32 +07:00
|
|
|
|
2014-03-25 00:30:04 +07:00
|
|
|
/* WaBCSVCSTlbInvalidationMode:ivb,vlv,hsw */
|
drm/i915: replace IS_GEN<N> with IS_GEN(..., N)
Define IS_GEN() similarly to our IS_GEN_RANGE(). but use gen instead of
gen_mask to do the comparison. Now callers can pass then gen as a parameter,
so we don't require one macro for each gen.
The following spatch was used to convert the users of these macros:
@@
expression e;
@@
(
- IS_GEN2(e)
+ IS_GEN(e, 2)
|
- IS_GEN3(e)
+ IS_GEN(e, 3)
|
- IS_GEN4(e)
+ IS_GEN(e, 4)
|
- IS_GEN5(e)
+ IS_GEN(e, 5)
|
- IS_GEN6(e)
+ IS_GEN(e, 6)
|
- IS_GEN7(e)
+ IS_GEN(e, 7)
|
- IS_GEN8(e)
+ IS_GEN(e, 8)
|
- IS_GEN9(e)
+ IS_GEN(e, 9)
|
- IS_GEN10(e)
+ IS_GEN(e, 10)
|
- IS_GEN11(e)
+ IS_GEN(e, 11)
)
v2: use IS_GEN rather than GT_GEN and compare to info.gen rather than
using the bitmask
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181212181044.15886-2-lucas.demarchi@intel.com
2018-12-13 01:10:43 +07:00
|
|
|
if (IS_GEN(dev_priv, 7))
|
2013-01-20 23:11:20 +07:00
|
|
|
I915_WRITE(GFX_MODE_GEN7,
|
2014-03-25 00:30:04 +07:00
|
|
|
_MASKED_BIT_ENABLE(GFX_TLB_INVALIDATE_EXPLICIT) |
|
2013-01-20 23:11:20 +07:00
|
|
|
_MASKED_BIT_ENABLE(GFX_REPLAY_MODE));
|
2010-10-27 18:18:21 +07:00
|
|
|
|
drm/i915: replace IS_GEN<N> with IS_GEN(..., N)
Define IS_GEN() similarly to our IS_GEN_RANGE(). but use gen instead of
gen_mask to do the comparison. Now callers can pass then gen as a parameter,
so we don't require one macro for each gen.
The following spatch was used to convert the users of these macros:
@@
expression e;
@@
(
- IS_GEN2(e)
+ IS_GEN(e, 2)
|
- IS_GEN3(e)
+ IS_GEN(e, 3)
|
- IS_GEN4(e)
+ IS_GEN(e, 4)
|
- IS_GEN5(e)
+ IS_GEN(e, 5)
|
- IS_GEN6(e)
+ IS_GEN(e, 6)
|
- IS_GEN7(e)
+ IS_GEN(e, 7)
|
- IS_GEN8(e)
+ IS_GEN(e, 8)
|
- IS_GEN9(e)
+ IS_GEN(e, 9)
|
- IS_GEN10(e)
+ IS_GEN(e, 10)
|
- IS_GEN11(e)
+ IS_GEN(e, 11)
)
v2: use IS_GEN rather than GT_GEN and compare to info.gen rather than
using the bitmask
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181212181044.15886-2-lucas.demarchi@intel.com
2018-12-13 01:10:43 +07:00
|
|
|
if (IS_GEN(dev_priv, 6)) {
|
2012-04-28 02:44:41 +07:00
|
|
|
/* From the Sandybridge PRM, volume 1 part 3, page 24:
|
|
|
|
* "If this bit is set, STCunit will have LRA as replacement
|
|
|
|
* policy. [...] This bit must be reset. LRA replacement
|
|
|
|
* policy is not supported."
|
|
|
|
*/
|
|
|
|
I915_WRITE(CACHE_MODE_0,
|
2012-05-08 18:39:59 +07:00
|
|
|
_MASKED_BIT_DISABLE(CM0_STC_EVICT_DISABLE_LRA_SNB));
|
2011-12-13 10:21:58 +07:00
|
|
|
}
|
|
|
|
|
2018-12-13 01:10:42 +07:00
|
|
|
if (IS_GEN_RANGE(dev_priv, 6, 7))
|
2012-04-24 19:04:12 +07:00
|
|
|
I915_WRITE(INSTPM, _MASKED_BIT_ENABLE(INSTPM_FORCE_ORDERING));
|
2011-12-13 10:21:58 +07:00
|
|
|
|
drm/i915: Invert the GEM wakeref hierarchy
In the current scheme, on submitting a request we take a single global
GEM wakeref, which trickles down to wake up all GT power domains. This
is undesirable as we would like to be able to localise our power
management to the available power domains and to remove the global GEM
operations from the heart of the driver. (The intent there is to push
global GEM decisions to the boundary as used by the GEM user interface.)
Now during request construction, each request is responsible via its
logical context to acquire a wakeref on each power domain it intends to
utilize. Currently, each request takes a wakeref on the engine(s) and
the engines themselves take a chipset wakeref. This gives us a
transition on each engine which we can extend if we want to insert more
powermangement control (such as soft rc6). The global GEM operations
that currently require a struct_mutex are reduced to listening to pm
events from the chipset GT wakeref. As we reduce the struct_mutex
requirement, these listeners should evaporate.
Perhaps the biggest immediate change is that this removes the
struct_mutex requirement around GT power management, allowing us greater
flexibility in request construction. Another important knock-on effect,
is that by tracking engine usage, we can insert a switch back to the
kernel context on that engine immediately, avoiding any extra delay or
inserting global synchronisation barriers. This makes tracking when an
engine and its associated contexts are idle much easier -- important for
when we forgo our assumed execution ordering and need idle barriers to
unpin used contexts. In the process, it means we remove a large chunk of
code whose only purpose was to switch back to the kernel context.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190424200717.1686-5-chris@chris-wilson.co.uk
2019-04-25 03:07:17 +07:00
|
|
|
return xcs_resume(engine);
|
2010-05-21 08:08:55 +07:00
|
|
|
}
|
|
|
|
|
2017-09-16 00:31:00 +07:00
|
|
|
static void cancel_requests(struct intel_engine_cs *engine)
|
|
|
|
{
|
2018-02-21 16:56:36 +07:00
|
|
|
struct i915_request *request;
|
2017-09-16 00:31:00 +07:00
|
|
|
unsigned long flags;
|
|
|
|
|
2019-06-14 23:46:06 +07:00
|
|
|
spin_lock_irqsave(&engine->active.lock, flags);
|
2017-09-16 00:31:00 +07:00
|
|
|
|
|
|
|
/* Mark all submitted requests as skipped. */
|
2019-06-14 23:46:06 +07:00
|
|
|
list_for_each_entry(request, &engine->active.requests, sched.link) {
|
2019-01-29 01:18:11 +07:00
|
|
|
if (!i915_request_signaled(request))
|
|
|
|
dma_fence_set_error(&request->fence, -EIO);
|
2018-12-03 18:36:55 +07:00
|
|
|
|
2019-01-29 01:18:11 +07:00
|
|
|
i915_request_mark_complete(request);
|
2017-09-16 00:31:00 +07:00
|
|
|
}
|
2018-12-03 18:36:55 +07:00
|
|
|
|
2017-09-16 00:31:00 +07:00
|
|
|
/* Remaining _unready_ requests will be nop'ed when submitted */
|
|
|
|
|
2019-06-14 23:46:06 +07:00
|
|
|
spin_unlock_irqrestore(&engine->active.lock, flags);
|
2017-09-16 00:31:00 +07:00
|
|
|
}
|
|
|
|
|
2018-02-21 16:56:36 +07:00
|
|
|
static void i9xx_submit_request(struct i915_request *request)
|
2016-08-03 04:50:34 +07:00
|
|
|
{
|
2018-02-21 16:56:36 +07:00
|
|
|
i915_request_submit(request);
|
2019-09-09 18:30:18 +07:00
|
|
|
wmb(); /* paranoid flush writes out of the WCB before mmio */
|
2016-11-15 03:40:59 +07:00
|
|
|
|
2019-03-26 04:49:40 +07:00
|
|
|
ENGINE_WRITE(request->engine, RING_TAIL,
|
|
|
|
intel_ring_set_tail(request->ring, request->tail));
|
2016-08-03 04:50:34 +07:00
|
|
|
}
|
|
|
|
|
2019-01-25 17:05:20 +07:00
|
|
|
static u32 *i9xx_emit_breadcrumb(struct i915_request *rq, u32 *cs)
|
2010-12-04 18:30:53 +07:00
|
|
|
{
|
drm/i915: Mark i915_request.timeline as a volatile, rcu pointer
The request->timeline is only valid until the request is retired (i.e.
before it is completed). Upon retiring the request, the context may be
unpinned and freed, and along with it the timeline may be freed. We
therefore need to be very careful when chasing rq->timeline that the
pointer does not disappear beneath us. The vast majority of users are in
a protected context, either during request construction or retirement,
where the timeline->mutex is held and the timeline cannot disappear. It
is those few off the beaten path (where we access a second timeline) that
need extra scrutiny -- to be added in the next patch after first adding
the warnings about dangerous access.
One complication, where we cannot use the timeline->mutex itself, is
during request submission onto hardware (under spinlocks). Here, we want
to check on the timeline to finalize the breadcrumb, and so we need to
impose a second rule to ensure that the request->timeline is indeed
valid. As we are submitting the request, it's context and timeline must
be pinned, as it will be used by the hardware. Since it is pinned, we
know the request->timeline must still be valid, and we cannot submit the
idle barrier until after we release the engine->active.lock, ergo while
submitting and holding that spinlock, a second thread cannot release the
timeline.
v2: Don't be lazy inside selftests; hold the timeline->mutex for as long
as we need it, and tidy up acquiring the timeline with a bit of
refactoring (i915_active_add_request)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190919111912.21631-1-chris@chris-wilson.co.uk
2019-09-19 18:19:10 +07:00
|
|
|
GEM_BUG_ON(i915_request_active_timeline(rq)->hwsp_ggtt != rq->engine->status_page.vma);
|
|
|
|
GEM_BUG_ON(offset_in_page(i915_request_active_timeline(rq)->hwsp_offset) != I915_GEM_HWS_SEQNO_ADDR);
|
2019-01-29 01:18:11 +07:00
|
|
|
|
2018-12-28 22:31:14 +07:00
|
|
|
*cs++ = MI_FLUSH;
|
|
|
|
|
2019-01-29 01:18:11 +07:00
|
|
|
*cs++ = MI_STORE_DWORD_INDEX;
|
|
|
|
*cs++ = I915_GEM_HWS_SEQNO_ADDR;
|
|
|
|
*cs++ = rq->fence.seqno;
|
|
|
|
|
2017-02-14 18:32:42 +07:00
|
|
|
*cs++ = MI_USER_INTERRUPT;
|
2019-05-08 15:06:25 +07:00
|
|
|
*cs++ = MI_NOOP;
|
2010-12-04 18:30:53 +07:00
|
|
|
|
2018-02-21 16:56:36 +07:00
|
|
|
rq->tail = intel_ring_offset(rq, cs);
|
|
|
|
assert_ring_tail_valid(rq->ring, rq->tail);
|
2019-01-25 17:05:20 +07:00
|
|
|
|
|
|
|
return cs;
|
2010-12-04 18:30:53 +07:00
|
|
|
}
|
2016-10-28 19:58:51 +07:00
|
|
|
|
2018-12-29 00:16:40 +07:00
|
|
|
#define GEN5_WA_STORES 8 /* must be at least 1! */
|
2019-01-25 17:05:20 +07:00
|
|
|
static u32 *gen5_emit_breadcrumb(struct i915_request *rq, u32 *cs)
|
2010-12-15 16:56:50 +07:00
|
|
|
{
|
2018-12-29 00:16:40 +07:00
|
|
|
int i;
|
|
|
|
|
drm/i915: Mark i915_request.timeline as a volatile, rcu pointer
The request->timeline is only valid until the request is retired (i.e.
before it is completed). Upon retiring the request, the context may be
unpinned and freed, and along with it the timeline may be freed. We
therefore need to be very careful when chasing rq->timeline that the
pointer does not disappear beneath us. The vast majority of users are in
a protected context, either during request construction or retirement,
where the timeline->mutex is held and the timeline cannot disappear. It
is those few off the beaten path (where we access a second timeline) that
need extra scrutiny -- to be added in the next patch after first adding
the warnings about dangerous access.
One complication, where we cannot use the timeline->mutex itself, is
during request submission onto hardware (under spinlocks). Here, we want
to check on the timeline to finalize the breadcrumb, and so we need to
impose a second rule to ensure that the request->timeline is indeed
valid. As we are submitting the request, it's context and timeline must
be pinned, as it will be used by the hardware. Since it is pinned, we
know the request->timeline must still be valid, and we cannot submit the
idle barrier until after we release the engine->active.lock, ergo while
submitting and holding that spinlock, a second thread cannot release the
timeline.
v2: Don't be lazy inside selftests; hold the timeline->mutex for as long
as we need it, and tidy up acquiring the timeline with a bit of
refactoring (i915_active_add_request)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190919111912.21631-1-chris@chris-wilson.co.uk
2019-09-19 18:19:10 +07:00
|
|
|
GEM_BUG_ON(i915_request_active_timeline(rq)->hwsp_ggtt != rq->engine->status_page.vma);
|
|
|
|
GEM_BUG_ON(offset_in_page(i915_request_active_timeline(rq)->hwsp_offset) != I915_GEM_HWS_SEQNO_ADDR);
|
2019-01-29 01:18:11 +07:00
|
|
|
|
2018-12-29 00:16:40 +07:00
|
|
|
*cs++ = MI_FLUSH;
|
|
|
|
|
|
|
|
BUILD_BUG_ON(GEN5_WA_STORES < 1);
|
|
|
|
for (i = 0; i < GEN5_WA_STORES; i++) {
|
|
|
|
*cs++ = MI_STORE_DWORD_INDEX;
|
2019-02-26 16:49:21 +07:00
|
|
|
*cs++ = I915_GEM_HWS_SEQNO_ADDR;
|
|
|
|
*cs++ = rq->fence.seqno;
|
2018-12-29 00:16:40 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
*cs++ = MI_USER_INTERRUPT;
|
|
|
|
|
|
|
|
rq->tail = intel_ring_offset(rq, cs);
|
|
|
|
assert_ring_tail_valid(rq->ring, rq->tail);
|
2019-01-25 17:05:20 +07:00
|
|
|
|
|
|
|
return cs;
|
2010-12-15 16:56:50 +07:00
|
|
|
}
|
2018-12-29 00:16:40 +07:00
|
|
|
#undef GEN5_WA_STORES
|
2010-12-15 16:56:50 +07:00
|
|
|
|
2016-07-01 23:23:27 +07:00
|
|
|
static void
|
|
|
|
gen5_irq_enable(struct intel_engine_cs *engine)
|
2012-04-12 03:12:54 +07:00
|
|
|
{
|
2019-08-12 04:06:33 +07:00
|
|
|
gen5_gt_enable_irq(engine->gt, engine->irq_enable_mask);
|
2012-04-12 03:12:54 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2016-07-01 23:23:27 +07:00
|
|
|
gen5_irq_disable(struct intel_engine_cs *engine)
|
2012-04-12 03:12:54 +07:00
|
|
|
{
|
2019-08-12 04:06:33 +07:00
|
|
|
gen5_gt_disable_irq(engine->gt, engine->irq_enable_mask);
|
2012-04-12 03:12:54 +07:00
|
|
|
}
|
|
|
|
|
2016-07-01 23:23:27 +07:00
|
|
|
static void
|
|
|
|
i9xx_irq_enable(struct intel_engine_cs *engine)
|
2010-05-22 03:26:39 +07:00
|
|
|
{
|
2019-03-26 04:49:40 +07:00
|
|
|
engine->i915->irq_mask &= ~engine->irq_enable_mask;
|
drm/i915: add GEN2_ prefix to the I{E, I, M, S}R registers
This discussion started because we use token pasting in the
GEN{2,3}_IRQ_INIT and GEN{2,3}_IRQ_RESET macros, so gen2-4 passes an
empty argument to those macros, making the code a little weird. The
original proposal was to just add a comment as the empty argument, but
Ville suggested we just add a prefix to the registers, and that indeed
sounds like a more elegant solution.
Now doing this is kinda against our rules for register naming since we
only add gens or platform names as register prefixes when the given
gen/platform changes a register that already existed before. On the
other hand, we have so many instances of IIR/IMR in comments that
adding a prefix would make the users of these register more easily
findable, in addition to make our token pasting macros actually
readable. So IMHO opening an exception here is worth it.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190410235344.31199-4-paulo.r.zanoni@intel.com
2019-04-11 06:53:42 +07:00
|
|
|
intel_uncore_write(engine->uncore, GEN2_IMR, engine->i915->irq_mask);
|
|
|
|
intel_uncore_posting_read_fw(engine->uncore, GEN2_IMR);
|
2010-05-22 03:26:39 +07:00
|
|
|
}
|
|
|
|
|
2010-05-21 08:08:55 +07:00
|
|
|
static void
|
2016-07-01 23:23:27 +07:00
|
|
|
i9xx_irq_disable(struct intel_engine_cs *engine)
|
2010-05-22 03:26:39 +07:00
|
|
|
{
|
2019-03-26 04:49:40 +07:00
|
|
|
engine->i915->irq_mask |= engine->irq_enable_mask;
|
drm/i915: add GEN2_ prefix to the I{E, I, M, S}R registers
This discussion started because we use token pasting in the
GEN{2,3}_IRQ_INIT and GEN{2,3}_IRQ_RESET macros, so gen2-4 passes an
empty argument to those macros, making the code a little weird. The
original proposal was to just add a comment as the empty argument, but
Ville suggested we just add a prefix to the registers, and that indeed
sounds like a more elegant solution.
Now doing this is kinda against our rules for register naming since we
only add gens or platform names as register prefixes when the given
gen/platform changes a register that already existed before. On the
other hand, we have so many instances of IIR/IMR in comments that
adding a prefix would make the users of these register more easily
findable, in addition to make our token pasting macros actually
readable. So IMHO opening an exception here is worth it.
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com>
Reviewed-by: Ville Syrjälä <ville.syrjala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190410235344.31199-4-paulo.r.zanoni@intel.com
2019-04-11 06:53:42 +07:00
|
|
|
intel_uncore_write(engine->uncore, GEN2_IMR, engine->i915->irq_mask);
|
2010-05-22 03:26:39 +07:00
|
|
|
}
|
|
|
|
|
2016-07-01 23:23:27 +07:00
|
|
|
static void
|
|
|
|
i8xx_irq_enable(struct intel_engine_cs *engine)
|
2012-04-23 03:13:57 +07:00
|
|
|
{
|
2019-06-11 17:45:45 +07:00
|
|
|
struct drm_i915_private *i915 = engine->i915;
|
2012-04-23 03:13:57 +07:00
|
|
|
|
2019-06-11 17:45:45 +07:00
|
|
|
i915->irq_mask &= ~engine->irq_enable_mask;
|
|
|
|
intel_uncore_write16(&i915->uncore, GEN2_IMR, i915->irq_mask);
|
|
|
|
ENGINE_POSTING_READ16(engine, RING_IMR);
|
2012-04-23 03:13:57 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2016-07-01 23:23:27 +07:00
|
|
|
i8xx_irq_disable(struct intel_engine_cs *engine)
|
2012-04-23 03:13:57 +07:00
|
|
|
{
|
2019-06-11 17:45:48 +07:00
|
|
|
struct drm_i915_private *i915 = engine->i915;
|
2012-04-23 03:13:57 +07:00
|
|
|
|
2019-06-11 17:45:48 +07:00
|
|
|
i915->irq_mask |= engine->irq_enable_mask;
|
|
|
|
intel_uncore_write16(&i915->uncore, GEN2_IMR, i915->irq_mask);
|
2012-04-23 03:13:57 +07:00
|
|
|
}
|
|
|
|
|
2011-01-05 00:34:02 +07:00
|
|
|
static int
|
2018-02-21 16:56:36 +07:00
|
|
|
bsd_ring_flush(struct i915_request *rq, u32 mode)
|
2010-05-21 08:08:57 +07:00
|
|
|
{
|
2017-02-14 18:32:42 +07:00
|
|
|
u32 *cs;
|
2011-01-05 00:34:02 +07:00
|
|
|
|
2018-02-21 16:56:36 +07:00
|
|
|
cs = intel_ring_begin(rq, 2);
|
2017-02-14 18:32:42 +07:00
|
|
|
if (IS_ERR(cs))
|
|
|
|
return PTR_ERR(cs);
|
2011-01-05 00:34:02 +07:00
|
|
|
|
2017-02-14 18:32:42 +07:00
|
|
|
*cs++ = MI_FLUSH;
|
|
|
|
*cs++ = MI_NOOP;
|
2018-02-21 16:56:36 +07:00
|
|
|
intel_ring_advance(rq, cs);
|
2011-01-05 00:34:02 +07:00
|
|
|
return 0;
|
2010-05-21 08:08:57 +07:00
|
|
|
}
|
|
|
|
|
2016-07-01 23:23:27 +07:00
|
|
|
static void
|
|
|
|
gen6_irq_enable(struct intel_engine_cs *engine)
|
2011-01-05 00:35:21 +07:00
|
|
|
{
|
2019-03-26 04:49:40 +07:00
|
|
|
ENGINE_WRITE(engine, RING_IMR,
|
|
|
|
~(engine->irq_enable_mask | engine->irq_keep_mask));
|
2019-01-02 23:35:24 +07:00
|
|
|
|
|
|
|
/* Flush/delay to ensure the RING_IMR is active before the GT IMR */
|
2019-03-26 04:49:40 +07:00
|
|
|
ENGINE_POSTING_READ(engine, RING_IMR);
|
2019-01-02 23:35:24 +07:00
|
|
|
|
2019-08-12 04:06:33 +07:00
|
|
|
gen5_gt_enable_irq(engine->gt, engine->irq_enable_mask);
|
2011-01-05 00:35:21 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2016-07-01 23:23:27 +07:00
|
|
|
gen6_irq_disable(struct intel_engine_cs *engine)
|
2011-01-05 00:35:21 +07:00
|
|
|
{
|
2019-03-26 04:49:40 +07:00
|
|
|
ENGINE_WRITE(engine, RING_IMR, ~engine->irq_keep_mask);
|
2019-08-12 04:06:33 +07:00
|
|
|
gen5_gt_disable_irq(engine->gt, engine->irq_enable_mask);
|
2010-05-21 08:08:57 +07:00
|
|
|
}
|
|
|
|
|
2016-07-01 23:23:27 +07:00
|
|
|
static void
|
|
|
|
hsw_vebox_irq_enable(struct intel_engine_cs *engine)
|
2013-05-29 09:22:30 +07:00
|
|
|
{
|
2019-03-26 04:49:40 +07:00
|
|
|
ENGINE_WRITE(engine, RING_IMR, ~engine->irq_enable_mask);
|
2019-01-05 18:56:47 +07:00
|
|
|
|
|
|
|
/* Flush/delay to ensure the RING_IMR is active before the GT IMR */
|
2019-03-26 04:49:40 +07:00
|
|
|
ENGINE_POSTING_READ(engine, RING_IMR);
|
2019-01-05 18:56:47 +07:00
|
|
|
|
2019-08-11 21:28:00 +07:00
|
|
|
gen6_gt_pm_unmask_irq(engine->gt, engine->irq_enable_mask);
|
2013-05-29 09:22:30 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
static void
|
2016-07-01 23:23:27 +07:00
|
|
|
hsw_vebox_irq_disable(struct intel_engine_cs *engine)
|
2013-05-29 09:22:30 +07:00
|
|
|
{
|
2019-03-26 04:49:40 +07:00
|
|
|
ENGINE_WRITE(engine, RING_IMR, ~0);
|
2019-08-11 21:28:00 +07:00
|
|
|
gen6_gt_pm_mask_irq(engine->gt, engine->irq_enable_mask);
|
2013-05-29 09:22:30 +07:00
|
|
|
}
|
|
|
|
|
2010-05-21 08:08:57 +07:00
|
|
|
static int
|
2018-02-21 16:56:36 +07:00
|
|
|
i965_emit_bb_start(struct i915_request *rq,
|
2016-08-03 04:50:27 +07:00
|
|
|
u64 offset, u32 length,
|
|
|
|
unsigned int dispatch_flags)
|
2010-05-21 08:08:57 +07:00
|
|
|
{
|
2017-02-14 18:32:42 +07:00
|
|
|
u32 *cs;
|
2010-10-27 18:18:21 +07:00
|
|
|
|
2018-02-21 16:56:36 +07:00
|
|
|
cs = intel_ring_begin(rq, 2);
|
2017-02-14 18:32:42 +07:00
|
|
|
if (IS_ERR(cs))
|
|
|
|
return PTR_ERR(cs);
|
2010-10-27 18:45:26 +07:00
|
|
|
|
2017-02-14 18:32:42 +07:00
|
|
|
*cs++ = MI_BATCH_BUFFER_START | MI_BATCH_GTT | (dispatch_flags &
|
|
|
|
I915_DISPATCH_SECURE ? 0 : MI_BATCH_NON_SECURE_I965);
|
|
|
|
*cs++ = offset;
|
2018-02-21 16:56:36 +07:00
|
|
|
intel_ring_advance(rq, cs);
|
2010-10-27 18:18:21 +07:00
|
|
|
|
2010-05-21 08:08:57 +07:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2012-12-17 22:21:27 +07:00
|
|
|
/* Just userspace ABI convention to limit the wa batch bo to a resonable size */
|
2018-12-04 21:15:16 +07:00
|
|
|
#define I830_BATCH_LIMIT SZ_256K
|
drm/i915: Evict CS TLBs between batches
Running igt, I was encountering the invalid TLB bug on my 845g, despite
that it was using the CS workaround. Examining the w/a buffer in the
error state, showed that the copy from the user batch into the
workaround itself was suffering from the invalid TLB bug (the first
cacheline was broken with the first two words reversed). Time to try a
fresh approach. This extends the workaround to write into each page of
our scratch buffer in order to overflow the TLB and evict the invalid
entries. This could be refined to only do so after we update the GTT,
but for simplicity, we do it before each batch.
I suspect this supersedes our current workaround, but for safety keep
doing both.
v2: The magic number shall be 2.
This doesn't conclusively prove that it is the mythical TLB bug we've
been trying to workaround for so long, that it requires touching a number
of pages to prevent the corruption indicates to me that it is TLB
related, but the corruption (the reversed cacheline) is more subtle than
a TLB bug, where we would expect it to read the wrong page entirely.
Oh well, it prevents a reliable hang for me and so probably for others
as well.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2014-09-08 20:25:41 +07:00
|
|
|
#define I830_TLB_ENTRIES (2)
|
|
|
|
#define I830_WA_SIZE max(I830_TLB_ENTRIES*4096, I830_BATCH_LIMIT)
|
2010-05-21 08:08:55 +07:00
|
|
|
static int
|
2018-02-21 16:56:36 +07:00
|
|
|
i830_emit_bb_start(struct i915_request *rq,
|
2016-08-03 04:50:27 +07:00
|
|
|
u64 offset, u32 len,
|
|
|
|
unsigned int dispatch_flags)
|
2010-05-22 03:26:39 +07:00
|
|
|
{
|
2019-07-09 19:33:43 +07:00
|
|
|
u32 *cs, cs_offset =
|
|
|
|
intel_gt_scratch_offset(rq->engine->gt,
|
|
|
|
INTEL_GT_SCRATCH_FIELD_DEFAULT);
|
2018-12-04 21:15:16 +07:00
|
|
|
|
2019-06-21 14:08:11 +07:00
|
|
|
GEM_BUG_ON(rq->engine->gt->scratch->size < I830_WA_SIZE);
|
2010-05-22 03:26:39 +07:00
|
|
|
|
2018-02-21 16:56:36 +07:00
|
|
|
cs = intel_ring_begin(rq, 6);
|
2017-02-14 18:32:42 +07:00
|
|
|
if (IS_ERR(cs))
|
|
|
|
return PTR_ERR(cs);
|
2010-05-22 03:26:39 +07:00
|
|
|
|
drm/i915: Evict CS TLBs between batches
Running igt, I was encountering the invalid TLB bug on my 845g, despite
that it was using the CS workaround. Examining the w/a buffer in the
error state, showed that the copy from the user batch into the
workaround itself was suffering from the invalid TLB bug (the first
cacheline was broken with the first two words reversed). Time to try a
fresh approach. This extends the workaround to write into each page of
our scratch buffer in order to overflow the TLB and evict the invalid
entries. This could be refined to only do so after we update the GTT,
but for simplicity, we do it before each batch.
I suspect this supersedes our current workaround, but for safety keep
doing both.
v2: The magic number shall be 2.
This doesn't conclusively prove that it is the mythical TLB bug we've
been trying to workaround for so long, that it requires touching a number
of pages to prevent the corruption indicates to me that it is TLB
related, but the corruption (the reversed cacheline) is more subtle than
a TLB bug, where we would expect it to read the wrong page entirely.
Oh well, it prevents a reliable hang for me and so probably for others
as well.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2014-09-08 20:25:41 +07:00
|
|
|
/* Evict the invalid PTE TLBs */
|
2017-02-14 18:32:42 +07:00
|
|
|
*cs++ = COLOR_BLT_CMD | BLT_WRITE_RGBA;
|
|
|
|
*cs++ = BLT_DEPTH_32 | BLT_ROP_COLOR_COPY | 4096;
|
|
|
|
*cs++ = I830_TLB_ENTRIES << 16 | 4; /* load each page */
|
|
|
|
*cs++ = cs_offset;
|
|
|
|
*cs++ = 0xdeadbeef;
|
|
|
|
*cs++ = MI_NOOP;
|
2018-02-21 16:56:36 +07:00
|
|
|
intel_ring_advance(rq, cs);
|
2012-12-17 22:21:27 +07:00
|
|
|
|
2015-02-13 18:48:10 +07:00
|
|
|
if ((dispatch_flags & I915_DISPATCH_PINNED) == 0) {
|
2012-12-17 22:21:27 +07:00
|
|
|
if (len > I830_BATCH_LIMIT)
|
|
|
|
return -ENOSPC;
|
|
|
|
|
2018-02-21 16:56:36 +07:00
|
|
|
cs = intel_ring_begin(rq, 6 + 2);
|
2017-02-14 18:32:42 +07:00
|
|
|
if (IS_ERR(cs))
|
|
|
|
return PTR_ERR(cs);
|
drm/i915: Evict CS TLBs between batches
Running igt, I was encountering the invalid TLB bug on my 845g, despite
that it was using the CS workaround. Examining the w/a buffer in the
error state, showed that the copy from the user batch into the
workaround itself was suffering from the invalid TLB bug (the first
cacheline was broken with the first two words reversed). Time to try a
fresh approach. This extends the workaround to write into each page of
our scratch buffer in order to overflow the TLB and evict the invalid
entries. This could be refined to only do so after we update the GTT,
but for simplicity, we do it before each batch.
I suspect this supersedes our current workaround, but for safety keep
doing both.
v2: The magic number shall be 2.
This doesn't conclusively prove that it is the mythical TLB bug we've
been trying to workaround for so long, that it requires touching a number
of pages to prevent the corruption indicates to me that it is TLB
related, but the corruption (the reversed cacheline) is more subtle than
a TLB bug, where we would expect it to read the wrong page entirely.
Oh well, it prevents a reliable hang for me and so probably for others
as well.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2014-09-08 20:25:41 +07:00
|
|
|
|
|
|
|
/* Blit the batch (which has now all relocs applied) to the
|
|
|
|
* stable batch scratch bo area (so that the CS never
|
|
|
|
* stumbles over its tlb invalidation bug) ...
|
|
|
|
*/
|
2019-08-11 00:43:38 +07:00
|
|
|
*cs++ = SRC_COPY_BLT_CMD | BLT_WRITE_RGBA | (6 - 2);
|
2017-02-14 18:32:42 +07:00
|
|
|
*cs++ = BLT_DEPTH_32 | BLT_ROP_SRC_COPY | 4096;
|
|
|
|
*cs++ = DIV_ROUND_UP(len, 4096) << 16 | 4096;
|
|
|
|
*cs++ = cs_offset;
|
|
|
|
*cs++ = 4096;
|
|
|
|
*cs++ = offset;
|
|
|
|
|
|
|
|
*cs++ = MI_FLUSH;
|
|
|
|
*cs++ = MI_NOOP;
|
2018-02-21 16:56:36 +07:00
|
|
|
intel_ring_advance(rq, cs);
|
2012-12-17 22:21:27 +07:00
|
|
|
|
|
|
|
/* ... and execute it. */
|
drm/i915: Evict CS TLBs between batches
Running igt, I was encountering the invalid TLB bug on my 845g, despite
that it was using the CS workaround. Examining the w/a buffer in the
error state, showed that the copy from the user batch into the
workaround itself was suffering from the invalid TLB bug (the first
cacheline was broken with the first two words reversed). Time to try a
fresh approach. This extends the workaround to write into each page of
our scratch buffer in order to overflow the TLB and evict the invalid
entries. This could be refined to only do so after we update the GTT,
but for simplicity, we do it before each batch.
I suspect this supersedes our current workaround, but for safety keep
doing both.
v2: The magic number shall be 2.
This doesn't conclusively prove that it is the mythical TLB bug we've
been trying to workaround for so long, that it requires touching a number
of pages to prevent the corruption indicates to me that it is TLB
related, but the corruption (the reversed cacheline) is more subtle than
a TLB bug, where we would expect it to read the wrong page entirely.
Oh well, it prevents a reliable hang for me and so probably for others
as well.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2014-09-08 20:25:41 +07:00
|
|
|
offset = cs_offset;
|
2012-12-17 22:21:27 +07:00
|
|
|
}
|
2010-10-27 18:45:26 +07:00
|
|
|
|
2018-02-21 16:56:36 +07:00
|
|
|
cs = intel_ring_begin(rq, 2);
|
2017-02-14 18:32:42 +07:00
|
|
|
if (IS_ERR(cs))
|
|
|
|
return PTR_ERR(cs);
|
drm/i915: Evict CS TLBs between batches
Running igt, I was encountering the invalid TLB bug on my 845g, despite
that it was using the CS workaround. Examining the w/a buffer in the
error state, showed that the copy from the user batch into the
workaround itself was suffering from the invalid TLB bug (the first
cacheline was broken with the first two words reversed). Time to try a
fresh approach. This extends the workaround to write into each page of
our scratch buffer in order to overflow the TLB and evict the invalid
entries. This could be refined to only do so after we update the GTT,
but for simplicity, we do it before each batch.
I suspect this supersedes our current workaround, but for safety keep
doing both.
v2: The magic number shall be 2.
This doesn't conclusively prove that it is the mythical TLB bug we've
been trying to workaround for so long, that it requires touching a number
of pages to prevent the corruption indicates to me that it is TLB
related, but the corruption (the reversed cacheline) is more subtle than
a TLB bug, where we would expect it to read the wrong page entirely.
Oh well, it prevents a reliable hang for me and so probably for others
as well.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2014-09-08 20:25:41 +07:00
|
|
|
|
2017-02-14 18:32:42 +07:00
|
|
|
*cs++ = MI_BATCH_BUFFER_START | MI_BATCH_GTT;
|
|
|
|
*cs++ = offset | (dispatch_flags & I915_DISPATCH_SECURE ? 0 :
|
|
|
|
MI_BATCH_NON_SECURE);
|
2018-02-21 16:56:36 +07:00
|
|
|
intel_ring_advance(rq, cs);
|
drm/i915: Evict CS TLBs between batches
Running igt, I was encountering the invalid TLB bug on my 845g, despite
that it was using the CS workaround. Examining the w/a buffer in the
error state, showed that the copy from the user batch into the
workaround itself was suffering from the invalid TLB bug (the first
cacheline was broken with the first two words reversed). Time to try a
fresh approach. This extends the workaround to write into each page of
our scratch buffer in order to overflow the TLB and evict the invalid
entries. This could be refined to only do so after we update the GTT,
but for simplicity, we do it before each batch.
I suspect this supersedes our current workaround, but for safety keep
doing both.
v2: The magic number shall be 2.
This doesn't conclusively prove that it is the mythical TLB bug we've
been trying to workaround for so long, that it requires touching a number
of pages to prevent the corruption indicates to me that it is TLB
related, but the corruption (the reversed cacheline) is more subtle than
a TLB bug, where we would expect it to read the wrong page entirely.
Oh well, it prevents a reliable hang for me and so probably for others
as well.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Daniel Vetter <daniel.vetter@ffwll.ch>
Cc: Ville Syrjälä <ville.syrjala@linux.intel.com>
Cc: stable@vger.kernel.org
Reviewed-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Signed-off-by: Jani Nikula <jani.nikula@intel.com>
2014-09-08 20:25:41 +07:00
|
|
|
|
2012-04-12 03:12:56 +07:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int
|
2018-02-21 16:56:36 +07:00
|
|
|
i915_emit_bb_start(struct i915_request *rq,
|
2016-08-03 04:50:27 +07:00
|
|
|
u64 offset, u32 len,
|
|
|
|
unsigned int dispatch_flags)
|
2012-04-12 03:12:56 +07:00
|
|
|
{
|
2017-02-14 18:32:42 +07:00
|
|
|
u32 *cs;
|
2012-04-12 03:12:56 +07:00
|
|
|
|
2018-02-21 16:56:36 +07:00
|
|
|
cs = intel_ring_begin(rq, 2);
|
2017-02-14 18:32:42 +07:00
|
|
|
if (IS_ERR(cs))
|
|
|
|
return PTR_ERR(cs);
|
2012-04-12 03:12:56 +07:00
|
|
|
|
2017-02-14 18:32:42 +07:00
|
|
|
*cs++ = MI_BATCH_BUFFER_START | MI_BATCH_GTT;
|
|
|
|
*cs++ = offset | (dispatch_flags & I915_DISPATCH_SECURE ? 0 :
|
|
|
|
MI_BATCH_NON_SECURE);
|
2018-02-21 16:56:36 +07:00
|
|
|
intel_ring_advance(rq, cs);
|
2010-05-22 03:26:39 +07:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-07-27 22:55:01 +07:00
|
|
|
int intel_ring_pin(struct intel_ring *ring)
|
2014-11-13 17:28:56 +07:00
|
|
|
{
|
2016-08-15 16:48:57 +07:00
|
|
|
struct i915_vma *vma = ring->vma;
|
2017-04-03 18:34:25 +07:00
|
|
|
unsigned int flags;
|
2016-04-12 20:46:16 +07:00
|
|
|
void *addr;
|
2014-11-13 17:28:56 +07:00
|
|
|
int ret;
|
|
|
|
|
2019-06-20 00:01:35 +07:00
|
|
|
if (atomic_fetch_inc(&ring->pin_count))
|
|
|
|
return 0;
|
2014-11-13 17:28:56 +07:00
|
|
|
|
2016-12-24 06:56:21 +07:00
|
|
|
flags = PIN_GLOBAL;
|
2018-07-27 21:11:46 +07:00
|
|
|
|
|
|
|
/* Ring wraparound at offset 0 sometimes hangs. No idea why. */
|
|
|
|
flags |= PIN_OFFSET_BIAS | i915_ggtt_pin_bias(vma);
|
|
|
|
|
2016-08-18 23:16:56 +07:00
|
|
|
if (vma->obj->stolen)
|
2016-08-15 16:48:57 +07:00
|
|
|
flags |= PIN_MAPPABLE;
|
2018-05-21 15:21:31 +07:00
|
|
|
else
|
|
|
|
flags |= PIN_HIGH;
|
2015-10-08 19:39:54 +07:00
|
|
|
|
2018-07-27 16:18:55 +07:00
|
|
|
ret = i915_vma_pin(vma, 0, 0, flags);
|
2016-08-15 16:48:57 +07:00
|
|
|
if (unlikely(ret))
|
2019-08-10 01:25:18 +07:00
|
|
|
goto err_unpin;
|
2015-10-08 19:39:54 +07:00
|
|
|
|
2016-08-18 23:16:56 +07:00
|
|
|
if (i915_vma_is_map_and_fenceable(vma))
|
2016-08-15 16:48:57 +07:00
|
|
|
addr = (void __force *)i915_vma_pin_iomap(vma);
|
|
|
|
else
|
2019-06-20 00:01:35 +07:00
|
|
|
addr = i915_gem_object_pin_map(vma->obj,
|
|
|
|
i915_coherent_map_type(vma->vm->i915));
|
2019-01-29 01:18:11 +07:00
|
|
|
if (IS_ERR(addr)) {
|
|
|
|
ret = PTR_ERR(addr);
|
2019-06-20 00:01:35 +07:00
|
|
|
goto err_ring;
|
2019-01-29 01:18:11 +07:00
|
|
|
}
|
2014-11-13 17:28:56 +07:00
|
|
|
|
2019-08-03 04:21:36 +07:00
|
|
|
i915_vma_make_unshrinkable(vma);
|
2017-10-14 03:26:16 +07:00
|
|
|
|
2019-06-20 00:01:35 +07:00
|
|
|
GEM_BUG_ON(ring->vaddr);
|
2016-08-03 04:50:22 +07:00
|
|
|
ring->vaddr = addr;
|
2019-06-20 00:01:35 +07:00
|
|
|
|
2014-11-13 17:28:56 +07:00
|
|
|
return 0;
|
2016-04-08 18:11:10 +07:00
|
|
|
|
2019-06-20 00:01:35 +07:00
|
|
|
err_ring:
|
2016-08-15 16:48:57 +07:00
|
|
|
i915_vma_unpin(vma);
|
2019-06-20 00:01:35 +07:00
|
|
|
err_unpin:
|
|
|
|
atomic_dec(&ring->pin_count);
|
2019-01-29 01:18:11 +07:00
|
|
|
return ret;
|
2014-11-13 17:28:56 +07:00
|
|
|
}
|
|
|
|
|
2017-04-25 20:00:49 +07:00
|
|
|
void intel_ring_reset(struct intel_ring *ring, u32 tail)
|
|
|
|
{
|
2019-08-19 14:58:18 +07:00
|
|
|
tail = intel_ring_wrap(ring, tail);
|
2017-04-25 20:00:49 +07:00
|
|
|
ring->tail = tail;
|
|
|
|
ring->head = tail;
|
|
|
|
ring->emit = tail;
|
|
|
|
intel_ring_update_space(ring);
|
|
|
|
}
|
|
|
|
|
2016-08-03 04:50:23 +07:00
|
|
|
void intel_ring_unpin(struct intel_ring *ring)
|
|
|
|
{
|
2019-08-03 04:21:36 +07:00
|
|
|
struct i915_vma *vma = ring->vma;
|
|
|
|
|
2019-06-20 00:01:35 +07:00
|
|
|
if (!atomic_dec_and_test(&ring->pin_count))
|
|
|
|
return;
|
2016-08-03 04:50:23 +07:00
|
|
|
|
2017-04-25 20:00:49 +07:00
|
|
|
/* Discard any unused bytes beyond that submitted to hw. */
|
2019-08-16 03:57:09 +07:00
|
|
|
intel_ring_reset(ring, ring->emit);
|
2017-04-25 20:00:49 +07:00
|
|
|
|
2019-08-03 04:21:36 +07:00
|
|
|
i915_vma_unset_ggtt_write(vma);
|
|
|
|
if (i915_vma_is_map_and_fenceable(vma))
|
|
|
|
i915_vma_unpin_iomap(vma);
|
2016-08-15 16:48:57 +07:00
|
|
|
else
|
2019-08-03 04:21:36 +07:00
|
|
|
i915_gem_object_unpin_map(vma->obj);
|
2019-06-20 00:01:35 +07:00
|
|
|
|
|
|
|
GEM_BUG_ON(!ring->vaddr);
|
2016-08-03 04:50:23 +07:00
|
|
|
ring->vaddr = NULL;
|
|
|
|
|
2019-08-03 04:21:36 +07:00
|
|
|
i915_vma_unpin(vma);
|
|
|
|
i915_vma_make_purgeable(vma);
|
2014-07-03 22:28:02 +07:00
|
|
|
}
|
|
|
|
|
2019-06-21 14:08:07 +07:00
|
|
|
static struct i915_vma *create_ring_vma(struct i915_ggtt *ggtt, int size)
|
2010-05-22 03:26:39 +07:00
|
|
|
{
|
2019-06-21 14:08:07 +07:00
|
|
|
struct i915_address_space *vm = &ggtt->vm;
|
|
|
|
struct drm_i915_private *i915 = vm->i915;
|
2010-11-09 02:18:58 +07:00
|
|
|
struct drm_i915_gem_object *obj;
|
2016-08-15 16:48:57 +07:00
|
|
|
struct i915_vma *vma;
|
2010-05-22 03:26:39 +07:00
|
|
|
|
2019-06-21 14:08:07 +07:00
|
|
|
obj = i915_gem_object_create_stolen(i915, size);
|
2019-10-05 00:04:32 +07:00
|
|
|
if (IS_ERR(obj))
|
2019-06-21 14:08:07 +07:00
|
|
|
obj = i915_gem_object_create_internal(i915, size);
|
2016-08-15 16:48:57 +07:00
|
|
|
if (IS_ERR(obj))
|
|
|
|
return ERR_CAST(obj);
|
2010-05-21 08:08:55 +07:00
|
|
|
|
2018-07-13 01:53:11 +07:00
|
|
|
/*
|
|
|
|
* Mark ring buffers as read-only from GPU side (so no stray overwrites)
|
|
|
|
* if supported by the platform's GGTT.
|
|
|
|
*/
|
|
|
|
if (vm->has_read_only)
|
2018-07-13 01:53:13 +07:00
|
|
|
i915_gem_object_set_readonly(obj);
|
2014-06-17 12:29:42 +07:00
|
|
|
|
2018-07-13 01:53:11 +07:00
|
|
|
vma = i915_vma_instance(obj, vm, NULL);
|
2016-08-15 16:48:57 +07:00
|
|
|
if (IS_ERR(vma))
|
|
|
|
goto err;
|
|
|
|
|
|
|
|
return vma;
|
2014-04-09 15:19:41 +07:00
|
|
|
|
2016-08-15 16:48:57 +07:00
|
|
|
err:
|
|
|
|
i915_gem_object_put(obj);
|
|
|
|
return vma;
|
2014-04-09 15:19:41 +07:00
|
|
|
}
|
|
|
|
|
2016-08-03 04:50:21 +07:00
|
|
|
struct intel_ring *
|
2019-08-10 01:25:18 +07:00
|
|
|
intel_engine_create_ring(struct intel_engine_cs *engine, int size)
|
2015-09-03 19:01:39 +07:00
|
|
|
{
|
2019-06-21 14:08:07 +07:00
|
|
|
struct drm_i915_private *i915 = engine->i915;
|
2016-08-03 04:50:21 +07:00
|
|
|
struct intel_ring *ring;
|
2016-08-15 16:48:57 +07:00
|
|
|
struct i915_vma *vma;
|
2015-09-03 19:01:39 +07:00
|
|
|
|
2016-08-03 04:50:30 +07:00
|
|
|
GEM_BUG_ON(!is_power_of_2(size));
|
2016-10-05 03:11:25 +07:00
|
|
|
GEM_BUG_ON(RING_CTL_SIZE(size) & ~RING_NR_PAGES);
|
2016-08-03 04:50:30 +07:00
|
|
|
|
2015-09-03 19:01:39 +07:00
|
|
|
ring = kzalloc(sizeof(*ring), GFP_KERNEL);
|
2016-08-15 16:48:57 +07:00
|
|
|
if (!ring)
|
2015-09-03 19:01:39 +07:00
|
|
|
return ERR_PTR(-ENOMEM);
|
|
|
|
|
2019-03-18 16:51:46 +07:00
|
|
|
kref_init(&ring->ref);
|
2016-08-04 13:52:36 +07:00
|
|
|
|
2015-09-03 19:01:39 +07:00
|
|
|
ring->size = size;
|
|
|
|
/* Workaround an erratum on the i830 which causes a hang if
|
|
|
|
* the TAIL pointer points to within the last 2 cachelines
|
|
|
|
* of the buffer.
|
|
|
|
*/
|
|
|
|
ring->effective_size = size;
|
2019-06-21 14:08:07 +07:00
|
|
|
if (IS_I830(i915) || IS_I845G(i915))
|
2015-09-03 19:01:39 +07:00
|
|
|
ring->effective_size -= 2 * CACHELINE_BYTES;
|
|
|
|
|
|
|
|
intel_ring_update_space(ring);
|
|
|
|
|
2019-06-21 14:08:07 +07:00
|
|
|
vma = create_ring_vma(engine->gt->ggtt, size);
|
2016-08-15 16:48:57 +07:00
|
|
|
if (IS_ERR(vma)) {
|
2015-09-03 19:01:39 +07:00
|
|
|
kfree(ring);
|
2016-08-15 16:48:57 +07:00
|
|
|
return ERR_CAST(vma);
|
2015-09-03 19:01:39 +07:00
|
|
|
}
|
2016-08-15 16:48:57 +07:00
|
|
|
ring->vma = vma;
|
2015-09-03 19:01:39 +07:00
|
|
|
|
|
|
|
return ring;
|
|
|
|
}
|
|
|
|
|
2019-03-18 16:51:46 +07:00
|
|
|
void intel_ring_free(struct kref *ref)
|
2015-09-03 19:01:39 +07:00
|
|
|
{
|
2019-03-18 16:51:46 +07:00
|
|
|
struct intel_ring *ring = container_of(ref, typeof(*ring), ref);
|
2016-10-28 19:58:29 +07:00
|
|
|
|
2019-05-28 16:29:56 +07:00
|
|
|
i915_vma_put(ring->vma);
|
2015-09-03 19:01:39 +07:00
|
|
|
kfree(ring);
|
|
|
|
}
|
|
|
|
|
2019-03-08 20:25:19 +07:00
|
|
|
static void __ring_context_fini(struct intel_context *ce)
|
|
|
|
{
|
drm/i915: Pull i915_vma_pin under the vm->mutex
Replace the struct_mutex requirement for pinning the i915_vma with the
local vm->mutex instead. Note that the vm->mutex is tainted by the
shrinker (we require unbinding from inside fs-reclaim) and so we cannot
allocate while holding that mutex. Instead we have to preallocate
workers to do allocate and apply the PTE updates after we have we
reserved their slot in the drm_mm (using fences to order the PTE writes
with the GPU work and with later unbind).
In adding the asynchronous vma binding, one subtle requirement is to
avoid coupling the binding fence into the backing object->resv. That is
the asynchronous binding only applies to the vma timeline itself and not
to the pages as that is a more global timeline (the binding of one vma
does not need to be ordered with another vma, nor does the implicit GEM
fencing depend on a vma, only on writes to the backing store). Keeping
the vma binding distinct from the backing store timelines is verified by
a number of async gem_exec_fence and gem_exec_schedule tests. The way we
do this is quite simple, we keep the fence for the vma binding separate
and only wait on it as required, and never add it to the obj->resv
itself.
Another consequence in reducing the locking around the vma is the
destruction of the vma is no longer globally serialised by struct_mutex.
A natural solution would be to add a kref to i915_vma, but that requires
decoupling the reference cycles, possibly by introducing a new
i915_mm_pages object that is own by both obj->mm and vma->pages.
However, we have not taken that route due to the overshadowing lmem/ttm
discussions, and instead play a series of complicated games with
trylocks to (hopefully) ensure that only one destruction path is called!
v2: Add some commentary, and some helpers to reduce patch churn.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20191004134015.13204-4-chris@chris-wilson.co.uk
2019-10-04 20:39:58 +07:00
|
|
|
i915_vma_put(ce->state);
|
2019-03-08 20:25:19 +07:00
|
|
|
}
|
|
|
|
|
2019-03-19 04:23:47 +07:00
|
|
|
static void ring_context_destroy(struct kref *ref)
|
2018-05-18 04:26:32 +07:00
|
|
|
{
|
2019-03-19 04:23:47 +07:00
|
|
|
struct intel_context *ce = container_of(ref, typeof(*ce), ref);
|
|
|
|
|
2019-03-08 20:25:22 +07:00
|
|
|
GEM_BUG_ON(intel_context_is_pinned(ce));
|
2018-05-18 04:26:32 +07:00
|
|
|
|
2019-03-08 20:25:19 +07:00
|
|
|
if (ce->state)
|
|
|
|
__ring_context_fini(ce);
|
2018-06-25 17:06:04 +07:00
|
|
|
|
2019-07-18 14:00:06 +07:00
|
|
|
intel_context_fini(ce);
|
2019-03-08 20:25:19 +07:00
|
|
|
intel_context_free(ce);
|
2018-05-18 04:26:32 +07:00
|
|
|
}
|
|
|
|
|
2019-07-30 21:32:08 +07:00
|
|
|
static struct i915_address_space *vm_alias(struct intel_context *ce)
|
|
|
|
{
|
|
|
|
struct i915_address_space *vm;
|
|
|
|
|
2019-07-30 21:32:09 +07:00
|
|
|
vm = ce->vm;
|
|
|
|
if (i915_is_ggtt(vm))
|
|
|
|
vm = &i915_vm_to_ggtt(vm)->alias->vm;
|
2019-07-30 21:32:08 +07:00
|
|
|
|
|
|
|
return vm;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int __context_pin_ppgtt(struct intel_context *ce)
|
2018-06-14 16:41:03 +07:00
|
|
|
{
|
2019-06-11 16:12:37 +07:00
|
|
|
struct i915_address_space *vm;
|
2018-06-14 16:41:03 +07:00
|
|
|
int err = 0;
|
|
|
|
|
2019-07-30 21:32:08 +07:00
|
|
|
vm = vm_alias(ce);
|
2019-06-11 16:12:37 +07:00
|
|
|
if (vm)
|
|
|
|
err = gen6_ppgtt_pin(i915_vm_to_ppgtt((vm)));
|
2018-06-14 16:41:03 +07:00
|
|
|
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
2019-07-30 21:32:08 +07:00
|
|
|
static void __context_unpin_ppgtt(struct intel_context *ce)
|
2018-06-14 16:41:03 +07:00
|
|
|
{
|
2019-06-11 16:12:37 +07:00
|
|
|
struct i915_address_space *vm;
|
2018-06-14 16:41:03 +07:00
|
|
|
|
2019-07-30 21:32:08 +07:00
|
|
|
vm = vm_alias(ce);
|
2019-06-11 16:12:37 +07:00
|
|
|
if (vm)
|
|
|
|
gen6_ppgtt_unpin(i915_vm_to_ppgtt(vm));
|
2018-06-14 16:41:03 +07:00
|
|
|
}
|
|
|
|
|
2019-03-08 20:25:18 +07:00
|
|
|
static void ring_context_unpin(struct intel_context *ce)
|
2018-06-05 15:53:48 +07:00
|
|
|
{
|
2019-07-30 21:32:08 +07:00
|
|
|
__context_unpin_ppgtt(ce);
|
drm/i915: Unify active context tracking between legacy/execlists/guc
The requests conversion introduced a nasty bug where we could generate a
new request in the middle of constructing a request if we needed to idle
the system in order to evict space for a context. The request to idle
would be executed (and waited upon) before the current one, creating a
minor havoc in the seqno accounting, as we will consider the current
request to already be completed (prior to deferred seqno assignment) but
ring->last_retired_head would have been updated and still could allow
us to overwrite the current request before execution.
We also employed two different mechanisms to track the active context
until it was switched out. The legacy method allowed for waiting upon an
active context (it could forcibly evict any vma, including context's),
but the execlists method took a step backwards by pinning the vma for
the entire active lifespan of the context (the only way to evict was to
idle the entire GPU, not individual contexts). However, to circumvent
the tricky issue of locking (i.e. we cannot take struct_mutex at the
time of i915_gem_request_submit(), where we would want to move the
previous context onto the active tracker and unpin it), we take the
execlists approach and keep the contexts pinned until retirement.
The benefit of the execlists approach, more important for execlists than
legacy, was the reduction in work in pinning the context for each
request - as the context was kept pinned until idle, it could short
circuit the pinning for all active contexts.
We introduce new engine vfuncs to pin and unpin the context
respectively. The context is pinned at the start of the request, and
only unpinned when the following request is retired (this ensures that
the context is idle and coherent in main memory before we unpin it). We
move the engine->last_context tracking into the retirement itself
(rather than during request submission) in order to allow the submission
to be reordered or unwound without undue difficultly.
And finally an ulterior motive for unifying context handling was to
prepare for mock requests.
v2: Rename to last_retired_context, split out legacy_context tracking
for MI_SET_CONTEXT.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161218153724.8439-3-chris@chris-wilson.co.uk
2016-12-18 22:37:20 +07:00
|
|
|
}
|
|
|
|
|
2017-04-27 17:46:51 +07:00
|
|
|
static struct i915_vma *
|
|
|
|
alloc_context_vma(struct intel_engine_cs *engine)
|
|
|
|
{
|
|
|
|
struct drm_i915_private *i915 = engine->i915;
|
|
|
|
struct drm_i915_gem_object *obj;
|
|
|
|
struct i915_vma *vma;
|
2017-11-10 21:26:33 +07:00
|
|
|
int err;
|
2017-04-27 17:46:51 +07:00
|
|
|
|
2019-05-28 16:29:45 +07:00
|
|
|
obj = i915_gem_object_create_shmem(i915, engine->context_size);
|
2017-04-27 17:46:51 +07:00
|
|
|
if (IS_ERR(obj))
|
|
|
|
return ERR_CAST(obj);
|
|
|
|
|
drm/i915: Flush pages on acquisition
When we return pages to the system, we ensure that they are marked as
being in the CPU domain since any external access is uncontrolled and we
must assume the worst. This means that we need to always flush the pages
on acquisition if we need to use them on the GPU, and from the beginning
have used set-domain. Set-domain is overkill for the purpose as it is a
general synchronisation barrier, but our intent is to only flush the
pages being swapped in. If we move that flush into the pages acquisition
phase, we know then that when we have obj->mm.pages, they are coherent
with the GPU and need only maintain that status without resorting to
heavy handed use of set-domain.
The principle knock-on effect for userspace is through mmap-gtt
pagefaulting. Our uAPI has always implied that the GTT mmap was async
(especially as when any pagefault occurs is unpredicatable to userspace)
and so userspace had to apply explicit domain control itself
(set-domain). However, swapping is transparent to the kernel, and so on
first fault we need to acquire the pages and make them coherent for
access through the GTT. Our use of set-domain here leaks into the uABI
that the first pagefault was synchronous. This is unintentional and
baring a few igt should be unoticed, nevertheless we bump the uABI
version for mmap-gtt to reflect the change in behaviour.
Another implication of the change is that gem_create() is presumed to
create an object that is coherent with the CPU and is in the CPU write
domain, so a set-domain(CPU) following a gem_create() would be a minor
operation that merely checked whether we could allocate all pages for
the object. On applying this change, a set-domain(CPU) causes a clflush
as we acquire the pages. This will have a small impact on mesa as we move
the clflush here on !llc from execbuf time to create, but that should
have minimal performance impact as the same clflush exists but is now
done early and because of the clflush issue, userspace recycles bo and
so should resist allocating fresh objects.
Internally, the presumption that objects are created in the CPU
write-domain and remain so through writes to obj->mm.mapping is more
prevalent than I expected; but easy enough to catch and apply a manual
flush.
For the future, we should push the page flush from the central
set_pages() into the callers so that we can more finely control when it
is applied, but for now doing it one location is easier to validate, at
the cost of sometimes flushing when there is no need.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Antonio Argenziano <antonio.argenziano@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Matthew Auld <matthew.william.auld@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190321161908.8007-1-chris@chris-wilson.co.uk
2019-03-21 23:19:07 +07:00
|
|
|
/*
|
|
|
|
* Try to make the context utilize L3 as well as LLC.
|
|
|
|
*
|
|
|
|
* On VLV we don't have L3 controls in the PTEs so we
|
|
|
|
* shouldn't touch the cache level, especially as that
|
|
|
|
* would make the object snooped which might have a
|
|
|
|
* negative performance impact.
|
|
|
|
*
|
|
|
|
* Snooping is required on non-llc platforms in execlist
|
|
|
|
* mode, but since all GGTT accesses use PAT entry 0 we
|
|
|
|
* get snooping anyway regardless of cache_level.
|
|
|
|
*
|
|
|
|
* This is only applicable for Ivy Bridge devices since
|
|
|
|
* later platforms don't have L3 control bits in the PTE.
|
|
|
|
*/
|
|
|
|
if (IS_IVYBRIDGE(i915))
|
|
|
|
i915_gem_object_set_cache_coherency(obj, I915_CACHE_L3_LLC);
|
|
|
|
|
2017-11-10 21:26:33 +07:00
|
|
|
if (engine->default_state) {
|
|
|
|
void *defaults, *vaddr;
|
|
|
|
|
|
|
|
vaddr = i915_gem_object_pin_map(obj, I915_MAP_WB);
|
|
|
|
if (IS_ERR(vaddr)) {
|
|
|
|
err = PTR_ERR(vaddr);
|
|
|
|
goto err_obj;
|
|
|
|
}
|
|
|
|
|
|
|
|
defaults = i915_gem_object_pin_map(engine->default_state,
|
|
|
|
I915_MAP_WB);
|
|
|
|
if (IS_ERR(defaults)) {
|
|
|
|
err = PTR_ERR(defaults);
|
|
|
|
goto err_map;
|
|
|
|
}
|
|
|
|
|
|
|
|
memcpy(vaddr, defaults, engine->context_size);
|
|
|
|
i915_gem_object_unpin_map(engine->default_state);
|
|
|
|
|
drm/i915: Flush pages on acquisition
When we return pages to the system, we ensure that they are marked as
being in the CPU domain since any external access is uncontrolled and we
must assume the worst. This means that we need to always flush the pages
on acquisition if we need to use them on the GPU, and from the beginning
have used set-domain. Set-domain is overkill for the purpose as it is a
general synchronisation barrier, but our intent is to only flush the
pages being swapped in. If we move that flush into the pages acquisition
phase, we know then that when we have obj->mm.pages, they are coherent
with the GPU and need only maintain that status without resorting to
heavy handed use of set-domain.
The principle knock-on effect for userspace is through mmap-gtt
pagefaulting. Our uAPI has always implied that the GTT mmap was async
(especially as when any pagefault occurs is unpredicatable to userspace)
and so userspace had to apply explicit domain control itself
(set-domain). However, swapping is transparent to the kernel, and so on
first fault we need to acquire the pages and make them coherent for
access through the GTT. Our use of set-domain here leaks into the uABI
that the first pagefault was synchronous. This is unintentional and
baring a few igt should be unoticed, nevertheless we bump the uABI
version for mmap-gtt to reflect the change in behaviour.
Another implication of the change is that gem_create() is presumed to
create an object that is coherent with the CPU and is in the CPU write
domain, so a set-domain(CPU) following a gem_create() would be a minor
operation that merely checked whether we could allocate all pages for
the object. On applying this change, a set-domain(CPU) causes a clflush
as we acquire the pages. This will have a small impact on mesa as we move
the clflush here on !llc from execbuf time to create, but that should
have minimal performance impact as the same clflush exists but is now
done early and because of the clflush issue, userspace recycles bo and
so should resist allocating fresh objects.
Internally, the presumption that objects are created in the CPU
write-domain and remain so through writes to obj->mm.mapping is more
prevalent than I expected; but easy enough to catch and apply a manual
flush.
For the future, we should push the page flush from the central
set_pages() into the callers so that we can more finely control when it
is applied, but for now doing it one location is easier to validate, at
the cost of sometimes flushing when there is no need.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Matthew Auld <matthew.william.auld@gmail.com>
Cc: Daniele Ceraolo Spurio <daniele.ceraolospurio@intel.com>
Cc: Antonio Argenziano <antonio.argenziano@intel.com>
Cc: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Matthew Auld <matthew.william.auld@gmail.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190321161908.8007-1-chris@chris-wilson.co.uk
2019-03-21 23:19:07 +07:00
|
|
|
i915_gem_object_flush_map(obj);
|
|
|
|
i915_gem_object_unpin_map(obj);
|
2017-04-27 17:46:51 +07:00
|
|
|
}
|
|
|
|
|
2019-06-21 14:08:08 +07:00
|
|
|
vma = i915_vma_instance(obj, &engine->gt->ggtt->vm, NULL);
|
2017-11-10 21:26:33 +07:00
|
|
|
if (IS_ERR(vma)) {
|
|
|
|
err = PTR_ERR(vma);
|
|
|
|
goto err_obj;
|
|
|
|
}
|
2017-04-27 17:46:51 +07:00
|
|
|
|
|
|
|
return vma;
|
2017-11-10 21:26:33 +07:00
|
|
|
|
|
|
|
err_map:
|
|
|
|
i915_gem_object_unpin_map(obj);
|
|
|
|
err_obj:
|
|
|
|
i915_gem_object_put(obj);
|
|
|
|
return ERR_PTR(err);
|
2017-04-27 17:46:51 +07:00
|
|
|
}
|
|
|
|
|
2019-08-10 01:25:16 +07:00
|
|
|
static int ring_context_alloc(struct intel_context *ce)
|
2016-06-24 20:55:53 +07:00
|
|
|
{
|
2019-03-08 20:25:20 +07:00
|
|
|
struct intel_engine_cs *engine = ce->engine;
|
2016-06-24 20:55:53 +07:00
|
|
|
|
2019-03-08 20:25:16 +07:00
|
|
|
/* One ringbuffer to rule them all */
|
2019-08-10 01:25:18 +07:00
|
|
|
GEM_BUG_ON(!engine->legacy.ring);
|
|
|
|
ce->ring = engine->legacy.ring;
|
|
|
|
ce->timeline = intel_timeline_get(engine->legacy.timeline);
|
2019-03-08 20:25:16 +07:00
|
|
|
|
2019-08-10 01:25:16 +07:00
|
|
|
GEM_BUG_ON(ce->state);
|
|
|
|
if (engine->context_size) {
|
2017-04-27 17:46:51 +07:00
|
|
|
struct i915_vma *vma;
|
|
|
|
|
|
|
|
vma = alloc_context_vma(engine);
|
2019-03-08 20:25:20 +07:00
|
|
|
if (IS_ERR(vma))
|
|
|
|
return PTR_ERR(vma);
|
2017-04-27 17:46:51 +07:00
|
|
|
|
|
|
|
ce->state = vma;
|
|
|
|
}
|
|
|
|
|
2019-08-10 01:25:16 +07:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
static int ring_context_pin(struct intel_context *ce)
|
|
|
|
{
|
|
|
|
int err;
|
|
|
|
|
2019-06-22 01:38:00 +07:00
|
|
|
err = intel_context_active_acquire(ce);
|
2018-06-05 15:53:48 +07:00
|
|
|
if (err)
|
2019-03-08 20:25:20 +07:00
|
|
|
return err;
|
2016-06-24 20:55:53 +07:00
|
|
|
|
2019-07-30 21:32:08 +07:00
|
|
|
err = __context_pin_ppgtt(ce);
|
2018-06-14 16:41:03 +07:00
|
|
|
if (err)
|
drm/i915: Keep contexts pinned until after the next kernel context switch
We need to keep the context image pinned in memory until after the GPU
has finished writing into it. Since it continues to write as we signal
the final breadcrumb, we need to keep it pinned until the request after
it is complete. Currently we know the order in which requests execute on
each engine, and so to remove that presumption we need to identify a
request/context-switch we know must occur after our completion. Any
request queued after the signal must imply a context switch, for
simplicity we use a fresh request from the kernel context.
The sequence of operations for keeping the context pinned until saved is:
- On context activation, we preallocate a node for each physical engine
the context may operate on. This is to avoid allocations during
unpinning, which may be from inside FS_RECLAIM context (aka the
shrinker)
- On context deactivation on retirement of the last active request (which
is before we know the context has been saved), we add the
preallocated node onto a barrier list on each engine
- On engine idling, we emit a switch to kernel context. When this
switch completes, we know that all previous contexts must have been
saved, and so on retiring this request we can finally unpin all the
contexts that were marked as deactivated prior to the switch.
We can enhance this in future by flushing all the idle contexts on a
regular heartbeat pulse of a switch to kernel context, which will also
be used to check for hung engines.
v2: intel_context_active_acquire/_release
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190614164606.15633-1-chris@chris-wilson.co.uk
2019-06-14 23:46:04 +07:00
|
|
|
goto err_active;
|
2018-06-14 16:41:03 +07:00
|
|
|
|
2019-03-08 20:25:20 +07:00
|
|
|
return 0;
|
2017-05-04 16:33:08 +07:00
|
|
|
|
drm/i915: Keep contexts pinned until after the next kernel context switch
We need to keep the context image pinned in memory until after the GPU
has finished writing into it. Since it continues to write as we signal
the final breadcrumb, we need to keep it pinned until the request after
it is complete. Currently we know the order in which requests execute on
each engine, and so to remove that presumption we need to identify a
request/context-switch we know must occur after our completion. Any
request queued after the signal must imply a context switch, for
simplicity we use a fresh request from the kernel context.
The sequence of operations for keeping the context pinned until saved is:
- On context activation, we preallocate a node for each physical engine
the context may operate on. This is to avoid allocations during
unpinning, which may be from inside FS_RECLAIM context (aka the
shrinker)
- On context deactivation on retirement of the last active request (which
is before we know the context has been saved), we add the
preallocated node onto a barrier list on each engine
- On engine idling, we emit a switch to kernel context. When this
switch completes, we know that all previous contexts must have been
saved, and so on retiring this request we can finally unpin all the
contexts that were marked as deactivated prior to the switch.
We can enhance this in future by flushing all the idle contexts on a
regular heartbeat pulse of a switch to kernel context, which will also
be used to check for hung engines.
v2: intel_context_active_acquire/_release
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190614164606.15633-1-chris@chris-wilson.co.uk
2019-06-14 23:46:04 +07:00
|
|
|
err_active:
|
|
|
|
intel_context_active_release(ce);
|
2019-03-08 20:25:20 +07:00
|
|
|
return err;
|
2016-06-24 20:55:53 +07:00
|
|
|
}
|
|
|
|
|
2019-04-11 02:01:20 +07:00
|
|
|
static void ring_context_reset(struct intel_context *ce)
|
|
|
|
{
|
|
|
|
intel_ring_reset(ce->ring, 0);
|
|
|
|
}
|
|
|
|
|
2019-03-08 20:25:18 +07:00
|
|
|
static const struct intel_context_ops ring_context_ops = {
|
2019-08-10 01:25:16 +07:00
|
|
|
.alloc = ring_context_alloc,
|
|
|
|
|
2019-03-08 20:25:20 +07:00
|
|
|
.pin = ring_context_pin,
|
2019-03-08 20:25:18 +07:00
|
|
|
.unpin = ring_context_unpin,
|
2019-04-11 02:01:20 +07:00
|
|
|
|
2019-04-25 03:07:15 +07:00
|
|
|
.enter = intel_context_enter_engine,
|
|
|
|
.exit = intel_context_exit_engine,
|
|
|
|
|
2019-04-11 02:01:20 +07:00
|
|
|
.reset = ring_context_reset,
|
2019-03-08 20:25:18 +07:00
|
|
|
.destroy = ring_context_destroy,
|
|
|
|
};
|
|
|
|
|
2019-06-11 16:12:38 +07:00
|
|
|
static int load_pd_dir(struct i915_request *rq, const struct i915_ppgtt *ppgtt)
|
2018-06-11 18:08:44 +07:00
|
|
|
{
|
|
|
|
const struct intel_engine_cs * const engine = rq->engine;
|
|
|
|
u32 *cs;
|
|
|
|
|
|
|
|
cs = intel_ring_begin(rq, 6);
|
|
|
|
if (IS_ERR(cs))
|
|
|
|
return PTR_ERR(cs);
|
|
|
|
|
|
|
|
*cs++ = MI_LOAD_REGISTER_IMM(1);
|
2019-03-26 04:49:40 +07:00
|
|
|
*cs++ = i915_mmio_reg_offset(RING_PP_DIR_DCLV(engine->mmio_base));
|
2018-06-11 18:08:44 +07:00
|
|
|
*cs++ = PP_DIR_DCLV_2G;
|
|
|
|
|
|
|
|
*cs++ = MI_LOAD_REGISTER_IMM(1);
|
2019-03-26 04:49:40 +07:00
|
|
|
*cs++ = i915_mmio_reg_offset(RING_PP_DIR_BASE(engine->mmio_base));
|
2019-07-12 16:43:22 +07:00
|
|
|
*cs++ = px_base(ppgtt->pd)->ggtt_offset << 10;
|
2018-06-11 18:08:44 +07:00
|
|
|
|
|
|
|
intel_ring_advance(rq, cs);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-06-12 00:18:25 +07:00
|
|
|
static int flush_pd_dir(struct i915_request *rq)
|
|
|
|
{
|
|
|
|
const struct intel_engine_cs * const engine = rq->engine;
|
|
|
|
u32 *cs;
|
|
|
|
|
|
|
|
cs = intel_ring_begin(rq, 4);
|
|
|
|
if (IS_ERR(cs))
|
|
|
|
return PTR_ERR(cs);
|
|
|
|
|
|
|
|
/* Stall until the page table load is complete */
|
|
|
|
*cs++ = MI_STORE_REGISTER_MEM | MI_SRM_LRM_GLOBAL_GTT;
|
2019-03-26 04:49:40 +07:00
|
|
|
*cs++ = i915_mmio_reg_offset(RING_PP_DIR_BASE(engine->mmio_base));
|
2019-07-09 19:33:43 +07:00
|
|
|
*cs++ = intel_gt_scratch_offset(rq->engine->gt,
|
|
|
|
INTEL_GT_SCRATCH_FIELD_DEFAULT);
|
2018-06-12 00:18:25 +07:00
|
|
|
*cs++ = MI_NOOP;
|
|
|
|
|
|
|
|
intel_ring_advance(rq, cs);
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-02-21 16:56:36 +07:00
|
|
|
static inline int mi_set_context(struct i915_request *rq, u32 flags)
|
2017-11-23 22:26:31 +07:00
|
|
|
{
|
|
|
|
struct drm_i915_private *i915 = rq->i915;
|
|
|
|
struct intel_engine_cs *engine = rq->engine;
|
|
|
|
enum intel_engine_id id;
|
2019-03-06 01:03:30 +07:00
|
|
|
const int num_engines =
|
2019-09-18 02:47:46 +07:00
|
|
|
IS_HASWELL(i915) ? RUNTIME_INFO(i915)->num_engines - 1 : 0;
|
2018-06-11 17:48:08 +07:00
|
|
|
bool force_restore = false;
|
2017-11-23 22:26:31 +07:00
|
|
|
int len;
|
|
|
|
u32 *cs;
|
|
|
|
|
|
|
|
flags |= MI_MM_SPACE_GTT;
|
|
|
|
if (IS_HASWELL(i915))
|
|
|
|
/* These flags are for resource streamer on HSW+ */
|
|
|
|
flags |= HSW_MI_RS_SAVE_STATE_EN | HSW_MI_RS_RESTORE_STATE_EN;
|
|
|
|
else
|
2019-04-19 18:17:48 +07:00
|
|
|
/* We need to save the extended state for powersaving modes */
|
2017-11-23 22:26:31 +07:00
|
|
|
flags |= MI_SAVE_EXT_STATE_EN | MI_RESTORE_EXT_STATE_EN;
|
|
|
|
|
|
|
|
len = 4;
|
drm/i915: replace IS_GEN<N> with IS_GEN(..., N)
Define IS_GEN() similarly to our IS_GEN_RANGE(). but use gen instead of
gen_mask to do the comparison. Now callers can pass then gen as a parameter,
so we don't require one macro for each gen.
The following spatch was used to convert the users of these macros:
@@
expression e;
@@
(
- IS_GEN2(e)
+ IS_GEN(e, 2)
|
- IS_GEN3(e)
+ IS_GEN(e, 3)
|
- IS_GEN4(e)
+ IS_GEN(e, 4)
|
- IS_GEN5(e)
+ IS_GEN(e, 5)
|
- IS_GEN6(e)
+ IS_GEN(e, 6)
|
- IS_GEN7(e)
+ IS_GEN(e, 7)
|
- IS_GEN8(e)
+ IS_GEN(e, 8)
|
- IS_GEN9(e)
+ IS_GEN(e, 9)
|
- IS_GEN10(e)
+ IS_GEN(e, 10)
|
- IS_GEN11(e)
+ IS_GEN(e, 11)
)
v2: use IS_GEN rather than GT_GEN and compare to info.gen rather than
using the bitmask
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181212181044.15886-2-lucas.demarchi@intel.com
2018-12-13 01:10:43 +07:00
|
|
|
if (IS_GEN(i915, 7))
|
2019-03-06 01:03:30 +07:00
|
|
|
len += 2 + (num_engines ? 4 * num_engines + 6 : 0);
|
2019-04-19 18:17:48 +07:00
|
|
|
else if (IS_GEN(i915, 5))
|
|
|
|
len += 2;
|
2018-06-11 17:48:08 +07:00
|
|
|
if (flags & MI_FORCE_RESTORE) {
|
|
|
|
GEM_BUG_ON(flags & MI_RESTORE_INHIBIT);
|
|
|
|
flags &= ~MI_FORCE_RESTORE;
|
|
|
|
force_restore = true;
|
|
|
|
len += 2;
|
|
|
|
}
|
2017-11-23 22:26:31 +07:00
|
|
|
|
|
|
|
cs = intel_ring_begin(rq, len);
|
|
|
|
if (IS_ERR(cs))
|
|
|
|
return PTR_ERR(cs);
|
|
|
|
|
|
|
|
/* WaProgramMiArbOnOffAroundMiSetContext:ivb,vlv,hsw,bdw,chv */
|
drm/i915: replace IS_GEN<N> with IS_GEN(..., N)
Define IS_GEN() similarly to our IS_GEN_RANGE(). but use gen instead of
gen_mask to do the comparison. Now callers can pass then gen as a parameter,
so we don't require one macro for each gen.
The following spatch was used to convert the users of these macros:
@@
expression e;
@@
(
- IS_GEN2(e)
+ IS_GEN(e, 2)
|
- IS_GEN3(e)
+ IS_GEN(e, 3)
|
- IS_GEN4(e)
+ IS_GEN(e, 4)
|
- IS_GEN5(e)
+ IS_GEN(e, 5)
|
- IS_GEN6(e)
+ IS_GEN(e, 6)
|
- IS_GEN7(e)
+ IS_GEN(e, 7)
|
- IS_GEN8(e)
+ IS_GEN(e, 8)
|
- IS_GEN9(e)
+ IS_GEN(e, 9)
|
- IS_GEN10(e)
+ IS_GEN(e, 10)
|
- IS_GEN11(e)
+ IS_GEN(e, 11)
)
v2: use IS_GEN rather than GT_GEN and compare to info.gen rather than
using the bitmask
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181212181044.15886-2-lucas.demarchi@intel.com
2018-12-13 01:10:43 +07:00
|
|
|
if (IS_GEN(i915, 7)) {
|
2017-11-23 22:26:31 +07:00
|
|
|
*cs++ = MI_ARB_ON_OFF | MI_ARB_DISABLE;
|
2019-03-06 01:03:30 +07:00
|
|
|
if (num_engines) {
|
2017-11-23 22:26:31 +07:00
|
|
|
struct intel_engine_cs *signaller;
|
|
|
|
|
2019-03-06 01:03:30 +07:00
|
|
|
*cs++ = MI_LOAD_REGISTER_IMM(num_engines);
|
2017-11-23 22:26:31 +07:00
|
|
|
for_each_engine(signaller, i915, id) {
|
|
|
|
if (signaller == engine)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
*cs++ = i915_mmio_reg_offset(
|
|
|
|
RING_PSMI_CTL(signaller->mmio_base));
|
|
|
|
*cs++ = _MASKED_BIT_ENABLE(
|
|
|
|
GEN6_PSMI_SLEEP_MSG_DISABLE);
|
|
|
|
}
|
|
|
|
}
|
2019-04-19 18:17:48 +07:00
|
|
|
} else if (IS_GEN(i915, 5)) {
|
|
|
|
/*
|
|
|
|
* This w/a is only listed for pre-production ilk a/b steppings,
|
|
|
|
* but is also mentioned for programming the powerctx. To be
|
|
|
|
* safe, just apply the workaround; we do not use SyncFlush so
|
|
|
|
* this should never take effect and so be a no-op!
|
|
|
|
*/
|
|
|
|
*cs++ = MI_SUSPEND_FLUSH | MI_SUSPEND_FLUSH_EN;
|
2017-11-23 22:26:31 +07:00
|
|
|
}
|
|
|
|
|
2018-06-11 17:48:08 +07:00
|
|
|
if (force_restore) {
|
|
|
|
/*
|
|
|
|
* The HW doesn't handle being told to restore the current
|
|
|
|
* context very well. Quite often it likes goes to go off and
|
|
|
|
* sulk, especially when it is meant to be reloading PP_DIR.
|
|
|
|
* A very simple fix to force the reload is to simply switch
|
|
|
|
* away from the current context and back again.
|
|
|
|
*
|
|
|
|
* Note that the kernel_context will contain random state
|
|
|
|
* following the INHIBIT_RESTORE. We accept this since we
|
|
|
|
* never use the kernel_context state; it is merely a
|
|
|
|
* placeholder we use to flush other contexts.
|
|
|
|
*/
|
|
|
|
*cs++ = MI_SET_CONTEXT;
|
2019-03-08 20:25:21 +07:00
|
|
|
*cs++ = i915_ggtt_offset(engine->kernel_context->state) |
|
2018-06-11 17:48:08 +07:00
|
|
|
MI_MM_SPACE_GTT |
|
|
|
|
MI_RESTORE_INHIBIT;
|
|
|
|
}
|
|
|
|
|
2017-11-23 22:26:31 +07:00
|
|
|
*cs++ = MI_NOOP;
|
|
|
|
*cs++ = MI_SET_CONTEXT;
|
2018-05-18 04:26:32 +07:00
|
|
|
*cs++ = i915_ggtt_offset(rq->hw_context->state) | flags;
|
2017-11-23 22:26:31 +07:00
|
|
|
/*
|
|
|
|
* w/a: MI_SET_CONTEXT must always be followed by MI_NOOP
|
|
|
|
* WaMiSetContext_Hang:snb,ivb,vlv
|
|
|
|
*/
|
|
|
|
*cs++ = MI_NOOP;
|
|
|
|
|
drm/i915: replace IS_GEN<N> with IS_GEN(..., N)
Define IS_GEN() similarly to our IS_GEN_RANGE(). but use gen instead of
gen_mask to do the comparison. Now callers can pass then gen as a parameter,
so we don't require one macro for each gen.
The following spatch was used to convert the users of these macros:
@@
expression e;
@@
(
- IS_GEN2(e)
+ IS_GEN(e, 2)
|
- IS_GEN3(e)
+ IS_GEN(e, 3)
|
- IS_GEN4(e)
+ IS_GEN(e, 4)
|
- IS_GEN5(e)
+ IS_GEN(e, 5)
|
- IS_GEN6(e)
+ IS_GEN(e, 6)
|
- IS_GEN7(e)
+ IS_GEN(e, 7)
|
- IS_GEN8(e)
+ IS_GEN(e, 8)
|
- IS_GEN9(e)
+ IS_GEN(e, 9)
|
- IS_GEN10(e)
+ IS_GEN(e, 10)
|
- IS_GEN11(e)
+ IS_GEN(e, 11)
)
v2: use IS_GEN rather than GT_GEN and compare to info.gen rather than
using the bitmask
Signed-off-by: Lucas De Marchi <lucas.demarchi@intel.com>
Reviewed-by: Jani Nikula <jani.nikula@intel.com>
Signed-off-by: Rodrigo Vivi <rodrigo.vivi@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20181212181044.15886-2-lucas.demarchi@intel.com
2018-12-13 01:10:43 +07:00
|
|
|
if (IS_GEN(i915, 7)) {
|
2019-03-06 01:03:30 +07:00
|
|
|
if (num_engines) {
|
2017-11-23 22:26:31 +07:00
|
|
|
struct intel_engine_cs *signaller;
|
|
|
|
i915_reg_t last_reg = {}; /* keep gcc quiet */
|
|
|
|
|
2019-03-06 01:03:30 +07:00
|
|
|
*cs++ = MI_LOAD_REGISTER_IMM(num_engines);
|
2017-11-23 22:26:31 +07:00
|
|
|
for_each_engine(signaller, i915, id) {
|
|
|
|
if (signaller == engine)
|
|
|
|
continue;
|
|
|
|
|
|
|
|
last_reg = RING_PSMI_CTL(signaller->mmio_base);
|
|
|
|
*cs++ = i915_mmio_reg_offset(last_reg);
|
|
|
|
*cs++ = _MASKED_BIT_DISABLE(
|
|
|
|
GEN6_PSMI_SLEEP_MSG_DISABLE);
|
|
|
|
}
|
|
|
|
|
|
|
|
/* Insert a delay before the next switch! */
|
|
|
|
*cs++ = MI_STORE_REGISTER_MEM | MI_SRM_LRM_GLOBAL_GTT;
|
|
|
|
*cs++ = i915_mmio_reg_offset(last_reg);
|
2019-07-09 19:33:43 +07:00
|
|
|
*cs++ = intel_gt_scratch_offset(rq->engine->gt,
|
|
|
|
INTEL_GT_SCRATCH_FIELD_DEFAULT);
|
2017-11-23 22:26:31 +07:00
|
|
|
*cs++ = MI_NOOP;
|
|
|
|
}
|
|
|
|
*cs++ = MI_ARB_ON_OFF | MI_ARB_ENABLE;
|
2019-04-19 18:17:48 +07:00
|
|
|
} else if (IS_GEN(i915, 5)) {
|
|
|
|
*cs++ = MI_SUSPEND_FLUSH;
|
2017-11-23 22:26:31 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
intel_ring_advance(rq, cs);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-07-30 21:32:08 +07:00
|
|
|
static int remap_l3_slice(struct i915_request *rq, int slice)
|
2017-11-23 22:26:31 +07:00
|
|
|
{
|
|
|
|
u32 *cs, *remap_info = rq->i915->l3_parity.remap_info[slice];
|
|
|
|
int i;
|
|
|
|
|
|
|
|
if (!remap_info)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
cs = intel_ring_begin(rq, GEN7_L3LOG_SIZE/4 * 2 + 2);
|
|
|
|
if (IS_ERR(cs))
|
|
|
|
return PTR_ERR(cs);
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Note: We do not worry about the concurrent register cacheline hang
|
|
|
|
* here because no other code should access these registers other than
|
|
|
|
* at initialization time.
|
|
|
|
*/
|
|
|
|
*cs++ = MI_LOAD_REGISTER_IMM(GEN7_L3LOG_SIZE/4);
|
|
|
|
for (i = 0; i < GEN7_L3LOG_SIZE/4; i++) {
|
|
|
|
*cs++ = i915_mmio_reg_offset(GEN7_L3LOG(slice, i));
|
|
|
|
*cs++ = remap_info[i];
|
|
|
|
}
|
|
|
|
*cs++ = MI_NOOP;
|
|
|
|
intel_ring_advance(rq, cs);
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2019-07-30 21:32:08 +07:00
|
|
|
static int remap_l3(struct i915_request *rq)
|
|
|
|
{
|
|
|
|
struct i915_gem_context *ctx = rq->gem_context;
|
|
|
|
int i, err;
|
|
|
|
|
|
|
|
if (!ctx->remap_slice)
|
|
|
|
return 0;
|
|
|
|
|
|
|
|
for (i = 0; i < MAX_L3_SLICES; i++) {
|
|
|
|
if (!(ctx->remap_slice & BIT(i)))
|
|
|
|
continue;
|
|
|
|
|
|
|
|
err = remap_l3_slice(rq, i);
|
|
|
|
if (err)
|
|
|
|
return err;
|
|
|
|
}
|
|
|
|
|
|
|
|
ctx->remap_slice = 0;
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-02-21 16:56:36 +07:00
|
|
|
static int switch_context(struct i915_request *rq)
|
2017-11-23 22:26:31 +07:00
|
|
|
{
|
2019-08-31 00:59:58 +07:00
|
|
|
struct intel_context *ce = rq->hw_context;
|
|
|
|
struct i915_address_space *vm = vm_alias(ce);
|
2019-07-30 21:32:08 +07:00
|
|
|
int ret;
|
2017-11-23 22:26:31 +07:00
|
|
|
|
|
|
|
GEM_BUG_ON(HAS_EXECLISTS(rq->i915));
|
|
|
|
|
2019-06-11 16:12:37 +07:00
|
|
|
if (vm) {
|
2019-08-31 00:59:58 +07:00
|
|
|
ret = load_pd_dir(rq, i915_vm_to_ppgtt(vm));
|
|
|
|
if (ret)
|
|
|
|
return ret;
|
2017-11-23 22:26:31 +07:00
|
|
|
}
|
|
|
|
|
2019-08-31 00:59:58 +07:00
|
|
|
if (ce->state) {
|
|
|
|
u32 hw_flags;
|
|
|
|
|
|
|
|
GEM_BUG_ON(rq->engine->id != RCS0);
|
2017-11-23 22:26:31 +07:00
|
|
|
|
|
|
|
/*
|
|
|
|
* The kernel context(s) is treated as pure scratch and is not
|
|
|
|
* expected to retain any state (as we sacrifice it during
|
|
|
|
* suspend and on resume it may be corrupted). This is ok,
|
|
|
|
* as nothing actually executes using the kernel context; it
|
|
|
|
* is purely used for flushing user contexts.
|
|
|
|
*/
|
2019-08-31 00:59:58 +07:00
|
|
|
hw_flags = 0;
|
2019-07-30 21:32:08 +07:00
|
|
|
if (i915_gem_context_is_kernel(rq->gem_context))
|
2017-11-23 22:26:31 +07:00
|
|
|
hw_flags = MI_RESTORE_INHIBIT;
|
|
|
|
|
|
|
|
ret = mi_set_context(rq, hw_flags);
|
|
|
|
if (ret)
|
2019-08-31 00:59:58 +07:00
|
|
|
return ret;
|
2017-11-23 22:26:31 +07:00
|
|
|
}
|
|
|
|
|
2019-06-11 16:12:37 +07:00
|
|
|
if (vm) {
|
2019-08-31 00:59:58 +07:00
|
|
|
struct intel_engine_cs *engine = rq->engine;
|
|
|
|
|
2018-09-04 13:38:02 +07:00
|
|
|
ret = engine->emit_flush(rq, EMIT_INVALIDATE);
|
|
|
|
if (ret)
|
2019-08-31 00:59:58 +07:00
|
|
|
return ret;
|
2018-09-04 13:38:02 +07:00
|
|
|
|
2018-06-12 00:18:25 +07:00
|
|
|
ret = flush_pd_dir(rq);
|
|
|
|
if (ret)
|
2019-08-31 00:59:58 +07:00
|
|
|
return ret;
|
2018-09-04 13:38:02 +07:00
|
|
|
|
|
|
|
/*
|
|
|
|
* Not only do we need a full barrier (post-sync write) after
|
|
|
|
* invalidating the TLBs, but we need to wait a little bit
|
|
|
|
* longer. Whether this is merely delaying us, or the
|
|
|
|
* subsequent flush is a key part of serialising with the
|
|
|
|
* post-sync op, this extra pass appears vital before a
|
|
|
|
* mm switch!
|
|
|
|
*/
|
|
|
|
ret = engine->emit_flush(rq, EMIT_INVALIDATE);
|
|
|
|
if (ret)
|
2019-08-31 00:59:58 +07:00
|
|
|
return ret;
|
2018-09-04 13:38:02 +07:00
|
|
|
|
|
|
|
ret = engine->emit_flush(rq, EMIT_FLUSH);
|
|
|
|
if (ret)
|
2019-08-31 00:59:58 +07:00
|
|
|
return ret;
|
2017-11-23 22:26:31 +07:00
|
|
|
}
|
|
|
|
|
2019-07-30 21:32:08 +07:00
|
|
|
ret = remap_l3(rq);
|
|
|
|
if (ret)
|
2019-08-31 00:59:58 +07:00
|
|
|
return ret;
|
2017-11-23 22:26:31 +07:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-02-21 16:56:36 +07:00
|
|
|
static int ring_request_alloc(struct i915_request *request)
|
2012-11-27 23:22:52 +07:00
|
|
|
{
|
2017-11-15 22:12:04 +07:00
|
|
|
int ret;
|
2016-04-28 15:56:49 +07:00
|
|
|
|
2019-03-08 20:25:22 +07:00
|
|
|
GEM_BUG_ON(!intel_context_is_pinned(request->hw_context));
|
drm/i915: Mark i915_request.timeline as a volatile, rcu pointer
The request->timeline is only valid until the request is retired (i.e.
before it is completed). Upon retiring the request, the context may be
unpinned and freed, and along with it the timeline may be freed. We
therefore need to be very careful when chasing rq->timeline that the
pointer does not disappear beneath us. The vast majority of users are in
a protected context, either during request construction or retirement,
where the timeline->mutex is held and the timeline cannot disappear. It
is those few off the beaten path (where we access a second timeline) that
need extra scrutiny -- to be added in the next patch after first adding
the warnings about dangerous access.
One complication, where we cannot use the timeline->mutex itself, is
during request submission onto hardware (under spinlocks). Here, we want
to check on the timeline to finalize the breadcrumb, and so we need to
impose a second rule to ensure that the request->timeline is indeed
valid. As we are submitting the request, it's context and timeline must
be pinned, as it will be used by the hardware. Since it is pinned, we
know the request->timeline must still be valid, and we cannot submit the
idle barrier until after we release the engine->active.lock, ergo while
submitting and holding that spinlock, a second thread cannot release the
timeline.
v2: Don't be lazy inside selftests; hold the timeline->mutex for as long
as we need it, and tidy up acquiring the timeline with a bit of
refactoring (i915_active_add_request)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190919111912.21631-1-chris@chris-wilson.co.uk
2019-09-19 18:19:10 +07:00
|
|
|
GEM_BUG_ON(i915_request_timeline(request)->has_initial_breadcrumb);
|
drm/i915: Unify active context tracking between legacy/execlists/guc
The requests conversion introduced a nasty bug where we could generate a
new request in the middle of constructing a request if we needed to idle
the system in order to evict space for a context. The request to idle
would be executed (and waited upon) before the current one, creating a
minor havoc in the seqno accounting, as we will consider the current
request to already be completed (prior to deferred seqno assignment) but
ring->last_retired_head would have been updated and still could allow
us to overwrite the current request before execution.
We also employed two different mechanisms to track the active context
until it was switched out. The legacy method allowed for waiting upon an
active context (it could forcibly evict any vma, including context's),
but the execlists method took a step backwards by pinning the vma for
the entire active lifespan of the context (the only way to evict was to
idle the entire GPU, not individual contexts). However, to circumvent
the tricky issue of locking (i.e. we cannot take struct_mutex at the
time of i915_gem_request_submit(), where we would want to move the
previous context onto the active tracker and unpin it), we take the
execlists approach and keep the contexts pinned until retirement.
The benefit of the execlists approach, more important for execlists than
legacy, was the reduction in work in pinning the context for each
request - as the context was kept pinned until idle, it could short
circuit the pinning for all active contexts.
We introduce new engine vfuncs to pin and unpin the context
respectively. The context is pinned at the start of the request, and
only unpinned when the following request is retired (this ensures that
the context is idle and coherent in main memory before we unpin it). We
move the engine->last_context tracking into the retirement itself
(rather than during request submission) in order to allow the submission
to be reordered or unwound without undue difficultly.
And finally an ulterior motive for unifying context handling was to
prepare for mock requests.
v2: Rename to last_retired_context, split out legacy_context tracking
for MI_SET_CONTEXT.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: http://patchwork.freedesktop.org/patch/msgid/20161218153724.8439-3-chris@chris-wilson.co.uk
2016-12-18 22:37:20 +07:00
|
|
|
|
2018-12-07 16:02:11 +07:00
|
|
|
/*
|
|
|
|
* Flush enough space to reduce the likelihood of waiting after
|
2016-04-28 15:56:49 +07:00
|
|
|
* we start building the request - in which case we will just
|
|
|
|
* have to repeat work.
|
|
|
|
*/
|
2016-04-29 15:07:05 +07:00
|
|
|
request->reserved_space += LEGACY_REQUEST_SIZE;
|
2016-04-28 15:56:49 +07:00
|
|
|
|
2019-04-19 18:17:47 +07:00
|
|
|
/* Unconditionally invalidate GPU caches and TLBs. */
|
|
|
|
ret = request->engine->emit_flush(request, EMIT_INVALIDATE);
|
2017-11-15 22:12:04 +07:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
2016-04-28 15:56:49 +07:00
|
|
|
|
2019-04-19 18:17:47 +07:00
|
|
|
ret = switch_context(request);
|
2017-11-20 17:20:02 +07:00
|
|
|
if (ret)
|
|
|
|
return ret;
|
|
|
|
|
2016-04-29 15:07:05 +07:00
|
|
|
request->reserved_space -= LEGACY_REQUEST_SIZE;
|
2016-04-28 15:56:49 +07:00
|
|
|
return 0;
|
2012-11-27 23:22:52 +07:00
|
|
|
}
|
|
|
|
|
2019-08-16 03:57:09 +07:00
|
|
|
static noinline int
|
|
|
|
wait_for_space(struct intel_ring *ring,
|
|
|
|
struct intel_timeline *tl,
|
|
|
|
unsigned int bytes)
|
2016-04-28 15:56:46 +07:00
|
|
|
{
|
2018-02-21 16:56:36 +07:00
|
|
|
struct i915_request *target;
|
2016-10-28 19:58:27 +07:00
|
|
|
long timeout;
|
|
|
|
|
2017-05-04 20:08:45 +07:00
|
|
|
if (intel_ring_update_space(ring) >= bytes)
|
2016-04-28 15:56:46 +07:00
|
|
|
return 0;
|
|
|
|
|
2019-08-16 03:57:09 +07:00
|
|
|
GEM_BUG_ON(list_empty(&tl->requests));
|
|
|
|
list_for_each_entry(target, &tl->requests, link) {
|
|
|
|
if (target->ring != ring)
|
|
|
|
continue;
|
|
|
|
|
2016-04-28 15:56:46 +07:00
|
|
|
/* Would completion of this request free enough space? */
|
2017-05-04 20:08:44 +07:00
|
|
|
if (bytes <= __intel_ring_space(target->postfix,
|
|
|
|
ring->emit, ring->size))
|
2016-04-28 15:56:46 +07:00
|
|
|
break;
|
2015-06-30 18:40:55 +07:00
|
|
|
}
|
drm/i915: Reserve ring buffer space for i915_add_request() commands
It is a bad idea for i915_add_request() to fail. The work will already have been
send to the ring and will be processed, but there will not be any tracking or
management of that work.
The only way the add request call can fail is if it can't write its epilogue
commands to the ring (cache flushing, seqno updates, interrupt signalling). The
reasons for that are mostly down to running out of ring buffer space and the
problems associated with trying to get some more. This patch prevents that
situation from happening in the first place.
When a request is created, it marks sufficient space as reserved for the
epilogue commands. Thus guaranteeing that by the time the epilogue is written,
there will be plenty of space for it. Note that a ring_begin() call is required
to actually reserve the space (and do any potential waiting). However, that is
not currently done at request creation time. This is because the ring_begin()
code can allocate a request. Hence calling begin() from the request allocation
code would lead to infinite recursion! Later patches in this series remove the
need for begin() to do the allocate. At that point, it becomes safe for the
allocate to call begin() and really reserve the space.
Until then, there is a potential for insufficient space to be available at the
point of calling i915_add_request(). However, that would only be in the case
where the request was created and immediately submitted without ever calling
ring_begin() and adding any work to that request. Which should never happen. And
even if it does, and if that request happens to fall down the tiny window of
opportunity for failing due to being out of ring space then does it really
matter because the request wasn't doing anything in the first place?
v2: Updated the 'reserved space too small' warning to include the offending
sizes. Added a 'cancel' operation to clean up when a request is abandoned. Added
re-initialisation of tracking state after a buffer wrap to keep the sanity
checks accurate.
v3: Incremented the reserved size to accommodate Ironlake (after finally
managing to run on an ILK system). Also fixed missing wrap code in LRC mode.
v4: Added extra comment and removed duplicate WARN (feedback from Tomas).
For: VIZ-5115
CC: Tomas Elf <tomas.elf@intel.com>
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-06-18 19:10:09 +07:00
|
|
|
|
2019-08-16 03:57:09 +07:00
|
|
|
if (GEM_WARN_ON(&target->link == &tl->requests))
|
2016-04-28 15:56:46 +07:00
|
|
|
return -ENOSPC;
|
|
|
|
|
2018-02-21 16:56:36 +07:00
|
|
|
timeout = i915_request_wait(target,
|
2019-06-18 14:41:30 +07:00
|
|
|
I915_WAIT_INTERRUPTIBLE,
|
2016-10-28 19:58:27 +07:00
|
|
|
MAX_SCHEDULE_TIMEOUT);
|
|
|
|
if (timeout < 0)
|
|
|
|
return timeout;
|
2016-08-04 13:52:38 +07:00
|
|
|
|
2018-02-21 16:56:36 +07:00
|
|
|
i915_request_retire_upto(target);
|
2016-08-04 13:52:38 +07:00
|
|
|
|
|
|
|
intel_ring_update_space(ring);
|
|
|
|
GEM_BUG_ON(ring->space < bytes);
|
|
|
|
return 0;
|
drm/i915: Reserve ring buffer space for i915_add_request() commands
It is a bad idea for i915_add_request() to fail. The work will already have been
send to the ring and will be processed, but there will not be any tracking or
management of that work.
The only way the add request call can fail is if it can't write its epilogue
commands to the ring (cache flushing, seqno updates, interrupt signalling). The
reasons for that are mostly down to running out of ring buffer space and the
problems associated with trying to get some more. This patch prevents that
situation from happening in the first place.
When a request is created, it marks sufficient space as reserved for the
epilogue commands. Thus guaranteeing that by the time the epilogue is written,
there will be plenty of space for it. Note that a ring_begin() call is required
to actually reserve the space (and do any potential waiting). However, that is
not currently done at request creation time. This is because the ring_begin()
code can allocate a request. Hence calling begin() from the request allocation
code would lead to infinite recursion! Later patches in this series remove the
need for begin() to do the allocate. At that point, it becomes safe for the
allocate to call begin() and really reserve the space.
Until then, there is a potential for insufficient space to be available at the
point of calling i915_add_request(). However, that would only be in the case
where the request was created and immediately submitted without ever calling
ring_begin() and adding any work to that request. Which should never happen. And
even if it does, and if that request happens to fall down the tiny window of
opportunity for failing due to being out of ring space then does it really
matter because the request wasn't doing anything in the first place?
v2: Updated the 'reserved space too small' warning to include the offending
sizes. Added a 'cancel' operation to clean up when a request is abandoned. Added
re-initialisation of tracking state after a buffer wrap to keep the sanity
checks accurate.
v3: Incremented the reserved size to accommodate Ironlake (after finally
managing to run on an ILK system). Also fixed missing wrap code in LRC mode.
v4: Added extra comment and removed duplicate WARN (feedback from Tomas).
For: VIZ-5115
CC: Tomas Elf <tomas.elf@intel.com>
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-06-18 19:10:09 +07:00
|
|
|
}
|
|
|
|
|
2018-02-21 16:56:36 +07:00
|
|
|
u32 *intel_ring_begin(struct i915_request *rq, unsigned int num_dwords)
|
2012-12-04 20:12:03 +07:00
|
|
|
{
|
2018-02-21 16:56:36 +07:00
|
|
|
struct intel_ring *ring = rq->ring;
|
2017-05-04 20:08:46 +07:00
|
|
|
const unsigned int remain_usable = ring->effective_size - ring->emit;
|
|
|
|
const unsigned int bytes = num_dwords * sizeof(u32);
|
|
|
|
unsigned int need_wrap = 0;
|
|
|
|
unsigned int total_bytes;
|
2017-02-14 18:32:42 +07:00
|
|
|
u32 *cs;
|
drm/i915: Reserve ring buffer space for i915_add_request() commands
It is a bad idea for i915_add_request() to fail. The work will already have been
send to the ring and will be processed, but there will not be any tracking or
management of that work.
The only way the add request call can fail is if it can't write its epilogue
commands to the ring (cache flushing, seqno updates, interrupt signalling). The
reasons for that are mostly down to running out of ring buffer space and the
problems associated with trying to get some more. This patch prevents that
situation from happening in the first place.
When a request is created, it marks sufficient space as reserved for the
epilogue commands. Thus guaranteeing that by the time the epilogue is written,
there will be plenty of space for it. Note that a ring_begin() call is required
to actually reserve the space (and do any potential waiting). However, that is
not currently done at request creation time. This is because the ring_begin()
code can allocate a request. Hence calling begin() from the request allocation
code would lead to infinite recursion! Later patches in this series remove the
need for begin() to do the allocate. At that point, it becomes safe for the
allocate to call begin() and really reserve the space.
Until then, there is a potential for insufficient space to be available at the
point of calling i915_add_request(). However, that would only be in the case
where the request was created and immediately submitted without ever calling
ring_begin() and adding any work to that request. Which should never happen. And
even if it does, and if that request happens to fall down the tiny window of
opportunity for failing due to being out of ring space then does it really
matter because the request wasn't doing anything in the first place?
v2: Updated the 'reserved space too small' warning to include the offending
sizes. Added a 'cancel' operation to clean up when a request is abandoned. Added
re-initialisation of tracking state after a buffer wrap to keep the sanity
checks accurate.
v3: Incremented the reserved size to accommodate Ironlake (after finally
managing to run on an ILK system). Also fixed missing wrap code in LRC mode.
v4: Added extra comment and removed duplicate WARN (feedback from Tomas).
For: VIZ-5115
CC: Tomas Elf <tomas.elf@intel.com>
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-06-18 19:10:09 +07:00
|
|
|
|
2017-07-21 23:11:01 +07:00
|
|
|
/* Packets must be qword aligned. */
|
|
|
|
GEM_BUG_ON(num_dwords & 1);
|
|
|
|
|
2018-02-21 16:56:36 +07:00
|
|
|
total_bytes = bytes + rq->reserved_space;
|
2017-05-04 20:08:46 +07:00
|
|
|
GEM_BUG_ON(total_bytes > ring->effective_size);
|
drm/i915: Reserve ring buffer space for i915_add_request() commands
It is a bad idea for i915_add_request() to fail. The work will already have been
send to the ring and will be processed, but there will not be any tracking or
management of that work.
The only way the add request call can fail is if it can't write its epilogue
commands to the ring (cache flushing, seqno updates, interrupt signalling). The
reasons for that are mostly down to running out of ring buffer space and the
problems associated with trying to get some more. This patch prevents that
situation from happening in the first place.
When a request is created, it marks sufficient space as reserved for the
epilogue commands. Thus guaranteeing that by the time the epilogue is written,
there will be plenty of space for it. Note that a ring_begin() call is required
to actually reserve the space (and do any potential waiting). However, that is
not currently done at request creation time. This is because the ring_begin()
code can allocate a request. Hence calling begin() from the request allocation
code would lead to infinite recursion! Later patches in this series remove the
need for begin() to do the allocate. At that point, it becomes safe for the
allocate to call begin() and really reserve the space.
Until then, there is a potential for insufficient space to be available at the
point of calling i915_add_request(). However, that would only be in the case
where the request was created and immediately submitted without ever calling
ring_begin() and adding any work to that request. Which should never happen. And
even if it does, and if that request happens to fall down the tiny window of
opportunity for failing due to being out of ring space then does it really
matter because the request wasn't doing anything in the first place?
v2: Updated the 'reserved space too small' warning to include the offending
sizes. Added a 'cancel' operation to clean up when a request is abandoned. Added
re-initialisation of tracking state after a buffer wrap to keep the sanity
checks accurate.
v3: Incremented the reserved size to accommodate Ironlake (after finally
managing to run on an ILK system). Also fixed missing wrap code in LRC mode.
v4: Added extra comment and removed duplicate WARN (feedback from Tomas).
For: VIZ-5115
CC: Tomas Elf <tomas.elf@intel.com>
Signed-off-by: John Harrison <John.C.Harrison@Intel.com>
Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
2015-06-18 19:10:09 +07:00
|
|
|
|
2017-05-04 20:08:46 +07:00
|
|
|
if (unlikely(total_bytes > remain_usable)) {
|
|
|
|
const int remain_actual = ring->size - ring->emit;
|
|
|
|
|
|
|
|
if (bytes > remain_usable) {
|
|
|
|
/*
|
|
|
|
* Not enough space for the basic request. So need to
|
|
|
|
* flush out the remainder and then wait for
|
|
|
|
* base + reserved.
|
|
|
|
*/
|
|
|
|
total_bytes += remain_actual;
|
|
|
|
need_wrap = remain_actual | 1;
|
|
|
|
} else {
|
|
|
|
/*
|
|
|
|
* The base request will fit but the reserved space
|
|
|
|
* falls off the end. So we don't need an immediate
|
|
|
|
* wrap and only need to effectively wait for the
|
|
|
|
* reserved size from the start of ringbuffer.
|
|
|
|
*/
|
2018-02-21 16:56:36 +07:00
|
|
|
total_bytes = rq->reserved_space + remain_actual;
|
2017-05-04 20:08:46 +07:00
|
|
|
}
|
2012-12-04 20:12:03 +07:00
|
|
|
}
|
|
|
|
|
2017-05-04 20:08:46 +07:00
|
|
|
if (unlikely(total_bytes > ring->space)) {
|
2017-11-15 22:12:04 +07:00
|
|
|
int ret;
|
|
|
|
|
|
|
|
/*
|
|
|
|
* Space is reserved in the ringbuffer for finalising the
|
|
|
|
* request, as that cannot be allowed to fail. During request
|
|
|
|
* finalisation, reserved_space is set to 0 to stop the
|
|
|
|
* overallocation and the assumption is that then we never need
|
|
|
|
* to wait (which has the risk of failing with EINTR).
|
|
|
|
*
|
2018-02-21 16:56:36 +07:00
|
|
|
* See also i915_request_alloc() and i915_request_add().
|
2017-11-15 22:12:04 +07:00
|
|
|
*/
|
2018-02-21 16:56:36 +07:00
|
|
|
GEM_BUG_ON(!rq->reserved_space);
|
2017-11-15 22:12:04 +07:00
|
|
|
|
drm/i915: Mark i915_request.timeline as a volatile, rcu pointer
The request->timeline is only valid until the request is retired (i.e.
before it is completed). Upon retiring the request, the context may be
unpinned and freed, and along with it the timeline may be freed. We
therefore need to be very careful when chasing rq->timeline that the
pointer does not disappear beneath us. The vast majority of users are in
a protected context, either during request construction or retirement,
where the timeline->mutex is held and the timeline cannot disappear. It
is those few off the beaten path (where we access a second timeline) that
need extra scrutiny -- to be added in the next patch after first adding
the warnings about dangerous access.
One complication, where we cannot use the timeline->mutex itself, is
during request submission onto hardware (under spinlocks). Here, we want
to check on the timeline to finalize the breadcrumb, and so we need to
impose a second rule to ensure that the request->timeline is indeed
valid. As we are submitting the request, it's context and timeline must
be pinned, as it will be used by the hardware. Since it is pinned, we
know the request->timeline must still be valid, and we cannot submit the
idle barrier until after we release the engine->active.lock, ergo while
submitting and holding that spinlock, a second thread cannot release the
timeline.
v2: Don't be lazy inside selftests; hold the timeline->mutex for as long
as we need it, and tidy up acquiring the timeline with a bit of
refactoring (i915_active_add_request)
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190919111912.21631-1-chris@chris-wilson.co.uk
2019-09-19 18:19:10 +07:00
|
|
|
ret = wait_for_space(ring,
|
|
|
|
i915_request_timeline(rq),
|
|
|
|
total_bytes);
|
2012-12-04 20:12:03 +07:00
|
|
|
if (unlikely(ret))
|
2017-02-14 18:32:42 +07:00
|
|
|
return ERR_PTR(ret);
|
2012-12-04 20:12:03 +07:00
|
|
|
}
|
|
|
|
|
2016-04-28 15:56:46 +07:00
|
|
|
if (unlikely(need_wrap)) {
|
2017-05-04 20:08:46 +07:00
|
|
|
need_wrap &= ~1;
|
|
|
|
GEM_BUG_ON(need_wrap > ring->space);
|
|
|
|
GEM_BUG_ON(ring->emit + need_wrap > ring->size);
|
2018-03-19 19:35:28 +07:00
|
|
|
GEM_BUG_ON(!IS_ALIGNED(need_wrap, sizeof(u64)));
|
2010-10-27 18:18:21 +07:00
|
|
|
|
2016-04-28 15:56:46 +07:00
|
|
|
/* Fill the tail with MI_NOOP */
|
2018-03-19 19:35:28 +07:00
|
|
|
memset64(ring->vaddr + ring->emit, 0, need_wrap / sizeof(u64));
|
2017-05-04 20:08:46 +07:00
|
|
|
ring->space -= need_wrap;
|
2018-03-19 19:35:28 +07:00
|
|
|
ring->emit = 0;
|
2016-04-28 15:56:46 +07:00
|
|
|
}
|
2014-01-02 21:32:35 +07:00
|
|
|
|
2017-04-25 20:00:49 +07:00
|
|
|
GEM_BUG_ON(ring->emit > ring->size - bytes);
|
2017-05-04 20:08:44 +07:00
|
|
|
GEM_BUG_ON(ring->space < bytes);
|
2017-04-25 20:00:49 +07:00
|
|
|
cs = ring->vaddr + ring->emit;
|
2018-03-19 19:35:28 +07:00
|
|
|
GEM_DEBUG_EXEC(memset32(cs, POISON_INUSE, bytes / sizeof(*cs)));
|
2017-04-25 20:00:49 +07:00
|
|
|
ring->emit += bytes;
|
2016-08-03 04:50:19 +07:00
|
|
|
ring->space -= bytes;
|
2017-02-14 18:32:42 +07:00
|
|
|
|
|
|
|
return cs;
|
2010-05-21 08:08:55 +07:00
|
|
|
}
|
2010-10-27 18:18:21 +07:00
|
|
|
|
2014-02-12 00:52:05 +07:00
|
|
|
/* Align the ring tail to a cacheline boundary */
|
2018-02-21 16:56:36 +07:00
|
|
|
int intel_ring_cacheline_align(struct i915_request *rq)
|
2014-02-12 00:52:05 +07:00
|
|
|
{
|
2018-04-25 19:37:18 +07:00
|
|
|
int num_dwords;
|
|
|
|
void *cs;
|
2014-02-12 00:52:05 +07:00
|
|
|
|
2018-04-25 19:37:18 +07:00
|
|
|
num_dwords = (rq->ring->emit & (CACHELINE_BYTES - 1)) / sizeof(u32);
|
2014-02-12 00:52:05 +07:00
|
|
|
if (num_dwords == 0)
|
|
|
|
return 0;
|
|
|
|
|
2018-04-25 19:37:18 +07:00
|
|
|
num_dwords = CACHELINE_DWORDS - num_dwords;
|
|
|
|
GEM_BUG_ON(num_dwords & 1);
|
|
|
|
|
2018-02-21 16:56:36 +07:00
|
|
|
cs = intel_ring_begin(rq, num_dwords);
|
2017-02-14 18:32:42 +07:00
|
|
|
if (IS_ERR(cs))
|
|
|
|
return PTR_ERR(cs);
|
2014-02-12 00:52:05 +07:00
|
|
|
|
2018-04-25 19:37:18 +07:00
|
|
|
memset64(cs, (u64)MI_NOOP << 32 | MI_NOOP, num_dwords / 2);
|
2018-02-21 16:56:36 +07:00
|
|
|
intel_ring_advance(rq, cs);
|
2014-02-12 00:52:05 +07:00
|
|
|
|
2018-04-25 19:37:18 +07:00
|
|
|
GEM_BUG_ON(rq->ring->emit & (CACHELINE_BYTES - 1));
|
2014-02-12 00:52:05 +07:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-02-21 16:56:36 +07:00
|
|
|
static void gen6_bsd_submit_request(struct i915_request *request)
|
2010-09-19 20:40:43 +07:00
|
|
|
{
|
2019-03-26 04:49:40 +07:00
|
|
|
struct intel_uncore *uncore = request->engine->uncore;
|
2010-09-19 20:40:43 +07:00
|
|
|
|
2019-03-26 04:49:38 +07:00
|
|
|
intel_uncore_forcewake_get(uncore, FORCEWAKE_ALL);
|
2016-06-30 21:33:45 +07:00
|
|
|
|
2010-09-19 20:40:43 +07:00
|
|
|
/* Every tail move must follow the sequence below */
|
2012-07-05 23:14:01 +07:00
|
|
|
|
|
|
|
/* Disable notification that the ring is IDLE. The GT
|
|
|
|
* will then assume that it is busy and bring it out of rc6.
|
|
|
|
*/
|
2019-03-26 04:49:38 +07:00
|
|
|
intel_uncore_write_fw(uncore, GEN6_BSD_SLEEP_PSMI_CONTROL,
|
|
|
|
_MASKED_BIT_ENABLE(GEN6_BSD_SLEEP_MSG_DISABLE));
|
2012-07-05 23:14:01 +07:00
|
|
|
|
|
|
|
/* Clear the context id. Here be magic! */
|
2019-03-26 04:49:38 +07:00
|
|
|
intel_uncore_write64_fw(uncore, GEN6_BSD_RNCID, 0x0);
|
2011-08-17 02:34:10 +07:00
|
|
|
|
2012-07-05 23:14:01 +07:00
|
|
|
/* Wait for the ring not to be idle, i.e. for it to wake up. */
|
2019-03-26 04:49:38 +07:00
|
|
|
if (__intel_wait_for_register_fw(uncore,
|
2017-04-11 17:13:37 +07:00
|
|
|
GEN6_BSD_SLEEP_PSMI_CONTROL,
|
|
|
|
GEN6_BSD_SLEEP_INDICATOR,
|
|
|
|
0,
|
|
|
|
1000, 0, NULL))
|
2012-07-05 23:14:01 +07:00
|
|
|
DRM_ERROR("timed out waiting for the BSD ring to wake up\n");
|
2011-08-17 02:34:10 +07:00
|
|
|
|
2012-07-05 23:14:01 +07:00
|
|
|
/* Now that the ring is fully powered up, update the tail */
|
2016-08-03 04:50:34 +07:00
|
|
|
i9xx_submit_request(request);
|
2012-07-05 23:14:01 +07:00
|
|
|
|
|
|
|
/* Let the ring send IDLE messages to the GT again,
|
|
|
|
* and so let it sleep to conserve power when idle.
|
|
|
|
*/
|
2019-03-26 04:49:38 +07:00
|
|
|
intel_uncore_write_fw(uncore, GEN6_BSD_SLEEP_PSMI_CONTROL,
|
|
|
|
_MASKED_BIT_DISABLE(GEN6_BSD_SLEEP_MSG_DISABLE));
|
2016-06-30 21:33:45 +07:00
|
|
|
|
2019-03-26 04:49:38 +07:00
|
|
|
intel_uncore_forcewake_put(uncore, FORCEWAKE_ALL);
|
2010-09-19 20:40:43 +07:00
|
|
|
}
|
|
|
|
|
2018-09-04 13:38:02 +07:00
|
|
|
static int mi_flush_dw(struct i915_request *rq, u32 flags)
|
2010-09-19 20:40:43 +07:00
|
|
|
{
|
2017-02-14 18:32:42 +07:00
|
|
|
u32 cmd, *cs;
|
2011-01-05 00:34:02 +07:00
|
|
|
|
2018-02-21 16:56:36 +07:00
|
|
|
cs = intel_ring_begin(rq, 4);
|
2017-02-14 18:32:42 +07:00
|
|
|
if (IS_ERR(cs))
|
|
|
|
return PTR_ERR(cs);
|
2011-01-05 00:34:02 +07:00
|
|
|
|
2011-02-02 19:13:49 +07:00
|
|
|
cmd = MI_FLUSH_DW;
|
2015-01-22 20:42:00 +07:00
|
|
|
|
2018-08-30 23:10:42 +07:00
|
|
|
/*
|
|
|
|
* We always require a command barrier so that subsequent
|
2015-01-22 20:42:00 +07:00
|
|
|
* commands, such as breadcrumb interrupts, are strictly ordered
|
|
|
|
* wrt the contents of the write cache being flushed to memory
|
|
|
|
* (and thus being coherent from the CPU).
|
|
|
|
*/
|
|
|
|
cmd |= MI_FLUSH_DW_STORE_INDEX | MI_FLUSH_DW_OP_STOREDW;
|
|
|
|
|
2012-10-26 23:42:42 +07:00
|
|
|
/*
|
2018-08-30 23:10:42 +07:00
|
|
|
* Bspec vol 1c.3 - blitter engine command streamer:
|
2012-10-26 23:42:42 +07:00
|
|
|
* "If ENABLED, all TLBs will be invalidated once the flush
|
|
|
|
* operation is complete. This bit is only valid when the
|
|
|
|
* Post-Sync Operation field is a value of 1h or 3h."
|
|
|
|
*/
|
2018-08-30 23:10:42 +07:00
|
|
|
cmd |= flags;
|
2015-01-22 20:42:00 +07:00
|
|
|
|
2017-02-14 18:32:42 +07:00
|
|
|
*cs++ = cmd;
|
|
|
|
*cs++ = I915_GEM_HWS_SCRATCH_ADDR | MI_FLUSH_DW_USE_GTT;
|
drm/i915: Remove obsolete ringbuffer emission for gen8+
Since removing the module parameter to force selection of ringbuffer
emission for gen8, the code is defunct. Remove it.
To put the difference into perspective, a couple of microbenchmarks
(bdw i7-5557u, 20170324):
ring execlists
exec continuous nops on all rings: 1.491us 2.223us
exec sequential nops on each ring: 12.508us 53.682us
single nop + sync: 9.272us 30.291us
vblank_mode=0 glxgears: ~11000fps ~9000fps
Since the earlier submission, gen8 ringbuffer submission has fallen
further and further behind in features. So while ringbuffer may hold the
throughput crown, in terms of interactive latency, execlists is much
better. Alas, we have no convenient metrics for such, other than
demonstrating things we can do with execlists but can not using
legacy ringbuffer submission.
We have made a few improvements to lowlevel execlists throughput,
and ringbuffer currently panics on boot! (bdw i7-5557u, 20171026):
ring execlists
exec continuous nops on all rings: n/a 1.921us
exec sequential nops on each ring: n/a 44.621us
single nop + sync: n/a 21.953us
vblank_mode=0 glxgears: n/a ~18500fps
References: https://bugs.freedesktop.org/show_bug.cgi?id=87725
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Once-upon-a-time-Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171120205504.21892-2-chris@chris-wilson.co.uk
2017-11-21 03:55:01 +07:00
|
|
|
*cs++ = 0;
|
2017-02-14 18:32:42 +07:00
|
|
|
*cs++ = MI_NOOP;
|
2018-08-30 23:10:42 +07:00
|
|
|
|
2018-02-21 16:56:36 +07:00
|
|
|
intel_ring_advance(rq, cs);
|
2018-08-30 23:10:42 +07:00
|
|
|
|
2013-11-03 11:07:12 +07:00
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2018-08-30 23:10:42 +07:00
|
|
|
static int gen6_flush_dw(struct i915_request *rq, u32 mode, u32 invflags)
|
|
|
|
{
|
2018-09-04 13:38:02 +07:00
|
|
|
return mi_flush_dw(rq, mode & EMIT_INVALIDATE ? invflags : 0);
|
2018-08-30 23:10:42 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
static int gen6_bsd_ring_flush(struct i915_request *rq, u32 mode)
|
|
|
|
{
|
|
|
|
return gen6_flush_dw(rq, mode, MI_INVALIDATE_TLB | MI_INVALIDATE_BSD);
|
|
|
|
}
|
|
|
|
|
2012-10-17 18:09:54 +07:00
|
|
|
static int
|
2018-02-21 16:56:36 +07:00
|
|
|
hsw_emit_bb_start(struct i915_request *rq,
|
2016-08-03 04:50:27 +07:00
|
|
|
u64 offset, u32 len,
|
|
|
|
unsigned int dispatch_flags)
|
2012-10-17 18:09:54 +07:00
|
|
|
{
|
2017-02-14 18:32:42 +07:00
|
|
|
u32 *cs;
|
2012-10-17 18:09:54 +07:00
|
|
|
|
2018-02-21 16:56:36 +07:00
|
|
|
cs = intel_ring_begin(rq, 2);
|
2017-02-14 18:32:42 +07:00
|
|
|
if (IS_ERR(cs))
|
|
|
|
return PTR_ERR(cs);
|
2012-10-17 18:09:54 +07:00
|
|
|
|
2017-02-14 18:32:42 +07:00
|
|
|
*cs++ = MI_BATCH_BUFFER_START | (dispatch_flags & I915_DISPATCH_SECURE ?
|
2018-08-04 06:24:43 +07:00
|
|
|
0 : MI_BATCH_PPGTT_HSW | MI_BATCH_NON_SECURE_HSW);
|
2012-10-17 18:09:54 +07:00
|
|
|
/* bit0-7 is the length on GEN6+ */
|
2017-02-14 18:32:42 +07:00
|
|
|
*cs++ = offset;
|
2018-02-21 16:56:36 +07:00
|
|
|
intel_ring_advance(rq, cs);
|
2012-10-17 18:09:54 +07:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
2010-09-19 20:40:43 +07:00
|
|
|
static int
|
2018-02-21 16:56:36 +07:00
|
|
|
gen6_emit_bb_start(struct i915_request *rq,
|
2016-08-03 04:50:27 +07:00
|
|
|
u64 offset, u32 len,
|
|
|
|
unsigned int dispatch_flags)
|
2010-09-19 20:40:43 +07:00
|
|
|
{
|
2017-02-14 18:32:42 +07:00
|
|
|
u32 *cs;
|
2010-09-19 23:53:44 +07:00
|
|
|
|
2018-02-21 16:56:36 +07:00
|
|
|
cs = intel_ring_begin(rq, 2);
|
2017-02-14 18:32:42 +07:00
|
|
|
if (IS_ERR(cs))
|
|
|
|
return PTR_ERR(cs);
|
2010-10-27 18:45:26 +07:00
|
|
|
|
2017-02-14 18:32:42 +07:00
|
|
|
*cs++ = MI_BATCH_BUFFER_START | (dispatch_flags & I915_DISPATCH_SECURE ?
|
|
|
|
0 : MI_BATCH_NON_SECURE_I965);
|
2011-08-17 02:34:10 +07:00
|
|
|
/* bit0-7 is the length on GEN6+ */
|
2017-02-14 18:32:42 +07:00
|
|
|
*cs++ = offset;
|
2018-02-21 16:56:36 +07:00
|
|
|
intel_ring_advance(rq, cs);
|
2010-09-19 23:53:44 +07:00
|
|
|
|
2011-08-17 02:34:10 +07:00
|
|
|
return 0;
|
2010-09-19 20:40:43 +07:00
|
|
|
}
|
|
|
|
|
2010-10-19 17:19:32 +07:00
|
|
|
/* Blitter support (SandyBridge+) */
|
|
|
|
|
2018-02-21 16:56:36 +07:00
|
|
|
static int gen6_ring_flush(struct i915_request *rq, u32 mode)
|
2010-11-02 15:31:01 +07:00
|
|
|
{
|
2018-08-30 23:10:42 +07:00
|
|
|
return gen6_flush_dw(rq, mode, MI_INVALIDATE_TLB);
|
2010-11-02 15:31:01 +07:00
|
|
|
}
|
|
|
|
|
2017-03-17 00:13:03 +07:00
|
|
|
static void i9xx_set_default_submission(struct intel_engine_cs *engine)
|
|
|
|
{
|
|
|
|
engine->submit_request = i9xx_submit_request;
|
2017-09-16 00:31:00 +07:00
|
|
|
engine->cancel_requests = cancel_requests;
|
2017-10-25 21:39:41 +07:00
|
|
|
|
|
|
|
engine->park = NULL;
|
|
|
|
engine->unpark = NULL;
|
2017-03-17 00:13:03 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
static void gen6_bsd_set_default_submission(struct intel_engine_cs *engine)
|
|
|
|
{
|
2017-10-25 21:39:41 +07:00
|
|
|
i9xx_set_default_submission(engine);
|
2017-03-17 00:13:03 +07:00
|
|
|
engine->submit_request = gen6_bsd_submit_request;
|
|
|
|
}
|
|
|
|
|
2019-05-01 17:32:04 +07:00
|
|
|
static void ring_destroy(struct intel_engine_cs *engine)
|
|
|
|
{
|
|
|
|
struct drm_i915_private *dev_priv = engine->i915;
|
|
|
|
|
|
|
|
WARN_ON(INTEL_GEN(dev_priv) > 2 &&
|
|
|
|
(ENGINE_READ(engine, RING_MI_MODE) & MODE_IDLE) == 0);
|
|
|
|
|
2019-06-20 00:01:35 +07:00
|
|
|
intel_engine_cleanup_common(engine);
|
|
|
|
|
2019-08-10 01:25:18 +07:00
|
|
|
intel_ring_unpin(engine->legacy.ring);
|
|
|
|
intel_ring_put(engine->legacy.ring);
|
|
|
|
|
|
|
|
intel_timeline_unpin(engine->legacy.timeline);
|
|
|
|
intel_timeline_put(engine->legacy.timeline);
|
2019-05-01 17:32:04 +07:00
|
|
|
|
|
|
|
kfree(engine);
|
|
|
|
}
|
|
|
|
|
2019-04-26 23:33:33 +07:00
|
|
|
static void setup_irq(struct intel_engine_cs *engine)
|
|
|
|
{
|
|
|
|
struct drm_i915_private *i915 = engine->i915;
|
|
|
|
|
|
|
|
if (INTEL_GEN(i915) >= 6) {
|
|
|
|
engine->irq_enable = gen6_irq_enable;
|
|
|
|
engine->irq_disable = gen6_irq_disable;
|
|
|
|
} else if (INTEL_GEN(i915) >= 5) {
|
|
|
|
engine->irq_enable = gen5_irq_enable;
|
|
|
|
engine->irq_disable = gen5_irq_disable;
|
|
|
|
} else if (INTEL_GEN(i915) >= 3) {
|
|
|
|
engine->irq_enable = i9xx_irq_enable;
|
|
|
|
engine->irq_disable = i9xx_irq_disable;
|
|
|
|
} else {
|
|
|
|
engine->irq_enable = i8xx_irq_enable;
|
|
|
|
engine->irq_disable = i8xx_irq_disable;
|
|
|
|
}
|
|
|
|
}
|
|
|
|
|
|
|
|
static void setup_common(struct intel_engine_cs *engine)
|
2016-06-29 22:09:20 +07:00
|
|
|
{
|
2019-04-26 23:33:33 +07:00
|
|
|
struct drm_i915_private *i915 = engine->i915;
|
|
|
|
|
drm/i915: Remove obsolete ringbuffer emission for gen8+
Since removing the module parameter to force selection of ringbuffer
emission for gen8, the code is defunct. Remove it.
To put the difference into perspective, a couple of microbenchmarks
(bdw i7-5557u, 20170324):
ring execlists
exec continuous nops on all rings: 1.491us 2.223us
exec sequential nops on each ring: 12.508us 53.682us
single nop + sync: 9.272us 30.291us
vblank_mode=0 glxgears: ~11000fps ~9000fps
Since the earlier submission, gen8 ringbuffer submission has fallen
further and further behind in features. So while ringbuffer may hold the
throughput crown, in terms of interactive latency, execlists is much
better. Alas, we have no convenient metrics for such, other than
demonstrating things we can do with execlists but can not using
legacy ringbuffer submission.
We have made a few improvements to lowlevel execlists throughput,
and ringbuffer currently panics on boot! (bdw i7-5557u, 20171026):
ring execlists
exec continuous nops on all rings: n/a 1.921us
exec sequential nops on each ring: n/a 44.621us
single nop + sync: n/a 21.953us
vblank_mode=0 glxgears: n/a ~18500fps
References: https://bugs.freedesktop.org/show_bug.cgi?id=87725
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Once-upon-a-time-Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171120205504.21892-2-chris@chris-wilson.co.uk
2017-11-21 03:55:01 +07:00
|
|
|
/* gen8+ are only supported with execlists */
|
2019-04-26 23:33:33 +07:00
|
|
|
GEM_BUG_ON(INTEL_GEN(i915) >= 8);
|
drm/i915: Remove obsolete ringbuffer emission for gen8+
Since removing the module parameter to force selection of ringbuffer
emission for gen8, the code is defunct. Remove it.
To put the difference into perspective, a couple of microbenchmarks
(bdw i7-5557u, 20170324):
ring execlists
exec continuous nops on all rings: 1.491us 2.223us
exec sequential nops on each ring: 12.508us 53.682us
single nop + sync: 9.272us 30.291us
vblank_mode=0 glxgears: ~11000fps ~9000fps
Since the earlier submission, gen8 ringbuffer submission has fallen
further and further behind in features. So while ringbuffer may hold the
throughput crown, in terms of interactive latency, execlists is much
better. Alas, we have no convenient metrics for such, other than
demonstrating things we can do with execlists but can not using
legacy ringbuffer submission.
We have made a few improvements to lowlevel execlists throughput,
and ringbuffer currently panics on boot! (bdw i7-5557u, 20171026):
ring execlists
exec continuous nops on all rings: n/a 1.921us
exec sequential nops on each ring: n/a 44.621us
single nop + sync: n/a 21.953us
vblank_mode=0 glxgears: n/a ~18500fps
References: https://bugs.freedesktop.org/show_bug.cgi?id=87725
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Once-upon-a-time-Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171120205504.21892-2-chris@chris-wilson.co.uk
2017-11-21 03:55:01 +07:00
|
|
|
|
2019-04-26 23:33:33 +07:00
|
|
|
setup_irq(engine);
|
2016-08-03 04:50:35 +07:00
|
|
|
|
2019-05-01 17:32:04 +07:00
|
|
|
engine->destroy = ring_destroy;
|
|
|
|
|
drm/i915: Invert the GEM wakeref hierarchy
In the current scheme, on submitting a request we take a single global
GEM wakeref, which trickles down to wake up all GT power domains. This
is undesirable as we would like to be able to localise our power
management to the available power domains and to remove the global GEM
operations from the heart of the driver. (The intent there is to push
global GEM decisions to the boundary as used by the GEM user interface.)
Now during request construction, each request is responsible via its
logical context to acquire a wakeref on each power domain it intends to
utilize. Currently, each request takes a wakeref on the engine(s) and
the engines themselves take a chipset wakeref. This gives us a
transition on each engine which we can extend if we want to insert more
powermangement control (such as soft rc6). The global GEM operations
that currently require a struct_mutex are reduced to listening to pm
events from the chipset GT wakeref. As we reduce the struct_mutex
requirement, these listeners should evaporate.
Perhaps the biggest immediate change is that this removes the
struct_mutex requirement around GT power management, allowing us greater
flexibility in request construction. Another important knock-on effect,
is that by tracking engine usage, we can insert a switch back to the
kernel context on that engine immediately, avoiding any extra delay or
inserting global synchronisation barriers. This makes tracking when an
engine and its associated contexts are idle much easier -- important for
when we forgo our assumed execution ordering and need idle barriers to
unpin used contexts. In the process, it means we remove a large chunk of
code whose only purpose was to switch back to the kernel context.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190424200717.1686-5-chris@chris-wilson.co.uk
2019-04-25 03:07:17 +07:00
|
|
|
engine->resume = xcs_resume;
|
2018-05-17 01:33:51 +07:00
|
|
|
engine->reset.prepare = reset_prepare;
|
|
|
|
engine->reset.reset = reset_ring;
|
|
|
|
engine->reset.finish = reset_finish;
|
2016-06-29 22:09:21 +07:00
|
|
|
|
2019-03-08 20:25:18 +07:00
|
|
|
engine->cops = &ring_context_ops;
|
2016-12-18 22:37:24 +07:00
|
|
|
engine->request_alloc = ring_request_alloc;
|
|
|
|
|
2019-01-30 01:54:50 +07:00
|
|
|
/*
|
|
|
|
* Using a global execution timeline; the previous final breadcrumb is
|
|
|
|
* equivalent to our next initial bread so we can elide
|
|
|
|
* engine->emit_init_breadcrumb().
|
|
|
|
*/
|
|
|
|
engine->emit_fini_breadcrumb = i9xx_emit_breadcrumb;
|
2019-04-26 23:33:33 +07:00
|
|
|
if (IS_GEN(i915, 5))
|
2019-01-30 01:54:50 +07:00
|
|
|
engine->emit_fini_breadcrumb = gen5_emit_breadcrumb;
|
2017-03-17 00:13:03 +07:00
|
|
|
|
|
|
|
engine->set_default_submission = i9xx_set_default_submission;
|
2016-07-01 15:18:12 +07:00
|
|
|
|
2019-04-26 23:33:33 +07:00
|
|
|
if (INTEL_GEN(i915) >= 6)
|
2016-08-03 04:50:27 +07:00
|
|
|
engine->emit_bb_start = gen6_emit_bb_start;
|
2019-04-26 23:33:33 +07:00
|
|
|
else if (INTEL_GEN(i915) >= 4)
|
2016-08-03 04:50:27 +07:00
|
|
|
engine->emit_bb_start = i965_emit_bb_start;
|
2019-04-26 23:33:33 +07:00
|
|
|
else if (IS_I830(i915) || IS_I845G(i915))
|
2016-08-03 04:50:27 +07:00
|
|
|
engine->emit_bb_start = i830_emit_bb_start;
|
2016-07-01 15:18:12 +07:00
|
|
|
else
|
2016-08-03 04:50:27 +07:00
|
|
|
engine->emit_bb_start = i915_emit_bb_start;
|
2016-06-29 22:09:20 +07:00
|
|
|
}
|
|
|
|
|
2019-04-26 23:33:33 +07:00
|
|
|
static void setup_rcs(struct intel_engine_cs *engine)
|
2010-09-16 09:43:11 +07:00
|
|
|
{
|
2019-04-26 23:33:33 +07:00
|
|
|
struct drm_i915_private *i915 = engine->i915;
|
2016-06-29 22:09:20 +07:00
|
|
|
|
2019-04-26 23:33:33 +07:00
|
|
|
if (HAS_L3_DPF(i915))
|
2016-07-01 23:23:28 +07:00
|
|
|
engine->irq_keep_mask = GT_RENDER_L3_PARITY_ERROR_INTERRUPT;
|
2016-07-01 23:23:21 +07:00
|
|
|
|
2018-03-15 01:26:53 +07:00
|
|
|
engine->irq_enable_mask = GT_RENDER_USER_INTERRUPT;
|
|
|
|
|
2019-04-26 23:33:33 +07:00
|
|
|
if (INTEL_GEN(i915) >= 7) {
|
2016-08-03 04:50:24 +07:00
|
|
|
engine->emit_flush = gen7_render_ring_flush;
|
2019-01-30 01:54:50 +07:00
|
|
|
engine->emit_fini_breadcrumb = gen7_rcs_emit_breadcrumb;
|
2019-04-26 23:33:33 +07:00
|
|
|
} else if (IS_GEN(i915, 6)) {
|
2018-12-28 22:31:14 +07:00
|
|
|
engine->emit_flush = gen6_render_ring_flush;
|
2019-01-30 01:54:50 +07:00
|
|
|
engine->emit_fini_breadcrumb = gen6_rcs_emit_breadcrumb;
|
2019-04-26 23:33:33 +07:00
|
|
|
} else if (IS_GEN(i915, 5)) {
|
2016-08-03 04:50:24 +07:00
|
|
|
engine->emit_flush = gen4_render_ring_flush;
|
2012-04-12 03:12:48 +07:00
|
|
|
} else {
|
2019-04-26 23:33:33 +07:00
|
|
|
if (INTEL_GEN(i915) < 4)
|
2016-08-03 04:50:24 +07:00
|
|
|
engine->emit_flush = gen2_render_ring_flush;
|
2012-04-18 17:12:11 +07:00
|
|
|
else
|
2016-08-03 04:50:24 +07:00
|
|
|
engine->emit_flush = gen4_render_ring_flush;
|
2016-03-16 18:00:36 +07:00
|
|
|
engine->irq_enable_mask = I915_USER_INTERRUPT;
|
2010-12-04 18:30:53 +07:00
|
|
|
}
|
2014-06-30 23:53:36 +07:00
|
|
|
|
2019-04-26 23:33:33 +07:00
|
|
|
if (IS_HASWELL(i915))
|
2016-08-03 04:50:27 +07:00
|
|
|
engine->emit_bb_start = hsw_emit_bb_start;
|
2016-07-01 15:18:12 +07:00
|
|
|
|
drm/i915: Invert the GEM wakeref hierarchy
In the current scheme, on submitting a request we take a single global
GEM wakeref, which trickles down to wake up all GT power domains. This
is undesirable as we would like to be able to localise our power
management to the available power domains and to remove the global GEM
operations from the heart of the driver. (The intent there is to push
global GEM decisions to the boundary as used by the GEM user interface.)
Now during request construction, each request is responsible via its
logical context to acquire a wakeref on each power domain it intends to
utilize. Currently, each request takes a wakeref on the engine(s) and
the engines themselves take a chipset wakeref. This gives us a
transition on each engine which we can extend if we want to insert more
powermangement control (such as soft rc6). The global GEM operations
that currently require a struct_mutex are reduced to listening to pm
events from the chipset GT wakeref. As we reduce the struct_mutex
requirement, these listeners should evaporate.
Perhaps the biggest immediate change is that this removes the
struct_mutex requirement around GT power management, allowing us greater
flexibility in request construction. Another important knock-on effect,
is that by tracking engine usage, we can insert a switch back to the
kernel context on that engine immediately, avoiding any extra delay or
inserting global synchronisation barriers. This makes tracking when an
engine and its associated contexts are idle much easier -- important for
when we forgo our assumed execution ordering and need idle barriers to
unpin used contexts. In the process, it means we remove a large chunk of
code whose only purpose was to switch back to the kernel context.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Cc: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Tvrtko Ursulin <tvrtko.ursulin@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20190424200717.1686-5-chris@chris-wilson.co.uk
2019-04-25 03:07:17 +07:00
|
|
|
engine->resume = rcs_resume;
|
2010-09-16 09:43:11 +07:00
|
|
|
}
|
|
|
|
|
2019-04-26 23:33:33 +07:00
|
|
|
static void setup_vcs(struct intel_engine_cs *engine)
|
2010-09-16 09:43:11 +07:00
|
|
|
{
|
2019-04-26 23:33:33 +07:00
|
|
|
struct drm_i915_private *i915 = engine->i915;
|
2016-06-29 22:09:20 +07:00
|
|
|
|
2019-04-26 23:33:33 +07:00
|
|
|
if (INTEL_GEN(i915) >= 6) {
|
2012-04-12 03:12:55 +07:00
|
|
|
/* gen6 bsd needs a special wa for tail updates */
|
2019-04-26 23:33:33 +07:00
|
|
|
if (IS_GEN(i915, 6))
|
2017-03-17 00:13:03 +07:00
|
|
|
engine->set_default_submission = gen6_bsd_set_default_submission;
|
2016-08-03 04:50:24 +07:00
|
|
|
engine->emit_flush = gen6_bsd_ring_flush;
|
drm/i915: Remove obsolete ringbuffer emission for gen8+
Since removing the module parameter to force selection of ringbuffer
emission for gen8, the code is defunct. Remove it.
To put the difference into perspective, a couple of microbenchmarks
(bdw i7-5557u, 20170324):
ring execlists
exec continuous nops on all rings: 1.491us 2.223us
exec sequential nops on each ring: 12.508us 53.682us
single nop + sync: 9.272us 30.291us
vblank_mode=0 glxgears: ~11000fps ~9000fps
Since the earlier submission, gen8 ringbuffer submission has fallen
further and further behind in features. So while ringbuffer may hold the
throughput crown, in terms of interactive latency, execlists is much
better. Alas, we have no convenient metrics for such, other than
demonstrating things we can do with execlists but can not using
legacy ringbuffer submission.
We have made a few improvements to lowlevel execlists throughput,
and ringbuffer currently panics on boot! (bdw i7-5557u, 20171026):
ring execlists
exec continuous nops on all rings: n/a 1.921us
exec sequential nops on each ring: n/a 44.621us
single nop + sync: n/a 21.953us
vblank_mode=0 glxgears: n/a ~18500fps
References: https://bugs.freedesktop.org/show_bug.cgi?id=87725
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Once-upon-a-time-Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171120205504.21892-2-chris@chris-wilson.co.uk
2017-11-21 03:55:01 +07:00
|
|
|
engine->irq_enable_mask = GT_BSD_USER_INTERRUPT;
|
2018-12-28 22:31:14 +07:00
|
|
|
|
2019-04-26 23:33:33 +07:00
|
|
|
if (IS_GEN(i915, 6))
|
2019-01-30 01:54:50 +07:00
|
|
|
engine->emit_fini_breadcrumb = gen6_xcs_emit_breadcrumb;
|
2019-01-25 19:00:04 +07:00
|
|
|
else
|
2019-01-30 01:54:50 +07:00
|
|
|
engine->emit_fini_breadcrumb = gen7_xcs_emit_breadcrumb;
|
2012-04-12 03:12:49 +07:00
|
|
|
} else {
|
2016-08-03 04:50:24 +07:00
|
|
|
engine->emit_flush = bsd_ring_flush;
|
2019-04-26 23:33:33 +07:00
|
|
|
if (IS_GEN(i915, 5))
|
2016-03-16 18:00:36 +07:00
|
|
|
engine->irq_enable_mask = ILK_BSD_USER_INTERRUPT;
|
2016-06-29 22:09:32 +07:00
|
|
|
else
|
2016-03-16 18:00:36 +07:00
|
|
|
engine->irq_enable_mask = I915_BSD_USER_INTERRUPT;
|
2012-04-12 03:12:49 +07:00
|
|
|
}
|
2010-09-16 09:43:11 +07:00
|
|
|
}
|
2010-10-19 17:19:32 +07:00
|
|
|
|
2019-04-26 23:33:33 +07:00
|
|
|
static void setup_bcs(struct intel_engine_cs *engine)
|
2010-10-19 17:19:32 +07:00
|
|
|
{
|
2019-04-26 23:33:33 +07:00
|
|
|
struct drm_i915_private *i915 = engine->i915;
|
2016-06-29 22:09:20 +07:00
|
|
|
|
2016-08-03 04:50:24 +07:00
|
|
|
engine->emit_flush = gen6_ring_flush;
|
drm/i915: Remove obsolete ringbuffer emission for gen8+
Since removing the module parameter to force selection of ringbuffer
emission for gen8, the code is defunct. Remove it.
To put the difference into perspective, a couple of microbenchmarks
(bdw i7-5557u, 20170324):
ring execlists
exec continuous nops on all rings: 1.491us 2.223us
exec sequential nops on each ring: 12.508us 53.682us
single nop + sync: 9.272us 30.291us
vblank_mode=0 glxgears: ~11000fps ~9000fps
Since the earlier submission, gen8 ringbuffer submission has fallen
further and further behind in features. So while ringbuffer may hold the
throughput crown, in terms of interactive latency, execlists is much
better. Alas, we have no convenient metrics for such, other than
demonstrating things we can do with execlists but can not using
legacy ringbuffer submission.
We have made a few improvements to lowlevel execlists throughput,
and ringbuffer currently panics on boot! (bdw i7-5557u, 20171026):
ring execlists
exec continuous nops on all rings: n/a 1.921us
exec sequential nops on each ring: n/a 44.621us
single nop + sync: n/a 21.953us
vblank_mode=0 glxgears: n/a ~18500fps
References: https://bugs.freedesktop.org/show_bug.cgi?id=87725
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Once-upon-a-time-Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171120205504.21892-2-chris@chris-wilson.co.uk
2017-11-21 03:55:01 +07:00
|
|
|
engine->irq_enable_mask = GT_BLT_USER_INTERRUPT;
|
2010-10-19 17:19:32 +07:00
|
|
|
|
2019-04-26 23:33:33 +07:00
|
|
|
if (IS_GEN(i915, 6))
|
2019-01-30 01:54:50 +07:00
|
|
|
engine->emit_fini_breadcrumb = gen6_xcs_emit_breadcrumb;
|
2019-01-25 19:00:04 +07:00
|
|
|
else
|
2019-01-30 01:54:50 +07:00
|
|
|
engine->emit_fini_breadcrumb = gen7_xcs_emit_breadcrumb;
|
2010-10-19 17:19:32 +07:00
|
|
|
}
|
2012-07-20 18:41:08 +07:00
|
|
|
|
2019-04-26 23:33:33 +07:00
|
|
|
static void setup_vecs(struct intel_engine_cs *engine)
|
2013-05-29 09:22:23 +07:00
|
|
|
{
|
2019-04-26 23:33:33 +07:00
|
|
|
struct drm_i915_private *i915 = engine->i915;
|
2018-12-28 22:31:14 +07:00
|
|
|
|
2019-04-26 23:33:33 +07:00
|
|
|
GEM_BUG_ON(INTEL_GEN(i915) < 7);
|
2016-06-29 22:09:20 +07:00
|
|
|
|
2016-08-03 04:50:24 +07:00
|
|
|
engine->emit_flush = gen6_ring_flush;
|
drm/i915: Remove obsolete ringbuffer emission for gen8+
Since removing the module parameter to force selection of ringbuffer
emission for gen8, the code is defunct. Remove it.
To put the difference into perspective, a couple of microbenchmarks
(bdw i7-5557u, 20170324):
ring execlists
exec continuous nops on all rings: 1.491us 2.223us
exec sequential nops on each ring: 12.508us 53.682us
single nop + sync: 9.272us 30.291us
vblank_mode=0 glxgears: ~11000fps ~9000fps
Since the earlier submission, gen8 ringbuffer submission has fallen
further and further behind in features. So while ringbuffer may hold the
throughput crown, in terms of interactive latency, execlists is much
better. Alas, we have no convenient metrics for such, other than
demonstrating things we can do with execlists but can not using
legacy ringbuffer submission.
We have made a few improvements to lowlevel execlists throughput,
and ringbuffer currently panics on boot! (bdw i7-5557u, 20171026):
ring execlists
exec continuous nops on all rings: n/a 1.921us
exec sequential nops on each ring: n/a 44.621us
single nop + sync: n/a 21.953us
vblank_mode=0 glxgears: n/a ~18500fps
References: https://bugs.freedesktop.org/show_bug.cgi?id=87725
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Once-upon-a-time-Reviewed-by: Joonas Lahtinen <joonas.lahtinen@linux.intel.com>
Reviewed-by: Mika Kuoppala <mika.kuoppala@linux.intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20171120205504.21892-2-chris@chris-wilson.co.uk
2017-11-21 03:55:01 +07:00
|
|
|
engine->irq_enable_mask = PM_VEBOX_USER_INTERRUPT;
|
|
|
|
engine->irq_enable = hsw_vebox_irq_enable;
|
|
|
|
engine->irq_disable = hsw_vebox_irq_disable;
|
2013-05-29 09:22:23 +07:00
|
|
|
|
2019-01-30 01:54:50 +07:00
|
|
|
engine->emit_fini_breadcrumb = gen7_xcs_emit_breadcrumb;
|
2019-04-26 23:33:33 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
int intel_ring_submission_setup(struct intel_engine_cs *engine)
|
|
|
|
{
|
|
|
|
setup_common(engine);
|
|
|
|
|
|
|
|
switch (engine->class) {
|
|
|
|
case RENDER_CLASS:
|
|
|
|
setup_rcs(engine);
|
|
|
|
break;
|
|
|
|
case VIDEO_DECODE_CLASS:
|
|
|
|
setup_vcs(engine);
|
|
|
|
break;
|
|
|
|
case COPY_ENGINE_CLASS:
|
|
|
|
setup_bcs(engine);
|
|
|
|
break;
|
|
|
|
case VIDEO_ENHANCEMENT_CLASS:
|
|
|
|
setup_vecs(engine);
|
|
|
|
break;
|
|
|
|
default:
|
|
|
|
MISSING_CASE(engine->class);
|
|
|
|
return -ENODEV;
|
|
|
|
}
|
|
|
|
|
|
|
|
return 0;
|
|
|
|
}
|
|
|
|
|
|
|
|
int intel_ring_submission_init(struct intel_engine_cs *engine)
|
|
|
|
{
|
2019-06-21 14:08:10 +07:00
|
|
|
struct intel_timeline *timeline;
|
2019-04-26 23:33:33 +07:00
|
|
|
struct intel_ring *ring;
|
|
|
|
int err;
|
|
|
|
|
2019-06-21 14:08:10 +07:00
|
|
|
timeline = intel_timeline_create(engine->gt, engine->status_page.vma);
|
2019-04-26 23:33:33 +07:00
|
|
|
if (IS_ERR(timeline)) {
|
|
|
|
err = PTR_ERR(timeline);
|
|
|
|
goto err;
|
|
|
|
}
|
|
|
|
GEM_BUG_ON(timeline->has_initial_breadcrumb);
|
|
|
|
|
2019-08-10 01:25:18 +07:00
|
|
|
err = intel_timeline_pin(timeline);
|
|
|
|
if (err)
|
|
|
|
goto err_timeline;
|
|
|
|
|
|
|
|
ring = intel_engine_create_ring(engine, SZ_16K);
|
2019-04-26 23:33:33 +07:00
|
|
|
if (IS_ERR(ring)) {
|
|
|
|
err = PTR_ERR(ring);
|
2019-08-10 01:25:18 +07:00
|
|
|
goto err_timeline_unpin;
|
2019-04-26 23:33:33 +07:00
|
|
|
}
|
|
|
|
|
|
|
|
err = intel_ring_pin(ring);
|
|
|
|
if (err)
|
|
|
|
goto err_ring;
|
2018-12-28 22:31:14 +07:00
|
|
|
|
2019-08-10 01:25:18 +07:00
|
|
|
GEM_BUG_ON(engine->legacy.ring);
|
|
|
|
engine->legacy.ring = ring;
|
|
|
|
engine->legacy.timeline = timeline;
|
2019-04-26 23:33:33 +07:00
|
|
|
|
|
|
|
err = intel_engine_init_common(engine);
|
|
|
|
if (err)
|
2019-08-10 01:25:18 +07:00
|
|
|
goto err_ring_unpin;
|
2019-04-26 23:33:33 +07:00
|
|
|
|
2019-08-10 01:25:18 +07:00
|
|
|
GEM_BUG_ON(timeline->hwsp_ggtt != engine->status_page.vma);
|
2019-04-26 23:33:33 +07:00
|
|
|
|
|
|
|
return 0;
|
|
|
|
|
2019-08-10 01:25:18 +07:00
|
|
|
err_ring_unpin:
|
2019-04-26 23:33:33 +07:00
|
|
|
intel_ring_unpin(ring);
|
|
|
|
err_ring:
|
|
|
|
intel_ring_put(ring);
|
2019-08-10 01:25:18 +07:00
|
|
|
err_timeline_unpin:
|
|
|
|
intel_timeline_unpin(timeline);
|
|
|
|
err_timeline:
|
|
|
|
intel_timeline_put(timeline);
|
2019-04-26 23:33:33 +07:00
|
|
|
err:
|
|
|
|
intel_engine_cleanup_common(engine);
|
|
|
|
return err;
|
2013-05-29 09:22:23 +07:00
|
|
|
}
|