NetCube-Systems-Austria/kumquat-buildroot
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
4c022010b4
kumquat-buildroot/package/openblas/Config.in

98 lines
3.8 KiB
Plaintext
Raw Normal View History

openblas: new package OpenBLAS is optimised for specific CPU models, which don't fully match with the GCC code generation options. Therefore, we can't automatically select BR2_PACKAGE_OPENBLAS_TARGET based on the CPU choice. Instead, let the user select the TARGET name, but offer a sensible default. Other possible solutions were deemed too complicated: adding choice options in the ambiguous cases, or only making the option user-visible when there is ambiguity. Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-06-27 10:44:50 +02:00
config BR2_PACKAGE_OPENBLAS_DEFAULT_TARGET
string
default "P2" if BR2_x86_pentium2
default "KATMAI" if BR2_x86_pentium3
default "NORTHWOOD" if BR2_x86_pentium4
openblas: drop SSE_GENERIC target Fixes #10856 The SSE_GENERIC target fails to build with a "sgemm_kernel.o: No such file or directory" error. Several upstream bug reports exist for this: https://github.com/xianyi/OpenBLAS/issues/502 https://github.com/xianyi/OpenBLAS/issues/685 In both cases, upstream suggests using a different target definition instead. E.G. from issue 685: You may use NORTHWOOD on x86: make TARGET=NORTHWOOD that uses SSE2 instructions. It's very hard to find non-SSE2 x86 CPUs today. For x86-64 use the PRESCOTT target So drop the SSE_GENERIC target. The only x86_64 variant we support not covered by a more specific openblas target is the default variant, nocona and jaguar. Nocona was a Xeon variant of the P4 "Prescott" architecture, so use the PRESCOTT openblas target: https://en.wikipedia.org/wiki/Xeon#Nocona_and_Irwindale Jaguar is from the Bobcat family, so use the BOBCAT openblas target: https://en.wikipedia.org/wiki/List_of_AMD_microprocessors#Bobcat_core_architecture_(APU) [Peter: add Jaguar as pointed out by Arnout] Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2018-04-01 10:46:41 +02:00
default "PRESCOTT" if BR2_x86_prescott || BR2_x86_nocona
openblas: new package OpenBLAS is optimised for specific CPU models, which don't fully match with the GCC code generation options. Therefore, we can't automatically select BR2_PACKAGE_OPENBLAS_TARGET based on the CPU choice. Instead, let the user select the TARGET name, but offer a sensible default. Other possible solutions were deemed too complicated: adding choice options in the ambiguous cases, or only making the option user-visible when there is ambiguity. Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-06-27 10:44:50 +02:00
default "BANIAS" if BR2_x86_pentium_m
default "CORE2" if BR2_x86_core2
package/openblas: Handle new westmere target architecture Nehalem, the predecessor to westmere, is best match for westmere architecture in current openblas. Signed-off-by: Esben Haabendal <esben@geanix.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2019-06-11 10:44:10 +02:00
default "NEHALEM" if BR2_x86_corei7 || BR2_x86_silvermont || BR2_x86_westmere
openblas: new package OpenBLAS is optimised for specific CPU models, which don't fully match with the GCC code generation options. Therefore, we can't automatically select BR2_PACKAGE_OPENBLAS_TARGET based on the CPU choice. Instead, let the user select the TARGET name, but offer a sensible default. Other possible solutions were deemed too complicated: adding choice options in the ambiguous cases, or only making the option user-visible when there is ambiguity. Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-06-27 10:44:50 +02:00
default "SANDYBRIDGE" if BR2_x86_corei7_avx
default "HASWELL" if BR2_x86_core_avx2
default "ATOM" if BR2_x86_atom
default "ATHLON" if BR2_x86_athlon || BR2_x86_athlon_4
default "OPTERON" if BR2_x86_opteron
default "OPTERON_SSE3" if BR2_x86_opteron_sse3
default "BARCELONA" if BR2_x86_barcelona
package/openblas: fix jaguar openblas target In commit [1] Peter said he will use BOBCAT for jaguar cpus. But JAGUAR was used instead. Use BOBCAT as openblas target for JAGUAR cpus since it is not listed in openblas's target list [2]. [1] 5e6fa93483caac317ab8844feb2ae9c07078a6c8 [2] https://github.com/xianyi/OpenBLAS/blob/release-0.3.0/TargetList.txt Signed-off-by: Romain Naour <romain.naour@gmail.com> Cc: Peter Korsgaard <peter@korsgaard.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2019-08-17 19:37:49 +02:00
default "BOBCAT" if BR2_x86_jaguar
openblas: new package OpenBLAS is optimised for specific CPU models, which don't fully match with the GCC code generation options. Therefore, we can't automatically select BR2_PACKAGE_OPENBLAS_TARGET based on the CPU choice. Instead, let the user select the TARGET name, but offer a sensible default. Other possible solutions were deemed too complicated: adding choice options in the ambiguous cases, or only making the option user-visible when there is ambiguity. Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-06-27 10:44:50 +02:00
default "STEAMROLLER" if BR2_x86_steamroller
default "VIAC3" if BR2_x86_c3 || BR2_x86_c32
default "POWER4" if BR2_powerpc_power4
default "POWER5" if BR2_powerpc_power5
default "POWER6" if BR2_powerpc_power6
default "POWER7" if BR2_powerpc_power7
default "POWER8" if BR2_powerpc_power8
default "PPCG4" if BR2_powerpc_7400 || BR2_powerpc_7450
default "PPC970" if BR2_powerpc_970
default "PPC440" if BR2_powerpc_440
default "PPC440FP2" if BR2_powerpc_440fp
openblas: P5600 and I6400 cores only available for Codescape toolchains These two MIPS cores are built with MSA support (-mmsa) which is currently in GCC trunk. The only toolchains that support it right now are Codescape MTI and Codescape IMG from Imagination Technologies. Fixes: http://autobuild.buildroot.net/results/af5/af5e9f10287aaf9b9be6228ad7d12b2d926f8051/ http://autobuild.buildroot.net/results/b20/b201e4072b0b634d5ac86781aee24c698f88d689/ Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-07-18 14:05:39 +02:00
# P5600 is built with MSA support which is only available in Codescape toolchains
openblas: use MIPS specific cores for P5600 and I6400 Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-10-15 13:26:12 +02:00
default "P5600" if BR2_mips_p5600 && BR2_TOOLCHAIN_EXTERNAL_CODESCAPE_MTI_MIPS
MIPS: replace every BR2_mips_* with the new MIPS CPU options Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-09-30 11:36:49 +02:00
default "SICORTEX" if BR2_MIPS_CPU_MIPS64
openblas: P5600 and I6400 cores only available for Codescape toolchains These two MIPS cores are built with MSA support (-mmsa) which is currently in GCC trunk. The only toolchains that support it right now are Codescape MTI and Codescape IMG from Imagination Technologies. Fixes: http://autobuild.buildroot.net/results/af5/af5e9f10287aaf9b9be6228ad7d12b2d926f8051/ http://autobuild.buildroot.net/results/b20/b201e4072b0b634d5ac86781aee24c698f88d689/ Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-07-18 14:05:39 +02:00
# I6400 is built with MSA support which is only available in Codescape toolchains
openblas: use MIPS specific cores for P5600 and I6400 Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Peter Korsgaard <peter@korsgaard.com>
2016-10-15 13:26:12 +02:00
default "I6400" if BR2_mips_i6400 && BR2_TOOLCHAIN_EXTERNAL_CODESCAPE_IMG_MIPS
openblas: SPARC support is for Sparc v9 Makefile.sparc in the openblas source code passes -mcpu=v9, i.e it assumes a SPARCv9 CPU. Therefore, this commit adjusts openblas Config.in file so that SPARC is only used for BR2_sparc_v9. Fixes: http://autobuild.buildroot.net/results/805087e87b8bb7d11adb49d9eca3959a37aca3a2/ Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2017-05-13 16:09:53 +02:00
# OpenBLAS assumes SPARC=Sparc v9
default "SPARC" if BR2_sparc_v9
openblas: fix build issues on ARM This commit fixes several build issues of OpenBLAS on ARM: - The first one occured on ARMv5 platforms, when the ARMV5 OpenBLAS architecture is used. In this case, OpenBLAS build system forces -march=armv5, which may not be correct for certain toolchains. As an example, the Sourcery CodeBench toolchain has an ARMv4 and an ARMv5 sysroot. The ARMv5 sysroot is actually an armv5te sysroot, so when OpenBLAS forces -march=armv5, gcc thinks it should use the ARMv4 sysroot, causing build failures. To address this, a patch to completely remove the -march ARM CFLAGS is added to OpenBLAS. Fixes: http://autobuild.buildroot.net/results/991497b12b70f948169e5ad99eebd0fe7f6209a2/ - The second one occured on ARMv7 platforms, when the ARMV7 OpenBLAS architecture is used. The OpenBLAS code expects an EABIhf build, so a dependency is added for EABIhf for both ARMv6 and ARMv7. Fixes: http://autobuild.buildroot.net/results/0ba0bee48a83367fcefab827e8eaa72f0c8fe90b/ - Once the previous ARMv7 problem has been fixed, it turns out that the ARMv7 specific code in OpenBLAS contains VFPv3 specific code. Therefore, the user *must* have choosen either VFPv3 or VFPv4, or the code will not build. VFPv3-D16/VFPv4-D16 are not sufficient, as more than 16 registers are used by the OpenBLAS code. To address this, the ARMV7 platform of OpenBLAS is restricted to the proper VFPv3/VFPv4 selection, and the ARMV6 platform is restricted to the proper VFPv2 selection. This problem was not visible in the autobuilders, as it was hidden by the previous one. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-08-07 23:32:34 +02:00
# Cortex-A15 always have a VFPv4
default "CORTEXA15" if (BR2_cortex_a15 && BR2_ARM_EABIHF)
# Cortex-A9 have an optional VFPv3, so we need to make sure it
# is available
default "CORTEXA9" if (BR2_cortex_a9 && BR2_ARM_EABIHF && \
BR2_ARM_CPU_HAS_VFPV3)
openblas: new package OpenBLAS is optimised for specific CPU models, which don't fully match with the GCC code generation options. Therefore, we can't automatically select BR2_PACKAGE_OPENBLAS_TARGET based on the CPU choice. Instead, let the user select the TARGET name, but offer a sensible default. Other possible solutions were deemed too complicated: adding choice options in the ambiguous cases, or only making the option user-visible when there is ambiguity. Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-06-27 10:44:50 +02:00
default "ARMV5" if BR2_ARM_CPU_ARMV5
openblas: fix build issues on ARM This commit fixes several build issues of OpenBLAS on ARM: - The first one occured on ARMv5 platforms, when the ARMV5 OpenBLAS architecture is used. In this case, OpenBLAS build system forces -march=armv5, which may not be correct for certain toolchains. As an example, the Sourcery CodeBench toolchain has an ARMv4 and an ARMv5 sysroot. The ARMv5 sysroot is actually an armv5te sysroot, so when OpenBLAS forces -march=armv5, gcc thinks it should use the ARMv4 sysroot, causing build failures. To address this, a patch to completely remove the -march ARM CFLAGS is added to OpenBLAS. Fixes: http://autobuild.buildroot.net/results/991497b12b70f948169e5ad99eebd0fe7f6209a2/ - The second one occured on ARMv7 platforms, when the ARMV7 OpenBLAS architecture is used. The OpenBLAS code expects an EABIhf build, so a dependency is added for EABIhf for both ARMv6 and ARMv7. Fixes: http://autobuild.buildroot.net/results/0ba0bee48a83367fcefab827e8eaa72f0c8fe90b/ - Once the previous ARMv7 problem has been fixed, it turns out that the ARMv7 specific code in OpenBLAS contains VFPv3 specific code. Therefore, the user *must* have choosen either VFPv3 or VFPv4, or the code will not build. VFPv3-D16/VFPv4-D16 are not sufficient, as more than 16 registers are used by the OpenBLAS code. To address this, the ARMV7 platform of OpenBLAS is restricted to the proper VFPv3/VFPv4 selection, and the ARMV6 platform is restricted to the proper VFPv2 selection. This problem was not visible in the autobuilders, as it was hidden by the previous one. Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-08-07 23:32:34 +02:00
# On ARMv6, OpenBLAS assumes that a VFP is available, and
# EABIhf is used
default "ARMV6" if (BR2_ARM_CPU_ARMV6 && BR2_ARM_EABIHF && \
BR2_ARM_CPU_HAS_VFPV2)
# On ARMv7, OpenBLAS assumes that a full VFPv3+ is available
# (and not the more limited D16 variant), and that EABIhf is
# used.
default "ARMV7" if (BR2_ARM_CPU_ARMV7A && BR2_ARM_EABIHF && \
BR2_ARM_CPU_HAS_VFPV3)
openblas: new package OpenBLAS is optimised for specific CPU models, which don't fully match with the GCC code generation options. Therefore, we can't automatically select BR2_PACKAGE_OPENBLAS_TARGET based on the CPU choice. Instead, let the user select the TARGET name, but offer a sensible default. Other possible solutions were deemed too complicated: adding choice options in the ambiguous cases, or only making the option user-visible when there is ambiguity. Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-06-27 10:44:50 +02:00
default "ARMV8" if BR2_aarch64 || BR2_aarch64_be
help
OpenBLAS target CPU. See TargetList.txt in the source tree for
the possible target strings. A possible value is set
automatically based on your Target Architecture Variant.
config BR2_PACKAGE_OPENBLAS_ARCH_SUPPORTS
bool
default y if BR2_PACKAGE_OPENBLAS_DEFAULT_TARGET != ""
config BR2_PACKAGE_OPENBLAS
bool "openblas"
depends on BR2_PACKAGE_OPENBLAS_ARCH_SUPPORTS
help
An optimized BLAS library based on GotoBLAS2 1.13 BSD version.
https://www.openblas.net/
if BR2_PACKAGE_OPENBLAS
config BR2_PACKAGE_OPENBLAS_TARGET
string "OpenBLAS target CPU"
default BR2_PACKAGE_OPENBLAS_DEFAULT_TARGET
package/openblas: allow disabling multithreading Buildroot would automatically enable multithreading in OpenBLAS if the architecture supports it. However, one may want to avoid OpenBLAS creating threads itself and configure single-threaded operation. To accommodate this use case, add a config option for multithreading. When multithreading is disabled but OpenBLAS functions are called in the same application by multiple threads, then locking is mandatory. The USE_LOCKING flag was added in version 0.3.7 with following release note: a new option USE_LOCKING was added to ensure thread safety when OpenBLAS itself is built without multithreading but will be called from multiple threads. However, if one knows that OpenBLAS will only be called from single-threaded applications, then passing USE_LOCKING is not necessary, so make it a config option too. When multithreading is enabled, locking is implicitly enabled inside openblas, so only provide the locking option when multithreading is disabled. Signed-off-by: Thomas De Schampheleire <thomas.de_schampheleire@nokia.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
2021-02-12 10:15:09 +01:00
config BR2_PACKAGE_OPENBLAS_USE_THREAD
bool "use multithreading"
default y
depends on BR2_TOOLCHAIN_HAS_THREADS
depends on !BR2_STATIC_LIBS
help
Tell OpenBLAS to use multithreading, by passing USE_THREAD=1.
config BR2_PACKAGE_OPENBLAS_USE_LOCKING
bool "use locking"
default y
depends on BR2_TOOLCHAIN_HAS_THREADS
depends on !BR2_PACKAGE_OPENBLAS_USE_THREAD
help
Tell OpenBLAS to use locking, by passing USE_LOCKING=1.
Locking is implicitly enabled when USE_THREAD=1.
However, if USE_THREAD=0 (i.e. OpenBLAS itself will run in
single-threaded mode) but an application makes OpenBLAS
function calls from multiple threads, then locking is
mandatory for correct operation.
openblas: new package OpenBLAS is optimised for specific CPU models, which don't fully match with the GCC code generation options. Therefore, we can't automatically select BR2_PACKAGE_OPENBLAS_TARGET based on the CPU choice. Instead, let the user select the TARGET name, but offer a sensible default. Other possible solutions were deemed too complicated: adding choice options in the ambiguous cases, or only making the option user-visible when there is ambiguity. Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> Signed-off-by: Thomas Petazzoni <thomas.petazzoni@free-electrons.com>
2016-06-27 10:44:50 +02:00
endif
Reference in New Issue Copy Permalink