Atlante delle trame e matrice delle trame: in che modo vengono gestiti da CPU e GPU e in che modo ciò influisce sulle prestazioni?

Unity 5.4 (attualmente in versione beta) porterà una funzionalità molto attesa (dal 2013), ovvero le trame array - nello stesso vano di ArrayTexture di OpenGL . Tuttavia, dopo aver letto alcune matrici di trame e atlanti di trama, non riesco ancora a capire le differenze tecniche sul loro utilizzo da parte di CPU e GPU.

Quindi, per essere più specifici, vorrei chiedere una spiegazione sulle principali differenze tra il modo in cui atlante delle trame e array di trame sono gestiti da CPU e GPU e, soprattutto, come tali differenze possono influire sulle prestazioni e sulla gestione della memoria (ad es. come gli array di texture possono essere più performanti degli atlanti di texture, ecc.).

Se i dettagli tecnici sull'implementazione di Unity mancano a causa della sua sfortunata sourceness chiuso, sarei abbastanza felice con una risposta su OpenGL.s ArrayTexture.

textures rendering texture-atlas

— ASteer
fonte

Non mi sorprende che tu non abbia trovato un confronto tecnico, poiché entrambi dipendono dall'implementazione (più per gli array).

— Wondra,

Avrai difficoltà a ottenere informazioni su come funzionano gli interni del motore Unity, in quanto è una scatola nera chiusa. L'unica cosa che puoi fare è profilare ogni caso e confrontarti sull'utilizzo della cpu e della gpu. Per capire come funziona, richiederebbe l'intervento di un ingegnere Unity o l'apertura o la fuoriuscita del codice sorgente.

— jgallant,

@Jon Abbastanza giusto, ma in realtà ero più interessato a una risposta agnostica al motore. Se varia così tanto, posso aggiornare la domanda per parlare, ad esempio, di ArrayTexture di OpenGL: opengl.org/wiki/Array_Texture

— ASteer,

Come notato nei commenti sopra, le prestazioni dipenderanno dall'implementazione, dal tuo hardware particolare e da cosa stai cercando di fare con le trame, quindi l'unica risposta affidabile è quella di profilare ogni alternativa.

Ci sono alcune differenze in termini di utilizzo di ciascuna opzione, che si applicheranno in modo coerente:

Una grande differenza è che, per le trame degli array, ogni trama viene trattata separatamente per scopi come avvolgere le coordinate della trama o il mipmapping.

Ciò evita problemi comuni con atlanti di texture in cui è necessario aggiungere un'imbottitura tra i campioni di texture adiacenti per evitare che i campioni ai loro bordi sanguinino insieme, specialmente a livelli di mip più profondi.

Questo significa anche che se vuoi che le tue trame vengano affiancate, puoi usare l'hardware di campionamento delle trame per farlo proprio come con una trama vaniglia. Con gli atlanti, di solito dobbiamo fare la matematica di piastrellatura nel nostro shader di frammenti, poiché il campionatore avvolge solo coordinate / specchi / morsetti / bordi delle coordinate dell'intero atlante, non singole piastrelle al suo interno.

La principale restrizione con le trame array è che richiedono che tutte le trame costituenti abbiano la stessa risoluzione e il numero di livelli mip. Se stai cercando di raggruppare le trame con esigenze di risoluzione molto diverse (ad esempio, archiviando le tessere del terreno il cui LoD cade a distanza in una trama virtuale ), potresti invece desiderare la flessibilità di un atlante.

— DMGregory
fonte

Grazie, era esattamente quello che stavo cercando. Voglio dire, non una risposta su quale sia più veloce e meno dispendiosa in termini di memoria, poiché ovviamente dipendono dall'implementazione. Tuttavia, ero sicuro che alcuni suggerimenti sul funzionamento di ciascun caso potessero essere utili per comprendere i loro soliti scenari migliori e peggiori. La tua risposta mi ha davvero aiutato in questo.

— ASteer,

Un altro svantaggio delle trame dell'array: sono limitate da GL_MAX_ARRAY_TEXTURE_LAYERS. Sulla mia GPU semi-moderna, questo è il 2048, quindi se vuoi tonnellate di piccole trame, questo limite potrebbe essere troppo basso.

— jwd