Am Donnerstag, dem 28.10.2021 um 15:26 +0200 schrieb Christian König:
> Just grab all fences in one go.
>
> Signed-off-by: Christian König
Reviewed-by: Lucas Stach
> ---
> drivers/gpu/drm/etnaviv/etnaviv_gem_submit.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/dr
The preferred location should be used as the migration destination
whenever it is accessible by the faulting GPU. System memory is always
accessible. Peer memory is accessible if it's in the same XGMI hive.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdkfd/kfd_svm.c | 14 +++--
Stack and heap pages tend to be shared by many small allocations.
Concurrent access by CPU and GPU is therefore likely, which can lead to
thrashing. Avoid this by setting the preferred location to system memory.
Signed-off-by: Felix Kuehling
Signed-off-by: Philip Yang
---
drivers/gpu/drm/amd/am
If some pages fail to migrate to system memory, don't update
prange->actual_loc = 0. This prevents endless CPU page faults after
partial migration failures due to contested page locks.
Migration to RAM must be complete during migrations from VRAM to VRAM and
during evictions. Implement retry and f
Right.
Alex
On Sun, Oct 31, 2021 at 11:41 PM Lazar, Lijo wrote:
>
> There are two subsystems - powerplay and swsmu. The subsystem implementation
> details are hidden from amdgpu_pm funcs. I thought Alex is talking about that.
>
> Thanks,
> Lijo
>
> From: Limonci
[Public]
Hi all,
This week this patchset was tested on the following systems:
HP Envy 360, with Ryzen 5 4500U, with the following display types: eDP 1080p
60hz, 4k 60hz (via USB-C to DP/HDMI), 1440p 144hz (via USB-C to DP/HDMI),
1680*1050 60hz (via USB-C to DP and then DP to DVI/VGA)
AMD
[AMD Official Use Only]
Hi Michel,
The problem with -ERESTARTSYS is the same half-baked atomic state with
modifications we made in the interrupted atomic check, is reused in the next
retry and fails the atomic check. What we expect in the next retry is with the
original atomic state. I am goin
On 2021-11-01 8:55 a.m., Felix Kuehling
wrote:
The preferred location should be used as the migration destination
whenever it is accessible by the faulting GPU. System memory is always
accessible. Peer memory is accessible if it's in the same XGMI hive.
Pushed to drm-misc-next
Andrey
On 2021-10-29 3:07 a.m., Christian König wrote:
Attached a patch. Give it a try please, I tested it on my side and
tried to generate the right conditions to trigger this code path by
repeatedly submitting commands while issuing GPU reset to stop the
scheduler
Previously Renoir compiler gfx target version was forced to Raven.
Update driver side for completeness.
Signed-off-by: Graham Sider
---
drivers/gpu/drm/amd/amdkfd/kfd_device.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/amdkfd/kfd_device.c
b/drivers/g
BOs need to be reserved before they are added or removed, so ensure that
they are reserved during kfd_mem_attach and kfd_mem_detach
Signed-off-by: Kent Russell
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/
kfd_mem_attach is not sharing GTT BOs correctly between processes. This
can cause kernel panics due to NULL pointers depending on which
processes hold references to specific GTT BOs. Temporarily disable this
functionality for now while a proper code refactor and proper fix is
done.
Note that since
This command corresponding to this attribute was deprecated in the PMFW
for YC so don't show a non-functional attribute.
Verify that the function has been implemented by the subsystem.
Suggested-by: Alex Deucher
Signed-off-by: Mario Limonciello
---
Changes from v1->v2:
* Change smu_get_power_p
On Mon, Nov 1, 2021 at 3:10 PM Mario Limonciello
wrote:
>
> This command corresponding to this attribute was deprecated in the PMFW
> for YC so don't show a non-functional attribute.
>
> Verify that the function has been implemented by the subsystem.
>
> Suggested-by: Alex Deucher
> Signed-off-by
BOs need to be reserved before they are added or removed, so ensure that
they are reserved during kfd_mem_attach and kfd_mem_detach
Signed-off-by: Kent Russell
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/
Am 2021-11-01 um 4:14 p.m. schrieb Kent Russell:
> BOs need to be reserved before they are added or removed, so ensure that
> they are reserved during kfd_mem_attach and kfd_mem_detach
>
> Signed-off-by: Kent Russell
Reviewed-by: Felix Kuehling
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd
Kent, the call to map has the same structure. Is it not possible to call
kfd_mem_attach after BO's are reserved?
Regards,
Ramesh
-Original Message-
From: amd-gfx On Behalf Of Felix
Kuehling
Sent: Monday, November 1, 2021 3:18 PM
To: Russell, Kent ; amd-gfx@lists.freedesktop.org
Subject
This better aligns that the caller can make a mistake with the buffer
and -EINVAL should be returned, but if the hardware doesn't support
the feature it should be -EOPNOTSUPP.
Signed-off-by: Mario Limonciello
---
Changes from v2->v3:
* New patch
drivers/gpu/drm/amd/pm/powerplay/amd_powerplay.c
Prevent possible issues from set and get being called simultaneously.
Signed-off-by: Mario Limonciello
---
Changes from v2->v3:
* New patch
drivers/gpu/drm/amd/pm/powerplay/amd_powerplay.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/amd/pm/powerplay/
This command corresponding to this attribute was deprecated in the PMFW
for YC so don't show a non-functional attribute.
Verify that the function has been implemented by the subsystem.
Suggested-by: Alex Deucher
Signed-off-by: Mario Limonciello
---
Changes from v2->v3:
* Handle powerplay to re
[AMD Official Use Only]
Hi Ramesh,
kfd_mem_attach_dmabuf would deadlock if the BO is already reserved, which is
obviously problematic.
Also, if it's AQL, we make 2 BOs, and would need to reserve each one of those
during addition, which we can't easily do if we lock outside of attach.
Kent
[Why]:
During hmm_range_fault validation calls on VRAM migrations, there could
be cases where some pages within the range could be marked as Read Only
(COW) triggering a migration back to RAM. In this case, the migration to
RAM will try to grab mutexes that have been held already before the
hmm_ran
Am 2021-11-01 um 6:04 p.m. schrieb Alex Sierra:
> [Why]:
> During hmm_range_fault validation calls on VRAM migrations,
This sounds a bit confusing. I think the hmm_range_fault is not called
from a migration, but right after a migration, in the context of a GPU
page fault handler. I would explain t
Ping.
Am 2021-09-13 um 5:23 p.m. schrieb Felix Kuehling:
> These bits are de-facto part of the uAPI, so declare them in a uAPI header.
>
> The corresponding bit-fields and enums in user mode are defined in
> https://github.com/RadeonOpenCompute/ROCT-Thunk-Interface/blob/master/include/hsakmttypes.
On Tue, Nov 02, 2021 at 02:01:17AM +0800, Sider, Graham wrote:
> Previously Renoir compiler gfx target version was forced to Raven.
> Update driver side for completeness.
>
> Signed-off-by: Graham Sider
Reviewed-by: Huang Rui
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_device.c | 2 +-
> 1 file ch
[Why]:
When we call hmm_range_fault to map memory after a migration, we don't
expect memory to be migrated again as a result of hmm_range_fault. The
driver ensures that all memory is in GPU-accessible locations so that
no migration should be needed. However, there is one corner case where
hmm_range
26 matches
Mail list logo
