Hardware accelerated graphics in container with amd gpu

Incus
1

I can’t seem to get HW accelerated graphics despite passing my gpu.

    Operating System: Fedora Linux 40 (Container Image)
              Kernel: Linux 6.8.5-301.fc40.x86_64

incus config show -e dmain | grep -C 1 'type: gpu':

  mygpu:
    type: gpu

ll /dev/dri:

total 0
crw-rw----. 1 root root 226,   1 Dec 24 12:53 card1
crw-rw-rw-. 1 root root 226, 128 Dec 24 12:53 renderD128

I have a bunch of mesa stuff installed which were pulled by @cinnamon-desktop; dnf list --installed | grep mesa:

mesa-dri-drivers.x86_64                     24.1.7-1.fc40                      @updates               
mesa-filesystem.x86_64                      24.1.7-1.fc40                      @updates               
mesa-libEGL.x86_64                          24.1.7-1.fc40                      @updates               
mesa-libGL.x86_64                           24.1.7-1.fc40                      @updates               
mesa-libGLU.x86_64                          9.0.3-4.fc40                       @fedora                
mesa-libOSMesa.x86_64                       24.1.7-1.fc40                      @updates               
mesa-libgbm.x86_64                          24.1.7-1.fc40                      @updates               
mesa-libglapi.x86_64                        24.1.7-1.fc40                      @updates               
mesa-va-drivers.x86_64                      24.1.7-1.fc40                      @updates               
mesa-vulkan-drivers.x86_64                  24.1.7-1.fc40                      @updates

glxinfo -display :1001 -B output; the display is set up by NoMachine (I got the same result with xpra):

name of display: :1001
display: :1001  screen: 0
direct rendering: Yes
Extended renderer info (GLX_MESA_query_renderer):
    Vendor: Mesa (0xffffffff)
    Device: llvmpipe (LLVM 18.1.6, 256 bits) (0xffffffff)
    Version: 24.1.7
    Accelerated: no
    Video memory: 15930MB
    Unified memory: yes
    Preferred profile: core (0x1)
    Max core profile version: 4.5
    Max compat profile version: 4.5
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.2
Memory info (GL_ATI_meminfo):
    VBO free memory - total: 21 MB, largest block: 21 MB
    VBO free aux. memory - total: 14483 MB, largest block: 14483 MB
    Texture free memory - total: 21 MB, largest block: 21 MB
    Texture free aux. memory - total: 14483 MB, largest block: 14483 MB
    Renderbuffer free memory - total: 21 MB, largest block: 21 MB
    Renderbuffer free aux. memory - total: 14483 MB, largest block: 14483 MB
Memory info (GL_NVX_gpu_memory_info):
    Dedicated video memory: 4294224127 MB
    Total available memory: 4294240057 MB
    Currently available dedicated video memory: 21 MB
OpenGL vendor string: Mesa
OpenGL renderer string: llvmpipe (LLVM 18.1.6, 256 bits)
OpenGL core profile version string: 4.5 (Core Profile) Mesa 24.1.7
OpenGL core profile shading language version string: 4.50
OpenGL core profile context flags: (none)
OpenGL core profile profile mask: core profile

OpenGL version string: 4.5 (Compatibility Profile) Mesa 24.1.7
OpenGL shading language version string: 4.50
OpenGL context flags: (none)
OpenGL profile mask: compatibility profile

OpenGL ES profile version string: OpenGL ES 3.2 Mesa 24.1.7
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20

I get llvmpipe software rendering, not good.

I use X11 and Cinnamon. I honestly don’t know how NoMachine knows how to start Cinnamon but it does. grep -iR cinnamon /etc/x11 gives nothing.

Could this be an X11 issue or what?

(related but only slightly: Run Offline TTS with AMD GPU Acceleration in an Incus Container)

2

I think it’s because you didn’t tell ct which gpu to use. Here is the profile I use for igpu, but I think amd gpu will work too.
devices:
mygpu:
gid: “1000”
gputype: physical
mode: “0770”
pci: “0000:00:02.0”
type: gpu
uid: “1000”

3

Try adding GPU with GID of the video group (for Ubunty that’s 44, for Fedora I don’t know):

  mygpu:
    gid: "44"
    type: gpu

Make sure your user belongs to the video and render groups:

sudo usermod -a -G render,video $LOGNAME

Restart container and check if you see root video instead of root root in folder /dev/dri/:

ll /dev/dri/
crw-rw---- 1 root video 226,   1 gru 27 11:07 card1
crw-rw---- 1 root video 226, 128 gru 27 11:07 renderD128
4

Thanks for the feedback @catfish @qkiel
Okay so I missed out really on video & render groups, I thought they are a Ubuntu thing. So I added the gid={{video group id}} setting to the gpu profile and added my user to the video and render groups and restarted. Now I get the video group for these devices:

crw-rw----. 1 root video 226,   1 Dec 27 16:23 card1
crw-rw-rw-. 1 root video 226, 128 Dec 27 16:23 renderD128

But unfortunately still both xpra and NoMachine create screens with sw rendering. I use this command for the xpra test:
xpra start --exec-wrapper=/usr/bin/vglrun --start-child=glxspheres64 --exit-with-children ssh://dmain@dmaincomp
and then glxinfo -display :0 -B in as xpra creates them starting from 0.

switcherooctl list lists nothing. I saw Cinnamon use this tool to search for gpus.

5

nomachine said

At the moment, H.264 hardware encoding is not available when virtual desktops are running in X11 vector graphics mode (default) and it’s not supported in Linux custom sessions.

from: https://kb.nomachine.com/AR10K00706

Xpra said you need opengl=yes for hardware acceleration.

from: xpra/docs/Usage/Client-OpenGL.md at master · Xpra-org/xpra · GitHub

as switcherooctl, I’ve never heard of, don’t know how to use.

in my setting, glxinfo does say it using gpu.
gpu
now

6

“direct rendering: Yes” doesn’t mean it’s using gpu. “OpenGL renderer string” not saying “llvmpipe” for example however does.

With xpra --opengl=auto is the default which should pick it up, --opengl=yes makes no difference.

Video encoding for remote session transmission is a different story than using gpu for GL draws, window rendering of DE.

7

This is likely not an Incus issue but with the display manager (lightdm) and X. Some additional configuration is needed. Maybe the fact that I added the GPU later on, and configured it correctly even later left me in a state in which these foundational configs for the display are improperly set.

8

No luck either with a new container with proper gpu passthrough from the get-go.

9

Not too much feedback on fedora forums yet :frowning: