You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be very useful to be able to specify the buffer row extent (and the buffer image height, in the 3D case) when calling the decoding API, so that the decoder can handle non tightly-packed data.
Row stride for each 2D input and output image seems like a useful thing to add.
For volumetric compression the data is provided as an array of 2D slices, so there is no need for a plane stride because you can already specify an arbitrary base pointer for each slice.
It would be very useful to be able to specify the buffer row extent (and the buffer image height, in the 3D case) when calling the decoding API, so that the decoder can handle non tightly-packed data.
This could happen in a variety of scenarios (for example, if we're trying to decode just a portion of a larger image), and would essentially mirror the Vulkan API (https://registry.khronos.org/vulkan/specs/latest/man/html/VkBufferImageCopy.html)
In the default case when buffer row extent and buffer image height are 0, the buffer can be assumed to be tightly packed.
The text was updated successfully, but these errors were encountered: