[SYCL] Check access to /dev/dri/renderD* in sycl-ls #19520
Conversation
This patch adds a check in sycl-ls to verify that the user has permission to access /dev/dri/renderD* device nodes, if they are present. If a device node exists but cannot be opened due to insufficient permissions (typically because the user is not in the render group), a clear warning is printed. This helps users quickly identify missing group membership as the cause of device enumeration failures, instead of silently failing and requiring time-consuming troubleshooting.
| // Check for /dev/dri/render* devices | ||
| for (int i = 128; i < 256; ++i) { | ||
| std::string path = std::string("/dev/dri/renderD") + std::to_string(i); |
There was a problem hiding this comment.
Do we know for sure that renderD directory name will have a suffix in the range 128 - 255? Any doc?
There was a problem hiding this comment.
Also, is /dev/dri/renderD[128-255] directory only used by Intel GPUs?
There was a problem hiding this comment.
It's hard to find official documentation regardin number of render nodes, but according to this comment it used to be limited to 64 (starting with D128, ..) but that condition was relaxed:
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/tree/drivers/gpu/drm/drm_drv.c#n131
So I think better to just use globbing to find existing nodes, here is the follow-up patch:
#19538
According to my understanding, /dev/dri/renderD* is used not only by intel gpu graphics driver but also, for example, for ROCM (https://rocm.docs.amd.com/projects/install-on-linux/en/latest/how-to/docker.html#restricting-gpu-access).
in this case we generate general warning in verbose mode indicating that some permissions are missing which are necessary for gpgpu offloading on some backends (intel, rocm and probably something else).
There was a problem hiding this comment.
I see. That makes sense.
This patch adds a check in sycl-ls to verify that the user has permission to access /dev/dri/renderD* device nodes, if they are present. If a device node exists but cannot be opened due to insufficient permissions (typically because the user is not in the render group), a clear warning is printed.
This helps users quickly identify missing group membership as the cause of device enumeration failures, instead of silently failing and requiring time-consuming troubleshooting.