3 ms·

When I want compressed images, I prefer lossy codecs supported by GPUs. A nice thing about them, they decompress on demand by GPU cores, thus saving not just st

When I want compressed images, I prefer lossy codecs supported by GPUs. A nice thing about them, they decompress on demand by GPU cores, thus saving not just storage, also VRAM bandwidth. For color images on Windows, D3D 11.0 and newer versions require support of BC7 decompression: https://learn.microsoft.com/en-us/windows/win32/direct3d11/bc7-format https://learn.microsoft.com/en-us/windows/win32/direct3d11/b... On Linux, some embedded GPUs I targeted supported ASTC decompression: https://en.wikipedia.org/wiki/Adaptive_scalable_texture_compression https://en.wikipedia.org/wiki/Adaptive_scalable_texture_comp...

jsheard 4y ago
The author of the OP also develops Basis, which is designed to take advantage of GPU texture compression formats. GPU formats are efficient in terms of memory space and bandwidth usage, but they have a fixed bits-per-pixel so they're not the most efficient for storage and transmission. There's also a rift between which formats are supported on desktop and mobile GPUs. Basis layers on a second level of variable-bitrate compression which is designed to be efficient to transcode to various compressed GPU formats (for both desktop and mobile) on the fly. https://github.com/BinomialLLC/basis_universal https://github.com/BinomialLLC/basis_universal Delivering images in a GPU-friendly manner on the web could be a massive memory saver (PNG/JPGs end up being 32 bits-per-pixel in memory, while GPU formats are usually 4bpp or 8bpp) but web standards haven't caught up yet, for now the only way to display these formats on the web is inside a WebGL context. It works, but it's a lot of machinery just to show a picture.
kvark 4y ago
GPU compression formats are still well subjected to entropy encoders such as LZ family.
- deleted 4y ago
  [deleted]
brucethemoose2 4y ago
GPUs can do LZ4 decompression. So you could still save ~50% PCIe bandwidth and a bunch of CPU time with these formats... but not VRAM, since (unlike BC7) its still a raw bitmap in memory. Apparently modern GPUs losslessly compress textures in memory by themselves, but the only info I can find is that this is proprietary AMD/Nvidia/Intel voodoo magic.
- kevingadd 4y ago
  AFAIK lossless compression of textures is not an automatic thing for GPUs, however framebuffers - the things you render to - are losslessly compressed to reduce bandwidth usage for rendering and scan-out. You're correct that it's vendor secret sauce. People with access to game console SDKs know a bit more about how it works since you can see the compressed frame buffer contents and you have to manually call the right APIs in the SDK to decompress the frame buffer before you can read it back. Historically lossless compression has also been applied to the depth buffer when rendering, though it isn't done the same way as the lossless framebuffer compression since depth values are floating point with a limited range. You can find more information about how that stuff works online unlike color compression, since people optimize around it - try searching for "hierarchical Z". Lossless framebuffer compression becomes especially important in cases where you are using MSAA or SSAA, where you might have a framebuffer containing 4 or more "samples" for every rendered pixel. If all of the samples are from the same polygon, it's quite possible that they will have the same value, so it's really profitable to compress them. Then at the end when you do your "resolve" to turn those 4+ MSAA/SSAA samples into a single pixel, that step becomes easier too.
  - rasz 4y ago
    >"hierarchical Z" isnt that one called compression just for marketing purposes? Afaik its a caching technique aimed at lowering latency cost of touching Zbuffer. It actually takes more ram than just raw non duplicated data.
    - kevingadd 4y ago
      The full resolution depth data doesn't always exist, which is why it can reduce bandwidth usage. It probably depends on the architecture, I've seen cases where there is no full resolution depth buffer and you have to generate one via decompression.

jsheard 4y ago

The author of the OP also develops Basis, which is designed to take advantage of GPU texture compression formats. GPU formats are efficient in terms of memory space and bandwidth usage, but they have a fixed bits-per-pixel so they're not the most efficient for storage and transmission. There's also a rift between which formats are supported on desktop and mobile GPUs. Basis layers on a second level of variable-bitrate compression which is designed to be efficient to transcode to various compressed GPU formats (for both desktop and mobile) on the fly. https://github.com/BinomialLLC/basis_universal https://github.com/BinomialLLC/basis_universal Delivering images in a GPU-friendly manner on the web could be a massive memory saver (PNG/JPGs end up being 32 bits-per-pixel in memory, while GPU formats are usually 4bpp or 8bpp) but web standards haven't caught up yet, for now the only way to display these formats on the web is inside a WebGL context. It works, but it's a lot of machinery just to show a picture.

kvark 4y ago

GPU compression formats are still well subjected to entropy encoders such as LZ family.

deleted 4y ago
[deleted]

brucethemoose2 4y ago

GPUs can do LZ4 decompression. So you could still save ~50% PCIe bandwidth and a bunch of CPU time with these formats... but not VRAM, since (unlike BC7) its still a raw bitmap in memory. Apparently modern GPUs losslessly compress textures in memory by themselves, but the only info I can find is that this is proprietary AMD/Nvidia/Intel voodoo magic.

kevingadd 4y ago
AFAIK lossless compression of textures is not an automatic thing for GPUs, however framebuffers - the things you render to - are losslessly compressed to reduce bandwidth usage for rendering and scan-out. You're correct that it's vendor secret sauce. People with access to game console SDKs know a bit more about how it works since you can see the compressed frame buffer contents and you have to manually call the right APIs in the SDK to decompress the frame buffer before you can read it back. Historically lossless compression has also been applied to the depth buffer when rendering, though it isn't done the same way as the lossless framebuffer compression since depth values are floating point with a limited range. You can find more information about how that stuff works online unlike color compression, since people optimize around it - try searching for "hierarchical Z". Lossless framebuffer compression becomes especially important in cases where you are using MSAA or SSAA, where you might have a framebuffer containing 4 or more "samples" for every rendered pixel. If all of the samples are from the same polygon, it's quite possible that they will have the same value, so it's really profitable to compress them. Then at the end when you do your "resolve" to turn those 4+ MSAA/SSAA samples into a single pixel, that step becomes easier too.
- rasz 4y ago
  >"hierarchical Z" isnt that one called compression just for marketing purposes? Afaik its a caching technique aimed at lowering latency cost of touching Zbuffer. It actually takes more ram than just raw non duplicated data.
  - kevingadd 4y ago
    The full resolution depth data doesn't always exist, which is why it can reduce bandwidth usage. It probably depends on the architecture, I've seen cases where there is no full resolution depth buffer and you have to generate one via decompression.