Recursive Tile-based architecture (комментарии)

Recursive Tile-based architecture (комментарии)

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

> Модуль tiler распределяет отправленные на рендер треугольники (geom and vertex shaders) и render state по тайлам
Немного оффтоп, но как обрабатывается тесселяция? Куча вершин генерируется перед разбиением на тайлы или есть возможность тесселировать после разбиения?

> Пример пайплайна для более сложного рендеринга.
Обычно для таких пайплайнов выделяют столбцы с VRAM, кэшем тайла и тд, чтоб видно было как между ними данные перекидываются. А для большей наглядности можно примерный объем данных указать и сколько это выделит тепла)

И какие шансы что это будет реализовано? Или получится как с меш шейдерами - давно добавили, а мало кто использует, потому что осталась куча старых гпу. RTX хотя бы дополняет screen space техники, поэтому чаще используется.

Опечатка:

>Немного оффтоп, но как обрабатывается тесселяция? Куча вершин генерируется перед разбиением на тайлы или есть возможность тесселировать после разбиения?
У мали нет хардварной поддержки тесселяции и геометри буферов, они эмулированы через cs. Программы довольно объёмные, я их не вычитывал, просто отметил, что они похожи на то, что нужно нам.
Сама работа тайлера вроде как железная.

>Обычно для таких пайплайнов выделяют столбцы с VRAM, кэшем тайла и тд, чтоб видно было как между ними данные перекидываются.
По сути это всё определяет разработчик, но какой-то особой дополнительно памяти тут не требуется, всё ложится на уже существующее железо. Мы уже сейчас в вулкане указываем, что и где - для RTBA просто нужно немного эту систему расширить, чтобы обеспечить многоразовость рендеринга до выгрузки тайла.
Например, в наших демках использовалось четыре или пять слоёв, а затем - 3 для подрендеров. Физически эти три могут располагаться в той же памяти - т.к. к моменту начала подрастеризации - часть памяти уже не нужна.

>И какие шансы что это будет реализовано?
Хз. Известная компания этого сделать не в состоянии. Посмотрим на конкурентов. В принципе в обсуждениях вендоров на кроносе к чему-то такому постепенно и идут, может заметят.

>Или получится как с меш шейдерами - давно добавили, а мало кто использует, потому что осталась куча старых гпу.
Вот кстати RTBA чем-то очень похож на мешшейдеры, эмулятор даже хотели на них сделать. Проблема в том, что их поддерживает только Нвидия. RTBA может быть востребованым, потому, что он позволяет заметно повысить качество рендера на мобилах, и при этом разработка с его использованием проще, нет необходимости возиться с заполнением коммандбуферов.

>RTX хотя бы дополняет screen space техники, поэтому чаще используется.
Да, следующая статья про это.

/A\
> Куча вершин генерируется перед разбиением на тайлы или есть возможность
> тесселировать после разбиения?
А если у нас после разбиеня, во время тесселяция вершину подвинули так, что она попала в другой тайл?

Честно говоря, до меня так и не дошла идея автора. Прочитаю, потом, во второй раз. Может понятнее станет.
Если основной посыл не выгружать из тайла данные до последнего, то разве сейчас не так? Разве не для этого придумывали все эти рендерпассы и сабпассы?

HolyDel
> А если у нас после разбиеня, во время тесселяция вершину подвинули так, что она
> попала в другой тайл?
В тайл попадает не вершина, а треугольник. А тесселяция да, происходит до работы тайлера.

> то разве сейчас не так
Это тенденция, которую развивает технология предложенная в статье.
Сейчас:
1. У нас только один поставщик треугольников в тайлы, причём он 2Д.
2. После того, как треугольники ушли на растеризацию - тайл обязательно будет выгружен, нельзя запросить новые треугольники в том же тайле и наложить их поверх.

опубликовал статью

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

HolyDel
> А если у нас после разбиеня, во время тесселяция вершину подвинули так, что она
> попала в другой тайл?
Можно расчитать OOBB и на основе этого раскидывать примитивы по тайлам, но это все усложнит, так что я думаю лучше найти замену тесселяции.

> Честно говоря, до меня так и не дошла идея автора.
Я так понял:
Во времена до RTX нужно было делать light probe, reflection probe в виде кубемап, для мобилок это дорого, так как используется VRAM.
Primitive Provider -  по конусу/пирамиде возвращает видимые треугольники.
Для тайла делается запрос к Primitive provider и растеризуется кусок сцены, дальше для всех отражающих поверхностей в тайле снова вызывается primitive provider с другим конусом и в отдельный тайл рисуются отражения, потом фильтруются и накладываются на первый тайл.
Когда вышел RTX здесь на форуме обсуждалось, что вместо трассировки лучами правильнее трассировать конусами, вот примерно оно и есть.

Mobile Developer
Я думал о чем-то подобном, только подготовка данных для отражений и прочего происходит на сервере, а на мобилке уже рисуется упращенная трансформированная геометрия с блендингом. Тот же downsampling для тонемапинга делается на сервере и передается только значение яркости кадра. Таким образом выкидываются дорогущие операции блура.
Таким образом не надо будет обновлять железо или апи, да и требования к железу меньше, а при потере связи с сервером только ухудшается картинка, в отличие от передачи видео.

Suslik
> помешала какая-нибудь весёленькая
Да, но тут всякие легальные вопросы... Сейчас посмотрю аналогичные картинки в инете.

/A\
> Можно расчитать OOBB и на основе этого раскидывать примитивы по тайлам, но это
> все усложнит, так что я думаю лучше найти замену тесселяции.
Чёт я не смотрел с этой точки зрения. Мне кажется, что они тупо всё тесселируют, а не только видимое. А затем новую полученную геометрию уже отправляют на рендер как обычную.

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

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

Но в принципе трассировка фрустомов (при куче существующих оптимизаций) - дешёвая, она в пике 1% времени может занять, при том, что даёт кучу бенефитов.

RTBA не требует обновления железа, просто нужно модуль в драйвер добавить. По крайней мере для Мали это всё очень красиво может быть сделано, я не думаю, что у остальных внутренняя архитектура сильно отличается (ещё broadcom архитектуру смотрел, допустим).

Mobile Developer
> Мне кажется, что они тупо всё тесселируют, а не только видимое.
Скорее всего так и есть. Я к тому что тесселяция после нарезания на тайлы может быть оптимальнее, но это уже тянет на другой тип шейдера.

> > в отдельный тайл рисуются отражения
> В тот же.
А как же блурить отражения для шероховатых поверхностей?

Mobile Developer
Кстати, на адрено 660 размер тайла зависит от формата G-буфера который умещается в 1.5Кб кэша. Для 64-битного G-буфера это аж 320х480 и 480х320 в зависимости от того, как лучше укладывается в экран.

/A\
> Я к тому что тесселяция после нарезания на тайлы может быть оптимальнее
Мб, только непонятно как это физически вообще сделать. Когда у тебя примитив попал в тайл - он же буквально оказался в компрессированном списке. Это нужно все списки обходить, искать тесселируемые треугольники, удалять их, повторять все процедуры, загружать обратно. Это очень сложно в реализации, а профит неочевиден.

>А как же блурить отражения для шероховатых поверхностей?
Тупых способов несколько:
1. Можно вторичные фрустумы делать чуть шире (математика фрустумов сама по себе нетривиальна, но в данном случае это возможно), получать отражение с чуть более широким углом, и делать из него несколько выборок.
2. Можно сохранить неразмытое, а затем сделать проход по всей текстуре. Тут банвиз растёт, но зато нет ограничения на число отражений: бликовать под определённым углом может каждая видимая поверхность, а если угол большой - то ничего и не происходит.

/A\
> умещается в 1.5Кб кэша. Для 64-битного G-буфера это аж 320х480 и 480х320 в
> зависимости от того, как лучше укладывается в экран.
Нет ли тут ошибки?
320х480 = 153600 пикселей. Если у тебя на пиксель только цвет и z-buffer то это уже полтора метра.

Впрочем Мали немного убитый чип, да. Одна из причин почему эту систему придумывали - стояла задача на нём что-то вытянуть.

Mobile Developer
> Если у тебя на пиксель только цвет и z-buffer то это уже полтора метра.
Да, значит 1.5Мб. В спеках этого не нашел, поэтому рассчитывал экспериментально через fragment density - на адрено в вределах тайла доступен только один режим.