-
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
válasz
hokuszpk
#63267
üzenetére
A GPU nem csak játékra használható, és ahogy nő ezeknek az alkalmazásoknak a száma, úgy válik egyre fontosabbá, hogy ne omoljon össze két GPGPU-s programtól a teljesítmény. Ezért csinálja ezt a Microsoft.
Ez leginkább az AI-nál lesz hasznos, mert a háttérben futhatnak AI programok, miközben valaki játszik. Nem mindegy, hogy a játékban a sebességvesztés 20-30% lesz, vagy 400-600%, amennyi manapság szokott lenni.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#63273
Abu85
HÁZIGAZDA
bitblueduck
#63272
Abu85
HÁZIGAZDA
válasz
bitblueduck
#63272
üzenetére
Felhőbe inkább a virtualizáció a hasznos.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Már most is dedikált hardver van RT-re a Radeonokban. Ez nem lesz újdonság.
De ez nem úgy működik, ahogy az a WCCFtech elképzeli. A PlayStation 5 API-ja eleve programozható bejárást támogat, tehát egy dedikált hardverrel nem is működne. Ezért baj, ha olyan ember talál ki pletykákat, aki nem is érti, hogy hogyan működik a Sony grafikus API-ja.
Amikor a Microsoft hozza a traversal shadert, akkor ezek a beépített fixfunkciós hardverek nem is fognak vele működni, mert maga a programozhatóság követeli meg, hogy a shaderekre építsen a rendszer.
XDNA2 NPU pedig nem tudom, hogy mire kellene a Sony-nak. Van egy GPU-juk 20 TOPS teljesítménnyel. Mi a túrónak nekik egy másik részegység? Olyan szinten hasztalan, hogy az hihetetlen. Ha ChatGPT-szerű megoldást akarnak lokálisan futtatni, akkor arra eleve alkalmas a mostani hardver, de kétlem, hogy ilyen megoldáson gondolkodnának. Felskálázni meg nem hasznos az AI. Egyetlen ma ismert felskálázó sem generál temporális tartalmat AI-val. Nyilván okkal. Tök hasztalan az AI ilyen célra. Túlságosan nagy ára lenne, hogy 10 GB-nyi neuronhálót csak úgy bedobnak a memóriába, és akkor lehet gazdálkodni a maradék 4 GB-ból minden másra. Nem véletlen, hogy ezt minden cég mellőzi.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Olyat egyébként el tudok képzelni, hogy a mostani dizájnnal megnövelik a multiprocesszorok számát. Az reális opció, de változtatni az architektúrán nem fognak, mert már kész API-k és fejlesztőkörnyezetek vannak erre. Azokat nem érdemes újraírni. Arra ott lesz a PlayStation 6.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A DLSS és az FSR is ugyanúgy elmos, csak azért nem érzékelhető, mert van rájuk beépítve élesítő post process. Már, ha a fejlesztők beépítik, de általában igen. Ha a TAA-ra nincs, akkor irány a Radeon vezérlőpult, és erre van a Radeon Image Sharpening. Ez ráadásul az egyetlen driverből injektálható renszer, ami konkrétan kontraszt adaptív, tehát nem fogja elrontani a kontrasztot az aktiválása.
A másik lehetőség a ReShade-féle CAS, de annál jobb az AMD-féle RIS, mert gyorsabban csinálja meg ugyanazt. Viszont, ha nincs Radeonod, akkor a ReShade-féle CAS nagyjából ugyanazt tudja, mint a RIS, csak némileg lassabban. Ha esetleg lenne a játékba beépítve CAS, akkor azt célszerű használni.
Az élesítőnél igazából az a lényeg, hogy kontraszt adaptív legyen, illetve elliptikus mintával dolgozzon, legalább 12-tap kernellel. Ha ez a két kritérium megvan, akkor általában jó az eredmény. A négyszöges mintájú rendszereket kerüld, mert ott nem lesz elég minta a jó eredményhez.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#63360
Abu85
HÁZIGAZDA
Petykemano
#63355
Abu85
HÁZIGAZDA
válasz
Petykemano
#63355
üzenetére
Erre rákérdeztem a múltkor, face-to-face az egyik vezető szerepkört betöltő személynél, és azt mondta, hogy ha lenne egy ilyen bug, amiről irkáltak, már rég javították volna, mert csak új steppinget kellett volna csinálni, amit negyed év alatt megoldanak, és akkor +50% teljesítmény. Az, hogy ezt nem tették meg, bizonyítja, hogy nem létezik a bug, mert +50%-ért megérné egy respin, de nincs mit javítani, mert úgy működik a hardver, ahogy tervezték.
Ami a valóságban van, hogy az RDNA 3 egyes részei eltérő órajelen futnak, és van olyan szituáció, amikor az egyes lapkák 3 GHz fölött működtetik a front-end részt. Ez szintén normális, így tervezték a hardvert. Arra nem tud mit mondani, hogy miért gondolják páran azt, hogy ha a front-endet 3,5 GHz-re tervezik, akkor a shadereknek is feltétlenül annyin kell működniük.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#63369
Abu85
HÁZIGAZDA
Petykemano
#63361
Abu85
HÁZIGAZDA
válasz
Petykemano
#63361
üzenetére
Az RDNA 2 készletek nem befolyásolnak semmit, hiszen eladják így is mindet.
Mi a valószínűbb... az AMD a saját maga ellensége, és azért nem javítanak egy +50%-os tempóval kecsegtető hibát, mert három hónapnyi melót túl soknak tartanak egy két és fél évig gyártandó generációnál, vagy eleve nem létezik a hiba, és valamelyik twitteres jószág kitalálta? Csak egy picit gondolkozzatok logikusan, és rájöttök, hogy a twitteres pletykák 99%-a megdől az elemi logikán.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#63370
Abu85
HÁZIGAZDA
Hellwhatever
#63366
Abu85
HÁZIGAZDA
válasz
Hellwhatever
#63366
üzenetére
A chiplet lényege az, hogy a lapka egyes részeit ne kelljen újratervezni. Ezért vezették be. Olcsóbb gyártást és olcsóbb fejlesztést jelent. Az olcsóbb gyártás abból ered, hogy a chipletbe nagyrészt I/O kerül, ami nem jól skálázódik, tehát lehet olcsóbb node-on gyártatni, az olcsóbb fejlesztés pedig onnan jön, hogy megvan az MCD, így a következő generációhoz már nem kell kifejleszteni. Spórolnak vele 200-300 millió dolláros egyszeri költséget.
A chiplet dizájn teljes egészében úgy egymilliárd dolláros, összköltségben mért spórolásra jön ki egy teljes generációra. Nyilván a jövőben is alkalmazni fogják, mert ennek a pénznek van jobb helye máshol. Persze manapság egy generáció három évre van tervezve, és akkor negyedévekre lebontva az egymilliárd dollár egy AMD szintű cégnek még nem is sok, de menedzsment szempontjából van jobb helye.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ez ezerszer át volt beszélve. A VRAM az olyan programok számára nem látható, mint a 3rd party tuningprogramok. Ennek az az oka, hogy a D3D12 és a Vulkan API-k esetében már nem létezik kernel driver. Tehát magáért a memóriamenedzsmentért az alkalmazás felel, de annak ezek az adatai annyira védettek, hogy még maga a grafikus meghajtó sem tudja már pontosan meghatározni, hogy mi hol van a VRAM-ban, és mennyi helyet használ.
Ezért vannak erre a problémára külön segédprogramok, mint például az RMV. [link] - De ez a program konkrétan felveszi az adott frame-re vonatkozó adatokat, tehát visszakereshető, hogy mi, hol, mennyi helyet foglal. Ez azért is lényeges, mert a VRAM az még egy operációs rendszer elől is elrejtett memória.
A DirectX 12 API-val a grafikus alrendszer úgy működik, hogy úgynevezett memóriahalmazok vannak logikai szinten kezelve az operációs rendszer, illetve annak kapcsolódó komponensei által. Ezekhez a logikai memóriahalmazokhoz tartoznak memóriatípusok. Ráadásul ezek mind, vagyis a halmazok és típusok is különböző flagekkel bírnak, vagyis lehetnek eszközlokálisak, host koherensek, host által láthatók, valamint host által cache-elhetők, esetleg egyik sem. Amikor például a Windows meghatározza a memóriahasználatot a feladatkezelő vonatkozó fülén belül, akkor ezeket a memóriahalmazokat látja, de azért nem tud még így sem pontos képet adni, mert egy memóriatípus lehet úgynevezett NULL-flages, és ilyenkor az operációs rendszer sem tudja megállapítani, hogy az adat, ami abban van, konkrétan hol található a fizikai memóriákon belül, a VRAM-ban vagy a rendszermemóriában. Ezt kizárólag az alkalmazás tudja, és pont emiatt vannak olyan memóriavizualizáló fejlesztői eszközök, amikkel ezt a fejlesztők láthatják.
Az ilyen 3rd party programok nagyrészt csak tippelnek, mert annyi adatjuk sincs, mint a Windows feladatkezelőjének, tehát megpróbálják kiolvasni az OS-ből az eszközlokális halmazok adatait, és kidobnak az alapján egy számot. Egy biztos, hogy annak köze nem lesz a valósághoz, mert nem foglalkoznak az összes memóriahalmazzal és memóriatípussal, főleg nem a NULL-flagesekkel. Márpedig ez fontos, mert az AMD-nél két memóriahalmaz és két memóriatípus van megkülönböztetve. Az NV-nél két memóriahalmazra 11! különböző memóriatípus létezik. És ezek közül egyik gyártónál sem mind eszközlokális. Ráadásul mint írtam a NULL-flagest semmi sem látja, márpedig abból az NV-nél van hét darab. Tehát minden adat, ami NULL-flages memóriatípusba kerül, az még az operációs rendszernek is láthatatlan információ. Nem tudnak vele számolni, mert el van rejtve, hogy ne zavarja a rendszer logikai működését.
Lehet nézni egy alkalmazásban az eltérő hardverek memóriahasználatát, de ahhoz memóriavizualizáló kell, mert a tippelőprogramok erre nem alkalmasak.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Semmi köze hozzá. Eleve a kiírás egy fals adat, mert a memóriahalamzok-típusok jó része nincs is beleszámolva. Értsétek meg, hogy a DirectX 12 úgy van felépítve, hogy ezt csak az alkalmazás tudhatja. Se az OS, se a driver, se egy külsőleg megírt program nem kaphat képet arról, hogy mi van a VRAM-ban. Fel lehet venni fejlesztőeszközzel, de nem ezt csinálta a videós. Ha ezt csinálta volna, akkor az reális adat lenne. Kiválaszt egy frame-et, és felveszi az egészet, majd elemzi külön. A gond az, hogy ilyen memóriavizualizálója csak az AMD-nek van. Tehát NV-n ez nem megvalósítható. Nem tudni, hogy ilyen tool mikor lesz a GeForce-okhoz. Igazából nem kritikus komponens, mert a legtöbb kapcsolódó bug univerzális, tehát az NV meg tudja várni, amíg ezeket javítják a fejlesztők Radeonokon, és ugyanúgy megjavul a hiba náluk is. Félelmetesen ritka, amikor valami gyártóspecifikus alkalmazásbeli bug okoz olyan hibát, ami szívást okoz a VRAM-on belül. Ha ilyen előfordul, akkor az NV meg tudja mondani, hogy miért, és könnyű javítani memóriavizualizáló nélkül is.
Az a baj, hogy minél közelebb viszed a hardverhez a programozást, annál kevesebb adatot tudsz az OS-sel vagy külön programokkal ellenőrizni. Régen ezek azért működtek, mert volt egy kernel driver, onnan azért a gyártók látták, hogy a program mit hova helyez, de ma a kernel driver nem létezik. Ki lett dobva, mert nagy többletterhelést csinált.
Az OS tud némi adatot ellenőrizni, de nem mindet, mert koncepcióból elvágta a Microsoft az ellenőrizhetőséget.
Még az AMD és az NV is képtelen erre driverből. Bár azt megjegyzem, hogy valamivel pontosabb a gyártói mérés a 3rd party programokhoz viszonyítva, de a NULL-flages foglalásokat senki se látja, és ez az AMD és az NV számára is megkerülhetetlen korlátozás. Koncepcióból ilyen a rendszer, tipikus nem bug, hanem fícsőr dolog.A kérdésedre válaszolva pedig olyan megtörténhet, hogy az alkalmazás memóriamenedzsmentje időnként defragmentál. Ez a DirectX 12 alatt lehetséges, és ilyenkor hirtelen növekszik a sebesség. Ez minden hardveren megtörténik, de más időközönként. A célja a defragmentálásnak az, hogy legyenek nagyobb összefüggő szabad memóriaterületek, vagyis ne kelljen valós időben kidobálni a last used lapokat.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
De van magyarázat.
Először is fontos, hogy az AMD és az NV logikai memóriakezelése eltér.
Az AMD-nek ez az implementációja:
Memóriahalmaz 0 (eszközlokális) -> Memóriatípus 0 (eszközlokális, host által látható, hostkoherens)
Memóriahalmaz 1 -> Memóriatípus 1 (host által látható, hostkoherens)
Memóriahalmaz 1 -> Memóriatípus 2 (host által látható, host által cache-selhető, hostkoherens)Az NV-nek ez az implementációja:
Memóriahalmaz 0 (eszközlokális)-> Memóriatípus 7 (eszközlokális, host által látható, hostkoherens)
Memóriahalmaz 0 (eszközlokális)-> Memóriatípus 8 (eszközlokális)
Memóriahalmaz 1 -> Memóriatípus 9 (host által látható, hostkoherens)
Memóriahalmaz 1 -> Memóriatípus 10 (host által látható, host által cache-selhető, hostkoherens)
Memóriahalmaz 1 (NULL) -> Memóriatípus 0 (NULL)
Memóriahalmaz 1 (NULL) -> Memóriatípus 1 (NULL)
Memóriahalmaz 1 (NULL) -> Memóriatípus 2 (NULL)
Memóriahalmaz 1 (NULL) -> Memóriatípus 3 (NULL)
Memóriahalmaz 1 (NULL) -> Memóriatípus 4 (NULL)
Memóriahalmaz 1 (NULL) -> Memóriatípus 5 (NULL)
Memóriahalmaz 1 (NULL) -> Memóriatípus 6 (NULL)Látható, hogy mennyi az eltérés, és ebből tud olvasni az OS. De nem minden memóriatípust. És itt a fő kérdés az, hogy maga a program hogyan használja a logikai implementációt. Például az UE5 tipikusan támaszkodik a host által látható flagre a működése miatt, így az NV-n eléggé intenzíven kell használni a NULL flages erőforrásokat, mert ugye szart sem ér az adatot olyan eszközlokális helyen tárolni, ami nem látható a host által. És minden olyan adat, ami NULL flages erőforrásban van nem számolt adat, mert csak az alkalmazás tudja nyomon követni a flagelés jellege miatt. Tehát az adat ettől még ott van a VRAM-ban, vagyis a gyakorlatban nem rosszabb az NV memóriakihasználásának hatékonysága, csak ez egy külső szoftver számára nem látható. De ettől az NV GPU-k is tudják használni a VRAM adottságait, mennyiségét, nem kényszerülnek a más logikai menedzsment miatt kevesebb VRAM-ra, csak tényleg nem látod, hogy konkrétan mennyit használ a VRAM-ból.
És abból se induljatok ki, hogy ennyire eltér a logikai menedzsment a gyártók között. Ugye a DirectX 12-nek is van egy elvárt működési módja, és a gyártók hardvereinek is. A logikai menedzsment a különbségeket próbálja áthidalni. A lényeg itt az, hogy kialakítható legyen egy olyan működés, amivel az adott alkalmazás képes teljes egészében kihasználni a rendelkezésre álló erőforrásokat, vagyis ha 8 GB VRAM-van egy VGA-n, akkor szépen menjen el a foglalás 8 GB közelébe. És azért vannak eltérő menedzsmentek logikailag, mert a gyártók ezt a célt más struktúrával érik el, de az API szempontjából mindegy a hogyan, a lényeg a cél elérése. És attól még az NV eléri ugyanezt a célt, hogy egy 3rd party alkalmazás képtelen látni a NULL flages részeket. Tehát a hatékony működés megvan, csak nem látható számodra.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#63410
Abu85
HÁZIGAZDA
Petykemano
#63403
Abu85
HÁZIGAZDA
válasz
Petykemano
#63403
üzenetére
Amit el is ér, hiszen két órajeldomain van, és a front-end az jellemzően 3 GHz fölött működik.
A Zen 4 egy CPU-mag, nem pedig multiprocesszor. Sosem fog olyan órajelen üzemelni egy TOC típusú dizájn, mint egy LOC.
#63408 Petykemano : Programozható bejárás már ma létezik a konzolokban. Az Ubisoft pedig univerzálisan megoldotta a Snowdrop 2-ben. És látható, hogy mennyire gyors az Avatarban a sugárkövetés, konkrétan annyira működik, hogy ki sem kell kapcsolni, mert lowon nem eszi a tempót.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#63413
Abu85
HÁZIGAZDA
Hellwhatever
#63412
Abu85
HÁZIGAZDA
válasz
Hellwhatever
#63412
üzenetére
Pedig ez igazolhatóan így van. Az AMD az RDNA 3-hoz két órajeldomaint vezetett be. A shaderek és a front-end eltérő órajeleken fut. A shadereket adják meg, de a front-end az nagyjából 3-3,5 GHz között üzemel tipikusan. Ezért írták oda a diára, mert ez valós adat, 3 GHz fölé tervezve. Az más kérdés, hogy ezt sokan nem képesek értelmezni, és inkább meséket gyártanak mellé.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#63415
Abu85
HÁZIGAZDA
Hellwhatever
#63414
Abu85
HÁZIGAZDA
válasz
Hellwhatever
#63414
üzenetére
Egészen egyértelműen elmondták, hogy a front-end órajeldomain képes 3 GHz-re. Ezt kimondták az előadáson.
Értem én, hogy akik nem hallgatták meg az előadást élőben, azok ezt nem tudják, de amit csinálnak az mesegyártás. És ebben nem mentség az, hogy csak a diát látták, mivel korlátozott adatokból gyártanak mesét.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#63418
Abu85
HÁZIGAZDA
Hellwhatever
#63416
Abu85
HÁZIGAZDA
válasz
Hellwhatever
#63416
üzenetére
Ennél sokkal több elhangzott, mert az AMD tartott zárt előadást is.
Nem hiányos az adat, elmondták egyértelműen.
#63417 Petykemano : Az AMD legalább tíz percet beszélt a sajtónak az órajeldomainekről. Érdekes, hogy senkinek nem volt kérdése az ügyben, csak azoknak, akiket nem hívtak meg az előadásra, és mesét költöttek.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Azért, hogy a sajtó leírhassa, hogy két órajeldomain van a dizájnban, és ezt a többség le is írta az elkészült cikkekben, például mi is. Nem véletlen, hogy a Twittermesék nem kaptak sajtónyilvánosságot, mert az AMD első kézből cáfolta őket. Bárki, aki csak egyszer végigolvasott egy RDNA3 elemzést, az tudhatja, hogy a dizájn tud 3 GHz-et, hiszen a front-end 3-3,5 GHz közötti órajelen üzemel. Az pedig a Twittermesélők hibája, hogy tájékozódás helyett meséket gyártanak, de erről szól a Twitter. Alapvetően a mai világban mindenki ostoba, aki egy névtelenségbe burkolózó twitterest komolyan vesz. Ha valaki tényleg infót akar szivárogtatni, vállalja a saját nevét, mutassa meg, hogy kicsoda.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
-
Abu85
HÁZIGAZDA
Bármikor beperelhet bárki, hiszen ott a saját nevem. Ez a különbség a Twittermesélők és köztem. Én nem bújok az internet homálya mögé. Ez egy alapkövetelménye a hitelességnek.
Egyébként olvassák a fórumot (az NV-től tudok két embert, az AMD-től is egyet, és az Inteltől is)... szóval írhattok nekik ide, ha akartok, a PH fórum a gyártók térképén van.
Pro tipp... nagyon szívesen veszik a gyártók, ha véleményezitek, hogy merre vigyék a szoftveres fejlesztéseket. Mi hiányzik a meghajtóból nektek, stb. Ezt tőlem rendre megkérdezik, szerintem itt is érdeklődve olvasnák a véleményeitek.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Olyanról tudok, hogy egyszer javasoltam az AMD-nek a The Outer Worlds című játékot promócióba, még a megjelenése előtt. Azt mondta nekem, aki itt volt, hogy átadja az üzenetet az érintettnek, aki ezzel foglalkozik, aztán hozta a diát a bejelentésről, hogy sikerült.
Nem állítom, hogy mindig sikerülni fog, azt sem tudom biztosra mondani, hogy az én javaslatom miatt figyeltek fel rá, vagy amúgy is opció volt, de tény, hogy mondtam, és utólag kaptam is üzenetet róla, hogy megoldották.
[ 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
Busterftw
#63503
üzenetére
Ez nem ilyen egyszerű... A program fejlesztőjének nagy kontrollja van afelett, hogy a VRAM elég lesz-e vagy sem. Lásd Far Cry 6, ahol ugye két beállítás van a textúrarészletességre: az irtó fos és a kimaxolt.
Tehát alapvetően erősen beállításfüggő, hogy a 16 GB VRAM elég lesz-e, mert nagymértékben meghatározza ezt a kérdést az, hogy a max részlegesség alatt csak ultrafos van, vagy szépen leskálázva ott van még a very high, high, medium, low, very low. Utóbbi esetben visszaváltasz maxról high-ra és elég lesz, míg előbbi esetben szívás.
Ez a kérdés tehát leginkább attól függ, hogy a motor hogyan van megírva. De leginkább a memóriát a textúrák, illetve a réjtrészing zabálja. Tehát akkor kell több memória felé menni, ha ezeket akarod felhúzni, viszont ez is túl általánosított megfogalmazás, mert végeredményben a fejlesztő dönti el, hogy hol vannak a határok a VRAM kihasználásánál.
Egyébként meg nagyon jó lehetőségek vannak erre, lásd a Starfield, ami nagyon-nagyon sok adattal dolgozik, mégsem zabálja két pofára a VRAM-ot. Sőt, igazából ha moddolod, akkor is nagyon hatékony marad a menedzsment. És ezt nem is a Bethesda, meg a Microsoft írta, hanem csak a The Forge menedzsmentjét használják, ami ugye megegyezik a D3D12MA-val. És nagyon érdekes adat, hogy ha ezt kikapcsolják, akkor biza a Starfield 22 GB VRAM-ot igényel maxon 4K-ban.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ezért írtam, hogy a VRAM terhelését nagymértékben meghatározzák a döntések, amiket a fejlesztésnél meghozol. Gyakorlatilag az explicit API-k működése miatt akármikor jöhet egy olyan játék, ami bezabál 20 GB-ot, akár úgy is, hogy nem néz ki jól.
Egyébként én a Microsoft és a Khronos helyében mindenkire finoman kényszeríteném a D3D12MA-t és a VMA-t. Pokolian jól működik a Starfieldben. Sőt, egyszerűen beolvasztanám az API-k mellé frameworkként. Az esetek többségében nem ír jobbat a fejlesztő.
[ 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
hahakocka
#63509
üzenetére
Az UE5 legnagyobb baja a Nanite potenciális instabilitása. Az Epic jelenleg atomi műveletekkel optimalizálja a hierarchikus kivágást. Ez mutex zárolásokhoz hasonló gondokat okoz, egyszerűen nincs garancia arra, hogy egy zárolt wave nem fogja a GPU-t TDR-be juttatni. Szóval ez lehet, hogy ideig-óráig jól működik, de ott van a fagyás lehetősége mindig. És ilyen formában az UE5 még nem valami nagy ötlet, mert olyan dolgokat csinál, amiket konkrétan nem ajánlott megtenni az API-kon.
Egyébként erre jó lesz a work graphs, ami már egy elméletben is stabil formában teszi lehetővé az Epicnek ezeket a Nanite optimalizálásokat. De a work graphs még nem része egyik explicit API-nak sem, csak kipróbálható. Viszont nem véletlen, hogy az Epic rávetette magát, mint gyöngytyúk a takonyra, mert pont ez a megoldás kell nekik.
[ 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
S_x96x_S
#63522
üzenetére
Az LLM-ek borzalmasan memóriazabálók. Nem is igazán a VRAM-os kutatások zajlanak, hanem inkább az, hogy ezek a lehetőségek lokálisan a CPU AI motorján fussanak, mert akkor a rendszermemória van terhelve.
Ezek a GPU-nak lokálisan amúgy is nagyon károsak, mert a matrix motorok ugyanazt a regiszterterületet használják, vagyis masszívan esik a grafikai teljesítmény, ha futna a játékban egy LLM is.A DirectStorage egyébként növeli a játék VRAM-igényét. Az annyit segít, hogy a betöltés lesz gyorsabb, de ennek az ára a több VRAM használata.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Annyi infó lett a héten közvetlen forrásból, hogy eredetileg 8 GB-osnak készült a 7600 XT. Az ősszel merült fel a 16 GB, amikor az AMD meglátta, hogy mennyire sok VRAM-ot esznek a partnereik készülő játékai. Eközben a D3D12MA-t és VMA-t nem sokan akarják használni mostanság használni, mert ugyan sokat javít a VRAM terhelésén, akár negyedeli is az igényelt kapacitást, de közben rontja a sebességet, és ez -10-15% is lehet. Sok fejlesztő valamilyen érthetetlen okból úgy van vele, hogy maradjon meg inkább a sebesség, majd default beállítják a low-medium textúrát, ha nincs elég VRAM.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
-
Abu85
HÁZIGAZDA
RT-re memória kell és memória-sávszélesség. Az egyik legnagyobb baj, hogy például az olyan motorok, mint az UE5 elég szarul kezelik a DXR-t. Egyszerűen egy nagyobb részletességű jelenet csak az RT effektek VRAM-igényét önállóan 10 GB-ra lőheti. És akkor még nincs semmi más a VRAM-ban. Ez egy extrém erős limitáció. Nem véletlen, hogy az Ubisoft azzal a poligonszámmal nem is erőltette a bedrótozott bejárást. Lenne vagy 10-15 GB csak az RT memóriaigénye. Amíg ez nem változik meg, vagyis nem válik programozható, addig ez tranzisztorpazarlás, mert le kell butítani a geometriai részletességet, hogy ne zabálja két pofára az RT a VRAM-ot.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az Avatar programozható bejárást használ. Az egy szoftveres RT, a DXR 1.1-et csak arra használja, hogy a mintát gyorsítva vegye, de a bejárás teljesen szoftveres, mert amúgy nem futna azzal a részletességgel a DXR-es hardvereken. Programozhatóság nélkül nem tudsz alkalmazni LOD-ot, vagyis el kell kezdeni mindent a legnagyobb részletességgel betölteni, és tulajdonképpen ez megeszi a VRAM-ot. Ezért nem használja az Ubisoft a DXR-nek a bejárását.
Nagyon hasonló az Avatar megoldása a Brixelizerhez. Csak az egy licencelhető rendszer, míg az Avataré az Ubisoft tulajdona.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
PC-n is ez van. Azért működik így. Azért nem kötelező hozzá a DXR. Ha a DXR-re támaszkodnának, akkor nem futna az RT a DXR-t nem támogató hardvereken, például GTX 1000-en vagy Radeon 5000-en, stb. De ugyanúgy shaderből oldják meg, ahogy konzolon, ezért fut, mert az igény csak a compute shader. Tehát fut az RT az említett VGA-kon is. Ezért engedhette meg magának az Ubisoft, hogy kikapcsolhatatlan legyen a sugárkövetés. Ha DXR-en menne, kiírná a startkor, hogy nincs DXR hardvered szóval irány a bolt.
A konzolos megoldás annyiban lehet más, hogy ott ki tudják használni az egységes memóriát, míg PC-n erre azért nehéz építeni, de a koncepció ugyanaz, csak más ALU dolgozik.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az MS-nek erre Xboxon saját API-ja van, tehát ők is ezt kérték. A PC-n egyébként már kiderült, hogy a legnagyobb probléma nem is azzal van, hogy az MS ezt nem akarta, hanem azzal, hogy az alkalmazott BVH adatstruktúra-formátum zárt. Tehát a Microsoft PC-n megkötötte a saját kezét a licenckonstrukcióval, mivel zárt formátumot szállítanak a DXR-ben. Ahhoz, hogy PC-n is programozható legyen ez az API-ból, ki kell cserélni a BVH adatstruktúra-formátumot nyíltra.
#63616 PuMbA : A DXR-nek a gondja nem a mintavételnél van, mert az fontos, a gondja a bejárásnál van, hogy az nem programozható. Az Ubisoft felhasználta a jó részét a DXR-nek, vagyis a mintavételt, és lecserélte a rossz részét, a programozhatóság hiányát. Ezt megcsinálhatja bárki, de a gond az, hogy körülményes. Sokkal jobb lenne, ha az API a konzolos API-khoz hasonlóan gyárilag kínálna programozhatóságot.
Csak ugye most már egy csomó pénzt öltek bele a cégek, és nyilván megy az ellentartás, hogy inkább zabálja kétpofára a memóriát, azt még meg tudják oldani az extra kapacitással, de ne kelljen újratervezni a bejárásért felelős egységeket a GPU-kban.[ 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
hokuszpk
#63619
üzenetére
Az NVIDIA-é. De ők nem nyitják meg, csak az újabb grafikus API-khoz engedik használni. Tehát a Microsoftnak van rá licence, ahogy a konkurenseknek is, de engedély a megnyitásra nincs, így a rendszer jelenleg black box.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#63625
Abu85
HÁZIGAZDA
bitblueduck
#63623
Abu85
HÁZIGAZDA
válasz
bitblueduck
#63623
üzenetére
Olyan is, meg nem is, mint az S3TC, de itt az NV ezért nem kér licencpénzt. Viszont maga a formátum az zárt, tehát nem lehet nyilvánosságra hozni a specifikációját. Valószínűleg valami háttéregyezményről van szó, mert anyagi háttere ennek úgy néz ki, hogy nincs, a licenc gyakorlatilag nem kerül pénzbe, csak azt korlátozzák, hogy ki kaphatja meg.
#63624 b. : Ugyanaz a két formátum. Ha nem lenne a DXR formátuma zárt, akkor a VGA-k sem zárt formátumra épülnének.
De a Microsoft, illetve az API-kat támogató implementációk erre csak használati jogot kapnak, nem kapják meg a specifikáció nyilvánosságra hozatalának jogát. És éppen ezért pont a fejlesztők nem jutnak hozzá az adathoz, ami szükség lenne a megfelelő optimalizáláshoz. Jelenleg csak el lehet hinni, hogy jó lesz, de tudni nem lehet.Aras Pranckevičius blogja, ezt körbejárta: [link]
Nyilván nem véletlen, hogy az Ubisoft ezt a black box jelleget kikerülte. Nem elegáns, de látványos előnyei vannak.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A Microsoft csak használhatja. Az NVIDIA a tulajdonosa a formátumnak. Bedobták a közösbe. Ha a Microsofté lenne, akkor rég megnyitották volna, mert nekik is gond, hogy ez zárt, csak ugye nem birtokolják, így nem ők döntik el, hogy meg van-e nyitva.
Ezért van Xboxon olyan lehetőség, hogy egyedi, nyílt BVH formátumot is lehet használni, mert ott az egy saját döntés, és ezzel túl tudnak lépni a zártság limitjein. PC-n ez nem saját döntés.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A Turing whitepaperben van megjegyezve. Amit az API használ, illetve amire gyártók építenek hardvert egy és ugyanaz a formátum. Ha nem ugyanaz lenne, akkor nem lennének egymással kompatibilisek, és felesleges lenne hozzá hardvert építeni.
Az mindegy, hogy a hardveres implementáció milyen, itt a formátumról van szó. Annak a specifikációja számít, és az jelenleg zárt. A gyártók elérik, mert az API-n belüli munkacsoportban meg van osztva, de kifelé nem vihetik.
A mesh shader nem erre van kitalálva. A probléma itt az, hogy a bejárás nem programozható, és a formátum specifikációi sem ismertek a fejlesztőknek. Ide traversal shader kell, vagy egy azt helyettesítő compute shader, hogy egyedi BVH formátumot használhasson a játék. Lásd Avatar. Ettől a mintavétel még lehet gyorsított.
Nem szükséges teljesen új DXR, mert a mintavételi része jó, csak kell bele egy új gyorsítóstruktúra specifikáció, így nem csak geometria és az AABB-k lennének specifikálva az API-ban olyan módon, hogy az adatokkal tetszőlegesen lehessen bánni. Ezt a részét nem kell felrúgni a DXR-nek, mert használhatók. Ki kell egészíteni csak egy új programozható lépcsővel.
#63632 PuMbA : Itt nem a nyers számokról van szó, hanem arról, hogy maga a memóriaelérés minden másodlagos sugárnál véletlenszerű, tehát nem cache-selhető. Csak az elsődleges sugarak gyorsítótárazhatók, de a sugárkövetésnek nem ez lenne a valódi haszna. Ezért orbitálisan limitált, amit ma látunk, mert nincs hozzá se memória, se memória-sávszélesség, se elég jó programozhatóság.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A chiplet dizájn a felhasználóknak is előnyös, mert az olcsóbb gyártás miatt a termék ára is alacsonyabb lehet.
Itt a legnagyobb probléma az, hogy a 3 nm-es node waferára őrületesen magas. Ha a teljes lapkát arra viszik, akkor fizetsz egy rakás extra költséget az eleve nem skálázódó áramkörökért, miközben előnye nincs. Tehát egy x teljesítményű, felsőházba szánt dizájnt csak azért hozhatsz ki 100-200 dollárral drágábban, mert monolitikus.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
-
Abu85
HÁZIGAZDA
Nagyjából a GA104+GDDR6X kombó kerül annyiba, amennyibe az AMD-nek van a Navi 31+GDDR6 kombó. Ez alapvetően a chiplet előnye, hogy a nem skálázódó elemek olyan node-on készülnek, ahol a waferár a tizede a komolyabb node-nak.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Piacszerzésre egyik cég sem gyúr már nagyon, mert annyira pici lett a piac, hogy nincs nagy jelentősége az egésznek. Az NV sem véletlenül mondta az előző évben, hogy ők már AI cég, nem pedig gaming. Egyszerűen az AI-ban van jövő, míg a VGA-piacban vannak kétségek, hogy masszívan növekedni tud-e, inkább az látszik, hogy egyre szűkülnek a lehetőségek, egyre inkább a platform lesz a döntő.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Ez az AI miatt fontos, mert már csipogott nemrég a ChatGPT vezetője, hogy szar az AI hatékonysága az NV chipeknek. És ez sose lesz jó, amíg ki nem műtik belőle a felesleges dolgokat.
#63735 PuMbA : A konzol az egy nehezebb piac, mert annyira érték lett a visszafelé kompatibilitás, hogy itt nagyon be van bástyázva a gyártó már. Ugye csak az adott gyártó tud biztosítani megfelel kompatibilitást, mert egy új gyártó nem tudja felhúzni rá az optimális ISA-t. Ez kevésbé fajsúlyos dolog, mert valójában csak a Nintendo tartható meg, új cég nem szerezhető hozzá. Hacsak nem jön valaki negyediknek.
[ 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 AI gyorsító az valójában nem más, mint egy mátrixszorzásra kigyúrt rendszer. Ebben kell jónak lennie, jó sok memóriával, AI-ra optimalizált memóriaalrendszerrel. Na most igazából a GPU-vonal ebben pont elég szar.
Itt senki sem akar 3rd party integrációt, mert nincs mit hozzáadni a rendszerhez, ugyanis a mátrixszorzás, amit használnak, az eleve van. A kulcstényező itt az, hogy fosszák meg a rendszert a grafikai (és még a klasszikus HPC) dolgoktól, mert az csak teher, és onnan jön a rossz hatékonyság. Ezért is mondta Jensen, hogy mostantól AI cég az NVIDIA, hogy ne legyen kérdőjel abban, hogy innentől bármikor kidobják a grafikára szabott áramköröket, ha az az AI-nak előnyös, és alapvetően az.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#63798
Abu85
HÁZIGAZDA
huskydog17
#63797
Abu85
HÁZIGAZDA
válasz
huskydog17
#63797
üzenetére
Foglalkoznak vele, csak nem sokat tudnak tenni, mert nem az övék a motor. Az UE5-tel általánosan van valami gond, mert nem az első eset, amikor az egyik frame-gen opció rosszul működik, lásd az Immortals of Aveum és a DLSS 3 esete az instabilitással, ami miatt implementálniuk kellett a fejlesztőknek az FSR3-at. Vagy a Lords of the Fallen, ahol ki kellett kapcsolni a DLSS 3-at.
Ezek nem működnek out of box, mert vagy a motor kódját nem érik el, vagy az eljárásét. És ez a jövőben is változhat, mert amivel sokan küzdenek, hogy egy engine frissítés ki tudja ütni a frame-gen kompatibilitást és stabilitást, ami az UE5-re tipikusan jellemző. Tehát egy új motorverzióval az eredeti frame-gen instabil lesz, tehát mehet offba, amíg ki nem javítja valaki. Ezekkel egy indie nagyon nehezen tud mit kezdeni, pláne a forráskód hiányában.
Az FSR3-nál csak azt látjuk, hogy ez a jelenség nem csak a DLSS3-at sújtja. És itt valami az UE5-tel van, mert tipikusan olyan játékokban nem jó a stabilitás DLSS3-mal és/vagy FSR3-mal, amik UE5-ösök.
[ 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
Albus_D
#63804
üzenetére
Sajnos ez bonyolultabb. Az Immortals of Aveum esetében sokáig keresték a megoldást a DLSS3 gondjaira, de nem találták. Aztán hirtelen implementálták az FSR3-at. De ezt nem tervezték, az AMD is azért nem jelentette be előre, mert nem volt sokáig tervben.
Az, hogy a háttérben mi volt nem tudni. De mivel az UE5-nél már nem az első eset, hogy köhög a frame-gen, így valszeg van valami háttérgond a motorban. És ezt azért írom, mert eddig kétszer a DLSS3-mal volt gond, és most az FSR3-mal, tehát nem specifikus jellegű.
Az 1.0.7-es dll azért nem volt megoldás, mert azzal romlott a stabilitás, ha csak ennyit lett volna a gond, akkor a fejlesztők is kicserélték volna egy másik verzióra a kódot, és akkor nem is kezdtek volna bele az FSR3 implementálásába.
[ 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
Albus_D
#63806
üzenetére
És a fejlesztők ezt azért nem csinálták meg, mert nem működik jól a régi kód. Instabilabb lesz. Nyilván tesznek rá, hogy ti kicserélitek a dll-t, de ők nem adhatnak ki instabil kódot, mert onnantól nem mondhatják a panaszokra, hogy user error.
Vagyis egy hónappal korábban írtak róla, ami nem túl nagy idő. A Forspokent jóval korábban reklámozta a cég, míg az Immortals of Aveumot nem igazán, mert hirtelen döntés volt a fejlesztők részéről, miután nem tudtak mit kezdeni a DLSS3-mal.
[ 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
Albus_D
#63808
üzenetére
Ha megnézed, akkor az UE5-nél már ez a harmadik játék, ahol valami gond van a frame gennel. Két esetben a DLSS3-at érintette, míg most az FSR3-at. Itt valami a motornál nem stimmel, mert ha a DLSS3-mal vagy az FSR3-mal lenne gond, akkor ezek a problémák előjöttek volna más motornál is. Viszont kizárólag az UE5 címek küzdenek ilyenektől, sorrendben Immortals of Aveum, Lords of the Fallen és Nightingale. Ez már nem az első eset, hanem a harmadik, ugyanazzal a motorral. Ez már trend.
#63809 Albus_D : Az őket nem érdekli, hogy ezen nevetsz, amíg vissza tudják írni a supporton, hogy a dll cserére nincs garancia, így user error. Ezzel ők egy csomó pénzt spórolnak.
[ 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
Albus_D
#63811
üzenetére
A DLSS 3 konkrétan ki lett véve a Lords of the Fallenből, mert nem volt stabil a motor vele. Az Immortals of Aveum esetében hónapokig reszelték, mire belerakták az FSR3-at, és most kb. úgy hagyták, ahogy van, mert van alternatívája, ha valakinek nem jó a meglévő DLSS3 kód. És a tesztek alapján látványos is, hogy nem jó, mert az FSR3 implementáció minőségre jobb lett. Tehát nem a fejlesztőknél van a gond.
Szerk.: Közben szerkesztetted, így amire válaszoltam az már nincs benne a hsz-ben. Örülök, hogy magadtól is átgondoltad, és rájöttél, hogy mi a helyzet.
[ 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.
