Please add Intel 13th gen support into iHD_drv_video.so

[vanvugt]

Please patch Intel 13th gen support into iHD_drv_video.so. Like we did in https://launchpad.net/bugs/2004237

Or more simply, update intel-media-driver to >= 22.4.2

[Saviq]

Is there somewhere we could grab the newer driver from? We're defaulting to what jammy-updates has, and would rather pull in from an established source like https://launchpad.net/~graphics-drivers maybe?

[vanvugt]

I don't have an opinion on the source used. Most recently it was implemented to use upstream in the gnome snap here, but I don't think we should be maintaining the Mesa libraries in the gnome snap forever. Hence this bug.

[Saviq]

On the one hand, I agree with @AlanGriffiths that this is a candidate for a mesa-core22 track (similar to gaming-graphics-core22).

On the other, the default snap experience on affected devices with 22.10+ would be worse than with debs.

We could decide for mesa-core22/latest to be latest, as in latest stable versions of what's included. Personally I'm of two minds.

[AlanGriffiths]

With graphics-core20 I created kisak-core20 based on ppa:kisak/kisak-mesa.

We now have the option of maintaining a kisak branch within mesa-core22 (with a more recent Mesa) for those that need it

[Saviq]

With graphics-core20 I created kisak-core20 based on ppa:kisak/kisak-mesa.

We now have the option of maintaining a kisak branch within mesa-core22 (with a more recent Mesa) for those that need it

Yes, but we do have to think about the default experience of people that don't know they "need" something. They'll install a 22.10+ system, install a snap, and see degraded performance of snaps vs. debs. We have a chance of doing better with the default mesa-core22 branch (maybe backport the latest stable versions from Ubuntu), so IMO we should entertain that option.

Not sure we (the Mir team) are the best to do it (foundations come to mind), but we own that hot potato for now at least.

[AlanGriffiths]

Yes, but we do have to think about the default experience of people that don't know they "need" something

Indeed. The management of tracking mesa versions is a can of worms we've intentionally opened with the changes from graphics-core20 to graphics-coe22.

Not sure we (the Mir team) are the best to do it (foundations come to mind), but we own that hot potato for now at least.

Also agreed. We need more conversations with stakeholders around the organisation. (And a good proposal for right the way forward)

[RAOF]

So, there seem to be broadly two sensible approaches here:

1. Follow the approach that seeded-in-Ubuntu snaps take: there's a track for each Ubuntu release, and those tracks follow the latest stable release at the point of the Ubuntu release. Problems here involve getting the right track selected during first install, but maybe we can use the same “it's installed by the Ubuntu installer” approach.
2. Track (primarily mesa) releases from the latest Ubuntu release, and have that as the default track. Probably splitting off an old-stable track once there's a new one. ie: the default track tracks lunar at the moment; once mantic is released the default track will track mantic and a lunar track could be added.
3. (For completeness) Track (primarily mesa) upstream stable releases, and have that as the default track.

When seeded-in-Ubuntu snaps start to rely on mesa-core22 I suspect there will be a desire for (1), to preserve Ubuntu release stability guarantees. If this starts to become core infrastructure, it would also be worthwhile extending ubuntu-drivers to understand mesa-coreXX tracks.

[vanvugt]

Not sure we (the Mir team) are the best to do it (foundations come to mind), but we own that hot potato for now at least.

Also agreed. We need more conversations with stakeholders around the organisation. (And a good proposal for right the way forward)

I think it's the kernel team that owns Mesa debs and hardware enablement in general so I would expect it to be the same people (hi Timo).