- Igencsak szerény méretekkel rendelkezik az Aetina Xe HPG architektúrás VGA-ja
- Miniképernyős, VIA-s Epomaker billentyűzet jött a kábelmentes szegmensbe
- Különösen rendezett beltér hozható össze a Cooler Master új házában
- A középkorra és a pokolra is gondolt az új AMD Software
- Új gyártástechnológiai útitervvel állt elő a TSMC
- Vezetékes FEJhallgatók
- Házi barkács, gányolás, tákolás, megdöbbentő gépek!
- Milyen monitort vegyek?
- Hobby elektronika
- Milyen alaplapot vegyek?
- Milyen SSD-t vegyek?
- OLED TV topic
- Xiaomi Mi Box androidos médialejátszó 4K és HDR támogatással
- Sony MILC fényképezőgépcsalád
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
Hirdetés
-
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.
-
É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.
-
Különösen rendezett beltér hozható össze a Cooler Master új házában
ph A 49,73 literes térfogatú, látszólag jól szellőző modell tárt karokkal várja a konnektoraikat rejtő ASUS és MSI alaplapokat.
Új hozzászólás Aktív témák
-
Fiery
veterán
"Azt nem értem ha 256bites memoriavezerlö van benne"
Ez csak Abu teoriaja, nincs ra semmilyen bizonyitek. Ami biztos, hogy a Kaveri memoriavezerloje 4 particiobol all, ami az eredeti tervek szerint 2x64 bit vagy 4x32 bit modban uzemelt volna, es az utobbi lett volna a GDDR5. Soha nem volt szo 256 bites aggregalt savszelessegrol.
A memoriavezerlo szelessegenek kerdese pedig uzleti alapon szuletett dontes: erre, a mostani megoldasra van a legnagyobb igeny, ezt lehet eladni abban a szegmensben, ahol a Kaveri "focizik".
[ Szerkesztve ]
-
Fiery
veterán
Az SDK biztositasa nem eleg, a fejlesztoket ra is kell(ene) venni arra, hogy egy olyan termekre tanuljanak meg uj eszkozokkel fejleszteni, ami nem piacvezeto. Az SDK-nal pedig azzal is maga allat vagta/vagja a fat az AMD, hogy nem hazon belul keszul a GPGPU felulet (OpenCL), mint az nVIDIA eseteben. Ergo az OpenCL roadmap is megkototte az AMD kezét: az OpenCL 2.0 specifikaciot alig sikerult idoben veglegesiteni, de a header-ok pl. me'g mindig nem publikusak. Me'g mindig kell par honap, mire a software stack kiforrja magat, a fejlesztok pedig me'g mindig nem mozgolodnak eleg alaposan. Az AMD ambiciozus, az biztos, de sok apro darabbol all a HSA puzzle
-
Fiery
veterán
A nem publikus SDK-t ugy hivjak, hogy alpha meg korai beta allapotu SDK Nem veletlen, hogy csak a partnerek kaphatjak meg. Ha kiforrott SDK lenne, akkor ugyanolyan nyilvanos lenne, mint mondjuk az APP SDK. Sz'al maradjunk annyiban, hogy van is SDK meg nincs is, de leginkabb nincs, egyelore.
-
Fiery
veterán
"Az OpenCL 2.0 nem gond. Az OpenCL 1.2-höz lesz számos HSA extension"
Igen, ezt hivjak takolasnak. Az AMD erre a takolasra azert kenyszerult, mert az OpenCL 2.0 nem keszult el idoben.
"Sőt, a HSA-nak lesz olyan kiegészítése is, ami az eddig írt OpenCL alkalmazásokat automatikusan a HSA hardver előnyeivel futtatja."
Igy van, marmint ha arra gondolsz, hogy az SVM nelkuli HSA elonyoket kihasznalhatjak az OpenCL 1.x szoftverek.
"Többek között így fut az Aftershot Pro. Ehhez az aktuális kód módosítására sincs szükség, egyszerűen out-of-box működik."
Igy igaz, csak mondjuk ahhoz kellene egy kiforrott OpenCL --> HSAIL fordito is (ami 1 honapja me'g nem volt), meg az is, hogy az adott szoftver oly modon hasznalja az OpenCL-t, hogy a HSA valoban elonyt tudjon hozni. Ahhoz pedig az kell, hogy pl. sok gyorsan lefuto kernel hivas legyen. Egy tipikus OpenCL 1.x szoftvernek jelen allas szerint nem elonyt, hanem hatranyt hoz a HSA SDK. Ez persze hamar javulni fog, ahogy a HSAIL fordito kiforrja magat, vagy ha a szoftvereket atviszik SVM compliantra. A problema ez utobbival csupan az, hogy ha egy eljarast mar eleve OpenCL 1.x-re (nem SVM-es architekturara) optimalizaltak/portoltak, akkor ott sok esetben az SVM mar nem hoz gyorsulast.
[ Szerkesztve ]
-
Fiery
veterán
Kezdjuk ott, hogy eleg vicces azt latni, hogy lebutazod az x86 processzorokat, holott a performance orientalt szamitasi feladatok oroszlanreszet manapsag otthon is es a szervertermekben is x86 alapu gepek vegzik. Raadasul, azokat a feladatokat egyetlen GPU-val sem lehetne rendesen, ertelmesen elvegeztetni, akarki akarmit is mond. Nyilvan vannak olyan feladatok, amikben egy GPU (vagy egy APU) nagyon jol teljesit, de ugy nagy altalanossagban nem hasznalhatoak processzorkent.
A Celeron meg Pentium pedig nem csak most, a Haswell eseteben, hanem mar az elozo generacioknal is mindig "faziskesessel" jutott el a boltokba. Ennek egyszeru piaci okai vannak, pl. az, hogy a regi gyartosorokat nem fogjak csak ugy egyik naprol a masikra leallitani csak azert, hogy 10 Ft-ot keressenek egy Celeronon... A regi gyartosorok ontjak tovabb az elozo generacios Celeronokat es Pentiumokat, mig az uj gyartosorok nyomjak a Core i3/i5/i7 procikat.
-
Fiery
veterán
"Az X86 architektura koros, roghozkotott voltara celoztam, ha nem lett volna vilagos."
Attol, hogy valamit regen talaltak "fel", me'g nem sz*r vagy elavult. Lasd Porsche 911, ha mar az autokat hoztad elo analogianak.
Probalj meg egy Windowst bebootolni egy nem-x86 GPU-val. Vagy probalj HSA applikaciot futtatni x86 processzor(magok) nelkul. Vagy ugy altalaban csak mutass egy nem-x86 CPU architekturat, ami a mobiltelefonoktol a tableteken es a notebookokon at egeszen a 8 utas szerverekig skalazodik, es igy szinte barmire **rva jol fel lehet hasznalni.
-
Fiery
veterán
Erre me'g senki sem tudja a valaszt, mivel a Mantle még nem keszult el. Majd ha vegre elkeszul, es lesz mellesleg egy kesz Mantle-s jatek is, akkor a review site-ok le fogjak velhetoen ezt is tesztelni.
De egy 7850K eseteben egesz komolyan az foglalkoztat, hogy jatek kozben mennyit fogyaszt? Ez miert olyan fontos? Egy notebooknal me'g talan ertenem a dolgot, de egy jatekra epitett desktop PC-nel a jatek kozbeni fogyasztas nem szabadna, hogy ilyen erdekfeszito kerdes legyen Az FPS erdekes kerdes, az idle fogyasztas szinten (amikor nem jatszol, akkor ne zabaljon sokat).
-
Fiery
veterán
A HSA-ra nem kell ugrani. Egy OpenCL (OpenCL 1.x) kodot valtoztatas nelkul tud futtatni egy HSA-compliant rendszer. A HSA SVM reszere (megosztott memoria) erdemes plusz optimalizaciokkal eloallni, azzal sokat lehet adott esetben nyerni -- csak kerdes, hogy ha a piac 80%-a (Intel CPU-k) nem tamogatja az SVM-et (a hardver hianyossagai miatt), a maradek 20%-bol meg csak a Kaveri (ami jelenleg legyen 0,1% az osszes PC-t nezve), akkor mennyire erdemes kulon foglalkozni az SVM-mel. Nyilvan ez a szitu valtozni fog, hiszen egyre tobb Kaverit fognak eladni, de az osszes PC-re vetitve az SVM-et tamogato rendszerek reszesedese akkor is csak nagyon nehezen fogja elerni a 10%-ot. Ami me'g mindig elenyeszo, sajnos.
Megint mas kerdes persze, ha egy adott szoftver adott reszet eddig azert nem vitte at a fejleszto ceg GPU-ra, mert tul bonyolultnak tunt SVM nelkul megoldani ezt, es most kapva kap az alkalmon, hogy vegre meg lehet ezt oldani. Ez esetben nagyon sokat lehet nyerni az SVM-mel (HSA-val), csak kerdes, hogy hany olyan ceg lesz, aki ezt meg is lépi. Az AMD az ilyen szoftver fejleszto cegeket probalja gyozkodni, hogy alljanak neki a melonak. Hamarosan kiderul, hogy mit eredmenyez ez.
[ Szerkesztve ]
-
Fiery
veterán
válasz #32839680 #478 üzenetére
Hol fikaztam a GCN-t? Az IA-64-et fikaztam.
"A HSA alakulása érdekes lehet, az már biztos, hogy ahol először sikereket fog elérni, azok a mobilok/tabletek"
Szerintem meg az x86 PC-n fog eloszor sikereket elerni, mar csak azert is, mert utcahosszal vezet az implementacio az ARM-hoz kepest. Kapasbol mar boltokban lehet kapni a Kaverit, tehat van vas, es van betas HSA stack is. ARM-ra meg mobilokra nagyjabol tervek vannak, mas nem.
"A heterogén játékok/alkalmazások fejlődését, pedig pont az Intel hátráltatja"
Nyilvan nem veletlenul van ez igy. Es nem hatraltatjak, csak nekik mas oltetuk van, es inkabb azon dolgoznak. Ennyi erovel az Intel is mondhatna azt, hogy ha az AMD oket hatraltatja a HSA-val, miert nem inkabb az AVX-et eroltetik?
"és ne akarjon az IGP egy VGA-t kiváltani"
Dehogynem! Pont ez a lenyege. Tunjon el a francba a belepo szintu dVGA, maradjon meg a felso 2 regio (HD78xx, HD79xx peldaul), es kesz. Legyen brutal eros az IGP is, ugy pl. sokkal jobban lehet notebookon vagy tableten jatszani. Ebbe az iranyba megy minden gyarto amugy is.
-
Fiery
veterán
"A gyártó, ha feláldozná a kompatibilitást a sebesség oltárán, akkor a mérnököknek egyszerűbb lenne sokkal a gyorsabb hw fejlesztése."
Ha ez ilyen egyszeru es egyertelmu, akkor miert nem csinalja ezt az Intel es az _AMD_ is? Ha ez ilyen egyertelmu, akkor miert nem lett atuto siker az Itanium? Miert buktak meg olyan architekturak, mint az Alpha? Es miert nincsenek ARM alapu notebookok, asztali gepek ill. szerverek tomegevel?
-
Fiery
veterán
"Telejesen irrelevans hogy mibol mennyit adnak, el hanyan hasznaljak."
Irrelevans? Az alacsony eladasok miatt mennek tonkre a cegek altalaban... Es ezzel mennek sokszor a fejlett vagy kevesbe fejlett technologiak is a kukaba
"Meg mindig nem valaszoltal ra miert koltot az Intel milliardokat Itaniumra ha olyan jo volt a sajat slagertermek X86"
Pont azert, mert ok is azt hittek, hogy a fejlettebb architektura at fogja venni az x86 helyet. Nem jott be, elk**tak Mondjuk ebben az AMD-nek is volt vastagon szerepe, de a vegen mi, a juzerek nyertunk ezzel is.
"Ok hivhatod X86-nak a Knights Landinget is"
En nem akarok semmit semminek hivni, de ha egyszer x86 architekturara epul, akkor az x86, es nem IA-64 vagy ARM vagy barmi mas.
"annak ellenere, hogy :“X86 specific logic <2% of core+L2 area” "
Ugyanez igaz minden modern x86 processzorra: maga az x86 specifikus vegrehajto resz elenyeszo szinte a teljes die area-hoz viszonyitva. A legtobb helyet es energiat manapsag mar a GPU, uncore es a cache-ek (L1-L4) viszik el. Meg persze nemileg az x86 SIMD (AVX, AVX2), de ugye Abutol tudjuk, hogy azt ugyse hasznalja ki senki Pont ezert hulyeseg egy adott x86 processzort azert fikazni, mert x86: ennyi erovel lehetne mas is, attol nem lenne jobb vagy rosszabb.
"Gyakorlatilag csak a kompatibilitasert van benne."
Uramatyam... Erre mar nem tudok mit mondani.
[ Szerkesztve ]
-
Fiery
veterán
válasz #32839680 #533 üzenetére
"Mindenki belátja hogy ez az egyetlen járható út"
Az Intel mikor mondott ilyet? Az, hogy az AMD kapcsan a csapbol is a HSA meg heterogen szoveg folyik, es hogy az nVIDIA is effele megy, me'g nem jelenti, hogy mindenki ugyanarra megy. Az x86 CPU-piac 80+%-at uralo ceget meg eleg furcsa lenne ignoralni a kepletbol. Plane mivel a Knights Landing kapcsan eleg egyertelmuve tették, hogy merre akarnak menni hosszutavon -- es nem, nem arra, amerre az AMD
-
Fiery
veterán
válasz #32839680 #538 üzenetére
"az Nvidia is tökmind1 mit mond, a GCN-hez hasonló GPU-ra törekszik."
Ezt honnan tudod? A legutobbi pletyka me'g egy VLIW-es architekturarol szolt, ami pont nem GCN, hanem az ATI eredeti TeraScale architekturajahoz hasonlithat (meg persze az Itanichoz )
"Viszont a konkurencia mit tud felmutatni?"
Peldaul egy csomo rendkivul sikeres termeket a kulonfele szerverekbe?
"Nyilvánvaló hogy nem lehet magokat növelni"
Ezt pont most mondod, amikor a socketenkent 15 magos Ivy Bridge-EX a kuszobon van? Vagy ha a desktopra gondolsz, az oke, csak a desktop meg kozel sem minden, van me'g egy csomo szegmense a szamitogep iparnak.
"értelmes keretek között az egyszálas teljesítményt sem"
Erdekes, hogy megis tudjak novelni, csak mondjuk SIMD feldolgozo egysegekkel. Es felettebb erdekes, hogy az AMD is ugyanerre megy, sot: az alacsonyfogyasztasu szegmensben (Kabini/Temash) ok leptek meg elobb az AVX-et, es nem az Intel. Az AVX2-t is berakjak a Carrizoba, mikozben azt kommunikaljak, hogy a 256 bites SIMD egysegeknek semmi ertelme. Akkor minek rakjak be?
"a csíkszélességet sem éri meg csökkenteni"
Erdekes, az Intelnek megeri...
"előbb utóbb elveszik a CPU nyers erőből fakadó teljesítményük"
Ami megvan mint teljesitmeny, az hogyan veszik el?
"ha a feladatok egy része átkerül az IGP-re amit az sokkal hatékonyabban képes futtatni."
Es mi van, ha kozben az Intel IGP eroben is beeri a konkurenciat? Nezzuk csak meg, mekkora leptekkel fejlodtek az Intel iGPU-i az utobbi 5-6 evben: ha csak feleennyire is tudjak tartani a felzarkozas tempojat, akkor hamarosan bajban lesz a "csodalatos" GCN. Ami egyebkent egy tok jo architektura, csak az AMD -- szamomra legalabbis furcsa modon -- mindent attol tesz fuggove, a teljes jovojet a GCN-re teszi fel. Ami persze bejohet, nagyot nyerhetnek vele; de ugyanigy el is bukhatnak mindent, ha az iparag megsem arra megy, amerre az AMD gondolja/szeretné.
[ Szerkesztve ]
-
Fiery
veterán
válasz #32839680 #549 üzenetére
"Fura, én úgy tudom hogy a Parker SoC miatt ugyanúgy heterogén felhasználásban jól skálázódóra lett tervezve, ami logikus is, mivel a Parker full olyan lesz mint a Kaveri most, csak ARMv8 magokkal."
De ki mondta, hogy egy heterogen megoldashoz GCN kell, vagy barmi olyan GPU architektura, ami a GCN-re hasonlit? Keplerre is lehet ilyet epiteni, siman.
"8 magos Xeon is van évek óta, csak nem fér be desktopon a TDP keretbe, nehéz lehűteni stb, épp ezért nem is lesz 8 magos desktopon."
Van 8 magos Xeonbol 70, 95, 130 es 150 Wattos varians is. Nem a TDP miatt nem mennek ezek desktopra, hanem a szoftverek miatt, amit futnak rajtuk. Szervereknel sokkal jellemzobb a sok-sok maggal valo skalazodas, a desktopon ez 4 mag felett problemas. No meg aztan a Haswell-E-bol lesz desktopon (HEDT) is 8 magos, ha minden igaz, ugyhogy azert ne zarjuk ki ezt a lehetoseget sem
"A csíkszélesség csökkentésről meg annyit, hogy az Intel sem tud a fizika ellen menni, és semmit nem tud tenni a black silicone jelenséggel, köthetik az ebet a karóhoz, ugyan úgy járnak a maghajhászással, mint anno a Prescottnál az órajelhajhászással."
Szerintem ezt bizzuk rajuk. Egyelore me'g mukodik a dolog, hiszen a Broadwell kisebb lesz es kevesebbet fogyaszt, mint a Haswell, mikozben gyorsabb lehet nemileg (legalabbis iGPU-ban mindenkepp). Megjegyzem, a Prescott es Tejas fiasko utan volt B-tervuk, annak koszonhetjuk a Conroe-t. En kinezem beloluk, hogy 2020 utanra is vannak kutatasaik, sot. Leginkabb azt kutathatjak manapsag, mert ok is pontosan tudjak, hogy a litografia egyszer veget er. De addig (5 nm?) is mennek lefele renduletlenul, mert naluk egyelore me'g mukodik a dolog.
"minden next-gen cím alapja a GCN, ezáltal a legtöbb konzolcím a közeljövőben kis átalakítással Mantle és HSA kompatibilis, ez igen nagy fegyvertény."
De azt ugye tudod, hogy a desktop es mobil (notebook, ultrabook) szegmens nem csupan a jatekokrol szol? Iszonyu sok PC felhasznalo van, aki sosem jatszik, vagy legalabbis nem a PC-n jatszik.
-
Fiery
veterán
"Akkor ezek szerint kár egyelöre kaverit venni?"
Ezt mindenki dontse el sajat hataskorben. Szerintem most is jo cucc a Kaveri, ha nem az abszolut (CPU) teljesitmeny a donto. En pl. sosem jatszok modern jatekokkal, nekem az iGPU csak arra kell, hogy kepet adjon a monitorom, neha egy-egy 720p videot megnezzek, de masra nem. Nekem mondjuk nem valo a Kaveri, de masnak me'g igen-igen jo valasztas lehet. HTPC-re is remek cucc, notebookba is nagyon jo valasztas lehet.
-
Fiery
veterán
"A fontos HSA direktívákhoz minimum Kaveri kell."
No offense, de miert nem lehet egyszerubben fogalmazni? A megosztott memoriahoz (SVM) kell Kaveri, ennyi. A fejlesztoket nem a modern queue villanyozza fel (ha felvillanyozza oket barmi is), hanem az SVM, ez a killer feature a Kaverinal.
"Az is heterogén módon programozható processzor, amiben ugyanazt az ISA-t használják a kis és a nagy magok is."
Az a baj, hogy leragadtal a Skylake-nel Raadasul egy olyan Skylake-nel, amirol _biztosat_ me'g nem is lehet tudni. Te es sokan masok ugy kepzelik el a Skylake-et, hogy 4 db Broadwell-szeru CPU-mag, meg mondjuk 20-25 db MIC iGPU mag, es az oprendszer felé csak a hagyomanyos x86 CPU-magok latszanak (mint a Haswell/Broadwellnel meg Kaverinal is). Semmi garancia nincs ra, hogy a Skylake igy fog kinezni, de talan a kovetkezo IDF-en tobbet fogunk tudni.
A Knights Landing kapcsan pedig eleg egyertelmunek tunik, hogy nem a heterogen megoldasok fele megy az Intel _hosszutavon_, hanem egy rakat egyszeru 512 bites SIMD x86 magot (pl. Silvermont) hasznal, melyek egyenertekuek es egyforman latszanak az operacios rendszer felé. Ha a Skylake heterogen megoldasu is lesz, a 2-vel utana kovetkezo generacio mar szinte biztos, hogy nem. Jo esellyel a Nehalem vonal kukazva lesz, es a Silvermont-ot viszi tovabb az Intel.
[ Szerkesztve ]
-
Fiery
veterán
"A Llano (A4-65W) es a 7750(55W) kulon-kulon is tobbet, egyutt majd 3szor tobbet eszik a nem letezo 4 szalas A4 teljesitmenyrol meg ne is beszeljunk"
Arra azert kivancsi lennek, miert jaratod max. terhelesen a videokartyat es a Llanot is egyszerre Mert ha nem terheled oket, akkor meg nem 120 Wattot fogyasztanak, hanem mondjuk max. 10 Wattot egyutt. Ugyanigy, ha epp mondjuk egy 720p videot jatszol le a gepen, eleg hasonlo lehet egy komolyabb APU es egy ilyen Llano+HD7750 kombo fogyasztasa...
"elavult Intel FPU-ra"
Arra a 256 bit szeles SIMD FPU-ra gondolsz, ami AVX-et, AVX2-t es FMA-t is tamogat? Ergo a legfejlettebb es leggyorsabb x86 FPU, ami valaha keszult?
[ Szerkesztve ]
-
Fiery
veterán
"Igen arra az FPU-ra ami a peldanak felhozott jo ar/ertek aranyu DVGA-s Celeron/Pentium-ban van es a fejlett HSA-s kodot AMD APU altali sebesseg toredekevel futtatja"
Melyik HSA-s kodra gondolsz? Arra az egy szem LibreOffice Calc-ra, amivel mindenki peldalozik? A HSA igeret, a jovo, nem a jelen. Es egyebkent mitol lesz egy HSA-s kod "fejlett" ? Attol, hogy egy csomo C-szeru kodsort egymas utan irogatsz, majd a betas HSA implementacio a hagyomanyos OpenCL 1.x code path-hez kepest _lassabban_ fut? Mert jelenleg ez a helyzet... Kiveve persze ha kifejezetten arra irsz egy benchmarkot, hogy kidomboritsa az SVM elonyeit, de azt meg nem feltetlenul neveznem relevansnak
[ Szerkesztve ]
-
-
Fiery
veterán
"Az azonban belátható, hogy mennyivel egyszerűbb lenne a mérnököknek tervezni 0-ról valamit és nem azzal törődni, hogy a DOS még mindig fusson"
Ez egyertelmu, csak epp a realitas meg mast mond Az eletet nem a mernokok alakitjak, nekik is az elethez kell igazodniuk. Kituno pelda az Itanium, ami mernoki szempontbol remek cucc, csak ugye nem mukodik a piacon, a gyakorlatban
-
Fiery
veterán
válasz #32839680 #582 üzenetére
"Minek kell bootolnia egy 2014-es hardveren a DOS-nak? Minek nem védett mód? Minek 16 bites üzemmód?"
Minek kivenni, ha minimalis overhead-et jelent? Ezek mar nem a 486-os idok, hogy egy-egy ilyen feature elviszi a die area 10 %-at
"az Itanic azért volt bukás mert 100%-osan elvetette a kompatibilitást a korábbi x86 procikkal, semmilyen régebbi alkalmazás nem futott rajta, ezt persze hogy nem nézik jó szemmel."
Szerintem nezz utana a dolognak kicsit alaposabban: az Itanium futtatja az x86 szoftvereket minden gond nelkul, csak nem tul gyorsan. Az AIDA64 is fut Itaniumon, a CPU-Z is
-
Fiery
veterán
Az a jo, hogy a HSA-nal nem fordulhat elo, hogy rossz a driver vagy az implementacio. Vagy megis? Mert ugye jelenleg igy nez ki a dolog: OpenCL kernel --> OpenCL-IL fordito --> IL-GPU ISA fordito --> vegrehajtas. Itt el lehet cseszni a 2 lepcsos forditast es lehet nem-tul-optimalisan vegezni a vegrehajtast is. Ezzel szemben, a HSA-nal elso korben lesz egy AMD-fele sajat HSA implementacio, ami igy nez ki: OpenCL kernel (ha mar az OpenCL-rol van szo) --> AMD-fele OpenCL-HSAIL fordito --> AMD-fele HSAIL-GPU ISA fordito --> vegrehajtas. Itt pontosan ugyanannyi lepcsoben lehet elszurni a dolgokat, mint a HSA elotti idokben...
Ha ehelyett lesz majd egy altalanos HSA implementacio, akkor meg igy fog kinezni a dolog: OpenCL kernel --> generalis OpenCL-HSAIL fordito --> AMD/Qualcomm/Samsung/stb-fele HSAIL-GPU ISA fordito --> vegrehajtas. Itt, amennyiben feltetelezzuk azt, hogy a generalis HSAIL fordito hibatlan es gyors kodot is fordit, akkor is megmarad a gyarto sajat HSAIL-GPU ISA forditoja, meg persze a vegrehajtasi resz, ahol ugyanugy el lehet szurni a dolgokat, meghozza nem kicsit, hanem pont annyira, mint a HSA nelkul. Semmi garancia nincs ra, hogy egy HSAIL kodot minden egyes gyartoi implementacio egyforma, egyenletes minosegben fog futtatni az epp aktualis GPU ISA-n. Plusz, azt me'g ki is kell varni, hogy legyen egy igazan jo OpenCL-HSAIL fordito, egyelore me'g az AMD-nek sincs, nem hogy barki masnak...
-
Fiery
veterán
Akkor nem lehet megirni, amikor a ceget (legyen mondjuk az egyik "C" betuvel kezdodo) erosen tamogatja az egyik GPU gyarto Akkor nagyon nehez mas architekturakra portolni az OpenCL kododat, sot, szinte lehetetlen Ha azonban a szoftver keszitojet nem tolja egy gyarto sem, hanem szabadon mokolhat, akkor furcsamod lehet lenyegeben platformfuggetlen OpenCL kodot kesziteni. Oke, lehet hogy lesz benne 1-2 elagazas, de nem tobb szaz, es nem tobb, mint mondjuk egy nativ x86/x64 kodban.
A HSA meg az OpenCL 2.0 egyebkent teny, hogy nagyon jol jon, ha mondjuk SVM-et akar az ember hasznalni. De azert ne allitsuk be ugy, hogy mostantol minden celra tokeletes eszkoz lesz, es az eddigi problemakat egy csapasra elsopri a HSA. Ha igy lenne, akkor mar most egy halom HSA-gyorsitott szoftver lenne piacon, vagy legalabb be lennenek harangozva. Ehhez kepest van 2 db szoftver _keszuloben_, meg egy Windows patch (by AMD), es nagyjabol ennyi.
-
Fiery
veterán
válasz #32839680 #694 üzenetére
Az eredeti OpenCL egy C-szeru nyelv, nem OOP. Keszuloben van az OpenCL C++, ami egy C+11-re epulo, OOP nyelv. Magyar dokumentaciot nem ismerek a temaban, lehet hogy van, de az angol doksikat is eleg konnyu megerteni. Ha programozo vagy, es angol szakmai szovegertesben nem vagy eros, akkor ott alapveto problemak vannak, amin SZVSZ az OpenCL tanulast megelozoen dolgozni kellene, no offense
[ Szerkesztve ]
-
Fiery
veterán
válasz #32839680 #698 üzenetére
Ebben az esetben melegen ajanlom az OpenCL-t, nem kell megijedni tole. Nagyon egyszeru az egesz, csak odaig kell eljutni, hogy az alapveto paradigmat megertse az ember (pl. work item, work group, device memory meg hasonlok). Par het alatt eleg jo rutint lehet benne szerezni, amennyiben van idod molyolni vele, es mondjuk a C-hez megvannak az alapok.
-
-
Fiery
veterán
válasz #32839680 #704 üzenetére
APP SDK olyan szempontbol franko, hogy egy halom sample-t adnak hozza, amik nagyon tanulsagosak. A tobbi reszet en meg se neztem, ahogy irtam fentebb is, az SDK-kat nem kedvelem, nem hasznalom, ha nem muszaj. Sample temaban erdemes me'g felrakni a CUDA Toolkit-et is, az is tartalmaz izgalmas sample-ket.
-
Fiery
veterán
Oke, olyan szempontbol hint a native, hogy ... sz'al nagyjabol semmi ertelme azt nezni Teljesen irrelevans, hiszen, ahogy irod is, a fordito mindent elintez. Szet kell a melot dobalni egy halom work group-ra, es megy minden szepen magatol. HSA nelkul is
Es nem lesz lassabb vektor tipusokkal sem, a fordito elsikalja a dolgot (jo ertelemben).
[ Szerkesztve ]
-
Fiery
veterán
-
Fiery
veterán
Tok mindegy, hogy runtime-nak vagy finalizernak hivod, attol me'g ott lesz a HSAIL --> GPU ISA fordito, amit a gyartoknak kell elkesziteni es karbantartani. A 3 gyarto, akinek van egyaltalan ehhez hasonloja (sajat IL --> GPU ISA fordito) az AMD, Intel es nVIDIA. Ebbol az AMD velhetoen fog tudni kesziteni egy megfelelo minosegu megoldast, leven hogy mar van par ev tapasztalatuk a temaban. Az Intel es nVIDIA velhetoen nem fognak ezzel babralni, hiszen nem leptek be a HSA alapitvanyba. A tobbi gyartonak meg pontosan nulla tapasztalata van ilyen forditok kesziteseben, tehat nekik is evekbe fog telni, mire valami jo minosegu forditot (finalizer) keszitenek. Sz'al en a magam reszerol az AMD-ben remenykedek, a tobbi gyarto teljesen kerdojeles, mar csak azert is, mert a nem-x86-Windows platformok sem tamogatjak specifikusan se az OpenCL-t, se a HSA-t. Amig pedig a juzereket el lehet vakitani me'g egy kicsivel tobb core-ral meg az idei es jovo ev slagerevel (64 bites SoC-ok), addig nem az OpenCL/HSA fordito irasa lesz a prioritas a gyartoknal, es a HSA sem lesz prioritas az oprendszer gyartoknal... Ne legyen igazam.
-
Fiery
veterán
"A legtöbb fejlesztő nem az első HSA implementációt célozza."
Ez jo duma Mondjuk inkabb ugy, hogy a szoftverkeszitoket nem gyozte meg egyelore a HSA, es mindenki a masikra var, hogy valamivel eloalljon, ami erdekes, amire raharapnak a juzerek, es akkor megmozditjak a s***uket a tobbi gyartonal is a fejlesztok. Csak epp kicsit veszelyes ez az egymasra varas, ebben benne van az a veszely is, hogy senki se mozdul semerre. Plane egy zsugorodo PC-piacon, ahol a befektetesek megterulese az idei evben sokkal kevesbe egyertelmu, mint mondjuk 5 eve volt. Ilyen korulmenyek kozt fejlesztoket allokalni a HSA-ra nem egyszeru kerdes, plane amig egesz pontosan 1 db hardver van, ami tamogatja a HSA-t. Ilyen helyzetben a legjobb taktika a kivaras.
[ Szerkesztve ]
Új hozzászólás Aktív témák
- Újszerű - INTEL Core i5-14600KF 14mag 20 szál 5.3GHz CPU - bolti garanciával
- i3 8100/ ingyen automata
- Beszámítás! AMD Ryzen 7 7800X3D 8 mag 16 szál processzor garanciával hibátlan működéssel
- ! Intel 13700KF + ASUS TUF Gaming Z790 Plus D4 + Kingston FURY DDR4 3600MHz CL18 !
- Garanciális Intel Core i5-13600K