Opengl / vdpau support beyond core16

snapd
1

This is probably mostly of interest to @zyga-snapd and @mborzecki as domain experts.

I’m building a strictly confined, non-classic snap which needs vdpau support for video playback. I’m building against the core18 base so I get newer toolchain and libraries, thus simplifying my yaml and reducing build time.

I have a wrapper script which detects the GPU and sets the various VDPAU environment variables before launching the application. However, on launch it fails to find the VDPAU drivers, which look like they have moved between Ubuntu 16.04 and Ubuntu 18.04.

export VDPAU_DRIVER_PATH=/var/lib/snapd/lib/gl/vdpau
VDPAU_DRIVER_PATH=/var/lib/snapd/lib/gl/vdpau
exec /snap/kodi/x1/usr/lib/x86_64-linux-gnu/kodi/kodi-x11
libva info: VA-API version 1.1.0
libva info: va_getDriverName() returns 0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/nvidia_drv_video.so
libva info: va_openDriver() returns -1
Failed to open VDPAU backend libvdpau_nvidia.so: cannot open shared object file: No such file or directory

We briefly looked at the code in the snapd repo which does the magic/voodoo and it looks a bit hard-wired and fragile (being kind).

I recall a conversation on irc some months back where @zyga-snapd hand-waved doom and gloom for this stuff continuing to work.

What’s the plan for supporting opengl/vdpau/vaapi on all the GPUs going forward?

3 Likes
2

I agree that the current code is something we should undo and that we need clearly defined snaps that ship user space parts of hardware drivers so that snaps don’t have to provide that. I don’t have a design for that though as it requires some coordination and deeper understanding of the architecture of said userspace drivers.

3

Agree with @zyga-snapd here. IMO the right solution is having a nvidia snap. Having that we could go even further and also have a mesa snap which provides the latest and greatest release.

In the interim, I think we could make the whole hack even worse by adding a workaround for you.

1 Like