19.7 Оптимизация
В условиях использования отложенного затенения, эффективность освещения прямо пропорциональна количеству пикселей, на которых должны функционировать шейдеры освещения. Следующая методика разработана с целью уменьшения числа пикселей, по которым необходимо провести расчеты, связанные с освещением, что способствует увеличению производительности.
Ранние формы таких видов оптимизации, как z-rejection, stencil masking и dynamic branching имеют одну общую особенность: зависимость от локализации данных. Они в действительности зависят от строения hardware, что также верно в отношении большинства типов оборудования. Как правило, для наиболее эффективной производительности ранних видов z-rejection, stencil masking и dynamic branching необходимо, чтобы все пиксели в рамках малой экранной площади вели себя однородно в связи с вышеописанной особенностью. То есть они должны быть подвержены таким способам оптимизации, как z-rejection, stencil masking и dynamic branching одновременно для достижения максимальной производительности.
19.7.1 Оптимальная полнота освещения
Мы используем геометрию полноты освещения, которая задает жесткие рамки для фактической степени освещения. В техническом плане это означает, что весь экран может быть визуализирован отдельно для каждого отдельного освещения, а окончательное изображение будет выглядеть точно так же. Тем не менее, показатели производительности значительно снизятся. Чем меньше пикселей в рамках экранного пространства дублируется геометрией полноты освещения, тем реже выполняется операция пиксельного шейдинга. Мы используем конусообразную форму для прожекторного освещения, сферическую для точечного освещения, квадратную форму для освещения квадратного типа и полноэкранные четырехугольники для масштабного освещения, такого как направленное освещение.
Другой подход, описанный в большинстве работ на тему отложенного освещения, заключается в настройке глубины освещения и методе отбора исходя из положения светового объема и камеры. Подобная корректировка максимизирует результаты z-rejection на раннем этапе. Этот метод требует использования процессора для определения того, какой тест на глубину освещения и способ отбора с наибольшей вероятностью выявит первые пиксели, подверженные форме оптимизации z-rejection.
Мы остановились на использовании «улучшенного» теста на глубину освещения и метода изгиба «по часовой стрелке» (то есть инвертированного изгиба), который в нашем случае всегда работает (наши световые объекты никогда не пересекаются с другими плоскостями). На уровне обоснованного предположения можно быстро выбрать наиболее вероятный вариант теста на глубину и метода отбора. Тем не менее, наша проблема заключалась не в этом, поэтому мы решили не использовать процессорные ресурсы в попытках оптимизировать производительность с помощью вышеописанного метода.
19.7.2 Stencil Masking (трафаретное маскирование)
Использование трафарета для маскировки пикселей является другим способом ускорения производительности освещения в методике отложенного рендеринга. Основной метод заключается в применении трафаретного буфера в качестве отметки пикселей, которые не могут быть подвергнуты воздействию освещения. При рендеринге геометрии полноты освещения, просто проводится трафаретный тест для отклонения отмеченных пикселей.
Мы опробовали несколько вариаций данного метода. Обнаружилось, что в среднем, показатели улучшения производительности от подобной методики не были достаточными для компенсации любых дополнительных расходов, которые она могла повлечь впоследствии. Мы попробовали использовать «дешевые» методы отбора освещения с помощью отметки трафаретов пикселей, стоящих вдали от освещения или вне пределов освещения. И этот метод увеличил количество пикселей, позднее отсеченных завершающим тестом на освещение. Тем не менее, использование данного метода помимо DirectX 9.0, казалось, делает невозможным по причине высокой стоимости любые результаты, достигнутые в области производительности на этапе завершающего теста на освещение (в среднем).
Мы используем технологию трафаретного маскирования во время рендеринга непрозрачных объектов для отметки пикселей, к которым позднее будет применяться метод отложенного затенения. Такой подход исключает пиксели, относящиеся к плоскости неба или любые пиксели, касательно которых мы заранее знаем, что в отношении них не будут применяться (или не следует применять) расчеты. Это не требует никаких дополнительных затрат, что делает методику фактически бесплатной. Тест на освещение в дальнейшем отсеивает помеченные пиксели за счет трафаретной проверки. Описанный метод позволяет существенно экономить на затратах, в случае, если преобладающую часть экрана занимает небо, и, что не менее важно, не оказывает негативного влияния на производительность, даже в самом худшем случае.
Накладные расходы уменьшаются благодаря DirectX 10. Для читателей, предпочитающих данную платформу, может быть целесообразно изучение использования дешевых тестов для отсеивания большего количества пикселей. Тем не менее, применение dynamic branches вместо дополнительных тестов, скорее всего, можно назвать более подходящим вариантом при использовании Shader Model версии 3.0 или более поздней.
19.7.3 Dynamic Branching
Одна из ключевых особенностей Shader Model 3.0 заключается в поддержке формата dynamic branching. Dynamic branching не только способствует улучшению программируемости GPU, но, в определенных условиях, может также функционировать в качестве инструмента оптимизации.
Для использования dynamic branching для целей оптимизации, следуйте двум правилам:
1. Создавайте только одну или две dynamic branches, которые максимизируют как объем пропускного кода, так и частоту его принятия;
2. Не упускайте из виду местонахождение данных. Если пиксель занимает конкретную нишу, убедитесь в том, что шансы занятия той же ниши соседними пикселями максимизированы.
Что касается освещения, лучшее использование dynamic branches в качестве инструмента оптимизации подразумевает отсеивание пикселя на основе его расстояния от источника света и, возможно, нормали поверхности. Если используются нормальные карты, нормаль поверхности будет менее однородным по всей поверхности, что уменьшает вероятность его выбора в процессе оптимизации.
19.8 Результаты
Метод ООЗ не без изъянов. В этом методе существуют некоторые проблемы, начиная от ограничений канала до ограничений в использовании памяти, о которых должно быть известно тем, кто хочет использовать этот метод.19.8.1 Альфа-Смешанняая(alpha-blended) Геометрия
Единственным главным недостатком метода ООЗ является тот факт, что этот метод не может поддерживать Альфа-смешанную геометрию. Она не поддерживается не только из за ограничений железа, но и из за самой сути метода, где запоминается информация только о ближайшем пикселе. Мы решаем эту проблему путем использования форвард рендеринга после ООЗ рендеринга.Чтобы наш метод поддерживал А-Б нужно иметь большой буфер в котором будет храниться информация о каждом фрагменте материала вокруг каждого пикселя. Такой тип глубоко буфера не поддерживается тем железом, на которое нацелен данный метод.
С другой стороны, наше железо может поддерживать Аддитивный блендинг так же как и альфа тестирование, пока MRT активны, предпологая что рендер использует совместимый формат. Альфа-значение цвета равное нулю используется в этом тесте. Если этот фрагмент не удается протестировать, то никакая из целей рендера не обновляется. Мы не используем альфа-тестирование. Вместо него мы используем клип команды чтобы убить пиксель, пока МРТ активны. Мы делаем так, потому что альфа канал ренедера используется чтобы хранить дополнительную информацию, а не рассеивать альфу. Каждый визуализированный пиксель непрозрачен, поэтому мы не храним эту бесполезную информацию.
Мы делаем это, потому что альфа-канал , используется, чтобы хранить другие материальные данные а не рассеивать альфу. Каждый пиксел, выполненный в пределах задержанного конвейера, полностью непрозрачен, таким образом мы не используем один из наших каналов передачи данных, чтобы хранить бесполезные альфа-значения.
Используя форвард рендер для прозрачной геометрии главным образом решает эту проблему. Мы используем наш передовой рендерер для нашей воды и всей прозрачной геометрии. Водная программа построения теней использует нашу текстуру глубины от нашего задержанного конвейера как ввод. Однако, фактическое освещение на воде сделано традиционными форвард-методиками затенения. Это решение проблематично, однако, почти невозможно чтобы освещение на прозрачной геометрии соответствовало освещению на непрозрачной геометрии. Кроме того, много световых типов и освещающих особенностей, поддержанных нашим задержанным рендерером, не поддержаны нашим форвард рендерером. Таким образом наш механизм делает соответствие между двумя типами освещения.
В Tabula Rasa есть два основных случая, в которых несоответствие в освещении действительно стало проблемой: волосы и флора (травяной покров). И волосы и флора смотрятся, лучше всего когда выполнены используя альфа-плавное сопряжение. Однако, не было приемлемо для аватара идти в тень, и чтобы при этом его волосы не становились темнее. Аналогично, не было приемлемо для поля травы испытать недостаток в тенях.
Мы решили использовать альфа-тестирования для волос и флоры а не альфа-блендинг. Это позволило использованать метод ООЗ для волос и теней. Освещение было тогда непрерывным сквозь волосы и флору. Чтобы минимизировать выталкивание флоры, мы попробовали несколько методик. Мы рассматривали своего рода полупрозрачность, и мы даже попробовали фактическую прозрачность, выполняя визуализацию постепенно появляющийся флоры использую наш форвард рендерер,потом переключались на задержанный рендерер, как только это флора становилась полностью непрозрачной. Ни один из этих методов не был приемлемым. Мы в настоящее время масштабируем флору вверх и вниз, чтобы моделировать постепенное появление.
19.8.2 Полоса пропускания Памяти (Memory Bandwidth)
Задержанное затенение значительно увеличивает использование полосы пропускания памяти на аппаратных средствах. Вместо того, чтобы писать синглу выполняют цель, мы выполняем четырем из них. Это тетрады число письменных байтов. Во время прохода освещения мы тогда производим выборку от всех этих буферов, увеличивая чтение байтов. Полоса пропускания памяти, или заполняют норму, единственный наибольший коэффициент, который определяет производительность задержанного механизма затенения на данной части аппаратных средств.Единственный наибольший коэффициент под нашим контролем, чтобы смягчить проблему полосы пропускания памяти является разрешающей способностью экрана. Полоса пропускания памяти непосредственно пропорциональна числу выполненных пикселов, таким образом 1280x1024 может быть целых на 66 процентов медленнее чем 1024x768. Производительность задержанных основанных на затенении механизмов в значительной степени привязана к разрешающей способности, в которой они выполняются.
Проверка независимой поддержки битовой глубины и использование уменьшенной битовой глубины выполняют цели для данных, которые не нуждаются в дополнительной точности, может помочь уменьшать полную полосу пропускания памяти. Это не было опцией для нас, однако, потому что наши целевые аппаратные средства не поддерживают ту особенность. Мы пытаемся свернуть, какой материал приписывают данные, в которых мы должны сохранить, выполняют цели и сворачивают, пишет и выбирает от тех целей когда возможный.
Выполняя наши индикаторы, мы фактически используем множитель, выполняют цели. Мы имеем два MRTs активный и используем совокупный элемент сопряжения. Они выполняют цели, буфера накопления для разбросанного и зеркального индикатора, соответственно. Сначала это, могло бы казаться, было бы нечетным выбором для того, чтобы свернуть полосу пропускания, потому что мы пишем два, выполняют цели, поскольку световые программы построения теней выполняются вместо одного. Однако, повсюду этот выбор может фактически быть более эффективным.
Общее уравнение освещения, которое комбинирует разбросанный и зеркальный индикатор для конечного цвета фрагмента, выглядит следующим образом:
Frag lit = Frag unlit x Light diffuse + Light specular·
Это уравнение отделимо относительно разбросанного светового и зеркального индикатора. Удерживая разбросанный и зеркальный отдельный индикатор, мы не должны выбирать неосвещенный цвет фрагмента в наших световых программах построения теней. Световые программы построения теней вычисляют и выводят только два цвета: распространите световой и зеркальный индикатор; они ничего не вычисляют кроме светового взаимодействия с поверхностью. Если бы мы не сохраняли зеркальный световой компонент отдельным от разбросанного индикатора, то световые программы построения теней должны были бы фактически вычислить конечный цвет фрагмента литерала. Это вычисление требует выборки неосвещенного цвета фрагмента и выборки любого другого материального атрибута, который затрагивает его конечный цвет фрагмента литерала. Вычисление этого конечного цвета в световой программе построения теней также означало бы, что мы потеряем то, чем были фактические разбросанные и зеркальные световые компоненты; то есть, мы не могли анализировать результат программы построения теней назад в оригинальные световые компоненты. Наличие доступа к разбросанным и зеркальным компонентам в выполняет цели, предоставляет себя отлично расширенному динамическому диапазону (расширенный динамический диапазон) или любой другой постпроцесс, который должен обратиться, чтобы "осветить" в пределах сцены.
После того, как все световые программы построения теней выполнились, мы выполняем конечный полноэкранный проход, который вычисляет конечный цвет фрагмента. Этот конечный проход постобработки - то, где мы вычисляем туман, обнаружение края и сглаживание, и конечный цвет фрагмента. Этот подход гарантирует, что каждая из этих операций выполнена только однажды за пиксел, сворачивая выборки и развертывая когерентность кэш-памяти текстуры, поскольку мы выбираем материальные данные атрибута от нашего MRTs. Выборка материальных данных от MRTs может быть дорогой, особенно если это сделано чрезмерно, и кэш текстуры в аппаратных средствах становится побежденным.
Используя эти световые буфера накопления также позволяет нам легко отключать зеркальное накопление, выполняют цель, если зеркальное освещение заблокировано, сохраняя ненужную полосу пропускания. Эти световые буфера накопления являются также большими для того, чтобы выполнить постобработку при освещении, чтобы увеличить контраст, вычислить расширенный динамический диапазон, или любой другой подобный эффект.
19.7.3 Управление Памятью
В игре Табула Раса, даже при скромном разрешении 1024x768 мы можем использовать 50 Мб видео памяти только для целей рендера ООЗ. Это не включает в себя первичный буфер, вертекс буфер, индекс буфер или текстур. Разрешение 1600x1200 требует порядка 100Мб видео памяти только для целей рендера.Мы используем визуализицию обьектов величиной с четыре размера экрана , выполняя геометрию с нашими материальными шейдерами. Наши световые шейдеры используют цели для визуализации величиной с два экрана. Они выполняют цели, могут быть 32 бита за пиксел или 64, в зависимости от параметров настройки графики и качества. Добавьте к этому 2048x2048 32-разрядная теневая карта для глобального направленного индикатора, плюс дополнительные теневые карты, которые были созданы для других индикаторов
Одно возможное решение это выполнять цели, с более низким разрешением , а затем повышать результаты в конце. У этого решения есть много плюсов, но мы находим получаемое качество изображения плохим. Мы не использовали эту опцию очень широко, но возможно она могла быть использована успешно для определенных приложений.
Количество видеопамяти, используемой, выполняет цели, только часть проблемы. Все это оказывает значительное влияние также на производительность . Даже при том, что фактическое размещение этих текстур в видеопамяти находится вне нашего контроля, мы делаем несколько вещей, чтобы выручить драйвер.
Мы распределяем наши первичные текстуры MRT вплотную и перед любой другой текстурой. Идея состоит в том, чтобы распределить их, в то время как большинство видеопамяти доступно, таким образом драйвер может разместить их в видеопамять с минимальной фрагментацией. Мы имеем все еще во власти драйвер, но мы пытаемся помочь ему столько, сколько мы можем
Мы ограничиваем число теневых карт, доступных для механизма. Основанный на световом приоритете, местоположение освещения , и желательный размер теневой карты, мы скупо выдаем теневые карты на индикаторы. Эти теневые карты не выпущены, но сохранены и многократно использованы. Это сворачивает фрагментацию видеопамяти, наверху связанный с создаванием и высвобождением средств
Мы также отслеживаем, сколько теневых карт визуализировано в любом кадре. Если больщое количество разных освещений требуют чтобы их теневые карты были перестроены в том же кадре, механизм может перестроить одну или две из них за один кадр, снижая цену их перестройки за большое количество кадров
19.8 Результаты
В игре Tabula Rasа мы достигли нашей цели, используя ООЗ рендер. Мы находим исполнение ООЗ приемлемым. Более раннее железо Шейдера 3.0, такое как NVIDIA GeForce 6800 Ultra может работать со скорость 30 fps с обычным сеттингами и средним разрещением. Мы обнаружили, что последнее железо с DirectX 10, такое как GeForce 8800 и ATI Radeon 2900 может обрабатывать игру Tabula Rasa очень хорошо со всеми высокими настройками.Рисунки с 19-6 по 19-10 показывают результаты, полученные нами с нашим подходом.
Рис 19-6 An Outdoor Scene with a Global Shadow Map
Рис 19-7 An Indoor Scene with Numerous Static Shadow-Casting Lights
Рис19-8 Fragment Colors and Normals
Рис 19-9 Depth and Edge Weight Visualization
Рис 19-10 Light Accumulation
Комментариев нет:
Отправить комментарий