- Vezeték nélküli fülhallgatók
- NVIDIA GeForce RTX 4080 /4080S / 4090 (AD103 / 102)
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Hobby elektronika
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Milyen videókártyát?
- Milyen egeret válasszak?
- Milyen TV-t vegyek?
- Amazon Kindle
- Amlogic S905, S912 processzoros készülékek
Hirdetés
-
Miniképernyős, VIA-s Epomaker billentyűzet jött a kábelmentes szegmensbe
ph A megfizethető, szivacsokkal jól megpakolt modell ötfajta kapcsolóval és kétféle színösszeállítással/kupakprofillal szerezhető be.
-
Free Play Days 2024 - 17. hét: Railway Empire, Prison Architect
gp Extraként a TramSim: Console Edition című játékot is kipróbálhatják az érdeklődők.
-
Robotkart irányított a majom a kínai Neuralink agyi chipjével
it A mindezt lehetővé tévő Neucybert a Neuralink kínai riválisa, a Beijing Xinzhida Neurotechnology fejlesztette ki.
Új hozzászólás Aktív témák
-
#25
Abu85
HÁZIGAZDA
huskydog17
#11
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[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#26
Abu85
HÁZIGAZDA
Mooka-Miki
#12
Abu85
HÁZIGAZDA
válasz
Mooka-Miki
#12
üzenetére
Ha volt is ilyen dolog, valószínűleg nem ez döntött. A FreeStyle-be integrálva nem működik a szűrő minden alkalmazáson. Csak azokon, amelyek rajta vannak a driver fehérlistáján a FreeStyle-re vonatkozóan. Így viszont, hogy ki lett szakítva a FreeStyle-ből, működhet általánosan.
(#14) Locutus: Csak a VRR, mint funkció. Ehhez nem kell speciális hardver, kábel se. Az aljzat áteresztőképességének erejéig működik.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#33
Abu85
HÁZIGAZDA
huskydog17
#31
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.
-
#37
Abu85
HÁZIGAZDA
huskydog17
#36
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.
-
#39
Abu85
HÁZIGAZDA
huskydog17
#38
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.
-
Abu85
HÁZIGAZDA
A NULL nem újdonság. Már augusztusban ott volt. Az újdonság az, hogy V-Sync és G-Sync egyszerre történő bekapcsolása mellett is működik.
(#44) BusinessGuy: Mit írtam másképp működik. A RIS lényege az, hogy minimalizálja a képtorzulást, miközben azokat az éleket élesíti, ahol nagy a kontrasztkülönbség. Az NV sharpeningje szimpla élesítés, nem tudja úgy elkerülni a képtorzulásokat, ahogy a RIS, mert nem erre van kigyúrva az algoritmus, cserébe van egy csúszka, amivel te tudod beállítani, hogy mi tetszik neked. Nem biztos, hogy jó lesz az eredmény, de végtére is az a célja az NV-nek, hogy neked tetsszen, nem pedig az, hogy torzulásoktól mentes legyen a kép. Az AMD-nek a célja pont ellentétes. Ők alapvetően úgy építették fel az algoritmusukat, hogy a torzulás minimalizált legyen. Emiatt szállítják ezt a fejlesztőknek is CAS néven, mert pont ilyet akarnak a programba az érintettek. Ugyanis tényleg tucatnyi sharpening algoritmus létezik, de mindegyik gondja az, hogy olyan helyen torzít, ahol azt nem akarod. Viszont egy valós időben futó programban ezt nem tudod jól megcsinálni, mint fentebb leírtam, irreális azt kérni a felhasználótól, hogy minden képkocka számítása előtt állítsa be a megfelelő paraméterezést. A RIS-nek ez nem kell, az dizájnból működik úgy, hogy torzulástól kvázi mentesen élesít, vagyis alkalmazható játékon belül.
Ezen nem azt kell érteni, hogy az egyik rossz megoldás. Valójában mindkettő ellátja a feladatát, csak máshogy, mivel elevel más már a működési elvük is. Valójában egyébként az AMD a RIS-t nem a driverbe fejlesztette. A CAS volt a fő cél, hiszen a fejlesztők régóta akarnak egy ilyen algoritmust, csak ugye a korábbi opciók nem alkalmazhatók egy játékban reálisan. A CAS viszont alkalmazható, és mivel ez kész volt, így átírták a driverbe is. Nem nagy meló ez már, hiszen az algoritmus nem változik, csak a programnyelv különböző. Az NV erre reagált gyorsan, csak ők erre nem fordítottak korábban erőforrást, így hasonló algoritmusuk nincs, de ahogy írtam van számos más megoldás is az élesítésre, csak nem úgy működnek, ahogy a CAS. Tehát önmagában maga az élesítés nem újdonság. Ez már évek óta ott van a legtöbb képszerkesztőben. Az újdonság csak az, hogy az AMD csinált egy olyan szűrőt, ami játékokban is alkalmazható, mert kvázi torzulás nélkül élesít.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#50
Abu85
HÁZIGAZDA
BusinessGuy
#49
Abu85
HÁZIGAZDA
válasz
BusinessGuy
#49
üzenetére
Mint írtam, nem az van, hogy az NVIDIA sharpeningje rossz, mert nem az. Az van, hogy az AMD sharpeningje minimálisan torzít, meg az NVIDIA a saját megoldásával ezt nem tudja elkerülni. Ezt úgy képzeld el, hogy van mondjuk 100 képed a játék legkülönfélébb részeiből. Arra ráereszted ezeket. A CAS úgy működik, hogy mind a 100 képből torzításmentes, vagy minimálisan torzított eredményt ad. Az NVIDIA megoldása erre nem képes, tehát optimális esetben neked mind a 100 képre külön kellene beállítani egy ideális paramétert, amivel az eredmény jó lesz. De ez egy játékban kivitelezhetetlen, tehát ha a játék indulása előtt beállítasz egy fix paramétert, akkor abból a 100 képből kb. 90 torzításmentes, vagy minimálisan torzított lesz, míg a maradék 10 esetében látható torzítás jelenik meg a nagy kontrasztkülönbségű élek szélén. Ez a vezető oka annak, amiért a CAS előtt nem igazán alkalmaztak a játékok ilyen élesítést, mert persze lesz egy jelenetsor, amire jól fog működni, de lesz egy másik, amire rosszul. A CAS viszont dizájnból úgy van felépítve, hogy mindenre jól működik, ezért építik be ezt már a játékokban.
Az egy teljesen más tényező, hogy neked mint felhasználónak amúgy belefér, ha a képkockák teszem azt 10%-ában lesz némi torzítás, pláne úgy, hogy ha ezt felfedezed, akkor kilépsz, bemész a driverbe, és átállítod a csúszkát, majd újra belépsz a játékba, hogy megnézd jobb lett-e a helyzet. Emiatt nem rossz az NV megoldása sem, de mondjuk egy játékfejlesztőnek már nem fér bele, mert ők általános megoldásban gondolkodnak, ahol nem kell nagy kompromisszumokat kötni, viszont nem akarnak kimutatható torzulásokat sem az effekt miatt. És itt nem feltétlenül kell szabad szemmel könnyen észlelhető torzulásokra gondolni. A legtöbb esetben az ilyen post-process effekteket úgy ellenőrzik, hogy kivonják a különbséget az input és az output között. Az így kapott kép, csak azokat a pixeleket mutatja, amelyek változnak az adott effekt hatására.
Tehát még egyszer hangsúlyozom. Egyik megoldás sem rossz a másiknál, csak másképp működnek. Ennél egyszerűbben ezt nem tudom leírni.
Egyébként valószínűleg idővel az NV is áttér majd egy hasonló sharpeningre, mert láthatóan van igény a fejlesztői oldalon erre, tehát megéri rá fejleszteni egy olyan effektet, amit oda tudsz adni a partnereidnek. Csak azok a partnerek olyasmi megoldást fogadnak el, mint amilyen a CAS. Most ugye a CAS effekttel nem valószínű, hogy nagy problémája van az NV-nek, mivel maga az effekt eléggé kevés erőforrást igényel, tehát még pusztán az effekt erejéig jobban is fut a Radeonokon, akkor is annyira kicsi a különbség, hogy a végső fps-re nincs igazán hatással. Ellenben mégis csiklandozhatja az orrukat, hogy a CAS úgy van megírva, hogy a Radeonokon gyorsabb kódot futtat, míg a többi hardveren szabványosat. Ezáltal például a GeForce-ok már abból hátrányba kerülnek, hogy ezeknek a hardvereknek FP32-ben kell számolni, majd a számolt eredményből lesz egy FP16-os adat konvertálva, míg a Radeonok eleve FP16-ban számolnak. Ez pusztán a számítás tekintetében azt jelenti, hogy az NVIDIA a hardver teljesítményének a felét bukja, tehát ha tudnának FP16-ban számolni, akkor kétszer gyorsabban dolgozna például a Turing. Emiatt lenne hasznos számukra egy hasonló effekt, ami ugyanúgy működik, mint a CAS, tehát a játékfejlesztők is alkalmaznák, és közben a Turing is FP16-ban számolhatna, mert mondjuk ezt a kódrészt szabványosra írnák. Az AMD sajnos nem írja szabványosra ezt, tehát hiába tud a Turing mixed precisiont, az nem használható azzal a kóddal, amit az AMD szállít. Ez azért különösen szánalmas egyébként, mert van már szabványos lehetőség packingre, Vulkan API-ban eléggé működik is, de az AMD-t nem érdekli, ők szállítják a saját zárt kiterjesztéseikhez a kódot. Az NV-nek itt sok esélye lenne, mert ha ők mondjuk ezt általánosan szabványosra írnák meg, akkor sok fejlesztő inkább az NV-től vinne egy CAS-hez hasonló effektet. Gondolj csak bele. Az AMD-t itt nem érné hátrány, és az NV hardverei is gyorsabban számolnának. Ellenben a CAS-szel, ahol az NV hardvereit a meglévő tudás ellenére hátrány éri, mert úgy van megírva a kód, hogy a beépített tudást nem tudja kihasználni. Szóval a jövőben szerintem az NV is csinál egy CAS alternatívát, és ha már kész lesz, akkor bedobják a driverbe is, utóbbi tényleg nem nagy meló. Leginkább a teszt része, ami időigényes.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Pedig továbbra is az a lényeg, hogy másképp működnek. Csak elmagyaráztam, hogy miben különböznek. De ettől még nem lesz rosszabb az egyik a másiknál.
Két tényezőt fontos kiemelni! Egy hasonló effekt két helyre készülhet. Egyrészt a játékfejlesztőknek, másrészt a játékosoknak a driverbe. Na most a játékfejlesztőknek egészen más igényeik vannak, mint a játékosoknak, mert ők nagyjából tisztában vannak azzal, hogy az efféle utófeldolgozásoknak vannak bizonyos, kisebb-nagyobb korlátjai, olyan nincs, hogy minden rózsaszín, még a CAS is torzít, csak a mértéke a különbség. Már pusztán az algoritmus ismeretében lehet következtetni arra, hogy milyen képi tartalom mellett lehet szó valamilyen nem várt hatásról, illetve ennek a nem várt hatásnak a mértéke mekkora lehet. Ha mondjuk létezne olyan sharpening eljrás ami sehol sem torzít, akkor odaértünk, ahova szeretnénk érni, nincs további fejlődési lehetőség, elértük az élesítés tekintetében a maximumot. De sajnos ez nem létezik, még talán AI-jal sem, utóbbi pedig igazából a teljesítményigénye miatt nem túl szerencsés, hiszen az ismert legjobb algoritmus minimális torzítását talán tovább minimalizálnál, de olyan kis különbségekért fizetnél sokkal több sebességet, hogy nem éri meg bevetni.
Innentől kezdve van két alapvető igény. Egyrészt a fejlesztői oldalon olyan algoritmus kell, ami tényleg minimálisan torzít, mert azt akarod fejlesztőként, hogy a képi tartalom valóban élesítésre szoruló részei legyenek szűrve, érintetlenül hagyva azokat a részeket, amelyeket alapvetően nem akarnál élesíteni. Nehéz, de alapvetően elértünk oda, hogy már van rá egy kvázi működő megoldás, és emiatt ezt elkezdték beépíteni a játékokba.
A másik igény a felhasználói. Na most a felhasználó egészen más kategória. A nagy többség nem ismeri, hogy bizonyos eljárásoknak milyen hátrányai vannak, az összehasonlításokat is szemmértékre nézi, a fejlesztőkkel ellentétben nem használ külön programot rá, hogy lással az input és az output különbségét. Ergo itt már sokkal szabadabb a választás, mert amíg egy fejlesztő szemében lényeges kérdés, hogy a torzítás mekkora mértékű lesz, addig egy tipikus felhasználó a torzítás jelenlétét sokszor fel sem ismeri. És innentől kezdve, egy játékosoknak driverbe épített megoldásnál nem az számít, hogy az eredmény mennyire lesz torz bizonyos képkockákra, hanem az, hogy az eredményt mennyire tartja jónak a játékos. Ebből remélem látható, hogy két alapvető nézet ütközik egymással. Emiatt nem rosszabb az egyik a másiknál, mert csúnyán fogalmazva a célpiac (gyakorlatilag a felhasználók) nem fogja ezt mély elemzéseknek alávetni, ahogy teszi mondjuk egy fejlesztő, amikor nézi a szóba került sharpening algoritmusokat, hogy kiválassza az optimálist.
Hasonló itt a helyzet a depth of field teljesen post-process megvalósításához. Láttam azt, ami van például a népszerű injektorokban. Hát valami pokolian szar, de alapvetően csomóan bekapcsolják, mert szépnek tartják (számomra WTF, de ez van), pedig elképesztően elbaszarintja a képet például azokhoz a DoF eljárásokhoz képest, amelyek egy játékban benne vannak (itt se rózsaszín minden persze
), ahol az alkalmazás nem pusztán a végső képkocka alapján dönt. Ez érthető is. Több adat, jobb eredmény, de sokan vígan elvannak az injektálással, vagyis a felhasználó nem pont torzulásmentes képet akar látni, hanem valami összhatást, ugyanis nem tudják eldönteni, hogy a torzulás jó-e vagy sem. Összhatásban jónak érzékelik, és elfogadják. Nagyjából emiatt sokkal szabadabbak a döntések egy driverbe épített megoldásnál, mert kvázi senki sem nézi szakmai szemmel az eredményt. Viszont pont emiatt nincs is az NV-nek alternatív effektje a CAS-re, mert a fejlesztők pont szakmai szempontokat mérlegelnek.Mindezzel azt akarom írni, hogy különbség lehet az értékelésnél, ha szakmailag vizsgálsz valamit, vagy ha csak összhatást nézel. Előbbinél viszonylag kötött az elemzés, míg utóbbinál nem igazán van rossz megoldás.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#62
Abu85
HÁZIGAZDA
Trailblazer
#60
Abu85
HÁZIGAZDA
válasz
Trailblazer
#60
üzenetére
Nem. Nem egyszerű driverben javítani. Jelenleg inkább alkalmazás oldali megoldásban gondolkodnak. Driverből is meg lehet oldani, de elképzelhető, hogy több hetet/hónapot venne igénybe, hacsak nem állítják vissza a korábbi implementációt, ami viszont lassabb, mint az új. Ez nem szokott opció lenni, mert akkor a 440-es batch minden sebességelőnye elveszik.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
), ahol az alkalmazás nem pusztán a végső képkocka alapján dönt. Ez érthető is. Több adat, jobb eredmény, de sokan vígan elvannak az injektálással, vagyis a felhasználó nem pont torzulásmentes képet akar látni, hanem valami összhatást, ugyanis nem tudják eldönteni, hogy a torzulás jó-e vagy sem. Összhatásban jónak érzékelik, és elfogadják. Nagyjából emiatt sokkal szabadabbak a döntések egy driverbe épített megoldásnál, mert kvázi senki sem nézi szakmai szemmel az eredményt. Viszont pont emiatt nincs is az NV-nek alternatív effektje a CAS-re, mert a fejlesztők pont szakmai szempontokat mérlegelnek.
Új hozzászólás Aktív témák
ph A WHQL minősítésű, 441.08-as meghajtó GeForce Experience nélkül is elérhetővé teszi az image sharpenning szűrőt.
- Mesterséges Intelligencia topik
- Kertészet, mezőgazdaság topik
- Kínában túl sok az EV, fokozódik az árháború
- Vírusirtó topic
- Vezeték nélküli fülhallgatók
- A fociról könnyedén, egy baráti társaságban
- Politika
- Székesfehérvár és környéke adok-veszek-beszélgetek
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Hosszú idő után újabb előzetest kapott a Gothic Remake
- További aktív témák...
