AMD KFD驱动分析

已于 2025-02-05 15:44:11 修改
阅读量1.7k 收藏 8
点赞数 6
CC 4.0 BY-SA版权
分类专栏： GPU GPGPU 计算机系统 文章标签： linux AMDGPU
于 2024-03-03 12:50:04 首次发布
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.youkuaiyun.com/tugouxp/article/details/136429639
本文详细解释了如何通过/opendev/kfd管理多个HSA设备，涉及open_device、ioctl操作如AMDKFD_IOC_GET_PROCESS_APERTURES_NEW来获取GPUID，以及KFD与GPU上下文、VM初始化的关系，特别提到了N卡与A卡驱动的区别和KFD的使用限制。

摘要生成于 C知道 ，由 DeepSeek-R1 满血版支持， 前往体验 >

1./dev/kfd管理一组设备而并非单个设备，如果有多个HSA节点，则open kfd的上下文将会创建一个process，并打开为这个server上的所有可用的HSA节点分别创建上下文。

#include <stdio.h>
#include <unistd.h>
#include <stdlib.h>
#include <string.h>
#include <sys/wait.h>
#include <pthread.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <sys/ioctl.h>
#include <fcntl.h>
#include <stdint.h>
#include <linux/kfd_ioctl.h>

#define DEV_NAME  "/dev/kfd"
int open_device(void)
{
	int fd = -1;

	if ((fd = open(DEV_NAME, O_RDWR)) < 0) {
		perror("open device error");
		return -1;
	}

	return fd;
}

int close_device(int fd)
{
	close(fd);

	return 0;
}

int main(void)
{
	int fd, ret, i, render_fd;
	struct kfd_ioctl_get_version_args args_ver;
	struct kfd_ioctl_get_process_apertures_new_args args_devinfo;
	struct kfd_process_device_apertures *pa;
	struct kfd_ioctl_set_memory_policy_args args = {0};
	struct kfd_ioctl_acquire_vm_args args_vm;

	fd = open_device();
	if (fd < 0) {
		perror("open kfd device failure.\n");
		return -1;
	}

	render_fd = open("/dev/dri/renderD128", O_RDWR | O_CLOEXEC);
	if (fd < 0) {
		perror("open render device failure.\n");
		return -1;
	}

	ret = ioctl(fd, AMDKFD_IOC_GET_VERSION, &args_ver);
	if (ret == 0) {
		printf("kfd version major %d, minor %d.\n",
		       args_ver.major_version, args_ver.minor_version);
	}

	args_devinfo.num_of_nodes = 10;
	args_devinfo.kfd_process_device_apertures_ptr = (unsigned long)malloc(args_devinfo.num_of_nodes * sizeof(struct kfd_process_device_apertures));
	if (args_devinfo.kfd_process_device_apertures_ptr == 0) {
		perror("fail to malloc device apertures buffer.\n");
		return -1;
	}

	ret = ioctl(fd, AMDKFD_IOC_GET_PROCESS_APERTURES_NEW, &args_devinfo);
	if (ret != 0) {
		perror("fail to get process apertures.\n");
		return -1;
	}

	printf("%s line %d, args_devinfo.num_of_nodes = %d.\n", __func__, __LINE__, args_devinfo.num_of_nodes);
	pa = (struct kfd_process_device_apertures *)args_devinfo.kfd_process_device_apertures_ptr;
	for (i = 0; i < args_devinfo.num_of_nodes; i ++) {
		printf("idx %d, gpu_id 0x%x.\n"
		       "lds_base 0x%llx.\n"
		       "lds_limit 0x%llx.\n"
		       "gpuvm_base 0x%llx.\n"
		       "gpuvm_limit 0x%llx.\n"
		       "scratch_base 0x%llx.\n"
		       "scratch_limit 0x%llx.\n", i, pa[i].gpu_id, pa[i].lds_base, pa[i].lds_limit, pa[i].lds_limit, pa[i].lds_limit, pa[i].scratch_base, pa[i].scratch_limit);
	}

	args_vm.gpu_id = pa[0].gpu_id;
	args_vm.drm_fd = render_fd;
	ret = ioctl(fd, AMDKFD_IOC_ACQUIRE_VM, (void *)&args_vm);
	if (ret != 0) {
		perror("fail to get acquire vm.\n");
		return -1;
	}

	args.gpu_id = pa[0].gpu_id;
	args.default_policy = KFD_IOC_CACHE_POLICY_COHERENT;
	args.alternate_policy = KFD_IOC_CACHE_POLICY_COHERENT;
	args.alternate_aperture_base = (uintptr_t)NULL;
	args.alternate_aperture_size = 0;

	ret = ioctl(fd, AMDKFD_IOC_SET_MEMORY_POLICY, &args);
	if (ret != 0) {
		perror("fail to set memory policy.\n");
		return -1;
	}

	printf("%s line %d, kfd test success.\n", __func__, __LINE__);
	free((void *)args_devinfo.kfd_process_device_apertures_ptr);
	close_device(fd);

	return 0;
}

2.如果/dev/kfd管理多个设备，那么驱动如何确定当前系统调用下来要访问那个HSA设备呢？

方法是用户会在系统调用的参数中传入要操作的gpu_id.

3.既然如此，进行系统调用前用户应用必须首先知道有那些GPU_ID,那么应用是如何知道的呢？答案是通过ioctl AMDKFD_IOC_GET_PROCESS_APERTURES_NEW command.在UMD应用初始化GPU Context阶段，会首先调用AMDKFD_IOC_GET_PROCESS_APERTURES_NEW CMD查询当前server上可用的HSA设备，并返回GPU ID。

3.AMDGPU显存对象叫做buffer object,简称BO，BO底层基于ttm实现：

4.amdgpu_vm_bo_base_init构造了什么？

一个amdgpu_bo本身表示一段显存，它本身不带有context信息，当MAP到具体的卡上才带有了上下文信息，1个BO可以映射到多张卡，所以，一个BO可以对应多个VM，一个VM也可以对应多个BO，为了体现这种联系，可以将归属于同一个BO的VM关联到一起，对应到BO上，amdgpu_vm_bo_base_init就是做的这件事。其逆操作是amdgpu_vm_bo_rmv。

每个struct amdgpu_vm_bo_base->bo指向的是链表头的bo，方便从任意一个base bo开始查询。

KFD关键数据结构：

1.每个打开GPU的进程，无论open多少次，只创建一个kfd_process对象，也就是说，kfd_process每个对象1个。

2.一个KFD PROCESS对应1个PASID，也就是说，一个进程一个PASID。

3.多卡环境，1个open kfd，所有的HSA设备上下文一次性打开，关联到kfd_process对象，每个设备上下文对应一个从drm框架私有结构分配的amdgpu_vm对象。

2025/02/05 update:可能正是这个原因，AMDGPU进程才可以每个进程分配对应唯一的PASID，否则,按照打开设备分配PASID是比较合理的办法，如果每个设备有各自的设备节点，则PASID最好由每个设备独立管理分配，这些设备结点包括MIG虚拟化设备，这样每个进程可能在不同的设备上又不同的PASID，需要根据（进程，设备）二元对寻找PASID。也就是 pasid = f(pid, device);

4.对于多进程一样。

DRM RENDER设备每次打开分配一个VM和一个GFX域内的PASID，所以UMD每次初始化一个HSA设备，都需要打开一次RENDER节点，然后传入对应的GPUID调用KFD IOCTL，再次对VM进行初始化。

然后KFD框架会调用kfd_ioctl_acquire_vm，得到DRM分配的amdgpu_vm，然后在KFD框架中调用amdgpu_vm_init再次将VM对象初始化一遍（第一遍初始化是在open drm render设备时候amdgpu_driver_open_kms上下文里面）。具体可以查看调用amdgpu_vm_init的地方，它只有两处，一处是DRM，另一处就是KFD的acquire_vm调用链中。

Render设备可以被多次打开，每次打开，内部生成一个VM对象，每个HSA Device对应一个Render FD，也就对应一个VM，在ACQUIRE_VM的IOCTL命令中完成初始化，下图是打开两个RENDER FD，创建两个VM的调用堆栈：

# tracer: function
#
# entries-in-buffer/entries-written: 4/4   #P:12
#
#                                _-----=> irqs-off
#                               / _----=> need-resched
#                              | / _---=> hardirq/softirq
#                              || / _--=> preempt-depth
#                              ||| /     delay
#           TASK-PID     CPU#  ||||   TIMESTAMP  FUNCTION
#              | |         |   ||||      |         |
           a.out-3374    [004] ....  4711.142621: amdgpu_vm_init <-amdgpu_driver_open_kms
           a.out-3374    [004] ....  4711.142626: <stack trace>
 => amdgpu_vm_init
 => amdgpu_driver_open_kms
 => drm_file_alloc
 => drm_open
 => drm_stub_open
 => chrdev_open
 => do_dentry_open
 => vfs_open
 => path_openat
 => do_filp_open
 => do_sys_openat2
 => do_sys_open
 => __x64_sys_openat
 => do_syscall_64
 => entry_SYSCALL_64_after_hwframe
           a.out-3374    [004] ....  4711.142729: amdgpu_vm_init <-amdgpu_driver_open_kms
           a.out-3374    [004] ....  4711.142733: <stack trace>
 => amdgpu_vm_init
 => amdgpu_driver_open_kms
 => drm_file_alloc
 => drm_open
 => drm_stub_open
 => chrdev_open
 => do_dentry_open
 => vfs_open
 => path_openat
 => do_filp_open
 => do_sys_openat2
 => do_sys_open
 => __x64_sys_openat
 => do_syscall_64
 => entry_SYSCALL_64_after_hwframe
/dev/render128的作用

ROCm依赖于/dev/render128节点提供的amdgpu_vm对象，但是分析代码，貌似对/dev/render128的依赖分成两个阶段，在5.4的KFD实现中，当lazy binding VM的关键函数kfd_process_device_init_vm的第二个参数为NULL时，代表不需要/dev/render128节点文件，子子流程amdgpu_amdkfd_gpuvm_create_process_vm函数会分配amdgpu_vm对象，不依赖于drm render128 file提供的amdgpu_vm文件。

在之后的的某个版本迭代中，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，也就是说，从之后的某个版本开始，KFD必须依赖于/dev/render128提供的amdgpu_vm对象，而不再使用KFD自行分配的amdgpu_vm对象。

所以，最新的ROCm sdk, KFD对/dev/render128的需要必不可少。

经过确认，去除kfd self create vm的改动是在v5.12-rc7的开发周期提交的。

KFD Process的释放

kfd_process对象通过引用计数进行生命期控制，由于FD释放发生在进程EXIT之前，所以最后一次释放发生在do_exit的流程中调用mmu notifier kfd_process_notifier_release, 通过mmu_notifier_put->mmu_notifier_free_rcu触发RCU回调，最终在kfd_process_ref_release中调用kfd_unref_release触发引用计数归零完成释放。        

           a.out-2880    [006] ....  3357.338719: kfd_unref_process <-kfd_release
           a.out-2880    [006] ....  3357.338720: <stack trace>
 => kfd_unref_process
 => kfd_release
 => __fput
 => ____fput
 => task_work_run
 => exit_to_user_mode_prepare
 => syscall_exit_to_user_mode
 => do_syscall_64
 => entry_SYSCALL_64_after_hwframe
           a.out-2880    [006] ....  3357.338751: mmu_notifier_put <-kfd_process_notifier_release
           a.out-2880    [006] ....  3357.338753: <stack trace>
 => mmu_notifier_put
 => kfd_process_notifier_release
 => __mmu_notifier_release
 => exit_mmap
 => mmput
 => do_exit
 => do_group_exit
 => __x64_sys_exit_group
 => do_syscall_64
 => entry_SYSCALL_64_after_hwframe
     kworker/6:0-2803    [006] ....  3357.351184: kfd_process_ref_release <-kfd_process_free_notifier
     kworker/6:0-2803    [006] ....  3357.351194: <stack trace>
 => kfd_process_ref_release
 => kfd_process_free_notifier
 => mmu_notifier_free_rcu
 => srcu_invoke_callbacks
 => process_one_work
 => worker_thread
 => kthread
 => ret_from_fork
           a.out-2880    [006] ....  3357.351315: remove_vma <-exit_mmap
           a.out-2880    [006] ....  3357.351319: <stack trace>
 => remove_vma
 => exit_mmap
 => mmput
 => do_exit
 => do_group_exit
 => __x64_sys_exit_group
 => do_syscall_64
 => entry_SYSCALL_64_after_hwframe
/dev/kfd的使用限制

看下图的注释和逻辑，CHILD进程需要打开它自己的FD句柄，而不能用继承子父进程的，分析原因可能是因为KFD_PROCESS上下文的使用限制，每个进程会创建自己的KFD_PROCESS对象，但是FORK调用时，内核复制进程的时候对文件的拷贝是浅拷贝，也就是说，子进程继承自父进程的kfd设备对应的fd和父进程自身的fd指向的是同一个struct file，这样就相当于，子进程没有经过调用kfd_open创建自己的KFD_PROCESS对象的过程，也就无法用继承来的FD调用KFD的IOCTL。

