Пятничные факты #251 – Горсть фреймов

Поделиться

опубликовал Klonan

Факторио в Национальной технической библиотеке в Праге (Klonan)

Если вы находитесь в Праге этим летом и хотите насытить свою тягу к Факторио, вы можете зайти в Национальную Технологическую Библиотеку в Праге, где Factorio загружается на 150 компьютеров для всех, чтобы играть. Вход бесплатный для всех посетителей с понедельника по пятницу с 08:00 до 22:00 до 31 августа.  ПК работают на Linux (Fedora), загруженные с помощью специальной сборки игры HanziQ, и вы можете размещать серверы локальной сети и играть со своими друзьями.

23 июля в библиотеке будет проходить наша собственная вечеринка Factorio LAN, которая начнется в 16:00 CEST (время в Праге), чтобы вы могли вместе с нами поиграть. Рекомендуется принести свой собственный набор наушников, если вы собираетесь участвовать.

Оптимизация рендеринга (posila)

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

Но во-первых, нет необходимости изобретать колесо, поэтому давайте посмотрим, как Аллегро делает волшебство. Allegro использует рассылку спрайтов, что означает, что он рисует несколько спрайтов, которые используют ту же текстуру и состояние рендеринга, используя одну команду, отправленную на GPU. Эти команды рисования обычно называются вызовами рисования. Allegro рисует спрайты, используя 6 вершин, и переносит их в C выделенный буфер. Всякий раз, когда заканчивается пакет, он передается в функцию рисования OpenGL или DirectX, которая копирует ее (чтобы не останавливать процессор) и отправлять вызов рисования.

Это выглядит довольно разумно, но мы не можем сделать то же самое, потому что в DirectX 10 нет функций для прямого рисования с C-массивов, и обязательно использовать вершинные буферы. Таким образом, наша первая версия создала буфер вершин, для которого текущая партия всегда копировалась для использования в вызове рисования, и мы перераспределили бы буфер с большим размером, если текущая партия не подходит. Он работал довольно хорошо, вероятно, не так быстро, как версия Allegro, и он заметно отставал всякий раз, когда нужно было изменить размер буфера вершин.

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

Поскольку мы пытались выяснить, как наиболее эффективно использовать данные в GPU, мы также экспериментировали с тем, какие данные отправлять на GPU. Чем меньше данных мы отправляем, тем лучше, и Аллегро использовал 6 вершин на спрайт с общим размером 144 байта. Мы хотели сделать точечные спрайты, которые потребуют всего 48 байт на спрайт и меньше общей математики для процессора для подготовки одного спрайта. Наша первая идея заключалась в том, чтобы использовать instancing, но мы быстро передумали, даже не пытаясь, потому что, исследуя метод, мы наткнулись на эту презентацию, специально предостерегая от использования instancing для объектов с низким количеством полигонов (например, спрайтов). Следующей идеей было внедрение точечных спрайтов с использованием геометрического шейдера.

Мы попробовали, и он отлично поработал. Мы получили некоторое ускорение из-за того, что ЦП должен был подготовить меньше данных, но при исследовании того, как разные API работают с геометрическими шейдерами, мы выяснили, что Metal (и, следовательно, MoltenVK) на macOS вообще не поддерживает геометрические шейдеры. После дальнейшего копания мы нашли статью под названием Почему геометрические шейдеры медленные. Поэтому мы протестировали использование геометрического шейдера на ряде ПК в офисе и обнаружили, что на ПК с новыми видеокартами было быстрее, более старые машины заметно снижали производительность. Из-за отсутствия поддержки macOS и возможного замедления работы на более медленных машинах мы решили отказаться от этой идеи.

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

Следующие результаты тестов относятся к различным компьютерам. Тест показал один кадр при максимальном уменьшении (около 25 000 спрайтов) в 600 раз быстрее, чем без обновления игры, а на графике показано среднее время подготовки и рендеринга кадра. На компьютерах с интегрированным графическим процессором было мало улучшений, потому что они, похоже, были узким местом для GPU.

новый и старый(темнее) рендеринг

Мы также заметили  ускорения на картах AMD по сравнению с картами nVidia. Например, на моем компьютере у меня есть GTX 1060 6GB и Radeon R7 360. В 0.16 рендеринг был намного медленнее на Radeon, чем на GeForce, но с новым рендерером производительность почти такая же (как и должно быть, потому что GPU заканчивает работа быстрее, чем процессор может подавать команды рисования). Затем нам нужно улучшить сторону GPU, в основном чрезмерное использование видеопамяти (VRAM), но больше на эту тему в некоторых будущих пятницах Факты …

Как всегда, дайте нам знать, что вы думаете на нашем форуме.


Поделиться

Комментарии: