Placement-independent POD array views for the GPU memory foundation. More...
#include <cstddef>#include <cstdint>#include <cstring>#include <type_traits>#include "EBGeometry_GPU.hpp"#include "EBGeometry_Macros.hpp"#include "EBGeometry_Pool.hpp"
Include dependency graph for EBGeometry_PODVector.hpp:
This graph shows which files directly or indirectly include this file:
Go to the source code of this file.
Classes | |
| struct | EBGeometry::PODSpan< T > |
| Raw pointer + size view into a Pool block, for hot inner loops. More... | |
| struct | EBGeometry::PODVector< T > |
| Placement-independent descriptor of a POD array inside a Pool. More... | |
Namespaces | |
| namespace | EBGeometry |
| Namespace containing all of EBGeometry's functionality. | |
Detailed Description
Placement-independent POD array views for the GPU memory foundation.
A EBGeometry::PODVector<T> is a trivially-copyable descriptor of a contiguous array of T living inside a EBGeometry::Pool. Crucially it stores a byte offset from the pool's base rather than a pointer, so the same EBGeometry::PODVector value resolves correctly against a host base and against a device base after a EBGeometry::Pool::mirror – with zero pointer patching. A structure built entirely from EBGeometry::PODVector members is therefore itself trivially copyable and survives a host-to-device memcpy unchanged.
Two access styles are provided:
- EBGeometry::PODVector::at / EBGeometry::PODVector::data resolve
base+offseton every call. Always correct, host and device, while the pool is still being built into and after freeze. This is the default. - EBGeometry::PODVector::bind returns a EBGeometry::PODSpan<T> – a raw pointer + size for a genuinely hot inner loop. A span captures a raw pointer, so it follows the pool's resolve, use, discard rule (see EBGeometry::Pool::reserve): it must not outlive the next reserve on that pool, which may grow and move the block. Nothing enforces this; taking the span against a frozen (or mirrored) pool is the one case where no reserve can follow.
