2012-06-14 11 views
25

Quali sono gli svantaggi di usare sempre l'alginamento di 1?glPixelStorei (GL_UNPACK_ALIGNMENT, 1) Svantaggi?

glPixelStorei(GL_UNPACK_ALIGNMENT, 1) 
glPixelStorei(GL_PACK_ALIGNMENT, 1) 

Impatterà sulle prestazioni dei moderni gpus?

+0

Intendi, oltre al fatto che alcuni dei tuoi dati potrebbero non avere righe allineate a 1 byte? –

+0

Per le trame non POTS può influire sulla velocità di upload/download. Per le trame POTS non dovrebbe avere alcun effetto. –

+0

@DietrichEpp: Che cos'è POTS-textures? – ronag

risposta

39

In che modo i dati non possono essere allineati a 1 byte?

Questo suggerisce fortemente una mancanza di comprensione di ciò che il row alignment in pixel transfer operations means.

Si prevede che i dati di immagine passati a OpenGL vengano raggruppati in righe. Ogni riga contiene il numero di pixel width, ogni pixel ha le dimensioni definite dai parametri di formato e tipo. Pertanto, un formato di GL_RGB con un tipo di GL_UNSIGNED_BYTE genererà un pixel di dimensioni pari a 24 bit. I pixel dovrebbero altrimenti essere imballati, quindi una riga di 16 di questi pixel occuperà 48 byte.

Ogni riga deve essere allineata su un valore specifico, come definito dallo GL_PACK/UNPACK_ALIGNMENT. Ciò significa che il valore aggiunto al puntatore per raggiungere la riga successiva è: align(pixel_size * width, GL_*_ALIGNMENT). Se la dimensione del pixel è 3 byte, la larghezza è 2 e l'allineamento è 1, la dimensione del byte della riga è 6. Se l'allineamento è 4, la dimensione del byte della riga è otto.

Vedere il problema?

I dati di immagine, che possono provenire da alcuni formati di file immagine caricati con un caricatore di immagini, hanno un allineamento di riga. A volte questo è allineato a 1 byte e talvolta lo non è. Le immagini DDS hanno un allineamento specificato come parte del formato. In molti casi, le immagini hanno allineamenti di righe di 4 byte; le dimensioni dei pixel inferiori a 32 bit avranno quindi un riempimento alla fine delle righe con determinate larghezze. Se l'allineamento che hai fornito a OpenGL non corrisponde a quello, otterrai una texture malformata.

È possibile impostare l'allineamento in modo che corrisponda all'allineamento del formato immagine. Se sai o no, puoi assicurarti che l'allineamento delle righe sia sempre 1 (e questo è improbabile a meno che tu non abbia scritto il tuo formato di immagine o il tuo DDS writer), devi impostare l'allineamento delle righe esattamente come viene utilizzato il formato dell'immagine.

+0

Sì, ha senso, non pensavo in termini di righe. Quindi, se riesco a controllare i "lineize/row bytes" (che sono in grado di copiare i dati su un PBO), quale allineamento sarebbe ottimale? C'è un miglioramento delle prestazioni con l'utilizzo dell'allineamento a 8 byte? – ronag

+0

Se ho dati GL_RGB, dovrei convertirlo io stesso a GL_RGBA mentre lo copio sul PBO? – ronag

+2

@ronag: È improbabile che tu possa battere le prestazioni del decompressore, ed è una funzione notoriamente complicata da scrivere usando SIMD. Sembra un sacco di lavoro, che dovrebbe essere giustificato con benchmark che dimostrano che la tua applicazione è limitata dalla velocità di upload * e * che la velocità di caricamento è influenzata negativamente dal decompressore. –

9

Impatterà sulle prestazioni dei moderni gpus?

No, perché le impostazioni del negozio di pixel sono rilevanti solo per il trasferimento di dati da o verso la GPU, ovvero l'allineamento dei dati. Una volta nella memoria della GPU, è allineato in qualsiasi modo desideri dalla GPU e dal guidatore.

+2

Penso che stia chiedendo se una o più GPU richiederebbero alle CPU di apportare alcune modifiche ai dati prima del caricamento. Cioè, se la GPU non può gestire righe allineate a byte. –

+4

Sto chiedendo se e quando potrebbe influire su upload/download di gpu e se ci sono altri aspetti su cui ho bisogno di pensare. – ronag

+2

@ronag: beh, se la GPU non è in grado di gestire il formato dati dei dati originali, il formato dei dati deve essere convertito prima dal driver. Tuttavia, dal momento che caricando i dati delle texture occasionalmente nel complesso, consumerà solo pochissimo tempo di CPU. Tuttavia i trasferimenti di dati non sono ciò che considererei un problema di prestazioni della GPU. Il collo di bottiglia è chiaramente la CPU e il bus dati lì. – datenwolf