cant get VA-API running on docker containing running debian stretch

[DLLDev]

vainfo on host:

ibva info: VA-API version 1.14.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iHD_drv_video.so
libva info: Found init function __vaDriverInit_1_14
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.14 (libva 2.12.0)
vainfo: Driver version: Intel iHD driver for Intel(R) Gen Graphics - 22.3.1 ()

vainfo on docker container (debian stretch)

libva info: VA-API version 0.39.4
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/iris_drv_video.so
libva info: va_openDriver() returns -1
vaInitialize failed with error code -1 (unknown libva error),exit

i tried hours of experimenting with docker and x11docker without any success.
is there any way around it?
and/or is there any way to avoid the need of drivers on guest and somehow use hosts?

[mviereck]

It might be an issue with different VA-API versions.
Did you also try with an image that has the same VA-API version?
Did you enable option --gpu?
Which X server is in use?
If in doubt, use --weston-xwayland --gpu --fallback=no.

and/or is there any way to avoid the need of drivers on guest and somehow use hosts?

Likely not.

[DLLDev]

hi,
well the host is ubuntu 20/22 (tried both)
the guest is stretch, so for sure all the libraries are a way older including the VA-API.
in ubuntu 22 as you can get from my previour post:
HOST: VA-API version 1.14.0 / (wayland/x11)
GUEST: VA-API version 0.39.4 / (x11)

[mviereck]

I am running some tests yet on a debian bullseye host.
vainfo on bullseye host:

$  vainfo 
libva info: VA-API version 1.10.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/nouveau_drv_video.so
libva info: Found init function __vaDriverInit_1_10
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.10 (libva 2.10.0)
vainfo: Driver version: Mesa Gallium driver 20.3.5 for NVA5
vainfo: Supported profile and entrypoints
      VAProfileNone                   :	VAEntrypointVideoProc

If build an image with debian buster, vainfo succeeds although it has a lower vaapi version (but >= 1.0).

libva info: VA-API version 1.4.0
libva info: va_getDriverName() returns -1
libva info: User requested driver 'nouveau'
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/nouveau_drv_video.so
libva info: Found init function __vaDriverInit_1_4
libva info: va_openDriver() returns 0
vainfo: VA-API version: 1.4 (libva 2.4.0)
vainfo: Driver version: Mesa Gallium driver 18.3.6 for NVA5
vainfo: Supported profile and entrypoints
      VAProfileNone                   :	VAEntrypointVideoProc

It even succeeds with a debian stretch image:

libva info: VA-API version 0.39.4
libva info: va_getDriverName() returns -1
libva info: User requested driver 'nouveau'
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/nouveau_drv_video.so
libva info: Found init function __vaDriverInit_0_39
libva info: va_openDriver() returns 0
vainfo: VA-API version: 0.39 (libva 1.7.3)
vainfo: Driver version: mesa gallium vaapi
vainfo: Supported profile and entrypoints
      VAProfileNone                   :	VAEntrypointVideoProc

So far, different VA-API versions do not matter.
However, I found another issue. I have to set --env LIBVA_DRIVER_NAME=nouveau, otherwise it fails with

libva info: VA-API version 0.39.4
libva info: va_getDriverName() returns -1
libva error: va_getDriverName() failed with unknown libva error,driver_name=(null)
vaInitialize failed with error code -1 (unknown libva error),exit

Your issue is different, vainfo detects an intel driver on host, but it shows something different in the container output.
Please try with --env LIBVA_DRIVER_NAME=intel
If that fails, please try --env LIBVA_DRIVER_NAME=i965
Yet I've commited a fix that does this automatically if glxinfo is available.

Just to confirm: Please show me the output of glxinfo | grep 'OpenGL vendor string'. It should show intel or i965.
glxinfo is part of package mesa-utils. xdriinfo (part of x11-utils) should give the information, too.

[mviereck]

There might be even more work to do to support VAAPI and VDPAU.
If found this script for archlinux: https://gist.github.com/DDoSolitary/ce7a005f9a139e0547484508a78259f7

#!/bin/bash

unset LIBVA_DRIVER_NAME VDPAU_DRIVER DRI_PRIME

if lspci -k | grep -q -e amdgpu -e radeon; then
	export LIBVA_DRIVER_NAME=radeonsi
	export VDPAU_DRIVER=radeonsi
elif lspci -k | grep -q nouveau; then
	export LIBVA_DRIVER_NAME=nouveau
	export VDPAU_DRIVER=nouveau
fi

if lspci -k | grep -q i915; then
	if [ -z "$LIBVA_DRIVER_NAME" ]; then
		export LIBVA_DRIVER_NAME=i965
		export VDPAU_DRIVER=va_gl
	else
		export DRI_PRIME=1
	fi
fi

It covers MESA drivers for intel, amd and nouveau.
It also sets variable VDPAU_DRIVER and in one case DRI_PRIME.
It does not regard proprietary NVIDIA drivers.
It also seems that some more drivers are possible:

$ ls /usr/lib/x86_64-linux-gnu/dri | grep video
i965_drv_video.so
iHD_drv_video.so
nouveau_drv_video.so
r600_drv_video.so
radeonsi_drv_video.so

I wonder how this script might be extended to cover all possible drivers.

[mviereck]

Based on the code above and additional information in https://wiki.archlinux.org/title/Hardware_video_acceleration , I have commited this code that might cover most or even all cases:
(x11docker version: 7.1.5-beta-12)

  # support for prime-run / discrete NVIDIA card #394
  [ -n "$__NV_PRIME_RENDER_OFFLOAD" ] && store_runoption env "__NV_PRIME_RENDER_OFFLOAD=$__NV_PRIME_RENDER_OFFLOAD" && DRI_PRIME="1"
  [ -n "$__VK_LAYER_NV_optimus" ]     && store_runoption env "__VK_LAYER_NV_optimus=$__VK_LAYER_NV_optimus"         && DRI_PRIME="1"
  [ -n "$__GLX_VENDOR_LIBRARY_NAME" ] && store_runoption env "__GLX_VENDOR_LIBRARY_NAME=$__GLX_VENDOR_LIBRARY_NAME" && DRI_PRIME="1"

  # Video decoding: VA-API and VDPAU, also DRI_PRIME #443
  # Infos at https://wiki.archlinux.org/title/Hardware_video_acceleration
  lspci -k | grep -q -e amdgpu -e radeon && {
    store_runoption env "LIBVA_DRIVER_NAME=${LIBVA_DRIVER_NAME:-radeonsi}"
    store_runoption env "VDPAU_DRIVER=${VDPAU_DRIVER:-radeonsi}"
  }
  lspci -k | grep -q nouveau && {
    store_runoption env "LIBVA_DRIVER_NAME=${LIBVA_DRIVER_NAME:-nouveau}"
    store_runoption env "VDPAU_DRIVER=${VDPAU_DRIVER:-nouveau}"
  }
  lspci -k | grep -q nvidia && {
    store_runoption env "LIBVA_DRIVER_NAME=${LIBVA_DRIVER_NAME:-nvidia}" # could also be set to "vdpau"
    store_runoption env "VDPAU_DRIVER=${VDPAU_DRIVER:-nvidia}"
  }
  lspci -k | grep -q i915 && {
    [ -n "${DRI_PRIME:-}" ] && {
      store_runoption env "DRI_PRIME=${DRI_PRIME:-1}"
    } || {
      store_runoption env "LIBVA_DRIVER_NAME=${LIBVA_DRIVER_NAME:-i965}"
      store_runoption env "VDPAU_DRIVER=${VDPAU_DRIVER:-va_gl}"
    }
  }

---

The driver r600_drv_video.so in /usr/lib/x86_64-linux-gnu/dri seems to be the same as the radeonsi driver and likely does not need to be handled separately.

---

The iHD driver is a newer VA-API for intel, but works on more recent GPUs only. (https://blogs.igalia.com/vjaquez/2020/01/08/gstreamer-vaapi-1-16-and-libva-2-6-in-debian/)
x11docker defaults to the older but more reliable i965 and prints a message how to enable iHD instead:

      note "Option --gpu: Enabling VA-API intel driver i965.
  If you want to use the newer iHD intel driver instead,
  please run x11docker with '--env LIBVA_DRIVER_NAME=iHD'
  or set the variable globally with 'export LIBVA_DRIVER_NAME=iHD'.
  (VA-API serves for accelerated video decoding.)"

However, the new iHD likely supports more recent video formats.

---

@ALL: This is tested only with nouveau without prime/optimus/discrete card yet.
It would help me if you could test this with other GPUs.
If you have a discrete second GPU, please with and without DRI_PRIME=1 x11docker [...] or prime-run x11docker [...].

A Dockerfile for test runs:

FROM debian:bullseye
RUN apt-get  update
RUN apt-get install -y vainfo vdpauinfo
CMD ["sh","-c","vainfo && vdpauinfo || echo 'ERROR'"]

Please check if commands vainfo and vdpauinfo succeed with:
x11docker --gpu --fallback=no gputestimage

[DLLDev]

thank you on your efford on getting this run.
i have to do more testing to see if this actually (can) work or not.
my testing machine is an optimus notebook (nvidia/intel) and it does still not work with the latest master of x11docker.
tried it with wayland and x11 on host.
but things might just be screwed up after so much testing and modding.

im about to get three fresh pcs with non optimus / single gpu and will do testing again.

[mviereck]

my testing machine is an optimus notebook (nvidia/intel) and it does still not work with the latest master of x11docker.

x11docker currently defaults to i965 for intel, but your vainfo shows iHD.
You could try with LIBVA_DRIVER_NAME=iHD x11docker [...].

I've made a commit that checks vainfo if available and should do this automatically now.

im about to get three fresh pcs with non optimus / single gpu and will do testing again.

That is quite appreciated!

How do you enable optimus on your current system?
It would help me if you show me e.g. prime-run vainfo if you enable optimus this way.

[DLLDev]

so i did a fresh install and by using x11docker-master, vainfo works now with your bullseye docker example.
seems you did well :-)

but for me personally, it wont solve my issue...
it just dont want to work with debian stretch.

i get different kind of errors trying to use those "old" stretch drivers.
i dont believe that my issue is "still" related to x11docker to be fair.
i think the issue is that intels i965 driver just wont work anymore with actual iHD hardware.

nvidea driver is also no option as recent proprietary drivers wont work on such an old distro.
i was also not able to get it run by using nouveau and vdpau.

[mviereck]

I had a look at the packages; the iHD driver is in package intel-media-va-driver that is not available in stretch but in buster and in bullseye.
So this cannot be fixed in x11docker alone.
I see these possibilities:

• change driver on host so it uses i965 instead of iHD. (I did not check how to do so).
• try to install the buster package on stretch (sometimes such a hack works).
• Use optimus card with nouveau
• Update your image to buster or bullseye

The third way using nouveau looks most straightforward. Which issues did you have this way?
Please show me the output of:

env DRI_PRIME=1 vainfo
env DRI_PRIME=1  x11docker --gpu --fallback=no gputestimage

(Edit: removed prime-run tests because it would work for proprietary driver only.)

---

The cleanest way is likely an update of the image to at least buster. Is there a major reason not to do so?
If there is a program that cannot be installed in buster directly due to dependencies, you can run an upgrade from stretch to buster after installing the program.

[DLLDev]

so you want me to use the proprietary nvidea driver and on guest nouveau?
if i got this right i will try it asap.

im not on the device right now but the drivers are simply crashing caused by missing functions or buffer errors and so one...
i might dump some logs if you really interested.

i think we both agree that this issue is/seems fixed.
the problems i have now are not x11docker related anymore.
you sucessfully patched x11docker to get hardware acceleration run in probably all possible cases.
(i did not tried it as windows host, so i cant tell...)

that my container does not work is simply because of the lack of compatible drivers on the guest.

i have to upgrade the container, i dont think there is another chance.

as for now, thank you a lot for your time and professional work.
good job!

[mviereck]

so you want me to use the proprietary nvidea driver and on guest nouveau?
if i got this right i will try it asap.

No, I think of free nouveau driver on host and in image to use the nvidia card. (Should work. Here it works even with a stretch image.)
And I think of the free i965 intel driver on host and in image to use the intel card. (Might be difficult to use i965 on host.)

that my container does not work is simply because of the lack of compatible drivers on the guest.

I think so, too, at least for the intel card.
Using the nvidia card with nouveau should already work. If not, we can try to debug this. The part to debug would be using optimus / running x11docker with DRI_PRIME=1 x11docker [...].

as for now, thank you a lot for your time and professional work.
good job!

And thank you very much for your donation! It is quite appreciated. :-)