RFC: Migrating GNOME and KDE Snapcraft extensions to gpu-2404 userspace interface

snapcrafters
1
Index MI024
Title MI024 - Migrating GNOME and KDE Snapcraft extensions to gpu-2404 userspace interface
Status Pending Review
Authors Michał Sawicz
Type Implementation
Created 2023-03-09

Abstract

To improve the graphical snap story and work towards a streamlined graphics support in snaps, migrate the GNOME and KDE Snapcraft extensions to using the gpu-XX04 (previously graphics-coreXX) content interface.

Rationale

The GNOME and KDE extensions, along with their respective content snaps include userspace drivers (Mesa) to support GPU acceleration (both GL and video) on the standard open source graphics stacks (GBM / KMS). They rely on SnapD support to supply the Nvidia userspace to support the proprietary stack. There are a handful of problems with that approach:

  • multiplication of the userspace for each of the content snaps (gnome-*, kf6-*, gpu-XX04)
  • lack of support for Nvidia on Ubuntu Core systems
  • lack of, or difficult support for other, custom graphics stacks (ARM, Asahi / Apple Silicon)
  • maintenance/responsibility of the graphics stack is diluted between all the snaps

The Mir team has solved this problem by way of the graphics-core, now gpu-XX04, interfaces, where a separate content snap provides the, possibly platform-specific, content. This specification will define how to move the GNOME and KDE snap stacks onto that approach. The move to base: core24 makes for an ideal pivoting point, avoiding regressions in the existing stack.

This would allow for common handling of the following scenarios:

  • new hardware enablement (through hwe, asahi, … tracks for mesa-2404 following the kernel track convention, where applicable)
  • inclusion of non-free userspace (through a non-free / hwe-non-free tracks)
  • custom graphics stacks (through custom gpu-2404 provider snaps)
  • collaborative development of the GPU stack.

Specification

Desktop launchers

https://github.com/snapcore/snapcraft-desktop-integration/
https://github.com/snapcore/snapcraft-desktop-integration/tree/3944bad4ba065a2b6c005760918c226a82ed703b at the time of writing

  • remove the LD_LIBRARY_PATH additions for mesa and mesa-egl (these doesn’t exist anywhere)
  • conditionally, when building for the gpu-2404 stack:
    • skip the following exports and their additions to LD_LIBRARY_PATH:
      • LIBGL_DRIVERS_PATH
      • LIBVA_DRIVERS_PATH
      • VDPAU_DRIVER_PATH
      • __EGL_VENDOR_LIBRARY_DIRS
    • move $__NV_PRIME_RENDER_OFFLOAD handling to gpu-2404-wrapper

GNOME

The GNOME snap stack comprises of the components listed below, along with the changes necessary:

KDE

  1. The Snapcraft extension
    https://github.com/canonical/snapcraft/pull/4698
    • same as above for the GNOME extension
    • migrate to the “lightweight” command-chain
  2. The KDE Frameworks 6 SDK snap
    https://invent.kde.org/neon/snap-packaging/kf6-snap
    • remove the mesa-no-patchelf part
    • remove libwayland-client0 stage from kguiaddons, kwayland parts
  3. The KDE Qt6 SDK snap
    https://invent.kde.org/neon/snap-packaging/kde-qt6-snap/
    • remove content overlapping with gpu-2404:
      • libxcb-glx0
      • libdrm-common
      • libgl1-mesa-glx
      • libxcb-dri2-0
      • libgl1
      • libgles2-mesa
      • libxcb1
      • libxcb-randr0
      • libgbm1
      • libxcb-shm0
      • libxcb-sync1
      • libglx0
      • libx11-xcb1
      • libvulkan1
      • libxcb-render0
      • libxcb-xfixes0
      • libwayland-server0
      • libgles1
      • libxext6
  4. https://invent.kde.org/neon/snap-packaging/kf6-snap-runtime
    • use the gpu-snap provided cleanup snippet
    • use the cleaned up gpu-2404 desktop launcher
    • remove the mesa part
    • remove libraries overlapping with gpu-2404:
      • libdrm-dev
      • mesa-va-drivers
      • i965-va-driver
      • intel-media-va-driver

Open questions

(1): Should a cleanup step be added to the extension, pruning the consumer snap of content expected to be found in the provider snap? There’s some precedent in Snapcraft, but is there an established approach?

(2): Should the command-chain vendored into Snapcraft be modified - or is it legacy only?

(3): What tracks for the mesa-2404 snap (some options mentioned in Rationale above) should be maintained?

Testing

Applications built using these stacks need to be selected for each of the extensions to exercise whenever either the runtime or the mesa-2404 snap receive an update. There’s existing tooling for this in the checkbox-mir snap and the certification team’s infrastructure that can be extended. Any existing testing should be amended to take this change into account.

Further Information

The graphical userspace handling is likely to move towards SnapD and / or the kernel snap (because the userspace is often tied to the kernel), but the above approach could continue to work, with the kernel snap slotting the gpu-2404 interface, exposing the userspace appropriate for the system - or SnapD supplying it to snaps implicitly. The userspace would likely follow the path of the Nvidia driver, getting installed as a kernel snap component. Details are out of scope for this specification.

Spec History and Changelog

Date Status Author(s) Comment
2024-04-18 Pending Review Michał Sawicz Resolved (2)
2024-04-19 Pending Review Michał Sawicz Introduced gpu-2404 documentation
2024-04-19 Pending Review Michał Sawicz Dropped wrapper mentions from runtime snaps
4 Likes
2

My thoughts on open questions:

  1. For KDE, yes I will add a cleanup.
  2. We are currently still using the command-chain until 24.04 I plan to break it out into a seperate repo like gnome.

I trust I don’t start this transition until we move to 2404 base? Scarlett

3

Correct, I only plan to apply this to base: core24 to give us time to rectify any issues.

Right, so it might be enough / appropriate only to do this on the external repository.

4

The GNOME side looks fine, we made gnome on core24 experimental for now (even if it still does not work as I do not believe the desktop folks have rebuilt the sdk and content snaps since the archive ABI re-shuffle)

For KDE, while kde-neon-6 on core22 uses the scripts you mention, for the core24 version, I would want the model to move to use the command-chain provided by the content snap itself.

I would prefer it is we left this to our library linter which would provide a list of unneeded libraries

Consider this legacy, or core22 and below.

I have no particular opinion on this, this might be something to discuss when getting the global connection assertion.

Will you also be trying to solve the OpenCL integration with this? There might be some snapd work though.

5

Was about to suggest that. Cool.

Based on what? I mean, how will the linter know what’s in mesa-2404 (there’s a lot)?

Not at this time, especially if it’s not an otherwise solved problem. We could introduce a revision of the gpu-2404 interface later on.