l_ms: 2500 [default 2500]
> max_busywait_duration_ns: 8000 [default 8000]
> preempt_timeout_ms: 640 [default 640]
> stop_timeout_ms: 100 [default 100]
> timeslice_duration_ms: 1 [default 1]
>
> Suggested-by: Joonas Lahtinen
> Signed-off-by: Chris Wilso
lockups) and also serve as a
> warning should we try to make this loop atomic in the future.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: sta...@vger.kernel.org
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_gpu_error.c | 3 +++
> 1 file chang
ris Wilson
Signed-off-by: Mika Kuoppala
---
drivers/gpu/drm/i915/i915_cmd_parser.c | 14 ++
1 file changed, 10 insertions(+), 4 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_cmd_parser.c
b/drivers/gpu/drm/i915/i915_cmd_parser.c
index 372354d33f55..5ac4a999f05a 100644
--- a/d
commands.
References: 926abff21a8f ("drm/i915/cmdparser: Ignore Length operands during
command matching")
Reported-by: Nicolai Stange
Cc: sta...@vger.kernel.org # v5.4+
Cc: Miroslav Benes
Cc: Takashi Iwai
Cc: Tyler Hicks
Cc: Jon Bloomfield
Cc: Chris Wilson
Signed-off-by: Mik
Chris Wilson writes:
> Quoting Chris Wilson (2020-08-14 20:41:32)
>> Quoting Mika Kuoppala (2020-08-14 19:41:14)
>> > Chris Wilson writes:
>> > > - entry = READ_ONCE(*csb);
>> > > - if (unlikely(entry == -1)) {
>> > > -
that was not covered by our
> previous w/a.
>
> References: d8f505311717 ("drm/i915/icl: Forcibly evict stale csb entries")
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Bruce Chang
> ---
> drivers/gpu/drm/i915/gt/intel_lrc.c | 70 +--
Chris Wilson writes:
> A CSB entry is 64b, and it is simpler for us to treat it as an array of
> 64b entries than as an array of pairs of 32b entries.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/intel_engine_types.h | 2 +-
>
rcs0: 10132462 cycles, 1.974us
> bcs0: 3667130 cycles, 5.454us
> vcs0: 3616618 cycles, 5.530us
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Ville Syrjälä
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_irq.c | 58 +--
Chris Wilson writes:
> Quoting Mika Kuoppala (2020-07-24 12:55:39)
>> Chris Wilson writes:
>>
>> > Quoting Chris Wilson (2020-07-23 19:33:48)
>> >> Avoid exposing a partially constructed context by deferring the
>> >> list_add() from the
reedesktop.org/drm/intel/-/issues/2169
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/intel_lrc.c | 18 --
> 1 file changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> b/d
Chris Wilson writes:
> Since we want to read the values from the HWSP as written to by the GPU,
> warn the compiler that the values are volatile.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/sel
Chris Wilson writes:
> Quoting Chris Wilson (2020-07-23 19:33:48)
>> Avoid exposing a partially constructed context by deferring the
>> list_add() from the initial construction to the end of registration.
>> Otherwise, if we peek into the list of contexts from inside debugfs, we
>> may see the pa
reedesktop.org/drm/intel/-/issues/2169
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/intel_lrc.c | 18 --
> 1 file changed, 12 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> b/d
ntial. Let's apply the
> preparser disable between batches as we invalidate the TLB as a dose of
> healthy paranoia, just in case.
>
> References: https://gitlab.freedesktop.org/drm/intel/-/issues/2169
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
Reviewed-by: Mika Kuoppala
Chris Wilson writes:
> It's been a while since gen6_rps_boost() [that only worked on gen6+] was
> replaced by intel_rps_boost() that understood itself when rps was
> active. Since the intel_rps_boost() is gen-agnostic, just call it.
>
> Signed-off-by: Chris Wilson
Review
Chris Wilson writes:
> Add a SRM read back of the aux invalidation register after poking
> hsdes: 1809175790, as failing to do so leads to writes going astray.
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2169
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
Chris Wilson writes:
> Since we want to read the values from the HWSP as written to by the GPU,
> warn the compiler that the values are volatile.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
Yes, for consistency (and accuracy) this should be nudged also, even
tho it is o
no result.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_request.c | 20 ++--
> 1 file changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_reque
Chris Wilson writes:
> Since we assert that the kernel_context is using the perma-pinned HWSP,
> make it so.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/mock_engine.c | 3 +++
> 1 file changed,
Chris Wilson writes:
> Track the position of the HWSP for each timeline.
>
> References: https://gitlab.freedesktop.org/drm/intel/-/issues/2169
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/intel_timeline.c| 7 +++
>
Chris Wilson writes:
> Since preempt-to-busy, we may unsubmit a request while it is still on
> the HW and completes asynchronously. That means it may be retired and in
> the process destroy the virtual engine (as the user has closed their
> context), but that engine may still be holding onto the
ng is active.
>
> Signed-off-by: Chris Wilson
> Cc: Tvrtko Ursulin
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/intel_lrc.c | 15 ++-
> 1 file changed, 6 insertions(+), 9 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
Chris Wilson writes:
> Pull the repeated check for the last active request being completed to a
> single spot, when deciding whether or not execlist preemption is
> required.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/gt/intel_lrc.c | 14 --
> 1 file changed, 4 ins
engine->name);
> + goto out;
> + }
This should do the trick. I was worried on the submit signal (fence) block being
empty above in this function that what happens if we never manage to
submit.
But this should cover that case also.
Reviewed-by: Mika
References: https://gitlab.freedesktop.org/drm/intel/-/issues/2119
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/intel_engine_heartbeat.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_eng
Chris Wilson writes:
> As we close a handle GEM object, we update the drm_file's idr with an
> error pointer to indicate the in-progress closure, and finally set it to
The error pointer part stage seems to be missing.
But the finding is valid.
Reviewed-by: Mika Kuoppala
> NU
Chris Wilson writes:
> Like live_unlite_ring, but instead of simply looking at the impact of
> intel_ring_direction(), check that preemption more generally works with
> different depths of queued requests in the ring.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> -
Chris Wilson writes:
> Like live_unlite_ring, but instead of simply looking at the impact of
> intel_ring_direction(), check that preemption more generally works with
> different depths of queued requests in the ring.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
P
n
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_request.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/i915_request.h
> b/drivers/gpu/drm/i915/i915_request.h
> index 118ab6650d1f..590762820761
a96 ("drm/i915/gt: Incrementally check for rewinding")
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/selftest_lrc.c | 150 +
> 1 file changed, 150 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/selftest_l
Chris Wilson writes:
> Quoting Mika Kuoppala (2020-06-16 09:55:04)
>>
>> Chris Wilson writes:
>>
>> > Not too long ago, we realised we had issues with a rolling back a
>> > context so far for a preemption request we considered the resubmit not
>>
execlists_dequeue(engine);
> - rcu_read_unlock();
> - }
> -}
> -
> static void __execlists_hold(struct i915_request *rq)
> {
> LIST_HEAD(list);
> @@ -3102,7 +3092,7 @@ static bool preempt_timeout(const struct
> intel_engine_cs *const engine)
>
in, rq)) {
> + intel_gt_set_wedged(engine->gt);
> + err = -ETIME;
> + break;
> + }
> +
> + preempt_disable();
> + dt = ktime_to_ns(ktime_get());
> + de = intel_engine_get_busy
Chris Wilson writes:
> Rather than mixing [012] and (A1, A2, B2) for the request indices, use
> the enums throughout.
>
> Signed-off-by: Chris Wilson
Yes, much more friendlier.
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/selftest_lrc.c | 15 ---
ncrementally check for rewinding")
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/selftest_lrc.c | 150 +
> 1 file changed, 150 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/selftest_lrc.c
> b/dr
Chris Wilson writes:
> If the tasklet is not being used, don't try and flush it.
>
> Fixes: 594893870044 ("drm/i915/gt: Add a safety submission flush in the
> heartbeat")
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
Reviewed-by: Mika Kuoppala
+ if (tasklet_trylock(t)) {
> + /* Must wait for any GPU reset in progress. */
> + if (__tasklet_is_enabled(t))
On heartbeat context this could be an assertion I think.
But it is difficult to enforce hw sanity and still please the
user.
They will curs
Chris Wilson writes:
> If the engine dies after a reset, and so we fail to submit a request
> but need to be interrupted by the CI runner, dump the engine state.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/selftes
Chris Wilson writes:
> Since the heartbeat may cause a preemption event, disable it over the
> preemption suppression tests.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/selftest_lrc.c | 14 +++---
> 1 file change
Chris Wilson writes:
> Quoting Mika Kuoppala (2020-06-12 23:05:18)
>> Chris Wilson writes:
>>
>> > gen3 does not fully flush MI stores to memory on MI_FLUSH, such that a
>> > subsequent read from e.g. the sampler can bypass the store and read the
>> >
ferences: a889580c087a ("drm/i915: Flush GPU relocs harder for gen3")
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Joonas Lahtinen
> ---
> drivers/gpu/drm/i915/gt/gen2_engine_cs.c | 61 ++--
> 1 file changed, 25 insertions(+), 36 deletion
Chris Wilson writes:
> Since the process_csb() does not require us to hold the
> engine->active.lock, we can move the opportunistic flush before
> direction submission to outside of the lock.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
>
ncoherency was seen over a few hours (with and without
> background memory pressure), 32 was the magic number.
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2018
> References: a889580c087a ("drm/i915: Flush GPU relocs harder for gen3")
> Signed-off-by: C
Chris Wilson writes:
> Rescue the GT workarounds from being buried inside init_clock_gating so
> that we remember to apply them after a GT reset, and that they are
> included in our verification that the workarounds are applied.
>
> Signed-off-by: Chris Wilson
Reviewed-by
Chris Wilson writes:
> Rescue the GT workarounds from being buried inside init_clock_gating so
> that we remember to apply them after a GT reset, and that they are
> included in our verification that the workarounds are applied.
>
> Signed-off-by: Chris Wilson
Reviewed-by
+
> + /* WaDisable_RenderCache_OperationalFlush:snb */
> + wa_masked_dis(wal, CACHE_MODE_0, RC_OP_FLUSH_ENABLE);
> +
> + /*
> + * BSpec recoomends 8x4 when MSAA is used,
recommends.
Reviewed-by: Mika Kuoppala
> + * however in practice 16x4 seems fastest
Chris Wilson writes:
> Rescue the GT workarounds from being buried inside init_clock_gating so
> that we remember to apply them after a GT reset, and that they are
> included in our verification that the workarounds are applied.
>
> Signed-off-by: Chris Wilson
Reviewed-by
Mika Kuoppala writes:
> Chris Wilson writes:
>
>> Rescue the GT workarounds from being buried inside init_clock_gating so
>> that we remember to apply them after a GT reset, and that they are
>> included in our verification that the workarounds are applied.
>>
Chris Wilson writes:
> Rescue the GT workarounds from being buried inside init_clock_gating so
> that we remember to apply them after a GT reset, and that they are
> included in our verification that the workarounds are applied.
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/gt/in
, not or in our disable
> bit.
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2011
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/intel_workarounds.c | 48 +
> drivers/gpu/drm/i915/intel_pm.c
Chris Wilson writes:
> Rescue the GT workarounds from being buried inside init_clock_gating so
> that we remember to apply them after a GT reset, and that they are
> included in our verification that the workarounds are applied.
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2011
>
Chris Wilson writes:
> This may be useful to identify contexts that are running even though
> they are supposed to be closed or banned.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 12
&g
und activity, as a
> separate flag from exercising all others.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/gpu/d
/*
> * Reserve space for 2 NOOPs at the end of each request to be
> * used as a workaround for not being allowed to do lite
> @@ -4770,6 +4786,9 @@ static u32 *gen8_emit_wa_tail(struct i915_request
> *request, u32 *cs)
> *cs++ = MI_NOOP;
> request->wa_tail = in
ight request.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/selftest_hangcheck.c | 36 ++--
> 1 file changed, 26 insertions(+), 10 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/selftest_hangche
n off the HW. Check that they are the
> - * only request in the pending submission.
> + * Sentinels are supposed to be the last request so they flush
> + * the current exection off the HW. Check that they are the only
s/exection/exeqution
Rev
Chris Wilson writes:
> Quoting Mika Kuoppala (2020-06-05 16:33:19)
>> Chris Wilson writes:
>>
>> > If any engine asks for the tasklet to be kicked from the CS interrupt,
>> > do so.
>>
>> The why part is a bit thin. The plan is to use execlist ta
Chris Wilson writes:
> Quoting Mika Kuoppala (2020-06-05 16:20:34)
>> Chris Wilson writes:
>>
>> > We may choose not to submit for a number of reasons, yet not fill both
>> > ELSP. In which case we must start timeslicing (there will be no ACK
>> > even
Chris Wilson writes:
> If any engine asks for the tasklet to be kicked from the CS interrupt,
> do so.
The why part is a bit thin. The plan is to use execlist tasklet
for move stuff from virtual rings to real ones?
-Mika
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/gt/intel_g
Chris Wilson writes:
> This was removed in commit 478ffad6d690 ("drm/i915: drop
> engine_pin/unpin_breadcrumbs_irq") as the last user had been removed,
> but now there is a promise of a new user in the next patch.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Ku
Chris Wilson writes:
> Add engine->fw_domain/active to the pretty printer for debug dumps and
> debugfs.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: Venkata Sandeep Dhanalakota
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/intel_e
Chris Wilson writes:
> We may choose not to submit for a number of reasons, yet not fill both
> ELSP. In which case we must start timeslicing (there will be no ACK
> event on which to hook the start) if the queue would benefit from the
> currently active context being evicted.
>
> Signed-off-by:
ently active context if the queue is of
> equal priority after its quantum expired).
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/intel_lrc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/
Chris Wilson writes:
> An important property for multi-client systems is that each client gets
> a 'fair' allotment of system time. (Where fairness is at the whim of the
> context properties, such as priorities.) This test forks N independent
> clients (albeit they happen to share a single vm), a
Chris Wilson writes:
> Use the central mechanism for recording and verifying that we restore
> the w/a for the older devices as well.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> .../gpu/drm/i915/gt/intel_ring_submission.c | 28 -
m outside of this context.
*want.
Acked-by: Mika Kuoppala
>
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/Makefile | 2 +
> drivers/gpu/drm/i915/gt/gen2_engine_cs.c | 340 +++
> drivers/gpu/drm/i915/gt/gen2_engine_cs.h | 3
Chris Wilson writes:
> Quoting Mika Kuoppala (2020-06-01 15:56:55)
>> Chris Wilson writes:
>>
>> > As we rewrite the batches on the fly to implement the non-preemptible
>> > lock, we need to tell Tigerlake to read the batch afresh each time.
>> >
Chris Wilson writes:
> Allow batch buffers to read their own _local_ cumulative HW runtime of
> their logical context.
>
> Fixes: 0f2f39758341 ("drm/i915: Add gen9 BCS cmdparsing")
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> Cc: # v5.4+
Reviewed-by: M
Chris Wilson writes:
> As we rewrite the batches on the fly to implement the non-preemptible
> lock, we need to tell Tigerlake to read the batch afresh each time.
> Amusingly, the disable is a part of an arb-check, so we have to be
> careful not to include the arbitration point inside our unpreem
63 72 +9
> ilk_irq_handler 22212080-141
>
> A slight improvement in the baseline overnight as well!
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/i915_irq.c | 59 +--
pact. [So we don't do that anymore!
> Hopefully, this will spare us from still needing the mitigation of the
> timer for steady state execution.]
>
> Signed-off-by: Chris Wilson
> Cc: Tvrtko Ursulin
> Cc: Mika Kuoppala
I am not a fan of having explicit put relying on ti
Chris Wilson writes:
> Sometimes an engine might need to keep forcewake active while it is busy
> submitting requests for a particular workaround. Track such nuisance
> with engine->fw_domain.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
>
Chris Wilson writes:
> Ever noticed that our interrupt handlers are where we spend most of our
> time on a busy system? In part this is unavoidable as each interrupt
> requires to poll and reset several registers, but we can try and so as
> efficiently as possible.
>
> Function
l_engines_release+0x68/0xc0 [i915]
> [ 16.136680] intel_engines_release+0x49/0xc0 [i915]
> [ 16.136757] intel_gt_init+0x2f4/0x5e0 [i915]
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/intel_engine_cs.c | 6 +++---
> 1 file c
Chris Wilson writes:
> Across the many users of the GGTT vma (internal objects, mmapings,
> display etc), we may end up with conflicting requirements for the
> placement. Currently, we try to resolve the conflict by unbinding the
> vma and rebinding it to match the new constraints; over time we w
it.
If this is last in a line, it makes sense to make sure
that we get woken up.
Reviewed-by: Mika Kuoppala
>
> Signed-off-by: Chris Wilson
> Cc: Tvrtko Ursulin
> ---
> drivers/gpu/drm/i915/gt/intel_lrc.c | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
>
* ringbuffer. If one context is blocked on an
> + * external fence, not only is it not submitted,
> + * but all other contexts, including the kernel
> + * context are stuck waiting for the signal.
> +
->execute_cb));
> spin_unlock_irq(&rq->lock);
>
> remove_from_client(rq);
> @@ -395,7 +394,8 @@ __await_execution(struct i915_request *rq,
> i915_sw_fence_complete(cb->fence);
> kmem_cache_free(global.slab
154 -15
> __execlists_submission_tasklet 46964659 -37
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/intel_lrc.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
eed with the reset as we
> shutdown the module. We know the next user must reinitialise the HW for
> their purpose.
>
> Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/489
> Signed-off-by: Chris Wilson
> Cc: sta...@kernel.org
Reviewed-by: Mika Kuoppala
> ---
> dr
l/-/issues/1880
> Signed-off-by: Chris Wilson
Acked-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/intel_ggtt.c | 11 +++
> 1 file changed, 3 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_ggtt.c
> b/drivers/gpu/drm/i915/gt/intel_ggtt.
Chris Wilson writes:
> Leave the error propagation in place, but limit the warnings to only
> show up in CI if the unlikely errors are hit.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gem/i915_gem_execbuffer.c | 3 +--
> dri
that the finit goes as you expect, you
could add two cancel_delayed_work_sync and assert
that the final one return false.
Reviewed-by: Mika Kuoppala
> }
>
> void intel_gt_fini_buffer_pool(struct intel_gt *gt)
> --
> 2.20.1
>
>
clare that a request has
> been already submitted too early.
submittedstarted...handled_by_gpu.
I guess wait_for_submit is generic enough to cater all cases
but we actually do not wait for submit but we wait for
gpu to reach it.
>
> Signed-off-by: Chris Wilson
Revie
Chris Wilson writes:
> Check for integer overflow in the priority chain, rather than against a
> type-constricted max-priority check.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/selftest_lrc.c | 6 +++---
> 1 file change
Chris Wilson writes:
> Since we temporarily disable the heartbeat and restore back to the
> default value, we can use the stored defaults on the engine and avoid
> using a local.
>
> Signed-off-by: Chris Wilson
> ---
Reviewed-by: Mika Kuoppala
> drivers/gpu/drm/i915/gt
nning with only the inflight request.
s/nnn/nn
Reviewed-by: Mika Kuoppala
>
> Fixes: 6cebcf746f3f ("drm/i915: Tweak scheduler's kick_submission()")
> Signed-off-by: Chris Wilson
> ---
> drivers/gpu/drm/i915/i915_scheduler.c | 16
> 1 file changed
Chris Wilson writes:
> A useful metric of the system's health is how fast we can tell the GPU
> to do various actions, so measure our latency.
>
> v2: Refactor all the instruction building into emitters.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
> C
_BIND, but for the moment this
> suffices to construct the GTT as required for arbitrary
> *user-controlled* indirect execution.
>
> Signed-off-by: Chris Wilson
> Cc: Joonas Lahtinen
> Cc: Mika Kuoppala
> ---
> lib/igt_core.h| 1 +
> tests/Makefile.sou
Chris Wilson writes:
> A useful metric of the system's health is how fast we can tell the GPU
> to do various actions, so measure our latency.
>
> v2: Refactor all the instruction building into emitters.
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuopp
Chris Wilson writes:
> While this does not appear to fix any issues, the backend itself knows
> when it wants to emit a breadcrumb, so let it make the final call.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/selftests
eing written too early. We also
> want to ensure that we do not add semaphore waits after we have already
> closed the semaphore section, an issue for later deferred waits.
>
> Signed-off-by: Chris Wilson
Reviewed-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/intel_lrc.c
Chris Wilson writes:
> Since there can only be one of in_fence/exec_fence, just use the single
> in_fence local.
>
> v2: Considate lookup
>
> Signed-off-by: Chris Wilson
> Cc: Mika Kuoppala
Reviewed-by: Mika Kuoppala
> ---
> .../gpu/drm/i915/gem/i9
Chris Wilson writes:
> Since there can only be one of in_fence/exec_fence, just use the single
> in_fence local.
>
> Signed-off-by: Chris Wilson
> ---
> .../gpu/drm/i915/gem/i915_gem_execbuffer.c| 24 ---
> 1 file changed, 10 insertions(+), 14 deletions(-)
>
> diff --git a/d
cking on the semaphore caused extremely bad scheduling with multiple
> clients utilising multiple rings. Now, there is no impact and we can
> remove the complication.
Not a small feat to accomplish.
Reviewed-by: Mika Kuoppala
>
> Signed-off-by: Chris Wilson
> ---
> .../gpu/drm/
0 [i915]
> <4>[ 449.386797] gt_sanitize+0xd6/0x260 [i915]
>
> As part of the reset preparation, engine->reset.prepare() prevents the
> tasklet from running, so pull the sanitization inside the critical
> section for reset.
>
> Closes: https://gitlab.freedesktop.org/d
so rejig the register reset.
>
> Signed-off-by: Chris Wilson
Acked-by: Mika Kuoppala
> ---
> drivers/gpu/drm/i915/gt/intel_lrc.c | 19 +--
> 1 file changed, 13 insertions(+), 6 deletions(-)
>
> diff --git a/drivers/gpu/drm/i915/gt/intel_lrc.c
> b/drivers
Daniele Ceraolo Spurio writes:
> On 5/7/20 7:20 AM, Mika Kuoppala wrote:
>> All engines, exception being blitter as it does not
>> care about the form, can access compressed surfaces.
>>
>> So we need to add forced aux table invalidates
>> for those engines.
&g
t; Signed-off-by: Chris Wilson
> Cc: Tvrtko Ursulin
> Cc: # v5.5+
Only thing I would change is tune up the subject line.
It fixes a possible busy loop in eviction so I feel 'watch out' is not
strong enough for my liking.
Reviewed-by: Mika Kuoppala
>
e asynchronous binds, and the
> remaining issues do not seem restricted to Cherryview [at least the ones
> seen over a few dozen CI runs, less frequent issues are sure to be
> discovered!]
>
> Signed-off-by: Chris Wilson
Acked-by: Mika Kuoppala
> ---
101 - 200 of 3589 matches
Mail list logo
