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

Issue on page /elements/oneMKL/source/domains/lapack/lapack.html #470

Closed
jakub-homola opened this issue Feb 6, 2023 · 5 comments
Closed

Comments

@jakub-homola
Copy link

Hi,

Are all the matrices in the LAPACK domain of oneMKL assumed to be row-major or column-major?

It seems they are assumed to be column-major, but I could not find that information anywhere on the webpage, nor there are any oneapi::mkl::layout parameters to the functions. Right now I am mainly concerned about potrf and trtrs, but knowing that information for the whole LAPACK would be great.

Could you please redirect me to where I can find that information, or add it to the spec/docs?

The version of the spec I am seeing is 1.2-rev-1

@mmeterel
Copy link
Contributor

mmeterel commented Feb 6, 2023

Assigning to @sknepper

@sknepper
Copy link
Contributor

sknepper commented Feb 6, 2023

Hi @jakub-homola, thanks for the question! The matrices in the LAPACK domain are assumed to be column-major. You're right that we need to add this information to the oneMKL specification. Thanks for finding this!

@jakub-homola
Copy link
Author

Thanks for the reply.
However, when thinking about it, I think it would be better to add an additional oneapi::mkl::layout argument, rather than accepting only column-major matrices. Would it be possible, with respect to backwards compatibility?

@sknepper
Copy link
Contributor

Hi @jakub-homola,
When we introduced row major support for the BLAS domain, that was one consideration - to take a parameter that indicated the layout of the matrices (like in CBLAS/LAPACKE). However, we ultimately opted to create separate namespaces as typically an application would use just one layout for the whole application. With namespaces, you don't need to pass an extra layout parameter for every function.

@sknepper
Copy link
Contributor

@jakub-homola Thanks again for catching this! I appreciate your interest and thoughtful replies. As we've updated the specification to clarify this, I'd like to ask @mmeterel to close this issue. Please re-open if needed.

And just a note about Intel oneMKL documentation since that was mentioned in the initial report: We note that "Currently, LAPACK DPC++ APIs do not support matrices stored using row major layout." in the Intel® oneAPI Math Kernel Library (oneMKL) - Data Parallel C++ Developer Reference (link). However, we will make this more clear in a future update. Thanks again!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants