The gpu-2404 Snap interface

Mir Docs
1

Contents:

This document describes how to use the gpu-2404 Snap interface, what are the requirements to create a content provider snap as well as discusses the design of the interface.

The basics

Snaps are software packages that are meant to bring all of their dependencies along. But to support graphical applications, userspace drivers matching the hardware used, and sometimes the kernel, are necessary. What’s more, those drivers on some systems are not available as open source, or even at all - outside of commercial engagements. This makes it impractical, or even impossible, to have application snaps ship drivers supporting the breadth of graphics hardware available.

The long-term solution is for SnapD (the daemon managing snaps on your system) to have explicit support for this, and other hardware-specific pieces of software (kernel modules, firmware, udev rules etc.). While this is being worked on, we’ve designed a content interface that allows application snaps to use the graphics hardware by providing the userspace drivers and environment in a content snap.

This interface is an evolution of the graphics-core22 interface - if your application uses base: core22, you’ll need to rely on that, or move to the newer base. It was renamed to signify that all GPU functions, and not only graphics, are in scope; and that it’s not only applicable to Ubuntu Core installations.

Consuming the interface

This section explains how graphical application snaps can consume this interface to enable graphics acceleration. We maintain a set of helpers that are the easiest to use, but if you have specific reasons, we also detail how to consume the provided userspace in your application snap.

Using the helpers provided

The simplest way to enable your snap to consume the interface are the helpers we maintain in the gpu-snap repository.

There’s just a few things you have to do in your snap/snapcraft.yaml to make use of it:

  1. plug the gpu-2404 interface (the wrapper assumes it’s put under $SNAP/gpu):

    plugs:
  gpu-2404:
    interface: content
    target: $SNAP/gpu-2404
    default-provider: mesa-2404

  2. lay out these paths in your snap:

    layout:
  /usr/share/libdrm:
    bind: $SNAP/gpu-2404/libdrm
  /usr/share/drirc.d:
    symlink: $SNAP/gpu-2404/drirc.d

    If your app needs X11 support:

      /usr/share/X11/XErrorDB:
    symlink: $SNAP/gpu-2404/X11/XErrorDB

  3. use bin/gpu-2404-wrapper in your command-chains:

    apps:
  my-app:
    command-chain:
    - bin/gpu-2404-wrapper
    command: my-app

  4. use bin/gpu-2404-cleanup after priming any staged packages to avoid shipping any libraries already provided by the gpu-2404 providers:

    parts:
  my-app:
    stage-packages:
  # ...

  gpu-2404:
    after: [my-app]
    source: https://github.com/canonical/gpu-snap.git
    plugin: dump
    override-prime: |
      craftctl default
      ${CRAFT_PART_SRC}/bin/gpu-2404-cleanup mesa-core24 nvidia-core24
    prime:
    - bin/gpu-2404-wrapper

Your snap, when installed, will pull in the default mesa-2404 provider, which supports a wide range of hardware. It also supports Nvidia drivers installed on your host system.

Going the manual route

If, for whatever reason, you don’t want to use the helpers, here is a description of the steps you should perform in your snap:

  1. connect the gpu-2404, see above.
  2. lay out the paths, see above.
  3. wrap your apps with <target>/bin/gpu-2404-provider-wrapper. This script, coming from the provider side, is what sets up all the environment - paths to the libraries, drivers and any supporting files.
  4. remove any libraries that are provided by the content providers (see below for a list). If you need to provide your own versions of any of those, you need to make sure they are ABI-compatible with Ubuntu 24.04.

Creating a provider snap

The requirements for a snap providing the content are purposefully quite simple:

  1. include a bin/gpu-2404-provider-wrapper that sets up all the environment and executes the provided arguments, usually:
    #!/bin/sh

export VAR=value

exec "$@"
  2. it should support (include, in Ubuntu 24.04 ABI-compatible versions, and ensure the application can find them) as many of the supported API libraries (and their dependencies) as possible/applicable
  3. if your provider uses the Mesa stack:
    • provide the drirc.d content source holding the app-specific workarounds
  4. if your provider supports X11:
    • provide the X11/XErrorDB content source with the appropriate assets
  5. optionally, if there are Mir-specific workarounds required:
    • provide the mir-quirks content source, with any options needed.

The rest is left to the author of the provider snap. The default provider - mesa-2404 - is a good reference.

Multi-architecture providers

In some cases, it may be desirable to include libraries for more than one architecture. The main use case would be supporting software for legacy architectures running on newer hardware that supports the legacy architecture (e.g. i386 on amd64, armhf on arm64). The default mesa-2404 implements that for the amd64 architecture.

The requirements remain as above - your wrapper needs to extend the environment for the additional architecture supported.

Testing your provider snap

The graphics-test-tools set of utilities will help you determine how well your provider works. Install and connect it to your provider and run to see what is supported and how well:

$ sudo snap install graphics-test-tools --channel 24/stable
graphics-test-tools (24/stable) 24.04 from Canonicalâś“ installed
$ sudo snap connect graphics-test-tools:gpu-2404 <your-snap>:gpu-2404
$ graphics-test-tools.drm-info
# ...
$ graphics-test-tools.eglinfo
# ...

Refer to the documentation of the individual tools to see what the results mean.

Lists

Supported APIs

  • graphics
    • GL (libGL.so.1)
    • EGL (libEGL.so.1)
    • GLESv1 (libGLESv1_CM.so.1)
    • GLESv2 (libGLESv2.so.2)
    • DRM (libdrm.so.2)
    • Vulkan (libvulkan.so.1)
    • GBM (libgbm.so.1)
  • video acceleration
    • VA-API (libva.so.2)
      • libva-drm.so.2
      • libva-glx.so.2
      • libva-x11.so.2
      • libva-wayland.so.2
    • VDPAU (libvdpau.so.1)
  • X11 support
    • libglx0
    • libx11-6
    • libx11-xcb1
    • libxcb-dri2-0
    • libxcb-dri3-0
    • libxcb-glx0,
    • libxcb-present0
    • libxcb-shm0
    • libxcb-sync1
    • libxcb-xfixes0
    • libxcb1
    • libxext6
    • libxfixes3
    • libxshmfence1
    • libxxf86vm1
  • Wayland support
    • libwayland-client0
    • libwayland-cursor0
    • libwayland-egl1
    • libwayland-server0

Libraries shipped

The lists of files shipped by a selection of snaps is maintained in the gpu-snap repository here:

The cleanup wrapper above uses that to prune the application snap from things it will receive through the content interface.

2 Likes
2

2 posts were split to a new topic: Easy bootstrapping of snaps

3

Some media drivers used to have some settings like for Intel Media: https://github.com/intel/media-driver/wiki

and also some media frameworks like used some advanced (Intel) settings for hw acceleration…
https://jellyfin.org/docs/general/administration/hardware-acceleration/intel

4

@hifron yes, VAAPI, and the Intel media drivers, are part of this - though not kernel drivers or firmware, as those can only come from the host (classic packages on common distros, pc-kernel snap on Ubuntu Core)

Did you mean anything in particular? Anything missing in the above design?

5

vainfo and maybe vdpau, but previously glxinfo shows that some info is shown but not errors with something if not run.

For example Steam snap package had some problems but test like vainfo from snap could shown and maybe make error to journal at system startup or erroneous usage(in snap) ./application 2>error.log not empty run such tests and report also error.log to console and journal :slight_smile: and maybe make GNOME user message that if something from snap GPU is problematic if GPU snap is used by such app :slight_smile:

6

@hifron vainfo and vdpauinfo are part of Install graphics-test-tools on Linux | Snap Store (should probably rename to gpu-test-tools now). That’s the “test suite” for the GPU drivers provider snaps, if you have suggestions on what’s there, please file an issue at https://github.com/canonical/graphics-test-tools/.

Any runtime errors should be surfaced from the app consuming the interface, there’s too many possible errors to “guard” against, and it would delay application startup when things are working fine.

7

I would like to make a suggestion that usr/share/man should be completely removed, as well as usr/share/doc and usr/share/lintian.

8

/usr/share/doc contains the copyright files of the included binaries from deb packages, you definitely want to keep at least these in place.

9

Those are not part of this content interface, they’ve no bearing here. Whoever builds the provider snap needs to take care of crafting the snap appropriately.

I would say stripping unnecessary content from snaps is a generic thing, nothing specific to content snaps or this in particular.

2 Likes