For each buffer object, remember evictions and try undoing them if
memory pressure gets lower again.
Signed-off-by: Friedrich Vock
---
drivers/gpu/drm/ttm/ttm_bo.c | 28 +++-
drivers/gpu/drm/ttm/ttm_bo_util.c | 3 +++
2 files changed, 30 insertions(+), 1 deletion(-)
Hi everyone,
recently I've been looking into remedies for apps (in particular, newer
games) that experience significant performance loss when they start to
hit VRAM limits, especially on older or lower-end cards that struggle
to fit both desktop apps and all the game data into VRAM at once.
The r
Provides fine-grained control for drivers over which buffers should be
considered when attempting to undo evictions.
Signed-off-by: Friedrich Vock
---
include/drm/ttm/ttm_device.h | 23 +++
1 file changed, 23 insertions(+)
diff --git a/include/drm/ttm/ttm_device.h b/include/
We will never try evicting things from VRAM for these resources anyway.
This affects TTM buffer uneviction logic, which would otherwise try to
move these buffers into VRAM (clashing with VRAM-only allocations).
Signed-off-by: Friedrich Vock
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 13 +++
Reserve the highest priority for the kernel, and choose a balanced value
as userspace default. Userspace is intended to be able to modify these
later to mark buffers as important/unimportant.
Signed-off-by: Friedrich Vock
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c| 1 +
drivers/gpu/drm/amd/
This makes buffer eviction significantly more stable by avoiding
ping-ponging caused by low-priority buffers evicting high-priority
buffers and vice versa.
Signed-off-by: Friedrich Vock
---
drivers/gpu/drm/ttm/ttm_bo.c | 9 +++--
drivers/gpu/drm/ttm/ttm_resource.c | 5 +++--
include/dr
When undoing evictions because of decreased memory pressure, it makes no
sense to try evicting other buffers.
Signed-off-by: Friedrich Vock
---
drivers/gpu/drm/ttm/ttm_bo.c | 2 ++
include/drm/ttm/ttm_bo.h | 2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/gpu/drm/ttm/ttm_bo.c b/
Indicates support for EVICTED_VRAM queries and
AMDGPU_GEM_OP_SET_PRIORITY
Signed-off-by: Friedrich Vock
---
drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_drv.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_d
Used to dynamically adjust priorities of buffers at runtime, to react to
changes in memory pressure/usage patterns.
Signed-off-by: Friedrich Vock
---
drivers/gpu/drm/ttm/ttm_bo.c | 17 +
include/drm/ttm/ttm_bo.h | 2 ++
2 files changed, 19 insertions(+)
diff --git a/drivers
If we didn't get the favorite placement because it was full, we should
try moving it into the favorite placement once there is space.
Signed-off-by: Friedrich Vock
---
drivers/gpu/drm/ttm/ttm_bo.c | 28 +++-
1 file changed, 27 insertions(+), 1 deletion(-)
diff --git a/dr
This adds GTT to the "preferred domains" of this buffer object, which
will also prevent any attempts at moving the buffer back to VRAM if
there is space. If VRAM is full, GTT will already be chosen as a
fallback.
Signed-off-by: Friedrich Vock
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c| 4 --
These utilities will be used to keep track of what buffers have been
evicted from any particular place, to try and decide when to try undoing
the eviction.
Signed-off-by: Friedrich Vock
---
drivers/gpu/drm/ttm/ttm_device.c | 1 +
drivers/gpu/drm/ttm/ttm_resource.c | 14 ++
include
Try unevicting only VRAM/GTT BOs.
Signed-off-by: Friedrich Vock
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 50 +
1 file changed, 50 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
index 64f5001a7dc5d..98e8a
TTM now takes care of moving buffers to the best possible domain.
Signed-off-by: Friedrich Vock
---
drivers/gpu/drm/amd/amdgpu/amdgpu.h| 2 -
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c | 191 +
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.h | 4 -
drivers/gpu/drm/amd/
Used by userspace to adjust buffer priorities in response to changes in
application demand and memory pressure.
Signed-off-by: Friedrich Vock
---
drivers/gpu/drm/amd/amdgpu/amdgpu_gem.c | 20
include/uapi/drm/amdgpu_drm.h | 1 +
2 files changed, 21 insertions(+)
Used by userspace to gauge the severity of memory overcommit and make
prioritization decisions based on it.
Used by userspace to gauge the severity of memory overcommit and make
prioritization decisions based on it.
Signed-off-by: Friedrich Vock
---
drivers/gpu/drm/amd/amdgpu/amdgpu_kms.c | 3 +
For adjustable priorities by userspace, it is nice to have a bit more
granularity.
Signed-off-by: Friedrich Vock
---
include/drm/ttm/ttm_resource.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/drm/ttm/ttm_resource.h b/include/drm/ttm/ttm_resource.h
index 7d1ce059c8
[AMD Official Use Only - General]
Acked-by: Alex Deucher
From: Bob Zhou
Sent: Tuesday, April 23, 2024 1:32 AM
To: amd-gfx@lists.freedesktop.org ; Deucher,
Alexander ; Koenig, Christian
Cc: Zhou, Bob
Subject: [PATCH 1/2] drm/amdgpu: fix double free err_addr po
Queue buffer, though it is in system memory, has to be created using the
correct amdgpu device. Enforce this as the BO needs to mapped to the
GART for MES Hardware scheduler to access it.
Signed-off-by: Harish Kasiviswanathan
---
drivers/gpu/drm/amd/amdkfd/kfd_chardev.c | 5 +
1 file changed
On Wed, Apr 24, 2024 at 1:57 PM Harish Kasiviswanathan
wrote:
>
> Queue buffer, though it is in system memory, has to be created using the
> correct amdgpu device. Enforce this as the BO needs to mapped to the
> GART for MES Hardware scheduler to access it.
>
> Signed-off-by: Harish Kasiviswanatha
[AMD Official Use Only - General]
> -Original Message-
> From: Ma, Jun
> Sent: Wednesday, April 24, 2024 6:04 AM
> To: amd-gfx@lists.freedesktop.org; Koenig, Christian
> ; Deucher, Alexander
>
> Cc: Ma, Jun
> Subject: [PATCH 1/3] drm/amdgpu: Fix uninitialized variable warning in
> amdgp
-id: 20240424-amdgpu-dml2-fix-frame-larger-than-dcn401-48ff7e1f51ea
Best regards,
--
Nathan Chancellor
When building with tip of tree Clang, there are some new instances of
-Wframe-larger-than from the new display code (which become fatal with
CONFIG_WERROR=y):
drivers/gpu/drm/amd/amdgpu/../display/dc/dml2/dml21/src/dml2_core/dml2_core_shared.c:754:6:
error: stack frame size (2488) exceeds limi
-Wframe-larger-than=2048 is a part of both CFLAGS and CFLAGS_REMOVE for
dml2_core_dcn4_calcs.o, which means that it ultimately gets removed
altogether for 64-bit targets, as 2048 is the default FRAME_WARN value
for 64-bit platforms, resulting in no -Wframe-larger-than coverage for
this file.
Remov
[AMD Official Use Only - General]
> -Original Message-
> From: Ma, Jun
> Sent: Wednesday, April 24, 2024 6:04 AM
> To: amd-gfx@lists.freedesktop.org; Koenig, Christian
> ; Deucher, Alexander
>
> Cc: Ma, Jun
> Subject: [PATCH 3/3] drm/amdgpu: Fix the uninitialized variable warning
>
> In
On 2024-04-24 13:40, Harish Kasiviswanathan wrote:
Queue buffer, though it is in system memory, has to be created using the
correct amdgpu device. Enforce this as the BO needs to mapped to the
GART for MES Hardware scheduler to access it.
Signed-off-by: Harish Kasiviswanathan
I guess this doe
[AMD Official Use Only - General]
Thanks for the fix.
Reviewed-by: Aurabindo Pillai
--
Regards,
Jay
From: Nathan Chancellor
Sent: Wednesday, April 24, 2024 2:19 PM
To: Wentland, Harry ; Li, Sun peng (Leo)
; Siqueira, Rodrigo ; Deucher,
Alexander ; Koenig, Ch
[Public]
> -Original Message-
> From: Jani Nikula
> Sent: Wednesday, April 24, 2024 9:55 AM
> To: dri-de...@lists.freedesktop.org
> Cc: Andrzej Hajda ; Maxime Ripard
> ; Jacek Lawrynowicz
> ; Stanislaw Gruszka
> ; Oded Gabbay ;
> Russell King ; David Airlie ; Daniel
> Vetter ; Neil Armstr
Hi Dave, Sima,
Fixes for 6.9.
The following changes since commit ed30a4a51bb196781c8058073ea720133a65596f:
Linux 6.9-rc5 (2024-04-21 12:35:54 -0700)
are available in the Git repository at:
https://gitlab.freedesktop.org/agd5f/linux.git
tags/amd-drm-fixes-6.9-2024-04-24
for you to fetch c
For the nouveau bits:
Reviewed-by: Lyude Paul
On Mon, 2024-04-22 at 15:10 +0300, Jani Nikula wrote:
> Surprisingly many places depend on debugfs.h to be included via
> drm_print.h. Fix them.
>
> v3: Also fix armada, ite-it6505, imagination, msm, sti, vc4, and xe
>
> v2: Also fix ivpu and vmwgf
On Mon, Apr 22, 2024 at 03:10:10PM GMT, Jani Nikula wrote:
drivers/gpu/drm/xe/xe_debugfs.c | 1 +
drivers/gpu/drm/xe/xe_gt_debugfs.c | 2 ++
drivers/gpu/drm/xe/xe_uc_debugfs.c | 2 ++
Acked-by: Lucas De Marchi
thanks
Lucas De Marchi
tree/branch:
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
branch HEAD: 5e4f84f18c4ee9b0ccdc19e39b7de41df21699dd Add linux-next specific
files for 20240424
Error/Warning reports:
https://lore.kernel.org/oe-kbuild-all/202404242144.8931hnhx-...@intel.com
https
[AMD Official Use Only - General]
Is it okay to drop below static function and just implement the logic in poison
creation handler leveraging the ras query api: amdgpu_ras_query_error_status.
It seems to me the static function may not be able to be used for other IP
blocks.
Regards,
Hawking
+
[AMD Official Use Only - General]
The patch is Reviewed-by: Hawking Zhang
Kevin, Thomas,
Alternatively, we need to explore the opportunity to centralize legacy ras and
aca ras implementation in the same API. Take sysfs create/remove interface for
example, legacy RAS and ACA RAS do share the s
[AMD Official Use Only - General]
+void amdgpu_amdkfd_ras_pasid_poison_consumption_handler(struct amdgpu_device
*adev,
+ enum amdgpu_ras_block block, uint16_t pasid,
+ pasid_notify pasid_fn, void *data, uint32_t reset);
So we ultimately switch to above
[AMD Official Use Only - General]
I might lose some context here. Can you please elaborate why we don't leverage
the existing umc_v12_0_convert_error_address implementation?
Regards,
Hawking
-Original Message-
From: Chai, Thomas
Sent: Thursday, April 18, 2024 10:58
To: amd-gfx@lists.fr
[AMD Official Use Only - General]
-
Best Regards,
Thomas
-Original Message-
From: Zhang, Hawking
Sent: Thursday, April 25, 2024 11:01 AM
To: Chai, Thomas ; amd-gfx@lists.freedesktop.org
Cc: Zhou1, Tao ; Li, Candice ; Wang,
Yang(Kevin) ; Yang, Stanley
Subject: RE: [PATCH
[AMD Official Use Only - General]
>> Alternatively, we need to explore the opportunity to centralize legacy ras
>> and aca ras implementation in the same API. Take sysfs create/remove
>> interface for example, legacy RAS and ACA RAS do share the same logic, just
>> have different filesystem nod
[AMD Official Use Only - General]
amdgpu_umc_fill_error_record is called in umc_v12_0_convert_error_address
directly to prepare for page retirement,
The new path need to check if these converted pages already exist before
filling the error page, umc_v12_0_convert_error_address is not suitable
[AMD Official Use Only - General]
OK, I will do this.
-
Best Regards,
Thomas
-Original Message-
From: Zhang, Hawking
Sent: Thursday, April 25, 2024 10:33 AM
To: Chai, Thomas ; amd-gfx@lists.freedesktop.org
Cc: Chai, Thomas ; Zhou1, Tao ; Li,
Candice ; Wang, Yang(Kevin)
From: Tim Huang
Clear resource leak warning that when the prepare fails,
the allocated amdgpu job object will never be released.
Signed-off-by: Tim Huang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_v
From: Tim Huang
Clear warning that cast operation might have overflowed.
Signed-off-by: Tim Huang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_r
Am 24.04.24 um 18:56 schrieb Friedrich Vock:
Make each buffer object aware of whether it has been evicted or not.
That reverts some changes we made a couple of years ago.
In general the idea is that eviction isn't something we need to reverse
in TTM.
Rather the driver gives the desired plac
Am 24.04.24 um 18:56 schrieb Friedrich Vock:
When undoing evictions because of decreased memory pressure, it makes no
sense to try evicting other buffers.
That duplicates some functionality.
If a driver doesn't want eviction to happen it just needs to mark the
desired placements as non-evicta
Converting size from size_t to int may overflow.
Signed-off-by: Jesse Zhang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
index f5
Am 24.04.24 um 18:56 schrieb Friedrich Vock:
We will never try evicting things from VRAM for these resources anyway.
This affects TTM buffer uneviction logic, which would otherwise try to
move these buffers into VRAM (clashing with VRAM-only allocations).
You are working on outdated code. That
Am 24.04.24 um 18:57 schrieb Friedrich Vock:
This adds GTT to the "preferred domains" of this buffer object, which
will also prevent any attempts at moving the buffer back to VRAM if
there is space. If VRAM is full, GTT will already be chosen as a
fallback.
Big NAK to that one, this is mandator
Am 24.04.24 um 18:57 schrieb Friedrich Vock:
This makes buffer eviction significantly more stable by avoiding
ping-ponging caused by low-priority buffers evicting high-priority
buffers and vice versa.
And creates a deny of service for the whole system by fork() bombing.
This is another very bi
Am 24.04.24 um 18:57 schrieb Friedrich Vock:
Used to dynamically adjust priorities of buffers at runtime, to react to
changes in memory pressure/usage patterns.
And another big NAK. TTM priorities are meant to be static based on in
kernel decisions which are not exposed to userspace.
In othe
Am 24.04.24 um 18:57 schrieb Friedrich Vock:
Used by userspace to adjust buffer priorities in response to changes in
application demand and memory pressure.
Yeah, that was discussed over and over again. One big design criteria is
that we can't have global priorities from userspace!
The backg
The function gfx_v9_4_3_init_microcode in gfx_v9_4_3.c was generating
about potential truncation of output when using the snprintf function.
The issue was due to the size of the buffer 'ucode_prefix' being too
small to accommodate the maximum possible length of the string being
written into it.
Th
Am 24.04.24 um 18:56 schrieb Friedrich Vock:
TTM now takes care of moving buffers to the best possible domain.
Yeah, I've been planning to do this for a while as well. The problem is
really that we need to keep the functionality.
For example TTM currently doesn't have a concept of an userspa
Am 25.04.24 um 05:33 schrieb Tim Huang:
From: Tim Huang
Clear resource leak warning that when the prepare fails,
the allocated amdgpu job object will never be released.
Signed-off-by: Tim Huang
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm_sdma.c | 5 +
1 f
Am 25.04.24 um 07:27 schrieb Tim Huang:
From: Tim Huang
Clear warning that cast operation might have overflowed.
Signed-off-by: Tim Huang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ring.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_r
Am 25.04.24 um 08:20 schrieb Jesse Zhang:
Converting size from size_t to int may overflow.
Signed-off-by: Jesse Zhang
---
drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_debugfs.c
b/driver
On 25.04.24 08:32, Christian König wrote:
Am 24.04.24 um 18:57 schrieb Friedrich Vock:
Used by userspace to adjust buffer priorities in response to changes in
application demand and memory pressure.
Yeah, that was discussed over and over again. One big design criteria
is that we can't have glo
In general: Yes please :)
But are exercising a lot of ideas we have already thrown over board over
the years.
The general idea Marek and I have been working on for a while now is
rather to make TTM aware of userspace "clients".
In other words we should start with having a TTM structure in t
[AMD Official Use Only - General]
-Original Message-
From: Koenig, Christian
Sent: Thursday, April 25, 2024 2:45 PM
To: Huang, Tim ; amd-gfx@lists.freedesktop.org
Cc: Deucher, Alexander
Subject: Re: [PATCH] drm/amdgpu: fix overflowed array index read warning
Am 25.04.24 um 07:27 schrieb
Am 25.04.24 um 08:46 schrieb Friedrich Vock:
On 25.04.24 08:32, Christian König wrote:
Am 24.04.24 um 18:57 schrieb Friedrich Vock:
Used by userspace to adjust buffer priorities in response to changes in
application demand and memory pressure.
Yeah, that was discussed over and over again. One
101 - 159 of 159 matches
Mail list logo
