--property=DeviceAllow="/dev/dri/renderD128"
Though not exactly pretty; it solves the problem in the first post. Thanks for all the info and solution.
]]>lamarpavel wrote:You shouldn't consider steam properly castrated just because it runs in an nspawn container anyway; the access it has to your xorg server is already a security concern.
The host can run a Wayland session, I tested vkcuke which default to XWayland, it works, no idea about Steam.
I don't really know much about wayland so I can't comment on that with confidence. I would guess, though, that passing on access to the wayland server(?) to create windows also poses a security risk in terms of information bleed - just like with xorg.
lamarpavel wrote:or change how the vulkan lib (maybe the driver itself?) accesses hardware,
It seems like this is the driver (mesa).
Worth noting that I notice similar issue when running QT5 Wayland apps is systemd-container, they try to get rw access to /dev/dri/card0, and I believe these are not Vulkan (Calibe, qutebrowser with qt5-webkit backend). No such issue when those QT5 apps are using X/XWayland and I also didn't noticed this with the GTK apps I tried nor with Vulkan apps running as native Wayland clients (see).
Interesting, I'll need to try this. I've got Sasha Willems Vulkan examples running on my host but never tried them in the nspawn container because both vulkaninfo and steam already tell me they can't access Vulkan.
]]>You shouldn't consider steam properly castrated just because it runs in an nspawn container anyway; the access it has to your xorg server is already a security concern.
The host can run a Wayland session, I tested vkcuke which default to XWayland, it works, no idea about Steam.
or change how the vulkan lib (maybe the driver itself?) accesses hardware,
It seems like this is the driver (mesa).
Worth noting that I notice similar issue when running QT5 Wayland apps is systemd-container, they try to get rw access to /dev/dri/card0, and I believe these are not Vulkan (Calibe, qutebrowser with qt5-webkit backend). No such issue when those QT5 apps are using X/XWayland and I also didn't noticed this with the GTK apps I tried nor with Vulkan apps running as native Wayland clients (see).
tinywrkbee wrote:Interesting and "fair enough" indeed, when thinking about the actual implications when allowing this access to hardware.
A process running directly on the host has this access anyway, so it would be nice to be able to use a container to limit as much access as possible and bite the bullet with access that has to be given. You shouldn't consider steam properly castrated just because it runs in an nspawn container anyway; the access it has to your xorg server is already a security concern.
So what's the way forward? Wait for the virtualization to be implemented in the kernel as poettering commented, or change how the vulkan lib (maybe the driver itself?) accesses hardware, or not use an nspawn contrainer at all?
I'd dread to go back to running steam under a different user, the way I did before I started to use nspawn...
]]>Interesting and "fair enough" indeed, when thinking about the actual implications when allowing this access to hardware.
]]>You could try to run all applications inside your nspawn container on the render-node instead of the full graphics card interface.
The problem is that an application which uses Vulkan (I only tried vulkaninfo and vkcube) is trying to open the render node with O_RDWR|O_CLOEXEC flags when calling vkEnumeratePhysicalDevices, but the default behavior for systemd-nspawn is to limit access to devices by employing cgroup.
By adding the property DeviceAllow with the render node device as its value the cgroup limit is being bypassed.
I reported this upstream as I thought maybe it's not an intended behavior, but I guess I was wrong.
]]>DRI_PRIME=/dev/dri/renderD128 ...
DRI_PRIME=/dev/dri/renderD129 ...
I don't know much about xorg, though. Is it possible to start a new instance of X11 from within a systemd-container and then use that rather than relaying the $DISPLAY of the host? Or can I somehow tweak how an existing X server treats new clients?
]]>Vulkaninfo still reports the following in the container.
[gaming@gaming ~]$ vulkaninfo
==========
VULKANINFO
==========
Vulkan Instance Version: 1.1.82
/build/vulkan-tools/src/Vulkan-Tools/vulkaninfo/vulkaninfo.c:3339: failed with VK_ERROR_INITIALIZATION_FAILED
I think you may have to enable read/write permissions for the graphics card in /sys/devices and /sys/class/drm.
I've bound /dev/dri, which shows up in the container with the same permissions for card0, card1, renderD128 and renderD129. According to /dev/dri/by-path these are pci-0000:00:02.0-card etc, which are available in the container under /sys/devices/pci0000:00/0000:00:02.0/ with the same permissions (and path) as on the host. A link to /sys/class/drm is also available with the same permissions as on the host.
The only difference I could find was that /dev/dri/renderD128 (and renderD129) are associated with group 993, which is render on the host but doesn't exist in the container. I'll investigate this further as soon as I have the time.
Thanks for your help so far.
Proton is not required thing for running windows games. You can install winetricks, create new WINEPREFIX, install required dlls, including "dxvk" and freely run almost any game requiring DX10/11 you will get exactly same performance as with Steam/Proton
Yes, indeed. But the core of the issue is that no Vulkan context can be acquired from the installed drivers while in a systemd-nspawn container even though this works on the host system. Regardless of proton.
I have another container for wine (separate from the container for steam) and there the same problem exists: VK_ERROR_INITIALIZATION_FAILED