- HTPC (házimozi PC) topik
- Házimozi haladó szinten
- Vezetékes FÜLhallgatók
- Nem indul és mi a baja a gépemnek topik
- Milyen monitort vegyek?
- OLED TV topic
- Milyen videókártyát?
- AMD Radeon™ RX 470 / 480 és RX 570 / 580 / 590
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- AMD Navi Radeon™ RX 7xxx sorozat
Hirdetés
-
A személyre szabott reklám lehet a streaming következő slágere
it A jobb célzott hirdetések érdekében adatplatformot indít a Warner Bros Discovery.
-
SMITE 2 - Napokon belül indul a zárt alfa teszt
gp Több mint egy tucat karaktert próbálhatnak ki a szerencsésebbek, a teljes listát a május első napján esedékes streamben árulják el.
-
A Video AI lehet a One UI 6.1.1 ütőkártyája
ma Vagy hogy fogja a mesterséges intelligencia manipulálni a mozgóképeket?
Új hozzászólás Aktív témák
-
ddekany
veterán
"Szerintem a régi játékokhoz a Windows 8-on belül lesz egy Xbox 360 emulátor."
Az Xbox 360 emulátor azért igencsak húzós projektnek hangzik. PPC emuláció még tán nem ügy, na de a Xenos emuláció... az GPU emuláció lenne, amit a megfelelő sebességhez GPU-n kellene futtatni. Meg lehet ezt egyáltalán csinálni PC-n, ahol mindenféle GPU-k vannak? Vagy egy modern PC-s ATI ennyire közel áll a Xenos-hoz?
[ Szerkesztve ]
-
ddekany
veterán
"Mert gyors, és jó a tranyóbudget szempontjából is [...] egy konzolba én is a PPC-t választanám"
Ha konzolba azt, akkor a kompatibilitási gondtól eltekintve (hogy nem x86) PC-be is jobb lenne? Csak furcsállom, hogy az x86 ennyi fejlesztéssel mögötte nem tudja megverni technikailag, holott nekem elég hasonló kategóriának tűnik egy mini-ITX PC és egy konzol (egyik sem mobiltelefon vagy szekrény).
-
ddekany
veterán
Én x86 CPU VS PPC CPU-ról beszéltem (nem Larrabee szerűségekről). Ha te is, akkor nem világos hogyan kommunikálnak a CPU magok PPC esetén, ha nincs hardver szinten garantálva a koherencia. Legalábbis valamiféle "szinkronizáld a cacheket" utasítás kellene, aminek viszont az egész memóriára kell vonatkoznia (akkor meg ugye, kb ugyanott tartunk). Enélkül nem tudom, hogyan futnának rajta a szemafor vagy monitor alapú többszálas programok, márpedig kb az egész ma rendelkezésre álló kódbázis ilyen.
[ Szerkesztve ]
-
P.H.
senior tag
"Az AMD például pontosan azért fejlesztett egymástól kvázi különálló integer és FPU magokat a Bulldozer modulba, hogy az FPU rész később gond nélkül becserélhető legyen a Radeonos CU-ra."
Ennek nagyon elméletileg adott a lehetősége, de az AMD már a K7 óta kvázi különálló integer- és FPU-egységeket fejleszt minden processzorába (a Bobcat-ba is), az FPU-részben physical register file-lal. Viszont a memóriaműveleteket azóta is és a Bulldozerben is az integer egységek kezelik.
Nem nagyon elméletileg arra van lehetőség inkább, hogy a CU-rész saját logikai memória-alrendszert kap. De akkor meg már olyasmi rajzolatnál járunk, mint a mostani APU-i.Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
ddekany
veterán
Tehát ha jól értem, szerinted ez, hogy könnyebb a cacheelés, az ISA-k közti különbségből adódik, nem csak a ezen ISA-k mostani megvalósítására áll (nekem ez furcsa, de hát biztos...). Vajon hol áll ilyen téren az ARM? Mert hogy a Win8 azt fogja támogatni, PPC-t (tudtommal) nem... ami megcsillant egy halvány reményt, hogy talán egyszer az x86-ot kiüti valami. Tehát ha nagyon sok magos heterogén éráról beszélünk, ott az ARM-nek megvan ugyan az az előnye mint a PPC-nek? Ja, meg ott van az AMD, aki ugyancsak x86-függő, mégis nyomja a fúziót témát... gondolom ők az x86-ot akarják összevegyíteni az (GP)GPU-val.
[ Szerkesztve ]
-
P.H.
senior tag
Igen, minden ISA-nak megvan a modellje, az x86-é az, hogy minden memóriahozzáférésnél a hardver gondoskodik arról, hogy minden, időben korábban törtánt tárolási művelet látható az adott olvasási részénél. A GPU-nak meg az, hogy neki az esetek többségében mindegy, mit írt/olvasott egy-egy részegysége, a programozó szinkronizálja, hogy mikor kell egymás adatait látni. Erre találták ki a koherencia-protokolokat (pl. MESI, MOESI), ami azt segít eldönteni, hogy az adott értéket hol és mikor kell keresni.
x86 esetében a komponensek folyamatosan küldözgetik egymásnak, ha kell, hogy mely adatokat módosították. A protokolok már eleve kiszűrik azokat az eseteket, amikor nem kell (pl. semelyik másik mag a közelébe se ment az adott munkaterületnek; szó szerint a közelébe, mert manapság legalább 64 byte-okról van szó).
Ezt a forgalmat még így is többféleképpen lehet csökkenteni, néhány példa:A Sandy Bridge-ben mindennek az alfája és omegája az L3, ez tud mindenről, ami a magok cache-eiben történik + az IGP is ebbe önti bele az összes dolgát, azaz gyakorlatilag nincs ilyen jellegű forgalom egy lapkán belül.
Az eddigi AMD CPU-kban ha nincs az adott mag L1D-ében és az L2D-ében találat, akkor minden címet el kell küldeni:
- a többi mag L1D-jének és L2-jének, mivel ezek tartalma kölcsönösen kizárt; azok válaszolnak, hogy van-e találat, vagy nincs: vagy egy üzenettel, vagy legfeljebb 1 db 64 byte-os adattal, ami frissebb, mint ami a memóriában van
- a többi mag L1I-jének, mert az önmódosító kódot még mindig kezelik, igaz onnan nem jön válasz, az csak törli magát találat esetén
- az L3-nak, ha vanA Bulldozerben minden címet el kell juttatni L1D- és L2-miss esetén:
- az L3-hoz
- a többi L2-höz
- a többi L1I-hez, ha annak tartalma mégsem lesz inkluzív (nem derült ki eddig)
- a többi L1D-hez nem, mert azt tartalmazza az L2 is; esetlegesen a Write Coalescing Cache-hez kell eljuttani, amennyiben az AMD az igen hülye programozók rossz programjait akarja javítgatni hardveresen, pl. azt, hogy az a szinkronizációs változókat nem atomi (LOCK) műveletként kezeli.Számolgatva ez azt jelenti, hogy míg 4 szálat futtató négymagos K8-K12 lapkán 12/13 helyen kell a címet lekezelni, addig 4 szálat futtató kétmodulos Bulldozerben legjobb esetben 3, legrosszabb esetben 7 helyen kell tranzisztort áldozni a snoop interface-re. Nem mindegy.
Az APU-k esetében a fenn leírtak érvényesek, viszont az IGP által generált memóriaforgalom külön (Garlic) buszon megy a memória felé, ebből semmit se látnak a CPU-magok, mindenki foglalkozik a saját dolgával. Az IGP-nek dedikált memóriaterületet a CPU-k alapból uncached megjelöléssel látják, az oda írást vagy onnan olvasást nem is küldik körbe, se az IGP annak olvasását/írását. A CPU-memóriához való hozzáférések üzenetei mennek mindenkihez, tegye azt a CPU vagy a GPU (Onion busz), ez meg ugye nem lassít semmit az eddigi megoldáshoz képest, mert ugyanaz.
Az egyik következő lépés az lehet (mivel sokáig nem lehet még kiirtani a dedikált IGP-memóriát a meglevő programok/játékok helyessége miatt), hogy az IGP a saját cache-ével bekapcsolódik a CPU MOESI címforgalmába egy snoop interface-szel, mivel a Bulldozer-magokkal úgyis ezek száma felére vagy harmadára csökkent.A Cell-t meg leírja valaki, ha lesz rá ideje. Legalább olyan hatékony, mint az APU-ké.
Azt az Intel tudja, hogy miért teljesen koherensre csinálta meg a Larrabee-t elsőre; sok értelme nincs, hisz a többszálúságnak pont az lenne az értelme, hogy minden szál csinálja a saját dolgát, nem foglalkozik a másikéval egy-egy szinkronizációs pontig. A Sandy Bridge meg a ló túlsó oldala, annak hátulütőit meg ismerjük.
Szvsz a felsoroltak közül a K12, illetve méginkább a Trinity a legkiegyensúlyozottabb, és megvalósítva már a Llano is baromi jó megoldás.(Az a megfogalmazás, hogy "Egyszerűen a Larrabee megosztott gyorsítótárát az Intel nem tudta bankokra osztani, így egymás eredményeit írták felül a szálak." elég pontatlan; az ilyen hardveres és/vagy szoftveres megoldásokat nem számítástechnikai terméknek hívnák, hanem olyan hűtött, szennyezett tisztaszilícium-darabnak, ami passzióból még áramot is fogyaszt.
A bankolási dologgal kapcsolatban tudnál valami további információt/linket adni?)
[ Szerkesztve ]
Arguing on the Internet is like running in the Special Olympics. Even if you win, you are still ... ˙˙˙ Real Eyes Realize Real Lies ˙˙˙
-
ddekany
veterán
Azért ennek továbbra is zavaros számomra a PPC VS x86 kérdéssel a kapcsolata. Mert, a GCN-szerű komponensen belül nincsenek PPC magok, csak azon kívül hagyományos CPU céljából. Hagyományos CPU magból meg gondolom asztali gépben elég lesz a jövőben is néhány (vagy ez is olyan lesz, mint hogy 640K elég mindenre...), mert az igazán jól párhuzamosítható feladatok átkerülnek a GCN-szerűségbe. Néhány magnál meg ha jól értem a cache koherenciás gond nem jelentős hátránya az x86-nak. A hagyományos magok és GCN-szerűség kommunikációjánál van a gond? (Mondjuk ott meg még nincs mivel visszafelé kompatibilisnek lenni, szóval tán nagyobb mozgástere van a mérnököknek...)
Új hozzászólás Aktív témák
- Creative Hybrid Pro Classic (Egyszer kipróbált, garanciális)
- iPhone 15 Pro 128gb Natúr Titanium, bontatlan, független
- ÚJ Apple Watch Ultra 2 GPS + Cellular 49mm - titántok, alpesi szíj
- 8/16GB memoriák
- APPLE MacBook Air 2020 13" Retina - M1 / 8GB / 256 GB SSD / MAGYAR / 96% akku, 81 ciklus / Garancia