- Androidos tablet topic
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Melyik tápegységet vegyem?
- Bambu Lab X1/X1C, P1P-P1S és A1 mini tulajok
- Milyen alaplapot vegyek?
- OLED TV topic
- Házimozi haladó szinten
- VR topik (Oculus Rift, stb.)
- Vezeték nélküli fülhallgatók
- HiFi műszaki szemmel - sztereó hangrendszerek
Hirdetés
-
Rövid előzetesen a S.T.A.L.K.E.R. 2: Heart of Chornobyl
gp Továbbra is szeptemberi premierrel számolnak a fejlesztők, reméljük több halasztásra már nem kell számítanunk.
-
Érkezőben a Poco M6 4G
ma 5G-s és 4G-s Pro modell már van, hamarosan lesz Poco M6 4G-s alapváltozat is.
-
Toyota Corolla Touring Sport 2.0 teszt és az autóipar
lo Némi autóipari kitekintés után egy középkategóriás autót mutatok be, ami az észszerűség műhelyében készül.
Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
Igen, az RX 6600-ak max RT minőséget nem nagyon fognak majd felmutatni. Talán a számítási kapacitásuk sem lesz meg hozzá, de lesz ehhez és a VRAM-jukhoz kisebb részletességi szint.
#5 Yutani : 1440p max+RT 105 fps 6800XT és 90 fps 6800.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Szabvány kódnál most az látszik, hogy kb. ugyanannyit veszítenek a VGA-k, ha mindkét gyártóra van optimalizálás, és az adott VGA-n van elég VRAM.
#11 Yany : Ha a GPU csinálja a kitömörítést, akkor a tömörített adatokat is a VRAM-ba kell másolni, nem csak a kitömörítetteket. Szóval a VRAM terhelése ettől valóban nőni fog. De a VRAM kapacitása marad, csak egy része tömörített adatokra megy majd el.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A Hangar demó is tele lesz RT-vel. GI, reflection és shadow. De a referenciademó az technikai volt, nem a minőségre mennek, hanem a megvalósításra, a forráskód elérhető volt a fejlesztőknek, stb. Ez volt a célja.
Akinek egyedi kell veheti azt, míg a referencia megy az OEM-eknek, de a gyártók megtarthatják.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az aktuális verzió rendkívül zabálja a VRAM-ot. Ez a gond. Semmire nem mennek, ha bekapcsolhatóvá teszik, mert csak felbőszítik az NV-tulajokat, hogy szaggat a kevés VRAM miatt. Nem mellesleg az NV-nek is nagyon rossz reklám az, hogy a termék kiadása után két hónappal már kevés a rajta lévő memória. Simán kérhetik, hogy ne csinálják már ezt, hanem várjanak, amíg lesz optimalizáltabb kód.
Mérnöki mintákat kapnak a partnerek. A kiadás előtt egy évvel a gyártóknak már vannak hardverei, a legközelebbi partnerek ezeket is megkapják. Tehát van olyan stúdió, amelyik már egy éve használhat RDNA2-t vagy Ampere-t.
[ 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ért lehet a véleményed, mert még nem láttad, hogy mennyire gyorsan fut ez a játék RT-ben 6800 XT-n. 1440p-ben 105 fps-t tud. RT-t kikapcsolva 121 fps. Szóval nagyon gyors az RDNA 2-re az implementáció. Az egyetlen gond, hogy két pofára zabálja a memóriát, mert nem csak pár virtuális méterig engedik futni, ahogy a régebbi játékokban, hanem nagyon messzire lövik a sugarakat. Így viszont sok objektumból kell betölteni a legrészletesebb verziót a memóriába.
A Cyperpunk fejlesztői már megírták, hogy a megoldásuk teljesen szabványos. A Godfall azért megy csak az AMD-n, mert nem is szabványos, csak a DXR 1.1-re építettek egy kiegészítést, ami leviszi a memóriahasználatot. De ezt csak AMD-n tudják alkalmazni, mert NV-nek nincs olyan szervizkönyvtára, ami detektálná a találatokat a DXR-ben. Valószínű, hogy lesz, mert ezt a problémát pusztán a DXR 1.1 alatt nem lehet megoldani, tehát muszáj lesz valami NV specifikus API-t bevetni, hogy levigyék náluk is a memóriahasználatot. Jó eséllyel ez már létezik, csak még nem publikus, de ők bőven elérhetik, mert szükségük van rá. Ha van a találatra szervizkönyvtár, akkor onnan már át lehet vinni a munkát mondjuk az OptiX-ba. Az már egy sokkal kevésbé kötött rendszer a DXR-hez viszonyítva, és ott meg lehet csinálni ugyanazokat az optimalizálásokat, amiket az AMD-re megcsinálnak. Azzal már mehet is a kód, de az sem lesz szabványos. Viszont legalább jól fut, és ez a fontos. Megtehetnék azt is, hogy szarnak bele, és akkor vegyél 3090-et, ha be akarod kapcsolni, de az nem a normális hozzáállás, neki pont ugyanolyan fontos egy NV VGA-val rendelkező felhasználó, és ha ki tudnak dolgozni az NV-vel erre egy optimalizálást, akár az NVAPI-n keresztül, akkor megcsinálják.
#44 arn : Őket semmi, de tesztelni, és production ready szinten effektet szállítani elég nagy különbség. Utóbbi esetben ugyanis számít, hogy mennyire gyorsan fut.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Meg lásd sok játék, de itt nem ez a lényeg, hanem, hogy mennyire messzire lövik a sugarakat. Ettől függ a terhelés is. A Godfall a nyílt jellege miatt eléggé távolra is számol, és ez az oka annak, hogy az RT effekt annyira memóriaigényes, mert nagy távolságban már rég valamelyik kis részletességű LOD-ot kell használni a modellekre, de az RT effektnél a sugár kilövésének pillanatában kell megválasztani a LOD-ot. Ha hamar találja el a sugár az objektumot, akkor ugye közel van a kamerához, és kell a részletes geometria, de ha messze lesz találat, akkor nem kell a részletesség, viszont ezt menet közben az aktuális DXR futószalagokon nem lehet jól kontrollálni, tehát kényszerből beállítják a maximális LOD-ot mindenre, mert a sugár kilövésének pillanatában nem lehet tudni, hogy a kamerától milyen távol lesz találat. Ez a probléma. A régebbi RT játékok ezt úgy kezelték, hogy nagyon limitált távolságig lőtték ki a sugarakat, és az eredményt sem a maximális részletességű LOD szinttel számolták. Ez egy memóriakímélőbb megoldás, csak rondább. Ha minden kötél szakad, akkor ezt is bevetheti a Godfall, csak a DXR 1.1 lehetőséget ad bizonyos korábbi limitációk megkerülésére, és emiatt jóval nagyobb távolságra dolgoznak, mint régen, ugyanakkor ez teremt új limitációkat, például azt, hogy az effekt rendkívül memóriazabáló lesz. De úgy néz ki, hogy ez valamilyen mértékben kezelhető a DXR-en kívül, és ezért alkalmaznak alternatív megközelítést. Az AMD-nek és az NV-nek is van saját trace engine API-ja erre (Radeon Rays és OptiX), és ezek sokkal többre képesek, mint a DXR, viszont szükség van egy olyan összeköttetésre, amivel a DXR-en belüli munkát részben átviszik egy külső komponensre. Erre kell a szervizkönyvtárakba egy találatjelző. Ha ez megvan, akkor igazából gyártóspecifikus lesz ugyan az RT, de nagyon sokat tudnak segíteni azon, hogy leküzdjék a DXR 1.1 működésének extrém memóriazabálását.
Mondhatod, hogy szemetek, amiért ezt csinálják, de végeredményben nem kevés többletmunkával azt érik el, hogy kevesebb sebességvesztés, illetve kevesebb memóriahasználat mellett szebb effektet kapj a hardvereden. Időigényes és nehéz elérni, de végeredményben tényleg megtehetnék azt is, hogy szarnak rá, és akkor fut ahogy fut NVIDIA-n, nem optimalizálják le, te meg veheted a sok VRAM-os GeForce-ot. Jelenleg olyan 1500 dolláros kiadásba fájna neked, ha nem dolgoznának rajta, hogy működjön az olcsóbb termékeken is.#48 Duck663 : A PhysX már rég nagyon jól fut a CPU-kon. Nem véletlenül kopott ki a GPU-s feldolgozási formája, mert gyakorlatilag utolérte a CPU-s sebességben.
A DXR a szabványért van, de nem tud mindent a szabvány. Mindkét DXR futószalag eléggé limitált, a DXR 1.1 kevésbé, de ettől még vannak határai, és nagyon komolyak. A gyártóspecifikus Radeon Rays vagy OptiX többre képes, és bizonyos effektek működéséhez érdemes ezeket bevetni, mert a sebességnövekedés, vagy pusztán a memóriahasználat javulása ezekkel jelentős lehet.
Ott van még a driverekben a Mantle, a fejlesztői módban elérhető. De egy végfelhasználónak ez nem kell, teljesen jó a DXR is az AMD-nek, amit nem tudnak vele megcsinálni, arra van Radeon Rays 4.0.
[ 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
kikikirly
#52
üzenetére
Ahol jól észrevehető a sugárkövetés hatása, azok pont az árnyékok, mert hagyományos megoldásokkal nagyon nehéz megfelelő minőséget hozni. Ha megnézed, akkor sok esetben az árnyékok lehetnek nagyon hasonlók sugárkövetés nélkül, de egyes esetekben szinte lehetetlen normálisan megoldani ezt raszterizálással. [link] - hónapokig kellene rajta dolgozni, arra meg nincs idő, és a befejtetett munka mellett sem biztos, hogy meglenne a minőség. Sugárkövetéssel ez tényleg csak napok kérdése.
A tükröződés annyiban egyszerűbb, hogy ott az SSR szintén gyorsan ad elég jó eredményt, nincsenek olyan nehézségek vele, mint az árnyékoknál, de persze nem is működik úgy, mint az RT-s megoldás, hiszen screen space. De a befektetett munka szempontjából nem igényel több hónapos munkát, mint az árnyékok. Ezért repültek rá sokan inkább az árnyékokra, mert ott a minőségbeli eltérés tényleg nagységrendi lehet, és egy csomó munkát is spórolnak vele.
Az, hogy külön optimalizálnak a gyártókra teljesen érthető. Ezzel nincs különösebb baj, hiszen az a cél vele, hogy mindkét gyártó hardverein jól működjön.
--- A PhysX-hez ---
Mert hülyeségnek tartják a fejlesztők. Egy csomó memóriát pazarolnak vele. De ettől teljesen megvalósítható bárhol, hiszen vannak rá szabványos API-k, van rá CPU-erő is, csak inkább költik olyan dolgokra a memóriát, amire megéri. Például jobb minőségű megjelenítésre, hogy ne nézzen ki olyan ocsmányul egy játék, ahogy a videón.
Láthatod te is, hogy manapság mennyi GPU-s PhysX játék érkezik. Gyakorlatilag semmi, ennek a fő oka, hogy a CPU-s kód utolérte teljesítményben a GPU-sat. Utóbbit már nincs értelme alkalmazni. Nem is használják.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#58
Abu85
HÁZIGAZDA
huskydog17
#54
Abu85
HÁZIGAZDA
válasz
huskydog17
#54
üzenetére
Anyagilag nem megterhelő a sugárkövetést megcsinálni. Maga az effekt nem drága. Nem pénzre van szükségük, hanem egy olyan szervizkönyvtárra, ami képes detektálni a találatot DXR alatt, és azt átadni egy másik rendszerre. Ennyi a lényeg. Ehhez tehát nem pénz kell, hanem egy funkció az NVAPI-ba, ahogy az AMD is belerakta ezt az AGS 6.0-ba.
#55 Duck663 : Már nagyon régóta nagyon gyors a CPU-s PhysX. Ne a múlt legendáiból éljetek meg, hanem nézzétek meg az új verziókat. A mostani verzió simán az egyik leggyorsabb CPU-s fizikai motor. Annyira gyors, hogy a régi GPU-s teljesítményt is üti CPU-ból. Nem véletlen, hogy manapság nincsenek GPU-s PhysX címek, csak lassítanák a feldolgozást.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Melyik olyan játék használ GPU-s gyorsítást, ami új PhysX-et alkalmaz? Amióta - cirka egy éve - ennyire gyors a rendszer, azóta nincs értelme pénzt pazarolni a gyorsításra.
A Frostpunk nem használ GPU-s PhysX-et.
[ 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
A Chaos nem a PhysX helyett jön, hanem mellé. Az UE4-nek továbbra is a PhysX a fő fizikai motorja, de például a romboláshoz a chaos lesz bevetve, míg a végeselem metódust használó szimulációkhoz a FemFX. Ezek viszont nem tudják helyettesíteni a PhysX-et, teljesen máshogy működnek.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Pontosan, azzal a különbséggel, hogy a 3DMark nem látott még Radeont, de pont úgy rá lehet optimalizálni a működést az Infinity Cache-re, ahogy ezt már megtette a Watch Dogs: Legion, a Dirt 5, és még pár készülő cím. A két említett címben gyökeresen mást látsz, mint a 3DMark tesztjében.
Jobban nehéz lenne csinálni. A lényeg itt az, hogy bizonyos modulokra keressél alternatívát. Egyébként az Unreal Engine 5-ben is lesz PhysX. Le tudnák cserélni, de legalább tíz év lenne, mire írnak ugyanilyen gyorsat. Eközben a PhysX ingyenes, nyílt forráskódú, mindennek megfelel, amire az Epicnek kell.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
#32839680
#72
üzenetére
A memóriazabálás attól függ, hogy mennyire messzire lövöd a sugarakat. Ahogy többször írtam, a DXR futószalagok nem támogatják azt, hogy a sugár kilövése után módosuljon a LOD, tehát már a sugár kilövésekor meg kell ezt határozni, és ha mondjuk a találat a kamerától távol van, akkor is a nagy részletességű tartalommal számol az effeket. Az RT onnan lesz memóriazabáló, hogy sokáig pásztázzák a jelenetet a sugarak, tehát elég messzi objektumokat is eltalálnak, amelyek esetleg a minimális részletességgel vannak betöltve, de az RT miatt be kell rakni a memóriába a maximális részletességű verzióját is.
Egy GI vagy egy reflection is ugyanígy enné a VRAM-ot, ha messzire pásztáznák a jelenetet a sugarak. A régebbi játékokban azért nem volt ez gond, mert a sugarak azért egyáltalán nem mentek annyira messze, de az új játékokban, főleg az olyen open world kaliberű holmikban sokkal tovább kell lőni ezeket. És az aktuális DXR futószalagokon ez bizony zabálja a VRAM-ot. Erre az egyik megoldás, hogy limitálod az effekt működési távolságát, de nem ezt választották a fejlesztők, hanem megpróbálják elérni, hogy kíméljék a memóriát, amellett, hogy megőrzik az effekt minőségét. Ehhez viszont ki kell lépni a szabványon túlra, mert a DXR nem alkalmas számos olyan optimalizálásra, amivel memóriát lehet spórolni.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Sokkal nagyobbal. Az eddig megjelent játékok közül ők küldik a legmesszebb a sugarakat. Ezért probléma nekik a memória, míg a többinek ezért nem volt az. Ez van. De elvileg meg fogják oldani úgy, hogy nem kell visszavenni a távolságból.
Ha erre lesz életképes megoldás, akár specifikusan per gyártó alapon is, akkor az másnak is jó, mert kezelik az egyik legnagyobb gondot: a memóriazabálást. A megoldás mehet is a következő DXR-be.
[ 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 elég jelentős problémát jelent a nagy részletességű LOD-ot használni távol. Megbirkózik vele a hardver, de nagyon zabálja a VRAM-ot. Szóval ennek a kezelése nem egyáltalán nem felesleges, mert a VRAM-mal lehetne ám spórolni is. A brute force megvalósítás nem mindig kifizetődő.
#88 morgyi : A Godfall implementációja az AMD-n azt csinálja, hogy dinamikusan LOD-ot vált a sugár kilövése után. Ezt programozható bejárással meg lehet csinálni nagyon egyszerűen. A gondot az jelenti, hogy szabványos futószalagon belül nem programozható a bejárás. Az NVIDIA-ra már dolgoznak egy megoldáson, ami hasonlóan képes a LOD-dal játszani, igaz nem pont ugyanúgy, ahogy az AMD-n teszik, vannak vele kezelendő kellemetlenségek, de úgy néz ki, hogy ráhackelhető ez a működés a hardverre, és így Ampere-en is spórolnak a VRAM-mal, miközben az effekt minőségében nem éri majd hátrány a GeForce-okat sem. Van realitása annak, hogy ezt megcsinálják. Ez fontos lehet számukra, mert ez az optimalizálás jelentheti a GeForce-okon a különbséget sebességben. Nem mindegy, hogy 100 fps-sel fog menni a 3080, vagy 20-szal.
[ 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
ph A fejlesztők az NVIDIA GPU-ira később hoznak majd egy memóriakímélő implementációt.
