- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- VR topik
- A Micron újszerű módszerrel javítja QLC-s SSD-jének sebességét
- Milyen videókártyát?
- Továbbfejlődött a Keychron egéralternatívája a Logitech MX Masterre
- AMD Navi Radeon™ RX 9xxx sorozat
- Radeon RX 9060 XT: Ezt aztán jól meghúzták
- HiFi műszaki szemmel - sztereó hangrendszerek
- Kezdő fotósok digitális fényképei
- Milyen billentyűzetet vegyek?
Új hozzászólás Aktív témák
-
-
Reggie0
félisten
-
#69
dezz
nagyúr
FollowTheORI
#63
dezz
nagyúr
válasz
FollowTheORI
#63
üzenetére
Az implementáció (~fordítás) és a konfiguráció (átprogramozás) két különböző dolog! Az első akár napokig is tarthat a legkomolyabb FPGA-knál, a második viszont másodpercek kérdése... Tehát nem feltétlen kell leállnia a rendszernek hosszabb időre. Az pedig alkalmazási terület és projektfüggő, hogy az adott program (v. újabb verziójának) elkészítése után belefér-e még pár óra vagy esetleg egynéhány nap, amíg azt futtatják is.
Mint már írtam, ahol elsődleges szempont a fogyasztás és/vagy teljesítménysűrűség (adott m3-ből mekkora teljesítmény hozható ki, hűtéssel együtt), ott tarolhat az FPGA, ha meglesz ez az OpenCL-es dolog...
A GPU éppen, hogy nem túlságosan rugalmas... Sok-sok butácska számoló egység, amiknek a relatíve egyszerűbb számítások nagyon fekszenek (és ebben messze felülmúlják pl. a CPU-kat), a komplexebbek viszont nem annyira. Ilyen esetben is nyerő lehet az FPGA!
-
Reggie0
félisten
válasz
Alchemist
#67
üzenetére
Hm, a sakkprogramra nem is gondoltam.
Mi anno SHA1 szamitast akartunk atrakni FPGA-ba, de a GPU osszessegeben optimalisabb, egyedul a fogyasztasban volt jobb az FPGA. A beruhazasbol nem lett semmi, mert tul hosszu volt a megterules es nem egyertelmu, hogy meddig piackepest egy ilyen kapacitas.
-
Alchemist
addikt
Nemrég írtam a témában, hogy pl. a sakkprogramok sok bitszintű logikai műveletet és rengeteg elágazást tartalmaznak, ráadásul a párhuzamosítható programrészek eredményei, futási idejük az adatoktól függően nagymértékben eltérhet és ezért nem igazán világos, hogyan lehetne hatékony és ugyanakkor kifinomultan számoló GPU-s gyorsítást létrehozni.
Viszont ilyesmire pont jó lenne sok kis-közepes kapuszámú FPGA, kis késleltetésekkel megszólíthatóan. -
#66
Reggie0
félisten
FollowTheORI
#63
Reggie0
félisten
válasz
FollowTheORI
#63
üzenetére
Hat azert ez nem teljesen igy van. Pont a sok parhuzamos vegrehajto funkcionalitasaban kene megtalalni az optimumot, mert ha egy ilyen egyseg tul komplex, akkor hiaba gyors, de az egyszeru muveleteket mar lassabban hajtja vegre, mint az idealis lenne es keves fer el belole, tehat sok ciklus kell es csokken a parhuzamos szalak szama, stb. stb.. Mig ha egy ilyen egyseg tul egyszeru, akkor hiaba van belole sok, mire bedrotozott a kivant funkcionalitast, az egesz osszessegeben mar lassu lesz(na ilyen az FPGA).
Az idealis az lenne, ha a HPC-kben hasznalt muveleteket fedne le egy ilyen eszkoz, raadasul ugy, hogy ezekbol a vegrehajto egysegekbol olyan aranyban lenne a csipen, mint amilyen gyakorisaggal alkalmazzak. Mondok egy elrugaszkodott peldat, de ha hardverbol tudna vegrehajtani az integralas egyes alaptipusait, mar lenne ertelme, mert nem kell szorzasokbol, osszeadasokbol, stb. osszedrotozni, ami nyilvan optimalisabb lenne. A GPU-k alapvetoen terszamitasokra talaltak ki, de teszem azt ha te idofuggo schrodinger egyenleteket akarsz szamolni, akkor nem biztos hogy ez adja a legoptimalisabb eszkozkeszletet. Az teny, hogy a CPU-nal jobb... -
#65
LordX
veterán
FollowTheORI
#63
LordX
veterán
válasz
FollowTheORI
#63
üzenetére
HPC, mint kicsi szegmens? 2008-ban a HPC piac 10 milliárd dolláros eladást bonyolított. Ugyanebben az évben a GPU piac 17 milliárd dollárra becsült volt. Azóta az egyik csökkent, a másik nőtt.
-
#64
FollowTheORI
nagyúr
Amiből meg a hír indult hogy vettek egy spéci feladatot és idealizálták hogy mindig az a feladat és ezért hatékonyabb az FPGA szerintem nem elég bizonyíték.
Ha vettek volna egy sziliciumba öntött implementációt, még jobb hatékonyságot láttak volna, ez is eléggé evidens.
De mi van ha általánosabb valami kell, ami picit mindig változik fejlődik?
Persze sok okos ember ül ott az Alteránál meg mindenhol biztos, de szerintem ez kicsit elhamarkodott kijelentés.
Még akkor is ha sok benne a "may" magyarul "talán/ha" szó... de meglátjuk.
Nem vagyok ellene, de jelenleg még nem hiszem el. -
#63
FollowTheORI
nagyúr
dezz
#43
Jogos.
Ezt néha elírom... szilícium. Jaja tudom én csak hát néha gyorsabb a kezem mint az átgondoltságom....
Értem amit írtatok, de gondolj bele miért alakult ki a GPU mint olyan?
Ott is előtte az volt hogy volt egy gyors célhardver... majd rájöttek jobb az ha többféle feladatra lehet fogni a dolgot, ha már ott az a sok tranzisztor... aztán a végén mindig oda jutottunk el, hogy az a "legjobb", ha van sok kis általános gyors végrehajtó és azt a program dönti el milyen magasabb műveletet valósítassz meg vele.Értem én hogy a HPC részen eléggé speciális feladatok lehetnek, de ez egy olyan kicsi szegmens hogy nem érné meg piaci alapon.
Gondolj bele van egy kutató cég vagy egy egyetem, akármi ott általában a HPC rendszert arra használják hogy mindenféle szimulációkat végezzenek, ahol a feladat mindig változik. Akár napon belül is... ilyenkor mindig újra kéne fordítani és szintetizálni az egész sokmillió FPGA-ból álló projektet. Nem biztos hogy van arra idő hisz addig áll az egész rendszer, ami HPC esetén nem olcsó mulatság és épp az a cél ezeknél mindig hogy folyamatosan maximumon menjen, akkor éri meg.
Persze erre írhatod hogy épp azért van ott az "általános" OpenCL, csak a probléma az hogy ezt nem hiszem meg fogják tudni jól és hatékonyan oldani. Eddig is volt próbálkozás C-ből meg egyéb nyelvekből hardver meg FPGA fordítót csinálni. Egyszerűbb kódokra még néha jól is működött, de amint komplexebb a probléma eléggé megnehezült (ha nem épp ellehetetlenült) a megvalósítás. Főleg úgy hogy elég gyors és hatékony legyen.
Eddig általában jobb volt az eredmény nagyon komplex problémák esetén is akkor ha inkább sok-sok egyszerű párhuzamos végrehajtó dolgozott az ügyön. Ezért van egyre több CPU vagy épp egyre általánosabb GPU a HPC rendszerekben.Egy egy nagyon spéci esetben el tudom képzelni hogy működik, de túl drága lenne szerintem ahhoz hogy érdemben elterjedjen.
Én azt mondom és azis látszik eddig hogy mindig jobb a több kicsi egyre gyorsabb végrehajtó és annak a programozása. Mert egyszerűen könnyebb kezelni és rugalmasabb, hatékonyabb.
Tényleg ott működhetne ez jól ahol pl mindig mondjuk atomrobbantást szimulálnak és ritkán változik a szimulációs módszer (vagy bármi hasonló, időjárás, földrengés... stb).
De nem véletlen ezen területeken sem csináltak célhardvert eddig... mert ha belegondolsz egy relative állandó FPGA jó lenne, akkor egy szilikonba ültetett célhardver mégjobb. Nemde?
Ha meg mindig változik, akkor lásd fentebb.Persze oké, bejöhet hogy tudnak csinálni egy gyors és jó OpenCL fordítót ami elég jó ér hatékony hardver kódot generál... de én egyelőre kevés esélyt látok az eddigi próbálkozások alapján.
-
JColee
őstag
Szerintem a másodikra gyúrnak. Az elsőnek nem lenne értelme, mert ennyi erővel normálisan le is lehetne gyártani azt a "kvázi virtuális gépet".
Utóbbi esetben mire kellhet külön odafigyelnie az OpenCL programozónak?
Ez akkor kiderül, ha kész lesz a környezet. Lehet majd menni drágáért alterás tanfolyamra, ahol elmondják, hogy a szintézer milyen struktúrákat ismer fel, miket lehet használni, miket kerüljön az ember, stb. -
dezz
nagyúr
Én arra lennék kíváncsi, hogy kiképeznek-e itt egy (a GPU-knál rugalmasabb) kvázi virtuális gépet, amin az OpenCL kód "fut", vagy az utóbbi közvetlenül fordulhat low-level logikai kifejezésekre? Utóbbi esetben mire kellhet külön odafigyelnie az OpenCL programozónak?
(#46) cousin333: "DevKit? Miért kellene azt megvenni?" - Én nem beszéltem DevKitekről.
3. A partícionálás és a részleges rekonfiguráció két különböző dolog.
(#56): "Nagyjából azt, amikor HDL kóddal úgy körülírod a HW-t, hogy "eszébe se jusson" mást fordítani, mint amit te eredetileg elterveztél, ahelyett, hogy magát a problémát írnád le, aztán majd hardveresen lesz belőle, amit jónak lát."
Az elsőt hogyan kivitelezed, tekintve hogy az implementáció többlépcsős folyamatában először is megkerestetnek a lényegi logikai műveletek, majd ehhez az optimlis elvi áramköri kialakítás, végül ennek a meglévő fizikai formákba öntése?
-
Reggie0
félisten
Ha ez igaz lenne, mar regebben elterjedt volna az FPGAs megoldas, de tobb probalkozas ellenere ez megsem jellemzo. Ha a HPC uzemeltetoknek ennyire nem szamitana a bekerulesi ar, akkor mar 100 kulonfele keretrendszer lenne a programkod forditasara/szintetizalasara, mert megerte volna kifejleszteni.
-
#58
LordX
veterán
VaniliásRönk
#11
LordX
veterán
válasz
VaniliásRönk
#11
üzenetére
Akkor újrafordítod?
-
LordX
veterán
-
cousin333
addikt
"Nem tudom, te mire gondolsz kézi kód alatt."
Nagyjából azt, amikor HDL kóddal úgy körülírod a HW-t, hogy "eszébe se jusson" mást fordítani, mint amit te eredetileg elterveztél, ahelyett, hogy magát a problémát írnád le, aztán majd hardveresen lesz belőle, amit jónak lát.
"olyat is egyszerűsített, amit nem kellett volna."
Ezzel bizony vigyázni kell. De nem csak itt.
-
JColee
őstag
válasz
cousin333
#53
üzenetére
Nem tudom, te mire gondolsz kézi kód alatt. De valóban nagy projektnél, több fejlesztővel nem lesz tökéletesen lefaragva a dolog.
Amúgy jártam már úgy, igaz az nem fpga-ra ment, hanem asicre, hogy olyat is egyszerűsített, amit nem kellett volna. Biztos meg lehetett volna adni, hogy ne tegye, de máshogy oldottam meg.
"Sok apró digitális áramkör" igaz akármelyik processzorra. Abban is van sok apró digitális áramkör. -
cousin333
addikt
Azt szoktam mondani, hogy egy jó találmánnyal két probléma lehet: ha túl későn érkezik, vagy ha túl korán. Lásd a Dell 5"-os mobilját, és annak "sikerét" összevetve a mai, akár még nagyobb telefonokéval.
"de egyelőre biz' a szoftveres cuccoknak áll a zászló"
HW-ből szerintem nem sok minden áll közelebb a szoftverhez, mint az FPGA. Főleg, hogy még CPU-t is implementálhatsz bele, akár szoftosan, akár hardosan...
-
cousin333
addikt
"Szerintem pont a komplexitás növekedésével lesz egyre pazarlóbb a szintetizált hardver."
Mihez képest? A kisebb komplexitáshoz képest biztosan. A kézi kódhoz képest már nem annyira. Itt arra gondolok, hogy esetleg olyan összefüggéseket, egyszerűsítéseket "lát meg", amit te már nem látnál át a kód mérete miatt. A fejlesztés sebessége meg határozottan gyorsabb lesz. Nem beszélve a kipróbált kitesztelt modulok alkalmazásáról, szemben a fifikás egyedi optimalizációval, amiről csak később derül ki (sok-sok munka árán), hogy bugos vagy nehezen bővíthető, hordozható.
"Azért lássuk be, ez eléggé ködös bullshit"
Nem bullshit, de igaz, nem is fejti ki az igazság minden részletét...
-
#52
Rive
veterán
FollowTheORI
#36
Rive
veterán
válasz
FollowTheORI
#36
üzenetére
Sosem lesz egy FPGA olyan gyors mint egy adott szilikonba implementált áramkör.
Csakhogy ehelyett inkább a kvázi általános célú programozható cuccokkal versenyez: azoknál pedig vastagon tud jobb lenni.
Amúgy 'vótmá'. Anno socket939 alapon több cég is kijött afféle 'koprocesszor' FPGA kártyákkal, 5-7000 dollár körüli áron. Érdekes próbálkozás volt, de - finoman fogalmazva - nem arattak osztatlan sikert. Nyilván, ha kicsit combosabb interface kerül alájuk mind memória, mind programozási oldalról, az kicsit felkavarhatja az állóvizet, de egyelőre biz' a szoftveres cuccoknak áll a zászló.
-
JColee
őstag
válasz
cousin333
#47
üzenetére
Szerintem pont a komplexitás növekedésével lesz egyre pazarlóbb a szintetizált hardver. HDL szinten eléggé hardverközeli módon írjuk le a dolgokat, és még így is csinál néha felesleges dolgokat, amit ki lehetne gyomlálni. Magasabb szinten leírt programban még nehézkesebb lesz adott szerkezeteket felismernie a szintézernek a nagyobb szabadsági fok miatt.
Amúgy igazad van, hogy hiába pazarlóbb a magasabb nyelven leírt kód, ha sokkal gyorsabban kész van a feladat. Aztán úgyis jön az újabb vas, amibe még több okosság fér.#46 Azért lássuk be, ez eléggé ködös bullshit: Ezt úgy érdemes elképzelni, hogy az FPGA, azaz a Field Programmable Gate Arrays egy olyan lapka, mely rengeteg apró digitális áramkört tartalmaz.
-
#49
ddekany
veterán
Blindmouse
#15
ddekany
veterán
válasz
Blindmouse
#15
üzenetére
"Igazából nem tudom hogy lehetne a jelenlegi programozókat beidomítani, hogy a hardveren tudjanak dolgozni."
Úgy, hogy kifizeted a szokványos órabért nekik, csak épp lenyelned, hogy 10x annyi ideig fog tartani a fejlesztés, tehát 10x annyiba fog kerülni. Amíg kifizeted a programozóknak... érted, az emberek azt tanulják, amire kereslet is van.
-
lenox
veterán
válasz
cousin333
#47
üzenetére
Jo, hat az fpgak eseteben ketlem, hogy ennek gyakorlati haszna van. A reszecske fizikus kodja szerintem cpun vagy gpun gyorsabban fog futni, mint fpgan, aki ki tudja hozna az fpga-bol a megfelelo teljesitmenyt, annak meg mindegy lesz, hogy melyik nyelven kell irnia. De ez csak egy velemeny, legfejlebb tevedek.
-
cousin333
addikt
Hosszútávon az a lényeg, hogy ne kelljen hozzá annyira érteni. Nyilván nem lesz sosem olyan, mintha direktbe, optimálisan írnád meg. Bár azért egy bizonyos komplexitás felett a fordító csinálhat jobb HDL kódot, mint amilyet te írnál, még ha értesz is hozzá. De legalábbis gyorsan elkészülne vele, míg mire te a kézi módszerrel készítesz valami igazán ütőset, ami esetleg rosszabbul hordozható vagy skálázható, addigra ott a 2x jobb hardver.
A másik, amit említettél is, hogy itt a tudás a lényeg. Az, hogy mit akarsz implementálni, és nem elsősorban az, hogy hogyan. Márpedig valószínű, hogy a tudás birtokosa (pl. egy részecske-fizikus) jobban átlátja, hogy mit akar, mint az, aki amúgy penge az FPGA-k terén.
-
cousin333
addikt
Pár gondolat (igyekszem 1 hsz-ben
):VaniliásRönk (#3): Az FPGA-k lényege benne van a nevében: Field-Programmable Gate Array. Ezek mindig is programozhatóak voltak és most sem lesz ez másképp.
korcsi (#5): Szerintem alapvetően nem nehéz programozni, csak szokatlan. Mármint a "hagyományos" programozáshoz képest. Itt az egyes elemek/modulok valóban párhuzamosan, egymástól függetlenül futnak, nem csak látszólag, mint egy 1 magos processzornál (de a 8-cal is hasonló lenne a helyzet).
JColee (#13): "Szóval a cikk jobban körüljárhatta volna az egész témakört, leírhatta volna az fpga-k lelki világát."
Ez egy hír, nem cikk. FPGA-k körüljárása kicsit több időt (és oldalt) igényelne.
VaniliásRönk (#17): "Szoval egy FPGA-ban "egyszeruen" ossze vannak hanyva a funkciok, aztan mazsolazd ossze ami kell?"
Mint már többen is írták, alapvetően nem. Van egy alap modul, ami képes 1-2 bitet tárolni, illetve 4-6 bemenet összes létező kombinációjára egy 1-2 bites kimenetet adni, ami így elmondva nem túl sok. De ezekből van több százezer, vagy millió, abból azért már elég komplex dolgokat lehet kihozni. Mindezek mellé van egy rugalmas vezetékezés az egyes komponensek között.
Bada Bing (#24): Azt se felejtsük el, hogy ezen programozható elemek mellett vannak fixen bedrótozott modulok is a legalapvetőbb funkcióknak, úgyis mint RAM (akár MB-os nagyságrendben) vagy DSP (szorzásra) vagy éppen nagy sebességű soros kommunikáció lehetősége.
VaniliásRönk (#26): "Rendben, de akkor hol van a dolog szépséghibája? Mert pl. szuperszámítógépekben nem látom akadályát miért ne terjedtek volna el eddig is tömegesen."
Ahhoz, hogy használható legyen, kell kiforrottság HW és SW (pl. fordító) terén, értelmes léptékű erőforrások és nem utolsó sorban piaci igény (esetleg kényszer) a változásra.
"Fontos információ, hogy az Intel egyedüliként az Altera-nak végez bérgyártást"
Más kisebb FPGA gyártóknak is nyújt ilyesmit pl. Achronix.
dezz (#33): DevKit? Miért kellene azt megvenni? Nem egy fejleszteni akarnak elsősorban, hanem futtatni. Na meg számolni. Ahhoz meg nem kell sok extra komponens. A jelenlegi (nagy) FPGA-kat viszonylag kis szériában gyártják, ha nő az érdeklődés, az ár is csökken.
NetTom (#36): "Az FPGA csak ott alternatíva ahol nem éri meg sorozatgyártani egy adott spéci áramkört a kis volumen miatt."
Mint például HPC-kben?
Gondolom ott éppen hogy jól jön a rugalmas áramkör (pl. ha éppen 19 bites regiszter kell, akkor olyat implementálnak, nem 32 vagy 64-est). Meg aztán az, hogy hány darab éri meg, folyamatosan változik, és gyanítom, hogy nő ez a szám."Maximum abban hogy egyes egyedi részfeladatok egy egy spéci áramkörrel gyorsíthatóvá válnak"
És ez nem elég? Pont az a lényeg, hogy ezekre az egyedi részfeladatokra már nem a CPU-t vagy a GPU-t kell használni, tehát vagy csinálhatnak közbe mást, nincs szükség olyan sokra belőlük.
lenox (#38): "Azt a reszet nem latom, hogy miert lesz igy jobb, ha opencl-lel lehet programozni."
Mert lesz egy magasabb szintű programozói felületed, ami esetleg transzparensen is működhet a GPU és az FPGA (és a CPU) között. A hardverek viszonylag gyorsan fejlődnek, egy bizonyos szint után már jobb, ha inkább a szoftverfejlesztést gyorsítod (egyszerűsíted), akár a HW követelmény kárára is.
Még pár megjegyzés:
1. Az FPGA elég egyszerű felépítésű, elég hamar át is állnak mindig a kisebb csíkszélességre.
2. A "fordítás" sok időt vehet igénybe, de ha komoly számítási mennyiséghez kell, akkor esetleg megéri az a néhány perc (óra, nap...).
3. A mai FPGA-k esetén nem kell feltétlenül mindig mindent "lefordítani". Lehet előre "legyártani" kisebb modulokat, amiket aztán igény szerint, akár futás közben is cserélgetsz, lásd dinamikus (parciális) rekonfiguráció. Ez kicsit olyan, mintha a videokártyádban az éppen aktuálisan futtatott játék igényétől függően állíthatnád be a különböző feldolgozóegységek arányát (ehhez több textúrázó kell, ahhoz inkább több raszterizáló egység... stb.).
-
lenox
veterán
Oke, de szerintem van egy olyan resze, hogy a nyelv az csak egy syntax, a tudas nem ebben rejlik, hanem amit csinalni akarsz. Nekem pl. mindegy, hogy opencl-ben vagy cuda-ban irom a kodot a gpu-ra, mert az a lenyeg, hogy ertsem az absztrakciot. Ugyanigy aki fpga-t fog programozni opencl-ben ha nem csak hello world-ot fog irni, akkor nagyon kell ertse az fpga-t is, nem eleg, hogy az opencl-t erti. Tehat szerintem egy 'mezei' opencl fejleszto nem fog boldogulni vele, plane nem fog jo kodot irni.
-
#43
dezz
nagyúr
FollowTheORI
#36
dezz
nagyúr
válasz
FollowTheORI
#36
üzenetére
+ Bada Bing: Nem szilikon (angolul silicone), hanem szilícium (silicon).
"Sosem lesz egy FPGA olyan gyors mint egy adott szilikonba implementált áramkör."
Ez így van, ha a chip a konkrét feladat implementációja. A GPU-k esetén ez nem áll fent, hiszen az nagyrészt viszonylag egyszerű, de multipurpose számolóegységek méretes tömbje, amin programok futnak. Az adott OpenCL kód hatékony FPGA-s megvalósításával kompenzálható a kisebb órajel és kevesebb áramköri elem.
"Az FPGA csak ott alternatíva ahol nem éri meg sorozatgyártani egy adott spéci áramkört a kis volumen miatt."
Mint a cikkből kiderül, ott is jó lehet a GPU-k ellenében, ahol a fogyasztás is fontos.
(#37) Bada Bing: Az említett árak, mint már ott is írtam, nem DevKit árak, hanem 1-1 chip kerül ennyibe a kereskedelemben. Nagyobb mennyiségű bevásárlásnál nyilván csökken az ár, de szerintem nem a töredékére.
(#38) lenox: Az OpenCL célközönsége idegenkedik a HDL nyelvektől...
(#42) Reggie0: Mint korábban elhangzott, nem a kommersz videokártyák árával kell itt hasonlítgatni, hanem a Teslák, amik szintén többezer dollárba kerülnek. Mondjuk a cikkbeli esetben a 2k USD vs. 8.5k USD kicsit húzós... De megérheti valakinek, aki pl. igen nagy teljesítménysűrűségre törekszik.
-
Reggie0
félisten
Arra, hogy OpenCL-el jatszanak rajta es meg valamennyire fel szeretnek venni a versenyt a GPU-k araval.
Ha szeretnel csinalni egy clustert szamitasi feladatokra, akkor jobban megeri tobbet venni a cyclonbol, mint stratix-ot venni.A prototyping mas kerdes, nyilvan oda a legnagyobbak kellenek.
-
-
Bada Bing
tag
Azért jó, mert az OpenCL kezd a sztenderd nyelvévé válni az adatintenzív, párhuzamos programoknak. Egyre többen egyre több programot írnak ezen a nyelven, kézenfekvő tehát, hogy támogassuk.
Ugyanazért támogatják az FPGA gyártók az OpenCL-t, amiért Androidra is Java-ban kell fejleszteni és nem egy frissen kitalált nyelvben. Ha egy FPGA-ra is lefordíthatod azt a programot, amit megírtál, akkor jobb eséllyel fogsz FPGA-t venni hozzá, mintha erre nem lenne lehetőséged.
-
lenox
veterán
Szerintem legrosszabb esetben sajat opencl extension-on keresztul biztos tudnak olyat csinalni, amitol nem lesz annyira bekorlatozva, hogy ertelmetlen legyen. Azt a reszet nem latom, hogy miert lesz igy jobb, ha opencl-lel lehet programozni. Mert elso korben azert lehetne jo, mert akkor fut esetleg celhardver nelkul cpu-n, de ahhoz a cpu drivernek is kell majd supportalni a spec extension-oket.
-
Bada Bing
tag
Tényleg nem jogos a devkitek árát összehasonlítani sorozatgyártott termékekével. Egy FPGA lapka ára ennek igenis a töredéke, tehát ha valaki aláépíti a hardvert, akkor a végterméknek nem kell drágábbnak lennie egy videokártyánál vagy egy felsőkategóriás processzornál.
(#36) NetTom: nem szilikonba implementált áramkör, hanem konkrétan GPU-k alternatívájaként említi a cikk az FPGA-kat. Ha egy hétig akarsz futtatni egy algoritmust, akkor megéri egy órát eltölteni vele, hogy ingyen lefordítsd az FPGA fejlesztőkörnyezetedre. Nem éri meg ugyanakkor milliós összegeket és fél évet eltölteni azzal, hogy szilinkonon implementáld. Az órajel pedig önmagában semmit nem jelent.
Érdemes szem előtt tartani, hogy itt most nem az FPGA-k újdonságáról van szó, hanem az OpenCL nyelvéről. Ma is nagy számban alkalmaznak már FPGA-kat jelfeldolgozási feladatokra. Ugyanezen feladatokra GPU-kat is lehet használni. Leginkább csak annyi fog változni, hogy ezeket a feladatokat hamarosan OpenCL nyelven is le lehet írni akkor is, ha FPGA-ra szeretnénk ezeket letölteni.
-
#36
FollowTheORI
nagyúr
Sosem lesz egy FPGA olyan gyors mint egy adott szilikonba implementált áramkör.
Az FPGA csak ott alternatíva ahol nem éri meg sorozatgyártani egy adott spéci áramkört a kis volumen miatt.
Órajelekben egy komplex FPGA megoldás messze elmarad egy GPU-tól... ezt szerintem egy GPU fejlesztő is simán meg tudná erősíteni.
Arra jó hogy kipróbálják egyáltalán müködik e a megoldás.Amit a post címe utal nem hiszek.
Maximum abban hogy egyes egyedi részfeladatok egy egy spéci áramkörrel gyorsíthatóvá válnak, míg általános CPU vagy GPU-n lekódolva nem elég hatékonyak. De azért sok ilyen feladatot nem tudok elképzelni most.
-
#33
dezz
nagyúr
shabbarulez
#12
dezz
nagyúr
válasz
shabbarulez
#12
üzenetére
DevKit? A Stratix-IV 530K darabja ~8500, ~18'000 vagy ~28'000 USD, attól függően, hogy E, GT vagy GX típus (valószínűleg az E-t használták, de nem biztos). Ezeket a legnagyobb FPGA-kat általában komolyabb IC tervek sorozatgyártás előtti gyakorlati kipróbálására használják, ahol néhányezer vagy akár néhánytízezer dollár a teljes R&D töredéke.
Ehhez képest pl. a Tesla C2075 ára 2200 USD. Úgyhogy, vagy az FPGA-gyártók gondolják újra az árazásukat, vagy csak igen szűk körben kerülnek majd ilyetén alkalmazásra ezen termékeik.
Szerintem, bár az OpenCL leegyszerűsíti az FPGA számítási feladatokra való bevetését, ugyanakkor viszont le is csökkenti a lehetőségek számát... Mármint, így nem lehet kihasználni az FPGA-k teljes potenciálját. De elképzelhető, hogy bizonyos tekintetben így is többre képesek, mint egy mai GPU. Lenox, mit gondolsz erről?
Egyébként hogy lehetséges az, hogy a Xeon jobb telj./fogy. aránnyal rendelkezett, mint a Tesla? Főleg egy ilyen, viszonylag egyszerű és jól párhuzamosítható algoritmussal?
-
-
Seregély
tag
Szerintem ez lesz a következő programozási paradigma váltás. Fontos információ, hogy az Intel egyedüliként az Altera-nak végez bérgyártást, annak fejében, hogy speciális FPGA változatokat fejlesztenek nekik. Csendben kihoztak olyan MCM-t, amiben egy Atom mellett FPGA van tokozva. Nálunk is van próbára néhány, és igen brutális dolgokat lehet kihozni belőle. Jövőre ígérnek már egy szilikonra integrált változatokat is, nem csak Atommal. A HW már készen áll, de a piac illetve a fejlesztők még nem. Én el tudom képzelni, hogy a gpGPU-t gyorsan át fogjuk ugrani és eljön a FPGA-k ideje.
http://download.intel.com/embedded/processors/prodbrief/324535.pdf
-
lenox
veterán
Lehet, de pl. en azt tippelnem, hogy a gpuk az utobbi 5 evben jobban fejlodtek, mint az fpgak, es 5-10 eve is voltak cegek, akik fpga-t probaltak eladni, pl. az sgi-nak es volt fpga-s node-ja, de megsem terjedt el mint altalanos celu eszkoz. Most az uj dolog az opencl. Ennek egy baja van, hogy szerintem aki veszi a faradtsagot, hogy egy ilyen fejlesztest megcsinaljon annak opencl ide vagy oda akkor is nagy kockazatot kell vallalnia, amit valoszinuleg opencl nelkul is vallalt volna. Ezek a cegek szerintem mar most is aruljak az fpga-s megoldasaikat, szoval az opencl szerintem nem fog sokat segiteni.
-
#27
Reggie0
félisten
VaniliásRönk
#26
Reggie0
félisten
válasz
VaniliásRönk
#26
üzenetére
Rohadt draga es sok ido mire megterul. Ha a magyar lakossagi villanyarat nezzuk, akkor kb. 2 ev a beruhazas megterulese, de az ilyesmiben utazo cegek joval olcsobban veszik az aramot igy ez az ido erosen kitolodik. Viszont a GPU-k fejlodesevel is fel kell venni a versenyt. Tehat mire hasznot hozna a valtas, addigra lehet lecserelni vagy boviteni.
-
#26
VaniliásRönk
nagyúr
VaniliásRönk
nagyúr
Rendben, de akkor hol van a dolog szépséghibája? Mert pl. szuperszámítógépekben nem látom akadályát miért ne terjedtek volna el eddig is tömegesen.
-
#24
Bada Bing
tag
VaniliásRönk
#21
Bada Bing
tag
válasz
VaniliásRönk
#21
üzenetére
Nem. Az FPGA teljesen általános logikai elemeket tartalmaz, amelyek tetszőleges logikai függvényt képesek megvalósítani. Az OpenCL parancsokat elvégző elemeket ilyen általános logikai elemekből állítjuk össze, amikor felprogramozzuk az FPGA-t. Tehát amikor legyártják a lapkát, akkor még azok a logikai elemek akármivé összeállhatnak, akkor válnak OpenCL utasításvégrehajtókká, amikor az emlegetett kapcsolókat ennek megfelelően állítjuk be.
-
#23
JColee
őstag
VaniliásRönk
#21
JColee
őstag
válasz
VaniliásRönk
#21
üzenetére
Pedig ez a lényeg:
Sok (milliós nagyságrend) ilyen blokk variálható kapcsolásával lehet megvalósítani tetszőleges (nem teljesen igaz, de sebaj) digitális áramkört. Ott van benne a d flip flop, a LUT-okkal a logikai alapkapukat lehet implementálni, és ott van egy teljes összeadó is. -
#22
Reggie0
félisten
VaniliásRönk
#21
Reggie0
félisten
válasz
VaniliásRönk
#21
üzenetére
Itt van az Altera osszefoglaloja, hogy ezt hogyan is kepzeltek megvalositani.
-
#21
VaniliásRönk
nagyúr
JColee
#18
VaniliásRönk
nagyúr
Nyilván én is itt próbáltam körülnézni először, de sokkal okosabb nem lettem tőle, részletekbe nem megy bele.
#19 Bada Bing: Nem inkább a különböző műveletvégző egységeket lehet tetszőlegesen szervezni? Tehát ha készül egy design OpenCL-hez, akkor annak tartalmaznia kell az OpenCL-ben kiadható parancsokat elvégző logikai blokkokat. Jól gondolom?
-
Reggie0
félisten
Az energiahatekonysaga jobb, viszont baromi draga. Egy videokartyaval osszevetheto teljesitmeny(persze ez funkciotol is fugg), nagyjabol 4x..5x annyiba kerul.
(#15) Blindmouse: Jo neked, nekem volt, hogy egy hetig szamolt(XC6LX45-re). Ez attol is fugg, hogy milyen optimalizaciot csinaltatsz es mennyire tomod meg.
Akit erdekel az FPGA, annak javaslom a ztex eszkozoket (ztex.de). Csak egy USB port kell hozza, spec programozo nem.
-
#19
Bada Bing
tag
VaniliásRönk
#17
Bada Bing
tag
válasz
VaniliásRönk
#17
üzenetére
Az FPGA egy teljesen általánosan konfigurálható (programozható) eszköz, nincs benne semmiféle funkció összehányva.
Közelítőleg úgy lehet elképzelni, mintha egy processzor tranzisztorait összekötő minden egyes vezetéken elhelyeznénk egy-egy kapcsolót. Az FPGA "programja" azt tartalmazza, hogy mely kapcsolók vannak bekapcsolva és melyek kikapcsolva.
Vagyis nem a gyártás során dől el, hogy mely logikai elemeket kötünk össze milyen sorrendben, hanem ezt egy számítógép segítségével bármikor módosíthatjuk.
Az FPGA-k épp azért kerülnek most az érdeklődés középpontjába, egyre több feladatot oldunk meg párhuzamos algoritmusokkal és az FPGA-k ebben nagyon hatékonyak.
Az, hogy az FPGA-k hatékonyan programozhatók legyenek egy adott területen, csak megfelelő nyelv és fejlesztőeszközök kérdése. Jelfeldolgozási feladatokra például már régóta alkalmaznak FPGA-kat, és ilyen célokra már vannak hatékony fejlesztőeszközök is, amelyhez jelfeldolgozási szemléletre van szükség, nem pedig hardveresre.
Az OpenCL révén most olyan algoritmusok és feladatok terjedtek el, amelyekben nagyon hatékonyak az FPGA-k, ezért kézenfekvő feladat egy OpenCL -> FPGA fordító megalkotása.
-
#18
JColee
őstag
VaniliásRönk
#17
JColee
őstag
válasz
VaniliásRönk
#17
üzenetére
Ilyen az FPGA. Nézd meg az architecture részt. Olyanból van benne jó sok.
-
#17
VaniliásRönk
nagyúr
Blindmouse
#15
VaniliásRönk
nagyúr
válasz
Blindmouse
#15
üzenetére
Szoval egy FPGA-ban "egyszeruen" ossze vannak hanyva a funkciok, aztan mazsolazd ossze ami kell? Mert szerintem ez igy soha sem lesz hatekonyan programozhato.
-
Ruuwa
tag
Tudom, tudom, az FPGA nem ilyen egyszerű valami, meg lehet nem is értem teljesen, de a kis laikus agyamban már olyan víziók jelentek meg, hogy egy évtized múlva már nem konkrét CPU/GPU/APU-t fog árulni az Intel vagy az AMD, hanem csak sémákat. "Höjj kijött az új Core i 9, le is töltöm gyorsan az FPGA-mra."
-
#15
Blindmouse
senior tag
VaniliásRönk
#11
Blindmouse
senior tag
válasz
VaniliásRönk
#11
üzenetére
Nekem volt, hogy egy 50 Kgates (elég kicsi) FPGA-ra három órát számolt a gépem, mire kiköpte az eredményt.
Igazából nem tudom hogy lehetne a jelenlegi programozókat beidomítani, hogy a hardveren tudjanak dolgozni. Legtöbbjüknek két magra nem megy az optimalizálás, nem tudom mit kezdenének n számú különböző funkciójú, késleletetésű, működésű egyszerre futó elemmel. -
#14
Phvhun
őstag
VaniliásRönk
#11
Phvhun
őstag
válasz
VaniliásRönk
#11
üzenetére
Az FPGA lényege, hogy akármikor újra lehet programozni a kapcsolatokat a chipben.
Tehát ha olyanod van akkor cpu-nak "behuzalozott" fpga-t át tudod állítani gpu-nak.
Ezt egy rendes procin csak emulálással lehet elérni, ami nagyságrendekkel lassabb működést eredményez.Viszont ha veszünk egy konkrét felprogramozott fpga-t, és legyártjuk ugyanazt rendesen, mint a procikat, akkor az lesz a kisebb lapkaméretű, gyorsabb és kisebb fogyasztású.
Tehát az fpga lényege a rugalmassága.
-
JColee
őstag
Senkit nem fog érdekelni, hogy egyikben olyan hülyeségeknek is kell áram, hogy decode dispatch stb., a másiknak meg nem, csak kompletten működik a rendszer, mindent bele kell számolni.
Ebben igazad van,de a cikk így azt sugalja, hogy hip-hop meg lehet valósítani fpga-ra az opencl kódot, de a szintézer kissé tovább fog futni, mint a fordító. Az is kérdéses, hogy mekkora projekt fér bele az fpga-ba?
Minél magasabb szintű leírást adnak a szintézernek annál kevésbé lesz optimális a hardver.
A vérpistike majd nem érti, hogy miért nem fpga van a gépében, ha az 10 wattot fogyaszt a 130 helyett.
Szóval a cikk jobban körüljárhatta volna az egész témakört, leírhatta volna az fpga-k lelki világát.VaniliásRönk Akkor módosítod a programot, aztán vársz jó sokat, mire újra kész a szintézer.
-
LordX
veterán
Ugyanazzal a HDL kóddal igen, de nem grafikuskártyát fognak beleprogramozni, hogy utána azon fusson egy OpenCL program, hanem direkten az OpenCL programot fogják beleprogramozni. És innentől a kérdés az, hogy az én kis 250 soros kódommal mennyi adatot lehet lezúzni 200W-al. Senkit nem fog érdekelni, hogy egyikben olyan hülyeségeknek is kell áram, hogy decode dispatch stb., a másiknak meg nem, csak kompletten működik a rendszer, mindent bele kell számolni.
-
JColee
őstag
Szerintem nem szabadna idekeverni az energiahatékonyságot, mivel az fpga pont hogy többet zabál ugyanazzal a hdl kóddal, mint egy asic.
Nyilván azért fogyaszt kevesebbet, mert az opencl kódot varálzsolják rá az fpga-ra, és nem egy valamilyen processzort írnak hdlben, ami majd futtatja az opencl programot. -
Alchemist
addikt
-
#6
ftc
nagyúr
VaniliásRönk
#3
ftc
nagyúr
válasz
VaniliásRönk
#3
üzenetére
library ieee;
use ieee.std_logic_1164.all;
use ieee.std_logic_unsigned.all;
use ieee.std_logic_arith.all;
entity ALU is
port( A: in std_logic_vector(3 downto 0);
B: in std_logic_vector(3 downto 0);
sel: in std_logic_vector(2 downto 0);
result: out std_logic_vector(3 downto 0);
carry: out std_logic);
end ALU;
architecture behv of ALU is
begin
process(A,B,Sel)
variable tempresult:std_logic_vector (4 downto 0);
begin
case sel is
when "000" => --000 add.
tempresult := ('0' & A)+('0' & B);
when "001" => --001 sub
tempresult := ('0' & A) + (not ('0' & B)) + 1;
when "010" => --010 mul.
tempresult := ('0' & A)*('0' & B);
when "011" => --011 div.
tempresult := ('0' & A)/('0' & B);
when "100" => --100 and
tempresult := ('0' & A) and ('0' & B);
when "101" => --101 or
tempresult := ('0' & A) or ('0' & B);
end case;
result<=tempresult(3 downto 0);
carry<=tempresult(4);
end process;
end behv;ez egy vhdl kód egy ALU-é... jelenleg ezt is programozni kell ezt szeretnék felépíteni egy magasabb szintű program nyelvel...ami az OpenCL lenne... amit látsz ez csak egy kis alap... a legnagyobb gond, hogy 90%-ban elveszel a részletekben egy nagy projektnél
-
#5
korcsi
veterán
VaniliásRönk
#3
korcsi
veterán
válasz
VaniliásRönk
#3
üzenetére
Sosem volt fixen bedrótozva, az összeköttetéseket lehet programozni a logikai blokkok között, ezért nehéz programozni, nekem sem maradt meg belőle sok a főiskola óta
-
lenox
veterán
Idorol idore elokerulnek az fpgak. Amugy mennyi egy ilyen? Amiket en tudok, hogy fpgas megoldasok, azokat kb. 5000 dollar per kartya aron adjak. Ehhez kepest egy 500 dolarros gpu a kulonbozetet 15 ev alatt fogyasztja el, ha a 300 dollar per eves kulonbseget nezzuk, szoval nem eri meg az fpga.
-
#3
VaniliásRönk
nagyúr
VaniliásRönk
nagyúr
Ha jol ertem az FPGA-k eddig teljesen fixen bedrotozott celhardware-ek voltak. Az lenne a meglepo, ha ez nem eredmenyezne nagysagrandekkel jobb energiahatekonysagot, viszont ez rogton megmagyarazza miert nem nagyon hasznaljak ilyen formaban. Ez az uj fejlesztes miben lesz elorelepes a programozhatosagot illetoen? Mire lehet ezt hasznalni olyan orokzold alkalmazasokon kivul, mint a zsdihad szo kiszurese szoveges uzenetekbol?
Ha már C++ fordítót C++-ban írnak, Java fordítót meg Javában..
):
FPGA for the win 
Új hozzászólás Aktív témák
Hirdetés
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- Formula-1
- VR topik
- A Micron újszerű módszerrel javítja QLC-s SSD-jének sebességét
- Apple iPhone 16 Pro - rutinvizsga
- Magga: PLEX: multimédia az egész lakásban
- alza vélemények - tapasztalatok
- Milyen videókártyát?
- Ingatlanos topic!
- Honor Magic6 Pro - kör közepén számok
- További aktív témák...
- Új, verhetetlen alaplap sok extrával!
- ÁRGARANCIA! Épített KomPhone i7 14700KF 32/64GB RAM RTX 5090 32GB GAMER PC termékbeszámítással
- REFURBISHED - HP USB-C Universal Dock G1 docking station (DisplayLink)
- Akciós dokkolók, Lenovo Legion Pro 7 RTX 4080/4090 laptopok, licencek, antivírusok
- Beszámítás! HP Z2 G4 Tower Workstation számítógép garanciával, hibátlan működéssel
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest