czwartek, 26 lipca 2012

Valve przedstawi prezentację na temat optymalizacji gier pod GNU/Linuksem

Zgodnie z planem konferencji SIGGRAPH, 8 sierpnia ma zostać przedstawiona prezentacja pod tytułem "Left 4 Dead 2 Linux: From 6 to 300 FPS in OpenGL". Głos zabierze Rich Geldreich, pracownik Valve specjalizujący się w kompresji danych i zagadnieniach renderingu w czasie rzeczywistym.

W międzyczasie polecam inne prezentacje Valve. Szczególnie warta uwagi jest prezentacja opisująca proces portowania gier na konsole.

Inne (pozostałych twórców) ciekawe lektury:

czwartek, 19 lipca 2012

Serious Sam 3 BFE został przeportowany na Linuksa

Aaaaaaaaargh yourself! Pisałem wcześniej o samym Samie jak i o jego rendererze OpenGL. Teraz jestem zmuszony zakomunikować wesołą nowinę: powstał port gry na Linuksa. Źródło to "fanpejdż" Croteam i strona G+.

Gdyby ktoś nie wiedział o czym jest Serious Sam BFE, to streszczam fabułę:
  • Sam "Serious" Stone robi sobie spacerek po Egipcie, przemycając armaty i wyrzutnie rakiet w kieszeniach,
  • anihiluje jakieś 7000 potworów z kosmosu, w tym kamikaze, którzy krzyczą nie mając głów, nagie panie-ptaki czy grubasów, którzy wpadają w furię nie mogąc zobaczyć swoich wacków,
  • i to chyba wszystko...
No, prawie. Humor jest świetny, polskie tłumaczenie (kinowe) nieocenzurowane. Rozgrywka gwarantuje wycieńczenie i Parkinsona (5-7 herców) po odejściu od klawiatury.

Mam też nadzieję, że SS3 będzie również pod Linuksem objęty Steamplay (teraz kupuje się jednocześnie wersje dla Windows i OS X). Niby oczywiste, ale nie działa np. w przypadku ID Software, gdzie chcąc grać w Rage na Maku i Windows, trzeba kupić dwa odrębne egzemplarze.

wtorek, 10 lipca 2012

Konsolka OUYA - $950 000 w kilka godzin

Na zebranie 950 000 dolarów na Kickstarterze było 30 dni. Wystarczyło kilka godzin (23:00 10.07.2012). Sukces stacjonarnej konsoli opartej na Androidzie 4 i Tegrze 3 jest oszałamiający.

OUYA jest tania (99 dolarów) i wystarczająco wydajna by uruchamiane na niej gry nie powodowały bólu oczu:) Gorzej, że Androidowe gry są na razie beznadziejne pod względem fabuły, długości rozgrywki i dostarczanych emocji. Kilka portów z PC (Max Payne czy GTA 3) nie ratuje sytuacji, No, ale poczekamy, zobaczymy...


niedziela, 8 lipca 2012

Serious Sam 3 BFE pod OpenGL/Wine

Nie ma SS3 dla Linuksa, ale Windowsowa wersja może używać OpenGL, tak jak to się dzieje w przypadku wersji na OS X. Aż się prosi o przetestowanie renderera OpenGL pod Wine. Dodatkową przyczyną pojawienia się tego wpisu są plotki o wydaniu BFE na Linuksa, po premierze Steama.
Wystarczy zmienić jeden wpis w pliku konfiguracyjnym, w przypadku wersji ze Steama: 
/home/uzytkownik/.wine/drive_c/Program Files/Steam/userdata/jakasliczba/41070/local/SeriousSam3.ini

2 to Direct3D9, 1 to OpenGL:
gfx_iAPI = 1;

Przy okazji, jeśli nie działa sterowanie:
inp_bRawInput = 0;

i jeśli są problemy z dźwiękiem (1 - OpenAL, 2 - DirectSound, 3 - XAudio):
sfx_iAPI = 2;

