- Vezeték nélküli fülhallgatók
- HiFi műszaki szemmel - sztereó hangrendszerek
- Fujifilm X
- AMD Radeon™ RX 470 / 480 és RX 570 / 580 / 590
- Milyen notebookot vegyek?
- NVIDIA GeForce RTX 4060 / 4070 S/Ti/TiS (AD104/103)
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Házi barkács, gányolás, tákolás, megdöbbentő gépek!
- Apple notebookok
- Vezetékes FÜLhallgatók
Hirdetés
-
Rossz üzlet az EV-kölcsönzés
it Küszködik az EV-kölcsönzés miatt a Hertz Global, még több EV-t adnak el.
-
Érkezőben a Poco M6 4G
ma 5G-s és 4G-s Pro modell már van, hamarosan lesz Poco M6 4G-s alapváltozat is.
-
Ülésezik a hardveregylet
ph Az irodai készülékek és monitorok társaságát egy ház, egy egér és egy DAC egészíti ki.
-
PROHARDVER!
OLVASD VÉGIG ALAPOSAN MIELŐTT ÚJ HOZZÁSZÓLÁST ÍRNÁL!!!
Új hozzászólás Aktív témák
-
Thrawn
félisten
Hát pont ez, hogy tök jó lenne egy GDDR5-ös pici lap Kaverivel, ha már a PC ipar is a mobil trend felé tolódik, de nem találtak gyártót, aki csinált volna valami ilyesmit belőle: [link]
szerk: Kabinis lesz belőle mondjuk [link][ Szerkesztve ]
Different songs for different moods. łłł DIII Thrawn#2856 łłł Look! More hidden footprints! łłł D4BAD łłł WoT: s_thrawn łłł
-
Abu85
HÁZIGAZDA
A PC-s gyártókban az a legjobb, hogy mindent jobban tudnak. Vannak nagyon érdekes sztorik az ODM notigyártókon keresztül. Több gaming szinten érdekelt cég letámadta idén a PC-s kiadókat, mert látták, hogy a jövőben rengeteg szegmentált technológia lesz, és hogy ezekre mindre nem lehet külön-külön termékeket építeni. Kvázi mindenki full szabványt követel. A kiadók persze tojnak a fejükre.
Viszont most mindenki be van tojva, hogy mégis melyik gyártó exkluzív funkciói kedvezőbbek a PC-s játékosoknak. A gondot tetézi, hogy az AMD, az Intel és az NV is tucatnyi játékkal készül ezekre a szolgáltatásokra.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Van egy olyan érzésem, hogy a gyártók egy része 2014-et csúnyán be fogja szívni.
Az Intel arra kéri őket, hogy építsenek gépeket a casual gamingre, vagyis a Windowsba implementált Androidhoz. Eközben az OpenGL ES 2.0-s alkalmazások jó része nem támogatja az Intel IGP-k pufferformátumát (sőt, egyik PC-s megoldásét sem). A Dual OS törekvésben rögtön tökön szúrják magukat.
Az AMD arra kéri őket, hogy építsenek gépet a Mantle és TrueAudio gamingre. Mert nekik már felsoroltak 30+ játékot, amelyek támogatják egyiket vagy mindkettőt és ezek fele idén megjelenik. Cserébe elesnek az Intel marketingtámogatásától.
Az NV meg arra kéri őket, hogy építsenek vaskos gaming notikat PhysX-re, mert hoznák játékokat. De itt meg nem lesz Mantle és TrueAudio.
Ja és mindhárom nem fér bele.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
-
-
leviske
veterán
Köszi! Így már valamennyivel tisztább a kép.
Még annyit kérdeznék, hogy a AVX-512 használata mellett elméletben lenne akkora teljesítményugrás, ami kárpótol azért, hogy sokkal több munkát igényel? Csak mert, ha eddig jól értelmeztem, akkor az AVX-512 használatával gyakorlatilag konkrét hardverekhez/architektúrákhoz(?) kell megírni a kódot.
-
leviske
veterán
-
-
Abu85
HÁZIGAZDA
A die méretét nem igazán határozza már meg az alkalmazott gyártástechnológia. Elsődlegesen a "Thin Library" képességeitől függ, hogy mekkora helyre mennyi tranyó préselhető be. Ha most átportolnák a Tahitit az Intel 14 nm-es node-jára, akkor az nem lenne kisebb, mint most 28 nm-es TSMC-n HDL-lel. Ergó előbb a HDL-t kell portolni.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
leviske
veterán
Önmagában 1 Vishera és 1 Tahiti még kb az a mérettartomány lenne, mint egy nem tudom hanyadik generációs Larrabee. De egyébként én is arról írtam a kollégának, hogy nem lenne egy logikus lépés legyártani ezen a csíkszélességen, hiszen az utóbbi években egyedül az nVidia esetében volt példa arra, hogy majd' tenyérnyi lapka sorozatgyártásba került és otthoni felhasználóknak is elérhető volt.
Amúgy a 28>14nm váltást követően, ha képesek arányaiban az adott tranzisztorsűrűséget tartani, akkor azért egy 8modulos X86 és 32CU-s RISC (még mindig csak kérdezem, hogy ezt a szót használhatom-e rá
) rész nem lenne elképzelhetetlen egy Kaveri méretű lapkán, nem? És, ha óvatoskodnak, akkor is elő tudnak jönni egy 4modult + 16CU-t tartalmazó lapkával ebben a mérettartományban. Vagy tévedek?Vagy eleve a Samsung féle 14nm nem XM alapú, mint amit a GloFo (meg még korábban az AMD) tervezett eredetileg?
(#14133): A Tahiti-t Vitamincsiga kolléga a teljesítménye miatt hozta fel és én erre reagáltam azt, hogy annak mérete is van. Nyilván elméleti síkon sem vár senki 14nm-en, vagy akár korábban egy Tahiti-t APU-ba, mikor már a Kaveri IGP-je is ahhoz képes finomhangolva lett tudomásom szerint. Feltételezem, hogy már a Carrizo is ennek megfelelően egy jócskán finomhangolt GCN generációt fog kapni, a 2016-os cuccról nem is beszélve.
Amúgy HSA alatt is nagyobb a memóriaigény, vagy ez most annak az analogiájára lett felhozva, hogy standalone használjuk az APU-t konzolnak?
(#14132) Abu85: Tőled is megkérdezem: Logikusan gondolkodva a Samsung-féle 14nm-en mekkora tranzisztor/mm2 aránynövekedésre lehet számítani? Azt értem, hogy a 4x az az elméleti maximum és erre nem igazán érdemes számolni.
[ Szerkesztve ]
-
dezz
nagyúr
Úgy emlékeztem, a Broadwell csak jövőre jön (ami még most sem kizárt, legfeljebb nem egy egész év múlva). Bár ahogy látom, ez is csak hellyel-közzel támogatja az OpenCL 2.0-t, az igazi a Skylake lesz, amire már áll az intervallummegjelölés.
Tudtommal egyelőre senki sem jelentette be, hogy tevőlegesen, driverekkel (az AMD így hívja, de nevezzük, aminek akarjuk) támogatná az OpenCL 2.0-t, még az AMD sem.
-
Abu85
HÁZIGAZDA
Az OpenCL 2.0 támogatása meglesz, de elsődlegesen a fejlesztők a HSA OpenCL 1.2-es kiterjesztései felé mozdultak. Innen viszont majdnem mindenki jelezte, hogy tudnak csinálni OpenCL 2.0-s portot. Akik nem jelezték azok is csinálnak majd. Az Intel az OpenCL 2.0-ra 100 alkalmazást vár 2015-re. Az AMD ennél pozitívabb, mert ők 400-ról tudnak jelenleg. Ebből persze 150-160 az aktuális OpenCL alkalmazások 2.0-ra portolása. Azt jó lenne tudni, hogy mekkora az átfedés. Valszeg olyan jó 500 alkalmazásunk azért lesz 2015-ben. De szerintem több is, mert az OpenCL 2.0 pont ott könnyíti meg a használatot, ahol a fejlesztőknek a legtöbb gondjuk volt.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Vitamincsiga
tag
Ahol a PCI-E-en kell szaladgálni az adatoknak, ott egyértelmű a nyertes.
Meg ami még ma nem belátható, hogy a 4-8 GB dGPU memóriánál lényegesen nagyobb RAM - ha igényli a program - milyen változásokat fog hozni a programozástechnikában. Ahogy írtad, itt nem lehet összehasonlítási alap.Ami ma még kevésé látszik, hogy a dGPU-k korszakának lassan bealkonyul. /Az Intel lesz az egyik siettető; mert neki nincs.../
Az 1500W-os táp persze, hogy poén volt
Az 5-600W az általad említett 300 W-os TDP-jű APU-nak természetesen elég.Jó lenne egy varázsgömb ;-)
-
dezz
nagyúr
A szaladgáláson szerintem azt értette, hogy többször utazik ide-oda az adat, ilyenkor már nagyon is számít a PCIe késleltetése és sávszéle, amik persze nagyságrendekkel rosszabbak, mint akár a main ramhoz való hozzáférésé.
Utolsó bekezdésre: ahogy az Itanium is lesöpört mindenkit a Föld színéről?
-
Abu85
HÁZIGAZDA
Túl nehéz az Intel koncepciójának hatékony programozása, hogy használható legyen a tömegpiac számára. A GPU-k különösen a SIMT rendszerűek nagyságrendekkel könnyebben programozhatók.
Andrew Richards többször mondta (és ő volt a Larrabee/MIC koncepció szoftveres vezéralakja), hogy az architektúra működhet, de csak akkor használható ki, ha a programozó úgy írja meg a kódot, hogy fixen 16 utasításonként mindig legyen egy scatter vagy gather operáció. Mindent ennek kell alárendelni, és ha ez nem teljesül, akkor a kihasználhatóság drámaian lecsökken. Ez pedig azért van, mert az eredetileg egy szálra tervezett memóriamodell működése túlságosan kötött ahhoz, hogy az efféle masszív párhuzamosságra tervezett rendszernél működjön a ma jellemző 3-4 utasításonkénti scatter/gather mellett.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A HSA csak egy vISA és egy egységes QL koncepció. Az csak arra van, hogy egyszerű legyen a programozás. A hatékonyság a hardverből jön.
Az Intel terve nem zsákutca. Más sem készít más felépítésű GPU-kat, mint a Larrabee/MIC/KNL. A különbség, hogy más ehhez tervezi az ISA-t, ami képes fenntartani a skálázható teljesítményt. A GCN rengeteg feladatban dettó ugyanúgy működik, mint az x86, csak az ISA memóriamodellje úgy van tervezve, hogy a lapkán belül 30ezer konkurens szál is futhat skálázási probléma nélkül. Az x86-ot eredetileg egy szálra tervezték.
Olyan architektúra nem lesz. A gond az, hogy a hatékonyságot nagyban befolyásolja az ISA. Vannak serial, task- és data-parallel feladatok. Nincs olyan univerzális rendszer, ami ezeket lefedi, így kell serial és parallel ISA is a hardverbe.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
dezz
nagyúr
Egyébként hogy néz ki a HSA szoftver oldalról? Lesz valamilyen (saját) OpenCL alternatíva?
"ignore-alod"
Már írtam korábban, hogy ezt felesleges így írni, rendes szótári szó az ignorál.
"Anno az IA-64-gyel is ez volt a terv, abbol is lehetett volna adott esetben x86 utani architektura..."
Mint tudjuk, nem a véletlenen múlt, hogy végül nem lett az - pedig az Intel váltig hitt benne. Csak azért hoztam fel példának, hogy az Intel sem tévedhetetlen. Lehetne más példákat is mondani.
"Amiben en maximalisan nagy fantaziat latok, az -- es most tegyuk zarojelbe az x86-ot mint architekturat, nem az itt a lenyeg -- a GPU felvaltasa egy olyan sokmagos processzorral, ami mindent hazon belul megold. Ha kell, altalanos feladatokra is hasznalhato remekul (mint most az x86 CPU magok), ha pedig az kell, akkor a compute-ot is gyorsan vegrehajtja."
Rendre kihagyod a képletből a fogyasztást és a helyigényt: egy CPU jóval több tranyóból hozza ki ugyanazt a számítási teljesítményt. Az Intel jelenleg a gyártástechnológiai előnyében bízik, de nem biztos, hogy az még sokáig fennmarad.
(#14163) Abu85: "A GCN rengeteg feladatban dettó ugyanúgy működik, mint az x86"
Ezt kifejtenéd, mert én speciel eléggé másmilyennek látom.
"csak az ISA memóriamodellje úgy van tervezve, hogy a lapkán belül 30ezer konkurens szál is futhat skálázási probléma nélkül. Az x86-ot eredetileg egy szálra tervezték."
Meg a GPU szinte teljes belső felépítése, ami lehetővé teszi ezt a 30 ezer szálat...
(#14164): Ja, akkor ugye nem lesz (saját) OpenCL alternatíva, csak a HSA keretrenszer lehetővé teszi, hogy C/C++/Javában is lehessen compute feladatokat leprogramozni. Illetve, ott van még a MS-féle C++ AMP.
[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
Ezért értékes annyira a HSA a fejlesztőknek. Ott nincsen több gyártói implementáció. Egy lesz, amit HSA alapítvány biztosít. Erre lesz a runtime, amit szintén a HSA alapítvány biztosít. Egyedül a finalizer térhet el, de akkor már nem lehet hibázni, hiszen a kód lefordult.
Nincs többféle irány az AMD-nél. Az x86, az ARM csak a serial ISA. Az ARM azért fontos, mert egy csomó szerverpiaci szereplő ARM-ot akar. Nem azért mert az x86 nem jó, hanem mert saját hardvert akarnak. Az AMD lepattanókat akar, hogy ha nincs erre erőforrása a cégnek, akkor megtervezik nekik a hardvert (semi-custom).
Konzolokon nem HSA van? Való igaz, hogy azokra az AMD és nem a HSA alapítvány tervezi az implementációt, de amit megírsz rájuk hozhatod át helyből HSA-ra.
Minden a HSA-ban fut össze.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem tudom mennyire beszélsz ezekről a gyártókkal, de a legtöbb hiba nem a vISA->fizikai ISA fordításból ered. Itt szinte soha nincs probléma. Maximum a kezdetekben, de annyira low-level a fordítási szint, hogy a termék megjelenéséig javítják. A fordítási hibák zöme a programnyelv valamilyen formátumából a vISA-ra való fordításban van. Mivel a HSA-nál a vISA közös és a fordító mindenkinél ugyanaz, így vagy mindenkinél hiba lesz, vagy senkinél. De leginkább az utóbbi.
A finalizer lényegében csak annyi, hogy a vISA utasításait direkten cserélje le a fizikai ISA megegyező utasításaival. Itt ma sem hibázik senki, pedig a HSAIL-nél sokkal elavultabb IL-eket használnak a cégek.
Lesznek külön toolok, de a gyártók ezeket is szabványosítják.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Más dolog a parallel ISA és a serial ISA. Utóbbira nem építesz olyan hardvert, amin belül minimum 2048, de esetleg 45056 szál fut (a GCN adatait tetszőlegesen lehet cserélni másra, itt a sok szál a lényeg). Az AMD64/ARMv8 nagyjából 80-100 szálig bírja. Utána brutális cache kell, ami nem helytakarékos, és nincs jó hatással a fogyasztásra. A parallel ISA azért hoz meg olyan koncepciós döntéseket a szálak futtatására vonatkozóan, hogy mondjuk 45056 szál mellett is elég legyen 1 MB-os gyorsítótár.
Új szoftverek minden újdonsághoz kellenek, de feltétlenül muszáj lekorlátozni a szoftver élettartamát? Miben lesz rosszabb, ha például a C++ programod HSA-ra fordítod és nem natívan GCN-re? Talán abban, hogy futni fog más ISA-n is? Tényleg nem értem, hogy ezzel mi a gond.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A HSAIL-t szándékosan rendkívül egyszerűre tervezték. Mindössze 136 utasítás az egész, és ezek is úgy vannak kialakítva, hogy az alapítványban résztvevő gyártók mindegyik virtuális utasítást ki tudják váltani egy fizikaival. Még az Intelt és az NVIDIA-t is belevették, ha később be akarnak lépni. A későbbi architektúrák nem túl lényegesek, mert azokat lehet vISA-hoz tervezni. Évek óta megteszi ezt mindenki, hiszen minden GPU ISA egy gyártóspecifikus vISA mögött van elrejtve. Most annyi változik, hogy a vISA szabványos lesz, így lecseréli a gyártóspecifikus opciót.
A HSA alapítvány csinál minden szabványosítást. A toolokat főleg az AMD és az ARM csinálja. A Samsung a teszteket dolgozza ki. Igazából mindenkinek megvan a maga feladata. Elsősorban úgy, hogy mihez értenek leginkább.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ez attól függ, hogy milyen architektúráról beszélünk. Például a SIMT modellnél nem kell foglalkoznod a szálakkal.
Ez nem olyan, hogy a mérnök eldönti, hogy a következő generációba 200 szál helyet 20000-et épít. Ahhoz előbb új ISA kell, mert a szálak közötti kommunikáció és a memóriamodell meghatározza, hogy effektíve mennyi szálat érdemes futtatni a hardverben. Akkor jó a data-parallel hardver, ha a beépített feldolgozókon pont az a mennyiségű szál fut, ami a hatékonysághoz szükséges és ezek a szálak is hatékonyan tudnak dolgozni egymás mellett, mert az ISA memória- és szinkronizációs modellje kellően kidolgozott ahhoz, hogy megbirkózzon a feladattal. Ha bármelyik eshetőség nem stimmel, akkor építheted be a millió szálat, a millió magot, a millió regisztert, de a hardver nem fog skálázódni.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
dezz
nagyúr
Oké, de a fizikai törvényeket (már ami a szilíciumra vonatkozik) ők sem tudják felülírni. Ezt a felvetést elintézted annyival, hogy "Tény." Aztán írsz egy panaszáradatot, mintha a szöveg mennyisége döntené el a kérdést.
Pedig hát nem."Ez a jovo? Tenyleg?"
Úgy néz ki, legalábbis amíg le nem cserélik a szilíciumot. De előbb-utóbb más technikánál is előjön a kérdés. A többmagúsítás sem nyerte el mindenki tetszését, de hát ugye eszi, nem eszi, nem kap mást.
Azt meg lehet érteni, hogy nem akarják kiadni a szoftverfejlesztést (mint ahogy az Intel is fejleszti a saját C compilerét), de valóban nem ártana most már gatyába rázni ott a sw-fejlesztő brigádot, komoly fejlesztőket ráállítani, komoly budgettel, stb.
Az, hogy mostanra beérték (ha valóban így van, nem tudom) az ARM-ot alacsony fogyasztásban, nem jelenti azt, hogy le is hagyják, hiszen a fizika itt is közbeszól. És hát legalább ilyen nehéz dolguk lesz ARM által birtokolt piacok meghódításával.
(#14180): "Miert kene egy adott feladatra sok szalat radobni, ha keves szal is gyors tud lenni?"
HA kevés szál is gyors tud lenni... Ez majd elválik.
[ Szerkesztve ]
-
-
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.
-
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 ]
-
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.
-
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 ]
-
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.
-
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.
-
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.
-
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 ]
-
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. -
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
-
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?
).
) rész nem lenne elképzelhetetlen egy Kaveri méretű lapkán, nem? És, ha óvatoskodnak, akkor is elő tudnak jönni egy 4modult + 16CU-t tartalmazó lapkával ebben a mérettartományban. Vagy tévedek?
Az 5-600W az általad említett 300 W-os TDP-jű APU-nak természetesen elég.
/Bár nem HSA, de azért mér valamit.../
Ú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.
- EAFC 24
- Vezeték nélküli fülhallgatók
- antikomcsi: Való Világ: A piszkos 12 - VV12 - Való Világ 12
- Főzőcskés topic
- Windows 11
- HiFi műszaki szemmel - sztereó hangrendszerek
- Székesfehérvár és környéke adok-veszek-beszélgetek
- Milyen okostelefont vegyek?
- A fociról könnyedén, egy baráti társaságban
- Sorozatok
- További aktív témák...