如果用户态应用强行这样做，KFD_IOCTL将会返回-EBADF错误。

N卡驱动和A卡驱动的不同

HSA模式下，BO没有属主，BO在某个卡的上下文中分配，但是并不属于这张卡，而是大家一起用，当某张卡下线（RESET）时，只需要取消对BO的引用即可。

N卡是独立显卡，物理上某个BO一定位于某张卡上，在此卡的上下文中分配，并被其它卡引用，当此卡下线时，可能会存在其他卡仍然在引用这个BO的情况。

结束

AMD GPU内存管理(2)：GEM/TTM
zhang_shuaifeng的博客
01-11 2558
DRM内存管理drm_mm、GEM/TTM内存管理
Kubernetes
数字人生
04-19 848
Docker是一个开源的应用容器引擎，它的主要作用是帮助开发者打包他们的应用及其依赖项到一个可移植的容器中，并发布到任何流行的Linux或Windows机器上。这使得从研发到测试、生产能提供一致环境。Docker提供了容器化的基础，而Kubernetes则在此基础上提供了容器编排和管理的强大功能，两者共同构成了现代云原生应用的核心技术栈。总的来说，Kubernetes为容器化应用提供了高效、自动化的部署、扩展和管理能力，使得应用能够在不同的云环境和操作系统间无缝迁移，大大提高了应用的可靠性和可维护性。
amdgpu kfd TTM create GTT
努力的志 的博客
07-01 2029
AMDGPU kfd TTM 创建 GTT
AMD HSA 异构计算架构和AMD-KFD内核驱动&NVIDIA内核驱动
tugouxp的专栏
11-12 2313
AMD好像全部都开源了，听在AMD工作过的朋友讲，AMD为了开源，几乎将整个KMD代码全部重写，从这个角度看，AMD的开源热情甩NVIDIA几条街。
AMD GPU 内核驱动分析(一)总览
tugouxp的专栏
09-11 6875
和CPU相比，GPU中包含了大量的并行计算单元，适合处理像素，矩阵，坐标等大量同类型的数据，因此，很多LINUX上的应用程序为了能够利用GPU的加速功能，都试图和GPU直接打交道，因此，系统中可能有多个组件或者程序同时使用GPU，比如桌面系统中OpenGL的实现MESA。
AMDKFD 合并入 Linux 3.19 内核
weixin_33805992的博客
06-04 279
作为 AMD 开源 HSA 异构计算核心的重要部分之一的 AMDKFD 内核驱动被纳入 Linux 3.19 内核，标志着 Linux 平台上的 HSA 计算基础架构完成。 本次合并入的 amdkfd 可以理解为在 DRM 子系统中提供了 CPU 与 GPU 沟通的快速通道，使得两者可以平等的访问内存资源而无需额外拷贝。结合前端时间同样开源的 HSA D...
amdgpu kfd TTM USERPTR
努力的志 的博客
07-01 1316
amdgpu kfd TTM USERPTR
AMDGPU KFD Test 编译使用
tugouxp的专栏
03-03 730
是一个用于在ROCm软件堆栈中提供设备无关性的层。它是ROCm的一部分，允许不同的硬件平台（如AMD GPU和Intel CPU）使用相同的API进行计算。要安装现在可以开始构建和安装ernelode这将在目录下安装。可以看到编译出来了kfdtest程序。
AMD GPU 内核驱动分析(三)-gpu scheduler ring fence同步工作模型
tugouxp的专栏
10-03 2711
在Linux Kernel 的AMDGPU驱动实现中，dma-fence扮演着重要角色，AMDGPU的Render/解码操作可能涉及到多个方面同时引用buffer的情况，以渲染/视频解码场景为例，应用将渲染/解码命令写入和GPU共享的BUFFER之后，需要将任务提交给GPU的运行队列等待执行，这个时候，应用不仅要监听buffer中任务的执行情况，还要保证在任务执行完毕之前，不能再去修改BUFFER中的数据。而AMDGPU也需要排它性地执行BUFFER命令。
【linux】AMD GPU和NVIDIA GPU驱动安装
数字人生
03-31 4726
综上，根据用户对性能和特性的需求以及所使用的Linux发行版，AMD GPU的驱动在安装上可以被认为相对简便，尤其是当满足于开源驱动提供的性能时。为了充分利用显卡的高性能计算（HPC）功能，可能需要安装AMDGPU-PRO驱动，这是AMD的官方专有驱动，它提供对OpenCL和其他专用计算框架的全面支持。对于Linux用户，AMD通常提供可执行的安装文件（比如`.run`或者`.sh`文件）或者用于各个发行版的包管理格式（例如Debian的`.deb`或者RedHat的`.rpm`）。
AMD在行动：揭示应用程序跟踪和性能分析的力量
数字人生
06-10 998
我们还将使用官方AMD Docker镜像：在容器中执行性能分析任务。以下是启动容器时应用的一些设置的定义：•-it：这种`-i`和`-t`的组合允许通过终端与容器互动。•和：分别授予容器追踪系统调用和系统监控的能力。•：这些选项允许访问主机上特定的设备。`--device=/dev/kfd`与AMD GPU设备相关联，`--device=/dev/dri`与直接访问图形硬件的设备相关联。•：这个选项允许容器有必要的权限直接访问视频硬件。•：这将主机上的卷挂载到容器中。
AMD GPU虚拟化
zhang_shuaifeng的博客
01-04 2557
PCIe, IOMMU, SRIOV, VFIO, Cgroup, PF/VF, Hypervisor
基于国产加速器海光DCU&GPGPU虚拟化功能用户指南（vDCU&vGPU）
qq_27815483的博客
09-18 3732
本文主要针对vDCU 虚拟化设备插件的安装与初步使用测试进行介绍，包括物理机、容器环境与kubernetes 集群环境下vDCU 设备的使用。
UOS系统开机提示：kfd kfd:amdgpu:OLAND not supported in kfd
skw1975的专栏
12-20 3748
开机提示：kfd kfd:amdgpu:OLAND not supported in kfd。切换回console(按Ctrl+Alt+F1)，检查图形界面是否启动。先用dkms status amdgpu 查询出admgpu版本号。apt reinstall -y lightdm #此步骤需要连网。dkms remove amdgpu/版本号 --all。
AMD GPU内存管理(1)：概览
zhang_shuaifeng的博客
12-28 2200
PCIe, IOMMU/ATS, PDE/PTE, GEM/TTM, TLB invalidate, DMA_BUF, mmu_notify, HMM
ROCT内存申请、注册、映射
11-01 1565
一、总览 1. CPU DDR物理内存对应的虚拟地址全部来自于SVM aperture GPU DDR物理内存对应的虚拟地址根据芯片系列决定来自于gpuvm_aperture或SVM aperture 2. 关于CPU DDR中的userptr区域给GPU访问的原理讨论 1）userptr就是CPU已经申请的CPU DDR空间，现在要register给KFD，再映射给GPU访问 2）register memory API调用过程 (上图的所有DDR处理路径，只有regi...
Linux驱动开发系列：DRM（第十部分）
爱她就要努力
03-13 2852
DRM，全称Direct Rending Manger。是目前Linux主流的图形显示框架。相比较传统的Framebuffer，DRM更能适应现代硬件。支持GPU、3D渲染显示等。DRM可以统一管理GPU、Display驱动，使得软件架构更统一、方便开发和维护。本文只介绍Display相关内容，GPU相关的，博主也不懂，无能为力，等以后学到相关的再来更新。从模块上划分，DRM可以分为三个部分：libdrm、KMS、GEM。l图1 DRM框架。
ROCT event
03-09 452
一. linux kernel的eventfd机制 让事件飞 ——Linux eventfd 原理与实践 - 知乎 (zhihu.com)https://zhuanlan.zhihu.com/p/40572954在Linux系统中，eventfd是一个用来通知事件的文件描述符，是一种内核向用户空间的应用发送通知的机制，可以有效地被用来实现用户空间的事件/通知驱动的应用程序。 二.ROCT event的event机制 ROCT event的本质也是内核(KMD)向用户空间的应用发送通知的机制。 1
docker amd显卡直通车
最新发布
03-22
<think>好的，我现在需要帮助用户解决在Docker中配置AMD显卡加速或透传的问题。首先，我得回顾用户的问题，确保我理解正确。用户想知道如何在Docker环境中支持AMD显卡的加速或驱动配置，特别是关于GPU透传的设置。 首先，我需要回忆Docker中GPU支持的一般方法。对于NVIDIA GPU，通常使用nvidia-docker工具，但AMD的情况可能不同。AMD的GPU加速可能涉及不同的驱动和容器配置。我需要考虑AMD官方是否有对应的Docker解决方案，或者社区中有没有类似的工具。 接下来，用户提到的“GPU passthrough”通常是指在虚拟化环境中将物理GPU直接分配给虚拟机使用，但这里用户可能是指将宿主机的AMD GPU透传给Docker容器使用。这需要宿主机正确安装AMD的驱动，并在Docker运行时配置相应的设备。 然后，我需要查阅相关的资料，比如AMD的官方文档是否有关于容器中使用GPU的指南。另外，可能涉及到在Docker运行时挂载设备文件和必要的库文件。例如，NVIDIA的做法是挂载设备文件和相关的驱动库，AMD可能也需要类似的操作。 同时，用户提供的引用中有关于创建docker-registry的secret和安装docker的命令，但可能和AMD GPU配置关系不大，不过需要注意是否有相关的依赖步骤。例如，确保Docker版本和安装正确，这是基础步骤。 可能还需要考虑使用AMD的ROCm（Radeon Open Compute）平台，它支持在容器中进行GPU计算。ROCm提供了类似CUDA的异构计算环境，可能需要在容器中安装ROCm的驱动和工具链。 接下来，我需要分步骤整理配置过程：首先确保宿主机安装AMD驱动和ROCm，然后在Docker中配置设备挂载和必要的环境变量。此外，检查Docker是否需要特定的运行参数来启用GPU支持。 另外，可能需要验证配置是否正确，比如在容器内运行AMD的检测工具或简单的GPU计算任务，确认GPU是否被正确识别和使用。 还要考虑用户可能遇到的问题，比如驱动版本兼容性、权限问题（设备文件的访问权限）、以及Docker版本是否支持GPU透传等。需要提醒用户注意这些潜在问题，并提供解决建议。 最后，生成相关问题，帮助用户深入理解该主题，比如如何验证AMD GPU在容器中的使用，或者性能优化方法等。</think>要在Docker中配置AMD显卡加速或透传，需通过以下步骤实现： ### 1. 宿主机环境准备 - **安装AMD显卡驱动** 确保宿主机已正确安装AMD GPU驱动和ROCm（Radeon Open Compute）平台。例如在Ubuntu中，可通过以下命令安装： ```bash sudo apt install rocm-hip-libraries rocm-dev ``` 验证驱动状态： ```bash rocminfo # 查看GPU识别情况 ``` - **配置用户组权限** 将用户加入`video`和`render`组以访问GPU设备： ```bash sudo usermod -aG video,docker $USER ``` ### 2. Docker配置AMD GPU透传 - **挂载设备文件与库** 在运行容器时，需挂载GPU设备文件和ROCm库： ```bash docker run -it --device=/dev/kfd --device=/dev/dri/renderD128 \ -v /opt/rocm:/opt/rocm:ro --group-add=video ubuntu:22.04 ``` 参数说明： - `--device`：挂载AMD GPU设备文件 - `-v /opt/rocm`：挂载宿主机ROCm工具链到容器 - `--group-add`：赋予容器访问GPU的组权限 - **使用官方ROCm镜像** AMD提供预装ROCm的Docker镜像，可直接运行： ```bash docker run -it --device=/dev/kfd --device=/dev/dri rocm/rocm-terminal ``` ### 3. 验证容器内GPU加速 在容器内执行AMD检测命令： ```bash rocminfo | grep "Agent\|Marketing Name" # 查看GPU信息 /opt/rocm/bin/rocblas-test # 运行ROCm测试案例 ``` ### 4. 权限问题处理 若出现`Permission denied`错误，尝试： - 检查`/dev/dri/renderD*`设备权限 - 添加`--security-opt seccomp=unconfined`参数启动容器 ### 配置示例 通过Docker Compose部署： ```yaml services: amd_gpu_app: image: rocm/pytorch devices: - "/dev/kfd" - "/dev/dri/renderD128" volumes: - "/opt/rocm:/opt/rocm:ro" group_add: - "video" ```
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

papaofdoudou

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付：¥1
获取中
扫码支付

您的余额不足，请更换扫码支付或充值

打赏作者

实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值