Keresés

Hirdetés

Új hozzászólás Aktív témák

  • Jack@l

    veterán

    válasz Abu85 #16 üzenetére

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

  • Fiery

    veterán

    válasz Abu85 #16 üzenetére

    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

    válasz Abu85 #16 üzenetére

    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 ]

Új hozzászólás Aktív témák