Új hozzászólás Aktív témák

• #12 Kansas addikt b. #8

  Új Válasz 2022-02-19 12:14:51 #12

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Kansas

  addikt

  válasz b. #8 üzenetére

  Az FSR leginkább 4K felbontáson közelíti meg a DLSS2-t(a DLSS1-et lehagyja kb. mindenhol), ott nincs is szabad szemmel(nagyító nélkül) látható különbség, de kevesebb az artifact.
  1440p-ben és az alatt egyértelmű a DLSS képminőség-fölénye, de csak a b*zi drága RTX kártyákkal műxik, ami azért sokat levon az értékéből, mert pont azokon a kártyákon nem segít, amiknek FHD/QHD-ban szüksége lenne rá(pl. GTX1650 és társai).
  És ha már az ember kicsengeti azt a borsos árat egy RTX-ért, hát nem feltétlenül FHD-ben akar játszani vele. 1440p határeset, én nem szeretem, mert játékokra jó ugyan, de filmezéskor már sokkal kevésbé, ha csak nem 720p forrást nézel.
  Arról nem is beszélve, hogy ha az ember nem kapcsolja be az RT-t, akkor ezeken a kártyákon játszhat akár natív felbontáson is, mindenféle skálázgatós huncutság nélkül, és akkor pont mindegy, melyik melyik skálázást nem kapcsolom be...

  Nincs olyan MI, ami képes lenne szimulálni az emberi hülyeséget... ha valaha lesz, annak tuti az emberi hülyeség lesz az oka... A Föld erőforrásai közül a legjobban az ész van elosztva - mindenki meg van róla győződve, hogy több jutott neki, mint másoknak.

• #16 Abu85 HÁZIGAZDA b. #8

  Új Válasz 2022-02-19 17:03:58 #16

  Új hozzászólás

  Összes hozzászólása itt Válaszok az összes hozzászólására itt Válaszok erre a hozzászólásra

  Privát üzenet küldése

  

  Abu85

  HÁZIGAZDA

  válasz b. #8 üzenetére

  Én mutattam neked képeket arról, hogy mi a különbség. A DLSS-nek és az FSR-nek is megvannak a maga hátrányai. A DLSS-nek az, hogy olyan képi hibákat generál, amik nincsenek benne az eredeti tartalomban, míg az FSR-nek az, hogy nem tartalmaz AA-t, így szüksége van élsimításra.

  Amit írtam, hogy az NV is adhatna plecsnit a legtöbb monitorra, csak a monitorgyártónak ezt igényelnie kell. A hitelesítést az NV és az AMD sem csinálja ingyen. A közhiedelemmel ellentétben ezekért a monitorgyártó pénzt fizet modellenként. Ami ingyenes az a VESA Adaptive-Sync hitelesítés, csak az meg jóval kevesebb tesztet tartalmaz, mint az AMD és az NV hitelesítése, és pont emiatt se az AMD, se az NV nem garantálja erre a hibátlan működést. Ez alapvetően a gyártók részéről érthető, aminél nem győződtek meg a hibátlan működésről, arra egyszerűen nem adnak hitelesítést. Na most maga a hitelesítési folyamat kétféleképpen történik. Az NV nem telepedett oda a monitorgyártókhoz, mert későn kezdtek ebbe bele, így a kijelző fejlesztésének végén, vagy a kiadása után lehet kérni G-Sync Compatible hitelesítést. Itt az NV megszabja, hogy 144 Hz-nél gyengébb monitorokra rá se néznek, de amúgy se adna be egy gyártó se ilyet, mert a G-Sync Compatible hitelesítés nagyon drága, tehát egyszerűen egy megfizethető kategóriába sorolt monitornál nem fér bele. Viszont ha a gyártó kifizeti a hitelesítést, akkor az NV megcsinálja, és a driverbe tesznek egy olyan profilt, ami igazodik a monitor firmware-éhez. Az AMD ezt teljesen másképp csinálja. Egy csomó gyártónál dolgoznak a saját mérnökeik, akik konkrétan megírják a monitorgyártó helyett a FreeSync-hez való frimware-t. Ezáltal a gyártó biztos lehet abban, hogy ha kérnek hitelesítést, akkor az garantáltan át fog menni, mert az AMD írta a monitornak ezt a részét. Ez az oka annak, amiért már ~2000 monitor is hitelesítve van FreeSync-re, a gyártó tudja, hogy mennyi költséget vállal fel a hitelesítését, és maga a sima FreeSync költsége sem annyi, mint a FreeSync Premium vagy Premium Pro kategóriáé. Emiatt egy abszolút kiszámítható költsége van a legolcsóbb monitoroknál is a hitelesítésnek, amit egyszerűen megéri felvállalni. Ha az AMD nem írná meg a frimware-t nekik, akkor ezek a monitorgyártók a FreeSync-re sem adnák be az olcsóbb monitorokat hitelesíteni, mert pont az lenne a gond, ami az NV-nél, egyszerűen nincs garantálva, hogy fix költségből megszerezik a plecsnit, a megfizethető árszinten pedig nincs nagy mozgástér költeni.
  Viszont, ahogy fentebb írtam, az NV is csinálhatná ugyanezt, az AMD-nek nincsenek a gyártókkal exkluzív szerződéseik. Meg lehet írni egy firmware-t úgy is, hogy minden gyártóra jó legyen, mert vannak olyan kijelzők, ahol az NV-re is rá van szabva a monitor default, és azt csak úgy lehet megtenni, hogy gyárilag optimális rá a frimware, így nem kell a meghajtóban kerülőutakat keresniük a potenciális problémákra. Viszont ehhez az NV-nek is oda kell költöznie a monitorgyártókhoz, fizetni egy rakás mérnököt azért, hogy gondoskodni a gyári szintű támogatásról. De ennek az egyik alapja az lenne, hogy a G-Sync Compatible hitelesítés ne legyen annyira drága, amennyi manapság, mert azt nem fogják tudni kifizetni a gyártók a megfizethető monitoroknál.

  A FreeSync erősen kategorizálva van. Van az alap, van a Premium, és van a Premium Pro. Az alap FreeSync, ami nem igazán szab meg követelményt a kijelzőre, a tartomány is meglehetősen szabad, egyedül az az igény, hogy vigye át a hitelesítési tesztet, ami azt garantálja, hogy a kijelölt tartományban működni fog a technológia. A Premium minősítési szint már megkövetel bizonyos dolgokat, kb. azokat, amiket a G-Sync Compatible. Tehát ezt már nem tudják megszerezni minden monitorra, és emiatt ennek az ára elég magas is a hitelesítésnél.

  A Premium Pro egy egyedi szint, aminek nincs G-Sync alternatívája. Ez valójában nem is az Adaptive-Sync-ről szól, hanem a HDR-ről, és egy megfelelő tartalmat kötelező a kijelzőnek megjelenítőoldali tone mapping fázis nélkül kiraknia. Erre majd a HDMI 2.1a kínál majd megoldást a Source-Based Tone Mappinggal. A gond az, hogy ezt nem elég a monitor oldalán támogatni. A szoftverbe is be kell építeni, mert a szoftvernek ki kell olvasnia a kijelző paramétereit, hogy megfelelő képet rendereljen. Ezért van az, hogy a FreeSync Premium Pro rendszert összesen 17 játék támogatja, mert az AGS-en belül kell a megfelelő tone mapping hátteret implementálni hozzá. A Source-Based Tone Mapping már szabványos lesz, viszont annyira zseni a HDMI Forum, hogy elfelejtette a szoftveres hátteret ebbe belekalkulálni, így egyik grafikus API sem támogatja ezt a módszert. Lesz egy harmadik alternatíva is, amit a Samsung készít, ez a HDR10+ Gaming. A koncepció ugyanaz, mint a Source-Based Tone Mapping vagy a FreeSync Premium Pro. Amiért nem mutatták be ezt a CES-en, az az, hogy ők is elfelejtették a szoftveres hátteret hozzá. Az AMD-nek az AGS-e átalakítható lenne a HDR10+ Gaming és a Source-Based Tone Mapping támogatására, de azzal ugyanúgy szart sem érünk el, mert az AGS nem fut NV és Intel GPU-n. Szóval most nagyjából ez a HDR-es dolog ott áll, hogy van még egy zárt FreeSync Premium Pro alternatíva, és végre be van jelentve a szabványos HDMI-s, de szoftveres szinten ezek sehol sem állnak, mert a Microsoft nem gondolt erre a problémára. A Khronos Group annyiban előnyben van, hogy ott van már VK_EXT_hdr_metadata, VK_EXT_full_screen_exclusive és VK_AMD_display_native_hdr. Ezek kellenek egy ilyen rendszer működéséhez, és jó hír, hogy az első kettőt támogatja majdnem mindenki, de az utolsót nem, és a fene megette az pont úgy van megírva, hogy ne is nagyon tudják, tehát abből kell egy gyártófüggetlen kiterjesztésport. Annyiban azért nem reménytelen a helyzet, hogy már van egy elég kellemes kódbázis a problémára [link] / [link] , amit majd át lehet írni, ha a szabvány használatához megjön a híd.

  Valójában a speckó hardver az nem lényeges. Akármelyik felskálázót veszed szemügyre, ezek becsatlakoznak a program pipeline-jába, és igazából onnan önállóan működnek. Tehát a speckó hardvereket, a különböző kódutakat egyszerűen a rendszer lekezeli maga, ezzel a fejlesztőknek nincs munkája. Mindegyik fekslálázónál csak arra kell ügyelni, hogy a pipeline jó részére kerüljenek (ugye tipikusan olyan helyre, ahol még a post-process előtt futnak, mert vannak olyan PP effektek, amik bele tudnak a működésükbe barmolni ... például akármi, ami szemcsés hatást eredményez, azt érthető okokból egyik se szereti). Ilyen szempontból az se gond, hogy az XeSS részben speckó hardvereken fut. Ha ezek elérhetők, akkor lefut a speckó kódút. Ha nem érhető el, akkor van SM6.6 és SM6.4 kódút. A hardverehez kiválasztja a rendszer a megfelelőt és ennyi. Fejlesztői beavatkozás itt nem kell. Van ilyen az FSR-ben is, ott is van packed math optimalizálás, és ha ehhez nem érhető el a hardveres tudás, akkor van egy szimpla konverziós kódút, ami lassabb. Ugyanúgy out-of-box működik a fejlesztők részésről nincs munka vele. Amire viszont figyelni kell mindegyik effektnél az a paraméterezés. Mi lesz a számolt felbontás, ahonnan megy a felskálázás, mi lesz az élesítés paramétere, stb. Ezekre vannak gyártói ajánlások, amikat az esetek többségében követnek a fejlesztők, egy kisebb részében pedig tesznek rá.
  Ami igazából különbség a spatiális és a mozgásvektort használó felskálázási eljárások között, hogy a spatiális alapvetően akármivel kompatibilis a pipeline-on, ellentétben a mozgásvektor miatt a másik megoldásnak csak olyan effektek jók, amelyek temporálisan is jó eredményt adnak. Ha van olyan effekt, amire ez nem igaz, akkor azt le kell tiltani DLSS2/XeSS mellett, mert nem fog jól működni. Ilyen például az Unreal Engine 4 gyári DoF effektje, de erre figyelnek a fejlesztők, amint bekapcsolod az UE4-ben a DLSS2-t vagy a TAAU-t, a motor máris tiltja le a DoF-ot. Szóval a beépítésnél nem a felskálázás a gond, hanem az, hogy kompatibilis-e mindennel, amit a pipeline alkalmaz, sőt arra is figyelni kell, hogy mennyi hibát generál maga a neuronháló.

  [ 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