- पिछले 10 वर्षों में DirectX 12, Vulkan, Metal जैसे लो-लेवल graphics API ने GPU प्रदर्शन को बढ़ाया है, लेकिन इनके साथ जटिलता और मेंटेनेंस लागत भी तेज़ी से बढ़ी है
- आधुनिक GPU अब पूर्ण cache hierarchy, 64-bit pointer, bindless resource को सपोर्ट करते हैं, जिससे पुराने जटिल state object और binding model अनावश्यक हो गए हैं
- प्रस्तावित डिज़ाइन C/C++ pointer-आधारित memory access और एकल 64-bit root pointer का उपयोग करके rendering pipeline को बहुत सरल बनाता है
- यह PSO explosion, resource barrier, जटिल binding API को हटाकर GPU memory और shader language को सीधे जोड़ने वाली संरचना पेश करता है
- यह दृष्टिकोण आधुनिक GPU architecture के लिए optimized अगली पीढ़ी का API है, और DirectX 13 या Vulkan 2.0 को किस दिशा में जाना चाहिए, यह दिखाता है
लो-लेवल graphics API में बदलाव
- 2013 में Xbox One और PS4 की AMD GCN architecture AAA गेम डेवलपमेंट का मानक बन गई, और Mantle·DirectX 12·Vulkan·Metal जैसे लो-लेवल API सामने आए
- यानी इन्हें 2013 के आसपास की GPU architecture को आधार बनाकर डिज़ाइन किया गया था
- पहले के DirectX 11/OpenGL single-thread rendering और ऊँचे driver overhead के कारण सीमित थे
- इन API ने precompiled pipeline object (PSO) के जरिए draw call लागत कम की, लेकिन engine structure से मेल न खाने के कारण जटिलता बढ़ गई
- नतीजतन engine के भीतर एक और “low-level driver layer” बन गई, और graphics programmer की भूमिका और अधिक विभाजित हो गई
ऐतिहासिक पृष्ठभूमि: यह इतना जटिल क्यों हो गया
- शुरुआती GPU अलग memory और fixed-function pipeline पर केंद्रित संरचना रखते थे
- OpenGL·DirectX ने hardware diversity abstraction के लिए state-based और object-based डिज़ाइन अपनाया
- DirectX 11 तक भी texture और buffer को opaque descriptor के रूप में मैनेज किया जाता था
- यही डिज़ाइन बाद की API तक भी जड़ता की तरह बना रहा
आधुनिक GPU और API के बीच असंगति
- आज के GPU सुसंगत cache hierarchy, PCIe ReBAR, 64-bit pointer, bindless texture को सपोर्ट करते हैं
- CPU का GPU memory में सीधे लिखना और GPU का उसे तुरंत पढ़ना संभव है
- ऐसे माहौल में PSO, descriptor set, binding table जैसी संरचनाएँ अनावश्यक हो जाती हैं
- PSO cache के विस्फोटक बढ़ाव के कारण सैकड़ों GB cache की ज़रूरत पड़ती है, जो loading delay और stuttering का कारण बनता है
- नया API इन पुराने ढाँचों को हटाकर सरल pointer-आधारित access पर जा सकता है
GPU memory management का सरलीकरण
- मौजूदा Vulkan/DirectX 12 में resource creation के बाद heap compatibility query करनी पड़ती है, जो अक्षम है
- प्रस्तावित तरीका gpuMalloc/gpuFree जैसे सरल API से GPU memory सीधे allocate करता है
- CPU सीधे GPU memory को map करके initialize कर सकता है
- बड़े डेटा को copy command से भेजकर DCC compression और swizzle processing किया जा सकता है
- CPU mapping address और GPU address को अलग रखा जाता है, और gpuHostToDevicePointer से रूपांतरण किया जाता है
डेटा और shader language का आधुनिकीकरण
- CUDA·Metal·OpenCL की तरह C/C++ pointer-आधारित shader language का उपयोग किया जाता है
- struct-स्तर के wide load (128-bit या अधिक) के जरिए कुशल memory access संभव है
- DirectX का ByteAddressBuffer या texel buffer अब सर्वोत्तम विकल्प नहीं हैं
- GLSL/HLSL में pointer सपोर्ट न होने से reusable shader library ecosystem नहीं बन पाया, जबकि CUDA समृद्ध लाइब्रेरी के साथ विकसित हुआ
root argument और data structure
- GPU kernel एकल 64-bit pointer इनपुट के रूप में लेकर उसे struct में cast करता है
- CPU और GPU एक ही C/C++ header साझा करते हैं, जिससे data structure की consistency सुनिश्चित होती है
- const/restrict keyword से compiler optimization को बढ़ावा मिलता है और अनावश्यक UBO/SSBO विभाजन हट जाता है
- आधुनिक GPU के scalar register preloading और dynamic uniform optimization का लाभ लिया जाता है
texture binding का सरलीकरण
- सभी texture को 256-bit descriptor array (heap) में मैनेज किया जाता है, जिसे CPU और GPU सीधे लिख सकते हैं
- 32-bit index-आधारित access से non-uniform texture sampling सपोर्ट होता है
- यह DirectX 12 SM 6.6 के descriptor heap से सरल है, और Vulkan VK_EXT_descriptor_buffer जैसा है
- texture object creation, upload और sampling सब कुछ GPU memory pointer-आधारित मॉडल में एकीकृत हो जाता है
shader pipeline और constant
- pipeline creation केवल shader IR load करने के बाद gpuCreatePipeline call करने जितना सरल है
- root signature, descriptor set, binding definition की ज़रूरत नहीं रहती
- static constant (struct-आधारित) के जरिए shader specialization constant को बदला जा सकता है, जिससे PSO combination explosion की समस्या कम होती है
- constant struct में GPU pointer भी शामिल किए जा सकते हैं, जिससे runtime address को सीधे hardcode किया जा सकता है
barrier और synchronization का सरलीकरण
- मौजूदा API की resource-स्तर barrier list आधुनिक GPU संरचना से मेल नहीं खाती
- प्रस्तावित मॉडल में सिर्फ queue/stage-स्तर bitfield flag का उपयोग होता है
- gpuBarrier(before, after, hazard) रूप में सरलीकरण किया गया है, और resource tracking की ज़रूरत नहीं रहती
- gpuSignalAfter / gpuWaitBefore कमांड से timeline semaphore जैसे GPU→GPU synchronization को लागू किया जा सकता है
command buffer और rendering
- केवल one-shot (transient) command buffer का उपयोग किया जाता है, जिससे Vulkan का जटिल reuse model हट जाता है
- gpuBeginRenderPass / gpuEndRenderPass से render target सेटअप और clear किया जाता है
- render pass के बीच कोई automatic barrier नहीं होती, इसलिए parallel rendering और depth prepass optimization संभव है
raster pipeline का सरलीकरण
- vertex/pixel shader pointer-आधारित data access से binding API को हटा देते हैं
- GpuDepthStencilState, GpuBlendState को PSO से अलग करके combinations की संख्या घटाई जाती है
- mobile GPU में framebuffer fetch intrinsic से programmable blending सपोर्ट होता है
- PSO में केवल न्यूनतम state (topology, format, sample count आदि) शामिल होते हैं
indirect draw और GPU-driven rendering
- सभी argument (data, arguments) GPU pointer के रूप में पास किए जाते हैं
- gpuDrawIndexedInstancedIndirectMulti से multi-draw सपोर्ट मिलता है
- GPU सीधे root data और draw argument बना सकता है, जिससे पूर्ण GPU-driven rendering संभव होती है
tooling और compatibility
- pointer-आधारित संरचना को CUDA/Metal debugger की तरह symbol information के जरिए trace किया जा सकता है
- virtual memory से सुरक्षा बनी रहती है, इसलिए कोई सुरक्षा समस्या नहीं होती; गलत access पर page fault होता है
- MoltenVK, Proton जैसे उदाहरणों की तरह मौजूदा DirectX/Vulkan/Metal API को translation layer के रूप में compatible बनाया जा सकता है
न्यूनतम विनिर्देश और निष्कर्ष
- Nvidia Turing(2018), AMD RDNA1(2019), Intel Xe1(2022), Apple M1(2020) आदि सभी प्रस्तावित फीचर को सपोर्ट करते हैं
- आज के GPU पहले ही bindless·64-bit pointer·coherent cache संरचना में बदल चुके हैं
- सिर्फ API ही अतीत की abstraction में फँसा हुआ है
- नया API DirectX 11 से सरल, Vulkan से तेज़, और Metal से अधिक लचीला है
- अगली पीढ़ी के Vulkan 2.0 / DirectX 13 को ऐसे पूरी तरह bindless डिज़ाइन की ओर बढ़ना चाहिए, और HLSL/GLSL की जगह C/C++ pointer-आधारित shader language के जरिए ecosystem का विस्तार करना चाहिए
अभी कोई टिप्पणी नहीं है.