จุดจบของการทดลองเดสก์ท็อป AArch64

 (marcin.juszkiewicz.com.pl)
1 คะแนน โดย GN⁺ 4 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • ใช้งานจริง เดสก์ท็อป AArch64 ที่ใช้ Ampere Altra ประมาณ 11 เดือน แต่เมื่อใช้แพลตฟอร์มสำหรับเซิร์ฟเวอร์เหมือนเดสก์ท็อป ภาระด้านเคอร์เนล, GPU และความเข้ากันได้ของแอปก็สะสมต่อเนื่อง
  • ระบบประกอบด้วย Ampere Altra Q80-30 80 คอร์ 3.0GHz, RAM 128GB, 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 แล้ว FreeCAD กับ OrcaSlicer ก็ยังแครชเพราะในคลัง AArch64 Flatpak ไม่มี org.freedesktop.Platform.GL.nvidia
  • สุดท้ายจึงกลับไปใช้ระบบ x86-64 Ryzen 5 3600 โดยคง Ampere Altra ไว้สำหรับ บิลด์แพ็กเกจ RISC-V แทนเดสก์ท็อป และสรุปว่าหากจะทำเดสก์ท็อป AArch64 ใหม่ต้องใช้แพลตฟอร์มฮาร์ดแวร์อื่น

การตั้งค่าที่นำ Altra สำหรับเซิร์ฟเวอร์มาใช้เป็นเดสก์ท็อป

  • หลังใช้งานเดสก์ท็อป AArch64 จริงประมาณ 11 เดือน จึง ยุติการทดลอง
  • สเปกฮาร์ดแวร์สุดท้ายมีดังนี้
    • 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: คอนโทรลเลอร์ USB 3.2/10Gbps แบบ PCIe x4 ไม่ระบุแบรนด์
  • บอร์ดนี้เป็น เมนบอร์ดเซิร์ฟเวอร์ และตัวระบบ Altra เองก็ไม่ได้ออกแบบมาเป็นผลิตภัณฑ์สำหรับเดสก์ท็อป
  • QVL ของระบบ Ampere Altra ไม่มีการระบุการ์ด AMD Radeon GPU ไว้ แม้ทำให้ใช้งานได้ แต่บ่อยครั้งต้องลงแรงเพิ่มเติม
  • คอนโทรลเลอร์ USB 3.2 แยกต่างหากให้จำนวนอุปกรณ์ USB ที่รองรับมากกว่าการรองรับพื้นฐานของเมนบอร์ด และมี พอร์ต 10Gbps สำหรับ NVMe ภายนอก
  • ระบบโดยรวมทำงานบน Fedora 42–44 ได้ แต่ในการใช้งานจริงจำเป็นต้องใช้เคอร์เนลที่บิลด์เอง ไม่ใช่เคอร์เนล Fedora มาตรฐาน

ภาระดูแลเคอร์เนลที่ PCIE_65 สร้างขึ้น

  • คอนโทรลเลอร์ PCI Express ของ Ampere Altra มีปัญหา erratum 82288 / PCIE_65
  • PCIE_65 อาจสร้างแอดเดรสที่ผิดพลาดในการเขียน PCIe MMIO และส่งผลกระทบเป็นพิเศษต่ออุปกรณ์บางประเภท เช่น AMD GPU
  • ปัญหาอาจเกิดขึ้นเมื่อไดรเวอร์เคอร์เนล Linux แมปพื้นที่ MMIO เป็นแอตทริบิวต์หน่วยความจำแบบ Normal, non-cacheable เช่น ioremap_wc
    • จุดประสงค์อาจเพื่อให้ทำ write combining หรือเข้าถึงแบบไม่จัดแนวได้
    • ในกรณีนี้ อาจเกิด ข้อมูลเสียหาย ใน outbound MMIO write ของอินเทอร์เฟซ PCIe
    • วิธีอ้อมปัญหาคือแมปเป็นหน่วยความจำแบบ Device, non-gathering เช่น ioremap แทน ioremap_wc และบังคับให้ทุกการดำเนินการกับหน่วยความจำในพื้นที่ PCIe MMIO ต้องจัดแนวอย่างเข้มงวด
  • หากต้องการใช้เป็นระบบ Linux ปกติ จำเป็นต้องบิลด์เคอร์เนลใหม่ทุกครั้งที่แพ็กเกจเคอร์เนล Fedora อัปเดต และโดยทั่วไปต้องทำงานนี้ ทุกสัปดาห์
  • หลังอัปเดตคลังแพ็กเกจเคอร์เนล Fedora แบบโลคัลแล้ว จะบิลด์ด้วยรูปแบบเวอร์ชันของตัวเอง เช่น 7.0.2-200.fc44.pcie65.6
    • pcie65 หมายถึงแพตช์ที่นำมาใช้
    • ตัวเลขสุดท้ายคือเคาน์เตอร์การ rebase แพตช์
  • นำแพตช์จากรีโพซิทอรี GitHub มา rebase และแก้ไขเมื่อจำเป็น ส่งผลให้บางครั้งใช้เคอร์เนลที่ใหม่กว่า Fedora ทางการ

80 คอร์ไม่ได้รับประกันประสบการณ์เดสก์ท็อปที่เร็ว

  • แม้มี CPU 80 คอร์ ก็ไม่ได้ทำให้กลายเป็น เครื่องเดสก์ท็อป ที่ดี
  • จำนวนคอร์ที่มากไม่ได้รับประกันความเร็วที่ผู้ใช้เดสก์ท็อปสัมผัสได้ทันใจ

ปัญหาความเข้ากันได้ของแอปที่ยังเหลือแม้เปลี่ยน GPU แล้ว

  • AMD Radeon RX6700XT ทำงานได้บนเคอร์เนลที่ใช้แพตช์ PCIE_65 แบบ out-of-tree และสามารถรันเกมรวมถึงถอดรหัสวิดีโอด้วยฮาร์ดแวร์ได้
  • ตั้งแต่บางช่วงก่อนหรือหลังการปล่อย Linux 7.0 AMD GPU เริ่มมีปัญหา
    • เมื่อรันเกม มีล็อก amdgpu 0000:03:00.0: Fence fallback timer expired on ring vcn_dec_0 ซ้ำ ๆ
    • เมื่อดูวิดีโอ YouTube เฟรมดรอป 720 เฟรมจากทั้งหมด 750 เฟรม จนแทบใช้งานไม่ได้
  • ในสถานการณ์ทั่วไปคง bisect เคอร์เนลเพื่อหาจุดที่เกิดปัญหา แต่เพราะแพตช์ PCIE_65 ทำให้เคอร์เนลอยู่ในสถานะ tainted จึงยากต่อการตัดสินสาเหตุจริง
  • จึงติดตั้ง Nvidia RTX 2060 แทน AMD Radeon
    • หากใช้ไดรเวอร์เคอร์เนล nouveau ก็ยังต้องใช้แพตช์ PCIE_65 อยู่ดี
    • การใช้เคอร์เนล Fedora มาตรฐานร่วมกับไดรเวอร์ไบนารีของ Nvidia ทำงานได้ปกติ
    • การเร่งถอดรหัสวิดีโอและบางเกมที่ใช้ Wine ก็ทำงานได้
  • FreeCAD และ OrcaSlicer แครชทันทีหลังเปิด
    • สาเหตุคือในคลัง AArch64 Flatpak ไม่มี org.freedesktop.Platform.GL.nvidia
    • เครื่องมือสองตัวนี้เป็นแอปที่ใช้บ่อย จึงเป็นปัญหาหลักที่ทำให้การย้ายมาใช้เดสก์ท็อปนี้ทำได้ยาก

กลับสู่ x86-64 และบทบาทใหม่ของ Altra

  • สุดท้ายจึงบูต ระบบ x86-64 ที่ปิดทิ้งไว้ขึ้นมาอีกครั้ง
  • หลังย้ายสายจำนวนมากและจัดสายใหม่ ก็ใช้งานสองระบบร่วมกันใต้โต๊ะ
    • wooster: ระบบ Ampere Altra
    • puchatek: ระบบ Ryzen 5 3600
  • ประสบการณ์จาก 80 คอร์ไปเป็น 6 คอร์ 12 เธรดให้ความรู้สึกแปลก แต่การทำงานจริงยังดำเนินได้ตามปกติ
    • แม้ใช้ทุกเธรด เพลงก็ยังเล่นต่อได้
    • เล่นเกมทุกเกมในไลบรารี Steam ได้
    • ออกแบบเคสสำหรับโปรเจกต์ที่บ้านใน FreeCAD จนเสร็จได้
    • ทำโปรโตไทป์สำหรับพิมพ์ 3D ใน OrcaSlicer ได้ทันที
  • ระบบ Ampere Altra ยังเปิดไว้ต่อเพื่อจัดการ การบิลด์แพ็กเกจ RISC-V
  • ระบบนี้มีประสิทธิภาพเธรดเดี่ยวอ่อน แต่ทำงานได้เร็วภายใต้โหลดแบบหลายคอร์

จะไม่ทำเดสก์ท็อป AArch64 แบบเดิมซ้ำ

  • ไม่มีแผนจะทำการทดลองเดสก์ท็อปแบบเดียวกันด้วย Ampere Altra อีก
  • หากจะลองเดสก์ท็อป AArch64 อีกครั้ง จำเป็นต้องใช้ แพลตฟอร์มฮาร์ดแวร์ใหม่ทั้งหมด
  • ไม่มีแผนจะจ่ายเกิน 20,000 PLN เพื่อซื้อระบบ Nvidia DGX Spark

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 4 시간 전
ความคิดเห็นจาก Lobste.rs

  • พอเข้าใจความรู้สึกในสถานการณ์นี้อยู่บ้าง บน Raptor Talos II ของฉัน IBM ยังทำให้ PowerNV พังต่อเนื่อง
    ตอนแรกเป็น amdgpu และตอนนี้กลายเป็นการ์ด SATA ที่มีปัญหา เพราะ IBM คอยไปแตะ PCIe สำหรับระบบที่ไม่ใช่ bare metal อยู่เรื่อย ๆ เลยต้องติดอยู่กับเคอร์เนล 6.14

    • อยากรู้ว่าใช้ Linux ดิสโทร อะไรอยู่ เซิร์ฟเวอร์ที่บริษัทฉันรัน Ubuntu 26.04 พร้อมเคอร์เนล 7.0 และรองรับได้ดีมาก
      ฉันอยากได้สักเครื่องมาตั้งแต่ตอนเปิดตัว แต่ตอนนี้มันก็ผ่านมานานพอสมควรแล้ว และก็คิดว่าอาจมีรุ่น Power 11 ออกมาก็ได้

  • ฉันก็เจอคล้ายกัน พยายามรัน NixOS บน Thinkpad X13S และมันก็พอใช้ได้บ้าง แต่แม้แต่ตอนติดตั้งก็ต้องใช้ Ubuntu ISO
    เพราะหาภาพอิมเมจ NixOS แบบ aarch64 UEFI ที่บูตได้จริงไม่เจอ หลังอัปเกรดเป็นเคอร์เนลใหม่ การบูตก็พังไป และตอนนี้ฉันหมดแรงจะมานั่งทำให้ระบบใช้งานได้แล้ว
    Ubuntu เองก็พอมีการรองรับ X13S อยู่บ้าง แต่หลายอย่างที่บนเครื่อง x86_64 ทั่วไปควรใช้ได้ กลับใช้ไม่ได้เลย การพักเครื่องใช้ไม่ได้โดยสิ้นเชิง, TPM รองรับจำกัด, กราฟิกก็มีพฤติกรรมแปลก ๆ และน่าจะยังมีปัญหาอื่นที่ฉันยังไม่ได้ทดสอบอีก
    และนี่ก็ยังไม่รวมอุปกรณ์ ARM ที่บริษัทอย่าง Anbernic ให้มาแต่ภาพอิมเมจเก่า ๆ เช่นเครื่องเล่นอีมูเลชันแบบพกพา หรืออุปกรณ์อย่าง Clockwork uConsole ที่ใช้หรือฝืนใช้ฮาร์ดแวร์อย่างชาญฉลาดจนต้องพึ่งแพตช์เคอร์เนลนอกมาตรฐาน สุดท้ายซอฟต์แวร์พวกนี้ก็ไม่ได้เข้า upstream และกลายเป็นฮาร์ดแวร์ที่ผูกติดกับระบบปฏิบัติการที่อัปเดตไม่ได้
    ฉันใช้เวลาไปไม่น้อยกับคอมพิวเตอร์หลายเครื่องโดยหวังว่า ARM บน Linux จะทำงานได้ดี แต่ก็ตันหมด นอกจาก Raspberry Pi แล้วก็แทบไม่มีอะไรที่ "ใช้ได้เลย" และฉันก็รู้เรื่องฝั่งฮาร์ดแวร์/เคอร์เนลไม่มากพอจะทำการปรับปรุงที่มีความหมายได้

    • ฉันก็ซื้อ X13S มาเหมือนกัน เพราะขนาดกับน้ำหนักมันดูสมบูรณ์แบบมาก
      ฉันเสียเวลาไปหลายชั่วโมงกับการติดตั้ง NixOS แบบเดียวกัน สุดท้ายติดตั้งจาก Ubuntu แล้วพอทำให้มันใช้งานได้คร่าว ๆ แต่ระบบเปราะบางเกินไปจนแทบใช้จริงไม่ได้
      ฉันอยากให้มันเวิร์กมากจริง ๆ แต่ฝั่ง Linux ให้ความรู้สึกเหมือนโดนทิ้ง สุดท้ายเลยยอมแพ้แล้วไปรัน NixOS เป็น VM บน Apple MacBook Air แทน
    • ฉันก็มี X13s เหมือนกัน ดิสโทรเดียวที่ลองคือ Fedora แต่พอเริ่มตัวติดตั้งก็เกิดอาการ I/O ค้างเลย ไม่ดีเลย
      ไม่ได้ชอบ Ubuntu เป็นพิเศษอยู่แล้ว เลยไม่ได้พยายามลองดิสโทรอื่น ส่วน Windows ก็ยังทำงานได้ดีพอสมควร
      SoC รุ่นใหม่กว่านี้มีความแปลกประหลาดน้อยกว่ามาก เช่น ไม่ต้องใส่ kernel command line ยาวเป็นย่อหน้า แต่ X13s ก็ไม่มีรุ่น X Elite 2 ออกมา

  • สงสัยว่า แล็ปท็อป Nvidia RTX Spark รุ่นใหม่จะได้การรองรับ Linux อย่างเป็นทางการหรือไม่
    เพราะสุดท้ายแล้วมันก็แทบเป็นแพลตฟอร์มเดียวกับ DGX Spark ที่รันดิสโทรสาย Ubuntu และสัญญาณเท่าที่เห็นตอนนี้ก็ดูไม่ค่อยดีนัก

  • ถ้าจะเล่าประสบการณ์ฝั่งตรงข้าม ตอนนี้ฉันใช้ Radxa Rock5bPlus มาได้ราว 4 เดือนแล้ว เป็นรุ่นแรม 16GB พร้อม NVMe และใช้ mainline u-boot, Fedora Rawhide รุ่น EFI และ mainline kernel
    งานที่ Collabora ทำเพื่อดันการรองรับ rk3588 ขึ้น mainline นั้นเรียกได้ว่าน่าทึ่งจริง ๆ
    ยังมีบางอย่างที่ต้องรออยู่ เช่น HDMI 2.0 ขึ้นไป หรือ 4k@60 และ USB-C DP อะไรพวกนี้ ถึงอย่างนั้น ในแง่ฮาร์ดแวร์มันกลับดูมีความแปลกน้อยกว่า XPS 13 9370 ของฉันเสียอีก บนโน้ตบุ๊กเครื่องนั้นเสียงออกพังไปเฉย ๆ ตั้งแต่ราว ๆ 5.14
    https://dell.com/community/en/…
    https://gitlab.collabora.com/hardware-enablement/rockchip-3588/…

    • ฉันใช้ OrangePi 5 Plus และเห็นว่าตอนนี้ HDMI capture ถูก merge แล้ว
      ยังไม่มีการรองรับ HDCP แต่ก็ดูเหมือนถึงเวลาจะกลับไปลองเล่นกับงานทดลอง HDMI OSD แบบ low-latency 1080p ที่เคยทำไว้
      ตอนนั้นมันทำงานได้ด้วยดีเลย์ 3 เฟรม และตามทฤษฎีต่ำสุดคือ 2 เฟรม เราสามารถ overlay Chromium Embedded ทับสัญญาณ HDMI เพื่อเพิ่มความสามารถด้าน OSD ในชุดโฮมมีเดียได้มาก
      ปัญหาใหญ่สุดคือความไม่เสถียร และทั้งระบบก็มักทำให้เคอร์เนลของ OrangePi แครชเป็นประจำ

  • เรื่องนี้ดูเหมือนจะสะท้อน สถานะการรองรับฮาร์ดแวร์ของ Linux ในปัจจุบันได้ดีกว่า คือมีแค่ฮาร์ดแวร์ที่นิยมและทำเงินเท่านั้นที่ได้การรองรับในเคอร์เนล ส่วนสถานะของไดรเวอร์แบบไบนารีก็นรกมาตั้งแต่อดีตจนถึงตอนนี้
    น่าสนใจที่ผู้คนวิ่งตาม Linux เพื่อพยายามทำให้บางอย่างบนฮาร์ดแวร์ของตัวเองใช้งานได้ สุดท้ายก็ต้องติดอยู่กับเคอร์เนลเก่า หรือไม่ก็ต้องดูแลและ rebase แพตช์เอง แทนที่จะใช้ระบบปฏิบัติการที่รองรับฮาร์ดแวร์เก่าได้โดยไม่ต้องทำเรื่องพวกนี้

    • สำหรับฉัน มันฟังดูเหมือนยังพยายามหาวิธีทำให้ฮาร์ดแวร์ที่มีข้อบกพร่องนี้ทำงานกับ AMD GPU ให้ได้
      ข้อความคือ “ตาม errata ของผลิตภัณฑ์ตระกูล Altra, PCIE_65 อาจสร้างที่อยู่ผิดพลาดในการเขียน PCIe MMIO และส่งผลกับอุปกรณ์บางประเภท โดยเฉพาะ AMD GPU ดังนั้นผลิตภัณฑ์ตระกูล Altra โดยทั่วไปจึงไม่เข้ากันกับอุปกรณ์ประเภทนี้ มีการให้แพตช์ซอฟต์แวร์ proof-of-concept ภายใต้ GPL v2 เพื่อให้สามารถทำงานทดลองและพัฒนาต่อได้”
      ฉันก็เข้าใจว่าทำไมระบบปฏิบัติการถึงไม่อยากรับแพตช์ proof-of-concept แบบนี้
      มี Linux kernel fork จำนวนมากที่รองรับฮาร์ดแวร์เฉพาะบางชิ้น ซึ่งน่าเสียดาย เพราะ fork เหล่านี้มักมีคอมมิตที่ invasive หรือ experimental ซึ่งต้องทำงานเพิ่มอีกมากกว่าจะถูกรับเข้า mainline Linux kernel
      เลยสงสัยว่าระบบปฏิบัติการอื่นเดินเกมต่างจากนี้ไหม ถ้าจะทำให้การมีส่วนร่วมกับ upstream ง่ายขึ้น พร้อมกับยังคุมภาระการดูแลสถาปัตยกรรม, SoC และบอร์ดต่าง ๆ ให้อยู่ในระดับที่จัดการได้ พวกเขาทำกันอย่างไร

  • ถ้าอย่างนั้นก็ถือว่าช่วยประหยัดแรงที่ฉันกะจะลองไปแล้ว ถึงอย่างนั้นก็หวังว่าการระบุ จุดที่เจ็บปวด พวกนี้จะช่วยในระยะยาวได้

  • ฉันนึกว่ามีแต่ฉันที่ลำบาก เคยใช้สเปกคล้ายกันเป็น dev server และปัญหาส่วนใหญ่มาจาก Python dependency ที่มี native code
    จำได้ว่ามีแพ็กเกจสำหรับ optimization อยู่ไม่กี่ตัว แล้วก็ Matplotlib ด้วย ลองทั้ง pip ปกติและ uv แล้ว แต่สุดท้ายก็ต้องคอมไพล์จากซอร์ส สุดท้ายเลยย้ายกลับไป x86 เต็มตัว และพูดตามตรง ถึงจะมีคอร์เยอะขนาดนั้น ประสิทธิภาพก็ไม่ได้น่าทึ่งอะไรนัก

    • อยากรู้ว่า “ลองทั้ง pip และ uv แล้ว แต่สุดท้ายก็ต้องคอมไพล์จากซอร์ส” หมายถึงต้องออกไปนอก pip แล้วไป build แพ็กเกจด้วยตัวเองใช่ไหม

  • ถ้าต้องการ Linux เดสก์ท็อป ที่ใช้งานเล่นเกมได้จริง ก็ต้องมีการ์ด Nvidia และไดรเวอร์ไบนารี และควรหลีกเลี่ยงอะไรอย่าง Flatpak ที่เข้ากันได้ไม่ดีนัก
    มันเป็นแบบนี้มาหลายสิบปีแล้วไม่ว่าจะสถาปัตยกรรมไหน และถือว่าใกล้เคียงสามัญสำนึก

    • ฉันใช้ AMD GPU และเล่นเกมบน Linux ได้ดีมาก แถมปัญหาจุกจิกโดยรวมยังน้อยกว่าสมัย Nvidia กับก้อนไดรเวอร์ปิดซอร์สโง่ ๆ นั่นอีก
    • ถ้าไม่ได้มีความจำเป็นต้องใช้ของ Nvidia อย่าง Cuda กับงานอย่างอื่นจริง ๆ หลายปีมานี้ AMD คือ GPU ที่คนมักเลือกสำหรับเล่นเกมบน Linux
    • ไม่รู้ว่ากำลังพูดถึงอะไรอยู่ AMD GPU ใช้เล่นเกมได้ดี และอย่าง Steam ใน Flatpak ก็ใช้ได้ดีเช่นกัน
      สำหรับ Steam นั้น บน Flatpak จะใช้ Steam controller ไม่ได้ แต่ที่เหลือทำงานได้ไม่มีปัญหา
      ถ้าจะอ้างอะไรแบบนั้นก็ควรมีข้อมูลมาสนับสนุน ไม่ใช่แค่พูดว่า “เชื่อฉันสิ”
    • ถ้ามองช่วงไม่กี่ปีหลังแบบเทียบช่วงเวลาเดียวกัน Steam Deck ที่ใช้ AMD, มินิพีซีที่ใช้ AMD APU 5750GE และ Intel Arc B580 กลับให้ประสบการณ์ที่ดีกว่า NVIDIA 3090 จริง ๆ

  • ถ้าเป็น ชุดระบบที่ไวต่อแพตช์เคอร์เนล ขนาดนี้ ฉันคงไม่ใช้แพ็กเกจเคอร์เนลของดิสโทรเลย
    คง build และบูตเคอร์เนลเองนอกระบบแพ็กเกจ แล้วค่อยอัปเดตตามจังหวะของตัวเอง

  • ฉันตามอ่านกระแสของโพสต์นี้อยู่บ้าง และกลับรู้สึกแปลกใจมากกว่าว่ามันใช้งานมาได้นานขนาดนั้น
    มันดูเหมือนเป็นแนว "พยายามยัดให้พอใช้ได้" มาโดยตลอด และพอได้อ่านบทสรุปแบบนี้ก็ยังรู้สึกเสียดายอยู่ดี