Remek, akkor tehat 2016 lesz a HSA eve. Mint ahogy 2013-ban a 2014 volt a HSA eve, 2014-ben pedig 2015 volt a HSA eve

Ö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?

Mar megint a jovoket. Ez a HSA-t is csak nyujtjak, de sosem latunk belole semmit. Ideje lenne vegre kiadni valamit es arra alapozva merengeni a jovokeprol.

Ez is olyan mint a játékmegjelenések. HSA-t valahogy a Duke Nukem Foreverhez tudom hasonlítani.

Premium Mining Rigek és Gamer/Workstation gépek: tőlem, nektek :)

"Ö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.

[ Szerkesztve ]

Kevered a Fusiont a HSA-val. A kettőnek nincs köze egymáshoz. A Fusion alapvetően az integrációról szól, vagyis arról, hogy a központi processzor legyen tele gyorsítókkal, amelyek használhatók a különböző feladatokra. Ez megvalósult 2011-ben. Azóta az integráció folyamatos fejlődik.
A HSA egy teljesen más problémára akar megoldást kínálni. A hardveres integráció csak egy alap, amit lehet bizonyos nyelvekkel programozni. Például OpenCL. De sajnos a jelenlegi specifikációkban nincs garantálva, hogy egy OpenCL alkalmazás futni fog minden OpenCL-t támogató hardveren. Lásd például a Strongene HEVC dekódere, és még sok más. Lényegében minden hardverre specifikus optimalizálás kell, hogy fusson, ami nem jó. A HSA ezt a problémát kezeli egy olyan felülettel, ami garantálja a futtathatóságot.

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

[link] - itt van teszteredmény a LibreOffice 4.4.4 Calc OpenCL-ben írt verziójából a HSA-n futtatva, A10-7800B-n tesztelve. Ez még nem végleges, de egyelőre itt áll a gyorsulás.

(#9) Kopi31415: Ki tudnál emelni egy bullshitet bármelyik HSA-s hírből?

[ Szerkesztve ]

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

Mutass már légyszi egy opencl 1.2-es kódot ami nem fut opencl 1.2-őt támogató hardveren?
Mi ennek a "garantálja a futtathatóságot" felületnek a neve? (tool, api, driver)

LibreOffice: honnan tudjuk, hogy az épp nem fut olyan gyorsan le egy dgpu-val?

[ Szerkesztve ]

A hozzászólási jogosultságodat 2 hónap időtartamra korlátoztuk (1 hsz / 10 nap) a következő ok miatt: Az ÁSZF III 10/8. pontjának megsértése - trollkodás - miatt. Többször és többen is kértek már, hogy hozzászólás írásakor használd a linkelés funkciót, mert ennek elmaradása sokak számára zavaró.

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?

[ Szerkesztve ]

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.

[ Szerkesztve ]

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.

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.

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.

Apple sosem all be HSA moge. Nem kuzdenek szegmentacioval. Jo a sajat zart vISA es queueing language.
Microsoft/Google tamogatok.

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.......

[ Szerkesztve ]

"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).

[ Szerkesztve ]

Pontosan. HSA-nak ott lenne ertelme, ahol a GPU-CPU olyan szorosan osszedolgozik, tehat majdhogynem minden utasitasuk interlacelt es nem csak nagyobb taskok vannak, valamint mindkettonek jelentos savszel kell. Ez max. a HPC-ben fordulhatna elo manapsag.

[ Szerkesztve ]

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.

Hivatalosan Submarine support csoport. Nintendo is.

[ Szerkesztve ]

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

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.

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.

Koszi, de sajnos ez sem valasz arra, hogy a gyakorlatban mikepp fog ez mukodni szeleskoru iparagi tamogatas nelkul, ill. anelkul, hogy a fejlesztoknek szet kellene fragmentalniuk a kodjukat. De majd meglatjuk, most mar tenyleg csak 1 evet kell varni a HSA-ra

Amúgy viccen kívül, ez tényleg így van, nem közeltávú cél az amit megcéloztak anno, nemhiába a jövőbe helyezték el ezt az egészet. Új hardverek kellettek, amikehez idő és $ kell kifejleszteni, aztán meg mégtöbb idő mire elterjednek. Szóval kicsit több türelem kell(ene) mindenki részéről. Na persze az is igaz hogy ez a rengeteg HSA-s cikk és Abu aki többnyire írja őket, néha mintha rózsaszín szemüvegen keresztül szemléltetné a helyzetet, ebben is van valami.

Annyira eszementek azért nem dolgoznak ott, vagyis AMD-nél is tudják / tudták, hogy egyedül nem fogják megváltani a világot ezzel (még ha az akkori piaci helyzetüket is vesszük alapul) cirka 9 éve ahogy írtad, és mire a hardverek olyan mértékben fejlődnek, hogy értelmes dolgokra is lehessen használni a CPU mellé integrált temérdek (és azóta is növekvő) grafikus számítási teljesítményt - ahol kb most tartunk - az általad is említett helyzet alakul ki. Azzal a ~ 1% piaccal akikről beszéltél, akik hasznot húzhatnának ebből jelenleg (HSA 1.0). Tehát a lényeg hogy kb. itt kezdődik majd az a jövőkép amit akkor kigondoltak, és amiben azóta egyébként a zintel is láthatóan támogatja őket (na már nem $$$ pénzügyileg, csak filozófiában), legalábbis, ha nekik más elképzelésük lenne a további fejlődésre, nem pakolnának egyre több és jobb IGP-t a processzorjaik mellé, nem?!

AMD-ék inkább ott szúrták el szvsz, hogy megint a jövőböl közelítettek meg a dolgot (ehhez tényleg nagyon értenek meg kell hagyni..). Baromi erős IGP-t raktak, már akkor, az első APU-ikba is (ugye az amúgy sem túl acélos X86 rész erős kárára), amikor még semmi kézzelfogható haszna sem volt, megjelenítésen kívül legalábbis. Intel közben meg csak finoman fejlesztett először X86-ra koncentrálva, aztán most amikor az már elég jó, jöhet a masszív IGP-re gyúrás.

Tehát az a vicces helyzet alakulhat ki, hogy amikor majd 1-2 generációval beljebb leszünk, majd az intelnek lesz több (nem biztos hogy jobb, de mindenképpen több) eladott (elméletileg) HSA-képes APU-ja, de addigra talán beindul és láthatunk is valamit az említett utópisztikus jövőkép áldásos hatásaiból is, és talán nem csak benchmarkokban.

No Comment

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/531074

HSA-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

[ Szerkesztve ]

A hozzászólási jogosultságodat 2 hónap időtartamra korlátoztuk (1 hsz / 10 nap) a következő ok miatt: Az ÁSZF III 10/8. pontjának megsértése - trollkodás - miatt. Többször és többen is kértek már, hogy hozzászólás írásakor használd a linkelés funkciót, mert ennek elmaradása sokak számára zavaró.

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...

[ Szerkesztve ]

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.

[ Szerkesztve ]

Arról már lekésett:
https://github.com/HSAFoundation/Hetero-Mark

@Fiery: pedig úgy tudtam az intel nagyon ráfeküdt az opencl-re az utóbbi években, nvidia szokás szerint nem igazán a cuda miatt

[ Szerkesztve ]

A hozzászólási jogosultságodat 2 hónap időtartamra korlátoztuk (1 hsz / 10 nap) a következő ok miatt: Az ÁSZF III 10/8. pontjának megsértése - trollkodás - miatt. Többször és többen is kértek már, hogy hozzászólás írásakor használd a linkelés funkciót, mert ennek elmaradása sokak számára zavaró.

Latom nem ertheto. Nincs sajat HSA! HSA csak nyilt formaban lehetseges. Nem tudom leirni jobban miert. Lehetne cikk abrakkal. Abu85 keressen meg ha erdekli.

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.

[ Szerkesztve ]