- iPhone topik
- Fotók, videók mobillal
- Telekom mobilszolgáltatások
- Samsung Galaxy S20 és S20+ duplateszt
- Megjelent a Poco F7, eurós ára is van már
- Brutál akkuval érkeztek az Ulefone X16 modellek
- Samsung Galaxy S24 - nos, Exynos
- Motorola Edge 60 és Edge 60 Pro - és a vas?
- Xiaomi 15 - kicsi telefon nagy energiával
- 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
-
leviske
veterán
A pletykák szerint a Warsaw egy HDL-es "próba", nem? Mert ha annak ellenére is tudnának szerverekben órajelet emelni, akkor a desktop verziókkal a mostaniakkal azonos fogyasztás mellett elég szépen tudnának egyet ugrani.
Más kérdés, hogy amennyiben az APU-k játékokban nem CPU+iGPU, hanem "bővítettCPU" formában lesznek kihasználva, akkor elég skizofrén hozzáállás volna még AM3+ foglalatos processzorokkal is bővíteni a kínlatot.
-
#13406
Ricsiii1992
tag
Fiery
#13405
Ricsiii1992
tag
Steamroller -es fx-re gondoltam (keverem már ezt a sok nevet)
Azért reméltem hogy lesz valami újdonság AM3+ba is; de akkor úgy tűnik nemigazán.Ha nem is több mag, de akkor az a 4 mehetne magasabb frekin, szerintem az a +25W már nem számítana, inkább a tesztekben elért szebb eredmény. Akinek meg számít, az venne 100W-osat alacsonyabb frekivel.
A 140W-ot is száműzték AM3-nál, csak a C2-es Phenom 965 volt annyi, szinte az összes lap tudja a 140-es TDP-t, kijöhetett volna annó a 8150 is pl 140W-tal 3.6 helyett 3.8-4GHz-en , vagy a 8350 4.2 körül. És ez mégse 220W tdp, mint a...
-
Valdez
őstag
Valami turpisság kell legyen akkor, mert így alig lesz előrelépés a 6800k-hoz képest. Tegyük fel jóindulattal a cpu rész egál (de ha tényleg sokkal kisebb az órajel, akkor még lassabb is lesz), a gpu rész meg alig lesz gyorsabb, mert hiába a 8 cu, ha lényegesen alacsonyabb órajelen megy. Ebből így nagy bukta lesz. Vagy mégis lesz benne 13 cu
-
-
dezz
nagyúr
A Ritchland lényegében egy javított Trinity, magasabb órajelekkel. De amúgy mindkettő a már bejáratott 32nm-t használta. Azonban az AMD többször eljátszotta, hogy új uarc-ot új node-on hozott ki, először alacsonyabb, majd egyre magasabb órajeleken. Van is egy kifejezésük a folyamatos gyártástechnológiai finomítások (most már persze nem házon belül, hanem kooperációban) módszerére, de most nem jut az eszembe.
-
Abu85
HÁZIGAZDA
Ott vannak a szoftverpartnereknél. Adobe, Cyberlink, EA, Sony, Corel, Arcsoft, MulticoreWare, eyeSight, Nuance, Mixamo, Fabric Engine, Oracle, ParStream. Ennyiről tudok. Ők mind írják a szoftvereket. Nekik már most van fejlesztőkörnyezetük ehhez, és a végleges speckókat is megkapták, amit idén elfogadnak, már csak a végső szavazás van hátra.
Jó, hát ha az emberek P4-Conroe váltáshoz szoktak hozzá, akkor a következő években is baromira csalódni fognak. Ezzel nem kell foglalkozni.
(#13370) Fiery: Most fejlődött a legtöbbet a belső north bridge-IMC. Muszáj volt, mert teljesen át kellett alakítani a működését, hiszen mostantól az IGP is ugyanazt a memory poolt használja, amit a CPU.
-
dezz
nagyúr
"Oke, kicsit faragnak az L1 data cache-en meg az L2 cache-en, de a CPU magok alapvetoen nem valtoznak"
Szerintem kellőképpen nagy változás a modulonkénti 1db utasításdekóder helyetti 2db utasításdekóder, főleg, hogy a korábbiaknál ez volt az egyik, ha nem a legfőbb szűk keresztmetszet... Lásd 20-60% gyorsulás (2 INT mag/modul)*2 + 4 szál vs. (1 INT mag/modul)*4 + 4 szál. (Nyilván a cache-kezelés is beleszólt ebbe, ami most szintén javult.)
"amikor a Haswellnel nincs elorelepes az Ivy Bridge-hez kepest (CPU orajelben es -teljesitmenyben), viszont iGPU-ban eleg szepen lepked elore az Intel, akkor megy a karogas, hogy megallt a fejlodes, nem gyorsult a CPU, nincs magasabb orajel, stb."
Ez nem károgás, pusztán egy technológiai körülmény. Az órajeleket egyre nehezebb növelni, a CPU magok számát sem érdemes már nagyon növelni, mert sokkal hatékonyabb megoldás az IGP-re gyúrni. (Ebben komolyabb változást a szilícium nyugdíjazása hozhat majd.) [Hacsak nem vezetik be általánosan a kompresszoros vagy folyékony nitrogénes/stb. hűtést, ami nem valószínű - hiába megy valami a laborban -200 fokon 10GHz-en, ha a hétköznapokban nem kivitelezhető.]
-
#24650752
törölt tag
Tudom, de mégis lehangoló ezeket olyantól hallani, akinek a kezében ott egy ES.
(#13365) Bici: a Bulldozerhez volt szerencsém. Bennem már akkor felmerült a kérdés, hogy mi van, ha nagyobb lesz ennek az egésznek a füstje, mint a lángja? Ha jól rémlik, akkor pont Fiery volt az, aki ennek hangot is adott itt a fórumon. Mondjuk ki, sajnos, bejött. Onnantól kezdve abszolút nincsenek nagy elvárásaim ezzel szemben. Viszont az, hogy legalább a Richland órajeleit tartsák, vagy csak minimális mértékben csökkentsék (nem pediglen _jelentősen_, ahogyan írja), az szerintem távolról sem nevezhető túlzónak. Emellett azért remélem, téved.
-
Oliverda
titán
Ezzel indult az eszmecsere (idézem saját magamat):
"Ha az alig módosított bdver2 tudott hozni majd 10%-ot a bdver1-en, akkor nem hiszem hogy legalább ennyit ne hozna a bdver3 a bdver2-n."
Az eddig szinte biztosan tudható infók alapján több és nagyobb horderejű változtatásokat hoz a bdver3 a bdver2-höz képest mint amit a bdver2 hozott a bdver1-hez mérten.
Az IMC-nem tudom hogy per pillanat hova fejlődhetne tovább. A DDR4 még nem jelent meg normális formában, a GDDR5 halott ötlet, DDR3-ból pedig a 2133 a leggyorsabb szabványosított verzió.
-
Abu85
HÁZIGAZDA
Az órajelben régóta balanszírozás megy a CPU és az IGP teljesítménye között. Mindkettőben tudnának nagyobb órajelet, csak mindig a másik kárára. Ez a turbóval lesz kiegyenlítve, legalábbis a CPU oldaláról.
Azt nem tudom, hogy mi volt a terv, de tekintve, hogy a vártnál sokkal gyorsabb a HSA terjedése, így könnyen lehet, hogy inkább több tempót raknak az IGP-re.
Több fejlesztőtől halottam, hogy HSA-val mindennel gyorsabb kódot kaptak, mint eddig. Főleg a Haswell gyorsult nagyon sokat, mert automatikusan használja a runtime az AVX2-t.(#13361) Fiery: Az Intelnek nem IGP hardverfejlesztés kellene, hanem driverfejlesztés. A legtöbb károgás ezért van, mert semmit sem ér a hardver normális szoftvertámogatás nélkül.
-
-
TRitON
aktív tag
Lehet, hogy eretnekség ilyet kérdezni és felesleges is volna vele szórakozni, de nem próbáltátok véletlenül, hogy az ES proci milyen órajelek elérésére képes? Ha igen, publikus ez az információ?
Tudom, hogy nem végleges stepping, meg ki tudja, mit változtatnak még addig rajta, csak kíváncsi vagyok. -
Oliverda
titán
Az A10-6700 és az A10-6800K között nincs túl nagy különbség. Átlagban kb. ~3,5 a difi x86-ban.
A szintén 512 végrehajtót tartalmazó 7750 800 MHz-es GPU órajellel rendelkezik. Tételezzük fel, hogy ennél 10%-kal fog alacsonyabb frekvencián menni a Kaveri IGP-je, ami a szűkösebb memória-sávszélességet figyelembe véve nem valószínű, hogy túl nagy különbséget eredményezne.
-
-
A számítógépek akkori technikai szintje nem haladta meg jelentősen az egyéb elektronikai cégek műszaki szintjét, ezért képesek voltak beszállni a buliba.
Ahogy emelkedett az elvárás, úgy hullottak ki azok, akik nem voltak elég erősek, mert a fejlesztési költségeket mindegyik cégnek ki kellett fizetnie, és a nagyobb szegmentáció kisebb piaci részesedéssel jár, ami a megtérülést nehezíti. A fejlesztési költségek növekedése a kétszereplős piac felé tolja az ipart.
Szerintem ez érthető folyamat, mégha nem is jó nekünk. -
Abu85
HÁZIGAZDA
Androidon hamarabb lesz HSA, mert ott a piac 95%-a támogatja, ráadásul az egyszerű programozás miatt ez sokkal kedvevezőbb felület lesz egy programozó számára. A mostaninál jóval kevesebb munka kell hozzá, hogy a 4+4 magos big.LITTLE és a teljes 8 magos telefonok képességeit kihasználják. Ráadásul számos mai lapka támogat már bizonyos HSA direktívákat. Windowson az AMD szoftveres partnerei ugranak rá a HSA-ra kezdésnek: Adobe, SCEA, MulticoreWare, Apical Limited, ArcSoft, Corel, eyeSight, Nuance, CyberLink, Oracle, OPTIS, Dassault Systemes, Fabric Engine, Mixamo, Rabbit.
-
leviske
veterán
De ha a DP számítások általános szoftverekbe nem igazán jönnek elő az kb annyit jelent, hogy alapvetően az AMD elgondolása jobb az AVX-nél, nem? Vagy ez teljesen más téma?
Az Android és HSA kapcsán pedig pont az ellenkezőjét olvastam Abu85 cikkeiből, mert elvileg a HSA-n keresztüli "OpenCL"-t a Google is támogatja az Androidban. (Ha jól értettem.) Emellett a Samsung/Qualcomm HSA-s cuccai elég hamar berághatják magukat a telefonokba és tabletekbe, nem kell ahhoz az AMD.
-
Abu85
HÁZIGAZDA
A szegmentáció nekem általánosan nem tetszik az Intelnél. Az asztali prociknál az olcsó termékekben még AVX sincs. A Core i3-ból AVX2 hiányzik, míg számos drágább termékben a TSX nincs meg, miközben pár olcsóbban megvan, ugyanez a helyzet a VT-d-vel. Teljesen átláthatatlan az egész. Nem csoda, hogy még az AVX-re sem startoltak rá a fejlesztők tömegesen. Márpedig ez az Intel érdeke is, hiszen azért van benne a prociban a technika. Ebben főszerepet játszik az extrém szegmentáció.
-
Abu85
HÁZIGAZDA
Jó én a tabletekre gondoltam, de valóban nem volt elég egyértelmű.
AVX2 biztos nem lesz tabletben. Nincs értelme egy ilyen környezetben ennek. Még az AVX-nek sincs. Az csak egy konzolörökség az AMD tablettermékeiben.
Az A4-1200 TDP-je csak 3,9 watt. Ennél nem fogyaszt kevesebbet egyik tabletbe szánt combosabb SoC sem. Mindegyiket 4 wattos max. fogyasztás közelébe tervezik. Lehet bűvészkedni azzal az SPD meghatározásánál, hogy a komolyan terhelő alkalmazásokat kiveszik a hitelesítésből, de ettől a TDP akkor is kb. kétszerese marad az SDP fogyasztásnak. Itt igazából nincs komoly különbség a chipek között. A többi pedig konfiguráció kérdése.
-
leviske
veterán
-
#13299
Menthirist
veterán
Fiery
#13298
-
#13297
Menthirist
veterán
Fiery
#13294
mi volt 2-3 éve a gpu-k piacán? a Radeon 7-es széria (2012 január)
Szóval akkor a következő 2-3 éves távlatban várhatóan (tudom hogy senki sem tud semmi biztosat) a 7950-em mellé várhatóan jobban járnék egy fx8320-assal (fű, por és árérzékeny vagyok, azért nem intel
), mintsem várhatóan egy kaverivel (aminek a spéci dolgait úgyis csak akkor tudnám kamatoztatni ha a dgpu helyett az apu-ét használnám)? A kaveri meg azoknak lenne jó, akik kevesebb pénzből akarnak "játszógépet" venni (pláne mantle-lel)Mert már akkor is többet tudnék mint most
-
#13295
Menthirist
veterán
Fiery
#13293
-
Oliverda
titán
A benchmark a Cosmology@Home projekthez tartozik.
"A Kaveri meg GCN2 vagy GCN 1.1, de ez a kisebb problema."
Az AMD jelöli valahol ilyen formában a GCN-t? Tudtommal nem számokkal szeparálják el az egyes verziókat.
Az kedvezőbb DP arányt szerintem az Opteron verzióra tartogatják.
-
#13280
hugo chávez
aktív tag
Fiery
#13279
hugo chávez
aktív tag
Jó, hát az Intelnek nem erőssége a GPU tervezés, az köztudott.
De én olvastam valami olyasmit, hogy a Haswell IGP-je tudna dp-t, csak nincs engedélyezve. Aztán meg az Intel fórumán azt, hogy nem tud... De az talán nem volt konkrétan írva ott sem, hogy hardveresen nem tud...
Viszont, ha nem is tudja, attól még simán cpu-ból lenyomja double float-ban az AMD APU-it IGP-stől és ez gáz...
Az NV meg egyelőre csakis GPU-t gyárt, nincs cpu-ja (a Tegra "igazi" pc-n nem játszik), szóval ott azért érthető, hogy a professzionális, meg az otthoni piacot szétválasztja ezzel is.
Az rendben, hogy optimalizálni kell keményen, ha ki akarod használni az AVX-et, de ha egy GPU-n/IGP-n akarod megközelíteni az elméleti FLOP/s-t valami hasznos alkalmazásban, akkor ott is ugyanannyira kell, mert végül is mindkettő SIMD, illetve, a többmagos cpu-knál (és már a GPU-knál is) igazából MIMD és SIMD, tehát egy programnál csak akkor tudod kihasználni, ha rá tudod venni hogy sok szálat és vektorműveleteket használjon, nem? -
#13278
hugo chávez
aktív tag
Fiery
#13272
hugo chávez
aktív tag
"DP-ben a Richland (es mellesleg a Kaveri is) gyorsabb AVX-szel mint az iGPU-val. Kimértük, nem kitaláció."
Ez marha jó... Akkor egy 4 magos Haswell meg mennyivel gyorsabb...
(#13275) Fiery:
Aha, csak így meg (legalábbis a szememben) tökönszúrják a saját HSA koncepciójukat, vagyis, hogy az IGP teljesértékű társa legyen a cpu magoknak...
(#13276) dezz:
Meg hát, mégis milyen üzenete van ennek, még ha (jelenleg?) annyira nem is fontos talán a 64 bites lebegőpontos teljesítmény...
Ha tényleg csakis grafikára lenne szánva és csakis az olcsóbb gyárthatóság miatt integrálták volna egybe a cpu-val, akkor nem háborognék, de így, hogy azzal jönnek, hogy "accelerated"... 32 biten, pffff! Hát ez így marha nagy accelerated, az már biztos!
-
dezz
nagyúr
Nyilván ha a teljesítmény a cél, maradnak a dGPU-k. Arra gondoltam, moderate teljesítményigény mellett így kevésbé van az ember OpenCL/HSA kód fejlesztésére motiválva, DP alkalmazása esetén, ha CPU-val gyorsabb a dolog. (Legalábbis, ha gyakorlott SIMD-es CPU-s kódolásban.)
-
dezz
nagyúr
Jahh, hát az ilyen, láthatólag tech-analfabéta "szerzők" blődségeivel eleve nem érdemes foglalkozni.
Valóban VLIW4, nem figyeltem.
"DP-ben a Richland (es mellesleg a Kaveri is) gyorsabb AVX-szel mint az iGPU-val."
Ez vicces...
Minek annyira lekorlátozni, hogy még a CPU is gyorsabb legyen? -
dezz
nagyúr
Ezt amúgy nem értem:
"Egy szoval tudnek reagalni: f***sag."
vs.
"Nyilvan lehet 30-40%-os gyorsulast is mérni, ha valaki kifejezetten arra megy ra"
A linkelt oldalon 32% gyorsulás látható valamilyen egyszerűbb integer teszben a Piledriverhez képest. Miért ne lehetne lehetséges?
(#13259): Ezt hogyan, tekintve, hogy az egyik VLIW5, a másik pedig GCN?
(#13266): Azért egy ideje már napirenden volt ez a téma. Mármint, hogy jó lenne egy a konzolokéhoz hasonló, lower level API. (Volt korábban is, a CTM, de az már túlzottan is low-level volt.)
(#13270) hugo chávez: Tényleg kevéske az 1/16.
Bár a legtöbb hétköznapi alkalmazásban nem használják, ahol pedig igen, ott csak egyes számításokat végeznek DP-ben, így ott még elmegy. De vannak esetek, amikor elengedhetetlen a DP. (Nagy rekurziós mélységű számítások, stb.) -
#13270
hugo chávez
aktív tag
Fiery
#13259
hugo chávez
aktív tag
-
leviske
veterán
És legalább Mantle-re alapozó alkalmazásokban, dGPU mellett hogy teljesít mondjuk egy FX8350-hez vagy egy i7 3770-hez képest? Vagy ehhez nem adott még tesztprogram? Esetleg ilyeneket nem is szoktál nézegetni?
Csak azért kérdezem, mert a Mantle kapcsán optimistábban nyilatkoztál, amiből arra tippeltem, hogy azzal is szereztél már tapasztalatot.
-
leviske
veterán
Szóval akkor a ~30%-os IPC teljesítményugrást se érdemes várni a Trinity X86-os részéhez viszonyítva? Mert mondjuk a 4770K beérését én se vártam, de a Trinity szintjéből nemigazán nézem ki, hogy a 2012-ig megjelent játékokban (pl BF3) ne lenne limitáló tényező 1650x1080-ban. Szóval azért egy FX6300 szintnek örültem volna a X86-os résztől.
Mind1, tényleg meglátjuk majd tesztekben. Nekem úgyis a Frostbite 3 alatti szereplése fog számítani dGPU mellett.
-
dezz
nagyúr
Előtte jeleztem már, hogy a Beema/Mullins példáját ne vetítsük ki a Kaverire. Ebből nem nyilvánvaló, hogy az első kettőről írtakat elfogadtam?
(#13245): De hát ilyeneket nem is várt senki tőle... A leglényegesebb változás talán a CPU mikroarchitektúrát illetően a dedikált utasításdekóderek, ami modulonként két szál végrehajtásakor fejti ki a hatását.
(Ezzel összefüggésben hadd kérdezzem meg: a ti tesztjeitek egyszálas vagy többszálas végrehajtásúak?)
A legnagyobb durranás az IGP GCN alapúra váltása. Másodsorban pedig a HSA, architektúrális integráció szintjén (Unified Address Space for CPU and GPU; Fully coherent memory between CPU & GPU; GPU uses pageable system memory via CPU pointers), amik új lehetőségekkel gazdagítják a GPGPU-s alkalmazásfejlesztést, miközben a programozók dolgát is megkönnyítik. Nem mellesleg elsőként az OpenCL 2.0-t is implementálhatóvá teszik.
-
-
dezz
nagyúr
Egyébként elég nehezen hihető, hogy elfogulatlan tudna lenni, aki - minden észérv ellenére - egy-az-egyben az egyik gyártó által hangoztatott elveket és elképzeléseket vallja és hírdeti úton-útfélen.
Holott az Intel valójában nem azért erőlteti a MIC-et, mert az annyira jó, hanem mert meg akarja őrízni az x86 piaci dominanciáját, a kisebb hatékonyságot pedig majd a piaci fölényükkel ellensúlyozzák.
ui. nem "ignore-ál", hanem ignorál: latin eredetű helyes magyar szó.
-
dezz
nagyúr
"Nem csak a doksi, mert kapasbol a Kaverirol beszeltunk az AMD-vel, ok emlitettek, hogy az egyik PC-gyarto intett be nekik, hogy a GDDR5 magas ara miatt nem fognak epiteni ra PC-t, ha megfeszul az AMD, akkor se. Ez dontotte el a kerdest."
Ezt úgy mondod, mintha Oliverda nem ugyanerről akart volna meggyőzni már napok óta.
"Ugyanigy beszeltunk veluk a Beema/Mullins problemarol, akkor emlitettek, hogy a HSA tamogatas ki fog maradni beloluk. Be szerették volna rakni, de nem jott ossze. Egyebkent az is beszedes, ha megnezed a Beema/Mullins BKDG-t, es abban a reszben, ahol az eloddel hasonlitjak ossze, hogy mik a valtozasok, nem a Kabinivel vetik ossze, hanem a Brazosszal. Akarcsak a Kabini BKDG, ott is a Brazosszal vetik ossze. Es akarhogy nezed a BKDG-t, nincsenek jelentos valtozasok, csak apro faragasok itt-ott. Ennel me'g a Trinity --> Richland valtas is eroteljesebb volt. Teljesen nyilvanvalo (szamomra) ez alapjan, hogy a Beema/Mullins se ugy sikerul, mint ahogy kellett volna neki."
Ezt meg úgy, mintha kételkedésnek adtam volna hangot.
"Ha mindezek alapjan azt mondod, hogy talalgatok, oke, elfogadom, Te igy latod a dolgot."
Attól, hogy valami nem sikerül, más még sikerülhet. A PS4 és az XBO APU-i pl. már nagyban tömegtermelődnek.
"Erre mar tenyleg nehezen tudnek mit mondani"
Próbáltalak az érvek szintjén meggyőzni, de rámküldtél egy karakterhadsereget, aztán témát váltottál.
"Me'g a Steamroller se jelent meg, es Te mar az Excavatort rangatod ide?"
Egyszerűen addigra érik be igazán a Bulldozer vonal. De az is lehet, hogy valójában az egész Bulldozer család csak az előkészület az Oliverda által korábban citált Bulldozer Nexthez, ahol már modulonként 8 integer mag és 4 "accelerator" (új fajta FPU) lesz. (Már persze ha nem fake.)
"szerintem business as usual lesz az Excavator: kijavitja a Kaveri apro hibait, hoz egy teljes HSA implementaciot"
Megint kevered a CPU mikroarchitektúrát az egész lapkával.
"Milyen tenyeket ignore-altam? Azt, hogy az AMD legyint az x86 magokra, hogy "az ugysem szamit" ? Ennyi erovel barki legyinthet a konkurenciara, hogy "ja, hát igen, ők jobban csinaljak, de ugysincs ertelme rohanni". Az ilyen arrogancia nem szokott sok jora vezetni..."
Ott van a következő modatban, jobb lenne, ha nem szaporítanád feleslegesen a szót...
"Most akkor a jelenrol beszelunk vagy a kovetkezo 5-10 evrol?"
Ez a dolog már érezteti a hatását egy ideje, ami csak erősödni fog. Az ilyen kezdeményezések pedig nem 1 évre szólnak.
"Egy masik topicban altalam felvazolt 4 GHz koruli orajelen futo, AVX-512-t tamogato, 6 magos CPU siman x86 CPU-bol nyomna kb. annyi TFLOPS-ot, mint a Kaveri iGPU-ja."
Túlságosan benchmarkban gondolkozol.
Egy dolog az elméleti számítási teljesítmény és egy másik a valós alkalmazások során elérhető. A harmadik pedig a teljesítmény/fogyasztás arány... -
lee56
őstag
"Biztos?"
Ha azt nézed hogy merre mennek a fejlesztések kb. minden processzorgyártónál, eléggé egyértelmű erre a kérdésre a válasz. Fantáziát látnak benne a cégek nyilván, vagy inkább mondom úgy hogy a hagyományos értelemben vett X86 számítási teljesítmény emelésben nem látnak már annyi fantáziát.
Csak látnánk már valami eredményt belőle, valami tesztet, valami forradalmian új játékmotort, vagy programot végre, ami IGP-t (is) használna és 10-20-50x-osára gyorsulna minden. Ezért várom már én is a Kaverit, mert kiváncsi vagyok mekkorát durran, (az a lufi). Amúgy ötletnek nem egy rosz dolog ez a fusion, meg a HSA, csak ne kéne még megint éveket várni, mint az egy-magos éra utáni időkben, hogy végre ugyan használják már ki a két, vagy több magos processzorokat a tisztelt programozók, valahogy nagyon úgy érzem itt is hasonló lesz a szitu mint anno (sőt még néhány program manapság is akad, amit "faszán" megírtak).Az általad említett dolog is érdekes azért; ha valaki majd kitalál egy jobb módit, akkor borulhat az egész, ebben tényleg van némi kockázat, AMD pedig úgytünik most mindent az IGP-nek rendelt alá, és nekik valamivel nehezebb lenne gyökeresen eltérő irányba elindulni mint a konkurenciának.
-
dezz
nagyúr
Lehet, hogy többet tudsz, de azt jól titkolod. A korábbiakban semmilyen konkrét tényt nem írtál ezzel ezzel kapcsolatban, a GDDR5 doksiból való kikerülésén kívül. Más termékekre hivatkoztál, hogy lám, azok sem azok lettek, mint amit eredetileg terveztek. Ez az egész így találgatás szerű.
"Bocsanat, nem hangsulyoztam ki, hogy a PC-rol beszelek."
A "semmi mas termek a vilagon" nem erre utalt.
"Megjegyzem, ez a topic is a mainstream PC-kbe valo AMD processzorokrol szol."
Ugye nem gondolod, hogy a kettőnek semmi hatása egymásra?
"De azt azert jegyezzuk meg, hogy a konzolok kozul -- ha jol tudom -- csak a PS4 APU-ja tamogat HSA-t."
Ezt még nem tudni pontosan.
"A CPU+FPU+memoria benchmarkok fejlesztoje nem en vagyok, de attol me'g fejleszto (koder, stb) vagyok. Pl. a hamarosan megjeleno AIDA64 v4.00 OpenCL GPGPU benchmarkjait es annak a GUI-jat is 100%-ban en keszitettem. Meg me'g ezer mas dolgot az AIDA64-ben."
Akkor ne haragudj, ez nem tudtam, más topikokbeli ezzel kapcsolatos írásaidból az jött le, hogy Balala a kóder és te vezényled a fejlesztést és intézed az egyéb ügyeket. (BTW, az OpenCL benchmarkban alkalmazott eljárások inkább az AMD-nek fekszenek jobban, vagy az Intelnek?
Mint tudjuk, egyes dolgokban az egyik a jobb, másban a másik.)"nalunk van egy Kaveri, amin fut egy alpha allapotu HSA implementacio (mivel annal jobb me'g nincs). Benchmarkoljuk, tesztelgetjuk nap mint nap ezt a konfigot."
Ezt a nem mellékes körülményt eddig nem közölted.
"Pont ezek alapjan a tapasztalatok alapjan mondom azt, hogy a HSA tul konnyen lekoppinthato, ill. hogy a Kaveri leginkabb csak iGPU-ban eros(ebb, mint a Richland)."
Szerintem csak felületesen szemlélve tűnik könnyen lekoppinthatónak.
"Egyebkent mulatsagos latni, hogy a Bulldozer elhibazott alapkoncepciojat "gyermekbetegseg"-kent aposztrofalod. En inkabb alapveto architekturalis mellefogasnak mondanam"
Erre térjünk majd vissza akkor, ha az Excavator is vacaknak bizonyul.
"Azota meg csak azt hallani, hogy a CPU/FPU nem is lenyeges, bezzeg az iGPU meg a HSA. Persze ha valamely adatnal az AMD kerul elonybe, akkor hirtelen az lesz a legfontosabb, pl. 8 mag es 5 GHz-es orajel. Akkor hirtelen megint a CPU/FPU resz kerul fokuszba. Milyen erdekes"
Ez meglehetősen rosszmájú, alapvető tényeket és iparági trendeket ignoráló megjegyzés volt. A félvezetőgyártás jelen helyzetében CPU téren 5-10 éves távlatban még az Intel sem fog tudni jelentősebb változást felmutatni. Ezért kezdtek el foglalkozni a Larrabee, később MIC projekttel, ezért készítettek OpenCL drivert ők is az IGP-ikhez. És bizonyosan nem az AMD kedvéért lépett be az ARM, a Samsung és egy sor más, meghatározó cég a HSA Alapítványba... A számításigényes feladatok jó részét a CPU-ét messzem meghaladó számítási teljesítményű IGP-re lehet bízni, illetve közösen dolgozhat rajtuk a CPU és az IGP. Néhány éves távlatban csak ezzel lehet jelentősebb teljesítménybeli előrelépést prezenlátni, ezért nagyon is ezen lesz a hangsúly.
-
stratova
veterán
A fejtágítást köszönöm.
Számomra a lényeg, hogy legyen olyan AMD-s noti, amiben akár mSATA akár M2 révén de kártya formájában kerülhet SSD, megőrizve ezzel a HDD eredeti helyét (s így az ODD-t).
Őszintén szólva eddig egyetlen AMD-s notebooknál sem láttam még csak opció szinten sem erre lehetőséget, holott azonos kategórián belül Inteles verziónál volt rá mód. Sőt utóbbi esetben akár már 140 környékén kapni ilyen gépet (nyilván más szempontok is vannak ezen kívül). -
leviske
veterán
A probléma csak azzal van, hogy tudomásom szerint már az ATi felvásárlása óta a FSA/HSA irány volt tervben. Ezért vállaltak be egy rizikós felvásárlást. Ez még haverok közt is 7 év előny az AMD számára. Vagyis azzal számolva, hogy az Intel még most is a MIC-on dolgozik és ezzel -ha eddig jól értettem- egészen más irányból közelít.
Az nVidia már egy egészen más tészta, de nekik a mobilpiac végett érdemes volna inkább belépni a HSA-ba, mivel anélkül az Android piacról kiszorulnak idővel. Arról nem is beszélve, hogy a HSA-val gyakorlatilag az AMD és ARM nyakán mászhatnának vissza a desktop élvonalba.
A Mantle meg önmagában egy semmi. Volt már próbálkozás saját API-ra és bukott is már bele gyártó a dologba. A Mantle-t szvsz nem az teszi érdekessé, hogy bevállalta az AMD, hanem az, hogy gyakorlatilag ott áll mögötte a két nagy konzol. Ez ellen meg jöhet az nVidia és az Intel bármilyen API-val, önmagában semmit nem érnek vele. Szóval a Mantle inkább addig van biztonságban, míg nem lép a Khronos vagy a Microsoft és tereli újra azonos mederbe a cégeket. És itt jönnek képbe az Abu által rengetegszer emlegetett "évek". Bár persze még meglátjuk.
-
leviske
veterán
De ha az AMD nem lenne magabiztos a HSA kapcsán, akkor meg se merték volna nyitni más gyártók irányába, nem? Szóval onnantól tökmind1, hogy lemásolják-e, mert ha a másolat kompatibilis lesz (márpedig, ha évekkel később jön, akkor annak kell lennie, hogy terjedni tudjon) akkor az AMD hazai pályán marad.
Emellett a Mantle és a PC-s gyártók (Dell, HP, Acer, Lenovo) gamer piac felé való elmozdulása a két konzol GCN alapjaival kiegészítve egy elég szép terjedési lehetőséget nyit az AMD számára. Szóval az általad is elismert Mantle siker esetén a HSA-t is kénytelen/kelletlen sikerre viheti, hiszen az Intelt kiszoríthatják a Mantle-kompatibilis APU-k.
-
Oliverda
titán
Hiába a marketing, ha nem lehet beszerezni a rendszerhez szükséges modulokat. Szerintem eléggé tökön lőtték volna magukat a GDDR5-tel, de talán még időben hagyták a fenébe az egészet. Egyedül talán a drágább ultrabook (szerű) gépekben lehetett volna létjogosultsága, illetve ott talán minden szempontból kivitelezhető lett volna.
Miért, nem azt írtam?
![;]](//cdn.rios.hu/dl/s/v1.gif)
stratova: Az mSATA sima SATA adatkapcsolatot használ, az M.2 pedig már csak PCIe-t. Az mSATA nincs az Intel-hez kötve. Létezik AMD-s cucc mSATA-val.
-
dezz
nagyúr
Ahhoz nem kell új chipet tervezni, hogy ugyanaz levalidálhassák letiltott GDDR5 móddal is.
Tudod az igazságot? Annyit tudsz, hogy egy ideje nem szerepel a GDDR5 támogatás a doksiban és ebből igyekszel túl messzemenő következtetéseket levonni.
"akkor 2014-ben vegig csak a Kaveri lesz, semmi mas termek a vilagon, ami HSA-t tamogatna."
Több millió termék lesz még a piacon az új konzolok képében. Ezt nagyon szereted elfelejteni. Az sem kizárt, hogy valamely más gyártó is kijön 2014 folyamán valamilyen HSA támogatású termékkel. Ezt is szereted elfelejteni.
Elhiszem én, hogy több vagy, mint egyszerű manager, de mint magad is írtad már korábban, Balala a kóder. (Egyszer már kérdeztem valami specifikusat privátban, ha emlékszel, hozzá irányítottál.
)A Bulldozer kicsit más eset volt. Maga a koncepció jól nézett ki (és szerintem kisülhet még belőle valami, ha elmúlasztják a gyermekbetegségeit), de te akkor már tudtál 1-2 konkrét gyermekbetegségről. Utána már csak reménykedni lehetett, hogy egy újabb steppingben javítani tudják ezt, de annál komolyabb beavatkozásra lett volna szükség. Most viszont te is csak találgatsz.
(#13217): Ezt mondom én is: ha alig tudunk valamit, akkor inkább talán ne feltételezzünk mindenféle rosszat.
(#13220): Ez így nagyon szépen és logikusan hangzik, csak sajnos pár dolgot nem vettél számításba és az sem érdekelt, amikor erre felhívtam a figyelmedet. Mintha a sok szövegeléssel próbálnád elterelni a figyelmet az ellenérvekről. Aztán, amikor már csak az maradt volna, hogy "oké, talán tévedtem", egyszerűen nem válaszoltál. Nekem ebből valahogy nem az jön le, mintha annyira "féltenéd" szegény kis AMD-t, hanem a fő cél a bizalom megingatása lenne.
-
stratova
veterán
Fiery & Oliverda: Amennyiben megemlíthető, van biztos információtok arra vonatkozóan, hogy ezen a dián szereplő "New PCIe SSD Interface" automatikusan maga után vonhatja pl. Mobil Kaveri mSATA támogatását? Ezzel - talán mondhatjuk - régi adósságot törlesztene a gyártó.
Thrawn: mióta először láttam azt a diasort, erre spekuláltam én is. No meg stacked RAM-ra, az első Amkoros diák és egyéb tesztlapkák (nem APU) után. Számomra még mindig nem tiszta, mitől lenne drágább egy GDDR5M (nem GDDR5!) egy DDR4-nél. Az APU-nak grafikus feladatra (nem GPGPU-ra) pedig ideális lehetne.
(#13223) Fiery Értem, köszönöm. Ez kifejezetten jó hír lenne. Már mSATA opcióval is elégedett lennék egy notebookban, eddig ez csak Intelnél volt elérhető tudtommal. NGFF (M.2) persze még jobb lehet, ha már beállt az ára egy elérhető szintre.
Régi vágású vagyok, nekem még kellene az ODD és a HDD az SSD mellé egy kalap alatt. -
Oliverda
titán
Továbbra is azt gondolom, hogy jelen esetben erősen túl van hájpolva a GDDR5 szerepe. Nem sokat segítene a Kaverin ha támogatná, mert az önmagában még semmit sem érne. Megfelelő gyártói ill. piaci támogatás nélkül csak egy pár oldal lenne a BKDG-ben, és leírhatnánk hogy már ilyen is volt.
-
dezz
nagyúr
Oliverda már a #13200-asban leírta. De nem is értem, hogy nem vagy tisztában vele, hogy az egyik a CPU modul mikroarchitektúrális kódneve, a másik pedig az egész lapkáé.
Más a tények közlése és más az állandó részrehajló feltételezések. Egy idő után nem olyan szórakoztató.
A GDDR5 a DDR3-on alapul, ugyanazzal a memóriavezérlővel lekezelhető (kb. mint ahogy az AM2+/AM3 Denebnél volt, csak ott DDR2/DDR3). Ezért szerintem a GDDR5 kihagyásához nem lett volna szükség új Kaveri lapkára.
És igen, szeretnénk azt hinni, hogy a Kaveri 2.0 nem butább, hanem okosabb lesz, mint az eredeti. Szerintem nem kell ehhez vérfannak lenni.
"A tobbi, amit leirtam, pl. a Kabini meg a Beema/Mullins kapcsan, azt szinten az AMD mondta el, nyilvan itt nem fogok specifikumokat emliteni. Mindenesetre az mar onmagaban is furcsa, hogy a Beema/Mullins feature szinten megegyezik a Kabinival, pl. nem tamogat HSA-t, azonos processzen keszul majd, stb."
És mi köze ennek a Kaverihez, ami viszont támogatja a HSA-t és egy teljesen másik vonal?
(#13209): "De ez esetben mar osszesen 4 fele variaciorol beszelunk, amibol vegul elkepzelheto, hogy a legkevesbe attraktiv valtozat kerul gyartasba."
Sokminden elképzelhető. Pl. az is, hogy egyszercsak felrobban az egész AMD központ. Bizonyára sokan fantáziálnak ezen... Csak nem mindenki kíváncsi rá.
(#13210): Tudod, egy idő után kicsit fárasztó az egyik irányba folyamatosan negatív spekuláció, a másik oldal dícsérgetése mellett. Próbáld ki, hogy felkeresed pl. Mercedes tulajok fórumát, és nekiállsz azon "spekulálni", hogy a következő Mercedes biztos nagyon vacak lesz, de a Citroen, na az nagyon megy... Elképzelhető egy idő után ott is rá fognak únni. Aztán meg állj neki lefanozni őket ezért...
(#13206) Oliverda: Az, hogy a modulokat SteamrollerB-nek hívják, számomra azt mutatja, hogy ez valami új. Szóval, szerintem:
- Kaveri 1.0 -> Steamroller CPU modulok
- Kaveri 2.0 -> SteamrollerB CPU modulokDe látom, te is így gondolod. Nos, én azt remélem, hogy a SteamrollerB jobb, nem pedig rosszabb, mint az eredeti Steamroller.
(#13212) Yutani: Ami azt illeti, nem ő a program aktív fejlesztője (a kóder). Szerintem ő a manager.
-
Oliverda
titán
-
Oliverda
titán
Mielőtt megint beindulna a kilométeres OFF özön:
Szerintem ezt most te értetted félre, ugyanis a SteamrollerB nem egyenlő a Kaveri 2.0-val. Míg előbbi az x86-os modulra utal, addig utóbbi a teljes lapkára, illetve annak képességeire.
Az rendben van, hogy végül törölték a GDDR5-t, és így született a Kaveri 2.0. Ezzel szerintem senki sem vitatkozik, pláne hogy nem túl sok információ került napvilágra.
-
Abu85
HÁZIGAZDA
C/C++, Java és Renderscript.
Ez a gyártóknak is a baja, mert ők is rengeteg OpenCL kódot készítettek, de a Google azt mondta, hogy nem. Az indokuk is egyszerű, a HSA garantálja, hogy ugyanaz a kód minden hardverrel kompatibilis, míg az OpenCL esetében erre nincs garancia.
A mainstream fejlesztők vidáman átállnak majd, itt a legfőbb probléma, hogy a gyártók rengeteg házon belüli technológiát építettek az OpenCL-re, amit most írhatnak át. Ez volt a legfőbb nyomás a Google-ön, de most úgy néz ki, hogy a HSA-val minden érintett megbékélt. Kicsit csúszni fog a dolog, de még mindig jobb, mint az eredeti "csak Renderscript lesz" álláspont.Csak PC-n gond, hogy mindenki mást akar. A mobil piacon nagy az egyetértés a HSA mellett. Az Intel és az NV a maréknyi részesedésükkel ebbe nem tudnak beleszólni. Vagy beállnak támogatni, vagy készítenek egy saját Android verziót, mint például az Amazon. Abba azt raknak amit akarnak, és építeniük kell egy saját áruházat rá. Az Android nagyon szerencsés helyzetben van, hogy a piacuk 95%-a a HSA-t preferálja.
-
Abu85
HÁZIGAZDA
Már nem a VIA tulajdona az S3. A HTC kapta meg a részleget és mindent ők pénzelnek innentől. A VIA az S3 fejlesztéseket licencelni fogja a HTC-től.
A VIA elsősorban a WonderMedia miatt lépet be az alapítványba és nem az S3 miatt. Egy pár hete már erős a pletyka, hogy a Google az OpenCL-re véglegesen nemet mondott, de az ARM, a Qualcomm, az Imagination, az LG, a Samsung és a Mediatek nyomására a HSA-t beépíti az Androidba, de cserébe azt kéri, hogy ezek a gyártók OpenCL-t többet ne telepítsenek bele a rendszerbe. A VIA csak követi ezt, mivel OpenCL nélkül nekik is a HSA felé kell húzni.
Igazából ez kemény menet volt, de úgy néz ki, hogy megegyeztek. GPGPU-t mindenki akar, de a hogyan kérdéses. A Google azt mondja, hogy Renderscript, míg a többiek ezt nem akarják. Most mindenki szerencséjére nagyon közel kerültek az álláspontok a HSA-val, mert azt a Google is támogatja. Egyébként ezért cserébe azt kérik, hogy a Renderscript kiemelt támogatást kapjon a HSA alapítványtól is. Tekintve, hogy mást nem tehetnek, így egyelőre ilyesmi Android szoftveres stack lehet a jövő, legalábbis az ARM felvázolásában.
A Google-nek az a szerencséje, hogy csak az Intel és az NV nem támogatja a HSA-t, de ők az Android piacának nem teszik ki az 5%-át sem, tehát kicsi az érdekellentét itt.
-
lee56
őstag
Egy Steamroller alapú CPU sem lenne teljesen zsír új mivel, FM2+höz ugyis elkészítik (sőt a dizájn már rég kész), így kb csak a másik tokozás miatti módosításokkat kellene megoldani, ami már csak nem olyan vészes. És nem hinném hogy ne lenne rá kereslet, amikor sokan már most is azért pártolnak át a konkurenciához, mert keveslik a CPU-erőt a jelenlegi felhozatalban. Egyszerűen nem értem az AMD miért ne akarna egy már szinte piackész versenyképesebb (ami azért nagyobb előrelépés lenne mint Trinty->Richland, sőt talán még a Bulldozer->Piledrivernél is) terméket piacra dobni, amikor megtehetné.
Azoknak a pletykáknak amik szerint 2015-re lenne új CPU (tokozással mindennel együtt), azt meg már nem tudom hova tenni. Épphogy mire jobban elterjednének az APU-k akarnak kijönni új CPU-val? Az időpont kb reális hogy akkor DRR4-es platform lenne, de az meg megint inkább az APU-knak lenne hasznosabb, szóval megintcsak..
-
Mi internetes képátvitellel kezdtünk el dolgozni az utóbbi években, és mi is GPU-val kezdtük a fejlesztést, mert 1,5-2,5-szeres ár/teljesítmény és teljesítmény/fogyasztás adat jön ki bármilyen x86-hoz képest a jelenlegi kódunkkal. Mondjuk mi nV-CUDA társaság vagyunk, mert az AMD linux alatt szoftveresen nem elég megbízható jelenleg sem, és a fejlesztőkörnyezetek sem olyan jók. Windózra meg nem akarunk váltani emiatt. Azóta már vannak GCN-es Radeon-ok, és folyamatosan napirenden van a váltás vizsgálata, de eddig mindig voltak szoftveres gondok, amik miatt nem lenne megbízható döntés, hiába izmosabb a GCN-es hardver.
-
Abu85
HÁZIGAZDA
Azt tudom megmondani, hogy a szervereknél a tradicionális feladatokat próbálják gyorsítani GPU-val. Ezt már ma is csinálják. A Facebooknak rengeteg Radeonja van a memcached technika offloadjára, csak nagyon megnő a fogyasztás, és nem gyorsul lényegesen. De nyilván ezen az integráció és főleg a közös memória sokat segít majd. Ez egy tipikus munkafolyamat, amire nagyon jó a GPU és sokszoros gyorsulás érhető el.
De van még a Hadoop és SQL gyorsítása, suffix tömb gyorsítása, Java GPGPU opciók, szimulációs feladatok. Ezekre mind jó a HSA, és nagyon tipikus munkafeladatok az adott szerverekben. A gyorsulás mértéke pedig sokszoros lehet.
A HSA nem a direkt verseny miatt érdekli a cégeket, hanem amiatt, hogy ugyanazt tizedannyi fogyasztásból megcsinálják. -
Oliverda
titán
Ha ez valóban így van akkor miért erőlködnek a Warsaw-val? Hiába nem új lapka, ennek a forgalomba hozása sincs ingyen, ergo valamiért még invesztálnak ebbe a szegmensbe.
Elvileg novemberben elérhetővé válik az új roadmap. Abból remélhetőleg már pontosan lehet látni az irányokat.
-
Oliverda
titán
Igen, de ezzel most nem sokat érnének a felsőbb kategóriákban, mert a Jaguar nem tud ~4 GHz-et, ha pedig átterveznék a magasabb órajelnek megfelelően, akkor kétlem, hogy megmaradna ez a kis méret.
Egyébként reális(abb) összehasonlítást majd a Steamrollerrel lesz érdemes csinálni, mivel ugye hasonló gyártástechnológiával fog készülni.
Nem tudok róla hogy kiszálltak volna a 2P-4P-ről, vagy hogy ez bárhol is szóba került volna. Most Inkább épp oda lenne érdemes összpontosítani, hisz míg a desktop szegmens egyre zsugorodik, addig a szerver folyamatosan növekszik. Ha igaz a pletyka akkor 2015-ben új platform jön SR-alapú CPU-kkal.
-
stratova
veterán
Ehhez képest az Opteron 6300-as vonal (Pieldriver) Warsaw réven még úgy néz ki kap egy frissítést (gondolom, kb olyat mint Trinity/Ruchlanddel).
miklosss2012 bár a kérdés nem nekem szólt, AM3+ Socket C32-vel egyetemben egy ideje már kikerült a szerver útitervből, pedig ott még több értelme van a több mag kisebb órajel melletti felállásnak, mint asztali vonalon. Szvsz AM3+ nyugdíjazva lett.
-
Oliverda
titán
Én egyelőre nem látok ekkora jövőt a Jaguarban. Még nem volt szerencsém saját kezűleg tesztelni, így csak más eredményeiből tudok kiindulni. Az 1,5 GHz-es, négymagos A4-5000 1,5 pontot ért el CB 11.5 alatt. Optimistán számoljunk tökéletes skálázódással az órajel emelésével párhuzamosan, így egy 3 GHz-es modell elméletben kereken 3 pontot kapna.
A fenti eredmények minden esetben négy, 3 GHz-re állított maggal születtek, így jól összevethető a teoretikus Jaguarral.
A Vishera-nál így elméletileg 16%-kal lenne gyorsabb azonos órajelen illetve magszám mellett a Jaguar egy olyan területen, ami (eddig) a BD-alapú megoldások egy elég gyenge pontjának mutatkozott ([link]).
Egyetlen 32 nm-es Bulldozer modul 2 MB az L2 cache-sel együtt 30,9 mm2, ami 28 nm-en kb. 24 mm2 lenne. Két darab 28 nm-es Jaguar mag 6,2 mm2, 2 MB L2 pedig saccra ~10 mm2 lehet, ami összesen 16 mm2. Ez ugyan 8 mm2-rel kisebb, de azt még mindig nem tudjuk, hogy mennyivel kéne megtoldani a magokat ahhoz, hogy 3,5-4,0 GHz-es frekvenciára is képesek legyenek, illetve hogy a komolyabb, 2P-4P szervereknél is megállják a helyüket. Egy szó mint száz, én még egyáltalán nem vagyok biztos abban, hogy ezzel együtt más területekre is olyan jó alternatíva lehet ez vonal. Time will tell.
-
#24650752
törölt tag
"A Jaguar ugyanis egy jobb, hatekonyabb, gyorsabb architektura osszessegeben, es ha megfeleloen fel tudjak skalazni orajelben, akkor siman az lehet a jovoje az AMD mainstream desktop/mobil platformjanak is."
Izgalmasan hangzik. Engem azóta foglalkoztat ez a kérdés, mióta kiderült, milyen processzor lesz az új konzolokban.
-
lee56
őstag
Igen, a célt tekintve logikusnak hangzik, mert jelenleg látszólag is nagy gond nekik a CPU részt kipofozni, miközben az IGP-t is hízlalják azért, hogy nyeregben maradjanak legalább iGPU fronton.
Ha a fusion álá HSA valóban sikeres lesz, nyugodtan csökkenthetik is akár a CPU részt az elkövetkező generációknál.De azért ez még nagyon a jövő, az átmeneti időkben pedig egyre jobb CPU nélkül nem tudom mi lesz velük.
Ugyanakkor izgalmas lesz tényleg ha az Intel végül mégis más utat választ (bár látszólag most ők is az IGP-jükre fókuszálnak inkább), érdekes dolgok jöhetnek ki azért.
-
dezz
nagyúr
"Mert akkor csatlakozniuk kene a HSA Foundation-hoz... Azt meg nem akarjak."
Mert? Ennyire derogál nekik az, ami a világ más nagy elektronikai cégeinek nem?
"A jozan esz azt diktalja, hogy az IL szintjen ne kelljen foglalkozni az utemezessel. Az x86 sem arrol szol, hogy mikepp utemezed a kodot, hogyan futtatod le (in-order, pipelined in-order vagy out-of-order)."
Nem utasításütemezésről van szó, hanem a (rész)feladatok ütemezéséről.
"A nyelv szintjen nem kell ezekkel foglalkozni, plane ha queuing megoldasrol van szo."
Ehhez képest az AMD kifejlesztett v. implementált egy bizonyos Architected Queuing Language-et (AQL). [link]
De más okai is vannak az IL szükségszerű megváltoztatásának:
- Többféle magas szintű nyelv támogatása az OpenCL-en kívül (C++, Java, C++ AMP, .NET, stb.).
- Másféle, önállóbb queuing, AQL, user-mode dispatches to HW, dispatch API-k.
- Unified memória modell, közös pointerek a CPU-val.
- Cache koherens és nem koherens területek.
- Önálló context switch, preemtion.
- stb.Nem tudom, miért gondolod, hogy az Intelnek csak minimális változtatásokat kellene eszközölnie az IL-jén egy HSA-szerű rendszer, illetve az OpenCL 2.0 kiszolgálásához? Vagy hogy az AMD nem próbált annyit átemelni a HSAIL-be a korábbi IL-ből, amennyit lehetett? Vagy hogy a fentiek és pár egyéb dolog implementálása és kiszolgálása szinte semmiség (az Intelnek)?
(#13073): Ez azért furcsa, mert a Brazos/Jaguar az tulajdonképpen a K8/K10 lebutítása, sok tekintetben. Ebből fakad az is, hogy nem tudnak jelenleg még 2 GHz fölé sem igazán menni vele. Valószínűleg jelentős változtatásokra lenne/lesz szükség ahhoz, hogy ez megváltozzon.
-
#13078
Mahrenburg
őstag
Fiery
#13026
Mahrenburg
őstag
Köszönöm!
Jól értem, hogy lehetne nagyobb (pl. 3 GHz körüli) órajelű Jaguar-változatot is kihozni (persze magasabb TDP-vel) ? És egy ilyen változat már elképzelhető, hogy "Intel-közeli" magonkénti teljesítményt nyújtana? (Ráadásul, ha jól sejtem, a kis lapkaméret okán még így is nagyon jó fogyasztási értékeket hozna.) Az is elképzelhető, hogy csak azért nem álltak át Jaguarra, mert a Carrizo már "készen van"? Az is eszembe ötlött, hogy (szintén a kis lapkaméretet alapul véve) lehetne 4 Jaguar-mag+GPU, s tisztán CPU, azaz 2x4 Jaguar-magos verzió is... (Persze lehet, hogy túlgondoltam/félreértettem valamit...
) -
Én konkrétan remélem, hogy így lesz.
Nekem az is jó, ha a Jaguarral rakják össze a GCN3-at, kihagyva az FPU-t, tulajdonképpen a lényeg, hogy minden területen legyen értelmes alternatívája az intel prociknak az AMD-től.
pl. nem tudom, hogy mivel lehetne maghajtani 2db, netán 4db 290X GPU-t. -
-
stratova
veterán
Akkor én félreértettem a korábbi bejegyzésedet, ezért is lepődhettem meg rajta.
Max. 8-at, igy van Persze ha lesz ra igeny, akkor barmikor tud az AMD 8-nal tobb GCN2 CU-t integrálni a Kaveri 2 CPU-modulja mellé, csak annak sajnos a TDP-keret látná kárát.Ugyanis én GPU CU-ként értelmeztem (ahogy lee56 is értelmezte a hsz-emet). Azért is hasonlítottam a legnagyobb teljesítményű konzol APU-hoz - Abu válaszára reagálva - mert korábbi híradások szerint ott a GPU CU-k nem csak grafikai számításokat végeznek. Ebből gondoltam arra, mi a legnagyobb GPU CU szám, amit a 2 CPU modul kiszolgálhat PC-n GPGPU-s felhasználás esetén.
AMD már HD 7000 megjelenésekor azt reklámozta, hogy az GCN mennyivel alkalmasabb ilyen területre a korábbi megoldásnál:
-
lee56
őstag
Szerintem iGPU CU-ra gondolt, tehát a radeon core tömbökre, amikből a PS4-ben 18 lesz elvileg.
Az a hozzászólás viszont nem tudom melyik lehetett amire utalt, de szerintem hosszútávon beszélhettél erről, vagyis hogy majd be tudnak építeni többet is, majd a Carizzo-ban és később. Ezért jó a moduláris felépítés, könnyebben tudnak újratervezni, ha esetleg még nagyobb die area kell az iGPU-nak. Amúgy a Jaguar magok (8) azért annyira nem erősek, nem? Desktop Kaveri 4 magja simán nagyobb teljesítményt fog adni, más kérdés hogy bizonyára nagyobb fogyasztás is fog járni e bónusz mellé.És itt nem is értem amit kérdezett strati ;
"Mi lehet itt az a felső küszöb amit 4 Steamroller mag még kiszolgál, a PS4 18 CU-ja?"
Ez PC-n a majd (lentebb) említett programozóktól függ igazán, meg a szoftverkörnyezettől amit az APU-k alá görgetnek a gyártók; lásd mantle. Konzolon a relative kisebb Jaguárok teljesítménye sem jelent gondot, mivel nem kell pl. a DirektX rétegeivel megküzdeni. És ugye azért van az erős iGP benne hogy azt piszkálják inkább, tehát ha már amúgyis ez volt a (játék)fejlesztők kívánsága, akkor essenek is neki és használják azt ki minél jobban. Tehát mire desktopon a PS4 szintjén fognak járni iGP-ben,már talán lesz elég tapasztalat is a témában.Na igen, amit írsz a végén az lenne a nonplusz ultra, a fusion utópia megvalósulása, szerinted mégis hány év telik el mire ez kökemény reality nem lesz, gondolva főként a globális elterjedés és a szoftverprogramozók felnövéséhez a feladathoz?
(#13055) stratova : Igen ez tényleg érdekes, állítólag kellően jó PR-al még a sz@rt is el lehet adni, de furcsamód - ahogy Fiery is írta - AMD-nek ez néha akkor sem ment, amikor tényleg minden tekintetben jobb cuccot árult mint a konkurencia. Bár ha a sok kék szemüveges bolti eladóra, meg a kékek jópár aljas húzására gondolok, akkor már azért érthetőbb hogy nem olyan egyszerű versenyezni velük.
Az meg hogy gyártósorok is néha megszivatják őket, és nem gördül le elég termék hogy elárasszák a világot, csak a hab a tortán. -
dezz
nagyúr
Persze, hogy nem, de az sem mindegy, mennyire lehet megközelíteni a 100%-ot. A HSA a HW-rel szemben is meghatároz egy sor követelményt.
"Talan meg kene probalnom osszeszedni elejetol a vegeig"
Szükségtelen, csak egy ponton volt félreértés.
"Nem, te jo eg, me'g csak az kene"
Miért? Akkor másokra hárulna az OpenCL, Java, stb. fordítók elkészítése, az Intelnek - a többi gyártóhoz hasonlóan - csak a HSA Finalizert kellene elkészítenie a HW-eihez...
"Fogja a meglevo OpenCL --> IL (sajat, Intel-specifikus IL) forditojat, nem kell semmi kulonoset csinalni vele, hiszen az OpenCL 2.0 nyelvi szinten nem valtoztat semmi alapvetot."
1. Már ha jelenleg van bármilyen IL-e az Intelnek, nem pedig csak valami sokkal egyszerűbb low-level GPU driver. (Az AMD jelenleg elvileg közvetlenül GPU ISA-ra fordít OpenCL-ről.)
2. Attól, hogy OpenCL szinten nem sokat változik a szintaxis, egyebek, az IL szintjén jelentős változások lehetnek.
3. Nem hiszem el, hogy csak úgy sitty-sutty implementálni tudnák az OpenCL 2.0-át, mindezt HSA szerű alapokon. Ha ez csak így menne, már beelőzték volna az AMD-t."Ezt honnan tudod? Van konkret informaciod erre vonatkozoan?"
Csak a józan ész.
"Es kulonben is, mi koze az IL-nek a context switch-hez meg a queue-hoz?"
Ez erősen attól függ, hogyan vannak és lesznek ezek alacsony szinten megvalósítva. CPU-knál is jöttek be új utasítások pl. gyorsabb context switchre, stb. Még összetettebb dolog lehet az SVM, cache koherenciával kapcsolatos esetleges műveletek, stb.
"Egyszerubb modositani, mint ujat irni (lasd AMD)."
Honnan tudod, hogy az Intelnek nem kell? (Lásd fent.) Vagy hogy az AMD-nek milyen szinten kell átírnia? Jelenleg az sem biztos, hogy volt valamilyen IL. (Lásd fent.) Ha volt, akkor kétfelé kell bontani (OpenCL->IL, IL->GPU ISA), az IL szintaxisát módosítni, a meglévők mellé új funkciókat beilleszteni. A HSAIL-t alapvetően az AMD dolgozta ki, nyilván építettek a meglévő IL-re is, ha volt olyan.
A dinoszauruszok is sokáig uralták a Földet, de aztán változások álltak be, amihez nem tudtak alkalmazkodni (mert megszokták, hogy addig nem kellett semmihez), szépen ki is haltak. Az x86 sokat veszített a befolyásából, és elég kicsi az esély, hogy ezt az egészet az Intel az ellenkezőjére fordítja.
-
dezz
nagyúr
"Mar leirtam, hogy ha valaki hazon belul akarja megoldani a HSA-t"
Akkor most olvasd el annak a mondatnak a második felét is, amire válaszoltál...
"Az Intel (es az nVIDIA sem, mellesleg) akkor se az a fajta, aki atveszi mas megoldasait. Inkabb csinal sajatot, me'g ha az nagyon hasonlit is egy meglevo megoldasra."
Ez a legutálatosabb benne (NV azért nem viszi ennyire túlzásba), hogy folytonosan vérre menő harcot vív az egész világ ellen, minden téren. Mintha nem az emberiség része lenne, hanem egy idegen faj. Kooperációra képtelen.
"A HSA-nak pont az a lenyege [...]"
Ezt tudjuk. De ha az Intel megoldása csak hasonlít rá, de eltér tőle, akkor nem feltétlen biztosítható, hogy ugyanaz a kód ugyanolyan jól fut majd mindkét rendszeren.
"Ha eddig szinte mindig bejott, miert kellene valtoztatniuk a viselkedesukon/hozzaallasukon?"
Remélem, tanultak az AMD64 esetéből. És nem azt, hogy még alantasabb módon próbálják megfúrni az "ellenség" kezdeményezését.
"Azt irtad, progamozol. Ha tenyleg igy van"
Ha tudni akarod, 28 éve programozom, az idő nagy részében ASM-ben (többféle proci, de az x86 nincs köztük), kisebb részében C-ben. Referenciáimmal nem hozakodnék itt elő. De megkérnélek, hogy ne vond kétségbe a szavamat. Továbbá újfent megkérlek, hogy ne nézz hülyének. Ha a másik valamit nem ért, vagy úgy tűnik, hogy nem ért, annak félreértés is lehet a oka.
"akkor nem ertem, miert nem erted meg, hogy az OpenCL adott, azt nem is kell masolni, teljesen nyilt."
Ki beszélt az OpenCL másolásáról?
"A cucc masik vege meg az a driver ami kommunikal az iGPU-val es atadja a szamitasi feladatokat. Ha nem nyilt rendszert epitesz (ami a HSA), hanem egy HSA-hoz hasonlo, de zart rendszert, akkor **rvara mindegy, hogy a 2 veg kozott mi van, milyen koztes retegek, nyelvek vannak. Senkinek semmi koze hozza."
Ezt írtad korábban: "Viszont ha az Intel lekkopintja a HSA-t, akkor neki nem kell uj forditot irnia, hanem csak a drivereket: joval kisebb melo." - Itt nem arra gondoltál, hogy a HSAIL-hez ír drivert és arra való fordítást meghagyja másoknak (AMD vagy aki a HSA Foudation keretein belül ezzel kíván foglalkozni)?
Vagy, ha arra gondoltál, hogy a saját fordítóját használja tovább és csak a saját meglévő IL-jéhez készít új drivert: kötve hiszem, hogy ez az IL eleve, már jó előre a HSA új megoldásainak megfelelő lett volna... A végén még kitalálod, hogy az AMD másolta a HSAIL-lel és a vISA-val az Intel titkos IL-jét... Ne bohóckodjunk már...
A valóság talaján maradva, ha az Intel csak egy HSA szerű architektúrát akar kialakítani, akkor bizony (az új HW-ek mellett) új IL rétegre lesz szüksége (a régi ugyanis nem coherent+unified memory aware, nem támogatja a korábban nem létező fast context switchet és az újfajta queue rendszert) és az OpenCL fordítóját is ennek megfelelően, jelentősen módosítania kell. Azaz, koránt csak csak új drivert kell írnia.
"Ha piaci versenyben kuzdo technologiai cegrol van szo, akkor a penz biztositja azt, hogy a kovetkezo technologiai innovaciora is legyen R&D."
Ha képesek lennének megfelelő szintű kooperációra, nem kellene mindent saját maguknak (újra) kifejleszteni, ezzel jelentősen csökkenhetne az R&D budget, máris nem kellene vérre menő kűzdelmet folytatniuk az egész világ ellen, hogy azt előteremtsék.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
)Ú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.
- Bomba ár! HP EliteBook 2540P - i5-540M I 4GB I 250GB I 12,1" WXGA I W10 I Garancia!
- Apple iPad (9th Generáció) Wi-fi + Cellular, 1 Év Garanciával
- ÁRGARANCIA!Épített KomPhone i5 10600KF 16/32/64GB RAM RTX 3060 12GB GAMER PC termékbeszámítással
- Apple iPhone 13 128GB, Kártyafüggetlen, 1 Év Garanciával
- BANKMENTES részletfizetés Noblechairs HERO Fekete/Platinafehér Gamer Szék
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest