Вредно ли сбрасывать производительность программы в OpenGL? - PullRequest
21 голосов
/ 14 декабря 2011

Я читал эту статью, а автор пишет:

Вот как написать высокопроизводительные приложения на каждой платформе в два простых шага:
[...]
Следуйте лучшим практикам. В случае Android и OpenGL это включает в себя такие вещи, как «вызовы пакетной отрисовки», «не использовать сброс в фрагментных шейдерах» и так далее.

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

Может ли кто-нибудь объяснить, почему и когда использование discard может считаться плохой практикой, и как discard + deeptest сравнивается с alpha + blend?

Редактировать: Получив ответ на этот вопрос, я провел некоторое тестирование, отрисовав фоновый градиент с текстурированным квадратом поверх этого.

  • Использование GL_DEPTH_TEST и фрагмент-шейдера, заканчивающегося строкой "if( gl_FragColor.a < 0.5 ){ discard; }", дало около 32 кадров в секунду .
  • Увеличено удаление оператора if / discard из фрагментного шейдера скорость рендеринга примерно до 44 кадров в секунду .
  • Использование GL_BLEND с функцией наложения "(GL_SRC_ALPHA, GL_ONE_MINUS_SRC_ALPHA) "вместо GL_DEPTH_TEST также получилось около 44 кадров в секунду .

Ответы [ 4 ]

20 голосов
/ 27 января 2012

«отбрасывать» плохо для любой основной техники ускорения графики - IMR, TBR, TBDR.Это связано с тем, что видимость фрагмента (и, следовательно, глубины) определяется только после обработки фрагмента, а не во время HSR в раннем Z или PowerVR (удаление скрытой поверхности) и т. Д. Чем дальше находится графический конвейер, тем дальше происходит удаление, что указывает на его влияние наспектакль;в этом случае больше обработки фрагментов + нарушение глубины обработки других полигонов = плохой эффект

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

Кстати, только аппаратное обеспечение PowerVR определяет видимость на этапе отложенного выполнения (следовательно, это единственный графический процессор, называемый «TBDR»).Другие решения могут быть основаны на мозаичном элементе (TBR), но все еще используют методы раннего Z, зависящие от порядка отправки, как это делает IMR.TBR и TBDR делают смешивание на кристалле (быстрее, менее энергоемким, чем при переходе в основную память), поэтому смешивание должно быть предпочтительным для прозрачности.Обычная процедура для правильного рендеринга смешанных полигонов состоит в том, чтобы отключить глубинные записи (но не тесты) и рендерить трис в обратном порядке в глубину (если операция смешивания не зависит от порядка).Часто приблизительная сортировка достаточно хороша.Геометрия должна быть такой, чтобы избежать больших областей полностью прозрачных фрагментов.Таким образом, по-прежнему обрабатывается более одного фрагмента на пиксель, но оптимизация глубины HW не прерывается, как при отбрасывании фрагментов.

18 голосов
/ 14 декабря 2011

Это зависит от оборудования. Для оборудования PowerVR и других графических процессоров, которые используют рендеринг на основе плиток, использование discard означает, что TBR больше не может предполагать, что каждый нарисованный фрагмент станет пикселем. Это предположение важно, потому что оно позволяет TBR оценивать все глубины сначала , а затем оценивать только шейдеры фрагментов для самых верхних фрагментов. Этакий подход отложенного рендеринга, кроме аппаратного.

Обратите внимание, что при включении альфа-теста возникнет та же проблема.

3 голосов
/ 22 апреля 2013

Кроме того, наличие в вашем фрагментном шейдере оператора if может вызвать значительное замедление работы некоторых устройств. (В частности, графические процессоры с высокой степенью конвейеризации или с одной инструкцией / несколькими данными будут иметь большие потери производительности из операторов ветвления.) Таким образом, результаты вашего теста могут быть комбинацией оператора «если» и эффектов, упомянутых другими.

(Что бы ни стоило, тестирование на моем Galaxy Nexus показало огромное ускорение, когда я переключился на сортировку по глубине своих полупрозрачных объектов и рендеринг их назад, вместо рендеринга в случайном порядке и отбрасывания фрагментов в шейдере.) 1003 *

1 голос
/ 30 января 2012

Объект A находится перед объектом B. У объекта A есть шейдер, использующий 'discard'. Таким образом, я не могу сделать 'Early-Z' должным образом, потому что мне нужно знать, какие разделы объекта B будут видны через объект A. Это означает, что объект A должен пройти весь путь через конвейер обработки до почти последнего момент (до тех пор, пока не будет выполнена обработка фрагмента), прежде чем я смогу определить, является ли Объект B действительно видимым или нет.

Это плохо для HSR и 'Early-Z', поскольку потенциально закрытые объекты должны сидеть и ждать обновления информации о глубине, прежде чем их можно будет обработать. Как было сказано выше, это плохо для всех, или, что более дружелюбно, «Друзья не позволяют друзьям использовать Discard».

...