Производительность видеокарт в играх: метод оценки дефицита видеопамяти

Движок может заранее резервировать место для текстур и буферов, драйвер не обязан сразу возвращать освобождённую память системе, а Windows распределяет доступный бюджет с учётом общей нагрузки на GPU.

Средняя частота кадров здесь тоже не всегда помогает. На одной сцене карта с 8 ГБ и модель с 16 ГБ могут показывать близкий средний FPS, но по-разному вести себя в моменты подгрузки ассетов. Поэтому тест видеопамяти в игровых приложениях строится не вокруг одного числа из оверлея, а вокруг повторяемых проходов, фреймтаймов и показателей памяти. Именно сочетание этих данных позволяет оценить, есть ли основания связывать просадки с VRAM.

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

Почему показатели занятой VRAM вводят в заблуждение

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

Игровой движок не обязательно загружает только те текстуры, которые видны на экране в текущем кадре. Он может держать в памяти резидентный пул текстур с разными MIP-уровнями, буферы команд и таблицы виртуального текстурирования. Состав пула меняется при переходе между зонами, но не всякая перемена сразу отражается на показателе занятости. Драйвер тоже может сохранять уже выделенные области, даже когда конкретная сцена перестала ими пользоваться.

Поэтому цифра «занято VRAM» не равна объёму данных, без которых игра прямо сейчас не сможет отрисовать кадр. Высокое значение может быть поводом присмотреться к поведению игры, однако не позволяет само по себе сделать вывод о нехватке. То же относится и к низкому значению: один мониторинг не всегда описывает всю работу системы с памятью.

В Windows для этой задачи полезны два показателя DXGI. CurrentUsage описывает текущее использование видеопамяти приложением. Budget показывает бюджет, который операционная система предоставляет приложению с учётом общей нагрузки на GPU и системную память. Это динамические показатели, поэтому их имеет смысл смотреть вместе и в контексте конкретного игрового прохода.

Если CurrentUsage подходит к Budget или превышает его, это может быть сигналом, что системе приходится активнее управлять доступной памятью. Возможные последствия включают подёргивания или снижение производительности, но они не возникают автоматически при каждом превышении. Значение важно сопоставить с фреймтаймами, повторяемостью просадки и другими условиями теста.

Есть и внешние признаки, на которые стоит обратить внимание: текстуры появляются с задержкой, качество материалов меняется во время игры, объекты дальнего плана выглядят упрощёнными. Такие наблюдения полезны, но сами по себе тоже не устанавливают причину. Похожие симптомы могут возникнуть из-за особенностей движка, накопителя, драйвера или других ограничений системы.

Длинный и короткий проход: что измеряют разные подходы

Лабораторные методики отличаются не только инструментами, но и тем, какой вопрос они задают. Длинный проход по меняющимся игровым зонам помогает увидеть, как система ведёт себя при подгрузке разных ассетов. Короткий проход по стационарной сцене удобен для многократного сравнения производительности в более контролируемых условиях. Это не взаимоисключающие подходы: у каждого своя задача.

TechSpot: проверить поведение в длинной игровой сессии

В материале TechSpot от 2 июля 2024 года описан подход, в котором для оценки потребления памяти используют ускоритель с большим объёмом VRAM. В качестве такой карты выступает RTX 4090 с 24 ГБ. Она помогает оценить, сколько памяти запрашивает конкретная игра при заданных разрешении и пресете, когда объём буфера не становится очевидным ограничением тестовой карты.

Но результат на карте с большим буфером не превращается в универсальный порог для моделей с меньшим объёмом памяти. Если на RTX 4090 игра использует определённый объём, это ещё не доказывает, что карта с 8 ГБ обязательно столкнётся с дефицитом. Движок, драйвер и сама видеокарта могут по-разному распределять ресурсы и менять поведение при другом доступном объёме. И наоборот, сравнительно скромное потребление на эталонной карте не гарантирует, что любая карта с 8 ГБ пройдёт ту же сцену без проблем.

Для длинного теста важны условия, при которых результат можно повторить:

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

В описанной методике TechSpot игровой проход длится не менее 10 минут. Смысл такой продолжительности не в том, что короткий тест всегда бесполезен, а в том, чтобы дать игре время пройти участки с разной нагрузкой на память. Если ограничиться короткой сценой без смены зон, часть проблем с подгрузкой может остаться незамеченной.

Пример из материала TechSpot: в Horizon Forbidden West при разрешении 1440p и пресете Very High RTX 4060 Ti с 16 ГБ показала в среднем 73 FPS, а версия на 8 ГБ — 49 FPS. В этом тесте у 8-гигабайтной модели были заметно менее ровные фреймтаймы. Результат относится к конкретной версии игры, настройкам и тестовой системе. Он показывает, что разница по объёму памяти может сопровождаться различием в плавности, но не задаёт универсальную величину для других игр.

В материале TechSpot 2025 года сравнивались версии RX 9060 XT с 8 и 16 ГБ. В The Last of Us Part II при 1440p, FSR Quality и пресете Ultra версия с 16 ГБ показала 84 FPS в среднем. В том же тесте преимущество по среднему FPS составило 22%, а по 1% low — 37%. Эти цифры описывают конкретный замер, а не гарантированный эффект от удвоения видеопамяти.

ComputerBase: повторяемые проходы и хвост фреймтаймов

В методике ComputerBase для замеров производительности используется OCAT, основанный на PresentMon. Инструменты фиксируют время отображения кадров и позволяют сопоставлять результаты разных видеокарт без изменения самого рендера.

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

На время замера авторы методики рекомендуют отключать оверлеи. Дополнительные программы могут повлиять на распределение времени кадра, особенно если цель теста состоит в изучении редких скачков. Методика ComputerBase опубликована в 2019 году; инструменты затем развивались, но общий принцип остаётся понятным: фиксированная сцена, повторяемые прогоны и анализ не только средней частоты кадров.

ComputerBase также показывает 99,8-й перцентиль фреймтаймов в представлении FPS. Эта метрика помогает увидеть хвост распределения: отдельные медленные кадры, которые среднее значение сглаживает. Для интерпретации важно помнить, что показатели, представленные в FPS, связаны с временем кадра обратным образом. Чем дольше отрисовывается медленный кадр, тем ниже его эквивалент в FPS.

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

Фреймтаймы, 1% low и динамичные сцены

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

1% low и 0,1% low помогают оценить медленную часть распределения кадров. В паре со средним FPS они дают более содержательную картину, чем одна средняя цифра. Однако эти метрики не являются прямыми измерителями видеопамяти. Просадки могут быть связаны с процессором, накопителем, компиляцией шейдеров, драйвером, фоновой задачей или особенностями самой сцены.

Именно поэтому диагностика нехватки видеопамяти в играх требует повторяемости. Если провал 1% low возникает в одном запуске, но исчезает в следующих, вывод о VRAM будет преждевременным. Если же при одинаковом маршруте и настройках повторяются скачки фреймтаймов, одновременно меняются CurrentUsage и Budget, а снижение качества текстур или разрешения меняет картину, это уже более весомый набор сигналов. Но и он требует проверки альтернативных причин.

Для анализа полезно сохранить лог с временами кадров через OCAT, PresentMon или CapFrameX. Важно не подгонять результат под заранее выбранный порог. Разница между средней частотой и 1% low может быть небольшой в одной сцене и заметной в другой; универсального значения, после которого можно объявить дефицит, здесь нет.

Проверка пропускной способности памяти GPU отвечает на соседний, но другой вопрос. Узкая шина или недостаточная скорость обмена данными способны ограничивать производительность даже тогда, когда объёма VRAM достаточно. Поэтому сравнение карт только по числу гигабайт не объясняет все различия. В тесте нужно учитывать сам GPU, частоты, пропускную способность, разрешение и настройки качества.

Сравнение адаптеров с разным объёмом буфера

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

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

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

Отдельный случай возникает, когда движок сам меняет размер пула текстур. В Indiana Jones and the Great Circle TechSpot сравнивал карты с 8 и 16 ГБ при разных размерах такого пула. На 8-гигабайтной версии уменьшенный пул ухудшал видимое качество изображения. Это меняет условия сравнения: различаются не только объём памяти и производительность, но и настройки, влияющие на картинку. Поэтому цифры FPS в этом случае нужно читать вместе с тем, как игра распределила текстуры.

Влияние объёма видеопамяти на FPS зависит от игры и настроек. Если движок меняет качество текстур при ограниченном буфере, одной таблицы кадров в секунду недостаточно: результат нужно сверять с изображением и поведением фреймтаймов.

Как провести тест без ложного диагноза

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

1. Выберите повторяемую сцену. Для оценки подгрузки подойдёт маршрут со сменой зон. Для сравнения чистой производительности можно взять стационарный бенчмарк. Эти задачи лучше не смешивать в одном выводе.

2. Зафиксируйте настройки. Запишите разрешение, пресет, апскейлер, трассировку лучей и параметры постобработки. После изменения настроек перезапустите игру, особенно если проверяете поведение текстурного пула.

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

4. Запишите метрики кадров. Сохраните средний FPS, 1% low, при необходимости 0,1% low и лог фреймтаймов. Не выводите заключение по одному перцентилю: смотрите, в какой момент он ухудшился и что происходило на экране.

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

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

7. Сравнивайте подходящие карты. Чтобы оценить именно роль объёма VRAM, лучше сопоставлять близкие модели с разным буфером памяти. Если различаются GPU, частоты и пропускная способность, результат характеризует систему в целом, а не только объём памяти.

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

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

Универсального процента занятости или разницы между средним FPS и 1% low, который сам по себе доказывал бы дефицит, нет. Надёжнее искать совпадение нескольких признаков в повторяемых условиях и отдельно проверять другие возможные ограничения. Тогда сравнение карт с разным объёмом буфера говорит не просто о том, какая из них быстрее, но и о том, где именно возникает разница.