Моя цель - настроить мини-сервер (не HTPC) с низким энергопотреблением в режиме ожидания, но при этом предлагая хорошую производительность. Основное внимание уделяется безопасности данных, а не доступности. Другими словами: качественные детали, но резервирование только для хранения.

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

Остающиеся вопросы:

• Будет ли состояние простоя графического процессора снизить энергопотребление и высвободить ресурсы для процессора?
• Приведут ли Cool'n'Quiet и Turbo Core к предполагаемому низкому энергопотреблению в режиме ожидания, но производительности под нагрузкой?
• Будет ли Linux поддерживать этот сценарий, как задумано? Довольно много вопросов и обсуждений на форуме, кажется, предполагают, что это не обязательно так.

[Редактировать: Заключительные мысли относительно выбора процессора]

• AMD против AMD:
  • Ричленд здесь работает намного лучше, чем Тринити.
  • Кавери не может конкурировать с рассеиванием мощности в режиме ожидания Ричленда (по крайней мере, пока).
  • Графический процессор A10-6700 может быть переоценен, но немного печально, что он не будет использоваться много. Некоторые алгоритмы могут быть в состоянии использовать свои вычислительные возможности. Не знаю, как это повлияет на энергопотребление процессора.
  • Я подозреваю, что A10-6790K будет тем же процессором, что и A10-6700, но с другим набором параметров для ускорений Turbo Core. Если это правда, A10-6790K сможет увеличить мощность и / или обеспечить более высокие частоты в долгосрочной перспективе благодаря более высокому TDP. Но для этого вам понадобится другой вентилятор процессора (подумайте о пространстве и температуре / сроке службы).
• AMD A10-6700 против Intel Core i3-3220:
  • A10-6700 имеет гораздо большую мощность графического процессора, которая здесь не используется.
  • У i3-3220 меньше рассеиваемая мощность в режиме ожидания.
  • В то время как в типичных тестах i3-3220 быстрее для вычислений, я не могу понять, как два его ядра с гиперпоточностью могли бы обрабатывать параллельные запросы (скажем, к базе данных с веб-интерфейсами) так же быстро, как четыре полнофункциональных ядра (по крайней мере, при условии серьезного кеширования). Однако не нашел никаких серьезных ориентиров - только некоторые признаки.

[Редактировать: параметр бесплатного драйвера radeon bapmустанавливается по умолчанию для систем Kaveri, Kabini и настольных компьютеров Trinity, Richland с Linux 3.16]

Смотрите [pull] radeon drm-fixes-3.16 .

Однако в отношении Debian на базе 3.16 значения по умолчанию не (пока?), Похоже, работают, в то время как параметр загрузки работает. См. Как настроить систему Debian (ориентированную на 2D или консоль / сервер) с AMD Turbo Core APU для максимальной энергоэффективности и вычислительной эффективности?

[Редактировать: у бесплатного драйвера Radeon скоро будет bapmпараметр]

Поскольку суть нижеприведенного заключается в том, чтобы использовать исправленную версию бесплатного radeonдрайвера с вашим APU для поддержки Turbo Core и максимально использовать его (кроме 3D-графики), если это возможно (включение bapmможет привести к нестабильности в некоторых конфигурациях ), это хорошая новость, что в будущих версиях Radeon будет параметр для включения bapm .

[Оригинальный пост следует]

AMD A10-6700 (Richland) APU Опыт

Выбор процессора

Моим первым ПК был 486DX2-66, созданный из десятков 3,5-дюймовых дискет с исходными пакетами Slackware. Итак, многое изменилось, и многие отрасли в настоящее время, похоже, находятся на стадии увеличения числа вариантов продукта.

Это обстоятельство и некоторые неудачные решения AMD в недавнем прошлом не облегчили мне выбор платформы для мини-сервера. Но, наконец, я решил, что A10-6700 будет хорошим выбором:

• Несколько обзоров показали, что (все еще широко недоступный) Kaveri потребляет больше энергии в режиме ожидания, чем Richland или Trinity
• Преимущество Richland A10-6700 над Trinity A10-5700 представляется значительным: более низкая самая низкая и более высокая самая высокая частота, более мелкозернистый Turbo Core (учитывая также температуру - довольно преимущество, когда графический процессор будет простаивать)
• Говорят, что GPU A10-6700 переоценен (маркетинговое наименование), а цена APU кажется справедливой

Другие компоненты и настройка

Несмотря на бесчисленное множество процессоров на выбор, не так много доступных плат Mini-ITX. ASRock FM2A78M-ITX + оказался разумным выбором. Тест был сделан с прошивкой V1.30 (обновлений нет, так как я пишу это).

Только 80% от номинальной мощности блока питания должны быть израсходованы. С другой стороны, многие не работают эффективно при нагрузке ниже 50%. Очень сложно найти энергоэффективный источник питания для системы с расчетным диапазоном рассеиваемой мощности от 35 до 120 Вт. Я провел эти тесты с Seasonic G360 80+ Gold, потому что он превосходит большинство конкурентов по эффективности при низких нагрузках.

Две 8 ГБ ОЗУ DDR3-1866 (сконфигурированные как таковые - что действительно имеет значение по сравнению с 1333), один SSD-накопитель и вентилятор ЦП с контролируемым качеством ШИМ также были частью тестовой установки.

Измерения были выполнены с использованием AVM Fritz! DECT 200, который, как сообщалось, для выполнения точных измерений. Тем не менее, достоверность была подтверждена с использованием старого устройства без имени. Никаких несоответствий выявлено не было. Измеренная рассеиваемая мощность системы будет включать в себя пониженную эффективность блока питания для более низких нагрузок.

Экран [W] QHD был подключен через HDMI.

Начальная общая память для графического процессора была установлена ​​в 32M в BIOS UEFI. Кроме того, встроенный графический процессор был выбран в качестве основного, и IOMMU был включен.

Никакая X или другая графическая система не была установлена ​​или настроена. Вывод видео был ограничен консольным режимом.

основы

Есть несколько вещей, которые нужно знать.

• В то время как решение о Cool'n'Quiet принимается программным обеспечением вне процессоров, Turbo Core - это решение, принимаемое автономно дополнительным микроконтроллером на APU (или CPU).
• Многие инструменты, а также /procи /sysместа не сообщают о деятельности Turbo Core. cpufreq-aperf, cpupower frequency-infoИ cpupower monitorделать, но только после того, как modprobe msr.

Группа тестов 1: Linux + Radeon

Я начал со свежего Arch Linux (установщик 2014.08.01, ядро ​​3.15.7). Ключевым фактором здесь является наличие acpi_cpufreq(масштабирование процессора ядра) и radeon(драйвер ядра GPU) и простой способ исправления radeon.

Тестовый пример 1.1: BIOS TC включен - CnQ включен / Linux OnDemand - Boost

UEFI BIOS Turbo Core Настройка ............................ Включено
Настройка UEFI BIOS Cool'n'Quiet .......................... Включена
/ sys / devices / system / cpu / cpufreq / boost ................... 1
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... ondemand 

"cpupowerquency-info" Pstates ....... 4300 4200 3900 3700 3400 2700 2300 1800
Наблюдаемый диапазон процессоров "/ proc / cpuinfo" МГц ... 1800 - 3700
Наблюдаемый "монитор мощности процессора" Freq range ... 1800 - 3700
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... уровень мощности 0

Загрузить | Core Freqs
--------------- + -----------
стресс - CPU 1 | 1 х 3700
стресс - CPU 2 | 2 х 3700
стресс - процессор 3 | 3 х 3700
стресс - процессор 4 | 4 х 3700

Тестовый пример 1.2: BIOS TC включен - CnQ on / производительность Linux - Boost

UEFI BIOS Turbo Core Настройка ............................ Включено
Настройка UEFI BIOS Cool'n'Quiet .......................... Включена
/ sys / devices / system / cpu / cpufreq / boost ................... 1
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... производительность 

