Consider creating oneMKL releases

[Rbiessy]

To continue the discussion from #459, I would like to suggest introducing quarterly releases for oneMKL. This would be useful:

• for users to know which version is expected to work with a release of the oneAPI base toolkit
• for users to be able to download a package of oneMKL
  • We have a use-case in GROMACS where users would like to download and use pre-built packages
  • I expect this will be easier than shipping oneMKL interface with the oneAPI base toolkit
• for the oneMKL CI, this helps reduce the number of configurations to test
  • We would only need to test compiler releases with oneMKL releases and compiler nightlies with oneMKL nightlies

There are some releases existing in oneMKL, I don't know if there are any plans to continue these releases quaterly?
I would suggest to start adding a release candidate tag 2025.0.rc0 end of July. If we find bugs in oneMKL we create new release candidate tags on commits fixing them. When oneAPI 2025.0 is released we can use the latest release candidate as a stable release.

I think for now the pre-built packages could be built for Ubuntu 22.04 and include all the domains and backends using MKL, CUDA and ROC libraries. We will need to clarify who is responsible for building and uploading the package to the releases.

[mmeterel]

@Rbiessy I personally find it ineffective to start and continue a broad discussion like this over github. I would suggest setting up a meeting to bring all key people up to speed with previous discussions and new proposals, and then clear up final details over github.

[al42and]

We have a use-case in GROMACS where users would like to download and use pre-built packages

Ideally, this should be bundled with the main Codeplay plugin (or, as mentioned, oneAPI base toolkit).

The need to install Intel oneAPI and NVIDIA/AMD Plugin is already not ideal. Installing pre-built package is better than building from scratch, but the need to install three packages, on top of the vendor runtime, while making sure all the versions match (and if CUDA/HIP or oneAPI get updated, then the Plugin and the oneMKL will have to be downloaded again) is not very user-friendly.

If bundling stuff together is not possible, another alternative would be to provide an APT and YUM repositories for "desktop" users and a Spack recipe for supercomputer users.

[jinz2014]

could you explain that bundling stuff together is not possible ? Thanks.

[al42and]

could you explain that bundling stuff together is not possible ? Thanks.

I was referring to the statement in the issue description that "[letting users download a package of oneMKL] will be easier than shipping oneMKL interface with the oneAPI base toolkit"

[rodburns]

@Rbiessy I personally find it ineffective to start and continue a broad discussion like this over github. I would suggest setting up a meeting to bring all key people up to speed with previous discussions and new proposals, and then clear up final details over github.

In the interest of open governance it would be great if as much as possible could be discussed in public so that anyone from the community can participate. Can we facilitate meetings through the UXL Foundation groups?