È scarto negativo per le prestazioni del programma in OpenGL?

Question

Stavo leggendo this articolo, e l'autore scrive:

Ecco come scrivere applicazioni ad alte prestazioni su ogni piattaforma in due semplici passaggi:
[...]
seguire le migliori pratiche. Nel caso di Android e OpenGL, questo include cose come "batch draw calls", "non usare scarto in frammenti shader" e così via.

Non ho mai sentito dire che lo scarto avrebbe un impatto negativo sulle prestazioni o simili e lo abbiamo utilizzato per evitare la fusione quando non è stato necessario un alfa dettagliato.

Qualcuno potrebbe spiegare perché e quando utilizzare lo scarto potrebbe essere considerato una cattiva pratica e come scartare + approfondimento si confronta con la combinazione alpha +?

Modifica: Dopo aver ricevuto una risposta a questa domanda, ho eseguito alcune verifiche eseguendo il rendering di un gradiente di sfondo con un quadratino di trama.

• Uso GL_DEPTH_TEST e un frammento shader termina con la linea "if( gl_FragColor.a < 0.5){ discard; }" dato circa 32 fps.
• La rimozione dell'istruzione if/discard dallo framment-shader ha aumentato la velocità di rendering di a circa 44 fps.
• Uso GL_BLEND con la funzione blend "(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA)" anziché GL_DEPTH_TEST anche portato a circa 44 fps .

Answer 1

È dipendente dall'hardware. Per l'hardware PowerVR e altre GPU che utilizzano il rendering basato su tile, utilizzando discard significa che il TBR non può più presumere che ogni frammento disegnato diventerà un pixel. Questa ipotesi è importante perché consente al TBR di valutare tutte le profondità prima, quindi valutare solo gli ombreggiatori di frammenti per i frammenti più in alto. Una sorta di approccio di rendering differito, tranne che nell'hardware.

Si noti che si otterrebbe lo stesso problema attivando il test alfa.

Answer 2

"scarto" è negativo per ogni tecnica di accelerazione grafica mainstream - IMR, TBR, TBDR. Questo perché la visibilità di un frammento (e quindi la profondità) è determinabile solo dopo l'elaborazione del frammento e non durante l'HSR di Early-Z o PowerVR (rimozione di superfici nascoste) ecc. Più in basso la pipeline grafica viene rilevata prima della rimozione per indicare il suo effetto su prestazione; in questo caso più elaborazione di frammenti + interruzione dell'elaborazione in profondità di altri poligoni = cattivo effetto

Se è necessario utilizzare lo scarto, assicurarsi che solo il tris che ne ha bisogno sia reso con uno shader che lo contiene e, per minimizzare il suo effetto su prestazioni di rendering complessive, renderizza i tuoi oggetti nell'ordine: opaco, scartato, miscelato.

Per inciso, solo l'hardware PowerVR determina la visibilità nella fase posticipata (quindi è l'unica GPU definita "TBDR"). Altre soluzioni possono essere basate su tile (TBR), ma stanno ancora utilizzando le tecniche Early Z dipendenti dall'ordine di presentazione come fa un IMR. I TBR e i TBDR fanno il blending su chip (più veloce, meno affamato di energia rispetto alla memoria principale), quindi la fusione dovrebbe essere favorita per la trasparenza. La normale procedura per rendere correttamente i poligoni miscelati è disabilitare le scritture di profondità (ma non i test) e renderizzare tris in ordine di profondità back-to-front (a meno che l'operazione di fusione non sia indipendente dall'ordine). Spesso lo smistamento approssimativo è abbastanza buono. La geometria dovrebbe essere tale da evitare ampie aree di frammenti completamente trasparenti. Più di un frammento viene ancora elaborato per pixel in questo modo, ma l'ottimizzazione della profondità HW non viene interrotta come con i frammenti scartati.

Answer 3

L'oggetto A si trova di fronte all'oggetto B. L'oggetto A ha uno shader che utilizza "scarta". Come tale, non posso fare correttamente 'Early-Z' perché ho bisogno di sapere quali sezioni dell'Oggetto B saranno visibili attraverso l'Oggetto A. Ciò significa che l'Oggetto A deve passare attraverso la pipeline di elaborazione fino quasi all'ultimo momento (fino all'elaborazione del frammento) prima di poter determinare se l'oggetto B è effettivamente visibile o meno.

Questo è un problema per HSR e 'Early-Z' poiché gli oggetti potenzialmente occlusi devono sedersi e attendere che le informazioni sulla profondità vengano aggiornate prima che possano essere elaborate. Come detto sopra, è un male per tutti, o, in un modo un po 'più amichevole, "Amici non permettete agli amici di usare Scarta".

Answer 4

Inoltre, la semplice istruzione "if" nel framment shader può causare un grosso rallentamento su alcuni componenti hardware. (In particolare, le GPU pesantemente pipeline, o che eseguono istruzioni singole/dati multipli, avranno grosse penalizzazioni in termini di prestazioni dalle dichiarazioni del ramo.) Quindi i risultati del test potrebbero essere una combinazione dell'istruzione "se" e degli effetti menzionati da altri.

(Per quel che vale, il test sul mio Galaxy Nexus ha mostrato un'enorme accelerazione quando sono passato all'analisi di profondità dei miei oggetti semitrasparenti e li ho riportati in primo piano, invece di eseguire il rendering in ordine casuale e scartare i frammenti nello shader.)