OBS Studio ने नया renderer पेश किया: OBS ने Metal को कैसे अपनाया
(obsproject.com)- macOS के लिए OBS Studio 32.0.0 से Apple Metal-आधारित renderer backend को प्रयोगात्मक रूप से जोड़ा गया है, जिसका लक्ष्य मौजूदा OpenGL की तुलना में प्रदर्शन और दक्षता में सुधार करना है
- Metal एक ऐसा API है जिसे कम overhead और आधुनिक GPU संरचना को ध्यान में रखकर डिज़ाइन किया गया है, और OBS ने इसे सपोर्ट करने के लिए GPU के साथ इंटरैक्शन के अपने तरीके में बुनियादी बदलाव किए
- OBS का मौजूदा renderer Direct3D-केंद्रित संरचना के अनुसार बना हुआ था, इसलिए Metal backend के लिए shader conversion और resource management जैसे क्षेत्रों में बड़े पैमाने पर compatibility work किया गया
- खास तौर पर HLSL shaders को real time में MSL में बदलना और Direct3D के
map/unmapव्यवहार को Metal के अंदर simulate करने जैसी जटिल implementation शामिल है - Metal backend अभी “experimental” चरण में है, लेकिन OpenGL से तेज प्रदर्शन, Swift-आधारित सुरक्षित code structure, और EDR preview support जैसी खूबियों के कारण यह macOS development environment में एक महत्वपूर्ण मोड़ है
Metal renderer पेश करने का अवलोकन
- OBS Studio 32.0.0 से macOS पर Metal graphics API-आधारित renderer को प्रयोगात्मक रूप से उपलब्ध कराया गया
- मौजूदा OpenGL backend के विकल्प के रूप में, प्रदर्शन और दक्षता सुधार इसका लक्ष्य है
- Metal एक आधुनिक API है जो GPU के साथ इंटरैक्शन के तरीके को बुनियादी रूप से बदलता है, और OBS ने उसी के अनुसार अपनी आंतरिक संरचना को समायोजित किया
- Metal backend को “Experimental” के रूप में चिह्नित किया गया है, और इसमें कुछ ज्ञात समस्याएँ और सीमाएँ मौजूद हैं
- OpenGL renderer अभी भी default बना हुआ है, और उपयोगकर्ता Metal संस्करण को खुद आज़मा सकते हैं
- Metal का अनुभव रखने वाले developers से feedback और Pull Request के रूप में भागीदारी का आग्रह किया गया है
Metal की पृष्ठभूमि और design philosophy
- Apple ने 2014 में पहले iPhone के लिए Metal पेश किया और 2015 में इसे Mac तक विस्तारित किया
- उस समय Metal, Intel, AMD, NVIDIA GPU सभी को सपोर्ट करने वाले पहले next-generation graphics API में से एक था
- Metal ने AMD के Mantle और मौजूदा OpenGL·Direct3D की अवधारणाओं को मिलाया, लेकिन legacy तत्वों को हटाकर इसे नए सिरे से डिज़ाइन किया गया
- Objective-C और Swift-आधारित API होने के कारण यह iOS·macOS developers के लिए परिचित संरचना देता है
- Xcode के भीतर shader debugging और GPU analysis features का integrated support मिलता है
API design के अंतर और OBS renderer का adaptation
- मौजूदा OpenGL·Direct3D में resource management और synchronization को API अपने आप संभालता था,
जबकि Metal जैसे आधुनिक API में developers को यह सीधे manage करना पड़ता है - नए API, GPU को parallel command queue-आधारित processing device की तरह देखते हैं, और pipeline state को immutable objects के रूप में manage करते हैं
- OBS का मौजूदा renderer Direct3D के तरीके के अनुसार डिज़ाइन किया गया था,
इसलिए Metal support के लिए backend स्तर पर compatibility layer implement की गई
OBS renderer की संरचना और Metal compatibility समस्याएँ
- OBS प्लेटफ़ॉर्म के अनुसार Direct3D (Windows) और OpenGL (Linux/macOS) backend का उपयोग करता है
- renderer core API-independent है, लेकिन कुछ Direct3D-केंद्रित मान्यताएँ मौजूद हैं
- प्रमुख सीमाएँ
- shaders HLSL-आधारित लिखे गए हैं, इसलिए execution के समय conversion की आवश्यकता होती है
- global variables का उपयोग, sequential execution की धारणा, और Direct3D-शैली texture handling जैसी बातें
- preview rendering DXGI के ‘discard model’ पर निर्भर करती है
Shader conversion (Transpiling Shaders)
- OBS की effect files HLSL में लिखी गई हैं और उन्हें हर API के अनुसार convert किया जाता है
- Metal support के लिए HLSL → MSL converter जोड़ा गया
- मुख्य अंतर
- MSL में input/output structs को अलग करना पड़ता है, और global variables supported नहीं हैं
- सभी uniform data को GPU buffer के माध्यम से भेजना होता है, इसलिए function arguments में इन्हें स्पष्ट रूप से देना पड़ता है
- function call के समय type match और signature validation अधिक सख़्त होते हैं
- converter runtime पर shader code को आंशिक रूप से rewrite करके MSL नियमों के अनुरूप बनाता है
- उदाहरण के लिए, HLSL के
uniformvariables को MSL केconstant bufferमें बदलना int3→uint2+uintजैसे type conversion logic को अपने आप insert करना
- उदाहरण के लिए, HLSL के
Direct3D व्यवहार का simulation
- OBS renderer को Direct3D के
map/unmapव्यवहार को आधार मानकर डिज़ाइन किया गया था- Metal ऐसा automatic synchronization नहीं देता, इसलिए इसे backend में सीधे implement करना पड़ा
- Metal backend की processing method
- write के समय GPU buffer बनाया जाता है और CPU memory के साथ सीधे share किया जाता है
unmapपर GPU blit command schedule की जाती है ताकि उसे texture में copy किया जा सके- read के समय GPU buffer share किया जाता है, लेकिन explicit synchronization से conflict रोके जाते हैं
- परिणामस्वरूप Direct3D की resource tracking और synchronization features को Metal के भीतर पुनर्निर्मित किया गया
Preview rendering की समस्या और अस्थायी समाधान
- macOS की Metal Layer, DXGI से अलग, app को मनचाहे समय पर frame दिखाने की अनुमति नहीं देती
- system ProMotion और low power mode के अनुसार frame rate नियंत्रित करता है
- OBS का अपना render loop और macOS का display cycle मेल न खाने से preview delay होता है
- अस्थायी समाधान
- OBS पहले virtual texture में render करता है, और एक अलग thread इसे screen surface पर copy करता है
- इस प्रक्रिया में GPU synchronization की आवश्यकता होती है, और frame mismatch की संभावना रहती है
- macOS 14 के बाद per-window independent timer के कारण अतिरिक्त चुनौतियों की उम्मीद है
आधुनिक graphics API की छिपी हुई लागत
- Metal backend का विकास कई महीनों के research और iterative design से गुज़रा
- इससे OpenGL→Vulkan और D3D11→D3D12 transition में प्रदर्शन गिरने के कारणों को व्यावहारिक रूप से समझा जा सका
- आधुनिक API में जो काम पहले driver करता था, वह अब application को खुद करना पड़ता है
- GPU के काम करने के तरीके और command dependency की गहरी समझ आवश्यक है
- Metal backend ने कुछ overhead दोबारा जोड़े हैं, लेकिन इसके बावजूद ये लाभ मिलते हैं
- OpenGL के बराबर या उससे बेहतर performance
- shader·texture debugging जैसी शक्तिशाली analysis capabilities
- Swift-आधारित सुरक्षित code structure
- EDR preview support के कारण उच्च-गुणवत्ता video processing संभव
- Xcode की integrated analysis features के ज़रिए macOS OBS maintenance की दक्षता बेहतर होती है,
और आगे Metal को default renderer बनाने के लिए developers से feedback माँगा गया है
1 टिप्पणियां
Hacker News की राय
यह वाकई बहुत अच्छा लेख था। shader processing के तरीके की व्याख्या बेहद चौंकाने वाली थी
यह जानने की जिज्ञासा हुई कि third-party plugin shaders को कई backends पर चलाने के लिए क्या सचमुच ऐसी प्रक्रिया से गुजरना पड़ता है, या फिर यह backward compatibility बनाए रखने की वजह से ऐसा हुआ
बाहरी developers से यह कहना कि "हर shader language में अलग-अलग लिखो" core team के नज़रिए से आसान हो सकता है, लेकिन व्यवहारिक रूप से यह वांछनीय नहीं है
सबको यह अक्षम लगता है, लेकिन व्यावहारिक रूप से इसका कोई विकल्प नहीं है
लेख का शीर्षक मुख्य बात छिपा रहा है
इसे कुछ ऐसा होना चाहिए: "OBS Studio ने नया renderer पेश किया: Metal अपनाने की प्रक्रिया"
यह साफ तौर पर Apple द्वारा Vulkan के बजाय अपने ecosystem की रक्षा के लिए API बनाने की कीमत दिखाता है
OBS Studio ने मार्च 2020 में, version 25.0 में Vulkan support जोड़ा था। तब से 5 साल से ज़्यादा हो चुके हैं
embedded environments में अब भी OpenGL ES का दबदबा है
मैं इस विषय का विशेषज्ञ नहीं हूँ। मैंने जो पढ़ा उसका शायद 5% ही समझ पाया, लेकिन ऐसे तकनीकी विवरण समझाने वाले लेख और होने चाहिए
साधारण announcement पोस्ट तो मार्केटिंग जैसी लगती हैं
व्यक्तिगत रूप से मैं आने वाले VST3 support को लेकर अधिक उत्साहित हूँ, लेकिन यह खबर भी अच्छी लगी
यह Rockchip SoC पर hardware encoding सेट करने से कहीं आसान है
यह बात दिलचस्प लगी कि Metal ने Direct3D के object-oriented approach को एक कदम आगे बढ़ाकर, उसे Objective-C और Swift की "ज़्यादा बोलने वाली" API design के साथ जोड़ दिया
यह हैरान करने वाली बात है कि OS-स्तर का 3D graphics API इस तरह dynamic language आधारित बनाया जा सकता है
मुझे लगता है कि यह
objc_msgSend()optimization की वजह से संभव हुआVulkan/Metal/DirectX 12 व्यक्तिगत calls के बजाय command buffer में कई commands भरकर भेजते हैं
2000s की शुरुआत में Direct3D को C# से इस्तेमाल करने पर किताबें थीं, जिन्होंने यह धारणा बदली कि GC language में भी high-performance graphics संभव हैं
असली कुंजी यह है कि pre-allocated buffers को reference करने वाली batch processing संरचना runtime overhead को न्यूनतम रखती है
Cocoa के बाद से ज़्यादातर चीज़ें सीमित C++ subset (जैसे IOKit) में लिखी गई हैं
मेरी उम्मीद है कि आधुनिक GPU APIs किसी और अधिक सरल चीज़ की ओर जाने वाला संक्रमणकालीन चरण भर हों
OpenGL से प्यार भी है और नफ़रत भी, लेकिन नए APIs इस्तेमाल करने के बाद उल्टा OpenGL की सरलता याद आने लगी
यह जानने की जिज्ञासा है कि Metal पुराने Intel Mac पर भी performance बेहतर करेगा या यह सिर्फ M series के लिए optimization है
लेकिन Metal 3 अब भी कई Intel Mac पर support होता है, इसलिए इसे सीमित क्यों किया गया, यह सवाल बना रहता है
मैं Mac Mini के साथ streaming setup बनाने के बारे में सोच रहा था
जानना चाहता हूँ कि इस performance improvement के बाद क्या यह पर्याप्त होगा
2D arcade games या development screen जैसी चीज़ों के लिए कोई दिक्कत नहीं होगी
अगर आधुनिक AAA games हैं, तो capture card से PC का output लेना बेहतर है
2017 के आसपास macOS पर streaming मुश्किल थी, लेकिन अब M series हो तो पर्याप्त है
उम्मीद है कि इस सुधार से efficiency और बेहतर होगी
काश Apple Metal के बाहरी सफलता के उदाहरण बढ़ाने के लिए और resources लगाता
Apple के अंदरूनी उपयोग के बाहर Metal अभी तक बड़ी सफलता हासिल नहीं कर पाया है