Почему игра может дёргаться даже при высокой частоте кадров

Игра показывает больше девяноста кадров в секунду, но ненадолго замирает при повороте камеры или входе в новую область. Средний FPS не стал бесполезным: он отвечает на общий вопрос о количестве кадров за определённый промежуток. Чтобы понять, поступают ли они равномерно, нужно изучить время каждого кадра.

Начните со времени кадра, а затем решите, что измерять дальше. Один процент «узкого места» или разовое падение загрузки GPU не указывают, какой компонент нужно заменить.

Долгий кадр может скрываться за хорошим средним значением

При идеально равномерном выводе интервал между кадрами в миллисекундах примерно равен 1 000 ÷ FPS. Поэтому 60 FPS соответствуют примерно 16,67 мс, а 120 FPS — примерно 8,33 мс. Это пересчёт времени, а не результат тестирования компьютера.

Предположим, в записи 100 кадров: 99 занимают по 10 мс, один — 100 мс. Общее время составляет 99 × 10 + 100 = 1 090 мс. Если разделить число кадров на длительность, получится около 91,74 FPS. Среднее выглядит достойно, но одно ожидание всё равно значительно длиннее.

Иллюстрация: расчёт на искусственных данных и порядок проверки времени кадра, а не скриншот игрового бенчмарка.

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

Полезно оценивать и долю времени, занятую медленными кадрами. В условной записи длиной 60 секунд шесть кадров по 100 мс занимают 0,6 секунды, то есть 1% всего интервала. Это тоже искусственный расчёт, но он сохраняет редкие паузы, которые может пропустить процентиль.

Иллюстрация: 100 искусственных кадров. По горизонтали указан номер кадра, а не равномерная шкала времени. Кадр 50 длится 100 мс, остальные 99 — по 10 мс.

Уточните, какие именно кадры записаны

На официальной странице NVIDIA FrameView перечислены измерения частоты кадров, времени кадра и мощности с поддержкой журналирования.[1] Журналы сохраняют данные вокруг события, но сама программа записи не доказывает, что узким местом является CPU.

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

Показатель «1% low» помогает оценить медленную часть кадров, но разные программы могут считать его по-разному. Сохраняйте вместе со значением название инструмента, версию, определение метрики и длительность записи. Не приравнивайте его к самому медленному отдельному кадру и не составляйте рейтинг из результатов разных программ.

CapFrameX явно различает процентили упорядоченных кадров и прошедшее время.[3] «99% кадров укладываются в порог» нельзя строго заменить на «99% игрового времени проходит плавно», поскольку несколько медленных кадров могут занять много времени. Также объясняется отличие значений процентилей от обобщения самой медленной доли выборки. Если отчёт указывает лишь «1% low» без метода расчёта, учитывайте это ограничение.

Какие поля журнала нужно читать вместе?

Откройте CSV и сначала проверьте заголовки. Документация консольной версии PresentMon определяет следующие поля; фактический вывод зависит от версии и настроек захвата.[2]

Поля описывают разные интервалы, а работа CPU и GPU может перекрываться. Нельзя просто складывать столбцы и требовать, чтобы сумма равнялась полной длительности кадра. MsGPUBusy — не процент загрузки GPU из Диспетчера задач. Прочитайте определения, прежде чем решать, сопоставимы ли два числа.

Если интервалы отправки растут и активное время GPU заметно увеличивается, стоит исследовать графическую нагрузку. Если GPU работает недолго, но ожидание велико, могут влиять ограничитель FPS, подача работы со стороны CPU или планирование. Это сужает поиск, но не доказывает недостаточную производительность процессора. Проект также описывает ограничения разных API и аппаратного планирования. Не подменяйте отсутствующие или ограниченные измерения выдуманными значениями.[4]

Сохраняйте данные на коротком повторяемом маршруте

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

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

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

Ниже приведён начальный шаблон. Шестьдесят секунд и три прохода — примеры, а не гарантия достаточности для любой игры.

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

PresentMon позволяет выбирать процесс по имени, задавать длительность захвата и указывать выходной CSV-файл.[2] В графическом интерфейсе и командной строке проверяйте целевой процесс, чтобы не смешивать кадры лаунчера и игры. Здесь реальная запись игры не выполнялась; изображения поясняют метрики.

Меняйте только одно условие за раз

Если подозреваете графическую нагрузку, уменьшите одну конкретную составляющую рендеринга и повторите маршрут. При подозрении на фоновую помеху закройте одну известную программу и повторите измерение. Не меняйте одновременно драйверы, качество графики и лимит FPS вместе с перезапуском игры: иначе причина улучшения останется неясной.

Если снижение качества повышает средний FPS, но всплеск остаётся в том же месте, средняя нагрузка рендеринга и эта пауза могут быть разными проблемами. Рывок на первом проходе, ослабевающий позже, может быть связан с загрузкой ресурсов или кэшем, но сам такой рисунок не устанавливает причину. Низкая загрузка GPU может отражать лимит, ожидание CPU или другие ограничения и не означает напрямую недостаточную мощность видеокарты.

Сохраните вывод с условиями, например: «во всех трёх проходах при входе в область был всплеск, и снижение теней его не убрало», вместо «у ПК узкое место 30%». Тогда следующий тест сможет проверить место всплеска и разницу в настройках теней, не начиная снова с догадок.

Источники

1. Официальная страница NVIDIA FrameView. Подтверждает функции измерения FPS, времени кадра и журналирования. Не подтверждает проведённый тест, одинаковые поля мощности у всех GPU или установленную программу.

2. Документация PresentMon Console Application. Состояние ветки main прочитано 2026-09-27. Определяет поля CSV, целевой процесс и длительность захвата. Поля зависят от версии; локальный захват не подразумевается.

3. CapFrameX: Explanation of different performance metrics. Taxxor, 2020-05-31. Объясняет процентили и x% low. Используется для понятий метрик, а не как снимок текущего интерфейса.

4. Документация и ограничения проекта PresentMon. Проверено 2026-09-27. API и аппаратное планирование могут влиять на измерения; фиксируйте среду, а не делайте немедленный вывод об узком месте.