Már évek óta minden beállításra van egy globális és egy játékonkénti mező is a Catalyst-ben.

Ezt a sokcsillió FPS-t miféle kijelző adja az arcodba?

A vélemény olyan, mint a segglyuk. Mindenkinek van, de mindekinek a másiké büdös.

Üdv mindenkinek! Gondoltam én is hozzászólok mert elég érdekes a dolog számomra.
Egyrészről nem értem miért kell mikor legtöbb programban benne van hogy le szabályozza az fps értékeket. amit valaki vagy be kapcsol vagy nem. Innentől ezt igazán bízhatnák a felhasználókra.
Viszont amit már fentebb is írtak így jóval ócskább alkatrészekből meg tudnak oldani dolgokat amik közel bírnák addig mint a mostani jobb alkatrészek.Azt viszont nem értem miért éri meg nekik meg írni az új motort +firmware-ket minden új kártyához + évente hozzáírni dolgokat és fejleszteni a meglévőt. Ebben nem látok logikát ez szerintem nem egy okos húzás mert pl ennek fejlesztésére elköltenek xxxxmillió dollárt plusz ha azt vesszük a gagyibb alkatrészek holott hagyhatnák a helyzetet úgy ahogy most van és nem költenének feleslegesen pénzt. Lehet az is a le cibált fps-el közelebb akarják hozni a konzolokat és az api-kat ami már nem akkora hülyeség.De kinek kell ez? Mire jó?. Ezt nem értem.

Ezt tudom. De mivel ez egy új funkció lesz és még nem látta senki miképp lesz megvalósítva, így addig csak találgatunk és nyitva hagytam egy kiskaput a gondolatmenetemben. Én is azt írtam, hogy szinte 100%, hogy erre is lesz profilozás.

kenyocsaba23:
Egyrészről nem értem miért kell mikor legtöbb programban benne van hogy le szabályozza az fps értékeket. Azért mert rengetegben nincs benne. És ne csak játékokban gondolkodjatok már. Nekem például 3DS Max alatt úgy sírt a GTX 680 az előnézeti ablakban, hogy öröm volt hallgatni.

Viszont amit már fentebb is írtak így jóval ócskább alkatrészekből meg tudnak oldani dolgokat amik közel bírnák addig mint a mostani jobb alkatrészek. Hagyjuk már ezt a hülyeséget. Honnan tudná a gyártó, hogy te mire használod? Honnan tudná a gyártó, hogy te leszabályzod-e a terméket, vagy sem? Vajon mennyi felhasználó korlátozná le a kártyáját (szerintem kevés a tulajdonosok számához képest) és épp ezért mennyi embernél jelentkeznének a gyengébb komponensek miatti sűrűbb halálozások és így a gyártóknál mennyivel nőne az ebből következő RMA? Vajon ez mennyi plusz költséget jelentene a cégeknek? Hagyjuk már a bullshit generálást....

Azt viszont nem értem miért éri meg nekik meg írni az új motort +firmware-ket minden új kártyához + évente hozzáírni dolgokat és fejleszteni a meglévőt. Ebben nem látok logikát ez szerintem nem egy okos húzás mert pl ennek fejlesztésére elköltenek xxxxmillió dollárt De miért kellene ezt tenniük pont emiatt a feature miatt? Amúgy egyébként is megteszik. Ha ez egy a driverben benne lévő feature lesz, akkor nem kell hetente fejleszteni, pláne nem kell játékonként optimalizálni. Egyszerűen valószínűleg figyelni fogja az FPS értékeket és ehhez igazítja a teljesítményt. Pont. Ha jól csinálják tökéletesen mindegy lesz a kártyának, hogy Super Mario miatt kell leszabályoznia az FPS-t, vagy a 3D-s kecskepornó miatt.

holott hagyhatnák a helyzetet úgy ahogy most van és nem költenének feleslegesen pénzt. Így van minek fejleszteni. Dögöljön éhen a sok programozó és fejlesztő. Gondolom nem hiába döntöttek úgy, ahogy.

