ArmA Memory / HDD Test - Runda druga!
Tak więc. Od czasu poprzedniego testu wykorystania przez ArmA pamięci i twardego dysku już troche czasu mineło. Wyszły już patche 1.04, 1.05 i 1.05+ który daje "największy" komfort gry w Armed Assault.
Zauważył to napewno każdy, ja też tak więc postanowiłem się temu przyjżeć. Tym razem nie będzie screenów z gry i everesta, ale tylko wykresy z Riva Tuner, każdy przecież wie jakie cyrki potrafi odstawić ArmA, prawda?
Sprzęt się nie zmienił, no może poza większym podkręceniem grafiki i zmiany sterowników na nowsze:
AMD Athlon 64 3500+ @ 2750 Mhz, Colled by ThermalTake BigTyphoon 4 in 1
Abit KN9
OCZ Technology 2x 512MB DDR2 800 @ 916 Mhz Platinium CL4 4-5-4-15
WD Caviar SE-16 WD2500KS
Galaxy GeForce 7900GS 256MB 256Bit 630/1756 Zalman Edition 1.2ns
Topower 420W P7 U12 EZ
Wersja sterowników kart graficznej:
97.92
Wersja Armed Assault:
1.05+
System operacyjny:
Windows XP Proffesional SP2
Ustawienia:
Wszystko na Bardzo wysoko, post efekty wyłączone, cienie wyłączone, AA Wysoko.
Zmieniła się też procedura testowa, na nieco "mniej zaawansowaną"
. Mianowicie było to latanie helikopterem po Sahrani, przeloty nad dużymi miastami, lasami, rozbijanie się w dużych i gęstych lasach, strzelanie i inne metody pozwalające na "zawalenie" ekranu grafiką.
Ku mojemu ździwieniu ArmA ruszyła z kopyta. Poprzednio na Windows Vista, naprawde wszystko dość się wlekło, po 10 minutach jazdy hummerem po drogach wszystko zaczynało przeskakiwać. Tak samo było z helikopterami. A teraz pomimo dzikich wyczynów w powietrzu gra utrzymywała dość stabilną płynność gry.
Popatrzmy na wykresy:
Kliknij, aby powiększyć!
Tutaj nie ma nic specjalnego. Prezentacja podkręcenia kary graficznej. Na poprzednich taktach i sterownikach było 620/1710 (855) i potrafiło przyciąć. Być może, głównie z tego powodu, że geometria w ArmA jest dość zrypana. Widać to po "dalszych" LOD'ach, podczas wycieku pamięci. Te kilka Mhz więcej, czyli +10 = 630, na "urządzeniach" odpowiadających za przetwarzanie i generowanie geometry jest to zawsze więcej, tutaj mamy 648. Teraz Armed Assault ma już mniejsza tendencje do niespodziewanych zaciachów. To by też wyjaśniło uległość ArmA wobec 8800GTX, tam bodaj na rdzeniu jest +700Mhz i odpowiednio więcej dla Geometry domain. No, ale przejdźym dalej...
Kliknij, aby powiększyć!
Tu już jest nieco ciekawiej. FPS, taktowanie CPU, wykorzystanie CPU i pamięć fizyczna RAM.
FPS skakało od 21 do 38 klatek, to każdy widzi. Taktów procesora też nie trzeba tłumaczyć. Zobaczmy jego wykorzystanie. Maksymalnie to oczywiście 100%, ale przy mniejszym obciążeniu spadało do 50-40%. Trzeba zwrócić uwagę, że procesor posiada jeden rdzęn, ale nie wiem czy na dwu-rdzeniowym byłoby lepiej. Armed Assault nie jest "aplikacją" dwu-wątkową i chociaż "niby" proces byłby rozłożony na dwa rdzenie to i tak byłyby one wykorzystywane jako jeden. Troche dziwne, ale to prawda...
Wykorzystanie pamięci fizycznej wacha się w granicach 900-1000 MB. W poprzednim teście było to 913 MB, lecz pamięć ciągle pękała w szwach od nieustannie wczytywanych plików. Tutaj wykorzystanie zasobów utrzymuje się na mniej więcej równym poziomie. Nareszczie Armed Assault "zauważa" ile mamy pamięci do dyspozycji i nie próbuje upchać w niej dodatkowych plików. Poprzednio było tak, iż gra "waliła" do pamięci wszystko co było pod "ręką", a to skutkowało "przepchaniem" pamięci RAM tak, że nie było już miejsca na geometrię gry. Stąd kartonowy świat.
Przejdźmy dalej...
Kliknij, aby powiększyć!
Mamy tu użycie pliku stronicowania i lokalną, a także nielokalną pamięć VRAM, czyli karty graficznej. Zacznijmy od pierwszej pozycji.
Plik stronicowania to nic innego jak pamięć wirtualna, czyli miejsce na twardym dysku przeznaczone do wykorzystania jako wirtualna pamięć RAM. U mnie na ten cel jest przeznaczone 1500-3000 MB. Jak widać, minimalne użycie pliku stronicowania to ~1200 MB, a maksymalne ~1300. Tyle pamięci brakuje do płynnej gry, dlatego też jest wykorzystywana pamięć wirtualna. W poprzednim teście chyba tego nie sprawdziłem. Aczkolwiek, chyba ta pamięć była wykorzystywana w mniejszym stopniu. Nie ważne. Ważne jest to, że poprzednio dysk mielił niemiłosiernie, a teraz było dość cicho.
Videomemory i Local Videomemory usage to dokładnie to samo. Widzimy, że pamięć karty graficznej (VRAM [Video Ram]) jest wykorzystywana maksymalnie, minimalna wartość użycia tej pamięci to 210 MB.
Non-Local Videomemory usage to użycie NIE LOKALNEJ pamięci VRAM. Czyli nie znajdującej się na karcie graficznej. Jest to ilość wykorzystanej pamięci RAM zaporzyczonej aby wspomóc karte graficzną. Wartość tą można zmieniać w BIOS. Jak widzimy wartość ta wacha się w granicach ~270 - ~370 MB. Tyle pamięci RAM jest przekazywane do dyspozycji karcie graficznej. I być może o tyle więcej powinna mieć karta do w pełni płynnego działania Armed Assault.
Porównując to z poprzednim testem można wywnioskować, że: Kiedy ArmA zapchała pamięć RAM, zaczeła pchać pliki w VRAM i Virtual Memory (stąd też mielenie dysku), kiedy i tego zaczeło braknąć, po przepchaniu VRAM'u system "na siłe" przydzielał karcie graficznej "porcje" pamięci z RAM. Czyli powiedzmy -300MB z RAMu na rzecz VRAM'u. Dane, które zostały dosłownie wykopane z RAM, czyli powiedzmy tekstury i geometria (co powodowało tzw. "Kartonowy ¦wiat"), musiały zostać gdzieś upchnięte. Gdzie? Oczywiście w Virtual Memory. Dlatego czasami Alt + Tab pomagało. Ale kiedy i Virtual Memory brakło... Wszystko było oczywiste. System musiał się jakoś odciążyć, a jak? CTD, SOD, Reset, błąd typu STOP itd...
W tej chwili jest już lepiej, bo powiedzmy, że ArmA "widzi" ile jest miejsca w szafie i nie pcha tam więcej niż może, a to przekłada się na kolejne czynniki, nie przepchania VRAMu itd. Lecz jeszcze czasami może się zdażyć tak, że z szafy znów coś się wysypie. No cóż, miejmy nadzieję, że patch 1.06 czy 1.07 zrobi z ArmA jeszcze bardziej grywalną grę.
IMO jak narazie wszystko idzie w dobrym kierunku.
Dziękuję za uwagę.
Linki zewnętrzne
Plik wymiany (Virtual Memory) - Co to jest i jak działa?
VRAM - Co to jest?
User of this number is currently dead. Resurrection in 5 minutes, please wait.