Simon Kozlov:
Давайте поговорим про многобсуждаемый tiled forward rendering.
Насколько я понимаю, идея в общем и целом в том, чтобы как-то в пикселе или тайле записать список источников.
И фигачить все за один проход forward render'ом,
чтобы не раздувать GBuffer и нормально работать с прозрачностью.
Графические программисты, расскажите что вы думаете.
Arseny Kapoulkine:
Дальше, проблема прозрачности на самом деле решается в итоге так себе :)
Так же как 10 лет назад.
Мой вопрос про DoF и партиклы скажем примерно про это, если есть k-buffer то можно сделать лучше - дальше надо смотреть, насколько практично k-buffer вместе с DS (скажем, через несколько лет на top hardware)
Finally, я только что как раз читал preprint статьи где делались сравнения по производительности.
Если есть статья лучше - расскажите, иначе вот http://www.cse.chalmers.se/~olaolss/papers/tiled_shading_preprint.pdf (наверное, есть в тех ссылках)
Там результаты (на GTX 480) не очень впечатляют.
Очевидно нет ни исходников ни доверия авторам, так что относиться надо скептически.
Arseny Kapoulkine:
Посмотрел ссылки - у других людей другие результаты, так что хрен знает.
Ultimately конечно если ALU будет и дальше расти, и расти быстрее памяти, то возможно на разные проблемы с т.з. производительности можно будет забить.
Vadim Shcherbakov:
я конечно не графический но мне лайтпрепас больше нравица чем такое.
Simon Kozlov:
То есть тебе не хочется сложного BRDF на матералах!
И вообще ебически сложного освещения.
Arseny Kapoulkine:
Там есть примерно следующие проблемы.
  • 1. Становится легко кастомизировать материалы но сложно кастомизировать лайты.
Например, размер шейдера пропорционален количеству разных лайтофич.
Примеры - разные шадовмапы (omni, cascaded, single)
Еще примеры - кастомная геометрия для лайтов.
Еще примеры - разные типы лайтов тупо (omni / spot / line / etc.)
Еще примеры - всякие screen-space блуры теней идут лесом, "шадовмап на все и специальный шадовмап на персонажа для качества" идут лесом и т.п.
  • 2. Все шадовмапы для кадра надо держать в памяти, ну и в одной текстуре/массиве в принципе.
  • 3. Эффективность PS сильно ниже из-за мелких треугольников (квады)
Denis Sladkov:
и это интересно. насколько популярны разные лайт-фичи типа кастомной геометрии? мы вот никогда не юзали до сих пор. типы ламп в рамках omni, spot, dir - объединяются бесплатно фактически. area lights - сложнее, да. но на практике опять же не видел никогда.
надо заметить что это чисто про прозрачность. screen-space sm mask (как и блюры) перпендикулярны месту рассчета лайтинга.
Arseny Kapoulkine:
Я где-то видел кастомную геометрию (кажется в инди Penumbra, но не уверен).
Есть еще всякая минорная хрень.
Типа gobo на спотах.
Denis Sladkov:
Да, отсекающая геометрия - часто полезная фича. Там где хочется секономить на тенях. Лампа на спине мейнкера в инвершене, например. Как и гобо - фонарик в хало. Думаю универсальных 4 плоскости в первом случае ок. А гобо в случае спота у нас был тоже дешевый 1д лукап. Но даже пусть и 2д - не звучит страшно.
Simon Kozlov:
Все так!
Arseny Kapoulkine:
Преимущества в целом все описаны вроде по ссылкам! Прозрачность (как я сказал уже, как 10 лет назад - впрочем можно OIT поверх этой фигни, с бонусом что всего лишь один цвет вместо кусочка g-buffer), разные материалы делать просто (есть вещи которые в deferred хорошо по-моему вообще не сделать - типа, многослойных материалов aka car paint, ну плюс анизотропное освещение и т.п), нормально работают производные (environment mapping)
MSAA опять же (как я понимаю, нормальный MSAA кстати делается в deferred shading, но не делается в light pre-pass - можно сделать почти без артефактов, если light buffer делать MSAA, а в shading pass усреднять семплы из light buffer по input coverage mask),но совсем без - нет)
Самое главное что меня смущает в общем - это набор фич про лайты (типы и свойства).
Есть также опасение что некоторые существующие демки решают что фича про лайты у нас ровно одна, и через это подход работает сильно лучше чем мог бы.
Впрочем, про tile-based deferred shading есть такое же опасение ;)
У меня вроде мысли закончились.
Dmitry Andreev:
а почему смущает? Пейперы эти я не читал, но насколько понимаю там список лайтов по пиксельный. А в этом случае это не сильно от обычного deferred tiled отличается.
Simon Kozlov:
А-а-а--а, deferred tiled.
Dmitry Andreev:
да... там тоже всякие пермутации нужны и на лайты и на материалы и т.д.
это все можно упростить, типа один тип лайти и один матераил как обычно сейчас делают.
Simon Kozlov:
А ты пробовал deferred tiled?
Dmitry Andreev:
я лично - нет, но такое видел как делали в BF3 и тут вроде специалисты были.
Crytek пробовал - но это пиздец геморрой.
но в принциме, в будующем, думаю что это дудет нормально работать.
Arseny Kapoulkine:
Насколько я понимаю, в BF3 как раз tiled только для omni и spots без теней.
Dmitry Andreev:
да.
и один материал.
Arseny Kapoulkine:
Вроде было три? :)
Типа фонг, skin shading и еще какая-то фигня, в презентациях говорили так кажется. Разные SPU kernel permutations кажется по маске...
Dmitry Andreev:
может и 3 (я только один видет пока). Но ну это нахер. Вот как туда что-то новое добавить я не представляю, а COD всеравно выглядит лучше во многих случаях при этом простой как дрова.
Simon Kozlov:
По маске - это в смысле, несколькими проходами?
Arseny Kapoulkine:
Я не очень уверен, мне кажется что нет - что есть вариант SPU shade code который умеет все материалы сразу.
Но можно и несколько раз прогонять специализированные SPU kernels и маскировать результат, это внутренние детали.
Arseny Kapoulkine:
В зависимости от того что понимать под deferred tiled.
Deferred tiled может быть дополнительной фичей.
Типа, пойнт лайты без теней делаем тайлами.
Остальное как обычно.
Это понятно убирает некоторые оптимизации и замедляет некоторые случаи,
но зато разрешает тебе комбинировать.
Список лайтов потайловый, тайлы понятно обычно несколько пикселей :)
Simon Kozlov:
А список bounded?
Arseny Kapoulkine:
В реализациях которые есть вроде ограничивается все в сумме (сумма количества лайтов по всем тайлам); наверное, имеет смысл ограничивать локально чтобы ограничивать артефакты если вдруг.
Simon Kozlov:
Спасибо!
Denis Sladkov:
это тоже интересно. насколько я понимаю, современное железо уже приучено группировать квады с нескольких примитивов в пределах 1 dip? иначе тесселяция должна быть дорогой.
Denis Sladkov:
итого я думаю что оно живуче с точностью до нормального hlsl компилятора (точнее уже линкера лучше)
потому как с DS/DL проблемы г-буфера все-таки кусают. carpaint уже упоминали, туда же skin, да и просто точность представления нормалей в 888 и все crytek-style пляски с бубнами вокруг.
туда же кламп освещения по геометрической нормали (обсуждали с Z с месяц назад тут)
и жирнющий г-пасс вместо легкого как ветерок з-пасса сильно убивает смысл DL, а в DS еще жестче ограничения.
короче пока делаешь tiled DL плавно переползающий в DS, все чаще вспоминаешь старый добрый форвард и думаешь про этот tiled forward.
собсно надо пробовать.
Boris Batkin:
как только появляются тени, становится нефига непонятно - как эти тайлы реализовывать.
Denis Sladkov:
также.
скрин спейс маска для opaque всего. несколько сплитов в атлас для прозрачного.
Boris Batkin:
я про тени на источниках.
иначе зачем огород городить.
Denis Sladkov:
?
Boris Batkin:
ну вот есть иточник света.
у него есть шадоумапа.
вот он попал в список источников света на тайле.
туда надо писать атласовый индекс?
Denis Sladkov:
в источнике света в самом лежит sm mask channel id (swizzle mask) - она юзается совокупно с см-маской для всего непрозрачного.
и атлас индекс - для прозрачного.
Simon Kozlov:
Т.е. тени считаются таки в screen space?
Denis Sladkov:
Ну можно по всякому, но для 90% пикселов так удобнее, фильтр качественнее, память для полного атласа не надо. Для прозрачности тени более халявно атласами можно.
Вплоть до первертекс см маски как в той статье про патиклы с тесселяцией.
Arseny Kapoulkine:
Тогда получается например так - в атлас кладем все SM, но скажем для каскадов можно класть только последний (если они вложенные)
SM маску считаем по атласу плюс доп. каскадам.
Непрозрачные шейдеры читают из SM маски, прозрачные из атласа.
Denis Sladkov:
Ну да, примерно так. В атласы сплиты сохранять в халфрезе ну и можно не все. А 4 или 8 или х каналов см маски хранить - это чисто вопрос перформанса в плане возможности рендерять х см'ов.
Simon Kozlov:
Ага.
Что кстати решает то, о чем говорил Zeux - про невозможность переиспользовать SM.
Arseny Kapoulkine:
Дану.
Оно ограничивает считай 4-мя теневыми источниками (на самом деле 4 per pixel конечно, надо подумать насколько одно в другое транслируется)
Транслируется нехитро.
Правда тогда screen-space blur будет мешать тени от разных источников друг с другом... :)
Denis Sladkov:
Не вижу проблемы сделать больше, но реально и 4 никто не осиливает.
Arseny Kapoulkine:
Ну на текущих консолях да, те лайт листы не про текущие консоли а скорее про следующие :)
Boris Batkin:
ну чо, если-бы не списки. был-бы наверное смысл заморачиватьс.
Denis Sladkov:
можно не списки.
обычные массивы. как в текущем тайловом лайтинге.
проблема только в комбинаторике или цыклах в ps.
ну и вопрос quad overdraw беспокоит.
таки умеют современные железяки объединять пиксель квады с разных примитивов или нет?
Boris Batkin:
умеют.
Denis Sladkov:
круто. я подозревал, но не был уверен.
Boris Batkin:
оно совсем не всегда объединяет, разумеется.
Denis Sladkov:
ну ксенос и рсх совсем не.
а так уже проблема смещается в мультисемплинг, если делать.
в общем надо делать и сравнивать.
Boris Batkin:
мне не нравится. я делать не буду.
мне эти списки с массивами неочевидны. они неплоские.
у меня на всё это есть только одна мысль.
если два лайта не пересекаются в 3д, то их можно рисовать в один color channel.
Denis Sladkov:
ну у меня они уже есть давно, поэтому проще видимо. хз чем неплоские если честно. N битиков на тайл.
Boris Batkin:
списки чем неплоские?
или массивы?
Denis Sladkov:
массивы. зачем списки то?
Boris Batkin:
списки чтобы не выкидывать из тайла по количеству.
неочевидным образом, со стыками.
но списки мне совсем не нравятся.
а массивы имеют свойство быть очень и очень конечными.
Denis Sladkov:
я хз. мне не надо стопицот лайтов никогда было.
64 или 128 на кадр - по зауши.
с учетом окклюжена.
Boris Batkin:
на тайл сколько?
Denis Sladkov:
столько же.
UINT64.
Boris Batkin:
цикл с маской в PS это сильно.
Denis Sladkov:
ну сейчас это не цикл с маской в ps.
цикл без маски в ps - очевидно проще чем списки.
т.е. маску в индексы превратить - не сильно сложно и не сильно больше чем uint64.
Boris Batkin:
ну да.
Denis Sladkov:
я только боюсь компилятора в случае циклов. и чуть еще боюсь комбинаторики в случае unroll по 4 скажем.
но второго в общем-то можно и не бояться наверное.
Boris Batkin:
там битовый фокус нужен, а не unroll.
Denis Sladkov:
битовый фокус? в ps?
Boris Batkin:
а какая разница по какому условию цикл-то.
while ( mask ) ( oldMask = mask; mask &= mask - 1; index = Log2(oldMask ^ mask); }
какая-нибудь вот такая херня.
все до единой операции есть в виде инструкций.
учитывая что маска на много пикселей одинаковая - граблей с созданием 100500 тредов не будет.
GPU скалярные все сейчас, смысла считать по 4 никакого.
как-то так.
Denis Sladkov:
xз. надо смотреть на асм конкретный. счетчик нейтив более-менее был всегда (константный правда в пс3.0)
да, фокус к месту. можно маску и не превращать в индексы, если нейтив инструкции.
по 4 - это не про векторизацию было. а про количество бинарников больше.
в смысле можно и по 3 и по 5. векторизация не нужна - согласен.
Denis Sladkov:
а вот такой вот цикл с while(mask) - он прямо равносилен for(N) на текущем железе?
Boris Batkin:
если N не константа то да.
а если константа - то драйвер типично развернёт.
Denis Sladkov:
ну в нашем случае не константа, да.
а нынче на песи от драйвера можно получить микрокод как-то?
Boris Batkin:
амд-шный тул был какой-то.
вроде.
4 по 16 на флоатах пишется влёт просто.
там как-бы не 24 бита в тот флоат влезало-то таким методом.
log2 и exp2 есть чуть-ли не с 1.1 шейдеров.
Denis Sladkov:
да, можно и по флотам разбить маску. так или иначе метод может оказаться вполне живым.
я убежал.
Boris Batkin:
оно блин даже на флоатах будет работать.