Stuttering w benchmarkach - zmiany metod pomiarowych

[_KaszpiR_]

Ogólni artykuł jest nakierowany na AMD, ale jest bardzo dobry, bo tak naprawde dotyczy wszystkich producentow kart grafinczych.

http://www.anandtech.com/show/6857/amd-stuttering-issues-driver-roadmap-fraps

Warto przeczytac.

 

Do tego jeszcze:

http://www.pcper.com/reviews/Graphics-Cards/Frame-Rating-New-Graphics-Performance-Metric

http://www.pcper.com/reviews/Graphics-Cards/Frame-Rating-Part-2-Finding-and-Defining-Stutter

http://www.pcper.com/reviews/Graphics-Cards/Frame-Rating-Part-3-First-Results-New-GPU-Performance-Tools

 

Icing on the cake:

http://www.pcper.com/reviews/Graphics-Cards/Frame-Rating-Dissected-Full-Details-Capture-based-Graphics-Performance-Testin

 

http://www.anandtech.com/show/6862/fcat-the-evolution-of-frame-interval-benchmarking-part-1

Edytowane 27 Marca 2013 przez _KaszpiR_

[HeatheN]

Oddzielny komputer do mierzenia klatek i droga karta :o

400mb danych na sek....

Hmmm to się raczej nie sprawdzi.

2-3 karty do porównania w 5-6 tytułach= tygodnie roboty.

 

Stuttering....to tak jak cholera z green ghostingiem na plazmach...:D

Do póki nie wiesz na co patrzeć, to tego nie widzisz, jak ktoś ci to pokaże...to jest tragedia.

Mi stuttering przeszkadza, ale qmpel tego nie dostrzegał dopóki mu nie pokazałem i wytłumaczyłem:D od tamtej pory ma wielki żal:D

Żył człowiek ze świadomością że ma 60 fps...a tu mu nagle świat do góry nogami wywrócili i zaczął dostrzegać "lagi"

Na PPC też zapowiadali jakieś zmiany w metodyce pomiarowej, ciekawe.

Ale min fps, średni fps to wystarczy, by móc coś o płynności powiedzieć. Stuttering nie każdy widzi, NIE ZAWSZE występuje.

Zaczniemy to analizować do poziomu na którym program/wykresy coś pokazują, a nasz wzrok nie (mózg nadrabia:D?)

[_KaszpiR_]

Sprawdzi sie, bo wiele serwisow zmienia metodologie mierzenia klatek.

Najprostszy przyklad FRAPS pokazujacy klatki jak nie nagrywa i nagrywa. W niektorych tytulach wlaczenie nagrywania DRAMATYCZNIE obniza ilosc FPS w porownaniu z nie nagrywanym materialem.

Roznica wynika wlasnie z faktu, ze jak nagrywasz to siegasz do buforwa klatki po wyrenderowaniu, a to pokazuje ile realnie sie czeka na wygenerowanie klatki.

 

O ile karta do capuringu troche bedzie kosztowac, o tyle wiecej kasy i czasu trzeba bedzie poswiecic na zakup softu do testowania. Na pewno czesc rzeczy da sie zautomatyzowac - np analize kolorowych paskow na obrazie wyjsciowym.

 

Co do stutterringu, jest to bardzo indywidualna sprawa, ale mysle, ze jak sie komus wyjasni w czym problem (vide Twoj kolega), to jednak jest to potem zauwazalne.

 

Dodatkowo taki testbed swietnie sie nadaje jako analiza input laga np myszek itd, oraz bedzie nadzwyczaj uzytecznie w zdefiniowaniu parametrow jakie nalezy ustawic aby dostosowac przyjemnosc z gry do np czasu reakcji.

Wiadomo, ze dodawanie kolejnych buforow polepsza odbior grafiki (np tripple buffering itd), ale kosztem opoznienia.

[HeatheN]

Ja nie neguję nowej techniki pomiarowej:) bo w końcowym rozrachunku czytelnik otrzymuje wynik czarno na białym:), brudną robotę odwali portal:P

To nowe podejście, da ciekawe wnioski i wyniki

 

Sam jednak w 90% czasu (a nie uważam się za laika komputerowego) patrząc na słupki przy testach GPU, analizuję średni i minimalny FPS by móc, porównać która karta jest wydajniejsza i to w 100% wystarczy do tego by kupić lepszą.

Sam FRAPSA nie używam, (wolę Afterburner) z przyczyn o których sam wspomniałeś.

 

Co z tego że w niektórych tytułach FRAPS bruździ...są tytuły z wbudowanym benchem, wtedy nawet frapsa nie trzeba używać.

Ani razu przy aktualnej metodyce nie kupiłem karty która okazała sie wolniejsza.

A boje się nowej techniki pomiarowej:D jeszcze odkryją coś o czym nie wiem/nie zwracałem na to uwagi i dopiero będzie buba, wtedy zamiast grać będę jak psychol siedział w sterach i kombinował, lub co tydzień wymieniał kartę.

[_KaszpiR_]

:)

Wiesz, ja miedzy innymi przestalem podkrecac moja GTX 680 - jakiekolwiek zmiany zegara powodowaly ze juz dostawala bzika, bo jest na krawedzi stabilnosci. Nie chce mi sie szukac, czy a nuz uda sie ja jeszcze podkrecic o 50MHz - ja juz za stary jestem. W pewnym momencie czlowiek szuka stabilnosci, i nie ma czasu na walke zeby cos dzialalo, szczegolnie jak jest w domu.

 

Z drugiej strony sa pewne rzeczy, na ktore jestem nadzwyczaj wyczulony, i np pewne aplikacje pokazuje ze 'wszystko ok, masz 100 klatek', ale jakos wizualnie wychodzila z tego kupa i wiedzialem, ze cos jest nie tak.

 

Wiadomo, ze nowe metody pomiarowe niosa ze soba 'ryzyko', ze znowu cos znajda i czlowiek nie bedzie spal po nocach. Ale to tez trzeba samemu sobie odpowiedziec na pytanie - czy akceptuje te niedoskonalosci i czy chce spac spokojnie? Czy jednak jestem psycholem i będę walczył o kazda klatke, nawet tę, ktora jest renderowana jako 3 poziome piksele? ;)

 

Jedno jest pewne, nowe metody pomiarowe uswiadamiaja nam w czym tkwi problem, przynajmniej wiemy co nas gryzie ;)

 

Mnie nowe testy najbardziej interesuja z tego punktu, gdyz zaczalem sie interesowac SLI. Wczesniej slyszalem o stutteringu w SLI - ale wiadomo, jak sie czegos nie posiada, to czlowiek nie jest swiadom plusow i minusow danego rozwiazania. Tutaj jednak te nowe metody pomiarowe dadza nam namacalne, mierzalne wartosci chociazby w postaci rozrzutu FPS. W ostatecznym rachunku przyda sie to zarowno ludziom zastanawiajacym sie nad kupnem jednej karty, czy kilku, ale takze bezposrednio zmusi producentow kart graficznych do kontynukacji pracy nad sterownikami (vide AMD).

 

dorzucilem 2 linki w pierwszym poscie.

Edytowane 27 Marca 2013 przez _KaszpiR_

[radiergummi]

Challenging FPS: Testing SLI And CrossFire Using Video Capture

[_KaszpiR_]

Pozwolę sobie wykopać trupa, bo.. ON ŻYJE!

 

http://www.purepc.pl/karty_graficzne/fcat_vs_fraps_porownanie_metod_testowania_kart_graficznych

 

A realnie, to Caleb jeszcze nie zrobił tematu/postu z linkiem do artykułu, a mam do niego kilka uwag i nie chcę pisać w komentarzach.

 

1. Przydałoby się jakby artykuł dokładniej opisywał co się dzieje na wykresach - trzeba pobawić się statystyką.

Brakuje na przykład opisu jak interpretować wykresy procentowej wydajności kart graficznych.

Najlepiej nadaje się do tego wykres ze Skyrim:

 

 

Chodzi po to jak bardzo pozioma jest linia oraz jak mocno zakręca w górę przy końcu wykresu.

 

Ogólnie wykres zależy od wybranych scen i ich złożoności i renderowania i tak:

- najlepiej jak linia jest jak najbardziej pozioma, oznacza to, że czas generowania sceny jest stały

- im niżej linia tym lepiej, oznacza to, że scena jest renderowana szybciej

- im wcześniej linia zaczyna iść na prawo ku górze, tym większe szanse, że sceny są nierówno renderowane. Skrajny prawy fragment oznacza ilość klatek długo renderowanych, i może oznaczać znaczące FPS drop w scenie.

- im bardziej łagodne przejście na końcu tym lepiej, bo gra ma mniej scen z FPS dropami.

- ważna jest wysokość słupa na prawo - pokazuje jak duże są to dropy, sugerowane jest aby był jak najniższy.

 

Patrząc na wykres Skyrima dla karty AMD widać, że w wybranej procedurze testowej co najmniej 15% klatek renderuje się powyżej 11ms. Ponieważ aby mieć 60FPS trzeba mieć jakieś 16ms na renderowanie klatki, można uznać, że przy tych ustawieniach gry renderuje ona ponad 60 klatek.

 

 

2. Liczba FPS z FRAPS vs liczba FPS w FCAT

Nie widzę jak dokładnie były liczone te wartości - prosiłbym o wyjaśnienie.

Zakładam, że FRAPS sumuje wszystkie klatki i wyciąga średnią.

Pytanie czy FCAT tak samo liczy, czy też odrzuca klatki nie w pełni renderowane?

Jesli liczy też klatki nie wpełni renderowane, to nic dziwnego, że wyniki są podobne. Uważam, że warto byłoby przedstawić wartości średnie dla 95% klatek (odrzucając skrajne przypadki).

 

 

3. Stuttering

FCAT świetnie się do tego nadaje, jeśli liczymy wszystkie klatki i przedstawimy na wykresie w czytelny sposób.

Idealnie nadaje się do tego wykres z BF4 i karta nVidii:

 

 

Widać na nim jak na nVidii są piki, a AMD radzi sobie znacznie lepiej.

Można by ten wykres przedstawić inaczej - jak pas sumujący klatki z okresu 1s i prezentującego różnicę między czasami renderowania poszczególnych klatek.

Pewnie jeszcze lepiej wyszło by to w Crysisie 3, bo tam wykres jest cały gruby od różnic w renderowaniu.

 

 

Ogólnie im węższy pasek czerwony albo zielony, tym lepiej, bo różnica w czasach rysowania jest mniejsza.

 

4. Na wykresach nie widać linii Runts i Drops.

Ach czemu! Śmiem twierdzić, że na wykresach brakuje danych, bo nie chce mi sie wierzyć aby ich nie było. Może wyrysowano dane po odrzuceniu tych danych?

 

Są to kluczowe elementy na wykresie jasno pokazujące płynność generowania grafiki - im więcej klatek częściowych i dropowanych, tym mniej płynnie się gra.

 

5. Brakuje złożenia wykresu FRAPS vs FCAT (razem z runts i drops).

Prawdopodobnie widać byłoby różnicę po zmianie zakresu osi, czyli zzoomowaniu do zakresu +/-10FPS

Nie wiem jednakże, czy da się wygenerowac dane z FRAPSa w taki sposób, aby zapisal czas klatki do pliku csv. do tego trzbea by zsynchronizować czas wyświetlenia klatki FRAPSa z momentem złapania jej przez kartę, aby nie było przesunięcia w fazie.

Edytowane 5 Lutego 2015 przez _KaszpiR_

[Caleb]

A realnie, to Caleb jeszcze nie zrobił tematu/postu z linkiem do artykułu, a mam do niego kilka uwag i nie chcę pisać w komentarzach.

Od tego są komentarze pod artykułami, na forum zaglądam rzadziej, ale niech będzie. A tak poza tym, Kaszpir, kopę lat :> 

 

 

1. Przydałoby się jakby artykuł dokładniej opisywał co się dzieje na wykresach - trzeba pobawić się statystyką.

Brakuje na przykład opisu jak interpretować wykresy procentowej wydajności kart graficznych.

Najlepiej nadaje się do tego wykres ze Skyrim:

Można dodać, w sumie nawet to co napisałeś w punktach jako rozwinięcie myśli.

 

 

2. Liczba FPS z FRAPS vs liczba FPS w FCAT

Nie widzę jak dokładnie były liczone te wartości - prosiłbym o wyjaśnienie.

Zakładam, że FRAPS sumuje wszystkie klatki i wyciąga średnią.

Pytanie czy FCAT tak samo liczy, czy też odrzuca klatki nie w pełni renderowane?

Jesli liczy też klatki nie wpełni renderowane, to nic dziwnego, że wyniki są podobne. Uważam, że warto byłoby przedstawić wartości średnie dla 95% klatek (odrzucając skrajne przypadki).

 

FCAT wypluwa pliki .csv gdzie są podane wszystkie dane, również średnią ich ilość podobnie jak we FRAPS-ie. W tym zawierają się klatki odrzucone i niepełne, ale żaden pomiar ich nie wykazał. 

 

 

Ogólnie im węższy pasek czerwony albo zielony, tym lepiej, bo różnica w czasach rysowania jest mniejsza.

No raczej. 

 

 

4. Na wykresach nie widać linii Runts i Drops.

Ach czemu! Śmiem twierdzić, że na wykresach brakuje danych, bo nie chce mi sie wierzyć aby ich nie było. Może wyrysowano dane po odrzuceniu tych danych?

Te zjawiska nie występowały na pojedynczych kartach. W SLI/CF wywaliło już kolorowe wykresy. 

[_KaszpiR_]

Hm, ostatni punkt.
Edit: w sumie sam sobie odpowiedziałem.
Dziwi mnie, że nie ma runts/drops na jednej karcie. Trzeba się dokładniej przyjrzeć czasom renderowania klatek.
W SLI/CF ten efekt pewnie sę nasila, jak pokazują artykuły w linkach w pierwszym poście.

Dropowanie można zaliczyć raczej do mega spowonienia w renderowaniu. Czyli de facto nie ma dropowania na jednej karcie graficznej tylko grafika nie nadąża z generowaniem obrazu.

Tpowy drop w SLI oznacza, że dana klatka została wygenerowana, ale nie została wyświetlona, bo została zastąpiona następną.

Runts, czyli te co są rysowane do 20px raczej nie będą miały miejsca z powodu wydłużonego czasu renderowania. Przy jednej karcie po prostu nie ma czasu. Jedyny moment kiedy wydaje mi sie, ze to moze wystepowac to jak jest bardzo dziwna zmiana scen - gdzie dosłownie zmienia sie to co widac co drugą trzecią klatkę (np powiedzmy padające obiekty tuż przez kamerą, które potrafią zasłonic cały ekran, wtedy gra by musiała wyrenderować najbliższy obiekt, a analizując zbuffer okazałby sie ze wszystko inne jest zasłonięte, więc renderujemy bardzo mało, bo np szary kwadrat). Ale takich scen w grach raczej nie uświadczysz.

To oznacza, ze jak mamy SLI/CF to mamy typowy race condition - dlatego się zdarzają sytuacje, że jakaś klatka nie jest rysowana albo rysowana jest fragmentarycznie. Wtedy chyba jedyną nadzieją jest jakies przewidywanie renderowania sceny (vide pre-render 3 klatek w DirectX), albo jakis vsync.
Ale to zależy zarówno do silnika gry, jak i sterów i dodatkowych ustawień.

 

Czyli Fraps pokazuje 110 FPS, ale efekt a ekranie może być taki, jakbyśmy mieli 55 klatek ;)

Ciekawe jak Gsync działa ze SLI....

Edytowane 5 Lutego 2015 przez _KaszpiR_