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

  • janos666

    nagyúr

    LOGOUT blog

    válasz Abu85 #150 üzenetére

    Azt tudom, hogy az RTSS limit csak fps limit, ami nyilván nem váltja ki a kijelző-szinkront.

    A linkelt hsz arról szól, hogy állítólag minimálisra csökken a RAQ-ban pihenő képkockák száma, ha picivel a sync frekvencia alá limitáljuk az fps-t CPU oldalon (itt épp most azért RTSS-el, mert ez tud ma ismert módon ilyen ezred-fps precizitással limitálni, illetve a lánc kellően korai pontján dolgozik ehhez, amit itt el akarunk érni vele), mert ha csak maga a kijelző-sync ad egy limitet a lánc végén (ami már a GPU oldalon is a lánc vége, míg a RAQ a CPU oldalán él a GPU előtt), olyankor tervszerűen felduzzad a RAQ az (általában statikus értékként előre, és "liberálisan" kiszabott) maximális megengedett hosszára, míg ha valami CPU oldalon "folytja" az fps-t (vagy épp nincs használatban semmi olyan képernyő-szinkron, ami valamiképp limitálna a GPU oldalán), akkor minden képkocka csak minimális időre kerül a RAQ-ba (ideális esetben, ha egyik hardware elem sincs 100%-ra terhelve, és elég sűrű ciklusban fut a RAQ kezelése --- ez még egy érdekes kérdés lehet, hogy ez polling-szerű, vagy direkt elküldik aludni az algót sok ms-re, hadd' duzzadjon csak az a queue, legyen mindig tele), ezzel csökkentve a lagot.

    Nekem régen az volt az empirikus szubjektív meggyőződésem, hogy a hagyományos Vsync az egyben scene-pacing is (bár akkor valószínűleg még senki nem hívta így, és én sem találtam ki rá új kifejezést, implicit a Vsync részének tekintettem), sőt direkt ezért is ragaszkodtam hozzá még akár online multiplayer FPS-ben is (amit már >10 éve nem játszok, és azóta rengeteg minden változott).
    -> Ezt még ma sem értem igazán, főleg mióta látom azt is, hogy mit csinál a FastSync, mennyire nem folyamatos a kép akkor sem, ha az fps a frissítési freki durván duplája, míg sima Vsync-el nincs ilyen bajom (így fura elhinni, hogy ez nem ad egyfajta scene-pacing megoldást is), kivéve esetleg egy anomáliát [***].

    A saját szűk megfigyelésem alapján (Frostbite3: DAI és MEA, mert ezekkel sokat időztem, és itt könnyű ezt kapcsolgatni a játék újraindítása nélkül devkonzolból) a Hawaii-nak, Polaris-nak és Pascal-nak is elég RAQ=2 (3-ra emelve semmi számottevőt nem látok az fps számlálón), de a RAQ=1 valóban feltűnőben bünteti a Pascal-t (CPU idő az egekben, az fps romokban, míg az AMD csak tűrhetően lassul..., de nem tudom ezt be lehetne-e hozni erősebb CPU-val, hisz a GTX1070 eleve gyorsabb kártya mint a 290X vagy RX480, illetve elméletben hajlandó lehetnék erőseb CPU-ra költeni, ha esetleg emiatt lenne értelme), és lehet hogy ez placebó, de mint ha kevesebb lenne az a jelenség, [***] mikor végig 60fsp Vsync mellett egy néha hirtelen egérmozgatáskor (ha pl. épp folyamatosan jobbra húzom az egeret, de valamiért meggondolom magam, és hirtelen elrántom balra) "zakatolva megugrik" a kép (nem tudom jobban körbeírni, de mint ha egy pillanatra lefagyna, és aztán kicsit dadogva, kapna észbe), amit régen (mondjuk 5-10 éve) nem rémlik, hogy bármikor tapasztaltam volna. Ebből érzem úgy, hogy túl "lomha" lett minden, hosszú queue-ra és ezzel magas késésre kezdtek optimalizálni mindent (játékmotorok, VGA driver-ek, stb), hogy kisajtoljanak még pár fps-t az ÁTLAG mutatókban (nem törődve azzal, hogy a játékos ebből mit tapasztal, akár rosszabb lesz neki összességében) és közben máshol próbálják csökkenteni az elszabaduló lag-ot (pl. végletekig kisajtolni mindent a monitorokból, hogy valahol csökkenjen a lag, ha már máshol duzzad, ami win-win, mert el lehet adni a "gamer" monitort, és mutogatni az erekciót, hogy milyen jól "optimalizált" a játékmotor/driver ÁTLAG teljesítményre).
    Persze lehet, hogy csak én öregszem és leszek egyre háklisabb mindenre. :DDD

    Általánosságban szerintem ez most ugyan az a klasszikus buffer-bloat probléma, mint amit jól nyomon lehet követni iskolapéldaként a Linux network és később Block layer fejlesztésében. Először az egekbe lövik a bufferelést, aztán kitalálnak helyette valami okosabbat, mikor zavaróvá válik az egyre több latency spike, amit nem mindenki tud tolerálni. Lehetne jobban, csak nem akarja senki, míg nem sírnak elég sokan és hangosan, de közben mindenhol máshol próbálják ellensúlyozni a baki hatásait (és talán a megoldás alapja is ott van a "történelemben", akár épp a Linux network fejlesztői naplók).

    Azt hiszem van is valami kihasználatlan RAM a G-sync modulon, amiről már elmélkedett valaki, hogy mire lehetne jó (de pontosan nem rémlik, rég olvastam), és talán köze lenne ehhez. De nyilván jobb lenne valami szabványos megoldás (nekem személy szerint olyan, ami HDMI standard is lesz TV-k miatt).

    Ironikus, hogy részben pont emiatt akartam idén újra Geforce-ot, mert azt hittem itt jobb a helyzet ilyesmikben (az átlag fps alatt lapuló apróságokban), erre most az AMD tolja a driver fejlesztéseket ebbe az irányba. :))

    [ Szerkesztve ]

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

  • Abu85

    HÁZIGAZDA

    válasz janos666 #151 üzenetére

    De azt nem kell minimálisra csökkenteni. Nem az a baj, hogy sok feldolgozásra váró adat van a parancslistában, hanem az, hogy túl rendszertelenül keletkeznek. Erre pedig az RTSS limit vagy az FRTC-féle megoldások nem jók. A Chill scene pacingje koncentrál direkten erre a problémára, viszont jelzi, hogy mennyire nehéz ezt normálisan kezelni, hogy minden egyes játékhoz teljesen egyedi profilozás kell. Eredetileg a HiAlgo nevű startup találta ki ezt az elgondolást, de gyorsan rájöttek, hogy képtelenség úgy megcsinálni, hogy nem ismerik a grafikus meghajtó forráskódját. Ezután arra törekedtek, hogy valamelyik cég felfigyeljen rájuk. Az AMD felvásárolta őket és tulajdonképpen ebből lett a Radeon Chill.
    Külső programmal scene pacingelni gyakorlatilag képtelenség. Annyira időigényes visszafejteni a meghajtók forráskódját, hogy a gyakorlati támogatást nem lehet megoldani. Ha meglehetne, akkor a HiAlgo nem tett volna fel mindent a cég eladására.

    Igen a Frostbite maga kezeli ezt az értéket, és a driverek ezt nem bírálják felül. Tulajdonképpen meg van előre beszélve, hogy melyik hardver milyen paramétert kap és arra írják a gyártók a profilokat.
    A probléma nem a CPU, hanem a meghajtó optimalizálása. Az AMD rengeteget költ arra, hogy alacsony késleltetésű legyen a működés, míg az NVIDIA a késleltetéssel annyira nem törődik. Igazából a GeForce-ból is ki lehetne hozni jobb teljesítményt minimális méretű parancslistával, csak az egész meghajtó nem erre készült. Ahhoz, hogy ez jó legyen egy rakás dolgot újra kellene benne írni, ahogy az AMD tette ezt 2015-ben. Nekik sem a mikulás hozta el ezeket. :) Szóval ez nagyrészt annak a kérdése, hogy az optimalizálás fókusza mi a meghajtó oldalán... Csak csőlátásban a magas fps, vagy valami egyensúly az alacsony késleltetés és a magas fps között.

    Sok minden van abban a G-Sync FPGA-ban, ami kihasználatlan. De itt is az a probléma, hogy érdemes-e rá pénzt költeni. Maga az ASIC sem készült el, mert nem látják értelmét a további fejlesztési zseton beleömlesztésének. Nincs annyi megrendelés, hogy reálisan szükség legyen rá. Eleve nincs hátránya, ha nem fejlesztik igazán. Mit tudsz tenni? Veszel egy FreeSync kijelzőt a GeForce-hoz? Nyilván nem. :DDD

    [ Szerkesztve ]

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

  • janos666

    nagyúr

    LOGOUT blog

    válasz Abu85 #152 üzenetére

    Szerintem ha több képkockányi a hossza (főleg ha csak <=60fps-re nézzük a képkockaidőt, nem >=120fps-re és feltesszük nem minden motor olyan épeszű, mint a Frostbite és megy akár 3 fölé is), és üzemszerűen tele van csordítva (legalább is ahogy Vsync mellett állítólag tele van), akkor könnyen lehet probléma.
    Arra gyanakszom, hogy ettől van a hirtelen irányváltáskor a stabilan magas fps mellett is némi akadás/dadogás, hogy a RAQ-ban sorakozik pár képkocka, ami még nem ezt követi (és így késve reagál, ráadásképp kevéssé "simán", mint amit előtte megszoktunk a látványtól).

    :N Azért ne ess át a ló másik oldalára, az nVidia is foglalkozott ezzel. Sőt, szerintem ők kezdték ezt az FCAT-el és hasonlókkal (+ ősidők óta van RAQ beállítás a driver-ben [ha nem is mindig bírálja felül ténylegesen a játékmotort] és előbb kezdték a custom Vsync-et is, de még a FreeSync is csak a G-Sync után jött...).
    Az lehet, hogy az nV utána megállt egy nekik kényelmes ponton, miközben az AMD mára nem csak felzárkózott, hanem most épp akár messzebb is ért, de történelmileg nem ők ebben a nagyobb úttörők. :N

    -- Egy kis extra kérdés --
    Most Win10-en DX11-el (hagyományos Win32, nem "modern" progik) van lag különbség exclusive fullscreen + Vsync és borderless windowed + Vsync (mármint a játékmenüben is bekapcsolva, mert tudom, hogy a WDM ilyenkor mindig Vsync-el, és ha kikapcsolom a játékban, akkor lényegében FastSync folytonosságot kapok [ami már nem jó], de vélhetően teljes Vsync laggal [ami így rossz üzlet])? :F

    A FreeSync önmagában ma az én szememben nem sokat ér a G-Sync mellett.
    Ha meg tudnék barátkozni egy <42" LCD-vel (de túlzottan hozzászoktam az ~50" TV mérethez, és mindig rühelltem az LCD-k minden nyavalyáját), akkor biztos G-Sync monitort vennék, mert tudtommal FreeSync esetén semmi garancia nincs az alacsony lagra, míg úgy látom, hogy a G-Sync "matrica" gyakorlatilag beleszól ebbe is. Egyrészt ugye a külön modullal (ami garantáltan egyforma lesz minden G-Sync monitorban, míg FreeSync-nél tetszőlegesen változó, csak a gyártón múlik miből, milyet, hogy...), illetve úgy látom, hogy ha nem is kötelezi őket erre az nV, de mégis szinte minden mai új G-Sync monitor real-time scan-out megoldású (persze a csak FreeSync-es is lehet ilyen, de ott nem érzem erre a "nyomást", és mivel tágabb az ársávjuk is, így az olcsóban gondolom bátrabban spórolnak, ha pedig drága modellek közt nézelődök, akkor már miért ne fizessem meg a garantált megoldást nyomozgatás vagy lottózás helyett...?).

    Kíváncsi leszek, hogy jövőre mely kijelzők és VGA-k jönnek már HDMI 2.1-el, és azokon belül melyek támogatják majd a "Game Mode VRR"-t. (Érdekes lenne, ha esetleg real-time scan-out megoldást is kapna egy OLED a VRR mellé alacsony lag-al, de "álmodik a nyomor", ha az LG-től kell várni hasonlót, már most is túlteljesítik magukat.) Nyilván az nVidia döntése lesz érdekesebb.

    [ Szerkesztve ]

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

  • NandoXXL

    senior tag

    válasz Abu85 #115 üzenetére

    Csinálj inkább egy Ryzen 3 tesztet. Hiányzik már egy jó Abu teszt, az új padawant pedig tanítsd be, nincs mentora ;). Nyugodtan írd le 2-3xx elavult, nekem sincs már szerencsére, minek rá fejleszteni :DDD

    [ Szerkesztve ]

  • haxiboy

    veterán

    Sok újítás egyben kib@szás...3rd Party OC programoknak búcsút mondhatunk, de vannak olyan programok amik megszűntek működni normálisan (szoftverből vezérelt ház ventillátor szabályzás a gpuk hőmérsékletének függvényében) mert nem tudják kiolvasni a GPU alapvető adatait sem... :R ty amd ty :R keserítsd meg az életünket mégjobban....

    Premium Mining Rigek és Gamer/Workstation gépek: tőlem, nektek :)

  • CJ4567

    veterán

    válasz haxiboy #155 üzenetére

    Nálam fagyás volt random, működésképtelen játék... Lehet csak elrontottam valamit, pedig DDU-val töröltem előtte a drivert.

    MSI AB-ben a monitorozás működött nálam, csak épp állítani nem lehetett semmit a kártyán.

    [ Szerkesztve ]

    No Sana No Life

  • haxiboy

    veterán

    válasz CJ4567 #156 üzenetére

    Én vissza is álltam minden gépen 17.4.4-re :K

    Premium Mining Rigek és Gamer/Workstation gépek: tőlem, nektek :)

  • NandoXXL

    senior tag

    válasz CJ4567 #156 üzenetére

    390-el hallottam random fagyást most. A 290-emel az első Crimson drivereknél tapasztaltam ilyet, a régi driver oldotta meg a problémát, és x hónap mire jött normális driver. Keressetek polarist a bányákban, azzal nincs gond, vagy ott a zöld legelő :D

  • BReal

    addikt

    válasz kolopele #10 üzenetére

    A Crimsonnal az AMD javított a driverek általános állapotán, a Catalyst vége óta pedig ugyanolyan gyakran ad ki driver frissítéseket, mint az NV. Mindeközben kb. 1,5 de lehet már 2 éve az NV driverek minősége (csak az NV tulajok beszámolóira hivatkozva) folyamatosan esik. Volt már hotfix hotfixe is kiadva, legutóbb ugye egy AAA játék (WD2) konkrétan kifagyott a driverrel. Ami előnyt ilyen téren kiépítettek maguknak, azt 1-2 év alatt lerombolják.

    [ Szerkesztve ]

  • janos666

    nagyúr

    LOGOUT blog

    válasz BReal #160 üzenetére

    "egy AAA játék (WD2)"

    Mondjuk én már majdnem azóta rosszul vagyok, ha ezt az "AAA játék" dolgot olvasom, hogy divattá vált maga a jelző ebben az ipar/sajtóban. Az jut róla eszembe, hogy béta állapotban kiadott bughalmaz, abszolút tömegigényre készült (butított) tartalommal, többnyire egy sorozat részeként, ami nem viszi előbbre a story-t (ha singleplayer), vagy újítja meg az élményt (ha multi, vagy lényegében story nélküli játék, pl. "ügyességi"), feleslegesen nagy pénzből, amit így az én megítélésem szerint kár volt elkölteniük (persze tisztelet a kivételnek), viszont most vissza kell húzni (és akkor ugye drága DLC-k, eszement számú mikrotranzakciók, stb).

    [ Szerkesztve ]

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

  • BReal

    addikt

    válasz janos666 #162 üzenetére

    Ez sokszor igaz is. :) Bár amennyire emlékszem, a WD2 azért elég jó állapotban lett kiadva.

  • ribizly

    veterán

    válasz CJ4567 #156 üzenetére

    Csak egy naiv kérdés (nvidia-nál így használom évek óta):
    Az nem működik, hogy nem törlitek az előző driver-t, hanem csak upgrade és csá? :U
    Mármint azt értem, hogy sokszor gond van a driver-ekkel, de az ilyen remover progik ki tudja leszedik e amit tényleg le kell, hogy clean install történjen valóban. Az upgrade véleményem szerint még mindig jobb megoldás elsőre, mert általában a teljesítményt ma már nem kéne, hogy befolyásolja ez a clean install vs upgrade. ;)

    |•| https://hardverapro.hu/tag/ribizly |•|

  • CJ4567

    veterán

    válasz ribizly #164 üzenetére

    17.5.2-től 17.7.1-ig frissítgettem csak, ezért próbáltam meg egy tiszta telepítést, és ez nagyobb frissítésnek tűnt, ezért akartam DDU-val uninstallálni előtte a drivert, lehet kár volt. Megnézem hogy frissítésre mit reagál.

    No Sana No Life

  • PuMbA

    titán

    válasz MasterMark #166 üzenetére

    Én körülbelül 8 AMD drivert telepítettem egymásra és semmiféle buggal nem találkoztam. Most éppen Intelem van, itt is így csinálom, ha kijön egy új verzió, de hamarosan megint AMD-m lesz :) Amennyiben a programozók valami nagy dolgot nem rontanak el, simán működnie kell a rátelepítésnek, mert én minimum 5 éve így csinálom és eddig szerencsére semmi gondom nem lett belőle.

    [ Szerkesztve ]

  • bozont

    veterán

    válasz ribizly #164 üzenetére

    Én sosem ajánlom senkinek a DDU-t vagy hasonló tisztító progikat. Max ha nem sikerül megoldani a problémát, akkor win újratelepítés előtt még egy próbát megér. De csak egy driver frissítésnél érdemes mellőzni. Elméletileg a rátelepítésnek nem kellene problémát okoznia, hiszen a windows külön kezeli a driver verziókat, de ugye ilyenkor nem csak meghajtók települnek. Szerintem ebben az esetben a vezérlőpult régi és új elemi akadhatnak össze, de nem tudom pontosan ez hogy frissül ilyenkor.

    Ami nekem hosszú évek óta bevált: a régi driver törlése előtt alaphelyzetbe állítom, aztán uninstall és egy gép újraindítás után mehet a frissebb meghajtó. A végére még egy újraindítás a biztonság kedvéért (de ezt talán kéri is a telepítés végén).

  • janos666

    nagyúr

    LOGOUT blog

    válasz bozont #168 üzenetére

    Szerintem inkább a Windows újratelepítés az, amit durván a 7-es óta teljesen feleslegesnek tartok. Hacsak nem verte rommá valami totális katasztrófa (pl. hardware hiba vagy instabil OC, esetleg vírus), akkor jó eséllyel megold mindent egy offline chkdsk + offline DISM restorehealth, és néha a beépített startup repair (kis bakiknál még online is jól működik a DISM, csak akkor kell offline, ha fel sem tud már állni a saját lábán).

    Persze a DDU is túl van misztifikálva. Attól, hogy néha maradhat vissza olyan config file, ami néha bezavarhat az új verzióval, még nem jelenti azt, hogy mindig csodát tenne.

    [ Szerkesztve ]

    TV/monitor kalibrálást vállalok. ||| "All right , Thom. But understand this: I do care for you. I care for all the lost souls than end up up here."

  • Aljasvip

    senior tag

    Most próbálgattam kicsit World of Tanks-ban az új funkciókat, számomra eléggé felamás a végeredmény.
    - Az FPS korlátozás üdvözölendő, tetszik az ötlet, szép folyamatos 60 FPS-en a kép (az eddigi 120-as beállításhoz viszonyítva).
    - A Chill teljesen szétcseszi a játékélményt nálam. Lövések után (klikkelés) folyamatos a kép pár másodpercig, de előtte és utána is mintha húzná a képet a játék. Ezt így azért annyira nem érzem forradalminak. ~20 perces tapasztalatom van csak, így közel sem megalapozott, és lehet másnál megy rendesen, de nálam ezt produkálja, ha aktiválom...
    - Enchanced Sync: RX580-al FullHD játékban nem tapasztaltam semmi olyan problémát eddig, amiért szükség lenne erre.

    Ez utóbbi esetében nem tudom mennyire releváns a Frame Rate Target Control mellett/helyett, mert egy elég izmos kártyánál, ha csak beállítom 60-ra az értéket, akkor is ugyanúgy 60 FPS-t tart majd. Az Enchanced Sync-hez való "válogatáshoz" max-on járatni a hardvert szerintem erősen felesleges - legalábbis az én kicsiny 60Hz-es monitoros esetemben, így "környezettudatosságból" marad a 60FPS-es limit, minden egyéb cicoma felesleges számomra.

  • awexco

    őstag

    válasz kwzatz #30 üzenetére

    Nekem is valamiért nagyon gyengusz a Wolfenstein: New Order.
    60fpsnél mindenféle v-sync nélkül besatuzik.

    I5-6600K + rx5700xt + LG 24GM77

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