Como funciona a compactação de textura de hardware?

O fato de compactar os dados em comparação com a matriz de pixels é óbvio.

Mas o que a diferencia da compactação normal (como png, jpeg)?

Como o comentário de Simon aludiu, uma grande diferença entre a compactação de textura de hardware e outra compactação de imagem comumente usada é que a primeira não usa codificação de entropia. A codificação de entropia é o uso de cadeias de bits mais curtas para representar padrões comuns ou repetitivos nos dados de origem - como visto em formatos de contêiner como ZIP, muitos formatos de imagem comuns como GIF, JPEG e PNG e também em muitos tipos de áudio comuns e formatos de vídeo.

A codificação de entropia é boa para compactar todos os tipos de dados, mas produz intrinsecamente uma taxa de compactação variável. Algumas áreas da imagem podem ter poucos detalhes (ou os detalhes são bem previstos pelo modelo de codificação que você está usando) e requerem muito poucos bits, mas outras áreas podem ter detalhes complexos que exigem mais bits para codificação. Isso dificulta a implementação do acesso aleatório, pois não há uma maneira direta de calcular onde, nos dados compactados, você pode encontrar o pixel no momento ( x ,  y) coordenadas. Além disso, a maioria dos esquemas de codificação de entropia é com estado, portanto, não é possível simplesmente começar a decodificar em um local arbitrário no fluxo; você precisa começar do início para criar o estado correto. No entanto, o acesso aleatório é necessário para a amostragem de texturas, pois um sombreador pode amostrar de qualquer local da textura a qualquer momento.

Portanto, em vez de codificar entropia, a compactação de hardware usa esquemas baseados em blocos e de taxa fixa. Por exemplo, na compactação DXT / BCn , a textura é dividida em blocos de 4 × 4 pixels, cada um dos quais é codificado em 64 ou 128 bits (dependendo do formato escolhido); no ASTC , diferentes formatos usam tamanhos de bloco de 4 × 4 a 12 × 12, e todos os blocos são codificados em 128 bits. Os detalhes de como os bits representam os dados da imagem variam entre os formatos (e podem até variar de um bloco para o outro na mesma imagem), mas como a proporção é fixa, é fácil para o hardware calcular onde está na memória o bloco contendo um determinado pixel ( x , y ) e cada bloco é independente, para que possa ser decodificado independentemente de qualquer outro bloco.

Outra consideração na compactação de textura de hardware é que a decodificação deve ser implementada com eficiência no hardware. Isso significa que operações matemáticas pesadas e fluxo de dados complexo são fortemente desfavorecidos. Os formatos BCn, por exemplo, podem ser decodificados executando algumas operações matemáticas inteiras de 8 bits por bloco para preencher uma pequena tabela de pesquisa e, em seguida, apenas procurando a entrada da tabela apropriada por pixel. Isso requer muito pouca área no chip, o que é importante porque você provavelmente deseja decodificar vários blocos em paralelo e, portanto, precisa de várias cópias do hardware de decodificação.

Em contraste, os formatos baseados em DCT, como o JPEG, exigem uma quantidade não trivial de matemática por pixel, sem mencionar um fluxo de dados complexo que troca e transmite vários valores intermediários entre os pixels em um bloco. (Veja neste artigo alguns detalhes sangrentos da decodificação do DCT.) Isso seria muito mais grosseiro para a implementação de hardware, o que eu acho que é por isso que o AFAICT, nenhum hardware de GPU implementou a compactação de textura baseada em DCT ou em wavelet .

"Como a compactação de textura (hardware) funciona" é um tópico amplo. Espero que eu possa fornecer algumas idéias sem duplicar o conteúdo da resposta de Nathan .

Exigências

A compactação de textura difere tipicamente das técnicas de compactação de imagem 'padrão', por exemplo, JPEG / PNG de quatro maneiras principais, conforme descrito em Renderização a partir de texturas compactadas de Beers et al :

1. Velocidade de decodificação : você não deseja que a compactação de textura seja mais lenta (pelo menos não notavelmente) do que usar texturas não compactadas. Também deve ser relativamente simples descomprimir, pois isso pode ajudar a obter descompressão rápida sem custos excessivos de hardware e energia.

2. Acesso aleatório : você não pode prever facilmente quais texels serão necessários durante uma determinada renderização. Se algum subconjunto, M , dos texels acessados ​​vierem, digamos, do meio da imagem, é essencial que você não precise decodificar todas as linhas 'anteriores' da textura para determinar M ; com JPEG e PNG, isso é necessário, pois a decodificação de pixels depende dos dados decodificados anteriormente.
   Observe que, tendo dito isso, apenas porque você tem acesso "aleatório", não significa que você deve tentar amostrar completamente arbitrariamente

3. Taxa de compressão e qualidade visual : Beers et al. Argumentam (de forma convincente) que perder alguma qualidade no resultado compactado para melhorar a taxa de compressão é uma troca que vale a pena. Na renderização em 3D, os dados provavelmente serão manipulados (por exemplo, filtrados e sombreados etc.) e, portanto, alguma perda de qualidade poderá ser ocultada.

4. Codificação / decodificação assimétrica : Embora talvez um pouco mais controversas, eles argumentam que é aceitável que o processo de codificação seja muito mais lento que a decodificação. Dado que a decodificação precisa estar nas taxas de preenchimento HW, isso geralmente é aceitável. (Admito que a compactação de PVRTC, ETC2 e outras na qualidade máxima pode ser mais rápida)

História e Técnicas

Pode surpreender alguns saber que a compressão de texturas existe há mais de três décadas. Os simuladores de vôo dos anos 70 e 80 precisavam acessar quantidades relativamente grandes de dados de textura e, considerando que 1 MB de RAM em 1980 era> US $ 6000 , a redução da pegada de textura era essencial. Como outro exemplo, em meados dos anos 70, mesmo uma pequena quantidade de memória e lógica de alta velocidade, por exemplo, o suficiente para um modesto buffer de quadro RGB de 512x512 ) poderia o preço da casa pequena.

Embora o AFAIK, não explicitamente chamado de compressão de textura, na literatura e nas patentes você possa encontrar referências a técnicas, incluindo:
a. formas simples de síntese de textura matemática / processual,
b. uso de uma textura de canal único (por exemplo, 4bpp) que é então multiplicada por um valor RGB por textura,
c. YUV, e
d. paletas (a literatura sugerindo o uso da abordagem de Heckbert para fazer a compressão)

Modelando Dados da Imagem

Como observado acima, a compactação de textura é quase sempre com perdas e, portanto, o problema passa a ser o de tentar representar os dados importantes de uma maneira compacta, descartando as informações menos significativas. Os vários esquemas que serão descritos abaixo têm um modelo implícito 'parametrizado' que aproxima o comportamento típico dos dados de textura e da resposta do olho.

Além disso, como a compactação de textura tende a usar a codificação de taxa fixa, o processo de compactação geralmente inclui uma etapa de busca para encontrar o conjunto de parâmetros que, quando inseridos no modelo, geram uma boa aproximação da textura original. Essa etapa de pesquisa, no entanto, pode ser demorada.
(Com a possível exceção de ferramentas como optipng , essa é outra área em que o uso típico de PNG e JPEG difere dos esquemas de compactação de textura)

Antes de avançar, para ajudar a entender melhor o TC, vale a pena dar uma olhada na Principal Component Analysis (PCA) - uma ferramenta matemática muito útil para compactação de dados.

Exemplo de textura

Para comparar os vários métodos, usaremos a seguinte imagem:

Observe que esta é uma imagem bastante difícil, especialmente para os métodos de paleta e VQTC, pois abrange grande parte do cubo de cores RGB e apenas 15% dos texels usam cores repetidas.

PC e (após meados dos anos 90) Console de compressão de textura

Para reduzir os custos de dados, alguns jogos de PC e consoles de jogos antigos também usavam imagens de paleta, que é uma forma de quantização vetorial (VQ). As abordagens baseadas em paleta pressupõem que uma determinada imagem use apenas partes relativamente pequenas do cubo de cores RGB (A). Um problema com as texturas da paleta é que as taxas de compactação para a qualidade alcançada são geralmente bastante modestas. A textura de exemplo compactada em "4bpp" (usando o GIMP) produziu Observe novamente que esta é uma imagem relativamente difícil para esquemas de VQ.

VQ com vetores maiores (por exemplo, 2bpp ARGB)

Inspirado por Beers et al, o console do Dreamcast usou o VQ para codificar blocos de 2 x 2 ou até 2 x 4 pixels com bytes únicos. Enquanto os "vetores" nas texturas da paleta são tridimensionais ou 4, os blocos de 2x2 pixels podem ser considerados 16 dimensionais. O esquema de compressão assume que existe uma repetição aproximada e suficiente desses vetores.

Embora o VQ possa alcançar uma qualidade satisfatória com ~ 2bpp, o problema com esses esquemas é que ele requer leituras de memória dependente: Uma leitura inicial do mapa de índice para determinar o código do pixel é seguida por um segundo para buscar os dados de pixel associados com esse código. Caches adicionais podem ajudar a aliviar parte da latência incorrida, mas adicionam complexidade ao hardware.

A imagem de exemplo compactada com o esquema 2bpp Dreamcast é . O mapa de índice é:

A compactação dos dados VQ pode ser feita de várias maneiras; no entanto, IIRC , o acima foi feito usando PCA para derivar e, em seguida, particionar os vetores 16D ao longo do vetor principal em 2 conjuntos, de modo que dois vetores representativos minimizassem o erro médio quadrático. O processo voltou a ocorrer até a produção de 256 vetores candidatos. Uma abordagem global do algoritmo k-means / Lloyd foi aplicada para melhorar os representantes.

Transformações de espaço de cores

As transformações no espaço de cores também fazem uso do PCA, observando que a distribuição global de cores geralmente se espalha ao longo de um eixo principal, com muito menos propagação nos outros eixos. Para representações de YUV, as suposições são de que: a) o eixo principal geralmente está na direção da luminosidade e b) o olho é mais sensível às mudanças nessa direção.

O sistema 3dfx Voodoo forneceu "YAB" , um sistema de compressão "Narrow Channel" de 8bpp, que dividiu cada texel de 8 bits em um formato 322 e aplicou uma transformação de cor selecionada pelo usuário nesses dados para mapeá-lo em RGB. O eixo principal tinha, assim, 8 níveis e os eixos menores, 4 cada.

O chip S3 Virge tinha um esquema um pouco mais simples, 4bpp, que permitia ao usuário especificar, para toda a textura , duas cores finais, que deveriam estar no eixo principal, juntamente com uma textura monocromática de 4bpp. O valor por pixel combinou as cores finais com os pesos apropriados para produzir o resultado RGB.

Esquemas baseados em BTC

Rebobinando alguns anos, Delp e Mitchell projetaram um esquema de compactação de imagem simples (monocromático) chamado Block Truncation Coding (BTC) . Este artigo também incluiu um algoritmo de compactação, mas, para nossos propósitos, estamos interessados ​​principalmente nos dados compactados resultantes e no processo de descompactação.

Nesse esquema, as imagens são divididas em blocos de pixel 4x4, que podem ser compactados independentemente com um algoritmo VQ localizado. Cada bloco é representado por dois "valores", um e B , e um conjunto de bits de índice 4x4, que identificam qual dos dois valores para usar para cada pixel.

S3TC : 4bpp RGB (+ 1bit alpha)
Embora várias variantes de cores do BTC para compactação de imagem tenham sido propostas, é de interesse para nós Iourcha et al S3TC , alguns dos quais parece ser uma redescoberta do trabalho um pouco esquecido do Hoffert et al que foi usado no Quicktime da Apple.

O S3TC original, sem as variantes do DirectX, compacta blocos de RGB ou RGB + 1bit Alpha em 4bpp. Cada bloco 4x4 na textura é substituído por duas cores finais, A e B , das quais até duas outras cores são derivadas por misturas lineares de peso fixo. Além disso, cada texel no bloco possui um índice de 2 bits que determina como selecionar uma dessas quatro cores.

Por exemplo, a seguir é uma seção de 4x4 pixels da imagem de teste compactada com a ferramenta AMD / ATI Compressenator. ( Tecnicamente, ele foi retirado de uma versão de 512x512 da imagem de teste, mas perdoe minha falta de tempo para atualizar os exemplos ).

Isso ilustra o processo de compactação: A média e o eixo principal das cores são calculados. Um melhor ajuste é então realizado para encontrar dois pontos finais que 'assentam' no eixo que, juntamente com as duas combinações derivadas 1: 2 e 2: 1 (ou, em alguns casos, uma mistura 50:50) desses pontos finais, que minimiza o erro. Cada pixel original é mapeado para uma dessas cores para produzir o resultado.

Se, como neste caso, as cores forem razoavelmente aproximadas pelo eixo principal, o erro será relativamente baixo. No entanto, se, como no bloco 4x4 vizinho mostrado abaixo, as cores forem mais diversas, o erro será maior.

A imagem de exemplo, compactada com o AMD Compressonator produz:

Como as cores são determinadas independentemente por bloco, pode haver descontinuidades nos limites do bloco, mas, desde que a resolução seja mantida suficientemente alta, esses artefatos de bloco podem passar despercebidos:

ETC1 : 4bpp A RGB
Ericsson Texture Compression também funciona com blocos de texels 4x4, mas pressupõe que, assim como o YUV, o eixo principal de um conjunto local de texels está frequentemente fortemente correlacionado com "luma". O conjunto de texels pode então ser representado por apenas uma cor média e um 'comprimento' escalar e altamente quantizado da projeção dos texels no eixo assumido.

Como isso reduz os custos de armazenamento de dados em relação ao S3TC, permite à ETC introduzir um esquema de particionamento, no qual o bloco 4x4 é subdividido em um par de sub-blocos horizontais 4x2 ou verticais 2x4. Cada um deles tem sua própria cor média. A imagem de exemplo produz: A área ao redor do bico também ilustra o particionamento horizontal e vertical dos blocos 4x4.

Global + Local

Existem alguns sistemas de compressão de textura que são um cruzamento entre esquemas globais e locais, como o das paletas distribuídas de Ivanov e Kuzmin ou o método do PVRTC .

PVRTC : RGBA de 4 e 2 bpp
pressupõe que uma imagem (na prática, bilateralmente) escalonada é uma boa aproximação ao alvo de resolução máxima e que a diferença entre a aproximação e o alvo, ou seja, a imagem delta, é localmente monocromática, ou seja tem um eixo principal dominante. Além disso, ele pressupõe que o eixo principal local possa ser interpolado pela imagem.

(a fazer: adicione imagens mostrando o detalhamento)

A textura de exemplo, compactada com PVRTC1 4bpp, produz: com a área ao redor do bico:



Comparado aos esquemas de BTC, os artefatos de bloco são geralmente eliminados, mas às vezes pode haver "superação" se houver fortes descontinuidades na imagem de origem, por exemplo, ao redor a silhueta da cabeça do lorikeet.

A variante 2bpp tem, naturalmente, um erro maior que o 4bpp (observe a perda de precisão nas áreas azuis de alta frequência próximas ao pescoço), mas sem dúvida ainda é de qualidade razoável:

Uma nota sobre os custos de descompressão

Embora os algoritmos de compactação para os esquemas descritos acima tenham um custo de avaliação moderado a alto, os algoritmos de descompactação, especialmente para implementações de hardware, são relativamente baratos. O ETC1, por exemplo, requer pouco mais do que alguns MUXes e adicionadores de baixa precisão; S3TC efetivamente um pouco mais unidades de adição para realizar a mistura; e PVRTC, um pouco mais novamente. Em teoria, esses esquemas simples de TC podem permitir que a arquitetura da GPU evite a descompressão até pouco antes do estágio de filtragem, maximizando assim a eficácia dos caches internos.

Outros Esquemas

Outros modos comuns de TC que devem ser mencionados são:

• ETC2 - é um superconjunto (4bpp) do ETC1 que melhora o manuseio de regiões com distribuições de cores que não se alinham bem com 'luma'. Há também uma variante de 4bpp que suporta alfa de 1 bit e um formato de 8bpp para RGBA.

• ATC - É efetivamente uma pequena variação no S3TC .

• FXT1 (3dfx) era uma variante mais ambiciosa do tema S3TC .

• BC6 e BC7: um sistema baseado em bloco de 8bpp que suporta o ARGB. Além dos modos HDR, eles usam um sistema de particionamento mais complexo que o do ETC para tentar modelar melhor a distribuição de cores da imagem.

• PVRTC2: 2 e 4bpp ARGB. Isso introduz modos adicionais, incluindo um para superar limitações com limites fortes nas imagens.

• ASTC: Este também é um sistema baseado em bloco, mas é um pouco mais complicado, pois possui um grande número de tamanhos de bloco possíveis visando uma ampla variedade de bpp. Ele também inclui recursos como até 4 regiões de partição com um gerador de partição pseudo-aleatório e resolução variável para os dados do índice e / ou precisão e modelos de cores.