Known Issues
With hwloc enabled, some applications integrating Ginkgo seem to have a very significant slowdown in performance. For this reason, if you observe lower performance than expected, please try to build Ginkgo with GINKGO_BUILD_HWLOC=off.
When using custom value types with Ginkgo (non-default ones), due to atomic operations not supporting custom value types, there may be some execution problems with some kernels. For more details, see issue 65.
CMake currently requires to know that it needs to link against CUDA as soon as one of your dependencies require it (there will be an error about CMAKE_CUDA_DEVICE_LINK_EXECUTABLE not being set). At the time of writing, it is still an open CMake issue.
To prevent the error, you can use enable_language(CUDA) in your CMakeLists.txt before using parts of Ginkgo.
Alternatively, it is also possible to remove the CUDA link dependency from the installed file ${CMAKE_INSTALL_PREFIX}/lib/cmake/Ginkgo/GinkgoTargets.cmake. From this:
IMPORTED_LINK_INTERFACE_LANGUAGES_DEBUG "CUDA;CXX"(It will look slightly different when Ginkgo was compiled in Release mode) to this:
IMPORTED_LINK_INTERFACE_LANGUAGES_DEBUG "CXX"We might automate this altering in the future.
This error only appears when having Ginkgo installed as a static library with CUDA, for shared libraries or when not having CUDA, the error should not occur.
If test/components/prefix_sum_dpcpp sometimes fails, it is related to the sync issue.
If the first kernel call does not really do anything but call sync in the end, the sync after the second call may not actually wait for second kernel.
first kernel call (do not do anything due to condition) -> sync -> second kernel call -> sync (may not wait second kernel)
It should be already fixed after final release 2023.1. If you face the error with compiler 2023.1, it might be not the final release.
If you face any issue with the compiler >= 2023.1, please report it in github.
On Arch Linux (and potentially other operating systems), using the latest (and default) g++ (at the time of writing, g++ (GCC) 10.1.0)
leads to linking errors like:
/usr/bin/ld: third_party/gtest/build/googlemock/gtest/./libgtestd.a(gtest-all.cc.o): in function `testing::Message::Message()':
ginkgo_github/build/debug/third_party/gtest/src/googletest/src/gtest.cc:979: undefined reference to `std::__cxx11::basic_stringstream<char, std::char_traits<char>, std::allocator<char> >::basic_stringstream()'
This can happen when compiling Ginkgo with tests or also when compiling it with the example custom-matrix-format.
The reason for failing is that part of the CUDA tests and the one examples are compiled with CUDA, using an older g++ version than 10,
which has linking problems with the shared core library, which is compiled with version 10.
The fix for this error is using g++-8 as the C++ compiler. This can be done by using the system variable export CXX="g++-8" or by
setting the CMake variable CMAKE_CXX_COMPILER="g++-8".
That way, the CUDA host-code compiler is compatible with the compiler used for the CPU code for Ginkgo.
template <typename T>
constexpr bool is_complex() {
return is_complex_s<T>::value;
}
typename <typename T>
enable_if_t<is_complex<T>()> func() {}
typename <typename T>
enable_if_t<!is_complex<T>()> func() {}
// MSVC C2995 error: function template has already been defined
typename <typename T>
enable_if_t<is_complex_s<T>::value> func() {}
typename <typename T>
enable_if_t<!is_complex_s<T>::value> func() {}
// Work in MSVC
We found an issue in gtest v1.10.x (commit 6a7ed316a5cdc07b6d26362c90770787513822d4). The issue may be solved in future gtest versions.
If the testing class inheriting from ::testing::Test uses using T = ...; in its class definition, MSVC will be confused and throw error C2039: ... is not a member of ....
To avoid it, do not use any using T = ...; in the class.
Note: using T = ...; is fine in the test function.
C++ Compiler 14.29.30037 shipped from Visual Studio 16.10 can not compile the code with CUDA 11.
Please use the previous version or the newer one.
The detail of issue: https://developercommunity.visualstudio.com/t/MSVC-C142930037-with-CUDA-112-occur/1437930
