Колись, коли> було швидше, ніж <... Зачекайте, що?

Я читаю дивовижний підручник з OpenGL . Це дійсно чудово, повірте мені. Тема, в якій я зараз перебуваю, - Z-буфер. Окрім пояснення того, про що йдеться, автор зазначає, що ми можемо виконувати спеціальні глибинні тести, такі як GL_LESS, GL_ALWAYS тощо. Він також пояснює, що власне значення значень глибини (яка є найвищою, а яка - ні) також може бути налаштовані. Я розумію поки що. І тоді автор говорить щось неймовірне:

Діапазон zNear може бути більшим, ніж діапазон zFar; якщо вона є, то значення віконного простору будуть перетворені в залежності від того, що є найбільш близьким або віддаленим від глядача.

Раніше говорилося, що значення Z-вікна-простору 0 є найближчим, а 1 - найдальшим. Однак, якщо наші значення Z-простору для кліпу були заперечені, глибина 1 була б найближчою до виду, а глибина 0 - найдальшою. Тим не менш, якщо ми перевернемо напрямок тесту на глибину (GL_LESS до GL_GREATER тощо), ми отримаємо точно такий же результат. Так що це справді просто умовність. Дійсно, перегортання знака Z і глибинний тест колись були життєво важливою оптимізацією продуктивності для багатьох ігор.

Якщо я правильно розумію, продуманий показник Z і глибинний тест - це не що інше, як зміна <порівняння на >порівняння. Отже, якщо я правильно розумію, і автор не бреше і не вигадує речі, то перехід <до >звичного є важливою оптимізацією для багатьох ігор.

Чи автор вигадує, чи я щось не розумію, чи справді це було колись <повільніше ( життєво , як каже автор), ніж >?

Дякуємо, що роз’яснили цю досить цікаву справу!

_{Відмова: Я повністю усвідомлюю, що складність алгоритму є основним джерелом для оптимізацій. Крім того, я підозрюю, що нині це однозначно не має ніякого значення, і я не прошу цього нічого оптимізувати. Мені просто надзвичайно, болісно, ​​можливо, надзвичайно цікаво.}

Якщо я правильно розумію, продуманий показник Z і глибинний тест - це не що інше, як зміна <порівняння на> порівняння. Отже, якщо я правильно розумію, і автор не бреше і не вигадує речі, то зміна <на> використовувалась як важлива оптимізація для багатьох ігор.

Я не особливо добре це пояснив, бо це не було важливо. Я просто відчув, що цікавий трішечки додати. Я не збирався конкретно переглядати алгоритм.

Однак контекст є ключовим. Я ніколи не говорив, що <порівняння було швидше, ніж> порівняння. Пам'ятайте: ми говоримо про тестування глибини графічного обладнання, а не про ваш процесор. Ні operator<.

Я мав на увазі стару специфічну оптимізацію, коли ви використовували б один кадр GL_LESSіз діапазоном [0, 0,5]. Наступний кадр ви надаєте з GL_GREATERдіапазоном [1,0, 0,5]. Ви їдете туди-сюди, буквально "перевертаючи знак Z і перевіряючи глибину" кожен кадр.

При цьому втрачається одна точність глибини, але вам не доведеться очищати буфер глибини, що колись було досить повільною роботою. Оскільки очищення глибини в наші дні не тільки безкоштовне, але насправді швидше, ніж ця методика, люди вже не роблять цього.

Майже напевно відповідь, що для будь-якого втілення драйвера чіпа + ієрархічний Z працював лише в одному напрямку - це було досить поширеною проблемою в той час. Збірка / розгалуження на низькому рівні не має нічого спільного - Z-буферизація проводиться в апаратному забезпеченні з фіксованою функцією та конвеєрним шляхом - немає спекуляцій, а отже, і не передбачено гілок.

Така оптимізація призведе до погіршення продуктивності багатьох вбудованих графічних рішень, оскільки це дозволить зробити вирішення кадру менш ефективним. Очищення буфера - це ясний сигнал драйверу, що він не потребує зберігання та відновлення буфера під час бінінгу.

Невелика довідкова інформація: розповсюджувач / розпорошений растеризатор обробляє екран кількома дуже маленькими плитками, які вписуються в оперативну пам'ять. Це зменшує запис і зчитування у зовнішній пам'яті, що зменшує трафік на шині пам'яті. Коли кадр завершений (викликається своп або FIFO змиваються через те, що вони заповнені, прив'язки кадрів буфера змінюються тощо), рамбуфер повинен бути вирішений; це означає, що кожен контейнер обробляється по черзі.

Водій повинен припустити, що попередній вміст повинен бути збережений. Збереження означає, що контейнер повинен бути записаний у зовнішню пам'ять і пізніше відновлений із зовнішньої пам'яті, коли бін знову буде оброблений. Чітка операція повідомляє драйверу, що вміст відрізка чітко визначений: прозорий колір. Це ситуація, яка є тривіальною для оптимізації. Також є розширення для "відкидання" вмісту буфера.

Це пов'язано з бітами прапора в сильно налаштованій збірці.

x86 має як jl, так і jg інструкції, але більшість процесорів RISC мають лише jl та jz (без jg).