Memory-compatible view of a DataVariant for texel upload. More...
#include <TextureAccess.hpp>
Collaboration diagram for MayaFlux::Kakshya::TextureAccess:Public Member Functions | |
| size_t | bytes_per_texel () const noexcept |
| Bytes per texel for this format. | |
| uint32_t | channel_count () const noexcept |
| Number of channels (components per texel). | |
| bool | was_promoted () const noexcept |
| True when data_ptr points into conversion_buffer rather than the original variant storage (i.e. | |
Public Attributes | |
| size_t | byte_count = 0 |
| std::vector< std::byte > | conversion_buffer |
| Promotion buffer. | |
| const void * | data_ptr = nullptr |
| GpuDataFormat | format = GpuDataFormat::VEC4_F32 |
Detailed Description
Memory-compatible view of a DataVariant for texel upload.
Analogous to VertexLayout: describes what the data IS in memory terms — pointer, byte count, and the GpuDataFormat that faithfully represents it — with no knowledge of Vulkan format enumerants or Portal types. The Portal layer maps GpuDataFormat to ImageFormat or vk::Format.
For types that map directly (vec2, vec4, float, uint8_t, complex<float>) data_ptr points into the variant's own storage — zero copy.
For glm::vec3, which has no universally-supported 3-channel float sampled image format in Vulkan, the variant is promoted to VEC4_F32 with W=0. In this case conversion_buffer holds the promoted data and data_ptr points into it. The promotion is logged as a warning.
Rejected types (as_texture_access returns std::nullopt, logs error): vector<complex<double>> RG64F is not a sampled image format in Vulkan. vector<glm::mat4> Ambiguous layout; caller must unpack to vec4 first. VEC2_F64 / VEC3_F64 / VEC4_F64 variants do not exist in DataVariant — included in GpuDataFormat for buffer use only.
Definition at line 30 of file TextureAccess.hpp.
The documentation for this struct was generated from the following files:
