On Sat, 3 May 2025 00:58:38 GMT, Sergey Bylokhov <s...@openjdk.org> wrote:
> even if we start allocating raster memory with padding internally, you will > still need to support both cases anyway, right? I don't think so. If we accept a user-created raster, it will not have a native structs initialized due to https://github.com/openjdk/jdk/pull/24378 anyway, so it will be converted into a known type first, before being used in Vulkan loops. So if we create rasters with optimal layouts internally, we should mostly be fine. Similarly for accepting external rasters (https://github.com/openjdk/jdk/pull/24378), we could only initialize native data if the memory layout matches the requirements of our accelerated loops. > are we talking only about padding per pixel, or do we also need full row > padding to meet Vulkan’s alignment requirements? Sorry, not "it will copy `height` rows of `rowLength`", but "it will copy `height` rows of `width` texels with `rowLength` steps". We are talking about per-pixel padding, **not** full row one. Here's the spec on that: https://registry.khronos.org/vulkan/specs/latest/html/vkspec.html#copies-buffers-images There is also an alignment limitation: buffer offset and row length must be multiple of texel block size - for our rasters it means that `startingOffset` and `scanlineStride` must be aligned to `pixelStride`, in order to be able to copy from this memory into Vulkan image directly. Again, this requirement is easily fulfilled when creating rasters internally, and can be checked when accepting external rasters. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24111#discussion_r2072359206
