AArch64デスクトップ実験の終わり

 (marcin.juszkiewicz.com.pl)
1 ポイント 投稿者 GN⁺ 4 시간 전 | 1件のコメント | WhatsAppで共有
  • 約11か月間 Ampere AltraベースのAArch64デスクトップ を実運用したが、サーバー向けプラットフォームをデスクトップのように使う中で、カーネル・GPU・アプリ互換性の負担が積み重なり続けた
  • システムは Ampere Altra Q80-30 80コア 3.0GHz、128GB RAM、AMD Radeon RX6700XT、ASRock Rack ALTRAD8UD-1L2T、Fedora 42–44 の組み合わせで、そもそもデスクトップ向けハードウェアではなかった
  • AMD GPUの利用には erratum 82288 / PCIE_65 の回避パッチが必要で、Fedoraのカーネル更新のたびに、ほぼ毎週のように独自カーネルを再ビルドする必要があった
  • Linux 7.0前後からAMD GPUの不具合と動画のフレームドロップが発生し、Nvidia RTX 2060に切り替えた後も、AArch64 Flatpakリポジトリに org.freedesktop.Platform.GL.nvidia がないため、FreeCADとOrcaSlicerがクラッシュした
  • 最終的にx86-64のRyzen 5 3600システムへ戻り、Ampere Altraはデスクトップではなく RISC-Vパッケージビルド 用に残し、新しいAArch64デスクトップには別のハードウェアプラットフォームが必要だと判断した

サーバー向けAltraをデスクトップとして使った構成

  • 約11か月間AArch64デスクトップを実運用した末に、実験を終了 した
  • 最終的なハードウェア構成は以下のとおり
    • CPU: Ampere Altra Q80-30、80コア 3.0GHz
    • RAM: 128GB、8×16GB HMA82GR7CJR8N-XN
    • GPU: AMD Radeon RX6700XT
    • NVMe: Lexar LM970 2TB、ADATA SX8200 Pro 1TB
    • マザーボード: ASRock Rack ALTRAD8UD-1L2T
    • PSU: MSI MPG A850G 850W
    • ケース: Endorfy 700 Air
    • USB3: PCIe x4の無名USB 3.2/10Gbpsコントローラー
  • このボードは サーバーマザーボード であり、Altraシステム自体もデスクトップ向けに設計された製品ではない
  • Ampere AltraシステムのQVLにはAMD Radeon GPUカードは含まれておらず、動作させることはできても追加作業が必要になることが多い
  • 別途追加したUSB 3.2コントローラーは、マザーボード標準のサポートより多くのUSB機器と、外付けNVMe向けの 10Gbpsポート を提供する
  • システム全体はFedora 42–44で動作したが、実際の運用には標準のFedoraカーネルではなく独自ビルドのカーネルが必要だった

PCIE_65がもたらしたカーネル保守の負担

  • Ampere AltraのPCI Expressコントローラーには erratum 82288 / PCIE_65 の問題がある
  • PCIE_65はPCIe MMIO書き込みで誤ったアドレスを生成することがあり、特にAMD GPUのような特定のデバイスタイプに影響する
  • Linuxカーネルドライバーが ioremap_wc のようにMMIO空間をNormal, non-cacheableメモリ属性でマップする場合に問題が起きる可能性がある
    • これはwrite combiningや非整列アクセスを可能にするためのことがある
    • この場合、PCIeインターフェースのoutbound MMIO writeで データ破損 が発生しうる
    • 回避策は ioremap_wc の代わりに ioremap のようなDevice, non-gatheringメモリでマップし、PCIe MMIO空間に対するすべてのメモリ操作を厳密に整列させる方式である
  • 正常なLinuxシステムとして使うには、Fedoraのカーネルパッケージ更新のたびにカーネルを再ビルドする必要があり、通常は 毎週 作業が必要だった
  • ローカルのFedoraカーネルパッケージリポジトリを更新した後、7.0.2-200.fc44.pcie65.6 のような独自のバージョン規則でビルドしていた
    • pcie65 は適用したパッチを示す
    • 最後の数字はパッチのリベース回数だった
  • GitHubリポジトリからパッチを取得してリベースし、必要に応じて修正していたため、その結果として公式Fedoraより新しいカーネルを使うこともあった

80コアでもデスクトップの体感性能は保証されない

  • CPUコアが80個あっても、優れた デスクトップマシン になるとは限らなかった
  • 多数のコアは、デスクトップで必要とされる素早い体感性能を保証しなかった

GPUを交換しても残ったアプリ互換性の問題

  • AMD Radeon RX6700XTは、out-of-treeのPCIE_65パッチを適用したカーネルで動作し、ゲームの実行やハードウェア支援による動画デコードも可能だった
  • Linux 7.0リリース前後のある時点からAMD GPUが失敗し始めた
    • ゲーム実行時に amdgpu 0000:03:00.0: Fence fallback timer expired on ring vcn_dec_0 というログが繰り返し出力された
    • YouTube動画視聴では750フレーム中720フレームがドロップし、実質的に使い物にならなかった
  • 通常であればカーネルをbisectして問題箇所を特定するところだが、PCIE_65パッチのためにカーネルがtainted状態となり、実際の原因を判断しにくかった
  • AMD Radeonの代わりに Nvidia RTX 2060 を装着した
    • nouveau カーネルドライバーを使う場合でも、依然としてPCIE_65パッチが必要だった
    • 標準のFedoraカーネルとNvidiaバイナリドライバーの組み合わせは正常に動作した
    • 動画デコード支援とWineベースの一部ゲームも動作した
  • FreeCADとOrcaSlicerは起動直後にクラッシュした
    • 原因は、AArch64 Flatpakリポジトリに org.freedesktop.Platform.GL.nvidia が存在しないことだった
    • この2つのツールは頻繁に使うアプリであり、デスクトップ移行を難しくした中核的な問題だった

x86-64への復帰とAltraの新しい役割

  • 最終的に、電源を切ってあった x86-64システム を再び起動した
  • 多くのケーブルを移し替え、新しいケーブルも配線した結果、机の下で2つのシステムを併用するようになった
    • wooster: Ampere Altraシステム
    • puchatek: Ryzen 5 3600システム
  • 80コアから6コア12スレッドへ移る体験は奇妙だったが、実際の作業は問題なく進んだ
    • すべてのスレッドを使っていても音楽再生は継続した
    • Steamライブラリ内のすべてのゲームをプレイできる
    • FreeCADで自宅プロジェクト用ケースの設計を仕上げられる
    • OrcaSlicerですぐに3Dプリント用のプロトタイプを作れる
  • Ampere Altraシステムは稼働させたまま、RISC-Vパッケージビルド を処理している
  • このシステムはシングルスレッド性能は弱いが、マルチコア負荷では高速に動作する

同じ方式のAArch64デスクトップは繰り返さない

  • Ampere Altraで同じデスクトップ実験を繰り返す予定はない
  • 別のAArch64デスクトップを試すなら、まったく新しいハードウェアプラットフォーム が必要になる
  • Nvidia DGX Sparkシステムを買うために20,000 PLN以上を支出するつもりはない

関連記事

1件のコメント

 
GN⁺ 4 시간 전
Lobste.rsの意見

  • この状況にはある程度共感する。自分の Raptor Talos II では IBM が PowerNV を壊し続けている
    最初は amdgpu で、今は SATA カードが問題だ。IBM が非ベアメタルシステム向けの PCIe をいじり続けているせいで、6.14 カーネルに縛られている

    • どの Linux ディストリビューション を使っているのか気になる。会社のサーバーでは Ubuntu 26.04 に 7.0 カーネルを載せて使っていて、うまくサポートされている
      発売時から1台欲しかったが、今となってはかなり古くなっていて、もしかすると Power 11 バージョンが出るかもしれないとも思う

  • 自分も似たような感じだった。Thinkpad X13S で NixOS を動かそうとしたが、ある程度は動いたものの、インストール時点から Ubuntu ISO を使わなければならなかった
    きちんと起動する aarch64 UEFI の NixOS イメージが見つからなかったからだ。最新カーネルへのアップグレード後に起動が壊れ、今ではシステムをただ動く状態にするために使う気力も尽きた
    Ubuntu でも X13S 向けのサポートはいくらか入っているが、従来の x86_64 マシンなら当然動くものがかなり多く動かない。スリープはまったく駄目で、TPM サポートは限定的、グラフィックスの挙動も独特で、まだ試せていない問題ももっと多いと思う
    しかもこれは、Anbernic のような会社のエミュレーション向け携帯機のように古いイメージしか提供されない ARM デバイスや、Clockwork uConsole のようにハードウェアを巧妙に使ったり無理に活用したりして非標準のカーネルパッチが必要なデバイスを除外してなおの話だ。結局そういうソフトウェアはアップストリームに入れられず、更新できない OS を載せたハードウェアとして残ってしまう
    Linux で ARM がうまく動くことを期待して複数のコンピューターでかなり時間を使ってきたが、行き詰まっている。Raspberry Pi を除けば「普通に動く」ものは何もなく、ハードウェアやカーネル周りを十分理解していないので意味のある改善を作るのも難しい

    • 自分も X13S を買った。サイズと重さが完璧に見えたからだ
      同じように NixOS のインストールに何時間も費やし、Ubuntu からインストールして何とかそれっぽく動かしたが、あまりに脆くて実用はほぼ無理だった
      本当にうまくいってほしかったが、Linux 側では見捨てられたように感じ、結局あきらめて Apple MacBook Air で NixOS を仮想マシンとして動かすようになった
    • 自分も X13s を持っているが、試したディストリビューションは Fedora だけで、インストーラーを起動すると I/O ハングが起きる。よくない
      Ubuntu に特別な愛着があるわけでもないので他のディストリビューションをわざわざ試してはいないが、Windows はそれなりに十分ちゃんと動く
      もっと新しい SoC は癖がずっと少ない。たとえばカーネルコマンドラインを一段落分も入力する必要はない。ただし X13s の X Elite 2 バージョンは出ていない

  • 新しい Nvidia RTX Spark ノートPC が公式の Linux サポートを受けるのか気になる
    結局は Ubuntu 派生ディストリビューションを動かす DGX Spark とほぼ同じプラットフォームだが、今のところ兆候はあまりよく見えない

  • 逆の経験を挙げると、Radxa Rock5bPlus を4か月ほど使っている。16GB メモリと NVMe の構成で、メインライン u-boot と Fedora Rawhide の EFI 版、メインラインカーネルを使っている
    rk3588 サポートをメインラインに載せるために Collabora が行った作業は、実際驚くべきものだ
    まだ待っている部分はある。HDMI 2.0 以上、つまり 4k@60 と、USB-C DP のようなものだ。それでもハードウェア面では、自分の XPS 13 9370 よりむしろ癖が少ない気がする。あのノートPCは 5.14 あたりからオーディオ出力が普通に止まってしまった
    https://dell.com/community/en/…
    https://gitlab.collabora.com/hardware-enablement/rockchip-3588/…

    • OrangePi 5 Plus を使っているが、HDMI キャプチャがついにマージされたのを見た
      まだ HDCP サポートはないが、以前やっていた低遅延 1080p HDMI OSD の実験に戻る時期かもしれない
      3フレーム遅延で動いていて、理論上の最小は 2 フレームだ。HDMI 信号の上に Chromium Embedded をオーバーレイして、ホームメディア構成での OSD 機能を大きく拡張できた
      最大の問題は不安定さで、構成全体が OrangePi カーネルを定期的にクラッシュさせていた

  • これは現在の Linux のハードウェアサポート状況 をよりよく示しているように思う。人気があって利益になるハードウェアだけがカーネルサポートを受け、バイナリドライバーの状態は昔から今までずっと地獄だ
    人々が自分のハードウェアで何かを動かそうとして Linux を追い回し、結局古いカーネルに縛られたり、自分でパッチを保守してリベースし続けたりするのは興味深い。そうしたことをしなくても古いハードウェアをサポートする OS を使えばよいのに、と思う

    • 自分には、これはこの欠陥ハードウェアを AMD GPU とうまく動かす方法をまだ探しているように聞こえる
      「Altra 製品群の正誤表によれば、PCIE_65 は PCIe MMIO 書き込みで誤ったアドレスを生成する可能性があり、特定のデバイスタイプ、とりわけ AMD GPU に影響するため、Altra 製品群は一般にその種のデバイスタイプと互換性がない。実験および開発作業を進められるよう、GPL v2 で概念実証ソフトウェアパッチを提供した」という話だ
      OS が単なる概念実証パッチを受け入れたがらない理由は理解できる
      特定のハードウェア片をサポートする Linux カーネルフォークは非常に多く、これは残念なことだ。こうしたフォークには、メインライン Linux カーネルに受け入れられるにはさらに多くの作業が必要な、侵襲的または実験的なコミットが含まれていることが多い
      他の OS はここで別の道を取っているのだろうか。アップストリームへの貢献を容易にしつつ、アーキテクチャ、SoC、ボードの保守を現実的な範囲に収めるために何をしているのか気になる

  • それなら、試してみようとしていた手間が省けた。それでも 痛点 を把握することが長期的には役に立つといい

  • 自分だけが苦労しているのかと思っていた。開発サーバーとして似たような仕様を使っていたが、問題の大半は ネイティブコードを含む Python 依存関係 から来ていた
    いくつかの最適化パッケージや Matplotlib も覚えている。通常の pip と uv の両方を試したが、結局ソースからコンパイルすることになった。最終的には x86 に完全に戻り、正直なところコア数が多くても性能はそれほどすごくなかった

    • 「pip と uv の両方を試したが、結局ソースからコンパイルすることになった」というのは、pip の外に出てパッケージを直接ビルドしなければならなかった、という意味なのか気になる

  • ゲーム用に実際にちゃんと動く Linux デスクトップ が欲しいなら Nvidia カードとバイナリドライバーが必要で、それとうまく噛み合わない Flatpak のようなものは避けるべきだ
    これはどのアーキテクチャでも何十年もそうで、常識に近いと思う

    • 自分は AMD GPU を使っているが、Linux でのゲームはとても快適だ。しかも昔の Nvidia とあの馬鹿げたクローズドドライバーの塊より、全体的な細かな問題も少ない
    • Cuda のように Nvidia がどうしても必要な別用途がない限り、Linux ゲームではここ数年 AMD が好まれる GPU だった
    • 何を言っているのかわからない。AMD GPU はゲームで普通に動くし、たとえば Flatpak 内の Steam でも問題ない
      Steam については Flatpak だと Steam コントローラーへのアクセスがないが、それ以外は問題なく動く
      そういう主張をするなら、「信じてくれ」ではなく裏づけるデータくらい持ってくるべきだ
    • ここ数年を同じ期間で比べると、AMD ベースの Steam Deck、AMD APU の 5750GE ベースのミニ PC、Intel Arc B580 のほうが、NVIDIA 3090 より実際には良い体験を与えてくれた

  • こんな カーネルパッチに敏感な構成 なら、ディストリビューションのカーネルパッケージはそもそも使わないと思う
    パッケージシステムの外で自分でカーネルをビルドして起動し、自分のペースで更新するだろう

  • この話の流れを少し追っていたが、そんなに長く動いていたことのほうがむしろ驚きだった
    ずっと「何とか無理やり動かしている」状態に見えていたし、それでもこんな結末を読むと残念だ