Hi Mo,
To use nvidia cards inside docker container, one has to map devices from the host to container: docker run -d -p6666:22 \ --device=/dev/nvidia0:/dev/nvidia0 \ --device=/dev/nvidiactl:/dev/nvidiactl \ --device=/dev/nvidia-modeset:/dev/nvidia-modeset \ --device=/dev/nvidia-uvm:/dev/nvidia-uvm \ --device=/dev/nvidia-uvm-tools:/dev/nvidia-uvm-tools I believe the mapping should be similar for AMD cards.
The magic incantation I use for AMD cards is:
docker run -it \
--device=/dev/dri \
--device=/dev/kfd \
--security-opt seccomp=unconfined \
--group-add video \
--group-add render
One thing to remember is that the container (schroot) user space has to match the version of host kernel module. At least nvidia-smi requires a matching version. I don't know whether ROCm requires the same.
I do all my development and testing inside docker containers with
a wide variety of ROCm versions. The interface between the kernel
module and userland is very stable. I think rocgdb might emit a
warning that it needs some newer functionality when you try to use
recent versions with older driver versions, but for most
components you would never even notice.
I've never encountered a problem related to mixing the version of rock-dkms or amdgpu-dkms installed on my host and the version of ROCm in the container. I have limited experience with the built-in kernel driver, but I would expect its interface to be at least as stable as the dkms modules.
If that's true. Then basically it requires the build machine to be Debian unstable. While our infrastructure only run with Debian stable, with at most backported packages.
I don't think there's any issue in general with a mismatch. To
me, the main question is whether Linux 5.10 is new enough to have
all the features that ROCm requires.