-
Fototrend
OLVASD VÉGIG ALAPOSAN MIELŐTT ÚJ HOZZÁSZÓLÁST ÍRNÁL!!!
Új hozzászólás Aktív témák
-
lee56
őstag
Én úgy tudtam ennél azért radikálisabb változások lesznek :
Ezt találta meg legelőször a google.
Memóriavezérlő helyett gondolom csatornát akartak írni, de amúgy máshol is hasonlót olvastam róla, hogy ilyen lesz.Ezzel a kettővel előre gondolattal csak odáig akartam kilyukadni, hogy majd azok IGP-je - ezt ki is emeltem
- már biztosan nem fog megelégedni egy mai átlagos DDR3 társaságával. (Magyarul visszafogja majd, és nem csak játékokra gondolok. Mert ha tényleg beindul jobban a GPGPU biznisz, s az IGP-k sokkal jobban ki lesznek használva mint manapság, akkor megnőhet a sávszélességéhségük is nem?) Tehát valami új kell majd, hogy ez GDDR5 vagy 5M vagy DDR4 az majd idővel kiderül.Ja most nézem a hozzászólásokat, ti ugyanazok a Fiery-k vagytok?
[ Szerkesztve ]
No Comment
-
Abu85
HÁZIGAZDA
Direkten azért nem nyilatkoznak az AVX-ről hátrányosan az AMD-nél, mert nekik is van AVX-es rendszerük. Ami történik, hogy John Gustafson otthagyta az Intelt és az AMD-hez ment. Pletykák szerint az Intel küldte el őt is, ahogy Michael Abrasht és Andrew Richardst. Ugye ők voltak az elsők, akik azt mondták, hogy a MIC nem fog működni. John Gustafson mélyebben dolgozott ezen a projekten, tehát többet láthatott, mint két programozó. Az AMD terveiből azután került ki az AVX további támogatása, hogy Gustafson munkába állt. Könnyen lehet, hogy elmondta nekik, hogy nem működik. De valszeg valami sejtésük úgyis volt róla, ha már két top programozó nem nyilatkozik róla kedvezően. Andrew Richards egyszer erről írt egy cikket, hogy miért nem fog működni, de az Intel mindenhonnan levetette.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#12955
Abu85
HÁZIGAZDA
TESCO-Zsömle
#12954
Abu85
HÁZIGAZDA
válasz
TESCO-Zsömle
#12954
üzenetére
Már rég felraktam volna torrentre, ha meglenne.
Igazából a lényeg egyszerű. Még Eric Demmers, illetve Bill Dally is mondogatta korábban, hogy many core skálázódáshoz parallel ISA (Dally hívja így) kell, ami arra van kihegyezve, hogy a lapkán belül soktízezer szálat kezeljen. Gyorsan kell menedzselni és szinkronizálni, és persze a kommunikációt sem szabad elfelejteni. Amikor terveznek egy ilyet, akkor mindig lesz egy skálázhatósági maximum, aminél többet az ISA már nem bír ki, tehát újat kell tervezni, ami kitolja a korlátokat.
Az Intel koncepciója az, hogy jó a soktízéves x86 is ide, majd a gyártástechnológiával raknak a magok mellé tizenakárhány MB-os gyorsítótárakat, és úgy működni fog. Ez elvben okés, viszont így más minden 5 MB-os cacheterület helyére rak 1 TFLOPS-ot, ami már nem jó.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#12956
TESCO-Zsömle
félisten
Abu85
#12955
TESCO-Zsömle
félisten
Értem, ez eléggé nagy bajnak tűnik. Mit jelenthet ez a jövőre nézve? Gondolok itt arra, hogy az Intel 2 éven belül ki fog jönni a MIC-el szerelt HPU-val, mert ugye sok pénz áll benne és amúgy sincs idő (nem beszélve a lehetőségről) új koncepcióba kezdeni. Mivel állnak majd szemben?
Addigra már lesz a piacon egy kazal Gaming Evolved játék Matle-el erősítve, zömük valszeg nextgenről portolt multiplatform. Szintén lesz egy csokor olyan GE cím is, ami már támogat csak a GCN-nel szerelt APU-kon futtatható funkciókat, legyenek ezek plusz látványt, vagy csak gyorsabb futást eredményező kódok. Az AMD a konzolokból befolyó pénz jó részét vissza fogja pumpálni, hogy minél több stúdiót ösztökéljen az új vasak és funkciók kihasználására.
Emellett nyomják be a GCN-t minden lehetséges formában a szerverpiacra is.
[ Szerkesztve ]
Sub-Dungeoneer lvl -57
-
Fiery
veterán
"Ez elvben okés, viszont így más minden 5 MB-os cacheterület helyére rak 1 TFLOPS-ot, ami már nem jó."
Ezt hogy szamoltad ki? A Crystal Well eDRAM-ja 128 MB-os, es 84 mm2 teruletet foglal. 5 MB-nyi eDRAM 3.28 mm2-nyi helyet visz el csupan. Ehhez kepest a Hawaii 430 mm2-en kepes 5.6 TFLOPS-ra, a Tahiti meg 365 mm2-en kepes cca. 4 TFLOPS-ra. Ez alapjan -- persze tudom en, hogy ez nem ilyen egyszeru -- 1 TFLOPS helyigenye legyen 40 mm2 durvan. Tudom-tudom, a Hawaii-ban tobb ROP blokk van meg TrueAudio, legyen akkor 20 mm2 1 TFLOPS-nyi CU helyigenye. Nagyon messze van ez a 3.28 mm2-tol...
Raadasul, hiaba is raksz be +1 TFLOPS-ot mondjuk egy Kaveriba (ami alapbol kozel 1 TFLOPS), nem er az egesz semmit, ha nem tudod etetni memoriaval. Ergo oda is kene eDRAM vagy L3 cache, hogy mukodhessen a nagyobb szamitasi kapacitas. Vagy GDDR5, ami meg ugye tudjuk, hogy megse lesz. De mondjuk 2 TFLOPS se lesz, me'g a Carrizoban se...
Ha csak durva viccnek szantad, smiley nelkul, akkor sorry, hogy komolyan vettem
[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
Nem én számoltam ki. Dally mondta korábban, de elvben nézzük meg mi is: ha a GCN-t számítjuk, akkor 28 nm-en 1 TFLOPS-hoz 8 CU kell (1 GHz-es órajelen, ami normává válik). Ennyit ~24 mm2-be lehet ma beépíteni, mert egy CU ~3 mm2. Ekkora területre ma 4 MB-nyi SRAM helyezhető 28 nm-en. Persze 5 MB-ról volt szó, de változók az architektúrák, tehát könnyen lehet, hogy Dally nem a GCN-t vette elő. Az alapvető mondandója viszont igaz.
Az AVX is OpenCL-lel használható ki a legjobban, ugyanúgy, mint az IGP-k. Ezért erősítette meg az OpenCL támogatását az Intel, mert több fejlesztő jelezte, hogy sokkal hosszabb kódot kell írni TBB+intrinsics mellett, ami lassabb lesz. Persze az OpenCL-lel sincsenek kibékülve a fejlesztők, de az MS dolgozik a C++AMP fejlesztésén. Az felkínálhat egy arany középutat.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Fiery
veterán
"Az AVX is OpenCL-lel használható ki a legjobban"
Probaltal mar CPU-n OpenCL kodot futtatni? Botranyosan lassu, fuggetlenul attol, hogy Intel vagy AMD processzorrol van szo. Ha valaki egy kicsit is ert az AVX-hez, az inkabb nekiall nativ kodot irni, vagy valamilyen fuggvenytarat hasznalni, mintsem hogy nekialljon OpenCL-en at vacakolni az AVX-szel... A GPU-kon az OpenCL mas teszta persze, azzal kevesbe a teljesitmeny a gond, inkabb a compilerek sz*rok.
-
-
Fiery
veterán
Rendes 4.szintu cache-nek latszodik az eDRAM a Crystal Well-ben. CPUID Leaf 4 output idevonatkozo resze (EAX-EBX-ECX-EDX):
CPUID4: 1C03C183-03C0F03F-00001FFF-00000004
Fully Associative Cache = nem
Cache Level = 4
Cache Type = Unified Cache
Ways of Associativity = 16-way
stb.[ Szerkesztve ]
-
-
Abu85
HÁZIGAZDA
Én nem, de több játékfejlesztő is mondta, hogy OpenCL-lel jobb erdmények érhetők el az AVX2 kihasználása kapcsán, mint TBB+intrinsics mellett. Szerintem ez a fő oka annak, hogy az Intel ennyire sok erőforrást öl az OpenCL-be. Ők is belátták, hogy bőven van olyan algoritmus, amit OpenCL-ben könnyebb megírni AVX2-re. Ennek egyébként kifejezetten örülnek a fejlesztők, annak már nem, hogy a tömegprocikból hiányzik az AVX2, tehát kaptak is segítséget meg nem is. Az OpenCL-en azonban nagyon rajta van az Intel, és erre a platformra épülő játékokat szeretnének látni.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Fiery
veterán
"Ők is belátták, hogy bőven van olyan algoritmus, amit OpenCL-ben könnyebb megírni AVX2-re."
Ezt nem vitatom, a fejlesztok lustasaga vegtelen
Viszont az is teny, hogy az OpenCL CPU driverek egyszeruen lassuak. Lehet, hogy me'g mindig gyorsabb ugy, mint ha mondjuk nativ SSE kodot futtatnanak, de a nativ AVX/AVX2 kodtol nagyon messze van az OpenCL CPU driverrel elerheto teljesitmeny."Ennek egyébként kifejezetten örülnek a fejlesztők, annak már nem, hogy a tömegprocikból hiányzik az AVX2, tehát kaptak is segítséget meg nem is."
Mondjuk ez konnyen athidalhato, hiszen ahol nincs AVX2, ott jo esellyel van eros dGPU vagy eros iGPU
De ennyi erovel akkor mar az AVX/AVX2 OpenCL CPU driver megoldast is lehetne az Intel iGPU-n futtatni, es mehetne kellemes tempoval."Az OpenCL-en azonban nagyon rajta van az Intel"
Van hova fejlodniuk, ez teny
![;]](//cdn.rios.hu/dl/s/v1.gif)
[ Szerkesztve ]
-
Oliverda
félisten
Számomra ez így első hallásra elég hihetetlenül hangzik. Ott van példának az OpenGL és D3D API, ami ugyebár nagyban visszafogja a GPU-k teljesítményét, CPU fronton pedig éppen fordítva lenne? Valahogy kétlem.
"Minden negyedik-ötödik magyar funkcionális analfabéta – derült ki a nemzetközi felmérésekből."
-
#12976
TESCO-Zsömle
félisten
Oliverda
#12975
-
Fiery
veterán
Onmagaban az a limitacio, hogy mostantol csatornankent csak 1 modul hasznalhato, nem igazan jelentos manapsag. A legtobben amugy sem hasznalnak csatornankent 1-nel tobb modult, raadasul az eladott PC-k tulnyomo tobbsegeben amugy is csak 2 DIMM slot van (a legtobb konfigban 2 SO-DIMM).
"ti ugyanazok a Fiery-k vagytok?"
Csak egy Fiery van
-
Abu85
HÁZIGAZDA
válasz
Oliverda
#12975
üzenetére
Itt az van, hogy TBB+intrinsics mellett is ki lehet hozni ugyanazt a teljesítményt, minden csak annak a kérdése, hogy mennyi időt ölsz az optimalizálásba. Az OpenCL azért jött elő, mert a fejlesztők a programozási modell megismerésével rájöttek, hogy ugyanazt kevesebb kódsorból és kevesebb erőforrás befektetéséből kihozzák.
A TBB+intrinsics nem rossz, ha beletanulsz és belerakod az időt, akkor jó dolgokat lehet belőle kihozni, de manapság annyira határidőzve van minden, hogy alapvető irány ha valamivel hamarabb eléred a kívánt sebességet.
Egyébként egyik sem olyan egyszerű. Ebből gondolom, hogy a C++AMP-nek lehet még keresnivalója. Vannak olyan ígéretek, hogy a köv. verzió a TBB-hez hasonló erőforrás befektetése mellett ad olyan gyors a kódot mint az OpenCL, vagy a TBB+intrinsics.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Fiery
veterán
Valoban nem ertem oket. Szerintem fogalmazd at a kerdest, vagy egyszeruen csak fogadd el a tenyt, hogy a Crystal Well eDRAM-ja sima, egyszeru, hetkoznapi L4 cache-kent viselkedik. Van L1, L2, L3 es L4 cache a prociban, ennyi. A differencia kozottuk mindossze az elhelyezkedesuk, meretuk, kialakitasuk, szervezesuk, felhasznalasi moduk (adat/kod/unified), kesleltetesuk es savszelesseguk. De mindegyikuk klasszikus ertelemben vett CPU cache. Onmagaban az, hogy nem a die-ra van integralva a cache, vagy hogy eDRAM, me'g nem jelenti azt, hogy nem cache. Emlekezzunk a Slot 1 es Slot A processzorok kulso L2 cache-ere, vagy a Pentium Pro MCM L2 cache-ere peldaul. Vagy idoben visszafele ott voltak az alaplapra pakolt L2 cache-ek.
-
#12981
Cickánykoma
tag
Cickánykoma
tag
Sziasztok!
Jelenleg egy bő 3 éves Toshiba 10" -os netbookom (NB-550D) van, C50-es procival. Nagyon jól kiszolgált az évek alatt, nagyon jó a 8-9 órás üzemideje, a kis súlya és hogy könnyű hurcolni, strapabíró. Időközben tuningoltam + RAM-mal és SSD-vel. Ahogy telt az idő azonban rájöttem, hogy a kis képernyő az, ami a mobilitás mellett zavaró nekem a kis munkafelület miatt.
Majdnem naprakészen követem a híreket és teszteket, amiket Abu és Oliverda készít, így már hónapokkal ezelőtt meggyőzött az AMD arról, hogy az Ontario procis kisgépemet egyszer egy Kabinisre akarom cserélni.
Ma keresgéltem a neten és Toshibából kiköpött hazai boltokban pár helyen 15"-os A4-5000 procis példányokat. Megnéztem a notebookcheck oldalon is, hogy jól látom-e, amit látok (ITT).
Kérdéseim a következők:1) Ez az a Kabini-e amire vártam és minden szempontból megfelel az igényeimnek? (Ontariohoz mért alacsony fogyasztás, erősebb GPU, gyorsabb feladat és memóriakezelés)
2) 96K-ért jó vétel-e lecsapni erre a Toshibára? Ha nem, tud-e valaki jobb alternatívát mutatni (nem vagyok elvakult Toshiba márkafan, csak jó tapasztalatom volt a mostani példánnyal) hasonló árkategóriában (90-110K)?
Köszönöm előre is a tanácsokat, válaszokat!
[ Szerkesztve ]
Madžari......Dober dan, passport kontrol !!! :D:D:D
-
#12982
Oliverda
félisten
Cickánykoma
#12981
Oliverda
félisten
válasz
Cickánykoma
#12981
üzenetére
Ez nem az a topik (lásd 1. hozzászólás).
Itt tedd fel a kérdést.
"Minden negyedik-ötödik magyar funkcionális analfabéta – derült ki a nemzetközi felmérésekből."
-
#12984
TESCO-Zsömle
félisten
Cickánykoma
#12983
TESCO-Zsömle
félisten
válasz
Cickánykoma
#12983
üzenetére
Jól gondoltad, viszont nem beszélgetünk notebook-okról. Itt "csak" magukról a chip-ekről esik sző és azok technikailag fontos eszközeikről.
[ Szerkesztve ]
Sub-Dungeoneer lvl -57
-
#12986
Abu85
HÁZIGAZDA
TESCO-Zsömle
#12956
Abu85
HÁZIGAZDA
válasz
TESCO-Zsömle
#12956
üzenetére
Szerintem a játékoknál az Intel a grafikát csak félig tekinti lényegesnek. Dedikált GPU-juk nem lesz, így azon vannak, hogy az IGP-n futó grafikai szint megfelelő legyen. Ez egyébként reális elképzelés, mivel a grafika nagyon jól skálázható.
A játékmenetre koncentrálnak. Abban kell innovatívnak lenni, és leginkább segíteni abban, hogy a next-gen motorok, amiket tényleg úgy írtak, hogy a konzolok extráit kihasználják, minél hamarabb áthozhatók legyenek PC-re. Itt a játékelemekre kell gondolni. A grafika az mindegy. Leskálázod a minőséget és megkapod ugyanazt a játékélményt.
A Mantle-lel nem lehet mit kezdeni. Amelyik játék támogatja az az AMD hardverein fog futni a legjobban. Ez ellen semmit sem tehetnek.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#12987
TESCO-Zsömle
félisten
Abu85
#12986
TESCO-Zsömle
félisten
-
#12988
Abu85
HÁZIGAZDA
TESCO-Zsömle
#12987
Abu85
HÁZIGAZDA
válasz
TESCO-Zsömle
#12987
üzenetére
Felesleges. Az Intelnek még nincs meg a technikája, hogy az AAA játékok területében gondolkodjon. Richard Huddy ezt rosszul közelítette meg. Annak semmi realitása nincs, hogy egy Grid 2-t vagy egy TW: Rome 2-t valaki Intel IGP-vel játsszon.
Én az Intel helyében ezt az egész stratégiát átgondolnám és elmennék a casual játékok támogatásának irányába. Ha valaki vesz egy Ultrabookot az nagyobb eséllyel fog egy Pirate101-gyel vagy egy Sonic-kal játszani. Vagy mondjuk a Torchlight 2-vel. Ebbe kellene ölni a pénzt, mert ilyen élményt kap ma egy Ultrabook és tablettulaj az Inteltől: [link]
Huddynak azon kellene gondolkodnia, hogy mit csináljon, hogy a kisebb fejlesztők figyeljenek az Intel hardverekre.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
-
dezz
nagyúr
Onnan indult a dolog, hogy Abu CPU magok mellé integrált tizenvalahány MB-os cache-ekről beszélt, ami (normális esetben) a sima SRAM területénél is többet igényel, per MB. Erre te a sokkal kisebb helyet foglaló és sokkal lassabb eDRAM-ot hoztad fel, csak mert azt ott L4 cache-nek hívják. Hát, ez nem egészen fer...
Emlékeim szerint a (L1-L3) cache memória mindig is SRAM volt, legalábbis x86 vonalon. Hiszen éppen a sokkal lassabb aktuális DRAM kiváltására szolgált.
Azért lettem volna kíváncsi az eDRAM, mint cache, implementálására, hogy kiderülhessen, akkor ez most sima DRAM vagy vagy valami más, ami nagyobb területet foglal annál és gyorsabb is. Ha sima DRAM, akkor a main ramhoz képesti nagyobb sávszélességet leginkább a tokozáson belül megvalósítható szélesebb busz biztosíthatja. Bár kétlem, hogy MCM-ben szélesebb lehetne, mint 128 bit. Igaz, a main rammal együtt ez már min. 256 bit. Vagy, ha nem lehet így összevonni őket, akkor legalább nem a main ram elérését lassítják a grafikai/computing műveletek.
Kicsit utánanézve, az eDRAM a L3 victim cache-e itt. (Az onnan kilökődő adatcsomagokat tárolja.) Így valószínűleg sima DRAM. Gyakorlati szempontból egy lokális frame-/texture buffer, ami képes gyorsítani az Iris Pro működésén, de sok-sok kis CPU mag kiszolgálására nem alkalmas.
[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
Az eDRAM eléggé speciális feladatott lát el. Az Intel a Sandy Bridge óta azt akarja, hogy az IGP és a CPU ugyanabba az utolsó cache-be írjon. Ez a Sandy-nél alapfunkció volt, de az IGP a pár MB-os cache-be 32 kB-os tartalmakat írt szálanként oda ahova akart. Ezt később kikapcsolták a driverben és eltűntek a másodperces akadások a játékokból. Az Ivy-ben az IGP már kapott egy saját méretesebb gyorsítótárat. A Haswellben az Intel az eDRAM-ot dolgozta ki a gond leküzdésére. Az LLC-t az IGP békén hagyja, és az eDRAM-ba szemetelhet 32 kB-os blokkokat. Ezzel a processzor teljesítménye sem omlik össze, ha az IGP sorra felülírja a szükséges adatokat a cache-ben, mert úgyis ott van szinte minden az LLC-ben.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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 
[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
Hivatalos bejelentés hiányában nyilván minden csak sejtés, vagy pletyka, de a Skylake IGP-jét Ofri Wechsler csapata fejleszti. Jelenleg ők felelnek azért a szoftveres futószalag kidolgozásáért, mely elvben biztosítja, hogy a MIC grafikára is jó legyen. "IA GFX Proof-of-concept" tanulmány.
Az igaz, hogy az Intel nem erősítette meg, hogy MIC lesz a Skylake-ben, de Ofri Wechsler személye gyakorlatilag eléggé konkrét adat erre vonatkozóan.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
batt
aktív tag
Sziasztok! Abu vagy esetleg valaki nem tud véletlen valami programot vagy bios mod-ot hogy lehessen tunningolni egy kabini E1 APU-t? (2100)
Ha csak egy kis esély lenne rá de boldog lennék! A "gpu"ja meglepően egész erős de a proci nagyon gyenge!
Nagyon új még elképzelhető,hogy később lesz rá valami?
[ Szerkesztve ]
Asus Rog Flow X13 @XG Mobile RTX 3070*^*Asus FX505GM
-
dezz
nagyúr
Azért, mert Abu nyilvánvalóan nem ilyen, eDRAM L4 cache-re gondolt, hanem normál SRAM cache-re, ami sokkal nagyobb helyet foglal, per MB.
"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."
Tényleg? Szerinted ezt ki nem tudja itt?
"Van ossz-vissz 4 mag, az nem sok-sok"
Pfff, az nem merült fel benned, hogy a "sok-sok kis mag" a MIC-re vonatkozik?
"A Skylake MIC implementacioja pedig me'g mindig nincs megerositve az Intel reszerol, csupan sejtesek vannak."
Hát egy biztos: a MIC mellé kevés lenne az eDRAM egyedüli cache-nek.
-
lee56
őstag
válasz
leviske
#12996
üzenetére
Valamivel közelebb, mivel itt CPU architechtúrákról van szó főleg (és azoknak általában szerves része valamennyi szintű cache), legalábbis volt amíg át nem állt a fókusz az APU-k felé (amikben azért szintén fontos rész maradt a CPU arch. is). Szóval most ha egy ilyen lapkáról (aminek több mint felét a grafikus magok teszik ki) és a jövőbeni társairól folyik a diskurzus, és totálisan ferek akarunk lenni, akkor már a GCN se lehetne off.
No Comment
-
dezz
nagyúr
válasz
leviske
#12996
üzenetére
Ha visszaolvasol, látni fogod, hogy az AMD és az Intel (utóbbinál feltételezett későbbi) alapvető APU architektúrális koncepcióiról és ezek egy fontos eltéréséről esett szó, aminek a szempontjából fontos kérdés, hogy milyen cache lesz a magok mellett. Ehhez képest az IGP belső felépítése egy szinttel mélyebbi dolog (kis túlzással részletkérdés). Bár nem gondoltam, hogy több hozzászólásváltást generál az a megjegyzésem, hogy a helyfoglalás szempontjából normál, esetünkben L2/L3 cache az összehasonlítási alap, nem az eDRAM.
Egyébként szerintem a Carrizónál, vagy max. utána az AMD is kénytelen lesz bevetni valamilyen nagyobb kiegészítő memóriát.
-
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 [ Szerkesztve ]
Memóriavezérlő helyett gondolom csatornát akartak írni, de amúgy máshol is hasonlót olvastam róla, hogy ilyen lesz.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Szívesen elolvasnám. 
Nem, nem kell szájbarágósan.
Új hozzászólás Aktív témák
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.
- AMD Ryzen 7 5700X3D 3.0GHz (96MB Cache, up to 4.1GHz) OEM AM4 Processzor!
- Intel I7 13700K 16mag/24szál - Új, Tesztelt - Eladó! 108.000.-
- AMD Ryzen 5 1600 6-Core 3.2GHz (up to 3.6GHz) AM4 OEM Processzor
- AMD Ryzen 5 5600X Tray - Új, 3 év garancia - Eladó! 45.000.-
- AMD-RYZEN-9-5950x , ASUS TUF Gaming B550M-Plus , 32GB 3600MHz DDR4 RAM G.Skill Ripjaws Félgép!
Állásajánlatok
Cég: HC Pointer Kft.
Város: Pécs
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest