OpenGL ES अनुरूपता प्रमाणन पाने वाला पहला M1 GPU ड्राइवर

 (rosenzweig.io)
1 पॉइंट द्वारा GN⁺ 2023-08-23 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • M1·M2 श्रृंखला GPU पर OpenGL ES 3.1 applications को मानक के अनुसार चलाने वाला Linux ड्राइवर उपलब्ध कराया गया है
  • Asahi Linux का reverse-engineering आधारित free·open source ड्राइवर, M1·M2 graphics hardware पर Khronos अनुरूपता टेस्ट पास करने वाला एकमात्र OpenGL ES 3.1 implementation है
  • प्रमाणन के लिए आधिकारिक टेस्ट पास करना, Khronos में submission, और 30-दिन की review अवधि से गुजरना होता है; M1, M1 Pro/Max/Ultra, M2, M2 Pro/Max प्रविष्टियाँ दर्ज की गई हैं
  • OpenGL ES 3.1, जून में आए experimental OpenGL ES 3.0·OpenGL 3.1 support को अपडेट करता है और compute shader तथा image atomic operations जोड़ता है
  • M1 में image atomic operations के लिए समर्पित instruction न होने पर address calculation से workaround किया गया, और बाद में bit interleave instruction खोजकर 10 instructions को 1 में घटा दिया गया

M1·M2 के लिए OpenGL ES 3.1 अनुरूपता प्रमाणन

  • M1·M2 श्रृंखला GPU के लिए OpenGL ES 3.1 अनुरूपता प्रमाणित ड्राइवर उपलब्ध है
    • यह OpenGL ES 3.1 applications के साथ compatible है
    • Linux install करके इसका उपयोग किया जा सकता है
  • मौजूदा Asahi Linux उपयोगकर्ता distribution के अनुसार upgrade command से नवीनतम ड्राइवर प्राप्त कर सकते हैं
    • Fedora: dnf upgrade
    • Arch: pacman -Syu
  • reverse-engineering आधारित free·open source graphics ड्राइवर asahi/mesa पर सार्वजनिक रूप से उपलब्ध है
  • यह ड्राइवर M1·M2 श्रृंखला graphics hardware पर दुनिया का एकमात्र OpenGL ES 3.1 अनुरूपता प्रमाणित implementation है
    • इसने दसियों हजार tests पास करके correctness साबित की है
    • इसे industry standards body से मान्यता मिली है

Khronos प्रक्रिया और पंजीकृत chip श्रृंखलाएँ

  • अनुरूपता प्रमाणन पाने के लिए implementation को आधिकारिक conformance test suite पास करना होता है
    • test suite को specification की सभी सुविधाओं को verify करने के लिए डिज़ाइन किया गया है
    • test results को standards body Khronos में submit किया जाता है
    • 30-दिन की review अवधि में कोई समस्या न होने पर इसे अनुरूपता प्रमाणित implementation माना जाता है
  • Khronos वेबसाइट पर निम्न ड्राइवर अनुरूपता प्रमाणित implementation के रूप में दर्ज हैं
  • यह उपलब्धि केवल OpenGL ES तक सीमित नहीं है
    • यह M1 के लिए पूरे graphics standards क्षेत्र में पहला अनुरूपता प्रमाणित implementation है

निर्माता ड्राइवर और standard API के बीच की खाई

  • निर्माता का M1 ड्राइवर Vulkan, OpenGL, OpenGL ES सहित किसी भी standard graphics API में अनुरूपता प्रमाणन प्राप्त नहीं कर पाया है
  • Linux का उपयोग न करने वाले M1·M2 environments में standard-based applications के काम करने की कोई गारंटी नहीं है
  • Vulkan के मामले में MoltenVK proprietary ड्राइवर के ऊपर Vulkan के कुछ हिस्सों को layer करता है
    • उस proprietary ड्राइवर में core features गायब हैं
    • वैध Vulkan applications टूट सकती हैं
    • यह Linux पर switch न किए हुए M1·M2 computers के developers और users दोनों के लिए बाधा बनता है
  • Asahi Linux ड्राइवर development का लक्ष्य standard software को M1-specific hacks या porting के बिना चलाना है
    • यह proprietary ड्राइवर, proprietary API, और standard implementation से इनकार पर संतुष्ट नहीं है
    • specification के अनुरूप open standard implementation को ecosystem की वांछनीय दिशा माना गया है

OpenGL ES 3.1 की मुख्य अतिरिक्त सुविधाएँ

  • OpenGL ES 3.1, जून में उपलब्ध experimental OpenGL ES 3.0 aur OpenGL 3.1 को अपडेट करता है
  • मुख्य अतिरिक्त सुविधा compute shader है
    • इसका उपयोग मुख्यतः graphics applications के भीतर general computation को accelerate करने के लिए किया जाता है
    • 3D games physics simulation को compute shader में चला सकते हैं
    • simulation results को सीधे rendering में उपयोग करने से GPU और CPU physics simulation के बीच synchronization से होने वाले stalls कम हो सकते हैं
    • इसके परिणामस्वरूप games अधिक तेज़ चल सकते हैं

image atomic operations की ज़रूरत क्यों है

  • OpenGL ES के पिछले versions applications को screen display के लिए images पढ़ने की अनुमति देते थे
  • ES 3.1 applications को सामान्यतः compute shader में images पर लिखने की अनुमति देता है
    • इससे image processing algorithms को fixed-function 3D pipeline में ढालने की बाधा कम होती है
  • GPU एक massively parallel संरचना है जो एक साथ हजारों threads चलाती है
    • यदि दो threads एक ही स्थान पर लिखें तो execution order के अनुसार परिणाम बदल सकता है
    • यही स्थिति race condition है
  • atomic memory access race condition को संभालने का मूल समाधान है
    • memory subsystem का विशेष hardware चुने गए operations के लिए thread order से स्वतंत्र consistent results सुनिश्चित करता है
    • आधुनिक graphics hardware addition जैसे कई atomic operations को support करता है
  • OpenGL ES extension OES_shader_image_atomic image pixels पर atomic operations जोड़ता है
    • यह extension ES 3.2 में अनिवार्य है
    • उदाहरण के लिए compute shader pixel (10, 20) का मान atomically बढ़ा सकता है

M1 पर image atomic operations लागू करने का तरीका

  • अन्य GPU image atomic operations के लिए dedicated instructions देते हैं, इसलिए ड्राइवर implementation सरल होता है
  • M1 में image atomic operations के लिए dedicated hardware instruction नहीं है
    • non-image atomic operations मौजूद हैं
    • non-atomic image functionality भी मौजूद है
  • इसलिए pixel पर सीधे atomic operation करने के बजाय, pixel का memory address निकाला गया और उस address पर सामान्य atomic operation किया गया
  • यदि image memory में linear रूप से रखी हो तो address calculation सरल है
    • Y coordinate को stride, यानी प्रति पंक्ति bytes की संख्या, से गुणा किया जाता है
    • X coordinate को प्रति pixel bytes की संख्या से गुणा किया जाता है
    • दोनों मान जोड़कर पहले pixel के सापेक्ष byte offset निकाला जाता है
    • पहले pixel के address में offset जोड़कर अंतिम address प्राप्त किया जाता है
  • वास्तविक images आम तौर पर linear रूप से व्यवस्थित नहीं होतीं
    • आधुनिक graphics hardware cache efficiency बढ़ाने के लिए X·Y coordinates को interleave करता है
    • memory में pixels की व्यवस्था पंक्ति-आधारित न होकर सर्पिल जैसी वक्ररेखा का अनुसरण करती है

bit interleave optimization और छिपे instruction की खोज

  • X·Y coordinates को interleave करते समय एक-एक bit को mask और shift करना अप्रभावी है
  • प्रसिद्ध bit manipulation algorithm bit groups को मिलाकर इस समस्या को parallel बनाता है
    • shader code में इस algorithm को लागू करने से performance बेहतर होती है
  • व्यवहार में प्रत्येक coordinate के केवल निचले 7 bits या उससे कम interleave किए जाते हैं
    • X·Y coordinates को 32-bit register के निचले·ऊपरी 16 bits में रखकर 32-bit instruction से एक साथ process किया जा सकता है
    • इससे instructions की संख्या आधी हो जाती है
    • GPU के shift-and-add fused instruction का भी उपयोग किया गया
  • इन तकनीकों को मिलाकर M1 GPU assembly की 10 instructions में interleave किया जा सका
  • इसके बाद dedicated bit interleave instruction की संभावना की जाँच की गई
    • PowerVR में shfl shuffle instruction है
    • M1 GPU में PowerVR से लिए गए तत्व हैं, इसलिए समान instruction की संभावना पर विचार किया गया
    • proprietary compiler ने test shader compile करते समय उस instruction का उपयोग नहीं किया, इसलिए केवल compile results देखकर reverse-engineering करना कठिन था

अनुमान और सत्यापन से interleave instruction की पुष्टि

  • Dougall Johnson ने पहले से ज्ञात instruction encoding के आधार पर संभावित candidate का अनुमान लगाया
  • bit reverse instruction में operation बताने वाला 2-bit field है और उसका मान 01 है
    • set bits की संख्या गिनने वाले instruction का मान 10 है
    • पहला set bit खोजने वाले instruction का मान 11 है
    • ज्ञात जटिल bit manipulation instructions इन तीन मानों का उपयोग करते हैं
  • बचा हुआ मान 00 अभी तक न देखा गया अज्ञात मान था
    • यदि interleave instruction मौजूद हो, तो यह bit reverse instruction जैसा हो सकता है लेकिन operation code 00 होने की संभावना पर विचार किया गया
  • ज्ञात तीन instructions में केवल एक input source होता है, लेकिन interleave instruction को दो sources चाहिए
    • M1 GPU instructions आम तौर पर source locations को consistent तरीके से encode करते हैं
    • दो-source arithmetic instructions में दूसरे source की जगह पर एक खाली स्थान था, इसलिए उसे दूसरे source के रूप में अनुमानित किया गया
  • सत्यापन के लिए compiler को संशोधित कर multiply जैसे 2-source integer operation को अनुमानित interleave encoding से बदला गया
    • compute shader में उस operation का उपयोग किया गया
    • test shader ने हर संभव input पर जाँचा कि अज्ञात instruction interleave result लौटाता है या नहीं
    • instruction दो 16-bit sources लेता है, इसलिए लगभग 4 अरब inputs थे
    • M1 GPU ने ड्राइवर के नए compute support के साथ सभी inputs को 1 सेकंड से कम में verify कर लिया
  • अंततः 10-instruction vectorized assembly को 1 interleave instruction से बदल दिया गया
    • यह तरीका तेज़ है और conformance tests भी पास करता है

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

1 टिप्पणियां

 
GN⁺ 2023-08-23
Hacker News की रायें

  • Apple OpenUSD rendering/animation/CAD/3D scene format को लेकर nVidia, Adobe, Autodesk, Microsoft आदि के साथ सहयोग कर रहा है, तो सोच रहा हूँ कि क्या OpenGL·Vulkan support बेहतर होगा
    अगर OpenUSD का मूल विचार “एक ऐसा file format जो हर जगह consistent तरीके से render हो” है, तो Apple इसे ज्यादा 3D software कंपनियों को macOS पर लाने के साधन की तरह इस्तेमाल कर सकता है
    आगे Apple के सामने दो रास्ते दिखते हैं: या तो फिल्म और game production pipelines में ताकत पाने वाले मौजूदा OpenGL/Vulkan standards का पालन करे, या उलटा Metal को और जोर से आगे बढ़ाकर दुनिया को Metal + macOS की ओर ले जाने की कोशिश करे
    मन तो पहले वाले रास्ते की उम्मीद करता है, लेकिन intuition कहती है कि Apple दूसरे रास्ते को पूरी ताकत से आगे बढ़ाएगा, और सिर्फ Apple ही नहीं बल्कि nVidia, Autodesk, Adobe, Microsoft भी आम तौर पर ऐसे standards पसंद नहीं करते जिन्हें वे control नहीं करते

    • इसमें मैं यह nuance जोड़ना चाहूँगा कि “Apple को open standards तब पसंद आते हैं जब वह कमजोर स्थिति में होता है”
      iMac और शुरुआती OS X ने USB, JPEG, MPEG, mp3, PostScript, built-in TCP/IP, .rtf जैसे standards को बड़े जोर से आगे रखा था, और Jobs ने भी इस पर जोर दिया था
      बाद में जब कंपनी खाई के किनारे से उबर गई, तो उसने फिर “value add” करना शुरू किया, और iPhone को भी शुरुआत में proprietary और खराब Flash या अधकचरे “mobile HTML” के बजाय HTML device के रूप में पेश किया गया था
      आज भी जिन क्षेत्रों में उसकी market dominance कमजोर है, वहाँ वह H.264, Matter/Thread जैसे ऐसे standards को support करता है जिन्हें वह control नहीं करता
    • Apple कई open standards को support करता है, लेकिन “वह ऐसे standards पर निर्भर नहीं होना चाहता जिन्हें वह control नहीं करता” कहना ज्यादा सटीक लगता है
      क्योंकि वह hardware और software को मजबूती से जोड़कर इच्छित user experience बनाता है, इसलिए यह समझ आता है कि वह ऐसे standards implement करना चाहता है जिन पर कुछ हद तक control हो, ताकि वह experience दूसरों पर निर्भर न हो
      USB-C जैसे industry standards जिनकी दिशा अभी पूरी तरह तय नहीं हुई हो, उनमें भी अगर पहले कदम बढ़ाया जाए तो दिशा को प्रभावित किया जा सकता है, इसलिए Apple कभी-कभी उन्हें अपनाता है
    • OpenUSD render किए जाने वाले data को package और specify करने का तरीका है; यह इससे अलग बात है कि app rendering acceleration के लिए कौन-सा API इस्तेमाल करता है
      Adobe, Autodesk, Blender आदि में से ज्यादातर पहले से ही अलग-अलग operating systems के लिए अलग backends support करते हैं, और macOS पर इसमें Metal भी शामिल है
    • मुझे नहीं लगता Apple OpenGL पर वापस जाएगा
      OpenGL बहुत पुराना है, अच्छे drivers के साथ काम करना भी लगभग nightmare है, और high-performance application code लिखना तक मुश्किल है, इसलिए इसका अफसोस नहीं है
      हाँ, अच्छा होता अगर Metal बनाने के बजाय Apple Vulkan को push करता, लेकिन Linux के बाहर Vulkan आम तौर पर second-class citizen जैसा है; फिर भी target करने के लिए यह काफी ठीक second-class citizen है
      games या Steam support के लिहाज से कई games API handling engine पर छोड़ देते हैं, और अगर किसी team के पास सीधे API संभालने की क्षमता है, तो जब तक वे बहुत cutting-edge features नहीं इस्तेमाल कर रहे, MoltenVK भी ठीक रहने की संभावना है
      मैंने life भर cross-platform के लिए OpenGL बहुत इस्तेमाल किया है, लेकिन global state, इस्तेमाल नहीं की जानी चाहिए वाली functions, pitfalls, विशाल extension headers और कठिन debugging के कारण यह सचमुच खराब API था; Vulkan verbose है, लेकिन कई मायनों में उलटा ज्यादा आसान है
    • Metal/Vulkan/OpenGL की स्थिति अफसोसजनक है और Apple की motivation अच्छी तरह समझ नहीं आती
      लेकिन अभी जो Mac मैं इस्तेमाल कर रहा हूँ, वह सिर्फ USB-C ports के जरिए कई peripherals और बड़े monitor से standard protocols पर जुड़ा हुआ है
      कुल मिलाकर Apple तब open standards को पसंद करता दिखता है जब standard पर्याप्त हो; जब USB2 Lightning द्वारा किए जाने वाले कई काम नहीं कर पाता था, तब उसने Lightning बनाया, लेकिन USB-C आने पर Mac और iPad में इसे तुरंत अपनाया, और iPhone में अफसोस की बात है कि अब भी देर कर रहा है

  • Asahi और Alyssa reverse engineering के दिग्गज हैं, और उनका काम अविश्वसनीय है
    मुझे लगता है कि Apple ने उन्हें hire करने की कोशिश की होगी, या पहले ही कोशिश कर चुका होगा लेकिन उन्होंने मना कर दिया होगा

    • Alyssa पहले से ही Valve के साथ contract में हैं
      शायद इस क्षमता को business में इस्तेमाल करने की वजह Apple से ज्यादा Valve के पास है
    • Apple ने शायद पहले ही कोशिश की होगी, लेकिन NDA और non-compete clauses के कारण इनकार मिला होगा, या फिर HR ने इनके profile को ठीक से assess नहीं किया होगा
    • नौकरी कोई बहुत अच्छा offer नहीं है
      आम तौर पर employees को उनके द्वारा पैदा किए गए profit की तुलना में कम compensation मिलता है, और IT में तो खासकर ऐसा है
      talented लोगों के लिए बेहतर है कि company बनाकर उचित कीमत पर services बेचें, लेकिन कुछ देशों में बड़ी कंपनियों ने government पर lobbying करके ऐसे रास्ते बंद करवा दिए हैं

  • atomic operation trick बहुत संतोषजनक था, और PowerVR lineage से swizzle instruction infer करना खास तौर पर impressive था
    Apple engineers भी इससे सीखेंगे या कम से कम इसकी cleverness को बहुत सराहेंगे
    मुझे Accolade द्वारा Sega Genesis video hardware की reverse engineering का पुराना मामला याद आया, जब engineers ने publicly available Texas Instruments TMS9918 VDP documents को starting point बनाया और Genesis(Mega Drive) के 9918-derived VDP का अनुमान लगाया था

    • Apple के पास अपने chips के बारे में internal documentation है, इसलिए वे इस काम की बहुत सराहना तो करेंगे, लेकिन ऐसा नहीं है कि वे black box बनाकर software लिखते समय design approach भूल गए हों

  • स्पष्ट करने के लिए, यह पहला conformance-certified Linux driver नहीं है; इसका अर्थ इससे बड़ा है
    Apple खुद भी OpenGL ES 3.1 के अनुरूप नहीं है, इसलिए किसी भी operating system पर M series के लिए यह सचमुच पहला conformance-certified OpenGL ES 3.1 driver है
    इसलिए team को donate करने की अपील आ रही है
    https://asahilinux.org/support/

    • वे जो कर रहे हैं वह मुझे सचमुच पसंद है, लेकिन पहले Hacker News पर asahilinux link क्लिक करने पर popup आया था कि Hacker News readers site पर welcome नहीं हैं, इसलिए मैं content पढ़ नहीं पाया
    • सोच रहा हूँ कि क्या इसे macOS पर इस्तेमाल किया जा सकता है
    • वहाँ का GitHub link Asahi को lead करने वाले marcan पर जाता है, लेकिन मैं मुख्य रूप से driver development support करना चाहता हूँ
      अगर ऐसा कोई option है तो जानना चाहूँगा कि कहाँ किया जाए, और अगर नहीं है तो बाद में बस वही link इस्तेमाल करूँगा

  • अब जिन macOS OpenGL ऐप्स की सिफारिश नहीं की जाती, उन्हें debug करके देखें तो यह समस्या बहुत साफ दिखती है
    क्योंकि abstraction layer असली OpenGL state को उस तरीके से expose नहीं करती जिसे पुराना Apple OpenGL debugger पढ़ सके
    अगर आपके पास पुराना Mac नहीं है जिस पर ऐसा पुराना macOS installed हो जहाँ OpenGL अंदर से Metal के ऊपर नहीं चलता था, तो default debugger से macOS पर OpenGL को व्यावहारिक रूप से debug नहीं किया जा सकता
    debugger या app बस crash हो जाता है

  • यह मुख्य रूप से games में मदद करता दिखता है, deep learning में बहुत ज्यादा नहीं
    Mac M1 की सबसे आकर्षक बात बड़ी memory capacity है, और कई cards में distribute न कर पाने की वजह से training के लिए शायद बहुत अच्छा न हो, लेकिन Stable Diffusion, LLaMA जैसे बड़े model inference engine के रूप में अच्छा है

    • Apple Silicon सैद्धांतिक रूप से जिन latest cross-platform general-purpose GPU standards का उपयोग या implementation कर सकता है, वे दो हैं: SYCL और Vulkan Compute
      SYCL Khronos Group का vendor-neutral high-level programming framework है, लेकिन application support सीमित है, और उम्मीद है कि Intel के support से यह धीरे-धीरे बेहतर होगा
      Vulkan Compute compute shaders के जरिए समस्या को workaround करता है, लेकिन application support की स्थिति के बारे में मुझे ठीक से नहीं पता
      SYCL को OpenCL और OpenCL के SPIR-V extension के ऊपर implement किया जा सकता है, लेकिन मजबूत vendor lock-in के कारण यह रास्ता Intel और Mesa के अलावा ज्यादातर छोड़ दिया गया है, और आजकल इसे अक्सर ROCm, HIP, CUDA जैसे हर GPU vendor API के backends के रूप में implement किया जाता है
      Metal पर यही तरीका लागू करना बहुत मुश्किल होगा, और Mesa में Intel तथा AMDGPU के लिए OpenCL+SPIR-V का experimental support है, इसलिए सैद्धांतिक रूप से इसे Apple Silicon तक extend किया जा सकता है, लेकिन फिलहाल Apple Silicon का OpenCL बिल्कुल support नहीं है और बस roadmap में होने भर की बात थी
    • सही है
      deep learning चलाने के लिए CUDA, ROCm, MPS जैसे backends चाहिए
      बड़े CUDA server पर PyTorch model train करके MacBook Air पर inference चलाना अपेक्षाकृत आसान था
    • compute shader वाला हिस्सा अच्छी प्रगति है, लेकिन फिर भी यह उन interfaces को provide नहीं करता जिनकी ऐसे deep learning tools उम्मीद करते हैं
      हालांकि eiln ने Apple Neural Engine driver लिखा है, जिससे GPU की जगह dedicated hardware इस्तेमाल किया जा सकेगा, और आगे इसे linux-asahi में merge किया जाना है
    • TensorFlow Lite वास्तव में OpenGL ES को support करता है

  • यह कहना शानदार लगता है कि Asahi Lina और दो लोगों ने न्यूनतम funding के साथ एक बड़ी company को हरा दिया, लेकिन असल में उन्होंने हराया कम, Apple ने उस पर ध्यान ही नहीं दिया ज्यादा लगता है
    Apple शुरू से उस race में शामिल ही नहीं था

  • “न्यूनतम funding के साथ दो लोगों ने एक बड़ी company को हरा दिया” वाला euphemism अच्छा है
    यह Apple के लिए साफ तौर पर शर्मनाक है, और Apple standards या compliance में रुचि नहीं रखता; वह चाहता है कि लोग उसके अपने closed garden में फंसे रहें
    अगर मैं iOS developer नहीं होता, तो बहुत पहले Apple ecosystem छोड़ चुका होता
    मुझे hardware पसंद है, और वह brand भी पसंद था जो 80–90 के दशक के Apple की तरह creativity और human-centric सोच को आगे रखता था, लेकिन आज की company politically correct marketing videos के पीछे लालच से सड़ी हुई दिखती है

    • पूरी तरह सहमत, लेकिन कोई meaningful alternative ढूंढना लगभग असंभव है
      पिछले upgrade के समय मैंने विकल्प खोजे थे, लेकिन Apple से बाहर निकलने के लिए अंतहीन compromises करने पड़ते
      iPhone की जगह stock Android और लंबा support पाने की उम्मीद में Pixel देखा, लेकिन battery problems की बातें लगातार आती रहीं, और software polish, app ecosystem, stability भी बाधा बने
      base MacBook Air M1 की build quality, battery और stability के करीब value-for-money product भी ढूंढना मुश्किल था
      मैं iPad पर comics और magazines भी पढ़ता हूं, लेकिन tablet market में कई सालों से समझ नहीं आता कि alternative क्या है, और Apple Watch शायद छोड़ी जा सकती है, लेकिन वह बस अच्छे से काम करती है और third-party accessories बहुत हैं
      अब वह दौर गुजर गया जब रोज नया ROM flash करते थे, और stability व ease of use में Apple को हराना मुश्किल लगता है—यह अफसोसजनक है
    • इस industry का सबसे बड़ा secret शायद यह हो सकता है कि दो लोग सबसे बड़ी companies से भी ज्यादा हासिल कर सकते हैं
      सबकी jobs सुरक्षित रहने की इकलौती वजह यह है कि कोई ठीक-ठीक पता नहीं लगा पाता कि वे दो लोग कौन हैं
    • लगता है सभी यह बात miss कर रहे हैं कि Apple के लिए laptops को lock down करना अपेक्षाकृत आसान रहा होगा, फिर भी उसने दूसरे operating systems और उनके development के लिए दरवाजा खुला रखा
      Apple ने खुद silicon बनाया और पूरा platform बनाया, ऐसे में दूसरे operating systems चलने देने के लिए जगह छोड़ना सिर्फ गलती थी, ऐसा मानना मुश्किल है
      यह साफ है कि third-party development के लिए उसने जानबूझकर दरवाजा खुला रखा, फिर भी Apple को दोष देने वाला माहौल निराशाजनक है
    • मुझे नहीं लगता कि कोई standard मौजूद है सिर्फ इसलिए Apple को उसे implement करना ही चाहिए
      उदाहरण के लिए, लगातार Vulkan implementation support करने में काफी resources और release schedule का बोझ आता है, इसलिए business reason चाहिए
      “शर्मिंदगी से बचने के लिए” शायद पर्याप्त नहीं होगा
      community goodwill वाला तर्क हो सकता है, लेकिन जो लोग Apple को “politically correct marketing videos के पीछे लालच से सड़ी company” कहते हैं, उनकी goodwill के पीछे Apple शायद नहीं भागेगा
    • OpenGL एक मरता हुआ specification है जो पुराने और भयानक programming model पर आधारित है, और Khronos के conformance tests भी कुछ अजीब और जरूरत से ज्यादा हैं
      conformance tests open source नहीं हैं, और GitHub पर मौजूद अलग “conformance suite” Google के dEQP पर आधारित है, Khronos का internal test bundle नहीं
      implementation में काफी बड़े bugs और gaps होने पर भी “standard compatible certification” मिल सकता है
      Apple ने सिर्फ OpenGL 3.1 support का वादा किया था, और M1 के लिए OpenGL driver भी पुराने apps चलते रहें इसलिए Metal के ऊपर emulation layer के रूप में दोबारा लिखा, लेकिन वह OpenGL के नए versions implement नहीं करेगा, और इसकी जरूरत भी नहीं है
      Apple की आलोचना करने के लिए बहुत कुछ है और Metal API व tools को बेहतर बनाने की काफी गुंजाइश है, लेकिन OpenGL पर ध्यान न देना यहां पूरी तरह reasonable decision है

  • यह interesting है कि original text में ‘Apple’ शब्द एक बार भी नहीं आता और सिर्फ ‘manufacturer’ और ‘large company’ कहा गया है
    अगर यह जानबूझकर है, तो सोचता हूं कि क्या legal reasons हैं

    • शायद इसलिए कि यह Apple के बारे में article नहीं है
      focus Apple नहीं, बल्कि M1/M2 architecture पर Linux को सही से चलाना है, और target Microsoft, Amazon, Google होता तो भी शायद इसी तरह handle किया जाता

  • इस ड्राइवर के development process को दिखाने वाली live stream देखना मज़ेदार था, और यह वाकई कमाल का काम है

    • जिन्हें पता नहीं है, उनके लिए: इसे https://www.youtube.com/c/AsahiLina पर देखा जा सकता है
      अब तक देखे गए सबसे हैरान कर देने वाले low-level programming कामों में से एक है