Új hozzászólás Aktív témák
-
Abu85
HÁZIGAZDA
-
Loha
veterán
Ha megnézed ezt az ábrát, az FCAT overlay ugyan oda épül be ahova a FRAPS, közvetlenül a játék engine mögé, és szépen megjelöli a képkockát, a capture kártya meg felveszi az ábra legvégén a kimenetet.
Ezzel a megoldással pontosan meg lehet határozni, hogy az adott képkocka mikor hagyta el a játék engine-t és mikor érkezett meg a monitorra.
Az természetesen nem derül ki, hogy mennyi idő volt amíg az egértől eljutott az infó a játék engine-ig, de ezt a részét nem értem, hogyan befolyásolná a VGA azonos fps esetén, a másik része meg ott van az FCAT mérésekben.[ Szerkesztve ]
-
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
Azért olyan dolog nincs, ami PRT-vel megoldható, de nélküle már nem. A PRT előnye a sebességben lesz inkább. Itt főleg azokra gondolok, hogy a nextgen Radeon és GeForce VGA-k is támogatják majd ugyanazokat a pointereket, amiket a CPU használ, csak a Kaveri x86/AMD64, vagyis az ARMv8-at támogató GeForce-ok ezzel nem fognak úgy működni, mint az x86/AMD64-et támogató Radeonok.
Jensen nem fog könnycseppeket hullatni. Ha őt a PC-s konzolportok érdekelnék, akkor nem építette volna már ma le a fejlesztői támogatást ezekre a játékokra. Az NV-t a felhő, a mobil, és a PC exkluzív F2P/MMO játékok érdeklik. Ezért engednek át szinte minden AAA PC portot az AMD-nek. Ezt az AMD sem titkolja. Roy Taylor pont mondta, hogy az NV már inkább egy smarthphone cég. Ez teljesen hihető, nyilván logikátlan azt gondolni, hogy a régebben mindent vivő TWIMTBP csupán egy év alatt leépült. Nem, ez a partnerprogram szándékosan koncentrál más területekre, és a Gaming Evolved ebből építkezik. Ha egységesen küzdenének ugyanazért a játékokért, akkor nem lenne ennyire egyoldalúan előretörő a Gaming Evolved a PC-s konzolportok területén.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
hát ezek miatt újradesignolni éppen nem kell - max. lesznek olyan effektek, amik nVidián nem mennek (mint ahogy a Just Cause 2-ben a bokeh filter nem ment AMD-n). azt mondjuk értem, hogy OEM-ben ez hol fog fájni - majd szabadidőmben elhullatok 1-2 könnycseppet Jensenék sanyarú sorsa miatt
"We put all our politicians in prison as soon as they're elected." "Why?" "It saves time."
-
#594
Loha
veterán
Whit3Rav3n
#592
Loha
veterán
válasz
Whit3Rav3n
#592
üzenetére
Pcper tesztje részletesebb, jobban belementek a részletekbe.
As we expected, both from The Tech Report's background with this and Nvidia's in-house examples, we see that AMD's Radeon HD 7870s in CrossFire tend to suffer more dropped and runt frames than a pair of GeForce GTX 660 Tis in SLI. This addresses much of the trepidation about multi-card configurations expressed in Best Graphics Cards for the Money, confirming that two of Nvidia's boards appear more appealing. AMD even admits it's playing catch-up in this area, and is addressing its shortcomings through successive driver improvements Idézet: Tom's A konklúzió ugyan az mint máshol.Abu85:
Nem keverem az input lagot a frame time-al. Az input lag egy részét a frame time adja, a többi részét meg elvileg nem kellene a VGA-nak befolyásolnia. Tehát, ha a frame time kisebb, akkor miért ne lenne kisebb az input lag is?[ 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.
-
#592
Whit3Rav3n
senior tag
Loha
#591
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 ]
-
#591
Loha
veterán
Whit3Rav3n
#576
Loha
veterán
válasz
Whit3Rav3n
#576
üzenetére
Ez akkor is méréssel bizonyított hogy a cpu idö mindig benne van képkocka kiadásában.
Ezt természetesen így van.Szóval olyan nincs hogy kapásból 2 kártyának egyidöben kiad 2 képkockát.
Ha 2-3 képkockával előre dolgozik a CPU, akkor szerintem lehetséges, hogy szinte egyszerre továbbad 2 képkockát.É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ú.
Itt a magyarázatodban nem értem, hogy ha a CPU egyesével adogatja a képkockákat a GPU-nak, akkor miért úgy néz ki a grafikon, hogy szinte 0 késleltetés, aztán 2 képkockányi késleltetés és ez ismétlődik.(#584) Abu85:
Azt, hogy az AMD a CF-nél az input lagot veszi figyelembe, míg az NV ezt növelve máshogy dolgozik. Szívük joga eldönteni. Más gond meg már nincs, ha megnézed a teszteket.
Azt a részét értem, hogy az AMD azt kommunikálja, hogy az input lag miatt működik így a CF, de a teszteket elnézve nekem úgy tűnik ez nem igaz, egyszerűen kihagytak egy funkciót, ami az SLI-ben benne van, persze ha mutatsz olyan tesztet ahol igazolják az AMD állítását az input lag előnyükről az más.[ Szerkesztve ]
-
siriq
őstag
Egyszeru kerdesre nem adtad meg a valaszt. Az okfejtes megvolt de hianyzott az egesz hozzaszolasbol a direkt valasz. Ezt ugye lehet a post elejere vagy a vegere rakni, amennyiben az okfejtesed koveti a valltozast. Az okfejetesed pedig csak nagyon-nagyon kozvetett dolgokkal lett magyarazva. Ami nem teljesen helytelen de legalabb hibas.
Neharagudj meg, mar 13 eve nem elek otthon de ezt meg en is tudom.[ 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
Érthető volt. Kifejtettem rá a választ is. Ha nem elég, akkor az már a te bajod.
(#585) gbors: Főleg azért, mert az AMD árukapcsolást használ a termékeire. A CPU-kat és a Radeon GPU-kat csomagban is meg lehet vásárolni. Ez így jóval olcsóbb, mint Radeon helyett GeForce-ot venni. Ez természetesen üzletileg törvénytelen, de az NV pontosan tudja, hogy az ilyen árukapcsolások ellen nem tesznek a hatóságok semmit, aminek régebben például az Ion látta kárát, amikor az Intel féláron kínálta az Atomot, ha chipsetet is kértek hozzá a partnerek. Ez az OEM-eknél egy vesztes helyzet. Az Ion kicsinálta tudásban és sebességben az atomos ellenfelét, de mégis alulmaradt az eladásoknál. Én aláírom, hogy elképesztően tisztességtelen volt, amit az Intel csinált, de az AMD is megcsinálja, mert ez a cégérdek.
Ezek mellett, ami az NV-nek kellemetlen lesz, hogy a DirectX 11.1-be kiterjesztésekre is van lehetőség. Ezeket természetesen lehet támogatni a konkurenseknek is, de ahhoz hardvert kell tervezni. A konzolok miatt a GDS kiterjesztett használatára és a PRT-re lesz az AMD-nek kiterjesztése. Mire erre hardveres választ adnak legalább két év. Az NV-nek most az a cél, hogy a konzolra kiadott játékokat lehessen játszani felhőből, mert más lehetőségük nincs a versenyzésre, leszámítva azt, hogy rábeszélik a fejlesztőket a PC-s port butítására és újradizájnolására, ha szükséges. Emellett nyilván nem árt leépíteni a konzolokat egy átgondolt marketingkampánnyal, ezt Tony Tamasi vállalta magára, mostanában mindenféle orbitális baromságokat nyilatkozik a konzolok kárára.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
siriq
őstag
Most ujra leirom hatha nem voltam ertheto. Megfogjatok irni a fooldalon vagy nem? Egyszeru igen vagy nem valasz tokeletes lesz.
Nem ertheto. Megint irtal egy regenyt az egyseru igen vagy nem helyett. Nem regenyre van szukseg.
[ 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.
-
azt a részét értem, hogy a Kaveri után érdeklődnek a fejlesztők, de ez miért fáj az nVidiának? nyilván nem az APU-n fog minden futni, diszkrét GPU kelleni fog mellé, akkor meg nem mindegy, melyik?
"We put all our politicians in prison as soon as they're elected." "Why?" "It saves time."
-
Abu85
HÁZIGAZDA
Mit? Azt, hogy az AMD a CF-nél az input lagot veszi figyelembe, míg az NV ezt növelve máshogy dolgozik. Szívük joga eldönteni. Más gond meg már nincs, ha megnézed a teszteket.
Ez egy olyan dolog, mint amikor az NV beharangozta, hogy az AMD képminősége rosszabb az NV-nél. Mindenki lehozta, majd később az AMD elmagyarázta, hogy az NVIDIA a shimmering jelenség eltüntetésére törekszik, míg a Radeonok a Microsoft referencia raszterizáló minőségét követik. De mivel az NV szeretné, így beépítettek egy olyan módot a driverbe, ami úgy dolgozik, ahogy az NV megoldása. Az NV akkor vett vissza, amikor látta, hogy a Radeonokon ez a mód 10%-kal több sebességet ad. Azóta az van kommunikálva, hogy jó az alapbeállítás.
Ezek mind csinált problémák, amik valójában nem is azok, csak másképp működnek. Ugyanaz lesz a vége, mint a képminőségnek. Az AMD a következő driverben belerakja, ahogy az NV dolgozik, és aztán az NV lekommunikálja, hogy jó lesz az alapbeállítás a CF-hez, mert gyorsulnak a frame smoothinggal.
Alapvető stratégiák ezek arra, hogy az emberek ne arról beszélgessenek, hogy az NV nem támogatja a top AAA címeket. Ez a valós probléma és az új generációs konzolok.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
siriq
őstag
A fo oldalon az infos dologra meg mindig nem irtal semmit, pedig mar masodjara kerdeztem.
Magyaran lehozzatok a fooldalon, vagy nem?[ 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
Az a baj, hogy a népszerűek és újak is AMD-sek. Az NV-nek az új konzolgeneráció betesz. Nem éri meg ebbe pénzt invesztálni, amikor a mobil piacon a Qualcomm is nagyon keményít. Ellenük van esélye az NV-nek. Az AMD hardveres felépítését követő konzolok ellen nincs. Ezt legalább két év, mire az NV is le tudja követni egy megfelelő hardverrel, és annak is ARM processzorosnak kell lennie, vagyis a legacy programok kiesnek.
Elsősorban az idő a tesztelt hardverek szempontjából van megszabva. Nem mehet el egy VGA-tesztnél csak a mérésekre egy hét. Főleg akkor nem, amikor egy kártyával már nem lehet mérni lényeges különbségeket. Más sem mér.
Akik csak VGA-kkal foglalkoznak azoknak ez értékelhető, de nekünk csak akkor válik azzá, ha a játékok számát annyira lecsökkentjük, hogy belefér az eddigi időkeretekbe. Ez számításaim szerint maximum négy játékot jelent. Jelen pillanatban ha négy játékkal számolunk, akkor eléggé meg lenne kötve a kezünk, de a Crysis 3, a Battlefield 3, a Tomb Raider és a Bioshock Infinite lenne benne. Ezekben totál sima minden, nem számítva, hogy az új BF3 patch elrontotta az új GeForce driveren az egyenletességet, amit javítanak.
Pédlául az olyan innovatív motorok, mint ami a DiRT Showdown alatt van teljesen kimaradna. Ezzel alapvetően a jövőről gyengébb képet kapnánk. A Sleeping Dogs is érdekes abból a szempontból, hogy az AA használata rendkívül egyedi. Nem egy, hanem három megoldást vetnek be.[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Locutus
veterán
Egyrészt, szerintem nem kell ennyire ráflesselni az nv vagy az amd támogatására a játékoknál. Népszerűség, és újdonság alapján kellene válogatni, és kész.
Másrészt miért van az megszabva, hogy egy tesztre mennyi idő fordítható? Ki korlátozza ezt?
Vagy legyenek két fejezetes tesztek. Az elsőben a hagyományos dolgok, a másodikban lehet egy kicsit mélyebbre ásni. Valami értelme kell legyen annak, hogy játékokkal teszteltek, és ha az FPS szám önmagában nem ad teljes képet, akkor ki KELL térni a frame ratingre is. Az úgy teljes munka, és az olvasók tudnak dönteni, hogy az általuk preferált játékokhoz mi a jobb választás.Komplett hangrendszerem eladó - https://hardverapro.hu/apro/mackie_studio_monitorok_mr5mk3_mr10s_mk3_sub_asus/hsz_1-50.html
-
Abu85
HÁZIGAZDA
Egy kártyánál nulla probléma van. Esetleg specifikus, amiről a driver nem tehet. Például a Far Cry 3-ban a MSAA mellett a Radenokra jellemzi, de ezt az fps korlátozásával meg lehet szüntetni. A konzolba kell beírni egy 999 alatti számot. A Sleeping Dogs is specfikus program. A GeForce-on nagyon pattog, de csak akkor, ha az Extreme AA rajta van a játékon. Ugyanez a gond a Sniper Elite V2-vel, de csak 4xSSAA-val jön elő GeForce-on.
Az új patch-csel és GeForce driverrel a Battlefield 3 is mikroakadásokat csinál, de az NV már szólt, hogy ezt javítani fogják, ez rendkívül speckó hiba, amit a patch hozott elő.
Szóval egy kártyával ez a jelenség jellemezően program oldalon keletkezik bizonyos beállítások mellett.Lehet, hogy csinálunk ilyen tesztet. Nem rajtunk múlik, hanem azon, hogy lesz-e hozzá hardver. Viszont erős ellenérzés az, hogy nagyon le kell csökkenteni a tesztelt játékok számát. Sok felhasználó már most is nehezteli, hogy alig van TWIMTBP AAA játék a tesztben. Szám szerint kettő maradt. Ezzel nagyon nehéz mit kezdeni, mert az NV lemondott az AAA konzolportokról. Nincs rá erőforrásuk, és a next-gen konzolokkal kapcsolatos bizonytalanság miatt a fejlesztők sem látják a helyzetet kellemesnek. A GDC alatt rengeteg vélemény alakult ki és nem vicc, hogy az AAA játékok portolását a fejlesztők jó része ahhoz köti, hogy az AMD Kaveri APU mennyire terjed majd el. Az alapvető gond, hogy a játékot PC-re rendkívül limitált funkciók mellett kell elkészíteni, mert az új konzolok képességei nem csak túlmutatnak a mai PC-s konfigurációkon, hanem a 8 darab Jaguar maggal arra vannak kényszerítve a fejlesztők, hogy az AI-t, a fizikát és a jól párhuzamosítható dolgokat nem a processzormagokon oldják meg. Ha átraksz az IGP-re olyan dolgokat, ami a játékmenetet befolyásolja, akkor csak az év végén érkező Kaveri APU lesz rá alkalmas, hogy játssz PC-n. Roppant kellemetlen probléma, és ezért fektet az AMD erőforrást a fejlesztők támogatásába, hogy akkor is adják ki a játékot PC-re, ha esetleg bizonyos funkciók Kaveri APU-t igényelnek. A többi gyártónak ez viszont nem jó, mert olyan irányba viszik a konzolok a fejlesztést, amire nem készültek fel. Az NV ezért ráállt a PC exkluzív játékokra, mert azoknál a konzolok felépítése nem számít. Mivel jellemzően AAA játékokkal tesztelünk, így gyakorlatilag három-négy játék mellett csak Gaming Evolved címeket fogsz látni. Nem csak a mostani felhozatal alapján, hanem a következő pár hónap megjelenései miatt is, mert az AMD partnerprogramjának a része a GRID 2, a Total War: ROME 2, a Company of Heroes 2, és jórészt az összes AAA cím. Később a Battlefiled 4, a Watch Dogs, a Raven's Cry, a Thief 4 ...
Egyszerűen az AAA játékok esetében kell 9 játék, hogy legalább egy TWIMTBP címet berakjunk. Hárommal csak AMD-s játékok kerülnének be.
Még a kilenc is nagyon kevés, mert jórészt a Metro 2033 tartja magát egyedüliként, hiszen az UE3-as Batmant fel fogja váltani az UE3-as Bioshock Infinite. Vannak persze TWIMTBP játékok is, de a Sniper: Ghost Warrior 2 még a készülő DX11-es patch-csel sem alternatíva, míg az MMO-k (például Neverwinter) elképesztően körülményesek (ahány mérés annyi eredmény még azonos konfigon is).[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
siriq
őstag
Egy kartyanal is latnak problemat.
A masik meg az info. Az meg ugyan ugy nincs megoldva. Ha mar nem akartok tesztelni, akkor reszletes leirast meg lehetne csinalni. Meg ilyen keson is. Mert ha most dobnad ki mar laza par honapos kesesben leszel.
Lehetne reszletezni miert nem csinaltok ilyen tesztet is pl.[ 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
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.
-
#576
Whit3Rav3n
senior tag
Loha
#574
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.
-
siriq
őstag
Ehez kepest az anand is az nv fele tool hasznalja. Emlekszel amikor kerezted, hogy mi mast hasznalnak frapson kivul?
Mar lassan minden kulfoldi oldal rendesen fogja tesztelni(vagy teszteli es infozik a fo oldalon errol) a temat.
[ 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.
-
#574
Loha
veterán
Whit3Rav3n
#570
Loha
veterán
válasz
Whit3Rav3n
#570
üzenetére
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. Alapesetben a Windows/DirectX 3-as pre-rendered frames értékkel dolgozik, tehát a CPU 3 képkockát mindig előkészít a GPU-nak, ha rendelkezésre állnak hozzá az erőforrások.
Abu85: NV control panel azt írja, hogy a max pre-rendered frames beállítást nem vonatkozik SLI-re.
-
#571
Abu85
HÁZIGAZDA
Whit3Rav3n
#568
Abu85
HÁZIGAZDA
válasz
Whit3Rav3n
#568
üzenetére
Még a Ferminél beszéltek arról, hogy kidolgoztak egy olyan módszert, hogy késleltetve számolják a frame-eket egy kártyával, mert így tudnak reagálni a frame spike-okra. Gondolom ezt a megoldást terjesztették ki az SLI-re, csak AFR-rel kell csinálni a késleltetett számítást.
Az NV-nek erről nincs mérése, de a Nixxes szokta azt csinálni, hogy a PC-s portokhoz az NV-nek más pre-render frame adatokat állít be, mert egy kártyával is késleltetve számolnak. Innen van az, hogy SLI-nél két kártyával az extra késleltetés az input lagra optimalizált AFR-hez képest +10-15 ms. Azt nem tudom, hogy más is így csinálja-e, igazából nem kötelező, csak érdemes a többletkésleltetésre a programból reagálni.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#570
Whit3Rav3n
senior tag
Loha
#569
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.
-
Loha
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 ]
-
#568
Whit3Rav3n
senior tag
Abu85
#554
Whit3Rav3n
senior tag
Egyébként erröl a módszerröl amit nv használ ez hivatalos infó mert egy másik fórumon mindenki csak találgatja hogy akkor pontosan milyen módszerrel is egyenlíti a frame idöket az nv. Szóval a te leírásod alapján 1 frame-el több az input lag a frame idö meghatározása miatt?
-
Locutus
veterán
Komplett hangrendszerem eladó - https://hardverapro.hu/apro/mackie_studio_monitorok_mr5mk3_mr10s_mk3_sub_asus/hsz_1-50.html
-
yah, pongyola voltam, az átlag frametime az az elmúlt pár frame átlaga akart lenni. és ahogy mondtam, sztem a flipnél kell késleltetni, úgyhogy a munka elkezdése nem gond.
a multi-monitoros cucchoz nem tudok hozzászólni. ha cinikus akarnék lenni (márpedig miért ne akarnék![;]](//cdn.rios.hu/dl/s/v1.gif)
), akkor azt írnám, hogy marhára nem érdekel, oldják meg..."We put all our politicians in prison as soon as they're elected." "Why?" "It saves time."
-
#565
Abu85
HÁZIGAZDA
huskydog17
#563
Abu85
HÁZIGAZDA
válasz
huskydog17
#563
üzenetére
Inkább az a kérdés, hogy hova menjenek. Nem azért van ennyi Gaming Evolved AAA konzolport, mert az AMD letarolja a piacot, hanem inkább azért, mert az NV-nek nincs rájuk erőforrása. Elviszik az embert a PC exkluzív projektek, a Tegra támogatása, ami marha sok embert kíván, és a saját motor fejlesztése, amit az NV a felhőbe szán. Ezek mellett nincs már elég erőforrás az AAA konzolportok kiemelt támogatásához. Az AMD-nek van. A Far Cry 3 is maradt volna TWIMTBP programos, de ez nem csak a fejlesztőkön múlik. Ha az NV-nek ez teher, akkor mennek máshova. Igazából az AMD is túlvállalja magát szerintem, 2013-ban mindenképp.
Javítások lesznek még szerintem. Elsősorban az NV-nek kellene megoldani, hogy végre jól működjön a HDAO. És ezt nem ártana a fejlesztőknek elintézni, mert ők rontották el.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#564
SzlobiG
félisten
huskydog17
#559
SzlobiG
félisten
válasz
huskydog17
#559
üzenetére
Ez azz megint olcsón jutok AAA gémekhez,
-
#563
huskydog17
addikt
Abu85
#562
huskydog17
addikt
Tééééényleg a Project Phoenix! Ez ki is ment a fejemből.
Hm...ez így tök logikus, akkor ez lenne az első játék, ahol a vörös szépséget irányíthatjuk. Gondolom oda is terveznek TressFX-et, hiszen Ruby haja megnőtt.Amúgy van valami "insider" infód arról, hogy a Watch Dogs fejlesztői, azaz a Ubisoft Montreal szándékozik-e maradni az AMD-nél vagy sem? Mennyire voltak elégedettek a FC3 esetében? Az AMD-nél még mindig kalapálják a FC3 kódját, hogy gyorsabb legyen, vagy vége a javításoknak végleg?
Gameplay csatornám: https://www.youtube.com/channel/UCG_2-vD7BIJf56R14CU4iuQ
-
#562
Abu85
HÁZIGAZDA
huskydog17
#559
Abu85
HÁZIGAZDA
válasz
huskydog17
#559
üzenetére
Lehet, hogy Ruby nem csak techdemó, hanem játék szintjén tér vissza. Igazából abba érdemes belegondolni, hogy az Illfonic egy játékfejlesztő cég, és ők csinálják a techdemót. Lehet, hogy több az amit rájuk bíztak, csak még nem beszélnek többről, mint techdemó. Eleve a csapat összesen 12 fő, tehát a Ruby demó teljesen leköti őket, viszont ennyi erőforrást belefektetve, meg abból kiindulva, hogy az egészet játékként kezdték el dizájnolni, simán lehet belőle game. Az AMD ingyen osztogatja, az Illfonic pedig felrakja steamre és abból van pénzük.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Abu85
HÁZIGAZDA
Az átlag frametime az elég rossz ötlet, mert az a játékokban eléggé ingadozó lehet. Ha ez alapján smootholsz, akkor a smooth nem biztos, hogy smooth lesz. A legjobb megoldás az előző frame idejét mérni, de még azelőtt el kell kezdeni a munkát, mielőtt ez kiderülne. Ezek jelentik a nehézséget.
Illetve a smoothing sémának vannak kellemetlenségei, mert növeli a driverben a hibalehetőséget. Ha több process fut, akkor a driver balanszírozhatja a teljesítményt. Ez multi-monitor környezetben kellemetlen, mert a hardver nem adja le a teljes sebességet minden kijelzőn. [link] - látható, hogy az alkalmazások nem futnak ugyanazzal a teljesítménnyel. És ez egy GTX 460 GPU. Ez az NV smoothing megoldása miatt van így. Ennek 400-500 fps között kellene mindegyik ablakot futtatni.Nem olyan egyszerű ez, mert megold egy jelenséget, aminek lesz némi ára, de ugyanakkor a multimonitor környezeteket eléggé furcsán balanszírozza. Ezért is ragaszkodik az AMD ahhoz, hogy alapértelmezett módban ne állítson fel ütemezést.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
#560
FireKeeper
nagyúr
huskydog17
#559
FireKeeper
nagyúr
válasz
huskydog17
#559
üzenetére
az új Total War már alapból GE, ugye? csak mert az tuti PC exkluzív.jah most nézem hogy be nem jelentett cím.
[ Szerkesztve ]
steam, GOG, uPlay: @petermadach || HotS: PeterMadach#2675 || Xperia 10 VI || Ultrawide & SFF masterrace || Unofficial and unpaid VXE R1 shill
-
#559
huskydog17
addikt
huskydog17
addikt
Rendkívül érdekes dolgok láttak napvilágot.
Először a hír, amely már tény:
Az AMD a VGA-k után az APU-k mellé is csomagol teljes értékű játékot. Bizonyos A8, illetve A10 APU-k mellé a legújabb SimCity játékot adják ajándékba, egyelőre azonban még kérdéses, hogy hol lehet majd ilyen központi egységekhez jutni és hogy pontosan mely modellekhez fog járni az ajándék-szoftver.Most jöjjön a nem kevésbé érdekes legfrissebb pletyka:
A Fudzilla szerint az AMD idén újabb Never Settle csomagot akar összeállítani, amihez állítólag már 2 cím be is van zsákolva. Ennek fényében a sokak által oly nagyon várt Battlefield 4 és a Ubisoft új, ütős nagyágyúja, a Watch Dogs benne lesz a csomagban, azaz Gaming Evolved címek lesznek. Ami tovább fokozza az izgalmakat, hogy állítólag egy harmadik, eddig még be nem jelentett, PC-exkluzív cím is szerepelni fog a csomagban. Erről még semmit nem tudni. Ezek az információk tehát pletykák, tessék őket fenntartással kezelni!Véleményem szerint a BF4 várható és logikus, hogy GE cím lesz, de a WD-nál már nem vagyok meggyőződve róla, bár az a játék már most brutálisan jól néz ki. A harmadik címhez pedig indulhat a találgatás. A Fudzilla nem aprózta el a dolgot és rögtön a Half-Life 3-ra tippelnek, de szerintem nem az lesz, mert ugye tudjuk, hogy a Valve nem tud 3-ig számolni.
Gameplay csatornám: https://www.youtube.com/channel/UCG_2-vD7BIJf56R14CU4iuQ
-
Yep, valóban szubjektív a dolog. Az AMD szerint normális, az meg már a felhasználó baja, ha
a) zavarja a microstutter
b) ugyanazt az eredményt kapná 1 kártyávalDe ha valakinek ez kell, hát szíve joga
Smoothing: nem látom, mi szükség lenne arra, amit írsz. ha az 1-es kártya a saját tempójában megy, akkor a 2-esnél összesen ennyire kell:
if ( time - last_flip < average_frametime ) then wait ( average_frametime - ( time - last_flip ) ) else endif
flip"We put all our politicians in prison as soon as they're elected." "Why?" "It saves time."
-
Abu85
HÁZIGAZDA
Pont az a lényeg, hogy ki szerint mi a normális. Ez marad az alapértelmezett CF mód, míg a másik csak egy kiegészítő lesz, amire át lehet kapcsolni. Az AMD továbbra is úgy gondolja, hogy ez a jó mód.
A smoothing esetén azért kell hangolni, mert ha fix értékkel tolod minden második frame számítását, akkor esély van rá, hogy rátolod a következő frame-re, és akkor lényegében nem tettél semmit. Ezért késleltet mindent a kiegyenlítés, így minden frame egyenletesen jelenik meg csak a normál AFR megoldás lagjához képest nagyobbal.
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
ja értem, hová akarsz kilyukadni. csak azt nem tetted hozzá, hogy az 1 GPU-t közelítő input lag az 1 GPU-t közelítő valódi fps-sel fog együtt járni. akkor viszont inkább kib****m a 2. kártyát a gépből
de viccen kívül, bárhová forgatod ezt a koncepciót, hülyeség jön ki belőle. magyarázhat az AMD, amit akar, ezt nagyon elközösülték. mindegy, csinálják meg normálisan, és akkor a múlt már a kutyát nem fogja érdekelni.a smoothing dolog így sántít, mert kell magát hangolnia aszerint, hogy az átlagos megjelenítés gyorsabb vagy lassabb. de mindegy, ezen felesleges vitatkozni, legyen amit mondasz, +10-15ms / frame. ennyi a normális AFR ára, pont.
"We put all our politicians in prison as soon as they're elected." "Why?" "It saves time."
-
Abu85
HÁZIGAZDA
Input lagra gyúrt AFR mellett kb. olyan lagot kapsz, mint egy GPU-val. Picit többet. Amint kész az első GPU az első frame-mel rögtön fog nekifog a harmadiknak. Ami nagyjából olyan jelenetből jön, mintha az a második lenne egy GPU-s rendszernél.
A smoothing esetében az első frame lesz normál lagos. Aztán a második egy kis eltolással lesz számolva. Ezután van két referenciaidőd, és ezekből lesz mindig számolva, hogy mekkora késleltetéssel lesznek számolva a következő páros és páratlan frame-ek, amelyeknek szintén lesz idejük, és így tovább. A cél az egyenletesség. Cserébe átlagosan 10-15 ms-os plusz lagot kapsz 60 fps mellett. Ha csak az egyik kártyát késlelteted, akkor sokszor az első kártya frame-jéből lesz kevés információ. A smoothingot általánosan kell csinálni, mindkét GPU-ra. Úgy lesz teljesen egyenletes.
(#555) Loha: De könyörgöm jelöld már ki a képen, hogy hol méri az input lagot? Én csak frame time-ot látok. A frame time != input lag!
[ Szerkesztve ]
Senki sem dől be a hivatalos szóvivőnek, de mindenki hisz egy meg nem nevezett forrásnak.
-
Loha
veterán
Az input lag tartalmazza a frame time-ot, az egyik összetevője.
Az input lag többi összetevője nem a VGA-n múlik, nem valószínű, hogy a VGA típusa befolyásolja mondjuk az egér driver vagy az USB port késleltetését.
Arra vagyok kíváncsi, hogy hány frame jelenik meg, amíg az egéren leadott parancs megjelenik?
Erre én is kíváncsi lennék, de jó esély van rá, hogy még senki nem csinált ilyen tesztet, főleg nem VGA-k összehasonlításához.Techreporton futottak bele, mert AMD-n vmiért kicsit eltért a csíkok színe, vmint egy kis zaj is volt bennük.
the extractor was having trouble because the overlay colors being displayed by the Radeon weren't entirely correct.
Szerencsére lehet állítani a toleranciát az elemző progiban, és miután lazábbra vették a probléma megoldódott.
The extractor routine had to be adjusted for looser tolerances in order to account for the variance. -
Sondi1986
addikt
itt is van egy jó SLI, CF, teszt: pcgameshardware.de
[ Szerkesztve ]
-
én azért kíváncsi lennék arra az elméleti alapra, mert a "játékosok kérték" az ilyen hangzatos buborék, különösen amiatt, amit lejjebb írtam - a runt frame-ek nem csökkentik, hanem növelik az input lagot.
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.
Ezt nem értem. Mi értelme van annak, hogy késleltetve kezdi számolni? Józan ész alapján, ha az időt kontrollálod, akkor a késleltetést a front-back fliphez praktikus tenni. És itt sem tűnik értelmesnek minden kockát késleltetni, elég az egyik kártyánál. Ne c'est pas?
"We put all our politicians in prison as soon as they're elected." "Why?" "It saves time."
-
Abu85
HÁZIGAZDA
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.
-
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""We put all our politicians in prison as soon as they're elected." "Why?" "It saves time."
-
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.
-
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.
"We put all our politicians in prison as soon as they're elected." "Why?" "It saves time."
-
p87
senior tag
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 ]
-
-
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
"We put all our politicians in prison as soon as they're elected." "Why?" "It saves time."
-
p87
senior tag
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 ]
-
Loha
veterán
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.
-
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.
"We put all our politicians in prison as soon as they're elected." "Why?" "It saves time."
-
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.
-
Loha
veterán
É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. -
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.
-
Loha
veterán
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 ]
-
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.
-
Loha
veterán
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. -
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.
-
Loha
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
É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.
-
Loha
veterán
-
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.
-
Loha
veterán
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... -
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.
-
Loha
veterán
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
-
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.
-
Loha
veterán
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 ]
-
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.
-
Loha
veterán
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.
-
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.
-
#519
Loha
veterán
Whit3Rav3n
#518
Loha
veterán
válasz
Whit3Rav3n
#518
üzenetére
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... -
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.
"We put all our politicians in prison as soon as they're elected." "Why?" "It saves time."
-
Abu85
HÁZIGAZDA
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.
-
TTomax
félisten
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"
-
-
#511
Abu85
HÁZIGAZDA
Whit3Rav3n
#510
Abu85
HÁZIGAZDA
válasz
Whit3Rav3n
#510
üzenetére
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.
-
Abu85
HÁZIGAZDA
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.
-
TTomax
félisten
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"
-
-
Locutus
veterán
É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
-
#505
Abu85
HÁZIGAZDA
Whit3Rav3n
#504
Abu85
HÁZIGAZDA
válasz
Whit3Rav3n
#504
üzenetére
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.
-
#504
Whit3Rav3n
senior tag
Abu85
#495
Whit3Rav3n
senior tag
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.
-
Abu85
HÁZIGAZDA
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.
-
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."We put all our politicians in prison as soon as they're elected." "Why?" "It saves time."
![;]](http://cdn.rios.hu/dl/s/v1.gif)
), akkor azt írnám, hogy marhára nem érdekel, oldják meg...
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?
, de azért lazán kapcsolódik a multi-GPU témakörhöz.
Ú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.
- Rezsicsökkentés, spórolás (fűtés, szigetelés, stb.)
- Politika
- eBay-es kütyük kis pénzért
- Gyúrósok ide!
- Háztartási gépek
- Autós topik
- Villanyszerelés
- Békéscsaba és környéke adok-veszek-beszélgetek
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Energiaital topic
- További aktív témák...
Állásajánlatok
Cég: Axon Labs Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest