Когда-то, когда> был быстрее, чем <… Подожди, что?

Я читаю потрясающий учебник 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-буферизация выполняется на оборудовании с фиксированной функцией и конвейерной - нет спекуляций и, следовательно, прогнозирования ветвлений.

Подобная оптимизация снизит производительность во многих встроенных графических решениях, потому что это сделает разрешение кадрового буфера менее эффективным. Очистка буфера является четким сигналом для драйвера о том, что ему не нужно хранить и восстанавливать буфер при биннинге.

Немного справочной информации: растеризатор мозаики / биннинга обрабатывает экран в виде множества очень маленьких плиток, которые помещаются во встроенную память. Это уменьшает записи и чтения во внешнюю память, что уменьшает трафик на шине памяти. Когда кадр завершен (вызывается swap, или FIFO сбрасываются, потому что они заполнены, привязки кадрового буфера изменяются и т. Д.), Кадровый буфер должен быть разрешен; это означает, что каждая корзина обрабатывается по очереди.

Драйвер должен предположить, что предыдущее содержимое должно быть сохранено. Сохранение означает, что корзина должна быть записана во внешнюю память, а затем восстановлена ​​из внешней памяти при повторной обработке корзины. Операция очистки сообщает водителю, что содержимое корзины четко определено: чистый цвет. Это ситуация, которую тривиально оптимизировать. Существуют также расширения для «отбрасывания» содержимого буфера.

Это связано с битами флагов в сильно настроенной сборке.

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