Létezik olyan programkód, amelyik mind CPU-n, mind GPU-n azonos hatékonysággal fut? MErt most mindenki a heterogén programozás büvkörében él, de valahogy mintha a szoftveroldalon nem lenne hozzá partner.

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.

[ Szerkesztve ]

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

nem érted. Nem a GPGPU-val van a bajom, hanem a heterogenséggel. Melyik kód képes azonos hatékonysággal futni a processzor mikroarchitektúrán, s a gpu mikroarchitektúrán? Az, hogy skálázhatóság egy buzzword, mint a processzorok teljesítmérnynövekedés´3enek kényszerü tartása egy dolog. De a feladatok jellegükböl adódóan inkább egyik, vagy másik rendszerrel oldhatóak meg hatékonyan. Teszemazt FEA, GPGPU-ra termett. De Egy CAD modell átlalános értelemben meg procira való, hisz nem tudod hol párhuzamosan számolni az alkatrészt. Render megint gpgpu. Az meg, hogy majd a magasabb programozói siznt eldönti, hogy akkor min fusson, hát, a hatékonyságot figyelembe véve nem feltétlen a józan paraszti ész megoldása.

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.

[ Szerkesztve ]

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

Van olyan eset, amikor két, teljesen eltérö adatfeldolgozási folyamatnak kell ugyanaz a csekélyke adatmennyiség? Mikor fordul elö, hogy a kód ugrálni tud, vagy variálódik a két alkalmazástípus között? Tudtommal maximum kifejezetten erre készített demókódok esetén. Valós flehazsnálásnál van, amikor egyik, avagy másik a jobb?

tudom, önzö hozzáállás, de felhasználóként engem pont nem érdekel a befektetett munka, a teljesítmény ellenben annál inkább. Ergo megfizetem a célkódot, ha jobb teljesítményt nyújt. A jelek szeritn pedig azt nyújt. Itt most mindegy, hogy magasabb felületen majd az apu megmondja min fusson, vagy eleve megírják a gpgpu szerint, ha jobb, megfizeti a vevö. S a heterogén rendszer a hülye kivitele miatt fog akkor folyamatosan gyengébben teljesíteni bármely odlalon a tisztán oda írt kódokhoz mérten, valamint hardver odlalról is a prociba pakolt vga sosem lehet elég erös, illetve ha a vga-ba pakolunk procit, akkor az meg fölös kiadás lesz a végén.

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.

[ Szerkesztve ]

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

Nem vagyok benne biztos, hogy a HPC, Workstation szegmens ezt ennyiben hagyja, s csak így elfogadja, hogy rájuk eröltessék. ok, hogy midnen árszegmensben lesz valami kretén apu, de a végfelhasználót pont nem érdekli, ha neki erös gpgpu teljesítmény kell minimális prociteljesítménnyel, esetleg fordítva, mert olyna alkalmazásai vannak. Ha ne adj isten meg erös cpu és gpu is kell, akkor meg a tdp limit fogja megfogni a rendszert.

Otthon pistikének oly mindegy mi ketyeg, de egy cégnél, ahol megéri megvenni a fireprot, quadrot, teslát, ott kötve hiszem, hogy az apu nagyon labdába tud rúgni a hibrid lelkével és megkötéseivel.

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.

[ Szerkesztve ]

Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

Asszem HPC alatt mást értünk. Illetve alapvetöen a napi munkámból adódó területeken más jön elsöként képbe ezért gondolkodom máson. A számomra jobban meglevö hpc terület a kvázi kevés bemenö adatból gyárt sokat, így a kezdeti memóriaigénye nem akkora, mint a késöbbi, vagyis egy marha nagy memóriával megpakolt DGPU hatékonyabb tud lenni a végére, hisz nincs sok PCI-e adatmozgatás.

A sokfoglalatos deszka s azt pakolok bele ami kell, na az jöjjön nagyon gyorsan már.