-
GAMEPOD.hu
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
Valójában csak a NYÁK egyezik. A komponensek mások. A RAS miatt az instinct más követelményeket teljesít, mert itt feladatkritikusnak kell lenni, míg a Radeon VII-nél ez nem igény, hogy évekig leállás és probléma nélkül működjön.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#40325
Abu85
HÁZIGAZDA
Petykemano
#40324
Abu85
HÁZIGAZDA
válasz
Petykemano
#40324
üzenetére
Nem különleges hardver a konzol, csak más. A Microsoft és a Sony ragaszkodik a saját IP-ihez. Az AMD-nek pedig igazából mindegy. Felőlük rendelhetik a Navit is, csak abba nem tudják belerakni az egyedi kéréseket. Ugye a Sony és a Microsoft nem rendelkezik egymás licenceivel.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az AMD-t nem érdekli igazából, hogy milyen gondok vannak szoftveres szinten, amitől a VRAM nem használható hatékonyan. Nekik a Vega óta van hardveres memóriamenedzsmentjük. Egy sorral lehet kezelni ezt a problémát a hardvereiket, vagy ha erre is képtelenek a fejlesztők, akkor a driverben bekapcsolható a HBCC szegmens, és konfigurálható a mérete is. Szóval a Vega esetében, ha egy program kér mondjuk 16 GB-ot, akkor annyit kell tenni userként, hogy megnyitod a Radeon Settings programot, 16 GB-ra húzod, majd alkalmazod, és máris 16 GB-osnak látja minden program az amúgy 8 GB-os VGA-d. Ezt egészen 64 GB-ig meg tudod tenni.
(#40332) Ribi: Az teljesen driveres tényező. Az AMD és az NVIDIA eltérően menedzseli szoftveresen a memóriát. Az AMD DX11-ben is egy nagy 7,75 GB-os szeletként használja (plusz 256 MB-os gyorsítószelet), míg az NVIDIA 8 darab 1 GB-os szeletként. 8 darab 1 GB-os kiosztás esetében gyorsabban fragmentálhatók a szeletek, tehát hiába van összességében ugyanannyi VRAM, hamarabb elfogy. Ez tisztán szoftveres probléma, nem a hardver tehet róla.
A Far Cry 5-höz adtak ki textúracsomagot. Azt nem szokás a tesztekben telepíteni, mert nagyon megnöveli ám a játék VRAM-igényét. Itt telepítve volt, ezért más a frame-time.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem így működik a játékvásárlás. Ezek külön szerződések, amelyek mennyiségi licencre vonatkoznak. A tipikus licencköltség 2-6 dollár per játék. Általában fél-egymillió kódot szoktak venni. Tehát se az AMD, se az NV nem fizeti a teljes játék árát. Az EA szokott nagy költséggel dolgozni, ők nem igazán mennek ~20 dollár per játék alá, de ők sem fizettetik a teljes árat.
Az is nagyon számít egyébként, hogy milyen a kiadóval kötött partnerszerződés is. Ha csak reklámszintű, akkor általában az ár nagyobb, mert lényegében a kapcsolat csak üzleti jellegű. Van azonban komolyabb szerződés is, például R&D vállalásokkal, és ott már azért lényeges engedmények is vannak, hiszen a gyártó végzi az R&D egy részét, ami éves szinten egy nagyobb kiadónál simán van 10-15 millió dollár.Keresnek amúgy az RX 570-en még. A GlobalFoundries ugyan idén már nem take-or-pay jellegű szerződéssel dolgozik, de fix waferárakkal, amelyek a TSMC waferáraihoz képest lényegesen alacsonyabbak. Ezért ragaszkodtak a GlobalFoundries technológiájához igen sokáig, mert lényegesen olcsóbban tudják elérni, mint a TSMC-ét.
Az NVIDIA is azért árazza a GTX 16-os sorozatot ilyen drágán, mert a kisebb Pascalokkal ellentétben ezek már nem a Samsungnál készülnek, hanem a TSMC-nél. A PC Partnertől tudom, hogy a TSMC 1x nm-es waferárai a Samsung 1x nm-es áraihoz képest majdnem négyszeresek. Tehát egy egységnyi méretű lapka legyártása majdnem négyszer drágább. És akkor a Samsung sem dolgozik az NV-nek fix szerződéssel, mint az AMD a GloFo esetében, tehát ennél még lehetne jobb árakat is kialkudni, csak az NV inkább flexibilitást akart. Értsd úgy, hogy menni akartak, ha az jobb. Az AMD például csak 7 nm-re ugorhat, de ha 12/14 nm-es lapka gyártásáról van szó, akkor azt a GloFo nem engedi máshol. Cserébe rohadt olcsón adja nekik a wafert.
A TSMC ilyeneket eleve nem csinál. Az viszi a kapacitás, aki a legtöbbet fizeti. Nekik nincs szükségük fix megrendelőre, mert sorban állnak a várakozók.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem. Az AMD és az NV úgy dolgozik, hogy van egy büdzsé az egész évre. Ebbe beletartozik a fejlesztői segítség, a szoftvercsomagok fejlesztése, illetve a reklámpénz. Ebből a büdzséből költenek mindketten. Tehát a valóságban már egy eleve betervezett éves költséget költik, amikor játékot vesznek a VGA-khoz. 20-25 dollárnyi játék egyébként nagyon sok. Főleg úgy, hogy az AMD-nek az Ubisoft és a Capcom esetében is R&D szerződése van, vagyis nem csak reklám, hanem egy rakás dolgot a PC-s porthoz tartozó R&D-nél nem az Ubisoft és a Capcom végez, hanem az AMD. Ugye az EA-vel ezért bontottak szerződést, mert berendezkedtek erre az R&D koncepcióra, de az EA-nek erre nincs szüksége. Megvan a saját anyagi forrásuk arra, hogy mindent elvégezzenek, amit az AMD fel tud kínálni. Az Ubisoft és a Capcom viszont költségkímélőbbnek érzi, ha ezt részben az AMD csinálja. Cserébe adnak nekik egy csomó olcsó kulcsot. De ez abszolút kifizetődő, hiszen az R&D költségek jóval nagyobbak, mint a kulcsok ára összesen. Másképp nem érné meg az Ubisoft és a Capcom számára ez az üzlet. Lesz majd a Borderlands 3, amit szintén berendelt magának az AMD, és az tuti drága lesz, mert ott a stúdióval van szerződésük, míg a kiadóval nem, tehát ott már nem ússzák meg 2-6 dollár/game-ből. Inkább 15 dollár/game lesz, talán még több.
Az RX 560 nagyon régen jelent meg, azóta az AMD és a GloFo kétszer újratárgyalta a szerződését. Alapvetően itt a GloFo van kényszerhelyzetben, mert fontos nekik az AMD megtartása. Ha mennek, akkor dollármilliókat fognak bukni naponta, hiszen a gyárak legnagyobb ellensége a kihasználatlanság. Emiatt a fő megrendelő megtartása úgy is kritikus, hogy nagyon olcsón adják a wafert. Ezt használja ki az AMD, amikor újratárgyalják a szerződést. Ezért jobb a TSMC üzleti modellje, mert ott nem egy megrendelőtől függ a működés. A GloFo azért nem tud igazán élni ezen a piacon, mert egy nagy megrendelőjük van, és emiatt a megrendelőnél pattog a labda, ha meg kell egyezni. Ezért voltak olyan tényezők a szerződésben, hogy ha az AMD mással is gyártat, akkor a GloFo felé büntetést kell fizetnie. 12/14 nm-re ez a kikötés még mindig él, viszont ilyen szinten a megrendelő elvárja, hogy marha olcsó legyen ám a wafer, annyira, amennyire más megközelítőleg sem adja. Ha ez nem teljesül, akkor inkább kifizetik a büntetést, és mennek máshova, aztán a GloFo nagy kerek szemekkel arra ébred egy nap, hogy le kell állítani a Fab 8-at, ami elkezdi veszettül égetni a pénzt. Ugyanez volt a gondja az IBM-nek, és ezért adták el úgy a gyáraikat, hogy még ők fizettek a vevőnek, hogy megvegye. Minden nap dollármilliókat buktak kihasználatlanság miatt.
Szóval ez a gyártás dolog nem úgy működik, ahogy azt elképzeli egy átlagember a mezei kereskedelmi tapasztalataiból.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Sose volt olyan drága gyártani, ahogy a táblázat írja. Ilyen árakon 50%-kal nagyobb lett volna a vételár.
Amit igazából sose vesznek figyelembe ezek a fantasztikus elemzések, hogy az AMD és az NV sosem lapka szintjén fizet a bérgyártónak. De még csak nem is a GPU-k szintjén. Wafereket vesznek, aztán a bérgyártó magasról tesz arra, hogy a kibérelt kapacitáson mi készül. Összességében tehát nem az számít az AMD-nek és az NV-nek, hogy egy-két GPU-ra legyen meg a haszon, hanem arra a több tucat termékre, amit gyártanak, legyen meg a pozitív mérleg. Más nem is igazán számolnak, mert alapvetően megveszik a wafert x összegért, gyártják rajta a lapkákat a piac igényétől függő mennyiségben, és a végeredményt nézik csak. Ez a legfőbb oka annak, amiért az NV nem igazán akar a TSMC-nél maradni, mert el kellene kezdeniük licitálni az AMD és az Apple ellen, akik biztos, hogy árban föléjük tudnak menni. Nem azért, mert egy-egy lapkát kedvezőbben gyártanak, hanem mert van olyan termékük, amelyet a gyártási költség sokszorosáért adnak. Az Apple marha drágán kínálja az iPhone-okat, miközben a lapka pici bele, így belefér, ha egységnyi szinten akár 50 dollár fölött költenek rá. Az AMD-nek pedig ott a CPU, ahol a gyártási költség az eladási árhoz képest sokkal alacsonyabb. És az AMD mondhatja azt, hogy a 7 nm-en a GPU-kra inkább nem akar hasznot, nem számít, mert a CPU-kkal magasan pozitívban lesz a teljes mérleg. Az NV ezt nem mondhatja, mert nincs olyan nagy volumenben eladott hardverük, ami ellensúlyozná ezeket, tehát nekik muszáj olyan bérgyártói szerződés után nézni, ahol a GPU-kon keresnek. Ezért erősödnek a Samsungra vonatkozó pletykák.
A 7 nm-rel a gyártási árak növekedni fognak, de igazából a piac is kezd berendezkedni rá az új árszabással.
A régi node-ok sokkal kellemesebbek, mert sokkal olcsóbb volt rájuk kihozni egy lapkát. Főleg akkor, ha az nem a TSMC-nél készült, hanem esetleg egy take-or-pay szerződéssel született, amikor azért a waferár igen alacsony tud lenni. Emiatt lehet levinni a GloFo és a Samsung által gyártott GPU-knál a VGA-k árát. Amit az NV a TSMC-nél gyárt, azt már látod, hogy drága, például a 16-os GeForce sorozat. Nem tudnak vele mit kezdeni, mert ugyanazért a waferért a sokszoros pénzt fizetnek, a Samsunghoz viszonyítva. Ha az AMD is a TSMC-nél gyártana, akkor ők se vinnék le 130 dollárra az RX 570-et, nem férne bele a sokszoros waferár mellett.
Mert a kulcsokat nem így rendelik. Nem az van, hogy eladnak egy VGA-t, és fizetnek 25 dollárt. Van egy fix éves büdzsé erre fenntartva az AMD-nél és az NV-nél is, amit már eleve úgy számolnak, hogy elköltik. Ha nem kulcsokra, akkor reklámszerződésre, stb. Tehát ez egy már bekalkulált éves veszteség, amit bőven ellensúlyoz a nyereség, amit hoz. Másképp egyik gyártó se csinálná.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Felhős játékhoz a Radeon Pro V340 van. Messze ez a legjobb ide. A Radeon VII nem ide való, illetve az Instinct MI50 és MI60 sem, mert ezek RAS megoldások. Cloud gamingre pedig felesleges a RAS-t megfizetni.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
#82819712
#40540
üzenetére
Nem tudom, hogy milyen az új pipeline. Annyit tudtam csak meg, hogy nincs VS és GS. Tekintve, hogy a hardver eleve unified shader, így csak hardverállapot különböző lépcsőket tervezni. Ez csak később derül ki.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#40555
Abu85
HÁZIGAZDA
Petykemano
#40545
Abu85
HÁZIGAZDA
válasz
Petykemano
#40545
üzenetére
Na most, ha a Google a Stadiát komolyan gondolja, akkor el kell kezdeni építeni a nagyjából 7000 peremhálózati szerverükre a hardvert. Jelenleg csak pár százzal vannak kész, tehát brutális mennyiségű peremhálózat van még GPU nélkül. Ide kellenek olyan megoldások, mint a Navi, mert a V340-nél jobb hatékonysággal működik. Az ár itt mindegy, még ha drágább, akkor is megéri, mert üzemeltetés szintjén hetek alatt visszahozza az árát, és másfél évig minimum működik. Tehát effektíve nem a vételárat nézik, hanem a másfél éves megtérülést.
Később nyilván a V340-eket is lecserélik, de most ezek kellenek a fejlesztőknek.
Szerverbe az AMD nem kliensekbe szánt VGA-kat fog adni, de mivel a Google nagy megrendelő, így nekik nem kell megvárni a fejlesztés alatt álló Radeon Pro megoldásokat, hanem szállítja nekik az AMD idő előtt. Ezért cserébe sokat fizetnek.
[ 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
#82819712
#40607
üzenetére
A Google eleve kevés peremhálózati szerverbe rakott még GPU-t. Azt a 7000-et nem egy hónap alatt fogják feltölteni, hanem inkább egy év alatt. Valószínűleg a V340-eket sem cserélik le még, hiszen azok jól működnek ám, csak ha van Navi, akkor az alacsonyabb üzemeltetési költséggel beépíthető, márpedig a Stadia esetében ez a lényeg. Főleg úgy, hogy 7000 szervert kell megtölteni GPU-kkal. De ez nem egyik napról a másikra lesz.
Az is lényeges, hogy a Google az nagy megrendelő. Az AMD simán csinál nekik olyan hardvert bármiből, amire igényük van. Nem egy nagy mérnöki munka egy NYÁK-ra két Navit rakni.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#40621
Abu85
HÁZIGAZDA
Petykemano
#40620
Abu85
HÁZIGAZDA
válasz
Petykemano
#40620
üzenetére
Ezekben részletezve van a működés. Nem olyan egyszerű, hogy csak így, meg csak úgy, sokkal bonyolultabb. Ezért adtam a két doksit.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A voxel a háromszögek problémájára jelent itt megoldást. A pixelekhez nincs köze. Amúgy a többi stimmel, azt viszont nem zárnám ki, hogy a Microsoft nem vezeti be a voxeleket. A DXR is ugyanúgy fejleszthető, csak nyilván a voxelekhez megint új hardverek kellenek. Na meg az sem ártana, ha minden motor tudna hatékony voxelizálást, de akár erre is hozható lenne valami API, csak ez már nem olyan egyszerű probléma.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#40679
Abu85
HÁZIGAZDA
Petykemano
#40675
Abu85
HÁZIGAZDA
válasz
Petykemano
#40675
üzenetére
Tehát megvizsgálták a hardvereket a régi programokon, miközben a legtöbb mai motor már GPU-driven pipeline. Ügyes.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Eléggé. Az A4 Engine nem lett jelentősen átírva, ezért is fut eléggé gyorsan.
Nm a háromszögről van szó, hanem arról, hogy a GPU felé mennyi adat megy. Egy GPU-driven pipeline motornál már a leképezés előtt ki lesz vágva egy rakás háromszög, amiért compute shaderek felelnek. Ettől még mérheted a GPU-k közötti különbséget a háromszögek terhelése szempontjából, csak a nagy terhelést a culling fogja jelenteni, ami viszont TFLOPS-okat zabál.
(#40683) Petykemano: Eleve az a probléma ezzel, hogy egy rakás új játék wave intrinsics shadereket használ, és ezek még a GCN-en belül sem szabványosak, tehát az lesz a leggyorsabb architektúra, amely a legtöbb intrinsics függvényt kapja a culling kódokon belül. Mindegy, hogy a hardver mit tud elméletben, ha nem ugyanaz a kód fut rajtuk. Szóval jelentősége lesz ezeknek, csak nem a hardvertől fog függni, hanem attól, hogy az egyes GPU-kon milyen nem szabványos optimalizálásokat engedélyeztek.
A szabványosság is para ebből a szempontból, lásd a World War Z-t, ami először csinálja azt, hogy szabványosan elérhető intrinsics függvényeket használ minden hardverre a cullinghoz is. Aztán ez jól megkavarta ám az állóvizet, és nem azért ver a Vega mindent, mert annyira gyors maga a hardver. Szóval a hardver az intrinsics függvények terjedésével, főleg a szabványosokkal nem pont egy egzakt kiindulási pont, mert nagyon sok függ magától a kódtól. Az a hardver lesz a legjobb, amelyiken maga a shader, illetve ennek a fordítása a leghatékonyabban fut, ettől a hardvernek nem kell nyersen a leggyorsabbnak lennie.
[ 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
Raggie
#40686
üzenetére
Az idei explicit API-s felhozatalból szinte mindegyik. De már az előző év végére is ez volt a jellemző. Azért csinálják ezt a fejlesztők, mert az AGS fordítója nagyrészt érti a PSSL shadereket, tehát ezeket nem kell újraírni, hanem van egy konverter, amibe beküldöd, és kiadod HLSL Ext. shaderként, amivel máris tud bánni az AGS valamelyik verziója.
A különbség most annyi lett, hogy a jövőben ezt valószínűleg nem AGS-sel képzeli el a piac, mert az alapvetően csak az AMD-nek előny, de maga a wave terminológia általánosan hasznos. Erre van a shader modell 6 és a Vulkan API-n belül a subgroup shaderek. A shader modell 6-ot még wave terminológiára nem használják, de Vulkan API-ra már ott a World War Z, ami subgroup shadereket is használ. Emiatt kavarodott össze az utóbbiban az erősorrend, mert a subgroup/wave terminológia (ugyanaz mindkettő, csak máshogy hívja a Microsoft és a Khronos) eltérő módon működteti a hardvereket a régi, soros feldolgozáshoz képest. Egészen konkrétan megadja annak a lehetőségét, hogy az egymástól független párhuzamos feladatok bármilyen módban párhuzamosan fussanak a multiprocesszoron belül, és meg tudják osztani egymással az adatokat, legyen szó bármilyen pici feladatról. A korábbi terminológia erre csak compute shaderben adott lehetőséget, és ott is csak a helyi adatmegosztást lehetett használni az adatok megosztására, de csakis a helyi munkacsoportok között, vagyis maga az adatmegosztás durva szemcsézettségű volt.
Látszatra ezek nem tűnnek nagy különbségnek, de valójában azok, mert a hardvernek vannak különböző állapotai, amelyeken belül a multiprocesszor némileg eltérően működik, és nehéz meghatározni, hogy egy ilyen váltásra a korábbi terminológiához tervezett hardverek hogyan reagálnak. Maga az architektúra fejlődik az AMD és az NV dizájnjaiban, de az ISA tekintetében az alap az AMD-nél még az öreg GCN, míg az NV-nél a szintén öreg Fermi, tehát amikor ezeket tervezték 2010-nél korábban, akkor nem nagyon volt szempont, hogy 2019-re mennyire változik meg a shader modell. Ezt igazán lekövetni új ISA-val lehet, de mivel a hardveres szálkezelés tekintetében még mindig nincs ott a GCN és a Fermi, hogy a limitek erősen látszódjanak, így egy darabig nem valószínű, hogy az AMD és az NV vált. 2020 után tuti, de az még később van.
DirectX 12-re támogatást lehet írni egy eredetileg DirectX 9-re tervezett játékra is. Nem éri meg, de ettől lehetséges. A régebbi leképezők alapvetően tudnak működni nagyon sok API-n. Vannak bizonyos leképezők, ahol már nagy hasznot hoz mondjuk a DirectX 11, vagy a 12. Előbbire tipikus példa szokott lenni a compute cullingos megoldások, amikor valami problémát compute shadereken keresztüli kivágással kezelsz, míg utóbbi leginkább akkor hasznos, ha maga az árnyalás a jelenet szintjén történik, és nem a fragmentek szintjén, ez ugyanis jelentősen növeli a rajzolási parancsok számát, hiszen már nem lesz erősen limitált a shadow casting fényforrások száma sem, és rengeteg effekt szimplán a jelenet szintjén megoldható, egyszerűen csak másolod az árnyalt objektumokat. Annyiszor tudod ezeket megjeleníteni, amennyi rajzolási parancsot költesz rá, a hardver csak egyszer számolja ki.(#40687) Raymond: compute-based triangle filtering
(#40688) gbors: A wave/subgroup shadereknél eléggé össze van keverve az erősorrend. Sok múlik a fordítón, illetve azon, hogy az adott program milyen intrinsics függvényeket használ, a 2010 előtt tervezett ISA-k mennyire rugalmasak ebből a szempontból, mert ezeken olyan sokat javítani nem lehet, maximum teljes újratervezéssel. Ezért baj itt tippelgetni, mert a World War Z Vulkan módja ugyan egyértelműen első fecske, de egy rakás olyan tényező van, amit még húsz fecske után sem fogunk igazán ismerni. Tehát a World War Z Vulkan módjából annyi vonható le következtetésként, hogy azokkal a subgroup shaderekkel, amiket a program használ, azokkal a hardverállapotokkal, amelyekben ezeket futtatják a GPU-k, azokkal a fordítókkal, amelyeket a gyártók jelenleg implementálnak, ez a teljesítmény. És a sok tényező miatt nem lehet azt mondani, hogy ez lesz a következő címnél is. Emiatt nehéz erre építeni. Simán lehet, hogy megfordul az egész, mert más kódokat kapnak a hardverek, más hardverállapotokban futtatják azokat, és máshogy fog működni a fordító. Régen ez azért volt sokkal egyszerűbb, mert ha adatmegosztás kellett a feladatok között, akkor arra egy mód volt, és erre a módra ki volt gyúrva a hardver (na jó a hardver nem mindig) és a fordító. Ma nagyon-nagyon sok mód lett erre, és ki tudja, hogy melyik állapotra van kigyúrva az adott hardver, és melyikre fordít hatékony kódot a fordí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
Raymond
#40690
üzenetére
Nem tettem hozzá. Megírtam, hogy miről van szó. Amelyik alkalmazás így működik, ott a legkevésbé a hardver nyers háromszög feldolgozási képessége számít, mert sokkal-sokkal több időt tölt majd azzal a GPU, hogy a nem látható háromszögeket nagy hatékonysággal kivágja a lefutó compute shaderekkel. Jó példa a Deus Ex Mankind Divided. Hiába rendelkezik ez a játék az egyik legtöbb háromszöggel egy jelenetben, a geometriai motorokra rótt terhelés szempontjából mégis kíméletes, mert nagyon sok háromszöget kivágnak a compute culling shaderek a leképezés előtt (bőven a leképezés előtt, vagyis bizonyos shader lépcsők is megmenekülnek a többletterheléstől), így igen kevés felesleges munka lesz a raszterizálás során. Összességében tehát többet ér ennél a programnál a nyers TFLOPS, mert a háromszögekkel való munka nagyobb részét a compute shaderek teszik ki. A raszterizálás előtti nyers háromszögterhelés átlag alatti, annak ellenére is, hogy a végleges geometriai részletesség átlag feletti.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#40699
Abu85
HÁZIGAZDA
Petykemano
#40695
Abu85
HÁZIGAZDA
válasz
Petykemano
#40695
üzenetére
A compute culling már úgy 8 éve bőven velünk van. A háromszögek korábbinál hatékonyabb kivágása nem újdonság, nagyjából 10 éves projektek, amelyeket számos aktuális motor már évek óta támogat (szerintem a mi tesztcsomagunkban is alig van olyan játék, ami nem ilyen). Az más kérdés, hogy vannak akik még nem támogatják, mert nem tekintik kritikusnak azt a geometriai részletességet, amit ezzel el lehet érni.
(#40698) gbors: Mint írtam egyelőre csak a World War Z használ szabványos subgroup shadereket. De azt is leírtam, hogy a terminológia alapvető működése miatt egy játék nem elég a következtetésekhez, talán még húsz sem lesz az. Tényleg nagymértékben befolyásolja a teljesítményt a fordító, valamint az, hogy az adott GPU az adatmegosztásra milyen hardverállapotban kényszerül. A mai multiprocesszorokat arra tervezték, hogy a helyi munkacsoportok között a helyi adatmegosztással megosszák az adatokat a compute shader futtatásához beállított hardverállapottal. A subgroup azt követeli meg, hogy a helyi munkacsoportoknál kisebbeknél is legyen adatmegosztás, akármilyen hardverállapot mellett. A hardver nyilván képes rá, elvégre a compute shader támogatása ezt már lehetővé teszi, csak a hardverállapotok nagymértékben módosítják ám a multiprocesszor működését, amivel erősen javul vagy éppen csökken az adatmegosztás hatékonysága.
És akkor ott a szoftveres kérdés, mert a GPU-t azért lehet ám vezérelni driverből, tehát az se biztos, hogy ahogy ma működik egy GPU, az úgy marad a jövőben. Valszeg az AMD úgy marad, mert ők az AGS-en azt csinálják, hogy stateless lesz minden adatmegosztás, és gondolom ezt használják szabványosan is, de például az NV-nél már sok a kérdés, mert náluk nincs stateless mód. Emiatt még sokat kísérletezhetnek azon, hogy mi a legjobb. Valószínűleg nem az, ami most van, tehát az aktuális driverekkel a hardver még nincs a teljesítménye határán.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem basztam le, csak rávilágítottam, hogy a Frostbite, az AnvilNext, a Snowdrop, a Dunia, a Dawn, a Foundation, az Asura, az id Tech, a Saber, ésatöbbi-ésatöbbi motorok már másképp működnek, mint az elavult feldolgozási formát megvalósító 3DMark, Unigine, Metro, stb. motorjai. Emiatt mások az arányok is egy újabb motorban, már csak azért is, mert a háromszögek feldolgozása részben compute feladattá vált bennü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
Raggie
#40704
üzenetére
A sorrend nem változna, csak a különbségek lennének nagyobbak, mert jelentős szerepet kapna a számítási teljesítmény, hiszen nem a központi processzor, hanem a GPU multiprocesszorai végzik a kivágási munkákat. Ezt nála az összes tesztelt programban a CPU csinálja, míg a mai AAA játékok többségénél már az a jellemző, hogy a GPU van vele terhelve.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#40708
Abu85
HÁZIGAZDA
Petykemano
#40707
Abu85
HÁZIGAZDA
válasz
Petykemano
#40707
üzenetére
Ezért írtam azt, hogy nagyon régiek a leképezők, mert a mai játékok már nem a CPU-n csinálják a cullingot, hanem a GPU-n. Egyszerűen utóbbi sokkal hatékonyabb. Más előnye is van egyébként, mivel GPU-driven pipeline-nal jelentősen csökkenthető a rajzolási parancsok száma. Ez hasznos volt az évtized elején, amikor elkezdték bevezetni ezeket a megoldásokat, míg az újabb API-kban aszinkron compute-ot lehet alkalmazni. Ugye az explicit API-k mellett a rajzolási parancsok száma nem annyira kritikus, de mint írtam majd egy évtizedes megoldásokról van szó, amit régi problémák kezelésére találtak ki. Van amúgy ezeknél hatékonyabb megoldás is, de az a pipeline módosítását igényli, mert le kell cserélni bizonyos shader lépcsőket. Ezekkel a megoldásokkal el lehet engedni a gyeplőt, csak ma még nem hasznosak, mert nincs olyan API, ami támogatja a szükséges grafikus futószalagot. Nyilván később lesz, és hardver is van hozzá, hiszen a Vega és a Turing támogatja ezeket az új shader lépcsőket.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Például arról, hogy ezeknek a hardvereknek a parancsprocesszora eltérő, így mondjuk egy async compute visibility test, ami egy GPU-driver pipeline motornál eléggé tipikus nyilván sokkal jobban fekszik egy újabb dizájnú hardvernek. Ettől a TFLOPS lehet ugyanolyan, csak ahogy a Vega 20-on is látszik. Nagy különbség van parancsprocesszor és parancsprocesszor között.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A parancsprocesszor akkor lényeges, ha limitált általa a GPU. Ilyen akkor fordul elő jellemzően, ha a játék az Xbox One-ról jött, ahol ugye eleve két parancsprocesszor van grafikai munkára, így mások a limitek, mint PC-n. Ha egy játékot már PS4-re is terveznek, akkor ott jellemzően hasonlóak a queue limitek a PC-s hardverekhez.
A Vega 20-nál ennek tényleg nincs igazán lényege, egy-két Microsoft játékot leszámítva. Itt arról volt igazán szó, hogy a Navi parancsprocesszora hamar kész lett, és azt rakták bele. Ennyi. Ez azért hasznos, mert így a régi parancsprocesszort nem kell 7 nm-re portolni, hanem elég a már leportolt fizikai IP-t felhasználni. Szimpla költségcsökkentés.
Aszinkron compute-ban pedig nyilván jobb egy Polaris, mint egy GCN2 vagy GCN3. Nem sokkal, de jobb, és emiatt nyílik szét az olló.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Én nem akarok árulkodni, de a World War Z-ben a Vega 56 még a 2080-at is veri, ráadásul utóbbi azzal a driverrel futott, ami +18%-ot hozott rajta. Ezzel a driverrel egyébként a 2080 Ti elkapja a Vega 64-et. De ahogy korábban is írtam, a subgroup egy kellemetlen dolog, mert nagyon sok tényezőtől függ, tehát nem lehet kiindulni az első fecskéből, de még a sokadikból sem.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem. A WWZ csak az első játék, ami használ subgroup shadereket. Mindig van egy első fecske. Aztán követik a többiek. Itt most kellene még példa, mert a subgroup nem egy nagyon specifikus újítás, hanem eléggé általános. Tehát a hatása sem specifikus, hanem a használattól függő, elvégre alapvetően megváltoztatja, hogy egy shader miképpen futhat egy multiprocesszoron.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#40719
Abu85
HÁZIGAZDA
huskydog17
#40718
Abu85
HÁZIGAZDA
válasz
huskydog17
#40718
üzenetére
Én. Mivel tesztjáték lesz, így ellenőrizni kell, hogy az új patchekkel, és driverekkel hogyan javult.
A Vega 56 Full HD-ben maxon Vulkan módban átlag 156 fps-t tud. A 2080 ugyanitt átlag 151-et. A 2080 Ti sem tud sokkal többet. 164-nél az is megáll. A Vega valamiért skálázódik tovább, elmegy 200 fps-ig is, de a PH procija lassabb, ott nem fog ennyire skálázódni. (cimbis tesztgépben egy 5 GHz-en működő 9700K van)Nem mérek 4K-ban. Azt majd a tesztcsomagban. Az itthoni monitorom nem tud 4K-t. Elkérhetném a szomszédét, ha már a gépet áthozom, de annyira nem izgat.
Én ugye arra voltam elsődlegesen kíváncsi, hogy mennyire fut már optimálisan GeForce-on. Az új driver javított, tényleg. De legalább ennyit javult az AMD is a kezdetek óta. Az jó hír viszont, hogy az NV még dolgozik tovább, de hónapokat vesz még igénybe a munka. Nem valószínű, hogy a WWZ-ért csinálják, hanem a többi játékért, mert a subgroup egy igen alapvető Vulkan 1.1 fícsőr, azt érdemes rendbe kapni. Nemrég kiderült, hogy a No Man's Sky is használni fogja, nem a mostani verzió, hanem a végleges.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem szoktam benchmarkolni. Frame-eket mentek ki, és azokat visszatöltöm profilozóban. A sebességet csak megmondtam, mert átlagoltam a kimentett kilenc frame-et. Ennek sok előnye van, mert nem arra vagyok kíváncsi, hogy a játék mit tud benchmarkban. Azt majd a tesztben megnézzük. Az érdekel, hogy pár kiválasztott frame hogyan fut le a GPU-kon. Így kiszűrhetők a limitek, mert például egy benchmarkon csak az fps-eket látod, de engem az érdekel, hogy konkrétan mik a timing és occupancy adatok. Ha ezek az egyik gyártón nem túl jók, akkor fel se vesszük a játékot a tesztcsomagba. Úgy felesleges tesztelni, hogy a GPU fele valami hiba miatt nem dolgozik. A korábbi driverrel simán nem vettük volna fel a World War Z-t, mert volt egy frame GeForce-on, amely azt mutatta, hogy a GPU egyszerűen malmozik a számítási idő nagy részében. Ezen sokat javított az új driver.
Egyébként itt az egy frame nem hangzik problémának, de valójában az, mert a probléma a jelenetből adódik, tehát ha egy frame-ben a timing és occupancy nem megfelelő egy hardveren (driver vagy program miatt, mindegy), akkor az az egész jelenetben rossz lesz, vagyis én igaz, hogy csak egy frame-et vizsgálok, de a tesztben abból lesz vagy 2000 rossz frame.
(#40722) b. : Más játék nem nagyon van az subgroup shaderek tesztelésére. Ha lesz, berakjuk azt is. Mint írtam, a No Man's Sky használni fogja.
Itt vannak a kártyák, csak állandóan van valami teszt, amit időre kell megírni. Így nehéz haladni. Múlt évben lett volna rá egy csomó időnk, ha küldenek hamarabb hardvereket, akkor nem lenne ebből probléma.
Attól függ, hogy mikor kapunk hardvert. Ha hamar, akkor elég gyorsan van teszt. Ha fél évig nem fontos a gyártónak, hogy csináljunk tesztet, akkor ott már nehéz az előre letervezett szervezést átalakítani, hogy legyen rá idő.
Szerk.: Pedig a teszthardver alapvetően a gyártón múlik. Ők döntik el, hogy a régiókba szánt hardverek kiknél landolnak. Ha tudnád mennyi GeForce jött a teljes régióba influenszereknek...
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#40731
Abu85
HÁZIGAZDA
huskydog17
#40724
Abu85
HÁZIGAZDA
válasz
huskydog17
#40724
üzenetére
Tervben van.
Nézd abban nem vagyok biztos, hogy az új Doom subgroup shadereket fog használni. Az AMD fizetett még 2017-ben sok-sok millió dollárt a cégnek, hogy külön optimalizálásban részesüljön a Radeon és a Ryzen vonal. Ezért az id Software-nek nagyon sok AMD-specifikus shader kódja van már, és egyrészt ezeket nem biztos, hogy megéri kidobni, másrészt nem tudjuk, hogy pontosan milyen kötelezettséget vállalt az id Software, a Bethesda és a Zenimax a szerződéssel. Az biztos, hogy ők voltak az elsők, akik támogatták az AMD subgroupokhoz hasonló képességű, de nem szabványos SPIR-V kiterjesztéseit. Ezek azért eléggé máshogy működnek, vagyis nagyon nagy munka mindent átírni szabványosra. Ráadásul az id Software helyzete hatványozottan problémás, mert olyan kiterjesztést is használnak, amit a Khronos nem is jegyez (VK_AMD_wave_limits). Ugye itt arról volt szó, hogy ezzel az id Software a PSSL kódokból tudja azokat is fordítani, ahol a wave-ek számát mesterségesen limitálják. Ez konzolon teljesen megszokott, és az AMD megcsinálta a Vulkan API-hoz, de nem adták be a Khronosnak, mert végeredményben az a baj ezekkel a gyártóspecifikus kiterjesztésekkel, egy idő után annyi kódod lesz rá, hogy rohadt nehéz megszabadulni tőlük. Az id Software-nél az összes shader nagyjából felére van AMD-specifikus verzió, ami azért jó ~100-120 ezer sornyi kód lehet. Ez ilyen kezdetben jól jártam vele, ma meg inkább nem tipikus esete. Persze nem kell félteni az id Software-t, nyilván amikor megkötötték a szerződést, akkor tudták mit csinálnak.
A szerződést egyébként eléggé védik, kérdezgettem őket, de nem válaszoltak a részletekről. Annyit tudtam kideríteni, hogy több millió dolláros értékű volt az egyezmény, és sok-sok évig érvényes marad. De specifikusan az adatokat se az AMD, se az id Software nem mondta meg. Konkrét adattal kapcsolatban csak annyit árult el az AMD, hogy a szerződés része, hogy az id Software és a Bethesda kizárólag AMD hardveren fejleszti a készülő játékaikat. Ez gondolom tényleg csak a fejlesztésre vonatkozik, az optimalizálást már csinálhatják Intel és NV hardveren is.
Szóval végeredményben a Doom az nem egyértelmű, mert köti a szerződés a céget, nem úgy ahogy a Sabert, amelynek nincs ilyen egyezménye az AMD-vel, tehát ők szabadon választhatnak fejlesztési irányt. Nyilván a szabványos kód volt a logikus, ők se hülyék.
Az ilyen szerződéses kapcsolatoknál a logikát sajnos felülírja a szerződés.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#40739
Abu85
HÁZIGAZDA
huskydog17
#40733
Abu85
HÁZIGAZDA
válasz
huskydog17
#40733
üzenetére
Ez kimaradt. Így viszont nagyon jó.
Ellenben problémásnak érzem az async compute-ot. Ha a számítás felét átlapolod a következő frame-mel, akkor az nem túl szerencsés Vulkan API alatt, ami nem tartalmaz fallback módot, ahogy a DX12. Itt azért simán futni fog egy rakás grafikai pipeline egy rakás compute pipeline mellett, és utóbbiak nem minden hardverben futnak ám stateless módban. Tehát attól, hogy ez elméletben adott, az átlapolás a GPU-kon belül nem valószínű, hogy megvalósul az állapotváltások miatt. Értem persze a konzolokon működik, de nem minden PC-s hardver hasonlít a konzolokra.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
schawo
#40804
üzenetére
A Hot Chipsen mindig csak dumálnak. Ez egy ilyen rendezvény. A gyártók elviszik bemutatni a legújabb dizájnjaikat. A 2018-as év augusztusában például a Raven Ridge-et részletezte az AMD.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#40877
Abu85
HÁZIGAZDA
Petykemano
#40876
Abu85
HÁZIGAZDA
válasz
Petykemano
#40876
üzenetére
Maximum a Google, de csak tesztre, mert megfeleződik a kiszolgálható játékosok száma, vagyis ugyanazt a központot kevesebb játékos befizetéseiből kell fenntartani, ami nem éppen jó dolog. A legtöbb gépben tehát marad a dual Vega 10.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Mert vannak a Navinak olyan képességei, amiket a korábbi hardverek nem tudnak, és ezekre a Microsoft hoz is API-t.
Ettől még a korábbi hardvereket megtarthatod, csak azok nem fognak olyan gyorsan működni ezeken az új lehetőségeken, konkrétan metaparancsokkal, mint a Navi.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#40890
Abu85
HÁZIGAZDA
Petykemano
#40887
Abu85
HÁZIGAZDA
válasz
Petykemano
#40887
üzenetére
Mint írtam nem muszáj ezeket használni, de ezekkel a Microsoft lényegében azt kínálja fel, hogy Full HD-s igénybevételből tudjon számolni a motor 4K-s minőséget. Azért ez nem olyan rossz dolog, főleg úgy, hogy alig kell vele dolgozni a program szintjén. Ez lesz igazából az új Xbox killer fícsőre, de nyilván PC-n is elérhető, sőt, itt lesz kitesztelve, hogy mire jön az Xbox next, akkora már rengeteg motor támogassa, és szimplán ki lehet vele szolgálni a 8K-s tévéket is, anélkül, hogy a 8K-s felbontást ki kellene számolni, miközben a minőségkülönbség a natív és a trükkös opció között alig észrevehető.
Mindenki eldöntheti, hogy akarja-e vagy sem. Rengeteg metaparancs egyébként működik a régebbi hardvereken is, de az újak sokkal hatékonyabbak ebből a szempontból.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ezekben a fícsőrökben nem jövő van, hanem csak nyers teljesítmény. Másra nem igazán jók, csak brutálisan felgyorsítani a feldolgozást, miközben szemre nem veszed észre a különbséget, a natív megjelenítés és a trükkös megoldás között. Majd az E3-on erről többet fognak beszélni. Nem csak az AMD, hanem a Microsoft is. De egyébként az Intel és az NV-nek is lesznek metaparancsokat támogató meghajtói. Kísérleti support szintjén ilyennel mindenki rendelkezik.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Csak a Microsoft a DLSS-nél ezerszer jobb megoldást csinált.
De mint írtam a cikkben is, a DLSS-nek nem a koncepciójával van a baj, hanem azzal, hogy a gyakorlatban nem működik. A Microsoft viszont sokkal régebb óta dolgozik ezen, és a GDC-n elég jó eredményekről beszéltek.
Az is számít, hogy ezeket a megoldásokat hogyan integrálod. A DLSS-nél csak egy fájlt tudsz bemásolni, aztán vagy működik, vagy nem. Nincs rá befolyásod fejlesztőként. A Microsoft megoldása teljes fejlesztői kontrollt ad.(#40895) GeryFlash: Szerintem a PS5 is képes rá, de a Sony-nak van egy érdekes hardvere, ami még ennél is jobb lehet. Azt a PS4 Próban kipróbálták, csak egy játék se támogatta. Viszont a háttérben nyilván megnézték, és javítgatták a PS5-ös bevetésre.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Pixel perfect scaling. Már benne van a dev alpha-ban. Elég sokat dob a képminőségen, ha mondjuk a natív felbontás alá állítod a kijelzőt, mert nem lineárisan skáláz, vagyis nem lesz mellékhatásként blur.
[ 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
solfilo
#40967
üzenetére
Biztosan nem lehet tudni. Tippem szerint egy évközi nagyobb frissítés úgyis lesz a Navihoz, és abba beférhet, mert alapvetően be van építve a funkció. Speciel működik is.
Van még mellette más is, mert például a saját gépes RX 570-emnél megjelent az auto tuning. Mondjuk helyből le is fagyott, de nem tudni, hogy a funkció miatt-e, mert eléggé instabil ez a driver.
Szintén megjelent a flip queue control, szerintem bugos is, mert a 2-es beállítást beveszi, de 3-mal már olyan, mintha a default 1-gyel menne. Na mindegy.Ezeket látom most benne, a többit majd írom, ha tudok valamit, de ha nem írnám, akkor meg NDA van, ami eleve azt jelenti, hogy közeleg. A Navira sem véletlen, hogy nem reagálok.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az az architektúra neve.
Alapvetően az AMD és az NV is egy nagyon régi ISA-ra épít. Az AMD a Southern Island ISA-jára, míg az NVIDIA a Fermi ISA-jára. Viszont az évek során változik annyit a kódolási séma, hogy ezek ugyan a szálkezelést tekintve ugyanazok, mint a 2010 körül hozott hardverek, de a feldolgozást tekintve már nem. Az AMD-nél ez a Vegánál módosult először, míg az NV-nél a Maxwellnél, majd a Turingnál. De a szálkezeléshez eddig nem nyúltak. Most viszont az AMD lépett, és az évek óta bevált alap ISA-k szempontjából megváltoztatták a hardveres szálkezelést is, tehát nem csak a kódolási séma módosult, hanem a skálázhatóság. Emiatt nem hívják GCN-nek, hanem az RDNA nevet adták neki.
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
#41057
üzenetére
Senki sem hazudik. Az AMD nem a Platinum 9242-höz hasonlította, hanem a Platinum 8280-hoz. Utóbbira építhetnek platformot az Intel partnerei, előbbi egy rendkívül nagy korlátozottsággal elérhető termék, amit sokan egyszerűen nem is rendelnek a korlátok miatt. Egyszerűen jobb kihagyni, mert túl sok a macera vele, nem bővíthető, illetve egyéniben kell megegyezni az Intellel az árakról, aztán hónapok, mire a rendelést teljesítik, stb. Nem véletlen, hogy ez az -AP vonal jövőre megszűnik, és helyette a Cooper Lake-P lesz, mert csak a papírért fejleszteni felesleges. Itt azért fontos, hogy a szerverpiacon a vásárlók zöme nem hülye, nem lehet a baromságokat eladni.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az fontos, hogy ezek valójában marketingnevek. A GCN neve eléggé erős, viszont annyit módosult a dizájn, hogy érdemes már más nevet adni neki. Az egy érdekes kérdés, hogy mikortól tekintesz valamit új architektúrának. Az AMD és az NV ezeket a határvonalakat már elmosta azzal, hogy generációnként új nevet adnak a dizájnoknak. De régebben akkor tekintettek valamit új architektúrának, ha módosult a kódolási séma. Mondjuk az igaz, hogy még 2010 előtt nem is terveztek annyira jól skálázható hardveres szálmenedzsmentet, amivel ki tudtak volna bírni tíz évet is, tehát régen amikor a kódolási séma megváltozott, akkor azzal egyetemben a szálmenedzsment is teljesen új volt. Ma már ez nem igaz.
(#41065) Raymond: Eleve nem lesz benne komoly RT hardver. Más DX újításokhoz való funkciók kerültek bele.
Egyébként, ha a Sony konzoljából ki lehet indulni, akkor az AMD nem ugyanúgy csinálja, ezt ahogy az NV. A brute force megoldás helyett van az új PS-ben egy koherenciaelemző, amivel gyakorlatilag elkerülhető a sok véletlenszerű memóriaelérés, így a sugárkövetés lényegében nem fogja a gyorsítótárat szétszemetelni. Utóbbi az, amiért probléma a sávszél, mert a Turingban ilyen hardver nincs, az full brute force megoldás, ami működik, csak borzalmasan messze van a hatékonytól.
(#41064) Oliverda: A GDDR6 nem azért volt drágább, mert drágább gyártani, hanem mert a rendelési mennyiség nem érte el azt a szintet, hogy olcsón tudják adni. A memóriák esetében mindenki tudja, hogy alapvetően a túltermelés döntően meghatározza az árat, viszont eleinte csak pár cég igényeit elégítik ki a gyártók, tehát nehéz túltermelni. Azzal viszont, hogy telik az idő, ez a túltermelés egyre reálisabb lesz, mert idővel 10-20 cég is rendelni fogja ezeket a memóriákat, vagyis jóval nehezebb lesz belőni a termelt mennyiséget. Emiatt csökken egy éves távlatban sokat az egyes új memóriaszabványok ára. Ezt akár megfigyelheted a memóriaárak változásán is. Amikor felmegy az ár, akkor nem azért megy fel, mert hirtelen de sokkal drágább lett azt gyártani...
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A szoftvernek itt nincs jelentősége, mert lényegében csak egy koherenciavizsgálóról van szó, ami csoportosítja a sugarakat, hogy ne annyira véletlenszerűen történjenek a memóriaelérések. Nem mondom, hogy egyszerű megoldani hardveresen, mert közel sem az, de szoftveres oldalról ez a fícsőr láthatatlan és hozzáférhetetlen. Egyszerűen csak működik a hardverben, és az a célja, hogy a sugárkövetés ne szemetelje össze a cache-eket.
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
#41071
üzenetére
Először meg kell értened a sugárkövetés működését. Ennek a tipikus problémája a véletlenszerű elérés. A legtöbb mai eljárás nem ilyen, hanem betöltenek egy rakás texeladatot egy textúra lokális területéről, és ahogy ezek a memóriában tárolva vannak, jó esély van rá, hogy a következő pixel is lényegében ugyanazokat a mintákat igényli. Ergo a cache-ek miatt nagyon gyorsan lehet ezekkel az adatokkal dolgozni. A sugárkövetés ennek az ellentéte, legalábbis a brute force hardverekkel, ugyanis itt konkrétan semmi garancia nincs erre a nagymértékű koherenciára, vagyis egy szomszédos pixelből kilőtt sugár bizony teljesen véletlenszerűen, akár teljesen más memóriaterületről igényelhet adatot. Ez két dolgot okoz. Egyrészt drámai mértékben szemeteli a cache-t, másrészt gyakorlatilag a hardver nem tud igazán cache-ből dolgozni, hanem mindig a memóriáig kell menni az adatért. Emiatt kell a sugárkövetéshez a nagy sávszél. Ugyanakkor persze lehetnek olyan hardveres megoldások erre, amelyek a megpróbálják ezt a problémát nem erőből, hanem észből kezelni, de persze maga a sugárkövetés jellege miatt 100%-os megoldás erre sosem lesz. Tehát lehet, hogy egy bizonyos mennyiségű sugarat tudsz megfelelően csoportosítani, de egy kellően nagy részt pedig nem, tehát a sávszél ugyanúgy kelleni fog.
A mai játékok azért nem tudják igazán megmutatni a sugárkövetés erejét, mert vagy egy sugár per pixellel, vagy akár kevesebbel dolgoznak, pedig az optimális a 4-16 sugár per pixel lenne, csak attól még fényévekre vannak a hardverek. Tehát marad a nagyon lebutított effektminőség, mi pedig sokszor nem ad igazán észrevehető különbséget. Ehhez még hozzátartoznak olyan hülye döntések is, mint a spekuláris visszaverődésre való gyúrás, ami egyrészt az erőforrásigény szempontjából számos ma bevált megoldás százszorosa, másrészt marginális előnye van.
Az egyetlen jó hír, hogy a Microsoft azért nem csukta be a szemét, és a GDC-n is utaltak rá, hogy jobb lesz majd a DXR, és az új verziónál még a kompatibilitás megőrzése sem kritikus.
[ 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
Devid_81
#41090
üzenetére
Nem rakták ki. Ezek egyelőre koncepciók, külön kihangsúlyozták. Nincs alattuk működő hardver. Az, hogy a média ezt úgy adja el, hogy ezek a NAVI-k, egy szegénységi bizonyítvány, amit a szenzációhajhászással állítanak ki. A NAVI-t az E3-ig senki sem mutathatja meg.
Itt az ASRock konkrétan a tervezés alatt álló hűtődizájnjaikat akarta megmutatni, semmi mást. Az se biztos, hogy lesz belőlük valami. Ha lesz is, akkor is fél év legalább.[ 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
Devid_81
#41097
üzenetére
Az mindegy, ha a dizájnok még nincsenek kész. Inkább raknak rá működőt, mint koncepciót. A kinézet látszik rajtuk, azt le is tudják másolni rá, de a hűtőteljesítményen még javítani kell. Márpedig egy hűtőnél ez a legfontosabb. És ezek igénybe vesznek több hónapot is. Az ASRock hosszabb távon maradna a VGA-piacon, és így saját tervezésű hűtő akarnak, mert eddig nem sajátot használtak.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem kamu a TBP, vagy az NV-féle verziója. Ezek tényleg arra szolgálnak, hogy egy határértéket adjanak a vásárlónak. A legegyszerűbben megfogható határérték az AMD-nél a board power, vagyis az elméleti maximum, ahogy a hardver a gyakorlatban működni tud. Más érték egyszerűen nem reális, mert alapvetően a Radeonok valós fogyasztása a driverben 100-150 wattos skálán is befolyásolható. Emiatt nem optimális a TDP-re építeni.
[link] - ebben a tesztben ezt mi is megnéztük. Ugyanazt látod a kijelzőn, a fogyasztásmérőn viszont világos, hogy nem mindegy, hogy a driver hogyan működteti a hardvert. Az egyetlen valóban megfogható paraméter, ami független a működési módtól az a TBP.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az alulfeszelés az tuning, arra nem specifikálhatnak.
Csak nincs ideálisnak kikiáltott gyári órajel. Az NV-nél van egy alapórajel, ami be van táplálva a BIOS-ba, ez nekik azért egyszerűbbé teszi a helyzetet, de még ők is kerülik a TDP-t. Ellenben az AMD-nek egy órajel van betáplálva a BIOS-ba, ami a PowerTune clock, aztán a driverbeállítástól függ, hogy a valós órajel mi lesz. Ezzel aztán pláne érdemes kerülni a TDP-t.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
Ú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 AMD é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: Promenade Publishing House Kft.
Város: Budapest
Cég: Ozeki Kft.
Város: Debrecen