Apple M1/M2 GPU ड्राइवर OpenGL 4.6 और Vulkan 1.3 तक आगे बढ़ा

 (lwn.net)
1 पॉइंट द्वारा GN⁺ 2024-11-01 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Apple M1/M2 GPU के लिए kernel graphics driver की खासियत Rust आधारित होना है, और अब इसने OpenGL 4.6 व Vulkan 1.3 conformance हासिल कर standards support का दायरा बढ़ा दिया है
  • OpenGL 4.0 का core हिस्सा tessellation Apple GPU hardware capabilities के सहारे standard पूरा करना कठिन बनाता है, इसलिए Microsoft reference tessellator को OpenCL C में port कर GPU पर चलाने के तरीके से इसे संभाला गया
  • M2 Mac पर Vulkan demo में OpenCL आधारित tessellation ने 265fps दर्ज किया, जो software-only implementation के 1fps से कम की तुलना में काफी तेज है, लेकिन hardware tessellator के 820fps से पीछे है
  • AAA games चलाने के लिए DirectX·Windows·x86·4KB page environment को Linux·Arm64·16KB page आधारित Apple Silicon के अनुरूप बनाना पड़ता है, और इसके लिए कई translation layers और virtual machine configurations साथ में इस्तेमाल होते हैं
  • Portal, The Witcher 3, Cyberpunk 2077 जैसे games सचमुच चले, लेकिन memory requirements और ray tracing support का दायरा अब भी अहम constraints बने हुए हैं

OpenGL 4.6 तक पहुँचा Apple GPU driver

  • Apple M1/M2 GPU के लिए kernel graphics driver Rust में लिखा गया है, और इसने कई graphics standards के लिए conformance हासिल किया है
  • Alyssa Rosenzweig ने X.Org Developers Conference 2024 में driver की स्थिति और supported games पर update दिया
    • presentation material YouTube video और slides के रूप में सार्वजनिक किया गया
  • पिछले वर्ष के XDC में driver ने OpenGL ES 3.1 conformance हासिल किया था, और बाद में OpenGL 4.6 conformance तक पहुँच गया
  • OpenGL 4.0 के लिए जरूरी tessellation) scene की detail को dynamically बढ़ाने या घटाने की technique है

Apple GPU hardware tessellator की सीमाएँ

  • Apple GPU में hardware tessellator है, लेकिन OpenGL standard implementation के लिए जरूरी capabilities मौजूद नहीं हैं, इसलिए driver उसे जस का तस इस्तेमाल नहीं कर सकता
  • hardware point mode और isoline support नहीं करता प्रतीत होता है, और ये दोनों features emulate किए जा सकते हैं
  • बड़ी समस्या transform feedback और geometry shader है
    • hardware दोनों को support नहीं करता
    • driver इन्हें compute shader से emulate करता है
    • hardware tessellator और emulation के tessellation algorithms में अंतर invariance failure पैदा कर सकता है, इसलिए इस combination से बचना चाहिए
  • Apple OpenGL 4.1 support करता है, लेकिन conformance नहीं रखता, और hardware द्वारा unsupported features को software से replace करता है
  • Rosenzweig ने कहा कि वे Metal implement नहीं कर रहीं, इसलिए उस तरीके से नहीं जाएँगी

