Войти
ПрограммированиеСтатьиГрафика

Recursive Tile-based architecture

Автор:

Данная статья вводит понятие Recursive Tile-Based Architecture (RTBA), расширяющее возможности традиционной tile-based архитектуры. Предложенный подход позволяет работать с аппаратно-ускоренным тайловым растеризатором в терминах когерентного рейтрейсинга, каждый тайл рассматривается, как средство обработки пучка лучей.

Для таких эффектов, как отражения, преломления и тени, данная архитектура позволяет уменьшить bandwidth, исключить или уменьшить работу со временными текстурами, не тратить время на обработку невидимых эффектов (заслонённых более близкими объектами), сделать рендеринг вторичных эффектов гибче — увеличив их количество и качество, упростить разработку риалтаймовых рендереров за счёт упрощения кода. RTBA сохраняет обратную совместимость с классической техникой растеризации и другими методами риалтайм графики.

В первую очередь, RTBA ориентирован на решение ряда проблем риалтаймовой 3D графики на мобильных платформах. Реализация данной архитектуры возможна на уровне драйверов современных GPU реализующих TBA.

Введение
Tile-based architecture (TBA)
  Рекурсивная растеризация в TBA
    Primitive Provider
    Re-rasterization of a tile
Пайплайн рендеринга RTBA
  Акселерационная структура
  Pipeline Binding Table
  Local Tile Memory Management
Заключение
Список литературы

Введение

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

Для расчёта транспорта фотонов используется множество техник, таких как: растеризация, path tracing, ray-marching, voxel tracing, shadow maps, beam-tracing и так далее. Каждый способ имеет свои за и против, различную точность, производительность и прочие особенности.

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

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

2. Растеризация происходит только в аффинном пространстве. Конечно, можно использовать clip-plane и другие техники, но этого недостаточно для ряда задач.

Решения на базе трассировки лучей не имеют таких ограничений; они притягивают внимание разработчиков своей высокой гибкостью и низким порогом входа. К сожалению, в типичных игровых сценариях, расчёте на одну точку, алгоритмы трассировки лучей в десятки и сотни раз медленнее, чем типичная растеризация, даже при наличии аппаратной оптимизации. Так же, они требуют denoising, которая тоже неэффективна для мобильных платформ из-за большого bandwidth. Двойная неэффективность этого метода не даст использовать рейтрейсинг в массовых 3Д приложениях на мобильных платформах в обозримом будущем. Альтернативные методы быстрее и позволяют реализовывать большое количество эффектов уже сейчас. Хотя альтернативные методы намного сложнее в реализации, в том числе в вопросе организации их взаимодействия – игровые движки позволяют скрыть эту сложность от разработчиков конечных продуктов.

Нужно отметить, что растеризацию можно рассматривать, как частный случай рейтрейсинга. В конечном счёте и там и там находится точное пересечение со сценой. В случае с растеризацией расчёт идёт для большого количества лучей, которые обязаны быть регулярным образом расположены во фраструме. Так же отметим, что аппаратные TBA растеризаторы оптимизированы для обработки небольших блоков фиксированного размера, например, Mali использует блоки 16х16 пикселей или лучей, в зависимости от интерпретации.

RTBA был разработан для того, чтобы раскрыть потенциал тайловых архитектур, рассматривая аппаратные ускорители растеризации маленьких блоков, как самостоятельную функцию, напоминающую когерентный рейтрейсинг.

Tile-based architecture (TBA)

Для начала рассмотрим некоторые особенности TBA.

TBA позволяет уменьшить bandwidth и снизить энергопотребление. Малые размеры рабочей части render target (тайл) позволяют разместить основные данные в кэше. Расчёты происходят с минимальной латентностью, а в основную память копируется только небольшая необходимая в дальнейшем часть данных. Например, в типичном случае работы с G-Buffer – z-buffer, нормали, идентификаторы материалов – будут присутствовать только в кэше, в виде небольших блоков фиксированного размера. Наложение прозрачных слоёв поверх, а также постобработка может произойти без обращения к основной памяти, а в конце будет скопирован только слой содержащий цвет пикселей. Некоторые вендоры даже проверяют контрольную сумму данных в тайле с контрольной суммой соответствующих данных в рендертаргете, это позволяет избежать копирования и несколько повысить энергоэффективность.

Ключевой особенностью TBA является разделение процесса растеризации на две стадии:

1. Модуль tiler распределяет отправленные на рендер треугольники (geom and vertex shaders) и render state по тайлам, где они могут быть видны. После распределения существует момент, когда в памяти GPU хранятся списки примитивов, которые нужно будет отправлять на растеризацию. Нужно отметить, что система хранения списков может быть нетривиальной, например иерархичной, для того чтобы сделать выделение памяти на список примитивов более предсказуемой.

2. После запуска растеризации GPU обходит каждый тайл и отправляет соответствующий список примитивов на растеризацию (стадия fragment). После завершения обработки списка примитивов тайла GPU копирует требуемые слои в основную память.

shema1 | Recursive Tile-based architecture

TBA пайплайн. Голубые блоки показывают ключевые для нас стадии.

Данная схема не устраняет bandwidth требуемый для чтения и записи временных текстур, которые требуются для рендеринга ряда эффектов, таких как отражения, преломления и тени. Конечно, есть и альтернативные способы рендеринга, без использования временных текстур, например shadow volumes или рендеринг отражений с помощью порталов, но и у этих способов есть свои недостатки.

shema2 | Recursive Tile-based architecture

Пример пайплайна для более сложного рендеринга. Приходится синхронизировать данные через основную память.

Вернёмся к спискам примитивов. Если разработчик имеет доступ к памяти и знает её структуру (это характерно для разработчиков драйверов), данные списки примитивов могут быть заполнены соответствующими низкоуровневыми средствами, например с использованием compute shaders. Конечно можно допустить существование экзотических платформ, например с жёстким разделением памяти по отдельным функциональным модулям, но у нас нет информации о таких платформах.
Держа в голове данные особенности и возможности TBA давайте рассмотрим две ключевых модификации драйвера способных значимо расширить наши возможности в растеризации сцен.

Рекурсивная растеризация в TBA

Primitive Provider

Предлагается ввести в драйвер и реализовать открытый API для новой сущности «primitive provider» (источник примитивов). Его можно представить как чёрный ящик, который на вход получает фрустум специфичный для отдельного тайла, а на выходе выдаёт список команд для отрисовки в том же формате, как это делает обычный tiler GPU для каждого тайла. В дальнейшем термин primitive provider будет рассматриваться, как интерфейс для  «акселерационной структуры». В самом деле, если для процесса растеризации не важно откуда берутся примитивы, и главное, чтобы их можно было получить по запросу, то для полноценного игрового движка - важно, чтобы реализация выборки примитивов была максимально эффективной, она может быть сложной и реализовываться разными алгоритмами, возможно предоставляемых, как драйвером, так и разработчиком.

Внешний API для акселерационной структуры уже имеет стандартизированный API, например в Vulkan. Этот API может быть использован для встроенной в драйвер реализации без изменений, или с добавлением нескольких функций ускоряющих систему с учётом специфики мобильных платформ (их обсуждение выходит за рамки статьи).

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

Для растеризации с использованием primitive provider требуется добавить, как минимум одну новую функцию, которая будет принимать следующие параметры:

1. Акселерационная структура;

2. Таблица пайплайнов рендеринга; поскольку сцена рендерится одним запросом, то и все необходимые для рендеринга данные должны быть доступны в один момент. Здесь ситуация аналогична с таблицами шейдеров для рейтрейсинга, единственное, что поскольку мы работаем в концепции растеризации — то и пайплайны используются из неё, тут не требуется какой-то принципиально новой функциональности. Детали будут описаны ниже.

3. Источник фрустумов; В простом варианте просто указатель на их массив в памяти, либо шейдер, который их сгенерирует по запросу;

4. Куда рендерить. Опционально — можно указывать маску актуальных тайлов.

Уже данной функции достаточно для того, чтобы сильно расширить возможности разработчика:

1.  Растут возможности по оптимизации растеризации за счёт использования акселерационных структур, лучшего клиппинга. Интеграция акселерационной структуры в драйвер, вместо использования внешней, позволяет убрать затраты на передачу геометрии от пользовательской структуры, существующей в большинстве игровых движков, в драйвер с помощью вызовов draw. Акселерационная структура может писать непосредственно в нужные участки памяти.

2.  Становится возможным сформировать сложные пространства камеры, вместо простой пирамиды. Например, становится возможным за один вызов создавать области рендеринга эффективно описывающие отражения или преломления от криволинейных поверхностей. Можно попробовать рендерить shadow map с очень сложной структурой каскадов, так как каждый тайл может быть подстроен под сцену.

3.  Становится возможным обновлять render target частично, экономя ресурсы. Например, возможно в reflection probe обновлять только те части, в область видимости которых попали какие-то анимации. То же самое с shadow map.

4.  Становится возможным реализовывать variate rate shading нескольких типов: например, отрендерив один тайл, или набор из 2х2 тайлов в зоне мало актуальных частей сцены, копировать их в финальных рендертаргет с растягиванием.

5.  Значительно упрощается программирование графических движков, так как драйвер может отрендерить сцену самостоятельно: не нужно думать о порядках отправки геометрии и материалов, ни о множестве оптимизаций, которые драйвер берёт на себя.

Re-rasterization of a tile

Вторым ключевым нововведение должна стать возможность запустить процедуру рендеринга тайла несколько раз, до выгрузки его данных в основную память.

Это может быть реализовано с помощью последовательного вызова различных типов шейдеров, которые будут использовать память тайла для обработки различных фаз рендеринга. Что-то подобное уже есть, например, в случае deferred shading с использованием G-Buffer, последующим наложением прозрачных объектов и постпроцессингом. Данный подход позволяет уменьшить bandwidth для типичных игровых сценариев. Мы предлагаем развить данный подход, позволив вызывать так же compute shaders и другие стадии растеризации, в условиях, когда данные тайла остаются в быстром кеше, либо выгружаются в кеш более низкого уровня, что должно быть всё-ещё быстрее, чем копировать их в финальный рендертаргет.

Это позволяет произвести анализ тайла после первичной растеризации, определить, какие необходимы вторичные эффекты и их параметры. Это может быть серия compute shader, которые идентифицируют соответствующие материалы, сформируют для них новые фрустумы (простейший случай – отражения). Затем происходит один или несколько вызовов шейдеров, реализующих функциональность акселерационной структуры. Она заполняет новый список треугольников и цикл растеризации повторяется. Результаты новой растеризации совмещаются с предыдущим состоянием тайла. Цикл может повторяться многократно до тех пор, пока это необходимо. Это может позволить эффективно реализовывать простые формы таких эффектов, как отражение, преломление, тени, SSS, OIT.

shema3 | Recursive Tile-based architecture

Пример растеризации тайла с отражением. Шаги растеризации синхронизируются через кеш.

В качестве удобного и эффективного способа реализации предложенной схемы, с учётом особенностей и  ограничений мобильных GPU, предлагается новая конструкция: дерево возможных bounce (bounce tree), где bounce это блок задач связанных с поиском пересечения группы лучей со сценой и первичная обработка найденных пересечений. Например, в типичном случае, дерево начинается с камеры, первый bounce соответствует первичному рендеру. Каждая ветка в дереве определяет некоторый тип спецэффектов. Внутри каждой ветки может происходить несколько подрендеров для обработки распространения лучей в разных направлениях. Это может быть необходимо, если, допустим, внутри одного тайла сошлось несколько отражающих поверхностей.

Bounce Tree позволяет формализовать алгоритм рендеринга сцены в рамках развитой системы растеризации. В результате, за один вызов, драйвер TBA GPU может более эффективно отправить на рендер такие эффекты, как: множественный рендеринг сцены (для реализации сложных эффектов), обработку отражений, преломлений, SSS и их произвольных сочетаний.

Например, дерево может содержать следующие bounce: рендеринг непрозрачных частей сцены, отражений, преломлений, прозрачности, UI. Это дерево позволит драйверу отрендерить всё и вернуть готовый тайл уже со всеми эффектами.

Для реализации рекурсивной растеризации требуется ввести две группы управляющих программ (шейдеров):

Первая, предназначенная для анализа и постобработки тайлов, обозначается «Advanced Tile Filter» или ATF. Шейдеры ATF могут быть вызваны на различных стадиях пайплайна рекурсивной растеризации, далее они будут идентифицироваться, как ATF A, ATF B, ATF C и ATF D.

ATF A предназначен для первичной постобработки тайла после его растеризации, а так же определяет – необходимо ли выполнение соответствующих веток bounce tree (подрастеризаций), и  заполняет массив подфрустумов. Эти фрустумы будут использованы драйвером для получения новых списков примитивов.

ATF B может быть запущен немедленно после выполнения дочернего bounce. Цель данного шейдера – объединить данные, полученные в ходе основной и дополнительных растеризаций. Например: добавить отражение на основное изображение сцены.

ATF C может быть запущен после того, как все подрендеры были завершены.

ATF D может быть запущен, когда подрендеров нет.

Реализация ATF основана на функциональности compute shader, но некоторые стадии могут быть fragment.

shema4 | Recursive Tile-based architecture

Структура первичного и вторичных потайловых растеризаций.

Второй тип шейдеров необходим для определения логики рекурсивной растеризации, мы называем его “Tile Rendering Management” или TRM. TRM позволяет регулировать:
-  Число подрендеров;
-  Параметры обращения к акселерационной структуре;
-  Определяет условия прекращения рекурсии;

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

Пайплайн рендеринга RTBA

Мы предлагаем рассмотреть пайплайн рендеринга в виде конечной машины состояний. Рекурсивная растеризация начинается с получения начального фрустума и заканчивается копированием необходимых слоёв тайла в рендертаргет.

shema5 | Recursive Tile-based architecture

Конечная машина состояний для RTBA

Акселерационная структура

Полноценное описание требований к акселерационной структуре выходит за пределы данной статьи. Отметим несколько пунктов:

1.  Акселерационная структура может быть, как встроенной, так и предоставленной разработчиком.

2.  Поставщиков примитивов может быть несколько, TRM позволяет определить текущий. Это необходимо, как минимум для того, чтобы в играх можно было раздельно рендерить уровни и UI.

3.  Исходный tiler может быть одним из доступных типов поставщиков примитивов работающих в рядовых случаях.

4.  В большинстве случаев, фрустумы по которым идёт выборка – узкие, боковые грани почти параллельны друг-другу. Можно оценить, что если ширина экрана 1600 пикселей, а соответствующий угол фрустума камеры 120 градусов, то угол фрустума одного тайла будет ~1.2 градуса.

5.  Существует множество оптимизаций для того, чтобы не обрабатывать одиночные фрустумы, а группировать их различными способами и обрабатывать сообща. По нашим расчётам, со всеми оптимизациями, совокупное количество запросов к акселерационной структуре для типичной игры будет порядка 5000–50000  в секунду, время на данные вычисления будет незначительным на фоне общего рендеринга.

6.  Акселерационная структура может учитывать LoD объектов, а также детектировать перекрытие видимости для фрустума (clipping).

7.  Акселерационная структура совмещается с системами генерации геометрии, так как только она является поставщиком примитивов.

8.  Одной из серьёзных проблем является рендеринг полупрозрачных объектов. Эта проблема может решаться размещением таких объектов в дополнительных акселерационных структурах, и организации специальных bounce для их рендеринга. Аналогично происходит сейчас при рендеринге с использованием G-buffer. Так же мы демонстрировали работу OIT на базе depth peeling: в случае RTBA этот метод может работать достаточно эффективно для простых случаев.

Pipeline Binding Table

Для растеризации всех этапов рендеринга сцены драйверу должен быть предоставлена структура всех возможным пайплайнам рендеринга. Это предлагается сделать с помощью введения новой сущности: Pipeline Binding Table. Каждому баунсу сопоставляется такая таблица.

Запись в этой таблице в качестве значения принимает пайплайн аналогичный пайплайнам Vulkan, а ключом выступает индекс идентификатор материала соответствующий идентификатору материала в акселерационной структуре.

Local Tile Memory Management

RTBA требует расширение возможностей для разработчика управлять данными тайла, определять их расположение в кэшах GPU. Например, при рендеринге сцены с отражениями, рендеринг основной сцены может потребовать 4-5 слоя в тайле: цвет, нормаль, глубина, материал, depth. После шейдинга, ATF A обходит слои с материалом, глубиной и нормалью и строит под-фрустумы для отражающих поверхностей. После чего нормаль, глубина, depth становятся неактуальными. Слой с материалом должен быть остаться актуальным, т.к. нужно понимать, какие пикселы куда и как отражают. Два актуальных слоя могут остаться в той же памяти, или быть скопированными в кэш более высокого уровня. После вторичного рендера, который может быть проще первичного – ATF C совмещает сохранённый слой с цветом с отражением, с использованием маски (бывшего слоя с материалами).

Заключение

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

Способность просто растеризовать сложную сцену без учёта вторичных эффектов уже не является какой-то проблемой. Современные девайсы вполне способны выводить миллионы треугольников в кадре, что сопоставимо с количеством пикселей на экране. Более важным становится запрос на рендеринг вторичных эффектов: реалистичных отражений, преломлений, теней, GI и т.п. Вторичность эффектов подразумевает всё большую связность сцены, её уже неэффективно представлять простыми списками треугольников, даже при растеризации. Поэтому, можно ожидать тенденций расширения практики использования акселерационных структур и всё большей поддержки их в драйверах.

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

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

Обратная связь:

Список литературы



J. Hart, "Sphere Tracing: A Geometric Method for the Antialiased Ray Tracing of Implicit Surfaces," The Visual Computer, 1995.
J. Amanatides and A. Woo, "A Fast Voxel Traversal Algorithm for Ray Tracing," in EuroGraphics, 1987.
C. Barré-Brisebois, H. Halén, G. Wihlidal, A. Lauritzen, J. Bekkers, T. Stachowiak and J. Andersson, "Hybrid Rendering for Real-Time Ray Tracing," in Ray Tracing Gems, Berkeley, CA, Apress, 2019, pp. 437-473.
H. Fuchs, J. Poulton, J. Eyles, T. Greer, J. Goldfeather, D. Ellsworth, S. Molnar, G. Turk, B. Tebbs and L. Israel, "Pixel-Planes 5: A Heterogeneous Multiprocessor Graphics System," in SIGGRAPH'89:Proceedings of the 16th annual conference on Computer graphics and interactive techniques., 1989.
R. Barringer, . C. J. Gribel, . A. Lefohn and T. G. Akenine-Möller, "Graphics tiling architecture with bounding volume hierarchies". Santa Clara, CA Patent 8823736, 02 09 2014.
G. Muthler, T. Karras, S. Laine, W. P. Newhall, . R. C. Babich, . J. Burgess and . I. Llamas, "Method for continued bounding volume hierarchy traversal on intersection without shader intervention". Patent 20210005010, 07 01 2021.
The Group, "Vulkan® 1.1.178 - A Specification (with all registered Vulkan extensions)," [Online]. Available: https://www.khronos.org/registry/vulkan/specs/1.1-extensions/html… ion-structure. [Accessed 20 05 2021].
N. Glushkov and E. Tyuleneva, "Projection matrices and related viewing frustums: new ways to create and apply," 19 05 2021. [Online]. Available: https://arxiv.org/abs/2105.09476. [Accessed 21 05 2021].
C. Magnerfelt, "Transparency with Deferred Shading," Royal Institute of Technology, Stockholm, Sweden, 2012.
The Group, "Vulkan® 1.2.178 - A Specification (with KHR extensions)," [Online]. Available: https://www.khronos.org/registry/vulkan/specs/1.2-khr-extensions/… binding-table. [Accessed 20 05 2021].
ARM, "Documentation – Arm Developer," [Online]. Available: https://developer.arm.com/documentation/101811/0101/The-Memory-Ma… ment-Unit-MMU. [Accessed 20 05 2021].
G. Gribb and K. Hartmann, "Fast Extraction of Viewing Frustum Planes from the WorldView-Projection Matrix," 2001. [Online]. Available: https://www.gamedevs.org/uploads/fast-extraction-viewing-frustum-… on-matrix.pdf. [Accessed 20 05 2021].
L. Yuanyuan, B. Hai and L. Guizi, "Graphics processing unit operation". Santa Clara, California Patent WO2017112403A1, 29 06 2017.
A. Shcherbakov and V. Frolov, "Dynamic Radiosity," in WSCG'2019 - 27. International Conference in Central Europe on Computer Graphics, Visualization and Computer Vision'2019, Plzen, Czech Republic, 2019.
J. Yu, L. McMillan and P. Sturm, "Multiperspective modeling, rendering, and imaging," in SIGGRAPH Asia '08: ACM SIGGRAPH ASIA 2008 courses, New York, NY, United States, 2008.
L. Baoquan, W. Li-Yi, Y. Xu, M. Chongyang, X. Ying-Qing, G. Baining and W. Enhua, "Non-Linear Beam Tracing on a GPU," Computer Graphics Forum, vol. 30, no. 8, pp. 2156-2169, 2011.
"Inigo Quilez: articles: distance functions," [Online]. Available: https://www.iquilezles.org/www/articles/distfu

#mobile, #rasterization, #Reflection, #rtba, #tile-base architecture

8 января 2022

Комментарии [51]