Kết thúc thử nghiệm desktop AArch64
(marcin.juszkiewicz.com.pl)- Đã sử dụng thực tế desktop AArch64 dựa trên Ampere Altra trong khoảng 11 tháng, nhưng khi dùng một nền tảng dành cho máy chủ như desktop, gánh nặng về kernel, GPU và khả năng tương thích ứng dụng cứ tiếp tục tích tụ
- Hệ thống gồm Ampere Altra Q80-30 80 nhân 3.0GHz, RAM 128GB, AMD Radeon RX6700XT, ASRock Rack ALTRAD8UD-1L2T và Fedora 42–44; ngay từ đầu đây không phải là phần cứng dành cho desktop
- Việc dùng GPU AMD cần bản vá né lỗi erratum 82288 / PCIE_65, nên mỗi lần Fedora cập nhật kernel, hầu như tuần nào cũng phải tự build lại kernel
- Từ khoảng Linux 7.0, xuất hiện lỗi GPU AMD và hiện tượng rớt khung hình video; ngay cả sau khi chuyển sang Nvidia RTX 2060, FreeCAD và OrcaSlicer vẫn bị crash vì kho Flatpak AArch64 không có
org.freedesktop.Platform.GL.nvidia - Cuối cùng đã quay lại hệ thống x86-64 Ryzen 5 3600; Ampere Altra được giữ lại để build gói RISC-V thay vì làm desktop, và kết luận rằng một desktop AArch64 mới cần nền tảng phần cứng khác
Cấu hình dùng Altra dành cho máy chủ như desktop
- Sau khoảng 11 tháng sử dụng thực tế desktop AArch64, thử nghiệm đã kết thúc
- Cấu hình phần cứng cuối cùng như sau
- CPU: Ampere Altra Q80-30, 80 nhân 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
- Case: Endorfy 700 Air
- USB3: bộ điều khiển USB 3.2/10Gbps PCIe x4 không thương hiệu
- Bo mạch này là mainboard máy chủ, và bản thân hệ thống Altra cũng không phải sản phẩm được thiết kế cho desktop
- QVL của hệ thống Ampere Altra không bao gồm card GPU AMD Radeon; có thể làm cho chúng hoạt động, nhưng thường cần thêm công sức
- Bộ điều khiển USB 3.2 rời cung cấp nhiều thiết bị USB hơn so với hỗ trợ mặc định của mainboard và các cổng 10Gbps cho NVMe ngoài
- Toàn bộ hệ thống chạy trên Fedora 42–44, nhưng để sử dụng thực tế thì cần kernel tự build thay vì kernel Fedora mặc định
Gánh nặng bảo trì kernel do PCIE_65 tạo ra
- Bộ điều khiển PCI Express của Ampere Altra có vấn đề erratum 82288 / PCIE_65
- PCIE_65 có thể tạo địa chỉ sai trong thao tác ghi PCIe MMIO, đặc biệt ảnh hưởng đến một số loại thiết bị như GPU AMD
- Vấn đề có thể xảy ra khi driver kernel Linux ánh xạ vùng MMIO với thuộc tính bộ nhớ Normal, non-cacheable như
ioremap_wc- Mục đích có thể là để bật write combining hoặc truy cập không căn chỉnh
- Trong trường hợp này, hỏng dữ liệu có thể xảy ra trong outbound MMIO write của giao diện PCIe
- Cách né lỗi là ánh xạ dưới dạng bộ nhớ Device, non-gathering như
ioremapthay vìioremap_wc, đồng thời căn chỉnh nghiêm ngặt mọi thao tác bộ nhớ trên vùng PCIe MMIO
- Để dùng như một hệ thống Linux bình thường, mỗi lần gói kernel Fedora cập nhật đều phải build lại kernel, thường cần làm hằng tuần
- Sau khi cập nhật kho gói kernel Fedora cục bộ, kernel được build theo quy tắc phiên bản riêng như
7.0.2-200.fc44.pcie65.6pcie65biểu thị bản vá đã áp dụng- Con số cuối là bộ đếm số lần rebase bản vá
- Các bản vá được lấy từ kho GitHub, rebase và chỉnh sửa khi cần; kết quả là đôi khi dùng kernel mới hơn cả Fedora chính thức
80 nhân không bảo đảm trải nghiệm desktop nhanh
- Có 80 nhân CPU không đồng nghĩa với việc trở thành một máy desktop tốt
- Số nhân lớn không bảo đảm hiệu năng cảm nhận nhanh mà desktop cần
Vấn đề tương thích ứng dụng vẫn còn sau khi thay GPU
- AMD Radeon RX6700XT hoạt động với kernel đã áp dụng bản vá PCIE_65 out-of-tree, và cũng có thể chạy game cùng giải mã video có hỗ trợ phần cứng
- Từ một thời điểm nào đó quanh bản phát hành Linux 7.0, GPU AMD bắt đầu gặp lỗi
- Khi chạy game, log
amdgpu 0000:03:00.0: Fence fallback timer expired on ring vcn_dec_0lặp lại liên tục - Khi xem video YouTube, 720 trong số 750 khung hình bị rớt, gần như không thể sử dụng
- Khi chạy game, log
- Trong tình huống thông thường có thể bisect kernel để tìm điểm gây lỗi, nhưng do bản vá PCIE_65 khiến kernel ở trạng thái tainted nên khó xác định nguyên nhân thực sự
- Đã lắp Nvidia RTX 2060 thay cho AMD Radeon
- Nếu dùng driver kernel
nouveauthì vẫn cần bản vá PCIE_65 - Tổ hợp kernel Fedora mặc định và driver nhị phân Nvidia hoạt động bình thường
- Tăng tốc giải mã video và một số game chạy trên Wine cũng hoạt động
- Nếu dùng driver kernel
- FreeCAD và OrcaSlicer crash ngay sau khi khởi chạy
- Nguyên nhân là kho Flatpak AArch64 không có
org.freedesktop.Platform.GL.nvidia - Hai công cụ này là các ứng dụng được dùng thường xuyên, nên đây là vấn đề cốt lõi khiến việc chuyển sang desktop này trở nên khó khăn
- Nguyên nhân là kho Flatpak AArch64 không có
Quay lại x86-64 và vai trò mới của Altra
- Cuối cùng đã khởi động lại hệ thống x86-64 vốn đang tắt
- Sau khi chuyển nhiều dây cáp và bố trí thêm cáp mới, hai hệ thống được dùng cùng nhau dưới bàn làm việc
wooster: hệ thống Ampere Altrapuchatek: hệ thống Ryzen 5 3600
- Trải nghiệm chuyển từ 80 nhân sang 6 nhân 12 luồng khá lạ lẫm, nhưng công việc thực tế vẫn chạy bình thường
- Nhạc vẫn tiếp tục phát ngay cả khi dùng tất cả các luồng
- Có thể chơi mọi game trong thư viện Steam
- Có thể hoàn tất thiết kế vỏ cho dự án tại nhà bằng FreeCAD
- Có thể tạo ngay prototype cho in 3D trong OrcaSlicer
- Hệ thống Ampere Altra vẫn được bật để xử lý build gói RISC-V
- Hệ thống này có hiệu năng đơn luồng yếu, nhưng chạy nhanh với tải đa nhân
Không lặp lại desktop AArch64 theo cùng cách
- Không có kế hoạch lặp lại thử nghiệm desktop tương tự với Ampere Altra
- Nếu thử một desktop AArch64 khác, sẽ cần một nền tảng phần cứng hoàn toàn mới
- Không có kế hoạch chi hơn 20.000 PLN để mua hệ thống Nvidia DGX Spark
1 bình luận
Các bình luận trên Lobste.rs
Tôi cũng đồng cảm phần nào với tình huống này. Trên Raptor Talos II của tôi, IBM vẫn liên tục làm hỏng PowerNV
Ban đầu là amdgpu, giờ thì đến card SATA. Vì IBM cứ mày mò PCIe cho các hệ thống không phải bare-metal nên tôi bị kẹt ở kernel 6.14
Tôi đã muốn có một chiếc từ lúc ra mắt, nhưng giờ nó cũng khá cũ rồi, và tôi nghĩ biết đâu sẽ có phiên bản Power 11
Tôi cũng tương tự. Tôi đã thử chạy NixOS trên Thinkpad X13S, và nó hoạt động ở một mức nào đó, nhưng ngay từ khâu cài đặt đã phải dùng ISO Ubuntu
Vì tôi không tìm được image NixOS aarch64 UEFI nào boot đúng cách. Sau lần nâng cấp kernel mới nhất thì boot bị hỏng, và giờ tôi đã cạn năng lượng để chỉ làm cho hệ thống chạy được
Ubuntu cũng có hỗ trợ X13S ở một mức nhất định, nhưng khá nhiều thứ vốn hiển nhiên phải chạy trên một máy x86_64 truyền thống thì lại không chạy. Sleep hoàn toàn không hoạt động, hỗ trợ TPM bị hạn chế, đồ họa cũng hành xử kỳ lạ, và có lẽ còn nhiều vấn đề khác mà tôi chưa kiểm thử
Đó là còn chưa tính đến các thiết bị ARM chỉ cung cấp image cũ như handheld giả lập của các công ty như Anbernic, hoặc các thiết bị như Clockwork uConsole dùng phần cứng một cách khéo léo, hay lạm dụng nó, đến mức cần các bản vá kernel phi chuẩn. Rốt cuộc phần mềm như vậy không được đưa upstream, và phần cứng bị bỏ lại với một hệ điều hành không thể cập nhật
Tôi đã dành khá nhiều thời gian trên nhiều máy tính với hy vọng ARM sẽ hoạt động tốt trên Linux, nhưng vẫn bị mắc kẹt. Ngoài Raspberry Pi ra thì chẳng có gì “cứ thế là chạy”, và tôi cũng không hiểu đủ về phần cứng/kernel để tạo ra cải thiện có ý nghĩa
Tôi cũng mất hàng giờ cài NixOS theo cách tương tự, cài qua Ubuntu và làm cho nó tạm chạy, nhưng quá mong manh nên thực tế khó mà dùng tử tế được
Tôi thật sự mong nó chạy tốt, nhưng về phía Linux thì có cảm giác bị bỏ rơi, nên cuối cùng tôi bỏ cuộc và chuyển sang chạy NixOS trong máy ảo trên Apple MacBook Air
Tôi cũng không quá yêu thích Ubuntu nên không thử các bản phân phối khác, còn Windows thì vẫn chạy đủ tốt
Các SoC mới hơn có ít điểm kỳ quặc hơn nhiều. Ví dụ không cần nhập dòng lệnh kernel dài cả một đoạn văn. Nhưng không có phiên bản X Elite 2 của X13s
Tôi tò mò liệu các laptop Nvidia RTX Spark mới có được hỗ trợ Linux chính thức không
Dù sao thì đó gần như là cùng nền tảng với DGX Spark chạy một bản phân phối phái sinh từ Ubuntu, nhưng các dấu hiệu đến giờ trông không mấy khả quan
Nói về trải nghiệm ngược lại, tôi đã dùng Radxa Rock5bPlus khoảng 4 tháng. Cấu hình 16GB RAM và NVMe, dùng u-boot mainline, bản EFI của Fedora Rawhide, và kernel mainline
Công việc Collabora đã làm để đưa hỗ trợ rk3588 vào mainline thực sự đáng kinh ngạc
Vẫn còn vài thứ đang chờ. HDMI 2.0 trở lên, tức 4k@60, và những thứ như USB-C DP. Dù vậy, xét về phần cứng thì tôi thấy nó còn ít điểm kỳ quặc hơn XPS 13 9370 của tôi. Chiếc laptop đó từ khoảng 5.14 là audio output cứ thế ngừng hoạt động
https://dell.com/community/en/…
https://gitlab.collabora.com/hardware-enablement/rockchip-3588/…
Vẫn chưa có hỗ trợ HDCP, nhưng có vẻ đã đến lúc quay lại thử nghiệm HDMI OSD 1080p độ trễ thấp mà tôi từng làm
Nó từng chạy với độ trễ 3 frame, còn tối thiểu theo lý thuyết là 2 frame. Có thể overlay Chromium Embedded lên tín hiệu HDMI, giúp mở rộng đáng kể khả năng OSD trong cấu hình home media
Vấn đề lớn nhất là độ bất ổn; toàn bộ cấu hình làm kernel OrangePi crash định kỳ
Tôi nghĩ chuyện này cho thấy rõ hơn tình trạng hỗ trợ phần cứng của Linux hiện nay. Chỉ phần cứng phổ biến và có lợi nhuận mới được hỗ trợ trong kernel, còn tình trạng driver binary thì từ xưa đến nay vẫn là địa ngục
Thật thú vị khi thấy mọi người chạy theo Linux để cố làm thứ gì đó hoạt động trên phần cứng của mình, rồi cuối cùng bị kẹt ở kernel cũ, hoặc phải tự duy trì và rebase patch. Trong khi đó, họ có thể dùng một hệ điều hành hỗ trợ phần cứng cũ mà không cần làm những việc này
Nội dung là: “Theo errata của dòng Altra, PCIE_65 có thể tạo địa chỉ sai trong các lệnh ghi PCIe MMIO và ảnh hưởng đến một số loại thiết bị nhất định, đặc biệt là AMD GPU, nên dòng Altra nói chung không tương thích với các loại thiết bị đó. Để có thể tiến hành thử nghiệm và phát triển, chúng tôi đã cung cấp một bản vá phần mềm proof-of-concept theo GPL v2”
Tôi hiểu vì sao hệ điều hành không muốn nhận một bản vá chỉ mang tính proof-of-concept
Có rất nhiều fork kernel Linux để hỗ trợ các mảnh phần cứng cụ thể, và đó là điều đáng tiếc. Những fork này thường chứa các commit mang tính xâm lấn hoặc thử nghiệm, cần thêm nhiều công sức nữa mới được chấp nhận vào kernel Linux mainline
Tôi tò mò liệu các hệ điều hành khác có đi con đường khác ở đây không. Họ đang làm gì để vừa giúp việc đóng góp upstream dễ hơn, vừa khiến việc bảo trì kiến trúc, SoC và bo mạch trở nên khả thi
Vậy là tôi đỡ mất công thử. Dù vậy, tôi hy vọng việc xác định các điểm đau sẽ có ích về dài hạn
Tôi cứ tưởng chỉ mình tôi khổ sở. Tôi từng dùng cấu hình tương tự làm server phát triển, và phần lớn vấn đề đến từ các dependency Python có mã native
Tôi nhớ cả vài gói tối ưu hóa và Matplotlib nữa. Tôi đã thử cả pip thường lẫn uv, nhưng cuối cùng vẫn phải compile từ source. Rốt cuộc tôi quay hẳn về x86, và thành thật mà nói, dù nhiều core như vậy thì hiệu năng cũng không ấn tượng lắm
Nếu muốn một desktop Linux thực sự chạy được để chơi game, bạn cần card Nvidia và driver binary, đồng thời nên tránh những thứ như Flatpak nếu chúng không vận hành ăn khớp với nó
Điều này đã đúng hàng chục năm trên mọi kiến trúc, và tôi xem nó gần như là lẽ thường
Với Steam thì trong Flatpak không truy cập được Steam controller, nhưng ngoài chuyện đó ra thì chạy không vấn đề gì
Nếu muốn đưa ra một khẳng định như vậy thì nên có dữ liệu hỗ trợ, chứ không chỉ nói “tin tôi đi”
Với một cấu hình nhạy cảm với patch kernel như thế này thì có lẽ tôi sẽ không dùng gói kernel của bản phân phối nữa
Tôi sẽ tự build và boot kernel ngoài hệ thống package, rồi cập nhật theo nhịp của mình
Tôi đã theo dõi luồng bài này một chút, và thật ra tôi ngạc nhiên là nó đã chạy được lâu như vậy
Lúc nào trông cũng gần như kiểu “làm sao đó cho chạy được”, nên đọc kết cục này vẫn thấy tiếc