Diciamo che voglio rendere un quadrato; la sua trama è "square.png".
Il rendering del computer è più semplice se la trama è solo di un colore normale?
E che dire se è molto rumoroso trama con colori completamente casuali qua e là?
O cosa succede se quella trama è rumorosa nel senso che ogni pixel in essa è diverso l'uno dall'altro, ma solo di un po '?
Risposte:
Come la maggior parte delle cose nello sviluppo del gioco, e specialmente nella grafica del gioco, la risposta è "dipende"
La risoluzione della trama può avere un impatto sulla velocità di rendering. Maggiore è il numero di pixel che contiene, maggiore è il numero di dati non elaborati da caricare sulla GPU e minore è la trama che possiamo inserire nella cache alla volta, quindi lo shader potrebbe fare più pause mentre attende la parte giusta della trama per essere trascinato nella cache.
L'uso del mipmapping può ridurre l'impatto di questo. Con le mipmap, memorizziamo una catena di versioni ridotte della trama, che all'inizio suona come ancora più memoria per schivare. Ma ci permette di leggere dalle versioni più piccole quando la trama viene visualizzata su una piccola dimensione sullo schermo (come un oggetto distante in prospettiva), quindi i nostri campioni fanno un uso migliore della cache delle trame, piuttosto che saltare dappertutto. Ciò riduce anche l'aliasing.
Il contenuto delle trame non ha alcun impatto sul rendimento dell'efficienza per la maggior parte del tempo.
Un colore è solo un mucchio di numeri per quanto riguarda la GPU, quindi non importa molto quali siano quei numeri, ma li incanala attraverso la sua matematica allo stesso modo. Non fa nulla di speciale come ricordare "Oh, ho già visto un pixel in questo verde prima, riuserò semplicemente lo stesso output che ho calcolato l'ultima volta che ho visto questo input", quindi se la tua texture è tutta di un colore o scintillii casuali, la tua GPU sta facendo lo stesso lavoro.
A differenza dei formati come PNG e JPG, che si comprimono in modo più efficiente in aree prevedibili dell'immagine e consumano più bit in regioni complesse, i formati di trama GPU come BTC, ETC, PVRTC o persino RGBA grezzo utilizzano un numero fisso di bit per blocco di pixel. Quindi rendere la tua trama più o meno dettagliata mantenendo lo stesso formato di compressione non cambierà la sua dimensione dei dati o influenzerà il trasferimento dei dati e l'efficienza relativa alla cache.
Ma se usi un particolare tipo di dettaglio che la tua compressione precedente non conserva bene, potresti essere costretto a cambiare l'intera immagine per usare un formato diverso, che potrebbe cambiare di nuovo la sua dimensione dei dati.
Ecco l'asterisco più grande della situazione: potresti usare questo input di colore per prendere decisioni, come un if()ramo. Qui, i dettagli contano per la velocità.
Le unità di shading GPU funzionano su blocchi di pixel in batch, eseguendo le stesse istruzioni in parallelo su più flussi di dati. Quindi quando alcuni pixel nel blocco prendono un ramo ifdell'altro pixel e l'altro prende l'altro, l'intero batch deve passare attraverso entrambi i rami (mascherando i risultati che non si applicano a un set di pixel o all'altro)
Se l'input cambia in modo uniforme / prevedibile, probabilmente avrai molti blocchi che devono solo prendere un singolo ramo e questi casi di entrambi i rami saranno limitati a bande strette attorno al bordo di transizione. Ma se il tuo input è casuale, ci aspetteremmo che molti blocchi prendano entrambi i rami e rallentino il rendering.
Questo può accadere anche se stai usando una trama per controllare le ricerche in una seconda trama, come una distorsione o una mappa indice. Se la prima trama salta casualmente, campioneremo da punti sparsi e casuali della seconda trama, facendo un uso meno coerente della nostra cache delle trame e aspettando più a lungo per ottenere i dati di cui abbiamo bisogno, in media.
Quindi, nel complesso: no, il contenuto della trama non ha molto impatto sulla velocità di rendering, ad eccezione dei casi in cui lo fa. ;)
nth pixel, dovresti passare attraverso ogni singolo pixel prima di esso. Con una larghezza in pixel di byte costante, è solo start_of_buffer + width * n, che è molto più veloce, soprattutto per le grandi n.
Insieme a DMGregory's all'eccellente risposta di sopra, c'è forse un caso in cui la complessità di una "trama" può influire sulle prestazioni di rendering ed è qui che i risultati di un rendering precedente sono usati come sorgente in una successiva, ad esempio mappe d'ombra / riflessioni / mappe ambientali.
Alcuni hardware moderni possono applicare una compressione senza perdita di dati a questi buffer: ad esempio PowerVR ha PVRIC , AMD, Delta Color Compression e ARM ha qualcosa di simile. Lo scopo di queste tecniche di compressione è ridurre la larghezza di banda complessiva che, a sua volta, può migliorare le prestazioni di rendering.
Più i dati sono semplici, siano essi profondità o colore (intero o virgola mobile), meglio funzioneranno questi schemi. Naturalmente, non suggerirei di semplificare deliberatamente l'output di rendering solo per farli funzionare meglio, ma evitare l'utilizzo di dati rumorosi potrebbe aiutare in alcune circostanze.
Inoltre, fare un campionamento sparso dei buffer di frame / profondità che usano questi schemi, nel vano tentativo di ridurre la larghezza di banda, non aiuterà perché sono molto probabilmente basati su blocchi.
Inoltre potresti trovare queste due domande SE Computer Graphics e le risposte di interesse: