Dawno, dawno temu, kiedy> było szybsze niż <… Zaraz, co?

Czytam niesamowity samouczek OpenGL . To naprawdę świetne, zaufaj mi. Tematem, w którym aktualnie jestem, jest bufor Z. Oprócz wyjaśnienia, o co w tym wszystkim chodzi, autor wspomina, że ​​możemy wykonywać niestandardowe testy głębokości, takie jak GL_LESS, GL_ALWAYS itp. Wyjaśnia również, że rzeczywiste znaczenie wartości głębokości (która jest najwyższa, a która nie) może być również dostosowane Jak dotąd rozumiem A potem autor mówi coś niewiarygodnego:

Zakres zNear może być większy niż zakres zFar; jeśli tak, to wartości przestrzeni okien będą odwrócone, jeśli chodzi o to, co stanowi najbliżej lub dalej od widza.

Wcześniej mówiono, że wartość Z w obszarze okien wynosząca 0 jest najbliższa, a 1 jest najdalsza. Jeśli jednak nasze wartości Z w przestrzeni klipu zostałyby zanegowane, głębokość 1 byłaby najbliższa widokowi, a głębokość 0 byłaby najdalsza. Jeśli jednak zmienimy kierunek testu głębokości (GL_LESS na GL_GREATER itp.), Otrzymamy dokładnie ten sam wynik. To naprawdę tylko konwencja. Rzeczywiście, odwrócenie znaku Z i test głębokości był kiedyś istotną optymalizacją wydajności dla wielu gier.

Jeśli dobrze rozumiem, pod względem wydajności odwrócenie znaku Z i test głębokości to nic innego jak zmiana <porównania na >porównanie. Tak więc, jeśli dobrze rozumiem, a autor nie kłamie ani nie wymyśla, to zmiana <na >dawną była niezbędną optymalizacją wielu gier.

Czy autor czyni rzeczy, mam nieporozumienie coś, czy to rzeczywiście jest tak, że raz <był wolniejszy ( niezwykle , jak mówi autor) niż >?

Dziękujemy za wyjaśnienie tej dość ciekawej sprawy!

_{Oświadczenie: Jestem w pełni świadomy, że złożoność algorytmu jest głównym źródłem optymalizacji. Co więcej, podejrzewam, że w dzisiejszych czasach zdecydowanie nie zrobiłoby to żadnej różnicy i nie proszę o to, aby cokolwiek zoptymalizować. Jestem po prostu bardzo, boleśnie, może zbyt ciekawie ciekawy.}

Jeśli dobrze rozumiem, pod względem wydajności odwrócenie znaku Z i test głębokości to nic innego jak zmiana porównania <porównanie do>. Tak więc, jeśli dobrze rozumiem, a autor nie kłamie ani nie wymyśla, to zmiana <na> była kiedyś istotną optymalizacją wielu gier.

Nie wyjaśniłem tego szczególnie dobrze, ponieważ nie było to ważne. Po prostu czułem, że można dodać ciekawą ciekawostkę. Nie zamierzałem szczegółowo omawiać algorytmu.

Kontekst jest jednak kluczowy. Nigdy nie mówiłem, że <porównanie było szybsze niż> porównanie. Pamiętaj: mówimy o testach głębi sprzętu graficznego, a nie o procesorze. Nie operator<.

Miałem na myśli konkretną starą optymalizację, w której jedna ramka byłaby używana GL_LESSz zakresem [0, 0,5]. Następna klatka renderuje GL_GREATERw zakresie [1,0, 0,5]. Poruszasz się tam iz powrotem dosłownie „przerzucając znak Z i test głębokości” w każdej klatce.

Traci to odrobinę precyzji głębokości, ale nie trzeba było czyścić bufora głębokości, co kiedyś było dość powolną operacją. Ponieważ czyszczenie głębokości jest obecnie nie tylko bezpłatne, ale w rzeczywistości szybsze niż ta technika, ludzie już tego nie robią.

Odpowiedź jest prawie na pewno taka, że ​​niezależnie od zastosowanego wcielenia sterownika + chip, Hierarchical Z działał tylko w jednym kierunku - był to dość powszechny problem w tamtych czasach. Asemblowanie / rozgałęzienie niskiego poziomu nie ma z tym nic wspólnego - buforowanie Z odbywa się w sprzęcie o stałej funkcji i jest przetwarzane potokowo - nie ma spekulacji, a zatem nie ma przewidywania rozgałęzień.

Taka optymalizacja obniży wydajność wielu osadzonych rozwiązań graficznych, ponieważ sprawi, że buforowanie ramek będzie mniej wydajne. Wyczyszczenie bufora jest wyraźnym sygnałem dla sterownika, że ​​nie musi on przechowywać i przywracać bufora podczas binowania.

Niewielka ilość informacji w tle: rasterizer kafelków / binowania przetwarza ekran na wiele bardzo małych kafelków, które mieszczą się w pamięci na chipie. Zmniejsza to zapis i odczyt do pamięci zewnętrznej, co zmniejsza ruch na szynie pamięci. Kiedy ramka jest kompletna (wywoływana jest zamiana lub FIFO są opróżniane, ponieważ są pełne, wiązania wiązania ramki zmieniają się itp.) Bufor ramki musi zostać rozwiązany; oznacza to, że każdy pojemnik jest przetwarzany po kolei.

Sterownik musi założyć, że poprzednia zawartość musi zostać zachowana. Zachowanie oznacza, że ​​pojemnik musi zostać zapisany w pamięci zewnętrznej, a następnie przywrócony z pamięci zewnętrznej, gdy pojemnik zostanie ponownie przetworzony. Operacja czyszczenia informuje kierowcę, że zawartość pojemnika jest dobrze zdefiniowana: czysty kolor. Jest to sytuacja trywialna do optymalizacji. Istnieją również rozszerzenia do „odrzucania” zawartości bufora.

Ma to związek z bitami flagowymi w wysoce zestrojonym zestawie.

x86 ma instrukcje jl i jg, ale większość procesorów RISC ma tylko jl i jz (bez jg).