AppImage: add needed VA-API libraries (Intel & AMD)

[gschintgen]

Description

Currently VA-API encoding may/will fail when the AppImage is used. This seems to be because of a mismatch between the bundled libva.so and the system's /usr/lib/*/dri/*_drv_video.so driver libraries. Since this is a rather important functionality the necessary libraries are now bundled in the AppImage itself in a relatively recent version. This PR changes the AppImage build process in order to include a recent libva version. This should fix VA-API issues for Intel and AMD based systems. I left out nouveau_drv_video.so since I'm somewhat skeptical of its encoding capabilities. (Please tell me if I'm wrong...)

I tested this PR on an older Intel-based laptop (Ubuntu 22.04, i965 driver) / on my main AMDGPU-based desktop. It's working fine for me.

Screenshot

Issues Fixed or Closed

See #2409 (but does not fix it since Flatpak is untouched)

Type of Change

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• Dependency update (updates to dependencies)
• Documentation update (changes to documentation)
• Repository update (changes to repository files, e.g. .github/...)

Checklist

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have added or updated the in code docstring/documentation-blocks for new or existing methods/components

Branch Updates

LizardByte requires that branches be up-to-date before merging. This means that after any PR is merged, this branch
must be updated before it can be merged. You must also
Allow edits from maintainers.

• I want maintainers to keep my branch updated

[ReenigneArcher]

I see the repo added, but what package is coming from here?

[gschintgen]

Thanks for asking. I added a comment giving a few more details. Here's the complete list as extracted from the CI build logs:

libwayland-server0:amd64 (1.20.0-1ubuntu0.1~kisak~f)
libwayland-bin (1.20.0-1ubuntu0.1~kisak~f)
libva2:amd64 (2.14.0-1~kisak1~f)
libglapi-mesa:amd64 (24.0.5~kisak1~f)
libvdpau1:amd64 (1.4-3build2~kisak~f)
libllvm15:amd64 (1:15.0.7-10~kisak1~f)
libwayland-egl1:amd64 (1.20.0-1ubuntu0.1~kisak~f)
libvdpau-dev:amd64 (1.4-3build2~kisak~f)
libdrm-common (2.4.120-1~kisak~f)
libwayland-client0:amd64 (1.20.0-1ubuntu0.1~kisak~f)
libdrm2:amd64 (2.4.120-1~kisak~f)
libva-drm2:amd64 (2.14.0-1~kisak1~f)
libwayland-cursor0:amd64 (1.20.0-1ubuntu0.1~kisak~f)
libva-x11-2:amd64 (2.14.0-1~kisak1~f)
libva-glx2:amd64 (2.14.0-1~kisak1~f)
libdrm-amdgpu1:amd64 (2.4.120-1~kisak~f)
libdrm-nouveau2:amd64 (2.4.120-1~kisak~f)
libgbm1:amd64 (24.0.5~kisak1~f)
libdrm-radeon1:amd64 (2.4.120-1~kisak~f)
libdrm-intel1:amd64 (2.4.120-1~kisak~f)
libgl1-mesa-dri:amd64 (24.0.5~kisak1~f)
libwayland-dev:amd64 (1.20.0-1ubuntu0.1~kisak~f)
libgbm-dev:amd64 (24.0.5~kisak1~f)
libegl-mesa0:amd64 (24.0.5~kisak1~f)
libva-wayland2:amd64 (2.14.0-1~kisak1~f)
mesa-va-drivers:amd64 (24.0.5~kisak1~f)
mesa-vdpau-drivers:amd64 (24.0.5~kisak1~f)
libdrm-dev:amd64 (2.4.120-1~kisak~f)
libglx-mesa0:amd64 (24.0.5~kisak1~f)
libva-dev:amd64 (2.14.0-1~kisak1~f)
va-driver-all:amd64 (2.14.0-1~kisak1~f)
vdpau-driver-all:amd64 (1.4-3build2~kisak~f)
libgl1-mesa-dev:amd64 (24.0.5~kisak1~f)
libegl1-mesa-dev:amd64 (24.0.5~kisak1~f)

It's quite an update over 20.04's mesa; some testing can't hurt.

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 6.80%. Comparing base (0a595dc) to head (7451cc0).

Additional details and impacted files

@@            Coverage Diff             @@
##           nightly   #2429      +/-   ##
==========================================
- Coverage     6.99%   6.80%   -0.20%     
==========================================
  Files           87      87              
  Lines        17679   17672       -7     
  Branches      8399    8399              
==========================================
- Hits          1237    1202      -35     
+ Misses       13867   13833      -34     
- Partials      2575    2637      +62     

Flag	Coverage Δ
Linux	5.34% <ø> (ø)
Windows	2.56% <ø> (ø)
macOS-12	?
macOS-13	7.91% <ø> (+0.01%)	⬆️
macOS-14	?

Flags with carried forward coverage won't be shown. Click here to find out more.

see 32 files with indirect coverage changes

[gschintgen]

I'm marking the PR as draft as long as there are unresolved issues with AMD GPUs. (See #2409 (comment))

[cgutman]

The way VA-API's backwards compatibility guarantees work is that the version of libva.so at runtime must be >= the version of libva that the driver (_drv_video.so) was compiled against. This is done via looking up a __vaDriverInit function that is decorated with the compile-time version number of VA-API.

For example, libva.so 2.19 wil look for __vaDriverInit_1_19(), then __vaDriverInit_1_18(), __vaDriverInit_1_17() and so on. So drivers built with any version equal or less than 2.19 will work, but a driver built for libva 2.20 (which only has __vaDriverInit_1_20()) will not work.

Due to this backwards compatibilty guarantee, essentially all we need to do for optimal compatibility is bundle whatever is the latest version of libva.so (currently 2.21) into the AppImage (this is also what Moonlight does). I don't think we should be bundling the _drv_video.so files because I think those have dependencies on Mesa and could break if we run them with a different version of Mesa than they were built as part of.

[gschintgen]

essentially all we need to do for optimal compatibility is bundle whatever is the latest version of libva.so (currently 2.21)

Thanks for your insightful and helpful comment! I've added changes to use the latest libva (from a PPA), but leaving out the *_drv_video.so. Let's see how it goes.

[gschintgen]

Oh well, the kisak-mesa PPA only has libva at version 2.14 instead of a more recent one. I guess for optimal support we'll have to build it ourselves. (That is if the latest versions of libva are compatible with a 4 year old distribution.)

I'll play around with it but it could take some time.

[gschintgen]

I force-pushed a new change overwriting the previous PR contents. This time we're building our own copy of the latest libva but we're using the host system's VA-API drivers. (Thanks cgutman )

On my own fork I've already tested the resulting AppImage and it is working fine on my system (cursory testing of remote desktop):

libva info: VA-API version 1.22.0
libva info: Trying to open /usr/lib/x86_64-linux-gnu/dri/radeonsi_drv_video.so
libva info: Found init function __vaDriverInit_1_14
libva info: va_openDriver() returns 0
[2024:04:23:16:54:30]: Warning: [hevc_vaapi @ 0x564a9a4d1380] Driver does not support some wanted packed headers (wanted 0xd, found 0x1).
[2024:04:23:16:54:30]: Info: 
[2024:04:23:16:54:30]: Info: // Ignore any errors mentioned above, they are not relevant. //
[2024:04:23:16:54:30]: Info: 
[2024:04:23:16:54:30]: Info: Found H.264 encoder: h264_vaapi [vaapi]
[2024:04:23:16:54:30]: Info: Found HEVC encoder: hevc_vaapi [vaapi]

[gschintgen]

I see that in the meantime the AppImage has been upgraded from Ubuntu 20.04 to 22.04. I don't think that change invalidates the logic behind this PR. I rebased to fix a minor merge conflict.

[gschintgen]

Are there any merge blockers for this PR? I think for supported distributions this should work fine and fix the initial issue. (Which I can confirm on my own system.)

The CI failures seem to be independent of the PR. For example the Analyze (cpp, ubuntu-latest) fails due to this:

/root/cuda.run      100%[===================>]   4.04G  75.3MB/s    in 55s     
terminate called after throwing an instance of 'boost::filesystem::filesystem_error'
  what():  boost::filesystem::copy_file: No space left on device: "./builds/nsight_systems/documentation/pdf/UserGuide.pdf", "/usr/nsight-systems-2022.4.2/documentation/pdf/UserGuide.pdf"

cuda is huge!?

[ReenigneArcher]

cuda is huge!?

Basically yea. GitHub modifies runners from time to time and it causes out of space failures. I tried to fix it in #2475 but it didn't work.