- Köredzésen járt az Exynos 1680
- Sony Xperia 1 VII - Látod-e, esteledik
- Google Pixel topik
- Milyen okostelefont vegyek?
- Xiaomi 14T - nem baj, hogy nem Pro
- Redmi Watch 5 - formás, de egyszerű
- Samsung Galaxy Z Fold7 - ezt vártuk, de…
- Samsung Galaxy Watch8 - Classic - Ultra 2025
- Redmi Note 13 Pro 5G - nem százas, kétszázas!
- Yettel topik
Hirdetés
Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
Nem is mostanában lesz, hogy bekerül. Eredetileg a Haswell lett volna a kiválasztott, de a Larrabee elhasalása miatt ez kockázatos. Most a Skylake lehet opciós, de ajánlott már a 2014-es váltásnál elgondolkodni, mert 2015 az komoly csúszás. Az AMD 2013-ra integrálja a GCN-t, míg az NV 2014-ben áll elő a Maxwellel, ami a Kepler utódjához fűzi a Denver procimagokat. Mindkettő előnye, hogy olyan integrációt jelent, melyben a CPU és a GPU közös címteret és teljesen koherens memóriát oszt meg. Az Intelnek ide a Larrabee integrálása a belépő.
-
Abu85
HÁZIGAZDA
A belső cache-szervezésről van szó. Ne keverjük ide a külső memóriát. Az olyan amilyen. Rakhatsz a Larrabee mellé is ultragyorsat. Sőt a Knights Corner mellé biztos ilyen kerül.
A mobil termékek jó része erre fel is is készült, hiszen a Tegra az egyetlen SoC, ami IMR IGP-t használ.
-
Abu85
HÁZIGAZDA
A Knights Ferry-t kukázták a Larrabee névvel együtt, de a koncepció továbbra is él. Az új név a MIC. Erre az első termék a Knights Corner lesz, ami terv szinten is a Ferry leváltója.
Az SCC az egy másik projekt. Ott nem egy darab sokmagos chipról van szó, hanem 24 darab kétmagos processzorról egy lapkában. [link] - ez is a Tera-Scale projekt része, ahogy a MIC is, de nem egyeznek meg.Az LLC-re az Intel MESIF protokollt használ. Mindegyik procimag olvassa a teljes tárat, de csak a saját szeletbe írnak. Az IGP-re ez nem vonatkozik. Ez a mag oda ír ahova akar. Majd ha a Larrabee beköltözik, akkor ez a Larrabee magokra is vonatkozik. Olvasnak mindent, de csak saját szeletbe írnak. Itt rendszer túlterhelését a rengeteg kommunikáció jelentheti. Ezért kell az LLC-t kímélni.
-
Abu85
HÁZIGAZDA
Azt senki sem mondta, hogy nem működik 4-8-12 procimagnál. Az a kérdés, hogy a Larrabee beköltözésével működni fog-e. Mert az 20-30+ magot jelent. Azt természetesen tudjuk, hogy a Larrabee-t eleve Binned Renderre csinálták, azaz egy TBR rendszer, hogy kímélje a saját LLC-jét. [link] - erről korábban írtunk. Ugyanez az elv szükséges az integrálásnál is. Az LLC-t minden eszközzel kímélni kell, mert ha ez megfekszik, akkor a teljes rendszer teljesítményének annyi. Ami most van az csak egy átmenet. Az LLC-t nem arra tervezték, hogy egy mostani IGP-t kiszolgáljon. Később a Larrabee magokat fogják erre ráfűzni, és megtartanak pár nagyobb magot. Ugyanígy erre kerül majd az System Agent, és pár fix funkciós egységeket tartalmazó tömb.
-
Abu85
HÁZIGAZDA
Ez a probléma. Az Inteltől kérdeztem, hogy miért viselkedik így, vagy miért hagyják, hogy ilyen legyen ebben a tesztben a rendszerük. Mondták, hogy reagálnak rá, és a jelzett két alkalmazásnál megtiltják, hogy az IGP írjon az LLC-be. Az tudom, hogy annak az FF benchmarknak megtiltották, mert később folyamatos lett a futása (persze az átlag fps esett, de legalább nem ingadozik, és nem áll le másodpercekre). Ezt driverből régóta vezérlik. Egy csomó játéknak tiltva van már az írás lehetősége, az AMD azért rakott benchmarkot a tesztbe, mert ott arra nincs tiltva, vagyis szépen ki lehet fektetni az LLC-t, amire az Intel rendszerének nagy szüksége van. Ha kiveszed a buliból, akkor a teljesítmény drasztikusan esik. Egyszerűen túl sok, ha proginként 3 MB-ot teleír az IGP mindenféle felügyelet nélkül. Az Ivy Bridge ezen segít, ugyanis az IGP kap egy saját L3-at (úgy tudom nem nagyot 256-512 kB körülit, egy GPU-nak ez elég). Ettől még írhat az LLC-be (a Stream out oda megy mindenképpen, de ez kicsi adat), de ha tiltani kell a fenti okok miatt, akkor nem marad nagyobb méretű cache nélkül.
-
Abu85
HÁZIGAZDA
[link] - Ezért nem akar az AMD közös cache-t a CPU-magoknak és a GPU-nak. A videó végén teljesen lehal a Sandy Bridge, mert elindítottak rajta két olyan programot, ami terheli a GPU-t. A GPU pedig az LLC-t teleírja (programonként 3-3 MB-ot), így a procinak mennie kell a memóriába az adatért.
Ez koncepcióból van így, mert kérdéses, hogy mennyire jó, ha a GPU a proci által használt nagyméretű LLC-be piszkít. Jelen esetben szálanként 32 kB-ot. Ezt minden felügyelet nélkül teszi. Az AMD szerint ez nem jó, így inkább másik oldalról közelítenek, vagyis nem egy LLC-re építik a rendszert, hanem a magokat látják el jó nagy gyorsítótárral.
Később majd az is kérdés lesz, hogy az LLC ring kapcsolat mellett mit szól majd, ha nem 5 magot lát el, hanem 50-et. A Larrabee 32-vel nem működött jól, ez egy komoly meló lesz.
kicsit járj utána a részleteknek 
Új hozzászólás Aktív témák
- Azonnali készpénzes Sony Playstation 5 lemezes és digitális felvásárlás személyesen/csomagküldéssel
- Intel X540-T2 dual-port 10GbE RJ45 hálózati vezérlő (10Gbit, 2 port, áfás számla, garancia)
- Lenovo IdeaPad Gaming 3 - 15.6" FHD IPS 165Hz - Ryzen 5-5600H - 16GB - 512GB - RTX 3050 Ti - Win11 P
- Apple iPhone 7 128GB Yettel Függő 1Év Garanciával
- LG 32SQ700S-W - 32" VA Smart - 3840x2160 4K UHD - 62Hz 5ms - WebOS - Wifi + BT - USB-C - Hangszórók
Állásajánlatok
Cég: FOTC
Város: Budapest