Atlas de textura vs. textura de matriz: quão diferentes eles são tratados pela CPU e GPU e como isso afeta o desempenho?

O Unity 5.4 (atualmente na versão beta) trará um recurso muito aguardado (desde 2013) que é texturas de matriz - da mesma forma que o ArrayTexture do OpenGL . No entanto, depois de fazer algumas leituras sobre matrizes-texturas e atlas de textura, ainda não consigo entender bem as diferenças técnicas em seu uso por CPUs e GPUs.

Portanto, para ser mais específico, gostaria de pedir uma explicação sobre as principais diferenças entre como o atlas e as matrizes de textura são tratados pela CPU e GPU e, mais importante, como essas diferenças podem afetar o desempenho e o tratamento da memória (por exemplo, como matrizes de textura podem ter mais desempenho do que atlas de textura, etc).

Se faltam detalhes técnicos sobre a implementação do Unity devido à sua infeliz fonte fechada, eu ficaria feliz com uma resposta sobre o OpenGL.s ArrayTexture.

textures rendering texture-atlas

— ASteer
fonte

Não surpreendi que você não tenha encontrado comparação técnica, pois ambos dependem da implementação (mais para matrizes).

— Wondra

É difícil obter informações sobre como os componentes internos do mecanismo Unity funcionam, pois é uma caixa preta de fonte fechada. A única coisa que você pode fazer é analisar cada caso e comparar o uso da CPU e da CPU. Para entender como funciona, seria necessário um engenheiro da Unity, ou seu código-fonte seria aberto ou vazado.

— Jgallant

@ Jon Fair o suficiente, mas na verdade eu estava mais interessado em uma resposta independente de mecanismo. Se varia muito, posso atualizar a pergunta para falar, por exemplo, sobre ArrayTexture do OpenGL: opengl.org/wiki/Array_Texture

— ASteer

Conforme observado nos comentários acima, o desempenho dependerá da implementação, do seu hardware específico e do que você está tentando fazer com as texturas; portanto, a única resposta confiável para o perfil de cada alternativa.

Existem algumas diferenças em termos de como você usa cada opção, que serão aplicadas de forma consistente:

Uma grande diferença é que, para texturas de matriz, cada textura é tratada separadamente para fins como quebra de coordenadas de textura ou mipmapping.

Isso evita problemas comuns com atlas de textura, onde precisamos adicionar preenchimento entre amostras de textura adjacentes para impedir que as amostras nas bordas sangrem juntas, especialmente em níveis mais profundos de mip.

Isso também significa que, se você deseja que suas texturas sejam lado a lado, você pode usar o hardware de amostragem de textura para fazê-lo exatamente como com uma textura de baunilha. Com os atlas, geralmente temos que fazer a matemática dos ladrilhos em nosso shader de fragmento, pois o amostrador apenas envolve / espelhos / grampos / bordas de coordenadas de textura em todo o atlas, e não em ladrilhos individuais.

A principal restrição com texturas de matriz é que elas exigem que todas as suas texturas constituintes tenham a mesma resolução e número de níveis de mip. Se você estiver tentando agrupar texturas com necessidades de resolução muito diferentes (por exemplo, armazenando blocos de terreno cujo LoD cai com a distância em uma textura virtual ), convém a flexibilidade de um atlas.

— DMGregory
fonte

Obrigado, foi exatamente o que eu estava procurando. Quero dizer, não é uma resposta exata sobre o que é mais rápido, menos intensivo em memória - pois é claro que isso depende da implementação. Ainda assim, eu tinha certeza de que algumas dicas sobre o funcionamento de cada caso poderiam ser úteis para entender os cenários habituais de melhor e pior ajuste. Sua resposta realmente me ajudou nisso.

— ASteer

Outra desvantagem das texturas de matriz: elas são limitadas por GL_MAX_ARRAY_TEXTURE_LAYERS. Na minha GPU semi-moderna, isso é 2048, portanto, se você quiser toneladas de pequenas texturas, esse limite poderá ser muito baixo.

— jwd