-
Mobilarena
OLVASD VÉGIG ALAPOSAN MIELŐTT ÚJ HOZZÁSZÓLÁST ÍRNÁL!!!
Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
A fejlesztői megközelítést én sem nagyon értem, de az Intel álláspontja világos. Szokták is mondani, hogy az ő megközelítésük valóban hatványozottan nehezebb a programozás szempontjából mint a többieké, de megmaradnak az aktuális SDK-k és Library-k.
A másik álláspont is ismert egyébként. A többi cég azt mondja, hogy könnyebb új SDK-kat és Library-ket fejleszteni, mint elvárni a programozóktól, hogy több tucat szálra threadoljanak, szinkronizáljanak és 256/512/1024 bites vektorra kézzel optimalizáljanak. -
Abu85
HÁZIGAZDA
A fejlesztői panaszokra odafigyeltek volna mindenképp. Évek óta odafigyelnek. Nem azért nem született eddig low-level API, mert a gyártók homokba dugják a fejüket. Johan odament mindenkihez, hogy neki most már tényleg kell valami megoldás. Az Intel és az NV is azt mondhatta neki, hogy értik a gondját. De biztos, hogy visszakérdeztek: ha adunk megoldást, akkor mi a biztosíték arra, hogy rajta kívül még xy fejlesztő megtanulja az adott GPU architektúrát. Ez tehát egy anyagi gond. Beleölnek egy rakás pénzt egy emberért. Akármennyire szeretik Johant, üzletileg ez nem kifizetődő. Az AMD csak azért mondott neki igent, mert a konzolok garantálják, hogy mindenki megtanulja a GCN-t. Egyéb esetben nemet mondtak volna.
-
Abu85
HÁZIGAZDA
Top GPU-val +10-15% megvan ráadásul magas felbontásban és részletesség mellett. Innentől ki lehet rakni az ablakba, hogy <200 dollárból mindennél jobb a sebesség.
Az Intel sem véletlenül akarja ezt az OpenCL-ből használd az IGP-t manapság. A Mantle előnyéből az AMD APU részesül, de az Intel IGP nem . Viszont, ha az AMD APU-k IGP-jét leterhelik valami mással, akkor azt már az Intel IGP-je is elvégezheti. Eközben az AMD-n a Mantle feladatok számára nem marad erőforrás. Ezzel is kinyírják a sima E-s processzorokat, de az i7-4770K jó opció marad.
Az ipari kémkedés is szerepet játszhat. Az Intel tudja, hogy 20+ játék jön Mantle-re. És a partnerek alapján összerakható, hogy ezek Mass Effect, Dragon Age, Star Wars, Tomb Raider, Hitman kaliberű alkotások. -
devast
addikt
Elolvastam, és semmi újat nem mondott. És teljesen igaz. Csak egy szó nincs benne az async crossfire-röl, amiröl itt beszéltünk. Meg abba sem értünk egyet, hogy ebböl a nagy HSA dologból, ami egyértelműen a jövő, mikor lesz jelen. Mantle-ban sokkal nagyobb fantáziát látok az elkövetkezendő 1-2 évben, tovább meg nem érdemes tervezni a konzumer pc piacon. HSA jelenleg ott tart, hogy libreoffice calc-ban gyorsítja a számolást. De neked legyen igazad, és fél-1 éven belül jelenjenek meg az olyan portok, amik erősen támaszkodnak a hsa-ra (igaz arra már majdnem a carrizo-nál fogunk tartani).
-
atti_2010
nagyúr
-
Az volt az alap, hogy egy szálon 10%-ot gyorsul, több szálon (sysoft sandra) meg 30%-t. Ebből következtettem arra a (hülyeségre), hogy tehát ha ezelőtt egy modulnál szállal 100% a skálázódás és két szállal 190%, és az új ez még jobban skálázódik a hatékonyabb etetés miatt, akkor 240%-ot kapunk két szálra.
-
stratova
veterán
Pardon, de az Multi teszt csak mindkét lapka 3.5 GHz-en ketyegett, mert elvileg a 65 W-os A10-7800-nak ennyi lenne a normál órajele.
Miresz én még nem, köszi!
Jó lenne élvezhető teljesítményt kapni a mobil verziónál is. Nekem 1600x900 lenne az aranyközépút 15.6"-on (FHD mánia ide vagy oda, jelenleg ez kellemes a szememnek még mindenféle bűvészkedés és felskálázás nélkül).
Még ne vegyük készpénznek, de Te láttad ezt? -
Oliverda
titán
A Carrizo még FM2+ tokozású lesz, ez szinte biztos, ergo a DDR4 kilőve. Az FM2+ után valószínűleg új foglalat jön, mondjuk FM4 néven, ami már csak DDR4-et fog támogatni. Mivel a Carrizo valamikor 2015 első felében érkezik, ezért az FM4 (vagy ahogy majd hívják) szerintem nem fut be 2016 előtt. Addigra várhatóan már szélesebb körben, megfizethető áron lesz elérhető a DDR4
Bár még nem mélyedtem nagyon bele, de az alapján amit eddig láttam nem lenne olyan egyszerű egy termékkel megoldani a DDR3 és DDR4 támogatását is. Szerintem ezt most inkább kihagyják.
-
dezz
nagyúr
Ehh, megnéztem a cikk forrását is, a kínai szövegben csak annyi szerepel, hogy továbbra is az A88X és A78 FCH-kat fogja használni. Ebből még nem feltétlen következik, hogy FM2+ kompatibilis lesz, ahogy ez a Tim Verry írja.
De talán, ha a DDR4 mellett képes támogatni a DDR3-at is. Esetleg lesz belőle FM2+ és FM3-as változat is. -
-
Oliverda
titán
Nem fake, és ezt már többen alátámasztották, de nem látom értelmét a vitának, mert hajthatatlan vagy ebben a kérdésben is. Majd ha kijön az Excavator, akkor visszatérünk rá, addig ez egy meddő vita.
30% IPC növekedésről nem készült hivatalos slide, itt a bibi. A front end teljesítményével (dekóder) kapcsolatban jött fel a 30%, de az ugye nem egyenlő az IPC-vel. Nincs kedvem másodjára is lefutni ezt, amikor már tövig le lett rágva a téma. Íme
-
Oliverda
titán
Ezekre a kérdésekre szerintem itt még senki nem tud válaszolni.
A die-shot nem volt fake, csak éppen nem a Steamrollert ábrázolta, hanem valószínűleg az Excavatort, vagy esetleg az azt követő magot.
Arra gondolok amit itt páran megelőlegeztek (30-40% IPC). Azt már néhány hete túltárgyaltuk, hogy az AMD hivatalosan sosem beszélt ilyen mértékű IPC növekedésről.
-
Oliverda
titán
Szerintem nem olyan bonyolult ez. A közelmúltban napvilágot látott, az újságíróknak is eljuttatott prezentációkon szereplő Kaveri az a szűkebb körökben Kaveri 2.0-névvel jelölt fejlesztés. A verziószámos anyagokat csak a partnerek kapták meg. Az 1.0 isten tudja hogy pontosan mi lett volna, de ezt végül dobták. Egyébként valószínűleg abban volt a SteamrollerA (is).
-
Thrawn
félisten
Nem tudok modkert linkelni de: 2013-11-10 13:48:48
Szóval végigolvastam mindent, a fenti a zanzásított véleményem.Nem lesz az, csak a nagy vita közben elfelejted azt az apróságot, hogy amíg neki van mire alapoznia a véleményét (ott van nála a vas), te csak kb a levegőbe beszélsz mindenféle innen-onnan elejtett infók alapján. Az AMD vs Intel kérdésben én csak eltérő nézőpontokat láttam, innentől kezdve kár is volt annyit ragozni a témát.
Fiery:
-
Thrawn
félisten
"szerintem mindenkinek úgy tűnik"
Az a szerencséd, hogy a "szerintem" szó ott van. Egyébként meg kikérem magamnak.
Az különösen zavar, hogy van aki leírja szárazon a tényeket és erre te nekiesel a ződszemüveggel úgy, hogy közben nem veted meg a személyeskedést sem. Ja és mindezek tetejébe a másikat vádolod kékszemüveg miatt, holott marhára nem így van, csak te látod bele. Nekem, akinek tökmindegy, hogy Intel vagy AMD eléggé szembeötlő ám a mutatványod.Megemelem a kalapom Fiery előtt az elmúlt napok történéseit követve, hogy hellyel-közzel türelemmel viseltetett több fórumozó felé is (nem csak ebben a topikban), akik mintha elfelejtették volna, hogy olyasvalakivel állnak le vitatkozni akinél ott figyel egy Kaveri...
Nálam többször elszakadt a cérna, pedig csak olvasó voltam, írni a modkerbe írtam. Nem történt semmi intézkedés, csak egy privátot kaptam, hogy jól van ez így, meg ez amúgyis egy ilyen topik. Hát akkor offba teszem ezt a hszt is és akkor pont jó lesz ide. -
Fiery
veterán
"de szerintem mindenkinek úgy tűnik, hogy te kárörvendesz ezen."
Legfeljebb neked.
"Amit a kacsintól smiley is csak erősít."
Marmint szerinted. Kerj a forum fenntartoitol egy kulon "karorvendoen kacsinto" es egy "kacsintos, de nem karorvendo" smiley ikont, hogy egyertelmu legyen, hogy melyiket kell hasznalni. Hidd el, onnantol mindenki oda fog figyelni arra, nehogy Dezz felreertse a felhasznalt smiley tipusat. Addig meg kerlek ne taplald bele masokba a sajat velemenyedet es elkepzeleseidet, plane amikor nyilvanvalo rosszindulat vezerel.
-
Fiery
veterán
"Megtudhatnám, miért
van a hsz-ed végén 
helyett?"A kacsintos smiley annak szolt, amit elotte TESCO-Zsömle irt ("komoly egy roadmap"). Nem oromot fejezett ki. Engem teljesen hidegen hagy, hogy mikor jon a Carrizo. Pontosabban nem, hiszen sok szempontbol is fontos nekem az, hogy mikor jelenik meg, de nem leszek szomoru, ha kesobb jon, mint X idopont, es nem leszek boldog, ha hamarabb.
-
Abu régebben valami olasmit mondott, hogy a Jaguar kicsit gyorsabb csak a Cortex A16-nél azonos frekin, de a 64 bites ARM procik jóval gyorsabbak, és valami Sandy Bridge-es összehasonlítást említett azonos frekin.
Lehet, hogy félreértettem, ez esetben sorry.Persze, a magméretekkel és fogyasztásokkal nem vagyok tisztában a fenti összehasonlítás kapcsán, pedig ez is nagyon érdekes infó lehet.
Abu, ha olvasod, kérlek, erősíts, vagy cáfolj meg! Kössz!
-
Fiery
veterán
A K10 elott volt egy K9, ami kukazva lett, ott kezdodott a rossz szeria. Tehat K9, K10, Bulldozer, Komodo, ez nem csak egy atmeneti benazas meg 1-2 rossz ev, hanem folyamatos benazas. Lenyegeben az ATI felvasarlasa ota nincs teljesitmenyben is versenykepes x86 CPU-ja az AMD-nek. Pusztan veletlen egybeeses?
Az Intelre meg lehet mutogatni, de attol, hogy valaki nyomas alatt van, me'g lehet jo termeket tervezni, pl. az Opteronok a nehez idoszakban is eljutottak rengeteg gyarto gepebe. Aztan meg kikoptak megint, mert megint volt jobb valasztas. -
Fiery
veterán
Nem egy lufirol beszeltem, hanem tobb lufirol. K10, Bulldozer, Komodo, most meg a HSA. De ahogy fentebb is leirtam, ne legyen igazam a HSA-val kapcsolatban.
"az AMD segítsége nélkül zátonyra futott volna a projekt, az ATI pedig valószínű csődbe jutott volna."
Remelem, itt a penzugyi segitsegre gondolsz, es nem a mernokire
"Az AMD mérnökei segítettek kipofozni."
Persze, egyik naprol a masikra felvasarolsz egy GPU-gyartot, majd te segitesz nekik ugy a mernoki gardaddal, hogy elotte neked semmilyen GPU-fejlesztesi tapasztalatod nem volt. Abszolut eletszagu.
"A GCN-t pedig már együtt hozta létre a két cég mérnökeiből álló csoport."
Nyilvan egyutt hoztak letre, hiszen a Fusion projekt megkovetelte, hogy bizonyos szempontbol egymasnak rendeljek ala a fejleszteseket. De az azert megiscsak furcsa, hogy az AMD-s felvasarlas ota nem tudott az ATI reszleg rossz termeket produkalni, mig az AMD x86 magokkal kapcsolatban hat finoman szolva sem csak success story-k voltak az utobbi 5-6 evben.
"A megfogalmazásod is elég furcsa: ha van kivétel, akkor nem mondhatod, hogy csak a GPU-ik jók."
Egyetlen udito kivetel van, igy igaz. Eleg sovany vigasz.
-
Fiery
veterán
A lelkesedessel nincs baj. A tulzott lelkesedes nem celravezeto, plane ha csupan azon alapszik, hogy a gyarto felfuj egy szep nagy lufit
A tenyek viszont azt mutatjak, hogy amiota az AMD megvette az ATI-t, azota az ATI-nak van AMD-je, es nem forditva. Maskepp fogalmazva: csak azok a termekek utnek nagyot, ahol az ATI vonal a dominans, azaz ahol a GPU kore epul a termek. Kivetel ez alol a Jaguar, ott az AMD (CPU) resz is remek. -
Fiery
veterán
Engem nem zavar semmi, csak az szokott mosolyt csalni az arcomra, amikor egy adott marka fanjai a nyilvanvalo tenyeket is figyelmen kivul tudjak hagyni
Es a makacs tenyeket is konkret tamadasnak veszik az imadott marka ellen. Ja, meg az is mokas, amikor a jovorol jelen idoben kepesek beszelni, mint ha mar megnyertek volna egy me'g el sem kezdodott haborut ![;]](//cdn.rios.hu/dl/s/v1.gif)
Akinek nem inge, ne vegye magara persze. -
leviske
veterán
-
lee56
őstag
Na igen, és mivel ezt az utat választották, ez talán egy kicsit legalább növeli annak az esélyét, hogy még érkezzen (SR-el) frissített FX is AM3+ba jövőre és párhuzamosan kicsit tovább létezhetne a két platform. Remélem ezt még azért meglépik, bár ha tényleg gondok vannak a sebességgel (mármint a GHz-ekkel) az nem a legjobb hír ebben az esetben sem, mivel ugye ez a moduláris felépítés még mindíg magas működési frekvencián teljesít(ene) a legjobban.
-
Oliverda
titán
Az azért meglepne, ha a SteamrollerB és a PiledriverV2 között nem lenne legalább 10%. Persze a Kaveri-ben nincs L3, így bizonyos területeken nehéz lesz kimérni a különbséget.
Láttam olyan pletykákat, miszerint már a Kaveri is megkapta a HDL-t, ami magyarázhatja a néhány 100 MHz-es órajelcsökkenést. Ezzel együtt sem tragikus a helyzet, mivel az 5800K szintje várható, ergo a 2900 MHz-es alapórajelről szóló pletykáknak nincs alapjuk.
-
Fiery
veterán
Oke, de ha innen nezzuk, akkor a Kaveri marad a bejelenteskori orajeleken, es majd a Carrizo fogja megint felnyomni az orajelet oda, ahol a Richland van most. Vagy a Carrizo csuszik fel-egy evet, es jon egy uj, koztes core (mint a Richland anno), ami egyenlo lesz a Kaverival, csak Richland orajeleken fog futni. Ertem en, tok logikus
De mindez semmit nem valtoztat azon a tenyen, hogy valami a Kaveri orajelei korul nem gombolyu. -
Fiery
veterán
"hogy viszonylag alacsonyabb órajelen vezeti be a termékeit, később pedig, ahogy tudja, folyamatosan növeli azt"
Ez a Trinitynel meg a Richlandnel is igy volt? Mert nekem baromira nem igy remlik. Hanem pont ugy, hogy az A10-5800K es a A10-6800K kijott a bejelenteskor, es utana nem jott utanuk magasabb SKU.
Teny, hogy az FX vonalon elofordult az ilyen faragas menet kozben, de most az APU-krol van szo, nem a hagyomanyos ertelemben vett CPU-krol. Megjegyzem, a Llanonal is csak +100 MHz-et sikerult kifacsarni menet kozben, ha jo remlik:
Ehhez kepest, most a Kaverinel nem 100 MHz-rol beszelunk (amennyivel alacsonyabb a CPU orajele, mint a 6800K-nak), hanem joval tobbrol. Remelem, be tudja hozni az AMD, mert amig nincs _kezzel foghato_ HSA, addig max. azoknak lesz tuti valasztas a Kaveri, akik mondjuk sokat jatszanak es nem akarnak dGPU-t venni.
-
#13301
Menthirist
veterán
dezz
#13300
kérdés, mennyi "jobb konzolport" lesz, pláne hogy ugye az intel és az nvidia sem leírható tényező
Mivel azoknak is meg kell felelni, így lehet hogy a 2x annyi mag / intel szál azért csökkenti a különbséget.trueaudio téren meg ugye pont azzal példálóztak, hogy helyben van a 3d-s tér minden adata, szóval abból jobban lehet penge 3d-s effekteket gyártani.
-
Fiery
veterán
Ha az AMD komoly veszelyet latja annak, hogy a DP korlatozas miatt nem terjed a HSA megfeleloen, es a vas maga amugy tudna tobbet is nyomni DP-ben, akkor barmikor feloldhatja a DP korlatozast egy HSA driver frissites (+ esetleg egy mikrokod update) segitsegevel. De szerintem nem lesz ez akkora korlat, hogy a HSA utjaba alljon.
-
-
Fiery
veterán
A linkelt oldalon ott van, hogy ha az AMD igy fejlesztgeti a Kaverit, akkor me'g a vegen a 4770K-ra is veszelyes lehet a Kaveri. Ez a f***sag, legalabbis ha az x86/x64 magokrol beszelunk. A tobbi baromsag mar kisebb f***sag, pl. hogy 1.8 meg 2 GHz-es procival benchmarkolnak, meg A0 steppinggel, meg hogy 1-2 nevtelen benchmarkot futtatnak, oszt annyi. Vagy valaki ismeri ezt a konkret benchmarkot, ami a "cikkben" szerepel?
"Ezt hogyan, tekintve, hogy az egyik VLIW5, a másik pedig GCN?"
Te is mindig kijavitasz, a legkisebb bakiknal is, ugyhogy en is hadd javitsalak ki: VLIW4 a Trinity/Richland, nem VLIW5
A Kaveri meg GCN2 vagy GCN 1.1, de ez a kisebb problema. Az SP/DP arány nem architektúra függő, barmelyiken barmennyi lehet lenyegeben, attol fuggoen, hogy fizikailag hany DP feldolgozot pakolnak be egy CU-ba, ill. hogy mestersegesen mennyire fojtjak le a teljesitmenyt. Amennyire en tudom, a Trinity/Richlandnel az SP/DP arány fizikailag 1:4, de a FirePro termekeket kiveve mindenhol 1:16-ra korlatozzak a teljesitmenyt. A Kaverinal velhetoen ugyanez lesz a megoldas, de az legalabbis tuti, hogy a "sima" SKU-knal 1:16 lesz az SP/DP arány a gyakorlatban, ennel nincs tobbre szuksege a felhasznalok 99%-anak."De vannak esetek, amikor elengedhetetlen a DP."
Arra lehet AVX kodot is irni
DP-ben a Richland (es mellesleg a Kaveri is) gyorsabb AVX-szel mint az iGPU-val. Kimértük, nem kitaláció. -
Fiery
veterán
Minden AIDA64 benchmark tobbszalu. Probald ki a gepeden, a Task Manager-ben szepen lathato, hogy mi tortenik.
"A legnagyobb durranás az IGP GCN alapúra váltása. Másodsorban pedig a HSA"
Ebben egyetertunk. De pont ezert, meg mert az x86-os reszen alig van valtozas, nem erdemes feszegetni azt, hogy nem kifejezetten az iGPU-ra tamaszkodo szoftverek eseteben lesz-e elorelepes.
-
-
Fiery
veterán
"Ez az egész így találgatás szerű."
Nem csak a doksi, mert kapasbol a Kaverirol beszeltunk az AMD-vel, ok emlitettek, hogy az egyik PC-gyarto intett be nekik, hogy a GDDR5 magas ara miatt nem fognak epiteni ra PC-t, ha megfeszul az AMD, akkor se. Ez dontotte el a kerdest. Ugyanigy beszeltunk veluk a Beema/Mullins problemarol, akkor emlitettek, hogy a HSA tamogatas ki fog maradni beloluk. Be szerették volna rakni, de nem jott ossze. Egyebkent az is beszedes, ha megnezed a Beema/Mullins BKDG-t, es abban a reszben, ahol az eloddel hasonlitjak ossze, hogy mik a valtozasok, nem a Kabinivel vetik ossze, hanem a Brazosszal. Akarcsak a Kabini BKDG, ott is a Brazosszal vetik ossze. Es akarhogy nezed a BKDG-t, nincsenek jelentos valtozasok, csak apro faragasok itt-ott. Ennel me'g a Trinity --> Richland valtas is eroteljesebb volt. Teljesen nyilvanvalo (szamomra) ez alapjan, hogy a Beema/Mullins se ugy sikerul, mint ahogy kellett volna neki. Ha mindezek alapjan azt mondod, hogy talalgatok, oke, elfogadom, Te igy latod a dolgot.
"te vezényled a fejlesztést és intézed az egyéb ügyeket."
Igy igaz. De attol, hogy valaki vezenyli a dolgokat, me'g nem jelenti, hogy o nem kodol. Lasd vadaszgep kotelek, ahol a kotelek vezetoje (wing commander pl.) ugyanugy a tobbiekkel repul, ugyanugy harcol, ugyanugy benne van mindenben
"BTW, az OpenCL benchmarkban alkalmazott eljárások inkább az AMD-nek fekszenek jobban, vagy az Intelnek?
Mint tudjuk, egyes dolgokban az egyik a jobb, másban a másik"Mindegyik gyarto sz*r OpenCL compilert csinal, csak mindegyik maskepp sz*r. De nyilvan egy igazan jo benchmarkot ugy kell fejleszteni, hogy minden gyarto minden termekebol ki kell hozni a lehetoseg szerinti maximumot. Az, hogy egymashoz kepest mikepp neznek ki a teljesitmeny ertekek, jovo honapban, az AIDA64 v4.00-nal meglatod
"Ezt a nem mellékes körülményt eddig nem közölted"
Olvass vissza, mar legalabb 2x leirtam fentebb.
"Szerintem csak felületesen szemlélve tűnik könnyen lekoppinthatónak"
Erre mar tenyleg nehezen tudnek mit mondani
Legyen igazad, maradjunk ennyiben."Erre térjünk majd vissza akkor, ha az Excavator is vacaknak bizonyul."
Me'g a Steamroller se jelent meg, es Te mar az Excavatort rangatod ide? Ja, tehat mindig a kovetkezo generacio a megvaltas?
Kar, hogy mindig lesz kovetkezo, mindig lesz miben bizni. Az eddigi leak-ek es infok alapjan szerintem business as usual lesz az Excavator: kijavitja a Kaveri apro hibait, hoz egy teljes HSA implementaciot (me'g a Kaveri sem full HSA, csak ugy mellesleg), es kicsit gyorsabb lesz, mint az elodje. Az meg tok mindegy, hogy hany x86 modul lesz benne, hiszen tudjuk, hogy az x86 teljesitmeny mar most is boven sok.Egyebkent sosem mondtam, hogy az Excavator vacak lesz. A Bulldozert en az AMD helyeben nem vinnem tovabb, de lehet, hogy megis megcsinaljak, csak erosen ujragondoljak nehany ponton. Ha igy lesz, akkor legalabb olyan jo lesz, mint a Kaveri, az meg tulajdonkeppen nem rossz cucc, csak mondjuk CPU/FPU-ban van erosebb is -- dragabban. Ha Jaguarra valtanak, akkor meg me'g jobb lesz a helyzet.
"Ez meglehetősen rosszmájú, alapvető tényeket és iparági trendeket ignoráló megjegyzés volt."
Milyen tenyeket ignore-altam? Azt, hogy az AMD legyint az x86 magokra, hogy "az ugysem szamit" ? Ennyi erovel barki legyinthet a konkurenciara, hogy "ja, hát igen, ők jobban csinaljak, de ugysincs ertelme rohanni". Az ilyen arrogancia nem szokott sok jora vezetni...
"A félvezetőgyártás jelen helyzetében CPU téren 5-10 éves távlatban még az Intel sem fog tudni jelentősebb változást felmutatni."
Most akkor a jelenrol beszelunk vagy a kovetkezo 5-10 evrol? Megjegyzem, ugyanazt a lof***t (a fizikai hatarait) fogja sz**ni az AMD es az Intel is, csak az AMD _velhetoen_ ugyanugy le lesz maradva a kovetkezo 7 evben is 1-2 processz generacioval.
"A számításigényes feladatok jó részét a CPU-ét messzem meghaladó számítási teljesítményű IGP-re lehet bízni"
Biztos, hogy messze meghalado? Biztos, hogy ez nem valtozhat meg akarmikor? Egy masik topicban altalam felvazolt 4 GHz koruli orajelen futo, AVX-512-t tamogato, 6 magos CPU siman x86 CPU-bol nyomna kb. annyi TFLOPS-ot, mint a Kaveri iGPU-ja. Plusz ehhez jonnek me'g a MIC magok vagy barmilyen mas iGPU. Az AMD kozben elhanyagolja az x86 core-okat, arra jatszva, hogy az Intel ugysem tud drivert meg SDK-t fejleszteni majd a MIC-hez meg az AVX-512-es CPU magokhoz. A 2015 erdekes ev lesz
"Néhány éves távlatban csak ezzel lehet jelentősebb teljesítménybeli előrelépést prezenlátni, ezért nagyon is ezen lesz a hangsúly."
Biztos?
-
Fiery
veterán
"Tudod az igazságot? Annyit tudsz..."
Annal kicsit tobbet tudok, de hagyjuk, nem lenyeges, hogy mit tudok es mit nem, nem rolam szol (nem rolam kene, hogy szoljon) ez a vita.
"Több millió termék lesz még a piacon az új konzolok képében"
Bocsanat, nem hangsulyoztam ki, hogy a PC-rol beszelek. Megjegyzem, ez a topic is a mainstream PC-kbe valo AMD processzorokrol szol. De azt azert jegyezzuk meg, hogy a konzolok kozul -- ha jol tudom -- csak a PS4 APU-ja tamogat HSA-t.
"Elhiszem én, hogy több vagy, mint egyszerű manager, de mint magad is írtad már korábban, Balala a kóder"
A CPU+FPU+memoria benchmarkok fejlesztoje nem en vagyok, de attol me'g fejleszto (koder, stb) vagyok. Pl. a hamarosan megjeleno AIDA64 v4.00 OpenCL GPGPU benchmarkjait es annak a GUI-jat is 100%-ban en keszitettem. Meg me'g ezer mas dolgot az AIDA64-ben.
"A Bulldozer kicsit más eset volt. Maga a koncepció jól nézett ki (és szerintem kisülhet még belőle valami, ha elmúlasztják a gyermekbetegségeit), de te akkor már tudtál 1-2 konkrét gyermekbetegségről. Utána már csak reménykedni lehetett, hogy egy újabb steppingben javítani tudják ezt, de annál komolyabb beavatkozásra lett volna szükség. Most viszont te is csak találgatsz."
Ez pont hogy ugyanaz az eset. Anno benchmarkoltuk a Bulldozert, es meglepodtunk rajta, hogy milyen gyatran muzsikal, legalabbis az elozetes hype es a konkurencia teljesitmenyehez kepest. Most is van gazdagon hype a Kaveri meg a HSA korul, nalunk van egy Kaveri, amin fut egy alpha allapotu HSA implementacio (mivel annal jobb me'g nincs). Benchmarkoljuk, tesztelgetjuk nap mint nap ezt a konfigot. Pont ezek alapjan a tapasztalatok alapjan mondom azt, hogy a HSA tul konnyen lekoppinthato, ill. hogy a Kaveri leginkabb csak iGPU-ban eros(ebb, mint a Richland). A HSA mint koncepcio is jol nez ki egyebkent
Egyebkent mulatsagos latni, hogy a Bulldozer elhibazott alapkoncepciojat "gyermekbetegseg"-kent aposztrofalod. En inkabb alapveto architekturalis mellefogasnak mondanam, amit csak azzal tudott elfedni az AMD, hogy baromi olcson adta (adja) az FX-eket. Azota meg csak azt hallani, hogy a CPU/FPU nem is lenyeges, bezzeg az iGPU meg a HSA. Persze ha valamely adatnal az AMD kerul elonybe, akkor hirtelen az lesz a legfontosabb, pl. 8 mag es 5 GHz-es orajel. Akkor hirtelen megint a CPU/FPU resz kerul fokuszba. Milyen erdekes
-
leviske
veterán
Az elmélet azt mondja, hogy egyértelműen profitálnia kéne, de a gyakorlatot még meglátjuk. A BF4 szép példa lesz a Kaveri bevethetőségére, mert CPU igényesebbnek ígérkezik (a multi miatt), mint a többi Frostbite3-ra épülő játék.
(#13204) Fiery: Azzal semmi gond nincs, hogy nem csak jót feltételezel az AMD-ről. Azt is fontos tudni, mert legrsszabb esetben nem esik pofára az ember. A gond azzal van, amit korábban említettem. Más szóval, hogy az Intelt idealizálod. Ha ők előállnak évekkel később egy megoldással "úgyis az ő megoldásuk lesz elterjedtebb", ha lemásolják, akkor is... Remélem erre még emlékszel, ugyanitt írtad.
-
Fiery
veterán
"De nem is értem, hogy nem vagy tisztában vele, hogy az egyik a CPU modul mikroarchitektúrális kódneve, a másik pedig az egész lapkáé."
Hogyne lennék tisztaban vele. Csupan en osszekotottem fejben azt, hogy a Kaveri 1.0-nak SteamrollerA magjai vannak, a Kaveri 2.0-nak pedig SteamrollerB magjai. Szamomra ez igy lenne logikus, kiveve persze ha a Kaveri 1.0 vs. 2.0 valtas egyaltalan nem az x86 magokrol szolt, hanem az uncore-rol vagy az iGPU-rol vagy barmi masrol, ami nem az x86 maghoz kotodik. De az egeszrol tul keveset tudunk, ugyhogy felesleges is ezt a csontot ragcsalni...
-
Fiery
veterán
"A GDDR5 a DDR3-on alapul, ugyanazzal a memóriavezérlővel lekezelhető (kb. mint ahogy az AM2+/AM3 Denebnél volt, csak ott DDR2/DDR3)."
Nyilvan lekezelheto ugyanazzal (bar azert nem ennyire egyszeru a dolog, de ne menjunk bele a reszletekbe), de pl. onmagaban a validalas es a BIOS implementalas miatt baromira nem mindegy, hogy egy CPU/APU DDR3-at tamogat (ahogy vegul a Kaveri 2.0 megjelenik hamarosan), vagy DDR3+GDDR5-ot. Azert valljuk be oszinten, a Kaveri sokkal nagyobbat durranna, ha GDDR5-ot (is) tamogatna. Ehhez me'g reszrehajlas sem kell, egyszeruen a marketing erteke is nagy lenne, pl. lehetne dobalozni sok GHz-es memoria orajelekkel es izmos savszelesseg ertekekkel. De majd a Carrizo (talan).
"És igen, szeretnénk azt hinni, hogy a Kaveri 2.0 nem butább, hanem okosabb lesz, mint az eredeti. Szerintem nem kell ehhez vérfannak lenni."
En is szeretnem ezt hinni, csak en kozben tudom az igazsagot. Ehhez meg nem kell masik oldalrol fannak lenni
"És mi köze ennek a Kaverihez, ami viszont támogatja a HSA-t és egy teljesen másik vonal?"
Alapvetoen baromi sok, hiszen a Kaveri mellett jol jott volna, ha az olcsobb termekek is HSA tamogatassal jelentek volna meg. Ha a Beema/Mullins nem tamogat HSA-t, akkor 2014-ben vegig csak a Kaveri lesz, semmi mas termek a vilagon, ami HSA-t tamogatna. Jo, persze, ott lesz a Bald Eagle meg a Berlin, de azok Kaveri pepitaban. A HSA sikere szempontjabol baromira nem mindegy, hogy hany termek tamogatja.
"Tudod, egy idő után kicsit fárasztó az egyik irányba folyamatosan negatív spekuláció, a másik oldal dícsérgetése mellett."
Es a Bay Trail? Azt megint nem olvasta el senki? Vagy azt csak nyugtazod, hogy igen, az Intel sz**t (marmint gyenge iGPU-t) csinalt megint, es lepjunk tovabb?
Nem gond ez sem, csak tisztazzuk."Aztán meg állj neki lefanozni őket ezért..."
Nincs semmi baj azzal, ha valaki fan. Csak ne oltsa le a masikat csupan azert, mert o nem fan. De ez csak az en velemenyem.
"Nos, én azt remélem, hogy a SteamrollerB jobb, nem pedig rosszabb, mint az eredeti Steamroller."
Ezt egyszer mar eljatszottuk a Bulldozer kapcsan. Akkor se hitt nekem senki, mindenki csak remelte, hogy **rva jo lesz. Lehet remelni ismet, mar csak 1-2 honap, es kiderul minden. A Kaverinak legalabb annyi remenye van, hogy van egy iGPU-ja, ami nagyon jo, es jon a HSA (majd, valamikor, amikor vegre kesz lesz az implementacio a Catalysthoz).
"Yutani: Ami azt illeti, nem ő a program aktív fejlesztője (a kóder). Szerintem ő a manager."
Rosszul tudod. Ha nem hiszed, tesztelj le privatban. Kerdezz valamit, amire egy manager nem tudhatja a valaszt. De ha gondolod, be is ugorhatsz hozzank, megihatunk egy kolat egyutt, es ellenorizheted a kiletemet. No smiley.
-
Fiery
veterán
"Kíváncsi lennék, hány helyen süti el ezt még Fiery - ahol nem akad valaki, aki ezt így leírná... Valóban teljesen elfogulatlan hozzáállás, hogy az AMD-ről folyamatosan csak rosszat feltételez, az Intelről pedig csak jót."
A mondandom melyik reszevel van problemad? Azzal, hogy GDDR5-t akart az AMD a Kaveri mellé? Megcsinaltak, csak a konzolokba jo volt, a PC-be tul korai. Vagy ha nem ez a gond, akkor mi? Nekunk pl. az AMD a HSA kapcsan olyan slide-ot mutatott, ahol a Kaverira "Kaveri 2.0" neven hivatkoztak, es amikor rakerdeztem, akkor ment a terelés. Jelentsen az barmit is. A lenyeg, hogy a Kaveri nem az lett, aminek indult -- de ha valaki AMD fan, akkor ezt ugy is lehet ertelmezni, hogy jobb lett, mint aminek terveztek
A tobbi, amit leirtam, pl. a Kabini meg a Beema/Mullins kapcsan, azt szinten az AMD mondta el, nyilvan itt nem fogok specifikumokat emliteni. Mindenesetre az mar onmagaban is furcsa, hogy a Beema/Mullins feature szinten megegyezik a Kabinival, pl. nem tamogat HSA-t, azonos processzen keszul majd, stb. Errol mi jot lehetne irni? Richland ujratoltve, kiadjuk ugyanazt, ujra, kicsit boostolt orajelekkel, uj kodneven. A Kabini jo cucc, CPU-ban legalabb olyan jo, mint a Bay Trail, iGPU-ban pedig ezerszer jobb. Plane ugy, hogy a Bay Trail iGPU-jaban is vannak negativ meglepetesek -- figyeled, rosszat irok az Intelrol, jegyezd fel azonnal! Peace, nemtom miert kell mindent veresen komolyan venni... Vagy ebbe a topicba csak AMD-s szemellenzovel szabad postolni? Ha igy van, akkor szivesen atmegyek mashova dumalgatni az AMD termekeirol. -
-
leviske
veterán
Ezt én értem, de nekem úgy rémlik, hogy a Bulldozer egyik nagy újdonsága volt, hogy 2magonként van 1 FPU és ha 1 modulba 8 mag lesz és ahhoz az egy modulhoz hozzá van szorosan kötve a IGP, akkor szerintem nincs sok értelme azt visszaduplázgatni a kivezetés helyett.
MOD: Értelmesebben összefoglalva: Szerintem, ha igaz lesz, akkor a BGN-ig inkább kivezetni kéne az FPU-t és rábízni a feladatait az IGP-re.
-
TomiLi
addikt
De saját magát hátráltatja az AMD ezzel a stratégiával szerintem. Nehezebben fogynak az FM2 lapok, ha már jelen vannak az FM2+-osok is ami mindent visz (trintiy/richland/kaveri).
Persze lehet csavarni rajta a fentebb említett módon....jaj majdnem elfeljtettem az off-ot...
(#13166) atti_2010 viszont logikus!
-
leviske
veterán
Azért az, hogy a PCIE-n keresztül nem közvetlenül kapja az információkat, felteszem mélyebben érintené az egész rendszert, mintsem hogy megoldható legyen egy egyszerű letiltással. Vagy tévedek?
(#13110) Fiery: Akkor már sikerült belekevernem a konzolok lapkáját, elnézést.
A lényeg, hogy nőtt volna a csatornák száma. Ebből fakadóan viszont érdekes, hogy FM2 kapcsán került szóba, hiszen tudtommal eléggé megnyomja a gyártási költségeket. Bár lehet ettől függetlenül megérte volna, elvégre 192bit-en már mégse lenne annyira hátrány a DDR3 sem. -
Fiery
veterán
"Miért? Akkor másokra hárulna az OpenCL, Java, stb. fordítók elkészítése, az Intelnek - a többi gyártóhoz hasonlóan - csak a HSA Finalizert kellene elkészítenie a HW-eihez"
Mert akkor csatlakozniuk kene a HSA Foundation-hoz... Azt meg nem akarjak. Ha meg mar nem csatlakoznak, akkor miert eroltessek magukra a HSAIL-t? Szuksegtelen.
"Már ha jelenleg van bármilyen IL-e az Intelnek"
Van nekik. Naluk is 2 lepcsos a forditas OpenCL 1.x-nel, azaz elso lepcso: OpenCL --> Intel IL, masodik lepcso: Intel IL --> iGPU gepi kod.
"Csak a józan ész"
A jozan esz azt diktalja, hogy az IL szintjen ne kelljen foglalkozni az utemezessel. Az x86 sem arrol szol, hogy mikepp utemezed a kodot, hogyan futtatod le (in-order, pipelined in-order vagy out-of-order). A nyelv szintjen nem kell ezekkel foglalkozni, plane ha queuing megoldasrol van szo.
"Ha volt, akkor kétfelé kell bontani (OpenCL->IL, IL->GPU ISA), az IL szintaxisát módosítni, a meglévők mellé új funkciókat beilleszteni."
Nem kell az IL-t modositani. De ha kell is, akkor sem akkora kaland modositani, mint atallni a forditokkal (mert ugye 2 forditorol beszelunk) egy teljesen uj IL-re.
"A HSAIL-t alapvetően az AMD dolgozta ki, nyilván építettek a meglévő IL-re is, ha volt olyan."
Van nekik is, ezt Abu is leirta fentebb. Mindharom gyarto ugyanazt a felepitest hasznalja, amit anno az nVIDIA kitalalt (ha o talalta ki). Nem tudom, az AMDIL es a HSAIL kozott milyen relacio van, de az biztos, hogy a jelenlegi OpenCL 2.0 --> HSAIL --> Kaveri iGPU gepi kod fordito megoldas teljesitmenye eleg messze van az OpenCL 1.2 --> AMDIL --> Kaveri iGPU gepi kod forditoetol
Ergo, vagy az AMD benazik, vagy a HSAIL teljesen mas mint az AMDIL. A logikai es az eddigi tapasztalatok azt diktaljak, hogy az utobbirol van szo."A dinoszauruszok is sokáig uralták a Földet, de aztán változások álltak be, amihez nem tudtak alkalmazkodni (mert megszokták, hogy addig nem kellett semmihez), szépen ki is haltak. Az x86 sokat veszített a befolyásából, és elég kicsi az esély, hogy ezt az egészet az Intel az ellenkezőjére fordítja."
2006-ban azt se gondolta volna senki, hogy a Nokiat par ev alatt el lehet soporni
Az Intel pedig mar azert ott van a "szeren" 30 eve (akarcsak az AMD, mellesleg), az x86 pedig eddig bizonyitott. A Silvermont baromi jol sikerult (akarcsak a Jaguar). 10 colos full passziv huteses slim profile tablet = 12-14 ora egy feltoltessel, 4 magos Bay Trail-T procival -- ezt is ki gondolta volna 2-3 eve? Hidd el, az x86-ban me'g nagyon sok minden van. A MIC talan nem valtja meg a vilagot, de rengeteg otlet van me'g a fiokok mélyén ill. a mernokok fejeben. Nekem is lennenek naiv otleteim, pl. hogy mikepp lehetne kivaltani az iGPU-t CPU-val, de majd az Intel _talan_ megcsinalja, amig az AMD a HSA-t nyomatja. Izgalmas lesz a kovetkezo 2 ev. -
Abu85
HÁZIGAZDA
Mondhatjuk így is, de a HSAIL-re direkten kódot írni olyan mint assembly-ben programozni. Nyilván nem kizárt, hogy lesz olyan, aki ezt az utat választja, de a fejlesztők többsége valami magasabb szintű nyelvet használ majd.
(#13063) Fiery: Azért az OCL2.0 nem csak egy shared virtual memory és kész. Azért a dinamikus parallelizmus elég komoly queueing modellt igényel. Ezt eddig csak az AMD oldotta meg skálázható formában. Elsősorban azért, mert baromi nehéz. Az NVIDIA-nak van még ilyen parancsprocesszora, de nem skálázzák, hanem minden lapkába áttervezik. Az Intel még nem beszélt róla, hogy milyen queueing modellt csinálnak, ami aggasztó, mert az NV-nek és az AMD-nek már működik a gyakorlatban.
-
Fiery
veterán
"Ezt tudjuk. De ha az Intel megoldása csak hasonlít rá, de eltér tőle, akkor nem feltétlen biztosítható, hogy ugyanaz a kód ugyanolyan jól fut majd mindkét rendszeren."
Ezt sosem tudod 100%-osan biztositani, hiszen az IL/HSAIL --> GPU gepi kod forditas mindig is egy valtozo lesz a kepletben, HSA-n belul is. A HSA-nak es a HSAIL-nek annyi elonye van, hogy legalabb a HSAIL-ig lemenve -- elvileg -- egyforma minden gyartonal a kod. Jelenleg meg ugye csak a legfelso szint (OpenCL kod) fix, onnantol lefele az IL is valtozo (gyartonkent mas a fordito), azutan meg a gepi kodra forditas plane valtozo.
Elnezest, ha felreertettuk egymast. Nekem csak kicsit furcsa, hogy nem erted meg, amit irok, pedig tobbszor, tobbfelekeppen leirtam. Talan meg kene probalnom osszeszedni elejetol a vegeig, es ugy leirni, mert lehet hogy a mondanivalom szettoredezik a sok postban, es nehez kovetni
Errol en tehetek, sorry. Egy pizza+sor/kola mellett egyszerubb dolgom lenne "Itt nem arra gondoltál, hogy a HSAIL-hez ír drivert és arra való fordítást meghagyja másoknak (AMD vagy aki a HSA Foudation keretein belül ezzel kíván foglalkozni)?"
Nem, te jo eg, me'g csak az kene
Pont ezzel szivatja magat a szerencsetlen AMD! Az AMD-nek vegre volt egy hasznalhato, egesz jo minosegu OpenCL --> IL (sajat, AMD-specifikus IL) forditoja, de a HSAIL miatt kenytelen azt ugy ahogy van kukazni, es nullarol irni egy OpenCL --> HSAIL (plusz mellesleg egy Java --> HSAIL) forditot Csupan emiatt csuszik a HSA konkret AMD implementacioja, ezert nem tart sehol a Kaveri szoftver stack Ha hasznalni tudná a regi, jol bevalt OpenCL --> IL forditot, mar kesz lenne a HSA implementacioval az AMD.Az Intel dehogy fog alkalmazkodni, miert tenné? Fogja a meglevo OpenCL --> IL (sajat, Intel-specifikus IL) forditojat, nem kell semmi kulonoset csinalni vele, hiszen az OpenCL 2.0 nyelvi szinten nem valtoztat semmi alapvetot. Egyszeruen ir egy uj drivert meg csinal egy megosztott memorias vasat a cucc ala (tudom, tudom, az nem olyan egyszeru...), es kesz a sajat "HSA"-ja. Ez a baj, ez egy komoly veszely lehet, en ettol feltem az AMD-t. Kitalaltak valami erdekeset, de tul konnyen koppinthato.
"kötve hiszem, hogy ez az IL eleve, már jó előre a HSA új megoldásainak megfelelő lett volna"
Az IL-t is lehet fejleszteni, fel lehet kesziteni a jovo kihivasaira. Plane mivel az AMD mar par eve lovagol az SVM teman, lepesrol lepesre halad elore, kozben az Intel siman megcsinalhatja/megcsinalhatta fu alatt, hogy az IL-jet felkesziti az SVM-re -- plane ha mondjuk menet kozben a vasat is keszitik hozza. _Ha_ keszitik.
"A végén még kitalálod, hogy az AMD másolta a HSAIL-lel és a vISA-val az Intel titkos IL-jét... Ne bohóckodjunk már..."
Kerlek ne adj a szamba olyat, amit soha nem mondanek. Az IL egyebkent sem feltetlenul annyira titkos
"új IL rétegre lesz szüksége (a régi ugyanis nem coherent+unified memory aware, nem támogatja a korábban nem létező fast context switchet és az újfajta queue rendszert)"
Ezt honnan tudod? Van konkret informaciod erre vonatkozoan? Es kulonben is, mi koze az IL-nek a context switch-hez meg a queue-hoz? Lehet, hogy en vagyok tajekozatlan, ebben az esetben kerlek kuldj nehany linket, ahol tajekozodhatok az IL + context switch + queuing relacioban.
"és az OpenCL fordítóját is ennek megfelelően, jelentősen módosítania kell"
Egyszerubb modositani, mint ujat irni (lasd AMD). Es nem kell modositani, hiszen a nyelv nem valtozik az SVM bevezetesevel. Az AMD-nek kell ujat irnia, de az a HSAIL miatt van, maganak csinalta a melot az AMD.
"Kooperációra képtelen"
+
"Ha képesek lennének megfelelő szintű kooperációra, nem kellene mindent saját maguknak (újra) kifejleszteni, ezzel jelentősen csökkenhetne az R&D budget, máris nem kellene vérre menő kűzdelmet folytatniuk az egész világ ellen, hogy azt előteremtsék."Tovabbra is azt mondom, hogy eddig mukodott naluk a dolog, minek maskepp csinalni... Majd ha eljutnak oda, hogy alig lesz profit vagy tartosan vesztesegbe fordulnak, akkor lehet, hogy atertekelik az eddigi hozzaallasukat. Addig aligha. Ne erts felre, szerintem is jobb lenne, ha maskepp csinalnak a dolgokat, de nem latok ra eselyt sajnos.
-
Fiery
veterán
"Szinte? Csak az egyik legfőbb összetevőt hagytad ki, a HSAIL-t és a hozzá tartozó virtuális ISA-t, amik biztosítják, hogy ugyanaz a lefordított bytecode más gyártók megfelelő termékein is futhat, mégpedig a rendszer kidolgozása által viszonylag optimálisan."
Mar leirtam, hogy ha valaki hazon belul akarja megoldani a HSA-t, akkor nem kell neki HSAIL, hiszen csak sajat maganak fejleszti a dolgokat. Hasznalhatja az Intel vagy barki mas a sajat meglevo IL-jet.
"He? Már a fél világ átvette a HSA-t, tucatnyi gyártó termékei készülnek hozzá/vele."
Az Intel (es az nVIDIA sem, mellesleg) akkor se az a fajta, aki atveszi mas megoldasait. Inkabb csinal sajatot, me'g ha az nagyon hasonlit is egy meglevo megoldasra.
"Az sem biztos, hogy az Intel HW-re fejlesztett OpenCL kód jól futna máshol és fordítva. Bár ahogy az Intelt ismerem, éppen erre építenének. Ami viszont visszafelé is elsülhet."
A HSA-nak pont az a lenyege, hogy azon a hardveren es ugy fut az OpenCL/Java/akarmilyen kod, amelyiken a legjobb, amelyiken optimalis. Ha a HSA-t koppintod, akkor ezt a hozzaallast is koppinthatod. Plusz, mar az OpenCL 1.x is ad lehetoseget gyartoi makrokra es egyeb optimalizacios megoldasokra, az OpenCL 2.0 / HSA is ugyanigy ad majd lehetoseget ilyenekre.
"Hasonló a helyzet, az Intel megint utólag próbálna másokra erőltetni egy hasonló, de mégis más megoldást."
Oket hibaztatod? Ha eddig szinte mindig bejott, miert kellene valtoztatniuk a viselkedesukon/hozzaallasukon?
"Akkor nem kellene új fordítót írnia, ha a HSAIL-t és a virtuális ISA-t is lekoppintaná. Amit persze nem tehet meg. (Csak ha belép a HSA Foundationbe és leszurkolja az árát.)"
Azt irtad, progamozol. Ha tenyleg igy van, akkor nem ertem, miert nem erted meg, hogy az OpenCL adott, azt nem is kell masolni, teljesen nyilt. A cucc masik vege meg az a driver ami kommunikal az iGPU-val es atadja a szamitasi feladatokat. Ha nem nyilt rendszert epitesz (ami a HSA), hanem egy HSA-hoz hasonlo, de zart rendszert, akkor **rvara mindegy, hogy a 2 veg kozott mi van, milyen koztes retegek, nyelvek vannak. Senkinek semmi koze hozza. Az Intel felugyeli az egeszet, elejetol a vegeig, kiveve persze az OpenCL-t. Az OpenCL viszont adott. A programozo dolga meg az, hogy OpenCL nyelven irjon egy, az SVM lehetosegeit kiaknazo progit, ami aztan ugyanugy fut HSA-n es az Intel-fele "HSA"-n is. A virtualis ISA (IL) eddig is el volt rejtve minden gyartonal, mert hazon belul ment az OpenCL-kod --> IL --> iGPU gepi kod forditas. Ha hazon belul maradsz, maradhatsz ugyanezen felallasnal, csak hozzapakolod a meglevo OpenCL megoldasodhoz az SVM tamogatast, meg levalasztod a video driverrol az egesz cuccot. De ez utobbi nem OpenCL-specifikus problema, csak a gyorsabb kernel launch miatt lenyeges.
"Szerintem meg nem a pénz a végső értékmérő"
Ha piaci versenyben kuzdo technologiai cegrol van szo, akkor a penz biztositja azt, hogy a kovetkezo technologiai innovaciora is legyen R&D. Nem minden a penzrol szol, de a mernokoknek, tudosoknak valamibol fizetest kell adni... Plusz anyagkoltseg, folyamatos beruhazasok, ami egy vertikalisan integralt CPU-gyartonal brutalis penz megint csak.
-
Abu85
HÁZIGAZDA
A GPU-k közül messze a MIC-nek a legmagasabb a pJ/FLOP mutatója. 2x-3x nagyobb, mint amit az NV és az AMD ma felmutat. Ez azt jelenti, hogy azonos sebességen 2x-3x többet is fogyaszt. A HSA támogatható természetesen, de nincs értelme egy olyan rendszeren megtenni, aminek az alapjai eleve egy bődületes fogyasztásbüntibe taszították az Intelt. Innen a natív programozás az egyetlen reális út. Ezen a ponton azt kell elhitetni a fejlesztőkkel, hogy végül a MIC lesz a piac egyetlen architektúrája, mivel a natív programozás miatt később nincs lehetőség az ISA lecserélésére. Ha ezt megteszik, akkor minden erre írt alkalmazás kukában végzi, mert nem fog elindulni.
-
Fiery
veterán
"A Jaguar az a CPU magok mikroarchitektúrájának a neve, nem?"
De igen.
"Ha kihagynák a HSAIL-t és ezzel együtt a virtuális ISA-t, akkor nincs is miről beszélni, egyszerűen csak egy OpenCL 2.0 fordítót kell készíteniük, ami csak saját HW-re fordít"
Pontosan. Es ezt hivhatjak barminek. Ha kiegeszitik a HSA mas elonyeivel (gyors kernel launch, jobb queing, videodriverrol valo levalasztas), akkor szinte minden elonyet atveszik a HSA-nak, anelkul, hogy HSA-nak "kellene" hivniuk.
"Kérdés, ki lesz kíváncsi a MIC-re?"
Barki, aki nem akarja magat bezarni az AMD okoszisztemajaba
Ami plane annak fenyeben hasznos lehet, ha megnezzuk, mekkora az AMD reszesedese a CPU/APU piacon. Egyebkent ha a MIC tenyleg HSA-szeru lesz, akkor ha OpenCL-re programozol, akkor megkapsz mindent, amit a HSA-val kapsz, legfeljebb nem pont ugyanazt a teljesitmenyt a vegen (a GCN2-t nehez utolerni)."És esetleg lemondhatnak a C++ AMP, .NET, stb. támogatásról is"
Talan. Vagy nem. A Microsoftot nem nehez meggyozni Intelkent, eddig egyetlen esetben nem sikerult (AMD64)
"Full kompatibilis rendszer licencdíj nélkül? Az nem fog menni."
Csak a source végén kompatibilis (OpenCL), a tobbi reszenel meg nem kell foglalkozni a kompatibilitassal, hiszen zart rendszer. Az OpenCL meg nyilt, ugyhogy nincs licencdij tudtommal.
QPI: mondjuk nezzuk meg, milyen piaci penetraciot ert el az egyik mára, es a masik. Melyikbol mennyit adtak el, amiota letezik. Sajnos a technologiai innovacio vegso ertekmeroje az eladasi darabszam ill. a realizalt profit. Ott pedig az Intel vs. AMD osszehasonlitast szinte sosem az utobbi nyeri.
"Az AMD-nek 512-bites memóriavezérlője is van (dGPU-hoz)"
Az Intelnek is van ennyi erovel, sot. Lasd Westmere-EX es a 12 magos Ivy Bridge-EP. A dGPU-kat egyebkent sem kellene direktben egy CPU-hoz hasonlitani, teljesen mas teszta
"Mármint itt ugye full saját platfom(ok)ról beszélsz, HW-rel együtt, ugyebár? Más szóval, nem csak SW szinten kellene lenyomniuk a világot (mármint, hogy valóban csak OpenCL-ben kódoljon mindenki, neadjisten direkte AVX-512-re), hanem HW szinten is (mindenki MIC-et vegyen mindenhova)."
Igy van, kell hozza hardver is, nyilvan. Egyebkent a multban sem volt akadaly nekik, ha nem ok gyartottak a legerosebb CPU-t vagy platformot, annak ellenere is tobbet tudtak eladni, mint a konkurensek. Szoval SZVSZ boven eleg lenne a Skylake-nal, ha hoznak mondjuk a Trinity iGPU teljesitmenyet egy HSA-szeru, MIC vagy nem MIC alapu iGPU-val.
"Ehhez azért kellett az AMD "segítsége" is"
Ez teny
Es mindenki jol jart vele, me'g az Intel is, ha vegre el tudja engedni a nyavalyas Itanicot. -
dezz
nagyúr
Erm, a virtuális API term. virtuális ISA akart lenni.
(#13036) Abu85: De miért ne lehetne egy MIC alapú HSA-s platform?
(#13037) Fiery: "Akkor csak a video driverrol valo levalasztas az elonye, a gyorsabb kernel launch meg a jobb queuing."
Azért ezek is elég hasznos dolgok. De egyébként az utóbbihoz hw támogatás is kell, szerintem.
(#13039): A Jaguar az a CPU magok mikroarchitektúrájának a neve, nem?
A körítés valamennyire biztos más, hiszen hiányoznak a legfontosabb HSA fícsőrök. A memóriavezérlő 4-csatornás a 2 helyett, stb.
Ha kihagynák a HSAIL-t és ezzel együtt a virtuális ISA-t, akkor nincs is miről beszélni, egyszerűen csak egy OpenCL 2.0 fordítót kell készíteniük, ami csak saját HW-re fordít... A MIC-kel/-vel valószínűleg pont ez fog történni. Kérdés, ki lesz kíváncsi a MIC-re? És esetleg lemondhatnak a C++ AMP, .NET, stb. támogatásról is.
"Viszont ha az Intel lekkopintja a HSA-t, akkor neki nem kell uj forditot irnia, hanem csak a drivereket: joval kisebb melo."
Full kompatibilis rendszer licencdíj nélkül? Az nem fog menni.
"Az AMD64-nel se voltak kozrohej targya" - Miért lettek volna? Bepróbálkoztak sajáttal (mármint ami nem kompatibilis), MS nemet mondott, ennyi.
"A QPI me'g sikeresebb lett, mint a HT"
Milyen értelemben?
"es az IMC-bol is az Intel tudta kihozni a legtobbet eddig (ld. LGA2011)"
Az AMD-nek 512-bites memóriavezérlője is van (dGPU-hoz).
"A piacnak siman be tudna adagolni az Intel, hogy csinaltak egy megosztott memoriara epulo GPGPU computing architekturat, ami tok szuper, es az eddigi programok (OpenCL) is mukodnek vele, de uj tavlatokat nyit, blablabla."
Mármint itt ugye full saját platfom(ok)ról beszélsz, HW-rel együtt, ugyebár? Más szóval, nem csak SW szinten kellene lenyomniuk a világot (mármint, hogy valóban csak OpenCL-ben kódoljon mindenki, neadjisten direkte AVX-512-re), hanem HW szinten is (mindenki MIC-et vegyen mindenhova).
(#13040): "hazon belul me'g az IA-64-et is"
Ehhez azért kellett az AMD "segítsége" is...
-
Fiery
veterán
"Talán mert azon kívül, hogy Jaguar és GCN, nem sok közük van egymáshoz?"
Az nem eleg?
Az alap architektura (Jaguar) ugyanaz, a CPU-magok (az uncore resz nelkuli magokra gondolok) ugyanazok, a GPU alapelemei ugyanazok, csak mindenbol kicsit tobb van darabra. Maga az AMD mondta, hogy a Beemahoz nagyon kozel allnak a konzolos APU-k, nem mi talaltuk ki."Ebből és ebből könnyebb mindent újra megcsinálni a világos zöldön kívül, mint csak a kéket?"
A Javat az AMD erolteti, az Intel -- latszolag -- tojik ra, ugyhogy a konkurencia szempontjabol az kevesbe erdekes. Ha meg maradunk az OpenCL-nel, akkor igen, a HSA-t ujrakrealni egy olyan cegnek, akinek mar van elfogadhato szintu OpenCL 1.x forditoja es meglevo, tegyuk fel hogy koherens memoria kezelesre alakithato vasa, nem olyan nagy feladat.
"Hát a virtuális API? Azt 1:1 koppintanák, vagy mégiscsak sajátot készítenének?"
Ha hazon belul maradsz, es nem 10-20 fele ceget meg 4-5 fele platformot akarsz kiszolgalni, akkor nem kell HSAIL. Eleg maradni az OpenCL-nel, azon megirja a fejleszto a kodot, es utana vagy lefordul a mostani OpenCL 1.x forditoval a mostani GPU-kra; vagy lefordul HSAIL-re es onnan futtatja a gep; vagy lefordul valami proprietary IL-re (pl. a meglevo Intel-fele IL-re), es megy a "HSA"-s iGPU drivernek finalizalasra es futtatasra.
Az egesz HSAIL-t nyilvan el kell felejteni, ha valaki le akarja a HSA-t masolni, hiszen azzal tenyleg konkret koppintas lenne. Viszont a HSAIL eletrehivasa pont annyira rossz a meglevo OpenCL fordito tulajoknak, mint amennyire jo. Ha nem lenne HSAIL, csak minden mas, amirol a HSA szol, az AMD mar reg piacon lehetne a sajat HSA SDK-javal. Igy viszont a compilereket ujra kell irnia nullarol, es szivatnia magat a HSAIL-lel. Ok akartak ezt
Viszont ha az Intel lekkopintja a HSA-t, akkor neki nem kell uj forditot irnia, hanem csak a drivereket: joval kisebb melo."Ha előállnának egy HSA koppintással, ami azért se kompatibilis vele, és vernék a mellüket, közröhej tárgya lennének..."
Az AMD64-nel se voltak kozrohej targya, legfeljebb a hasonlo kozegben, mint ez a topic. A nagykozonseg racuppant pikkpakk. A QPI me'g sikeresebb lett, mint a HT, es az IMC-bol is az Intel tudta kihozni a legtobbet eddig (ld. LGA2011). A piacnak siman be tudna adagolni az Intel, hogy csinaltak egy megosztott memoriara epulo GPGPU computing architekturat, ami tok szuper, es az eddigi programok (OpenCL) is mukodnek vele, de uj tavlatokat nyit, blablabla. Nem emlitenek nyilvan, hogy a HSA-t masoltak le, adnanak neki valami Intel SuperComputing API vagy hasonlo nevet, es kesz.
"es vegul az Intel megoldasa me'g jobban is sikerult, mint amit lemasolt."
Ld. elozo bekezdesem.
-
Abu85
HÁZIGAZDA
Nem valószínű, hogy az Intelt egy ilyen rendszer érdekli. Jelenleg sokszázmilliós tranyótöbblettel fizetnek azért, hogy a MIC x86-ra épül (még ha nincs is bináris kompatibilitás), és nem egy speckó ISA-ra. Ha fejlesztenének egy HSA alternatívát, akkor gyakorlatilag az egész koncepcióba feleslegesen öltek 10 évet és sokszázmillió dollárt. A MIC tranzisztorigényének töredékén kihoznának egy hasonló rendszert.
Az Intel koncepciója még mindig az "x86 rule the world". Ha ez nem tetszik a piacnak, akkor is a piaccal van gond és nem a koncepcióval. Majd idővel kiderül, hogy Krzanich mit szeretne a jövőben, mert ugye neki most abból kell egy darabig élnie, amit az elődje ráhagyott, de könnyen lehet, hogy Krzanich már nem válik meg azoktól, akik esetleg meg merik szólni az x86-ot. -
Fiery
veterán
"PS4. (Félig-meddig az XB1 is.)"
Arra a PS4-re gondolsz, ami egy zart rendszer, es olyan HSA-capable APU van benne, aminek "furcsamod" a PC-s megfeleloje (Kabini/Temash), valamint annak utodja (Beema/Mullins) sem kepes a HSA-ra?
Mennyire relevans az a platform ezek utan egy Kabini, Kaveri, Carrizo topicban? Megjegyzem, eleg nagy szegyen, hogy a Beema/Mullins sem tamogatja a megosztott memoriat, mikozben ott a PS4... Az AMD-nel sem minden rozsaszin azert.Raadasul pont azt irod, hogy "programozó vagyok és "bele tudom élni magam" a használatába": ha ilyen szemszogbol nezed a dolgokat (ami nagyon helyes), akkor pont full irrelevansak a konzolok, hiszen azokat a budos eletben nem fogja Te sem, en sem, egyik idelatogato programozo sem programozni, legalabbis ha nem jatekrol beszelunk. Ami relevans, az a Kaveri es Kabini, azokhoz meg a HSA implementacio (szoftver stack) me'g alpha-1 allapotu (Kaveri) ill. semmilyen (Kabini). Azt gondolom nem kell senkinek magyarazni, hogy az alpha-1 milyen messze van a stabil allapottol
"A másik dolog, hogy mit ér a körítés, ha nincs hozzá vas?"
Van az Intelnek vasa (iGPU) hozza, legfeljebb nem annyira gyors, mint a konkurencia. De ennyi erovel a CPU-ban meg az AMD nem eleg eros, szoval valahol ezek kiegyenlitodnek
Fogadni mernek ra, hogy az Intel mar csinalt teszteket, esetleg betas megoldast is konkret vassal, hogy mikepp tudnak implementalni a HSA-t vagy egy HSA-koppintast. Ha a HSA berobban, fel kell hogy keszuljenek ra. Ha a HSA nepszeru lesz, es tenyleg sok elonye szarmazik belole a vegfelhasznalonak, akkor me'g egy gyengebb HSA-capable iGPU-val is jobban jar az Intel, mint ha HSA nelkuli iGPU-val probalkoznak tovabb."de redundáns meló újra megcsinálni az egészet, csak hogy kicsit más legyen, miközben elég lenne egy egyszerű drivert írni a HSA virtuális API-jához"
Lekoppintani pont ugyanakkora melo, es az Intelnek meg is eri, ha utana tudja verni a mellét, hogy azt o talalta fel. Arrol nem is beszelve, hogy mar elofordult nehanyszor a tortenelemben, hogy az Intel is megcsinalt valamit, amit mas mar kitalalt, es vegul az Intel megoldasa me'g jobban is sikerult, mint amit lemasolt.
"Szerintem, ha meglenne már, nem bohóckodtak volna az Iris Proval"
Ez egyertelmu.
-
Fiery
veterán
Nem mondtam, hogy az AMD sz*r. GPU-ban pl. baromi jok, a Mantle is baromi jo otlet, a TrueAudio is izgalmasan hangzik. Azt sem irtam, hogy a MIC mukodni fog, sot. En nem is vagyok meggyozodve arrol, hogy a desktopra valaha eljut a MIC. Meglatjuk.
"Ez ellensúlyozható fejlettebb processzel, de vajon mekkora processz-előny kell ahhoz az Intelnek, hogy ezt valóban el is érjék?"
Ki mondta, hogy maradni fognak mindig a mostani felallasnal? Nyilvan, ha maradna mondjuk a Haswell IGP-je (Gen7.5), es csak a processzt csiszolna az Intel alatta, annak nem lenne semmi ertelme. Ha viszont valtanak valami masra, abban nagyon sok minden benne lehet. Sokfele iranyba lehet indulni, es ha egy legjobb vagy masodik legjobb megoldast valasztja az Intel, es azt megtamogatja egy brutal jo processzel, az erdekes lesz.
"A Physix rossz példa, az a bizonyos "dedikált fizikai gyorsitó" valójában egy viszonylag egyszerű (3rd party?) DSP volt, saját szoftverrel."
Biztos vagy ebben? Csak azert kerdem, mert en konkretan az Ageia egyik tarsalapitojaval beszelgettem a PhysX-rol nem reg, es az o elmondasa alapjan inkabb egy GPU-ra hasonlitott a PhysX, mintsem egy DSP-re. Ugy gondolom, o azert eleg authentikus forras
"Amennyit értesz belőle."
Persze, en nyilvan nem ertek semmihez
Van HSA-capable hardvered? Van HSA SDK-d? Hasznaltal mar HSA-t barmilyen szinten? Benchmarkoltal HSA-t? Nalam ezekre igen a valasz, mindre. En nem csak PDF-et olvasgatom meg elhiszem kritika nelkul a sok marketing maszlagot, amit az AMD az arcunkba tol direktben ill. kulonfele mediumok fizetett hasabjain keresztul."Azért jön majd csak jövőre pl. az Nvidiánál, tudomásom szerint."
Az AMD sincs kesz a sajat HSA implementaciojaval. A Kaveri nincs piacra dobva, a HSA SDK me'g beta allapotban sincs. Az egesz HSA csak jovore jon, iden nem lesz semmi kezzelfoghato belole. Na jo, esetleg egy Kaveri, de nem lesz hozza szoftver stack, megsutheted az egeszet. Ill. nem, mert a GCN2-es iGPU anelkul is mukodik.
"Meg sebtiben összedobnak hozzá egy világklasszis GPU-t is."
Nem azt mondtam, hogy egy eros vasat konnyu tervezni. Azt nyilvan nem konnyu, sot, baromi nehez. De a korites a vas kore nem nagy cucc. Meg nem is erre akartam ravilagitani, hanem arra, hogy a HSA-t baromi konnyu lekoppintani. A HSA egy jo otlet, csak mint otlet nincs levedve. Barki megcsinalhatja ujra, teljesen kompatibilis lesz a magasszintu kod (pl. OpenCL, Java) szintjen, csak nem HSA-nak fogjak hivni.
"Ami valahogy az Intelnek sem jött még össze."
Nem veletlenul nem jott ossze. Nem azt az iranyt eroltetik, csak ezert nem jott ossze. Egy megfelelo MMU-t nem nagy cucc implementalni egy prociba, ne gondold, hogy ezt ne tudná barmelyik x86 gyarto megoldani. Ennyi erovel az AMD-nek meg az eDRAM "nem jott ossze" meg nem tudnak eleg gyors CPU-magot gyartani, nem tudnak AVX2-t implementalni. Dehogy nem tudnak, mindet tudná az AMD is, ha azt akarná csinalni. Csak naluk is mas a fokusz.
"C++, C++ AMP, .NET támogatás..."
Whatever, a fejlesztok nagy resze ugyis OpenCL-en fog nyomulni, mint ahogy eddig is.
"Minek is beállni egy lassan iparági szabvány mögé, félkézzel lenyomjuk a fél világot... Vagy talán mégsem"
Egy olyan "szabvany" moge, amit egyszerubb lemasolni es a sajatodnak beallitani? Vagy egy olyan "szabvany" moge, amihez nincs me'g egyetlen implementacio sem kesz, me'g beta szinten sem?
"pl. mikor neveztek ki Intel szóvivőnek?"
Engem baromira nem erdekel az Intel
Sot, ha szurkolni kene valamelyik cegnek, akkor a VIA-t valasztanam. Ezerszer szimpatikusabb banda, mint a masik ket x86 gyarto. A kritikaimat pedig mindenkivel szemben megfogalmazom, csak lehet, hogy az Intel fele valo szurkalasomat es az AMD-vel szembeni dicsereteimet nem veszed eszre, nem akarod eszrevenni? -
Fiery
veterán
A Haswell nem koherens memoria kezelesre kepes processzor. Ott me'g elnezi az ember azt, hogy benaznak a cache kezelessel. De egy Kaveritol azert en mar elvarnam, hogy normalisan legyen implementalva a cache kezeles, rendesen egy LLC-be dolgozzanak a CPU es iGPU magok. Nem artana egy nagyobb LLC is, de az megint mas kerdes
-
Fiery
veterán
Az (AMD) APU-knal eleve razos dolog beepiteni a cache-t. Az iGPU nem egy FPU, nem olyan relacioban van a hagyomanyos CPU-val, hogy csak ugy meg tudja osztani a cache-eket a CPU-val
Nem veletlen, hogy az APU-kban nincs es nem is lehet hagyomanyos ertelemben vett, a CPU-iGPU altal kozosen hasznalt L2 vagy L3 cache. Me'g a Kaverinal sem ugy mukodik az L2 cache sem, mint ahogy azt a jozan esz diktalna. Jobban hasonlit me'g a Kaveri is egy 2 socketes, cache snoopos megoldashoz, mint egy rendes cache koherenciaval implementalt rendszer. Takolas, mondjuk ki. Jol mukodik a gyakorlatban, de takolas. A Carrizo megint faragni fog ezen, ott pl. mar nem lesz letiltva a iGPU L2 cache-e a koherens memoria hasznalatnal, de ezek az apro lepcsok szamomra tul lassu fejlodesnek tunnek. -
Fiery
veterán
Jo lenne, ha leszallnal a magas lorol ("Szerinted ezt ki nem tudja itt?", "az nem merült fel benned"). Kezdjuk ott, hogy Te kezdtel el mindenfele furcsasagokat kerdezni az eDRAM-rol, ahelyett, hogy utananeztel volna a Crystal Well eDRAM implementaciojanak. De ennyit a szemelyeskedesrol, az amugy sem az en asztalom, nem vezet sehova, es amugy sem kivanatos itt.
Vissza a Crystal Well-re meg az eDRAM-ra. Ha az Intel szamara a nagy cache terulet implementalasara az eDRAM jobbnak tunik, mint az SRAM, akkor fogadd el, hogy innentol eDRAM-rol beszelunk, ha L4 cache a tema. Tok mindegy, hogy eddig mi volt, a technologia fejlodik.
"Hát egy biztos: a MIC mellé kevés lenne az eDRAM egyedüli cache-nek"
eDRAM-bol lehet sokkal nagyobb kapacitasut is gyartani. 84 mm2 = 128 MB, akkor 672 mm2 = 1 GB -- a mostani processzen. Az Intellel az a "problema", hogy annyira nekifekudtek a processzeknek, hogy lassan nem lesz mit gyartaniuk
Tul sok tranzisztort tudnak integralni egy CPU-ba, viszont ki kell talalniuk, hogy mire hasznaljak fel a sok tranzisztort. Az egyik megoldas lehet egy relative alacsony orajelen uzemelo, sokmagos CPU es/vagy egy sokmagos GPU es/vagy egy bazinagy L3 cache es/vagy egy bazinagy L4 cache. Egyelore me'g senki sem tudja (Te sem, Abu sem, en sem), hogy az Intel ezek kozul mely megoldasokat valasztja, hogyan fogja kombinalni a dolgokat. Az tuti, hogy amivel eloallnak, minosegi ugras lesz a mostani Haswell IGP-hez kepest, maskulonben feleslegesen meloznanak. Az is fix, hogy a GPU-k teruleten az Intel fejlodik a legtobbet (%-osan) a mindenkori elozo generaciohoz kepest, mar vagy 4-5 generacio ota. Oke, van honnan (a beka s***e alol), nyilvan, de ha tegyuk fel, a Skylake-kel beerik a mostani Richland szintjet, akkor a Skylake utani generacioval siman lenyomhatjak az AMD akkori APU-jait. Az AMD-nek ugyanis jelen allas szerint nincs utokartyaja, csak egy AVX-ig x86-os CPU-ja harmatos szamitasi kapacitassal, meg egy GCN alapu GPU-ja, ami most me'g eleg jo. Ja, meg a jovo ev elejere lesz az Intelhez kepest 2-3 processznyi lemaradasuk, attol fugg, honnan nezzuk -
Fiery
veterán
Miert ne hozhatnam fel az eDRAM cache-t, ha az cache-kent (is) hasznalhato? A sokkal lassabb DRAM-nal pedig szuksegszeruen gyorsabb az eDRAM cache is, egyszeruen mert kozelebb van a CPU-hoz, es szelesebb/gyorsabb kapcsolattal csatlakozik hozza, mint a rendszermemorianak szolgalo DRAM. A Crystal Well konkret eDRAM implementacioja iranyonkent 50 GB/mp, osszesen 100 GB/mp savszelesseget kinal, ami azert elegge felette van a memorianak -- bar teny, hogy az L3 cache-nel azert lassabb (Haswellnel cca. 150-190 GB/mp az L3). De nem veletlenul hivjak 4.szintu cache-nek: ahogy megyunk a szinteken felfele (szamozas tekinteteben), egyre lassabb minden cache lepcso, ez eddig is igy mukodott a cache-eknel, CPU-gyartotol fuggetlenul.
Az eDRAM kesleltetese kb. feluton van az L3 cache es a memoria kozott, ld. a grafikont itt --> [link]
"de sok-sok kis CPU mag kiszolgálására nem alkalmas"
Van ossz-vissz 4 mag, az nem sok-sok
A Skylake MIC implementacioja pedig me'g mindig nincs megerositve az Intel reszerol, csupan sejtesek vannak. Nekem is vannak sejteseim, azokat se kezeljuk tenykent
De akkor ehhez mérten az eddigi modulon belüli skálázódásnak kakinak kéne lennie, legalábbis a 90%-ból nem tudom hogy lehet 140%-ot csinálni. ![;]](http://cdn.rios.hu/dl/s/v1.gif)
Jó lenne élvezhető teljesítményt kapni a mobil verziónál is. Nekem 1600x900 lenne az aranyközépút 15.6"-on (FHD mánia ide vagy oda, jelenleg ez kellemes a szememnek még mindenféle bűvészkedés és felskálázás nélkül).
De talán, ha a DDR4 mellett képes támogatni a DDR3-at is. Esetleg lesz belőle FM2+ és FM3-as változat is.
Új hozzászólás Aktív témák
Hirdetés
A topikban az OFF és minden egyéb, nem a témához kapcsolódó hozzászólás gyártása TILOS!
Az ide nem illő hozzászólások topikja:[link]
MIELŐTT LINKELNÉL VAGY KÉRDEZNÉL, MINDIG OLVASS KICSIT VISSZA!!
A topik témája:
Az AMD éppen érkező, vagy jövőbeni új processzorainak kivesézése, lehetőleg minél inkább szakmai keretek között maradva.
- iPhone topik
- Teljes a kép a OnePlus Nord CE5-tel kapcsolatban
- Kevesebb dolgozó kell az Amazonnak, AI veszi át a rutinfeladatokat
- AMD Navi Radeon™ RX 9xxx sorozat
- Tenisz topic
- Yettel topik
- Vezetékes FEJhallgatók
- Milyen belső merevlemezt vegyek?
- Linux kezdőknek
- Milyen autót vegyek?
- További aktív témák...
- ÚJ Lenovo ThinkPad X13 Gen 5 - 13.3" WUXGA IPS - Ultra 5 135U - 16GB - 512GB - Win11 - 2,5 év gari
- ÁRGARANCIA!Épített KomPhone Ryzen 7 5700X 16/32/64GB RAM RTX 3060 12GB GAMER PC termékbeszámítással
- Telefon felvásárlás!! iPhone 11/iPhone 11 Pro/iPhone 11 Pro Max
- AKCIÓ! ASUS PRIME Z390-P i5 8600K 16GB DDR4 512GB SSD RX 6600 8GB GDDR6 DEEPCOOL Matrexx55 630W
- REFURBISHED és ÚJ - HP USB-C Dock G5 docking station (5TW10AA) - 3x4K felbontás, 120Hz képfrissítés
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PC Trade Systems Kft.
Város: Szeged