Hirdetés
-
Igencsak szerény méretekkel rendelkezik az Aetina Xe HPG architektúrás VGA-ja
ph Az 50 wattos modellt beágyazott rendszerekbe, MI-vel kapcsolatos munkafolyamatokhoz és edge applikációkhoz szánták.
-
A Video AI lehet a One UI 6.1.1 ütőkártyája
ma Vagy hogy fogja a mesterséges intelligencia manipulálni a mozgóképeket?
-
Premier előzetesen a Demon Slayer -Kimetsu no Yaiba- Sweep the Board!
gp Elérhető lett Switch-re a játék, amely leginkább a Mario Party-hoz hasonlítható.
Új hozzászólás Aktív témák
-
#13
Abu85
HÁZIGAZDA
Petykemano
#4
Abu85
HÁZIGAZDA
válasz
Petykemano
#4
üzenetére
1) Infinity Fabric. A Rome dizájnban már mindegyik lapka ugyanannyira van a memóriavezérlőtől. Mivel manapság elég sok magról beszélünk már, így eleve ajánlott NUMA-aware programokat írni, amelyek rendkívül toleránsak a késleltetéssel. A szerverpiacon ez nagyon jellemző, és igazából az asztali szintre is kezd lejönni ez az irány, hiszen a magok száma csak nőni fog.
2) A GPU-hoz raksz egy HBM3-at. Az önmagában 512 GB/s. Ezt sokféleképpen lehet implementálni, mivel csak egy stackről van szó, így jó a Samsung RDL megoldása is, vagy a TSMC InFO. Több HMB stack esetén azért jóval bonyolultabb a probléma, ott az Si interposer nem úszható meg, de egyelőre az 512 GB/s elégnek tűnik.
Az IF Rome platformhoz készült verziója egy baromira gyors link IFOP szinten is. Az új verzió 100 GB/s fölötti kapcsolatot ad. Ennél gyorsabban egy mai APU-ban sincs összekötve a két részegység, a Raven Ridge-ben úgy emlékszem 51,2 GB/s az SDF. Az IFOP pedig a CAKE-be fut be, onnan pedig a belső SDF-be mindegyik chipleten. IFIS, vagyis tokozások közötti kapcsolat esetén van igazán lényeges késleltetése az Infinity Fabric technológiának, és azzal az interfésszel a sávszélesség sem olyan nagy. Viszont legyen szó IFIS vagy IFOP összeköttetésről, a memóriakoherencia biztosított.
Ha Rome platformhoz hasonló lesz a dizájn, akkor a memóriavezérlő az I/O lapkában lesz. A GPU és a CPU csak chiplet. A GPU-hoz hozzáköthető a HBM, de ezt optimális csak cache-ként működtetni.
(#12) Yany: Itt azért nagyon sokat jelent, hogy mivel a magok száma drasztikusan elkezdett növekedni, a programfejlesztések is elindultak a NUMA-aware felé a desktop szinten. Ergo pusztán a program oldalán kezd toleránssá válni a rendszer a késleltetésre.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#21
Abu85
HÁZIGAZDA
Petykemano
#16
Abu85
HÁZIGAZDA
válasz
Petykemano
#16
üzenetére
Szerintem nem fognak külön GPU chipletet tervezni ide, hanem van egy normál GPU, és azt rakják ide, illetve VGA-ba is.
Egyelőre a GDDR6 elképesztően drága, és eközben a fogyasztása sokkal rosszabb a HBM-nél. Az egyetlen, ami mellette szól az a kiépíthető mennyiség, de ez az AMD-nek nem probléma a HBCC miatt. Nem véletlen, hogy már a kisebb Vega esetében is HBM-re mentek. Olcsóbb lett mára a GDDR5X/6-os opcióknál, és még nincs is itt a Samsung low-cost csomagja, ami tipikusan a belépőszintet célozza a karakterisztikájával. Nem véletlen, hogy a Samsungnál különösebben a GDDR6-ról nem beszélnek, mert hatékonyságban mérföldekre van a low-cost HBM-jüktől, és ugye ehhez már Si interposer se kell.
Persze a nagyobb buszszélesség szintjén nem úszható meg a normál HBM és az Si interposer, de ugye, ha 2 TB/s-ot akarsz, és nyilván jövőre az a cél, akkor ott eleve megépíted a rendszert, aztán kérsz érte egy borsos árat. A lényeg a Samsung low-cost megoldásával az, hogy maga a HBM a GDDR-ek alá menjen árban a belépőszinten is, és itt tényleg nem kell sok stack. Egy elég az 512 GB/s-hoz, ami azért egy entry GPU-hoz két év múlva is sok lesz.
Szerintem a GPU-ból 3D-s WoW tokozású megoldást fogunk látni először, utána pedig jönnek majd a komplexebb megoldások, de ahhoz meg kell oldani az on-chip routingot tokozás szintjén. Nagyon eltérő chiplet dizájnokkal ez nem könnyű ám (egy GPU chiplet szinten ilyen lenne). Az AMD-nem van erre egy tanulmánya, ami az aktív interposerrel kezeli a gondot, de ez azért még évekre van a tényleges bevethetőségtől.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az IF-nek több verziója van. A Zen 2-höz tervezett IFOP már 100 GB/s körüli. De itt nem ez a lényeg egyébként. ~50 GB/s is elég lenne, mert ennél most sincs gyorsabb link a Raven Ridge-ben a CPU és az IGP között. Ami a különbség az az, hogy az IF memóriakoherens, míg a PCI Express nem.
Ha mondjuk találnánk valami megoldást, hogy a PCI Express helyett legyen valami memóriakoherens interfész, hasonló sebességgel, akkor igazából nem kellene dolgozni az integráción, de jelenleg az egyetlen szabvány erre a CCIX, amit az Intel és az NVIDIA mereven elutasít. Az NVIDIA NVLinkje is memóriakoherens, csak az elől meg az AMD és az Intel zárkózik el. Tehát itt nem technikai problémáról van szó, hanem arról, hogy a gyártók már most azon dolgoznak, hogy szopassák egymást a különálló részegységekkel, így rá legyél kényszerítve, hogy ugyanattól vedd a CPU-t, akitől a GPU-t vásároltad. Erre van mindenkinek saját memóriakoherens megoldása. Az AMD-nek az IF GMI linkje, az NV-nek az NVLink, míg az Intelnek a UPI. De amúgy, ha mondjuk megegyeznének abban, hogy akkor legyen CCIX mindenkinek, akkor még memóriakoherens formában is mehetne tovább a gyártók keverése.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A PCI Expresst nem kell kukázni. Annak semmi baja. Persze nem memóriakoherens, de ez egyáltalán nem ér meglepetésként senkit, hiszen a PCI Express specifikációja évek óta ismert. Ha a GPU továbbra is a CPU szolgája marad, akkor nem is kell amúgy memóriakoherensnek lennie. Ellenben a HPC-piacon már eléggé alakul át ez a terület. A Linux esetében elég sokat módosítottak már a kernelen ahhoz, hogy ha a gyorsítót akarod célozni, akkor ott már van arra is lehetőség, hogy a GPGPU-s API-k a kerneleket közvetlenül futtassák, ehhez persze implementációtól függően ma még kellhet a PCI Express 3.0 AtomicOp, de működik, és ezáltal a kerneleknek már nem kell tartalmaznia az OS rendszerhívást is, vagyis amikor egy GPGPU-s program elindít egy kernelt, akkor nem kell megkérni az OS-t, ezen belül is egy erre vonatkozó szervizfolyamatot, hogy indítsa el azt a programot futtató felhasználónak, az adott API implementációjának kernel driverén. Gyakorlatilag az AMD IF GMI-je és az NVIDIA NVLinkje ennek a továbbgondolása a teljes memóriakoherenciával. Ha nem lenne ugye erre szükség, akkor ki se fejlesztették volna. Ugyanez igaz a Xilinx saját megoldására, csak ők ugye a CCIX-et fogják használni erre a célra. Mondjuk mást igazából nem tehetnek, az az egyetlen szabványos memóriakoherens interfész. A CAPI, illetve az OpenCAPI esetleg még opció lehetett, de valószínűleg jobbnak látták, ha az x86/AMD64-es hosthoz igazodnak, és nem a Powerhöz. Ez tisztán üzleti döntés lehetett, ők minden bizonnyal több FPGA-t adnak el x86/AMD64-hez, tehát nincs okuk abban kételkedni, hogy az ACAP-pal ez nem így lesz.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
Új hozzászólás Aktív témák
ph Úgy néz ki, hogy az APU-ból már sosem lesz nagy teljesítményű fejlesztés, ráadásul ennek még oka is van.
