- iPhone topik
- Xiaomi 15 - kicsi telefon nagy energiával
- Android alkalmazások - szoftver kibeszélő topik
- Xiaomi 15 vagy Samsung S25
- Motorola Edge 60 és Edge 60 Pro - és a vas?
- Fejlődik az okosóra piac, csak visszafelé
- Átlépi végre az iPhone az 5000 mAh-t?
- Vivo X200 Pro - a kétszázát!
- Egy óra, két rendszer
- Redmi Note 9 Pro [joyeuse]
-
Mobilarena
OLVASD VÉGIG ALAPOSAN MIELŐTT ÚJ HOZZÁSZÓLÁST ÍRNÁL!!!
Új hozzászólás Aktív témák
-
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..
-
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
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.
-
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.
-
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. -
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.
-
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.
-
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. -
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.
-
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!
-
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.
-
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.
-
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.
-
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!
-
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.
-
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.
-
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.
-
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.
-
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.
-
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. -
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.
-
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.
-
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. -
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?
-
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. -
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.
-
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.
-
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.
-
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.
-
-
leviske
veterán
-
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.
-
-
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.
-
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. -
-
leviske
veterán
Hogy a mobil vonal a lényeges, és ennek ellenére alaplapgyártók miatt maradt ki a GDDR5.
(#13976) Thrawn:
A Carrizos megjegyzéssel nem értek egyet, mert ha az APU-nak van jövője, annak van most is. Early-adopterként tuti szívni fognak a Kaveri vásárlók, de kérdés, hogy végül a Carrizo mikorra érkezik és mekkora eséllyel indul a piacon, ha várakozás címszó alatt mindenki skippeli érte a Kaverit, ezzel gátolva a HSA desktopon való terjedését.Egyelőre én is gondolkozom, hogy van-e értelme APU-ban gondolkodni frissítés szempontjából, de ha most nem tudnak meggyőzni, nem hiszem, hogy később már sikerül-e. A feltétel most adott, hogy berobban a köztudatba.
MOD: Mindenesetre kettő elmúlt, mostmár tényleg vigyünk át minden Kaveris témát annak a topikjába. Szerintem.
-
leviske
veterán
De én ezt nem értem. $60-80-os videokártyákról nem sajnálják az 1GB GDDR5-öt, de egy akár $400-500-ért eladható alaplapról sajnálják a 8GB-ot? Arról nem is beszélve, hogy mekkora potenciál van a lapkában a barebone gyártók számára.
Mennyire nyomhatná meg a költségeket 8GB GDDR5 integrálása alapokra?
-
-
Abu85
HÁZIGAZDA
Nagyjából egy tucat skálázási stratégiát dolgozott már ki a Mantle team, ideértve a partnereket.
Nyilván a normál AFR-ben senki sem gondolkodik, mert elavult, és ilyen lehetőségek mellett nem is kell törődni vele.
A legegyszerűbb megoldások közé tartoznak a feladat orientált futószalagos rendszerek. Ekkor a motor munkája több lépcsőre lesz bontva és az egyes lépcsők a logikai partíciókon futnak. Például compute és culling az IGP-n, a többi a dGPU-n.
Aztán lehet objektumszinten is szegmentálni. Ez olyan a Lucid régi Hydra technikája, csak a motorba építve, hogy működjön is. Ez a leghatékonyabb opció, csak a legnehezebb is.(#13917) Bici: Nem. Itt párhuzamos a GPU etetése. Nem kellenek átlapolások a soros etetés miatt. Agresszív kötegelés sem kell, mert nincs driver thread.
-
Vartanus
őstag
Ha a Carizzot követő APU-ba esetleg már 14-16CU belekerülne ahhoz már eff. 5,5Ghz-es RAM-ok illenének(mint ahogy a 14CU-s 7790-nek is eff. 6Ghz-esek a ramok),de gyanítom a DDR4 teljes pályája során nem igen fog 5Ghz fölé menni.
Az mondjuk érdekes lehet hogy CPU-dVGA esetében megvan a CPU-dVGA közti relatív nagy késleltetésű PCI-E busz,ami a Kaverinél nincs, mivel a Kaveri GPU-ja közvetlen a rendszer memóriába ír amit a cpu magok azonnal nagyon minimális késleltetéssel érnek el,arról nem beszélve hogy a GCN magok is indíthatnak folyamatot az X86/64-es magokon bármikor-lehet ezekkel már nem lesz annyira veszélyes a ~40Gb/s-os sávszélesség. Gyanítom neked erről jóval több tapasztalatod van hivatásodból kiindulva mint nekem
Én csak okoskodok laikusként,de majd januárban úgy is minden kiderül."es siman hozza egy par generacioval ezelotti csucs dGPU szintjet, APU-bol ",milyen dVGA szintet hozhat?a régi AM3-as konfigom HD 4850-esét beelőzné simán esetleg a 4870-est is?
-
#13593
Ricsiii1992
tag
Fiery
#13591
Ricsiii1992
tag
Remélem csak a gpu (tdp korlát) miatt megy 3,7-en, nem azért mert nem tudja azokat az órajeleket mint a bull., piledriver.
legalább clock to clock javul valamit. Pl ha 16%-ot hoz a bullhoz képest akkor 4,3GHz-en megvan egy 5GHz-en járatott 2 modulos zambezi teljesítménye.Tuningra lehet valamit következtetni? Ha jól tudom még a steamroller se nagyon tér el a magas órajelre tervezett bulldozertől, piledriver-től. Nem kellene már sok a visherához képest könnyedebb stabil 5GHz-hez.
nem csak Fiery-nek akartam, már nem tudtam javítani
-
P.H.
senior tag
Szvsz a "nem szem elől tévesztés" egy másik, akár sikeresebb formája az is, ha - változtatva az régi Intel-stratégián - nem elnyomni szándékoznak a riválisokat, hanem azok eladott termékeiből is hasznot igyekeznek húzni (Android-Microsoft pl.).
Az már sokkal érdekesebb kérdés (és vita tárgya lehet), hogy ez a stratégiaváltozás annak köszönhető, hogy a régi Grove-Otellini tengelyű szemlélet változott az új CEO-val, vagy egyszerűen csak annak, hogy a gyártástechnológia adott legyártott mennyiséggel tudja visszahozni a befektetett dollármilliárdokat - a volumennek tehát legalább egyenes arányban kell nőnie kell a befektetett összeggel -, és az Intel eddig hagyományosan sikeres területei (szerver+asztal+notebook) már szerintük sem nem ígérnek akkora volument a következő 3-5 évre, hogy ezt vagy inkább következő gyártástechnológiai fejlesztéseket finanszírozza, és előnyét megőrizze. -
leviske
veterán
Itt szvsz az is kérdés lesz, hogy az AMD és az Intel mennyire tekintenek még konkurensként egymásra (az összehasonlítgatásoktól eltekintve). Pláne, hogy mobil (első sorban tabletekre gondolok most) fronton az Intelnek mondjuk érdeke volna az AMD sikere is az X86 terjedése végett.
-
Oliverda
titán
Igen, a piaci visszaesésével kicsit kezd visszaütni az erőltetett menet, már ami gyártástechnológiát, és az arra évenként rendszeresen elköltött dollár százmilliókat illeti.
Ha irreális árat mond, akkor azzal valahol maga alatt is vágja majd a fát, mert ugyebár ha nincs üzlet, nincs bevétel sem.
Remélem legalább az NV tud gyártat majd velük valamit, mert akkor legalább valami konkrétabb viszonyítási alap lesz a TSMC-hez képest.
-
Oliverda
titán
14-16 nm-en már talán. Felette kétlem.
A GF-nek szerintem még legalább 2 év, hogy eljusson erre a szintre. Szvsz az AMD-nek érdemes lenne valahogy lelépni tőlük, bár olyan túl sok más opció per pillanat nincs. Az IBM mellett talán a Samsung lehetne egy kapaszkodó. Utóbbi elég sokat fejlődött ezen a területen.[link]
-
-
stratova
veterán
Mivel az aktuális útiterv alapján változatlanul készül 25 W-os variáns is, okkal lehetne feltételezni némi c2c javulást vagy legalább órajelemelést azonos TDP-n belül.
Dezz, közben ezt találtam:
AMD hasn’t disclosed how much the underlying architecture has changed, and I would guess the Puma cores are actually quite similar to Jaguar cores, but the net result is a 2X improvement in performance per Watt according to AMD. They arrive at that number by dividing the performance in a few common benchmarks by the rated TDP of the APUs. Now that’s a bit contrived, as a 25W TDP APU may not actually be drawing 25W during the tests, but we’ll just ignore the marketing for now and focus on the important metrics. Update: It sounds like most of the performance gains come from frequency increases, while power improvements happen at the SoC level.
Anand -
MiklosSaS
nagyúr
Igen, de az AMD-nek nem a VGA-val van gondja hanem pont az X86-reszben. Ott kellene kicsit erositeni..nem latom nagy ertelmet pumpalni az IGP-et, amikor meg semmi sem hasznalja ki..vagy alig. Jatszani ugysem lesz jo meg egyenlore, egy rendes jatekhoz kell a 7790/7850-es VGA, amit ugysem fognak elerni a Kaveri-vel.
-
dezz
nagyúr
Ezt esetleg a Kaveri híres topikba is beírhatnád. Legjobb lenne aktuális órajeleken és CU szám melletti eredményekkel. (Ha már korábbi kijelentéseid hatására egyesek le is vonták a nagy tanulságot, hogy a Kaveri bukás, irány a boltokba i5-ért...)
(#13492) Thrawn: Nem látjuk egymás hozzászólásait abban a topikban.
"mindenféle innen-onnan elejtett infók alapján"
Fogalmam sincs, hogy itt mire gondolsz. Onnantól kezdve senki sem vitatta Fiery teljesítményre vonatkozó kiejeltéseit, hogy közölte, hogy van náluk egy példány. Bár azt azért megjegyeztük, hogy az azért még csak egy ES, amire ő azt mondta, hogy a végleges is ilyen lehet, aztán utóbb hozzátette, hogy meglátjuk. Korábban csak a nem túl acélos órajelet említette, amire én a megduplázott utasításdekódert hoztam fel, ami nem pletyka, hanem hivatalos információ. Megkérnélek, hogy a tényeknek megfelelően "tudósíts".
-
dezz
nagyúr
A piac és a felhasználók szempontjából rossz, ha késik. Akár még ez is hidegen hagyhat, de szerintem mindenkinek úgy tűnik, hogy te kárörvendesz ezen. Amit a kacsintól smiley is csak erősít.
(#13485) Oliverda: Az lehet, csak az a baj, hogy sokan ténynek veszik. Mondjuk ezen nem segítenek azok a roadmapok sem, amiken kb. az év közepétől látható a Kaveri, miközben az év utolsó hónapjában indul meg csak a szállítás és a köv. év Q1-ben kerül valóban piacra.
-
Abu85
HÁZIGAZDA
Lesz benne bidirekcionális power elosztás, de ennek az alapértelmezett működési módja a 3,7 GHz és a 720 MHz. Természetesen ahogy nő a turbó, úgy csökken majd az IGP órajele. Ez fordítva nem lesz igaz az asztali termékeknél.
(#13461) Oliverda: 45 watt a TDP kerete az IGP-nek amiben benne van az UVD és a VCE is. Ezek mellett még van TrueAudio és egy elég komplex memóriavezérlő, plusz a display és a PCI Express. Illetve még az L2 cache a processzornak. Ezt most az AMD már külön számolja hozzá, mert dinamikusan lekapcsolható a háromnegyede.
-
Abu85
HÁZIGAZDA
Technikailag az AMD mérnökei rakták össze működőre. Nem a pénz hiányzott, hanem a szakértelem a gyártástechnológia kapcsán. Az R600 már akkor is működött, amikor megtörtént a felvásárlás, csak az ATI verziója feleannyit tudott, mint a végleges hardver. Az AMD-től kaptak egy teljes mérnöki gárdát, hogy radikálisan feljavítsák az órajelet. Ezt megtették, de ezért jelent meg 9 hónap csúszással.
Ezután az AMD rakott át mérnököket, hogy a következő kör már jó legyen. Így álltak át gyorsan 55 nm-re, amit az ATI nem tett volna meg, de a friss segítséggel megvolt a tapasztalat. Az RV770-et is az AMD tervezte át. Eredetileg 480 shaderesnek készült, de már a felvásárlásnál átvette az AMD-től egy csapat, hogy 800 shaderest csináljon belőle. -
dezz
nagyúr
Akkor még házon belül volt a gyártás az AMD-nél (*), gyártástechnológiai mérnökcsoporttal, akik segítettek az R600 terveinek gyakorlati kivitelezésében, más szóval gyárthatóvá tételében.
A K10 a koros K8-ra épült és a Bulldozer sem pont úgy sikerült, ahogy szerették volna. Na bumm. Mintha az Intelnek nem lett volna már rossz szériája...
* Apropó, ha az Intel nem akadályozta volna illegális módszerekkel a K8 alapú procik piaci sikereit, valószínűleg ma is meg lennének azok a gyárak és talán a gyártástechnológiában sem lennének annyira lemaradva.
-
dezz
nagyúr
Hogy ez csak egy lufi, az a te véleményed. A véleményedet ne vedd ténynek, mintha tévedhetetlen lennél! (Számos vállalat szakembergárdája pedig pancserok. Ja, tudom, csak az Intelnél dolgoznak jó szakemberek...
)Az ATI-s dolog már ott nem stimmel, hogy az ATI azért lett hirtelen és váratlanul eladó, mert komoly gondjaik voltak az R600-assal, az AMD segítsége nélkül zátonyra futott volna a projekt, az ATI pedig valószínű csődbe jutott volna. Az AMD mérnökei segítettek kipofozni. A GCN-t pedig már együtt hozta létre a két cég mérnökeiből álló csoport.
A megfogalmazásod is elég furcsa: ha van kivétel, akkor nem mondhatod, hogy csak a GPU-ik jók.
-
Abu85
HÁZIGAZDA
A Mantle kapcsán sok dolgot nem fognak publikusan elmondani. Repi arról fog beszélni, hogy neki milyen előnyöket jelentett (párhuzamos dispatch, direkt memóriaelérés és async compute), és hogy mit lehet vele megcsinálni, amit a DX-szel például nem.
Azért az állóvizet kavarni is kell folyamatosan. A Mantle igen közel került ahhoz, hogy a PC-s gaming piacot monopolizálja. Az lehet, hogy azt mondják a támogatók, hogy nem kell félni, mert lesz DX port, de annak a minősége elmarad majd a Mantle-től, vagyis a játékosoknak csak látszólag lesz választásuk. Igen, a Mantle-lel kiütjük a szabvány API-k korlátjait, de a kasszánál majd komoly árat fizetünk ezért. Én nem látom, hogy ebben mi a jó.
-
dezz
nagyúr
Az a kérdés merül most fel bennem, hogy vajon kiből indulsz ki...?
Körös-körül mindenki az Intelt ajnározza, ilyen környezetben az is a másik oldal irányába tűnik elfogultnak, aki középen van. De még ha túl is leng a mutató a 0-án a másik irányba, miért csípi annyira egyesek szemét, hogy van egy kivétel az említett szabály alól?
-
Oliverda
titán
"In particular, the L2 Cache becomes much faster, by about 20% compared to Richland, a non-negligible value, while the L1 cache increases both size and speed. Finally, the performance values of L1 and L2 cache should reach those of Intel Ivy Bridge and Haswell."
Azonos órajelen mennyivel gyorsabb a Trinity/Richland párosnál az IVB (és a Haswell) az L1 és L2 cache sebességét tekintve?
, miért nem javítottatok ki, hogy egy másik "R" betűs lesz, amit keresek? Most megyek elszégyellni magam.
/Fáradozásodat előre is köszönjük!!/
/Bár nem HSA, de azért mér valamit.../
Pedig hát nem.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Új hozzászólás Aktív témák
Hirdetés
A topikban az OFF és minden egyéb, nem a témához kapcsolódó hozzászólás gyártása TILOS!
Az ide nem illő hozzászólások topikja:[link]
MIELŐTT LINKELNÉL VAGY KÉRDEZNÉL, MINDIG OLVASS KICSIT VISSZA!!
A topik témája:
Az AMD éppen érkező, vagy jövőbeni új processzorainak kivesézése, lehetőleg minél inkább szakmai keretek között maradva.
- Formula-1
- Steam Deck
- Házimozi belépő szinten
- Dell notebook topic
- iPhone topik
- Xiaomi 15 - kicsi telefon nagy energiával
- Villanyszerelés
- Android alkalmazások - szoftver kibeszélő topik
- Vélemény: nem úgy tűnik, de Lip-Bu Tan most menti meg az Intelt
- Amlogic S905, S912 processzoros készülékek
- További aktív témák...
- AKCIÓ! Apple MacBook Pro 13 2022 M2 8GB 256GB SSD garanciával hibátlan működéssel
- Xiaomi Redmi 13128GB Kártyafüggetlen 1Év Garanciával
- ÁLTALÁNOS IGAZGATÓHELYETTES tábla
- BESZÁMÍTÁS! 6TB Seagate SkyHawk SATA HDD meghajtó garanciával hibátlan működéssel
- Csere-Beszámítás! Asus Számítógép PC Játékra! R5 1600X / GTX 1080 8GB / 32GB DDR4 / 256SSD + 2TB HDD
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: CAMERA-PRO Hungary Kft
Város: Budapest