O fim do experimento de desktop AArch64
(marcin.juszkiewicz.com.pl)- Após cerca de 11 meses de uso real de um desktop AArch64 baseado em Ampere Altra, o experimento foi encerrado, já que o custo contínuo de compatibilidade de kernel, GPU e aplicativos se acumulava ao usar uma plataforma de servidor como se fosse desktop
- O sistema era composto por Ampere Altra Q80-30 de 80 núcleos a 3.0GHz, 128GB de RAM, AMD Radeon RX6700XT, ASRock Rack ALTRAD8UD-1L2T e Fedora 42–44, e desde o início não era um hardware voltado para desktop
- Para usar a GPU AMD, era necessário um patch de contorno para erratum 82288 / PCIE_65, o que exigia recompilar o próprio kernel praticamente toda semana a cada atualização do kernel do Fedora
- Por volta do Linux 7.0, passaram a ocorrer erros na GPU AMD e queda de frames em vídeo; mesmo após a troca para uma Nvidia RTX 2060, FreeCAD e OrcaSlicer travavam por falta de
org.freedesktop.Platform.GL.nvidiano repositório Flatpak para AArch64 - No fim, houve o retorno para um sistema x86-64 com Ryzen 5 3600, deixando o Ampere Altra para builds de pacotes RISC-V e concluindo que um novo desktop AArch64 exigiria outra plataforma de hardware
Configuração usando um Altra de servidor como desktop
- Após cerca de 11 meses de uso real de um desktop AArch64, o experimento foi encerrado
- A configuração final de hardware era a seguinte
- CPU: Ampere Altra Q80-30, 80 núcleos a 3.0GHz
- RAM: 128GB, 8×16GB HMA82GR7CJR8N-XN
- GPU: AMD Radeon RX6700XT
- NVMe: Lexar LM970 2TB, ADATA SX8200 Pro 1TB
- Placa-mãe: ASRock Rack ALTRAD8UD-1L2T
- Fonte: MSI MPG A850G 850W
- Gabinete: Endorfy 700 Air
- USB3: controlador USB 3.2/10Gbps PCIe x4 sem marca
- Esta placa é uma placa-mãe de servidor, e o próprio sistema Altra também não foi projetado para uso em desktop
- A QVL do sistema Ampere Altra não inclui placas de vídeo AMD Radeon, e embora seja possível fazê-las funcionar, isso frequentemente exige trabalho extra
- O controlador USB 3.2 separado fornece mais dispositivos USB e portas de 10Gbps para NVMe externo do que o suporte padrão da placa-mãe
- O sistema inteiro funcionava com Fedora 42–44, mas para uso real era necessário um kernel compilado manualmente, e não o kernel padrão do Fedora
A carga de manutenção do kernel causada pelo PCIE_65
- O controlador PCI Express do Ampere Altra tem o problema erratum 82288 / PCIE_65
- O PCIE_65 pode gerar endereços incorretos em escritas MMIO PCIe, afetando especialmente certos tipos de dispositivos, como GPUs AMD
- O problema pode surgir quando o driver do kernel Linux mapeia espaço MMIO com atributos de memória Normal, non-cacheable, como em
ioremap_wc- Isso pode ter como objetivo permitir write combining ou acessos desalinhados
- Nesse caso, pode ocorrer corrupção de dados em escritas MMIO de saída na interface PCIe
- A solução alternativa é mapear com memória Device, non-gathering, como em
ioremap, e alinhar estritamente todas as operações de memória no espaço MMIO PCIe
- Para usar o sistema como um Linux funcional, era necessário recompilar o kernel a cada atualização do pacote do kernel do Fedora, normalmente toda semana
- Depois de atualizar o repositório local de pacotes de kernel do Fedora, a compilação seguia uma convenção de versão própria como
7.0.2-200.fc44.pcie65.6pcie65indicava o patch aplicado- O último número era a contagem de rebase do patch
- Os patches eram obtidos de um repositório no GitHub, passavam por rebase e eram ajustados quando necessário; por isso, às vezes o kernel usado era mais novo que o oficial do Fedora
80 núcleos não garantem boa performance percebida em desktop
- Mesmo com 80 núcleos de CPU, isso não se traduziu em uma boa máquina de desktop
- A grande contagem de núcleos não garantiu a resposta rápida percebida que se espera em um desktop
Problemas de compatibilidade de apps que continuaram mesmo após trocar a GPU
- A AMD Radeon RX6700XT funcionava em um kernel com patch PCIE_65 fora da árvore principal, e era possível rodar jogos e usar decodificação de vídeo acelerada por hardware
- Em algum momento por volta do lançamento do Linux 7.0, a GPU AMD começou a falhar
- Ao rodar jogos, o log repetia
amdgpu 0000:03:00.0: Fence fallback timer expired on ring vcn_dec_0 - Ao assistir vídeos no YouTube, 720 de 750 frames eram descartados, tornando o uso praticamente inviável
- Ao rodar jogos, o log repetia
- Em uma situação comum, o próximo passo seria fazer bisect do kernel para encontrar o ponto do problema, mas com o patch PCIE_65 o kernel ficava tainted, dificultando identificar a causa real
- No lugar da AMD Radeon, foi instalada uma Nvidia RTX 2060
- Para usar o driver de kernel
nouveau, o patch PCIE_65 ainda era necessário - A combinação do kernel padrão do Fedora com o driver binário da Nvidia funcionava normalmente
- Aceleração de decodificação de vídeo e alguns jogos baseados em Wine também funcionavam
- Para usar o driver de kernel
- FreeCAD e OrcaSlicer travavam logo após iniciar
- A causa era a ausência de
org.freedesktop.Platform.GL.nvidiano repositório Flatpak para AArch64 - Como essas duas ferramentas eram usadas com frequência, isso se tornou um problema central que dificultou manter o desktop
- A causa era a ausência de
Retorno ao x86-64 e o novo papel do Altra
- No fim, o sistema x86-64 que estava desligado foi ligado novamente
- Depois de mover muitos cabos e organizar cabos novos, os dois sistemas passaram a ser usados juntos sob a mesa
wooster: sistema Ampere Altrapuchatek: sistema Ryzen 5 3600
- A mudança de 80 núcleos para 6 núcleos e 12 threads pareceu estranha, mas o trabalho real voltou a fluir normalmente
- A música continua tocando mesmo com todas as threads em uso
- Todos os jogos da biblioteca da Steam podem ser jogados
- Foi possível terminar o projeto de gabinete de um projeto pessoal no FreeCAD
- É possível criar imediatamente protótipos para impressão 3D no OrcaSlicer
- O sistema Ampere Altra continua ligado e cuida de builds de pacotes RISC-V
- Esse sistema tem desempenho fraco em thread única, mas é rápido sob carga multicore
O mesmo tipo de desktop AArch64 não será repetido
- Não há planos de repetir o mesmo experimento de desktop com o Ampere Altra
- Para tentar outro desktop AArch64, será necessária uma plataforma de hardware totalmente nova
- Não há planos de gastar mais de 20.000 PLN para comprar um sistema Nvidia DGX Spark
1 comentários
Comentários no Lobste.rs
Tenho certa empatia por essa situação. No meu Raptor Talos II, a IBM continua quebrando o PowerNV
Primeiro foi o amdgpu, agora o problema é a placa SATA. Estou preso no kernel 6.14 porque a IBM continua mexendo no PCIe para sistemas que não são bare metal
Eu queria ter um desde o lançamento, mas agora ele já está bem antigo, e penso que talvez possa sair uma versão Power 11
Passei por algo parecido. Tentei rodar NixOS em um Thinkpad X13S e, até certo ponto, funcionou, mas desde a instalação tive que usar uma ISO do Ubuntu
porque não consegui encontrar uma imagem NixOS aarch64 UEFI que inicializasse corretamente. Depois de uma atualização recente do kernel, o boot quebrou, e agora minha energia para simplesmente fazer o sistema funcionar acabou
O Ubuntu também tem algum suporte ao X13S, mas muitas coisas que seriam dadas como certas em uma máquina x86_64 tradicional não funcionam. Suspensão simplesmente não funciona, o suporte a TPM é limitado, os gráficos se comportam de forma peculiar, e provavelmente há mais problemas que não consegui testar
E isso sem contar dispositivos ARM que só oferecem imagens antigas, como os portáteis de emulação de empresas como a Anbernic, ou dispositivos como o Clockwork uConsole, que usam — ou abusam — do hardware de forma engenhosa e precisam de patches de kernel não padronizados. No fim, esse software não chega ao upstream, e o hardware fica preso a um sistema operacional que não pode ser atualizado
Passei bastante tempo em vários computadores esperando que ARM funcionasse bem no Linux, mas estou travado. Fora o Raspberry Pi, nada simplesmente funciona, e eu não conheço o suficiente sobre hardware/kernel para produzir melhorias significativas
Do mesmo modo, passei horas tentando instalar o NixOS, instalei a partir do Ubuntu e consegui fazê-lo funcionar mais ou menos, mas era frágil demais para ser realmente utilizável
Eu queria muito que desse certo, mas no lado Linux parecia abandonado; acabei desistindo e passei a rodar NixOS em uma máquina virtual em um Apple MacBook Air
Como também não tenho grande apreço pelo Ubuntu, não me dei ao trabalho de tentar outras distribuições, e o Windows ao menos funciona suficientemente bem
Os SoCs mais recentes têm muito menos peculiaridades. Por exemplo, não é preciso passar uma linha de comando do kernel do tamanho de um parágrafo. Mas não existe uma versão X Elite 2 do X13s
Fico curioso se os novos notebooks Nvidia RTX Spark vão receber suporte oficial a Linux
No fim, é praticamente a mesma plataforma do DGX Spark, que roda uma distribuição derivada do Ubuntu, mas os sinais até agora não parecem muito bons
Para relatar uma experiência oposta, estou usando uma Radxa Rock5bPlus há cerca de 4 meses. Ela tem 16 GB de memória e NVMe, e uso u-boot mainline, a versão EFI do Fedora Rawhide e kernel mainline
O trabalho que a Collabora fez para levar o suporte ao rk3588 ao mainline é francamente impressionante
Ainda há coisas pelas quais estou esperando: HDMI 2.0 ou superior, isto é, 4k@60, e coisas como USB-C DP. Mesmo assim, do ponto de vista de hardware, parece ter menos peculiaridades do que meu XPS 13 9370. Nesse notebook, a saída de áudio simplesmente parou de funcionar por volta do 5.14
https://dell.com/community/en/…
https://gitlab.collabora.com/hardware-enablement/rockchip-3588/…
Ainda não há suporte a HDCP, mas parece hora de voltar aos experimentos que fiz com OSD HDMI 1080p de baixa latência
Funcionava com atraso de 3 quadros, e o mínimo teórico era 2 quadros. Sobrepondo Chromium Embedded ao sinal HDMI, dava para ampliar bastante os recursos de OSD em uma configuração de mídia doméstica
O maior problema era a instabilidade, e a configuração inteira fazia o kernel da OrangePi travar regularmente
Isto parece mostrar melhor o estado atual do suporte de hardware no Linux. Só hardware popular e lucrativo recebe suporte no kernel, e a situação dos drivers binários sempre foi, e continua sendo, um inferno
É interessante ver pessoas correndo atrás do Linux para fazer algo funcionar no próprio hardware e, no fim, ficando presas a kernels antigos ou tendo que manter e fazer rebase de patches por conta própria. Tudo isso em vez de usar um sistema operacional que dá suporte a hardware antigo sem precisar desse trabalho
“Segundo a errata da família Altra, o PCIE_65 pode gerar endereços incorretos em escritas PCIe MMIO e afeta certos tipos de dispositivo, especialmente GPUs AMD; portanto, a família Altra, em geral, não é compatível com esses tipos de dispositivo. Para permitir experimentação e trabalho de desenvolvimento, foi fornecido um patch de software de prova de conceito sob GPL v2”
Dá para entender por que um sistema operacional não gostaria de aceitar um simples patch de prova de conceito
Há muitos forks do kernel Linux que dão suporte a pedaços específicos de hardware, e isso é lamentável. Esses forks frequentemente contêm commits invasivos ou experimentais que precisariam de mais trabalho para serem aceitos no kernel Linux mainline
Fico curioso se outros sistemas operacionais estão seguindo outro caminho aqui. O que eles fazem para facilitar contribuições upstream e, ao mesmo tempo, manter viável a manutenção de arquiteturas, SoCs e placas?
Então poupei o trabalho que eu estava pensando em tentar. Ainda assim, espero que identificar os pontos de dor ajude no longo prazo
Achei que só eu estivesse sofrendo. Usei uma configuração parecida como servidor de desenvolvimento, e a maioria dos problemas veio de dependências Python com código nativo
Também me lembro de alguns pacotes de otimização e do Matplotlib. Tentei tanto pip normal quanto uv, mas no fim tive que compilar a partir do código-fonte. Acabei voltando totalmente para x86 e, sinceramente, mesmo com tantos núcleos, o desempenho não era lá tão impressionante
Se você quer um desktop Linux que realmente funcione para jogos, precisa de uma placa Nvidia e do driver binário, e deve evitar coisas como Flatpak que não se encaixam bem nisso
Isso tem sido assim há décadas, em qualquer arquitetura, e eu diria que é praticamente senso comum
No caso do Steam, no Flatpak não há acesso ao Steam Controller, mas fora isso funciona sem problemas
Para fazer uma afirmação dessas, você precisa trazer algum dado que a sustente, não apenas “confie em mim”
Se fosse uma configuração tão sensível a patches de kernel, eu provavelmente nem usaria o pacote de kernel da distribuição
Compilaria e inicializaria meu próprio kernel fora do sistema de pacotes, atualizando no meu próprio ritmo
Eu estava acompanhando um pouco o desenrolar desse texto, e o que me surpreendeu foi ele ter funcionado por tanto tempo
Sempre pareceu algo mais próximo de “dar um jeito de fazer funcionar”, e ainda assim é triste ler esse desfecho