Se eu tiver muitas texturas (digamos, 5+ mapas) vinculadas à mesma unidade de textura, isso funciona pior para o cache do que se eu tivesse apenas 2 ou 3 texturas?
Apenas adicionando à resposta do imallett , é verdade que aumentar o número de acessos a diferentes dados de textura em um shader aumentará a pressão no (s) cache (s) da GPU, mas existem vários outros fatores que podem influenciar significativamente o efeito. Também é possivelmente complicado pelo fato de que, como os caches da CPU, pode haver várias camadas de cache em uma GPU, por exemplo. Unidade de textura <= L0 <= L1 <= ..Memória
Se você tiver uma cena que possui minificação de dados de textura, seja devido à perspectiva ou à escala simples e não estiver usando o mapeamento MIP, obterá o alias. Isso não vai apenas produzir artefatos visuais; é muito provável que seja um problema de desempenho.
Assim que você obtiver um alias, o acesso aos endereços da textura se tornará incoerente, o que não só acabará prejudicando os caches, mas também introduzirá muitas "quebras de página" DRAM (mais corretamente, quebras de linha) que podem ser caras. O mapeamento MIP ajuda a reduzir a incoerência.
Talvez seja uma opção óbvia, mas se você puder usar a compactação de textura (por exemplo, DXTn | ETC * | PVRTC * | etc) direcionando de 8bpp a 2bpp, por exemplo, você poderá aumentar bastante a eficácia da largura de banda / cache de memória, fatores de 4x a 16x. Agora não posso falar por todas as GPUs, mas alguns esquemas de compactação de textura (por exemplo, os listados acima) são tão simples de decodificar no hardware, que os dados podem permanecer compactados em toda a hierarquia de cache e serem descomprimidos apenas na unidade de textura, portanto multiplicando efetivamente o tamanho desses caches.
Obviamente, alguns dados, por exemplo, destinos de renderização usados como dados de textura em renderizações subsequentes, não podem empregar compactação de textura. Sempre que puder, use o menor formato de pixel que fará o trabalho, ou seja, se 32 / 16bpp (A) RGB o fizer, não use formatos de flutuação 4x32!
Isso está um pouco relacionado ao exemplo de aliasing acima, mas vimos casos em que grandes destinos de renderização são criados, mas apenas com poucas amostras. As linhas de cache, seja em CPUs ou GPUs, são muito longas; portanto, se você estiver usando apenas um pixel em cada linha de cache, estará desperdiçando transferências.
Além disso, as texturas compactadas do WRT conseguem atingir a compactação compartilhando efetivamente dados entre uma região local de texels. Se você não tiver acesso coerente, além da redução do espaço ocupado na memória, a compactação provavelmente não ajudará.
Não é muito um problema de cache (bem, a menos que os acessos computados sejam bastante incoerentes), mas os acessos de textura que não são definidos diretamente pelas coordenadas UV fornecidas com os vértices podem ser mais lentos do que aqueles definidos diretamente.
Embora eu suspeite que a maioria das texturas hoje em dia seja armazenada em ordem de lado a lado ou do tipo Morton (também conhecida como Twiddled / Swizzled) (ou mesmo uma combinação de ambas), algumas texturas ainda podem estar na ordem das linhas de digitalização, o que significa que a rotação de é provável que a textura leve a um número significativo de falhas de cache / quebras de página. Infelizmente, eu realmente não sei identificar se um formato específico é organizado dessa maneira.
(Para leitura em segundo plano, tente The Truth About Texture Mapping , de Blinn. FWIW, dando alguns passos adiante, levou ao uso de texturas de ordem Twiddled (ordem Morton) em pelo menos alguns hardwares para PC ).
A resposta depende do que você quer dizer. O hardware moderno (por exemplo, com texturas sem encadernação) realmente não se importa muito com quantas texturas são "encadernadas". A verdadeira questão é quantos você usa .
As texturas geralmente armazenam dados de maneira amigável ao cache (uma curva de Morton, acredito). Se você usar mais texturas, terá mais erros de cache, pois agora as texturas competem entre si por espaço.
Isso realmente se resume à conhecida e antiga heurística da programação de shader: os toques de textura são lentos; não use demais.