- VR topik (Oculus Rift, stb.)
- Házi barkács, gányolás, tákolás, megdöbbentő gépek!
- Milyen TV-t vegyek?
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Epson nyomtatók
- Vezeték nélküli fejhallgatók
- 3D nyomtatás
- NVIDIA GeForce RTX 4080 /4080S / 4090 (AD103 / 102)
- Bambu Lab X1/X1C, P1P-P1S és A1 mini tulajok
- Hobby elektronika
Hirdetés
-
Igencsak szerény méretekkel rendelkezik az Aetina Xe HPG architektúrás VGA-ja
ph Az 50 wattos modellt beágyazott rendszerekbe, MI-vel kapcsolatos munkafolyamatokhoz és edge applikációkhoz szánták.
-
Rossz üzlet az EV-kölcsönzés
it Küszködik az EV-kölcsönzés miatt a Hertz Global, még több EV-t adnak el.
-
Érkezőben a Poco M6 4G
ma 5G-s és 4G-s Pro modell már van, hamarosan lesz Poco M6 4G-s alapváltozat is.
Új hozzászólás Aktív témák
-
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 ]
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ó.
-
#06658560
törölt tag
Igen, a hatalmas jövőbeli terjedést kész tényként leírva, eléggé random mennyiségből. Állandó hibád, hogy kitalálsz valamit, ami szimpátiád alapján tetszetős jövőkép, majd az összes, ezzel foglalkozó cikkbe beleírod, még ha nem is kellene. Kész tényként tálalva, aztán évek múlva sem következik be a leírt esemény.
-
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
félisten
Ez tok jo, de normalis mappingal siman hozhato kb. ez az eredmeny,mert a CPU oldalon tok mindegy, hogy a PCIE-n az adatokat csak 8...16GB/s-el eri el, hiszen a szamitasok javareszt nem ott mennek a megjelentieshez/menteshez nem kell sok muvelet. Ez pont egy olyan pelda, ahol a HSA elonye szinte nulla, max prezentaljak, hogy HSA-val csinaltak valamit.
-
con_di_B
tag
Amerre most haladunk, ugy a GPU-k egyre tobb olyan problemat oldanak meg, ami a CPU-kon mar ugy van, es "szerettek". Kisse kevesbe cinikusan fogalmazva, ahogy bovul a felhasznalasi teruletek szama, egyre tobb olyan kifogas merul fel, mint a QoS megoldhatosaga stb.
Meg nem tudom, hogy abbol lesz-e valami, de idorol idore a cache-coherency is elokerul termeszetesen.
Magukban az utasitaskeszletekben, aritmetikai szinten legalabbis ma sincs sok csoda. Az, hogy most valakinek dedikalt az integer feldolgozoja, vagy reszben az FP-t hasznalja, es akkor azon gyorsabbak lesznek a 24 bites integer muveletek, vagy most van-e half float egyaltalan, ha van, akkor van-e register packing support a 32 bitesnel kisebb tipusokra, meg egyaltalan, packing, vagy explicit kicsomagolo utasitasok vannak, mit szeret az SFU stb-stb. ezek mind absztrahalhato problemak. Amikor nagyobb valtasok vannak, pl. eleve vektoros formaban vannak-e az utasitasok, vagy skalar szalak futnak SIMD tombokon, vagy mi van, az mar egy izgalmasabb kor, de ott meg eleg egyertelmu, hogy az utobbi a nyero megoldas, szoval azt batran atveheti mindenki.
Es ezeknek semmi koze nincs a skalazodashoz. Pl. siman mondhatod azt, hogy minden szal rahivhat egy SFU instruction-re, mintha lenne is olyan vegrehajtoja, aztan meg round robinban lesz kiszolgalva egy kozos poolbol. Ez nem latszik instruction level. Ilyenek CPU-kon is vannak, AVX-et is vidaman lehet implementani 2x4 szelesen.
A vegere maradnak a memoria specifikus dolgok, amiknek igen, van rahatasa a skalazodasra egy bizonyos szinten, de azert osszessegeben jelenleg a cache koherencia hianya vagy meglete, meg, a lokalis memoria implementacioja az izgalmas kerdesek. A cache koherencianal mondhatod azt, hogy legyenek explicit tranzakcios utasitasok, aztan legfeljebb NOP-kent implementaljak azokon a rendszereken, ahol nem kell. A lokalis memorianal meg rohadtul mindegy, hogy programozhato cache pinning volt, vagy dedikalt hardver, azt neked nem kell latni.
Az osszes tobbi dolog, pl. vektorszelessegek stb. a memoria kapcsan azok vagy a) a grafikus felhasznalas oroksegei, ertsd minden float4, ami rohadtul nem igaz GPGPU-ra amugy sem, szoval halal ra vagy b) a sokcsatornas DRAM mukodesi elvebol kovetkezik, azt meg ugyis mindenki ugyanugy fogja megoldani.
Ami meg beuthetne a skalazodasnak, termeszetesen, ha az ilyen dolgok hogy "fetcheltem egyet a memoriabol, hogy jut el hozzam a DRAM-bol az adat" utak kozvetlenul programozhatoak volnanak, de erre nincsen semmi szukseg. Igen, lehet cached, meg non-cached, meg ilyen olyan fetch-eket ISA szinten megkulonboztetni csak van ra jobb megoldas, illetve ezek sok esetben nem jelentenek funkcionalis kulonbseget a programban, szoval a non-cached implementalhato cached utasitassal, ha nincs mas.
Az igaz, hogy ha a 3-4 evvel ezelotti ISA-k valamelyiket szabvanyositottak volna, akkor nem lenne jo vilag, de amint ezt leirtam eszembe jutott, hogy hello, a GCN azert eleg vidaman el van alapvetoen hasonlo ISA-val azota is, az uj feature-oket meg az x86 vilagban is megkapjak a rendszerek, a nemtudomhanyezerfele SSE verzion, meg TSX, meg franctudja min keresztul. Szoval, van az a fejlettsegi szint, ahol teljesen jo ISA-t lehet definialni, aztan, hogy ki hogyan implementalja, az mar mas kerdes.
A HSA ISA is egy lehetseges megoldas erre, csak mivel eleg egyertelmu, h senki nem fogja kidobni a fo design-jait, elso korben csakis szoftveres eloforditas lehetseges. Aztan meg ki tudja. Anno meg Java byte-kodra is volt hardver epitve, az volt a Jazelle, nem? Ez annal azert ertelmesebb dolog.
[ Szerkesztve ]
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? 
Ú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.
