- 28 Oct, 2019 1 commit
-
-
Pavel Kus authored
This commit addresses several issues. It essentially forbids the use of the GPU kernel, which become obsolete and caused problems. But it does not complete remove the related code, nor does it forbid from explicitly selecting the GPU kernel. However, if the user does select it, the warning will be issued and the GENERIC kernel would be used instead. In the more details: * Commentin out operations in the GPU kernel, which do not compile with CUDA 10.1. This makes the kernel deffinitely not ussable (but it was true even before) * removing the gpu_tridiag_band option, sincie the tridiag->banded routine is actually not ported to GPU at all. This step will thus always be run on the CPU * removing the gpu_trans_ev_tridi_to_band option, since the GPU version of this step cannot run without the GPU kernel and it is not usable. This step will thus also be performed on the CPU * modifying REAL_GPU_KERNEL_ONLY_WHEN_GPU_IS_ACTIVE and COMPLEX_GPU_KERNEL_ONLY_WHEN_GPU_IS_ACTIVE such that the GPU kernel is not considered during the autotuning * TODO however, the GPU kernel can still be enforced by the user. In this case, during the calculation, a warning is issued and the kernel is switched to the GENERIC one. This should be improved and there should not even be the possibility to choose the GPU kernel at the begining.
-
- 03 Aug, 2017 1 commit
-
-
Lorenz Huedepohl authored
Anything if it makes Andreas happy :)
-
- 06 Apr, 2017 1 commit
-
-
Andreas Marek authored
-
- 29 Mar, 2017 4 commits
-
-
Andreas Marek authored
-
Andreas Marek authored
-
Andreas Marek authored
-
Andreas Marek authored
- the functions now contain the appropiate real/complex in their name - unused functions have been removed as cleanup
-
- 28 Mar, 2017 2 commits
-
-
Andreas Marek authored
-
Andreas Marek authored
-
- 04 Aug, 2016 1 commit
-
-
Andreas Marek authored
-
- 18 May, 2016 1 commit
-
-
Andreas Marek authored
Both real and complex single-precision GPU versions are fixed now. This closses issue #8
-
- 18 Mar, 2016 1 commit
-
-
Andreas Marek authored
library It the configure option "--enable-single-precision" is specified, ELPA will also be build for single precision usage. The double precision and single precision will be available at the same time with names "solve_evp_real_1stage_double" or "solve_evp_real_1stage_single" and so on... This change immplied some major refactoring of the ELPA code: 1.) functions/procedures had to be renamed with suffix "_double" 2.) If necessary the same functions have to be available with suffix "_single" 3.) Variable kind definitions have to be consistent with the intented use To avoid uneccessary code duplication this is done (most of the time) with preprocessor string substitution. The documentation has been updated. NOT SUPPORTED are at the moment: - single precision usage of ELPA2 with kernels, others than "generic" and "generic_simple" - single precision usage of GPU
-