Petascale changes everything

 Let's say you have multiple petabytes of JPEG's/WebP/etc. content and you need (not want - because your competitors are doing it already) to add GPU texture support to your app. What do you do?

• Encode 2-3x times without supercompression (BC7+ASTC, maybe ETC1 too, no supercompression): utterly impractical, explodes (8x-16x or more) overall content size. Even 1 format (say ASTC) without supercompression is impractical - explodes content size.
• Use supercompression to a universal texture format, transcode on device (native or plain WASM): Adds another ~1-1.5 petabytes. The tech is entirely free, has no driver dependencies and is standardized by Khronos.
• Use compute shaders, try to transcode on device: but now you're endlessly chasing ever-changing mobile GPU driver bugs until the end of time, outliers can't use your app reliably. You're also stuck with large textures in VRAM because you can't exploit the largest ASTC block sizes (beyond 6x6, and even 6x6 sacrifices quality due to compute shader issues). Supercompressed solutions can readily exploit ASTC 8x8 (2bpp in VRAM), 10x10 (1.28 bpp) and 12x12 (0.89 bpp), while compute shader solutions are limited to the smallest block sizes (3.56 bpp - 8 bpp) and have to make sacrifices (such as disabling dual plane support in some scenarios) to even achieve that.

At petascale many things that are taken for granted ("we'll just encode multiple times!") aren't practical. We knew this when we started Binomial to work on GPU texture tech. Our tech was already quietly deployed at petascale over a decade ago. At this scale supercompression is the way to go - the only approach that scales.

Once your customer base is 100's of millions to 1+ billion, even a ~.1% failure rate is intolerable. If a compute shader (driver dependent) failure prevents a firefighter, pilot, or war fighter from reliably seeing their map or geospatial content, you can't ship it.