1 पॉइंट द्वारा GN⁺ 2023-12-19 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • AMD CDNA 3 एक compute GPU आर्किटेक्चर है, जिसका लक्ष्य उन कमियों को दूर करना है जहाँ CDNA 2 ने FP64 supercomputing में तो अच्छा प्रदर्शन किया, लेकिन H100 की तुलना में AI performance और integrated GPU scale में पीछे रह गया
  • MI300X, 8 XCD में कुल 304 Compute Unit को एक single GPU की तरह expose करता है, जिससे MI250X की तरह दो GPU और अलग-अलग memory pool में काम बाँटने का बोझ कम होता है
  • memory hierarchy को 256MB Infinity Cache, प्रति XCD 4MB L2, और CU के पास 32KB L1 के रूप में फिर से बनाया गया है; यह theoretically 17.2TB/s cache bandwidth देता है, लेकिन unified memory configuration में die-to-die link bottleneck बन सकता है
  • execution units में FP32 utilization बढ़ाने के लिए dual issue के करीब संरचना और प्रति SIMD track किए जा सकने वाले thread count में बढ़ोतरी लाई गई है, और matrix operation throughput भी पिछली CDNA generation की तुलना में प्रति CU 2 गुना बढ़ा है
  • CDNA 3 में मुख्य बदलाव memory hierarchy और packaging हैं, और MI300X को काफी बढ़ी हुई Infinity Fabric bandwidth के साथ इस तरह design किया गया है कि कई chiplet एक बड़े accelerator जैसे दिखें

CDNA 3 जिस gap को target करता है

  • AMD ने GPU compute market में Nvidia को पकड़ने के लिए Terascale 3, GCN, और CDNA/RDNA separation से गुजरते हुए architecture को विकसित किया है
  • CDNA 2 आधारित MI250X और MI210 ने ORNL के Frontier सहित कई supercomputer contracts हासिल किए, और Frontier ने नवंबर 2023 में TOP500 में पहला स्थान पाया
  • CDNA 2 ने FP64 compute में मजबूत और cost-effective performance दिया, लेकिन H100 बेहतर AI performance और बड़ा integrated GPU प्रदान करता है
  • CDNA 3 को AMD की advanced packaging, Infinity Fabric, RDNA series के Infinity Cache, और improved Compute Unit को जोड़कर इस gap को कम करने की दिशा में design किया गया है

MI300X का GPU layout

  • MI300X एक chiplet structure इस्तेमाल करता है जिसमें compute को Accelerator Complex Die(XCD) में अलग किया गया है
    • XCD, CDNA 2/RDNA 3 के Graphics Compute Die(GCD) और Ryzen के Core Complex Die(CCD) जैसी भूमिका निभाता है
    • CDNA products में RDNA series के dedicated graphics hardware नहीं होते, इसलिए लगता है AMD ने नाम बदल दिया है
  • हर XCD में physically 40 CDNA 3 Compute Unit हैं, और MI300X में प्रति XCD 38 active होते हैं
    • एक XCD में 4MB L2 cache है, जिसे उस die के सभी CU इस्तेमाल करते हैं
    • MI300X, 8 XCD के जरिए कुल 304 Compute Unit प्रदान करता है
  • यह MI250X के 220 CU से काफी ज्यादा है, और MI300X इन CU को single GPU के रूप में expose कर सकता है
    • MI250X में हर GPU का अपना अलग memory pool था, इसलिए programmers को दो GPU में काम खुद बाँटना पड़ता था
  • Nvidia H100, 132 Streaming Multiprocessor(SM) को एक unified GPU के रूप में expose करता है, लेकिन compute को बड़े single die पर implement करने का traditional तरीका इस्तेमाल करता है
    • H100, L2 को दो instances में बाँटता है; एक single SM पूरा 50MB L2 इस्तेमाल कर सकता है, लेकिन 25MB से अधिक access पर performance penalty होती है
    • MI300X का XCD, cache के लिए दूसरे XCD की L2 capacity इस्तेमाल नहीं करता, इसलिए cache capacity utilization के मामले में Nvidia का तरीका ज्यादा efficient है

Ponte Vecchio के साथ structure comparison

  • Intel Ponte Vecchio(PVC), Compute Tile को basic compute block के रूप में इस्तेमाल करता है, जो मोटे तौर पर CDNA 3 के XCD के बराबर है
  • PVC का Base Tile, CDNA 3 के IO die की तरह बड़े last-level cache और HBM memory controller शामिल करता है
  • PVC card भी MI300X की तरह single GPU और unified memory pool के रूप में expose किया जा सकता है
  • दोनों structures का अंतर chiplet size, cache placement, और inter-die links में दिखता है
    • PVC का Compute Tile 8 Xe Core से बना है, इसलिए यह 38 CU वाले CDNA 3 XCD से छोटा है
    • Intel, पूरे Compute Tile cache के बजाय बड़े L1 cache के जरिए cross-die traffic requirement कम करता है
    • 2-stack Ponte Vecchio को unified GPU के रूप में इस्तेमाल करने पर EMIB bridge केवल 230GB/s देता है, इसलिए सभी memory controllers तक access को striping करते समय HBM bandwidth का पूरा उपयोग करना मुश्किल होता है
    • Intel, GPU को NUMA configuration के रूप में handle करने के लिए API प्रदान करता है
  • physical configuration में CDNA 3 को IO die के बीच high bandwidth चाहिए, और PVC low-bandwidth EMIB link के सहारे काम चला लेता है, लेकिन चार die types और अलग-अलग process/foundry के कारण design जटिल हो जाता है
  • MI300X केवल दो die types इस्तेमाल करता है, और 6nm तथा 5nm दोनों TSMC process हैं

Infinity Cache और memory bottleneck

  • compute performance कई दशकों से memory की तुलना में तेज़ी से बढ़ी है, और GPU भी CPU की तरह अधिक sophisticated cache strategies से इसका जवाब देते आए हैं
  • CDNA 2 ने 8MB L2 और HBM2e पर निर्भर traditional 2-level cache hierarchy इस्तेमाल की, लेकिन MI250X में Nvidia H100 की तुलना में bandwidth की कमी ज्यादा थी
  • CDNA 3, RDNA 2 से लिया गया Infinity Cache जोड़ता है
    • MI300 का Infinity Cache एक memory-side cache है, जिसे technical documents में Memory Attached Last Level(MALL) कहा जाता है
    • यह L1·L2 की तुलना में Compute Unit से दूर होता है, और memory controller से जुड़ा होता है
    • सारा memory traffic Infinity Cache से होकर गुजरता है, और IO traffic व peer GPU communication भी Infinity Cache bandwidth का फायदा ले सकते हैं
    • यह DRAM contents की latest state हमेशा देखता है, इसलिए snoop जैसे cache maintenance operations handle करने की जरूरत नहीं होती
  • memory-side cache में आम तौर पर latency ज्यादा होती है, इसलिए AMD ने CDNA 3 और RDNA 2 दोनों में multi-MB L2 cache से Compute Unit को protect किया है

Infinity Cache capacity और theoretical bandwidth

  • CDNA 3 का Infinity Cache, RDNA 2 की तरह 16-way set associative structure है
  • CDNA 3 implementation capacity की बजाय bandwidth के लिए ज्यादा optimized है
    • यह 128 slice से बना है
    • प्रति slice capacity 2MB है, और read bandwidth प्रति cycle 64 bytes है
    • सभी slices मिलकर प्रति cycle 8192 bytes देते हैं, जो 2.1GHz पर 17.2TB/s के बराबर है
  • RDNA 2 का 128MB Infinity Cache, सभी slices के आधार पर प्रति cycle 1024 bytes और 2.5GHz पर theoretically 2.5TB/s देता है
    • die shots के आधार पर RDNA 2 का Infinity Cache slice 4MB capacity और प्रति cycle 32 bytes देता हुआ लगता है
  • MI300X, कम compute density वाले workloads में भी अगर पर्याप्त Infinity Cache hit मिल जाएँ तो ठीक performance दे सकता है
  • Infinity Cache theoretical bandwidth से roofline model बनाने पर, MI300X loaded byte प्रति 4.75 FLOPs पर पूरी FP64 throughput तक पहुँच सकता है
    • केवल DRAM इस्तेमाल करने पर loaded byte प्रति 14.6~15 FLOPs की जरूरत होती है

Cross-die bandwidth की सीमाएँ

  • MI300X का Infinity Fabric 4 IO die में फैला है, और हर IO die 2 HBM stack व संबंधित cache partition से जुड़ा है
  • जब MI300X unified memory pool वाले single logical GPU के रूप में काम करता है, तो die-to-die connection bandwidth Infinity Cache की पूरी theoretical bandwidth हासिल करने को सीमित कर सकती है
  • single IO die partition के आधार पर bottleneck bandwidth calculation में दिखता है
    • adjacent IO die से सटे दो edges पर 2.7TB/s ingress bandwidth होती है
    • उस IO die से जुड़े 2 XCD, 4.2TB/s Infinity Cache bandwidth पा सकते हैं
    • अगर L2 miss requests पूरे die में evenly striped हों, तो 3/4 यानी 3.15TB/s peer die से आना होगा
    • 3.15TB/s, 2.7TB/s से बड़ा है, इसलिए cross-die bandwidth cache bandwidth को limit करती है
  • अगर unified configuration में सभी die maximum Infinity Cache bandwidth माँगें, तो opposite corner die के बीच transfer के लिए 2-hop की जरूरत पड़ती है, जिससे ingress bandwidth और खर्च होती है
  • MI300X को कई NUMA domain में बाँटने पर combined Infinity Cache bandwidth ज्यादा हो सकती है
  • high L2 hit rate bottleneck की संभावना घटाता है, और Infinity Cache hit rate कम होने पर MI300X के die-to-die links HBM traffic को संभालने के लिए पर्याप्त bandwidth देते हैं

XCD के बीच coherency और L2 behavior

  • Infinity Cache में coherency की चिंता करने की जरूरत नहीं है, लेकिन L2 cache के लिए अलग handling जरूरी है
  • सामान्य GPU memory access relaxed coherency model का पालन करता है, लेकिन programmer atomics के जरिए threads के बीच ordering enforce कर सकता है
  • AMD GPU में memory access को GLC(Global Level Coherent) bit से चिह्नित किया जा सकता है
  • पुराने AMD GPU में atomics और coherent access L2 में handle होते थे
    • GLC bit set वाला load L1 को bypass करके L2 से नवीनतम data लाता है
    • MI300X में नवीनतम cacheline किसी दूसरे XCD के L2 में हो सकती है, इसलिए केवल यह तरीका पर्याप्त नहीं है
  • CDNA 3, Ryzen के Infinity Fabric की तरह XCD और IO die के connection पर Coherent Master(CM) रखता है, और हर memory controller के पास Infinity Cache slice के साथ Coherent Slave(CS) रखता है
    • Ryzen documentation से पता चलता है कि Coherent Slave में probe filter और atomic transaction processing के लिए hardware होता है
    • MI300X में भी similar CS implementation होने की संभावना दिखती है
  • जब coherent write CS तक पहुंचता है, तो GPU में कहीं भी चल रहा thread coherent read में उस write को observe कर पाना चाहिए
    • simple implementation में CS को सभी XCD के L2 को probe करना पड़ेगा
    • probe filter track करता है कि किस XCD ने संबंधित line को cache किया है, ताकि unnecessary probe traffic से बचा जा सके
    • CDNA 3 whitepaper बताता है कि snoop filter कई XCD L2 caches को cover करने लायक बड़ा है
  • हालांकि XCD के अंदर CDNA 3 पुराने GPU जैसा ही काम करता है
    • सामान्य memory write CPU की तरह peer cache की line को automatically invalidate नहीं करता
    • code को explicitly dirty L2 cache line को writeback करना और peer L2 cache की non-local L2 line को invalidate करना होता है
    • संबंधित LLVM documentation GFX942 target में buffer_wbl2 sc1 और buffer_inv sc0 sc1 के उपयोग को समझाता है

L2 और L1 cache improvements

  • हर MI300X XCD में Compute Unit के पास 4MB L2 cache होता है
    • L2 16 slices से बना है
    • हर 256KB slice प्रति cycle 128 bytes bandwidth देता है
    • 2.1GHz पर यह प्रति XCD 4.3TB/s है
  • MI300X का L2 bandwidth-to-compute ratio H100 और MI250X से ज्यादा है
    • हर XCD में L2 होने से, CDNA 3 products में XCD बढ़ने पर L2 bandwidth भी naturally बढ़ती है
    • कई Compute Units को एक बड़े cache से जोड़ते हुए bandwidth बनाए रखने की समस्या से बचा जाता है
  • PVC में Compute Tile बढ़ने पर Base Tile के shared L2 पर ज्यादा bandwidth demand आती है
    • PVC architecture cache design के लिहाज से simple है, क्योंकि L2 coherency का single point और L1 miss का backstop दोनों है
    • यह MI300X L2 जितनी high bandwidth नहीं दे पाता
  • CDNA 3 का L1 भी bandwidth-केंद्रित improvements के साथ आता है
    • L1 throughput प्रति cycle 64 bytes से बढ़कर 128 bytes हो गया है
    • L1 capacity भी 16KB से बढ़कर 32KB हो गई है
    • बड़ा cache hit rate बढ़ाकर average memory access latency घटा सकता है और execution unit utilization बेहतर कर सकता है
    • L2 या उससे ऊपर से data लाने में power खर्च होती है, इसलिए hit rate बढ़ना power efficiency में भी मदद कर सकता है
  • Ponte Vecchio L1 के मामले में अब भी मजबूत है
    • हर Xe Core प्रति cycle 512 bytes देता है
    • L1 capacity 512KB है
    • L1 में fit होने वाले memory-bound kernel Intel architecture पर अच्छी तरह काम कर सकते हैं
    • हालांकि Compute Tile level पर mid-level cache न होने से, data L1 से आगे जाते ही performance में तेज गिरावट आ सकती है

Scheduling और execution units

  • CDNA 3, MI300X को single GPU जैसा दिखाने वाले chiplet और cache structure के अलावा, Compute Unit architecture में iterative improvements के जरिए CDNA 2 के FP32 utilization issue को address करता है
  • CDNA 2 FP64 को natively handle करते हुए packed execution के जरिए double-rate FP32 देता था
    • compiler को दो FP32 values को adjacent registers में pack करके वही instruction execute करना पड़ता था
    • अगर programmer explicitly vector का उपयोग न करे, तो compiler के लिए यह अच्छी तरह करना अक्सर मुश्किल होता था
  • CDNA 3 इस issue को ज्यादा flexible dual issue mechanism से bypass करता है
    • यह RDNA 3 के VOPD/wave64 approach की तुलना में GCN की multi-issue capability के extension के ज्यादा करीब लगता है
    • CU scheduler हर cycle में चार SIMD में से एक चुनता है और जांचता है कि कोई thread execution के लिए ready है या नहीं
    • अगर कई threads ready हों, तो GCN उनमें से अधिकतम 5 को execution units में भेज सकता था
  • CDNA 3 का dual issue compiler की तुलना में programmer द्वारा बड़े dispatch size से thread-level parallelism expose करने पर effective होने की संभावना ज्यादा है
    • जब SIMD अधिक threads execute कर रहा होता है, तो FP32 instructions वाले दो threads को एक साथ ढूंढने की संभावना बढ़ती है
    • पूरी FP32 throughput पाने के लिए कम से कम प्रति SIMD 2 active threads होने चाहिए
    • असल में memory latency या execution latency की वजह से ज्यादा occupancy जरूरी होती है
  • AMD ने CDNA 3 SIMD द्वारा track किए जा सकने वाले threads की संख्या 8 से बढ़ाकर 24 कर दी है
    • vector register file capacity में वृद्धि का उल्लेख नहीं है, और यह capacity अक्सर SIMD द्वारा एक साथ maintain किए जा सकने वाले threads की संख्या को limit करती है
    • कम per-thread register usage वाले simple kernels में multi-issue capability सबसे अच्छी तरह काम कर सकती है
  • dual issue register file bandwidth को भी समस्या बना सकता है
    • CDNA 2 का packed FP32, 64-bit values pass करने वाले wide register file ports का उपयोग करता था, इसलिए अतिरिक्त read की जरूरत नहीं थी
    • separate instructions अलग-अलग registers को reference कर सकते हैं, जिससे ज्यादा reads की जरूरत पड़ सकती है
    • AMD का कहना है कि उसने source caching को generation दर generation improve किया है, जिससे एक vector register read ज्यादा downstream vector या matrix operations को support कर सके
    • संभव है कि बड़ा register cache port conflict को कम करके execution units को data supply करता हो

Matrix operations और AI performance

  • machine learning के फैलाव के साथ matrix multiplication की अहमियत बढ़ी, और Nvidia ने Volta और Turing में tensor cores जोड़कर इस क्षेत्र में बड़ा निवेश किया
  • AMD CDNA भी matrix multiply support करता था, लेकिन उसी दौर की Nvidia architectures ने FP16 जैसे low-precision data types की matrix throughput में ज्यादा निवेश किया
  • MI300X ने पिछली CDNA generations की तुलना में प्रति CU matrix throughput को 2x बढ़ाया
  • MI300X का chiplet design बहुत बड़ी संख्या में CU संभव बनाता है, जिससे overall throughput बढ़ता है
  • Nvidia की per-SM matrix performance high है, इसलिए वह अब भी मजबूत competitor है; CDNA 3, AMD की trend के अनुरूप vector FP64 performance से Nvidia पर कड़ा pressure डालते हुए independently strong AI performance बनाए रखता है

instruction cache में बदलाव

  • Compute Unit को data memory access के साथ-साथ instructions खुद भी memory से लाने पड़ते हैं
  • GPU code पारंपरिक रूप से सरल और code size में छोटा रहा है, इसलिए instruction delivery अपेक्षाकृत आसान थी
  • CDNA 2 और RDNA GPU 32KB instruction cache का उपयोग करते रहे, लेकिन CDNA 3 ने इसे बढ़ाकर 64KB कर दिया
    • associativity भी 4-way से बढ़कर 8-way हो गई
    • बड़े और जटिल kernels में instruction cache hit rate बढ़ाता है
  • लगता है AMD ने CPU code को GPU पर सीधे port करने वाले मामलों को ध्यान में रखा है
    • जटिल CPU code GPU पर बोझ बन सकता है
    • GPU के लिए लंबी दूरी की instruction prefetching और सटीक branch prediction से instruction cache miss latency छिपाना मुश्किल होता है
    • बड़ा instruction cache बड़े kernels को रखने में मदद करता है, और ज्यादा associativity conflict misses को घटाती है
  • CDNA 3 का instruction cache instance, CDNA 2 की तरह, दो Compute Units द्वारा साझा किया जाता है
    • GPU kernels आम तौर पर इतने बड़े work size के साथ चलते हैं कि कई Compute Units भर जाएं, इसलिए instruction cache sharing SRAM का कुशल उपयोग करने का तरीका है
    • अगर अधिक Compute Units एक cache instance साझा करें, तो instruction bandwidth की मांग पूरी करना मुश्किल हो सकता है

MI300X और MI300A में अंतर

  • CDNA 3 में सबसे बड़ा generational बदलाव memory hierarchy है, और असली मुख्य सुधार भी Infinity Cache जोड़ने में है
  • MI250X की मुख्य समस्या यह थी कि वह एक GPU से ज्यादा, एक ही package साझा करने वाले दो GPU जैसा था
    • दोनों GCD के बीच bandwidth हर दिशा में 200GB/s थी
    • AMD ने माना कि यह bandwidth MI250X को एक GPU जैसा दिखाने के लिए पर्याप्त नहीं थी, इसलिए die-to-die bandwidth को काफी बढ़ाया
  • MI300 ने कुल East-West bandwidth को हर दिशा में 2.4TB/s तक बढ़ाया, जो MI250X की तुलना में 12 गुना है
    • कुल North-South bandwidth हर दिशा में 3.0TB/s पर और भी अधिक है
    • इस bandwidth वृद्धि से MI300, MI250X की तरह 2 accelerators नहीं बल्कि एक बड़े unified accelerator जैसा दिख सकता है
  • एक single IO die की कुल ingress bandwidth 4.0TB/s है, जो दो XCD द्वारा उपयोग किए जा सकने वाले 4.2TB/s से लगभग मेल खाती है, इसलिए व्यावहारिक रूप से यह बड़ी समस्या नहीं है
    • हालांकि single IO die पूरी 5.3TB/s memory bandwidth का उपयोग नहीं कर सकता
    • यह Ryzen 7000 में एक CCD द्वारा Infinity Fabric limitation के कारण DDR5 bandwidth का पूरा उपयोग न कर पाने जैसी स्थिति है
    • MI300X में जब सभी dies साथ काम करते हैं, bandwidth demand सबसे ज्यादा होती है, और इस स्थिति में हर die लगभग 1.3TB/s consume करता है, इसलिए cross-die link से 3/4 लाना समस्या नहीं बनता
  • MI300A एक “big iron” APU है, जो उसी base die को reuse करते हुए 6 CDNA3 XCD और 24 Zen 4 cores को जोड़ता है
    • CPU और GPU एक ही memory address space साझा कर सकते हैं
    • CPU और GPU की coherency बनाए रखने के लिए external bus पर data copy करने की जरूरत खत्म हो जाती है

