Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[RFC|oneMKL]Enable programmatic versioning #561

Merged
merged 20 commits into from
Sep 30, 2024
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -11,11 +11,43 @@ This section covers all other features in the design of oneMKL architecture.

.. _onemkl_spec_current_version:

Current Version of this oneMKL Specification
Specification Version and Compliance
+++++++++++++++++++++++++++++++++++++++++++++

This is the oneMKL specification which is part of the oneAPI specification version 1.0.0.
Each oneMKL domain must define a preprocessor macro to represent the version of the specification that the implementation is compliant with.
vmalia marked this conversation as resolved.
Show resolved Hide resolved
vmalia marked this conversation as resolved.
Show resolved Hide resolved

The macros for each domain are listed as follows:

| ONEMKL_BLAS_SPEC_VERSION
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If/When we switch to oneMATH name for the Specification and Interfaces project, will we also switch the macro names ? maybe we want to delay this merge until those are made to not have to deprecate/switch ... ?

Copy link
Contributor Author

@vmalia vmalia Sep 17, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@spencerpatty The changes you mentioned are from oneapi-src/oneMKL#564 which is an RFC in one of the implementations of this spec. The implementation can choose to take any direction, whether or not it is in compliance with the specification.

@Rbiessy you approved this PR earlier so there are 2 questions -

  1. Does your RFC([RFC] oneMKL Interface renaming oneapi-src/oneMKL#564) block this RFC?
  2. Does your RFC aim to make changes to the oneAPI specification eventually? If yes, can you please create a placeholder Issue/PR in this project and mention it here? If not, please note that your oneMKL Interfaces RFC breaks compliance with the oneAPI specification as of the current status of your RFC.

Note point number 5 in https://github.com/mkrainiuk/oneMKL/blob/rfcs/README.md#rfc-ratification-process

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I had an offline discussion with the team and we came to an agreement that the oneMATH proposal has a lot of work ahead of it, and that name change will have to be made in not just oneMKL Interfaces, but also in multiple places across oneAPI spec and other documents. Since this change will have a wider impact than just this specific part of document where this PR targets, it is better to make that change at that time. It will not affect the core version schema or approach proposed here.
This PR and RFC is NOT blocked by @Rbiessy 's RFC in oneMKL Interfaces.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It does not matter to me which RFC is implemented first. The RFC for renaming is planning to rename the occurrences of all the macros using ONEMKL.
The RFC describes how it impacts the specification. I read the ratification process, it does not say that an issue needs to be created. @mkrainiuk could this be clarified in the RFC process? I created #580 but I have some concerns the discussions will be split in 2 different places now.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hi @Rbiessy, good point, we need to clarify it in the ratification process, and I think any changes related to API should be discussed in Spec only, since opensource is just an implementation of the Spec, I believe it should just follow what was decided for Spec. In this particular case I guess the problem is that we have opensource project migration (which is not related to the Spec) combined with renaming (which is Spec related and should be started in the Spec).

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you for clarifying, @mkrainiuk . @spencerpatty @Rbiessy Let's proceed with this RFC with the oneMKL naming. When the oneMATH proposal is made to the oneAPI spec, it can address these macros and other changes across the oneAPI spec simultaneously.

| ONEMKL_LAPACK_SPEC_VERSION
| ONEMKL_SPBLAS_SPEC_VERSION
| ONEMKL_DFT_SPEC_VERSION
| ONEMKL_RNG_SPEC_VERSION
vmalia marked this conversation as resolved.
Show resolved Hide resolved
| ONEMKL_STATS_SPEC_VERSION
| ONEMKL_VM_SPEC_VERSION

The specification version can be created by appending all digits of the specification version in the format of <MAJOR><MINOR>. MINOR version always uses two digits. This version can be used to check the compatibility of the implementation with the specification version. Note that the revision is not included here because it reflects changes only for the specification document without affecting the implementation. If the implementation is not compliant with any release of the specification, then the macro must have a numerical value of `000`.
vmalia marked this conversation as resolved.
Show resolved Hide resolved

Version Example

| oneAPI 1.1 rev 1 will be represented as a numerical value of 101
| oneAPI 1.2 rev 1 will be represented as a numerical value of 102
| oneAPI 1.2 rev 2 will be represented as a numerical value of 102

Macro Example

.. code-block:: c

// For oneAPI 1.2 rev 1
vmalia marked this conversation as resolved.
Show resolved Hide resolved
#define ONEMKL_BLAS_SPEC_VERSION 102

// For oneAPI 1.2 rev 2
mkrainiuk marked this conversation as resolved.
Show resolved Hide resolved
#define ONEMKL_DFT_SPEC_VERSION 102

// For oneAPI 1.3 rev 1
#define ONEMKL_VM_SPEC_VERSION 103

Versioning details are defined here: https://github.com/uxlfoundation/oneAPI-spec/blob/main/doc/versioning.rst#provisional-versions

.. _onemkl_pre_post_conditions:

Expand Down