Исчерпывающе про тестирование компьютера в играх

Специализированных программ-бенчмарков для тестирования оборудования немало. Они предназначены для проверки производительности, анализа возможностей 3D-графики, мониторинга работы различных компонентов. Но как бы эти программы ни были хороши, в конечном итоге это всё искусственные тесты, так называемая «синтетика». Трудно поспорить, что компьютер за десятки тысяч покупается совсем не для того, чтобы целыми днями гонять на нём софт для тестирования.

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

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

Больше, чем игра

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

Более того, многие игры имеют встроенный бенчмарк. В той же Assassin's Creed Odyssey можно запустить встроенный тест, который проходит непосредственно в игровом мире, а затем отобразить результаты в подробном виде. Полученные данные о производительности и кадровой частоте можно сохранить, потом изменить настройки графики, прогнать тест ещё раз и сравнить с предыдущим. Как итог наглядные результаты, и легко понять, какое влияние оказали те или иные настройки.

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

Предельно просто для понимания, не правда ли? Но в этом заключена проблема. Абсолютные значения могут быть только 1 раз, буквально для одного-единственного кадра за весь тест, а могут повторяться с регулярными интервалами. Это важная для анализа информация, но увидеть её можно только при наличии графика. Если есть только цифра fps «в прямом эфире» (при измерении в оверлее на лету), то эта особенность упускается.

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

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

Софт для проведения замеров

Бесплатных программ для регистрации скорости обработки данных в компьютерных играх много. Под Windows чаще всего используют MSI Afterburner. Это комплексный инструмент, который среди прочего позволяет регулировать тактовые частоты видеокарты. Несмотря на MSI в названии, он работает с любыми видеокартами, и даже интегрированными видеоядрами.

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

Специалисты DigitalRazor тестируют «железо» иначе. Мы используем программный комплекс под названием OCAT (Open Capture and Analysis Tool). Он разработан компанией AMD в рамках открытой инициативы GPUOpen. Работает с любыми видеокартами. Чисто технически это профессиональный инструмент для разработчиков.

Как и Afterburner, OCAT имеет функцию наложения, которая позволяет в режиме оверлея отображать фреймрейт и среднее время обработки кадров. По нашему мнению, это лучший инструмент для отображения и регистрации данных в играх на базе DirectX 11/12 и Vulkan.

При запуске программа в оверлее по умолчанию показывает, какой графический API используется, а также отображает изменения частоты кадров в виде небольшого графика. Но считывать информацию прямо c оверлея довольно сложно. Тут ОСАТ объективно проигрывает Afterburner.

Afterburner отображает в наложенном оверлее гораздо больше данных (тактовые частоты, температуры и т.д.). Поэтому если цель просто следить «в онлайне» за показателями компьютера во время игры – OCAT малоинформативен. Это инструментарий для углублённой оценки производительности, способный фиксировать огромное количество данных, обрабатывать их и анализировать.

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

0,5% данных, собранных за 106 секунд

OCAT сохраняет результаты в виде файла .csv, поэтому для их просмотра не обязательно использовать именно этот софт. Microsoft Excel, Google Sheets и Apache OpenOffice понимают такой формат. Но второй важный момент: файл будет содержать по-настоящему впечатляющее количество данных. Само открытие такого документа – уже неслабая нагрузка.

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

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

Неочевидный процент загрузки

На тематических форумах часто можно встретить вопрос, дескать «раскроет ли процессор Х видеокарту Y?». Получить ответ довольно просто – включить мониторинг загрузки CPU и GPU.

Эти данные можно регистрировать с помощью утилит HWMonitor или Afterburner. Но нужно чётко понимать, что означает цифра «% загрузки процессора», а здесь всё не так просто. Если кратко, местный % – это не 1/100 от потенциальных возможностей. Это показатель того, как долго CPU или GPU обрабатывают последовательности инструкций в блоке кода в данный момент. Эта длительность выражена в проценте от общего времени, выделенного для этого блока. Обычно такой временной интервал составляет 1 секунду.

Блоки могут быть в активной обработке (заняты), ожидать данных из кэша/памяти (остановлены) или завершены (простаивают). Занятые и остановленные блоки классифицируются одинаково, поэтому высокий показатель загрузки CPU или GPU не обязательно означает, что в реальности процессор/видеокарта молотят изо всех сил. Проще говоря, 100% и 100% загрузки процессора могут сильно отличаться.

В этом можно убедиться, запустив пару разных бенчмарков, и записав данные с помощью HWMonitor. Первый тест – Geekbench 5, в котором все вычислительные процедуры выполняются на видеокарте.

Если посмотреть на колонку «Max» в HWMonitor, то заметно, что максимальная загрузка видеокарты составила 96%. При этом фактически видеокарта потребляла чуть более половины лимита мощности – 57,3%, что для RTX 2080 Super порядка 140 Вт из 250 Вт возможных. Также стоит заметить, что температура видеоядра поднялась всего на 9 градусов выше минимального значения – слишком мало для прилично нагруженной видеокарты.

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

В этом тесте загрузка GPU достигает 100%. Условно это всего на 4% больше, чем в GeekBench5, а вот показатели потребляемой мощности и температуры графического процессора значительно выше. Наглядное доказательство того, что во втором случае GPU работал гораздо интенсивнее, хотя при поверхностной оценке, просто по % загрузки, разница небольшая.

Кстати, ведение журнала потребляемой мощности – очень полезный метод анализа рабочей нагрузки на любые компоненты ПК. На картинке ниже показаны цифры мощности, потребляемой CPU, системной памятью и GPU при выполнении двух тестов в бенчмарке 3DMark Time Spy Extreme.

Слева – Тест CPU, справа – Графический Тест № 2

В CPU-тесте видеокарта не особо напрягается. А вот центральный процессор ожидаемо отрабатывает на полную, вдобавок здорово нагружена и оперативная память. В GPU-тесте энергопотребление видеокарты значительно возрастает, что говорит о её интенсивной работе.

Казалось бы, ну всё очевидно, но всю ли работу в этом тесте выполняет именно видеокарта? Как можно быть уверенным, что CPU не влияет на результаты теста, который должен отображать только возможности GPU? Глядя только на процент загрузки процессора и потребляемую мощность, это утверждать нельзя.

Поэтому регистрация этих показателей – дело конечно замечательное и нужное, но его недостаточно для оценки интенсивности использования различных компонентов ПК. Для дальнейшего анализа нужно разобраться, как OCAT действует «под капотом».

Что на самом деле регистрируем, измеряя частоту кадров?

Чтобы понять, какие параметры фиксирует OCAT, нужно хотя бы базовое понимание процесса рендеринга в игре. Хорошо поясняет картинка от NVIDIA в документации к FrameView – утилите-счётчику fps и не только.

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

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

• Графический API (DirectX, OpenGL или Vulkan) преобразует общие инструкции от игрового движка в более подробные и сложные наборы алгоритмов;

• Затем драйвер видеокарты преобразует алгоритмы в код, который поймёт GPU;

• GPU обрабатывает эти коды, и ставит на кадр флаг готовности к выводу на экран;

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

• Пока это всё происходит игровой движок уже начинает или даже заканчивает подготовку следующего кадра.

В итоге время, прошедшее между инструкциями Present, не отражает точно, насколько быстро GPU отрисовывает кадр. Однако процесс отрисовки составляет львиную долю времени от всего цикла почти всегда. А потому оценка, основанная на этом принципе, будет довольно близка к реальности.

ОСАТ и аналоги, вроде PresentMon или FrameView, несколько раз в секунду измеряет множество различных временных интервалов и сохраняет их в файле .csv. Основные интервалы, представляющие интерес:

• MsInPresentAPI – время, потраченное на выполнение инструкции Present;

• MsUntilRenderComplete – задержка с момента выполнения инструкции Present до момента завершения рендеринга кадра;

• MsUntilDisplayed – время с момента выдачи инструкции Present до момента отображения кадра;

• MsBetweenPresents – задержка между последней выданной командой Present и текущей;

• MsBetweenDisplayChange – задержка между отображением предыдущего кадра и текущего.

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

Нетрудно заметить, что этот параметр измеряется в миллисекундах. Как же он превращается в частоту кадров? Довольно просто: поскольку в 1 секунде 1000 миллисекунд, нужно разделить 1000 на полученный показатель времени.

К примеру, если значение MsBetweenPresents стабильно 50 мс, то отображаемая частота кадров: 1000/50 = 20 кадров в секунду. В итоге, если цель 60 fps или 144 fps, то временной интервал должен составлять 17 и 7 мс соответственно.

Прогрев, необходимое и достаточное

Важная и полезная часть этого исследования – минимизация числа переменных, которые могут влиять на результаты тестирования.

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

• Запускать только необходимый минимум софта для тестирования и мониторинга;

• Закрыть все фоновые программы (чаты, облачные сервисы, лаунчеры и т.д.);

• Приостановить работу антивируса;

• Отключить Интернет;

• Проследить, чтобы во время тестов не происходило обновление системы и стороннего софта.

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

В видеокартах этот механизм работает особенно интенсивно. Это хорошо заметно на изображении выше: при повышении температуры чипа частота снижается, что позволяет держать уровень нагрева под контролем. На самом деле принцип работы этого механизма гораздо сложнее, но для простоты восприятия лучше остановиться на зависимости температура-частота.

Само собой, снижение частоты означает и снижение производительности видеокарты. Однако, если предварительно прогреть все ключевые компоненты ПК (CPU, RAM, GPU), то тактовые частоты должны выйти на плато и сохранять относительную стабильность. Самый простой способ сделать это – минут на 5 для прогрева запустить игру, в которой будет тестироваться компьютер, и только потом записывать данные.

Также следует помнить, что даже при соблюдении всех вышеперечисленных мер результаты тестирования всегда будут отличаться. Это может быть связано с особенностями самой игры или каким-то фоновым процессом. Вот почему важно собрать несколько наборов данных. Нужно провести несколько тестов, хотя бы 3, а потом рассчитать среднее значение. Конечно, тут тоже нужно знать меру: много прогонов – это хорошо, но больше 3 (в крайнем случае 5) не внесут какие-то существенные изменения в конечные результаты. Обычно возможные вариации значений довольно малы. Если соблюдать базовые условия эксперимента, то на несколько тысяч собранных цифр незначительные отклонения не окажут большого влияния.

Наконец, третий принцип, которому хорошо бы следовать – выбор оптимальной длительности сбора данных. Период, в течение которого будет происходить запись, должен быть достаточным для точного отображения основных показателей. При этом не слишком большим, чтобы не собирать данные, которые уже не повлияют на статистику. Проиллюстрируем это на примере Assassin's Creed Syndicate.

Заданная в OCAT длительность сбора данных составляла 10, 100 и 1 000 секунд. Вот результаты:

Весомой разницы в средней частоте кадров нет. Но в 10-секундном прогоне гораздо больший диапазон fps – от 33,8 до 120,4. Наверняка такой же разброс был и в других прогонах, но из-за большего количества данных статистическое влияние этих отклонений значительно уменьшается.

В то же время результаты прогонов на 100 и 1 000 секунд практически идентичны. 17-минутный тест показал ровно то же самое, что и длительностью в 10 раз меньше. В общем, необходимое и достаточное.

Процентили и анализ

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

Дальше всё просто. Жмём кнопку «Select capture file to visualize», выбираете тот .csv-файл, куда данные складировались, а затем жмём «Visualize».

В качестве примера тесты Assassin's Creed Odyssey, записанные во встроенном бенчмарке игры. Тесты проводились при разрешении 4K и настройках графики Ultra High. С тем, как разрешение монитора и графические настройки влияют на кадровую частоту, можно ознакомиться здесь.

По умолчанию OCAT покажет значения из столбца «MsBetweenPresents» за всё время регистрации в виде графика.

На этом графике отображены 2629 точек данных. Очевидно, что чем меньше время обработки кадров (ось Y), тем выше производительность. В лучшем случае получилось порядка 18 миллисекунд, что соответствует 56 кадрам в секунду. Затем этот показатель снижается до 26 мс (38 кадров в секунду) и держится плюс-минус стабильно на протяжении всего теста.

Также можно анализировать сразу несколько файлов данных в формате .csv. Для этого сначала загружается один, а потом нужно снова нажать на кнопку «Select capture file to visualize». Благодаря этому можно легко сравнивать показатели в разных сценариях или играх. Например, на картинке ниже показаны результаты из игры MotoGP 20 (зелёный график) и Shadow of the Tomb Raider (оранжевый).

Обе игры были запущены в разрешении 4K с максимальными настройками графики. В случае Tomb Raider также были включены DLSS и трассировка лучей.

По времени обработки кадров видно, что Tomb Raider работает заметно медленнее. Также стоит заметить сильные колебания среднего времени обработки кадра. В MotoGP 20 этот показатель намного более стабилен и составляет примерно 14 мс, а в Tomb Raider – от 20 до 40 мс, или от 11 до 70 мс, если смотреть по самым пикам.

Помимо построения графиков, OCAT умеет в базовый статистический анализ. За кнопкой «Capture statistics» скрываются множество опций, из которых особенно интересуют две: «Average FPS» и «99th-percentile».

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

ОСАТ умеет вычислять 99-й процентиль времени обработки кадров. Процентили – это значения, которые отражают распределение чисел в пределах выборки. Показатель 99-го процентиля – это граница, ниже которой лежат 99% всех полученных результатов. Соответственно, только 1% времени обработки кадров был выше этого значения. Проще говоря, это показатель редких событий, считай «просадок».

В наших тестах Assassin's Creed 99-й процентиль – 31,65 мс. Напомним, что чем больше время обработки кадра, тем ниже fps. Это означает, что если перевести время в частоту кадров, то получим 1%-ный перцентиль для fps. Это именно то, что в различных тестах обозначают как «1% low fps». Этот параметр показывает, что в 99% замеров частота кадров была выше этого числа. В нашем случае это 1000/31,65 = 31,60 fps.

Средний fps и 1% low fps – два статистических показателя, которые дают представление о том, что происходит за боковой стенкой ПК в игре. Например, абсолютный минимум fps может быть намного ниже, чем цифра 1% low fps. Но такие просадки происходят редко, не более 1% от всего времени игры. А потому в реальности они оказывают мало влияния на игровой процесс.

Кроме того, в ходе записи данных производительность может падать на долю секунды, когда система включает протоколирование и/или сохраняет собранную информацию. Это, очевидно, вызывает искусственные просадки fps, которых не будет при обычном игровом процессе, когда тесты не проводятся. А потому нахождение показателей 1% low fps и их исключение из общей статистики позволит игнорировать при анализе самые низкие значения. Это ещё больше приблизит к реальности итоговые результаты.

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

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

Однако, как уже было сказано, чтобы исследовать возможности ПК в игре вполне достаточно среднего fps и значения 1% low. Самое главное в правильной интерпретации полученных результатов!

От сухих цифр к реальному «железу»

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

Тестовая система качестве основных компонентов имеет процессор Intel Core i7-9700K, 16 ГБ оперативной памяти DDR4-3000 и видеокарту GeForce RTX 2080 Super. Да, сейчас есть и более производительные комплектующие, но мы специально взяли именно такую конфигурацию – достаточно мощную, но не избыточно, чтобы потребности игры не перекрывались с лихвой.

В качестве игры снова Assassin's Creed Odyssey. Для начала запустим встроенный бенчмарк, а потом сравним его результаты с цифрами, полученными непосредственно во время игры. Это даст представление о том, насколько хорошо встроенный тест отражает быстродействие в реальной игре.

Использовалось разрешение 1080p (1920x1080 пикселей) и качество графики Ultra High. Всего сделано 5 прогонов. Время обработки кадров было усреднено, затем преобразовано в частоту кадров (fps) и, наконец, отображено на графике.

Тут может показаться, что частота кадров сильно скачет, а результаты теста крайне беспорядочны. Но стоит учитывать, что эти быстрые изменения разделены миллисекундными интервалами. Это слишком быстро, чтобы их можно было заметить в реальной игре. Несмотря на «рваный» график, визуально прогон бенчмарка был плавным.

Средняя частота кадров довольно высока – чуть менее 75 fps. Однако, заметен значительный разрыв между показателями 1% low, 99% High и средним значением – около 22 и 40 кадров в секунду соответственно. Это наводит на мысль, что здесь время от времени возникали какие-то пиковые нагрузки. Вопрос: какой компонент в ПК в основном с ними справлялся – CPU или GPU?

Один из способов проверить это – повторить тесты при различных разрешениях и настройках графики. Изменение разрешения повлияет только на GPU, в то время как настройки графики отразятся на работе и CPU, и GPU. В нашем случае для тестов использовались 5 разрешений, самые низкие и самые высокие настройки детализации.

На графике приведены только значения среднего fps, поскольку показатели 1% low имели ровно такие же закономерности. На первый взгляд эти данные не дают никакой свежей информации: улучшенные тени или использование дополнительных эффектов рендеринга приводит к снижению частоты кадров. Кто бы мог подумать…

Но при изменении разрешения fps уменьшается линейно, о чем свидетельствуют прямые линии графика. Почему это важно? Сравним эти данные с результатами, которые были получены после графического теста в бенчмарке 3DMark Fire Strike Extreme:

Здесь графики выглядят как изогнутые линии. Наглядное свидетельство, что изменение разрешения очень сильно влияет на производительность. Следовательно, с шейдерными вычислениями видеокарта справляется довольно легко, но по мере увеличения числа пикселей fps утыкается. Этот «потолок» ограничен пропускной способностью памяти и быстродействием графического процессора.

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

Соответственно, линейные графики в Assassin's Creed указывают, что этот тест ограничен либо вычислительными ресурсами, либо пропускной способностью. Другими словами, есть два варианта. Первый – CPU или GPU приходится выполнять так много сложных вычислений, что число пикселей уже не сильно влияет на нагрузку. Второй – данных, которые нужно передавать, так много, что не справляется память системы.

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

Как выяснить, какая именно ситуация в данном случае? Для этого нужно изменить всего одну переменную – тактовую частоту ядра GPU. Вот результаты нескольких тестов при разрешении 1080р в широком диапазоне частот.

Посмотрите сначала на график с настройками Ultra High. Удвоение тактовой частоты графического процессора увеличивает средний fps почти в 2 раза. Заметим, что изменение параметра 1% low было примерно таким же. Это не такой большой скачок, как в тестах 3DMark, но его достаточно для понимания, что здесь показатели зависят именно от вычислительной мощности. Если снизить настройки до low-пресета, то картина будет очень похожей. А тот факт, что график сначала чуть более изогнут и выходит на плато только на частоте около 1900 МГц – ещё одно доказательство, что рабочая нагрузка в бенчмарке падает в основном на GPU.

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

Для этого попробуем поменять тактовую частоту центрального процессора с помощью утилиты Intel Extreme Tuning Utility. Для всех ядер процессора были заданы фиксированные частоты от 3,6 до 5 ГГц.

При разрешениях 1080p, 2К, 4К и ультра-настройках качества изменения частоты процессора в диапазоне от 3,6 до 5,0 ГГц практически не дали никакого эффекта. Здесь fps почти полностью зависит от видеокарты.

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

И тут всплыл ещё один факт: график начинает сглаживаться, когда частота приближается к 5 ГГц. Это как раз стандартная скорость Core i7-9700K в turbo-режиме. И это дополнительное свидетельство, что встроенный бенчмарк Assassin's Creed Odyssey в значительной степени тестирует именно видеокарту. Просто потому, что производительность CPU влияет на результаты только когда видеокарта загружена минимально.

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

Начнём с того, что fps в игре в целом ниже, чем в бенчмарке. Кроме того, эти графики сильно отличаются. При самых низких настройках производительность практически одинакова как при 1080p, так и при 720p. А существенное снижение fps только когда разрешение переваливает за 2К. Результаты по 1% low выглядят точно так же. Это говорит о том, что GPU на самом деле легко справляется с работой. А производительность игры определяется возможностями центрального процессора.

Теперь сменим настройки на ультра-пресет. Картина резко меняется: теперь график изогнутый к низу, как и в тесте 3DMark. Да, кадровая частота не проседает так сильно, как в Fire Strike Extreme. Но и этого достаточно для понимания, что при таком уровне графики fps в игре зависит от производительности как процессора, так и видеокарты.

При повторной проверке влияния частот GPU и CPU при настройках Ultra и low обнаружились те же закономерности, что и раньше. Всё это показывает, что встроенный бенчмарк – фактически тест видеокарты. А потому не полностью отражает то, что можно ожидать от реальной игры.

Тут, конечно, нужно сделать оговорку. Все полученные цифры актуальны только для конкретного ПК, выполняющего этот конкретный тест. На другом «железе» результаты, скорее всего, будут другими. Например, более мощный GPU лучше справится с вычислительной нагрузкой, а центральный процессор будет сильнее влиять на среднюю частоту кадров. И наоборот: слабый GPU имеет все шансы стать «бутылочным горлышком», от которого и будет зависеть общая производительность системы в реальной игре.

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

Ещё раз кратко и по пунктам опишем всю методику, чтобы вы могли повторить её на собственном ПК:

1. Установите настройки графики и разрешение монитора на максимально возможные значения;

2. Прогоните несколько максимально похожих тестов и усредните результаты;

3. Повторите пункт 2, пошагово снижая разрешение монитора;

4. Из полученных результатов постройте график. Если в итоге прямая линия – игра упирается в дефицит мощности CPU и/или GPU. Если график кривой – fps ограничен возможностями видеокарты;

5. Возьмите только одно разрешение (например, 1080р) и повторите тест, изменяя тактовую частоту GPU;

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

7. Повторите тест ещё раз, но теперь меняйте тактовую частоту CPU. Это поможет подтвердить ранее сделанные выводы.

Это, безусловно, значительный объём работы. Но тест можно и упростить, меняя только тактовую частоту GPU. Для этого нужно запускать игру и собирать данные, пошагово снижая скорость видеокарты. Существенные изменения среднего fps или 1% low fps укажут на то, что именно GPU – ограничивающий производительность игры фактор. А если снижение скорости видеокарты на условные 25% не даст особенной разницы – значит дело в CPU.

Послесловие

Такой углублённый бенчмаркинг и анализ данных – развлечение для фанатов. Многим это может показаться нудным и утомительным занятием, ведь компьютерные игры создают не для тестов «железа», а для того, чтобы в них играть!

Описанный подход к тестам полезен, если колеблетесь, какую часть ПК стоит модернизировать в первую очередь. Конечно, есть и более простой способ разрешить сомнения. Позвоните по телефону 8 800 500 9926 и в лоб задайте свой вопрос специалистам DigitalRazor. Мы всегда сможем помочь профессиональным советом!

Также можно посмотреть на готовые конфигурации наших компьютеров, где пара процессор-видеокарта подобраны друг к другу идеально.

P.S. Краткое примечание от редактора. Вышеописанный метод технически очень грамотный, точный, универсальный и правильный, но для большинства избыточный и слишком сложный.

Если вообще любая диагностическая утилита показывает загрузку процессорных ядер в игре на 90+ процентов – процессора недостаточно. Если загрузка видеокарты менее 98% или потребляемая мощность сильно ниже лимита TDP видеокарты – процессора недостаточно. Во всех других случаях упор в видеокарту – вот и вся любовь джентльмены.