Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
Ettől még működni fog az RT a mostani RT-s kártyákon, csak nem úgy ahogy most. De az igaz, hogy a DXR 1.0 és 1.1 egy zsákutca. A DXR 1.0 azért, mert túl sok dinamikus bekötést igényel, és emiatt lassú, míg a DXR 1.1 azért, mert nem kompatibilis a működési elve olyan potenciális jövőbeli hardveres fejlesztésekkel, mint a másodlagos sugarak koherenciájának biztosítása. A traversal shader egyébként egyik zsákutcára sem megoldás. Ez abban segít, hogy ha RT-t raknak a játékba, és nem csak marhára limitált távolságig lövik a sugarakat, akkor az RT VRAM-igénye ne legyen 2-3 GB, ami ma is előfordul a távolra számolós RT-s játékokban, mint például a Godfall. Ha azt átrakják traversal shaderre, akkor ez a VRAM-igény 0,5-1 GB közé csökken, ami azért nem mindegy. Ez most a legégetőbb probléma. De a DXR 1.0 és 1.1 problémáit ez sem kezeli, ahhoz egy harmadikféle irány kell. Na most a Microsoft dönthet úgy, hogy csinál egy új irányt, vagy megpróbálja erősen kombinálhatóra módosítani a DXR 1.0-t és 1.1-et. Utóbbi esetben nem kell új specifikáció, és úgy működhetne a dolog, hogy a másodlagos sugarakkal dolgozó lövéseket DXR 1.0-ban, míg a csak elsődlegessel dolgozókat DXR 1.1-ben alkalmaznák. Itt kihasználnák, hogy az elsődleges sugarak alapból koherensek.
Szerintem amúgy ez még évekig útkeresés lesz, de ettől tesztelni lehet.
Érdemes amúgy az Intelnek megnézni ezt a konstrukcióját: [link] - nem megoldás mindenre, de a DXR legégetőbb bajait kezeli. Oldalt van egy videó, amiben az előadás megtekinthető, és nagyon jól érthetően elmagyarázzák. Erre lesz jó amúgy a traversal shader.
#43298 b. : Az EVGA-nak az a gondja, hogy az Intel már nem az elsődleges gaming választás a prociban. Ezt le kell reagálni, mert ha megnézed a DIY eladásokat a procinál, akkor azt gaming szinten a Zen 3 uralja le, nem a rakétató. Ez az EVGA-nak azért baj, mert kevesebb lesz az igény az inteles alaplapjaira, hiszen ha már eleve nem veszik meg a szükséges procit, akkor hova adnák el a legyártott termékeiket ugye...
-
Abu85
HÁZIGAZDA
A Microsoft-féle API szabványos, de még nincs kész PC-re. Amíg nem véglegesítik a specifikációt, addig nem fogják használni a programok. Erre azért jó oka van az iparágnak... better safe than sorry.
[link] - itt alul lehet olvasni készülő fejlesztéseket. A három felsorolt újítás közül kettő már nem potenciális, hanem konkrétan benne van az Xbox Series S/X mono API-jában. Konkrétan a traversal shader és a beam tracing. Új hardvert sem igényelnek, sőt igazából a meglévő hardverekből is kevesebb részegység lesz kihasználva, mert a traversal shader egy programozható lépcső, így a fixfunkciós traversal unit hiába van ott az egyes GPU-kban, azokat nem lehet majd ezzel használni.
Az AMD-nek van nem szabványos rendszere erre, de igazából ezt sokan csak a fejlesztéshez használták. Igazából ahogy lesz szabvány, nincs értelme az AMD-féle nem szabványos csomagnak. A fejlesztésben segíthet, de másban nem.
-
-
Abu85
HÁZIGAZDA
A WoW a Shadowlands óta inkább csak Radeonra van optimalizálva. GeForce-okat a Blizzard elképesztően elhanyagolja. Meg is látszik a teljesítményen. Mi fel akartuk venni a WoW-ot a tesztcsomagba, de 1080p-ben DX12-ben, bekapcsolt RT-vel, quality 10 beállítással egy Radeon 6700 XT 145 fps-t tudott, míg egy GeForce RTX 3090 109 fps-t. Itt kérdezősködtünk, hogy ez miért van, lesz-e patch, vagy mi a tosz, és annyit tudtunk meg, hogy a Blizzard fejlesztői gépeiben már nincsenek GeForce-ok. Az NVIDIA is mostanra oldotta meg azt a bugot a driverben, ami miatt a játékosok már hónapok óta képi hibákkal küzdenek. Valamin összekaphattak, és most rohadtul nem néznek egymás felé, de az AMD sem beszél arról, hogy mi a probléma. Az a pletyka járja, hogy eléggé komoly a mosolyszünet, mert a Blizzard még mindig nagyon zabos azért, hogy az egyes játékaik elérhetők voltak a GeForce Now szolgáltatáson, és ezért nem kaptak licencdíjat. De kifelé mindenki kommunikálja, hogy minden fasza, csak nem látszik a programon. Így a Shadowlands ki lett ütve a tesztcsomagból, mert így nagyon egyoldalú lenne ez a cím. Emiatt nem is túl jó összehasonlítási alap még réjtrészinggel sem, a kód elképesztően szarul fut GeForce-on, és így fél évvel a megjelenés után láthatóan az akarat is hiányzik, hogy ezen javítsanak.
-
Abu85
HÁZIGAZDA
Ha tudod, hogy mit keress, akkor feltűnő lehet. Ez az átka a szakmának, tudni fogod, hogy az egyes eljárások hol hibázhatnak, míg mások nem, és esetleg elnézik a hibát.
Mindkettő célja ugyanaz, csak másképp jutnak el az eredményhez.
Egyébként a DLSS nem igazán hardverfüggő. Az NV erőlteti rá a tensor magokra, de lényegesen jobban járnának, ha nem tennék, mert igazából a tensor magok nem igazán a DLSS-hez lettek kitalálva, így a hatékonyságuk elég sokat esik alatta. Jó példa volt erre a DLSS 1.9, ami nem a tensor magokon futott, és micsoda minőségi ugrás volt a korábbi DLSS verziókhoz viszonyítva. Azt nehéz megérteni, hogy az NV miért szopatja magát a tensor magokkal, nélkülük jobb minőséget lehetne előállítani, ráadásul gyorsabban. Elképzelhető, hogy ebbe beleszól a marketing, amely nagyon erőlteti, hogy használják a DLSS-hez a tensort, még ha nem is erre tervezték a hardvert.
-
Abu85
HÁZIGAZDA
Több dolog okozhat hibát a felskálázási eljárás során.
A shimmering általános jelenség, az FSR-t és a DLSS-t is érinti, mert a működésből keletkezik a probléma, de valamennyire kezelhető, viszont nem szüntethető meg.A szellemképes hatás a mozgásvektor-alapú algoritmusok sajátja, egyszerűen a temporális adat miatt nem szűrhető ki teljesen, de lehet segíteni rajta, hogy ne legyen annyira zavaró, viszont nem szüntethető meg. [link]
Az egyéb grafikai hibákba sorolandó az, ha egy effekt nem működik jól temporális rekonstrukcióval. Ez abból ered, hogy a szükséges adatok temporális rekonstrukcióval hiányozhatnak Az ide kategorizálható grafikai bugok sem szüntethetők meg, de talán minimalizálhatók. [link]
Amiért az AMD az FSR-rel kerüli a temporális megoldást az pont az, hogy a szellemképes hatással és az egyéb grafikai hibákkal nem tudnak mit kezdeni, ezeket maga a mozgásvektor generálja. És mivel jelenleg láthatóan leszarják a fejlesztők az efféle bugok javítását a DLSS 2-nél (mert ezzel egyébként per program alapon kellene valamit kezdeni), jobbnak látták, ha olyan felskálázási eljárást választanak, amely eleve nem generál ilyen hibákat.
-
Abu85
HÁZIGAZDA
Nem szükséges a temporális megoldás. Pont ma bizonyította be az AMD. Az az NVIDIA döntése, hogy ők így csinálják, de egyértelműen látszik, hogy nem ez az egyetlen megoldás.
Az AMD egyelőre eléggé távol van a mozgásvektor-alapú algoritmustól. Ezt azzal indokolták, hogy egy rakás olyan problémát hoz be egy ilyen rendszer a képletbe, amelyet a fejlesztőknek direkten kellene kezelni, de láthatóan nem teszik. Amíg nem látják a fejlesztői akaratot a DLSS 2-nél, hogy a mozgásvektor által generált hibákat direkten kezeljék, addig jobbnak látják, ha ezeket a hibákat a felskálázó eljárás elő sem hozza. Ezért nem dolgozik temporális adatokkal az FSR, a fejlesztők egyszerűen tesznek arra, hogy a temporális adatok által behozott problémákat kezeljék.
Sok dolgot lehet fejleszteni a felskálázó megoldásokon, de nem az a kérdés, hogy elméletben mit lehetne megtenni, hanem az, hogy a fejlesztők számára mi lenne az optimális. És itt ezen azt kell érteni, hogy a megoldás rendelkezzen olyan nagy kompatibilitással, hogy a fejlesztőknek ne kelljen a felskálázás beépítése miatt semmit sem átírniuk.
-
Abu85
HÁZIGAZDA
Attól, hogy az NV áttért mozgásvektorra még nem kell követnie őket az AMD-nek. Miért is lenne jó a piacnak ugyanarra a problémára ugyanaz megoldás? Gondolj arra, hogy ha például egy adott effekttel nem kompatibilis a DLSS 2, akkor nem kell az effektet áttervezni, hanem könnyebb beépíteni az FSR-t. Ez volt a koncepció az AMD döntése mögött.
Mindkét cég járja a saját útját, és ha ez az út eltérő, akkor az hasznos, mert mások az előnyök és a hátrányok.
-
Abu85
HÁZIGAZDA
Szándékosan ilyen. A temporális adatok korlátozzák a kompatibilitást és kisebb-nagyobb grafikai hibákat generálhatnak. Ezt a tényezőt az FSR-ből direkt vették ki, hogy minden effekttel kompatibilis legyen, és ne kelljen grafikai hibákkal számolnia a fejlesztőknek, mert az eddigi tapasztalatok alapján sajnos nem írnak csak a felskáláz miatt temporális eljárásokkal kompatibilis effekteket.
-
#43156
Abu85
HÁZIGAZDA
gainwardgs
#43150
Abu85
HÁZIGAZDA
válasz
gainwardgs
#43150
üzenetére
Én se nagyon, de az Intel nagyon ígérgeti a partnereknek, hogy lesznek kompatibilis szoftverek az Alder Lake startjára. Már amúgy van olyan profilozójuk, amivel az alkalmazás működése hozzáigazítható az eltérő magokhoz, tehát ez jó jel. Innen már csak a fejlesztőkön múlik, hogy megcsinálják-e, vagy inkább kijelölik az egyik magcsoportot oszt jóvan.
-
Abu85
HÁZIGAZDA
A CCX-es megoldás abból a szempontból nem nagy gond, hogy ott mindegyik mag ugyanolyan késleltetéssel éri el a gyorsítótárait. A hibrid dizájnoknál az kavar be, hogy a két magcsoporton belül is eltérők a magok. Ezeket alkalmazás szintjén tudni kell kezelni, vagy meg kell mondani az OS-nek, hogy erre az applikáció nincs felkészítve, így ne is ossza a másik magcsoportra a programszálakat.
Igen. A BIOS-ban ki lehet kapcsolni a kisebb teljesítményű magcsoportot.
-
#43144
Abu85
HÁZIGAZDA
gainwardgs
#43143
Abu85
HÁZIGAZDA
válasz
gainwardgs
#43143
üzenetére
A Windows ennek csak az egyik eleme. Az új OS-t a Microsoft felkészítette arra, hogy jobban tudjon dönteni a hibrid dizájnokban. De ez az ütemező jórészt a Qualcomm kódjára épül. A problémás terület nem ez, hanem az alkalmazások helyzete, hogy lekezeljék az eltérő magok jelentősen eltérő késleltetését a gyorsítótárakra nézve. Ebben valamennyire segít az, hogy az új ütemező felé egy alkalmazás jelezheti, hogy hibrid dizájn esetén tudja-e kezelni a magok különbségeit, vagy nem, és ha nem, akkor melyik magcsoporton akar futni, és melyiket hagyja munka nélkül. Default beállításon az Edge böngésző például eleve az Atom magokon fut, és a nagy mag(ok)hoz hozzá sem nyúl. Azt még nem tudni, hogy ebbe a user belenyúlhat-e, vagy el kell fogadni az alkalmazás/OS döntését. Androidon ugye úgy van, hogy nem lehet megszabni felhasználói szinten, hogy egy alkalmazás melyik magcsoporton fusson, ha a leglassabb magokon akar futni, akkor lófaszt se tehet a user.
-
Abu85
HÁZIGAZDA
A Samsung 7 nm-es node-ja is jó, csak ugyanúgy drága, mint a TSMC-é.
5 nm-en inkább a TSMC tűnik kiemelkedően jónak. A többiek azzal küzdenek, hogy ilyen csíkszélességen már erőteljesebben kell alkalmazni az EUV-t, és erre egyszerűen nem készültek fel. A TSMC ott nyert baromira sokat, hogy nem várta meg az ASML pelluláit, hanem csinált magának, és ezzel hatalmas előnyre tett szert az EUV node-ok tekintetében. A Samsung itt hibázott, mert nem terveztek maguknak pellulát, hanem vártak az ASML-ét. A TSMC-vel most az ipar legalább 3-4 évig nem tud majd mit kezdeni, mert ugyan a gyártási problémákat lassan megoldja mindenki, de a TSMC már meg is oldotta, és így már nagy mennyiségben rendelhetik az EUV-s eszközöket. Az Intel itt a futottak még kategória, mert ők még egyetlen EUV-s gyártósort sem üzemeltetnek tömeggyártás szintjén, ellentétben a Samsunggal és a TSMC-vel. Tehát lesz egy rakás munkájuk a problémák megoldásával, de ezen a TSMC és a Samsung akkorra már rég túl lesz. Ettől függetlenül az Intel az IDM 2.0 miatt olcsón adhatja a wafert, amit az NV ki is használhat, de ez annyit is ér, mert ettől még 1-2 évvel lesznek a Samsung és a TSMC gyártási eljárásai mögött.
Az a gond az Intelnél, hogy nagyon jó dolgokat beszélnek magukról, de valójában meg sem közelítik jelenleg azt, amit a TSMC vagy éppen a Samsung tud biztosítani tömeggyártás szintjén. És a kulcsszó itt a tömeggyártás. Azért nyeri a TSMC és a Samsung a megrendelőket, mert nekik nem csak papíron működik a legmodernebb gyártástechnológiájuk. Nézd csak meg mit tud az Intel 10 nm-es node-ja az Ice Lake-SP-ben. Alig van megvásárolható új Xeon. Nem azért, mert nem gyártják, hanem azért, mert akkora lapkaméretben iszonyatosan sok selejtjük lesz. Pont ezért viszik a GPU-s projekteket bérgyártóhoz, pontosan tudják, hogy nagyon messze vannak a TSMC és a Samsung 7 nm-es node-jaitól. Ha nem így lenne, akkor házon belül gyártanának. Emiatt sem nagyon látom reálisnak, hogy az NV-t ez érdekelheti. Lehet, hogy van olyan olcsón kínált wafer, ami mellett megéri, de a technológiai előny a Samsungnál és a TSMC-nél van, és egy darabig még ott is marad. Az Intel is leghamarabb 5 nm-re ígérte a versenyképességet, ami a szokásos optimizmussal van kirántva.
-
-
#42952
Abu85
HÁZIGAZDA
FollowTheORI
#42950
Abu85
HÁZIGAZDA
válasz
FollowTheORI
#42950
üzenetére
De a PS5-ön ez GNM-en fut, ami azért sokszor jobb API, mint a DirectX 11.
-
Abu85
HÁZIGAZDA
A VRS-t többféleképpen lehet használni. Van neki egy Tier_1-es és egy Tier_2-es szintje. Ebben a játékban a Tier_1 van csak kihasználva, abban nincs sok lehetőség, ellenben fut az Intel IGP-in. És ez azoknál fontos, mert sokat jelent ám az előny. A Tier_2-es szint viszont nem fut az Intel IGP-ken (ilyen van egyébként a Gears 5-ben). Na most a Tier_2-es szintre lehet olyan megoldást csinálni, ami úgy növeli a teljesítményt, hogy nem csökkenti a képminőséget, de a Tier_1-es szint túl limitált ehhez. Az új RE-ben az lehetett a döntő, hogy a motor eleve marha gyors, ergo sokkal jobban számított, hogy az Intel IGP-i kapjanak egy kis boostot, minthogy a VGA-k 100 fps helyett 110-zel menjenek. Véleményem szerinte teljesen érthető döntés ez most.
-
#42924
Abu85
HÁZIGAZDA
AsakuraDave
#42916
Abu85
HÁZIGAZDA
válasz
AsakuraDave
#42916
üzenetére
Sok játékban ma borzasztóan korlátozva van a sugarak távolsága. Egyszerűen csak a szemed elé lövi ki, pár virtuális méterre. Ennek az oka, hogy ha olyan messzire lőné, mint mondjuk a Godfall, akkor borzasztóan zabálná a VRAM-ot az effekt. Erre a megoldása programozhatóság.
[link] - ez az előadás nagyon részletesen bemutatja, hogy mi a probléma. Felvázol rá egy potenciális megoldást, és azt is prezentálja, hogy az miért megoldás.
#42917 b. : A probléma általános. Elég sok dolognak nem úgy kellene, hogy kinézzen RT-ben, ahogy kinéz. Azért olyan az eredmény, mert 2-3 méterig vannak sugarak. Esélye sincs az RT-nek, hogy igazán jól működjön. De ugye a fejlesztők is be vannak szorítva, mert ha tovább lövik a sugarakat, akkor azért gigabájtokban fizetnek. Olyan VRAM terhelést raknak a VGA-kra, amire nincsenek felkészítve. Nincs elég VRAM rajtuk. De a megoldás nem az, hogy raksz rájuk sok GB-ot, hanem az, hogy azt a memória- és erőforrás-pazarló működést megszünteted. Ez már csak azért is fontos, mert ugye a nextgen konzolról jönnek át majd az új portok, azokban extrém geometriai terhelés lesz, és eközben akkor is számolni kell egy rakás tartalmat, ha a kamera rá sem néz. Ez butaság. Ha a rendszert erre építjük, akkor a nextgen RT-t alkalmazó portokhoz 50-60 GB-os VGA-k fognak kelleni, mert a PC-s szabványos rendszer nem tud kivágni és LOD-ot változtatni. Ezért nem alkalmaz egyik konzol sem fixfunkciós bejárási lépcsőt. Ha így tennének, akkor ott is gyűlnének ám a felesleges gigabájtok a memóriában, de ugye van a hülye brute force megoldás, és az okos. És a fixfunkciós egység ugyan jóval gyorsabb lehet, de a programozhatósággal meghatározhatod, hogy csak a szükséges dolgokat számold. Ami a teljes számítás egy töredéke lesz, mert a kamera nem lát mindent, és amit nem lát azt nyugodtan ki lehet vágni (kinek számolod, ha nem látszik?), vagy ami messze van, arra nyugodtan mehet egy alacsonyabb LOD szint, amit akár a sugár kilövése után is lehet változtatni.
-
Abu85
HÁZIGAZDA
Érdekes. A Godfall esetében nem voltál ennyire kibékülve azzal, hogy messzire lőtték a sugarakat. Akkor baj volt vele. Most már megbékéltél ezzel is? Mert őszintén szólva szerintem, és tényleg csak szerintem, a Godfall pont elképesztően sokat profitálnak az Intel megoldásából. Gigabájtokban mérhető memóriát spórolnának vele, miközben a képminőség semmit sem romlana.
-
Abu85
HÁZIGAZDA
Tehát teljesen jó, hogy egy eljárás 3-7 GB VRAM-ot el tud pazarolni a semmiért? Oké, nincs több kérdésem.
Az a baj, hogy ez nem gyártói vita. Minden VGA be tudja szopni a 3-7 GB-os extra VRAM használatot, és az ezzel járó extra terhelést, méghozzá csak azért, mert szar a rendszer. És ha megnéznéd azt az előadást, akkor meg is értenéd, hogy miért. De ha azért nem vagy hajlandó megnézni, mert az Intel csinálta, akkor úgy alakítasz ki véleményt, hogy az API problémáit nem ismered.
Megjegyzem, az NV-nek is pont ugyanaz a véleménye, mint az Intelnek és az AMD-nek. A DXR aktuális állapota híg fos, mert őket is pont ugyanúgy érinti az extrém pazarló memóriahasználata, mint az Intelt és az AMD-t. Sőt, a GDDR6X miatt őket jobban érinti.
-
Abu85
HÁZIGAZDA
Sokkal olcsóbban lehet jobb GI-t csinálni. Lásd az Unreal Engine 5 Lumen megoldását. Annak van szüksége RT-s GI-ra, aki nem elég okos, hogy ezt a problémát az erőforrások töredékéből megoldja. Nem viccből nem használnak ilyet a modern motorok. Sokat zabál, és az alternatíváknál nem jobb. De persze, ha az erőforrásokat akarod pazarolni, akkor hajrá.
Pedig érdekelhetne, mert egészen jól elmondja az Intel, hogy miért fos most az RT. Csak egyszer nézd meg, és meg fogod érteni, hogy nem a hardver az oka, hanem az a pazarló munkavégzés, amire az API rákényszeríti a hardvert. Az Intel fel is vázolja, sőt, be is mutatja működés közben a megoldását.
-
Abu85
HÁZIGAZDA
Teljes körű RT van azokban is. A különbség, hogy a programozhatóságra van tervezve. Már elmondtam, hogy a traversal unit, ami hiányzik koncepció. Azért nincs benne, mert a traversal shaderrel használhatatlan. Nem lehet majd elérni a hardverben, ott fog porosodni a tranzisztorok között, egy hardveres /dev/null lesz.
Ugyanígy az Intelnek sem lesz fixfunkciós traversal unitja. Érdemes megnézni ezt az előadást. Nagyon jól bemutatja azt a gigantikus pazarlást, ami a gondot jelenti, ha a traversal lépcső nem programozható. Ha a pazarlást kilövöd a programozhatósággal, akkor sokkal több sebességet nyersz, mintha egy külön hardvert építenél a pazarlásra. [link]
-
-
Abu85
HÁZIGAZDA
válasz
awexco
#42886
üzenetére
Csak az EU nem akar architektúrákhoz kötődni. Pont az a lényege a stratégiánknak, hogy legyen architektúráktól független. Az egyes piacokra más dizájnnal fognak dolgozni. A szerverre ARM és RISC-V, míg a beágyazott piacra RISC-V. Az EU-s stratégia kulcsa eleve a gyártástechnológia, arra megy a nagy lóvé.
#42883 Busterftw : Az ARM székhelye az Egyesült Királyságban maradt. Valószínűleg az lesz, hogy adnak az NV elé egy szerződést, hogy milyen feltételekkel engedik meg. Két lényeges tényező van az UK-nak:
- Maradjon az ARM székhelye az Egyesült Királyságban, és az NV-nek csak a leányvállalata legyen.
- Az NVIDIA nem vihet be saját technológiát az ARM-ba, hogy az ARM-ot továbbra is csak az Egyesült Királyságon belül fejlesszék, így pedig az USA-nak sose lesz joga szabályozni a birtokolt IP-ket.Ha ezt a két tényezőt elfogadja az NV, akkor szerintem az UK is megadja az engedélyt a felvásárlásra. Ez egyébként még Kína szempontjából is hasznos lenne, mert ők nem éreznék fenyegetve magukat, ha az NVIDIA-nak az UK szerződésben tiltaná meg, hogy hatalma legyen az ARM felett. Kérdés, hogy így minek kiadni 40 milliárd dollárt...
-
Abu85
HÁZIGAZDA
Az NV erre nem apellál. Ők a médiapistikkel ellentétben felfogják, hogy a Google számára a Stadia elképesztően kis költség. Ki vannak építve a peremhálózatra a szervereik, amikbe csak GPU-t raknak, és a szabad kapacitást használják a Stadiához. Az egésznek a lényege az, hogy elképesztően kevés extra fenntartási költséggel tudnak több pénzt visszatermelni a Stadia store-on keresztül. A Stadiának akkor lesz baja, ha a Google keresőszolgáltatása leáll, ugyanis akkor nem fognak kelleni a Stadiát működtető szerverek.
Ugyanez van a Microsoftnál és az Amazonnál is. A cloud gaming irányuk egy kiegészítés a meglévő szerverek szabad kapacitásának kihasználására. Költségben nem sok extrát visz, miközben a saját store-ral sokat hoz. -
Abu85
HÁZIGAZDA
válasz
Raggie
#42808
üzenetére
Igazából ez nem driver overhead. Ezek DirectX 12-es címek. Van a meghajtónak némi többletterhelése, de megközelítőleg sem annyi, mint DirectX 11-ben. Az alkalmazás gondoskodik egy rakás olyan feladatról, amit korábbi API-knál a driver csinált. Ergo a többletterhelés igazából az alkalmazáson belül keletkezik, nem a driverből. Ezt is meg lehet magyarázni, főleg amiatt fordulhat elő ilyen, hogy egy játékot Radeonokon fejlesztenek le, és nem ellenőrzik a Radeonnal detektált problémákra adott válaszokat, hogy azok mennyire működnek optimálisan GeForce-on. Ez is gond, de nem a driver az oka. Ezt leginkább per alkalmazás szinten kell leprofilozni és javítani. Az más kérdés, hogy egy fejlesztő a problémát tényleg akkora jelentőségűnek tartja-e, hogy foglalkozzon vele. Elvégre maga az alkalmazás hibátlanul fut, csak nem olyan gyorsan, mint elvileg futhatna.
-
Abu85
HÁZIGAZDA
Akkor nézd meg. Attól még nem lesz valami külső tér, mert a szabad ég alatt játszódik. Ezernyi trükk van, hogy épületekkel körbevedd a területet, és ezzel megteremted magadnak a zárt tér hatását.
#42790 tisztelturam : Attól függ, hogy szabványosan lesz-e implementálva bele a sugárkövetés. A legtöbb játékban a DXR-rel van ez megoldva, de az AMD-nek van egy zárt kiterjesztése a DXR-hez, amivel olyan dolgokat is elérhetnek a fejlesztők, amelyek még nem részei a szabványnak. Minden esetben a Radeon Rays 4.0-t lehet meghívni, ez egészíti ki a szabványt. Ennek két külön módja van, amiről itt egy rövid leírás:
Ha utóbbi kerül egy játékba akkor kap egy külön dll-t, lásd a Godfallban az "amdrtshadow.dll", ebben vannak a szabványból hiányzó részek, például egyedi BVH bejárás. Ha így lesz implementálva a Resident Evil is, akkor azt az NV nem tudja majd futtatni, tehát kell nekik egy külön szabványos implementáció, ami megkerüli a binárisan szállított dll részét a játéknak.Szimpla API interop valószínűleg alkalmazva lesz, de az a jobbik eset, mert az csak intrinsic lehetőség, tehát maga a shader nagymértékben szabványos, csak vannak olyan részei, amelyek az AMD dizájnján meghívnak egy beépített függvényt, és akkor gyorsabban fut. Így van alkalmazva az RT a Dirt 5-ben és az új WoW: Shadowlands frissítésben. Ezeknél a kódoknál a beépített függvényeket az NV ugyan nem éri el, de elég könnyű kezelni ezt a problémát, mert csak írni kell rá pár extra shadert. Emiatt az RR 4.0 szimpla API interoppal nem akkora gond, mintha tényleg egyedi BVH bejárásra használná a Radeon Rays 4.0-t egy játék. Intrinsic lehetőségnél csak kismértékben kell módosítani a kódot, hogy szabványos szinten is fusson. A Godfall esetében azért marha sok munka volt teljesen eltérő LOD kezelést implementálni, mert a flexibilis LOD-ot a DXR nem kezeli, tehát kidolgoztak helyette egy DXR-rel kompatibilis sztochasztikus LOD eljárást. Ennek hasonló az eredménye a memória terhelésére vonatkozóan, csak többet számol, mint a flexibilis LOD.
#42791 huskydog17 : Semmiféle exkluzív szerződés nem volt. A Godfallba egy olyan algoritmus került eredetileg a bejárásra, amit a szabványos DirectX Raytracing nem támogat. Nem megvalósítható az aktuális specifikációkkal a flexibilis LOD. E mellé implementáltak a szabványos kódba egy sztochasztikus LOD eljárást, amit már megenged a DXR. A memóriaigény tekintetében a flexibilis és a sztochasztikus LOD hasonló, csak utóbbi eljárás elvégzéséhez többet kell számolni.
#42796 Locutus : Nem véletlen. A 8 GB-os VRAM igényt már nem egy játék meghaladta az Ampere kiadása előtt. Azóta csak nőttek a lehetőségek, így lassan meghaladtuk a 10 GB-ot is. Ezzel pokoli nehéz mit kezdeni, de ezért vannak a grafikai beállítások. Ha elfogy a memória, akkor lejjebb kell venni a grafikai részletességet. Régen is ez volt a megoldás, és ma is.
-
Abu85
HÁZIGAZDA
Nem a kizárólagosság a lényeg, hanem a pályadizájn kialakítása. Ezt leírtam neked először, hogy külső tereknél külön lehet arra dizájnolni, hogy belső tereknek megfelelő legyen a kialakítás. A CP2077 tipikusan ilyen játék. Egyedül akkor vannak dizájn szinten külső terek, amikor elhagyod a várost. Itt látszik is rajta, hogy az effektek nem működnek olyan jól.
-
Abu85
HÁZIGAZDA
válasz
Busterftw
#42783
üzenetére
Semmi, a játékdizájn részei az effektek. Alapvetően a fejlesztők döntenek arról, hogy mire paramétereznek. Az optimális az lenne, ha lenne külön dizájn a belső terekre, illetve egy teljesen eltérő a külső terekre. Csak ennek a megvalósítása aránytalanul sok befektetést igényelne, így az effekteket alapvetően egy dizájnra alakítják ki, arra amelyikkel a játékos arányaiban a legtöbbször fog találkozni. A CP2077 esetében a belső terek, míg a Godfall esetében a külső terek. Ennek megvannak a hátrányai az ellentétes pályadizájn esetében, de nem éri meg vele törődni, mert túl drága lenne a problémák megoldása. Emellett a minőségi ugrás nem feltétlenül lenne arányban a befektetett munkával.
-
Abu85
HÁZIGAZDA
Tudom miről beszélek. Arra próbálsz koncentrálni, hogy a játékmenet bizonyos százalékában találsz nyílt terepet, de nem ez a döntő tényező az effektek dizájnjának kialakításakor. Okkal néz ki a CP2077 zárt térben sokkal jobban, mint nyílt térben. Egyszerűen az effektek dizájnját zárt térre tervezték, és ez nem működik olyan jól nyílt térben. De ettől még vannak nyílt terek benne, csak nem ez volt a fókusz. A Godfall esetében pont ezek voltak fókuszban, mert arányaiban több nyílt térrel találkozik a játékos, mint zárttal. Emiatt a Godfall inkább zárt térben nem működik olyan jól.
-
Abu85
HÁZIGAZDA
Nem madártávlatra tervezik ezeket, hanem játékmenetre. A Cyberpunk 2077 nagy részében nem látsz el messzire, vagy zárt térben vagy, vagy megakadályozzák az épületek. A Godfall esetében nincsenek épületek, ott sűrűbben nagy a látótávolság. Más dolog az eltérő dizájnra effekteket tervezni. A Cyberpunk 2077 esetében tök reális lekorlátozni a sugárkövetés távolságát, mert a játékmenet nagy részében ezt nem veszed majd észre. A Godfall esetében nehezebb ügy. Alapvetően minden fejlesztő a korlátozást választaná, mert az csak egy napnyi munka. Senki sem szeret egy effektért fél évet dolgozni, de ritkán megteszik, ha nagyon fontos az effekt minősége. Ettől persze le lehet őket hurrogni, hogy miért optimalizálnak, de a saját idejüket lövik el erre.
-
Abu85
HÁZIGAZDA
A kép jól mutatja a dizájnt. Körül vagy véve az épületekkel, tehát nem kell túl messzire lőni a sugarakat. A Godfallban nem tudod körülvenni a játékteret épületekkel, nem a modern korban játszódik. Nem tudsz ilyen hatékonyan trükközni.
Nem számít a memória terhelésénél, hogy hány effektet futtatsz, mert mindegyik ugyanazokat a sugarakat használja. Nem fognak minden effekthez külön sugarakat kilőni. A memóriahasználat kizárólag attól függ, hogy mennyire messzire lövöd a sugarakat. És itt jön képbe a pályadizájn. A Godfall esetében is könnyebb lenne, ha nagy házakkal vehetnék körbe a játékteret, dehát...
És a Godfall is használhatna több effektet lényegében extra memóriaigény nélkül, de Unreal Engine 4-en fut, aminek a gyári SSR-je és SSAO-ja eleve nagyon jó.
-
Abu85
HÁZIGAZDA
Közel sem a végtelenbe számolnak. Egy játék három kategóriába eshet a pályadizájn tekintetében. Lehet a pályatervezés zárt, nyíltnak imitált zárt és nyílt. Az első kettő esetében reális dolog korlátoznia sugárkövetés távolságát, mert már maga a pályadizájn korlátozott. A Godfall esetében ez azért nem működne, mert a pályadizájn egészen nyílt, túl sokszor túl nagy terek vannak benne ahhoz, hogy jól működjön a jellemző limitálás. Emiatt választottak más módot, és nyilván nem jószántukból döntöttek így, mert nekik is sokkal egyszerűbb lett volna azt mondani, hogy a sugárkövetést tart 4 virtuális méterig és kész, mint konkrétan kidolgozni kétféle algoritmust, és elverni az egész probléma megoldáásra kb. fél évet. Ez tehát egy pályadizájnból eredő döntés. Más játékban, például a Cyberpunk 2077-ben nem feltétlenül ez a jó döntés, mert ott a városi nyílt terek is úgy vannak felépítve, hogy a lehető legtöbb oldalról körül vannak zárva. Természetesen ez egyszerűbbé tesz bizonyos fejlesztői döntéseket, csak egy Godfallban nem tudsz felhőkarcolókat felhúzni a játéktérbe.
Az RT teljesítmény játékfüggő.
Az optimalizáció azt jelenti, hogy egy problémára kitalálsz valami olyan megoldást, ami segít az erőforrás optimális használatában. Ezt tette a Godfall is. Az nem optimalizálás, hogy négy virtuális méterre korlátozod a sugarak távolságát, ilyenkor pont elkerülöd az optimalizálást, hiszen meghúzol egy olyan mesterséges limitet, amivel szükségtelenné válik az optimalizáció. Természetesen sokszor ennek is van értelme, de ahogy fentebb írtam, nehéz a nagyon nyílt dizájnú játékokra ezt ráhúzni, de persze nem mindegy, hogy fél évig optimalizálsz, vagy egy nap alatt limitálod a számítást. Ez is a fejlesztői döntések része.
Mindenki annyi VRAM-mal rendelkező VGA-t vesz, amennyit akar, de az világosan látszik, hogy ezek az új technológiák VRAM-zabálók.
Semmi gond nem volt az NV-nek a tesszellációs megoldásaival. Saját vásárlóikat szopatták meg vele, miután az AMD a meghajtóban kezelte a problémát. De a kettő nem ugyanaz. A tesszelláció esetében a problémát az jelentette, hogy felesleges volt egy pixelnél kisebb háromszögeket generálni, mert ugye a pixel a legkisebb elem, amit a monitor meg tud jeleníteni. Itt nem felesleges a sugárkövetés távolságát kitolni, mert észreveszed a 10-15 virtuális méterre lévő dolgokat is. De ugye akinek ez nem annyira fontos természetesen kikapcsolhatja az effektet.
-
Abu85
HÁZIGAZDA
A Godfall fejlesztőit lehet bántani, de tény, hogy ők az egyetlenek, akik szabványos kóddal raktak sztochasztikus LOD-ot a játékukba. Más erre sem veszi a fáradtságot, mert egyszerűen túl soknak tartják az ezzel járó bő négy hónapnyi munkát. Inkább lekorlátozzák a sugárkövetés távolságát, mert azzal is vissza lehet fogni a memóriahasználatot. Jelen pillanatban éppen azokat a fejlesztőket trágyázod, akik a piacon egyedüliként nem az egyszerű megoldást választották, nem a sugárkövetés távolságát limitálták, hanem igenis belefektettek egy rakás erőforrást, hogy más módon csökkentsék a memóriahasználatot. De eközben mindenki azért sír, hogy a PC-be nem fektetnek a fejlesztők semmi energiát. Hát persze, hogy nem. Beleölsz valamibe négy hónapot, és csak trágyázzák a megoldásod, amikor egy nap alatt meg tudnád oldani az effekt minőségének jelentős korlátozásával, amiért a userek simogatnak.
Hardveresen nincsenek igazán problémáin. Szoftveres tényezők hiányoznak. A traversal shader igazból bármilyen compute shadert támogató hardveren üzemképes. Az összes hardveres RT-t támogató rendszerrel kompatibilis, mert csak annyi történik, hogy a futószalag bejárás lépcsője nem egy specifikus hardveren fog működni, hanem a multiprocesszorokon, ugyanis programozhatóvá válik. Erre az AMD és az NV is tud meghajtókat írni, hiszen csak a futószalagot kell a multiprocesszoron futtatni, és kész, a shader fordítót kell kiegészíteni az új shader lépcsővel. Nem egy megoldhatatlan probléma, csak ki kell dolgozni a specifikációt.
-
Abu85
HÁZIGAZDA
Amíg nincs itt a traversal shader, addig az RT egy memóriazabáló technológia. Korábban leírtam, hogy miért. Egy sugár kilövésekor ki kell választani a LOD szintet, de előre nem tudod, hogy mennyire távoli lesz a metszés, tehát nem tudod meghatározni, hogy mi az optimális LOD szint. Ergo egyszerű megoldásként mindenre kiválasztod a LOD0-t, ami jókora extra információt jelent a VRAM-on belül. Egyedül a GodFall működik másképp, és jól jelzi, hogy mekkora nehézség ezt szabványosan megoldani, mert több hónapig csak ezt fejlesztették, hogy működjön a GeForce-okon. A Radeonokon ugye egy zárt kiterjesztést használnak, ami megengedi azt, hogy a sugár kilövése után LOD-ot válts. Ez lesz majd a traversal shader haszna szabványosan.
Amíg a játékok csak elsődleges sugarakat használnak, addig van koherencia, így a memória-sávszélesség nem akkora probléma, mert a memóriaelérések nem annyira véletlenszerűek. Ezek onnantól kezdenek el gondot okozni, ha vannak másodlagos sugarak is, azok már nem koherensek, és például a DXR 1.1 egyik visszalépése, hogy nem is tudod ezeket koherens csoportokba gyűjteni. De a Microosft mégis a DXR 1.1-re állt át, mert figyelembe vette, hogy ma még a másodlagos sugarakat nem igazán fontolják meg a fejlesztők, így a DXR 1.0 előnye hasztalan, és van egy rakás hátránya, amit a DXR 1.1-gyel megoldottak. Valószínű, hogy sem a DXR 1.0, sem a DXR 1.1 nem jelenti a jövőt, hiszen hosszabb távon azért erősen korlátozzák a lehetőségeket, de egyelőre nincs jobb megoldás.
Számítási kapacitás kell az RT-hez, de nem ez jelenti az erős limitet. Sokkal nagyobb baj, hogy nem tudsz LOD-ot váltani egy sugár kilövése után, így pedig akármilyen RT effektet írsz, az mindenképpen zabálni fogja a VRAM-ot.
A Resident Evilben többféle RT lesz. Pont emiatt lő ki a memória terhelése. Maga a motor eleve egy VRAM-zabáló szörnyeteg volt, ezt már a korábbi RE címekben is lehetett látni. 4K-ban RT nélkül is megette a 13 GB-ot. Ugyanez a motor lesz most is, csak átrakják a memóriakezelést az AMD-féle D3D12MA-ra, ezzel nyernek némi hatékonyságot, de nagyobbak lesznek a textúrák, amivel buknak is. Plusz mostantól az RT effektek jellemző +2 GB-ja is hozzájön. Értik, hogy kevés VGA-n van ennyi memória, de most ezzel mit kezdjenek? Annyit tudnak tenni, mint a korábbi RE címekben, lesz benne egy dinamikus textúraskálázás, hogy ha nem fér bele a VRAM-ba a highres textúra, akkor a motor azt érzékeli, és legközelebb már a medium vagy low részletességet tölti be, hogy spóroljon. Jelen pillanatban ez a reális megoldása a problémának, aztán idővel lesznek több VRAM-mal rendelkező VGA-k.
#42770 do3om : A memóriasávszél gond, ha egy játék másodlagos sugarakat is használ, hiszen ott véletlenszerű az elérés, tehát nem jól cache-elhető az információ. De ehhez muszáj másodlagos sugarakat is használni. Elsődleges sugarakkal marad a koherencia, tehát jól cache-selhető adatról van szó. Ezt korábban is leírtam. Az AMD számára az elsődleges sugarak megfelelőek, hiszen van a GPU-kban egy rakás cache, és úgy a sávszélesség 1,6+ TB/s. A másodlagos sugarakkal van gondban az RDNA2, de ezek pusztán a koherencia hiánya miatt eleve nem elterjedtek manapság a játékokban, mert a nagyon véletlenszerű adateléréshez nincs meg a kellő sávszél egyik mai hardveren sem.
-
Abu85
HÁZIGAZDA
Nem kell ennyire parázni. Ez az AMD javaslata, ami marketing. A játék RT effektje bármilyen VGA-val jól fog futni, amin legalább van 12 GB VRAM. Persze nem biztos, hogy 4K-ban, ott 12 GB-nál több VRAM kell, de 1440p-ben bele lehet férni 11 GB-ba.
RT nélkül a VRAM-igény is 10 GB alá csökken.
-
Abu85
HÁZIGAZDA
válasz
FLATRONW
#42740
üzenetére
Ez egy időbeli probléma csak, a funkció működik, de be kell paraméterezni. Azért lát az NV lassulást, mert ez még hiányzik az egyes játékokra. A gond az, hogy az AMD a SAM-et 2019 elején kezdte el fejleszteni. Az NVIDIA 2020 nyarán. Egyszerűen hiányzik az a másfél év, ami alatt az AMD kitesztelte az összes játékot. 2022 közepére az NV is el fog érni az összes címig, addig fokozatosan hozzáadják az egyes címeket. Sajnos a paraméterezés az pepecselős meló. Le kell ülni, és egyenként be kell lőni az egyes játékokra a működést. Ezt nem lehet siettetni. Amint kész lesznek ezzel a melóval, az NV sem fog lassulást látni a játékokban. Minimális eltérés egyébként bármikor előfordul, de ha 3%-on elül van az mérési hiba is lehet.
#42739 AsakuraDave : A 3060-ra fel van rakva a VBIOS. A többi hardverre még nem készült el, de nem ez a prioritás jelenleg, hanem növelni kell a támogatott játékok számát.
-
#42738
Abu85
HÁZIGAZDA
AsakuraDave
#42737
Abu85
HÁZIGAZDA
válasz
AsakuraDave
#42737
üzenetére
Ha Founders Edition, akkor március végén jön hozzá a VBIOS, ha nem referencia, akkor Q2-ben hozzák a gyártók. De ha nem azon a nyolc játékon éppen nem játszol, amit az NV támogat, akkor felesleges vele foglalkoznod még. Az NV megoldása egyelőre nem olyan, amilyen az AMD-é, hogy minden szoftveren működik. Fokozatosan kerül hozzáadásra a szoftverek támogatása. Egyelőre erre a nyolc játékra van korlátozva: Assassin's Creed Valhalla, Battlefield V, Borderlands 3, Forza Horizon 4, Gears 5, Metro Exodus, Red Dead Redemption 2 és Watch Dogs: Legion
-
Abu85
HÁZIGAZDA
válasz
Locutus
#42716
üzenetére
Nekem volna. A GeForce mikrokódból vágják ki a lop3 utasítást. Ezzel a bányászat melletti tempó jelentősen mérséklődik, de ami ennél is fontosabb, hogy maga a hatékonyság is óriásit esik vissza a hash algoritmusok futtatásakor, hiszen ezt igazából a lop3 lapátolja össze. És ez a változás megkerülhetetlen. Az eredménye ennek az lenne, hogy az EtHash nagyjából a mostani számok tizedét hozná csak, miközben a hardverek fogyasztása igen magas maradna. A problémát valószínűleg az jelenti, hogy nem csak bányászatra használnak hash algoritmust, és a lop3 kilövésével kilőnék az alternatív felhasználást is.
#42717 Valdez : Ez is opció.
-
#42709
Abu85
HÁZIGAZDA
huskydog17
#42708
Abu85
HÁZIGAZDA
válasz
huskydog17
#42708
üzenetére
Mit számít ez? A valóságon nem változtat, ha elrejtik egy függöny mögé.
-
Abu85
HÁZIGAZDA
A másik topikban belinkelt videódban látszik az eltérés több helyen is. [link]
A részletek a lényegesek, mert az árnyékok raszterizálás mellett az apró részletekben csúsznak el. Egyszerűen mag a raszterizálás nem igazán alkalmas a jó minőségű megvalósításra, a frustrum tracing pedig drágább eljárás, és konzervatív raszterizálást igényel.A videóban ezeket érdemes nézni:
- 1:20-21-nél a növény a két kép közepein. RT-vel a finom geometriákon is van árnyék. Ez általánosan is látható a fákon is. A háttérben látszódó kis épület is jobban van árnyékolva.
- 1:38-nál van a jelenetben egy rakás árnyék, és nagyon jól látszik, hogy RT nélkül mennyire erősen kell alkalmazni a lágy szélű árnyékolást. A valóságban ennyire gyorsan nem vesznek el a részletek, csak sokkal messzebb vetülő árnyéknál. Az RT-s megoldás megőrzi a részleteket, de mégis lágy szélű. Ez szintén megfigyelhető több helyen is.Ezek azok az apró problémák, amelyekre raszterizálással egyszerűen képtelenség reagálni. Trükközheted napestig, de sosem éred el azt a minőségi szintet, amit az RT shadows tud adni. Ráadásul utóbbit nagyságrendekkel egyszerűbb implementálni.
Ha messzire lövöd a sugarakat, akkor az kellemetlen a LOD számára. Az RT a jelenlegi specifikációban egy memóriazabáló dolog, hacsak nem maradsz nagyon a kamera közelében, de ezt a játékot nem úgy tervezték, hogy szűk terek legyenek benne, tehát nincs különösebb választás, muszáj sokáig lőni a sugarakat. Az más kérdés, hogy lehetne low szint is, ahova elég lehetne 1 GB VRAM is, azzal nem enne az effekt 3 GB-ot, de sokkal rosszabb is lenne a minősége, hiszen előtted jelenne meg pár méterre minden árnyék. Effektíve úgyis visszakapcsolnád a raszterizált verziót, mert az lehet, hogy nem kezeli jól az árnyékokat, de legalább nem csak a virtuálisan 4-5 méteres körzetedben lesznek láthatók.
Van a Godfallban teljesen dinamikus GI, a Sony-val közösen dolgozták ki az alapul szolgáló effektet. Az RT esetében az a lényeges kérdés, hogy meg tudod-e oldani a jó minőséget nélküle. Sok eljárásra meglehet, például GI-ra height field vagy distance field GI, visszaverődésre hibrid SSSR. De árnyékra sajnos nincs semmi értelmes megoldás.
-
#42702
Abu85
HÁZIGAZDA
AsakuraDave
#42701
Abu85
HÁZIGAZDA
válasz
AsakuraDave
#42701
üzenetére
Nem más szögből süt, hiszen ez egy fejlesztői kép, ahol direkt pont ugyanúgy vannak beállítva a fényforrások. De pont ez a lényeg, hogy az árnyékoknál RT nélkül az apró részleteket nem tudod normálisan megvalósítani. Egyszerűen a kapott eredmény torz lesz, és raszterizálásnál esélyed sincs, hogy ezen reális körülmények szintjén javíts. Vannak persze bizonyos trükkök, mint például a frustum tracing, de az az RT-nél is nagyobb teljesítményigénnyel rendelkezik.
Emiatt repült rá sok fejlesztő az RT árnyékokra, mert a problémát ezeknél az effekteknél csak RT-vel lehet kezelni. Más effekteknél vannak nagyon jó alternatívák, de az árnyékok túl nehezen alkalmazhatók. -
#42700
Abu85
HÁZIGAZDA
AsakuraDave
#42698
Abu85
HÁZIGAZDA
válasz
AsakuraDave
#42698
üzenetére
A Hitman 3 az nem szimpla SSR, hanem egy hibrid megoldás, aminek az alapja SSR, de ezt kiegészíti még render to texture, illetve némelyik felületre elég a cube map, és az is van rajta. Használhattak volna RT-t is, csak lassabb sokkal, és nem ad többet.
Itt van a Godfall RT:
On:
Off:
Az RT a tipikus gondokra tud reagálni. Képesek vagyunk alapvető árnyékot kreálni nélküle, de nem tudunk pontosat. Egy csomó hiba lesz az árnyékok szélével, sokszor ez nem elég éles, vagy nem elég lágy, nem elég erős az átmenet, stb. Ezeket nagyon nehéz RT nélkül kezelni. És azt is, ahova kellene árnyék, de az istenért se tudod beműteni. RT-vel ezek egyszerűen mennek.
Ugyanez van a Dirt 5-ben is RT-vel:
On:
Off:
Ezek mind olyan apró problémák, amelyekre a raszterizáláson belül nincs válasz. A visszaverődéssel még lehet jól trükközni, ahogy a GI effektekkel is, de az árnyékoknál a raszterizálásának egészen durva határai vannak.
-
#42697
Abu85
HÁZIGAZDA
AsakuraDave
#42696
Abu85
HÁZIGAZDA
válasz
AsakuraDave
#42696
üzenetére
Cyberpunk lelépezője nem valami jó. Sok, nagyon régi technológiát használ, amelyeket a mai motorok már bőven leléptek. Ezért számít a visszaverődés. De ha olyan SSR-t használna, amilyet mondjuk a Godfall, akkor messze nem vennéd észre a különbséget.
A Godfall az árnyékoknál azokat a dolgokat számolja RT-ben, amit nehéz raszterizálással megoldani. Szinte lehetetlen. Nagyon sok munkával közel lehet kerülni, de egyszerűbb leimplementálni RT-vel. -
#42695
Abu85
HÁZIGAZDA
huskydog17
#42694
Abu85
HÁZIGAZDA
válasz
huskydog17
#42694
üzenetére
Ez nem a leképezőn múlik. Attól függ az egész, hogy építenek-e be olyan játékmenetbeli elemet, ami igényel komolyabb szimulációt. Ha nem, akkor felesleges ezekre erőforrást pazarolni.
-
#42693
Abu85
HÁZIGAZDA
AsakuraDave
#42692
Abu85
HÁZIGAZDA
válasz
AsakuraDave
#42692
üzenetére
A memóriaigény 4K-ra van megadva. 1440p-ben csökken memóriaigény, így nem kell már 12 GB. Emellett a Primal update bevezet egy új textúramenedzsmentet. Ha nincs elég VRAM a VGA-n, akkor elkezdi dinamikusan csökkenteni a textúrák méretét, így nyerve extra kapacitást az RT shadow effektre, ami önmagában 3 GB körüli VRAM-igénnyel rendelkezik.
Az árnyékok jelentik a legnagyobb problémát, amit nem lehet RT nélkül megoldani. Minden más problémára van gyorsabb, hasonló minőséget adó alternatíva. Sőt, a Far Cry 6-ban az Ubisoft bevezet majd egy hibrid SSSR-t. Az lényegében az RT visszaverődés effektekhez hasonló minőséget ad, csak negyedannyi erőforrásigény mellett, töredék memóriahasználattal. Egyébként lehetne alkalmazni jó hatékonysággal RT-t az árnyékokon túl is, de egyszerűen nincs még traversal shader, amivel visszafogható lehetne a memóriahasználat. Utóbbi a legnagyobb probléma, mert ha nem tudod a LOD-ot megfelelően kezelni, akkor jobban jársz egy trükkös implementációval mondjuk a visszaverődésre, mert az RT-s megoldás csak a kamerához nagyon közel működhet kevés VRAM terheléssel. Az Ubisoft főleg emiatt a probléma miatt vetette el az RT reflectiont a Far Cry 6-nál. Elképesztően limitált a mostani API.A Flight Simulator is viszonylag jó. A legnagyobb problémája az, hogy elavult API-t használ, mert a motor alatta sok éves.
A The Coalition a Microsoft tulajdona, ezért fértek hozzá az Unreal Engine Microsoft által módosított változatához, ami jelentősen átírt ám, emiatt fut sokkal jobban, mint a gyári. -
Abu85
HÁZIGAZDA
Az AMD csak hozott pár jó döntést a múltban, és most úsznak az árral. Az NVIDIA is meghozhatta volna ugyanezeket a döntéseket, és ugyanúgy fordíthatnák az új pipeline-ra a régi shadereket.
Azért kevés cég optimalizál jobban PC-re, mint a Microsoft. Nem véletlenül fut elképesztően jól a Gears 5.
-
Abu85
HÁZIGAZDA
Ez mindig így volt, amíg egy új, de nagyon drágán hasznosítható technológiából csak a potenciális vásárlóbázis töredéke jut előnyhöz, addig nem is igazán piszkálják a fejlesztők. Vannak nagyobb gyorsulás biztosító, jóval olcsóbban beépíthető újítások. Ezeken lesz a fejlesztői fókusz. A VRS itt a fő irány mostanság. És már olyan formában is létezik, amihez nem kell VRS-t támogató hardver.
Szimplán compute shaderben le van implementálva. Az új Call of Duty ezt használja, és minden DirectX 12-es VGA-n megy.Szorgalmazni lehet, de ha nem fizetnek százezer dollárnyi zsetont a kód karbantartására, akkor senki sem fog veszteséget bevállalni egy gyártóért. Egyszerűen nem jön ki pozitívra a mérleg, és így nincs értelme erre dolgozni. Gondolod véletlenül maradtak ki a mesh shaderek a PC-s portokból? Nem. Egyszerűen kurva drága beépíteni és karbantartani. Gondolkodj egy fejlesztő szemével. Van egy büdzsé gyorsítani a kódon valami új technológiával. A mesh shaderre írt culling a mai geometriai komplexitás mellett nagyjából képes eredményezni úgy 2-3%-nyi gyorsulást. Ezért +50 ezer sor beírása és költséges karbantartása kell. Ezzel szemben mondjuk a VRS képes biztosítani 5-15% közötti gyorsulást. Az implementációs költség a már elérhető kódoknak hála minimális, sokszor csak copy-paste az egész, és a karbantartási költség sem magas. Nyilván azt választják, ami olcsóbb és nagyobb gyorsulást hoz.
-
Abu85
HÁZIGAZDA
Alapvetően az AMD-nek mindegy, hogy van-e mesh shader egy játékban vagy nincs. A legacy kódokat mindenképpen szállítani kell, és azokból tudnak NGG módba fordítani az 5700-asokra is. Az RDNA 2 pedig megeszi a mesh shadert.
A fejlesztők számára nem kell az AMD kímélete. El tudják dönteni, hogy belefér-e +50 ezer sornyi kódot írni, és ezt folyamatosan karbantartani a vásárlóbázis maximum 10%-ára. Nyilván az AMD is átgondolta ezt a kérdést, és arra jutottak, hogy a magas költségeket figyelembe véve nem éri meg. Nem véletlenül tervezték úgy az RDNA2-t, hogy majdnem minden vertex és geometry shadert NGG-be fordítson a fordító. Ugyanígy gondolhatott volna erre az NVIDIA is. Egyébként létezik mesh shadert használó játék már. A Gears 5 Xbox Series S/X frissítése erre épít. Megvan írva a teljes kód, és azt se hozza át a Microsoft PC-re, mert jelentős többletköltsége lenne a support oldalán. Egyszerűen a vásárlókból nem termelik ki. Ehelyett olyan megoldásokat portolnak vissza PC-re, mint az új VRS. Az legalább a support költséget nem növeli jelentősen, és abból is lehet nyerni egy rakás teljesítményt. Talán többet is, mint a mesh shaderből, miközben a költségek szintjén olcsóbb. Persze a Microsoft igazán kinyithatná a pénztárcát a mesh shaderre, hiszen nagyságrendekkel nagyobb anyagi tartalékaik vannak, mint bárki másnak, de osztottak-szoroztak, és egyszerűen nem éri meg, még úgy sem, hogy a portolás copy-paste lenne.
A mesh shader akkor kezd majd igazán terjedni, amikor a vásárlóbázis 60%-a is el tudja majd érni. Addig igazából pénzkidobás fejlesztői szemmel. Nekem sem tetszik, de ez van. Némelyik fícsőr beépítése olcsó (például VRS), némelyiké pedig költséges.
-
Abu85
HÁZIGAZDA
válasz
atok666
#42682
üzenetére
Az UL megkérhette őket, hogy ennek a tesztnek a shadereit ne fordítsák a mesh/primitive pipeline-ba. Ez a 3DMark szempontjából fontos. Az AMD-nek ez nem sok munka, mert ki tudnak jelölni a meghajtóban egy programot, aminek az indítását detektálják, és annak egyes shadereit legacy futószalagra fordítják. Akinek ezzel sok dolga lesz az az UL, hiszen az AMD meghajtójára így muszáj engedni az "alkalmazásspecifikus optimalizálást", és ha köcsög az AMD, akkor elkezdik lecserélni a 3DMark többi shadereit is, ezzel nyerve 2-3 ezer pontocskát per kártya. Ezt majd az UL-nek folyamatosan ellenőriznie kell.
#42684 b. : Az AMD-nek jók mesh shaderrel és anélkül is a portok. Úgy van felépítve a hardverük és a fordítójuk, hogy minden esetben az NGG módban fut a program. Ha most egy fejlesztő a vertex/geometry shaderek mellé akar írni mesh shadereket is, akkor csak nyugodtan. A stúdióknak és kiadóknak fog jelentősen nőni a játékra levetített support költség nem az AMD-nek.Egyébként a legnagyobb gond, nem az, hogy nem tudsz mesh shadert írni, hanem, hogy az átállás nagyon drága. Egyrészt minden geometriára vonatkozó shadert kétszer kell megírni. Egy komplex játéknál az simán +50 ezer sor. Másrészt mindkét kódbázist szállítani kell, mert a legacy kártyákat támogatni kell. Az tesztelés szintjén dupla munka, ami végeredményben megduplázza a support költséget. Szóval ez nem egy olyan döntés, amit egyszerű meghozni. Ha nincs meg az anyagi háttér a mesh shaderhez, akkor nincs értelme beépíteni.
-
Abu85
HÁZIGAZDA
Ezt valószínűleg az UL kérte, mert nem tudják befolyásolni a meghajtó működését, így a megfelelő százalékos gyorsulás kiértékeléséhez mindenképpen szükség van arra, hogy az AMD nem fordítsa a vertex/geomatry shadereket a mesh/primiive pipeline-ba. Ha megteszik, akkor a Radeonra nem tudja megmondani a tesztprogram a gyorsulás mértékét. Most, hogy kikapcsolták, meg tudja majd mondani. Nem kritikus fontosságú, de az UL számára fontos, mert ők képtelenek megkerülni a fordító működését. Csak az AMD tehet azért, hogy ez a teszt megfelelő értékeket adjon vissza a százalékos gyorsulásban. Az AMD ezt rohadtul leszarná, hiszen nekik aztán teljesen mindegy, hogy hány százalékot ír egy szintetikus teszt. Nekik a review policy-jük, hogy szintetikus teszteket senki se használjon. De nyilván meg tudják érteni, hogy az UL-nek ez bassza a csőrét, hiszen dolgoztak a programon, így átdolgozták a meghajtót, csak közben ez azért egy nehéz kérdés, mert az UL tiltja a 3DMark felismerését, tehát az AMD-t az egyik legfőbb szabály alól kellett felmenteni. Ez veszélyes az UL-nek, hiszen így az AMD-nek szabad a 3DMark felismerése, és manipulálhatják az alkalmazás futtatását, amit innentől folyamatosan ellenőriznie kell a finneknek, minden egyes kiadott Radeon driver után. Nekik sem lesz túl jó az élet innentől, havi két driverrel számolva, igencsak sok dolguk lesz.
-
Abu85
HÁZIGAZDA
Na jó hír a mesh shader tesztre vonatkozóan. Az AMD és az UL megegyezett, így a 21.2.2-es meghajtó már letiltja az NGG módba való shader fordítást. Ezzel már valóban lehet mérni az előrelépést, illetve mesh shadert is másképp fordítja a fordító. Sajnos még nincs hivatalos eredmény, de az UL egy szimpla 6800-ra 1600%-ot mért.
Némi torzítás még, hogy az intelligent workload distributor nem letiltható. Enélkül az AMD hardvere már nem működik, vagyis az NGG módból csak a shader fordítás kontrollálható, a feladatkiosztás mindenképpen az új generációs futószalagon megy a hardveren belül, mert a régi futószalag konkrétan ki lett véve a lapkából. Elméletileg ez csak kismértékben torzít.
-
Abu85
HÁZIGAZDA
A Radeon RX 6000 eleve NGG módba fordít. Nem lehet rajta megnézni, hogy mit tudna legacy pipeline-nal. Ezzel a 3DMark sem tud mit kezdeni. Lehet, hogy az AMD a legacy pipeline-t már teljesen leépítette a hardverben, így nem is tud működni hatékonyan az RDNA 2 a régi futószalagon. Erről elég kevés az adat, de valamiért a meghajtó fordítója a vertex és geometry shadereket is mesh/primitive pipeline-ba fordítja. Ezt a múltkor láttam az RGP-ben. Az AC Valhallában egyszerűen egyetlen vertex és geometry shadert nem fordít vertex és geometry futószalagra az RDNA2 fordítója. Mindegyiket átkonvertálja a driver mesh/primitive-be. És azok elég komplex shaderek, nem olyan egyszerűek, mint a 3DMarké ami szintetikus terhelésre van tervezve.
Ahhoz, hogy lássuk a százalékos gyorsulást az AMD-nek ki kell kapcsolnia az NGG módot a driverből. De nem fogják megtenni, a program pedig nem döntheti el, hogy hova fordít a meghajtó. -
Abu85
HÁZIGAZDA
válasz
imi123
#42664
üzenetére
Nem igazán maradt. Az UL már elmondta, hogy a százalékos érték a fontos, mert ez egy szintetikus teszt. A nyers fps semmit sem jelent önmagában, de számol a teszt egy százalékos adatot, hogy mennyit gyorsít a mesh shader. Persze az RDNA2 esetében ez is torz, leírtam a cikkben, hogy miért.
Az fps-t azért felesleges nézni, mert aszerint a GeForce GTX 1660 Ti megveri az RTX 3090-et. Közben a játékokban nem ezt látod. De ez egy szintetikus teszt, úgy lett felépítve, hogy a gyorsulást mutassa meg.
-
Abu85
HÁZIGAZDA
Ezerszer le lett írva, hogy a Steam survey egy nem reprezentatív statisztika. Semmiféle statisztikai módszertan alapján nincs kezelve. Oda van hányva egy csomó adat, amelyek már rég annyira tele vannak szemetelve, hogy használhatatlanok. A Valve-ot igazából nem érdekli, hogy ezt javítsa.
-
Abu85
HÁZIGAZDA
válasz
keIdor
#42543
üzenetére
Azok korábban jelentek meg. A gyártásukat még nyáron kellett fixálni. A 3060 gyártását decemberben fixálták, akkor már teljesen más volt a piac, mint a nyár közepén. Ennek megfelelően alakult a memória is. Az NV rendelhet ehhez is 1 GB-os GDDR6-ot, de egyrészt kevesebb van mennyiségben, vagyis hiányuk lesz, másrészt a 2 GB-os lapka alapvetően nem drágább, és van belőle bőven.
#42542 huskydog17 : Egyrészt a mobil 3080 az közelebb van az asztali 3070-hez a kiépítésben, mert GA104-es lapkát használ, másrészt a fogyasztása a normál mobil verziónak 150 watt.
-
Abu85
HÁZIGAZDA
válasz
keIdor
#42536
üzenetére
Nem pofájuk nem volt, hanem memória nincs hozzá elég. A GDDR6-nál a 2 GB-os stackekre nőtt meg az érdeklődés, és emiatt az 1 GB-os stackek gyártását gyakorlatilag visszafogta mindenki. Ez annyira durván megmutatkozik, hogy a 2 GB-os stack alig drágább, mint az 1 GB-os, ezért rendeli most mindenki azt. Majdnem ugyanolyan áron mennek, és 2 GB-os stackből még van elég is, míg az 1 GB-os stack ellátása limitált. Jelenleg ha akarnak se tudnak 6 GB-os verziót csinálni.
-
#42513
Abu85
HÁZIGAZDA
FollowTheORI
#42511
Abu85
HÁZIGAZDA
válasz
FollowTheORI
#42511
üzenetére
Nem nézték be, csak nincs natív libGNM implementáció PS5-ön, és ezek a játékok azon futnak. A libGNM-re írt kódot a PS5 egy wrapperen keresztül futtatja az új API-ján. Nyilván ennek nem valami jó a hatásfoka, de annyi nyers erő van a gépben, hogy könnyen elfedi a szoftveres rétegezésből eredő rosszabb hatékonyságot. Ha nyers teljesítmény kell, akkor át kell portolni a játékot a libGNM-ről.
Emiatt nincs egyébként PS5-ön ray tracing a Dirt 5-ben. A port igazából nem a natív API-ra van írva. A legnagyobb gond szerintem az, hogy az új API nem támogat legacy geometry pipeline-t. Tehát abban csak primitive shader van és kész. Ez még nem a világvége, de nem lehet minden vertex és geometry shadert csak úgy primitive shaderbe fordítani. Ez egyébként nagyon sokat ér, meg lehet nézni, hogy mit kihozott a Microsoft a Gears 5 natív Xbox Series S/X portjából. Ott elég rendesen használták a mesh shadert. Emiatt nem hozzák le ezt a portot PC-re, mert itt ugye két külön programkód is kellene. Egy a régi pipeline-ra és egy az újra. Az meg dupla support költség.
-
Abu85
HÁZIGAZDA
Kell a VRAM, csak nincs elég nagy kapacitású GDDR6X, hogy olcsón lehessen sok VRAM-ot rakni a VGA-ra. Ha csak 1 GB-os lapkákat gyárt a Micron, akkor verheti az NV az asztalt 2 GB-os variánsért, akkor sem tud adni a beszállító. Egyszerűen nem létezik még a kívánt termék.
-
Abu85
HÁZIGAZDA
válasz
Yutani
#42435
üzenetére
Az AMD is átírhatja a Quake 2 kódját, ahogy az NV tette. Az eredeti kód openszósz. Erről régebben kérdeztem őket, és RT-vel nagyjából annyi hozható ki, amit a Quake 2 RTX kihoz, de ennek a minősége elmarad a többi Quake 2 grafikai mód mögött. Például a Bersekerhez viszonyítva elég sok a különbség: [link]
-
#42428
Abu85
HÁZIGAZDA
huskydog17
#42427
Abu85
HÁZIGAZDA
válasz
huskydog17
#42427
üzenetére
Többeknek van már itt a fórumon. Ha megfizeted az árat, akkor mindkét gyártó VGA-it be lehet szerezni, de olyan drágák, hogy sokan nem fizetik meg. Megjegyzem nagyon helyesen teszik.
-
Abu85
HÁZIGAZDA
Az Ethereum 2.0 nem fog majd igazán jól futni GPU-n. De mire kivezetik a PoW rendszert, addig még eltelik három év, ameddig az Etheriumon lehet keményen bányászni egy GPU-val is. Emiatt ugranak egyre többen rá, mert most még van benne GPU-val kinyerhető pénz. Majd amikor csak PoS blokkok lesznek, akkor vége lehet a GPU-s bányászatnak Ethereumon, de ez 2023 előtt tuti nem jön el. Akkor majd keresni kell egy új kriptovalutát.
-
Abu85
HÁZIGAZDA
Így pedig Kína mondhatja, hogy ők tisztán játszanak, hiszen a több kínai vezető mást akar. Mennyire kár, hogy Wu hatalma jelenleg túl nagy, és Hszi Csin-ping ezt biztos elképesztően sajnálja is...
Ha Kínának Wu tényleg annyira nagy probléma lenne, már rég eltávolították volna. Gondolod pont egy ilyen illiberális államban nem tudnak piszkos eszközökhöz nyúlni? A valóság az, hogy Kínának nagyon is tetszik az a káosz, amit Wu teremt, mert egy olyan üzletet hátráltatnak vele, ami az országnak rossz. A megegyezés csúszásával viszont fel lehet készülni a későbbiekre. -
Abu85
HÁZIGAZDA
Amit nem fog megkapni, mert az brutálisan sok, vagyis végeredményben teljesíti azt a szerepet, amit rábíztak, hátráltatja az üzlet létrejöttét, amíg a kínai projekteket leszedik az ARM-ról.
Idővel majd el fog fogadni egy ajánlatot, és amikor megy ki az ajtón, akkor visszafordul, hogy sajnálja, hogy Kína otthagyja az ARM-ot. Ez politika már, érdekek és érdekellentétek.
-
#42049
Abu85
HÁZIGAZDA
nkaresz1976
#42045
Abu85
HÁZIGAZDA
válasz
nkaresz1976
#42045
üzenetére
Kevert. Némelyik ultra, némelyik afölötti, némelyik high vagy medium.
-
-
Abu85
HÁZIGAZDA
válasz
GodGamer5
#42034
üzenetére
Nem akarok elkeseríteni senkit, de a next-gen címek ilyen processzorigénnyel rendelkeznek. Leginkább hat maggal érdemes belevágni. Ez van. A konzolban van erős nyolcmagos, és nyilván nem fogják lebutítani a minőséget a PC-s portra, bizonyos elemek nem skálázhatók. Egyszerűbb lenne a helyzet, ha a PC-s port az Xbox One verzióból jött volna, akkor sokkal jobban futna a gyengébb CPU-kon, de úgy meg az lenne a baj, hogy sokkal rondább, mint az új generációs verzió.
A VRAM-ból sem elégszik meg kevéssel. Max részletességhez dobni kell alá 12 GB-ot legalább.Ray tracing is lesz benne, csak az újságírói verzió egy nagyon régi kód.
-
#41978
Abu85
HÁZIGAZDA
gainwardgs
#41973
Abu85
HÁZIGAZDA
válasz
gainwardgs
#41973
üzenetére
Kettéhúgyozza (2 fps), agyonveri (1 fps), majd még egyszer kettéhúgyozza (2 fps).
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
Abu85
HÁZIGAZDA
Nem céloz olyan piacokat, mint a konkurensek, ahol nagyon zsíros haszonnal lehet lapkákat eladni, ráadásul tömeges mennyiségben. Alapesetben az AMD sem tudná ezt, ezért vitték el a GPU-k gyártását régen a GlobalFoundries-hez, viszont mivel a TSMC-hez vitték a CPU-k gyártását, így már könnyen túl tudnak licitálni akárkit. De ha csak GPU-kat gyártanának a TSMC-nél, akkor ugyanúgy tennének, mint az NV, keresnék a Samsung kegyeit, mert a GPU-k piaca messze nem akkora, mint a CPU-ké, és olyan orbitális hasznot sem tudnak rácsapni, mint a CPU-kra.
Alapvetően ez a licit nem termékekre vonatkozik, hanem waferekre. Az AMD-nek nem különösebb gond, ha drága a wafer, mert lehet, hogy a GPU-kon nem keresnek, vagy akár buknak is egy picit, de a CPU-kkal együtt bőven pluszban van a waferszinten leadott rendelés. Az NV-nek ez nagy gond, mert nincsenek CPU-ik, amik pozitívba tolják a waferekre leadott rendeléseiket, tehát nekik olyan megoldás kell, ami a GPU-kkal is nyereséget termel. Ez a TSMC üzleti modellje mellett baromira nehéz. Pár rohadtul minőségi piacot célzó cég úgyis rád fog licitálni, amit esélyed sincs tartani, mert gondolni kell arra, hogy nyereséget kell majd termelni. Az AMD-nek sem lenne ugyanúgy semmi esélye, ha nem gyártanának CPU-kat is.
-
Abu85
HÁZIGAZDA
Írni lehet erről, de a TSMC szempontjából miért is adná olcsóbban a wafert, ha eladja normál áron is. Attól, hogy a DigiTimes ír valamit még nem jelent semmit. A DigiTimes azt is állította már, hogy a Zen 3 5 nm-en jön, aztán látjuk, hogy rohadtul nem. De anno le is írtam, hogy miért volt faszság, amit írtak. [link]
A probléma az, hogy média nem tudja elképzelni, hogy a Samsung jót tud gyártani. Pedig igazából a 8 nm egy proven technology. Nem új dolog, évek óta hibátlanul gyártanak rajta vagy a korábbi verzióján a cégek. De ami ennél is durvább, hogy sokan azt hiszik, hogy 7 nm-re könnyű átugrani. Ahogy a DigiTimes azt hitte, hogy 5 nm-re ugrani csak egy döntés, de nagyon nem, bizonyos node-ok nem kompatibilisek egymással, és az áttervezés ideje másfél-két év.
Az NV-nek nem feltétlenül a waferár a gondja a TSMC-nél, hanem az, hogy ha például ma eldöntik, hogy átmennek, akkor abból 2022 első negyedévében lesz termék. Ezt már innen nem viszik sehova. Az ilyen problémákat hagyni kell a fenében, és át kell ugrani azt. El kell vonni az erőforrást a fejlesztéstől, majd koncentrálni a következő generációra.
-
Abu85
HÁZIGAZDA
Minek reflektáljon rá a Samsung? Nagyon régóta működik a 8 nm-es eljárásuk. Az NV előtt sok cég csinált már rá több tucat lapkát, mindet probléma nélkül. A half-node-okkal sosincs igazán baj, mert az mindig egy továbbfejlesztése egy már évek óta tökéletesen működő node-nak, jelen esetben a 10 nm-es eljárásnak.
Akit érdekel a 8 nm, az tud kérni a Samsungtól jelentést, hogy mire képes, és az ezerszer több adatot jelent számukra, mint a pletykacikkek. Az alapján fogják eldönteni, hogy ez az ideális választás-e számukra. Az NV is így csinálta. Kértek jelentést a TSMC-től és a Samsungtől az elérhető gyártástechnológiákra. Ezeket a bérgyártók megadják, természetesen a többi partner adatainak a védelme mellett.A 7 nm-es TSMC node-ra való áttérés lehetséges, de a Samsung és a TSMC gyártástechnológiai nem kompatibilisek, tehát ez nem olyan, hogy akkor eldöntöm, hogy inkább a TSMC, mert előbb át kell tervezni a dizájnt, hogy ott is gyártható legyen. Az NV ezt vállalhatja, de ha ezt eldöntik egyszer, akkor onnan másfél év legalább, hogy tömeggyártható lapkák szülessenek. Tehát, ha még csak most gondolkodnak egy ilyen váltáson, akkor az Ampere refresh az kb. egy 2021Q1-es történet lesz. Jóval hamarabb kellett erről dönteni, ha egy refresht akarnak csinálni 2020-ban.
#41781 b. : De a Samsung nem onnan szerez vevőket, akik a pletykalapokat olvassák. Ha van érdeklődő, akkor ők direkt felkeresik a céget, és kikérik az adatokat az adott node-ra.
A TSMC senkinek sem ad kedvezményt. Lehet licitálni a gyártókapacitásra és kész. Akinek nem tetszik, az várhat a következő licitekre. A TSMC-nek mindegy, a pénzüknél vannak mindenképpen maximum nem az NV-nek gyártanak, hanem a Qualcomm, Apple, AMD, Xilinx, akárkinek. De ha ez a rendszer nem jó, akkor lehet menni máshova, de kedvezmény itt sosincs. Ellenben mindenkinek van esélye waferhez jutni, csak túl kell licitálnia a többieket. Az NV elsődlegesen azért keresi a Samsung kegyeit, mert az említett cégekkel szemben nem túl könnyű waferekhez jutni, ha a Xilinx nem is feltétlenül, de az Apple, AMD, Qualcomm simán túllicitálja őket, és akkor még jön az Intel is a TSMC node-jaira. Ők is olyan piacokat céloznak, amiből okádni tudják a pénzt a TSMC-nek.
Arról nem is beszélve, hogy a TSMC nem különösebben érdekelt abban, hogy specifikus node-okat tervezzen egy olyan megrendelőjének, aki messze nem a legnagyobb. Ellenben a Samsung megcsinálj. Az NV is egy rájuk tervezett 8 nm-es variánst használ. -
Abu85
HÁZIGAZDA
GDDR6X. Ez a gondja a 3080-nak és 3090-nek. A GDDR6-tal a 3070-ből több lesz, de azt meg az OEM-ek is nagy mennyiségben rendelik, mert sok gépbe a 3080 és a 3090 nem jó. Túl nagyok és túl sokat fogyasztanak. A 3070 viszont elég sok konfigurációba beépíthető, így ebből nagyon bevásárolnak éppen. Itt gondolni kellett volna arra az NV-nek, hogy az OEM-eknek nem adják ki a 3070-et, és akkor lenne belőle bőven elég dobozos. De mennyiségileg ebből tényleg nagyon sokat gyártanak, bőven a tízszeresét a 3080-3090-nek, csak az OEM-ek, meg kb. ennek is a sokszorosát rendelik, hiszen kő a hardver a karácsonyi szezonra.
-
#41760
Abu85
HÁZIGAZDA
huskydog17
#41758
Abu85
HÁZIGAZDA
válasz
huskydog17
#41758
üzenetére
Az Ubisoft már előre gondolkodik. Lesz egy rakás platform, ami támogatni fog raytracinget. Arra ki kell alakítani egy olyan környezetet, amiben mindent le tudnak fedni a legkisebb munkával. Egyelőre itt a Radeon Rays 4.0 az a rendszer, ami hosszabb távon megoldja ezt, mert támogatni fogja majd a Stadiát, támogatja a két új konzolt, támogatja a PC-s Radeonokat, és generál majd fallback kódot szabványos DXR-re. Tehát egyszer írsz raytracing támogatást, és lefedsz vele mindent, amit alapvetően le lehet fedni. Ha nem erre mennének, akkor kellene szabványos PC-s/Stadia kód, egy külön kód az új Xbox-ra, és egy harmadik az új PS-re. Az eredmény majdnem ugyanaz, csak a befektetett munka háromszoros.
Na most ezeket ki kell kísérletezni, és például tökéletes alany itt egy játék. Arra megnézik, hogy miképp működik a rendszer, esetleg hoznak bele egy-két effektet, amikor úgy látják, hogy jó, így kipróbálják élesben is. Ezért érdemes számukra most a DX12-n maradni. A Radeon Rays 4.0 egyelőre alkalmas arra, hogy a DXR intrinsics módot bevessék. Később lesz Vulkánra is ilyen, sőt, a Vulkan API-ra még az egyedi bejárásra vonatkozó Radeon Rays 4.0 mód is átmenthető, mert a DirectX 12-vel ellentétben a Vulkan támogatja a programozható bejárást, amit a processzormagok minden PC-n el tudnak majd végezni, nem számít, ha a GPU nem támogat programozhatóságot erre vonatkozóan. Ebből a szempontból a Vulkan egy komplettebb rendszer, ami figyelembe veszi, hogy ma már azért bőven vannak 16-64 magos CPU-k PC-n, amik nem kicsit tempósak. Ezekben olyan erő van, hogy ki tud váltani egy komplett fixfunkciós hardvert is a programozható bejárást nem támogatók GPU-kon belülről. Mire erre készítenek majd szoftvereket, addigra már 128 magnál is járhatunk asztali szinten. Nem véletlen, hogy ez bekerült a Vulkan API-ba, figyelembe vették a szabványalkotók, hogy az elkövetkező években komoly "magrobbanás" lesz.
-
#41757
Abu85
HÁZIGAZDA
huskydog17
#41756
Abu85
HÁZIGAZDA
válasz
huskydog17
#41756
üzenetére
Támogatja a Vulkan API-t is, hiszen az kell a Stadiának, de a DirectX 12 lesz szállítva a PC-s verzióban.
Ezek a döntések az AMD miatt vannak, mert a Radeon Rays 4.0 még nem támogatja a Vulkan API-t, tehát a kísérletezéseket DirectX 12-n kell végezni. Így viszont a DirectX 12 az elsődleges API. Kettő API-t pedig felesleges szállítani, mert csak a karbantartási költségeket növelné.
-
#41753
Abu85
HÁZIGAZDA
huskydog17
#41752
Abu85
HÁZIGAZDA
válasz
huskydog17
#41752
üzenetére
Csak ebből hibás következtetést fognak levonni. A DirectX 12 alapvetően ugyanolyan gyors API, mint a Vulkan, és itt is elérné a teljesítményét, ha szálszinten párhuzamos shader kódokat kapna.
A Stadia csak Vulkan API-t támogat, nyilván az az elsődleges opció.
-
#41751
Abu85
HÁZIGAZDA
huskydog17
#41749
Abu85
HÁZIGAZDA
válasz
huskydog17
#41749
üzenetére
De az fontos, hogy azért nyer a Vulkan, mert ott subgroupokat is használnak. A DirectX 11 és 12 esetében elavult shader kódok futnak, amik nem használják a wave terminológiát. Persze, hogy a wave terminológiát használó kódok sokkal gyorsabbak a Vulkan alatt, hiszen nem mindegy, hogy a feldolgozás szálszinten soros vagy szálszinten párhuzamos. Óriási hátrány ám a DirectX 11/12-nek, hogy szálszinten soros feldolgozásra van kényszerítve (pedig a DirectX 12 támogat wave intrinsics-et). Így nem lehet hozzámérni az API-kat a Vulkan eredményekhez, mert már a shaderek szintjén ki van végezve a teljesítmény.
Az a baj, hogy Stadiára írt GLSL shadereket nem lehet ám egyszerűen visszaportolni másra. Ezért sem most érkezik a PlayStation 4 és az Xbox One port. Előbb vissza kell portolni a shadereket modern HLSL-be/PSSL-be. Így csalóka azért, mert az előny, amit a Vulkan ad nem azért van, mert maga a Vulkan API ennyivel gyorsabb.
-
Abu85
HÁZIGAZDA
Az IBM magjai lényegesen erősebbek az ARM és az Intel/AMD magjainál. És a rendszerük teljesítménye is nagyon magas. Olyannyira, hogy nem igazán tudja őket közelíteni az ARM vagy az AMD/Intel. A probléma leginkább az, hogy nem x86/AMD64 az ISA.
1. Az Intelnél ezt bárki később tudja szállítani, még az AMD is. Hiába tud a Cray adni egy másfajta rendszert. A leggyorsabban akkor van meg az Aurora, ha az Intel szállít nekik TSMC-nél gyártott gyorsítót. Mindenki más csak lassabban tudja összerakni a rendszert.
2. Ez a projekt már eleve csúszik. Évek óta kész kellene lennie, csak az Intel törölte a Xeon Phit.
3. Az 3 év legalább. Ha csak a pénzen múlna, akkor már megkérték volna, de a chiptervezés problémája az idő. Ráadásul mire raknak CXL-t az A100-ba, addigra ez a lapka rég elavul, és sokkal újabb rendszerek lesznek kész. Ez nem olyan dolog, hogy kell a funkció, és az NV megoldja fél év alatt. Le kell ülni a tervezőasztalhoz, és egy csomó mindent ki kell cserélni a dizájnban, ami kb. egy év meló, majd két év mire azt tömeggyártásra alkalmassá teszik.
Az, hogy Addison Snell mit szeretne az irreleváns. A DOE meg azt szeretné, ha az Aurora 2022-ben működne, és azt csak az Intel tudja biztosítani. Minden más lehetőség további csúszás. Az AMD ezt nem fogja tudni vállalni 2023 előtt, az NVIDIA pedig 2025 előtt.
Mondjuk a top Ponte Vecchio eleve 40 TFLOPS-ra lő, tehát ha abból 30-35 jön össze, akkor az is elég jó még. Ráadásul az Aurora konfigurációja az 6 GPU-s, tehát 50 TFLOPS-ot egy szerver node TSMC-vel is tudni fog. Az AMD-nek a CDNA-ja 40 TFLOPS körüli. FP64 ezeknek a számoknak a fele. Az NVIDIA nem tudni, hogy hoz-e valamit az A100 mellé, mert az általános számításban nem valami erős, csupán 19,5/9,75 TFLOPS-ot tudnak vele FP32/64-ben.
-
Abu85
HÁZIGAZDA
Az Aurora nem tud módosulni. Az Exascale rendszereknél nagy problémát jelent, ha nem koherens interfésszel vannak bekötve a gyorsítók. Egyszerűen túl nehéz ilyen szintre skálázni egy konfigurációt. Tehát marad az Intel gyorsítója, csak nem az Intel fogja gyártani hozzá a Compute Tile-t, hanem a TSMC. Ennyi lesz a változás. Ez valószínűleg kisebb teljesítményt jelent majd, így az Intelnek el kell döntenie, hogy több hardvert szállít-e, vagy azt csinálják, hogy marad a tervezett rendszer, és idővel ingyen kicserélik a gyorsítókat nagyobb teljesítményűre.
AMD-re, NV-re, akármire nem lehet váltani. Egyrészt azzal dobni kellene a host rendszert. Tud ugyan másik memóriakoherens platformot kínálni a Cray, de akkor nem teljesül a CORAL-2 program követelménye, tehát AMD-re nem tudnak átállni. NV-vel pedig a tervezett teljesítmény töredéke jönne össze csak. -
#41715
Abu85
HÁZIGAZDA
Petykemano
#41701
Abu85
HÁZIGAZDA
válasz
Petykemano
#41701
üzenetére
A fogyasztást a mai hardvereknél eleve a fogyasztási limit befolyásolja. Ha befogásra kerülnek a nem használt részegységek, attól a fogyasztási limit nem változik, maximum nem x MHz-es tartományban lesz az órajel, hanem x-200 MHz-esben.
-
#41691
Abu85
HÁZIGAZDA
Petykemano
#41690
Abu85
HÁZIGAZDA
válasz
Petykemano
#41690
üzenetére
Az 580-on és az 590-en eltérő lapkák vannak. Előbbin Polaris 20, utóbbin Polaris 30. A Polaris 30 nem is 14 nm-es node-on készül. Természetes, hogy két teljesen különböző lapka ebben eltér.
-
Abu85
HÁZIGAZDA
Olyan nincs, hogy 98%-os terhelés. Az maximum azt jelenti, hogy a parancsmotor a 100 ciklusból 98-ban beolvas valamilyen parancsot. De belül azt nem úgy dolgozza ám fel. A GPU-n erősen heterogén processzorok, tehát nagyon sok az üresjárat bennük, és ezeket afterburner nem fogja megmutatni. Érdemes inkább megnézni egy profilozóval, ott azért közel sem az látszik, hogy 98%-os a terhelés. Jó ha 50% megvan.
Minden dizájnnak van egy optimális hatékonysága, ahol arányaiban a legnagyobb teljesítményt adja le a fogyasztáshoz viszonyítva. Ezek gyártói döntések, hogy hogyan állítják be.
Például az AMD ezzel azért nem törődik annyira, mert ma már teljesítménytartományt szállítanak a Radeonokban. Van egy közepesre állított szint, amiből a power limit beállítással elérhető a legnagyobb hatékonyság és a legnagyobb teljesítmény is. A felhasználó egy -50 és +50 százalék közötti csuszkával kiválaszthatja, hogy mit akar. Általában -10-20% között van az optimális hatékonysági szint, de ez termékfüggő, valamelyiknél 12%, valamelyiknél 18%. Ezt azért vezette be az AMD, mert ezernyi igény létezik, és ezt csak teljesítménytartomány felkínálásával fedhetik le. Mindenki beállíthatja azt, amit magának akar.Az NVIDIA ezt még nem vezette be, de az Ampere már tett lépéseket felé, tehát később valószínűleg ők is bevezetik ezt a tartományos modellt, csak ahhoz még szükségük van arra, hogy gyorsabban váltson az órajellépcsők között a dizájn. Valószínűleg a következő körben elérik. Az Ampere annyiban előrelépés, hogy teljesen hardveres lett az órajel- és feszültségmenedzsment, tehát már nincs benne szoftveres tényező.
A gyártástechnológiát könnyű hibáztatni, de az esetek nagy részében nem ott van a gond.
Az undervolt azért nem ajánlott, mert a gyártók a beállításokat nem a programokra nézik, hanem egy szimulációra. Ez a szimuláció bekapcsol minden részegységet a lapkában, tehát egy eléggé worst case mérés. Egy játékban azért működik az undervolt, mert a legtöbb játék közel sem túráztatja a GPU-ban található összes részegységet. Egy adott pillanatban jó ha a teljes lapka 50%-a be van fogva. De ugye jöhet egy olyan feldolgozás, ahol be lesz fogva a 80%-a is, és akkor bizony az undervolt megadja magát, mert ahhoz az a feszültség kellene, amit a gyártók beállítottak, csak a felhasználó nem engedi elérni.
Ez ellen egyébként a Navi már védekezik. Ha túl kevés a feszültség, akkor nem fagy bele a munkába a GPU, hanem indít a rendszer egy fail-safe módot, ami azt jelenti, hogy a GPU az órajelet levágja 500 MHz körülire. Ezért van az, hogy ha valaki undervoltol egy Navit, akkor nő a mikroakadások száma, mert már nem fagy bele az alacsony feszültségbe a rendszer, de harmadolja a teljesítményt arra az időre, amíg a feszültséget alacsonynak tartja. -
#41687
Abu85
HÁZIGAZDA
Petykemano
#41686
Abu85
HÁZIGAZDA
válasz
Petykemano
#41686
üzenetére
Minden VGA-t alul tudsz feszelni, csak kérdés, hogy az az alulfeszelt eredmény átmegy-e a GPU-ra írt terhelésszimuláción. Nem véletlen van az a feszültség oda állítva, ahova. Ha egy GPU-t nagyjából 40-50%-osan terhelő játék lenne a mérce, akkor persze lehetnek alacsonyabb feszültséget alkalmazni, csak bajban lenne a termék, ha szembejön mondjuk a Strange Brigade, ami azért 60-70%-osan is leterheli a GPU-kat.
-
#41685
Abu85
HÁZIGAZDA
Petykemano
#41684
Abu85
HÁZIGAZDA
válasz
Petykemano
#41684
üzenetére
Mert 16 nm-en jött be FinFET, és elsőre marhára jól kezelhető volt. A gondok 10 nm-en kezdődtek vele. Majd a GAAFET is kezelhető lesz 3/2 nm-et. Aztán 1 nm-en már lehetnek vele problémák.
Az AMD is nagyon jól eltalálta a 14 nm-t. Ha nem találták volna el jól, akkor a Vega 20 jobban elhúzott volna már elsőre.
Ebben érzem, hogy mindenki a bérgyártót akarja belelátni, de nem sok közük van ehhez. Tapasztalat, tapasztalat, tapasztalat. Ez a három dolog kell a modern node-okhoz.
-
#41682
Abu85
HÁZIGAZDA
Petykemano
#41681
Abu85
HÁZIGAZDA
válasz
Petykemano
#41681
üzenetére
Ha megnézed az A100-at, ami a TSMC-nél készül, az se hatékonyabb ám. Sőt, FP32 számítási kapacitásban alatta van a GA102-nek, miközben fogyasztásban felette. A probléma nem igazán a gyártástechnológia, hanem az, hogy az NV akkor a 12 nm-t ismerte, mert a 16 nm half-node-ja volt, míg most a 7 és 8 nm-t nem ismerik, nem is vihették át a dizájnkönyvtáraikat rá, most van velük először dolguk. Ez nem igazán a bérgyártó mondjuk úgy felelőssége, a FinFET tényleg nehezen kezelhető alacsony csíkszélességen, és ki kell azt tapasztalni.
Ugyanezt rá lehetne húzni a Vega 20-ra is, ami 7 nm-en jött. Annál is hasonló lett volna a grafikon a Vega 10-hez viszonyítva. Aztán látod, hogy hova jutottak a Renoirral.
-
#41670
Abu85
HÁZIGAZDA
Petykemano
#41669
Abu85
HÁZIGAZDA
válasz
Petykemano
#41669
üzenetére
Persze. A mostani helyzetnek már lőttek. Mire megoldják rég a második 5 nm-es lapkáját hozza az AMD, és akkor ugyanott lesznek, mint ma. Ezt a problémát át kell ugraniuk. Nem is azt mondom, hogy a TSMC-nél, mert náluk azért nagy a licit az 5 nm-re. Mehetnek a Samsunghoz is. Csak legyenek ott a kezdésnél, mert akkor a második körben nem kerülnek hátrányba.
Jövőre az AMD csak szerverbe hozza a Zen 4-et. Amikor ebből lesz desktop, akkor bőven lesz új verzió, ha kell. Bele van tehát már tervezve, hogy a Zen 4-nek esetleg problémái lesznek 5 nm-en. Ha nem, akkor az még jobb, nem kell az új revízió.
-
#41668
Abu85
HÁZIGAZDA
Petykemano
#41667
Abu85
HÁZIGAZDA
válasz
Petykemano
#41667
üzenetére
Eleve az NV-nek már rég váltania kellett volna. Szóval a 7-8 nm már a késői váltással elúszott. Innen már előre kellene tekinteni az 5 nm-re.
Az AMD eleve a szerverrel megy először 5 nm-re. Kis Zen 4 chiplet, amit majd rádobnak az EPYC-ekre. Ebből baj nem lehet. A probléma a későbbi lapkáknál jöhet elő, de akkorra lesz tapasztalat.
Amíg a Windows nem bizonyítja, hogy képes jól kezelni az eltérő teljesítményű magokat, addig az AMD biztosan távol marad ettől. Az Intel azért megy erre, mert nincs más választása, de a Zen magok nem csak gyorsak, hanem keveset is fogyasztanak, ezért tudnak 64 magot belerakni akkora fogyasztásba, ahova az Intel csak feleennyit. -
#41665
Abu85
HÁZIGAZDA
Petykemano
#41658
Abu85
HÁZIGAZDA
válasz
Petykemano
#41658
üzenetére
Többször írtam már, hogy a FinFET közeledik a végéhez. Mi volt az AMD-nek az első 7 nm-es lapkája? A Vega 20. Nem volt valami jó a fogyasztásban, de utána mindegyik javult, és most a Renoir már igen nagy órajelen is keveset fogyaszt. A kettő közötti különbség a tapasztalat.
Az NV-re is ugyanazok a fizikai törvények vonatkoznak, így elsőre nekik sem sikerült jól a FinFET egy modern node-on. Ez van. Hozni kell jövőre egy másikat 8 nm-re, és az jobb lesz, majd egy harmadikat, és az már igen jó lesz, közel az elméleti maximumokhoz.Amíg a GAAFET nincs itt, addig elsőre nagy mázli kell, hogy összejöjjön egy lapka egy új node-on. Ez nem igazán a Samsung és a TSMC hibája, hanem az adott node-ra vonatkozó tapasztalat hiánya.
-
#41663
Abu85
HÁZIGAZDA
Malibutomi
#41657
Abu85
HÁZIGAZDA
válasz
Malibutomi
#41657
üzenetére
Azért az RDNA1/2-t nem hívnám lightweightnek. Nézzetek meg egy multiprocesszort. 128 kB-os az LDS, négy darab, egyenként 128 kB-os regiszterterület, két 16 kB-os L0, és megosztottan 16 kB-os skalár és 32 kB-is utasítás gyorsítótár, illetve 128 kB L1.
Ha ez a lightweight nem tudom mi a szénné gyúrt.
Az Ampere esetében egy multiprocesszor az 128 kB L1, amiből 48 kB az LDS grafikai számításnál, tehát külön LDS nincs is, 32 kB az utasítás gyorsítótár, és van még négy darab, egyenként 64 kB-os a regiszterterület. Ez sokkal inkább lightweight azokhoz az izmokhoz képet, amit az AMD rak az RDNA-ba.
Szimplán compute shaderben le van implementálva. Az új Call of Duty ezt használja, és minden DirectX 12-es VGA-n megy.
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Ú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!
Megbízhatatlan oldalakat ahol nem mérnek (pl gamegpu) ne linkeljetek.
- Okos Otthon / Smart Home
- Nintendo Switch 2
- Escape from Tarkov
- PlayStation 5
- Futás, futópályák
- Milyen TV-t vegyek?
- Intel Core Ultra 3, Core Ultra 5, Ultra 7, Ultra 9 "Arrow Lake" LGA 1851
- Assetto Corsa Rally
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Milyen billentyűzetet vegyek?
- További aktív témák...
- MSI GeForce RTX 3080 10Gb GAMING Z TRIO
- EVGA GeForce RTX 3080 FTW3 ULTRA GAMING 10GB GDDR6X (10G-P5-3897-KR) Videokártya
- Hp NVidia RTX 2070 Super 8Gb Videokártya - HP L84981-001
- PowerColor 9070 XT Hellhound Spectral White OC 16GB - Garancia 2028.05.28 - BESZÁMÍTÁS
- RTX 5000-ES SZÉRIA ÚJONNAN GARANCIÁLIS ELADÓ TERMÉKEK! 5050, 5060, 5070, 5080, 5090.
- Kezdő Gamer PC-Számítógép!Csere-Beszámítás! I5 6500 / RX580 8GB / 16GB DDR4 / 512 SSD
- BESZÁMÍTÁS! LENOVO Ideapad Gaming 3 notebook - R5 5600H 16GB DDR4 256GB +1TB SSD nVidia GTX 1650 4GB
- AKCIÓ! Apple MacBook Pro 16 M4 Pro 48GB RAM 4TB SSD macbook garanciával hibátlan működéssel
- Samsung Galaxy S24 8/128 GB Onyx Black 6 hónap Garancia Beszámítás Házhozszállítás
- Azonnali készpénzes GAMER / üzleti notebook felvásárlás személyesen / csomagküldéssel korrekt áron
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest
Cég: NetGo.hu Kft.
Város: Gödöllő