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

• #19 Abu85 HÁZIGAZDA #06658560 #18

  Új Válasz 2012-06-28 09:46:14 #19

  Ú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 #06658560 #18 üzenetére

  A HPC kéri a legjobban az APU-t, mert nagyon nagy teher a PCI Express interfészen keresztül másolgatni az adatokat. Ez a nehéz a gyorsítók programozásában is, hogy van két lapka, amelyek különálló memóriával rendelkeznek, és a között megy ide-oda az adat.
  A Penguin Computing szokott erről előadásokat tartani, hogy rengeteg developer boardjuk van, amin tesztelnek AMD APU-kat és a HPC-s Tegra tesztelésében is részt vesznek. A jövőben a legnagyobb előny az lesz, hogy az APU-ban a CPU és az IGP teljesen koherens memóriát oszt meg. Ez meghozza az áttörést a HPC-ben, mert nem kell a data copy-val törődni az egységes memória miatt. Erre megy az AMD, az Intel és az NVIDIA integrációja is. Emellett a Penguin Computing nemrég előállt azzal, hogy a dedikált GPU-knak is van haszna, és lesz is, de csak úgy, ha olyan platformokat fejlesztenek a cégek, ahol több foglalat van az alaplapon és CPU-t vagy GPU-t lehet belerakni. Ezzel lehetőség nyílik, hogy a GPU-t az operációs rendszer ne csak gyorsítóként kezelje, hanem teljes értékű feldolgozóként. Sokkal könnyebb lesz majd így programozni. Ez persze még a jövő zenéje és az OS-t is módosítani kell, de az igények le vannak adva a gyártók felé. Az biztos, hogy a PCI Expresst el kell felejteni, mert ez a limitáció jelenleg. Csak egy példa a cloud szervereknél a offload memcached key lookup technika. Manapság egyre többször alkalmazzák (Youtube, Facebook, és a többi nagy cég is épít rá). Ez gyorsítható GPU-val, de nagyon erős GPU kell, hogy gyorsítson, mert a feladat végrehajtásából 2-3%-ot visz el a valós számítás és a maradék csak adatmozgatás a PCI Express buszon. Éppen ezért sokszor nem is gyorsabb a mai többmagos processzoroknál. Az viszont tisztán mérhető, hogy a GPU fényévekkel gyorsabban számol, csak a PCI Express büntet. Az integrációval ezt kiütőd, és rögtön ott van az E-350-es APU (itt is van data copy, mert a rendszermemóriában megvan az IGP és a CPU külön poolja is, de jóval gyorsabban megoldható), ami így gyorsabb tud lenni a leggyorsabb homogén többmagos processzoroknál. Mindezt tizedannyi fogyasztás mellett. Szóval az, hogy te mint felhasználó nem látsz rá igényt, még nem jelenti azt, hogy a cégek nem csurgatnák a nyálukat, mert a legnagyobb problémákra megoldás az integráció.
  A professzionális termékek más lapra tartoznak. De azt látni kell, hogy az Intel kínál ilyet. Erre válaszolni kell, mert a professzionális GPU-k piaca is olyan, hogy a low-end a menő. Ha ezt elviszi az Intel, akkor az gáz, tehát hozni kell a FirePro IGP-s Trinity-t. Lehet, hogy az AMD ezt nem így akarta, sőt szerintem biztos, de nincs más választás. A verseny rákényszeríti őket.

• #17 Abu85 HÁZIGAZDA #06658560 #16

  Új Válasz 2012-06-27 20:19:32 #17

  Ú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 #06658560 #16 üzenetére

  Algoritmustól függ. De a csekély adat az nem gond. Viszont inkább a viszonylag nagy adatmennyiség a jellemző, így a PCI Express buszon keresztül gáz, mert sok adatot kell mozgatni. Ezért szívás a GPU-val gyorsítható rigid body szimuláció. Persze ez a mai IGP-ken is szívás, ellenben az architekturális integrációnál már nem lesz az. A Bullett fejlesztői előadásán mondták is, hogy a Kaveri APU a jóval gyengébb IGP ellenére is sokkal több objektummal birkózik meg, mint a Radeon HD 7970, amiről ugye tudjuk, hogy egy compute monster a GPGPU számításról van szó.

  Bárki megfizeti, csak ott vannak az új OpenCL programok, mint a WinZip 16.5 és az új VLC. Mindkettő exkluzív AMD kódot tartalmaz. Semmi máson nem fut, és nem azért, mert az AMD megvette a támogatást, hanem azért, mert nagyon nehéz a kód teljesítményét portolni a többi hardverre. A WinZip fejlesztői már mondták, hogy a 17-es verzióban megoldják az Intel és az NVIDIA támogatását, de a VLC-sek egyelőre a HSA felé nézelődnek. Szóval az, hogy nehéz a kódot megírni és főleg portolni a megfelelő teljesítménnyel, az komoly gond.

  A helyzet egyszerű. A homogén többmagos processzorokat leváltják a heterogén többmagos lapkák. Az integráció egyre fejlettebb lesz. 2013-2015 közötti időszak az érdekes, amikor a cégek a lapkába pakolt CPU-t és GPU-t úgy tervezik, hogy kiegészítsék egymást. Tehát minden árszinten választhatsz APU-t. AMD/Intel/NVIDIA, és a Windows ARM-hoz való húzása mellett még a jó ég tudja, hogy kitől. A VGA-k esetében a problémát az jelenti, hogy drasztikusan csökken a kereslet. A HSA például kiterjeszthető VGA-kra is, mert technikailag ennek nincs akadálya. Az AMD-nek ez szerepelt is az útitervében 2011-ben. 2012 viszont más megvilágításba helyezi az egészet. Technikailag még mindig megoldható, de felmerült az a kérdés, hogy megéri-e. A piac mérete csökken, az új termékeket egyre drágábban fogják árulni, és az eladások is esnek vissza. Jelenleg nincs meg a biztosíték arra, hogy 2014-ben is lesz tömeges igény VGA-kra, és ekkora volt tervezve a HSA teljes kiterjesztése. Ha nem lesz értéke VGA-piacnak, akkor teljesen felesleges erre erőforrást pazarolni. Ezért tűnt el ez az útitervből. Nem tettek le róla, de már nem jelzik, mert jelenleg nem biztos, hogy két év múlva is lesznek új VGA-k.

• #15 Abu85 HÁZIGAZDA #06658560 #14

  Új Válasz 2012-06-27 18:40:59 #15

  Ú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 #06658560 #14 üzenetére

  Semelyik. Az egyik feladat csak GPU-n, míg a másik csak CPU-n hatékony. Ez abból ered, hogy a CPU egy késleltetésre optimalizált erőforrás, míg a GPU-t az adatpárhuzamos végrehajtásra optimalizálták. Ezért megyünk a heterogén éra irányába, mert ha egy lapkán van ez a két erőforrás, és teljesen koherens memóriát osztanak meg, akkor a feladatokat mindig azon lehet elvégezni, amelyik erőforráson hatékony a munkavégzés.

  Nyilván a legjobb teljesítményt OpenCL-C-vel fogják elérni a fejlesztők, de rengeteg vele a munka, szóval a magasabb szintű felületnek van értelme. [link] - ez a grafikon eléggé jól mutatja, hogy a teljesítmény enyhén esik, de a befektetett munka kevesebb, mint serial kódnál. Szóval ez egy elég jó megoldás. A mérések egyébként A10-5800K APU-n futottak.

• #13 Abu85 HÁZIGAZDA #06658560 #11

  Új Válasz 2012-06-27 17:28:42 #13

  Ú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 #06658560 #11 üzenetére

  Nem ez a lényeg, hanem az, hogy gyorsítva legyen. A CPU és a GPU másra jó. Ezt kell hatékonyan kihasználni.
  Azért él minden cég ennek a bűvkörében, mert nem találnak más megoldást a Dennard scaling zátonyra futására. Biztos átrágtak minden lehetőséget. Az, hogy mindenki ugyanerre a következtetésre jutott eléggé egyértelművé teszi, hogy a heterogén módon programozható többmagos termékek jelentik a jövőben a skálázhatóság kulcsát. A szoftver oldalon sem lesz választás, mert vagy beállsz a sorba, vagy a programod sebessége nem fog nőni, és akkor letarol egy konkurens cég, aki beállt a sorba. Az persze igaz, hogy kell a magas szintű felület az APU-k programozására, de már bemutatták a HSA-t. Az NV-nek ott a CUDA, amit nyilván továbbfejleszthetnek. Az Intelnek is van hasonló felülete. Azt elő lehet venni. A többi cég pedig beáll a nyílt HSA mögé, mert idő már nincs új felületet kidolgozni. Az, hogy az ARM beállt sok választást nem biztosít a partnereknek.

  A programok oldaláról jelenleg nagyjából 200 GPU-t általánosan kihasználó alkalmazás van. Idén eléggé sokat léphetünk előre, mert az OpenCL-C++ és a C++ AMP segít a programozásban. A tényleges megoldás viszont egy magas szintű felület, mint a HSA Bolt.

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