- Apple notebookok
- Kétféle tájolással munkára fogható, ITX-es ház jött a Sharkoontól
- Melyik tápegységet vegyem?
- VR topik (Oculus Rift, stb.)
- Milyen belső merevlemezt vegyek?
- Analóg fényképezés
- ThinkPad (NEM IdeaPad)
- Épített vízhűtés (nem kompakt) topic
- AMD Ryzen 9 / 7 / 5 / 3 3***(X) "Zen 2" (AM4)
- Havi kétszáz leégett tápcsatlakozó fut át egy Los Angeles-i szervizen
Hirdetés
-
The Witcher - Jön az 5. évad, ezzel együtt pedig elkaszálták a sorozatot
gp A negyedik szezon forgatása a napokban kezdődött el, kíváncsian várjuk mikor láthatjuk a végeredményt.
-
Sony Xperia bemutató lesz május 17-én
ma Különleges Xperia eseményt tart a Sony Tokióban, száz résztvevőt invitálnak.
-
Sorra osztja a dollármilliárdokat az USA a chipgyártóknak
it Az Intel, a TSMC és a Samsung után a Micron következik, ők is tetemes összegű támogatást kapnak az USA-tól a chipgyártáshoz.
-
PROHARDVER!
OLVASD VÉGIG ALAPOSAN MIELŐTT ÚJ HOZZÁSZÓLÁST ÍRNÁL!!!
Új hozzászólás Aktív témák
-
Fiery
veterán
Az (AMD) APU-knal eleve razos dolog beepiteni a cache-t. Az iGPU nem egy FPU, nem olyan relacioban van a hagyomanyos CPU-val, hogy csak ugy meg tudja osztani a cache-eket a CPU-val
Nem veletlen, hogy az APU-kban nincs es nem is lehet hagyomanyos ertelemben vett, a CPU-iGPU altal kozosen hasznalt L2 vagy L3 cache. Me'g a Kaverinal sem ugy mukodik az L2 cache sem, mint ahogy azt a jozan esz diktalna. Jobban hasonlit me'g a Kaveri is egy 2 socketes, cache snoopos megoldashoz, mint egy rendes cache koherenciaval implementalt rendszer. Takolas, mondjuk ki. Jol mukodik a gyakorlatban, de takolas. A Carrizo megint faragni fog ezen, ott pl. mar nem lesz letiltva a iGPU L2 cache-e a koherens memoria hasznalatnal, de ezek az apro lepcsok szamomra tul lassu fejlodesnek tunnek.[ Szerkesztve ]
-
-
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.
-
Fiery
veterán
válasz
leviske
#13004
üzenetére
Pont ezt irom, csak maskepp fogalmaztam, nem volt egyertelmu az uzenet: a lapkameret/teljesitmeny mutato ma mar nem er semmit, nincs jelentosege. Akkor lenne jelentosege, ha az AMD es az Intel kb. azonos processzt hasznalnanak. Az Intel egyszeruen megteheti, hogy agyuval verebre alapon integral nehany tiz MIC core-t es/vagy ez bazinagy cache-t (legyen szo SRAM vagy eDRAM, L3 vagy L4 cache-rol). Nekik a cel szentesiti az eszkozt, es ha a fegyvertaruk megengedi, akkor erobol fogjak lenyomni az AMD-t, nem pedig IQ-bol, mint elozoleg. Lehet hapogni, hogy milyen keves teljesitmenyt hoz ki az Intel egy adott magmeretbol, de a Crystal Well a jo pelda arra, hogy ha a vegtermeket nezzuk, akkor tulajdonkeppen mukodik az Intel processz uthengere. Igen, az tenyleg az, nem ugy, mint a Steamroller
A HSA-t pedig varjuk ki. Vagy mukodni fog, vagy nem. Raadasul, es errol talan me'g nem volt szo a topicban: ne gondolja senki azt, hogy az Intel tetlenul fogja nezni a HSA felfutasat (ha felfut jovore). Vagy csatlakoznak a HSA Foundation-hoz (szinte kizart), vagy eloallnak egy konkurens megoldassal, vagy egyszeruen megoldjak maskepp a feladatot.
Az ugyanis csak egy dolog, hogy az AMD az iGPU iranyaba akarja terelni a fejlesztoket a HSA-val. Azt hangoztatjak, hogy olyan feladatokat lehet hatekonyan implementalni a HSA-val, amit maskepp nehezen, korulmenyesen lehetne csak megoldani. Pl. raytracing, arc- es gesztus felismeres. De ki mondta, hogy ezeket a feladatokat (es me'g sok mas feladatot) mindenkepp az iGPU-val kell megoldani? Vagy OpenCL-lel? Nincs semmi kotelezo recept: ha a processz elonyt kiaknazva az Intel eloall egy tok mas megoldassal, amivel ugyanolyan hatekonyan meg lehet oldani a feladatokat mondjuk nem az iGPU-val, hanem a CPU-val vagy egy celhardverral, akkor mi lesz? Mi van, ha tok mas lesz a hardver, de ugyanugy OpenCL-en meg lehet hajtani? Mi van, ha nem is lesz szukseg az iGPU-ra? Az egesz iGPU amugy is csak egy szukseges rossz: azert tartjuk, mert gyorsabban lehet vele megoldani feladatokat _jelenleg_, mint a CPU-val. A technologia fejlodese barmikor szuksegtelenne teheti az iGPU-t, es onnantol az AMD a HSA-val egyutt mehet a sarokba gondolkozni. Anno az Ageia is dedikalt fizikai gyorsitot keszitett, aztan megse kellett celhardverkent hasznalni, hanem megoldottak maskepp. Ugyanez lehet a sorsa az iGPU-nak is hosszutavon. Vagy nem...
Plusz egy erdekesseg a HSA kapcsan: az AMD sosem fogja elismerni, de a HSA tulajdonkeppen nem sokkal tobb, mint egy videodrivert megkerulo OpenCL 2.0 iGPU driver meg egy OpenCL --> HSAIL fordito. Ennyi. A hatekonyabb kernel launch es utemezes (queuing) gyerekjatek, ugyanazzal a megoldassal (mint az AMD HSA GCN implementacioja) barki mas is meg tudja csinalni, nem kell HSA Foundation hozza. OpenCL 2.0-hoz hardvert meg drivert csinalni mas is tud, ha akar (akár a VIA is), nem nagy kaland, csupan koherens memoria kezelest kell implementalni. SVM -- Shared Virtual Memory --, nagyjabol ennyit hoz az OpenCL 2.0 az 1.2-hoz kepest. Ha megvan a vas, megvan az OpenCL 2.0 driver meg a videodriverrol valo levalasztas, akkor tulajdonkeppen van egy HSA-capable megoldas, ami nem HSA. Nem kell hozza csatlakozni a HSA Foundation-hoz. Az egyeduli, amit ezzel nem lehet csinalni, az a HSAIL, de az meg ha hazon belul dolgozik az ember (Intel), teljesen irrelevans, megtarthato a regi, OpenCL 1.x IL. Persze a HSA-nal nyomjak ezerrel a Javat meg egyeb maszlagokat, de mas is tud Java --> IL forditot csinalni, az sem akkora dolog.
A vicc az egeszben az, hogy az Intel (vagy az nVIDIA) barmikor lekoppinthatja az egesz HSA-t ugy ahogy van. Csak kerdes, hogy tenyleg a HSA-e a jovo es az egyeduli udvozito megoldas. Jovore talan kiderul...
[ Szerkesztve ]
-
Fiery
veterán
A Haswell nem koherens memoria kezelesre kepes processzor. Ott me'g elnezi az ember azt, hogy benaznak a cache kezelessel. De egy Kaveritol azert en mar elvarnam, hogy normalisan legyen implementalva a cache kezeles, rendesen egy LLC-be dolgozzanak a CPU es iGPU magok. Nem artana egy nagyobb LLC is, de az megint mas kerdes
-
#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.
-
Fiery
veterán
Nem mondtam, hogy az AMD sz*r. GPU-ban pl. baromi jok, a Mantle is baromi jo otlet, a TrueAudio is izgalmasan hangzik. Azt sem irtam, hogy a MIC mukodni fog, sot. En nem is vagyok meggyozodve arrol, hogy a desktopra valaha eljut a MIC. Meglatjuk.
"Ez ellensúlyozható fejlettebb processzel, de vajon mekkora processz-előny kell ahhoz az Intelnek, hogy ezt valóban el is érjék?"
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. Ha viszont valtanak valami masra, abban nagyon sok minden benne lehet. Sokfele iranyba lehet indulni, es ha egy legjobb vagy masodik legjobb megoldast valasztja az Intel, es azt megtamogatja egy brutal jo processzel, az erdekes lesz.
"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."
Biztos vagy ebben? Csak azert kerdem, mert en konkretan az Ageia egyik tarsalapitojaval beszelgettem a PhysX-rol nem reg, es az o elmondasa alapjan inkabb egy GPU-ra hasonlitott a PhysX, mintsem egy DSP-re. Ugy gondolom, o azert eleg authentikus forras
"Amennyit értesz belőle."
Persze, en nyilvan nem ertek semmihez
Van HSA-capable hardvered? Van HSA SDK-d? Hasznaltal mar HSA-t barmilyen szinten? Benchmarkoltal HSA-t? Nalam ezekre igen a valasz, mindre. En nem csak PDF-et olvasgatom meg elhiszem kritika nelkul a sok marketing maszlagot, amit az AMD az arcunkba tol direktben ill. kulonfele mediumok fizetett hasabjain keresztul."Azért jön majd csak jövőre pl. az Nvidiánál, tudomásom szerint."
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. Na jo, esetleg egy Kaveri, de nem lesz hozza szoftver stack, megsutheted az egeszet. Ill. nem, mert a GCN2-es iGPU anelkul is mukodik.
"Meg sebtiben összedobnak hozzá egy világklasszis GPU-t is."
Nem azt mondtam, hogy egy eros vasat konnyu tervezni. Azt nyilvan nem konnyu, sot, baromi nehez. De a korites a vas kore nem nagy cucc. 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.
"Ami valahogy az Intelnek sem jött még össze."
Nem veletlenul nem jott ossze. Nem azt az iranyt eroltetik, csak ezert nem jott ossze. Egy megfelelo MMU-t nem nagy cucc implementalni egy prociba, ne gondold, hogy ezt ne tudná barmelyik x86 gyarto megoldani. Ennyi erovel az AMD-nek meg az eDRAM "nem jott ossze" meg nem tudnak eleg gyors CPU-magot gyartani, nem tudnak AVX2-t implementalni. Dehogy nem tudnak, mindet tudná az AMD is, ha azt akarná csinalni. Csak naluk is mas a fokusz.
"C++, C++ AMP, .NET támogatás..."
Whatever, a fejlesztok nagy resze ugyis OpenCL-en fog nyomulni, mint ahogy eddig is.
"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"
Egy olyan "szabvany" moge, amit egyszerubb lemasolni es a sajatodnak beallitani? Vagy egy olyan "szabvany" moge, amihez nincs me'g egyetlen implementacio sem kesz, me'g beta szinten sem?
"pl. mikor neveztek ki Intel szóvivőnek?"
Engem baromira nem erdekel az Intel
Sot, ha szurkolni kene valamelyik cegnek, akkor a VIA-t valasztanam. Ezerszer szimpatikusabb banda, mint a masik ket x86 gyarto. A kritikaimat pedig mindenkivel szemben megfogalmazom, csak lehet, hogy az Intel fele valo szurkalasomat es az AMD-vel szembeni dicsereteimet nem veszed eszre, nem akarod eszrevenni?[ Szerkesztve ]
-
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ő.
-
Fiery
veterán
"Az Intelnek a MIC-kel pont az a problémája, hogy sokkal több tranyó beépítésére lenne szükségük, mint ami lehetséges"
Oke, akkor beszeljunk konkretumokrol a MIC kapcsan. Ha jol sejtem, az Intel altal megcelzott teljesitmeny az 1 TFLOPS (egyszeres pontossaggal), hiszen a Kaveri is kozel ennyit fog tudni, a Carrizo pedig minden bizonnyal -- nemileg -- meg fogja haladni ezt a teljesitmenyt. 1 TFLOPS-ot MIC-kel hogyan tud az Intel eloallitani _szerinted_? Milyen orajel, hany mag es hany tranzisztor szukseges hozza?
A driver meg tenyleg sz*r, de azon a legkonnyebb csiszolni, javitani. Ne ugorjatok a torkomnak mindjart, en is tudom, hogy ez csak elmeletben van igy, es sok idobe telik
Csak epp ha van egy valamilyen iGPU hardvered, azon menet kozben mar nem tudsz varialni; viszont a driver benasagat a meglevo vasakra is tudod me'g menet kozben finomitani. Mindennek az alapja egy jo vas lenne, a driver-team meg elobb-utobb majd csak felno vegre a feladathoz. Megjegyzem, siman lehet, hogy a MIC-es megoldast azert is erolteti az Intel (ha a desktopra is erolteti), mert drivert es/vagy OpenCL compilert sokkal egyszerubb lenne irniuk hozza. De ez megint csak egy sejtes, nyilvan mas faktorok is szerepet jatszanak a dontesben. A tranzisztorszam viszont biztosan nem, legalabbis nem olyan szinten, hogy azon akarnanak sporolni. Van boven tranyo, csak az ertelmet kell kitalalni par milliardnak [ Szerkesztve ]
-
Fiery
veterán
válasz
leviske
#13016
üzenetére
"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"
Az Intel most epp azzal van elfoglalva, hogy az ARM-ot lenyomja. A legutobbi IDF masrol se szolt, mint a kulonfele szines-szagos mobil cuccokrol. Ilyen tablet, olyan convertible, ultrabook, anyamkinja. Most epp ez a fokusz, a befektetoket azzal nyugtatjak, hogy az ARM ellen miket kuldenek. A Crystal Well retegtermek, lenyegtelen, hogy mennyibe kerul legyartani -- no meg eleve brutal dragan is adja az Intel. Ez utobbi az oka annak is, hogy nem tud mainstream termek lenni belole. Ki adna 450 dollart egy prociert onmagaban, amikor nem ritkan egy notebookot vesz annyiert az ember?
De arra jo a Crystal Well, hogy kiprobalja az Intel a gyakorlatban az eDRAM-ot, villogtassa a technologia folenyet meg innovacios kepessegeit. Ha pedig bevalik, es olcsobb lesz gyartani, akkor me'g mainstream termek is lehet elobb-utobb belole."Viszont erre az Intelnek eredetileg a Larrabee akart a válasza lenni, 3 évvel ezelőtt. Azóta se sikerült desktopon bevetni."
Teny, a MIC eddig nem muzsikalt valami jol. De az ilyen radikalis ujitasoknal az Intel mindig is benazott par evet, mire ertelmes termeket tudott faragni a betas szutykokbol. Lasd Itanic
Kerdes, hogy a MIC milyen sorsra jut majd. Mint ahogy fentebb is leirtam, en nem vagyok meggyozodve arrol, hogy a MIC es csak a MIC, amit az Intel akar tenni az iGPU problemakorrel. Siman lehet, hogy AVX-512-vel es a CPU-val akarjak athidalni a problemat. Vagy valami osszver megoldas lesz majd, hiszen a Knights Landing is tamogatni fog AVX-512-t -- ami az LRBNI fenyeben eleg erdekes otlet, es mindenkepp jelzi azt, hogy valamire keszulnek."Tulajdonképpen minek kéne lennie a HSA-nak szerinted ahhoz, hogy "elismerhető" alternatíva legyen?"
Minek az alternativaja? Csak azert kerdezem, mert jelen allas szerint a HSA a mostani, OpenCL-es GPGPU alkalmazasok lehetosegeinek kiterjeszteset jelenti. Egyszerubb programozhatosag, a memoria masolgatasok elkerulesevel, gyorsabb kernel launch, stb. Ennek max. egy unified memory tamogatasu CUDA lehetne az alternativaja jelen allas szerint -- vagy ha az iGPU-t valamilyen mas modon hajtod meg, de arra me'g otletek sincsenek (Intel reszrol sem). Vagy esetleg alternativa lehet egy teljesen mas megkozelites, de arrol plane nem lehet tudni semmit, tehat nem lehet alternativa jelenleg.
"É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ő."
Ki mondta, hogy az Intelnek barkire is szuksege van? Az ARM-ra plane nincs, az a legnagyobb mumusa az Intelnek jelenleg. Az Intel eddig is proprietary cuccokat fejlesztett, es csak azokkal osztotta meg, akikkel nagyon muszaj volt (pl. AMD es VIA x86 keresztlicenc megallapodasok). Ha a Microsoft nem kavar be annak idejen, akkor az AMD64-et se vette volna at az Intel, hanem valami mast csinalt volna, ha az IA-64 ugyanilyen sorsra jut. Sot, vegul is az AMD64-et Intel64 neven promozza, ergo lemasolta az AMD otletet, es sajat neven haknizik vele. Felek tole, hogy a HSA is erre a sorsra juthat: egy jo otlet, amit aztan lemasol az Intel, es csinal ala egy erosebb hardvert
-
Fiery
veterán
Sok mindenre mondja azt az AMD, hogy ugy a legjobb, ahogy ok csinaljak. De az ilyen dontesek mogott sokszor az is all(hat), hogy ok igy tudjak megoldani a problemat. Minden generacional arrol beszelnek (AMD), hogy a kovetkezo mennyivel kozelebb hozza oket a vegcelhoz. Mindig van egy igeret, hogy a kovetkezo mennyivel jobb lesz. Inkrementalisan epitkeznek, sok evbe telik (7-8), mire elerik a vegcelt. Az Intel mas utakat jar, nekik van kapacitasuk meg eroforrasuk arra, hogy radikalis valtoztatasokat eszkozoljenek, kiprobaljanak ujszeru dolgokat. Aztan vagy belebuknak (Itanic), vagy nem. Az LLC kapcsan pedig az is megoldhato lenne, hogy ha pl. egy kozos cache-be dolgoznanak, csak az jol el lenne szeparalva 2 reszre, amikor az iGPU is szemetel. Persze akkor minek a kozos cache, johet a kerdes? Hat pl. azert, mert ha a CPU-nak kellene a nagy cache, akkor jol jonne. Ezert baromi jo az eDRAM: azt tudja hasznalni a CPU is L4 cache-kent. Ha megnezzuk, mennyi cache van egy Kaveriban, es mennyi egy Crystal Well-ben, hat eleg brutalis a kulonbseg. Persze tudom en, hogy minden az iGPU-rol szol, es a CPU csak disznek van ott, minek gyorsitani holmi cache-ekkel
-
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.
-
Fiery
veterán
22 nanon 1,86 milliard tranyo es 257 mm2 egy 6 magos Ivy Bridge-E. Ebbol nagyjabol lehet kovetkeztetni a tranyo surusegre -- persze egy iGPU mas tema, mint egy sima CPU, es a MIC cache mereteket sem tudjuk. Ha a szamitasaidat vesszuk figyelembe, akkor csak az iGPU lenne mondjuk 276 mm2 MIC alapokon, 22 nanon. Mivel 14 nanon jon a Skylake, igy kis tulzassal skalazzuk azt le 175 mm2-re mondjuk. Ez me'g mindig csak az iGPU, 2 milliard tranyoval.
A CPU+Uncore resz meretere nehez becsleseket adni, hiszen nem tudjuk a cache mereteket, valamint hogy AVX-512 lesz-e mar a Skylake-ben. Az szinte biztos, hogy 4 magos lesz. De legyen mondjuk hasonlo meretu es kialakitasu, mint a 4 magos Sandy Bridge-E, csak 14 nanon gyartva, ugyhogy legyen mondjuk a CPU resz 1,3 milliard tranyo es 128 mm2. Ezzel a CPU+Uncore+iGPU osszesen 3,3 milliard tranyo es 303 mm2. Ez nem kicsi, de nem is mondanam legyarthatatlannak. Meretben hasonlo kategoria, mint a Sandy Bridge-E (ami 32 nano / 4 mag: 294 mm2), a tranyoszam meg nem nagy cucc, gyartott mar ennel sokkal durvabbat is mindharom GPU gyarto. A Crystal Well kapasbol nagyobb (348 mm2) az eDRAM-mal egyutt, bar annak a tranyoszamat nem tudjuk. Megjegyzem, a 2 modulos Trinity/Richland sem sokkal kisebb, cca. 250 mm2.
Mas kerdes persze, hogy mennyit disszipalna egy ilyen proci, es mekkora orajeleken tudná hozni a Kaveri vagy a Carrizo tempojat. Az AMD-s sracok nekem pont azt elemezgettek, hogy az Intel baromi jo cuccokat tud gyartani, csak az orajel a baj, azt nem lehet tulsagosan felnyomni, mert nagyon megszalad a TDP. Ugyhogy ha iGPU-rol van szo, es a hw dizajn megfelelo, akkor egy megfeleloen alacsony orajelen mukodhet a dolog 2 milliardnyi iGPU tranyoval SZVSZ.
[ Szerkesztve ]
-
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
-
#13026
Fiery
veterán
Mahrenburg
#13025
Fiery
veterán
válasz
Mahrenburg
#13025
üzenetére
Fejlesztenek valamit, de a Jaguar egy nagyon eros architektura, aminek nagyon nehez lesz a nyomaba erni
Raadasul, ami a nagyobb problema: OpenCL-lel nem foglalkozik a VIA, sajnos nincs ra kapacitasuk. Ez lehet, hogy a ceg sorsat el is fogja donteni. -
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 ]
-
Fiery
veterán
"PS4. (Félig-meddig az XB1 is.)"
Arra a PS4-re gondolsz, ami egy zart rendszer, es olyan HSA-capable APU van benne, aminek "furcsamod" a PC-s megfeleloje (Kabini/Temash), valamint annak utodja (Beema/Mullins) sem kepes a HSA-ra?
Mennyire relevans az a platform ezek utan egy Kabini, Kaveri, Carrizo topicban? Megjegyzem, eleg nagy szegyen, hogy a Beema/Mullins sem tamogatja a megosztott memoriat, mikozben ott a PS4... Az AMD-nel sem minden rozsaszin azert.Raadasul pont azt irod, hogy "programozó vagyok és "bele tudom élni magam" a használatába": ha ilyen szemszogbol nezed a dolgokat (ami nagyon helyes), akkor pont full irrelevansak a konzolok, hiszen azokat a budos eletben nem fogja Te sem, en sem, egyik idelatogato programozo sem programozni, legalabbis ha nem jatekrol beszelunk. Ami relevans, az a Kaveri es Kabini, azokhoz meg a HSA implementacio (szoftver stack) me'g alpha-1 allapotu (Kaveri) ill. semmilyen (Kabini). Azt gondolom nem kell senkinek magyarazni, hogy az alpha-1 milyen messze van a stabil allapottol
"A másik dolog, hogy mit ér a körítés, ha nincs hozzá vas?"
Van az Intelnek vasa (iGPU) hozza, legfeljebb nem annyira gyors, mint a konkurencia. De ennyi erovel a CPU-ban meg az AMD nem eleg eros, szoval valahol ezek kiegyenlitodnek
Fogadni mernek ra, hogy az Intel mar csinalt teszteket, esetleg betas megoldast is konkret vassal, hogy mikepp tudnak implementalni a HSA-t vagy egy HSA-koppintast. Ha a HSA berobban, fel kell hogy keszuljenek ra. Ha a HSA nepszeru lesz, es tenyleg sok elonye szarmazik belole a vegfelhasznalonak, akkor me'g egy gyengebb HSA-capable iGPU-val is jobban jar az Intel, mint ha HSA nelkuli iGPU-val probalkoznak tovabb."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"
Lekoppintani pont ugyanakkora melo, es az Intelnek meg is eri, ha utana tudja verni a mellét, hogy azt o talalta fel. 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.
"Szerintem, ha meglenne már, nem bohóckodtak volna az Iris Proval"
Ez egyertelmu.
[ 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.
-
Fiery
veterán
"A HSA az nem csak CPU és IGP integrációja. Annak van egy memória és queueing modellje."
Marmint arra gondolsz, hogy a megosztott memoria mukodesehez van szukseg -- tobbek kozt -- IOMMUv2-re. Ez stimmel is. A HSA-hoz alapkovetelmeny a megosztott memoria, amihez az AMD-nel kell az IOMMUv2. De a HSA kapcsan felesleges IOMMUv2-t igenyelni vagy nezni vagy keresni; a lenyeg, hogy ha nem mukodik a megosztott memoria, akkor nem HSA-capable a vas, tehat HSA szempontbol irrelevans.
"Ugyanolyan támogatása lesz így ennek mint a Trinity/Richland APU-nak."
Vagyis semmilyen, ha a HSA szemszogebol nezzuk. A megosztott memoria nem fog mukodni, ez a baj, ahogy a Trinity/Richlandnel sem mukodik, hiaba van ott az IOMMUv2.
-
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
Nem valószínű, hogy az Intelt egy ilyen rendszer érdekli. Jelenleg sokszázmilliós tranyótöbblettel fizetnek azért, hogy a MIC x86-ra épül (még ha nincs is bináris kompatibilitás), és nem egy speckó ISA-ra. Ha fejlesztenének egy HSA alternatívát, akkor gyakorlatilag az egész koncepcióba feleslegesen öltek 10 évet és sokszázmillió dollárt. A MIC tranzisztorigényének töredékén kihoznának egy hasonló rendszert.
Az Intel koncepciója még mindig az "x86 rule the world". Ha ez nem tetszik a piacnak, akkor is a piaccal van gond és nem a koncepcióval. Majd idővel kiderül, hogy Krzanich mit szeretne a jövőben, mert ugye neki most abból kell egy darabig élnie, amit az elődje ráhagyott, de könnyen lehet, hogy Krzanich már nem válik meg azoktól, akik esetleg meg merik szólni az x86-ot.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Fiery
veterán
Oke, de ha a HSA legacy modban megy, akkor nem sokkal jobb, mint egy OpenCL 1.2-es jelenlegi rendszer. Akkor csak a video driverrol valo levalasztas az elonye, a gyorsabb kernel launch meg a jobb queuing. Ezek meg osszessegeben nem nagy dolgok, sajnos, az igazi dobas a megosztott memoria. Ertem en, hogy azonos modon kodolsz, de ha amugy is az OpenCL-t valasztja a fejleszto nyelvnek, akkor a HSA legacy modja es a mostani OpenCL-es megoldas kozt azert nincs olyan nagy kulonbseg.
-
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.
-
Fiery
veterán
"Talán mert azon kívül, hogy Jaguar és GCN, nem sok közük van egymáshoz?"
Az nem eleg?
Az alap architektura (Jaguar) ugyanaz, a CPU-magok (az uncore resz nelkuli magokra gondolok) ugyanazok, a GPU alapelemei ugyanazok, csak mindenbol kicsit tobb van darabra. Maga az AMD mondta, hogy a Beemahoz nagyon kozel allnak a konzolos APU-k, nem mi talaltuk ki."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?"
A Javat az AMD erolteti, az Intel -- latszolag -- tojik ra, ugyhogy a konkurencia szempontjabol az kevesbe erdekes. Ha meg maradunk az OpenCL-nel, akkor igen, a HSA-t ujrakrealni egy olyan cegnek, akinek mar van elfogadhato szintu OpenCL 1.x forditoja es meglevo, tegyuk fel hogy koherens memoria kezelesre alakithato vasa, nem olyan nagy feladat.
"Hát a virtuális API? Azt 1:1 koppintanák, vagy mégiscsak sajátot készítenének?"
Ha hazon belul maradsz, es nem 10-20 fele ceget meg 4-5 fele platformot akarsz kiszolgalni, akkor nem kell HSAIL. Eleg maradni az OpenCL-nel, azon megirja a fejleszto a kodot, es utana vagy lefordul a mostani OpenCL 1.x forditoval a mostani GPU-kra; vagy lefordul HSAIL-re es onnan futtatja a gep; vagy lefordul valami proprietary IL-re (pl. a meglevo Intel-fele IL-re), es megy a "HSA"-s iGPU drivernek finalizalasra es futtatasra.
Az egesz HSAIL-t nyilvan el kell felejteni, ha valaki le akarja a HSA-t masolni, hiszen azzal tenyleg konkret koppintas lenne. Viszont a HSAIL eletrehivasa pont annyira rossz a meglevo OpenCL fordito tulajoknak, mint amennyire jo. Ha nem lenne HSAIL, csak minden mas, amirol a HSA szol, az AMD mar reg piacon lehetne a sajat HSA SDK-javal. Igy viszont a compilereket ujra kell irnia nullarol, es szivatnia magat a HSAIL-lel. Ok akartak ezt
Viszont ha az Intel lekkopintja a HSA-t, akkor neki nem kell uj forditot irnia, hanem csak a drivereket: joval kisebb melo."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..."
Az AMD64-nel se voltak kozrohej targya, legfeljebb a hasonlo kozegben, mint ez a topic. A nagykozonseg racuppant pikkpakk. A QPI me'g sikeresebb lett, mint a HT, es az IMC-bol is az Intel tudta kihozni a legtobbet eddig (ld. LGA2011). A piacnak siman be tudna adagolni az Intel, hogy csinaltak egy megosztott memoriara epulo GPGPU computing architekturat, ami tok szuper, es az eddigi programok (OpenCL) is mukodnek vele, de uj tavlatokat nyit, blablabla. Nem emlitenek nyilvan, hogy a HSA-t masoltak le, adnanak neki valami Intel SuperComputing API vagy hasonlo nevet, es kesz.
"es vegul az Intel megoldasa me'g jobban is sikerult, mint amit lemasolt."
Ld. elozo bekezdesem.
-
Fiery
veterán
Azt azert az Intel vedelmeben erdemes megemliteni, hogy az "x86 rule the world" eddig azert eleg jol mukodott, es bizonyitott. Lenyomtak vele egy halom eros ceget es architekturat, hazon belul me'g az IA-64-et is, es az iGPU vonalon kivul mindenhol remekul mukodik mind a mai napig az x86 (a konzolokban is
). Na jo, a telefonokban meg a tabletekben sem igazan villog az x86, de a Silvermont nagyon jo cucc, helyrerakja a dolgokat megint, es ott a Temash is.Maga az a teny, hogy egy hosszu evek ota eroltetett koncepcio nem mukodik, nem mindig szegi kedvet az Intelnek (Itanic), de hosszutavon, ha adodik egy jobb alternativa, akkor kepes az Intel is iranyt valtani. Megtortent mar az AMD64-gyel is (bar ott kenyszerhelyzetben voltak a Microsoft miatt), megtortent mar lenyegeben az Itaniummal is, na meg ott volt a Tejas is.
Ha a MIC mondjuk me'g 5 evig nem fut be, akkor tutira kidobja az Intel, es csinal valami mast helyette. Bar, nekem mar az AVX-512 is gyanus: miert nem az LRBNI-t hozta at az Intel a desktopra, miert forditva csinalja? Kerdes persze, hogy ha me'g tovabb erolteti az Intel a MIC-et, akkor nem fog-e tul sokat vesziteni vele...
[ Szerkesztve ]
-
dezz
nagyúr
Erm, a virtuális API term. virtuális ISA akart lenni.
(#13036) Abu85: De miért ne lehetne egy MIC alapú HSA-s platform?
(#13037) Fiery: "Akkor csak a video driverrol valo levalasztas az elonye, a gyorsabb kernel launch meg a jobb queuing."
Azért ezek is elég hasznos dolgok. De egyébként az utóbbihoz hw támogatás is kell, szerintem.
(#13039): A Jaguar az a CPU magok mikroarchitektúrájának a neve, nem?
A körítés valamennyire biztos más, hiszen hiányoznak a legfontosabb HSA fícsőrök. A memóriavezérlő 4-csatornás a 2 helyett, stb.
Ha kihagynák a HSAIL-t és ezzel együtt a virtuális ISA-t, akkor nincs is miről beszélni, egyszerűen csak egy OpenCL 2.0 fordítót kell készíteniük, ami csak saját HW-re fordít... A MIC-kel/-vel valószínűleg pont ez fog történni. Kérdés, ki lesz kíváncsi a MIC-re? És esetleg lemondhatnak a C++ AMP, .NET, stb. támogatásról is.
"Viszont ha az Intel lekkopintja a HSA-t, akkor neki nem kell uj forditot irnia, hanem csak a drivereket: joval kisebb melo."
Full kompatibilis rendszer licencdíj nélkül? Az nem fog menni.
"Az AMD64-nel se voltak kozrohej targya" - Miért lettek volna? Bepróbálkoztak sajáttal (mármint ami nem kompatibilis), MS nemet mondott, ennyi.
"A QPI me'g sikeresebb lett, mint a HT"
Milyen értelemben?
"es az IMC-bol is az Intel tudta kihozni a legtobbet eddig (ld. LGA2011)"
Az AMD-nek 512-bites memóriavezérlője is van (dGPU-hoz).
"A piacnak siman be tudna adagolni az Intel, hogy csinaltak egy megosztott memoriara epulo GPGPU computing architekturat, ami tok szuper, es az eddigi programok (OpenCL) is mukodnek vele, de uj tavlatokat nyit, blablabla."
Mármint itt ugye full saját platfom(ok)ról beszélsz, HW-rel együtt, ugyebár? Más szóval, nem csak SW szinten kellene lenyomniuk a világot (mármint, hogy valóban csak OpenCL-ben kódoljon mindenki, neadjisten direkte AVX-512-re), hanem HW szinten is (mindenki MIC-et vegyen mindenhova).
(#13040): "hazon belul me'g az IA-64-et is"
Ehhez azért kellett az AMD "segítsége" is...
[ Szerkesztve ]
-
Fiery
veterán
"A Jaguar az a CPU magok mikroarchitektúrájának a neve, nem?"
De igen.
"Ha kihagynák a HSAIL-t és ezzel együtt a virtuális ISA-t, akkor nincs is miről beszélni, egyszerűen csak egy OpenCL 2.0 fordítót kell készíteniük, ami csak saját HW-re fordít"
Pontosan. Es ezt hivhatjak barminek. 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.
"Kérdés, ki lesz kíváncsi a MIC-re?"
Barki, aki nem akarja magat bezarni az AMD okoszisztemajaba
Ami plane annak fenyeben hasznos lehet, ha megnezzuk, mekkora az AMD reszesedese a CPU/APU piacon. 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)."És esetleg lemondhatnak a C++ AMP, .NET, stb. támogatásról is"
Talan. Vagy nem. A Microsoftot nem nehez meggyozni Intelkent, eddig egyetlen esetben nem sikerult (AMD64)
"Full kompatibilis rendszer licencdíj nélkül? Az nem fog menni."
Csak a source végén kompatibilis (OpenCL), a tobbi reszenel meg nem kell foglalkozni a kompatibilitassal, hiszen zart rendszer. Az OpenCL meg nyilt, ugyhogy nincs licencdij tudtommal.
QPI: mondjuk nezzuk meg, milyen piaci penetraciot ert el az egyik mára, es a masik. Melyikbol mennyit adtak el, amiota letezik. 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.
"Az AMD-nek 512-bites memóriavezérlője is van (dGPU-hoz)"
Az Intelnek is van ennyi erovel, sot. Lasd Westmere-EX es a 12 magos Ivy Bridge-EP. A dGPU-kat egyebkent sem kellene direktben egy CPU-hoz hasonlitani, teljesen mas teszta
"Mármint itt ugye full saját platfom(ok)ról beszélsz, HW-rel együtt, ugyebár? Más szóval, nem csak SW szinten kellene lenyomniuk a világot (mármint, hogy valóban csak OpenCL-ben kódoljon mindenki, neadjisten direkte AVX-512-re), hanem HW szinten is (mindenki MIC-et vegyen mindenhova)."
Igy van, kell hozza hardver is, nyilvan. Egyebkent a multban sem volt akadaly nekik, ha nem ok gyartottak a legerosebb CPU-t vagy platformot, annak ellenere is tobbet tudtak eladni, mint a konkurensek. 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.
"Ehhez azért kellett az AMD "segítsége" is"
Ez teny
Es mindenki jol jart vele, me'g az Intel is, ha vegre el tudja engedni a nyavalyas Itanicot.[ Szerkesztve ]
-
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.
-
letepem
aktív tag
válasz
leviske
#13044
üzenetére
Én csak azt véltem felfedezni, hogy Fiery álláspontja mennyire megvaltozott az elmúlt hetek alatt: hiszen eddig a mondanivalójából az új platform(kaveri) iránti lelkesedés érződött; míg most annak ellentéte , mintha az Intel bármivel is "meggyőzte" volna az utóbbi időben...
látok, hallok, érzek és gondolkodom.
-
Abu85
HÁZIGAZDA
A GPU-k közül messze a MIC-nek a legmagasabb a pJ/FLOP mutatója. 2x-3x nagyobb, mint amit az NV és az AMD ma felmutat. Ez azt jelenti, hogy azonos sebességen 2x-3x többet is fogyaszt. A HSA támogatható természetesen, de nincs értelme egy olyan rendszeren megtenni, aminek az alapjai eleve egy bődületes fogyasztásbüntibe taszították az Intelt. Innen a natív programozás az egyetlen reális út. Ezen a ponton azt kell elhitetni a fejlesztőkkel, hogy végül a MIC lesz a piac egyetlen architektúrája, mivel a natív programozás miatt később nincs lehetőség az ISA lecserélésére. Ha ezt megteszik, akkor minden erre írt alkalmazás kukában végzi, mert nem fog elindulni.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Fiery
veterán
válasz
leviske
#13044
üzenetére
Elnezest, ha valakit zavar az Intel ebben a topicban. De a piac nem csak az AMD-rol szol, sot. A PC-s piacon pont o a masodik legnagyobb szereplo, ergo az Intel nelkul, onmagaban az AMD-t vizsgalni nem feltetlenul adja ki a teljes kepet. Raadasul, sok esetben pont arrol beszelgetunk, hogy az AMD-t hogyan fogja tudni utolerni az Intel, vagy milyen alternativ megoldasokat talalnak ki a meglevo problemak megoldasara.
De ha ennyire nem ide illik a dolog, akkor szerintem nyissunk egy "HSA: AMD vs. Intel+nVIDIA" topicot, es akkor atmegyek oda beszelgetni a nagyerdemuvel
[ Szerkesztve ]
-
Fiery
veterán
válasz
letepem
#13045
üzenetére
En a magam reszerol mindenkepp kulon kivanom valasztani a Kaveri hagyomanyos ertekeit es a HSA-s innovaciot. Ha hagyomanyos APU-kent vagy CPU-kent tekintunk a Kaverira, akkor tovabbra is azt mondom, hogy azt kapjuk, amire szamitani lehetett. CPU-ban alig erosebb, mint a Richland, az iGPU-ja viszont a GCN architektura miatt (es mert tobb CU-ja is van) a gyakorlatban jelentos elorelepest hoz. A finomitott PStates es CPB kezeles miatt energiahatekonysagban is elorelepes, bar nem olyan radikalis, mint amire szukseg lenne.
Mas tema a HSA, amirol viszont minel tobbet tudok meg (es foleg miutan a gyakorlatban is lattam a jelenlegi helyzetet muzsikalni), annal kevesbe bizok abban, hogy onmagaban ez fogja az AMD-t sikerre vinni. Plane mivel, ahogy fentebb fejtegettem, a HSA lenyegi resze tul konnyen lekoppinthato, meghozza ugy, hogy a fejlesztok nem feltetlenul erzik a kulonbseget, nem erinti oket hatranyosan, ha belep a piacra mondjuk az Intel a sajat "HSA"-javal. Ez az AMD-re nezve veszelyes, me'g akkor is, ha jelenleg a GCN2 eleg szep elonyt ad nekik az iGPU nyers erejet tekintve.
[ Szerkesztve ]
-
Fiery
veterán
válasz
letepem
#13045
üzenetére
Me'g annyit, hogy az allaspontomat az AMD viselkedese, PR-offenzivaja pont nem abba az iranyba tereli, amibe az AMD szeretné. A marketing jo dolog, de meg kell tanulni zarojelbe tenni a marketing maszlagot, es arra fokuszalni, hogy a gyakorlatban mit is jelent egy adott technologia, mire jo, mikepp lehet hasznositani, es valojaban mikor is lesz belole kezzel foghato eredmeny. Az AMD azt hiszi, hogy ha a csapbol is a HSA, GCN, TrueAudio meg a Mantle folyik, ha egyes mediumok kulon rovatot szentelnek az AMD-s cuccoknak, ha mas mediumok hetente 3-4 alkalommal kotelezo ervenyu AMD hireket/postokat/cikkeket hoznak le, akkor azzal ellensulyozni lehet a technologia lemaradasukat, hianyossagaikat. Lehet, hogy a vegen a piac tenyleg bekajalja az osszes maszlagot, es az AMD marketinggal nyomja le a vilagot, de ahhoz az is kell, hogy a konkurencia ne tegyen keresztbe, ne csinalja meg sajat hataskorben legalabb ugyanolyan jol ugyanazt. Az utobbi par postban nem volt szo az nVIDIA-rol, de me'g oket sem szabad zarojelbe tenni, me'g ok is elohuzhatnak valamit a kalapbol. Me'g maguk az AMD-sek sem becsulik le az nVIDIA-t, sot. Jelenleg jobban tartanak az nVIDIA-tol, mint az Inteltol...
[ Szerkesztve ]
-
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.
Nem veletlen, hogy az APU-kban nincs es nem is lehet hagyomanyos ertelemben vett, a CPU-iGPU altal kozosen hasznalt L2 vagy L3 cache. Me'g a Kaverinal sem ugy mukodik az L2 cache sem, mint ahogy azt a jozan esz diktalna. Jobban hasonlit me'g a Kaveri is egy 2 socketes, cache snoopos megoldashoz, mint egy rendes cache koherenciaval implementalt rendszer. Takolas, mondjuk ki. Jol mukodik a gyakorlatban, de takolas. A Carrizo megint faragni fog ezen, ott pl. mar nem lesz letiltva a iGPU L2 cache-e a koherens memoria hasznalatnal, de ezek az apro lepcsok szamomra tul lassu fejlodesnek tunnek.
Ami plane annak fenyeben hasznos lehet, ha megnezzuk, mekkora az AMD reszesedese a CPU/APU piacon. 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).
Ú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.
- Android alkalmazások - szoftver kibeszélő topik
- Apple notebookok
- YouTube
- Jeorjosz7 károsultjai
- Autóápolás, karbantartás, fényezés
- Spórolós topik
- Kétféle tájolással munkára fogható, ITX-es ház jött a Sharkoontól
- Samsung Galaxy A54 - türelemjáték
- Melyik tápegységet vegyem?
- VR topik (Oculus Rift, stb.)
- További aktív témák...