OpenCL C में port किया गया reference tessellator

  • driver Microsoft द्वारा 10 साल से अधिक पहले public किए गए reference tessellator का उपयोग करता है
    • यह मूल रूप से hardware vendors को tessellation अपनाते समय implement किए जाने वाले behavior को दिखाने के लिए code था
    • यह लगभग 2000 lines का C++ code है, और एक single patch को tessellate करता है
  • GPU driver में 2000 lines का C++ जस का तस execute नहीं किया जा सकता, इसलिए इस code को OpenCL C में port किया गया
    • OpenCL C सामान्य CPU C से लगभग मिलता-जुलता है, लेकिन इसमें GPU के लिए restrictions और extensions होते हैं
    • लक्ष्य code को पूरी तरह समझना नहीं, बल्कि porting के दौरान behavior को न तोड़ना है
  • CPU tessellator एक बार में केवल एक patch process करता है, लेकिन scene में 10,000 patches हो सकते हैं
    • GPU की बड़े पैमाने की parallelism का उपयोग कर कई threads tessellation करते हैं
    • parallel processing के दौरान output buffer allocation GPU atomic instructions से manage किया जाता है
  • tessellator output को GPU द्वारा अपेक्षित packed data structure format की draw commands से draw करना होता है
    • आम तौर पर C driver code में GenXML tool द्वारा generated functions इसे handle करते हैं
    • tessellator OpenCL की वजह से C code form में है, इसलिए generated functions को GPU पर चलने वाले code में शामिल किया जा सकता है

Tessellation performance

  • OpenCL आधारित tessellation का उपयोग M2 Mac पर Vulkan demo के terrain tessellation को चलाने के लिए किया गया
  • performance comparison इस प्रकार है
    • software-only terrain tessellation: 1fps से कम
    • OpenCL आधारित tessellation: 265fps
    • hardware tessellator जोड़कर मापा गया आंकड़ा: 820fps
  • Rosenzweig ने OpenCL approach की performance को “ठीक” बताया, और माना कि real games में इसके bottleneck बनने की संभावना कम है
  • driver performance में अभी सुधार की गुंजाइश है

Vulkan 1.3 और Honeykrisp

  • Honeykrisp M1/M2 GPU driver ने Vulkan 1.3 conformance हासिल किया
  • शुरुआती point NVK Vulkan driver for NVIDIA GPUs को copy कर OpenGL 4.6 driver के साथ जोड़ने वाला रूप था
    • करीब एक महीने में यह conformance test suite pass करना शुरू कर गया
    • वह समय presentation के आधार पर 6 महीने पहले था
  • इसके बाद निम्न features जोड़े गए
    • geometry shader
    • tessellation shader
    • transform feedback
    • shader object
  • मौजूदा driver कई DirectX versions के लिए जरूरी सभी features support करता है

AAA games चलाने के लिए translation layers

  • Apple Silicon environment में AAA games चलाने के लिए कई environment differences को साथ-साथ संभालना पड़ता है
    • game target environment: DirectX, Windows, x86 CPU, 4KB pages
    • वास्तविक target hardware: Linux, Arm64, 16KB pages आधारित Apple Silicon
  • DirectX से Vulkan में translation और Windows से Linux पर execution को क्रमशः DXVK और Wine संभालते हैं
  • x86 से Arm64 में translation के लिए FEX-Emu या Box64 जैसे existing options हैं
  • सबसे बड़ी अड़चन page size difference है
    • FEX-Emu को 4KB pages चाहिए
    • Box64 में 16KB pages इस्तेमाल करने वाला hack है, लेकिन यह Wine में काम नहीं करता, इसलिए यहाँ मददगार नहीं है
    • macOS x86 emulation के लिए 4KB pages इस्तेमाल कर सकता है, लेकिन इसके लिए बहुत intrusive kernel support चाहिए
    • Asahi Linux के पास mainline kernel में जाने वाले लगभग 1000 patches पहले से हैं, इसलिए Linux memory manager को फिर से लिखने वाला approach reasonable नहीं है

4KB guest kernel VM configuration

  • Linux अलग-अलग processes के बीच heterogeneous page sizes support नहीं करता, लेकिन अलग-अलग kernels के बीच यह संभव है, और इसे virtualization से handle किया जाता है
  • KVM guest kernel host kernel से अलग page size रख सकता है
  • FEX-Emu, Wine, DXVK, Honeykrisp, Steam और पूरे game को 4KB guest kernel चलाने वाली virtual machine में डालने वाला structure इस्तेमाल होता है
  • CPU overhead hardware virtualization की वजह से कम होने की उम्मीद थी, और असली burden peripherals side पर है
  • Honeykrisp host kernel में नहीं, बल्कि guest में virtgpu native contexts के जरिए चलता है
    • final GPU command buffer बनाने का काम guest में किया जाता है
    • हर Vulkan call के virtual machine boundary पार करने के बजाय, completed command buffer host को दिया जाता है
    • host का VirGL renderer इसे GPU को pass करता है
  • Rosenzweig ने कहा कि यह तरीका 100% native speed नहीं है, लेकिन 90% से निश्चित रूप से ऊपर है
  • CPU और GPU overhead parallel में चलते हैं, इसलिए उनकी cost एक-दूसरे में जुड़ती नहीं है

वास्तव में चले games और public status

  • इस configuration ने वास्तव में कई games चलाए
  • संबंधित components presentation के दिन यानी 10 अक्टूबर को public किए गए
  • Fedora Asahi Remix users तुरंत update कर ये components पा सकते हैं
  • presentation के दौरान Steam चलने में virtual machine और x86 emulation की वजह से समय लगा, और बाद में Control M1 MAX system पर 45fps पर चला

Memory और ray tracing constraints

  • 8GB RAM वाले Mac पर भी कुछ games चल सकते हैं
    • Rosenzweig ने conference के दौरान 8GB system पर Castle Crashers खेला
    • Portal भी 8GB system पर चलता है
  • advanced game titles के 16GB या अधिक वाले systems पर ही चलने की संभावना ज्यादा है
  • Rosenzweig ने उम्मीद जताई कि समय के साथ आवश्यक resources कम होंगे
  • ray tracing support high priority नहीं है
    • Control इस feature का उपयोग कर सकता है
    • Apple hardware M3 से ही ray tracing support करता है
    • मौजूदा driver M1 और M2 GPU के लिए है
    • Rosenzweig जल्द ही M3 पर काम शुरू करने की योजना रखती हैं

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

1 टिप्पणियां

 
GN⁺ 2024-11-01
Hacker News की रायें

  • M1/M2 सपोर्ट को आखिर तक पूरा करने की प्रतिबद्धता सच में काबिले-तारीफ है
    चमकदार नए ray tracing खिलौने के आते ही बहुत सारे project छोड़ दिए जाते हैं, जबकि ऐसा काम कम documentation वाले hardware की वजह से तकलीफदेह होता है, लेकिन जब यह चल पड़ता है तो उसका reward बड़ा होता है
    मैंने अपना M1 भी इसी project और Alyssa के OpenGL+ES काम की वजह से खरीदा था, और सिर्फ Asahi Linux ही boot करता हूं

    • M4 MacBook announcement के comments में यह बात ध्यान देने लायक थी कि बहुत से लोग अपने M1 laptop से संतुष्ट हैं, और कई लोग MacBook को लगभग 10-10 साल तक इस्तेमाल करते हैं
      ऐसे devices लंबे समय तक चलने के लिए बने हैं, और Apple खुद तथा Linux community का long-term support सराहनीय है
      Open source होने के कारण Apple भी इसे देख रहा हो सकता है, और लेख में chip में missing features को workaround करने का काम भी शामिल था
    • “जब यह चल पड़ता है तो reward” वाली बात से सहमत हूं
      20 साल से ज्यादा coding की है, लेकिन career के सबसे खुश और सबसे उदास पल, दोनों एक hardware project से आए जिसमें मैं सिर्फ 4 महीने शामिल था
    • लेख में भी कहा गया था, “ईमानदारी से कहूं तो ray tracing मुझे थोड़ी gimmick feature लगती है,” और नए खिलौने के आते ही project छोड़ दिए जाने वाली बात के साथ, मैं दोनों से पूरी तरह सहमत हूं

  • 4KB और 16KB page size के फर्क को हल करने के लिए सब कुछ virtual machine में चलाने का Alyssa का तरीका clever hack भी लगता है और संभावित performance bottleneck भी
    सोच रहा हूं कि ऐसे workaround का long-term मतलब क्या होगा
    क्या हम उस बिंदु पर पहुंच गए हैं जहां closed ecosystem के लिए design किए गए proprietary hardware की खाई पाटने की complexity, फायदे से ज्यादा हो रही है
    M1 MAX पर open source driver से Control का 45fps पर चलना उत्साहजनक है, लेकिन सवाल है कि community को बंद systems को और खोलने के लिए लगातार बड़े resources लगाने चाहिए, या ज्यादा open hardware standards को आगे बढ़ाना चाहिए
    Apple tessellation shader जैसी standard features को मुश्किल बनाने वाली GPU limitations और non-standard page size से developers के लिए अनावश्यक बाधाएं बना रहा है, और ऐसा closed ecosystem न सिर्फ open source contributors को थकाता है बल्कि उन innovations को भी दबाता है जिनसे सभी users को फायदा हो सकता है

    • Apple अपने मकसद के हिसाब से, और सिर्फ अपने मकसद के हिसाब से, hardware design करता है
      यह साफ है कि इससे उसका closed business model टिकता है, और असल में Apple के लिए यह बहुत अच्छी तरह काम करता है
      वह बेहतरीन hardware बनाता है, और हाल में software कुछ अस्थिर होने के बावजूद आम users को hardware और software के combination से आम तौर पर अच्छा अनुभव मिलता है
      इसलिए Apple जिस तरह अभी hardware design करता है, उसे developers के लिए “अनावश्यक बाधाएं” रखना नहीं कहा जा सकता; वह बस अपनी जरूरतों के हिसाब से hardware design पर focus कर रहा है
      ऊपर से, अगर hardware शानदार न होता, तो Apple की मंशा से अलग तरीके से उसे इस्तेमाल करने में इतनी दिलचस्पी भी नहीं होती
    • सच में जानना चाहता हूं कि उन barriers की कोई technical justification है या नहीं
      standards को नजरअंदाज करके बेहतर पहिया दोबारा बनाना, और compatibility रोकने के लिए जानबूझकर standard से हटना—इन दोनों में काफी बड़ा फर्क है
      मुख्य बात यह है कि क्या वे standard behavior बनाए रखने पर resources नहीं लगा रहे, या standard से हटने के लिए सक्रिय रूप से resources लगा रहे हैं; अगर पहला मामला है तो निजी तौर पर मुझे उन्हें दोष देने वाली बात नहीं लगती
    • शुरुआती announcement में Alyssa ने virtual machine के memory overhead को वजह बताया था कि ज्यादातर Windows games को emulate करने के लिए minimum requirement 16GB RAM क्यों हो जाती है
    • Apple के नजरिए से देखें तो motivated developers मुश्किल काम उनकी जगह कर रहे हैं
      इस ecosystem में Apple की मुख्य चिंता native app compatibility और उससे मिलते-जुलते स्तर का AI inference experience होगी, और लगता है दोनों कभी-कभी संयुक्त प्रयासों से सुलझ जाते हैं
      बाकी मामलों में वह जितना हो सके lock down करना पसंद करता है, और community दुर्भाग्य से अच्छे open initiatives की तुलना में overall appeal की तरफ ज्यादा खिंचती है
    • “closed systems को और खोलना या open hardware standards को आगे बढ़ाना” एक false dichotomy है
      दोनों किए जा सकते हैं

  • पहले मैं कहने वाला था कि Alyssa को Valve में काम करते हुए Mac के Linux पर Steam चलाने में मदद करनी चाहिए, लेकिन लगता है वह पहले से ही ऐसा कर रही हैं [1]
    [1] https://en.wikipedia.org/wiki/Alyssa_Rosenzweig#Career

    • अच्छा है
      इससे यह काफी दिलचस्प सवाल उठता है कि Valve यहां क्या plan कर रहा है
      मुश्किल होगा, लेकिन Mac पर Steam/Proton चलाना Valve के लिए बहुत समझदारी की बात है, और अगर लोग game खेलने के लिए Mac पर Linux boot करने लगें तो Apple शायद काफी चिढ़ेगा

  • Alyssa R और Asahi Lina का काम शानदार है
    हालांकि अगर driver code से परिचित न हों तो इस content का ज्यादातर हिस्सा सच में बहुत कठिन है, और hardware side पर बहुत सी चीजें इतनी अजीब हैं कि काश ऐसा code लिखना कहीं ज्यादा आसान होता
    witch costume जैसी old-school वाली शरारत भी काफी मजेदार लगी

    • हाल की presentation देखते हुए लगा जैसे वे wand हिलाकर slides आगे बढ़ा रही थीं
      सोच रहा हूं कि क्या ऐसा करने वाला कोई जाना-पहचाना hardware है
      search किया, लेकिन PowerPoint से जुड़े blog spam के बीच मनचाहा result ढूंढना मुश्किल था, और Google की AI भी मददगार नहीं रही
    • ये लोग जो काम कर रहे हैं वह लगभग जादू से बस थोड़ा ही कम है, इसलिए शायद वह costume न भी हो

  • क्या और किसी को यह देखकर हैरानी हुई कि hardware में इतनी सारी चीजें missing हैं, और इतनी ज्यादा चीजें emulate होती हैं

    • आधुनिक GPU की graphics pipeline मोटे तौर पर बड़े पैमाने की parallel CUDA जैसी compute architecture के ऊपर एक पतली low-level Vulkan/Metal जैसी layer होती है
      असल में लगभग सब कुछ emulation माना जा सकता है
      GPU manufacturers drivers को open source में release नहीं करना चाहते, इसकी एक वजह यह भी है कि secret sauce का बड़ा हिस्सा बड़े पैमाने की parallel compute architecture के ऊपर driver software में होता है
    • जो चीजें emulate होती हैं वे ज्यादातर modern software में बहुत कम या बिल्कुल इस्तेमाल न होने वाली legacy features हैं, इसलिए backward compatibility के लिए emulation overhead घातक नहीं है
      geometry shader को व्यापक रूप से ऐसी गलती माना जाता है जिसे शुरू से standardize नहीं किया जाना चाहिए था, और Metal ने कभी इसे support भी नहीं किया, इसलिए यह macOS के पुराने OpenGL code में ही दिख सकता है; ऐसे में Apple को इसे hardware में support न करने के लिए दोष देना मुश्किल है
      https://x.com/pointinpolygon/status/1270695113967181827
    • पता नहीं यह दूसरे mobile-derived GPUs से सच में इतना अलग है या नहीं

  • Alyssa कमाल की हैं
    मुझे GPU काम पर उनका पहला लेख याद है, और उसके बाद जब पता चला कि वह सिर्फ 17 साल की हैं, तो दिमाग चकरा गया था
    किसी का भी ऐसा काम कर पाना अपने-आप में हैरान करने वाला है, और किसी किशोर का यह कर दिखाना तो सचमुच चौंकाने वाला है

  • अगर latest OpenGL और Vulkan को Apple Silicon पर लाना वैसे भी emulation layer के बिना संभव नहीं है, तो क्या सैद्धांतिक रूप से Linux के लिए native Metal API बनाया जा सकता है
    या Metal macOS SDK में बहुत गहराई तक धंसा हुआ है
    MoltenVK भी वही समस्या हल करने की कोशिश कर रहा है, जिसके बारे में Alyssa ने अपनी presentation में बात की थी [1, issue की आखिरी comment Alyssa की है]
    [1] https://github.com/KhronosGroup/MoltenVK/issues/1524

    • Apple को macOS में Vulkan को native तौर पर support करने से रोकने वाली कोई चीज नहीं है
      असल में Alyssa Rosenzweig की presentation का निष्कर्ष यही था
      Apple internal documents जानता है, इसलिए बेहतर low-level implementation बनाने की सबसे अच्छी स्थिति में वही है
      अभी मुख्य बाधा यह जिद्दी रुख है कि Metal porting ही आधिकारिक support path है
      अगर Valve, Apple के support के बिना Mac पर AAA games चलाने का कोई जादुई तरीका निकाल लेता है, तो खेल दिलचस्प हो जाएगा, और अगर Apple अपने ही platform पर घिरना नहीं चाहता तो उसे अपना approach फिर से सोचने पर मजबूर कर सकता है
    • ऐसा न होने की कोई वजह नहीं दिखती
      Linux के लिए DirectX implementation भी है, और Proton भी इसी तरह काम करता है
      बस सवाल यह है कि उस API को Vulkan के ऊपर एक layer बनाया जाए, MoltenVK या dxvk की तरह पूरी तरह client side पर handle किया जाए, या Mesa में ज्यादा गहराई से integrate किया जाए
      शुरुआत के लिए पहला विकल्प निश्चित रूप से आसान लगता है

  • ऐसे title वाले लेख देखकर अब मुझे “support बंद कर दिया जाएगा और acqui-hire हो जाएंगे” जैसी बात की उम्मीद करने की आदत पड़ गई है

  • Alyssa Rosenzweig Turing Award पाने की हकदार हैं

  • ऐसे /SubscriberLink/ links को लेकर मैं हमेशा सोचता रहा हूं
    क्या इन्हें share करना unethical है

    • LWN FAQ में लिखा है कि subscriber links को लगभग कहीं भी पोस्ट किया जा सकता है
      निजी mail, project mailing list messages, blog posts—सब ठीक हैं, और वे चाहते हैं कि इन्हें share किया जाए, बशर्ते इन्हें subscribers जुटाने की कोशिश को bypass करने के तरीके के रूप में इस्तेमाल न किया जाए
    • LWN से जुड़े लोगों ने पहले यहां कहा था कि इन्हें share करना ठीक है
      हालांकि उन्होंने विनम्रता से कहा था कि इन्हें बहुत ज्यादा न फैलाएं, क्योंकि site, authors और editors को चलाना होता है, और जहां तक मैं समझता हूं, उसका funding source subscriptions ही हैं
      LWN subscription fee काफी affordable है, और Linux व संबंधित topics पर सबसे अच्छी in-depth technical reporting को support करती है
      मेरा LWN से कोई संबंध नहीं है, बस एक संतुष्ट subscriber हूं, और मुझे लगता है कि LWN articles से मिली जानकारी ने मेरे career success में भी कुछ योगदान दिया है
    • HN नियमित रूप से LWN site पर भारी traffic भेजता है, यह बात LWN को भी काफी खुशी देती होगी
      लोगों को subscribe करने के लिए पहले LWN के अस्तित्व के बारे में पता होना जरूरी है
    • ऐसे links का मकसद sharing ही है
      FAQ देखें: https://lwn.net/op/FAQ.lwn#slinks
      LWN का paywall अलग तरह का है, जहां सारा content एक हफ्ते बाद free हो जाता है
      subscriber links इसलिए हैं कि अगर आपकी क्षमता हो तो subscription लेने के लिए encourage किया जा सके
    • नोटिस में लिखा है, “निम्नलिखित subscriber-only content को एक LWN subscriber ने आपके लिए देखने योग्य बनाया है”
      मैं गलत हो सकता हूं, लेकिन इसे पढ़कर ऐसा लगता है कि जो content पहले paid था, उसे शायद article-level पर public करने के लिए funding जुड़ी हुई है
      क्या सच में ऐसा है, यह जानने वाला कोई है तो उत्सुक हूं