[ Szerkesztve ]

Értem amit írsz és van is benne logika ha jobban át gondolom de szerintem aki jobban el mélyül ebben a témában és zavarja ha pörög a kártya a semmiért egy sima progival pl. evga precisonx-el lehet fixálni az értéket igaz ez nem mindenkinek kényelmes. A programozók pedig sosem fognak éhen halni az AMD-nél mert van bőven munkájuk szerintem.

Csak az előttem lévő kommentre reagáltam (vagyis inkább kijavítottam), amiben G-syncet javasolnak. Ha már ezt a technológiát ajánlják, legalább a szabványos változatát írják le.

Csökken az órajel és a hozzátartozó feszültség szint is, így pedig a fogyasztás is nagy mértékben csökken.
Adaptívra kell állítani a power managmentet.

AMD-nél is van valami hasonló beállítás.

Azonban ez a megoldás nem annyira hatékony, mert a GPU kihasználtságnak is egy bizonyos szint alá kell esni, hogy vissza vegye az órajeleket és a feszültséget és az órajel csökkentés után is egy bizonyos szint alatt kell lennie a terhelésnek, hogy alacsonyan is maradjon az órajel.

Ahogy utána olvastam az Nvidia féle Battery Boost funkciónak, az jött le nekem, hogy az adott fps limithez a lehető legalacsonyabb órajelet próbálja beállítani magas GPU kihasználtság mellett és ezt elég hatékonyan teszi. Szerintem az AMD is valami hasonlót próbál létrehozni.
Igaz, hogy csak mobil fronton érhető el ez a funkció, de az AMD is erre a piacra szánja elsősorban ezt a technológiát.

[ Szerkesztve ]

Értem, köszi szépen. Néztem a CCC-ben hasonló menüpont alatt, de nincs releváns funkció.

Mivel még fejlesztés alatt áll a funkció, ezért ez nem meglepő..

Ő azt mondta, hogy van. Erre reflektáltam.

Valószínűleg keveri a 2 dolgot.
V-sync vagy külső fps korlátozás hatására ha jól tudom (radeon tulajok írták, hogy igen) a Radeonok is vissza veszik az órajeleket hogyha nincs szükség magas teljesítményre. Csak ennek a működése nem annyira agresszív, tehát egy bizonyos szint alatt kell lennie a GPU terhelésének, hogy visszavegye az órajeleket.
Az nvidia notebookokra fejlesztett Batery Boostja pedig a lehető legalacsonyabban próbálja tartani az órajeleket magas GPU terhelés mellett és csak akkor emel rajta, hogyha szükséges.
Ezt próbálja az AMD is megcsinálni, ez áll jelenleg fejlesztés alatt.

Ja jó, olyan opció tényleg nincs, hogy ne vegye vissza az órajelet, ha nincs elegendő terhelés, mert ennek csak akkor lenne értelme, ha szarul lenne implementálva a váltás, és problémákat okozna.. A Battery Boost meg majd jön. Az órajel visszavételt az Ati hozta be 1 generációval az nV előtt (X800 vs 7800 GT), ezt az nV hozta ki egy generációval az AMD előtt. Egyszer egyik, egyszer másik, ilyen ez a popszakma.

Egyébként mi értelme nem adaptívra állítani ezt az opciót, hogy a kártya, ami egyébként 240 FPS-t tolna ki az adott játékban, az idő háromnegyed részében max frekvencia és max ventilátorzaj mellett pörögjön idle-ben VSync mellett?

VSync mellett nem pörög, mint az állat. 60 fps felett (tekintve, hogy 60 Hz-es monitorról beszélünk) az adaptív VSync ugyanaz, mint a VSync. Az adaptív VSync csak annyit csinál, hogy 60 fps felett bekapcsolja a VSync-et, alatta meg kikapcsolja. Nem atomfizika

