КРИ-2009. День первый.

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

Стендов очень мало. Народу тоже сильно меньше, чем в 2005. WiFi'я нет. Вернее есть, но какой-то Comstar за деньги, это не интересно.

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

После посещения КРИ вы твердо усвоите одну вещь - Аструм нанимает.

Об этом висят плакаты у входа, рекламные листовки кидают в пакет участников. Объявления висят даже на дверях туалета. HRы Аструма сидят в отдельном зале (!). Меня этот факт несколько удивил. Обычно на конференциях запрещают хантить народ, потому что тогда компании отказываются присылать туда своих сотрудников. На HighLoad2007 очень по этому поводу наезжали на Яндекс, даже заставили убрать один слайд.

Собственно доклады, на которых я была сегодня.
Илья Пшеничный, Creat Studios
Разговоры про жизнь

Илья попробовал активно в доклад вовлечь зал. Программеры из зала реагировали вяло, доклад тянулся медленно. Но зато доклад отличался от других, потому Илье бонус за смелость. Что запомнилось из полезного - рассказал, что FMOD+многопоточность - это тяжело, что просто так Хавок для физики машинки прикрутить не удастся, надо будет много тюнить...

Александр Лазарев, Intel
Многопоточный интеллект - это победа! Построение N-поточной масштабируемой оболочки.

На синтетическом примере показывал, что код AI можно распараллелить. Меня по этому поводу обеспокоил один вопрос - как это все отлаживать. Александр посоветовал Intel Thread checker и добавил, что да, проблем прибудет, потому решение параллелить AI должно быть очень оправдано.

Задача Интела понятна - им надо железо и тулзы продавать. И железо, и тулзы у Интела традиционно хорошие. (Intel vTune - супервещь). Но распараллеливая AI вы открываете ящик Пандорры. И оттуда такое полезет - мало не покажется. И отлаживать код придется вам, а не Интелу.

Арсений Капулкин (AKA Zeux), Creat Studios
SPU Render
Гвоздь программы. Большой подробный рассказ по делу, поэтому тут будет много.
Вообще обычно организаторы выкладывают записи выступлений на КРИ и это тот случай, когда доклад следует послушать целиком, а не довольствоваться перессказом. Мой перессказ - он для того, чтобы понять интересна вам вообще эта тема или нет.
Zeux сказал, что доклад большой, слайдов много и времени на вопросы не останется. И понеслась.
Если совсем кратко, то доклад о том, как в игре Smash Cars 2 под PS3 код рендеринга переносили с PPU на SPU.

Рендеринг, который работал на PPU, занимал 12 ms. Что было много и они решили перенести его на SPU.

Немножко информации про SPU, чтобы дальше было понятнее. SPU всего шесть штук. Речь идет о работе на одном из них. У SPU есть Local Storage (дальше LS) 256 Кб памяти под код и данные. Код не может работать с данным, которые лежат не в LS.
256 Кб - это не много, но у них код занимал максимум 80 Кб в дебаге, так что все влезало.
Доступ к внешней памяти через DMA.

Перенос кода происходил в три этапа.

Этап 1. Собрали прототип.
Цель - чтобы рендеринг заработал хоть как-то. Использовали пока синхронные DMA вызовы.
В силу особенностей архитектуры возникли проблемы с виртуальными фукнциями и инкапсуляцией. С тем, что vptr'ы не туда показывали, разобрались так: вообще отказались от виртуальных функций и использовали enum'ы.
Проблему с инкапсуляцией решили волшебной строкой

#define private public

Как происходит синхронизация PPU и SPU. У них PPU всегда ждет SPU. А SPU - достаточно быстрый.

Этап занял 3 дня. Время рендеринга 25 ms.

Этап 2. Оптимизация данных
Синхронные DMA вызовы, понятное дело, тормозили.
Начали они с того, что переуложили данные, чтобы их можно было загрузить все за один запрос. Сделали software cache. И сделали вызовы DMA асинхронными. В процессе работы время рендеринга уменьшилось сначала до 12ms, потом до 8ms. Сколько времени заняла работа не помню, по-моему тоже 3 дня.

Этап 3. Оптимизация кода.
Использовали SNTuner, SPUsim.
Этот кусок доклада похож на экскурсию в восьмидесятые. Использовали loop unrolling, branch flattering, ибо ветвления дорогие и они пытались уменьшить их число. Заменили switch по числам 0..N на function pointer table, получили ускорение в полтора раза.
Еще использовали branch hinting, который Zeux назвал шагом отчаяния и который принес десятипроцентный прирост производительности. Для branch hinting есть такой gcc-specific синтаксис, который говорит, что "вот этот if скорее всего не сработает".
Меняли работу с LS. Запись/чтение только по 16 байт.
Времени это у них заняло 5 дней. Время рендеринга стало 2 ms.


Итог дня: без WiFi'я плохо, Creat - молодцы.