Hirdetés
-
Olcsó 5G-s ajánlatot nyújt a Realme Indiának
ma Megérkezett a Realme C65 5G, az első készülék a MediaTek Dimensity 6300-zal.
-
Rövid előzetesen a S.T.A.L.K.E.R. 2: Heart of Chornobyl
gp Továbbra is szeptemberi premierrel számolnak a fejlesztők, reméljük több halasztásra már nem kell számítanunk.
-
Robotkart irányított a majom a kínai Neuralink agyi chipjével
it A mindezt lehetővé tévő Neucybert a Neuralink kínai riválisa, a Beijing Xinzhida Neurotechnology fejlesztette ki.
Új hozzászólás Aktív témák
-
ukornel
aktív tag
Örülök a hírnek, ugyanakkor semmi olyan sincs benne, miszerint jövőre a "HSA éve lenne".
A HSA végül vagy beérik, vagy nem. Ha beérik, akkor sem lesz egy gyors, robbanásszerű folyamat - ez törvényszerű.
Ez azt jelenti, hogy addig kötélidegeket kell növeszteni annak, aki el akarja viselni a folytonos károgásodat a HSA-val kapcsolatban?
-
Abu85
HÁZIGAZDA
Kevered a Fusiont a HSA-val. A kettőnek nincs köze egymáshoz. A Fusion alapvetően az integrációról szól, vagyis arról, hogy a központi processzor legyen tele gyorsítókkal, amelyek használhatók a különböző feladatokra. Ez megvalósult 2011-ben. Azóta az integráció folyamatos fejlődik.
A HSA egy teljesen más problémára akar megoldást kínálni. A hardveres integráció csak egy alap, amit lehet bizonyos nyelvekkel programozni. Például OpenCL. De sajnos a jelenlegi specifikációkban nincs garantálva, hogy egy OpenCL alkalmazás futni fog minden OpenCL-t támogató hardveren. Lásd például a Strongene HEVC dekódere, és még sok más. Lényegében minden hardverre specifikus optimalizálás kell, hogy fusson, ami nem jó. A HSA ezt a problémát kezeli egy olyan felülettel, ami garantálja a futtathatóságot.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Reggie0
félisten
-
sayinpety
tag
Fut barmin. HSA runtime szukseges, am BRIG allomany fut runtime nelkul. Finalizer szukseges, telepul a driverrel.
Runtime telepitesevel HSA-compliant hardware sem kell programfuttatashoz. Nem szeretnek egyszeru peldat hozni, am szerintem a Javat ismeret. Ugy kepzeld el a HSAt. -
lee56
őstag
Amúgy viccen kívül, ez tényleg így van, nem közeltávú cél az amit megcéloztak anno, nemhiába a jövőbe helyezték el ezt az egészet. Új hardverek kellettek, amikehez idő és $ kell kifejleszteni, aztán meg mégtöbb idő mire elterjednek. Szóval kicsit több türelem kell(ene) mindenki részéről. Na persze az is igaz hogy ez a rengeteg HSA-s cikk és Abu aki többnyire írja őket, néha mintha rózsaszín szemüvegen keresztül szemléltetné a helyzetet, ebben is van valami.
Annyira eszementek azért nem dolgoznak ott, vagyis AMD-nél is tudják / tudták, hogy egyedül nem fogják megváltani a világot ezzel (még ha az akkori piaci helyzetüket is vesszük alapul) cirka 9 éve ahogy írtad, és mire a hardverek olyan mértékben fejlődnek, hogy értelmes dolgokra is lehessen használni a CPU mellé integrált temérdek (és azóta is növekvő) grafikus számítási teljesítményt - ahol kb most tartunk - az általad is említett helyzet alakul ki. Azzal a ~ 1% piaccal akikről beszéltél, akik hasznot húzhatnának ebből jelenleg (HSA 1.0). Tehát a lényeg hogy kb. itt kezdődik majd az a jövőkép amit akkor kigondoltak, és amiben azóta egyébként a zintel is láthatóan támogatja őket (na már nem $$$ pénzügyileg, csak filozófiában), legalábbis, ha nekik más elképzelésük lenne a további fejlődésre, nem pakolnának egyre több és jobb IGP-t a processzorjaik mellé, nem?!
AMD-ék inkább ott szúrták el szvsz, hogy megint a jövőböl közelítettek meg a dolgot (ehhez tényleg nagyon értenek meg kell hagyni..). Baromi erős IGP-t raktak, már akkor, az első APU-ikba is (ugye az amúgy sem túl acélos X86 rész erős kárára), amikor még semmi kézzelfogható haszna sem volt, megjelenítésen kívül legalábbis. Intel közben meg csak finoman fejlesztett először X86-ra koncentrálva, aztán most amikor az már elég jó, jöhet a masszív IGP-re gyúrás.
Tehát az a vicces helyzet alakulhat ki, hogy amikor majd 1-2 generációval beljebb leszünk, majd az intelnek lesz több (nem biztos hogy jobb, de mindenképpen több) eladott (elméletileg) HSA-képes APU-ja, de addigra talán beindul és láthatunk is valamit az említett utópisztikus jövőkép áldásos hatásaiból is, és talán nem csak benchmarkokban.
No Comment
-
Thrawn
félisten
Szívesen nézegetnék olyan HSA benchmarkokat, ahol egymás mellett lehetne látni és elemezgetni a "with HSA" és "without HSA" eredményeket. Gondolom más is van így ezzel. Ennyire nem vonzó a "World's first ever implemented HSA benchmark" titulus?
Eddig arról írtál, hogy senki nem akarja elkezdeni, de úgy látom te/ti sem akarjátok elkezdeni. A szekértolás pedig kétoldalú lenne ugyebár 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. -
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 łłł
-
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.
-
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 ]
-
#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
-
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 ]
-
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? -
#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
"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.
-
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?
Ú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.
- Futás, futópályák
- Azonnali informatikai kérdések órája
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Windows 11
- Politika
- GoPro Topic
- A Watch7-tel debütálhat a Samsung vércukormérője
- Yettel topik
- NVIDIA GeForce RTX 4080 /4080S / 4090 (AD103 / 102)
- További aktív témák...
- Intel I7 13700K 16mag/24szál - Új, Tesztelt - Eladó! 128.000.-
- Beszámítás! Intel Core i9-11900 Processzor - Garancia & Számla - Utolsó Darabok
- Beszámítás! Intel Core i7 7700K 4 mag 8 szál processzor garanciával hibátlan működéssel
- i5-9600K , és i5-9400F processzor eladó!
- AMD Ryzen 3600 (pár napig használt, szinte új)