Why has to offer "/dev/drv/render128" fd when running ROCm demo?
Russell, Kent
Kent.Russell at amd.com
Mon Mar 11 15:28:54 UTC 2024
[AMD Official Use Only - General]
That flow was removed back in 5.13 timeframe, with this patch:
commit f45e6b9d03ff767ff946b6fce7ed3b004ab43ba4
Author: Felix Kuehling Felix.Kuehling at amd.com<mailto:Felix.Kuehling at amd.com>
Date: Wed Apr 7 17:30:05 2021 -0400
drm/amdkfd: Remove legacy code not acquiring VMs
ROCm user mode has acquired VMs from DRM file descriptors for as long
as it supported the upstream KFD. Legacy code to support older versions
of ROCm is not needed any more.
Signed-off-by: Felix Kuehling Felix.Kuehling at amd.com<mailto:Felix.Kuehling at amd.com>
Reviewed-by: Philip Yang Philip.Yang at amd.com<mailto:Philip.Yang at amd.com>
It was there from back in KFD’s early days, and has no longer been part of the upstream code since the 5.13 kernel. With KFD merging into amdgpu, and with ROCm using VMs from DRM FDs, there is no use case anymore where we would not use a DRM FD to get the VM.
Kent
From: amd-gfx <amd-gfx-bounces at lists.freedesktop.org> On Behalf Of ???
Sent: Saturday, March 9, 2024 2:28 AM
To: Deucher, Alexander <Alexander.Deucher at amd.com>
Cc: amd-gfx at lists.freedesktop.org; Yat Sin, David <David.YatSin at amd.com>; Kuehling, Felix <Felix.Kuehling at amd.com>
Subject: Re:Re: Re:RE: Why has to offer "/dev/drv/render128" fd when running ROCm demo?
Hi alex/guys:
No such situation exists. there is always a rendernode.
=======>
if so, why the logic in function "kfd_process_device_init_vm" has a situation that in consideration of the "drm render file" not exsists? and even im "kfd_bind_process_to_device" therea are lazy vm conetxt binding " err = kfd_process_device_init_vm(pdd, NULL);" which pass NULL pointer as drm file directly ? if so , can the another path on scenario drm_file empty "amdgpu_amdkfd_gpuvm_create_process_vm" call is redundant?
Thank you!
774 int kfd_process_device_init_vm(struct kfd_process_device *pdd,
775 ¦ struct file *drm_file)
776 {
777 struct kfd_process *p;
778 struct kfd_dev *dev;
779 int ret;
780
781 if (pdd->vm)
782 return drm_file ? -EBUSY : 0;
783
784 p = pdd->process;
785 dev = pdd->dev;
786
787 if (drm_file)
788 ret = amdgpu_amdkfd_gpuvm_acquire_process_vm(
789 dev->kgd, drm_file, p->pasid,
790 &pdd->vm, &p->kgd_process_info, &p->ef);
791 else
792 ret = amdgpu_amdkfd_gpuvm_create_process_vm(dev->kgd, p->pasid,
793 &pdd->vm, &p->kgd_process_info, &p->ef);
794 if (ret) {
795 pr_err("Failed to create process VM object\n");
796 return ret;
797 }
At 2024-03-06 22:45:13, "Deucher, Alexander" <Alexander.Deucher at amd.com<mailto:Alexander.Deucher at amd.com>> wrote:
[Public]
No such situation exists. there is always a rendernode.
Alex
________________________________
From: 曹子龙 <gainerying at 163.com<mailto:gainerying at 163.com>>
Sent: Wednesday, March 6, 2024 12:25 AM
To: amd-gfx at lists.freedesktop.org<mailto:amd-gfx at lists.freedesktop.org> <amd-gfx at lists.freedesktop.org<mailto:amd-gfx at lists.freedesktop.org>>
Cc: Deucher, Alexander <Alexander.Deucher at amd.com<mailto:Alexander.Deucher at amd.com>>; Yat Sin, David <David.YatSin at amd.com<mailto:David.YatSin at amd.com>>; Kuehling, Felix <Felix.Kuehling at amd.com<mailto:Felix.Kuehling at amd.com>>
Subject: Re:RE: Why has to offer "/dev/drv/render128" fd when running ROCm demo?
Hi felix:
Thanks for your kindly help.
i still has a question, if on a pure-compute platform, which has no /dev/dri/render node, but only with a single /dev/kfd node, how the compue scenario works since that wei have no "render" fd exists?
is such platfom(without render node) exists?
thanks for your kindly help.!
BRs
zlcao.
At 2024-03-06 04:43:30, "Kuehling, Felix" <Felix.Kuehling at amd.com<mailto:Felix.Kuehling at amd.com>> wrote:
[AMD Official Use Only - General]
I already answered this question in a reply to another email that was addressed to me:
The render nodes are used for CPU mapping of VRAM with mmap calls and an offset that identifies the BO. The render node also creates the GPU virtual address space that is used by KFD to create the GPU memory mappings. Applications that use both graphics and compute can share the same GPU virtual address space in this way.
Zlcao, in the future, this type of question may be better addressed to a mailing list such as amd-gfx at lists.freedesktop.org<mailto:amd-gfx at lists.freedesktop.org>, instead of writing separately to different maintainers.
Regards,
Felix
From: Deucher, Alexander <Alexander.Deucher at amd.com<mailto:Alexander.Deucher at amd.com>>
Sent: Tuesday, March 5, 2024 3:17 PM
To: 曹子龙 <gainerying at 163.com<mailto:gainerying at 163.com>>; Kuehling, Felix <Felix.Kuehling at amd.com<mailto:Felix.Kuehling at amd.com>>; Yat Sin, David <David.YatSin at amd.com<mailto:David.YatSin at amd.com>>
Subject: Re: Why has to offer "/dev/drv/render128" fd when running ROCm demo?
[AMD Official Use Only - General]
+ Felix, David to comment.
________________________________
From: 曹子龙 <gainerying at 163.com<mailto:gainerying at 163.com>>
Sent: Tuesday, March 5, 2024 8:46 AM
To: Deucher, Alexander <Alexander.Deucher at amd.com<mailto:Alexander.Deucher at amd.com>>
Subject: Why has to offer "/dev/drv/render128" fd when running ROCm demo?
Hi alexander.:
sorry for bother. but i really need some help to deal with my puzzle.
i am a freshman to AMD GPU Driver, NOW i am trying to write a simple demo to use "/dev/kfd" and do some vram alloc/free tests, but i found you must do the right "AMDKFD_IOC_ACQUIRE_VM" ioctl comamnd before you try GPU to do vram allocation and other things. from the kfd driver code,the pre-condition to do the right "AMDKFD_IOC_ACQUIRE_VM" is to offer a "/dev/drv/render128" fd to the parameters.
so, why need to do this? kfd is used for compute, but "/dev/dri/render128" is specify to gfx usaged, why must open the "/dev/dri/render128" during the KFD compute scenario?
thanks for your kindly help!
BRs
zlcao.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20240311/479a0dbf/attachment-0001.htm>
More information about the amd-gfx
mailing list