Sam renderer OpenGL (widoczny na zrzucie powyżej) niestety wymaga dopracowania. Dość powiedzieć, że nie oferuje wyraźnie wyższej wydajności niż Direct3D, który jest dopiero tłumaczony przez Wine na OpenGL. Mało tego, błędy wyświetlania (nawet znikające ściany) widoczne są tylko w pierwszym przypadku. Na obecną chwilę lepszym wyborem jest Direct3D+Wine niż OpenGL+Wine. Niuans: D3D nie chciał działać w oknie, OGL działał zarówno w oknie jak i na pełnym ekranie.  
W obu przypadkach ustawienie średnich detali w 1920x1080 powodowało "slideshow" 10-20 kl./s. Nie należy jednak traktować moich obserwacji dot. wydajności jako wiążących, bo gra wygląda na "CPU-limited". 


Ważne: nie działa singleplayer, gra wysypuje się tuż po wybraniu poziomu trudności. Cóż, muszę chyba faktycznie polecić poczekanie na natywnego Steama i Poważnego Jana.


Więcej na stronach Wine appdb.winehq.org.

Dla porządku kawałek logu świadczący o działaniu OGL:

00:02:13 LOG:   Trying to set display mode 1920x1080(maximized)...
00:02:13 INF:   
00:02:13 INF:   * Desktop settings...
00:02:13 INF:   Color depth: 32-bit
00:02:13 INF:   Desktop resolution: 1920 x 1080
00:02:13 INF:   Virtual screen: 1920 x 1080
00:02:13 INF:   Monitors attached: 1
00:02:13 LOG:   Loaded "C:\Program Files\Steam\steamapps\common\Serious Sam 3\Bin\GfxOGL.dll".
00:02:13 LOG:   Loaded "OpenGL32.dll".
00:02:13 LOG:   Loaded "DXGI.DLL".
00:02:14 INF:   
00:02:14 INF:   Gfx API: OpenGL
00:02:14 INF:   Window: 1920 x 1011
00:02:14 INF:   Vendor: unknown (0x0000)
00:02:14 INF:   Driver: ATI Technologies Inc. (0x0000)
00:02:14 INF:   Renderer: AMD Radeon HD 6670
00:02:14 INF:   Version: 4.2.11733 Compatibility Profile Context
00:02:14 INF:   Video memory size: 1024 MB
00:02:14 INF:   Available for textures: 1024 MB
00:02:14 INF:   Active GPU(s): 1
00:02:14 LOG:   Processing file Content/SeriousSam3/Config/CheckDriver.lua
00:02:14 INF:   Unable to check for correct version of display driver!
00:02:14 LOG:   Loaded "C:\Program Files\Steam\steamapps\common\Serious Sam 3\Bin\SfxDSD.dll".
00:02:14 LOG:   Loaded "dsound.dll".
00:02:14 TRC:   EAX is not supported.
00:02:14 INF:   
00:02:14 INF:   Sfx API: DirectSound
00:02:14 INF:   Device: Pulseaudio
00:02:14 INF:   Mixer frequency: 44100 Hz
00:02:14 INF:   Mixer voices: 0
00:02:14 INF:   Max sound sources: 25
00:02:14 INF:   Max total volume: 3
00:02:14 INF:   Speaker config: stereo
00:02:14 INF:   Environment FX: not supported

I jeszcze jeden ładny obrazek - SS3 (Direct3D, OpenGL nie wyraził chęci do współpracy) uruchomiony z użyciem otwartego sterownika R600g, z programem RadeonTop uruchomionym w tle:
 

środa, 4 lipca 2012

Mutacja prawdy w Internecie

Internet jest trochę jak głuchy telefon. Niedawno na Roflcopterze (serwis dla ludzi niemających przyjaciół) przeczytałem notkę o tym jak Nvidia oszukiwała benchmarki. Nie wiedziałem jednak czy ta informacja ma cokolwiek wspólnego z prawdą. Oto treść notki:
In the early 2000s Nvidia was lagging behind ATI in performance, causing them to panic a bit about losing their stranglehold on the graphics card industry. As a quick attempt to "catch up" they set their drivers to disable common graphical options automatically, despite what the game called for. The real genius was that they set it up so that it would re-enable all those effects for a single frame if it caught the system trying to take a screenshot. (This of course being a time before streaming high quality comparison videos were feasible)

