В данном материале в рамках лаборатории будет рассмотрен разгон процессора AMD A10-5800K. Модели AMD Trinity – уже второе поколение «гибридов», или так называемых APU (Accelerated Processing Unit). Под одной крышкой размещены как привычные процессорные ядра, так и интегрированная графика, что для недорогих систем позволяет отказаться от использования внешних видеокарт. Внутри самого A10-5800K находится пара модулей Piledriver, а также графическое ядро HD 7660D на базе архитектуры VLIW4.
По отдельности данные компоненты сильного интереса не представляют, а вот собранные воедино уже могут быть некоторой головоломкой при поиске оптимального разгона. С одной стороны, процесс разгона Piledriver изучен достаточно подробно, а с другой, свое влияние наверняка проявят такие факторы, как отсутствие кэш-памяти третьего уровня, более сложный контроллер памяти и наличие графического ядра.
Тестирование производилось в составе следующей конфигурации:
Программное обеспечение:
Системная плата всегда привносит тот или иной оттенок в процессе разгона процессора, так что перед тем, как приступить к его рассмотрению, не помешает ознакомиться и с возможностями платы. Ее обзор уже был за авторством I.N., так что по плате «пройдемся» только кратко, по вопросам, которые непосредственно важны для разгона.
Так как все указанные в дальнейшем в тексте статьи или на графиках напряжения – значения, установленные в BIOS платы, то замеры необходимы в первую очередь для того, чтобы пользователи других материнских плат могли сопоставлять результаты со своими.
Работа Load-Line Calibration для напряжения питания процессора:
| Напряжение | Установлено, В | Без нагрузки, программный мониторинг, В |
Под нагрузкой, программный мониторинг, В |
Без нагрузки, замер мультиметром, В |
Под нагрузкой, замер мультиметром, В |
| CPU Vcore, Load Line calibration Auto |
1.375 | 1.368 | 1.332 | 1.37 | 1.334 |
| CPU Vcore, Load Line calibration Normal |
1.375 | 1.368 | 1.332 | 1.37 | 1.334 |
| CPU Vcore, Load Line calibration Standard |
1.375 | 1.368 | 1.332 | 1.37 | 1.334 |
| CPU Vcore, Load Line calibration Low |
1.375 | 1.368 | 1.344 | 1.372 | 1.346 |
| CPU Vcore, Load Line calibration Medium |
1.375 | 1.368 | 1.356 | 1.374 | 1.359 |
| CPU Vcore, Load Line calibration Extreme |
1.375 | 1.38 | 1.392 | 1.38 | 1.399 |
Традиционно для Gigabyte, режимы Load-Line Calibration Auto, Normal и Standard совпадают, что лишь вводит пользователя в заблуждение. По результатам замеров можно сделать вывод, что минимальные расхождения между напряжением питания в простое и под нагрузкой наблюдаются в режиме Medium. Хотя эта разница весьма заметна, но в других режимах она еще выше. Явно не хватает промежуточной настройки между режимами Medium и Extreme. Что касается программного мониторинга, то расхождения с показаниями мультиметра минимальны, на данной материнской плате ему можно доверять.
В дальнейшем, при разгоне процессора использовался режим Vcore LLC Medium.
Работа Load-Line Calibration для напряжения CPU_NB:
| Режим работы | Установлено, В | Без нагрузки, замер мультиметром, В |
Под нагрузкой, замер мультиметром, В |
| CPU_NB, Load-Line Calibration Auto |
1.275 | 1.275 | 1.283 |
| CPU_NB, Load-Line Calibration Normal |
1.275 | 1.275 | 1.283 |
| CPU_NB, Load-Line Calibration Standard |
1.275 | 1.275 | 1.283 |
| CPU_NB, Load-Line Calibration Low |
1.275 | 1.28 | 1.288 |
| CPU_NB, Load-Line Calibration Medium |
1.275 | 1.284 | 1.294 |
| CPU_NB, Load-Line Calibration Extreme |
1.275 | 1.302 | 1.312 |
Как и в случае с CPU Vcore, режимы Auto, Normal и Standard показывают одинаковое поведение системы. В каждом из режимов напряжение питания под нагрузкой растет, и чем более агрессивный режим LLC выставлен, тем сильнее рост напряжения. Итого, оптимальнее использовать настройки Auto, где результаты замеров максимально близки к выставленным в UEFI значениям.
Дабы исключить вероятность «самодеятельности» платы в плане Auto (мало ли, переключит режим в зависимости от используемого напряжения?) при дальнейшем разгоне процессора использовался режим CPU_NB LLC Normal.
Результаты замера вторичных напряжений:
| Напряжение | Установлено, В | Без нагрузки, замер мультиметром, В |
Под нагрузкой, замер мультиметром, В |
| DRAM Voltage | 1.6 | 1.605 | 1.607 |
| APU VDD | 1.2 | 1.199 | 1.2 |
| FCH Voltage | 1.1 | 1.104 | 1.106 |
Расхождения установленных в UEFI значений с показаниями мультиметра невелики, и ими можно пренебречь.
Все замеры производились при помощи мультиметра Mastech MY64.
Поскольку процессоры Llano и Trinity в отличие от предшественников без встроенной графики работают на базовой частоте 100 МГц, а не 200 МГц, то точный поиск стабильных частот осложнен. На это влияет и отсутствие «дробных» коэффициентов умножения CPU, и сама величина коэффициента умножения, который для штатной частоты ЦП равен уже Х38. Как итог, каждый шаг изменения базовой частоты приводит к большему увеличению частоты работы процессора, помимо этого уменьшается количество возможных сочетаний базовой частоты и коэффициента умножения. Так что лучше заранее знать, какие настройки доступны материнской плате.
К сожалению, результаты разгона базовой частоты совпали с теми, которые были достигнуты I.N. в своем обзоре, то есть 106.5 МГц. При этом можно отметить весьма скверную точность ее установки. Приведу все доступные значения базовой частоты в таблице ниже:
| Установлено в UEFI, МГц |
Реальное значение, МГц |
| 100 | 99.82 |
| 101 | 101.9 |
| 102 | 102.32 |
| 103 | 103.16 |
| 104 | 103.98 |
| 105 | 106.49 |
| 106 | 106.49 |
Как можно заключить, перечень доступных настроек не очень-то и впечатляющий, что в дальнейшем может усложнить процесс разгона. Печально, но ничего с этим не поделать. Возможно, стоило просить у AMD на тесты MSI FM2-A85XA-G65 (предоставляли выбор из двух моделей материнских плат), но после того, как wildchaser и I.N. нарисовали себе по звезде «за сбитого», выбор пал на Gigabyte.
В UEFI шаг изменения частоты встроенного графического ядра составляет 1 МГц, но после результатов разгона базовой частоты не мешает проверить и то, как система реагирует на изменение частоты встроенной графики. Оказалось, проверка была не зря: несмотря на шаг в 1 МГц, реально доступными оказались лишь несколько фиксированных значений частоты, это 800 МГц -> 844 МГц -> 894 МГц -> 950 МГц -> 1013 МГц -> 1086 МГц -> 1169 МГц.
При любом другом выставленном значении устанавливается частота предыдущей отметки, то есть, если выставить в UEFI частоту графики 1168 МГц, то система запустится на частоте 1086 МГц и так далее. Значение следующей после 1169 МГц отметки вычислить не удалось – это максимальная частота, при которой материнская плата стартовала.
Что ж, видимо, при поиске стабильных частот графики придется повозиться.
С материнской платой закончили, можно приступать к изучению возможностей процессора.
Так как у Trinity есть встроенная графика, то описание разгона поделено на две части. Сначала рассмотрим возможности вычислительной части, то есть непосредственно процессора и CPU_NB. Тем временем, графику пока отключим, установив в систему внешнюю видеокарту.
Предыдущие опыты по процессорам AMD Bulldozer и AMD Vishera показали, что для определения стабильности лучше подходят специализированные стресс-тесты, нежели тесты производительности системы или игры, так что на сей раз остановимся только на них.
Программное обеспечение, выбранное для выявления нестабильности:
За стабильность принято состояние системы, при котором в течение 10-15 минут работы теста не возникает каких-либо проблем в работе системы.
В данном подразделе статьи выберем программное обеспечение, при помощи которого легче выявить нестабильность именно процессора, при заведомо стабильных частотах памяти и CPU_NB.
Методика относительно проста: при фиксированном значении напряжения питания подобрать максимальный разгон для каждой из программ и вычислить тест, при котором будет достигнута минимальная частота стабильной работы. Ну, а параллельно поиску стабильных частот можно и оценить поведение системы при переразгоне для того или иного теста. Дабы избежать нестабильности, вызванной перегревом ЦП, все тесты производились при штатном напряжении питания CPU (1.375 В).
Частота работы процессора, при которой стартует Windows – 4392 МГц.
Таблица с результатами разгона A10-5800K под стресс-тестами:
| Тест | Результат разгона процессора, МГц |
Поведение системы при легком переразгоне (20-60 МГц) |
Поведение системы при среднем переразгоне (60-100 МГц) |
Поведение системы при сильном переразгоне (свыше 100 МГц) |
| LinX 0.6.4, 2560 Мбайт |
4263 | Остановка теста в связи с ошибкой | Остановка теста в связи с ошибкой | Зависание системы на первых секундах теста |
| LinX 0.6.4, 1024 Мбайт + Linpack 11.0.1.005 |
4192 | Остановка теста в связи с ошибкой | Зависание системы на первых секундах теста | Перезагрузка системы после первых секунд появления нагрузки |
| LinX 0.6.4, 2560 Мбайт + Linpack 11.0.1.005 |
4159 | Остановка теста в связи с ошибкой | Зависание системы спустя 30-40 секунд после включения нагрузки | Перезагрузка системы после первых секунд появления нагрузки |
| LinX 0.6.4, 6144 Мбайт + Linpack 11.0.1.005 |
4159 | Остановка теста в связи с ошибкой | Зависание системы спустя 40-50 секунд после включения нагрузки | Перезагрузка системы после первых секунд появления нагрузки |
| OCCT 4.3.2.b01, LINPACK + AVX |
4263 | Зависание системы после 4-5 минут работы теста | Зависание системы на первых секундах теста | Перезагрузка системы после первых секунд появления нагрузки |
| OCCT 4.3.2.b01, Large Data Set |
4192 | Зависание системы на первых минутах теста | Зависание системы на первых секундах теста | Зависание системы на первых секундах теста |
| OCCT 4.3.2.b01, Medium Data Set |
4229 | Зависание системы на первых минутах теста | Остановка теста в первые секунды теста в связи с ошибкой | Зависание системы на первых секундах теста |
| OCCT 4.3.2.b01, Small Data Set |
4229 | Зависание системы на первых минутах теста | Остановка теста в первые секунды теста в связи с ошибкой | Зависание системы на первых секундах теста |
| Prime 95 v27.7 build2, Small FFTs |
4159 | Остановка теста в связи с ошибкой | Зависание системы на первых минутах теста | Зависание системы на первых секундах теста |
| Prime 95 v27.7 build2, In-place Large FFTs |
4192 | Остановка теста в связи с ошибкой | Остановка теста в связи с ошибкой | Зависание системы на первых секундах теста |
| Prime 95 v27.7 build2, Blend |
4192 | Зависание системы после 4-5 минут работы теста | Зависание системы на первых минутах теста | Зависание системы на первых секундах теста |
| CST 0.20.01a | 4292 | Остановка теста в связи с ошибкой | Остановка теста в связи с ошибкой | – |
Как видно, исходя из таблицы выше, наиболее лучший результат показали такие тесты, как Prime 95 в режиме Small FFTs и Linpack последней версии в режимах с доступной памятью 2560 Мбайт и 6144 Мбайта. Чуть позади остались такие тесты, как Prime 95 в режимах In-place Large FFTs и Blend, а также Linpack последней версии в режиме с доступной памятью 1024 Мбайта и OCCT 4 в режиме Large Data Set. Все вышеперечисленные тесты уложились в 33 МГц разницы разгона процессора. Остальные тесты/режимы показывают уже более худшие результаты.
Отмечу, что плотность результатов «лидирующей группы» выше, чем в случае с процессорами AMD Bulldozer и AMD Vishera.
В данном подразделе статьи выберем программное обеспечение, при помощи которого легче выявить нестабильность CPU_NB (встроенный в процессор контроллер памяти), при заведомо стабильных частотах ЦП и памяти. Методика та же, что и в случае с поиском ПО для тестирования CPU: при фиксированном значении напряжения питания подобрать максимальный разгон для каждой из программ и вычислить тест, при котором будет достигнута минимальная частота стабильной работы. Все тесты производились при штатном напряжении питания CPU_NB 1.275 В. Так как CPU_NB включает в себя контроллер памяти, к списку стресс-тестов добавлен Memtest-86 v4.0a.
Частота, при которой стартует Windows – 2595 МГц.
Таблица с результатами разгона A10-5800K под стресс-тестами:
| Тест | Результат разгона процессора, МГц |
Поведение системы при переразгоне |
| LinX 0.6.4, 2560 Мбайт |
2495 | Зависание системы |
| LinX 0.6.4, 1024 Мбайт + Linpack 11.0.1.005 |
2495 | Остановка теста в связи с ошибкой |
| LinX 0.6.4, 2560 Мбайт + Linpack 11.0.1.005 |
2495 | Зависание системы |
| LinX 0.6.4, 6144 Мбайт + Linpack 11.0.1.005 |
2495 | Зависание системы |
| OCCT 4.3.2.b01, LINPACK + AVX |
2579 | Зависание системы |
| OCCT 4.3.2.b01, Large Data Set |
2495 | Остановка теста в связи с ошибкой |
| OCCT 4.3.2.b01, Medium Data Set |
2495 | Остановка теста в связи с ошибкой |
| OCCT 4.3.2.b01, Small Data Set |
2495 | Остановка теста в связи с ошибкой |
| Prime 95 v27.7 build2, Small FFTs |
2595 | – |
| Prime 95 v27.7 build2, In-place Large FFTs |
2495 | Остановка теста в связи с ошибкой |
| Prime 95 v27.7 build2, Blend |
2495 | Остановка теста в связи с ошибкой |
| CST 0.20.01a | 2595 | – |
| Memtest-86 v4.0a | 2495 | Зависание системы |
Результаты весьма интересны. С одной стороны, разница между лучшим и худшим значением стабильной частоты составляет 100 МГц, то есть разброс выше, чем у моделей AMD Bulldozer и AMD Vishera, с другой стороны – подавляющее большинство тестов остановилось на одной и той же частоте стабильной работы в 2495 МГц. Хотя здесь очевидно, что проблема кроется в доступных значениях базовой частоты материнской платы, при которых доступны частоты 2495 МГц -> 2548 МГц -> 2558 МГц -> 2579 МГц -> 2595 МГц.
Так что для отличившихся тестов пришлось на частоте 2495 МГц проводить дополнительное тестирование: на выявление минимального напряжения питания CPU_NB, дабы таки выявить лучшие/худшие тесты.
| Тест | Требуемое напряжение питания CPU_NB, В |
| LinX 0.6.4, 2560 Мбайт |
1.225+ |
| LinX 0.6.4, 1024 Мбайт + Linpack 11.0.1.005 |
1.225+ |
| LinX 0.6.4, 2560 Мбайт + Linpack 11.0.1.005 |
1.225+ |
| LinX 0.6.4, 6144 Мбайт + Linpack 11.0.1.005 |
1.2375+ |
| OCCT 4.3.2.b01, Large Data Set |
1.225+ |
| OCCT 4.3.2.b01, Medium Data Set |
1.225+ |
| OCCT 4.3.2.b01, Small Data Set |
1.2125+ |
| Prime 95 v27.7 build2, In-place Large FFTs |
1.225+ |
| Prime 95 v27.7 build2, Blend |
1.2375+ |
| Memtest-86 v4.0a | 1.2375+ |
Что ж, при таком раскладе картина уже более ясна, и появляется возможность выявить наиболее подходящие тесты стабильности. Таковыми оказались Prime 95 в режиме Blend, Memtest-86, а также Linpack последней версии в режиме с доступной памятью 6144 Мбайта.
Мониторинг температурного режима – больная тема для Trinity, получаемые цифры сильно зависят от утилит мониторинга, причем все любят показывать для состояния простоя температуры ниже комнатных. При замерах температур использовалась утилита, идущая в комплекте с материнской платой – Gigabyte ET6.
Для того, чтобы более адекватно оценить разницу в результатах, были использованы сразу три различных уровня напряжения: 1.4 В, 1.5 В и 1.5875 В. Система охлаждения – Zalman CNPS10X Performa.
| Тест | Пиковое значение температуры процессора при 1.4 В |
Пиковое значение температуры процессора при 1.5 В |
Пиковое значение температуры процессора при 1.5875 В |
| LinX 0.6.4, 2560 Мбайт |
48 | 63 | 85 |
| LinX 0.6.4, 1024 Мбайт + Linpack 11.0.1.005 |
46 | 60 | 83 |
| LinX 0.6.4, 2560 Мбайт + Linpack 11.0.1.005 |
48 | 61 | 84 |
| LinX 0.6.4, 6144 Мбайт + Linpack 11.0.1.005 |
47 | 61 | 85 |
| OCCT 4.3.2.b01, LINPACK + AVX |
48 | 62 | 84 |
| OCCT 4.3.2.b01, Large Data Set |
48 | 62 | 78 |
| OCCT 4.3.2.b01, Medium Data Set |
47 | 60 | 75 |
| OCCT 4.3.2.b01, Small Data Set |
48 | 63 | 79 |
| Prime 95 v27.7 build2, Small FFTs |
48 | 63 | 79 |
| Prime 95 v27.7 build2, In-place Large FFTs |
49 | 64 | 80 |
| Prime 95 v27.7 build2, Blend |
49 | 64 | 80 |
| CST 0.20.01a | 46 | 60 | 75 |
Интересно, что при разном уровне напряжения питания пиковое значение температуры достигается в различных программах. Так, при 1.4 В и при 1.5 В это Prime 95 в режимах Blend и In-place Large FFTs, а при максимальном значении 1.5875 В в лидерах с разницей в 4-5 градусов уже Linpack тесты. Что интересно – более «горячие» результаты показывает медленная версия Linpack’а. Хотя не исключено, что это просто «причуды» мониторинга.
Вот и подошло время перейти непосредственно к процессу разгона. В данном подразделе статьи изучим зависимость результатов разгона от установленного напряжения питания, а также сравним разгон на воздушном и жидкостном охлаждении, что, сопоставив результаты, позволит выявить зависимость разгона от температурного режима процессора.
Как и ранее, помимо изучения возможностей к увеличению штатной частоты, проверена и работа режимов с заниженным напряжением питания CPU. Точкой отсчета выбрано минимальное напряжение, требуемое для стабильной работы ЦП на частоте 3 ГГц (2994 МГц, с поправкой на точность установки базовой частоты материнской платой).
Результаты A10-5800K с воздушным охлаждением:
Процессор отвечает неплохим ростом частотного потенциала на увеличение напряжения питания вплоть до 1.5 В, после дивиденды от увеличения напряжения питания уже не так велики. Отмечу, что на фоне протестированных ранее старших представителей линеек AMD Bulldozer и AMD Vishera результаты разгона выглядят откровенно слабыми. Тем более что процессорная часть Trinity куда проще, ведь урезана в два раза по количеству ядер, и отсутствует кэш-память третьего уровня. Видимо, все же оказывает влияние наличие встроенной графики, даже когда та не задействована.
К слову, использование встроенной графики вместо внешней видеокарты сколько-нибудь значимых изменений в разгон процессора не привносит. Можно отметить, что достигнутая частота в 4539 МГц не является для стендового ЦП пределом на воздушном охлаждении, просто тут свою лепту вносит материнская плата, не позволяющая изменять его частоту с достаточно низким шагом (следующий шаг частоты – уже 4592 МГц, что ему не под силу). Лишние 20-30 МГц наверняка еще можно было бы «выжать», пусть и с поднятием напряжения питания свыше 1.6 В.
Зависимость температурного режима от напряжения питания процессора:
В целом, слишком сильный рост температур наблюдается лишь при переходе от 1.5375 В к 1.5875 В, в остальных случаях рост температурного режима с увеличением напряжения питания более-менее плавен.
При этом относиться к графику можно двояко. С одной стороны, по форме график вроде и близок к тому, что должен быть, а с другой, крайние точки графика видятся как промахи мониторинга температур, и если с нижними значениями все понятно – показания температуры на уровне комнатной под нагрузкой быть не могут, то с верхними значениями возникает вопрос о предыдущем графике, с результатами максимального разгона процессора.
Получается, что или ЦП устойчив к высоким температурам, и разгон к температурному режиму не критичен, или все же мониторинг не совсем адекватен. С другой стороны, на тех же AMD Vishera рост температур в первую очередь бил по стабильности CPU_NB, или, что вероятнее – по кэш-памяти третьего уровня, которой нет у Trinity. Скорее всего, именно это отличие приводит к возможности стабильной работы процессора при высоких температурах.
С воздушным охлаждением разобрались, самое время рассмотреть результаты разгона при переходе на жидкостное охлаждение:
График для сравнения разгона на воздушном и жидкостном охлаждении:
Разница между максимальными результатами даже с учетом разницы в используемых напряжениях составила лишь чуть более 100 МГц, то есть можно сделать вывод, что вклад температурного режима в результат разгона минимален, и все определяется скорее удачностью конкретно взятого экземпляра процессора, нежели эффективностью системы охлаждения (в разумных пределах). Думаю, что хороший экземпляр A10-5800K мог бы и на воздушном охлаждении показать результат выше, нежели используемый ЦП с жидкостным охлаждением. Что касается максимальной разницы в результатах разгона при одном уровне напряжения питания, то это 65 МГц, что находится на равном с протестированным ранее FX-8350 уровне.
Зависимость температурного режима от напряжения питания процессора:
Разница по сравнению с воздушным охлаждением весьма заметна только при высоких напряжениях, к примеру, при равном напряжении 1.5875 В разница между воздушным и жидкостным охлаждением составляет 21 градус. При этом отличия видны не только в цифрах, но и в самой форме графика, который стал более плавным на всем своем протяжении. Интересно, что в конце графика изгиб уже начинает усиливаться, и, вероятно, следующий шаг напряжения уже привел бы к скачку температуры, сравнимому с переходом на 1.5875 В при воздушном охлаждении. При всем при этом, температура у основания водоблока колебалась на уровне комнатной.
Напоследок приведу сравнение температурного режима при воздушном и жидкостном охлаждении:
По графику видно, что до уровня 1.5375 В разница не такая уж и большая, несмотря на отличие в эффективности систем охлаждения. Возможно, проблема заключается в малой площади кристалла, и в не самом лучшем отводе тепла от него к теплораспределителю. Нечто подобное можно видеть у процессоров Intel Ivy Bridge. Ведь судя по температуре у основания водоблока, да и по температуре воздуха, выходящего из CNPS10X Performa, можно сделать вывод о том, что у A10-5800K не такой уж и горячий нрав, как можно видеть по температурным графикам.
В данном подразделе статьи изучим зависимость результатов разгона CPU_NB от установленного напряжения питания. Как и в случае с разгоном процессора, произведено и сравнение результатов разгона в зависимости от системы охлаждения.
Точкой отсчета взято минимальное напряжение питания, при котором система стабильна на штатной частоте CPU_NB в 1800 МГц (1797 МГц, с поправкой на точность установки базовой частоты материнской платой).
Результат разгона CPU_NB явно лучше, чем у протестированного ранее FX-8350, но в то же время разгон слабее, нежели у моделей AMD Bulldozer. Можно отметить явную разницу в поведении процессоров – если представители AMD Bulldozer и AMD Vishera на увеличение напряжения CPU_NB свыше 1.3-1.35 В отзывались не слишком охотно, то здесь график почти не меняет вида и при переходе от 1.4 В к 1.45 В. Отсутствие кэш-памяти третьего уровня на поведении ЦП сказывается заметно. Но тут главное – в порыве азарта не загубить его высокими напряжениями, и даже несмотря на хороший отклик, для постоянной работы процессора лучше напряжениями не злоупотреблять.
Отмечу, что включение интегрированной графики негативно сказывается на разгоне CPU_NB, в среднем, график смещается примерно на 0.05-0.07 В вправо, без изменения поведения.
Результаты разгона с жидкостным охлаждением:
График для сравнения разгона на воздушном и жидкостном охлаждении:
По сравнению с процессорами AMD Vishera, рост результатов разгона от перехода на жидкостное охлаждение не так велик, и находится примерно на равном с моделями AMD Bulldozer уровне. При этом поведение ЦП остается схожим, резкого увеличения разницы результатов при увеличении напряжения питания не наблюдается. Отдельно отмечу, что при использовании встроенной графики результаты разгона CPU_NB находятся примерно на том же уровне, что и с воздушным охлаждением, то есть при использовании встроенной графики жидкостное охлаждение не приносит выгоды.
С изучением возможностей процессора как конкретно процессора закончили, так что теперь с чистой совестью можно приступить к изучению возможностей встроенной графики.
В данном подразделе статьи выберем программное обеспечение, при помощи которого легче выявить нестабильность встроенной графики, при заведомо стабильных частотах процессора, памяти и CPU_NB. Методика относительно проста: при фиксированном значении напряжения питания подобрать максимальный разгон для каждой из программ и вычислить тест, при котором будет достигнута минимальная частота стабильной работы. Помимо этого, параллельно поиску частот производилась оценка поведения системы при переразгоне. Все тесты производились при штатном напряжении питания встроенной графики 1.2 В.
Вопрос поиска ПО для выявления нестабильности графики довольно сложен, ибо ранее всерьез не рассматривался, так что была попытка охватить максимально возможное количество игр/тестов.
В список попали следующие синтетические тесты:
И следующие игры:
Частота работы встроенной графики, при которой стартует Windows – 1169 МГц.
Таблица с итоговыми результатами разгона для штатного напряжения графического ядра 1.2 В:
| Тест | Итоговый результат разгона встроенной графики, МГц |
Поведение системы при переразгоне на 1 шаг частоты |
Поведение системы при переразгоне на 2 и более шага частоты |
| FurMark 1.10.4 | 1013 | Сброс частоты работы графического ядра до 217 МГц и сообщение «Видеодрайвер перестал отвечать и был успешно восстановлен» | Появление артефактов и последующее зависание системы |
| OCCT 4.3.2, DX9 | 844 | Монотонное закрашивание экрана и зависание системы | Перезагрузка системы после первых секунд теста |
| OCCT 4.3.2, DX10 | 950 | Сброс частоты работы графического ядра до 217 МГц и сообщение «Видеодрайвер перестал отвечать и был успешно восстановлен» | Сброс частоты работы графического ядра до 217 МГц и сообщение «Видеодрайвер перестал отвечать и был успешно восстановлен» |
| 3DMark Vantage | 1013 | Зависание системы в произвольных местах | Зависание системы на первых секундах теста |
| 3DMark 11 | 1013 | Зависание системы в произвольных местах | Зависание системы на первых секундах теста |
| HWBOT Unigine Heaven Benchmark | 1013 | Вылет программы | – |
| GUIMiner v2012-12-03 | 1086 | Остановка вычислений в связи с ошибкой | – |
| Assassin's Creed 3 | 950 | BSOD | Вылет программы, иногда со сбросом частоты работы графического ядра до 217 МГц и сообщением «Видеодрайвер перестал отвечать и был успешно восстановлен» |
| Batman: Arkham City | 1013 | Сброс частоты работы графического ядра до 217 МГц и сообщение «Видеодрайвер перестал отвечать и был успешно восстановлен» | Зависание системы |
| Battlefield 3 | 1013 | Зависание системы | Зависание системы |
| Deus Ex: Human Revolution | 1013 | Сброс частоты работы графического ядра до 217 МГц и сообщение «Видеодрайвер перестал отвечать и был успешно восстановлен» | Зависание системы |
| Dishonored | 950 | Зависание системы | Перезагрузка системы |
| Dirt: Showdown | 1013 | Вылет игры | Зависание системы |
| Dragon Age II | 1013 | Зависание системы | Зависание системы |
| Far Cry 3 | 1013 | Сброс частоты работы графического ядра до 217 МГц и сообщение «Видеодрайвер перестал отвечать и был успешно восстановлен» | Фризы и последующее зависание системы |
| Hitman: Absolution | 1013 | Вылет программы, иногда со сбросом частоты работы графического ядра до 217 МГц и сообщением «Видеодрайвер перестал отвечать и был успешно восстановлен» | Зависание системы |
| Sleeping Dogs | 1013 | Зависание системы | Перезагрузка системы |
| Metro 2033 | 844 | Зависание системы спустя 4-5 минут работы теста | Зависание системы на первом проходе бенчмарка |
| The Elder Scrolls V: Skyrim | 1013 | Зависание системы | Перезагрузка системы |
| The Witcher 2: Assassins of Kings | 1013 | Сброс частоты работы графического ядра до 217 МГц и сообщение «Видеодрайвер перестал отвечать и был успешно восстановлен» | Зависание системы |
| Total War: Shogun 2 | 950 | Вылет программы | Сброс частоты работы графического ядра до 217 МГц и сообщение «Видеодрайвер перестал отвечать и был успешно восстановлен» |
Вообще, перед тем, как приступить к проверке тестов и игр была мысль, что разница между различным ПО будет небольшой, ведь тут накладывается и довольно солидный шаг по изменению частоты работы встроенной графики (напомню, 800 МГц -> 844 МГц -> 894 МГц -> 950 МГц -> 1013 МГц -> 1086 МГц -> 1169 МГц). На деле же оказалось, что разброс очень велик. Наибольшие требования к стабильности системы предъявили такие тесты, как Metro 2033 и OCCT 4.3.2 в режиме DX9.
В качестве теста стабильности была выбрана Metro 2033. Опираясь на возможности материнской платы по изменению частоты работы графического ядра по сравнению с разгоном процессора и CPU_NB в методику пришлось вносить коррективы. Точка отсчета, как и в случае с CPU_NB – минимальное значение напряжения, необходимое для работы графики на штатной частоте (800 МГц). Но в дальнейшем подбиралась не максимальная стабильная частота работы (в зависимости от установленного напряжения), а напряжение, требуемое для каждого последующего шага увеличения частоты.
Итого, результат разгона:
Разгон откровенно слабоват, да и на увеличение напряжения питания отклик слабый. Также отметку наложил и весьма большой шаг изменения частоты. К примеру, при сохранении текущей линии графика, для следующего шага частоты в 1013 МГц надо уже ~1.55 В. Отдельно можно отметить слабость преобразователя питания встроенной графики: помимо Metro 2033 с увеличением напряжения питания был проверен и OCCT 4.3.2 в режиме DX9. Так вот, при напряжении питания 1.28-1.3 В в OCCT система теряет стабильность уже при штатной частоте работы.
Отдельно отмечу, что переход с воздушного охлаждения на жидкостное к улучшению результатов разгона не привел, как и попытки манипуляции с напряжениями питания VCore и CPU_NB. Видимо, все же сказывается общая бюджетность платформы.
Все уже было сказано в статье выше, но необходимо сделать краткое заключение. Для удобства восприятия разобью выводы по пунктам:
Выражаем благодарность: