Re: [Intel-gfx] [PATCH v3 2/4] drm/i915/pmu: Use kstat_irqs to get interrupt count

On 10/12/2020 07:53, Joonas Lahtinen wrote: + Tvrtko and Chris for comments Code seems to be added in: commit 0cd4684d6ea9a4ffec33fc19de4dd667bb90d0a5 Author: Tvrtko Ursulin Date: Tue Nov 21 18:18:50 2017 + drm/i915/pmu: Add interrupt count metric I think later in the thread

Re: [Intel-gfx] [PATCH v3 2/4] drm/i915/pmu: Use kstat_irqs to get interrupt count

On 10/12/2020 16:35, Thomas Gleixner wrote: On Thu, Dec 10 2020 at 10:45, Tvrtko Ursulin wrote: On 10/12/2020 07:53, Joonas Lahtinen wrote: I think later in the thread there was a suggestion to replace this with simple counter increment in IRQ handler. It was indeed unsafe until recent

[Intel-gfx] [PATCH] drm/i915/pmu: Stop peeking at kernel internals for counting interrupts

From: Tvrtko Ursulin Peeking at kernel internals is bad taste so instead we keep our own counter which also solves the problem of shared interrupt lines. Additional cost should be way below noise relative to mmio reads. Signed-off-by: Tvrtko Ursulin Suggested-by: Thomas Gleixner Cc: Chris

Re: [Intel-gfx] [PATCH v3 2/4] drm/i915/pmu: Use kstat_irqs to get interrupt count

On 10/12/2020 17:44, Thomas Gleixner wrote: On Thu, Dec 10 2020 at 17:09, Tvrtko Ursulin wrote: On 10/12/2020 16:35, Thomas Gleixner wrote: I'll send out a series addressing irq_to_desc() (ab)use all over the place shortly. i915 is in there... Yep we don't need atomic, my bad. An

Re: [Intel-gfx] [patch 14/30] drm/i915/pmu: Replace open coded kstat_irqs() copy

either do that or deal with wrap at PMU read time. So thanks for dealing with it, some small comments below but overall it is fine. Signed-off-by: Thomas Gleixner Cc: Tvrtko Ursulin Cc: Jani Nikula Cc: Joonas Lahtinen Cc: Rodrigo Vivi Cc: David Airlie Cc: Daniel Vetter Cc:

[Intel-gfx] [CI 2/3] drm/i915/pmu: Use raw clock for rc6 estimation

From: Tvrtko Ursulin RC6 is a hardware counter and as such estimating it using the raw clock during runtime suspend is more appropriate. Signed-off-by: Tvrtko Ursulin References: 34f439278cef ("perf: Add per event clockid support") Cc: Chris Wilson Reviewed-by: Chris Wilson --- d

[Intel-gfx] [CI 1/3] drm/i915/pmu: Don't grab wakeref when enabling events

From: Tvrtko Ursulin Chris found a CI report which points out calling intel_runtime_pm_get from inside i915_pmu_enable hook is not allowed since it can be invoked from hard irq context. This is something we knew but forgot, so lets fix it once again. We do this by syncing the internal book

[Intel-gfx] [CI 3/3] drm/i915/pmu: Remove !CONFIG_PM code

From: Tvrtko Ursulin Chris spotted that since 16ffe73c186b ("drm/i915/pmu: Use GT parked for estimating RC6 while asleep") we don't rely on runtime pm internals when estimating RC6 while asleep. We can remove the ifdef code to simplify and at the same time wake up the device les

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 1/4] i915/perf_pmu: Verify RC6 measurements before/after suspend

On 14/12/2020 10:51, Chris Wilson wrote: RC6 should work before suspend, and continue to increment while idle after suspend. Should. v2: Include a longer sleep after suspend; it appears we are reticent to idle so soon after waking up. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 2/4] i915/gem_exec_balancer: Measure timeslicing fairness

(i915, ci, count); + free(ci); + } +} + static bool has_context_engines(int i915) { struct drm_i915_gem_context_param p = { @@ -2848,6 +2999,9 @@ igt_main full(i915, p->flags); } + igt_subtest(&qu

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 3/4] i915/gem_shrink: Refactor allocation sizing based on available memory

On 14/12/2020 10:51, Chris Wilson wrote: Refactor the allocation such that we utilise just enough memory pressure to invoke the shrinker, and just enough processes to spread across the CPUs and contend on the shrinker. Signed-off-by: Chris Wilson --- tests/i915/gem_shrink.c | 11 ++-

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 1/4] i915/perf_pmu: Verify RC6 measurements before/after suspend

On 14/12/2020 15:49, Chris Wilson wrote: Quoting Tvrtko Ursulin (2020-12-14 15:42:20) On 14/12/2020 10:51, Chris Wilson wrote: RC6 should work before suspend, and continue to increment while idle after suspend. Should. v2: Include a longer sleep after suspend; it appears we are reticent to

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] i915/gem_exec_schedule: Measure timeslice distribution when oversaturated

On 14/12/2020 20:44, Chris Wilson wrote: Check that timeslices for an oversaturated system (where there is more work than can be supported by a single engine) are evenly distributed between the clients. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin --- tests/i915/gem_exec_schedule.c

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] i915/gem_shrink: Refactor allocation sizing based on available memory

per cpu. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin --- tests/i915/gem_shrink.c | 11 ++- 1 file changed, 6 insertions(+), 5 deletions(-) diff --git a/tests/i915/gem_shrink.c b/tests/i915/gem_shrink.c index 023db8c56..6413d25f5 100644 --- a/tests/i915/gem_shrink.c +++ b/tests/i915

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] i915/gem_exec_schedule: Measure timeslice distribution when oversaturated

On 15/12/2020 09:47, Chris Wilson wrote: Quoting Tvrtko Ursulin (2020-12-15 09:41:09) On 14/12/2020 20:44, Chris Wilson wrote: Check that timeslices for an oversaturated system (where there is more work than can be supported by a single engine) are evenly distributed between the clients

Re: [Intel-gfx] [PATCH 14/69] drm/i915/gt: Track the overall awake/busy time

/i915_drm.h @@ -177,6 +177,7 @@ enum drm_i915_pmu_engine_sample { #define I915_PMU_REQUESTED_FREQUENCY __I915_PMU_OTHER(1) #define I915_PMU_INTERRUPTS __I915_PMU_OTHER(2) #define I915_PMU_RC6_RESIDENCY__I915_PMU_OTHER(3) +#define I915_PMU_GT_AWAKE

Re: [Intel-gfx] [PATCH 1/2] i915/perf: Move gen specific OA formats to single array

On 15/12/2020 21:49, Umesh Nerlige Ramappa wrote: Variations in OA formats in the different gens has led to creation of several sparse arrays to store the formats. Move oa formats into a single array and add the supported range of platforms for the oa formats. Signed-off-by: Umesh Nerlige Ram

[Intel-gfx] [PATCH i-g-t 2/2] intel_gpu_top: Aggregate engine busyness per class

From: Tvrtko Ursulin Similarly to how top(1) handles SMP, we can default to showing engines of a same class as a single bar graph entry. To achieve this a little bit of hackery is employed. PMU sampling is left as is and only at the presentation layer we create a fake set of engines, one for

[Intel-gfx] [PATCH i-g-t 1/2] intel_gpu_top: Support exiting the tool by pressing 'q'

From: Tvrtko Ursulin Analoguous to top(1) we can enable the user to exit from the tool by pressing 'q' on the console. Signed-off-by: Tvrtko Ursulin --- man/intel_gpu_top.rst | 6 tools/intel_gpu_top.c | 77 +++ 2 files changed, 70

[Intel-gfx] [PATCH v2 i-g-t 1/2] intel_gpu_top: Support exiting the tool by pressing 'q'

From: Tvrtko Ursulin Analoguous to top(1) we can enable the user to exit from the tool by pressing 'q' on the console. v2: * Fix sleep period with closed stdin. (Chris) Signed-off-by: Tvrtko Ursulin --- man/intel_gpu_top.rst | 6 tools/intel_gpu_

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 2/2] intel_gpu_top: Aggregate engine busyness per class

On 16/12/2020 15:51, Chris Wilson wrote: Quoting Tvrtko Ursulin (2020-12-16 15:28:09) From: Tvrtko Ursulin Similarly to how top(1) handles SMP, we can default to showing engines of a same class as a single bar graph entry. To achieve this a little bit of hackery is employed. PMU sampling

[Intel-gfx] [PATCH v2 i-g-t 2/2] intel_gpu_top: Aggregate engine busyness per class

From: Tvrtko Ursulin Similarly to how top(1) handles SMP, we can default to showing engines of a same class as a single bar graph entry. To achieve this a little bit of hackery is employed. PMU sampling is left as is and only at the presentation layer we create a fake set of engines, one for

[Intel-gfx] [PATCH i-g-t 1/3] intel_gpu_top: Support exiting the tool by pressing 'q'

From: Tvrtko Ursulin Analoguous to top(1) we can enable the user to exit from the tool by pressing 'q' on the console. v2: * Fix sleep period with closed stdin. (Chris) Signed-off-by: Tvrtko Ursulin --- man/intel_gpu_top.rst | 6 tools/intel_gpu_

[Intel-gfx] [PATCH i-g-t 3/3] intel_gpu_top: Fix interactive mode on serial console

From: Tvrtko Ursulin TIOCGWINSZ returns zero columns and rows on serial so lets assume 80x24. Signed-off-by: Tvrtko Ursulin --- tools/intel_gpu_top.c | 5 + 1 file changed, 5 insertions(+) diff --git a/tools/intel_gpu_top.c b/tools/intel_gpu_top.c index d1149eb8e14d..72ad7cbe9a8c 100644

[Intel-gfx] [PATCH i-g-t 2/3] intel_gpu_top: Aggregate engine busyness per class

From: Tvrtko Ursulin Similarly to how top(1) handles SMP, we can default to showing engines of a same class as a single bar graph entry. To achieve this a little bit of hackery is employed. PMU sampling is left as is and only at the presentation layer we create a fake set of engines, one for

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t] i915/perf_pmu: Replace init/read-other with a plea

: Tvrtko Ursulin --- tests/i915/perf_pmu.c | 56 --- 1 file changed, 15 insertions(+), 41 deletions(-) diff --git a/tests/i915/perf_pmu.c b/tests/i915/perf_pmu.c index e2f975a1a..db375341c 100644 --- a/tests/i915/perf_pmu.c +++ b/tests/i915/perf_pmu.c

Re: [Intel-gfx] [PATCH i-g-t] i915/perf_pmu: Exercise I915_PMU_SOFTWARE_GT_AWAKE_TIME

On 17/12/2020 17:26, Chris Wilson wrote: Measure the sample gt-awake time while each engine and every engine is busy. They should all report the same duration, the elapsed runtime of the batch. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin --- include/drm-uapi/i915_drm.h | 3 ++- tests

Re: [Intel-gfx] [PATCH i-g-t] i915/perf_pmu: Exercise I915_PMU_SOFTWARE_GT_AWAKE_TIME

On 17/12/2020 17:39, Chris Wilson wrote: Quoting Tvrtko Ursulin (2020-12-17 17:33:05) On 17/12/2020 17:26, Chris Wilson wrote: Measure the sample gt-awake time while each engine and every engine is busy. They should all report the same duration, the elapsed runtime of the batch. Signed-off

Re: [Intel-gfx] [PATCH i-g-t v2] i915/perf_pmu: Exercise I915_PMU_SOFTWARE_GT_AWAKE_TIME

On 17/12/2020 17:45, Chris Wilson wrote: Measure the sample gt-awake time while each engine and every engine is busy. They should all report the same duration, the elapsed runtime of the batch. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin --- include/drm-uapi/i915_drm.h | 3 ++- lib

[Intel-gfx] [PATCH i-g-t] lib/igt_perf: Request CLOCK_MONOTONIC when opening events

From: Tvrtko Ursulin Ask for CLOCK_MONOTONIC which is more stable than the default perf clock. (Ability to select a clock has been available since kernel version 4.1.) The change should not have any significant impact on the IGT as whole apart from maybe improving the occasional jitter in

Re: [Intel-gfx] [PATCH 1/2] i915/perf: Move gen specific OA formats to single array

On 18/12/2020 02:32, Umesh Nerlige Ramappa wrote: On Wed, Dec 16, 2020 at 09:25:35AM +, Tvrtko Ursulin wrote: On 15/12/2020 21:49, Umesh Nerlige Ramappa wrote: Variations in OA formats in the different gens has led to creation of several sparse arrays to store the formats. Move oa

Re: [Intel-gfx] [PATCH v2] drm/i915: Check for rq->hwsp validity after acquiring RCU lock

e (context) HWSP") Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin Cc: # v5.1+ --- drivers/gpu/drm/i915/gt/intel_breadcrumbs.c | 11 ++ drivers/gpu/drm/i915/gt/intel_timeline.c| 10 +++--- drivers/gpu/drm/i915/i915_request.h | 37 ++--- 3 files changed,

Re: [Intel-gfx] [PATCH v2] drm/i915: Check for rq->hwsp validity after acquiring RCU lock

On 18/12/2020 16:07, Chris Wilson wrote: Quoting Tvrtko Ursulin (2020-12-18 15:52:05) On 18/12/2020 12:24, Chris Wilson wrote: Since we allow removing the timeline map at runtime, there is a risk that rq->hwsp points into a stale page. To control that risk, we hold the RCU read lock wh

Re: [Intel-gfx] [PATCH 1/4] drm/i915/selftests: Break out of the lrc layout test after register mismatch

On 06/01/2021 12:39, Chris Wilson wrote: AFter detecting a register mismatch between the protocontext and the image generated by HW, immediately break out of the double loop. (Otherwise we end up a second configuing error message.) s/configuing/confusing/? No use of dumping all differences?

Re: [Intel-gfx] [PATCH 2/4] drm/i915/selftests: Improve handling of iomem around stolen

in = (void __force *)s; + if (i915_memcpy_from_wc(tmp, in, PAGE_SIZE)) in = tmp; x = crc32_le(0, in, PAGE_SIZE); Reviewed-by: Tvrtko Ursulin Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lis

Re: [Intel-gfx] [PATCH 1/4] drm/i915/selftests: Break out of the lrc layout test after register mismatch

On 06/01/2021 15:17, Chris Wilson wrote: Quoting Tvrtko Ursulin (2021-01-06 15:10:02) On 06/01/2021 12:39, Chris Wilson wrote: AFter detecting a register mismatch between the protocontext and the image generated by HW, immediately break out of the double loop. (Otherwise we end up a second

Re: [Intel-gfx] [PATCH 4/4] drm/i915/gt: Remove timeslice suppression

On 06/01/2021 12:39, Chris Wilson wrote: In the next^W future patch, we remove the strict priority system and continuously re-evaluate the relative priority of tasks. As such we need to enable the timeslice whenever there is more than one context in the pipeline. This simplifies the decision a

Re: [Intel-gfx] [PATCH v2 1/2] drm/i915: Wrap our timer_list.expires checking

On 06/01/2021 16:36, Chris Wilson wrote: Refactor our timer_list.expires checking into its own timer_active() helper. Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_utils.c | 2 +- drivers/gpu/drm/i915/i915_utils.h | 7 ++- 2 files changed, 7 insertions

Re: [Intel-gfx] [PATCH 4/4] drm/i915/gt: Remove timeslice suppression

On 06/01/2021 16:08, Chris Wilson wrote: Quoting Tvrtko Ursulin (2021-01-06 15:57:49) [snip] @@ -1363,16 +1336,16 @@ static void execlists_dequeue(struct intel_engine_cs *engine) __unwind_incomplete_requests(engine); last = NULL

Re: [Intel-gfx] [PATCH 4/4] drm/i915/gt: Remove timeslice suppression

On 07/01/2021 10:27, Chris Wilson wrote: Quoting Tvrtko Ursulin (2021-01-07 10:16:57) On 06/01/2021 16:08, Chris Wilson wrote: Quoting Tvrtko Ursulin (2021-01-06 15:57:49) [snip] @@ -1363,16 +1336,16 @@ static void execlists_dequeue(struct intel_engine_cs *engine

Re: [Intel-gfx] [PATCH v3] drm/i915/gt: Remove timeslice suppression

principle for timeslicing. v2: Commentary v3: Commentary for the right cancel_timer() Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2802 Testcase: igt/gem_exec_balancer/fairslice Signed-off-by: Chris Wilson Cc: Tvrtko Ursulin --- drivers/gpu/drm/i915/gt/intel_engine_types.h | 10

Re: [Intel-gfx] [PATCH 1/4] drm/i915/gt: Disable arbitration around Braswell's pdp updates

I had to remind myself that Gen8LP is indeed the only platform with 32-bit ppgtt. I presume you are fixing some sporadic CI failures here, anyway: Reviewed-by: Tvrtko Ursulin Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesk

Re: [Intel-gfx] [PATCH 2/4] drm/i915/gt: Check for arbitration after writing start seqno

On 11/01/2021 10:57, Chris Wilson wrote: On the off chance that we need to arbitrate before launching the payload, perform the check after we signal the request is ready to start. Assuming instantaneous processing of the CS event, the request will then be treated as having started when we make

Re: [Intel-gfx] [PATCH 3/4] drm/i915/gt: Perform an arbitration check before busywaiting

On 11/01/2021 10:57, Chris Wilson wrote: During igt_reset_nop_engine, it was observed that an unexpected failed engine reset lead to us busywaiting on the stop-ring semaphore (set during the reset preparations) on the first request afterwards. There was no explicit MI_ARB_CHECK in this sequence

Re: [Intel-gfx] [PATCH 4/4] drm/i915/selftests: Include engine name after reset failure

k; } Reviewed-by: Tvrtko Ursulin Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [PATCH 3/4] drm/i915/gt: Perform an arbitration check before busywaiting

On 11/01/2021 16:27, Chris Wilson wrote: Quoting Tvrtko Ursulin (2021-01-11 16:19:40) On 11/01/2021 10:57, Chris Wilson wrote: During igt_reset_nop_engine, it was observed that an unexpected failed engine reset lead to us busywaiting on the stop-ring semaphore (set during the reset

Re: [Intel-gfx] [PATCH 2/4] drm/i915/gt: Check for arbitration after writing start seqno

On 11/01/2021 16:10, Chris Wilson wrote: Quoting Tvrtko Ursulin (2021-01-11 16:03:48) On 11/01/2021 10:57, Chris Wilson wrote: On the off chance that we need to arbitrate before launching the payload, perform the check after we signal the request is ready to start. Assuming instantaneous

Re: [Intel-gfx] [PATCH 3/4] drm/i915/gt: Perform an arbitration check before busywaiting

On 11/01/2021 21:54, Chris Wilson wrote: Quoting Tvrtko Ursulin (2021-01-11 17:12:57) On 11/01/2021 16:27, Chris Wilson wrote: Quoting Tvrtko Ursulin (2021-01-11 16:19:40) On 11/01/2021 10:57, Chris Wilson wrote: During igt_reset_nop_engine, it was observed that an unexpected failed

Re: [Intel-gfx] [PATCH -next] drm/i915: use DEVICE_ATTR_RO macro

TTR_RO(media_rc6_residency_ms); static struct attribute *rc6_attrs[] = { &dev_attr_rc6_enable.attr, Reviewed-by: Tvrtko Ursulin Regards, Tvrtko ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx

Re: [Intel-gfx] [RFC PATCH 60/97] drm/i915: Track 'serial' counts for virtual engines

On 27/05/2021 18:01, John Harrison wrote: On 5/27/2021 01:53, Tvrtko Ursulin wrote: On 26/05/2021 19:45, John Harrison wrote: On 5/26/2021 01:40, Tvrtko Ursulin wrote: On 25/05/2021 18:52, Matthew Brost wrote: On Tue, May 25, 2021 at 11:16:12AM +0100, Tvrtko Ursulin wrote: On 06/05/2021

Re: [Intel-gfx] [PATCH 1/1] Let userspace know if they can trust timeslicing by including it as part of the I915_PARAM_HAS_SCHEDULER::I915_SCHEDULER_CAP_TIMESLICING

On 27/05/2021 11:27, Daniel Vetter wrote: On Thu, May 27, 2021 at 11:22:16AM +0100, Tvrtko Ursulin wrote: On 27/05/2021 11:13, Daniel Vetter wrote: On Wed, May 26, 2021 at 11:20:13AM +0100, Tvrtko Ursulin wrote: On 25/05/2021 15:47, Daniel Vetter wrote: On Tue, May 25, 2021 at 03:19:47PM

Re: [Intel-gfx] [PATCH] drm/i915/selftests: Fix return value check in live_breadcrumbs_smoketest()

On 01/06/2021 10:19, Ursulin, Tvrtko wrote: [Don't see this on intel-gfx so I have to reply with top post.] Reviewed-by: Tvrtko Ursulin Pushed with commit text wrapped and Fixes: tag fixed, thanks for the patch! Regards, Tvrtko -Original Message- From: Zhihao Cheng

Re: [Intel-gfx] [PATCH -next] drm/i915: use DEVICE_ATTR_RO macro

On 01/06/2021 10:15, Tvrtko Ursulin wrote: On 28/05/2021 11:04, YueHaibing wrote: Use DEVICE_ATTR_RO() helper instead of plain DEVICE_ATTR(), which makes the code a bit shorter and easier to read. Signed-off-by: YueHaibing ---   drivers/gpu/drm/i915/i915_pmu.c   |  8 +++-   drivers/gpu

Re: [Intel-gfx] [RFC PATCH 60/97] drm/i915: Track 'serial' counts for virtual engines

On 02/06/2021 02:20, John Harrison wrote: On 6/1/2021 02:31, Tvrtko Ursulin wrote: On 27/05/2021 18:01, John Harrison wrote: On 5/27/2021 01:53, Tvrtko Ursulin wrote: On 26/05/2021 19:45, John Harrison wrote: On 5/26/2021 01:40, Tvrtko Ursulin wrote: On 25/05/2021 18:52, Matthew Brost

Re: [Intel-gfx] [RFC PATCH 60/97] drm/i915: Track 'serial' counts for virtual engines

On 06/05/2021 20:14, Matthew Brost wrote: From: John Harrison The serial number tracking of engines happens at the backend of request submission and was expecting to only be given physical engines. However, in GuC submission mode, the decomposition of virtual to physical engines does not happ

Re: [Intel-gfx] [RFC PATCH 61/97] drm/i915: Hold reference to intel_context over life of i915_request

On 06/05/2021 20:14, Matthew Brost wrote: Hold a reference to the intel_context over life of an i915_request. Without this an i915_request can exist after the context has been destroyed (e.g. request retired, context closed, but user space holds a reference to the request from an out fence). In

Re: [Intel-gfx] [RFC PATCH 63/97] drm/i915/guc: Direct all breadcrumbs for a class to single breadcrumbs

On 06/05/2021 20:14, Matthew Brost wrote: With GuC virtual engines the physical engine which a request executes and completes on isn't known to the i915. Therefore we can't attach a request to a physical engines breadcrumbs. To work around this we create a single breadcrumbs per engine class wh

Re: [Intel-gfx] [RFC PATCH 64/97] drm/i915/guc: Reset implementation for new GuC interface

On 06/05/2021 20:14, Matthew Brost wrote: Reset implementation for new GuC interface. This is the legacy reset implementation which is called when the i915 owns the engine hang check. Future patches will offload the engine hang check to GuC but we will continue to maintain this legacy path as a

Re: [Intel-gfx] [RFC PATCH 65/97] drm/i915: Reset GPU immediately if submission is disabled

On 06/05/2021 20:14, Matthew Brost wrote: If submission is disabled by the backend for any reason, reset the GPU immediately in the heartbeat code. Okay that's what, but why is also often good to have in commit messages. Regards, Tvrtko Signed-off-by: Matthew Brost --- .../gpu/drm/i915

Re: [Intel-gfx] [RFC PATCH 00/97] Basic GuC submission support in the i915

On 25/05/2021 17:45, Matthew Brost wrote: On Tue, May 25, 2021 at 11:32:26AM +0100, Tvrtko Ursulin wrote: On 06/05/2021 20:13, Matthew Brost wrote: Basic GuC submission support. This is the first bullet point in the upstreaming plan covered in the following RFC [1]. At a very high level

Re: [Intel-gfx] [RFC PATCH 00/97] Basic GuC submission support in the i915

On 03/06/2021 05:10, Matthew Brost wrote: On Wed, Jun 02, 2021 at 04:27:18PM +0100, Tvrtko Ursulin wrote: On 25/05/2021 17:45, Matthew Brost wrote: [snip] * Kludgy way of interfacing with rest of the driver instead of refactoring to fit (idling, breadcrumbs, scheduler, tasklets

Re: [Intel-gfx] i915 and swiotlb_max_segment

Hi, On 03/06/2021 09:40, Joonas Lahtinen wrote: + Tvrtko to take a look Quoting Konrad Rzeszutek Wilk (2021-05-20 18:12:58) On Mon, May 10, 2021 at 05:25:25PM +0200, Christoph Hellwig wrote: Hi all, swiotlb_max_segment is a rather strange "API" export by swiotlb.c, and i915 is the only (re

Re: [Intel-gfx] [RFC PATCH 00/97] Basic GuC submission support in the i915

On 03/06/2021 05:47, Daniel Vetter wrote: On Thu, Jun 3, 2021 at 5:48 AM Matthew Brost wrote: On Wed, Jun 02, 2021 at 08:57:02PM +0200, Daniel Vetter wrote: On Wed, Jun 2, 2021 at 5:27 PM Tvrtko Ursulin wrote: On 25/05/2021 17:45, Matthew Brost wrote: On Tue, May 25, 2021 at 11:32:26AM

Re: [Intel-gfx] [RFC PATCH 00/97] Basic GuC submission support in the i915

On 03/06/2021 04:41, Matthew Brost wrote: On Wed, Jun 02, 2021 at 08:57:02PM +0200, Daniel Vetter wrote: On Wed, Jun 2, 2021 at 5:27 PM Tvrtko Ursulin wrote: On 25/05/2021 17:45, Matthew Brost wrote: On Tue, May 25, 2021 at 11:32:26AM +0100, Tvrtko Ursulin wrote: * Context pinning code

Re: [Intel-gfx] [PATCH 1/1] Let userspace know if they can trust timeslicing by including it as part of the I915_PARAM_HAS_SCHEDULER::I915_SCHEDULER_CAP_TIMESLICING

On 27/05/2021 11:22, Tvrtko Ursulin wrote: On 27/05/2021 11:13, Daniel Vetter wrote: On Wed, May 26, 2021 at 11:20:13AM +0100, Tvrtko Ursulin wrote: On 25/05/2021 15:47, Daniel Vetter wrote: On Tue, May 25, 2021 at 03:19:47PM +0100, Tvrtko Ursulin wrote: + dri-devel as per process On 25

Re: [Intel-gfx] [RFC PATCH 36/97] drm/i915/guc: Add non blocking CTB send function

On 07/06/2021 18:31, Matthew Brost wrote: On Thu, May 27, 2021 at 04:11:50PM +0100, Tvrtko Ursulin wrote: On 27/05/2021 15:35, Matthew Brost wrote: On Thu, May 27, 2021 at 11:02:24AM +0100, Tvrtko Ursulin wrote: On 26/05/2021 19:10, Matthew Brost wrote: [snip] +static int ct_send_nb

Re: [Intel-gfx] [PATCH 0/5] dma-fence, i915: Stop allowing SLAB_TYPESAFE_BY_RCU for dma_fence

On 09/06/2021 22:29, Jason Ekstrand wrote: Ever since 0eafec6d3244 ("drm/i915: Enable lockless lookup of request tracking via RCU"), the i915 driver has used SLAB_TYPESAFE_BY_RCU (it was called SLAB_DESTROY_BY_RCU at the time) in order to allow RCU on i915_request. As nifty as SLAB_TYPESAFE_BY_

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Move intel_engine_free_request_pool to i915_request.c

On 09/06/2021 22:29, Jason Ekstrand wrote: This appears to break encapsulation by moving an intel_engine_cs function to a i915_request file. However, this function is intrinsically tied to the lifetime rules and allocation scheme of i915_request and having it in intel_engine_cs.c leaks details

Re: [Intel-gfx] [PATCH 2/5] drm/i915: Use a simpler scheme for caching i915_request

On 09/06/2021 22:29, Jason Ekstrand wrote: Instead of attempting to recycle a request in to the cache when it retires, stuff a new one in the cache every time we allocate a request for some other reason. I supposed the "why?" is "simpler scheme" - but in what way it is simpler? Signed-off-b

Re: [Intel-gfx] [PATCH 0/5] dma-fence, i915: Stop allowing SLAB_TYPESAFE_BY_RCU for dma_fence

On 10/06/2021 12:29, Daniel Vetter wrote: On Thu, Jun 10, 2021 at 11:39 AM Christian König wrote: Am 10.06.21 um 11:29 schrieb Tvrtko Ursulin: On 09/06/2021 22:29, Jason Ekstrand wrote: Ever since 0eafec6d3244 ("drm/i915: Enable lockless lookup of request tracking via RCU"), the i

Re: [Intel-gfx] [PATCH 1/5] drm/i915: Move intel_engine_free_request_pool to i915_request.c

On 10/06/2021 14:57, Jason Ekstrand wrote: On Thu, Jun 10, 2021 at 5:04 AM Tvrtko Ursulin wrote: On 09/06/2021 22:29, Jason Ekstrand wrote: This appears to break encapsulation by moving an intel_engine_cs function to a i915_request file. However, this function is intrinsically tied to the

[Intel-gfx] [PATCH] drm/i915: Fix busy ioctl commentary

From: Tvrtko Ursulin Just tidy one instance of incorrect context parameter name and a stray sentence ending from before reporting was converted to be class based. Signed-off-by: Tvrtko Ursulin --- include/uapi/drm/i915_drm.h | 9 - 1 file changed, 4 insertions(+), 5 deletions(-) diff

[Intel-gfx] [PATCH] drm/i915: Document the Virtual Engine uAPI

From: Tvrtko Ursulin A little bit of documentation covering the topics of engine discovery, context engine maps and virtual engines. It is not very detailed but supposed to be a starting point of giving a brief high level overview of general principles and intended use cases. Signed-off-by

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for drm/i915: Steer MCR reads to lowest potential slice/subslice

On 12/06/2021 00:42, Matt Roper wrote: On Fri, Jun 11, 2021 at 05:35:53AM +, Patchwork wrote: == Series Details == Series: drm/i915: Steer MCR reads to lowest potential slice/subslice URL : https://patchwork.freedesktop.org/series/91367/ State : failure == Summary == CI Bug Log - chan

[Intel-gfx] [PATCH v2] drm/i915: Document the Virtual Engine uAPI

From: Tvrtko Ursulin A little bit of documentation covering the topics of engine discovery, context engine maps and virtual engines. It is not very detailed but supposed to be a starting point of giving a brief high level overview of general principles and intended use cases. v2: * Have the

[Intel-gfx] [PATCH v3] drm/i915: Be more gentle with exiting non-persistent context

From: Tvrtko Ursulin When a non-persistent context exits we currently mark it as banned in order to trigger fast termination of any outstanding GPU jobs it may have left running. In doing so we apply a very strict 1ms limit in which the left over job has to preempt before we issues an engine

[Intel-gfx] [PATCH v4] drm/i915: Be more gentle with exiting non-persistent context

From: Tvrtko Ursulin When a non-persistent context exits we currently mark it as banned in order to trigger fast termination of any outstanding GPU jobs it may have left running. In doing so we apply a very strict 1ms limit in which the left over job has to preempt before we issues an engine

Re: [Intel-gfx] [PATCH 3/3] drm/i915: Add support for explicit L3BANK steering

On 15/06/2021 04:34, Matt Roper wrote: Because Render Power Gating restricts us to just a single subslice as a valid steering target for reads of multicast registers in a SUBSLICE range, the default steering we setup at init may not lead to a suitable target for L3BANK multicast register. In c

[Intel-gfx] [PATCH v5] drm/i915: Be more gentle with exiting non-persistent context

From: Tvrtko Ursulin When a non-persistent context exits we currently mark it as banned in order to trigger fast termination of any outstanding GPU jobs it may have left running. In doing so we apply a very strict 1ms limit in which the left over job has to preempt before we issues an engine

Re: [Intel-gfx] [PATCH 3/3] drm/i915/uapi: Add query for L3 bank count

On 10/06/2021 21:46, john.c.harri...@intel.com wrote: From: John Harrison Various UMDs need to know the L3 bank count. So add a query API for it. Signed-off-by: John Harrison --- drivers/gpu/drm/i915/gt/intel_gt.c | 15 +++ drivers/gpu/drm/i915/gt/intel_gt.h | 1 + drivers/

[Intel-gfx] [PATCH v5] drm/i915: Be more gentle with exiting non-persistent context

From: Tvrtko Ursulin When a non-persistent context exits we currently mark it as banned in order to trigger fast termination of any outstanding GPU jobs it may have left running. In doing so we apply a very strict 1ms limit in which the left over job has to preempt before we issues an engine

Re: [Intel-gfx] [PATCH v2] drm/i915: Document the Virtual Engine uAPI

On 17/06/2021 18:17, Daniel Vetter wrote: On Mon, Jun 14, 2021 at 10:09:59AM +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin A little bit of documentation covering the topics of engine discovery, context engine maps and virtual engines. It is not very detailed but supposed to be a

[Intel-gfx] [PATCH v3] drm/i915: Document the Virtual Engine uAPI

From: Tvrtko Ursulin A little bit of documentation covering the topics of engine discovery, context engine maps and virtual engines. It is not very detailed but supposed to be a starting point of giving a brief high level overview of general principles and intended use cases. v3: * Move text

[Intel-gfx] [PATCH v4] drm/i915: Document the Virtual Engine uAPI

From: Tvrtko Ursulin A little bit of documentation covering the topics of engine discovery, context engine maps and virtual engines. It is not very detailed but supposed to be a starting point of giving a brief high level overview of general principles and intended use cases. v2: * Have the

Re: [Intel-gfx] [PATCH v4] drm/i915: Document the Virtual Engine uAPI

On 18/06/2021 21:46, Daniel Vetter wrote: On Fri, Jun 18, 2021 at 5:00 PM Tvrtko Ursulin wrote: From: Tvrtko Ursulin A little bit of documentation covering the topics of engine discovery, context engine maps and virtual engines. It is not very detailed but supposed to be a starting point

Re: [Intel-gfx] [PATCH 1/3] drm/i915/gt: Do not allow setting ring size for legacy ring submission

I had some questions on the trybot mailing list, let me copy&paste.. On 21/06/2021 12:41, Maarten Lankhorst wrote: It doesn't work for legacy ring submission, and is in the best case ignored. Looks rejected instead of ignored: static int set_ringsize(struct i915_gem_context *ctx,

Re: [Intel-gfx] [RFC 7/8] drm/i915: Inherit process nice for context scheduling priority

On 06/10/2021 18:24, Matthew Brost wrote: On Mon, Oct 04, 2021 at 03:36:49PM +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Introduce the concept of context nice value which matches the process nice. We do this by extending the struct i915_sched_attr and add a helper

Re: [Intel-gfx] [RFC 6/8] drm/i915: Make some recently added vfuncs use full scheduling attribute

On 06/10/2021 18:12, Matthew Brost wrote: On Mon, Oct 04, 2021 at 03:36:48PM +0100, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Code added in 71ed60112d5d ("drm/i915: Add kick_backend function to i915_sched_engine") and ee242ca704d3 ("drm/i915/guc: Implement GuC prio

Re: [Intel-gfx] [PATCH] drm/i915/pmu: Connect engine busyness stats from GuC to pmu

On 06/10/2021 21:45, Umesh Nerlige Ramappa wrote: On Wed, Oct 06, 2021 at 10:11:58AM +0100, Tvrtko Ursulin wrote: [snip] @@ -762,12 +764,25 @@ submission_disabled(struct intel_guc *guc)  static void disable_submission(struct intel_guc *guc)  { struct i915_sched_engine * const

Re: [Intel-gfx] [RFC 1/8] sched: Add nice value change notifier

On 06/10/2021 21:21, Barry Song wrote: On Thu, Oct 7, 2021 at 2:44 AM Tvrtko Ursulin wrote: Hi, On 06/10/2021 08:58, Barry Song wrote: On Wed, Oct 6, 2021 at 5:15 PM Wanghui (John) wrote: HI Tvrtko On 2021/10/4 22:36, Tvrtko Ursulin wrote: void set_user_nice(struct task_struct

Re: [Intel-gfx] [RFC 1/8] sched: Add nice value change notifier

On 07/10/2021 09:50, Tvrtko Ursulin wrote: On 06/10/2021 21:21, Barry Song wrote: On Thu, Oct 7, 2021 at 2:44 AM Tvrtko Ursulin wrote: Hi, On 06/10/2021 08:58, Barry Song wrote: On Wed, Oct 6, 2021 at 5:15 PM Wanghui (John) wrote: HI Tvrtko On 2021/10/4 22:36, Tvrtko Ursulin wrote

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v7,1/8] drm/i915/gem: Break out some shmem backend utils

Hi, On 06/10/2021 16:26, Patchwork wrote: *Patch Details* *Series:* series starting with [v7,1/8] drm/i915/gem: Break out some shmem backend utils *URL:* https://patchwork.freedesktop.org/series/95501/ *State:*failure *Details:* ht

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v7,1/8] drm/i915/gem: Break out some shmem backend utils

On 07/10/2021 10:19, Christian König wrote: Am 07.10.21 um 11:15 schrieb Tvrtko Ursulin: Hi, On 06/10/2021 16:26, Patchwork wrote: *Patch Details* *Series:*    series starting with [v7,1/8] drm/i915/gem: Break out some shmem backend utils *URL:*    https://patchwork.freedesktop.org/series

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v7,1/8] drm/i915/gem: Break out some shmem backend utils

On 07/10/2021 13:57, Christian König wrote: Am 07.10.21 um 12:51 schrieb Tvrtko Ursulin: On 07/10/2021 10:19, Christian König wrote: Am 07.10.21 um 11:15 schrieb Tvrtko Ursulin: Hi, On 06/10/2021 16:26, Patchwork wrote: *Patch Details* *Series:*    series starting with [v7,1/8] drm/i915

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v7,1/8] drm/i915/gem: Break out some shmem backend utils

On 07/10/2021 16:18, Vudum, Lakshminarayana wrote: -Original Message- From: Tvrtko Ursulin Sent: Thursday, October 7, 2021 6:41 AM To: Christian König ; intel-gfx@lists.freedesktop.org Cc: Vudum, Lakshminarayana Subject: Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with

Re: [Intel-gfx] [PATCH v3] drm/dp: Add Additional DP2 Headers

Hi, Is it my checkout only or this causes a lot of build warnings for everyone? ./include/drm/drm_dp_helper.h:1120: warning: "DP_TEST_264BIT_CUSTOM_PATTERN_7_0" redefined 1120 | #define DP_TEST_264BIT_CUSTOM_PATTERN_7_0 0x2230 | In file included from ./drivers/gpu/drm/amd/amdgpu/../di

Re: [Intel-gfx] [PATCH] drm/i915/gem: Check function return in live_nop_switch

On 07/10/2021 23:55, Oak Zeng wrote: Fail this test earlier if i915_request_await_dma_fence fails. Why only this instance and not the other one in the same function? Signed-off-by: Oak Zeng --- drivers/gpu/drm/i915/gem/selftests/i915_gem_context.c | 9 - 1 file changed, 8 insert

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v7,1/8] drm/i915/gem: Break out some shmem backend utils

On 07/10/2021 19:18, Christian König wrote: Am 07.10.21 um 17:53 schrieb Tvrtko Ursulin: On 07/10/2021 16:18, Vudum, Lakshminarayana wrote: -Original Message- From: Tvrtko Ursulin Sent: Thursday, October 7, 2021 6:41 AM To: Christian König ; intel-gfx@lists.freedesktop.org Cc

Re: [Intel-gfx] ✗ Fi.CI.IGT: failure for series starting with [v7,1/8] drm/i915/gem: Break out some shmem backend utils

On 08/10/2021 10:17, Tvrtko Ursulin wrote: On 07/10/2021 19:18, Christian König wrote: Am 07.10.21 um 17:53 schrieb Tvrtko Ursulin: On 07/10/2021 16:18, Vudum, Lakshminarayana wrote: -Original Message- From: Tvrtko Ursulin Sent: Thursday, October 7, 2021 6:41 AM To: Christian

[Intel-gfx] [PATCH] dma-resv: Fix dma_resv_get_fences and dma_resv_copy_fences after conversion

From: Tvrtko Ursulin Cache the count of shared fences in the iterator to avoid dereferencing the dma_resv_object outside the RCU protection. Otherwise iterator and its users can observe an incosistent state which makes it impossible to use safely. Such as: <6> [187.517041] [IGT] ge

  1   2   3   4   5   6   7   8   9   10   >