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

245

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

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

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

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

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

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

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

  • 81
    Мне просто чрезвычайно, больно, может быть, слишком любопытно. - Ну и дела, вы говорите, как будто это было плохо :)
  • 6
    Ссылка на этот урок, кажется, (недавно) исчезла. :(
Показать ещё 5 комментариев
Теги:
optimization
opengl
gpu
cpu

3 ответа

326
Лучший ответ

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

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

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

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

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

  • 126
    Ага! Так что это я должен поблагодарить вас за замечательные уроки? :) Ну, пожалуйста, примите мои самые искренние поздравления с лучшей онлайн-книгой opengl! И большое спасибо за разъяснение этого, теперь я понимаю. Собираетесь ли вы продолжать больше уроков по турориалу? :)
  • 36
    Это прямо здесь ТАК. Фантастика.
Показать ещё 5 комментариев
2

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

-7

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

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

  • 0
    Это существенно повышает производительность?
  • 0
    @ Армен: это зависит от того, как часто используется звонок, не так ли?
Показать ещё 15 комментариев

Ещё вопросы

Сообщество Overcoder
Наверх
Меню