[SRU] Intel Battlemage cards lack hardware encode support

[Shane McKee]

[ Impact ]

The Intel media driver needs a version update to fully support Battlemage in 24.4.4, and the required gmmlib version is 22.5.5. Ideally, this will get pulled back to Noble, this version bump should be backported to oracular before we file an SRU exception for HWE purposes.

PPA:
https://launchpad.net/~mckeesh/+archive/ubuntu/lp2098413

[ Test Plan ]

 * Intel performs extensive validation for the media stack internally before releasing.

 * Canonical's Intel squad (in this case, me) performs basic testing on successful media driver initialization (vainfo) as well as testing hardware encode/decode on H264, VP9, and AV1 at 1080p and 4K.

The media driver supports the following platforms:
* BDW (Broadwell)
* SKL (Skylake)
* BXTx (BXT: Broxton, APL: Apollo Lake, GLK: Gemini Lake)
* KBLx (KBL: Kaby Lake, CFL: Coffee Lake, WHL: Whiskey Lake, CML: Comet Lake, AML: Amber Lake)
* ICL (Ice Lake)
* JSL (Jasper Lake) / EHL (Elkhart Lake)
* TGLx (TGL: Tiger Lake, RKL: Rocket Lake, ADL-S/P/N: Alder Lake, RPL-S/P: Raptor Lake)
* DG1/SG1
* Alchemist(DG2)/ATSM
* MTLx (MTL: Meteor Lake, ARL-S/H: Arrow Lake)
* LNL (Lunar Lake)
* BMG (Battlemage)

Intel tests for regressions on supported hardware prior to releasing a new version, but we have tested the versions in the PPA on the following Intel generations:
* Battlemage
* Lunar Lake
* Raptor Lake
* Alder Lake
* Tiger Lake

Once the new versions land in proposed, we will re-test on those platforms with the official package versions.

[ Where problems could occur ]

 * Issues can occur if media driver component versions mismatch. In this case, we should have gmmlib at 22.5.5, libva at 2.22.0, and the media driver (free and non-free) at 24.4.4 (LP: #2098420).

* If there is any critical bug in the media stack, there could be a fallback to software encode/decode, which is slower and more resource-intensive.

[ Other Info ]

This is dependent on the SRU request in LP: #2098420. These changes must land together to avoid compatibility issues

[Shane McKee (mckeesh)]

Oracular debdiff

[Shane McKee (mckeesh)]

Plucky debdiff

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "22.5.2_to_22.5.5_24.10.debdiff" seems to be a debdiff. The ubuntu-sponsors team has been subscribed to the bug report so that they can review and hopefully sponsor the debdiff. If the attachment isn't a patch, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are member of the ~ubuntu-sponsors, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issue please contact him.]

[Simon Quigley (tsimonq2)]

Hey Shane!

Could you please adjust the versions in the debdiffs to remove the ~ppaX suffixes and changelog entries, then resubscribe ~ubuntu-sponsors once you have updated diffs?

Thanks in advance! Please feel free to reach out if you have any questions.

[Shane McKee (mckeesh)]

Sure! Here's the new one for Oracular

[Shane McKee (mckeesh)]

And for plucky. They wouldn't both upload to the PPA without any suffixes, so I added the ~25.04

[Simon Quigley (tsimonq2)]

Hey, Shane!

Version numbers are cheap; I'd suggest something like "22.5.5-0ubuntu1" and "22.5.5-0ubuntu0.24.10.1" for your uploads.

I'm not confident enough in my ability to review the substantive parts of this patch, so I'll be leaving this in the queue for someone else to pick up.

Thanks! Feel free to join #devel:ubuntu.com on Matrix if you'd like real-time feedback here.

[Zixing Liu (liushuyu-011)]

Debian currently has 22.6.0 in unstable. Can we do a sync for Plucky (sync 22.6.0) and then an SRU for Oracular (using 22.5.5)?

[Zixing Liu (liushuyu-011)]

intel-gmmlib seems to also build on Oracular when removing the vendored spdlog in the source tarball: https://launchpad.net/~liushuyu-011/+archive/ubuntu/misc/+sourcepub/17003314/+listing-archive-extra.

I guess we can just use `uscan --download-version 22.5.5` to fetch the tarball?

[Zixing Liu (liushuyu-011)]

I have performed a sync for intel-gmmlib in Plucky to fix the intel-media-driver FTBFS in Plucky:

New changes:
intel-gmmlib (22.6.0+ds1-1) unstable; urgency=medium

  * New upstream version 22.6.0+ds1

 -- Sebastian Ramacher <email address hidden> Sat, 28 Dec 2024 13:31:31 +0100

intel-gmmlib (22.5.5+ds1-1) unstable; urgency=medium

  * New upstream version 22.5.5+ds1

 -- Sebastian Ramacher <email address hidden> Sun, 15 Dec 2024 20:50:16 +0100

intel-gmmlib (22.5.2+ds1-1) unstable; urgency=medium

  * New upstream version 22.5.2+ds1

 -- Sebastian Ramacher <email address hidden> Sun, 20 Oct 2024 12:28:33 +0200

[Simon Quigley (tsimonq2)]

For Oracular, could you please rebase the changes off of what is now in Plucky, and change the bug description to match the SRU documentation? https://documentation.ubuntu.com/sru/en/latest/

Once you're ready, please re-subscribe Ubuntu Sponsors.

Thanks!

[Zixing Liu (liushuyu-011)]

> description: updated

SRU changes LGTM. Sponsoring as version 22.5.5-0ubuntu0.24.10.1.

For SRU uploads, we use a special version numbering scheme so that if users upgrade their system to a new version, they will automatically get the newer version in the newer release instead of keeping the SRU'ed version in the older release. You can learn more about how this special version numbering scheme works here: https://github.com/canonical/ubuntu-maintainers-handbook/blob/main/VersionStrings.md#version-adding-a-change-in-ubuntu-as-a-stable-release-update.

You will need to wait for the SRU team to process this upload through the queue.

[Robie Basak (racb)]

> The Intel media driver needs a version update to fully support Battlemage in 24.4.4

In that case, please add a test for full support of Battlemage to the Test Plan. If that's the purpose of the update, then we should be testing that before release. If it doesn't work, then we'd be creating churn and risk on our users for no reason. And if it's the purpose of the update, then surely it's not burdensome to specifically test it?

If that's the sole reason for the update (it's the sole reason given at the moment, anyway), then the bug should be titled something like "Battlemage doesn't fully work" (more detail would be good; all I know right now is that you're trying to "fully support Battlemage"), with an Oracular task. We would use the same bug with individual tasks to track the status in Oracular and Noble.

> * Canonical's Intel squad performs basic testing on successful media driver initialization (vainfo) as well as testing hardware encode/decode on H264, VP9, and AV1 at 1080p and 4K.

The usual requirement is that the test plan is specified in enough detail that it can be carried out by anyone. This is useful in case of regression - to determine if the test plan needs amending for the future, and to enable any user to debug the root cause of a regression. Could you provide that level of detail of the plan, please? If that's not possible, then I think we should at least have an explanation of why that is not possible.

[Robie Basak (racb)]

See also: https://documentation.ubuntu.com/sru/en/latest/howto/common-issues/#test-plan and https://documentation.ubuntu.com/sru/en/latest/explanation/further-requirements/#detail-in-test-plans

[Shane McKee (mckeesh)]

Fair point. We have 3 layers of testing going on, one of which is repeatable for anyone reviewing this request. The first layer is from the media driver team at Intel. They use extensive internal testing before releasing new versions. The next layer is from our partner team at Intel who run their own validation cycle on versions that we are promoting. Finally, the last step is me running checkbox tests that I have developed which can be run like this:

sudo snap install --classic snapcraft
sudo snap install checkbox24
lxd init --auto
git clone https://github.com/canonical/checkbox-media
cd checkbox-media
git checkout mckees-dev
snapcraft
sudo snap install --dangerous --classic ./checkbox-media_1.0_amd64.snap
checkbox-media.install
checkbox-media.test

These tests do a couple things. First, they check vainfo output to see if there is encode and decode support for each codec. Some of these will naturally fail because the tests are not sophisticated enough to infer the intel generation and map them to the table on the media driver support table. That lookup must be done manually.

The next stage is libvpl testing. This step runs the unit tests packaged with libvpl, the newest version of which will come with libvpl-examples as a newly-added package. Since the new package isn't in the archive yet, we have to install these separately. I've been doing gmmlib and the media driver at the same time:

mkdir debs && pushd debs
wget https://launchpad.net/~mckeesh/+archive/ubuntu/lp2098420/+files/libigdgmm12_22.5.5+ds1-1_amd64.deb
wget https://launchpad.net/~mckeesh/+archive/ubuntu/lp2098420/+files/libigdgmm-dev_22.5.5+ds1-1_amd64.deb
wget https://launchpad.net/~mckeesh/+archive/ubuntu/lp2098420/+files/intel-media-va-driver_24.4.4+dfsg1-0ubuntu1_amd64.deb
wget https://launchpad.net/ubuntu/+source/libvpl/1:2.14.0-1/+build/30317579/+files/libvpl2_2.14.0-1_amd64.deb
wget https://launchpad.net/ubuntu/+source/libvpl/1:2.14.0-1/+build/30317579/+files/libvpl-dev_2.14.0-1_amd64.deb
wget https://launchpad.net/ubuntu/+source/libvpl/1:2.14.0-1/+build/30317579/+files/libvpl-examples_2.14.0-1_amd64.deb
sudo dpkg -i *.deb
popd

The last type of test is an ffmpeg test. We run encode and decode operations with LIBVA_TRACE enabled, then grep the trace output files for the correct entrypoint (https://github.com/intel/libva/blob/3da1ba7e3cac635c6dc4d5d4cd1234d386926b49/va/va.h#L551) for the operation we are performing and the correct profile (https://github.com/intel/libva/blob/3da1ba7e3cac635c6dc4d5d4cd1234d386926b49/va/va.h#L502) for the codec. This test ensures that we are getting the hardware acceleration that we are requesting.

To be clear, not all of the tests pass, but there are no test regressions when upgrading from 24.3.4 media driver + 22.5.2 gmmlib to 24.4.4 + 22.5.5 across the platforms I tested.

As far as Battlemage enablement goes, the release notes for 24.4.4 call out BMG encoding enablement:
https://github.com/intel/media-driver/releases/tag/intel-media-24.4.4

Our partner team at Intel ran their own validation to confirm this.

[Shane McKee (mckeesh)]

If this sounds agreeable, can we also submit the media driver (free and non-free) 24.4.4, since they are being tested as part of the same stack?

[Robie Basak (racb)]

> Since the new package isn't in the archive yet, we have to install these separately.

Please *do not* install these from a PPA for the purposes of SRU verification. If this is necessary then you're not really testing what would land in the SRU, and there is no real justification for a hardware enablement in Ubuntu that requires software from third party sources (in that case the entire enablement could just be done in those third party sources, with no need for an SRU).

This does mean that you need to get the *entire* SRU uploaded into proposed at once, so that they can all be tested together. The expectation is that the *entire* enablement is performed in proposed before being released to updates all together.

I haven't finished reviewing your comment above - that will take some time to go through carefully - but I hope this immediate feedback is useful.

From https://documentation.ubuntu.com/sru/en/latest/howto/common-issues/#test-plan:

> The Test Plan or verification only tested part of the user story that we are fixing with a series of SRUs. In this case, we expect all packages in proposed and verification of the entire user story at once. E.g. a hardware enablement needs to be done across three packages. This avoids iteration in the stable release.

[Shane McKee (mckeesh)]

> If this is necessary then you're not really testing what would land in the SRU, and there is no real justification for a hardware enablement in Ubuntu that requires software from third party sources (in that case the entire enablement could just be done in those third party sources, with no need for an SRU).

I'm not sure what you mean here. I'm installing the version bumped packages that would be going into the SRU so that I can test against them to make sure they all function together. I don't have the power to put packages into proposed, and it doesn't seem like anyone adds those new versions to proposed unless I prove thorough testing of the stack to show that it's fit for upload. If you add the requested versions to proposed, I'd be happy to test those versions. If we want everything out of the PPA, I'll add libvpl 2.14.0 to this request as well

[Robie Basak (racb)]

The bug title is much better - thanks. The test plan you describe in comment 15 is much better, but I think there are a couple of things still needed, please. Since this is hardware specific, what matrix of hardware are you intending to test? For example, if using ffmpeg, then are you testing both with and without the relevant hardware to ensure that behaviour for those without this hardware is not regressed? Or would that not make a useful test, and if so, why?

> To be clear, not all of the tests pass, but there are no test regressions when upgrading from 24.3.4 media driver + 22.5.2 gmmlib to 24.4.4 + 22.5.5 across the platforms I tested.

I think that's fine, but then it should be part of the documented test plan as to how to validate that there are no test regressions please.

> I'm not sure what you mean here. I'm installing the version bumped packages that would be going into the SRU so that I can test against them to make sure they all function together. I don't have the power to put packages into proposed, and it doesn't seem like anyone adds those new versions to proposed unless I prove thorough testing of the stack to show that it's fit for upload. If you add the requested versions to proposed, I'd be happy to test those versions. If we want everything out of the PPA, I'll add libvpl 2.14.0 to this request as well

I do expect you have done some testing of the stack to show that it's good for upload, but that's not what I'm reviewing for here. I'm reviewing what testing you intend to do of the final built proposed binaries that will be released, and that requires that you test using binaries that are either already shipped by Ubuntu or will be released as part of this update.

> If you add the requested versions to proposed, I'd be happy to test those versions. If we want everything out of the PPA, I'll add libvpl 2.14.0 to this request as well

This one, but note that the SRU reviewer (me) is not the person who uploads the packages to the archive (your sponsor). Please see https://canonical-sru-docs.readthedocs-hosted.com/en/latest/explanation/roles/ for the distinction. The SRU requirement is that you have a user impact statement ("Intel Battlemage cards lack hardware encode support" is good, albeit a little inverted), that you propose an SRU of multiple packages as required to fix that user impact, the test plan uses only those packages and not external sources so that we can validate the final binaries that will land, and then we execute on that once the plan is accepted and the upload accepted and built into proposed.

I hope that explains things. Please ask your sponsor for further help as needed.

[Zixing Liu (liushuyu-011)]

> I'm not sure what you mean here. I'm installing the version bumped packages that would be going into the SRU so that I can test against them to make sure they all function together. I don't have the power to put packages into proposed, and it doesn't seem like anyone adds those new versions to proposed unless I prove thorough testing of the stack to show that it's fit for upload. If you add the requested versions to proposed, I'd be happy to test those versions. If we want everything out of the PPA, I'll add libvpl 2.14.0 to this request as well

Hi Shane,

Please post a merge proposal or a patch (you can use the Plucky one as the base) to libvpl so I can sponsor it. If you need more packages sponsored/backported to get intel-gmmlib functional/testable, please also communicate with me and your SRU reviewer (Robie in this case).

Thanks

[Shane McKee (mckeesh)]

Debdiff for libvpl

[Shane McKee (mckeesh)]

Debdiff for onevpl-intel gpu

[Shane McKee (mckeesh)]

Debdiff for libvpl-tools

[Shane McKee (mckeesh)]

> Since this is hardware specific, what matrix of hardware are you intending to test? For example, if using ffmpeg, then are you testing both with and without the relevant hardware to ensure that behaviour for those without this hardware is not regressed?

My current hardware testing is on TGL, ADL, RPL, LNL, and BMG. So I do test a few generations back as well as on the hardware specifically being enabled. If you're talking about testing on a whole other vendor, I would say that this would not be a useful test because the tests were only developed with Intel's media stack in mind. The other vendor would have had to implement everything exactly the same, down to libva trace log formatting.

> I think that's fine, but then it should be part of the documented test plan as to how to validate that there are no test regressions please.

Sure. I just run the tests on the old package versions, upgrade only the packages being tested, and re-run the tests. Then I look at each failure to make sure that it was not passing on the old (current) version.

ACK on the rest, thanks for the explanation. I'll re-run the tests again once the packages (hopefully) get submitted to proposed.

[Zixing Liu (liushuyu-011)]

Hi Shane,

> libvpl_2.13.0_to_2.14.0.debdiff Edit (6.7 MiB, text/plain)

I think you accidentally mixed up the files from onevpl and libvpl. Also, you can post a link to your PPA build if a package is not in the archive.

> libvpl-tools-1.2.0_to_1.3.0.debdiff Edit (118.9 KiB, text/plain)

According to the SRU policy, the version number is incorrect. I suggest using version "1.3.0-0ubuntu0.24.10.1".

> onevpl_intel_gpu_24.3.4_to_24.4.4.debdiff Edit (267.9 KiB, text/plain)

According to the SRU policy, the version number is incorrect. I suggest using version "24.4.4-0ubuntu0.24.10.1".

After you address the issues, you can subscribe "ubuntu-sponsors" to this bug for another review. Thanks!

[Shane McKee (mckeesh)]

Hi Zixing,

libvpl has replaced onevpl in Debian to better align with the upstream source name:
https://salsa.debian.org/debian/libvpl/-/commit/28d19b094625a29ca0e6fd5dde5b42de6c2edc28

I'll upload the debdiffs with the versions changed as you suggested, thanks!

[Shane McKee (mckeesh)]

Updated the name for libvpl

[Shane McKee (mckeesh)]

Updated name for onevpl-intel-gpu

[Shane McKee (mckeesh)]

Updated name for libvpl-tools

[Zixing Liu (liushuyu-011)]

Hi Shane,

> libvpl-tools-1.2.0_to_1.3.0_v2.debdiff Edit (119.6 KiB, text/plain)
>
> Updated name for libvpl-tools

Do you also want to update libvpl-tools to 1.3.0 in Plucky (currently at 1.2.0)?

> onevpl_intel_gpu_24.3.4_to_24.4.4_v2.debdiff Edit (267.9 KiB, text/plain)
>
> Updated name for onevpl-intel-gpu

Sponsored. I have modified the changelog entry as "Backport new upstream release 24.4.4 to Oracular."

Do you also want to update libvpl-tools to 25.1.2 (currently at 24.3.4) in Plucky? 25.1.2 is the version currently available in Debian testing.

> libvpl_2.13.0_to_2.14.0_v2.debdiff Edit (6.7 MiB, text/plain)
>
> Updated the name for libvpl

Sponsored now. I have modified your changelog to "Backport to Oracular" to reflect the real upload intent.

If you want to replace the onevpl source package, you must file a removal request (see https://wiki.ubuntu.com/StableReleaseUpdates/ProposalRemoves; if wiki does not work, here is a backup: https://archive.md/ak6WM) for onevpl (only for Oracular in this case).

[Timo Aaltonen (tjaalton)]

libvpl shouldn't be backported as-is, but with the old source name, and since it's based on -1 the backported version should carry it too

the uploaded onevpl-intel-gpu was newer than what was in plucky so it was too early to sponsor, but I synced a newer version to plucky..

didn't look at the rest yet but really, the devel series should be sorted *before* pushing stuff to the SRU queue!

[Timo Aaltonen (tjaalton)]

Also, the libvpl sync didn't have a bug ref here, and neither did onevpl-intel-gpu. The sponsor should check for these...

[Shane McKee (mckeesh)]

Updated libvpl to use the old onevpl name since this is a backport. Also added the LP bug reference in the changelog and changed to the -1 debian number

[Shane McKee (mckeesh)]

Thanks Timo for syncing the plucky version. I added the bug reference in the changelog and updated the message to reflect what Zixing changed it to.

[Shane McKee (mckeesh)]

Thanks Timo for syncing Plucky for libvpl-tools. Changed the changelog language to specify the backport language we have been using

[Timo Aaltonen (tjaalton)]

plucky has 22.6.0+ds1-1

[Dave Jones (waveform)]

Looking at this as part of my patch pilot shift, I'm confused as to what (if anything?) needs uploading to plucky? If there's nothing to do for plucky, then those tasks should be marked Fix Released (or Invalid as appropriate). The most recent batch of debdiffs appear to be for oracular, but without knowing if devel is fixed I can't sponsor them (I'm also not entirely sure this qualifies as a "bug fix" given we're now past feature-freeze -- if not, this would also need FFe justification).

[Shane McKee (mckeesh)]

@waveform Nothing should be going into plucky at this point. I think those were added by mistake. I didn't think I had the authority to change them since I can't add them in the first place, but I was able to change them over to Fix Committed

[Vladimir Petko (vpa1977)]

Attaching debdiffs as an archive as the driver debdiff is extremely large (90mb).

PPA with the built packages: https://launchpad.net/~vpa1977/+archive/ubuntu/battlemage

[Vladimir Petko (vpa1977)]

Uploading to ubuntu (via ftp to upload.ubuntu.com):
  Uploading intel-gmmlib_22.5.5+ds1-0ubuntu0.24.10.1.dsc: done.
  Uploading intel-gmmlib_22.5.5+ds1.orig.tar.xz: done.
  Uploading intel-gmmlib_22.5.5+ds1-0ubuntu0.24.10.1.debian.tar.xz: done.
  Uploading intel-gmmlib_22.5.5+ds1-0ubuntu0.24.10.1_source.buildinfo: done.
  Uploading intel-gmmlib_22.5.5+ds1-0ubuntu0.24.10.1_source.changes: done.
Successfully uploaded packages.

Uploading to ubuntu (via ftp to upload.ubuntu.com):
  Uploading intel-media-driver_24.4.4+dfsg1-1ubuntu0.24.10.1.dsc: done.
  Uploading intel-media-driver_24.4.4+dfsg1.orig.tar.gz: done.
  Uploading intel-media-driver_24.4.4+dfsg1-1ubuntu0.24.10.1.debian.tar.xz: done.
  Uploading intel-media-driver_24.4.4+dfsg1-1ubuntu0.24.10.1_source.buildinfo: done.
  Uploading intel-media-driver_24.4.4+dfsg1-1ubuntu0.24.10.1_source.changes: done.
Successfully uploaded packages.

Uploading to ubuntu (via ftp to upload.ubuntu.com):
  Uploading intel-media-driver-non-free_24.4.4+ds1-1ubuntu0.24.10.1.dsc: done.
  Uploading intel-media-driver-non-free_24.4.4+ds1.orig.tar.gz: done.
  Uploading intel-media-driver-non-free_24.4.4+ds1-1ubuntu0.24.10.1.debian.tar.xz: done.
  Uploading intel-media-driver-non-free_24.4.4+ds1-1ubuntu0.24.10.1_source.buildinfo: done.
  Uploading intel-media-driver-non-free_24.4.4+ds1-1ubuntu0.24.10.1_source.changes: done.
Successfully uploaded packages.

Uploading to ubuntu (via ftp to upload.ubuntu.com):
  Uploading libvpl-tools_1.3.0-0ubuntu0.24.10.1.dsc: done.
  Uploading libvpl-tools_1.3.0.orig.tar.gz: done.
  Uploading libvpl-tools_1.3.0-0ubuntu0.24.10.1.debian.tar.xz: done.
  Uploading libvpl-tools_1.3.0-0ubuntu0.24.10.1_source.buildinfo: done.
  Uploading libvpl-tools_1.3.0-0ubuntu0.24.10.1_source.changes: done.
Successfully uploaded packages.

Uploading to ubuntu (via ftp to upload.ubuntu.com):
  Uploading onevpl_2.14.0-1ubuntu0.24.10.1.dsc: done.
  Uploading onevpl_2.14.0.orig.tar.gz: done.
  Uploading onevpl_2.14.0-1ubuntu0.24.10.1.debian.tar.xz: done.
  Uploading onevpl_2.14.0-1ubuntu0.24.10.1_source.buildinfo: done.
  Uploading onevpl_2.14.0-1ubuntu0.24.10.1_source.changes: done.
Successfully uploaded packages.

Uploading to ubuntu (via ftp to upload.ubuntu.com):
  Uploading onevpl-intel-gpu_24.4.4-0ubuntu0.24.10.1.dsc: done.
  Uploading onevpl-intel-gpu_24.4.4.orig.tar.gz: done.
  Uploading onevpl-intel-gpu_24.4.4-0ubuntu0.24.10.1.debian.tar.xz: done.
  Uploading onevpl-intel-gpu_24.4.4-0ubuntu0.24.10.1_source.buildinfo: done.
  Uploading onevpl-intel-gpu_24.4.4-0ubuntu0.24.10.1_source.changes: done.
Successfully uploaded packages.