http://public.closedcircles.com/posts/few-minute-problem

http://public.closedcircles.com/posts/tiled-forward-rendering

http://public.closedcircles.com/posts/wwdc-followup

Взрослею, наверное.

GDC 2014: Мелочи про F2P games

GDC 2014: Rendering in Ryse
Долгий и подробный рассказ про устройство рендера в Ryse от Crytek. Много мяса про Physically based rendering, персонажей, итд итп.

GDC 2014: Umbra Internals
Про детали использования Umbra, популярного middleware для расчета видимости объектов в реалтайме, в Witcher 3: Wild Hunt. Деталей значительно больше, чем в брошюрках Umbra, полезно и даже если вы его не используете.

Я часто рассказываю, что пришел в Windows Graphics в замечательный момент – Windows в целом перестал беспокоиться про трехмерную графику и геймдевелоперов. Не все в мире получили memo, но вот DirectX SDK снова вышел не раз в три месяца, а раз в три года, и многие стали что-то подозревать!

И вот ситуация разворачивается, так что похоже и ушел я из MS тоже в замечательный момент – DX12 решает вполне актуальные проблемы. Не знаю, как там у мужиков мысленный процесс работает, но кажется, что это реакция прежде всего на независимые инициативы AMD и в некотором смысле NVidia в мире PC, а не на конкуренцию со стороны Мака и мобильного мира.
Хотя казалось бы, беспокоиться-то надо про второе.

Итак, будет DX12 и он очень напоминает AMD Mantle. OpenGL тоже не стоит на месте, но пытается решить те же проблемы совсем другим способом.

А теперь подробнее.
Начинать читать лучше с замечательного рассказа Zeux про проблемы текущего состояния вещей:

http://public.closedcircles.com/posts/gdc-2014-mantle-directx12-and-dip-cost

В частности, потому что он не только о будущих графических API, а о том, почему все так плохо в текущем положении вещей. История графических API на PC/Mac – это история наслаивающихся абстракций, яростной эволюции железа под этими абстракциями, legacy, длящейся 10 лет итд итп. Про какую-то ее часть этой истории я писал тут и тут.
И вот стоимости этих абстракций постепенно накапливалась и накапливалась эти 10 лет, причем все это время все участники экосистемы в меру сил старались этому противостоять – и оптимизировали игры, и драйвера, и прослойку в операционной системе.
Тем не менее, имеем что имеем – ситуация очень показательная.

Далее есть отдельные детали про DX12 и OpenGL:
http://public.closedcircles.com/posts/gdc-2014-directx12
http://public.closedcircles.com/posts/gdc-2014-optimizing-driver-overhead-in-opengl

В общем, это все здорово, позитивно и должно было блин случиться 5 лет назад. Ох, как бы опять не получилось too little too late у родной компании.

Надо иметь ввиду, у меня несколько искаженная перспектива, я все время смотрю на платформу в целом, не только на клиентскую часть.

GDC 2014 Unity dev day: Introduction
GDC 2014 Unity dev day: New lighting pipeline
GDC 2014 Unity dev day: Export to WebGL

Мне самым значительным показался экспорт в asm.js и WebGL, но он к сожалению всем будет доступен нескоро. Обратно, от Unity Cloud у меня впечатление, что там надо очень много работать. У Unity совершенно замечательный тулсет и рантайм для клиента, а вот в так называемое облако и паблишинг делаются только первые шаги.

Все оттуда можно и нужно к себе утаскивать, постить куда-то ссылки, итд итп.

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

Мы там начали выкладывать записи с GDC 2014 – @zeuxcg ходил на много докладов и я на чуть.
Сейчас выложены транскрпиты с дня Advanced Visual Effects, дальше будут записи с Unity developer day и отдельные доклады.

GDC 2014: GPU Particle Systems
GDC 2014: DX11 Software Tesselation
GDC 2014: Vertex Shader Tricks
GDC 2014: Efficient Work Submission in Direct3D
GDC 2014: Yet another Tesselation Talk
GDC 2014: Using DX11.2 Tiled Resources
GDC 2014: Grass, fur and hair
GDC 2014: Tesselation in Call of Duty: Ghosts

Ну и бонус:
GDC 2014: PowerVR raytracing

Самое важное событие – пожалуй, анонс и сам факт существования DirectX 12. Следите за апдейтами!

Алсо, прикрутил по случаю на http://blog.gamedeff.com Disqus comments, комментировать должно стать гораздо проще.

People in this conversation:
Arseny Kapoulkine (Zeux) Add
CREAT Studios, Saber3D, Sperasoft (EA Sports – FIFA). Currently making kids happy at ROBLOX. http://zeuxcg.org/

Zeux: DirectX 11 Performance Reloaded – Nick Thibieroz (AMD) and Holger Grun (NVIDIA)
Парни из AMD и NVidia рассказывали про то как сделать так чтобы в вашей directx11 игре (если она у вас случайно таки есть) было все хорошо с производительностью – с точки зрения CPU и GPU. Большинство из рассказаного уже было упомянуто в различных talks, большинство советов были универсальны (NV/AMD), про часть была конкретика по вендорам. Поскольку куча материала уже где-то была, я выпишу то что почему-либо отметил.

При создании шейдера драйвер выполняет трансляцию из D3D микрокода в GPU-specific, при большом количестве шейдеров это может отнимать время.
Общая рекомендация – создавать шейдеры заранее (сильно до отрисовки) и с нескольких потоков.
Выглядит так, что у NV компиляция примерно в момент CreateShader, а у AMD в момент CreateShader в один из драйвер тредов делается schedule job на трансляцию
Общая рекомендация про остальные ресурсы – создавать их из нескольких потоков, чтобы у драйвера было больше возможности параллелизации.
В d3d11 рантайме есть способ проверить, поддерживает ли драйвер такое эффективно
См. D3D11_FEATURE_DATA_THREADING

При создании ресурсов традиционно флаги биндинга надо стараться ставить те какие понадобятся
Особенно были выделены флаги RENDER_TARGET и UNORDERED_ACCESS.
Если их ставить ресурсам которые в этих возможностях не нуждаются, будут лишние overheads.

В дополнение к стандартным советам про группировку констант в constant buffers по update frequency прозвучали следующие:
- С доступом к CB связан некий оверхед, поэтому количество CB привязанных к пайплайну следует ограничивать, было рекомендовано <5.
Это связано в основном с каким-то фиксированным overhead, а не с паттернами доступа, вроде как.
- Для улучшения локальности доступа к константам надо стараться читать из одного CB в следующих друг за другом инструкциях

Occlusion Queries рекомендовано использовать ограничено, было названо число несколько сотен на кадр.

При работе с динамической геометрией, традиционно рекомендуется использовать DISCARD + NOOVERWRITE.
Дополнительные советы:
- Не обязательно каждый кадр звать DISCARD если буфер используется как стек - достаточно звать при переполнении, это может происходить реже чем 1 раз за фрейм
- На AMD рекомендуемый размер буферов которым делается DISCARD - 4 Mb и меньше
- На NV специальных ограничений на размер нет, но есть фиксированное ограниченное количество discard-ов на кадр, после которого все становится медленно (CPU-GPU синхронизации)

Оптимизация vertex fetch/shade стадии:
- Традиционно, чем меньше читаем на vertex fetch тем лучше - это значит минимизируем количество input атрибутов в декларации (layout), и по возможности распиливаем стримы (например, атрибуты вертекса для depth-only render и все остальное)
- Традиционно, чем меньше пишем из vertex shader тем лучше - на NVidia вроде просто линейная зависимость скорости от размера, на AMD есть магическое число в 4 float4 атрибута, на котором (и меньше) скорость оптимальна
Поговорили про тесселяцию, highlights которые я запомнил:
- В hull shader бывает полезно делать frustum & back-face culling вручную для патча, чтобы не тратить время на тесселяцию - fixed-function culling работает сильно позже
- Фактор тесселяции >15 на AMD использовать не рекомендуется из соображений скорости
- Как известно, у миллионов маленьких треугольников проблемы с производительностью; было названо число 10-16 пикселей на треугольник как качественное.
Как обычно, чтобы его добиться нужна адаптивная тесселяция (зависящая от расстояния, величины требуемой деформации итп)

Поговорили про geometry shaders, все как обычно – если можете не использовать то лучше не используйте
Если не можете то пишите фиксированное (маленькое) число данных
На AMD есть специальный fast path
На котором GS invocations выдают один и тот же render target index
Если не один и тот же то медленнее.
GS invocations с одного входного примитива.

Поговорили про глубину, на NVidia рекомендуют использовать D24 для скорости (не D16 и не 32-битные форматы)
И при работе с одним буфером глубины не использовать depth test разных направлений (greater/less), иначе ломается early z reject
На AMD рекомендуют использовать D16 глубину для шадовмап.

У обоих вендоров discard/alpha test убивают ранний fine-grained (попиксельный) z test, но оставляют coarse grained
У обоих вендоров depth output в пиксельном шейдере убивает и fine grained и coarse grained early z test
Про консервативную глубину почему-то сказано не было.

Ну и наконец, при работе с MSAA в случае, если есть post-process pass который читает из одного семпла все время, рекомендуется сначала этот семпл зарезолвить в non-MSAA texture, а потом читать из нее – cache coherence лучше при нескольких выборках.
У меня все про этот доклад.

А, там еще авторы пытались рассказывать про deferred contexts, но у них не очень хорошо получилось – лучше получилось у автора тематического доклада, про который я скажу.
Было сказано еще что типично драйвер генерирует команды для GPU в отдельном потоке, и рендер тред с API вызовами выступает как producer команд, так что если у вас между API вызовами много своей какой-то работы типа стейт менеджмента или прочего рендер кода
То драйверный тред слишком много ждет, что плохо – хорошо это когда вы генерируете работу для драйвера быстрее чем он ее может обрабатывать.
Для @Simon – я тут специально все пишу в normal mode, если ты ответишь repost то наверное будет максимальный exposure

Так, здесь еще пропустил про апдейт текстур.
Если у вас есть динамическая текстура, то:
- При ее апдейте пытайтесь обновлять ее целиком или, в случае 3д текстуры, целый слайс. Иначе есть риск нарваться на не оптимальный codepath в драйвере.
- Map на динамические текстуры в целом не рекомендуется, т.к. по контракту API вам выдадут указатель на линейную память (строчки друг за другом в памяти), а на самом деле с высокой вероятностью текстура в памяти лежит в другом формате, тайликами – поэтому драйверу придется ее конвертировать после Unmap (и при Map если не discard/write-only…)

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

А вот для вдохновения и забавных техник ознакомиться вполне полезно. Epipolar space вообще колбаса – как обычно оказывается, что есть куча интересного неиспользуемого матаппарата.

People in this conversation:
Simon Kozlov Add
Engineer at ROBLOX (www.roblox.com), previously at Microsoft. And ClosedCircles was my idea.
Boris Batkin Add
i press buttons for living. u can call me god
Artem Brizitskiy (art321) Add
хуятор в uber команде Naughty Dog
Santa Monica
Roman Galashov (RomBinDaHouse) Add
Il-2 Sturmovik: Birds of Prey (Art Director);
Skyforge (TA)
Yury Degtyarev Add
Graphics programmer at Transas New Technologies

Simon Kozlov:
Кстати, пока не забыл. Напоследок я ходил на GDC на доклад некого Егора Юсова из Интела про light scattering
http://software.intel.com/en-us/blogs/2013/03/18/gtd-light-scattering-sample-updated
Вот тут есть скриншоты
Такая забористая полуакадемическая трава, я прямо представил себе себя 7 лет назад на Графиконе
Впрочем, мои облачка были зубодробительно простыми “палка-палка-веревка”, а тут академия без хороших артистов

Я попробую воспроизвести часть рассуждений и оптимизаций
(кстати, очень хорошая презентация, там хоть и дохера интегралов и прочего матана, очень классно и последовательно появлялись формулы и шаги в рассуждениях – буду у докладчика учиться)
У него где-то слайды кстати должны были быть…

Ну в общем, он начинает с рассмотрения интеграла для light scattering
Там, понятно, есть вклад от отраженного света объекта + вклад от всех частичек на луче до объекта
Каждая частичка отражает часть света источника в направлении камеры
От плотности частиц, распределения отраженного света и расстояния до частиц (потому что свет рассеивается) складывается финальный цвет
Одни частички – Rayleigh, другие частички – Mie
Этот интеграл решается в аналитической форме для направленного источника и не считается для точечного

Его новшество начинается с того, что он хочет учитывать затенение
Типа, вот у нас есть shadow map, давайте учитывать рассеяние только на тех частичках, которые не в тени
Давайте вот для каждого луча из камеры найдем незатененные depth ranges
И посчитаем вклад интеграла только в этих ranges
По-прежнему, для направленного источника есть аналитическая формула, для точечного – он придумал предрассчитать 2D LUT, чтобы можно было зная начало и конец вычесть-умножить и получить вклад

Дальше идут оптимизации. Если тупо посчитать такой raycast через shadow map для каждого пикселя – получается 91 msec на последней NV карточке в типичном разрешении
Первая мысль – давайте считать не для каждого пикселя, а только для некоторых, а остальное интерполировать
Какие пиксели важные? Давайте трансформируем все в забавное “epipolar” пространство, где лучи от солнца становятся параллельными
Мол, наблюдение такое, что вдоль этих лучей освещение меняется плавно
Поэтому интерполировать лучше в нем
И вот возьмем там сэмплы вдоль лучей от солнца + где есть depth discontinuites
Т.е. проанализуем depth buffer и в местах, где он сильно отличается добавим сэмплов
Считаем для этих пикселей честный трейс через shadow map
А остальное интерполируем

Вторая ключевая оптимизация, типа – этот самый трейс через shadow map, т.е. нахождение отрезков где луч “не в тени”
Используют технику для height map min/max mipmaps
Мол, если есть мипмапы, можно искать промежутки быстрее (я могу подробнее, если интересно)
Ну и остальное мелкая техника

В общем, основные идеи – интерполировать в специальном пространстве, пользуясь тем, что лучи исходят от источника, добавлять depth discontinuities как сэмплы и для трейса лучика через shadow map использовать height map min/max mips
Говорит, получается 2 мсек на топовой NV карте, 8 msec на последнем поколении Интела
Но в общем какие-то идеи в сильно упрощенном виде можно и использовать, если хочется очень крутых light shafts

art321: егора я знаю. я с ним работал. у чувака есть еще мега текстуринг с теселяцией и изменяющимся ландшафтом и все это работает на интегрированной графике. я постараюсь его на кружечки пригласить. чувак этот лайт шафт пишет оч долго мы сравнивали с нвидией у него было значительно быстрее. апдейт презентации не видел но вроде сценка в 2008 году была моя для этой штуки(ну надоже похвастаться)

Simon Kozlov: Да, ты там был в списке благодарностей в конце слайдов
На первом месте!

art321: круто, не знал

Simon Kozlov: Я на всякий случай уточню, что “без хороших артистов” – я имел ввиду, что эффект не фейкается как всегда артом, а почти честно считается

art321: туту смысл был не сделать клево а сделать честно (нахрена -хз ) интел платит че…

Simon Kozlov: Да-да. Т.е. никакая игровая компания бы такого не делала

art321: ну и мегатекстуринг для интегрированной графики – тоже изврат )

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

Yury Degtyarev: кто хочет ознакомиться с тесселяцией, есть его статья в GPU Pro 3
ты тоже там в Acknowledgments :)

Boris Batkin: гляжу в презенташку и понимаю что кодить я такое не возьмусь в том виде, в каком да

Simon Kozlov: О, а ты нашел линк на слайды?

Boris Batkin: только на демо покамест.
там прям в шейдере картиночки пиксельартом
даже прям интересно – в чём рисовалось. не поверю что руками

Simon Kozlov: emacs поди!

Boris Batkin: интересно было-бы сравнить визуально и по производительности с тем, какое в GPU gems 3

Simon Kozlov: А какое там?

Boris Batkin: http://http.developer.nvidia.com/GPUGems3/gpugems3_ch13.html
тупое как пробка

Simon Kozlov: Я пробежался и не очень понял идею
Вот он там пишет классическую формулу из Hoffman and Preetham и говорит, надо учитывать для точки volumetric shadow factor
Какая точка имеется ввиду? Каждый пиксель на экране?
Вот луч улетел в бесконечность на far plane – какая это точка в world space?

Boris Batkin: если в бесконечность то вроде никакая
так вроде все пиксели на экране

Simon Kozlov: Ну а должна быть
Там же может тоже быть light shaft

Boris Batkin: значит я тоже что-то не понял
но глядя на картинки не уверен что хочу понимать

Simon Kozlov: Ну короче, это такой хак – он трейсит луч в 2D к источнику и смотрит, сколько окклудеров он пересечет
Если пересек что-нибудь – значит там shaft!
Совершенно без всякой физики, молодца
Впрочем, если ему надо на каждый пиксель трейсить – то можно подразогнать с теми вон интерполяционными идеями

Boris Batkin: в GPU-gems сделано так. трейсится в 2д от точки до источника. и суммируется. всё это медленно экспоненциально затухает
вопрос
чем оно отличается?

Simon Kozlov: Ну, многим. Повторюсь – вот луч улетел в far plane, от какой точки ты трейсишь до источника?

Boris Batkin: в 2д-то?

Simon Kozlov: Да

Boris Batkin: от каждой точки экрана до источника

Simon Kozlov: Ну и берешь черно-белый фактор?
Это такой хак
Очень практический, не имеющий отношения к тому, как свет распрострянется

Boris Batkin: в смысле чёрнобелый? я бы брал light * diffuse
в дефферед
прям как есть

Simon Kozlov: Ну это же может быть occluder, который вообще не на луче
Здание впереди
Оно же никак не может загородить твой воображаемый луч из точки в мире до источника
У чувака происходит более-менее корректное вычисление света
Он идет по лучу до каждой точки в shadow map space
И смотрит по этому лучу, что затенено
И там где незатенено – считает вклад от освещения в этом отрезке
Понимаешь? Трейсит по лучу до точки, не от точки до источника в 2D

Boris Batkin: т-е берёт все точки shadowmap-а
в 3д
трейсит по лучу до источника 3д
?

Simon Kozlov: Не трейсит до источника, вообще
Берет луч от камеры до пикселя
Растеризует этот луч в shadow map space
И по этому лучу в shadow map “трейсит”

Boris Batkin: вот теперь понял

Simon Kozlov: То есть, они считают совершенно разные суммы и факторы
У чувака из Интела много корректнее
Надо ли – скорее всего нет!
Чтобы быстрее работает – тоже вопрос, кстати
Потому что он этот трейс делает для маленького количества пикселей
Сильно меньше, чем родное разрешение

Boris Batkin: ну их оба можно в неродном очевидно
по одним и тем-же причинам

Simon Kozlov: Да, разумеется
Но в статье из GPU Gems про эту оптимизацию не было
Я почему и говорю, что некоторые идеи можно в каком-то виде использовать
Он типа предложил пространство, в котором интерполируется сильно лучше, чем тупо downsample
Такая нелинейная трансформация, хорошо коррелирующая с вкладом, который ты считаешь

Boris Batkin: подумал. разница будет в том, что если здесь источник не видно – то шафты всё равно будут
а если там источник не видно – то и шафтов не видно

Simon Kozlov: Там – это в GPU Gems?
Да будут наверно
Хотя зависит как считают
Если аккумулируют по 2d лучу – то не будет, да

Boris Batkin: там? там в 2д трассируют из точки экрана в точку где луч
и суммируют

Simon Kozlov: Если вклад следующего сэмпла на основе предыдущего – от не будет
А если каждый независимо – то будут какие-то, наверное
Посмотрел на код, каждый независимо
Будут какие-то шафты

Boris Batkin: ну там как только появляется “солнце” – яркий такой луч
а если нет – то блееееееееееееклый

Simon Kozlov: Ага
Ну от коэффициентов затухания зависит
Практический метод – надо настраивать слайдерами :)

Boris Batkin: блин. щас сяду вкодаю его тупо
чтобы “заценить”
у меня правда готовых сцен с “солнцем” нет
но я это дело поборю

Simon Kozlov: У чувака из Интела в демке какая-то сцена

Boris Batkin: у него там .mdl и .mtl файлы
надыть найти конвертор в колладу. подумав – не щас, через недельку
мне как раз есть куда такой эффект сунуть
мне идея трассировать по shadowmap понравилась
в таком раскладе понятно, что делать с лучами – какие упёрлись в far plane
их надо тупо обрезать по zfar последнего каскада
если тени каскадные
можно даже отдельно по каскадам рисовать. там-же интеграл
получается вполне себе луч znear-zfar
для каждого каскада
не, вообще хорошая идея.
надо будет её покурить

Yury Degtyarev: Например, для объёмных теней в частицах. Если делать просто попиксельный/повертексный shadow-лукап в шейдере частиц, то получится говно. Правда 2мс все равно многовато сейчас.