Shuenhoy/vtk-m
1
0
Fork 0
mirror of https://gitlab.kitware.com/vtk/vtk-m synced 2024-09-16 17:22:55 +00:00
Code Issues 2 Actions Packages Projects Releases Wiki Activity
master
vtk-m/vtkm/cont/cuda/internal/CMakeLists.txt

41 lines
1.3 KiB
CMake
Raw Permalink Normal View History

Adding a cuda device adapter to vtkm. Porting the dax device adapter over to vtkm. Unlike the dax version, doesn't use the thrust::device_vector, but instead uses thrust::system calls so that we can support multiple thrust based backends. Also this has Texture Memory support for input array handles. Some more work will need to be done to ArrayHandle so that everything works when using an ArrayHandle inplace with texture memory bindings.
2014-11-26 17:19:46 +00:00
##============================================================================
## Copyright (c) Kitware, Inc.
## All rights reserved.
## See LICENSE.txt for details.
conslidate the license statement
2019-04-15 23:24:21 +00:00
##
Adding a cuda device adapter to vtkm. Porting the dax device adapter over to vtkm. Unlike the dax version, doesn't use the thrust::device_vector, but instead uses thrust::system calls so that we can support multiple thrust based backends. Also this has Texture Memory support for input array handles. Some more work will need to be done to ArrayHandle so that everything works when using an ArrayHandle inplace with texture memory bindings.
2014-11-26 17:19:46 +00:00
## This software is distributed WITHOUT ANY WARRANTY; without even
## the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR
## PURPOSE. See the above copyright notice for more information.
##============================================================================
set(headers
Add CudaAllocator to encapsulate runtime managed memory logic. Unified memory is now used when we detect that the hardware supports it.
2017-07-14 14:36:15 +00:00
CudaAllocator.h
Adding a cuda device adapter to vtkm. Porting the dax device adapter over to vtkm. Unlike the dax version, doesn't use the thrust::device_vector, but instead uses thrust::system calls so that we can support multiple thrust based backends. Also this has Texture Memory support for input array handles. Some more work will need to be done to ArrayHandle so that everything works when using an ArrayHandle inplace with texture memory bindings.
2014-11-26 17:19:46 +00:00
DeviceAdapterAlgorithmCuda.h
Add Buffer class The buffer class encapsulates the movement of raw C arrays between host and devices. The `Buffer` class itself is not associated with any device. Instead, `Buffer` is used in conjunction with a new templated class named `DeviceAdapterMemoryManager` that can allocate data on a given device and transfer data as necessary. `DeviceAdapterMemoryManager` will eventually replace the more complicated device adapter classes that manage data on a device. The code in `DeviceAdapterMemoryManager` is actually enclosed in virtual methods. This allows us to limit the number of classes that need to be compiled for a device. Rather, the implementation of `DeviceAdapterMemoryManager` is compiled once with whatever compiler is necessary, and then the `RuntimeDeviceInformation` is used to get the correct object instance.
2020-03-26 23:34:18 +00:00
DeviceAdapterMemoryManagerCuda.h
CUDA's RuntimeDeviceTracker and Timer are now built as part of vtkm_cont This is done to not only reduce the amount of code that users need to generate but to reduce the amount of errors when using the RuntimeDeviceTracker. If the runtime device tracker is initially used in a library by a c++ file it will never properly detect the cuda backend. By moving the code into vtkm_cont we can make sure this problem doesn't occur.
2018-05-10 13:08:03 +00:00
DeviceAdapterRuntimeDetectorCuda.h
Adding a cuda device adapter to vtkm. Porting the dax device adapter over to vtkm. Unlike the dax version, doesn't use the thrust::device_vector, but instead uses thrust::system calls so that we can support multiple thrust based backends. Also this has Texture Memory support for input array handles. Some more work will need to be done to ArrayHandle so that everything works when using an ArrayHandle inplace with texture memory bindings.
2014-11-26 17:19:46 +00:00
DeviceAdapterTagCuda.h
CUDA's RuntimeDeviceTracker and Timer are now built as part of vtkm_cont This is done to not only reduce the amount of code that users need to generate but to reduce the amount of errors when using the RuntimeDeviceTracker. If the runtime device tracker is initially used in a library by a c++ file it will never properly detect the cuda backend. By moving the code into vtkm_cont we can make sure this problem doesn't occur.
2018-05-10 13:08:03 +00:00
DeviceAdapterTimerImplementationCuda.h
Resolves Issue #42. Now all thrust API calls are in try/catch blocks.
2015-09-07 16:20:31 +00:00
MakeThrustIterator.h
Implement RuntimeDeviceConfiguration
2021-05-26 19:43:36 +00:00
RuntimeDeviceConfigurationCuda.h
Add Kokkos backend
2020-06-16 12:54:01 +00:00
ScopedCudaStackSize.h
Resolves Issue #42. Now all thrust API calls are in try/catch blocks.
2015-09-07 16:20:31 +00:00
ThrustExceptionHandler.h
Adding a cuda device adapter to vtkm. Porting the dax device adapter over to vtkm. Unlike the dax version, doesn't use the thrust::device_vector, but instead uses thrust::system calls so that we can support multiple thrust based backends. Also this has Texture Memory support for input array handles. Some more work will need to be done to ArrayHandle so that everything works when using an ArrayHandle inplace with texture memory bindings.
2014-11-26 17:19:46 +00:00
)
VTK-m yet again has properly installed headers. Fixes the install issues mentioned in #342
2019-01-24 19:26:40 +00:00
vtkm_declare_headers(${headers})
Adding a cuda device adapter to vtkm. Porting the dax device adapter over to vtkm. Unlike the dax version, doesn't use the thrust::device_vector, but instead uses thrust::system calls so that we can support multiple thrust based backends. Also this has Texture Memory support for input array handles. Some more work will need to be done to ArrayHandle so that everything works when using an ArrayHandle inplace with texture memory bindings.
2014-11-26 17:19:46 +00:00
Re-implement DeviceAdapterRuntimeDetector to avoid ODR violations. The previous implementation of DeviceAdapterRuntimeDetector caused multiple differing definitions of the same class to exist and was causing the runtime device tracker to report CUDA as disabled when it actually was enabled. The ODR was caused by having a default implementation for DeviceAdapterRuntimeDetector and a specific specialization for CUDA. If a library had both CUDA and C++ sources it would pick up both implementations and would have undefined behavior. In general it would think the CUDA backend was disabled. To avoid this kind of situation in the future I have reworked VTK-m so that each device adapter must implement DeviceAdapterRuntimeDetector for that device.
2018-05-14 20:21:30 +00:00
cmake: namespace vtkm export targets
2022-12-09 23:46:56 +00:00
if (TARGET vtkm_cuda)
Require CMake 3.8 to build VTK-m.
2019-01-09 15:04:34 +00:00
target_sources(vtkm_cont PRIVATE
${CMAKE_CURRENT_SOURCE_DIR}/CudaAllocator.cu
${CMAKE_CURRENT_SOURCE_DIR}/DeviceAdapterAlgorithmCuda.cu
Add Buffer class The buffer class encapsulates the movement of raw C arrays between host and devices. The `Buffer` class itself is not associated with any device. Instead, `Buffer` is used in conjunction with a new templated class named `DeviceAdapterMemoryManager` that can allocate data on a given device and transfer data as necessary. `DeviceAdapterMemoryManager` will eventually replace the more complicated device adapter classes that manage data on a device. The code in `DeviceAdapterMemoryManager` is actually enclosed in virtual methods. This allows us to limit the number of classes that need to be compiled for a device. Rather, the implementation of `DeviceAdapterMemoryManager` is compiled once with whatever compiler is necessary, and then the `RuntimeDeviceInformation` is used to get the correct object instance.
2020-03-26 23:34:18 +00:00
${CMAKE_CURRENT_SOURCE_DIR}/DeviceAdapterMemoryManagerCuda.cu
Require CMake 3.8 to build VTK-m.
2019-01-09 15:04:34 +00:00
${CMAKE_CURRENT_SOURCE_DIR}/DeviceAdapterRuntimeDetectorCuda.cu
${CMAKE_CURRENT_SOURCE_DIR}/DeviceAdapterTimerImplementationCuda.cu
)
else()
#build the file with cpp compiler if cuda is disabled
Re-implement DeviceAdapterRuntimeDetector to avoid ODR violations. The previous implementation of DeviceAdapterRuntimeDetector caused multiple differing definitions of the same class to exist and was causing the runtime device tracker to report CUDA as disabled when it actually was enabled. The ODR was caused by having a default implementation for DeviceAdapterRuntimeDetector and a specific specialization for CUDA. If a library had both CUDA and C++ sources it would pick up both implementations and would have undefined behavior. In general it would think the CUDA backend was disabled. To avoid this kind of situation in the future I have reworked VTK-m so that each device adapter must implement DeviceAdapterRuntimeDetector for that device.
2018-05-14 20:21:30 +00:00
target_sources(vtkm_cont PRIVATE
${CMAKE_CURRENT_SOURCE_DIR}/DeviceAdapterRuntimeDetectorCuda.cxx
)
A thought on what CMake 3.9 would mean to VTK-m.
2017-09-25 12:47:47 +00:00
endif()
Reference in New Issue Copy Permalink