Nekem szokott olyan lenni, hogy belassitja, pedig nem kene, ugyhogy en maximum performance-on szoktam hasznalni, ugy csak a turbo nem megy terheles nelkul, de amugy nem veszi vissza.

Állítólag tényleg vannak olyan esetek, amikor az órajelváltások hibához vezetnek, olyankor érdemes áttenni maximális teljesítményre, hogy ne váltogassa az órajeleket.

Hogyha nincs bekapcsolva v-sync vagy valamilyen külső fps korlátozó, akkor teljesen mindegy hogy adaptívra vagy maximális teljesítményre van állítva, mert ilyenkor úgyis max órajeleken jár a kártya.

Kérdés, hogy régebbi mondjuk HD4000-res vagy az alatti szériánál is működhet ez a fajta limiter? Amúgy szimplán az fps csökkentésnek nem látom sok értelmét, kivéve ha ugye a játék is gyorsul az fps szám alatt. De egy ilyen teljesítmény/fogyasztás szabályzó jól fog jönni, ha lesz ilyen.

Tehát egy monitor ha 60, vagy 75 hz-et tud akkor azt jelenti a max fps-t is? Tehát így a sok fps csak kimérhető és nem látható...

Ez nem igaz. 60-szor kerül friss kép a monitorra, de nem mindegy, hogy 60 vagy pl. 120 az fps. A magasabb fps csökkenti az input lagot. Ha két képfrissítés között 1 képet számol ki a GPU, akkor képfrissítés után egy régebbi állaptot látsz. Ha viszont mondjuk 3-at számol és a legutolsót rakja ki, akkor frissebb információt látsz. Lehet, hogy így az előző 2 kép megy a kukába, de ez már csak ilyen.

Érdekes... Akkor nem árt ha több az fps. Anno mikor nagy counter strikeos voltam. Mindig belőttük 100-ra az fps-t és gondoltuk, ha valakinek 60 van akkor mi hamarabb észrevehetjük, de ez a különbség elenyésző és monitorfüggő egyben...

Nem mennek a kukába a kiszámolt képek. Ez az egyik oka a képtörésnek.
Vegyünk egy nagyon egyszerű példát. A monitor 60 Hz-es, tehát 16,6 ms-onként frissít. A grafikus kártya pedig pontosan 120 képkockát képes kiszámolni, tehát 8,3 ms-onként egy képet. Ez azt jelenti, hogy a monitor egyetlen frissítési ciklusa alatt 2 képkocka kerül kiszámításra.
Ebben az esetben az történik, hogy a monitor az első képnek még csak a felét jelenítette meg, de már elkészült a második is és ilyenkor a monitor már a második képből folytatja a megjelenítést. Tehát ebben az esetben pont a kép felénél megjelenik egy törés, mert két félkép van megjelenítve eltérő mozgás fázisban.

Tehát a 16,6 ms-es frissítés azt jelenti, hogy a bal felső képponttól a jobb alsóig ennyi időbe telik a pixelek újraírása? Azt hittem ez CRT-knél volt így. Akkor ha jól értem, 60 Hz és 120 fps esetén a monitor felső fele az első képkocka alapján rakja ki a pixeleket, utána meg ahogy bejön a második képkocka, az alsó fele már az alapján lesz frissítve?
Akkor mondjuk 240 fps-nél a legfrissebb információ csak a kép alsó negyedében található? Ami egy fps esetén a talaj?

Végre, mostmár világossá vált számomra is, hogy mi a különbség, köszi szépen !

Nem teljesen érted jól. 240 fps azt jelenti, hogy 4 darab negyed kép lesz egy frissítési ciklusban, 3 törés lesz a monitoron.
Tehát az első kép az első negyedben, a második a másodikban, a harmadik a harmadikban, a negyedik pedig a negyedik negyedben lesz megjelenítve. Az ötödik kép kirajzolásának kezdetetekor már frissít a monitor is és kezdődik elölről a megjelenítés. És így kerül a 237. képkocka újra az első negyedbe és így tovább.

[ Szerkesztve ]

Egy kicsit módosítom a második mondatot, mert félreérthető.

Tehát az első kép első negyede az első negyedben, a második kép második negyede a második negyedben, a harmadik kép harmadik negyede a harmadik negyedben és a negyedik kép utolsó negyede pedig a negyedik negyedben lesz megjelenítve.

Egen. Nekem nagyon zavaró az, ha nincs bekapcsolva vsync/fix 60 fps. nem értem más hogyan tud nélküle játszani.

De amugy lehetne triple bufferinget is hasznalni, es akkor nem kene tearingelni, megis lehetne kicsi az input lag.

Az v-sync mellett használható és így máris korlátozva van a sebesség. Nekem elegendő a 60 fps, de sokaknak nem és inkább bevállalják a képtörést.

A triple bufferinghez nem kell vsync. Hacsak nem a szinkronizált buffer cserét nem hívod vsync-nek, de az semmilyen FPS-t nem korlátoz, simán megy az 55 FPS a 60 Hz-es monitorral (és nem esik le 30-ra).

A tripla buffehez nagyon is kell v-sync és a programnak is OGL-nek kell lenni.
Természetesen dupla buffer mellet is lehet az fps szám bárhol 30 és 60 között.
Elsősorban azt kell megérteni, hogy az fps számláló nem a pillanatnyi sebességet mutatja, hanem az elmúlt 1 másodpercben kiszámolt képkockák számát.
Ami számít a végső képkocka sebességnél dupla bufferes v-sync esetén, hogy mennyi időbe kerül egy képkocka kiszámítása.

Mondjuk hogyha a GPU minden egyes képkockát 16,7 - 33,3 ms között számol ki, akkor az fps mutató 30-at fog jelezni. Azonban hogyha az esetek nagyon nagy többségében 16,6 ms alatt kiszámolja és csak néhány képkocka kiszámolásához kell több idő, akkor simán mutathat 55-öt is a mutató.

De, pontosan ezt mondtam én is. Így már érthető, csak nem tudtam, hogy ez a frissítés hogy működik.

(#85) FLATRONW
Igen, jól mondod, és ugye ez a triple buffering + vsync lényege, hogy ha minden esetben 16,6 ms és 33,3 ms között van a képkockák kiszámolásának ideje az adott másodpercben, az fps akkor sem esik le 30-a, hanem nyugodtan lehet 55 is.

Eléggé érdekesség ez számomra. Sosem tudtam, hogy a Vsync-nek ekkora jelentősége van. Sosem kapcsoltam be, mert gondoltam a nagyobb fps szám sosem jelenthet hátrányt. Azért van az ha mondjuk 200 fps-el fut egy alkalmazás, hogy aprócska vonalak jelennek meg a monitoron? Nem GPU hibára gondolok itt..

Akkor jön ki nagyon durván a dolog, amikor mondjuk földrengés vagy hasonló rázkódás van a játékban és emiatt nagy sebességgel remeg a kép. Akkor az ilyen magas fps-eknél teljesen szétszakad. Pl. a Dead Space 1 elején, ahol az űrhajó remgett és volt 200 fps-em, ott az űrhajó ablakén lévő merevítőoszlopok vízszintes osztások mentén teljesen széttöredeztek. Vagy a Painkillerben, amiben ez a konfig hozott vagy 400 fps-t, egy oszlopcsarnokban kapott el egy földrengésszerű valami és az oszlopok teljesen széttöredeztek ugyaní]y a vízszintes osztások mentén. Annyire irreális látványt nyújtott, hogy muszáj volt bekapcsolnom a VSync-et.

Plusz ha ehhez még villódzó fények és árnyékok is társulnak, akkor garantált az epilepsziás roham.

[ Szerkesztve ]

"A tripla buffehez nagyon is kell v-sync és a programnak is OGL-nek kell lenni."

Ezt gondold át még egyszer..

Ezt olvasd el, jól leírja miről van szó: [link]

Az általad linkelt oldalon is szépen leírják a lényeget.
Eleinte az őskorban csak egy buffer volt, de ez valami miatt nem volt jó (gondolom sebesség problémák voltak)
Ezért bevezették a dupla buffert, ami már remek sebességet adott, de képtörés lett az eredménye.
Ezért bevezették a v-syncet, ami megszüntette a törést, de adott esetben a képfrissítés felére csökkentette a sebességet.
És utolsó lépésben létrehozták a tripla buffert, hogy a dupla bufferes v-sync okozta sebességvesztést kiküszöböljék.

A következő oldal legalján frissítették a cikket és leírják, hogy az MS nem építette be a DX-be a tripla buffert, cserébe beletettek egy ahead prerenderd frames funkciót, ami 0-8 képkockáig buferrelheti a képkockákat. Azt, hogy pontosan mennyi ez a prerendered frames, azt a mai játékokban a készítők döntik el. Ez általában 3 képkocka. A tripla buffer kikapcsolt v-sync mellet semmilyen előnyt nem ad a duplához képest, ezért nincs is értelme használni és nem is használják.

Plusz néhány játékban a tripla buffer bekapcsolásához előbb a v-syncet kell engedélyezni. Máshol a v-sync almenüjeként szerepel a tripla buffer, v-sync off-ban szürke az opció.

De jelen pillanatban a tripla puffernek sok szerepe van, illetve úgy értem, hogy mostmár microsofték is előszeretettel használják a directx-ben. Vagy tévednék talán?

Nem tudják használni a játékfejlesztők DX alatt a tripla buffert, mert az API nem támogatja. Helyette van a render ahead funkció, aminek ugyanaz a feladata, mint a tripla bufernek csak némileg eltér a működése. A DX-es játékokban a fejlesztők tripla bufferként szoknak hivatkozni a funkcióra, tévesen.

Na végre!
Néhány játékban (pl. FarCry 4) nincs limitálva a framerate a menüben, így amikor megnyomom az Esc gombot hirtelen megszűnik a CPU limit, a videokari pedig több száz FPS-t tol ki magából és azonnal felzúgnak a ventilátorok.
Jó lenne erre megoldást találni.

Nem igazán érted, hogy mi az a CPU limit. A menüben sokkal nagyobb az esélye, hogy cpu limites lesz az fps

[ Szerkesztve ]

Szerintem elég jól értem, én csak annyit vettem észre hogy a menüben 300+ FPS-em van és a VGA pörög fel. (=a VGA 100%-os kihasználtságon van)

..legalább is nekem ennyi jött le.

[ Szerkesztve ]

Akkor elmagyarázom.
CPU limit akkor jöhet elő, amikor a GPU-nak kevés erőforrást igénylő képkockákat kell kiszámolni (pl. egy régebbi játék kis felbontáson vagy egy játék menüje). A GPU rengeteg fps-t tudna produkálni, de már a CPU nem tudja elegendő mennyiségű adattal ellátni, mert nem elég erős hozzá.
Ez a CPU limit. Hiába raknál a rendszerbe egy 2x olyan erős GPU-t, az sem tudna több fps-t generálni, mert a CPU limitálja az fps-ek számát, az a bottleneck, a szűk keresztmetszet.

Amikor játékban vagy pl. egy Far Cry 4-ben, ami rendesen terheli a GPU-t, ott nincs semmilyen CPU limit. Ott a GPU izzad rendesen és a CPU bőven el tudja látni a szükséges adatokkal ahhoz a számú fps-hez, amit a GPU ki tud préselni magából.

Ha csak ennyiben jobb mint a v-sync akkor nem valami érdekes....