F42 Change Proposal: Intel Compute Runtime - Upgrade with HW cut-off (self-contained)

Project Discussion Change Proposals
,
1

Intel Compute Runtime - Upgrade with HW cut-off

This is a proposed Change for Fedora Linux.
This document represents a proposed Change. As part of the Changes process, proposals are publicly announced in order to receive community feedback. This proposal will only be implemented if approved by the Fedora Engineering Steering Committee.

Wiki
Announced

:link: Summary

Intel Compute Runtime parts are currently stuck at a legacy branch that isnā€™t undergoing an active development. Newer branches did significantly cut hardware support (for GPU Generations prior to the 12th), and the aim of this change is to do the leap of faith, and rebase intel-compute-runtime and intel-igc to the latest upstream releases.

This Change doesnā€™t affect the intel-media-driver included in the default package set, which continues to have support for old generations of hardware in the main development branches for now.

:link: Owner

:link: Detailed Description

Intel Compute Runtime, consisting of intel-compute-runtime, intel-igc, oneapi-level-zero, removed support for GPU Generations prior to the 12th Gen GPUs. This effectively means that any hardware released before 2020 is no longer supported for OpenCL and oneAPI workloads. The cut-off occurred first in compute-runtime with branch 24.39, released as stable on October 21st, 2024, and followed in rest of the components.

The removed architectures are listed at LEGACY_PLATFORMS:

  • Broadwell
  • Skylake
  • Kaby Lake
  • Coffee Lake
  • Apollo Lake
  • Gemini Lake
  • Ice Lake
  • Elkhart Lake

The now supported GPU generations would be:

  • DG1
  • Alchemist
  • Tiger Lake
  • Rocket Lake
  • Alder Lake
  • Meteor Lake
  • Raptor Lake
  • Lunar Lake
  • Arrow Lake
  • more to comeā€¦

Fedora packages thus stayed on the older branches that support older hardware generations up to Broadwell (released around 2015). These snapshots do miss support for newer Hardware generations, most notably Intel Battlemage GPUs, will miss support for upcoming graphics based on Xe3+, and lack fixes and improvements for integrated Xe2 architecture products.

Apart from HW Support plane, itā€™ll, over time, become problematic to keep the pieces working, as new kernels, headers, and compilers do break the suite on occasion, and older branches arenā€™t getting fixes in these areas.

This change is to propose a rebase of the entire suite to the latest upstream branches, undergoing an active development and adding support for new products.

:link: Feedback

:link: Benefit to Fedora

This change brings in a new hardware support, and will allow to keep supporting future hardware generations. The change would also allow Fedora to come with the latest fixes and improvements (including in the performance area) to the Intel Compute Runtime. And finally, itā€™ll allow the suite to continue to work with other parts of the components forming the stack (drivers in kernel, OpenCL, etc.) as they evolve.

This will also enable to move the suite from depending on LLVM 15 to a newer releases, bringing batch of improvements and changes done over the years in LLVM.

:link: Scope

  • Proposal owners: Prepare, and build rebased parts of the stack in a testing COPR, rebase the components in Fedora.

  • Other developers: If any volunteers want/need, they can package legacy branches of the suite to keep it in the repositories.

  • Release engineering: N/A

  • Policies and guidelines: N/A (not needed for this Change)

  • Trademark approval: N/A (not needed for this Change)

  • Alignment with the Fedora Strategy:

:link: Upgrade/compatibility impact

:link: Early Testing (Optional)

Do you require ā€˜QA Blueprintā€™ support? N

:link: How To Test

(expected in Jan/Feb 2025 timeframe)

  1. Own any intel GPU from the supported generation (12th Gen onwards)
  2. Enable testing COPR: TBD
  3. Update to the packages in the testing COPR
  4. Install intel-compute-runtime, darktable, any other software which leverages OpenCL or oneAPI
  5. Run various compute tests, eg. clinfo, clpeak, rm -rf ~/.cache/darktable/ && darktable-cltest, zello_world
  6. Observe the results

:link: User Experience

:link: Dependencies

:link: Contingency Plan

  • Contingency mechanism: Not doing the change, reverting packages that may have been affected
  • Contingency deadline: Final Freeze
  • Blocks release? N/A (not a System Wide Change)

:link: Documentation

N/A (not a System Wide Change)

:link: Release Notes

Last edited by @amoloney 2024-12-16T20:46:05Z

Last edited by @amoloney 2024-12-16T20:46:05Z

2

How do you feel about the proposal as written?

  • Strongly in favor
  • In favor, with reservations
  • Neutral
  • Opposed, but could be convinced
  • Strongly opposed
0 voters

If you are in favor but have reservations, or are opposed but something could change your mind, please explain in a reply.

We want everyone to be heard, but many posts repeating the same thing actually makes that harder. If you have something new to say, please say it. If, instead, you find someone has already covered what youā€™d like to express, please simply give that post a :heart: instead of reiterating. You can even do this by email, by replying with the heart emoji or just ā€œ+1ā€. This will make long topics easier to follow.

Please note that this is an advisory ā€œstraw pollā€ meant to gauge sentiment. It isnā€™t a vote or a scientific survey. See About the Change Proposals category for more about the Change Process and moderation policy.

3

Maybe you could spell out what this means for ā€œoldā€ (pre 2020) hardware: would it be supported with a legacy compute-runtime, or would OpenCL applications need to be rebuild for legacy?
Item 4 in your bullet list sounds as if one would need to install darktable etc from the COPR with testing packages in order to test things.
I would think that OpenCL apps such as darktable do not need to be rebuilt either way (neither for testing with the COPR, nor once we have a legacy compute-runtime).

2 Likes
4

Thanks for the tips! Iā€™ll edit it tomorrow, to reply:

Old hardware wouldnā€™t be supported at all, unless somebody wants to package and maintain a separate intel-compute-runtime and intel-igc legacy packages.

And yes, youā€™re right, rebuilds for that scenario arenā€™t necessary, nor for testing copr, Iā€™ll amend the formating, thanks!

5

@mjg Iā€™ve edited the change on the wiki

@amoloney But I canā€™t edit it here due to ā€œYou must choose 3 tagsā€, but that seems impossible to do with the field greyed out :confused: . Can you take a look at it please?

6

This seems reasonable to do. Do we know what other distros are doing in this area? (debian/opensuse/centos stream)?

7

Mhm,

CentOS Stream: the compute-runtime isnā€™t there at all, Intel may have some repository somewhere for it (saying that only on basis that Iā€™ve seen some .spec templates for it some time ago). Iā€™ve got some requests to package that for EPEL (that may go into the 10 only, after the rebase if the change is accepted).

ArchLinux has made the jump, while having a legacy package in the repositories too.

openSUSE has way older release (than what we already have in Fedora) of the suite packaged.

Both Ubuntu/Debian are on the same branch that we currently have in Fedora. Intel provides official deb files for each stable release of the runtime and a separate repository for Ubuntu aimed for users with Xe2/BMG which has the newer release.

I am not aware of any concrete plans, Iā€™ll definitely check up on the status every now and then!

8

This change proposal has now been submitted to FESCo with ticket #3307 for voting.

To find out more, please visit our Changes Policy documentation.