Hirdetés
-
Premier előzetesen a Demon Slayer -Kimetsu no Yaiba- Sweep the Board!
gp Elérhető lett Switch-re a játék, amely leginkább a Mario Party-hoz hasonlítható.
-
Ülésezik a hardveregylet
ph Az irodai készülékek és monitorok társaságát egy ház, egy egér és egy DAC egészíti ki.
-
AMD Radeon undervolt/overclock
lo Minden egy hideg, téli estén kezdődött, mikor rájöttem, hogy már kicsit kevés az RTX2060...
-
PROHARDVER!
OLVASD VÉGIG ALAPOSAN MIELŐTT ÚJ HOZZÁSZÓLÁST ÍRNÁL!!!
Új hozzászólás Aktív témák
-
stratova
veterán
Ez egybevágott volna a Hynix által kínált "leglassabb" 3.2 GHz (eff) GDDR5M-mel, ami még így is tekintélyes 51.2 GB/s sávszélességet jelentene, szemben Richland hivatalosan 2133-as (34.128 GB/s) és tuning mellett még többnyire stabil 2400-as DDR3 lehetőségével (38.4 GB/s). Ráadásul ha jól ertelmeztem a korábbi magyarázatodat, Richlanddél ellentétben nem csak a csúcsmodell kezelhetné mobil vonalon (A10-5750M DDR3 1866-at a kisebb modellek viszont 1600-at támogattak csak, az LV és ULV modellek pedig 1333-at [ehhez képést Intel itt is DDR3 1600-at ír]).
[ Szerkesztve ]
-
#12906
marcell991
tag
Fiery
#12903
marcell991
tag
Az a nagy kérdés, hogy az IGP-t a Kaveriben mennyire lassítja a kisebb memória-sávszélesség. Ha nagy tempónövekedést lehet elérni GDDR5M-mel (normálisan lehet etetni az IGP-t), akkor szerintem elhibázott döntés kihagyni a kereskedelmi termékből. Ráadásul lehetne rendesen marketingelni (főleg mobil vonalra lenne értelme), hogy ez az AMD válasza az Intel Iris-re, mivel láttam már olyan tesztet, amiben a mobil i7 (megnövelt TDP-s) jóval az asztali A10-6800K felett teljesített.
Developers, developers, developers, developers! http://youtu.be/KMU0tzLwhbE
-
lee56
őstag
Az nem lehet hogy már a DDR4-re készülnek (tesztelik a több csatorna beépíthetőségét, helyigényét, gyárthatóságát), ott ugye minden új memmodulhoz egy csatorna fog társulni ha jól emlékezek az előzetes infókra. Amúgy ha már működik mind a négy csatorna, akár DDR3-al is ki lehetne használni? A legerősebb IGP-nek már lehet nem lesz elég a két csatornás sávszél, főleg tuning mellett.
No Comment
-
Oliverda
félisten
Lehet. Ahogy itt elnéztem még működne is, mert egyesek megváltóként látják a GDDR5-öt, holott szerintem több negatívuma lenne mint amennyi plusz tudna adni. Szívesebben látnék valamilyen kisebb méretű, lapkába vagy tokozásra integrált gyorsítótárat (ala Iris Pro).
"Minden negyedik-ötödik magyar funkcionális analfabéta – derült ki a nemzetközi felmérésekből."
-
Oliverda
félisten
Ahogy nézem százalékosítva itt sincs nagyobb difi 1866 és a többi között.
"XMP results aren’t important for Adata and Patriot, since the A10 APU wasn’t stable at DDR3-2400 using any memory kit."
Mondjuk ezt nem tudom hogyan hozták össze, illetve inkább hogyan nem.
"Minden negyedik-ötödik magyar funkcionális analfabéta – derült ki a nemzetközi felmérésekből."
-
dezz
nagyúr
Beleszámoltad, hogy a GDDR5 effektív órajele a duplája a DDR3-nak, azonos valós órajel mellett? A 3 GHz irracionálisan alacsony, 6 GHz viszont ésszerű plafonnak.
(#12918) Oliverda: Sok OEM-es cucc kapható a kereskedelemben... Ez miért ne? Mármint, a GDDR5M modulokra gondolok. Az viszont lehet, hogy csak jövőre jelenik meg majd valamikor, hiszen csak nemrég szabványosították.
-
dezz
nagyúr
Hát, nem tudom, a HD8570/HD8670/R7-250-en (Oland, 384 sp) 4600-as GDDR5 van... Kaveriben 512 sp lesz.
Azért is furcsa lett volna a 3 GHz, mert ott az alapórajel 750 MHz, ami 1500 MHz-es DDR3-nak felel meg abból a szempontból, hogy az alapórajel hajtja a belső memóriacellákat is. Ha jól tudom legalábbis, GDDR5-nél sincs duplázva.
A Trinity/Richlandből nem feltétlen kell kiindulni, lehet valami bottleneck a memóriavezérlőjükben.
(#12934) Oliverda: Elméleti plafonnak gondoltam a 6 GHz-t.
Gondolom, nem csak az AMD kedvéért hozta létre a Hynix a GDDR5M szabványt.
[ Szerkesztve ]
-
lee56
őstag
Igen így utólag átgondolva tényleg nem sok értelme lenne, ha meg 128-bitesnél nagyobb vezérlés lenne az meg túlságosan megdrágítaná az egészet.
Igazából amire kiváncsi lennék, hogy majd a DDR4-el hogy oldják meg, mert ez hogy csatornánként egy modul, ez kicsit behatároló is lehet. Pl aki csak egy modult használ, akkor 4/ed sávszélre korlátozza magát majd? Olcsóbb lapokon lesz only két memória slot, aranyárban meg up to négy?
Ott vajon már megérné bevezetni nagyobb bites kontrollert, vagy a DDR4 sávszél alapból elégséges lesz sok csatornával? Két nextgen APU-val (IGP-vel) odébb, reálsian nézve ezek ugye már komoly teljesítményt befolyásoló kérdések lehetnek.[ Szerkesztve ]
No Comment
-
lee56
őstag
Én úgy tudtam ennél azért radikálisabb változások lesznek :
Ezt találta meg legelőször a google.
Memóriavezérlő helyett gondolom csatornát akartak írni, de amúgy máshol is hasonlót olvastam róla, hogy ilyen lesz.Ezzel a kettővel előre gondolattal csak odáig akartam kilyukadni, hogy majd azok IGP-je - ezt ki is emeltem
- már biztosan nem fog megelégedni egy mai átlagos DDR3 társaságával. (Magyarul visszafogja majd, és nem csak játékokra gondolok. Mert ha tényleg beindul jobban a GPGPU biznisz, s az IGP-k sokkal jobban ki lesznek használva mint manapság, akkor megnőhet a sávszélességéhségük is nem?) Tehát valami új kell majd, hogy ez GDDR5 vagy 5M vagy DDR4 az majd idővel kiderül.Ja most nézem a hozzászólásokat, ti ugyanazok a Fiery-k vagytok?
[ Szerkesztve ]
No Comment
-
Abu85
HÁZIGAZDA
Direkten azért nem nyilatkoznak az AVX-ről hátrányosan az AMD-nél, mert nekik is van AVX-es rendszerük. Ami történik, hogy John Gustafson otthagyta az Intelt és az AMD-hez ment. Pletykák szerint az Intel küldte el őt is, ahogy Michael Abrasht és Andrew Richardst. Ugye ők voltak az elsők, akik azt mondták, hogy a MIC nem fog működni. John Gustafson mélyebben dolgozott ezen a projekten, tehát többet láthatott, mint két programozó. Az AMD terveiből azután került ki az AVX további támogatása, hogy Gustafson munkába állt. Könnyen lehet, hogy elmondta nekik, hogy nem működik. De valszeg valami sejtésük úgyis volt róla, ha már két top programozó nem nyilatkozik róla kedvezően. Andrew Richards egyszer erről írt egy cikket, hogy miért nem fog működni, de az Intel mindenhonnan levetette.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem én számoltam ki. Dally mondta korábban, de elvben nézzük meg mi is: ha a GCN-t számítjuk, akkor 28 nm-en 1 TFLOPS-hoz 8 CU kell (1 GHz-es órajelen, ami normává válik). Ennyit ~24 mm2-be lehet ma beépíteni, mert egy CU ~3 mm2. Ekkora területre ma 4 MB-nyi SRAM helyezhető 28 nm-en. Persze 5 MB-ról volt szó, de változók az architektúrák, tehát könnyen lehet, hogy Dally nem a GCN-t vette elő. Az alapvető mondandója viszont igaz.
Az AVX is OpenCL-lel használható ki a legjobban, ugyanúgy, mint az IGP-k. Ezért erősítette meg az OpenCL támogatását az Intel, mert több fejlesztő jelezte, hogy sokkal hosszabb kódot kell írni TBB+intrinsics mellett, ami lassabb lesz. Persze az OpenCL-lel sincsenek kibékülve a fejlesztők, de az MS dolgozik a C++AMP fejlesztésén. Az felkínálhat egy arany középutat.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
-
Abu85
HÁZIGAZDA
Én nem, de több játékfejlesztő is mondta, hogy OpenCL-lel jobb erdmények érhetők el az AVX2 kihasználása kapcsán, mint TBB+intrinsics mellett. Szerintem ez a fő oka annak, hogy az Intel ennyire sok erőforrást öl az OpenCL-be. Ők is belátták, hogy bőven van olyan algoritmus, amit OpenCL-ben könnyebb megírni AVX2-re. Ennek egyébként kifejezetten örülnek a fejlesztők, annak már nem, hogy a tömegprocikból hiányzik az AVX2, tehát kaptak is segítséget meg nem is. Az OpenCL-en azonban nagyon rajta van az Intel, és erre a platformra épülő játékokat szeretnének látni.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
dezz
nagyúr
Onnan indult a dolog, hogy Abu CPU magok mellé integrált tizenvalahány MB-os cache-ekről beszélt, ami (normális esetben) a sima SRAM területénél is többet igényel, per MB. Erre te a sokkal kisebb helyet foglaló és sokkal lassabb eDRAM-ot hoztad fel, csak mert azt ott L4 cache-nek hívják. Hát, ez nem egészen fer...
Emlékeim szerint a (L1-L3) cache memória mindig is SRAM volt, legalábbis x86 vonalon. Hiszen éppen a sokkal lassabb aktuális DRAM kiváltására szolgált.
Azért lettem volna kíváncsi az eDRAM, mint cache, implementálására, hogy kiderülhessen, akkor ez most sima DRAM vagy vagy valami más, ami nagyobb területet foglal annál és gyorsabb is. Ha sima DRAM, akkor a main ramhoz képesti nagyobb sávszélességet leginkább a tokozáson belül megvalósítható szélesebb busz biztosíthatja. Bár kétlem, hogy MCM-ben szélesebb lehetne, mint 128 bit. Igaz, a main rammal együtt ez már min. 256 bit. Vagy, ha nem lehet így összevonni őket, akkor legalább nem a main ram elérését lassítják a grafikai/computing műveletek.
Kicsit utánanézve, az eDRAM a L3 victim cache-e itt. (Az onnan kilökődő adatcsomagokat tárolja.) Így valószínűleg sima DRAM. Gyakorlati szempontból egy lokális frame-/texture buffer, ami képes gyorsítani az Iris Pro működésén, de sok-sok kis CPU mag kiszolgálására nem alkalmas.
[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
Hivatalos bejelentés hiányában nyilván minden csak sejtés, vagy pletyka, de a Skylake IGP-jét Ofri Wechsler csapata fejleszti. Jelenleg ők felelnek azért a szoftveres futószalag kidolgozásáért, mely elvben biztosítja, hogy a MIC grafikára is jó legyen. "IA GFX Proof-of-concept" tanulmány.
Az igaz, hogy az Intel nem erősítette meg, hogy MIC lesz a Skylake-ben, de Ofri Wechsler személye gyakorlatilag eléggé konkrét adat erre vonatkozóan.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
dezz
nagyúr
Azért, mert Abu nyilvánvalóan nem ilyen, eDRAM L4 cache-re gondolt, hanem normál SRAM cache-re, ami sokkal nagyobb helyet foglal, per MB.
"De nem veletlenul hivjak 4.szintu cache-nek: ahogy megyunk a szinteken felfele (szamozas tekinteteben), egyre lassabb minden cache lepcso, ez eddig is igy mukodott a cache-eknel, CPU-gyartotol fuggetlenul."
Tényleg? Szerinted ezt ki nem tudja itt?
"Van ossz-vissz 4 mag, az nem sok-sok"
Pfff, az nem merült fel benned, hogy a "sok-sok kis mag" a MIC-re vonatkozik?
"A Skylake MIC implementacioja pedig me'g mindig nincs megerositve az Intel reszerol, csupan sejtesek vannak."
Hát egy biztos: a MIC mellé kevés lenne az eDRAM egyedüli cache-nek.
-
dezz
nagyúr
Szerintem az beszél magas lóról, aki hülyének nézi a másikat (miután külön jeleztem, hogy nem kell szájbarágósan magyarázni, de nem is tudom, hogy gondoltad, hogy én vagy akárki más itt nincs tökéletesen tisztában pl. azzal, hogy az egyre magasabb besorolású cache-ek egyre lassabbak, stb.). Ezt hadd utasíthassam vissza...
Sejtettem, hogy az eDRAM is sima DRAM, éppen ezért kérdeztem, amit kérdeztem, hátha te tudsz olyat, amit én/más nem.
Kétlem, hogy egy nagyobb DRAM cache kiválthatna néhány MB CPU magok melletti L2/L3 SRAM cache-t.
A nagy lemaradásból való gyorsabb felzárkózás egyátalán nem jelenti azt, hogy ugyanilyen lendülettel meg is előzik a másikat.
-
leviske
veterán
Bocsánat, hogy beleszólok, de a Richland azért van ott ahol, mert a memsávszél nem túl combos. Nyilván nem véletlen, hogy a GDDR5 támogatása felmerült, ami a gyártóknak eleve pozitív volna, hiszen hasonló kiszerelésben saját maguk adhatnák el az APU-kat, mint a videokártyák esetében.
Tessék megnézni az új Radeonok, meg az Iris Pro lapkaméret/teljesítmény mutatóját és aztán tessék figyelembe venni, hogy mi lesz, ha esetleg a Mantle és HSA hamarabb elterjed, minthogy az Intel végrehajtsa a bámulatos bűvészmutatványát, amivel hirtelen az AMD elé ugrik, miközben egy normális drivert nem képesek az asztalra lerakni.
Nyilván nem akarom fikázni az Intelt, hiszen hasonló helyzet áll fenn, mint anno az Athlon / Pentium idején és akkoriban jól kitudták magukat vágni, de el kell ismerni, hogy a desktop piacon aktuálisan trendnek nevezhető el"gamer"esedés (fúj, de meggyalázom néha a magyart) határozottan az AMD-nek kedvez, ahogy az ARM-es gyártók HSA-felé fordulása is.
-
#13009
marcell991
tag
Fiery
#13007
marcell991
tag
Szerintem a HSA egyik fontos tulajdonsága, hogy gyakorlatilag az egész ARM-os ökoszisztéma mögötte van. A szoftverfejlesztőknek pedig a HSA lesz az első választása mobil fronton, ha azt látják, hogy a piac friss mobil eszközeinek a nagytöbbsége futtatja a kódot, ráadásul sokkal gyorsabban, mint eddig (itt nem csak az applikáció fejlesztőker gondolok, hanem a rendszerfejlesztőkre is). Az Intelnek a maga pár százalékos mobil piaci jelenlétével pedig nem hiszem, hogy lesz ideje olyan technológiát kidolgozni, amit a HSA ellenében küldhetne. Ugyanígy az AMD-nek is okosan kell a dolgait rendeznie, mert ők pont az Intel "felségterületén" akarják a HSA-t elterjeszteni.
Developers, developers, developers, developers! http://youtu.be/KMU0tzLwhbE
-
dezz
nagyúr
Szóval, az AMD azért szar, mert csak egy lépéssel hagyták le az Intelt, nem kettővel... Világos.
(#13007): Majd ha a Crystal Well átlagos gépekben is megtalálható lesz, akkor emlegesd...
Valójában előzőleg is erőből nyomták le, hiszen megtehették, hogy párhuzamosan több fejlesztést pénzeljenek, nagyobb fejlesztőcsapatokkal, stb. Aztán azt vegyék elő, amelyik a legjobban beválik.
A
HSA-tMIC-et pedig varjuk ki. Vagy mukodni fog, vagy nem.A GPU-k teljesítménysűrűsége jóval nagyobb a CPU-kénál, ez tény. Ez ellensúlyozható fejlettebb processzel, de vajon mekkora processz-előny kell ahhoz az Intelnek, hogy ezt valóban el is érjék?
A Physix rossz példa, az a bizonyos "dedikált fizikai gyorsitó" valójában egy viszonylag egyszerű (3rd party?) DSP volt, saját szoftverrel.
"Ennyi." - Amennyit értesz belőle.
"es utemezes (queuing) gyerekjatek" - Azért jön majd csak jövőre pl. az Nvidiánál, tudomásom szerint.
"(akár a VIA is), nem nagy kaland" - Meg sebtiben összedobnak hozzá egy világklasszis GPU-t is.
"csupan koherens memoria kezelest kell implementalni." - Ami valahogy az Intelnek sem jött még össze.
"egyeb maszlagokat" - C++, C++ AMP, .NET támogatás...
"Nem kell hozza csatlakozni a HSA Foundation-hoz." - Minek is beállni egy lassan iparági szabvány mögé, félkézzel lenyomjuk a fél világot... Vagy talán mégsem.
pl. mikor neveztek ki Intel szóvivőnek?
-
Abu85
HÁZIGAZDA
Az Intelnek a MIC-kel pont az a problémája, hogy sokkal több tranyó beépítésére lenne szükségük, mint ami lehetséges. Az eDRAM az nem elég jó, ami jó lehet az az FBC, de még nincs kész. Az SRAM meg túl drága.
A Haswell IGP-hez képest bárki előáll minőségi ugrással. Kétszer több tranzisztorból áll a GT3, mint a legerősebb Trinity IGP. Eközben eDRAM nélkül még lassabb is. Ezért nincs ebből sima asztali verzió.De az Intel baja nem a hardver, hanem a driver. A Haswell még az új parancsprocesszor ellenére is úgy működik, hogy a processzor felel a teljesítmény maximalizálásáért. Ez nagyon lassú. Annyit csinál ma az Intel, hogy a népszerű játékokra ráoptimalizál, de ha olyanon játszol, amit nem vettek számításba, akkor rögtön tízszer lassabb a hardver a konkurenshez képest (csak a driver miatt).
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem is lesz közös cache az AMD termékeiben. Sosem. Ez a koncepció ott problémás, hogy nem engedhető meg, hogy a CPU adatait teleszemetelje az IGP. A CPU jól követhető rendszer, hiszen egy mag maximum két szállal dolgozik. Egy IGP multiprocesszor (például GCN) minimum 256 szállal, de akár 2560 szállal is dolgozhat. Ahhoz, hogy a CPU és az IGP közös gyorsítótárazást használjon drámaian csökkenteni kell a multiprocesszorokban a feldolgozási szálak számát. 10 alá mindenképp, itt viszont felmerül az a probléma, hogy oké mostantól jöhet egy közös LLC, de közben kivégeztek az IGP-ben mindent, ami hatékonnyá tesz egy ilyen elven működő rendszert.
Szóval közös LLC-t ne várj az AMD-től, mert már rég elvetették ezt az irányt, hiszen a gyakorlatban nem működik jól.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az egy dolog, hogy ezt valaki elvárja, de miért kellene az AMD-nek egy ilyen koncepcióra építenie, csak azért, mert az Intel szerint ez a jó irány. Azóta dolgozik ezeken a problémákon egy csapat, amióta megvették az ATI-t. Több tucat implementációt szimuláltak az elmúlt 6 évben, és arra jutottak, hogy a leghatékonyabb az amivel dolgoznak. A gyakorlatban leghatékonyabb.
Emlékszel még a Sandy rajtra? Az NV, az AMD és mindenki azt mondta az LLC-re, hogy hülyeség. Az Intel erre azt mondta, hogy átgondolták, és az elméleti alapok azt mutatják, hogy ez a leghatékonyabb, és biztosak benne, hogy a gyakorlatban is működni fog. Azóta már letiltottál az IGP írását az LLC-be a Sandy-nél és onnantól kezdve minden generációban. Pedig az elmélet rendben volt.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
leviske
veterán
"lapkameret/teljesitmeny mutato ma mar nem er semmit, nincs jelentosege."
Valami elkerülte a figyelmem, vagy esetleg az Intel gyártástechnológiai előnyére gondolsz? Csak mert ha utóbbi, akkor azért én előbb megkérdezném az Intelt, hogy mennyivel is csökken az elkövetkezőkben az egy tranzisztorra jutó költség gyártástechnológiai váltásonként, mielőtt kijelentem, hogy nincs jelentőssége. Meg eleve felmerül a kérdés, hogy az Iris Pro miért is nem került be minden termékbe, ha ennyire mindegy az Intel számára az anyagköltség? Csak mert nyilván nem a kategóriáját messze felülmúló teljesítmény az ok, hiszen arról azért a Richland fényében nemigazán beszélhetünk."De ki mondta, hogy ezeket a feladatokat (es me'g sok mas feladatot) mindenkepp az iGPU-val kell megoldani?"
Nyilván senki. Viszont erre az Intelnek eredetileg a Larrabee akart a válasza lenni, 3 évvel ezelőtt. Azóta se sikerült desktopon bevetni.Tulajdonképpen minek kéne lennie a HSA-nak szerinted ahhoz, hogy "elismerhető" alternatíva legyen? És miből gondolod, hogy az Intel mögé bárki beállna az ARM-es csapatból? Pláne, hogy több éves lemaradásban volna, ha saját technológiával állna elő.
-
Abu85
HÁZIGAZDA
Ha csak az 1TFLOPS-ra szűkítsük le a dolgot, akkor olyan 22-30 MIC mag kell, függően az órajeltől. Legjobb opcióval számolva is 1,7 milliárd tranzisztorról van szó csak az IGP-re, mert szerintem 22 mag 1,5 GHz-en kivitelezhető. De ami a nagyobbik probléma, hogy a MIC ma mindent emulál, kivéve a textúrázást. Tehát reálisan túl kell tervezni a hardvert a ROP és setup emuláció miatt. A tesszelláció még kérdés, de az emuláció reális, mert binned render az ideális a rendszerhez, így eleve lesz a hardvernek egy maximális háromszög-kezelési képessége, tehát amelyik program ezen túlmegy ott úgyis lehal az architektúra sebessége, mert be kell vetni a mélységpuffert.
Ha a Kaveri IGP sebessége a cél, akkor úgy 2 milliárd tranzisztor kell majd hozzá a MIC alapjain.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Magonként 512 kB kell a MIC-nek. A 256 kB nagyon kevés, viszont az 1 MB-ból még profitál, de csak ritkán, tehát minden szempontból a fél MB cache/mag az optimális.
22 MIC mag 1,5 GHz-en elég lenne a Kaveri IGP-je ellen. Csak magasabb felbontás mellett és részletes geometriai vázzal lenne lassabb a rendszer. De a részletesség amúgy is gond, mert csak addig működik jól a MIC, amíg nem kell mélységpuffer.
Ami nagyobb gond lesz, hogy ma a PC-re dolgozó fejlesztők nulla olyan alkalmazást készítenek, ami képes megmondani, hogy egy mozaikon belül betöltötte-e a rendszer az összes háromszöget. A MIC-nek alapvetően fontos az információ, mert enélkül képi hibákat generálhat. Ezenkívül para lehet, hogy minden eddiginél komplexebb drivert kell írni, de szerencsére ez csak szoftveres kérdés.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#13025
Mahrenburg
senior tag
Fiery
#13015
Mahrenburg
senior tag
A VIA-nak van Kabinihez hasonló fejlesztése, ami belátható időn belül megjelenik, vagy bármilyen (többé-kevésbé) versenyképes alternatívája?
[ Szerkesztve ]
"Egy fel nem használt Phenom II matrica olyan mint egy nap ami sosem kelt fel, egy múló szerelemről szóló dal amit sosem énekeltek, egy harcos szív amely sosem dobbanhatott..!" by Habugi
-
dezz
nagyúr
A Kaveri cache és memóriakezelési implementációjára gondoltam, ami szerinted tákolmány. Az Intel megoldása persze nem az, miközben bebukták az LLC-s megoldást és inkább odatettek a Haswell mellé egy nálánál sokkal nagyobb lapkán 128 MB eDRAM-ot, mint a L3 victim cache-e, koherens és unified main ram kezelés meg sehol. De az jó.
"Ki mondta, hogy maradni fognak mindig a mostani felallasnal? Nyilvan, ha maradna mondjuk a Haswell IGP-je (Gen7.5), es csak a processzt csiszolna az Intel alatta, annak nem lenne semmi ertelme."
Ezért írtam a megelőző mondatban, hogy "A GPU-k teljesítménysűrűsége jóval nagyobb a CPU-kénál, ez tény.", amivel a MIC-re utaltam, ami jelen állás szerint az Intel köv. gen. IGP-inek alapja lesz nagy valószínűséggel.
Annó ezt olvastam valahol, de most megnézve egy pármagos MIPS CPU egy "adag" SIMD egységgel. Az utóbbit akár mondhatjuk GPU szerűnek is. Összességében pedig APU szerű...
A válasz a kérdéseidre nem. Viszont programozó vagyok és "bele tudom élni magam" a használatába.
"Az AMD sincs kesz a sajat HSA implementaciojaval. A Kaveri nincs piacra dobva, a HSA SDK me'g beta allapotban sincs. Az egesz HSA csak jovore jon, iden nem lesz semmi kezzelfoghato belole."
Dehogynem: PS4. (Félig-meddig az XB1 is.)
"De a korites a vas kore nem nagy cucc."
Ezt majd akkor mondd, ha magad is terveztél effélét. (Véletlenül FPGA programozással is foglalkozom, és tudom, hogy nem olyan egyszerű ez, mint amilyennek a laikusok elképzelik.) Azt persze nem vitatom, hogy többen is képesek rá. Sőt, több ARM-os cég nagyban dolgozik rajta.
A másik dolog, hogy mit ér a körítés, ha nincs hozzá vas?
"Meg nem is erre akartam ravilagitani, hanem arra, hogy a HSA-t baromi konnyu lekoppintani. A HSA egy jo otlet, csak mint otlet nincs levedve. Barki megcsinalhatja ujra, teljesen kompatibilis lesz a magasszintu kod (pl. OpenCL, Java) szintjen, csak nem HSA-nak fogjak hivni."
Ezt aláírom, de redundáns meló újra megcsinálni az egészet, csak hogy kicsit más legyen, miközben elég lenne egy egyszerű drivert írni a HSA virtuális API-jához.
"Nem veletlenul nem jott ossze. Nem azt az iranyt eroltetik, csak ezert nem jott ossze."
Valószínűleg nagyban készül a hagyományos CPU magokat a MIC-kel/-vel ötvöző hibrid procijuk, aminek szerves része kell legyen a koherencia az összes mag között és a unified memória. Ki tudja, talán éppen ezzel szívnak éppen... Szerintem, ha meglenne már, nem bohóckodtak volna az Iris Proval...
"az AMD-nek meg az eDRAM "nem jott ossze" " - Talán mert 28nm-en sem lenne elég gazdaságos...
(Az utolsó előtti bek. két kérdésére fent megvannak a válaszok.)
[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
A HSA az nem csak CPU és IGP integrációja. Annak van egy memória és queueing modellje. Ha a Kabini/Temash kapott volna HSA-MMU-t, akkor képes lenne támogatni. A Beema/Mullins kap IOMMUv2.0-t, ami a beugró a HSA-ba. Ugyanolyan támogatása lesz így ennek mint a Trinity/Richland APU-nak.
A PS4 egyébként HSA toolokkal lesz használható. Ezért lépett be a Sony az alapítványba. Az MS rendszere is hasonló, de ők más toolokat használnak majd (C++AMP továbbfejlesztésekben gondolkodnak).
Technikailag egyébként egyik hardver sem az AMD hUMA modelljét implementálja, bár a Sony-é tényleg nagyon hasonló. A queueing modell a PS4 esetében megegyezik az AMD megoldásával, de az X1 itt is használ eltéréseket.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem követelmény a megosztott memória, sosem volt az, csak ajánlott. Még a HSA-MMU sem követelmény, csak ez kell ahhoz, hogy egy HSA alkalmazás ne legacy módban fusson. Ennek az alapverziója az IOMMUv2, amivel az IGP eléri a teljes CPU memóriát. A modernizált verzió az IOMMUv2.5, ami lesz a Kaveriben és ez a kombináció a GCN-nel a HSA full profile large módját támogatja.
A HSA alapötlete eleve az, hogy egy forrásból szolgálj ki mindent. Meg kell írni C++-ban például és annál jobban fog menni, minél több funkció van a hardverben. De nincs követelmény, mert legacy módban bármin elfut, de base profile small módban is fut számos aktuális hardveren.
A Trinity/Richland HSA base profile large módot támogat.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
dezz
nagyúr
"Arra a PS4-re gondolsz, ami egy zart rendszer"
Attól még vanni van.
"es olyan HSA-capable APU van benne, aminek "furcsamod" a PC-s megfeleloje (Kabini/Temash)"
Ez egy induripindurikát félrevezető így...
"valamint annak utodja (Beema/Mullins) sem kepes a HSA-ra?"
Talán mert azon kívül, hogy Jaguar és GCN, nem sok közük van egymáshoz?
"Mennyire relevans az a platform ezek utan egy Kabini, Kaveri, Carrizo topicban?"
Inább, mint a Haswell...
"Megjegyzem, eleg nagy szegyen, hogy a Beema/Mullins sem tamogatja a megosztott memoriat, mikozben ott a PS4... Az AMD-nel sem minden rozsaszin azert."
Ezt mondjuk én sem értem.
"Van az Intelnek vasa (iGPU) hozza"
Nem kimondottan az Intelre gondoltam, hanem bárkire. Pl. Via.
"Lekoppintani pont ugyanakkora melo"
Ebből és ebből könnyebb mindent újra megcsinálni a világos zöldön kívül, mint csak a kéket?
Hát a virtuális API? Azt 1:1 koppintanák, vagy mégiscsak sajátot készítenének? Annak átgondolása és kialakítása sem 5 perc. (A HSA Foundationnek fél-egy évig tartott. Igaz, itt több cég között kellett egyeztetni.)
"es az Intelnek meg is eri, ha utana tudja verni a mellét, hogy azt o talalta fel."
Ha előállnának egy HSA koppintással, ami azért se kompatibilis vele, és vernék a mellüket, közröhej tárgya lennének...
"Arrol nem is beszelve, hogy mar elofordult nehanyszor a tortenelemben, hogy az Intel is megcsinalt valamit, amit mas mar kitalalt, es vegul az Intel megoldasa me'g jobban is sikerult, mint amit lemasolt."
Pl.?
-
Abu85
HÁZIGAZDA
Igen, technikailag annyi az előnye a HSA-nak, hogy ugyanazt sokkal rövidebb kódból kihozod. Akinek számít, hogy negyedannyi kódsort ír be, az ezt választja majd. Vagy megvárják a C++AMP-t. Az is ilyen HSA-féle vISA irányba szeretne elmenni.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
leviske
veterán
"annak ellenere is tobbet tudtak eladni"
Ezen a ponton értük el az ovis színvonalat és ezért inkább javasolnám a vita lezárását. Ez a topik a Kaveri/Carrizo és az AMD szerver platformjainak lenne elvileg szentelve. Az Intel még meg nem jelent termékeinek a hősies csodatetteiről valamelyik Inteles pletykatopikban érdemes tovább folytatni a diskurzust.
Bár nyugodtan jelentkezzen, akit ez érdekel.
-
Abu85
HÁZIGAZDA
Marketingben minden cég kb. ugyanakkora bullshiteket nyom. Ez már ki tud nagyobbat mondani verseny. Az AMD csak annyival csinál többet, hogy az Anandtechnél és számos médiánál befizettek egy külön oldalt, ami csak az AMD-vel kapcsolatos független és hivatalos PR anyagokat gyűjti össze kizárva minden más anyagot. [link] - ilyeneket bárki más befizethet, amellett egyébként, hogy az Anandtech mondhatta volna azt is, hogy ilyenben nem vesznek részt. Bár hátrányosan ez őket nem érinti.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
leviske
veterán
Nem az Intel zavar, hanem mikor lesüllyed egy beszélgetés az "én apukám erősebb, mint a tiéd" színvonalra. Rengeteg forrása van a cégnek, ez vitathatatlan. Viszont kijelenteni egy meg nem jelent, sőt be sem jelentett megoldásról, hogy az bizony eladásokban állva hagyja a kb 1 hónap múlva milliószámra eladott ellenfelét (gondolok ez alatt a Kaveri csöndes startja mellett a konzolok kevésbé csöndes érkeztére), az erősen szemellenzős látásmódra utal.
"a HSA lenyegi resze tul konnyen lekoppinthato"
Egy nyílt rendszerben pont ez a csodálatos. Egészen más piaci helyzetet láthatunk magunk előtt, ha az Intel "lekoppintja", mintha a MIC alap elképzelése terjed el. Arról viszont még nem sikerült meggyőzni, hogy miért annyival jobb az Intel elképzelése, hogy véleményed szerint a semmiből letudná tolni az AMD évekkel korábban megjelent megoldását. Pont az általad említett X86-64 vs IA-64 helyzet a példa arra, hogy mennyire lényeges, hogy a fejlesztők mit látnak kifizetődőbbnek használni. A Larrabee buktája és az ARM-el vívott harc pedig arra szolgáltatnak példát, hogy nem tudnak belépni csak izomból egy piacra.
Külön jegyzem meg, hogy az nVidia-t a HSA-val szembeállítani egy kicsit korainak érzem, elvégre nem a Mantle-ről beszélünk, ami a GCN köré lett megírva. A HSA és az nVidia tervei aránylag egy irányba tartanak, ami az nVidia/Intel viszonyáról nem mondható el. Emellett a HSA kapcsán sem csak az AMD-t kéne megemlíteni, ha már nyitnánk egy ilyen topikot.
-
Abu85
HÁZIGAZDA
Senki sincs senkivel a HSA alapítvány tagjai közül. Számos cég direkt konkurense a másiknak. Nem egymást akarják segíteni és főleg nem az AMD-t. Mindenki érdektelennek tekinti azt, hogy a Samsung vagy az AMD részesedése nő-e vagy csökken. Csak azért léptek be az érintett cégek mert olyat kínál a HSA, amit más még nem kínált fel, vagy önerőből túl időigényes lenne kifejleszteni. Úgy vannak vele a cégek, hogy lerakják a szoftveres alapokat közösen aztán majd hardverből versenyeznek.
A legfőbb probléma egyébként az Android szegmentáció. A Google az OpenCL-t nagyon nem akarja, de a HSA-tól nem zárkóznak el, mert nem okoz szegmentációt, illetve a saját Renderscriptjükhöz is nagyon illik a platform. Ez a fő oka amiért az ARM-os cégek zöme ott van.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
dezz
nagyúr
Nos, akkor a "körítés" a Jaguar CPU magok és GCN(2) CU-k között lehet akár teljesen más architektúra is, mint ahogy más is.
"Ha kiegeszitik a HSA mas elonyeivel (gyors kernel launch, jobb queing, videodriverrol valo levalasztas), akkor szinte minden elonyet atveszik a HSA-nak, anelkul, hogy HSA-nak "kellene" hivniuk."
Szinte? Csak az egyik legfőbb összetevőt hagytad ki, a HSAIL-t és a hozzá tartozó virtuális ISA-t, amik biztosítják, hogy ugyanaz a lefordított bytecode más gyártók megfelelő termékein is futhat, mégpedig a rendszer kidolgozása által viszonylag optimálisan.
"Barki, aki nem akarja magat bezarni az AMD okoszisztemajaba"
He? Már a fél világ átvette a HSA-t, tucatnyi gyártó termékei készülnek hozzá/vele.
"Egyebkent ha a MIC tenyleg HSA-szeru lesz, akkor ha OpenCL-re programozol, akkor megkapsz mindent, amit a HSA-val kapsz, legfeljebb nem pont ugyanazt a teljesitmenyt a vegen (a GCN2-t nehez utolerni)."
Kisebb teljesítmény és/vagy jelentősen rosszabb telj./fogy. Az sem biztos, hogy az Intel HW-re fejlesztett OpenCL kód jól futna máshol és fordítva. Bár ahogy az Intelt ismerem, éppen erre építenének. Ami viszont visszafelé is elsülhet.
"eddig egyetlen esetben nem sikerult (AMD64)"
Hasonló a helyzet, az Intel megint utólag próbálna másokra erőltetni egy hasonló, de mégis más megoldást.
"Csak a source végén kompatibilis (OpenCL)"
Nem. Nézd meg, mire válaszoltam: "Viszont ha az Intel lekkopintja a HSA-t, akkor neki nem kell uj forditot irnia, hanem csak a drivereket: joval kisebb melo." - Akkor nem kellene új fordítót írnia, ha a HSAIL-t és a virtuális ISA-t is lekoppintaná. Amit persze nem tehet meg. (Csak ha belép a HSA Foundationbe és leszurkolja az árát.)
"QPI: mondjuk nezzuk meg, milyen piaci penetraciot ert el az egyik mára, es a masik."
Egyrészt az nem a QPI érdeme. Másrészt a QPI csak LGA2011 és Xeon vonalon is csak egyes szegmensekben található meg, így nem vagyok róla meggyőződve, hogy a millió számra eladott {minden, ami nem APU} nem veri eladásokban. Harmadrészt a QPI egyszerűbb, mint a HT.
"Sajnos a technologiai innovacio vegso ertekmeroje az eladasi darabszam ill. a realizalt profit. Ott pedig az Intel vs. AMD osszehasonlitast szinte sosem az utobbi nyeri."
Szerintem meg nem a pénz a végső értékmérő...
"A dGPU-kat egyebkent sem kellene direktben egy CPU-hoz hasonlitani, teljesen mas teszta"
Csak egy részegységről volt szó.
"Szoval SZVSZ boven eleg lenne a Skylake-nal, ha hoznak mondjuk a Trinity iGPU teljesitmenyet egy HSA-szeru, MIC vagy nem MIC alapu iGPU-val."
Kommersz PC vonalon valószínű így van (elég baj az), más szegmensekben nem feltétlenül.
(#13046) Abu85: Huh, hát ezt próbálják meg processzel ellensúlyozni...! Még a 14nm is kevés hozzá.
[ Szerkesztve ]
-
stratova
veterán
Én például éppen ebbe kezdek belefáradni. Nagyítóval kell keresni az igazán ütős AMD-s gépeket.
Amikor egyik nem notebookos topikban a régebbi generációk alapján beskatulyázott "AMD melegszik forró vacak, notiban inkább Intelt" felütésű hozzászólásra belinkeltem a Probook B-t, az volt a meglepetés a kedves fórumtárs számára, hogy ilyen gép egyáltalán létezik AMD-vel. Bár ez nem újdonság, Phenom II P650 (2 mag 2600 MHz, 45 nm, 25 W TDP) sem árasztotta el a piacot [azt is tán csak HP szerelte a gépeibe].
Igazán költhetnének az OEM partnerkapcsolatok ápolására, mert jó olvasni, hogy ilyen és amolyan fejlesztés és APU jött ki AMD-nél csak épp megvásárolni nem lehet Európa szerte a legütősebbeket. Erre a hazai forgalmazók csak rátesznek egy lapáttal
A HP meg Kaveri megjelenése előtt csak azért is (szvsz) elszúrja az új Elitebook/Probook szériát, de ne legyen igazam.
Ami engem kicsit meglepett egyik korábbi hozzászólásodban, hogy AMD a igény szerint bármikor integrálhat még több (>8) CU-t az APU-ba. Az odáig rendben van, hogy 4 Steamroller mag az asztalinál megszokott órajelen hozza 8 Jaguar teljesítményét, de nekem ez kissé hmm.. meredek. Mi lehet itt az a felső küszöb amit 4 Steamroller mag még kiszolgál, a PS4 18 CU-ja?
Esetleg arra lenne jó, hogy (GP)GPU oldalon megtartsa a teljesítménykülönbséget Boardwellhez képest (amit pletykák szerint nem is hoz asztali vonalra Intel).Említetted a az energiatakarékossági funkciók további javulását. Itt szerintem, azért is nehéz Intelt hajszolni, mert gyártástechnológiai lemaradásban vannak még AMD bérgyártói CPU/APU-k esetében.
2010 Intel 32 nm HKMG Bulk [Westmere - Nehalem-C]
2011 AMD 32 nm PD-SOI [Llano]
2012 Intel 22 nm tri-gate Bulk [Ivy Bridge]
2013-2014 AMD 28 nm HKMG Bulk [Kabini, Temash - Kaveri]
2014 Intel 14 nm tri-gate Bulk [Boardwell]Persze ezek mellett egyéb megoldásokkal is javította mindkét gyártó a telj/fogy. arányt, de jó lenne Carizzoval meglépni a 20nm FDSOI-t. GloFo-val kapcsolatos cikkekből ill. saját oldaluk alapján úgy vettem ki a 14nm-XM inkább a mobil SoC megoldásokhoz készül.
[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
A vISA a legfontosabb komponens, mert az biztosítja a kompatibilitást házon belül is. A HSAIL nem egyedi dolog. Minden cégnek van ilyen rendszere. Az NV-ét PTX-nek, az AMD-ét AMDIL-nek hívják stb. A HSAIL annyiban más mint ezek, hogy nem csak házon belül támogatott, hanem számos más gyártó által. Ez nem egy extra, hanem egy aktuális komponens lecserélése, amit ma is használ mindegyik OpenCL alkalmazás például. Az Intelnek is van ilyen, de az nagyon kimondhatatlan nevű, de a lényeg, hogy van.
A HSAIL annyi, hogy akik a HSA-t támogatják a saját vISA-jukat erre cserélik. Ezzel biztosítva egy igen alacsony szintű kompatibilitási réteget.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ Szerkesztve ]
Ott vajon már megérné bevezetni nagyobb bites kontrollert, vagy a DDR4 sávszél alapból elégséges lesz sok csatornával? Két nextgen APU-val (IGP-vel) odébb, reálsian nézve ezek ugye már komoly teljesítményt befolyásoló kérdések lehetnek.
Nem, nem kell szájbarágósan.
Új hozzászólás Aktív témák
A topikban az OFF és minden egyéb, nem a témához kapcsolódó hozzászólás gyártása TILOS!
Az ide nem illő hozzászólások topikja:[link]
MIELŐTT LINKELNÉL VAGY KÉRDEZNÉL, MINDIG OLVASS KICSIT VISSZA!!
A topik témája:
Az AMD éppen érkező, vagy jövőbeni új processzorainak kivesézése, lehetőleg minél inkább szakmai keretek között maradva.
