Keresés

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

  • h_143570

    addikt

    válasz huskydog17 #11 üzenetére

    A RIS nem igenyel jatek oldali tamogatast (az API tamogatas visszont korlatos), a CAS igenyel jatek oldali tamogatast.

  • Abu85

    HÁZIGAZDA

    válasz huskydog17 #11 üzenetére

    Rosszul tudod.

    Az eredeti sharpening csak a FreeStyle által támogatott játékokban működött. Most, hogy kikerült a FreeStyle közül, működik mindennek, ami DX9/11/12. A 10 azért nem szokott megemlítve lenni, mert maga a DirectX 10 API hiányzik a Windows 7-8-10 operációs rendszernél a futtatási környezetből, vagyis minden DirectX 10-es játék automatikusan DirectX 11-es lett, mert ezen a futtatási környezeten indul el. A DirectX 10-nek Vista alatt van értelme, de azt meg már a driver nem támogatja.

    Az AMD RIS mindenen működik, ami DirectX 9/12, illetve Vulkan. A CIS, az amit be kell építeni.

    Egyébként hiába ugyanaz a sharpening név, a szűrők eléggé különböznek. Az AMD RIS lényegében a CAS algoritmust használja, de csak a szűrés van beépítve, a DRS (skálázó) opció már nem. Utóbbi van benne a FidelityFX csomagban, így a játékok belül jobb minőséget lehet elérni, illetve az UI kiemelhető a munkából, vagyis a CAS algoritmus csak a képre fut, nem az UI-ra, egy driverből injektált megoldásnál nem lehet így válogatni. Emellett amíg CAS compute shaderben van írva, addig a RIS PAL-ban. Ez az oka annak, hogy a CAS azért okoz úgy 2-4%-os teljesítményveszteséget, miközben a RIS-nek inkább 1-2%-os deficitje van. Gyakorlatilag a PAL az egy közvetlenül a GPU assembly szintje fölötti réteg, tehát nagyon rá lehet optimalizálni azt a kódot a hardverre, míg compute shadernél ez nem igazán lehetséges. Ez az oka annak, amiért nincs még DirectX 11-re támogatás, mert külön PAL-t használ a DirectX 9, a DirectX 11 (a Windows 7 óta ide tartozik a DirectX 10 is) és a DirectX12/Vulkan (az explicit API-knak az absztrakciója közös az AMD driverében).

    Az NV-nek a sharpeningje eredetileg egyedi shader nyelvben volt a FreeStyle módban, de onnan kiszedték, és átrakták a driverbe, ahol D3BC-ben van írva. Emiatt nincs Vulkan támogatás, mert ez az API nem fogadja el a D3BC kódot, tehát előbb át kell írni SPIR-V-re. Az NV nem foglalkozik nagyon alacsony szintű implementációval, mert nagyon eltérően oldják meg az egyes API-k kezelését, tehát amíg az AMD-nek ez maximum három különböző, hardverhez közeli kódot jelent, addig az NV-nek ötöt, és úgy már inkább megéri írni egy D3BC és egy SPIR-V kódot rá, ami csak két különböző kód. Ez ugyan lassabb, mert átmegy a driver fordítóján, illetve nem is lehet hardverhez közelivé optimalizálni, viszont a karbantartás szempontjából ez az optimális. Ugyanez volt a helyzet a post-process AA-knál, az AMD-nél az MLAA szintén PAL-ban van írva, míg az NV-nél az FXAA a támogatott API-k bájtkódjában.

    A működés tekintetében az AMD RIS egy kontraszt adaptív algoritmus, míg az NV-nek az eredeti sharpening szűrője egy nagyon szimpla luma sharpening rendszer, de az új szűrő már egy high pass sharpening megoldás, bilaterális szűrővel. Ez az új effekt van átemelve a driverbe.
    Itt vannak is összehasonlítások, hogy mennyire működnek jól:
    NV sharpening - AMD sharpening

    NV sharpening - AMD sharpening

    [ Szerkesztve ]

    Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.

  • tomio

    tag

    válasz huskydog17 #11 üzenetére

    Mekkora felbontáson van bemutatva?

    Első blikkre a Turing Integer Scaling jónak néz ki :K
    Viszont elvileg Turing specific feature

    Linux, BSD, ReactOS, MenuetOS, Haiku-OS, Syllable... Van még több is! distrowatch.com/

  • Abu85

    HÁZIGAZDA

    válasz huskydog17 #31 üzenetére

    Azt, hogy a RIS-hez alkalmazásoldali támogatás kell.

    Az NV képén nincs rajta a DX10, de leírtam, hogy miért. A DX10 API nem létezik a Windows 7-nél modernebb OS-nél, így csak DirectX 11 van. Ezen a futtatási környezeten futnak a DirectX 10-es játékok is, és ha valamire azt írják a driverben, hogy támogatja a DX11-et, akkor az automatikusan azt jelenti, hogy támogatja a DX10-et is.

    Az AMD-nek a szűrője kontraszt adaptív. Alapvetően mindig a végső képkockához igazodik, vagyis nincs szüksége külön paraméterezésre ahhoz, hogy ne okozzon fénykoszorúszerű képtorzulásokat az egyes objektumok élein, ahol eleve magas a kontrasztkülönbség az eredeti képen. Az NVIDIA szűrője nem ilyen, így nem tud ehhez igazodni, cserébe kapsz egy csúszkát, hogy ha ezeket a hibákat felfedezed a szűrt eredményen, akkor a csúszka módosításával lehet rajtuk javítani, és megfelelő beállítással gyakorlatilag teljesen el lehet őket tüntetni, csak minden egyes játékra, sőt eltérő jellegű játéktérre más az optimális beállítás.

    (#32) Locutus: A VGA oldalán a kijelzőmotor a lényeg. Ami van a Turingban az biztos, hogy jó, legyen szó 16 vagy 20 sorozatról. A Pascal elképzelhető, hogy jó, de erre vonatkozóan még nincs hivatalos álláspont. Valószínűleg még vizsgálják, hogy működhet-e. Van esély rá, hiszen a HDMI szabványos VRR-je nem igazán különbözik attól, amit a VESA csinál, tehát ha arra jó a kijelzőmotor, akkor majdnem csak szoftveres kérdés, hogy a HDMI-re is jó legyen.

    Az, hogy a tévé tudja a HDMI 2.1-et nem jelent semmi. A HDMI 2.1 VRR-t kell tudnia. Nagyon sok tévén van HDMI 2.1-es bemenet, de nem a szabványos VRR-t támogatják, hanem azt a FreeSyncet, mert az kompatibilis az Xbox One-nal. Tehát olyan HDMI 2.1-es tévé kell, amely ténylegesen a HDMI szabványát kezeli, és nem az Xbox One-hoz való rendszert. Utóbbi azért nem jó, mert hiába van benne a nevében, hogy free, valójában marhára zárt technológia.

    [ 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 huskydog17 #36 üzenetére

    Benne van az eredeti kép a cikkben.

    Még DirectX 9 sincs abban az értelemben, ahogy például a Windows XP-n volt. Úgy működik ezeknek a programoknak a betöltése, hogy egy DirectX9Ex API van, ami tulajdonképpen a WDDM-hez igazodik, miközben biztosítja a kompatibilitást azokhoz a régi applikációkhoz, amelyeket a DirectX9+XPDM-hez írtak. Csak XPDM már a Windows Vista óta nincs. A program azt írja vissza, amit a saját belső adatbázisában betápláltak, hogy visszaírjon egy adott erőforrás létrehozásakor. Ha mondjuk létrejön egy teszem azt D3D11 FL_10_0 erőforrás, akkor ahhoz a program beírhatja, hogy D3D10, de ha ehhez az erőforráshoz az alkalmazás azt írta be, hogy "Juliska bement az erődbe megkeresni a gonosz farkast", akkor ezt a szöveget adja vissza a lekérdezéskor, és nem a D3D10-et. Vagy egyébként visszaírhatja magát az erőforrást is, ami D3D11_feature_level_10_0 lesz egy D3D10-es programnál.

    A WDDM megjelenése óta elég sokat változott az OS, és ezt muszáj volt meglépni, mert a WDDM rohadtul nem kompatibilis a korábbi DM-ekkel. Vagyis az ezekhez tervezett API-kkal sem kompatibilis. Ergo például a DirectX 9 nem létezik Windows Vistától kezdve. Ennek egy olyan verziója van, ami WDDM-hez van írva. Ugyanígy a DirectX 10 sem létezik a Windows 7-től kezdve, a DirectX 11 kapott egy FL_10_0 és FL_10_1 szintet, hogy az alkalmazások futtathatók maradjanak, de ettől az eredeti API már nincs ott! Itt nem a WDDM-mel volt a gond, hanem a futtatási környezetből volt felesleges két ugyanolyat rakni az OS-be, így a DirectX10 API-t eltüntették, és beolvasztottak két kompatibilis szintet a DirectX 11-be.

    Csupán elmagyaráztam neked, hogy miért nincs csúszka. A RIS-nek erre nincs szüksége, mert tud igazodni a képhez. Az NV-nek a sharpeningje nem, tehát ott neked kell beállítanod, hogy jó legyen.

    [ 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 huskydog17 #38 üzenetére

    A friss pdf-ből mentettem, amit a cikkben látsz. Az lehet, hogy utánaszerkesztette magának az NV, mert gondolt azokra, akik nem fogják majd fel, hogy a Windows 7-től kezdve nem létezik D3D10, és esetleg azt gondolhatják, hogy ez nem támogatott.

    A kontraszt adaptív megoldás lényege, hogy mindig jó eredményt adjon. Ezért kontraszt adaptív. Az élesítés nem újdonság. A probléma azonban az vele, hogy a végeredmény tekintetében nem akarod, hogy mindent manipuláljon, ami a képen van. Ezért hagyták ki korábban a játékokból az efféle szűrőket, mert ugyan volt rá egy rakás algoritmus, de mindegyiknél az volt a baj, hogy az elkészülő képek egy részében olyan területet manipulál, amit érintetlenül akarsz hagyni. Timothy Lottes, aki csinálta anno az FXAA-t, tervezett egy olyan algoritmust, ami képes úgy javítani a képen, hogy nem, vagy csak nagyon kevés hibát generál. Ezáltal lett ez reális alternatíva a fejlesztők számára, mert innentől kezdve a kép élesítése minden tartalomra vonatkozóan optimális, tehát nem fogod azt a hátrányt elszenvedni, hogy bizonyos tartalmakra jó a megírt algoritmus, míg bizonyos tartalmakra nem. Ugye utóbbi reális lehetőség egy képszerkesztőprogramban, mert dobnak hozzád egy csúszkát, hogy állítsd be magadnak, aztán kapsz egy tetszetős eredményt, de egy játéknál nem tudja az alkalmazás minden egyes képszámítás előtt megkérdezni tőled, hogy akkor a következő képet milyen paraméterekkel élesítse. Ha megtenné, akkor másodpercenként annyiszor leállna a játék, amennyi képet számol a GPU.

    Persze elmenti, amit beállítasz, csak nem garantálja, hogy minden képkockára jó lesz az eredmény. Ha nem lesz az, akkor állíthatod át. Ezért nincs ugye az NV sharpeningjének direkten játékba építhető verziója, mert a fejlesztők nem ilyet akarnak. Egy képszerkesztőben ez realitás, pár beállítással mentesz pár eredményt ugyanarról a képről, majd a legjobbat kiválasztod, de egy játékban ezt nem lehet megcsinálni.

    [ 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