Il mio obiettivo è quello di installare un mini server (non HTPC) con un basso consumo energetico in modalità inattiva, offrendo comunque buone prestazioni quando utilizzato. L'attenzione si concentra più sulla sicurezza dei dati che sulla disponibilità. In altre parole: parti di qualità, ma ridondanza solo per la conservazione.

Non considerandomi di parte, dopo alcune ricerche ho sentito che alcune APU desktop AMD avrebbero offerto un buon valore.

Le domande rimanenti sono:

• Lo stato di inattività della GPU ridurrà il consumo energetico e libererà risorse per la CPU?
• Cool'n'Quiet e Turbo Core porteranno al consumo di energia basso previsto in modalità inattiva ma a prestazioni sotto carico?
• Linux supporterà questo scenario come previsto? Molte domande e discussioni sul forum sembrano suggerire che questo non è necessariamente il caso.

[Modifica: pensieri conclusivi sulla scelta del processore]

• AMD vs AMD:
  • Richland fa un lavoro molto migliore di Trinity qui.
  • Kaveri non può competere con la dissipazione di potenza in modalità di riposo di Richland (almeno per ora).
  • La GPU dell'A10-6700 potrebbe essere sopravvalutata, ma è un po 'triste che non verrà utilizzata molto. Alcuni algoritmi potrebbero essere in grado di distribuire il suo potere computazionale. Tuttavia, non ho idea di come ciò influirà sul consumo di energia del processore.
  • Sospetto che l'A10-6790K sia lo stesso processore dell'A10-6700 con solo un diverso set di parametri per i potenziamenti Turbo Core. Se questo è vero, A10-6790K sarà in grado di aumentare il tempo e / o fornire frequenze più elevate a lungo termine grazie al suo TDP più elevato. Ma per questo avrai bisogno di una diversa ventola della CPU (pensa a spazio e temperatura / durata).
• AMD A10-6700 vs Intel Core i3-3220:
  • L'A10-6700 ha molta più potenza della GPU, che non viene utilizzata qui.
  • L'i3-3220 ha una dissipazione di potenza in modalità inattiva inferiore.
  • Mentre nei benchmark tipici l'i3-3220 è più veloce per i calcoli, non riesco a vedere come i suoi due core hyper-threading sarebbero in grado di gestire richieste parallele (diciamo, a un database con front-end web) con la stessa velocità di quattro core con funzionalità complete (almeno quando si assume una certa memorizzazione nella cache). Non ho trovato parametri di riferimento seri, però - Solo alcune indicazioni.

[Modifica: il bapmparametro del driver radeon gratuito è impostato di default per i sistemi Kaveri, Kabini e desktop Trinity, Richland a partire da Linux 3.16]

Vedi [pull] radeon drm-fixes-3.16 .

Tuttavia, per quanto riguarda Debian basato su 3.16, le impostazioni predefinite non sembrano (ancora?) Funzionare, mentre il parametro boot lo fa. Vedi Come configurare un sistema Debian (focus su 2D o console / server) con un'APU AMD Turbo Core per la massima efficienza energetica ed informatica?

[Modifica: il driver radeon gratuito avrà presto un bapmparametro]

Poiché la linea di fondo di seguito è utilizzare una versione patchata del radeondriver gratuito con la tua APU per supportare Turbo Core e ottenere il massimo (tranne la grafica 3D) se possibile (l'abilitazione bapmpuò portare a instabilità in alcune configurazioni ), è una grande notizia che le versioni future di radeon avranno un parametro per abilitare bapm .

[Post originale segue]

Esperienza APU AMD A10-6700 (Richland)

Scelta del processore

Il mio primo PC è stato un 486DX2-66 impostato da dozzine di floppy disk da 3,5 "contenenti pacchetti sorgente Slackware. In alcuni casi, molte cose sono cambiate e molte industrie sembrano essere nella fase in cui continuano ad aumentare il numero delle varianti di prodotto.

Questa circostanza e alcune delle sfortunate decisioni di AMD nel recente passato non mi hanno reso più semplice decidere su una piattaforma per un mini server. Ma alla fine, ho deciso che la A10-6700 sarebbe stata una buona scelta:

• Diverse recensioni hanno dimostrato che un Kaveri (ancora ampiamente non disponibile) consumerà più energia in modalità inattiva rispetto a un Richland o un Trinity
• Il vantaggio del Richland A10-6700 rispetto al Trinity A10-5700 sembra essere significativo: frequenza più bassa sempre più alta e più alta, Turbo Core a grana più fine (considerando anche la temperatura - un bel vantaggio quando la GPU sarà inattiva)
• Si dice che la GPU dell'A10-6700 sia sopravvalutata (denominazione orientata al marketing) e il prezzo dell'APU sembra giusto

Altri componenti e impostazioni

Nonostante gli innumerevoli processori tra cui scegliere, non ci sono molte schede Mini-ITX disponibili. L'ASRock FM2A78M-ITX + sembrava essere una scelta ragionevole. Il test è stato eseguito con il firmware V1.30 (nessun aggiornamento disponibile mentre scrivo questo).

Solo l'80% della potenza nominale di un alimentatore dovrebbe essere consumato. D'altra parte, molti non riescono a lavorare in modo efficiente con un carico inferiore al 50%. È molto difficile trovare un alimentatore ad alta efficienza energetica per un sistema con un intervallo di dissipazione di potenza stimato da 35W a 120W. Ho condotto questi test con un Seasonic G360 80+ Gold perché supera la maggior parte dei concorrenti per quanto riguarda l'efficienza a bassi carichi.

Anche due RAM DDR3-1866 da 8 GB (configurate come tali - che fanno la differenza rispetto al 1333), un'unità SSD e una ventola CPU di qualità di controllo PWM facevano parte della configurazione del test.

Le misurazioni sono state eseguite utilizzando un AVM Fritz! DECT 200 che è stato segnalato per eseguire misurazioni accurate. Tuttavia, la plausibilità è stata convalidata utilizzando un vecchio dispositivo senza nome. Non è stato possibile identificare incoerenze. La dissipazione di potenza del sistema misurata includerà l'efficienza ridotta dell'alimentatore per carichi inferiori.

Uno schermo [W] QHD è stato collegato tramite HDMI.

La memoria iniziale condivisa per la GPU è stata impostata su 32M nel BIOS UEFI. Inoltre, la GPU integrata è stata selezionata come primaria e IOMMU è stato abilitato.

Nessuna X o altro sistema grafico è stato installato o configurato. L'uscita video era limitata alla modalità console.

Nozioni di base

Ci sono alcune cose che bisogna sapere.

• Mentre la decisione su Cool'n'Quiet viene presa da un software esterno ai processori, Turbo Core è una decisione presa autonomamente da un microcontrollore aggiuntivo sull'APU (o CPU).
• Molti strumenti /proce /sysluoghi non riportano l'attività di Turbo Core. cpufreq-aperf, cpupower frequency-infoe cpupower monitorfallo, ma solo dopo modprobe msr.

Test Case Group 1: Linux + radeon

Ho iniziato con Arch Linux nuovo (programma di installazione 2014.08.01, kernel 3.15.7). Il fattore chiave qui è la presenza di acpi_cpufreq(scaling della CPU del kernel) e radeon(driver GPU del kernel) e il modo semplice di applicare patch radeon.

Caso di prova 1.1: BIOS TC on - CnQ on / Linux OnDemand - Boost

Impostazione UEFI BIOS Turbo Core ............................ Abilitato
Impostazione Cool'n'Quiet del BIOS UEFI .......................... Abilitato
/ sys / devices / system / cpu / cpufreq / boost ................... 1
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... ondemand 

"Informazioni sulla frequenza cpupower" ... 4300 4200 3900 3700 3400 2700 2300 1800
Intervallo cpu MHz "/ proc / cpuinfo" osservato ... 1800 - 3700
Intervallo Freq "monitor cpupower" osservato ... 1800 - 3700
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... livello di potenza 0

Carica | Core Freqs
--------------- + -----------
stress --cpu 1 | 1 x 3700
stress --cpu 2 | 2 x 3700
stress --cpu 3 | 3 x 3700
stress --cpu 4 | 4 x 3700

Caso di prova 1.2: BIOS TC on - Prestazioni CnQ on / Linux - Boost

Impostazione UEFI BIOS Turbo Core ............................ Abilitato
Impostazione Cool'n'Quiet del BIOS UEFI .......................... Abilitato
/ sys / devices / system / cpu / cpufreq / boost ................... 1
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... performance 

"Informazioni sulla frequenza cpupower" ... 4300 4200 3900 3700 3400 2700 2300 1800
Gamma di CPU cpu "/ proc / cpuinfo" osservata ... 3700
Gamma Freq osservata "cpupower monitor" ... 2000 - 3700
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... livello di potenza 0

Carica | Core Freqs
--------------- + -----------
stress --cpu 1 | 1 x 3700
stress --cpu 2 | 2 x 3700
stress --cpu 3 | 3 x 3700
stress --cpu 4 | 4 x 3700

Riepilogo gruppo casi di test 1

I boost basati su Turbo Core sono impossibili in questo scenario perché il radeondriver attualmente disabilita la bapmbandiera a causa di problemi di stabilità in alcuni scenari . Pertanto, sono stati saltati ulteriori test.

Test Case Group 2: Linux + radeon con patch bapm

Al fine di consentire bapm, ho iniziato con un nuovo Arch Linux (installazione 2014/08/01, kernel 3.15.7), mi ha fatto il core linuxpacchetto tramite ABS(3.15.8), a cura l' PKGBUILDuso pkgbase=linux-tc, tirato le fonti con makepkg --nobuild, cambiato pi->enable_bapm = true;in trinity_dpm_init()a src/linux-3.15/drivers/gpu/drm/radeon/trinity_dpm.c, e compilato con makepkg --noextract. Quindi, l'ho installato ( pacman -U linux-tc-headers-3.15.8-1-x86_64.pkg.tar.xze pacman -U linux-tc-3.15.8-1-x86_64.pkg.tar.xz) e aggiornato GRUB( grub-mkconfig -o /boot/grub/grub.cfgma, ovviamente, YMMV).

Di conseguenza, mi è stata data la scelta di avviare linuxo linux-tc, e i seguenti test si riferiscono a quest'ultimo.

Caso di prova 2.1: BIOS TC on - CnQ on / Linux OnDemand - Boost

Impostazione UEFI BIOS Turbo Core ............................ Abilitato
Impostazione Cool'n'Quiet del BIOS UEFI .......................... Abilitato
/ sys / devices / system / cpu / cpufreq / boost ................... 1
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... ondemand 

"Informazioni sulla frequenza cpupower" ... 4300 4200 3900 3700 3400 2700 2300 1800
Intervallo cpu MHz "/ proc / cpuinfo" osservato ... 1800 - 3700
Intervallo Freq "monitor cpupower" osservato ... 1800 - 4300
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... livello di potenza 0

Carica | Core Freqs
--------------- + -----------------
stress --cpu 1 | 1 x 4300
stress --cpu 2 | 2 x 4200 .. 4100
stress --cpu 3 | 3 x 4100 .. 3900
stress --cpu 4 | 4 x 4000 .. 3800

Caso di prova 2.2: BIOS TC on - CnQ on / Prestazioni Linux - Boost

Impostazione UEFI BIOS Turbo Core ............................ Abilitato
Impostazione Cool'n'Quiet del BIOS UEFI .......................... Abilitato
/ sys / devices / system / cpu / cpufreq / boost ................... 1
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... performace

"Informazioni sulla frequenza cpupower" ... 4300 4200 3900 3700 3400 2700 2300 1800
Gamma di CPU cpu "/ proc / cpuinfo" osservata ... 3700
Intervallo Freq "monitor cpupower" osservato ... 2000 - 4300
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... livello di potenza 0

Carica | Core Freqs
--------------- + -----------------
stress --cpu 1 | 1 x 4300
stress --cpu 2 | 2 x 4200 .. 4100
stress --cpu 3 | 3 x 4100 .. 3900
stress --cpu 4 | 4 x 4000 .. 3800

Test Case 2.3: BIOS TC on - CnQ on / Linux OnDemand - No Boost

Impostazione UEFI BIOS Turbo Core ............................ Abilitato
Impostazione Cool'n'Quiet del BIOS UEFI .......................... Abilitato
/ sys / devices / system / cpu / cpufreq / boost ................... 0
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... ondemand

"Informazioni sulla frequenza cpupower" ... 4300 4200 3900 3700 3400 2700 2300 1800
Intervallo cpu MHz "/ proc / cpuinfo" osservato ... 1800 - 3700
Intervallo Freq "monitor cpupower" osservato ... 1800 - 3700
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... livello di potenza 1

Carica | Core Freqs
--------------- + -----------
stress --cpu 1 | 1 x 3700
stress --cpu 2 | 2 x 3700
stress --cpu 3 | 3 x 3700
stress --cpu 4 | 4 x 3700

Caso di prova 2.4: BIOS TC on - Prestazioni CnQ on / Linux - No Boost

Impostazione UEFI BIOS Turbo Core ............................ Abilitato
Impostazione Cool'n'Quiet del BIOS UEFI .......................... Abilitato
/ sys / devices / system / cpu / cpufreq / boost ................... 0
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... performace

"Informazioni sulla frequenza cpupower" ... 4300 4200 3900 3700 3400 2700 2300 1800
Gamma di CPU cpu "/ proc / cpuinfo" osservata ... 3700
Gamma Freq osservata "cpupower monitor" ... 2000 - 3700
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... livello di potenza 1

Carica | Core Freqs
--------------- + -----------
stress --cpu 1 | 1 x 3700
stress --cpu 2 | 2 x 3700
stress --cpu 3 | 3 x 3700
stress --cpu 4 | 4 x 3700

Caso di prova 2.5: BIOS TC off - CnQ on / Linux OnDemand - Boost

Impostazione UEFI BIOS Turbo Core ............................ Disabilitato
Impostazione Cool'n'Quiet del BIOS UEFI .......................... Abilitato
/ sys / devices / system / cpu / cpufreq / boost ................... 1
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... ondemand 

"Informazioni sulla frequenza cpupower" ... 4300 4200 3900 3700 3400 2700 2300 1800
Intervallo cpu MHz "/ proc / cpuinfo" osservato ... 1800 - 3700
Intervallo Freq "monitor cpupower" osservato ... 1800 - 3700
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... livello di potenza 0

In altre parole, se Turbo Core è disabilitato nel BIOS, la patch radeonnon lo accenderà.

Caso di prova 2.6: BIOS TC on - CnQ off / Linux n / a

Impostazione UEFI BIOS Turbo Core ............................ Abilitato
Impostazione Cool'n'Quiet BIOS UEFI .......................... Disabilitata
/ sys / devices / system / cpu / cpufreq / boost ................... n / a
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... n / a

"Informazioni sulla frequenza cpupower" ... 4300 4200 3900 3700 3400 2700 2300 1800
Gamma di CPU cpu "/ proc / cpuinfo" osservata ... 3700
Intervallo Freq "monitor cpupower" osservato ... 2000 - 4300
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... livello di potenza 0

Carica | Core Freqs
--------------- + -----------------
stress --cpu 1 | 1 x 4300
stress --cpu 2 | 2 x 4100 .. 4000
stress --cpu 3 | 3 x 4000 .. 3800
stress --cpu 4 | 4 x 3900 .. 3700

Con Cool'n'Qiet disabilitato, il kernel di Linux non offrirà alcuna scelta del governatore e (erroneamente) supporrà che i core funzionino a una frequenza fissa. È interessante notare che le frequenze Turbo Core risultanti sono le peggiori di tutte le combinazioni testate nel Test Case Group 2.

Riepilogo gruppo casi di test 2

Con il radeondriver con patch , Turbo Core funziona. Nessuna instabilità (che è la ragione per cui bapmanche il Turbo Core è disabilitato lì) è stata vista finora.

Test Case Group 3: Linux + fglrx (catalizzatore)

Ho iniziato con una nuova installazione di Ubuntu (14.04 Server, kernel 3.13), che vedo paragonabile a Arch Linux (programma di installazione 2014.08.01, kernel 3.15.7) a causa della presenza di acpi_cpufreq(scaling CPU kernel) e radeon(driver GPU kernel) ). Il motivo per passare a Ubuntu è la facile installazione di fglrx. Ho convalidato il consumo di energia e il comportamento con la nuova installazione, che utilizza radeon.

Ho installato fglrxdalla riga di comando ( sudo apt-get install linux-headers-generic, sudo apt-get install fglrx) e riavviato il sistema. Il passaggio da radeona fglrxè immediatamente evidente sia per quanto riguarda l'aspetto della console ( fglrx: 128 x 48,: radeonmolto più alto) sia per il consumo di energia in modalità inattiva ( fglrx: 40W radeon,: 30W). Ma Turbo Core funziona subito.

Test Case 3.1: BIOS TC on - CnQ on / Linux OnDemand - Boost

Impostazione UEFI BIOS Turbo Core ............................ Abilitato
Impostazione Cool'n'Quiet del BIOS UEFI .......................... Abilitato
/ sys / devices / system / cpu / cpufreq / boost ................... 1
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... ondemand 

"Informazioni sulla frequenza cpupower" ... 4300 4200 3900 3700 3400 2700 2300 1800
Intervallo cpu MHz "/ proc / cpuinfo" osservato ... 1800 - 3700
Intervallo Freq "monitor cpupower" osservato ... 1800 - 4300
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... n / a

Carica | Core Freqs
--------------- + ----------------------------
stress --cpu 1 | 1 x 4300
stress --cpu 2 | 2 x 4200 .. 3900 (core chg)
stress --cpu 3 | 3 x 4100 .. 3700
stress --cpu 4 | 4 x 4000 .. 3600

Il fglrxcomportamento è decisamente interessante. Quando 'stress --cpu 2' veniva chiamato per uno qualsiasi dei casi di tes in qualsiasi gruppo di casi di test, i due core caricati erano sempre posizionati su moduli separati. Ma con fglrx, un'improvvisa riallocazione è avvenuta in modo tale che è stato utilizzato un singolo modulo (che consente di risparmiare un po 'di energia vedi sotto). Dopo qualche tempo, il core caricato è tornato all'altro modulo. Questo non è stato visto con radeon. Potrebbe essere che fglrxmanipola l'affinità di base dei processi?

Riepilogo gruppo casi di test 3

Il vantaggio fglrxè che abilita subito Turbo Core, senza bisogno di patcharlo.

Poiché fglrxnel nostro scenario sprechi da 10 a 12 W per la GPU su un chip con 65 W TDP, i risultati complessivi relativi alle velocità core disponibili non sono impressionanti. Pertanto, non sono stati condotti ulteriori test.

Anche da un punto di vista ingegneristico, il comportamento di fglrxsembra essere un po 'triste. La riallocazione di uno dei due core occupati sull'altro modulo per mantenere una frequenza più elevata può essere o non essere una buona idea, perché prima di quel passaggio, entrambi i core avevano una propria cache L2, mentre in seguito devono condividerne uno. Il fatto che fglrxconsideri eventuali metriche (come i mancati accessi alla cache) a supporto della sua decisione dovrà essere chiarito separatamente, ma ci sono altri rapporti sul suo comportamento improvviso .

Riepilogo del consumo di energia

Alcuni dei valori delta nella tabella seguente peggiorano leggermente all'aumentare della temperatura; si potrebbe dire che la ventola controllata da PWM e il chip svolgono un ruolo lì.

System @State / -> Transition Delta | Dissipazione di potenza del sistema
------------------------------------- + ------------ -------------
  @BIOS | @ 95 .. 86W
  @Bootloader | @ 108 .. 89W
  @Ubuntu Installer Idle | @ 40 W.
  @Linux radeon Idle ondemand | @ 30W
  @Linux radeon Prestazioni inattive | @ 30W
  @Linux fglrx Idle ondemand | @ 40 W.
  1 Modulo 1800 -> 3700 | + 13 W.
  1 Modulo 1800 -> 4300 | + 25 W.
  1 Core 1800 -> 3700 | + 5 W.
  1 Core 1800 -> 4300 | + 10 W.
  Uscita video "radeon" -> Disabilita | - 2 W.
  'fglrx "Uscita video -> Scurisci | + - 0W
  @Linux radeon Maximum | @ 103 .. 89 W.
  @Linux fglrx Maximum | @ 105 .. 92 W.

• Sembra che ci sia molto di più su Turbo Core (almeno con le APU Richland) del previsto: non vi è alcuna differenza evidente nella dissipazione di potenza quando è presente il regolatore di ridimensionamento "ondemand" rispetto a quando è presente il regolatore di "performance". Althouth /proc/cpuinfosegnalerà sempre 37000 MHz sotto il regolatore delle prestazioni, cpupower monitorrivelerà che i core rallentano effettivamente. In alcuni casi, sono state mostrate frequenze basse fino a 2000 MHz; è possibile che vengano utilizzati anche 1800 MHz internamente.
• L'A10-6700 è costituito da due moduli con due core ciascuno. Se ad esempio due core sono inattivi e due core sono occupati e vengono accelerati, il comportamento del sistema sarà diverso a seconda che i core occupati si trovino sullo stesso modulo o meno.
  • L'accelerazione di un modulo richiede più energia rispetto all'accelerazione di un core.
  • La cache L2 è assegnata per modulo.
• La differenza tra la dissipazione di potenza di due core che accelera sullo stesso modulo rispetto a moduli diversi è stata determinata sostituendo stress --cpu 2(che ha sempre portato a una distribuzione tra i due moduli) con .taskset -c 0 stress --cpu 1andtaskset -c 1 stress --cpu 1
• L'A10-6700 sembra avere un limite di dissipazione di potenza totale per l'APU (92 W insieme agli altri componenti) con un piccolo bit riservato solo alla GPU (3 W). Con radeon, consentirà di più per un breve periodo e si ridurrà al massimo in modo molto fluido, mentre con fglrx, è stato osservato che questi limiti vengono superati in modo più significativo e la dissipazione di potenza viene quindi ridotta bruscamente.
• Mentre molte persone affermano che il ritardo nella disponibilità di Kaveri è inteso da AMD perché ucciderebbe le loro attuali APU, io prego di differire. Il Richland A10 ha dimostrato un'eccellente gestione della potenza e il Kaveri non può competere con il suo basso consumo in idle state (la complessità del chip di Kaveri è quasi il doppio di quella di Richland, quindi richiederà altri uno o due passaggi di sviluppo).

Conclusione generale

• Includere la temperatura nella logica Turbo Core (come riportato per il passaggio Trinity -> Richland) sembra avere senso e sembra funzionare bene, come si può vedere dalla riduzione della dissipazione del BIOS nel BIOS e nel Bootloader nel tempo.
• Per lo scenario cosole / server, A10-6700 supporta 4 core a 3700 MHz (3800 MHz con Turbo Core) a lungo termine, almeno con il radeondriver. Probabilmente non ci sono molte possibilità di mantenere questo livello di prestazioni quando la GPU ha del lavoro da fare.
• Sembrerebbe che il TDP da 65 W possa essere permanentemente superato leggermente a pieno carico, ma è difficile dirlo poiché l'alimentatore ha un'efficienza inferiore a 30 W. Dato che ci sono chiare indicazioni che si considera la temperatura (è stata osservata una dissipazione di potenza di picco di quasi 110 W prima che iniziasse a ridursi a 90 W, e anche due core a 4300 MHz sono stati riportati per qualche tempo), investire nel raffreddamento APU potrebbe essere un buona idea. Tuttavia, le schede madri limitate a 65 W TDP saranno in grado di fornire così tanta corrente, quindi ci sarà sicuramente un limite rigido imposto dall'APU.
• Se si intende utilizzare un'APU Richland per l'informatica su Linux, si desidera sicuramente utilizzare un radeondriver con patch (se non si riscontrano instabilità, in particolare in combinazione con l'abilitazione di Dynamic Power Management). Altrimenti, non otterrai il pieno valore.
• Stranamente, sembra che la migliore configurazione sia abilitare sia Turbo Core che Cool'n'Quiet nel BIOS, ma quindi scegliere il performanceregolatore di ridimensionamento, almeno se l'APU si comporta come quella testata qui. Avrai lo stesso consumo di energia ondemandma con un ridimensionamento della frequenza più veloce e meno sovraccarico del kernel per prendere la decisione di ridimensionamento.

Ringraziamenti

Un ringraziamento speciale va ad Alex Deucher, che mi ha spinto significativamente nella giusta direzione su bugzilla.kernel.org .

Sono impressionato dalla qualità del radeondriver gratuito e vorrei ringraziare tutto il team per aver mantenuto questo software, che sembra essere stato progettato con cura. Se radeonnon si fosse comportato così, la mia decisione a favore dell'A10-6700 sarebbe stata sostanzialmente sbagliata.