Quanta memoria occupa una trama sulla GPU?


9

Un png di grandi dimensioni su disco può occupare solo un paio di megabyte, ma immagino che sulla gpu lo stesso png sia archiviato in un formato non compresso che occupa molto più spazio. È vero? Se è vero, quanto spazio?

Risposte:


16

I file JPG e PNG saranno quasi sempre più piccoli su disco che in memoria; devono essere decompressi al volo per acquisire dati RGB grezzi, quindi richiedono più potenza di elaborazione per il caricamento e più RAM in seguito. Così tanti motori moderni scelgono di archiviare sul disco lo stesso formato che hanno in memoria, portando a file delle stesse dimensioni dei requisiti di memoria della trama (ma anche più grandi di un PNG o JPG). RGB / RGBA e S3TC / DXTn / BCn sono i formati più utilizzati, perché vengono letti direttamente in memoria senza alcuna elaborazione (le trame DXT sono precompresse).

Quindi, queste sono le dimensioni per i diversi formati di trama comuni:

  • L (luminanza, ad es. Scala di grigi): larghezza * altezza * 1 byte.
  • LA (luminanza e alfa, comune per i caratteri): larghezza * altezza * 2 byte.
  • RGB (colore, no alfa): larghezza * altezza * 3 byte.
  • RGBA (colore con alfa): larghezza * altezza * 4 byte.
  • DXT1 / BC1 (colore, alfa binario): (larghezza * altezza * 4 byte) / 8 (rapporto di compressione 8: 1).
  • DXT3 / BC2 (colore, alfa nitida) / DXT5 / BC3 (colore, sfumatura alfa): (larghezza * altezza * 4 byte) / 4 (rapporto di compressione 4: 1).

Se usi un'immagine con mipmap , la trama richiederà 4/3 di memoria. Inoltre, la larghezza e l'altezza della trama possono essere arrotondate internamente per essere una potenza di due su hardware vecchio o meno capace e su hardware molto limitato, costretto anche ad essere un quadrato.

Maggiori informazioni su DXT: è una compressione con perdita; questo significa che alcuni dati di colore vengono persi quando si comprime la trama. Ciò ha un impatto negativo sulla trama, distorcendo i bordi nitidi e creando "blocchi" su pendenze; ma i vantaggi sono di gran lunga migliori degli svantaggi (se hai una trama che sembra orribilmente brutta in DXT, mantienila non compressa; gli altri compenseranno la perdita di dimensioni). Inoltre, poiché i pixel sono compressi da blocchi di dimensioni fisse, la larghezza e l'altezza della trama devono essere un multiplo di quattro.


Ciò è corretto, tranne per la prima frase: il formato della trama su disco può essere qualsiasi formato altamente compresso e quindi non occupa lo stesso spazio su disco della VRAM, tranne per i formati di disco che sono serializzazioni dirette dei formati di memoria.

Certo che può, ma controlla le risorse utilizzate nei giochi creati con Unreal Engine, Source, ecc. Di solito non sono compresse su disco, perché al giorno d'oggi c'è spazio su disco più che sufficiente per lasciare le risorse non compresse; e lo spazio risparmiato non compensa il tempo aggiuntivo di RAM e CPU necessario per decomprimere i file su ogni carico.
r2d2rigo,

1
Penso che troverai che varia da motore a motore. Molti dei motori più grandi, specialmente quelli che funzionano su console, useranno un formato del disco identico o vicino al formato della memoria. Ma è abbastanza facile trovare giochi solo per PC con risorse PNG o JPEG. Se devi andare su disco per un carico che dominerà comunque il tuo tempo. Inoltre, Mike menziona specificamente PNG e JPEG come formato del disco.

Principalmente corretto, tranne per il fatto che i formati RGB normalmente non esistono nelle GPU; vedi: opengl.org/wiki/Common_Mistakes#Texture_upload_and_pixel_reads
Maximus

9

Ovviamente: dipende dal formato.

Prendiamo una trama quadrata di 256 x 256 pixel. Se non è compresso a 32 bit con un canale alfa ( Colorin XNA), sono necessari 256 KB ( 256*256*4byte).

I formati a 16 bit (ad es . :)Bgr565 avranno ovviamente la metà della dimensione - 128 KB .

Quindi si arriva ai formati compressi. In XNA hai DXT1, DXT3 e DXT5 (noto anche come compressione S3 ). Questo è un formato di compressione con perdita di dati. È anche un formato basato su blocchi, il che significa che puoi campionare da esso (perché sai in quale blocco si trova un pixel). È anche più veloce, perché usi meno larghezza di banda.

Il rapporto di compressione di DXT1 è 8: 1 e per DXT3 e DXT5 è 4: 1.

Quindi un'immagine DXT1 di 256x256 è 32 KB . E DXT3 o DXT5 è 64 KB .

E poi c'è il mipmapping . Se abilitato, crea una serie di immagini nella memoria grafica della metà delle dimensioni della precedente. Quindi per la nostra immagine 256x256: 128x128, 64x64, 32x32, 16x16, 8x8, 4x4, 2x2, 1x1. Una trama con mipmapping ha approssimativamente il 133% delle dimensioni dell'originale.


4

La maggior parte delle GPU può leggere solo un formato di compressione molto specifico. per esempio. BC *, DXT *, non formati come png. Quindi sì, è vero per la maggior parte che un .png occuperà più spazio nella memoria video che sul disco.

Le trame possono essere archiviate compresse o non compresse nella memoria video e nella memoria di sistema.

Per le trame non compresse, la regola generale è che occuperà la stessa quantità di spazio nella memoria video della forma non compressa nella memoria di sistema.

Per trame compresse DXT1. la GPU memorizza 8 byte per ogni riquadro 4x4 nella trama. I dati non compressi (a 8 bit per canale RGB) sarebbero normalmente 4x4x3 = 48 byte, quindi questo è un rapporto di compressione di 6: 1. Per le trame compresse DXT3 / DXT5, la GPU memorizza 16 byte per ogni riquadro 4x4 nella trama. Questo è un rapporto di compressione leggermente inferiore di 3: 1.

Ci sono alcuni avvertimenti con trame non compresse e compresse:

  • La maggior parte della memoria è allocata in pagine (la cui dimensione varia tra le GPU) di dimensioni fisse. per esempio. 4KB e spesso non allocato e condiviso con altri dati GPU. Vale a dire. se l'impronta della trama è inferiore alla dimensione della pagina, l'impronta nel mem video sarà spesso comunque la dimensione della pagina.

  • Alcuni gpus hanno requisiti di allineamento molto specifici. In passato, alcune GPU avevano il requisito che le trame avessero una potenza di 2 dimensioni. Ciò è stato spesso richiesto per supportare una rappresentazione sfrigolata (vedi Morton Ordering: http://en.wikipedia.org/wiki/Z-order_(curve )) per migliorare la località di accesso durante il campionamento dalla texture. Ciò significava che le trame di dimensioni dispari sarebbero state imbottite al fine di preservare questi requisiti (in genere questa imbottitura è gestita dal conducente). Sebbene l'ordine dei mortoni non sia necessariamente utilizzato nella moderna GPU, potrebbe ancora esserci gonfiore per supportare i requisiti specifici della GPU.

  • Rappresentazioni multiple della trama possono esistere in memoria in qualsiasi momento, soprattutto se si utilizzano blocchi di scarto su di esse. Questo può gonfiare l'utilizzo della memoria fino a quando le rappresentazioni non vengono più utilizzate dalla gpu (che in genere è alcuni frame dietro il rendering della CPU)

  • Se si abilita il mipmapping, i mip aggiuntivi consumeranno in media circa un terzo del livello di mip di base. YMMV basato sulle avvertenze di cui sopra.


0

AFAIK è la larghezza dell'immagine * altezza * BPP, indipendente se si tratta di un PNG, JPG o BMP. Non so come siano disposti DDS o altri formati comprimibili.

La mappatura Mip aumenterà la necessità di memoria video.

Le mie conoscenze in questo argomento potrebbero essere un po 'datate. Ho abbandonato il 3D qualche tempo fa.


2
Le immagini hanno anche un passo (o falcata), che è la quantità di byte tra la fine di una riga e l'inizio della riga successiva di pixel. Nessun altro l'ha menzionato, quindi potrei sbagliarmi.
CiscoIPPhone

1
Di solito "passo" si riferisce alla lunghezza di una linea di scansione in byte (come in Freetype e SDL), e "falcata" si riferisce allo spazio tra gli elementi, che può essere pixel o linee di scansione (come in OpenGL e il terzo argomento di Python). Entrambi i valori sono necessari per eseguire l'elaborazione delle immagini, ma "solitamente" pitch = width * bytes_per_pixel e stride = 0. I termini sono spesso usati in modo approssimativo e confuso, quindi è meglio controllare i documenti API per la tua libreria preferita.
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.