I know that texture caching on GPU works to optimize locality in 2D (or 3D if using 3D textures). I believe this is done using space-filling curves like Morton or Hilbert curves.

When passing an array of texture data to the GPU, though, for example using glTextureSubImage2D, the data is specified in scan-line order.

So how and when does the conversion take place? I can think of a couple of possibilites:

  1. The texture is laid out linearly in VRAM, and the texture unit merges transactions on different areas when loading to cache.
  2. The texture gets swizzled when passed to the GPU, and is stored in VRAM in Morton-coded order (or another space-filling curve).

So which is it, or is there another possibility I've missed? If it's option 2, is there an option to pass textures 'verbatim' if you already have a Morton-coded version on CPU-side? Or would you have to de-swizzle it before loading to GPU?


In vulkan, like a lot of other implicit operations, this transition is made explicit. Images can be in one of 2 tiling layouts: optimal and linear. Linear images have a fixed layout while optimal is with implementation-defined space-filling curve. (There is no way currently to figure out which exact curve is used).

To fill a optimally tiled image you need to copy from another image or from a vkBuffer (which has the data in linear format). The swizzle is done as part of the copy. But with the requirement that the data source must not be changed during the operation. Because other operations are allowed be read from the copy operation's source.

  • $\begingroup$ That's cool. I'll need to give Vulkan a try one of these days, I had a look at it when it came out but got scared off by the 1000-line hello triangle program! $\endgroup$
    – russ
    Nov 21 '17 at 12:21
  • $\begingroup$ TBH most of those 1000 lines busywork is filling in structs that 80% of the time will not need to change, but are there for the remaining 20% to have a good path. Once you understand the general architecture of the api and can place why each struct is important it's not that horrible. $\endgroup$ Nov 21 '17 at 12:25

Possibly "all of the above".

I've worked with different generations of the same vendor's hardware which have, variously, required software (either the API/driver or the texture tool) to preorder the texture data into a Morton/tiled layout, and others which, I think, had more "built-in" processing.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.