On 22/07/2024 22:06, Lucas De Marchi wrote:
Instead of calling perf_pmu_unregister() when unbinding, defer that to
the destruction of i915 object. Since perf itself holds a reference in
the event, this only happens when all events are gone, which guarantees
i915 is not unregistering the pmu wit
On 22/07/2024 22:06, Lucas De Marchi wrote:
There's no need to free the resources during unbind. Since perf events
may still access them due to open events, it's safer to free them when
dropping the last i915 reference.
Signed-off-by: Lucas De Marchi
---
drivers/gpu/drm/i915/i915_pmu.c | 21
ommit 05488673a4d41383f9dd537f298e525e6b00fb93
Author: Tvrtko Ursulin
AuthorDate: Wed Oct 16 10:38:02 2019 +0100
Commit: Tvrtko Ursulin
CommitDate: Thu Oct 17 10:50:47 2019 +0100
drm/i915/pmu: Support multiple GPUs
Added IS_DGFX:
commit dc90fe3fd219c7693617ba09a9467e4aadc2e039
Author: José Roberto de
On 22/07/2024 15:06, Christian König wrote:
Am 22.07.24 um 15:52 schrieb Tvrtko Ursulin:
On 19/07/2024 16:18, Christian König wrote:
Am 19.07.24 um 15:02 schrieb Christian König:
Am 19.07.24 um 11:47 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
Long time ago in commit b3ac17667f11 (&quo
On 19/07/2024 16:18, Christian König wrote:
Am 19.07.24 um 15:02 schrieb Christian König:
Am 19.07.24 um 11:47 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
Long time ago in commit b3ac17667f11 ("drm/scheduler: rework entity
creation") a change was made which prevented priority c
From: Tvrtko Ursulin
Long time ago in commit b3ac17667f11 ("drm/scheduler: rework entity
creation") a change was made which prevented priority changes for entities
with only one assigned scheduler.
The commit reduced drm_sched_entity_set_priority() to simply update the
entities pri
Hi Dave, Sima,
One display fix for the merge window relating to DisplayPort LTTPR. It
fixes at least Dell UD22 dock when used on Intel N100 systems.
Regards,
Tvrtko
drm-intel-next-fixes-2024-07-18:
- Reset intel_dp->link_trained before retraining the link [dp] (Imre Deak)
- Don't switch the L
o this could be just "return
DRM_GEM_OBJECT_RESIDENT", although granted, like you have it is more
future proof.
Either way:
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
+
+ return res;
+}
+
/* Called DRM core on the last userspace/kernel unreference of the
* BO.
*/
From: Tvrtko Ursulin
Add some local variables to make the code a bit less verbose, with the
main benefit being pulling some lines to under 80 columns wide.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Maíra Canal
---
drivers/gpu/drm/v3d/v3d_submit.c | 88 ++--
1
From: Tvrtko Ursulin
If userspace provides an unknown or invalid handle anywhere in the handle
array the rest of the driver will not handle that well.
Fix it by checking handle was looked up successfully or otherwise fail the
extension by jumping into the existing unwind.
Signed-off-by: Tvrtko
From: Tvrtko Ursulin
Now that the build time dependencies on various array sizes have been
removed, we can move the perfmon init completely into its own compilation
unit and remove the hardcoded defines.
This improves on the temporary fix quickly delivered in commit
9c3951ec27b9 ("drm/v3d
From: Tvrtko Ursulin
Removing the intermediate buffer removes the last use of the
V3D_MAX_COUNTERS define, which will enable further driver cleanup.
While at it pull the 32 vs 64 bit copying decision outside the loop in
order to reduce the number of conditional instructions.
Signed-off-by
From: Tvrtko Ursulin
Instead of statically reserving pessimistic space for the kperfmon_ids
array, make the userspace extension code allocate the exactly required
amount of space.
Apart from saving some memory at runtime, this also removes the need for
the V3D_MAX_PERFMONS macro whose removal
From: Tvrtko Ursulin
The loop which looks up the syncobj and copies the kperfmon ids is
identical so lets move it to a helper.
The only change is replacing copy_from_user with get_user when copying a
scalar.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Maíra Canal
---
drivers/gpu/drm/v3d
From: Tvrtko Ursulin
If userspace provides an unknown or invalid handle anywhere in the handle
array the rest of the driver will not handle that well.
Fix it by checking handle was looked up successfully or otherwise fail the
extension by jumping into the existing unwind.
Signed-off-by: Tvrtko
From: Tvrtko Ursulin
It makes it just a tiny bit more obvious what is going on.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Maíra Canal
---
drivers/gpu/drm/v3d/v3d_submit.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_submit.c b
From: Tvrtko Ursulin
If fetching of userspace memory fails during the main loop, all drm sync
objs looked up until that point will be leaked because of the missing
drm_syncobj_put.
Fix it by exporting and using a common cleanup helper.
Signed-off-by: Tvrtko Ursulin
Fixes: bae7cb5d6800 (&quo
From: Tvrtko Ursulin
If fetching of userspace memory fails during the main loop, all drm sync
objs looked up until that point will be leaked because of the missing
drm_syncobj_put.
Fix it by exporting and using a common cleanup helper.
Signed-off-by: Tvrtko Ursulin
Fixes: 9ba0ff3e083f (&quo
From: Tvrtko Ursulin
Check that the number of perfmons userspace is passing in the copy and
reset extensions is not greater than the internal kernel storage where
the ids will be copied into.
Signed-off-by: Tvrtko Ursulin
Fixes: bae7cb5d6800 ("drm/v3d: Create a CPU job extension for the
From: Tvrtko Ursulin
When we had to quickly deal with a tree build issue via merging
792d16b5375d ("drm/v3d: Move perfmon init completely into own unit"), we
promised to follow up with a nicer solution.
As in the process of eliminating the hardcoded defines we have discovered a few
On 11/07/2024 14:00, Maíra Canal wrote:
On 7/11/24 06:15, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
If fetching of userspace memory fails during the main loop, all drm sync
objs looked up until that point will be leaked because of the missing
drm_syncobj_put.
Fix it by exporting and using
On 11/07/2024 13:31, Iago Toral wrote:
El mar, 09-07-2024 a las 17:34 +0100, Tvrtko Ursulin escribió:
From: Tvrtko Ursulin
Removing the intermediate buffer removes the last use of the
V3D_MAX_COUNTERS define, which will enable further driver cleanup.
While at it pull the 32 vs 64 bit
27; error and make can_preempt()
function param as const to resolve error: passing argument 1 of
‘can_preempt’ discards ‘const’ qualifier from the pointer target type.
v2: Simplify can_preemt() function (Tvrtko Ursulin)
Yeah sorry for that yesterday when I thought gen8 emit bb was dead code,
some
From: Tvrtko Ursulin
It makes it just a tiny bit more obvious what is going on.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Maíra Canal
---
drivers/gpu/drm/v3d/v3d_submit.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_submit.c b
From: Tvrtko Ursulin
Add some local variables to make the code a bit less verbose, with the
main benefit being pulling some lines to under 80 columns wide.
Signed-off-by: Tvrtko Ursulin
Reviewed-by: Maíra Canal
---
drivers/gpu/drm/v3d/v3d_submit.c | 88 ++--
1
From: Tvrtko Ursulin
The loop which looks up the syncobj and copies the kperfmon ids is
identical so lets move it to a helper.
The only change is replacing copy_from_user with get_user when copying a
scalar.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/v3d/v3d_submit.c | 152
From: Tvrtko Ursulin
Now that the build time dependencies on various array sizes have been
removed, we can move the perfmon init completely into its own compilation
unit and remove the hardcoded defines.
This improves on the temporary fix quickly delivered in
9c3951ec27b9 ("drm/v3d: Fix pe
From: Tvrtko Ursulin
Removing the intermediate buffer removes the last use of the
V3D_MAX_COUNTERS define, which will enable further driver cleanup.
While at it pull the 32 vs 64 bit copying decision outside the loop in
order to reduce the number of conditional instructions.
Signed-off-by
From: Tvrtko Ursulin
Instead of statically reserving pessimistic space for the kperfmon_ids
array, make the userspace extension code allocate the exactly required
amount of space.
Apart from saving some memory at runtime, this also removes the need for
the V3D_MAX_PERFMONS macro whose removal
From: Tvrtko Ursulin
If userspace provides an unknown or invalid handle anywhere in the handle
array the rest of the driver will not handle that well.
Fix it by checking handle was looked up successfuly or otherwise fail the
extension by jumping into the existing unwind.
Signed-off-by: Tvrtko
From: Tvrtko Ursulin
When we had to quickly deal with a tree build issue via merging
792d16b5375d ("drm/v3d: Move perfmon init completely into own unit"), we
promised to follow up with a nicer solution.
As in the process of eliminating the hardcoded defines we have discovered a few
From: Tvrtko Ursulin
If fetching of userspace memory fails during the main loop, all drm sync
objs looked up until that point will be leaked because of the missing
drm_syncobj_put.
Fix it by exporting and using a common cleanup helper.
Signed-off-by: Tvrtko Ursulin
Fixes: bae7cb5d6800 (&quo
From: Tvrtko Ursulin
If fetching of userspace memory fails during the main loop, all drm sync
objs looked up until that point will be leaked because of the missing
drm_syncobj_put.
Fix it by exporting and using a common cleanup helper.
Signed-off-by: Tvrtko Ursulin
Fixes: 9ba0ff3e083f (&quo
From: Tvrtko Ursulin
If userspace provides an unknown or invalid handle anywhere in the handle
array the rest of the driver will not handle that well.
Fix it by checking handle was looked up successfully or otherwise fail the
extension by jumping into the existing unwind.
Signed-off-by: Tvrtko
From: Tvrtko Ursulin
Check that the number of perfmons userspace is passing in the copy and
reset extensions is not greater than the internal kernel storage where
the ids will be copied into.
Signed-off-by: Tvrtko Ursulin
Fixes: bae7cb5d6800 ("drm/v3d: Create a CPU job extension for the
On 10/07/2024 18:43, Maíra Canal wrote:
On 7/10/24 10:41, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Add some local variables to make the code a bit less verbose, with the
main benefit being pulling some lines to under 80 columns wide.
Signed-off-by: Tvrtko Ursulin
I'd p
On 10/07/2024 18:38, Maíra Canal wrote:
On 7/10/24 10:41, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Now that the build time dependencies on various array sizes have been
removed, we can move the perfmon init completely into its own compilation
unit and remove the hardcoded defines.
This
On 10/07/2024 18:06, Maíra Canal wrote:
On 7/10/24 10:41, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
If userspace provides an unknown or invalid handle anywhere in the handle
array the rest of the driver will not handle that well.
Fix it by checking handle was looked up successfuly or
On 10/07/2024 14:41, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Check that the number of perfmons userspace is passing in the copy and
reset extensions is not greater than the internal kernel storage where
the ids will be copied into.
Signed-off-by: Tvrtko Ursulin
Fixes: bae7cb5d6800 (&quo
Hi Iago,
On 10/07/2024 07:06, Iago Toral wrote:
El mar, 09-07-2024 a las 17:34 +0100, Tvrtko Ursulin escribió:
From: Tvrtko Ursulin
When we had to quickly deal with a tree build issue via merging
792d16b5375d ("drm/v3d: Move perfmon init completely into own unit"),
we
promised to
From: Tvrtko Ursulin
Now that the build time dependencies on various array sizes have been
removed, we can move the perfmon init completely into its own compilation
unit and remove the hardcoded defines.
This improves on the temporary fix quickly delivered in
792d16b5375d ("drm/v3d:
From: Tvrtko Ursulin
It makes it just a tiny bit more obvious what is going on.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/v3d/v3d_submit.c | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_submit.c b/drivers/gpu/drm/v3d/v3d_submit.c
From: Tvrtko Ursulin
If userspace provides an unknown or invalid handle anywhere in the handle
array the rest of the driver will not handle that well.
Fix it by checking handle was looked up successfuly or otherwise fail the
extension by jumping into the existing unwind.
Signed-off-by: Tvrtko
From: Tvrtko Ursulin
In the timestamp and performance extensions userspace type for counts is
u32 so lets use unsigned in the kernel too.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/v3d/v3d_submit.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu
From: Tvrtko Ursulin
Removing the intermediate buffer removes the last use of the
V3D_MAX_COUNTERS define, which will enable further driver cleanup.
While at it pull the 32 vs 64 bit copying decision outside the loop in
order to reduce the number of conditional instructions.
Signed-off-by
From: Tvrtko Ursulin
The loop which looks up the syncobj and copies the kperfmon ids is
identical so lets move it to a helper.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/v3d/v3d_submit.c | 148 +--
1 file changed, 64 insertions(+), 84 deletions(-)
diff
From: Tvrtko Ursulin
Instead of statically reserving pessimistic space for the kperfmon_ids
array, make the userspace extension code allocate the exactly required
amount of space.
Apart from saving some memory at runtime, this also removes the need for
the V3D_MAX_PERFMONS macro whose removal
From: Tvrtko Ursulin
Add some local variables to make the code a bit less verbose, with the
main benefit being pulling some lines to under 80 columns wide.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/v3d/v3d_submit.c | 79 +---
1 file changed, 42 insertions
From: Tvrtko Ursulin
If userspace provides an unknown or invalid handle anywhere in the handle
array the rest of the driver will not handle that well.
Fix it by checking handle was looked up successfuly or otherwise fail the
extension by jumping into the existing unwind.
Signed-off-by: Tvrtko
From: Tvrtko Ursulin
When we had to quickly deal with a tree build issue via merging
792d16b5375d ("drm/v3d: Move perfmon init completely into own unit"), we
promised to follow up with a nicer solution.
As in the process of eliminating the hardcoded defines we have discovered a few
From: Tvrtko Ursulin
If fetching of userspace memory fails during the main loop, all drm sync
objs looked up until that point will be leaked because of the missing
drm_syncobj_put.
Fix it by exporting and using a common cleanup helper.
Signed-off-by: Tvrtko Ursulin
Fixes: 9ba0ff3e083f (&quo
From: Tvrtko Ursulin
Check that the number of perfmons userspace is passing in the copy and
reset extensions is not greater than the internal kernel storage where
the ids will be copied into.
Signed-off-by: Tvrtko Ursulin
Fixes: bae7cb5d6800 ("drm/v3d: Create a CPU job extension for the
From: Tvrtko Ursulin
If fetching of userspace memory fails during the main loop, all drm sync
objs looked up until that point will be leaked because of the missing
drm_syncobj_put.
Fix it by exporting and using a common cleanup helper.
Signed-off-by: Tvrtko Ursulin
Fixes: bae7cb5d6800 (&quo
On 09/07/2024 15:02, Tvrtko Ursulin wrote:
On 09/07/2024 13:53, Nitin Gote wrote:
We're seeing a GPU HANG issue on a CHV platform, which was caused by
bac24f59f454 ("drm/i915/execlists: Enable coarse preemption boundaries
for gen8").
Gen8 platform has only timeslice and do
From: Tvrtko Ursulin
Now that the build time dependencies on various array sizes have been
removed, we can move the perfmon init completely into its own compilation
unit and remove the hardcoded defines.
This improves on the temporary fix quickly delivered in
792d16b5375d ("drm/v3d:
From: Tvrtko Ursulin
Removing the intermediate buffer removes the last use of the
V3D_MAX_COUNTERS define, which will enable further driver cleanup.
While at it pull the 32 vs 64 bit copying decision outside the loop in
order to reduce the number of conditional instructions.
Signed-off-by
From: Tvrtko Ursulin
Instead of statically reserving pessimistic space for the kperfmon_ids
array, make the userspace extension code allocate the exactly required
amount of space.
Apart from saving some memory at runtime, this also removes the need for
the V3D_MAX_PERFMONS macro whose removal
From: Tvrtko Ursulin
The loop which looks up the syncobj and copies the kperfmon ids is
identical so lets move it to a helper.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/v3d/v3d_submit.c | 148 +--
1 file changed, 64 insertions(+), 84 deletions(-)
diff
From: Tvrtko Ursulin
If userspace provides an unknown or invalid handle anywhere in the handle
array the rest of the driver will not handle that well.
Fix it by checking handle was looked up successfuly or otherwise fail the
extension by jumping into the existing unwind.
Signed-off-by: Tvrtko
From: Tvrtko Ursulin
If fetching of userspace memory fails during the main loop, all drm sync
objs looked up until that point will be leaked because of the missing
drm_syncobj_put.
Fix it by exporting and using a common cleanup helper.
Signed-off-by: Tvrtko Ursulin
Fixes: 9ba0ff3e083f (&quo
From: Tvrtko Ursulin
If userspace provides an unknown or invalid handle anywhere in the handle
array the rest of the driver will not handle that well.
Fix it by checking handle was looked up successfuly or otherwise fail the
extension by jumping into the existing unwind.
Signed-off-by: Tvrtko
From: Tvrtko Ursulin
If fetching of userspace memory fails during the main loop, all drm sync
objs looked up until that point will be leaked because of the missing
drm_syncobj_put.
Fix it by exporting and using a common cleanup helper.
Signed-off-by: Tvrtko Ursulin
Fixes: bae7cb5d6800 (&quo
From: Tvrtko Ursulin
In the timestamp and performance extensions userspace type for counts is
u32 so lets use unsigned in the kernel too.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/v3d/v3d_submit.c | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a
From: Tvrtko Ursulin
Add some local variables to make the code a bit less verbose, with the
main benefit being pulling some lines to under 80 columns wide.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/v3d/v3d_submit.c | 103 ---
1 file changed, 54 insertions
From: Tvrtko Ursulin
It makes it just a tiny bit more obvious what is going on.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/v3d/v3d_submit.c | 22 +++---
1 file changed, 11 insertions(+), 11 deletions(-)
diff --git a/drivers/gpu/drm/v3d/v3d_submit.c b/drivers/gpu/drm
From: Tvrtko Ursulin
When we had to quickly deal with a tree build issue via merging
792d16b5375d ("drm/v3d: Move perfmon init completely into own unit"), we
promised to follow up with a nicer solution.
As in the process of eliminating the hardcoded defines we have discovered a few
From: Tvrtko Ursulin
Check that the number of perfmons userspace is passing in the copy and
reset extensions is not greater than the internal kernel storage where
the ids will be copied into.
Signed-off-by: Tvrtko Ursulin
Fixes: bae7cb5d6800 ("drm/v3d: Create a CPU job extension for the
On 09/07/2024 13:53, Nitin Gote wrote:
We're seeing a GPU HANG issue on a CHV platform, which was caused by
bac24f59f454 ("drm/i915/execlists: Enable coarse preemption boundaries for
gen8").
Gen8 platform has only timeslice and doesn't support a preemption mechanism
as engines do not have a p
Hi Dave, Sima,
The final pull for 6.11 is quite small and only contains a handful of
fixes in areas such as stolen memory probing on ATS-M, GuC priority
handling, out of memory reporting noise downgrade and fence register
hanlding race condition reported by CI.
Regards,
Tvrtko
drm-intel-gt-ne
Hi,
I few questions below.
On 01/07/2024 18:14, Lucas Stach wrote:
From: Christian König
Multiple drivers came up with the requirement to measure how
much runtime each entity accumulated on the HW.
A previous attempt of accounting this had to be reverted because
HW submissions can have a l
On 01/07/2024 10:25, Maarten Lankhorst wrote:
Den 2024-06-28 kl. 16:04, skrev Maxime Ripard:
Hi,
On Thu, Jun 27, 2024 at 09:22:56PM GMT, Maarten Lankhorst wrote:
Den 2024-06-27 kl. 19:16, skrev Maxime Ripard:
Hi,
Thanks for working on this!
On Thu, Jun 27, 2024 at 05:47:21PM GMT, Maarten
Hey Christian,
Any thoughts on the below reply? Did I get it wrong or I found a
legitimate issue?
Regards,
Tvrtko
On 14/06/2024 17:06, Tvrtko Ursulin wrote:
On 14/06/2024 10:53, Christian König wrote:
if (domain & abo->preferred_domains &
AMDGPU_GEM_
On 14/06/2024 19:00, Thadeu Lima de Souza Cascardo wrote:
On Fri, Jun 14, 2024 at 11:52:03AM +0100, Tvrtko Ursulin wrote:
On 24/03/2024 10:15, Thadeu Lima de Souza Cascardo wrote:
commit e531fdb5cd5e ("dma-buf/sw_sync: Avoid recursive lock during fence
signal") fixed a recursi
On 14/06/2024 10:53, Christian König wrote:
if (domain & abo->preferred_domains &
AMDGPU_GEM_DOMAIN_VRAM &&
- !(adev->flags & AMD_IS_APU))
- places[c].flags |= TTM_PL_FLAG_FALLBACK;
+ !(adev->flags & AMD_IS_APU)) {
+ /*
+ * Wh
On 24/03/2024 10:15, Thadeu Lima de Souza Cascardo wrote:
commit e531fdb5cd5e ("dma-buf/sw_sync: Avoid recursive lock during fence
signal") fixed a recursive locking when a signal callback released a fence.
It did it by taking an extra reference while traversing it on the list and
holding the t
the timeout used.
A couple tiny cleanups here and there and finally one back-merge which
was required to land some display code base refactoring.
Regards,
Tvrtko
drm-intel-gt-next-2024-06-12:
UAPI Changes:
- Support replaying GPU hangs with captured context image (Tvrtko Ursulin)
Driver
Hi Christian,
On 04/06/2024 17:05, Christian König wrote:
This should prevent buffer moves when the threshold is reached during
CS.
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 36 --
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 22 ++
On 10/06/2024 10:24, Nirmoy Das wrote:
Hi Andi,
On 6/7/2024 4:51 PM, Andi Shyti wrote:
The forcewake count and domains listing is multi process critical
and the uncore provides a spinlock for such cases.
Lock the forcewake evaluation section in the fw_domains_show()
debugfs interface.
Signe
Hi Andi,
On 10/06/2024 13:10, Andi Shyti wrote:
Hi Tvrtko,
On Mon, Jun 10, 2024 at 12:42:31PM +0100, Tvrtko Ursulin wrote:
On 03/06/2024 17:20, Niemiec, Krzysztof wrote:
The test is trying to push the heartbeat frequency to the limit, which
might sometimes fail. Such a failure does not
On 03/06/2024 17:20, Niemiec, Krzysztof wrote:
The test is trying to push the heartbeat frequency to the limit, which
might sometimes fail. Such a failure does not provide valuable
information, because it does not indicate that there is something
necessarily wrong with either the driver or the
On 05/06/2024 08:19, Iago Toral wrote:
Thanks for looking at ixing this Tvrtko.
El mar, 04-06-2024 a las 17:02 +0100, Tvrtko Ursulin escribió:
From: Tvrtko Ursulin
Move static const array into the source file to fix the "defined but
not
used" errors.
The fix is perhaps not the
On 06/06/2024 02:49, Adrián Larumbe wrote:
Some drivers must allocate a considerable amount of memory for bookkeeping
structures and GPU's MCU-kernel shared communication regions. These are
often created as a result of the invocation of the driver's ioctl()
interface functions, so it is sensib
From: Tvrtko Ursulin
Move static const array into the source file to fix the "defined but not
used" errors.
The fix is perhaps not the prettiest due hand crafting the array sizes
in v3d_performance_counters.h, but I did add some build time asserts to
validate the counts look se
Hi,
On 20/05/2024 12:13, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Convert fdinfo memory stats to use the common drm_print_memory_stats
helper.
This achieves alignment with the common keys as documented in
drm-usage-stats.rst, adding specifically drm-total- key the driver was
missing
Hi,
On 16/05/2024 13:18, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Reduced re-spin of my previous series after Christian corrected a few
misconceptions that I had. So lets see if what remains makes sense or is still
misguided.
To summarise, the series address the following two issues
From: Tvrtko Ursulin
Kernel test robot reports i915 can hit a warn in kvmalloc_node which has
a purpose of dissalowing crazy size kernel allocations. This was added in
7661809d493b ("mm: don't allow oversized kvmalloc() calls"):
/* Don't even allow crazy sizes */
From: Tvrtko Ursulin
Convert fdinfo memory stats to use the common drm_print_memory_stats
helper.
This achieves alignment with the common keys as documented in
drm-usage-stats.rst, adding specifically drm-total- key the driver was
missing until now.
Additionally I made the code stop skipping
From: Tvrtko Ursulin
Currently it is not well defined what is drm-memory- compared to other
categories.
In practice the only driver which emits these keys is amdgpu and in them
exposes the current resident buffer object memory (including shared).
To prevent any confusion, document that drm
On 16/05/2024 20:21, Alex Deucher wrote:
On Thu, May 16, 2024 at 8:18 AM Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Reduced re-spin of my previous series after Christian corrected a few
misconceptions that I had. So lets see if what remains makes sense or is still
misguided.
To summarise
From: Tvrtko Ursulin
Reduced re-spin of my previous series after Christian corrected a few
misconceptions that I had. So lets see if what remains makes sense or is still
misguided.
To summarise, the series address the following two issues:
* Migration rate limiting does not work, at least not
From: Tvrtko Ursulin
Current code appears to live in a misconception that playing with buffer
allowed and preferred placements can always control the decision on
whether backing store migration will be attempted or not.
That is however not the case when userspace sets buffer placements of
VRAM
From: Tvrtko Ursulin
Currently the driver appears to be thinking that it will be attempting to
re-validate the evicted buffers on the next submission if they are not in
their preferred placement.
That however appears not to be true for the very common case of buffers
with allowed placements of
driver may implement either this key or drm-total-cycles-, but not
+both.
+
For the spec part:
Acked-by: Tvrtko Ursulin
Some minor comments and questions below.
Memory
^^
@@ -168,5 +184,6 @@ be documented above and where possible, aligned with other dri
On 15/05/2024 15:31, Christian König wrote:
Am 15.05.24 um 12:59 schrieb Tvrtko Ursulin:
On 15/05/2024 08:20, Christian König wrote:
Am 08.05.24 um 20:09 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
Current code appears to live in a misconception that playing with
buffer
allowed and
On 15/05/2024 08:20, Christian König wrote:
Am 08.05.24 um 20:09 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
Current code appears to live in a misconception that playing with buffer
allowed and preferred placements can control the decision on whether
backing store migration will be
On 15/05/2024 08:14, Christian König wrote:
Am 08.05.24 um 20:09 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
The logic assumed any migration attempt worked and therefore would over-
account the amount of data migrated during buffer re-validation. As a
consequence client can be unfairly
On 13/05/2024 14:49, Tvrtko Ursulin wrote:
On 09/05/2024 13:40, Tvrtko Ursulin wrote:
On 08/05/2024 19:09, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Last few days I was looking at the situation with VRAM over
subscription, what
happens versus what perhaps should happen. Browsing
On 09/05/2024 13:40, Tvrtko Ursulin wrote:
On 08/05/2024 19:09, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Last few days I was looking at the situation with VRAM over
subscription, what
happens versus what perhaps should happen. Browsing through the driver
and
running some simple
On 13/05/2024 11:22, Jacek Lawrynowicz wrote:
Hi,
On 10.05.2024 18:55, Jeffrey Hugo wrote:
On 5/8/2024 7:29 AM, Jacek Lawrynowicz wrote:
From: Tomasz Rusinowicz
The driver tracks the time spent by NPU executing jobs
and shares it through sysfs `npu_busy_time_us` file.
It can be then used b
On 08/05/2024 19:09, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Last few days I was looking at the situation with VRAM over subscription, what
happens versus what perhaps should happen. Browsing through the driver and
running some simple experiments.
I ended up with this patch series which
101 - 200 of 2052 matches
Mail list logo
