Shuenhoy/vtk-m
1
0
Fork 0
mirror of https://gitlab.kitware.com/vtk/vtk-m synced 2024-09-19 18:45:43 +00:00
Code Issues 2 Actions Packages Projects Releases Wiki Activity
557055b9cc
vtk-m/vtkm/cont/CellSetExplicit.cxx

174 lines
6.6 KiB
C++
Raw Normal View History

Streamline CellSetExplicit 1) Don't require a DeviceAdapter for the BuildConnectivity function (#131) 2) Explicitly instantiate default CellSetExplicit and CellSetSingleType
2017-08-10 20:13:58 +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
//
Streamline CellSetExplicit 1) Don't require a DeviceAdapter for the BuildConnectivity function (#131) 2) Explicitly instantiate default CellSetExplicit and CellSetSingleType
2017-08-10 20:13:58 +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.
//============================================================================
#define vtk_m_cont_CellSetExplicit_cxx
#include <vtkm/cont/CellSetExplicit.h>
Compile reverse connectivity builder into vtkm_cont library Because `CellSetExplicit` is a templated class, the implementation of most of its features is part of the header files. One of the things that was included was the code to build the reverse connectivity links. That is, it figured out which cells were incident on each point using the standard connections of which points comprise which cells. Of course, building these links is non-trivial, and it used multiple DPPs to engage the device. It meant that header had to include the device adapter algorithms and therefore required a device compiler. We want to minimize this where possible. To get around this issue, a non-templated function was added to find the reverse connections of a `CellSetExplicit`. It does this by passing in `UnknownArrayHandle`s for the input arrays. (The output visit-points- with-cells arrays are standard across all template instances.) The implementation first iterates over all `CellSetExplicit` versions in `VTKM_DEFAULT_CELL_SETS` and attempts to retrieve arrays of those types. In the unlikely event that none of these arrays work, it copies the data to `ArrayHandle<vtkm::Id>` and uses those.
2021-08-18 19:55:19 +00:00
#include <vtkm/cont/Algorithm.h>
#include <vtkm/cont/ArrayCopy.h>
#include <vtkm/cont/DefaultTypes.h>
#include <vtkm/cont/Logging.h>
#include <vtkm/cont/TryExecute.h>
#include <vtkm/cont/internal/ReverseConnectivityBuilder.h>
namespace
{
template <typename ConnectStorage, typename OffsetStorage>
void DoBuildReverseConnectivity(
const vtkm::cont::ArrayHandle<vtkm::Id, ConnectStorage>& connections,
const vtkm::cont::ArrayHandle<vtkm::Id, OffsetStorage>& offsets,
vtkm::Id numberOfPoints,
vtkm::cont::detail::DefaultVisitPointsWithCellsConnectivityExplicit& visitPointsWithCells,
vtkm::cont::DeviceAdapterId suggestedDevice)
{
using CellsWithPointsConnectivity = vtkm::cont::internal::
ConnectivityExplicitInternals<VTKM_DEFAULT_STORAGE_TAG, ConnectStorage, OffsetStorage>;
// Make a fake visitCellsWithPoints to pass to ComputeRConnTable. This is a bit of a
// patchwork from changing implementation.
CellsWithPointsConnectivity visitCellsWithPoints;
visitCellsWithPoints.ElementsValid = true;
visitCellsWithPoints.Connectivity = connections;
visitCellsWithPoints.Offsets = offsets;
bool success =
vtkm::cont::TryExecuteOnDevice(suggestedDevice, [&](vtkm::cont::DeviceAdapterId realDevice) {
vtkm::cont::internal::ComputeRConnTable(
visitPointsWithCells, visitCellsWithPoints, numberOfPoints, realDevice);
return true;
});
if (!success)
{
throw vtkm::cont::ErrorExecution("Failed to run CellSetExplicit reverse "
"connectivity builder.");
}
}
struct BuildReverseConnectivityForCellSetType
{
template <typename ShapeStorage, typename ConnectStorage, typename OffsetStorage>
Fix performance issue with CellSetSingleType reverse connections When building the reverse connections (visit points with cells) for `CellSetSingleType`, the fast path for building these was not built due to a templating error.
2021-10-04 22:38:30 +00:00
void BuildExplicit(
const vtkm::cont::CellSetExplicit<ShapeStorage, ConnectStorage, OffsetStorage>*,
const vtkm::cont::UnknownArrayHandle* connections,
const vtkm::cont::UnknownArrayHandle* offsets,
Compile reverse connectivity builder into vtkm_cont library Because `CellSetExplicit` is a templated class, the implementation of most of its features is part of the header files. One of the things that was included was the code to build the reverse connectivity links. That is, it figured out which cells were incident on each point using the standard connections of which points comprise which cells. Of course, building these links is non-trivial, and it used multiple DPPs to engage the device. It meant that header had to include the device adapter algorithms and therefore required a device compiler. We want to minimize this where possible. To get around this issue, a non-templated function was added to find the reverse connections of a `CellSetExplicit`. It does this by passing in `UnknownArrayHandle`s for the input arrays. (The output visit-points- with-cells arrays are standard across all template instances.) The implementation first iterates over all `CellSetExplicit` versions in `VTKM_DEFAULT_CELL_SETS` and attempts to retrieve arrays of those types. In the unlikely event that none of these arrays work, it copies the data to `ArrayHandle<vtkm::Id>` and uses those.
2021-08-18 19:55:19 +00:00
vtkm::Id numberOfPoints,
Fix performance issue with CellSetSingleType reverse connections When building the reverse connections (visit points with cells) for `CellSetSingleType`, the fast path for building these was not built due to a templating error.
2021-10-04 22:38:30 +00:00
vtkm::cont::detail::DefaultVisitPointsWithCellsConnectivityExplicit* visitPointsWithCells,
vtkm::cont::DeviceAdapterId* device) const
Compile reverse connectivity builder into vtkm_cont library Because `CellSetExplicit` is a templated class, the implementation of most of its features is part of the header files. One of the things that was included was the code to build the reverse connectivity links. That is, it figured out which cells were incident on each point using the standard connections of which points comprise which cells. Of course, building these links is non-trivial, and it used multiple DPPs to engage the device. It meant that header had to include the device adapter algorithms and therefore required a device compiler. We want to minimize this where possible. To get around this issue, a non-templated function was added to find the reverse connections of a `CellSetExplicit`. It does this by passing in `UnknownArrayHandle`s for the input arrays. (The output visit-points- with-cells arrays are standard across all template instances.) The implementation first iterates over all `CellSetExplicit` versions in `VTKM_DEFAULT_CELL_SETS` and attempts to retrieve arrays of those types. In the unlikely event that none of these arrays work, it copies the data to `ArrayHandle<vtkm::Id>` and uses those.
2021-08-18 19:55:19 +00:00
{
Fix performance issue with CellSetSingleType reverse connections When building the reverse connections (visit points with cells) for `CellSetSingleType`, the fast path for building these was not built due to a templating error.
2021-10-04 22:38:30 +00:00
if (visitPointsWithCells->ElementsValid)
Compile reverse connectivity builder into vtkm_cont library Because `CellSetExplicit` is a templated class, the implementation of most of its features is part of the header files. One of the things that was included was the code to build the reverse connectivity links. That is, it figured out which cells were incident on each point using the standard connections of which points comprise which cells. Of course, building these links is non-trivial, and it used multiple DPPs to engage the device. It meant that header had to include the device adapter algorithms and therefore required a device compiler. We want to minimize this where possible. To get around this issue, a non-templated function was added to find the reverse connections of a `CellSetExplicit`. It does this by passing in `UnknownArrayHandle`s for the input arrays. (The output visit-points- with-cells arrays are standard across all template instances.) The implementation first iterates over all `CellSetExplicit` versions in `VTKM_DEFAULT_CELL_SETS` and attempts to retrieve arrays of those types. In the unlikely event that none of these arrays work, it copies the data to `ArrayHandle<vtkm::Id>` and uses those.
2021-08-18 19:55:19 +00:00
{
return; // Already computed reverse
}
using ConnectArrayType = vtkm::cont::ArrayHandle<vtkm::Id, ConnectStorage>;
using OffsetArrayType = vtkm::cont::ArrayHandle<vtkm::Id, OffsetStorage>;
Fix performance issue with CellSetSingleType reverse connections When building the reverse connections (visit points with cells) for `CellSetSingleType`, the fast path for building these was not built due to a templating error.
2021-10-04 22:38:30 +00:00
if (connections->CanConvert<ConnectArrayType>() && offsets->CanConvert<OffsetArrayType>())
Compile reverse connectivity builder into vtkm_cont library Because `CellSetExplicit` is a templated class, the implementation of most of its features is part of the header files. One of the things that was included was the code to build the reverse connectivity links. That is, it figured out which cells were incident on each point using the standard connections of which points comprise which cells. Of course, building these links is non-trivial, and it used multiple DPPs to engage the device. It meant that header had to include the device adapter algorithms and therefore required a device compiler. We want to minimize this where possible. To get around this issue, a non-templated function was added to find the reverse connections of a `CellSetExplicit`. It does this by passing in `UnknownArrayHandle`s for the input arrays. (The output visit-points- with-cells arrays are standard across all template instances.) The implementation first iterates over all `CellSetExplicit` versions in `VTKM_DEFAULT_CELL_SETS` and attempts to retrieve arrays of those types. In the unlikely event that none of these arrays work, it copies the data to `ArrayHandle<vtkm::Id>` and uses those.
2021-08-18 19:55:19 +00:00
{
Fix performance issue with CellSetSingleType reverse connections When building the reverse connections (visit points with cells) for `CellSetSingleType`, the fast path for building these was not built due to a templating error.
2021-10-04 22:38:30 +00:00
DoBuildReverseConnectivity(connections->AsArrayHandle<ConnectArrayType>(),
offsets->AsArrayHandle<OffsetArrayType>(),
Compile reverse connectivity builder into vtkm_cont library Because `CellSetExplicit` is a templated class, the implementation of most of its features is part of the header files. One of the things that was included was the code to build the reverse connectivity links. That is, it figured out which cells were incident on each point using the standard connections of which points comprise which cells. Of course, building these links is non-trivial, and it used multiple DPPs to engage the device. It meant that header had to include the device adapter algorithms and therefore required a device compiler. We want to minimize this where possible. To get around this issue, a non-templated function was added to find the reverse connections of a `CellSetExplicit`. It does this by passing in `UnknownArrayHandle`s for the input arrays. (The output visit-points- with-cells arrays are standard across all template instances.) The implementation first iterates over all `CellSetExplicit` versions in `VTKM_DEFAULT_CELL_SETS` and attempts to retrieve arrays of those types. In the unlikely event that none of these arrays work, it copies the data to `ArrayHandle<vtkm::Id>` and uses those.
2021-08-18 19:55:19 +00:00
numberOfPoints,
Fix performance issue with CellSetSingleType reverse connections When building the reverse connections (visit points with cells) for `CellSetSingleType`, the fast path for building these was not built due to a templating error.
2021-10-04 22:38:30 +00:00
*visitPointsWithCells,
*device);
Compile reverse connectivity builder into vtkm_cont library Because `CellSetExplicit` is a templated class, the implementation of most of its features is part of the header files. One of the things that was included was the code to build the reverse connectivity links. That is, it figured out which cells were incident on each point using the standard connections of which points comprise which cells. Of course, building these links is non-trivial, and it used multiple DPPs to engage the device. It meant that header had to include the device adapter algorithms and therefore required a device compiler. We want to minimize this where possible. To get around this issue, a non-templated function was added to find the reverse connections of a `CellSetExplicit`. It does this by passing in `UnknownArrayHandle`s for the input arrays. (The output visit-points- with-cells arrays are standard across all template instances.) The implementation first iterates over all `CellSetExplicit` versions in `VTKM_DEFAULT_CELL_SETS` and attempts to retrieve arrays of those types. In the unlikely event that none of these arrays work, it copies the data to `ArrayHandle<vtkm::Id>` and uses those.
2021-08-18 19:55:19 +00:00
}
}
Fix performance issue with CellSetSingleType reverse connections When building the reverse connections (visit points with cells) for `CellSetSingleType`, the fast path for building these was not built due to a templating error.
2021-10-04 22:38:30 +00:00
void BuildExplicit(...) const
Compile reverse connectivity builder into vtkm_cont library Because `CellSetExplicit` is a templated class, the implementation of most of its features is part of the header files. One of the things that was included was the code to build the reverse connectivity links. That is, it figured out which cells were incident on each point using the standard connections of which points comprise which cells. Of course, building these links is non-trivial, and it used multiple DPPs to engage the device. It meant that header had to include the device adapter algorithms and therefore required a device compiler. We want to minimize this where possible. To get around this issue, a non-templated function was added to find the reverse connections of a `CellSetExplicit`. It does this by passing in `UnknownArrayHandle`s for the input arrays. (The output visit-points- with-cells arrays are standard across all template instances.) The implementation first iterates over all `CellSetExplicit` versions in `VTKM_DEFAULT_CELL_SETS` and attempts to retrieve arrays of those types. In the unlikely event that none of these arrays work, it copies the data to `ArrayHandle<vtkm::Id>` and uses those.
2021-08-18 19:55:19 +00:00
{
// Not an explicit cell set, so skip.
}
Fix performance issue with CellSetSingleType reverse connections When building the reverse connections (visit points with cells) for `CellSetSingleType`, the fast path for building these was not built due to a templating error.
2021-10-04 22:38:30 +00:00
// Note that we are doing something a little weird here. We are taking a method templated
// on the cell set type, getting pointers of many of the arguments, and then calling
// a different overloaded method to do the actual work. Here is why.
//
// Our ultimate goal is to call one method if operating on `CellSetExplict` or
// _any subclass_. We also want to ignore any cell type that is not a `CellSetExplicit`
// or one of its sublcasses. So we want one templated method that specializes on a
// `CellSetExplicit` with its three template arguments and another that is templated on
// any `CellSet`. That works for a class of `CellSetExplicit`, but not of a subclass.
// A subclass will match the more generic class.
//
// We can get around that by use variadic arguments (e.g. `...` for the arguments), which
// we can easily do since we just want to ignore the arguments. C++ will match the arguments
// with templates before matching the C variadic arguments. However, these variadic
// arguments only work for POD types. To convert to POD types, we make a new overloaded
// method that accepts pointers instead. (Not sure why pointers work but references do not.)
template <typename CellSetType>
void operator()(
const CellSetType& cellset,
const vtkm::cont::UnknownArrayHandle& connections,
const vtkm::cont::UnknownArrayHandle& offsets,
vtkm::Id numberOfPoints,
vtkm::cont::detail::DefaultVisitPointsWithCellsConnectivityExplicit& visitPointsWithCells,
vtkm::cont::DeviceAdapterId device) const
{
this->BuildExplicit(
&cellset, &connections, &offsets, numberOfPoints, &visitPointsWithCells, &device);
}
Compile reverse connectivity builder into vtkm_cont library Because `CellSetExplicit` is a templated class, the implementation of most of its features is part of the header files. One of the things that was included was the code to build the reverse connectivity links. That is, it figured out which cells were incident on each point using the standard connections of which points comprise which cells. Of course, building these links is non-trivial, and it used multiple DPPs to engage the device. It meant that header had to include the device adapter algorithms and therefore required a device compiler. We want to minimize this where possible. To get around this issue, a non-templated function was added to find the reverse connections of a `CellSetExplicit`. It does this by passing in `UnknownArrayHandle`s for the input arrays. (The output visit-points- with-cells arrays are standard across all template instances.) The implementation first iterates over all `CellSetExplicit` versions in `VTKM_DEFAULT_CELL_SETS` and attempts to retrieve arrays of those types. In the unlikely event that none of these arrays work, it copies the data to `ArrayHandle<vtkm::Id>` and uses those.
2021-08-18 19:55:19 +00:00
};
} // anonymous namespace
Streamline CellSetExplicit 1) Don't require a DeviceAdapter for the BuildConnectivity function (#131) 2) Explicitly instantiate default CellSetExplicit and CellSetSingleType
2017-08-10 20:13:58 +00:00
namespace vtkm
{
namespace cont
{
template class VTKM_CONT_EXPORT CellSetExplicit<>; // default
template class VTKM_CONT_EXPORT
CellSetExplicit<typename vtkm::cont::ArrayHandleConstant<vtkm::UInt8>::StorageTag,
VTKM_DEFAULT_CONNECTIVITY_STORAGE_TAG,
typename vtkm::cont::ArrayHandleCounting<vtkm::Id>::StorageTag>;
Compile reverse connectivity builder into vtkm_cont library Because `CellSetExplicit` is a templated class, the implementation of most of its features is part of the header files. One of the things that was included was the code to build the reverse connectivity links. That is, it figured out which cells were incident on each point using the standard connections of which points comprise which cells. Of course, building these links is non-trivial, and it used multiple DPPs to engage the device. It meant that header had to include the device adapter algorithms and therefore required a device compiler. We want to minimize this where possible. To get around this issue, a non-templated function was added to find the reverse connections of a `CellSetExplicit`. It does this by passing in `UnknownArrayHandle`s for the input arrays. (The output visit-points- with-cells arrays are standard across all template instances.) The implementation first iterates over all `CellSetExplicit` versions in `VTKM_DEFAULT_CELL_SETS` and attempts to retrieve arrays of those types. In the unlikely event that none of these arrays work, it copies the data to `ArrayHandle<vtkm::Id>` and uses those.
2021-08-18 19:55:19 +00:00
namespace detail
{
void BuildReverseConnectivity(
const vtkm::cont::UnknownArrayHandle& connections,
const vtkm::cont::UnknownArrayHandle& offsets,
vtkm::Id numberOfPoints,
vtkm::cont::detail::DefaultVisitPointsWithCellsConnectivityExplicit& visitPointsWithCells,
vtkm::cont::DeviceAdapterId device)
{
if (visitPointsWithCells.ElementsValid)
{
return; // Already computed
}
vtkm::ListForEach(BuildReverseConnectivityForCellSetType{},
VTKM_DEFAULT_CELL_SET_LIST{},
connections,
offsets,
numberOfPoints,
visitPointsWithCells,
device);
if (!visitPointsWithCells.ElementsValid)
{
VTKM_LOG_S(vtkm::cont::LogLevel::Warn,
CellSetExplicit: reword warning message ParaView ends up triggering this in its test suite and the "failure" mention ends up triggering the "failed test" condition in its test harness. Reword to read more like a warning than an error.
2021-11-01 16:32:06 +00:00
"BuildReverseConnectivity attempted for all known cell set types; "
"falling back to copy connectivity arrays.");
Compile reverse connectivity builder into vtkm_cont library Because `CellSetExplicit` is a templated class, the implementation of most of its features is part of the header files. One of the things that was included was the code to build the reverse connectivity links. That is, it figured out which cells were incident on each point using the standard connections of which points comprise which cells. Of course, building these links is non-trivial, and it used multiple DPPs to engage the device. It meant that header had to include the device adapter algorithms and therefore required a device compiler. We want to minimize this where possible. To get around this issue, a non-templated function was added to find the reverse connections of a `CellSetExplicit`. It does this by passing in `UnknownArrayHandle`s for the input arrays. (The output visit-points- with-cells arrays are standard across all template instances.) The implementation first iterates over all `CellSetExplicit` versions in `VTKM_DEFAULT_CELL_SETS` and attempts to retrieve arrays of those types. In the unlikely event that none of these arrays work, it copies the data to `ArrayHandle<vtkm::Id>` and uses those.
2021-08-18 19:55:19 +00:00
vtkm::cont::ArrayHandle<vtkm::Id> connectionsCopy;
vtkm::cont::ArrayCopy(connections, connectionsCopy);
vtkm::cont::ArrayHandle<vtkm::Id> offsetsCopy;
vtkm::cont::ArrayCopy(offsets, offsetsCopy);
DoBuildReverseConnectivity(
connectionsCopy, offsetsCopy, numberOfPoints, visitPointsWithCells, device);
}
Streamline CellSetExplicit 1) Don't require a DeviceAdapter for the BuildConnectivity function (#131) 2) Explicitly instantiate default CellSetExplicit and CellSetSingleType
2017-08-10 20:13:58 +00:00
}
Compile reverse connectivity builder into vtkm_cont library Because `CellSetExplicit` is a templated class, the implementation of most of its features is part of the header files. One of the things that was included was the code to build the reverse connectivity links. That is, it figured out which cells were incident on each point using the standard connections of which points comprise which cells. Of course, building these links is non-trivial, and it used multiple DPPs to engage the device. It meant that header had to include the device adapter algorithms and therefore required a device compiler. We want to minimize this where possible. To get around this issue, a non-templated function was added to find the reverse connections of a `CellSetExplicit`. It does this by passing in `UnknownArrayHandle`s for the input arrays. (The output visit-points- with-cells arrays are standard across all template instances.) The implementation first iterates over all `CellSetExplicit` versions in `VTKM_DEFAULT_CELL_SETS` and attempts to retrieve arrays of those types. In the unlikely event that none of these arrays work, it copies the data to `ArrayHandle<vtkm::Id>` and uses those.
2021-08-18 19:55:19 +00:00
} // namespace vtkm::cont::detail
} // namespace vtkm::cont
} // namespace vtkm
Reference in New Issue Copy Permalink