• पिछले 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 का विस्तार करना चाहिए

अभी कोई टिप्पणी नहीं है.

अभी कोई टिप्पणी नहीं है.