/**
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
drivers/gp
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(>-&
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, 2
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
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 to
ing 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 i9
tical.
Signed-off-by: Randy 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/inclu
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
itching from PID
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 the
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 Shyt
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
i915_gsc
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 is
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 is
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
It
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 track
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
c7600f7 ("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
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
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
Where did you receive this tag? There is nothing under link below.
Link: https://lore.kernel.org/all/20231102101642.52988-1-che
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 the
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: T
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 there is a
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 in
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
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 ("i915
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 on the
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
From: Tvrtko Ursulin
To enable propagation of settings from the cgroup DRM controller to DRM
and vice-versa, we need to start tracking to which cgroups DRM clients
belong.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/drm_file.c | 6
include/drm/drm_file.h | 6
include
From: Tvrtko Ursulin
This series contains a proposal for a DRM cgroup controller which implements a
weight based hierarchical GPU usage budget approach and is similar in concept to
some of the existing controllers like CPU and IO.
Motivation mostly comes from my earlier proposal where I
From: Tvrtko Ursulin
Skeleton controller without any functionality.
Signed-off-by: Tvrtko Ursulin
---
include/linux/cgroup_drm.h| 9 ++
include/linux/cgroup_subsys.h | 4 +++
init/Kconfig | 7
kernel/cgroup/Makefile| 1 +
kernel/cgroup/drm.c
Hi Dave, Daniel,
Here is the final pull request for 6.7.
As indicated that it may happen in the last pull, the remaining
missing functionality for Meteorlake, enabling the GuC based TLB
invalidation, has since been merged and platform thought to be ready for
lifting out of force probe status.
Al
.
Regards,
Tvrtko
Regards,
Zhao
On Mon, Apr 17, 2023 at 10:53:28AM -0400, Rodrigo Vivi wrote:
Date: Mon, 17 Apr 2023 10:53:28 -0400
From: Rodrigo Vivi
Subject: Re: [PATCH v2 9/9] drm/i915: Use kmap_local_page() in
gem/i915_gem_execbuffer.c
On Mon, Apr 17, 2023 at 12:24:45PM +0100, Tvrtko Ursulin
On 13/10/2023 21:51, Rodrigo Vivi wrote:
On Thu, Sep 28, 2023 at 01:48:34PM +0100, Tvrtko Ursulin wrote:
On 27/09/2023 20:34, Belgaumkar, Vinay wrote:
On 9/21/2023 3:41 AM, Tvrtko Ursulin wrote:
On 20/09/2023 22:56, Vinay Belgaumkar wrote:
Provide a bit to disable waitboost while
Hi Dave, Daniel,
Here is the second pull request for 6.7.
I say second and not final because there is a very small chance we might
be doing another one next week, to bring Meteorlake out of force probe
status, which was quite close this week but apparently not quite there.
At the moment it looks
On 21/09/2023 19:20, john.c.harri...@intel.com wrote:
From: John Harrison
If an active context has been banned (e.g. Ctrl+C killed) then it is
likely to be reset as part of evicting it from the hardware. That
results in a 'ignoring context reset notification: banned = 1'
message at info level
-off-by: Janusz Krzysztofik
Signed-off-by: Jonathan Cavitt
Signed-off-by: Nirmoy Das
Signed-off-by: Radhakrishna Sripada
Signed-off-by: Andi Shyti
Cc: Jani Nikula
Cc: Joonas Lahtinen
Cc: Rodrigo Vivi
Cc: Tvrtko Ursulin
---
Hello,
This patch eliminates the 'force probe' for the MTL p
On 07/10/2023 00:43, Matthew Brost wrote:
On Fri, Oct 06, 2023 at 03:14:04PM +, Matthew Brost wrote:
On Fri, Oct 06, 2023 at 08:59:15AM +0100, Tvrtko Ursulin wrote:
On 05/10/2023 05:13, Luben Tuikov wrote:
On 2023-10-04 23:33, Matthew Brost wrote:
On Tue, Sep 26, 2023 at 11:32:10PM
On 06/10/2023 11:46, Ville Syrjälä wrote:
On Fri, Oct 06, 2023 at 09:31:01AM +0100, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
It is not our policy to keep pre-production hardware support for this long
so I guess this one was just forgotten.
This is about detecting pre-prod hw, not
From: Tvrtko Ursulin
XeHP SDV was a pre-production hardware used to bring up ATS and was not
generally available. Since latter was since explicitly added, there is no
need to keep the code for the former around.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/gt/intel_gsc.c
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
---
.../gpu/drm/i915/gem/i915_gem_object_types.h | 2 +-
drivers/gpu/drm/i915/gt/gen8_engine_cs.c | 3 -
drivers
From: Tvrtko Ursulin
It is not our policy to keep pre-production hardware support for this long
so I guess this one was just forgotten.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/i915/i915_driver.c | 1 -
drivers/gpu/drm/i915/i915_drv.h| 2 --
2 files changed, 3 deletions(-)
diff
From: Tvrtko Ursulin
A little bit of house keeping, trimming off some pre-production hardware and
incomplete platform support.
Tvrtko Ursulin (3):
drm/i915: Remove early/pre-production Haswell code
drm/i915: Remove incomplete PVC plumbing
drm/i915: Remove xehpsdv support
.../gpu/drm
On 05/10/2023 05:13, Luben Tuikov wrote:
On 2023-10-04 23:33, Matthew Brost wrote:
On Tue, Sep 26, 2023 at 11:32:10PM -0400, Luben Tuikov wrote:
Hi,
On 2023-09-19 01:01, Matthew Brost wrote:
In XE, the new Intel GPU driver, a choice has made to have a 1 to 1
mapping between a drm_gpu_schedu
On 04/10/2023 10:43, Andi Shyti wrote:
The MCR steering semaphore is a shared lock entry between i915
and various firmware components.
Getting the lock might sinchronize on some shared resources.
Sometimes though, it might happen that the firmware forgets to
unlock causing unnecessary noise in
e_requests/25233
v2:
- incorporated feedback from Tvrtko Ursulin:
- updated patch description to clarify the use case that identified
this issue.
- updated query_uc_fw_version() to use copy_query_item() helper.
- updated the implemented GuC version query to return Submission
On 27/09/2023 20:34, Belgaumkar, Vinay wrote:
On 9/21/2023 3:41 AM, Tvrtko Ursulin wrote:
On 20/09/2023 22:56, Vinay Belgaumkar wrote:
Provide a bit to disable waitboost while waiting on a gem object.
Waitboost results in increased power consumption by requesting RP0
while waiting for the
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 troublesome to read (and in fact machine
On 27/09/2023 17:36, Teres Alexis, Alan Previn wrote:
Thanks for taking the time to review this Tvrtko, replies inline below.
On Wed, 2023-09-27 at 10:02 +0100, Tvrtko Ursulin wrote:
On 26/09/2023 20:05, Alan Previn wrote:
When suspending, add a timeout when calling
round checks, make others IP version based
[mtl] (Matt Roper)
- Replace Meteorlake subplatforms with IP version checks (Matt Roper)
- Adding DeviceID for Arrowlake-S under MTL [mtl] (Nemesa Garg)
- Run relevant bits of debugfs drop_caches per GT (Tvrtko Ursulin)
Miscellaneous:
- Remove Wa_150105
From: Tvrtko Ursulin
Simplify the implementation of perf/OA queries by re-ogranizing the way
querying of the OA config list is done, how temporary storage is used,
and also replace the multi-step manual retrieving of user data with the
existing copy_query_item helper.
Note that this could be
On 22/09/2023 11:58, Adrián Larumbe wrote:
On 20.09.2023 16:53, Tvrtko Ursulin wrote:
On 20/09/2023 00:34, Adrián Larumbe wrote:
Some BO's might be mapped onto physical memory chunkwise and on demand,
like Panfrost's tiler heap. In this case, even though the
drm_gem_shmem_object
From: Tvrtko Ursulin
To enable accounting of indirect client memory usage (such as page tables)
in the following patch, lets start recording the creator of each PPGTT.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Aravind Iddamsetty
---
drivers/gpu/drm/i915/gem/i915_gem_context.c | 11
From: Tvrtko Ursulin
Account ring buffers and logical context space against the owning client
memory usage stats.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Aravind Iddamsetty
---
drivers/gpu/drm/i915/gt/intel_context.c | 14 ++
drivers/gpu/drm/i915/i915_drm_client.c | 10
From: Tvrtko Ursulin
Use the newly added drm_print_memory_stats helper to show memory
utilisation of our objects in drm/driver specific fdinfo output.
To collect the stats we walk the per memory regions object lists
and accumulate object size into the respective drm_memory_stats
categories.
v2
From: Tvrtko Ursulin
At the moment memory region names are a bit too varied and too
inconsistent to be used for ABI purposes, like for upcoming fdinfo
memory stats.
System memory can be either system or system-ttm. Local memory has the
instance number appended, others do not. Not only
From: Tvrtko Ursulin
Account page table backing store against the owning client memory usage
stats.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Aravind Iddamsetty
---
drivers/gpu/drm/i915/gt/intel_gtt.c | 6 ++
1 file changed, 6 insertions(+)
diff --git a/drivers/gpu/drm/i915/gt
From: Tvrtko Ursulin
In order to show per client memory usage lets add some infrastructure
which enables tracking buffer objects owned by clients.
We add a per client list protected by a new per client lock and to support
delayed destruction (post client exit) we make tracked objects hold
From: Tvrtko Ursulin
A short series to enable fdinfo memory stats for i915.
I added tracking of most classes of objects (user objects, page tables, context
state, ring buffers) which contribute to client's memory footprint and am
accouting their memory use along the similar lines as in
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 troublesome to read (and in fact machine
parsing is I expect the norm here), they align with other api like
/proc/meminfo, and they
301 - 400 of 2069 matches
Mail list logo