1 टिप्पणियां

 
GN⁺ 2023-12-19
Hacker News की राय
  • क्या यही वजह थी कि AMD के consumer cards compute नहीं कर पाते? मुझे लगा था यह बस आधी-अधूरी product segmentation strategy है, लेकिन यह तो बिना entry ramp वाले highway जैसा ऊपरी architecture-level issue लग रहा है, इसलिए थोड़ा गंभीर दिखता है
    • आम तौर पर software developers सिर्फ एक general-purpose GPU API को support करते हैं, और वह API nVidia CUDA है
      तकनीकी तौर पर AMD consumer cards की compute performance शानदार है। उदाहरण के लिए UE5 graphics pipeline के बजाय compute से triangle mesh render करता है https://www.youtube.com/watch?v=TMorJX3Nj6U
      ऊपर से nVidia ने compute performance और memory bandwidth के बजाय ray tracing और DLSS को प्राथमिकता दी, इसलिए कई मामलों में AMD cards उसी class के nVidia से आगे भी निकल जाते हैं
      समस्या यह है कि कोई भी tech company PyTorch जैसी AI libraries में D3D या Vulkan backend जोड़ना नहीं चाहती। nVidia status quo से खुश है, इसलिए नहीं करती, और Intel व AMD public GPU API के बजाय CUDA को अपने proprietary alternatives से बदलना चाहते हैं, इसलिए वे भी नहीं करते
    • AMD consumer cards compute तो करते हैं, लेकिन ecosystem mature नहीं है और support भी कमजोर है। ROCm लगभग अव्यवस्थित है
      हालांकि यह न तो आधी-अधूरी product segmentation है, न ही ऊपरी architecture issue। specialized products अपने field में general-purpose products से बेहतर होते हैं। compute और gaming दोनों में अच्छे cards की मांग छोटी है, और ऐसे लोग होते तो हैं, लेकिन एक ही तरफ ध्यान देने वालों की तुलना में कम हैं
      GCN को RDNA और CDNA में बांटने का असर तुरंत दिखा। Radeon VII(GCN 5) और RX 5700 XT(RDNA 1) की तुलना करें तो games में वे आगे-पीछे होते रहते हैं और औसतन Radeon VII थोड़ा आगे रहता है, लेकिन RX 5700 XT compute benchmarks में काफी पीछे रह जाता है। दोनों TSMC 7nm हैं, लेकिन RX 5700 XT में shaders कम हैं(2560 बनाम 3840), die छोटा है(251 बनाम 311 mm2), और power भी कम है(225 बनाम 300 W), जिससे दिखता है कि gaming efficiency कहीं बेहतर है। कम power, कम noise, और कई सौ डॉलर कम कीमत की वजह से यह gamers के लिए कहीं ज्यादा आकर्षक card था
      CDNA cards में render output units जैसे gaming के लिए जरूरी components नहीं लगते। इसलिए DirectX, OpenGL, Vulkan का official support नहीं है। मैंने इससे games चलाने का कोई case नहीं देखा। इसके बजाय compute performance इतनी अच्छी है कि बेहद मजबूत CUDA ecosystem के बावजूद कई companies nVidia के बजाय ये cards खरीद रही हैं। 2013 में GCN-based supercomputer एक top 100 में आया था, और वही इकलौता GCN-based top 100 system था। अब energy efficiency के हिसाब से top 10 supercomputers में से 8 CDNA accelerators इस्तेमाल करते हैं, और कुल मिलाकर नंबर 1 सबसे तेज supercomputer भी CDNA इस्तेमाल करता है
    • 2 महीने पहले high-end Radeon cards का support जोड़ा गया था। ROCm “कभी न कभी” broadly RDNA पर आने वाला है, लेकिन यह धीमी प्रक्रिया है, और शुरू से AMD ने ROCm को जिस तरह handle किया है, उससे मोटे तौर पर मेल खाती है। यह बहुत छोटे compute subset को target करके शुरू करता है और हर major version के साथ धीरे-धीरे दायरा बढ़ाता है
      https://www.tomshardware.com/news/amd-enables-rocm-and-pytor...
    • AMD हमेशा ATI को ठीक से lead नहीं कर पाया
      मूल रूप से यह hardware company है(जैसा Lisa Su के background से भी दिखता है), और इस बात को जल्दी स्वीकार नहीं कर पाया कि CUDA निर्णायक वार है। मुझे Phoronix पर @Bridgman का developers को रोके रखने के लिए पीछे हटते हुए लड़ाई जारी रखना याद है। यह ऐसी लड़ाई थी जिसे हारना तय था
      कुछ हद तक समझ आता है। 80/90 के दशक की hardware generation सहज रूप से मानती है कि stack में hardware सबसे ऊपर है, और Su समेत AMD की leadership उसी background से आई है
      Kodura समझ गया था कि consumer cards पर भी CUDA चलने की वजह से nVidia AMD पर हावी हो रहा है। इसलिए उसने Lisa Su के खिलाफ जाकर Radeon VII को push किया, और वह card बहुत हाल तक कई वर्षों तक ROCm द्वारा supported इकलौता consumer card था। उसके कुछ ही समय बाद उसे practically निकाल दिया गया, और शानदार card RVII भी जल्दी बंद कर दिया गया। उसके बाद Wang आया और consumer/professional split को पक्का कर दिया
      अब AMD बेतहाशा वापस लौटने की कोशिश कर रहा है, लेकिन बहुत देर हो चुकी है। competition करने की कोशिश करने वाले कई हैं, लेकिन वास्तव में बात करने लायक AAPL और Metal ही हैं
      AMD ने मौका गंवा दिया
    • separation करीब 2016 के आसपास दिखती है। उस समय cryptocurrency की स्थिति देखें तो यह समझ में आता है। nVidia को AMD से ज्यादा जोर से लगी समस्याओं में से एक यह थी कि consumer cards mining farms में खिंच जा रहे थे। AMD ने जानबूझकर split करके compute cards और gamer cards को practically अलग-थलग कर दिया
      फिर भी, यह AMD cards के compute workloads में adoption के लिए अच्छा रहा होगा, ऐसा नहीं लगता। CUDA की शानदार बात यह है कि CUDA code develop करने के लिए special accelerator card की जरूरत नहीं होती
  • निकट भविष्य में AMD के NVidia से मुकाबला कर पाने की संभावना नहीं लगती। क्योंकि ML/AI की core libraries बनाने वाले कई scientists को NVidia से GPUs free या भारी discount पर मिलते हैं
    अगर उन्हें अपने पैसे या research grant से आम consumers जैसी कीमत पर GPU खरीदना पड़ता, तो स्थिति शायद अलग हो सकती थी
    निजी तौर पर मुझे लगता है कि NVidia जिस तरह academia और university research environments में घुसता है, वह बहुत अनैतिक है
    • Nvidia ने इसमें resources और समय लगाना 10 साल से भी पहले शुरू कर दिया था। CUDA 2007 में आया था, और उस समय आज की ML/AI waves मौजूद भी नहीं थीं
      उसके बाद भी वे इंतजार करते रहे, और कई बार company को इस बात पर दांव पर लगाया कि उनके बनाए product का market “आएगा”
      पिछले कुछ वर्षों में यह सचमुच हुआ, और stock price में भी दिखा। बाकी players मूल रूप से 10 साल पीछे हैं, और मौजूदा hype व AI/ML workflows के popularization को देखते हुए किसी का catch up करना लगभग असंभव लगता है
    • इस field में AMD के प्रति काफी नाराजगी भी है। मैं कुछ लोगों को जानता हूं जिन्होंने शुरुआती दौर में Nvidia और AMD GPU दोनों को support करने में बहुत समय लगाया, लेकिन AMD ने API support बंद करके उनके code को बेकार कर दिया
      इसके उलट CUDA code नई Nvidia card generations आने पर भी चलता रहा
    • मुझे नहीं पता यह बात कितनी सही है। मैं university में LLM, computer vision आदि, यानी आम तौर पर कहे जाने वाले “AI” research करने वाले researchers को support कर रहा हूं, और NVIDIA education के लिए discount सिर्फ A5000 card पर देता है। हो सकता है एक और card हो जिसमें उनकी रुचि नहीं है(L40?)

ज़्यादातर लोग Exxact या Supermicro जैसी कंपनियों से A6000 या उससे ऊपर के कार्ड consumer price पर खरीद रहे हैं
V100 के दौर, यानी DGX-1 सिस्टम के बाद से, मुझे नहीं लगता कि मैंने कभी किसी researcher को मुफ्त GPU मिलते देखा है

  • AMD को developers को मुफ्त कार्ड देने से कोई नहीं रोक रहा
  • “कई दशकों से compute ने memory को पीछे छोड़ दिया है, और CPU की तरह GPU भी increasingly sophisticated caching strategies से जवाब देते आए हैं” — मुझे लगता है यह बात उल्टी ही ज़्यादा है
    CPU के विपरीत, GPU इसे सीधे compensate करने की कोशिश नहीं करते। वे ज़्यादा latency स्वीकार करते हैं, लेकिन CPU की तुलना में कहीं ज़्यादा व्यापक, बल्कि aggressive parallelization करते हैं, और ढेरों parallel pseudo-threads latency hiding का असर देते हैं
    यह असर, उदाहरण के लिए, GPU code optimization presentations में भी देखा जा सकता है
    https://www.olcf.ornl.gov/wp-content/uploads/2019/12/03-CUDA...
    slide 11 से शुरू होने वाली animation इसका उदाहरण है
    • GPU parallelism के अलावा भी memory से निपटते हैं। इसलिए GPU बड़े register files (RDNA1 में प्रति thread अधिकतम 256 architectural registers) और local memory (RDNA1 में प्रति work group अधिकतम 64KB LDS) देने की प्रवृत्ति रखते हैं
      यानी बहुत सा काम पूरी तरह registers और LDS में किया जा सकता है, और global memory access, CPU की तुलना में कहीं कम होता है, जहाँ global memory में लगभग सब कुछ होता है और architectural registers करीब 16 के आसपास होते हैं
      फिर भी global memory समस्या है। वजह सिर्फ latency नहीं, bandwidth भी है। इसलिए RDNA2 और Ada ने अंतिम-स्तर के cache बड़ी मात्रा में जोड़े। यह latency को बेहतर ढंग से छिपाने के लिए भी है, लेकिन मुख्य उद्देश्य bandwidth amplifier की तरह काम करना है
  • VLIW के बारे में मुझे ज़्यादा नहीं पता था, लेकिन यह काफ़ी रोचक है
    Very long instruction word(VLIW) एक instruction set architecture है जिसे instruction-level parallelism (ILP) का लाभ उठाने के लिए design किया गया है। सामान्य central processing unit (CPU) आम तौर पर program को केवल वे instructions बताने देता है जिन्हें क्रम से execute करना है, लेकिन VLIW processor program को explicitly यह specify करने देता है कि कौन-से instructions parallel में execute होंगे। इस design का उद्देश्य दूसरे तरीकों में मौजूद complexity से बचते हुए higher performance देना है
    processor performance बढ़ाने के पारंपरिक तरीकों में pipelining है, जिसमें instructions को छोटे stages में बाँटकर उनमें से कुछ को साथ-साथ execute किया जाता है; superscalar architecture है, जिसमें अलग-अलग instructions को processor के अलग-अलग हिस्सों में independent execution के लिए भेजा जाता है; और यहाँ तक कि out-of-order execution भी है, जिसमें instructions program के क्रम से अलग order में execute होते हैं। ये तरीके hardware को complex बनाते हैं, क्योंकि processor को internally सारे decisions लेने पड़ते हैं
    https://en.wikipedia.org/wiki/Very_long_instruction_word
    • VLIW processor का सबसे मशहूर example Itanic, नहीं, Itanium था
      वह सफल नहीं हुआ। इसलिए उसे Itanic कहा जाता था
      धारणा यह थी कि compiler dependencies को पर्याप्त रूप से statically समझ सकेगा और कई sequential execution paths और कुछ branch execution paths को एक ही instruction में डाल सकेगा। लेकिन असल में पता चला कि compiler ऐसा नहीं कर पाते, इसलिए processor को sequential instruction stream में dependencies और parallelize किए जा सकने वाले instructions को dynamically ढूँढना पड़ा
      इसमें बहुत काम, बहुत chip resources और बहुत energy लगती है। और यह एक सीमा तक ही अच्छी तरह काम करता है, उसके बाद diminishing returns से टकराता है। लगता है आज हम उसी जगह पर हैं
    • SIMD के बारे में कुल मिलाकर पढ़ना अच्छा रहेगा
      यह instructions भेजने की भाषा नहीं, बल्कि processing का तरीका है
      और यह ध्यान रखना भी ठीक है कि VLIW4 या VLIW5 जैसे terms किसी खास implementation को refer करते हैं
      https://en.wikipedia.org/wiki/Single_instruction,_multiple_d...
  • यहाँ वह luddite मौजूद है जिसने कहा था कि AMD chiplets और bus fabric की अपनी जानकारी का इस्तेमाल करके AI में पलटवार करेगा। यह नहीं कहूँगा कि मैं यह article पढ़ सकता हूँ, या सच कहूँ तो article ही पढ़ सकता हूँ, लेकिन फिर भी अपना झंडा गाड़ना चाहता हूँ
  • थोड़ा विषयांतर है, लेकिन “compute” कब से noun की तरह इस्तेमाल होने लगा? कानों को बहुत खटकता है
    • कम से कम AWS के उभरने के समय से तो मुझे याद है। “Amazon Elastic Compute Cloud(EC2)” 2006 में launch हुआ था [0]। Google Trends भी देखने लायक है [1]
      0: https://en.m.wikipedia.org/wiki/Amazon_Elastic_Compute_Cloud
      1: https://trends.google.com/trends/explore?date=all&q=Compute&...
    • Deep Space Nine(1999) में भी ऐसा expression था, तो या तो उस समय की terminology sense बहुत accurate थी या यह expression चलन में आकर गायब होता रहा होगा
    • आजकल AI और GPU जैसे chips की वजह से यह काफी common हो गया है
    • यह ऐसा term है जिसे मैं रोज़ सुनता, पढ़ता और लिखता हूँ; मेरे workplace में यह करीब 5 साल पहले आया और करीब 2 साल पहले से common इस्तेमाल में आने लगा