From: Tvrtko Ursulin
Currently when one enables driver debugging dmesg gets spammed, at I
suspect vblank rate, with messages like:
[drm:amdgpu_dm_atomic_check [amdgpu]] MPO enablement requested on
crtc:[f073c3bb]
Fix if by converting some logging from deprecated and incorrect
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
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
Align kerneldoc with the function argument name.
Signed-off-by: Tvrtko Ursulin
Reported-by: Stephen Rothwell
Fixes: 26e20235ce00 ("drm/amdgpu: Add amdgpu_bo_is_vm_bo helper")
Cc: Christian König
Cc: Alex Deucher
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 2
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
Hi Christian,
On 08/05/2024 09:26, Tvrtko Ursulin wrote:
On 08/05/2024 06:42, Christian König wrote:
Am 06.05.24 um 18:26 schrieb Tvrtko Ursulin:
On 03/05/2024 10:14, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Help code readability by replacing a bunch of:
bo->tbo.base.resv ==
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
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
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
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
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
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 08/05/2024 20:08, Friedrich Vock wrote:
On 08.05.24 20:09, Tvrtko Ursulin wrote:
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 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
On 08/05/2024 06:42, Christian König wrote:
Am 06.05.24 um 18:26 schrieb Tvrtko Ursulin:
On 03/05/2024 10:14, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Help code readability by replacing a bunch of:
bo->tbo.base.resv == vm->root.bo->tbo.base.resv
With:
amdgpu_vm_is_bo_always
From: Tvrtko Ursulin
Currently the fallback placement flag can achieve a hint that buffer
should be migrated back to the non-fallback placement, however that only
works while there is no memory pressure. As soon as we reach full VRAM
utilisation, or worse overcommit, the logic is happy to leave
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, as a disclaimer, may be completely
wrong
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 penalised by incorrectly considering
its migration budget spent.
Fix it by looking at the before
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
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 attempted or not.
Both from code inspection and from empirical experiments I see that not
being true
From: Tvrtko Ursulin
Now that TTM has the preferred placement flag, extend the current
workaround which assumes the GTT placement as fallback in the presence of
the additional VRAM placement.
By marking the VRAM placement as preferred we will make the buffer re-
validation phase actually
On 03/05/2024 15:28, Alex Deucher wrote:
On Fri, May 3, 2024 at 7:50 AM Tvrtko Ursulin wrote:
On 02/05/2024 16:00, Alex Deucher wrote:
On Thu, May 2, 2024 at 10:43 AM Tvrtko Ursulin
wrote:
On 02/05/2024 14:07, Christian König wrote:
Am 01.05.24 um 15:27 schrieb Tvrtko Ursulin:
Hi
On 06/05/2024 17:59, 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 until now
On 03/05/2024 10:14, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Help code readability by replacing a bunch of:
bo->tbo.base.resv == vm->root.bo->tbo.base.resv
With:
amdgpu_vm_is_bo_always_valid(vm, bo)
No functional changes.
v2:
* Rename helper and move to amdgpu_vm. (Chris
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
Help code readability by replacing a bunch of:
bo->tbo.base.resv == vm->root.bo->tbo.base.resv
With:
amdgpu_vm_is_bo_always_valid(vm, bo)
No functional changes.
v2:
* Rename helper and move to amdgpu_vm. (Christian)
v3:
* Use Christian's kerneldoc.
v4:
From: Tvrtko Ursulin
Accurately show all placements when describing objects in debugfs, instead
of bunching them up under the 'CPU' placement.
Signed-off-by: Tvrtko Ursulin
Cc: Christian König
Cc: Felix Kuehling
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
From: Tvrtko Ursulin
All apart from AMDGPU_GEM_DOMAIN_GTT memory domains map 1:1 to TTM
placements. And the former be either AMDGPU_PL_PREEMPT or TTM_PL_TT,
depending on AMDGPU_GEM_CREATE_PREEMPTIBLE.
Simplify a few places in the code which convert the TTM placement into
a domain by checking
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 total memory use (including shared).
To prevent any confusion, document that drm-memory- is deprecated
From: Tvrtko Ursulin
Following on from the recent discussion from:
https://lore.kernel.org/dri-devel/ZjjTaeZYNqVSj2y-@phenom.ffwll.local/T/#mb8105d8d7de055d3068975d27c428525e55cff84
I included some old three patches to start with, since the last in the series
depends on first, plus first had
On 03/05/2024 16:58, Alex Deucher wrote:
On Fri, May 3, 2024 at 11:33 AM Daniel Vetter wrote:
On Fri, May 03, 2024 at 01:58:38PM +0100, Tvrtko Ursulin wrote:
[And I forgot dri-devel.. doing well!]
On 03/05/2024 13:40, Tvrtko Ursulin wrote:
[Correcting Christian's email]
On 03/05/2024
On 03/05/2024 14:47, Alex Deucher wrote:
On Fri, May 3, 2024 at 3:50 AM Tvrtko Ursulin wrote:
On 02/05/2024 14:16, Christian König wrote:
Am 30.04.24 um 19:27 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
Do not emit the key-value pairs if the VRAM does not exist ie. VRAM
placement
On 03/05/2024 14:39, Alex Deucher wrote:
On Fri, May 3, 2024 at 8:58 AM Tvrtko Ursulin wrote:
[And I forgot dri-devel.. doing well!]
On 03/05/2024 13:40, Tvrtko Ursulin wrote:
[Correcting Christian's email]
On 03/05/2024 13:36, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Currently
[And I forgot dri-devel.. doing well!]
On 03/05/2024 13:40, Tvrtko Ursulin wrote:
[Correcting Christian's email]
On 03/05/2024 13:36, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
Currently it is not well defined what is drm-memory- compared to other
categories.
In practice the only driver
On 03/05/2024 07:26, Christian König wrote:
Am 29.04.24 um 18:47 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
Help code readability by replacing a bunch of:
bo->tbo.base.resv == vm->root.bo->tbo.base.resv
With:
amdgpu_vm_is_bo_always_valid(vm, bo)
No functional changes.
v2:
Hi,
I tried asking on #radeon yesterday but no takers. I was wondering if
the below splat is already known or not.
Appears to happen due amdgpu_bo_release_notify genuniely running before
amdgpu_ttm_set_buffer_funcs_status set the buffer funcs to enabled
during device probe.
I couldn't
[Correcting Christian's email]
On 03/05/2024 13:36, Tvrtko Ursulin wrote:
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 total memory use (including
On 02/05/2024 16:00, Alex Deucher wrote:
On Thu, May 2, 2024 at 10:43 AM Tvrtko Ursulin
wrote:
On 02/05/2024 14:07, Christian König wrote:
Am 01.05.24 um 15:27 schrieb Tvrtko Ursulin:
Hi Alex,
On 30/04/2024 19:32, Alex Deucher wrote:
On Tue, Apr 30, 2024 at 1:27 PM Tvrtko Ursulin
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 total memory use (including shared).
Document that drm-memory- and drm-total-memory- are aliases
From: Tvrtko Ursulin
Help code readability by replacing a bunch of:
bo->tbo.base.resv == vm->root.bo->tbo.base.resv
With:
amdgpu_vm_is_bo_always_valid(vm, bo)
No functional changes.
v2:
* Rename helper and move to amdgpu_vm. (Christian)
v3:
* Use Christian's kerneldoc.
S
From: Tvrtko Ursulin
All apart from AMDGPU_GEM_DOMAIN_GTT memory domains map 1:1 to TTM
placements. And the former be either AMDGPU_PL_PREEMPT or TTM_PL_TT,
depending on AMDGPU_GEM_CREATE_PREEMPTIBLE.
Simplify a few places in the code which convert the TTM placement into
a domain by checking
From: Tvrtko Ursulin
Accurately show all placements when describing objects in debugfs, instead
of bunching them up under the 'CPU' placement.
Signed-off-by: Tvrtko Ursulin
Cc: Christian König
Cc: Felix Kuehling
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c
On 02/05/2024 14:16, Christian König wrote:
Am 30.04.24 um 19:27 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
Do not emit the key-value pairs if the VRAM does not exist ie. VRAM
placement is not valid and accessible.
Yeah, that's unfortunately rather misleading.
Even APUs have VRAM
On 02/05/2024 14:07, Christian König wrote:
Am 01.05.24 um 15:27 schrieb Tvrtko Ursulin:
Hi Alex,
On 30/04/2024 19:32, Alex Deucher wrote:
On Tue, Apr 30, 2024 at 1:27 PM Tvrtko Ursulin
wrote:
From: Tvrtko Ursulin
I have noticed AMD GPUs can have more than one "engine&q
Hi Alex,
On 30/04/2024 19:32, Alex Deucher wrote:
On Tue, Apr 30, 2024 at 1:27 PM Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
I have noticed AMD GPUs can have more than one "engine" (ring?) of the same type
but amdgpu is not reporting that in fdinfo using the capacity
On 30/04/2024 01:31, Felix Kuehling wrote:
On 2024-04-29 12:47, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
All apart from AMDGPU_GEM_DOMAIN_GTT memory domains map 1:1 to TTM
placements. And the former be either AMDGPU_PL_PREEMPT or TTM_PL_TT,
depending on AMDGPU_GEM_CREATE_PREEMPTIBLE
From: Tvrtko Ursulin
Avoids a tiny bit of arithmetic and more importantly walking those empty
arrays up to amdgpu_sched_jobs slots and amdgpu_ctx_num_entities, both
which are pointless if there are no rings of the respective type.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/amd/amdgpu
From: Tvrtko Ursulin
Do not emit the key-value pairs if the VRAM does not exist ie. VRAM
placement is not valid and accessible.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c | 29 +-
1 file changed, 17 insertions(+), 12 deletions(-)
diff
From: Tvrtko Ursulin
In cases where there is more than one user visible engine of the same type
DRM fdinfo spec allows the capacity tag to be emitted.
Start doing that so that gputop can adapt and show, for example, 50% if
only one of the two engine instances is fully loaded, while the other
From: Tvrtko Ursulin
Now that we keep a cached value it is no longer required to walk the
arrays and check the fuses.
Open however is whether at runtime this query is supposed to report if a
ring has disappeared due for example amdgpu_ib_ring_tests() turning it
off.
Signed-off-by: Tvrtko
From: Tvrtko Ursulin
With the end goal being using the number of rings for exposing capacity in
fdinfo, and the observation that the number could be used elsewhere in the
driver, lets cache it during the driver init phase.
We count the number of created scheduler instances for user visible hw
From: Tvrtko Ursulin
I have noticed AMD GPUs can have more than one "engine" (ring?) of the same type
but amdgpu is not reporting that in fdinfo using the capacity engine tag.
This series is therefore an attempt to improve that, but only an RFC since it is
quite likely I got s
From: Tvrtko Ursulin
All apart from AMDGPU_GEM_DOMAIN_GTT memory domains map 1:1 to TTM
placements. And the former be either AMDGPU_PL_PREEMPT or TTM_PL_TT,
depending on AMDGPU_GEM_CREATE_PREEMPTIBLE.
Simplify a few places in the code which convert the TTM placement into
a domain by checking
On 29/04/2024 12:02, Christian König wrote:
Am 26.04.24 um 18:43 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
Help code readability by replacing a bunch of:
bo->tbo.base.resv == vm->root.bo->tbo.base.resv
With:
amdgpu_bo_is_vm_bo(bo, vm)
No functional changes.
Ah,yes that
Hi Christian,
On 29/04/2024 12:03, Christian König wrote:
Am 26.04.24 um 18:43 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
All apart from AMDGPU_GEM_DOMAIN_GTT memory domains map 1:1 to TTM
placements. And the former be either AMDGPU_PL_PREEMPT or TTM_PL_TT,
depending
On 29/04/2024 12:11, Christian König wrote:
Am 29.04.24 um 11:43 schrieb Tvrtko Ursulin:
On 26/04/2024 23:24, Felix Kuehling wrote:
On 2024-04-26 12:43, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
When commit b453e42a6e8b ("drm/amdgpu: Add new placement for
preemptible
SG BOs&qu
On 29/04/2024 15:43, Felix Kuehling wrote:
On 2024-04-29 5:43, Tvrtko Ursulin wrote:
On 26/04/2024 23:24, Felix Kuehling wrote:
On 2024-04-26 12:43, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
When commit b453e42a6e8b ("drm/amdgpu: Add new placement for
preemptible
SG BOs") a
From: Tvrtko Ursulin
Help code readability by replacing a bunch of:
bo->tbo.base.resv == vm->root.bo->tbo.base.resv
With:
amdgpu_vm_is_bo_always_valid(vm, bo)
No functional changes.
v2:
* Rename helper and move to amdgpu_vm. (Christian)
Signed-off-by: Tvrtko Ursulin
Cc: Christ
From: Tvrtko Ursulin
All apart from AMDGPU_GEM_DOMAIN_GTT memory domains map 1:1 to TTM
placements. And the former be either AMDGPU_PL_PREEMPT or TTM_PL_TT,
depending on AMDGPU_GEM_CREATE_PREEMPTIBLE.
Simplify a few places in the code which convert the TTM placement into
a domain by checking
From: Tvrtko Ursulin
Instead of mixing them together with regular system memory objects mark
them explicitly as 'PREEMPTIBLE'.
Signed-off-by: Tvrtko Ursulin
Cc: Christian König
Cc: Felix Kuehling
---
No idea on the name to use.. :)
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 3 +++
1
On 26/04/2024 23:24, Felix Kuehling wrote:
On 2024-04-26 12:43, Tvrtko Ursulin wrote:
From: Tvrtko Ursulin
When commit b453e42a6e8b ("drm/amdgpu: Add new placement for preemptible
SG BOs") added a new TTM region it missed to notice the conceptual
imbalance in GART pin size
From: Tvrtko Ursulin
All apart from AMDGPU_GEM_DOMAIN_GTT memory domains map 1:1 to TTM
placements. And the former be either AMDGPU_PL_PREEMPT or TTM_PL_TT,
depending on AMDGPU_GEM_CREATE_PREEMPTIBLE.
Simplify a few places in the code which convert the TTM placement into
a domain by checking
From: Tvrtko Ursulin
As I was reading through the driver I spotted one thing which could
perhaps make it more readable (1/3), one thing which reduces some double
conversions (in principle) from TTM placement back to domain (2/3), and
also enables the last patch in the series which maybe fixes
From: Tvrtko Ursulin
When commit b453e42a6e8b ("drm/amdgpu: Add new placement for preemptible
SG BOs") added a new TTM region it missed to notice the conceptual
imbalance in GART pin size accounting as done in amdgpu_bo_pin/unpin.
That imbalance leads to such objects getting account
From: Tvrtko Ursulin
Help code readability by replacing a bunch of:
bo->tbo.base.resv == vm->root.bo->tbo.base.resv
With:
amdgpu_bo_is_vm_bo(bo, vm)
No functional changes.
Signed-off-by: Tvrtko Ursulin
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c| 2 +-
drivers/gpu/drm/a
On 01/04/2024 18:58, Felix Kuehling wrote:
On 2024-04-01 12:56, Tvrtko Ursulin wrote:
On 01/04/2024 17:37, Felix Kuehling wrote:
On 2024-04-01 11:09, Tvrtko Ursulin wrote:
On 28/03/2024 20:42, Felix Kuehling wrote:
On 2024-03-28 12:03, Tvrtko Ursulin wrote:
Hi Felix,
I had one more
On 01/04/2024 17:37, Felix Kuehling wrote:
On 2024-04-01 11:09, Tvrtko Ursulin wrote:
On 28/03/2024 20:42, Felix Kuehling wrote:
On 2024-03-28 12:03, Tvrtko Ursulin wrote:
Hi Felix,
I had one more thought while browsing around the amdgpu CRIU plugin.
It appears it relies on the KFD
On 28/03/2024 20:42, Felix Kuehling wrote:
On 2024-03-28 12:03, Tvrtko Ursulin wrote:
Hi Felix,
I had one more thought while browsing around the amdgpu CRIU plugin.
It appears it relies on the KFD support being compiled in and /dev/kfd
present, correct? AFAICT at least, it relies
for things like
re-assigned minor numbers due driver reload.
Otherwise I am eagerly awaiting to hear more about the design specifics
around dma-buf handling. And also seeing how to extend to other DRM
related anonymous fds.
Regards,
Tvrtko
On 15/03/2024 18:36, Tvrtko Ursulin wrote:
On 15/03
On 21/03/2024 12:43, Christian König wrote:
This reverts drm/amdgpu: fix ftrace event amdgpu_bo_move always move
on same heap. The basic problem here is that after the move the old
location is simply not available any more.
Some fixes where suggested, but essentially we should call the move
Hi Christian,
On 21/03/2024 10:25, Christian König wrote:
Am 20.03.24 um 18:12 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
Pipelined object migration will free up the old bo->resource, meaning
the tracepoint added in 94aeb4117343 ("drm/amdgpu: fix ftrace event
amdgpu_bo_move alw
From: Tvrtko Ursulin
Pipelined object migration will free up the old bo->resource, meaning
the tracepoint added in 94aeb4117343 ("drm/amdgpu: fix ftrace event
amdgpu_bo_move always move on same heap") will trigger an use after free
when it dereferences the cached old_mem.
Fix
From: Tvrtko Ursulin
Pipelined object migration will free up the old bo->resource, meaning
the tracepoint added in 94aeb4117343 ("drm/amdgpu: fix ftrace event
amdgpu_bo_move always move on same heap") will trigger an use after free
when it dereferences the cached old_mem.
Fix
On 15/03/2024 02:33, Felix Kuehling wrote:
On 2024-03-12 5:45, Tvrtko Ursulin wrote:
On 11/03/2024 14:48, Tvrtko Ursulin wrote:
Hi Felix,
On 06/12/2023 21:23, Felix Kuehling wrote:
Executive Summary: We need to add CRIU support to DRM render nodes
in order to maintain CRIU support
On 11/03/2024 14:48, Tvrtko Ursulin wrote:
Hi Felix,
On 06/12/2023 21:23, Felix Kuehling wrote:
Executive Summary: We need to add CRIU support to DRM render nodes in
order to maintain CRIU support for ROCm application once they start
relying on render nodes for more GPU memory management
Hi Felix,
On 06/12/2023 21:23, Felix Kuehling wrote:
Executive Summary: We need to add CRIU support to DRM render nodes in
order to maintain CRIU support for ROCm application once they start
relying on render nodes for more GPU memory management. In this email
I'm providing some background
s[id].shared += sz;
else
stats[id].private += sz;
Reviewed-by: Tvrtko Ursulin
Good that you remembered this story, I completely forgot!
Regards,
Tvrtko
G_LOCKDEP
/**
Not sure what the local view on static inlines, but fine nevertheless.
Reviewed-by: Tvrtko Ursulin
Regards,
Tvrtko
ts(obj)) {
status.shared += obj->size;
} else {
status.private += obj->size;
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 13/07/2023 16:09, Thomas Zimmermann wrote:
Hi
Am 13.07.23 um 16:41 schrieb Sean Paul:
On Thu, Jul 13, 2023 at 9:04 AM Uwe Kleine-König
wrote:
hello Sean,
On Wed, Jul 12, 2023 at 02:31:02PM -0400, Sean Paul wrote:
I'd really prefer this patch (series or single) is not accepted. This
On 10/05/2023 19:46, Tejun Heo wrote:
Hello,
On Wed, May 10, 2023 at 04:59:01PM +0200, Maarten Lankhorst wrote:
The misc controller is not granular enough. A single computer may have any
number of
graphics cards, some of them with multiple regions of vram inside a single card.
Extending
On 03/05/2023 09:34, Maarten Lankhorst wrote:
Based roughly on the rdma and misc cgroup controllers, with a lot of
the accounting code borrowed from rdma.
The interface is simple:
- populate drmcgroup_device->regions[..] name and size for each active
region.
- Call
On 12/04/2023 10:34, Christian König wrote:
Am 12.04.23 um 00:56 schrieb Rob Clark:
From: Rob Clark
Similar motivation to other similar recent attempt[1]. But with an
attempt to have some shared code for this. As well as documentation.
It is probably a bit UMA-centric, I guess devices
On 05/04/2023 09:28, Daniel Vetter wrote:
On Tue, 4 Apr 2023 at 12:45, Tvrtko Ursulin
wrote:
Hi,
On 03/04/2023 20:40, Joshua Ashton wrote:
Hello all!
I would like to propose a new API for allowing processes to control
the priority of GPU queues similar to RLIMIT_NICE/RLIMIT_RTPRIO
Hi,
On 03/04/2023 20:40, Joshua Ashton wrote:
Hello all!
I would like to propose a new API for allowing processes to control
the priority of GPU queues similar to RLIMIT_NICE/RLIMIT_RTPRIO.
The main reason for this is for compositors such as Gamescope and
SteamVR vrcompositor to be able to
On 20/02/2023 10:01, Christian König wrote:
Am 20.02.23 um 10:55 schrieb Tvrtko Ursulin:
Hi,
On 14/02/2023 13:59, Christian König wrote:
Am 14.02.23 um 13:50 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
Currently drm_gem_handle_create_tail exposes the handle to userspace
before
Hi,
On 14/02/2023 13:59, Christian König wrote:
Am 14.02.23 um 13:50 schrieb Tvrtko Ursulin:
From: Tvrtko Ursulin
Currently drm_gem_handle_create_tail exposes the handle to userspace
before the buffer object constructions is complete. This allowing
of working against a partially
From: Tvrtko Ursulin
Currently drm_gem_handle_create_tail exposes the handle to userspace
before the buffer object constructions is complete. This allowing
of working against a partially constructed object, which may also be in
the process of having its creation fail, can have a range
On 29/11/2022 18:05, Matthew Auld wrote:
On Fri, 25 Nov 2022 at 11:14, Tvrtko Ursulin
wrote:
+ Matt
On 25/11/2022 10:21, Christian König wrote:
TTM is just wrapping core DMA functionality here, remove the mid-layer.
No functional change.
Signed-off-by: Christian König
---
drivers
+ Matt
On 25/11/2022 10:21, Christian König wrote:
TTM is just wrapping core DMA functionality here, remove the mid-layer.
No functional change.
Signed-off-by: Christian König
---
drivers/gpu/drm/i915/gem/i915_gem_ttm.c | 9 ++---
1 file changed, 6 insertions(+), 3 deletions(-)
diff
On 26/07/2022 08:46, Thomas Zimmermann wrote:
Hi
Am 25.07.22 um 19:14 schrieb Christian König:
Am 25.07.22 um 17:27 schrieb Tvrtko Ursulin:
On 24/07/2022 19:28, Thomas Zimmermann wrote:
Hi
Am 22.07.22 um 17:47 schrieb Christian König:
Hi Tvrtko,
scratching my head what exactly is going
st regards
Thomas
Regards,
Christian.
Am 22.07.22 um 16:46 schrieb Tvrtko Ursulin:
On 14/07/2022 09:45, Thomas Zimmermann wrote:
Hi
Am 08.07.22 um 11:30 schrieb Arunpravin Paneer Selvam:
This reverts commit 708d19d9f362766147cab79eccae60912c6d3068.
This commit is only present in drm-misc-ne
On 14/07/2022 09:45, Thomas Zimmermann wrote:
Hi
Am 08.07.22 um 11:30 schrieb Arunpravin Paneer Selvam:
This reverts commit 708d19d9f362766147cab79eccae60912c6d3068.
This commit is only present in drm-misc-next. Should the revert be
cherry-picked into drm-misc-next-fixes?
Seemed like an
On 10/05/2022 17:55, Christian König wrote:
This is enough to get gputop working :)
Super cool! So I guess it's time for me to cleanup that code base a bit.
Regards,
Tvrtko
Signed-off-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_fdinfo.c | 7 +++
1 file changed, 3
1 - 100 of 116 matches
Mail list logo
