sokol icon indicating copy to clipboard operation
sokol copied to clipboard

sokol_gfx.h: simplify image data specification

Open floooh opened this issue 2 years ago • 0 comments

Image data for all image attribute combinations should be described by a single ptr/size pair and a clearly defined and documented memory layout.

  • 2D vs 3D vs Array vs Cubemap
  • with and without mipmaps
  • compressed vs uncompressed formats (esp block size for compressed formats, which affecs the smallest mip levels)

Especially figure out a single memory layout for cubemaps with mipmaps that works for all backends. In DDS files, mipmap cascades for faces are packed next to each other: https://learn.microsoft.com/en-us/windows/win32/direct3ddds/dds-file-layout-for-cubic-environment-maps, while in array and 3D textures, slices for one mipmap level are next to each other.

In theory we could define 2 packing conventions:

  • all mipmaps of the same slice/face next to each other
  • all slices of the same mipmap level next to each other

D3D11 and Metal are flexible enough to allow both layouts, because they require a pointer to each single subsurface (so it doesn't matter how those surfaces are arranged in memory)

GL is restricted in that 2D-array and 3D-texture slices must be packed so that all slices of the same mipmap level are next to each other (because an entire mip-level is defined with a single glTexImage3D() call).

Solution: to allow referencing image data with a single ptr/size pair, and at the same time allow loading most textures directly from DDS file dumps across all backends, the expected memory layout will be the same as in DDS files with the expection of array textures:

  • 2d textures: https://learn.microsoft.com/en-us/windows/win32/direct3ddds/dds-file-layout-for-textures
  • cubemaps: https://learn.microsoft.com/en-us/windows/win32/direct3ddds/dds-file-layout-for-cubic-environment-maps
  • 3d textures: https://learn.microsoft.com/en-us/windows/win32/direct3ddds/dds-file-layout-for-volume-textures

Unlike DDS, array textures are expected to be layed out in memory like 3D textures (this is different from the convention used in DDS files - this is so that GL texture creation functions can be used to create array textures without copying data around inside sokol-gfx).

floooh avatar Sep 09 '23 12:09 floooh