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.

9

Can there be a legacy version of the runtime packages in the repos?

1 Like
10

On openSUSE and Arch, there is. Fedora shouldnā€™t abandon working CPUs while advertising against mandatory/synthetic TPM2/Gen8 CPU requirements of other systems.

1 Like
11

I completely agree with this statement. I want to add that even a company should have absolutely no right to abandon support for any hardware for atleast 12 year without any exceptions. Fedora should maintain a legacy package for sure. It is troublesome to make a distrobox and install opencl applications in it.

1 Like
12

The proposal indicates that someone (perhaps you?) could do so, but the upstream legacy branches are not being actively updated, and the maintainer is not interested in continuing such support. If you want to support the legacy branches via a compat package, please consider stepping up to do so.

13

I totally would have but someone needs to train me to do so. I am just a high school student (10th class/grade). I donā€™t know how to maintain packages. I did try and see how debian builds this package and made a copr repo to try and build it for fedora. I took the fedora 41 spec file and modified it and took the original source and tried to build it for 42 but the build kept on failing. Both in copr and my machine (laptop).
I tried.
Now I am just hoping someone with more experience builds the package. Or I might have to look at some other maintainers maintaining the legacy version for opensuse. Copy and modify their spec file so it works for fedora. And try and build it.

I have build packages in the past but I just follow instructions given by the developers. I donā€™t know how to create rpm spec files or patches.

I am still learning C arrays and loops and functions and stuff like that at school.

I donā€™t have much idea about build systems and object oriented programming (the introduction to oop is given in our course in the last chapter) and maintaining packages.

1 Like
14

Is anyone actually even using Intel compute runtime? Itā€™s really senseless because Intel GPUs have such little compute capability compared to dedicated GPUs. Intel HD5500 is about 144 CUDA cores (extrapolated) versus NVIDIA RTX 3060 with 3584 CUDA cores), and Intel HD5500 is also 2x slower clock.

Is this even necessary?

15

Yes it is. My Intel integrated graphics perform much better than cpu processing. Not everybody has a good hardware. I donā€™t have a dedicated gpu.

1 Like
16

What are you computing with zero computing power?

17

No but my igpu is not that bad. Atleast it is better than using cpu processing. I have a low end laptop. But atleast my igpu performs a lot better than a gtx710.

1 Like
19

I managed to build that legacy driver in Copr.

20

I did manage to make a COPR repo and build it there.

21

I managed to build it in COPR but I am still questioning myself should I try submitting to official repos or maybe rpm fusion? Maintaining a package is a big responsibility.