La fin de l’expérience du desktop AArch64

 (marcin.juszkiewicz.com.pl)
1 points par GN⁺ 3 시간 전 | 1 commentaires | Partager sur WhatsApp
  • Après environ 11 mois d’usage quotidien d’un desktop AArch64 basé sur Ampere Altra, la charge liée à la compatibilité du noyau, du GPU et des applications n’a cessé de s’accumuler en utilisant une plateforme serveur comme un desktop
  • Le système était composé d’un Ampere Altra Q80-30 80 cœurs à 3,0 GHz, de 128 Go de RAM, d’une AMD Radeon RX6700XT, d’une ASRock Rack ALTRAD8UD-1L2T et de Fedora 42–44, et il ne s’agissait pas dès le départ d’un matériel conçu pour un usage desktop
  • L’usage du GPU AMD nécessitait un patch de contournement erratum 82288 / PCIE_65, ce qui imposait de recompiler son propre noyau pratiquement chaque semaine à chaque mise à jour du noyau Fedora
  • Autour de Linux 7.0, des erreurs GPU AMD et des pertes d’images vidéo sont apparues, et même après le passage à une Nvidia RTX 2060, FreeCAD et OrcaSlicer plantaient à cause de l’absence de org.freedesktop.Platform.GL.nvidia dans le dépôt Flatpak AArch64
  • Au final, retour à un système x86-64 Ryzen 5 3600, tandis que l’Ampere Altra reste affecté à la compilation de paquets RISC-V ; pour un nouveau desktop AArch64, il faudrait une autre plateforme matérielle

Configuration d’un Altra serveur utilisé comme desktop

  • Après environ 11 mois d’usage quotidien d’un desktop AArch64, l’expérience a pris fin
  • La configuration matérielle finale était la suivante
    • CPU : Ampere Altra Q80-30, 80 cœurs à 3,0 GHz
    • RAM : 128 Go, 8×16 Go HMA82GR7CJR8N-XN
    • GPU : AMD Radeon RX6700XT
    • NVMe : Lexar LM970 2 To, ADATA SX8200 Pro 1 To
    • Carte mère : ASRock Rack ALTRAD8UD-1L2T
    • Alimentation : MSI MPG A850G 850W
    • Boîtier : Endorfy 700 Air
    • USB3 : contrôleur PCIe x4 USB 3.2/10Gbps sans marque
  • Cette carte est une carte mère serveur, et le système Altra lui-même n’est pas conçu pour un usage desktop
  • La QVL des systèmes Ampere Altra ne comprend pas les cartes GPU AMD Radeon ; il est possible de les faire fonctionner, mais cela demande souvent un travail supplémentaire
  • Le contrôleur USB 3.2 séparé fournit davantage de périphériques USB et des ports 10 Gbit/s pour du NVMe externe que la prise en charge native de la carte mère
  • L’ensemble du système fonctionnait sous Fedora 42–44, mais en pratique il fallait un noyau compilé maison plutôt que le noyau Fedora standard

La charge de maintenance du noyau imposée par PCIE_65

  • Le contrôleur PCI Express de l’Ampere Altra présente le problème erratum 82288 / PCIE_65
  • PCIE_65 peut générer une adresse incorrecte lors d’écritures MMIO PCIe, ce qui affecte en particulier certains types de périphériques comme les GPU AMD
  • Le problème peut se produire quand le pilote du noyau Linux mappe un espace MMIO avec des attributs mémoire Normal, non-cacheable, comme avec ioremap_wc
    • cela peut viser à permettre le write combining ou des accès non alignés
    • dans ce cas, une corruption de données peut se produire lors des écritures MMIO sortantes sur l’interface PCIe
    • la parade consiste à mapper avec une mémoire Device, non-gathering comme avec ioremap au lieu de ioremap_wc, et à aligner strictement toutes les opérations mémoire sur l’espace MMIO PCIe
  • Pour disposer d’un système Linux utilisable au quotidien, il fallait recompiler le noyau à chaque mise à jour des paquets du noyau Fedora, en général chaque semaine
  • Après mise à jour du dépôt local de paquets noyau Fedora, le noyau était compilé avec une convention de version maison comme 7.0.2-200.fc44.pcie65.6
    • pcie65 indique le patch appliqué
    • le dernier chiffre correspondait au compteur de rebase du patch
  • Le patch était récupéré depuis un dépôt GitHub, rebasé et modifié si nécessaire, au point d’utiliser parfois un noyau plus récent que le Fedora officiel

80 cœurs ne garantissent pas une bonne réactivité desktop

  • Même avec 80 cœurs CPU, cela n’en faisait pas une bonne machine desktop
  • Un grand nombre de cœurs ne garantissait pas la réactivité perçue nécessaire sur un desktop

Des problèmes de compatibilité applicative persistants après le changement de GPU

  • L’AMD Radeon RX6700XT fonctionnait avec un noyau intégrant le patch PCIE_65 hors arbre, et il était possible de lancer des jeux ainsi que le décodage vidéo accéléré matériellement
  • À partir d’un moment autour de la sortie de Linux 7.0, le GPU AMD a commencé à poser problème
    • au lancement des jeux, le journal répétait amdgpu 0000:03:00.0: Fence fallback timer expired on ring vcn_dec_0
    • lors du visionnage de vidéos YouTube, 720 images sur 750 étaient perdues, rendant l’usage pratiquement impossible
  • Dans une situation normale, on ferait un bisect du noyau pour trouver l’origine du problème, mais avec le patch PCIE_65 le noyau était tainted, ce qui rendait la cause réelle difficile à déterminer
  • Une Nvidia RTX 2060 a été installée à la place de l’AMD Radeon
    • l’utilisation du pilote noyau nouveau nécessitait toujours le patch PCIE_65
    • la combinaison noyau Fedora standard + pilote binaire Nvidia fonctionnait correctement
    • l’accélération du décodage vidéo et certains jeux basés sur Wine fonctionnaient aussi
  • FreeCAD et OrcaSlicer plantaient juste après leur lancement
    • la cause était l’absence de org.freedesktop.Platform.GL.nvidia dans le dépôt Flatpak AArch64
    • comme ces deux outils étaient souvent utilisés, c’était le principal obstacle à la poursuite de l’usage desktop

Retour au x86-64 et nouveau rôle pour Altra

  • Finalement, le système x86-64 resté éteint a été redémarré
  • Après avoir déplacé beaucoup de câbles et ajouté de nouveaux câbles, les deux systèmes ont fini par cohabiter sous le bureau
    • wooster : système Ampere Altra
    • puchatek : système Ryzen 5 3600
  • Le passage de 80 cœurs à 6 cœurs / 12 threads était inhabituel, mais en pratique le travail s’effectue normalement
    • la musique continue même quand tous les threads sont utilisés
    • tous les jeux de la bibliothèque Steam peuvent être lancés
    • il est possible de terminer la conception d’un boîtier pour un projet maison dans FreeCAD
    • il est possible de créer directement des prototypes d’impression 3D dans OrcaSlicer
  • Le système Ampere Altra reste allumé pour gérer la compilation de paquets RISC-V
  • Ce système est faible en performances mono-thread, mais il est rapide sur les charges multithread

Il n’y aura pas de second desktop AArch64 de ce type

  • Il n’est pas prévu de répéter la même expérience desktop avec Ampere Altra
  • Pour tenter un autre desktop AArch64, il faudrait une plateforme matérielle entièrement nouvelle
  • Il n’est pas prévu de dépenser plus de 20 000 PLN pour acheter un système Nvidia DGX Spark

À lire aussi

1 commentaires

 
GN⁺ 3 시간 전
Commentaires sur Lobste.rs

  • Je me reconnais assez dans cette situation. Sur mon Raptor Talos II, IBM continue de casser PowerNV
    Au début, c’était amdgpu, et maintenant c’est la carte SATA qui pose problème. IBM continue de bricoler le PCIe pour les systèmes non bare metal, ce qui me bloque sur le noyau 6.14

    • Je suis curieux de savoir quelle distribution Linux tu utilises. Nos serveurs d’entreprise tournent sur Ubuntu 26.04 avec un noyau 7.0, et le support fonctionne bien
      J’en voulais un depuis sa sortie, mais ça fait maintenant un bon moment, et je me dis qu’une version Power 11 pourrait peut-être arriver

  • J’ai eu une expérience similaire. J’ai essayé de faire tourner NixOS sur un Thinkpad X13S, et ça fonctionnait plus ou moins, mais il a déjà fallu utiliser une ISO Ubuntu pour l’installation
    parce que je n’ai pas trouvé d’image UEFI NixOS aarch64 qui démarre correctement. Après une mise à niveau vers un noyau plus récent, le démarrage s’est cassé, et je n’ai plus l’énergie nécessaire pour simplement faire en sorte que le système fonctionne
    Ubuntu intègre aussi un certain niveau de support pour le X13S, mais beaucoup de choses qui vont de soi sur une machine x86_64 classique ne marchent tout simplement pas. La mise en veille ne fonctionne pas du tout, le support TPM est limité, le graphisme se comporte bizarrement, et il y a probablement encore d’autres problèmes que je n’ai pas testés
    Et cela sans même parler des appareils ARM qui ne proposent que de vieilles images, comme les consoles portables d’émulation de sociétés comme Anbernic, ou des appareils comme le Clockwork uConsole, qui exploitent ou détournent intelligemment le matériel et nécessitent des patchs de noyau non standard. Au final, ce logiciel n’est jamais intégré upstream, et le matériel se retrouve avec un système d’exploitation impossible à mettre à jour
    J’ai passé pas mal de temps sur plusieurs machines en espérant que Linux fonctionnerait bien sur ARM, mais je suis bloqué. À part le Raspberry Pi, rien ne fonctionne simplement, et je ne connais pas assez la partie matériel/noyau pour apporter des améliorations significatives

    • J’ai aussi acheté un X13S. Sa taille et son poids semblaient parfaits
      J’ai passé des heures à tenter d’installer NixOS de la même manière, et j’ai fini par l’installer depuis Ubuntu pour arriver à quelque chose qui fonctionnait à peu près, mais c’était trop fragile pour être réellement utilisable
      J’espérais vraiment que ça marche, mais côté Linux, j’avais l’impression qu’il avait été abandonné, et j’ai fini par laisser tomber pour faire tourner NixOS dans une machine virtuelle sur un Apple MacBook Air
    • J’ai aussi un X13s, et la seule distribution que j’ai essayée est Fedora. Quand je lance l’installateur, les entrées/sorties se figent. Pas terrible
      Comme je n’ai pas un grand attachement à Ubuntu, je n’ai pas spécialement essayé d’autres distributions, et Windows fonctionne au moins suffisamment bien
      Les SoC plus récents ont beaucoup moins de bizarreries. Par exemple, il n’est plus nécessaire de saisir une ligne de commande noyau longue comme un paragraphe. Mais il n’y aura pas de version X Elite 2 du X13s

  • Je me demande si les nouveaux ordinateurs portables Nvidia RTX Spark auront un support Linux officiel
    Au fond, c’est presque la même plateforme que le DGX Spark, qui fait tourner une distribution dérivée d’Ubuntu, mais jusqu’ici les signes ne sont pas très encourageants

  • Pour donner un contre-exemple, j’utilise un Radxa Rock5bPlus depuis environ quatre mois. Configuration avec 16 Go de mémoire et NVMe, avec le u-boot mainline, la version EFI de Fedora Rawhide et un noyau mainline
    Le travail de Collabora pour faire monter le support rk3588 dans la branche principale est franchement impressionnant
    Il reste encore des choses que j’attends. Le HDMI 2.0 et plus, donc le 4k@60, ainsi que l’USB-C DP par exemple. Mais côté matériel, ça me semble au final moins exotique que mon XPS 13 9370. Sur ce portable, la sortie audio a simplement cessé de fonctionner à partir de la version 5.14 environ
    https://dell.com/community/en/…
    https://gitlab.collabora.com/hardware-enablement/rockchip-3588/…

    • J’utilise un OrangePi 5 Plus, et j’ai vu que la capture HDMI a désormais été fusionnée
      Il n’y a toujours pas de support HDCP, mais on dirait que le moment est venu de reprendre une vieille expérimentation d’OSD HDMI 1080p à faible latence
      Ça tournait avec trois images de latence, avec un minimum théorique de deux. En superposant Chromium Embedded sur le signal HDMI, on pouvait fortement étendre les capacités OSD dans une configuration multimédia domestique
      Le plus gros problème, c’était l’instabilité, et l’ensemble de la configuration faisait planter régulièrement le noyau OrangePi

  • J’ai l’impression que cela montre surtout mieux l’état actuel du support matériel de Linux. Seul le matériel populaire et rentable obtient un support dans le noyau, et l’état des pilotes binaires est un enfer permanent depuis toujours
    Il est intéressant de voir les gens courir après Linux pour faire fonctionner quelque chose sur leur matériel, puis finir bloqués sur de vieux noyaux, ou à devoir maintenir et rebaser eux-mêmes des patchs, au lieu d’utiliser un système d’exploitation qui prendrait en charge du vieux matériel sans exiger tout cela

    • Pour moi, on dirait surtout qu’il cherche encore un moyen de faire fonctionner ce matériel défectueux avec un GPU AMD
      « Selon l’errata de la gamme Altra, PCIE_65 peut générer des adresses incorrectes lors des écritures MMIO PCIe et affecte certains types de périphériques, en particulier les GPU AMD, de sorte que la gamme Altra n’est généralement pas compatible avec ce type de périphériques. Un patch logiciel de preuve de concept sous GPL v2 a été fourni pour permettre les travaux d’expérimentation et de développement »
      Je comprends pourquoi un système d’exploitation n’aurait pas envie d’accepter un simple patch de preuve de concept
      Il existe énormément de forks du noyau Linux qui prennent en charge des morceaux de matériel spécifiques, et c’est regrettable. Ces forks contiennent souvent des commits intrusifs ou expérimentaux qui demandent davantage de travail avant d’être acceptés dans le noyau Linux principal
      Je me demande si les autres systèmes d’exploitation suivent une autre voie sur ce point. Que font-ils pour faciliter les contributions upstream tout en gardant gérable la maintenance des architectures, SoC et cartes

  • Dans ce cas, ça m’aura au moins évité l’effort d’essayer. J’espère quand même que l’identification des points de douleur sera utile à long terme

  • Je croyais être le seul à galérer. J’utilisais une configuration similaire comme serveur de développement, et la plupart des problèmes venaient de dépendances Python avec du code natif
    Je me souviens aussi de quelques paquets d’optimisation et de Matplotlib. J’ai essayé à la fois pip et uv, mais au final j’ai dû compiler depuis les sources. Je suis finalement revenu complètement sur x86, et honnêtement, même avec autant de cœurs, les performances n’étaient pas si extraordinaires

    • Quand tu dis « j’ai essayé à la fois pip et uv, mais au final j’ai dû compiler depuis les sources », tu veux dire qu’il a fallu sortir de pip et construire directement les paquets toi-même ?

  • Si tu veux un bureau Linux qui fonctionne vraiment pour le jeu, il te faut une carte Nvidia et des pilotes binaires, et il vaut mieux éviter des choses comme Flatpak qui ne s’intègrent pas bien avec ça
    C’est comme ça sur n’importe quelle architecture depuis des décennies, et ça me semble relever du simple bon sens

    • J’utilise un GPU AMD, et le jeu fonctionne très bien sous Linux. En plus, il y a globalement moins de petits problèmes qu’avec les anciennes cartes Nvidia et leur stupide bloc de pilotes propriétaires
    • Sauf besoin spécifique de Nvidia comme Cuda, AMD est le GPU privilégié pour jouer sous Linux depuis plusieurs années
    • Je ne vois pas du tout de quoi tu parles. Les GPU AMD fonctionnent bien pour le jeu, et Steam dans Flatpak fonctionne aussi très bien, par exemple
      Dans le cas de Steam, l’accès aux contrôleurs Steam ne marche pas en Flatpak, mais à part ça, tout fonctionne sans problème
      Si tu veux avancer ce genre d’affirmation, il va falloir apporter autre chose qu’un simple « fais-moi confiance »
    • Sur les dernières années, à période comparable, un Steam Deck à base d’AMD, un mini PC basé sur l’APU AMD 5750GE et un Intel Arc B580 m’ont en pratique offert une meilleure expérience qu’une NVIDIA 3090

  • Avec une configuration aussi sensible aux patchs du noyau, je n’utiliserais probablement pas du tout le paquet noyau de la distribution
    Je compilerais et démarrerais directement mon propre noyau en dehors du système de paquets, puis je mettrais à jour à mon rythme

  • Je suivais un peu le fil de cet article, et j’étais presque surpris que ça ait tenu aussi longtemps
    Ça a toujours semblé relever du « faire en sorte que ça marche tant bien que mal », donc c’est quand même triste de lire une telle conclusion