[[CCCP] Monster]

Вообще тема про консоли, PC и оптимизацию игр на этих платформах всплыла в разговоре про плановую экономику в разделе "Политика" (не спрашивайте, как это случилось).

Речь там шла вот о чем:

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

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

Но сперва правила темы:
Оффтопом не считается:
1. Обсуждение графики и производительности PC в сравнении с консолями.
2. Обсуждение того, что "вот эта игра могла работать лучше!", при условии аргументации
3. Сравнение характеристик железа (процессоров, памяти и GPU) PC и консолей, консолей и консолей, PC и PC.
__________________________________________________ __________________________________________________ ___________

Итак, действительно ли разработчики игр сговорились с производителями видеокарт, чтобы те могли продавать больше видеокарт и получать больше минералов прибыли?

На самом деле нет. Когда вы запускаете игру, в начале запускается целый ряд заставок в стиле "Коламбия пикчерс представляет", где вы видите лого издателя, разработчика и прочих причастных организаций. И часто в этом списке обитают NVidia и AMD. Это значит, что разработчики обращались к производителям видеокарт, чтобы те сделали их игру более медленной быстрой. Например, NVidia имеет в Москве самый большой офис в Европе, который занимается тестированием и оптимизацией игр. Иногда NVidia или AMD даже приплачивают(!) командам наиболее перспективных тайтлов, чтобы те предоставили исходники своих движков для редактирования, чтобы можно было заставить игру работать быстрее на железе соответствующего производителя. Однако в большинстве случаев оптимизации там получаются довольно общего вида, так что улучшения получаются на всех типах карт. Просто NVidia или AMD имеет возможность еще и подогнать тонкие настройки драйвера (вроде объема CPU-GPU кэша и оптимального размера квантов памяти для обновления содержимого буферов констант, например), что позволяет достичь плавной картинки и оптимального фреймрейта.

Но все же есть подозрения, что разработчики игр делают не все для того, чтобы игра быстро бегала на вашем компьютере, да?

Отчасти это так. Зависит от конкретной команды разработчиков, а именно того, каких программистов они наняли для написания движка (или какой движок они взяли готовым) и как художники распорядились тем, что дали им программисты.

Окей, а как дела с приставками?

Ну, с приставками, на самом деле, в плане железа, все удручающе. Посмотрите вот на этот график:

Скрытый текст:

Здесь показано, чем занимаются создатели видеокарт, пока создатели приставок стригут капусту.
Обратите внимание, что шкала флопсов (от слова FLOPS - Floating Point OPerations - операции с плавающей запятой) - логарифмическая. Это значит, что значение каждой следующей горизонтальной линии в 10 раз больше предыдущего. То есть если GeForce 8800 имел где-то 500-600 GigaFLOP (это миллиардов операций, стало быть), то уже Titan X имеет больше 6000 GigaFLOP, т.е. в 10 раз больше. Окей, и как же на помогут эти флопсы, спросите вы? Да очень просто. Один флоп - это одно сложение, вычитание, умножение или деление, выполненное над некой переменной типа float.

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

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

А нынче ведь все любят уже не Ламберта, а какого-нибудь Орена-Наяра, где можно шероховатость материала указывать.

Так почему же тогда разработчики игр любят приставки больше?

Все из-за вас, маленькие жадные дети(с). Дело в пиратстве. Разработчик хочет кушать, и желательно побольше. Поэтому он хочет продавать свои игры, а за пиратские игры никто ему не заплатит. А на приставках с пиратством все гораздо лучше с точки зрения разработчика.

В этом, кстати, заключается причина, почему часто одни и те же игры на консолях и на PC одинаково выглядят: они просто портированы с консолей. В этом случае в PC-версию можно добавить больше каких-то эффектов, которые не затрагивают ресурсы игры: какие-нибудь HBAO/shadow map based godrays/ ray-marching reflections. Текстуры и модели остаются прежними, поэтому особой разницы не заметно.

Можем ли мы как-то выяснить, хорошо ли оптимизирована игра?

Ну, если вы умеете программировать графику, у вас не maxwell-видеокарта и вы поставили себе NSight graphics debugger, то полагаю, кое-какие выводы сделать вполне получится. Этот дебаггер работает с картами NVidia и может показывать различные данные во время работы игры и выполнять capture frame - получение данных о всех вызовах, выполненных от одного D3D11ImmediateContext->Present() (или glSwapBuffers) до другого. Там можно понять, что рисует игра и как она это делает, сколько времени тратит на выполнение каждой операции, если ли в процессе рендера остановки для синхронизации GPU-CPU (например, когда игра пытается получить результаты GPU-based occlusion culling, и когда она делает это не правильно) и как выглядит шейдер, который выполняется на конкретном этапе, а также можно посмотреть состояние всех ресурсов. Единственное, что удручает - это то, что дебаггер не доступен для работы с видеокартами с архитектурой Maxwell внутри, а это 7хх и 9хх.

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

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

За один раз я их все не опишу, потому буду добавлять по мере поступления вдохновения.

Скрытый текст:

Текстуры
Режимы фильтрации
Вообще в природе есть 4 основных вида фильтрации текстур: метод ближайшего подходящего, билинейная, трилинейная и анизотропная.
Метод ближайшего подходящего для фильтрации текстур на объектах никто (кроме Майнкрафта) уже давно не использует, потому что если подойти к стенке, результат выглядит вот так:

Скрытый текст:

Линейная в этом плане получше. Чтобы ее выполнить, текстурный сэмплер видеокарты читай 4 ближайших пикселя к той точке, которую нужно закрасить, и смешивает их с помощью линейной интерполяции. Результат вот такой:

Скрытый текст:

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

Скрытый текст:

Screen-Space методы
SSAO / HBAO
Screen Space Ambient Occlusion. Особый метод аттенюации итоговой картинки, который затемняет те места, которые закрыты большим количеством объектов.

Впервые техника появилась в Crysis.

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

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

Проблема в том, что для затенения одного пикселя, нужно просмотреть много пикселей вокруг и понять, насколько далеко каждый из них находится от экрана (эта информация у нас есть в Z-буфере). Чем больше пикселей осмотришь, тем лучше будет результат. Но это очень сильно пожирает ресурсы: чтобы отойти от закрашиваемого пикселя на 2 пикселя в каждую сторону (pixel kernel 5x5), нужно осмотреть 25 пикселей. Чтобы увеличить радиус до 4 пикселей вокруг, нужно осмотреть в общей сложности 81 пиксель.

Выглядит результат вот так:

Скрытый текст:

[[CCCP] Monster]

lYXl, окей, давай посчитаем: в случае обычного инстансинга у нас получается количество drawCalls как количество уникальных объектов * количество лодов для каждого из двух типов возможных объектов в deferred shading (непрозрачных и прозрачных), для каждого рендер-таргета (в том числе тени и прочее), это умножить еще где-то на 4-8. Причем прозрачные и непрозрачные ты даже в forward-rendering все равно сортируешь, потому что, например, растения имеют попиксельную прозрачность, что заставляет перейти с Early-Z на Late-Z, и обратный переход, если ты вызовешь после листвы рендеринг чего-то непрозрачного, это вызовет GPU-stall пока все Late-Z процессы дальше по конвейеру не завершатся.

Но у нас количество самих объектов (например, деревьев), обычно сильно больше, чем всех этих draw-calls вместе взятых, и их надо отсечь из области видимости, поэтому самым тяжелым тут являются не вызовы отрисовки, а отсечение, и именно они делают большинство игр CPU-Bound. В таких случаях каллинг выводят на GPU, и поскольку данные уже оказываются там, использование indirect-вызовов как-то само собой подразумевается. А индиректы хороши тем, что минимизируют необходимый размер стейта для передачи в драйвер, и соответственно, занимают меньше времени.

Единственный оставшийся случай, когда сам по себе draw-call является очень медленным и потому приложение упирается в CPU, это когда у тебя DX9/XNA. Там да, даже с инстансингом все будет плохо.

[lYXl]

Было бы интересно мнение по DX12 и Metal API. Или с выходом Vulkan они уже никому не будут нужны, кроме их же разработчиков? Что-нибудь удалось опробовать лично из перечисленных API?

[lYXl]

Если кто не видел: https://vc.ru/p/unity-pics
Статья про то, как происходит отрисовка кадра на примере Unity.

[VirtTrans]

Оптимизация

Забудьте это слово на ПК. Ваша оптимизация это новая видеокарта каждые 3-5 лет.

[Zasranec]

Может немного не в тему, но недавно с удивлением обнаружил, что просадки fps были нормой и на 6-м поколении консолей (XBOX, PS2, GamuCube), хотя раньше как-то не обращал на это внимание. Особенно сильно в глаза бросились тормоза в первом KotOR на XBOX'е. Хотя тот же Doom 3 на нём (в принципе, как и Doom 3: Resurrection of Evil) идет очень даже неплохо. А Far Cry: Instincts - просто шикарно. Все-таки что ни говори - железо железом, а ровные руки у программистов решают.

[кук]

Zasranec, на Деньди так же есть пачка игр с плохой оптимизацией, как например Contra force или Panic restoration и еще других. Так, что да, кривые руки всегда встречались.