+1

Te Fiery, nem lehetne, hogy egyes mondatok kiragadása és fanboyszerű lereagálása helyett inkább egészben válaszolnál 1-1 bekezdésre, a lényegre koncentrálva?

Más a trendek és más az ipar szabályainak megváltoztatsa. Az előbbit akár kisebb cégek is képesek megváltoztatni, ha valami olyat kínálnak, ami más fontos szereplőknek kimondottan hasznos. Lásd pl. ARM.

Leírtam: igen, a gyengélkedő CPU oldallal csak félkarú óriás az APU. Most! Hadd emlékeztesselek, hogy egy olyan topikban beszélgetünk, ami többek között a Zenről szól, ami kiegyenlítettebbé teheti az erőviszonyokat, Intel vs. AMD és CPU vs. IGP terén is.

Arról nem beszélve, hogy az Intel is ott van ezen a pályán, csak ők IGP oldalról erősítenek. Ezen kívül az AMD és a HSA az ARM-os cégeknek nem csak átvehető mintákat, hanem kész megoldásokat is kínálnak.

- Az Apple pont az OpenCL egyik fő propagálója, legalábbis desktopon. Nem tudom, teló/tablet fronton mi a helyzet, mindenesetre a SoC-jaikban lévő PowerVR IGP-k a Series 6 óta támogatják az OpenCL 1.2-t.

- Az újabb Tegrák támogatják a CUDA-t és az OpenCL támogatás is be lett jelentve.

- A SoC-ok többségében alkalmazott IGP-knél ott van az OpenCL-támogatás: Adreno, Mali, PowerVR, Vivante, stb.

- Természetesen az Intel termékei is támogatják.

- Szoftveres támogatás is van Android alatt:
o OpenCL on Mobile Devices
o Getting Started with OpenCL on Android
o OpenCL Info app @ Google Play
o OpenCL ES Phone GP(GPU) Android Benchmarks from SiSoftware
(Az AIDA for Androidban mikor lesz ilyen? Látom, device listing már van.)

Továbbá, mint tudod, az ARM, az Imagination (MIPS) és a főbb SoC-készítők többsége (Broadcom, MediaTek, Qualcomm, Samsung, STMicroelectronics, Texas Instruments, Toshiba, stb.) tagjai a HSA Foundationnek. Nem történik semmi? Mint szintén tudnod kell, a hw területén lassan őrölnek azok a bizonyos malmok, még csak nemrég készült el a HSA 1.0 és idejekorán semmelyik gyártó sem fedi fel a terveit.

"A valosag (a jelenben) az, hogy a gyartok teljesen massal vannak elfoglalva, mint hogy HSA-val vackolodjanak."

Azt nem tudni, hogy a HSA-val kapcsolatban milyen fejleszések mennek a háttérben, de annyira azért nincsenek mással elfoglalva, hogy az OpenCL támogatásra ne helyezzenek hangsúlyt és ne biztosítsanak OpenCL fejlesztői SDK-kat is (lásd fent). A telós szoftverfejlesztők is kezdenek mozgolódni, jól jön a plusz számítási teljesítmény.

(#235): Dehogynincs.

(#223) eight: Ott van pár sorral feljebb.

[ Szerkesztve ]

Én személy szerint bár cseréltem Intelre 1éve...de 25évig AMD-s voltam.
Csak is azért vettem Intelt mert hajtott a kiváncsiság hogy tényleg mi is az igaz "a többet is tudna a vga-d" mondtat részletből...bevált igazuk volt többet tud...
Viszont a hozzászólók többsége elfelejti azt ha annyira fikázhatjuk az elmaradt cpu 1szálas tudás miatt az AMD-t akkor az APU-kban is találjunk már kifogást mert ott pl igp fronton igen csak az AMD a jobb...
Kevesebb pénzből kisebb piaci részesedéssel..amúgysem lehet túlnagyot álmodni.
Én várom az Am4-et, jólesz az ahogy egy Am3+ még mindíg tud olyan jó lenni mint egy i5....csak számításba kell venni h nem a legjobb vga dukál mellé és máris levan a gond.

Asus ROG STRIX /ROG-Join the republic/

"igp fronton igen csak az AMD a jobb" - Ez bizony így van, és kb akkora fölénnyel vezetnek, mint amekkorával CPU-téren a kékek. A gond ott van, hogy míg a hiányos igp-t ki tudod pótolni dVGA-val, ha a CPU-ból hiányzik az erő, arra nincs bővítőkártya. Igazából az AMD-re tökéletesen passzolhatna a subnotebook/ultrabook/netbook/tablet és a HTPC szegmens, lévén ott nem kell őrült nagy CPU erő, viszont a sok médiafogyasztás miatt, hasznát venné az ember az IGP-nek. Na honnan is hiányoznak pont az AMD-re épülő termékek? a szubnoti/ultrabook/netbook/tablet és a mini-PC piacról . Pedig a most érkező Carrizzo-L is tök jó lenne, de szokás szerint ezt is el fogják b&@#ni, és majd belerakják 17"-os förmedvényekbe. -> ne legyen igazam.

[ Szerkesztve ]

30€ Meta store bónusz Quest headset aktiváláshoz, keress priviben :)

"Te Fiery, nem lehetne, hogy egyes mondatok kiragadása és fanboyszerű lereagálása helyett inkább egészben válaszolnál 1-1 bekezdésre, a lényegre koncentrálva?"

En a lenyegre szoktam fokuszalni. Vagy azt szeretned, hogy inkabb minden mondatra kulon-kulon valaszoljak, az olyanokra is, amikre nincs mondandom? Amugy meg visszautasitom a fanboy jelzot, en nem vagyok fanboy, akarmennyire is szeretnek sokan azt gondolni. Mar tobb topicban is leirtam ezzel kapcsolatban az allaspontomat, itt nem fogom leirni, mert mar qrvara unom, hogy akarmit irok, valaki mindig elkezdi a szemelyeskedest. Ez egy szakmai topic, nem egy Fiery-topic.

"Más a trendek és más az ipar szabályainak megváltoztatsa. Az előbbit akár kisebb cégek is képesek megváltoztatni, ha valami olyat kínálnak, ami más fontos szereplőknek kimondottan hasznos. Lásd pl. ARM."

A gyakorlat nem ezt mutatja. Marmint hogy a kis cegek igazan komoly valtozasokat tudnak eszkozolni az x86 PC piacon -- amirol ugye szo van alapvetoen, hiszen ez egy Zen topic. De me'g ha tegyuk fel, egy kis ceg meg is tudja a trendeket valtoztatni, abbol is sokszor az jon ki, hogy pont az a kis ceg tud legkevesbe profitalni belole. Hogy ennek mi az oka, nos, ezt mindenkinek a fantaziajara bizom. Mindenesetre ha az AMD az utobbi 10 evet nem azzal toltotte volna, hogy legvarakat epitget es az API, Fusion, ARM meg hasonlo dolgokra fokuszal a klasszikus x86 CPU fejlesztes helyett, akkor siman lehet (_lehet_, nem biztos), hogy elorebb tartana.

"Most! Hadd emlékeztesselek, hogy egy olyan topikban beszélgetünk, ami többek között a Zenről szól, ami kiegyenlítettebbé teheti az erőviszonyokat, Intel vs. AMD és CPU vs. IGP terén is."

Ezt nem vitatja senki, en sem. Csak ugye ott a felteteles mod. Bar, az alapjan, amit az AMD allit (+40% IPC), ha a vegrehajtas idoben es megfelelo modon megtortenik, akkor nem ketseges, hogy az eroviszonyok sokkal kiegyenlitettebbek lesznek a jovo evben.

"Arról nem beszélve, hogy az Intel is ott van ezen a pályán, csak ők IGP oldalról erősítenek"

Marmint IGP oldalrol _is_. Ne allitsuk be az Intelt egy olyan cegnek, aki az AMD-vel ellentetes modon mozog, azaz az x86-ot lesz*rjak, es csak az IGP-t fejlesztik. Plane a Skylake hivatalos rajtja elott ne mondjuk ezt ki: az uj architekturaban barmi lehet, kicsi es nagy fejlesztes is.

"Az Apple pont az OpenCL egyik fő propagálója, legalábbis desktopon. Nem tudom, teló/tablet fronton mi a helyzet, mindenesetre a SoC-jaikban lévő PowerVR IGP-k a Series 6 óta támogatják az OpenCL 1.2-t."

Szerintem ennek nezz utana alaposabban Az Apple anno az OpenCL-t nagyon tolta, igen, de "erdekes" modon az iOS-es keszulekek egyike sem tamogat OpenCL-t, semmilyen formaban, es terv sincs ilyesmire. Ergo az Apple altal ertekesitett keszulekek tulnyomo tobbsege nem tamogat OpenCL-t, es jelen allas szerint nem is fog, hiaba tudná az IGP amugy ezt a kepesseget. Ez a rideg valosag, sokszor nem a vas tudasa donti el a dolgokat. Az Apple lesz**ja valojaban az OpenCL-t es a HSA-t is, sajat terveik vannak a problema megoldasara.

"Az újabb Tegrák támogatják a CUDA-t és az OpenCL támogatás is be lett jelentve."

Igen, a Tegra K1 es X1 (piaci reszesedesuk 0,1% alatt lehet valahol) tamogatja a CUDA-t, de az OpenCL-t nem, es akarmit is jelentenek be, hidd el, nem fogja az nVIDIA elsietni a dolgot. Nekik a CUDA tamogatas a lenyeg, az OpenCL-t csak muszajbol csinaljak, ha az adott piac megkoveteli. Az ultramobil piacon az OpenCL nincs tulzottan elterjedve -- hiaba tamogatja X fele SoC jelenleg is, ha egyszer szoftverek nincsenek ra --, es amig nem terjed el jobban, addig az nVIDIA sem fog sietni az OpenCL stack-kel.

"A SoC-ok többségében alkalmazott IGP-knél ott van az OpenCL-támogatás: Adreno, Mali, PowerVR, Vivante, stb."

Marmint csak az ujabbaknal, es ott sem mindegyik verzional. A Vivante egyebkent erdekes allatfajta, naluk hiaba tudja adott esetben egy SKU, az arra epulo eszkozon megsem mindig talalhato OpenCL implementacio. De teny, hogy terjed az OpenCL tamogatas, bar azt sosem probaltam konkret OpenCL kernel futtatasaval, hogy ezek milyen minoseguek. Mar szamtalanszor leirtam, hogy a compilerek ugy nagy altalanossagban sz*rok szoktak lenni, igy nem lepodnek meg azon sem, ha az ARM, Qualcomm (stb) OpenCL stack-ek is tele lennenek bugokkal. Az Adreno 330 driverben mar talaltam a device info resznel crash-t, sz'al nincs tul jo eloerzetem a compilerekkel kapcsolatban sem...

"Szoftveres támogatás is van Android alatt:"

Van, marmint diagnosztikai szoftverek meg benchmarkok. Es azon kivul? Valami ertelmes felhasznalasa az OpenCL-nek?

"Az AIDA for Androidban mikor lesz ilyen? Látom, device listing már van"

Majd lesz, az ultramobil benchmark nem egyszeru tema, ha az ember jol akarja csinalni. Pontosabban, igazan jol nem is lehet csinalni a hoproblemak es throttling miatt... De ez nagyon off.

"Továbbá, mint tudod, az ARM, az Imagination (MIPS) és a főbb SoC-készítők többsége (Broadcom, MediaTek, Qualcomm, Samsung, STMicroelectronics, Texas Instruments, Toshiba, stb.) tagjai a HSA Foundationnek"

Igen, de a tagsag nem kotelezi oket semmire.

"Mint szintén tudnod kell, a hw területén lassan őrölnek azok a bizonyos malmok, még csak nemrég készült el a HSA 1.0"

Es akkor hogy van az, hogy ha a Khronos bejelenti az OpenGL 4.4-et (csak egy pelda), akkor mar aznap jon melldongetve az nVIDIA, hogy itt az elso OpenGL 4.4 compliant ForceWare? Nem csipem a kioktato stilusodat, de csereben en is hadd legyek kioktato: ugye tudod, hogy a HSA Foundation tagjakent lenyegeben 2-3 evre elore megvan a specifikacio fejlesztesi, validalasi es veglegesitesi roadmap minden HSA tag cegnek? Tehat pontosan tudtak, hogy mikorra varhato a HSA 1.0 veglegesitese, hogy abban mi lesz, mirol szol. Szerinted miert nem jelent meg megsem egyetlen rohadt hardver sem a HSA 1.0 bejelentese idejere idozitve? Es azota sem, csak ugy mellesleg... Nem lehet, hogy megis csak az az oka ennek, hogy a SoC gyartok egesz mas dolgokkal vannak elfoglalva es/vagy lesz*rjak az egesz HSA mizeriat?

"és idejekorán semmelyik gyártó sem fedi fel a terveit."

Hat persze hogy nem Nem letezik ARM es Qualcomm roadmap sem, es abszolut nem egy AMD-fele roadmapet bemutato cikkhez kapcsolodik ez a topic sem. Oh, wait......

"A telós szoftverfejlesztők is kezdenek mozgolódni, jól jön a plusz számítási teljesítmény."

Peldakat kerek ilyen szoftverekre. Lehet betas is, de benchmark nem lehet.

[ Szerkesztve ]

EZ már 1 cikk ...-.-

Az élet olyan mint a motor, ha nem megy akkor be kell rúgni..

lol Az ok hogy neked elég egy 6300 szintű proci, de ki ne találd már, hogy fölösleges az i7. Képzeld vannak nagyobb igényű emberek is. Valószínű azért lehet kapni i7-et mert mindenkinek elég egy 6300. Megnézném mit kezdene a 970-emmel. Egy i3 is jobban meghajtaná sztem. Használtan már elég jó áron lehet kapni i5-i7-et. Nem akkora összeg. Jobban megéri mint az AMD. Persze újan más tészta. peace

<R6 08'> Core™ i5-13600KF / Gainward RTX 4070 Panther / ACER™ PREDATOR XB271HU 165Hz //

Nem írtam, hogy fanboy vagy, csak megállapítottam, hogy egyes dolgok (fölényeskedőnek tűnő és túlzó) odadörgölése (1-1 smilyval tűzdelve) inkább fanboyszerű megnyilvánulás, mint szakmai, nemde? Másrészt ezek csak felesleges mellékszálakat indukálnak, ezért tettem javaslatot a mellőzésükre.

A MS, az Apple és sok másik is kicsiként kezdte és aztán elég gyorsan meghatározóvá váltak. Az okostelefonok és tabletek beköszöntével pedig az ARM és egy sor alig ismert cég vált meghatározó tényezővé. Az AMD is kiveheti ebből a részét a HSA-val és az egész CPU-GPU házasítás úttörőjeként (talán a K12-vel is).

Leszűkítve az x86-ra, sokkal jobban is elsülhetett volna a Fusion téma, jobban előtérbe helyezve a GPGPU-t és a CPU-GPU kooperációt, ha az AMD eddigi APU-i nem lettek volna félkarú óriások. Nem értesz ezzel egyet?

"Marmint IGP oldalrol _is_. Ne allitsuk be az Intelt egy olyan cegnek, aki az AMD-vel ellentetes modon mozog, azaz az x86-ot lesz*rjak, es csak az IGP-t fejlesztik. "

Miért, talán nem került egyre fejlettebb és nagyobb teljesítményű IGP az AMD APU-iba? (Dehogynem.)

Oké, tehát az Apple nem támogatja az OpenCL-t iOS-en. Van helyette Metal. Más szóval, magát a GPGPU-t ők is fontosnak tartják...

"Van, marmint diagnosztikai szoftverek meg benchmarkok. Es azon kivul? Valami ertelmes felhasznalasa az OpenCL-nek?"

Ha nem lehet ilyen, akkor nyilván nem lesz. Ha lehet, akkor pedig lesz. Miért is ne lehetne értelmes alkalmazási területet találni neki?

Fontos tények leszögezése, amik neked sem újdonságok, mitől kioktatás?

"Nem letezik ARM es Qualcomm roadmap sem"

De, az van, meg pár felületes infó, de ha a részletekre vagy kíváncsi, hamar falakba ütközöl. Jó esetben NDA alatt adnak ki infókat, vagy még úgy sem. Ezt neked kellene a legjobban tudnod.

"Szerinted miert nem jelent meg megsem egyetlen rohadt hardver sem a HSA 1.0 bejelentese idejere idozitve? Es azota sem, csak ugy mellesleg..."

Akkor ez mi a fene?

Kész, hasznos program talán még nincs, de rákeresve az "OpenCL Android"-ra számos ilyen irányú fejlesztésről szóló oldal és topik jön elő, azaz előbb-utóbb jönnek ilyen programok. Az lenne a furcsa, ha nem jönnének.

(#261) morgyi: Dehogy vannak tiltva! Van fent néhány egyszerűbb programocska és egy sor OpenCL-es fejlesztésről szóló könyv is. [link]

Most még az mondható el, hogy 2 évnyi felesleges költekezés nélkül is versenyképesek a felsőkategóriában és vígan kínálhatnak $400 és $1000-os árakon termékeket. Erre fog most megérkezni a GTX980 ellenfele vélhetőleg 500-550 dolcsi környékére, vagy fölé. Függően attól, hogy mennyire lesz tényleges ellenfél és mennyire lesz félúton az új Titan felé.
Nem teljesen értem, hogy milyen kiegyensúlyozatlanságról beszélsz a dGPU piacon, hiszen ha valaki eddig nem vett GCN kártyát az még a mai napig megteheti szájbiggyesztés nélkül a HEDT szegmensben is. Ezzel szemben processzor piacon azért vitathatatlan, hogy AMD-t választani kompromisszumokat igényel.

A Kaveri-t pedig nem azért hoztam fel, mert HEDT piacra szánt terméknek tartom, hanem mert elég jól tükrözi a cég megváltozott hozzáállását. Olybá tűnik, hogy háttérbe szorult a mennyiség és előtérbe a termékenkénti haszon. Nem kizárt, hogy ez a Zen korszakban is fennmarad. A 800-1000 dolláros kategória megcélozásához szerintem bőven elég, ha elérik, hogy ne legyen ennyire egyértelmű, hogy melyik cég termékei képezik a csúcsot. Ehhez nem kell nyers erőben erősebb processzort összerakni a konkurenciánál, csak egy okosabb és sok területen ügyes terméket, ami közel egál helyzetből tud indulni és egyes fontosabb területeken első helyre ugrani. Erre meg van sansz, ha továbbra is komoly kapcsolatban marad a cég a szoftverfejlesztőkkel. Ráadásul aktuálisan ott vannak a CMT felépítésből származó kudarcok tapasztalatai és a konkurens Nehalem architektúrájával elkezdett útjának eredményei.

Csak én a továbbiakban is a GloFo miatt kételkedem.

u.i.: Ez lehet mégis Fiery topik lesz.

(#253) Z10N: A Carrizo elvileg már integrált SATA/USB és egyéb vezérlőkkel jön. Ezért nem tudom, hogy milyen hagyományosan vett "chipsetet" tudnak még az alaplapra tenni. És gondolom a közös foglalat miatt az egész AM4-re jellemző lesz ez.

A Godavari meg ugyanúgy Steamroller, mint a Kaveri, lévén, hogy a Kaveri lapkáról beszélünk, talán minimálisan optimalizált formában.

[ Szerkesztve ]

"A Godavari meg ugyanúgy Steamroller, mint a Kaveri, lévén, hogy a Kaveri lapkáról beszélünk, talán minimálisan optimalizált formában."

Elvileg egy újabb stepping. Régebben is új nevet kaptak ezek. Kérdés, milyen érdemi változásokat hoz. Sokat nyilván nem.

(Mostanában nem sokat "vacakol" az AMD steppingekkel... Bár a Bulldozer->Piledriver váltás lényegében egy revízióváltás, B2/3->C0. De steppingváltások nincsenek, illetve csak ha nagyon muszáj.)

Az előzőben az FX-ekre gondoltam a revízióváltással kapcsolatban, nem a Trinityre. Apropó, az viszont fura, hogy a Trinity->Richland váltásnál ugyanaz maradt a stepping, legalábbis a kódja, még csak nem is B0-ás lett, holott megjelentek olyanok a Trinityk között.

[ Szerkesztve ]

Hajrá AMD, csak ígérgetésből meg tervekből már valami kézzelfoghatót (és maradandót) is alkossatok!

Jelenleg jobban élek, mint... 1 év múlva. // Eladó Warwick BC10 basszusgitár kombó -> https://hardverapro.hu/apro/warwick_bc_10_basszusgitar_kombo/friss.html

Gondolom így, hogy a 20nm ugrott és vele együtt a SkyBridge, van lehetősége a mérnököknek "matatni" még egy kicsit a Seattle-lel is. Talán egy újabb steppinget hoznak ki, talán a mikrokódján csiszolnak még (*), esetleg csak az AGESA kódon javítanak.

* Ha jól sejtem, a Richlandnál is ez változott, hiszen steppingváltás nélkül jelentek meg új utasításkészletek a vonatkozó wikis lap szerint. És talán a Godavarinál is csak itt van változás, ha ott sincs steppingváltás.

(#267) Agregator: Ami azt illeti, akadt néhány alkalmazás, ahol már a 8150 is be tudta előzni picivel az aktuális i7-et.

[ Szerkesztve ]

"A MS, az Apple és sok másik is kicsiként kezdte és aztán elég gyorsan meghatározóvá váltak."

Igen, de ez a fajta siker inkabb az ujonnan indulo cegekre jellemzo, nem az olyan regi motorosokra, mint az AMD. Az AMD kicsikent kezdte, szepen novekedtek, jol lovagoltak meg az x86 hullamokat egy darabig, aztan jott az inkompetens vezetoseg es lenullazta az elozo 20 ev erofesziteseit. Mindig nehezebb egy regi, becsontosodott ceget megujitani es ujra energiaval megtolteni, mint egy zsir uj ceget -- ami mondjuk 1-2 jo otletre epit -- felfuttatni. Nem veletlen, hogy sokszor nagy, regi cegekbol kivalt kisebb csapatok startupokat inditva jutnak el a vilaghirnevig, es utana egy masik nagy mamut adott esetben par milliard dollarert megszerzi a kis ceget a remek otlete miatt.

"Az AMD is kiveheti ebből a részét a HSA-val és az egész CPU-GPU házasítás úttörőjeként (talán a K12-vel is)."

Az igazan jo otletek nem 10 evig szoktak huzodni, mire attorest ernek el veluk. Nem mondom, hogy ez esetben nem lehet maskepp, csak hogy nem tipikus, hogy eddig **szkolodik egy ceg egy koncepcioval, es a vegen megis sikerre tudja vinni. Az Intel is szenvedett sokaig az Itaniummal, es nem is lett sikeres. Az IT berkeiben altalaban egy jo otlet nagyon hamar felfut, aztan X ideig tarol. Nem tipikus az, hogy csomo idot kell varni egy jo otlet materializalodasara.

"Leszűkítve az x86-ra, sokkal jobban is elsülhetett volna a Fusion téma, jobban előtérbe helyezve a GPGPU-t és a CPU-GPU kooperációt, ha az AMD eddigi APU-i nem lettek volna félkarú óriások. Nem értesz ezzel egyet?"

Fene tudja. Szerintem hasonloan jart volna abban az esetben a Fusion tema, mint ahogy az AVX-AVX2. Azaz, anelkul is remek teljesitmenyt jut a proci, a szoftverek es jatekok 99%-ahoz teljesen jo, a maradek 1% hasznositja a plusz feature-t. De mondjuk ez most is igy van a GPGPU piacon, van azert a szoftverek 1%-a (kb), ami valamilyen formaban a GPU-t is megdolgoztatja.

Egyebkent ami szerintem igazan segithette volna a GPGPU koncepcio terjedeset, ha sokkal korabban behozzak az SVM-et, ha sokkal korabban behozzak a HSA-t, es ha tenyleg egyszeruen, compiler fejfajasok nelkul lehetne programozni az APU-kat. Ja, es az is sokat segitett volna, ha nincsenek dGPU-k Akkor ugyanis a gyartok (AMD + Intel) me'g inkabb ra lettek volna kenyszeritve arra, hogy igazan utos iGPU-t szereljenek a CPU-tokba, es akkor me'g nagyobb lenne a "kisertes" a szoftver fejlesztoknel, hogy kiaknazzak az APU-kban rejlo nagy teljesitmenyt. Mert a jelenlegi helyzet az, hogy vagy szivatod magad a memoria masolassal es a CUDA/OpenCL nyavalyaival, es ha megfelelo kodot tudsz csinalni, akkor egy dGPU-n brutalis gyorsulast erhetsz el; vagy SVM-es APU-ra fejlesztesz mondjuk OpenCL 2.0-ban, de akkor joval kisebb teljesitmenyt kapsz (mint egy kepzeletbeli SVM-es, eros dGPU-nal kapnal), es raadasul a piac sokkal kisebb szeletet tudod megcelozni (a Kaveri + Broadwell egyutt nehany %-a csupan a PC-piacnak). Tehat szerintem a kulonbozo problemak -- az SVM-es APU-k kesoi bemutatkozasa, a HSA lassu elkeszulese, az APU-k relative alacsony teljesitmenye, a programozasi nehezsegek, a dGPU-k meglete, az API-k gancsolasa (Google, Apple, Microsoft, nVIDIA, AMD mind-mind mas API-t szeretne) -- egyuttesen, egymasra raerositve okozzak azt, hogy a GPGPU, dacara minden fejlesztesnek es erofeszitesnek, nem tud kitorni a retegtermek csapdajabol.

"Miért, talán nem került egyre fejlettebb és nagyobb teljesítményű IGP az AMD APU-iba? (Dehogynem.)"

Arra gondolok, hogy most az a kozvelekedes -- nem alap nelkul --, hogy az Intel csak marginalisan fejleszti az x86 CPU reszt, es erosen fejleszti az iGPU reszt; mig az AMD most az x86 CPU reszre van rafekudve (Zen), es az iGPU reszt -- latszolag, erzesre -- kicsit hanyagolja, hiszen ott a Kaveri ota nem tortent semmi, es iden es jovore sem ugy nez ki, hogy inkrementalis fejlesztesnel tobbre futna. Abu mar szamtalanszor leirta, hogy a GPU-kban az a remek dolog (vs. x86 SIMD vagy MIC), hogy 4-5 evente le lehet cserelni az architekturat egy zsir ujra, hogy a bottleneckektol meg lehessen szabadulni, es jelentosen lehessen novelni a teljesitmeny/fogyasztas mutatot. Nos, az AMD reszerol a GCN 2011-ben mutatkozott be, tehat iden vagy jovore -- ha Abunak hiszunk -- idoszeru lenne a csereje. Errol megsincs egyetlen szo sem, egyedul inkrementalis GCN fejlesztesrol beszel az AMD. Oke, hogy (latszolag vagy epp technikai szemszogbol nezve) me'g mindig jol mukodik a GCN, de a Maxwell peldajan latszik, hogy sokszor mas tenyezok dontenek a piaci sikerrol.

Sz'al fentebb csak arra akartam utalni, hogy ez a velekedes nem biztos, hogy megallja a helyet. Nem gondolnam ugyanis, hogy az x86 reszt az Intel akarmeddig inkrementalis fejlesztesekkel akarna tovabbvinni: itt az ideje (Skylake), hogy valami radikalis fejlesztes keruljon a prociba. Ha pedig most megsem kerul be, akkor a 10 nanos shrinknel (Cannonlake) be fog kerulni.

"Oké, tehát az Apple nem támogatja az OpenCL-t iOS-en. Van helyette Metal. Más szóval, magát a GPGPU-t ők is fontosnak tartják..."

En is azt irtam, hogy sajat elkepzelesuk van a problema megoldasara. A problema csupan az, hogy mar hazon belul is eros a fragmentacio, hiszen az x86 alapu rendszereknel OpenCL van, az osszes tobbinel meg nem. nVIDIA-nal ott a CUDA, a Google a Renderscriptet tolja es kopkod az OpenCL-re, a Microsoft pedig a D3DCS-t szeretne inkabb tolni a mobil eszkozokon. Igy fejlesztoi szemszogbol nem egyszeru az elet Ilyen helyzetben me'g ha meg is lenne a fejlesztoben a szandek, hogy szivassa magat a GPGPU temaval, vajon mire es hogyan kezdjen el fejleszteni?

"Miért is ne lehetne értelmes alkalmazási területet találni neki?"

Nem azt mondtam, hogy nincs ilyen terulet, hanem hogy nincs szoftver. Igeny lenne ra, lehetoseg is lenne ra, megsem mukodik a GPGPU a szeles tomegek szamara. Fentebb irtam a problemakat, amik ide vezetnek. Ezzel persze nincs baj, ha egy hardver gyarto nem a GPGPU-ra epiti szinte a teljes termek strategiajat... Az Intel pl. csak ugy mellekesen foglalkozik ezzel, az nVIDIA pedig csak reszben epit a GPGPU-ra, fokent olyan teruleteken, ahol nem problema a specializaltsag, ahol nem mainstream a felhasznalas eleve (Tesla/HPC). Az AMD viszont az utobbi 10 évét feltette a GPGPU-ra, es mivel a GPGPU sehova nem jutott, az rantotta magaval az AMD-t is.

"Fontos tények leszögezése, amik neked sem újdonságok, mitől kioktatás?"

A stilus szurta a szememet. De valoszinuleg eloben maskepp hangzott volna, ezert is lenne jobb ezekrol pizza mellett ertekezni, ugy szerintem sokkal inkabb elo tudna mindkettonk adni a mondandojat

"De, az van, meg pár felületes infó, de ha a részletekre vagy kíváncsi, hamar falakba ütközöl. Jó esetben NDA alatt adnak ki infókat, vagy még úgy sem. Ezt neked kellene a legjobban tudnod"

Miert pont a HSA tamogatast hallgatnák el ezek a cegek? A feluletes roadmapeken is az ilyen alap dolgok fel szoktak lenni tuntetve.

"Akkor ez mi a fene?"

Ha nem tevedek, nem a HSA 1.0 rajtjara keszult el, nem HSA 1.0-ra epul, es nem mellesleg, nem latom a HSA emliteset sem. HSA-ra epul, csak epp jol titkoljak ( me'g Abu sem emliti a hirben, hogy ez HSA-re epul, az pedig mar nem semmi ) Ezt hivjak a HSA Foundation szembekopesenek...

"Kész, hasznos program talán még nincs, de rákeresve az "OpenCL Android"-ra számos ilyen irányú fejlesztésről szóló oldal és topik jön elő, azaz előbb-utóbb jönnek ilyen programok."

Egyedul a kesztermek szamit, tervekkel tele van a padlas. Nezd meg, hany tervezett processzora volt az AMD-nek, es vegul evente hany tervet tettek fel a polcra. Egy szoftver cegnel ez plane igy van, ha nem jutnak elorebb egy projekttel, mert az alapok rosszak, akkor torlik es foglalkoznak valami massal.

"Az lenne a furcsa, ha nem jönnének"

Az lesz a furcsa, ha jonnek

Az androidos OpenCL implementacio pedig egeszen addig tunik frankonak, amig az ember el nem kezd behatobban foglalkozni vele. 3 alapveto problema van vele:

1) Az Android SDK-nak meg ugy altalaban az Androidnak nem resze az OpenCL, tehat minden gyarto olyan implementaciot rak a keszulekre, amilyet akar. Lehet jo, lehet nagyon rossz minosegu is a stack. Javabol nem tudod meghajtani az OpenCL-t, hanem nativ kodot kell hozza fejlesztened. Az Android app fejlesztes egyik legvonzobb tulajdonsaga a Javaban valo kodolas: rettento egyszeruen meg lehet oldani bonyolult problemakat is, nem kell csomo hulyeseggel foglalkozni, es nagyon gyorsan lehet egy appot elkesziteni. Amikor mar nativ kodhoz kell nyulni, onnantol szivas az egesz, es a fejleszto ott talalja magat, hogy a jol megszokott meleg pocsolyabol ujra vissza kell ugrania a 3 meter mely hidegvizes medencebe. Ha Javarol probalsz ujra nativ kodolassal szorakozni, plane hozza me'g az OpenCL kernelt is meg kell csinalnod, az baromira elveszi az ember kedvet az egesztol. Az egesznek, mindenestul Javaban kellene mukodnie, ezt igeri a HSA, elvileg ez meg lesz valamikor oldva. Kerdes, hogy mikor? Iden? Jovore? Es mar megint ott tartunk, megint ugyanaz a problema van: a jovo igerete a GPGPU, nem a jelen technologiaja. Plusz, ha meg is csinaljak a javas HSA implementaciot, azzal me'g mindig csupan a Javaban keszitett szoftverekhez lesz jo az egesz, es az osszes tobbi platformra ez sem lesz megoldas.

2) Ha nem tevedek, egyetlen androidos OpenCL implementacio sem OpenCL 2.x, azaz egyik sem tamogat SVM-et. Java kod, keverve nativ koddal, plusz OpenCL kernel kodolas, plusz memoria masolgatas, plusz nativ kod <-> Java kod interop, plusz a debuggolas nehezsege ---> a jo franc se akarja sz**atni magat ezzel.

3) Az a teny, hogy a Google a Renderscriptet tolja, es hogy az OpenCL csupan megturt statuszt kapott az Android okosziszteman belul, nagyon nem abba az iranyba tereli a fejlesztoket, hogy pont az OpenCL-lel kezdjenek foglalkozni. Kapasbol a Renderscript sokkal egyszerubb, az az Android rendszer resze, lehet Javaban kodolni, nem kell hozza nativ kod, stb. Ha pedig a Google akarja, barmikor kiranthatja a szonyeget az OpenCL alol, valamilyen mondvacsinalt indokkal. A "Don't be evil" mar egy ideje lejart lemez, sajnos. A Nexus 4-rol is milyen ugyesen letakaritotta a Google az OpenCL implementaciot, ha esetleg valaki emlekszik me'g arra a fiaskora. Persze abbol azert nem lett nagy botrany, mert ugysem hasznalta semmilyen szoftver az OpenCL-t...

dGPU: Arra gondolok, hogy az nVIDIA 3x tobb dGPU-t ad el, mint az AMD. Ez nem kicsit megborult piac lett. Teny, hogy barmikor megfordithato, ha az AMD eloall valami utos ujgeneracios kartya csaladdal, csak epp jelen allas szerint rovidtavon csupan a felsohaz kap frissitest (Fiji), az igazan mainstream vonal pedig nem. Ahhoz, hogy legalabb a kiegyensulyozott 50-50% allapot bealljon, a Fijinel joval tobbre lesz szukseg. De egyelore nem latszik a horizonton pl. a GTX960 uj ellenfele, az Rx 300-as szeria inkabb atcimkezes lesz, mintsem valodi uj generacio...

"A 800-1000 dolláros kategória megcélozásához szerintem bőven elég, ha elérik, hogy ne legyen ennyire egyértelmű, hogy melyik cég termékei képezik a csúcsot. Ehhez nem kell nyers erőben erősebb processzort összerakni a konkurenciánál, csak egy okosabb és sok területen ügyes terméket, ami közel egál helyzetből tud indulni és egyes fontosabb területeken első helyre ugrani."

Te teljesen hulyenek nezed azokat az embereket, akik kepesek 800-1000 dollart kolteni egy CPU-ra? De most komolyan Akinek van ennyi penze, es me'g hajlando is ennyi penzert CPU-t venni, az nem a masodik legjobbat akarja, hanem az egyertelmuen legjobbat. 1000 dollarnal dragabb desktop CPU nincs (a Xeonokat ne szamitsuk desktop procinak, az ws es szerver proci), ergo ha valaki 1000 dollart ad egy prociert, az a legdragabb procit veszi, ami desktop PC-be illesztheto. Ha a legdragabbat veszed, a legjobbat, leggyorsabbat akarod kapni, es nem egy okos meg ugyes termeket.

Ha pedig a Zen alapu HEDT proci azonos aron kb. azonos teljesitmenyt fog biztositani, mint az Intel HEDT megoldasai, az egy erdekes szituacio lenne, de akkor sem hiszem, hogy az emberek az AMD fele huznanak. Akkor ugyanis me'g mindig ott lesznek a brandhez kapcsolodo stigmak, pl. hogy az AMD az utobbi idoben nem a teljesitmenyrol volt hires, ez pedig az emberek agyaba ivodott. Plusz, az Intel HEDT platformja igen jol marketingelheto a 4 csatornas DDR4-gyel, ami ellen nem lesz utokartyaja az AMD-nek. Me'g akkor is, ha nem jelent semmilyen valodi elonyt, akkor is a több = jobb keplet alapjan az Intel HEDT platformja fog nyerni. Ergo abszolut letszukseglet lesz, hogy a Zen HEDT CPU teljesitmenyben is egyertelmuen le tudja gyozni a Broadwell-E-t.

[ Szerkesztve ]

Az mindenkepp jo dolog, ha a Seattle egy kiforrott termekkent kerul piacra. Az viszont nagyon rossz, hogy 1 ev kesessel, es hogy a K12-t is arrebb tolta 1 evvel. Vagy azt a Zen tolta arrebb? A fene se tudja, de mindenesetre az is kesobb jon.

A Godavarinal pedig nem a steppinget meg reviziot meg egyebeket kell nezegetni. Godavari = Kaveri + cca. 100-200 MHz x86 clock bump + cca. 10% iGPU clock bump. Ennyi. Jobb lett volna Kaveri Refresh-nek hivni, az egy oszintebb kodnev lett volna, de vegul is mindegy, hiszen a szakmai kozosseg a bemutatonal ugyis pontosan latni fogja, hogy mekkora fejlesztesrol is van szo valojaban. Kicsit jobban eladhato termek lenne, ha legalabb -- a Haswell Refresh platformhoz hasonloan -- uj chipsetekkel es uj alaplapokkal egyutt erkezne a frissites, de en nem tudok rola, hogy "A98X" vagy hasonlo chipset keszulne a Godavarihoz. Ha pedig nincs uj chipset, akkor velhetoen az uj alaplapok is maximum annyit tudnak majd villantani, hogy lesz rajtuk USB 3.1 -- viszont tovabbra sem lesz M.2 slot

[ Szerkesztve ]

Ez apróbb módosításokkal mehetne is egy Logout bejegyzésbe.

A Bulldozer vonalra tekintesz úgy, mint az inkompetens vezetőség hibájára? Felsővezetői döntés lehetett, hogy pont erre mentek el akkor?

Akkoriban sokan szídták a moduláris fejlesztési koncepciót is, mostanra már talán látszik, hogy nem volt értelmetlen a dolog, hiszen lehetővé teszi az aktuális céloknak vagy elvárásoknak meg megfelelő könnyebb építkezést a meglévő elemekből. (A mostani prezentációban is hangsúlyt kapott, puzzle-lel jelképezve.)

Értem, amit írsz, de a GPGPU koncepció nem az AMD szüleménye. Már az első programozható shaderes GPU-knál elindultak ilyen próbálkozások. (Most néztem meg, pl. a "QJuliaPS2_0.exe" 2005-ös, de voltak korábbiak is.) Akkor persze ez még nagyon nehézkes és korlátozott volt, de mozgatta a programozók fantáziáját. Valószínűleg senki sem gondolta volna, hogy így 10 évvel később még mindig csak az első nagyobb lépéseknél fogunk tartani. Mindenesetre, az AMD ezt akarta "meglovagolni" és egyben egy új szintre emelni. Nagy kár, hogy közben a CPU oldalt egy kicsit elbaszarintották.

Valóban lassúcskának tűnik a HW alapok fejlesztése, valószínűleg túl kockázatosnak ítélték meg, ha nem csak kisebb lépésekben haladtak, így egyszerre mindig csak egy főbb új komponest vittek be a rendszerbe.

Én mindenesetre nem úgy látom, hogy egy elvetélt dolgot próbálnak élesztgetni, hanem olyasmiről van szó, ami lassan érik be, de addig is nevelgetni kell.

Adott esetben a dGPU-s GPGPU is hasznos tud lenni, de sokszor szükség lenne egy helyi CPU-ra, mert vannak feladatrészek, amik annak fekszenek igazán. (Úgy tudom, az Nvidia is elindult ilyen irányban, csak ugye x86 licent hiányában ARM alapon, nem tudom, hol tart most ez a dolog.) Meg hát ugye dGPU-n sem mentesül jelenleg a programozó minden nehézségtől.

Ezt nem igazán tudom értelmezni, hogy a Kaveri óta nem sok minden változott, hiszen az az AMD legutóbbi, már piacon lévő APU-ja. Én a Llano->Trinity->Kaveri sorozatra gondoltam, ahol nem kis változások voltak IGP oldalról (is). Azt nem mondanám, hogy eközben Intelnél semmi sem történt a CPU oldalon, de azért túl forradalmiak sem voltak a változások. Lényegében kb. mint AMD-nél a Bulldozer vonalon. A Carrizo IGP-je minden bizonnyal szintén GCN alapú, kisebb-nagyobb csiszolásokkal. Van valami gond a GCN-nel, hogy mindenképpen le kellene cserélni?

(Nem tudom, mikor írta azt Abu, a DX8-9-10-11 korában még érvényes volt, a Mantle mellett már talán kevésbé áll. De hát a fő kérdés, hogy érdemes-e lecserélni vagy sem.)

A Renderscript is a GPGPU-ra épít, itt tehát csak az API-k harcáról van szó... Nem a GPGPU hasznossága kérdőjeleződik meg.

"Az AMD viszont az utobbi 10 évét feltette a GPGPU-ra, es mivel a GPGPU sehova nem jutott, az rantotta magaval az AMD-t is."

Na hát azért kellett ahhoz a CPU oldal meglehetős gyengélkedése is. Sőt, inkább úgy mondanám, hogy a CPU oldal gyengélkedése lassította be a GPGPU és a GPU-GPU kooperáció előretörését, ami az AMD fejlődéshez való hozzájárulását illeti. (Intel oldalról pedig az, hogy egyrészt nekik az IGP-n kellett és még kell jócskán fejleszteni, másrészt nagyobb érdekeltségük van a CPU-ban.) De ezek szerintem mind csak halogatni tudták és tudják egy újabb korszak eljövetelét, meggátolni nem. Egyszerűen azt diktálja az energiahatékonyság történye (amit Abu szintén szokott emlegetni), hogy amit sokkal hatékonyabban tud ellátni a GPU, még a grafikán kívül, azt rá kell bízni.

Na az nem kis kockulás lenne.

"HSA-ra epul, csak epp jol titkoljak"

Látod!? De hogy ez miért van, azt ne tőlem kérdezd... Talán nem akarják készakarva helyzetbe hozni az AMD-t, vagy hogy túlzottan nyeregben érezze magát, vagy ilyesmi. (Végső soron alapvetően konkurencia.)

1) Ja, én is nagyon várom, mikor épül be végre a natív és kényelmesebb GPGPU-támogatás a Javába, mindenestre előbb-utóbb megtörténik. (Tudom, ilyenre nehéz építeni, de legalább tudjuk, hogy lesz ilyen.)

Az okostelefonok és tabletek robbanásszerű elterjedésével igencsak meghatározóvá vált a Java is. Ha megjelenik valamilyen javás program, amit sokan használnak, az portolásra kerül más platformra is. De olyan alkalmazások is lehetnek, amik kimondottan okostelefonokhoz vagy tabletekhez "illenek".

2) Én is csak 1.2-vel találkoztam. Kísérletezgetésre ez is jó lehet.

3) Ez igaz, de az OpenCL-t már ismerik páran, ezért először nyilván ezzel próbálkoznak (vagy próbálkoztak). Lehet, hogy később áttérnek a Renderscriptre, már ha kimondottan Andoidra akarnak fejleszteni. Vélhetően egyelőre kivárnak és addig is kísérletezgetnek.

(#271): Amúgy mi teszi lehetővé ezt a 100-200 MHz-es bumbot? Tekintve, hogy a gyártást már külső cég végzi. Az utóbbi érdeme?

[ Szerkesztve ]

Nincsenek blogger ambicioim, de annak orulok, ha hasznosnak talalja valaki a postjaimat.

"A Bulldozer vonalra tekintesz úgy, mint az inkompetens vezetőség hibájára? Felsővezetői döntés lehetett, hogy pont erre mentek el akkor?"

Barmelyik cegrol is legyen szo, mindig a vezetoseg hibaja, ha felrecsuszik valami. Nekik kellett donteniuk arrol, hogy a klasszikus dizajn helyett egy ilyen erdekes megoldast (CMT) reszesitsenek elonyben, es hogy extrem magas orajeleket celozzanak be -- a NetBurst latvanyos bukasa utan par evvel, ugyebar. De nem csak az volt a hiba, hanem az is, hogy a Fusion projektnek egyaltalan nekikezdtek az ATI felvasarlasaval. Erre persze lehetne azt mondani, hogy anelkul most nem lenne APU meg nem lenne konzol biznisz -- de en meg erre azt mondom, hogy akkor siman lehet, hogy helyette lenne egy eros x86 architekturajuk, amivel me'g meglenne az a piaci reszesedesuk es stabil helyzetuk a szerver piacon, ami az Athlon 64 / Opteron idokben volt anno. Es jol latszik az Intel penzugyi jelentesein, hogy manapsag az x86/PC piacon a szerverekbol lehet penzt csinalni, a tobbi maximum a vegetalasra eleg. (A konzolokbol meg nagyjabol ehenhalni lehet, ha az AMD egykori meretet nezzuk. Mostansag lehet hogy jol jon nekik az a penz, de aranyaiban eleg keves az, hosszutavon, a kezdeti boom utan)

"Értem, amit írsz, de a GPGPU koncepció nem az AMD szüleménye."

Nem mondtam, hogy az AMD talalta ki/fel a GPGPU-t. De az AMD epitette a teljes piaci strategiajat a GPGPU-ra, mig masok legfeljebb reszben. Az AMD-nel mar hosszu evek ota minden a GPGPU-rol (Fusion, APU, Stream majd OpenCL, HSA, stb) szol, mindennek az a magyarazata, mindenre az a mentseg, mindenre az a reakcio. Egyedul a topikhoz kapcsolodo hirben taglalt befektetoi eloadas szolt arrol, hogy megis az x86 a lenyeg, es megsem minden a GPGPU-rol szol. Breath of fresh air -- ahogy az angol mondja.

"Akkor persze ez még nagyon nehézkes és korlátozott volt, de mozgatta a programozók fantáziáját."

A fantaziaval azota sincs gond. Csak ez kicsit olyan tema, mint a megujulo energia: rengeteg (fel)megoldas letezik mar most is, de hosszu evek utan sincs egyelore igazan tuti megoldas (Kerek mindenkit, hogy ebbe most ne kosson bele, ne menjunk el egy eco vita iranyba, csak mint peldat hoztam fel egy hasonloan nehezen megfoghato, hasonloan nehezen megoldhato problemara)

"Én mindenesetre nem úgy látom, hogy egy elvetélt dolgot próbálnak élesztgetni, hanem olyasmiről van szó, ami lassan érik be, de addig is nevelgetni kell."

Nezopont kerdese. Ha egy ilyen nevelgetesi proceduraba belerokkan kozben egy ceg, ha (lassan) a csod szelere kerul, az nem jo dolog Annyit nem er az egesz, akarmilyen igeretes technologiarol legyen is szo.

"Adott esetben a dGPU-s GPGPU is hasznos tud lenni, de sokszor szükség lenne egy helyi CPU-ra, mert vannak feladatrészek, amik annak fekszenek igazán."

Ezt senki sem vitatja. Csak epp egy dGPU-val me'g nehezebb bánni, es igy me'g kevesbe van esely arra, hogy mainstream feladatokra is be lehessen fogni a dGPU-kban rejlo teljesitmenyt. Az idealis megoldas egy SVM-es eros CPU + eros iGPU paros lenne, amivel egyszerre lehetne kivaltani a videokartyakat es a mostani nem tul eros GPU-val szerelt APU-kat is. Csak persze ott meg a TDP a problema, a memoria alrendszer, az alaplapok bonyolultsaga, stb. stb.

"Ezt nem igazán tudom értelmezni, hogy a Kaveri óta nem sok minden változott, hiszen az az AMD legutóbbi, már piacon lévő APU-ja."

Arra probaltam celozni, hogy azota valahogy nincs szo arrol, hogy majd milyen oriasi valtozasok jonnek az iGPU-khoz. Igen, a Llano --> Trinity --> Kaveri vonalon boven volt valtozas, minden lepcsonel radikalisat huzott az AMD, most viszont szo nincs ilyesmirol sem a Carrizonal, sem a Carrizo utoda kapcsan. GCN egyszer, GCN ketszer, GCN sokadszorra is. Amivel a Maxwell megjeleneseig nem is volt baj, de most mar ideje lenne megint lepni egy nagyot elore az AMD-nek, iGPU-ban is. Fokent, mert az Intel iGPU-k jonnek fel, mint a talajviz. Hogy mivel lehet az AMD-nek villantani iGPU-ban? Pl. eDRAM, HBM, stacked memory, uj architektura, stb.

"Van valami gond a GCN-nel, hogy mindenképpen le kellene cserélni"

A Maxwell ota van. Azota jol latszik, hogy a GCN mar nem csucstechnologia. Amivel nincs is baj, vegul is mar 4 eve nyomja az AMD, de pont ezert is kellene mar hozzanyulni az orajel reszelgetesen es az aprobb tweakeleseken tul is.

"A Renderscript is a GPGPU-ra épít, itt tehát csak az API-k harcáról van szó... Nem a GPGPU hasznossága kérdőjeleződik meg."

Szerintem felreerted azt, amit mondani akarok Nem azt mondom, hogy a GPGPU mint koncepcio rossz vagy haszontalan vagy ertelmetlen. Dehogyis. Azt mondom, hogy a szethuzas, fragmentacio, egymasra kopkodes, toketlenkedes es me'g ki tudja mi miatt az utobbi 10 evben sem sikerult senkinek letennie az asztalra egy olyan koherens megoldast, amivel konnyen kiaknazhatova valna a GPU-k ereje altalanos celokra is. Ezt igeri a HSA, csak ugye az API-k harca miatt megint nem fognak a fejlesztok egy koherens, egyseges, minden (vagy legalabbis a legtobb) platformon hasznalhato megoldast kapni. Es ha a fejlesztok nem kapjak meg azt, amivel a legtobb hardvert egyszeruen meg tudjak celozni, akkor nem is fogjak megmozditani a hatsojukat.

"Na hát azért kellett ahhoz a CPU oldal meglehetős gyengélkedése is."

Az x86 CPU-oldalt is bealdoztak a GPGPU eroltetese miatt. Azt hittek, majd az OpenCL meg a HSA megoldja a gyenge CPU problemajat, es igy nem kellett nekik idoben osszekapni magukat az x86 fejlesztesben. Ha nem a GPGPU buvkoreben elt volna az AMD, akkor a Zambezi tervezese kozben mar azonnal nekiallnak a Zenen dolgozni, es akkor mar reg piacon lehetne a Zen, es ujra versenykepesek lehetnenek az x86-piacon. Nem baj, ha valaki hibazik, csak idoben fel kell ismerni, es ki kell javitani. A Zambezirol mar a szimulatorban lehetett latni, hogy nem fog mukodni, azaz hogy nem lesz eleg eros az aktualis konkurenciahoz kepest. Vagy piacra sem kellett volna dobni, vagy ha mar megis piacra dobtak, akkor azonnal le kellett volna allni arrol a vonalrol. Maximum me'g a Trinity belefert volna, de aztan annyi, dobni kellett volna az egesz Earthmoving core vonalat. A Cats (Jaguar/Puma) vonalon tisztan latszik, hogy a mernoki tehetseg abszolut megvan (vagy megvolt, anno) az AMD-nel: tudnak ok rohadt jo x86 CPU magokat tervezni, ha az van fokuszban. Ezert is lehet remenykedni a Zenben, ezert is varhato, hogy ha gyartassal es az ido tenyezovel nem lesz gond, akkor eljohet ujra az "Athlon 64 korszak". Csak epp a Zent meg lehetett volna csinalni 3-4 eve is mar, ha nem a GPGPU-ra tett volna fel mindent az AMD...

"Egyszerűen azt diktálja az energiahatékonyság történye (amit Abu szintén szokott emlegetni), hogy amit sokkal hatékonyabban tud ellátni a GPU, még a grafikán kívül, azt rá kell bízni."

Igen, ez az elmelet. De elmeletben az IA-64 is jo volt, a Transmeta is jo volt, stb. stb. Vannak olyan problemak, amik a gyakorlatban nem megvalosithatoak oly modon, hogy az a tomegeket tudja celozni. A GPGPU egyelore ebben a fazisban van, aztan majd meglatjuk, ki tud-e torni ebbol.

"Talán nem akarják készakarva helyzetbe hozni az AMD-t"

Akkor megiscsak HSA = AMD? Ezt mondom mar egy ideje Vagy ha nem igy van, akkor ha a HSA-t helyzetbe hozod, azzal miert hoznad pont az AMD-t helyzetbe? Viccelek, nehogy komolyan vedd

"Ez igaz, de az OpenCL-t már ismerik páran, ezért először nyilván ezzel próbálkoznak (vagy próbálkoztak). Lehet, hogy később áttérnek a Renderscriptre, már ha kimondottan Andoidra akarnak fejleszteni."

Ha kifejezetten Androidra fejlesztesz, es nagyon erdekel a GPGPU, akkor miert varnal a javas HSA-ra, ha egyszer ugyanazt (khm, najo, tudom, hogy nem ugyanaz, de fogjuk ra) megkapod mar most, egyenesen a Google-tol? (Renderscript) Ehhez kepest, nem latok tul sok renderscriptes appot sem.

"Amúgy mi teszi lehetővé ezt a 100-200 MHz-es bumbot? Tekintve, hogy a gyártást már külső cég végzi. Az utóbbi érdeme?"

A Godavari tulajdonkeppen egy uj Kaveri stepping, amiben aprobb modositasok, gyartastechnologiai optimalizalasok is vannak. Cca. 1-1,5 evvel a tomeggyartas elkezdese utan abszolut normalis (mas CPU gyartoknal is), hogy annyit tudnak faragni az eredeti die-on, hogy belefer a TDP-be 1-200 MHz clock bump. Ez teszi lehetove pl. az i7-3960X utan az i7-3970X piacra dobasat, a Haswell Refresh-nel is a hasonlo merteku clock bump-ot, stb. A Godavarinal inkabb az a kerdes, hogyan sikerul +10% orajelet kihozni az iGPU-bol, de velhetoen ez is a die optimalizalasanak es a gyartastechnologia melyebb ismeretenek koszonheto.

[ Szerkesztve ]

"a vállalat bizonyos mértékben ki szeretné vonni magát a belépőszintű PC-k piacáról, ugyanis ez a szegmens meglehetősen volatilis, helyette pedig inkább a kiszámíthatóbb közép és csúcskategóriára helyeznék a hangsúlyt"
Ezt így ilyen i3 szintű procikínálattal nehéz lesz, a marketingadatokat legalább maradéktalanul hoznia kell a Zennek hogy ebből valóság legyen.

"az AMD beszélt 2016-ról is, amikor egy újabb GCN architektúra érkezik, aminek kódneve egyelőre ismeretlen. Ez a fejlesztés elsődlegesen a teljesítmény/fogyasztás mutató megkétszerezésére fókuszál"
Magyarul: a 380-as Radeon még mindig radiátor lesz elsősorban? Mondjuk ha már választani kell teljesítmény és fogysztás közt, inkább az előbbire szavazok (legalábbis asztali gépben, mobilban nem), ilyen szempontból jól lépett az AMD.

A VR szemcsik sztem ugyanolyan buzzword lesz mint a 3D, elején jópofa, utána leszoknak róla az emberek. Ma már az se hoz senkit lázba, ha az orra alá finganak 4D-ben.

Az alacsonyszintű API-któl kicsit félek, de félhetnének a gyártók is, az mondjuk nem nagyon segíti elő az eladási mutatókat ha egy GTA szintű játék majd rosszabbul fog futni az új kártyán mint az előzőn. Kicsit más, de ugyanígy nem rohant senki a boltba PS4/X1-ért amikor először csak prevgenre jött a GTA5. 1 évig feleslegesen rakták ki a polcra.

[ Szerkesztve ]

Nehez tarsprocesszorkent tekinteni az IGP-re, amikor nem hogy szoftverek, de me'g benchmarkok sincsenek ra. Pl. --> AMD Kaveri APU: hozott is, meg nem is

Idezet a cikkbol:

"Továbbra sem túl rózsás a helyzet jól használható, valamint mérhető OpenCL alkalmazások terén, így ezen képesség vizsgálatához továbbra is a LuxMarkot használjuk, illetve új tagként debütál az AES EncryptDecrypt nevű kis program."

A vicc az, hogy az AESEncryptDecrypt pedig nem mas, mint egy AMD APP SDK sample program: "Copyright ©2012 Advanced Micro Devices, Inc. All rights reserved." Sz'al azt akár ki is huzhatjuk a kinalatbol, plane mivel le sem fut(ott) Intel iGPU-n, meg ugy altalaban fura otlet egy AMD altal fejlesztett "benchmark" progit hasznalni mas hardveren. Meg mellesleg x86 CPU-kon a hardveresen gyorsitott AES amugy is gyorsabb, mint GPU-kon, sz'al tobb szempontbol is ertelmetlen az AES-t belerangatni egy GPGPU temaba.

Persze ez egy cca. 14 honapos cikk, de sajnos a helyzet azota sem sokat javult, azota se gazolunk terdig a GPGPU szoftverekben vagy epp benchmarkokban.

"Valamiért az AMD elképzelései a GPGPU terén, nem ért össze a marketinggel"

Az AMD marketingjevel nem volt gond, marmint nyomattak a GPGPU-s temat a szoftver fejlesztoknel is, csak azok nem nagyon akartak/akarnak megmozdulni. Az AMD tenyleg megprobalta, de nem sikerult -- egyelore.

[ Szerkesztve ]

"Valamiért az AMD elképzelései a GPGPU terén, nem ért össze a marketinggel, mert ott meg játékteljesítményt demóztak az IGP-k erejével, holott arra nem elég, és sosem lesz elég."

Nem fullon 4xMSAA-val/60 FPS-sel, de elég. Leginkább játékfüggő, régebbi és most is népszerűbb címekhez akár az 1080p@30+FPS medium beállítás sem kizárt (ugye nem is olyan régen még ez is elképzelhetetlennek tűnt...) És ugye a DDR3 jelenleg a legnagyobb limitáló tényező nem maga az iGPU. Jobb memóriával a 20-30k-s VGA piac már most kiváltható lenne IGP-kel. Jobb gyártástechnológiával és mondjuk HBM-mel pár év múlva meg akár az is elképzelhető, hogy csak a csúcskategória maradna...

[ Szerkesztve ]

Autocad-be még azt se oldották meg hogy több magot használjon :'D

hiába van 4-6-8magos proci, max 1et eszik

Kevesebb hangulatjel is elég lesz.

[ Módosította: Oliverda ]

M5A99X-EVO R2.0 , 1050Ti, 4x8GB 1960MHz , FX 8350@4,4GHz, 1x3TB+2x1TB HDD, 120GB+480GB+1TB SSD || HP Pavilion 15-CX0000NH

Vegyük figyelembe, hogy az aktuális termékskálára mennyit költött az nVidia és mennyit költött az AMD. Utóbbi a fejlesztésekre költött pénzt ennyi idő alatt rég vissza tudta forgatni az eladásokból. Hogy az nVidia friss fejlesztését 3x jobban viszik, arról még lehetne vitatkozni, hogy mekkora siker.
A GTX960 elég jól megfoghatónak tűnik a Tonga-val, tehát annak a 300-as reinkarnációja vélhetőleg kellőképp mentes lesz a sávszélesség- és memória mennyiségbeli korlátoktól. Így én annyira a mainstream-et nem féltem. Nyilván a mostani béna verziójától senki nem várhatott komoly eladásokat.

Akkor álljunk meg egy pillanatra és gondolkodjunk. A 800-1000 dolláros árkategória már messze enthusiast vásárlóközönséget takar. Itt igen is vannak Intel és AMD fanboyok és első sorban az AMD-nek nem az Intel hívőinek megszerzése a dolga - hiszen ez borzasztóan sok és felesleges pénzkidobás egy olyan vásárlói kör megszerzése érdekében, amitől a hasonló költségeket igénylő professzionális piacon többszörös hasznot lehet bezsebelni -, hanem az Ő pártjukon állók felbuzdítása a vásárlásra. Ez nem sikerült a FX-9000 procikkal, teljesen érthető módon. Közel azonos teljesítményszint esetén ez egészen másképp is alakulhatna.

Mindenesetre úgy látom egészen másképp látjuk a dolgokat, de ez nem az első eset. Első sorban a Zen-nek a 2016-os útitervet kell teljesítenie, hogy a Broadwell-E procik pályafutásával egy időbe essen az övé.

Végülis nincs túl sok különbség a full-extrás fórumhozzászólások és a blogbejegyzések között. Lehet az egyszerű személyes bejegyzés is, nem csak címlapos írás. Megvan az az előnye, hogy nincs szétszórva és mindegyikhez kapcsolódik saját topik is, ahol ráérősen ki lehet vesézni. Bár én is sokszor utólag jövök rá. Illetve néhány dolog részletesebb leírásának már eleve nem állok neki a fórumban, mert úgy vagyok vele, hogy majd egyszer ott leírom, csak ezt idő hiányában halogatom.

Rendben, de vajon milyen terveket tettek le eléjük a mérnökök? Vélhetően azért folyamodtak ilyen különös megoldáshoz, hogy ezzel próbálják kompenzálni a gyártástech. lemaradást, azaz így próbáltak több teljesítményt kihozni kevesebb tranzisztorból. Ez végülis sikerült, hiszen a 8x50-ek kb. akkorák, mint az Ph2 X6, de sokszálas alkalmazásokban jócskán verik azt, elérve az akkori i7-ek szintjét is, igaz, jóval magasabb fogyasztás mellett.

Sokáig úgy gondoltam egyébként, hogy az - amúgy sovány - int. blokkokat 2x órajelen akarták járatni eredetileg, csak ez nem jött össze, ezért voltak kénytelenek az egész chipet magas órajelen járatni. Meg ugye a decode egység működése sem stimmelt. Állítólag az Intelnek hasonló tervei voltak eredetileg a P4-gyel és talán innen merítették az ötletet, ami egyben azt jelentheti, hogy már akkoriban kezdek neki a Bulldozer uarch fejlesztésének. Vagy ha később, akkor talán azt gondolták, nekik talán sikerül, ami az Intelnek nem. Ez persze csak feltételezés, de az a két ALU int. blokkonként egyszerűen túl kevés.

Nyilván jobb lett volna, ha kapásból egy Zen-féleséggel kezdenek. Egyszer majd talán kiderül, miért nem tették.

"Nem mondtam, hogy az AMD talalta ki/fel a GPGPU-t."

Tudom, be is akartam tenni egy "ugye" szócskát, ezzel jelezve, hogy ezt persze mindketten tudjuk és ez is egy afféle leszögezés, nem utolsó sorban pedig pluszinformáció azoknak, akik még olvassák, talán nem mindenki tudja.

Bizonyos vagyok benne, hogy az ATI beolvasztását az alkalom szülte. A cég komoly gondban volt az R600-assal. Az AMD mérnökeinek segítsége nélkül valószínűleg zátonyra futott volna a dolog, ami könnyen a cég csődjéhez vezetett volna, ezért mentek bele a fúzióba. Még jól is jártak anyagilag a tulajdonosok, vélemények szerint túl sokat is fizetett az ATI-ért az AMD. És ha már megvették, kezdeni kellett vele valamit. Plusz akkorra már érezhették, hogy CPU oldalon elhúz az Intel, így hát előre menekültek, mint már nem először. Ez az előre a GPGPU és a CPU-GPU kooperáció. Csak hát túlzottan megelőzték a korukat. Sokan beleestek már ebbe a "hibába".

Most azt mondták, hogy a CPU a lényeg? Vagy azt, hogy az IS ugyanolyan fontos?

"Az idealis megoldas egy SVM-es eros CPU + eros iGPU paros lenne"

Szerintem a HBM-mel ez is el fog jönni.

A Maxwellel nem vagyok képben, de a 14nm+HBM egyelőre megoldást nyújt. IGP terén sem nevezhető még elavultnak a GCN. Persze előbb-utóbb nyilván lépnek majd, ahogy eddig is.

Szerintem az API-k harca le fog csengeni, ha nem csak egy elméleti vetélkedés lesz, mert rendelkezésre fognak állni megfelelő HW-ek és neki lehet állni dolgozni.

"Az x86 CPU-oldalt is bealdoztak a GPGPU eroltetese miatt."

Nem hiszem, hogy ez szándékos volt. A fentiek fényében egyfajta kényszerpályán voltak.

"Azt hittek, majd az OpenCL meg a HSA megoldja a gyenge CPU problemajat"

Csak remélték, de nyilván tudták, hogy amint lehet, a CPU oldalt is helyre kell rakni.

"a Zambezi tervezese kozben mar azonnal nekiallnak a Zenen dolgozni"

Tudjuk, hogy mikor kezdtek neki? Már tavaly emlegette az AMD a Zent és nyilván akkor már rég nem a kezdeti stádiumban voltak (nem szokás olyan korán felfedni a dolgokat). Évekig tart egy ilyen fejlesztés.

"Vagy piacra sem kellett volna dobni"

Mi lett volna helyette?

"Igen, ez az elmelet."

Több, mint elmélet, hiszen ma sem sok-sok magos CPU-k dolgoznak a 2D/3D grafikán. Mobil vonalon még hangsúlyosabb lesz a dolog!

Tagadhatatlan, hogy az AMD a HSA kezdeményezője és fő fejlesztője, de a SoC-készítők jól felfogott érdeke is, hogy ne csak az ARM legyen a közös nevező. (Sőt, a MIPS-es Imagination is a szövetség részese.)

A Renderscriptről ez olvasható a Wikipedián: "Renderscript is designed to always run on the various Android platforms regardless of hardware type. Its goal is code portability for various architectures and not performance." Szerintem a későbbiekben együtt tud majd élni az OpenCL-lel, kiegészítve egymást. Talán az utóbbival az a baja a Google-nek, hogy nem mindenhol elérhető. A végső megoldást valószínűleg Java GPGPU-s kiegészítése hozza majd el. Akkor majd versenyezhetnek a gyártók, hogy ugyanaz a kód hol fut jobban.

Ut. bek: Persze, tudom, csak most már nem az AMD mérnökei dolgoznak a gyártástech. csiszolgatásán. Bár nyilván kapnak visszajelzéseket és ez alapján ők is végezhetnek kisebb módosításokat, ami egy újabb steppinghez vezet. Mindegy, majd kiderül. Akkor ugye jól gondolom, hogy a Richlandnál a mikrokód változott? (És úgy tűnik, ez valamiféle ROM-ban van, nem flashban, a procin belül.)

u.i. Meg is feledkeztem a Folding@Home-ról, az is nagyon korán elkezdte alkalmazni a GPU-t. Ma már andoidos kliens is van hozzá, bár még csak a CPU-t használja.

(#276): A SANDRA-ban mintha lennének. De az AIDA-ban miért nincsenek?

(#274) Dr. Akula: "A VR szemcsik sztem ugyanolyan buzzword lesz"

Próbáltad már?

"mint a 3D, elején jópofa, utána leszoknak róla az emberek."

Vannak, akik eleve elutasítók (sokszor mert nem képesek hozzászokni vagy térlátási problémáik vannak), vannak, akik számára csak érdekesség és vannak, akik nagyon is kedvelik. Nekem úgy tűnik, az utóbbiak sincsenek olyan kevesen.

(#275) morgyi: Bizony, a tech. újságírók jelentős része is nagyon lassan értette meg, mi a fene az a GPGPU vagy hogy van egyátalán ilyen. (Nem itt a Ph!-n.)

Az, hogy az AMD sem ezt domborította ki, azért volt, mert nem igazán volt mit mutogatni ilyen téren. Viszont a játékok jobban futtak rajta, mint az Inteleken. Csak hát egy valamirevaló, de főleg gamer laptopban evidens a dGPU.

"Vagy ha ezt szeretné valaki, akkor a VGA mellé integráljon CPU-t ne pedig fordítva."

Ez egyelőre nem történt meg, bár lehetett hallani ilyen tervekről, viszont pl. az Nvidia nagy hangsúlyt fektet rá a jövőre tervezett Pascalnál, hogy a ("rendes") CPU könnyen és nagy sebességgel érje el a GPU-hoz tartozó RAM-ot, ami elősegíti a kettő közötti jobb kooperációt.

(#279): Elég furcsa, hogy sok komoly ipari program még a többszálúsításig sem igazán jutott el.

Nem mondanam, hogy egyedul a szettagoltsag a problema. Felsoroltam, hogy mi minden a problema szerintem, es ezek kozul egy a szettagoltsag. Az semmikeppen sem tesz jot, ha mindenki a sajat feje utan megy. Az OpenCL pedig nehezkes, es jol latszik, hogy nem sikerult az iparagat meggyozni arrol, hogy azt hasznalja mindenki. A rengeteg compiler bug, az SVM nelkuli rendszereknel a memoria masolgatas, a hosszas inicializalasi sallangok mind azt okozzak, hogy ha bele is akar kezdeni az ember, hamar elmegy a kedve az egesztol. Amikor egy fejleszto hozza van szokva ahhoz, hogy szokoevente egyszer (se) talalkozik a VCC-ben, GCC-ben, ICC-ben (stb, tehat egy akarmelyik klasszikus C --> x86 vagy ARM compilerben) compiler buggal, akkor nagyon idegesito az, amikor egy tok egyszeru OpenCL kerneltol elhasal az X gyarto OpenCL compilere. Erre az igeretek szerint megoldast nyujthat (majd, valamikor) a HSA, csak ugye a HSA-val (+ SVM) kellett volna az egeszet elkezdeni, es akkor -- talan -- ma nem itt tartana a GPGPU.

Ne erts felre, en nem mondom, hogy az nVIDIA 3x jobb GPU-t gyart, mint az AMD. Csupan azt mondom, hogy a piac jelenleg azt mutatja, hogy 3x kelendobbek az nVIDIA GPU-k. Ez nem segit az AMD-nek, plane azok utan, hogy eleg sok penzt beleraktak az ATI-ba anno. Es mellesleg ez a pelda is mutatja az, hogy mennyire fontos a kiralykategoria hazon belul tudasa: ha elveszited a leggyorsabb GPU vagy leggyorsabb CPU cimet, az alsobb kategoriakban is sokkal nehezebb lesz eladni az amugy adott esetben versenykepes termekeidet is. Az nVIDIA a Titan szeriaval pont az biztositja, hogy ove maradhasson a teljesitmenybeli korona, es onnantol az AMD dolga me'g nehezebb a megfizetheto GPU-k eladasaval is. Az semmit nem szamit, hogy a Titanbol csak par ezer db kel el, a cim, a tron, a brand a lenyeg. Az meg a piacot egy egesz kicsit sem erdekli, hogy mennyi penzbe kerul valamit kifejleszteni. Nincs az a vasarlo, aki ilyen alapon valasztana. Ar/teljesitmeny az mas teszta, az alapjan sokan valasztanak, de nem a fejlesztesi koltseg alapjan.

Es erre rakotve, az egy dolog, hogy maskepp latjuk a dolgokat, az rendben van. Az a nagyobbik baj, hogy Te kicsit irrealisan tekintesz a 800-1000 dollaros CPU-k piacara, ill. azok vasarloira. Azt gondolod, hogy aki ennyi penzt kolt procira, az rajongasbol teszi ezt. Hat nem. Akinek ennyi penze van procira, _es_ hajlando is procira kolteni, az egesz egyszeruen a leggyorsabb CPU-t akarja a PC-jeben tudni. Ilyen egyszeru. Ha az AMD hirtelen letenne az asztalra ma egy 5960X-nel erosebb CPU-t, rengeteg altalad Intel hivonek gondolt Sandy Bridge-E/Ivy Bridge-E/Haswell-E tulajdonos fogna a PC-jet, kivagna belole az alaplap+CPU-t, es beujitana egy zsir uj Zen konfigot. Akinek van ennyi penze es hajlandosaga is ilyen sok penzt kolteni egyetlen nyavalyas CPU-ra, az lesz*rja a markanevet, az egyszeruen csak a legjobbat akarja, akarki is adja neki. Gondold csak meg, mennyi mindent kaphatsz egyetlen ilyen CPU arabol. Egy csucskategorias Apple tablet 700 dollar, me'g az sincs 800-1000 dollar. Egy MacBook Air alapmodell -- ami alapmodell dacara sem egy low-end masina -- kompletten 900-1000 dollar. Komplett tabletet vagy ultrabookot kapsz egyetlen HEDT proci araert. Aki pedig megis CPU-t vesz, az nem fogja a 2. legjobbat venni ennyi penzert. Suta parhuzam, de nem hagyhatom ki: ha 10 eve egyutt vacsorazhattal volna az Apollo 11 legenysegenek egyetlen tagjaval, kit valasztottal volna? Ugye hogy Neil Armstrongot

Arrol nem is beszelve, hogy ha az AMD-nek nem sikerul ujra a leggyorsabb desktop procit letennie az asztalra, akkor tovabbra is szenvedni fog az alsobb kategoriakban is. Az AMD viragzasa akkor valosult meg, amikor ketseg nem ferhetett ahhoz, hogy teljesitmenyben (is) a legjobbat kinalta az x86 desktop CPU-k piacan. Sot, a szerver piacon is akkor indult be a szeker az Opteronnal, amikor egyertelmuen gyorsabb volt, mint a Xeonok. Egyszeruen muszaj a kiralykategoriat elhoditani, kerul amibe kerul, kulonben tovabbra is menni fog a vergodes az APU-k piacan Nem veletlenul probalkozott be az AMD az FX-9590-nel sem: ugyanez a cel vezerelte oket, csak ugye ott mission impossible volt valoban meghoditani a HEDT-t. De arra boven jo volt, hogy egy kis buzz-t generalt a ceg korul. Jovore viszont nem buzz kell, hanem valodi eredmenyek.

Kivancsi lennek egyebkent, hogy mi alapjan gondolod valakirol azt, hogy Intel vagy AMD fanboy. Ha pl. valakinek a Conroe ota csak Intel procijai vannak a gepeben, de minden valtasnal felmerul benne, hogy AMD-re alljon at, de mindig elmegy a kedve tole, mert teljesitmenyben nem kapna elegendot a zoldektol, az Intel fanboy? Vagy ha nem, akkor mi kell ahhoz, hogy valaki fanboy legyen? Hogy fel se meruljon az AMD mint otlet? Ha me'g igy is lenne, marmint nyilvan sokan vannak igy, szerinted nem lehet az ilyen gondolkodasmodnak, berogzulesnek fokent inkabb az az oka, hogy a media mar hosszu evek ota masrol sem szol, mint hogy jon egy uj AMD CPU vagy APU, es hogy jo-jo meg jo ara van, de egyszeruen lassabb, mint amit az Intel kinal? Az AMD a 90-es evekben eljutott oda, hogy az emberek agyaba beegett az, hogy az Intel a draga es gyors proci, az AMD az olcso(bb) es lassu/lassabb proci. Ezt sikerult eloszor az Athlonnal kicsit megvaltoztatnia az AMD-nek, majd az Athlon 64-gyel egyertelmuen megvaltoztatnia. Aztan az egesz ment a levesbe, es mára visszajutott az AMD oda, ahol a 90-es evekben volt. Megint az van az emberek agyába égve, hogy az Intel a draga es gyors proci, az AMD az olcso(bb) es lassu/lassabb proci. Ezt az Athlon/Athlon 64-gyel ugy sikerult anno megvaltoztatni, hogy letettek az asztalra egy vitan felul leggyorsabb desktop procit. Ujra sikerulhet ezt megtenniuk, de ahhoz megint kell egy vitan felul leggyorsabb desktop proci. A masodik legjobb nem lesz eleg, mint ahogy anno a 90-es evekben sem volt eleg.

"Rendben, de vajon milyen terveket tettek le eléjük a mérnökök?"

Valoszinuleg egy rosszat es egy me'g rosszabbat, es a legkevesbe rosszat valasztottak. Maskepp elkepzelesem sincs, miert bolintottak volna ra a Bulldozerre.

"Ez végülis sikerült, hiszen a 8x50-ek kb. akkorák, mint az Ph2 X6, de sokszálas alkalmazásokban jócskán verik azt, elérve az akkori i7-ek szintjét is, igaz, jóval magasabb fogyasztás mellett."

Ize, szerintem meretben es tranyo szamban a Zambezit nem a Phenom II X6-hoz, hanem inkabb a Sandy Bridge-hez kellene hasonlitani. Nagyjabol a Sandy Bridge i5 es i7 kozotti teljesitmenyt hozta anno az elso Zambezi, mikozben igy nezett ki tranyoszamban es die meretben a ket proci:

Zambezi: 1200M / 315 mm2
Sandy Bridge: 1160M / 216 mm2

Csak ugye ne felejtsuk el, hogy a Sandy Bridge-nel a joval kisebb die es nemileg kevesebb tranyoban me'g az iGPU is benne volt! Ez alapjan pedig jol lathato, hogy mennyire rossz volt mar az elso Bulldozer is. Se teljesitmenyben, se die meretben, se tranyo szamban nem volt versenykepes

"Csak hát túlzottan megelőzték a korukat."

Hat ezaz. Lehet elore menekulni, a jovot epitgetni, a kovetkezo evtized technologiajan dolgozni, de nem szabad(na) kozben elhanyagolni a jelenben felmutatott teljesitmenyt sem. Az Intel procik kapcsan is ki lenne mindenki borulva, ha mondjuk az AVX-512 tamogatas oltaran felaldoznanak a 4 magbol 1-et a Cannonlake-nel, es igy kisebb teljesitmenyt kapna a juzer. Hiaba mondana az Intel azt, hogy "Majd figyeljetek meg, mekkorat lep a Cannonlake, ha lesznek AVX-512 gyorsitott szoftverek". Na, az AMD pont ezt csinalta az utobbi X evben, es jol lathato, hova jutottak ezzel a hozzaallassal

"Most azt mondták, hogy a CPU a lényeg? Vagy azt, hogy az IS ugyanolyan fontos?"

En ugy altalaban az egesz eloadas eszenciajara gondolok, amikor azt mondom, hogy most lathatoan mas kerult fokuszba. Nyilvan nem fogjak azt mondani, hogy a GPGPU, a HSA vagy epp az eros iGPU innentol nem szamit, hiszen azzal sajat magukat is szembekopnek. De az eloadas uzenete -- szamomra legalabbis -- egyertelmuen annak tunt, hogy az x86 teljesitmenyen dolgoznak ezerrel, hogy abban oriasit lepnek elore jovore. Vegre nem az igergetes megy az API-krol meg GPGPU-rol, hanem ismet kompetitiv x86 teljesitmenyt akarnak letenni az asztalra. Az lenne a non-plusz ultra, ha amellé még egy eros, HSA 1.0 compliant iGPU-t is tudnanak adni, ez egyertelmu. Es ha a Zen maga jol sikerul, akkor nincs is semmi akadalya egy ilyen mindent-vero APU-nak. Mas kerdes, hogy TDP tekinteteben hogyan fog alakulni a helyzet, de a Zen elvileg abban a tekintetben is kompetitiv lesz.

"Szerintem a HBM-mel ez is el fog jönni."

Marmint mire akarod a HBM-et hasznalni? Mert ugye megosztott (unified) rendszermemorianak nem tudod hasznalni, legalabbis az AMD legutolso ilyen jellegu probalkozasa (Kaveri + GDDR5) sem jott mar be. Miert pont most tudnak meggyozni a piacot arrol, hogy DDR4 helyett HBM-et hasznaljanak a PC-s alaplapokon? Ha pedig near memory vagy L4 cache-szeru megoldasra gondolsz, akkor az elvileg nem mukodhet olyan jol osszessegeben, mint az Intel eDRAM-ja, hiszen a GCN nem tamaszkodik annyira a gyors cache-ekre, hanem sokkal inkabb a memoria savszelesseg a lenyeg. Abbol pedig eros korlatok koze szoritja magat az AMD, ha dual channel DDR4-et hasznal az APU-khoz. Egy bizonyos magszam (iGPU CU) felett az ugyanugy nem fog skalazodni, mint ha egy Kaveriba raknal 16 db CU-t. Amig az AMD vagy epp az Intel nem tud brutalis memoria savszelesseget pakolni az iGPU-k ala, addig nehezen tudjak azok befogni a dGPU-kat.

"A Maxwellel nem vagyok képben, de a 14nm+HBM egyelőre megoldást nyújt."

En ugy tudom, a Fiji me'g 28 nanon fog keszulni, de mar HBM-et hasznal. Tehat az "egyelőre megoldást nyújt" inkabb jovo ido kellene hogy legyen, a 14 nano okan

"Szerintem az API-k harca le fog csengeni"

Melyik API-ra gondolsz? GPGPU vagy low-level grafika? De akarmelyikre is gondolsz, az API-k harca csak akkor tudna lecsengeni, ha vagy kihalna az API-k fele, vagy egy adott hardver mindent tamogatna _rendesen_. Sajnos egyikre sincs sok esely, foleg ha beleveszed a kepbe az ultramobil szegmenst is

"Nem hiszem, hogy ez szándékos volt. A fentiek fényében egyfajta kényszerpályán voltak."

Ugyan... A Zambezi szimulatorbeli elso tesztjei ota eltelt mennyi ido is? Legyen csak 5 ev, joindulattal, bar inkabb 6 ev lehet az inkabb. Annyi ido alatt mar boven nekilathattak volna barmikor palyat modositani. Rengeteg penzt, idot es energiat oltek a GPGPU temaba: ha annak csak a felét mashova allokaljak az utobbi 3 evben, ma mar piacon lehetne a Zen.

"Tudjuk, hogy mikor kezdtek neki?"

2013 nyaran me'g szo nem volt a Zenrol, amikor az AMD-vel (eloben) beszelgettem. 1 evvel kesobb, 2014 nyaran viszont mar dicsekedtek vele, hogy elkezdtek a fejlesztest, egyelore me'g korai szakaszban vannak, me'g a szimulatorban sem mukodik a cucc. 2014 nyaran mar konkretan Zenkent hivatkoztak ra. Ergo valamikor 2014-ben kezdodhetett el a fejlesztes, vagy a nagyon korai szakasz esetleg 2013 kozepe-vege tajan. De akarhogy is, nem azt kell nezni, hogy mikor kezdenek neki, hanem hogy 2 termek piacra dobasa kozott mennyi ido telik el. Hiszen a Bulldozert is X evig fejlesztettek, mire piacra kerult, ugyanugy a Zent is. Viszont ha a piacra kerules kozott van mondjuk 5 ev, akkor durva becslessel, hunyoritva lehet 5 ev a fejlesztesek megkezdese kozott is. Ergo 5 evet vartak arra, hogy a GPGPU-val eljussanak valahova, 5 evig tokoltek. Ez az en olvasatomban legfeljebb akkor lett volna elfogadhato vagy "oke", ha az eredeti architektura lenyegesen jobban sikerult volna. Egy eleve nem versenykepes architektura utodat ennel sokkal hamarabb el kellett volna kezdeni fejleszteni.

"Mi lett volna helyette?"

6 vagy 8 magos Llano, iGPU nelkul. Ne mondd, hogy az annyival rosszabb lett volna, mint a Zambezi. Es legalabb lett volna lehetoseguk azonnal dolgozni az utodon, nem vesztegettek volna el 5 evet, es nem alltak volna neki sok olyan Bulldozer alapu projektnek, ami utana amugy sem kerult piacra. A piacra kerult Zambezi, Trinity, Vishera, Richland, Kaveri, Carrizo-n felul a kukaban vegezte a Komodo, a Sepang, Macau, Terramar, Dublin, az eredeti Richland (masnak indult, mint ami lett belole), az eredeti Kaveri (ami piacra kerult, az a Kaveri 2.0). Ezek mind-mind rengeteg penzt es idot vittek el, ehelyett gondolom azt, hogy sokkal jobb otlet lett volna massal foglalkozni (Zen).

"Akkor ugye jól gondolom, hogy a Richlandnál a mikrokód változott?"

A Richlandnel sokkal tobb valtozas volt a Trinityhez kepest, mint amit a Godavari tartalmaz. A Richlandnel pl. a CPB (Turbo) viselkedesen, mukodesen is valtoztattak, fejlesztettek. Ami aztan a Kaveriba nem is kerult be, sz'al ezek "erdekes" dolgok

"A SANDRA-ban mintha lennének. De az AIDA-ban miért nincsenek?"

Marmint mi nincs az AIDA64-ben? OpenCL GPGPU benchmarkbol eleg sok van benne, 12 metodus. Raadasul direkt a mar letezo (x86/x64/MMX/SSE/AVX/AVX2/FMA/XOP-rol) CPU benchmarkokat portoltuk GPGPU-ra, hogy direktben ossze lehessen hasonlitani a GPU es CPU teljesitmenyet. A Kaveri piaci rajtjanal mar piacon volt a sajat GPGPU benchmark megoldasunk. Az megint mas kerdes, hogy melyik ujsagiro akarta ezt hasznalni a Kaveri tesztelesehez.

Nyilván még nem, de a 3D mániából kiindulva ez a csoda is 3 napig fog tartani. A google glassos felhasználási módot sokkal életképesebbnek tartom (mész az utcán és infokat közöl ahhoz amit látsz, mondjuk bolt vagy moziműsor), de azt meg kb. betiltották.

Nem azt mondtam, hogy a vásárlókat kéne, hogy érdekelje, hanem a befektetőket, akik az egészből most annyit látnak, hogy az AMD két év HEDT fejlesztés nélkül is egy gond nélkül választható alternatíva a piacon. Teljes GPU piaci részesedésben az AMD-re még mindig nagyobb veszélyt jelent az Intel, mint az nVida. Ezt meg ugye az aktuális X86 teljesítménynek köszönhetik, nem a Radeonok csúcstartó hiányában 'állítólagosan' kialakult hírnevének.

Hogy irreálisan látom a piacot, az nem kizárt, elvégre nem vagyok szakértő és eleve egyre kevesebbet foglalkozok az itteni folyamatokkal. Viszont a fentebb leírt véleményemet nem a levegőből kapkodtam össze, hanem tapasztalatok alapján írtam, amiket meg a xtremesystems és társai látogatásával szereztem. Vannak olyan emberek, akik ebben a kategóriában is érzelmek nélkül nyúlnak a pénztárcájukhoz, de ezeknek az embereknek meg elég annyi, ha az Intel se tud egyértelműen első maradni és máris a választás se lesz egyértelmű.

Viszont átgondolva, amiért a specifikációk alapján irreális a 800-1000 dolcsis sáv, mégha a teljesítmény esetleg engedné is, az a PCIE sávok száma GPU irányba. Mivel megálltak 16-nál, míg ugye LGA2011v3-on 24-38 közt változik, függően attól, hogy melyik processzort választod. Szóval tényleg reálisabb, hogy amennyiben esetleg a LGA105x-es zászlóshajót sikerül lepofozni, akkor a csúcs képviselőt esetleg belövik $400-450 környékére.

Amúgy AMD fanboynak azokat tartom a HEDT kategóriában, akik még a mai napig is AMD cuccokra alapoznak kemény gépeket (rendre FX-9 vagy széttuningolt FX-8 + 980 vagy 780Ti SLI, stb - számomra is meglepő mennyi ilyennel össze lehet futni fórumokon). Az Intelen való ragadást Conroe óta annyira tartom Intel fanboyságnak, hogy amennyiben nudli lesz a Zen, valószínűleg én is szemrebbenés nélkül fogok váltani. (Mert onnantól válik véglegesen világossá, hogy hiába a szimpatikus koncepció, ha nem képesek az előnyeit a valóéletbe átültetni. Aktuálisan van még némi bizodalmam a Fusion-ben.)

(#283) Peat: A fogyasztás/teljesítmény az architektúrából adódik. Az nVidia ebben nagyobbat tudott húzni, mert a mostani szériát nem kell egyszerre a professzionális piacon is tartaniuk, ellenben az AMD-vel. A Tonga esetén elég volna annyi, ha kiderülne, hogy aktuális formában nagyon durván vissza volt fogva. Erre meg emlékeim szerint a mobil verziókkal összehasonlítva még esély is van.

[ Szerkesztve ]

"inkabb a Sandy Bridge-hez kellene hasonlitani"

Igaz, de az AMD nem tudhatta évekre előre, hogy akkor pontosan mi lesz Intel oldalon. Ne feledkezzünk meg az SB 1 MB L2-jéről sem, szemben a BD 8 MB-jával, ez sem kevés helyet foglal. Pusztán a CPU magokat véve kb. egyforma területet foglalnak. És pár sokszálas alkalmazásban teljesítményben is egálban voltak (8150 vs. 2600K). Az egy-/kevésszálas teljesítmény és a fogyasztás hibádzott, ami persze el is döntötte a meccset.

"Na, az AMD pont ezt csinalta az utobbi X evben"

Ez a látszat, de ha megnézzük a dolgok hátterét (éppen ezt tettem), rájöhetünk, hogy nem egészen így van. Nem kellene őket teljesen hülyének nézni.

"az x86 teljesitmenyen dolgoznak ezerrel"

Ehhez azért nem volt szükségük valami hatalmas revelációra, évek óta nyilvánvaló, hogy szükség van egy új uarchra, csak ez náluk nem egészen úgy megy, mint az Intelnél, hogy egy 2. vagy 3. csapat kezd el dolgozni rajta, miközben az aktuális dolgokkal is foglalkozni kell.

"Marmint mire akarod a HBM-et hasznalni?"

Hát erre, csak a GPU helyén egy APU-val. Így lehet unified, egyszerűsödik az alaplap és az utóbbi gyártóit sem kell győzködni. Miért ne működhetne olyan jól, mint az Intel eDRAM-ja? Persze, hogy mikor lesz ilyen, azt nem tudom.

"En ugy tudom, a Fiji me'g 28 nanon fog keszulni, de mar HBM-et hasznal."

És szerinted a 4096-bites memóriabusz (128~256 GB/s) nem hoz némi teljesítménytöbbletet, egy új verziójú GCN chip társaságában? Jövőre meg jöhet a 14(/16)nm.

A GPGPU-s API-kra gondoltam. Szerintem a Carrizo és főleg a jövőre érkező asztali APU már használható cuccok lesznek. És úgy tűnik, okosteló/tablet vonalra is kezdenek érkezni a HSA alapú chipek.

"2013 nyaran me'g szo nem volt a Zenrol"

Vagy csak nem kötötték az orrodra.

"valamikor 2014-ben kezdodhetett el a fejlesztes, vagy a nagyon korai szakasz esetleg 2013 kozepe-vege tajan"

2-2,5 év alatt 0-ról kész termékké egy új uarch?

"Ergo 5 evet vartak arra, hogy a GPGPU-val eljussanak valahova, 5 evig tokoltek."

Ha 2010-ben volt a BD tapeout-ja, akkor is max. 4 évet tököltek (volna), ha a Zent tényleg csak 2014-ben kezdték el. De ez is csak akkor áll, ha feltételezzük, hogy kapásból neki tudtak volna állni az új fejlesztésének, ha akarnak, amin a BD elkészült. Az Intel megteheti, mert legalább két csapat dolgozik ezen, egymást váltogatva (~fél időben az új uarcht fejlesztve, ~fél időben pedig shrinket és egyéb finomításokat végrehajtva), az AMD-nél ugyanaz a csapat végzi a kettőt, de legalábbis nincs kapacitás két fejlesztés teljesen párhuzamos futtatására. Azt pedig nem tehették meg, hogy leállnak a Bulldozernél és több évig azt nyomják, amíg el nem készül a Zen.

"6 vagy 8 magos Llano, iGPU nelkul."

Minimális különbség van a Deneb/Thuban és a Llano CPU magjai között és a Llano L3-mal sem rendelkezett, így lényegében egy Athlon II-nek felelt meg CPU oldalról. Sőt, ki is jött néhány Llano alapú, letiltott IGP-vel rendelkező proci Athlon II brand alatt (X4 651/641/638/631). Szóval, a 6-magosod egy Athlon II X6 lett volna. A 8-magosban talán lett volna ráció, de nem tudom, hogy hogy szerepelt volna L3 nélkül, azzal pedig már elég nagy lett volna.

Ja, már emlékszem, kitűzött cél, hogy csak hétköznapi programokkal vagy azok bechmarkosított változatával (pl. CineBench) tesztelnek. No de a (szinte) semminél azért csak jobb egy szintetikus teszt, főleg, ha az csak "félig" szintetikus (nem belső sávszéleket mérő tesztek, hanem hétköznapi programokban is előfoduló feladatok). De amúgy lehet valahol nézni AIDA64(/SANDRA)-(e)s GPGPU-s összehasonlításokat APU vonalon (Intel is)?

(#287) Dr. Akula: Én már igen, és ez alapján nem egészen így gondolom. Sőt, inkább attól félek, hogy jóval nagyobb függőséget képes okozni, mint a megszokott forma.

Látom, félálomban megfeledkeztem róla, hogy a Llano már 32nm-es volt, miközben a Deneb/Thuban még 45, így valószínűleg kivitelezhető lett volna akár L3-mal is a 8 mag. Most nem tudok utánaszámolni a méreteknek. Annak is utána kellene nézni, milyen órajeleket tudott elérni a Llano a maga 32nm-ével. Lehet, itt volt a gond. Vagy talán úgy voltak vele, hogy még ha ez így nem is rossz, nem tudnak már vele továbblépni, miközben a Bulldozer, még ha nem is olyan jó, de továbbfejleszthető és úgy már jó lesz. Jobb is lett, csak lassan és nem eléggé. De ennyire nem lehet mindent előre látni, erre szoktak panaszkodni a chiptervezők.

Közben rábukkantam Oliverda nemrégi cikkére, amiben ez olvasható:
"[...] nem is csoda, hogy néhány éve kvázi nulláról egy teljesen új x86-os koncepció kidolgozásába fogott az AMD. A vállalat ehhez 2011-ben műszaki igazgatónak szerződtette a processzorguruként emlegetett Mark Papermastert, majd alig egy évvel később egy újabb gurut, Jim Kellert csábították vissza a sikeres Apple processzorok tervezőasztala mellől."

Azaz, még a Bulldozer kiadási évében szerződtették Papermastert, aki vélhetően el is kezdett dolgozni egy stábbal az új uarch alapjain, valamivel később pedig Jim Keller is beszállt a "buliba"... Tehát, nem volt itt töketlenkedés, csak hát egy vadi új uarchhoz idő kell.

(Tavaly olvastam is Kellerrel egy rövid interjút, amiben beszámolt a fejlesztésről és hogy csinálják már egy ideje, bár mintha konkrétumokat még nem mondott volna.)

Érdeklődéssel olvasom az eszmecseréteket...

Egy apróbb hozzászólás:

"igy nezett ki tranyoszamban es die meretben a ket proci:
Zambezi: 1200M / 315 mm2
Sandy Bridge: 1160M / 216 mm2
Csak ugye ne felejtsuk el, hogy a Sandy Bridge-nel a joval kisebb die es nemileg kevesebb tranyoban me'g az iGPU is benne volt!"

Ha jól emlékszem, a magok méretéről ezek az információk jöttek:
1 Sandy Bridge mag 18,4 mm2; + 2 MiB L3 29,5 mm2
1 Bulldozer modul 18,0 mm2; + 2 MiB L2 30,9 mm2
Mi a bánattól lett végül 100 mm2-rel nagyobb a Zambezi lapka, ha a magok/modulok mérete hasonló, ugyanannyi volt belőlük a lapkán (4), ráadásul a SB-ben volt IGP is?

Ja, persze, megvan: az Zambezin (Bulldozer) volt L3 cache is, méghozzá szintén 8 MB a négy modulhoz.
Az APU kiviteleken (Trinity, Kaveri) nem volt L3.

dezz
"a Llano már 32nm-es volt, miközben a Deneb/Thuban még 45, így valószínűleg kivitelezhető lett volna akár L3-mal is a 8 mag. Most nem tudok utánaszámolni a méreteknek."
A Llano-ban egy mag 9,7 mm2; két mag és a hozzá tartozó 2 MB L2 pedig 32 mm2. A Bullhoz hasonló értékek ezek - valószínűleg kivitelezhető lett volna.

[ Szerkesztve ]

Az Orochi valós tranzisztorszáma ~2 milliárd.

"még a Bulldozer kiadási évében szerződtették Papermastert, aki vélhetően el is kezdett dolgozni egy stábbal az új uarch alapjain, valamivel később pedig Jim Keller is beszállt a "buliba"... Tehát, nem volt itt töketlenkedés, csak hát egy vadi új uarchhoz idő kell."

Pont ezt akartam én is írni.
Valószínűleg már a Bulldozer szimulátorbeli eredmények láttán elkezdtek leizzadni a mérnökök, de még bíztak az órajelekben. Aztán a rossz kihozatal és a katasztrofális szivárgás láttán maradék reményeik is elszálltak, és -innentől feltételezés- azonnal elkezdtek mentőöv után kapkodni. Így még abban az évben leigazolták Papermastert, de Kellert csak a következő évben, mert még volt egy kis dolga a az A7-tel.
Nyilván velük kezdődött meg a Zen tervezése, onnantól 2016/17 fordulója öt év, annyi idő kell is a nulláról való újratervezéstől a forgalomba kerülésig. 2013-ban még nem nagyon lehetett mit mondaniuk a készülő új mikroarchitektúráról.

[ Szerkesztve ]

Én azonnal vennék egy full amd pc-t ha jól sikerülne...
csak úgy miért ne alapon, meg ha olcsóbb lenne (ami valószínű az lenne mint az intel)

Csak kár hogy köv év elejére semmi se lesz belőle, majd max az új vga-kat akkor már ki bírom próbálni, mert tervezem év végén eladni a pc-m aztán egy újat össze rakni 4-500 ból

[ Szerkesztve ]

Az élet olyan mint a motor, ha nem megy akkor be kell rúgni..

A Sandy Bridge-ben is van 8 MB L3. A (a cellánként több tranyót használó) L2-ben van nagy eltérés: 1 MB (SB) vs. 8 MB (DB). Nem elhanyagolható a Hypertransport portok területe sem, amiből a desktop változatnál 4-ből 3 le van tiltva, de a helyet attól még foglalja.

Így van!
A #293-asban a SB-nél hozzászámoltam magok méretéhez az L2-t, a Bull-nál nem - szép nagy az L2 cache, de legalább lassú...

Hasonló adatokat "közöltem" jómagam is annó a néhai Bulldozer (most már Carrizo, stb.) topikban egy hasonló eszmecserében, de lusta voltam rákeresni. [*]

Nem lett volna ez olyan rossz, ha kapásból a Steamrollerrel jönnek ki (korábban kezdve a fejlesztést, más által nem akadályoztatva). Majd köv. évben shrink 22nm-re (Intel által bérgyártva [*] ), majd Excavator, majd újabb shrink, majd Zen. Mint ahogy az Intel csinálja titokban, izé, Tick-Tock-ban. [*] Vagy akár az Excavator shrinkjét kihagyva, ahogy most csinálja az AMD (úgy tűnik, az Excavator egyszeri 28nm-es jelenség lesz).

* =

(#297) morgyi: Szerintem a korábbi perek után ezt most nem mernék/merik majd megtenni.

[ Szerkesztve ]

Majd amikor már az AMD csődbe ment majd lehet, hogy kapnak valami büntikécskét, ami azt kiszabó szervek zsebébe megy. Ami ugye az AMD-n már nem fog segíteni. Meg a felhasználókon sem akiknek már csak jól felülárazott monopol procik elérhetők, és nem is jutottak hozzá jobb ár érték arányú AMD procikhoz amikor még lehetséges volt az Intel elnyomása miatt.

Tudni esetleg, hogy lesz-e R9 APUs procijuk?
Ahogy olvasom, mégiscsak ugyanaz az APU lesz ezekben is,mint ami az A10-esekben van

eladók: Hifiman HE560V3, Topping DX3PRO+ DX7PRO