-
Notifications
You must be signed in to change notification settings - Fork 189
Add findBLAS support to CMakeLists.txt #844
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
Changes from 10 commits
a203645
6e36e6b
6862209
03590ea
5567ab1
095ee16
d475595
434b849
0534325
3254fd0
90fd5b9
a690390
40765ad
b867c2b
9de0589
58074c7
0ce2372
e4d90b2
9e80c17
dee6979
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -59,23 +59,25 @@ jobs: | |
with: | ||
compiler: ${{ matrix.toolchain.compiler }} | ||
version: ${{ matrix.toolchain.version }} | ||
|
||
|
||
# Build and test with built-in BLAS and LAPACK | ||
- name: Configure with CMake | ||
if: ${{ contains(matrix.build, 'cmake') }} | ||
run: >- | ||
cmake -Wdev -G Ninja | ||
-DCMAKE_BUILD_TYPE=Release | ||
-DCMAKE_MAXIMUM_RANK:String=4 | ||
-DCMAKE_INSTALL_PREFIX=$PWD/_dist | ||
-DFIND_BLAS:STRING=FALSE | ||
-S . -B ${{ env.BUILD_DIR }} | ||
|
||
- name: Build and compile | ||
if: ${{ contains(matrix.build, 'cmake') }} | ||
run: cmake --build ${{ env.BUILD_DIR }} --parallel | ||
|
||
- name: catch build fail | ||
run: cmake --build ${{ env.BUILD_DIR }} --verbose --parallel 1 | ||
if: ${{ failure() && contains(matrix.build, 'cmake') }} | ||
run: cmake --build ${{ env.BUILD_DIR }} --verbose --parallel 1 | ||
|
||
- name: test | ||
if: ${{ contains(matrix.build, 'cmake') }} | ||
|
@@ -89,3 +91,71 @@ jobs: | |
- name: Install project | ||
if: ${{ contains(matrix.build, 'cmake') }} | ||
run: cmake --install ${{ env.BUILD_DIR }} | ||
|
||
Build-with-MKL: | ||
runs-on: ubuntu-latest | ||
strategy: | ||
fail-fast: false | ||
matrix: | ||
toolchain: | ||
- {compiler: intel, version: '2024.1'} | ||
build: [cmake] | ||
env: | ||
BUILD_DIR: ${{ matrix.build == 'cmake' && 'build' || '.' }} | ||
APT_PACKAGES: >- | ||
intel-oneapi-mkl | ||
intel-oneapi-mkl-devel | ||
steps: | ||
- name: Checkout code | ||
uses: actions/checkout@v4 | ||
|
||
- name: Set up Python 3.x | ||
uses: actions/setup-python@v5 # Use pip to install latest CMake, & FORD/Jin2For, etc. | ||
with: | ||
python-version: 3.x | ||
|
||
- name: Install fypp | ||
run: pip install --upgrade fypp ninja | ||
|
||
- name: Setup Fortran compiler | ||
uses: fortran-lang/[email protected] | ||
id: setup-fortran | ||
with: | ||
compiler: ${{ matrix.toolchain.compiler }} | ||
version: ${{ matrix.toolchain.version }} | ||
|
||
- name: Install Intel oneAPI MKL | ||
run: | | ||
sudo apt-get install ${APT_PACKAGES} | ||
source /opt/intel/oneapi/mkl/latest/env/vars.sh | ||
printenv >> $GITHUB_ENV | ||
|
||
# Build and test with external BLAS and LAPACK (MKL on Ubuntu with Intel compilers) | ||
- name: Configure with CMake and MKL | ||
run: >- | ||
cmake -Wdev -G Ninja | ||
-DCMAKE_BUILD_TYPE=Release | ||
-DCMAKE_MAXIMUM_RANK:String=4 | ||
-DCMAKE_INSTALL_PREFIX=$PWD/_dist | ||
-DFIND_BLAS:STRING=TRUE | ||
-DBLAS_LIBRARIES="/opt/intel/oneapi/mkl/latest/lib/intel64/libmkl_rt.so" | ||
-DLAPACK_LIBRARIES="/opt/intel/oneapi/mkl/latest/lib/intel64/libmkl_rt.so" | ||
-S . -B build_mkl | ||
|
||
- name: Build and compile with MKL | ||
run: cmake --build build_mkl --parallel | ||
|
||
- name: catch build fail with MKL | ||
if: failure() | ||
run: cmake --build build_mkl --verbose --parallel 1 | ||
|
||
- name: test with MKL | ||
run: >- | ||
ctest | ||
--test-dir build_mkl | ||
--parallel | ||
--output-on-failure | ||
--no-tests=error | ||
|
||
- name: Install project with MKL | ||
run: cmake --install build_mkl |
Original file line number | Diff line number | Diff line change | ||
---|---|---|---|---|
|
@@ -30,7 +30,9 @@ contains | |||
new_unittest("test_gemv${t1[0]}$${k1}$", test_gemv${t1[0]}$${k1}$), & | ||||
new_unittest("test_getri${t1[0]}$${k1}$", test_getri${t1[0]}$${k1}$), & | ||||
#:endfor | ||||
new_unittest("test_idamax", test_idamax) & | ||||
new_unittest("test_idamax", test_idamax), & | ||||
new_unittest("test_external_blas",external_blas_test), & | ||||
new_unittest("test_external_lapack",external_lapack_test) & | ||||
] | ||||
|
||||
end subroutine collect_blas_lapack | ||||
|
@@ -117,6 +119,75 @@ contains | |||
|
||||
end subroutine test_idamax | ||||
|
||||
!> Test availability of the external BLAS interface | ||||
subroutine external_blas_test(error) | ||||
!> Error handling | ||||
type(error_type), allocatable, intent(out) :: error | ||||
|
||||
#ifdef STDLIB_EXTERNAL_BLAS | ||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Correct me if I got this wrong, but I think the test should be calling
Which already interface the respective routines if In this case, the test_blas_lapack.fypp file does not need to be moved to the C preprocessed category. Which is why the fpm build is failing as it was not included in the fypp_deployment.py file, but I'm guessing that it is not needed. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Great comment Jose, thank you for looking into it. I've tried that. The meaning of the test is to ensure that the external function is being picked. However, calling the interface does not guarantee that we're using the external library function. One thing that I had tried to check that was to use a procedure pointer: abstract interface
subroutine blas_saxpy(blabla)
end interface
procedure(blas_saxpy), pointer :: axpy_
axpy_ => axpy
! Check that we're not using the internal implementation
call check(error, .not.associated(axpy_ , stdlib_saxpy)) But unfortunately, Fortran does not allow pointing to an interface, so this is not possible. If you have a better idea how could we check this, I'm very much in for removing preprocessing from the test module! There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Edit: the way that CMake uses to check if a fortran function exists is just to declare it There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I see, so if I understand, the objective of this test is to check if If say one does force these macros to be TRUE but the external library is not visible in the path, then a compile-time error would occur such as "'undefined reference to `dgetrf_'" which would already alert of a link issue. If the library is visible, then
would have the same effect as the local test interface. So I'm just wondering if there could be a different kind of test using directly the higher-level interfaces from the stdlib modules? Now, if the test is kept as is, this file should be added here stdlib/config/fypp_deployment.py Line 23 in 4859081
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. In the case of the stdlib CI, yes because there are testing routines that check that the base functions work anyways. But in general, if you don't build the tests there is no guarantee that these functions are available. So long story short, I think we have these two options:
So in light of the additional complexity, maybe let's just remove the tests and go for option 1? There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I would be in favor of option 1, so given this PR started by @zoziha is meant to help using the bindings in MSYS2, what about changing one of the windows CI jobs, I would also suggest one of the linux-intel jobs to link againts MKL. That should be more than good enough I think. |
||||
interface | ||||
subroutine saxpy(n,sa,sx,incx,sy,incy) | ||||
import sp,ilp | ||||
implicit none(type,external) | ||||
real(sp), intent(in) :: sa,sx(*) | ||||
integer(ilp), intent(in) :: incx,incy,n | ||||
real(sp), intent(inout) :: sy(*) | ||||
end subroutine saxpy | ||||
end interface | ||||
|
||||
integer(ilp), parameter :: n = 5, inc=1 | ||||
real(sp) :: a,x(n),y(n) | ||||
|
||||
x = 1.0_sp | ||||
y = 2.0_sp | ||||
a = 3.0_sp | ||||
|
||||
call saxpy(n,a,x,inc,y,inc) | ||||
call check(error, all(abs(y-5.0_sp)<sqrt(epsilon(0.0_sp))), "saxpy: check result") | ||||
if (allocated(error)) return | ||||
|
||||
#else | ||||
call skip_test(error, "Not using an external BLAS") | ||||
#endif | ||||
|
||||
end subroutine external_blas_test | ||||
|
||||
!> Test availability of the external BLAS interface | ||||
subroutine external_lapack_test(error) | ||||
!> Error handling | ||||
type(error_type), allocatable, intent(out) :: error | ||||
|
||||
#ifdef STDLIB_EXTERNAL_LAPACK | ||||
interface | ||||
subroutine dgetrf( m, n, a, lda, ipiv, info ) | ||||
import dp,ilp | ||||
implicit none(type,external) | ||||
integer(ilp), intent(out) :: info,ipiv(*) | ||||
integer(ilp), intent(in) :: lda,m,n | ||||
real(dp), intent(inout) :: a(lda,*) | ||||
end subroutine dgetrf | ||||
end interface | ||||
|
||||
integer(ilp), parameter :: n = 3 | ||||
real(dp) :: A(n,n) | ||||
integer(ilp) :: ipiv(n),info | ||||
|
||||
|
||||
A = eye(n) | ||||
info = 123 | ||||
|
||||
! Factorize matrix | ||||
call dgetrf(n,n,A,n,ipiv,info) | ||||
|
||||
call check(error, info==0, "dgetrf: check result") | ||||
if (allocated(error)) return | ||||
|
||||
#else | ||||
call skip_test(error, "Not using an external LAPACK") | ||||
#endif | ||||
|
||||
end subroutine external_lapack_test | ||||
|
||||
end module test_blas_lapack | ||||
|
||||
|
||||
|
Uh oh!
There was an error while loading. Please reload this page.