Új hozzászólás Aktív témák
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Itt azért lesz némi. Elég sok változott a korábbi Ego motorokhoz képest. Ez az új motor valódi next-gen, voxel cone tracing, hatékony fénykezelés, tele részecskeeffektekkel, stb, de a legtöbbet teljesítményt egyébként az árnyékok zabálják.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#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.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A DLSS-t alapvetően készre kapják, tehát azért aligha hibáztatható az Ubi, de a játék többi elemében vastagon benne vannak. Márpedig vannak nem kis problémák a PC-s porttal. Gondolom a DLSS a legkisebb, azért felmarkolták a pénzt, és szarnak bele.
[ 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
awexco
#42072
üzenetére
Mert ez Kína. Ott nem önhatalmúlag cselekednek ezek az emberek, hanem pártutasításra. Wu feladata most az lehet, hogy elhúzza addig a deal akadályozását, amíg Kína nem dobja teljesen az ARM-ot.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#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.
[ 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
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]
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#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.
[ 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
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.
[ 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
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ 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
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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ó.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
-
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.
[ 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
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az AMD 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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#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.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#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.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#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.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#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.Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#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é.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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ó.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#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
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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ó.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ 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
#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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem a 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.
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
válasz
Raggie
#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.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
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.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
Szimplán compute shaderben le van implementálva. Az új Call of Duty ezt használja, és minden DirectX 12-es VGA-n megy.
Ú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.
- iPhone 14 PRO - Arany - Gyönyörű
- iPhone 14 PRO MAX - 2026.10ig Garancia - Független
- Microsoft Surface Book 2in1 Érintős Szétszedhető Laptop Tablet 13,5" -60% i5-7300U 8/256 QHD+ Win 10
- Lenovo Thinkpad T490, 14" FHD IPS, I5-8365U, 16GB DDR4, 256GB SSD, WIN 10/11, Számla, garancia
- Féláron! Új Dell XPS 13 9315 Prémium Érintős Profi Ultrabook 13,4" -50% i7-1250U 16/512 UHD+ Iris Xe
Állásajánlatok
Cég: Ozeki Kft.
Város: Debrecen
Cég: Ozeki Kft.
Város: Debrecen