क्या Microsoft से बेहतर DirectX shader compiler बनाना?

मूल लेख ↗ Hacker News चर्चा ↗

Microsoft के DirectX shader compiler और DXIL “signing” को reimplement करने के एक open-source प्रयास पर ध्यान इसलिए जा रहा है क्योंकि इससे Microsoft का proprietary `dxil.dll` ship करने की ज़रूरत खत्म हो सकती है, जो फिलहाल Godot engine और cross-platform tooling जैसे projects को जटिल बनाती है। Commenters बताते हैं कि Direct3D, Vulkan, और Metal के बीच shader compilation एक fragile, vendor-controlled mess है, और Mach/Zig का cross‑API, cross‑OS shader toolchain बनाने का काम game development के लिए संभावित रूप से transformative हो सकता है। चर्चा में legal और licensing constraints, opaque DLLs के बजाय source-available infrastructure के फायदे, और Wine/Proton जैसी layers का Linux gaming के लिए de facto stability और compatibility target बन जाना भी शामिल है.

Godot, dxil.dll, और लाइसेंसिंग

  • Godot की D3D12 support Microsoft के proprietary dxil.dll पर निर्भर है, जो closed-source components शिप न करने के उसके लक्ष्य से टकराता है।
  • कुछ users का तर्क है कि end-users “बस चीज़ों का काम करना” चाहते हैं और उन्हें फर्क नहीं पड़ता कि drivers/libraries proprietary हैं; जबकि अन्य proprietary drivers और blobs से बचने को प्राथमिकता देते हैं।
  • proprietary हिस्सा खास तौर पर dxil.dll/libdxil.so “signing” library है, जो अलग license के साथ binary blob के रूप में ship होती है; इसका source DXC repo में नहीं है।
  • legal constraints (जैसे click-through requirements, non-redistributable terms) को असली blocker के रूप में ज़ोर दिया गया है, सिर्फ ideology के रूप में नहीं।

Cross-API shader compilation और Mach/Zig

  • Direct3D, Vulkan, और Metal के बीच underlying shader ecosystem को एक mess बताया गया है, खासकर cross-compilation के लिए।
  • Metal shader compilation Apple के proprietary compilers के पीछे locked है, जो केवल macOS और हाल ही में Windows पर उपलब्ध हैं; Linux hosts बिना reverse engineering के सीधे Metal target नहीं कर सकते।
  • Mach की यह vision कि Zig को cross-API shader compiler और toolchain के रूप में इस्तेमाल किया जाए, यदि यह Zig की cross-compilation कहानी जैसी polish तक पहुँचती है, तो उसे संभावित रूप से transformative माना गया है।

Microsoft incentives और platform dynamics

  • कुछ लोग तर्क देते हैं कि Microsoft के पास software सुधारने की बहुत कम प्रेरणा है क्योंकि उसकी dominance और lock-in है; दूसरे कहते हैं कि internal game studios इन tools पर निर्भर हैं, इसलिए quality मायने रखती है।
  • Valve के Proton/Wine पर लंबी बहस:
    • एक पक्ष कहता है कि Proton native Linux ports को हतोत्साहित करता है क्योंकि इससे “Windows-only” पर्याप्त target बन जाता है।
    • दूसरा पक्ष कहता है कि Proton ही Linux पर gaming को संभव बनाता है, क्योंकि ABI stability कमज़ोर है और fragmentation बहुत है (glibc versions, graphics stacks, Wayland, आदि)।
  • कई comments Win32 को Wine के माध्यम से Linux पर long-term-stable binary graphics API के रूप में देखते हैं।

DXIL “signing” और reverse engineering

  • DXIL “signing” step को security theater कहा गया है; दूसरे graphics APIs इसके बिना काम करते हैं।
  • recreated signing एक हल्का-सा modified MD5-style hash प्रतीत होता है; similar implementations पहले से मौजूद थीं (जैसे debugging tools में)।
  • यह speculation भी है कि author ने legal deniability बनाए रखने के लिए RE process को स्पष्ट रूप से describe करने से परहेज़ किया, हालांकि अन्य लोग नोट करते हैं कि interoperability-focused RE आम तौर पर defensible है।

SPIR-V, shader languages, और toolchains

  • कुछ लोग HLSL/GLSL → SPIR-V ↔ DXIL जैसी pipeline का समर्थन करते हैं, जहाँ SPIR-V को common IR के रूप में उपयोग किया जाए।
  • SPIR-V→DXIL conversion में रुचि है (Mesa का spirv2dxil mention किया गया), और DXIL→SPIR-V (vkd3d) पहले से मौजूद है।
  • एक commenter गंभीरता से यह प्रस्ताव देता है कि shaders सीधे SPIR-V में लिखे जाएँ ताकि cross-driver predictability बेहतर हो, भले ही authoring cost अधिक हो।
  • LLVM/C++ dependency “bloat” को लेकर frustration व्यक्त की गई है, और plain C99-based, सरल compilers की इच्छा जताई गई है।

dxil.dll ship करना बनाम open implementation

  • कुछ लोग नोट करते हैं कि कई games पहले से ही बहुत सारी proprietary DLLs ship करते हैं, इसलिए dxil.dll जोड़ना व्यवहारिक रूप से ठीक लगता है।
  • जवाब में कहा गया:
    • size और dependency bloat छोटे games/tools के लिए मायने रखते हैं।
    • binary-only deps toolchain upgrades, cross-compiling, और नए hosts/targets पर porting को जटिल बनाती हैं।
    • हर चीज़ का source होना अधिक नियंत्रण और लंबे समय की कम integration headaches देता है।

अन्य संबंधित विषय

  • SDL SDL_gpu पर काम कर रहा है, जो एक cross-platform graphics abstraction और shader layer है; WebGPU से तुलना में WebGPU की complexity और web-security overhead को लेकर चिंताएँ उठती हैं।
  • Apple Silicon पर Wine के जरिए Halo CE के खराब चलने की रिपोर्ट्स के बाद Apple के Game Porting Toolkit (D3D→Metal) को आज़माने के सुझाव दिए गए।
  • कई comments Mach/Zig ecosystem की प्रशंसा करते हैं (जैसे mach-sysgpu/WebGPU reimplementation) और बेहतर graphics tooling सक्षम करने वाले general “infrastructure work” की तारीफ़ करते हैं।
  • Microsoft के DXC fork ने कहा जाता है कि LLVM की codegen के कुछ हिस्सों को नुकसान पहुँचाया; Microsoft ने स्पष्ट रूप से कहा है कि वे DXC में DXBC generation वापस नहीं लाएँगे और संभवतः बाद में upstream Clang में इसे support करेंगे, जबकि फिलहाल DXIL और SPIR-V पर ध्यान देंगे।