Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
A Socket AM3+-ba lényegében a Vishera lesz az utolsó processzor. Az lehet, hogy nem pont ez a három, és esetleg 2013-ban jön még egy FX-8370-es, vagy mi, de maga a fejlesztés nem megy tovább. 2013-ra csak a Vishera FX-ek vannak jelölve, mint alternatívák, míg a gyártóknak leadott 2014-es útitervben nincs asztali CPU ... csak APU. De az jelölve van, hogy a felsőkategóriás CPU-k helyét felsőkategóriás APU-k veszik át, vagyis a termékkategória megmarad, csak nem CPU-k lesznek kínálva. Itt azt kell mérlegelni a cégeknek, hogy a ma egy HEDT platformot (High-End Desktop ugye) főleg játékra vesznek. Az AMD azzal, hogy bemutatta a HSA-t egy csomó dolgot átrakat az IGP-re a játékfejlesztőkkel. Ebben a hsz-be - bemásoltam egy aktuális előadás anyagait, ahol arról van szó, hogy mi az ami lehetségessé válik a Kaveri APU-kkal. Egyszerűen temérdek dolgot rá lehet bízni egy játékban az IGP-re, amit eddig a proci csinált. Ez abból a szempontból hasznos, hogy jelentősen kitolja a CPU limitet, mert sokkal gyorsabban dolgozik egy APU. Ezért nem tervez az AMD asztalra processzort, mert az APU a játékosoknak is gyorsabb megoldás lesz, így pedig nincs értelme az egésznek. Ugyanígy gondolkodik az Intel is. Az SB-E van a 2013-as útitervben is. Az IB-E egyszerűen eltűnt. Pedig a korábbi útitervek 2012Q4-re tervezték a frissítést. Nekik is csak APU-juk lesz, mert előnyös az IGP offload. Ha kirakják az IGP-re az FC-t és a OC-t, akkor egy átlagos új generációs APU durván seggbe rúgja az összes homogén többmagos CPU-t.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Már van nekik is APU-juk. Haswell is lesz jövőre, ahol a mérnökök a CPU-s teljesítményt alig növeli, de az IGP-be 16 helyett 40 EU-t pakolnak. Nem mondják ki, de az, hogy ilyen erővel gyúrják az IGP-t a compute irányba mutatja, hogy már az Intel is az APU-ban látja a jövőt. Egyszerűen semmi nem akadályozza már a piacot, hogy meneteljen előre. Azt viszont mindenki látja, hogy a homogén többmagos processzorok skálázhatósága megszűnt, szóval vagy újítanak a fejlesztők, vagy leragadunk az aktuális szinten. Itt már választási lehetőség nincs. Túl sokáig halasztgatták a gyártók a problémák megoldását.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A többi régi dologgal nem tudnak mit kezdeni. Ez olyan lesz, mint az egymagos->kétmagos váltás. A régi programok, amiket nem frissítenek még ma is egy processzormagon futnak, de a gyártóknak rá kellett lépni a többmagos procik ösvényére, mert megszűnt az egymagos processzoroknál a skálázás lehetősége. Most ugyanez a többmagos prociknál szűnik meg, vagyis ki kell jelölni egy olyan új irányt, ami biztosítja azt, hogy a lapkák throughput teljesítménye évről-évre nőjön. Korábban már mondtam, hogy erre két lehetőség van. Az egyiket az Intelnél dolgozó Fred Pollack szabálya. Ez azt mondja ki, hogy a processzormagok bonyolultságát csökkentve csökkenthető a lapkán elfoglalt méretük is, és ezzel több processzormag kerülhet egy chipre, ami növeli a throughput teljesítményt. Ezzel az a baj, hogy negatív hatással van az egy szálon elérhető teljesítményre, vagyis az Amdahl-törvény miatt a legacy programok lassulnak ettől az iránytól, de az új programok nyilván gyorsulni fognak. A másik megoldás az APU, ahol külön magok lesznek a serial vagy task parallel kódoknak (CPU-magok), és külön magokat lesznek a data parallel munkavégzésre (GPU-magok). Ezzel a legacy programok sebessége nem lassul, noha nem is gyorsul majd drasztikusan, emellett az új programok gyorsulni fognak. A két dolog között az a különbség, hogy Fred Pollack szabálya nem követel új programozási modelleket, míg az APU igen. Szóval vannak rendesen pro/kontra érvek, de úgy néz ki, hogy a gyártók nem akarják lassítani a legacy programok sebességét, és ezért inkább jöjjenek az új programozási modellek, és az APU-k.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nincs más választás. Vagy tartod az irányt, vagy sosem lesz gyorsabb a programod az új hardverek érkezésével sem. Ugyanaz a helyzet, mint az egymagos->többmagos váltásnál. Ott is szívták a fogukat a fejlesztők, de rákényszerültek, mert a chipek skálázódása nagy úr. A programozó szempontjából a programozási modellek átalakulása kellemetlen dolog, de áthidalható probléma, a lapkák tervezésénél viszont a fizika törvényei kőbe vésett jelenségek, és megkerülhetetlenek. Legalábbis eddig még nem volt rá példa, hogy a fizikát sikerült legyőzni. Lehet elmélkedni transzdimenzionális fejlesztésekben, hogy mondjuk egy adott térre más fizikai törvények legyenek jellemzők, de ezek elméletben is csak kitalációk, semmilyen gyakorlati bizonyíték nem létezik rájuk. Hamarabb váltjuk le a CMOS-t, minthogy legyőzzük a fizika korlátjait. Természetes, hogy a programozó szempontjából az 50 GHz-es egymagos processzor jelenti az űberhardvert, de ez a jelenlegi technológiai szintünkön kivitelezhetetlen, a teljesítmény skálázását viszont mindenki elvárja. Következtetés az, hogy keresni kell azt az utat, amivel skálázni lehet a lapkákat.
Mindenki próbál párhuzamosítani. Az Adobe már APU-ban gondolkodik például, mert nem engedhetik meg maguknak, hogy a szoftverük teljesítménye megrekedjen egy szinten. A vezető szoftvermérnökük már elmondta ebben a hónapban az AFDS előadáson, hogy a jövőben a HSA-ra építenek, és szívesen venné, mindegyik cég beállna a támogatók sorába, mert megkönnyíteni a programozók dolgát.
A játékok helyzete a legkönnyebb. Ugye egy programnál az APU kihasználása attól függ, hogy mennyi párhuzamosítható részlet van a feldolgozás során. Na most a játékok ebben igazán bővelkednek. A fizika, az útkeresés, a különböző culling eljárások, a sorting, a tartalom kikódolás ... mind-mind nagyon jól átrakhatók GPU-ra. Amiért ma ez nem történt még meg az az, hogy a GPU egy lassú külső buszon kapcsolódik a processzorhoz, és mindkét erőforrás különálló memóriát használ, emellett a DirectX is egy elég nagy késleltetéssel rendelkező API. A GPU pusztán a számítások oldalán így is gyorsabb, de annyi büntetést kap az adatok másolgatásával és az API késleltetésével, hogy összességében gyorsabb a processzor által való feldolgozás. Az APU-val lehetőség lesz teljesen koherens memóriát megosztani a CPU és az IGP között, azaz nem kell másolgatni az adatokat. Az API limitációira pedig megoldás például a HSA, vagy más hasonló irányú felület.
A programozás szempontjából pedig HSA BOLT-ot használva rövidebb programkód írható, mint soros programozás mellett egy magot használva. A különbség, hogy HSA-val párhuzamos lesz a feldolgozás, és majdnem olyan lesz a sebesség, mintha OpenCL-be írtál volna egy 6x hosszabb kódot. Ezért buzdít az Adobe a belépésre, mert a programozóknak a befektetett munka nagymértékben redukálódik, és még a hardverek közötti különbség is elfedésre kerül, hiszen a HSAIL egy virtuális ISA, vagyis az alatta lévő fizikai hardver támogatása a finalizertől függ. Ha van x számú fizikai hardverre HSA támogatás, akkor ugyanaz a kód bármelyik hardveren fut függetlenül a gyártótól. Persze specifikus optimalizálásra szükség lesz, de aki eddig látta a HSA-t működni, az azt mondja, hogy a befektetett munka így is nagyon kevés, ahhoz képest, amit az OpenCL specifikus optimalizálásába kell beleölni.(#63) Kopi31415: Lesz is olyan kód, de rengeteg olyan kód van, ami nagyon jól párhuzamosítható.
Bármit hozol a PCI Express helyett, akkor sem lesz gyorsabb a lapkába integrált kommunikációnál, és sosem fog két külön lapka teljesen koherens memóriát megosztani. A gyártók is látják ezt, és elképesztő ütemben integrálnak, mert nem tudnak más megoldást a problémákra. Ha lenne szerintem nem ezt az utat választanák.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
#06658560
#74
üzenetére
És ezért jó az integráció. Ugyanis a feladatnak a serial részei mehetnek a CPU magokon, míg a párhuzamosíthatók az IGP-n. Ezért mennek erre a gyártók, hogy ezt a programozók meg tudják lépni. Ma ilyet lehetetlen csinálni, mert az adatok másolása lassú lenne, és önmagában a processzor gyorsabban végez.
Az APU legnagyobb előnye, hogy megjelenhet az egységes címtér, így az IGP ugyanazokat a pointereket kezelheti, amiket a CPU, továbbá a grafikus vezérlő képes lesz elérni a processzor virtuális címterét, illetve a CPU és az IGP teljesen koherens memóriát oszthat meg. A memória elérése nem lesz gyorsabb. Az lesz előny, hogy ha valami kell a GPU-nak, akkor azt nem kell elvinni a memóriájába, vagy ha valami kell a CPU-nak, akkor azt nem kell visszaírni a rendszermemóriába. A data copy megszűnik.
Attól, hogy lesz két foglalatod és az egyikbe CPU-t, míg a másikba GPU-t raksz még nem lesz egységes a memória.
Ma azért egyirányú a CPU-GPU kommunikáció, mert egyszerűen nincs lehetőség másra. Nem kell, hogy ez örökké így maradjon. A gyártók tesznek majd ellene az integrációval.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
#06658560
#80
üzenetére
A GPU-ban az a jó, hogy tolerálja a késleltetést. A CPU nem, de neki ott a cache. Ha a GPU-nak szüksége van adatra, akkor ugyanúgy menni fog a memóriához, de a CPU-val ellentétben többszáz konkurens szál fut a feldolgozókon belül, így ha valamelyik adat hiányában nem tud tovább számolni, akkor lesz helyette másik szál, ami számolhat.
A ray-tracinghez az APU elég jó opció, de maga a ray-tracing nem áll még készen a bevetésre. A Zebra Imaging a hologrammokat ray-tracinggel rendereli és APU-t választottak hozzá, mert ez a leghatékonyabb formája a számításnak.
Van sok terület, ahol az APU előnyös. Például a szervereknél ott a Hadoop. Az kap majd HSA támogatást, hogy APU-val gyorsabb legyen. Ezért hozza az AMD az APU-kat a szerverekbe, mert nő az igény a GPU-s gyorsításra, de a PCI Express és a data copy sok helyen korlátozó, ami viszont a Kaveri APU-ban nem lesz az. A GPU teljes értékű koprocesszorává válik a központi magoknak.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az egész idei AFDS szinte arról szólt, hogy a szerverpiacon, milyen sok helyen lehet használni az IGP-t. Ezekre példákat is hoztak fel, sőt, teszteket is, mindezt az említett területekről.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem, mert sok anyag máig nem publikus, emellett inkább a user oldalra koncentráltam. Az a baj az AFDS-sel, hogy nem olyan, mint az NV GTC. Nagyon durván fejlesztői rendezvény, így a marketing háttérbe szorul. Ez nem volt szerintem baj, de az anyagok publikálása már limitált, mert azok a fejlesztők nem kevés pénzt fizettek azért, hogy ott legyenek, és megnézzék. Idővel mindenről lehet majd írni, de ma még nem. Akkor pedig amikor a cikket írtam eléggé limitáltak voltak a lehetőségeim.
Régebben volt PDF-em a HSAIL-ről. Nem véletlenül nem töltöttem fel valahova és adtam közzé a linket. Azért mondtam, hogy akit érdekel kérje privátban, mert hivatalosan nekem sem kellett volna meglennie, de szerencsére pár netes ismerős kijutott, így szereztem anyagokat. Mára már megvan majdnem mind, bár ~30 még hiányzik, de dolgozok rajta. Sajna zömében pont a szerveresek.[ 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 A Socket AM3+ foglalatba illeszthető, Vishera kódnevű termékek minimum 4 GHz-en ketyegnek.
