Hirdetés

Hozzászólok Aktív témák

  • Fiery

    veterán

    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 :U

  • 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? :(

  • Kopi31415

    félisten

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

    [ Szerkesztve ]

    Part to Part | Status:122% completed | Estimated time remaining:1193hr 2min 30sec ----- Converting Data | Status: 425% completed | Estimated time remaining: 1193hr46sec

  • 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. ;)

    No Comment

  • ukornel

    aktív tag

    "HSA mindent lesöpör jellegű"
    Lehet, hogy te másik cikket olvastál, én ebben a cikkben semmi ilyesmit nem láttam.
    De ha eleged van belőlük, minek olvasod? :F

    [ Szerkesztve ]

  • Reggie0

    nagyúr

    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.

  • haxiboy

    addikt

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

    Csatlakozz az EVE Online közösséghez : http://bit.ly/JoinEVEOnline

  • Jack@l

    veterán

    Nem károg, csak reálisan látja a helyzetet... (nem tapsikol ész és tények nélkül)
    Kicsit talán lehetne adni a szavára, mert éppen ő az az ember aki foglalkozott már gpgpu programozással. (ellentétben a fórumozók 99%-ával)

    [ Szerkesztve ]

  • Kopi31415

    félisten

    "Lehet, hogy te másik cikket olvastál, én ebben a cikkben semmi ilyesmit nem láttam."

    Gondolom a másik hatvanötöt az elmúlt n évből akkor nem olvastad.

    "De ha eleged van belőlük, minek olvasod?"

    Mert érdekelne a téma a bullshitek nélkül, amit abu rendre mellé tesz.

    Part to Part | Status:122% completed | Estimated time remaining:1193hr 2min 30sec ----- Converting Data | Status: 425% completed | Estimated time remaining: 1193hr46sec

  • Reggie0

    nagyúr

    Nem mintha az #1-ben levo meglatasainak barmi koze lenne a gpgpu programozashoz.

  • Reggie0

    nagyúr

    Ja, ahhoz nagyon kell tudni programozni, hogy feltunjon a hireket olvasva a tobb eves csuszas.

  • 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 ]

  • 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)

    [ Szerkesztve ]

  • Plasticbomb

    őstag

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

    Star Citizen, Subnautica

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

    A semmi az nem nincs, hanem van. Ha a semmi van, akkor nincs semmi, de ha nincs semmi, akkor valami van, de az nem semmi.

  • Abu85

    HÁZIGAZDA

    [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 ]

    A semmi az nem nincs, hanem van. Ha a semmi van, akkor nincs semmi, de ha nincs semmi, akkor valami van, de az nem semmi.

  • Jack@l

    veterán

    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 ]

  • Kopi31415

    félisten

    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.

    Part to Part | Status:122% completed | Estimated time remaining:1193hr 2min 30sec ----- Converting Data | Status: 425% completed | Estimated time remaining: 1193hr46sec

  • 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 ]

  • Reggie0

    nagyúr

    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.

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

  • 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

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

  • Fiery

    veterán

    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

    "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 ]

  • Reggie0

    nagyúr

    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 ]

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

  • sayinpety

    tag

    Hivatalosan Submarine support csoport. Nintendo is.

    [ Szerkesztve ]

  • Fiery

    veterán

    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 :)

  • Fiery

    veterán

    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.

  • Thrawn

    félisten

    Olyat lehet kérdezni, hogy mikor lesz natív 64 bites AIDA64 megtűzdelve HSA benchmarkokkal? :D

    Different songs for different moods. łłł DIII Thrawn#2856 łłł Look! More hidden footprints! łłł DIV: Blessed Mother! Save us! łłł

  • 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

    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

    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 :))

  • lee56

    őstag

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

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

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

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

    No Comment

  • 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 ;)

  • 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 :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/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 ]

  • Thrawn

    félisten

    Szívesen nézegetnék olyan HSA benchmarkokat, ahol egymás mellett lehetne látni és elemezgetni a "with HSA" és "without HSA" eredményeket. Gondolom más is van így ezzel. Ennyire nem vonzó a "World's first ever implemented HSA benchmark" titulus? :) Eddig arról írtál, hogy senki nem akarja elkezdeni, de úgy látom te/ti sem akarjátok elkezdeni. :( A szekértolás pedig kétoldalú lenne ugyebár :)

    Different songs for different moods. łłł DIII Thrawn#2856 łłł Look! More hidden footprints! łłł DIV: Blessed Mother! Save us! łłł

  • 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 ]

  • Jack@l

    veterán

    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 ]

  • Thrawn

    félisten

    Itt hol az exe amit futtatni kell? :D

    Different songs for different moods. łłł DIII Thrawn#2856 łłł Look! More hidden footprints! łłł DIV: Blessed Mother! Save us! łłł

  • Jack@l

    veterán

    Ezzel szűrik ki az egységsugarú felhasználókat... :) (ők úgyis csak agyatlanul puffognának hogy nem fut a gépükön)

  • sayinpety

    tag

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

  • 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 ]

Hozzászólok Aktív témák