Új hozzászólás Aktív témák
-
ukornel
aktív tag
válasz
#06658560
#114
üzenetére
"Nincs nagy memóriaigény: Titan X és rokonlelkek."
Dehogy nincs, példát is hoztam (ipari szimulációk).
Nem véletlenül igyekeznek a compute kártyákra lehetőség szerint több memóriát pakolni (bár ez GRRD5-tel nem olyan egyszerű), pl az nVidia a K80-ra 24GB-ot zsúfolt!"Adatmozgás: így ha nem nonstop kell adatot mozgatni, hanem kevesebb alkalommal, sokkal kisebb a veszteség annak mozgatásával, mint amennyit nyerni lehet a lényegesen gyorsabb számítással."
Amit írsz, az tökéletesen igaz. Csak az a "ha" ne volna ott..."Melyik APU tud egy Titan X, Fury X számítási teljesítmény felét?"
Most megpróbálsz úgy csinálni, mint aki nem tud olvasni? Itt ugye az APU-król, mint potenciálról, elvi lehetőségről beszélgetünk, már a #105-ösben leszögeztem, hogy ne ragadjunk le az AMD jelenlegi APU-inál. Az idézett rész (#110) utáni zárójeles részben pedig ott van pontosan, hogy mire gondoltam: hasonló lapkaméretű (azonos architektúra+gyártástechnológia) APUra!
Ha csinálnának egy böszme nagy 600mm2-es APUt, arra jó eséllyel már 28 nm-en is ráférne mondjuk 8 CPU mag és 1500-2000 számoló."Az, hogy te szűk rétegnek látod, még messze nem az, lényegesen vastagabb, mint egy APU-val bohóckodni jelenleg, bármelyiket is nézve a sok közül."
Azt írod, "jelenleg". De itt alapvetően nem a pillanatnyi, már megvalósult fejlesztésekről beszélünk, hanem arról, van-e értelme a HSA-nak, vagy úgy általánosabban a heterogén programozásnak. A cikk címében: "[...] a HSA-s jövőkép [...]".
Másrészt különösebb érvek nélkül hagytad a példáimat, ez nem igazán vitte előre a beszélgetés fonalát."Nem csúsztatás, szerinted az LGA2011 foglalatos intel CPU-k mik? APU-k, vagy kulcstartók?"
Onnan indult a történet, hogy azt írtam, potenciálisan egy i7+R9-380 erejét lehet az APU-koncepció mögé képzelni; ezzel ugyanazt akartam érzékeltetni, amiről az előző bekezdésben írtam. Erre te megkérdezted, hogy melyik 2011 foglalatos i7 APU
Semmi értelme ennek a kérdésnek, az i7 =/= LGA2011; szerintem csak szándékosan félreviszed a mondandómat. 
"Hülyeséget bes´zelsz itt össze vissza"
"[...] hülyeségként szökkent a fejedbe [...]"
"[...] APU-val bohóckodni [...]"
Ha kezdődnek az igénytelen sértegetések, vége az eszmecserének. Én mostantól ehhez tartom magam. -
lenox
veterán
válasz
#06658560
#113
üzenetére
En biztos nem beszelek PCIE-n keresztul bekotott tobb apurol. Elso korben egy apurol, masodik korben tobb utas rendszerrol, de te egy mai tobbutas rendszernel hallottal olyat, hogy PCIE-n keresztul masolsz adatot? Nyilvan nem, a tobbutas apunal sem akarna senki ilyet csinalni. Ugyanugy kell megoldani, mint a mostani tobbutasoknal.
Ezt az apu erosebb, mint 2 xeon + 4 dvga dolgot el kene felejteni. Arra kene koncentralni, ami a valosag, hogy a sima cpu-t kiokositjuk parhuzamos feldolgozasra optimalis magokkal, es akkor jol parhuzamosithato feladatoknal tud gyorsabb lenni.
-
#06658560
törölt tag
"Ahha. Tehát oda lyukadunk ki, hogy a dGPU-s compute-nak mindig lesz létjogosultsága APU-k mellett is abban a szűk szegmensben, ahol nincs nagy memóriaigény, nincs intenzív adatmozgatás a kártya és a CPU/rendszermemória között, és a teljesítményigény a legerősebb APU teljesítménye és annak max. kétszerese között van."
Hülyeséget bes´zelsz itt össze vissza. Nincs nagy memóriaigény: Titan X és rokonlelkek. Adatmozgás: így ha nem nonstop kell adatot mozgatni, hanem kevesebb alkalommal, sokkal kisebb a veszteség annak mozgatásával, mint amennyit nyerni lehet a lényegesen gyorsabb számítással. Az aláhúzott gondolat milyen hülyeségként szökkent a fejedbe? Melyik APU tud egy Titan X, Fury X számítási teljesítmény felét? És ezekből négy számítási teljesítménye felét?
"Ez elég szűk rétegnek tűnik - az a kérdés, hogy pont egy szűk réteg részére fejlesztenek-e majd az elefánt méretű GPU-kat?"
Az, hogy te szűk rétegnek látod, még messze nem az, lényegesen vastagabb, mint egy APU-val bohóckodni jelenleg, bármelyiket is nézve a sok közül.
"Ha megnézed, onnan indult a történet, hogy egy szál APUt hasonlítottál össze egy komplett kétfoglalatos, quadGPUs rendszerrel. Ez így nem túl fair összevetés, viszont egyes genyó feladatokban, ahol a bika rendszered adatmásolgatásokkal tölti az idejét, az egy szál APUt még mindig nem tudja "agyonverni"!"
Nem, onnan indult a történet, hogy pár embernek fixa ideája, hogy az APU-k valamikor majd teljesítményben felveszik a versenyt a CPU+dGPU rendszerekkel, s a memóriakezelés miatt agyon fogják verni. Viszont APU terén a lehetőségek jelenleg ott állnak, hogy maximum kétutas intel megoldás, míg a CPU+dGPU esetén kétutas intel+akár négy, vagy több coprocesszor. Amit soha a büdös életben nem lehet majd utol érni, csak ha mindegyik coprocesszor helyére is APU kerül, aminek a memóriakezelése lesz majd probléma. A fizikai korlátokat nem szabad figyelmen kívül hagyni.
"Hogy jön ide az LGA2011?? Eddig szó sem volt foglalatról, ne kezdjünk már el csúsztatgatni."
Nem csúsztatás, szerinted az LGA2011 foglalatos intel CPU-k mik? APU-k, vagy kulcstartók?
-
-
lenox
veterán
válasz
#06658560
#111
üzenetére
Szerintem ez ott hal meg, hogy több lesz a memóriakérés a másik egységbe, a PCI-e busz terhelése nő, amit csak ront, hogy időzíteni is kell okosan, mi mikor melyik memóriához nyúljon.
Apurol beszelunk, nincs masik memoria, csak egy. Sima cpunal is kell idoziteni a magok kozott, hasonload kellene megoldani ezt is.
-
#06658560
törölt tag
"Vagy ugy ertetted, hogy csak a 2011-es i7-ek rugjak szet az apukat, egy 4770 (+dgpu) nem?"
Isten igazából nekem az i7 az bizony az LGA 2011, a többit valahogy mindig kihagyom onnan. Tehát pont annyira az én hibám, ahogy a tied, másik felét vettük a néven belül a csoportnak.
"Melyik levezetesre gondolsz?"
Arra, amelyikben leírtam, milyen felépítés mellett mi a probléma, s miért nehéz rá fejleszteni.
"Pl. nekem egy cuda-szeru api megfelelne, annyi plusszal, hogy nem lenne kulon device es host memory, csak memory es emiatt nem is kene mindig kuldozgetni a buszon az adatot."
Szerintem ez ott hal meg, hogy több lesz a memóriakérés a másik egységbe, a PCI-e busz terhelése nő, amit csak ront, hogy időzíteni is kell okosan, mi mikor melyik memóriához nyúljon. Eltérő memóriák, sebességek, sávszélességek, s nem tudod adott adat épp melyikben van. Szerintem ez végképp nem adna sebességbeli előnyt semmit, csak hátráltatna. Akkor lenne működőképes, ha a VGA-k saját memóriáját teljesen megszüntetnénk.
-
ukornel
aktív tag
válasz
#06658560
#108
üzenetére
"Esetleg azért, mert kevés a számítási kapacitás?"
Ahha. Tehát oda lyukadunk ki, hogy a dGPU-s compute-nak mindig lesz létjogosultsága APU-k mellett is abban a szűk szegmensben, ahol nincs nagy memóriaigény, nincs intenzív adatmozgatás a kártya és a CPU/rendszermemória között, és a teljesítményigény a legerősebb APU teljesítménye és annak max. kétszerese között van. (Mert ugye ez alatt ott lenne az APU, fölötte meg úgyis klaszter kell, mert egy dGPU-nak nem lesz több, mint kétszer nagyobb számítási kapacitása, mint egy APU-nak - hasonló lapkaméret, architektúra, gyártástechnológia esetén). Ez elég szűk rétegnek tűnik - az a kérdés, hogy pont egy szűk réteg részére fejlesztenek-e majd az elefánt méretű GPU-kat?
Ha tehát "kevés a számítási kapacitás", magad írtad, hogy "[...] akkor jön a HPC, render farm, stb. megoldások clusterekkel, minden egyéb mókával.""Honnan tudod, hogy nem kell? Játékprogramot akarunk HSA-val írni, Hello World szinten, vagy valami értelmeset is?"
Lásd a föntieket."Melyik LGA 2011 foglalatos i7 APU?"
Hogy jön ide az LGA2011?? Eddig szó sem volt foglalatról, ne kezdjünk már el csúsztatgatni.
Xeon szerverprocik között ott vannak az Iris Próval kitömött E3-12xxL v4 procik 1150-ös foglalatba."Akkor nem fogalmaztál elég egyértelműen. Másik probléma, amint több APU-t raksz össze, máris kezd jönni a memóriamásolási probléma- minimum a Cachek szintjén, ami már négy egység esetén is jó kalamalkát okozhat a kód oldalán. Az erőforrás-menedzsment szempontjából meg pláne."
Igazad van, nem fogalmaztam egyértelműen.
Ha megnézed, onnan indult a történet, hogy egy szál APUt hasonlítottál össze egy komplett kétfoglalatos, quadGPUs rendszerrel. Ez így nem túl fair összevetés, viszont egyes genyó feladatokban, ahol a bika rendszered adatmásolgatásokkal tölti az idejét, az egy szál APUt még mindig nem tudja "agyonverni"!
Az az érzésem, hogy az említett ipari szimulációk jelentős része (szó volt arról korábban, hogy az RTM algoritmusokat a fentiek miatt nem gyorsítják GPUval) pont ilyen genyó feladat -erősítsen vagy cáfoljon valaki, akinek van több tapasztalata- márpedig ezekben óriási pénz van. -
lenox
veterán
válasz
#06658560
#103
üzenetére
Nyilvan a 1155/1150-es i7-ek az apuk, ezekbol hangyafasznyival tobb van, mint 2011-esbol. Vagy ugy ertetted, hogy csak a 2011-es i7-ek rugjak szet az apukat, egy 4770 (+dgpu) nem?
Melyik levezetesre gondolsz? Lehet amugy, hogy tok masra gondolunk, en pl. arra gondolok, hogy cpu+dgpu-hoz kepest lehetne konnyebb programozni. Pl. nekem egy cuda-szeru api megfelelne, annyi plusszal, hogy nem lenne kulon device es host memory, csak memory es emiatt nem is kene mindig kuldozgetni a buszon az adatot. Ezt nem lenne tul nehez megcsinalni es maris konnyebb lenne programozni, szoval ez kb. bizonyitja hogy lehetseges olyan scenario, amiben konnyebb apuval programozni mint cpu+dgpu-val.
-
#06658560
törölt tag
"Miért raknánk mellé bármit az adatpárhuzamos appokhoz, ha már ott van a gyorsító (IGP) a lapkán??? Hogy újra szívhassunk az adatmásolgatásokkal? "
Esetleg azért, mert kevés a számítási kapacitás?
"Az a baj, hogy a fejekben mintha ez lenne: APU = AMD proci, gyengécske Bulldozer architektúrájú magokkal.
Felejtsd el ezt a képet! Valójában az i7 is az, csak az Intel nem használja ezt a terminológiát. Képzelj el egy i7-et és egy R9 380-nal egy lapkán - nem mondanám gyengécskének. Ez 14 nanón lehetséges."Melyik LGA 2011 foglalatos i7 APU?
Az APU egyik fontos eleme lenne a megosztott memória, ami tudtommal intel esetén még lényegesen visszafogottabb mértékben létezik, mint az AMD oldalán, így APU technológiát értelmezve az AMD a cutting edge."Persze, hogy nem fog. Az esetek többségében nem is kell"
Honnan tudod, hogy nem kell? Játékprogramot akarunk HSA-val írni, Hello World szinten, vagy valami értelmeset is?
" Ezek helyébe képzelek hat APU-t, mindegyiket a saját hűtésével, és ezek is kommunikálnak egymással."
Akkor nem fogalmaztál elég egyértelműen. Másik probléma, amint több APU-t raksz össze, máris kezd jönni a memóriamásolási probléma- minimum a Cachek szintjén, ami már négy egység esetén is jó kalamalkát okozhat a kód oldalán. Az erőforrás-menedzsment szempontjából meg pláne.
-
ukornel
aktív tag
"Mi baj az adatmásolással? Szükséges rossz, de ha a számítás pár százalékát veszi csak el időben?"
"Ha"? A feladatok egy részénél lehet, hogy csak ennyit vesz el, de mi van a memóriaigényes, vagy az olyan feladatokkal, ahol sűrűn váltják egymást a jól párhuzamosítható, és a késleltetésre érzékeny részfeladatok? Lásd a #95-ösbeli példákat. Ott az idő nagy része másolgatással telik"Apu-n meg ott van a ddr3-4, ami baromi lassú egy dgpuhoz képest"
Nagy erőkkel dolgoznak az ügyön (HBM, HMC, Wide I/O)."sztem sokkal nagyobb overhead mint a feladatok átküldése a kártyára, meg a végeredmény visszamásolása."
Azért a PCIe busz sebességét, látenciáját ne próbáljuk már a 2-4 csatornás rendszermemóriájáéval összehasonlítani
"Az apu-k sikerességéhez két dolog kéne: hbm2 integrálva alaplapra, baromi sok, legalább 12-16 GB, és sokkal nagyobb igp rész, hogy már egy középkategóriás kártyát megüssön"
Baromi sok alatt én nem 12-16 GB-ot értenék, ha compute.ról van szó, hanem ennél sokkal többet.
A HBM2-nek pedig nem alaplapra, hanem interposer-re integrálva lenne értelme, mint a Fury-n, a sávszélesség és a fogyasztás miatt."és sokkal nagyobb igp rész, hogy már egy középkategóriás kártyát megüssön"
Igen, és biztos vagyok benne, hogy lesz ilyen; lásd #105. -
Jack@l
veterán
Mi baj az adatmásoplással? Szükséges rossz, de ha a számítás pár százalékát veszi csak el időben?
Apu-n meg ott van a ddr3-4, ami baromi lassú egy dgpuhoz képest, az sztem sokkal nagyobb overhead mint a feladatok átküldése a kártyára, meg a végeredmény visszamásolása.
Főleg hogy többször annyi mag van egy dgpu-n is, mint az apu-n. (több kártyás rendszereket már meg se említem, most is egy alap gépbe be lehet pakolni legalább 4 kártyát, a profibbakba meg többször ennyit)
Az apu-k sikerességéhez két dolog kéne: hbm2 integrálva alaplapra, baromi sok, legalább 12-16 GB, és sokkal nagyobb igp rész, hogy már egy középkategóriás kártyát megüssön. Akkor, de csak akkor érné meg használni játékra meg compute-ra is. (amíg ez nem teljesül, addig gyerekjáték az egész, egy műanyag gagyi kínai fajta PC-ben) -
ukornel
aktív tag
"De akkor mi értelme az apunak, ha úgyis raksz mellé erős kártyát adatpárhuzamos appokhoz?"
Miért raknánk mellé bármit az adatpárhuzamos appokhoz, ha már ott van a gyorsító (IGP) a lapkán??? Hogy újra szívhassunk az adatmásolgatásokkal?"Még mindig a felhasználói programok pár százalékáról beszélünk amúgy, a többi progi mind cpu-n fut csak. Ott meg megint elvérzik a gyengécske apu."
Az a baj, hogy a fejekben mintha ez lenne: APU = AMD proci, gyengécske Bulldozer architektúrájú magokkal.
Felejtsd el ezt a képet! Valójában az i7 is az, csak az Intel nem használja ezt a terminológiát. Képzelj el egy i7-et és egy R9 380-nal egy lapkán - nem mondanám gyengécskének. Ez 14 nanón lehetséges.#100 lenox
Ez egy értelmes és reális megközelítés.#104 Kopi31415
"Csakhogy ennyi foglalat APU esetében a 2 CU-t jelenti."
Úgy érted: CU=CPU?"Amennyiben mellé teszel még 4 dGPU-t, vagy egyéb koprocesszort, az már nem APU."
Nem tennék mellé dGPU-t, annak semmi értelme. Ezért kár APU-t fejleszteni."Márpedig egy foglalatnyi helyre nem fog soha beférni az akár egy top CPU+ akár 4 top dGPU számítási teljesítmény."
Persze, hogy nem fog. Az esetek többségében nem is kell.
Te egy olyan rendszerről beszéltél, amiben egy-két CPU és négy dGPU van, mindegyik a saját hűtésével, és ezek kommunikálnak egymással valahogy. Ezek helyébe képzelek hat APU-t, mindegyiket a saját hűtésével, és ezek is kommunikálnak egymással. Így van ugyanannyi lapka, hasonló fogyasztás, hasonló hűtőteljesítmény és hasonló számú számolóegység. -
#06658560
törölt tag
"Ennyi foglalatban (2CPU + 4cGPU) az APUk is komoly összteljesítményt adhatnak le."
Csakhogy ennyi foglalat APU esetében a 2 CU-t jelenti. Amennyiben mellé teszel még 4 dGPU-t, vagy egyéb koprocesszort, az már nem APU. Márpedig egy foglalatnyi helyre nem fog soha beférni az akár egy top CPU+ akár 4 top dGPU számítási teljesítmény.
"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. "
Itt jön képbe a feladathoz igényelt hardver. Ha "kevesebb, jól párhuzamosítható, sok memóriamásolással járó a feladat, akkor megéri az APU-ra igazítani. Ha a memóriamásolások mennyisége, jellege olyan, hogy elfér egy GPU memóriájában, ritkán kell memóriamáslást alkalmazni (mert egyszer betölti a GPU memóriájába, majd azzal az adatmennyiséggel elvan egy jó ideig, s más adathoz nem kell nyúlnia), akkor a CPU+dGPU rendszer a nyerő. Amikor pedig sok a memóriamásolás és marha nagy számítási kapacitás is kell, akkor jön a HPC, render farm, stb. megoldások clusterekkel, minden egyéb mókával.
-
-
#102
hugo chávez
aktív tag
#06658560
#90
hugo chávez
aktív tag
válasz
#06658560
#90
üzenetére
Nagyjából én is ezt mondom, vagyis a "sikeressége" azon múlik, vajon lesznek-e olyan "real-world" feladatok (vagyis inkább mennyi), amiknél valós előnyt jelent egy ilyen végrehajtási mód. És ez az, ami legkésőbb úgy 2020-ra egyértelműen ki is fog derülni szerintem.
Az első bekezdést a HSA megvalósítására értettem technikai oldalról, vagyis, hogy ha van alkalmazás, ami profitálna belőle, de a compilerek és a finalizerek nem megfelelő minőségűek, akkor ezen is bukhat. Ez utóbbiak felelősek ugye az adott feldolgozóegység natív ISA-jára lefordítani a HSAIL kódot, ezért nagyon komoly a jelentősége, hogy jók legyenek.
Egyébként Abuval arról is beszéltünk régebben az Intel kapcsán, hogy ugye ők hivatalosan nem támogatják (persze ez még változhat) a HSA-t. Hardveresen pl. a Skylake már megfelelne a követelményeknek, viszont így nem lesz Intel által felügyelt/írt finalizer az IGP-ikhez. Bár az architektúra dokumentációja elvileg nyílt, szóval bárki írhat hozzá, de ha ír is, annak a minőségére meg pláne nem lesz garancia. -
Jack@l
veterán
De akkor mi értelme az apunak, ha úgyis raksz mellé erős kártyát adatpárhuzamos appokhoz? Még mindig a felhasználói programok pár százalékáról beszélünk amúgy, a többi progi mind cpu-n fut csak. Ott meg megint elvérzik a gyengécske apu. (már amelyikbe "erős" gpu részt pakolnak)
-
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.
-
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. -
#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
#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. -
#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.
-
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. -
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? -
#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.
-
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. -
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.
-
#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.
-
#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.
-
#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.
-
#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. -
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. -
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? -
#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.
-
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 -
Fiery
veterán
-
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
-
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.
-
-
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.
-
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.
-
#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.
-
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 ?
-
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. -
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.
-
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...
-
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.
-
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.
-
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.
-
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.
-
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
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.
-
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.
-
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.
-
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
-
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
![;]](//cdn.rios.hu/dl/s/v1.gif)
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
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.
-
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.
-
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
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?
), hanem inkább olyasmire, hogy mennyit emelkedne az AMD részvények ára ha kijönne egy HSA-s AIDA64 
-
Fiery
veterán
OpenCL nem egyenlo HSA. Onmagaban az OpenCL tamogatas nem jelent HSA tamogatast. Az Intel (es az nVIDIA is) van annyira rafkos ceg, hogy egy nyiltnak beallitott, de valojaban az AMD sajat gyerekekent letrejott kezdemenyezes moge me'g veletlenul se alljon be. Ami nekik jo, nekunk felhasznaloknak meg nagyon sz*r. De hat ez van.
-
Fiery
veterán
"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."
Ott az AIDA64 GPGPU benchmark panel: pont ezert raktuk egymas mellé a GPU-s es a CPU-s eredmenyeket. Rendkivul jol latszik, hogy oriasi potencial van a GPU-kban, nagysagrendekkel gyorsabban tudjak vegezni a szamitasokat, ez vitan felul all. Csak epp ami egy benchmarkban mukodik, az nagy semmit nem er, ha a gyakorlatban meg amiben me'g mukodik es hasznalhato, az egy masik benchmark
Ez kb. olyan mint egy taxi, amivel csak versenypalyan szabad kozlekedni. Vagy egy vonat, ami csak az allomas egyik vegebol a masikig hasznalhato.Mi azert nem akarjuk elkezdeni, mert nincs mit elkezdeni. Az nem a mi stilusunk, hogy fogunk egy mar letezo benchmarkot, atnevezzuk, es azt mondjuk, hogy ez egy uj cucc, "world's first". Mert ez lenne, ha a meglevo OpenCL benchmarkokat atvinnenk HSA-ra. A kiindulasi alap, az OpenCL benchmark kernel ugyanaz lenne, csupan a futtatokornyezet lenne mas. Es az eredmenyek is kozel azonosak lennenek, sot. Amikor legutoljara neztuk, a Kaveri HSA path-en atnyomott OpenCL benchmarkok, azaz a HSA compiler altal eloallitott kod valojaban lassabb es bugosabb volt, mint amit az AMD sajat GPU-s OpenCL compilerei tudtak. Ami nem is csoda, hiszen a GPU-s OpenCL compilernek van nehany ev elonye kiforrottsagban.
Nyilvan teljesen mas lenne a helyzet, ha me'g sosem foglalkoztunk volna GPGPU-val vagy OpenCL-lel. Akkor lehetne specifikusan HSA-ra fejleszteni a benchmarkokat, bar akkor meg a legacy tamogatas okan kellene igazsag szerint kiemelni a HSA-bol az OpenCL kerneleket, es a nem-HSA-ready konfigokon atkuldeni a hagyomanyos OpenCL runtime-on. Es vegul ugyanoda lyukadnank ki, mintha forditva csinalnank, azaz megint nem lenne sok ertelme.
"A szekértolás pedig kétoldalú lenne ugyebár
"Olyasmire gondolsz, mint amit az AMD a Fury Nano kapcsan muvelt az IT mediaval?
Nothx, akkor inkabb ne toljon minket senki. -
Fiery
veterán
OpenCL 2.0-ban lehet HSA-ra is programozni. A baj inkabb az, hogy a HSA-t nem tudod hasznalni Intel es nVIDIA GPU-kon. Az meg a GPU-piac 90+%-at jelenti, sajnos. Innentol kezdve a PC-piacon zarojelbe is lehet tenni a HSA-t, ugy ahogy van. A mobil piacot meg mar lefestettem, ott me'g ennyire se jo a helyzet...
Persze azt is lehetne csinalni, hogy megirod az OpenCL 2.0 kernelt, es vagy HSA-val futtatod, vagy legacy OpenCL-lel. Papiron tok jo megoldasnak tunik, csak ugye ott vannak az Intel es nVIDIA szemetre valo OpenCL compilerei, amik szepen el is gancsoljak az ilyen otleteket... A HSA megoldana ezt, csak ok nem fognak HSA-val foglalkozni.
-
Fiery
veterán
Az AMD motivaciojaval nincs semmi gond, csak szerintem egesz egyszeruen eltaktikaztak magukat. Eloszor felpattantak az OpenCL gyorsvonatra, csak aztan rajottek, hogy az a vonat nem megy sehova, csak az allomason pofog egy helyben. Aztan arrol kvazi leugrottak, es jott a HSA, gondoltak, majd ha sajat kezbe veszik a dolgot, akkor helyre tudjak rakni az OpenCL-t. Nemtom miert gondoltak ezt, amikor az OpenCL bukasanak is az iparagi szethuzas volt a fo oka. Nem volt alapvetoen az OpenCL-lel sem semmi gond, nem volt az eredendoen hulyeseg, papiron. Csak epp a gyakorlatban sokszor nem mukodik az, ami papiron mukodik. Gyakorlati buktatok, politika, az egyseges cel hianya, stb. stb. (lasd me'g Flash, Java netbankolas, stb, papiron mind nagyon jol neznek ki)
Ugyanez a baj a HSA-val is: azt hitte az AMD, majd ok kitalalnak egy jobb OpenCL-t, amihez aztan mindenki csatlakozik. A baj az, hogy a mindenki minusz 3-5 ceg me'g mindig keves. Ha sikerul nekik a maradek nehany szereplot is bevonni, akkor abszolut nagyot gurithatnak a dologgal, de addig semmire nem jo az egesz. 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...
-
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 -
Jack@l
veterán
A kérdés hogy mért pont a hsa-t kell eröltetni évek óta, ha egyszer ott van az opencl 2.0(meg készülőben a 2.1). Intel már tavaly óta támogatja a procijaiban, driverben.
https://software.intel.com/en-us/forums/opencl/topic/531074HSA-ra meg amit találtam:
- amd oldalán semmi, csak opencl-es letöltések a heterogenious szekcióban
- egy eldugott github-os oldalt, ami a kaveri meg carizzo-hoz ad implementációt, csoda hogy megtaláltam -
Fiery
veterán
"Válasz: mert általában érdemes elolvasni, megbízható információkat ad, olyanokat is, amik nem kapnak nagy nyilvánosságot. Na, ezért örömmel látom, ha hozzászól, és nagyot csalódok, amikor szakértő mezbe bújtatott, harsány és bántón megfogalmazott véleményt találok csak."
De ha ilyen lelkesen olvasod a hozzaszolasaimat -- aminek oszinten orulok, smiley nelkul --, akkor gondolom az is feltunt mar, hogy a sokszor tomor, velos, szurkalodo kommentjeim leginkabb csak arra iranyulnak, hogy aztan egy erdekes es izgalmas diskurzus bontakozzon ki? Mert a nyito komment utan nem tuntem el, hanem sot, reszletesen kifejtettem azt, amit a nyito postbol hianyoltal. Remelem, igy mar oke a dolog, es megbocsatod a nyito postot
-
ukornel
aktív tag
"Nem károg, csak reálisan látja a helyzetet"
Aha persze... a hozzászólásban semmilyen konkrét állítás nem volt, csak feltételezések más feltételezések alapján, és aztán egy jó kis fejcsóválás."nem tapsikol ész és tények nélkül"
Jó lenne, ha megneveznéd bicskanyitogató kijelentésed címzettjét, mert én nem veszem magamra az "eszetlen" jelzőt."Gondolom a másik hatvanötöt az elmúlt n évből akkor nem olvastad."
De igen, olvastam, és olvastam hozzá rendszerint Fiery kételkedését is. Ide viszont végképp nagyon fölösleges volt.">>"De ha eleged van belőlük, minek olvasod?"
Mert érdekelne a téma a bullshitek nélkül, amit abu rendre mellé tesz."Speciel semmi bullshit nem volt ebben a cikkben.
De ide kapcsolódva hadd válaszoljak egy föl nem tett (de idevágó) kérdésre: Miért olvasom Fiery hozzászólását, ha idegesít?
Válasz: mert általában érdemes elolvasni, megbízható információkat ad, olyanokat is, amik nem kapnak nagy nyilvánosságot. Na, ezért örömmel látom, ha hozzászól, és nagyot csalódok, amikor szakértő mezbe bújtatott, harsány és bántón megfogalmazott véleményt találok csak.
Ez másoktól nem föltétlenül okoz ekkora megrázkódtatást, mert inkább átugrom; azon se lepődj meg, ha téged is halálos nyugalommal ignorállak -
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.
-
Fiery
veterán
-
Fiery
veterán
Hogyne lehetne
Az AIDA64 benchmarkjai es a stresszteszt modul mar most is nativ 64 bites. Ezek azok a reszei a szoftvernek, ahol gyakorlati jelentosege is van a 64 bitnek, nem csupan egy jol hangzo marketing szoveg. Minden mas marad 32 biten, amig maradhat. Bizunk benne, hogy a Microsoft me'g egy jo darabig megtartja a WoW feluletet a Windowsokban, es igy sokaig marad 32 biten az AIDA64 nagy resze.HSA benchmarknak meg akkor lenne ertelme, ha hirtelen alkalmatlan vagy keves lenne a mostani OpenCL benchmark szett. Azaz, ha mondjuk megjelenne egy csomo HSA-ready hardver, rendes HSA runtime-mal, amin viszont nem vagy nem jol futna az OpenCL benchmarkunk. Vagy ha lenne olyan hardver, ami csak HSA-ready lenne, de nem tamogatna OpenCL-t. Kizarolag az AMD APU-ira fejleszteni HSA benchmarkot, ami raadasul lenyegeben ugyanaz lenne, mint a mostani OpenCL benchmark, nem lenne egy okos dontes. Nem vagyunk mi annyira izgalmas piaci szereplo, hogy pont mi kezdjuk el tolni az AMD szekeret. Mar most is nagyon jo eredmenyeket produkalnak az AMD GPU-k az OpenCL benchmarkjainkban, legyen ennyi eleg
-
sayinpety
tag
HSAILre optimalizalhato a kod. IHVk tervezhetnek HSAILhez hardwaret.
HSAIL>CPU ISA atgondoltabb mint OpenCL CPU fallback. HSAIL jol mappelheto AVXre! Rovid tavon Intelnek legjobb a HSA.Tudtommal Submarine support azert letezik hogy hivatalos bejelentes elnapolhato legyen.
-
Fiery
veterán
válasz
sayinpety
#31
üzenetére
Magyarul olyan tamogatok, akik nem akarjak arcukkal vallalni a dolgot?
Mi lenne ennek az ertelme, miert lenne ez jo nekik vagy barki masnak? Vagy csak addig titkoloznak, amig a hardverekbe nem kerul be a HSA tamogatas? Barcsak igy lenne, es hirtelen egy csapasra minden CPU gyarto + minden oprendszer gyarto eloallna, hogy "Egyesitsuk eroinket!" Plane izgalmas lenne, ha az Intel es az nVIDIA is csatlakozna, amire egesz pontosan 0 eselyt latok tovabbra is. De az mindenkepp hatalmas elorelepes lenne, ha az oprendszer es fejlesztokornyezet gyartok tobbsege csatlakozna a HSA-hoz. Tokmindegy, hogy ez valojaban mennyire szukseges a HSA mukodesehez, nem minden a technikai feltetelekrol szol. -
Fiery
veterán
válasz
sayinpety
#30
üzenetére
Arra a Javara gondolsz, ami nem fut OSX alatt, iOS alatt, Edge bongeszobol, WP-n, Tizenen, stb?
Mert akkor alig varom De viccen kivul -- bar amit irtam 1 sorral fentebb, az sajnos nem vicc --, termeszetesen tudom, hogy _elmeletben_ hogyan nez ki a HSA. Papiron, elmeletben tok jo. En vegig a gyakorlati buktatokrol beszeltem. Elmeletben en is egy rendkivul kozeli jobaratja vagyok Candice Swanepoel-nek
Vagy gondolod, hogy realis elkepzeles az, hogy majd lesz valamifele runtime iOS-re, OSX-re, Windowsra, WP-re, amivel raadasul a Java/OpenCL kod kompromisszum mentesen fog futni akkor is, ha a vas alatta me'g veletlenul sem HSA-compliant, raadasul az oprendszer sem tamogatja az egesz erolkodest? Nem veszit majd az ember teljesitmenyt azon, hogy ha csak HSA kodot ir, es a runtime-ra hagyatkozik, hogy majd az valahol, valahogyan lefuttatja a kodot? Csak azert kerdezem, mert amikor pl. OpenCL kodot probalok CPU-n futtatni, ott nem az lathato, hogy az ilyen fallback lehetosegek jobbak lennenek, mint ami mondjuk az ember C++-ban tud alkotni egy kis kezi optimalizacioval
-
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. -
-
Fiery
veterán
válasz
sayinpety
#26
üzenetére
"Microsoft/Google tamogatok"
Ugy erted, hogy megtűrők, ugye? Mert a hsafoundation.com-on nem latok MS es Google logot sem, me'g a "koca" tamogatok kozott sem. Viszont tamogato a Marvell, aki lassan mar SoC-ot sem gyart; ill. a VIA, aki me'g odaig se jutott el, hogy az OpenCL-t implementalja a SoC-aiba vagy a chipsetbe (ez utobbival elindultak, de feladtak).
-
Fiery
veterán
válasz
sayinpety
#24
üzenetére
Veled mar ertekeztunk errol a temarol, igy tudom, hogy profi vagy ezen a vonalon (is). Ugyhogy ennek fenyeben ertsd a kerdesemet: egyszer megirod a kodot, es utana mi lesz? Futni fog Kaverin, Godavarin, Carrizon. Es utana? Me'g ha tegyuk fel a MediaTek es Qualcomm SoC-okba be is kerul -- persze csak a legujabbakba, nyilvan --, akkor is egy HSA-t celzo mondjuk OpenCL koddal hany platformot, hany eszkozt tudsz megcelozni? Amig nem all be a szabvany moge teljes mellszelesseggel a teljes iparag (eselye = 0), addig minek bohockodni ezzel? Ha a piac szuk szeletenek tamogatasa annyira izgalmas dolog lenne, akkor mar reg nem itt tartana a BB10 vagy epp a WP. Sot, az AMD sem itt tartana, hiszen akkor mar reg racuppantak volna a HSA-ready AMD APU-kra a fejlesztok. Ja, es a Mantle-re is megjelent volna akkor egy rakat jatek, ahogy egyebkent igertek is.......
-
Fiery
veterán
Khm, ismeros problema
Valojaban azt a benchmarkot meg lehetne irni OpenCL 2.0-ban is, HSA sem kellene hozza. Es azert irtak meg egy nyakatekert driveres hakkolassal -- hiszen akkor, amikor az megjelent, me'g a kanyarban nem volt a HSA 1.0 specifikacio --, hogy ne OpenCL 2.0-ban irjak meg, hanem elmondhassak, hogy HSA. Az a HSA, amivel elvileg portolhato a teljesitmeny, csak sajnos nincs hova portolni a teljesitmenyt Hiszen nincs mas platform, amire lehetne portolni. Mondjuk nem csak hogy nincs hova, nincs mit portolni. -
sayinpety
tag
Velemenyem szerint nem ertitek mi a HSA. Felre lett magyarazva? Nincs sok idom, roviden irok. Minden IHV rendelkezik sajat virtual ISAval es queueing languagevel. A HSA kezdemenyezes egysegesitesre. Heterogeneous System Architecture Intermediate Language es Architected Queuing Language. Az IHVk erre cserelik sajat zart technologiaikat. Atlag programozot a valtasbol annyit vesz eszre hogy az IVH specific hibak eltunnek. Valoban csak egyszer kell a kodot megirni.
-
Reggie0
félisten
Ez tok jo, de normalis mappingal siman hozhato kb. ez az eredmeny,mert a CPU oldalon tok mindegy, hogy a PCIE-n az adatokat csak 8...16GB/s-el eri el, hiszen a szamitasok javareszt nem ott mennek a megjelentieshez/menteshez nem kell sok muvelet. Ez pont egy olyan pelda, ahol a HSA elonye szinte nulla, max prezentaljak, hogy HSA-val csinaltak valamit.
-
Fiery
veterán
Me'g egy pelda arra, hogy a programozok valojaban mit szeretnenek latni, mit szeretnenek hasznalni. Amikor megjott a Win8, es a Microsoft bemutatta a WinRT API-t, onnantol lehetett appot irni Win8-ra, az uj, WinRT API-val. Azzal parhuzamosan ment a Windows Phone 8, ami viszont Silverlight API volt. Kulon API, kulon UI, de legalabb kozos fejleszto kornyezet (VS2012). A fejlesztok nyilvan huztak a szajukat: rohadt sok kodolas, kulon projektek kellenek ahhoz, hogy meg tudjak celozni a Win7-et (Win32 API), a Win8-at (WinRT API) es a WP8-at (Silverlight API) is. Erre jott a Microsoft, a Win8.1/WP8.1-gyel, amiben bevezette a WinRT-t a WP platformon is. Azonos API, de me'g mindig kulon UI, kulon projekt (de megosztott/shared projekt lehetoseggel). A fejlesztok me'g mindig nyekeregtek, hogy oke, hogy kozos API, de me'g mindig kulon projekt kell a Win8.1+WP8.1-re, es plane kulon projekt kell Win7-re. Erre a Microsoft behozta a Win10-et, amiben azonos projekt, azonos UI, es meg tudod vele celozni az osszes platformot. A Win7-et nem, de erre meg kitalalta a Microsoft, hogy mindenkit nagyon gyorsan atzavar Win10-re az "eroszakos" upgrade-del. A fejlesztok igy megkaptak a kozos platformot, kozos API-t, es nem kell 2-3 fele fejleszteniuk. Ez az, ami a programozoknak kell, igy kell csinalni. Igy kellett volna mar kezdeni a Win7/WP7 bemutatasakor, de ez mas lapra tartozik
Ezzel szemben szerinted mi tortenne, ha hirtelen s varatlan mondjuk a Qualcomm bejelenti, hogy a Snapdragon 820 full HSA compliant (Android alatt)? Ugyanaz, mint a WinRT API kapcsan. A programozoknak eszuk agaban se lenne ezerfele tordelni az amugy is fragmentalt fejleszteseket. Persze, majd kulon code path lesz a Snapdragon 820-ra, es kulon az osszes tobbire. Meg majd kulon a Mali-7xx-re meg az Adreno 4xx-re, mert az OpenCL-compliant, de nem HSA-compliant. Meg kulon app iOS-re, de ott nincs se OpenCL, se HSA. Meg kulon app Win10-re, de ott szinten nincs egyik se.
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 (a tobbiek, a retorika szintjen legalabbis meg mar nagyjabol bealltak moge -- ami tok jo poen, csak pont a legfontosabb, leginkabb lenyeges cegek nem alltak be moge). Minden gyarto villamgyorsan implementalja a HSA-t a sajat cuccara, minden programozasi kornyezetbe (fokent Xcode, VS es Android Studio) hirtelen bekerul a tamogatasa mindenfele nyakatekert baromsagok nelkul. Ahogy hasznalom pl. a StringBuilder class-t, ugy hasznalhatom a HSA-s classokat is Android Studio-ban, ez lenne az idealis. Es mindenhol fusson le, amit csinalok, a hardver oldja meg a _kompromisszum mentes_ futtatast legacy hardveren, legacy oprendszer alatt is. Mert ugye ha irsz egy x86 kodot Visual C++-ban, az futni fog minden x86 vason, igaz? Na ez kellene a HSA-hoz is, es pontosan ez az, ami soha nem fog osszejonni. Ugyanis az alapkoncepcio rossz, raadasul a gyartok mind masfele nezelodnek. Mindenki mast akar, mindenkinek a sajat gyereke a legcukibb. Csak az fog a HSA-val bibelodni tovabbra is, aki az egeszet kitalalta, az pedig nem mas, mint .......
A megfejteseket a szerkesztosegbe varjuk. -
Fiery
veterán
Hogyne lenne kozuk egymashoz. Az AMD eloszor OpenCL (azelott meg Stream, de az mar tortenelem) alapokon kepzelte el a Fusion mint hardveres megoldas gyakorlati ki/felhasznalhatosagat. Miutan ez nem jott be -- es nem azert, amit irsz, annak valojaban semmi koze az egeszhez --, eloszedtek a HSA-t, hatha majd azzal vegre ra tudjak venni az istenverte lusta kodereket (mint pl. en), hogy vegre olyan kodot irjanak, amivel csodalatosan gyorsulni fog minden es bejutunk a nirvanaba. Na, ez megint -- egyelore legalabbis ugy tunik -- nem jott be. Az AMD mar 2 eve is a HSA-val haknizott a komolyabb szoftver cegeknel, ennek eredmenye pedig a nagy nullaval egyenlo, mind a mai napig. Pedig most mar van vas, van final HSA, minden van. Egy valami nincs: elkepzeles arra, hogy ez miert lenne jo a programozoknak. Ez ugyanis nem x86, nem Visual C, hogy egyszer megirod a kodot, es utana mindenen fut, ami x86 + Windows kombinacio (cca. 1-2 milliard konfig). A HSA-ra kodolas nagyjabol azt jelenti, hogy a doglodo PC-piac egyik legkisebb szereplojenek egyik legkevesbe nepszeru termek triojan (Kaveri, Godavari, Carrizo) fog csupan futni az, amit megirsz. Ez a gyakorlatban mondjuk a forgalomban levo PC-k kevesebb, mint 1%-a. Erre kulon kodoljon a programozo?
De vegyuk be a kepbe az OpenCL-t is. Anno arrol volt szo, hogy ez egy OpenGL-hez hasonlo, nyilt standard lesz. Egyszer megirod a kodot, es minden OpenCL-kepes hardveren szepen futni fog. Igy is van, mind a mai napig, ez az elmelet. Elmeletileg ez mukodik is. A problema csupan az, hogy:
1) A gyartok (AMD, Intel, nVIDIA, stb) balf***ok, es nem tudnak jol mukodo OpenCL compilert irni. Megirod a kernelt OpenCL-ben, aztan vagy mukodik egy adott hardveren, vagy nem. Vagy lefagy a compiler, vagy nem. Oke, erre megoldas lenne a HSA, alairom. De ott a tobbi problema:
2) Anno arrol volt szo, hogy majd mindenki az OpenCL-t fogja tamogatni. Minusz a Microsoft, hiszen nekik ott a D3DCS. De persze egy windowsos PC-n elfer az OpenCL runtime, nem tiltotta ki a Microsoft. De aztan "furcsamod" a PC kiment a divatbol, es a mobil eszkozokon mindenki mas iranyba ment, mar valojaban _senkit_ nem erdekel mobil vonalon az OpenCL. Windows Phone-on termeszetesen nincs OpenCL. Androidon maximum megturi a Google, de barmikor kitilthatja, ha epp ugy szottyan kedve. A Nexusokrol is leszetde a Google az OpenCL libraryket az egyik frissitesnel -- ha me'g emlekszik erre a fiaskora valaki. Csak azert nem lett belole balhe, mert ugysincs semmi, amivel ki tudnad hasznalni az OpenCL-t Androidon (mashol se sok). Aztan ott az iOS, amin -- dacara annak, hogy az Apple ha nem tevedek, alapitoja es fo szekertoloja volt me'g nem is olyan reg az OpenCL-nek -- soha nem volt es ugy tunik, nem is lesz OpenCL. Nem csodalkoznek, ha hamarosan az OSX-bol is kitakaritana az Apple az OpenCL-t.
Kanyarodjunk vissza a HSA-hoz. Tegyuk fel, hogy ez lenyegeben ugyanazt celozza, mint az OpenCL, de az OpenCL hibai, hianyossagai, baromsagai nelkul. Annak ellenere is feltehetjuk ezt, hogy bizarr modon az OpenCL a HSA egyik programozasi nyelve
Sz'al ha a HSA annyira tuti cucc, ha valoban megoldja minden problemankat, ha vegre helyreteszi a 6 eve huzodo OpenCL balf***kodast vegre, akkor miert nem tolong mindenki, hogy a HSA szekerere _gyakorlati eredmenyeket is felmutatva_ felugorjon? Miert csak az AMD kepes osszerakni egy HSA-compilant hardvert? Miert nincsenek szoftverek? Latszolag miert sz***ik mindenki az egeszre, a retorikan es a slideware-en kivul? Nem lehet -- csak ugy egeszen veletlenul --, hogy ennek az a prozai oka, hogy az a nyamvadt koncepcio, ami a Fusionbol es az ATI-AMD fuziobol (sic) eredeztetheto, valojaban egy ertelmetlen erolkodes, amibol sokadik nekifutasra sem lesz semmi, soha, akarhany hirt is irsz rola? -
#06658560
törölt tag
Igen, a hatalmas jövőbeli terjedést kész tényként leírva, eléggé random mennyiségből. Állandó hibád, hogy kitalálsz valamit, ami szimpátiád alapján tetszetős jövőkép, majd az összes, ezzel foglalkozó cikkbe beleírod, még ha nem is kellene. Kész tényként tálalva, aztán évek múlva sem következik be a leírt esemény.
-
-
-
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. -
#15
Plasticbomb
addikt
Plasticbomb
addikt
Szuper, lesz tuti MediaTek "APU", már csak a forráskódókkal foglalkoznának egy kicsit, mondjuk kiadnák a meglévőket, hogy lehessen frissíteni egy két évig a vadonatúj telefonom is...
-
Jack@l
veterán
Ahhoz kell a programozás hogy képben legyél mire jó, meg mire nem. Bárki irhat bármit egy cikkbe, hogy jövőre ez meg az lesz a nagy befutó, mikor a konrétan azzal dolgozó emberek meg hülyeségnek tartják és baromira nem gondolják úgy hogy ez lesz a killer feature, ez fogja megdobni bármelyik procigyártó eladásait.
Jó dolog lesz ez mobil fronton pár cél-appba. (mondjuk ahhoz is kell várni még 1-2 évet) -
Fiery
veterán
"Örülök a hírnek, ugyanakkor semmi olyan sincs benne, miszerint jövőre a "HSA éve lenne"."
Konkretan emlitve van benne a 2016-os ev; valamint hogy a Qualcomm kozel all az implementalashoz. Namost, ha kicsit lejjebb gorgetsz, es elolvasod a linkelt cikkeket ("Elozmenyek"), akkor azokbol eleg szepen kirajzolodik, hogy elvileg pont a 2016-nak kene lennie a HSA evenek. Mint ahogy a Kaveri megjelenese elott a 2014-es ev volt az, valamint a Carrizo megjelenese elott a 2015-os ev volt az. Mindig epp a kovetkezo ev a nagy attores eve. Lasd me'g David Coulthard, aki mindig a kovetkezo ev F1 vilagbajnokanak volt kikialtva
"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ű."
Mikor is indult az egesz HSA? Akkor me'g nem annak hivtak, persze, hanem Fusionnek. Segitek, hogy ne kelljen keresgelni a PH archivumban --> Megveszi az ATI-t az AMD. Írta: Erasmus | 2006-07-24 13:10. Tehat mar 9 rohadt eve nem sikerul a gyakorlatba is atultetni az eleve hibas elkepzelest. Az elobbi mondat utolso 4 szava csupan az en velemenyemet tukrozi, nem orokervenyu igazsag. Olvass vissza, hogy miket irtam a HSA-rol ill. a GPGPU temarol elozoleg. Eddig a tortenelem nem ugy tunik, hogy ramcafolna. De oke, varjuk meg, amig a HSA-bol lesz valami, hiszen ahogy irod is, "akkor sem lesz egy gyors, robbanásszerű folyamat - ez törvényszerű". Sz'al mar 9 eve varunk erre. Adjunk neki me'g 9 evet? En benne vagyok, csak ha ilyen hosszutavu, retesteszta-szeru folyamat ez, akkor mennyi ertelme van havonta nehany hirt pazarolni a nagy semmire? Ennyi erovel havonta ugyanannyi hirt kerek a Mars utazasrol, a Szaturnusz holdjainak betelepiteserol, a levegovel hajtott autokrol, az atomfegyverek globalis leszereleserol is.
-
#06658560
törölt tag
-
lee56
őstag
Csak kibírjuk valahogy addig uraim. Evlégre nem kötelező mindent elolvasni, majd azon megsértődni / idegeskedni / károgni
(#1) Fiery : Megint olyan negatív vagy.. Nézd úgy, hogy legalább most az AMD azt nyújtja pontosan, amit anno megígértek, szóról szóra.: Future is Fusion, emlékszel? Tehát már csak az a kérdés, hogy megéljük-e azt a jövőt.
-
#06658560
törölt tag
"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?
"Csak annyira, amennyire azoknak, akiknek abu a HSA mindent lesöpör jellegű cikkeiből van elegük.
Nagyon zavaró a cikkben az állandó beszélés. Szinonimát nem ismersz rá abu?
-
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?
Semmi értelme ennek a kérdésnek, az i7 =/= LGA2011; szerintem csak szándékosan félreviszed a mondandómat. 
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."
Majd reggel melóba menet beleolvasgatok, de ilyenkor már nincs lelki energiám ilyesmire 
Szerintem az sem olvasta végig, akinek válaszba ment ! 
![;]](http://cdn.rios.hu/dl/s/v1.gif)
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.
Új hozzászólás Aktív témák
- Apple iPhone 15 128GB,Dobozával,12 hónap garanciával
- 10magos! Fémvázas! HP EliteBook 860 G9 i7-1255U 16GB 512GB 16" FHD+
- BESZÁMÍTÁS! ASUS B760M i5 12400F 32GB DDR4 1TB SSD RTX 3070Ti 8GB Fractal Design R5 FSP 850W
- BESZÁMÍTÁS! LENOVO IdeaPad Gaming 3 Gamer notebook - R5 5500H 16GB DDR4 512GB SSD RTX 2050 4GB WIN11
- BESZÁMÍTÁS! MSI B450 R5 5500 16GB DDR4 512GB SSD RX 6600 XT 8GB Fractal Design Core 2500 ADATA 600W
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest