-
GAMEPOD.hu
OLVASD VÉGIG ALAPOSAN MIELŐTT ÚJ HOZZÁSZÓLÁST ÍRNÁL!!!
Új hozzászólás Aktív témák
-
-
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.
-
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 ]
-
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 ]
-
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.[ Szerkesztve ]
-
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
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?[ Szerkesztve ]
-
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.
[ Szerkesztve ]
-
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.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
-
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...
[ Szerkesztve ]
-
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.[ Szerkesztve ]
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ Szerkesztve ]
-
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.
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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. -
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. -
-
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!
[ Szerkesztve ]
Bogyorisz
-
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.
[ Szerkesztve ]
-
leviske
veterán
-
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.[ Szerkesztve ]
-
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
"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...
-
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
"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
[ Szerkesztve ]
-
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?
[ Szerkesztve ]
-
-
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
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
![;]](//cdn.rios.hu/dl/s/v1.gif)
DP-ben a Richland (es mellesleg a Kaveri is) gyorsabb AVX-szel mint az iGPU-val. Kimértük, nem kitaláció.[ Szerkesztve ]
-
-
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.
-
#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.
[ Szerkesztve ]
Star Citizen FAQ http://starcitizen.hu/star-citizen-faq-az-ujaknak/ (Mielőtt kérdeznél)
-
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.
-
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. -
Oliverda
félisten
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.
"Minden negyedik-ötödik magyar funkcionális analfabéta – derült ki a nemzetközi felmérésekből."
-
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.
[ Szerkesztve ]
No Comment
-
leviske
veterán
128 MegaByte egyebkent. De ezt eddig is tudni lehetett.
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.
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).
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.
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.![;]](http://cdn.rios.hu/dl/s/v1.gif)
DP-ben a Richland (es mellesleg a Kaveri is) gyorsabb AVX-szel mint az iGPU-val. Kimértük, nem kitaláció.
Ú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.
- f(x)=exp(x): A laposföld elmebaj: Vissza a jövőbe!
- Kerékpárosok, bringások ide!
- Dell notebook topic
- Kodi és kiegészítői magyar nyelvű online tartalmakhoz (Linux, Windows)
- Samsung Galaxy A54 - türelemjáték
- Nézzük együtt a ma esti Ubisoft Forwardot!
- Milyen CPU léghűtést vegyek?
- KuKirin G4 - a sebesség ára
- Milyen TV-t vegyek?
- Autós topik látogatók beszélgetős, offolós topikja
- További aktív témák...
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen