-
GAMEPOD.hu
OLVASD VÉGIG ALAPOSAN MIELŐTT ÚJ HOZZÁSZÓLÁST ÍRNÁL!!!
Új hozzászólás Aktív témák
-
-
Vitamincsiga
tag
"En inkabb ugy mondanam, hogy a GPU korszaknak lesz lassan vege"
Ezzel egyetértünk
Külön FPU sincs - annó 387-est még vettem 1.600-ért...
Az É-i és a D-i vezérlőhidak ideje is lejárt.
Miért is állnánk meg itt?
Egybe fogják integrálni a GPU CU-jait a mai CPU magokkal. Az Intel más utat választott, a többiek is keresgélik a magukét.
Az AMD számára lehet, hogy most túl nagy falat lenne a CU beintegrálása a Bull architektúra moduljába. Bár valószínűbb, hogy az x86, ARM fordulattal el is tudnának adni valamit nagy mennyiségben, és valljuk be őszintén még a HSA-ra sem készült fel szinte senki, pedig a Kaveri ott tényleg tud valamit és az Excavator is befut hamarosan!A "szaladgálást" én nagyméretű, sokdimenziós tömbök feldolgozásakor éreztem leginkább. A sok feltételes szerkezet rettentően belassít. Az A8-7600 megvétele után visszatérek erre!
Jó lenne egy varázsgömb ;-)
-
leviske
veterán
Igazából még mindig nem teljesen értem, hogy hogy nem látod a párhuzamot az Itanium és a MIC között. A HSA kapcsán nem lehet konkrétan rosszul járó feleket említeni a piacon, hiszen idővel a szoftveres problémák kiküszöbölhetők, mint bármilyen más, elterjedt megoldás esetén.
Ellenben, ha az Intel olyan formában "győzne", hogy megint egyeduralkodóvá válik a piacon, akkor azzal rengeteg cég veszítene, köztük jó pár, Intelnél nagyobb méretű vállalat is (LG, Samsung, Apple?). Emellett az nVidia is érdekelt volna a HSA térnyerésében, mert az Intel megoldása mellett a CUDA-t is lehet kukázni, míg a HSA mellett bőven megfér.
Egy HSA implementáció elkészítését meg szvsz én nem érzem annyira nagy bűnnek, mint egy-egy tesztprogram tesztrutinjaihoz igazítani egy hardvert, ami utána gyakorlatban nem képes hozni a teszt által sugallt eredményt.
-
Fiery
veterán
válasz
leviske
#14203
üzenetére
Bocs, de tenyleg nem ertem, mi koze az Itaniumnak a MIC-hez. Az egyik egy gyokeresen uj architektura, ami megbukott, sosem tudta az x86-ot lenyomni -- kiveve a piac egy nagyon szuk szegmenset. A masik meg pont egy, az x86-ra epulo compute architektura lenne, amit GPU-kent ill. GPGPU-kent is lehet(ne) hasznalni. Az Itanium egy teljesen uj architektura volt, a MIC tulajdonkeppen nem az, csak egy specialisan kialakitott x86 hardveres implementacio. Vagy azt akarod sugallni, hogy a MIC az Itaniumhoz hasonloan meg fog bukni? Ezzel szerintem varjuk meg a Knights Landing-et es a Skylake-et, majd utana raerunk ilyen konkluziot levonni
A KNL-et es a Skylake-et sikernek vagy bukasnak beallitani elore, csak mert -- velhetoen -- MIC alapuak lesznek kb. olyan lenne, mint ha az AMD Family 20h-t allitanank be ugyanigy elore sikernek vagy bukasnak."Ellenben, ha az Intel olyan formában "győzne", hogy megint egyeduralkodóvá válik a piacon"
Sajnos mar most is van nehany piaci szegmens, ahol nincs ellenfeluk. Kapasbol a mainstream desktop es mobil piac felso fele ilyen, aztan ott vannak az 1, 2 es 4 utas szerverek, a munkaallomasok, a HEDT, stb. Ahol van konkurenciajuk, az az ultramobil eszkozok (tabletek, telefonok) es az olcso desktop es mobil PC-k. Nyilvan senki sem akarja, hogy ez a helyzet me'g rosszabbra forduljon a piac szamara, de azzal, hogy ennyire eltero utat valaszt az AMD es az Intel (az nVIDIA-rol nem is beszelve), abszolut megjosolhatatlanna teszi azt, hogy vegul mi lesz a jelenlegi GPU-piaccal. Egyaltalan nem biztos, hogy az x86 barmilyen szinten utokartya lesz a jovoben, emiatt pedig a MIC lehet, hogy rossz valasztas lesz hosszutavon. Viszont, a masik oldalon meg egyaltalan nem biztos, hogy a compilerekre, driverekre es a szoftver fejlesztokre ra lehet bizni az, hogy ok oldjak meg a jelenlegi "teljesitmeny fal" problemat. Nincsenek jo OpenCL compilerei es nincsenek jo driverei sem jelenleg az AMD-nek es az Intelnek sem, ez pedig nem jo alapot ad a fejlesztoknek arra, hogy szivassak magukat az egesz OpenCL es HSA temaval. Az nVIDIA-nak -- talan -- lenne ehhez megfelelo alapja, csak ok meg nem egyertelmu, hogy milyen iranyba tartanak. Talan abban biznak, hogy az x86 hamarosan elvesziti jelentoseget, es az ARM alapu "APU"-jukkal, egy sajat, proprietary HSA-szeru megoldassal ok is utolerhetik a "nagyokat".
"Emellett az nVidia is érdekelt volna a HSA térnyerésében, mert az Intel megoldása mellett a CUDA-t is lehet kukázni, míg a HSA mellett bőven megfér."
Az nVIDIA sosem szeretett masok moge beallni, nem csodalom, hogy a HSA-t sem favorizaljak (egyelore). Velemenyem szerint -- de erre semmi bizonyitekom nincs -- egy sajat megoldason dolgoznak, ami vagy a CUDA-ra fog epulni, azt egesziti ki SVM es mas HSA-bol "ellesett" kepessegekkel, vagy egy az egyben a HSA koppintasa lesz mas neven. Kisebb eselyt adok annak, hogy osszeallnak az Intellel, bar annak egyebkent abszolut lenne ertelme.
"Egy HSA implementáció elkészítését meg szvsz én nem érzem annyira nagy bűnnek, mint egy-egy tesztprogram tesztrutinjaihoz igazítani egy hardvert, ami utána gyakorlatban nem képes hozni a teszt által sugallt eredményt"
Egyedul annyi a problema ezzel, ha a nagykozonseg az AMD altal, a sajat hardvereikre, sajat HSA szoftver stack-ukre fejlesztett megoldas teljesitmenyet probalja levetiteni a HSA-ban rejlo teljes potencialra. Kb. mint ha holnap kidobna az AMD egy sajat benchmark szoftvere altal mért eredmenyt a Carrizora, es az alapjan eldontened, hogy a Carrizo qrva eros proci lesz es megeszi reggelire a Skylake-et jovore. Lehet, hogy a HSA segitsegevel konnyu lesz a Kaveri es Carrizo iGPU-janak teljesitmenyet kiaknazni, siman lehet hogy annak segitsegevel lenyomhato lesz mondjuk a legerosebb Broadwell-K is, de hogy valojaban mire is lesz kepes a HSA, azt nem a jelenlegi HSA megoldasok alapjan dontenem el. Mas lenne a helyzet, ha mondjuk lenne mar tobbfele fajltomorito, tobbfele video enkoder, tobbfele benchmark szoftver is HSA-ra, akkor mar egy sokkal realisabb kepet kaphatnank a HSA optimalizacio _atlagos_ hozadekarol. En csupan attol felek, hogy nagyon hosszu idonek kell eltelnie ahhoz, hogy egy atlagos hw review website altal hasznalt benchmark, applikacio es jatek programok akarcsak negyede is HSA optimalizaciot kapjon.
Plane erdekes kerdes lesz, hogy ha az Intel is beepiti az OpenCL 2.0 es SVM tamogatast (Broadwell es/vagy Skylake), akkor azzal a HSA nelkuli OpenCL 2.0 implementaciok mennyire kezdenek el terjedni. Mert ugye szep dolog HSA-ra fejleszteni, csak epp jelenleg 1 (egy) darab olyan vas van a PC-s vilagban, ami ezt kepes futtatni is, es abbol raadasul baromi keveset is adnak el, tehat a teljes PC-piacra nezve nagyon alacsony a penetracioja a HSA-ready hardvernek. Szoftver fejlesztokent ha donteni kell, hogy OpenCL 2.0 vagy HSA, es mindkettot tamogatja a Kaveri, viszont az OpenCL 2.0-t az aktualis Intel mainstream desktop/mobil processzor is, akkor sok fejleszto inkabb az OpenCL 2.0-ra fog szavazni. Amiben szepen fog hasitani nyilvan a Kaveri is, viszont a Broadwell/Skylake is, noha ott mar egyaltalan nem biztos (sot), hogy az Intel megoldasa lesz gyorsabb. Erdekes lesz, ha vegre OpenCL 2.0-n is egymasnak tud majd feszulni az AMD es az Intel iGPU-ja
[ Szerkesztve ]
-
#14205
dezz
nagyúr
Vitamincsiga
#14198
dezz
nagyúr
válasz
Vitamincsiga
#14198
üzenetére
Nem is értem, Abuék miért nem csinálnak ilyen teszteket...? Nem csak HSA, hanem mindenféle OpenCL is. Már évekkel ezelőtt is volt egy pár ilyen program. (A LuxMark pont nem az igazi, az egy alapvetően CPU-s algoritmus áthackelése OpenCL-re.) Hiszen éppen ezekkel lehetne kézzelfoghatóvá tenni az egész APU-s koncepciót.
BTW, különösen érdekes a Sandra GP FinalcialAnalysis nevű tesztje! Egyrészt eddig csak képfeldolgozóknál láttam ilyen 50x gyorsulást eddig, másrészt a 6800K-hoz képest is 3x gyorsabb. Nem tudom, futtatható-e ez dGPU-n (GPGPU módban), kíváncsi lennék, azok hogy teljesítenek. Tehát, hogy itt a HSA dobott ennyit, vagy egyszerűen a GCN-nek fekszik a dolog.
(#14202): Ő nem úgy értette.
Hanem, hogy a GPU szerinte teljesen eltűnik, mert kiüti az Intel MIC-je (sok kis CPU mag hálózatban).(#14199) Fiery: Az miért lenne gond? Az Intel is sokmindent szponzorált már. Oké, kevés a három, de lesz majd több is, eleve csak nemrég óta elérhető a HSA fejlesztőkörnyezet. Maga a GPGPU is lassan nyer teret.
Egyébként most akkor a Sandra fenti tesztje az egyik, amit az AMD szponzorált? Titeket nem szponzorálnak?
(#14204): Azt természetesen nem tudhatjuk, hogy bukás lesz-e a MIC. Én ezekre a párhuzamokra utaltam: 1. Az Itanium is úgy jött, hogy az most aztán mindenkit letarol és átveszi az x86 helyét. 2. Az első generáció bukás lett, de az Intel nem adta fel, pumpálta bele a milliárdokat. Ez esetben hiába. 3. A MIC is új architektúra, bár az alapot képező mikroarchitektúra csak félig új.
Az utolsó bekezdésből kihagytad a játékokat (újfent), amik azért erős befolyással vannak a PC-re is. Elképzelhető, hogy lesznek majd játékok, amik - PS4/XB1-ról portolva - Kaveri+dGPU konfigon fognak a legjobban futni, ami növelheti az AMD proci-eladásait, és akár más sw-szegmensekben is kedvet csinálhat a HSA-hoz, vagy legalábbis az OpenCL 2.0-ához, amiben egyelőre szintén az AMD a jobb (már csak a jobb IGP okán is).
[ Szerkesztve ]
-
leviske
veterán
"Bocs, de tenyleg nem ertem, mi koze az Itaniumnak a MIC-hez."
A közös pont, hogy egy olyan megoldást kínál, amivel az Intel még jobban be tudja zárni a piacot. Ha az AMD nem jön elő az X86-64-el és az Itanium lenyomja az X86-ot, akkor ma az Intelen kívül kérdés, hogy hány processzorgyártó lenne a piacon. A MIC esetében ugyanez a helyzet, mert ha az válna egyeduralkodóvá, akkor sem az nVidia, sem az AMD, se a Samsung, sem pedig az Apple nem tudna a fősodorban maradni. Na jó, talán az AMD, mivel neki legalább van X86 licenc a tulajdonában.
Emellett a másik közös pont pedig, hogy feltételezem az X86-64 nem egy önálló ötlet volt az AMD-től, hanem a szoftverfejlesztők igényeinek a megtestesítése. Márpedig, ha eddig jól értettem a vitákban felhozott érveiteket, akkor a HSA egy ideális 'sweet spot' lehetne (azaz az X86-64-hez hasonlóan a szoftverfejlesztők érdeke), ha maga a szoftveres oldal már most tökéletes lenne.
"Ahol van konkurenciajuk, az az ultramobil eszkozok (tabletek, telefonok) [...]."
Elég enyhe megfogalmazás ez.
Egy olyan piacon, ahol a gyártók maguk faragják a hardvert, az Intelnek és az AMD-nek konkrét saját termékekkel szerintem sosem lesz esélye labdába rúgni. Még az nVidia is kapott egy szép pofonsorozatot attól a piactól, pedig ők még csak eltérni sem akartak az ARM-től."Kapasbol a mainstream desktop es mobil piac felso fele ilyen, aztan ott vannak az 1, 2 es 4 utas szerverek, a munkaallomasok, a HEDT, stb"
Igen, ezek súlyos tények. Viszont volt már az AMD egy másik piacon hasonló helyzetben, amit aztán az követett, hogy évekig kisebb lapkákkal hozták ugyanazt a teljesítményt, mint a konkurencia.
"Az nVIDIA-nak -- talan -- lenne ehhez megfelelo alapja, csak ok meg nem egyertelmu, hogy milyen iranyba tartanak. Talan abban biznak, hogy az x86 hamarosan elvesziti jelentoseget, es az ARM alapu "APU"-jukkal, egy sajat, proprietary HSA-szeru megoldassal ok is utolerhetik a "nagyokat"." <> "Kisebb eselyt adok annak, hogy osszeallnak az Intellel, bar annak egyebkent abszolut lenne ertelme."
Nem teljesen értem, hogy az aláhúzott rész az irónia-e vagy sem.
Mindenesetre az nVidia-nak egyértelműen érdeke felküzdeni magát a nagyok közé és nekem világosnak tűnik, hogy egy saját HSA szerű megoldással csak akkor tudnák ezt kivitelezni, ha eleve a HSA dominálna a piacon, nem pedig a natív X86, amit az Intel szeretne.Én nVidia & Intel összeborulást még abban az esetben sem éreztem volna abszolút értelmesnek, ha az nV és a ViA sikerrel összeolvadt volna és ezzel Huang keze alá került volna egy X86 részleg is. Még a G80 & CUDA1.0 idejében elkötelezték magukat egy irány mellett és azt tartják. Az az irány pedig több párhuzamot mutat az AMD elképzeléseivel, mint az Intelével.
Ettől függetlenül én nem arról beszélek, hogy az X86 az Intel részéről rossz választás. Ha az volna, nem ölnének még most is rengeteg pénzt a fejlesztésébe. Viszont amíg a MIC egy HSA-n keresztül is támogatható valami, addig nem tűnik logikusnak, hogy az egyelőre kiforratlan compilerek miatt bukjon.
"Plane erdekes kerdes lesz, hogy ha az Intel is beepiti az OpenCL 2.0 es SVM tamogatast (Broadwell es/vagy Skylake), akkor azzal a HSA nelkuli OpenCL 2.0 implementaciok mennyire kezdenek el terjedni."
Kérdés, hogy mennyire éri meg csak az Intel miatt egy az egyben lemondani a HSA használatáról. Nyugodtan világosíts fel, mert sok közöm nincs a szoftverfejlesztéshez. Az én rózsaszín elképzelésem, hogy a compilerek esetleges hibáin túl tekintve a HSA-n keresztül megírható egy kód az AMD cuccai mellett az összes HSA-t támogató ARM cuccra, emellett a HSA-n keresztül, ha jól értem, nem csak az OpenCL-re, hanem Raspberry PI-re is egyszerűbb fejleszteni, így ezen a ponton az Intel az, aki a nehezebb utat járatja a fejlesztőkkel. Bár dereng valami, hogy az ő cuccaikra is lehet HSA-n fejleszteni, de lehet ez hülyeség (mindenesetre, ha mégsem hülyeség, akkor eleve nem is értem, hogy a Broadwell/Skylake miért jelentené a HSA mentes OpenCL2 korszak eljövetelét).
"Az nVIDIA sosem szeretett masok moge beallni"
Észrevételeim alapján inkább az AMD volt, aki beállt az nVidia mögé. A két cég hozzáállásában a legnagyobb különbség az, hogy Huang egy zárt kis királyságban gondolkozik, míg az AMD káoszban, sok belépőben és idővel terveztetésre rászorulókban.
"Egyedul annyi a problema ezzel, ha a nagykozonseg az AMD altal, a sajat hardvereikre, sajat HSA szoftver stack-ukre fejlesztett megoldas teljesitmenyet probalja levetiteni a HSA-ban rejlo teljes potencialra."
Az Intel-féle "tervezzünk hardvert a teszt alá" megoldással meg az a probléma, hogy olyan teljesítményt sugall, amit valójában ideális körülmények közt sem képes hozni a hardver. Ellenben az AMD által tervezett HSA tesztek legalább annak a demonstrálására alkalmasak, hogy példázzák az optimális esetben elérhető maximumot.
"Erdekes lesz, ha vegre OpenCL 2.0-n is egymasnak tud majd feszulni az AMD es az Intel iGPU-ja"
Én inkább arra vagyok kíváncsi, hogy az OpenCl, C++AMP, Raspberry PI, stb mennyire fogják valósan háttérbe szorítani az egyszálas X86 teljesítményt. Meg arra, hogy az AMD milyen módon kívánja a legacy programok ésszerű futtatási sebességét megtartani, ha Puma-utód alapokra helyezik a Carrizo utódját. Arról nem is beszélve, hogy mire volt jó a Bulldozerrel való szenvedés, ha aztán a Bobcat alapjait viszik tovább.
[ Szerkesztve ]
-
#14207
Vitamincsiga
tag
dezz
#14205
Vitamincsiga
tag
"BTW, különösen érdekes a Sandra GP FinalcialAnalysis nevű tesztje!"
Ez nekem is szemet szúrt azonnal!
De van még más APU teszt is a tarsolyukban: [link]
Amire kíváncsi vagyok - és gondolom még jó néhányan
- hogy a Kaveri GPU-jával megegyező dGPU mekkora teljesítményre lenne képes! Természetesen a legerősebb Intel processzorok társaságában...Jó lenne egy varázsgömb ;-)
-
Fiery
veterán
A szponzoracioval vagy azzal, hogy mas helyett az AMD szakemberei portolnak egy adott algoritmust HSA-ra alapvetoen nincs baj. A baj azzal van, ha ennek az eredmenyere valaki azt gondolja, hogy a HSA szeleskoru elterjedesevel mindenki ugyanezt fogja tudni produkalni. Ha ugyanis ugyanilyen hatszelet kapott volna minden szoftver az AMD-tol, Inteltol es nVIDIA-tol is egyarant, akkor mar nem itt tartanank az OpenCL 1.x elterjedeseben sem. Amikor X ceg azt mondja, hogy az o szoftveret csak AMD (vagy csak Intel, vagy csak nVIDIA) GPU-n tudja atvinni CPU-rol OpenCL-re, az mar kapasbol: 1. gyanus, 2. szomoru. Azert gyanus, mert nem tudni, valojaban mi van a dolog mogott: a GPU-gyarto ceg fizetett a szoftver portolasaert a fejlesztonek, vagy eleve ok maguk csinaltak meg a munkat. Gyanus az is, hogy direkt kotottek ki, hogy mas platformra nem portolhatjak ezek utan a szoftvert. Szromoru pedig azert, mert ez nem segiti az iparag fejlodeset. Es ne erts felre, barmelyik ceg csinalja ezt, az szamomra ugyanugy gyanus es szomoru. Mert az elvi lehetoseg meg van egy GPGPU-ra elvben portolhato algoritmus eseteben arra, hogy mindharom GPU-gyarto OpenCL implementaciojara portolni lehessen. Ha egy fuggetlen szoftver fejleszto belefut egy compiler bugba vagy anomaliaba, es az egyik, masik vagy mindharom gyarto nem tamogatja azzal, hogy belathato idon belul javitja az OpenCL compilert, akkor megall a munka. Ez a rögvalosag, amit azonban eltorzit az, ha a 3-bol az egyik gyarto egy adott szoftver fejlesztojet aktivan tamogatja. De ez az egesz szitu megoldodik majd, ha lesznek normalis compilerek, es ha a HSA tenyleg szeleskorben elterjed. Ha mar 50-100 szoftver tamogatja, onnantol mar a nagy atlag meg fogja mutatni az egesz dolog valodi hozadekat. Addig meg en szemely szerint ketkedessel fogadok minden benchmark eredmenyt.
A Sandrarol nem tudok erdemben nyilatkozni, ugyanis annak a fejlesztoje -- az en meglatasom szerint -- egy zseni es/vagy baromi jo iparagi kontaktjai vannak (minden oldalrol, nem csak AMD), akik segitenek neki sok mindenben. Nehez megmondani, hogy milyen jellegu segitseget kap, es ha kap, milyen melysegben. Ennel tobbet nem mondhatok errol, van tobb infom is, de azok nem publikusak. A Sandra altal elert teljesitmenyrol plane nem tudok nyilatkozni, azt mindenki dontse el maga, hogy atlag PC felhasznalokent mennyire erzi hitelesnek es relevansnak az opcios kereskedesi benchmarkokat.
Minket nem szponzoral senki, sajnos
MIC: az a baj, hogy nem vilagos egyelore, hogy a MIC valojaban milyen hosszu vagy rovid tavon lesz az Intel GPU-helyettesitoje. Ha mar ismernenk a Skylake iGPU-janak pontos felepiteset, talan konnyebb dolgunk lenne. En nem vagyok meggyozodve arrol, hogy a MIC lesz hosszutavon a megoldas, inkabb egyfajta koztes lepcsonek gondolnam. Abban igaza van Abunak, hogy AVX-512-ben nativan kodolni nem konnyu, viszont az sem vilagos, hogy az Intel mikepp probalja a HSA-t lemasolni vagy valami hasonlot kinalni a fejlesztoknek, hogy megkonnyitse az eletuket. 2-3 ev mulva mar latni fogjuk szerintem az iranyt, es sokat fog az is segiteni, ha latjuk mar, hogy az nVIDIA merre lep tovabb.
A jatekokkal azert nem kivanok foglalkozni, mert egyreszt nem erdekelnek engem szemely szerint; masreszt meg mert nem tul valoszinu, hogy egyik jatekfejleszto is meglépné azt, hogy kifejezetten a Kaverira/Carrizora optimalizaljon egy jatekot oly modon, hogy azonos render eredmennyel jarjon Intel es nVIDIA GPU-n, valamint AMD dGPU-n is. Tudom, ez igy kicsit kusza
Szoval arra gondolok, hogy az siman elofordulhat, hogy egy portolt jatek full detailben Kaverin fog szepen szaladni, es lemaradnak a konkurens megoldasok, beleertve az AMD dGPU-kat is. Az viszont kizart, hogy ne legyen a jatekokban 1-2 alacsonyabb reszletessegu, kifejezetten nem-Kaveri beallitasi lehetoseg. Vegeredmenyben pedig a Kaverit nem ugy fogja tudni promotalni az AMD, hogy gyorsabb, mint mondjuk egy Broadwell vagy egy GeForce dGPU, hanem ugy, hogy maskepp nez ki a jatek Kaverin, szebb effekteket fog tudni portolni a konzolrol PC-re a Kaveri segitsegevel. Ez viszont -- bar en nem vagyok jatekos -- SZVSZ keves lesz ahhoz, hogy valaki Kaverit valasszon mondjuk egy Broadwell+GeForce vagy Broadwell+Radeon dGPU kombo helyett. Anno voltak mar hasonlo proprietary GPU effektes probalkozasok, es azok sem jottek be, sajnos. Nem vesz senki egy adott hardvert csak azert, mert 1-2 jatekban szebben fodrozodik a viz, mikozben az osszes tobbi jatekban alacsonyabb FPS-t ad, mint egy masik vas. -
Fiery
veterán
válasz
leviske
#14206
üzenetére
Ertem, hogy mit mondasz a MIC vs. Itanium parhuzamrol, de SZVSZ semmi ertelme oket parhuzamba allitani. Az Intel mar most is kvazi monopol helyzetben van a PC-s processzorok piacan, ennel jobban mar nem lehet kizarni a konkurenciat, mert me'g a vegen feldaraboljak oket is az antitroszt torvenyekre hivatkozva. Jelenleg pedig egyaltalan nem ugy tunik, hogy aka'r az AMD, aka'r az nVIDIA fel akarna szallni valaha is a MIC-vonatra. Ami nem is csoda, hiszen me'g nem latszik, mire is lesz jo ez az egesz a gyakorlatban.
"Emellett a másik közös pont pedig, hogy feltételezem az X86-64 nem egy önálló ötlet volt az AMD-től, hanem a szoftverfejlesztők igényeinek a megtestesítése"
Nem kell am azt gondolni, hogy a szoftver fejlesztok iranyitjak a vilagot
Me'g ha egy adott ceg azt is mondja, hogy a partnerek/baratok/kliensek igenyei szerint is fejlesztett valamit, ez egyaltalan nem biztos, hogy igaz. Plusz, honnan tudod, hogy ha meg is hallgattak nehany szoftver fejlesztot, valojaban hany fejlesztot hallgattak meg, es mennyi mindent valositottak meg abbol, amit ok szerettek volna? Minden fejlesztonek masok az igenyei, mindent nem lehet megvalositani, mindig vannak korlatok, mindig kell kompromisszumokat tenni.De ne erts felre, nem biralom az AMD64-et (nevezzuk inkabb igy), nagyon jo kiegeszitese a klasszikus x86-nak. Viszont, ha nincs a Microsoft, vagy a Microsoftot az intel meg tudja gyozni, akkor az AMD64 mar reg a 3DNow! sorsara jutott volna, es az Intel altal lekoppintott Intel64 lenne most az egyeduralkodo. A Microsoft volt az, aki az asztalra csapott, es nem volt hajlando egyszerre harom 64 bites architekturat tamogatni a Windowsban. Lenyegeben rakenyszeritettek az Intelt, hogy adoptaljak az AMD64-et. Persze ha anno az Intel jobban latja a jovot, akkor mar akkor eldobhattak volna az IA-64-et, es valthattak volna Intel64-re.
"Elég enyhe megfogalmazás ez.
Egy olyan piacon, ahol a gyártók maguk faragják a hardvert, az Intelnek és az AMD-nek konkrét saját termékekkel szerintem sosem lesz esélye labdába rúgni."Just wait & see
"Viszont volt már az AMD egy másik piacon hasonló helyzetben, amit aztán az követett, hogy évekig kisebb lapkákkal hozták ugyanazt a teljesítményt, mint a konkurencia."
Hidd el, en oszinten szurkolok annak, hogy ujra legyen egy K8-a az AMD-nek. Ujra rugjak s*ggbe az Intelt, hogy megint jobban igyekezzen. Mert az Intel most nagyon el van tunyulva a mainstream PC-s szegmensben, es minden erejukkel az ultramobilt toljak. Jo lenne, ha megint lenne rendes konkrenciajuk minden szegmensben.
"Nem teljesen értem, hogy az aláhúzott rész az irónia-e vagy sem"
Abszolut komolyan gondoltam. Az Intel es az nVIDIA egyutt baromi erosek lennenek. Egyedul az a gond, hogy az nVIDIA vezere tul becsvagyo, es leginkabb akkor menne bele egy egyesulesbe, ha az uj ceget is o vezethetne'. Siman lehet, hogy ragaszkodna ahhoz is, hogy nVIDIA legyen az egyesules neve. Ez pedig nyilvan nem fer bele a kékeknek...
"Én nVidia & Intel összeborulást még abban az esetben sem éreztem volna abszolút értelmesnek, ha az nV és a ViA sikerrel összeolvadt volna és ezzel Huang keze alá került volna egy X86 részleg is."
Hidd el, ez a felvasarlas felmerult. A problema csupan az, hogy az x86 licenc non-transferable. Azaz, ha a ceget, aminek jelenleg van x86 licence, felvasarolja egy masik ceg, akkor a felvasarolt ceg elvesziti az x86 licencet. Az Intel pedig anno par eve me'g olyan pozicioban volt, hogy nem hianyzott neki me'g egy x86 konkurens, plane nem egy olyan szivos, eros ceg, mint az nVIDIA. Manapsag, hogy a VIA mar szinte eltunt az x86 piacrol, es az AMD-t is konnyebb "kezelni" (ertsd: gyengebb termekeket gyart, csokkent a relevanciaja az x86 piacon), talan nem zavarna az Intelt annyira, ha belepne egy uj x86 szereplo. De kivanatosnak biztos nem gondoljak, tehat nem fogjak szorgalmazni
"Az az irány pedig több párhuzamot mutat az AMD elképzeléseivel, mint az Intelével."
Persze, csak a G80 idejeben me'g nem lehetett elore latni, hogy mikor utkozik falnak a gyartastechnologia. Ha az nVIDIA-t megszivatja a TSMC, es nem tudjak normalisan legyartani a high-end Maxwell GPU-kat, akkor nagyon hamar rohadt nagyot koppanhat az nVIDIA. Az Intel gyartastechnologiajat -- talan -- be lehetne vetni a dGPU-knal is, ergo egy gyartasi kooperacioval az nVIDIA sokat nyerhetne _elvben_. A gyakorlat azonban maskepp mukodik, sok dontest a politika mozgat, ill. az nVIDIA vezere sem egyertelmu, hogy merre akarja vinni a cégét...
"Kérdés, hogy mennyire éri meg csak az Intel miatt egy az egyben lemondani a HSA használatáról."
Miert kellene barmirol is lemondani? Megirod a kernelt OpenCL 2.0-ban, es vagy HSA path-re kuldod a vegrehajtast, vagy OpenCL-re.
"Az Intel-féle "tervezzünk hardvert a teszt alá" megoldással meg az a probléma, hogy olyan teljesítményt sugall, amit valójában ideális körülmények közt sem képes hozni a hardver."
Egy konkret peldat kérek erre.
"Én inkább arra vagyok kíváncsi, hogy az OpenCl, C++AMP, Raspberry PI, stb mennyire fogják valósan háttérbe szorítani az egyszálas X86 teljesítményt"
Ezt konnyen le tudod tesztelni magadon is akár. Hasznalj par napig egy Kabini vagy Bay Trail alapu desktop gepet. Ha folyamatosan azt erzed, hogy lassu, akkor szamodra az egyszalas teljesitmeny a donto, es a HSA/OpenCL sem fog segiteni. Ha azonban teljesen korrektnek erzed ezeket a low-power cuccokat, akkor me'g jo lehet a HSA/OpenCL is Nalad. Van 1-2 ismerosom, aki ilyen Kabinis ill. Bay Trail-es konfigot kapott tesztelesre, es köpködik oket, hogy erzesre, a mindennapi hasznalat soran milyen lassuak. Nyilvan egy Haswell i5 vagy i7, de me'g egy Kaveri utan is termeszetes ez, csak epp ez is jol mutatja azt, hogy az egyszalas teljesitmeny mennyire donto tud lenni sok PC felhasznalonal. Mert ha a tobbszalas teljesitmenyt nezzuk, akkor a Kabini es a Bay Trail is eros CPU-k, csak epp megsutheted a tobbszalas teljesitmenyt, ha nincs ami kihasznalja. Nagy kerdes, hogy a HSA/OpenCL tul tud-e lepni majd ezen a probleman.
"Arról nem is beszélve, hogy mire volt jó a Bulldozerrel való szenvedés, ha aztán a Bobcat alapjait viszik tovább."
A Bulldozer (volt) az AMD NetBurstje, ilyen egyszeru. Minden cegnek vannak zsakutcaba szorult termekei, nincs ezzel gond, ha idoben jon a korrekcio. Az AMD-nel -- szerintem -- kicsit keson jon a korrekcio, de nem tul keson me'g, szerencsere. Ha a Puma+ utoda skalazhato lesz 4 GHz-ig, akkor jo lehet a Bulldozer kivaltasara. Ha azonban megmaradnak a Puma+ szintjen orajelben es teljesitmenyben, akkor az keves lesz, HSA ide vagy oda.
-
Fiery
veterán
"Nem is értem, Abuék miért nem csinálnak ilyen teszteket...? Nem csak HSA, hanem mindenféle OpenCL is"
Majd Abu is leirja az okokat, de szerintem az a legfobb problema, hogy nincsenek igazan OpenCL-t mindharom platformon korrektul kihasznalo real-world applikaciok. A benchmarkokat, foleg a szintetikus benchmarkokat pedig a PH-sok nem szivesen hasznaljak a tesztekhez.
-
leviske
veterán
"Jelenleg pedig egyaltalan nem ugy tunik, hogy aka'r az AMD, aka'r az nVIDIA fel akarna szallni valaha is a MIC-vonatra."
Konkrétan milyen formában kéne az nVidia-nak felugrani a MIC vonatra és mi célból tenné, ha ezt képest gyakorlatilag RISC alapon is kivitelezni?
"Nem kell am azt gondolni, hogy a szoftver fejlesztok iranyitjak a vilagot" <> "Viszont, ha nincs a Microsoft"
Egyébként nem gondolom, de logikusnak tűnik egyeztetni a piac egy-két reprezentatív tagjával és annak megfelelően fejleszteni."Just wait & see"
Ebbe a hozzáállásba már korábban többször belekötöttem. Az egy dolog, hogy az Intel egy nagyon komoly piaci erőt képvisel, de azért vannak nála nagyobb cégek is, köztük pár HSA alapítványtag.
"Hidd el, ez a felvasarlas felmerult."
Én elhiszem, mert emlékszem, mégha akkor még tini voltam is akkoriban. Épp ezért használtam a felvásárlás helyett az összeolvadás szót, csak gondolom egy ilyen cég jogutódja se kaphatta volna meg az X86 licencet.
"Ezt konnyen le tudod tesztelni magadon is akár."
Erről nekem is ez a véleményem: "Nagy kerdes, hogy a HSA/OpenCL tul tud-e lepni majd ezen a probleman." és erre is céloztam az idézett mondattal.
-
#14212
dezz
nagyúr
Vitamincsiga
#14207
dezz
nagyúr
válasz
Vitamincsiga
#14207
üzenetére
Hmm, ahogy nézem, ez nem kimondottan HSA-s teszt, hanem CUDA/OpenCL. Kár, hogy a Scientific Analysis nevű tesztet kihagyták a tesztben.
Érdekes szalagcímek vannak a főoldalon:
Sandra 2014 : OpenCL ES Android Tablet GP(GPU) Battle ARM vs. x86: Which is the best? @ SiSoftware
Sandra 2014 : OpenCL GPGPU Android Battle : Which is the best? (Qualcomm vs. Samsung) @ SiSoftware(#14208) Fiery: A WinZIP-re gondolsz? Nos, az eléggé jelentéktelen alkalmazás. De amúgy Abu azt mondta róla, hogy nem az AMD kérésére késleltették az Nvidia/Intel supportot (nem sokat számított a dolog, mint írtam, nem egy létfontosságú alkalmazás, vannak jobbak a feladatra), hanem egyszerűen nem ment velük rendesen. Szóval, ezt nem kell túldramatizálni/túldimenzionálni.
Voltak már korábban is más jellegű OpenCL-lel gyorsított programok, amik hasonló speedupot értek el, nincs ebben semmi igazán különleges. Hozzáteszem: ezek valós alkalmazások voltak, Abuék mégsem használták a tesztekben.
Ha lesznek egyes PS4/XB1 játékoknak Kaverire külön ráoptimalizált portjai, azok szerintem nem apró látványeffektekben lesznek különbek, hanem inkább arra számítok, hogy pl. a fizikai szimuláció számítását bízzák az IGP-re, miközben a többit dGPU számolja, így egy Kaveri+dGPU konfigon is ugyanúgy vagy akár jobban futhat, mint egy drága i7 alapú konfigon, ez lehet az előnye. Más kérdés, hogy a hagyományos játékok továbbra is az utóbbin fognak jobban futni, de előfurdulhat, hogy valaki kimondottan az említett portokkal akar játszani. (Úgy vettem észre, a konzolos játékok sokszor kidolgozottabbak és/vagy jobban építenek a játékélményre.)
(#14209): Most írtad, hogy szerinted a MIC megöli a GPU-kat. Ennél nagyobb monopolhelyzet mi lenne?
Abból a szempontból tökéletes a párhuzam, hogy a MIC is nagy sebbel-lobbal jön, egyesek által előre a végső győztesnek kikiáltva, és ugyanúgy nem vált be az első 1-2 generáció.
Az AMD64 megalkotásakor minimum két teljesen nyilvánvaló igényt vettek figyelembe: x86 alapú 64 bit (nyilván) és az eddig kicsit szegényes regiszterkészlet számbeli növelése (a szélesítés mellett).
"es az Intel altal lekoppintott Intel64 lenne most az egyeduralkodo."
Ez a mondat némileg félreérthető, hiszen az AMD64 Intel-féle implementációját is így hívják. A MS azért csapott az asztalra, mert az AMD64 teljesen jó volt, el is kezdték portolni rá már a Windowst, amikor az Intel előállt a saját, hasonló megoldásával, és a MS-nak nem csak pluszmunka lett volna arra is portolni, de teljesen felesleges is (csak az Intel érdekeit szolgálta volna).
-
dezz
nagyúr
Ez volt az a teszt, amit emlegettem:
Can OpenGL And OpenCL Overhaul Your Photo Editing Experience?
Dátum: 2012. június 10.
Felsorakoztatott programok: GIMP, AfterShot Pro, Musemage, Photoshop CS6.Azóta sem láttam hasonlót, csak most ezt a wccftech.com-osat. Nagyobb oldalakon semmi. (Még a fenti cikkben beígért folytatás sem jelent meg.) Mintha egy kék ködbe vesző kéz megkocogtatta volna a vállukat és azt suttogta volna egy hang, hogy nono, álljunk csak le ezzel nagyon gyorsan!
[ Szerkesztve ]
-
leviske
veterán
válasz
leviske
#14211
üzenetére
Kimaradt az Intel-féle tesztelős móka. Sajnos nem tudok példát hozni, de holnap szívesen visszakeresek olyan hozzászólásokat, ahol te is elismered, hogy az IGP eredményeket igyekszik/igyekezett a cég szépíteni több alternatív módon is. Talán rendes grafikai megoldások mellett felmerült az OpenCL is, de ebben nem vagyok már biztos.
-
Fiery
veterán
válasz
leviske
#14211
üzenetére
"Konkrétan milyen formában kéne az nVidia-nak felugrani a MIC vonatra és mi célból tenné, ha ezt képest gyakorlatilag RISC alapon is kivitelezni?"
Ennyi erovel azt is kerdezhetned, hogy miert erolteti az AMD me'g mindig az x86-ot
Sosem tudhatod, mit hoz a jovo, hova fejlodik a MIC, a CUDA vagy epp a GCN es a HSA. De ha mondjuk feltetelezunk egy olyan jovot, ahol a HSA nem er el attorest, a CUDA megragad a mostani szinten, a dGPU-k relevanciajukat vesztik (a KNL-szeru megoldasok miatt), a MIC viszont befut es mindenki nativ x86-on akarja a "GPU"-t is programozni, akkor pl. szuksege lehet x86 licencre az nVIDIA-nak. Nem mondom, hogy ez fog tortenni, csak mint egy lehetseges forgatokonyvet vazoltam fel. Anno az x86-ra sem gondolta volna senki, hogy ilyen sikert fog befutni, aztan tessek... Persze ennyi erovel siman lehet, hogy a HSA lesz a kiraly, es akkor az architektura lesz erdektelen, barki barmit csinalhat, amig a HSA-ra fejlesztett kodot tudja futtatni a vas."logikusnak tűnik egyeztetni a piac egy-két reprezentatív tagjával és annak megfelelően fejleszteni."
A logika ezt diktalja, a valosag azonban az, hogy a gyartok hozzaszoktak ahhoz, hogy ok megmondjak mindenkinek, hogy mire van szukseguk. Ez vezetett aztan oda, ahol most tartunk, pl. Windows 8, AVX, stb. Kerdes, hogy ha megforditjuk a dolgot, es -- legalabbis a retorika szintjen -- a fejlesztok kezebe adjuk a jovot, akkor mi fog tortenni. Mas lenne ugyanis a helyzet, ha jonne egy zseni szoftver fejleszto, aki kitalalja, hogy mikepp nezzen ki a HSA, mikepp tud majd segiteni az o munkajaban, es utana egymaga lekodolja az osszes szukseges compilert, finalizert, szoftver stacket, drivert, stb az osszes hardver gyarto szamara. Ez nyilvan lehetetlen, senki sem ekkora zseni es egy nyilvan ra kell dobni egy csomo fejlesztot minden gyartonak, csak tudod az a szomoru ezzel az egesszel, hogy hany eve is fejleszti az OpenCL implementaciojat az ATI/AMD? Hany eve fejleszti az Intel, az nVIDIA? Es me'g mindig nem tokeletes, sot. Leginkabb f*s me'g mindig, egyedul talan az nVIDIA-e hasznalhato, hellyel-kozzel. Mi a garancia arra, hogy a HSA-val maskepp fog mukodni a dolog? Mi a garancia arra, hogy nem tart 6-7 evig, mire hasznalhato lesz a HSA a szoftver fejlesztok szamara?
"Az egy dolog, hogy az Intel egy nagyon komoly piaci erőt képvisel, de azért vannak nála nagyobb cégek is, köztük pár HSA alapítványtag."
Az Intel es az x86 mar az elmult cca. 30 evben is lenyomott par olyan piaci szereplot, akit nem gondoltunk volna, hogy le tud nyomni. Nem mondom, hogy tevedhetetlenek, de amig az egesz vilag nem all szemben az Intellel, addig nehez kiszoritani oket a piacrol. Plusz, az, hogy valaki HSA alapitvanytag, me'g nem sokat jelent. Mit csinal a VIA? Mit csinal a Samsung? Hol vannak a Samsung SoC-ok, amik HSA-ready-k? Ha a Samsung nem keszult el veluk, akkor a kisebbek mikor fognak? Miert nincs az alapitvanyban a Google, az Apple, a Microsoft es az nVIDIA? Lehet, hogy a HSA alapitvanyhoz csatlakozott nehany nagy nev, de kozben meg baromi sok nagy nev nem. Mindenki sutogeti a sajat pecsenyejet, igy pedig nehezen fog tudni elrugaszkodni a HSA pl. Androidon vagy iOS-en.
-
Fiery
veterán
"A WinZIP-re gondolsz? Nos, az eléggé jelentéktelen alkalmazás"
A JPEG dekoder is, ennyi erovel
Barmire ramondhatod, hogy jelentektelen, de pont ezert is irtam fentebb azt, hogy 50-100 HSA-s alkalmazasig nem is igazan van ertelme odafigyelni a benchmark eredmenyekre."De amúgy Abu azt mondta róla, hogy nem az AMD kérésére késleltették az Nvidia/Intel supportot (nem sokat számított a dolog, mint írtam, nem egy létfontosságú alkalmazás, vannak jobbak a feladatra), hanem egyszerűen nem ment velük rendesen. Szóval, ezt nem kell túldramatizálni/túldimenzionálni"
Vagy ugy volt, vagy nem. En nem hiszem el egyik es masik variaciot sem. Mindketto lehetseges ugyanis. Az OpenCL compilerek tenyleg annyira sz*rok, hogy siman lehet, hogy elso korben a WinZIP nem mukodott rendesen egyik gyarto OpenCL megoldasaval sem. Az is elkepzelheto, hogy az AMD onszorgalombol segitett a WinZIP-et osszekalapalni. Az is elkepzelheto, hogy a masik 2 gyarto sz*rt az egeszre. De az is ugyanolyan realis forgatokonyv, hogy az AMD kereste meg a WinZIP fejlesztojet (Corel), hogy noszogassa oket, hogy csinaljak meg OpenCL-re a tomoritot, hogy vegre legyen valami hangzatos nevu Windows utility, amit OpenCL-re is portolnak es/vagy eleve meg is csinaltak nekik a portolast. Hazon belul a gyartok sokkal konnyebben meg tudjak ezeket oldani, hiszen ha az OpenCL kernel fejlesztese ill. tesztelese kozben valami compiler bug elojon, csak atszol a kolleganak, hogy fekudjon ra a temara gyorsan. Egyszeru kis porbaf*ngo szoftver fejlesztokent meg egy-egy ilyen bugnal heteking, honapokig tart, mire az AMD/Intel/nVIDIA kijavitja a compilert, es tudod folytatni a fejlesztest. Ez a nagy baj, ezert ketelkedek en az egesz HSA-s, OpenCL-es buliban. Az egesznek az alapja egy kvazi hibatlan, jol hasznalhato compiler kellene hogy legyen. Onnantol lehet rendesen dolgozni fejlesztokent. Ezert olyan sikeres a Visual C++, gcc es tarsaik: regi, kiforrott, stabil compilerek, amiknel nem kell egyfolytaban a compiler fejlesztojehez szaladgalni, mert megint elojott egy bug. Nyilvan ha par honap mulva hirtelen kijon pl. az OpenCL 2.0 --> HSAIL compiler, megtamogatva a Kaverihez a megfelelo finalizerrel es kornyezettel, es az elsore hibatlanul fog mindent forgatni, es a media tele lesz a halalkozo szoftver fejlesztok success story-jaival, akkor azt fogom mondani, hogy na ez igen, ezt nem vartam, de fantasztikus, sracok, jol dolgoztatok. Viszont, ha azt nezzuk, hogy lenyegeben ugyanez a melo allt eddig is az AMD, Intel es nVIDIA elott (azaz hogy OpenCL-rol a sajat belso IL-jukre forditsanak), es 6 ev alatt egyik gyarto sem tudott rendes compilert fejleszteni, akkor nem tartom valoszinunenk, hogy meg kellene kovetnem a HSAIL compiler fejlesztoket me'g az iden -- vagy akár jovore.
"Voltak már korábban is más jellegű OpenCL-lel gyorsított programok, amik hasonló speedupot értek el, nincs ebben semmi igazán különleges. Hozzáteszem: ezek valós alkalmazások voltak, Abuék mégsem használták a tesztekben."
Konkret peldakat kerek ilyen alkalmazasokra. Mindharom platformon, korrektul mukodjon. WinZIP egynek jo.
"Ha lesznek egyes PS4/XB1 játékoknak Kaverire külön ráoptimalizált portjai, azok szerintem nem apró látványeffektekben lesznek különbek, hanem inkább arra számítok, hogy pl. a fizikai szimuláció számítását bízzák az IGP-re, miközben a többit dGPU számolja, így egy Kaveri+dGPU konfigon is ugyanúgy vagy akár jobban futhat, mint egy drága i7 alapú konfigon, ez lehet az előnye"
Ez nagyon keves elonynek, sajnos
Plusz, a fizikaval mar probalkoztak nehanyan, pl. PhysX annak idejen, es nem igazan latom azt, hogy valaki a fizikai szimulacio miatt valasztana egy adott hardvert. Mikor hallottal utoljara olyan juzerrol, hogy vasarolt volna a gepebe plusz egy GeForce videokartyat, hogy a fizikai szamitasokat arra bizza? De egyebkent nem csodalkozok, ha a fizika felol probalkozik az AMD, ugyanis az AMD HSA fejlesztoi csapataban tobb volt Ageia-s (es igy volt nVIDIA-s) is van, tobbek kozt az egyik Ageia alapito is."Most írtad, hogy szerinted a MIC megöli a GPU-kat. Ennél nagyobb monopolhelyzet mi lenne?"
Arra gondoltam, hogy ugy oli meg a GPU-kat, hogy egy uj kategoriakent lep be a piacra. Socketelt GPU-szeru megoldas, ami operacios rendszert is futtat, es gond nelkul lehet masszivan multi-threadelt hagyomanyos x86 szoftverek futtatasara is hasznalni. Vagy egy olyan CPU, ami a GPU feladatokat is ellatja, attol fugg, honnan nezzuk. Ilyet adott esetben az nVIDIA vagy az AMD is keszithet. En ezt az uj CPU/GPU/akarmit nem hivnam mar GPU-nak, es siman lehet, hogy az Intel is kitalal majd ra valami uj betuszot a KNL bemutatasaig. Az viszont alapveto kerdes, hogy ha valaki hasonlo megoldast keszit (en az nVIDIA-t varnam elso korben, hogy meglepi), akkor milyen ISA-t valaszt hozza. Ez szabadon eldontheto, csak ugye compilert kell erre is fejleszteni, ha nem x86-ot/MIC-et valaszt az adott gyarto. Az is kerdes, hogy a MIC-hez van-e hozzaferese az AMD-nek, de elvileg kell hogy legyen, a keresztlicenc megallapodas alapjan.
[ Szerkesztve ]
-
Fiery
veterán
válasz
leviske
#14214
üzenetére
Nekem nem remlik ilyesmi, de nem is zarom ki a lehetoseget. De ennyi erovel siman mondhatod azt is, hogy egy X benchmark hulyeseget mér, mert egy olyan x86 kiterjesztesre valo optimalizaciot hasznal (pl. AVX2 vagy XOP), amit amugy a szoftverek 99 %-a nem hasznal. Igy gondolkoztak anno az SSE megjelenesekor is sokan, es par evig igazuk is volt. Manapsag meg mar teljesen altalanos, hogy egy adott szoftver SSE nelkul el se indul
-
Abu85
HÁZIGAZDA
Én abból indulok ki, hogy MIC-ről az Intel saját mérnökei mondták, hogy nem fog működni. Még ha az lenne, hogy az NV és a többiek piszkálják. Na jó az NV nagyon sokat röhögött a koncepción, de nyilván ez nem releváns. Az viszont az, hogy a projekt elindítása után az Intel beszervezte a világ legokosabb mérnökeit és szoftverfejlesztőit, akik aztán mind otthagyták a koncepciót. Még ha csak egy emberről lenne szó, de Andrew Richards mellett Michael Abrash, Atman Binstock, Tom Forsyth, Mike Sartain és John Gustafson is be lett vonva a projektbe és amint kiderült, hogy az Intel vezetősége ragaszkodik az x86-hoz kiléptek. A cégen belül ők mondták a legjobban, hogy ez nem lesz jó. Azóta a MIC fejlesztése átkerült Izraelbe.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Fiery
veterán
"beszervezte a világ legokosabb mérnökeit"
Ezt mar mashol is elsutotted, es ott sem tudtal bizonyitekkal szolgalni arra, hogy valoban ok a legokosabbak. Nem ketlem, hogy az Intel a legjobb mernokoket probalja magahoz csalogatni, de azert ne jelentsuk mar ki az Inteltol kibukott/kirugott/kilepett mernokokrol automatikusan azt, hogy ok a legokosabbak, csak azert mert fikazzak a MIC-et, amin dolgoztak.
"Azóta a MIC fejlesztése átkerült Izraelbe."
Helyes, ott fejlesztettek ki a Conroe-t is, ami ha nem tevedek, az Intel jelenlegi sikerenek egyik kulcsa. Vagy valami problema van azzal az orszaggal? Ott nem a legokosabb mernokok dolgoznak, hanem masodvonalbeli bean counterek?
![;]](//cdn.rios.hu/dl/s/v1.gif)
[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
JPEG-et állandóan nézegetnek az emberek. Amikor letöltik a képet a netről, akkor azt a gép még kikódolja és úgy jeleníti meg a böngészőben. A JPEG gyorsabb dekódolása fogyasztáscsökkenést is jelent. Ezért rakott az Intel is a Haswellbe dedikált JPEG dekódoló fixfunkciós hardverblokkot, mert ez egy olyan terület, ami nagyon is számít.
Az Intel és az AMD koncepciója között nincs akkora különbség, csak az Intel a saját rendszerét nem tudja beépíteni a Windowsba, míg az AMD úgy tervezte a sajátját, hogy ezt meg tudják tenni. Az Intel cucca programszinten lenne használható, például IrfanView, csak a Windows problémák miatt nincs is rá SDK.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Fiery
veterán
A JPEG-et en arra irtam, hogy ha a WinZIP jelentektelen, akkor ennyi erovel a JPEG dekoder is az. Kinek mi a jelentektelen es kinek mi a relevans. En nem nezek tul sok JPEG-et (es nem erdekel a fogyasztas sem, nincs mobil PC-m), es nem hasznalok WinZIP-et, sz'al nekem mindketto jelentektelen. De a nagykozonseg szamara barmelyik lehet erdekes vagy lenyeges. Csupan annyi a problema, hogy me'g ha a "kicsiket" is szamba vesszuk, akkor is rohadt keves az OpenCL es HSA applikacio _jelenleg_.
[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
Nézd meg azokat a neveket, hogy kik ők pontosan. Azért csábították őket a MIC-hez, mert rengeteg hardver és szoftvertapasztalatuk van a data-parallel rendszerekről. A maguk területén igazi zsenik, a legjobbak.
Az izraeli csapat soha az életben nem dolgozott data-parallel hardveren. Kaptak egy feladatot, amit John Gustafson a data-parallel rendszerek szakértője nagyjából 20 éves tapasztalattal nem tudott megoldani. Mit várunk tőlük? Nem is erre a területre specializálódtak. Egyedül a ZiiLabs korábbi mérnökeinek van fogalmuk róla, hogyan kell data-parallel rendszert építeni. Ők beépültek, de ettől még ugyanaz lesz a gondjuk, mint a kilépett csapatnak. Tudnak készíteni egy parallel ISA-t és rá egy data-parallel hardvert, de az Intel azt kéri, hogy egy serial ISA-ra építsenek ilyet.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Fiery
veterán
"A maguk területén igazi zsenik."
Igazi zsenik lehetnek, de a legokosabb kifejezes akkor is eros. Okos, zseni, hatalmas tehetseg, ezek rendben vannak. A "leg" jelzot kellene ovatosabban hasznalnod, mert ahhoz minimum egy rangsor kellene, mint az olimpiakon a sportagakban. Arany, ezust, bronz medal, mernokoknek, akkor mondhatnad, hogy XY a legokosabb mernok vagy a legokosabb szoftver fejleszto.
"de az Intel azt kéri, hogy egy serial ISA-ra építsenek ilyet."
Majd megoldjak, legyen ez az o problemajuk. Ha megoldjak, akkor mit fogsz mondani? Hogy bocs, de megsem John Gustafson a legokosabb mernok?
Ha meg nem tudjak megoldani, ha zsakutca lesz vegkepp a MIC, akkor majd elovesznek egy B-tervet. Az Intel behuzta mar magat tobbszor is zsakutcaba (NetBurst, Itanic, Tejas), es mindig meg tudott ujulni, mindig volt ujabb otletuk. Mint ahogy az AMD-nek is, mellesleg, ok is ugyesen tudnak valtani. Majd lesz valami mas, ha a MIC nem valik be.De egyebkent megertem, ha sokan ketelkednek a MIC-ben. Teny, hogy a jelenlegi formajaban tenyleg nehez elkepzelni, hogy utokepes lehet. De a KNL-rol nem sok konkretumot tudunk, a Skylake-rol meg me'g annyit sem. Siman lehet, hogy lesz bennuk valami olyan szoftveres vagy hardveres trukk, amivel athidalhatoak a jelenleg lathato problemak. Pl. egy HSA-szeru absztrakcio az x86 felett, sokszoros HyperThreading, ujfajta utemezo es dekoder, stb.
-
Abu85
HÁZIGAZDA
A MIC-hez csak egy új memória és szinkronizációs modell kell és rögtön működni fog. A probléma az, hogy az Intel vezetősége ezt nem engedi meg. Ezért nem rezelt be ettől a rendszertől senki, mert a data-parallel területen dolgozó mérnökök pontosan tudják, hogy mi működik és mi nem.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
leviske
veterán
"A logika ezt diktalja, a valosag azonban az, hogy a gyartok hozzaszoktak ahhoz, hogy ok megmondjak mindenkinek, hogy mire van szukseguk."
Ez egészen addig egy teljesen igaz állítás, míg az adott gyártó izomból, a saját elképzelései szerint tudja hozni mindenkinek az igényeit. Viszont kérdés, hogy amennyiben az Intel sikeresen megszül egy versenyképes MIC-et, akkor mégis hogy fogja fenntartani a fejlődést, ha maga az első sikeres MIC is eltart x generáción keresztül?
"hany eve is fejleszti az OpenCL implementaciojat az ATI/AMD? Hany eve fejleszti az Intel, az nVIDIA?"
Alapvetően kevesebb ideje fejlesztik, mint amennyi ideje a MIC kalapács alatt van. Pedig, ha még esetleges hibákkal is, de működik.
Emellett, ha a DirectX el tudott jutni arra a szintre az évek folyamán, hogy használható legyen, akkor nem tudom, hogy a OpenCL miért ne mehetne végig ugyanezen. Pláne, hogy pontosan ennek a koordinálására jött létre a HSA tudomásom szerint."Nem mondom, hogy tevedhetetlenek, de amig az egesz vilag nem all szemben az Intellel, addig nehez kiszoritani oket a piacrol."
Milyen szinten kellene megnyilvánulnia, hogy az egész világ az Intel ellen van? Teljesen őszintén és ártatlanul kérdezem. A HP nem olyan rég kijelentette, hogy függetlenedni akar a Microsofttól és az Inteltől, a Samsungnak és az Apple-nek megvan a maga processzorgyártó részlege, az nVidia meg túl magas áron kaphatna X86 licencet pláne annak fényében, hogy anélkül is van járható út.
Sok monopol helyzetben lévő céget taszítottak mostanság le a helyéről. Az Intel esetében pedig az a faramuci helyzet áll fenn, hogy még csak taszigálni sem kell senkit, hiszen az OpenCL/RaspberryPi/C++AMP létezik a MIC jelenlétében is, ellenben a MIC nem lehet átütő és piacátformáló siker, amíg ezek léteznek és van esélyük használatba kerülni.
Márpedig, ha a HSA-t kivesszük a képletből, akkor az említett megoldások mögött áll többek közt az Apple/Google/Microsoft.[ Szerkesztve ]
-
Fiery
veterán
válasz
leviske
#14225
üzenetére
"Viszont kérdés, hogy amennyiben az Intel sikeresen megszül egy versenyképes MIC-et, akkor mégis hogy fogja fenntartani a fejlődést, ha maga az első sikeres MIC is eltart x generáción keresztül?"
Ha mar van egy sikeres, stabil alap, arra mar konnyebb epitkezni, mint nullarol indulva eloszor rossz iranyba indulni (videokartya projekt), majd korrekciokkal eljutni valami hasznalhatoig. Rengeteg pelda van erre, de a lenyeg az, hogy ha van egy jo alapod, onnan mar evolucios lepesekkel konnyebb haladni.
"Alapvetően kevesebb ideje fejlesztik, mint amennyi ideje a MIC kalapács alatt van."
Nem kevesebb ideje, hanem kb. ugyanannyi ideje. Es az OpenCL "csupan" egy szoftveres layer, amihez megvolt a stabil hardveres alap (Tesla/G80, VLIW5 by ATI) mar a legelejen is; mig az Intelnek a hardver a legnagyobb nyomora, azt nem tudjak osszerakni 6 eve. Alapvetoen teljesen mas a problema. Ha lenne egy tenyleg jol mukodo x86 alapu GPGPU hardvere az Intelnek, a compilerrel sokkal konnyebben megbirkoznanak _szerintem_, nem az lenne a fejlodes akadalya, mint most az OpenCL 1.x GPU-knal, gyartotol fuggetlenul.
"Pedig, ha még esetleges hibákkal is, de működik."
Marmint melyik?
Nagyjabol egyik sem. Ha az OpenCL olyan jol mukodne az "esetleges" hibakkal egyutt, akkor sokkal jobban elterjedt volna 6 ev alatt. 6 ev rohadt hosszu ido, kb. ugyanennyi ideje volt az Androidnak is nullarol elterjedni, megis teljesen mas utat jart be, mint a MIC vagy az OpenCL."Milyen szinten kellene megnyilvánulnia, hogy az egész világ az Intel ellen van?"
Ki kellene mindenkinek hatralnia az x86-bol. Az AMD-nek, a VIA-nak (bar ok nem sok vizet zavarnak most sem, sajnos), es foleg a Microsoftnak. Ha az MS azt mondaná, hogy nincs tobb x86 Windows, mindjart mas lenne a helyzet. Ez persze utopisztikus, hiszen a Microsoft sem hulye es az AMD sem hulye, hogy elhagyja az x86-ot. Addig azonban, amig a cegek fuggenek a Windows+x86 kombotol; meg amig az emberek x86 PC-ket (asztali, mobil, ultramobil) es x86 szervereket folyamatosan tiz/szazmillios nagysagrendben vasarolnak, nem lehet azt mondani, hogy az Intel ellen van a vilag, sajnos. Nagyon is kenyelmes helyzetben vannak mind a mai napig, egyedul az ultramobil vonalon van felzarkoznivalojuk, a mikroszerver szegmensben pedig ki kell epiteniuk a hidfoallasukat, a tobbi szegmensben siman elvannak erolkodes nelkul is.
"ellenben a MIC nem lehet átütő és piacátformáló siker, amíg ezek léteznek és van esélyük használatba kerülni"
Kiveve, ha a MIC architekturas CPU/GPU/akarmivel is hozhato OpenCL-ben vagy C++AMP-ban ugyanaz a teljesitmeny, ami AMD vagy nVIDIA GPU-val. Ez majd elvalik, egyelore nyilvan sehol sincs az Intel a mostani Gen7 megoldasokkal.
"Márpedig, ha a HSA-t kivesszük a képletből, akkor az említett megoldások mögött áll többek közt az Apple/Google/Microsoft."
Az Apple? Maximum a desktopon, de nem az ultramobil eszkozokon. Vagy csak lemaradtam valamirol, es az OpenCL iOS-en is szalad?
Legutoljara amikor neztem, me'g csak OSX-re volt OpenCL implementacioja az Apple-nek.A Google pedig me'g veletlenul sem tamogatja a felsorolt technologiakat, kulonosen nem tamogatja az OpenCL-t es a C++AMP-ot. Az OpenCL-t eddig igyekezett minden erovel kiszoritani az Androidrol, kerdes, hogy ez meg fog-e valtozni a HSA-val, megbekel-e vele a Google, vagy lemasoljak benabb kiadasban (a la RenderScript vs. OpenCL), es azt tolják inkabb a HSA helyett.
A Microsoft pedig szinten nem orul az OpenCL-nek meg a HSA-nak, ok inkabb a C++AMP-ot tolnák. De legalabb nem tesznek keresztbe ezeknek az API-knak. Viszont, siman lehet, hogy a DirectX12-vel ok is kihoznak valami HSA-szeru megoldast, amit tamogathat az Intel es az nVIDIA is.
[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
A Google az OpenCL-től elsősorban a fragmentáció miatt zárkózik el, de másodsorban az is fontos, hogy a Renderscript ellenfele. A HSA azért érdekli őket, mert nem jelent fragmentációt, legalábbis jelenleg az androidos gyártók piaci részesedését figyelembe véve csupán 4%-os gyártói részesedés van ahol a legacy kódra lenne kötelezve a rendszer, akkor is ha jönnek az új chipek. Emellett a HSA nem a Renderscript ellenfele, hanem kiegészítése. A Renderscriptből pont azt hiányolják a fejlesztők, ami a HSA-ban benne van. A Google-nek a HSA pont azt nyújtja amire szükségük van és a gyártópartnerek igen jelentős többségét semmilyen hátrány nem éri. Csinálhatnak egy saját platformot, de a HSA-nál nyíltabb nem lesz. Ráadásul akik nem akarnak piaci versenyt azt sem fogják támogatni.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Egyelőre senki sem mondta, hogy nem tagja. Az Oracle 2012 nyara óta tag mégis 2013 végén rakták ki a logójukat az alapítványi oldalra. Nem kötelező azelőtt elárulni a tagságot, mielőtt be nem jelentené az adott cég az okát. Az Oracle például várt a Java 9 hivatalos első bejelentéséig, amikor elmondhatták, hogy mi közül lesz a HSA-hoz.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
leviske
veterán
"Ha mar van egy sikeres, stabil alap, arra mar konnyebb epitkezni, mint nullarol indulva eloszor rossz iranyba indulni, majd korrekciokkal eljutni valami hasznalhatoig."
Ezt elfogadom, de az eddigi beszélgetésetek alapján nekem az jött át, hogy a rossz irány itt gyakorlatilag maga az X86 alap és az ehhez való ragaszkodásból kéne feladni. DE ennek az esélylatolgatásába nem akarok belemenni. Ugyanannyira nem lenne jó senkinek, ha az Intel sodródna ki egy időre a MIC-el, mintha az AMD bandája a HSA-val, vagy az nVidia a CUDA(?)-val.
"Kiveve, ha a MIC architekturas CPU/GPU/akarmivel is hozhato OpenCL-ben vagy C++AMP-ban ugyanaz a teljesitmeny, ami AMD vagy nVIDIA GPU-val."
Ez nem "kivéve", hanem ezt jeleztem egyik lehetőségként és ezt érezném optimálisnak. Ha mindenki a saját útján el tudná érni ugyanazt a hatékonyságot. Éppen ennek a lehetőségnek a fényében tartanám hülyeségnek azt, hogy az AMD és az nVidia hagyjon ott csapot-papot és másolja le az Intel elképzelését, mikor van rá esély, hogy mindenki a saját jól megtervezett útján be tud futni ugyanabba a célba.
"Ki kellene mindenkinek hatralnia az x86-bol. Az AMD-nek, a VIA-nak (bar ok nem sok vizet zavarnak most sem, sajnos), es foleg a Microsoftnak."
Mindketten tudjuk, hogy ez nem az Intel iránt érzett szeretetet, vagy épp a X86 iránti elkötelezettséget jelzi, hanem azt, hogy senki nem akarja dobni a legacy támogatást. Ez még nem jelenti azt, hogy nem gondolkodhat minden cég sokkal diverzebb jövőképben.
Hülye példa: A HP ugye gyakorlatilag egy viszonteladó, akinek az Intel/AMD-vel ellentétben közvetlen ügyfelei vannak.
Az Intel jövőképében, ha a HP-hez fordul az egyik komolyabb ügyfele azzal, hogy "Hé, Te ott, rég fejlődtek a termékeid X-ben, nekem viszont arra volna szükségem még abban az esetben is, ha Y és Z kárára is megy.", akkor a HP legfeljebb annyit tud tenni, hogy végigböngészi az Intel termékkínálatát és reménykedik, hogy ennek megfelelő terméket még abban az esetben is talál, ha az Intel éppen Y-ra koncentrál és tojik az X fejlesztésére.
Ez az a jövőkép, amihez Te is ragaszkodsz attól való félelmedben, hogy a gyártók nem lesznek képesek felnőni a HSA kiszolgálásához.Ezzel szemben az AMD jövőképében, ha a HP-hez fordul ez az ügyfél ugyanezzel a problémával, akkor a HP vagy ráállítja a tervezőcsapatát és jó pénzért terveznek az ügyfélnek egy egyedi lapkát, vagy kiadja a munkát a Samsung-nak, Qualcomm-nak, esetleg épp az AMD-nek.
"ugyanennyi ideje volt az Androidnak is nullarol elterjedni, megis teljesen mas utat jart be, mint a MIC vagy az OpenCL."
A nagy különbség, hogy az Android terjedséhez minden környezeti tényező adott volt. Az OpenCL meg értelmezésem szerint a Kaveri érkezésével érte el azt a szinten, hogy legyen értelme róla beszélni és erre az Intel csak rá fog erősíteni hamarosan.
"Az Apple? Maximum a desktopon, de nem az ultramobil eszkozokon."
Hogy téged idézzelek: "Just wait & see." Ha jól rémlik, anno az Apple és az nVidia pont az OpenCL miatt rúgta össze a port és miután a Microsoft is viszi mindenhova a C++AMP-t nem lepne meg, ha majd az iOSX is csendben meghozná, vagy akár még korábban megérkezne az OCL iPhone/iPad/iPod-ra.
"Viszont, siman lehet, hogy a DirectX12-vel ok is kihoznak valami HSA-szeru megoldast, amit tamogathat az Intel es az nVIDIA is."
És ezzel kinek ártanának? Senkinek. A Mantle esetéhez hasonlóan kijelöltek egy irányt. Ha erre a Khronos és a Microsoft jól lecsap és kiad egy saját kiegészítést, azzal a HSA tagoknak nem esnek kútba a fejlesztései, stb.
Bár egyébként azért nem látom sok esélyét a dolognak, mert a Khronos számára szvsz bőven jó a HSA is, a Microsoft meg nem fedi már le olyan százszázalékosan az nVidia és Intel jövőképét, mint régen."a la RenderScript vs. OpenCL"
Basszus, minimum 3x írtam le a RaspberryPI-t
, miért nem javítottatok ki, hogy egy másik "R" betűs lesz, amit keresek? Most megyek elszégyellni magam. -
Abu85
HÁZIGAZDA
válasz
leviske
#14230
üzenetére
Teljesen mindegy, hogy milyen HSA alternatívák készülnek. Az Intelnek és az NV-nek nem ezzel van baja, mert a HSA-nál nyíltabb dolog sosem születhet meg. Azzal van a gond, hogy az ilyen koncepció minden kínai dzsunkacéget beenged a piacra. A PC gyakorlatilag háromszereplős. Egy HSA-val vagy egy ugyanilyen koncepcióval csak más néven pillanatok alatt jöhet még tíz szereplő, aztán nem sokkal később még tíz.
A Microsoft sem egy olyan aranyos cég már. Az utóbbi időben csupa rossz dolgot csináltak az Intelnek és az NV-nek, amihez pusztán a politikai látszat matt széles mosolyt kellett vágniuk. A DirectX 12-vel az MS kiszállt gyártói harcból, mostantól leszarják, ha az Intel és az NV nem tud valamit támogatni.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#14232
Vitamincsiga
tag
dezz
#14212
Vitamincsiga
tag
Ez igen! [link] Köszi a cikk nevet
Végleg kezd kilépni a benchmark világ a PC bűvköréből - a Sandra eddig is mért minden paramétert, de úgy látszik nem csak CPU -> APU váltást hajtotta végre, hanem kinézett az x86 világból is.
Sandráék tesztjéből az már kiviláglik, hogy nagyságrendbeli különbség nincs az ARM és az Intel között CPU teljesítményben, viszont fogyasztás és a GPU teljesítmény terén már más más a helyzet. De vajon hogy szerepelne az AMD Puma+ architektúrája a tesztekben? Kihegyezve a HSA-ra!A Kaverire és a HSA tesztre visszatérve egy leheletnyit.
Ahogy elkezdenek majd terjedni a CPU és az IGP közös memóriatartományát kihasználó prg-ok, lehet, hogy nem az AMD lesz az, aki gyászosan lemarad a tesztekben?Jó lenne egy varázsgömb ;-)
-
Vitamincsiga
tag
válasz
lezso6
#14183
üzenetére
Kellett kicsit rágódni a felvetéseden!
Kell ilyenfajta fejlesztés is mindenképpen! A kompatibilitáshoz mindig csak addig ragaszkodnak, ameddig a fejlődés üteme vagy töretlen, vagy szinte zéró és szükség sincs rá.
A CPU-ra a második felvetés jó ideig - ami a szükséget érinti - nem lesz igaz. Szeretnék egy olcsó, 8K-s, +200"-os monitoron, 16-bit csatornánkénti színmélység mellett, 120Hz-en a kedvenc játékom valamelyik jövőbeni részét játszani! De ki nem?
Az első viszont megint válságban van.
A magasabb IPC és a hosszabb futószalag volt az egyik irányzat. P4 volt a másodiknál a megálló, illetve az AVX512 se tetszik mindenkinek.
A 10 GHz bukása volt a másik törés a fejlődésben. Ha egy mag kevés legyen több! De ez is olyan mint a macska: 2 felett tömeg; kezelhetetlen.
De volt aki máshogy gondolta, mert hitt benne, hogy az gyorsabb lesz. A GPU felemelkedése és integrációja a CPU-ba ez a folyamat, ami jelenleg is tart.És itt jön képbe a HSA virtuális ISA-ja! Még ha szoftveresen is, de nagyon hatékony választ ad a fokozódó teljesítményigényre. Hogy HW-be is meg merné-e lépni valaki? Ha kevés más út lesz és ebből is lehet többletteljesítményt nyerni, akkor biztos lesz, aki ezt is megpróbálja!
Amit a többen is felvetettek, az a gyártástechnológia finomítása. Az AMD a Beema és a Mullins fejlesztésébe szinte mindent beleadott. Ahogy egy korai teszt írja: "nincs benne hiba". Gondolom a Carrizo sem lesz rosszabb!
De, lehet, hogy a fentiekből semmi sem lesz!!
Valaki rájön, hogyan lehet a grafént "félvezetésre bírni"
Vagy a szilicén is könnyebben gyárthatóvá válik
Vagy az optikai áramköröknél történik valami használható fejlesztés
QSZG
De egy tény, a fenti hibákat akkor is el fogják megint követni újra
[ Szerkesztve ]
Jó lenne egy varázsgömb ;-)
-
#14234
Fiery
veterán
Vitamincsiga
#14232
Fiery
veterán
válasz
Vitamincsiga
#14232
üzenetére
"Ahogy elkezdenek majd terjedni a CPU és az IGP közös memóriatartományát kihasználó prg-ok, lehet, hogy nem az AMD lesz az, aki gyászosan lemarad a tesztekben?"
Ez konnyen elofordulhat, viszont az az ido me'g mindig nem jott el, me'g mindig nincsenek ilyen szoftverek. Majd jovo ilyenkor mar talan jobb lesz a helyzet, 2 ev mulva meg kulonosen. Az ido azonban eroteljesen az AMD ellen dolgozik, ugyanis jelen allas szerint az Intelnek sokkal tobb lehetosege van az iGPU teljesitmenyenek fokozasara, mint az AMD-nek. Ergo, cca. 1-2 ev alatt siman lehet, hogy nyers teljesitmenyben kozel kerulnek a legdurvabb Intel iGPU-k a Carrizo iGPU-jahoz, onnantol pedig mar csupan az donti el a kerdest, hogy a szoftverek melyik platformot favorizaljak, esetleg melyikre irjak oket exkluzivan.
-
lee56
őstag
Igen AMD technológiai úttörő szerepe sajnos nagyon kevésszer volt kifizetődő, valamit nagyon nem jól csinálnak szegények. Az ember azt hinné azért egy cég is képes tanulni a hibáiból, hisz nem először történik ilyen velük.
És pont ez a kritikus köztes időszak amit élünk jelenleg, hogy még nagyon gyerekcipőben az APU korszak, de már felhagytak a hagyományos CPU-k piacra dobásával, ami csak tovább nehezíti a helyzetüket..
No Comment
-
atti_2010
nagyúr
Hiba? ha az innovációt választják a "Intel pasztás profit " helyett, nem hiszem, és ezért szeretjük páran az AMD-t.
1.Asrock FM2A88X+ Killer,A10-5800K,Kingston 2x4Gb 2400Mhz,Int X25-V SSD,SF Pro S.F.-450P14XE. 2.MSI-A75A-G55,A8-3870, Kingston 2x2GB2000, MSI R9-270, Zen 400.
-
stratova
veterán
Brazos/Llano óta téma ez az integráció és ennek ellenére eddig többnyire grafikára használtuk az IGP-t. Miközben kihoztak 7 APU-t, PC-n a kompakt gépek mellett nem sok babér termett nekik. Eközben viszont bezsebeltek 2 konzolgyártót, akik legalább 5 évre biztosítanak bevételt.
-
dezz
nagyúr
válasz
#17954112
#14239
üzenetére
Meg lehetett volna csinálni, csak valószínűleg nem érte volna meg a ráfordítást, mert CPU erőben így sem lett volna igazán versenyképes, így csak kevesen vették volna meg. Arról se feledkezzünk meg, hogy a CPU rész többet fogyaszt, mint az IGP rész.
(Amúgy még az sem teljesen kizárt, hogy meg is csinálták, kísérleti példányok formájában, és a tesztek során arra jutottak, hogy a 2 modul + 512 SP (8 CU) felállás a legszerencsésebb.)
-
leviske
veterán
válasz
#17954112
#14239
üzenetére
A Steamroller nagy baja, hogy egyszálú teljesítményben nagyon elmarad a Haswell-től. A Kaveri X86 teljesítményén az segített volna, ha gyakorlatilag dobják az egész Bulldozer felépítést. Bulk-ra szvsz már elő kellett volna jönni egy olyan architektúrával, ami közelebb áll c2c az Intelekhez. Bár fene tudja, lehet, hogy az Excavator már ezen a téren jócskán előrelépést jelent majd.
(#14231) Abu85: Mondjuk ez a hozzáállás az nVidia részéről hülyeségnek tűnik, hiszen aktuálisan ők sem szereplői a piacnak, hosszú távon meg úgy is valószínűleg "csak" két valós belépővel kéne számolni az nV-n túl.
(#14234) Fiery: "az Intelnek sokkal tobb lehetosege van az iGPU teljesitmenyenek fokozasara, mint az AMD-nek"
Ezt nem biztos hogy értem. Itt most arról van szó, hogy a GCN egy zsákutca, vagy arról, hogy az Intel még nem találta meg az útját és ezért még végtelen sok lehetősége van?
Mindenesetre az idő nem csak egy cégnek dolgozik. Az AMD komoly pénzeket öl abba, hogy a marketing szempontból fontos réteget (gamer) meggyőzze. Ehhez egyelőre ott áll mögötte egy EA, egy SquareEnix és vélhetőleg egy Activision-Blizzard a nagy kiadók közül. Ehhez jön még hozzá, hogy a két konzol multiplatform címei is kedvezhetnek akár az AMD rendszereknek. A Mantle/DX12 csapásirányán pedig már elkezdhet kialakulni egy OpenCL környezet.
Két év alatt pedig az AMD is összerakhat egy olyan, kiegyensúlyozottabb architektúrát, ami már nem csak a közvetlen partnerek számára meggyőző.Biztosra veszem, hogy az Intel oda fogja tenni magát OpenCL-ben, akár IGP akár MIC (gondolom az idézett mondat erre utal valójában) felől közelítik a témát, hiszen mobil piacon nekik is szükségük lesz rá gondolom. De abban azért nem vagyok biztos, hogy az AMD addig egy helyben fog állni, hiszen optimális esetben 2 év múlva már a 3. HSA képes APU-nál fogunk járni.
[ Szerkesztve ]
-
lee56
őstag
Párszor azért ők maguk voltak a chipgyártók is, vagy a TSMC, és nem mindíg ez volt a gond..
Pl. gondolok itt a HD2000es GPU széria alapjára; az R600 is hasonlóan nehéz utat járt be, ha jól emlékezek.(#14237) atti_2010 : Nem, a hiba az amit Fiery is írt, hogy mire beérne a jövőbemutató fejlesztés, addigra behozzák sőt, le is előzik a versenytársak általában.
Amúgy nekem is tetszik amit csinálnak, csak míg pl az Intelnek simán belefér néhány üzletileg katasztrófa döntés is, náluk már inkább meg kéne gondolni mire költenek és fejlesztenek.(#14238) stratova : Na igen, az a baj ezzel az egésszel, hogy szoftveresen már tegnapra kellett volna... De csak tegyük fel, hogy a programok 50%-a képes lesz ez év végére kiaknázni az iGPU-k általános számítási teljesítményét (azt hiszem ez is még túl optimista becslés volt), azzal hogy valaki most egy AMD APU-t vesz, még mindíg jókora kompromisszumra kényszerül (X86 teljesítményt áldoz be ugye a jóformán kihasználatlan iGPU-jával, ami a chip több mint felét alkotja, és akinek dGPU-ja van, annál a chip azon része így csak pihen jelenleg, de persze ki kell fizetni azt is a kasszánál). És amég nem lesz jobban elterjedve, és szoftverileg sem készülnek fel jobban.. Na szóval látni a fényt az alagút végén, de baromi halvány még mindíg, az én szememben legalábbis.
A két uj konzol azért valamennyire enyhítheti az AMD kínjait, de azért ez sem fog örökké tartani.. Remélem azért hamarosan kitalálnak valami megvalósítható, eladható, és főleg versenyképes innovációt, mert azért tudnak ők ilyet is.
No Comment
-
AMD-nek szerintem ez szerverben az igazi szopás. Legalábbis az én szemszögemből haszontalan egy APU egy általános web vagy adatbázis-szerverbe. Elviekben tök jó lenne mindkettőre, főleg web, mert ott tényleg rengeteg szál fut (minden letöltéshez egy) aszinkron egyszerre. Adatbázis terén szintén jó lenne, bár itt nagyon fontos lenne a párhuzamosan több aszinkron kérés a webről (már ha nem kell egy tranzakcióban lenniük), amivel messze jobb kihasználtságot el lehetne vele érni az adatbázis-szerveren, mert jelenleg a legtöbb helyen egyszerre csak egy szinkron kérést küld a web az adatbázisnak, ami a válaszidőt hazavágja.
Közbe egy gyors gúglizással találtam egy érdekességet: PGStrom
Itt egyértelműen látható, hogy egy közös címterű APU lenne az igazi, a dGPU-t nagyon korlátozza a PCIE.
De ha ezek elterjednének, portolnának mindent APU-ra, akkor már rég nem sírnék. Egy dGPU szvsz már azért bukó, mert relatív nagyon kevés memóriája van, ami nem is bővíthető.
[ Szerkesztve ]
A RIOS rendkívül felhasználóbarát, csak megválogatja a barátait.
-
#14244
Vitamincsiga
tag
dezz
#14240
Vitamincsiga
tag
"(Amúgy még az sem teljesen kizárt, hogy meg is csinálták, kísérleti példányok formájában, és a tesztek során arra jutottak, hogy a 2 modul + 512 SP (8 CU) felállás a legszerencsésebb.)"
Ha hozzászámítjuk a DDR3-2400-ból fakadó 38,4 GB/s-os maximális memóriaelérést, akkor elképzelhető, hogy a 2 modul + 8 CU nem csak az arányra, de a mértékre is optimális.
Ebben az esetben a DDR4-3200 - bár csak itt tartanánk már
- memória használatánál a 4 modul + 16 CU bevállalható lenne. Természetesen 20 nm-es gyártástechnológia mellett.(#14234) Fiery:
"Az ido azonban eroteljesen az AMD ellen dolgozik, ugyanis jelen allas szerint az Intelnek sokkal tobb lehetosege van az iGPU teljesitmenyenek fokozasara, mint az AMD-nek."
Az AMD örök baja a gyártás
Van jó cuccuk, de senki sem akarja belerakni notiba, táblába... A konzol piac megszerzése még ma is az az érzetet kelti, hogy biztos így történt, Nem elírás?
Zsé', pedig az eladásokból van. Abból meg a fejlesztés, ahol az Intel nagyságrenddel nagyobb lehetőségekkel bír.Hogy a GCN-ből továbblépni tényleg nehezebb - mert nagyon is jó - mint az Intel IGP-jéből az tény. De az is, hogy egy GCN-t összerakni sem egy-két év; melózik az Intel rendesen, hogy behozza a lemaradást.
(#14241) leviske:
Az igazi durranásra szerintem várnunk kell még.
Mindannyiótoknak igaza van, hogy az AMD a HSA-ja felkészületlenül érte a programozókat. A Win9 megjelenése utáni 2 év lesz, mire a HSA szignifikánsan lesz jelen a mindennapokban.
Addigra az Intel addigra gatyába rázza a MIC-et, az ARM-osok pedig élvezni fogják MS-t. És csak a teljesítmény - ahogy öregapám mondogatta: "a lóerő per dioptria" - számít egyedül.Az AMD a legérdekesebb mindezek közül!!
A GCN2(?) mellé mind az ARM - mobilteló, tábla, SeaMicro-, mind az x86 - noti, asztali, HPC, régimódi szerver - integrálásra kerül. /A tokozás más tészta, de majd kiderül!/
Zseniális!
Egy lépésben, 2 architektúrával lefedik az egész TDP tartományt
A GCN ezt eddig is tudta - ABU erről írt többször is - most pedig a "megoldhatatlan CPU részét" is megoldották.
2015-re már "kész" minden - Carizzo, Beema, Mulins - cucc, a fenti fejlesztés a 2016-2017(?) tartományt fedheti le.Ezek után még inkább úgy gondolom, hogy a GCN2(?) valószínűleg az utolsó IGP lesz. A CU-k integrálódni fognak a főnixként feltámadó modulba. Extra hatékony!
Hogy miért nem most?
Se gyártástechnológia, és valószínűleg se működőképes prototípus. Ráadásul most már nemcsak x86-ról szól a modul, hanem az ARM-ról is. Úgy pedig nem akarnak járni még egyszer, ahogy a Liano és a Bulldozer bevezetésekor volt
Ezek az évek egy kicsit hasonlítanak a (h)öskorszakra
286 386 486...
Megint sokszereplős a piac, megint nem tudjuk ki, mivel fog előrukkolni, de a teljesítményvágy, az örökJó lenne egy varázsgömb ;-)
-
Vitamincsiga
tag
válasz
leviske
#14241
üzenetére
"A Steamroller nagy baja, hogy egyszálú teljesítményben nagyon elmarad a Haswell-től. A Kaveri X86 teljesítményén az segített volna, ha gyakorlatilag dobják az egész Bulldozer felépítést. Bulk-ra szvsz már elő kellett volna jönni egy olyan architektúrával, ami közelebb áll c2c az Intelekhez. Bár fene tudja, lehet, hogy az Excavator már ezen a téren jócskán előrelépést jelent majd."
Tavaly is azt hittük a Kaverivel kapcsolatban, amikor felkerült a netre AZ A KÉP
Ahogy most kinéz, a Carrizo is csak 28 nm-en jön ki így extra teljesítménynövekedésre kevés az esély - remélem TÉVEDEK!!Viszont a "fúzió" a végére ér és az a funkcionalitás, amit megálmodtak pár éve mind belekerül
A HSA-t kihasználó programok nagyon is versenyképesek a Kaverivel is, az utód csak jobb lehet![ Szerkesztve ]
Jó lenne egy varázsgömb ;-)
-
Fiery
veterán
válasz
leviske
#14241
üzenetére
"Itt most arról van szó, hogy a GCN egy zsákutca, vagy arról, hogy az Intel még nem találta meg az útját és ezért még végtelen sok lehetősége van?"
Arra gondolok, hogy a fejlett(ebb) gyartastechnologia (foleg a 14 es majd a 10 nano, ha majd elkeszulnek egyszer) lehetoseget ad az Intelnek arra, hogy olyan trukkoket vessen be (pl. eDRAM), amivel ugymond erobol (brute force) nyomja le az AMD-fele APU-kat. Mint anno a NetBurst: nem okos architektura volt, hanem nagyon magas orajelre skalazhato. Az orajellel potoltak az architekturabol kimaradt "ravaszsagokat". Most meg majd nyers magszammal (shader) meg eDRAM-mal ellenpontozzak a GCN zsenialitasat.
A GCN egyaltalan nem zsakutca, csak epp nem latszik jelenleg az, hogy az egyre csokkeno TDP keretbe hogyan fog tudni az AMD me'g nagyobb nyers iGPU teljesitmenyt beszuszakolni, kulonosen ha maradnak me'g 1-2 evig a mostani gyartastechnologianal. Plane ugy, hogy a mobil vonalon me'g az FCH-t is integralnia kell, az is beleszamit a TDP-be -- mig jelenleg azt kulon szamitjuk. Mar a Kaverinal is problemat okoz(ott) a TDP es/vagy a kiforratlan gyartastechnologia, eleg csak megnezni az orajeleket (vs. Trinity orajelek).
"A Mantle/DX12 csapásirányán pedig már elkezdhet kialakulni egy OpenCL környezet."
No offense, de mi a frasz koze van a Mantle-nek es a DX12-nek az OpenCL-hez?
"Két év alatt pedig az AMD is összerakhat egy olyan, kiegyensúlyozottabb architektúrát, ami már nem csak a közvetlen partnerek számára meggyőző."
Igy legyen! 2 ev mindenkepp kell ehhez, addig ugyanis eleg fixnek latszik az AMD utiterve: jovo ilyenkor jon a Carrizo, utana meg nem valoszinu, hogy egy-masfel even belul erkezne az uj mag (Family 20h).
"optimális esetben 2 év múlva már a 3. HSA képes APU-nál fogunk járni."
Teljesen mindegy, hogy hanyadik generacional jar. Nem az a baj (mostanra mar), hogy nincs vas a HSA-hoz, hanem az a baj, hogy annak a vasnak (Kaveri) a PC-piaci penetracioja borzalmasan alacsony. Plusz, a HSA nincs kesz, ergo a fejlesztok amugy sem tudnak rendesen dolgozni vele. Majd ha lesz tobbfele hardver, azokbol eladnak par tizmilliot, es a HSA is stabil allapotba kerul, akkor elindulhat a szoftverek gyartasa. Ha az aztan general egy lavinat, akkor menni fog a HSA, es az AMD APU-jai is sikeresek lesznek, de ez akkor sem azon fog mulni, hanyadik generacional tart az AMD.
-
#14247
Fiery
veterán
Vitamincsiga
#14244
Fiery
veterán
válasz
Vitamincsiga
#14244
üzenetére
"A Win9 megjelenése utáni 2 év lesz, mire a HSA szignifikánsan lesz jelen a mindennapokban."
A Win9-nek az egvilagon semmi koze a HSA-hoz vagy a HSA elterjedesehez. A HSA akkor terjed el, ha elkeszul vegre, es lesz elegendo hardver a piacon ahhoz, hogy megerje mokolni vele a fejlesztoknek. Egy 1-2 %-os piaci reszesedesu procira minek fejlesztene barki is, akit nem az AMD tol?
-
#14248
Fiery
veterán
Vitamincsiga
#14245
Fiery
veterán
válasz
Vitamincsiga
#14245
üzenetére
"Ahogy most kinéz, a Carrizo is csak 28 nm-en jön ki így extra teljesítménynövekedésre kevés az esély - remélem TÉVEDEK!!"
A Carrizo lenyegesen alacsonyabb TDP-vel fog elvileg rendelkezni, mint a Kaveri, ergo ha azonos gyartastechnologian keszulnek, akkor kicsi az esely arra, hogy a Carrizo gyorsabb legyen, mint a Kaveri. Lesz persze AVX2 tamogatas a Carrizoban, de Abutol tudjuk, hogy szinte egyetlen szoftver sem kepes az AVX2 kihasznalasara, tehat az sem fog segiteni a Carrizon
"A HSA-t kihasználó programok nagyon is versenyképesek a Kaverivel is, az utód csak jobb lehet!"
Csak epp nem azon mulik, hogy a Kaveri hova fejlodik, hanem azon, hogy egyaltalan lesznek-e HSA-t kihasznalo programok tomegevel. A Kaveri mar most is egy tokeletes fejlesztesi platform ahhoz, ha valaki HSA-ra akarja a meglevo szoftveret optimalizalni. Programozoi szemszogbol a Kaveri teljesen jo vas, csak kellene hozza a szoftver. Kb. mint anno a 3DNow!, ami teljesen jo otlet volt, csak sajnos keves szoftver (jatek) aknazta ki, es vegul az SSE elmosta sajnos
[ Szerkesztve ]
-
dezz
nagyúr
A néhány nappal ezelőtti hírek szerint a Carrizóból lesz FX jelölésű, csodálkoznék, ha az nem 95W-os lenne.
Nem tudom, mi mása van a GloFo-nak vagy a TSMC-nek, illetve mit licencelt nemrég az első, de a 28nm-t sem venném készpénznek, legalábbis sima bulk. Hogy tudnának ennyit javítani a teljesítményen és telj./fogy. arányon ugyanazon a node-on, hogy nem hogy jobb, de legalább azonos szinten legyen a Kaverivel?
-
Fiery
veterán
A GloFo tudtommal a Samsunggal allt ossze, hogy kozosen fejlesszek ki a 14 nanos node-ot. Kerdes, hogy addig mi lesz, es mikorra keszul az el. De akarhogy is lesz, en kizartnak tartom, hogy 20 nano alatti node-on keszuljon a Carrizo. Jo lenne, ha ugy lenne, de nem hiszem, hogy megtortenik
/Fáradozásodat előre is köszönjük!!/
/Bár nem HSA, de azért mér valamit.../
A KNL-et es a Skylake-et sikernek vagy bukasnak beallitani elore, csak mert -- velhetoen -- MIC alapuak lesznek kb. olyan lenne, mint ha az AMD Family 20h-t allitanank be ugyanigy elore sikernek vagy bukasnak.
Egy olyan piacon, ahol a gyártók maguk faragják a hardvert, az Intelnek és az AMD-nek konkrét saját termékekkel szerintem sosem lesz esélye labdába rúgni. Még az nVidia is kapott egy szép pofonsorozatot attól a piactól, pedig ők még csak eltérni sem akartak az ARM-től.
Plusz, a fizikaval mar probalkoztak nehanyan, pl. PhysX annak idejen, es nem igazan latom azt, hogy valaki a fizikai szimulacio miatt valasztana egy adott hardvert. Mikor hallottal utoljara olyan juzerrol, hogy vasarolt volna a gepebe plusz egy GeForce videokartyat, hogy a fizikai szamitasokat arra bizza? De egyebkent nem csodalkozok, ha a fizika felol probalkozik az AMD, ugyanis az AMD HSA fejlesztoi csapataban tobb volt Ageia-s (es igy volt nVIDIA-s) is van, tobbek kozt az egyik Ageia alapito is.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Ú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.
