--gpu fails with --podman #293
Comments
|
While the above is using podman rootless, I get the same black screen with rootful podman. |
|
In the log I found x11docker uses Edit: it might as well be an issue with podman. Could you try with docker instead? |
|
Updating the issue with other data points:
I mistakenly called this an amd system, it's really a hybrid system running on intel/amd. On the host it uses the Intel graphics. I created an image based on the host system, same failure.
So podman rootless works with a nvidia discrete gpu, but doesn't work with an intel integrated gpu. |
|
With docker Until the |
mviereck
changed the title
|
I have a working podman rootless solution:
It renders the animation using the gpu and prints information about the gpu, instead of the software stack (llvmpipe) From
I attempted to add ´CAP_SYS_ADMIN´ but it wasn't enough. I'm unsure if it is possible to narrow down a specific privilege, but given I can use nvidia without |
Interesting, thank you! It is odd that
I assume that capabilities will make no difference. They only define what user root is allowed to do. If it works, also drop |
That didn't worked. This article discusses a few other differences, but I haven't got any other ideas. A curious thing is that Feel free to close this issue if you feel the |
I'll leave the ticket open because I consider
The intel GPU does not work even with
A useful article, thank you for the link. It also provides a command to disable selinux for the container (another than that x11docker uses). That might be worth a try: There are further options to track down the needed privileges, I'll look later again. |
It doesn't.
Closed source.
Yes, but I don't have SELinux. |
In that case there is not much left how to fix this. I tried With docker everything works well. On the nvidia machine, is the nvidia container runtime installed? |
Yup, that's the image I used.
Not the runtime (e.g. no --runtime=nvidia), but the hook from nvidia-container-toolkit instead that's triggered by the |
|
So I am running out of ideas here. |
|
I just found that there is no A very odd podman bug. Edit: I found that podman shares the device file with |
|
I guess it depends on the vendor:
Also on my systems it doesn't require container user to have {video,render} groups. I suppose it's udev/ACL rules in play on the host. |
|
This very privileged setup fails: (Covers all aspects of https://www.redhat.com/sysadmin/privileged-flag-container-engines, should replace This one works:
Odd. Here (AMD) no
Here at least the container user needs the groups. |
The article mention masked paths, a more recent release (2.1) masks To workaround the issue, no flag other than |
|
Thank you for sharing this research! So it is basically a |
|
As a workaround, x11docker now shares the device files with |
I've removed the workaround. A fix is at work at podman. |
Context: I'm troubleshooting a freezing issue with an electron app (Visual Studio Code) running as a container. I'm clueless about what the real issue might be but two things that occurred to me is the lack of gpu access and /dev/shm. I'm on a nvidia system but the same issue reproduces on an amd system.
To move forward with this, I'm using x11docker with a simpler container on the amd system, using podman rootless:
x11docker --podman --cap-default --gpu x11docker/xfce glxgearsIt renders a black screen. Without the
--gpuflag it renders correctly using a lot of cpu. On the host it renders using the gpu.The command above translates to:
I reduced it to:
It's a slightly different command, it causes some flickering on screen which takes me to reset the display manager.
Full logs
UPDATE
Solution: add the
privilegedflagx11docker --podman --cap-default --gpu -- --privileged -- x11docker/xfce glxgears -infoThe text was updated successfully, but these errors were encountered: