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

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

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

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

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

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

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

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

Ответ 1

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

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

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

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

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

Ответ 2

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

Ответ 3

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

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