Forum Debian Users Gang

NIC · 2010-07-19 14:17:07

Ja mam Mesę 7.8.2 i jądro 2.6.34.1 takich wyników nie osiągam..

Running synchronized to the vertical refresh. The framerate should be
approximately the same as the monitor refresh rate.
339 frames in 5.0 seconds = 67.589 FPS
339 frames in 5.0 seconds = 67.716 FPS
337 frames in 5.0 seconds = 67.396 FPS

Co ciekawe normalnie to mam 30 lub 58... Przy 67 kółeczka kręcą w zasadzie płynnie. Być może przysłowiowo maszyna musi się najpierw rozgrzać by wyniki były takie jakie powinny (bzdura, tak nie było wcześniej)

Mesy 7.8.0 jako jedynej nie miałem (bo to ponoć nie jest stabilna-stabilna). Ale może to sprawka nowego jądra? Sprawdzałeś na innym niż to niestabilne jąderko?

PS. Oczywiście synchronizacji nie da się wyłączyć u mnie. Jak się przegląda internet to takie coś nie tylko ja mam. Ale czemu Ty masz lepiej? :)

PS 2. Aha, i jeszcze nas wersja xservera i spółki równi, tak? Ale to chyba nie powinno mieć większego wpływu....

PS 3. Jest gdzieś dostępna informacja jak debianowcy kompilują te pakieciki? Konkretnie wykaz flag ./configure by był jak znalazł. (coś jak LFS zapodaje: http://www.linuxfromscratch.org/lfs/view/developmen … 06/glibc.html)

//-------------------------
Zauważyłem, że gdy:

Kod:

glxgears; xset dpms force suspend

To zdaje się że VBlank znika (obraz oczywiście też), bo normalnie mam

Kod:

225 frames in 5.0 seconds = 44.626 FPS
225 frames in 5.0 seconds = 44.914 FPS
230 frames in 5.0 seconds = 45.831 FPS
223 frames in 5.0 seconds = 44.517 FPS
133 frames in 61.9 seconds =  2.149 FPS   # tu załączamy suspend ekranu
2572 frames in 5.0 seconds = 514.349 FPS
2703 frames in 5.0 seconds = 540.527 FPS
2593 frames in 5.0 seconds = 518.565 FPS
2661 frames in 5.0 seconds = 531.256 FPS
2598 frames in 5.0 seconds = 519.553 FPS
2681 frames in 5.0 seconds = 536.074 FPS

Fajne nie?

Ostatnio edytowany przez NIC (2010-07-19 15:38:16)

sal_i · 2010-07-19 20:17:18

Niech dobrze zrozumiem. Nowa mesa 7.8 synchronizuje ilość fps z częstotliwością odświeżania. Logicznym powodem jest fakt że niezależnie ile klatek na sekundę wygeneruje gpu to ekran odświeży się tylko te 60 (albo ile tam jest ustalone) razy. W takim razie pogoń za milionem FPS jest bez sensu bo i tak dodatkowe klatki zostaną zgubione gdzieś między jednym Hz'em a drugim.
Czy dobrze myślę?

NIC · 2010-07-20 11:30:43

By obraz był płynny to przynajmniej 120 klatek przy odświeżaniu 60 Hz powinno być. Chyba normalne odświeżanie to 75 Hz więc tak 180 FPS by się przydało. Moje rozumienie jest na podstawie elektroniki* i tamtejszego prawa...

Ludzkie ucho słyszy dźwięki do częstotliwości około 20 kHz. Według twierdzenia Kotielnikowa-Shannona, częstotliwość zapisu cyfrowego musi być zatem większa niż 40 kHz, aby nie dało się usłyszeć przekłamań (tzw. częstotliwość Nyquista). Stąd 44 100 próbek na sekundę (44,1 kHz) dla każdego kanału, na płycie CD-Audio przyjęto za wartość wystarczającą.
(źródło - wikipedia)

-------------------------------------

Swoją drogą jest jeszcze coś takiego jak intel-gpu-tools, też można użyć tego do testów kontrolnych:

Kod:

bash-4.1# intel_stepping
Vendor: 0x8086, Device: 0x27ae, Revision: 0x03 (??)

bash-4.1# intel_upload_blit_large
200 iterations in 3.084 secs: 228.0 MB/sec
bash-4.1# intel_upload_blit_large
200 iterations in 3.025 secs: 232.5 MB/sec

bash-4.1# intel_upload_blit_small
1000 iterations in 2.706 secs: 46.2 MB/sec
bash-4.1# intel_upload_blit_small
1000 iterations in 2.620 secs: 47.7 MB/sec

bash-4.1# intel_upload_blit_large_gtt
200 iterations in 2.324 secs: 302.5 MB/sec
bash-4.1# intel_upload_blit_large_gtt
200 iterations in 2.310 secs: 304.4 MB/sec

bash-4.1# intel_upload_blit_large_map
200 iterations in 3.069 secs: 229.1 MB/sec
bash-4.1# intel_upload_blit_large_map
200 iterations in 3.188 secs: 220.5 MB/sec

# choć to pewnie zależy od szybkości RAMu, ale RAMy aż tak bardzo się nam nie różnią...

sal_i · 2010-07-20 11:52:48

Ciekawe czemu developerzy ustawili synchronizację fps z odświeżaniem w stosunku 1:1 zamiast 1:2.

iria · 2010-07-28 20:05:30

Wybacz NIC, że po takim czasie odpisuję, ale byłem zabiegany.
W tym czasie pojawiło się nowe rc jajka 2.6.35 i przyniosło sporo stabilizacji dla naszych kart.

Popełniliśmy najprostszy błąd, czyli nie uzgodniliśmy metodologii pomiarów. Niech zgadne... robiłeś wszystkie testy z włączonymi efektami w kwin?;)

Tu masz rozpiskę testów, które przeprowadziłem z różnymi kernelami, mesami i wł/wył efektami w kwin:

Kod:

2.6.34-sidux, mesa 7.7.1, kwin bez efektów

x11perf -putimage500    4000 reps @   1.2490 msec (   801.0/sec): PutImage 500x500 square
x11perf -aaftext    6400000 reps @   0.0008 msec (1270000.0/sec): Char in 80-char aa line (Courier 12)
x11perf -oddostrap300    6000 reps @   0.8860 msec (  1130.0/sec): Fill 300x300 opaque stippled trapezoid (17x15 stipple)
glxgears        2954 frames in 5.0 seconds = 590.697 FPS


2.6.34-sidux, mesa 7.7.1, kwin z efektami

x11perf -putimage500    1600 reps @   3.2905 msec (   304.0/sec): PutImage 500x500 square
x11perf -aaftext    5600000 reps @   0.0009 msec (1070000.0/sec): Char in 80-char aa line (Courier 12)
x11perf -oddostrap300    6000 reps @   1.0301 msec (   971.0/sec): Fill 300x300 opaque stippled trapezoid (17x15 stipple)
glxgears        2052 frames in 5.0 seconds = 410.223 FPS


2.6.34-sidux, mesa 7.8.2, kwin bez efektów

x11perf -putimage500    8000 reps @   1.2972 msec (   771.0/sec): PutImage 500x500 square
x11perf -aaftext    6400000 reps @   0.0008 msec (1270000.0/sec): Char in 80-char aa line (Courier 12)
x11perf -oddostrap300    6000 reps @   0.8851 msec (  1130.0/sec): Fill 300x300 opaque stippled trapezoid (17x15 stipple)
glxgears        4480 frames in 5.0 seconds = 892.396 FPS


2.6.34-sidux, mesa 7.8.2, kwin z efektami

x11perf -putimage500    1600 reps @   3.3853 msec (   295.0/sec): PutImage 500x500 square
x11perf -aaftext    5600000 reps @   0.0010 msec (1050000.0/sec): Char in 80-char aa line (Courier 12)
x11perf -oddostrap300    6000 reps @   1.0395 msec (   962.0/sec): Fill 300x300 opaque stippled trapezoid (17x15 stipple)
glxgears        3073 frames in 5.0 seconds = 614.427 FPS

2.6.35rc6, mesa 7.7.1, kwin bez efektów

x11perf -putimage500    8000 reps @   1.1538 msec (   867.0/sec): PutImage 500x500 square
x11perf -aaftext    6400000 reps @   0.0008 msec (1260000.0/sec): Char in 80-char aa line (Courier 12)
x11perf -oddostrap300    6000 reps @   0.8772 msec (  1140.0/sec): Fill 300x300 opaque stippled trapezoid (17x15 stipple)
glxgears        3011 frames in 5.0 seconds = 602.196 FPS


2.6.35rc6, mesa 7.7.1, kwin z efektami

x11perf -putimage500    1600 reps @   3.7197 msec (   269.0/sec): PutImage 500x500 square
x11perf -aaftext    5600000 reps @   0.0009 msec (1070000.0/sec): Char in 80-char aa line (Courier 12)
x11perf -oddostrap300    6000 reps @   1.0282 msec (   973.0/sec): Fill 300x300 opaque stippled trapezoid (17x15 stipple)
glxgears        1988 frames in 5.0 seconds = 397.437 FPS


2.6.35rc6, mesa 7.8.2. kwin bez efektów

x11perf -putimage500    8000 reps @   1.1477 msec (   871.0/sec): PutImage 500x500 square
x11perf -aaftext    6400000 reps @   0.0008 msec (1260000.0/sec): Char in 80-char aa line (Courier 12)
x11perf -oddostrap300    6000 reps @   0.8782 msec (  1140.0/sec): Fill 300x300 opaque stippled trapezoid (17x15 stipple)
glxgears        4463 frames in 5.0 seconds = 891.935 FPS


2.6.35rc6, mesa 7.8.2, kwin z efektami

x11perf -putimage500    1600 reps @   3.5753 msec (   280.0/sec): PutImage 500x500 square
x11perf -aaftext00    5600000 reps @   0.0009 msec (1080000.0/sec): Char in 80-char aa line (Courier 12)
x11perf -oddostrap300    6000 reps @   1.0171 msec (   983.0/sec): Fill 300x300 opaque stippled trapezoid (17x15 stipple)
glxgears        2527 frames in 5.0 seconds = 505.235 FPS

Tak jak mówiłem u mnie nie ma synchronizacji domyślnie włączonej, Zauważyłem, że przy mesie 7.8.2 i z włączonymi efektami kwin, kółka w glxgears kręcą się płynnie...niestety test w stellarium wykazał, że grafika nadal "rwie". Nie mam pojęcia co jest tego przyczyną.

Co do testów intel-gpu-tools, oto moje:

intel_stepping
Vendor: 0x8086, Device: 0x27a2, Revision: 0x03 (A3)

intel_upload_blit_large
200 iterations in 1.826 secs: 385.0 MB/sec

intel_upload_blit_small
1000 iterations in 1.383 secs: 90.4 MB/sec

intel_upload_blit_large_gtt
200 iterations in 1.154 secs: 609.5 MB/sec

intel_upload_blit_large_map
200 iterations in 1.175 secs: 598.6 MB/sec

Przeprowadzone na jajku 2.6.35rc6, mesie 7.8.2, i z włączonymi efektami, choć to pewnie nie ma większego wpływu.

Najchętniej pozbył bym się tego "rwania" przy nowej mesie.

Ostatnio edytowany przez iria (2010-07-28 20:06:08)

Huk · 2010-07-28 22:12:34

Sorry za offtop ale słowo wyjasninia:

@NIC:

By obraz był płynny to przynajmniej 120 klatek przy odświeżaniu 60 Hz powinno być. Chyba normalne odświeżanie to 75 Hz więc tak 180 FPS by się przydało. Moje rozumienie jest na podstawie elektroniki* i tamtejszego prawa...

Nie, nie i jeszcze raz nie - całkowicie przestrzeliłeś to porównanie. Prawo Kotielnikowa-Shannona nie odnosi się do ludzkiego ucha tylko do błędów dyskretyzacji, zapis cyfrowy ma po prostu to do siebie że musi być zawsze tworzony z podwójnym próbkowaniem aby była możliwość odtworzenia próbkowania oryginalnego - stąd, jak nagrywamy coś w 44100 Hz to po przepuszczeniu przez dekodery usłyszymy dźwięk w 22500 Hz - to nie wynika z budowy ucha, a z techniki dyskretyzacji. Odnośnie ekranu te prawa nie mają żadnego zastosowania - ludzkie oko potrafi przełapać (w zależności od źródła) 45-100 "klatek/s" , przy czym większość źródeł jakiś czas temu podawała 60 jako najbardziej zbliżoną liczbę - z tego względu różnicy pomiędzy 120 a 60 się praktycznie nie zobaczy, zresztą odpal sobie GLXGears przy włączonym i wyłączonym VSync i powiedz szczerze, czy widzisz żeby płynność uległa zmianie?

Rożnicę można było zobaczyć kiedy miało się monitor CRT (przed którym obecnie siedzę ;p) i na nim tak egzotyczne odświeżanie jak 75/85 czy 100 Hz, a gra wyciągała FPS'y poniżej tej wartości. Wtedy trzeba stosować odpowiednie algorytmy dublowania klatek (bo monitor musi jakoś zapełnić te "dziury" wynikające z różnic odświeżania) które zwykle zmniejszały (nieco) płynność - ale nadal było to ledwo zauważalne (wczoraj tak stało mi się podczas grania że FPS'y w MaxPayne2 spadły do 60, a monitor był ustawiony na 85 - było widać że płynności trochę "ubyło" - ale szybko idzie przywyknąć).

Oczywiście należy brać pod uwagę że ludzie oko i mózg to nie są układy scalone - każdy ma nieco inne i nieco inaczej przetwarza obrazy - stąd będą tacy co różnice pomiędzy 60 a 120 określą jako widoczną - ale większość zapewne jej nie zauważy ;]

Tyle w kwestii off-topu

Dodam jeszcze tylko:

Dobrym narzędziem do testowania wydajności OpenGL jest GLMark:

http://sourceforge.net/projects/glmark/

Zdecydowanie lepiej pokaże czy wszystko chodzi ok, niż glxgears...

Ostatnio edytowany przez Huk (2010-07-28 22:25:41)

Forum Debian Users Gang

Ogłoszenie

#26 2010-07-19 14:17:07

NIC - Członek DUG

Re: Słaba wydajność karty graficznej (GMA 950) na netbooku

Kod:

Kod:

#27 2010-07-19 20:17:18

sal_i - Członek DUG

Re: Słaba wydajność karty graficznej (GMA 950) na netbooku

#28 2010-07-20 11:30:43

NIC - Członek DUG

Re: Słaba wydajność karty graficznej (GMA 950) na netbooku

Kod:

#29 2010-07-20 11:52:48

sal_i - Członek DUG

Re: Słaba wydajność karty graficznej (GMA 950) na netbooku

#30 2010-07-28 20:05:30

iria - Redaktor

Re: Słaba wydajność karty graficznej (GMA 950) na netbooku

Kod:

#31 2010-07-28 22:12:34

Huk - Smoleńsk BULWA!

Re: Słaba wydajność karty graficznej (GMA 950) na netbooku

Stopka forum