Hirdetés
-
Lesz új Sony OLED tévé is idén
ph A Bravia 8 az LG Display által gyártott 4K panelt használja.
-
Launch trailert kapott a Stellar Blade
gp A teljes kiadás hivatalosan a mai naptól elérhető lett PlayStation 5-re.
-
Lenovo Essential Wireless Combo
lo Lehet-e egy billentyűzet karcsú, elegáns és különleges? A Lenovo bebizonyította, hogy igen, de bosszantó is :)
Új hozzászólás Aktív témák
-
Thrawn
félisten
Jó, hát no, nem születhet mindenki programozónak
Gondolom nem egy nagy művészet készíteni egy felugró ablakot, hogy "Hardware not supported". Aki meg ezért puffog az így járt.Fiery: Az oké, hogy lefuttattok egy benchet egyszer CPU-n aztán meg GPU-n és lelkendezek, hogy jujjdejó, gyorsabb az utóbbi, de nekem egy 3. HSA oszlop is kellene ami azt mutatná meg, ezek együtt mire képesek (CPU+GPU). Nem külön-külön, hanem együtt. Ebben látom értelmét a HSA-nak.
Nem a Fury Nano-ra gondolok (nocsak ti sem kaptatok?
![;]](//cdn.rios.hu/dl/s/v1.gif)
), hanem inkább olyasmire, hogy mennyit emelkedne az AMD részvények ára ha kijönne egy HSA-s AIDA64 
Different songs for different moods. łłł DIII Thrawn#2856 łłł Look! More hidden footprints! łłł D4BAD łłł WoT: s_thrawn łłł
-
ukornel
aktív tag
"Konkretan emlitve van benne a 2016-os ev"
Öhöm... a hír szerint: >>A vállalat szerint 2016-ban minden olyan komponens licencelhető lesz, amivel támogatni lehet a HSA-t<< - ennyi, nem több. Csak még az, hogy >>Arról sajnos hivatalosan egyetlen információ sem hangzott el, hogy az AMD-n kívül kik szállítanak először HSA 1.0-val kompatibilis lapkát<<. Ezt és az előzmények általad felállított értelmezését- te úgy fordítod le magadnak, mintha azt állítanák, hogy 2016 a nagy áttörés éve; majd ezt szemforgatva kétségbe vonod? Ennek mi az értelme?Eddig azon sopánkodtál, hogy csak az AMD aktív HSA ügyben. Tessék, most szó van az ARM-ról és az Imaginationról, és pletykálnak a Qualcommról és a MediaTekről. Nü?
"Mikor is indult az egesz HSA? Akkor me'g nem annak hivtak, persze, hanem Fusionnek. [...] Tehat mar 9 rohadt eve nem sikerul a gyakorlatba is atultetni"
Mit tekintesz sikernek? Idén végleges lett a HSA 1.0, széles iparági héttérrel. Megjelentek az első lapkák, amik HSA-képesek. Talán jövőre jön több, más gyártótól is. Ha nem is teljes a siker, de egyáltalán nem kudarc (még).
A 9 év meg erősen relatív. A HSA, de még az előd AMD-s Fusion sem öregebb 4-5 évnél.
Persze, nyilvánvaló, hogy az AMD-nél az alapok tervezése az ATI-biznisz környékén kezdődhetett, de nem árt figyelembe venni, hogy milyen nagyságrendű és horderejű koncepcióról van szó:
1. Le kell fektetni a koncepció alapjait
2. Szerezni hozzá egy csomó partnert, hogy ne egy fecske akarjon nyarat csinálni
3. Kidolgozni a szoftveres részt
4. Megtervezni a támogató hardvert (az alkalmas gyorsítót, illetve a CPU és gyorsító közti megfelelő buszt és az egyéb körítést).
Ezek a lépések önmagukban sem pár hónapos mutatványok, hanem több éves erőfeszítést jelentenek a legoptimistább forgatókönyv szerint is. Pl ott a hardver tervezése, ez az alapkoncepciótól a lapka tömeggyártásáig simán lehet 3-4-5 év is. A többi lépés sem kevésbé húzós, pl a szoftverfejlesztés. Összességében nem tartom aggasztónak, hogy 9 év alatt nem lett egy ötletszerű elképzelésből iparági sztenderd."nem sikerul a gyakorlatba is atultetni az eleve hibas elkepzelest. "
Na, ezt illene bővebben kifejteni, miben hibás eleve az elképzelés.
A gyorsítók megkönnyített munkába fogása a hibás elképzelés? Vagy a nyílt szabványalkotási folyamat? Vagy valami más?"En benne vagyok, csak ha ilyen hosszutavu, retesteszta-szeru folyamat ez, akkor mennyi ertelme van havonta nehany hirt pazarolni a nagy semmire?"
Semmire? A hír tartalma tényleg nem sok, de egyáltalán nem semmi. Semmi akkor lenne, ha csak a korábbi híreket ismételné, de van új fejlemény. Ha nem érdekel, nem olvasod, nem kommentálod.
#22
"Me'g egy pelda arra, hogy a programozok valojaban mit szeretnenek latni, [...] De tudod mit, elmondom, mi lenne a megoldas, mi menthetne meg a HSA-t. Ha hirtelen beallna moge mindenki, beleertve a Apple-t, Google-t, Intelt, Microsoftot, nVIDIA-t [...]"
Ez egy konkrét, helyénvaló hozzászólás, amivel 95%-ban egyetértek.
Egy kis kiegészítés: a vázolt forgatókönyv nem megmentené, hanem egyenesen a trónra röpítené a HSA-t!
Egyetértek azzal, hogy az ehhez szükséges globális támogatottság esélye 0, de ezt nyilván az AMD-nél is tudták előre. Szerintem ők arra számítottak, hogy elég megszerezni 20-30-40% támogatást, hogy szemmel látható alternatíva legyen a koncepció, és akkor hosszabb távon köztudatba kerülhet és polgárjogot nyerhet, míg végül a nagyok is támogatni fogják.
Ennek a menetrendnek nem kifejezetten használt, hogy a Bulldozer architektúra családdal, illetve most már a 28nm-es GCN architektúrával is jelentősen piacot vesztett az egyik fő támogató.#40
"Mert a nyito komment utan nem tuntem el, hanem sot, reszletesen kifejtettem azt, amit a nyito postbol hianyoltal. Remelem, igy mar oke a dolog"
Közben a dógozóban kicsit jobban kellett húznom az igát, elnézést az eltűnésért. Csak most próbálok lépést tartani a hsz-ekkel. A részletes kifejtést köszi, a 22-esre föntebb reagáltam."#43"
"Es felek tole (sot, biztos vagyok benne), hogy a kimaradtak kozul pont az Intel es az nVIDIA sosem fog csatlakozni. Mar csak azert sem, mert azzal az AMD-t borzasztoan megerositenek. Az meg nekik nem erdekuk, me'g akkor sem, ha a megerosodott AMD me'g mindig gyengebb lenne, mint amilyen 2007 kornyeken volt mondjuk. Az Intel es az nVIDIA elobb all ossze, es talalnak ki egy sajat megoldast, mint hogy a HSA szekeret elkezdjek tolni"
Ez nagyon valószínű, de ...
Akkor mi a jó francot csináljon egy kis cég? Semmit??
Különben meg a nagy ARM-os gyártók miatt lehet(ett?) egy kis esélye az AMD-nek arra, hogy vetélytársaira is rákényszerítse hosszabb távon a saját koncepcióját. -
con_di_B
tag
Megkoszonnem ha valaki kijavitana, de szerintem itt eleg sok felreertes van programozoi oldalrol. Amennyire en latom, a HSA meg a kifejezetten GPGPU programozokat sem erinti a gyakorlatban, mert alapvetoen transzparens.
Az elso dolog, amit nem ertek, hogy miert mondja mindenki, hogya HSA a futtathatosagot fogja megoldani. Az OpenCL specifikaciok megfelelo kovetese garantalja a futtathatosagot mar most is. Megfelelo kovetes alatt azt kell erteni, hogy az undefined behaviour-nal az ember feltetelezi a legrosszabbat, illetve nem felejt el lekerdezni lenyegtelennek tuno aprosagokat az aktualis eszkozrol, es az igy kapott informaciokhoz automatikusan adaptalodo programot fejleszt. Az sem art, ha az ember tisztaban van a floating point muveletek hordozhatatlansagaval, ami nem mellesleg nem GPU specifikus problema, ez egyebkent is van.
Lehet, hogy erre nincsen olyan kenyelmes tooling, hogy raereszt az ember egy verifikatort ami megmondja a tutit, de attol meg meg lehet csinalni.
Ha valami ezek utan sem fut, az 99% hogy driver bug, de ezen a HSA sem fog valtoztatni, az IHV driver stack nem tunik el, csak sokkal kisebb lesz. De abban a sokkal kisebben ugyanugy lehetnek bugok.
Mi nem garantalt? Az, hogy az igy keszult kod kihozza a maximumot minden egyes eszkozbol, amire raeresztik, peldaul. Ezt orvosolja a HSA? Egyaltalan nem, a vegen ez is ugyanugy egyedi ISA-ra fordul, kulonbozo hatekonysagu forditokkal (finalizer) stb.
Az igaz, hogy van par speci cucc, ha jol emlekszem, amit a HSA definial pl. utemezessel kapcsolatban, amivel lehetne ugyes optimalizaciokat csinalni, csak akkor meg nem fog futni ugyanaz az OpenCL program nem HSA hardveren.
Amire jo a HSA, az az, hogy az OpenCL az (sajnos) sok minden lett, de sikeres, elterjedt szabvany az nem, illetve nem is ez az egyetlen, es nem is feltetlenul a legjobb modja a GPGPU programozasnak. Viszont ha a hardvergyartoknak minden egyes eddigi, vagy meg ezutan jovo API-ra uj forditoprogramot, runtime-ot kell irnia, az eleg keserves lesz, szoval koltsegcsokkento hatasu volna, ha kivennek a belet a GPGPU mukodesnek, szabvanyositanak, es akkor mar csak egyszer kene megirni a toolokat fole, aztan mindenki programozhatja a HSA hardvereket OpenCL-ben, C++ AMP-ban, CUDA-ban (elvileg meg lehetne irni, nem?), Java-ban, Pythonban, GPU Haskellben, vagy tenyleg, barmiben amiben akarja, es keszult hozza HSA fordito.
De ez a programozonak csak annyiban nem mindegy, hogy talan jobb minosegu lesz a support, de ahogy ezeket ismerem, az elejen kicsit rosszabb lesz, aztan meg nagyon fognak orulni, hogy nem kellett folvenni meg 10 embert a compiler reszlegre az OpenGPU++ x-ik uj API tamogatasara, mert nehany felnotas megcsinalta ingyen az open-source HSA compilert, a tobbi meg mar kesz van.
[ Szerkesztve ]
-
Fiery
veterán
Bar az is remek lenne, ha lehetne aggregalni a CPU es GPU teljesitmenyet, SZVSZ mar az is hatalmas elorelepes lenne, ha a GPU-t konnyen munkara lehetne fogni a HSA-val. Tehat en ugy gondolom, egymas mellett latni is nagyon jo az eredmenyeket. Azon egyebkent gondolkoztunk, hogy ossze is lehetne az eredmenyeket adni, hiszen ugyanazt szamolja mindket oszlop. Csak epp az csalas lenne, hiszen a Turbo Boost es hasonlo megoldasok miatt egy APU sosem lenne kepes az osszteljesitmenyre. Vagy a CPU-t tudod kihajtani, vagy a GPU-t, de a ketto egyutt nem tudna olyan gyors lenni, mint a 2 eredmeny osszege.
Mi nem kifejezetten Nanot kertunk, hanem barmilyen Furyt, de nem kaptunk. Szerencsere mi legalabb nem okkal nem kaptunk, hanem csak nem jutott. De egy olyan draga es nehezen gyarthato kartyanal, mint a Fury szeria, meg is ertem, ha nekunk nem jut. Az, hogy a mediaban nem jutott mindenkinek, az egy mas tortenet, azzal se lenne gond, ha kisorsoltak volna a kartyakat.
-
Fiery
veterán
Az egesz hir azt sugallja, hogy a 2016 lesz az attores eve. Le van irva, hogy 2016-ban mi mindenre lesz lehetoseg, hogy mennyire kozel all a Qualcomm, hogy a MediaTek is jol halad, lent pedig linkelve van a Snapdragon 820 hir, aminek a cimet is eleg elolvasni. Rakd ossze a puzzle darabokat, ha mar Abu nem hajlando leirni, hogy 2016 lesz a HSA eve
En me'g mindig nem latok HSA-rol szolo bejelenteseket, sorry. Belinkelted, de ide is beszurom, ezt a 3 gugli kereso kifejezest es az altaluk adott talalatokat:
hsa site:amd.com = 4330 results
hsa site:qualcomm.com = 4 results
hsa site:mediatek.com = 98 resultsEz iden majus volt. Azota nem tobb, hanem _kevesebb_ talalat van a cegek site-jan, tessek csak beirni a gugliba! De az nem valtozott, hogy tovabbra is csupan az AMD beszel erdemben a HSA-rol, senki mas. Marmint a weben, de azt hittem, az is relevans, ami a weben van, nem csak az, ami elhangzik egy konferencian.
En azt tekintenem sikernek, ha mondjuk ... nem is tudom ... lenne egyetlen nem AMD altal keszitett szoftver, ami valami ertelmeset is csinal a HSA-val
Nem benchmark, nem demo, nem techdemo. Na jo, viccelek. Valojaban a siker az lenne, ha megjelenne me'g 2-3 HSA-compliant SoC, es elkezdenenek szepen csorogni a szoftverek is, amik pozitiv visszhangot valtananak ki. Olyan szoftverek, amik jok is valamire, amiknel azt mondja az ember, hogy emiatt mar erdemes mondjuk egy AMD APU-t vagy egy akarmilyen mas SoC-cal szerelt telefont/tabletet valasztani."Összességében nem tartom aggasztónak, hogy 9 év alatt nem lett egy ötletszerű elképzelésből iparági sztenderd."
Remelem, tisztaban vagy vele, hogy 9 eve me'g iPhone sem volt. 9 ev borzalmasan hosszu ido az IT iparban. A konkurens megoldasoknak, iparagi sztenderdeknek furcsamod nem kell ilyen hosszu ido, hogy kezzelfoghato eredmenyt hozzanak.
"A gyorsítók megkönnyített munkába fogása a hibás elképzelés?"
Az a hibas elkepzeles, hogy konnyen es egyszeruen lehessen programozni, debuggolni, validalni egy heterogen rendszert. Nem mondom, hogy specialis feladatokra nem mukodik a dolog, megfelelo programozoi rutinnal, felkeszultseggel. Vegul is, a Teslakat is van ahol imadjak, elad joparat az nVIDIA, es nem disznek. De az az elkepzeles, hogy majd egyszer teljesen transzparensen fog mukodni minden, mint ahogy most akarmilyen windowsos PC-n tudsz futtatni egy akarmilyen programot, nos, ez szerintem nem fog mukodni. Mint ahogy most sem mukodik, eddig se mukodott. Vannak megoldasok, vannak probalkozasok, de mindegyiknel ott van az X CPU vagy Y GPU mint alapfeltetel kapasbol, speci driver kell hozza, stb.
"Akkor mi a jó francot csináljon egy kis cég? Semmit??"
Mantle-t, peldaul. Arrol anno azt mondtam, hogy nagyon jo dolog, orulok neki. Aztan az AMD elajandekozta es beszuntette a projektet (legalabbis azt, amirol anno azt mondtak, hogy vilagmegvalto).
-
Fiery
veterán
"Az OpenCL specifikaciok megfelelo kovetese garantalja a futtathatosagot mar most is."
Ja, elmeletben. Gyakorlatban viszont az OpenCL compiler vagy mukodik, vagy nem. Egy hibatlan OpenCL kernel vagy lefordul egy adott compilerrel, vagy nem. Vagy jol fog mukodni az eredmeny, vagy nem. Erre _semmi_ ralatasa vagy rahatasa nincs a programozonak. Erre lehetne persze megoldas a HSA, tudom en
"Az sem art, ha az ember tisztaban van a floating point muveletek hordozhatatlansagaval, ami nem mellesleg nem GPU specifikus problema, ez egyebkent is van."
Van, csak qrvara nem mindegy, hogy mennyire tudod megoldani azt sajat hataskorben. Pl. x86 alatt ez "erdekes" modon nem problema. Itt megint bejon az, hogy a heterogen rendszerekkel tobb a gond, mint az öröm
"Ha valami ezek utan sem fut, az 99% hogy driver bug, de ezen a HSA sem fog valtoztatni, az IHV driver stack nem tunik el, csak sokkal kisebb lesz. De abban a sokkal kisebben ugyanugy lehetnek bugok."
Igy van, me'g egy problema, ami alapszinten jelentkezik. Azaz, maga az elkepzeles tul torekeny, tul necces. Elmeletileg mukodik minden, gyakorlatban pedig a compiler/finalizer keszito kezebe adod magad programozokent. Ez nem az a vilag, hogy C++ kodbol csinalsz x86 binarist, es az mindenhol menni fog, ha egyszer jol lefordult a fejlesztoi gepen. Itt ha a fejlesztoi gepen jol is mukodik a cucc, akkor is elhasalhat barmikor egy juzer gepen. Sot, egy driver frissites utan is elhasalhat az elozoleg jol mukodo cucc. Remek, programozoi szemszogbol ez abszolut vonzo elkepzeles
-
Thrawn
félisten
Nincs olyan kód ami egy APU-t egészében dolgoztat meg? CPU-GPU részt egyszerre? Az eredmény nyilván nem lenne olyan magas, mintha csak össze lenne adva a CPU és GPU külön kiszámolt része, de legalább valódi eredmény születne, nem egy elméleti maximum, ami a Turbo sajátossága miatt valójában sosem érhető el.
A Fury jutott-nem jutott mizéria utóhatásainak köszönhetően meg vannak ilyen öngólok: [link] Csodálom, hogy a szerző még ott dolgozik, mert amit művelt nem engedhető meg semmilyen szinten. Egyébként teljesen nyilvánvaló volt, hogy nem jut majd minden teszternek kártya (ami AMD oldalról gáz akárhogy is nézzük), ezért én az egész mizériát úgy ahogy van nem értem.
Different songs for different moods. łłł DIII Thrawn#2856 łłł Look! More hidden footprints! łłł D4BAD łłł WoT: s_thrawn łłł
-
Fiery
veterán
A CPU es GPU egyszerre dolgoztatasa még bonyolultabb, mint ha OpenCL-lel hajtod meg a GPU reszt. Ha ugyanis a CPU-t is OpenCL-lel kezeled, akkor kulon parancssor kell hozza, kulon kotextus, adott esetben kulon kernel, kulon build, es _kulon_ compiler fogja forditani a kerneledet! Tehat eloallhat egy olyan "vicces" helyzet, hogy az OpenCL kernel remekul fut a GPU-n, de az azzal parhuzamosan futo CPU kod viszont hibas eredmenyt ad. Vagy az egyik szalon fut a GPU kod, mikozben a masik szalon vegtelen ciklusba kerul a CPU kernel forditasa. Remek dolgok ezek
Az persze megoldhato, hogy a GPU-n OpenCL kernelt futtatsz, a CPU-n pedig nativ x86 kodot. Csak akkor 2 kodbazis, mindent kulon kell megirni, es persze okostan kell megoldani a multi-threadinget, hiszen az egyik CPU-n futo szalnak vezerelnie kell az OpenCL munkafolyamatot is (queuing). Hidd el, agyrem az egesz, nem tulzok.
A Fury Nano temaban szerintem az lett volna az elfogadhato megoldas, ha idoben szallitja a kartyakat a review site-oknak az AMD, es megmondja nekik, hogy van 1 hetetek ra, aztan villamgyorsan kuldjetek vissza. Majd kikuldik a kovetkezo site-nak, stb. Igy 10 kartyaval, ha idoben indulnak, le lehetett volna fedni 40 site-ot is siman. Nyilvan nem egyszeru logisztika. Alternativ megoldas lett volna, amit emlitettem: be kell ismerni, hogy nincs eleg kartya, valamivel meg kell magyarazni, es ki kell sorsolni a kartyakat a site-ok kozt.
[ Szerkesztve ]
-
con_di_B
tag
Azert a legtobb dolgot abszolut vidaman lehet javitani sajat hataskorben most is, amirol te beszelsz az egy termektamogatasi problema. Lehet arra vagyni, hogy ugy mukodjenek a dolgok, hogy te megirod a tokeletes OpenCL/HSA programodat, leteszteled egyetlen egy kornyezetben, ott jo volt, aztan rairod a dobozra, hogy a te cuccod bizony minden HSA kompatibilis eszkozt tamogat, es ezt el is hiszed.
De a tisztesseges termektamogatashoz azt a mindent azt vagy specifikalod, hogy pontosan mit ertesz alatta, vagy tenyleg kell ra egy metodus, hogy vegigteszteld az osszes gyakori hardver/szoftver kombinacion. Ez meg egy olyan dolog, amire (a szandek szerint) sokkal kevesbe "torekeny" rendszereknel is szukseg van. Peldaul te megcsinalhatsz valamit Androidra johiszemuen, hogy tessek, itt van az APK, leteszteltem egy telefonon is, meg az emulatorral is jo volt, de attol meg az is lehet ugyanugy rosszabb.
Ha pedig megvan a rendszered a tisztesseges, szeleskoru tesztelesre, akkor igenis latod, hogy hol nem futott a cuccod, es ki is lehet deriteni, hogy mi volt a baj. Az esetek tobbsegeben, ha kell is work-around, az sem feltetlenul olyan, hogy amiatt ne futna mashol a programod. Jo esetben meg meg reagalnak is a bug reportodra, ha be tudsz kuldeni valamit.
Az igaz, hogy GPU-nal az a kor, amit "muszaj" tesztelni szelesebb, de ez nem valami gyokeresen uj problema, csak ugyanaz a problema lesz dragabb valamivel. Innentol meg mukodik a gazdasagi racionalitas, es csak ott fogjak hasznalni a technologiat, ahol ezt a plusz koltseget meghaladja ertekben a teljesitmeny-tobblet, amit hoz.
Ez a "leforditom es azt mar az uristen sem fogja elronteni" meg nyilvan csak egy illuzio. A GPU-knal nyilvan nem jelent semmifele kobe vesett garanciat a precompiled modell sem (CUDA), de a CPU-knal is:
1) Ugyanugy van IR, az az x86.
2) Van "JIT"/finalizer, csak hardveresen tortenik.
3) Ami ugyanugy bug-os, csak azt legalabb javitani sem lehet.
4) Te is hasznalsz egy forditot, aminal meg szurkolhatsz, hogy annak a processzornak az errata-janak megfelelo verzioval van mar dolgod.
4) Az instruction scheduling meg annal is kevesbe definialt viselkedesu, mint GPU-kon, vagyis tenyleg csak kiserleti uton lehet instruction level optimization-t csinalni.
5) Cache-coherency az van ugyan a hardverben, de a C++11 eleve bugos memoria konzisztencia modellel jott ki, nehogy garantalhato legyen a tobbszalu hordozhatosag.A floating point-nal pedig oszinten szolva nem tudom, hogy az x86 definial-e szigorubb kovetelmenyeket mint a relevans IEEE szabvanyok, de ha nem, akkor Intel<>Intel nyilvan nem lesz bajod, Intel<>AMD lehet, hogy lesz, nem tudom, INTEL<>ARM meg nagyon nem volna meglepo, ha volna.
Es akkor: miutan leirtam, hogy ugyanolyan rossz, tenyleg ugyanannyira megkeseritik az eletedet ezek a problemak a CPU-kon? Nem, a CPU fejlesztes sokkal megbizhatobb eredmenyt ad valoban. De ez sokkal inkabb a kovetkezmenye annak a gazdasagi logikanak, amit mondtam, a koncentracio elonyeirol, semmint annak, hogy barmifele szerkezeti garancia lenne a "hagyomanyos" oldalon, ami miatt a dolgok mindig jol fognak mukodni.
Szoval osszessegeben tartom, hogy a fo a baj GPU-val az, hogy draga, de ezen a koncentracio azert eleg jol tud majd segiteni. Akar a HSA, akar mas, de leginkabb mas.
Ha peldaul az Intel valamifele AVX verziot futtatna a sajat GPU-in (hasonloan, mint a Xeon Phi/MIC eseteben), es ahhoz irna OpenCL forditot, meg hagyna, hogy barki mas irjon akarmilyen AVX forditot hozza, ismerve az elterjedtseget a Wintel vilagban, az peldaul kapasbol egy eleg megbizhato "de facto" standard tudna lenni. Ha "mindenki" licenszelne is, mint az x86-ot, akkor tenyleg.
De pont ez volt a lenyeg a GPU vilagban, hogy mindenki el akarta kerulni, hogy legyen meg egy Intel, vagy ARM. Meg CISC->RISC baromkodas.
[ Szerkesztve ]
-
Thrawn
félisten
Én még megfejelném azzal, hogy a CPU-nak időnként szüksége legyen olyan adatra, amit a GPU-tól kap meg és vice versa. Lehetőleg minél többször
[ Szerkesztve ]
Different songs for different moods. łłł DIII Thrawn#2856 łłł Look! More hidden footprints! łłł D4BAD łłł WoT: s_thrawn łłł
-
con_di_B
tag
Ha APU-krol van szo, akkor nem kell kulon kontextus, es a buffereket is automatikusan fogja szinkronizalni a ket eszkoz kozott, osszesen csak ket command queue kell a ket device-nak, a tobbi teljesen kenyelmes.
Az mar mas kerdes, hogy a GPU kodod rohejesen lassan fog futni a CPU reszen, meg hogy ugyanezt ha bejatszod mondjuk egy low-power Intel "APU"-n, akkor a CPU miatt le fogja throttlingolni a GPU-t, szoval jah, szivas az lesz.
Diszkretnel nyilvan ugy van, ahogy irtad, de abban a vilagban mar regen szivas, ha meg egyaltalan barmire kell hasznalnod a CPU-t komolyabban.
-
Abu85
HÁZIGAZDA
A GPU-világban nem azért néznek a cégek rossz szemmel "az egységesítsük az utasításkészletet" gondolatra, mert az egy céget kiemelne, hanem azért, mert a GPU-k sokkal durvább szinten skálázódnak, mint egy CPU. Sokkal több olyan belső eltérés lehet, amely kihatással van az egész architektúra működésére. És ha feltételezzük, hogy megegyeznek, hogy legyen egy GPU-AVX, akkor arra épít mindenki mondjuk 3-4 évig. Lefordított programokkal eljön a Kánaán, aztán elérjük a dizájn skálázási maximumát. Ezzel meg kell változtatni a memória- és a szinkronizációs modellt, hogy tovább lehessen skálázni és az új GPU-AVXnext rendszerek már nem futtatják a GPU-AVX-es programokat. Ez így nem megoldás.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
con_di_B
tag
Amerre most haladunk, ugy a GPU-k egyre tobb olyan problemat oldanak meg, ami a CPU-kon mar ugy van, es "szerettek". Kisse kevesbe cinikusan fogalmazva, ahogy bovul a felhasznalasi teruletek szama, egyre tobb olyan kifogas merul fel, mint a QoS megoldhatosaga stb.
Meg nem tudom, hogy abbol lesz-e valami, de idorol idore a cache-coherency is elokerul termeszetesen.
Magukban az utasitaskeszletekben, aritmetikai szinten legalabbis ma sincs sok csoda. Az, hogy most valakinek dedikalt az integer feldolgozoja, vagy reszben az FP-t hasznalja, es akkor azon gyorsabbak lesznek a 24 bites integer muveletek, vagy most van-e half float egyaltalan, ha van, akkor van-e register packing support a 32 bitesnel kisebb tipusokra, meg egyaltalan, packing, vagy explicit kicsomagolo utasitasok vannak, mit szeret az SFU stb-stb. ezek mind absztrahalhato problemak. Amikor nagyobb valtasok vannak, pl. eleve vektoros formaban vannak-e az utasitasok, vagy skalar szalak futnak SIMD tombokon, vagy mi van, az mar egy izgalmasabb kor, de ott meg eleg egyertelmu, hogy az utobbi a nyero megoldas, szoval azt batran atveheti mindenki.
Es ezeknek semmi koze nincs a skalazodashoz. Pl. siman mondhatod azt, hogy minden szal rahivhat egy SFU instruction-re, mintha lenne is olyan vegrehajtoja, aztan meg round robinban lesz kiszolgalva egy kozos poolbol. Ez nem latszik instruction level. Ilyenek CPU-kon is vannak, AVX-et is vidaman lehet implementani 2x4 szelesen.
A vegere maradnak a memoria specifikus dolgok, amiknek igen, van rahatasa a skalazodasra egy bizonyos szinten, de azert osszessegeben jelenleg a cache koherencia hianya vagy meglete, meg, a lokalis memoria implementacioja az izgalmas kerdesek. A cache koherencianal mondhatod azt, hogy legyenek explicit tranzakcios utasitasok, aztan legfeljebb NOP-kent implementaljak azokon a rendszereken, ahol nem kell. A lokalis memorianal meg rohadtul mindegy, hogy programozhato cache pinning volt, vagy dedikalt hardver, azt neked nem kell latni.
Az osszes tobbi dolog, pl. vektorszelessegek stb. a memoria kapcsan azok vagy a) a grafikus felhasznalas oroksegei, ertsd minden float4, ami rohadtul nem igaz GPGPU-ra amugy sem, szoval halal ra vagy b) a sokcsatornas DRAM mukodesi elvebol kovetkezik, azt meg ugyis mindenki ugyanugy fogja megoldani.
Ami meg beuthetne a skalazodasnak, termeszetesen, ha az ilyen dolgok hogy "fetcheltem egyet a memoriabol, hogy jut el hozzam a DRAM-bol az adat" utak kozvetlenul programozhatoak volnanak, de erre nincsen semmi szukseg. Igen, lehet cached, meg non-cached, meg ilyen olyan fetch-eket ISA szinten megkulonboztetni csak van ra jobb megoldas, illetve ezek sok esetben nem jelentenek funkcionalis kulonbseget a programban, szoval a non-cached implementalhato cached utasitassal, ha nincs mas.
Az igaz, hogy ha a 3-4 evvel ezelotti ISA-k valamelyiket szabvanyositottak volna, akkor nem lenne jo vilag, de amint ezt leirtam eszembe jutott, hogy hello, a GCN azert eleg vidaman el van alapvetoen hasonlo ISA-val azota is, az uj feature-oket meg az x86 vilagban is megkapjak a rendszerek, a nemtudomhanyezerfele SSE verzion, meg TSX, meg franctudja min keresztul. Szoval, van az a fejlettsegi szint, ahol teljesen jo ISA-t lehet definialni, aztan, hogy ki hogyan implementalja, az mar mas kerdes.
A HSA ISA is egy lehetseges megoldas erre, csak mivel eleg egyertelmu, h senki nem fogja kidobni a fo design-jait, elso korben csakis szoftveres eloforditas lehetseges. Aztan meg ki tudja. Anno meg Java byte-kodra is volt hardver epitve, az volt a Jazelle, nem? Ez annal azert ertelmesebb dolog.
[ Szerkesztve ]
-
Fiery
veterán
En csak azt mondom, hogy ha a forraskodbol nem binarist keszitesz, ami nativan fut a GPU-n, CPU-n vagy akarmi mason, akkor programozokent kenytelen vagy kitenni magad a driver/compiler gyartok kenye-kedvenek. Kiszolgaltatod magad, hiszen nem fogod tudni garantalni, hogy a forraskodbol elkeszult, es vegul nativan a vason futo binaris mindig konzisztens es a Te ralatasod szerint hibamentes lesz. Az oke, hogy tobb hardver+szoftver kombinacion kell tesztelni, az is igaz, hogy ez pl. Androidnal is igaz (sot, x86 Windowson is, nyilvan), csak epp x86 Windowson ki tudod nagyreszt kuszobolni a driver/compiler hibakat a binaris forditasakor. Mig ha mondjuk OpenCL-nel le is teszteled a kerneled az aktualis osszes vason, az aktualis osszes driverrel (pl. ForceWare, Catalyst), arra nincs semmi garancia, hogy egy jovobeni driver/compiler, egy jovobeni hardveren is ugyanolyan jol fogja kezelni a kernelt. Johet egy pl. ForceWare frissites, amiben kicsit tweakel valamit az OpenCL compileren az nVIDIA, es maris elhasalhat az addig jol mukodo kerneled. Ilyen egesz egyszeruen nem fordul elo, ha nativ kodot hasznalsz. Ha megirsz egy notepad.exe-t, az fog futni jovore a Zenen, es kesz, nincs problema.
"Nem, a CPU fejlesztes sokkal megbizhatobb eredmenyt ad valoban. De ez sokkal inkabb a kovetkezmenye annak a gazdasagi logikanak, amit mondtam, a koncentracio elonyeirol, semmint annak, hogy barmifele szerkezeti garancia lenne a "hagyomanyos" oldalon, ami miatt a dolgok mindig jol fognak mukodni."
Nem, ez annak a kovetkezmenye, hogy nativ kodot forditasz. Nyilvan nem a Javara meg .NET-re gondolok itt, hanem pl. C/C++, Delphi, assembly, stb. De pl. a .NET kapcsan azert nincs annyi baj, mert "erdekes" modon a Microsoft compilere jobb minosegu, mint amit OpenCL vonalon a legtobb gyarto produkalni tud. Persze az sokat segit, ha mondjuk a .NET target platform 2-3 fele lehet csupan
"De pont ez volt a lenyeg a GPU vilagban, hogy mindenki el akarta kerulni, hogy legyen meg egy Intel, vagy ARM. Meg CISC->RISC baromkodas."
Forditsuk inkabb meg a dolgot. Az x86 vilagban, a dinoszaurusz architektura sokat segit abban, hogy mind a mai napig lehessen nativ kodot hasznalni, es csak akkor kelljen Javaval meg .NET-tel foglalkozni, ha az ember akar. Nem vagyok en ellenere a managed code-nak meg a JIT-nek, de ugy az igazi, ha az embernek van valasztasi lehetosege. GPU vonalon viszont nincs, gyakorlatilag keptelenseg nativ kodot hasznalni -- vagy ha megis lehet, akkor ertelmetlen, hiszen annyifele kulon architekturaval kellene foglalkozni, hogy elbukik a gyakorlatban a kezdemenyezes.
Ha lenne a GPU-kra egy egyseges architektura (mint a CPU-knal az x86), es arra lehetne nativ kodot kesziteni, akkor ezerszer konnyebb lenne ez az egesz Fusion/OpenCL/HSA tema is.
-
Abu85
HÁZIGAZDA
A QoS-re is kínál megoldást a HSA, legalábbis már van rá megoldás a Carrizo APU-ban. Persze nem könnyű hardveresen implementálni, de ha megvan, akkor működik.
A GCN nincs igazából el olyan szempontból, ahogy te szeretnéd. A kezdetek óta már három verziója van, és az első verzió óta módosult a memóriamodell. A GCN2 és GCN3 nagyon hasonló, de a jövőre érkező GCN4 megint más lesz. Ráadásul a disassemblerből látható, hogy a következő két GCN biztosan más kódolási sémát használ, mint a mostani három elérhető verzió.
Annyit biztosan tudok, hogy a következő két GCN verzió jobban fog hasonlítani a HSAIL-hez, mint a mostani három GCN. Szerintem az AMD-nél az egy fejlesztési cél, hogy egy HSAIL utasítást lehetőség szerint megfeleltessen egy GCN utasításnak.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
con_di_B
tag
Ha az ember nagyon ragaszkodik hozza, hogy ne forduljon ujra a kodja, akkor erre tudnak lehetoseget biztositani a gyartok, mert a leforditott binary image letoltheto. Arra nincs garancia, hogy a kovetkezo driver verziok megeszik, mint ahogy arra sincs, hogy nem valamifele IR van benne, amit akkor is ujrafordit, ha nem akarod, de szerkezetileg ott van a lehetoseg erre az OpenCL modelljeben.
Amit meg mondtam, azt tartom, hogy mas formaban, de x86-on is leteznek a "JIT" megfeleloi, es elmeletben nagyon hasonlo problemakkal talalkozhatnal.
Pl. a leforditott szazezer eves VC++ 6.0 programod produkalhatna hibakat a Skylake-en. Szinte lehetetlen, de amikor az a fordito kijott, meg nem volt Skylake, nem volt errata hozza, azt nem vettek figyelembe a fordito irasanal, a kodod triggerelhet benne hibakat. Es nem azert szinte lehetetlen, mert az elore forditos modell annyira klassz, pont az, hogy nyilvan eleve tok rosszul optimalizalt lesz a kimenet, mert a forditonak lovese sem volt rola, h min fog futni a vegeredmeny, ez meg azert szamit x86-on is, hanem azert szinte lehetetlen, mert a Skylake is, meg a VC++ 6.0 fordito is normalisan meg vannak csinalva, azert.
Ha az osszes OpenCL driver es fordito ugyanolyan normalisan meg lenne csinalva, akkor semmi bajod nem lenne. De mivel ugyanazt a feladatot kell tobbszor megoldani egy eleve kisebb piacon, nyilvan nem lesznek.
De a vegeben egyetertunk, kell vagy egy egyseges, vagy egy dominans architektura. Komolyan mondom neha irigylem a konzolos fejlesztoket, ott van az egy darab vas, azon kell jol menni, hajra...
[ Szerkesztve ]
-
Fiery
veterán
"Ha az ember nagyon ragaszkodik hozza, hogy ne forduljon ujra a kodja, akkor erre tudnak lehetoseget biztositani a gyartok"
Nem, amit Te mondasz, az nem megoldas. Maximum a 2 lepcsos forditas elso lepcsojet lehet igy meguszni ertelmes keretek kozt, de akkor me'g mindig ott a finalizer. Hiaba rakod be a programodba a HSA kodot OpenCL kernel helyett HSAIL binariskent (ha mar HSA-rol van szo alapvetoen), a finalizer me'g mindig elhasalhat rajta most vagy a jovoben barmikor, egy ujabb vasnal, egy ujabb drivernel. Ez egesz egyszeruen nem mukodik -- hacsak nem vallalja minden gyarto, hogy egy kozponti adatbazisba feltoltott HSAIL kod konyvtarat minden egyes driver frissiteskor vegigtesztel helyessegre es helyes mukodesre is. Ilyet viszont senki sem fog bevallalni, me'g a Microsoft sem (ld me'g: WHQL, ami szinten nem garancia semmire).
"Amit meg mondtam, azt tartom, hogy mas formaban, de x86-on is leteznek a "JIT" megfeleloi, es elmeletben nagyon hasonlo problemakkal talalkozhatnal."
Ez nyilvan igaz, de x86-on _van_ valasztasi lehetoseged. Nem muszaj Javat meg .NET-et hasznalni, ha nem akarsz. Ha azt mondod, a JIT sz*r, hasznalhatsz C++-t vagy assembly vagy akár gepi kodot. A GPU-kon nincs a gyakorlatban erre ertelmes keretek kozt lehetoseged, egyszeruen nem opcio.
"Pl. a leforditott szazezer eves VC++ 6.0 programod produkalhatna hibakat a Skylake-en. Szinte lehetetlen, de amikor az a fordito kijott, meg nem volt Skylake, nem volt errata hozza, azt nem vettek figyelembe a fordito irasanal, a kodod triggerelhet benne hibakat. Es nem azert szinte lehetetlen, mert az elore forditos modell annyira klassz, pont az, hogy nyilvan eleve tok rosszul optimalizalt lesz a kimenet, mert a forditonak lovese sem volt rola, h min fog futni a vegeredmeny, ez meg azert szamit x86-on is, hanem azert szinte lehetetlen, mert a Skylake is, meg a VC++ 6.0 fordito is normalisan meg vannak csinalva, azert."
Nyilvan van erre baromi kicsi esely. De ez az esely kb. 1000x vagy millioszor kisebb, mint az, hogy egy tetszoleges OpenCL kernel, amit ma megirsz, holnap hibasan fog mukodni egy tetszoleges OpenCL-compliant konfiguracion. Ha tudnad, az OpenCL benchmarkok fejlesztese kozben hany OpenCL compiler bugba sikerult belefutnom
Pedig nem hosszu es nem bonyolult kerneleket firkaltam ossze. Volt olyan kernel, ami egyetlen bazihosszu 1 soros ciklusbol allt, es annak az unroll-olasaba halt bele a compiler (AMD is, Intel is, csak masik kernelnel). Es azota is, folyamatosan uldoznek a compiler bugok, most pl. Intel vonalon van egy egyelore nem kijavitott OpenCL compiler bug, ami a Hash benchmarkunkban okoz szamitasi hibat, es igy a benchmark eredmeny torlesre szorul (nem jelenitheto meg). A hiba a Broadwellt (iGPU) erinti, termeszetesen jelentettuk az Intelnek 5 honapja (!), de azota se sikerult javitaniuk. Ugyanaz az OpenCL kernel remekul fut pl. Skylake-en, csak hogy egy, a Broadwelltol nem fenyevekre allo GPU architekturat mondjak.Ja, es az is mokas, amit az OpenCL compiler keszitok tudnak reagalni egy-egy bugra, amit az ember jelent nekik. Pl. kepesek voltak azt mondani, hogy nem kene integert hasznalnom, mert az "nem tipikus GPU-n". Aham, ertem, tehat egy sima 32 bites integertol mar a compiler idegbajt kap, vilagos
Egy masik compiler meg a szinusz fuggvenytol kapott hulyet. Tenyleg ritkasag a szinusz, alig lehet rola hallani valamit a mai vilagban "Ha az osszes OpenCL driver es fordito ugyanolyan normalisan meg lenne csinalva, akkor semmi bajod nem lenne. De mivel ugyanazt a feladatot kell tobbszor megoldani egy eleve kisebb piacon, nyilvan nem lesznek."
Igy van, es ezert is hibas a koncepcio. Amig ez az egesz ilyen ingatag labakon all, addig nem mas, mint egy betas kiserlet. Azzal kiserleteznek a gyartok, hogy vajon hany programozo fog idot es energiat nem sporolni azon, hogy egy ilyen idiota rendszerben is fejlesszen, csak azert, hogy a GPU-val 2-3-5-10x nagyobb teljesitmenyt el tudjon erni. A gyakorlat azt mutatja, hiaba van meg a potencialisan nagysagrendbeli teljesitmeny novekedes lehetosege, a legtobb programozo inkabb biztosra megy, es elkeruli az ilyen mokas dolgokat. Ez is az (egyik) oka annak, hogy az OpenCL elbukott. Es mivel a HSA sem tudja az OpenCL osszes problemajat kikuszobolni, nem veletlenul kerulik mar most is el a programozok.
"De a vegeben egyetertunk, kell vagy egy egyseges, vagy egy dominans architektura."
Igen. Kell egy x86. Vagy ARM. De az legyen stabil, egyseges, kozpontilag kezben tartott, es lehessen nativan kodolni ra. Abba pedig egyszeruen nem fer bele a GPU, es kesz. Meg kell oldani, hogy a CPU at tudja venni a GPU feladatait, a hagyomanyos ISA-val (x86 vagy ARM). Lasd Knights Landing, amirol persze Abu pontosan azt gondolja, amit en a HSA-rol. Jovore talan me'g nem fog kiderulni, hogy melyik a jo megoldas, de 5 eves tavlatban szerintem mar latszodni fog.
[ Szerkesztve ]
-
jedis
senior tag
Jesszus f.om ! Ilyen "maratoni' kommenteket !
Szerintem az sem olvasta végig, akinek válaszba ment ! Ha az autópályán haladván, egyszer csak vészjósló mennydörgést hallasz magad mögött, és hátratekintvén egy nagy feketeség közelít feléd ezerrel, ne hidd azt hogy egy viharfelhő vett üldözőbe !
-
Fiery
veterán
"Ha APU-krol van szo, akkor nem kell kulon kontextus, es a buffereket is automatikusan fogja szinkronizalni a ket eszkoz kozott, osszesen csak ket command queue kell a ket device-nak, a tobbi teljesen kenyelmes."
Hatigen, csak ugye nem minden APU
"Sajnos" rengeteg embernek a gepeben van dGPU is, adott esetben az APU mellett, vagy dGPU-bol tobb is, stb. Ha minden compute-ra alkalmas eroforrast be akarsz fogni, ami elofordulhat mondjuk csak egy Windows PC-ben, akkor sajnos nem lehet annyira leegyszerusiteni az OpenCL-t, ahogy irod az idezett a mondatban. Es ugyanigy, az OpenCL meg a HSA tema is persze rendkivul le tudna egyszerusodni, a hasznalatuk szinten nagyon kenyelmesse tudna valni, ha limitalnank az egeszet egyetlen architekturara, azon belul nehany variaciora. Ha pl. az lenne a feladat, hogy irni kene egy franko ray-trace motort, es csak Kaveri + Godavari + Carrizon kell mennie, de ott baromi gyorsan, akkor nyilvan az egy sokkal kisebb feladat lenne, mint ha csak annyi valtozna a kiirason, hogy az APU mellett be kell fogni egy tetszoleges GCN dGPU-t is a munkaba. -
HalasKYO
aktív tag
Sokat megértettem a jelenlegi piaci helyzetből ezek a kommentek alapján.
Én amit nagyon szeretnék, és nekem jó lenne, az a GPU renderelés.
Régi vesszőparipa.
Raytracing.Úgy volt, hogy jön openCL és mindenen jól fog menni (AMD kártyák erősebbek, olcsóbbak)
viszont a legtöbb gyártó (Vray, Octane, Furyball) csak CUDA-ra mentek rá.Blender próbálkozott OpenCLel de ott is egy bug-ba futottak így tiltásra került.
Az, hogy csak CUDA-ra építenek azt nem tudom, hogy mi.
Ennek nem tudom, hogy mi az oka.
Kicsit zavar, így nem lehet választani pl csak nVidia kártyám lehet, mert ezt támogatják a szoftverek.Abban bíztam, hogy vagy openCL vagy HSA alapon kialakul egy olyan motor amit mindenki támogat, de ahogy itt is olvasom ennél jóval árnyaltabb a helyzet, és inkább örüljek annak ami van.
CUDA ennyire stabil lenne ? Úgy értem, hogy gtx4xx-től felfelé bármin lefut ?
[ Szerkesztve ]
Halas - http://www.flickr.com/photos/halaskyo
-
#73
hugo chávez
aktív tag
Fiery
#64
hugo chávez
aktív tag
"Ha lenne a GPU-kra egy egyseges architektura (mint a CPU-knal az x86), es arra lehetne nativ kodot kesziteni, akkor ezerszer konnyebb lenne ez az egesz Fusion/OpenCL/HSA tema is."
Ha lenne egységes/közös architektúra, "hardveres" ISA, akkor éppenhogy nem is kéne a HSA/HSAIL-szerű közös virtuális (vagyis szoftveres) ISA-kkal szórakozni a legalább ezen a "magasabb" szinten történő egységesítés nevében és a HSA-koncepció is pont amiatt jött létre, mert nincs és nem is várható olyan egységes (és "jövőbiztos") architektúra, amit minden gyártó elfogadna, hajlandó lenne átállni rá, nem?
(#69) Kopi31415:
+1
(#70) Fiery:
Javíts(atok) ki, ha tévednék és azóta már változott a dolog, de úgy tudom, hogy konkrétan a HSA kifejezetten az APU-król szól, arról, hogy az APU-ban lévő bármilyen típusú végrehajtóegységet (jelenleg elsősorban persze az egyre erősebbé váló IGP-t) egyszerre be lehessen fogni egy program végrehajtásához, vagyis adott részfeladathoz az annak legjobban fekvőt és ezért is kell az egységes virtuális memória és címtér, hogy az adatmásolgatás ne legyen gond ezen egységek között. És nem célja (bár elvileg megoldható) a dGPU-k bevonása. Arra ott van az OpenCL, ha valaki CPU/APU+dGPU-n (és ezzel vállalva az adatmásolgatásoknál a PCI-E okozta késleltetést/sávszélességkorlátot, stb.) akarna egyszerre futtatni egy adott progit. Tehát egy hipotetikus HSA bench is csak APU-kon menne, a dGPU-k irrelevánsak a HSA szempontjából.
[ Szerkesztve ]
"sajnos ez a beszélgetés olyan alacsony szintre jutott, hogy a továbbiakban már nem méltó hozzám" - by Pikari
-
lenox
veterán
Nyilvan ahogy mar mas is irta, a piac 0.1%-at ado Kaveri/Godavari/Carizzo miatt nem fog mindenki ezekre fejleszteni. De ha van valamilyen specko piac, ahol piacvezetonek lehet lenni, akkor ott mar ra lehet birni a nepeket, hogy az adott technologiara fejlesszenek. Az amd-nek pl. a konzolpiac ilyen. Ha mas piacot is talalnanak, ahol ok tudnak a legjobbak lenni, akkor lehetne tovabblepni. A szarra szegmentalt mobil piac az tuti nem ilyen.
-
con_di_B
tag
"Nem, amit Te mondasz, az nem megoldas. Maximum a 2 lepcsos forditas elso lepcsojet lehet igy meguszni ertelmes keretek kozt, de akkor me'g mindig ott a finalizer."
clGetProgramInfo, CL_PROGRAM_BINARIES, clCreateProgramWithBinaries
Nem a HSA-IL eloforditasrol beszelek, hanem az OpenCL letoltheto binaris kerneleirol. Nincsen definialva, hogy annak minek kell lennie, ugyhogy sajnos 99%, hogy valami IR-t fog visszakopni, vagy az IR-t is, ez igaz, de alapvetoen az a funkcio lenne arra kitalalva, hogy direktben visszakopje neked a GPU assemblyt, finalizalva, amit akarsz, ugy, hogy ahhoz mar ne nyuljon a fordito ujra.
A JIT-es Skylake-es commentjeim kapcsan mar ertem h mit nem ertesz, mert nem fogalmaztam eleg vilagosan. Nem arrol beszeltem, h milyen plusz komplikaciokat okozhat, ha managed nyelvet hasznalsz, hanem arrol, hogy az x86 az semminek nem a nativ utasitaskeszlete, funkciojat tekintve az egy IR, amit a CPU majd ugyesen okosan lefordit valamire, amit vegre is tud hajtani. (Meg szetszedi, meg dependency analysalja, meg amit akarsz, meg amik egyebkent compile time tobbnyire teljesen jol megoldhato problemak volnanak, ha a fordito tudna, h mire fordit, de mivel nem tudja, ezert marad egy IR (x86).) Ezt "kereszteltem el" JIT-nek, mivel lenyegeben errol is van szo.
Az errata-hoz kotodo kommentjeimre meg annyit tudok felhozni, hogy pl. x86-ot (most epp felejtsuk el, h az nem egy nativ ISA) eppen tudnal kezzel programozni, es mukodne is, de ugyanez a GPU-knal mar tavolrol sem trivialis.
Valoszinuleg egy NVIDIA, AMD GPU-t lehetne viszonylag megbizhatoan programozni assembly-ben, de mobil vonalon amennyire kepben vagyok ott a legtobb architektura annyi "majd szoftverbol megoldjuk" verifikacios hibaval kerul legyartasra, amiket soha nem fogsz megismerni, hogy osszessegeben mindenki jobban jar, ha gyartonak maganak van lehetosege hazon belul kenegetni amit kenegetni kell.
Es akkor ezuton minden tiszteletem a Raspberry Pi - Broadcom VC4 open-source kozossegenek.
[ Szerkesztve ]
-
-
con_di_B
tag
Jo, de az a faktor ugyis kiesik majd, mert ott meg mindent Metal-ban kell majd csinalni.
Nem muszaj lecovekelni az OpenCL-nel, felolem lehet D3D Compute minden Windows-on, meg Metal OS X-en, csak hasznaljuk mar ki ertelmesen a GPU-kat.
Persze szivem szerint dehogynem, covekeljunk csak le az OpenCL-nel, mivel az mar az 1.0-val megoldott olyan dolgokat amiken a grafikus API-knal meg mindig csak sirnak, es amennyire tudom a tobbi cuccban nem is lehet normalisan tetszoleges feledat grafokat rendesen definialni, ami azert nem mindegy amikor egy nagy GPU-t kene szaturalni.
De ahogy mondtad, az, hogy technikailag mi a jobb, az huszadrangu kerdes.
[ Szerkesztve ]
-
Fiery
veterán
GPU-knal sajnos nem megoldas a binarisok hasznalata, hiszen azzal legfeljebb a jelenleg piacon levo GPU architekturakat tudod megcelozni, a jovoben megjelenoket viszont abszolut nem. Raadasul, magadnak kell beassignolni a binarisokat az egyes architekturakhoz, ami eleg bonyolult tud lenni, hiszen nem ad vissza az OpenCL feluleten at olyan infot az OpenCL stack, ami az adott GPU architekturara egyertelmuen tudna utalni. Lehet persze nyakatekert megoldasokat berakni, amivel megis eleg jol beloheto az aktualis GPU architekturaja, de ez az egesz akkor is egy nagy katyvasz, es en szemely szerint nem megoldasnak neveznem, hanem egy borzaszto vekony piaci szegmens (= nagyjabol az MIT laborja es hasonlo akademiai/kutatasi kozpontok) szamara adott esetben jo eszkoznek. Nagyjabol hasonlo, mint amikor egy szoftver OpenCL-lel gyorsitott portjat kizarolag 1 gyarto 2-3 GPU architekturajara keszitenek el kulonfele mondvacsinalt vagy adott esetben legitim indokokkal -- konkret neveket nem emlitenek, de van ilyen szoftver a piacon, es nyilvan a PH is lehozta hirkent anno
Az x86 IR kapcsan valahol, a dolgok legmelyen igazad van, de abban viszont nagyon nincs, ha ezt parhuzamba akarod hozni a GPGPU vilaggal. Ugyanis, az x86 processzorokban ez az "JIT" hardveresen van implementalva, es mint ilyen, nem valtozik. Tehat a "compiler", ami az x86 utasitasokat szetszedi RISC vagy akarmilyen mas kisebb/egyszerubb utasitasokra, nem valtozik, hanem fix, legalabbis egy adott x86 processzor steppingen belul. Es a steppingek kozott is olyan minimalis a valtoztatas, es olyan durvan odafigyel az AMD, Intel es VIA is a validaciora, hogy a gyakorlati eselye annak, hogy a "compiler" valaha is bajt okoz egy x86 kod futtatasakor, lenyegeben a 0-val egyenlo. Ez egy osszehasonlithatatlanul kisebb problema, mint akárcsak egy C++ --> x86 compiler vagy plane mint egy OpenCL compiler. Raadasul, egy OpenCL compiler buggal ellentetben, ha kipattan egy x86 "compiler" bug, azt azonnal felkapja a media, es ha kicsit is komolyabb problema, visszahivasba vagy BIOS patchbe fog fajulni (pl. Pentium FDIV bug).
"Valoszinuleg egy NVIDIA, AMD GPU-t lehetne viszonylag megbizhatoan programozni assembly-ben"
Hogyne lehetne, ezt nem vitatja senki. Csak epp az assembly utasitasok ill. azok hasznalata architekturankent valtozik. Amit nagy nehezen megcsinalnal Keplerre, azt a Maxwell megjelenesekor azonnal portolnod kene az uj architekturara. Ez igy nem megoldas, hacsak nem valaki szuletett mazochista, vagy pont ezert valakinek megeri nagyon sok penzert fenntartani egy programozot
[ Szerkesztve ]
-
Fiery
veterán
-
Fiery
veterán
"Nem muszaj lecovekelni az OpenCL-nel, felolem lehet D3D Compute minden Windows-on, meg Metal OS X-en, csak hasznaljuk mar ki ertelmesen a GPU-kat."
Az nem megoldas, tobb okbol sem. Kezdjuk ott, hogy ha az Apple, Google, Microsoft okoszisztemat nezzuk, boven eleg nyomora van a fejlesztoknek azzal, hogy mindegyikre kulon nyelven es kulon fejleszto kornyezetben kell nyomulni. Apple: Xcode es C++11/Swift, Google: Android Studio es Java/C++, Microsoft: Visual Studio es C#/C++. Tudom en, hogy van ezeknek kozos halmaza, de a tipikus inkabb megis a 3 fele nyelv (Apple: C++, Google: Java, MS: C#). Na ha ebbe me'g belekeversz 3 kulonbozo GPGPU fejleszto platformot+nyelvet is, az vegkepp kiveri a biztositekot a programozok fejeben
De persze me'g ha a nyelv fix is lenne, akkor is ott lenne a JIT problema, stb. stb. stb, megint korbeertunk -
#84
Fiery
veterán
hugo chávez
#73
Fiery
veterán
válasz
hugo chávez
#73
üzenetére
"Ha lenne egységes/közös architektúra, "hardveres" ISA, akkor éppenhogy nem is kéne a HSA/HSAIL-szerű közös virtuális (vagyis szoftveres) ISA-kkal szórakozni a legalább ezen a "magasabb" szinten történő egységesítés nevében és a HSA-koncepció is pont amiatt jött létre, mert nincs és nem is várható olyan egységes (és "jövőbiztos") architektúra, amit minden gyártó elfogadna, hajlandó lenne átállni rá, nem?"
Persze hogy nem kene a HSA, ha nem lenne ennyifele architektura. A HSA egy ernyot kepez az architekturak fole, egy absztrakcios reteget, ilyen szempontbol tenyleg hasonlit a Javara vagy epp a JavaScriptre. De ahhoz, hogy ez mukodjon, hasonloan a JavaScripthez, mindenkinek tamogatnia kellene, es hasonloan a JavaScripthez, baromi jo es stabil compilerek kellenenek hozza. Egyik sem adott, es az alagut vegen nem latszik, hogy mikor jon el ez az ido. Ha pedig a "nagyok", azaz az iparag fejlodeset valoban formalo cegek megmakacsoljak magukat, akkor hasonloan a Flash es az OpenCL halalahoz, a HSA is ki lesz vegezve, me'g mielott a gyakorlatban be tudna mutatni, hogy mire is kepes.
"Javíts(atok) ki, ha tévednék és azóta már változott a dolog, de úgy tudom, hogy konkrétan a HSA kifejezetten az APU-król szól"
Elsosorban az APU-krol szol, de ugyanugy bevonjak a CPU-kat es a dGPU-kat is egy legacy retegen keresztul, mint ahogy az OpenCL is mukodik manapsag.
"Arra ott van az OpenCL"
Ertsuk mar meg vegre, hogy a HSA OpenCL nyelven is meghajthato
A ketto nem 2 kulonallo ag. Az OpenCL viszont nem csak az OpenCL kernelek nyelvet, mukodeset meghatarozo nyelvet foglalja magaban, hanem a frameworkot, azaz az OpenCL kernelek leforditasat es vegrehajtasat menedzselo reteget is. Ez utobbi 2 eleg docogosen mukodo modulon probal a HSA javitani a sajat, fejlettebb megoldasaival. De maga a nyelv, amiben megirod a kernelt, amit aztan a HSA lefordit es vegrehajt a vason, lehet OpenCL is."Tehát egy hipotetikus HSA bench is csak APU-kon menne, a dGPU-k irrelevánsak a HSA szempontjából."
Nagyjabol igen, es ezert sem lenne relevans pl. az AIDA64 mostani OpenCL benchmarkjait atvinni HSA-ra. Egy APU+dGPU kombonal lenyegesen kedvezobb eredmenyt kapnal HSA nelkul, mint HSA-val, hiszen a dGPU-t a HSA-val nem vonnad be a benchmarkba, mig a "hagyomanyos" OpenCL benchmark azt is szepen megdolgoztatja.
Ahol egyebkent a HSA egyertelmuen villantani tudna, es amire lehetne benchmarkot is irni kifejezetten, az valami olyan munkafolyamat lenne, aminel a CPU (azaz az x86 magok) es a GPU egy bonyolult adatstrukturan parhuzamosan (pontosabban felvaltva) dolgozna. Valamint, me'g egy nagysagrendet tudna gyorsitani a HSA, ha raadasul a GPU altal vegzett munkafolyamat relative gyorsan lefutna. Jelenleg, ha pl. OpenCL-lel akarsz olyan szamitast vegezni, ami nagyon hamar lefut a GPU-n, majd utana a CPU-val valamit matatsz az adatokon, es megint jon a GPU, es megint tul hamar vegez a GPU (es igy tovabb), akkor a rengeteg kernel inditas miatt, a gyenge labakon allo, nem optimalis queue modell miatt baromi lassan fog az egesz mukodni. Me'g akkor is lassu lesz, es alig gyorsul egy tisztan x86 kodhoz kepest, ha OpenCL 2.0-val, azaz megosztott memoriaval oldod meg. Az meg aztan plane horror, ha a memoriat is masolgatni kell, es a GPU tul gyorsan letudja a melot. A mostani OpenCL keretek kozt nagyon oda kell figyelni arra, hogy mikor es mennyi memoriat masolgatsz, es gondoskodni kell arrol, hogy a GPU-nak elegendo munkat tudj adni.
[ Szerkesztve ]
-
ukornel
aktív tag
"Az egesz hir azt sugallja, hogy a 2016 lesz az attores eve. Le van irva, hogy 2016-ban mi mindenre lesz lehetoseg, hogy mennyire kozel all a Qualcomm, hogy a MediaTek is jol halad, lent pedig linkelve van a Snapdragon 820 hir, aminek a cimet is eleg elolvasni. Rakd ossze a puzzle darabokat, ha mar Abu nem hajlando leirni, hogy 2016 lesz a HSA eve"
Nem, nekem mást mutat a kirakós. Nem óriások azok, Don Quijote, csak szélmalmok."tovabbra is csupan az AMD beszel erdemben a HSA-rol, senki mas."
Igen, a Qualcomm és a Samsung nem azon a szinten áll, hogy egy kockázatos, még a programozók közül is csak egy szűkebb rétegnek érthető jövőképet kelljen propagálniuk. Az idézett pletykák szerint mégis jövőre HSA1.0-képes lapkára számítani tőlük - ha ez igaznak bizonyul, teljesülhet a
"siker az lenne, ha megjelenne me'g 2-3 HSA-compliant SoC, es elkezdenenek szepen csorogni a szoftverek is"
állításod első fele. Ami még mindig nem áttörés, nem lesz az év a HSA-é, de szemmel látható haladás."Remelem, tisztaban vagy vele, hogy 9 eve me'g iPhone sem volt. 9 ev borzalmasan hosszu ido az IT iparban. A konkurens megoldasoknak, iparagi sztenderdeknek furcsamod nem kell ilyen hosszu ido, hogy kezzelfoghato eredmenyt hozzanak."
iPhone... az egy kiválóan összerakott okostelefon (volt olyan már korábban, hogy ne lett volna), a hozzá igazított zárt op.rendszer, és szoftveres ökoszisztéma kellően minőségi összegyúrása. A siker alkotóelemei majdnem mind léteztek már korábban. Sokkal inkább finomításon, tökéletesítésen volt a hangsúly, ötletes tálaláson, ergonómián. A HSA kidolgozása ezzel szemben nem csiszolgatást jelentett, hanem az alapok kidolgozását, ami a legtöbb részletében teljes újdonság.
Ha megvalósulna az általad (viccből) vizionált teljes összefogás az Inteltől a Samsungig, Apple-től Google-ig, AMD-től az Nvidiáig, a Fraditól az Újpestig , és öntenék a nagyok a pénzt a fejlesztésbe, akkor persze én is kevesellném az 5, vagy 9 év alatt eddig elért eredményeket."Az a hibas elkepzeles, hogy konnyen es egyszeruen lehessen programozni, debuggolni, validalni egy heterogen rendszert. [...]"
Értem. Végre látom, hogy miért fújsz ennyire
Én nem értek hozzá, nem tudom megítélni, de azért egy jópár fejlesztő -úgy tűnik- mégiscsak hisz benne. Nem tudom kinek van/lesz igaza. Talán mindkettő véleménynek, mert meg lehetne csinálni a dolgot, de ha nem, vagy csak fél szívvel támogatják a nagyok, akkor kevés bugos szoftver lesz csak, és elhal végül.
Remélem, nem így lesz."Mantle-t, peldaul. Arrol anno azt mondtam, hogy nagyon jo dolog, orulok neki."
Csókolom, a HSA kb olyan ambíciózus, a lapok az iparágban újraosztani hivatott kezdeményezés, mint a Mantle a grafikában, külső laikus szemmel legalábbis. Egyik jó, a másik nem? -
Fiery
veterán
"iPhone... az egy kiválóan összerakott okostelefon (volt olyan már korábban, hogy ne lett volna), a hozzá igazított zárt op.rendszer, és szoftveres ökoszisztéma kellően minőségi összegyúrása. A siker alkotóelemei majdnem mind léteztek már korábban. Sokkal inkább finomításon, tökéletesítésen volt a hangsúly, ötletes tálaláson, ergonómián. A HSA kidolgozása ezzel szemben nem csiszolgatást jelentett, hanem az alapok kidolgozását, ami a legtöbb részletében teljes újdonság."
Ebben nem ertunk egyet. A HSA alapjat kepezi a Stream, a CUDA, az OpenCL, a D3DCS. Boven lehetett otleteket nyulni a kulonfele JIT megoldasokbol, pl. Java. Semmivel sem nagyobb melo egy HSA-t osszerakni, mint egy iPhone-t. Egyebkent az iPhone-t csupan azert emlitettem, mert az mar rohadt regen volt, talan olyan regen, hogy sokan fel sem tudjak idezni, miert volt akkora szam es hogyan nezett ki a legelso iPhone. Es a Fusion/HSA fejlesztese me'g annal is regebben kezdodott.
"Én nem értek hozzá, nem tudom megítélni, de azért egy jópár fejlesztő -úgy tűnik- mégiscsak hisz benne. Nem tudom kinek van/lesz igaza. Talán mindkettő véleménynek, mert meg lehetne csinálni a dolgot, de ha nem, vagy csak fél szívvel támogatják a nagyok, akkor kevés bugos szoftver lesz csak, és elhal végül.
Remélem, nem így lesz."Mutass nekem 3 olyan konkret programozot, aki lelkesedik a HSA-ert, _es_ aki mar OpenCL-ben vagy CUDA-ban is nyomult elozoleg, tehat kepben van GPGPU vonalon. Aki alig varja, hogy mas procin is fusson, mint az AMD APU-jai. Olyat is mutass, aki mar eloallt HSA koddal, barmilyen celbol. Nyilvan lehetne ilyen embereket talalni, de miutan megvannak ok, nezzuk meg, hanyan tolonganak az Android fejlesztoi szekcioban a StackOverflow-n. Vagy a CUDA forumokban. Vagy barhol, lenyegeben. Minden hulyesegre lehet fanokat talalni, a legnehezebb programozoi feladatokat is megoldjak paran, de az igazi merce valojaban az, hogy mi a mainstream.
"Csókolom, a HSA kb olyan ambíciózus, a lapok az iparágban újraosztani hivatott kezdeményezés, mint a Mantle a grafikában, külső laikus szemmel legalábbis. Egyik jó, a másik nem?"
No offense, de baromi nagy laikusnak kell lenni ahhoz, hogy valaki a HSA es a Mantle koze egyenloseg jelet, vagy ugy altalaban barmilyen relacios jelet rakjon. Kb. annyi kozuk van egymashoz, mint a tengerjaro hajonak a futobiciklihez. De ha mindenaron akarod, felolem hasonlithatjuk oket egymashoz, abszolut nem professzionalis modon. A Mantle ugyanaz pepitaban, mint ami anno a Glide volt, valojaban semmi extra, csak egy jo pillanatban egy felutott magas labda lecsapasa. De mivel en nagy rajongoja vagyok a custom API-knak -- mert valojaban csak azokkal lehet egy adott architekturabol kihozni a maximumot, es biztositani a konzisztens teljesitmenyt --, a Mantle kapasbol megtetszett. A HSA ezzel szemben egy alapjaiban rossz elkepzeles (GPGPU) plusz absztrakcios retegekkel valo megfejelese, annak remenyeben, hogy az alapveto hulyeseget hasznalhato szintre tudja hozni. A low-level custom 3D API alapjaiban jo otlet, mig a HSA alapjaiban hibas elkepzeles. Ez az en velemenyem a temarol
A jatek fejlesztok meg biztos maskepp gondoljak, legalabbis a Mantle kapcsan.[ Szerkesztve ]
-
#87
hugo chávez
aktív tag
Fiery
#84
hugo chávez
aktív tag
"De ahhoz, hogy ez mukodjon, hasonloan a JavaScripthez, mindenkinek tamogatnia kellene, es hasonloan a JavaScripthez, baromi jo es stabil compilerek kellenenek hozza."
Na igen, leginkább a compilerek és a finalizerek "minőségén" hasalhat el az egész koncepció.
"Ha pedig a "nagyok", azaz az iparag fejlodeset valoban formalo cegek megmakacsoljak magukat, akkor hasonloan a Flash es az OpenCL halalahoz, a HSA is ki lesz vegezve, me'g mielott a gyakorlatban be tudna mutatni, hogy mire is kepes."
Erről már beszéltük régebben és alapvetően egyet is értek veled. De mobil vonalon a hardvergyártók és a Google (még, ha jelenleg csak fű alatt is, de) támogatják, tehát ott egyelőre úgy néz ki, hogy menni fog a dolog. PC-n viszont nagyon kéne az Intel hivatalos támogatása is...
"Ertsuk mar meg vegre, hogy a HSA OpenCL nyelven is meghajthato
A ketto nem 2 kulonallo ag. Az OpenCL viszont nem csak az OpenCL kernelek nyelvet, mukodeset meghatarozo nyelvet foglalja magaban, hanem a frameworkot, azaz az OpenCL kernelek leforditasat es vegrehajtasat menedzselo reteget is. Ez utobbi 2 eleg docogosen mukodo modulon probal a HSA javitani a sajat, fejlettebb megoldasaival. De maga a nyelv, amiben megirod a kernelt, amit aztan a HSA lefordit es vegrehajt a vason, lehet OpenCL is."Nyilván, de amikor az OpenCL-t írtam, akkor a komplett keretrendszerre is gondoltam, nem csak a nyelvre.
Jobban belegondolva amúgy tényleg felesleges is egyelőre erőltetni egy HSA-benchet, hiszen gyakorlati jelentősége nem nagyon lenne...
De szerintem, ha van kellő számú olyan típusú feladat, aminek a megoldásához gyógyír lenne a HSA, akkor ez a HSA-t támogató (nem AMD!) hardverek nagyobb számban történő megjelenése (tehát 2016-2017) utáni két-három évben ki fog derülni. Ha még akkor sem lesz jópár darab olyan alkalmazás, ami valóban profitál a HSA-ból, akkor én is "halottnak" (rétegcuccnak) fogom tekinteni."sajnos ez a beszélgetés olyan alacsony szintre jutott, hogy a továbbiakban már nem méltó hozzám" - by Pikari
-
#06658560
törölt tag
"Igen, a Qualcomm és a Samsung nem azon a szinten áll, hogy egy kockázatos, még a programozók közül is csak egy szűkebb rétegnek érthető jövőképet kelljen propagálniuk. Az idézett pletykák szerint mégis jövőre HSA1.0-képes lapkára számítani tőlük - ha ez igaznak bizonyul, teljesülhet a..."
Probléma, hogy mobil SoC esetén a fogyasztás eléggé sarkalatos pont, így minden, ki nem használt tranzisztor helyet, energiát pazarol, ezáltal kevésbé versenyképes. Mobil szintre akkor van racionális indok levinni, amikor már desktop és kompletten x86 szinten befutott.
"Én nem értek hozzá, nem tudom megítélni, de azért egy jópár fejlesztő -úgy tűnik- mégiscsak hisz benne. Nem tudom kinek van/lesz igaza. Talán mindkettő véleménynek, mert meg lehetne csinálni a dolgot, de ha nem, vagy csak fél szívvel támogatják a nagyok, akkor kevés bugos szoftver lesz csak, és elhal végül."
A HSA elméletben egy teljesen jó irány, minden számítást azzal az egységgel elvégeztetni, amelyiknek ideális feladat. Probléma a komplexitással van. Fejlessz egy "fix" hardverre, menni fog. Fejlesz komplett x86 rendszerre, meg fogsz halni a milliónyi variációtól. És attól, hogy bár debugolsz, bármikor beeshet egy vevő, hogy kéri vissza a pénzét, a terméket dobd ki az ablakon, annyira szar- mert pont az általa használt környezetben dob egy hülye, végzetes hibát. Teszem azt, APU+dGPU, s a memóriamásolások során a kódba a különböző sávszélek miatt s más adatot emel be, mint ami kell neki.
-
#06658560
törölt tag
"No offense, de baromi nagy laikusnak kell lenni ahhoz, hogy valaki a HSA es a Mantle koze egyenloseg jelet, vagy ugy altalaban barmilyen relacios jelet rakjon. Kb. annyi kozuk van egymashoz, mint a tengerjaro hajonak a futobiciklihez."
Annyiban össze lehet vetni őket, hogy ugyan azon a ponton hasalnak el- az x86 piac fragmentáltságán. Illetve pontosítok, a Mantle mivel csak AMD-re volt, így ott legalább kézben lehet tartani mi történjen. Ahogy NV oldalon CUDA esetén. De amint a Mantle átvedlik Vulkanná, DX12-vé, jelentkezik a probléma a debugolhatóság, optimalizálás, költségvetés, menetrend bermuda sokszögében.
Mindegyik irány isteni, amíg kis számú hardvervariációra kell megírni. Amint a teljes x86 világra, már jön a fejvakarás, hogy tényleg akarja-e az ember.
-
#90
#06658560
törölt tag
hugo chávez
#87
#06658560
törölt tag
válasz
hugo chávez
#87
üzenetére
A heterogén programozás problémája inkább a heterogén kódot igénylő feladatok létén múlik. Mi az a feladat, ami jobban fut hibrid környezetben, mint vagy csak CPU-n, vagy csak GPU-n futva? És itt a tényleges feladatot értem, nem a kifejezetten ilyenre kitenyésztett, de egyébként semmit nem csináló kódokat. Tehát pl. tömörítésnek jobb a vagy ez, vagy az állapotnál? CAd-nek, FEA-nak, kép-, videoszerkesztésnek? Valamilyen szimulációnak, titkosításnak? Ezen jobban múlik a siker.
-
Fiery
veterán
válasz
#06658560
#90
üzenetére
Ezt nehez ilyen szintre leegyszerusiteni, vagy legalabbis nem celszeru. Nem celszeru csak azt nezni, hogy valami CPU-n es GPU-n is fut. Inkabb nezzuk a regi paradigmat es vessuk ossze az uj paradigmaval. A regi paradigma az, hogy van egy GPU-d, aminek van sajat memoriaja (device memory), ami valamekkora meretu. A GPU elvileg baromi gyors, nagysagrendekkel gyorsabb, mint a CPU, es a teljesitmenyehez igazodik a sajat memoriajanak savszelessege is. Problema azonban a szukos savszelesseg (az adatokat ide-oda kell masolni a GPU device memory-ja es a rendszermemoria kozott, a ketto kozotti PCIe csatorna pedig relative szukos), a device memory meret korlatja (van olyan feladat, amihez keves a 4-6-8 GB-nyi memoria), valamint hogy az egyes, a CPU altal a GPU-nak kiadott parancsok (pontosabban feladatok) nem azonnal hajtodnak vegre, hanem egy parancssorba kerulnek. A parancssor kezelese pedig relative lassu, tehat a GPU vegeredmenyben csak relative rossz kesleltetesu parancs vegrehajtast fog tudni csak vegezni. Tovabbi problema ezzel a megkozelitessel, hogy a CPU es a GPU csak nagyon nehezen tudnak ugyanazokon az adatokon dolgozni, hiszen a CPU csinal valamit a rendszermemoriaban levo adatokkal, azt utana at kell masolni a GPU sajat memoriajaba, aztan a GPU is csinal vele valamit, es utana vissza kell megint masolni a rendszermemoriaba, hogy a CPU hozza tudjon ferni az eredmenyhez.
Az uj paradigma (SVM -- azaz megosztott memoria, OpenCL 2.0, de a HSA is erre epit) ezzel szemben az, hogy a CPU es a GPU is ugyanazt a kozos memoriat hasznalja, azaz a rendszermemoriat. Nem kell masolgatni semmit, es joval szelesebb a memoriakorlat is, hiszen a rendszermemoria egy APU-nal joval nagyobb kapacitasu lehet, mint egy videokartya sajat on-board memoriaja. A CPU es a GPU remekul hozza tud ferni ugyanazokhoz az adatokhoz, azaz egymas eredmenyeihez is konnyen hozzajutnak. A parancsok kiadasa is gyorsabb, bar azon inkabb csak a HSA segit, mintsem az OpenCL 2.0. A hatranya ennek a megkozelitesnek az, hogy egy tipikus APU szamitasi kapacitasa nem tudja elerni azt, amit egy dGPU tud, egyszeruen a TDP korlat miatt. Ha bele lehetne szuszakolni a CPU tokba egy 200-250 Wattos sajat TDP kerettel rendelkezo GPU-t, es alarakni mondjuk 256 GB nagyon gyors rendszermemoriat, akkor a 2 vilagot tokeletesen lehetne egyesiteni -- de ez nem egyhamar fog megtortenni, bar az AMD mar felvazolt egy ilyen APU-t (Greenland kodneven).
Az AMD-vel amikor arrol beszeltunk, hogy milyen feladatokhoz jon nagyon jol az SVM, ok azt mondtak, hogy a komplex adatstrukturaknal rendkivul hasznos tud lenni, ill. ha az adatstrukturaban pointerek vannak (pl. lancolt lista). A pointerekkel a regi paradigma nem tud mit kezdeni, hiszen a GPU nem erti, nem ertheti, hogy a rendszermemoriaban hova mutat egy pointer, hiszen nem ferhet hozza a rendszermemoriahoz eleve. A regi paradigmaban ilyenkor at kell konvertalni a strukturat, le kell cserelni a pointereket indexalasra vagy az egesz strukturat at kell konvertalni a GPU "szaja ize" szerint, majd a vegen vissza kell konvertalni. Az ilyen feladatok, azaz amikor a struktura bonyolultsaga vagy a pointerek miatt eleve elkepzelhetetlen volt a regi paradigma szerint atvinni a szamitasokat a GPU-ra; ill. az olyan esetekben, amikor ezt meg tudtak ugyan oldani, de nagyon nagy overheadet jelentett a strukturak es pointerek konverzioja, na az ilyen esetekben varjak a programozok messiaskent az OpenCL 2.0-t ill. HSA-t. Mas kerdes, hogy az ilyen jellegu feladatok baromira nem a mainstreambe tartoznak. Aki kicsit jobb matekbol, mint en, vagy mar foglalkozott ilyesmivel, az biztos tudna mondani egy konkret feladatot, ami olyan jellegu, mint amit en korulirtam. De biztosan nem az audio/video enkodolas, hash szamitas, adat titkositas kornyeken kell nezelodni, azokhoz ugyanis a regi paradigma is viszonylag jo megoldas. Talan az adattomorites lehet az, aminel nagyon jol jonne az SVM, a Huffman tree-re gondolva, de ez csak egy tipp.
[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
Össze lehet hasonlítani a Mantle-t és a HSA-t hiszen mindkettő az AMD gyermeke, viszont a HSA-ból a piac csak nyerhet, míg a Mantle-ből csak veszíthet.
Rengeteg cégnek van saját technológiája valamire, de ezek közül a Mantle a legveszélyesebb, mert az AMD zsarolásra használja. Az MS és a Khronos is csak úgy vezet be technológiákat, ha a board tagok 100%-ban megszavazták. Az AMD például az ASTC helyett a saját licencköteles formátumát akarja. A többiek vagy fizetnek, mint a katonatiszt, vagy csak a Radeon lesz alkalmas a konzolról átmentett tartalom megjelenítésére.
Lehet, hogy impozáns a Mantle önmagában, de gondolj bele abba, hogy az AMD milyen sötét céllal használja jelenleg, és sajnos amíg csak nekik van ilyen API a kezükben, addig képesek arra, hogy megmondják a tutit.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#06658560
törölt tag
Gondolom az a baj, hogy nem programozó vagyok, így nekem nem az a szempont, nem az a munka, hogy valami kódnak kell futnia. Hanem van valami elvégzendő feladat- statisztikai, mérnöki, digitális, grafikusi, stb. Magyarul édes mindegy, milyen memóriában van tárolva, milyen alegység számolja. A probléma annyi, hogy amit el kell végezni, az mennyire párhuzamosítható, vagy egyes részei mennyire párhuzamosíthatóak. Ha jól, akkor az jó GPU-nak, ha nem, akkor CPU-n marad.
De rendben, gondolkodjunk paradigmákban. Az új paradigma a memória címzést tekinti mindenek felett állónak. És elfelejti azt, hogy hiába fér sok adat bele, azt valaminek fel kell dolgoznia.És itt bukik több ponton is a koncepció.
Vegyünk egy példát, ami jól leírja a helyzetet: FEA. Sok kis elemen végrehajtott, gyakorlatilag ugyanolyan számítás, nagy memóriaigénnyel, egyes, kevésbé párhuzamosítható elemekkel.
Problémái: A memóriaigény szembe megy az APU-k esetében a rendelkezésre álló számolóegységek és a fogyasztási keret korlátozza a teljesítményt. Amennyiben feljebb lépünk, dGPU-t veszünk figyelembe, akkor változik a helyzet, kevésbé köt a fogyasztási keret, viszont nincs egységes memória, s a memóriamásolások fogják vissza a teljesítményt. Ellenben egy APU számítási kapacitásának sokszorosa áll rendelkezésre. Még feljebb lépve pedig bejön a cluster és egyéb csemege, ahol elvileg már van egységes memória is, számítási kapacitás is. A HSA-nak is akkor van értelme, ha mindegyik lehetőséget le tudja fedni. A helyzetet rontja a különböző architektúrák memóriakezelése, kódolási igényei. Minél heterogénebb a rendszer, annál nagyobb lesz a szívás kód oldalon. Márpedig a HSA pont azt adná, hogy bármilyen, azt támogató hardveren jól menjen. Ilyen peremfeltételekkel pedig nagyon nem lehet kódot írni univerzálisan.Másik elméleti probléma: a feladat egyik része jól párhuzamosítható, másik része nem, a kettő párhuzamosan fut valameddig, s az eredményeiket utána felhasználja még. Ilyenkor a jól párhuzamosíthatót sem biztos, hogy megéri túlságosan párhuzamosra tervezni, mert nem fog gyorsabb lenni az összesített feladatvégzés, mint a leglassabb részén keresztül futó számítás. Olyankor annak igényéig érdemes menni a maradék gyorsításában is.
Mint programozó, ha nem írod elő, milyen hardveren fut kizárólagosan a programod, s véges kapacitásod van megírni, akkor szerintem teljesen logikus, hogy bele se vágsz, hanem maradsz a jól bejáratott úton, ami mindenen kiszámíthatóan fut. Pláne, ha kompatibilitási igények is vannak a vevőid részéről.
-
ukornel
aktív tag
"Ebben nem ertunk egyet. A HSA alapjat kepezi a Stream, a CUDA, az OpenCL, a D3DCS. Boven lehetett otleteket nyulni a kulonfele JIT megoldasokbol, pl. Java. Semmivel sem nagyobb melo egy HSA-t osszerakni, mint egy iPhone-t. "
A szoftveres oldalról beszélsz csak, mintha az "ötletnyúlás" azonos lenne azzal, hogy tapasztalt beszállítók hada lesi ugrásra készen, hogy az ő szenzoraik, lapkáik, stb legyenek az új telefon alkotóelemei
Közben megfeledkezel a korábban (#52) írt többi nehézségről (vadonatúj hardverarchitektúrák, közös nevezőre jutás más gyártókkal, stb)."Minden hulyesegre lehet fanokat talalni, a legnehezebb programozoi feladatokat is megoldjak paran, de az igazi merce valojaban az, hogy mi a mainstream."
Most ugye egy kezdeményezésről beszélünk, ami -a remények szerint- egy napon mainstream-mé válhat."No offense, de baromi nagy laikusnak kell lenni ahhoz, hogy valaki a HSA es a Mantle koze egyenloseg jelet, vagy ugy altalaban barmilyen relacios jelet rakjon. Kb. annyi kozuk van egymashoz, mint a tengerjaro hajonak a futobiciklihez."
Nézd meg még egyszer, hogy mik közé "tettem egyenlőségjelet": a két kezdeményezés "ambíciózussága", és hogy arra szánták, hogy az "iparágban újraossza a lapokat". Ezek nem technikai, összehasonlítások hanem inkább a kezdeményezés stratégiájára vonatkoznak. Attól még, hogy nem szégyellem, hogy laikus vagyok, az értő olvasás még az én hozzászólásaimnak is kijárna tőled, nem? -
ukornel
aktív tag
válasz
#06658560
#88
üzenetére
"Probléma, hogy mobil SoC esetén a fogyasztás eléggé sarkalatos pont, így minden, ki nem használt tranzisztor helyet, energiát pazarol, ezáltal kevésbé versenyképes. Mobil szintre akkor van racionális indok levinni, amikor már desktop és kompletten x86 szinten befutott."
Nem látom az összefüggést, tekintve, hogy a desktop & x86 világnak kicsi a metszete a mobilokéval.
Másrészt az ARM említése nem jelent föltétlenül mobil irányt, hiszen az ARM már régóta feni a fogát a szerverpiacra.#90, #93
Ebben a kb két éves hírben a HSA alapítvány elnöke példaként tömörítő algoritmusokat (HEVC), B+ fákon végzett műveleteket, ipari szimulációkat (RTM) hozza példaként a HSA-val gyorsítható feladatokra."Vegyünk egy példát, ami jól leírja a helyzetet: FEA. [...] Problémái: A memóriaigény szembe megy az APU-k esetében a rendelkezésre álló számolóegységek és a fogyasztási keret korlátozza a teljesítményt."
Itt nem világos, mit akartál kifejezni.
Ugyanakkor az APU-k alatt nem biztos, hogy csak 35-65 W, max 95 W-os egységeket kell érteni, főleg, ha szerverfoglalatra gondolunk. -
#06658560
törölt tag
"Nem látom az összefüggést, tekintve, hogy a desktop & x86 világnak kicsi a metszete a mobilokéval.
Másrészt az ARM említése nem jelent föltétlenül mobil irányt, hiszen az ARM már régóta feni a fogát a szerverpiacra"Nem az ARM említése jelenti a mobil irányt, hanem az android, Samsung említése, akik esetében erről szó van, illetve a Mediatek sem nagyon a szerverek irányába törekszik egyelőre. Magyarul mobil szegmens.
"Itt nem világos, mit akartál kifejezni.
Ugyanakkor az APU-k alatt nem biztos, hogy csak 35-65 W, max 95 W-os egységeket kell érteni, főleg, ha szerverfoglalatra gondolunk."Pedig pont kifejtettem: milyen igényre, körülmények közé, környezetre kell kódot fejleszteni, aminek ideálisan kellene kihasználni egyik, másik, harmadik rendszert is.
APU alatt sosem fogsz tudni csúcs CPU+GPU erőt egybe csomagolni és ki is használni, mert a hőtermelés és a szabványos méretek megkötik a kezed. A CPU+multiGPU/Coprocesszor rendszert (Tesla, Phi, stb.) Így a három lépcsőfok, mint hardverstruktúra, amire a programot jól meg kell írni, megmarad. Ha multi APU rendszer lesz, a Cache kezelése akkor is megmarad gubancnak.
[ Szerkesztve ]
-
ukornel
aktív tag
válasz
#06658560
#96
üzenetére
"Nem az ARM említése jelenti a mobil irányt, hanem az android, Samsung említése"
A szóban forgó részben nem volt említve az Android."Pedig pont kifejtettem: milyen igényre, körülmények közé, környezetre kell kódot fejleszteni, aminek ideálisan kellene kihasználni egyik, másik, harmadik rendszert is."
Igen, kifejtetted, de az egyik mondat értelmezése nem megy. Erről van itt szó (#93):
"A memóriaigény szembe megy az APU-k esetében a rendelkezésre álló számolóegységek és a fogyasztási keret korlátozza a teljesítményt."
Biztosan sietve írtad le, ezért hiányos, nem kerek a mondat, nincsenek egyeztetve a mondat részei, és így elakadt a decode egységemben."APU alatt sosem fogsz tudni csúcs CPU+GPU erőt egybe csomagolni és ki is használni, mert a hőtermelés és a szabványos méretek megkötik a kezed."
Persze, hogy nem tudsz, de ahol ez megkötést jelentene, ott már úgyis a foglalatok skálázódása lesz a probléma.[ Szerkesztve ]
-
#06658560
törölt tag
""A memóriaigénnyel szembe megy az APU-k esetében a rendelkezésre álló számolóegységek száma és a fogyasztási keret, ami korlátozza a teljesítményt."
Biztosan sietve írtad le, ezért hiányos, nem kerek a mondat, nincsenek egyeztetve a mondat részei, és így elakadt a decode egységemben."Kieg a javítás, ami kimarad félkövéren szedve.
"Persze, hogy nem tudsz, de ahol ez megkötést jelentene, ott már úgyis a foglalatok skálázódása lesz a probléma."
Nem, már egy i7, vagy dual Xeon+ Quad Fury/Firepro/stb. rendszer is szétrúgja az APU-kat, bármikori generációt nézünk a jelenben, vagy a jövőben.
-
ukornel
aktív tag
válasz
#06658560
#98
üzenetére
OK.
"már egy i7, vagy dual Xeon+ Quad Fury/Firepro/stb. rendszer is szétrúgja az APU-kat, bármikori generációt nézünk a jelenben, vagy a jövőben"
Ez persze csak az elméleti csúcsteljesítményre vonatkozik, mert, ahogy magad írtad korábban, ezeknél "a memóriamásolások fogják vissza a teljesítményt". Ennyi foglalatban (2CPU + 4cGPU) az APUk is komoly összteljesítményt adhatnak le. -
lenox
veterán
válasz
#06658560
#98
üzenetére
Az i7-ek amugy apuk. De egyebkent nem az lenne a feladat, hogy egy apuba egy csucs cpu es gpu parossal megegyezo teljesitmenyt kellene egybe csomagolni, hanem a cpu magok melle egy olyan resource-ot tenni, ami a jol parhuzamosithato feladatokat gyorsabban es/vagy kevesebb energiafelhasznalassal oldja meg. Es mukodik multitasking alatt, virtualizaltan, tobb socketben stb. Nincs meg ilyen, talan majd lesz. A HSA egy probalkozas ebben az iranyba, szerintem bukik amugy, de valahol el kell kezdeni.
#101: Az lenne az ertelme, hogy konnyebb lenne programozni, es gyorsabb lenne, mint egy mezei cpu. Nyilvan nem egy mas altal gyartott erosebb cpu-nal lenne gyorsabb, hanem egy ugyanolyan felepitesu, csak cpu magokat hasznalo cpu-nal, es jelenleg a konnyebb programozni se igaz, nem is hasznalja szinte senki oket apukent.
[ Szerkesztve ]
![;]](http://cdn.rios.hu/dl/s/v1.gif)
), hanem inkább olyasmire, hogy mennyit emelkedne az AMD részvények ára ha kijönne egy HSA-s AIDA64 
Nem benchmark, nem demo, nem techdemo. Na jo, viccelek. Valojaban a siker az lenne, ha megjelenne me'g 2-3 HSA-compliant SoC, es elkezdenenek szepen csorogni a szoftverek is, amik pozitiv visszhangot valtananak ki. Olyan szoftverek, amik jok is valamire, amiknel azt mondja az ember, hogy emiatt mar erdemes mondjuk egy AMD APU-t vagy egy akarmilyen mas SoC-cal szerelt telefont/tabletet valasztani.
Pedig nem hosszu es nem bonyolult kerneleket firkaltam ossze. Volt olyan kernel, ami egyetlen bazihosszu 1 soros ciklusbol allt, es annak az unroll-olasaba halt bele a compiler (AMD is, Intel is, csak masik kernelnel). Es azota is, folyamatosan uldoznek a compiler bugok, most pl. Intel vonalon van egy egyelore nem kijavitott OpenCL compiler bug, ami a Hash benchmarkunkban okoz szamitasi hibat, es igy a benchmark eredmeny torlesre szorul (nem jelenitheto meg). A hiba a Broadwellt (iGPU) erinti, termeszetesen jelentettuk az Intelnek 5 honapja (!), de azota se sikerult javitaniuk. Ugyanaz az OpenCL kernel remekul fut pl. Skylake-en, csak hogy egy, a Broadwelltol nem fenyevekre allo GPU architekturat mondjak.
Majd reggel melóba menet beleolvasgatok, de ilyenkor már nincs lelki energiám ilyesmire 
Új hozzászólás Aktív témák
ph A Linley Processor Conference rendezvényen mindhárom cég részletezte az erre vonatkozó útitervet.
- Beszámítás! Intel Core i5 6500 4 mag 4 szál processzor garanciával hibátlan működéssel
- Beszámítás! Intel Core i3 9100 4 mag 4 szál processzor garanciával hibátlan működéssel
- Beszámítás! Intel Core i3 10105 4 mag 8 szál processzor garanciával hibátlan működéssel
- Beszámítás! Intel Core i7 7700K 4 mag 8 szál processzor garanciával hibátlan működéssel
- Intel I7 13700K 16mag/24szál - Új, Tesztelt - Eladó! 128.000.-