- Google Pixel 7a - venni vagy nem venni?
- Bemutatkozott a Poco X7 és X7 Pro
- Poco X6 Pro - ötös alá
- Samsung Galaxy A54 - türelemjáték
- Mobil flották
- OnePlus 8 Pro - a túlgondolt
- Google Pixel 8 Pro - mestersége(s) az intelligencia
- Nothing Phone (3a) és (3a) Pro - az ügyes meg sasszemű
- A OnePlus Nord 5 sem sokkal marad le akkuméretben
- Samsung Galaxy S23 Ultra - non plus ultra
-
Mobilarena
OLVASD VÉGIG ALAPOSAN MIELŐTT ÚJ HOZZÁSZÓLÁST ÍRNÁL!!!
Új hozzászólás Aktív témák
-
Nem teljesen ide tartozik, de a grafént nem tervezi valamelyik gyártó alkalmazni a gártásban?
2-3 év múlva fényképezőgép szenzorokat terveznek grafénnel, így gondolom a félvezető gyártásban is elkezdődtek a kutatások. Erről van valami infó?Ez sokat változtathat a CPU-k / APU-k / GPU-k fejlődési irányán.
-
stratova
veterán
Ez elég misztikus.
Más:
Nem tudom AMD bármely partnere tervez-e Kaverivel is Gamer notebookot piacra dobni, de látsz esetleg rációt abban, hogy ilyen célra 45 W-os kategóriában is készüljön mobil APU?
Vegyük pl. az Intel állatorvosi lovát az i5-4200H-t ahol látszólag sem az IGP, sem a magszám, de még az órajel sem feltétlenül indokolja a 47 W-os keretet (szimplán egy rosszabbul sikerült darabra tippelek).Ellenben MSI a CX60 két verzióját is piacra dobta, ahol a HD 7970M majd HD 8970M "etetésének hálátlan feladata" A10-4600M ill. A10-5750M APU-kra hárult. A két modell közötti gyorsulás kb. kizárólag a nagyobb teljesítményű APU-nak volt köszönhető, de még így is CPU limites volt a gép (jellemzően. CX60 CX70 tulajok éltek előszeretettel MSR mókolással).
Trinity/Richland esetében a A10-6700T (45 W) asztali verzió előnye A10-5750M-hez képest a GPU órajelemelésében merült ki.
Viszont ha forgalomban még nem is került Kaveri A8-7600 45 W-os kivitele érdemi előrelépés lehetne.A10-5750M
CPU 2/4 2.5/2.8/3.5 GHz + GPU 6 CU 533/720 MHz 35 WA10-6700T
CPU: 2/4 2.5/2.8/3.5 GHz + GPU 6 CU 720 MHz 45 WFX-7600P
CPU 2/4 2.6/?/3.6 GHz + GPU 8 CU 600/720 MHz 35 WA8-7600
CPU 2/4 3.1/3.3 GHz + GPU 6 CU 720 MHz 45 Wvő.
3350 HE*
CPU 2/4 2.8/3.1/3.8 GHz 45 W -
#14335
Mahrenburg
őstag
Abu85
#14332
-
stratova
veterán
Igen, erről már diskuráltunk, hogy emiatt kellett AMD-nek a Freedom Fabric. Az tiszta sor, hogy elméletileg ezzel is magas összteljesítmény érhető el, de ha csak ez marad az végleges visszavonulást jelentene az abszolút high-endtől (Intel S4S S8S, Power 8).
OK tfh.:
Seamicro SM15000-OP
4365 EE (4/8 2.3/2.8/3.2 GHz) 40 W-> [2x]RX-427BB-nek megfelelő Opteron (2/4 2.7/3.6 GHz) 30-35 W
Amivel TDP-n belül kiváltható az két FX-7500-nak [(2/4 2.1/3.3 GHz) 19 W] megfelelő Opteron (2 db BGA-s CPU/APU egy bővítőkártyán). Mondjuk az jó kérdés mekkora kárát látnák cache igényes folyamatok.
Szóval a logikát fogjuk rá, hogy értem, de itt még Warsaw alatt szerepel Toronto:
-
lee56
őstag
Ez oké, csak nem ezt kérdeztem. És nem is magyarázat arra, amit még mindíg nem értek :
"Nincs igazán lényeges teljesítménykülönbség a 30 és 90 watt közötti tartományban."
- Ez a kijelentés ami kissé érdekes, és önellentmondásosnak is tűnik. Ezek szerint, akkor csak hővé alakulna a 30-90 watt közötti sebességváltás igen nagy része, nem tűnik valami energiahatékonynak!? Persze ha teszem azt 50W-on is képes lenne az elző gen. 90W-os tempóját hozni, akkor nem szóltam, de attól még fura.
-
stratova
veterán
A HP számára készített Kabini.
Jut eszembe, HP 355-ben HP A4-6400 és A4-6300-as APU-król regél, melyek specifikációi leginkább az A6-6310 és A4-6210 modellekre hasonlítanak. Ezzel szemben a hazai oldalon A6-6310 szerepel. Miben nyilvánulhat meg az eltérés?
-
dezz
nagyúr
Nagyon jól hangzik ez a HDL-es dolog. Ha jól értem, ez azt csinálja, hogy kevesebb tranyóból hozza össze ugyanazt a funkcionalitást.
Viszont itt a wattos és MHz-es dolognál véletlenül nem egy a Pumára vonatkozó órajel/fogy. grafikonból indulsz ki? Az azért nem feltétlen jó ötlet, mert a Puma eleve jóval alacsonyabb órajelre van tervezve, 2 GHz-en még igen alacsony a fogyasztása, de onnantól csak az utóbbi drasztikus növekedésével gyorsítható akár 100 MHz-cel is.
(A Puma+-nál vélhetően jelentős módosítások történtek a futószalagoknál, hogy alkalmasak legyenek a magasabb órajelekre.)
A Kaveri viszont nem fogyaszt sokkal többet 4-4.5 GHz-cen, mint 3.7-en - csak éppen nem fértek be vele a 95W-ba.
-
Fiery
veterán
"de lehet, hogy azt mondják a fejlesztők, hogy ők kérnek 1 GHz-es IGP-t, és annak hatása lesz a processzorteljesítményre."
Erre kivancsi lennék en magam is. Mondjuk az orajelekkel dobalozni a mai vilagban nem a legjobb otlet, de ha mondjuk azt mondjuk, hogy 1,2-1,4 TFLOPS + Dual Channel DDR4-3200, nemileg alacsonyabb CPU-orajel, es mindez kijon 65 wattbol, az egy rendkivul erdekes termek lenne. Kerdes, hogy az AMD be meri-e vallalni, hogy a CPU-reszt ennyire bealdozza az iGPU miatt.
-
Fiery
veterán
"Az a legerősebb 15 wattos Kabini, amivel teszteltek."
Es akkor ez [A4-5100] micsoda? Februarban jelent meg, ergo az Anand cikk keszulesekor mar piacon volt.
"Carizzo esetében már nem is lesz 95 wattos, mert egy +100 MHz-et jelentene a turbóra és kész."
Es akkor 65 watton tudja majd hozni a 95 wattos Kaveri teljesitmenyet, de nem tobbet?
-
Fiery
veterán
Koszi. Ez alapjan a Mullins GPU teljesitmenye valoban hasonlo, mint a 15 wattos Kabinie, nem rossz. Persze jobb lett volna, ha a legerosebb 15 wattos Kabinit rakjak be a tesztbe
Ezek alapjan akkor 65 watton siman hozhatja a Carrizo a 95 wattos Kaveri teljesitmenyet, 95 watton pedig masfelszeresre gyorsulhat?
-
Fiery
veterán
"Abból lehet kiindulni, hogy a Mullins most 5 wattból nagyjából hozza a 15 wattos Kabini teljesítményét."
Ezt Te magad benchmarkoltad le?
Mert en me'g nem lattam olyan fuggetlen (nem AMD altal futtatott) benchmarkot, ami ezt kimutatta volna. Van Mullins konfiguracionk (meg persze Kabini is nehany), es azon nem latszik ilyen merteku elorelepes... Nyilvan Turboval magasabb orajeleket tud elerni a Mullins, mint a Temash, de ugye kerdes, hogy a gyakorlatban ez mennyit is jelent majd valojaban. 20 vagy 30%-os novekedes a turbos orajelben nem osszekeverendo az alaporajel ilyen aranyu novekedesevel. A Mullinsnal pedig -- nem veletlenul -- nem nagyon reklamozza az AMD azt, hogy az alaporajel mennyivel novekedett a Temash-hoz kepest."Csak a "thin" library-t cserélték ki alatta, csíkszél azonos"
Csak az a valtozas? Semmi mas? Biztos? Mi mast is eszrevettunk, ami nem epp elorelepes.
-
Fiery
veterán
Rendben, akkor kerlek becsuld meg, hogy mennyit lehetne facsarni a Carrizoban a Kaveri iGPU teljesitmenyen, amennyiben a thin libraryt optimalizalja az AMD. Ehhez feltetelezzuk, hogy az APU TDP-je, az orajelek es a shader szam nem valtoznak, es a GCN architektura sem valtozik erdemben. Ez utobbi persze addig me'g lehet, hogy megis valtozik, sot, valoszinu, de nem latok ebben 10-15%-nal nagyobb elorelepesi potencialt.
-
stratova
veterán
Úgy értem ha akar valaha is nagy teljesítményben gondolkodni, akkor számba veszi az FDSOI-t is.
Egyébként tényleg érdekesen alakulhat a skálázódás, ha:
A10-7850 95 W - 3.7/4.0 GHz, 512 SP 720 MHz GCN
A10-6800K 95 W - 4.0/4.4 GHz, 384 SP 820 MHz VLIW4
vs.
FX-7600P 35 W - 2.7/3.6 GHz, 512 SP 600/666 MHz GCN
A10-5757M 35 W - 2.5/3.5 GHz, 384 SP 600/720 MHz VLIW4
Vagy a mobil verzióknál komoly válogatás folyik. -
Fiery
veterán
"A maguk területén igazi zsenik."
Igazi zsenik lehetnek, de a legokosabb kifejezes akkor is eros. Okos, zseni, hatalmas tehetseg, ezek rendben vannak. A "leg" jelzot kellene ovatosabban hasznalnod, mert ahhoz minimum egy rangsor kellene, mint az olimpiakon a sportagakban. Arany, ezust, bronz medal, mernokoknek, akkor mondhatnad, hogy XY a legokosabb mernok vagy a legokosabb szoftver fejleszto.
"de az Intel azt kéri, hogy egy serial ISA-ra építsenek ilyet."
Majd megoldjak, legyen ez az o problemajuk. Ha megoldjak, akkor mit fogsz mondani? Hogy bocs, de megsem John Gustafson a legokosabb mernok?
![;]](//cdn.rios.hu/dl/s/v1.gif)
Ha meg nem tudjak megoldani, ha zsakutca lesz vegkepp a MIC, akkor majd elovesznek egy B-tervet. Az Intel behuzta mar magat tobbszor is zsakutcaba (NetBurst, Itanic, Tejas), es mindig meg tudott ujulni, mindig volt ujabb otletuk. Mint ahogy az AMD-nek is, mellesleg, ok is ugyesen tudnak valtani. Majd lesz valami mas, ha a MIC nem valik be.De egyebkent megertem, ha sokan ketelkednek a MIC-ben. Teny, hogy a jelenlegi formajaban tenyleg nehez elkepzelni, hogy utokepes lehet. De a KNL-rol nem sok konkretumot tudunk, a Skylake-rol meg me'g annyit sem. Siman lehet, hogy lesz bennuk valami olyan szoftveres vagy hardveres trukk, amivel athidalhatoak a jelenleg lathato problemak. Pl. egy HSA-szeru absztrakcio az x86 felett, sokszoros HyperThreading, ujfajta utemezo es dekoder, stb.
-
Fiery
veterán
A JPEG-et en arra irtam, hogy ha a WinZIP jelentektelen, akkor ennyi erovel a JPEG dekoder is az. Kinek mi a jelentektelen es kinek mi a relevans. En nem nezek tul sok JPEG-et (es nem erdekel a fogyasztas sem, nincs mobil PC-m), es nem hasznalok WinZIP-et, sz'al nekem mindketto jelentektelen. De a nagykozonseg szamara barmelyik lehet erdekes vagy lenyeges. Csupan annyi a problema, hogy me'g ha a "kicsiket" is szamba vesszuk, akkor is rohadt keves az OpenCL es HSA applikacio _jelenleg_.
-
Fiery
veterán
"beszervezte a világ legokosabb mérnökeit"
Ezt mar mashol is elsutotted, es ott sem tudtal bizonyitekkal szolgalni arra, hogy valoban ok a legokosabbak. Nem ketlem, hogy az Intel a legjobb mernokoket probalja magahoz csalogatni, de azert ne jelentsuk mar ki az Inteltol kibukott/kirugott/kilepett mernokokrol automatikusan azt, hogy ok a legokosabbak, csak azert mert fikazzak a MIC-et, amin dolgoztak.
"Azóta a MIC fejlesztése átkerült Izraelbe."
Helyes, ott fejlesztettek ki a Conroe-t is, ami ha nem tevedek, az Intel jelenlegi sikerenek egyik kulcsa. Vagy valami problema van azzal az orszaggal? Ott nem a legokosabb mernokok dolgoznak, hanem masodvonalbeli bean counterek?
-
Ja, én is inkább az egész gyártástechnológiára gondoltam, mint a nanométerre. Erről lehetne egy részletesebb tudástárcikk, esetleg akár vélemény cikk a nagyobb terjedelem miatt, mert sokaknak (nekem is) elég homályos, s szerintem nem csak én vagyok rá kíváncsi, hogy most mi van. Jelenleg csak azt tudom, hogy egyes gyártók nanométereit nem lehet összehasonlítani, nemcsak azért, mert azok gyakorlatilag "nem is annyik amennyik", hanem mert az általad is említett "thin library" is rengeteget közrejátszik. Gondolom ez utóbbi a cpu-kban használt egységek építőköveinek halmaza.
-
P.H.
senior tag
Még ha el is fogadjuk, hogy a nanométer már nem megoldás minden problémára, azért azt semmiképp sem hagyható figyelmen kívül, hogy a nanométer-csökkentés gazdaságosabbá teszi a gyártást. De csakis a gyártást - azaz az 1 mm2 waferre eső költséget -, ami csak egy bizonyos része az egész "chip-készítési" folyamatnak, de az utóbbi években egyre markánsabban látható, hogy ez a "chip-készítési folyamat" egyre jobban szegmentálódik, úgy mint:
- ARM vagy MIPS mint ISA-tervező (a.k.a architektúra)
- Qualcomm, MediaTek, Apple, stb. mint "egyedi" elvárások készítője (a.k.a microarch)
- TSMC, GlobalFoundries mint gyártó cégek (a.k.a design implementation)Emlékeztetve erre: "An understanding of the terms architecture, microarchitecture, and design implementation is important when discussing processor design.
The architecture consists of the instruction set and those features of a processor that are visible to software programs running on the processor. The architecture determines what software the processor can run. [...]
The term microarchitecture refers to the design features used to reach the target cost, performance, and functionality goals of the processor. [...]
The design implementation refers to a particular combination of physical logic and circuit elements that comprise a processor that meets the microarchitecture specifications."Ebben a közegben a néhány nagy öregen (Samsung, IBM, Intel) kívül egyre kevésbé finanszírozható házon belül az összes lépés, legutóbb látványosan az AMD is elvesztette/kiszervezte a gyártást és a bele ölt költségeket, és az IBM is erre készül; tehát ez legalábbis nem a tehetségesség vagy a tehetségtelenség mutatója.
Ha viszont ilyen vertikális tekintetben nézzük az egyes fázisok költségeit (K+F, termelési eszközök, gyárak, ...), akkor úgy tűnik, először is a gyártás a legköltségesebb, nála lényegesen kevesebbe kerül a microarch-fejlesztés; új architektúra (ISA) kidolgozása pedig a legkevésbé költséges, lévén - nem lebecsülve a szükséges tudást, - inkább elméleti, mint gyakorlati dolog. A gyakorlat is ezt látszik igazolni, eddig legalábbis a leggyakoribb a "design implementation" váltás volt, kevésbé gyakori a microarch-újratervezés (bár az Intel - kissé érthetetlen, vagy piacilag nem teljesen magyarázható módon - a kettőt évente váltogatta), a legritkább az új ISA-k létrehozása. Ez igaz GPU-fronton is.
Mivel eddig a nanométer-csökkentés volt a legfőbb fegyver hatékonyság növelése érdekében, ha ennek lehetőségei elfogynak, ennek megfelelően egy-egy architektúrát "birtokló/felügyelő" cégnek még mindig kevésbé érdeke az ISA-ja felújítása, viszont igenis érdeke a legtöbbet kihozni microarchitecture-szinten belőle; ez pedig együtt jár - SZVSZ végre - a software-es oldalra helyezett nagyobb hangsúllyal is (gondolok itt arra, hogy az AMD se dobta volna be a pl. Mantle-t, ha számításai szerint úgy haladna a chip-hatékonység fejlesztése a következő 10 évben, mint az elmúlt 10 esztendőben).
A gyártó cégeknek viszont érdeke, hogy minél több eszköz legyen legyártva, hisz a csökkenő mm2-re eső gyártási költségek melletti növekvő egyéb költségek csak úgy behozhatók, ha minél több chip kerül legyártásra. Internet of Things, you know.
-
HookR
addikt
"A legnagyobb ellenség a Heisenberg-féle határozatlansági reláció. Ez nagyjából a 2000-es évek eleje óta létező probléma és minden generációváltásnál egyre jobban felerősödik. Jelen pillanatban nem találjuk a jelenség megkerülésére a megoldást..."
Akadnak érdekes kutatási eredmények a témában: Tricking the Uncertainty Principle
-
Fiery
veterán
"A hatékony szálkezelés a hatékony skálázhatóság alapja"
Es kevesebb szalat nem konnyebb kezelni?
Miert kene egy adott feladatra sok szalat radobni, ha keves szal is gyors tud lenni? Plusz, ki mondta hogy a jovobeni, adott esetben x86 alapu Intel "GPU"-k csak negyszeres HyperThreadinggel fognak uzemelni? Miert ne lehetne 16x vagy 32x? Akkor mindjart tobb ezer szalrol beszelunk Tudom, sok-sok regiszter kell hozza, de hely van, legalabbis ha az Intel a 10 nanot is tudja hozni idoben... -
Fiery
veterán
Az, hogy egy adott architektura hany szalat kezel, az valahol teljesen mindegy. Ennyi erovel azt is feszegethetnenk, hogy melyik hany MHz-re skalazhato, az is teljesen mindegy. A lenyeg, hogy egy adott feladatot, pl. egy bazinagy adathalmaz AES-256 kriptalasat melyik architektura milyen gyorsan oldja meg. Ha ehhez mondjuk egy Hawaiinak 10000 szalat kell inditania, akkor annyi. Ha ugyanazt a feladatot azonos sebesseggel megoldja egy KNL mondjuk, de eleg neki 288 szal hozza, akkor nem tokmindegy, hogy hany szalig skalazodik az adott ISA?
"Miben lesz rosszabb, ha például a C++ programod HSA-ra fordítod és nem natívan GCN-re? Talán abban, hogy futni fog más ISA-n is? Tényleg nem értem, hogy ezzel mi a gond."
Elvben tok jo. Gyakorlatban vannak vele problemak, mint ahogy irtam is. De mindegy, hagyjuk, nem egy dologrol es nem egy problemakorrol beszelunk.
-
Fiery
veterán
Miert kellene, hogy megegyezzen a HSAIL utasitaskeszlete mondjuk a GCN utasitaskeszletevel? Vagy ha "teljesen veletlenul" megegyezik, azaz van direkt megfeleloje minden HSAIL utasitasnak, akkor mi a biztositek arra, hogy ez ugyanigy fog mukodni a GCN utani AMD ISA-nal, vagy mondjuk a Qualcomm vagy a Samsung sajat ISA-janal? Vagy mondjuk az x86-nal? Hiszen a HSA-nak mukodnie kene x86 CPU-kon is, vagy barmilyen x86 alapu GPU-n is.
"Lesznek külön toolok, de a gyártók ezeket is szabványosítják"
Hogyan fogjak szabvanyositani? Milyen toolok? Ki fogja kesziteni a toolokat? Konkretumokat kerek, nem papiron letezo igereteket.
-
dezz
nagyúr
"Az x86/AMD64-ben van full 32 bit UINT/INT támogatás. A GCN ezt átmentette, és lényegében ugyanazokat az integer matematikai trükköket teszi lehetővé, amiket a fejlesztők alkalmaznak a CPU-kon."
Az jó, de ez még csak egy kisebb része az egésznek. Nem vitatom, hogy közelebb állnak, mint akorábban, de egy GCN CU így is eléggé más, mint egy normál CPU mag (kevesebb benne a "sallang", sokkal inkább párhuzamosított végrehajtásra optimalizált, mintsem skalárra), és az egész GCN alapú GPU is eléggé más, mint az Intel many-core CPU koncepciója (más a buszrendszer, kevésbé önállóak a CU-k, viszont külön egységek vannak az igazgatásukra).
Az Intel egy univerzális magokat akar, az AMD viszont úgy gondolja, a CPU jobb skaláris számításokra, a GPU pedig párhuzamosra. És ugyebár van egy olyan mondás, hogy ami mindenre jó, az semmire sem jó igazán. Mint írtam, ezt az Intel a gyártástechnológiai előnyével próbálja ellensúlyozni, csak kérdés, ez meddig sikerülhet.
(#14167) Fiery: Még ha nem is lesz valamilyen kimondott OpenCL alternatíva, később az is egyfajta alternatívát fog jelenteni, hogy C/C++/Javában is le lehet majd programozni ugyanazt. A Java részévé fog válni a párhuzamosítás.
"Engem mint fejlesztot szemely szerint nem erdekel se az ISA, se a threadek szama, se az egysegnyi tranzisztorra juto fogyasztas."
Ez így azért eléggé leszűkített látómező. Egy dolog, hogy mi lenne kényelmes a fejlesztőknek (a legjobb egy több THz-es CPU lenne) és egy másik dolog, hogy a fizikai törvények mit hagynak megvalósítani, jelenleg szilícium alapon. Egy a jövőről folyó eszmecseréből ez nem hagyható ki.
"Az Intelben azt dijazom, hogy legalabb kiallnak egy adott platform (x86) mellett, azt nyomjak, azt eroltetik, arra fokuszalnak."
Még jó, hogy ezt próbálják nyomni, ez a legfőbb ütőkártyájuk.
Az előzőből kimaradt: "lefele meg az ARM-ot szorongatja"
Ez vicces, inkább talán az ARM szorongatja őket alulról (úgy is mondhatnám, a töküket).
-
Fiery
veterán
Ha a regebben leforditott programok ennyire nagy problemat jelentenek, es ennyire problema lecserelni X evente az ISA-t, akkor mi van az ARM vs. x86 kerdessel, az AMD-nel? Ott nem gond, hogy nem mukodnek ARM-on a legacy x86 szoftverek? Megjegyzem, ahhoz, hogy a HSA-t, az OpenCL 1.x-et vagy epp a Mantle-t ki tudd hasznalni, ahhoz teljesen uj szoftvereket kell kesziteni, tehat mar ott uj szoftverre van szukseg. Miben kulonbozik ez attol, mint ha a most megirt x86 szoftvereket 7 ev mulva ujra kellene irni? Egy 7 evvel ezelott irt x86 szoftver sem fog raszagolni sem egy GCN GPU-ra manapsag. Miert fontos akkor az, hogy ha most irnank egy nativ GCN szoftvert, akkor az nem futna a GCN utani generacion, 2021-ben? Ha ennyire fontos az ISA-hoz ragaszkodas, akkor az x86 a kiraly
De a mai vilagban pont nem azt latom, hogy az ISA-hoz valo ragaszkodas lenne a legfobb kerdes, plane a mobil es ultramobil vonalon. -
Fiery
veterán
"Ott nincsen több gyártói implementáció."
Hogy a fenebe ne lenne?! A HSAIL kodot valahogy at kell forditani az aktualis CPU vagy GPU sajat ISA-jara.
"Egyedül a finalizer térhet el, de akkor már nem lehet hibázni, hiszen a kód lefordult."
Hogy a fenebe ne lehetne hibazni? A kod nem fordult le, a HSAIL-t me'g at kell forditani egyszer. Gazdagon van abban is hibalehetoseg. Hivhatod finalizernek, compilernek, barminek, attol me'g van egy forditasi lepcso, ami gyartonkent eltero es el lehet **szni egyenileg maskepp es mas mertekben.
Amugy meg, lesz HSA-hoz debugger es profiler? Nem lesz, mert az gyarto-specifikus lenne, hiszen vastagon az ISA szintjere kellene lemenni. Az AMD fejleszt ilyesmit? Ketlem, naluk mar az OpenCL rendkivul buta, egyszeru beepitett profilozoja is bugos. Vagy a Qualcomm, vagy a Samsung fejleszt ilyesmit?
"Nincs többféle irány az AMD-nél. Az x86, az ARM csak a serial ISA."
Nincs tobbfele irany, de csak a serial ISA-ra irsz 2-t
Furcsa dolgok ezek."Az ARM azért fontos, mert egy csomó szerverpiaci szereplő ARM-ot akar."
Talan meg kene oket gyozni egy utokepes x86 megoldassal, es nem lenne gond. Ha igy folytatja az AMD, lesz egy kozepszeru vagy annal sz*rabb x86 core-ja, meg egy hasonlokepp kimagaslo ARM core-ja is. Ha ez nekik igy jo...
"Minden a HSA-ban fut össze."
Marmint az AMD lazalmaiban legfeljebb
Mert amugy en nem latom a mozgolodast az Intelnel, nem latom az nVIDIA-nal, nem latom a Google-nal (Android) sem, de me'g a Microsoft sem tulzottan kardoskodik a HSA mellett. Egyedul az AMD nyomja, meg van nehany tamogato (Samsung, Qualcomm, VIA, stb), amik meg vagy csinalnak valamit, vagy nem, de leginkabb nem, mert mindenki csak var-var-var. Sz'al a nagy nulla fut ossze a HSA-ban, ami egyelore egy hatalmas nagy nulla, es nem latszik, hogy mikor lesz belole barmi is. -
Fiery
veterán
Igen, mert a HSA sokkal egyszerubb
Papiron, talan. Csak epp a problema az, hogy mig egy monolitikus sok-sok (72+) magos, sok-sok (288+) threades CPU-t tudsz HSA/OpenCL-lel _is_ programozni meg direktben (x86 + AVX-512) is, addig a GPU-knal marad a HSA/OpenCL, es kesz. Ha nem mukodik eleg jol, mert az adott gyarto (pl. AMD) sz*r implementaciot keszit (ha keszit egyaltalan), akkor megsutheted a vasat. Ez a legnagyobb problema mind a mai napig: az AMD jo vasat (GPU) keszit, csak nincs meg hozza a megfelelo, kiforrott, korrekt software stack. Anelkul meg nincs semmi. A kutya nem fog direktben GCN assemblyben programozni AMD GPU-t -- mig arra sokkal tobb esely van, hogy valaki, a szamara mar amugy is ismeros x86 assemblyt beveti mondjuk egy KNL-en.Arrol nem is beszelve, hogy me'g mindig nem ertem, miert kell ugyanazt a lemezt felrakni. Oke, volt/van egy MIC, ami nem mukodik igazan hatekonyan. De ki mondta, hogy ugyanez a koncepcio lesz a Skylake-ben vagy a KNL-ben? Ki mondta, hogy a near memory vagy egyeb trukkok (amit me'g nem ismerunk, pl. Skylake-rol szinte zero info van jelenleg) nem tudjak ellensulyozni azt, ami jelenleg problema a MIC kapcsan? A GCN persze tok jo, csak azt meg senki se tudja leprogramozni, mert nincs hozza normalis software stack. Mit er egy jo vas, ha nem tudsz vele mit csinalni?
Az meg plane szuklatokoru hozzaallasra utal, ha azert ignore-alod Te vagy mas az Intel "GPU" terveit, mert volt egy rossz koncepcio, egy-ket evolucios zsakutca (pl. MIC vagy IA-64) az Intel tortenelmeben. Anno mindenki kesz tenynek vette, hogy a K8 az istencsaszar es a NetBurst meg f*s, aztan lattuk mi lett abbol is. Az Intel evekig erolteti (talan feleslegesen), de vegul kepes kukaba dobni egy koncepciot, ha van helyette egy jobb megoldas. A NetBurst is ment a levesbe, mert volt Conroe helyette, ami jobb volt. Ha a MIC a gyakorlatban (KNL) nem mukodik eleg jol, majd lesz helyette mas. Az x86-ra mar 10 eve es 20 eves is azt mondtak sokan, hogy zsakutca, aztan milyen fura, hogy me'g mindig itt van velunk, es felfele mindent lesoport (az IA-64-gyel egyutt), lefele meg az ARM-ot szorongatja jelenleg. Ha pedig az x86 vegkepp nem valik be a compute temaban, akkor hosszutavon siman eldobhatja azt is az Intel, es lesz helyette mas. Anno az IA-64-gyel is ez volt a terv, abbol is lehetett volna adott esetben x86 utani architektura...
Amiben en maximalisan nagy fantaziat latok, az -- es most tegyuk zarojelbe az x86-ot mint architekturat, nem az itt a lenyeg -- a GPU felvaltasa egy olyan sokmagos processzorral, ami mindent hazon belul megold. Ha kell, altalanos feladatokra is hasznalhato remekul (mint most az x86 CPU magok), ha pedig az kell, akkor a compute-ot is gyorsan vegrehajtja.
-
stratova
veterán
Jim Keller visszatérése kapcsán olvasgattam kicsit egy két nyilatkozatában érdekes részleteket hintett el.
1. AMD következő x86-os megoldásáról:
They will be closer in frequency to the 4 GHz of AMD's latest Kaveri x86 SoC than today's 2 GHz ARM chips, he said. For Skybridge, AMD tweaked its new Puma x86 cores to look more like an ARM V8 core.AMD upgraded its current on-chip fabric, I/O and memory-management units so they could accommodate either the Puma+ or standard ARM cores in Skybridge. The fabric gets an upgrade for the custom ARM cores coming in 2016, probably made in a 16/14nm FinFET process.
"We got the IP, SoC and fabric right, then worked on how to plug the cores into them," he said. Skybridge provided an opportunity to "get the [SoC] plumbing right," he added.
Keller suggested AMD will consolidate its work on separate Bulldozer and Jaguar x86 cores into one processor line in the future. Meanwhile, the team had to bring up new verification and design flows for ARM SoCs.
Much of the architectural work on the upcoming AMD chips is done and the company is well along in implementing them, Keller suggested. AMD is apparently already well along in the custom designs that will use a 16/14nm FinFET process that he said "looks pretty good, we're happy with it."
2. Gyártástechnológia kapcsán:
Keller considers largely solved the issues dealing with multiple-patterning lithography required for the 14/16nm processes in which his team is designing the first K12 chips. Just adding on more metal layers is no longer an option, but "we have other proprietary tricks," he said.For the 14/16nm process, his team had to scale challenges with the vertical FinFET transistors it uses. He notes of all the parts of his team, the design for manufacturing and test groups have grown the most over the years.
Itt netán már az utolsó (D) árbára célzott?
A. PD-SOI pl. AMD Phenom II/Llano
B. FD-SOI pl. ST mintachipje
C. FinFET Bulk pl. Intel Ivy/Haswell (bár a 3D Tri-Gate így néz ki náluk)
D. Vertical FET BulkEsetleg ha így jobban tetszik:
Vagy ne rohanjunk annyira előre és "csak" az Inteléhez hasonló finFET kialakításnál a silicon fin okozott némi gondot?
-
leviske
veterán
Azt már összeraktam korábban az egyik "Intel bérgyártónak áll" hír alatt is, hogy önmagában a csíkszélesség nem számít semmit, de engem az érdekelne, hogy a Samsung-féle 14nm esetében mi a helyzet, mit lehet várni. A GloFo terve ugye egy egységes 14nm-XM volt, ami emlékeim szerint olyan sajátságokkal rendelkezett, ami az AMD-nek is kedvezett volna. A Samsung verziója ezzel milyen viszonyban van?
(#14139) Fiery: A Larrabee-t a mérete miatt hoztam ide, a többire meg annyit tudok mondani, hogy olvass vissza. Feleslegesnek tartom még azzal pluszban szemetelni a topikot, hogy plusz hozzászólásokon keresztül magyarázom meg. Felmerült egy ötlet, arról én elmondtam a saját véleményemet. Ennyi.
Ezen túlmenően már csak azzal a gondolattal játszottam el, hogy mi lenne, ha a következő gyártástechnológia váltás tudna 4x tranzisztor/mm2 arányt hozni az AMD-nek, de Abu most így lehűtött, hogy ilyesmit egy darabig nem kell várni.
Innentől maradok annál az eredeti véleményemnél, hogy az AMD-nek most az elsődleges feladata a felsőkategóriás, óriás méretű lapkák erőltetése helyett a HSA erősítése és a Kaveri/Carrizo kihasználtságának fokozása, ezzel talán idővel egálba kerülve az Intellel. -
Fiery
veterán
Altalanossagban 14 nanos node-rol beszeltem, nemtom miert kell az Intel sajat 14 nanojat idekeverni
Amugy is csak elmeleti lehetosegek ezek, hiszen kapasbol a Tahitit mar nem érné meg 14 nanora lehozni, inkabb akkor mar a Hawaii egyfajta butitott valtozatat. De annak meg joval nagyobb memoria savszelesseg is kellene, sz'al egy Itanium-szeru rettenet lenne belole a Vishera magokkal megfejelve... -
stratova
veterán
Abu, ebben mi a ráció? Az még OK, hogy el kell passzolni a HD8570M-eket, de miért éppen ott ahol sok haszna nincs? Legfeljebb Mantle megjelenésével, mobil Kaverivel társítva.
Vagy hogy egy kicsit is komolyabb gép esetében A10 APU csak komolyan felextrázott gépbe kerül (alapból 1TB HDD, 8GB RAM, néha gyárilag SSD), azonos körítéssel olcsóbb ugyan a konkurenciánál, de az induló ár az előbbiek miatt közel azonos. Jobbak már a kilátások idén OEM partnerség ápolására? AMD jövőképét tekintve érthető, hogy a fejlesztők megnyerésén volt a fókusz, de kinek fejlesztenek ha egyes piacokon (EU) egyáltalán nem kapni bizonyos modelleket? Tudom új stratégia, hogy szinte elébe mennek a fejlesztői igényeknek, de így nem hogy ajánlani saját részre vásárolni sem könnyű a kisebbik gyártótól.
A SteamBox vonal kompakt részlegét is meglovagolhatnák, mert 1600x900-ig nem rosszabb A10-7850K mint a konkurens i5/i7 R Iris Proval. Az új DG azért bizalomgerjesztő mobil platformra szánt/fix hardveres kiépítése esetében. -
eastone1
senior tag
-
dezz
nagyúr
Tulajdonképpen milyen az a "HSA-ra írt program"? Tudomásom szerint jelenleg OpenCL és C++ AMP kódokat lehet a HSA keretrendszer fordítójával HSAIL-re fordítani (ami a javás bytecode-nak felel meg), ami aztán HSA-kompatibilis környezetben futtatható. Később pedig ezt kiterjesztik hétköznapibb programnyelvekre is (gondolom, szintén autovektorizációval, stb.).
(#14056) Fiery: Az arányokra gondoltam.
-
letepem
aktív tag
Ha jól értelmezem akkor Rory ezt az irányzatot indította el? Mármint az AMD fejleszt hardvert a fejlesztőknek, nem a fejlesztők szoftvert a hardverhez? Remélem érthető amire gondoltam!
Fiery: Esetleg van valami doksi az AVX-ről, amiből lehet tanulmányozni a működését/előnyeit/hátrányait?
-
leviske
veterán
Azt sejtettem, hogy a Carrizo nem fog változni, de azt a 100GLOPS teljesítményt nem érzem annyira univerzálisnak... Értem én, hogy platformosodik a cég és igyekszik egy bizonyos felhasználási módra kihegyezni a termékeit, de azért remélem, hogy hosszú távon a igyekeznek megtartani a PC pozitívumait. Csúnya lenne, ha elérnénk egy olyan pontot, amikor egy Excel táblát csak egy AMD tud megnyitni, míg egy Word doksit csak egy Intel.
Emellett nem lenne rossz, ha azért olyan partnerek igényeit vennék figyelembe, akikre a felhasználóknak igénye van.
(#14035) Fiery: A helyzet nem új keletű. Aki eddig vásárlásokból befolyó összegekből akarta fenntartani magát, az már sokkal korábban koppant egyet. Szerintem.
De most én nem az ARM helyzetének az elemzésébe akartam belemenni, hanem arra vagyok kíváncsi, hogy a HSA mennyire jelent az ARM/X86 platformok között átjárást. Azért tőled kérdezem, mert az itteni csapatban valószínűleg te foglalkoztál a fejlesztések során a legtöbbet a témával.
-
stratova
veterán
Ez a 100 GFLOPs az az elméleti GFLOPs amivel AMD szokott példálózni a diáin?
(CPU core x CPU clk x 8 + IGP core x IGP clk x2) elméletben ezt még a 65/45 W-os A8-7600 is megugorja.
Az is érdekes, hogy szerver vonalon Toronto APU eleve SoC, de még Carrizot csak 65 W-os TDP-re tervezik. (miért csak az SWE-n találtam most meg a ti képeteket?
)
Az 1 TFLOPs elméletit egy 10 CU-s Cape Verde is megugraná ~800 MHz-en. Bonaire-re kaliberrel (14 CU) pedig az 1,5 is 850-en. Bár ez utóbbihoz gondolom már kellene a 20 nm. -
leviske
veterán
Hm. Akkor valamit nagyon benéztem, mert nekem úgy rémlett, hogy 4 modul lesz. Meg mondjuk, ha hosszú távon akarnak 2 modulon bohóckodni, akkor idővel szükség lehet az SMT használatára is, nem? Vagy az CMT mellett megoldhatatlan? (Bár ezt a kérdést egyszer azt hiszem már feltettem a topikban, szóval elnézést az ismétlésért.)
Amúgy értem én, hogy a HDL-t korábban is használták, de a Kaveri-ben már a teljes lapka azzal lett tervezve, nem? Mert, ha a CPU részt sikerült azzal megtervezni és olyan hatásfokkal, amit a tranzisztorszám/lapkaméret arány sugall, akkor szerverekbe mehetne egy feleakkora processzor, mint eddig. És Piledriver mellett még lenne is idejük kitesztelni jobban a technológiát, mire jön az új termék. Gondolom ennyi fáradozást megérne a szerverpiac.
(#14028) Fiery: Elég sok fejlesztőcég szeretne betörni az ARM piacra, köztük a Microsoft is. Az eddigi ismereteid szerint a HSA nagyjából mennyire tudna ebben segíteni? (Induljunk ki abból az ideális helyzetből, hogy minden ARM gyártó full támogatja a HSA-t és már mindenki csak a szoftverekre vár.)
-
leviske
veterán
Mondjuk engem meglepne, ha a HP, Dell vagy akár pont az Acer számára derogálna kismillió gépet kiadni, amikből 1-1 az Intel/AMD/nVidia irányzat felé mozdul. Pláne, hogy az nV/Intel elképzelés egyelőre megvalósíthatónak tűnik egy gépben is. Vagy dGPU esetén máris elesik a gyártó a marketingtámogatástól?
-
devast
addikt
Igen, ez a marketing szöveg
Vagy az az igazság, vagy az, hogy hónapokig ment a brainstorming a meetingeken, hogy hogyan lehetne növelni a cpu fronton a piaci részesedést úgy, hogy (gyártástechnológiai + anyagi + egyéb okok miatt) nem tudnak teljesítményben versenyezni.
Az intel is rohadék, mert nem lépett be a hsa-ba, mikor tudja, hogy az jó, de a piaci érdekeivel ellentétes. És a piaci erőfölényet könyörtelenül ki fogja használni a hsa ellen, ezért látom jelenleg még túl kockázatosnak az egészet. -
Arról van infó, hogy az AMD jövőképében hogy szerepel a High-End PC-s játék piac?
Arra gondolok, hogy a saját csúcs kártyáik erejét mi módon tervezik kihasználni? Akarnak ide saját erős CPU maggal rendelkező APU-t, vagy ezt átengedik az intelnek?
Esetleg a Mantle-től, vagy egyéb alacsony szintű API-tól várják a CPU tehermentesítést széles körben? -
atti_2010
nagyúr
Hát ez az hogy a CPU limit egyre ritkább manapság de a TrueAudio és a Mantle alatt nyert teljesítmény többet jelenthet, persze ez függ attól is hogy hány játékba kerül be a Mantle és hogy hogyan futnak az új konzolokra tervezett játékok a Kaverin, de mivel ezekről még nincs teszt nem tudni hogy melyik konfig éri meg.
-
devast
addikt
Még egy jó ideig ps3-ra és xbox360-ra is jönni fognak ezek (Fifa 14 is van mindkettőre), és addig nem hinném, hogy full hsa-ra építik őket. Ha meg csak pár plusz effekt, vagy extra dolog használja, akkor felmerül a kérdés, hogy megéri-e (nem implementálni szoftver oldalról, mert az triviális lesz, hanem user oldalról kaveri apu-ba fektetni).
-
Fiery
veterán
Ez egyebkent remek magyarazat lenne arra, hogy funkcionalisan miert nem valtozott a Beema/Mullins a Kabini/Temash-hoz kepest. Mert en szemely szerint nem ertettem azt, hogy mi a kulonbseg az elozo generaciohoz kepest. Hiszen funkcionalitasban -- legalabbis az AMD dokumentacioi szerint -- lenyegeben nincs kulonbseg, SVM-et sem tamogat még az uj generacio, azonos processzen keszul, szinte azonos a tokozasa, azonos a magszam, latszolag nagyon hasonlo az iGPU-ja is, stb. De ha az egesz Beema/Mullins lenyege az, hogy a performance/Watt mutatot egy jo nagy lepcsovel feljebb nyomjak, akkor mar vilagos minden, igy varjuk szeretettel, a Bay Trail-t igy siman le tudjak nyomni majd, es nem csak iGPU-ban. Foleg arra leszek kivancsi, hogy clock-for-clock is lesz-e fejlodes a Kabini/Temash-hoz kepest, vagy "csupan" azonos orajelen fog kevesebb TDP-vel gazdalkodni a Beema/Mullins. Furcsa lenne, ha az architekturaba is melyen belenyultak volna, mikozben a funkcionalitast valtozatlanul hagytak, de vegul is nem lehet kizarni ezt a lehetoseget sem.
-
stratova
veterán
Asszinkron Mantle feladatelosztás
No ez mikorra várható? Tekintve, hogy az új asztali útiterven a korábbi szervereshez hasonlóan nyoma sincs frissítésnek AM3+on.
Beeman pedig nem tudom mit faragtak, de az hogy a 15 W-os veri a 25 W-os verziót hozhatna egy kis felfrissülést az anorexiás termék vonalon Sőt a 25 W-os akár házon belüli konkurenciát is jelenthetne (CPU-ként) Kaverinek mobil vonalon? -
-
Fiery
veterán
"A CUDA az olyan dolgot nem kínál, amit az OpenCL ne kínálna fel. Még csak gyorsabb programok sem írhatók benne. Az OpenCL-lel alapvetően ugyanúgy tudod használni bármelyik GPU-t, mert a lényeges dolgokban egyezik a CUDA és az OpenCL. Némileg persze más a körítés, de amit CUDA-ban megírsz azt legalább ugyanolyan jól meg tudod írni OpenCL-ben."
...
"A fejlesztői oldalon a CUDA-t azért cserélik manapság OpenCL-re, mert pont ugyanarra jó, így felesleges két fejlesztési irányt fenntartani. Ha csak az OpenCL-re koncentrálnak a fejlesztők, akkor összességében még jobb is lehet a sebesség, mintha írnának CUDA és OpenCL portot egyszerre. Ez egy előnyös dolog a piac minden résztvevőjének: kevesebb fejlesztéssel gyorsabb programok, melyek futnak minden gyártó újabb hardverein. Minden szempontból win-win szituáció."Kivetelesen 100%-ig egyetertek Abuval. Mi is gondolkoztunk azon, hogy az OpenCL GPGPU stressz tesztet vagy az OpenCL GPGPU benchmarkokat portoljuk-e CUDA-ra, de semmi ertelme. Ugyanazt a funkcionalitast, ugyanazt a teljesitmenyt kapod. Sot, ha jol tudom, a ForceWare az OpenCL kodot az elso forditasi fazis utan mar a CUDA feluleten keresztul forditja tovabb es futtatja le, ergo tok mindegy, melyiket hasznalja az ember. Amikor az OpenCL-ben me'g nem lehetett lekerdezni pl. az NVCC-t (Compute Capability), azaz detektalni a GPU generaciojat (pl. Fermi vs. Kepler, GK10x vs. GK110, stb), addig talan volt ertelme a CUDA-nak, mert jobban lehetett specifikusan optimalizalni. De most mar az OpenCL-en at is 100%-osan lehet detektalni az nVIDIA GPU tipusat, az NVCC-t es a PCI eszkozt is, ergo ez az elonye is elveszett a CUDA-nak.
A Mantle kapcsan egyebkent hamarosan beszamol az AMD reszletesen is az API-rol, en szemely szerint nagyon kivancsi leszek ra, mert ha eleg jol van kitalalva, akkor baromi sok mindent ki lehet majd belole hozni. Mondjuk en azert is orulok a Mantle-nak, mert vegre valami felbolygatja az allovizet. Ahogy az angol mondja: S*it hits the fan
-
dezz
nagyúr
"Az AMD-nek speciel pont ezért kellett az ATI, mert megvették vele a HDL-t is."
Legfeljebb ezért is kellett nekik...
(#13420) leviske: Egyszerű: a nextgen konzolokba AMD chip került, nem NV. Így kellő hátszéllel indul a Mantle, aminek a megjelenése egyben szükségszerűség is.
Egyébként milyen grafikus API lesz a SteamOS-ben?
-
leviske
veterán
"Kevesen tudják, de őket is érinti a DirectX fejletlensége."
Ezen a ponton viszont számomra teljesen érthetetlenné vált a mostani helyzet. Adott egy cég, aki gyakorlatilag már 2008-ban neki akart menni az Intelnek és ha a körülmények adottak lettek volna, akkor lazán a háttérbe is szorítják mind a két processzorgyártót. Ez a cég nemrég (tudtommal) szorosan részt vett egy, játékokra kihegyezett operációs rendszer kifejlesztésében.
Mégis hogy a fenébe lehet, hogy pont az AMD állt elő saját API-val, miközben az nVidia számításait évek óta keresztülhúzza a Microsoft a DX fejlesztési irányával? A Steam OS/BOX pont egy tiszta lap lett volna a cégnek és az nVidia ARM-es jövőképe az eddigi elhangzott Valve-es tervekkel össze is vágna. (Ugye az eddigiek alapján amolyan nyíltforrású WiiU ellenfelet akar a cég, valamivel több HC címmel.)
-
Oliverda
titán
Anno amikor bejött a CUDA még nem tartott ott az OpenCL ahol most, de ezt továbbvezetve az sem kizárt, hogy később a Mantle is a CUDA sorsára jut, ha jön egy olyan API ami képes lesz gyártófüggetlen modellel hozni a teljesítményét. Ha az OpenCL-nek ez sikerült akkor miért ne. Amúgy sem tesznek jót a piacnak a zárt API-k, így felőlem az összes mehet a levesbe.
-
-
Oliverda
titán
-
Oké, akkor a játékos részét értem.
Mi lesz az egyéb szoftverekkel? 3D tervezés, animáció, stb.
Itt a GCN-es FirePro a stratégia, vagy CPU/APU szinten is terveznek valamit újítani?Oké, láttam, hogy a HSA-t támogatják sokan, ahogy pár hsz-szel elöbb írtad.
Autodesk-ről, vagy egyéb 3D-s tervező szoftveres cégről van bármi infód? Ezek mintha be lennének betonozva az intel-nV világba, az Autodesk-kel az élen.
-
#13383
kriszpontaz
veterán
Abu85
#13374
kriszpontaz
veterán
Olyan lehangoló hogy ezekben a felsorolásokban soha nem látok Autodesk feliratot!
Se az Autocad, se a C3D nem bír 2 magon (inkább 1,5, mert a második magot csak 50%-on járatja a többi meg alszik) felül többet kihasználni. Szeretném már látni hogy ez az egy cég is ráfeküdne picit az optimalizálásra, de sose hallani róla. -
Fiery
veterán
"Ők mind írják a szoftvereket."
Tehat megint jovo idorol van szo, oke, csak gondoltam tisztazzuk
Tehat a HSA ugy terjed, hogy egyre tobben foglalkoznak a dologgal, gondolkoznak rajta, esetleg mar fejlesztenek valamit HSA-ra. Ez is egyfajta terjedes, vegul is, de en inkabb akkor mondanam terjedesnek, amikor hetente egy-egy hir jon majd arrol, hogy epp milyen HSA-capable szoftver (vagy jatek) jelenik meg a piacon. No meg nem artana hozza egy stabil HSA SDK sem..."Most fejlődött a legtöbbet a belső north bridge-IMC"
Feature szinten igen. Csak nem teljesitmeny szinten.
-
Fiery
veterán
"tekintve, hogy a vártnál sokkal gyorsabb a HSA terjedése"
Hol vannak a HSA implementaciok? Hol vannak a HSA-ra irt szoftverek? Vagy ugy erted, hogy az elozetes varakozas az volt, hogy az implementacio (mondjuk az AMD HSA SDK) 1 ev mulva keszul el, es akkorra lesznek kesz az elso HSA-t kihasznalo szoftverek; de kozben most meg ugy fest a dolog, hogy 6 honapra modosult mindket datum mostantol szamitva?
A karogast meg en nem csak a driverek kapcsan hallottam, olvastam, hanem a nyers CPU ero kapcsan foleg. Az emberek hozzaszoktak az olyan valtasokhoz, mint a P4 utan a Conroe, a Lynnfield utan a Sandy Bridge (stb), amikor no az orajel (me'g ha csak Turboval is), es no az IPC is. Most meg megallt -- latszolag -- az Intel is (ha az AVX2-t es az FMA-t nem szamoljuk), az AMD is, sot, elindultak visszafele (Kaveri, orajelben).
-
Fiery
veterán
Ha szerinted nincs ertelme AVX-et meg AVX2-t tabletbe rakni, akkor miert rovod fel az Intelnek a szegmentacio teremtest?
A TDP kapcsan igazad van, nekem kimaradt az A4-1200, csak a nagyobbakat neztem. Mentsegemre szoljon, az A4-1200 eleg harmatos teljesitmenyu, fejben en azt zarojelbe is tettem, hiszen az Atom Z3770 siman lenyomja, barmikor, kiveve persze iGPU-ban. A Jaguar nagyon jo architektura, de az az 1 GHz-es alaporajel, Turbo letiltva, csupan 2 mag, az keves, nagyon keves. Nem hiszem, hogy tul sok tabletet adnanak majd el A4-1200-zal, de ne legyen igazam. A Z3770-nel egyebkent a long duration Turbo power limit 5W, de a "sima" TDP-rol nincs info a CPU-ban, sajnos.
-
Fiery
veterán
Ne csusztassunk azert ekkorat, kerlek. Mobil alatt kell erteni a hagyomanyos notebook/laptop, DTR, ultrabook (es esetleg az all-in-one desktop) szegmenst is, leven hogy ezekbe is mobil processzorok kerulnek. Az Intelnel minden felsorolt szegmensben van AVX es AVX2 tamogatasu CPU (Haswell, Crystal Well), csakugy mint az AMD eseteben (Trinity, Richland, es hamarosan Kaveri). A tabletekben nincs AVX tamogatas az Intel Bay Trail-T eseteben, mig a Temash eseteben van. De azt azert jegyezzuk meg, hogy ha a Temash TDP-je lenyegesen magasabb, mint a Bay Trail-T-e, ami miatt az iPad-hez hasonlo kialakitasu, azaz hasonlo meretu es vastagsagu, passziv huteses tabletekbe a gyartok inkabb a Bay Trail-T fogjak szerelni. Ez nem segit az AVX-nek, ez teny, de velhetoen a jovore erkezo Airmont (Cherry Trail) eseteben az Intel berakja az AVX tamogatast. SZVSZ azert nem kerult be a Silvermont-ba az AVX, mert egyszerre akarjak implementalni az AVX-es es az AVX2-t (es esetleg az FMA-t is), de az nem fert volna bele a megcelzott keretbe 22 nanon. De ez csak az en sejtesem, nem teny.
-
Fiery
veterán
Lehet, hogy nagyon buta kerdes, de ha a gugli nem akar OpenCL-t Androidon, de HSA-t akar, akkor milyen nyelven fognak fejleszteni a joemberek HSA-ra Androidon? Java? RenderScript? Es mit csinalnak azokkal a fejlesztokkel, akik nagy nehezen belerazodtak az OpenCL 1.x-be (mondjuk PC-n), es a nyomorult gugli miatt most kenytelenek lesznek atallni egy uj nyelvre?
Tok jo egyebkent, hogy mindenki mast akar, mindenki ezerfele huz. Ertem en, hogy a HSA tok jo, mert tobbfele nyelvet is tamogat, de a fejlesztoknek mar most is kivan a haja a sokfele nyelvvel, most bejon me'g nehany, minden platformon mas lesz a preferalt nyelv... Agyrem.
-
-
Fiery
veterán
"Azért az OCL2.0 nem csak egy shared virtual memory és kész."
Oke, de en feature szinten feszegetem azt a kerdest, hogy mennyire koppinthato a HSA. Ha lemasolod a HSA-t, de kicsit lassabb, kevesbe skalazhato lesz, az me'g mindig jobb, kivanatosabb lehet vegeredmenyben, mint a mostani OpenCL 1.x-es megoldasok. Ugy is mondhatnam, egy masolt HSA teljesitmenyben a mostani OpenCL-es programok es az "igazi" HSA-s megoldasok koze eshet.
-
Fiery
veterán
En is azt irtam, amit Te irsz
"A HSAIL annyi, hogy akik a HSA-t támogatják a saját vISA-jukat erre cserélik. Ezzel biztosítva egy igen alacsony szintű kompatibilitási réteget."
Persze, ez egy tok jo dolog, ha masokkal egyutt akarsz mukodni. De ha lekoppintod a HSA-t, akkor maradhatsz a sajat IL-ednel, nem kell vacakolni ujjal.
-
Fiery
veterán
Azt azert az Intel vedelmeben erdemes megemliteni, hogy az "x86 rule the world" eddig azert eleg jol mukodott, es bizonyitott. Lenyomtak vele egy halom eros ceget es architekturat, hazon belul me'g az IA-64-et is, es az iGPU vonalon kivul mindenhol remekul mukodik mind a mai napig az x86 (a konzolokban is
). Na jo, a telefonokban meg a tabletekben sem igazan villog az x86, de a Silvermont nagyon jo cucc, helyrerakja a dolgokat megint, es ott a Temash is.Maga az a teny, hogy egy hosszu evek ota eroltetett koncepcio nem mukodik, nem mindig szegi kedvet az Intelnek (Itanic), de hosszutavon, ha adodik egy jobb alternativa, akkor kepes az Intel is iranyt valtani. Megtortent mar az AMD64-gyel is (bar ott kenyszerhelyzetben voltak a Microsoft miatt), megtortent mar lenyegeben az Itaniummal is, na meg ott volt a Tejas is.
Ha a MIC mondjuk me'g 5 evig nem fut be, akkor tutira kidobja az Intel, es csinal valami mast helyette. Bar, nekem mar az AVX-512 is gyanus: miert nem az LRBNI-t hozta at az Intel a desktopra, miert forditva csinalja? Kerdes persze, hogy ha me'g tovabb erolteti az Intel a MIC-et, akkor nem fog-e tul sokat vesziteni vele...
-
Fiery
veterán
Oke, de ha a HSA legacy modban megy, akkor nem sokkal jobb, mint egy OpenCL 1.2-es jelenlegi rendszer. Akkor csak a video driverrol valo levalasztas az elonye, a gyorsabb kernel launch meg a jobb queuing. Ezek meg osszessegeben nem nagy dolgok, sajnos, az igazi dobas a megosztott memoria. Ertem en, hogy azonos modon kodolsz, de ha amugy is az OpenCL-t valasztja a fejleszto nyelvnek, akkor a HSA legacy modja es a mostani OpenCL-es megoldas kozt azert nincs olyan nagy kulonbseg.
-
Fiery
veterán
"A HSA az nem csak CPU és IGP integrációja. Annak van egy memória és queueing modellje."
Marmint arra gondolsz, hogy a megosztott memoria mukodesehez van szukseg -- tobbek kozt -- IOMMUv2-re. Ez stimmel is. A HSA-hoz alapkovetelmeny a megosztott memoria, amihez az AMD-nel kell az IOMMUv2. De a HSA kapcsan felesleges IOMMUv2-t igenyelni vagy nezni vagy keresni; a lenyeg, hogy ha nem mukodik a megosztott memoria, akkor nem HSA-capable a vas, tehat HSA szempontbol irrelevans.
"Ugyanolyan támogatása lesz így ennek mint a Trinity/Richland APU-nak."
Vagyis semmilyen, ha a HSA szemszogebol nezzuk. A megosztott memoria nem fog mukodni, ez a baj, ahogy a Trinity/Richlandnel sem mukodik, hiaba van ott az IOMMUv2.
-
Fiery
veterán
22 nanon 1,86 milliard tranyo es 257 mm2 egy 6 magos Ivy Bridge-E. Ebbol nagyjabol lehet kovetkeztetni a tranyo surusegre -- persze egy iGPU mas tema, mint egy sima CPU, es a MIC cache mereteket sem tudjuk. Ha a szamitasaidat vesszuk figyelembe, akkor csak az iGPU lenne mondjuk 276 mm2 MIC alapokon, 22 nanon. Mivel 14 nanon jon a Skylake, igy kis tulzassal skalazzuk azt le 175 mm2-re mondjuk. Ez me'g mindig csak az iGPU, 2 milliard tranyoval.
A CPU+Uncore resz meretere nehez becsleseket adni, hiszen nem tudjuk a cache mereteket, valamint hogy AVX-512 lesz-e mar a Skylake-ben. Az szinte biztos, hogy 4 magos lesz. De legyen mondjuk hasonlo meretu es kialakitasu, mint a 4 magos Sandy Bridge-E, csak 14 nanon gyartva, ugyhogy legyen mondjuk a CPU resz 1,3 milliard tranyo es 128 mm2. Ezzel a CPU+Uncore+iGPU osszesen 3,3 milliard tranyo es 303 mm2. Ez nem kicsi, de nem is mondanam legyarthatatlannak. Meretben hasonlo kategoria, mint a Sandy Bridge-E (ami 32 nano / 4 mag: 294 mm2), a tranyoszam meg nem nagy cucc, gyartott mar ennel sokkal durvabbat is mindharom GPU gyarto. A Crystal Well kapasbol nagyobb (348 mm2) az eDRAM-mal egyutt, bar annak a tranyoszamat nem tudjuk. Megjegyzem, a 2 modulos Trinity/Richland sem sokkal kisebb, cca. 250 mm2.
Mas kerdes persze, hogy mennyit disszipalna egy ilyen proci, es mekkora orajeleken tudná hozni a Kaveri vagy a Carrizo tempojat. Az AMD-s sracok nekem pont azt elemezgettek, hogy az Intel baromi jo cuccokat tud gyartani, csak az orajel a baj, azt nem lehet tulsagosan felnyomni, mert nagyon megszalad a TDP. Ugyhogy ha iGPU-rol van szo, es a hw dizajn megfelelo, akkor egy megfeleloen alacsony orajelen mukodhet a dolog 2 milliardnyi iGPU tranyoval SZVSZ.
-
Fiery
veterán
Sok mindenre mondja azt az AMD, hogy ugy a legjobb, ahogy ok csinaljak. De az ilyen dontesek mogott sokszor az is all(hat), hogy ok igy tudjak megoldani a problemat. Minden generacional arrol beszelnek (AMD), hogy a kovetkezo mennyivel kozelebb hozza oket a vegcelhoz. Mindig van egy igeret, hogy a kovetkezo mennyivel jobb lesz. Inkrementalisan epitkeznek, sok evbe telik (7-8), mire elerik a vegcelt. Az Intel mas utakat jar, nekik van kapacitasuk meg eroforrasuk arra, hogy radikalis valtoztatasokat eszkozoljenek, kiprobaljanak ujszeru dolgokat. Aztan vagy belebuknak (Itanic), vagy nem. Az LLC kapcsan pedig az is megoldhato lenne, hogy ha pl. egy kozos cache-be dolgoznanak, csak az jol el lenne szeparalva 2 reszre, amikor az iGPU is szemetel. Persze akkor minek a kozos cache, johet a kerdes? Hat pl. azert, mert ha a CPU-nak kellene a nagy cache, akkor jol jonne. Ezert baromi jo az eDRAM: azt tudja hasznalni a CPU is L4 cache-kent. Ha megnezzuk, mennyi cache van egy Kaveriban, es mennyi egy Crystal Well-ben, hat eleg brutalis a kulonbseg. Persze tudom en, hogy minden az iGPU-rol szol, es a CPU csak disznek van ott, minek gyorsitani holmi cache-ekkel
-
Fiery
veterán
"Az Intelnek a MIC-kel pont az a problémája, hogy sokkal több tranyó beépítésére lenne szükségük, mint ami lehetséges"
Oke, akkor beszeljunk konkretumokrol a MIC kapcsan. Ha jol sejtem, az Intel altal megcelzott teljesitmeny az 1 TFLOPS (egyszeres pontossaggal), hiszen a Kaveri is kozel ennyit fog tudni, a Carrizo pedig minden bizonnyal -- nemileg -- meg fogja haladni ezt a teljesitmenyt. 1 TFLOPS-ot MIC-kel hogyan tud az Intel eloallitani _szerinted_? Milyen orajel, hany mag es hany tranzisztor szukseges hozza?
A driver meg tenyleg sz*r, de azon a legkonnyebb csiszolni, javitani. Ne ugorjatok a torkomnak mindjart, en is tudom, hogy ez csak elmeletben van igy, es sok idobe telik
Csak epp ha van egy valamilyen iGPU hardvered, azon menet kozben mar nem tudsz varialni; viszont a driver benasagat a meglevo vasakra is tudod me'g menet kozben finomitani. Mindennek az alapja egy jo vas lenne, a driver-team meg elobb-utobb majd csak felno vegre a feladathoz. Megjegyzem, siman lehet, hogy a MIC-es megoldast azert is erolteti az Intel (ha a desktopra is erolteti), mert drivert es/vagy OpenCL compilert sokkal egyszerubb lenne irniuk hozza. De ez megint csak egy sejtes, nyilvan mas faktorok is szerepet jatszanak a dontesben. A tranzisztorszam viszont biztosan nem, legalabbis nem olyan szinten, hogy azon akarnanak sporolni. Van boven tranyo, csak az ertelmet kell kitalalni par milliardnak -
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?
-
#12987
TESCO-Zsömle
titán
Abu85
#12986
-
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
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Ha meg nem tudjak megoldani, ha zsakutca lesz vegkepp a MIC, akkor majd elovesznek egy B-tervet. Az Intel behuzta mar magat tobbszor is zsakutcaba (NetBurst, Itanic, Tejas), es mindig meg tudott ujulni, mindig volt ujabb otletuk. Mint ahogy az AMD-nek is, mellesleg, ok is ugyesen tudnak valtani. Majd lesz valami mas, ha a MIC nem valik be.
)
Se az Autocad, se a C3D nem bír 2 magon (inkább 1,5, mert a második magot csak 50%-on járatja a többi meg alszik) felül többet kihasználni. Szeretném már látni hogy ez az egy cég is ráfeküdne picit az optimalizálásra, de sose hallani róla.
Ú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.
- ÁRGARANCIA! Épített KomPhone Ryzen 7 9800X3D 32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
- Samsung Galaxy A53 5G 128GB, Kártyafüggetlen, 1 Év Garanciával
- HP 200W (19.5V 10.3A) kis kék, kerek, 4.5x3.0mm töltők + tápkábel, 928429-002
- REFURBISHED és ÚJ - Lenovo ThinkPad 40AS USB-C docking station (akár 3x4K felbontás)
- LG 27GR95QL - 27" OLED / Limitált LoL Edition / QHD 2K / 240Hz & 0.03ms / NVIDIA G-Sync / FreeSync
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest