Почему при 200 FPS игра лагает и зависает

Средний показатель FPS порой абсолютно оторван от реальной визуальной плавности. Даже если вы собрали ультимативный ПК и монитор фиксирует железобетонные 180 кадров в секунду, картинка все равно может прерываться микрофризами. Человеческий глаз чувствителен не к их количеству, а к стабильности интервалов между генерацией. Усредненная статистика надежно маскирует эти перепады. Следовательно, анализировать нужно иные параметры. Но какие именно?

Хотя понятие «лаги» используют для всего подряд, технически они делятся на три независимые категории: подергивания видеоряда, отзывчивость управления при визуальной гладкости и сетевые телепортации в онлайн-баталиях. В данном материале мы сфокусируемся на первом и частично на втором аспектах. Высокий пинг и потеря сетевых пакетов — совершенно иная плоскость, которую счетчик кадров вообще не фиксирует.

Какие инструменты задействовать для диагностики

Для оценки стабильности вывода кадров необходим специализированный софт. Оптимальным выбором станет проверенная связка MSI Afterburner и RivaTuner Statistics Server, которые устанавливаются вместе и настраиваются за считанные минуты.

Инсталлируем утилиты, открываем параметры мониторинга, отыскиваем пункт Frametime (время кадра). Активируем его, ставим галочку напротив «Показывать в ОЭД» и переключаем режим визуализации на график.

• Прямая линия с минимальными зубцами свидетельствует об идеальной стабильности — можно продолжать сессию.

• Частый «частокол» указывает на микрофризы. Кадры поступают неравномерно, хотя усредненный FPS держится на высокой отметке.

• Единичные пики, уходящие под потолок, означают кратковременные замирания картинки, воспринимающиеся как слайд-шоу.

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

Здесь доступны два основных инструмента:

• Первый — CapFrameX, функционала которого хватает с избытком для большинства сценариев. Софт фиксирует тайминги каждого кадра за время игровой сессии, самостоятельно рассчитывая перцентили и демонстрируя графики распределения. Достаточно запустить логирование, поиграть несколько минут и остановить запись — программа выдаст готовый аналитический срез.

• Второй вариант — решение PresentMon от Intel. Оно считывает телеметрию напрямую из системного конвейера Windows, приближаясь к «железному» уровню и разделяя время генерации кадра между центральным процессором и графическим чипом. Это позволяет точно определить слабое звено. Правда, интерфейс утилиты спартанский, а интерпретировать собранные данные придется самостоятельно.

Стоит учитывать важный нюанс: для корректного расчета показателя 0.1% low требуется внушительный массив данных. Тестирование длительностью в тридцать секунд зафиксирует лишь горстку кадров, и любая случайная микропауза исказит статистику. Уделяйте заездам не менее пары минут, проводя тесты в динамичных игровых ситуациях, а не в пустых коридорах. Проводите замеры циклично: при сильном разбросе результатов верить им пока рано.

На какие метрики опираться и что они означают

Рано или поздно графики уступят место конкретным цифрам. Программы обычно оперируют тремя ключевыми параметрами:

• Средний FPS. Демонстрирует производительность системы, но умалчивает о плавности. Релевантен исключительно для сопоставления различных графических настроек.

• 1% low. Усредненное значение для одного процента наиболее медленных кадров. Фиксирует регулярные просадки: подгрузку текстур при перемещении, перегруженные спецэффектами сцены или дефицит процессорной мощности.

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

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

Разрыв между двумя последними метриками колоссален. Если игра зависла на 300 миллисекунд единожды за весь вечер, на 1% low это почти не повлияет — один кадр растворится среди десяти тысяч. Зато в графе 0.1% low этот сбой проявится во всей красе.

Универсальных референсных значений не существует. Колебание в две миллисекунды ощущается совершенно иначе при 240 и при 45 кадрах в секунду, к тому же многое зависит от специфики движка. Оценивайте динамику изменений относительно ваших собственных замеров до и после оптимизации.

Впрочем, критические проблемы заметны и без утилит: средние 120 FPS при просадках 1% low до 40 говорят о трехкратном разрыве, указывая на серьезные проблемы с ритмом генерации.

Почему задержка одного потока тормозит весь конвейер

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

• Игровой поток (Game thread) — рассчитывает логику мира: тики сущностей, физические взаимодействия, анимации, пользовательский ввод и алгоритмы искусственного интеллекта.

• Поток рендеринга (Render thread) — транслирует сцену в инструкции для видеокарты: отсекает скрытые объекты, настраивает материалы и формирует вызовы отрисовки (draw calls).

• Графический чип (GPU) — исполняет полученные команды.

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

Однако на практике сценарий выглядит иначе. Предположим, логика отработала за 5 мс, рендер — за 4, а GPU потребовалось 15 мс. Сколько займет формирование кадра? Правильно, все те же 15 мс, поскольку конвейер подстраивается под скорость самого медленного элемента.

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

В проектах на базе Unreal Engine эту статистику можно вывести прямо во время игры. Открываем консольную строку, вводим командный запрос stat unit, и в углу монитора появляются четыре строки:

• Frame — суммарное время подготовки кадра, от старта симуляции до вывода на дисплей.

• Game — временные затраты логического потока.

• Draw — нагрузка на поток рендеринга.

• GPU — время работы видеокарты.

Далее сопоставляем показатели: тот из трех последних параметров, чье значение ближе всего к общему времени Frame, и выступает в роли узкого горлышка (bottleneck).

• При значениях Game — 18, Draw — 8, GPU — 12 лимитирующим фактором выступает процессор и логика, поэтому замена видеокарты не принесет результата.

• Если Game — 8, Draw — 6, GPU — 20, упирается производительность графической подсистемы.

Для отслеживания непостоянных фризов вводится команда stat unitgraph, выводящая телеметрию в виде графиков, где пиковые нагрузки видны мгновенно.

Экспресс-диагностика за пару минут

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

Пройдите один и тот же игровой отрезок дважды и оцените результат:

• Подергивание зафиксировано исключительно при первом прохождении — перед нами компиляция шейдеров. Сгенерированный объект сохранился в кэше и повторно не просчитывается.

• Рывки стабильно повторяются в конкретной точке — это подгрузка ассетов (traversal stutter). Граница стриминга пересекается при каждом приближении, вызывая повторную нагрузку.

Для проверки шейдеров существует надежный метод. Скомпилированные данные драйвер видеокарты сохраняет в локальный дисковый кэш, переносящийся между сессиями. Очистите его, и объекты соберутся заново.

Нужная опция находится в панели управления драйвера: у NVIDIA это кэш шейдеров, у AMD — аналогичный параметр в фирменном ПО. Сбросьте кэш и повторите маршрут. Возникли фризы на тех же участках? Диагноз подтвержден — это компиляция.

Причины появления компиляции шейдеров

Если диагностика выявила компиляцию шейдеров, это скорее позитивный знак. Сохраненный в кэше объект не потребует повторной сборки в будущем. Прошли локацию один раз — впредь этот участок будет работать безупречно.

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

Архитектура Direct3D 11 функционировала иначе. Процесс компиляции никуда не исчезал, но драйвер маскировал его от пользователя, принимая команды по отдельности и достраивая их перед выводом. В Direct3D 12 и Vulkan управление конвейером переложили на плечи игрового движка. Состояние конвейера упаковывается в неизменяемый объект Pipeline State Object (PSO), который должен компилироваться заранее.

Концепция PSO задумывалась для устранения компиляции из игрового процесса: выполните предварительную сборку при загрузке, чтобы в динамике не тратить на это ресурсы.

Однако на практике все пошло не по плану. API Direct3D 12 вышел в 2015 году, но разработчики движков освоили новый механизм далеко не сразу. Реорганизация существующих систем материалов оказалась сложнейшей задачей, да и архитектурные изъяны API проявились со временем. Годами студии выпускали проекты, где объекты PSO создавались по факту обращения в реальном времени.

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

Почему нельзя скомпилировать абсолютно все на старте

Главная преграда — колоссальные объемы данных. Статистика Epic Games для Fortnite показательна: за один матч движок компилирует порядка 30 тысяч состояний, используя из них около 10 тысяч, притом что общее число возможных комбинаций исчисляется миллионами.

Загрузить такой массив на этапе старта невозможно из-за ограничений по времени и оперативной памяти. Требуется прогнозирование необходимых ресурсов. Эту задачу решает прекэшинг (precaching), внедренный в Unreal Engine начиная с версии 5.2.

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

Стало ли лучше? Определенно. Система эволюционировала и справляется с большинством задач. Тем не менее в Epic признают наличие слепых зон. Глобальные шейдеры постобработки — тени, размытие движения, отражения — по-прежнему способны вызывать просадки. А декали вовсе не охватывались прекэшингом вплоть до релиза версии 5.6.

Если микрофризы носят перманентный характер

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

Подобные симптомы обычно указывают на задержки на уровне ядра операционной системы. Для их поиска применяется утилита LatencyMon.

Алгоритм прост: запускаем софт, играем около пяти минут и изучаем две строки в отчете: Highest ISR routine execution time и Highest DPC routine execution time с указанием проблемных модулей.

Что означают эти параметры?

• Первый — время выполнения обработчика прерываний. Этот механизм работает на высоком уровне IRQL и блокирует прочие процессы, поэтому корпорация Microsoft рекомендует удерживать показатель в пределах 25 микросекунд.

• Второй — длительность отложенной обработки в очереди DPC. Здесь лимит мягче, около 100 микросекунд.

На практике задержки длительностью в миллисекунду приводят к звуковым щелчкам и визуальным рывкам. В запущенных случаях фиксировались показатели в 15 726 микросекунд у драйверов NVIDIA и 101 миллисекунда у системного модуля dxgkrnl.sys, что превышает нормативы в тысячу раз.

Однако имена в отчетах обманчивы. Тот же dxgkrnl.sys является графическим ядром Windows и редко выступает первопричиной — чаще он лишь фиксирует задержку, порожденную сторонним драйвером. Аналогичная ситуация с модулем Wdf01000.sys, через который функционирует половина системных компонентов.

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

Почему на мониторах 240 Гц рывки заметнее, чем на 60 Гц

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

Парадокса здесь нет. Чем выше частота обновления, тем короче временной интервал одного кадра и тем острее воспринимается любое отклонение от ритма. При 60 Гц кадр отображается 16,6 миллисекунды, маскируя задержку в 5 мс. На частоте 240 Гц длительность кадра сокращается до 4,2 миллисекунды, и задержка, превышающая этот порог, становится очевидной. Монитор просто перестал прощать системе ее медлительность.

Казалось бы, технологии адаптивной синхронизации вроде G-Sync или FreeSync призваны решить эту проблему. Польза от них огромна, но ожидания часто завышены.

Адаптивная синхронизация подстраивает частоту обновления дисплея под темп генерации кадров движком. Разрывы изображения (тиринг) исчезают, а статтер, вызванный несовпадением частот, нивелируется.

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

Для стабильной работы рекомендуется ограничивать кадровую частоту чуть ниже верхней границы диапазона VRR. Для дисплея 144 Гц оптимальным значением станет лимит в 138-141 FPS, для 240 Гц — около 235 FPS. Точное число второстепенно, главное — не упираться в аппаратный потолок.

Программные ограничители работают с погрешностью: зафиксированные 144 кадра на практике будут колебаться до 144.2 или 145, выводя систему за пределы диапазона VRR. В этот момент активируется стандартная вертикальная синхронизация со своими задержками, сменяющаяся отключением, что и ощущается как рывки.

С нижней границей диапазона ситуация аналогична. При падении FPS ниже рабочего диапазона включается компенсация (LFC): монитор начинает дублировать кадры по два-три раза. Например, 47 кадров на панели 144 Гц превратятся в 141 Гц. Механизм эффективен, но моменты активации и деактивации сопровождаются заметным подергиванием картинки, а на OLED-дисплеях — еще и скачками яркости.

Пару слов стоит сказать о режимах экрана, поскольку многие до сих пор руководствуются устаревшими данными. Раньше оконный режим без рамки маршрутизировал кадры через оконный композитор Windows, добавляя задержку, в то время как полноэкранный режим работал напрямую. В современных версиях ОС разница стерта благодаря новому конвейеру вывода в DX12 и актуальных сборках DX10/DX11. Тем не менее, при возникновении рывков в окне проверить поведение в полноэкранном режиме все же стоит.

Алгоритм действий после диагностики

Собрав полученную телеметрию воедино и выявив виновника, можно переходить к устранению неполадок.

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

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

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

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

Нестабильный фреймтайм без явных фризов. Установите ограничение кадров примерно на десять процентов ниже возможностей системы. Ровные 90 FPS воспринимаются значительно комфортнее, чем хаотичные колебания от 100 до 140. При активном VRR лимит обязателен и выставляется на 3-5% ниже максимальной герцовки монитора.

Упор в узкое место (bottleneck). Универсальных таблеток не существует, зато приходит понимание целесообразности финансовых вложений. Уперлась производительность логического потока процессора — покупка новой видеокарты не изменит ничего, вопросы следует адресовать CPU и оптимизации игры. Уперлись в GPU — снижайте параметры графики: разрешение, тени, трассировку лучей. Кроме того, на производительность процессорной части напрямую влияет оперативная память.

Резюме

Усредненный показатель FPS отражает производительность, но не визуальную плавность. Анализировать следует фреймтайм и метрику 0.1% low, поскольку редкие пиковые задержки скрываются именно там.

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

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

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

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

А с какими проблемами сталкивались вы? Приходилось ли анализировать фреймтайм и что в итоге оказывалось источником лагов — особенно в ситуациях, когда «железо» формально полностью соответствовало системным требованиям?

 

Источник