Why has to offer "/dev/drv/render128" fd when running ROCm demo?
曹子龙
gainerying at 163.com
Sat Mar 9 07:27:42 UTC 2024
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> wrote:
[Public]
No such situation exists. there is always a rendernode.
Alex
From: 曹子龙 <gainerying at 163.com>
Sent: Wednesday, March 6, 2024 12:25 AM
To: amd-gfx at lists.freedesktop.org <amd-gfx at lists.freedesktop.org>
Cc: Deucher, Alexander <Alexander.Deucher at amd.com>; Yat Sin, David <David.YatSin at amd.com>; Kuehling, Felix <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> 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, instead of writing separately to different maintainers.
Regards,
Felix
From: Deucher, Alexander <Alexander.Deucher at amd.com>
Sent: Tuesday, March 5, 2024 3:17 PM
To:曹子龙 <gainerying at 163.com>; Kuehling, Felix <Felix.Kuehling at amd.com>; Yat Sin, David <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>
Sent: Tuesday, March 5, 2024 8:46 AM
To: Deucher, Alexander <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/20240309/c36936e9/attachment-0001.htm>
More information about the amd-gfx
mailing list