-
Fototrend
OLVASD VÉGIG ALAPOSAN MIELŐTT ÚJ HOZZÁSZÓLÁST ÍRNÁL!!!
Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
válasz
Oliverda
#20953
üzenetére
Az OpenCL 1.2 és 2.x teljesen jó nyílt alternatíva, míg sajátnak ott a HIP. Erre még van olyan eszköz is, ami a CUDA kódokat lekonvertálja (HIPify). Az új kódok ráadásul írhatók HIP C++-ban, amiből fordít a HCC és az NVCC is. Tehát fejlesztőként a HIP C++-ból kapsz GeForce-on és Radeonon futtatható kódot. Ráadásul az NVCC az NV-nek a fordítója, tehát semmivel nem lesz lassabb a programod, mintha CUDA C++-ban írtad volna. De tényleg mindegy, hogy miben írod, a HIPify lekonvertálja legalább a kód 99,x%-át, elvégre a HIP a CUDA másolata, effektíve annyiban különbözik, hogy a függvények neve más (eléjük van írva a hip és ennyi), de ugyanazt csinálják. Ilyen formában nem látom az értelmét még egy API-nak.
-
Abu85
HÁZIGAZDA
válasz
leviske
#20951
üzenetére
Mert már nincs értelme a HSA jelölésnek. A ROCm van helyette, ami pedig egy platform. Kb. abba a kategóriába esik, amibe az OpenCL. Innentől kezdve az is lehet a kérdés, hogy az OpenCL-t miért nem írják oda.
A legtöbb félreértés abból ered, hogy sokaknak fingjuk sincs arról, hogy mi a HSA. Még ma is látom, hogy ez valami OpenCL alternatívaként van felfogva, pedig marhára nem az. A magyarázattal sem megyünk semmire, mert annyira tisztában kell lenni pár alapfogalommal, hogy ezek nélkül nem érti meg a user, akár elmagyarázzák, akár nem. Az is tévhit, hogy ehhez APU kell. A ROCm implementációhoz jó egy Ryzen/EPYC, esetleg új Xeon/Core, mellé mondjuk egy Fiji, Polaris 10, vagy egy Vega Frontier és működik. -
Abu85
HÁZIGAZDA
válasz
leviske
#20948
üzenetére
A HSA nem fícsőr. Az AMD-nek a szoftverkomponensei több részből állnak. Most leszámítva a legacy layereket, koncentrálva csak a modernekre, van AMDIL-jük, ehhez közvetetten kapcsolódik az egyes API-khoz írt ICD-kben a PQL, illetve maguk az ICD-k a grafikus API-nál a PAL rétegen vannak rajta, míg a dedikált compute API-nál natív a hardverek elérése. A HSA mindössze arról szól, hogy az AMDIL helyére van a HSAIL, míg a PQL helyére az AQL. Az egész HSA nem több ennél. Persze ezt az teszi erőssé, hogy más gyártónál nem külön IL és QL van, hanem minden alapítványi tag ugyanúgy HSAIL-t és AQL-t használ. Emiatt például ki tudod alakítani úgy az OS-t, hogy maga a GPGPU-s modell ne olyan legyen, hogy a GPGPU-s driver megkéri az OS-t, hogy egy rendszerhívással indítsa el az adott GPGPU-s kernelt. És most ez független az API-tól. Egyelőre ezt Linuxon lehet megtenni, illetve az se biztos, hogy a Microsoft és az Apple nem hoz saját szabványosított IL-t és QL-t.
Tehát alapvetően te mint felhasználó a HSA-ból nem fogsz látni semmit, mert ez a rendszerkomponensek része. Valószínűleg sokan nem hallottak még az AMDIL-ről, a PQL-ről, a PAL-ról, a HSAIL és az AQL is csak azért lehet ismerős, mert ezek voltak az első szabványos megoldások. Amiről a user hall azok az API-k vagy konkrét platformimplementációk, amelyek ezeken a komponenseken futnak. Ilyen például a DirectX 12, a Vulkan, vagy a Mantle. Ezek az AMDIL-re, a PQL-re és a PAL-ra vannak implementálva, a meghajtó oldalán egyedül ICD-ben térnek el. A ROCm pedig az AMD-nek a HSA implementációja. Az is fontos, hogy a HSA sem egy APU-only dolog az AMD implementációjával. A ROCm simán működik dedikált GPU-val is persze kell a PCIe Platform Atomics képesség hozzá, de működik. Igazából akármilyen összeköttetéssel kompatibilis, ami képes IO Atomics-ra, például jó lesz a GenZ, vagy az AMD saját GMI-je is. -
Abu85
HÁZIGAZDA
Azért maga a közös címtér nem egy HSA-only dolog. Ebből egy rakás másik API/platform előnyt tud kovácsolni. Például az OpenCL 2.0, a DirectX 12, hamarosan a Vulkan is.
Alapvetően a ROCm is, csak azért ez egy marhára speciális dolog, ami egy rakás nem szabványos dolgot is tartalmaz. Például olyan OpenCL 2.0-féle verziót, amely többek között nem támogatja a pipe-okat. És ez azért nagyon nem egy legális dolog, de persze egy rakás HPC-be szánt alkalmazás OpenCL 1.2-re van írva, és marhára nincs se pénz, se kedv ezt OpenCL 2.0-ra portolni, így az AMD csinált egy köztes verziót, amivel kihasználhatók bizonyos fontos OpenCL 2.0-s képességek, anélkül, hogy marha sok pénzt el kellene égetni a portolásra. -
Abu85
HÁZIGAZDA
Igazából lehet számszerűsíteni, csak nincs értelme, mert már magának a WDDM 2.0-nak is vannak igen komoly igényei az integrációk felé. Egy hardver meghajtója visszajelezheti, hogy az adott lapka UMA, gyorsítótár-koherens UMA, és/vagy izolált MMU módban működik. Ezek az IGP-s procik mindkét UMA módot, illetve az izolált MMU-t jelezhetik vissza, míg a dedikált GPU-k nyilván csak az izolált MMU-t (persze logikailag az UMA nincs kizárva, csak hát a PCI Express...). De nyilván maga az UMA, főleg a gyorsítótár-koherens verzió biztosan extra tranyóba kerül, elvégre ajánlott egy címfordítást gyorsító egység multiprocesszorokba, kötelező a megfelelő IOMMU a lapkába integrált északi hídba, illetve egy hatékony belső buszrendszer sem árt. A Raven Ridge az utóbbi szempontból újított a korábbi Carrizóhoz képest.
Ma egyébként még nincs nagy jelentősége az UMA módoknak. Leginkább az alap UMA-t támogatják a meghajtók, annak ellenére, hogy az Intel (Broadwell-től) és az AMD (Kaveritől) újabb APU-i vagy IGP-s CPU-i is képesek mindkét UMA módot támogatni. De amúgy a gyorsítótár-koherens UMA egy fontos dolog lesz azzal, hogy a Microsoft megvette a Simplygont és a Havokot. Ezek tipikusan olyan számításokat végeznek, ahol a gyorsítótár-koherens UMA aranyat ér. Bár valószínűleg a Microsoft jobban örülne az AVX512-nek, de alig van proci, ami támogatja, gyorsítótár-koherens UMA-t viszont nagyon sok eladott hardver kezel. -
Abu85
HÁZIGAZDA
Nem szorult háttérbe, csak a HSA igazából egy alapítvány. Addig volt lényege, amíg a specifikációt lefektették. Mivel ez kész, mindenki a saját HSA-ra építő implementációját csinálja. Az AMD-nek például ez a ROCm.
Androidon a HSA-t a gyártók az AI-hoz használják egyelőre, de ott is saját néven. Ez fontos, mert a gyártók meg akarják különböztetni az elgondolásaikat. A HSA igazából nem több egy specifikációnál. Ilyenje egyébként minden gyártónak volt, csak külön-külön írták meg. A HSA csupán annyit csinál, hogy egységesíti az vISA-t és a QL-t. Tehát értsd úgy, hogy a gyártók nem tettek többet, mint az egyes implementációikban szabványosra cserélték a korábbi komponenseiket.A Raven Ridge tudja mindazt, amit például a Carizzo. Van program, például bármelyik WDDM 2.0-t használó játék UMA-kompatibilis.
-
Abu85
HÁZIGAZDA
válasz
Oliverda
#20462
üzenetére
Más garantálni és más lehetőségként felkínálni. Utóbbi gyakorlatilag tuningnak számít. Ha véletlenül nem működik, akkor nem fog a hivatalos support csatornán segítséget nyújtani se az AMD, se az alaplapod gyártója, se a memóriagyártó. Maximum a fórumokban érdeklődhetsz válaszokért.
-
Abu85
HÁZIGAZDA
válasz
-=MrLF=-
#20447
üzenetére
Nagyon vékony a Lenovo notija. Általában 14 mm alatt eleve csak egy csatorna van felhasználva lényegében platformtól függetlenül, mert nem lesz beépítve az integrált memória mellé egy SO-DIMM, amivel az integrált memória kétcsatornásra bővíthető. Kétcsatornás memóriát pedig egy bizonyos árszint alatt nem szoktak integrálni.
Egyébként különösebb hátrány ezt a kategóriát most nem éri az egycsatornás memóriával. Annyi csökkent a memóriabusz terhelése az architektúra áttervezése miatt, hogy az új IGP még egy csatornával is gyorsabb az előző generációs AMD IGP-nél. A 2700U-s referenciaplatform a Time Spy-ban egy csatornával 550 pont körül teljesít, ami még mindig jobb eredmény a 35 wattos Bristol Ridge kétcsatornás ~400 pontjától. És akkor ez még NGG nélküli meghajtóval van, ami azért fontos, mert az NGG még tovább csökkenti a memóriabusz terhelését.
-
Abu85
HÁZIGAZDA
válasz
Yutani
#19798
üzenetére
Valószínűleg ez a projekt egy kényszerű irány. Krzanich eléggé leépítetté a Broadwell után a grafikus részleget. A gaming részleget a sikerek ellenére kivégezte, nemrég pedig leépült az advanced technology részleg, ami a grafikus technológiákat kutatta. Renduchintala az, aki manapság korrigálja Krzanich hibás döntéseit, állítólag ő az, aki a grafikát életben akarja tartani. Valószínűleg van háttérfejlesztés, de nagyon messze van, így addig kihúzzák ilyen MCM-mel. Nem mellesleg rengeteg rendszerprogramozót kell majd visszacsábítani.
-
#19790
Abu85
HÁZIGAZDA
darealkilla
#19789
Abu85
HÁZIGAZDA
válasz
darealkilla
#19789
üzenetére
Az API annyira nem válogatós. Ráadásul a Metal drivereket az Apple írja, kivéve a shader fordítót, mert azt részben a GPU fejlesztője szállítja.
Az egyébként nem kizárt, hogy a fejlesztők jelentik a problémát, mert például az UE4 is csak a GCN-en támogat mulri-enginet a Metal API-val. Hiába van benne ez az Intel IGP-k Metal drivereiben. -
Abu85
HÁZIGAZDA
válasz
stratova
#19784
üzenetére
Hardverben igen, csak az Intel IGP-k szoftveres fronton nagyon viasza vannak fogva. Sokkal többet tud a dizájn, mint amennyit kiaknáznak belőle a driverek. Például meg mindig nincs aszinkron compute, pedig a Gen9 óta annyira képes a hardver, amennyire a Maxwell és a Pascal ebből a szempontból. Csak a meghajtó nem támogatja. Tucatnyi hasonló limit van a rendszerben.
-
Abu85
HÁZIGAZDA
A semi-custom azt szállít, amit megrendelő kér. Az AMD az igénylő elé rak pár alapot, és abból lehet választani.
Én azon is csodálkoznák, ha Polaris lenne, mert a semi-custom részleg még a GCN3-at sem tette rendelhetővé. Van GCN2, és azon tudnak módosításokat végezni.
Ha Polaris kell, akkor nagyobb az esélye, hogy egy szimpla megrendelést ad le az Intel a Polaris 12-re. Az elég picike lapka, hogy ráférjen az Intel tokozásaira.
-
Abu85
HÁZIGAZDA
Az, hogy miért éri meg az AMD-nek igen egyértelmű. Egyrészt a pénz, másrészt a semi-custom egy technológiákat felhasználó üzletág az AMD-n belül. Vagyis saját alapfejlesztéseik igazából nincsenek, csupán az AMD architektúráit veszik át, és a megrendelő igényei szerint átalakítják és kiegészítik. Ez addig nagyon jó, amíg egy ilyen termék speciális igényekre készül, lásd konzolok, esetleg egyedi szerverek vagy beágyazott piacot célzó holmik. A versenyre a semi-custom nem igazán alkalmas, főleg nem az AMD saját termékek ellen, mert a semi-custom üzletág generációs lemaradásban van. Például ha az Intel az idénre tényleg akar egy MCM cuccot, akkor az maximum egy Polaris lesz. A Vegát talán egy ev múlva kapja meg a semi-custom részleg.
Főleg ez az oka, hogy az aktívan versenyt megkövetelő területeken inkább az IP licencelése vált általánossá, mintsem egy termék megrendelése. -
Abu85
HÁZIGAZDA
Az MCM-nek a baja az, hogy a tokozást megdrágítja, illetve a kép lapka tokozáson belüli összeköttetése problémát jelent a tokozás méreténél. Nagyon jól kell megtervezni a huzalozást, hogy a tokozás mérete kicsi legyen. Tehát az elsődleges indok ellene az, hogy drágább a gyártás, illetve a tokozás nagyobb lesz, ami növeli a platformdizájn méretét is. Ezek manapság elég fontos érvek. Viszont minden gyártó problémája eltérő, tehát a pro-kontra érvek másképp csapódnak le az egyes cégeknél.
A legjobb egyébként tényleg az egy lapka, de nem azért, mert nagyságrendekkel gyorsabb lesz a CPU és az IGP belső összeköttetése. -
Abu85
HÁZIGAZDA
Nincsenek olyan fizikai távolságban a lapkák, hogy ez radikálisan rosszabb legyen. Picit biztosan rosszabb lesz, de elfogadható mértékben. Chipen belül sem sokkal rövidebb a huzalozás. A busz sebessége sem annyival rosszabb. Szóval az MCM lesz a legkisebb gond, sőt, nem is igazán gond.
(#18895) Oliverda: Elképzelhető, hogy a 16 CU az Zen+GCN volt.
-
Abu85
HÁZIGAZDA
válasz
seolwon
#18883
üzenetére
Hogyne használnák ki a draw streamet? Mindegyik alkalmazás használja, amit elérhető lesz a hardver. Ezért nem kifejezetten jó stratégia ez. De az Intel tudja, bár szerintem ez megint az idióta vezetőség újabb rossz döntése.
(#18884) Fiery: Egy embedded diában volt benne. Ugyanazt a lapkát kapja a Raven Ridge, tehát maximum 16 CU lesz benne.
(#18886) Fiery: Az MCM-nek különösebb hátránya nincs. Még az egységes virtuális memória is használható vele.
-
Abu85
HÁZIGAZDA
A Raven Ridge egy VEGA és 16 CU van benne. Egy MCM dizájnt idén hozhat az Intel, de a semi-custom divízió még csak a Polaris fícsőröket tudja használni.
Az Intelnek az MCM nem a szerver miatt fontos, hanem amiatt, hogy leépítették a grafikus részleget. De ez azért nem tökéletes stratégia, mert például a Raven Ridge-re leghamarabb akkor tudnak válaszolni, amikor az AMD semi-custom divíziónál elérhető lesz a VEGA, vagyis nagyjából 2018 vége. Persze valószínűleg így is jobban járnak, mintha saját rendszert használnának, viszont az ilyen üzlettel az Intel leginkább másfél év hátrányt vesz csak. Gondolom kiszámolták, hogy az nem olyan rossz, ahhoz képest, ahol most tartanak, illetve később még ott a 3rd party IP lehetősége is.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#18478
üzenetére
A sample-ök ugyanazt az összeillesztést használják, amit a Kaveri első generációs verziója. Mivel ezzel is olyan alacsonyak a hőfokok, mint egy 95 wattos TDP-jű 7850K-n, így jó esély van rá, hogy a végleges is ilyen pasztával jön. Ha forrasztják, akkor a 7870K-ből ítélve, ami szintén forrasztott volt, annyira sokat nem nyernek. Maximum -5-6 fokot. Ez kb. 60 helyett 55 fokos terheléses átlag hőmérsékletet jelentene gyári hűtővel. Persze lehet, hogy végül úgy döntenek, hogy ezzel minőséget akarnak sugallni, és mégis forrasztják, de egyértelműen nem éri meg annyiért, amennyit nyernének vele.
-
#18443
Abu85
HÁZIGAZDA
Petykemano
#18442
Abu85
HÁZIGAZDA
válasz
Petykemano
#18442
üzenetére
Ja ... hát nem tudom. Nyilván azért, mert nem akarják, hogy idő előtt kiderüljön, hogy mit tud igazából. Másért nem érdemes védeni terméket.
-
#18441
Abu85
HÁZIGAZDA
Petykemano
#18438
Abu85
HÁZIGAZDA
válasz
Petykemano
#18438
üzenetére
Minek? Annak, hogy nincs leak? Nincs mit leakelni. A Socket AM4-es alaplapok már léteznek. X370-es leak pedig nyilván nem lesz. Erre NDA van.
A leakhez egyébként olyan ember is kell, aki hajlandó kiadni az NDA-s anyagokat. Mivel az AMD az elmúlt fél évben tisztogatott, így elég nehéz manapság leaket várni. A VEGA-ra is igen kevés slide van kint, holott decemberi a pdf. Eredményes volt a tisztogatás, és a tipikus leakelő embereknek már nem küldik el az anyagokat.
-
-
Abu85
HÁZIGAZDA
válasz
#85552128
#18433
üzenetére
Nem is fog a megjelenésig. Borzasztóan elzárták a leak lehetőségét. Csak a hibás ES-ek vannak kiküldve, míg a végleges verziót zárt csatornákon küldik. Az Athlon 64 óta nem védtek ennyire procit.
Valószínűleg leakek továbbra is lesznek az első revízióval, de ugye a végleges a második revízió lesz. -
#18376
Abu85
HÁZIGAZDA
Petykemano
#18374
Abu85
HÁZIGAZDA
válasz
Petykemano
#18374
üzenetére
Hónapokkal a start előtt. Szerinted? Mégis kinek lenne végleges processzora, amikor az AMD nulla darabot szállított a média felé. Elmondom mikor lesznek tesztek, amikor az NDA lejár.
-
Abu85
HÁZIGAZDA
A Raven Ridge simán megkaphatja a PS4 Pro GPU IP-jét. Az igen régóta kész van. Az sem kizárt, hogy a Sony technikáját behozzák a Vegába, és akkor nagyon is jó döntés a PS4 Pro GPU IP-je, mert abban már van Super-Stencil. Ez megold egy olyan problémát, amin lassan egy évtizede töri a fejét a Microsoft.
-
Abu85
HÁZIGAZDA
válasz
Ragnar_
#18332
üzenetére
A következő konzolgeneráció még legalább 4-5 évre van, de a köztes generáció miatt szerintem elhúzzák.
Valószínűleg a 4 mag lesz PC-n az új abszolút minimum. Már csak azért is, mert számos lehetőséget teremt az aszinkron compute, tehát ha nagyon kellene a 6 mag, akkor át kell rakni pár feladatott a GPU-ra, és újra elég a 4 mag. Ez meglepően jól működik a Nitrous motor új verziójában, és emiatt több fejlesztő is ilyen irányba mehet, hiszen így kezelhető az a probléma is, hogy a szoftveres korlátok miatt sok gyártó nem lépdelt erősen a több mag felé. A Frostbite és a Dawn is kellemesen elvan ezekkel az alternatív irányokkal, lásd az async compute GPU-s kivágás, amit egyébként alapesetben egy rakás játékban a CPU csinál meg, de nincs elég erőforrása rá egy négymagosnak.
-
#18331
Abu85
HÁZIGAZDA
Malibutomi
#18329
Abu85
HÁZIGAZDA
válasz
Malibutomi
#18329
üzenetére
A magszám emelése igazából egy iparági igény is. Tíz éve léteznek legalább két magos procik, és csak egy éve tudnak a fejlesztők több szálon parancsokat kreálni szabványos formában. Amikor a hardver és a lehetőségek között ekkora kontraszt alakul ki, akkor azt mindig egy robbanásszerű szoftveres fejlődés követi, mert kilenc év alatt a kutatások történtek (már csak a konzolok miatt is, ahol ez a probléma nem létezett), csak azokat nem sikerült implementálni egy PC-s portba, emiatt sok esetben multiplatform szoftverbe sem. Most viszont leporolható számos kutatás az elmúlt kilenc évből.
-
Abu85
HÁZIGAZDA
válasz
Ragnar_
#18328
üzenetére
Ezt nagyrészt az alakította ki, hogy az aktuális grafikus API-kban a parancsok kreálása nem rakható ki több szálra. De itt a DX12 és a Vulkan. Ráadásul minden eddig megjelent játékban minimum 16 szálig skálázódik a parancskreálás, de vannak olyan címek, amelynél 32 szálig. Azért ez nagy különbség a DX11-es "egy szálon fut a parancskreálás és kész" lehetőséghez.
A magokra vonatkozó igény ezzel a váltással megnő. Például a Nitrous motor minimum négy magot kér, nem szálat, hanem fizikailag létező magot. A következő verziója minimum hat magot fog kérni, de már elkészült egy olyan optimalizálás, hogy aszinkron compute-ot támogató VGA mellett elég a négy mag is. A Frostbite dettó erre megy. Az új Mass Effectbe kerülő verzió 24 szálig skálázódik.
-
Abu85
HÁZIGAZDA
Csak az a baj, hogy az alternatívának tekinthető SGX jóval több ponton támadható. Nem azért, mert a koncepciója hibás, hanem azért, mert a támadók okosak, és mindig meg fogják találni az egyes rendszerek gyenge pontjait. A SEV/SME elsődleges célja az volt, hogy az SGX helyére kerüljön jóval erősebb védelemmel. Ezt teljesíti is, de ettől még ugyanúgy okosak lesznek a támadók, és találnak ezen is fogást. De a fogás ezekkel az SGX, illetve most a SEV/SME rendszerekkel egyre kevesebb. Tehát maga az összeállítás egyre kisebb felületen támadható, de amíg megéri támadni, addig mindig találnak rést a pajzson.
Eleve senki sem nyilatkozik olyat, hogy bármilyen hasonló konstrukció hibátlan lehet. Azért nem, mert sok az okos támadó odakint.
Az AMD ezt inkább azért nyilatkozta jelenleg, mert az eredeti anyag több helyen csak feltételezi a szoftveres implementációt, de valójában nem tudják, hogy az AMD hogyan fogja megoldani. -
Abu85
HÁZIGAZDA
Nem hibás az sem. Csak megkérdőjelezik, hogy elég jó-e. Ugyanakkor lényegesen jobb, mint az eddigi megoldások.
Az ilyen konstrukciók sosem fognak mindent kivédeni. Egyszerűen azért, mert a támadók előnyben vannak az idő tekintetében. Viszont arra kell törekedni, hogy a lehető legtöbb támadási felületet lefedjék. A SEV/SME lényegesen többet lefed, mint az eddigi SGX. De nem fed le mindent. Lehet, hogy egy későbbi implementáció még többet fog tudni. Sőt, ez szinte biztos.
A koncepció viszont nem hibás, mert az SGX-hez képest nagyságrendi az előrelépés. Ez egyébként azt is jelzi, hogy mennyire mások a piac igényei, mint amit a jelenlegi hardverek képesek kiszolgálni.
-
Abu85
HÁZIGAZDA
válasz
Ragnar_
#18168
üzenetére
A Dota2 játékosok nagyon jó reklámfelületet jelentenek. Sokan vannak és mennek 300 fps-re is, ha végre lesz elérhető áron termék, ami biztosítja. Aki pedig ilyen fanatikus viszi magával a tömeget, mert ő profi játékos, biztos profi cuccot használ, tehát jó lesz az a rajongóinak is. Nem kell agysebésznek lenni hozzá, hogy átlátható legyen a stratégia.
-
Abu85
HÁZIGAZDA
Az egy marketing aranyszabály, hogy ha jó a termék, akkor a megjelenés előtti "agymosás" nem elég hatékony. Ugyanis ilyenkor sokkal kedvezőbb az, ha a hype-ot a potenciális vásárlók generálják.
Bizonyos értelemben ma már minden a hype-ról szól, és különböző tapasztalati kimutatások vannak, hogy milyen versenyképességű terméknél mi az ajánlott stratégia. Bár általános koncepciók nincsenek, de ha nagyon jó egy termék, akkor el kell vágni a szivárgásokat, különösen a jó hírt hordozókat. Egyszerűen maga a várakozáson felüli értékek megsokszorozzák a hype hatását.
Úgy érdemes ezt felfogni, hogy alakuljon ki a termék körül egy trendiség, hasonlóan a divathoz. Nem kell minden évben új cipő, de a divat megveteti. -
Abu85
HÁZIGAZDA
Ezzel kapcsolatban még annyit, hogy nem akarok itt politikázni, de nézd meg miképp működik ma az ország. Van a valóság, és amit a mondanak a politikusok, és utóbbiból a polgárok kreálnak egy alternatív valóságot. A gyártók is pont ugyanilyen módszerekkel dolgoznak, pont ugyanilyen, sőt nagyobb hatékonysággal. Tehát borzalmasan egyszerű a médiafelületeken agyat mosni, csak tudni kell a megfelelő módját.
-
Abu85
HÁZIGAZDA
Ha megnézzük a múltat, akkor ez a nyilatkozat a legbiztatóbb. Mindig akkor volt erős egy termék, ha eldugták és teljesen visszafogottan nyilatkoztak róla. Amikor pedig gyenge volt már a megjelenés előtt előre "széthájpolták". Ez nagyon tipikus viselkedése az AMD-nek. Bár a vezetők jöttek-mentek, ez a viselkedési forma látszólag nem változott. Azt is megmondom, hogy miért csinálják. A hype jó darabig elad egy terméket, legyen az akármilyen. Ez a része marketing, az emberek agyába már a megjelenés előtt beleverték, hogy ezt kell venni. Erre pedig megvannak a megfelelő kulcsszavakra építő "agymosó" módszerek. Például az egyik, hogy ilyet nem szabad mondani: Zen has opportunity to do well in certain workloads.
-
#18132
Abu85
HÁZIGAZDA
Petykemano
#18129
Abu85
HÁZIGAZDA
válasz
Petykemano
#18129
üzenetére
Ez attól függ, hogy mit tartanak jobbnak a marketingesek. Az AMD-nél az az elsődleges gond, hogy sokan AMD-t AMD-vel párosítanak, és nagyon sok potenciális vásárló nem tudja, hogy AMD proci mellé jó egy NV VGA is, vagy az AMD VGA működik Intel proci mellett. Erről viszonylag sokat mesélt nekem pár hónapja a hazai képviseletet ellátó személy. Az, hogy miképp akarnak üzeneteket átadni a marketingesek döntése. Egy ilyen rendezvényen kedvezőbb teljesen házon belül maradni, tehát valószínűbb valamilyen csúcs-Radeon.
-
Abu85
HÁZIGAZDA
válasz
#85552128
#18127
üzenetére
Nem valószínű, hogy a publikus verzióval tesztelnek, hanem már a javított DOTA2 programkóddal, ami amúgy is jön decemberben. Az megoldja a Vulkan fagyását a startkor. A publikus kód azért sem jó, mert az nem tartalmaz Zen optimalizálást, tehát mindenképpen egy még fejlesztett verziót használnak a játékokból.
-
Abu85
HÁZIGAZDA
válasz
wjbhbdux
#18125
üzenetére
Megvan az oka. A DOTA 2 borzalmasan jól skálázódik Vulkan módban. Egészen pontosan 18 szálig lineárisan, tehát elég jó a Zennek előzetes erődemonstrációra. Az AMD-nek pedig azért jó, mert az eSportban kezd megtelepedni az a gondolat, hogy a 144 Hz sem elég. Ezért jöttek és jönnek a 200-240 Hz-es kijelzők. Ahhoz, hogy ezekre legyen 200+ fps-ed kell a nyolc mag, még tán a 16 szál is. Ha a profik ezen játszanak, akkor a hobbi eSport játékosok követik őket a hardvervásárlásban.
-
Abu85
HÁZIGAZDA
Most is van ilyen. A DX12-es programok 12-16 szálig skálázódnak, de van az AotS, ami 32 szálig. Az új Frostbite 20 szálig fog skálázódni.
Nem értitek, hogy miért nincsenek a GPU-k normálisan kihasználva. Ezek heterogén processzorok, amiken jórészt soros feladatfeldolgozás történik. Az okozza a rossz kihasználtságot, hogy van xy grafikai munka, ami terheli a ROP-ot, a sávszélt, a tesszellátor, a setupot, és ilyenkor az ALU folyamatosan kihasználatlan. Ide egy rakás munka beszúrható. Ilyen munka például a compute kivágás, a skinning, a GPU particles, post-process, a hangokhoz a path tracing, esetleg az AI útkeresése. Az első négyet már aktívan használják is a modern motorok.
A CPU-igény nem feltétlenül fog csökkenni, mert a világ komplexitása nő, tehát több lesz a rajzolási parancs. A CPU-k egyre egyszerűbb feladatokat fognak futtatni, csak ezekből többet mint ma, jóval többet. -
Abu85
HÁZIGAZDA
válasz
leviske
#17625
üzenetére
A Dawnnal érkezik az összes Labs kötődésű Square Enix játék a jövőben. Egyedül az IO Interactive és a keleti régió marad saját motoron. A Dawnt elsődlegesen azért fejlesztette az Eidos Montreállal a Square Enix, hogy nekik is legyen egy biztos pontjuk, mert egy csomót szívtak a licencelt technikákkal.
Az idtech 6 és a leszármazottai is GPU-driven pipeline rendszerek. Innen csak egy lépés a compute culling. A következő verzióban simán bevetik, mert sokat gyorsít. Eddig azért nem tették meg, mert az AMD GeometryFX csak DirectX-re van megírva, de az a jó az open source-ban, hogy átírhatja az id magának Vulkan API-ra.
Sok NV tulajnak fáj a DX12 és a Vulkan. Nem kell foglalkozni velük. Idővel lesz működő NV hardver ezekre az irányokra és akkor alábbhagy a frusztráció.
-
Abu85
HÁZIGAZDA
válasz
Yutani
#17616
üzenetére
Ez azért alapvetően független lesz a gyártóktól. Valójában az elsődleges koncepció a fejlesztések mögött az, hogy a konzolban nem elég erősek a CPU-k. Ezért megy mindenki most arra, hogy menjen a GPU-ra akkor minden, mert ott van elég teljesítmény, és mivel a PC-re nincs külön kutatás és fejlesztés, így mi is azt kapjuk, amit a piac a konzolokból visszaoszt. PC-n arról nem vagyok meggyőződve, hogy tisztán ez a legjobb, most ezt nem mindre értem, a culling, a particles, az audio path tracing, a skinning simán jobb GPU-n. De AI-ra például van elég procierőnk, viszont a fejlesztőknek nem lesz elég pénzük két rendszert fenntartani, így nekünk is jön a konzolos modell.
-
Abu85
HÁZIGAZDA
Ehhez még annyit, hogy a GDC-n ugyanezen a kerekasztal beszélgetésen volt egy nagyon érdekes mondat, hogy a CPU azokban a motorokban, amik most készülnek, igazából csak alapvető szimulációt fog számolni, illetve a parancsokat írja be a parancspufferbe, az új API-kkal azt is explicit párhuzamosan. Tehát amíg ma a skinning, a hangszámítás, a kivágás, a komplex fizika, az AI egy CPU-s feladat, addig idén és főleg jövőre ezek mennek át a GPU-ra. Idén a kivágás és a komplex fizika már átköltözött a modern motorokban (Glacier, Dawn, Frostbite), ezek miatt jött az execute indirect, és egyes motorok már a skinninget is átnyomták aszinkron compute-tal (az új CoD motorja). A következő a hangszámítás, ami a VR miatt szükségges, de a spórolás miatt nem éri meg megtartani a CPU-s rendszereket. Végül jön az útkeresés.
-
Abu85
HÁZIGAZDA
válasz
Yutani
#17610
üzenetére
Nem annyira órajelérzékeny már ez a piac játékosokra levetítve, akiket a Zen céloz. Az Intel is azért hoz hatmagos mainstream procit a négymagosokhoz képest alacsonyabb órajelekkel, mert innentől kezdve a játékok 16-20 szálig is lineárisan skálázódnak. Ez nem csak az új API-k miatt történik, hanem amiatt is, hogy a GPU-driven pipeline teljesen általános lesz. Látható például az új Deus Ex, aminek a Dawn motorja még DX11 alatt is nyolc szálig skálázódik lineárisan, DX12-ben 16-ig. Az Intel programozója pont mondta az egyik GDC Europa briefingen, hogy nehéz lesz a marketingnek, mert eddig gémer procinak négy mag kellett magas órajellel. De jövőre ez egyáltalán nem lesz jó. Meg kell találni az egyensúlyt a magok száma és az alapórajel között. Intel szerint ez 2,8-3 GHz és 12 szál lesz.
-
Abu85
HÁZIGAZDA
válasz
Yutani
#16514
üzenetére
Persze. Ezért jön rá a fix jövőre.
Egyébként maga a dolog a fejlesztőknek is megoldható, ugyanis úgy is írhatják a játékot, hogy az eDRAM-ot használják fő memóriaként, és IOMMU-val elérik a rendszermemóriát. Ezzel viszont az a baj, hogy annyira kevés az eDRAM-os IGP a felhasználóknál, hogy nem éri meg egy ilyen alternatív memóriamenedzsmentet fejleszteni. Ez sajnos nem is olyan egyszerű.
-
Abu85
HÁZIGAZDA
válasz
Goose-T
#16512
üzenetére
Nem ez a baj. Az eDRAM nagyon speckó cucc, és az Intel a legrosszabbkor hozta be, amikor a Microsoft WDDM-et váltott. Többek között az Intelre még mindig azért nincs DX12 mód az AotS-ben, mert az új WDDM már nem támogatja a régi szegmentált fizikai címzést, amire a vállalat építettet a hardverét. Viszont a virtuális címzés mellett jön az a gond, hogy az eDRAM-os IGP-ken a fizikai címtér csak maga az eDRAM lehet, vagyis az a csupán 64-128 MB-nyi memória. Így meg nyilván nincs sebessége a programnak. Ezt a problémát majd egy jövőre érkező DX12 frissítés kezelni fogja, amely lehetővé teszi, hogy az IGP-hez a DX12-ben a nagyméretű gyorsítótárat, és a fizikai memória már egy rendszermemóriából lecsípett szelet lesz. Most vagy ezt használja az Intel vagy az eDRAM-ot. A kettőt együtt nem lehet.
-
Abu85
HÁZIGAZDA
válasz
Oliverda
#16493
üzenetére
Nem elvadult útiterv ez egyébként, csak talán gyors a tempó. Az lesz itt a baj, hogy a fejlesztők úgy állnak hozzá a váltáshoz, hogy elbasztak 5 évet és azt most be akarják hozni 2 év alatt. Sok fejlesztőnél még a kutatás része meg is van, mert attól, hogy a DX11 hurka volt a gyakorlati implementációra a kutatást levezényelték, és ha le is állították, az eredményeket nem dobták ki. Viszont szerintem az extrém igényeket jellemzően felvállaló AMD sem akar ennyire nagy lépéseket. A GDC alapján az látszik rajtuk, hogy egyelőre elég lenne PC-n elérhetővé tenni azt, amit a két konzol tud. Ez meg is lesz áprilisban, aztán a következő lépésen majd gondolkodnak.
-
Abu85
HÁZIGAZDA
Mivel az OpenCL és a HSA nem ellenfelek, így értelmetlen lenne az összehasonlításuk. A HSA egy eszköz az OpenCL-hez, mert ez az egyik nyelv, amit támogat és képes kiegészíteni azt. Ennyi. De az OpenCL nélküle is működőképes, illetve a SPIR-V miatt elég sok előnyt kap. Ebből a szempontból az OpenCL legnagyobb eredményeit az idei SYCL 2.1 fogja felmutatni, mert végre le lesz egységesítve. Egyébként az OpenCL nem elég jó ahhoz, hogy portolható legyen a teljesítmény. A SYCL sokkal jobb ilyen szempontból. A HSA-t pedig eleve portolhatóra tervezték.
-
Abu85
HÁZIGAZDA
Már írtam párszor, hogy az AVX-512 és a HSA nem zárja ki egymást. A HSA például jelen helyzetben az egyik legegyszerűbb eszköz az AVX-512 kihasználáshoz. Lényegesen kevesebb erőforrást kell befektetned vele, hogy eredményed legyen, és az a kód gyakorlatilag futni fog az FPU mellett DPS-n, GPU-n, stb.
-
Abu85
HÁZIGAZDA
válasz
Oliverda
#16484
üzenetére
Van az Oxide-nak és az általuk létrehozott fejlesztői szövetségnek egy olyan útiterve, hogy 2018-ra legyen egymillió batch/frame-re képes PC. Na most nyilván, ha a processzorok két év alatt nem gyorsulnak a hússzorosára, akkor az egymilliós határ elérésére kell egy új struktúrájú API, amivel gyorsítani lehet a parancsgenerálást. Ilyen formában a következő lépés a grafikus API-k célhardverrel történő gyorsítása.
Amióta átnyomták a Microsofton és a Khronoson az akaratukat ezek a fejlesztők, azóta eléggé "RAGE" módba kapcsoltak, és úgy gondolják, hogy bármit amit csinálnak átnyomhatnak, ha sikerül az egyik gyártót meggyőzni arról, hogy az jó, és így lesz rá támogatást.
-
Abu85
HÁZIGAZDA
válasz
Oliverda
#16349
üzenetére
Igen. Ez igazából egy adok-kapok rendszer. Se a HDL, se a HPL nem ideális, és most ezt nem az AMD-re kell levetíteni, hanem mindenkire, mert hasonló, de más hatékonyságú libjei több gyártónak vannak. Kivéve az Intel, nekik csak HPL-hez hasonló rendszerük van.
A lényeg az, hogy igazából egyik sem jó, mert amilyen előnyöket behoznak, ahhoz hátrányokat is társítanak. Viszont köztes lehetőség nincs, tehát az adott áramkörhöz azt érdemes használni, ahol több az előny. A GPU-knál ma azért a HPL-t, mert nagyon nagy része a lapkának regiszter, cache, busz, különböző fixfunkciós egység, stb. Ahol a HDL igazán segít azok az ALU-k, de ma már ezek vannak kisebbségben. Már akinek persze, de az AMD-nek a GCN-nel az ALU-kra megy relatíve kevés tranyó, mert multipreciziós egységeket terveztek. Nyilván másnak ilyenje még nincsen, tehát például az NV-nél és az Intelnél még jellemző, hogy az ALU és a hozzá tartozó ütemezés viszonylag sok tranzisztorba kerül, ugyanis a integerre és FP-re, a 32 és 64 bitre, a speciális utasításokra, mind-mind külön ALU-t használnak (az Intel ráadásul még mindig co-issue-zik, ami brutálisan rossz hatékonyságú, mert rögtön felezi a sebességet, ha függőség van a kódban), míg az AMD nem, mert multipreciziós rendszert csináltak, ami eleve helytakarékos és csúnya szóval mindent tudó. Az más téma, hogy a megnyert tranyókat elköltik regiszterre, de ez részletkérdés. A GCN tehát kb. nyerne úgy 5%-nyi lapka területet a HDL-lel, miközben vesztene 100-200 MHz-et. Egyértelmű, hogy így már a HPL éri meg, mert az az 5%-nyi lapkaterület máshogy is megnyerhető, vagy akár nem is érdekes, de az extra órajel szükséges. Nem mellesleg a 1-2 GHz-es tartomány között a HPL hatékonyabb. A HDL igazán 2 GHz fölött kezd működni, ahol tényleg jelentős előny jön a hatékonyságban.
A CPU-knál pedig az a helyzet, hogy bármit is használnak 4 GHz fölé nagyon nehéz menni. Egyszerűen a mai tervezési direktívák, és a mobil fókusz mellett minden lapkánál a 2-3 GHz közötti órajel a cél. Ott kell elérni a hatékonysági maximumot, míg a 4 GHz-et majd hozzák kevésbé hatékonyan. És a lényeg, hogy hiába van neked HPL-ed, a 4 GHz-et úgy sem fogod megugrani. Erre az órajelre pedig a HDL is képes, tehát az egyéb előnyöket beszámítva ezekre az egységekre jobb a HDL. -
Abu85
HÁZIGAZDA
válasz
Oliverda
#16347
üzenetére
Az OEM listában van benne, hogy mobilra a 28 nm jobb, mint a 14 nm LPP a standard dens. library-vel. Ugyanerről a gondról beszélt már például a Rickchip is.
Csalóka a nanométer előtti szám manapság, mert attól, hogy az kisebb még nem fog kevesebb elektron kelleni a tranyó bekapcsolásához. Egyszerűen annyira pici lesz a tömeg, hogy nem úgy viselkednek, ahogy azt a fizika törvényei leírják. Ez már a kvantumfizika területe. Tehát végeredményben azt kell elérni, hogy különböző speciális könyvtárak fejlesztésével ne a bérgyártók standard elemeit kelljen használni.
A 14 nm LPP egyedül ott jelent igazi előnyt, ha magas órajel kell relatíve alacsony fogyasztással. A HDL azt próbálja elérni, hogy máshol is legyen belőle előny. Ilyet egyébként mindenki tervezett, bár ezeknek a libeknek a hatékonysága azért jelentősen eltérő.A Zent már HDL-lel készítik. A GPU-kat HPL-lel fogják. Az ok az, hogy a HPL igazából ott segít, ha magasabb órajelet kell beállítani, de az a gond, hogy technikailag a HDL-lel is ugyanarra a határra fogsz futni, vagyis azért állt át az AMD fokozatosan a HDL-re a 28 nm-es node-tól kezdve a CPU-knál, mert a tervezett órajelet HDL-lel is elérik, miközben a fogyasztás és a tranyósűrűség jobb lesz. Mindeközben a HPL-lel nem tudnák hozni a jóval magasabb órajelet, így erre már nem éri meg lőni. A HPL a GPU-knál azért marad, mert ott a lapkának viszonylag nagy része lesz regiszter, cache, busz és hasonló olyan elem, amelynél a HDL nem nyújt igazi előnyt, vagyis megéri némi tranyósűrűséget beáldozni a magasabb órajelért. Elsődlegesen azért, mert még HPL-lel is 1 GHz körüli órajelre lőnek, vagyis bőven van tartalék.
-
Abu85
HÁZIGAZDA
válasz
Oliverda
#16332
üzenetére
Mert a HPL-lel a 14 nm-es node nem olyan jó, mint a 28 nm-es node HDL-lel. Rosszabb lenne a perf/watt.
A GPU-kat a TSMC-nél csinálták HDL-lel. A GloFo-nál az IGP-k HPL-lel készültek.
Egyébként a GloFo-nál a HDL nem ugyanaz a HDL, ami a TSMC-nél van. A TSMC-nél ezt nem fejlesztették tovább. -
Abu85
HÁZIGAZDA
Azért nincs esélye a 14 nm-nek a Bristol Ridge esetében, mert az a HDL, amit ehhez a lapkához használnak csak most lett átportolva FinFetre. Ez azt jelenti, hogy leghamarabb a Raven Ridge-hez lesz használható. A HPL-t hamarabb átportolták. Azon jönnek a GPU-k.
A specifikus HDL nélkül nem fognak majd hozzá az új APU-nak, mert standard GloFo/Samsung library mellett négyszer több hely kell ugyanannyi tranzisztor beépítésére. -
#15649
Abu85
HÁZIGAZDA
Petykemano
#15646
Abu85
HÁZIGAZDA
válasz
Petykemano
#15646
üzenetére
A heterogén multiadapter eléggé alap fícsőr a DX12-ben. A Bristol Ridge ebben nem fog funkcionálisan többet tudni, mint más WDDM 2.0-s driverrel rendelkező IGP. Az eltérést a sebesség jelenti majd. Nyilván minél gyorsabb az IGP, annál nagyobb az előny.
-
#15645
Abu85
HÁZIGAZDA
Petykemano
#15643
Abu85
HÁZIGAZDA
válasz
Petykemano
#15643
üzenetére
A Bristol Ridge számos titkolt képességet fog hozni. A Kaveri/Godavari az új BIOS-okkal ezeknek csak egy kis részét kapja meg.
A Bristol Ridge egyébként elsődlegesen az IGP-re helyezi a hangsúlyt, míg a Godavari inkább a CPU-ra. Persze itt nüansznyi különbségekről van szó, de észrevehetők. Ami miatt a Bristol Ridge lényeges, hogy WDDM 2.0 miatt rengeteg új motorba kerül olyan képesség, hogy az IGP-t dolgoztatja a dedikált GPU mellett. Egy csomó népszerű motornál a fejlesztők nem is csinálnak hagyományos multi-GPU támogatást, mert pici a piac, de elképesztően sok gépben van IGP+dGPU. Az optimalizálás szempontjából az egyik legegyszerűbb irány az eredeti programkód javítása helyett egy eddig malmozó egységet befogni a munkára. Ezt a legtöbb kiadó finanszírozza, mert biztos az eredmény ... naná, gazdagabb leszel 300-1000 GFLOPS-szal, és ez nyilván látszódni fog. Például a Nitrous motornak a kódja eléggé előrehaladott állapotban van, és egy Kaveriben az IGP kihasználása +20%-ot dob egy R9-290-re, ahhoz képest, mintha nem lenne aktív az IGP. És teszi ezt magas felbontásokon. Az Unreal Engine 4 erre vonatkozó kódja még erősen fejlesztés alatt van, de az előzetes tesztekben 5-15%-os gyorsulások jönnek az IGP és egy erősebb dGPU párosításából. Sokan ezt az egyszerű utat választották a teljesítmény növelésére az aktuális gépeken. Azt nem mondanám, hogy egyetértek azzal, hogy ez az optimalizálási forma kritikus fontosságú, vagy hogy feltétlenül felül kell írnia az amúgy normális optimalizálási lehetőségeket, de megértem az irányt abból a szempontból, hogy nagyon olcsó beépíteni és biztos eredményt ad.Az alaplapnál igazából nem nagy változás történik. Egyszerűen lesz egy extra vezérlő, amit hozzá lehet kötni a mostanihoz. Szimplán pár PCI Express sáv kell hozzá, abból pedig van sok. Igazából ilyet bárki csinálhat most is, és csináltak is páran. Az AMD csak validált egy csomagot hozzá, így az alaplapgyártóknak a validálás megspórolható. Igazából ez nem nagy kunszt a fejlesztés szintjén.
-
Abu85
HÁZIGAZDA
válasz
Gainka
#15626
üzenetére
Igen, de ott történt más változás is. Egyrészt aktiválták a TrueAudio blokkot, ami egyébként 5 wattot fogyaszt max. Persze ezt részben csökkentette, hogy a GPU optimalizáltabb lett. Viszont a memória elvitt némi keretet, de inkább +10 watt volt.
(#15628) Oliverda: A memória kapacitása helyett a memória mennyisége számít igazán. A 2 GB-ot ki lehet hozni 4 és 8 lapkából is. A 4 lapkás kevesebbet fogyaszt, mert a kétszer akkora memóriachip nem jelent kétszer akkora fogyasztást, kétszer több, viszont már igen.
-
Abu85
HÁZIGAZDA
A tervezésnél a maximum nagy probléma. A memória órajele nem állítható dinamikusan terhelés mellett, tehát amikor egy TDP keretet megszabsz a terméknek, akkor abból a keretből pont annyi kell a memóriának, amennyit a teszteken a max fogyasztás mutatott. Teljesen mindegy, hogy a memória egy átlagos alkalmazás alatt annak a felét fogja fogyasztani, és csak egy pillanatra ugrik felé maxra, a TDP keretet már elvitte. Ezért megyünk a HBM felé, mert például a következő elméleti lépcsőnek tekinthető 512 bites buszon lévő 8 GB-nyi 7 GHz-es GDDR5 már 70-80 wattot fogyaszt. Ez borzasztóan nagy keret a 300 wattos TDP-ből. És a következő utáni lépcsőnél meglesz a 150 watt, és onnantól a VGA-k csak lassulnának, mert túl kevés keret jut a GPU-nak.
-
Abu85
HÁZIGAZDA
válasz
Oliverda
#15620
üzenetére
Csak ők tudják lemérni, mert nekik vannak olyan programjaik, amelyek a memóriát maximumra terhelik. Egy átlagos programban a memória nincs állandóan ugyanolyan terhelésszint alatt, így az adatbuszok kihasználtsága közel sem 100%-os, ami ugye a legnagyobb fogyasztó.
A GGDR5 sem a DDR3-as alap miatt fogyaszt sokat, hanem az x32-es konfiguráció miatt. A busz, ami megterhelő. Ezért volt a GDDR5M annyira jó opció, mert az a GDDR5 előnyeit x16-os konfigurációba hozta volna, vagyis a nagy hátrányt, mint a fogyasztást megszüntette volna. -
Abu85
HÁZIGAZDA
válasz
Oliverda
#15616
üzenetére
Ez a tézis nem számolja bele azt, hogy a tranyó bekapcsolásához szükséges elektrontömeg nem lehet egy bizonyos szintnél kevesebb, mert a fizika törvényei már nem vonatkoznak rájuk, míg a kvantumfizika törvényeit nem ismerjük eléggé, hogy felállítsunk rá egy új modellt, amivel tovább skálázhatnánk a rendszereket. Ma már sokkal inkább számít az, hogy mekkora feszültségen és órajelen lehet egy olyan statisztikailag, lehetőleg minél kisebb elektrontömeget kezelni, ami még bekapcsol egy tranzisztort. Ha a több évtizedes elméletek működnének, ma nem lennénk bajban, és itt lennének a 30 GHz-es processzorok a 10 GHz-es memóriákkal, de nincsenek.
-
Abu85
HÁZIGAZDA
válasz
Oliverda
#15614
üzenetére
Sajnos fog. Eredetileg azért tervezték a szabványt 5-6 GHz közé, mert magasabb órajelen elszabadult a fogyasztás. Ezt ugyan ki tudták hozni stabilra, illetve hűteni is lehet, de az energiaigénnyel már nem tudtak mit kezdeni. Manapság nagyon tipikus, hogy van egy órajelszint, amit reális fogyasztással lehet hozni, és a következő lépcsőben már az extra órajel egy aránytalan fogyasztástöbbletet hoz. Ez ma megfigyelhető mindenhol. A GDDR5 határa picivel 6 GHz alatt van.
-
Abu85
HÁZIGAZDA
-
Abu85
HÁZIGAZDA
A Hynix a HBM memóriákat 2015Q3-tól szállította a partnereinek. Októberben már kaptak mintát, akik kértek. Előtte csak az AMD kapott terméket.
A Hynix nem azt nézte, hogy kinek ad vagy kinek nem. Egy céget akartak a fejlesztéshez, és azért választották az AMD-t, mert ők dolgozták ki a specifikáció jelentős részét. Nekik volt az egész fejlesztésben a legnagyobb tapasztalatuk. A Hynix érdeke pedig világos volt. Nem akarták, hogy az első HBM-es termék csak 2018-ban jöjjön. Ez nem csak a Hynix érdeke volt, hanem mindenkié, aki a HBM-et választotta a jövő szempontjából.
Az AMD mindenképpen első akart lenni, sok más cég mellett, mert tudják jól, hogy az elsők csinálják meg a legjobban a második kört a tapasztalatokra építve. Az, hogy mellettük a Hynix nem adott senkinek már a Hynix döntése volt, de ezt megindokolták azzal, hogy kellenek a termékek a piacra, és így tud mindenki a lehető leggyorsabban HBM-es csomagot piacra dobni. Az AMD persze egy picit hamarabb, de arányaiban ezzel mindenki jól járt, ahhoz képest, mintha nem így csinálták volna.
Természetesen a többiek is kaptak HBM-et. Októbertől már mindenkinek volt mintája, akinek kellett.A GDDR5 hasonlóan bonyolult váltás volt, mint a HBM. Mások a kihívások, de az EMI nagy problémát jelentett. Az AMD onnan tudta elsőként hozni az 5 GHz fölötti memóriákat, hogy még a HD 4800 idején le tudták tesztelni az EMI-vel kapcsolatos gondokat és kitaláltak rá egy megoldást. Az NV is tudott rá megoldást csinálni, lényegében ugyanazt, amit az AMD, de a Fermi esetében még nem ismerték a GDDR5 problémáit, annak ellenére, hogy sok mintával rendelkeztek. Sajnos tipikus probléma, hogy számos gond a tömeggyártás előtt nem jön elő, és amit nem látnak a mérnökök a laborokban, arra nem tudnak reagálni. Aztán persze amint gyártottak a Fermit, le tudták tesztelni az EMI-parákat, ahogy az AMD és a Keplernél meg is oldották.
-
Abu85
HÁZIGAZDA
válasz
Yllgrim
#15607
üzenetére
Persze, hogy nem tűnt fel, a nem működő termékek nem kerülnek forgalomba, de a hiány érződik, és az attól van, hogy a csomag összerakása tömeggyártás szintjén nehéz. A HBM2-t ezért nem ajánlja a Hynix kezdésnek, mert senkinek sem lesz elég tapasztalata arra a HBM1 nélkül, hogy megcsinálja. Ezzel a memóriagyártó nem tud mit kezdeni, mert ő azért felel, hogy rátegye a memóriát a megkapott interposerre, majd arra rátegye a GPU-t. A probléma egyébként a GPU és az interposer között keletkezik, szóval még csak segíteni sem tud a memóriagyártó, megcsinálja a tokozást úgy, ahogy a megrendelő kéri. Azt a megrendelőnek kell tudnia, hogy mi lesz a jó, ezt pedig csak úgy tudják megmondani, ha tapasztalatot gyűjtenek. Akkor tudna a megrendelőnek segíteni az összerakó, ha az GPU, az interposer és a memória is ugyanabban a gyárban készülne, mert akkor a prototípusokból sem lenne költséges egy 10000 darabos tesztet csinálni. Viszont jelenleg a HBM-et három különböző gyár rakja össze, ami gyakorlatilag ellehetetleníti a nagy mennyiségű tesztet. A Xilinx egyébként ezt a problémát úgy hidalta át, hogy mindent a Samsungnál csinálnak, az összes komponens egy gyárban kerül legyártásra és összerakásra. Nem kizárt, hogy az AMD-nek is ez lesz a megoldása a problémára.
Egyébként az nem egyedi, hogy az efféle memóriaváltásoknál az kerül előnybe, aki elsőnek megcsinálta. Lásd a GDDR5-öt legutóbb. Az AMD behozta a HD4800-as sorozatban és a HD 5800-ban rögtön egészen magas órajelen nyomtatták, miközben más még azt a szintet futotta, amit az AMD a HD 4800-nál. Ennyit számít, hogy ha valakinek már tömeggyártás szintjén van tapasztalata az efféle nem éppen egyszerűen implementálható rendszereknél. Valószínű, hogy az AMD a következő körbe már két HBM-es csomagot fog csinálni, míg a többi cég inkább csak egyet, hogy ha nem sikerül, akkor csak egy terméket kelljen törölni a termékskálából. Vagy akár csak egy szűk piacra betolni, ha ellátási problémákba futnak. Nyilván figyelembe kell venni ilyenkor, hogy az AMD a HBM-es Fiji-t már akkor gyártotta, amikor más még HBM mintát sem kapott a Hynixtól. A semmiből pedig nem lehet kutatni. El lehet vinni egy darabig az elméletet, és erre építeni a projektet, de egy idő után szükséges a minta.
-
Abu85
HÁZIGAZDA
Meg sem kérdezték őket, hogy részt akarnak-e venni a fejlesztés befejezésében. A Hynix azt mondta, hogy ha nem akarnak abba a hibába esni, amibe a Micron esett, akkor egyetlen egy céggel kell befejezniük. Az AMD-t azért választották, mert ők tervezték meg a HBM alapjait. Másnak ebbe nem volt beleszólása, kizárólag a Hynix döntötte el, hogy mi legyen. A helyzet az, hogy ezzel a piac egyetértett. Látva, hogy a Micron mit szerencsétlenkedik a HMC-vel már 4 éve, amiből jövőre is csak egy módosított rendszert tudnak összedobni az Intelnek, vagyis nem olyat, ami a HMCC specifikációinak megfelel, talán nem volt olyan nagy hülyeség a Hynix koncepciója. Ha nem teszik meg, akkor talán 2018-ig várni kellett volna a HBM-es termékekre, ez pedig senkinek sem lett volna jó. A többi gyártó azért nem balhézott, mert ha kiszámolod, akkor így 2017-re biztos tudnak HBM-es holmit hozni, ami egy esetleges a 2018-nál jobb. Mindemellett a Hynix lehetővé tette a HBM használatát is, hogy ne kelljen rögtön HBM2-re ugrani, az valóban nagy falat lenne. A Xilinx példája már mutatja, hogy nem annyira rossz az időzítés. Ők csinálnak egy kísérleti lapkát HBM1-gyel és arra építve csinálnak egy ténylegesen HBM2-es FPGA-t, amit piacra is dobnak 2017 elején. A HBM2-vel is lehet kezdeni, csak nagyon rossz lesz a kihozatal, ezért nem ajánlja a Hynix. Az AMD tapasztalataira építve az a legfőbb gond, hogy a Fiji+HBM+interposer komponensei egyenként tökéletesek, de amint összekerülnek már az elkészült termékek fele nem működik. A hibát már megtalálták, de nem javítható csak a következő körben. Ezért kell a HBM-es teszt.
-
#15491
Abu85
HÁZIGAZDA
Petykemano
#15484
Abu85
HÁZIGAZDA
válasz
Petykemano
#15484
üzenetére
[link] - ennek a mérnöki mintája.
-
Abu85
HÁZIGAZDA
Az x86-ot az mentené meg, ha az Intel az ingyen lapkaosztogatás helyett az évi 5 milliárdos mínuszt arra fordította volna, hogy finanszírozza az applikációk átportolását x86-ra. Ma viszont már abban sem érdekeltek, hogy ingyen lapkákat adjanak. Elmennek évente mínusz 800 milláig és ott meghúzzák a határt. Idén vissza is estek a részesedésben emiatt. Egyszerűen a legtöbb gyártó nem építi be az Intel holmit, ha nem adják oda ingyen. Inkább visszatértek az olcsó ARM-ra az új modelleknél.
Az egyetlen épen maradt bástya a Silvermont licenc a Rockchip és a Spreadtrum számára, ami igazából működik, de csakis a kínai tabletek szempontjából, és az Intel számára ez az üzlet nem egy aranybánya, mert ezeket az Atom x3-akat 4-6 dollárért adják, és a híresztelések szerint a licenc az Intel számára fixen a lapka eladási árának 0,07%-a. Ez egyébként egy valóban nyereséges terület önmagában, de az Atom x5/x7 eladások mínuszba tolják a mobil üzletágat. Ez így egy döglött ló. Ha érdekli az Intelt ez a piac, akkor mennie kell ARM-ra. -
Abu85
HÁZIGAZDA
Az Android-Intel dolog nem teljesen van így. Erről pont beszéltem régebben a cégekkel, és egy Intel SoC alapvetően érdekli őket, de csakis akkor, ha nem x86-os procimagok vannak benne. Az x86 ami nem érdekli a piacot, mert egyrészt nem is jó Androidhoz, másrészt mindenki nyitva akarja tartani ezt a területet az ARM-mal, megtartva arra a lehetőséget, hogy később saját lapkákat kínáljanak. Az AMD pont ezért mondta régebben, hogy ha valaha is kínálnak Androidra SoC-ot, akkor azt ARM-on teszik, mert az x86 itt halott irány.
A Windows 10 mobile is gond lesz majd az Intelnek, mert a Microsoft megtiltja ezen a verzión, hogy fussanak a Win32 API-s programok, tehát az x86 előnye itt is teljesen elveszik. Sőt, tulajdonképpen hátránnyá válik, mert a Windows Phone appok ARM-ra vannak írva.
-
#15192
Abu85
HÁZIGAZDA
Petykemano
#15191
Abu85
HÁZIGAZDA
válasz
Petykemano
#15191
üzenetére
A GPU-k extrém skálázhatók, míg a CPU-k sosem lesznek ilyenek. Szóval attól, hogy csinálnak egy új ISA-t jó SIMD implementációval, és hatékony memóriamodellel, a GPU-kra továbbra is szükség lesz, mert jóval nagyobb teljesítménytartományban képesek skálázódni, mint egy CPU. Egyszerűen belátható időn belül esélyed nem lenne tisztán CPU-ból 4 TFLOPS DP teljesítményt hozni, miközben IGP-ből simán megoldható 2017-re.
Szerintem az AMD inkább az ARM-ra gyúr több szerverprojektben, mert az ARMv8-nak jóval jobb a memóriamodellje, mint az x86-nak. Jóval hatékonyabban skálázható egy 32 magos K12, mint egy 32 magos Zen.
Nem jelent problémát egy lapkán gyártani őket. Csak meg kell találni az ideális kompromisszumot. Ma mindenki ezt csinálja.
-
#15190
Abu85
HÁZIGAZDA
Petykemano
#15189
Abu85
HÁZIGAZDA
válasz
Petykemano
#15189
üzenetére
Csak akkor, ha új ISA-t építenek normális SIMD kezeléssel. A legnagyobb baj az Intel, az ARM és az IBM SIMD kiterjesztéseivel, hogy borzasztóan kevés a regiszter. AVX512-nél csak 2 kB-od van 512 bites SIMD-re. A jelenlegi kódokban 512 bites vektormotorra 128 kB lenne ideális. Na most persze elmélet, de ma például a GPU-k FP32-es operációnként 2-4 kB-os regiszterterületet odavágnak a programozóknak, míg egy AVX512 csak 128 bájtot!!! ad. Nincs az az isten, aki ennyire szűkös keretre jól leoptimalizálja a kódot. Az Intel példáiban is azért van sokszor csak pár százalékos extra az új AVX-ekből, mert kevés a regiszter.
Ahova ezeket a szerverprocikat szánján úgy sem működne 4 GHz-en a rendszer. Sokszor még 3-on sem. Semmi értelme így elméleti lehetőségeket hajkurászni az órajellel.
-
Abu85
HÁZIGAZDA
Nem. Csak már nem igazán céloznak ezek a processzek órajelet. Ennyi. Simán be lehet rajta állítani a 4 GHz-et, de nem ez a cél a fejlesztésnél, hanem az energiahatékonyság. Persze ezt a fizika korlátjai határolják be leginkább. A kiválasztható anyagokat ez lekorlátozza, és ezért van az, hogy minden chipgyártó csakis low-power node-ot tervez, és ezeket skálázzák valamennyire. Klasszikus high-performance node-ot 28 nm-en terveztek utoljára a bérgyártók, az Intel pedig 32 nm-en.
Azt kell a bérgyártóknak mérlegelnie, hogy mennyire fontos az 5 GHz-es órajel normális fogyasztással. Ha az, akkor hozni kell az FDSOI-t, de alig van rá igény. Főleg azért, mert FDSOI-ra GPU-t tervezni körülményes, és a lapkaterület túl nagy részét teszi ki ez az egység, hogy be lehessen vállalni ezt a hátrányt.
-
Abu85
HÁZIGAZDA
Egyetlen mai processt sem fejlesztenek már magas órajelre. Elsősorban azért, mert a 4 GHz-et egyszerű elérni szimplán dizájnnal, miközben a direkt magas órajelre fejlesztett processek nem tudják elérni az 5 GHz-et. Ilyen fizikai határok között ma inkább az energiahatékonyság a cél, mert sokkal előnyösebb kb. 200-400 MHz-ről lemondani a dupla hatékonyságért. Ez ma eléggé univerzális nézet az egész iparágban.
A GloFo-nak egyébként vannak érdekes kísérletei a magas órajelre, de FDSOI kell hozzá, és a legtöbb piaci szereplő nem akar átváltani erre a bulkról. Még most is inkább azt mondják, hogy legyen kisebb az órajel, de a bulk wafer maradjon.A Common Platformból a Samsungnak is vannak FDSOI technológiái, tehát ha mutatkozna rá komoly piaci igény, akkor tudnának ők is ilyen node-ot hozni.
-
Abu85
HÁZIGAZDA
Ha a kódolási séma megváltozása elég komoly módosítás. Ez nagyon fontos egyébként, mert ezek a masszívan párhuzamos rendszerek a futtatható szálaktól, a hardveres szinkronizációtól és a memóriamodelltől fognak skálázódni. A GCN-nél is a memóriamodell a korlátozó, ahogy minden rendszernél, tehát ha további skálázódást akarnak, akkor azt kell cserélni, majd ehhez igazítani a szálak hardveres szinkronizációját. Mivel a GCN-t eleve multiprocesszoronként 2560 szál kezelésére tervezték, nem valószínű, hogy ez a jövőben limitáló lesz, mert egyetlen más architektúra sem dolgozik ennyi szállal. Persze a memóriamodell problémáit is lehetne ellensúlyozni gigantikus gyorsítótárakkal, de láthatóan erre az AMD sem vetemedik, inkább lecserélik.
Szerk.: most láttam én is. Folytassuk majd ott.
-
Abu85
HÁZIGAZDA
A két új ASIC verzió biztos, hogy más kódolási sémát használ, tehát ez már egy olyan fejlesztés, amely megőrzi a GCN jellegzetességeit, de a memóriamodell megváltozik, hogy skálázódjon tovább. Alapvetően a memóriamodell a skálázódás kulcsa, ezt kell cserélni, de architektúrák strukturális jellege megtartható. Persze ehhez így kell tervezni az alapokat, de úgy néz ki, hogy a GCN-t így tervezték. Valószínűleg az AMD a 2011 végi GCN megjelenés után két irányt tervezett. Az egyik az, aminél bejön az API reform, míg a másik az ahol nem. Előbbi esetben minden fasza, mert a GCN működéséhez igazodnak az API-k, míg utóbbi esetben lett volna teljes architektúraváltás, mert a GCN kényszerült volna emulációra, és nem az összes többi gyártó.
-
Abu85
HÁZIGAZDA
A GCN-ből még legalább két verzió lesz, mert a disassembler már elfogad két még nem létező ASIC-ot, gondolom okkal.
De most, hogy így alakult az API-k helyzete szerintem bőven benne van, hogy amíg ez a konzolgeneráció tart, addig ezt az architektúrát nem váltják le, csak javítgatják. Túl nagy hátrány lesz low-level irányban teljesen új architektúrára váltani, mert 50%-kal is lassabb lehet, mint az előző generáció azokon a játékokon, amelyek már megjelentek és ott vannak a tesztekben. Aztán ezt még meg is kell tanulniuk a programozóknak, mert nem a driver fogja menedzselni a GPU-t. Az AMD-nek most az a hatalmas mákja, hogy az új API-k memóriaalapú architektúrát igényelnek, és nekik az van, így nem kell feltétlenül váltaniuk, hogy igazodjanak az API-k működéséhez. -
Abu85
HÁZIGAZDA
Azért annyira nem örül az ipar annak, hogy lényegében a DX12 és a Vulkan is nagyrészt egy másolata az AMD API-jának. Ez azért óriási előny. Nem az API miatt, hanem a tervezett irány miatt. Azért elég durva, hogy pár éve elképzelhetetlen volt, hogy valami szabvány lesz, amit az egyik cég nem tervez támogatni. Erre most jött egy olyan nézetváltás, hogy mostantól a gyártók ebbe nem szólnak bele. Őszintén hány olyan architektúra van a piacon, amely az SRV-ket képes direkten a multiprocesszorba bekötni? Na látod, és ez lett a szabványosan elfogadott teljes értékű koncepció. Ez most szerinted hogyan érinti a többieket? Gondolod, hogy az NV és az Intel azt mondta az MS-nek, hogy oké, akkor nulláról letervezünk egy új architektúrát, ami így működik.
-
Abu85
HÁZIGAZDA
Azt mondtam, hogy az AMD hardvertervezése, már nagyrészt attól függ, hogy a fejlesztők számukra a megalakult konzorciumon belül mit mondanak. A DSP alapvetően nem az AMD ötlete, hanem az Oxide-é, de magát a koncepciót érdemes megvizsgálni. Bár meggyőződésem, hogy az AMD ezt nem akarja, inkább az IGP-vel gyorsítanák a grafikus API-t.
A lényeg igazából az, hogy az AMD mostantól a szabvány előtt szeretne lépdelni, mert ez a Mantle-lel baromira bevált, és nincs okuk feltételezni, hogy nem válna be még egyszer, vagy többször is.
Ha az én véleményemre vagy kíváncsi, akkor az AMD szerintem egyértelműen az IGP-s API gyorsítás ötletéért rajong, de ha a fejlesztők szeretnék a DSP-t, akkor képesek azonnal licencelni egy komplett Tensilica rendszert. -
Abu85
HÁZIGAZDA
Ezért írtam, hogy ott a DSP lehetősége is. Koncepciós szinten a HSA nem tesz különbséget az IGP és a DSP között. Magát a DSP-t egyébként az Oxide már korábban felvetette, hogy sokkal jobb lenne, ha apró DSP magok adnák ki a rajzolási parancsokat, mert sokat beépítve gyorsabb lenne és a processzoridő is felszabadulna. Nem kizárt, hogy ennek a prototípus jellege az Oxide ötletén alapszik, ők abszolút célként tűzték ki, hogy 2015-ben 300k rajzolást akarnak látni. Ez az aktuális API-kkal és aktuális processzorokkal nem lehetséges. Még azokkal sem, amelyek a következő évben jönnek, tehát ismét valami részben szoftveres újítással kell megoldani ezt a kérdést. Pont az ilyen problémák megoldására alakult meg az AMD-n belül ez a fejlesztői konzorcium.
-
Abu85
HÁZIGAZDA
válasz
stratova
#14875
üzenetére
Ahogy ez most látszik a fejlesztők inkább funkciókat szeretnének. Nem nyilvános minden információ, de a gyártópartnerek szerint ezek vannak aktívan napirenden:
- rajzolási parancsok gyorsítása. Oké, hogy most durvult be a dolog, de számos fejlesztő egymillió rajzolást szeretne akár jövőre. Nyilván ez processzorral képtelenség, tehát kell valami célirányos részegység magának a grafikus API-nak a gyorsítására. Egy rakás DSP? Vagy az IGP? Vagy a HSA-n keresztül akár mindkettő?
- a másik dolog a nagyobb kontroll. Több fejlesztő még mindig azt mondja, hogy ezek az új API-k is korlátozzák a lehetőségeiket, így szeretnék magát az API-t is saját maguk megírni vagy a meglévőt módosítani. Éppen ezért egy új egységesítési rendszert kell ehhez keresni.
Ilyesmiket igényelnek. -
Abu85
HÁZIGAZDA
Az AMD hardvertervezése azért ma már különbözik attól, ami régen volt. Ők alapítottak a cégen belül egy zárt konzorciumot, ami arra szolgál, hogy szoftverfejlesztők leadják az igényeiket, és ezeket megbeszéljék. Amik elfogadhatók, azokra kitalálnak egy gyorsítási technikát, és a fejlesztők vállalják, hogy támogatják. Ez sokszor nehezen érthető roadmapokhoz vezet, hiszen kvázi megrendelésre kerülnek a funkciók a hardverbe.
-
Abu85
HÁZIGAZDA
Az APU-khoz annyit, hogy a Fudzilla nem tudom honnan vette azt a slide-ot. Több AMD-hez közel álló gyártó sem látta soha. Az viszont biztos, hogy készül egy nagy FirePro S APU elsődlegesen a HPC szerverek piacára. Ezt konkrétan az AMD mondta Japánban. Ez szükséges, mert rengeteg munkamenet gyorsítható extrém módon, de ma nem teszik meg, mert az adatmásolás miatt elveszik a gyorsulás.
Webszerverekbe is érkezik APU, mert a Facebook külön kérte, mivel nem mindegy, hogy az általuk nagyon-nagyon sokszor használt offload memcached technika 10x gyorsabban fut vagy sem. Azt tudni kell, hogy a Facebook számára a GPGPU nem idegen. Rengeteg HD 5870-et használtak pár éve, de csupán 20%-ot gyorsultak. Viszont maga a számolás 20x gyorsabb lett, de az adatmásolással elment az előny.
-
Abu85
HÁZIGAZDA
Igen jelen esetben az tehet róla, hiszen ebből a szempontból a TSMC sokat javított, csak az AMD nem portolta le rá a HDL-t, mert sosem érdekelte őket ez a node, ugyanis más szempontból meg sokat rontottak a 28 nm-hez képest.
A lényeg az, hogy egy komplex SoC tranzisztorsűrűségét nagymértékben a density library határozza meg, és elhanyagolható mértékben függ a node paramétereitől.Valószínű egyébként a TSMC 16 nm-je lesz ebből a szempontból a legjobb. Ott elérhető lehet a 35 millió tranyó/mm2 is, persze megfelelő HDL-lel. Viszont hátrány, hogy a 16 nm sem jobb minden szempontból a 28 nm-nél, tehát még mindig előfordulhat, hogy 28 nm-en gyorsabb GPU-t lehet tervezni.
-
Abu85
HÁZIGAZDA
Azt is érdemes még észben tartani, hogy messze az AMD HDL-je a legfejlettebb a piacon, nyilván nagyon sokat számít, hogy GPGPU-s szuperszámítógépen terveznek. Tehát más szoftveréhez abszolút nem mérhető hozzá a képessége. De nyilván ezért tudnak 28 nm-en majdnem olyan tranzisztorsűrűséget elérni, mint amit az Intel 14 nm-en. A Broadwell-U átlagos sűrűsége 14,3 millió tranyó/mm2, míg a Carrizo esetében ez a paraméter 12,7 millió tranyó/mm2. És úgy, hogy a Broadwell-U IGP-je százalékosan több helyet foglal el a lapkán.
A GloFo szerint más leginkább 25 millió tranzisztor/mm2-nél lesz a 14 nm LPP-n egy SoC esetében, ami szerintem is reális.
-
Abu85
HÁZIGAZDA
A gyártástechnológiánál fontos észben tartani, hogy a tényleges chipek tranyósűrűségénél a legkevésbé számít az adott node jellegzetessége. Nagyon-nagyon befolyásolja ezt a paramétert az alkalmazott density library. Ezért tud az Apple A8X is 3 milliárd tranzisztort építeni 20 nm-es TSMC node-on 123 mm2-en belül, miközben az Intel a 14 nm-es node-ján Broadwell-U 133mm2-be épít 1,9 milliárd tranyót.
A Samsung node-ja esetében a HPL-t még nem portolta az AMD, de a HDL-lel 30 millió tranzisztor/mm2 elérhető a GPU-kra. HPL-lel csak becslések vannak, de valószínű, hogy az AMD ezzel a koncepcióval már nem fog CPU-t tervezni, mert feleannyi tranyó férne ugyanakkora helyre, miközben az ezzel nyert teljesítmény nem több 10%-nál.
-
Abu85
HÁZIGAZDA
válasz
Oliverda
#14732
üzenetére
A kombinált írást kapcsolják le a profilok. Az Intel IGP-je az összes futtatott szálból ciklusonként 32 kB-ot írhat az LLC-be és az eDRAM-ba. Na most ez ciklusonként több MB-nyi tartalom, ami annyira összeszemeteli a szegény LLC-t, hogy a processzormagoknak a memóriába kell menni az adatért. Ez lelassítja a feldolgozást, így ezt a megoldást több programnál is kikapcsolják, így az IGP csak a saját belső gyorsítótáraiba írhat, míg az LLC-t és az eDRAM-ot csak olvashatja.
-
Abu85
HÁZIGAZDA
válasz
Oliverda
#14730
üzenetére
Az eDRAM az általános megjelölés, de ha az Intel eDRAM-ja érdekel, akkor ilyen a HBM-hez képest:
Intel eDRAM:
Kapacitás: 128 MB
Buszszélesség: 1024 bit
Órajel: 1,6 GHz
RCT: 3,75 nsHynix HBM 4Hi:
Kapacitás: 1 GB
Buszszélesség: 1024 bit
Órajel: 1 GHz
RCT: 1 nsEgy HBM jóval kisebb is. Kb. negyedakkora helyet igényel, mint az Intel eDRAM-ja, ezért van esély ugye 2048-4096 bites buszokat kiépíteni.
A HBM2 még jobb lesz. Ott 2 GHz lesz az órajel.Egyébként a HBM-nek főleg a nagyobb kapacitásból származó előnyét fogják érezni a fejlesztők, mert cache-ként ezek a megoldások rendkívül rossz hatékonysággal működnek. Sok program profiljában az Intel is inkább kikapcsolja a cache-lést, hogy növeljék a teljesítményt.
-
Abu85
HÁZIGAZDA
válasz
Oliverda
#14726
üzenetére
Milyen alacsonyra gondolsz? Az eDRAM-nál biztos alacsonyabbat hoz. Annál már a HMC is jobb ilyen formában, a HBM pedig pláne. Az integrált eSRAM-nál nem, de ez nem integrált memória. Nem mellesleg az IGP nem érzékeny a késleltetésre.
Valószínűleg nem jár messze a szimuláció a valóságtól, mert a Samsung az LPE node-on HPL dizájnnal hoz 28 milliós tranyósűrűséget négyzetmilliméterenként egy tényleges lapkával. Ennél az LPP és a HDL jobb, tehát a 30 millió tranyó/mm2 még óvatos megközelítés. Valszeg még jobb is lesz.
Az Apple-t kell majd megvárni. Nekik van HDL-jük. Most ezzel a TSMC 20 nm-én ~120 mm2-be építenek 3 milliárd tranyót. -
Abu85
HÁZIGAZDA
válasz
Oliverda
#14710
üzenetére
A HBM arra alkalmas, amire bekötik. Úgy lehet használni, ahogy akarják. A Hynix korábban már mondta, hogy három eltérő vezérlést tesztelnek. Az egyik a HBM only, vagyis ez a fő memória, a másik amikor cache-ként viselkedik, míg a harmadik, amikor a HBM egy kiegészítése a külső memóriának. Ezek ma a lehetőségek. Az, hogy ebből ki mit választ egyéni döntés kérdése. A Hynix szerint úgy is megoldható, hogy mindhármat támogassa egy fejlesztés és BIOS-ban módosítható a működés.
A fabric az lapkán belüli összeköttetés. Egyébként simán lehet ennyi hely egy lapkán. A szimulációk szerint a 14 nm-es LPP az AMD új HDL-je négyzetmilliméterenként nagyjából 30 millió tranzisztort enged meg ALU logikának és fabricnak. Ez nagyjából hatszor sűrűbb annál, amit ma alkalmaznak a Kaveri esetében.
-
Abu85
HÁZIGAZDA
Lényegében a MediaTek egy licencelő cég. Ők bármikor összerakhatnak egy ARM-os holmit, de egyre erősebbek a pletykák, hogy saját IGP-t terveznek az AMD-vel kooperációban. A Qualcommnak ott a Snapdragon 820. A Samsung szintén licencelő cég, tehát összerakhat magának egy ARM-os cuccot, de náluk is erős a saját IGP-s pletyi.
Csak a Kaveri és a Carrizo esetében ismerem, hogy milyen IOMMU van benne. Minimum IOMMU v2.5 kell.
A Mantle meg akarták tartani. Fejlesztgetik aztán időnként odaadják a forrást és a specifikációkat a Khronos Groupnak és a Microsoftnak, hogy fejlődjön a Vulkan és a DirectX is. Ebben az a koncepció, hogy az AMD akarja meghatározni, hogy merre fejlődjön a szabvány. Ehhez viszont le kell zárniuk a saját API-jukat, hogy hónapokon belül reagálni tudjanak a fejlesztői igényekre.
-
Abu85
HÁZIGAZDA
Az AMD azért van sűrűn megjelölve, mert a vezetői pozíciót Phil Rogers tölti be, aki az AMD-nél dolgozik. Ő olyan mint Neil Trevett a Khronos Groupnál.
A szakmai előadásokat mindig felosztják a támogatók között, így mindenki láthatja, hogy ez egy konzorcium. A Samsung, az Imagination, a Qualcomm, az ARM, a CodePlay, mind tartanak előadásokat.
Mindenki sejtette, hogy az AMD jár az élen az integrációban, tehát nekik lesz meg leghamarabb a hardver. Ez sosem volt titok. Ettől függetlenül dolgoznak a többiek is. Az ARM-nak és az Imaginationnek van komplett HSA rendszere, ami összerakható.
De most, hogy így alakult az API-k helyzete szerintem bőven benne van, hogy amíg ez a konzolgeneráció tart, addig ezt az architektúrát nem váltják le, csak javítgatják. Túl nagy hátrány lesz low-level irányban teljesen új architektúrára váltani, mert 50%-kal is lassabb lehet, mint az előző generáció azokon a játékokon, amelyek már megjelentek és ott vannak a tesztekben. Aztán ezt még meg is kell tanulniuk a programozóknak, mert nem a driver fogja menedzselni a GPU-t. Az AMD-nek most az a hatalmas mákja, hogy az új API-k memóriaalapú architektúrát igényelnek, és nekik az van, így nem kell feltétlenül váltaniuk, hogy igazodjanak az API-k működéséhez.Új hozzászólás Aktív témák
A topikban az OFF és minden egyéb, nem a témához kapcsolódó hozzászólás gyártása TILOS!
Az ide nem illő hozzászólások topikja:[link]
MIELŐTT LINKELNÉL VAGY KÉRDEZNÉL, MINDIG OLVASS KICSIT VISSZA!!
A topik témája:
Az AMD éppen érkező, vagy jövőbeni új processzorainak kivesézése, lehetőleg minél inkább szakmai keretek között maradva.
- Windows 11
- Anime filmek és sorozatok
- Gyúrósok ide!
- BMW topik
- Amlogic S905, S912 processzoros készülékek
- Fejhallgató erősítő és DAC topik
- Kertészet, mezőgazdaság topik
- ASUS notebook topic
- Itt a Galaxy S26 széria: az Ultra fejlődött, a másik kettő alig
- iPhone Ultra néven jöhet az Apple első foldja, nem lesz olcsó mulatság
- További aktív témák...
- Apple iPad mini 4 (A1538) 128GB Wi-Fi Asztroszürke
- REFURBISHED és ÚJ - HP Thunderbolt Dock G2 230W with combo cable (3TR87AA)
- 236 - Lenovo Legion Pro 7 (16IRX9H) - Intel Core i9-14900HX, RTX 4090
- HIBÁTLAN iPhone 12 Pro 128GB Gold-1 ÉV GARANCIA - Kártyafüggetlen, MS4441, 100% Akksi
- ÁRGARANCIA!Épített KomPhone i9 14900KF 32/64GB DDR5 RAM RTX 5070 12GB GAMER PC termékbeszámítással
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest