- Milyen notebookot vegyek?
- Vezetékes FÜLhallgatók
- Multimédiás / PC-s hangfalszettek (2.0, 2.1, 5.1)
- Alapértelmezett konfiguráción sok Core CPU-nak lehet stabilitási gondja
- Házimozi belépő szinten
- Milyen TV-t vegyek?
- Szünetmentes tápegységek (UPS)
- Egészen nagy teljesítményspektrumon fedné le a mobil piacot az AMD
- Kompakt vízhűtés
- Gaming notebook topik
Hirdetés
-
Képeken az egyik kameráját elvesztő Sony Xperia 10 VI
ma Részletes anyag került fel az internetre a Sony idei középkategóriás telefonjáról, három helyett két hátlapi kamera várható.
-
Az Apple megszerezné a klubvilágbajnokság közvetítési jogait
ph A vállalat ezért irgalmatlan pénzt fizetne a FIFA-nak, és ezzel rajzolná át az online streaming platformok háborújában a frontvonalakat.
-
AMD Radeon undervolt/overclock
lo Minden egy hideg, téli estén kezdődött, mikor rájöttem, hogy már kicsit kevés az RTX2060...
Új hozzászólás Aktív témák
-
félisten
Kiváncsi vagyok, hogy miylen erőviszonyok fognak kisülni a teljes integráció megvalósulása után.
Az intel a GPU-val szenved, az AMD a CPU-val bénázik, az nV-nek nincs x86 licensze, a többi ARM gyártó nem tudom, hogy jön majd a képbe...
Izgi lesz, az biztos.Eladó régi hardverek: https://hardverapro.hu/apro/sok_regi_kutyu/friss.html
-
ddekany
veterán
A megoldás egyszerű: Az Intel licencelje a CPU magját az AMD-nek, amiért ő cserébe licenceli neki a GCN-es IGP-szerűségét. (Amúgy technikailag vajon mennyire lehetne a kettőt egybeépíteni? Már persze világos, hogy csak úgy kapásból nem lehet, de vajon van-e olyan alapelképzelésbeli eltérés, ami miatt ez a kettő nem tudna együttműködni hatékonyan.)
-
Abu85
HÁZIGAZDA
Megoldható a GCN beépítése az Intel magok mellé. Azért szükség van egy módosított System Agentre, de pár apró változtatáson kívül nem lehet probléma az integráció.
Persze ez csak elmélet. Az AMD már elmondta, hogy a GCN-t senkinek nem adja oda licencelésen keresztül.(#3) ivana: Nem érdekelné a versenyhivatalt. Az Intel egyszerű üzletet kötne a GCN licencelésével. Olyan, mintha raknál a proci mellé egy VGA-t. De ez nem fog megtörténni.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Meteorhead
aktív tag
Csak annyit akartam hozzáfűzni a cikk elejéhez (amit talán módosítani is kéne), hogy teljesen érthető, sőt preferált Intel compilernél a preferált 1-es vektor szélesség.
Intelnek van messze a legbonyolultabb és legfejlettebb OpenCL compilere CPU-ra, ők ugyanis leimplementálták azt, amit az AMD nem tudott, és helyette architektúrát váltott. Az Intel compiler ugyanis azt csinálja, hogy akármilyen vektoros kódot is írtál, skalárműveletekre szedi szét az egész kernel kódot, és az AVX 4-8 sávján 4-8 kernel példány fut, tehát tökéletes a vektorfeldolgozók kihasználtsága. A nehézségek az elágazásoknál adódnak, főleg a kernel példányonként változó hosszúság ciklusoknál (ezt egy maszkolással oldják meg, és egyedül ilyen helyeken romlik a hatékonyság, ahol a maszkolt szálak is elvégzik a műveleteket, csak nem látni memóriában az eredményt). AMD-nek is hasonlót kellett volna implementálni a VLIW compilerükbe, de helyette szétszedték a vektorfeldolgozókat négy fürtre, így lett VLIW4-ből GCN (jó, persze GCN-ben másváltozások is vannak, de leginkább a szuperskalár feldolgozóról skalárra térés a legnagyobb váltás.
Itt látszik, hogy mi a különbség az OpenCL-ben lekérdezhető "Native float vector width" és a "Preferred float vector width" között, mert nyílván ilyen compilerrel tök fölösleges vektorizálni (aki kapásból skalár kódra szedi szét), sőt inkább jobb tudni, hogy kár a gőzért.
Eltérés a másik irányba is lehetséges amúgy, ahol a natív szélesség mondjuk 4, de a preferred 16. Ilyen lehet a char vektor, ahol egyes compilerek/architektúrák 4 byte-ra rendezik a regisztereket, és képesek tömöríteni őket.
Szóval ezért 1 a preferred vector width Intel-nél.
-
ddekany
veterán
"Megoldható a GCN beépítése az Intel magok mellé."
Amikor buldozerre cserélték a CPU-t, akkor az mint önálló CPU mag rosszabb lett (telj./fogy.), és mintha lett volna valami duma, hogy ez viszont jobban passzol majd az AMD jövőképébe, mikor is GPU és CPU összeolvad. Viszont ha az Intel jóval ütőképesebb magja is stimmel az GCN-el, holott azt sem arra tervezték, akkor felmerül bennem, hogy ez vagy BS volt, vagy én én emlékszem rosszul, vagy... szóval hogy is van ez? A buldózer jobban beleillik a GCN-es jövőkébe mint a régi AMD mag, és miért? (Mert ha még a Jaguárra mondják ezt, akkor értem, mert az pici és keveset fogyaszt azért cserébe, hogy gyenge.)
[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
válasz Meteorhead #7 üzenetére
Ezt akkor nem érdemes kiegészíteni, mert nem probléma, hanem tervezett működés. Inkább kivettem. Mondjuk így meg megint az a kérdés, hogy miért ilyen gyenge a teljesítmény, de mindegy.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Voltak ilyen elméletek, de szerintem sosem fog a CPU és a GPU összeolvasni, mert túl sok az eltérés a működésben. A FlexFP előnye, hogy jobb lehet a vektorfeldolgozó kihasználtsága. Ami esetleg adalék lehet, hogy az Intel a magjainak a SIMD motorját nagyon kigyúrja, míg az AMD már nem, mert ott az IGP koprocesszorként. Ez viszont szimplán koncepció, nincs köze ahhoz, hogy működhet-e az integrálás vagy sem.
(#9) ddekany: Ja, igen az aranyos lett volna.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
pakriksz
őstag
valszeg az amd-nek nem igazán kell a cpu... csak és kizárólag a PC ragadt le a cpu-nál, máshol ahol nem kell mindenféle ősrégi dolgot figyelembe venni, ott a gpu dolgozik, lásd az új konzolokba sem a legerősebb amd cpu magok lettek beépítve hanem a legkisebb fogyasztásúak, valszeg azért mert egyszerűen nincs szükség többre.
[ Szerkesztve ]
Troll (nemhivatalos definíció): az akinek véleménye nem tetszik nekünk/nem értünk vele egyet. (10-ből 9 fanboy ezt ajánlja) || Fanboy 8 in 1 (Intel, AMD, Nvidia, konzol, PC,+minden politikai oldal) hiszen "ahol nem mi vagyunk, ott az ellenség"
-
félisten
-
-
ddekany
veterán
"valszeg az amd-nek nem igazán kell a cpu..."
Ok, csak ezzel önmagában nem magyarázható egy visszalépés. Mikor a Buldozer kijött, bennem legalábbis az maradt, hogy amit leváltottak, az összességében hatékonyabb volt. Innen jött a kérdésem. Persze lehet hogy ez olyan, hogy ők miden tekintetben jobbat akartak, de nem jött össze. Nem tudom...
"új konzolokba sem a legerősebb amd cpu magok lettek beépítve hanem a legkisebb fogyasztásúak"
Alkalmazás-függő lehet, hogy hol mi a jó kompromisszum, és egy power-user PC-n a játék egy a sok alkalmazás közül. A legtöbb programkód, ide értve a jövőben készülteket is, reálisan, soha nem lesz többszálú. A kérdés persze, hogy ezen feladatok tényleg 99%-ban olyan kicsik-e, hogy nem is érdekes a gyorsításuk. Nem vagyok meggyőződve erről... kapásból, remek lehetőségek vannak a programkód tetszőleges lassítására kellően magas szintű nyelvek/framework-ok alkalmazása mellett. Némelyiknél már sajnálom a CPU-t, annyi rétegen kell átvergődnie.
[ Szerkesztve ]
-
Sinesol
veterán
Hja volt is mar regeben szo pletykaszinten hogy siman megveszi kilora XD, nemcsoda hiszen a piac 80-90 szazaleka az öve tehat van penz böven, nem terhelne meg tulsagosan ha felvasarolná az egesz amd-t.
Csak hat akk meg csak 2 szereplös lenne a piac es az mar erösen kartell gyanus jelenleg is emiatt van csak a via életben hagyva 3. piaci szereplönek. Ja igen ahogy emlitetted ha az ARM is megjelenik a piacon az egyszerüsiti a helyzetet, meg nemsoka Nvidia is jön a Maxwellel.[ Szerkesztve ]
-
Male
nagyúr
Igen, jelenleg ez nem lehetséges, nem engednének egy ilyen felvásárlást, viszont az ARM ha már azonos piacon lesz, akkor ez az akadály szerintem elhárul. (talán ők is számolnak ezzel.... bepróbálkoznak a MIC-cel, ha bejön, akkor oké, ha nem, akkorra talán meglesz a lehetőség a felvásárlásra már, és megoldják ezzel a GPU problémájukat)
-
Sinesol
veterán
Hát ja az nvidia hiaba licencel ha x86 magok mellé nem lehet beepiteni apu celjara, viszont a gcn meg ahogy Abu is irta könnyen tarsithato az intel cpu resze mellé és gondolom a kesöbbi amd projektek is ilyenek lesznek, igy ha nem akarnak sok vacakolást akk egyszerüen felvasaroljak az Amd-t. Az sem utolso szempont hogy mar az Nvidia es az Arm megoldasok is küszöbön allnak és akkor mar jelentös többfrontos konkurencia lesz és közben a szükülö piac miatt is nehezen ferne bele hogy gpu-val vacakoljanak. Emiatt elegáns megoldas lenne ha siman megvenné az Amd-t. Habár mindez a mi szempontunkbol nagyon rossz lenne az biztos...ha megszünne az egyetlen életképes konkurencia pc fronton.
-
Abu85
HÁZIGAZDA
Az AMD sem jó az Intelnek. Ők nem GCN-t akarnak, hanem olyan piacot, ahol monopóliumuk van, vagy olyan rendszert, amivel monopóliumot építhetnek. Ha a GCN-t belerakják, akkor egyenes útjuk lesz a HSA-ba, vagyis egy olyan platformba, ami értéktelenné teszi az x86-ot. Ez az Intelnek nem jó. Amit max nyernének az AMD-vel az a tapasztalat meg a szabadalmak (ezekre persze úgyis van licencük), de az ott dolgozó mérnökök egy része dolgozott a Larrabee-n. Például John Gustafson, aki Eric Demmers helyét vette át, miután megunta, hogy az Intel szerelmes az x86-ba és nem tud felszabadultan architektúrát tervezni. Tehát valamilyen szinten az Intel a saját korábbi mérnökeit kapná vissza.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Sinesol
veterán
De egyébként ha az Intel megvenne az Amdt-t es hagyna a francba a HSA-t akkor gyakorlatilag az Amd kiesésével a legfontosabb, gyakorlatilag alapito tag esne ki a Hsa-bol es mindez egy enyhe celiranyos piaci nyomas hatasara az egesz Hsa kukázásához is vezethetne...nem ujdonsag mar az ilyesmi, sok hasznos elképzelés bukott már el óriascégek erdekei miatt...meg ha mas haszna nem is lenne egy feltörekvö konkurenst eltüntetne+ nemcsak a gcnröl van szo, hanem mar a 9ezres sorozat is jo eséllyel lassan tesztfazisba kerül mert mar evekkel kiadas elött fejlesztik és az már nem gcn lesz.
///Ja igen itt rendes elméleti 2015 -ös 9000esekre gondoltam nem pedig arra hogy a kövi lesz 9000 ha tenyleg igaz hogy a 8000es elnevezes kimarad////
[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
És mit csinálna az Intel a HSA nélkül egy HSA-hoz tervezett architektúrával?
Nem mellesleg a HSA mögött ott van a teljes ARM iparág. Kivéve az NV-t, de ők az ARM partnerek között törpék. Szóval az alapítvány még az AMD nélkül is megmaradna.
Ha a Larrabee nem jön be, akkor ez a vészforgatókönyv. Őket már megvette az Intel.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Sinesol
veterán
Hat eddig hsa nelkül is jol müködik a gcn architektura, mire meg beérik az Apu biznisz addigra irnak ra egy HSA-hoz hasonlo de zart rendszert amit levédenek es hiaba majdnem hsa lesz akkor is csak övek lesz a szabadalom. Mint anno ahogy az MS is koppintasbol szedte a DOS rendszert.
A pelda adott már csak a megvalositas hianyzik de az csak reszletkerdes. Na meg tegyük hozza a szinte jelenleg is monopol helyzetben levö Intel-t és nem kérdés hogy siman az eladott intel apu-k tömege miatt rengeteg felhasznalo hasznalna az intel hsa koppintását.
Gondolom az amd-nek amugyis kiemelt jogköre van a hsa alapitvanyban igy azokat megkapna az intel igy valoszinüleg könnyen fel is hasznalhatna a szabadalmakat egy ugyanolyan gcn -es architekturas hsa szerü rendszer kiepitesere és mindezt legalisan.Ez esetben adott lenne a Hsa viszonylag kis tamogatottsaggal ezzel szemben pedig az Intel hsa koppintasa. A felvasarlas utan viszont kb 95 szazalekos piaci reszesedessel, nem nehez kitalalni meik rendszer terjedne el jobban... az amd altal lassan felépitett rendszer hasznat learatna az intel...
Persze mindez csak fikció[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
Az a baj a HSA-val, hogy az AMD ezt úgy építette fel, hogy ne kelljen direkten támogatni. Mindegy, hogy az Intel mit dönt, akkor is futni fog a HSA program az Intel hardverein. Az ARM is készít egy ilyen legacy módot az NVIDIA hardvereire. Nem lesz gyors, de futni fog, és ez a fejlesztőnek a lényeg. Szóval a HSA-ból kiléptetni az AMD-t nem egyszerű, mert ott a futtathatóság csapdája.
Az AMD-nek nincs kiemelt jogköre. Annyi a különbség a többiekhez képest, hogy két tagjuk van a vezetőségben, de csak egy szavazhat így is, tehát ebből előnyük nem lesz.A HSA mögött nem csak az AMD meg az ARM van, hanem az LG, a Sony, a Mediatek, a Samsung, a Qualcomm, a TI. Ezek a cégek összesítve nagyságrendekkel több lapkát gyártanak, mint az Intel egymaga. Az Intel "HSA koppintása" lenne a kisebbség.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
stratova
veterán
Ami CPU magokat illeti, tippem szerint nem feltétlenül csak a CPU+GPU összeolvadással, a skálazhatósággal lenne még magyarázható a Bulldozerrel bemutatkozó modulos felépítés. Pl. mobil prociknál Intelnek bevett receptje: Celeron = 2 mag, Pentium = 2 mag magasabb órajellel, i3 = 2 mag + m.o. + HT, i5 = 2 mag + m.o. + turbo boost, i7 szegmenstől függően = i5 + m.o. + 4 MB L3 vagy mindez 4 mag + HT felállásban. Ezen kívül játszanak a szolgáltatásokkal és az IGP teljesítményével. AMD csak a moduláris Trinityvel tudott "lemenni" ULV szintre a más ligában játszó Brazos mellett APU-k között; még mindig 32 nm-en. Llano C2C erősebb volt, de csak 35-45 W-os TDP-vel dobták piacra.
-
azopi74
addikt
APU-ban érdekes lehet a MIC alkalmazása. Néhány nagyteljesítményű x86-os out-of-order és sok szintén x86-os kisteljesítményű in-order mag egy chipen... Amiket akár grafikára, vagy másra is be vethet a fejlesztő. Vagy nem is kell ezzel a fejlesztőnek foglalkoznia, az OS majd szépen szétosztja a feladatokat (persze ehhez olyan OS kell, - ami egyelőre még nincs
big.LITTLE HMP Intel módra? Hmmm. Érdekes. Lehet, hogy az x86 mégsem fog eltűnni a süllyesztőben hosszabb távon sem?
-
azopi74
addikt
Most is rengeteg, különböző gyártók által fejlesztett SoC-ok épülnek ugyanarra a GPU-CPU kombó párosra, (pl Cortex X + PowerVR X , Cortex X + Mali X, Cortex X + Vivante, sőt most már jöhetnek a Cortex X + GeForce ULP-s megoldások is), mégsincs a versenyhivatalnak semmi kifogása, mert attól, hogy ugyanazokból a főbb elemekből építkeznek, még nem lehet ugyanannak a terméknek nevezni őket...
Szóval nem lenne elvi akadálya egy ilyen keresztlicensz megállapodásnak, erősen kétlem, hogy az AMD az egyetlen ütőkártyáját, a GCN-t áruba bocsátaná. Különben is, mit kapna cserébe az Inteltől az AMD? Intel CPU magokat licenszelne? Az van az AMD-nek is. Vagy le is gyártaná az AMD-nek az aktuális legfejlettebb gyártástechnológiáján a chipeket?
Én inkább Intel-nVidia megállapodásra tippeltem eredetileg, de ha ez a MIC dolog bejön az intelnek, nem fog az nV-ra sem rászorulni. -
azopi74
addikt
Szerintem akik összeolvadásról beszélnek, nem arra gondolnak, hogy homogén rendszerek lesznek, hajszálra azonos feldolgozó egységekből felépülve, hanem arra, hogy a jövő chipjeiben már meglehetősen filozófikus kérdés lesz eldönteni egy "magról" , hogy az most vajon GPU vagy CPU mag.
Lesznek különféle feldolgozó egységek, amik futtathatnak mindenféle feladatokat, hogy melyik éppen mit, azt majd az OS és a driver eldönti ...
Az AMD által ígért Context Switching nem valami ilyesmit vetít előre? Tényleg, ezzel mi van? Nincs valami infod róla? Eredetileg 2014-re ígérték., sőt QoS-t is. A Kaveri utódja már támogatni fogja ezeket? És mikorra várható?
-
ddekany
veterán
Végül is lehetne úgy (és most nem mondom, hogy erre bármi esély lenne), hogy mindenki csinálja azt, ami épp mérnökileg jól megy neki... Az Intel bika CPU magokat licencel, az AMD meg a GPU-szerűségét. Tulajdonképpen pont az a versenyellenes (közérdek ellenes), hogy nem így van, hanem mindenki "csomagokat" állít össze, azaz mindenki a saját vackához köti a saját nem-vackát (azaz Intel a jó CPU magját csak a szar GPU-jával együtt adja el, és fordítva). Gyártás is olyan dolog, hogy felőlem gyárthatnak egy 3 cégnél is, vagy gyárthatnak ő maguk is, ha versenyképesnek érzik magukat azon a téren. Persze vannak ilyen "apróságok", hogy egy CPU-t/GPU-t, ami a gyártástechnológiai határokat feszegeti, nem egyszerű másik gyártóhoz átvinni... ha pl. az Intel-féle CPU-t csak az egyik, az AMD-féle GPU-t csak a másik tudja legyártani, akkor abból úgy nem lesz APU.
-
ddekany
veterán
Valószínűleg ott ugyan arról a context switching-ről van szó, ami CPU-knál nagyon régóta már megvan. Ez több látszólag egyszerre futó szál ill. több folyamat támogatása egyetlen magon, időosztással (tehát valójában felváltva futnak, nem egyszerre). Ezt az OS vezérli le, de a hardvernek is alkalmasnak kell rá lennie, értelmes sebességgel, és amennyire tudom, GPU-knál ez eddig nem volt adott. Ebből még egyáltalán nem következik viszont, hogy a szál a CPU és a GPU közt mozgatható lenne, és ilyen belátható időn belül nem is lesz lehetséges ha más ISA a kettő (mint GCN + x86/ARM esetén). A GPU-n belüli kontextus váltás viszont nagyon kéne, ha sok alkalmazás akar rá építeni. Ill. GPU-knál még az is felmerül gondolom, hogy nem is kell mindig időosztással ezt, hanem egyik folyamat megkapja a CU-k egyik felét, másik a másikat... ezt se tudom ez mostanság már megoldott-e, de van egy tippem, hogy nem igazán.
[ Szerkesztve ]
-
ivana
Ármester
Az x86 azért maradt meg eddig is mivel jobban megéri a visszafele kompatibilitásra felhasználni néhány tranzisztort mint egy teljesen új architechtúrát bevezetni.
A versenyügyi problémára, pedig: az ARM-os proci piac és az x86-os proci piac nem ugyan az, ARM nem megy desktopba és laptopba, x86 nem megy telóba (kevés kivételtől eltekintve, de ez szerintem is változni fog), az előbbinél van egy vagon gyártó, néhány nagyobb, az utóbbinál 2 (+1) gyártó, ha ez a kettő össze vissza licenszeli a mikro architechtúrákat az már elég erősen kartell gyanús (továbbra is az az eset ami egy vicc gcn->intel intel proci->amd)
-
azopi74
addikt
"Ebből még egyáltalán nem következik viszont, hogy a szál a CPU és a GPU közt mozgatható lenne, és ilyen belátható időn belül nem is lesz lehetséges ha más ISA a kettő (mint GCN + x86/ARM esetén). "
http://www.xbitlabs.com/picture/?src=/images/news/2012-02/amd_power_tech_roadmap.jpg
Hát pedig én ezt pont úgy értelmezem, hogy CPU-GPU magok közti context switching-re gondolnak.
HSA alkalmazása esetén mindegy is, hogy milyen az ISA-ja a különböző magoknak, nem? -
ddekany
veterán
Nem látok azon a képen semmit ami ide kapcsolódik.
HSA-t nem ismerem közelebbről, de amennyire nekem eddig átjött, az lényegében egy virtuális ISA (ahol a HSAIL felel meg a gépikódnak), kicsit hasonló a JVM-hez. Ezt feltételezve nekem nagyon meredeknek tűnik futó program oda-vissza dobálása az x86-os CPU és GCN-es GPU közt. A HSAIL-t ugyanis tovább kell fordítani natívra, mielőtt futna, és ebből következően az x86-on meg GCN-en futtatott kód különböző lesz. Egy futó taszk átvitelénél egy másik magra/akármire, a program állapotát is át kell vinni, tehát a regiszterek és RAM-ban tárolt változók tartalmát, ezek viszont (főleg az alkalmazott regiszterek és lokális vagy egyéb módon privát változók) fordítás-függőek. Meg persze, az utasítás mutatót is át kéne fordítani, de általános esetben két fordítás utasításai közt nincs 1:1 megfeleltetés, tehát nincs a fordításban amire át akarsz váltani olyan utasítás, ami a megszakított program soron következő utasításának felelne meg. Mondjuk azt lehet, ha van direkt ilyen betervezve a HSA-ba, hogy nem akárhol lehet kontextust váltani, hanem vannak meghatározott helyek a programban (afféle fence-k), ahol a HSAIL fordítónak garantálnia kell, hogy minden változó ki van írva a RAM-ba, és minden előző HSAIL utasítás megfelelője már lefutott, és a következő végrehajtása még nem kezdődött el. Na ott lehetne kontextust váltani, feltéve, hogy a HSAIL programok változóinak tárolási módja egységes a két fordítás közt.
De igazából nem látom miért lenne az egésznek értelme, mert adott kód vagy GPU-n, vagy CPU-n fut hatékonyan, tehát minek dobálnám a futó programot a kettő közt?
[ Szerkesztve ]
-
azopi74
addikt
"épp ezért kérdéses még, hogy egyáltalán alkalmas lesz-e grafikára."
Pedig eredetileg arra tervezték, sőt diszkrét GPU-kba szánták, hogy majd lemossák a Radeonokat és a GeForce-okat a föld színéről
Én is jókat derültem akkoriban az egészen.
APU-ban viszont látom létjogosultságát egy ilyen megoldásnak.A mai GMA ősét, az i740-et is először megpróbálta egy rövid ideig a diszkrét VGA-kba kínálni az Intel, jókora bukás is lett a dologból, úgyhogy gyorsan kivonták a piacról, northbridge-be integrált IGP-kbe persze elment, mert azt "ingyen" kapta a vásárló, és úgysem volt igazán komolyan vehető versenytárs, aki meg lett volna, azt kizárta licensztrükközéssel, és ellehetetlenítette.
Na ekkor kellett volna az Intelt jól megb*ni a versenyhivatal által tiltott árukapcsolás miatt, amíg lehetett. Ez indította el azt a folyamatot, ami aztán a diszkrét GPU piac totális szétzúzásához , és közvetve a PC-s játékpiac hanyatlásához is vezetett...
-
azopi74
addikt
"De igazából nem látom miért lenne az egésznek értelme, mert adott kód vagy GPU-n, vagy CPU-n fut hatékonyan, tehát minek dobálnám a futó programot a kettő közt?"
Mert a terhelés úgy alakul, hogy szükség lesz egy-két GPU-ra vagy CPU-ra , és fel kell ébreszteni, vagy már nincs szükség, és le lehet kapcsolni valamelyiket. Függetlenül attól, hogy min futna amúgy a leghatékonyabban, pusztán energiazdálkodási szempontok figyelembe vételével. Tudom, ez ma még kicsit meredeknek tűnik...
-
ddekany
veterán
"Ez indította el azt a folyamatot, ami aztán a diszkrét GPU piac totális szétzúzásához , és közvetve a PC-s játékpiac hanyatlásához is vezetett..."
A PC-s játék piac további hanyatlásához szerintem most már leginkább az fog hozzájárulni, ha nem lehet az APU-k tudását olyan hatékonyan kihasználni, mint a konzolokon... Ez vastagon szoftveres és persze üzletpolitikai gond (az Intel betart), de diszkrét kártyákkal már hardveres gond is lenne.
-
azopi74
addikt
De nem akarom a folyamatot felfuggeszteni, mert szukseg van ra, csak az eppen azon dolgozo feldolgozoegyseget akarom kikapcsolni, mert mar nincs ra szukseg, elmult a veszhelyzet, es el tudja sokkal hatekonyabban latni egy arra optimalizalt, alacsony fogyasztasu egyseg is.
-
dezz
nagyúr
válasz Meteorhead #7 üzenetére
"skalárműveletekre szedi szét az egész kernel kódot, és az AVX 4-8 sávján 4-8 kernel példány fut"
Ezt hogyan? Alapból a SIMD ugyebár azt jelenti, hogy pl. 256-bites vektorok esetén egyszerre 8db SP FP művelet hajtódik végre, de mindegyiken ugynaz a művelet. Az AVX tud MIMD-et is?
"AMD-nek is hasonlót kellett volna implementálni a VLIW compilerükbe"
Tudtommal pedig náluk is az van, lásd alább.
"de helyette szétszedték a vektorfeldolgozókat négy fürtre, így lett VLIW4-ből GCN"
Nekem ez a cikk, különösen ez az oldal kicsit mást mond erről.
-
Meteorhead
aktív tag
A második cikk (ami inkább közelebb áll a technikai dolgokhoz) nemigazán hangsúlyozza ki a lényeget, de valahol ott van a sorok között. Megpróbálom saját szavakban, elmondani mi a különbség, és mi a mágia az Intel fordítóban.
Ezek a cikkek nagyon szeretnek dobálózni a SIMD, MIMD, VLIW és hasonló szavakkal, csak azt felejtik el megemlíteni, hogy a HW mégis melyik szintjén érvényesek az állítások (mert már annyi szintje van, hogy egy gyakorlott róka is eltéved közöttük).
HD6000 széria Radeonokból VLIW4-et használt. Ez azt jelenti, hogy mindegyik shaderprocesszor (SP) egy darab multiprocesszorban (CU) olyan kódot tudott futtatni, amiben egy órajel alatt (az egyszerűség kedvéért) 4 utasítást is végre tudott hajtani, amik különbözőek is lehettek akár. Ergo, ha olyan shader/kernel kódja volt az embernek, ami alapvetően skalár kód volt, akkor is egymás utáni műveleteket össze tudott pakolni egy VLIW instructionbe, és ez faján működik. Ha nagyon egymásra épülnek a számítások, az egyik eredménye kell a következőhöz, akkor a compiler meg volt lőve és nem tudott vele mit csinálni. Grafikai számításoknál viszont nevetségesen könnyű dolga volt, mert a 4x4 mátrixokat szorozása 4-es vektorokkal szétszedhető nagyon jól VLIW-re (de még SIMD-re is, ezen a szinten).
VLIW tehát egy fajta MIMD, a feldolgozó szintjén. Azért hívják SIMD-nek a Cayman CU-t, mert ilyen VLIW feldolgozóból van benne 16db, de azok már halál ugyanazt csinálják egy órajelben, tehát ha ilyen messziről nézünk rá, akkor SIMD a CU. A problémát már meg is foglmaztuk (mint ahogy a második linkelt cikk is írja), hogy grafikára ez nagyon jól működik, de általános skalár kódra vért izzad a compiler, mire talál adatfüggetlenséget és feltölti a VLIW sávokat. Ezért sírtak emberek, hogy miért nem fut 4 kernel/shader példány egy SP-nek a 4 VLIW sávján? Azért mert buzi nehéz erre megírni a compilert. (GPU-n még olyan betegségek is vannak, hogy ott a vektor regiszter az vektor regiszter, és skalárváltozót nem szeret belerakni, de ez messzire vezet)
Tehát AMD is folytatta NV példáját, és a művelet ütemezőt kirakta a kártyára. A compiler fellélegezhetett, cserébe olyan architektúrát rakott mögé, amire kellően könnyű ütemezni. VLIW nem lehet, mert futásidőben nem tudja a HW megcsinálni azt a mágiát, amin a compiler korábban offline tetszőlegesen sokáig gondolkodhatott. Mit csináltak? Szétszedték VLIW4-et 4 darab skalár fürtre. Ezek papíron más-más műveleteket is csinálhatnak, de a gyakorlatban ez ritkán, vagy szinte soha nem történik meg. Tehát 1 CU-ban van 4 skalár SIMD fürt, amik igazából ugyanazt a kódot futtatják, nagyjából lock-stepben.
Ezzel szemben AVX önmagában egy SIMD feldolgozó, aminek ténylegesen ugyanazt kell csinálnia minden sávjában. AVX-szel megcsinálni azt, amit AMD compiler csinált VLIW-vel, hogy adatfüggetlenség alapján vektorosítja a skalár kódot szinte lehetetlen. Ezért csinálták azt, hogy 1-1 sávban 1-1 kernel példány fut. Ezt végig, tisztán azonos műveletekkel megcsinálni állati nehéz. AMD-nek sokkal könnyebb dolga lett volna VLIW-vel.
AVX úgy tud MIMD-et, hogy a CU-k (ami egy x86 mag) csinálhat halál más dolgot, de maga az AVX az SIMD. Ezzel szemben HD6000 egy fajta MIMD belül, de kívülről SIMD, mert a CU-k ugyanazt a kódot futtatják. (Fermi CU-k tudnak más kódot futtatni, Tahiti-ben nem vagyok biztos, azt hiszem azok nem tudnak (cserébe tudnak elágazni, de most már zárom a sorokat, mert az idők végezetéig tudnék mesélni)
-
dezz
nagyúr
válasz Meteorhead #41 üzenetére
Köszi a kimerítő válaszodért, bár ezekkel valamennyire tisztában voltam. Csak nem tudtam, hogy pl. az AVX 4-8 sávján 4-8 CPU magot értesz (azt hittem, magon belül lehet valahogy "varázsolni", bár nem láttam erre lehetőséget).
Nos, azért azt el kell ismerned, hogy sokkal nehezebb lett volna több kernelnek a Cayman féle SP-kre osztása egy tömbön belül, mint ugyanezeknek több CPU magra osztása. Ha egyátalán kivitelezhető. A hatékonyság is kérdéses, hiszen tömbönként egy branch unit van. Plusz osztozni kell a regisztereken, cache-en. A linkelt cikkben (a második link a 4. oldal) fel sem merül, hogy ezt kellett volna tenniük.
(Ez a mondat téves volt a részemről: "Tudtommal pedig náluk is az van".)
[ Szerkesztve ]
Új hozzászólás Aktív témák
- ASUS TUF 3080TI 12GB OC IPON garanciával
- Asus GtX 780 3GB Videokártya
- INNO3D GTX 1660 Super DDR6 6gb videokártya eladó.
- LED XFX Radeon RX 580 8GB Gaming videokártya hibátlan állapotban eladó, samsung ramos(ritka és jó na
- ELADÓ VGA AMD FirePro W8100 8GB 512BIT GDDR5 PCIe 3.0 videokártya, 4db DP, tervezéshez vagy akár...
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Promenade Publishing House Kft.
Város: Budapest