it-swarm-eu.dev

C'era una volta, quando> era più veloce di <... Aspetta, cosa?

Sto leggendo un fantastico tutorial OpenGL . È davvero fantastico, credimi. L'argomento al quale sono attualmente è Z-buffer. Oltre a spiegare di cosa si tratta, l'autore afferma che possiamo eseguire test di profondità personalizzati, come GL_LESS, GL_ALWAYS, ecc. Inoltre, spiega che il vero significato dei valori di profondità (che è superiore e che non lo è) può anche essere personalizzato. Capisco finora. E poi l'autore dice qualcosa di incredibile:

L'intervallo zNear può essere maggiore dell'intervallo zFar; se lo è, allora il i valori dello spazio della finestra saranno invertiti, in termini di ciò che costituisce più vicino o più lontano dallo spettatore.

In precedenza, si è detto che il valore Z dello spazio finestra di 0 è il più vicino e 1 è il più lontano. Tuttavia, se i valori Z dello spazio clip sono stati annullati, il la profondità di 1 sarebbe la più vicina alla vista e la profondità di 0 sarebbe più lontano. Tuttavia, se invertiamo la direzione del test di profondità (da GL_LESS a GL_GREATER, ecc.), Otteniamo lo stesso risultato esatto. Quindi è davvero solo un convenzione. Infatti, lanciando il segno di Z e il test di profondità è stata una volta Un ottimizzazione delle prestazioni vitale per molti giochi.

Se ho capito bene, per quanto riguarda le prestazioni, lanciando il segno di Z e il test di profondità non è altro che modificare un confronto < con un confronto >. Quindi, se ho capito bene e l'autore non sta mentendo o inventando qualcosa, la modifica di < a > è stata un'ottimizzazione vitale per molti giochi.

L'autore sta inventando qualcosa, sto fraintendendo qualcosa, o è vero che una volta < è stato più lento (vitalmente, come dice l'autore) di >?

Grazie per aver chiarito questa cosa piuttosto curiosa!

Dichiarazione di non responsabilità: sono pienamente consapevole che la complessità dell'algoritmo è la fonte primaria per le ottimizzazioni. Inoltre, sospetto che oggigiorno sicuramente non farebbe alcuna differenza e non sto chiedendo questo per ottimizzare nulla. Sono solo estremamente, dolorosamente, forse proibitivamente curioso.

270
Armen Tsirunyan

Se ho capito bene, per quanto riguarda le prestazioni, lanciando il segno di Z e il test di profondità non è altro che modificare un confronto <confronto con a>. Quindi, se ho capito bene e l'autore non sta mentendo o inventando qualcosa, allora il <to> di solito è stato un'ottimizzazione vitale per molti giochi.

Non l'ho spiegato particolarmente bene, perché non era importante. Ho solo sentito che era un po 'interessante da aggiungere. Non avevo intenzione di esaminare l'algoritmo in modo specifico.

Tuttavia, il contesto è la chiave. Non ho mai detto che un confronto <è stato più veloce di un> confronto. Ricorda: stiamo parlando di test di profondità dell'hardware grafico, non della tua CPU. Non operator<.

Quello a cui mi riferivo era una specifica vecchia ottimizzazione in cui un frame si usava GL_LESS con un intervallo di [0, 0,5]. Fotogramma successivo, esegui il rendering con GL_GREATER con un intervallo di [1.0, 0.5]. Tu vai avanti e indietro, letteralmente "lanciando il segno di Z e il test di profondità" ogni fotogramma.

Questo perde un po 'di precisione in profondità, ma non è stato necessario cancellare il buffer di profondità, che una volta era un'operazione piuttosto lenta. Dal momento che la pulizia di profondità non è solo gratuita in questi giorni, ma in realtà più veloce di questa tecnica, le persone non lo fanno più.

337
Nicol Bolas

La risposta è quasi certamente che per qualsiasi incarnazione del chip + driver è stata utilizzata, la Zierarchica Z ha funzionato solo nell'unica direzione - questo era un problema abbastanza comune nel corso della giornata. Assemblaggio/ramificazione di basso livello non ha nulla a che fare con esso: il buffering Z viene eseguito in hardware con funzioni fisse ed è pipeline - non ci sono speculazioni e quindi nessuna previsione di branch.

3
Crowley9

Un'ottimizzazione del genere danneggerà le prestazioni su molte soluzioni grafiche incorporate perché renderà la risoluzione dei framebuffer meno efficiente. La cancellazione di un buffer è un chiaro segnale al driver che non è necessario memorizzare e ripristinare il buffer durante il binning. 

Piccole informazioni di base: un rasterizzatore di piastrellatura/binatura elabora lo schermo in numero di tessere molto piccole che si adattano alla memoria on-chip. Ciò riduce le scritture e le letture nella memoria esterna che riduce il traffico sul bus di memoria. Quando un frame è completo (lo swap è chiamato, o i FIFO sono scaricati perché sono pieni, i binding del framebuffer cambiano, ecc.) Il framebuffer deve essere risolto; questo significa che ogni cestino viene elaborato a turno. 

Il driver deve presupporre che i contenuti precedenti devono essere conservati. La conservazione significa che il raccoglitore deve essere scritto nella memoria esterna e successivamente ripristinato dalla memoria esterna quando il raccoglitore viene elaborato di nuovo. L'operazione chiara indica al guidatore che il contenuto del cestino è ben definito: il colore chiaro. Questa è una situazione che è banale da ottimizzare. Ci sono anche estensioni per "scartare" il contenuto del buffer. 

0
t0rakka