AMD'nin CDNA 3 Hesaplama Mimarisi
(chipsandcheese.com)- AMD CDNA 3, CDNA 2 FP64 süper hesaplamada başarılı olsa da H100 karşısında yapay zeka performansı ve birleşik GPU ölçeği açısından geride kaldığı noktaları telafi etmeyi amaçlayan bir hesaplama GPU mimarisidir
- MI300X, 8 XCD üzerinde toplam 304 Compute Unit'i tek bir GPU gibi sunarak, MI250X'te olduğu gibi işleri iki GPU ve ayrı bellek havuzları arasında bölme yükünü azaltır
- Bellek hiyerarşisi 256MB Infinity Cache, XCD başına 4MB L2 ve CU yakınındaki 32KB L1 olarak yeniden düzenlendi; teorik olarak 17.2TB/s önbellek bant genişliği sunsa da birleşik bellek yapılandırmasında die-to-die bağlantıları darboğaz olabilir
- Yürütme birimleri, FP32 kullanımını artırmak için dual issue'ya yakın bir yapı ve SIMD başına izlenebilen thread sayısında artış getirirken, matris işlem verimi de önceki CDNA nesline kıyasla CU başına 2 kat arttı
- CDNA 3'teki temel değişim bellek hiyerarşisi ve paketlemedir; MI300X, büyük ölçüde artırılmış Infinity Fabric bant genişliğiyle birden fazla chiplet'i tek bir büyük hızlandırıcı gibi gösterecek şekilde tasarlandı
CDNA 3'ün hedeflediği fark
- AMD, GPU hesaplama pazarında Nvidia'yı yakalamak için Terascale 3, GCN ve CDNA/RDNA ayrımından geçerek mimarisini geliştirdi
- CDNA 2 tabanlı MI250X ve MI210, ORNL'nin Frontier sistemi dahil çeşitli süper bilgisayar sözleşmeleri kazandı ve Frontier, Kasım 2023 TOP500 listesinde 1. oldu
- CDNA 2, FP64 hesaplamada sağlam ve maliyet açısından verimli performans sundu, ancak H100 daha iyi yapay zeka performansı ve daha büyük bir birleşik GPU sağladı
- CDNA 3, AMD'nin gelişmiş paketleme teknolojisini, Infinity Fabric'i, RDNA kökenli Infinity Cache'i ve geliştirilmiş Compute Unit'leri birleştirerek bu farkı azaltacak şekilde tasarlandı
MI300X'in GPU yerleşimi
- MI300X, hesaplama işini Accelerator Complex Die(XCD) olarak ayıran chiplet yapısını kullanır
- XCD, CDNA 2/RDNA 3'teki Graphics Compute Die(GCD) ve Ryzen'deki Core Complex Die(CCD) ile benzer bir rol üstlenir
- CDNA ürünlerinde RDNA ailesine özgü grafik donanımı bulunmadığı için AMD'nin adlandırmayı değiştirdiği anlaşılıyor
- Her XCD'de fiziksel olarak 40 CDNA 3 Compute Unit bulunur ve MI300X'te XCD başına 38'i aktiftir
- Bir XCD üzerinde 4MB L2 cache vardır ve o kalıptaki tüm CU'lar bunu kullanır
- MI300X, 8 XCD ile toplam 304 Compute Unit sunar
- Bu sayı, MI250X'in 220 CU'suna göre büyük bir artıştır ve MI300X bu CU'ları tek bir GPU olarak sunabilir
- MI250X'te her GPU'nun ayrı bir bellek havuzu vardı ve programcının işi iki GPU arasında doğrudan bölmesi gerekiyordu
- Nvidia H100, 132 Streaming Multiprocessor(SM)'u tek bir birleşik GPU olarak sunar, ancak hesaplama birimlerini büyük tekil kalıp üzerinde uygulayan geleneksel yaklaşımı kullanır
- H100, L2'yi iki örneğe böler; tek bir SM tüm 50MB L2'yi kullanabilir, ancak 25MB üzerindeki erişimlerde performans cezası vardır
- MI300X'in XCD'leri, diğer XCD'lerin L2 kapasitesini önbellekleme için kullanmadığından, önbellek kapasitesinden yararlanma açısından Nvidia'nın yaklaşımı daha verimlidir
Ponte Vecchio ile yapısal karşılaştırma
- Intel Ponte Vecchio(PVC), temel hesaplama bloğu olarak Compute Tile kullanır; bu, CDNA 3'teki XCD'ye kabaca karşılık gelir
- PVC'nin Base Tile'ı, CDNA 3'ün IO kalıbına benzer şekilde büyük bir son seviye önbellek ve HBM bellek denetleyicileri içerir
- PVC kartı da MI300X gibi tek GPU ve birleşik bellek havuzu olarak sunulabilir
- İki yapı arasındaki farklar chiplet boyutu, önbellek yerleşimi ve kalıplar arası bağlantılarda ortaya çıkar
- PVC'nin Compute Tile'ı 8 Xe Core'dan oluşur ve bu, 38 CU içeren CDNA 3 XCD'sinden daha küçüktür
- Intel, Compute Tile genelinde paylaşılan önbellek yerine daha büyük L1 önbellek kullanarak cross-die trafik ihtiyacını azaltır
- 2-stack Ponte Vecchio birleşik GPU olarak kullanıldığında EMIB köprüsü yalnızca 230GB/s sağladığı için, tüm bellek denetleyicilerine erişimi şeritler halinde dağıtırken HBM bant genişliğinden tam yararlanmak zordur
- Intel, GPU'yu NUMA yapılandırması olarak ele alabilen API'ler sunar
- Fiziksel yapıda CDNA 3, IO kalıpları arasında yüksek bant genişliği gerektirirken; PVC, daha düşük bant genişlikli EMIB bağlantılarıyla bunu taşır, ancak dört farklı kalıp tipi ve farklı süreçler/dökümhaneler nedeniyle tasarım karmaşıktır
- MI300X ise yalnızca iki kalıp tipi kullanır ve hem 6nm hem 5nm tarafında TSMC süreci tercih edilir
Infinity Cache ve bellek darboğazı
- Hesaplama performansı onlarca yıldır bellekten daha hızlı arttı ve GPU'lar da CPU'lar gibi buna giderek daha gelişmiş önbellek stratejileriyle yanıt verdi
- CDNA 2, 8MB L2 ve HBM2e'ye dayanan geleneksel iki seviyeli önbellek hiyerarşisini kullanıyordu, ancak MI250X'in bant genişliği açığı Nvidia H100'e göre daha büyüktü
- CDNA 3, RDNA 2'den alınan Infinity Cache'i ekler
- MI300'deki Infinity Cache, teknik belgelerde Memory Attached Last Level(MALL) olarak adlandırılan bellek tarafı bir önbellektir
- L1 ve L2'ye göre Compute Unit'lerden daha uzaktadır ve bellek denetleyicilerine bağlıdır
- Tüm bellek trafiği Infinity Cache'ten geçer; IO trafiği ve eş GPU iletişimi de Infinity Cache bant genişliğinin avantajından yararlanabilir
- DRAM içeriğinin en güncel halini her zaman gördüğü için snoop benzeri önbellek tutarlılığı işlemlerini yürütmesi gerekmez
- Bellek tarafı önbellekler genellikle daha yüksek gecikmeye sahiptir; bu yüzden AMD, hem CDNA 3 hem RDNA 2'de Compute Unit'leri çok megabaytlık L2 önbellekle korur
Infinity Cache kapasitesi ve teorik bant genişliği
- CDNA 3'ün Infinity Cache'i, RDNA 2'de olduğu gibi 16-way set associative yapıdadır
- CDNA 3 uygulaması kapasiteden çok bant genişliği için optimize edilmiştir
- 128 slice'tan oluşur
- Slice başına kapasite 2MB, okuma bant genişliği ise çevrim başına 64 bayttır
- Tüm slice'lar çevrim başına 8192 bayt sağlar; bu da 2.1GHz'de 17.2TB/s'ye karşılık gelir
- RDNA 2'nin 128MB Infinity Cache'i, tüm slice'lar genelinde çevrim başına 1024 bayt ve 2.5GHz'de teorik olarak 2.5TB/s sağlar
- die shots temel alındığında, RDNA 2'nin Infinity Cache slice'larının 4MB kapasite ve çevrim başına 32 bayt sunduğu görülüyor
- MI300X, düşük compute density'ye sahip iş yüklerinde bile yeterli Infinity Cache isabet oranı yakalarsa iyi performans verebilir
- Infinity Cache'in teorik bant genişliğiyle bir roofline modeli kurulduğunda, MI300X yüklenen bayt başına 4.75 FLOP ile toplam FP64 işlem kapasitesine ulaşabilir
- Yalnızca DRAM kullanıldığında ise yüklenen bayt başına 14.6~15 FLOP gerekir
Cross-die bant genişliği kısıtları
- MI300X'in Infinity Fabric'i 4 IO kalıbına yayılır ve her IO kalıbı 2 HBM stack ile ilgili önbellek bölümlerine bağlıdır
- MI300X, birleşik bellek havuzuna sahip tek bir mantıksal GPU olarak çalıştığında, die-to-die bağlantı bant genişliği Infinity Cache'in tam teorik bant genişliğine ulaşmasını sınırlayabilir
- Tek bir IO kalıbı bölümü temelinde darboğaz, bant genişliği hesabında ortaya çıkar
- Komşu IO kalıbıyla temas eden iki kenarda 2.7TB/s ingress bant genişliği vardır
- O IO kalıbına bağlı 2 XCD, 4.2TB/s Infinity Cache bant genişliği elde edebilir
- L2 miss istekleri tüm kalıplara eşit biçimde şeritlenirse, bunun 3/4'ü olan 3.15TB/s'nin peer die'lardan gelmesi gerekir
- 3.15TB/s, 2.7TB/s'den büyük olduğu için cross-die bant genişliği önbellek bant genişliğini sınırlar
- Birleşik yapılandırmada tüm kalıplar en yüksek Infinity Cache bant genişliğini talep ederse, karşı köşedeki kalıplar arasındaki aktarım 2-hop gerektirir ve bu da ingress bant genişliğini ek olarak tüketir
- MI300X'i birden fazla NUMA domain'e ayırmak, toplam Infinity Cache bant genişliğini daha yüksek hale getirebilir
- Yüksek L2 isabet oranı darboğaz olasılığını azaltır; Infinity Cache isabet oranı düşük olduğunda ise MI300X'in die-to-die bağlantıları HBM trafiğini taşımak için yeterli bant genişliği sunar
XCD'ler arası tutarlılık ve L2 davranışı
- Infinity Cache için tutarlılık konusunda endişe gerekmiyor, ancak L2 önbelleği için ayrı işlem gerekiyor
- Genel GPU bellek erişimi relaxed coherency modelini izler, ancak programcı thread'ler arası ordering'i atomics ile zorlayabilir
- AMD GPU'larda bellek erişimi GLC (Global Level Coherent) biti ile işaretlenebilir
- Önceki AMD GPU'larda atomics ve coherent access L2 üzerinde işlenirdi
- GLC biti ayarlanmış load işlemleri L1'i atlayıp en güncel veriyi L2'den alır
- MI300X'te en güncel cacheline başka bir XCD'nin L2'sinde olabilir, bu yüzden bu yöntem tek başına yeterli değildir
- CDNA 3, Ryzen'daki Infinity Fabric'e benzer şekilde XCD ile IO kalıbı bağlantısına Coherent Master (CM) yerleştiriyor ve her bellek denetleyicisinin yanına Infinity Cache slice ile birlikte Coherent Slave (CS) koyuyor
- Ryzen belgelerinden, Coherent Slave içinde probe filter ve atomic transaction işleme donanımı bulunduğu anlaşılıyor
- MI300X'in de benzer bir CS uygulamasına sahip olduğu görülüyor
- coherent write CS'ye ulaştığında, thread GPU'nun neresinde çalışıyor olursa olsun coherent read sırasında bu write'ın görülmesi gerekir
- Basit bir uygulamada CS'nin tüm XCD'lerin L2'lerini probe etmesi gerekir
- probe filter, hangi XCD'nin ilgili satırı önbelleğe aldığını izleyerek gereksiz probe trafiğini önler
- CDNA 3 whitepaper'ı, snoop filter'ın birden fazla XCD L2 önbelleğini kapsayacak kadar büyük olduğunu belirtiyor
- Ancak XCD içindeki CDNA 3, eski GPU'lara benzer şekilde çalışıyor
- Genel bellek write işlemleri CPU'lardaki gibi peer cache satırlarını otomatik olarak invalidate etmiyor
- Kodun dirty L2 cache line'larını writeback etmesi ve peer L2 cache'teki non-local L2 line'ları invalidate etmesi açıkça belirtilmelidir
- İlgili LLVM belgeleri, GFX942 target'ında
buffer_wbl2 sc1vebuffer_inv sc0 sc1kullanımını açıklıyor
L2 ve L1 önbellek iyileştirmeleri
- Her MI300X XCD'si, Compute Unit'lere yakın konumda 4 MB L2 önbelleğe sahip
- L2, 16 slice'tan oluşuyor
- Her 256 KB slice, döngü başına 128 bayt bant genişliği sunuyor
- 2,1 GHz'de bu, XCD başına 4,3 TB/s anlamına geliyor
- MI300X, H100 ve MI250X'e kıyasla daha yüksek L2 bandwidth-to-compute oranına sahip
- Her XCD'nin kendi L2'si olduğundan, CDNA 3 ürünlerinde XCD sayısı arttıkça L2 bant genişliği de doğal olarak artıyor
- Çok sayıda Compute Unit'i tek bir büyük önbelleğe bağlayıp bant genişliğini koruma sorunundan kaçınılıyor
- PVC'de Compute Tile sayısı arttıkça Base Tile üzerindeki paylaşımlı L2'ye daha fazla bant genişliği talebi geliyor
- PVC yapısı, L2'nin tutarlılığın tek noktası ve L1 miss'ler için backstop olması nedeniyle önbellek tasarımı açısından daha basit
- Ancak MI300X L2'si kadar yüksek bant genişliği sunamıyor
- CDNA 3'ün L1'i de bant genişliği odaklı şekilde geliştirildi
- L1 throughput'u döngü başına 64 bayttan 128 bayta çıktı
- L1 kapasitesi de 16 KB'den 32 KB'ye yükseldi
- Daha büyük önbellek, hit rate'i artırarak ortalama bellek erişim gecikmesini düşürebilir ve yürütme birimi kullanımını iyileştirebilir
- L2 ve ötesinden veri getirmenin güç tüketmesi nedeniyle, hit rate artışı enerji verimliliğine de katkı sağlayabilir
- Ponte Vecchio, L1 tarafında hâlâ güçlü
- Her Xe Core, döngü başına 512 bayt sunuyor
- L1 kapasitesi 512 KB
- L1'e sığan memory-bound kernel'ler Intel mimarisinde iyi çalışabilir
- Ancak Compute Tile düzeyinde orta seviye bir önbellek olmadığından, veri L1'i aştığında performans keskin biçimde düşebilir
Zamanlama ve yürütme birimleri
- CDNA 3, MI300X'i tek GPU gibi gösteren chiplet ve önbellek yapısının ötesinde, Compute Unit mimarisini kademeli olarak geliştirerek CDNA 2'nin FP32 kullanım sorununu ele alıyor
- CDNA 2, FP64'ü yerel olarak işlerken packed execution ile çift oranlı FP32 sağlıyordu
- Derleyicinin iki FP32 değeri bitişik register'lara pack etmesi ve aynı komutu çalıştırması gerekiyordu
- Programcı açıkça vector kullanmadıkça derleyicinin bunu iyi yapması çoğu zaman zordu
- CDNA 3, daha esnek bir dual issue mekanizmasıyla bu sorunu aşıyor
- Bu yaklaşım, RDNA 3'teki VOPD/wave64 yönteminden ziyade GCN'in multi-issue özelliğinin genişletilmiş hâline daha yakın görünüyor
- CU scheduler her cycle dört SIMD'den birini seçiyor ve yürütmeye hazır thread olup olmadığını kontrol ediyor
- Birden fazla thread hazırsa, GCN bunlardan en fazla 5'ini yürütme birimlerine gönderebiliyordu
- CDNA 3'ün dual issue yaklaşımı, derleyiciden çok programcının büyük dispatch size ile thread-level parallelism'i görünür kılmasına bağlı olarak etkili olabilir
- SIMD ne kadar fazla thread çalıştırıyorsa, FP32 komutlu iki thread'i aynı anda bulma olasılığı da o kadar artar
- Tam FP32 throughput'a ulaşmak için en azından SIMD başına 2 aktif thread gerekir
- Pratikte bellek gecikmesi ve yürütme gecikmesi nedeniyle daha yüksek occupancy gerekir
- AMD, CDNA 3 SIMD'nin takip edebileceği thread sayısını 8'den 24'e büyük ölçüde artırdı
- Vector register file kapasitesinde bir artıştan söz edilmiyor; bu kapasite çoğu zaman SIMD'nin aynı anda tutabileceği thread sayısını sınırlar
- Multi-issue yeteneği, thread başına register kullanımı düşük olan basit kernel'lerde en iyi şekilde çalışabilir
- Dual issue, register file bant genişliğini de sorun hâline getirebilir
- CDNA 2'de packed FP32, ek okuma gerektirmeden 64 bit değer taşıyan geniş register file portlarından yararlanıyordu
- Ayrı komutlar farklı register'lara başvurarak daha fazla okuma gerektirebilir
- AMD, source caching'i nesiller boyunca geliştirerek tek bir vector register okumasının daha fazla alt seviye vector veya matrix işlemini beslemesini sağladığını belirtiyor
- Bu, daha büyük bir register cache ile port conflict'leri hafifletip yürütme birimlerine veri sağlama yöntemi olabilir
Matris işlemleri ve yapay zeka performansı
- Makine öğreniminin yaygınlaşmasıyla matris çarpımı daha önemli hâle geldi ve Nvidia, Volta ile Turing'de tensor core ekleyerek bu alana büyük yatırım yaptı
- AMD CDNA da matrix multiply destekliyordu, ancak aynı dönemin Nvidia mimarileri FP16 gibi düşük hassasiyetli veri tiplerinde matris işlem throughput'una daha fazla yatırım yaptı
- MI300X, önceki CDNA nesillerine kıyasla CU başına matrix throughput'unu 2 kat artırıyor
- MI300X'in chiplet tasarımı çok yüksek sayıda CU'yu mümkün kılarak toplam throughput'u büyütüyor
- Nvidia, SM başına yüksek matrix performansı sayesinde hâlâ güçlü bir rakip; CDNA 3 ise AMD'nin genel çizgisine uygun şekilde vector FP64 performansıyla Nvidia'ya güçlü baskı uygularken kendi başına da güçlü yapay zeka performansını koruyor
Komut önbelleğindeki değişiklikler
- Compute Unit, yalnızca veri belleğine erişmekle kalmaz, komutların kendisini de bellekten getirmek zorundadır
- GPU kodu geleneksel olarak basit ve kod boyutu küçük olduğundan, instruction delivery nispeten kolaydı
- CDNA 2 ve RDNA GPU'lar 32KB instruction cache kullanmaya devam etti, ancak CDNA 3 bunu 64KB'ye çıkardı
- associativity de 4-way'den 8-way'e yükseltildi
- daha büyük ve daha karmaşık kernel'lerde instruction cache hit rate'i artırır
- AMD'nin, CPU kodunun GPU'ya basitçe taşındığı durumları göz önünde bulundurduğu görülüyor
- karmaşık CPU kodu GPU üzerinde yük oluşturabilir
- GPU'lar, uzun mesafeli instruction prefetching ve doğru branch prediction ile instruction cache miss latency'sini gizlemekte zorlanır
- daha büyük bir instruction cache, büyük kernel'leri barındırmaya yardımcı olur ve yüksek associativity, conflict miss'i azaltır
- CDNA 3'ün instruction cache instance'ı, CDNA 2'de olduğu gibi iki Compute Unit tarafından paylaşılır
- GPU kernel'leri genellikle çok sayıda Compute Unit'i dolduracak kadar büyük work size ile çalıştırıldığından, instruction cache paylaşımı SRAM'i verimli kullanmanın bir yoludur
- daha fazla Compute Unit'in tek bir cache instance'ını paylaşması, instruction bandwidth gereksinimlerini karşılamayı zorlaştırabilir
MI300X ve MI300A arasındaki fark
- CDNA 3'ün nesildeki en büyük değişimi bellek hiyerarşisidir ve asıl önemli iyileştirme de Infinity Cache eklenmesidir
- MI250X'in temel sorunu, tek bir GPU olmaktan çok aynı paketi paylaşan iki GPU'ya daha yakın olmasıydı
- iki GCD arasındaki bant genişliği yön başına 200GB/s idi
- AMD, bu bant genişliğinin MI250X'i tek bir GPU gibi göstermek için yeterli olmadığına karar vererek die-to-die bant genişliğini büyük ölçüde artırdı
- MI300, toplam East-West bant genişliğini yön başına 2.4TB/s'ye çıkararak MI250X'e göre 12 kat artırdı
- toplam North-South bant genişliği ise yön başına 3.0TB/s ile daha da yüksektir
- bu bant genişliği artışı sayesinde MI300, MI250X'teki gibi 2 hızlandırıcı yerine tek ve büyük bir birleşik hızlandırıcı gibi görünebilir
- Tek bir IO die'ın toplam 4.0TB/s ingress bandwidth'i, iki XCD'nin kullanabildiği 4.2TB/s ile neredeyse örtüştüğünden pratikte büyük bir sorun yaratmaz
- ancak tek bir IO die, 5.3TB/s toplam bellek bant genişliğinin tamamını kullanamaz
- bu durum, Ryzen 7000'de tek bir CCD'nin Infinity Fabric kısıtları nedeniyle DDR5 bant genişliğini tam olarak kullanamamasına benzer
- MI300X'te bant genişliği gereksinimi, tüm die'lar birlikte çalıştığında en yüksektir ve bu durumda her die yaklaşık 1.3TB/s tükettiğinden, bunun 3/4'ünü cross-die link üzerinden almak sorun olmaz
- MI300A, aynı base die'ı yeniden kullanırken 6 CDNA3 XCD ile 24 Zen 4 core'u birleştiren bir “big iron” APU'dur
- CPU ve GPU aynı bellek adres alanını paylaşabilir
- CPU ile GPU arasında tutarlılığı korumak için veriyi harici bir veri yolu üzerinden kopyalama ihtiyacı ortadan kalkar
1 yorum
Hacker News yorumları
Teknik olarak AMD tüketici kartları hesaplama performansında harika. Örneğin UE5, üçgen mesh'leri grafik pipeline'ı yerine hesaplama ile render ediyor https://www.youtube.com/watch?v=TMorJX3Nj6U
Üstelik nVidia hesaplama performansı ve bellek bant genişliği yerine ray tracing ve DLSS'ye öncelik verdiği için, AMD kartlarının aynı sınıftaki nVidia kartlarını geçtiği durumlar da çok
Sorun şu ki hiçbir teknoloji şirketi PyTorch gibi yapay zeka kütüphanelerine D3D ya da Vulkan backend'i eklemek istemiyor. nVidia mevcut durumdan memnun olduğu için yapmıyor; Intel ve AMD ise açık GPU API'leri yerine CUDA'yı kendi kapalı alternatifleriyle değiştirmeye çalıştıkları için yapmıyor
Ancak bu ne acemice ürün ayrıştırma ne de üst düzey bir mimari sorunu. Özelleşmiş ürünler kendi alanlarında genel amaçlı ürünlerden daha iyi iş çıkarır. Hem hesaplama hem oyun tarafında iyi olan kartlara talep az; böyle insanlar var ama yalnızca bir tarafa önem verenlere kıyasla azınlıktalar
GCN'nin RDNA ve CDNA olarak ayrılmasının etkisi anında görüldü. Radeon VII (GCN 5) ile RX 5700 XT (RDNA 1) karşılaştırıldığında, oyunlarda başa baş gidip ortalamada Radeon VII biraz önde olsa da RX 5700 XT hesaplama benchmark'larında ciddi geride kalıyor. İkisi de TSMC 7nm; buna rağmen RX 5700 XT'nin shader sayısı daha az (2560'a karşı 3840), die'ı daha küçük (251'e karşı 311 mm2) ve güç tüketimi daha düşük (225'e karşı 300 W), bu da oyun verimliliğinin çok daha iyi olduğunu gösteriyor. Daha düşük güç, daha düşük gürültü ve birkaç yüz dolar daha düşük fiyat sayesinde oyuncular için çok daha cazip bir karttı
CDNA kartlarında render output unit gibi oyun için gerekli bileşenlerin eksik olduğu görülüyor. Bu yüzden resmi DirectX, OpenGL, Vulkan desteği yok. Bunlarla oyun çalıştırıldığına dair bir örnek görmedim. Buna karşılık hesaplama performansı o kadar iyi ki, ezici CUDA ekosistemine rağmen birçok şirket nVidia yerine bu kartları satın alıyor. 2013'te GCN tabanlı bir süper bilgisayar ilk 100'e girmişti ve bu, ilk 100'deki tek GCN tabanlı sistemdi. Şimdi enerji verimliliği açısından ilk 10 süper bilgisayarın 8'i CDNA hızlandırıcıları kullanıyor; genel sıralamadaki en hızlı süper bilgisayar da CDNA kullanıyor
https://www.tomshardware.com/news/amd-enables-rocm-and-pytor...
Temelde bir donanım şirketi ve (Lisa Su'nun geçmişinin de gösterdiği gibi) CUDA'nın belirleyici darbe olduğu gerçeğini hızlıca kabullenemedi. Phoronix'te @Bridgman'ın geliştiricileri elde tutmaya çalıştığı geri çekilme savaşını sürdürdüğünü hatırlıyorum. Kaybedilmesi kaçınılmaz bir savaştı
Bir ölçüde anlaşılır. 80'ler/90'lar donanım kuşağı, stack'in en üstünde donanımın yer aldığını içgüdüsel olarak düşünür; Su dahil AMD yönetiminin tamamı da o taraftan geliyor
Kodura, CUDA'nın tüketici kartlarında da çalışması nedeniyle nVidia'nın AMD'yi ezdiğini anlamıştı. Bu yüzden Lisa Su'ya karşı Radeon VII'yi zorladı; o kart da çok yakın zamana kadar yıllar boyunca ROCm'un desteklediği tek tüketici kartıydı. Kısa süre sonra fiilen kovuldu ve mükemmel bir kart olan RVII de hızla rafa kaldırıldı. Ardından Wang geldi ve tüketici/profesyonel ayrımını sağlamlaştırdı
AMD şimdi çaresizce geri dönmeye çalışıyor ama çok geç kaldı. Rekabet etmeye çalışan birçok yer var, fakat aslında kayda değer olan neredeyse yalnızca AAPL ve Metal
AMD fırsatı kaçırdı
Yine de bunun AMD kartlarının hesaplama işlerinde benimsenmesi için iyi olduğunu sanmıyorum. CUDA'nın güzel yanı, CUDA kodu geliştirmek için özel bir hızlandırıcı karta ihtiyaç olmaması
Kendi paralarıyla ya da araştırma fonlarıyla, sıradan tüketicilerle aynı fiyatı ödeyerek GPU almak zorunda kalsalardı durum farklı olabilirdi
Kişisel olarak NVidia'nın akademi ve üniversite araştırma ortamlarına sızma biçimini son derece etik dışı buluyorum
Sonrasında da beklemeye devam ettiler ve yaptıkları ürünlerin pazarının “geleceği” üzerine şirketi birkaç kez ortaya koydular
Son birkaç yılda bu gerçekten yaşandı ve hisse fiyatına da yansıdı. Diğer oyuncular temelde 10 yıl geride; mevcut aşırı ısınmış ortam ve AI/ML iş akışlarının yaygınlaşması düşünüldüğünde birinin yetişmesi neredeyse imkansız görünüyor
Buna karşılık CUDA kodu, yeni Nvidia kart nesilleri çıktığında da çalışmaya devam etti
Çoğu kişi A6000 ve üstünü Exxact ya da Supermicro gibi şirketlerden tüketici fiyatıyla satın alıyor
V100 dönemi, yani DGX-1 sisteminden bu yana araştırmacıların ücretsiz GPU aldığını hiç görmedim sanırım
CPU'lardan farklı olarak GPU'lar bunu doğrudan telafi etmeye çalışmaz. Daha yüksek gecikmeyi kabul etmek yerine CPU'lara kıyasla çok daha geniş, hatta agresif biçimde paralelleştiler; çok sayıda paralel sözde iş parçacığı da gecikmeyi gizleme etkisi sağlıyor
Bu etki örneğin GPU kodu optimizasyonu sunumlarında da görülebilir
https://www.olcf.ornl.gov/wp-content/uploads/2019/12/03-CUDA...
11. slayttan itibaren gelen animasyon bunun bir örneği
Yani birçok iş tamamen register'lar ve LDS üzerinde yürütülebilir; global belleğe erişim, neredeyse her şeyin global bellekte olduğu ve mimari register sayısının 16 civarında kaldığı CPU'lara göre çok daha seyrektir
Yine de global bellek bir sorundur. Çünkü mesele yalnızca gecikme değil, bant genişliğidir de. Bu yüzden RDNA2 ve Ada büyük miktarda son kademe önbellek ekledi. Bu, gecikmeyi daha iyi gizlemek için de var ama asıl amaç bant genişliği yükselticisi işlevi görmesi
Very long instruction word (VLIW), komut düzeyi paralelliğinden (ILP) yararlanmak üzere tasarlanmış bir komut kümesi mimarisini ifade eder. Tipik bir merkezi işlem birimi (CPU) genelde programın yalnızca sırayla çalıştırılacak komutları belirtmesine izin verirken, VLIW işlemci programın paralel çalıştırılacak komutları açıkça belirtmesini sağlar. Bu tasarımın amacı, başka yaklaşımların doğasında bulunan karmaşıklıktan kaçınırken daha yüksek performans elde etmektir
İşlemci performansını artırmanın geleneksel yolları arasında komutları alt aşamalara bölüp bazılarını eşzamanlı yürütmek olan pipeline kullanımı, tek tek komutları işlemcinin farklı bölümlerinde bağımsız çalıştırılmak üzere gönderen superscalar mimari ve hatta komutları programdakinden farklı bir sırayla çalıştıran sırasız yürütme bulunur. Bu yaklaşımlar, işlemcinin tüm kararları dahili olarak vermesini gerektirdiği için donanımı karmaşıklaştırır
https://en.wikipedia.org/wiki/Very_long_instruction_word
Pek başarılı olmadı. Bu yüzden Itanic deniyordu
Varsayım, derleyicinin bağımlılıkları statik olarak yeterince iyi anlayıp birden fazla sıralı yürütme yolunu ve bazı dallanma yürütme yollarını aynı komutun içine koyabileceğiydi. Ancak pratikte derleyicilerin bunu yapamadığı ortaya çıktı; bu yüzden işlemciler sıralı komut akışı içinde bağımlılıkları ve paralelleştirilebilecek komutları dinamik olarak bulur hale geldi
Bu çok iş, çok çip kaynağı ve çok enerji gerektirir. Ayrıca yalnızca bir noktaya kadar iyi çalışır; sonrasında azalan getirilere çarpar. Bugün bulunduğumuz nokta da tam orası gibi görünüyor
Bu, komut gönderen dili değil, işlemenin kendisini ifade eder
VLIW4 veya VLIW5 gibi terimlerin belirli uygulamaları işaret ettiğini de akılda tutmakta fayda var
https://en.wikipedia.org/wiki/Single_instruction,_multiple_d...
0: https://en.m.wikipedia.org/wiki/Amazon_Elastic_Compute_Cloud
1: https://trends.google.com/trends/explore?date=all&q=Compute&...