Graphics API की ज़रूरत न रहने वाले युग की ओर

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

[GN⁺]

Hacker News की राय

• यह लेख Vulkan और DX12 के अनावश्यक हिस्सों को बहुत अच्छी तरह दिखाता है
  आजकल DX12 तो buffer pointer तक सपोर्ट नहीं करता, इसलिए वह लगभग उपेक्षित-सा लगता है, और Vulkan भी 2.0 में साफ-सुथरा नहीं हुआ, इसलिए ऐसे कई driver हैं जिनमें extension features ठीक से implement नहीं हैं
  अगर ऐसा कोई नया API मौजूद हो, तो उसके ऊपर OpenGL को कहीं ज्यादा तेज़ी से emulate किया जा सकता है, और SDL3 GPU जैसी चीज़ों में भी शायद 3~4 गुना performance improvement मिल सकता है

  • मौजूदा DirectX documentation की स्थिति बहुत खराब है
    Frank Luna की किताब भी नए features को cover नहीं करती, इसलिए Learn site, GitHub samples और reference docs सब खंगालने पड़ते हैं
    Vulkan भी इसी तरह जटिल है, और भले ही 2.0 आ जाए, खासकर Android जैसे बड़े platform पर उसे वास्तव में कैसे इस्तेमाल किया जा सकेगा, यह सवाल बना रहता है
  • मुझे लगता है कि यह सब कहीं न कहीं PCI Resizable BAR requirement की वजह से हो सकता है
    Intel Arc को छोड़ दें तो ज़्यादातर GPU reBAR के बिना भी चल जाते हैं, लेकिन शायद Microsoft या Intel को इसे UEFI में अनिवार्य करना होगा, तभी bindless texture जैसी सुविधाओं का स्थिर रूप से इस्तेमाल हो पाएगा
    लेकिन इस स्थिति में supported hardware की एक न्यूनतम सीमा बन जाएगी, और 2020 से पहले के motherboard में support भी काफ़ी असंगत है

• लेख की मुख्य प्रेरणा गायब है
  blog index के मुताबिक, “पिछले 10 वर्षों में graphics API और shader language की जटिलता तेज़ी से बढ़ी है, और अब abstraction layer को सरल बनाकर development efficiency और performance बढ़ानी चाहिए, साथ ही भविष्य के GPU workloads के लिए तैयार होना चाहिए” — यही इसका आशय है

  • यह कुछ-कुछ NVMe के आने की वजह जैसा है
    शुरुआत में SSD ने IDE/SATA interface का ही पुन: उपयोग किया, लेकिन rotating disk वाली धारणाओं को छोड़कर नया transfer तरीका बनाना पड़ा, तभी असली performance मिल सकी
    graphics API के लिए भी यह वैसा ही रूपक लगता है कि अब legacy constraints छोड़ने का समय आ गया है

• मैं Sebastian Aaltonen के काम को लंबे समय से देखता आया हूँ, इसलिए शायद थोड़ा पक्षपाती हो सकता हूँ, लेकिन यह लेख सचमुच शानदार है
  मुझे लगता है कि आगे की दिशा software rendering की ओर वापसी है
  फर्क सिर्फ इतना है कि इस बार उसके algorithm और data structure को hardware acceleration मिलेगा
  VFX industry में यह रुझान पहले से चल रहा है, और लगभग 5 साल पहले OTOY द्वारा OctaneRender को CUDA-आधारित रूप में port करना भी इसका एक उदाहरण है

  • GPU के अंदर fixed-function hardware बहुत होता है, इसलिए उसे हटा देने पर performance काफ़ी गिर जाएगी
    shader types इन pipelines के बीच की कड़ी का काम करते हैं, इसलिए पूरी तरह software-based होना व्यावहारिक नहीं है
  • सच कहें तो ऐसा बदलाव कुछ हद तक पहले से हो रहा है
    उदाहरण के लिए Unreal Engine का Nanite, छोटे triangles को process करते समय GPU के compute shader पर चलने वाला software rasterizer इस्तेमाल करता है

• लेख की detail बहुत प्रभावशाली थी
  मैं उसका सिर्फ कुछ हिस्सा ही समझ पाया, लेकिन लगता है कि यह आगे चलकर graphics API design के लिए reference बन सकता है
  ज़्यादातर gamers के लिए Vulkan/DX12 से बहुत बड़ा फायदा नहीं हुआ, और PSO समस्याओं की वजह से कई games को दिक्कत हुई
  Vulkan में सुधार हो रहा है, लेकिन WebGPU ने शुरुआती Vulkan design की सीमाएँ लगभग जस की तस विरासत में ली हैं
  जब hardware इतनी तेज़ी से बदल रहा हो, तब शायद बहुत low-level API की ओर जाना गलती रही होगी
  हो सकता है CUDA जैसा general-purpose computing केंद्रित approach ही बेहतर दिशा हो

• Mantle की याद आती है
  उसकी कमियाँ थीं, लेकिन hardware को सीधे संभालने जैसा एहसास था, और Xbox 360 development के समय सबसे ज़्यादा मज़ा आता था

  • Switch का graphics API भी उसी तरह बेहतरीन है
    उसे Nvidia और Nintendo ने design किया था, और मुझे लगता है कि consoles में वही सबसे intuitive API है

• यह लेख पढ़कर ऐसा लगा जैसे किसी ऐतिहासिक क्षण का साक्षी बना हूँ

• इससे जुड़ा हुआ प्रोजेक्ट लगता है: Google Toucan

• इस लेख ने बहुत-सी पुरानी यादें ताज़ा कर दीं
  API designers जिन अतिरिक्त बातों पर विचार करते हैं, उनमें शामिल हैं

  • GPU virtualization — कई applications को GPU resources साझा करने देने की क्षमता (उदाहरण: D3D residency API)
  • undefined behavior — अगर applications अनजाने में इस पर निर्भर हो जाएँ, तो नए API पर port करना मुश्किल हो जाता है

• समझ नहीं आता कि Microsoft नया DirectX version क्यों नहीं लाता
  DirectX Ultimate या 12.2 भी असल में DX12 ही हैं
  क्या Unreal Engine जैसे middleware के प्रभाव से अपने API का महत्व घट गया है, या फिर EPIC को नया API प्रस्तावित करना चाहिए — ऐसा सोचता हूँ

  • ऐसी चर्चा ज़्यादातर FOSS community में ही सक्रिय रहती है
    असली game developers तो RHI(Rendering Hardware Interface) बनाकर game development पर ध्यान देते हैं
    ray tracing और mesh shader सबसे बड़े innovations थे, लेकिन उनका उपयोग अब भी कम है, इसलिए लगता है कि बात आगे नहीं बढ़ रही
  • कुछ हद तक दोनों बातें सही हैं
    Unreal, Unity जैसे engines के centralization की वजह से API innovation में रुचि कम हुई है, और प्रगति मुख्यतः GPU पक्ष में ही जारी है
    CPU API अब भी बस साधारण buffer mapping के स्तर पर है
    शायद फिर से वैसी ही प्रगति के लिए, जैसी पहले tessellation shader आने पर हुई थी, कोई नया hardware बदलाव ज़रूरी होगा

• सोचता हूँ कि क्या Valve कभी SteamOS के लिए अपना graphics API बना सकता है

  • सच तो यह है कि Vulkan की जटिलता के लिए Valve भी कुछ हद तक ज़िम्मेदार है
    मैंने सुना है कि Vulkan के शुरुआती development phase में Valve प्रमुख प्रेरक शक्तियों में से एक था