Shuenhoy/vtk-m
1
0
Fork 0
mirror of https://gitlab.kitware.com/vtk/vtk-m synced 2024-09-08 21:33:55 +00:00
Code Issues 2 Actions Packages Projects Releases Wiki Activity
master
vtk-m/vtkm/cont/internal/ArrayCopyUnknown.cxx

256 lines
8.1 KiB
C++
Raw Permalink Normal View History

Add general `ArrayCopy` between `UnknownArrayHandle`s Add an overload of `ArrayCopy` that takes `UnknownArrayHandle`s and copies them for (almost) any `ArrayHandle` type. The code uses `CastAndCallWithExtractedArray` to reduce the total number of copy conditions to about 100, which are all precompiled into the library. On a debug build on my mac, this creates a .o file of 21MB. That's not great, but not terrible. Hopefully, this can be used to consolidate copy implementations elsewhere.
2021-01-14 22:25:09 +00:00
//============================================================================
// Copyright (c) Kitware, Inc.
// All rights reserved.
// See LICENSE.txt for details.
//
// 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.
//============================================================================
#include <vtkm/cont/ArrayCopy.h>
Add ArrayCopy fast paths There are some common uses of `ArrayCopy` that don't use basic arrays. Rather than move away from `ArrayCopy` for these use cases, compile a special fast path for these cases. This required some restructuring of the code to get the template resolution to work correctly.
2022-01-20 17:46:40 +00:00
#include <vtkm/cont/ArrayCopyDevice.h>
#include <vtkm/cont/ArrayHandleIndex.h>
Add general `ArrayCopy` between `UnknownArrayHandle`s Add an overload of `ArrayCopy` that takes `UnknownArrayHandle`s and copies them for (almost) any `ArrayHandle` type. The code uses `CastAndCallWithExtractedArray` to reduce the total number of copy conditions to about 100, which are all precompiled into the library. On a debug build on my mac, this creates a .o file of 21MB. That's not great, but not terrible. Hopefully, this can be used to consolidate copy implementations elsewhere.
2021-01-14 22:25:09 +00:00
#include <vtkm/cont/DeviceAdapterList.h>
#include <vtkm/cont/Invoker.h>
Add copy methods to `UnknownArrayHandle` `vtkm::cont::UnknownArrayHandle` now provides a set of method that allows you to copy data from one `UnknownArrayHandle` to another. The first method, `DeepCopyFrom`, takes a source `UnknownArrayHandle` and deep copies the data to the called one. If the `UnknownArrayHandle` already points to a real `ArrayHandle`, the data is copied into that `ArrayHandle`. If the `UnknownArrayHandle` does not point to an existing `ArrayHandle`, then a new `ArrayHandleBasic` with the same value type as the source is created and copied into. The second method, `CopyShallowIfPossibleFrom` behaves similarly to `DeepCopyFrom` except that it will perform a shallow copy if possible. That is, if the target `UnknownArrayHandle` points to an `ArrayHandle` of the same type as the source `UnknownArrayHandle`, then a shallow copy occurs and the underlying `ArrayHandle` will point to the source. If the types differ, then a deep copy is performed. If the target `UnknownArrayHandle` does not point to an `ArrayHandle`, then the behavior is the same as the `=` operator. One of the intentions of these new methods is to allow you to copy arrays without using a device compiler (e.g. `nvcc`). Calling `ArrayCopy` requires you to include the `ArrayCopy.h` header file, and that in turn requires device adapter algorithms. These methods insulate you from these.
2021-09-28 16:46:41 +00:00
#include <vtkm/cont/internal/ArrayCopyUnknown.h>
Add general `ArrayCopy` between `UnknownArrayHandle`s Add an overload of `ArrayCopy` that takes `UnknownArrayHandle`s and copies them for (almost) any `ArrayHandle` type. The code uses `CastAndCallWithExtractedArray` to reduce the total number of copy conditions to about 100, which are all precompiled into the library. On a debug build on my mac, this creates a .o file of 21MB. That's not great, but not terrible. Hopefully, this can be used to consolidate copy implementations elsewhere.
2021-01-14 22:25:09 +00:00
#include <vtkm/worklet/WorkletMapField.h>
namespace
{
// Use a worklet because device adapter copies often have an issue with casting the values from the
// `ArrayHandleRecomineVec` that comes from `UnknownArrayHandle::CastAndCallWithExtractedArray`.
struct CopyWorklet : vtkm::worklet::WorkletMapField
{
using ControlSignature = void(FieldIn, FieldOut);
using ExecutionSignature = void(_1, _2);
using InputDomain = _1;
template <typename InType, typename OutType>
Fix inverted `ArrayCopy` arguments Also fix condition where a `UnknownArrayHandle` destination does not have an underlying `ArrayHandle` set yet.
2021-02-03 00:30:02 +00:00
VTKM_EXEC void operator()(const InType& in, OutType& out) const
Add general `ArrayCopy` between `UnknownArrayHandle`s Add an overload of `ArrayCopy` that takes `UnknownArrayHandle`s and copies them for (almost) any `ArrayHandle` type. The code uses `CastAndCallWithExtractedArray` to reduce the total number of copy conditions to about 100, which are all precompiled into the library. On a debug build on my mac, this creates a .o file of 21MB. That's not great, but not terrible. Hopefully, this can be used to consolidate copy implementations elsewhere.
2021-01-14 22:25:09 +00:00
{
out = in;
}
};
struct UnknownCopyOnDevice
{
bool Called = false;
Properly check whether ArrayHandleRecombineVec is on device The `ArrayCopy` was simply calling `IsOnDevice` to see if the array from the `UnknownArrayHandle` was on a device. Seems right, but it is actually operating on an `ArrayHandleRecombineVec`. This is a special array that mostly behaves like other `ArrayHandle`s, but because it has variable vec size, it breaks some `ArrayHandle` conventions. One of the iffy things it has to do is stick the dependent `Buffer` objects into the metadata of its own `Buffer` rather than list them in the `Buffer` list. This means that `ArrayHandle` cannot properly check them to see where they are located. Instead, it just sees that the one `Buffer` it has is empty. A recent change to `IsOnDevice` made it return true for any device if the `Buffer` is empty. So previously this was broken in that it reported that the array was not on any device. That changed to report that it was on all devices, even inactive ones. So the code went from not efficiently copying to throwing an exception. This has been fixed by pulling one of the dependent arrays and checking that one.
2021-08-06 19:16:19 +00:00
template <typename InType, typename OutType>
Add general `ArrayCopy` between `UnknownArrayHandle`s Add an overload of `ArrayCopy` that takes `UnknownArrayHandle`s and copies them for (almost) any `ArrayHandle` type. The code uses `CastAndCallWithExtractedArray` to reduce the total number of copy conditions to about 100, which are all precompiled into the library. On a debug build on my mac, this creates a .o file of 21MB. That's not great, but not terrible. Hopefully, this can be used to consolidate copy implementations elsewhere.
2021-01-14 22:25:09 +00:00
void operator()(vtkm::cont::DeviceAdapterId device,
Properly check whether ArrayHandleRecombineVec is on device The `ArrayCopy` was simply calling `IsOnDevice` to see if the array from the `UnknownArrayHandle` was on a device. Seems right, but it is actually operating on an `ArrayHandleRecombineVec`. This is a special array that mostly behaves like other `ArrayHandle`s, but because it has variable vec size, it breaks some `ArrayHandle` conventions. One of the iffy things it has to do is stick the dependent `Buffer` objects into the metadata of its own `Buffer` rather than list them in the `Buffer` list. This means that `ArrayHandle` cannot properly check them to see where they are located. Instead, it just sees that the one `Buffer` it has is empty. A recent change to `IsOnDevice` made it return true for any device if the `Buffer` is empty. So previously this was broken in that it reported that the array was not on any device. That changed to report that it was on all devices, even inactive ones. So the code went from not efficiently copying to throwing an exception. This has been fixed by pulling one of the dependent arrays and checking that one.
2021-08-06 19:16:19 +00:00
const vtkm::cont::ArrayHandleRecombineVec<InType>& in,
const vtkm::cont::ArrayHandleRecombineVec<OutType>& out)
Add general `ArrayCopy` between `UnknownArrayHandle`s Add an overload of `ArrayCopy` that takes `UnknownArrayHandle`s and copies them for (almost) any `ArrayHandle` type. The code uses `CastAndCallWithExtractedArray` to reduce the total number of copy conditions to about 100, which are all precompiled into the library. On a debug build on my mac, this creates a .o file of 21MB. That's not great, but not terrible. Hopefully, this can be used to consolidate copy implementations elsewhere.
2021-01-14 22:25:09 +00:00
{
Properly check whether ArrayHandleRecombineVec is on device The `ArrayCopy` was simply calling `IsOnDevice` to see if the array from the `UnknownArrayHandle` was on a device. Seems right, but it is actually operating on an `ArrayHandleRecombineVec`. This is a special array that mostly behaves like other `ArrayHandle`s, but because it has variable vec size, it breaks some `ArrayHandle` conventions. One of the iffy things it has to do is stick the dependent `Buffer` objects into the metadata of its own `Buffer` rather than list them in the `Buffer` list. This means that `ArrayHandle` cannot properly check them to see where they are located. Instead, it just sees that the one `Buffer` it has is empty. A recent change to `IsOnDevice` made it return true for any device if the `Buffer` is empty. So previously this was broken in that it reported that the array was not on any device. That changed to report that it was on all devices, even inactive ones. So the code went from not efficiently copying to throwing an exception. This has been fixed by pulling one of the dependent arrays and checking that one.
2021-08-06 19:16:19 +00:00
// Note: ArrayHandleRecombineVec returns the wrong value for IsOnDevice (always true).
// This is one of the consequences of ArrayHandleRecombineVec breaking assumptions of
// ArrayHandle. It does this by stuffing Buffer objects in another Buffer's meta data
// rather than listing them explicitly (where they can be queried). We get around this
// by pulling out one of the component arrays and querying that.
if (!this->Called &&
((device == vtkm::cont::DeviceAdapterTagAny{}) ||
Fixed an issue with copying array from a disabled device The internal array copy has an optimization to use the device the array exists on to do the copy. However, if that device is disabled the copy would fail. This problem has been fixed.
2023-05-30 00:55:48 +00:00
(in.GetComponentArray(0).IsOnDevice(device) &&
vtkm::cont::GetRuntimeDeviceTracker().CanRunOn(device))))
Add general `ArrayCopy` between `UnknownArrayHandle`s Add an overload of `ArrayCopy` that takes `UnknownArrayHandle`s and copies them for (almost) any `ArrayHandle` type. The code uses `CastAndCallWithExtractedArray` to reduce the total number of copy conditions to about 100, which are all precompiled into the library. On a debug build on my mac, this creates a .o file of 21MB. That's not great, but not terrible. Hopefully, this can be used to consolidate copy implementations elsewhere.
2021-01-14 22:25:09 +00:00
{
vtkm::cont::Invoker invoke(device);
invoke(CopyWorklet{}, in, out);
this->Called = true;
}
}
};
struct UnknownCopyFunctor2
{
Properly check whether ArrayHandleRecombineVec is on device The `ArrayCopy` was simply calling `IsOnDevice` to see if the array from the `UnknownArrayHandle` was on a device. Seems right, but it is actually operating on an `ArrayHandleRecombineVec`. This is a special array that mostly behaves like other `ArrayHandle`s, but because it has variable vec size, it breaks some `ArrayHandle` conventions. One of the iffy things it has to do is stick the dependent `Buffer` objects into the metadata of its own `Buffer` rather than list them in the `Buffer` list. This means that `ArrayHandle` cannot properly check them to see where they are located. Instead, it just sees that the one `Buffer` it has is empty. A recent change to `IsOnDevice` made it return true for any device if the `Buffer` is empty. So previously this was broken in that it reported that the array was not on any device. That changed to report that it was on all devices, even inactive ones. So the code went from not efficiently copying to throwing an exception. This has been fixed by pulling one of the dependent arrays and checking that one.
2021-08-06 19:16:19 +00:00
template <typename OutType, typename InType>
void operator()(const vtkm::cont::ArrayHandleRecombineVec<OutType>& out,
const vtkm::cont::ArrayHandleRecombineVec<InType>& in) const
Add general `ArrayCopy` between `UnknownArrayHandle`s Add an overload of `ArrayCopy` that takes `UnknownArrayHandle`s and copies them for (almost) any `ArrayHandle` type. The code uses `CastAndCallWithExtractedArray` to reduce the total number of copy conditions to about 100, which are all precompiled into the library. On a debug build on my mac, this creates a .o file of 21MB. That's not great, but not terrible. Hopefully, this can be used to consolidate copy implementations elsewhere.
2021-01-14 22:25:09 +00:00
{
UnknownCopyOnDevice doCopy;
// Try to copy on a device that the data are already on.
vtkm::ListForEach(doCopy, VTKM_DEFAULT_DEVICE_ADAPTER_LIST{}, in, out);
// If it was not on any device, call one more time with any adapter to copy wherever.
doCopy(vtkm::cont::DeviceAdapterTagAny{}, in, out);
}
};
struct UnknownCopyFunctor1
{
Properly check whether ArrayHandleRecombineVec is on device The `ArrayCopy` was simply calling `IsOnDevice` to see if the array from the `UnknownArrayHandle` was on a device. Seems right, but it is actually operating on an `ArrayHandleRecombineVec`. This is a special array that mostly behaves like other `ArrayHandle`s, but because it has variable vec size, it breaks some `ArrayHandle` conventions. One of the iffy things it has to do is stick the dependent `Buffer` objects into the metadata of its own `Buffer` rather than list them in the `Buffer` list. This means that `ArrayHandle` cannot properly check them to see where they are located. Instead, it just sees that the one `Buffer` it has is empty. A recent change to `IsOnDevice` made it return true for any device if the `Buffer` is empty. So previously this was broken in that it reported that the array was not on any device. That changed to report that it was on all devices, even inactive ones. So the code went from not efficiently copying to throwing an exception. This has been fixed by pulling one of the dependent arrays and checking that one.
2021-08-06 19:16:19 +00:00
template <typename InType>
void operator()(const vtkm::cont::ArrayHandleRecombineVec<InType>& in,
Allow ArrayCopy into const ref of UnknownArrayHandle Added the following form of `ArrayCopy`: ```cpp VTKM_CONT_EXPORT void ArrayCopy( const vtkm::cont::UnknownArrayHandle& source, const vtkm::cont::UnknownArrayHandle& destination); ``` Note that the destination array is a constant reference. This is actually OK because you can change the contents of an `UnknownArrayHandle` (as long as you don't change the array being referenced). The main motivation for this change is to allow you to call this form of `ArrayCopy` while passing in a `ArrayHandle` as the second argument. C++ will automatically make the conversion, but the function has to accept a const reference for it to be passed correctly. Note that there is still a form of `ArrayCopy` that accepts a non-const reference to the destination array. The two arrays behave the same except for one difference. For the non-const version, if the `UnknownArrayHandle` does not already point to an array (i.e. is not valid), a new array will be created and placed in the destination object. However, because this cannot be done for a const reference, an exception is thrown instead.
2021-09-01 18:11:04 +00:00
const vtkm::cont::UnknownArrayHandle& out) const
Add general `ArrayCopy` between `UnknownArrayHandle`s Add an overload of `ArrayCopy` that takes `UnknownArrayHandle`s and copies them for (almost) any `ArrayHandle` type. The code uses `CastAndCallWithExtractedArray` to reduce the total number of copy conditions to about 100, which are all precompiled into the library. On a debug build on my mac, this creates a .o file of 21MB. That's not great, but not terrible. Hopefully, this can be used to consolidate copy implementations elsewhere.
2021-01-14 22:25:09 +00:00
{
out.Allocate(in.GetNumberOfValues());
Change ArrayCopy of UnknownArrayHandle to limit types Rather than copy every type to every other type, only copy for the same base type or copy to/from FloatDefault. This should reduce the amount of code generated by a lot. This reduces the size of the .o for ArrayCopy.cxx on my mac from 21MB to 7.7MB.
2021-01-14 23:56:13 +00:00
Properly check whether ArrayHandleRecombineVec is on device The `ArrayCopy` was simply calling `IsOnDevice` to see if the array from the `UnknownArrayHandle` was on a device. Seems right, but it is actually operating on an `ArrayHandleRecombineVec`. This is a special array that mostly behaves like other `ArrayHandle`s, but because it has variable vec size, it breaks some `ArrayHandle` conventions. One of the iffy things it has to do is stick the dependent `Buffer` objects into the metadata of its own `Buffer` rather than list them in the `Buffer` list. This means that `ArrayHandle` cannot properly check them to see where they are located. Instead, it just sees that the one `Buffer` it has is empty. A recent change to `IsOnDevice` made it return true for any device if the `Buffer` is empty. So previously this was broken in that it reported that the array was not on any device. That changed to report that it was on all devices, even inactive ones. So the code went from not efficiently copying to throwing an exception. This has been fixed by pulling one of the dependent arrays and checking that one.
2021-08-06 19:16:19 +00:00
this->DoIt(in, out, typename std::is_same<vtkm::FloatDefault, InType>::type{});
Change ArrayCopy of UnknownArrayHandle to limit types Rather than copy every type to every other type, only copy for the same base type or copy to/from FloatDefault. This should reduce the amount of code generated by a lot. This reduces the size of the .o for ArrayCopy.cxx on my mac from 21MB to 7.7MB.
2021-01-14 23:56:13 +00:00
}
Properly check whether ArrayHandleRecombineVec is on device The `ArrayCopy` was simply calling `IsOnDevice` to see if the array from the `UnknownArrayHandle` was on a device. Seems right, but it is actually operating on an `ArrayHandleRecombineVec`. This is a special array that mostly behaves like other `ArrayHandle`s, but because it has variable vec size, it breaks some `ArrayHandle` conventions. One of the iffy things it has to do is stick the dependent `Buffer` objects into the metadata of its own `Buffer` rather than list them in the `Buffer` list. This means that `ArrayHandle` cannot properly check them to see where they are located. Instead, it just sees that the one `Buffer` it has is empty. A recent change to `IsOnDevice` made it return true for any device if the `Buffer` is empty. So previously this was broken in that it reported that the array was not on any device. That changed to report that it was on all devices, even inactive ones. So the code went from not efficiently copying to throwing an exception. This has been fixed by pulling one of the dependent arrays and checking that one.
2021-08-06 19:16:19 +00:00
template <typename InType>
void DoIt(const vtkm::cont::ArrayHandleRecombineVec<InType>& in,
Allow ArrayCopy into const ref of UnknownArrayHandle Added the following form of `ArrayCopy`: ```cpp VTKM_CONT_EXPORT void ArrayCopy( const vtkm::cont::UnknownArrayHandle& source, const vtkm::cont::UnknownArrayHandle& destination); ``` Note that the destination array is a constant reference. This is actually OK because you can change the contents of an `UnknownArrayHandle` (as long as you don't change the array being referenced). The main motivation for this change is to allow you to call this form of `ArrayCopy` while passing in a `ArrayHandle` as the second argument. C++ will automatically make the conversion, but the function has to accept a const reference for it to be passed correctly. Note that there is still a form of `ArrayCopy` that accepts a non-const reference to the destination array. The two arrays behave the same except for one difference. For the non-const version, if the `UnknownArrayHandle` does not already point to an array (i.e. is not valid), a new array will be created and placed in the destination object. However, because this cannot be done for a const reference, an exception is thrown instead.
2021-09-01 18:11:04 +00:00
const vtkm::cont::UnknownArrayHandle& out,
Properly check whether ArrayHandleRecombineVec is on device The `ArrayCopy` was simply calling `IsOnDevice` to see if the array from the `UnknownArrayHandle` was on a device. Seems right, but it is actually operating on an `ArrayHandleRecombineVec`. This is a special array that mostly behaves like other `ArrayHandle`s, but because it has variable vec size, it breaks some `ArrayHandle` conventions. One of the iffy things it has to do is stick the dependent `Buffer` objects into the metadata of its own `Buffer` rather than list them in the `Buffer` list. This means that `ArrayHandle` cannot properly check them to see where they are located. Instead, it just sees that the one `Buffer` it has is empty. A recent change to `IsOnDevice` made it return true for any device if the `Buffer` is empty. So previously this was broken in that it reported that the array was not on any device. That changed to report that it was on all devices, even inactive ones. So the code went from not efficiently copying to throwing an exception. This has been fixed by pulling one of the dependent arrays and checking that one.
2021-08-06 19:16:19 +00:00
std::false_type) const
Change ArrayCopy of UnknownArrayHandle to limit types Rather than copy every type to every other type, only copy for the same base type or copy to/from FloatDefault. This should reduce the amount of code generated by a lot. This reduces the size of the .o for ArrayCopy.cxx on my mac from 21MB to 7.7MB.
2021-01-14 23:56:13 +00:00
{
// Source is not float.
Properly check whether ArrayHandleRecombineVec is on device The `ArrayCopy` was simply calling `IsOnDevice` to see if the array from the `UnknownArrayHandle` was on a device. Seems right, but it is actually operating on an `ArrayHandleRecombineVec`. This is a special array that mostly behaves like other `ArrayHandle`s, but because it has variable vec size, it breaks some `ArrayHandle` conventions. One of the iffy things it has to do is stick the dependent `Buffer` objects into the metadata of its own `Buffer` rather than list them in the `Buffer` list. This means that `ArrayHandle` cannot properly check them to see where they are located. Instead, it just sees that the one `Buffer` it has is empty. A recent change to `IsOnDevice` made it return true for any device if the `Buffer` is empty. So previously this was broken in that it reported that the array was not on any device. That changed to report that it was on all devices, even inactive ones. So the code went from not efficiently copying to throwing an exception. This has been fixed by pulling one of the dependent arrays and checking that one.
2021-08-06 19:16:19 +00:00
if (out.IsBaseComponentType<InType>())
Change ArrayCopy of UnknownArrayHandle to limit types Rather than copy every type to every other type, only copy for the same base type or copy to/from FloatDefault. This should reduce the amount of code generated by a lot. This reduces the size of the .o for ArrayCopy.cxx on my mac from 21MB to 7.7MB.
2021-01-14 23:56:13 +00:00
{
// Arrays have the same base component type. Copy directly.
Make ArrayCopy not depend on a device compiler Rather than require `ArrayCopy` to create special versions of copy for all arrays, use a precompiled versions. This should speed up compiles, reduce the amount of code being generated, and require the device compiler on fewer source files. There are some cases where you still need to copy arrays that are not well supported by the precompiled versions in `ArrayCopy`. (It will always work, but the fallback is very slow.) In this case, you will want to switch over to `ArrayCopyDevice`, which has the old behavior.
2022-01-05 21:46:37 +00:00
try
{
UnknownCopyFunctor2{}(out.ExtractArrayFromComponents<InType>(vtkm::CopyFlag::Off), in);
}
catch (vtkm::cont::Error& error)
{
throw vtkm::cont::ErrorBadType(
"Unable to copy to an array of type " + out.GetArrayTypeName() +
" using anonymous methods. Try using vtkm::cont::ArrayCopyDevice. "
"(Original error: `" +
error.GetMessage() + "')");
}
Change ArrayCopy of UnknownArrayHandle to limit types Rather than copy every type to every other type, only copy for the same base type or copy to/from FloatDefault. This should reduce the amount of code generated by a lot. This reduces the size of the .o for ArrayCopy.cxx on my mac from 21MB to 7.7MB.
2021-01-14 23:56:13 +00:00
}
else if (out.IsBaseComponentType<vtkm::FloatDefault>())
{
// Can copy anything to default float.
Make ArrayCopy not depend on a device compiler Rather than require `ArrayCopy` to create special versions of copy for all arrays, use a precompiled versions. This should speed up compiles, reduce the amount of code being generated, and require the device compiler on fewer source files. There are some cases where you still need to copy arrays that are not well supported by the precompiled versions in `ArrayCopy`. (It will always work, but the fallback is very slow.) In this case, you will want to switch over to `ArrayCopyDevice`, which has the old behavior.
2022-01-05 21:46:37 +00:00
try
{
UnknownCopyFunctor2{}(
out.ExtractArrayFromComponents<vtkm::FloatDefault>(vtkm::CopyFlag::Off), in);
}
catch (vtkm::cont::Error& error)
{
throw vtkm::cont::ErrorBadType(
"Unable to copy to an array of type " + out.GetArrayTypeName() +
" using anonymous methods. Try using vtkm::cont::ArrayCopyDevice. "
"(Original error: `" +
error.GetMessage() + "')");
}
Change ArrayCopy of UnknownArrayHandle to limit types Rather than copy every type to every other type, only copy for the same base type or copy to/from FloatDefault. This should reduce the amount of code generated by a lot. This reduces the size of the .o for ArrayCopy.cxx on my mac from 21MB to 7.7MB.
2021-01-14 23:56:13 +00:00
}
else
{
// Arrays have different base types. To reduce the number of template paths from nxn to 3n,
// copy first to a temp array of default float.
vtkm::cont::UnknownArrayHandle temp = out.NewInstanceFloatBasic();
(*this)(in, temp);
vtkm::cont::ArrayCopy(temp, out);
}
}
Properly check whether ArrayHandleRecombineVec is on device The `ArrayCopy` was simply calling `IsOnDevice` to see if the array from the `UnknownArrayHandle` was on a device. Seems right, but it is actually operating on an `ArrayHandleRecombineVec`. This is a special array that mostly behaves like other `ArrayHandle`s, but because it has variable vec size, it breaks some `ArrayHandle` conventions. One of the iffy things it has to do is stick the dependent `Buffer` objects into the metadata of its own `Buffer` rather than list them in the `Buffer` list. This means that `ArrayHandle` cannot properly check them to see where they are located. Instead, it just sees that the one `Buffer` it has is empty. A recent change to `IsOnDevice` made it return true for any device if the `Buffer` is empty. So previously this was broken in that it reported that the array was not on any device. That changed to report that it was on all devices, even inactive ones. So the code went from not efficiently copying to throwing an exception. This has been fixed by pulling one of the dependent arrays and checking that one.
2021-08-06 19:16:19 +00:00
template <typename InType>
void DoIt(const vtkm::cont::ArrayHandleRecombineVec<InType>& in,
Allow ArrayCopy into const ref of UnknownArrayHandle Added the following form of `ArrayCopy`: ```cpp VTKM_CONT_EXPORT void ArrayCopy( const vtkm::cont::UnknownArrayHandle& source, const vtkm::cont::UnknownArrayHandle& destination); ``` Note that the destination array is a constant reference. This is actually OK because you can change the contents of an `UnknownArrayHandle` (as long as you don't change the array being referenced). The main motivation for this change is to allow you to call this form of `ArrayCopy` while passing in a `ArrayHandle` as the second argument. C++ will automatically make the conversion, but the function has to accept a const reference for it to be passed correctly. Note that there is still a form of `ArrayCopy` that accepts a non-const reference to the destination array. The two arrays behave the same except for one difference. For the non-const version, if the `UnknownArrayHandle` does not already point to an array (i.e. is not valid), a new array will be created and placed in the destination object. However, because this cannot be done for a const reference, an exception is thrown instead.
2021-09-01 18:11:04 +00:00
const vtkm::cont::UnknownArrayHandle& out,
Properly check whether ArrayHandleRecombineVec is on device The `ArrayCopy` was simply calling `IsOnDevice` to see if the array from the `UnknownArrayHandle` was on a device. Seems right, but it is actually operating on an `ArrayHandleRecombineVec`. This is a special array that mostly behaves like other `ArrayHandle`s, but because it has variable vec size, it breaks some `ArrayHandle` conventions. One of the iffy things it has to do is stick the dependent `Buffer` objects into the metadata of its own `Buffer` rather than list them in the `Buffer` list. This means that `ArrayHandle` cannot properly check them to see where they are located. Instead, it just sees that the one `Buffer` it has is empty. A recent change to `IsOnDevice` made it return true for any device if the `Buffer` is empty. So previously this was broken in that it reported that the array was not on any device. That changed to report that it was on all devices, even inactive ones. So the code went from not efficiently copying to throwing an exception. This has been fixed by pulling one of the dependent arrays and checking that one.
2021-08-06 19:16:19 +00:00
std::true_type) const
Change ArrayCopy of UnknownArrayHandle to limit types Rather than copy every type to every other type, only copy for the same base type or copy to/from FloatDefault. This should reduce the amount of code generated by a lot. This reduces the size of the .o for ArrayCopy.cxx on my mac from 21MB to 7.7MB.
2021-01-14 23:56:13 +00:00
{
// Source array is FloatDefault. That should be copiable to anything.
Add general `ArrayCopy` between `UnknownArrayHandle`s Add an overload of `ArrayCopy` that takes `UnknownArrayHandle`s and copies them for (almost) any `ArrayHandle` type. The code uses `CastAndCallWithExtractedArray` to reduce the total number of copy conditions to about 100, which are all precompiled into the library. On a debug build on my mac, this creates a .o file of 21MB. That's not great, but not terrible. Hopefully, this can be used to consolidate copy implementations elsewhere.
2021-01-14 22:25:09 +00:00
out.CastAndCallWithExtractedArray(UnknownCopyFunctor2{}, in);
}
};
Add ArrayCopy fast paths There are some common uses of `ArrayCopy` that don't use basic arrays. Rather than move away from `ArrayCopy` for these use cases, compile a special fast path for these cases. This required some restructuring of the code to get the template resolution to work correctly.
2022-01-20 17:46:40 +00:00
void ArrayCopySpecialCase(const vtkm::cont::ArrayHandleIndex& source,
const vtkm::cont::UnknownArrayHandle& destination)
{
if (destination.CanConvert<vtkm::cont::ArrayHandleIndex>())
{
// Unlikely, but we'll check.
destination.AsArrayHandle<vtkm::cont::ArrayHandleIndex>().DeepCopyFrom(source);
}
else if (destination.IsBaseComponentType<vtkm::Id>())
{
destination.Allocate(source.GetNumberOfValues());
auto dest = destination.ExtractComponent<vtkm::Id>(0, vtkm::CopyFlag::Off);
vtkm::cont::ArrayCopyDevice(source, dest);
}
else if (destination.IsBaseComponentType<vtkm::IdComponent>())
{
destination.Allocate(source.GetNumberOfValues());
auto dest = destination.ExtractComponent<vtkm::IdComponent>(0, vtkm::CopyFlag::Off);
vtkm::cont::ArrayCopyDevice(source, dest);
}
else if (destination.CanConvert<vtkm::cont::ArrayHandle<vtkm::FloatDefault>>())
{
vtkm::cont::ArrayHandle<vtkm::FloatDefault> dest;
destination.AsArrayHandle(dest);
vtkm::cont::ArrayCopyDevice(source, dest);
}
else
{
// Initializing something that is probably not really an index. Rather than trace down every
// unlikely possibility, just copy to float and then to the final array.
vtkm::cont::ArrayHandle<vtkm::FloatDefault> dest;
vtkm::cont::ArrayCopyDevice(source, dest);
vtkm::cont::ArrayCopy(dest, destination);
}
}
template <typename ArrayHandleType>
bool TryArrayCopySpecialCase(const vtkm::cont::UnknownArrayHandle& source,
const vtkm::cont::UnknownArrayHandle& destination)
{
if (source.CanConvert<ArrayHandleType>())
{
ArrayCopySpecialCase(source.AsArrayHandle<ArrayHandleType>(), destination);
return true;
}
else
{
return false;
}
}
Allow ArrayCopy into const ref of UnknownArrayHandle Added the following form of `ArrayCopy`: ```cpp VTKM_CONT_EXPORT void ArrayCopy( const vtkm::cont::UnknownArrayHandle& source, const vtkm::cont::UnknownArrayHandle& destination); ``` Note that the destination array is a constant reference. This is actually OK because you can change the contents of an `UnknownArrayHandle` (as long as you don't change the array being referenced). The main motivation for this change is to allow you to call this form of `ArrayCopy` while passing in a `ArrayHandle` as the second argument. C++ will automatically make the conversion, but the function has to accept a const reference for it to be passed correctly. Note that there is still a form of `ArrayCopy` that accepts a non-const reference to the destination array. The two arrays behave the same except for one difference. For the non-const version, if the `UnknownArrayHandle` does not already point to an array (i.e. is not valid), a new array will be created and placed in the destination object. However, because this cannot be done for a const reference, an exception is thrown instead.
2021-09-01 18:11:04 +00:00
void DoUnknownArrayCopy(const vtkm::cont::UnknownArrayHandle& source,
const vtkm::cont::UnknownArrayHandle& destination)
{
if (source.GetNumberOfValues() > 0)
{
Add ArrayCopy fast paths There are some common uses of `ArrayCopy` that don't use basic arrays. Rather than move away from `ArrayCopy` for these use cases, compile a special fast path for these cases. This required some restructuring of the code to get the template resolution to work correctly.
2022-01-20 17:46:40 +00:00
// Try known special cases.
if (TryArrayCopySpecialCase<vtkm::cont::ArrayHandleIndex>(source, destination))
{
return;
}
Allow ArrayCopy into const ref of UnknownArrayHandle Added the following form of `ArrayCopy`: ```cpp VTKM_CONT_EXPORT void ArrayCopy( const vtkm::cont::UnknownArrayHandle& source, const vtkm::cont::UnknownArrayHandle& destination); ``` Note that the destination array is a constant reference. This is actually OK because you can change the contents of an `UnknownArrayHandle` (as long as you don't change the array being referenced). The main motivation for this change is to allow you to call this form of `ArrayCopy` while passing in a `ArrayHandle` as the second argument. C++ will automatically make the conversion, but the function has to accept a const reference for it to be passed correctly. Note that there is still a form of `ArrayCopy` that accepts a non-const reference to the destination array. The two arrays behave the same except for one difference. For the non-const version, if the `UnknownArrayHandle` does not already point to an array (i.e. is not valid), a new array will be created and placed in the destination object. However, because this cannot be done for a const reference, an exception is thrown instead.
2021-09-01 18:11:04 +00:00
source.CastAndCallWithExtractedArray(UnknownCopyFunctor1{}, destination);
}
else
{
destination.ReleaseResources();
}
}
Add general `ArrayCopy` between `UnknownArrayHandle`s Add an overload of `ArrayCopy` that takes `UnknownArrayHandle`s and copies them for (almost) any `ArrayHandle` type. The code uses `CastAndCallWithExtractedArray` to reduce the total number of copy conditions to about 100, which are all precompiled into the library. On a debug build on my mac, this creates a .o file of 21MB. That's not great, but not terrible. Hopefully, this can be used to consolidate copy implementations elsewhere.
2021-01-14 22:25:09 +00:00
} // anonymous namespace
namespace vtkm
{
namespace cont
{
Make ArrayCopy not depend on a device compiler Rather than require `ArrayCopy` to create special versions of copy for all arrays, use a precompiled versions. This should speed up compiles, reduce the amount of code being generated, and require the device compiler on fewer source files. There are some cases where you still need to copy arrays that are not well supported by the precompiled versions in `ArrayCopy`. (It will always work, but the fallback is very slow.) In this case, you will want to switch over to `ArrayCopyDevice`, which has the old behavior.
2022-01-05 21:46:37 +00:00
namespace internal
{
Add general `ArrayCopy` between `UnknownArrayHandle`s Add an overload of `ArrayCopy` that takes `UnknownArrayHandle`s and copies them for (almost) any `ArrayHandle` type. The code uses `CastAndCallWithExtractedArray` to reduce the total number of copy conditions to about 100, which are all precompiled into the library. On a debug build on my mac, this creates a .o file of 21MB. That's not great, but not terrible. Hopefully, this can be used to consolidate copy implementations elsewhere.
2021-01-14 22:25:09 +00:00
Make ArrayCopy not depend on a device compiler Rather than require `ArrayCopy` to create special versions of copy for all arrays, use a precompiled versions. This should speed up compiles, reduce the amount of code being generated, and require the device compiler on fewer source files. There are some cases where you still need to copy arrays that are not well supported by the precompiled versions in `ArrayCopy`. (It will always work, but the fallback is very slow.) In this case, you will want to switch over to `ArrayCopyDevice`, which has the old behavior.
2022-01-05 21:46:37 +00:00
void ArrayCopyUnknown(const vtkm::cont::UnknownArrayHandle& source,
vtkm::cont::UnknownArrayHandle& destination)
Add general `ArrayCopy` between `UnknownArrayHandle`s Add an overload of `ArrayCopy` that takes `UnknownArrayHandle`s and copies them for (almost) any `ArrayHandle` type. The code uses `CastAndCallWithExtractedArray` to reduce the total number of copy conditions to about 100, which are all precompiled into the library. On a debug build on my mac, this creates a .o file of 21MB. That's not great, but not terrible. Hopefully, this can be used to consolidate copy implementations elsewhere.
2021-01-14 22:25:09 +00:00
{
Fix inverted `ArrayCopy` arguments Also fix condition where a `UnknownArrayHandle` destination does not have an underlying `ArrayHandle` set yet.
2021-02-03 00:30:02 +00:00
if (!destination.IsValid())
{
destination = source.NewInstanceBasic();
}
Allow ArrayCopy into const ref of UnknownArrayHandle Added the following form of `ArrayCopy`: ```cpp VTKM_CONT_EXPORT void ArrayCopy( const vtkm::cont::UnknownArrayHandle& source, const vtkm::cont::UnknownArrayHandle& destination); ``` Note that the destination array is a constant reference. This is actually OK because you can change the contents of an `UnknownArrayHandle` (as long as you don't change the array being referenced). The main motivation for this change is to allow you to call this form of `ArrayCopy` while passing in a `ArrayHandle` as the second argument. C++ will automatically make the conversion, but the function has to accept a const reference for it to be passed correctly. Note that there is still a form of `ArrayCopy` that accepts a non-const reference to the destination array. The two arrays behave the same except for one difference. For the non-const version, if the `UnknownArrayHandle` does not already point to an array (i.e. is not valid), a new array will be created and placed in the destination object. However, because this cannot be done for a const reference, an exception is thrown instead.
2021-09-01 18:11:04 +00:00
DoUnknownArrayCopy(source, destination);
}
Make ArrayCopy not depend on a device compiler Rather than require `ArrayCopy` to create special versions of copy for all arrays, use a precompiled versions. This should speed up compiles, reduce the amount of code being generated, and require the device compiler on fewer source files. There are some cases where you still need to copy arrays that are not well supported by the precompiled versions in `ArrayCopy`. (It will always work, but the fallback is very slow.) In this case, you will want to switch over to `ArrayCopyDevice`, which has the old behavior.
2022-01-05 21:46:37 +00:00
void ArrayCopyUnknown(const vtkm::cont::UnknownArrayHandle& source,
const vtkm::cont::UnknownArrayHandle& destination)
Allow ArrayCopy into const ref of UnknownArrayHandle Added the following form of `ArrayCopy`: ```cpp VTKM_CONT_EXPORT void ArrayCopy( const vtkm::cont::UnknownArrayHandle& source, const vtkm::cont::UnknownArrayHandle& destination); ``` Note that the destination array is a constant reference. This is actually OK because you can change the contents of an `UnknownArrayHandle` (as long as you don't change the array being referenced). The main motivation for this change is to allow you to call this form of `ArrayCopy` while passing in a `ArrayHandle` as the second argument. C++ will automatically make the conversion, but the function has to accept a const reference for it to be passed correctly. Note that there is still a form of `ArrayCopy` that accepts a non-const reference to the destination array. The two arrays behave the same except for one difference. For the non-const version, if the `UnknownArrayHandle` does not already point to an array (i.e. is not valid), a new array will be created and placed in the destination object. However, because this cannot be done for a const reference, an exception is thrown instead.
2021-09-01 18:11:04 +00:00
{
if (!destination.IsValid())
Properly check whether ArrayHandleRecombineVec is on device The `ArrayCopy` was simply calling `IsOnDevice` to see if the array from the `UnknownArrayHandle` was on a device. Seems right, but it is actually operating on an `ArrayHandleRecombineVec`. This is a special array that mostly behaves like other `ArrayHandle`s, but because it has variable vec size, it breaks some `ArrayHandle` conventions. One of the iffy things it has to do is stick the dependent `Buffer` objects into the metadata of its own `Buffer` rather than list them in the `Buffer` list. This means that `ArrayHandle` cannot properly check them to see where they are located. Instead, it just sees that the one `Buffer` it has is empty. A recent change to `IsOnDevice` made it return true for any device if the `Buffer` is empty. So previously this was broken in that it reported that the array was not on any device. That changed to report that it was on all devices, even inactive ones. So the code went from not efficiently copying to throwing an exception. This has been fixed by pulling one of the dependent arrays and checking that one.
2021-08-06 19:16:19 +00:00
{
Allow ArrayCopy into const ref of UnknownArrayHandle Added the following form of `ArrayCopy`: ```cpp VTKM_CONT_EXPORT void ArrayCopy( const vtkm::cont::UnknownArrayHandle& source, const vtkm::cont::UnknownArrayHandle& destination); ``` Note that the destination array is a constant reference. This is actually OK because you can change the contents of an `UnknownArrayHandle` (as long as you don't change the array being referenced). The main motivation for this change is to allow you to call this form of `ArrayCopy` while passing in a `ArrayHandle` as the second argument. C++ will automatically make the conversion, but the function has to accept a const reference for it to be passed correctly. Note that there is still a form of `ArrayCopy` that accepts a non-const reference to the destination array. The two arrays behave the same except for one difference. For the non-const version, if the `UnknownArrayHandle` does not already point to an array (i.e. is not valid), a new array will be created and placed in the destination object. However, because this cannot be done for a const reference, an exception is thrown instead.
2021-09-01 18:11:04 +00:00
throw vtkm::cont::ErrorBadValue(
"Attempty to copy to a constant UnknownArrayHandle with no valid array.");
Properly check whether ArrayHandleRecombineVec is on device The `ArrayCopy` was simply calling `IsOnDevice` to see if the array from the `UnknownArrayHandle` was on a device. Seems right, but it is actually operating on an `ArrayHandleRecombineVec`. This is a special array that mostly behaves like other `ArrayHandle`s, but because it has variable vec size, it breaks some `ArrayHandle` conventions. One of the iffy things it has to do is stick the dependent `Buffer` objects into the metadata of its own `Buffer` rather than list them in the `Buffer` list. This means that `ArrayHandle` cannot properly check them to see where they are located. Instead, it just sees that the one `Buffer` it has is empty. A recent change to `IsOnDevice` made it return true for any device if the `Buffer` is empty. So previously this was broken in that it reported that the array was not on any device. That changed to report that it was on all devices, even inactive ones. So the code went from not efficiently copying to throwing an exception. This has been fixed by pulling one of the dependent arrays and checking that one.
2021-08-06 19:16:19 +00:00
}
Allow ArrayCopy into const ref of UnknownArrayHandle Added the following form of `ArrayCopy`: ```cpp VTKM_CONT_EXPORT void ArrayCopy( const vtkm::cont::UnknownArrayHandle& source, const vtkm::cont::UnknownArrayHandle& destination); ``` Note that the destination array is a constant reference. This is actually OK because you can change the contents of an `UnknownArrayHandle` (as long as you don't change the array being referenced). The main motivation for this change is to allow you to call this form of `ArrayCopy` while passing in a `ArrayHandle` as the second argument. C++ will automatically make the conversion, but the function has to accept a const reference for it to be passed correctly. Note that there is still a form of `ArrayCopy` that accepts a non-const reference to the destination array. The two arrays behave the same except for one difference. For the non-const version, if the `UnknownArrayHandle` does not already point to an array (i.e. is not valid), a new array will be created and placed in the destination object. However, because this cannot be done for a const reference, an exception is thrown instead.
2021-09-01 18:11:04 +00:00
DoUnknownArrayCopy(source, destination);
Add general `ArrayCopy` between `UnknownArrayHandle`s Add an overload of `ArrayCopy` that takes `UnknownArrayHandle`s and copies them for (almost) any `ArrayHandle` type. The code uses `CastAndCallWithExtractedArray` to reduce the total number of copy conditions to about 100, which are all precompiled into the library. On a debug build on my mac, this creates a .o file of 21MB. That's not great, but not terrible. Hopefully, this can be used to consolidate copy implementations elsewhere.
2021-01-14 22:25:09 +00:00
}
Add copy methods to `UnknownArrayHandle` `vtkm::cont::UnknownArrayHandle` now provides a set of method that allows you to copy data from one `UnknownArrayHandle` to another. The first method, `DeepCopyFrom`, takes a source `UnknownArrayHandle` and deep copies the data to the called one. If the `UnknownArrayHandle` already points to a real `ArrayHandle`, the data is copied into that `ArrayHandle`. If the `UnknownArrayHandle` does not point to an existing `ArrayHandle`, then a new `ArrayHandleBasic` with the same value type as the source is created and copied into. The second method, `CopyShallowIfPossibleFrom` behaves similarly to `DeepCopyFrom` except that it will perform a shallow copy if possible. That is, if the target `UnknownArrayHandle` points to an `ArrayHandle` of the same type as the source `UnknownArrayHandle`, then a shallow copy occurs and the underlying `ArrayHandle` will point to the source. If the types differ, then a deep copy is performed. If the target `UnknownArrayHandle` does not point to an `ArrayHandle`, then the behavior is the same as the `=` operator. One of the intentions of these new methods is to allow you to copy arrays without using a device compiler (e.g. `nvcc`). Calling `ArrayCopy` requires you to include the `ArrayCopy.h` header file, and that in turn requires device adapter algorithms. These methods insulate you from these.
2021-09-28 16:46:41 +00:00
} // namespace vtkm::cont::internal
Add general `ArrayCopy` between `UnknownArrayHandle`s Add an overload of `ArrayCopy` that takes `UnknownArrayHandle`s and copies them for (almost) any `ArrayHandle` type. The code uses `CastAndCallWithExtractedArray` to reduce the total number of copy conditions to about 100, which are all precompiled into the library. On a debug build on my mac, this creates a .o file of 21MB. That's not great, but not terrible. Hopefully, this can be used to consolidate copy implementations elsewhere.
2021-01-14 22:25:09 +00:00
} // namespace vtkm::cont
Add copy methods to `UnknownArrayHandle` `vtkm::cont::UnknownArrayHandle` now provides a set of method that allows you to copy data from one `UnknownArrayHandle` to another. The first method, `DeepCopyFrom`, takes a source `UnknownArrayHandle` and deep copies the data to the called one. If the `UnknownArrayHandle` already points to a real `ArrayHandle`, the data is copied into that `ArrayHandle`. If the `UnknownArrayHandle` does not point to an existing `ArrayHandle`, then a new `ArrayHandleBasic` with the same value type as the source is created and copied into. The second method, `CopyShallowIfPossibleFrom` behaves similarly to `DeepCopyFrom` except that it will perform a shallow copy if possible. That is, if the target `UnknownArrayHandle` points to an `ArrayHandle` of the same type as the source `UnknownArrayHandle`, then a shallow copy occurs and the underlying `ArrayHandle` will point to the source. If the types differ, then a deep copy is performed. If the target `UnknownArrayHandle` does not point to an `ArrayHandle`, then the behavior is the same as the `=` operator. One of the intentions of these new methods is to allow you to copy arrays without using a device compiler (e.g. `nvcc`). Calling `ArrayCopy` requires you to include the `ArrayCopy.h` header file, and that in turn requires device adapter algorithms. These methods insulate you from these.
2021-09-28 16:46:41 +00:00
} // namespace vtkm
Reference in New Issue Copy Permalink