Hasty Briefsbeta

Bilingual

Hardware Image Compression

a day ago
  • #Graphics Hardware
  • #Texture Compression
  • #Real-time Rendering
  • Hardware image formats have historically suffered from slow innovation due to the need for wide hardware support, delaying adoption until standardization (e.g., BC4/BC5 adoption waited for Direct3D 10).
  • Real-time texture compression, like Spark, enables easier introduction of new hardware formats by eliminating the wait for content creation targeting specific formats.
  • Three current hardware compression formats are ARM's AFRC, ImgTec's PVRIC4, and Apple's Metal Lossy, each with varying compression ratios, quality, and performance.
  • Apple's Metal Lossy compression offers 1:2 ratio, easy API integration, high performance, and supports many pixel formats, but quality is lower than BC formats.
  • ARM's AFRC provides flexible compression ratios (e.g., 2-5 bpc), superior quality outperforming Spark's ASTC, uses YCoCg transform, and performs well in bandwidth-limited scenarios.
  • ImgTec's PVRIC4 currently defaults to 1:2 compression with disappointing quality and potential driver bugs; Spark can outperform it in some cases.
  • Hardware compression is vendor-specific and may not guarantee consistent output, making real-time compression like Spark valuable for cross-vendor consistency.
  • Native hardware compression is mainly available on high-end devices but is not yet exposed in WebGPU, though Spark could integrate it if support emerges.