- Kisebb méretben is elérhető a OnePlus Watch 3
- Belépő táblagépet is villantott a OnePlus
- Változó design, tekerhető lünetta: megjött a Galaxy Watch8 és a Classic
- Teljes külső kijelzővel hódítana a Flip7, ami kapott egy kistestvért is
- Vékonyabb lett, jobb kamerát kapott, de az akku maradt a régi: itt a Fold7
- Azonnali navigációs kérdések órája
- Vékonyabb lett, jobb kamerát kapott, de az akku maradt a régi: itt a Fold7
- Feljutott a G96 a Moto széria csúcsára
- Változó design, tekerhető lünetta: megjött a Galaxy Watch8 és a Classic
- Realme GT 2 Pro - papírforma
- Mobil flották
- Okosóra és okoskiegészítő topik
- Profi EKG-s óra lett a Watch Fitből
- Teljes külső kijelzővel hódítana a Flip7, ami kapott egy kistestvért is
- Samsung Galaxy Watch7 - kötelező kör
Új hozzászólás Aktív témák
-
#126
Abu85
HÁZIGAZDA
fatallerror
#125
Abu85
HÁZIGAZDA
válasz
fatallerror
#125
üzenetére
A 28 nm-rel nincs gond. Már van elég kapacitás is.
Generációnként jobban el lehet adni az áremelést. A kereslet egyébként folyamatosan csökken. A Q1-Q2 negyedéves visszaesés például 7% volt. Ez éves szinten majd kiad egy nagyobb csökkenést. Az alapján kikalkulálható, hogy milyen árak kellenek.Egyébként nem csak az áremelés lehet opció. Meg lehet úszni anélkül is. A platformhoz kötött funkciók ebben segíthetnek, mert ha veszel mondjuk egy Radeont és akarsz bizonyos extrákat, akkor AMD-s gépet kell építeni. Ilyenkor az alacsony nyereséghányaddal rendelkező Radeon mellé veszel egy magas nyereséghányaddal kapható processzort. Ez ellensúlyozza a gondokat. Az NV ugyanezt meg tudja csinálni a Maxwell APU megjelenésével. Ott jó mézesmadzag lehet platformhoz kötni a PhysX esetleges új funkcióit.
-
Abu85
HÁZIGAZDA
Nem az értelmét kell megérteni, hanem azt, hogy nincs más lehetőség. A chipek skálázódása több évtizeden át a Dennard Scalingra épült. Most elértünk egy falat, amit nem lehet átugrani. [link]
Ha nem tudunk átugrani valamit, akkor meg kell kerülni, és ez az ami megszülte a GPGPU-s terveket. Nyilván magát a GPGPU-t nem ez szülte meg, annak alapjai régebbre nyúlnak vissza, de lényegében utat mutatott, hogy merre lehetne kerülni.A kérdés ma már nem úgy hangzik, hogy mit érdemes gyorsítani, hanem úgy, hogy mit lehet, mert a teljesítményt ez fogja biztosítani a jövőben. Más részei a rendszernek már nem skálázhatók.
Mindent, ami adatpárhuzamos érdemes átrakni a GPU-s gyorsításra, máshonnan a fejlesztő nem kap majd teljesítményt.
A felhasználási módokat a piac is alakítja nyilván az eddig ismertek mellett a jövőre is lehet gondolni. Már sokszor volt téma, hogy kezd kibontakozni a hang-, gesztus- és mozgásfelismerés. Mindegyik durván adatpárhuzamos munka, vagyis az inputot nem árt, ha a GPU dolgozza fel. Ehhez hasonló ötletek sorozatban jöhetnek.
-
Abu85
HÁZIGAZDA
A képszerkesztés tipikusan az a munka, amit egyszerű kivitelezni GPU-n. Már a CUDA és az OpenCL előtt is voltak OpenGL-es megoldások. A cél azonban, hogy ne csak ezek a munkák menjenek GPU-val gyorsítva, hanem komplexebb feladatok. Ezekre már komplexebb megoldások is kellenek.
-
#103
Abu85
HÁZIGAZDA
FireKeeper
#102
Abu85
HÁZIGAZDA
válasz
FireKeeper
#102
üzenetére
Ez csak cégérdek. A monopólium megőrzése az elsődleges. Persze most a világ megy szembe ezzel, ami megnehezítik a helyzetet.
Az x86-tól való függést egy olyan infrastruktúra rombolhatja le, mint a HSA. Az OS szintjén ez mindegy. HSA működhet Windows-on, Androidon, Linuxon és gyakorlatilag bármilyen OS-en. Az, hogy az ARM-ra is lesz Windows még nem jelent rögtön nyert meccset, mert a fejlesztők szemében ez például nyűgként jelentkezik, hiszen egy új fizikai ISA, amire programot kell optimalizálni. Nyilván megcsinálják, csak nem szívesen. A sok fizikai CPU és GPU ISA mellett ezért előnyös egy olyan infrastruktúra, amivel a fejlesztők munkája leegyszerűsödik. El kell érni, hogy a fejlesztő egyszer írja meg a programot, és az fusson bármin onnantól kezdve.
-
Abu85
HÁZIGAZDA
A Knights Corner annyira nem gond, mert az eleve accelerator HPC-be. Arra direkten fognak úgyis fejleszteni OpenMP-ben vagy MPI-ben mondjuk.
Az Intelnek monopóliumot ad az x86. Ezért erőltetik oda is ahova nem előnyös. Az Intel előtt a kiépített monopólium fenntartása lebeg, vagyis a programokat az x86-hoz hardverekhez kell kötni. Ha valaha is belebuknak ebbe, akkor az azért lesz, mert makacsul ragaszkodnak az x86-hoz. -
Abu85
HÁZIGAZDA
A HSA-nak sosem lesz marketingértéke, mert az a felhasználók felé nem fog látszani. A programozóknak jó, hogy egyszer megírnak valamit, és módosítás nélkül tudják a különböző hardvereken futtatni a kódot, ráadásul egyszerűbb lesz a munka is. Persze be lehet fizetni egy logót a programba, hogy mutassa ez bezza HSA, de nem hiszem, hogy az alapítvány pénze erre megy majd, nem lenne értéke. A cégek attól, hogy közösen értékelik a jövőt még ellenfelek a piacon, vagyis azon túl, hogy segítik a programozókat, mert ez mindenkinek az érdeke, a marketinget már saját vállra veszik. A HSA a felhasználók felé érdektelen lesz, és nem is lesz kommunikálva, mert nekik ezzel nem kell törődni. Persze élvezni fogják az előnyeit, de a többség nem fogja tudni, hogy a HSA miatt fut a program úgy ahogy.
Az Intelnek minden olyan kezdeményezés rossz, ami a HSA alapkoncepcióját viszi, vagyis elfedi a fizikai ISA-k közötti határokat. Konkrétan a sátán műve a szemükben, mert az Intel a MIC projektben is az x86-tal operál. Ez pedig a tervezés szempontjából szenvedés. Azért tart ennyi ideig a Larrabee fejlesztése, mert az alapokat szolgáltató x86 ISA megalkotásánál még csak nem is volt téma, hogy lesz majd egyszer több mag egymás mellé rakva. Az egész rendszer nagyon mereven kezelik a memóriaműveleteket és a koherenciát, mivel úgy van kialakítva, hogy egy magot szolgáljon, nem volt igény többre, amikor az egészet kreálták. Persze szerencsére valamennyire rugalmas a dolog, így pár szálig azért elevickél, de nagyon sok szálat már érez. Az Intel ezért szopott be három Larrabee-t, mert az x86 egyszerűen túl kötött ahhoz, hogy egy nagyon sokmagos x86-os proci skálázódjon. A GPU-kat eleve úgy tervezik, hogy a skálázódás legyen az elsődleges szempont, és ezért a rendszer minden elemében megteszik a szükséges fejlesztéseket. Ezért változik sokszor - még gyártón belül is - a GPU-architektúrák ISA-ja, mert rugalmasnak kell lennie mindig. Ha nem elég rugalmas, akkor a koncepcionális működés veszik oda, vagyis értelmetlen lesz a termék, lásd Larrabee 1-2-3. A Knights Corner tulajdonképpen a negyedik nekifutás. A Larrabee név eltűnt, helyette lett MIC. Történt egy pár jelentősebb változtatás a rendszerben, amivel lényegében megszűnt az x86-os processzorokkal való bináris kompatibilitás. Ez a skálázás alapvető érdeke volt, így meg kellett lépni. A memóriamodellre rengeteg trükk került elő. A gathert és a scattert is meg kellett reszelni, ahol a korábbi megoldások elvéreztek. Erre talált az Intel egy kvázi értékelhető megoldást: "Programmers should always enforce the execution of a gather/scatter instruction to be re-executed (via a loop) until the full completion of the sequence (i.e. all elements of the gather/scatter sequence have been loaded/stored and hence, the write-mask bits all are zero)." - nem szép, de ha így lehet biztosítani a működést, akkor ez van ...
A legfájóbb viszont a skálázáshoz bevetett tranyó mennyisége. Ez óriási. Hihetetlen méretű a Knights Corner L2 cache mérete, és az Intel fel is hívja rá a figyelmet, hogy a programozásnál is ügyelni kell arra, hogy a magok munkája a hozzájuk rendelt L2 tárra korlátozódjon. Kvázi a feladatszeleteket úgy kell kialakítani, hogy beférjen a cache-be. Nem véletlen, hogy az SRAM cache-t le akarják cserélni, mert amerre ők mennek, ott ez többmilliárd tranyós extraként fog előjönni a konkurencia jóval korszerűbb megoldásaival szemben. Nyilván az x86-hoz való makacs ragaszkodásnak tranyóban kell megfizetni az árát. Az Intel persze jelzi, hogy csak 2%-os extra az x86, de nem konkrétan az ISA dekódolásához szükséges tranyóval van a baj, hanem azzal, hogy amikor tervezték a memóriamodellt, akkor fel sem merült, hogy valaha is terveznek brutálsokmagos x86 rendszert. A dekódolás maga az lehet csak +2%, de a skálázás biztosítása az már milliárdos mértékű extra tranyó. Nem véletlen, hogy a Knights Corner működésbeli koncepcióját senki sem követi a GPU-t, vagy acceleratort tervező, nagy tapasztalattal rendelkező vállalatok közül. Nem azzal van a baj, hogy nem kivitelezhető, hanem a kivitelezhetőség árával. Na most, ha a HSA-t erősíti az Intel, akkor ezt hiába szenvedik el, mert az x86-ot a HSA mellett csak a kirakatba lehet helyezni, de másra igazából nem lesz jó. -
Abu85
HÁZIGAZDA
Az 1.0-s specifikáció a munkacsoportnál van. Az AMD, az ARM, az ImgTec és nemrég a Vivante elfogadta (bár utóbbi cég nem tehetett mást, mert nem founder tag
). A Samsung és a Texas Instruments ül rajta. Ők most dolgoznak még két kiterjesztésen, amit szeretnének, ha elfogadna a munkacsoport. Ezzel elvileg nem lesz gond, de nem biztos, hogy az 1.0-hoz megvárják azokat, mert még az év vége előtt zárni fogják a speckókat, és akkor majd a következő körbe kerülnek be.
A CodeXL-be fog bekerülni az AMD-nél. Ennek a bétája már elérhető. De amúgy, ha OpenCL vagy C++ AMP alkalmazást írsz, akkor az automatikusan kihasználja majd a HSA előnyeit.
Az Intel az sosem fog belépni semmilyen nyílt kezdeményezésbe, ami elmossa a határokat a fizikai ISA-k között. Nekik mindegy, hogy HSA vagy más az infrastruktúra, maga az "írd meg egyszer és futtasd bárhol" koncepció kedvezőtlen számukra. A HSA-val még nem lenne bajuk, hiszen ők is tudják, hogy a programozóknak kell valami egyszerűbb infrastruktúra, azzal az alapgondolatával van a gond, hogy a HSA-hoz hasonló koncepcióban szart sem ér az x86, sőt, az őskövület alapok miatt inkább hátrány. Az Intel választása nagyon egyszerű jelenleg. A HSA széttépi a monopóliumukat, vagyis ugyanoda vezetne, ha beállnak támogatni, vagy esetleg nélkülük elterjed. A cél tehát ellene dolgozni. Persze a fejlesztőket nehéz lesz meggyőzni, hogy miért jó nekik legalább egy tucat cég architektúráira külön dolgozni, mint szimplán a HSA-t használva egyszerre mindet lefedni. Ez lesz a kemény dió. Főleg azután, hogy a HSA-t úgy módosították utólag, hogy legacy módban is fusson, vagyis nem kell egy cég direkt támogatása ahhoz, hogy egy HSA-ra írt program elinduljon az adott hardveren. Többféle futtatás lehetséges a HSA alkalmazásoknál, de olyan alternatívát nem ismer az 1.0-s specifikáció, hogy nem fut. Ezzel tényleg WORA az egész elv, mert még támogatnia sem kell az Intelnek. Persze nyilván a támogatás hiányának lesz sebességáldozata, de az programfüggő, hogy mekkora. -
#74
Abu85
HÁZIGAZDA
ViiiiktorOC
#73
Abu85
HÁZIGAZDA
válasz
ViiiiktorOC
#73
üzenetére
Nagyobb lesz az előzetes adatok alapján. A mértéke persze attól függ, hogy idén még hány százalékot esik a VGA-kra a kereslet.
-
Abu85
HÁZIGAZDA
Pont ezért csinálják a HSA-t, hogy ez ne legyen gond a programozó oldalán. A hardverek közötti különbségeken majd dolgozik a runtime és a finalizer. Johan Andersson is azért van oda érte, mert amit ezzel megír az mindegy, hogy milyen hardveren fut. A HSA még legacy kompatibilítást is kínál, vagyis ha nincs HSA SS a gépen, akkor fordít egy működő legacy kódot.
-
Abu85
HÁZIGAZDA
Másképp kell gondolkodni a GPGPU-nál, de a legnagyobb gondokat a HSA megoldja. Szóval a kezdeti gondok már nem számítanak. Most az számít, hogy minél több cég lépjen be a HSA alapítványba, vagy ahogy Johan Andersson mondta, ha ez nem tetszik, akkor gyorsan készítsenek egy olyan, hasonló infrastruktúrát, ami mindenkinek megfelel. Nyilván a HSA is megfelel mindenkinek, hiszen ellenérvet nem lehet felhozni a támogatása ellen, hacsak az nem ellenérv, hogy az Intel félti a monopóliumát, mert a HSA ezt valóban darabokra tépi, de a programozónak nagyon kedvező, ha egyszer ír meg valamit, és az módosítás nélkül megy minden hardveren.
-
Abu85
HÁZIGAZDA
Az ipar egy dologban hisz, és az a skálázhatóság. Ez megoldható a Pollack-féle szabály alkalmazásával, vagyis sok pici Atom/Bobcat szerű mag, vagy megoldható a GPGPU-val, amivel megőrizhető az egyszálú számítási teljesítmény. Utóbbira startolt mindenki, mert az egy szálú tempót senki sem akarja kivégezni. A többi gondot út közben megoldják. A HSA a legfőbb problémákra már tökéletes megoldást kínál a programozó oldaláról. Annak még lesznek különböző verziói a jövőbeli problémákra.
Nyilván nem kötelező az iparral egyetérteni, de ők azért jobban tudják, hogy mi az ami kivitelezhető, és mi az ami nem. Nyilván ők is tudják, hogy lesznek programozók, akik ezt nem fogják követni, hiszen ma is vannak olyan programozók, akik nem programoznak több szálra.
-
Abu85
HÁZIGAZDA
Az AMD architektúrája jobban figyel Pollack szabályára mint az Intelé. 1 mag meg 2 wattból is kihozható, ha kellően lebutítod. Pollack szabályára természetesen lehet építeni, csak nincs értelme, mert kiheréled az egy szálon elérhető teljesítményt. De igen, lehet 3 GHz-es 16 magos procit csinálni Atom és Bobcat magokkal, és akkor 125 watton belül vagy. Kérdés, hogy kinek lenne ilyenre igénye.
-
Abu85
HÁZIGAZDA
válasz
Baryka007
#19
üzenetére
1000 dolláros kártyát csinálni az AMD szerint nem éri meg. Három cég 1000 darabos limitált szériája le tudja fedni az éves piaci igényt ebben az árkategóriában. A PowerColor, a Sapphire és a HIS csinál egyet-egyet, és teljesen felesleges HD 7990-et csinálni.
Korábban azért más volt, mert 600 dollár volt a csúcsmodell, ami azért tízszeres eladást jelentett. Ma 600 dollár egy Sapphire Toxic 7970 GHz Edition.
). A Samsung és a Texas Instruments ül rajta. Ők most dolgoznak még két kiterjesztésen, amit szeretnének, ha elfogadna a munkacsoport. Ezzel elvileg nem lesz gond, de nem biztos, hogy az 1.0-hoz megvárják azokat, mert még az év vége előtt zárni fogják a speckókat, és akkor majd a következő körbe kerülnek be.
Új hozzászólás Aktív témák
Hirdetés
- ALIENWARE Area-51 R6 Threadripper Edition 1920X
- LG 48C4 - 48" OLED evo - 4K 144Hz - 0.1ms - NVIDIA G-Sync - FreeSync - HDMI 2.1 - A9 Gen7 CPU
- AKCIÓ! nVidia Quadro P4000 8GB GDDR5 videokártya garanciával hibátlan működéssel
- ÁRGARANCIA!Épített KomPhone Ryzen 5 7600X 32/64GB RAM RTX 5070 12GB GAMER PC termékbeszámítással
- Tablet felvásárlás!! Apple iPad, iPad Mini, iPad Air, iPad Pro
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest