Akhir dari eksperimen desktop AArch64

 (marcin.juszkiewicz.com.pl)
1 poin oleh GN⁺ 4 jam lalu | 1 komentar | Bagikan ke WhatsApp
  • Selama sekitar 11 bulan, desktop AArch64 berbasis Ampere Altra dipakai sebagai sistem utama, tetapi beban kompatibilitas kernel, GPU, dan aplikasi terus menumpuk karena platform server dipakai seperti desktop
  • Sistemnya terdiri dari Ampere Altra Q80-30 80-core 3.0GHz, RAM 128GB, AMD Radeon RX6700XT, ASRock Rack ALTRAD8UD-1L2T, dan Fedora 42–44, dan sejak awal memang bukan perangkat keras yang ditujukan untuk desktop
  • Untuk memakai GPU AMD diperlukan patch workaround erratum 82288 / PCIE_65, sehingga setiap kali kernel Fedora diperbarui harus membangun ulang kernel sendiri, biasanya hampir setiap minggu
  • Menjelang dan sesudah Linux 7.0, muncul error GPU AMD dan frame drop video, dan bahkan setelah beralih ke Nvidia RTX 2060, FreeCAD dan OrcaSlicer tetap crash karena tidak adanya org.freedesktop.Platform.GL.nvidia di repositori Flatpak AArch64
  • Pada akhirnya kembali ke sistem x86-64 Ryzen 5 3600, Ampere Altra dipertahankan untuk build paket RISC-V alih-alih desktop, dan disimpulkan bahwa desktop AArch64 baru memerlukan platform perangkat keras yang berbeda

Konfigurasi memakai Altra server sebagai desktop

  • Setelah sekitar 11 bulan memakai desktop AArch64 sebagai sistem utama, eksperimen ini diakhiri
  • Konfigurasi perangkat keras terakhir adalah sebagai berikut
    • CPU: Ampere Altra Q80-30, 80-core 3.0GHz
    • RAM: 128GB, 8×16GB HMA82GR7CJR8N-XN
    • GPU: AMD Radeon RX6700XT
    • NVMe: Lexar LM970 2TB, ADATA SX8200 Pro 1TB
    • Mainboard: ASRock Rack ALTRAD8UD-1L2T
    • PSU: MSI MPG A850G 850W
    • Casing: Endorfy 700 Air
    • USB3: kontroler USB 3.2/10Gbps PCIe x4 tanpa merek
  • Board ini adalah mainboard server, dan sistem Altra sendiri juga bukan produk yang dirancang untuk desktop
  • QVL sistem Ampere Altra tidak mencantumkan kartu GPU AMD Radeon, dan meskipun bisa dijalankan, sering kali memerlukan pekerjaan tambahan
  • Kontroler USB 3.2 terpisah menyediakan lebih banyak perangkat USB dan port 10Gbps untuk NVMe eksternal dibanding dukungan bawaan mainboard
  • Seluruh sistem berjalan di Fedora 42–44, tetapi untuk penggunaan nyata diperlukan kernel rakitan sendiri, bukan kernel Fedora bawaan

Beban perawatan kernel akibat PCIE_65

  • Pengendali PCI Express pada Ampere Altra memiliki masalah erratum 82288 / PCIE_65
  • PCIE_65 dapat menghasilkan alamat yang salah pada penulisan PCIe MMIO, dan terutama memengaruhi jenis perangkat tertentu seperti GPU AMD
  • Masalah dapat muncul ketika driver kernel Linux memetakan ruang MMIO dengan atribut memori Normal, non-cacheable seperti ioremap_wc
    • Tujuannya bisa untuk memungkinkan write combining atau akses yang tidak selaras
    • Dalam kasus ini, korupsi data dapat terjadi pada outbound MMIO write di antarmuka PCIe
    • Workaround-nya adalah memetakan dengan memori Device, non-gathering seperti ioremap alih-alih ioremap_wc, dan menyelaraskan secara ketat semua operasi memori pada ruang PCIe MMIO
  • Agar bisa dipakai sebagai sistem Linux yang normal, kernel harus dibangun ulang setiap kali paket kernel Fedora diperbarui, biasanya setiap minggu
  • Setelah memperbarui repositori paket kernel Fedora lokal, kernel dibangun dengan aturan versi sendiri seperti 7.0.2-200.fc44.pcie65.6
    • pcie65 menandakan patch yang diterapkan
    • Angka terakhir adalah jumlah rebase patch
  • Patch diambil dari repositori GitHub, di-rebase, dan dimodifikasi bila perlu, sehingga terkadang justru memakai kernel yang lebih baru daripada Fedora resmi

80 core tidak otomatis menjamin performa desktop yang terasa cepat

  • Memiliki 80 core CPU tidak otomatis menjadikannya mesin desktop yang bagus
  • Jumlah core yang besar tidak menjamin performa responsif yang dibutuhkan pada desktop

Masalah kompatibilitas aplikasi tetap ada setelah ganti GPU

  • AMD Radeon RX6700XT berjalan pada kernel dengan patch PCIE_65 out-of-tree, dan bisa dipakai untuk menjalankan game serta decoding video berbantuan hardware
  • Pada suatu titik menjelang atau sesudah rilis Linux 7.0, GPU AMD mulai gagal
    • Saat menjalankan game, log amdgpu 0000:03:00.0: Fence fallback timer expired on ring vcn_dec_0 terus berulang
    • Saat menonton video YouTube, 720 dari 750 frame ter-drop sehingga praktis tidak bisa dipakai
  • Dalam situasi normal, kernel akan di-bisect untuk mencari titik masalah, tetapi karena patch PCIE_65 membuat kernel berada dalam keadaan tainted, sulit menilai penyebab sebenarnya
  • Sebagai pengganti AMD Radeon, dipasang Nvidia RTX 2060
    • Untuk memakai driver kernel nouveau, patch PCIE_65 tetap dibutuhkan
    • Kombinasi kernel Fedora bawaan dan driver biner Nvidia berjalan normal
    • Akselerasi decoding video dan beberapa game berbasis Wine juga berfungsi
  • FreeCAD dan OrcaSlicer crash segera setelah dijalankan
    • Penyebabnya adalah repositori Flatpak AArch64 tidak memiliki org.freedesktop.Platform.GL.nvidia
    • Kedua alat ini adalah aplikasi yang sering dipakai, dan menjadi masalah utama yang membuat transisi desktop sulit dilakukan

Kembali ke x86-64 dan peran baru Altra

  • Pada akhirnya, sistem x86-64 yang sebelumnya dimatikan dinyalakan kembali
  • Setelah memindahkan banyak kabel dan menata kabel baru, kedua sistem dipakai bersama di bawah meja
    • wooster: sistem Ampere Altra
    • puchatek: sistem Ryzen 5 3600
  • Perpindahan dari 80 core ke 6 core 12 thread terasa aneh, tetapi pekerjaan nyata tetap berjalan normal
    • Musik tetap berjalan meski semua thread dipakai
    • Semua game di pustaka Steam dapat dimainkan
    • Desain casing untuk proyek rumahan bisa diselesaikan dengan FreeCAD
    • Prototipe untuk cetak 3D bisa langsung dibuat di OrcaSlicer
  • Sistem Ampere Altra tetap dibiarkan menyala untuk menangani build paket RISC-V
  • Sistem ini lemah dalam performa single-thread, tetapi bekerja cepat pada beban multicore

Tidak akan mengulangi desktop AArch64 dengan cara yang sama

  • Tidak ada rencana mengulangi eksperimen desktop yang sama dengan Ampere Altra
  • Jika ingin mencoba desktop AArch64 lain, diperlukan platform perangkat keras yang sepenuhnya baru
  • Tidak ada rencana mengeluarkan lebih dari 20.000 PLN untuk membeli sistem Nvidia DGX Spark

Bacaan terkait

1 komentar

 
GN⁺ 4 jam lalu
Komentar di Lobste.rs

  • Saya cukup bersimpati dengan situasi ini. Di Raptor Talos II saya, IBM terus merusak PowerNV
    Awalnya amdgpu, dan sekarang kartu SATA yang bermasalah. Karena IBM terus mengutak-atik PCIe untuk sistem non-bare-metal, saya tertahan di kernel 6.14

    • Saya penasaran distribusi Linux apa yang dipakai. Server perusahaan kami menjalankan Ubuntu 26.04 dengan kernel 7.0, dan dukungannya berjalan baik
      Sejak rilis saya ingin punya satu, tetapi sekarang sudah cukup tua, dan saya berpikir mungkin saja akan ada versi Power 11

  • Pengalaman saya juga mirip. Saya mencoba menjalankan NixOS di Thinkpad X13S, dan sebagian memang berfungsi, tetapi dari tahap instalasi pun harus memakai ISO Ubuntu
    Karena saya tidak bisa menemukan image NixOS aarch64 UEFI yang bisa boot dengan benar. Setelah upgrade kernel terbaru, boot rusak, dan sekarang energi saya untuk sekadar membuat sistemnya berjalan sudah habis
    Ubuntu juga punya sejumlah dukungan untuk X13S, tetapi cukup banyak hal yang seharusnya wajar di mesin x86_64 tradisional justru tidak berfungsi. Suspend sama sekali tidak jalan, dukungan TPM terbatas, grafis juga berperilaku aneh, dan mungkin masih ada lebih banyak masalah yang belum sempat saya uji
    Itu pun belum menghitung perangkat ARM yang hanya menyediakan image lama, seperti handheld emulasi dari perusahaan seperti Anbernic, atau perangkat seperti Clockwork uConsole yang menggunakan—atau menyalahgunakan—hardware secara cerdik sehingga membutuhkan patch kernel nonstandar. Pada akhirnya perangkat lunak seperti itu tidak masuk upstream, dan hardwarenya tersisa dengan sistem operasi yang tidak bisa diperbarui
    Saya sudah menghabiskan cukup banyak waktu di beberapa komputer dengan harapan ARM bisa berjalan baik di Linux, tetapi mentok. Selain Raspberry Pi, tidak ada yang langsung berjalan, dan saya tidak cukup memahami sisi hardware/kernel untuk membuat perbaikan yang berarti

    • Saya juga membeli X13S. Ukuran dan bobotnya terlihat sempurna
      Dengan cara yang sama, saya menghabiskan berjam-jam untuk instalasi NixOS, lalu menginstalnya dari Ubuntu dan membuatnya kira-kira berjalan, tetapi terlalu rapuh sehingga pada praktiknya sulit dipakai dengan benar
      Saya benar-benar berharap itu berjalan baik, tetapi di sisi Linux rasanya seperti ditinggalkan, dan akhirnya saya menyerah lalu menjalankan NixOS sebagai mesin virtual di Apple MacBook Air
    • Saya juga punya X13s, dan satu-satunya distribusi yang saya coba adalah Fedora; saat menjalankan installer, terjadi hang pada input/output. Tidak bagus
      Saya juga tidak punya ketertarikan besar pada Ubuntu, jadi saya tidak mencoba distribusi lain, sementara Windows tetap berjalan cukup baik
      SoC yang lebih baru jauh lebih sedikit keanehannya. Misalnya, tidak perlu memasukkan command line kernel sepanjang satu paragraf. Namun versi X Elite 2 dari X13s tidak pernah muncul

  • Saya penasaran apakah laptop Nvidia RTX Spark baru akan mendapat dukungan Linux resmi
    Pada akhirnya platformnya hampir sama dengan DGX Spark yang menjalankan distribusi turunan Ubuntu, tetapi tanda-tanda sejauh ini tidak terlihat terlalu bagus

  • Sebagai pengalaman sebaliknya, saya sudah memakai Radxa Rock5bPlus sekitar 4 bulan. Konfigurasinya 16 GB memori dan NVMe, menggunakan mainline u-boot, versi EFI dari Fedora Rawhide, dan kernel mainline
    Pekerjaan Collabora untuk membawa dukungan rk3588 ke mainline benar-benar nyaris menakjubkan
    Masih ada beberapa hal yang saya tunggu. HDMI 2.0 atau lebih tinggi, yaitu 4k@60, dan hal-hal seperti USB-C DP. Meski begitu, dari sisi hardware rasanya malah lebih sedikit keanehannya dibanding XPS 13 9370 saya. Di laptop itu, output audio berhenti begitu saja sejak sekitar 5.14
    https://dell.com/community/en/…
    https://gitlab.collabora.com/hardware-enablement/rockchip-3588/…

    • Saya memakai OrangePi 5 Plus, dan saya melihat capture HDMI sekarang sudah digabungkan
      Dukungan HDCP memang belum ada, tetapi sepertinya sudah waktunya kembali ke eksperimen OSD HDMI 1080p latensi rendah yang pernah saya coba
      Dulu berjalan dengan latensi 3 frame, dan minimum teoretisnya 2 frame. Dengan meng-overlay Chromium Embedded di atas sinyal HDMI, kemampuan OSD dalam setup media rumah bisa diperluas cukup besar
      Masalah terbesarnya adalah ketidakstabilan, dan seluruh setup itu secara berkala membuat kernel OrangePi crash

  • Ini sepertinya lebih menunjukkan kondisi dukungan hardware Linux saat ini. Hanya hardware yang populer dan menguntungkan yang mendapat dukungan kernel, dan keadaan driver biner dari dulu sampai sekarang tetap seperti neraka
    Menarik melihat orang-orang mengejar Linux untuk membuat sesuatu berjalan di hardware mereka, lalu akhirnya tertahan di kernel lama, atau harus memelihara dan me-rebase patch sendiri. Padahal mereka bisa memakai sistem operasi yang mendukung hardware lama tanpa perlu melakukan hal seperti ini

    • Bagi saya ini terdengar seperti mereka masih mencari cara agar hardware cacat ini bisa bekerja baik dengan GPU AMD
      Isinya kira-kira, “Menurut errata keluarga produk Altra, PCIE_65 dapat menghasilkan alamat yang salah pada penulisan PCIe MMIO, dan berdampak pada jenis perangkat tertentu, terutama GPU AMD, sehingga keluarga Altra umumnya tidak kompatibel dengan jenis perangkat tersebut. Agar pekerjaan eksperimen dan pengembangan dapat dilakukan, kami menyediakan patch perangkat lunak proof-of-concept di bawah GPL v2”
      Saya bisa memahami mengapa sistem operasi tidak ingin menerima patch yang sekadar proof-of-concept
      Ada sangat banyak fork kernel Linux yang mendukung potongan hardware tertentu, dan itu menyedihkan. Fork seperti ini sering berisi commit yang invasif atau eksperimental dan membutuhkan lebih banyak pekerjaan agar bisa diterima ke kernel Linux mainline
      Saya penasaran apakah sistem operasi lain mengambil jalan berbeda di sini. Apa yang mereka lakukan agar kontribusi upstream lebih mudah sekaligus membuat pemeliharaan arsitektur, SoC, dan board tetap tertangani

  • Kalau begitu, saya jadi tidak perlu repot-repot mencoba. Meski begitu, semoga memahami titik-titik nyeri ini akan membantu dalam jangka panjang

  • Saya kira hanya saya yang kesulitan. Saya memakai spesifikasi serupa sebagai server pengembangan, dan sebagian besar masalah berasal dari dependensi Python yang punya kode native
    Saya ingat beberapa paket optimisasi dan juga Matplotlib. Saya mencoba pip biasa dan uv, tetapi pada akhirnya harus mengompilasi dari source. Akhirnya saya sepenuhnya kembali ke x86, dan jujur saja meski core-nya sebanyak itu, performanya tidak terlalu luar biasa

    • Saya penasaran apakah “mencoba pip dan uv, tetapi akhirnya harus mengompilasi dari source” berarti harus keluar dari pip dan membangun paket secara manual

  • Kalau menginginkan desktop Linux yang benar-benar berjalan untuk gaming, Anda butuh kartu Nvidia dan driver biner, serta harus menghindari hal-hal seperti Flatpak yang tidak bisa berjalan selaras dengannya
    Ini sudah begitu selama puluhan tahun di arsitektur apa pun, dan menurut saya hampir seperti pengetahuan umum

    • Saya memakai GPU AMD, dan gaming di Linux berjalan sangat baik. Selain itu, secara keseluruhan masalah-masalah kecilnya juga lebih sedikit dibanding Nvidia lama dan tumpukan driver tertutupnya yang bodoh itu
    • Jika tidak benar-benar membutuhkan Nvidia untuk hal lain seperti Cuda, AMD sudah menjadi GPU yang lebih disukai untuk gaming Linux sejak beberapa tahun lalu
    • Saya tidak paham maksudnya. GPU AMD berfungsi baik untuk gaming, dan misalnya Steam di dalam Flatpak juga berjalan baik
      Untuk Steam, akses Steam Controller memang tidak bisa di Flatpak, tetapi selain itu berjalan tanpa masalah
      Kalau mau membuat klaim seperti itu, bawalah data pendukung, bukan sekadar “percaya saja”
    • Jika melihat periode beberapa tahun terakhir, Steam Deck berbasis AMD, mini PC berbasis APU AMD 5750GE, dan Intel Arc B580 benar-benar memberi pengalaman yang lebih baik daripada NVIDIA 3090

  • Untuk konfigurasi yang sensitif terhadap patch kernel seperti ini, saya rasa saya tidak akan memakai paket kernel dari distribusi sama sekali
    Saya akan membangun dan mem-boot kernel sendiri di luar sistem paket, lalu memperbaruinya sesuai ritme saya sendiri

  • Saya sempat mengikuti alur tulisan ini sedikit, dan justru terkejut bahwa itu bisa berjalan selama itu
    Sejak awal selalu terlihat seperti “membuatnya jalan dengan cara apa pun”, dan tetap saja membaca akhir seperti ini terasa disayangkan