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

Question

Я читаю потрясающий учебник OpenGL .Это действительно здорово, поверь мне.Тема, которой я сейчас занимаюсь, - это Z-буфер.Помимо объяснения, что это такое, автор упоминает, что мы можем выполнять пользовательские тесты глубины, такие как GL_LESS, GL_ALWAYS и т. Д. Он также объясняет, что фактическое значение значений глубины (которое является верхним, а что нет) также может бытьнастроены.Я так понимаю, до сих пор.И тогда автор говорит что-то невероятное:

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

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

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

Автор придумывает, я что-то неправильно понимаю, или это действительно так, что когда-то < был медленнее ( жизненно , как говорит автор), чем >?

Спасибо за разъяснение этого довольно любопытного вопроса!

_{Отказ от ответственности: я полностью осознаю, что сложность алгоритма является основным источником для оптимизации.Кроме того, я подозреваю, что в настоящее время это определенно не будет иметь никакого значения, и я не прошу это оптимизировать что-либо.Мне просто чрезвычайно, больно, может быть, чрезмерно любопытно.}

Answer 1

Если я правильно понимаю, с точки зрения производительности переключение знака Z и проверка глубины - не что иное, как изменение сравнения <сравнение с>. Поэтому, если я правильно понимаю, и автор не лжет и не выдумывает, то изменение <на> раньше было жизненно важной оптимизацией для многих игр.

Я не очень хорошо это объяснил, потому что это было неважно. Я просто почувствовал, что это была интересная мелочь, чтобы добавить. Я не собирался специально рассматривать алгоритм.

Тем не менее, контекст является ключевым. Я никогда не говорил, что <сравнение было быстрее, чем> сравнение. Помните: мы говорим о тестах глубины графического оборудования, а не о вашем процессоре. Не operator<.

Я имел в виду конкретную старую оптимизацию, где один кадр вы бы использовали GL_LESS с диапазоном [0, 0,5]. Следующий кадр вы визуализируете с помощью GL_GREATER с диапазоном [1.0, 0.5]. Вы идете взад-вперед, буквально «переворачивая знак Z и проверяя глубину» каждого кадра.

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

Answer 2

Ответ почти наверняка состоит в том, что для любого воплощения чипа + драйвера Hierarchical Z работал только в одном направлении - это было довольно распространенной проблемой в те времена. Низкоуровневая сборка / ветвление не имеет к этому никакого отношения - Z-буферизация выполняется в аппаратных средствах с фиксированной функцией и конвейерна - нет спекуляций и, следовательно, нет прогноза ветвления.

Answer 3

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

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

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

Answer 4

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

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