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/BitField.cxx

120 lines
4.0 KiB
C++
Raw Normal View History

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
//============================================================================
// 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/BitField.h>
#include <vtkm/cont/Logging.h>
namespace vtkm
{
namespace cont
{
namespace detail
{
} // namespace detail
BitField::BitField()
{
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
this->Buffer.SetMetaData(internal::BitFieldMetaData{});
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::Id BitField::GetNumberOfBits() const
{
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
return this->Buffer.GetMetaData<internal::BitFieldMetaData>().NumberOfBits;
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
}
void BitField::Allocate(vtkm::Id numberOfBits,
vtkm::CopyFlag preserve,
vtkm::cont::Token& token) const
{
const vtkm::BufferSizeType bytesNeeded = (numberOfBits + CHAR_BIT - 1) / CHAR_BIT;
const vtkm::BufferSizeType blocksNeeded = (bytesNeeded + BlockSize - 1) / BlockSize;
const vtkm::BufferSizeType numBytes = blocksNeeded * BlockSize;
VTKM_LOG_F(vtkm::cont::LogLevel::MemCont,
"BitField Allocation: %llu bits, blocked up to %s bytes.",
static_cast<unsigned long long>(numberOfBits),
vtkm::cont::GetSizeString(static_cast<vtkm::UInt64>(numBytes)).c_str());
this->Buffer.SetNumberOfBytes(numBytes, preserve, token);
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
this->Buffer.GetMetaData<internal::BitFieldMetaData>().NumberOfBits = numberOfBits;
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
}
Add BitField::Fill and BitField::AllocateAndFill
2022-01-03 18:51:25 +00:00
void BitField::FillImpl(const void* word,
vtkm::BufferSizeType wordSize,
vtkm::cont::Token& token) const
{
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
this->Buffer.Fill(word, wordSize, 0, this->Buffer.GetNumberOfBytes(), token);
Add BitField::Fill and BitField::AllocateAndFill
2022-01-03 18:51:25 +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
void BitField::ReleaseResourcesExecution()
{
this->Buffer.ReleaseDeviceResources();
}
void BitField::ReleaseResources()
{
vtkm::cont::Token token;
this->Buffer.SetNumberOfBytes(0, vtkm::CopyFlag::Off, token);
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
this->Buffer.GetMetaData<internal::BitFieldMetaData>().NumberOfBits = 0;
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
}
void BitField::SyncControlArray() const
{
vtkm::cont::Token token;
this->Buffer.ReadPointerHost(token);
}
bool BitField::IsOnDevice(vtkm::cont::DeviceAdapterId device) const
{
return this->Buffer.IsAllocatedOnDevice(device);
}
BitField::WritePortalType BitField::WritePortal() const
{
vtkm::cont::Token token;
return WritePortalType(this->Buffer.WritePointerHost(token),
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
this->Buffer.GetMetaData<internal::BitFieldMetaData>().NumberOfBits);
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
}
BitField::ReadPortalType BitField::ReadPortal() const
{
vtkm::cont::Token token;
return ReadPortalType(this->Buffer.ReadPointerHost(token),
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
this->Buffer.GetMetaData<internal::BitFieldMetaData>().NumberOfBits);
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
}
BitField::ReadPortalType BitField::PrepareForInput(vtkm::cont::DeviceAdapterId device,
vtkm::cont::Token& token) const
{
return ReadPortalType(this->Buffer.ReadPointerDevice(device, token),
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
this->Buffer.GetMetaData<internal::BitFieldMetaData>().NumberOfBits);
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
}
BitField::WritePortalType BitField::PrepareForOutput(vtkm::Id numBits,
vtkm::cont::DeviceAdapterId device,
vtkm::cont::Token& token) const
{
this->Allocate(numBits, vtkm::CopyFlag::Off, token);
return WritePortalType(this->Buffer.WritePointerDevice(device, token),
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
this->Buffer.GetMetaData<internal::BitFieldMetaData>().NumberOfBits);
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
}
BitField::WritePortalType BitField::PrepareForInPlace(vtkm::cont::DeviceAdapterId device,
vtkm::cont::Token& token) const
{
return WritePortalType(this->Buffer.WritePointerDevice(device, token),
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
this->Buffer.GetMetaData<internal::BitFieldMetaData>().NumberOfBits);
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
}
}
} // namespace vtkm::cont
Reference in New Issue Copy Permalink