Új hozzászólás Aktív témák

• #922 Abu85 HÁZIGAZDA HSM #912

  Új Válasz 2012-04-24 09:28:13 #922

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Abu85

  HÁZIGAZDA

  válasz HSM #912 üzenetére

  A HD 4000 sokkal gyorsabb. A HD 2000 nagyjából a felét tudja. Szóval érdemes 4000-et venni.
  Pont erről írtam a harmadik oldalon. Az Intel kigyúrta az IGP-t GPGPU-ra. A Sandy buta volt. Ez már nem az, és jobb is a felépítés. Grafikában vannak limitáló tényezők, mint a gyenge ROP és a viszonylag gyenge setup rész, de az EU-k az IGP-n belüli L3-mal eléggé komálják majd a számításokat. A szálkezelés sokkal jobb lesz, így a co-issue képesség is sokszor használható majd ki szerintem. OpenCL támogatás már van. Ezt persze még fejleszteni kell, de ez csupán szoftveres kérdés. A C++ AMP támogatás még nincs bejelentve, de a DirectCompute 5.0 megy, szóval ez is csak szoftveres kérdés. Sőt, ez gyakorlatilag kvázi támogatás, mert csak engedélyezni kell, amikor itt a felület.

  Az Intel látva a skálázási problémákat elvitte a fejlesztést az IGP irányába. Lényegében ez az Intel első igazi APU-ja. Követik az AMD-t ebben az értelemben. Mivel mindenkire vonatkoznak a fizika törvényei, így mindenki ugyanazt a következtetést vonja le a Dennard-féle skálázási szabály kihalásával a homogén többmagos processzorok skálázása is megállt. Kvázi ugyanaz a probléma mint az egymagos processzorok hattyúdalánál, csak most több a megoldandó gond, de lépni kell, mert a skálázódás nem tartható fent. Erre a cégek egységesen a heterogén módon programozható lapkákat látják megoldásnak, ami logikus, mert a grafikus vezérlő a jellegéből adódóan sokkal kevesebb energiát igényel egy operáció végrehajtásához. A Dennard-féle skálázás nélkül lényegében az a cél, hogy az operációk végrehajtása kevesebb energiát igényeljen, mert a gyártástechnológia fejlődése már fizikai határokat feszeget, így az ingyen ebédnek lőttek. Moore törvénye él, mert egységnyi méretbe több tranyót lehet pakolni a csíkszélesség váltásoknál, de ez semmit sem ér, ha a bekapcsolásukhoz szükséges energia nem, vagy csak alig csökken. Innentől kezdve a chiptervezőknél pattog a labda. A gyártástechnológia fejlődésében nem bízhatnak, így a tervezés szintjén kell növelni a hatékonyságot. Ezt lehet a Pollack-féle szabállyal csinálni, vagy ha nem akarják kivégezni az egy szálú tempót, akkor a heterogén éra marad. Egyelőre az utóbbit választották a cége okkal, így a fejlődés erre megy. Innentől kaptak egy pöttyös labdát a szoftverfejlesztők is, hogy ideje brutál mód párhuzamosítani, akár úgy hogy átdobálják a feladatokat a CPU és az IGP között, vagy a program nem fut majd gyorsan. Ezt persze majd dobják vissza, hogy ez így nem jó, mert a mai integráció lényegében csak fizikai jellegű, de az architektúrákat egymáshoz kellene tervezni, hogy ne kelljen felesleges másolgatásokat csinálni a rendszermemóriában. Ezt a labdát a cégek nyilván elfogadják, és az integráció új generációját már úgy tervezik, hogy architekturálisan is egymáshoz illő komponensekből álljon a lapka. Lásd Kaveri APU, mint a következő evolúciós lépcső. Ugyanezt fogja mindenki másolni. Az Intel is, csak a Larrabee leszármazottja még nincs olyan állapotban, hogy bevethető legyen.

  Elég sok dologra használható az IGP. Már az Intelé is elég okos. A peak FLOP teljesítmény az nem annyira erős, de jól etethető, így az átlagos tempója jó lehet. Persze ez függ az algoritmustól, de maximum a co-issue mód nem használható, az elsődleges vektor viszont etethető. A mire pedig a fejlesztőkön múlik. Nyilván lehet fizika számítására. Egyelőre a DiRT 3 használ ilyet a látványra DirectCompute 5.0-val, de lehet játékmenetre is. Vagy ott az AI gyorsítása. A Shogun 2 a Llano APU-n, illetve a Brazos platformon az AI-t az IGP-vel számítja. Persze ez nem általános kód, hanem egy CAL-ban írt dolog, vagyis semmi máson nem fut, de van OpenCL, lesz C++ AMP, így ezek a lehetőségek megnyílnak.

  A másik rész itt az általános programok területe. Ott az új WinZip 16.5, ami OpenCL-lel gyorsítja a feldolgozást. Ez egyelőre csak AMD-n működik, de a kód megvan, így kellő tesztelés után az Intel és az NVIDIA OpenCL driverére is engedélyezik. A WinZipben tisztán látszik az APU előnye. Az AMD Vision APU-kkal a gyorsulás mértéke 70-120% lehet terméktől függően. Sima VGA-val a PCI Express korlátozó, így ott a gyorsulás jóval kisebb. Nyilván az Ivy Bridge-es teszt még várat magára, de amint engedélyezik le lehet mérni, hogy mennyit gyorsul. Valószínűsítem a 60-70%-ot, mert az algoritmus hatékonyan futtatható ezen az IGP-n. Például az AMD TeraScale (aka VLIW) architektúráján a WinZip kódja nem olyan hatékony. Ez tipikusan abból ered, hogy az AMD ezt az architektúrát játékra tervezte, így sok helyen kompromisszumot kötöttek. A GCN architektúrán már nagyon hatékony a WinZip kódja. Például lehet venni egy 256 bites AES kódolást. Ezt lemértem a HD 5850-en és a HD 7850-en. Elméleti TFLOPS-ok tekintetében a HD 5850 jobban áll, de a HD 7850 mégis 3,8x gyorsabban futtatja az előbbi feladatott. Erre mondtam, hogy a peak FLOP érték nem biztos, hogy irányadó. Azt sem mondom persze, hogy nem, de ez nagyon függ a futtatott algoritmustól és az architektúrától.

  [ 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