AArch64 डेस्कटॉप प्रयोग का अंत

 (marcin.juszkiewicz.com.pl)
1 पॉइंट द्वारा GN⁺ 5 시간 전 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • लगभग 11 महीनों तक Ampere Altra आधारित AArch64 डेस्कटॉप को असल काम में इस्तेमाल किया, लेकिन server platform को desktop की तरह चलाने से kernel, GPU और app compatibility का बोझ लगातार बढ़ता गया
  • सिस्टम में Ampere Altra Q80-30 80-core 3.0GHz, 128GB RAM, AMD Radeon RX6700XT, ASRock Rack ALTRAD8UD-1L2T, Fedora 42–44 का संयोजन था, और यह शुरू से ही desktop hardware नहीं था
  • AMD GPU इस्तेमाल करने के लिए erratum 82288 / PCIE_65 workaround patch चाहिए था, इसलिए Fedora kernel update के हर बार custom kernel को आम तौर पर हर हफ्ते फिर से build करना पड़ता था
  • Linux 7.0 के आसपास AMD GPU errors और video frame drops आने लगे, और Nvidia RTX 2060 पर जाने के बाद भी AArch64 Flatpak repository में org.freedesktop.Platform.GL.nvidia न होने से FreeCAD और OrcaSlicer crash होते रहे
  • आखिरकार x86-64 Ryzen 5 3600 सिस्टम पर वापस लौटना पड़ा; Ampere Altra को desktop के बजाय RISC-V package build के लिए रखा गया और निष्कर्ष निकला कि नए AArch64 desktop के लिए अलग hardware platform चाहिए

Server-grade Altra को desktop की तरह इस्तेमाल किया गया configuration

  • लगभग 11 महीनों तक AArch64 desktop को असल इस्तेमाल में रखने के बाद experiment खत्म किया गया
  • अंतिम hardware configuration इस प्रकार था
    • 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
    • motherboard: ASRock Rack ALTRAD8UD-1L2T
    • PSU: MSI MPG A850G 850W
    • case: Endorfy 700 Air
    • USB3: PCIe x4 no-name USB 3.2/10Gbps controller
  • यह board एक server motherboard है, और Altra system खुद भी desktop के लिए design किया गया product नहीं है
  • Ampere Altra system के QVL में AMD Radeon GPU cards शामिल नहीं हैं; उन्हें चलाया जा सकता है, लेकिन अक्सर extra work की जरूरत पड़ती है
  • अलग USB 3.2 controller, motherboard की default support से ज्यादा USB devices और external NVMe के लिए 10Gbps ports देता है
  • पूरा system Fedora 42–44 पर चलता था, लेकिन real-world use के लिए default Fedora kernel के बजाय custom-built kernel चाहिए था

PCIE_65 से बना kernel maintenance का बोझ

  • Ampere Altra के PCI Express controller में erratum 82288 / PCIE_65 issue है
  • PCIE_65 PCIe MMIO writes में गलत address बना सकता है, और खास तौर पर AMD GPU जैसे कुछ device types को प्रभावित करता है
  • जब Linux kernel driver ioremap_wc की तरह MMIO space को Normal, non-cacheable memory attributes के साथ map करता है, तब समस्या आ सकती है
    • इसका मकसद write combining या unaligned access को enable करना हो सकता है
    • इस स्थिति में PCIe interface के outbound MMIO write में data corruption हो सकता है
    • workaround यह है कि ioremap_wc के बजाय ioremap की तरह Device, non-gathering memory के रूप में map किया जाए, और PCIe MMIO space की सभी memory operations को सख्ती से align किया जाए
  • इसे एक normal Linux system की तरह इस्तेमाल करने के लिए Fedora kernel package update के हर बार kernel फिर से build करना पड़ता था, और आम तौर पर हर हफ्ते यह काम करना होता था
  • local Fedora kernel package repository update करने के बाद 7.0.2-200.fc44.pcie65.6 जैसे custom versioning rule के साथ build किया जाता था
    • pcie65 applied patch को दर्शाता था
    • आखिरी number patch rebase counter था
  • GitHub repository से patches लेकर उन्हें rebase किया और जरूरत पड़ने पर modify किया; नतीजतन कभी-कभी official Fedora से भी ज्यादा नया kernel इस्तेमाल हो रहा था

80 cores desktop की महसूस होने वाली performance की गारंटी नहीं देते

  • 80 CPU cores होने से वह अपने-आप अच्छा desktop machine नहीं बन जाता
  • ज्यादा core count desktop में जरूरी तेज perceived performance की guarantee नहीं देता था

GPU बदलने के बाद भी app compatibility issues बाकी रहे

  • AMD Radeon RX6700XT out-of-tree PCIE_65 patch लगे kernel पर चलता था, और games चलाना तथा hardware-assisted video decoding भी संभव था
  • Linux 7.0 release के आसपास किसी समय से AMD GPU fail होने लगा
    • game चलाते समय amdgpu 0000:03:00.0: Fence fallback timer expired on ring vcn_dec_0 log बार-बार आता था
    • YouTube video देखने में 750 frames में से 720 frames drop हो रहे थे, इसलिए वह practically unusable था
  • आम स्थिति में kernel को bisect करके issue point ढूंढा जाता, लेकिन PCIE_65 patch के कारण kernel tainted state में था, इसलिए असली वजह तय करना मुश्किल था
  • AMD Radeon की जगह Nvidia RTX 2060 लगाया गया
    • nouveau kernel driver इस्तेमाल करने के लिए अभी भी PCIE_65 patch चाहिए था
    • default Fedora kernel और Nvidia binary driver का combination ठीक से चला
    • video decoding acceleration और Wine-based कुछ games भी चले
  • FreeCAD और OrcaSlicer launch होते ही crash हो गए
    • वजह यह थी कि AArch64 Flatpak repository में org.freedesktop.Platform.GL.nvidia नहीं था
    • ये दोनों tools अक्सर इस्तेमाल होने वाले apps थे, इसलिए desktop transition को मुश्किल बनाने वाली core problem यही थी

x86-64 पर वापसी और Altra की नई भूमिका

  • आखिरकार बंद पड़े x86-64 system को फिर से boot किया गया
  • काफी cables इधर-उधर करने और नए cables लगाने के बाद, desk के नीचे दोनों systems साथ इस्तेमाल होने लगे
    • wooster: Ampere Altra system
    • puchatek: Ryzen 5 3600 system
  • 80 cores से 6 cores 12 threads पर जाना अजीब अनुभव था, लेकिन actual work ठीक से चलने लगा
    • सभी threads इस्तेमाल करने पर भी music playback जारी रहता है
    • Steam library के सभी games खेले जा सकते हैं
    • FreeCAD से home project case design पूरा किया जा सकता है
    • OrcaSlicer में सीधे 3D print के लिए prototype बनाया जा सकता है
  • Ampere Altra system को चालू रखकर RISC-V package builds संभाले जाते हैं
  • इस system की single-thread performance कमजोर है, लेकिन multicore load में यह तेज चलता है

इसी तरह का AArch64 desktop फिर नहीं दोहराया जाएगा

  • Ampere Altra के साथ वही desktop experiment दोहराने की कोई योजना नहीं है
  • एक और AArch64 desktop आजमाने के लिए पूरी तरह नया hardware platform चाहिए
  • Nvidia DGX Spark system खरीदने के लिए 20,000 PLN से ज्यादा खर्च करने की योजना नहीं है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 5 시간 전
Lobste.rs की रायें

  • इस स्थिति से कुछ हद तक सहमत हूं। मेरे Raptor Talos II पर IBM लगातार PowerNV को तोड़ रहा है
    शुरुआत में समस्या amdgpu थी, और अब SATA कार्ड समस्या है। IBM बेयर-मेटल न होने वाले सिस्टमों के लिए PCIe से लगातार छेड़छाड़ कर रहा है, इसलिए मैं 6.14 kernel पर अटका हुआ हूं

    • उत्सुकता है कि आप कौन-सा Linux distribution इस्तेमाल कर रहे हैं। कंपनी का server Ubuntu 26.04 पर 7.0 kernel के साथ चल रहा है, और support अच्छा है
      launch के समय से ही एक लेना चाहता था, लेकिन अब वह काफी पुराना हो चुका है, और लगता है शायद Power 11 version आ भी सकता है

  • मेरा अनुभव भी मिलता-जुलता था। Thinkpad X13S पर NixOS चलाने की कोशिश की, और कुछ हद तक चला भी, लेकिन installation के लिए Ubuntu ISO इस्तेमाल करना पड़ा
    क्योंकि ठीक से boot होने वाली aarch64 UEFI NixOS image नहीं मिल सकी। latest kernel upgrade के बाद boot टूट गया, और अब system को बस चलाते रहने में ऊर्जा खत्म हो गई है
    Ubuntu में भी X13S support कुछ हद तक है, लेकिन पारंपरिक x86_64 machine पर जो चीजें स्वाभाविक रूप से चलतीं, उनमें से काफी कुछ नहीं चलता। sleep बिल्कुल नहीं चलता, TPM support सीमित है, graphics भी अजीब तरह से behave करता है, और शायद और भी कई untested समस्याएं होंगी
    यह सब उन ARM devices को छोड़कर भी है जिनमें सिर्फ पुरानी images मिलती हैं, जैसे Anbernic जैसी कंपनियों के emulation handhelds, या Clockwork uConsole जैसे devices, जो hardware का चतुराई से इस्तेमाल या दुरुपयोग करते हैं और जिन्हें non-standard kernel patches चाहिए होते हैं। आखिरकार ऐसा software upstream में नहीं पहुंच पाता, और hardware एक ऐसे operating system के साथ रह जाता है जिसे update नहीं किया जा सकता
    Linux पर ARM ठीक से चले, इस उम्मीद में मैंने कई computers पर काफी समय लगाया, लेकिन अटका हुआ हूं। Raspberry Pi को छोड़ दें तो कुछ भी बस अपने-आप नहीं चलता था, और hardware/kernel side की मेरी समझ इतनी नहीं कि कोई meaningful improvement कर सकूं

    • मैंने भी X13S खरीदा था। उसका size और weight perfect लग रहे थे
      इसी तरह NixOS install करने में कई घंटे लगाए, Ubuntu से install करके किसी तरह चलाया भी, लेकिन वह इतना fragile था कि असल में ठीक से इस्तेमाल करना मुश्किल था
      मैं सच में चाहता था कि यह अच्छा चले, लेकिन Linux side पर छोड़ा हुआ सा लगा, और आखिरकार हार मानकर Apple MacBook Air पर VM में NixOS चलाने लगा
    • मेरे पास भी X13s है, और मैंने सिर्फ Fedora distribution आजमाया; installer शुरू करते ही I/O hang हो जाता है। अच्छा नहीं है
      Ubuntu से भी कोई खास लगाव नहीं है, इसलिए दूसरी distributions आजमाने की जहमत नहीं उठाई, और Windows फिर भी पर्याप्त ठीक चलता है
      नए SoC में quirks बहुत कम हैं। उदाहरण के लिए, kernel command line को एक paragraph जितना लंबा डालने की जरूरत नहीं पड़ती। लेकिन X13s का X Elite 2 version नहीं आया

  • उत्सुकता है कि नए Nvidia RTX Spark laptops को official Linux support मिलेगा या नहीं
    आखिरकार वे DGX Spark जैसे ही platform पर हैं, जो Ubuntu derivative distribution चलाता है, लेकिन अब तक के संकेत बहुत अच्छे नहीं लगते

  • उलटा अनुभव बताऊं तो, मैं Radxa Rock5bPlus करीब 4 महीने से इस्तेमाल कर रहा हूं। 16GB memory और NVMe configuration है, और mainline u-boot, Fedora Rawhide का EFI version, तथा mainline kernel इस्तेमाल कर रहा हूं
    rk3588 support को mainline में लाने के लिए Collabora ने जो काम किया है, वह सच में हैरान करने वाला है
    अभी कुछ चीजों का इंतजार है। HDMI 2.0 या उससे ऊपर, यानी 4k@60, और USB-C DP जैसी चीजें। फिर भी hardware के लिहाज से इसमें मेरे XPS 13 9370 से उलटे कम quirks लगते हैं। उस laptop में 5.14 के आसपास से audio output बस बंद हो गया था
    https://dell.com/community/en/…
    https://gitlab.collabora.com/hardware-enablement/rockchip-3588/…

    • मैं OrangePi 5 Plus इस्तेमाल कर रहा हूं, और देखा कि HDMI capture अब merge हो गया है
      अभी HDCP support नहीं है, लेकिन लगता है अब अपने पुराने low-latency 1080p HDMI OSD experiment पर लौटने का समय आ गया है
      वह 3-frame delay पर चलता था, और theory में minimum 2 frames है। HDMI signal के ऊपर Chromium Embedded overlay करके home media setup में OSD capability काफी बढ़ाई जा सकती थी
      सबसे बड़ी समस्या instability थी, और पूरा setup OrangePi kernel को नियमित रूप से crash कर देता था

  • यह अभी Linux hardware support की स्थिति को बेहतर दिखाता लगता है। सिर्फ popular और profitable hardware को ही kernel support मिलता है, और binary drivers की हालत पहले से अब तक लगातार नरक जैसी रही है
    दिलचस्प है कि लोग अपने hardware पर कुछ चलाने के लिए Linux के पीछे भागते हैं और आखिर में पुराने kernel पर अटक जाते हैं, या patches खुद maintain और rebase करने पड़ते हैं। जबकि वे ऐसा काम किए बिना पुराने hardware को support करने वाला operating system इस्तेमाल कर सकते थे

    • मुझे तो यह ऐसा लगता है जैसे वे अभी भी इस flawed hardware को AMD GPU के साथ ठीक से चलाने का तरीका खोज रहे हैं
      “Altra product family errata के अनुसार, PCIE_65 PCIe MMIO writes में गलत address generate कर सकता है और कुछ device types, खासकर AMD GPU, को प्रभावित करता है, इसलिए Altra product family आम तौर पर ऐसे device types के साथ compatible नहीं है। experimentation और development work आगे बढ़ाने के लिए GPL v2 के तहत proof-of-concept software patch उपलब्ध कराया गया” — बात यह है
      समझ आता है कि कोई operating system सिर्फ proof-of-concept patch को accept क्यों नहीं करना चाहेगा
      खास hardware pieces को support करने वाले Linux kernel forks बहुत ज्यादा हैं, और यह दुखद है। ऐसे forks में अक्सर invasive या experimental commits होते हैं जिन्हें mainline Linux kernel में accept होने के लिए और काम चाहिए
      उत्सुकता है कि दूसरे operating systems यहां कोई अलग रास्ता अपना रहे हैं या नहीं। upstream contributions को आसान बनाते हुए architecture, SoC और board maintenance को manageable रखने के लिए वे क्या कर रहे होंगे

  • तो फिर जिसे आजमाने की सोच रहा था, उसकी मेहनत बच गई। फिर भी उम्मीद है कि pain points समझना लंबे समय में मददगार होगा

  • मुझे लगा था सिर्फ मैं ही जूझ रहा हूं। development server के तौर पर मिलते-जुलते specs इस्तेमाल किए, और ज्यादातर समस्याएं native code वाली Python dependencies से आईं
    कुछ optimization packages और Matplotlib भी याद हैं। normal pip और uv दोनों आजमाए, लेकिन आखिरकार source से compile करना पड़ा। अंत में पूरी तरह x86 पर लौट गया, और सच कहूं तो इतने cores होने के बावजूद performance बहुत शानदार नहीं थी

    • “pip और uv दोनों आजमाए, लेकिन आखिरकार source से compile करना पड़ा” से आपका मतलब है कि pip से बाहर जाकर packages खुद build करने पड़े?

  • अगर gaming के लिए सच में चलने वाला Linux desktop चाहिए, तो Nvidia card और binary driver चाहिए, और Flatpak जैसी चीजों से बचना चाहिए जो उसके साथ सही से काम नहीं कर पातीं
    यह किसी भी architecture पर दशकों से ऐसा ही रहा है, और मुझे तो यह common sense जैसा लगता है

    • मैं AMD GPU इस्तेमाल करता हूं और Linux पर gaming बहुत अच्छी चलती है। ऊपर से पुराने Nvidia और उसके मूर्खतापूर्ण closed driver blob की तुलना में कुल मिलाकर छोटे-मोटे issues भी कम हैं
    • अगर किसी और use case के लिए Cuda जैसे Nvidia की जरूरत नहीं है, तो Linux gaming में पिछले कुछ सालों से AMD preferred GPU रहा है
    • समझ नहीं आ रहा आप क्या कह रहे हैं। AMD GPU gaming के लिए अच्छा चलता है, और उदाहरण के लिए Flatpak के अंदर Steam भी ठीक चलता है
      Steam के मामले में Flatpak में Steam controller access नहीं मिलता, लेकिन उसके अलावा बिना समस्या चलता है
      ऐसा दावा करना है तो “मुझ पर भरोसा करो” के बजाय कुछ supporting data तो लाना चाहिए
    • हाल के वर्षों में उसी अवधि को देखें तो, AMD-based Steam Deck, AMD APU 5750GE वाले mini PC, और Intel Arc B580 ने NVIDIA 3090 से असल में बेहतर experience दिया

  • ऐसी kernel patches पर sensitive configuration हो तो मैं distribution के kernel packages बिल्कुल इस्तेमाल नहीं करूंगा
    package system के बाहर खुद kernel build करके boot करूंगा, और अपनी speed से update करूंगा

  • मैं इस thread को थोड़ा follow कर रहा था, और उलटे यह देखकर हैरानी हुई कि यह इतने लंबे समय तक चला
    हमेशा “किसी तरह चलवा लो” जैसा लगता था, फिर भी ऐसा अंत पढ़कर अफसोस हुआ