An optimized BLAS library based on GotoBLAS2

Edit Package openblas

OpenBLAS is an optimized BLAS library based on GotoBLAS2 1.13 BSD version. The project is supported by the Lab of Parallel Software and Computational Science, ISCAS. http://www.rdcps.ac.cn

Refresh
Refresh
Source Files
Filename Size Changed
Define-sbgemm_r-to-fix-DYNAMIC_ARCH-builds.patch 0000001087 1.06 KB
Do-not-include-symbols-defined-in-driver-others-parameter.c-in-DYNAMIC_BUILD.patch 0000001300 1.27 KB
Fix-checks-for-AVX512-and-atomics.patch 0000001441 1.41 KB
OpenBLAS-0.3.20.tar.gz 0012742441 12.2 MB
README.HPC.SUSE 0000000889 889 Bytes
README.SUSE 0000000851 851 Bytes
Remove-extraneous-and-wrong-definition-of-sbgemm_r-on-x86_64.patch 0000000825 825 Bytes
Revert-AVX512-capability-check-from-PR-1980-moved-to-build.patch 0000000948 948 Bytes
Use-CC-and-full-command-line-instead-of-hard-coding-gcc-for-AVX512-checking.patch 0000001128 1.1 KB
Utilize-compiler-AVX512-capability-info-from-c_check-when-building-getarch.patch 0000000943 943 Bytes
_constraints 0000000373 373 Bytes
_multibuild 0000000180 180 Bytes
openblas-noexecstack.patch 0000001216 1.19 KB
openblas-ppc64be_up2_p8.patch 0000003464 3.38 KB
openblas-s390.patch 0000001363 1.33 KB
openblas.changes 0000063598 62.1 KB
openblas.spec 0000016203 15.8 KB
Revision 46 (latest revision is 60)
Dominique Leuenberger's avatar Dominique Leuenberger (dimstar_suse) accepted request 966746 from Egbert Eich's avatar Egbert Eich (eeich) (revision 46)
- Build PPC64LE libraries with the lastest gcc available to
  take advantage of instruction sets in later CPUs used in
  the CPU specific kernels (jsc#SLE-18143, bsc#1197721).
  For fortran use the stock compiler to avoid compatibility
  issues between different versions of libfortran.
  This is relevant for Leap/SLE only. It may be dropped once
  gcc < 10 is no longer supported.
- Do the same for x86_64 on SLE to make sure Cooperlake support
  is built properly.
- Remove:
  * Do-not-attempt-to-check-host-CPU-if-TARGET-is-set.patch
  * Create-independent-kernel-Makfile-configuration-when-building-DYNAMIC_ARCH.patch
  * For-DYNAMIC_ARCH-don-t-use-sbgemm_r-as-parameter.c-doesn-t-get-build.patch
  Instead, add from upstream:
  * Define-sbgemm_r-to-fix-DYNAMIC_ARCH-builds.patch
  * Remove-extraneous-and-wrong-definition-of-sbgemm_r-on-x86_64.patch
  * Fix-checks-for-AVX512-and-atomics.patch
  * Revert-AVX512-capability-check-from-PR-1980-moved-to-build.patch
  * Use-CC-and-full-command-line-instead-of-hard-coding-gcc-for-AVX512-checking.patch
  * Utilize-compiler-AVX512-capability-info-from-c_check-when-building-getarch.patch

- Update to v0.3.20:
  * general:
    some code cleanup, with added casts etc.
    fixed obtaining the cpu count with OpenMP and OMP_PROC_BIND unset
    fixed pivot index calculation by ?LASWP for negative increments other
          than one
    fixed input argument check in LAPACK ? GEQRT2
    improved the check for a Fortran compiler in CMAKE builds
    disabled building OpenBLAS' optimized versions of LAPACK complex SPMV,
Comments 7

Andre Barros's avatar

Please, update to OpenBLAS to 3.17, as some optimizations were causing segfaults and reverted. See: https://github.com/xianyi/OpenBLAS/blob/develop/Changelog.txt.


Andre Barros's avatar

It seems that octave 6.3.0 build failures (on test phase) may be associated to this on Tumbleweed.


Andre Barros's avatar

OK, this really needs a better explanation. I have Tumbleweed and Leap 15.3 installed on different computers, and on both of them I use the Science repo to provide some more packages I need. Downgrading to default versions (3.13 on Leap and 3.14 on Tumbleweed) fixes the problem with Octave, as I was able to build version 6.3 and also run the tests (make check-local) without unknown failures. It probably affects other numerical packages too.

Regards, André



Andre Barros's avatar

Hi,

Now it is something less trivial (or, perhaps, more). Julia version 1.8.5 (and probably some older versions of 1.8.x series too) needs integer indexes of vectors and matrices to be 64 bits, that means, there is a need to build adjusted "flavors" of some libraries.

For openBLAS, the "flavored" version must be compiled with "INTERFACE64=1" option.

Of course, other libraries that are linked against openBLAS will need "flavored" versions too. SuiteSparse, qrupdate, sundials and arpack-ng, at least.

The relevant sources of information are: https://docs.octave.org/v7.3.0/Compiling-Octave-with-64_002dbit-Indexing.html https://savannah.gnu.org/bugs/?57771 https://github.com/Reference-LAPACK/lapack/issues/666

On my computer, I built "proto" packages with the needed adjustments, but, of course, the "ideal" way is to have an established standard for package and libraries names.

It should be noted that, once "flavored" libraries are built, not only we will be able to build Julia but also a special version of Octave.

May I collaborate with the effort to make it happen, let me know.


Andre Barros's avatar

OK, I will fork the current project so that my modifications can be debated. Still, I have one doubt, how do I pass a definition to rpmbuild when using build.opensuse.org infrastructure?

What I mean is that, on my computer, to generate the binary package with 64 bits indexes, I use: rpmbuild --define "index64 1" openblas.spec

I have no idea how to do this under build.opensuse.org.


Andre Barros's avatar

Branched. Will do the same on SuiteSparse, arpack-ng, qrupdate and sundials, but would appreciate if I get an input about what may be the best practices, names and definitions to be used, or if it seems to be OK the way I did.

openSUSE Build Service is sponsored by