- iPhone topik
- Honor Magic5 Pro - kamerák bűvöletében
- Honor 400 - és mégis mozog a kép
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
- Betiltották a Pixel 7-et Japánban
- One mobilszolgáltatások
- Poco X6 Pro - ötös alá
- Rekord vékony lesz a Z Flip7 is
- Milyen okostelefont vegyek?
- Samsung Galaxy A54 - türelemjáték
-
Mobilarena
OLVASD VÉGIG ALAPOSAN MIELŐTT ÚJ HOZZÁSZÓLÁST ÍRNÁL!!!
Új hozzászólás Aktív témák
-
HSM
félisten
Persze, ezt mind lehet, és ez így is van. A lényeg csak annyi, hogyha bármit odaütemez egy kritikus szál mellé az OS, akkor szívás van. Ugyanis a folyamat prioritását veszti, a magon belül a hardver nem aszerint fogja végrehajtani. Ilyen helyzet pl. a DX11 játékoknál gyakran előfordult. De több feladat párhuzamos futtatása mellett is futottam már ebbe bele. (Pl. videózás egy erősen többsazálú program háttérben futása mellett, ott is kézzel kellett az affinitásokban turkálni, nem volt elég a priorizálás.)
-
HSM
félisten
Arra gondoltam, hogyha van egy (vagy néhány) kritikus szál, amiktől függ a többi munkavégzése, akkor lassíthat a HT, ugyanis megosztja az erőforrásokat, és nem tudod priorizálni a kritikus folyamatokat.
Nem hiszem, hogy bárhogy előfordulna a gyakorlatban ezen kívül, hogy lassuljon miatta, miért lassulna? Minél több feladatot adsz a magnak, annál optimálisabban tudja őket végrehajtani....
A gyakrolati tapasztalataim is ezt támasztják alá. -
#17543
Petykemano
veterán
dezz
#17542
Petykemano
veterán
Hát... nem tudom ez az Apple custom SoC egyelőre inkább a wishful thinking kategória. De jó lenne, ha úgy lenne.
Mit gondolsz, egy ilyen cucc
- adhatna löketet az IGP-t használó általános alkalmazások térnyerésének (HSA, openCL, stb)?
- nem késő 2017-2018-ra? (2017 nem, de reálisan nézve 2017-2018 => 2018) -
Simid
senior tag
Egy ilyen HBMs APU-val szerelt mini alaplap vajon nem lenne vonzó az Apple számára?
Nekik elég fontosak lehetnek a kis méretből fakadó lehetőségek, hogy kifizessék a 8-16GB HBM felárát és elég nagy is a volumen, hogy fejlesszenek rá valami egyedit. Gyakorlatilag csak egy forrasztott SSD meg egy tápellátás kellene mellé.Más esetben nehezen tudom elképzeli, hogy jövő ilyenkorra lenne értelme HBM-s APUk kiadásának.
-
Fiery
veterán
Ha a NUC/UCF meretbe (10 x 10 cm-es alaplap) befer az SO-DIMM memoria foglalatbol 2 db, plusz egy M.2 es egy MiniPCIe foglalat, akkor nem gondolnam, hogy pont az AMD-nek kellene ilyen formatumu miniPC-knel a BGA memoriaval vacakolnia. Plane mivel az AM4 foglalat maga megszabja azt, hogy egy NUC meretbe mar eleve bele sem fog ferni a konfiguracio... Tehat a legkisebb ami SFF alaplapok kapcsan szoba johet, az a Mini-STX (14 x 14 cm-es alaplap), arra meg boven rafer most is a (2 db) SO-DIMM foglalat, me'g kulso chipsettel (pontosabban deli hiddal) es M.2 foglalattal + MiniPCIe foglalattal egyutt is, pl. --> ASRock H110M-STX
Az egyertelmu, hogy a tabletek vilagaban nagyon jol jon a BGA tokozasu RAM, de az AM4 nem oda valo, es a kollega is alaplapokrol beszelt.
-
-
#17052
Petykemano
veterán
dezz
#17047
Petykemano
veterán
hétköznapi = ami miatt gémer józsi fontolóra venné, hogy a nagymamájának, vagy irodába ptöyögni AMD-t vegyen.
Csomó programot felsoroltál, amiknek kb felét ismerem/hallottam róla. Thrawn jól állapította meg: "a vindóvzt nem gyorsíccsa."
Komolyra fordíta a szót:
Abu azt sugallta, hogy a kaveri az IGP megfelelő kihasználsa mellett gyorsabb lehet, mint egy i7. Én nem is bonyolódnék bele abba, hogy de miben, meg hogy. A lényeg, hogy egyelőre nem jött el az a szoftveres kánaán, amelyben általánosságban, hétköznapi értelemben (nagymamának, irodába, játékra, stb) ha egymás mellé állítod a kettőt, akkor a kaveri győz.Az urak ezt az "ígért" eredményt hiányolták.
Viszont feltűnt, hogy nem különböztetted meg a GPGPU, opencl tekintetében azt, hogy különálló CPU és GPU végzi a gyorsított feladatot, vagy fusion apu, aminek a sztory szerint az lenne a lényege, hogy nem kell PCI-E vagy más speciális csatornákon keresztül (nvlink) másolni az adatokat a GPU memóriájába, hanem mindkét részegységnek helyben rendelkezésre áll. Elvileg erről szólna a hUMA. Ehhez képest a múltkori olajkeresős cikkben arról beszélnek, hogy az APU másol adatokat memóriaterületeket, csak vagy hardveresen, vagy explicit.
Ha igaz az, hogy a fusion hybrid apu cpu és gpu részegysége mindenfőle hUMAbugok ellenére sem tud másolgatás nélkül, az adat helybenmaradásával dolgozni, akkor ez valójában semmivel nem jobb, mint egy megfelelően gyors busz a cpu és a gpu között, csak annyi, hogy a busz szerepét maga memóriavezérlő tölti be: olyan gyors tud lenni, amilyen gyorsan a memóriavezérlő tud adatot másolni a memória egyik részéről a másikra. Ez elég gyalázatos lenne és számomra megmagyarázná, hogy miért is nem olyan korszakalkotó a megoldás és hogy miért is nem ért el átütő sikert és eredményeket. ÉS persze azt is, hogy a legújabban megjelent AMD HPC apu skecceken miért szerepel a HBM a GPU résznek dedikálva és miért köti össze a CPU és GPU részt a 100GB/s-os GMI: hogy mert valójában hUMA APU esetén is a központi memóriában tárolt (egyik) helyről másolni kell az adatot egy másik helyre ahhoz, hogy a GPU dolgozzon rajta, és teljesen mindegy, hogy ez a hely maga a központi memória egy másik szelete, vagy egy belső nagysávszélességű dedikált memória.
Jól látom ezt? -
lee56
őstag
Jójó nem is írtam hogy nincs rá példa, de kb össze is szedted az összes manapság,ami csak van. Mára már sokkal de sokkal de sokkal többnek kéne lennie, szerintem te is egyet értesz. Nem 2 nap alatt valóban, de 10 éve lassan hogy látják az irányt (vagyis az x86-os skálázódás határait).. Mégis mire tippelsz,még mennyi kellhet hogy oda is érjünk, vagy "ott vagyunk már" (by szamár)?
-
#17044
Petykemano
veterán
dezz
#17043
Petykemano
veterán
A kollégák nyilván arra gondoltak, hogy hol vannak a hétköznapi számítógépen használt alkalmazások, amelyeknél az amd apu gyorsabb az i7-nél az igp-nek köszönhetően?
(Szerintem ez be fog következni, de nem felétlenül közvetlenül az amd miatt, vagx az amd hardverein. Az arm, a qualcomm, a mediatek is hsa tagok. Ha valahol valamiért, akkor a mobil piacon bekövetkezhet egy váltás. De elképzelhetőnek látom azt is, hogy ha a zen sikeres lesz, akkor az intel aktiválja a számítógépek 95%-ban jelen levő igp-jét. Persze nyilván ez se egy perc. Az amd-nek ilyenfajta siker learatására két elméleti lehetősége lehet: ha sikerül a zennel valami hpc szerződést megcsípni és építhet "big apu"-kat, amihez hozzáírják a szoftvert. Vagy ha az apple esetleg úgy döntene, hogy pc szegmensben nem fejleszt, hanem custom zen apukat rendel az amdtől, amihez a jól kontrolált szoftveres környezetét hozzáigazítja és így jelentős teljesítmény/élmény előnyhöz juttatja vásárlóit más pc/android félhasználókkal szemben.)
-
Simid
senior tag
Nyilván tisztában vagyok vele, hogy mennyi idő egy új uarch fejlesztése. Arra gondoltam, hogy ezeket mind idén szeretnék bemutatni (plusz K12, de annál lehet nem idén volt a cél).
A "mit csináltak ez elmúlt pár évben?" költői kérdés félreérthető volt. Nyilván Zen és Polaris. Viszont akkor ezekkel remélem időben érkeznek, mert más dolguk nem nagyon volt. Nekem kicsit ijesztő, hogy Bristol kapcsán egy stepping váltás + új foglalat kombo sem jön össze nekik...
Goose-T: Lásd feljebb.
-
-
Fiery
veterán
Myrtle-rol nem lattam me'g fotot a weben. Nekem van 2 fotom is rola, egy korai (tavaly novemberi) meg egy iden aprilisi.
"Igen, jól néz ki a Gardenia, de a hozzánemértő nagyközönséget nem célszerű ilyen bonyolult lappal "sokkolni". Az ISSCC azért egy kicsit más, mint egy Computex, Cebit, stb."
Talan igazad lenne, csak epp a Zen kapcsan pont hogy pozitiv sokkot okozott volna, ha bemutatnak egy mukodo peldanyt
Vagy Neked nem lenne tokmindegy, hogyan nez ki a PC, amennyiben Zen dolgozna benne? Felolem tele lehetne smiley-s matricakkal is, csak lassak egyet mukodni 
"Nem mondanám, hiszen a Vishera a módosított energiatakarékosság és tápszabályzás miatt igényelt módosított platformot (miközben néhány letiltott funkcióval egyes AM3 lapokban is elment). A Kaverinél már nem emlékszem, mi volt a "bibi"."
Az architektura szempontjabol akkor is irrelevans. Az mas kerdes, ha a gyarto olyan plusz funkciokat epit be, ami foglalat cseret indukal. De ez szigoruan veve nem az architektura resze akkor sem. De akarhogy is, a Summit Ridge es a Bristol Ridge fejlesztese nagyjabol egyutt zajlik -- csak az egyikkel kevesebb a melo --, emiatt pedig nincs az a veszely, hogy az egyik vagy masik miatt a platformot at kellene tervezni.
-
Fiery
veterán
Az AMD sajat AM4 foglalatu teszt platormjat ugy hivjak, hogy Myrtle. Teljesen hagyomanyos full-ATX alaplap. A HDT-t leszamitva nincsenek rajta speci csatlakozok. Van rajta 4 teljesen hagyomanyos DDR4 DIMM, 2 db teljesen hagyomanyos x16 PCIe foglalat, meg egy par egyeb PCIe slot (x1, x4). Teljesen hagyomanyos ATX tap csatlakozok vannak rajta. Az egyeduli furcsasag -- mar persze azon felul, hogy kicsit iparinak nez ki --, hogy a chipseten ventilatoros hutes van. Na most ha van ilyen alaplap, foto is van rola, a foto mar legalabb 2 honapja keszult, es megsem tudjak egy uvegkockaban bemutatni az alaplapba rakott Zent mukodes kozben, az mit jelenthet?
Egyebkent tudom, hogy milyen alaplapra gondolsz, pl. a Gardenia (Carrizo es Bristol Ridge BGA) vagy epp a Larne (Kabini, Mullins, Beema) tesztplatform is ilyen. De az me'g brutal jol is nez ki, en legalabbis szeretek ranezni
Nem gondolnam, hogy ne lehetne akár egy ilyen dizajnt is mutogatni. Es amint lathato pl. itt, volt mar ra pelda, hogy mutogatta ezeket a speci fejlesztoi platformokat az AMD. Ehhez kepest pedig egy Myrtle me'g csak nem is nez ki gyokeresen maskepp, mint egy akarmilyen gyarto altal keszitett, piacra szant, low-end ATX alaplap."Hülyeség? Gondoljunk csak az AM3 - AM3+-ra és az FM2 - FM2+-ra. Eredetileg ezeknél sem volt szó a +-os változatról, aztán mégis."
Az teljesen mas helyzet volt. A BR es Summit Ridge (es nem mellesleg Raven Ridge) eseteben mar a kezdetektol fogva pontosan tudta mindenki, hogy milyen platformot fognak kapni. Hogy egyetlen foglalat lesz, egyetlen chipset, egyetlen platform. Ez eleve cel es kovetelmeny is volt a tervezeskor. Az AMD most nincs abban a helyzetben, hogy lehuzza a wc-n jovore az idei (AM4) foglalatot. Nem beszelve arrol, hogy a masik oldalon (Intel) is kitolodtak ujabban a platform eletciklusok, legalabbis ami a foglalatot illeti. Mar nem trendi az uj procihoz uj foglalat, hacsak nem kivanja meg a memoria generacio valtas. Ami az AM4-nel pont jo utemben tortenik.
"Az Ivy Bridge esete más, az nem vadi új (mikro)architektúra, csak egy shrink"
Az teljesen mindegy. A foglalat szempontjabol irrelevans az architektura. A vegul kukaba kerult Socket FF1 BGA tokozasba is 2 teljesen mas architekturaju proci erkezett volna: Nolan (x86) es Amur (ARM). A foglalat/tokozas megis ugyanaz lett volna mindket esetben, sot, az uncore resz is.
-
Fiery
veterán
"Gondolod, hogy nincs mibe beledugniuk, csak úgy fogdossák, nézegetik a procit?"
En szemely szerint azt gondolom, hogy ha van is, amibe beledugjak az AM4-es procikat, az nem eleg stabil ahhoz, hogy:
1) Szeleskorben teriteni tudjak a gyarto- es fejleszto partnerek fele (ES peldanyokat persze)
2) Bemutassak mukodes kozben is. Ez alatt ertsd: egy atlatszo desktop hazban az alaplap + CPU + DDR4 RAM dolgozik, M.2 SSD-rol fut a Windows, a kijelzon pedig lathato, hogy ez egy 16 szalas cucc, ami minden szalon vegez valami szamitast. Odaig mar ne menjunk el, hogy 3-4 szoftvert is futtatni kellene, bemutatva, hogy tenyleg mukodik a cucc, mar tenyleg csak az utolso simitasok vannak hatra, es indulhat az 1-es pont
"A BristolR-ről is elég konkrét telj./fogy. javulási viszonyszámot közöltek."
Az AM4 verziorol? Biztos, hogy a 65W TDP-vel rendelkezo, AM4 foglalatos verziorol kozoltek adatokat?
"Szerintem ők is és az alaplapgyártók is egy készközeli lapkát várnak a SummitR-ről, hogy lezárulhasson az AM4 tesztidőszaka és validálhassák végre. Mert szép lenne, ha kiadnák a BristolR-rel és utána kiderülne, hogy nem megy rendesen, illetve csak módosításokkal a SummitR. Nem lenne szerencsés egy AM4+ pár hónappal az AM4 piacra kerülése után."
Ez hulyeseg. Ennyi erovel a P67 chipsetet meg LGA1155 alaplapokat sem szabadott volna addig kiadni, amig nem tudtak levalidani a platformot az Ivy Bridge CPU-kkal is... Egy foglalat, chipset meg ugy altalaban platform specifikacio ha jol van kitalalva, akkor a kesobbiekben erkezhet bele uj proci, ami az eredeti platform elso piaci rajtjakor me'g nem letezett. Szamtalan peldat lehetne mondani erre. Eleg gaz az, ha az AMD vagy a gyartopartnerei olyan benak, hogy a Summit Ridge nelkul keptelenek kiadni egy AM4 platformot oly modon, hogy kesobb csak egy BIOS update-en muljon, hogy az uj procit a "regi" alaplapokba be lehessen dobni.
-
-
Fiery
veterán
En vigyaznek az ilyen Zen Lite megnevezesekkel, plane ha az AMD hasznalja azt. A Carrizo Lite sem volt mas, mint a Beema/Mullins atnevezese. Valojaban koze nem volt a Carrizohoz vagy a Bulldozer csaladu processzorokhoz. Ezzel fedtek el a tenyt, hogy a Nolan kukazva lett, es probaltak azt erzekeltetni, mintha a 2 szeria egy csaladba tartozna. Ha lesz is konzolba szant 14 nanos APU iden vagy jovore, 100%, hogy nem a Zen architekturara fog epulni. Sokkal egyszerubb megoldas az, ha egyszeruen nyomnak egy die-shrinket a meglevo konzol APU-kra, meg esetleg kicserelik az iGPU-t Polaris alapura. Azaz, tovabbra is a Cats architekturat viszik tovabb az x86 magok kapcsan. A 14 nanos shrink egyebkent megoldhato lenne a Beema/Mullins kapcsan is, de nem hiszem, hogy az AMD ezzel akarna vacakolni. Sanszos, hogy az ilyen low-power desktop es mobil gepekbe inkabb a Stoney Ridge-et (azaz kb. Bristol Ridge osztva 2-vel) szanja az AMD, es nem akarja a Cats vonalat tovabbvinni a PC kapcsan.
-
dezz
nagyúr
Még egy infó, ami segítheti a megértést: az utasításkészlet tagjainak (és azok különféle címzésmódjainak) végrehajtásához eltérő számú órajelciklusra van szükség és ezekhez más-más IPC rendelhető (ez attól is függ, hogy egyet vagy többet tud párhuzamosan végrehajtani egy mag). A tipikus IPC meghatározására különféle módszereket lehet igénybe venni, pl. az említett IPC-k egyszerű vagy előfordulási aránnyal súlyozott átlagát lehet venni, vagy egy a különféle utasításokat átlagos előfordulási arányban, átlagos függőségi helyzetben tartalmazó szintetikus mintakód végrehajtásából lehet számolni. Nem tudom, az AMD melyik módszer híve.
(#16653) Petykemano: Jó kérdések. (A Zenre vonatkozóakat valószínűleg majd élőben való tesztelgetés során lehet megválaszolni.)
-
Direkt hagytam ki az SMT-t, mert nem tudjuk, milyen hatékonysággal dolgozik, és a számolásaim is valós magokra, illetve AMD modulokra érvényesek. Fontos: ki kell egészítsem magam, hogy szigorúan Cinebench R15 többszálú eredményekre vonatkozik minden fentebb közölt adat/spekuláció! Az egy szálas teljesítményt is ez alapján fogom lentebb meghatározni.
Kis adalék: korábban említettem, hogy az Intel valós magok ~95-97%-os hatékonysággal dolgoznak együtt MT esetén a CB-ben, a modulok pedig 80%-os hatékonysággal dolgoznak. Ezt értsd úgy, hogy
Ha 1 mag 100 pont, akkor
4 valós mag esetén a MT pontszám 380-390 körül van
2 modul esetén az MT pontszám 320 körül vanPont az a helyzet, hogy az Athlon X4 845 3.5GHz-en 321 pontot csinál MT-ben. Tehát turbó nélkül egy szál 3.5GHz-en 100 pont körül lesz.
Scenario 1:
Ha a Zen 3.5GHz-en 1 szálon hoz 40% IPC növekedést, akkor 140 pontot kellene hoznia, négy szálon ez 532 pont. Ezt a pontszámot egy Haswell i5 3440 MHz-ből hozza, tehát akkor ott vagyunk a Haswell szintjén, de a Skylake-nek is csak 3265 MHz kell hozzá, azaz ~7%-ra lennénk a Skylake-től.Scenario 2:
Ha a Zen EXW modul vs 2 Zen mag szinten hoz 40%-ot, akkor az 100*0,8*2=160*1,4=224/2/0,95=118 pont per szál lesz, ami az EXW-hoz képest csak 18% szálankénti IPC javulást jelent. Ezzel az eredménnyel van az Sandy mögött 4%-kal és a Skylake mögött 27%-kal.Ha az első scenario jön be, akkor boldogok lehetünk. A másodikkal viszont nem fog az AMD jelentős piaci részesedést szeretni az Intellel szemben, kivéve ha jó áron kínálja a terméket.
#16643 dezz: Mivel én csak távolról ugatom a témát, nem vagyok CPU tervező mérnök és csak spekulálni tudok, az IPC javulást úgy értem, hogy azonos órajelen a Zen annyival több pontot hoz CB-ben, mint az Excavator. Tényleg leegyszerűsítem, mert nem látok bele a dolgokba. Az is lehet, hogy az AMD sunnyog, és az a 40% IPC növekmény csak nagyon speciális esetben jön ki, azaz például CB-ben közel sem lesz annyi a növekedés (akkor számíthatunk a Scenario 2-re).
Egyébként fogalmam sincs, Stiltnek honnan jött az a 46%, amikor az AMD mindig is 40%-ot említett.
-
Nagy a baj, ha ez igaz!
Egy G3220 Pentium (Ivy Bridge) csinál 3 GHz-en 2 maggal 225 pontot CB15-ben. A leírtak alapján számításaim szerint ehhez a Zennek 3.6 GHz-re lenne szüksége. Egy Phenom II X2-nek ehhez a ponthoz 4.5GHz kell, az Excavatornak 5.3 GHz.
Saját magához az AMD előrébb van ezzel, de 17% IPC lemaradást jelent egy Ivy Pentiumtól. Sőt, ezzel Sandy alatt vagyunk. Nem hiszem, hogy ez az, amire várunk...
-
-
Fiery
veterán
"Azért egy Piledriver->Excavator váltás azonos órajelen nem elhanyagolható tényező. Az IGP és talán az IMC terén is történtek kisebb változások. (Godavari->Carrizo váltás és erre jön még egy jelentős steppingváltás.)"
Oke, de en azt feltetelezem, hogy az ide irogato APU tulajdonosok tobbsege vagy eleve high-end APU-t hasznal (6800K, 7850K, stb), vagy egy lepcsovel alatta levot. Egy ilyen APU-rol pedig nincs sok ertelme BR-re valtani, egyszerubb akkor mar inkabb a penzt beleölni egy jofajta 2.5 colos SSD-be. Egy SSD sok esetben sokkal nagyobbat dob az erezheto, mindennapi PC teljesitmenyen, mint egy 10-15%-kal gyorsabb CPU. Szigoruan SZVSZ
-
-
stratova
veterán
Fiery korábban ismertette a foglalat méreteit és pin-számot. Viszont elvileg ez a foglalat a 2 magos 4 szálas APU-któl (teljesen ép lapkát nézve) egészen a 8 mag 16 szálas termékekig terjed, utóbbi pedig már érinti az Intel LGA2011v3 "vadászterűletét" is.
Hát nem megelőzött?
ez van ha régi qwerty telóról ír az ember. -
leviske
veterán
Nem tudom, hogy mennyi értelme volna kiadni ugyanazt a lapkát egy 1300 és egy 900 pin-es foglalatra is az FP4 mellett. Pláne csak pár alsókategóriás FM2+ lap miatt. Az AM3+ vonalra több új lap jött.
Amennyiben meg az AM4 a pár hónappal ezelőtti ütemtervvel ellentétben a Summit-tal mutatkozna be, abban az esetben szerintem rengeteg embert elvesztene a cég a potenciális vásárlói bázisból. Mert valószínűleg nem én vagyok az egyetlen, aki a Bristol > Raven és Skylake/Broadwell(eDRAM miatt) fejlesztési utak közt tépődik. Az pedig elég könnyen az Intelek oldalára döntené, ha a Bristol gyakorlatilag kimaradna.
-
#16289
FireKeeper
nagyúr
dezz
#16288
FireKeeper
nagyúr
ami a foglalatokat illeti én azt gondolom az AMD tulajok már így sokkal jobb helyzetben vannak mint az intelesek, ahol ugye 2-3 családonként váltás, plusz mainstreamnek és HEDT-nek külön foglalat, ehhez képest ami az AMD-nél van/volt, maga a kánaán. sztem nem fog szarakodni az AMD emiatt.
-
stratova
veterán
Szvsz ez a dián az FP4 és nem AM4 foglalat miatt szerepel így. FP4-et használ Carrizo (6. generáció) és Carrizo-L is, viszont pl. a notebookgyártóknak olcsóbb egy DDR3-as kivitel, ahol a kereslet (haha..) függvényében eldönthetik, hogy modulos APU kerül a lapba vagy macskásodik (Beema csak DDR3-mat támogat).
BristolRidge kb. steppingváltás Carrozihoz képest kár lenne (az OEM-ek szempontjából) bukni miatta ezt a lehetőséget (anélkül is elég kevés gép készül AMD-s APU-val Intelhez mérten). -
-
Fiery
veterán
Az en forrasaim eleg szilardak, a problema sokszor inkabb az, hogy az AMD szereti az utiterveit ujratervezni, mondjuk fel evente egyszer minimum
En mindig az epp aktualis tervekrol tudok, de sokszor me'g en is le vagyok maradva par honappal A Carrizo pedig tamogat DDR4-et es DDR3-at is. Az AMD-nel pedig nem igazan jellemzo a komolyabb stepping valtas. Ha ok komolyabbat valtanak/fejlesztenek, akkor uj modellszamot szokott kapni a cucc a legtobb esetben. Igy lett uj modellszama a Kaverinak a Trinity/Richland utan, es a Carrizonak is a Kaveri utan. De a Bristol Ridge ugy tunik, a Carrizo modellszamat viszi tovabb, tehat en szemely szerint nem szamitanek tobb valtozasra/fejlesztesre, mint a Trinity -> Richland valtasnal. Persze ebbol az elmeletbol kilog kicsit a Stoney, ami uj modellszamot kapott, nem a Carrizoet viszi tovabb, de az meg egy low-end cucc, tehat kevesbe izgalmas itt a legtobbunk szamara -
stratova
veterán
Köszönöm a kiegészítést. :-) (rég láttalak erre)
-
Fiery
veterán
"De ezt a játékot is illik tisztességesen játszani."
Az a baj, hogy mindenkinek mast jelent a tisztesseges. Minden cegnel mashol vannak a hatarok. Aztan ha egymas ellen athagjak a hatarokat, jon a pereskedes. Ez mindennapos a cegek kozt, szamtalan ceg all most is perben egymassal. A legtobb ilyen aztan peren kivuli megegyezessel zarul, az egyik ceg kicsit enged, a masik ceg kicsit nyer a dolgon, es megy minden tovabb. Ez is a rendszer resze.
"A Google, Apple, Samsung nem arra törekszenek, hogy holnaputánra teljesen kiszorítsák vagy felfalják egymást, nem olvasztják be a SoC tervező cégeket sem. Kooperálnak velük és egymással."
Google? Apple? Samsung? Kooperalnak?! Ezen most jot nevettem
Az a Google aki folyamatosan gancsolja az OpenCL-t? Az az Apple, aki folyamatosan perli a fel vilagot, es szabadalmaztatja a lekerekitett sarkot? Az a Samsung, aki -- ez ugye a perbol kiderult egyertelmuen -- direkt es pontrol pontra igyekezett lemasolni az iOS mukodeset? Ugyan mar... Es igen, SoC tervezo ceget nem vasarolnak ezek a cegek, mert nem all erdekukben. Majd ha erdekukben all, akkor meg fogjak tenni. Ha az egyik a harombol holnaputan felvasarolja az nVIDIA-t, akkor mit mondasz? (zarojelben: az pedig csupan uzleti dontes kerdese, hogy az ellenseged altal gyartott termeket is vasarolod millioszamra. Ha olcsobban adja, mint a baratod, akkor is az ellensegedtol fogod venni, hiszen a profit es a versenykepes aru termekek gyartasa/forgalmazasa mindenek felett all. Uzletben nincs baratsag, ilyen egyszeru)"Az egészséges versenyt törvények szavatolják"
Igy van. Csak epp a torvenyek sosem 2+2 alapon vannak megirva, hanem ertelmezni kell oket, ill. azok betartasat vagy nem betartasat is lehet tobbfelekeppen ertelmezni. Ez nem matematika, sajnos, nem olyan egyertelmu.
"A kapitalizmusban sem gondolja azt mindenki, hogy mindenáron csak nőni és nőni kell. Fenntartható fejlődés, meg ilyenek."
O, dehogynem gondoljak ugy. Az egeszet a folyamatos fejlodes, folyamatos novekedes igerete es vágya mozgatja. Ha nem igy lenne, miert sz*rna be minden kozgazdasz es politikus egy 1-2%-os eves GDP novekedesi kilatastol? (amit egyebkent mar recesszionak belyegeznek egyes korokben...) Az pedig, aki cegvezetokent ugy gondolja, hogy nem a novekedes a lenyeg, hosszutavon el fog bukni, mert nem lesz ami sarkallja ot arra, hogy kemenyebben dolgozzon es kemenyebben dolgoztassa a dolgozoit. Egyik piac es egyik piaci pozicio sem tart orokke, es ha lazit egy ceg, ha nem igyekszik elegge, elobb-utobb egy nagyobb, erosebb, ambiciozusabb, torekvobb, szorgalmasabb, szerencsesebb ceg el fogja soporni.
Az Intel is megtehetné, hogy azt mondja, az ultramobil piacon sosem volt sikeres, nem is erdemes probalkozni, at lehet engedni az ARM-nak. Csak aztan jonnek a nagy ARM-os cegek, nekiallnak 64 bites ARM procikat gyartani, szervereket nyomni ARM alapon, es mi lesz a kovetkezo? Elobb-utobb ARM kerul a MacBook Air-be, utana a MacBook Pro-ba, es a vegen me'g a PC-kbe es a munkaallomasokba is. Ez a baj azzal, ha valaki nem torekszik a folyamatos novekedesre: jon majd mas, aki torekszik ra, es elsopri ot.
-
Fiery
veterán
Ne haragudj, de a szabadversenyes kapitalizmus igy mukodik, errol nem az Intel tehet. Ennyi erovel fikazhatnal egy nagy halom mas ceget is, pl. Google, Apple, Samsung, stb. A piaci versenyben minden ceg arra hajt, hogy egy adott piacon minel tobb termeket adjon el. Ennek lehet a meroszama az eladott darabszam, es/vagy a piaci reszesedes. Egy dinamikusan novekvo piacon eleg tartani a piaci reszesedest, akkor is folyamatosan novekszik a ceged, egyre sikeresebb lesz. Egy stagnalo piacon azonban masoktol kell elrabolni a piaci reszesedest, ha tobb termeket akarsz eladni. A piacrablas (tortenjen barhogyan is) vegcelja pedig a 100%-os piaci reszesedes, hiszen addig lehet csak novekedni, annal nincs tovabb. Nyilvan egy jo piacon, egy jol szabalyzott rendszerben senki sem erhet el 100%-ot a piacon, ezt a cegek is tudjak, de attol me'g lehet torekedni 90, 95 vagy akár 99%-ra
Ha ez a rendszer Neked nem szimpatikus, ne a cegeket fikazd, hanem a rendszert."Egy sor ARM-os cég éldegél vígan ezen a hatalmas piacon"
Es? Pont veluk kell megkuzdeni az Intelnek azert, hogy a tabletekbe es telefonokba ne ARM alapu processzor keruljon. Szep kihivas. Az x86 piacon sikerult 80%-ra feltornasznia az Intelnek magat, csak az a piac most mar kevesbe erdekes. Az ultramobil piacon viszont lenyegeben 0%-rol indul az Intel, onnan sokkal erdekesebb lesz akár csak 25%-ig is eljutnia. De ha az ARM-ot is lenyomjak (_ha_), es az ultramobil piacon is az x86 lesz az egyeduralkodo, es megint az Intel vs. AMD csata lesz ott is a jellemzo, akkor azt fogod mondani, hogy "köcsög Intel"? Csak azert kerdezem, mert uzletileg egy oriasi teljesitmeny lenne ezt megcsinalni (nem hiszem, hogy sikerulni fog), ergo inkabb csodalni kellene az Intelt emiatt
Csak ugye sokkal jopofabb dolog utalni egy ceget, ha tul nagyra nott, es a kicsiket meg babusgatni, mert szegenyeket mindig bantjak. A problem ott van, hogy az ultramobil piacon most az Intel a kicsike, lenyegeben a legkisebb, ergo most me'g lehetne akár szeretni is Aztan _ha_ tul nagyra no, akkor el lehet kezdeni utalni megint 
-
Fiery
veterán
Teljesitmeny/fogyasztasban jobb termeket adni azonos vagy alacsonyabb aron, raadasul ugy, hogy azt konkret tabletekbe es telefonokba is beepitik. Ez most az Intel legnagyobb kihivasa. A masik erdekes kihivas a mikroszerver piac (Avoton es majd Denverton), de ott elvileg sokkal konnyebb lesz az ARM-okat visszaszoritani.
-
Fiery
veterán
A Top500-ban tenyleg rengeteg AMD GPU van
De az is csak egy lista, nem feltetlenul reprezentativ. Sokkal tobbet mutat az, hogy a piacon milyen GPU szervereket lehet kapni. Amire igeny van, azt aruljak. De persze ez valtozhat, csak nem varazsutesre. A HSA egyebkent ezen a probleman is tudna segiteni "Azért neked sincs kristálygömböd."
Nincs, de ugy altalaban pesszimistan latom a PC-piacra tulsagosan tamaszkodo cegek jovojet. Az Intelet is, ha nem sikerul lenyomnia az ARM-ot a mobil piacon.
De szivesen hallgatom, hogy masok mit gondolnak az emlitett cegek jovojerol. Kovetkezmenyek nelkul lehet tippelgetni, nem fog senki a forum postok alapjan reszvenyt venni vagy eladni
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
Fiery
veterán
Ezekkel minddel az a baj, hogy "ha" meg "hozhatnak" meg "majd meglatjuk". Ez alapjan nyilvan az AMD-nek van eselye elorebb lepni, de ettol -- legalabbis a kozeljovoben -- a reszvenyek nem fognak tulzottan meglodulni, es a ceget sem fogjak a mostaninal sokkal nagyobbra ertekelni a piacon. Az AMD most nagyon nehez helyzetben van, de teny, hogy legalabb van egy csomo lehetoseguk kitorni. En egyikben sem latok tul nagy potencialt, de ennek az is az oka, hogy a PC-piac hanyatlik, es az AMD tulsagosan tamaszkodik a PC-piacra. Egy zsugorodo piacon nagyon nagyot kellene ahhoz guritani, hogy sikert csinalj. A tablet- es telefonpiac pedig annyira zsufolt es olyan nagy es eros szereplokkel van tele, hogy ott vegkepp nem latok eselyt arra, hogy az AMD igazan befusson. Nezzunk vissza a multba: amikor az ARM kozel sem volt ilyen eros, a PC-piac (+ dGPU-piac is) szarnyalt, es az AMD-nek csak 1 igazi CPU-gyarto konkurense volt (Intel) meg 2-vel tobb sajat gyara, akkor sem tudott hosszutavon 25%-nal nagyobb piaci reszesedest szerezni, akkor sem tudott atuto sikert elerni a piacon (nem a termekekre meg az innovaciora gondolok, abbol volt nem egy, ami nagyon jol sikerult). Most meg ott a zsugorodo PC-piac, ahol az Intel erosebb, mint valaha; es ott van az ARM, ahol nem egy ellenfele van az AMD-nek, hanem vagy egy tucat a kinaiakkal egyutt.
Az AMD egyebkent a jelenlegi tervei es a piac alakulasa alapjan egy piaci arusra kell emlekeztetni, akitol mindent be lehet szerezni olcson. Barmit kerhetsz, hozza, es minimalis haszonkulccsal adja. Ez is egyfajta taktika, ez is egyfajta uzletpolitika, csak a tehetseg es a fokusz ilyen merteku szetforgacsolasa egy ilyen kicsi cegnel rendkivul veszelyes _szerintem_. Tul sok helyen lehet hibat elkovetni, es ha eljatszod a partnerek bizalmat, onnan nagyon nehez forditani. Az nVIDIA peldaul egy sokkal fokuszaltabb ceg, sokkal kevesebb (darabra) es kevesebb fajta termekkel. En az nVIDIA-fele hozzaallast jobbnak tartom, de persze az is egyfajta forgatokonyv, hogy az AMD sokfele termeke kozul majd idovel kirostalodnak a nem sikeresek, es marad egy sikeres 3-as vagy 4-es fogat mondjuk. Kb. mint ahogy a Google futtatja a termekeket, termeszetes szelekcioval
-
Fiery
veterán
"Néhány évig még el lehet adni a dGPU-kat, nem beszélve a nagyobb haszonkulcsú FirePro-król."
Evente kb. 2-300 millio dollarnyi arbevetele van csupan az AMD-nek a dGPU eladasokbol. Ezt a globalis PC-piacon ugy hivjak: hibahatar. A FireProkbol meg ha nem tevedek, alig ad el az AMD. A Hawaii-ra epulo FirePro jol sikerult, de az elozo generaciosak nem voltak tul sikeresek. No meg akarhonnan is nezzuk, ez nagyon retegtermek. Manapsag mar maga a dGPU is retegtermek, hat me'g a FirePro/Quadro vonal belole.
"Mini- vagy szuperszámítógépet is lehet velük építeni."
Mibol? Ez nem Tesla. Mutass nehany GPU szervert, amiben FirePro van. Tesla alapu van, FirePro alapu lenyegeben nincs (pl. [link] -- a Supermicro pedig tenyleg nem vadolhato AMD ellenszenvvel, Opteron alapu szervert es workstationt is minden mennyisegben forgalmaznak). Szuperszamitogeprol sem tudok, amiben FirePro dolgozik... Eleve a szoftveres oldal a gond, elegge ra vannak allva a CUDA-ra a sracok. De akarhogy is, ebben a piacban sincs olyan rengeteg $$.
"Volt már olyan a világtörténelemben, hogy egy cég részvényindexe alaposan megemelkedett."
Volt, csak annak oka is volt. Mi lenne az ok az AMD-nel? Miben lehet bizni? Mi fog hozni rengeteg $$-t mondjuk 5 ev mulva? A PC-piac hanyatlik, azt ne is emlitsd. A konzolok stabil bevetel, azt mar belearazta a piac az AMD ertekebe. De robbanas a konzolpiacon nem lesz. A dGPU-piac meg haldoklik. Mi marad? ARM? Amivel csak most kezdenek molyolni, me'g azt se lehet tudni, hogy milyen termeket keszitenek, mire lesz az jo, mennyire lesz sikeres?
-
Fiery
veterán
"A GCN (egyben) egy termékvonal, a Puma magos chipek is termékek (nem igazán az ARM-ok ellen, hanem inkább az ARM és a komolyabb x86 procik között foglal helyet) és a kozolok APU-i is, amik természetesen növelik a cég értékét. (Ha valaki megvenné, ezekből még évekig jelentős bevétele lehetne, minimális ráfordítás mellett, ha nem nem terveznek további fejlesztéseket.)"
Az AMD osszes APU-ja (Bulldozer + Puma + konzol) x86 alapu, tehat megveheted az AMD-t, de utana ezeket nem gyarthatod tovabb. Mi marad nelkuluk? dGPU? Abbol meddig lehetne vegetalni? Mi ertelme lenne egyaltalan a dGPU-kkal veszodni, amikor a piac pont az ellenkezo iranyba megy?
"Szerintem ha valaki megveszi az AMD-t és leányvállalatként üzemelteti, akkor az simán gyártathatja tovább az x86 procikat."
Legfeljebb akkor, ha az Intellel meg tud egyezni az x86 licenc kerdeseben. Az Intel viszont hulye lenne beengedni egy uj x86 gyartot a piacra, van eleg bajuk most az ARM-os oriasokkal (Samsung, Qualcomm, Apple foleg).
"Ha ARM vonalon elterjed a HSA (márpedig az ARM és több más ARM procikban érdekelt cég ezen van), akkor előbb-utóbb az Nvidiának is alkalmazkodnia kell ehhez"
Majd nyom egy copy-paste-et a HSA-ra, es kesz. Ha egyaltalan szukseg lesz ra. A Mantle bejelentesekor is kialtottak sokan, hogy "Most mi lesz az nVIDIA-val?" -- "Mit fognak tudni csinalni? Veguk van!". Aztan jott a Mantle-re is a copy-paste (Direct3D 12), azt majd implementalja az nVIDIA es kesz, megy tovabb minden. Amig nem vedesz le egy technologiat, addig ez a sorsod. Lehet jofejkedni, csak a piac nem jofejsegbol el.
"Lehet, hogy az Nvidia 3x nagyobb, de ugyebár 3x0=0, márpedig az Nvidia értéke nem 0, tehát az AMD értéke sem 0."
Hadd ne menjunk bele a konyvelesbe es egyeb finomsagokba. Nyilvanvaloan amig egy cegnek van arbevetele, es kozel nyereseges vagy nyereseges a mukodese, amig van keszpenz tartaleka, amig 1-2 evre elore stabil uzleti terve van, addig nem 0 a piaci kapitalizacioja. De az azert eleg beszedes, hogy mennyivel tobbet ernek a kozvetlen konkurensek, mint az AMD, me'g akkor is, ha joval szegenyesebb termek kinalatuk van. Az AMD gyart egy csomo erdekes es izgalmas termeket, csomo helyen ott vannak, megsem tartja oket nagyra a piac.
-
Fiery
veterán
"Bizonyára így fest a világ kék szemüvegen át nézve (avatarod).
"Aranyos vagy, jo poen volt, csak pont nem kek cegrol beszeltem, hanem 2 zoldrol meg az Asusrol. Asszem Te me'g mindig nem erted, hogy ha valaki kritizal egy adott ceget vagy termeket, az nem jelenti automatikusan azt, hogy a konkurens cegbe bele van b*zulva. Az Intel legalabb annyi balf*szsagot csinalt es csinal, mint az AMD, csak masmilyeneket. Ugyanugy az nVIDIA is, az Asus is, meg minden mas ceg. Szerintem sokkal konstruktivabb az, ha az ember kritizal, ha felhivja a figyelmet a problemakra, potencialis problemakra, mint ha rajongassal atitatva fenyesre nyalja a kedvenc cege hatsojat. De ha ez kell, tudnek mondani olyan cegeket es olyan termekeket, amiket nagyra becsulok, amikert rajongok. Keves ilyen van, es tortenetesen egyik sem kapcsolodik az informatikahoz, kulonosen nem a hardveriparhoz. A PC meg a CPU/APU nekem csak munkaeszkoz, nem fetisizalom, hanem (ki)hasznalom oket. Nalam pont olyan szinten van a PC, mint a porszivo: a porszivomat se imadom, nem rajongom korbe, csak hasznalom arra, amire valo. En igy allok a dolgokhoz, es nem zavar, ha mas meg imadja a PC-jet vagy a mobiltelefonjat vagy az autojat vagy akarmi mast. Kerlek, hogy ne vetitsd ki a sajat erzeseidet, a sajat frusztracioidat masra. Szeretheted az AMD-t, rajonghatsz erte, utalhatod az Intelt, de ez nem jelenti azt, hogy ha az AMD-t kritizalom, akkor automatikusan beallithatsz Intel-berencnek. Lesz*rom az AMD-t es az Intelt is, egyiket se imadom es mindkettot utalom, sok szempontbol. Errol ennyit, nem kell erre a postra reagalnod, nem varom el.
A piaci kapitalizacionak meg nezz utana, erdemes. A piac bearazza a dolgokat, ez egy orok igazsag. Masik orok igazsag: minden annyit er, amennyit kifizetnek erte.
-
Fiery
veterán
"Az Intel az egyike a legbarátságtalanabb és legkevésbé kooperatív cégeknek."
Ezt csak azert mondod, mert nem volt me'g fejlesztokent dolgod az nVIDIA-val es az Asusszal
Az Intel sokkal baratsagosabb, sokkal nyiltabb ceg, mint az nVIDIA vagy az Asus. Az AMD me'g nyiltabb, csak ez nem feltetlenul valik elonyukre..."No offense, de ez enyhén szólva túlzás. Vegyük pl. a GPU-it, a GCN-t, a HSA mögé is sok nagy (és kis) cég állt be, pedig nem ingyen volt a belépő, a Puma magos termékek sem olyan rosszak. A konzol-biznisszből sem kevés fog befolyni az elkövetkező 7-10 évben."
En a ceget araztam be (sot, azt a piac arazta be, en csak leirtam a tenyeket), nem az innovacioit. Az innovacio szep dolog, de ha kiteregeted a kartyaidat, ha barkinek adsz beloluk, akkor onnantol mar nem a sajat ceged erteket novelik a fejleszteseid
Az emlitett termekeket sorra vegigvehetjuk, ha gondolod. A GPU es a GCN manapsag mar teljesen ugyanaz az AMD-nel, azok teljesen jo cuccok, csak epp a mernokoket (akik terveztek oket) barmikor at lehet csabitani egy masik ceghez. Plusz, magaban a GPU-architekturakban nincs igazan IP ertek, hiszen -- ahogy Abu is szajkozza -- a GPU-architekturakat 6-7 evente ugyis ujratervezik, a regi megy a kukaba. Ez nem az x86, aminek hosszutavon is van erteke, hosszutavon is magahoz tudja lancolni a piacot. A HSA-bol az AMD-nek -- ha nem tevedek -- semmilyen kozvetlen bevetele nincs. Maga a HSA amugy sem egy raketa tudomany. Ahogy mar szamtalanszor hangsulyoztam, barmikor, kovetkezmenyek nelkul le lehet koppintani, csak a "HSA" es "HQ" szavakra kell egy Replace All-t nyomni a promo anyagban. Jo otlet a HSA, de nincs levedve, nincs korulbastyazva ugy, mint mondjuk az x86. A Puma magos termekek meg ha nem tevedek, hasonlo teljesitmeny/fogyasztas mutatoval rendelkeznek, mint az ARM konkurensek, csak mas jellegu szoftvert futtatnak (x86). Egy olyan vilagban, ahol mar az x86-nak nincs olyan oriasi jelentosege, mint 10 eve, ha valaki procit akar gyartani, megy az ARM-hoz, vesz egy licencet, atmegy egy bergyartohoz legyartani a cuccot, es kesz. Nem kell a Puma mint innovacio, mint licencelheto architektura senkinek. Raadasul, a Puma x86 alapu, tehat ha viszed az AMD-t, a Pumat nem kapod meg. A Bulldozert se, de azert nem kar, ugyebar
A konzolbiznisz meg teljesen irrelevans, abbol kozel sem keres olyan sokat az AMD. Csak nekunk mint egyszeru foldi halandoknak tunik soknak az evi 1-2 milliard USD _arbevetel_, de valojaban nem olyan rengeteg az, ha melleteszed akarcsak az AMD 10 evvel ezelotti arbevetelet. Na meg ugye a konzolokban is x86 APU dolgozik, tehat az se er semmit, ha viszed az AMD-t.A piac bearazza a cegeket, az AMD-t is. Erdemes megnezni, hanyszor nagyobb egy Samsung, Intel, Apple, nVIDIA, Broadcom, Qualcomm, mint az AMD. A felsoroltak kozul a legkisebbet emelnem ki: az nVIDIA tobb mint haromszor nagyobb, mint az AMD, legalabbis a piaci kapitalizaciojat tekintve. Pedig me'g x86 licencuk sincs, tulajdonkeppen APU-juk sincs, es a HSA-t is lesz**jak
De nem adjak oda a fejleszteseiket a fel vilagnak, nem teregetik ki a lapjaikat. -
atti_2010
nagyúr
Szerintem a konzolokból az elkövetkező 4-5 év biztosított hiszen nem akármiből akarnak Indiai leányvállalatot építeni és az alatt az idő alatt sok minden változhat a piacon, az APU -s tervük is bejöhet na nem úgy hogy majd lekörözik az Intelt de olyan szinten hogy profitot hozzon, szóval nem kell temetni ha eddig nem haltak meg, az hogy a CPU rész haldoklik nem akkora érvágás hiszen már régóta csak vitte a pénzt.
-
dezz
nagyúr
Bocsánat, 4.5 GHz-en már nagyon is többet fogyaszt. [link] De állítólag a 4 GHz-t viszi alapfeszen is. Viszont elnézve ezeket a A10 PRO-7x50B-s fogysztási értékeket, végülis el tudom képzelni, hogy a 65W fölötti rész már az, amikor már egyre jelentősebb fogyasztásnövekedést okoz az órajel egyre kisebb növelése.
-
Fiery
veterán
A GloFo tudtommal a Samsunggal allt ossze, hogy kozosen fejlesszek ki a 14 nanos node-ot. Kerdes, hogy addig mi lesz, es mikorra keszul az el. De akarhogy is lesz, en kizartnak tartom, hogy 20 nano alatti node-on keszuljon a Carrizo. Jo lenne, ha ugy lenne, de nem hiszem, hogy megtortenik
-
#14244
Vitamincsiga
tag
dezz
#14240
Vitamincsiga
tag
"(Amúgy még az sem teljesen kizárt, hogy meg is csinálták, kísérleti példányok formájában, és a tesztek során arra jutottak, hogy a 2 modul + 512 SP (8 CU) felállás a legszerencsésebb.)"
Ha hozzászámítjuk a DDR3-2400-ból fakadó 38,4 GB/s-os maximális memóriaelérést, akkor elképzelhető, hogy a 2 modul + 8 CU nem csak az arányra, de a mértékre is optimális.
Ebben az esetben a DDR4-3200 - bár csak itt tartanánk már
- memória használatánál a 4 modul + 16 CU bevállalható lenne. Természetesen 20 nm-es gyártástechnológia mellett.(#14234) Fiery:
"Az ido azonban eroteljesen az AMD ellen dolgozik, ugyanis jelen allas szerint az Intelnek sokkal tobb lehetosege van az iGPU teljesitmenyenek fokozasara, mint az AMD-nek."
Az AMD örök baja a gyártás
Van jó cuccuk, de senki sem akarja belerakni notiba, táblába... A konzol piac megszerzése még ma is az az érzetet kelti, hogy biztos így történt, Nem elírás?
Zsé', pedig az eladásokból van. Abból meg a fejlesztés, ahol az Intel nagyságrenddel nagyobb lehetőségekkel bír.Hogy a GCN-ből továbblépni tényleg nehezebb - mert nagyon is jó - mint az Intel IGP-jéből az tény. De az is, hogy egy GCN-t összerakni sem egy-két év; melózik az Intel rendesen, hogy behozza a lemaradást.
(#14241) leviske:
Az igazi durranásra szerintem várnunk kell még.
Mindannyiótoknak igaza van, hogy az AMD a HSA-ja felkészületlenül érte a programozókat. A Win9 megjelenése utáni 2 év lesz, mire a HSA szignifikánsan lesz jelen a mindennapokban.
Addigra az Intel addigra gatyába rázza a MIC-et, az ARM-osok pedig élvezni fogják MS-t. És csak a teljesítmény - ahogy öregapám mondogatta: "a lóerő per dioptria" - számít egyedül.Az AMD a legérdekesebb mindezek közül!!
A GCN2(?) mellé mind az ARM - mobilteló, tábla, SeaMicro-, mind az x86 - noti, asztali, HPC, régimódi szerver - integrálásra kerül. /A tokozás más tészta, de majd kiderül!/
Zseniális!
Egy lépésben, 2 architektúrával lefedik az egész TDP tartományt
A GCN ezt eddig is tudta - ABU erről írt többször is - most pedig a "megoldhatatlan CPU részét" is megoldották.
2015-re már "kész" minden - Carizzo, Beema, Mulins - cucc, a fenti fejlesztés a 2016-2017(?) tartományt fedheti le.Ezek után még inkább úgy gondolom, hogy a GCN2(?) valószínűleg az utolsó IGP lesz. A CU-k integrálódni fognak a főnixként feltámadó modulba. Extra hatékony!
Hogy miért nem most?
Se gyártástechnológia, és valószínűleg se működőképes prototípus. Ráadásul most már nemcsak x86-ról szól a modul, hanem az ARM-ról is. Úgy pedig nem akarnak járni még egyszer, ahogy a Liano és a Bulldozer bevezetésekor volt
Ezek az évek egy kicsit hasonlítanak a (h)öskorszakra
286 386 486...
Megint sokszereplős a piac, megint nem tudjuk ki, mivel fog előrukkolni, de a teljesítményvágy, az örök -
lee56
őstag
Párszor azért ők maguk voltak a chipgyártók is, vagy a TSMC, és nem mindíg ez volt a gond..
Pl. gondolok itt a HD2000es GPU széria alapjára; az R600 is hasonlóan nehéz utat járt be, ha jól emlékezek.(#14237) atti_2010 : Nem, a hiba az amit Fiery is írt, hogy mire beérne a jövőbemutató fejlesztés, addigra behozzák sőt, le is előzik a versenytársak általában.
Amúgy nekem is tetszik amit csinálnak, csak míg pl az Intelnek simán belefér néhány üzletileg katasztrófa döntés is, náluk már inkább meg kéne gondolni mire költenek és fejlesztenek.(#14238) stratova : Na igen, az a baj ezzel az egésszel, hogy szoftveresen már tegnapra kellett volna... De csak tegyük fel, hogy a programok 50%-a képes lesz ez év végére kiaknázni az iGPU-k általános számítási teljesítményét (azt hiszem ez is még túl optimista becslés volt), azzal hogy valaki most egy AMD APU-t vesz, még mindíg jókora kompromisszumra kényszerül (X86 teljesítményt áldoz be ugye a jóformán kihasználatlan iGPU-jával, ami a chip több mint felét alkotja, és akinek dGPU-ja van, annál a chip azon része így csak pihen jelenleg, de persze ki kell fizetni azt is a kasszánál). És amég nem lesz jobban elterjedve, és szoftverileg sem készülnek fel jobban.. Na szóval látni a fényt az alagút végén, de baromi halvány még mindíg, az én szememben legalábbis.
A két uj konzol azért valamennyire enyhítheti az AMD kínjait, de azért ez sem fog örökké tartani.. Remélem azért hamarosan kitalálnak valami megvalósítható, eladható, és főleg versenyképes innovációt, mert azért tudnak ők ilyet is.
-
#14232
Vitamincsiga
tag
dezz
#14212
Vitamincsiga
tag
Ez igen! [link] Köszi a cikk nevet
Végleg kezd kilépni a benchmark világ a PC bűvköréből - a Sandra eddig is mért minden paramétert, de úgy látszik nem csak CPU -> APU váltást hajtotta végre, hanem kinézett az x86 világból is.
Sandráék tesztjéből az már kiviláglik, hogy nagyságrendbeli különbség nincs az ARM és az Intel között CPU teljesítményben, viszont fogyasztás és a GPU teljesítmény terén már más más a helyzet. De vajon hogy szerepelne az AMD Puma+ architektúrája a tesztekben? Kihegyezve a HSA-ra!A Kaverire és a HSA tesztre visszatérve egy leheletnyit.
Ahogy elkezdenek majd terjedni a CPU és az IGP közös memóriatartományát kihasználó prg-ok, lehet, hogy nem az AMD lesz az, aki gyászosan lemarad a tesztekben? -
Fiery
veterán
"A WinZIP-re gondolsz? Nos, az eléggé jelentéktelen alkalmazás"
A JPEG dekoder is, ennyi erovel
Barmire ramondhatod, hogy jelentektelen, de pont ezert is irtam fentebb azt, hogy 50-100 HSA-s alkalmazasig nem is igazan van ertelme odafigyelni a benchmark eredmenyekre."De amúgy Abu azt mondta róla, hogy nem az AMD kérésére késleltették az Nvidia/Intel supportot (nem sokat számított a dolog, mint írtam, nem egy létfontosságú alkalmazás, vannak jobbak a feladatra), hanem egyszerűen nem ment velük rendesen. Szóval, ezt nem kell túldramatizálni/túldimenzionálni"
Vagy ugy volt, vagy nem. En nem hiszem el egyik es masik variaciot sem. Mindketto lehetseges ugyanis. Az OpenCL compilerek tenyleg annyira sz*rok, hogy siman lehet, hogy elso korben a WinZIP nem mukodott rendesen egyik gyarto OpenCL megoldasaval sem. Az is elkepzelheto, hogy az AMD onszorgalombol segitett a WinZIP-et osszekalapalni. Az is elkepzelheto, hogy a masik 2 gyarto sz*rt az egeszre. De az is ugyanolyan realis forgatokonyv, hogy az AMD kereste meg a WinZIP fejlesztojet (Corel), hogy noszogassa oket, hogy csinaljak meg OpenCL-re a tomoritot, hogy vegre legyen valami hangzatos nevu Windows utility, amit OpenCL-re is portolnak es/vagy eleve meg is csinaltak nekik a portolast. Hazon belul a gyartok sokkal konnyebben meg tudjak ezeket oldani, hiszen ha az OpenCL kernel fejlesztese ill. tesztelese kozben valami compiler bug elojon, csak atszol a kolleganak, hogy fekudjon ra a temara gyorsan. Egyszeru kis porbaf*ngo szoftver fejlesztokent meg egy-egy ilyen bugnal heteking, honapokig tart, mire az AMD/Intel/nVIDIA kijavitja a compilert, es tudod folytatni a fejlesztest. Ez a nagy baj, ezert ketelkedek en az egesz HSA-s, OpenCL-es buliban. Az egesznek az alapja egy kvazi hibatlan, jol hasznalhato compiler kellene hogy legyen. Onnantol lehet rendesen dolgozni fejlesztokent. Ezert olyan sikeres a Visual C++, gcc es tarsaik: regi, kiforrott, stabil compilerek, amiknel nem kell egyfolytaban a compiler fejlesztojehez szaladgalni, mert megint elojott egy bug. Nyilvan ha par honap mulva hirtelen kijon pl. az OpenCL 2.0 --> HSAIL compiler, megtamogatva a Kaverihez a megfelelo finalizerrel es kornyezettel, es az elsore hibatlanul fog mindent forgatni, es a media tele lesz a halalkozo szoftver fejlesztok success story-jaival, akkor azt fogom mondani, hogy na ez igen, ezt nem vartam, de fantasztikus, sracok, jol dolgoztatok. Viszont, ha azt nezzuk, hogy lenyegeben ugyanez a melo allt eddig is az AMD, Intel es nVIDIA elott (azaz hogy OpenCL-rol a sajat belso IL-jukre forditsanak), es 6 ev alatt egyik gyarto sem tudott rendes compilert fejleszteni, akkor nem tartom valoszinunenk, hogy meg kellene kovetnem a HSAIL compiler fejlesztoket me'g az iden -- vagy akár jovore.
"Voltak már korábban is más jellegű OpenCL-lel gyorsított programok, amik hasonló speedupot értek el, nincs ebben semmi igazán különleges. Hozzáteszem: ezek valós alkalmazások voltak, Abuék mégsem használták a tesztekben."
Konkret peldakat kerek ilyen alkalmazasokra. Mindharom platformon, korrektul mukodjon. WinZIP egynek jo.
"Ha lesznek egyes PS4/XB1 játékoknak Kaverire külön ráoptimalizált portjai, azok szerintem nem apró látványeffektekben lesznek különbek, hanem inkább arra számítok, hogy pl. a fizikai szimuláció számítását bízzák az IGP-re, miközben a többit dGPU számolja, így egy Kaveri+dGPU konfigon is ugyanúgy vagy akár jobban futhat, mint egy drága i7 alapú konfigon, ez lehet az előnye"
Ez nagyon keves elonynek, sajnos
Plusz, a fizikaval mar probalkoztak nehanyan, pl. PhysX annak idejen, es nem igazan latom azt, hogy valaki a fizikai szimulacio miatt valasztana egy adott hardvert. Mikor hallottal utoljara olyan juzerrol, hogy vasarolt volna a gepebe plusz egy GeForce videokartyat, hogy a fizikai szamitasokat arra bizza? De egyebkent nem csodalkozok, ha a fizika felol probalkozik az AMD, ugyanis az AMD HSA fejlesztoi csapataban tobb volt Ageia-s (es igy volt nVIDIA-s) is van, tobbek kozt az egyik Ageia alapito is."Most írtad, hogy szerinted a MIC megöli a GPU-kat. Ennél nagyobb monopolhelyzet mi lenne?"
Arra gondoltam, hogy ugy oli meg a GPU-kat, hogy egy uj kategoriakent lep be a piacra. Socketelt GPU-szeru megoldas, ami operacios rendszert is futtat, es gond nelkul lehet masszivan multi-threadelt hagyomanyos x86 szoftverek futtatasara is hasznalni. Vagy egy olyan CPU, ami a GPU feladatokat is ellatja, attol fugg, honnan nezzuk. Ilyet adott esetben az nVIDIA vagy az AMD is keszithet. En ezt az uj CPU/GPU/akarmit nem hivnam mar GPU-nak, es siman lehet, hogy az Intel is kitalal majd ra valami uj betuszot a KNL bemutatasaig. Az viszont alapveto kerdes, hogy ha valaki hasonlo megoldast keszit (en az nVIDIA-t varnam elso korben, hogy meglepi), akkor milyen ISA-t valaszt hozza. Ez szabadon eldontheto, csak ugye compilert kell erre is fejleszteni, ha nem x86-ot/MIC-et valaszt az adott gyarto. Az is kerdes, hogy a MIC-hez van-e hozzaferese az AMD-nek, de elvileg kell hogy legyen, a keresztlicenc megallapodas alapjan.
-
Fiery
veterán
"Nem is értem, Abuék miért nem csinálnak ilyen teszteket...? Nem csak HSA, hanem mindenféle OpenCL is"
Majd Abu is leirja az okokat, de szerintem az a legfobb problema, hogy nincsenek igazan OpenCL-t mindharom platformon korrektul kihasznalo real-world applikaciok. A benchmarkokat, foleg a szintetikus benchmarkokat pedig a PH-sok nem szivesen hasznaljak a tesztekhez.
-
Fiery
veterán
A szponzoracioval vagy azzal, hogy mas helyett az AMD szakemberei portolnak egy adott algoritmust HSA-ra alapvetoen nincs baj. A baj azzal van, ha ennek az eredmenyere valaki azt gondolja, hogy a HSA szeleskoru elterjedesevel mindenki ugyanezt fogja tudni produkalni. Ha ugyanis ugyanilyen hatszelet kapott volna minden szoftver az AMD-tol, Inteltol es nVIDIA-tol is egyarant, akkor mar nem itt tartanank az OpenCL 1.x elterjedeseben sem. Amikor X ceg azt mondja, hogy az o szoftveret csak AMD (vagy csak Intel, vagy csak nVIDIA) GPU-n tudja atvinni CPU-rol OpenCL-re, az mar kapasbol: 1. gyanus, 2. szomoru. Azert gyanus, mert nem tudni, valojaban mi van a dolog mogott: a GPU-gyarto ceg fizetett a szoftver portolasaert a fejlesztonek, vagy eleve ok maguk csinaltak meg a munkat. Gyanus az is, hogy direkt kotottek ki, hogy mas platformra nem portolhatjak ezek utan a szoftvert. Szromoru pedig azert, mert ez nem segiti az iparag fejlodeset. Es ne erts felre, barmelyik ceg csinalja ezt, az szamomra ugyanugy gyanus es szomoru. Mert az elvi lehetoseg meg van egy GPGPU-ra elvben portolhato algoritmus eseteben arra, hogy mindharom GPU-gyarto OpenCL implementaciojara portolni lehessen. Ha egy fuggetlen szoftver fejleszto belefut egy compiler bugba vagy anomaliaba, es az egyik, masik vagy mindharom gyarto nem tamogatja azzal, hogy belathato idon belul javitja az OpenCL compilert, akkor megall a munka. Ez a rögvalosag, amit azonban eltorzit az, ha a 3-bol az egyik gyarto egy adott szoftver fejlesztojet aktivan tamogatja. De ez az egesz szitu megoldodik majd, ha lesznek normalis compilerek, es ha a HSA tenyleg szeleskorben elterjed. Ha mar 50-100 szoftver tamogatja, onnantol mar a nagy atlag meg fogja mutatni az egesz dolog valodi hozadekat. Addig meg en szemely szerint ketkedessel fogadok minden benchmark eredmenyt.
A Sandrarol nem tudok erdemben nyilatkozni, ugyanis annak a fejlesztoje -- az en meglatasom szerint -- egy zseni es/vagy baromi jo iparagi kontaktjai vannak (minden oldalrol, nem csak AMD), akik segitenek neki sok mindenben. Nehez megmondani, hogy milyen jellegu segitseget kap, es ha kap, milyen melysegben. Ennel tobbet nem mondhatok errol, van tobb infom is, de azok nem publikusak. A Sandra altal elert teljesitmenyrol plane nem tudok nyilatkozni, azt mindenki dontse el maga, hogy atlag PC felhasznalokent mennyire erzi hitelesnek es relevansnak az opcios kereskedesi benchmarkokat.
Minket nem szponzoral senki, sajnos
MIC: az a baj, hogy nem vilagos egyelore, hogy a MIC valojaban milyen hosszu vagy rovid tavon lesz az Intel GPU-helyettesitoje. Ha mar ismernenk a Skylake iGPU-janak pontos felepiteset, talan konnyebb dolgunk lenne. En nem vagyok meggyozodve arrol, hogy a MIC lesz hosszutavon a megoldas, inkabb egyfajta koztes lepcsonek gondolnam. Abban igaza van Abunak, hogy AVX-512-ben nativan kodolni nem konnyu, viszont az sem vilagos, hogy az Intel mikepp probalja a HSA-t lemasolni vagy valami hasonlot kinalni a fejlesztoknek, hogy megkonnyitse az eletuket. 2-3 ev mulva mar latni fogjuk szerintem az iranyt, es sokat fog az is segiteni, ha latjuk mar, hogy az nVIDIA merre lep tovabb.
A jatekokkal azert nem kivanok foglalkozni, mert egyreszt nem erdekelnek engem szemely szerint; masreszt meg mert nem tul valoszinu, hogy egyik jatekfejleszto is meglépné azt, hogy kifejezetten a Kaverira/Carrizora optimalizaljon egy jatekot oly modon, hogy azonos render eredmennyel jarjon Intel es nVIDIA GPU-n, valamint AMD dGPU-n is. Tudom, ez igy kicsit kusza
Szoval arra gondolok, hogy az siman elofordulhat, hogy egy portolt jatek full detailben Kaverin fog szepen szaladni, es lemaradnak a konkurens megoldasok, beleertve az AMD dGPU-kat is. Az viszont kizart, hogy ne legyen a jatekokban 1-2 alacsonyabb reszletessegu, kifejezetten nem-Kaveri beallitasi lehetoseg. Vegeredmenyben pedig a Kaverit nem ugy fogja tudni promotalni az AMD, hogy gyorsabb, mint mondjuk egy Broadwell vagy egy GeForce dGPU, hanem ugy, hogy maskepp nez ki a jatek Kaverin, szebb effekteket fog tudni portolni a konzolrol PC-re a Kaveri segitsegevel. Ez viszont -- bar en nem vagyok jatekos -- SZVSZ keves lesz ahhoz, hogy valaki Kaverit valasszon mondjuk egy Broadwell+GeForce vagy Broadwell+Radeon dGPU kombo helyett. Anno voltak mar hasonlo proprietary GPU effektes probalkozasok, es azok sem jottek be, sajnos. Nem vesz senki egy adott hardvert csak azert, mert 1-2 jatekban szebben fodrozodik a viz, mikozben az osszes tobbi jatekban alacsonyabb FPS-t ad, mint egy masik vas. -
#14207
Vitamincsiga
tag
dezz
#14205
Vitamincsiga
tag
"BTW, különösen érdekes a Sandra GP FinalcialAnalysis nevű tesztje!"
Ez nekem is szemet szúrt azonnal!
De van még más APU teszt is a tarsolyukban: [link]
Amire kíváncsi vagyok - és gondolom még jó néhányan - hogy a Kaveri GPU-jával megegyező dGPU mekkora teljesítményre lenne képes! Természetesen a legerősebb Intel processzorok társaságában... -
#14198
Vitamincsiga
tag
dezz
#14048
Vitamincsiga
tag
A legutóbb nem tudtam olyan tesztet találni, ami a Kaveri igazi erejét bemutatná, most pótlom: [link]
A HSA-val készítettek a cikk második felében találhatóak; nagyon meggyőzőek
HSA-val kihasználva az erejét 2,5-5x-ös a gyorsulás, az i5-tel szemben így 1,5-2,5x-te jobb teljesítményre képes!Jó lett volna egy 6 magos i7-et látni a tesztben
A fenti teszt tükrében, már értem miért készül az Intel 8 magos i7-tel a csúcsproci cím megtartására - lehet, hogy a HSA-val készült programoknál az Excavatornak így is lesz esélye lenyomni őket a trónról?No! Mégis csak van kakaó a Bull legújabb reinkarnációjában
-
Fiery
veterán
GPU-kba nehezen tudjak berakni, tulzottan megbonyolitana a chipet. Max. valami olyasmi lenne elkepzelheto, hogy mondjuk CU-nkent 1 ilyen egyseg, de azzal meg nem lehetne eleg nagyot elorelepni a teljesitmenyben.
Ahhoz, hogy a GPU-k tudjak tartani a(z x86) CPU-kkal szembeni kedvezo parametereiket (flop/watt), szuksegszeruen (relative) egyszerunek kell maradniuk. Ha tul sok kacatot bepakolsz, akkor hasonloan bonyolultak lesznek egy ido utan, mint most az x86 CPU-k, es az a hatekonysag rovasara fog menni.
-
Fiery
veterán
"A Samsung azért eléggé az élvonalban van chipgyártásban"
Csak epp ahhoz, hogy az Intel nyomulasat meg tudja allitani, nem eleg, hogy azonos, hanem jobb gyartastechnologian kellene gyartaniuk, mint az Intel. Jelenleg pedig epp forditva van a helyzet, sajnos.
"Az AES pont rossz példa, hiszen céláramkör végzi el a feladatot, amit GPU-kba is simán beépíthetnek."
Megsem teszik meg, mint ahogy az SHA gyorsitas is csak a CPU-kba (ARMv8 + Skylake) fog bekerulni hamarosan, a GPU-kba nem. A GPU-kban meg FMA celaramkor van ennyi erovel. Minden platformnak meg vannak a maga erossegei es gyengei. Csupan arra akartam ravilagitani, hogy nem feltetlenul kell baromi sok szal ahhoz, hogy egy adott feladatot gyorsan vegre lehessen hajtani. Lehetne egyebkent egy csomo specifikus kodot talalni, ami x86 CPU-n jobban fut mint mondjuk egy Bonaire-en vagy GK106-on (pl. dupla pontossagu lebegopontos szamitasok), de vegul is nem cel ez, csupan szemleltetni akartam egy -- felig-meddig jo -- peldaval.
Az igazi teszt az lenne, ha mondjuk jonne egy uj trend, egy uj divat, es arra kellene celaramkort pakolni a CPU-kba es GPU-kba is. Ott lenne igazan erdekes a verseny. Pl. a reszleges ray-tracinget felkapna a jatekipar
-
Fiery
veterán
"A többmagúsítás sem nyerte el mindenki tetszését, de hát ugye eszi, nem eszi, nem kap mást"
Nem vagyok benne biztos, hogy a "többmagúsítás" alatt az x86 CPU magok sokszorozasat erted-e, pl. 16 magos Interlagos es tarsai. Ha igen, akkor az azert eleg egyertelmu, hogy jelenleg sokkal tobb szoftver kepes a sok CPU-mag kihasznalasara (me'g ha nem is mindig az osszes mag egyszerre, azaz nem 100%-os CPU-terhelessel), mint amennyi szoftver kepes mondjuk az OpenCL vagy CUDA segitsegevel a hagyomanyos x86 CPU-ra rott feladatot gyorsabban vegrehajtani a GPU segitsegevel. Nyilvan ez a helyzet barmikor megvaltozhat, ha berobban a HSA, de jelen allas szerint a sokmagos x86 CPU-k me'g egesz jol mukodnek, es sok szoftver ki is hasznalja oket. Az persze teny, hogy az AVX, AVX2, XOP es FMA nem terjed tul gyorsan. Azokkal egyutt tudnanak igazan szepen muzsikalni a modern x86 CPU-k.
"Az, hogy mostanra beérték (ha valóban így van, nem tudom) az ARM-ot alacsony fogyasztásban"
Erdemes utananezned
"nem jelenti azt, hogy le is hagyják, hiszen a fizika itt is közbeszól."
Az alapjan, hogy az ARM-os cegek es az Intel is folyamatosan fejleszti a gyartastechnologiajat, hozzaveve azt, hogy az Intelnel vegre az Atom vonal kerult fokuszba, plusz hogy az elmult evekben mekkorat lepett elore az Intel, plusz hogy az Intel masfel-ket ev gyartastechnologiai elonyben van a tobbi gyartoval szemben szamomra egyertelmuen azt sugallja, hogy a kozeljovoben le fogjak hagyni az ARM-ot. Ha nem igy fog tortenni, az csak ugy kepzelheto el, ha az egyik ARM-gyarto (pl. Apple vagy Samsung) behuz egy olyan gyartastechnologiat, amivel atugorja az Intelt. Ahhoz viszont olyan brutalis toke befektetes kellene, amit nem fog egyik gyarto sem felvallalni _szerintem_. (masik elvi lehetoseg, hogy az Intel elbaltazza mondjuk a 10 nanot vagy a 7 nanot... nem tartom valoszinubbnek, mint hogy egy barmelyik ARM gyarto ugyanugy elszurja)
"HA kevés szál is gyors tud lenni... Ez majd elválik"
Mar most is lehet keves szallal, x86 CPU-val is gyorsabban futtatni bizonyos feladatokat, mint sok szalas dGPU-val. Pl. AES enkriptalasban az AES-NI kepes processzorok siman lenyomjak a kozepkategorias GCN dGPU-kat is. AES-256 eredmenyek, OpenCL a GPU-n, nativ AES-NI kod a CPU-n:
Bonaire: 19968 MB/sec
Core i7-4930K: 21094 MB/secPersze ez egy szelsoseges pelda, tudom
-
Abu85
HÁZIGAZDA
Félreértettük egymást. Igen igaz amit írsz. A GPU az valahol csak GPU. Sok szálra optimalizált, szörnyen sok regiszterrel, stb. Az x86(AVX)/ARMv8 ehhez képest valóban egy baromira regiszterszegény architektúra, kevés szálas működésre optimalizálva.
Egyelőre én még nem látom tisztán, hogy az Intel mit akar. A koncepcióikból kihozható egy olyan Skylake, amiben van négy nagyobb mag, amellett van kb. 12-16 MIC mag és még amellett van egy Gen9 IGP. Ez a lehetőségeket figyelembe véve egy reális opció.
(#14178) Fiery: A hatékony szálkezelés a hatékony skálázhatóság alapja.
-
Fiery
veterán
"Ez így azért eléggé leszűkített látómező."
Teny, de a fejlesztoket hidd el, hogy az erdekli elsosorban, hogy mikepp tudod megoldani a feladatot, es a hibakeresest, teljesitmeny optimalizaciot hogyan tudod vegezni. Az OpenCL pedig jelenleg nagyjabol pont ezen a 2 teruleten kalap sz*r. A HSA az igeri, hogy majd jobb lesz ezeken a teruleteken is, csak epp nem latni egyelore, hogy milyen konkret lepeseket fognak tenni. Egy C++-hoz es CPU-hoz (leginkabb x86 CPU-hoz) szokott fejleszto szamara az OpenCL jelenleg egy fekete lyuk, amibe belevagod a vegrehajtando feladatot, es aztan a vegen valami kijon. Hihetetlenul nincs sem ralatasod, sem rahatasod arra, hogy mikepp hajtja vegre a GPU az adott OpenCL kernelt, es hogy a vegeredmeny valojaban helyes-e vagy sem. Ha van otleted, hogy mitol lehetne gyorsabb a cucc, akkor elkezdesz probalgatni kulonfele technikakat (pl. unroll, inline, ilyesmi), amire aztan a kulonfele GPU architekturak a kulonfele compilerekkel teljesen maskepp reagalnak. Ami fekszik az egyiknek (pl. GCN), az a masikat lassitja (pl. Kepler). Az pedig kesz rohej, amikor kenytelen vagy tobbfele GPU architekturat tobbfele driver verzioval is tesztelni, mert az egyebkent helyes OpenCL kod hibas eredmenyt ad az egyik kombinacion (pl. AMD VLIW + Catalyst 14.x). Aminek az okara, gyokerere megint nincs se ralatasod, se rahatasod, kenytelen vagy az AMD-t molesztalni, hogy javitsak vegre a rohadt driveruket. Amit persze 5 honapon belul nem tudnak megoldani, es kidobjak WHQL minosites alatt a bugos OpenCL compilert. Ez a jovo? Tenyleg?
"Még jó, hogy ezt próbálják nyomni, ez a legfőbb ütőkártyájuk."
Nyilvan, de ha az AMD-nek meg ott a szuper GCN -- mert hardveres szempontbol tenyleg qrvajo --, akkor miert nem azt nyomjak, hanem minden egyebet, amiben nem eleg jok? x86, ARM, szoftver fejlesztes (= HSA es tarsaikhoz valo szoftver stack).
"Ez vicces, inkább talán az ARM szorongatja őket alulról (úgy is mondhatnám, a töküket)."
Nezz vissza az elso Atomig. Akkor hol allt az Intel az ARM konkurensekkel szemben, es hol all most. Eg es fold a kulonbseg. Az elso iPhone megjelenesekor me'g fel sem merulhetett, hogy Intel SoC keruljon egy mobiltelefonba. Az elso iPad megjelenesekor szinten szoba sem johetett volna egy Intel SoC az ARM helyett. Mostanra pedig mar lenyegeben azonos teljesitmenyt es fogyaszast tudsz elerni Intel es ARM SoC-okkal is. Ha ezt kicsit tovabbgondolod (vagyis hogy 7 ev alatt mennyit fejlodott ebben a szegmensben az Intel), akkor eleg egyertelmu, hogy ki kinek a tökét szorongatja kozeljovoben. Mar csak azert is, mert az ARM nem egy egyseges, vertikalisan integralt CPU-gyarto, hanem egy rendkivul toredezett "valami", sokfele architekturaval, sokfele ceggel, akik raadasul sok esetben egymas konkurensei vagy epp ellensegei. Az ARMv8 remekul probalja osszefogni, gatyaba razni, modernizalni az ARM vonalat, rendkivul erdekes lesz a kovetkezo 2-3 ev...
-
Fiery
veterán
"Egyébként hogy néz ki a HSA szoftver oldalról? Lesz valamilyen (saját) OpenCL alternatíva?"
Nem ertem, mit akarsz irni. A HSA nem egyenlo OpenCL-lel. Az OpenCL-nek meg miert kellene alternativat kesziteni? Teljesen jo cucc, amennyiben jo compilert ir hozza az adott gyarto. Az AMD compilere jelenleg f*s, az Intele meg hig f*s. Amig ez a helyzet nem valtozik, addig a fejlesztok nem fognak komolyabban foglalkozni a kerdessel. Ha pl. egy Visual C++ vagy gcc mellé teszel egy AMD vagy Intel OpenCL implementaciot, akkor jol latszik, hogy az egyik egy kiforrott kornyezet, kiforrott, lenyegeben hibatlan compilerrel, amihez sokfele jol bevalt, ismert tool is elerheto (debuggolas, profilozas). Ezzel szemben az OpenCL alapu fejleszteshez nincs rendes, egyseges fejleszto kornyezet, nem lehet rendesen debuggolni es profilozni, nem jol mukodnek a compilerek. Gyakorlatilag sz*pas az egesz. Nyilvan az SVM sokat konnyit azon, hogy az egesz GPU-s mizeriat konnyebben ki tudd hasznalni. Azzal legalabb az adatmasolgatast el tudod kerulni, kicsit konnyebben atlathatova tudod tenni a komplexebb feladatokat (foleg a lancolt listaknal jon jol az SVM). Viszont, a compiler ugyanugy problema marad, a debuggolas es profilozas ugyanugy megoldhatatlan a jelenlegi eszkozokkel. Es a legfobb problema: tovabbra is koprocesszorkent kezeled a GPU-t, holott annak mar reg a CPU reszenek kellene lennie. Engem mint fejlesztot szemely szerint nem erdekel se az ISA, se a threadek szama, se az egysegnyi tranzisztorra juto fogyasztas. Nekem egy olyan CPU kellene, amivel a mostani CPU-k es a GPU-k teljesitmenyet egy tokban tudnam latni, es a jol megszokott eszkokkel lehetne fejleszteni ra, a debuggolassal es a profilozassal egyetemben. Az Intel-fele KNL megkozelitesnel azt erzem, hogy az Intel is ebbe az iranyba szeretne menni, mig az AMD-nel azt erzem, hogy 3-4 kulonfele iranyba mennek, es egyik platformra, egyik megoldasra se tudnak letenni kiforrott, teljes erteku fejleszto eszkozt. Nincs tovabbra sem jo OpenCL compileruk, nincs mukodo HSA implementaciojuk -- de kozben nyomjak az x86-ot, nyomjak a GCN-t, nyomjak a konzolokat, nyomjak mar az ARM-ot is. Ertem en, hogy sok labon akarnak allni, meg ok sem latjak igazan, hogy melyik vonalbol lesz a jovo, de a jelen allas szerint mekkmester lesz beloluk. Mindenbe beleszagolnak, mindenre azt mondjak, hogy van kesz megoldasuk ra, csak kozben az sosem lesz igazan kesz, igazan jol hasznalhato. Felolem csinalhatnak azt is, hogy a GCN-bol keszitenek egy CPU-t -- ugyis szeretik hangoztatni, hogy a GCN tulajdonkeppen most mar egy teljes erteku processzor, ennyi erovel OS-t is be lehetne bootolni rajta. Nosza, akkor legyen az, csinaljanak egy ilyen megoldast, felejtsek el az x86-ot, ugysem az a fokusz mar naluk. Az Intelben azt dijazom, hogy legalabb kiallnak egy adott platform (x86) mellett, azt nyomjak, azt eroltetik, arra fokuszalnak. Lehet, hogy a vegen besz*pjak, es az ARM meg a HSA lesz a tuti megoldas, de legalabb nem 50 fele iranyban kapaloznak, es a vegen a delivery vagy kesik vagy meg sem tortenik normalisan.
-
Abu85
HÁZIGAZDA
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.
Persze van amiben eltér a GCN, de a dizájnja sokkal inkább hasonlít egy CPU-ra, mint egy hagyományos GPU-ra. Nagyon sok PS3 fejlesztő mondogatja az előadásán, hogy ami működött a Cellen az most működik GCN-en is, csak sokkal gyorsabban.Igaz a szálkommunikációt nagyon hatékonyan kell megoldani, de a fő előny a memóriamodellből jön. Amikor ISA-t cserélnek a cégek, akkor főleg ehhez nyúlnak hozzá.
Nem lesz. A HSA az OpenCL kiegészítése lehet és nem leváltója, ugyanígy egészíti ki a C++AMP-t is.
-
Fiery
veterán
A tobbszori ide-oda utaztatas sem problema, ha a compute feladatot annyival gyorsabban oldja meg a dGPU. Nyilvan osszessegeben me'g igy is jobb lehet egy APU, ha a fogyasztas/teljesitmeny mutatot nezzuk. Tobb masolgatas de gyorsabb szamitas vs. nincs masolgatas de lassabb szamitas vegeredmenyben kilyukadhat ugyanahhoz az osszteljesitmenyhez is, csak kozben egy high-end GPU zabalja az aramot.
Az Itaniumot nemtom miert kell iderangatni. Ott pont az x86-ot akarta felvaltani az Intel es nem jott ossze. A KNL pedig pont az x86-tal akarja felvaltani a nyomoronc GPU-kat. Terjunk vissza a GPU-s dolgokra mondjuk 6 ev mulva. Barmennyiben le mernem fogadni, hogy addigra a PC-kben mar nem lesz semmilyen GPU, vagy legalabbis marginalis feladatra fognak visszaszorulni. A CPU fog mindent intezni, legyen szo ARM vagy x86 utasitaskeszletrol.
-
#14152
Vitamincsiga
tag
dezz
#14126
Vitamincsiga
tag
Az APU CPU/IGP ALU/FPU/CU optimális arányát - legalább is azok a programok közül, amelyek képesek kihasználni ezt az architektúrát - tényleg csak a jövő fogja tudni megmondani...
Bár ahogy írod és én is eltöprengtem rajta, nem valószínű hogy lesz "optimális arány", még kiátlagolva sem. Főleg eleinte!
Inkább nagy szórás lesz az egyes gyártók termékei között az adott programra.Ami az Intelen hasítani fog, az az AMD-n vánszorog majd, vagy fordítva. Az ARM pedig sötét ló.
De majd meglátjuk! -
stratova
veterán
Igaz, már több mint másfél éve. Szintén 2012-ben láttak napvilágot AMD ARM-mal kapcsolatos tervei (és Jim Kellert éppen az Apple-től szerezték meg/vissza, ahol mit ad Isten éppen ilyen területen tevékenykedett).
Csak eddig Trinity/Richland/Kaveri volt a középpontban.
Bár Kaverit is kicsit ráncba szedhették. Azok után, hogy A10-7850K alacsonyabb órajelen üzemelt CPU és GPU (bár ez utóbbi azonos CU-szám mellett is hatékonyabb és 6 helyett már 8 CU) tekintetben, mint A10-6800K; most úgy tűnik érdemes volt finomítani a mobil verzión (vagy egyszerűen ebben az alacsonyabb órajeltartományban nagyobb a gyártástechnológia előnye?)
A10-5757M 35 W 2.5/3.5 GHz + HD 8650G 384:24:8 600/720 MHz max. DDR3-1866
FX-7600P 35 W 2.7/3.6 GHz + R7 512:32:16 600/686 MHz max. DDR3-2133
Ha ezt tényleg tudják tartani, már "csak" az OEM-ek kínálata lesz a fogós kérdés. -
Fiery
veterán
En ugy ertelmezem, hogy 2 kulon temarol van szo. A 4 GHz a Family 20h-ra vonatkozik, ami -- adott esetben -- egyszerre valthatja le a Pumat es a Bulldozert is. A Skybridge pedig egy atmeneti megoldas lesz a Family 20h erkezese _elotti_ idokre, azaz az elkovetkezo 2-3 evre.
-
-
#14077
Balala2007
tag
dezz
#14074
Balala2007
tag
Ez mit jelent?
A 3 kozul pontosan az egyik lesz, de meg nem tudom melyik
Remélhetőleg előbb-utóbb a GPGPU-zásba is belekezdenek a fejlesztőik
A Kribi3D definicio szerint csak CPU-val foglalkozik, a y-cruncher fejlesztoje konkretan kizarta dolgot, a tobbit nem tudom.
Hacsak nem az Intel szponzorálja őket a háttérben.
Ennek semmi koze az Intelhez. Vannak olyan problemaosztalyok, amikre a GPU alkalmatlan. Vegul is csak egy koprocesszor, nem varhato, hogy altalaban hatekony legyen mindenre.
-
Fiery
veterán
"Vagy simán foghatják pl. a korábbi OpenCL kódokat (legfeljebb átírva OpenCL 2.0-ára) és lefordíthatják a HSA keretrendszer (esetleg IDE) fordítójával?"
Mukodik a visszamenoleges kompatibilitas termeszetesen. A meglevo OpenCL 1.x kodot le tudod forditani a HSA keretrendszerrel is, legfeljebb nem fog koherens memoriat (SVM) hasznalni. Ha kicsit vagy jobban atirod a meglevo OpenCL 1.x kerneledet (meg ami azt korulveszi, mukodteti), akkor meg mehet OpenCL 2.0-ra SVM-mel.
"Amúgy van már HSA-s OpenCL 2.0 fordító?"
Az AMD-nek van, csak betas es lassu kodot fordit. Pontosabban ugy nez ki a helyzet, hogy azonos OpenCL 1.x forraskodot azonos vason lassabb kodra fordit le jelenleg az AMD HSA implementacioja. De ez a helyzet gyorsan javulni fog.
Persze lehetne extrem peldakat talalni, pl. ha van egy olyan OpenCL 1.x kerneled, ami nagyon szenved az SVM hianyatol, es a Kaveri hozza el neki a "megvaltast", akkor a mostani, betas OpenCL 2.0 compilerrel is el tudsz erni nagy gyorsulast. Lasd LibreOffice Calc
Ami nem feltetlenul egy ertelmes felhasznalasa a HSA-nak, de az AMD ennel jobbat egyelore nem tudott prezentalni. Majd a Corel osszekapja magat, es jonnek toluk a HSA-optimalizalt szoftverek szepen sorban (AfterShot Pro, WinZip). -
Abu85
HÁZIGAZDA
A HSA Runtime megjelenése után lényegében bármilyen nyelv jó. Leginkább a Java-t fogják ajánlani, mert az a legegyszerűbb, és direkten fordít a HSAIL-re is. Jelenleg mindenki saját maga gondoskodik a HSAIL beépítéséről a driverbe. Az univerzális Runtime még nincs kész.
Azt nehéz megmondani, hogy az autovektorizálás mennyire lesz fókusz a HSA Runtime esetében. Sokkal reálisabb a SIMT modellre gyúrni. Idővel úgyis áttérnek a HSA-s gyártók erre. Egyszerűen olyan algoritmus kell, ami több száz szálra is skálázódik. A többit elintézi a hardver. A kódot is elég egy szálra megírni.
-
#14066
Balala2007
tag
dezz
#14048
Balala2007
tag
Mikor is jön az AVX-512? 2015 elején, közepén, végén?
min(release_date(KNL),release_date(Skylake)) <>=? release_date(Carrizo_AVX2)
Mennyien veszik a fáradtságot AVX assembly programozásra manapság?
Mindenhol, ahol nem fejlesztesi, hanem futasidore optimalizalnak.Pl.:
- x264/ffmpeg/libav/VLC komplex (AVX2);
- Google VP9 (AVX2, VP8 meg csak SSE41-ig jutott);
- x265 (AVX2);
- GIMPS/Prime95 (27.7-tol, 2012 majustol van AVX);
- GMPLib 5.2 (Ez csak most fog kijonni, de felhasznalja a Mathematica es a Maple is);
- FFTW (3.3.3 ota AVX)
- y-cruncher (tudtommal ez mostani pi-comp csucstarto, 2011 ota van benne AVX);
- nyomokban feltunik mar a PovRay-ben is, az FMA4-gyel egyutt;
- A Kribi3D is hasznal AVX2-t mar tavaly szeptembertol. Mivel nem publikus a forrasa, biztosat nem lehet tudni, de a megjelenes sebessegebol es a futasido kritikussagat itelve ez is asm alapu lehet.
- minden mas projekt eselyes lehet, aminek van SSEn asm resze, es forditoja kepes AVX kodot gyartani.Eleg keves az SSE->AVX assembly valtashoz a tanulnivalo, par Intel pdf atnezesevel a lenyeg 90%-at meg lehet erteni. Ugy altalaban azt lehet varni, hogy ahol volt SSEn codepath, ott idovel lesz AVXn is.
-
Abu85
HÁZIGAZDA
Autóvektorizálással könnyen átrakható. Vagy akár a HSA-ra írt programok esetében még a kódot sem kell módosítani, mert a Runtime felel majd az AVX támogatásért. Úgy fordítja a fizikai kódot, ahogy az a procinak jó. Kezdetben SSE2-től AVX2-ig támogatja a hardvereket.
A kézi optimalizálás az már más tészta, de ott már a 256 bites vektorral sem akarnak foglalkozni a fejlesztők. Az 512 és 1024 bitet csípőből elvetik majd. Amire képes az autóvektorizáló az lesz a programból.
-
Fiery
veterán
"Mikor is jön az AVX-512? 2015 elején, közepén, végén?"
Attol fugg, hova, melyik platformra. De 2016 lesz az inkabb. Kiveve, ha az Intel meglep minket azzal, hogy mar a Skylake-ben is ott lesz az AVX-512 (ennek en 1% eselyt adok). Csak ugye azt azert nem szabad elfelejteni, hogy ha most optimalizalsz egy kodot AVX/AVX2-re, akkor pikkpakk at tudod majd dobni AVX-512-re, ha megjelenik. Ergo nem egyfajta igeret az AVX-512, hanem inkabb egy utiterv. Azt uzeni a fejlesztoknek, hogy az AVX ki lesz terjesztve 512 bitre (a kesobbiekben 1024 bitre), ergo erdemes foglalkozni a temaval, mert amit most megirsz AVX/AVX2-re, az utana kis meloval ugrasszeruen fog gyorsulni az ujabb architekturakon.
"Mennyien veszik a fáradtságot AVX assembly programozásra manapság?"
Akik veszik ra a faradsagot, azok specifikus kodot fejlesztenek altalaban, es igy nincsenek a CPU-gyarto altal korbehordozva a mediaban (mint amit most az AMD a HSA-val csinal).
-
#14053
Vitamincsiga
tag
dezz
#14048
Vitamincsiga
tag
Tudom
de olyan - szintetikus - tesztet rém nehéz találni! Amit felleltem a CPU/GPU közti sebességkülönbségéről, az ez: [link] illetve egy összefoglaló táblázatot: [link] a gpu-k elméleti erejéről.
Természetesen a Kaveri igazi ereje abban fog megmutatkozni, hogy nem csak játékokban lesz kiaknázható ez a teljesítmény.A szintetikus teszteket pedig azért kedvelem, mert rém egyszerű - művelet/sec - formában közlik, hogy mennyit tud a vas
)
![;]](http://cdn.rios.hu/dl/s/v1.gif)
ez van ha régi qwerty telóról ír az ember.
- memória használatánál a 4 modul + 16 CU bevállalható lenne. Természetesen 20 nm-es gyártástechnológia mellett.
Ú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.
- Samsung Galaxy S23 , 8/128 GB , Kártyafüggetlen
- Samsung Galaxy Xcover 5 64GB, Kártyafüggetlen, 1 Év Garanciával
- Bowers/Wilkins PX8 fejhallgatók (dupla Bluetooth eszköz csatlakoztatása!) - ELKELTEK
- Beszámítás! Sony PlayStation 5 825GB SSD digital konzol garanciával, hibátlan működéssel
- Samsung Galaxy A12 64GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest