- Milyen processzort vegyek?
- Milyen billentyűzetet vegyek?
- Zeneszerkesztő és DJ topic
- NVIDIA GeForce RTX 4060 / 4070 S/Ti/TiS (AD104/103)
- LG LCD és LED TV-k
- Azonnali informatikai kérdések órája
- 3D nyomtatás
- Übergyors Samsungnak próbál látszani egy hamisított NVMe SSD
- TCL LCD és LED TV-k
- AMD Radeon™ RX 470 / 480 és RX 570 / 580 / 590
Hirdetés
-
Premier előzetesen a Demon Slayer -Kimetsu no Yaiba- Sweep the Board!
gp Elérhető lett Switch-re a játék, amely leginkább a Mario Party-hoz hasonlítható.
-
Toyota Corolla Touring Sport 2.0 teszt és az autóipar
lo Némi autóipari kitekintés után egy középkategóriás autót mutatok be, ami az észszerűség műhelyében készül.
-
A személyre szabott reklám lehet a streaming következő slágere
it A jobb célzott hirdetések érdekében adatplatformot indít a Warner Bros Discovery.
Új hozzászólás Aktív témák
-
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.
[ Szerkesztve ]
-
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? [ Szerkesztve ]
-
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.[ Szerkesztve ]
-
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. -
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.......
[ Szerkesztve ]
-
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).
[ Szerkesztve ]
-
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
![;]](//cdn.rios.hu/dl/s/v1.gif)
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
-
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
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
-
Fiery
veterán
-
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
-
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...
[ Szerkesztve ]
-
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.
[ Szerkesztve ]
-
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.[ Szerkesztve ]
-
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.
[ Szerkesztve ]
-
Fiery
veterán
Bar az is remek lenne, ha lehetne aggregalni a CPU es GPU teljesitmenyet, SZVSZ mar az is hatalmas elorelepes lenne, ha a GPU-t konnyen munkara lehetne fogni a HSA-val. Tehat en ugy gondolom, egymas mellett latni is nagyon jo az eredmenyeket. Azon egyebkent gondolkoztunk, hogy ossze is lehetne az eredmenyeket adni, hiszen ugyanazt szamolja mindket oszlop. Csak epp az csalas lenne, hiszen a Turbo Boost es hasonlo megoldasok miatt egy APU sosem lenne kepes az osszteljesitmenyre. Vagy a CPU-t tudod kihajtani, vagy a GPU-t, de a ketto egyutt nem tudna olyan gyors lenni, mint a 2 eredmeny osszege.
Mi nem kifejezetten Nanot kertunk, hanem barmilyen Furyt, de nem kaptunk. Szerencsere mi legalabb nem okkal nem kaptunk, hanem csak nem jutott. De egy olyan draga es nehezen gyarthato kartyanal, mint a Fury szeria, meg is ertem, ha nekunk nem jut. Az, hogy a mediaban nem jutott mindenkinek, az egy mas tortenet, azzal se lenne gond, ha kisorsoltak volna a kartyakat.
-
Fiery
veterán
Az egesz hir azt sugallja, hogy a 2016 lesz az attores eve. Le van irva, hogy 2016-ban mi mindenre lesz lehetoseg, hogy mennyire kozel all a Qualcomm, hogy a MediaTek is jol halad, lent pedig linkelve van a Snapdragon 820 hir, aminek a cimet is eleg elolvasni. Rakd ossze a puzzle darabokat, ha mar Abu nem hajlando leirni, hogy 2016 lesz a HSA eve
En me'g mindig nem latok HSA-rol szolo bejelenteseket, sorry. Belinkelted, de ide is beszurom, ezt a 3 gugli kereso kifejezest es az altaluk adott talalatokat:
hsa site:amd.com = 4330 results
hsa site:qualcomm.com = 4 results
hsa site:mediatek.com = 98 resultsEz iden majus volt. Azota nem tobb, hanem _kevesebb_ talalat van a cegek site-jan, tessek csak beirni a gugliba! De az nem valtozott, hogy tovabbra is csupan az AMD beszel erdemben a HSA-rol, senki mas. Marmint a weben, de azt hittem, az is relevans, ami a weben van, nem csak az, ami elhangzik egy konferencian.
En azt tekintenem sikernek, ha mondjuk ... nem is tudom ... lenne egyetlen nem AMD altal keszitett szoftver, ami valami ertelmeset is csinal a HSA-val
Nem benchmark, nem demo, nem techdemo. Na jo, viccelek. Valojaban a siker az lenne, ha megjelenne me'g 2-3 HSA-compliant SoC, es elkezdenenek szepen csorogni a szoftverek is, amik pozitiv visszhangot valtananak ki. Olyan szoftverek, amik jok is valamire, amiknel azt mondja az ember, hogy emiatt mar erdemes mondjuk egy AMD APU-t vagy egy akarmilyen mas SoC-cal szerelt telefont/tabletet valasztani."Összességében nem tartom aggasztónak, hogy 9 év alatt nem lett egy ötletszerű elképzelésből iparági sztenderd."
Remelem, tisztaban vagy vele, hogy 9 eve me'g iPhone sem volt. 9 ev borzalmasan hosszu ido az IT iparban. A konkurens megoldasoknak, iparagi sztenderdeknek furcsamod nem kell ilyen hosszu ido, hogy kezzelfoghato eredmenyt hozzanak.
"A gyorsítók megkönnyített munkába fogása a hibás elképzelés?"
Az a hibas elkepzeles, hogy konnyen es egyszeruen lehessen programozni, debuggolni, validalni egy heterogen rendszert. Nem mondom, hogy specialis feladatokra nem mukodik a dolog, megfelelo programozoi rutinnal, felkeszultseggel. Vegul is, a Teslakat is van ahol imadjak, elad joparat az nVIDIA, es nem disznek. De az az elkepzeles, hogy majd egyszer teljesen transzparensen fog mukodni minden, mint ahogy most akarmilyen windowsos PC-n tudsz futtatni egy akarmilyen programot, nos, ez szerintem nem fog mukodni. Mint ahogy most sem mukodik, eddig se mukodott. Vannak megoldasok, vannak probalkozasok, de mindegyiknel ott van az X CPU vagy Y GPU mint alapfeltetel kapasbol, speci driver kell hozza, stb.
"Akkor mi a jó francot csináljon egy kis cég? Semmit??"
Mantle-t, peldaul. Arrol anno azt mondtam, hogy nagyon jo dolog, orulok neki. Aztan az AMD elajandekozta es beszuntette a projektet (legalabbis azt, amirol anno azt mondtak, hogy vilagmegvalto).
-
Fiery
veterán
"Az OpenCL specifikaciok megfelelo kovetese garantalja a futtathatosagot mar most is."
Ja, elmeletben. Gyakorlatban viszont az OpenCL compiler vagy mukodik, vagy nem. Egy hibatlan OpenCL kernel vagy lefordul egy adott compilerrel, vagy nem. Vagy jol fog mukodni az eredmeny, vagy nem. Erre _semmi_ ralatasa vagy rahatasa nincs a programozonak. Erre lehetne persze megoldas a HSA, tudom en
"Az sem art, ha az ember tisztaban van a floating point muveletek hordozhatatlansagaval, ami nem mellesleg nem GPU specifikus problema, ez egyebkent is van."
Van, csak qrvara nem mindegy, hogy mennyire tudod megoldani azt sajat hataskorben. Pl. x86 alatt ez "erdekes" modon nem problema. Itt megint bejon az, hogy a heterogen rendszerekkel tobb a gond, mint az öröm
"Ha valami ezek utan sem fut, az 99% hogy driver bug, de ezen a HSA sem fog valtoztatni, az IHV driver stack nem tunik el, csak sokkal kisebb lesz. De abban a sokkal kisebben ugyanugy lehetnek bugok."
Igy van, me'g egy problema, ami alapszinten jelentkezik. Azaz, maga az elkepzeles tul torekeny, tul necces. Elmeletileg mukodik minden, gyakorlatban pedig a compiler/finalizer keszito kezebe adod magad programozokent. Ez nem az a vilag, hogy C++ kodbol csinalsz x86 binarist, es az mindenhol menni fog, ha egyszer jol lefordult a fejlesztoi gepen. Itt ha a fejlesztoi gepen jol is mukodik a cucc, akkor is elhasalhat barmikor egy juzer gepen. Sot, egy driver frissites utan is elhasalhat az elozoleg jol mukodo cucc. Remek, programozoi szemszogbol ez abszolut vonzo elkepzeles
-
Fiery
veterán
A CPU es GPU egyszerre dolgoztatasa még bonyolultabb, mint ha OpenCL-lel hajtod meg a GPU reszt. Ha ugyanis a CPU-t is OpenCL-lel kezeled, akkor kulon parancssor kell hozza, kulon kotextus, adott esetben kulon kernel, kulon build, es _kulon_ compiler fogja forditani a kerneledet! Tehat eloallhat egy olyan "vicces" helyzet, hogy az OpenCL kernel remekul fut a GPU-n, de az azzal parhuzamosan futo CPU kod viszont hibas eredmenyt ad. Vagy az egyik szalon fut a GPU kod, mikozben a masik szalon vegtelen ciklusba kerul a CPU kernel forditasa. Remek dolgok ezek
Az persze megoldhato, hogy a GPU-n OpenCL kernelt futtatsz, a CPU-n pedig nativ x86 kodot. Csak akkor 2 kodbazis, mindent kulon kell megirni, es persze okostan kell megoldani a multi-threadinget, hiszen az egyik CPU-n futo szalnak vezerelnie kell az OpenCL munkafolyamatot is (queuing). Hidd el, agyrem az egesz, nem tulzok.
A Fury Nano temaban szerintem az lett volna az elfogadhato megoldas, ha idoben szallitja a kartyakat a review site-oknak az AMD, es megmondja nekik, hogy van 1 hetetek ra, aztan villamgyorsan kuldjetek vissza. Majd kikuldik a kovetkezo site-nak, stb. Igy 10 kartyaval, ha idoben indulnak, le lehetett volna fedni 40 site-ot is siman. Nyilvan nem egyszeru logisztika. Alternativ megoldas lett volna, amit emlitettem: be kell ismerni, hogy nincs eleg kartya, valamivel meg kell magyarazni, es ki kell sorsolni a kartyakat a site-ok kozt.
[ Szerkesztve ]
-
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.
-
Fiery
veterán
"Ha az ember nagyon ragaszkodik hozza, hogy ne forduljon ujra a kodja, akkor erre tudnak lehetoseget biztositani a gyartok"
Nem, amit Te mondasz, az nem megoldas. Maximum a 2 lepcsos forditas elso lepcsojet lehet igy meguszni ertelmes keretek kozt, de akkor me'g mindig ott a finalizer. Hiaba rakod be a programodba a HSA kodot OpenCL kernel helyett HSAIL binariskent (ha mar HSA-rol van szo alapvetoen), a finalizer me'g mindig elhasalhat rajta most vagy a jovoben barmikor, egy ujabb vasnal, egy ujabb drivernel. Ez egesz egyszeruen nem mukodik -- hacsak nem vallalja minden gyarto, hogy egy kozponti adatbazisba feltoltott HSAIL kod konyvtarat minden egyes driver frissiteskor vegigtesztel helyessegre es helyes mukodesre is. Ilyet viszont senki sem fog bevallalni, me'g a Microsoft sem (ld me'g: WHQL, ami szinten nem garancia semmire).
"Amit meg mondtam, azt tartom, hogy mas formaban, de x86-on is leteznek a "JIT" megfeleloi, es elmeletben nagyon hasonlo problemakkal talalkozhatnal."
Ez nyilvan igaz, de x86-on _van_ valasztasi lehetoseged. Nem muszaj Javat meg .NET-et hasznalni, ha nem akarsz. Ha azt mondod, a JIT sz*r, hasznalhatsz C++-t vagy assembly vagy akár gepi kodot. A GPU-kon nincs a gyakorlatban erre ertelmes keretek kozt lehetoseged, egyszeruen nem opcio.
"Pl. a leforditott szazezer eves VC++ 6.0 programod produkalhatna hibakat a Skylake-en. Szinte lehetetlen, de amikor az a fordito kijott, meg nem volt Skylake, nem volt errata hozza, azt nem vettek figyelembe a fordito irasanal, a kodod triggerelhet benne hibakat. Es nem azert szinte lehetetlen, mert az elore forditos modell annyira klassz, pont az, hogy nyilvan eleve tok rosszul optimalizalt lesz a kimenet, mert a forditonak lovese sem volt rola, h min fog futni a vegeredmeny, ez meg azert szamit x86-on is, hanem azert szinte lehetetlen, mert a Skylake is, meg a VC++ 6.0 fordito is normalisan meg vannak csinalva, azert."
Nyilvan van erre baromi kicsi esely. De ez az esely kb. 1000x vagy millioszor kisebb, mint az, hogy egy tetszoleges OpenCL kernel, amit ma megirsz, holnap hibasan fog mukodni egy tetszoleges OpenCL-compliant konfiguracion. Ha tudnad, az OpenCL benchmarkok fejlesztese kozben hany OpenCL compiler bugba sikerult belefutnom
Pedig nem hosszu es nem bonyolult kerneleket firkaltam ossze. Volt olyan kernel, ami egyetlen bazihosszu 1 soros ciklusbol allt, es annak az unroll-olasaba halt bele a compiler (AMD is, Intel is, csak masik kernelnel). Es azota is, folyamatosan uldoznek a compiler bugok, most pl. Intel vonalon van egy egyelore nem kijavitott OpenCL compiler bug, ami a Hash benchmarkunkban okoz szamitasi hibat, es igy a benchmark eredmeny torlesre szorul (nem jelenitheto meg). A hiba a Broadwellt (iGPU) erinti, termeszetesen jelentettuk az Intelnek 5 honapja (!), de azota se sikerult javitaniuk. Ugyanaz az OpenCL kernel remekul fut pl. Skylake-en, csak hogy egy, a Broadwelltol nem fenyevekre allo GPU architekturat mondjak.Ja, es az is mokas, amit az OpenCL compiler keszitok tudnak reagalni egy-egy bugra, amit az ember jelent nekik. Pl. kepesek voltak azt mondani, hogy nem kene integert hasznalnom, mert az "nem tipikus GPU-n". Aham, ertem, tehat egy sima 32 bites integertol mar a compiler idegbajt kap, vilagos
Egy masik compiler meg a szinusz fuggvenytol kapott hulyet. Tenyleg ritkasag a szinusz, alig lehet rola hallani valamit a mai vilagban 
"Ha az osszes OpenCL driver es fordito ugyanolyan normalisan meg lenne csinalva, akkor semmi bajod nem lenne. De mivel ugyanazt a feladatot kell tobbszor megoldani egy eleve kisebb piacon, nyilvan nem lesznek."
Igy van, es ezert is hibas a koncepcio. Amig ez az egesz ilyen ingatag labakon all, addig nem mas, mint egy betas kiserlet. Azzal kiserleteznek a gyartok, hogy vajon hany programozo fog idot es energiat nem sporolni azon, hogy egy ilyen idiota rendszerben is fejlesszen, csak azert, hogy a GPU-val 2-3-5-10x nagyobb teljesitmenyt el tudjon erni. A gyakorlat azt mutatja, hiaba van meg a potencialisan nagysagrendbeli teljesitmeny novekedes lehetosege, a legtobb programozo inkabb biztosra megy, es elkeruli az ilyen mokas dolgokat. Ez is az (egyik) oka annak, hogy az OpenCL elbukott. Es mivel a HSA sem tudja az OpenCL osszes problemajat kikuszobolni, nem veletlenul kerulik mar most is el a programozok.
"De a vegeben egyetertunk, kell vagy egy egyseges, vagy egy dominans architektura."
Igen. Kell egy x86. Vagy ARM. De az legyen stabil, egyseges, kozpontilag kezben tartott, es lehessen nativan kodolni ra. Abba pedig egyszeruen nem fer bele a GPU, es kesz. Meg kell oldani, hogy a CPU at tudja venni a GPU feladatait, a hagyomanyos ISA-val (x86 vagy ARM). Lasd Knights Landing, amirol persze Abu pontosan azt gondolja, amit en a HSA-rol. Jovore talan me'g nem fog kiderulni, hogy melyik a jo megoldas, de 5 eves tavlatban szerintem mar latszodni fog.
[ Szerkesztve ]
-
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
GPU-knal sajnos nem megoldas a binarisok hasznalata, hiszen azzal legfeljebb a jelenleg piacon levo GPU architekturakat tudod megcelozni, a jovoben megjelenoket viszont abszolut nem. Raadasul, magadnak kell beassignolni a binarisokat az egyes architekturakhoz, ami eleg bonyolult tud lenni, hiszen nem ad vissza az OpenCL feluleten at olyan infot az OpenCL stack, ami az adott GPU architekturara egyertelmuen tudna utalni. Lehet persze nyakatekert megoldasokat berakni, amivel megis eleg jol beloheto az aktualis GPU architekturaja, de ez az egesz akkor is egy nagy katyvasz, es en szemely szerint nem megoldasnak neveznem, hanem egy borzaszto vekony piaci szegmens (= nagyjabol az MIT laborja es hasonlo akademiai/kutatasi kozpontok) szamara adott esetben jo eszkoznek. Nagyjabol hasonlo, mint amikor egy szoftver OpenCL-lel gyorsitott portjat kizarolag 1 gyarto 2-3 GPU architekturajara keszitenek el kulonfele mondvacsinalt vagy adott esetben legitim indokokkal -- konkret neveket nem emlitenek, de van ilyen szoftver a piacon, es nyilvan a PH is lehozta hirkent anno
Az x86 IR kapcsan valahol, a dolgok legmelyen igazad van, de abban viszont nagyon nincs, ha ezt parhuzamba akarod hozni a GPGPU vilaggal. Ugyanis, az x86 processzorokban ez az "JIT" hardveresen van implementalva, es mint ilyen, nem valtozik. Tehat a "compiler", ami az x86 utasitasokat szetszedi RISC vagy akarmilyen mas kisebb/egyszerubb utasitasokra, nem valtozik, hanem fix, legalabbis egy adott x86 processzor steppingen belul. Es a steppingek kozott is olyan minimalis a valtoztatas, es olyan durvan odafigyel az AMD, Intel es VIA is a validaciora, hogy a gyakorlati eselye annak, hogy a "compiler" valaha is bajt okoz egy x86 kod futtatasakor, lenyegeben a 0-val egyenlo. Ez egy osszehasonlithatatlanul kisebb problema, mint akárcsak egy C++ --> x86 compiler vagy plane mint egy OpenCL compiler. Raadasul, egy OpenCL compiler buggal ellentetben, ha kipattan egy x86 "compiler" bug, azt azonnal felkapja a media, es ha kicsit is komolyabb problema, visszahivasba vagy BIOS patchbe fog fajulni (pl. Pentium FDIV bug).
"Valoszinuleg egy NVIDIA, AMD GPU-t lehetne viszonylag megbizhatoan programozni assembly-ben"
Hogyne lehetne, ezt nem vitatja senki. Csak epp az assembly utasitasok ill. azok hasznalata architekturankent valtozik. Amit nagy nehezen megcsinalnal Keplerre, azt a Maxwell megjelenesekor azonnal portolnod kene az uj architekturara. Ez igy nem megoldas, hacsak nem valaki szuletett mazochista, vagy pont ezert valakinek megeri nagyon sok penzert fenntartani egy programozot
[ Szerkesztve ]
-
Fiery
veterán
-
Fiery
veterán
"Nem muszaj lecovekelni az OpenCL-nel, felolem lehet D3D Compute minden Windows-on, meg Metal OS X-en, csak hasznaljuk mar ki ertelmesen a GPU-kat."
Az nem megoldas, tobb okbol sem. Kezdjuk ott, hogy ha az Apple, Google, Microsoft okoszisztemat nezzuk, boven eleg nyomora van a fejlesztoknek azzal, hogy mindegyikre kulon nyelven es kulon fejleszto kornyezetben kell nyomulni. Apple: Xcode es C++11/Swift, Google: Android Studio es Java/C++, Microsoft: Visual Studio es C#/C++. Tudom en, hogy van ezeknek kozos halmaza, de a tipikus inkabb megis a 3 fele nyelv (Apple: C++, Google: Java, MS: C#). Na ha ebbe me'g belekeversz 3 kulonbozo GPGPU fejleszto platformot+nyelvet is, az vegkepp kiveri a biztositekot a programozok fejeben
De persze me'g ha a nyelv fix is lenne, akkor is ott lenne a JIT problema, stb. stb. stb, megint korbeertunk -
#84
Fiery
veterán
hugo chávez
#73
Fiery
veterán
válasz
hugo chávez
#73
üzenetére
"Ha lenne egységes/közös architektúra, "hardveres" ISA, akkor éppenhogy nem is kéne a HSA/HSAIL-szerű közös virtuális (vagyis szoftveres) ISA-kkal szórakozni a legalább ezen a "magasabb" szinten történő egységesítés nevében és a HSA-koncepció is pont amiatt jött létre, mert nincs és nem is várható olyan egységes (és "jövőbiztos") architektúra, amit minden gyártó elfogadna, hajlandó lenne átállni rá, nem?"
Persze hogy nem kene a HSA, ha nem lenne ennyifele architektura. A HSA egy ernyot kepez az architekturak fole, egy absztrakcios reteget, ilyen szempontbol tenyleg hasonlit a Javara vagy epp a JavaScriptre. De ahhoz, hogy ez mukodjon, hasonloan a JavaScripthez, mindenkinek tamogatnia kellene, es hasonloan a JavaScripthez, baromi jo es stabil compilerek kellenenek hozza. Egyik sem adott, es az alagut vegen nem latszik, hogy mikor jon el ez az ido. Ha pedig a "nagyok", azaz az iparag fejlodeset valoban formalo cegek megmakacsoljak magukat, akkor hasonloan a Flash es az OpenCL halalahoz, a HSA is ki lesz vegezve, me'g mielott a gyakorlatban be tudna mutatni, hogy mire is kepes.
"Javíts(atok) ki, ha tévednék és azóta már változott a dolog, de úgy tudom, hogy konkrétan a HSA kifejezetten az APU-król szól"
Elsosorban az APU-krol szol, de ugyanugy bevonjak a CPU-kat es a dGPU-kat is egy legacy retegen keresztul, mint ahogy az OpenCL is mukodik manapsag.
"Arra ott van az OpenCL"
Ertsuk mar meg vegre, hogy a HSA OpenCL nyelven is meghajthato
A ketto nem 2 kulonallo ag. Az OpenCL viszont nem csak az OpenCL kernelek nyelvet, mukodeset meghatarozo nyelvet foglalja magaban, hanem a frameworkot, azaz az OpenCL kernelek leforditasat es vegrehajtasat menedzselo reteget is. Ez utobbi 2 eleg docogosen mukodo modulon probal a HSA javitani a sajat, fejlettebb megoldasaival. De maga a nyelv, amiben megirod a kernelt, amit aztan a HSA lefordit es vegrehajt a vason, lehet OpenCL is."Tehát egy hipotetikus HSA bench is csak APU-kon menne, a dGPU-k irrelevánsak a HSA szempontjából."
Nagyjabol igen, es ezert sem lenne relevans pl. az AIDA64 mostani OpenCL benchmarkjait atvinni HSA-ra. Egy APU+dGPU kombonal lenyegesen kedvezobb eredmenyt kapnal HSA nelkul, mint HSA-val, hiszen a dGPU-t a HSA-val nem vonnad be a benchmarkba, mig a "hagyomanyos" OpenCL benchmark azt is szepen megdolgoztatja.
Ahol egyebkent a HSA egyertelmuen villantani tudna, es amire lehetne benchmarkot is irni kifejezetten, az valami olyan munkafolyamat lenne, aminel a CPU (azaz az x86 magok) es a GPU egy bonyolult adatstrukturan parhuzamosan (pontosabban felvaltva) dolgozna. Valamint, me'g egy nagysagrendet tudna gyorsitani a HSA, ha raadasul a GPU altal vegzett munkafolyamat relative gyorsan lefutna. Jelenleg, ha pl. OpenCL-lel akarsz olyan szamitast vegezni, ami nagyon hamar lefut a GPU-n, majd utana a CPU-val valamit matatsz az adatokon, es megint jon a GPU, es megint tul hamar vegez a GPU (es igy tovabb), akkor a rengeteg kernel inditas miatt, a gyenge labakon allo, nem optimalis queue modell miatt baromi lassan fog az egesz mukodni. Me'g akkor is lassu lesz, es alig gyorsul egy tisztan x86 kodhoz kepest, ha OpenCL 2.0-val, azaz megosztott memoriaval oldod meg. Az meg aztan plane horror, ha a memoriat is masolgatni kell, es a GPU tul gyorsan letudja a melot. A mostani OpenCL keretek kozt nagyon oda kell figyelni arra, hogy mikor es mennyi memoriat masolgatsz, es gondoskodni kell arrol, hogy a GPU-nak elegendo munkat tudj adni.
[ Szerkesztve ]
-
Fiery
veterán
"iPhone... az egy kiválóan összerakott okostelefon (volt olyan már korábban, hogy ne lett volna), a hozzá igazított zárt op.rendszer, és szoftveres ökoszisztéma kellően minőségi összegyúrása. A siker alkotóelemei majdnem mind léteztek már korábban. Sokkal inkább finomításon, tökéletesítésen volt a hangsúly, ötletes tálaláson, ergonómián. A HSA kidolgozása ezzel szemben nem csiszolgatást jelentett, hanem az alapok kidolgozását, ami a legtöbb részletében teljes újdonság."
Ebben nem ertunk egyet. A HSA alapjat kepezi a Stream, a CUDA, az OpenCL, a D3DCS. Boven lehetett otleteket nyulni a kulonfele JIT megoldasokbol, pl. Java. Semmivel sem nagyobb melo egy HSA-t osszerakni, mint egy iPhone-t. Egyebkent az iPhone-t csupan azert emlitettem, mert az mar rohadt regen volt, talan olyan regen, hogy sokan fel sem tudjak idezni, miert volt akkora szam es hogyan nezett ki a legelso iPhone. Es a Fusion/HSA fejlesztese me'g annal is regebben kezdodott.
"Én nem értek hozzá, nem tudom megítélni, de azért egy jópár fejlesztő -úgy tűnik- mégiscsak hisz benne. Nem tudom kinek van/lesz igaza. Talán mindkettő véleménynek, mert meg lehetne csinálni a dolgot, de ha nem, vagy csak fél szívvel támogatják a nagyok, akkor kevés bugos szoftver lesz csak, és elhal végül.
Remélem, nem így lesz."Mutass nekem 3 olyan konkret programozot, aki lelkesedik a HSA-ert, _es_ aki mar OpenCL-ben vagy CUDA-ban is nyomult elozoleg, tehat kepben van GPGPU vonalon. Aki alig varja, hogy mas procin is fusson, mint az AMD APU-jai. Olyat is mutass, aki mar eloallt HSA koddal, barmilyen celbol. Nyilvan lehetne ilyen embereket talalni, de miutan megvannak ok, nezzuk meg, hanyan tolonganak az Android fejlesztoi szekcioban a StackOverflow-n. Vagy a CUDA forumokban. Vagy barhol, lenyegeben. Minden hulyesegre lehet fanokat talalni, a legnehezebb programozoi feladatokat is megoldjak paran, de az igazi merce valojaban az, hogy mi a mainstream.
"Csókolom, a HSA kb olyan ambíciózus, a lapok az iparágban újraosztani hivatott kezdeményezés, mint a Mantle a grafikában, külső laikus szemmel legalábbis. Egyik jó, a másik nem?"
No offense, de baromi nagy laikusnak kell lenni ahhoz, hogy valaki a HSA es a Mantle koze egyenloseg jelet, vagy ugy altalaban barmilyen relacios jelet rakjon. Kb. annyi kozuk van egymashoz, mint a tengerjaro hajonak a futobiciklihez. De ha mindenaron akarod, felolem hasonlithatjuk oket egymashoz, abszolut nem professzionalis modon. A Mantle ugyanaz pepitaban, mint ami anno a Glide volt, valojaban semmi extra, csak egy jo pillanatban egy felutott magas labda lecsapasa. De mivel en nagy rajongoja vagyok a custom API-knak -- mert valojaban csak azokkal lehet egy adott architekturabol kihozni a maximumot, es biztositani a konzisztens teljesitmenyt --, a Mantle kapasbol megtetszett. A HSA ezzel szemben egy alapjaiban rossz elkepzeles (GPGPU) plusz absztrakcios retegekkel valo megfejelese, annak remenyeben, hogy az alapveto hulyeseget hasznalhato szintre tudja hozni. A low-level custom 3D API alapjaiban jo otlet, mig a HSA alapjaiban hibas elkepzeles. Ez az en velemenyem a temarol
A jatek fejlesztok meg biztos maskepp gondoljak, legalabbis a Mantle kapcsan.[ Szerkesztve ]
-
Fiery
veterán
válasz
#06658560
#90
üzenetére
Ezt nehez ilyen szintre leegyszerusiteni, vagy legalabbis nem celszeru. Nem celszeru csak azt nezni, hogy valami CPU-n es GPU-n is fut. Inkabb nezzuk a regi paradigmat es vessuk ossze az uj paradigmaval. A regi paradigma az, hogy van egy GPU-d, aminek van sajat memoriaja (device memory), ami valamekkora meretu. A GPU elvileg baromi gyors, nagysagrendekkel gyorsabb, mint a CPU, es a teljesitmenyehez igazodik a sajat memoriajanak savszelessege is. Problema azonban a szukos savszelesseg (az adatokat ide-oda kell masolni a GPU device memory-ja es a rendszermemoria kozott, a ketto kozotti PCIe csatorna pedig relative szukos), a device memory meret korlatja (van olyan feladat, amihez keves a 4-6-8 GB-nyi memoria), valamint hogy az egyes, a CPU altal a GPU-nak kiadott parancsok (pontosabban feladatok) nem azonnal hajtodnak vegre, hanem egy parancssorba kerulnek. A parancssor kezelese pedig relative lassu, tehat a GPU vegeredmenyben csak relative rossz kesleltetesu parancs vegrehajtast fog tudni csak vegezni. Tovabbi problema ezzel a megkozelitessel, hogy a CPU es a GPU csak nagyon nehezen tudnak ugyanazokon az adatokon dolgozni, hiszen a CPU csinal valamit a rendszermemoriaban levo adatokkal, azt utana at kell masolni a GPU sajat memoriajaba, aztan a GPU is csinal vele valamit, es utana vissza kell megint masolni a rendszermemoriaba, hogy a CPU hozza tudjon ferni az eredmenyhez.
Az uj paradigma (SVM -- azaz megosztott memoria, OpenCL 2.0, de a HSA is erre epit) ezzel szemben az, hogy a CPU es a GPU is ugyanazt a kozos memoriat hasznalja, azaz a rendszermemoriat. Nem kell masolgatni semmit, es joval szelesebb a memoriakorlat is, hiszen a rendszermemoria egy APU-nal joval nagyobb kapacitasu lehet, mint egy videokartya sajat on-board memoriaja. A CPU es a GPU remekul hozza tud ferni ugyanazokhoz az adatokhoz, azaz egymas eredmenyeihez is konnyen hozzajutnak. A parancsok kiadasa is gyorsabb, bar azon inkabb csak a HSA segit, mintsem az OpenCL 2.0. A hatranya ennek a megkozelitesnek az, hogy egy tipikus APU szamitasi kapacitasa nem tudja elerni azt, amit egy dGPU tud, egyszeruen a TDP korlat miatt. Ha bele lehetne szuszakolni a CPU tokba egy 200-250 Wattos sajat TDP kerettel rendelkezo GPU-t, es alarakni mondjuk 256 GB nagyon gyors rendszermemoriat, akkor a 2 vilagot tokeletesen lehetne egyesiteni -- de ez nem egyhamar fog megtortenni, bar az AMD mar felvazolt egy ilyen APU-t (Greenland kodneven).
Az AMD-vel amikor arrol beszeltunk, hogy milyen feladatokhoz jon nagyon jol az SVM, ok azt mondtak, hogy a komplex adatstrukturaknal rendkivul hasznos tud lenni, ill. ha az adatstrukturaban pointerek vannak (pl. lancolt lista). A pointerekkel a regi paradigma nem tud mit kezdeni, hiszen a GPU nem erti, nem ertheti, hogy a rendszermemoriaban hova mutat egy pointer, hiszen nem ferhet hozza a rendszermemoriahoz eleve. A regi paradigmaban ilyenkor at kell konvertalni a strukturat, le kell cserelni a pointereket indexalasra vagy az egesz strukturat at kell konvertalni a GPU "szaja ize" szerint, majd a vegen vissza kell konvertalni. Az ilyen feladatok, azaz amikor a struktura bonyolultsaga vagy a pointerek miatt eleve elkepzelhetetlen volt a regi paradigma szerint atvinni a szamitasokat a GPU-ra; ill. az olyan esetekben, amikor ezt meg tudtak ugyan oldani, de nagyon nagy overheadet jelentett a strukturak es pointerek konverzioja, na az ilyen esetekben varjak a programozok messiaskent az OpenCL 2.0-t ill. HSA-t. Mas kerdes, hogy az ilyen jellegu feladatok baromira nem a mainstreambe tartoznak. Aki kicsit jobb matekbol, mint en, vagy mar foglalkozott ilyesmivel, az biztos tudna mondani egy konkret feladatot, ami olyan jellegu, mint amit en korulirtam. De biztosan nem az audio/video enkodolas, hash szamitas, adat titkositas kornyeken kell nezelodni, azokhoz ugyanis a regi paradigma is viszonylag jo megoldas. Talan az adattomorites lehet az, aminel nagyon jol jonne az SVM, a Huffman tree-re gondolva, de ez csak egy tipp.
[ Szerkesztve ]
![;]](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
ph A Linley Processor Conference rendezvényen mindhárom cég részletezte az erre vonatkozó útitervet.
- Garmin Forerunner 165 - alapozó edzés
- Milyen processzort vegyek?
- Milyen billentyűzetet vegyek?
- Zeneszerkesztő és DJ topic
- NVIDIA GeForce RTX 4060 / 4070 S/Ti/TiS (AD104/103)
- Sorozatok
- LG LCD és LED TV-k
- Azonnali informatikai kérdések órája
- Politika
- Android alkalmazások - szoftver kibeszélő topik
- További aktív témák...
- i5-9600K , és i5-9400F processzor eladó!
- Beszámítás! Intel Core i7 7700K 4 mag 8 szál processzor garanciával hibátlan működéssel
- Intel I5 13600KF 14mag/20szál - Új, Tesztelt - Eladó! 88.000.-
- BESZÁMÍTÁS! ÚJ Intel Core i5 11400F / i9 11900KF / i9 11900K tálcás processzorok 27% áfás számlával
- Intel Core i7-11700K processzor (használt)