Meu objetivo é configurar um mini servidor (não HTPC) com baixo consumo de energia no modo ocioso, mas oferecendo bom desempenho quando usado. O foco é mais na segurança dos dados do que na disponibilidade. Em outras palavras: peças de qualidade, mas redundância apenas para armazenamento.

Não me considerando tendencioso, depois de algumas pesquisas, senti que algumas APUs para desktop da AMD ofereceriam um bom valor.

As questões restantes são:

• O estado ocioso da GPU reduzirá o consumo de energia e liberará recursos para a CPU?
• Cool'n'Quiet e Turbo Core levarão ao baixo consumo de energia pretendido no modo inativo, mas desempenho sob carga?
• O Linux suportará esse cenário como pretendido? Muitas perguntas e discussões no fórum parecem sugerir que esse não é necessariamente o caso.

[Editar: Pensamentos finais sobre a escolha do processador]

• AMD vs AMD:
  • Richland faz um trabalho muito melhor do que Trinity aqui.
  • Kaveri não pode competir com a dissipação de energia no modo ocioso de Richland (pelo menos por enquanto).
  • A GPU do A10-6700 pode estar superestimada, mas é um pouco triste que não será usada muito. Alguns algoritmos podem ser capazes de implantar seu poder computacional. Porém, não faço ideia de como isso afetará o consumo de energia do processador.
  • Eu suspeito que o A10-6790K seja o mesmo processador que o A10-6700 com apenas um parâmetro diferente definido para os reforços do Turbo Core. Se isso for verdade, o A10-6790K poderá aumentar por mais tempo e / ou fornecer frequências mais altas a longo prazo devido ao seu TDP mais alto. Mas você precisará de um ventilador de CPU diferente para isso (pense em espaço e temperatura / vida útil).
• AMD A10-6700 vs Intel Core i3-3220:
  • O A10-6700 possui muito mais energia da GPU, que não é usada aqui.
  • O i3-3220 possui uma menor dissipação de energia no modo inativo.
  • Embora em benchmarks típicos o i3-3220 seja mais rápido para cálculos, não consigo ver como seus dois núcleos de hyperthreading seriam capazes de lidar com solicitações paralelas (por exemplo, para um banco de dados com front-end da web) tão rápido quanto quatro núcleos com todos os recursos (pelo menos ao assumir algum cache sério). Não encontrou nenhum parâmetro de referência sério - Apenas algumas indicações.

[Edit: O bapmparâmetro do driver radeon gratuito é definido por padrão para os sistemas Kaveri, Kabini e Trinity, desktop Richland a partir do Linux 3.16]

Veja [pull] radeon drm-fixes-3.16 .

No entanto, no Debian baseado na 3.16, os padrões (ainda?) Não parecem funcionar, enquanto o parâmetro de inicialização funciona. Consulte Como configurar um sistema Debian (foco em 2D ou console / servidor) com uma APU AMD Turbo Core para obter o máximo de eficiência energética e de computação?

[Edit: O driver radeon gratuito em breve terá um bapmparâmetro]

Como a linha inferior abaixo é usar uma versão corrigida do radeondriver gratuito com sua APU para suportar o Turbo Core e tirar o máximo proveito (exceto gráficos 3D), se puder (a ativação bapmpode levar a instabilidades em algumas configurações) ), é uma ótima notícia que as versões futuras do radeon terão um parâmetro para ativar o bapm .

[A postagem original segue]

Experiência da APU AMD A10-6700 (Richland)

Escolha do processador

Meu primeiro PC foi um 486DX2-66 configurado a partir de dezenas de disquetes de 3,5 "contendo pacotes de fontes Slackware. Então, muitas coisas mudaram e muitas indústrias atualmente parecem estar na fase em que ainda aumentam o número de variantes do produto.

Essa circunstância e algumas das infelizes decisões da AMD no passado recente não facilitaram a decisão de uma plataforma para um mini servidor. Mas, finalmente, decidi que o A10-6700 seria uma boa escolha:

