AMD की CDNA 3 कंप्यूट आर्किटेक्चर

AMD के CDNA compute GPUs और RDNA gaming GPUs में विभाजन पर यह बहस छिड़ती है कि क्या कंपनी ने specialized hardware की खोज में एक unified software ecosystem का त्याग कर दिया। टिप्पणीकार AMD के fragmented, अक्सर fragile ROCm और OpenCL support की तुलना Nvidia की दीर्घकालिक CUDA strategy से करते हैं, और तर्क देते हैं कि consistent tooling और backward compatibility—not raw FLOPS—ने Nvidia को AI और HPC markets में जीत दिलाई। कुछ लोग high-end consumer Radeons के लिए हालिया ROCm support में आशा देखते हैं, लेकिन कई मानते हैं कि AMD के देर से और असंगत software focus ने Nvidia को mindshare का एक महत्वपूर्ण दशक सौंप दिया।

AMD GPU आर्किटेक्चर: CDNA बनाम RDNA

  • AMD ने GPU विकास को CDNA (compute/HPC) और RDNA (graphics) में विभाजित किया, GCN को CDNA में विकसित किया और graphics को RDNA में पुनर्गठित किया।
  • CDNA graphics-केंद्रित units (जैसे render outputs) को हटा देता है या न्यूनतम करता है, compute में उत्कृष्ट है, और कई Top500 सुपरकंप्यूटरों को शक्ति देता है।
  • RDNA gaming के लिए optimized है: पुराने GCN की तुलना में बेहतर raster performance, कम power और die size (जैसे RX 5700 XT बनाम Radeon VII), लेकिन compute-oriented features के लिए कमजोर।
  • कुछ लोगों का तर्क है कि यह विभाजन compute को अलग-थलग करता है और mindshare को नुकसान पहुँचाता है; अन्य कहते हैं कि gaming और HPC में प्रतिस्पर्धी होने के लिए specialization आवश्यक थी।

ROCm और Software Ecosystem

  • ROCm वर्तमान में PTX-जैसे bytecode के बजाय प्रति-architecture GPU machine code ship करता है, जिससे सभी libraries के लिए architecture-specific binaries की आवश्यकता होती है और package size बढ़ जाता है।
  • छोटे ISA variants (जैसे gfx1030 बनाम gfx1031) support को जटिल बनाते हैं; workarounds और लंबी अवधि के “family ISA” approaches मौजूद हैं, लेकिन वे धीरे-धीरे आ रहे हैं।
  • कई पोस्ट करने वाले ROCm को fragile बताते हैं: सीमित GPU/OS support, दर्दनाक installs, segfault करने वाले demos, और प्रभावी रूप से abandoned issue trackers।
  • कुछ users असमर्थित consumer cards पर छोटे environment hacks के साथ सफलता की रिपोर्ट करते हैं, लेकिन यह unofficial और brittle है।

NVIDIA और CUDA के साथ तुलना

  • generations और products के पार CUDA की consistency को NVIDIA का मुख्य moat माना जाता है: consumer और data center GPUs पर वही API, backward-compatible PTX के साथ।
  • NVIDIA को “software-first” के रूप में चित्रित किया गया है, जो जल्दी (CUDA 2007 से) और लगातार tools, docs, और libraries में निवेश करता रहा है।
  • AMD की आलोचना की जाती है कि उसने पुराने APIs (जैसे OpenCL implementations) को छोड़ दिया, ecosystems को बार-बार reset किया, और ROCm support को घुमाया, जिससे अविश्वास पैदा हुआ।
  • raw FLOPs बनाम real-world performance पर बहस है; tensor cores और specialized matrix units simple TFLOP comparisons को भ्रामक बनाते हैं।

Open Standards और Alternative Stacks

  • OpenCL को एक “betrayed” standard माना जाता है: C99 पर अटका हुआ, AMD/Intel द्वारा खराब समर्थित, और NVIDIA द्वारा अनदेखा किया गया।
  • SYCL/oneAPI को अधिक open बताया गया है, multi-vendor governance के साथ; Mesa/RustiCL और Vulkan/D3D backends मौजूद हैं लेकिन अपरिपक्व या niche हैं।
  • कुछ लोग PTX/MSIL जैसी cross-vendor GPU IR की मांग करते हैं; अन्य SPIR-V जटिलताओं और Vulkan/OpenCL models के बीच अंतर की ओर इशारा करते हैं।

Consumer & Hobbyist Compute Path

  • AMD consumer GPUs, खासकर APUs और पुराने cards पर, मजबूत, official compute support की कमी को developers को seed करने का एक बड़ा खोया हुआ अवसर माना जाता है।
  • कई लोगों का तर्क है कि consumer hardware पर students और hobbyists आज के HPC buyers बनते हैं; उन्हें नज़रअंदाज़ करने से यह funnel CUDA और, increasingly, Apple/Metal को मिल गया।

Architecture & Terminology Side Threads

  • चर्चा में VLIW history (Itanium, DSPs, पुराने AMD GPUs), modern GPUs में dual-issue trends, और wide in-order parallelism के घटते returns पर बात होती है।
  • GPU memory strategies (large register files, shared/local memory, big caches, latency hiding via massive parallelism) की तुलना CPU cache hierarchies से की जाती है।
  • कुछ लोग “compute” को संज्ञा के रूप में लेकर शिकायत करते हैं; अन्य बताते हैं कि यह कम-से-कम early cloud services और modern AI से common रहा है।