eeeeegen, ez egyrészt érthető, másrészt ha jó a design, akkor még bele is férhet. csak a sok lensflare-től már a crysis 3-ban nem láttam, mi történik, ki is hajítottam

input lag kérdés: megnézném azért a derék versenyzőket vakteszten, akik kiszúrják a +7ms-ot
a frame smoothing amúgy szerintem csak alacsony fps esetén növeli az input lagot. minden 2. frame a helyén marad, és a közöttük levőket helyezgeti a GPU. ha sok frame-ed van, akkor smoothing nélkül könnyen előfordul, hogy egyes frame-eket egyáltalán nem látsz, mert annyira kevés ideig vannak a képernyőn - ez pedig azt az érzetet kelti, mintha fele annyi fps-ed lenne az engine oldalon. 60 fps esetén pedig a smoothing maximum 16.6ms-ot tesz hozzá, de ugye ez olyan esethez képest van, amikor a "smootholt" frame kb. 1 scanline erejéig látszana. tehát átlagosan jó a 8ms.

Pedro... amigo mio... ma is konzervvért iszunk! Kár lenne ezért a tehetséges gyerekért...

PS3 és X360-ra ott van az Epic UE3 motorja. Gyönyörű dolgokat lehet vele művelni. Az UE3 mehetne multiplatformra, a csak next gen-re szánt játékok pedig mehetnek UE4-el.

Az input lag az az egérgomb lenyomásától a képernyőn megjelenő tüzelésig tart. A frame számításának ideje nem változik, csak a képkocka kirakását késlelteti a smoothing. Ez nem mérhető szoftveresen. Esetlen burtálnagysebességű kamerával manuálisan mérhető lehet, hogy hány ms telt el az parancs kiadása és a látható hatása között.

