Új hozzászólás Aktív témák
-
PuMbA
titán
DirectX State of the Union: Raytracing and PIX Workflows (Presented by Microsoft)
Eléggé késve, de megjött az előadás. SER és OMM az A jelenetben RTX4090-en Alan Wake 2-ben 1440p-n 16.8ms-ről 10.2ms-re csökkenti a jelenetszámítási időt 10 ray / pixel-es RT esetén
-
PuMbA
titán
Értem. A GDC prezentációban 40%-os sebesség előnyt is tudott mutatni a Remedy a DXR 1.2-vel:
"DXR 1.2 represents a substantial leap forward in raytracing performance, achieving improvements of up to 40% in complex scenes, as demonstrated by Remedy Entertainment with their Alan Wake 2 showcase at GDC."
Remélem minél hamarabb megnézhetjük YouTube-on az előadást
-
hapakj
őstag
-
Abu85
HÁZIGAZDA
Sosem lett kész. A SER-t építették be. Az a gond, hogy az OMM egy nehezen implementálható technika, és nagyon-nagyon pici a sebességelőny, ami jön belőle. Miközben évekig a nyakadba veszel egy jelentős többletköltséget a karbantartással. Egyszerűen átlag 1-2% plusz teljesítményért nem éri meg, és a Cyberpunk tipikusan nem olyan játék, ahol ennek haszna van.
Az 1.65 és a 2.0 ugyanazokat a technikákat alkalmazza, csak a 2.0 optimalizált.
A SER-t támogatja ez az egy játék, de se az OMM-et, se a DMM-et nem implementálta senki. Ezeket irtó nehéz a jelenlegi RT pipeline-okba beilleszteni, mert nem csak programkódról van szó.
Azt számold bele, hogy az OMM az jelenleg nem szabvány. Gyakorlatilag bármikor jön egy új meghajtó, akkor a szabványosítás hiány miatt kénytelen lennél újratesztelni a játékot rá. Ez borzasztóan magas többletköltség egy játéknál, havi két-három meghajtóval. Mert ugye az NV bármikor változtathat az NVAPI-n, és általában meg is teszik, mert nem szabványos. És ez oké lenne mondjuk ha nyernél vele sebességet, de 1-2%-ért? Oké elkészíted, és akkor mi van? Megéri havi kétszer újratesztelni a játékot ezért? Nem, nem fogja. Ezért ezt elvetették. Csak azt a jelentős kockázatot elemezd, hogy ha a DMM-et beépítették volna, akkor most a játék el sem indulna, mert az NV már kivette az NVAPI-ból. És mivel nem szabvány az OMM, ugyanígy bármikor kikerülhet, vagy megváltozhat. Aztán a program oldalán igazodni kellene hozzá. Nagyon magad ellenségének kell lenni ahhoz, hogy ezt +1-2%-ért vállald. Mondjuk a Shadow of the Tomb Raiderben, ott használna, mert ott hozna +10%-ot is, de ők sem vállalták.
Nyilván ezen a gondon a szabványosítás pont segít.
-
PuMbA
titán
Ez biztos? 1.62-es javítás után adtak interjút és ekkor már az implementációján dolgoztak: Cyberpunk 2077 Path Tracing Q&A – ‘Plenty of Room to Further Improve on What We Achieved’; OMM Support Coming
"Are you planning to also take advantage of the remaining optimizations introduced with the Ada Lovelace architecture, such as Displaced Micro-Mesh (DMM) and Opacity Micro-Maps (OMM)?
We are currently working on OMM implementation, but I’m not super certain of what will be our decision regarding DMM. For sure it is a revolutionary technology that brings incredible fidelity to the screen, we just need to see how practical it would be for us taking into account the state we have the game in currently."
Sőt még a hivatalos NVIDIA anyag szerint is használ OMM-et: [link]
"Supporting the new Ray Tracing: Overdrive Mode are several new NVIDIA technologies that greatly accelerate and improve the quality of advanced ray tracing workloads, for even faster performance when playing on GeForce RTX 40 Series graphics cards:
Shader Execution Reordering (SER)
Opacity Micromaps
NVIDIA Real Time Denoisers (NRD)" -
Abu85
HÁZIGAZDA
-
PuMbA
titán
Cyberpunk 2077 2.0 - PC Tech Review - DLSS 3.5 Ray Reconstruction Deep Dive
Cyberpunk-ban 23% sebességet hozott az OMM fás területen.
-
Abu85
HÁZIGAZDA
Mivel úgy van tervezve a hardver, hogy így működjön. Igazából a SER megoldható teljesen hardveresen, csak a hardver maga nagyobb lesz, több tranzisztort igényel. De bármit, amit szoftverből csinálsz végeredményben be tudod építeni a hardverbe annak árán, hogy a hardvered jóval több tranzisztorból áll majd. Ez nem újdonság. A kérdés az, hogy mire éri meg teljesen hardvert tervezni, mit éri meg csak szoftverből futtatni, és mire jobb ha részben van hardver, a maradék rész pedig szoftver. Az AMD szerinte ez fontos annyira, hogy legyen hardver, és abból kiindulva, hogy a SER itt van már évek óta, és ennek ellenére csak egy cím implementálta, az is egyetlen beállításban, arra utal, hogy a fejlesztők nem akarnak ezzel törődni. Vagyis az AMD úgy döntött, hogy legyen meg ez a hardver úgy, hogy a fejlesztőknek ne legyen munkájuk vele.
Egyébként nem az AMD csinált ilyet először, már az Imagination is ilyen jellegű motort épített az RT hardverjeibe.
-
Abu85
HÁZIGAZDA
Mit számít, hogy egy cég mit ígér? Az API világos, az újítás világos. Soha az életben nem hoz majd 2,3x-szeres gyorsulást, mert egyszerűen csak a munkafolyamat egy aprócska részén alkalmazható. Ilyenekből születnek a csalódások, hogy várod az új címeket, hogy támogatja a DXR 1.2-t, hogy majd gyorsabb lesz a 2x OMM miatt és a megint 2x SER miatt, tehát majd 4x gyorsabban fog futni biztos, aztán azt látod végül, hogy semmivel sem fut gyorsabban, mert ezek együttes hatása a teljes képkockára levetítve jó ha van +2-4%.
Eleve a SER-ből indulj ki. Ezt az AMD az RDNA 4-ben helyettesíti egy hardverrel. Tehát bármilyen kódot úgy futtat, mintha az át lenne írva SER-re, csak nem kell átírni hozzá. És nem lesz ettől 2x sebességed. Persze, a másodlagos sugarakra biztos hoznak ennyit, de az a munkafolyamat egy apró része. Tehát összességében, amit nyernek inkább +3%-hoz van közelebb.
-
Abu85
HÁZIGAZDA
Leírtam, hogy mit hoz az 5. hsz-ben.
Egyetlen egy cím van jelenleg, ami SER-t használ. OMM-et még semmi sem. A Cyberpunk 2077 overdrive módja a SER-től 3%-ot gyorsul. 3%-ot érted? Azért nem tud ennél többet, mert a teljes munkamenetnek csak egy nagyon aprócska részét gyorsítja meg 2x-esre, de az a munkamenetnek mindössze 5-7%. Máshol nincs hatása, mert a többi sugár eleve koherens.
A legnagyobb baj, hogy konstans benyaljátok a marketinget.
És ez egyébként nem a gyártókról szól, mert egyébként ezzel senki sem jár rosszul. Az OMM az az ARM-nak a megoldása, ez lesz implementálva a DXR 1.2-be. És ezt már most tudja támogatni az AMD, az ARM és az NV. Az Intel is tudná valószínűleg, mert nekik is van részben hardverük rá, majd ezt meglátjuk.
A SER-t tudja támogatni az NVIDIA és az Intel, az AMD-nek pedig az RDNA 4-je eleve hardveresen így működik, tehát nekik még külön programkód sem kell ahhoz, hogy így dolgozzon. Szóval erre nekik elég egy felületet írni, ami befogadja a kódot, és a hardver úgyis elvégzi, ahogy el szokta végezni a specifikus kód nélkül.
A probléma itt az, hogy olyan dolgok ezek, amelyek már évek óta léteznek, és mivel nem arra reflektálnak, ahol elveszik a DXR teljesítménye, nem is igazán vannak használva a játékokban, mert nem sok értelmük van addig, amíg pusztán maga az API olyan lassú, hogy másodlagos sugarakhoz nyúlj nagy mennyiségben. És ezért nem nagyon hasznos a fejlesztőknek ezzel törődniük, mert már ott játszhatatlan az egész, hogy path tracing, mert az API maga nem illeszkedik ehhez. Kismillió hardvert hozhatsz erre, a limit nem itt keletkezik, hanem az API működésében. És ezért hozta az NV is a 4x képgenerálást, mert hozhatnak 100x erősebb RT teljesítményt is, az API limitjét nem tudják megkerülni. Tehát vagy nem használod ezt a képességet, vagy szopsz a 4x frame gen masszív képhibáival.
Ez itt jelenleg mind marketing, mert nem hasznos fícsőrök. Nem tudod őket működtetni képi hibákat okozó rekonstrukciós technikák nélkül. Egy köztes gyorsítóstruktúra kellene, hogy megoldja azt, ahol az API jelenleg limites, de amíg ez nincs, addig hiába hoznak olyan technikákat, amelyek reálisan hasztalanok köztes gyorsítóstruktúra nélkül. Ezért nincs a SER-nek és az OMM-nek támogatása úgy sem, hogy tényleg évek óta elérhetők.
-
GeryFlash
veterán
Ja nem, abszolut nem hoz ujdonsagot csupan 2.3X-ros teljesitmeny javulast path tracing eseteben . Elkepeszto ez az alternativ valosag amit a fopap itt teremt a PH-n evek ota, most hogy az Nvidia a vilag egyik legertekesebb cege lett az elmult evekben mikozben folyamatosan elo volt itt adva, hogy majd az AMD-nek all a jovo ezzel mar tuti tudathasados allapotba kerulhetett az oreg.
-
gV
őstag
az AW2 mikor kapja meg ezt vajon? hmm.. lehet félre kéne tennem addig a Final draftot (NG+).
engem az zavar, hogy nem ír konkrétumot. ott a TPU RT oldala zárójelben mennyit lassít az adott VGA-n az RT. megírhatná ahelyett, hogy rém lassú a DXR, hogy mekkora -%-nak kellene lenni, hogy azt mondja a DXR-re, hogy iszonyú gyors. -
Más oldalon: [Microsoft Unveils DirectX Raytracing 1.2 With Huge Performance & Visual Improvements, Next-Gen Neural Rendering, Partnerships With NVIDIA, AMD & Intel]
Mindegyik gyártónál 1-2 kártya kategóriával gyorsabb működést hoz , annyi hogy Nvidiánál már működik a többieknél meg fog. Alan wake 2 DX 1.2 demó ugye smafu....
Nem értem amúgy mi a fenéért kell a saját véleményét folyamatosan beilleszteni a híreknél miért nem bízzza ezt az olvasóra.Tényszerű újságírás forever...
jah amúgy meg hát mindeki tudja mi van mögötte le se kellett írnom, Biztos véletlen.
-
Abu85
HÁZIGAZDA
Le van írva, hogy nem a fícsőrök a gond, hanem az, hogy ettől még továbbra sincs megoldva az RT-nek a memóriazabálása, és a rossz hatásfoka.
De akkor részletesebben. Az opacity micromaps segítségével a shader invokációk csökkenthetők, vagy akár el is hagyhatók. Ha elég nagy a geometria, akkor ez valóban hozhat 2x-es gyorsulást, de ahhoz nagy geometria kell, mert átlagos geometriánál ez nem igaz. Ott inkább 10-20% plusz a jellemző, és ez csak az eljárásra értett gyorsulás a tradicionális alpha testinghez viszonyítva. Tehát a teljes képkocka szintjén számolva ez a gyorsulás nem lesz nagyobb 0,9-1%-nál. Optimális esetben. Emiatt nem implementálta ezt senki, mert ahol számít, ott a DXR eleve rossz hatásfokkal működik, ahol pedig használható, ott szökőévente ha nyernek +1%-ot a teljes képkockára levetítve, ami nem éri meg a befektetett munkát.
És pont emiatt baj, hogy amúgy az opacity micromaps egy tök jó dolog lenne, tényleg nem igényel extra hardvert, mert egy szoftveres fícsőr az egész, a legújabb hardverekbe implementálni lehetne, legrosszabb esetben az LDS-t használva, de igazából amíg a bejárással kapcsolatos gondot nem oldja meg az DXR, addig pont annyira fogják használni ezt a képességet a fejlesztők, amennyire most használják. Semennyire. Mert ez most is elérhető. Sőt, már több éve elérhető, és most is lehetne támogatni +1%-ért. De senki sem csinálja.
A DXR verziónak annyi előnye, hogy nem az NVIDIA specifikációi szerint van tervezve, hanem az ARM specifikáció szerint. Tehát nem az NVIDIA technikája lett implementálva, hanem az ARM-é. Elsődlegesen azért, mert hatékonyabban működik, de még így is kicsi potenciális gyorsulás, amíg a DXR bejárással kapcsolatos gondjait nem oldják meg. Viszont az ARM megoldása implementálható a legtöbb hardverre. Ezért tudja az NV is támogatni a Turing és az Ampere architektúrán, holott a saját megoldásukhoz Ada kell minimum. És emiatt a többi gyártó modernebb dizájnjai is támogatni tudják. De a jelenlegi geometriai terhelés mellett 1% extrát, ha hoz, ez továbbra sem változott meg.
A shader execution reorderingnek már több haszna van, de azt is csak ritkán implementálták eddig. A legnagyobb gond vele az, hogy sok munkát igényel, és akkor van csak hatása, ahol már a DXR eleve nem működik jól a nem koherens sugarak miatt. Például ezt eleve megpróbálják elkerülni a játékok, nem véletlenül, hogy az egyetlen cím, ami a shader execution reorderinget eddig beépítette az a Cyberpunk 2077 volt, de kizárólag az egyik beállításra, méghozzá az overdrive módra. És ezt jó okkal tették így, mert csak az overdrive mód alkalmaz másodlagos sugarakat. Tehát minden más módnál 0%-ot hozna a shader execution reordering, de overdrive mód alatt is az a gond, hogy a másodlagos sugarakkal kapcsolatos számítások a teljes sugárkövetés 2-3%-át teszik ki, tehát a shader execution reordering ezt a 2-3%-ot gyorsítja kb. a kétszeresére. Tehát a teljes képkockát tekintve itt is kb. 1-2%-nyi összesített gyorsulásról van csak szó.
Mellesleg ez az egész például az Intel és az AMD modernebb dizájnjait azért érintik kevésbé, mert a Battlemage részlegesen, míg az RDNA 4 teljesen kezeli a másodlagos sugarak koherenciáját. Egyszerűen a hardver mindenféle extra szoftveres támogatás nélkül csoportosítja a sugarakat, hogy a koherensek lehetőleg közös szálcsoportba kerüljenek.Szóval örüljetek az 1%-nak, ha tetszik nektek, de ez semmit nem javít azon, amiért sokszor rém lassú a DXR. Az arabus által közölt 20-40% pedig irreális. Ha ennyit jelentene mindenki implementálta volna az elmúlt 2 évben, mert ennyi ideje érhetők el. De nem basszus, 1-2% maximum, ez is szökőévente.
-
#3
hapakj
őstag
Hellwhatever
#2
hapakj
őstag
válasz
Hellwhatever
#2
üzenetére
jah
Igazából ezzel a bejárással kapcsolatos problémákat is leginkább itt lehet olvasni
-
#2
Hellwhatever
aktív tag
b.
#1
Hellwhatever
aktív tag
2 Nvidia feature kerül szabványosításra: Jön a DirectX Raytracing 1.2, de nem sok újítást hoz
2 AMD feature kerül szabványosításra: Jön a DirectX Raytracing 1.2, apró, de hasznos újításokat hozUtána meg megy az oktatás hogy itt aztán nem készülnek előjeles tartalmak egyik oldal irányába se, business as usual
Új hozzászólás Aktív témák
ph A neurális leképezés kapcsán is kiderült, hogy melyik shader modellbe kerül majd be.
- MSI RTX 5080 16GB GDDR7 VENTUS 3X OC - Új, 3 év garancia - Eladó!
- ASUS RX 6800 16GB GDDR6 TUF GAMING OC Eladó!
- PNY - Founders - Referencia hűtéssel - GTX 780 TI - Korának leggyorsabbja - Gyűjtőknek is
- XFX Radeon Speedster MERC 319 RX 6800 XT 16GB GDDR6 256bit // dobozos // 34 CM HOSSZÚ, 1,8 KG !!!
- ASRock RX 7800 XT 16GB GDDR6 Challenger OC - Új, bontatlan, 3 év garancia - Eladó!
- Újra Akcióban!!! Ducky One 2 Mini és SF billentyűzetek a bolti ár töredékéért! Számla+Gari
- ÁRGARANCIA!Épített KomPhone i5 14600KF 32/64GB DDR5 RAM RTX 5070Ti 16GB GAMER PC termékbeszámítással
- Bomba ár! Dell Latitude 5500 - i5-8GEN I 8GB I 256SSD I HDMI I 15,6" FHD I Cam I W11 I Garancia!
- Bomba ár! Dell Latitude 5410 - i5-10GEN I 16GB I 256SSD I HDMI I 14" FHD I Cam I W11 I Garancia!
- Honor X6b 128GB, Kártyafüggetlen, 1 Év Garanciával
Állásajánlatok
Cég: Laptopszaki Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest