Új hozzászólás Aktív témák
-
BeLucZ
addikt
hozzuk már ki hogy jobban megy kepleren a tomb raider a gtx 680hoz képest kéne hasonlítani, nem a majd 3x drágább titanhoz amivel szoros küzdelmet folytat a 7970 ghz tressfx onon
biztos vagyok benne, hogy fog még jönni catalyst ami gyorsít a radeonokon is, nálam ragyogóan megy 7970el
[ Szerkesztve ]
-
veterán
A link lemaradt:
Tomb Raider (2013) TressFX Hair Crossfire Bug
Tomb Raider (2013) PC Gameplay
Vmiért nem működik az időponthoz linkelés Youtubeon...[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
Fel kell rakni a 13.2 beta6 drivert. A kopaszodás ezzel megszűnik. Ez a gond ugyanúgy driverben lesz javítva az NV-nél is.
A fő különbségeket a Tomb Raiderben a High Precision, az SSAO, a shadows, a DoF és a TressFX adja az architektúrák között. Ezek használnak compute shadert, illetve az FXAA még, de az annyira nem terhel.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
siriq
őstag
Kifejezetten hulladek a haj megvalositasa. Akkor, inkabb mar fx nelkul ha kerhetem, Dolgozzanak rajta meg vagy 1 evet es nem lesz ilyen nevetseges a megvalositasa az egesznek.
[ Szerkesztve ]
Meg mindig nincs 1000 oras BF3 nev, kozben mar masok is erdeklodnek utana... Mar bevallottan nincs 1000 ora neki... Varjunk Dec 31-ig a Mantle-a.
-
Abu85
HÁZIGAZDA
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.
-
Abu85
HÁZIGAZDA
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.
-
Abu85
HÁZIGAZDA
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.
-
Abu85
HÁZIGAZDA
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.
-
Abu85
HÁZIGAZDA
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.
-
Abu85
HÁZIGAZDA
É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.
-
veterán
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 ]
-
Abu85
HÁZIGAZDA
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.
-
Abu85
HÁZIGAZDA
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.
-
Abu85
HÁZIGAZDA
É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.
-
Abu85
HÁZIGAZDA
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.
-
Abu85
HÁZIGAZDA
É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.
-
veterán
A látottak alapján számomra elég egyértelmű, hogy mi a különbség CF és SLI közöt, meg hogy mit csinál a gyakorlatban a 2 rendszer.
~13ms alatt végez az egyik képkockával a CF (ami annyi idő amit egy szóló kártya tud), aztán szinte azonnal (0ms) ott a következő, aztán 13ms múlva jön megint egy, aztán szinte instant (0ms) megint egy. Hogy lehetséges ez amikor tudjuk egy szóló kártyánnak kb. 13ms kell egy képkockához az adott játékban?
Ebből én arra következtetek, hogy a 2 VGA párhuzamosan dolgozik, amit úgy értek, hogy egyszerre kezdik el számolnia köv. képkockát. Az 1-es számú VGA számolja a soron következő képet, a 2-es számú pedig az utána következőt, és mivel egyszerre kezdték, kb. egyszerre fognak végezni is, ezért megy ki egyszerre a 2 képkocka, ilyenkor látjuk a grafikonon, hogy a második kép szinte 0ms alatt ott van az első mögött. Utána mindkét VGA nekiáll a következő képkocka számításának, ami pont ugyan annyi időbe telik mint egy szóló GPU esetén, ilyenkor látjuk a 13ms körüli késleltetést az ábrán.
Mit csinál ezzel szemben az SLI? Mivel a késleltetések kiegyensúlyozottak, és kb. fele annyi ideig tartanak mint egy szóló VGA esetén, én ebből csak arra tudok következtetni, hogy a 2. VGA fél képkocka eltolással dolgozik. Tehát az 1-es VGA számolja a soron következő képet, aztán amikor a munka feléhez ér, a 2-es számú VGA nekiáll az utána következő kép számolásának, így nem egyszerre fognak végezni, hanem a 2. VGA fél képkockányi idővel később, így a képkockák kb. fele annyi idő alatt követik egymást mint egy szóló VGA esetében.
Az AMD jelenlegi megoldásának az a hátránya, hogy ha azonnal követi egymást 2 képkocka akkor vmelyik egyáltalán nem vagy csak alig fog látszani a monitoron a játékos számára.
[ Szerkesztve ]
-
Whit3Rav3n
senior tag
Ezzel az elmélettel csak az a baj hogy honnan tudod hogy mikor vagy a munka felénél, a képkocka rajzolása csak egy kis része az egésznek, a vidkarinak elöször 3d-ben ki kell számolni a teljes részt. Szóval emiatt kell egy + késleltetés hogy kell egy pár kiszámolt képkocka hogy ismert legyen az átlag idö ami kell az eltoláshoz. A CF sem párhuzamosan számol 2 képkockát hiszen az lehetetlen, maga az engine egymás után adja a képkockákat és annak is van egy feldolgozási ideje. Ezért is van az hogy ha a cpu-ra kell várni akkor gyakorlatilag nincs mikroszaggatás mert a kártyáknak a cpu-ra kell várni. Szóval a minimális frametime az az idö ami kell a rendszernek a következö képkocka számolásának kiadásához a vga-hoz.
-
Whit3Rav3n
senior tag
Ez akkor is méréssel bizonyított hogy a cpu idö mindig benne van képkocka kiadásában. Szóval olyan nincs hogy kapásból 2 kártyának egyidöben kiad 2 képkockát. Ha cpu limited van azért nincs mikroszaggatás mert nem tudja gyorsan egymás után átadni a gpu-knak a számolást a cpu hogy aztán várni kelljen míg kész legyen. Én magam is résztvettem ezekben a mérésekben és tényleg úgy volt hogy a cpu olyan gyorsan adogatja a frame-eket a gpu-knak ahogy tudja aztán vár amíg kész lesz az egyik az újabb frame átadásával, ez okozza ezt az egy kicsi egy nagy frame idöt 2 gpu-nál ami egyébkent 3 gpu-nál 2 rövid egy hosszú és négynél 3 rövid 1 hosszú.
Az egyébként lehet hogy elökészít frame-eket de ezek szerint ekkora hibát nem tettek a rendszerbe hogy multigpu-nál egyszerüen átadja mindkét gpu-nak egyszerre a frame.et hanem a kiszámolási idö delay mindig megmarad. Egyébként én sohasem tapasztaltam azt hogy cf-el normális skálázás mellett nem lett volna szubjektívan jobb a gameplay 1 gpu-hoz képest.
-
Abu85
HÁZIGAZDA
Pont erről írtam korábban, hogy az új driverekben ezt a lehetőséget elvették a felhasználóktól. Ezért háborogtak az SLI tulajok, hogy az új driverekkel nem tudják beszabályozni a lagot, mert a driver egyéni profilt használ minden játékra, vagy a játék alapbeállításait használja.
(#575) siriq: a GPUView az ilyen. [link] - Ez marha jó tool, csak sokszáz frame-et kielemezni belőle eléggé időigényes, mert statisztikát, vagy egyszerű grafikont nem csinál.
Az NV toolja az elég jó, csak kell hozzá egy marha gyors SSD-rendszer. Emellett néztem az időigényét. Kilenc játék helyett három férne bele. Tekintve, hogy alig tesztelünk AFR-t, így a több játékot választjuk, mert egy kártyával a külföldi tesztek sem látnak problémát.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Whit3Rav3n
senior tag
Azt nem tudom hogy a pcper miért ezt mérte, ha megnézed a tomshardware mérését ott sokkal jobban szerepelt a cf, ez még egy új dolog úgy néz ki még kicsit problémás a dolog ha ekkora szórások vannak, mindenesetre ez nem egyezik az én tapasztalatommal sem cf téren. Én csak fraps-el tudtam mérni de a mérések igazolták a szubjektív benyomást is, minél közelebb votl a cpu limithez a game annál kevesebb volt a mikroszaggatás és cpu limitnél gyakorlatilag nem is volt.
Na meg ha tényleg egyszerre adná a 2 képkockát akkor semmivel sem lenne jobb a 2 kártya 1-nél amit megint sokan igazolnak hogy ez nem igaz mert van javulás a szubjektív sebességben 2 kártyával cf-nél.
[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
Már írtam, hogy kevered az input lagot a frame time-mal. Azt hiszed, hogy ez a két fogalom egyenlő, de valójában nem az. A frame time az csak egy képkockára vonatkozik, míg az input lag igazából nem meghatározható így, mivel a bevitt parancsot nem tudod követni, hogy először melyik képkockán jelenik meg.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Akkor másképp magyarázom. Van egy lövés a játékban. Honnan tudod, hogy az a képen ugyanakkor jelenik meg CF-fel, mint SLI-vel? Mert a frame time erre nincs teljes befolyással.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
-
Abu85
HÁZIGAZDA
Rossz ábrát nézel. Ez azt mutatja, hogy egy motor a jelenettől a képkocka megjelenítéséig mit csinál. Azon belül mit mér a FRAPS. Az FCAT Display részben eltelt időt méri. Viszont az új frame számításával a motor nem várja meg a T_Displayt.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
-
Whit3Rav3n
senior tag
Azért a valóság nem így néz ki, neked ezek szerint nem volt még soha cf rendszered mert a valóságban a mikroszaggatás ellenére is javul a lényegesen a játékélmény. Különben már rengeteg embernek feltünt volna hogy vett mégegy kártyát és ugyanúgy mennek a game-ek érzésre. Ez a 0 frame-es szituáció egy extrém helyzet ami nem szokott normálisan cf-nél sem elöfordulni. Legalábbis olyan nálam még nem votl hogy volt rendes cf profil meg skálázás a game-ben de nem ment érzésre jobban a game 2 kártyával mint 1-el.
[ Szerkesztve ]
-
Abu85
HÁZIGAZDA
A FRAPS és az FCAT nem függ egymástól. Az FCAT semmit sem igényel a FRAPS-tól. De már unom, hogy ezt sokadjára le kell írnom. Vagy elolvasod, amit írok, vagy nem. Ennyi. Ha nem, akkor azt hiszel innentől, amit akarsz.
Igen a CF funkcionálisan nagyjából olyan eredményt ad a kimenetnél, mintha egy GPU-s lenne a rendszer. Pontosan ezért alacsonyabb az input lag, mintha a smootholás miatt eltolnád a frame-számításokat.A HDAO a Far Cry 3-ban a legjobb képminőséget nyúltó AO megoldás. Teljesen szabványos effekt, csak valamiért az utolsó patch óta nem jó GeForce-on. Pont az FC3-mal készítettem összehasonlítást az AO effektekről. [link]
Az meg, hogy ront a látványon ... hát egyáltalán nem, maximum akkor, ha fake árnyékokat csinál, de ez a HDAO-ra pont nem jellemző.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A FRAPS az funkcionálisan csak arra jó, hogy kiírja az FPS-t. Ennyi. Semmi mást nem lehet vele ténylegesen vizsgálni.
Az FCAT az jobb, hiszen megtudod belőle a displayidőt. Ezeket nem kell cáfolni.
Input lagot senki sem mér, mert ahhoz egy marha nagy sebességű kamera kell. De igazából mérni sem érdemes, mert az elvben is benne van, hogy a smoothing a számítás késleltetésével jár. De mindegy. Fentebb olvashatsz arról, hogy miért. Ha az nem elég, akkor ennyi.Dehogy szubjektív. Nézz a való világba, és a látottakat ültesd át a virtuális világba. Egyértelmű, hogy olyan erős árnyékokat nem látsz mint az SSAO-nál és a HBAO-nál az FC3-ban. A HDAO megoldása jellemzően fake árnyékoktól mentes ebben a játékban. Hogy ennél a legkisebb a változás? Hát talán azért, mert ez dolgozik a legtöbb mintával, és nem rak oda árnyékot, ahol nem keletkezne a valóságban.
Az AO az abszolút nem a fake árnyékokról szól. A szimulált screen space opciókat azért használjuk, mert az eredményük messze elég jó, és az erőforrás-igényük nem sok a scene megoldásokhoz képest.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az AMD ilyet nem mondott, csak 4 éve, amikor beszélték, hogy az AFR implementációjuk azért ilyen, hogy az input lag alacsony legyen. 4 éve volt ez. És eleve érthető, hogy ha késleltetés nélkül kezdődik meg minden frame számítása, akkor a késleltetéssel dolgozó megoldás több input lagot eredményez.
Ez nem olyan egyszerű, már írtam. Eleve a smoothing egy GPU-ra is működik, tehát nem SLI specifikus. SLI-vel annyi a különbség, hogy két GPU-ra történik az egész rendszer feldolgozása.
Nem. Az AMD azt mondta, hogy a tesztelők kérésére raknak egy olyan megoldást is a driverbe, ami úgy működik, ahogy az NV AFR-je, de a mostani AFR marad az alapértelmezett, mert a profi játékosok jobban kedvelik ennek az előnyeit. Egy kapcsolóval lehet majd a kettő között váltogatni.
Az a baj, hogy azt hiszed, hogy az egyik AFR megoldásnak csak előnyei vannak, míg a másiknak csak hátrányai. A valóság az, hogy ami az egyiknek előnye, az a másiknak hátránya és fordítva. Olyan AFR nincs, ami minden szempontból előnyös. Ha lenne, akkor mindenki arra építene implementációt.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
A GTX 580 sokszor 40 wattra volt a kártyába épített TDP limittől. Ennyi teljesítmény maradt benne, amit a fix órajel miatt nem tudtak kihasználni. Ha kihasználják, akkor úgy jó 15-20%-kal gyorsabb lehetett volna, de ez már történelem, nyilván ilyen DVFS rendszereket nem könnyű fejleszteni.
(#829) HSM: De minek akarnál rátenni 8-at, amikor 6-tal is megvan a 300 wattos szabványos fogyasztás. Attól, hogy raksz rá 8-at még nem mehetsz a 300 watt fölé, ha el akarod adni a kártyát az OEM-eknek.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Nem. A Furmark szintű terhelés mellett a GK110 500 MHz-en üzemképes a 300 wattra tervezett PCB-vel. Ezért van driverből lefojtva a működése, hogy ne kelljen az órajelet csökkenteni.
Ha nincs DVFS, akkor mindenképp peakre kell tervezni, ami még a Furmarknál is nagyobb terhelés.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
Új hozzászólás Aktív témák
A topikban az OFF és minden egyéb, nem a témához kapcsolódó hozzászólás gyártása TILOS!
Megbízhatatlan oldalakat ahol nem mérnek (pl gamegpu) ne linkeljetek.
- MasterDeeJay: Volta a bányából azaz CMP 100-210 kisteszt (Tesla V100 mining)
- Telekom mobilszolgáltatások
- Kertészet, mezőgazdaság topik
- exHWSW - Értünk mindenhez IS
- Facebook és Messenger
- EAFC 24
- Házimozi haladó szinten
- OLED TV topic
- Székesfehérvár és környéke adok-veszek-beszélgetek
- Vicces képek
- További aktív témák...
- LG NanoCell 55NANO766QA Halvány píxel csík
- Philips 58PUS8545/12 1 ÉV GARANCIA Játék üzemmód
- Tyű-ha! HP EliteBook 850 G7 Fémházas Szuper Strapabíró Laptop 15,6" -65% i7-10610U 32/512 FHD HUN
- Bomba ár! HP EliteBook 840 G5 - i5-8G I 8GB I 128GB SSD I 14" FHD I HDMI I Cam I W10 I Gari!
- The Last of Us Part I Ps5