• Várias revisões mostraram que um Kaveri (ainda indisponível) consumirá mais energia no modo ocioso do que um Richland ou um Trinity
• A vantagem do Richland A10-6700 sobre o Trinity A10-5700 parece ser significativa: menor e maior frequência mais alta, Turbo Core mais refinado (considerando também a temperatura - uma grande vantagem quando a GPU fica ociosa)
• Diz-se que a GPU do A10-6700 está superestimada (nomeação orientada ao marketing) e os preços da APU parecem justos

Outros componentes e instalação

Apesar dos inúmeros processadores para escolher, não há muitas placas Mini-ITX disponíveis. O ASRock FM2A78M-ITX + parecia ser uma escolha razoável. O teste foi realizado com o firmware V1.30 (nenhuma atualização disponível enquanto escrevo isso).

Apenas 80% da produção nominal de uma fonte de alimentação deve ser consumida. Por outro lado, muitos não conseguem trabalhar com eficiência abaixo de 50% da carga. É muito difícil encontrar uma fonte de alimentação com eficiência energética para um sistema com um intervalo estimado de dissipação de energia de 35W a 120W. Realizei esses testes com um Seasonic G360 80+ Gold, porque supera a maioria dos concorrentes em relação à eficiência em cargas baixas.

Duas RAMs DDR3-1866 de 8 GB (configuradas como tal - o que faz a diferença em comparação com 1333), uma unidade SSD e um ventilador da CPU com qualidade de controle PWM também fizeram parte da configuração do teste.

As medições foram feitas usando um AVM Fritz! DECT 200, que foi relatado para realizar medições precisas. Ainda assim, a plausibilidade foi validada usando um dispositivo sem nome mais antigo. Nenhuma inconsistência pode ser identificada. A dissipação de energia medida do sistema incluirá a eficiência reduzida da fonte de alimentação para cargas mais baixas.

Uma tela [W] QHD foi conectada via HDMI.

A memória compartilhada inicial da GPU foi configurada para 32M no UEFI BIOS. Além disso, a GPU integrada foi selecionada como Primária e o IOMMU foi ativado.

Nenhum X ou outro sistema gráfico foi instalado ou configurado. A saída de vídeo foi restrita ao modo do console.

Fundamentos

Há algumas coisas que precisamos saber.

• Embora a decisão sobre o Cool'n'Quiet seja tomada por software fora dos processadores, o Turbo Core é uma decisão tomada de forma autônoma por um microcontrolador adicional na APU (ou CPU).
• Muitas ferramentas, bem como /proce /syslugares não relatam atividade Turbo Core. cpufreq-aperf, cpupower frequency-infoE cpupower monitorfazer, mas só depois modprobe msr.

Grupo de Casos de Teste 1: Linux + radeon

Comecei com o novo Arch Linux (instalador 2014.08.01, kernel 3.15.7). O fator principal aqui é a presença de acpi_cpufreq(dimensionamento da CPU do kernel) e radeon(driver da GPU do kernel) e a maneira mais fácil de corrigir radeon.

Caso de Teste 1.1: BIOS TC ativado - CnQ no / Linux OnDemand - Boost

Configuração UEFI BIOS Turbo Core ............................ Ativado
Configuração UEFI BIOS Cool'n'Quiet .......................... Ativado
/ sys / devices / system / cpu / cpufreq / boost ................... 1
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... ondemand 

"cpupower frequency-info" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Intervalo de cpu "/ proc / cpuinfo" de MHz observado ... 1800 - 3700
Faixa de freqüência observada "monitor de potência" ... 1800 - 3700
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... nível de potência 0

Carregar | Freqs principais
--------------- + -----------
estresse - CPU 1 | 1 x 3700
estresse - CPU 2 | 2 x 3700
estresse - CPU 3 | 3 x 3700
estresse - CPU 4 | 4 x 3700

Caso de teste 1.2: BIOS TC ativado - Desempenho do CnQ on / Linux - Boost

Configuração UEFI BIOS Turbo Core ............................ Ativado
Configuração UEFI BIOS Cool'n'Quiet .......................... Ativado
/ sys / devices / system / cpu / cpufreq / boost ................... 1
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... desempenho 

"cpupower frequency-info" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Intervalo de cpu MHz observado "/ proc / cpuinfo" ... 3700
Observado "monitor cpupower" Freq range ... 2000 - 3700
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... nível de potência 0

Carregar | Freqs principais
--------------- + -----------
estresse - CPU 1 | 1 x 3700
estresse - CPU 2 | 2 x 3700
estresse - CPU 3 | 3 x 3700
estresse - CPU 4 | 4 x 3700

Resumo do Grupo de Casos de Teste 1

Os impulsionamentos baseados no Turbo Core são impossíveis nesse cenário porque o radeondriver atualmente desativa o bapmsinalizador devido a problemas de estabilidade em alguns cenários . Portanto, mais testes foram ignorados.

Grupo de Caso de Teste 2: Linux + radeon com patch bapm

A fim de permitir bapm, eu comecei com uma Arch Linux fresco (instalador 2014/08/01, do kernel 3.15.7), me pegou o core linuxpacote via ABS(3.15.8), editou o PKGBUILDpara uso pkgbase=linux-tc, puxou as fontes com makepkg --nobuild, alteradas pi->enable_bapm = true;em trinity_dpm_init()em src/linux-3.15/drivers/gpu/drm/radeon/trinity_dpm.ce compilou com makepkg --noextract. Em seguida, instalei ( 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 atualizei GRUB( grub-mkconfig -o /boot/grub/grub.cfgmas, é claro, YMMV).

Como resultado, tive a opção de inicializar linuxou linux-tc, e os testes a seguir se referem ao último.

Caso de teste 2.1: BIOS TC ativado - CnQ on / Linux OnDemand - Boost

Configuração UEFI BIOS Turbo Core ............................ Ativado
Configuração UEFI BIOS Cool'n'Quiet .......................... Ativado
/ sys / devices / system / cpu / cpufreq / boost ................... 1
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... ondemand 

"cpupower frequency-info" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Intervalo de cpu "/ proc / cpuinfo" de MHz observado ... 1800 - 3700
Observado "monitor cpupower" Freq range ... 1800 - 4300
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... nível de potência 0

Carregar | Freqs principais
--------------- + -----------------
estresse - CPU 1 | 1 x 4300
estresse - CPU 2 | 2 x 4200 .. 4100
estresse - CPU 3 | 3 x 4100 .. 3900
estresse - CPU 4 | 4 x 4000 .. 3800

Caso de teste 2.2: BIOS TC ativado - CnQ on / Linux Performance - Boost

Configuração UEFI BIOS Turbo Core ............................ Ativado
Configuração UEFI BIOS Cool'n'Quiet .......................... Ativado
/ sys / devices / system / cpu / cpufreq / boost ................... 1
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... desempenho

"cpupower frequency-info" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Intervalo de cpu MHz observado "/ proc / cpuinfo" ... 3700
Observado "cpupower monitor" Freq range ... 2000 - 4300
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... nível de potência 0

Carregar | Freqs principais
--------------- + -----------------
estresse - CPU 1 | 1 x 4300
estresse - CPU 2 | 2 x 4200 .. 4100
estresse - CPU 3 | 3 x 4100 .. 3900
estresse - CPU 4 | 4 x 4000 .. 3800

Caso de teste 2.3: BIOS TC ativado - CnQ on / Linux OnDemand - sem reforço

Configuração UEFI BIOS Turbo Core ............................ Ativado
Configuração UEFI BIOS Cool'n'Quiet .......................... Ativado
/ sys / devices / system / cpu / cpufreq / boost ....................... 0
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... ondemand

"cpupower frequency-info" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Intervalo de cpu "/ proc / cpuinfo" de MHz observado ... 1800 - 3700
Faixa de freqüência observada "monitor de potência" ... 1800 - 3700
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... nível de potência 1

Carregar | Freqs principais
--------------- + -----------
estresse - CPU 1 | 1 x 3700
estresse - CPU 2 | 2 x 3700
estresse - CPU 3 | 3 x 3700
estresse - CPU 4 | 4 x 3700

Caso de teste 2.4: BIOS TC ativado - Desempenho do CnQ on / Linux - sem reforço

Configuração UEFI BIOS Turbo Core ............................ Ativado
Configuração UEFI BIOS Cool'n'Quiet .......................... Ativado
/ sys / devices / system / cpu / cpufreq / boost ....................... 0
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... desempenho

"cpupower frequency-info" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Intervalo de cpu MHz observado "/ proc / cpuinfo" ... 3700
Observado "monitor cpupower" Freq range ... 2000 - 3700
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... nível de potência 1

Carregar | Freqs principais
--------------- + -----------
estresse - CPU 1 | 1 x 3700
estresse - CPU 2 | 2 x 3700
estresse - CPU 3 | 3 x 3700
estresse - CPU 4 | 4 x 3700

Caso de teste 2.5: BIOS TC desativado - CnQ on / Linux OnDemand - Boost

Configuração UEFI BIOS Turbo Core ............................ Desativado
Configuração UEFI BIOS Cool'n'Quiet .......................... Ativado
/ sys / devices / system / cpu / cpufreq / boost ................... 1
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... ondemand 

"cpupower frequency-info" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Intervalo de cpu "/ proc / cpuinfo" de MHz observado ... 1800 - 3700
Faixa de freqüência observada "monitor de potência" ... 1800 - 3700
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... nível de potência 0

Em outras palavras, se o Turbo Core estiver desativado no BIOS, o patch radeonnão o ativará .

Caso de teste 2.6: BIOS TC ativado - CnQ desativado / Linux n / a

Configuração UEFI BIOS Turbo Core ............................ Ativado
Configuração UEFI BIOS Cool'n'Quiet .......................... Desativado
/ sys / devices / system / cpu / cpufreq / boost ................... n / a
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... n / a

"cpupower frequency-info" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Intervalo de cpu MHz observado "/ proc / cpuinfo" ... 3700
Observado "cpupower monitor" Freq range ... 2000 - 4300
/ sys / kernel / debug / dri / 0 / radeon_pm_info ... nível de potência 0

Carregar | Freqs principais
--------------- + -----------------
estresse - CPU 1 | 1 x 4300
estresse - CPU 2 | 2 x 4100 .. 4000
estresse - CPU 3 | 3 x 4000 .. 3800
estresse - CPU 4 | 4 x 3900 .. 3700

Com o Cool'n'Qiet desativado, o kernel do Linux não oferece nenhuma opção de governador e (incorretamente) assume que os núcleos são executados em uma frequência fixa. Curiosamente, as frequências Turbo Core resultantes são as piores de todas as combinações testadas no Grupo de Casos de Teste 2.

Resumo do Grupo de Casos de Teste 2

Com o radeondriver corrigido , o Turbo Core funciona. Nenhuma instabilidade (que é a razão pela qual o bapmTurbo Core está desativado lá) foi vista até agora.

Grupo de Caso de Teste 3: Linux + fglrx (catalisador)

Comecei com uma nova instalação do Ubuntu (14.04 Server, kernel 3.13), que considero comparável ao Arch Linux (instalador 2014.08.01, kernel 3.15.7) devido à presença de acpi_cpufreq(dimensionamento da CPU do kernel) e radeon(driver GPU do kernel) ) A razão para mudar para o Ubuntu é a fácil instalação do fglrx. Eu validei o consumo de energia e o comportamento com a nova instalação, que usa radeon.

Eu instalei a fglrxpartir da linha de comando ( sudo apt-get install linux-headers-generic, sudo apt-get install fglrx) e reiniciei o sistema. A mudança de radeonpara fglrxé imediatamente óbvia, tanto na aparência do console ( fglrx: 128 x 48,: radeonmuito maior) quanto no consumo de energia do modo ocioso ( fglrx: 40W,: radeon30W). Mas o Turbo Core funciona imediatamente.

Caso de teste 3.1: BIOS TC ativado - CnQ on / Linux OnDemand - Boost

Configuração UEFI BIOS Turbo Core ............................ Ativado
Configuração UEFI BIOS Cool'n'Quiet .......................... Ativado
/ sys / devices / system / cpu / cpufreq / boost ................... 1
/ sys / devices / system / cpu / cpu * / cpufreq / scaling_governor ... ondemand 

"cpupower frequency-info" Pstates ........ 4300 4200 3900 3700 3400 2700 2300 1800
Intervalo de cpu "/ proc / cpuinfo" de MHz observado ... 1800 - 3700
Observado "monitor cpupower" Freq range ... 1800 - 4300
/ sys / kernel / depuração / dri / 0 / radeon_pm_info ... n / a

Carregar | Freqs principais
--------------- + ----------------------------
estresse - CPU 1 | 1 x 4300
estresse - CPU 2 | 2 x 4200 .. 3900 (var. Do núcleo)
estresse - CPU 3 | 3 x 4100 .. 3700
estresse - CPU 4 | 4 x 4000 .. 3600

O fglrxcomportamento é definitivamente interessante. Quando 'stress --cpu 2' era chamado para qualquer um dos casos de tes em qualquer grupo de casos de teste, os dois núcleos carregados estavam sempre localizados em módulos separados. Porém fglrx, com uma realocação repentina ocorreu de forma que um único módulo foi usado (o que economiza bastante energia, veja abaixo). Após algum tempo, o núcleo carregado voltou para o outro módulo. Isso não foi visto com radeon. Será que fglrxmanipula a afinidade central dos processos?

Resumo do Grupo de Casos de Teste 3

A vantagem fglrxé que ele permite o Turbo Core imediatamente, sem a necessidade de corrigi-lo.

Como fglrxdesperdiça 10 a 12W para a GPU em nosso cenário em um chip com 65W TDP, os resultados gerais em relação às velocidades de núcleo disponíveis são inexpressivos. Portanto, nenhum outro teste foi realizado.

Também do ponto de vista da engenharia, o comportamento de fglrxparece um pouco triste. A realocação de um dos dois núcleos ocupados para o outro módulo para manter uma frequência mais alta pode ou não ser uma boa ideia, porque antes dessa etapa, os dois núcleos tinham um cache L2 próprio e, posteriormente, eles tinham que compartilhar um. A fglrxconsideração de qualquer métrica (como erros de acerto no cache) para apoiar sua decisão terá que ser esclarecida separadamente, mas há outros relatórios sobre seu comportamento abrupto .

Resumo do consumo de energia

Alguns dos valores delta na tabela a seguir pioram um pouco à medida que a temperatura aumenta; pode-se dizer que o ventilador controlado por PWM e o chip desempenham um papel nesse processo.

Sistema @ Estado / -> Delta de Transição | Dissipação de energia do sistema
------------------------------------- + ------------ -------------
  @BIOS @ 95 .. 86W
  @Bootloader | @ 108 .. 89W
  Instalador do Ubuntu ocioso | @ 40W
  @Linux radeon Idle ondemand | @ 30W
  @Linux radeon Desempenho ocioso | @ 30W
  @Linux fglrx Idle ondemand | @ 40W
  1 Módulo 1800 -> 3700 | + 13W
  1 Módulo 1800 -> 4300 | + 25W
  1 núcleo 1800 -> 3700 | + 5W
  1 núcleo 1800 -> 4300 | + 10W
  Saída de Vídeo "radeon" -> Desativar | - 2W
  'fglrx "Saída de Vídeo -> Escurecer | + - 0W
  @Linux radeon Maximum | @ 103 .. 89W
  @Linux fglrx Maximum | @ 105 .. 92W

• Parece haver mais no Turbo Core (pelo menos com as APUs Richland) do que o esperado: Não há diferença perceptível na dissipação de energia quando o regulador de escala "ondemand" está em vigor quando comparado ao regulador "desempenho". Althouth /proc/cpuinfosempre reportará 37000MHz sob o regulador de desempenho, cpupower monitorrevelará que os núcleos realmente diminuem a velocidade. Em alguns casos, foram mostradas frequências tão baixas quanto 2000MHz; é possível que 1800 MHz também sejam utilizados internamente.
• O A10-6700 consiste em dois módulos com dois núcleos cada. Se, por exemplo, dois núcleos estão ociosos e dois estão ocupados e são acelerados, o comportamento do sistema será diferente dependendo se os núcleos ocupados estão localizados no mesmo módulo ou não.
  • Acelerar um módulo consome mais energia do que acelerar um núcleo.
  • O cache L2 é atribuído por módulo.
• A diferença entre a dissipação de energia de dois núcleos acelerando no mesmo módulo vs em módulos diferentes foi determinada substituindo stress --cpu 2(o que sempre levava a uma distribuição entre os dois módulos) por .taskset -c 0 stress --cpu 1andtaskset -c 1 stress --cpu 1
• O A10-6700 parece ter um limite total de dissipação de energia para a APU (92W junto com os outros componentes), com um pouquinho reservado apenas para a GPU (3 W). Com radeon, permitirá mais por um curto período e reduzirá ao máximo muito suavemente, enquanto com fglrx, foi observado que esses limites são excedidos mais significativamente e a dissipação de energia é reduzida abruptamente.
• Enquanto muitas pessoas afirmam que o atraso na disponibilidade do Kaveri é pretendido pela AMD porque mataria suas APUs atuais, eu imploro para diferir. O Richland A10 demonstrou um excelente gerenciamento de energia e o Kaveri não pode competir com seu baixo consumo de energia em estado inativo (a complexidade do chip da Kaveri é quase o dobro da da Richland, portanto, será necessário mais uma ou duas etapas de desenvolvimento).

Conclusão geral

• A inclusão de temperatura na lógica do Turbo Core (como é relatado na etapa Trinity -> Richland) parece fazer sentido e parece funcionar bem, como pode ser visto pela redução na dissipação do pwoer no BIOS e no Bootloader ao longo do tempo.
• Para o cenário cosole / servidor, o A10-6700 suporta 4 núcleos a 3700 MHz (3800 MHz com Turbo Core) a longo prazo, pelo menos com o radeondriver. Provavelmente, não há muita chance de manter esse nível de desempenho quando a GPU faz algum trabalho.
• Parece que o TDP de 65W pode ser permanentemente excedido levemente sob carga total, mas é difícil dizer porque a fonte de alimentação tem uma eficiência mais baixa a 30W. Como existem indicações claras de que a temperatura é considerada (um pico de dissipação de energia de quase 110W foi observado antes de começar a ser reduzido para 90W e também 2 núcleos a 4300 MHz foram relatados por algum tempo), investir no resfriamento da APU pode ser um boa ideia. No entanto, as placas-mãe limitadas a 65W TDP só poderão fornecer tanta corrente, portanto, definitivamente haverá um limite rígido imposto pela APU.
• Se você pretende usar uma APU Richland para computação no Linux, definitivamente deseja usar um radeondriver corrigido (se não encontrar instabilidades - especificamente em conjunto com a ativação do Gerenciamento Dinâmico de Energia). Caso contrário, você não obterá o valor total.
• Curiosamente, parece que a melhor configuração seria habilitar o Turbo Core e o Cool'n'Quiet no BIOS, mas depois escolher o performanceregulador de escala - pelo menos se a sua APU se comportar como a testada aqui. Você terá o mesmo consumo de energia, ondemandmas com escala de frequência mais rápida e menos sobrecarga do kernel para tomar a decisão de escala.

Reconhecimentos

Um agradecimento especial a Alex Deucher, que me empurrou significativamente na direção certa em bugzilla.kernel.org .

Estou impressionado com a qualidade do radeondriver gratuito e gostaria de agradecer a toda a equipe por manter esse software, que parece ter sido cuidadosamente projetado. Se radeonnão se comportasse como ele, minha decisão a favor da A10-6700 teria sido substancialmente errada.