(#501) gbors: Ezek hardcore játékosok a 60 vs 120 fps különbségét észreveszik 60 Hz-es kijelzőn.
Mindig növeli, mert mindig késleltetni kell minden második képkocka kirakását. A növekedés mértéke az aktuális fps-től függ. Alacsony ~30 fps mellett tényleg észrevehető lehet.
Igazából pár hét múlva ez nem lesz dilemma. Mindkét cég beépíti mindkét módot a driverbe. Tényleg nehéz eldönteni, hogy melyik a jobb. Valójában egyik sem elég jó.

(#502) daneeeeee: Ez nem ilyen egyszerű. Az Epic is ezt mondja, hogy van UE3, csak azért elfelejtik, hogy a cégek nem így működnek. Ha van egy projekt, ami elkészül az aktuális konzolokra, a nextgen gépekre, PC-re, illetve esetleg a Nintendo Wii U-ra, akkor az Unreal Engine 4 kiesett. Hiába jó a motor egyszerűen a megcélzott gépek felén működésképtelen. Nézd meg az alternatívákat. Az előbbi igényeket a Frostbite 3 és a CryEngine 3.5 megoldja. És mindkettő sokkal jobb minőségű grafikát tesz lehetővé az aktuális konzolokon, mintha az UE4 játékot átdizájnolnák UE3-ra. Sem anyagilag, sem minőségben nem éri meg. Az UE4 jelenleg csak azoknak a fejlesztőknek lehet alternatíva, akik csak PS4-re, PC-re és új Xbox-ra dolgoznak. Látható, hogy az eddig bejelentett projektekből kimaradnak a régi rendszerek. Valami csak PC-re jön.
Az UE4 egyébként egész jó, legalábbis az előrelépés tényleg nagy. Ennek viszont azért komoly hátrányai is vannak. Úgy gondold el a motor felépítését, hogy a megvilágítási fázishoz olyan rendszert használ, amit eddig soha senki. Ez az ami nem fut a régi hardvereken, vagyis, ha ezt kikapcsolják, akkor konkrétan nem lesz a pályán megvilágítás. Ergo nem kikapcsolható technika. A másik gond vele, hogy nagyon számításigényes. Ezért van compute shaderben írva. Alapvetően a VCT-hez fel kell építeni egy sparse adatstruktúrát. Ezt nem minden képkockára kell, de a jelenet változásával nyilván tartania kell a lépést a voxelizációnak Na most ezt a jelenlegi motor szoftveresen építi fel a GPU-val, de ez nem mondható annyira gyorsnak. Lehet persze hardveres implementációt is használni, és az új konzolokon nyilván az AMD PRT-jével fog működni (ez lehozható PC-re is), mivel számottevően gyorsabb. Itt mákolt az Epic, hogy GCN-t kap az új Box és PS.

[ Szerkesztve ]

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

Az rendben van hogy nem veszi ki a módot mert van annak is értelme. Csak pl olyan game-eknél ahol arra kell a cf hogy játszható fps-t kapjon az ember az adott beállításnál ott sokkal jobb a frametimeot optimalizálni mert azt úgysem profin fogja játszani az ember abban a beállításban, ott arról van szó hogy minél jobban játszható legyen és akkor inkább legyen magasabb input lag mint szaggatás.

Szerintem rég rossz, ha valamelyik oldalon meg kell kötni a kompromisszumot. Én magasabb input lagra sem szavaznék.

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

Érdekes ez, hogy szerintük fontosabb az alacsony input lag.

A konzolos játékok világa látszólag pont nem erről szól jelenleg. Se teljesítményben, se kontrollerben, se a TV-k input lagjában nem tükröződik, hogy hú de érdekelné a játékipart a dolog. A PC meg ugye már ma sem a fő platform (sajnos).

Komplett hangrendszerem eladó - https://hardverapro.hu/apro/mackie_studio_monitorok_mr5mk3_mr10s_mk3_sub_asus/hsz_1-50.html

a 2. kártya mindenképpen beletesz 16.6ms-ot (60 fps esetén), úgyhogy akinek ennyire fontos az input lag, az eleve felejtse el az AFR-alapú multi-GPU-t

[ Szerkesztve ]

Pedro... amigo mio... ma is konzervvért iszunk! Kár lenne ezért a tehetséges gyerekért...

Na hát igen ez amit leírtál az igaz,de ebben ahogy írod benne van ám a monitortól az egérig minden...most ha jól értem CSAK a vga input lagjával foglalkozunk,ám igaz ami igaz hardcore cs vagy cod játékosnak nem való a multiGPU...de ez csak egy valóban vékony réteg,jellemzően ők még csak véletlenül sem vásárolnak csúcs cuccokat,és nem magas grafikai beállításokkal játszanak.

★★★★★ I got too much soul, rhythm and blues R&B ya see, all that's cool, but hip-hop and rap yeah that's where my heart's at Even back when I used to break on a box ★★★★★ "Chief Rocka"

Pont ez a lényeg. Érdemes-e azt tovább növelni? Mi az a határ, aminél még jó? Nehéz kérdések. A megkerülő válasz erre, hogy gáz az AFR mód multi GPU-hoz. Mindegy, hogy hogyan csinálod meg, valahol kompromisszum kell. Azzal nem változik a helyzet, hogy az NV és az AMD a user kezébe adja a döntést, hogy hol legyen a kompromisszum. Ez az alapprobléma szőnyeg alá söprése. Itt nem a részproblémákat kellene orvosolni, hanem amiből ez az egész gond ered. Olyan, mint a körömgomba. Gyökerestől kell kezelni.

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

Milyen alternatívák lennének az AFR mellett, a képfelosztás az nem vált be ahogy nézem.

Osszuk el a parancsokat. Nem lesz 90+%-os skálázódás, csak 70-80, de minden AFR-re jellemző kritikus problémának vége. Utóbbi szerintem sokkal többet ér.

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

yep, AFR mondjon le. csak az a borzasztó gyanúm, hogy a jelenlegi raszterizációs pipeline mellett általánosan jól skálázódó megoldás aligha van. meg ugye a közös címtér sem ártana

Pedro... amigo mio... ma is konzervvért iszunk! Kár lenne ezért a tehetséges gyerekért...

Ott a pont...amíg nincs közös címtér addig nem igazán lehet jobb megoldást kínálni az AFRnél...

(#511) Abu85
Aham,csak hát tudod ki fogja azt beépíteni amikor egy rendes portolással nem foglalkoznak konzolról...

[ Szerkesztve ]

★★★★★ I got too much soul, rhythm and blues R&B ya see, all that's cool, but hip-hop and rap yeah that's where my heart's at Even back when I used to break on a box ★★★★★ "Chief Rocka"

A mai GPU-kon is megoldható a közös címtér, mert a kártyákon ugyanaz a hardver van. Ami ezt lehetetlenné teszi, hogy az operációs rendszer nem kezeli a VRAM-ot direkten, így azt a driver mögé kell elrejteni. És ez sosem fog megváltozni, mert túl speciális a VRAM kezelése az operációs rendszer számára. A menedzsmenten szinte driverenként változtatnak valamennyit, szóval mindig el lesz rejtve a driver mögé.

A parancslistás megoldással vesztesz 10-20%-ot teljesítményben, de cserébe mindennel kompatibilis lesz, minden AFR gond megszűnik, és az interframe kommunikáció sem jelent majd problémát, ami egyre több motorban egyre nagyobb adatmennyiségre valósul meg. Szerintem egyértelműen megéri.

(#513) TTomax: Mit kell beépíteni azon, hogy a parancsokat szortírozod? Ez egy gyors folyamat a proci simán meg tudja csinálni.

[ Szerkesztve ]

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

én inkább bevállalnám hogy legyen lassabb 10-20% de cserébe problémamentesebb legyen

tehát érdemben a közös címtér felejtős. innentől kezdve a közös, érzékenyen loadbalance-olt, minimális overheaddel járó munkamegosztás is az.

a parancslistás megoldás szerintem nem ennyire egyszerű. a geometria feldolgozása és a megvilágítás során az objektumokat kell szétosztani, a post process során meg gondolom tile-okon dolgoznának a GPU-k. így is, úgy is át kell adni az egyik GPU eredményeit a másiknak és viszont egy frame során legalább egyszer. nekem ez így fájósnak tűnik.

Pedro... amigo mio... ma is konzervvért iszunk! Kár lenne ezért a tehetséges gyerekért...

FCAT: The Evolution of Frame Interval Benchmarking
Úgy néz ki NV kiad egy progit amivel minden eddiginél jobban lehet majd mérni a képkockák közti késleltetést, mikroszaggatás mértékét, meg sok minden mást is...

[ Szerkesztve ]

Már ki is adta de hétköznapi felhasználók nem tudják használni mert egy dvi elosztón keresztül kell egy másik gépnek felvennie az adott képkockákat és abból a frametimokat meghatározni.

Egy digitális videó felvevő kártya kell csak hozzá, semmi más, ha jól láttam.
Publikus letöltő linket viszont nem látok...

Meg egy olyan tárolórendszer, ami képes 600 MB/s-os tempóval írni. Azé ez nem mindegy.
Azért nincs publikus letöltő, mert a kártya, amivel működik nem érhető el kereskedelmi forgalomban. Ezt az NV adja óda, és vele együtt a szoftvert is. A tárolórendszert meg be kell szerezni.

[ Szerkesztve ]

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

Elméletben egy mezei, 60FPS-re képes, HDMI-s, hardveres tömörítéssel rendelkező kártya ugyan úgy alkalmas a tesztre és nem kell semmi más. Persze, ha az NV nem adja oda a progit, akkor a gyakorlatban nem. Ilyen komoly hardver csak akkor kell, ha képkockánként akarod összehasonlítani a tesztalanyok képminőségét is.

A mezei kártya pont azért nem alkalmas rá, mert az fix képkockaszámot rögzít, míg az a valós frame buffer tartalmat menti le. Ezért kell a gyors tárolórendszer, mert egy frame buffer mérete Full HD-ben 6 MB, és ebből kell másodpercenként annyit kiírni, amennyi a capture szint. Persze a felbontás növelésével nő a tárolókra a teher is. 600 MB/s-os ajánlott konfig nagyjából 100 fps-ig működik Full HD felbontáson. Ha többet és/vagy nagyobb felbontásút akarsz rögzíteni gyorsabb tároló kell.
Ez nem capture kártya, hogy bárhol működhet, itt minden képkockáról egyedi kép van. Még ha meg is kapnád az NV-től a kiírást biztosító kártyát, akkor sincs meg a tárolórendszered alá.
A képminőség összehasonlítása felesleges, mert két mérés mellett sem lesz ugyanolyan az eredmény még azonos hardverrel sem. A képminőségre egyszerűbb a print screen.

Otthonra a GPUView-et használjátok. Az képes elkülöníteni a folyamatokat, így abból kellő tapasztalattal minden leolvasható. Még az is, amiről a FRAPS nem ad információt, vagyis a lényeg.

[ Szerkesztve ]

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

Ez egy professzionális felvevő kártya ami tud annyi fps-el rögzíteni ahány Hz-es jelet a DVI-on kap. Teszthez teljesen jó a szokásos 60Hz mert ez szimulálja legjobban az átlagos otthoni környezetet is, amihez pedig nem kell spéci kártya.

Szóval elméletben továbbra sincs semmi akadálya FullHD-ig egy olcsó capture kártyának.

[ Szerkesztve ]

Ez jó kártya csak lassú. legalább olyan kellene, ami 60 fps-t rögzít. Azzal szimulálható lenne a legtöbb kijelző.

Már hogy a fenébe ne kellene? Eleve az, hogy 60 fps-sel rögzítsen frame buffereket eléggé spéci igény. Ez nem az olcsó capture kategória. De még ha a kártya nem is lenne gond, akkor a tárolórendszer az lesz alatta. Legalább négy gyors SSD kell RAID 0+1-ben.

[ Szerkesztve ]

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

igen, ez jó, de hogy kapcsolódik a korábbi témához?

Pedro... amigo mio... ma is konzervvért iszunk! Kár lenne ezért a tehetséges gyerekért...

Nem válasz akart lenni, bocsánat , de azért lazán kapcsolódik a multi-GPU témakörhöz.

Van már pár teszt is az új teszt módszerrel, de csak erős idegzetű CrossFire tulajoknak ajánlott :

Frame Rating Dissected: Full Details on Capture-based Graphics Performance Testing

Inside the second with Nvidia's frame capture tools

Challenging FPS: Testing SLI And CrossFire Using Video Capture

Ezt is tárgyaltuk már itt, hogy az AFR-re két lehetőség van. A frame smoothing magasabb input laggal és a smoothing nélküli megoldás az input lag minimalizálásával. Ez nem az erős idegzetűeknek nem ajánlott, hanem azoknak, akik nem értik meg, hogy az AFR soha sem működhet jól, mert a technikának vannak korlátjai és nem a CF-nek illetve az SLI-nek. Az AMD az alacsony input lagot tartja szem előtt, míg az NVIDIA a frame smoothingot. Ezek különböző előnyökkel és hátrányokkal járnak. Éppen ezért nem fogja az AMD kivenni a driverből a mostani AFR-t, hanem mellé építi a másik megoldást, és a két mód között majd lehet váltani. Ha magas input lag jó, de egyenletesebb frame megjelenítést akarsz, akkor be lesz vezetve a frame csúsztatás. Ha idegenkedsz attól, hogy a virtuális fejlövéshez esetleg az ellen feje elé kell célozni ilyenkor, akkor pedig ott az alacsony input lagra optimalizált verzió.
Tényleg ne hidd, hogy ezekről nem tudnak semmit a rendszerprogramozók. Ezek mind ismert jelenséget, csak nagyon nehéz eldönteni, hogy a usernek melyik lesz a szerethetőbb verzió, mert olyan pro-kontra érvek cserélnek helyet, amelyeknek alapvetőnek kellene lennie. Ezért panaszkodtak egy időben az SLI tulajok, hogy kikerült a driverből a pre-render frame limitálás. Nekik ez fontos, mert az SLI AFR megvalósítása miatt a normál pre-render paraméterek mellett hátrányt élveznek. A Radeon tulajok ilyenért sosem panaszkodtak, mert az AMD CF megvalósítása eleve az input lag csökkentését tartja szem előtt.

[ Szerkesztve ]

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

Az AMD az alacsony input lagot tartja szem előtt, míg az NVIDIA a frame smoothingot.
Ez így jól hangzik, de ezek a tesztek rávilágítanak, hogy a gyakorlatban nem igaz.
Gyakorlatban ez úgy néz ki, hogy míg az AMD megoldása figyelmen kívül hagyja magának a játékosnak (ember) a működését, és úgy tolja ki a képkockákat a képernyőre, ahogy éppen sikerül, maximalizálva ezzel a FRAPS által mért fps számot, addig az NV megoldásánál figyeltek arra, hogy az a lehető legjobban alkalmazkodjon az ember működéséhez. A játékosok egy nagyjából állandó input laghoz könnyedén tudnak alkalmazkodni, ahogy írtad is, az ellen elé lőnek pl., de egy folyamatosan változó input lagnál ez egyszerűen lehetetlen, mert nem tudják, hogy mennyivel kell elé lőni.

Ha idegenkedsz attól, hogy a virtuális fejlövéshez esetleg az ellen feje elé kell célozni ilyenkor, akkor pedig ott az alacsony input lagra optimalizált verzió.
Itt van pl. egy BF3-as grafikon, nyoma sincs a CF input lag előnyének, azt lehet látni, hogy míg a CF esetében folyamatosan ~0-20ms között ugrálunk, addig az SLI elég jól tartja magát ~10-12ms körül, de az átlag késleltetés kb. ugyan annyi, csak ezt az SLI sokkal kisebb kilengések mellett tudja, és ha kisebb a kilengés könnyebb hozzá alkalmazkodni -> jobb.

Aztán vannak itt még érdekes dolgok, pl. itt van a FRAPS-al mért FPS,
itt meg az az FPS szám mit a játékos ténylegesen láthat is. Mit jelent az, hogy ténylegesen láthat? Ebből le vannak vonva azok a képkockák amik egyáltalán nem jelentek meg a monitoron, vagy csak 21 sornál kisebb részét tették ki a képernyőnek, tehát gyakorlatilag nem adtak hozzá semmit a monitoron látható dolgokhoz.
CF esetén elég nagy különbség van a 2 mért érték között, míg szóló AMD GPU vagy SLI esetén meg nincs. CF tulajoknak elgondolkodtató lehet, hogy a monitoron látható képkockák tekintetében alig vannak jobb helyzetben mintha csak egy szóló kártyájuk lenne...

Az input lagot én még egyetlen tesztben sem láttam, hogy mérték volna.
A FRAPS lényegtelen, mert az úgy sem méri a grafikus pipeline-on a működést. Ergo mindegy, hogy melyik AFR megoldást választják, mert a FRAPS eredménye a program és a D3D runtime közé ékelődik be és az alapján mér.
Mielőtt folytatnánk ezt jó lenne nem keverni a frame time-ot az input laggal. A két dolog nem egyezik. Az input lag ingadozásához nem kell CF vagy SLI. Az egy kártyánál is ingadozik. CF-nél jobban érződik, míg SLI-nél sokkal nagyobb a kiingás, mert konkrétan direkt késlelteti a frame számítását. Ez a frame smoothing alapvető hátránya, és pontosan ezért nem akarja az AMD kivenni a driverből az input lagra optimalizált AFR megoldást, mert sok multis júzernek ez jobban számít, mint a smoothing. Ez nyilván nagysebességű kamera nélkül nehezen mérhető dolog. A tesztekhez készítenek egy smoothing megoldást CF-hez, de már elmondták, hogy a mostani AFR lesz az alapértelmezett akkor is, mert erről jobbak a profi játékosok visszajelzései.

A monitoron látható képkockák szempontjából mindenki olyan helyzetben van, hogy 60 Hz mellett 60 képkockát lát. Ez a kártyák számától független dolog.

[ Szerkesztve ]

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

Mielőtt folytatnánk ezt jó lenne nem keverni a frame time-ot az input laggal. A két dolog nem egyezik.
Input lag része a frame time, tehát ha magasabb a frame time, akkor magasabb lesz input lag, ha jobban ingadozik a frame time, jobban fog ingadozni az input lag is.

És ha eltolod a frame számítását a smoothinggal, akkor még nagyobb, még jobban ingadozó lagot kapsz. A frame time ettől nem változik. Ezért van az AMD ellene, mert a profi versenyzők a lag csökkentésére koncentrálnak. Ez nem hiba, hanem döntés. Szerinted az SLI-s topikokban miért tweakelik a GeForce drivert a pre-render frame szempontjából? Hát persze, nagy az input lag. A CF-hez ilyen korrekció nincs, mert az úgy van kalibrálva, hogy minimális legyen a lag.

Egyébként az AMD és az NV számtalan dolgot másképp csinál. Például a képminőség. Az NV a shimmering jelenség visszafogása érdekében csökkenti a textúraszűrés minőségét, és így megbuknak az MS tesztjein. Az AMD az MS tesztjeinek akar megfelelni, de kapták az ütéseket, hogy bezzeg az NV másképp csinálja, mert a shimmering fontosabb. Addig erőszakolták ezt a témát a tesztelők, hogy az AMD berakott egy alternatív módot a driverbe, hogy az NV-hez hasonló szűrési minőség mellett is lehessen tesztelni a Radeonokat. Ez a texture filtering quality opció performance beállítása. De az alapértelmezett quality mód az maradt az MS tesztjeinek megfelelő megoldás. Érdekes, hogy a tesztelők kikövetelték ezt a változtatást az AMD-től, de most, hogy ott van a driverben nem tesztelnek vele.
Ez is ugyanúgy fog járni, mint a textúraszűrés. Amint ott lesz a driverben az egész el lesz felejtve. A FRAPS értelmét az NV prezentációja leépítette, míg az FCAT-ra nem lesz sok médiának pénze, egyszerűen négy SSD-t RAID-ben befogni szimplán nem éri meg, amikor mindkét AFR megoldás ugyanúgy fog működni, pontosabban az AMD driverében kiválasztható lesz ugyanaz a működés.

[ Szerkesztve ]

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

Szerkesztés közben lehalt a fórum...

FRAPS nem lényegtelen mert az alapján készül a tesznek nagy része, de a linkeken nem a FRAPS a lényeg, hanem az FCAT és a teljesen új módszer a felhasználói élmény mérésére, meg az, hogy CF esetén nincs összhangban a FRAPS-al mért értékekkel.

SLI-nél sokkal nagyobb a kiingás, mert konkrétan direkt késlelteti a frame számítását
Pont hogy sokkal kisebb, mert az egész frame smoothing rendszer lényege, hogy csökkentse a kiingást.
Direkt késleltetés olyan képkockák esetén történik, amik túl korán jönnének ahhoz, hogy érdemben hozzáadjanak a látványhoz, és csak annyira lesznek késleltetve, hogy ne lógjanak ki az átlagból, viszont azok a képkockák amik vmiért késnek CF esetén, SLI-n "gyorsítva vannak" és időben érkeznek, tehát a kilengés pont, hogy sokkal kisebb, és az élmény "smooth"-abb.

A monitoron látható képkockák szempontjából mindenki olyan helyzetben van, hogy 60 Hz mellett 60 képkockát lát. Az a helyzet, hogy ha nincs bekapcsolva a vsync, akkor 60Hz-en jóval több képkockát tudsz látni mint 60, ez az egyik oka a képtörés jelenségnek is, amikor több képkockát rajzol ki a monitor, egy frissítés alatt.

Szerinted az SLI-s topikokban miért tweakelik a GeForce drivert a pre-render frame szempontjából?
A maximum pre-rendered frames-t DirectX -ben állítod, csak erre az NV ad opciót a control panelben az AMD meg nem. Szóló kártyával is érdemes állítgatni, mert CPU által előre számított képkockák max. számát állítod vele.

FCAT nem egy CF vs. SLI összehasonlításra készült cucc, hanem egy új lehetőség olyan dolgok vizsgálatára, amik eddig nem voltak lehetségesek. Mint már mondtam, nem kell hozzá semmi drága cucc, csak egy capture kártya. A drága cucc csak az NV által adott kártyához kell, ami nem tud hardveres tömörítést.

[ Szerkesztve ]

Ami nem méri az input lagot, ami szintén egy fontos elem. Mondjuk ezt semmi sem méri. De gondolom eddig ezt nem értetted meg, így ezután sem fogod. Nem töröm magam.

Persze kisebb ... Mit is csinál a smoothing? Fogja magát a rendszer és késleltetve dolgozza fel a jelenet adatait. Na már ha mesterségesen késleltet, akkor hogy a fenébe lehet kisebb az input lag, amikor a késleltetés mértéke biztos pozitív valós szám ms-ban mérve. Ha kisebb lenne, akkor negatív valós szám lenne, de mivel a mai hardverek még nem képesek időutazásra, így be kell érni a fizika törvényei adta keretekkel.
Nincs olyan, hogy a képkocka túl korán jön. Az jön. Annak a számítás késleltethető, de ezzel nő az input lag.

A képtörés az a kijelzett kép része. A monitor akkor sem fog 60-nál többet megjeleníteni.

Ha nem állítod, akkor is állítja a driver, mert van minden programra profilozott beállítás. De ennek az opciónak a célja, hogy SLI mellett csökkentse le az input lagot a sebesség csökkentése oltárán is. Ezért ad rá beállítást az NV. Az AMD nem ad, mert nekik erre nincs szükség. Annál kisebb input lagod sosem lesz, mint ahogy működik a CF. Állíthatod egy kártyával is, de sok értelme nincs, mivel a profilban definiált beállítások egy GPU-hoz vannak szabva.

Légyszi hagyjuk már az általad elképzeld dolgokat és szorítkozzunk a tényekre. Kurvára kell a 4 SSD, mert 60 képkockát kell másodpercenként kiírni 24 bites színmélységben. Ezt veszi be az NV-nek a programja, és ebből alakít egy tömörített állományt, amit például virtualdubbal lehet használni. De basszus milyen tömörítésről beszélsz, amikor képkockákat ment a rendszer érted ... nem videót. Képkockát! 24 bites 8/8/8-as színmélységű tömörítetlen frame buffer tartalmat. A videót baszhatom, mert nem tudja az FCAT alkalmazás beszínezni a képtöréseket.

[ Szerkesztve ]

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

Igen, nem méri az input lagot, de mivel az input lag része a frame time, ezért ha a frame time nagyobb, nagyobb lesz az input lag is. Tehát nem tudjuk, hogy mennyi összesen az input lag, de azt tudjuk, hogy CrossFire esetén átlagban nem kisebb, viszont többet ingadozik mint SLI vagy szóló kártya esetén.

A késleltetés nem minden képkockára vonatkozik, csak azok lesznek késleltetve, amik az átlagnál hamarabb kerülnének képernyőre vagy meg sem jelennének monitoron, túl korán a többihez képest.
Ha megnézted volna a grafikont, akkor láttad volna, hogy azokat a képkockákat késlelteti amiket a CF rendszer ~0ms-es frame time-al kiküld és lehet meg sem jelenik a monitoron, ebből SLI-n lesz 10ms késleltetve.
Viszont azok a képkockák amik CF esetén ~20ms-es frame time-al számolódnak, SLI esetén ugyan úgy ~10-12ms után érkeznek gyorsabban mint CF esetén. Tehát a CF rendszer bizonyos esetekben kisebb, bizonyos esetekben nagyobb frame tima-al dolozik mint az SLI, de az átlag kb. ugyan annyi, tehát a kilengés nagyobb.

A képtörés az a kijelzett kép része. A monitor akkor sem fog 60-nál többet megjeleníteni.
Mint mondtam, ha a vsync nem hangolja össze a monitort és a VGA-t, akkor több képkocka is szerepelhet egyszerre egy képen, persze tört részleteiben.

Sorry, de a maximum pre-rendered framesnek semmi köze az SLI-hez, DirecX cucc, SLI-nél azért hangsúlyosabb, mert könnyebben fordulhat elő CPU limit, és ezzel az opcióval ez csökkenthető, az input lag beáldozásával. A maximum pre-rendered framest a játékok maguk szokták állítgatni, de ezt NV-nél felül lehet bírálni, vagy AMD esetén a játékon belül, ha van rá lehetőség.

De basszus milyen tömörítésről beszélsz, amikor képkockákat ment a rendszer érted ... nem videót.
Nem tudom, hogy feltűnt-e, de sima DVI csatin csatlakozik a capture kártya a VGA-hoz, ami nem egy USB, hogy dolgokat töltsön le rajta az ember, hanem videó kimenet. Videót meg fel lehet venni tömörítetlenül, meg tömörítve is. A videót baszhatom, mert nem tudja az FCAT alkalmazás beszínezni a képtöréseket. Pedig pont ezt csinálja, ráadásul megeszik szinte minden formátumot, csak legyen fent hozzá codec.

OMG. Vegyük át újra. AFR input lagra optimalizálva. Minden azonnal lesz számolva, mert ahogy jön, úgy mehet a render pipeline-ra. Magát a frame-time-ot ez nem befolyásolja, csak hamar kezdi el minden második frame számítását, így hamarabb lesz eredménye. A smoothing megoldás késlelteti minden második frame kiszámolását, így ezzel növeli az input lagot. A frame-time itt sem változik, de a késleltetés miatt a frame-ek egymás utáni megjelenítése egységesebb. Ennél érthetőbben én sem vagyok képes leírni.

Jaj értem már miért nem érted. Jó, akkor nem én magyarázok rosszul.
Tehát ez nem méri bele a késleltetést, mert csak a kimenetet látod, de az a kimenet bőven késhet. Itt arról a lagról van szó, amit a beviteli eszközön kiadott parancstól a megjelenítésig terjed. De a frame megjelenítésének idejéből honnan tudod, hogy az a frame, amihez a beviteli eszköz parancsa tartozott mikor jelent meg? Hát sehonnan. Ha nem lősz a számítás, akkor is folyamatosan ugyanúgy megtörténik.

És azokból a tört képkockákból lesz 60 darab megjelenített 60 Hz-es kijelző esetén. Ha gyorsabb a kártyás, akkor több törés lesz bennük, ha lassabb, akkor kevesebb.

Maradjuk annyiban, hogy a játékok erre mindig kínálnak beállítást, de profilban mindig felülbírálják azokat a gyártók. Az input lag pedig csak akkor nő, ha pozitív irányba növeled a pre-render számot. Az alapbeállítást csökkentve csökken. Ezért szeretik ezt az SLI tulajok.

Nem tudom feltűnt-e, de ez a capture kártya azt csinálja, hogy a frame buffer tartalmát bemásolja a saját memóriájába és abból küldi ki a képet a monitorba, illetve a tárolóba elmenti. Ebből lesz sokezer tömörítetlen 24 bites képfájl, amiből az FCAT program készít egy olyan állományt, aminél a képtörésekhez színezés lesz rendelve, és ebből lehet különböző táblázatokat lekérni, amiből grafikont lehet kreálni. Egy dolog, ami kettőnk között a különbség. Én erről a rendszerről kaptam leírást. Te nem. Enged már meg, hogy az NVIDIA press leírásának tudatában kijelenthessek olyan dolgokat, hogy itt bizony semmilyen tömörített videofelvétel nincs, és olyanokat, hogy az NV 600 MB/s-os write speedet ajánl az adattárolónak.

Részemről ezt a témát lezártam, mert te csak a magadét mondod, nekem pedig sem időm, sem kedvem ezeket elmagyarázni. Főleg úgy, hogy nem is figyelsz oda arra, amiket írok.

[ Szerkesztve ]

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

Elég egyértelműen ott vannak az adatok a grafikonon, és elég egyértelműen látszik, hogy melyik egységesebb, lehet magyarázni, hogy a CF elméletben jobb, de itt a bizonyíték, hogy a gyakorlatban sokkal rosszabb, sőt alig jobb mint egy szóló kártya. Frame Variance külön kiemelve, hogy jobban látszódjon.

Pontosan azt méri amit te a monitoron látsz, a játék motorjától kezdve egészen a monitorra kiküldött képig.
Input lag pedig az az idő (egyszerűsítve), amíg a billentyűzeten lenyomott gomb eljut a monitorig.
Csak a VGA-ban és VGA driverben eltérő gépen a gomb lenyomása amíg eljut a játék motorjáig ugyan annyi ideig fog tartani NV és AMD VGA esetén is, az utána lévő időt, amíg a driveren és a VGA-n keresztül kiér a monitorra pedig a FCAT méri, és meg lehet tekinteni.

60Hz esetén lesz 60 képkockád, amin szerepelhet, jóval több tört (részleges) képkocka is.
Mint pl. itt, 2 képkocka szerepel egy képen.

Biztos vagyok benne, hogy nem kínál minden játék a maximum pre-rendered frames-re beállítási lehetőséget, de igazából mivel semmi köze a SLI, CF kérdéshez, lényegtelen is.

Már sokadjára írom le, hogy nem másol semmit sehova, egy professzionális videó felvevő kártyáról van szó, ami DVI-on felveszi a monitornak kiküldött videó jelet, amit előtte, egy DVI splitterrel szétosztottak, semmi több.
The video output from the gaming system being tested connects to this Gefen dual-link DVI splitter, which feeds outputs to both the monitor and the DVI capture card.

3-4 tesztben le van írva ugyan úgy a dolog, nyugodtan idézz vmelyikből, ha vmit félre értelmeztem, mert nem valószínű, hogy az összes helyen félreértelmezték az NV leírását, tehát vagy én értelmezem rosszul a tesztekben leírtakat, vagy te értetted félre a leírást amit az NV-től kaptál.

[ Szerkesztve ]

És hol van a grafikonon az, hogy az input lag mekkora, vagyis az, hogy az egéren leadott tüzelés mikor jelenik meg a kijelzőn?

Minden játékban be van állítva egy pre-render frame paraméter. Van olyan program, ami CF-hez és SLI-hez szándékosan más paramétert állít be.

[link] - 600 MB/s write kell. Ő is félreértette?

[ Szerkesztve ]

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

És hol van a grafikonon az, hogy az input lag mekkora, vagyis az, hogy az egéren leadott tüzelés mikor jelenik meg a képen?
Magamat tudom idézni:
Csak a VGA-ban és VGA driverben eltérő gépen a gomb lenyomása amíg eljut a játék motorjáig ugyan annyi ideig fog tartani NV és AMD VGA esetén is, az utána lévő időt, amíg a driveren és a VGA-n keresztül kiér a monitorra pedig a FCAT méri, és meg lehet tekinteni.
Mondok egy példát: Az egérlenyomást mire megkapja a játék motorja mondjuk 20ms (ezt nem tudjuk mérni, de nem tudom miért változna a VGA függvényében) onnantól kezdve, amíg a VGA kiküldi a monitorra, hozzájön +10ms (ezt méri az FCAT és ez szerepel a grafikonon) és akkor összesen lesz 30ms + még a monitor mire meg is jeleníti összesen mondjuk 50ms. SLI esetén ez 50ms körül lesz folyamatosan, CF esetén pedig 40 és 60ms között fog ingadozni.

2560x1440-es felbontásban 60FPS-el tömörítetlenül videót felvenni igényel 600MB/s-et ez így van.
NV ezt a kártyát küldte nekik, mert ilyet használnak az NV-nál is a belső tesztekhez, nekik gondolom nem tétel pár SSD, de ez nem jelenti azt, hogy ilyen kártya kell a videó felvételhez.

Ne idézd magad, hanem mutasd meg azon a grafikonon.

És gondolod az NV csak azért küldi ezt a kártyát, hogy az SSD-kre fellendítse a keresletet? Vagy esetleg lehet benne olyan dolog is, hogy ezzel a hardverrel működik a csomagjuk? Gondolod ha megoldható lenne hagyományos capture kártyával, akkor tényleg olyan hardverhez kötnék a rendszert, ami brutál SSD tárolót követel?

[ Szerkesztve ]

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

valószínűleg az az oka a tömörítetlen video tárolásának, hogy ha bármilyen veszteséges tömörítéssel mentenék a képeket, akkor az egyes képkockákon a színes szalag a bal oldalon nem egyenszínű lenne (esetleg az RGB összetétel is eltérne), és ez megzavarná az elemző szoftvert. valamelyik tesztoldal belefutott ilyesmibe némi artifacting kapcsán.

Pedro... amigo mio... ma is konzervvért iszunk! Kár lenne ezért a tehetséges gyerekért...

Grafikon bal oldalán a függőleges tengelyen láthatod a csak a VGA által generált input lag mértékét.
VGA tesztben nem értem miért kellene az input lag többi részével is foglalkozni.

A capture kártyáról meg minden infó elérhető itt. Eléggé úgy tűnik, hogy az NV a saját belső használatra szánt szoftverét és kártyáját adta oda a tesztelőknek, és mivel elég gyorsan reagáltak az igényre, SZVSZ nem lett volna idő mindenféle capture kártyával tesztelni a dolgot, és nem akartak beégni, hogy esetleg vmelyiket nem szereti a szoftver.

Guru3D is beszáll az új mérésbe.

Egyértelműen jobb az NV a grafikonokat látván.

Nem, ebből csak az derül ki, hogy az Sli jobb CF-el szemben frametime mérés esetén, de ezt eddig is tudtuk, mert pár napja volt linkelve teszt erről, és Abu is megpróbálta elmagyarázni ennek az okát.
Single kártya esetén pedig egyértelműen az AMD jobb. [link]

De amúgy szokásos guru3d minőség, 690-et hasonlítanak 6990-hez, egy esetben...
Viszont azt legalább szépen mutatja, hogy a Fraps-es frametime mérés szart se ér, így akik eddig ezzel parádéztak elfelejthetik, meglehet nézni fraps-es mérésnél össze-vissza ugrál a frametime, míg FCAT-al mérve meg szép "sima ".

[ Szerkesztve ]

a fraps az engine által kiadott renderelendő "játékállapotok" közötti ugrásokat méri, és mint ilyen, igencsak releváns. akkor fut ideálisan a játék, ha mind a fraps, mind az FCAT által mutatott frametime grafikon sima.

a CF grafikonokon látottak pedig siralmasak, bárki bármit mond

Pedro... amigo mio... ma is konzervvért iszunk! Kár lenne ezért a tehetséges gyerekért...

Nem hiába panaszkodnak a CF-es mikro laggokra hiába mondja Abu, hogy kettő lehetőség van az NV a jobbat választotta ez nem kérdés, mert ott nincs panasz ilyen mikro laggra.

Jó tudom be lesz építve a választási lehetőség, de még nincs.

Nem akarok hülyeséget írni, mert ti sokkal jobban tudjátok ezt a témát mint én, de én arra gondoltam, hogy a Fraps-el mért értékeknek semmi köze a kártyához és driverhez mivel még jóval előttük kapcsolódik be folyamatba, ergo ezt nem lehet se NV-nek, se AMD-nek felróni ha valami furcsát látunk mert semmi közük hozzájuk.

CF-et nem vitatom én sem.

[ Szerkesztve ]

az igaz, hogy a Present() call után jön csak a képbe a teljes GPU miskulancia, de két dolgot nem árt ehhez tekintetbe venni:
- ha a Present()-ek egyenletesen jönnek, és utána a a GPU-k összeb*****k az időzítést, akkor annak ugyanúgy ugráló hatása lesz (nagyon rossz esetben jönnek a sokat emlegetett runt frame-ek)
- ha valamelyik frame kiszámolása nagyon sokáig tart, akkor az engine közben megtölti a saját framebufferét, és vár, amíg a GPU nem ürít. ilyenkor a Present()-ek között is jelentkezik egy hosszú frame - rosszabb esetben pedig utána néhány rövid, mert a GPU gyorsabban ürít, mint ahogy a motor számít rá, és akkor a motor is felgyorsít. ezért problémás, ha a két gyártó csudálatos power control megoldásai gyakran billegtetik az órajelet nagy mértékben.

@SzlobiG: én egy kicsit sarkosabban fogalmaznék. teljesen sz*r, amit az AMD megoldása csinál, és ezt az input lagos rizsát csak utólagos magyarázkodásként hozták be. ha az input lagra figyelnének, akkor olyan ütemben tennék ki a frame-eket, ahogy a Present()-ek érkeznek.

Pedro... amigo mio... ma is konzervvért iszunk! Kár lenne ezért a tehetséges gyerekért...

Én nem az input lagot látom, hanem a frame számításával töltött. A két dolog nem egyenlő. Arra vagyok kíváncsi, hogy hány frame jelenik meg, amíg az egéren leadott parancs megjelenik?

Olvastad ezt? [link] - teljesen érthető dolgot ír, és minden alapja megvan annak, hogy azokon a csíkokon a részleteknek nem szabad elveszni.

(#547) gbors: Az AMD erről a rendszerről, amit használnak 2010-ben beszélt, amikor elemezték az AFR-t, hogy melyik megoldás a jobb. Akkor írták le, hogy két opció van, és a profi játékosok visszajelzései alapján az input lag alacsonyan tartására gyúr a megoldásuk. Ez három évvel ezelött volt. Most csak elmondták, hogy a véleményük nem változott meg, de beépítik a másik módot is.
Azon lehet vitázni, hogy hiba-e a profi játékosok véleményére adni, de valamelyik megoldás mellett dönteni kell akkor is. Mindkettőnek megvannak a hátrányai, így olyan nem lesz, ahol kompromisszum nélkül működik majd az AFR.

[ Szerkesztve ]

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

kíváncsi lennék a részletekre, mert ennek így füle sincs, meg farka se nagyon. én azt értem, hogy van olyan szituáció, ahol néhány ms-mmal csökken az input lag (bár azt továbbra sem hiszem, hogy a "profi játékosok" 8ms-ot észrevesznek, de ettől most tekintsünk el), viszont ha ez lett volna a cél, akkor legalább annyi késleltetést rakott volna bele az AMD is, hogy legalább a frame közepe biztosan látható legyen, ugyanis ha két frame a két GPU-n úgy megy ki, hogy az egyiket kitakarja a másik, akkor lazán duplázódik az input lag a kiegyenlített megoldáshoz képest.
nem lennék meglepve, ha a 2010-ben végzett vizsgálat másról szólt volna, csak vmi marketingzseni mai szemmel "újraértelmezte"

Pedro... amigo mio... ma is konzervvért iszunk! Kár lenne ezért a tehetséges gyerekért...

A marketing ezeket nem vette elő újra. Nem is részletezte. Ezt a CF megoldást azért választották, mert a profi játékosok erre szavaztak. Semmi másért. Nekik is teljesen mindegy, hogy hogyan oldják meg, mert az fps alapján ugyanott lesznek. Egyszerűen dönteni kellett, és az AMD a játékosokra hallgatott. Nyilván az elméleti alapja megvan ennek, és ez a döntés így logikus volt. Most beépítik a másikat is a tesztelők kérelmének megfelelően.
Igazából ez az egész tök lényegtelen, mert az már rég rossz, amikor dönteni kell, hogy egységes legyen a megjelenítés, vagy alacsony legyen az input lag.
Egyébként a smoothingot úgy számold, hogy minden képkockát késleltetve kezd számolni, pont azért, hogy igazodjanak egymáshoz.

[ Szerkesztve ]

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