- AMD K6-III, és minden ami RETRO - Oldschool tuning
- NVIDIA GeForce RTX 4080 /4080S / 4090 (AD103 / 102)
- Nem indul és mi a baja a gépemnek topik
- Processzor árak megváltozása Windows 11-gyel
- Mini-ITX
- Azonnali VGA-s kérdések órája
- A manapság optimális specifikációkra törekszik az MSI QD-OLED monitorja
- Épített vízhűtés (nem kompakt) topic
- Autóhifi
- ThinkPad (NEM IdeaPad)
Hirdetés
-
Retro Kocka Kuckó 2024
lo Megint eltelt egy esztendő, ezért mögyünk retrokockulni Vásárhelyre! Gyere velünk gyereknapon!
-
F1 24 - Íme a végső gépigény
gp Akik a Champions Editiont vásárolták meg azok már játszhatnak a programmal.
-
A manapság optimális specifikációkra törekszik az MSI QD-OLED monitorja
ph 27 hüvelyk, 1440p, 240 Hz, Type-C és AI funkciók jellemzik dióhéjban a kijelzőt.
Új hozzászólás Aktív témák
-
LordX
veterán
"Tökéletesen illik az OpenCL-t és a C++ AMP-t koncepciójába"
Kicsit sok a -t
-
MCBASSTION
aktív tag
"A tagokat listáját ma már egyszerűbb"
elso bekezdes, tagok?am a 3. kepbol nekem az jott le, hogy ha most opencl-t hasznalok, akk gyakorlatilag ugyanott vagyok mintha hsa-t hasznalnek, nem?
vagy van vmi feature ami csak hsa-n lesz? Csak mert furcsa lenne, hogy ha az AMD ennyi kuszkodes utan otthagyna az opencl-t.mellesleg ez a mindenki utasithat mindenkit modell nagyon jo
windows7sins.org
-
Abu85
HÁZIGAZDA
válasz MCBASSTION #4 üzenetére
Köszi. Azt is javítottam.
Teljesítményben igen, csak a HSA garantálja, hogy mindenhol jó teljesítménnyel fut a programod, míg az OpenCL nem. Az OpenCL kód teljesítménye nem portolható. A HSA Bolt kódé igen.
Ami érdekes, hogy az OpenCL 2.0 elég sok hasonlóságot mutat a HSA-hoz.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
myckie2
őstag
Úgy érzem erről még fogunk párszor hallani a közeljövőben.
-
Prof
addikt
Kivancsi vagyok az Intel mikor es hogyan jon majd ebbe a kepbe
A Haswell/Iris kapcsan latszik, hogy mamutceg reven grafikai teljesitmenyben nagyon gyorsan tudnak gyors elorelepest produkalni.
Ha felvesznek jopar driver programozot bizony kelleni fog a nagy ossznepi osszefogas ellenuk, hogy megallitsak oket.[ Szerkesztve ]
-
Hmm..
Sehol egy Intel, vagy Microsoft (és Nvidia se... de a kínaiak ott vannak a fő csoportban, amin anno meglepődtem és még mindig.. a MediaTek-re nagyon kell figyelni)... bár szerintem kétségtelen, hogy ők lehetnek a legnagyobb vesztesei ezen "jövőképnek"..
Nélkülük nehezebben terjedhet el sajnos, de eléggé sok kicsi összegyűlt, így remélem lesz belőle valami.The human head cannot turn 360 degrees... || Ryzen 7 5700X; RX580 8G; 64GB; 2TB + 240GB + 2TB || Samsung Galaxy Z Flip 5
-
Fiery
veterán
"Ami érdekes, hogy az OpenCL 2.0 elég sok hasonlóságot mutat a HSA-hoz."
Pont Te irsz ilyet? ("erdekes") Nyilvan hogy van hasonlosag, hiszen a HSA alap nyelve az OpenCL. Tudom, lehet programozni majd 10 fele nyelven, de ugyis mindenki az OpenCL-t fogja valasztani... Mar csak azert is, mert megvan az az elonye, hogy az OpenCL-re fejlesztett programok futnak nem-HSA-s rendszereken is (pl. Intel).
-
Abu85
HÁZIGAZDA
A Microsoftot az Open Source rész riasztja el, de amúgy baromi sokat nyernek vele, mert a .net jó lesz a GPU-k programozására.
Az NV nyilván túl sok pénzt ölt bele a CUDA-ba, hogy beálljanak egy ilyen kezdeményezésbe.
Az Intel x86-ot akar mindenhova. Ez már eleve egy tetemes hátrány az architektúra fejlesztésénél, így egy ISA független platform nem kedvező a cégnek.Az NV szerintem idővel belép, mert a CUDA-nak a konzumer termékek oldalán már úgyis annyi, csak a sokszázmillió beleölt dollár van a józan ész előtt, de előbb-utóbbi rájön a vezetőség, hogy a piac nem az NV 2,5%-ára fog programot írni, hanem a MediaTek, a Qualcomm, a Samsung és ... 97,5%-ára.
A Microsoft valszeg nem lép be, de az előnyöket azért a Windowson belül kihasználhatják.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ezt pont kihangsúlyozták, hogy szerintük nem így lesz. A HSA független az OpenCL-től, csupán kiegészíti azt. Amiben a fejlesztők ezt jellemzően programozni fogják az leginkább Java és C++, de nyilván az OpenCL és a C++AMP sem akadály (meg más sem).
A Java és a C++ azért reális, mert a HSA-nak van legacy módja is. Ez garantálja, hogy a HSA-t nem támogató hardvereken is fusson az adott program. Viszont OpenCL-lel nem biztos, hogy érdemes tökölni, mert közel ugyanazt a teljesítményt egy magas szintű nyelvvel kihozod minden hardveren, viszont ötödannyi kódsorral.
Az OpenCL és a C++AMP azért jön elő, mert az ebben írt programok automatikusan profitálnak a HSA-ból. A C++ nem, míg a Java esetében elképzelhető a GPU-s gyorsítás a kód változtatása nélkül, de nem mindig.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az OpenCL programba nem csak az algoritmust kell beírni meg az egyéb részeket, hanem a másolásokat is, illetve a fordításra és az inicializálásra is figyelni kell. A HSA esetében ezek teljesen elhagyhatók, szinte csak az algoritmus kell.
A legtöbb párhuzamosítható algoritmus nagyjából annyi programsorból kihozható, mint az egy szálra optimalizált algoritmus C-ben. HSA nélkül a több szálra optimalizálás esetében be kellene vetni a TBB-t, illetve az Intrinsicset, de a HSA ezeket is kiváltja. Ha nincs IGP-d, akkor a HSA program gyakorlatilag negyedannyi kódsorral felmutatja ugyanazt a teljesítményt mint a TBB és az Intrinsics együtt.
Még a C++ AMP-hez képest is elég a feleolyan hosszú kódot írni, pedig az MS rendszerének pont ez az előnye.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Geri Bátyó
őstag
Remélem, hogy a Microsoft új vezetése észbe kap és végre a felhasználók érdekeit fogja nézni a saját (sokszor eléggé ostoba) elképzelései helyett. Hogyha meg akarják vetni a lábukat a mobil piacon (hosszú távon), kénytelenek lesznek a HSA mellé állni.
CUDA ide, vagy oda, az NV is kénytelen lesz lenyelni a békát, már csak azért is, mert az ARM-el való együttműködésre helyezik a jövőjüket.
Azt értem, hogy az Intel x86-ot akar mindenhová, de mivel nem értek a dologhoz, nem tudom, hogy ez miért befolyásolná azt, hogy támogassa a HSA-t? Nem lehet összehozni a kettőt? Nem tudná kihasználni a HSA előnyeit úgy, hogy közben megtartsa a saját fejlesztéseiben rejlő előnyöket?
"Ki a büdös istennyila vagy te bohócképű!?" SzŐr Geri, birodalmi poéta és főszakács (:L topic)
-
alevan
őstag
a HSA-t nem támogató hardvereken is fusson az adott program
A jelenlegi h/w között van HSA-t támogató (gondolok itt mobil és pc-re egyaránt)? Vagy ehhez megint új hardverek kellenek?
"Ezért lovagol a pokolba a konzumer IT piac. A hülye igények... . Azt sem tudod, hogy mit akarsz de az jöjjon havonta frissités formájában."
-
bitblueduck
senior tag
a CUDA-nak a konzumer termékek oldalán már úgyis annyi... a piac nem az NV 2,5%-ára fog programot írni, hanem a MediaTek, a Qualcomm, a Samsung és ... 97,5%-ára.
nem csak mobilalkalmazas letezik, CUDA szerintem a belathato jovoben lesz, max. nem a pistike end usernel lesz altalanos. meg HSA es tarsait sem erzem meg, hogy a mindennapjaim resze lenne, azt hiszem osszesen videolejatszashoz hasznalok gpgpu feature-oket. en annyira nem temetnem, mint az AMD.An open mind is like a fortress with its gates unbarred and unguarded.
-
Abu85
HÁZIGAZDA
válasz Geri Bátyó #14 üzenetére
Szerintem a Microsoft olyan irányba fejleszti a C++AMP-t, ahogy a HSA működik. Ezért nem akarnak belépni, és a C++AMP következő nagy frissítését a Windowsra korlátozzák. De a HSA elérhető lesz a Windowson is. Az MS sok dolgot nem támogat, de azok telepítésétől (például HSA runtime) nem zárkózik el. Ha a nyílt platformok engedélyezését nézzük, akkor még mindig az MS enged meg a legtöbbet a többiekkel szemben.
A HSA értéktelenné teszi az x86-ot. Ha megírod a programot, akkor az HSAIL-re fordul le, de alatta fizikailag bármilyen hardver lehet, és a program azon futni fog. Ez az IGP-s tervek szempontjából baj, mert oda is x86-ot akar az Intel, és amíg a többiek sűrűn lecserélik a parallel ISA-t, addig az Intelnek az x86 miatt extrém méretű gyorsítótárakat kell terveznie a lapkába.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz bitblueduck #16 üzenetére
A CUDA megmarad, de a HPC-piacra korlátozódik. A konzumer szinten nincs értelme a PC-ben és a mobilban is maroknyi részesedéssel rendelkező NV-t előnyben részesíteni a piac nagy többségével szemben. Már láthatod ennek a jeleit. Aki eddig CUDA-ra fejlesztett átállt OpenCL-re, és most jön az az időszak, amikor a CUDA-ra vonatkozó fejlesztéseket le is lövik, vagyis csak az OpenCL-re koncentrálnak az új funkciókkal. Az Adobe már mondta, hogy hosszútávon csak az OpenCL kódjukat tartják meg és fejlesztik tovább.
Ilyen szembeszéllel lehetetlen bármit is kezdeni. A CUDA lesz a következő zárt szabvány a történelemben, amit kivégez a nyílt alternatíva. Ezzel az a sorozat sem szakad meg, hogy a zártat mindig kivégzi a platformfüggetlen.
(#15) alevan: A teljes támogatáshoz új hardver kell.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Fiery
veterán
Latszik, hogy bekajaltad a marketing maszlagot. A masolas 2 sor (egyszer oda, egyszer vissza), annak megsporolasaval hogyan lesz 1/5 a kod? Oke, legyen plusz 2 sor amig elinditod a cuccot OpenCL-lel (clSetKernelArg, clEnqueueNDRangeKernel), legyen egy harmadik sor a lefutasra valo varakozas (clWaitForEvents). Maga az OpenCL felinicializalasa legyen 5 sor (clCreateContext, clCreateCommandQueue, clCreateProgramWithSource, clBuildProgram, clCreateKernel), a deinicializalas hasonloan 5 sor. Legyen nagyvonaloan az egesz OpenCL overhead a tiszta algoritmus kodon felul 25 sor, csak hogy a buffer inicializalasok is benne legyenek, es ne legyek annyira szorosszivu. Ehhez kepest egy AES encrypt/decrypt sample kernel (tisztan az algoritmus, egyenesen az AMD APP SDK-bol kivalasztva) 290 kodsor. Ugyanonnan egy vektorizalt Mandelbrot sample algoritmus 475 sor. Black Scholes 180 sor.
Hol lehet itt a kod 4/5-et megsporolni? Amikor maga az algoritmus nagysagrendekkel hosszabb kod, mint az OpenCL overheadje?
[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
Nem tudom, hogy a bristoli egyetemnek mi köze van a marketinghez. Általában az egyetemek nem szoktak marketingelni. Az a HSA alapítvány dolga. A kódsorokra vonatkozó dolgokat a cikkben nem a HSA alapítvány mondta a Hot Chipsen, hanem a bristoli egyetemnek volt egy korábbi prezentációja.
A copy és copy-back valóban kevés sor, de az inicializálás és a compile kitehet annyit, amennyit maga az algoritmus, sőt, többet is.
De eleve azt kellene megérteni, hogy már maga a HSA algoritmus is rövidebb, mint a feladat egyszálú verziója.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Fiery
veterán
Tehat az egyetem egy adott feladatra altaluk irt kodbol kiindulva allit valamit. Teny, hogy lehet olyan szemetre valo kodot irni, aminel az OpenCL API-t noszogatja az ember egesz allo nap, es parosit hozza egy 5 soros algoritmust, aztan vegul is lehet azt mondani, hogy az OpenCL overhead csokkentesevel toredekere esne a kod merete, de kapasbol az AMD sajat APP SDK-janak sample-jei sem tamasztjak ezt ala. Direkt nem a sajat OpenCL kodommal jottem elo, az AMD megiscsak jobb referencia...
"De eleve azt kellene megérteni, hogy már maga a HSA algoritmus is rövidebb, mint a feladat egyszálú verziója."
Szeretnék mar latni nehany konkret sample-t. Mikor lesz az APP SDK-ban egy "hsa" mappa is a "cl" mellett a sample gyujtemenyben? Akkor vegkepp ki fog derulni, mennyire igaz az 1/5. Amig se hardver (Kaveri), se SDK, se API, se sample, addig barki barmit mondhat.
-
atti_2010
nagyúr
A Haswell/Iris kapcsan latszik, hogy mamutceg reven grafikai teljesitmenyben nagyon gyorsan tudnak gyors elorelepest produkalni.
Az Iris önmagában semmire sem jó csak egy kirakatcikk amivel meg akarták mutatni hogy ők is tudnak gyorsabb IGP-t alkotni de tömegtermék sohasem lesz belőle, nem annak köszönheti a sebességét mert hű de okosan van megalkotva és milyen jól skálázódik hanem az eSRAM-nak amit az AMD is belerakhat vagy rakhatna bármikor a Kaveribe és 100x gyorsabb lenne, sokkal gazdaságosabban mint az Iris.
[ Szerkesztve ]
1.Asrock FM2A88X+ Killer,A10-5800K,Kingston 2x4Gb 2400Mhz,Int X25-V SSD,SF Pro S.F.-450P14XE. 2.MSI-A75A-G55,A8-3870, Kingston 2x2GB2000, MSI R9-270, Zen 400.
-
Abu85
HÁZIGAZDA
[link] - GitHUB HSA-Libraries
[link] - GitHUB HSA FoundationVannak benne példák is. Minden ami új ide kerül fel.
A példáknál ugyanaz a Hessian kernel el van készítve többféle programozási modellel. Trinity APU-n le is fut mindegyik, így a teljesítmény is összehasonlítható. Ez persze nem az egyetem példája, hanem az AMD-é. Publikus szinten csak ez van.(#22) atti_2010: Ha az Iris lenne az, amivel meg akarják mutatni, hogy tudnak IGP-t csinálni, akkor rosszul teszik, mert az pont arra példa, hogy nem tudnak. Elképesztő többlettranzisztor kell a GT3-nak a GT2-es dizájnhoz képest 10-20% extra sebességért. Kizárt, hogy az Intel ezt a képet akarja lefesteni magára a világnak. Az Iris az inkább próba, hogy merre tovább.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Fiery
veterán
Tok jo, itt csak HSA-s sample-k nincsenek Bolt van, de az nem egyenlo a HSA-val, az csak egy library nehany gyakran hasznalt algoritmushoz. A Hessian pelda pedig tok izgalmas, csak sajnos pont HSA implementacio nincs benne, ha jol latom; sot, Bolt sincs (printf ("NOT IMPLEMENTED\n")
-
Abu85
HÁZIGAZDA
Viszont ide kerülnek fel, tehát itt kell ezeket keresni. Majd az APU13 során lesz egy csomó bejelentés, és azzal jönnek rá a példák. Az előbbi oldalakon fent lesz. Az APP SDK-ba szerintem késéssel kerülnek majd bele.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Geri Bátyó
őstag
"De a HSA elérhető lesz a Windowson is. Az MS sok dolgot nem támogat, de azok telepítésétől (például HSA runtime) nem zárkózik el."
Végülis ez a lényeg! Nem kell feltétlenül a nevét adnia hozzá, de legyen meg a lehetőség a használatára.
Mondjuk mobiltelefon és tablet fronton lehet, hogy ennél többre lenne szükség."Ha megírod a programot, akkor az HSAIL-re fordul le, de alatta fizikailag bármilyen hardver lehet, és a program azon futni fog."
Ez elméletileg (laikusként) nem hangzik rosszul. Az a gond, hogy a különböző utasításarchitekturák és kiegészítések (pl: AVX) előnyei elvesznek?
Lehet, hogy csak én nem értem, de nem az van, hogy a programot az a hardver futtatja, ami a legjobb neki?"Ez az IGP-s tervek szempontjából baj, mert oda is x86-ot akar az Intel"
Nem az van, hogy ezt már elvetették, mert nem skálázható megfelelően? Az utóbbi időben mintha azt érezném a hírekből, hogy az Intel is más irányra vált és csak a HPC szegmensben lesznek x86 alapú gyorsítókártyák.[ Szerkesztve ]
"Ki a büdös istennyila vagy te bohócképű!?" SzŐr Geri, birodalmi poéta és főszakács (:L topic)
-
Fiery
veterán
-
Fiery
veterán
válasz Geri Bátyó #27 üzenetére
Valojaban senki sem tudja jelenleg, hogy az Intel hosszutavon, a mainstream es low-end PC szegmensben milyen architekturaju IGP-vel fog probalkozni. SZVSZ x86 alapon fog nyomulni, hosszutavon direkt GPU programozassal (ami Abu szerint hulyeseg), de hogy az mire lesz eleg, azt nem tudni.
-
Abu85
HÁZIGAZDA
A partnerek sokkal többet kapnak a HSA-ból, mint mi publikus formában. Ennek az oka, hogy a szabvány hitelesítése folyamatban van, tehát még változhat valami a 0.95-os specifikációkhoz képest, amit egyébként a programozók már átnyálazhattak.
A publikus elérhetőséggel megvárják az 1.0-s verziót. Tekintve, hogy elég fontos hibátlanra csinálni, így ez nem olyan rossz döntés.(#27) Geri Bátyó: Az biztos, hogy minimum SSE2-es proci nélkül a HSA program futtathatatlan. Fölötte nyilván támogatható az AVX2 is.
Az Intelnek jelenleg három iránya van a GPU fejlesztésre. Az egyik a MIC, a másik a mostani HD Graphics rendszer, míg a harmadik a ZiiLabs rendszere. Mivel a HD Graphics borzalmasan rosszul skálázható, így úgy gondolom, hogy a MIC és a ZiiLabs marad meg.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Meteorhead
aktív tag
Azonfelül, hogy nem túl szimpatikus, ha valaki xarja a spanyolviaszt, azért nem mernék ilyen határozott kijelentéseket tenni. (Hátmég ilyeneket)
Aki wrappelt már OpenCL C-t, az tudja, hogy milyen kib***ott verbose a kód. Mondhatod, hogy csak egy sor ez, és egy sor az, de egy vér egyszerű szimulációs kernel hívás sort (4 kernel egymás után), init részben 1920*1080 felbontásban VS-ben több mint egy oldal csak a setKernelArg()!!! És akkor még nincs platform-device-context init, device paraméterek lekérdezése, compile time constansok beállítása, kernel kód módosítás, kernel fordítás, kernel preference lekérdezések, work-group size-ok beállítása a kernel preferenciák alapján, buffer létrehozás/init, kezdeti adatmásolás, és hadd ne mondjam mi kell még, ha ez az egész OpenGL interoppal megy!! A francba, már leírni is hosszú! Egy valamirevaló interop context létrehozásához tüzeskarikákon kell átugornia a programozónak, mire Windows-Linuxon működik. Kódban meg 800-1000 sor csak az init ha performance portable módon akarod megírni. És ha belekezdenék abba, hogy mi lesz itt OpenCL 2.0-val, amikor még azt is lekérdezed, hogy milyen SVM (Shared Virtual Memory) modellt támogat az adott HW, az alapján válogatod össze az eszközöket, és potenciálisan k*****ra mást kell csinálnod aszerint, hogy milyen memóriakoherenciát használhatsz host-device és device-device között... Még egy Adobe méretű cég sem szeretne azért kódereket etetni, hogy ilyenekkel töltsék az idejüket.
Szóval aki azt mondja nekem, hogy nem lesz 4/5 a kód C++AMP-ban, HSA Bolt-ban, vagy bármilyen más magasabb szintű cuccban, az még nem írt performance portable OpenCL kódot, márpedig arra lett kitalálva. Meg tudja csinálni, de rohadtul fáj.
Nincsenek arra szavak, hogy mekkora könnyedség, ha az összes STL tárolónak van GPU kompatilibis verziója. OpenCL 2.0 nagyon intelligensen kipécézett egyet, a FIFO-t. Hát gratulálok. Van még másik 8-10 ami hasznos. A kód attól lesz 4/5, hogy nincs ez a buzi sok init, hanem ez mind AUTOMATIKUSAN megy. Nem mind, de a túlnyomó része.
-
Fiery
veterán
Furcsa, mert kozben meg elozetes (provisional) kiadasban kiadjak az OpenCL 2.0-t, pedig az sincs me'g veglegesitve.
"programozók már átnyálazhattak."
Az a HSAIL compiler irashoz hasznos, nem a fejlesztok szamara, akik HSA-ra akarnak fejleszteni. Ne keverd a kettot. A HSAIL a fejlesztoket baromira nem erdekli, az csak a compiler irokat erdekli.
"A publikus elérhetőséggel megvárják az 1.0-s verziót."
Csak kozben a fejlesztok nem kapnak semmit, nem tudnak elkezdeni dolgozni. Mire varnak? Ha ennyit toketlenkednek, akkor a Kaveri rajtjara nem lesz keszen semmi.
[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
Persze. Az azért van kiadva publikusra, hogy az open source közösség dolgozzon rajta.
Aki akar HSA programot, az elmegy az AMD-hez, elmondja, hogy mit csinál, és az AMD odaadja neki a toolokat. Amíg nem lesz kész az 1.0 spec, addig ez a rendszer így zajlik. Egyrészt azért, hogy az AMD rajta tartsa a felügyeletét a programon. De egyébként az ARM is ugyanígy odaad bármit bárkinek, de első körben felügyelik.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
ukornel
aktív tag
Valaki, csak hogy én is értsem...
Ha mondjuk végeselemes szimulációt futtatok, videót, képet buzerálok, abban hogyan fog segíteni a HSAIL?
Új, HSA kompatibilis Photoshop, Comsol, Virtualdub vagy Sony Vegas stb. verzióra kell várnom, vagy elegendő drivert, APIt, keretrendszert, mittoménmit frissíteni, és a meglevő alkalmazás is kihasználhatja az IGP adta erősítést? -
Fiery
veterán
válasz Meteorhead #31 üzenetére
Amit leirtal, abbol egy csomo mindent nem fogsz tudni meguszni HSA-val sem. Nyilvan lesz olyan kod, amikor sokat lehet sporolni, de azert ne mondjuk mar ki altalanosan, hogy 1/5-ere esik a kod merete csak azert, mert HSA-ra valtunk. OpenGL-OpenCL interopnal talan lesz ilyen, igen, talan az Adobe cuccoknal igen. De nem mindenhol, kozel sem.
"Kódban meg 800-1000 sor csak az init ha performance portable módon akarod megírni."
Ezt nem fogod tudni meguszni teljesen HSA-val sem. Ha optimalizalni akarsz, akkor a HSA onmagaban keves lesz, mert maga a platform nem fog a hatterben _mindent_ szénné optimalizalni. Mar most is latszik, hogy ha pl. az OpenCL-re hagyatkozol, hogy megtegye helyetted a _CPU_ optimalizaciokat (pl. vektorizacio, AVX es tarsai), akkor vagy lassu lesz a compiler ido, vagy a kod maga rohadt lassan fog futni egy igazi kezi optimalizaciohoz kepest.
Persze lesz arra lehetoseg, hogy irjon az ember egy 10 soros kodot tok gyorsan, es aztan az lefut majd a CPU-n meg a GPU-n, de ettol nem varnam azt, hogy az kivaltson egy letezo teljesitmeny optimalizalt kodot. Arra persze jo lesz, hogy atlagos programozok CPU-rol at tudjanak allni GPU alapu programozasra, es igy nyerjenek futasidot.
[ Szerkesztve ]
-
Fiery
veterán
válasz Meteorhead #31 üzenetére
"Szóval aki azt mondja nekem, hogy nem lesz 4/5 a kód C++AMP-ban, HSA Bolt-ban, vagy bármilyen más magasabb szintű cuccban, az még nem írt performance portable OpenCL kódot, márpedig arra lett kitalálva. Meg tudja csinálni, de rohadtul fáj."
En azt irtam, hogy a 4/5-et nehez lesz megsporolni csupan a HSA-ra valtassal. Nem azt irtam, hogy az 1/5-et nem lehet megsporolni.
-
Fiery
veterán
"Aki akar HSA programot, az elmegy az AMD-hez, elmondja, hogy mit csinál, és az AMD odaadja neki a toolokat. Amíg nem lesz kész az 1.0 spec, addig ez a rendszer így zajlik. Egyrészt azért, hogy az AMD rajta tartsa a felügyeletét a programon."
Oke, megtettuk, meglatjuk, hogy az AMD mennyire figyel oda a fejlesztokre, es valojaban mennyire is van kesz a HSA spec/API.
-
LordX
veterán
-
Meteorhead
aktív tag
Ez az egész ott egyszerűsödik le, hogy sokkal több lehetősége van a compilernek, meg a finalizernek.
Vegyünk egy kutya közönséges feladatot: rácsszámolás. (Mondhattam volna képfeldolgozást is, de fizikus vagyok, úgyhogy az én szótáramban az rácsszámolás) Az ember megírja szépen paraméteresen a kernelt, hogy használjon shared-et, és akármekkora lehessen egy munkacsoport. Megírja az initet (a munka mérete adott), csak a munkacsoport kérdés, mekkora legyen. A PREFERRED_KERNEL_WORKGROUP_SIZE lekérdezést rohadtul nem érdekli a __local memória mérete. Az csak azt nézi mennyi regisztert használsz. Aztán mire az ember megírja, hogy milyen dimenzió mentén szeretne terjeszkedni a munkacsoport (hogy coalesced maradjanak a memóriaműveletek), de beleférjen a __local-ba, és a lehető legnagyobb legyen a munkacsoport, de nem nagyobb, mint amit támogat... mire ezt az egy függvényt megírom hiba nélkül, addigra megőszülök. Ez nem egy ritka eset, egy sima játékprogramba minden post-process effekthez kell egy ilyen számolás, vagy akármi. 2D rács az egyik leggyakoribb eset.
HSA-tól azt várom el, hogy az ember megírja ezeket paraméteresen, és a finalizer lesz, aki megmondja, hogy mekkora legyen a work-group az alapján, hogy milyen a memory access pattern, és milyenek a device képességei. Lehet, hogy nem a legjobbat fogja mondani, de ha egy OpenCL kód 80%-át ki tudja hozni teljesítményben, akkor bármikor elcserélem arra, hogy a fejlesztési idő a 30%-a legyen az OpenCL-ének.
Az optimalizációról pedig csak annyit, hogy most épp azzal szívok, hogy rácsot kézzel vektorosítani runtime típusokkal (DEVICE_PREFERRED_FLOAT/DOUBLE_VECTOR_WIDTH) alapján használok más-más szélességű vektorokat a kernelben, amik más-más rácspontokat jelentenek, és ezekhez dukál ugye trükkös indexer, illetve az előbb ecsetelt workgroup-size kalkulációnak egy még trükkössebb verziója.
-
Meteorhead
aktív tag
Igen, én írtam el, bocsánat.
Szóval szeirntem nem ritkán lesz a kód 1/5 méretű. Kernele válogatja, de egy sablon kernel 100-200 sor hosszú, egy hozzátartozó jó init meg ~800. Ezek az én tapasztalataim. Az egy másik kérdés, hogy az említett problémámban 3Ds ritkamátrixszorzás van, meg 2D rács RK4-gyel rém elbazsevált peremfeltételekkel, és ez a kernel valóban 800 sor, de ez elég ritka.
(Még küldtem is bugot AMD fórumra, hogy a CodeXL annyira lassan indexelte a kernel kódot sytax highlightra, hogy használhatatlanná vált az IDE. Írták, hogy egy kicsit tuningolnak rajta, hogy ne ilyen legyen. Ezzel csak azt akartam mondani, hogy 800 soros kernel már közel "nem rendeltetésszerű használat".)
-
Fiery
veterán
válasz Meteorhead #39 üzenetére
Csak aztan nehogy az legyen az egeszbol, hogy megjon vegre a HSA, portolod a meglevo kodot (az se lesz 5 perces fejlesztoi ido), es kiderul, hogy 50%-a lesz a teljesitmeny az optimalizalt OpenCL-enek -- mikozben elvesz egy csomo lehetoseget arra, hogy sajat szajizedre optimalizald a platform mukodeset Aztan jon majd a kovetkezo igeret az AMD-tol, hogy hamarosan jobb lesz a platform, jobb lesz a HSAIL compiler, stb. stb. Ilyen igeretekbol mar a HSA-hoz kepest tok egyszeru OpenCL compiler bugok kapcsan is tele a padlas nalunk. Olyan egyszeru dolgot nem kepesek a compilerek kezelni mar most sem, hogy "a = b * a + b", ha "veletlenul" az "a" es "b" valtozok integerek. Rohej. Erre huz ra az AMD egy ujabb reteget, sok joval kecsegtet ez
-
Geri Bátyó
őstag
+ (#29) Fiery
Hogyha jól értem, akkor az Intelnek CPU terén semmiféle hátránya nem származik a HSA-ból, mert a különböző "trükkjeiket" ugyan úgy támogatja (támogathatja).
Viszont. IGP terén, még ők sem tudják, hogy mit akarnak, mert 3 különböző megközelítésük van, amiből az egyik, valószínűleg zsákutca (HD Graphics), a MIC jelenleg csak HPC szegmensben működik, valamint a ZiiLabs megoldása, ami még (számukra) kiforratlan és ráadásul a többi gyártóhoz képest eltérő megközelítést alkalmaz. Ráadásul nem is igazán elterjedt.
Jelenleg 2 döcögős rendszerük van, amiből a MIC, nem biztos, hogy profitál a HSA-ból (hogyha jól értelmezem), viszont a ZiiLabs-os megoldásnak jól jönne.
Talán az Intelnek (és a Microsoftnak is) rá kellene döbbenni, hogy már nem ők diktálnak és akkor meg tudnák tartani a piaci részesedésüket úgy, hogy nem tolnak ki a felhasználókkal és a fejlesztőkkel."Ki a büdös istennyila vagy te bohócképű!?" SzŐr Geri, birodalmi poéta és főszakács (:L topic)
-
Fiery
veterán
válasz Geri Bátyó #42 üzenetére
Az Intel pont hogy nem tolna ki a fejlesztokkel, ha direkt GPU programozast huznanak elo a kalapbol x86 alapon. Mar egy masik topicban kifejtettem a viziomat, amibol siman lehet, hogy semmi sem lesz, es valojaban az Intelnel sem igy gondoljak. De ha meg megis ugy lenne, akkor azzal az Intel nagyot tudna lepni az IGP szegmensben, legalabbis ha a compute vonalat nezzuk (a jatekok engem speciel nem izgatnak, legalabbis a 3D rendering resze).
-
Geri Bátyó
őstag
Belenéztem a topicba, de nem olvastam végig, mert az nekem magas!
Laikusként: A direkt GPU programozás nyilvánvalóan jó, de bonyolult, mert minden hardverre eltérő kódot kellene írni, ami a fejlesztőknek nem jó. A HSA előnye pont az, hogy egységes körülmények között lehet kvázi optimalizált kódot írni, ami csak a gyártó által írt drivertől függ.
A HSA emellett viszont a heterogén programozást is lehetővé teszi, amit a direkt GPU programozás esetén nem lenne járható út.
A játékok engem sem hatnak meg, mert évek óta nem játszottam, de a gyártóknak ezt is figyelembe kell venni.(#47) Abu85: Mégsem vagyok olyan ostoba, mert (tulajdonképpen) ezt írtam én is! Igaz, belőlem csak a józan paraszti ész és nem a hozzáértés beszélt.
[ Szerkesztve ]
"Ki a büdös istennyila vagy te bohócképű!?" SzŐr Geri, birodalmi poéta és főszakács (:L topic)
-
Abu85
HÁZIGAZDA
Dehogynem tolnának ki. A fejlesztőknek direkt programozás mellett nem egyszer kellene megírni a programot, hanem úgy nagyjából 10-szer, és akkor még nem számoltuk bele azokat az architektúrákat, amelyek a program megírása után érkeznek, és az alkalmazás nem fog elindulni rajtuk.
Ha ma írsz egy programot, és direkten a forgalomba lévő hardverekre, akkor az Intelnek van 2 eltérő HD Graphics architektúra, és van a MIC, az AMD-nek van 3 eltérő architektúrája, míg az NV-nek kettő. Összesen 8 hardverre kell célozni a programot, és amint megjön a Maxwell máris nem fog futni rajta, mert arra is meg kell írni. Bárki találta ki ezt a direkt GPU programozás dolgot, világosan látszik, hogy gőze sincs hozzá, hogy a fejlesztők mit szeretnének. Még a GPU tervezéshez sem érthet.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Fiery
veterán
En a direkt programozasnal arra gondolok, hogy arra az adott architekturara lenne jobb nekik programozni, osszevetve egy HSA vagy OpenCL alapu programozassal, ami most van (ill. a HSA csak lesz, majd, talan, egyszer ).
A HSA-ra valo programozas egyebkent mar csak azert is erdekes kerdes, osszevetve valami direkt megoldassal, mert az alapitvanynak nem tagja sem a Microsoft, sem az nVIDIA, sem a Google, sem az Intel. A VIA-t asszem zarojelbe lehet tenni, de mintha ok sem lennenek tagok. Ergo a Windows nem fogja kulonosebben tamogatni, a WP-vel egyetemben -- persze blokkolni sem fogjak a runtime-ot. Az Androidban a Google mar most is sz**ik az OpenCL-re, nem latom, hogy miert valtoztatnanak ezen, persze idovel meggondolhatjak magukat. Az nVIDIA vagy ragaszkodik a CUDA-hoz, vagy nem, ezt me'g nem tudni, de emiatt teljesen kerdojeles, hogy mi lesz az nVIDIA dGPU-kkal HSA alatt. Az Intel meg aztan vegkepp kerdojeles. Ha ezeket osszeadjuk es atnezzuk, akkor nagyjabol az jon ki belole, hogy PC-n (esetleg konzolon), Windows alatt, AMD CPU-n es AMD iGPU-n (es valamennyire AMD dGPU-n) tok jol fog remelhetoleg mukodni a HSA, de azon kivul barmilyen vasat vagy oprendszert veszel, barmi tortenhet. Nekem ez is elegge behatarolt fejlesztesi platformnak tunik, nem kevesbe mint a direkt GPU programozas -- csak a HSA nem olyan hatekony eleve. Vagy az AMD sajat maga fog garanciat adni a fejlesztoknek arra, hogy mondjuk az nVIDIA vagy az Intel compilerei megfelelo minoseguek lesznek, mikozben ezek a cegek ugy fognak dolgozni, mint ha a fogukat huznak?
[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
Az OpenCL-t meg a HSA-t meg ezeket itt nem érdemes belekeverni. Itt tényleg csak arról van szó, hogy minden GPU-t tervező cég nagyon sűrűn cseréli az ISA-t. Ez nem olyan, mint a CPU, hogy évtizedekig alapozhatsz ugyanarra, illetve azt fejlesztheted. A GPU-k esetében a párhuzamosságot és a skálázhatóságot nem a hardverbe, hanem az ISA-ba tervezik bele. Köré épül majd a hardver. Ha az adott ISA elérte a határait, akkor terveznek egy jobb parallel ISA-t, amire jobb hardvert lehet építeni. Ezt mindenki így csinálja, mivel más módon, például egy skalár ISA tervezésével, és az arra való építkezéssel extrém méretű lesz a hardver, mert a skálázhatóságot gyorsítótárakkal kell biztosítani. Nem pár kB-tal, hanem MB-os, illetve később GB-os összmérettel.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
Új hozzászólás Aktív témák
- Milyen okostelefont vegyek?
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Moderátort keresek a fórumhoz!
- Székesfehérvár és környéke adok-veszek-beszélgetek
- PlayStation 5
- Törvénnyel pörgetné fel az európai zöldtechnológiát az EU
- NVIDIA GeForce RTX 4080 /4080S / 4090 (AD103 / 102)
- Politika
- Fotók, videók mobillal
- Helldivers 2 (PC, PS5)
- További aktív témák...
- Beszámítás! Intel Core i9 11900KF 8mag 16szál processzor garanciával hibátlan működéssel
- Beszámítás! Intel Core i7 4790 4mag 8szál processzor garanciával hibátlan működéssel
- Beszámítás! Intel Core i7 4790K 4mag 8szál processzor garanciával hibátlan működéssel
- Beszámítás! Intel Core i3 8100 4mag 4szál processzor garanciával hibátlan működéssel
- ÚJ, Bontatlan AMD Ryzen 7 7800X3D
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Ozeki Kft.
Város: Debrecen