| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
| |
For NVCC the compiler takes care of device linking when passed the "-dlink"
flag.
Clang doesn't support such magic and requires the buildsystem to do the work
that NVCC does behind the scenes.
The implementation is based on Bazel's device linking documentation:
https://github.com/tensorflow/tensorflow/blob/7cabcdf073abad8c46e9dda62bb8fa4682d2061e/third_party/nccl/build_defs.bzl.tpl#L259
Closes: #20726
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In commit a653ca9504 (Tests: Update CUDA tests to work with Clang,
2020-03-27) some tests were conditioned using `CMAKE_CUDA_COMPILER_ID`.
That is not defined when configuring CMake itself, so it accidentally
turned off NVCC-specific CUDA tests altogether. Convert the conditions
to check `CMake_TEST_CUDA` for `Clang` instead. That option is added
explicitly to builds where we want the tests to run, so we can set it to
a value indicating the CUDA compiler vendor.
In commit a653ca9504 (Tests: Update CUDA tests to work with Clang,
2020-03-27) the NVCC-specific `CudaOnly.GPUDebugFlag` test was
accidentally broken by removing a space when appending `-G` to the CUDA
flags. This was covered by the test not running. Restore the space.
Fixes: #20727
|
| |
|
|\
| |
| |
| |
| |
| |
| |
| |
| | |
6e474364d1 CUDAToolkit: No targets now depend on the CUDA runtime
907bb7df57 CUDAToolkit: Gracefully handle missing SDK components
e500eb80cd CUDAToolkit: add_cuda_link_dependency correctly sets dependencies
Acked-by: Kitware Robot <kwrobot@kitware.com>
Merge-request: !4183
|
| |
| |
| |
| |
| |
| | |
It is not a requirement to have shared|static consistent across your
CUDA libraries (e.g curand, nppc ) and your CUDA runtime library.
It is entirely allowable to use a static nppc and a shared runtime.
|
|\ \
| |/
|/| |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When CUDA is enabled, and a pure non-CUDA target has
CMAKE_CUDA_SEPARABLE_COMPILATION enabled, don't actually perform
the device linking step, as it will fail. A target that has
CMAKE_CUDA_SEPARABLE_COMPILATION enabled must also have CUDA
usage (either itself, or something it links to).
Fixes: #20182
|
| |
| |
| |
| |
| |
| | |
Refined the initial design of FindCUDAToolkit and improve it
by adding more library support, more toolkit information and
tests.
|
|/ |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Checks added in commit 81b4d10d8f (CUDA: More exhaustive checks to
determine when to do device linking, 2019-05-09, v3.15.0-rc1~82^2)
assumed that CUDA properties would be set only if CUDA is enabled.
We cannot do a device link step if we do not have the CUDA language
enabled. This was discovered as some projects unconditionally set CUDA
properties such as `CUDA_RESOLVE_DEVICE_SYMBOLS` even when the CUDA
language has not been enabled.
Fixes: #19432
|
|
|
|
|
|
|
|
|
| |
Convert the `CudaOnly.LinkSystemDeviceLibraries` test to a new
`Cuda.ProperDeviceLibraries` test. The former covered only the
`cublas_device` library which is removed by CUDA 10. Extend the new
test to also cover various cases of using threads.
Issue: #18008
|
|
|
|
|
|
|
|
|
|
|
| |
When C++ features require a certain C++/CUDA level, verify or update the
standard level target property for each language independently.
While at it, add missing rejection of invalid `CUDA_STANDARD` property
values.
Co-Author: Brad King <brad.king@kitware.com>
Fixes: #17519
|
|
|
|
| |
An executable using CUDA and C should link as CUDA.
|
|
|
|
|
| |
The `nvcc -v` output provides what include directories need to be added
to use the CUDA toolkit from other languages ( C/C++ ).
|
| |
|
|
|