On AArch64 we also noticed problems with HSA_SVM due to virtual address
limitations on our GPUs. Basically we can only use 47-bit virtual
addresses for user mode pointers. AArch64 uses 48 bit pointers with 4KB
pages and even more with 64KB pages.
It should be possible to work around that with
urrently in the process of deprecating the KFD IOCTLs and either
>>> using
>> the existing DRM render node ones or coming up with new IOCTL/additions to
>> the
>> existing ones.
>> I really meant to convey this to justify using drm documentation as the
>>
caller to reflect this.
>
> The rest of the kernel patches required to enable CRIU can be
> found at
> https://lore.kernel.org/dri-devel/20250617194536.538681-1-david.fran...@amd.com/
>
> v2 - Move documentation to UAPI headers
> v3 - Always return 0 on success
>
> Signed-of
On 2025-07-09 02:51, Han Gao wrote:
KFD has been confirmed that can run on LoongArch systems.
It's necessary to support CONFIG_HSA_AMD on LoongArch.
Signed-off-by: Han Gao
Thank you. I'm applying this patch to amd-staging-drm-next.
Reviewed-by: Felix Kuehling
---
Cha
On 2025-07-05 04:05, Han Gao wrote:
KFD has been confirmed that can run on LoongArch systems.
It's necessary to support CONFIG_HSA_AMD on LoongArch.
Signed-off-by: Han Gao
---
drivers/gpu/drm/amd/amdkfd/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/d
On 2025-06-19 14:37, Francis, David wrote:
>
> [AMD Official Use Only - AMD Internal Distribution Only]
>
>
> > > + spin_lock(&filp->table_lock);
> > > + idr_for_each_entry(&filp->object_idr, gobj, id)
> > > + num_bos += 1;
> > > + spin_unlock(&filp->table_lock);
> > > +
> >
On 2025-06-17 15:45, David Francis wrote:
> Add new ioctl DRM_IOCTL_AMDGPU_CRIU_BO_INFO.
>
> This ioctl returns a list of bos with their handles, sizes,
> and flags and domains.
>
> This ioctl is meant to be used during CRIU checkpoint and
> provide information needed to reconstruct the bos
> in
On 2025-06-17 15:45, David Francis wrote:
The kfd CRIU checkpoint ioctl would return an error if trying
to checkpoint a process with no kfd buffer objects.
This is a normal case and should not be an error.
Signed-off-by: David Francis
This patch is
Reviewed-by: Felix Kuehling
On 2025-06-17 15:45, David Francis wrote:
CRIU restore of drm buffer objects requires the ability to create
or import a buffer object with a specific gem handle.
Add new drm ioctl DRM_IOCTL_GEM_CHANGE_HANDLE, which takes
the gem handle of an object and moves that object to a
specified new gem ha
On 2025-06-09 5:36, francisco_flynn wrote:
> HMM device memory is allocated at the top of
> iomem_resource, when iomem_resource is larger than
> GPU device's dma mask, after devm_memremap_pages,
> max_pfn will also be update and exceed device's
> dma mask, when there are multiple card on system
>
Sorry for the delay. I merged the patch to amd-staging-drm-next.
Regards,
Felix
On 2025-05-28 22:25, liu.xuem...@zte.com.cn wrote:
> From: Xuemei Liu
>
> KFD has been confirmed that can run on RISCV systems. It's necessary to
> support CONFIG_HSA_AMD on RISCV.
>
> Signed-off-by: Xuemei Liu
>
drey Vatoropin
Sorry about the long delay. I just applied this patch to amd-staging-drm-next.
Regards,
Felix
> ---
> v1 -> v2: also change return type of svm_range_get_info() per Felix Kuehling
> suggestion
> v2 -> v3: deleted extra code in the function kfd_criu
On 2025-04-26 21:25, liu.son...@zte.com.cn wrote:
From: Xuemei Liu
KFD has been confirmed that can run on RISCV systems. It's necessary to
support CONFIG_HSA_AMD on RISCV.
Is there a public user mode branch with any changes needed to make ROCm
user mode work with RISCV?
One more question i
return type of "void". The
caller of the function svm_range_get_info() does not need a return value.
Delete extra code.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Signed-off-by: Andrey Vatoropin
---
v1 -> v2: also change return type of svm_range_get_info() per F
On 2025-03-25 3:09, Ваторопин Андрей wrote:
> From: Andrey Vatoropin
>
> Static analysis shows that pointer "svms" cannot be NULL because it points
> to the object "struct svm_range_list".
>
> Remove the extra NULL check. It is meaningless and harms the readability
> of the code.
>
> Found by Linu
On 2025-03-19 03:02, Daisuke Matsuda (Fujitsu) wrote:
On Tue, Mar 18, 2025 5:35 AM Felix Kuehling wrote:
On 2025-03-17 15:07, Deucher, Alexander wrote:
[Public]
-Original Message-
From: Daisuke Matsuda
Sent: Thursday, March 13, 2025 9:18 PM
To: amd-...@lists.freedesktop.org; dri
On 2025-03-17 15:07, Deucher, Alexander wrote:
> [Public]
>
>> -Original Message-
>> From: Daisuke Matsuda
>> Sent: Thursday, March 13, 2025 9:18 PM
>> To: amd-...@lists.freedesktop.org; dri-devel@lists.freedesktop.org; Deucher,
>> Alexander ; Koenig, Christian
>>
>> Cc: airl...@gmail.c
On 2025-03-05 16:08, Salah Triki wrote:
Replace (un)register_chrdev() by (unregister/alloc)_chrdev_region() as
they are deprecated since kernel 2.6.
Where is that information coming from? I see __register_chrdev
documented in the current kernel documentation. I see no indication that
it's d
ntation to access the members and pull
> out the two specific fields.
>
> No intended functional changes.
>
> Link:
> https://www.dmtf.org/sites/default/files/standards/documents/DSP0134_3.8.0.pdf
> p99
> Signed-off-by: Mario Limonciello
Reviewed-by: Felix Kuehling
&g
On 2025-02-05 15:36, Mario Limonciello wrote:
> On 2/5/2025 14:33, Felix Kuehling wrote:
>>
>>
>> On 2025-02-05 14:31, Mario Limonciello wrote:
>>> On 2/4/2025 17:19, Felix Kuehling wrote:
>>>>
>>>> On 2025-02-04 17:21,
On 2025-02-05 14:31, Mario Limonciello wrote:
> On 2/4/2025 17:19, Felix Kuehling wrote:
>>
>> On 2025-02-04 17:21, Mario Limonciello wrote:
>>> From: Mario Limonciello
>>>
>>> find_system_memory() pulls out two fields from an SMBIOS type 17
>
On 2025-02-04 17:21, Mario Limonciello wrote:
> From: Mario Limonciello
>
> find_system_memory() pulls out two fields from an SMBIOS type 17
> device and sets them on KFD devices. This however is pulling from
> the middle of the field in the SMBIOS device and leads to an unaligned
> access.
>
27;t find any issues in testing, the series
is
Reviewed-by: Felix Kuehling
> ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 5 +-
> .../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 52 ---
> drivers/gpu/drm/amd/amdgpu/amdgpu_object.c| 38 --
>
gpu: kgd2kfd_quiesce_mm called by svm_range_evict
[ 1062.937907] amdgpu: evict_process_queues_cpsch started
On Wed, Nov 27, 2024 at 3:50 PM Felix Kuehling
wrote:
On 2024-11-27 06:51, Christian König wrote:
> Am 27.11.24 um 12:46 schrieb Mika Laitio:
>> AMD gfx1103 / M780 iGPU will cra
local variable, the original pointer
not set to NULL, this could cause use-after-free bug.
Signed-off-by: Philip Yang
Reviewed-by: Felix Kuehling
Acked-by: Christian König
Signed-off-by: Alex Deucher
Signed-off-by: Sasha Levin
Signed-off-by: Vamsi Krishna Brahmajosyula
---
drivers/gpu/drm
On 2024-11-27 06:51, Christian König wrote:
Am 27.11.24 um 12:46 schrieb Mika Laitio:
AMD gfx1103 / M780 iGPU will crash eventually when used for
pytorch ML/AI operations on rocm sdk stack. After kernel error
the application exits on error and linux desktop can itself
sometimes either freeze o
ack SDMA utilization per process")
> Signed-off-by: Yuan Can
Thank you. The patch is
Reviewed-by: Felix Kuehling
I am submitting it to amd-staging-drm-next.
Regards,
Felix
> ---
> drivers/gpu/drm/amd/amdkfd/kfd_process.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 d
On 2024-09-27 10:37, Thomas Zimmermann wrote:
With the next DRM client coming soon (drm_log) and most of DRM's
fbdev emulation consolidated in a few places, it's time to provide
a single place for the clients.
The new module drm_client_lib.ko stores most of the common client
code. It's designe
On 2024-09-24 12:42, Matthew Brost wrote:
> On Tue, Sep 24, 2024 at 01:48:29PM +0200, Simona Vetter wrote:
>> On Fri, Sep 20, 2024 at 09:59:51PM +, Matthew Brost wrote:
>>> On Fri, Sep 20, 2024 at 05:50:10PM -0400, Felix Kuehling wrote:
>>>>
>>>>
On 2024-09-20 17:23, Matthew Brost wrote:
On Fri, Sep 20, 2024 at 04:26:50PM -0400, Felix Kuehling wrote:
On 2024-09-18 11:10, Alistair Popple wrote:
Matthew Brost writes:
On Wed, Sep 11, 2024 at 02:53:31PM +1000, Alistair Popple wrote:
Matthew Brost writes:
I haven't seen the sa
Cc: Philip Yang
Cc: Felix Kuehling
Cc: Christian König
Cc: Andrew Morton
Suggessted-by: Simona Vetter
Signed-off-by: Matthew Brost
---
mm/memory.c | 13 +++---
mm/migrate_device.c | 60 +++--
2 files changed, 50 insertions(+), 23 deleti
d the descriptor table while
we'd been going through that song and dance.
Switch kfd_mem_export_dmabuf() to using drm_gem_prime_handle_to_dmabuf()
and leave the descriptor table alone...
Signed-off-by: Al Viro
This patch is
Reviewed-by: Felix Kuehling
---
drivers/gpu/drm/
On 2024-07-09 22:38, 周春明(日月) wrote:
--
发件人：Felix Kuehling
发送时间：2024年7月10日(星期三) 01:07
收件人：周春明(日月) ; Tvrtko Ursulin
; dri-devel@lists.freedesktop.org
; amd-...@lists.freedesktop.org
; Dave Airlie ;
Daniel Vetter ; criu
抄 送
On 2024-07-09 5:30, 周春明(日月) wrote:
>
>
>
>
>
>
> --
> 发件人：Felix Kuehling
> 发送时间：2024年7月9日(星期二) 06:40
> 收件人：周春明(日月) ; Tvrtko Ursulin
> ; dri-devel@lists.freedesktop.org
> ; amd-...@li
oduction for that?
Hi David,
This refers to the SVM API that has been in the upstream driver for a while
now:
https://elixir.bootlin.com/linux/v6.9.8/source/include/uapi/linux/kfd_ioctl.h#L732
Regards,
Felix
>
> Thanks,
> -David
>
> ---
On 2024-06-05 05:14, Christian König wrote:
Am 04.06.24 um 20:08 schrieb Felix Kuehling:
On 2024-06-03 22:13, Al Viro wrote:
Using drm_gem_prime_handle_to_fd() to set dmabuf up and insert it into
descriptor table, only to have it looked up by file descriptor and
remove it from descriptor
i Jul 28 12:20:12 2023 -0400
drm/amdkfd: drop IOMMUv2 support
Now that we use the dGPU path for all APUs, drop the
IOMMUv2 support.
v2: drop the now unused queue manager functions for gfx7/8 APUs
Reviewed-by: Felix Kuehling
Acked-by: Christian König
Tested-by:
elper
and leave the descriptor table alone.
Signed-off-by: Al Viro
This patch looks good to me on the amdgpu side. For the DRM side I'm
adding dri-devel.
Acked-by: Felix Kuehling
---
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
b/drivers/gpu/drm/amd/amdgpu/amdgpu_
On 2024-05-07 07:58, Thomas Zimmermann wrote:
Implement struct drm_client_funcs with the respective helpers and
remove the custom code from the emulation. The generic helpers are
equivalent in functionality.
Signed-off-by: Thomas Zimmermann
---
drivers/gpu/drm/radeon/radeon_fbdev.c | 66 ++-
On 2024-04-16 10:04, Tvrtko Ursulin wrote:
>
> 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:
>&
oid calling dma_fence_signal and dma_fence_put with zero fences to rely
on checking parameters in DMA API.
Cc: Alex Deucher
Cc: Christian Koenig
Cc: Xiaogang Chen
Cc: Felix Kuehling
Signed-off-by: Vitaly Prosyak
---
drivers/gpu/drm/amd/amdkfd/kfd_process.c | 10 ++
1 file changed, 6 inser
On 2024-04-15 10:08, Christian König wrote:
Am 15.04.24 um 15:53 schrieb Felix Kuehling:
On 2024-04-15 9:48, Christian König wrote:
From: Christian König
We only pool write combined and uncached allocations because they
require extra overhead on allocation and release.
If we also pool
On 2024-04-15 9:48, Christian König wrote:
From: Christian König
We only pool write combined and uncached allocations because they
require extra overhead on allocation and release.
If we also pool cached NUMA it not only means some extra unnecessary
overhead, but also that under memory pressur
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 thought while browsing around the amdgpu CRIU
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 support being compiled in and
/dev/kfd present
ably going to be at least a few weeks.
Regards,
Felix
Regards,
Tvrtko
On 15/03/2024 18:36, Tvrtko Ursulin wrote:
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
On 2024-03-15 7:37, Christian Göttsche wrote:
Use the new added capable_any function in appropriate cases, where a
task is required to have any of two capabilities.
Reorder CAP_SYS_ADMIN last.
Signed-off-by: Christian Göttsche
Acked-by: Alexander Gordeev (s390 portion)
Acked-by: Felix
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 for ROCm application once they
start relying on
On 2024-03-11 11:14, Sasha Levin wrote:
From: Prike Liang
[ Upstream commit c671ec01311b4744b377f98b0b4c6d033fe569b3 ]
Currently, GPU resets can now be performed successfully on the Raven
series. While GPU reset is required for the S3 suspend abort case.
So now can enable gpu reset for S3 abor
nly memory, instead of having to be dynamically
allocated at boot time.
Cc: Greg Kroah-Hartman
Suggested-by: Greg Kroah-Hartman
Signed-off-by: Ricardo B. Marliere
The patch looks good to me. Do you want me to apply this to Alex's
amd-staging-drm-next?
Reviewed-by: Felix Kuehling
--
On 2024-01-29 14:03, Christian König wrote:
Am 29.01.24 um 18:52 schrieb Felix Kuehling:
On 2024-01-29 11:28, Christian König wrote:
Am 29.01.24 um 17:24 schrieb Felix Kuehling:
On 2024-01-29 10:33, Christian König wrote:
Am 29.01.24 um 16:03 schrieb Felix Kuehling:
On 2024-01-25 13:32
On 2024-01-29 11:28, Christian König wrote:
Am 29.01.24 um 17:24 schrieb Felix Kuehling:
On 2024-01-29 10:33, Christian König wrote:
Am 29.01.24 um 16:03 schrieb Felix Kuehling:
On 2024-01-25 13:32, Daniel Vetter wrote:
On Wed, Jan 24, 2024 at 09:33:12AM +0100, Christian König wrote:
Am
On 2024-01-29 10:33, Christian König wrote:
Am 29.01.24 um 16:03 schrieb Felix Kuehling:
On 2024-01-25 13:32, Daniel Vetter wrote:
On Wed, Jan 24, 2024 at 09:33:12AM +0100, Christian König wrote:
Am 23.01.24 um 20:37 schrieb Zeng, Oak:
[SNIP]
Yes most API are per device based.
One
On 2024-01-25 13:32, Daniel Vetter wrote:
On Wed, Jan 24, 2024 at 09:33:12AM +0100, Christian König wrote:
Am 23.01.24 um 20:37 schrieb Zeng, Oak:
[SNIP]
Yes most API are per device based.
One exception I know is actually the kfd SVM API. If you look at the svm_ioctl
function, it is per-proce
h in reality all those gpuvm shares a same virtual
address space.
See one more comment inline
*From:*Christian König
*Sent:* Wednesday, January 24, 2024 3:33 AM
*To:* Zeng, Oak ; Danilo Krummrich
; Dave Airlie ; Daniel Vetter
; Felix Kuehling
*Cc:* Welty, Brian ;
dri-devel@lists.freedeskto
On 2024-01-23 5:21, Dan Carpenter wrote:
Hello Felix Kuehling,
The patch 1819200166ce: "drm/amdkfd: Export DMABufs from KFD using
GEM handles" from Aug 24, 2023 (linux-next), leads to the following
Smatch static checker warning:
drivers/dma-buf/dma-buf.c:729 dma_buf_get()
On 2024-01-23 14:37, Zeng, Oak wrote:
Thanks Christian. I have some comment inline below.
Danilo, can you also take a look and give your feedback? Thanks.
Sorry, just catching up with this thread now. I'm also not familiar with
drm_gpuvm.
Some general observations based on my experience wit
ection via ras_ctrl debugfs
Charlene Liu (1):
drm/amd/display: Update z8 latency
Dafna Hirschfeld (1):
drm/amdkfd: fixes for HMM mem allocation
Daniel Miess (1):
Revert "drm/amd/display: Fix conversions between bytes and KB"
Felix Kuehling (4):
drm/amdkfd:
t could be generalized later if there is interest then.
Regards,
Felix
On 2023-12-06 16: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
On 2024-01-07 08:07, Dafna Hirschfeld wrote:
Fix err return value and reset pgmap->type after checking it.
Fixes: c83dee9b6394 ("drm/amdkfd: add SPM support for SVM")
Reviewed-by: Felix Kuehling
Signed-off-by: Dafna Hirschfeld
---
v2: remove unrelated DOC fix and add 'F
/* Disable SVM support capability */
+ pgmap->type = 0;
Ooff, thanks for catching that. For the KFD driver changes you can add
Fixes: c83dee9b6394 ("drm/amdkfd: add SPM support for SVM")
Reviewed-by: Felix Kuehling
return PTR_ERR(r);
ng to set
the DRM_BUDDY_CLEARED flag.
- Remove ! from amdgpu_res_cleared(&cursor) check.
Signed-off-by: Arunpravin Paneer Selvam
Suggested-by: Christian König
Acked-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_object.c| 22 ---
.../gpu/drm/amd/amdgpu/amdgpu
On 2023-12-07 13:02, Alex Deucher wrote:
Show buffers as shared if they are shared via dma-buf as well
(e.g., shared with v4l or some other subsystem).
You can add KFD to that list. With the in-progress CUDA11 VM changes and
improved interop between KFD and render nodes, sharing DMABufs betwee
On 2023-12-13 9:20, Christian König wrote:
Am 12.12.23 um 00:32 schrieb Felix Kuehling:
On 2023-12-11 04:50, Christian König wrote:
Am 08.12.23 um 20:53 schrieb Alex Deucher:
[SNIP]
You also need a functionality which resets all cleared blocks to
uncleared after suspend/resume.
No idea how
On 2023-12-11 04:50, Christian König wrote:
Am 08.12.23 um 20:53 schrieb Alex Deucher:
[SNIP]
You also need a functionality which resets all cleared blocks to
uncleared after suspend/resume.
No idea how to do this, maybe Alex knows of hand.
Since the buffers are cleared on creation, is ther
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 why we are doing this, and outlining some
of the problems
to 6.6.
Cheers,
Felix
Alex
Thanks,
Felix
On 2023-12-01 18:34, Felix Kuehling wrote:
This reverts commit 71a7974ac7019afeec105a54447ae1dc7216cbb3.
These helper functions are needed for KFD to export and import DMABufs
the right way without duplicating the tracking of DMABufs associated
w
Felix
On 2023-12-01 18:34, Felix Kuehling wrote:
This reverts commit 71a7974ac7019afeec105a54447ae1dc7216cbb3.
These helper functions are needed for KFD to export and import DMABufs
the right way without duplicating the tracking of DMABufs associated with
GEM objects while ensuring that move not
Use drm_gem_prime_fd_to_handle to import DMABufs for interop. This
ensures that a GEM handle is created on import and that obj->dma_buf
will be set and remain set as long as the object is imported into KFD.
Signed-off-by: Felix Kuehling
Reviewed-by: Ramesh Errabolu
Reviewed-by: Xiaogang.C
Create GEM handles for exporting DMABufs using GEM-Prime APIs. The GEM
handles are created in a drm_client_dev context to avoid exposing them
in user mode contexts through a DMABuf import.
Signed-off-by: Felix Kuehling
Reviewed-by: Ramesh Errabolu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
VM. Revalidation after evictions is handled
in the VM code.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 3 +
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 45 ---
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c| 6 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_bu
This is not strictly a change in the IOCTL API. This version bump is meant
to indicate to user mode the presence of a number of changes and fixes
that enable the management of VA mappings in compute VMs using the GEM_VA
ioctl for DMABufs exported from KFD.
Signed-off-by: Felix Kuehling
Create a new VM state to track user BOs that are in the system domain.
In the next patch this will be used do conditionally re-validate them in
amdgpu_vm_handle_moved.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 17 +
drivers/gpu/drm/amd/amdgpu
: Christian König
Acked-by: Thomas Zimmermann
Acked-by: Daniel Vetter
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/drm_prime.c | 33 ++---
include/drm/drm_prime.h | 7 +++
2 files changed, 25 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm
On 2023-11-28 12:22, Alex Deucher wrote:
On Thu, Nov 23, 2023 at 6:12 PM Felix Kuehling wrote:
[+Alex]
On 2023-11-17 16:44, Felix Kuehling wrote:
This reverts commit 71a7974ac7019afeec105a54447ae1dc7216cbb3.
These helper functions are needed for KFD to export and import DMABufs
the right
[+Alex]
On 2023-11-17 16:44, Felix Kuehling wrote:
This reverts commit 71a7974ac7019afeec105a54447ae1dc7216cbb3.
These helper functions are needed for KFD to export and import DMABufs
the right way without duplicating the tracking of DMABufs associated with
GEM objects while ensuring that
R simply go back to v1 of
this patch set, which was consistent at least.
I think I'd prefer that because I don't really understand what you're
trying to achieve.
Thanks,
Felix
Best regards
Thomas
Am 22.11.23 um 00:11 schrieb Felix Kuehling:
Change drm_gem_prime_handle_to_fd
Use drm_gem_prime_fd_to_handle to import DMABufs for interop. This
ensures that a GEM handle is created on import and that obj->dma_buf
will be set and remain set as long as the object is imported into KFD.
Signed-off-by: Felix Kuehling
Reviewed-by: Ramesh Errabolu
Reviewed-by: Xiaogang.C
: Christian König
CC: Thomas Zimmermann
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/drm_prime.c | 33 ++---
include/drm/drm_prime.h | 7 +++
2 files changed, 25 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm
Create GEM handles for exporting DMABufs using GEM-Prime APIs. The GEM
handles are created in a drm_client_dev context to avoid exposing them
in user mode contexts through a DMABuf import.
Signed-off-by: Felix Kuehling
Reviewed-by: Ramesh Errabolu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
Change drm_gem_prime_handle_to_fd to drm_gem_prime_handle_to_dmabuf to
export a dmabuf without creating an FD as a user mode handle. This is
more useful for users in kernel mode.
Suggested-by: Thomas Zimmermann
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/drm_prime.c | 63
the stack when inlining which can blow up the stack.
Cc: Arnd Bergmann
Acked-by: Arnd Bergmann
Reviewed-by: Felix Kuehling
Acked-by: Christian König
Signed-off-by: Alex Deucher
commit 1f3b515578a1d73926993629a06a7f3b60535b59
Author: Alex Deucher
Date: Thu Sep 21
On 2023-11-20 11:02, Thomas Zimmermann wrote:
Hi Christian
Am 20.11.23 um 16:22 schrieb Christian König:
Am 20.11.23 um 16:18 schrieb Thomas Zimmermann:
Hi
Am 20.11.23 um 16:06 schrieb Felix Kuehling:
On 2023-11-20 6:54, Thomas Zimmermann wrote:
Hi
Am 17.11.23 um 22:44 schrieb Felix
On 2023-11-20 6:54, Thomas Zimmermann wrote:
Hi
Am 17.11.23 um 22:44 schrieb Felix Kuehling:
This reverts commit 71a7974ac7019afeec105a54447ae1dc7216cbb3.
These helper functions are needed for KFD to export and import DMABufs
the right way without duplicating the tracking of DMABufs
Use drm_gem_prime_fd_to_handle to import DMABufs for interop. This
ensures that a GEM handle is created on import and that obj->dma_buf
will be set and remain set as long as the object is imported into KFD.
Signed-off-by: Felix Kuehling
Reviewed-by: Ramesh Errabolu
Reviewed-by: Xiaogang.C
Create GEM handles for exporting DMABufs using GEM-Prime APIs. The GEM
handles are created in a drm_client_dev context to avoid exposing them
in user mode contexts through a DMABuf import.
Signed-off-by: Felix Kuehling
Reviewed-by: Ramesh Errabolu
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c
: Christian König
CC: Thomas Zimmermann
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/drm_prime.c | 33 ++---
include/drm/drm_prime.h | 7 +++
2 files changed, 25 insertions(+), 15 deletions(-)
diff --git a/drivers/gpu/drm/drm_prime.c b/drivers/gpu/drm
On 2023-11-07 11:58, Felix Kuehling wrote:
Create GEM handles for exporting DMABufs using GEM-Prime APIs. The GEM
handles are created in a drm_client_dev context to avoid exposing them
in user mode contexts through a DMABuf import.
This patch (and the next one) won't apply upstream be
NUMA systems (dGPU) and AMD
APU platforms such as GFXIP9.4.3.
Acked-by: Felix Kuehling
Signed-off-by: Rajneesh Bhardwaj
Reviewed-by: Christian König
Going to push this to drm-misc-next.
Hold on. Rajneesh just pointed out a WARN regression from testing. I
think the problem is that the bdev
across interconnect boundaries such
as xGMI, PCIe etc.
This change helps USWC GTT allocations on NUMA systems (dGPU) and AMD
APU platforms such as GFXIP9.4.3.
Signed-off-by: Rajneesh Bhardwaj
Acked-by: Felix Kuehling
---
drivers/gpu/drm/ttm/ttm_bo.c | 10 +-
drivers/gpu/drm/ttm
On 2023-10-17 17:13, Felix Kuehling wrote:
Let amdgpu_vm_handle_moved update all BO VA mappings of BOs reserved by
the caller. This will be useful for handling extra BO VA mappings in
KFD VMs that are managed through the render node API.
Signed-off-by: Felix Kuehling
Reviewed-by: Christian
This is not strictly a change in the IOCTL API. This version bump is meant
to indicate to user mode the presence of a number of changes and fixes
that enable the management of VA mappings in compute VMs using the GEM_VA
ioctl for DMABufs exported from KFD.
Signed-off-by: Felix Kuehling
VM. Revalidation after evictions is handled
in the VM code.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h| 3 +
.../gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c | 15 ++-
drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c| 2 +-
drivers/gpu/drm/amd/amdgpu/amdgpu_dma_bu
Let amdgpu_vm_handle_moved update all BO VA mappings of BOs reserved by
the caller. This will be useful for handling extra BO VA mappings in
KFD VMs that are managed through the render node API.
Signed-off-by: Felix Kuehling
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu
Use drm_gem_prime_fd_to_handle to import DMABufs for interop. This
ensures that a GEM handle is created on import and that obj->dma_buf
will be set and remain set as long as the object is imported into KFD.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h|
Create GEM handles for exporting DMABufs using GEM-Prime APIs. The GEM
handles are created in a drm_client_dev context to avoid exposing them
in user mode contexts through a DMABuf import.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c| 11 +++
drivers/gpu
Create a new VM state to track user BOs that are in the system domain.
In the next patch this will be used do conditionally re-validate them in
amdgpu_vm_handle_moved.
Signed-off-by: Felix Kuehling
---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 17 +
drivers/gpu/drm/amd/amdgpu
not a production use case.
Signed-off-by: Felix Kuehling
Reviewed-by: Christian König
---
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.c | 29 --
drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd.h | 5 ---
drivers/gpu/drm/amd/amdgpu/amdgpu_vm.c | 44 ++
drivers/gpu/drm/amd/a
When restoring after an eviction, use amdgpu_vm_handle_moved to update
BO VA mappings in KFD VMs that are not managed through the KFD API. This
should allow using the render node API to create more flexible memory
mappings in KFD VMs.
Signed-off-by: Felix Kuehling
Acked-by: Christian König
In amdgpu_dma_buf_move_notify reserve fences for the page table updates
in amdgpu_vm_clear_freed and amdgpu_vm_handle_moved. This fixes a BUG_ON
in dma_resv_add_fence when using SDMA for page table updates.
Signed-off-by: Felix Kuehling
Reviewed-by: Christian König
---
drivers/gpu/drm/amd
1 - 100 of 901 matches
Mail list logo
