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
5aba6e1bea
vtk-m/vtkm/cont/internal/Buffer.h

367 lines
14 KiB
C
Raw Normal View History

Add Buffer class The buffer class encapsulates the movement of raw C arrays between host and devices. The `Buffer` class itself is not associated with any device. Instead, `Buffer` is used in conjunction with a new templated class named `DeviceAdapterMemoryManager` that can allocate data on a given device and transfer data as necessary. `DeviceAdapterMemoryManager` will eventually replace the more complicated device adapter classes that manage data on a device. The code in `DeviceAdapterMemoryManager` is actually enclosed in virtual methods. This allows us to limit the number of classes that need to be compiled for a device. Rather, the implementation of `DeviceAdapterMemoryManager` is compiled once with whatever compiler is necessary, and then the `RuntimeDeviceInformation` is used to get the correct object instance.
2020-03-26 23:34:18 +00:00
//============================================================================
// 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.
//============================================================================
#ifndef vtk_m_vtkm_cont_internal_Buffer_h
#define vtk_m_vtkm_cont_internal_Buffer_h
#include <vtkm/cont/vtkm_cont_export.h>
#include <vtkm/cont/DeviceAdapterTag.h>
Simplify creating metadata in Buffer objects Previously you had to create a special virtual object to place in the `Buffer`'s metadata. This added a lot of difficulty that is probably unnecessary. Instead, just have `Buffer` hold an arbitrary object and some simple functions to copy and delete it. There may be issues with type safety across translation units, but we'll deal with that when/if we run into it.
2020-11-10 23:22:05 +00:00
#include <vtkm/cont/Logging.h>
Add Buffer class The buffer class encapsulates the movement of raw C arrays between host and devices. The `Buffer` class itself is not associated with any device. Instead, `Buffer` is used in conjunction with a new templated class named `DeviceAdapterMemoryManager` that can allocate data on a given device and transfer data as necessary. `DeviceAdapterMemoryManager` will eventually replace the more complicated device adapter classes that manage data on a device. The code in `DeviceAdapterMemoryManager` is actually enclosed in virtual methods. This allows us to limit the number of classes that need to be compiled for a device. Rather, the implementation of `DeviceAdapterMemoryManager` is compiled once with whatever compiler is necessary, and then the `RuntimeDeviceInformation` is used to get the correct object instance.
2020-03-26 23:34:18 +00:00
#include <vtkm/cont/Serialization.h>
#include <vtkm/cont/Token.h>
#include <vtkm/cont/internal/DeviceAdapterMemoryManager.h>
#include <memory>
#include <mutex>
namespace vtkm
{
Convert ArrayHandleSOA to use Buffer Make `ArrayHandleSOA` use the new `ArrayHandle` style that uses `Buffer` objects to manage and transfer data.
2020-08-13 14:32:58 +00:00
namespace internal
{
///@{
/// \brief Convert the number of values of a type to the number of bytes needed to store it.
///
/// A convenience function that takes the number of values in an array and either the type or the
/// size of the type and safely converts that to the number of bytes required to store the array.
///
/// This function can throw an `vtkm::cont::ErrorBadAllocation` if the number of bytes cannot be
/// stored in the returned `vtkm::BufferSizeType`. (That would be a huge array and probably
/// indicative of an error.)
///
VTKM_CONT_EXPORT vtkm::BufferSizeType NumberOfValuesToNumberOfBytes(vtkm::Id numValues,
std::size_t typeSize);
template <typename T>
vtkm::BufferSizeType NumberOfValuesToNumberOfBytes(vtkm::Id numValues)
{
return NumberOfValuesToNumberOfBytes(numValues, sizeof(T));
}
///@}
} // namespace internal
Add Buffer class The buffer class encapsulates the movement of raw C arrays between host and devices. The `Buffer` class itself is not associated with any device. Instead, `Buffer` is used in conjunction with a new templated class named `DeviceAdapterMemoryManager` that can allocate data on a given device and transfer data as necessary. `DeviceAdapterMemoryManager` will eventually replace the more complicated device adapter classes that manage data on a device. The code in `DeviceAdapterMemoryManager` is actually enclosed in virtual methods. This allows us to limit the number of classes that need to be compiled for a device. Rather, the implementation of `DeviceAdapterMemoryManager` is compiled once with whatever compiler is necessary, and then the `RuntimeDeviceInformation` is used to get the correct object instance.
2020-03-26 23:34:18 +00:00
namespace cont
{
namespace internal
{
namespace detail
{
struct BufferHelper;
Simplify creating metadata in Buffer objects Previously you had to create a special virtual object to place in the `Buffer`'s metadata. This added a lot of difficulty that is probably unnecessary. Instead, just have `Buffer` hold an arbitrary object and some simple functions to copy and delete it. There may be issues with type safety across translation units, but we'll deal with that when/if we run into it.
2020-11-10 23:22:05 +00:00
using DeleterType = void(void*);
Add Buffer class The buffer class encapsulates the movement of raw C arrays between host and devices. The `Buffer` class itself is not associated with any device. Instead, `Buffer` is used in conjunction with a new templated class named `DeviceAdapterMemoryManager` that can allocate data on a given device and transfer data as necessary. `DeviceAdapterMemoryManager` will eventually replace the more complicated device adapter classes that manage data on a device. The code in `DeviceAdapterMemoryManager` is actually enclosed in virtual methods. This allows us to limit the number of classes that need to be compiled for a device. Rather, the implementation of `DeviceAdapterMemoryManager` is compiled once with whatever compiler is necessary, and then the `RuntimeDeviceInformation` is used to get the correct object instance.
2020-03-26 23:34:18 +00:00
Simplify creating metadata in Buffer objects Previously you had to create a special virtual object to place in the `Buffer`'s metadata. This added a lot of difficulty that is probably unnecessary. Instead, just have `Buffer` hold an arbitrary object and some simple functions to copy and delete it. There may be issues with type safety across translation units, but we'll deal with that when/if we run into it.
2020-11-10 23:22:05 +00:00
template <typename T>
void BasicDeleter(void* mem)
Add metadata to Buffer object. One of the goals of the `Buffer` object is to allow sharing of data among objects that will interpret the data differently or give a different interface over the data. However, when sharing only the array, important metadata can become lost. Provide a field that can store some custom metadata in the buffer object so that the rest of the state can follow the buffer object around.
2020-08-24 17:00:42 +00:00
{
Simplify creating metadata in Buffer objects Previously you had to create a special virtual object to place in the `Buffer`'s metadata. This added a lot of difficulty that is probably unnecessary. Instead, just have `Buffer` hold an arbitrary object and some simple functions to copy and delete it. There may be issues with type safety across translation units, but we'll deal with that when/if we run into it.
2020-11-10 23:22:05 +00:00
T* obj = reinterpret_cast<T*>(mem);
delete obj;
}
Add metadata to Buffer object. One of the goals of the `Buffer` object is to allow sharing of data among objects that will interpret the data differently or give a different interface over the data. However, when sharing only the array, important metadata can become lost. Provide a field that can store some custom metadata in the buffer object so that the rest of the state can follow the buffer object around.
2020-08-24 17:00:42 +00:00
Simplify creating metadata in Buffer objects Previously you had to create a special virtual object to place in the `Buffer`'s metadata. This added a lot of difficulty that is probably unnecessary. Instead, just have `Buffer` hold an arbitrary object and some simple functions to copy and delete it. There may be issues with type safety across translation units, but we'll deal with that when/if we run into it.
2020-11-10 23:22:05 +00:00
using CopierType = void*(const void*);
template <typename T>
void* BasicCopier(const void* mem)
{
return new T(*reinterpret_cast<const T*>(mem));
}
} // namespace detail
Add metadata to Buffer object. One of the goals of the `Buffer` object is to allow sharing of data among objects that will interpret the data differently or give a different interface over the data. However, when sharing only the array, important metadata can become lost. Provide a field that can store some custom metadata in the buffer object so that the rest of the state can follow the buffer object around.
2020-08-24 17:00:42 +00:00
Add Buffer class The buffer class encapsulates the movement of raw C arrays between host and devices. The `Buffer` class itself is not associated with any device. Instead, `Buffer` is used in conjunction with a new templated class named `DeviceAdapterMemoryManager` that can allocate data on a given device and transfer data as necessary. `DeviceAdapterMemoryManager` will eventually replace the more complicated device adapter classes that manage data on a device. The code in `DeviceAdapterMemoryManager` is actually enclosed in virtual methods. This allows us to limit the number of classes that need to be compiled for a device. Rather, the implementation of `DeviceAdapterMemoryManager` is compiled once with whatever compiler is necessary, and then the `RuntimeDeviceInformation` is used to get the correct object instance.
2020-03-26 23:34:18 +00:00
/// \brief Manages a buffer data among the host and various devices.
///
/// The `Buffer` class defines a contiguous section of memory of a specified number of bytes. The
/// data in this buffer is managed in the host and across the devices supported by VTK-m. `Buffer`
/// will allocate memory and transfer data as necessary.
///
Replace basic ArrayHandle implementation to use Buffers This encapsulates a lot of the required memory management into the Buffer object and related code. Many now unneeded classes were deleted.
2020-04-22 19:58:59 +00:00
class VTKM_CONT_EXPORT Buffer final
Add Buffer class The buffer class encapsulates the movement of raw C arrays between host and devices. The `Buffer` class itself is not associated with any device. Instead, `Buffer` is used in conjunction with a new templated class named `DeviceAdapterMemoryManager` that can allocate data on a given device and transfer data as necessary. `DeviceAdapterMemoryManager` will eventually replace the more complicated device adapter classes that manage data on a device. The code in `DeviceAdapterMemoryManager` is actually enclosed in virtual methods. This allows us to limit the number of classes that need to be compiled for a device. Rather, the implementation of `DeviceAdapterMemoryManager` is compiled once with whatever compiler is necessary, and then the `RuntimeDeviceInformation` is used to get the correct object instance.
2020-03-26 23:34:18 +00:00
{
class InternalsStruct;
std::shared_ptr<InternalsStruct> Internals;
friend struct vtkm::cont::internal::detail::BufferHelper;
public:
/// \brief Create an empty `Buffer`.
///
VTKM_CONT Buffer();
Replace basic ArrayHandle implementation to use Buffers This encapsulates a lot of the required memory management into the Buffer object and related code. Many now unneeded classes were deleted.
2020-04-22 19:58:59 +00:00
VTKM_CONT Buffer(const Buffer& src);
Store the number of bits of a BitField in the Buffer's metadata The number of bits in a `BitField` cannot be directly implied from the size of the buffer (because the buffer gets padded to the nearest sized word). Thus, the `BitField stored the number of bits in its own internals. Unfortunately, that caused issues when passing the `BitField` data between it and an `ArrayHandleBitField`. If the `ArrayHandleBitField` resized itself, the `BitField` would not see the new size because it ignored the new buffer size. To get around this problem, `BitField` now declares its own `BufferMetaData` that stores the number of bits. Now, since the number of bits is stored in the `Buffer` object, it is sufficient to just share the `Buffer` to synchronize all of the state.
2020-08-24 21:26:57 +00:00
VTKM_CONT Buffer(Buffer&& src) noexcept;
Replace basic ArrayHandle implementation to use Buffers This encapsulates a lot of the required memory management into the Buffer object and related code. Many now unneeded classes were deleted.
2020-04-22 19:58:59 +00:00
VTKM_CONT ~Buffer();
VTKM_CONT Buffer& operator=(const Buffer& src);
Store the number of bits of a BitField in the Buffer's metadata The number of bits in a `BitField` cannot be directly implied from the size of the buffer (because the buffer gets padded to the nearest sized word). Thus, the `BitField stored the number of bits in its own internals. Unfortunately, that caused issues when passing the `BitField` data between it and an `ArrayHandleBitField`. If the `ArrayHandleBitField` resized itself, the `BitField` would not see the new size because it ignored the new buffer size. To get around this problem, `BitField` now declares its own `BufferMetaData` that stores the number of bits. Now, since the number of bits is stored in the `Buffer` object, it is sufficient to just share the `Buffer` to synchronize all of the state.
2020-08-24 21:26:57 +00:00
VTKM_CONT Buffer& operator=(Buffer&& src) noexcept;
Replace basic ArrayHandle implementation to use Buffers This encapsulates a lot of the required memory management into the Buffer object and related code. Many now unneeded classes were deleted.
2020-04-22 19:58:59 +00:00
Add Buffer class The buffer class encapsulates the movement of raw C arrays between host and devices. The `Buffer` class itself is not associated with any device. Instead, `Buffer` is used in conjunction with a new templated class named `DeviceAdapterMemoryManager` that can allocate data on a given device and transfer data as necessary. `DeviceAdapterMemoryManager` will eventually replace the more complicated device adapter classes that manage data on a device. The code in `DeviceAdapterMemoryManager` is actually enclosed in virtual methods. This allows us to limit the number of classes that need to be compiled for a device. Rather, the implementation of `DeviceAdapterMemoryManager` is compiled once with whatever compiler is necessary, and then the `RuntimeDeviceInformation` is used to get the correct object instance.
2020-03-26 23:34:18 +00:00
/// \brief Returns the number of bytes held by the buffer.
///
/// Note that `Buffer` allocates memory lazily. So there might not actually be any memory
/// allocated anywhere. It is also possible that memory is simultaneously allocated on multiple
/// devices.
///
VTKM_CONT vtkm::BufferSizeType GetNumberOfBytes() const;
/// \brief Changes the size of the buffer.
///
/// Note that `Buffer` alloates memory lazily. So there might not be any memory allocated at
/// the return of the call. (However, later calls to retrieve pointers will allocate memory
/// as necessary.)
///
/// The `preserve` argument flags whether any existing data in the buffer is preserved.
/// Preserving data might cost more time or memory.
///
Fix potential deadlock in ArrayHandle::PrepareForOutput `ArrayHandle::PrepareForOutput` often has to reallocate the array to the specified size. Previously, this allocation was not happening with the `Token` that is passed to `PrepareForOutput`. If the `ArrayHandle` is already attached or enqueued for that `Token`, then the allocation would deadlock. You can now pass a `Token` object to `Allocate`, which is what `PrepareForOutput` does.
2020-07-08 00:30:38 +00:00
VTKM_CONT void SetNumberOfBytes(vtkm::BufferSizeType numberOfBytes,
vtkm::CopyFlag preserve,
Allow ArrayHandle to have a runtime selectable number of buffers Previously, the number of buffers held by an `ArrayHandle` had to be determined statically at compile time by the storage. Most of the time this is fine. However, there are some exceptions where the number of buffers need to be selected at runtime. For example, the `ArrayHandleRecombineVec` does not specify the number of components it uses, and it needed a hack where it stored buffers in the metadata of another buffer, which is bad. This change allows the number of buffers to vary at runtime (at least at construction). The buffers were already managed in a `std::vector`. It now no longer forces the vector to be a specific size. `GetNumberOfBuffers` was removed from the `Storage`. Instead, if the number of buffers was not specified at construction, an allocation of size 0 is done to create default buffers. The biggest change is to the interface of the storage object methods, which now take `std::vector` instead of pointers to `Buffer` objects. This adds a little hastle in having to copy subsets of this `vector` when a storage object has multiple sub-arrays. But it does simplify some of the templating.
2022-06-28 20:26:38 +00:00
vtkm::cont::Token& token) const;
Add Buffer class The buffer class encapsulates the movement of raw C arrays between host and devices. The `Buffer` class itself is not associated with any device. Instead, `Buffer` is used in conjunction with a new templated class named `DeviceAdapterMemoryManager` that can allocate data on a given device and transfer data as necessary. `DeviceAdapterMemoryManager` will eventually replace the more complicated device adapter classes that manage data on a device. The code in `DeviceAdapterMemoryManager` is actually enclosed in virtual methods. This allows us to limit the number of classes that need to be compiled for a device. Rather, the implementation of `DeviceAdapterMemoryManager` is compiled once with whatever compiler is necessary, and then the `RuntimeDeviceInformation` is used to get the correct object instance.
2020-03-26 23:34:18 +00:00
Simplify creating metadata in Buffer objects Previously you had to create a special virtual object to place in the `Buffer`'s metadata. This added a lot of difficulty that is probably unnecessary. Instead, just have `Buffer` hold an arbitrary object and some simple functions to copy and delete it. There may be issues with type safety across translation units, but we'll deal with that when/if we run into it.
2020-11-10 23:22:05 +00:00
private:
VTKM_CONT bool MetaDataIsType(const std::string& type) const;
VTKM_CONT void SetMetaData(void* data,
const std::string& type,
detail::DeleterType* deleter,
detail::CopierType copier) const;
VTKM_CONT void* GetMetaData(const std::string& type) const;
public:
/// \brief Returns whether this `Buffer` holds metadata.
Add metadata to Buffer object. One of the goals of the `Buffer` object is to allow sharing of data among objects that will interpret the data differently or give a different interface over the data. However, when sharing only the array, important metadata can become lost. Provide a field that can store some custom metadata in the buffer object so that the rest of the state can follow the buffer object around.
2020-08-24 17:00:42 +00:00
///
Simplify creating metadata in Buffer objects Previously you had to create a special virtual object to place in the `Buffer`'s metadata. This added a lot of difficulty that is probably unnecessary. Instead, just have `Buffer` hold an arbitrary object and some simple functions to copy and delete it. There may be issues with type safety across translation units, but we'll deal with that when/if we run into it.
2020-11-10 23:22:05 +00:00
VTKM_CONT bool HasMetaData() const;
/// \brief Determines if the metadata for the buffer is set to the given type.
Add metadata to Buffer object. One of the goals of the `Buffer` object is to allow sharing of data among objects that will interpret the data differently or give a different interface over the data. However, when sharing only the array, important metadata can become lost. Provide a field that can store some custom metadata in the buffer object so that the rest of the state can follow the buffer object around.
2020-08-24 17:00:42 +00:00
///
Simplify creating metadata in Buffer objects Previously you had to create a special virtual object to place in the `Buffer`'s metadata. This added a lot of difficulty that is probably unnecessary. Instead, just have `Buffer` hold an arbitrary object and some simple functions to copy and delete it. There may be issues with type safety across translation units, but we'll deal with that when/if we run into it.
2020-11-10 23:22:05 +00:00
template <typename MetaDataType>
VTKM_CONT bool MetaDataIsType() const
{
return this->MetaDataIsType(vtkm::cont::TypeToString<MetaDataType>());
}
Add metadata to Buffer object. One of the goals of the `Buffer` object is to allow sharing of data among objects that will interpret the data differently or give a different interface over the data. However, when sharing only the array, important metadata can become lost. Provide a field that can store some custom metadata in the buffer object so that the rest of the state can follow the buffer object around.
2020-08-24 17:00:42 +00:00
/// \brief Sets the metadata for the buffer.
///
Simplify creating metadata in Buffer objects Previously you had to create a special virtual object to place in the `Buffer`'s metadata. This added a lot of difficulty that is probably unnecessary. Instead, just have `Buffer` hold an arbitrary object and some simple functions to copy and delete it. There may be issues with type safety across translation units, but we'll deal with that when/if we run into it.
2020-11-10 23:22:05 +00:00
/// Takes an arbitrary object and copies it to the metadata of this buffer. Any existing
/// metadata is deleted. Any object can be set as the metadata as long as the object has
/// a default constructor and is copyable.
///
/// Holding metadata in a `Buffer` is optional, but helpful for storing additional
/// information or objects that cannot be implied by the buffer itself.
Add metadata to Buffer object. One of the goals of the `Buffer` object is to allow sharing of data among objects that will interpret the data differently or give a different interface over the data. However, when sharing only the array, important metadata can become lost. Provide a field that can store some custom metadata in the buffer object so that the rest of the state can follow the buffer object around.
2020-08-24 17:00:42 +00:00
///
Simplify creating metadata in Buffer objects Previously you had to create a special virtual object to place in the `Buffer`'s metadata. This added a lot of difficulty that is probably unnecessary. Instead, just have `Buffer` hold an arbitrary object and some simple functions to copy and delete it. There may be issues with type safety across translation units, but we'll deal with that when/if we run into it.
2020-11-10 23:22:05 +00:00
template <typename MetaDataType>
VTKM_CONT void SetMetaData(const MetaDataType& metadata) const
{
MetaDataType* metadataCopy = new MetaDataType(metadata);
this->SetMetaData(metadataCopy,
vtkm::cont::TypeToString(metadata),
detail::BasicDeleter<MetaDataType>,
detail::BasicCopier<MetaDataType>);
}
Add metadata to Buffer object. One of the goals of the `Buffer` object is to allow sharing of data among objects that will interpret the data differently or give a different interface over the data. However, when sharing only the array, important metadata can become lost. Provide a field that can store some custom metadata in the buffer object so that the rest of the state can follow the buffer object around.
2020-08-24 17:00:42 +00:00
Simplify creating metadata in Buffer objects Previously you had to create a special virtual object to place in the `Buffer`'s metadata. This added a lot of difficulty that is probably unnecessary. Instead, just have `Buffer` hold an arbitrary object and some simple functions to copy and delete it. There may be issues with type safety across translation units, but we'll deal with that when/if we run into it.
2020-11-10 23:22:05 +00:00
/// \brief Gets the metadata for the buffer.
///
/// When you call this method, you have to specify a template parameter for the type
/// of the metadata. If the metadata has not yet been set in this buffer, a new metadata
/// object is created, set to this buffer, and returned. If metadata of a different type
/// has already been set, then an exception is thrown.
Add metadata to Buffer object. One of the goals of the `Buffer` object is to allow sharing of data among objects that will interpret the data differently or give a different interface over the data. However, when sharing only the array, important metadata can become lost. Provide a field that can store some custom metadata in the buffer object so that the rest of the state can follow the buffer object around.
2020-08-24 17:00:42 +00:00
///
Simplify creating metadata in Buffer objects Previously you had to create a special virtual object to place in the `Buffer`'s metadata. This added a lot of difficulty that is probably unnecessary. Instead, just have `Buffer` hold an arbitrary object and some simple functions to copy and delete it. There may be issues with type safety across translation units, but we'll deal with that when/if we run into it.
2020-11-10 23:22:05 +00:00
/// The returned value is a reference that can be manipulated to alter the metadata of
/// this buffer.
Add metadata to Buffer object. One of the goals of the `Buffer` object is to allow sharing of data among objects that will interpret the data differently or give a different interface over the data. However, when sharing only the array, important metadata can become lost. Provide a field that can store some custom metadata in the buffer object so that the rest of the state can follow the buffer object around.
2020-08-24 17:00:42 +00:00
///
template <typename MetaDataType>
Simplify creating metadata in Buffer objects Previously you had to create a special virtual object to place in the `Buffer`'s metadata. This added a lot of difficulty that is probably unnecessary. Instead, just have `Buffer` hold an arbitrary object and some simple functions to copy and delete it. There may be issues with type safety across translation units, but we'll deal with that when/if we run into it.
2020-11-10 23:22:05 +00:00
VTKM_CONT MetaDataType& GetMetaData() const
Add metadata to Buffer object. One of the goals of the `Buffer` object is to allow sharing of data among objects that will interpret the data differently or give a different interface over the data. However, when sharing only the array, important metadata can become lost. Provide a field that can store some custom metadata in the buffer object so that the rest of the state can follow the buffer object around.
2020-08-24 17:00:42 +00:00
{
Simplify creating metadata in Buffer objects Previously you had to create a special virtual object to place in the `Buffer`'s metadata. This added a lot of difficulty that is probably unnecessary. Instead, just have `Buffer` hold an arbitrary object and some simple functions to copy and delete it. There may be issues with type safety across translation units, but we'll deal with that when/if we run into it.
2020-11-10 23:22:05 +00:00
if (!this->HasMetaData())
{
this->SetMetaData(MetaDataType{});
}
return *reinterpret_cast<MetaDataType*>(
this->GetMetaData(vtkm::cont::TypeToString<MetaDataType>()));
Add metadata to Buffer object. One of the goals of the `Buffer` object is to allow sharing of data among objects that will interpret the data differently or give a different interface over the data. However, when sharing only the array, important metadata can become lost. Provide a field that can store some custom metadata in the buffer object so that the rest of the state can follow the buffer object around.
2020-08-24 17:00:42 +00:00
}
Add Buffer class The buffer class encapsulates the movement of raw C arrays between host and devices. The `Buffer` class itself is not associated with any device. Instead, `Buffer` is used in conjunction with a new templated class named `DeviceAdapterMemoryManager` that can allocate data on a given device and transfer data as necessary. `DeviceAdapterMemoryManager` will eventually replace the more complicated device adapter classes that manage data on a device. The code in `DeviceAdapterMemoryManager` is actually enclosed in virtual methods. This allows us to limit the number of classes that need to be compiled for a device. Rather, the implementation of `DeviceAdapterMemoryManager` is compiled once with whatever compiler is necessary, and then the `RuntimeDeviceInformation` is used to get the correct object instance.
2020-03-26 23:34:18 +00:00
/// \brief Returns `true` if the buffer is allocated on the host.
///
VTKM_CONT bool IsAllocatedOnHost() const;
/// \brief Returns `true` if the buffer is allocated on the given device.
///
Replace basic ArrayHandle implementation to use Buffers This encapsulates a lot of the required memory management into the Buffer object and related code. Many now unneeded classes were deleted.
2020-04-22 19:58:59 +00:00
/// If `device` is `DeviceAdapterTagUnknown`, then this returns the same value as
/// `IsAllocatedOnHost`. If `device` is `DeviceAdapterTagAny`, then this returns true if
/// allocated on any device.
///
Add Buffer class The buffer class encapsulates the movement of raw C arrays between host and devices. The `Buffer` class itself is not associated with any device. Instead, `Buffer` is used in conjunction with a new templated class named `DeviceAdapterMemoryManager` that can allocate data on a given device and transfer data as necessary. `DeviceAdapterMemoryManager` will eventually replace the more complicated device adapter classes that manage data on a device. The code in `DeviceAdapterMemoryManager` is actually enclosed in virtual methods. This allows us to limit the number of classes that need to be compiled for a device. Rather, the implementation of `DeviceAdapterMemoryManager` is compiled once with whatever compiler is necessary, and then the `RuntimeDeviceInformation` is used to get the correct object instance.
2020-03-26 23:34:18 +00:00
VTKM_CONT bool IsAllocatedOnDevice(vtkm::cont::DeviceAdapterId device) const;
/// \brief Returns a readable host (control environment) pointer to the buffer.
///
/// Memory will be allocated and data will be copied as necessary. The memory at the pointer will
/// be valid as long as `token` is still in scope. Any write operation to this buffer will be
/// blocked until the `token` goes out of scope.
///
VTKM_CONT const void* ReadPointerHost(vtkm::cont::Token& token) const;
/// \brief Returns a readable device pointer to the buffer.
///
/// Memory will be allocated and data will be copied as necessary. The memory at the pointer will
/// be valid as long as `token` is still in scope. Any write operation to this buffer will be
/// blocked until the `token` goes out of scope.
///
Replace basic ArrayHandle implementation to use Buffers This encapsulates a lot of the required memory management into the Buffer object and related code. Many now unneeded classes were deleted.
2020-04-22 19:58:59 +00:00
/// If `device` is `DeviceAdapterTagUnknown`, then this has the same behavior as
/// `ReadPointerHost`. It is an error to set `device` to `DeviceAdapterTagAny`.
///
Add Buffer class The buffer class encapsulates the movement of raw C arrays between host and devices. The `Buffer` class itself is not associated with any device. Instead, `Buffer` is used in conjunction with a new templated class named `DeviceAdapterMemoryManager` that can allocate data on a given device and transfer data as necessary. `DeviceAdapterMemoryManager` will eventually replace the more complicated device adapter classes that manage data on a device. The code in `DeviceAdapterMemoryManager` is actually enclosed in virtual methods. This allows us to limit the number of classes that need to be compiled for a device. Rather, the implementation of `DeviceAdapterMemoryManager` is compiled once with whatever compiler is necessary, and then the `RuntimeDeviceInformation` is used to get the correct object instance.
2020-03-26 23:34:18 +00:00
VTKM_CONT const void* ReadPointerDevice(vtkm::cont::DeviceAdapterId device,
vtkm::cont::Token& token) const;
/// \brief Returns a writable host (control environment) pointer to the buffer.
///
/// Memory will be allocated and data will be copied as necessary. The memory at the pointer will
/// be valid as long as `token` is still in scope. Any read or write operation to this buffer
/// will be blocked until the `token` goes out of scope.
///
VTKM_CONT void* WritePointerHost(vtkm::cont::Token& token) const;
/// \brief Returns a writable device pointer to the buffer.
///
/// Memory will be allocated and data will be copied as necessary. The memory at the pointer will
/// be valid as long as `token` is still in scope. Any read or write operation to this buffer
/// will be blocked until the `token` goes out of scope.
///
Replace basic ArrayHandle implementation to use Buffers This encapsulates a lot of the required memory management into the Buffer object and related code. Many now unneeded classes were deleted.
2020-04-22 19:58:59 +00:00
/// If `device` is `DeviceAdapterTagUnknown`, then this has the same behavior as
/// `WritePointerHost`. It is an error to set `device` to `DeviceAdapterTagAny`.
///
Add Buffer class The buffer class encapsulates the movement of raw C arrays between host and devices. The `Buffer` class itself is not associated with any device. Instead, `Buffer` is used in conjunction with a new templated class named `DeviceAdapterMemoryManager` that can allocate data on a given device and transfer data as necessary. `DeviceAdapterMemoryManager` will eventually replace the more complicated device adapter classes that manage data on a device. The code in `DeviceAdapterMemoryManager` is actually enclosed in virtual methods. This allows us to limit the number of classes that need to be compiled for a device. Rather, the implementation of `DeviceAdapterMemoryManager` is compiled once with whatever compiler is necessary, and then the `RuntimeDeviceInformation` is used to get the correct object instance.
2020-03-26 23:34:18 +00:00
VTKM_CONT void* WritePointerDevice(vtkm::cont::DeviceAdapterId device,
vtkm::cont::Token& token) const;
Replace basic ArrayHandle implementation to use Buffers This encapsulates a lot of the required memory management into the Buffer object and related code. Many now unneeded classes were deleted.
2020-04-22 19:58:59 +00:00
/// \brief Enqueue a token for access to the buffer.
///
/// This method places the given `Token` into the queue of `Token`s waiting for
/// access to this `Buffer` and then returns immediately. When this token
/// is later used to get data from this `Buffer` (for example, in a call to
/// `ReadPointerDevice`), it will use this place in the queue while waiting for
///
/// \warning After calling this method it is required to subsequently call a
/// method that attaches the token to this `Buffer`. Otherwise, the enqueued
/// token will block any subsequent access to the `ArrayHandle`, even if the
/// `Token` is destroyed.
///
VTKM_CONT void Enqueue(const vtkm::cont::Token& token) const;
Add Buffer class The buffer class encapsulates the movement of raw C arrays between host and devices. The `Buffer` class itself is not associated with any device. Instead, `Buffer` is used in conjunction with a new templated class named `DeviceAdapterMemoryManager` that can allocate data on a given device and transfer data as necessary. `DeviceAdapterMemoryManager` will eventually replace the more complicated device adapter classes that manage data on a device. The code in `DeviceAdapterMemoryManager` is actually enclosed in virtual methods. This allows us to limit the number of classes that need to be compiled for a device. Rather, the implementation of `DeviceAdapterMemoryManager` is compiled once with whatever compiler is necessary, and then the `RuntimeDeviceInformation` is used to get the correct object instance.
2020-03-26 23:34:18 +00:00
/// @{
Swap call pattern of ArrayHandle::DeepCopy The new method `ArrayHandle::DeepCopy` had the pattern such that the data in the `this` array was pushed to the provided destination array. However, this is the opposite pattern used in the equivalent method in VTK, which takes the data from the provided array and copies it to `this` array. So, swap the pattern to match that of VTK. Also, make the method name more descriptive by renaming it to `DeepCopyFrom`. Hopefully, users will read that to mean given the `ArrayHandle`, you copy data from the other provided `ArrayHandle`.
2020-09-01 16:08:06 +00:00
/// \brief Copies the data from the provided buffer into this buffer.
Add Buffer class The buffer class encapsulates the movement of raw C arrays between host and devices. The `Buffer` class itself is not associated with any device. Instead, `Buffer` is used in conjunction with a new templated class named `DeviceAdapterMemoryManager` that can allocate data on a given device and transfer data as necessary. `DeviceAdapterMemoryManager` will eventually replace the more complicated device adapter classes that manage data on a device. The code in `DeviceAdapterMemoryManager` is actually enclosed in virtual methods. This allows us to limit the number of classes that need to be compiled for a device. Rather, the implementation of `DeviceAdapterMemoryManager` is compiled once with whatever compiler is necessary, and then the `RuntimeDeviceInformation` is used to get the correct object instance.
2020-03-26 23:34:18 +00:00
///
/// If a device is given, then the copy will be preferred for that device. Otherwise, a device
/// already containing the data will be used for the copy. If no such device exists, the host
/// will be used.
///
Swap call pattern of ArrayHandle::DeepCopy The new method `ArrayHandle::DeepCopy` had the pattern such that the data in the `this` array was pushed to the provided destination array. However, this is the opposite pattern used in the equivalent method in VTK, which takes the data from the provided array and copies it to `this` array. So, swap the pattern to match that of VTK. Also, make the method name more descriptive by renaming it to `DeepCopyFrom`. Hopefully, users will read that to mean given the `ArrayHandle`, you copy data from the other provided `ArrayHandle`.
2020-09-01 16:08:06 +00:00
VTKM_CONT void DeepCopyFrom(const vtkm::cont::internal::Buffer& source) const;
VTKM_CONT void DeepCopyFrom(const vtkm::cont::internal::Buffer& source,
vtkm::cont::DeviceAdapterId device) const;
Add Buffer class The buffer class encapsulates the movement of raw C arrays between host and devices. The `Buffer` class itself is not associated with any device. Instead, `Buffer` is used in conjunction with a new templated class named `DeviceAdapterMemoryManager` that can allocate data on a given device and transfer data as necessary. `DeviceAdapterMemoryManager` will eventually replace the more complicated device adapter classes that manage data on a device. The code in `DeviceAdapterMemoryManager` is actually enclosed in virtual methods. This allows us to limit the number of classes that need to be compiled for a device. Rather, the implementation of `DeviceAdapterMemoryManager` is compiled once with whatever compiler is necessary, and then the `RuntimeDeviceInformation` is used to get the correct object instance.
2020-03-26 23:34:18 +00:00
/// @}
Pin user provided memory in ArrayHandle Often when a user gives memory to an `ArrayHandle`, she wants data to be written into the memory given to be used elsewhere. Previously, the `Buffer` objects would delete the given buffer as soon as a write buffer was created elsewhere. That was a problem if a user wants VTK-m to write results right into a given buffer. Instead, when a user provides memory, "pin" that memory so that the `ArrayHandle` never deletes it.
2020-06-24 23:27:36 +00:00
/// \brief Resets the `Buffer` to the memory allocated at the `BufferInfo`.
Add Buffer class The buffer class encapsulates the movement of raw C arrays between host and devices. The `Buffer` class itself is not associated with any device. Instead, `Buffer` is used in conjunction with a new templated class named `DeviceAdapterMemoryManager` that can allocate data on a given device and transfer data as necessary. `DeviceAdapterMemoryManager` will eventually replace the more complicated device adapter classes that manage data on a device. The code in `DeviceAdapterMemoryManager` is actually enclosed in virtual methods. This allows us to limit the number of classes that need to be compiled for a device. Rather, the implementation of `DeviceAdapterMemoryManager` is compiled once with whatever compiler is necessary, and then the `RuntimeDeviceInformation` is used to get the correct object instance.
2020-03-26 23:34:18 +00:00
///
/// The `Buffer` is initialized to a state that contains the given `buffer` of data. The
Replace basic ArrayHandle implementation to use Buffers This encapsulates a lot of the required memory management into the Buffer object and related code. Many now unneeded classes were deleted.
2020-04-22 19:58:59 +00:00
/// `BufferInfo` object self-describes the pointer, size, and device of the memory.
Add Buffer class The buffer class encapsulates the movement of raw C arrays between host and devices. The `Buffer` class itself is not associated with any device. Instead, `Buffer` is used in conjunction with a new templated class named `DeviceAdapterMemoryManager` that can allocate data on a given device and transfer data as necessary. `DeviceAdapterMemoryManager` will eventually replace the more complicated device adapter classes that manage data on a device. The code in `DeviceAdapterMemoryManager` is actually enclosed in virtual methods. This allows us to limit the number of classes that need to be compiled for a device. Rather, the implementation of `DeviceAdapterMemoryManager` is compiled once with whatever compiler is necessary, and then the `RuntimeDeviceInformation` is used to get the correct object instance.
2020-03-26 23:34:18 +00:00
///
Pin user provided memory in ArrayHandle Often when a user gives memory to an `ArrayHandle`, she wants data to be written into the memory given to be used elsewhere. Previously, the `Buffer` objects would delete the given buffer as soon as a write buffer was created elsewhere. That was a problem if a user wants VTK-m to write results right into a given buffer. Instead, when a user provides memory, "pin" that memory so that the `ArrayHandle` never deletes it.
2020-06-24 23:27:36 +00:00
/// The given memory is "pinned" in the `Buffer`. This means that this memory will always
/// be used on the given host or device. If `SetNumberOfBytes` is later called with a size
/// that is inconsistent with the size of this buffer, an exception will be thrown.
///
Replace basic ArrayHandle implementation to use Buffers This encapsulates a lot of the required memory management into the Buffer object and related code. Many now unneeded classes were deleted.
2020-04-22 19:58:59 +00:00
VTKM_CONT void Reset(const vtkm::cont::internal::BufferInfo& buffer);
Add Buffer class The buffer class encapsulates the movement of raw C arrays between host and devices. The `Buffer` class itself is not associated with any device. Instead, `Buffer` is used in conjunction with a new templated class named `DeviceAdapterMemoryManager` that can allocate data on a given device and transfer data as necessary. `DeviceAdapterMemoryManager` will eventually replace the more complicated device adapter classes that manage data on a device. The code in `DeviceAdapterMemoryManager` is actually enclosed in virtual methods. This allows us to limit the number of classes that need to be compiled for a device. Rather, the implementation of `DeviceAdapterMemoryManager` is compiled once with whatever compiler is necessary, and then the `RuntimeDeviceInformation` is used to get the correct object instance.
2020-03-26 23:34:18 +00:00
Store the number of bits of a BitField in the Buffer's metadata The number of bits in a `BitField` cannot be directly implied from the size of the buffer (because the buffer gets padded to the nearest sized word). Thus, the `BitField stored the number of bits in its own internals. Unfortunately, that caused issues when passing the `BitField` data between it and an `ArrayHandleBitField`. If the `ArrayHandleBitField` resized itself, the `BitField` would not see the new size because it ignored the new buffer size. To get around this problem, `BitField` now declares its own `BufferMetaData` that stores the number of bits. Now, since the number of bits is stored in the `Buffer` object, it is sufficient to just share the `Buffer` to synchronize all of the state.
2020-08-24 21:26:57 +00:00
/// \brief Unallocates the buffer from all devices.
///
/// This method preserves the data on the host even if the data must be transferred
/// there.
///
/// Note that this method will not physically deallocate memory on a device that shares
/// a memory space with the host (since the data must be preserved on the host). This
/// is true even for memory spaces that page data between host and device. This method
/// will not attempt to unpage data from a device with shared memory.
///
VTKM_CONT void ReleaseDeviceResources() const;
Replace basic ArrayHandle implementation to use Buffers This encapsulates a lot of the required memory management into the Buffer object and related code. Many now unneeded classes were deleted.
2020-04-22 19:58:59 +00:00
/// \brief Gets the `BufferInfo` object to the memory allocated on the host.
Add Buffer class The buffer class encapsulates the movement of raw C arrays between host and devices. The `Buffer` class itself is not associated with any device. Instead, `Buffer` is used in conjunction with a new templated class named `DeviceAdapterMemoryManager` that can allocate data on a given device and transfer data as necessary. `DeviceAdapterMemoryManager` will eventually replace the more complicated device adapter classes that manage data on a device. The code in `DeviceAdapterMemoryManager` is actually enclosed in virtual methods. This allows us to limit the number of classes that need to be compiled for a device. Rather, the implementation of `DeviceAdapterMemoryManager` is compiled once with whatever compiler is necessary, and then the `RuntimeDeviceInformation` is used to get the correct object instance.
2020-03-26 23:34:18 +00:00
///
Replace basic ArrayHandle implementation to use Buffers This encapsulates a lot of the required memory management into the Buffer object and related code. Many now unneeded classes were deleted.
2020-04-22 19:58:59 +00:00
VTKM_CONT vtkm::cont::internal::BufferInfo GetHostBufferInfo() const;
Add Buffer class The buffer class encapsulates the movement of raw C arrays between host and devices. The `Buffer` class itself is not associated with any device. Instead, `Buffer` is used in conjunction with a new templated class named `DeviceAdapterMemoryManager` that can allocate data on a given device and transfer data as necessary. `DeviceAdapterMemoryManager` will eventually replace the more complicated device adapter classes that manage data on a device. The code in `DeviceAdapterMemoryManager` is actually enclosed in virtual methods. This allows us to limit the number of classes that need to be compiled for a device. Rather, the implementation of `DeviceAdapterMemoryManager` is compiled once with whatever compiler is necessary, and then the `RuntimeDeviceInformation` is used to get the correct object instance.
2020-03-26 23:34:18 +00:00
Replace basic ArrayHandle implementation to use Buffers This encapsulates a lot of the required memory management into the Buffer object and related code. Many now unneeded classes were deleted.
2020-04-22 19:58:59 +00:00
/// \brief Gets the `BufferInfo` object to the memory allocated on the given device.
Add Buffer class The buffer class encapsulates the movement of raw C arrays between host and devices. The `Buffer` class itself is not associated with any device. Instead, `Buffer` is used in conjunction with a new templated class named `DeviceAdapterMemoryManager` that can allocate data on a given device and transfer data as necessary. `DeviceAdapterMemoryManager` will eventually replace the more complicated device adapter classes that manage data on a device. The code in `DeviceAdapterMemoryManager` is actually enclosed in virtual methods. This allows us to limit the number of classes that need to be compiled for a device. Rather, the implementation of `DeviceAdapterMemoryManager` is compiled once with whatever compiler is necessary, and then the `RuntimeDeviceInformation` is used to get the correct object instance.
2020-03-26 23:34:18 +00:00
///
Replace basic ArrayHandle implementation to use Buffers This encapsulates a lot of the required memory management into the Buffer object and related code. Many now unneeded classes were deleted.
2020-04-22 19:58:59 +00:00
/// If the device is `DeviceAdapterTagUndefined`, the pointer for the host is returned. It is
/// invalid to select `DeviceAdapterTagAny`.
Add Buffer class The buffer class encapsulates the movement of raw C arrays between host and devices. The `Buffer` class itself is not associated with any device. Instead, `Buffer` is used in conjunction with a new templated class named `DeviceAdapterMemoryManager` that can allocate data on a given device and transfer data as necessary. `DeviceAdapterMemoryManager` will eventually replace the more complicated device adapter classes that manage data on a device. The code in `DeviceAdapterMemoryManager` is actually enclosed in virtual methods. This allows us to limit the number of classes that need to be compiled for a device. Rather, the implementation of `DeviceAdapterMemoryManager` is compiled once with whatever compiler is necessary, and then the `RuntimeDeviceInformation` is used to get the correct object instance.
2020-03-26 23:34:18 +00:00
///
Replace basic ArrayHandle implementation to use Buffers This encapsulates a lot of the required memory management into the Buffer object and related code. Many now unneeded classes were deleted.
2020-04-22 19:58:59 +00:00
VTKM_CONT vtkm::cont::internal::BufferInfo GetDeviceBufferInfo(
vtkm::cont::DeviceAdapterId device) const;
Add Buffer class The buffer class encapsulates the movement of raw C arrays between host and devices. The `Buffer` class itself is not associated with any device. Instead, `Buffer` is used in conjunction with a new templated class named `DeviceAdapterMemoryManager` that can allocate data on a given device and transfer data as necessary. `DeviceAdapterMemoryManager` will eventually replace the more complicated device adapter classes that manage data on a device. The code in `DeviceAdapterMemoryManager` is actually enclosed in virtual methods. This allows us to limit the number of classes that need to be compiled for a device. Rather, the implementation of `DeviceAdapterMemoryManager` is compiled once with whatever compiler is necessary, and then the `RuntimeDeviceInformation` is used to get the correct object instance.
2020-03-26 23:34:18 +00:00
Allow VTK-m Buffer to have ownership transferred
2020-08-03 17:37:46 +00:00
/// \brief Transfer ownership of the Host `BufferInfo` from this buffer
/// to the caller. This is used to allow memory owned by VTK-m to be
/// transferred to an owner whose lifespan is longer
Allow ArrayHandle to have a runtime selectable number of buffers Previously, the number of buffers held by an `ArrayHandle` had to be determined statically at compile time by the storage. Most of the time this is fine. However, there are some exceptions where the number of buffers need to be selected at runtime. For example, the `ArrayHandleRecombineVec` does not specify the number of components it uses, and it needed a hack where it stored buffers in the metadata of another buffer, which is bad. This change allows the number of buffers to vary at runtime (at least at construction). The buffers were already managed in a `std::vector`. It now no longer forces the vector to be a specific size. `GetNumberOfBuffers` was removed from the `Storage`. Instead, if the number of buffers was not specified at construction, an allocation of size 0 is done to create default buffers. The biggest change is to the interface of the storage object methods, which now take `std::vector` instead of pointers to `Buffer` objects. This adds a little hastle in having to copy subsets of this `vector` when a storage object has multiple sub-arrays. But it does simplify some of the templating.
2022-06-28 20:26:38 +00:00
VTKM_CONT vtkm::cont::internal::TransferredBuffer TakeHostBufferOwnership() const;
Allow VTK-m Buffer to have ownership transferred
2020-08-03 17:37:46 +00:00
/// \brief Transfer ownership of the device `BufferInfo` from this buffer
/// to the caller. This is used to allow memory owned by VTK-m to be
/// transferred to an owner whose lifespan is longer
VTKM_CONT vtkm::cont::internal::TransferredBuffer TakeDeviceBufferOwnership(
Allow ArrayHandle to have a runtime selectable number of buffers Previously, the number of buffers held by an `ArrayHandle` had to be determined statically at compile time by the storage. Most of the time this is fine. However, there are some exceptions where the number of buffers need to be selected at runtime. For example, the `ArrayHandleRecombineVec` does not specify the number of components it uses, and it needed a hack where it stored buffers in the metadata of another buffer, which is bad. This change allows the number of buffers to vary at runtime (at least at construction). The buffers were already managed in a `std::vector`. It now no longer forces the vector to be a specific size. `GetNumberOfBuffers` was removed from the `Storage`. Instead, if the number of buffers was not specified at construction, an allocation of size 0 is done to create default buffers. The biggest change is to the interface of the storage object methods, which now take `std::vector` instead of pointers to `Buffer` objects. This adds a little hastle in having to copy subsets of this `vector` when a storage object has multiple sub-arrays. But it does simplify some of the templating.
2022-06-28 20:26:38 +00:00
vtkm::cont::DeviceAdapterId device) const;
Allow VTK-m Buffer to have ownership transferred
2020-08-03 17:37:46 +00:00
Add ability to fill values in a Buffer This is in preparation to add a method to `ArrayHandle` that allows initializing fill values.
2021-11-22 21:52:41 +00:00
/// \brief Fill up the buffer with particular values.
///
/// Given a short `source` C array (defined on the host), sets all values in the buffer
/// to that source. The `sourceSize`, in bytes, is also specified. You also specify an
Specify end position when filling values in Buffer This allows us to support `Fill` in `ArrayHandleView` and `ArrayHandleReverse`.
2022-01-11 14:15:41 +00:00
/// offset to where the fill should `start` and `end`. Values before the `start` and
/// after the `end` are not affected.
Add ability to fill values in a Buffer This is in preparation to add a method to `ArrayHandle` that allows initializing fill values.
2021-11-22 21:52:41 +00:00
///
Specify end position when filling values in Buffer This allows us to support `Fill` in `ArrayHandleView` and `ArrayHandleReverse`.
2022-01-11 14:15:41 +00:00
/// Both `start` and `end` must be divisible by `sourceSize`.
Add ability to fill values in a Buffer This is in preparation to add a method to `ArrayHandle` that allows initializing fill values.
2021-11-22 21:52:41 +00:00
///
VTKM_CONT void Fill(const void* source,
vtkm::BufferSizeType sourceSize,
vtkm::BufferSizeType start,
Specify end position when filling values in Buffer This allows us to support `Fill` in `ArrayHandleView` and `ArrayHandleReverse`.
2022-01-11 14:15:41 +00:00
vtkm::BufferSizeType end,
Add ability to fill values in a Buffer This is in preparation to add a method to `ArrayHandle` that allows initializing fill values.
2021-11-22 21:52:41 +00:00
vtkm::cont::Token& token) const;
Replace basic ArrayHandle implementation to use Buffers This encapsulates a lot of the required memory management into the Buffer object and related code. Many now unneeded classes were deleted.
2020-04-22 19:58:59 +00:00
VTKM_CONT bool operator==(const vtkm::cont::internal::Buffer& rhs) const
Add Buffer class The buffer class encapsulates the movement of raw C arrays between host and devices. The `Buffer` class itself is not associated with any device. Instead, `Buffer` is used in conjunction with a new templated class named `DeviceAdapterMemoryManager` that can allocate data on a given device and transfer data as necessary. `DeviceAdapterMemoryManager` will eventually replace the more complicated device adapter classes that manage data on a device. The code in `DeviceAdapterMemoryManager` is actually enclosed in virtual methods. This allows us to limit the number of classes that need to be compiled for a device. Rather, the implementation of `DeviceAdapterMemoryManager` is compiled once with whatever compiler is necessary, and then the `RuntimeDeviceInformation` is used to get the correct object instance.
2020-03-26 23:34:18 +00:00
{
Replace basic ArrayHandle implementation to use Buffers This encapsulates a lot of the required memory management into the Buffer object and related code. Many now unneeded classes were deleted.
2020-04-22 19:58:59 +00:00
return (this->Internals == rhs.Internals);
Add Buffer class The buffer class encapsulates the movement of raw C arrays between host and devices. The `Buffer` class itself is not associated with any device. Instead, `Buffer` is used in conjunction with a new templated class named `DeviceAdapterMemoryManager` that can allocate data on a given device and transfer data as necessary. `DeviceAdapterMemoryManager` will eventually replace the more complicated device adapter classes that manage data on a device. The code in `DeviceAdapterMemoryManager` is actually enclosed in virtual methods. This allows us to limit the number of classes that need to be compiled for a device. Rather, the implementation of `DeviceAdapterMemoryManager` is compiled once with whatever compiler is necessary, and then the `RuntimeDeviceInformation` is used to get the correct object instance.
2020-03-26 23:34:18 +00:00
}
Replace basic ArrayHandle implementation to use Buffers This encapsulates a lot of the required memory management into the Buffer object and related code. Many now unneeded classes were deleted.
2020-04-22 19:58:59 +00:00
VTKM_CONT bool operator!=(const vtkm::cont::internal::Buffer& rhs) const
Add Buffer class The buffer class encapsulates the movement of raw C arrays between host and devices. The `Buffer` class itself is not associated with any device. Instead, `Buffer` is used in conjunction with a new templated class named `DeviceAdapterMemoryManager` that can allocate data on a given device and transfer data as necessary. `DeviceAdapterMemoryManager` will eventually replace the more complicated device adapter classes that manage data on a device. The code in `DeviceAdapterMemoryManager` is actually enclosed in virtual methods. This allows us to limit the number of classes that need to be compiled for a device. Rather, the implementation of `DeviceAdapterMemoryManager` is compiled once with whatever compiler is necessary, and then the `RuntimeDeviceInformation` is used to get the correct object instance.
2020-03-26 23:34:18 +00:00
{
Replace basic ArrayHandle implementation to use Buffers This encapsulates a lot of the required memory management into the Buffer object and related code. Many now unneeded classes were deleted.
2020-04-22 19:58:59 +00:00
return (this->Internals != rhs.Internals);
Add Buffer class The buffer class encapsulates the movement of raw C arrays between host and devices. The `Buffer` class itself is not associated with any device. Instead, `Buffer` is used in conjunction with a new templated class named `DeviceAdapterMemoryManager` that can allocate data on a given device and transfer data as necessary. `DeviceAdapterMemoryManager` will eventually replace the more complicated device adapter classes that manage data on a device. The code in `DeviceAdapterMemoryManager` is actually enclosed in virtual methods. This allows us to limit the number of classes that need to be compiled for a device. Rather, the implementation of `DeviceAdapterMemoryManager` is compiled once with whatever compiler is necessary, and then the `RuntimeDeviceInformation` is used to get the correct object instance.
2020-03-26 23:34:18 +00:00
}
};
Replace basic ArrayHandle implementation to use Buffers This encapsulates a lot of the required memory management into the Buffer object and related code. Many now unneeded classes were deleted.
2020-04-22 19:58:59 +00:00
template <typename... ResetArgs>
VTKM_CONT vtkm::cont::internal::Buffer MakeBuffer(ResetArgs&&... resetArgs)
{
vtkm::cont::internal::Buffer buffer;
buffer.Reset(vtkm::cont::internal::BufferInfo(std::forward<ResetArgs>(resetArgs)...));
return buffer;
}
Add Buffer class The buffer class encapsulates the movement of raw C arrays between host and devices. The `Buffer` class itself is not associated with any device. Instead, `Buffer` is used in conjunction with a new templated class named `DeviceAdapterMemoryManager` that can allocate data on a given device and transfer data as necessary. `DeviceAdapterMemoryManager` will eventually replace the more complicated device adapter classes that manage data on a device. The code in `DeviceAdapterMemoryManager` is actually enclosed in virtual methods. This allows us to limit the number of classes that need to be compiled for a device. Rather, the implementation of `DeviceAdapterMemoryManager` is compiled once with whatever compiler is necessary, and then the `RuntimeDeviceInformation` is used to get the correct object instance.
2020-03-26 23:34:18 +00:00
}
}
} // namespace vtkm::cont::internal
//=============================================================================
// Specializations of serialization related classes
/// @cond SERIALIZATION
namespace mangled_diy_namespace
{
template <>
struct VTKM_CONT_EXPORT Serialization<vtkm::cont::internal::Buffer>
{
static VTKM_CONT void save(BinaryBuffer& bb, const vtkm::cont::internal::Buffer& obj);
static VTKM_CONT void load(BinaryBuffer& bb, vtkm::cont::internal::Buffer& obj);
};
} // diy
/// @endcond SERIALIZATION
#endif //vtk_m_vtkm_cont_internal_Buffer_h
Reference in New Issue Copy Permalink