Background

The Intel graphics stack is a multi-package recipe for GPU-based functionality on Intel hardware in Ubuntu. The following packages are currently included in this group:

1. intel-gmmlib
2. libva
3. libva-utils
4. intel-media-driver
5. intel-media-driver-non-free
6. level-zero
7. intel-compute-runtime
8. intel-graphics-compiler
9. onetbb
10. libvpl
11. libvpl-tools
12. onevpl-intel-gpu
13. intel-vc-intrinsics

Whenever new Intel graphics hardware is introduced, support for that hardware must be added in the kernel as well as in these userspace packages. Without these efforts, baseline functionalities like hardware encode/decode would not work on new hardware.

Since users often prefer LTS releases, these packages need periodic backporting to ensure prompt support for their new hardware at time of launch.

This update work will often be closely related to Mesa updates for HWE: https://wiki.ubuntu.com/MesaUpdates

Process

Graphics HWE package versions will be worked out with Intel for new hardware support. Partner Engineering's Intel squad will submit an SRU bug for tracking the backport to these versions.

Verification

Each major component of the stack (Compute Runtime, Media Driver, Mesa) will have test results from Parter Engineering to show that no regression happens during the version bump. Some dependencies such as level-zero and onetbb will also have tests.

Additionally, Intel and Canonical will run their own independent validation cycles to ensure that the new stack does not demonstrate any concerning behaviors not present in the current stack.

Requesting the SRU

The SRU should be done with a single process bug, instead of individual bug reports for individual bug fixes. Individual bug fixes may also be tracked/closed by the upload; however only the one process bug must have the following:

* The SRU should be requested following the the StableReleaseUpdates documented process.

* The template at the end of this document should be used and all $variables filled out. * Major changes should be called out in the SRU template, especially where changed behavior is not backwards compatible. * Any packaging changes (e.g. a dependency changes) need to be stated. * If any manual testing occurs it should also be documented. * If backwards compatibility is to be broken, this should be clearly written at the top of the bug description for the SRU, as well as in the package list with "[breaks-compat]" for the offending package. Furthermore, an email to ubuntu-release will be sent to point the release / SRU teams to the bug in order to get approval before uploading to the release's upload queue.

SRU Bug Template

Title: Backport Intel Graphics stack to enable $intelPlatform on $release

[ Impact ]

• Without backporting these versions, the graphics stack in Ubuntu would not run on $intelPlatform
• This is not backporting a single fix, nor an MRE, but backporting a later
  • version of each package for platform enablement.

• See https://wiki.ubuntu.com/IntelGraphicsUpdates for more details

[ Test Plan ]

• Intel's validation team will install all proposed version bumps and test that the graphics stack is working as expected.
• Canonical's validation team will install all proposed version bumps and test that the graphics stack is working as expected.
• Partner Engineering will run tests developed to confirm successful integration of each component and its dependencies. At minimum, these will include media driver, libvpl, mesa, compute-runtime, and level-zero testing. It will also include test runs on older platforms to show that regressions did not happen there.

[ Where problems could occur ]

• We are accepting a lot of new changes in a HWE update. On an LTS, it is likely that the version will not change between HWE updates, which means pretty substantial diffs, especially on projects as active as the media driver and compute runtime. With the bugfixes, refactors, and new features introduced in the meantime, we will likely be trading known issues for new issues. When dealing with packages like these, we could see a lot of pretty serious bugs, but we have to balance that knowledge with the knowledge that we will only promote well-tested configurations.

[ Other Info ]

Packages to update:

$packagename version $version to $release

$packagename2 version $version2 to $release

$packagename3 version $version3 to $release

...

Why not cherry-pick enablement patches?

Unfortunately, there is no HWE branch for each repo, and such an effort would require a lot of bandwidth for all of the packages listed. The larger (and most visible) projects in this list such as the media driver are heavily tested inside Intel "with their current configuration." Any departure from their existing configuration would invalidate those QA efforts. By cherry-picking enablement patches, we would likely be risking stability more than we would by taking all changes in a full update.

The smaller projects listed are dependencies of the larger projects, so full version bumps will be needed in order to meet minimum build requirements. Attempting to cherry pick patches and lowering the version requirement for build dependencies would create problems for anyone who doesn't realize we are altering package versions.