On 21/02/2024 21:28, Rodrigo Vivi wrote:
On Wed, Feb 21, 2024 at 09:42:34AM +, Tvrtko Ursulin wrote:
On 21/02/2024 00:14, Vinay Belgaumkar wrote:
Allow user to provide a context hint. When this is set, KMD will
send a hint to GuC which results in special handling for this
context. SLPC
, Tvrtko Ursulin wrote:
On 16/02/2024 16:57, Daniel Vetter wrote:
On Wed, Feb 14, 2024 at 01:52:05PM +, Steven Price wrote:
Hi Adrián,
On 14/02/2024 12:14, Adrián Larumbe wrote:
A driver user expressed interest in being able to access engine usage stats
through fdinfo when debugfs is not built
From: Tvrtko Ursulin
To enable adding override of the default engine context image let us start
shadowing the per engine state in the context.
Signed-off-by: Tvrtko Ursulin
Cc: Lionel Landwerlin
Cc: Carlos Santa
Cc: Rodrigo Vivi
---
drivers/gpu/drm/i915/gt/intel_context_types.h | 2
From: Tvrtko Ursulin
When debugging GPU hangs Mesa developers are finding it useful to replay
the captured error state against the simulator. But due various simulator
limitations which prevent replicating all hangs, one step further is being
able to replay against a real GPU.
This is almost
From: Tvrtko Ursulin
Please see 2/2 for explanation and rationale.
v2:
* Extracted shadowing of default state into a leading patch.
Tvrtko Ursulin (2):
drm/i915: Shadow default engine context image in the context
drm/i915: Support replaying GPU hangs with captured context image
drivers
On 21/02/2024 12:08, Tvrtko Ursulin wrote:
On 21/02/2024 11:19, Andi Shyti wrote:
Hi Tvrtko,
On Wed, Feb 21, 2024 at 08:19:34AM +, Tvrtko Ursulin wrote:
On 21/02/2024 00:14, Andi Shyti wrote:
On Tue, Feb 20, 2024 at 02:48:31PM +, Tvrtko Ursulin wrote:
On 20/02/2024 14:35, Andi
On 21/02/2024 11:19, Andi Shyti wrote:
Hi Tvrtko,
On Wed, Feb 21, 2024 at 08:19:34AM +, Tvrtko Ursulin wrote:
On 21/02/2024 00:14, Andi Shyti wrote:
On Tue, Feb 20, 2024 at 02:48:31PM +, Tvrtko Ursulin wrote:
On 20/02/2024 14:35, Andi Shyti wrote:
Enable only one CCS engine
On 21/02/2024 00:14, Vinay Belgaumkar wrote:
Allow user to provide a context hint. When this is set, KMD will
send a hint to GuC which results in special handling for this
context. SLPC will ramp the GT frequency aggressively every time
it switches to this context. The down freq threshold will
On 20/02/2024 22:50, Rodrigo Vivi wrote:
On Tue, Feb 13, 2024 at 01:14:34PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
When debugging GPU hangs Mesa developers are finding it useful to replay
the captured error state against the simulator. But due various simulator
limitations which
On 21/02/2024 00:14, Andi Shyti wrote:
Hi Tvrtko,
On Tue, Feb 20, 2024 at 02:48:31PM +, Tvrtko Ursulin wrote:
On 20/02/2024 14:35, Andi Shyti wrote:
Enable only one CCS engine by default with all the compute sices
slices
Thanks!
diff --git a/drivers/gpu/drm/i915/gt
On 20/02/2024 14:35, Andi Shyti wrote:
Enable only one CCS engine by default with all the compute sices
slices
allocated to it.
While generating the list of UABI engines to be exposed to the
user, exclude any additional CCS engines beyond the first
instance.
This change can be tested
On 20/02/2024 14:20, Andi Shyti wrote:
Since CCS automatic load balancing is disabled, we will impose a
fixed balancing policy that involves setting all the CCS engines
to work together on the same load.
Erm *all* CSS engines work together..
Simultaneously, the user will see only 1 CCS
On 20/02/2024 10:36, Maxime Ripard wrote:
On Tue, Feb 20, 2024 at 09:16:43AM +, Tvrtko Ursulin wrote:
On 19/02/2024 20:02, Rodrigo Vivi wrote:
On Mon, Feb 19, 2024 at 01:14:23PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Request can be NULL if no guilty request was identified
On 20/02/2024 10:11, Andi Shyti wrote:
Hi Tvrtko,
On Mon, Feb 19, 2024 at 12:51:44PM +, Tvrtko Ursulin wrote:
On 19/02/2024 11:16, Tvrtko Ursulin wrote:
On 15/02/2024 13:59, Andi Shyti wrote:
...
+/*
+ * Exclude unavailable engines.
+ *
+ * Only the first CCS engine is utilized due
On 19/02/2024 20:02, Rodrigo Vivi wrote:
On Mon, Feb 19, 2024 at 01:14:23PM +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Request can be NULL if no guilty request was identified so simply use
engine->i915 instead.
Signed-off-by: Tvrtko Ursulin
Fixes: d50892a9554c ("drm/i915
From: Tvrtko Ursulin
Tooling appears very strict so lets pacify it by adding some comments,
even if fields are completely self-explanatory.
Signed-off-by: Tvrtko Ursulin
Fixes: b11236486749 ("drm/i915: Add GuC submission interface version query")
Reported-by: Stephen Rothwell
Cc:
From: Tvrtko Ursulin
Request can be NULL if no guilty request was identified so simply use
engine->i915 instead.
Signed-off-by: Tvrtko Ursulin
Fixes: d50892a9554c ("drm/i915: switch from drm_debug_printer() to device
specific drm_dbg_printer()")
Reported-by: Dan Carpenter
Cc: Ja
On 19/02/2024 11:16, Tvrtko Ursulin wrote:
On 15/02/2024 13:59, Andi Shyti wrote:
Since CCS automatic load balancing is disabled, we will impose a
fixed balancing policy that involves setting all the CCS engines
to work together on the same load.
Simultaneously, the user will see only 1 CCS
On 15/02/2024 13:59, Andi Shyti wrote:
Since CCS automatic load balancing is disabled, we will impose a
fixed balancing policy that involves setting all the CCS engines
to work together on the same load.
Simultaneously, the user will see only 1 CCS rather than the
actual number. As of now,
On 16/02/2024 16:57, Daniel Vetter wrote:
On Wed, Feb 14, 2024 at 01:52:05PM +, Steven Price wrote:
Hi Adrián,
On 14/02/2024 12:14, Adrián Larumbe wrote:
A driver user expressed interest in being able to access engine usage stats
through fdinfo when debugfs is not built into their
submission version query which Mesa
wants for implementing Vulkan async compute queues.
Regards,
Tvrtko
drm-intel-gt-next-2024-02-15:
UAPI Changes:
- Add GuC submission interface version query (Tvrtko Ursulin)
Driver Changes:
Fixes/improvements/new stuff:
- Atomically invalidate userptr on mmu
From: Tvrtko Ursulin
When debugging GPU hangs Mesa developers are finding it useful to replay
the captured error state against the simulator. But due various simulator
limitations which prevent replicating all hangs, one step further is being
able to replay against a real GPU.
This is almost
On 08/02/2024 18:13, Erick Archer wrote:
The "struct i915_syncmap" uses a dynamically sized set of trailing
elements. It can use an "u32" array or a "struct i915_syncmap *"
array.
So, use the preferred way in the kernel declaring flexible arrays [1].
Because there are two possibilities for
On 08/02/2024 17:55, Souza, Jose wrote:
On Thu, 2024-02-08 at 07:19 -0800, José Roberto de Souza wrote:
On Thu, 2024-02-08 at 14:59 +, Tvrtko Ursulin wrote:
On 08/02/2024 14:30, Souza, Jose wrote:
On Thu, 2024-02-08 at 08:25 +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Add a new
On 08/02/2024 14:30, Souza, Jose wrote:
On Thu, 2024-02-08 at 08:25 +, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Add a new query to the GuC submission interface version.
Mesa intends to use this information to check for old firmware versions
with a known bug where using the render
On 07/02/2024 19:34, John Harrison wrote:
On 2/7/2024 10:49, Tvrtko Ursulin wrote:
On 07/02/2024 18:12, John Harrison wrote:
On 2/7/2024 03:56, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Add a new query to the GuC submission interface version.
Mesa intends to use this information
From: Tvrtko Ursulin
Add a new query to the GuC submission interface version.
Mesa intends to use this information to check for old firmware versions
with a known bug where using the render and compute command streamers
simultaneously can cause GPU hangs due issues in firmware scheduling
On 07/02/2024 18:12, John Harrison wrote:
On 2/7/2024 03:56, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Add a new query to the GuC submission interface version.
Mesa intends to use this information to check for old firmware versions
with a known bug where using the render and compute
From: Tvrtko Ursulin
Add a new query to the GuC submission interface version.
Mesa intends to use this information to check for old firmware versions
with a known bug where using the render and compute command streamers
simultaneously can cause GPU hangs due issues in firmware scheduling
Hi,
On 06/02/2024 16:45, Nikita Zhandarovich wrote:
After falling through the switch statement to default case 'repr' is
initialized with NULL, which will lead to incorrect dereference of
'!repr[n]' in the following loop.
Fix it with the help of an additional check for NULL.
Found by Linux
s[id].shared += sz;
else
stats[id].private += sz;
Reviewed-by: Tvrtko Ursulin
Good that you remembered this story, I completely forgot!
Regards,
Tvrtko
ts(obj)) {
status.shared += obj->size;
} else {
status.private += obj->size;
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
G_LOCKDEP
/**
Not sure what the local view on static inlines, but fine nevertheless.
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
-total-: [KiB|MiB]
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
On 09/01/2024 14:57, Christian König wrote:
Am 09.01.24 um 15:26 schrieb Daniel Vetter:
On Tue, 9 Jan 2024 at 14:25, Tvrtko Ursulin
wrote:
On 09/01/2024 12:54, Daniel Vetter wrote:
On Tue, Jan 09, 2024 at 09:30:15AM +, Tvrtko Ursulin wrote:
On 09/01/2024 07:56, Christian König wrote
On 09/01/2024 12:54, Daniel Vetter wrote:
On Tue, Jan 09, 2024 at 09:30:15AM +, Tvrtko Ursulin wrote:
On 09/01/2024 07:56, Christian König wrote:
Am 07.12.23 um 19:02 schrieb Alex Deucher:
Add shared stats. Useful for seeing shared memory.
v2: take dma-buf into account as well
On 09/01/2024 07:56, Christian König wrote:
Am 07.12.23 um 19:02 schrieb Alex Deucher:
Add shared stats. Useful for seeing shared memory.
v2: take dma-buf into account as well
Signed-off-by: Alex Deucher
Cc: Rob Clark
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c | 4
On 08/01/2024 15:13, Joonas Lahtinen wrote:
Quoting Tvrtko Ursulin (2024-01-05 12:39:31)
On 04/01/2024 21:23, Andi Shyti wrote:
+void intel_gt_apply_ccs_mode(struct intel_gt *gt)
+{
+ mutex_lock(>ccs.mutex);
+ __intel_gt_apply_ccs_mode(gt);
+ mutex_unlock(>ccs.mutex);
+}
+
On 04/01/2024 21:23, Andi Shyti wrote:
Hi Tvrtko,
[1]
+ /*
+* Loop over all available slices and assign each a user engine.
+*
+* With 1 engine (ccs0):
+* slice 0, 1, 2, 3: ccs0
+*
+* With 2 engines (ccs0, ccs1):
+* slice 0,
On 04/01/2024 14:35, Andi Shyti wrote:
The CCS mode involves assigning CCS engines to slices depending
on the number of slices and the number of engines the user wishes
to set.
In this patch, the default CCS setting is established during the
initial GT settings. It involves assigning only one
On 13/12/2023 14:13, Christian König wrote:
Am 13.12.23 um 12:46 schrieb Tvrtko Ursulin:
Hi,
On 12/12/2023 14:10, Christian König wrote:
Hi Tvrtko,
Thanks for pointing this mail out once more, I've totally missed it.
That's okay, if it was really urgent I would have re-raised the thread
On 14/12/2023 15:04, Zhao Liu wrote:
On Thu, Dec 14, 2023 at 02:35:26PM +, Tvrtko Ursulin wrote:
Date: Thu, 14 Dec 2023 14:35:26 +
From: Tvrtko Ursulin
Subject: Re: [PATCH v3 0/9] drm/i915: Replace kmap_atomic() with
kmap_local_page()
On 14/12/2023 13:45, Tvrtko Ursulin wrote
On 14/12/2023 13:45, Tvrtko Ursulin wrote:
Hi Zhao,
On 14/12/2023 13:19, Zhao Liu wrote:
Hi maintainers,
Just kindly ping.
May I ask if this refresh version could be merged into the next tree of
the i915?
I certainly spotted your series last week or so but then it slipped my
mind to go
Hi Zhao,
On 14/12/2023 13:19, Zhao Liu wrote:
Hi maintainers,
Just kindly ping.
May I ask if this refresh version could be merged into the next tree of
the i915?
I certainly spotted your series last week or so but then it slipped my
mind to go through it. Should be able to go through it
and no known real use cases affected.
Am 12.12.23 um 11:37 schrieb Tvrtko Ursulin:
On 25/09/2023 14:16, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Allow mmap forwarding for imported buffers in order to allow minigbm
mmap
to work on aperture-less platforms such as Meteorlake.
So far i915 did
ndy Dunlap
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Tvrtko Ursulin
Cc: intel-...@lists.freedesktop.org
---
include/uapi/drm/i915_drm.h | 12 ++--
1 file changed, 6 insertions(+), 6 deletions(-)
diff -- a/include/uapi/drm/i915_drm.h b/include/uapi/drm/i915_drm.h
--
On 25/09/2023 14:16, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Allow mmap forwarding for imported buffers in order to allow minigbm mmap
to work on aperture-less platforms such as Meteorlake.
So far i915 did not allow mmap on imported buffers but from minigbm
perspective that worked
On 07/12/2023 11:46, Andi Shyti wrote:
On Thu, Dec 07, 2023 at 11:43:28AM +, Tvrtko Ursulin wrote:
On 07/12/2023 11:26, Andi Shyti wrote:
Hi Tvrtko,
Engine->id namespace is per-tile so struct igt_live_test->reset_engine[]
needs to be two-dimensional so engine reset counts fr
counts would be incorrect for same engine instance on
different tiles.
Signed-off-by: Tvrtko Ursulin
Fixes: 0c29efa23f5c ("drm/i915/selftests: Consider multi-gt instead of to_gt()")
Reported-by: Alan Previn Teres Alexis
Cc: Tejas Upadhyay
Cc: Andi Shyti
Cc: Daniele Ceraolo Spurio
On 06/12/2023 00:52, Daniele Ceraolo Spurio wrote:
On 12/1/2023 4:21 AM, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Commit 503579448db9 ("drm/i915/gsc: Mark internal GSC engine with
reserved uabi class")
made the GSC0 engine not have a valid uabi class and so broke the en
D
to TGID.
Oops, yes..
Reviewed-by: Tvrtko Ursulin
Will you apply it to the AMD tree for fixes if it looks OK
or does it go elsewhere?
I can push this to drm-misc-fixes as long as nobody objects in the next
hour or so.
CC: stable? If yes which versions?
Cc: # v6.4+
Regards,
Tvrtko
On 05/12/2023 10:44, Nirmoy Das wrote:
Hi Tvrtko,
On 12/5/2023 11:05 AM, Tvrtko Ursulin wrote:
On 05/12/2023 08:50, Nirmoy Das wrote:
Hi Tvrtko,
On 12/5/2023 9:34 AM, Tvrtko Ursulin wrote:
On 01/12/2023 15:44, Nirmoy Das wrote:
gen8_engine_reset_prepare() can fail when HW fails to set
On 05/12/2023 08:50, Nirmoy Das wrote:
Hi Tvrtko,
On 12/5/2023 9:34 AM, Tvrtko Ursulin wrote:
On 01/12/2023 15:44, Nirmoy Das wrote:
gen8_engine_reset_prepare() can fail when HW fails to set
RESET_CTL_READY_TO_RESET bit. In some cases this is not fatal
error as driver will retry.
Let
or not.
No complaints per se but I don't see the caller deciding and it is not
really reducing log level but converting to trace. So commit message and
patch do not align for me which I think should be improved.
Regards,
Tvrtko
Cc: Tvrtko Ursulin
Cc: John Harrison
Cc: Andi Shyti
Cc
From: Tvrtko Ursulin
Commit 503579448db9 ("drm/i915/gsc: Mark internal GSC engine with reserved uabi
class")
made the GSC0 engine not have a valid uabi class and so broke the engine
reset counting, which in turn was made class based in cb823ed9915b
("drm/i915/gt: Use intel_gt
From: Tvrtko Ursulin
Engine->id namespace is per-tile so struct igt_live_test->reset_engine[]
needs to be two-dimensional so engine reset counts from all tiles can be
stored with no aliasing. With aliasing, if we had a real multi-tile
platform, the reset counts would be incorrect for same
On 22/11/2023 19:15, Alan Previn wrote:
Debugging PXP issues can't even begin without understanding precedding
sequence of important events. Add drm_dbg into the most important PXP
events.
v5 : - rebase.
v4 : - rebase.
v3 : - move gt_dbg to after mutex block in function
On 15/11/2023 20:42, Michal Wajdeczko wrote:
On 15.11.2023 11:00, Tvrtko Ursulin wrote:
On 14/11/2023 16:55, Michal Wajdeczko wrote:
On 14.11.2023 13:37, Tvrtko Ursulin wrote:
On 10/11/2023 18:22, Michal Wajdeczko wrote:
The Single Root I/O Virtualization (SR-IOV) extension to the PCI
On 14/11/2023 19:48, Teres Alexis, Alan Previn wrote:
On Tue, 2023-11-14 at 17:52 +, Tvrtko Ursulin wrote:
On 14/11/2023 17:37, Teres Alexis, Alan Previn wrote:
On Tue, 2023-11-14 at 17:27 +, Tvrtko Ursulin wrote:
On 13/11/2023 17:57, Teres Alexis, Alan Previn wrote:
On Wed, 2023
From: Tvrtko Ursulin
The GSC CS is not exposed to the user, so we skipped assigning a uabi
class number for it. However, the trace logs use the uabi class and
instance to identify the engine, so leaving uabi class unset makes the
GSC CS show up as the RCS in those logs.
Given that the engine
From: Tvrtko Ursulin
The GSC CS is not exposed to the user, so we skipped assigning a uabi
class number for it. However, the trace logs use the uabi class and
instance to identify the engine, so leaving uabi class unset makes the
GSC CS show up as the RCS in those logs.
Given that the engine
On 14/11/2023 16:55, Michal Wajdeczko wrote:
On 14.11.2023 13:37, Tvrtko Ursulin wrote:
On 10/11/2023 18:22, Michal Wajdeczko wrote:
The Single Root I/O Virtualization (SR-IOV) extension to the PCI
Express (PCIe) specification suite is supported starting from 12th
generation of Intel
On 14/11/2023 17:37, Teres Alexis, Alan Previn wrote:
On Tue, 2023-11-14 at 17:27 +, Tvrtko Ursulin wrote:
On 13/11/2023 17:57, Teres Alexis, Alan Previn wrote:
On Wed, 2023-10-25 at 13:58 +0100, Tvrtko Ursulin wrote:
On 04/10/2023 18:59, Teres Alexis, Alan Previn wrote:
On Thu, 2023
On 13/11/2023 17:57, Teres Alexis, Alan Previn wrote:
On Wed, 2023-10-25 at 13:58 +0100, Tvrtko Ursulin wrote:
On 04/10/2023 18:59, Teres Alexis, Alan Previn wrote:
On Thu, 2023-09-28 at 13:46 +0100, Tvrtko Ursulin wrote:
On 27/09/2023 17:36, Teres Alexis, Alan Previn wrote:
alan:snip
to the new Xe driver and to propose related additions to the sysfs.
Signed-off-by: Michal Wajdeczko
Cc: Oded Gabbay
Cc: Rodrigo Vivi
Cc: Joonas Lahtinen
Cc: Tvrtko Ursulin
Cc: Daniel Vetter
---
Documentation/gpu/rfc/index.rst | 5 +
Documentation/gpu/rfc/sysfs-driver-xe-sriov | 501
From: Tvrtko Ursulin
__rcu annotation is needed to avoid the sparse warnings such as:
.../i915_drm_client.c:92:9: sparse: sparse: incompatible types in comparison
expression (different address spaces):
.../i915_drm_client.c:92:9: sparse:struct list_head [noderef] __rcu
From: Tvrtko Ursulin
There is no need to return anything in the version which was merged and
also the implementation of the !CONFIG_PROC_FS wasn't returning anything,
causing a build failure there.
Signed-off-by: Tvrtko Ursulin
Fixes: e4ae85e364fc ("drm/i915: Add ability for tracking b
On 10/11/2023 10:58, Dipam Turkar wrote:
Making i915 use drm_gem_create_mmap_offset() instead of its custom
implementations for associating GEM object with a fake offset.
Does it compile?
Regards,
Tvrtko
Signed-off-by: Dipam Turkar
---
drivers/gpu/drm/i915/gem/i915_gem_mman.c | 192
On 04/11/2023 00:25, Luben Tuikov wrote:
Hi Tvrtko,
On 2023-11-03 06:39, Tvrtko Ursulin wrote:
On 02/11/2023 22:46, Luben Tuikov wrote:
Eliminate drm_sched_run_job_queue_if_ready() and instead just call
drm_sched_run_job_queue() in drm_sched_free_job_work(). The problem is that
the former
On 05/11/2023 01:51, Luben Tuikov wrote:
On 2023-11-02 06:55, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
I found some of the naming a bit incosistent and unclear so just a small
attempt to clarify and tidy some of them. See what people think if my first
stab improves things or not.
Cc
quot;drm/i915/gem: Use the proto-context to handle create
parameters (v5)")
Cc: # v5.15+
Signed-off-by: Kunwu Chan
Suggested-by: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
Link: https://lore.kernel.org/all/20231102101642.52988-1-chen...@kylinos.cn
---
drivers/gpu/drm/i915/gem/i915_gem_
On 02/11/2023 22:46, Luben Tuikov wrote:
Eliminate drm_sched_run_job_queue_if_ready() and instead just call
drm_sched_run_job_queue() in drm_sched_free_job_work(). The problem is that
the former function uses drm_sched_select_entity() to determine if the
scheduler had an entity ready in one of
he proto-context to handle create
parameters (v5)")
Cc: # v5.15+
Signed-off-by: Kunwu Chan
Suggested-by: Tvrtko Ursulin
Reviewed-by: Tvrtko Ursulin
Where did you receive this tag? There is nothing under link below.
Link: https://lore.kernel.org/all/20231102101642.52988-1-chen.
On 02/11/2023 10:16, chentao wrote:
Fix smatch warning:
drivers/gpu/drm/i915/gem/i915_gem_context.c:847 set_proto_ctx_sseu()
warn: potential spectre issue 'pc->user_engines' [r] (local cap)
Signed-off-by: chentao
I don't know if this is actually exploitable given the time deltas between
On 31/10/2023 03:24, Matthew Brost wrote:
Rather than call free_job and run_job in same work item have a dedicated
work item for each. This aligns with the design and intended use of work
queues.
v2:
- Test for DMA_FENCE_FLAG_TIMESTAMP_BIT before setting
timestamp in free_job() work
From: Tvrtko Ursulin
Because a) helper is exported to other parts of the scheduler and
b) there isn't a plain drm_sched_wakeup to begin with, I think we can
drop the suffix and by doing so separate the intimiate knowledge
between the scheduler components a bit better.
Signed-off-by: Tvrtko
From: Tvrtko Ursulin
"If ready" is not immediately clear what it means - is the scheduler
ready or something else? Drop the suffix, clarify kerneldoc, and employ
the same naming scheme as in drm_sched_run_free_queue:
- drm_sched_run_job_queue - enqueues if there is something
From: Tvrtko Ursulin
Whether or not there are more jobs to clean up does not depend on the
existance of the current job, given both drm_sched_get_finished_job and
drm_sched_free_job_queue_if_done take and drop the job list lock.
Therefore it is confusing to make it read like
From: Tvrtko Ursulin
"Get cleanup job" makes it sound like helper is returning a job which will
execute some cleanup, or something, while the kerneldoc itself accurately
says "fetch the next _finished_ job". So lets rename the helper to be self
documenting.
Signed-off-by
From: Tvrtko Ursulin
The current name makes it sound like helper will free a queue, while what
it does is it enqueues the free job worker.
Rename it to drm_sched_run_free_queue to align with existing
drm_sched_run_job_queue.
Despite that creating an illusion there are two queues, while
From: Tvrtko Ursulin
I found some of the naming a bit incosistent and unclear so just a small
attempt to clarify and tidy some of them. See what people think if my first
stab improves things or not.
Cc: Luben Tuikov
Cc: Matthew Brost
Tvrtko Ursulin (5):
drm/sched: Rename
On 26/10/2023 15:43, Tvrtko Ursulin wrote:
On 28/09/2023 13:47, Tvrtko Ursulin wrote:
On 27/09/2023 14:48, Steven Price wrote:
On 27/09/2023 14:38, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
It is better not to lose precision and not revert to 1 MiB size
granularity for every size
On 02/11/2023 09:24, Jani Nikula wrote:
On Wed, 01 Nov 2023, Tvrtko Ursulin wrote:
On 01/11/2023 10:06, Jani Nikula wrote:
On Wed, 01 Nov 2023, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Unused macro after 99919be74aa3 ("drm/i915/gem: Zap the i915_gem_object_blt
code")
re
From: Tvrtko Ursulin
Iterators operate on struct intel_gt so lets move it to intel_gt.h in
order to make i915_drv.h less of a dumping ground for stuff.
Signed-off-by: Tvrtko Ursulin
Suggested-by: Jani Nikula
---
drivers/gpu/drm/i915/gt/intel_engine_pm.h | 1 +
drivers/gpu/drm/i915
From: Tvrtko Ursulin
Unused macro after 99919be74aa3 ("drm/i915/gem: Zap the i915_gem_object_blt
code")
removed some code.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Jani Nikula
---
drivers/gpu/drm/i915/i915_drv.h | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gp
On 01/11/2023 10:06, Jani Nikula wrote:
On Wed, 01 Nov 2023, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Unused macro after 99919be74aa3 ("drm/i915/gem: Zap the i915_gem_object_blt
code")
removed some code.
Signed-off-by: Tvrtko Ursulin
\o/
Reviewed-by: Jani Nikula
Could
From: Tvrtko Ursulin
Unused macro after 99919be74aa3 ("drm/i915/gem: Zap the i915_gem_object_blt
code")
removed some code.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_drv.h | 5 -
1 file changed, 5 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/d
From: Tvrtko Ursulin
XeHP SDV was a pre-production hardware used to bring up PVC and was not
generally available and has since been decided will be supported in the
new xe driver and not i915.
v2:
* Correct historical fact SDV was for PVC, not ATS. (John)
Signed-off-by: Tvrtko Ursulin
Cc
From: Tvrtko Ursulin
PVC support will not be coming to i915 so get rid of its partial
enablement and reduce the driver maintenance burden.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Andi Shyti
Reviewed-by: Andrzej Hajda
---
.../gpu/drm/i915/gem/i915_gem_object_types.h | 2 +-
drivers/gpu
On 27/10/2023 18:38, Tvrtko Ursulin wrote:
On 27/10/2023 18:28, Harshit Mogalapalli wrote:
When i915 perf interface is not available dereferencing it will lead to
NULL dereferences.
As returning -ENOTSUPP is pretty clear return when perf interface is not
available.
Fixes: 2fec539112e8
river specific drm_dbg
call")
Suggested-by: Tvrtko Ursulin
Signed-off-by: Harshit Mogalapalli
---
v1 --> v2: Remove the debug calls as they don't add much value and
-ENOTSUPP is a good enough return value.
---
drivers/gpu/drm/i915/i915_perf.c | 15 +++
1 file changed, 3 inse
On 27/10/2023 15:11, Andrzej Hajda wrote:
On 27.10.2023 16:07, Harshit Mogalapalli wrote:
When i915 perf interface is not available dereferencing it will lead to
NULL dereferences.
Fix this by using DRM_DEBUG() which the scenario before the commit in
the Fixes tag.
Fixes: 2fec539112e8
On 28/09/2023 13:47, Tvrtko Ursulin wrote:
On 27/09/2023 14:48, Steven Price wrote:
On 27/09/2023 14:38, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
It is better not to lose precision and not revert to 1 MiB size
granularity for every size greater than 1 MiB.
Sizes in KiB should not be so
On 04/10/2023 18:59, Teres Alexis, Alan Previn wrote:
On Thu, 2023-09-28 at 13:46 +0100, Tvrtko Ursulin wrote:
On 27/09/2023 17:36, Teres Alexis, Alan Previn wrote:
Thanks for taking the time to review this Tvrtko, replies inline below.
alan:snip
Main concern is that we need to be sure
From: Tvrtko Ursulin
When notified by the drm core we are over our allotted time budget, i915
instance will check if any of the GPU engines it is reponsible for is
fully saturated. If it is, and the client in question is using that
engine, it will throttle it.
For now throttling is done
From: Tvrtko Ursulin
To support container use cases where external orchestrators want to make
deployment and migration decisions based on GPU load and capacity, we can
expose the GPU load as seen by the controller in a new drm.active_us
field. This field contains a monotonic cumulative time
From: Tvrtko Ursulin
To reduce the number of tracking going on, especially with drivers which
will not support any sort of control from the drm cgroup controller side,
lets express the funcionality as opt-in and use the presence of
drm_cgroup_ops as activation criteria.
Signed-off-by: Tvrtko
From: Tvrtko Ursulin
Similar to CPU scheduling, implement a concept of weight in the drm cgroup
controller.
Uses the same range and default as the CPU controller - CGROUP_WEIGHT_MIN,
CGROUP_WEIGHT_DFL and CGROUP_WEIGHT_MAX.
Later each cgroup is assigned a time budget proportionaly based
From: Tvrtko Ursulin
Add a new callback via which the drm cgroup controller is notifying the
drm core that a certain process is above its allotted GPU time.
Signed-off-by: Tvrtko Ursulin
---
include/drm/drm_drv.h | 8
kernel/cgroup/drm.c | 16
2 files changed, 24
From: Tvrtko Ursulin
Add a driver callback and core helper which allow querying the time spent
on GPUs for processes belonging to a group.
Signed-off-by: Tvrtko Ursulin
---
include/drm/drm_drv.h | 28
kernel/cgroup/drm.c | 20
2 files
101 - 200 of 2130 matches
Mail list logo
