Quanta memória uma textura ocupa na GPU?


9

Um png grande no disco pode ocupar apenas alguns megabytes, mas imagino que no gpu o mesmo png seja armazenado em um formato não compactado, que ocupa muito mais espaço. Isso é verdade? Se é verdade, quanto espaço?

Respostas:


16

Os arquivos JPG e PNG quase sempre serão menores no disco do que na memória; eles precisam ser descompactados on-the-fly para adquirir dados RGB brutos, exigindo mais poder de processamento para o carregamento e mais RAM posteriormente. Muitos mecanismos modernos optam por armazenar o mesmo formato no disco que na memória, levando a arquivos que têm o mesmo tamanho que os requisitos de memória da textura (mas também maiores que um PNG ou JPG). RGB / RGBA e S3TC / DXTn / BCn são os formatos mais amplamente utilizados, porque são lidos diretamente na memória sem nenhum processamento (as texturas DXT são pré-compactadas).

Portanto, esses são os tamanhos para diferentes formatos de textura comuns:

  • L (luminância, por exemplo, escala de cinza): largura * altura * 1 byte.
  • LA (luminância e alfa, comum para fontes): largura * altura * 2 bytes.
  • RGB (cor, sem alfa): largura * altura * 3 bytes.
  • RGBA (cor com alfa): largura * altura * 4 bytes.
  • DXT1 / BC1 (cor, alfa binário): (largura * altura * 4 bytes) / 8 (taxa de compressão 8: 1).
  • DXT3 / BC2 (cor, alfa nítido) / DXT5 / BC3 (cor, alfa de gradiente): (largura * altura * 4 bytes) / 4 (taxa de compressão 4: 1).

Se você usar uma imagem com mipmaps , a textura precisará de 4/3 de memória. Além disso, a largura e a altura da textura podem ser arredondadas internamente para ser uma potência de dois em hardware antigo ou menos capaz e em um hardware muito limitado, também forçado a ser quadrado.

Mais informações sobre o DXT: é uma compactação com perdas; isso significa que alguns dados de cores são perdidos ao compactar a textura. Isso tem um impacto negativo na sua textura, distorcendo bordas nítidas e criando "blocos" em gradientes; mas os benefícios são muito melhores do que as desvantagens (se você tiver uma textura que parece terrivelmente ruim no DXT, mantenha-a descompactada; os outros compensarão a perda de tamanho). Além disso, como os pixels são compactados por blocos de tamanho fixo, a largura e a altura da textura devem ser múltiplas de quatro.


Isso está correto, exceto na sua primeira frase - o formato da textura no disco pode ser qualquer formato altamente compactado e, portanto, não ocupa o mesmo espaço no disco que na VRAM, exceto os formatos de disco que são serializações diretas dos formatos de memória.

Claro que pode, mas verifique os ativos usados ​​nos jogos criados com o Unreal Engine, Source etc. Eles geralmente não são compactados no disco, porque hoje em dia há espaço em disco suficiente para deixar os recursos descompactados; e o espaço economizado não compensa o tempo extra de RAM e CPU necessário para descompactar os arquivos em cada carregamento.
R2d2rigo 04/11

11
Acho que você descobrirá que isso varia de mecanismo para mecanismo. Muitos dos mecanismos maiores - especialmente aqueles que funcionam em consoles - usarão um formato de disco idêntico ou próximo ao formato de memória. Mas é muito fácil encontrar jogos apenas para PC enviados com recursos PNG ou JPEG. Se você precisar ir ao disco para carregar, isso vai dominar o seu tempo. Além disso, Mike menciona especificamente PNG e JPEG como o formato do disco.

Principalmente correto, exceto que os formatos RGB normalmente não existem nas GPUs; veja: opengl.org/wiki/Common_Mistakes#Texture_upload_and_pixel_reads
Maximus Minimus

9

Obviamente: depende do formato.

Vamos dar uma textura quadrada de 256 por 256 pixels. Se não estiver compactado em 32 bits com um canal alfa ( Colorem XNA), serão necessários 256 KB ( 256*256*4bytes).

Formatos de 16 bits (por exemplo :)Bgr565 obviamente terão metade do tamanho - 128 KB .

Então você entra nos formatos compactados. No XNA, você tem DXT1, DXT3 e DXT5 (também conhecido como S3 Compression ). Este é um formato de compactação com perdas. Também é um formato baseado em bloco - o que significa que você pode fazer uma amostra dele (porque você sabe em qual bloco o pixel está). Também é mais rápido, porque você usa menos largura de banda.

A taxa de compactação do DXT1 é 8: 1 e para o DXT3 e o DXT5 é 4: 1.

Portanto, uma imagem DXT1 de 256x256 tem 32 KB . E DXT3 ou DXT5 é 64KB .

E depois há o mipmapping . Se isso estiver ativado, isso criará uma série de imagens na memória gráfica com metade do tamanho da anterior. Portanto, para a nossa imagem de 256x256: 128x128, 64x64, 32x32, 16x16, 8x8, 4x4, 2x2, 1x1. Uma textura com mipmapping é aproximadamente 133% do tamanho do original.


4

A maioria das GPUs pode ler apenas um formato de compactação muito específico. por exemplo. BC *, DXT *, não formatos como png. Portanto, sim, na maioria das vezes é verdade que um .png ocupará mais espaço na memória de vídeo do que no disco.

As texturas podem ser armazenadas compactadas ou descompactadas na memória de vídeo e na memória do sistema.

Para texturas não compactadas, a regra geral é que ela ocupará a mesma quantidade de espaço na memória de vídeo e na forma não compactada na memória do sistema.

Para texturas compactadas DXT1. a GPU armazena 8 bytes para cada bloco 4x4 em sua textura. Os dados não compactados (a 8 bits por canal RGB) normalmente seriam 4x4x3 = 48 bytes, portanto, essa é uma taxa de compactação de 6: 1. Para texturas compactadas DXT3 / DXT5, a GPU armazena 16 bytes para cada bloco 4x4 em sua textura. Essa é uma taxa de compressão um pouco menor de 3: 1.

Existem algumas ressalvas com as texturas não compactadas e compactadas:

  • A maior parte da memória é alocada em páginas (cujo tamanho varia entre as GPUs) de tamanho fixo. por exemplo. 4KB e muitas vezes isso não é subalocado e compartilhado com outros dados da GPU. Ou seja. se a sua pegada de textura for menor que o tamanho da página, a pegada em vid mem geralmente continuará sendo o tamanho da página.

  • Alguns gpus têm requisitos de alinhamento muito específicos. No passado, algumas GPUs exigiam que as texturas tivessem uma potência de 2 em tamanho. Isso geralmente era necessário para oferecer suporte a uma representação distorcida (consulte Morton Ordering: http://en.wikipedia.org/wiki/Z-order_(curve )) para melhorar a localidade de acesso ao coletar amostras da textura. Isso significava que texturas de tamanhos ímpares seriam preenchidas para preservar esses requisitos (normalmente esse preenchimento é tratado pelo driver). Embora a ordem morton não seja necessariamente usada nos gpus modernos, ainda pode haver inchaço para suportar os requisitos específicos do gpu.

  • Várias representações de sua textura podem existir na memória a qualquer momento, especialmente se você estiver usando bloqueios de descarte. Isso pode aumentar o uso de memória até que as representações não sejam mais usadas pela gpu (que geralmente está alguns quadros atrás da renderização da CPU)

  • Se você ativar o mipmapping, os mips adicionais consumirão, em média, cerca de um terço do nível mip básico. YMMV com base nas advertências acima.


0

AFAIK é a largura das imagens * altura * BPP, independente se for PNG, JPG ou BMP. Não sei como são dispostos o DDS ou outros formatos compactáveis.

O mapeamento Mip aumentará a necessidade de memória de vídeo para.

Meu conhecimento neste tópico pode estar um pouco desatualizado. Eu abandonei o 3D há um tempo atrás.


2
As imagens também têm um passo (ou passo), que é a quantidade de bytes entre o final de uma linha e o início da próxima linha de pixels. Ninguém mais mencionou isso, então eu posso estar enganado.
CiscoIPPhone

11
Normalmente, "pitch" refere-se ao comprimento de uma linha de varredura em bytes (como no Freetype e SDL) e "stride" refere-se ao espaço entre os elementos, que podem ser pixels ou linhas de varredura (como no argumento da terceira fatia do OpenGL e do Python). Os dois valores são necessários para o processamento da imagem, mas "geralmente" pitch = width * bytes_per_pixel e stride = 0. Os termos são frequentemente usados ​​de maneira vaga e confusa, portanto, é melhor verificar os documentos da API para sua biblioteca de escolha.
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.