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

Sto leggendo un fantastico tutorial su OpenGL . È davvero fantastico, fidati di me. L'argomento in cui mi trovo attualmente è Z-buffer. Oltre a spiegare di cosa si tratta, l'autore menziona che possiamo eseguire test di profondità personalizzati, come GL_LESS, GL_ALWAYS, ecc. Spiega anche che il significato effettivo dei valori di profondità (che è in alto e che non lo è) può anche essere personalizzato. Ho capito fino ad ora. E poi l'autore dice qualcosa di incredibile:

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

In precedenza, si diceva che il valore Z dello spazio finestra di 0 fosse il più vicino e 1 fosse il più lontano. Tuttavia, se i nostri valori Z dello spazio clip fossero negati, la profondità di 1 sarebbe la più vicina alla vista e la profondità di 0 sarebbe la più lontana. Tuttavia, se invertiamo la direzione del test di profondità (da GL_LESS a GL_GREATER, ecc.), Otteniamo lo stesso risultato esatto. Quindi è davvero solo una convention. In effetti, capovolgere il segno di Z e il test di profondità era una volta un'ottimizzazione delle prestazioni vitale per molti giochi.

Se ho capito bene, dal punto di vista delle prestazioni, capovolgere il segno di Z e il test di profondità non è altro che cambiare un <confronto in un >confronto. Quindi, se ho capito bene e l'autore non sta mentendo o fare le cose, quindi modificando <ad >usato per essere un'ottimizzazione di vitale importanza per molti giochi.

L'autore sta inventando le cose, sto fraintendendo qualcosa o è davvero il caso che una volta <fosse più lento ( vitale , come dice l'autore) di >?

Grazie per aver chiarito questa questione piuttosto curiosa!

_{Dichiarazione di non responsabilità: sono pienamente consapevole che la complessità dell'algoritmo è la fonte primaria di 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.}

Se ho capito bene, dal punto di vista delle prestazioni, capovolgere il segno di Z e il test di profondità non è altro che cambiare un confronto tra <confronto con>. Quindi, se capisco correttamente e l'autore non sta mentendo o inventando cose, cambiare <in> era un'ottimizzazione vitale per molti giochi.

Non l'ho spiegato particolarmente bene, perché non era importante. Ho solo pensato che fosse un po 'di curiosità interessante da aggiungere. Non intendevo approfondire l'algoritmo in modo specifico.

Tuttavia, il contesto è la chiave. Non ho mai detto che un <confronto fosse 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 vecchia ottimizzazione specifica in cui un fotogramma da utilizzare GL_LESScon un intervallo di [0, 0,5]. Il fotogramma successivo, si esegue il rendering con GL_GREATERun intervallo di [1,0, 0,5]. Vai avanti e indietro, letteralmente "capovolgendo il segno di Z e il test di profondità" ogni fotogramma.

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

La risposta è quasi certamente che per qualunque incarnazione di chip + driver sia stata usata, la Hierarchical Z ha funzionato solo in una direzione - questo era un problema abbastanza comune nel passato. L'assemblaggio / ramificazione di basso livello non ha nulla a che fare con esso - il buffering Z viene eseguito nell'hardware a funzione fissa ed è pipeline - non vi è alcuna speculazione e quindi nessuna previsione di diramazione.

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

Poche informazioni di base: un rasterizzatore di piastrellatura / binning elabora lo schermo in un numero di tessere molto piccole che si adattano alla memoria su chip. Ciò riduce le scritture e le letture su memoria esterna, riducendo il traffico sul bus di memoria. Quando un frame è completo (lo swap viene chiamato, oppure i FIFO vengono scaricati perché sono pieni, i collegamenti del framebuffer cambiano, ecc.) Il framebuffer deve essere risolto; questo significa che ogni cestino viene elaborato a sua volta.

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

Ha a che fare con bit di flag in assembly altamente ottimizzati.

x86 ha entrambe le istruzioni jl e jg, ma la maggior parte dei processori RISC ha solo jl e jz (no jg).