"cpupowerquency-info" Pstates ....... 4300 4200 3900 3700 3400 2700 2300 1800
Наблюдаемый диапазон процессоров "/ proc / cpuinfo" МГц ... 3700
Наблюдаемый "cpupower monitor" Freq range ... 2000 - 3700
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... уровень мощности 0

Загрузить | Core Freqs
--------------- + -----------
стресс - CPU 1 | 1 х 3700
стресс - CPU 2 | 2 х 3700
стресс - процессор 3 | 3 х 3700
стресс - процессор 4 | 4 х 3700

Сводка тестов группы 1

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

Тестовый набор Group 2: Linux + BAPM-патч Radeon

Для того чтобы bapmя начал с новой Arch Linux (установщиком 2014.08.01, ядро 3.15.7), у меня core linuxпакет с помощью ABS(3.15.8), редактировал PKGBUILDдля использования pkgbase=linux-tc, натянул источники с makepkg --nobuild, измененные pi->enable_bapm = true;в trinity_dpm_init()в src/linux-3.15/drivers/gpu/drm/radeon/trinity_dpm.cи скомпилировал это с makepkg --noextract. Затем я установил его ( pacman -U linux-tc-headers-3.15.8-1-x86_64.pkg.tar.xzи pacman -U linux-tc-3.15.8-1-x86_64.pkg.tar.xz) и обновил GRUB( grub-mkconfig -o /boot/grub/grub.cfgно, конечно же, YMMV).

В результате мне дали выбор загрузить linuxили linux-tc, и последующие тесты относятся к последнему.

Тестовый пример 2.1: BIOS TC включен - CnQ включен / Linux OnDemand - Boost

UEFI BIOS Turbo Core Настройка ............................ Включено
Настройка UEFI BIOS Cool'n'Quiet .......................... Включена
/ sys / devices / system / cpu / cpufreq / boost ................... 1
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... ondemand 

"cpupowerquency-info" Pstates ....... 4300 4200 3900 3700 3400 2700 2300 1800
Наблюдаемый диапазон процессоров "/ proc / cpuinfo" МГц ... 1800 - 3700
Наблюдаемый "cpupower monitor" диапазон частот ... 1800 - 4300
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... уровень мощности 0

Загрузить | Core Freqs
--------------- + -----------------
стресс - CPU 1 | 1 х 4300
стресс - CPU 2 | 2 х 4200 .. 4100
стресс - процессор 3 | 3 х 4100 .. 3900
стресс - процессор 4 | 4 х 4000 .. 3800

Тестовый пример 2.2: BIOS TC включен - CnQ on / производительность Linux - Boost

UEFI BIOS Turbo Core Настройка ............................ Включено
Настройка UEFI BIOS Cool'n'Quiet .......................... Включена
/ sys / devices / system / cpu / cpufreq / boost ................... 1
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... Performace

"cpupowerquency-info" Pstates ....... 4300 4200 3900 3700 3400 2700 2300 1800
Наблюдаемый диапазон процессоров "/ proc / cpuinfo" МГц ... 3700
Наблюдаемый "cpupower monitor" Freq range ... 2000 - 4300
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... уровень мощности 0

Загрузить | Core Freqs
--------------- + -----------------
стресс - CPU 1 | 1 х 4300
стресс - CPU 2 | 2 х 4200 .. 4100
стресс - процессор 3 | 3 х 4100 .. 3900
стресс - процессор 4 | 4 х 4000 .. 3800

Тестовый пример 2.3: BIOS TC включен - CnQ включен / Linux OnDemand - без повышения

UEFI BIOS Turbo Core Настройка ............................ Включено
Настройка UEFI BIOS Cool'n'Quiet .......................... Включена
/ sys / devices / system / cpu / cpufreq / boost ................... 0
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... ondemand

"cpupowerquency-info" Pstates ....... 4300 4200 3900 3700 3400 2700 2300 1800
Наблюдаемый диапазон процессоров "/ proc / cpuinfo" МГц ... 1800 - 3700
Наблюдаемый "монитор мощности процессора" Freq range ... 1800 - 3700
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... уровень мощности 1

