Hirdetés
- Feháborodott az Apple, a Meta az iPhone-felhasználók üzeneteit akarja olvasgatni
- A luxusmárkáknak kell a bitcoin, az USA jegybankjának nem
- Letiltja az USA a politikusokat a telefonhívásokról és szöveges üzenetekről
- Nagy áttörés jön a napelemek piacán, nem kell annyi hely a paneleknek
- Belenyúlt az USA az Epic Games igazgatótanácsába, nyomoz az NVIDIA
-
IT café
A legtöbb kérdésre (igen, talán arra is amit éppen feltenni készülsz) már jó eséllyel megtalálható a válasz valahol a topikban. Mielőtt írnál, lapozz vagy tekerj kicsit visszább, és/vagy használd bátran a keresőt a kérdésed kulcsszavaival!
Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
válasz
Oliverda
#16102
üzenetére
A Hynix erről sosem beszél, mert mindig risk productiont kell érteni a listázott termékeire, és a szállítástól számítva négy hónappal állnak át a tömeggyártásra. Ez a Hynixnál mindig így van, a HBM-nél is így volt.
Már nem listázzák, mert mindenki a GDDR6-ra várt, de a volt róla szó a Foxconn információi szerint, hogy az Xbox One X GDDR5X-szel jön, viszont letettek róla, mivel 7x-es volt egy memóriachip ára a GDDR5-höz képest. A GDDR6 ára csak háromszor annyi lesz. Innentől kezdve a GDDR5X ugyanott végzi, ahol a GDDR5M végezte. Amelyik szabványt nem veszi át másik gyártó, az nem tud elterjedni, mert nem alakul ki az árverseny, sőt, az áremelés a jellemző.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Oliverda
#16100
üzenetére
A kísérleti gyártásban mindent fel lehet már tenni. Ezért kísérleti gyártás és nem sampling, a termék szempontjából ez már végleges állapotot tükröz. A gyártósor szempontjából nincs még véglegesítés. A GDDR5X is kísérleti gyártásban volt az 1080 megjelenése után jó három hónapig. Ugyanígy a HBM a Fiji esetében. Ahogy a HBM2-nél is a Xilinx a kísérleti gyártás fázisában rendelt. A GDDR6-nál sem lesz másképp. Ha nincs konkrét termék a kísérleti gyártás során, akkor baromira nehéz valamit tömeggyártásra állítani.
(#16099) core i7: Semmit.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Oliverda
#16097
üzenetére
Tömeggyártás != kísérleti gyártás
Három részletben történik a memóriák bevezetése. Az első a minta kiadása. Ez a program már nyilván aktív, hiszen másképp aligha lehetne itt tavasszal termék, ha ma nem szállítanak hozzá mintákat. A második a kísérleti gyártás, amikor igazából maga a hardver végleges, de a gyártósor paraméterezése még nem az. Emiatt a gyártott mennyiség alacsony, de lényegében rendelhető általánosan. A harmadik lépés pedig a tömeggyártás, amikor véglegesítik a gyártósort is, és ennek megfelelően kezdik el építeni a többit, ilyenkor beszélünk rump upról.(#16095) lenox: Bármi lehet, de a roadmapben az MR-Volta (így szerepel benne) 24/48 GB GDDR6-tal szerepel tavaszra.
(#16096) Loha: A GDDR5X lekerült a fókuszról, mert mocskosul drága. A Micronnak nincs értelme árat csökkenteni, mert senki más nem gyártja, annak ellenére, hogy szabvány a memória, az NV-t bármekkora ár megfizetésére rá tudja kényszeríteni. A GDDR6 is olcsóbban kezd nála, pedig ezek az új memóriák tipikusan drágábban kezdenek.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
core i7
#16092
üzenetére
Túl drága. Emellett jó eséllyel a Volta esetében már csak csatornánként 180 tűt vezetnek ki, ami kell a GDDR6-hoz és jó még a GDDR5-höz is. A GDDR5X 190 tűt igényel. Harmadrészt pedig a GDDR5X-et a Micron nem igazán fejleszti, így kevés a kapacitása.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
-
Abu85
HÁZIGAZDA
válasz
keIdor
#15979
üzenetére
Már van róla GTC előzetes is. Ez az NV első fejlesztése, amit alapból 8 bites integer számításokra optimalizáltak. Egy CUDA magban mostantól nem egy FP és egy INT ALU lesz, hanem egy FP és több INT ALU. Arról még nincs adat, hogy mennyi. Feltételezhetőén nyolc, mert a DL TOPS teljesítményre nyolcszoros hatékonyságot ígérnek.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
-
Abu85
HÁZIGAZDA
válasz
core i7
#15804
üzenetére
Nem biztos, hogy nyáron jön. A Xavier az első Volta GPU-t használó bejelentette termék, ami 2018ban érkezik. Lehetnek még nem bejelentett termékek is, de a Volta bemutatását az NV egy 2017 májusi GTC-re teszi. És a korábbi évek GTC-iről tudjuk, hogy az első bemutatótól számítva 1-2 év telik el a tényleges megvásárolhatóságig.
Az is lehet, hogy a gaming piacra nem Volta jön, hanem egy másik, mert a Volta legfőbb előnye, hogy az egész buszrendszerét az Int8-ra optimalizálták, amiről pont volt szó a most lezajlott GTC Europe alkalmával. Ezért tud 512 CUDA magból kiszedni annyi DL TOPS-ot, amennyit két Parker és két GP106. Na most VGA-nak egy Int8-ra optimalizált rendszer nem ideális, mert egyik grafikus API sem definiálja ezt a precizitást, vagyis kell belőle csinálni egy FP32-es verziót is, mint amilyen a Pascal. Azzal a Volta VGA-ként nem sokra megy, hogy van a CUDA magon belül egy helyett nyolc int8 ALU, ezek nem használhatók PC-n.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Egyik se jön RX 460 árban.
A sima 1050 valamivel 4 GB-os RX 470 alá jön. Verziótól függően 10-25 dollár.
Az 1050 Ti valamivel a 8 GB-os RX 470 alá. Itt a legolcsóbb is annyi lesz, amennyi a 4 GB-os RX 470.A 2 GB-os RX 460-at otthagyják. Annyira drágán gyárt a TSMC, hogy nem tudnak GPU-k küldeni ellene. Az AMD majdnem feleannyiért veszi a wafert a GloFo-tól.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#15692
Abu85
HÁZIGAZDA
KillerKollar
#15691
Abu85
HÁZIGAZDA
válasz
KillerKollar
#15691
üzenetére
Nincs NDA. Akkor tesztel bárki Titan X-et, amikor akar, és az eredmények is publikálhatók. Viszont nincs sample, szóval mindenkinek külön kell vásárolni. Esetleg az OEM-ektől kell komplett gépre sample-t kérni. Az ugye az OEM-en múlik, hogy szállítanak-e, tehát nem gond az, hogy az NVIDIA nem szállít sample-t.
A Titan X az NV-nél hasonló kártya, mint a Radeon Pro Duo az AMD-nél. Van egy szűk célpiaca, és különösebben nem számít a gyártónak, hogy van-e a termékből teszt vagy nincs. A célpiac megveszi úgyis. Általában akkor vannak tesztek, ha a gémerek számítanak célpiacnak.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
-
Abu85
HÁZIGAZDA
Publikusan nem. Mint mondtam ezeket a partnerektől lehet tudni.
A GK210-re válaszolták azt, hogy azokból hiányoznak a grafikai egységek. A GP100-ról hivatalosan nem közölnek ilyeneket, de mindegy, mert a gyártók elmondták, hogy nem lesz, mert nincsenek grafikai egységek benne.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
GTC előadás. Zárt gyártói előadás volt, így újságírók nem mehettek be, de ezek a gyártók megkapták az adatokat, és számos helyről az jött, hogy nincs grafikai egység a GP100-ban. A Hardware.fr is így hallotta, bár nem tudom, hogy nekik melyik gyártó mondta, hogy nem épül majd rá GeForce. Nekem a Supermicro.
Azt az NV írta egy kérdésemre, hogy nincs benne grafikai egység, és ezért adták ki csak Tesla vonalra. Ezt meg is írtam régebben. [link]
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#15292
Abu85
HÁZIGAZDA
Firestormhun
#15291
Abu85
HÁZIGAZDA
válasz
Firestormhun
#15291
üzenetére
Viszont a GK110 esetében az NV nem mondta a GTC-s publikumnak, hogy csak Tesla opciót építenek rá, és Quadro/GeForce modellt ne is várjanak. De egyébként akkor még nem volt kellően moduláris a dizájn, hogy megvonják a HPC-s lapkát a grafikai résztől. Ezt a GK210 esetében kísérletezték ki, hogy miképp lehet olyan blokkokat tervezni, amelyek könnyen megfoszthatók a compute szempontjából nem hasznos elemektől. Ilyet más nem nagyon csinált, aminek az oka, hogy az egész nem teljesen úgy működik, hogy csak kiveszed belőle és kész. Ezt tervezés szintjén kell felépíteni. A grafikai elemeket külön blokkba kell befűzni, stb.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#15290
Abu85
HÁZIGAZDA
FollowTheORI
#15289
Abu85
HÁZIGAZDA
válasz
FollowTheORI
#15289
üzenetére
Mintavételhez. De nem átlagos TMU van benne, hanem olyan, amelyik egy csatornán csak egy címzőt és négy mintavételezőt használ, szűrő pedig nincs. Ezért nem képes szűrt mintákkal visszatérni a GP100. De a compute-ban eleve nem használják a gyártók a szűrőket, szóval ez lényegtelen a HPC-piacon.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Minek nézzék meg? Az NV a GTC-n elmondta, hogy ez csak HPC cucc. Csak Tesla épül majd rá, más sosem. Felesleges például egyet vennie a Chipworksnek és kiadni róla egy röntgent. Persze nem mondom érdekes lenne, de annyit nem ér. Feltételezve, hogy az NV nem hazudik.
Bizonyos Teslákon van. Itt az igények átfedése a fontos. A Tesla P100 szélesebb spektrumon is képes igényeket lefedni, de például ezeknek csak a 10%-a jár jól egy kimenettel, míg a maradéknak nincs szüksége rá. A 10% pedig tudja pótolni egy extra lapkával a node-on belül. Ettől függetlenül egy ekkora lapkánál egy kijelzőmotor nem lett volna haszontalan, de nyilván a hiánya nem rontja a potenciális eladást.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Röntgen. Eléggé felismerhetők ezek az egységek az így készült képen, de lényegtelen röntgenezni, mert a Supermicro számára az NV mondta el, hogy nincs benne grafikai rész. Ezért nem terveznek GP100-as Quadro és GeForce modellt.
Például kaphatna videokimenetet és akkor nem kellene egy extra 2D-s GPU erre a célra node-onként. De ez nem akkora igény, hogy ne lehetne élni nélküle. A legtöbb vezérlőhíd a szerverekben tartalmaz egy alapvető megjelenítőt, hogy legyen egy hibakimenet, ha valami gond van a node-dal.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
westlake
#15273
üzenetére
A GP100 teljesen mindegy, mert nincs benne se szűrt mintákkal visszatérő textúrázó csatorna, se ROP, se setup rész, se kijelzőmotor, se multimédiás blokk. Nem tudják máshova rakni csak Teslába. Ez már biztos, mert ki vannak szállítva az első minták, így ellenőrizhető volt, hogy mi hiányzik a lapkából. Persze Tesla szinten ezek egyáltalán nem hiányoznak. Na jó a kijelzőmotor bizonyos területeken nem lenne rossz, de nem dőlnek a kardjukba a megrendelők, ha nincs.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
stratova
#15268
üzenetére
Valójában nem, mert attól, hogy van öt CUDA_Arch megkülönböztetés, az még nem jelent rögtön öt különböző lapkát, ugyanis egy lapkának is lehet két megkülönböztetett verziója a CUDA-n belül. Ez azért van, hogy a GeForce-ok ne legyenek olyan jók, mint a Teslák. A zárójeles rész pedig csak mellé lett írva.
Ettől egyébként még jöhet akármilyen lapka, akár a sokat emlegetett GP102 is, de az a driverben felfedezett rész egyértelműen nem jelent semmit.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#15157
Abu85
HÁZIGAZDA
gainwardgs
#15156
Abu85
HÁZIGAZDA
válasz
gainwardgs
#15156
üzenetére
Nincs olyan, hogy tökéletes architektúra. Ennek az oka, hogy az igények hónapok alatt kiegészülhetnek, vagy megváltozhatnak, így hardveres váltást igényelnek. Jó példa erre a VR. Amíg ez nem volt, addig senkit sem érdekelt a preempció szemcsézettsége, mert a grafikai munka kiszámítható volt. Amint bejött, hirtelen baromira fontos lett, hogy a szemcsézettség kellően finom legyen, és amelyik cégeknek lépni kellett léptek.
Számos olyan probléma van még, amelyekre egyetlen létező architektúra sem reagál. Rögtön mondok egyet: a rajzolási parancsok számának növekedésével túl kicsik lesznek az elkülönülő feladatok a GPU-n belül, ami csökkenti a kihasználtságot.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#15155
Abu85
HÁZIGAZDA
Malibutomi
#15154
Abu85
HÁZIGAZDA
válasz
Malibutomi
#15154
üzenetére
A magasabb órajel egy másik dolgot is szolgál. DX12-ben nagyon számít a futószalag mélysége, így a +70% órajel 60%-kal csökkenti a várakozási időt, ami azért 20k rajzolásnál már nem mindegy. Az AMD erre problémára utasítás előbetöltést hoz. Ez órajelfüggetlen. Gyakorlatilag arra játszik, hogy már az igénylésnél elérhető legyen az adat.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#15153
Abu85
HÁZIGAZDA
gainwardgs
#15150
Abu85
HÁZIGAZDA
válasz
gainwardgs
#15150
üzenetére
Nem hiszem, hogy ez a konstrukció bukta. Nem a legjobb, de valószínűleg a fermis alap nagyon korlátozza a lehetőségeket. A statikus módszer egy elég jó kompromisszumnak tűnik. Azt biztos sikerül vele korrigálni, hogy ne legyen negatív hatása a multi-engine kódnak. A többi attól függ, hogy az alkalmazásból érkező parancsok alapján a driver mikor milyen felosztást választ, meg persze az is kérdés, hogy a hibrid partíciós üzemmódból mennyi ciklus más üzemmódra váltani.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#15149
Abu85
HÁZIGAZDA
Malibutomi
#15124
Abu85
HÁZIGAZDA
válasz
Malibutomi
#15124
üzenetére
Nem igazán.
Azn kívül, hogy szükséges a dedikált compute queue a hardverhez, ami a Pascalban már megvan, még egy dolog kell az aszinkron shaderhez: a shader típusok konkurens végrehajtása. Ebből a szempontból sok az eltérés. A GCN-ben egy CU bármilyen konkurens shaderekkel dolgozhat, mivel a rendszer dinamikusan particionálja az erőforrásokat a munkamenetnek megfelelően. Ezzel szemben a Kepler/Maxwell erre nem volt képes, így egy SM-en belül nem futhatott csak VS/DS/HS/GS/PS vagy CS.
A Pascal annyit csinál, hogy a driver például az SM-en belüli két blokkból az egyiket odaadhatja a compute-nak, míg a másikat fenntarthatja grafikára. Ez statikus particionálása a munkamenetnek. Jobb, mint amit a Maxwell tud, de rosszabb, mint a GCN1, viszont valszeg a fermis alappal ez a maximum.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Abból lenne érdemes kiindulni, hogy mindkét gyártó azt mondta a partnereknek, hogy a VR belépőt 250 dollárra akarják levinni. Vagyis 250 dollárért minimum 290/970 teljesítmény kell.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#14897
Abu85
HÁZIGAZDA
Malibutomi
#14896
Abu85
HÁZIGAZDA
válasz
Malibutomi
#14896
üzenetére
Nulla gyártó tud bármit is arról, amiről pár napja megy a hírezés. Milyen forrást vársz?
WCCFtech is jó? 
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Programfüggő lesz. A Pascal felépítése nagyon lépdel a GCN felé. Például hasonló lesz az ütemezése, pure bindless lesz, ugyanannyi lesz a ALU/regiszter arány, minden compute blokk aktív lehet az LDS használata mellett, lesz aszinkron compute és durvaszemcsés preempció ... kb. GCN1 szintű tudást kap. Ilyen formában, ha GCN-optimalizált kódokat hoznak át a konzolból, akkor azt a Pascal jobban fogja tűrni, mint egy Maxwell, és ez már előnyt jelenthet a gyakorlatban is. Szóval érdemes a Pascalt venni Maxwell helyett, ha megjelenik.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
westlake
#14883
üzenetére
Azért az architektúra működősét nyilván elég sok tényező befolyásolja. A Kepler elsősorban azért kezd lemaradni, mert a konzolos kódok egyre több shared memory atomicset futtatnak. Az ilyen műveleteket a TFLOPS-októl függetlenül nagyságrendekkel lassabban végzi a Kepler, mert LUU (lock update unlock) mintát alkalmaz, míg a Maxwell1/2-GCN1/2/3-Gen8/9 architektúrák natívak és mindegyik biztosít CAS-t (compare and swap). Semmit sem érsz el a TFLOPS-okkal és a GB/s-okkal, ha a jellemző shared memory atomics kódok futtatásához szükséges tudás hiányában ezek nagyon körülményesen futnak a hardveren, és egy csomószor arra kényszerítik az ütemezőt, hogy állítson le minden munkát, amíg a címzett memória nem válaszol.
A Maxwellben is van egy rakás olyan dolog, ami korrigálásra szorul.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A GDDR5X leginkább attól függ, hogy mikor és mekkora mennyiségben startol egy termék. Magában a lapkában rendkívül kevés változtatást igényel a memóriavezérlő oldalán, tehát igen jó esély van rá, hogy ezt a memóriát már mindegyik hardver támogatni fogja elméletben. De számításba kell venni, hogy a gyártás az év vége előtt nem fog felfutni. Emiatt leginkább azokra a hardverekre ajánlott használni, amelyek az év vége után jönnek.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A belső buszt nehéz fejleszteni anélkül, hogy kivégeznéd a rendszer skálázását, szóval ahhoz nem érdemes hozzányúlni. A GPC-n belüli buszt már egyszerűbb fejleszteni, de ott limitálni fog a fő belső busz teljesítménye. Tehát ez akkor sem fog teszem azt 640 CUDA magnál többet elbírni. És ez most csak egy hasraütésből jött szám, csak a példa miatt. A kérdés tehát az, hogy az a például 640 CUDA mag hogyan legyen strukturálva a GPC-n belül, hogy az jobb eredményt adjon.
Hasonló dolog ez a Fiji-nél. Ott is négy compute motort kezelt a belső busz. És például azt megtehették volna, hogy egy motorba 1024-nél több magot raknak, de minek, nem fog skálázódni a belső busz miatt. Ezért változik ez meg a Polarisben, viszont emiatt megváltozik az architektúra kódolási sémája.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ez nem ilyen egyszerű, ugyanis az alapvető működést biztosító belső busz összesen hat GPC-t kezel. Ezért nem láttál ennél több GPC-t tartalmazó GPU-t a Fermi óta. A Pascal GPC-n belüli busza pedig maximum 10 SM-et kezel, tehát ilyen formában a maximális kiépítés 60 SM. Ha egy SM megőrzi a 64 CUDA magot, akkor a maximális "magszám" 3840.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Mindegy ma már a node, mert direkten GPU-kra tervezett nincsen. Az összes opció SoC-ra tervezett. Ennek az oka, hogy már nincs lehetőség olyan sok variációs lehetőségre, mint régen.
Egyébként nyilván a GPU-kra a 16 nm-es FF+ és az 14 nm-es LPP a legjobb, de csak picikét.A bérgyártó kiválasztásánál az dominálhat ma, hogy akar-e az adott cég az Apple, a Qualcomm és a MediaTek mögött várni a felszabaduló kapacitásra, mert a TSMC sajnos a rendelés mennyisége alapján priorizálja a kiszolgálást. Egy GPU-gyártó ma maximum a negyedik-ötödik lehet a sorban. Ilyen szempontból a Samsung+GloFo sokkal jobb, mert egyrészt a TSMC-től nem lehet semerre lépni, míg a Samsung-GloFo között van átjárás, másrészt a Samsungnál csak a Samsung, míg a GloFo-nál senki nem élvez prioritást.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#14604
Abu85
HÁZIGAZDA
Firestormhun
#14603
Abu85
HÁZIGAZDA
válasz
Firestormhun
#14603
üzenetére
Fasza, akkor kamuztak, mert azt állították, hogy az a Pascal. De legalább most nem makettel jöttek elő.
Az a slide szándékosan nem arányos. Az AMD írta, hogy abból ne számolgassunk.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
-
-
Abu85
HÁZIGAZDA
Nem valószínű, hogy a GP106 250 mm2 körüli méretű. Számold bele, hogy ez nem 28 nm. A 16/14 nm-es node-okhoz készült bulk wafer négyszer drágább, vagyis ugyanabba az árkategóriába kisebb méretű lapka kell. Szóval, ami most 400 mm2 28 nm-en, annak a leváltója 200-300 mm2 között lesz 16/14 nm-en, hacsak nem akarnak úgy 100-150 dollárt emelni megint a VGA-árakon.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Jack@l
#14437
üzenetére
Az ilyen problémákat látnák a röntgenen vagy az ultrahangon. És eleve a hibás forrasztású lapkák nem is kerülnek forgalomba. Itt az a kérdés, hogy ha minden jó, és az egységek külön működnek, akkor együtt miért nem. Az nem kérdés, hogy ha a forrasztás nem jó, akkor miért nem működik, nyilván azért, mert nem lett jó a forrasztás.
A forraszanyag minősége változó. De a notikban sem azért döglenek meg a BGA-s cuccok, mert rossz az anyagminőség, hanem azért, mert a notebookgyártó nem a kiadott specifikációknak megfelelő hűtést tervez. Ezért nem akarta az NV cserélni a tonnaszámra elhulló mobil GeForce-okat, mert igazából a specifikált hűtéssel kibírták volna a garanciaidőt.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Locutus
#14435
üzenetére
Az nem baj, ha gyorsabban halad a fejlesztés, mint azt tervezték. Ennek minden piaci érintett marhára örül, mert az, hogy a HBM-et megveszik még nem jelent semmit. Azt rá kell ültetni egy interposerre és a GPU-val együtt az egész csomagnak kell működnie. Minél hamarabb kapnak nagy mennyiségben lapkákat annál hamarabb tudják tapasztalatot szerezni arról, hogy a komponensek összeillesztése utáni jó működéséhez mi kell. És ez különösen fontos a Fijit látva, mert maga a GPU, a memória és az interposer kihozatala nagyon magas, de amikor összerakják őket, akkor a külön működő egységek jó része együtt már nem működik. Ez jelenleg komoly fejfájást okoz minden érintettnek, mert nem igazán tudják, hogy mi az oka.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Dyingsoul
#14433
üzenetére
Az interposertől függ. Az új modellben ez készül el a legkésőbb. A Fiji életútja árulkodó ebből a szempontból, annak a tape-outja 2013Q3-ban volt. A HBM elkészült 2014Q3-ban, míg az interposer 2015 elején. A Fiji csomagja így 2015 közepén jelent meg.
Ha minden szuper, akkor az új rendszerben a tape-outtól számolva úgy két év, mire lesz termék.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Még az FL_11_1 sem lényeges, mert a legtöbb motor nem megy túl az FL_11_0-n. Mindenki a DX12 alapfunkciókra gyúr, mert azok kihasználása is sok munka. Emellett az FL ma már legacy rendszer. Egyenként kell az opcionális funkciókat ellenőrizni.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#14275
Abu85
HÁZIGAZDA
FollowTheORI
#14274
Abu85
HÁZIGAZDA
válasz
FollowTheORI
#14274
üzenetére
Valójában ez egy kevert motor. Az Unreal Engine 4-ben van pár dolog lecserélve a Luminous Engine működő részeire. De alapjaiban egy UE4-ről van szó.
Jelen helyzetben nem fog jönni PC-re, amit látsz belőle az PS4 port.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#14273
Abu85
HÁZIGAZDA
FollowTheORI
#14272
Abu85
HÁZIGAZDA
válasz
FollowTheORI
#14272
üzenetére
Ez speciel PlayStation 4 devcsomagon fut. PC-re tudtommal nem is jön.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Csabro
#14043
üzenetére
A terv a Q2-es GTC. Ezt azért nehéz innen megmondani, mert az NV-nek a Pascallal egyszerre kell 14 nm-re váltania, interposert választania alá, és átállni HBM-re. Tehát itt megint jön az, hogy a tervekhez képest ezek módosulhatnak. Az utóbbi időben azért volt stabil a VGA-k megjelenése, mert 28 nm-en vagyunk jó ideje, és igazából mindenféle nehéz gyártástechnológiai innováció nélkül jönnek a lapkák.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#13914
üzenetére
Honnan tudod, hogy mit enged és mit tilt az NDA?
Jó, és szerinted miért van gond a Keplerrel az új driverekkel és az új NV-s játékokban? Azon kívül persze, hogy rossz a kihasználtság. Nehéz innen megmondani, hogy ez egy véletlen vagy már szándékos. Vagy egyáltalán nem a driver a gond, és az alkalmazásból hiányzik a Kepler optimalizálás. Ilyen is lehetséges. Mivel eléggé képlékeny ez a terület, így előbb megvárnám mi az oka. A Kepler alapvetően csak az újabb TWIMTBP játékokban szenved, tehát nem valószínű, hogy bármi gond lenne a driverrel vagy a hardverrel. Egyelőre erre csak teóriám van.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#13902
üzenetére
A HBM NDA-s volt. Akkor ment ki a cikk, amikor lejárt az NDA. Ha összehasonlítod más oldallal, akkor ezt láthatod. Az új Catalyst cikkért rám szóltak, hogy nem kellene még. Ezért nem írok erről.
A kép engedélyezve volt.Akármennyire akarod NDA-t nem fogunk sérteni. Nagyon drága a büntetés és nincs aki kifizeti. Ez van. Majd ha lejár az NDA lesz anyag.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
#35434496
#13898
üzenetére
Már nem lehet megmondani, de korábban utaltam rá. Sőt, többen is leírták a Radeon találgatósban.
(#13899) westlake: Semmiről, ami NDA-s. A gyártó dönthet úgy, hogy bizonyos dolgok esetében ezt feloldja, de ha nem, akkor az NDA lejártáig nem lehet írni róla. Egyébként nyilván tudod mi jön legközelebb. Azért nem írom le, mert már ezt is tiltja az NVIDIA.
(#13900) TTomax: De van, viszont nem általános. A HBM-ről és arról a fotóról lehet írni. A nevét viszont már nem lehet elmondani.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
TTomax
#13867
üzenetére
Fogjátok már fel, hogy az NDA megsértése pénzbüntetést von maga után, rosszabb esetben pedig teljes kizárást is. A jövőhéten tudnánk négy-öt olyan érdekes hírt lehozni, amiről más maximum a következő hónapban ír, de nem lehet. Ez mindig így volt és a jövőben is így lesz. Van amiről lehet írni és van amiről nem.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
namaste
#13814
üzenetére
A lapkán belül elfoglalt hely igazából jóval kisebb lesz. A memóriavezérlőnél nem csak a memóriabusz szélessége veszi el a lapkán a helyet, hanem a hozzá épített logikai blokk. A HBM esetében utóbbi nagyságrendekkel egyszerűbb, így még 4096 bites HBM memóriavezérlő is sokkal kevesebb lapkaterületet igényel, mint egy 512 bites DDR3/GDDR5 vezérlő. A huzalozás pedig addig nem gond, amíg azt nem kell kivezetni a NYÁK-ra. A HBM-nél a probléma az interposer. Az az egésznek az alapja. Ha az nem jó, akkor bukik az egész.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Jack@l
#13809
üzenetére
Nagyságrendekkel egyszerűbb vezérlő kell hozzá, mint ami akár a DDR3 memóriához kell. Számos komponens el is tűnik, mivel nem kell kivezetned a csatornát a NYÁK-ra. A HBM kritikus pontja az interposer, és a memória, interposer, GPU működésének összehangolása a kívánt órajelen. Más szempontból jóval egyszerűbb, mint a GDDR5. Ha tényszerűen akarunk fogalmazni, akkor a HBM implementálásának a GDDR5 implementációkhoz képest máshol vannak a buktatói. Összességében viszont, ha a buktatóit lekezeled, akkor jóval egyszerűbben működtethető rendszert kapsz, amely nagymértékben egyszerűsíti a VGA dizájnját.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Jack@l
#13807
üzenetére
Nézz utána. Egy GDDR5-ös lapka kapacitástól és órajeltől függően 1-2 watt között fogyaszt. Add össze a lapkákat a VGA-n. A memóriavezérlő magán a GPU-n szélességtől függően 10-30 watt, A PLI és az egyéb komponensek ezt további +10-20 wattal egészítik ki órajeltől és a busz szélességétől függően.
A HBM esetében a memóriák fogyasztása megmarad 1-2 watt órajeltől függően, viszont maga a lapkába épített memóriavezérlő jóval egyszerűbb lesz, illetve a 2.5D stacking a többi komponens fogyasztásától nagyrészt megkíméli a rendszert (nem teszi szükségessé azokat). Innen jönnek ki azok az előnyök, amelyekről a Hynix szokott beszélni.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Jack@l
#13804
üzenetére
Azért itt a teljes memóriarendszer fogyasztása GDDR5-tel nem kevés, és ebben benne vannak a lapkák, a PLI, a vezérlő, ami tehát lényegében kell a működéshez. Ez pedig egy mai top VGA-nál 40-60 watt közötti órajeltől függően.
A HBM esetében ez 10-20 watt közé szorítható, szintén órajeltől függően.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#13679
Abu85
HÁZIGAZDA
KillerKollar
#13670
Abu85
HÁZIGAZDA
válasz
KillerKollar
#13670
üzenetére
[link] - itt le van írva hogyan jön ki.
(#13674) TESCO-Zsömle: Nem marketing, nagyjából alá van támasztva.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#13662
Abu85
HÁZIGAZDA
Malibutomi
#13661
Abu85
HÁZIGAZDA
válasz
Malibutomi
#13661
üzenetére
A feketedoboznak igazából semmi előnye nincs. Mivel a D3D bájtkódot mindenképp látja mindenki, így le lehet cserélni. Minden GameWorks játék esetében ugyanaz van. Az AMD hoz rá egy shader cserét, amivel megelőzik az NV-t és az NV is hoz rá egy shader cserét, amivel felzárkóznak. A gond az, hogy ez egy másfél hónapos procedúra, ami igazából a játékosnak szopás. Ezért óriási nagy baromság a GameWorks abban a formában, ahogy van, mert a kezdetekkor senkinek sem fut jól, amire számtalan példa van az elmúlt évből, és másfél hónap után is csak hackelés megy. Nem véletlen, hogy PC-s szinten komoly stúdió és kiadó hozzá sem nyúl, egyszerűen nem éri meg a vele járó szopást.
Maga a GameWorks koncepció egyébként jó, csak csomagolni kellene a forráskódot.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
-Solt-
#13656
üzenetére
Azért az NV és az AMD is meg van győződve arról, hogy amit tesznek az szoftveres szempontból jó. És ennek megvan a teljesen logikus magyarázata: azt a visszajelzést kapták a partnereiktől, hogy erre lesz szükség a jövőben.
A probléma valójában az, hogy mindkét kategória él. Van olyan stúdió, ahol egyszerűen nincs pénz arra, hogy csak a PC-ért rakjanak a játékba egy abszolút kidolgozott szőrzet és hajszimulációt. Tehát igényelnek egy olyan middleware-t, ami egyszerűen beépíthető, ne követeljen semmit, az sem baj, ha nincs hozzá OIT, analitikai élsimítás, és önárnyékolás, egyszerűen csak működjön: HairWorks. Van azonban a másik véglet, ahol azért úgy állnak hozzá, hogy jó lenne ha kinézne valahogy, és ezért hajlandók akár fél éves kutatásra is, annak minden anyagi költségével: TressFX.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
-Solt-
#13652
üzenetére
Persze ez realitás. Eleve az én véleményem az, hogy az AMD és az NV is egy buborékban él. Nem viccből alakultak ki úgy a partnerprogramok ahogy, de kérdés, hogy mennyire torzultak a vélemények a partnerek jellegétől.
Világos, hogy az EA, a Square Enix, a Capcom és a hasonló nagy, PC-re azért figyelő kiadók számára abszolút realitás mindent saját maguknak megírni. Ezt róluk el is hiszem, de egy City Interactive-ról már nem. Viszont az AMD minőségi rostáján ők nem csúsztak át, így elveszik a véleményük. Ugyanez az NV-nél, csak az EA, a Square Enix és a Capcom véleménye veszik el, mert nem partnerek, tehát amit ők ebből látnak, hogy a például a City Interactive igényli a middleware-eket.
Ezzel az AMD és az NV a befutott véleményeket levetítik a piacra.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nagyon röviden leírom mi a gond.
Vagy egy fejlesztői réteg, akik nem akarnak feketedobozokat, mert szerintük a zárt middleware-ek a fő okai annak, hogy a játék rosszul fut és/vagy rosszul néz ki. Ott a The Order 1886. Nem csinál semmi rendkívülit, csak a leképző minden egyes porcikája saját, hogy a végeredmény szuper legyen. Ezzel ért egyet az AMD és ennek a rétegnek az igényét szolgálják ki dokumentációkkal, disassemblerrel és saját API-val.
Van egy másik réteg, akiknek marhára nincs erre erőforrásuk, ezért számukra mindegy, hogy rosszul fut és/vagy csúnyácska, az a lényeg, hogy olcsón beépíthető legyen. Ha lassú majd vesz hozzá a user egy második VGA-t vagy kikapcsolja. Ezzel ért egyet az NV és ennek a rétegnek az igényét szolgálják ki a zárt middleware-jeikkel.
Az átfedés esélye csekély.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
daveoff
#13630
üzenetére
Nem akarok válaszolni Gbors helyett, de már mondtam neked, hogy az AMD és az NV teljesen eltérő igényeket akar kiszolgálni, elsődlegesen a fejlesztői, és ezzel kapcsolatban a felhasználói oldalon.
A fejlesztők támogatása szempontjából annyira radikálisan eltérő a két cég hozzáállása, hogy amelyikkel az egyik csapat együtt tud dolgozni, az a másikkal már nem.Ez úgy fog lecsapódni, hogy lesznek exkluzív dolgok Radeonra és GeForce-ra is, csak más-más játékokban. Tehát lényegében mindegy az árazás, ha a kedvenc játékod xy gyártóra tartalmaz exkluzív cuccot, akkor el van döntve a választás. És ezt nem csak úgy mondom, láttam már, hogy milyen újítások jönnek.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
daveoff
#13562
üzenetére
Ilyen formában nem. Csak számokat kaptak a gyártók, amiből készült a grafikon. Valaki megszerezte ezt a leírást és arra felhúzott egy komplett prezentációt. Amit írnak benne az nagyrészt igaz, bár vannak benne elírások.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
daveoff
#13560
üzenetére
A dia az. Leírás van a kártyáról a gyártóknál és azt valszeg valaki összeszerkesztette egy ilyen anyaggá, ezért van benne rengeteg hiba.
Úgy fogalmaznék, hogy ilyen formában, ahogy látod nem létezik a dia. Más formában létezik.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
daveoff
#13486
üzenetére
A Vulkan core specifikáció bármilyen modernebb hardveren üzemképes (Kepler+, Gen7.5+). Azt lehet tudni, hogy nagyjából az API függvények 90%-a ugyanaz, mint a Mantle, és a Mantle core-t eleve úgy építették fel, hogy több architektúrát is támogathasson. A kiterjesztések igényelnek GCN-t. De például az explicit bindless kiterjesztéshez jó a Kepler és a Maxwell is, mert emulálhatóvá tették a bekötést, így az NV írhat rá egy szoftveres implementációt. Szóval a programok futtathatósága széleskörűen támogatott.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
daveoff
#13484
üzenetére
Johan Andersson mondta már, hogy ő és ezzel lényegében a Frostbite Team is a Vulkan API-t támogatja. Ez biztos. Aztán, hogy akarnak-e még DX12-t is az rajtuk áll. Nyilván nem lenne nagy meló, de nincs túl sok érv mellette, ha már a Vulkan adott. Még ha meg is írják, ami napok kérdése, akkor is effektíve megduplázza a leképzőkre levetített tesztelési időt, ami igazából nem hiányzik senkinek.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A low-level váltás eléggé gyors lesz. A Vulkan nagyjából augusztusban lesz elérhető, míg a DX12 ugye a Windows 10-zel októberben.
Ősszel szinte csak olyan AAA játék jön, ami valamelyiket vagy mindkettőt támogatja. Ideértve a patcheket is, amelyek a korábban megjelent játékokhoz jönnek.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#13478
Abu85
HÁZIGAZDA
#Morcosmedve
#13475
Abu85
HÁZIGAZDA
válasz
#Morcosmedve
#13475
üzenetére
A mostani gondok jelentős részét az adja, hogy túl drága puffert törölni DirectX 11 és OpenGL 4.x alatt. Egyszerűen inkább otthagyják a nem használt adatot, mert a törlés parancs 30-50 ms-ig tartó ellenőrzést is maga után vonhat. Ez gyakorlatilag mikroakadást fog jelenteni. A másik gond a streaming. A rossz törlési lehetőségek megakadályozzák a hatékony rendszerek felépítését.
Ha a low-level lehetőségekre gondolunk, akkor valószínűleg a legtöbb PC-s játék a Sniper Elite 3 streamingjét veszi majd át. Ott a memóriatörlés ingyenes, néha kell csupán a gyors defragmentáció után egy pointerkorrekció. A különböző VRAM kapacitás mellett a defragmentáció sűrűsége fog változni.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Jack@l
#13470
üzenetére
Mit milyen áron? Jönnek a 8 TFLOPS-os teljesítményt megközelítő GPU-k, és ezeknek szükségük van legalább fél terabájt/s-os sávszélességre, de inkább többre. Mivel 1024 bites GDDR5-öt nagyon körülményes építeni egy olyan NYÁK-ra, mint amilyen a VGA-knak van, meg persze nagyon költséges is, így kellett valami új memória. A HBM látja el most ezt a szerepet. Ezzel nem kell kivezetni a NYÁK-ra a memóriabusz-t. Persze ott az interposer kérdése, ami távolról sem egyszerű, de a GlobalFoundries és a TSMC megoldása is jól működik.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Jack@l
#13466
üzenetére
Nagyobb sávszélesség, alacsonyabb késleltetés, kisebb fogyasztás, kisebb költség a NYÁK szempontjából.
Ha az AMD-nek nem fog működni, akkor az a Hynix számára baj, hiszen csupán egy cég visszajelzéseire tették fel az egész HBM jövőjét. Ha az AMD rossz visszajelzéseket adott, akkor hibás irányba fejlesztik a második és harmadik generációs HBM-et, tehát gyakorlatilag csúszni fog minden, esetleg a rendeléseket a többi cég visszamondja, és megpróbálják a HMC-vel, ami persze nem áll jobban, de több cég visszajelzései alapján fejleszti a Micron.
De amúgy ennek kicsi az esélye. Az AMD nem ma kezdte, mivel ők vállalták a vezetős szerepet a GDDR4 és a GDDR5 fejlesztésében is, és utóbbira máig építünk.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Amit ők csinálnak az sajnos nagyon terheli. A legtöbb particle rendszer a mai játékokban közelébe sincs annak, amit a Nitrous tud. Azért tértek át a GPGPU-ra, mert több modernebb hardver kezel több compute parancslistát, így nem csak a fő parancsprocesszoron lehet eljuttatni a compute parancsokat a GPU-ba. Emellett ennek az előnye még, hogy lehetőség van a compute pipeline-ok párhuzamos futtatására. Ez az új API-k másik újdonsága, így úrrá tudnak lenni számos korábbi limitáción. Most a legfőbb gondjuk a memória-sávszélesség, ugyanis amelyik szoftveres limitet ki lehetett ütni azt kiütötték, de eljutottak egy nehezen kezelhető hardveres limithez. Jelen formában a Nitrous teljesítményét a sávszél korlátozza.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Valamivel komplexebb is lehet a jelenet, mert például StarSwarmban még nagyon kezdetleges volt a particle rendszer. Ezt már az AotS átrakta GPGPU-ra. Az fontos, hogy nagyon sok dolog változott. Az effektek nagy része compute lett, hogy ezek a pipeline-ok egymás mellett is futhassanak. A StarSwarm az csak egy promó volt, hogy megmutassák a lehetőségeket. Az AotS az éles bevetés. Youtube-on vannak róla videók.
Nem is sávszél a gond, hanem az allokációs stratégia, mint a Tonga és a BF4 esetében. Nem volt lényeges erre optimalizálni, mert nem ezt akarták megmutatni.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Jack@l
#13433
üzenetére
Nagyon egyszerűen le lehet vezetni.
Egy 1 GHz-es HBM stack 1 Gbps-os, ami 1024 biten 128 GB/s-ot jelent, míg egy 7 GHz-es GDDR5 memória 7 Gbps-os, ami 32 biten 28 GB/s-ot jelent.
Ezeket adhatod össze. Például 128 bitre kötsz négy 32 bites GDDR5-öt, akkor abból 112 GB/s-od lesz. 256 biten már 224 GB/s-od lesz és így tovább.
A HBM is ugyanez. 2048 biten lesz 256 GB/s-od, míg 4096 biten 512 GB/s-od.Persze az órajelek változhatnak és akkor változik a sávszélesség is.
A hatékonyság az, amiben sokkal jobban működik a HBM, mint a GDDR5, mert az alacsony órajel miatt nagyságrendekkel kisebb a fogyasztása.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Jack@l
#13431
üzenetére
Írtam, hogy a GDDR5 szabvány lehetőséget ad erre, de csak azokkal a memóriákkal, amelyek támogatják a clamshell módot. Ilyenkor az adott memória a 32 bites buszra párosával helyezhető, és az inicializálásnál a busznak az egyik 16 bitjét az egyik, míg a másik 16 bitjét a másik memória fogja használni. Természetesen ez 16-16 bites kapcsolat, ami összességében 32 bites lesz.
A HBM esetében egy picit más a működés ugyanis egymásra vannak helyezve a memóriák. Egy HBM stack 4 memóriát tartalmaz és így jön ki egy stackre ma az 1 GB-os kapacitás. A HBM szabvány szerint ez a stack köthető hozzá 1024 biten a lapka vezérlőjéhez. De ha több stack kell, akkor több kivezetés is kell.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Jack@l
#13429
üzenetére
Amiről te beszélsz azt úgy hívják, hogy konfigurálás. A GDDR5 szabványnak is a része, hogy a memória lehet x16-os és x32-es konfigurálású. Például, amikor a VGA-t hátoldalán is vannak lapkák, akkor x16-os konfigurálás kell, ugyanis nem tudsz egy 32 bites adatbuszra bekötni két 32 bites memóriát. Két 16 bitest viszont igen, és ezzel növelhető a kapacitás. Viszont ehhez az is kell, hogy az adott GDDR5 memória támogassa az x16-os konfigurálást, azaz a clamshell módot. Van ilyen, csak nem a 8 gigabitesek között.
A HBM lényege, hogy ne vezesd ki a memóriabuszt a NYÁK-ra. Egyszerűen az interposerig tart a kivezetés, tehát a tokozást nem hagyja el az adatbusz. A többi viszont ugyanaz, ha négy darab 1 GB-os memóriát akarsz, akkor muszáj négy darab 1024 bites, azaz 4096 buszt építeni hozzá.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Jack@l
#13425
üzenetére
Mint írtam azt kell figyelembe venni, hogy hány kivezetésed van. Ha 256 bites a busz, akkor arra 8 darab x32-es GDDR5 memória köthető. Ha 512 bites a busz, akkor 16 darab. Eszerint kell megválasztanod a GDDR5 memória kapacitását is.
128 bites buszra nem valószínű, hogy be tudsz kötni 8 GB-ot, mert a legnagyobb kapacitású GDDR5 memória 8 gigabites, tehát abból csak négyet tudsz használni, ami 4 GB-nyi memória. Esetleg ha valaki csinál neked x16-os konfigurálású 8 gigabites GDDR5 memóriát, de ilyen ma nem létezik.
Igen a HBM is ugyanígy működik, csak egy memóriának a konfigja x1024-es. Ergó, ha négyet kötsz be, akkor 4096 bites buszt kell a GPU-ból kivezetni.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Jack@l
#13415
üzenetére
A HBM kb. ugyanaz, mint a GDDR5, csak a HBM x1024-es IO-t használ, míg a GDDR5 x32-est. Tehát mondjuk, ha 8 GDDR5 memóriát akarsz a GPU-hoz kötni, akkor 256 bites buszra van szükség. Ugyanígy ha négy HBM-et akarsz bekötni, akkor 4096 bites busz kell.
(#13418) Jack@l: Nem is szükséges az API-t ismerni ahhoz, hogy a motor struktúrája low-level API-hoz igazodjon. Csak a gond az, hogy a 0.1-es és a 0.7-es motorverzió sok dologban eltér.
A StarSwarm nem scriptelt jelenet.
Azért jóval több az 1-2 napos munkánál. A 0.7-es motorverzió a StarSwarm effektjeinek többségét nem fogadja el, tehát azokat át kell írni. Ezért nem foglalkoznak már vele. Akinek az új motorverzióról kell teszt, az kérheti az AotS techdemót.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A StarSwarm nem tartalmaz optimalizált memóriamenedzsmentet a GCN-hez. Egyébként inkább 30% a terhelése az R9 290X-en. Nem volt cél ezt optimalizálni.
Az Ashes of the Singularity esetében fogyasztásra vonatkozó adatok nincsenek, de a 290X ventilátora 80% körül üzemelt. A terhelés az Oxide szerint 90% közeli, ha a sávszél nem limitálja a lapkát. A Fiji egyébként többre képes, csak azt még nem mutatták meg. Ott már mindig 90% fölött van a terhelés az olyan szituációkban is, ahol a sávszél a többi GPU-t megfogja. Azt mondták, hogy jóval nagyobb a terhelés, mint a Furmark esetében, ezért is pörög sokkal jobban a venti.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
De az. Ezt direkt megkérdeztem Tim Kipptől. A Nitrous 2014-ben beépített fejlesztései nincsenek kimentve a StarSwarmba. Túl sok erőforrás lenne, és már a saját játékukra szeretnének koncentrálni. Ezért a StarSwarm a 2013-as engine-re épül, amit igény esetén optimalizálnak az egyes architektúrákra, ha valaki promózni akar vele, de ettől még 0.1 alpha marad a motor. Akinek kell a legújabb Nitrous kód promó célra az elkérheti az Ashes of the Singularity engine tesztjét, ezt is odaadják, de ennek jóval komolyabb az igénye, mint a StarSwarmnak, mivel ez már a 0.7-es motorverzióra épül, és az effektek 70%-a át van benne írva compute-ra, illetve támogat már aszinkron compute-ot és aszinkron DMA-t, és van benne MSAA (ez még nincs engedélyezve).
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Hiába pakolsz 7-8 TFLOPS-ot egy GPU-ba, ha nem növeled a sávszélt.
Tettek ajánlatot az NV-nél a Microsoftnak.
Ez azért van, mert a StarSwarm az AMD-re egy 2014 márciusi kódot tartalmaz, míg a Maxwellre egy decemberit. Az Intel esetében például teljesen hiányzik az optimalizálás. [link] - ezért nem skálázódik. Innentől kezdve mindegy a driver, mert az alkalmazásban lesz mindaz, amiért korábban a driver felelt. A Kepler sem az igazi benne, erre is régi a path.
Hát akkor nézd meg: [link]
(#13408) Jack@l: Az aktuális HBM memória 1 GB-os. Ahhoz, hogy 8 GB-ot rakjanak rá 8192 bites busz kell, de csak 4096 bitest kap a Fiji.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
schwartz
#13405
üzenetére
Az sem elfogadható, hogy a GCN legyen az optimalizálási cél a fejlesztőknél, csak azért, mert az AMD behúzott két konzolt. Ők pontosan tudják, hogy ha az új API-k lehetővé teszik a compute nyalánkságokat, akkor az AMD úgy elhúz, ahogy azt ma az OpenCL-ben teszik. Ezért nem szabad engedniük a fejlesztőknek, hogy a saját fejük után menjenek. Majd az NV megírja és odaadja az effektet, amit kérnek. Az egyébként nem feltétlenül fontos, hogy minden játékban legyen GameWorks. Erre az NV sem koncentrál, mert tudják jól, hogy bizonyos nagyobb stúdiók nem fognak middleware-eket használni, de a kisebb stúdiókat nagyon könnyen lehet ezzel célozni.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
schwartz
#13402
üzenetére
A legtöbb nagy stúdió eleve visszafejti a GeForce-ok architektúráját. Tehát a nagyoknál ebből nem lesz gond. Vagy csak akkor, ha pénzszűkébe kerülnek, lásd Crytek. A frissebb CryEngine verziók ezért lassabbak GeForce-on, mert nem volt lehetőség az optimalizálásra, de ez is csak időszakos probléma.
Az NV azt akarja, hogy a GameWorksöt használják sokan. Valószínű, hogy azt is elfogadják, ami történt az Evolve esetében. A beépített SSDO nagyon jó minőségű, de berakták a HBAO+-t is, annak ellenére, hogy lassabb és nem olyan jó minőségű, mert nem veszi figyelembe a környezet színét.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
schwartz
#13394
üzenetére
Ebbe is bejátszanak az alapvető irányzatok, amiket leírtam. Az NV a saját middleware-jére koncentrál. A GameWorks előnye, hogy reálisan beépíthetők a motorokba (kis módosítás esetleg kell). Viszont a hátrány között nem csak a minőség és a sebesség hiánya szerepel, hanem az optimalizálhatóság hiánya is. Minden middleware problémája, hogy nem lehet a VRAM használatot normálisan optimalizálni.
Ezek miatt az NV például nem számol azzal, hogy a GameWorks mellett bármelyik fejlesztő is hozzányúl mondjuk az async compute és DMA képességekhez az új API-kban. Egyszerűen túl bonyolult megoldani a GameWorksszel. Ilyen szempontból nekik a sávszél nem annyira kritikus probléma, mert eleve nagyon nehéz lesz a partnereiknek párhuzamosan futtatni a pipeline-okat.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
decibel
#13390
üzenetére
Nincs itt semmiféle mesterterv. Történnek a dolgok. Mindenki sütögeti a saját pecsenyéjét. Nyitnak ilyen-olyan irányba és azokat összefűzve próbálják erősíteni a teljes termékskálájukat.
Az AMD helyzete nagyon egyszerű. Ott vannak két olyan konzolban, amelyből évente eladnak összesen 12-14 milliót. Ezt tudták 2009-ben is, mivel ekkor már le volt fixálva az üzlet. Így kitalálták, hogy akkor ebből úgy tudnak a PC-ben előnyt kovácsolni, ha mostantól low-level API-kkal dolgoznának a fejlesztők PC-re is. Nem kell zseninek lenni ahhoz, hogy az összefüggést lássuk. A GCN-t megtanulják és ezt a tudást át tudják úgy menteni PC-re, hogy az alkalmazásokba hatékonyan meg tudják írni azokat a funkciókat, amelyeket eddig a gyártók írtak a driverbe. Ezért mindegy, hogy milyen API-val dolgozik a fejlesztő, a lényeg, hogy low-level legyen. Persze a terv része még, hogy ha már csinált az AMD egy saját API-t, akkor most rákényszerítheti az akaratát a piacra. A Khronos már most nem úgy fejlesztett, ahogy szokott. Nagyon egyszerű egy olyan sérülékeny ipart manipulálni, ahol egy-két évig is ülnek az egyes ötleteken az API-t fejlesztő csoportok. Az AMD csak a saját előnyére fordítja a szabványalkotás általános gyengeségeit. Mindenki kizárásával beépítenek valamit egy saját API-ba, azt amit a fejlesztők kérnek, és odadobnak egy pöttyös labdát a lépéskényszerbe kerülő Khronos és MS számára. Közvetve ennek az a hatása, hogy az AMD részben meghatározza a fejlődés irányát. Két konzollal a hátuk mögött nekik ez a logikus irány.
Az NV helyzete is nagyon egyszerű. Nyilván ők is sejtették, hogy 2009-ben az AMD elvitte mindkét konzolt (azért az iparágon belül valószínűleg nem nehéz megszerezni ilyen alap infókat, valszeg nem tudták, hogy az AMD mivel nyert, de azt tudták, hogy nem őket választották, és az MS/Sony igényei mellett kinek volt reális esélye), és mivel nem hülyék dolgoznak ott, így azt is tudták, hogy ebből mit akar majd kihozni az AMD a PC-ben. Az NV tehát arra készült fel, hogy a fejlesztőknek nagyon nehéz dolguk legyen a low-level iránnyal, így a Fermi-vel kezdve fokozatosan leállították a dokumentációt, a fejlesztőeszközöket egyre jobban lezárták vagy az egyes optimalizálást segítő részeiket megszüntették. Ezzel elérték, hogy a fejlesztők nem tudnak majd az NV architektúráira optimalizálni, hacsak önköltségen vissza nem fejtik azokat. Viszont, hogy legyen menekülőút létrehozták a GameWorksöt, ahol meghatározhatják, hogy az egyes effektek min és mennyire gyorsan fussanak, és megfelelő tudás nélkül a legtöbb fejlesztő még a forráskód elkérése esetén sem fogja tudni, hogy az a kód optimálisan fut-e a GeForce-on, tehát nem tehetnek mást, mint elhiszik, hogy igen. És, ha logikusan szemléled, akkor nulla konzollal a hátuk mögött nekik ez a logikus irány.
Az persze kétségtelen, hogy ezeknek a változásoknak közvetve van hatása a PC-s játékpiacra, hiszen az AMD azt mondja, hogy biztosítunk minden leírást és lehetőséget, hogy a programhoz jól optimalizált effektek és post-process futószalagok születhessenek, míg az NV azt mondja, hogy nem adunk semmit, de ne is fejlesszetek saját megoldást, hanem használjátok az általános effektjeinket. Mindkettőre van igény csak más kiadói és fejlesztői csoportok által. Az viszont már most látszik, hogy az AMD megoldásával lehet a minőséget, míg az NV-ével az egyszerűséget célozni. Persze ez várható volt. A különböző általános middleware-eknél a mélyen integrált eljárások mindig gyorsabban és jobb minőségben működtek, mert ezeket specifikusan lehet fejleszteni, míg az általános eljárások beépítése korlátokkal jár, vagy a sebesség, vagy a minőség, vagy mindkét szempontból.
Az, hogy átkozzák-e a döntést? Ezeket a döntéseket évekkel korábban hozták meg és pontosan tudták, hogy mik a következményeik. Mindkét cég tudta a maga irányával, hogy az EA, a Square Enix, a Capcom, és más nagyobb kiadó az AMD-hez fog húzni, mert saját maguk fejlesztik a technikáikat, így nekik jól dokumentált rendszerek kellenek leginkább middleware-ek nélkül, mert mindent megírnak maguk. Azt is tudták, hogy az NVIDIA kedveltebb lesz például a kisebb fejlesztőknél, vagy a PC-vel nem törődő kiadóknál, ahol szimplán nincs meg az anyagi keret, arra hogy saját eljárásokat fejlesszenek, vagy szimplán nem kifizetődő a PC-t figyelembe venni a kevés eladás miatt. Itt hiába van meg a jól dokumentált rendszer, muszáj xy middleware-t elővenniük, mivel ez így is olcsóbb, mint a saját fejlesztés.
Én személy szerint úgy gondoltam, hogy ebből csak baj lehet a PC-n, de valójában meglepő, hogy mennyire alkalmazkodtak az eltérő irányokhoz a fejlesztők. Eldöntötték, hogy kivel tartanak, kinek a koncepciójával tudnak jobbak lenni, és annak a cégnek a hardvereit ajánlják. Átrendeződtek a fejlesztői nézetek, de a PC-s játékpiac feltalálta magát.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
daveoff
#13385
üzenetére
A cloud gaming az tényleg működő modell, de valójában az üzleti részét sokkal jobban ki kell majd dolgozni. Az NV-nek ebből akkor lenne igazán komoly eredménye, ha megegyezne a tévégyártókkal. A Sony is úgy tartja fent a szervereit, hogy a PlayStation Now szolgáltatást a Samsung egyes okostévéin is elérhetővé teszik. Ha ezt nem lépnék meg, akkor több veszteséget termelne. Most azon kell dolgozniuk, hogy a többi tévégyártó is jöjjön. Ugyanez kell a GRID-nek is, mivel túl kevés lesz a Shield Console eladása ahhoz, hogy a szervereket fenntartsák.
A Sony felhője például évi egymillió aktív előfizetéssel válik nyereségessé. Nagyjából ennyi kellene az NV-nek is, vagy több, mert a Sony felhője azért drágább. Amíg ez nem jön össze addig ez egy masszív veszteség, ahogy a Sony-nak is az ma még (persze még nincs felkapcsolva minden, de a pénz a kiépítésben benne áll).Az üzemköltségek a modernizálással, és a szoftveres újításokkal csökkenthetők a jövőben, szóval a felhő reális elképzelés lehet, de úgy kell beleugrani, hogy nagyjából két év az átfutási idő, amíg önmagában nyereségessé válik. Az eddigi felhős koncepciók sorra itt buktak el, egyszerűen a két éves tervben sem váltak nyereségessé, és lelőtték a cuccot.
Sokkal realistább egyébként a Microsoft tervezet, amelyben egy már működő Azure felhőbe raknák bele a felhős játék képességét, tehát sokkal szabadabb lehetne az árszabás, mert maga a játék része akár veszteséges is lehet, ha a munkára való teljesítménybérlés része nyereséges. És egy idő után ez kinövi magát.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A Hynix választotta ki a partnerét, de valójában több jelentkező volt. Azért amellett, hogy a HBM fejlesztést az egy gyártóra való lekorlátozás segíti, a többi gyártónak hátrányt okoz, mivel nagyjából egy éves kutatási hátrányba kerülnek. Nem véletlen, hogy az Intel a Hynix döntése után megerősítette a szerződését a Micronnal. Hiába jobb a HBM, ha az AMD már rég tömegesen gyártja a termékét, amikor a többiek még javában tesztelik az interposerüket.
Kérdés, hogy mit tekintesz vonzónak. A sebességet, vagy a dobozra írt számokat. HBM-mel biztos gyorsabb lenne, még 4 GB memóriával is.Ja értem, tehát azért mondtak le éves szinten gépenként 100 dolláros bevételről, mert szerintük jobban megéri, ha előállnak egy saját konzollal. Végülis, ha kiszámoljuk a matekot, akkor az XO-ból és a PS4-ből éves szinten eladnak nagyjából összesen 12-14 milliót. Az NV viszont úgy döntött, hogy nekik egy olyan konzol kell, amiből éves szinten a legjobb esetben is félmilliót lehet eladni. Logikus döntés.
Ja tetemes. Mert a DX12-höz aztán lesznek driverek ... A DX12 egy explicit API. Ahhoz csak shader fordító lesz, ami mindenkinek van és semmi fejlesztést nem igényel. Ami eddig a driverben volt az az alkalmazásban lesz. Zéró lehetősége van a gyártóknak befolyásolni az alkalmazást. Drivert sem kell fejleszteniük, mert úgy sem nem látják mi van a videomemóriában. Ezekkel az API-kkal az számít, hogy az alkalmazás hogyan kezeli a GPU architektúrákat és azok verzióit.
Elárulom, hogy a Tonga GPU-ban van ma a leghatékonyabb DCC. Az kb. 40%-os hatékonyságú, míg a GM206/GM204-é kb. 33%. Persze ez a gyakorlatban nem annyira lényeges, de az egyértelműen merész állítás, hogy a Fiji-ben a Tonga DCC-je nem lesz benne.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
VR, 4K, 3x4K, 5x4K, 8K? (ezzel kapcsolatban szkeptikus vagyok, de miért ne
![;]](//cdn.rios.hu/dl/s/v1.gif)
), és innen akkor 3x8K, 5x8K ... Szóval a kraft kell, csak mostantól nem Full HD-re veszed. Nem nehéz elképzelni, hogy az évtized végére a 4K annyira alap felbontás lesz, mint ma a Full HD.
Hohoho... és még miket nem láthattál a GDC zárt részéről (11 fps-ről -> 125 fps-re csak a DX11->DX12 váltással, persze meg nem jelent hardvereken, de működik).A nagyszerű hír, hogy az API-k változásával egészen másképp nézhetünk majd a hardverekre. Nem véletlenül ad majd ki az AMD egy low-level API-k programozására vonatkozó 450 oldalas könyvet még márciusban. Mert az aktuális könyvekben leírtak nem igazán helytállóak az új API-kkal. El kell felejteni ezeket. Graham Sellers is ígérte, hogy hamarosan megírja a könyvét a Vulkan API-hoz. Ez lesz a Khronos hivatalosan ajánlott könyve. Addig, amíg ez meg nem jelenik az AMD könyvét ajánlják.
Nagyon sok részlet van az érkező könyvben arról, hogy mit kell máshogy csinálni, mint régebben és, hogy ez milyen előnyöket hoz. A végeredményben az új API-khoz írt motorok teljesen másképp fognak működni, mint az aktuálisak, kivéve a Nitrous, mert az már az új API-khoz készült az alapjaiban is (talán ezt másolják le, mert ez tényleg nagyon működik). És, hogy ez mit hoz? A Nitrous filmes minőségű motion blurt támogat, nem post-process fost. Be lesz építve a motorba egy 36x-os temporális MSAA, olyan amilyet az animációs filmekben használnak, vagy például a CGI effektekhez. És még van egy nagyon komoly nyalánkságuk az árnyékokra, de azt még nem mutatták meg. Az SSAO, és az erre épülő post-process alternatívák mehetnek a picsába. Jöhet helyettük az Obscurance Fields (pár játék már ma használja - a Sniper Elite 3 és a The Last of Us) és valami multi-view SSDO extrának (erre a hardverekben ott a sok TFLOPS és az aszinkron compute-tal ki is használható).Azt azért ki kell emelni, hogy a mai motorok komplexek. Ezekben sokszázezer vagy millió dolláros pénz áll (ha hosszú távon nézzük a fejlesztés, hiszen bizonyos motorok alapjai 10 évesek). Az alapvetően jó, hogy itt a konzolgeneráció, mert általában ilyenkor szeretnek a kiadók jobban költeni, mert most leraknak egy jó és új alapot és arra jó esetében a konzol életciklusának végéig lehet építeni, ami azért 10 év, tehát egy ilyen beruházás abszolút megéri (a nagy kiadók éves szinten 4-6 játékkal is számolnak). Ezt a szelet az új API-kkal simán kifoghatja a PC is, mert például pont jó lesz nekünk az a technika, amit a konzolról portolnak PC-re, a munkát pedig segítik az érkező könyvek. A fejlesztőknek viszont kell némi idő, amíg írnak új, vagy alaposan felújított motorokat. Az nagyon jó dolog, hogy a mostani GDC-n letisztult a terep. Lehet választani a Vulkan és a DirectX 12 között. Valaki mindkettőt támogatni fogja, míg szerintem lesz olyan, aki csak a Vulkanra megy. Az EA technikai vezetője már utalt rá, hogy ezzel az API-val több operációs rendszert érnek el, és a Windows 10-hez is jó, míg az előnyei ugyanazok. Gondolom Johan Andersson is ezért tűnt fel a Khronos előadásán. Logikus döntés lehet. A Vulkan egyetlen gondja, hogy nem támogatja a HLSL-t, és nagyon sok kódjuk a stúdióknak ebben van, de az EA már régóta fejleszti a saját shader nyelvét, amihez simán írhatnak SPIR-V-re fordító réteget. A Vulkan ezt megengedi, ezért is lehet jobb, mint a DX12-t, mert sokkal nagyobb programozói szabadságot ad. A GLSL-t nem látom úgy, hogy komoly terjedésbe kezdeni, de SPIR-V-nek ez csak egy kompatibilitási irányzata, ha a fejlesztő akarja, akkor írhatja a shadert OpenCL C++-ban, vagy akár SYCL-ben is. Ezek sokkal jobbak, mint a HLSL, de az ultimate megoldás tényleg a saját shader nyelv. Akinek erre van pénze (nyilván az EA-nek van), az erre fog menni.
Azt nem tartom egyébként kizártnak, hogy a nagy és a kis stúdiók között növekszik majd a szakadék. A kicsiknek egyszerűen nincs erőforrások gyorsan lereagálni ennyi újítást. Amit az ipar az elmúlt 5 évben elfelejtett fejleszteni, azt most rázúdítják a piacra gyakorlatilag egy éven belül. Ilyen mértékű változáshoz csak a nagy kiadóknak elég vastag pénztárcája. Az látszik, hogy az EA koncentrál a leginkább erre az irányra, így azt sem tartom kizártnak, hogy ők technikailag mindenkihez képest elhúznak. Ebből a szempontból nyilván nem szerencsés, ami történik. Sokkal jobb lett volna a kisebb fejlesztőknek, ha szépen fokozatosan fejlődik a piac, úgy nem egyszerre kellene ugraniuk legalább tíz lépcsőfokot.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Jack@l
#13373
üzenetére
Persze. 2014 elején csak 20 oldalas sajtóanyagot adtak körbe arról, hogy erre miért nincs szükség. De aztán jött a GDC és minden megváltozott.
Ismerd fel a szarkazmust a HBM-es mondatomban. Azért írtam, mert addig semmi semmilyen irány nem jó, amíg az NV nem támogatja. Aztán hirtelen minden irány jó lesz.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem ők döntötték el. A Hynix választotta ki, hogy kivel dolgozik.
Persze lehet mindenre azt mondani, hogy őket nem érdekli.
Ott voltak a konzolok. 2013 végén azt mondták, hogy nem jó piac ez, de a héten bejelentettek egy konzolt.
Ott volt a Mantle. 2013 végén azt mondták, hogy erre az irányra nincs szükség, de a DX12 bejelentésével már mellette érveltek.
Most pedig a HBM. Gondoltuk, hogy nem kell nekik ez, de azért a Pascalt HBM-re tervezik.A DCC-ről pedig úgy beszélsz, mintha az AMD-nek ilyenje legalább akkora hatékonysággal nem lenne.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#13368
Abu85
HÁZIGAZDA
#Morcosmedve
#13365
Abu85
HÁZIGAZDA
válasz
#Morcosmedve
#13365
üzenetére
Ez nem szokás szerinti dolog. A HBM bonyolult és a Hynix úgy határozott, hogy az első generációs fejlesztést csak egy céggel fejezik be. Mivel az AMD-nek volt a legtöbb tapasztalata, így őket választották. A többiek a második generációnál jönnek, amikor már a Hynix is tapasztaltabb lesz.
Valószínűleg az NVIDIA is elvállalta volna, hiszen úgy nekik lenne sokkal több tapasztalatuk a többieknél. Ez csak így alakult.
Ugyanez az API-knál is. Nehezen hihető, hogy az NV-nél azt mondják, hogy határozza csak meg nyugodtan az AMD az elkövetkező fél évtized technológiai irányát. Egyszerűen ez is csak így alakult.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Itt van, amit lehet tudni róla. [link] - egész részletes.
--- Más:
Az Assetto Corsa esetében valószínűleg az játszik be, hogy az 1.0-s verzióig nem engedélyezték az összes optimalizálást. Ez jellemző dolog, mert nem biztos, hogy stabil a kód. Egyébként nyilván a sávszél számít egy tele post-processelt, full deferred shading motorral, manapság ezt már nem szokták alkalmazni, pont azért, mert zabálja a sávszélt. Azt nem tudom, hogy miért ilyen leképzőt választottak, amikor ma már vannak sávszélkímélő tiled vagy clustered megoldások
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Valószínűleg nekik sokkal több tesztjük van az olyan új generációs motorokról, mint a Nitrous, az új Frostbite, az új CryEngine, vagy a Dawn Engine, amit nagyrészt ők építettek fel. Ez alapján reálisnak érezhetik, hogy a memsávszél legyen 500 GB/s fölött. Meg azt se felejtsük el, hogy a Fiji nagyjából 8 TFLOPS-os GPU, azért ezt etetni kell.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem összehasonlítható a dolog a mai szinttel. A HBM működéséből eredően a széles memóriabuszra gyúr. Egy HBM memóriát 1024 biten lehet bekötni, és mivel 4 GB lesz rajta, ezért 4 HBM memória kell, ami 4096 biten van bekötve. Ha 8 HBM memóriát kezel egy lapka, akkor 8192 bites a memóriabusz, és így tovább.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#13293
Abu85
HÁZIGAZDA
TESCO-Zsömle
#13292
Abu85
HÁZIGAZDA
válasz
TESCO-Zsömle
#13292
üzenetére
Sőt, 4-5 év is. Pontosan ez az oka annak, amiért az AMD nem akarja követni a szabványosítási procedúrákat, mivel nagyon sokáig tartanak. Helyette elérhetővé teszik a saját megoldásaikat, amit aztán majd a szabványok idővel lemásolnak. A lényeg, hogy a fejlesztők aktuális problémáit gyorsan meg lehessen oldani, és a megoldás irányt mutasson a Microsoft és a Khronos számára. Ebből a teljes iparág profitál. Lásd jön a DX12 és az új OpenGL is, nagyjából arra a mintára, ami az AMD API-jában megjelent.
Távolról se higgyük azt, hogy az új API-k minden gondot megoldanak. Adnak egy jó alapot, amire lehet építkezni, és jönnek a következő újítások, amelyekre szintén jön szabvány, ami egy új alap lesz, amire ismét lehet építkezni, és így tovább.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Túl hardvercentrikusan közelítitek meg a kérdést. Idén is sokkal több változás lesz szoftveres oldalon, mint a hardverben. Persze jönnek új lapkák, de az igazi innováció nem itt lesz.
Csak mondok egy példát. Ma a játékokban a GPU-kat a HLSL-en programozzák. Ez a szabvány nyelv a shaderekre, de nem elég jó már.
Nyilván egy ideig még erre leszünk szorítva, ami részben alap a szabványosságnak, de már rengeteg kutatás megy arra, hogy a HLSL mellett legyen más alternatíva.Ha megnézitek az API-kat, akkor ma három lehetőség van: HLSL (DX), GLSL (OGL) és AMDIL (Mantle). A HLSL oké, az egy jó alap, míg a GLSL nem a legjobb, de csak azért, mert nincs referenciafordító az OGL-ben. Az AMDIL nyilván azért gáz, mert eléggé alacsony szintű, így erre csak nagyon kritikus esetben érdemes direkt kódot írni. Van azonban egy nagyon érdekes kutatás, hogy ne kössük a lehetőségeket feltétlenül egy shader nyelvhez. Ha valaki mondjuk C++-ban akar shadert írni, akkor írjon. És innen egy frontend fordíthat egy hardver közeli IL-re, amiből mehet a kód a hardverre. Ebben az irányban óriási lehetőségek rejlenek, mert az eddigieknél jóval komplexebb programok is futtathatók lesznek a GPU-n, illetve a HLSL korlátjai is mehetnek a levesbe.
Maga a modell prototípus szinten nagyon működik. A Nitrousban számos shader így van lekódolva, és a GDC-n mutatnak majd egy demót, ami megalázóan jó. A probléma viszont, hogy a magas szintű kód (ami jelen esetben Bolt C++) és a hardverközeli IL-ek között nincs egységesítés. A programba kell egy fordító frontend, ami fordít AMDIL-re, PTX-re, és az Intel, meg a többi gyártó vISA-jára. Ez működik csak jó fordítót nagyon nehéz írni, és időigényes is. Sokkal kedvezőbb lenne, ha minden gyártó ugyanazt a vISA-t használná, és akkor arra lehetne készíteni egy agyonoptimalizált frontendet, vagy akár használni a Clanget, és az LLVM-en keresztül elérhető például a HSAIL.
Az nagyon látszik, hogy kezdjük kinőni a HLSL-t, és egyre többen kacsintgatnak a C++ felé.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Crytek
#13184
üzenetére
A saját tabletet azért csinálták, mert az egy módosított Android és benne van az OpenGL 4.4, tehát nem OpenGL ES. Ez azért haladás számukra, csak más gyártót ez az irány nem érdekli, mert OpenGL 4.4-es alkalmazás nem kerülhet fel a Google Play-re. Egyébként ott van az NV_command_list kiterjesztés is. Igaz, hogy nem kompatibilis az OpenGL core specifikációval, illetve nem mobilba tervezték, hanem a professional piacnak, de használható, csak sokkal nehezebb lesz meggyőzni a fejlesztőket, mert egy Metal API-t olcsó támogatni, de egy OpenGL kiterjesztést, ami még a core specifikációkkal sem kompatibilis nem sokan vállalnának be, hacsak nincs nyomós indok rá.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Crytek
#13180
üzenetére
Nyilvánvaló, hogy tudnak a problémákról, azt is tudják, hogyan kell egy API-t írni. Viszont szerintem nem sokan gondolták ebben az iparágban, hogy lesz két cég, amelyek nem várnak Microsoft, Khronos, meg akárkire, hanem a saját kezükbe veszik a sorsukat. Ha visszautazhatna számos cég 5 évet az időben, akkor ma nekik is saját API-juk lenne. Viszont akkor úgy gondolták, hogy túl kockázatos a projekt és senki sem fogja meglépni.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
WCCFtech is jó? 
![;]](http://cdn.rios.hu/dl/s/v1.gif)
), és innen akkor 3x8K, 5x8K ... Szóval a kraft kell, csak mostantól nem Full HD-re veszed. Nem nehéz elképzelni, hogy az évtized végére a 4K annyira alap felbontás lesz, mint ma a Full HD.
Ú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!
MIELŐTT LINKELNÉL VAGY KÉRDEZNÉL, MINDIG OLVASS KICSIT VISSZA!!
A topik témája:
Az NVIDIA éppen érkező, vagy jövőbeni új grafikus processzorainak kivesézése, lehetőleg minél inkább szakmai keretek között maradva. Architektúra, esélylatolgatás, érdekességek, spekulációk, stb.
Állásajánlatok
Cég: Axon Labs Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest