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
7aae612d95
vtk-m/vtkm/cont/ArrayCopy.cxx

168 lines
5.2 KiB
C++
Raw 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>
#include <vtkm/cont/DeviceAdapterList.h>
#include <vtkm/cont/Invoker.h>
#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{}) ||
(in.GetComponentArray(0).IsOnDevice(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.
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
UnknownCopyFunctor2{}(out.ExtractArrayFromComponents<InType>(), in);
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.
UnknownCopyFunctor2{}(out.ExtractArrayFromComponents<vtkm::FloatDefault>(), in);
}
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);
}
};
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)
{
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
{
void ArrayCopy(const vtkm::cont::UnknownArrayHandle& source,
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::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);
}
void ArrayCopy(const vtkm::cont::UnknownArrayHandle& source,
const vtkm::cont::UnknownArrayHandle& destination)
{
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
}
}
} // namespace vtkm::cont
Reference in New Issue Copy Permalink