Загрузить | Core Freqs
--------------- + -----------
стресс - CPU 1 | 1 х 3700
стресс - CPU 2 | 2 х 3700
стресс - процессор 3 | 3 х 3700
стресс - процессор 4 | 4 х 3700

Тестовый пример 2.4: BIOS TC включен - CnQ on / производительность Linux - без повышения

UEFI BIOS Turbo Core Настройка ............................ Включено
Настройка UEFI BIOS Cool'n'Quiet .......................... Включена
/ sys / devices / system / cpu / cpufreq / boost ................... 0
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... Performace

"cpupowerquency-info" Pstates ....... 4300 4200 3900 3700 3400 2700 2300 1800
Наблюдаемый диапазон процессоров "/ proc / cpuinfo" МГц ... 3700
Наблюдаемый "cpupower monitor" Freq range ... 2000 - 3700
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... уровень мощности 1

Загрузить | Core Freqs
--------------- + -----------
стресс - CPU 1 | 1 х 3700
стресс - CPU 2 | 2 х 3700
стресс - процессор 3 | 3 х 3700
стресс - процессор 4 | 4 х 3700

Тестовый пример 2.5: BIOS TC выключен - CnQ включен / Linux OnDemand - Boost

UEFI BIOS Turbo Core Настройка ............................ Отключено
Настройка UEFI BIOS Cool'n'Quiet .......................... Включена
/ sys / devices / system / cpu / cpufreq / boost ................... 1
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... ondemand 

"cpupowerquency-info" Pstates ....... 4300 4200 3900 3700 3400 2700 2300 1800
Наблюдаемый диапазон процессоров "/ proc / cpuinfo" МГц ... 1800 - 3700
Наблюдаемый "монитор мощности процессора" Freq range ... 1800 - 3700
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... уровень мощности 0

Другими словами, если Turbo Core отключен в BIOS, исправленный radeonне включит его.

Тестовый пример 2.6: BIOS TC включен - CnQ выключен / Linux нет

UEFI BIOS Turbo Core Настройка ............................ Включено
UEFI BIOS Cool'n'Quiet Настройка .......................... Отключено
/ sys / devices / system / cpu / cpufreq / boost ................... н / д
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... н / п

"cpupowerquency-info" Pstates ....... 4300 4200 3900 3700 3400 2700 2300 1800
Наблюдаемый диапазон процессоров "/ proc / cpuinfo" МГц ... 3700
Наблюдаемый "cpupower monitor" Freq range ... 2000 - 4300
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... уровень мощности 0

Загрузить | Core Freqs
--------------- + -----------------
стресс - CPU 1 | 1 х 4300
стресс - CPU 2 | 2 х 4100 .. 4000
стресс - процессор 3 | 3 х 4000 .. 3800
стресс - процессор 4 | 4 х 3900 .. 3700

При отключенном Cool'n'Qiet ядро ​​Linux не будет предлагать никакого выбора регулятора и (ошибочно) полагать, что ядра работают с фиксированной частотой. Интересно, что полученные частоты Turbo Core являются худшими из всех протестированных комбинаций в тестовом наборе 2-й группы.

Сводка тестов группы 2

С пропатченным radeonдрайвером работает Turbo Core. Никакой нестабильности (которая является причиной того, что bapmTurbo Core там отключен) до сих пор замечено не было.

Контрольная группа 3: Linux + fglrx (катализатор)

Я начал со свежей установки Ubuntu (14.04 Server, ядро ​​3.13), которая, на мой взгляд, сопоставима с Arch Linux (установщик 2014.08.01, ядро ​​3.15.7) из-за наличия acpi_cpufreq(масштабирование ЦП ядра) и radeon(драйвер GPU ядра) ). Причиной перехода на Ubuntu является простота установки fglrx. Я проверил энергопотребление и поведение с новой установкой, которая использует radeon.

Я установил fglrxиз командной строки ( sudo apt-get install linux-headers-generic, sudo apt-get install fglrx) и перезагрузил систему. Изменение от radeonк fglrxсразу становится очевидным как в отношении внешнего вида консоли ( fglrx: 128 x 48,: radeonнамного выше), так и в энергопотреблении в режиме ожидания ( fglrx: 40 radeonВт,: 30 Вт). Но Turbo Core работает сразу.

Тестовый пример 3.1: BIOS TC включен - CnQ включен / Linux OnDemand - Boost

UEFI BIOS Turbo Core Настройка ............................ Включено
Настройка UEFI BIOS Cool'n'Quiet .......................... Включена
/ sys / devices / system / cpu / cpufreq / boost ................... 1
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... ondemand 

"cpupowerquency-info" Pstates ....... 4300 4200 3900 3700 3400 2700 2300 1800
Наблюдаемый диапазон процессоров "/ proc / cpuinfo" МГц ... 1800 - 3700
Наблюдаемый "cpupower monitor" диапазон частот ... 1800 - 4300
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... н / д

Загрузить | Core Freqs
--------------- + ----------------------------
стресс - CPU 1 | 1 х 4300
стресс - CPU 2 | 2 х 4200 .. 3900 (ядро chg)
стресс - процессор 3 | 3 х 4100 .. 3700
стресс - процессор 4 | 4 х 4000 .. 3600

fglrxПоведение, безусловно , интересно. Когда для любого из тестовых случаев в любой группе тестовых случаев вызывался стресс - cpu 2, два загруженных ядра всегда располагались в отдельных модулях. Но при этом fglrxпроизошло внезапное перераспределение, так что был использован один модуль (что экономит довольно много энергии, см. Ниже). Через некоторое время загруженное ядро ​​вернулось к другому модулю. Это не было видно с radeon. Может быть, это fglrxманипулирует сродством ядра процессов?

Сводная группа по тестированию 3

Преимущество fglrxзаключается в том, что он позволяет Turbo Core сразу, без необходимости его исправления.

Поскольку fglrxв нашем сценарии на чипе с TDP 65 Вт расходуется от 10 до 12 Вт на графический процессор, общие результаты в отношении доступных скоростей ядра не впечатляют. Поэтому дальнейшие испытания не проводились.

Также с инженерной точки зрения поведение fglrxвыглядит немного грустным. Перераспределение одного из двух занятых ядер на другой модуль для поддержания более высокой частоты может быть или не быть хорошей идеей, потому что до этого шага оба ядра имели собственный кэш L2, а после этого им приходилось делить одно. fglrxРассматривает ли какие-либо метрики (например, пропуски попаданий в кэш) в поддержку своего решения, необходимо будет уточнить отдельно, но есть и другие отчеты о его неожиданном поведении .

Краткое изложение энергопотребления

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

Система @State / -> Переход Дельта | Рассеиваемая мощность системы
------------------------------------- + ------------ -------------
  @BIOS | @ 95 .. 86 Вт
  @ Bootloader | @ 108 .. 89 Вт
  Инсталлятор @Ubuntu простаивает | @ 40 Вт
  @Linux Radeon Idle ondemand | @ 30 Вт
  @Linux Radeon Idle Performance | @ 30 Вт
  @Linux fglrx Idle ondemand | @ 40 Вт
  1 модуль 1800 -> 3700 | + 13 Вт
  1 модуль 1800 -> 4300 | + 25 Вт
  1 Core 1800 -> 3700 | + 5 Вт
  1 Core 1800 -> 4300 | + 10 Вт
  Видео выход "radeon" -> Отключить | - 2 Вт
  Видеовыход 'fglrx' -> Darken | + - 0W
  @Linux Radeon Maximum | @ 103 .. 89 Вт
  @Linux fglrx Максимум | @ 105 .. 92 Вт

• Похоже, что в Turbo Core (по крайней мере, с APU Richland) есть больше, чем ожидалось: при использовании регулятора масштабирования «по требованию» заметной разницы в рассеянии мощности нет по сравнению с тем, когда установлен регулятор производительности. Althouth /proc/cpuinfoвсегда будет сообщать о частоте 37000 МГц при использовании регулятора производительности, сообщая, cpupower monitorчто ядра действительно замедляются. В некоторых случаях были показаны частоты до 2000 МГц; возможно, что 1800 МГц будет использоваться и для внутреннего использования.
• A10-6700 состоит из двух модулей с двумя ядрами в каждом. Если, например, два ядра простаивают и два ядра заняты и ускоряются, поведение системы будет отличаться в зависимости от того, расположены ли занятые ядра на одном и том же модуле или нет.
  • Ускорение модуля является более энергоемким, чем ускорение ядра.
  • Кэш-память второго уровня назначается для каждого модуля.
• Разницу между рассеиваемой мощностью двух ядер, ускоряющихся на одном и том же модуле, и разными модулями определяли путем замены stress --cpu 2(которая всегда приводила к распределению между двумя модулями) на .taskset -c 0 stress --cpu 1andtaskset -c 1 stress --cpu 1
• Кажется, у A10-6700 есть предел полного рассеивания мощности для APU (92 Вт вместе с другими компонентами) с небольшим битом, зарезервированным для одного GPU (3 Вт). При radeonэтом это позволит получить большее в течение короткого периода и очень плавно уменьшится до максимума, в то время как при fglrxэтом было замечено, что эти пределы превышаются более значительно, а рассеиваемая мощность затем резко уменьшается.
• В то время как многие люди утверждают, что задержка в доступности Kaveri предназначена AMD, потому что это убило бы их текущие APU, я позволю себе не согласиться. Richland A10 продемонстрировал превосходное управление питанием, и Kaveri не может конкурировать с низким энергопотреблением в режиме ожидания (сложность чипа Kaveri почти вдвое выше, чем у Richland, поэтому потребуется еще один или два этапа разработки).

Общий вывод

• Включение температуры в логику Turbo Core (как сообщается для шага Trinity -> Richland), кажется, имеет смысл и, по-видимому, работает хорошо, что видно по уменьшению рассеивания энергии в BIOS и Bootloader с течением времени.
• Для сценария cosole / server A10-6700 поддерживает 4 ядра на частоте 3700 МГц (3800 МГц с Turbo Core) в течение длительного времени, по крайней мере, с radeonдрайвером. Вероятно, не так много шансов сохранить этот уровень производительности, когда графическому процессору нужно выполнить какую-то работу.
• Казалось бы, TDP 65 Вт может постоянно превышаться при полной нагрузке, но трудно сказать, так как блок питания имеет более низкую эффективность при 30 Вт. Поскольку имеются явные признаки того, что температура считается (пиковая мощность рассеяния почти 110 Вт наблюдалась до того, как ее начали снижать до 90 Вт, а также сообщалось о 2 ядрах на 4300 МГц в течение некоторого времени), инвестирование в охлаждение APU может быть отличная идея. Тем не менее, материнские платы, ограниченные TDP до 65 Вт, смогут подавать только такой большой ток, поэтому APU определенно будет иметь жесткие ограничения.
• Если вы намереваетесь использовать Richland APU для вычислений в Linux, вам определенно нужно использовать пропатченный radeonдрайвер (если вы не сталкиваетесь с нестабильностью - особенно в сочетании с включением Dynamic Power Management). В противном случае вы не получите полную стоимость.
• Как ни странно, кажется, что лучшей настройкой было бы включить Turbo Core и Cool'n'Quiet в BIOS, но затем выбрать performanceрегулятор масштабирования - по крайней мере, если ваш APU ведет себя так же, как тот, что был здесь протестирован. Вы будете иметь то же энергопотребление, что и при ondemandболее быстром масштабировании частоты и меньших издержках ядра, чтобы принять решение о масштабировании.

Подтверждения

Особая благодарность выражается Алексу Деучеру, который значительно подтолкнул меня в правильном направлении на bugzilla.kernel.org .

Я впечатлен качеством бесплатного radeonдрайвера и хотел бы поблагодарить всю команду за поддержку этого программного обеспечения, которое, похоже, продуманно разработано. Если radeonбы не вел себя так, как он, мое решение в пользу A10-6700 было бы по существу неверным.