SDL3 का नया GPU API मर्ज हो गया

 (github.com/libsdl-org)
1 पॉइंट द्वारा GN⁺ 2024-08-31 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • SDL3 का नया GPU API PR #9312 29 अगस्त 2024 को मर्ज हुआ, और SDL 3.0 के नज़दीक आने की स्थिति में अधिक समीक्षा पाने के लिए Refresh-आधारित अप्रोच को तेज़ी से आगे बढ़ाया गया
  • प्रस्ताव में MoonWorks के graphics component Refresh को SDL_gpu के अंतिम API उम्मीदवार के रूप में लेने की बात थी, जो Vulkan और PS5 graphics API को सपोर्ट करता है, और D3D11 deferred context सपोर्ट पर भी काम चल रहा था
  • API डिज़ाइन आधुनिक rendering model का उपयोग करता है, जिसमें काम को render pass, compute pass, और copy pass में बाँटा गया है, और resource write operations को frame के बीच dependency से बचाने के लिए अंदरूनी रूप से cycle किया जा सकता है
  • shader पक्ष में शुरुआती offline compilation-केंद्रित प्रस्ताव को runtime shader generation सपोर्ट की जाँच करने वाली दिशा में समायोजित किया गया, और backend-विशिष्ट IR format लेने वाली संरचना पर चर्चा हुई ताकि SDL खुद shader compiler को wrap न करे
  • मर्ज होने के तुरंत बाद API function names, build configuration macros, UTF-8 BOM, और D3D12 swapchain की 60 FPS सीमा जैसी बाद की समायोजन प्रक्रियाएँ जारी रहीं, और thatcosmonaut को commit access दे दिया गया

PR की शुरुआत और merge स्थिति

  • PR #9312, SDL_gpu के लिए जल्दी समीक्षा पाने हेतु नए GPU API प्रस्ताव के रूप में शुरू हुआ
    • SDL 3.0 के नज़दीक आने की स्थिति में इसका उद्देश्य जल्दी से “ज़्यादा लोगों की नज़र” हासिल करना था
    • 29 अगस्त 2024 को It's merged की पुष्टि के बाद इसे मर्ज कर दिया गया
  • मर्ज होने के तुरंत बाद कुछ समय के लिए बदलाव रोककर review और adjustment करने का अनुरोध किया गया
    • बाद में स्थिति everything is merged तक पहुँची, और बताया गया कि GPU-संबंधित बदलाव फिर से मर्ज किए जा सकते हैं
    • thatcosmonaut को incoming changes की समीक्षा करने की संभावना अधिक होने के कारण commit access में जोड़ा गया

Refresh-आधारित API उम्मीदवार

  • प्रस्ताव का केंद्र MoonWorks के graphics component Refresh को SDL_gpu के अंतिम API उम्मीदवार के रूप में लेना था
    • MoonWorks को FNA की तरह XNA का reimplementation नहीं, बल्कि XNA के उत्तराधिकारी के क़रीब एक प्रोजेक्ट के रूप में प्रस्तुत किया गया
    • Refresh, FNA3D से मिलता-जुलता है, लेकिन Vulkan जैसे आधुनिक API को लक्ष्य बनाता है
  • उस समय Refresh, Vulkan और PS5 graphics API को सपोर्ट करता था
    • D3D11 deferred context सपोर्ट पर काम जारी था
    • इसे PC और console पर Samurai Gunn 2 में production उपयोग में होने के रूप में पेश किया गया
  • PR लेखक ने thatcosmonaut को मुख्य संपर्क व्यक्ति बताया, और FNA core team के भी प्रक्रिया में शामिल रहने की बात कही

API डिज़ाइन और resource handling

  • API को deferred context-केंद्रित आधुनिक rendering API के रूप में बनाया गया है
    • काम render pass, compute pass, और copy pass में विभाजित है
    • बाकी API को binding, render, और compute dispatch calls के क़रीब एक मानक रूप बताया गया
  • resource पर लिखने वाले सभी operations, cycle के माध्यम से frame के बीच dependency से बच सकते हैं
    • GpuBuffers जैसे graphics resource handles, अंदरूनी resource references को cycle करने के लिए container की भूमिका निभाते हैं
    • बाद में cycle की अवधारणा को bool तक सरल किया गया, और कई WriteOptions enum हटा दिए गए
  • शुरुआत में AMD D3D11 driver से जुड़ी data API behavior समस्या के कारण कई WriteOptions enum मौजूद थे
    • यह समझाया गया कि D3D11 data API का AMD पर अपेक्षित रूप से काम न करना पूरी तरह bypass नहीं किया जा सका था
    • बाद में इस हिस्से को सरल बनाया गया और code में इसके व्यवहार को document किया गया

shader system पर चर्चा

  • शुरुआती shader समाधान shaderbuild.py नाम की एक script थी
    • यह client machine पर offline shader build tools के frontend की भूमिका निभाती थी
    • इसका ढाँचा कई formats को bundle करके हर render backend के अनुसार भेजने का था
  • इस तरीके को online shader compilation को न रोकने वाली डिज़ाइन के रूप में समझाया गया
    • बताया गया कि भविष्य में SDLSL source को binary में शामिल करके CreateShaderModule में ज़रूरत के backend bytecode में तुरंत बदला जा सकता है
    • public API को तोड़े बिना online compilation की अनुमति देना इसका लाभ बताया गया
  • बाहरी feedback में pure offline compilation के कुछ engines के लिए उपयुक्त न होने की चिंता सामने आई
    • यह भी कहा गया कि Python, glslc, और spirv-cross को PATH में install करना developers के लिए असुविधाजनक हो सकता है
    • यह राय भी आई कि SDL ecosystem में offline shader compilation tool को अलग satellite library के रूप में रखना अधिक स्वाभाविक हो सकता है
  • बाद में shader system को “raw” shader और “portable” shader में अंतर करने की दिशा में समायोजित किया गया
    • runtime shader generation सपोर्ट के stress test के रूप में FNA3D port का उपयोग किया गया
    • Vulkan में सीधे पास करने के लिए MojoShader SPIR-V emitter का उपयोग, और दूसरे backends में वैकल्पिक अलग library SDL_shader के ज़रिए conversion का ज़िक्र हुआ
    • लक्ष्य ऐसी संरचना बनाना था जिसमें SDL को यह जानने या परवाह करने की ज़रूरत न हो कि shader कहाँ से आया

backend और testing की प्रगति

  • शुरुआती Refresh-आधारित implementation की मज़बूती इस बात को माना गया कि Vulkan backend पहले से मौजूद था
    • यह राय थी कि Refresh 2.0 के आधार पर Vulkan backend की performance उच्च है
    • compute का first-class feature होना भी पुराने SDL_GPU draft की तुलना में एक महत्वपूर्ण अंतर माना गया
  • मार्च 2024 के अंत से अप्रैल की शुरुआत तक कई वास्तविक games के चलने के उदाहरण साझा किए गए
    • बताया गया कि यह offline shader compilation के बिना काम करने वाली स्थिति तक पहुँच गया था
    • Streets of Rage 4 के boot होने वाला current revision साझा किया गया
    • Wizorb, Metal पर चलाया गया
    • Celeste, trace database के काफ़ी हिस्से में in-game स्थिति तक पहुँच गई
  • feature additions भी साथ-साथ चलती रहीं
    • कहा गया कि hardware instancing सपोर्ट अगली push में जोड़ा जाएगा
    • बाद में instancing और occlusion queries जोड़ दिए गए, और बताया गया कि Metal पक्ष की implementation को अभी भरना बाकी है

review में सामने आए build, API, और platform मुद्दे

  • Vulkan include order की वजह से VkInstance, VkSurfaceKHR typedef redefinition errors आए
    • SDL_gpu_vulkan.c में Vulkan headers और SDL_vulkan.h के include order को बदलने वाला patch सुझाया गया
    • suitableQueueFamilyIndex के uninitialized रह जाने की warning को 0 initialization से शांत करने वाला patch भी सुझाया गया
  • dynapi update की ज़रूरत भी उठाई गई
    • बताया गया कि src/dynapi/ के नीचे gendynapi.py चलाने पर यह अपडेट हो जाएगा
    • साथ ही यह caveat भी था कि चलाते समय documentation missing warnings काफ़ी आती हैं
  • API function signatures में byte size type को size_t में बदलने का प्रस्ताव आया, लेकिन निष्कर्ष यह रहा कि GPU API में Uint32 ही रखा जाए
    • यह राय थी कि buffer size बहुत बड़ा होने पर 32/64-bit simultaneous compatibility मुश्किल हो सकती है
    • विकल्प के रूप में Uint64 की संभावना का ज़िक्र हुआ, लेकिन अंततः Uint32 बनाए रखने की राय दी गई

merge के बाद के adjustments

  • मर्ज के बाद #10622 में कई tweaks किए गए
    • बताया गया कि नए function names को beta users तक पहुँचाने के लिए पहले मर्ज किया जाएगा
    • build configuration में SDL_GPU_VULKAN SDL_VIDEO_VULKAN, SDL_GPU_METAL SDL_VIDEO_METAL जैसे मामलों में दाएँ वाले macro के defined होने की ज़रूरत वाली समस्या को #10622 में ठीक किया गया
    • GPU source files में UTF-8 BOM की समस्या भी #10622 में ठीक की गई
  • D3D12 में यह पाया गया कि D3D12_ClaimWindow() swapchain को VSYNC पर सेट कर देता है, जिससे testsprite 60 FPS तक सीमित हो जाता है
    • समझाया गया कि claim window चरण में SDR और VSYNC जैसे सार्वभौमिक रूप से supported parameters के साथ swapchain बनाना, फिर support query करने के बाद SetSwapchainParameters कॉल करना ही intended workflow है
    • render driver, claim के बाद SetSwapchainParameters कॉल कर रहा होने के बावजूद D3D12 driver में 60 FPS सीमा बनी रहने के कारण यह जाँच का विषय बना रहा

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

1 टिप्पणियां

 
GN⁺ 2024-08-31
Hacker News की राय

  • SDL3 अभी preview चरण में है, लेकिन नया GPU API main branch में merge हो चुका है और SDL3 maintainers अंतिम adjustments कर रहे हैं
    मेरी समझ में, इस नए GPU API की मुख्य बात यह है कि आप graphics code और shaders एक बार लिखें और वे console सहित कई platforms पर बिना ज्यादा झंझट के चल सकें। पहले इसके लिए Unity या Unreal, या फिर अपना custom solution चाहिए होता था
    WebGPU/WGSL भी ऐसा ही cross-platform graphics stack है, लेकिन जहां तक मुझे पता है, किसी ने console backend नहीं बनाया है। इसके उलट SDL3 GPU API अभी WebGPU को backend के रूप में support करता हुआ नहीं लगता

    • Unreal/Unity ही एकमात्र solution नहीं हैं। काफी लोकप्रिय bgfx(https://github.com/bkaradzic/bgfx) भी है, और मेरी जानकारी में sokol gfx(https://github.com/floooh/sokol) भी है। बेशक, कम चर्चित विकल्प भी और कई हैं
    • पहले मैंने graphics code और shaders को एक बार लिखने देने और consoles भी support करने वाले bgfx [1] को SDL2 stack और Swift [2] के साथ integrate करके देखा था। ऐसे tools कभी इस्तेमाल न करने वाले व्यक्ति के तौर पर भी अनुभव काफी अच्छा था
      SDL3 console abstraction लाता है, इसलिए GPU API के लिए अतिरिक्त dependency की जरूरत नहीं रहेगी, यह बात उत्साहित करती है। इसके अलावा Godot Steam Deck को officially support करता है, और उम्मीद है कि आगे और consoles भी support होंगे। इसी संदर्भ में Miguel de Icaza Godot में Swift अपनाने को आगे बढ़ा रहे हैं, और iPad पर editor को SwiftUI में port करने का काम भी कर रहे हैं। progress [3] दिलचस्प है
      [1] https://bkaradzic.github.io/bgfx/overview.html
      [2] https://github.com/bgbernovici/myndsmith
      [3] https://blog.la-terminal.net/xogot-code-editing/
    • यह बात भी उल्लेखनीय है कि Godot में भी cross-platform shaders हैं। GDShader भाषा OpenGL shader language पर काफी हद तक आधारित है, लेकिन उसकी 1:1 copy नहीं है, और target platform के अनुसार compile होती है। हालांकि PS5 और Xbox के लिए तीसरे पक्ष की कंपनियों के साथ सहयोग करना पड़ता है। Nintendo NDA पर sign करने वालों के लिए Nintendo builds जारी करने वाले लोग भी हैं
    • लेकिन SDL API की gfx-rs / wgpu से ज्यादा जरूरत क्यों है? सोच रहा हूं कि क्या एक और नया बनाने की जरूरत थी

  • अतिरिक्त context यहां है: https://icculus.org/finger/flibitijibibo?date=2024-06-15&time=13-14-16

  • उम्मीद है कि यह trend किस तरह जगह बनाता है, देखना दिलचस्प होगा। आखिरकार custom game engines और apps बनाने के लिए ज्यादा विकल्प मिलें तो अच्छा है
    हाल में मैं Vulkan में गहराई से उतर रहा हूं; सीखना मजेदार है और कई insights भी मिलती हैं, लेकिन Vulkan की प्रकृति के कारण progress धीमी महसूस होती है। अगर शुरुआत करते समय SDL3 मौजूद होता, तो शायद मैं खुशी से वही चुनता, और लगाए गए समय के मुकाबले दिखाने लायक नतीजे भी ज्यादा होते

  • यह API सच में उपयोगी होगा या नहीं, यह समय ही बताएगा। खासकर resource synchronization और object renaming का तरीका अहम होगा
    WebGPU या अन्य abstractions की तुलना में performance बेहतर होगी या नहीं, यह भी देखना होगा। driver bugs को work around करने वाली स्थितियों में भी यह छोटा बना रह पाएगा या नहीं, यह भी देखने वाली बात है
    shading language के लिए नए bytecode को लेकर भी मैं skeptical हूं। WebGPU में runtime shader parsing चिंता की बात नहीं थी और बहुत तेज है। native shader generation भी तेज है [1]। धीमी चीज pipeline creation है, और यह bytecode उसमें मदद नहीं करता
    [1] http://kvark.github.io/naga/shader/2022/02/17/shader-translation-benchmark.html

  • सोच रहा हूं कि यह इतनी जल्दी कैसे कर लिया गया. WebGPU native का development cycle लंबा रहा है और वह अभी भी final नहीं हुआ है, जबकि SDL GPU API ज्यादा platforms support करता है, इसलिए उल्टा इसे और ज्यादा समय लगना चाहिए था

    • WebGPU को ज्यादा समय इसलिए लगा क्योंकि SPIR-V का इस्तेमाल करने के बजाय उन्होंने अपनी shading language बनाने का फैसला किया. SDL ने वह गलती नहीं की, और shader compiler व conversion tools यूज़र पर छोड़ दिए
      cross-platform shading language के लिए एक sibling project [1] और मौजूदा languages को आपस में convert करने वाला एक और project [2] है, लेकिन वे जब तैयार होंगे तब होंगे; API के बाकी हिस्सों को उनका इंतज़ार करने की जरूरत नहीं है
      WebGPU vendors और language lawyers, या कहें standards lawyers की committee द्वारा politics और bureaucracy के बीच बनाया गया नतीजा है, और यह दिखता है. SDL_GPU को उन game developers ने बनाया है जो सबसे पहले practicality को महत्व देते हैं, और इसी वजह से उन्हें अक्सर ivory tower में कमतर समझा जाता है
      [1]: https://github.com/libsdl-org/SDL_shader_tools
      [2]: https://github.com/flibitijibibo/SDL_gpu_shadercross
    • SDL3 GPU project के core contributors को FNA3D और Refresh नाम की दो cross-platform GPU abstraction layers, यानी PC और consoles दोनों को target करने वाली layers, पर काम करने का अनुभव है. उस knowledge और मौजूदा open source code के आधार पर वे इसे तेजी से और अच्छी quality के साथ जोड़ पाए
    • क्योंकि कोई committee नहीं थी, और motivated developers थे जिन्हें अपने projects के लिए result चाहिए था. खासकर FNA वाले लोग
    • आसान है. SDL GPU ने उल्लू के बाकी हिस्से को, यानी common format के shaders को API-specific intermediate representations में convert करने वाले हिस्से को, बाहर छोड़ दिया

  • dx12 हिस्से में contribute करके खुशी हुई :)

    • अच्छा है. मैं modern HLSL को target करने वाला हूं, इसलिए शुरुआत में शायद वही backend इस्तेमाल करूंगा. उम्मीद है DXC अंत में ठीक-ठाक SPIR-V बना देगा
    • DX12 सीखने के लिए आप कौन से resources recommend कर सकते हैं?

  • शायद इसे कभी try करूंगा. मुझे हमेशा लगा है कि SDL quality software है. यह जल्दी compile होता है, कई platforms पर आसानी से compile होता है, और हमेशा ठीक काम करता है. इसलिए इस नए API से भी उम्मीदें हैं

  • कुल मिलाकर मैं SDL का बड़ा fan हूं
    जब मैं cross-platform game library ढूंढ रहा था, तो SDL और उसका API मुझे बिल्कुल सही balance लगा. मुझे बस एक C/C++ library चाहिए थी जिसे window और graphics context बनाने के लिए call कर सकूं, और fast sprite rendering framework चाहिए था. पूरी IDE या bloated library की जरूरत नहीं थी, और नई language सीखने का मन भी नहीं था

  • SDL3 में second system effect होता दिख रहा है. SDL2 तो explicit window handle वाले SDL1 के करीब था, इसलिए SDL3 तीसरा नहीं बल्कि second system है. SDL1/2 ऐसे thin layers थे जो window खोलने और input events handle करने वाले platform-specific boilerplate को wrap करते थे, ताकि आप जल्दी से उस OpenGL rendering code में पहुंच सकें जिसे सच में लिखना चाहते थे

    • अगर सिर्फ Windows/Linux/Android support करने हैं, तो कहा जा सकता है कि SDL GPU API बेवजह bloated है
      लेकिन अगर Apple operating systems भी support करने हैं, तो आप OpenGL 4.1 तक बंध जाते हैं. Apple ने इसे 5 साल पहले officially deprecated mark कर दिया था, इसलिए compute shaders जैसी modern GPU features इस्तेमाल नहीं कर सकते
      Vulkan route लेकर Apple systems पर MoltenVK इस्तेमाल किया जा सकता है, लेकिन Vulkan की complexity OpenGL से काफी ज्यादा है. जैसा लोग अक्सर कहते हैं, “एक triangle के लिए code की 1000 lines” जैसा. SDL3 के GPU API का लक्ष्य ज्यादा approachable और फिर भी पर्याप्त flexible alternative देना है
      consoles के लिए भी शायद यही कहानी होगी
      बताया जाता है कि बहुत लोगों ने request किया था, “क्या SDL_render जैसा कुछ दे सकते हैं, लेकिन सभी platforms पर चलने वाला shader support जोड़कर,” और वही starting point था
      SDL3 एक higher-level audio API भी जोड़ता है, लेकिन उसके फायदे मुझे ठीक से नहीं पता
    • SDL2 सिर्फ “explicit window handle वाला SDL1” नहीं था. पूरे API में कई बदलाव और नए features थे, और SDL3 की तरह graphics subsystem में भी बड़ा बदलाव था. SDL1 software rendering इस्तेमाल करता था, और SDL2 ने hardware acceleration जोड़ा
      साथ ही SDL2, 2.0.0 के बाद काफी evolve हुआ, और SDL3 API compatibility तोड़ने वाले changes की अनुमति देते हुए उसी evolution को आगे बढ़ाता है. SDL3 को scratch से फिर से नहीं लिखा गया है, और SDL user के नजरिए से SDL2 से SDL3 पर जाना इतना मुश्किल नहीं होगा
      और SDL1/2 भी इतने “सिर्फ thin” कभी नहीं थे कि उनका अपना higher-level graphics system न हो. नए users या basic users के लिए सीधे screen पर कुछ दिखा पाने की built-in सुविधा उपयोगी होती है
      जैसा ahefner ने बताया, SDL1 modern standards से काफी “thin” था, लेकिन बिना खुद pixel math लिखे screen पर basic चीजें draw करने लायक सुविधा देता था, और 90s में वह काफी मददगार था
    • समस्या यह है कि OpenGL लगभग मर चुका है, और ease of use के मामले में Vulkan, OpenGL का poor replacement है
    • render API भी पहले से ही कई SDL users के लिए अनावश्यक bloat था. binary size के मामले में SDL2 भी SDL1 से पहले ही काफी बड़ा हो गया था
      फिर भी यह abstraction साधारण 2D games से आगे की जरूरतें पूरी करते हुए, दुर्भाग्य से लगातार fragmented होते graphics API ecosystem को target करना संभव बना सकती है. universal OpenGL(Next) future का सपना खत्म हो चुका है. हालांकि सबसे मुश्किल हिस्सा, shader conversion, अभी भी मौजूद नहीं दिखता

  • मैंने यह library कभी इस्तेमाल नहीं की, लेकिन अगर linked thread से मेरी समझ सही है, तो अब मिलने वाली cross-platform GPU compute functionality के examples देखना चाहूंगा. कहां से शुरू करना अच्छा रहेगा, इस पर कोई recommendation है?