What you ended up with were benchmarks that claimed not only that Nvidia was faster, but that enabling antialiasing and texture filtering had little to no performance hit and comparison screenshots showed that image quality was equal or better than their competitor.
Sterowniki miały wyłączać efekty podczas trwania benchmarku. Jednak w momencie wykonywania zrzutu ekranu efekty były włączane ponownie. Czy to prawda? Roflcopter podaje jako źródło komentarz na reddicie:
While somewhat underhanded, it isn't quite the most underhanded thing a tech company has done to make their product appear faster.
In the early 2000s ATI was lagging behind Nvidia in performance. As a quick attempt to "catch up" they set their drivers to disable common graphical options automatically, ignoring what the game settings actually said. The real genius was that they set it up so that it would re-enable all those effects for a single frame if it caught the system trying to take a screenshot. (This of course being a time before streaming high quality comparison videos were feasible)
What you ended up with were benchmarks that claimed not only that ATI was faster, but that enabling antialiasing and texture filtering had little to no performance hit and comparison screenshots showed that image quality was equal or better than their competitor.

Jak widać, według tego komentarza, to ATI oszukiwało. Skąd ta rozbieżność? Ktoś zarzucił nieprawdę autorowi komentarza i ten zamienił firmy (w pierwotnej wersji  to Nvidia była oszustem). To w końcu kto oszukiwał? A może nikt, a informacja została wyssana z palca?

Jak się okazuje, opisywane oszustwo naprawdę zostało wykryte w w 2003 roku i opisane na prezentacji Gabe'a Newella:
Newell was concerned particularly with some of the techniques NVIDIA has used in recent driver releases, although he didn't exempt other graphics hardware makers from his complaints. He said they had seen cases where fog was completely removed from a level in one of Valve's games, by the graphics driver software, in order to improve performance. I asked him to clarify which game, and he said it was Half-Life 2. Apparently, this activity has gone on while the game is still in development. He also mentioned that he's seen drivers detect screen capture attempts and output higher quality data than what's actually shown in-game
Nvidia posunęła się do takiego kroku z powodu marnej wydajności Geforce 5200, 5600 i 5900 w Direct3D 9.0. Układy "zielonych" nie miały żadnych szans z Radeonami 9800 i 9600.

Lata 2003-2004 były okresem bardzo zaciętej rywalizacji ATI z Nvidią. ATI było wspierane przez Valve z silnikiem Source (użytym w Half-Life 2 w 2004), Nvidia była wspierana przez Id Software z silnikiem Id Tech 4 (użytym w Doomie 3 w 2004). Wielu podejrzewało Valve o specjalne optymalizacje dla R300 (Radeony 9500-9800). Newell powiedział jednak, że Radeony korzystają ze standardowego D3D 9.0, a Valve wręcz próbowało zastosować dodatkowe optymalizacje (uproszczenia) dla NV3x (Geforce 5x00). 

Smaczku sprawie dodawała wyższa wydajność Geforce 5900 w Doomie 3. Ostatecznie domysły uciął sam John Carmack (szef Id Software), zapytany przez BonusWeb.cz:

In view of recent ATI’s Shader Day event and Gabe Newell’s presentation of Half-Life 2, we asked John Carmack about his opinion. What can we expect from GeForce FX family regarding future DirectX 9 games?


Hi John,
No doubt you heard about GeForce FX fiasco in Half-Life 2. In your opinion, are these results representative for future DX9 games (including Doom III) or is it just a special case of HL2 code preferring ATI features, as NVIDIA suggests?
Unfortunately, it will probably be representative of most DX9 games. Doom has a custom back end that uses the lower precisions on the GF-FX, but when you run it with standard fragment programs just like ATI, it is a lot slower. The precision doesn't really matter to Doom, but that won't be a reasonable option in future games designed around DX9 level hardware as a minimum spec. John Carmack
Carmack wprowadził dodatkowy backend (nie wiem jaki jest polski odpowiednik) który umożliwiał działanie z obniżoną precyzją. Gdyby jednak uruchomić Geforce 5x00 z backendem ARB2, to cała przewaga nad Radeonem by stopniała.
Silnik Dooma 3 miał aż 5 różnych backendów:
  • R10 (GeForce256)
  • R20 (GeForce3)
  • R200 (Radeon 8500)
  • ARB (OpenGL 1.X)
  • ARB2 (OpenGL 2.0)
To wszystko już historia, ale też dowód jak potrzebne jest uźródłowienie każdej informacji. Niech [citation needed] będzie z wami!

niedziela, 1 lipca 2012

Catalyst kontra R600g w Half-Life 2/Wine

Niedawno w serwisie Phoronix pojawiła się notka o tym, że otwarty sterownik R600g jest szybszy niż dostarczany przez AMD Catalyst. Benchmark dotyczył gry Half-Life 2 uruchomionej pod Wine. Zapachniało sensacją, musiałem sprawdzić to osobiście.

Informacje o teście:


Timedemo było uruchamiane dwukrotnie. Liczył się wynik drugiej próby. Szczegółowe wyniki:
  • R600g, 1920x1080
    9649 frames 166.126 seconds 58.08 fps (17.22 ms/f) 3.450 fps variability 
  • R600g, 1280x720
    9649 frames 135.284 seconds 71.32 fps (14.02 ms/f) 7.916 fps variability
  • Catalyst 12.6, 1920x1080
    9649 frames 123.921 seconds 77.86 fps (12.84 ms/f) 7.058 fps variability
  • Catalyst 12.6, 1280x720
    9649 frames 125.311 seconds 77.00 fps (12.99 ms/f) 6.662 fps variability
Ciekawostką jest brak wpływu rozdzielczości na prędkość wyświetlania, gdy używane są Catalysty. Widocznie karta graficzna nie jest tu wąskim gardłem.  W przeciwieństwie do benchmarków zamieszczonych na Phoroniksie, R600g nie okazał się szybszy. Wytłumaczeniem może być natura tamtych prób, przeznaczono je do testów Wine, a nie sterowników - ustawienia grafiki były bardzo niskie.

Pomiędzy R600g a Catalystami można zaobserwować drobne różnice w wyświetlaniu:

Catalyst 12.6

R600g

Informacje systemowe Steama (procesor skaluje się 800 - 2800MHz):
Informacje o procesorze:
    Dostawca: AuthenticAMD
    Szybkość: 800 MHz
    2 procesory logiczne
    1 procesory fizyczne
    HyperThreading:  Obsługiwane
    FCMOV:  Obsługiwane
    SSE2:  Obsługiwane
    SSE3:  Obsługiwane
    SSSE3:  Obsługiwane
    SSE4a:  Obsługiwane
    SSE41:  Nieobsługiwane
    SSE42:  Nieobsługiwane
  
Informacje o sieci:
    Szybkość sieci: 
   
Wersja systemu operacyjnego:
    Windows XP (32 bitów)
    Wersja Wine: wine-1.5.7
    NTFS:  Obsługiwane
    Klucze szyfrujące: Obsługiwane 323 0x0 0x0 0x0
   
Karta graficzna:
    Nie wykryto sterownika

    Nazwa sterownika DirectX: ati2dvag.dll
    Nie wykryto wersji sterownika
    Wersja sterownika DirectX: 6.14.10.8681
    Nie wykryto daty sterownika
    Karta DirectX: AMD Radeon HD 6600 Series
    Ident. producenta: 0x1002
    ID urządzenia: 0x6758
    Liczba monitorów: 1
    Liczba logicznych układów graficznych:  1
    Nie wykryto SLI lub Crossfire
    Rozdzielczość głównego ekranu:  1920 x 1080
    Rozdzielczość pulpitu: 1920 x 1080
    Rozmiar głównego ekranu: 20.00" x 11.26" (22.91" diag)
50.8cm x 28.6cm (58.2cm diag)
    Nie wykryto rodzaju szyny głównej
    Ilość pamięci VRAM: 1024 MB
    Nie wykryto obsługiwanych trybów MSAA
   
Karta dźwiękowa:
    Dźwięk: Pulseaudio
   
Pamięć:
    RAM: 2013 MB 


Update: Half Life 2: Lost Coast 


  • R600g, 1920x1080, CPU@2,8GHz - 42,74 kl./s
  • Catalyst 12.6 1920x1080, CPU@2,8GHz - 48,43 kl./s
  • R600g, 1920x1080, CPU@3,5GHz - 49,67 kl./s
  • Catalyst 12.6 1920x1080, CPU@3,5GHz - 57,41 kl./s 
Zrobiłem jeszcze kilka testów wbudowanym benchmarkiem w Lost Coast. Podobnie jak poprzednio AA, AF, v-sync były wyłączone, reszta ustawiona na maksimum. W tym przypadku obniżanie rozdzielczości nie zwiększało prędkości wyświetlania. Za to widoczny był wpływ taktowania procesora na wyniki.