Re: [Intel-gfx] [PATCH v5 4/4] drm/i915: add guard page to ggtt->error_capture

On 08/03/2023 15:39, Andrzej Hajda wrote: Write-combining memory allows speculative reads by CPU. ggtt->error_capture is WC mapped to CPU, so CPU/MMU can try to prefetch memory beyond the error_capture, ie it tries to read memory pointed by next PTE in GGTT. If this PTE points to invalid addres

Re: [Intel-gfx] [PATCH 2/2] drm/i915/pmu: Use correct requested freq for SLPC

On 08/03/2023 05:36, Dixit, Ashutosh wrote: On Mon, 06 Mar 2023 03:10:24 -0800, Tvrtko Ursulin wrote: Hi Tvrtko, On 04/03/2023 01:27, Ashutosh Dixit wrote: SLPC does not use 'struct intel_rps'. Use UNSLICE_RATIO bits from Would it be more accurate to say 'SLPC d

Re: [Intel-gfx] [PATCH 1/2] drm/i915/pmu: Use only freq bits for falling back to requested freq

On 08/03/2023 05:36, Dixit, Ashutosh wrote: On Mon, 06 Mar 2023 03:04:40 -0800, Tvrtko Ursulin wrote: Hi Tvrtko, On 04/03/2023 01:27, Ashutosh Dixit wrote: On newer generations, the GEN12_RPSTAT1 register contains more than freq information, e.g. see GEN12_VOLTAGE_MASK. Therefore use

[Intel-gfx] [RFC 10/12] drm/i915: Waitboost external waits

From: Tvrtko Ursulin Userspace waits coming via the drm_syncobj route have so far been bypassing the waitboost mechanism. Use the previously added dma-fence wait tracking API and apply the same waitboosting logic which applies to other entry points. This should fix the perfomance regressions

[Intel-gfx] [RFC 09/12] drm/syncobj: Mark syncobj waits as external waiters

From: Tvrtko Ursulin Use the previously added dma-fence tracking of explicit waiters. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/drm_syncobj.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c index

[Intel-gfx] [RFC 12/12] drm/i915: Wait boost requests waited upon by others

From: Tvrtko Ursulin Use the newly added dma-fence API to apply waitboost not only requests which have been marked with I915_WAIT_PRIORITY by i915, but which may be waited upon by others (such as for instance buffer sharing in multi-GPU scenarios). Signed-off-by: Tvrtko Ursulin --- drivers

[Intel-gfx] [RFC 11/12] drm/i915: Mark waits as explicit

From: Tvrtko Ursulin Use the previously added dma-fence API to mark the direct i915 waits as explicit. This has no significant effect apart from following the new pattern. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_request.c | 3 ++- 1 file changed, 2 insertions(+), 1

[Intel-gfx] [RFC 08/12] dma-fence-chain: Propagate wait status to contained fences

From: Tvrtko Ursulin As signaling is enabled on the container fence we need to propagate any external waiting status to individual fences in order to enable owning drivers see it. Signed-off-by: Tvrtko Ursulin --- drivers/dma-buf/dma-fence-chain.c | 22 -- include/linux

[Intel-gfx] [RFC 05/12] dma-fence: Track explicit waiters

From: Tvrtko Ursulin Track how many callers are explicity waiting on a fence to signal and allow querying that via new dma_fence_wait_count() API. This provides infrastructure on top of which generic "waitboost" concepts can be implemented by individual drivers. Wait-boosting is an

[Intel-gfx] [RFC 06/12] dma-fence: Export __dma_fence_add_callback

From: Tvrtko Ursulin ... Signed-off-by: Tvrtko Ursulin --- drivers/dma-buf/dma-fence.c | 9 + include/linux/dma-fence.h | 3 +++ 2 files changed, 8 insertions(+), 4 deletions(-) diff --git a/drivers/dma-buf/dma-fence.c b/drivers/dma-buf/dma-fence.c index bdba5a8e21b1..5607acdb6ccf

[Intel-gfx] [RFC 07/12] dma-fence-array: Propagate wait status to contained fences

From: Tvrtko Ursulin As signaling is enabled on the container fence we need to propagate any external waiting status to individual fences in order to enable owning drivers see it. Signed-off-by: Tvrtko Ursulin --- drivers/dma-buf/dma-fence-array.c | 5 +++-- 1 file changed, 3 insertions(+), 2

[Intel-gfx] [RFC 03/12] drm/i915: Use fence callback initialization helper

From: Tvrtko Ursulin Use the previously added initialization helper to ensure correct operation of the common code. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_active.c | 2 +- drivers/gpu/drm/i915/i915_active.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff

[Intel-gfx] [RFC 04/12] drm/vmwgfx: Use fence callback initialization helper

From: Tvrtko Ursulin Use the previously added initialization helper to ensure correct operation of the common code. Signed-off-by: Tvrtko Ursulin Cc: Zack Rusin --- drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm

[Intel-gfx] [RFC 02/12] dma-fence: Add callback initialization helper

From: Tvrtko Ursulin In preparation of adding a new field to struct dma_fence_cb we will need an initialization helper for those callers who add callbacks by open- coding. That will ensure they initialize all the fields so common code does not get confused by potential garbage in some fields

[Intel-gfx] [RFC 01/12] dma-fence: Move i915 helpers into common

From: Tvrtko Ursulin Unhide some i915 helpers which are used for splitting the signalled check vs notification stages during en masse fence processing. Signed-off-by: Tvrtko Ursulin --- drivers/dma-buf/dma-fence.c | 35 +++-- drivers/gpu/drm/i915/gt

[Intel-gfx] [RFC v4 00/12] Waitboost drm syncobj waits

From: Tvrtko Ursulin In i915 we have this concept of "wait boosting" where we give a priority boost for instance to fences which are actively waited upon from userspace. This has it's pros and cons and can certainly be discussed at lenght. However fact is some workloads really li

Re: [Intel-gfx] [PATCH 2/2] drm/i915/pmu: Use correct requested freq for SLPC

On 04/03/2023 01:27, Ashutosh Dixit wrote: SLPC does not use 'struct intel_rps'. Use UNSLICE_RATIO bits from Would it be more accurate to say 'SLPC does not use rps->cur_freq' rather than it not using struct intel_rps? Fixes: / stable ? CI chances of catching this? GEN6_RPNSWREQ for SLPC

Re: [Intel-gfx] [PATCH 1/2] drm/i915/pmu: Use only freq bits for falling back to requested freq

On 04/03/2023 01:27, Ashutosh Dixit wrote: On newer generations, the GEN12_RPSTAT1 register contains more than freq information, e.g. see GEN12_VOLTAGE_MASK. Therefore use only the freq bits to decide whether to fall back to requested freq. Could you find an appropriate Fixes: tag please? If

Re: [Intel-gfx] [PATCH v9 15/15] drm/i915: Add deadline based boost support

On 03/03/2023 14:48, Rob Clark wrote: On Fri, Mar 3, 2023 at 1:58 AM Tvrtko Ursulin wrote: On 03/03/2023 03:21, Rodrigo Vivi wrote: On Thu, Mar 02, 2023 at 03:53:37PM -0800, Rob Clark wrote: From: Rob Clark missing some wording here... v2: rebase Signed-off-by: Rob Clark

Re: [Intel-gfx] [PATCH v4] drm/i915: add guard page to ggtt->error_capture

On 02/03/2023 11:00, Andrzej Hajda wrote: On 02.03.2023 11:43, Tvrtko Ursulin wrote: On 08/02/2023 10:51, Andrzej Hajda wrote: Write-combining memory allows speculative reads by CPU. ggtt->error_capture is WC mapped to CPU, so CPU/MMU can try to prefetch memory beyond the error_capture,

Re: [Intel-gfx] [PATCH v9 15/15] drm/i915: Add deadline based boost support

On 03/03/2023 03:21, Rodrigo Vivi wrote: On Thu, Mar 02, 2023 at 03:53:37PM -0800, Rob Clark wrote: From: Rob Clark missing some wording here... v2: rebase Signed-off-by: Rob Clark --- drivers/gpu/drm/i915/i915_request.c | 20 1 file changed, 20 insertions(+) d

Re: [Intel-gfx] [PATCH v4] drm/i915: add guard page to ggtt->error_capture

can affect them as well. Signed-off-by: Andrzej Hajda Reviewed-by: Andi Shyti Research tells the explanation is plausible so: Acked-by: Tvrtko Ursulin On patch details below. What about "simiar risk in other places" - are there any plans to asses the potential impact elsewhere? -

Re: [Intel-gfx] [PATCH] drm/i915/mtl: Apply Wa_14017073508 for MTL SoC Step

On 23/02/2023 18:41, Badal Nilawar wrote: Apply Wa_14017073508 for MTL SoC die A step instead of graphics step. To get the SoC die stepping there is no direct interface so using revid as revid 0 aligns with SoC die A step. Bspec: 55420 Fixes: 8f70f1ec587d ("drm/i915/mtl: Add Wa_14017073508 fo

Re: [Intel-gfx] [PATCH] drm/i915/sseu: fix max_subslices array-index-out-of-bounds access

On 20/02/2023 17:18, Andrea Righi wrote: It seems that commit bc3c5e0809ae ("drm/i915/sseu: Don't try to store EU mask internally in UAPI format") exposed a potential out-of-bounds access, reported by UBSAN as following on a laptop with a gen 11 i915 card: UBSAN: array-index-out-of-bounds

Re: [Intel-gfx] [RFC v2 0/5] Waitboost drm syncobj waits

On 20/02/2023 16:44, Tvrtko Ursulin wrote: On 20/02/2023 15:52, Rob Clark wrote: On Mon, Feb 20, 2023 at 3:33 AM Tvrtko Ursulin wrote: On 17/02/2023 20:45, Rodrigo Vivi wrote: [snip] Yeah I agree. And as not all media use cases are the same, as are not all compute contexts someone

Re: [Intel-gfx] [RFC v2 0/5] Waitboost drm syncobj waits

On 20/02/2023 15:52, Rob Clark wrote: On Mon, Feb 20, 2023 at 3:33 AM Tvrtko Ursulin wrote: On 17/02/2023 20:45, Rodrigo Vivi wrote: [snip] Yeah I agree. And as not all media use cases are the same, as are not all compute contexts someone somewhere will need to run a series of

Re: [Intel-gfx] [RFC v2 0/5] Waitboost drm syncobj waits

On 20/02/2023 15:45, Rob Clark wrote: On Mon, Feb 20, 2023 at 4:22 AM Tvrtko Ursulin wrote: On 17/02/2023 17:00, Rob Clark wrote: On Fri, Feb 17, 2023 at 8:03 AM Tvrtko Ursulin wrote: [snip] adapted from your patches.. I think the basic idea of deadlines (which includes "I wa

Re: [Intel-gfx] [PATCH v4 14/14] drm/i915: Add deadline based boost support

On 18/02/2023 21:15, Rob Clark wrote: From: Rob Clark Signed-off-by: Rob Clark --- This should probably be re-written by someone who knows the i915 request/timeline stuff better, to deal with non-immediate deadlines. But as-is I think this should be enough to handle the case where we want s

Re: [Intel-gfx] [RFC 5/9] dma-fence: Track explicit waiters

On 18/02/2023 19:54, Rob Clark wrote: On Thu, Feb 16, 2023 at 3:00 AM Tvrtko Ursulin wrote: From: Tvrtko Ursulin Track how many callers are explicity waiting on a fence to signal and allow querying that via new dma_fence_wait_count() API. This provides infrastructure on top of which

Re: [Intel-gfx] [RFC 6/9] drm/syncobj: Mark syncobj waits as external waiters

On 18/02/2023 19:56, Rob Clark wrote: On Thu, Feb 16, 2023 at 2:59 AM Tvrtko Ursulin wrote: From: Tvrtko Ursulin Use the previously added dma-fence tracking of explicit waiters. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/drm_syncobj.c | 6 +++--- 1 file changed, 3 insertions

Re: [Intel-gfx] [RFC v2 0/5] Waitboost drm syncobj waits

On 17/02/2023 17:00, Rob Clark wrote: On Fri, Feb 17, 2023 at 8:03 AM Tvrtko Ursulin wrote: [snip] adapted from your patches.. I think the basic idea of deadlines (which includes "I want it NOW" ;-)) isn't controversial, but the original idea got caught up in some bikes

Re: [Intel-gfx] [RFC v2 0/5] Waitboost drm syncobj waits

On 17/02/2023 20:45, Rodrigo Vivi wrote: On Fri, Feb 17, 2023 at 09:00:49AM -0800, Rob Clark wrote: On Fri, Feb 17, 2023 at 8:03 AM Tvrtko Ursulin wrote: On 17/02/2023 14:55, Rob Clark wrote: On Fri, Feb 17, 2023 at 4:56 AM Tvrtko Ursulin wrote: On 16/02/2023 18:19, Rodrigo Vivi

Re: [Intel-gfx] [PATCH v3 0/2] Don't use stolen memory or BAR mappings for ring buffers

fers with LLC drm/i915: Don't use BAR mappings for ring buffers with LLC drivers/gpu/drm/i915/gt/intel_ring.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) It is doing what it laid out as the problem statement so series looks good to me. Acked-by: Tvrtko Ursulin Regards, Tvrtko

Re: [Intel-gfx] [RFC v2 0/5] Waitboost drm syncobj waits

On 17/02/2023 14:55, Rob Clark wrote: On Fri, Feb 17, 2023 at 4:56 AM Tvrtko Ursulin wrote: On 16/02/2023 18:19, Rodrigo Vivi wrote: On Tue, Feb 14, 2023 at 11:14:00AM -0800, Rob Clark wrote: On Fri, Feb 10, 2023 at 5:07 AM Tvrtko Ursulin wrote: From: Tvrtko Ursulin In i915 we have

Re: [Intel-gfx] [RFC v2 0/5] Waitboost drm syncobj waits

On 16/02/2023 18:19, Rodrigo Vivi wrote: On Tue, Feb 14, 2023 at 11:14:00AM -0800, Rob Clark wrote: On Fri, Feb 10, 2023 at 5:07 AM Tvrtko Ursulin wrote: From: Tvrtko Ursulin In i915 we have this concept of "wait boosting" where we give a priority boost for instance to fences

Re: [Intel-gfx] [PATCH v5] drm/i915: Consolidate TLB invalidation flow

On 16/02/2023 15:41, Matt Roper wrote: On Thu, Feb 16, 2023 at 09:21:23AM +, Tvrtko Ursulin wrote: From: Tvrtko Ursulin As the logic for selecting the register and corresponsing values grew, the code become a bit unsightly. Consolidate by storing the required values at engine init time

Re: [Intel-gfx] [RFC v2 0/5] Waitboost drm syncobj waits

On 14/02/2023 19:14, Rob Clark wrote: On Fri, Feb 10, 2023 at 5:07 AM Tvrtko Ursulin wrote: From: Tvrtko Ursulin In i915 we have this concept of "wait boosting" where we give a priority boost for instance to fences which are actively waited upon from userspace. This has it'

[Intel-gfx] [RFC 7/9] drm/i915: Waitboost external waits

From: Tvrtko Ursulin Userspace waits coming via the drm_syncobj route have so far been bypassing the waitboost mechanism. Use the previously added dma-fence wait tracking API and apply the same waitboosting logic which applies to other entry points. This should fix the perfomance regressions

[Intel-gfx] [RFC 9/9] drm/i915: Wait boost requests waited upon by others

From: Tvrtko Ursulin Use the newly added dma-fence API to apply waitboost not only requests which have been marked with I915_WAIT_PRIORITY by i915, but which may be waited upon by others (such as for instance buffer sharing in multi-GPU scenarios). Signed-off-by: Tvrtko Ursulin --- drivers

[Intel-gfx] [RFC 8/9] drm/i915: Mark waits as explicit

From: Tvrtko Ursulin Use the previously added dma-fence API to mark the direct i915 waits as explicit. This has no significant effect apart from following the new pattern. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_request.c | 3 ++- 1 file changed, 2 insertions(+), 1

[Intel-gfx] [RFC 5/9] dma-fence: Track explicit waiters

From: Tvrtko Ursulin Track how many callers are explicity waiting on a fence to signal and allow querying that via new dma_fence_wait_count() API. This provides infrastructure on top of which generic "waitboost" concepts can be implemented by individual drivers. Wait-boosting is an

[Intel-gfx] [RFC 3/9] drm/i915: Use fence callback initialization helper

From: Tvrtko Ursulin Use the previously added initialization helper to ensure correct operation of the common code. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_active.c | 2 +- drivers/gpu/drm/i915/i915_active.h | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) diff

[Intel-gfx] [RFC 6/9] drm/syncobj: Mark syncobj waits as external waiters

From: Tvrtko Ursulin Use the previously added dma-fence tracking of explicit waiters. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/drm_syncobj.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c index

[Intel-gfx] [RFC 4/9] drm/vmwgfx: Use fence callback initialization helper

From: Tvrtko Ursulin Use the previously added initialization helper to ensure correct operation of the common code. Signed-off-by: Tvrtko Ursulin Cc: Zack Rusin --- drivers/gpu/drm/vmwgfx/vmwgfx_fence.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/gpu/drm

[Intel-gfx] [RFC 2/9] dma-fence: Add callback initialization helper

From: Tvrtko Ursulin In preparation of adding a new field to struct dma_fence_cb we will need an initialization helper for those callers who add callbacks by open- coding. That will ensure they initialize all the fields so common code does not get confused by potential garbage in some fields

[Intel-gfx] [RFC v3 0/9] Waitboost drm syncobj waits

From: Tvrtko Ursulin In i915 we have this concept of "wait boosting" where we give a priority boost for instance to fences which are actively waited upon from userspace. This has it's pros and cons and can certainly be discussed at lenght. However fact is some workloads really li

[Intel-gfx] [RFC 1/9] dma-fence: Move i915 helpers into common

From: Tvrtko Ursulin Unhide some i915 helpers which are used for splitting the signalled check vs notification stages during en masse fence processing. Signed-off-by: Tvrtko Ursulin --- drivers/dma-buf/dma-fence.c | 35 +++-- drivers/gpu/drm/i915/gt

[Intel-gfx] [PATCH v5] drm/i915: Consolidate TLB invalidation flow

From: Tvrtko Ursulin As the logic for selecting the register and corresponsing values grew, the code become a bit unsightly. Consolidate by storing the required values at engine init time in the engine itself, and by doing so minimise the amount of invariant platform and engine checks during

Re: [Intel-gfx] [PATCH] drm/i915: Don't use stolen memory for ring buffers

On 15/02/2023 01:56, Ceraolo Spurio, Daniele wrote: On 2/14/2023 3:48 PM, john.c.harri...@intel.com wrote: From: John Harrison Direction from hardware is that stolen memory should never be used for ring buffer allocations. There are too many caching pitfalls due to the way stolen memory ac

Re: [Intel-gfx] [PATCH v3] drm/i915: Consolidate TLB invalidation flow

On 02/02/2023 09:39, Andrzej Hajda wrote: On 02.02.2023 09:33, Tvrtko Ursulin wrote: On 02/02/2023 07:43, Andrzej Hajda wrote: On 01.02.2023 17:51, Tvrtko Ursulin wrote: [snip] Btw - do you have any idea why the test is suppressed already?! CI told me BAT was a success... Except

Re: [Intel-gfx] [PATCH] drm/i915/gt: Use i915 instead of dev_priv as name for the private device

t think this patch that affects only the content of "gt/" has any dependency on dev_priv macros so that please let me know if anyone has anything against. No complaints, to the contrary! Acked-by: Tvrtko Ursulin Regards, Tvrtko

[Intel-gfx] [PATCH i-g-t] intel_gpu_top: Add compute class names

From: Tvrtko Ursulin No one remembered to add names for the new compute engines. Signed-off-by: Tvrtko Ursulin --- tools/intel_gpu_top.c | 4 1 file changed, 4 insertions(+) diff --git a/tools/intel_gpu_top.c b/tools/intel_gpu_top.c index c043c8960dd0..e13e35b71f4b 100644 --- a/tools

[Intel-gfx] [RFC 3/5] drm/i915: Waitboost external waits

From: Tvrtko Ursulin Userspace waits coming via the drm_syncobj route have so far been bypassing the waitboost mechanism. Use the previously added dma-fence wait tracking API and apply the same waitboosting logic which applies to other entry points. This should fix the perfomance regressions

[Intel-gfx] [RFC 5/5] drm/i915: Wait boost requests waited upon by others

From: Tvrtko Ursulin Use the newly added dma-fence API to apply waitboost not only requests which have been marked with I915_WAIT_PRIORITY by i915, but which may be waited upon by others (such as for instance buffer sharing in multi-GPU scenarios). Signed-off-by: Tvrtko Ursulin --- drivers

[Intel-gfx] [RFC 4/5] drm/i915: Mark waits as explicit

From: Tvrtko Ursulin Use the previously added dma-fence API to mark the direct i915 waits as explicit. This has no significant effect apart from following the new pattern. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/i915/i915_request.c | 3 ++- 1 file changed, 2 insertions(+), 1

[Intel-gfx] [RFC 2/5] drm/syncobj: Mark syncobj waits as external waiters

From: Tvrtko Ursulin Use the previously added dma-fence tracking of explicit waiters. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/drm_syncobj.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c index

[Intel-gfx] [RFC v2 0/5] Waitboost drm syncobj waits

From: Tvrtko Ursulin In i915 we have this concept of "wait boosting" where we give a priority boost for instance to fences which are actively waited upon from userspace. This has it's pros and cons and can certainly be discussed at lenght. However fact is some workloads really li

[Intel-gfx] [RFC 1/5] dma-fence: Track explicit waiters

From: Tvrtko Ursulin Track how many callers are explicity waiting on a fence to signal and allow querying that via new dma_fence_wait_count() API. This provides infrastructure on top of which generic "waitboost" concepts can be implemented by individual drivers. Wait-boosting is an

[Intel-gfx] [RFC 2/3] drm/syncobj: Mark syncobj waits as external waiters

From: Tvrtko Ursulin Use the previously added dma-fence tracking of explicit waiters. Signed-off-by: Tvrtko Ursulin --- drivers/gpu/drm/drm_syncobj.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/drivers/gpu/drm/drm_syncobj.c b/drivers/gpu/drm/drm_syncobj.c index

[Intel-gfx] [RFC 3/3] drm/i915: Waitboost external waits

From: Tvrtko Ursulin Userspace waits coming via the drm_syncobj route have so far been bypassing the waitboost mechanism. Use the previously added dma-fence wait tracking API and apply the same waitboosting logic which applies to other entry points. This should fix the perfomance regressions

[Intel-gfx] [RFC 1/3] dma-fence: Track explicit waiters

From: Tvrtko Ursulin Track how many callers are explicity waiting on a fence to signal and allow querying that via new dma_fence_wait_count() API. This provides infrastructure on top of which generic "waitboost" concepts can be implemented by individual drivers. Wait-boosting is an

[Intel-gfx] [RFC 0/3] Waitboost drm syncobj waits

From: Tvrtko Ursulin In i915 we have this concept of "wait boosting" where we give a priority boost for instance to fences which are actively waited upon from userspace. This has it's pros and cons and can certainly be discussed at lenght. However fact is some workloads really li

Re: [Intel-gfx] [PATCH i-g-t 1/3] intel_gpu_top: Do not repeat header lines in non-interactive output

On 08/02/2023 12:31, Kamil Konieczny wrote: Hi Tvrtko, one small nit, see below. On 2023-02-03 at 11:16:34 +, Tvrtko Ursulin wrote: From: Tvrtko Ursulin If output is redirected to a file, or a pipe, lets not repeat the headers because that can usually mean user is trying to parse the

Re: [Intel-gfx] [bug report] drm/i915: Allow compaction upto SWIOTLB max segment size

On 07/02/2023 08:49, Dan Carpenter wrote: On Mon, Feb 06, 2023 at 04:59:36PM +, Tvrtko Ursulin wrote: On 06/02/2023 14:19, Dan Carpenter wrote: [ Ancient code but the warning showed up again because the function was renamed or something? - dan ] Hello Chris Wilson, The patch

Re: [Intel-gfx] [bug report] drm/i915: Allow compaction upto SWIOTLB max segment size

On 06/02/2023 14:19, Dan Carpenter wrote: [ Ancient code but the warning showed up again because the function was renamed or something? - dan ] Hello Chris Wilson, The patch 871dfbd67d4e: "drm/i915: Allow compaction upto SWIOTLB max segment size" from Oct 11, 2016, leads to the following S

Re: [Intel-gfx] [PATCH v2] drm/i915: Initialize the obj flags for shmem objects

ags should have been grouped with the ones below in one block. I have tidied this while pushing, thanks for the fix and review! Regards, Tvrtko v2: Add fixes tag (Tvrtko, Matt A) Cc: Matthew Auld Cc: Tvrtko Ursulin Reviewed-by: Matthew Auld Signed-off-by: Aravind Iddamsetty --- drivers/gp

Re: [Intel-gfx] [PATCH] drm/i915/gt: Avoid redundant pointer validity check

Hi, Adding Matt & Thomas as potential candidates to review. Regards, Tvrtko On 03/02/2023 19:30, Deepak R Varma wrote: The macro definition of gen6_for_all_pdes() expands to a for loop such that it breaks when the page table is null. Hence there is no need to again test validity of the page

Re: [Intel-gfx] [PATCH] drm/i915: Move fd_install after last use of fence

visable to userspace, so it must be the last thing we do with the fence. Fixes: 00dae4d3d35d ("drm/i915: Implement SINGLE_TIMELINE with a syncobj (v4)") This is correct and the fix looks good to me. Reviewed-by: Tvrtko Ursulin CI is green so I will merge it, thanks again for

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 8/8] gputop: Basic vendor agnostic GPU top tool

On 03/02/2023 16:42, Kamil Konieczny wrote: Hi Tvrtko, On 2023-01-31 at 11:32:37 +, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Rudimentary vendor agnostic example of how lib_igt_drm_clients can be used to display a sorted by card and usage list of processes using GPUs. Borrows a bit

Re: [Intel-gfx] [PATCH] Initialize the obj flags for shmem objects

On 03/02/2023 11:57, Aravind Iddamsetty wrote: Obj flags for shmem objects is not being set correctly. Cc: Matthew Auld Signed-off-by: Aravind Iddamsetty Could even be: Fixes: 13d29c823738 ("drm/i915/ehl: unconditionally flush the pages on acquire") Cc: # v5.15+ ? Regards, Tvrtko -

[Intel-gfx] [PATCH i-g-t 3/3] intel_gpu_top: Add CSV output format

From: Tvrtko Ursulin Add CSV output mode. Signed-off-by: Tvrtko Ursulin Cc: Caleb Callaway --- man/intel_gpu_top.rst | 3 ++ tools/intel_gpu_top.c | 78 +-- 2 files changed, 78 insertions(+), 3 deletions(-) diff --git a/man/intel_gpu_top.rst b/man

[Intel-gfx] [PATCH i-g-t 3/3] intel_gpu_top: Add CSV output format

From: Tvrtko Ursulin Add CSV output mode. Signed-off-by: Tvrtko Ursulin Cc: Caleb Callaway --- man/intel_gpu_top.rst | 3 ++ tools/intel_gpu_top.c | 78 +-- 2 files changed, 78 insertions(+), 3 deletions(-) diff --git a/man/intel_gpu_top.rst b/man

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 3/3] intel_gpu_top: Add CVS output format

On 03/02/2023 11:22, Ville Syrjälä wrote: On Fri, Feb 03, 2023 at 11:16:36AM +, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Add CVS output mode. Should that be csv? Lol at least I was consistent.. facepalm. Regards, Tvrtko Signed-off-by: Tvrtko Ursulin Cc: Caleb Callaway

[Intel-gfx] [PATCH i-g-t 1/3] intel_gpu_top: Do not repeat header lines in non-interactive output

From: Tvrtko Ursulin If output is redirected to a file, or a pipe, lets not repeat the headers because that can usually mean user is trying to parse the data later and so repeated headers are a hindrance. Signed-off-by: Tvrtko Ursulin Cc: Caleb Callaway --- tools/intel_gpu_top.c | 19

[Intel-gfx] [PATCH i-g-t 3/3] intel_gpu_top: Add CVS output format

From: Tvrtko Ursulin Add CVS output mode. Signed-off-by: Tvrtko Ursulin Cc: Caleb Callaway --- man/intel_gpu_top.rst | 3 ++ tools/intel_gpu_top.c | 78 +-- 2 files changed, 78 insertions(+), 3 deletions(-) diff --git a/man/intel_gpu_top.rst b/man

[Intel-gfx] [PATCH i-g-t 2/3] intel_gpu_top: Rename STDOUT to TEXT

From: Tvrtko Ursulin Internal cleanup only - the name text is more accurate given the output can also go to a file. Signed-off-by: Tvrtko Ursulin Cc: Caleb Callaway --- tools/intel_gpu_top.c | 54 +-- 1 file changed, 26 insertions(+), 28 deletions

[Intel-gfx] [PATCH i-g-t 0/3] More intel_gpu_top improvements

From: Tvrtko Ursulin Suggestion was received to omit repeating header lines when outputting to a file and also to add the CVS mode for easy parsing. We have JSON but I guess CVS can definitely be easier for some use cases. Tvrtko Ursulin (3): intel_gpu_top: Do not repeat header lines in non

Re: [Intel-gfx] [PATCH] drm/i915/pxp: limit drm-errors or warnings on firmware API failures

On 02/02/2023 17:11, Teres Alexis, Alan Previn wrote: On Thu, 2023-02-02 at 08:43 +, Tvrtko Ursulin wrote: On 02/02/2023 08:13, Alan Previn wrote: MESA driver is creating protected context on every driver handle initialization to query caps bit for app. So when running CI tests, they

Re: [Intel-gfx] [RFC 10/12] cgroup/drm: Introduce weight based drm cgroup control

On 28/01/2023 01:11, Tejun Heo wrote: On Thu, Jan 12, 2023 at 04:56:07PM +, Tvrtko Ursulin wrote: ... + /* +* 1st pass - reset working values and update hierarchical weights and +* GPU utilisation. +*/ + if (!__start_scanning(root, period_us

Re: [Intel-gfx] [PATCH] drm/i915/pxp: limit drm-errors or warnings on firmware API failures

On 02/02/2023 08:13, Alan Previn wrote: MESA driver is creating protected context on every driver handle initialization to query caps bit for app. So when running CI tests, they are observing hundreds of drm_errors when enabling PXP in .config but using SOC or BIOS configuration that cannot sup

Re: [Intel-gfx] [PATCH v3] drm/i915: Consolidate TLB invalidation flow

On 02/02/2023 07:43, Andrzej Hajda wrote: On 01.02.2023 17:51, Tvrtko Ursulin wrote: [snip] +static int intel_engine_init_tlb_invalidation(struct intel_engine_cs *engine) +{ +    static const union intel_engine_tlb_inv_reg gen8_regs[] = { +    [RENDER_CLASS].reg    = GEN8_RTCR

[Intel-gfx] [PATCH v4] drm/i915: Consolidate TLB invalidation flow

From: Tvrtko Ursulin As the logic for selecting the register and corresponsing values grew, the code become a bit unsightly. Consolidate by storing the required values at engine init time in the engine itself, and by doing so minimise the amount of invariant platform and engine checks during

[Intel-gfx] [PATCH v3] drm/i915: Consolidate TLB invalidation flow

From: Tvrtko Ursulin As the logic for selecting the register and corresponsing values grew, the code become a bit unsightly. Consolidate by storing the required values at engine init time in the engine itself, and by doing so minimise the amount of invariant platform and engine checks during

[Intel-gfx] [PULL] drm-intel-gt-next

- Document where to implement register workarounds (Gustavo Sousa) - Use uabi engines for the default engine map (Tvrtko Ursulin) - Flush all tiles on test exit (Tvrtko Ursulin) - Annotate a couple more workaround registers as MCR (Matt Roper) Driver refactors: - Add and use GuC oriented print macr

Re: [Intel-gfx] ✓ Fi.CI.IGT: success for GuC oriented print macros (rev3)

On 28/01/2023 22:11, Patchwork wrote: *Patch Details* *Series:* GuC oriented print macros (rev3) *URL:* https://patchwork.freedesktop.org/series/113162/ *State:*success *Details:* https://intel-gfx-ci.01.org/tree/drm-tip/Patchw

[Intel-gfx] [PATCH i-g-t 8/8] gputop: Basic vendor agnostic GPU top tool

From: Tvrtko Ursulin Rudimentary vendor agnostic example of how lib_igt_drm_clients can be used to display a sorted by card and usage list of processes using GPUs. Borrows a bit of code from intel_gpu_top but for now omits the fancy features like interactive functionality, card selection

[Intel-gfx] [PATCH i-g-t 7/8] lib/igt_drm_clients: Enforce client status sort order in the library

From: Tvrtko Ursulin Some libdrmclient operations require that inactive clients are last in the list. Rather than relying on callers of the library sort routine to implement their comparison callbacks correctly, enforce this order directly in the library and let callers comparison callbacks

[Intel-gfx] [PATCH i-g-t 6/8] lib/igt_drm_clients: Decouple hardcoded engine assumptions

From: Tvrtko Ursulin Intel_gpu_top gets it's main engine configuration data via PMU probe and uses that for per client view as well. Furthemore code so far assumed only clients belonging from a single DRM card would be tracked in a single clients list. Break this inter-dependency by movin

[Intel-gfx] [PATCH i-g-t 5/8] lib/igt_drm_fdinfo: Track largest engine index

From: Tvrtko Ursulin Prep code for incoming work. Signed-off-by: Tvrtko Ursulin --- lib/igt_drm_fdinfo.c | 2 ++ lib/igt_drm_fdinfo.h | 1 + 2 files changed, 3 insertions(+) diff --git a/lib/igt_drm_fdinfo.c b/lib/igt_drm_fdinfo.c index 68c89ad2c17e..b850d2210ae7 100644 --- a/lib

[Intel-gfx] [PATCH i-g-t 4/8] lib/igt_drm_clients: Support multiple DRM cards

From: Tvrtko Ursulin Require DRM minor match during client lookup. Signed-off-by: Tvrtko Ursulin --- lib/igt_drm_clients.c | 14 -- 1 file changed, 8 insertions(+), 6 deletions(-) diff --git a/lib/igt_drm_clients.c b/lib/igt_drm_clients.c index c23a3fae9793..e11c8b18188f 100644

[Intel-gfx] [PATCH i-g-t 3/8] lib/igt_drm_clients: Record client drm minor

From: Tvrtko Ursulin Prepare for supporting clients belonging to multiple DRM cards by storing the DRM minor in the client record. Signed-off-by: Tvrtko Ursulin --- lib/igt_drm_clients.c | 22 ++ lib/igt_drm_clients.h | 1 + 2 files changed, 15 insertions(+), 8 deletions

[Intel-gfx] [PATCH i-g-t v3 0/8] Vendor agnostic gputop

From: Tvrtko Ursulin This is a pile of patches which implements a rudimentary vendor agnostic gputop tool based of the new DRM spec as documented in Documentation/gpu/drm-usage-stats.rst. First part of the series is code refactoring which should be reasonably stable. I've tested it all

[Intel-gfx] [PATCH i-g-t 1/8] lib: Extract igt_drm_clients from intel_gpu_top

From: Tvrtko Ursulin Extract some code into a new library to prepare for further work towards making a vendor agnostic gputop tool. Signed-off-by: Tvrtko Ursulin --- lib/igt_drm_clients.c | 432 ++ lib/igt_drm_clients.h | 85 +++ lib/meson.build

[Intel-gfx] [PATCH i-g-t 2/8] lib: Allow specifying custom engine map

From: Tvrtko Ursulin Instead of hard coding the engine names, allow a map of names to indices to either be passed in or it gets auto-detected (less efficient) while parsing. --- lib/igt_drm_clients.c | 18 +--- lib/igt_drm_clients.h | 3 ++- lib/igt_drm_fdinfo.c| 48

Re: [Intel-gfx] [PATCH v6] drm/i915/gt: Add selftests for TLB invalidation

xit (Tvrtko), - print sanitycheck params only on error (Tvrtko), - comment fixes (Tvrtko) Reviewed-by: Tvrtko Ursulin Regards, Tvrtko --- drivers/gpu/drm/i915/gt/intel_gpu_commands.h | 1 + drivers/gpu/drm/i915/gt/intel_gt.c| 4 + drivers/gpu/drm/i915

Re: [Intel-gfx] [PATCH v5] drm/i915/gt: Add selftests for TLB invalidation

On 30/01/2023 10:14, Andrzej Hajda wrote: From: Chris Wilson Check that we invalidate the TLB cache, the updated physical addresses are immediately visible to the HW, and there is no retention of the old physical address for concurrent HW access. Signed-off-by: Chris Wilson [ahajda: adjust

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 6/6] lib/igt_device_scan: Improve Intel discrete GPU selection

On 27/01/2023 16:17, Kamil Konieczny wrote: Hi Tvrtko, On 2023-01-27 at 11:12:41 +, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Now that DRM subsystem can contain PCI cards with the vendor set to Intel but they are not Intel GPUs, we need a better selection logic than looking at the

Re: [Intel-gfx] [igt-dev] [PATCH i-g-t 5/6] intel_gpu_top: Fix cleanup on old kernels / unsupported GPU

On 27/01/2023 16:10, Kamil Konieczny wrote: Hi Tvrtko, On 2023-01-27 at 11:12:40 +, Tvrtko Ursulin wrote: From: Tvrtko Ursulin Avoid trying to dereference null engines on exit when there are either none which are supported, or kernel does not have i915 PMU support. Also fix a memory

Re: [Intel-gfx] [PATCH] drm/i915: Fix potential bit_17 double-free

ere as a "BKL" (struct_mutex) aroung the call to i915_gem_object_set_tiling. Otherwise fix looks good: Reviewed-by: Tvrtko Ursulin I'll tweak the fixes tag and merge in a minute, thanks for the fix! Regards, Tvrtko Signed-off-by: Rob Clark --- drivers/gpu/drm/i915/gem/i915_

Re: [Intel-gfx] [RFC 10/12] cgroup/drm: Introduce weight based drm cgroup control

On 27/01/2023 14:11, Michal Koutný wrote: On Fri, Jan 27, 2023 at 01:31:54PM +, Tvrtko Ursulin wrote: I think you missed the finish_suspend_scanning() part: if (root_drmcs.suspended_period_us) cancel_delayed_work_sync(&root_drmcs.scan_work); So if scanning

<    4   5   6   7   8   9   10   11   12   13   >