Autor Wątek: Wyciskanie soków z procesora w grze RTS  (Przeczytany 5857 razy)

Offline mINA87

  • Użytkownik

# Lipiec 01, 2011, 22:05:41
Przykład skiningu miał pokazać sytuację, w której decydujemy się na jakieś rozwiązanie/algorytmy i już na początku wiemy jakie fragmenty kodu będą obciążone. Pisząc takie fragmenty nie musimy oczywiście od początku pisać całości w ASMie i otymalizować co do instrukcji, ale fajnie by było pokusić się w takich miejscach o wektoryzację chociażby.

Lepszy przykład - programista game play implementuje feature - jakiś obiekt AI powiedzmy, może się spodziewać że level designerzy wykorzystają go dosyć mocno. Taki programista odpala sobie prostego test case'a - działa na planowanym sprzęcie, działa. Nie spadł FPS, nie spadł. Zajebiście - commit i idę do domu. Za tydzień wszyscy z przerażeniem patrzą na regresję FPSów, programiści silnika rzucają wszystko, żeby znowu poprofilować kod gry i voila - okazuje się, że ktoś tydzień temu machnął sobie kod z d.... a na dzień dzisiejszy przypadków użycia tego feature'a jest 100x więcej i wychodzą jakieś debilizmy. Czy faktycznie taka sytuacja musiała wystąpić, bo przecież premature optimization is root of all evil? Źle itnerpretujecie to zdanie, albo nie rozumiecie mojego przesłania :)

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Lipiec 01, 2011, 23:13:42
Cytuj
Tak, ale jak robisz przykładowo skining na CPU, to wypadałoby mieć sensownie działające mnożenie macierzy. Proste.
Dopiero w momencie, gdy ów skinning zacznie Ci zamulać na docelowym sprzęcie. Jeżeli wszystko działa wystarczająco płynnie, to nie ma potrzeby robić żadnych optymalizacji, nawet jeżeli miały by one dać 100-krotny zysk wydajności.

Cytuj
Lepszy przykład - programista game play implementuje feature - jakiś obiekt AI powiedzmy, może się spodziewać że level designerzy wykorzystają go dosyć mocno. Taki programista odpala sobie prostego test case'a - działa na planowanym sprzęcie, działa. Nie spadł FPS, nie spadł. Zajebiście - commit i idę do domu. Za tydzień wszyscy z przerażeniem patrzą na regresję FPSów, programiści silnika rzucają wszystko, żeby znowu poprofilować kod gry i voila - okazuje się, że ktoś tydzień temu machnął sobie kod z d.... a na dzień dzisiejszy przypadków użycia tego feature'a jest 100x więcej i wychodzą jakieś debilizmy. Czy faktycznie taka sytuacja musiała wystąpić, bo przecież premature optimization is root of all evil? Źle itnerpretujecie to zdanie, albo nie rozumiecie mojego przesłania :)
Dobry level designer nie wstawi Ci w mapie featura, który zamuli cała mapę. A nawet jeżeli będzie potrzebował/chciał coś takiego zrobić, to zawczasu uderzy do technicznego, który powinien zidentyfikować kto jest odpowiedzialny za feature i zbadać, ile da się tu ugrać. W przypadku, o którym piszesz, zawalili na całej linii designerzy, którzy nie obejrzeli się na FPSy robiąc mapę.

(co do wcześniejszych wypowiedzi - pisałem o projektach domowych; w firmach panują różne zasady, ale główną jest że szef ma rację i robisz co on Ci zleci)

Offline yarpen

  • Użytkownik

# Lipiec 02, 2011, 02:03:04
kto jest odpowiedzialny za feature i zbadać, ile da się tu ugrać. W przypadku, o którym piszesz, zawalili na całej linii designerzy, którzy nie obejrzeli się na FPSy robiąc mapę.
Nie do konca. Tak naprawde to zawiodla komunikacja. Programista tworzac feature powinien miec informacje - czy to bedzie jeden NPC na mapie czy 10. Z opisu wynika, ze kazdy dlubie swoja dzialke, a potem ma nadzieje, ze jak sie zlozy do kupy to bedzie dzialac.

Offline Mr.Protek

  • Użytkownik
    • Pogromcy Potworów

# Lipiec 02, 2011, 07:41:24
Tak, ale jak robisz przykładowo skining na CPU, to wypadałoby mieć sensownie działające mnożenie macierzy. Proste.
To akurat korzystając z tej waszej rozmowy mam pytanie, bo właśnie robię sobie powoli animację szkieletową u siebie na CPU, pogrupowałem Face'y względem materiału i kości (jeżeli 3 wierzchołki Face'a przynależą do tej samej kości) i teraz w zamyśle mam wyświetlać zgrupowane Face'y zmieniając tylko D3DTS_WORLD, czy takie coś będzie wydajne? Przeczytałem gdzieś że nie powinno się zmieniać macierzy widoku i świata za często podczas jednego przebiegu bo karta niby ma dużo do ustawiania rzeczy wewnątrz. Oczywiście Face'y których wierzchołki należą do różnych kości są zgrupowane w kilka grup (zależnych już tylko od materiału) i one wymagają obliczeń dla każdego wierzchołka Face'a.

Offline hashedone

  • Użytkownik

# Lipiec 02, 2011, 10:48:16
Robienie animacji szkieletowej na CPU nigdy nie będzie wydajne.

Offline mINA87

  • Użytkownik

# Lipiec 02, 2011, 13:21:20
@yarpen, Krzysiek: Ani LD, ani komunikacja. Feature był projektowany z myślą o tym, że będzie często wykorzystywany, bo to stosunkowo ważna sprawa była (nie chodzi o NPCe, powiedzmy obiekty-helpery). Autor machnął kod wychodząc z założenia - wstawiam 3 na ampę działa, no to fajnie. LD wyszli z założenia, że skoro działa to korzystają, bo w końcu trzeba, a nikt się nie połapał w czym rzecz dopóki z 10 tych obiektów zrobiło się 1000. Z racji tego, że zmiany FPSów z iteracji na iteraję mapy były niewielkie nikt tego nie zauważył na bieżąco.

@hashedone:
Bullshit. Wydajność to miara względna, którą należy rozpatrywać w konkretnym kontekście dlatego przykładowo:
1. GBA/NDS - jak tutaj zrobisz skinowanie nie na CPU jak masz dostępne tylko ARMy obsługujące fixed pointy?
2. Masz grę na PS3, RSX już wyciska siódme poty - będziesz jeszcze mu dorzucał skining jak masz bezrobotne SPU?
3. Ogólniej - wyobraź sobie instancjonowany animowany tłum osób rysowany forward rendererem. Też będziesz zawsze rzucał wszystko na GPU jeśli nie wspiera ono Stream Outa? No to powodzenia.

Jeśli dobrze pamiętam, to papery na temat Black'n'White 2 rozwodziły się nad tematyką animacji wielkich armii i właśnie tam część obiektów na dalszych LODach miało uproszczone szkielety transformowane na CPU.

@Mr.Protek:
Będziesz miał dużo DIPów, które faktycznie będą sporo stanów zmieniać. Wszystko jest kwestią tego w jaki sprzęt celujesz i na jakim API oraz jakie będą te ilości obiektów. Jeśli dodatkowo będziesz w forward renderingu rysował ten sam model parę razy dla wielu świateł to ta liczba jeszcze bardziej rośnie. W takim wypadku może Ci się bardziej opłacić przetransformować cały szkielet, wrzucić to do VB i wtedy już rysować jako jednolity obiekty jednym DIPem. Jak już wspomniałem - kwestia konkretnej sytuacji.
« Ostatnia zmiana: Lipiec 02, 2011, 13:26:20 wysłana przez mINA87 »

Offline rm-f

  • Użytkownik
    • Tu trolluje

# Lipiec 02, 2011, 13:29:14
Cytuj
1. GBA/NDS - jak tutaj zrobisz skinowanie nie na CPU jak masz dostępne tylko ARMy obsługujące fixed pointy?
> GBA
> skinning
Eeee?

Mówimy o tym samym GBA?


Offline rm-f

  • Użytkownik
    • Tu trolluje

# Lipiec 02, 2011, 15:00:41
Jedną/dwie postacie które mają mniej poligonów niz postać w quake jako techdemo z 2002 nazywasz grą?
Tak jak byś mi przytaczał "argumenty" za optymalizacją pod rozmiar assetów pokazując .kkriegera
Sztuka dla sztuki.

Offline Esidar

  • Użytkownik

# Lipiec 02, 2011, 17:58:46
@yarpen, Krzysiek: Ani LD, ani komunikacja. Feature był projektowany z myślą o tym, że będzie często wykorzystywany, bo to stosunkowo ważna sprawa była (nie chodzi o NPCe, powiedzmy obiekty-helpery). Autor machnął kod wychodząc z założenia - wstawiam 3 na ampę działa, no to fajnie. LD wyszli z założenia, że skoro działa to korzystają, bo w końcu trzeba, a nikt się nie połapał w czym rzecz dopóki z 10 tych obiektów zrobiło się 1000.
Jesli "autor wyszedł z założenia", to znaczy że nie rozmawiał o tym z LD, ani z grafikami, czyli zero komunikacji. LD ma usiąść razem z programistą i z grafikiem i we trzech razem mają ustalić, ilość postaci, ich szczegółowość, jakie features są potrzebne (np. mimika, fizyka włosów), jaka będzie różnorodność wyglądu, ile jest na to pamięci, jakie są ograniczenia sprzętu (np. 1 kość na wierzchołek) itd. Nie może być tak, że jeden z nich "wyszedł z założenia".

Eeee?
Mówimy o tym samym GBA?
GBA nie ma sprzętowego skinowania. Musisz robić na CPU. Po za tym to co już pisał mINA87: czasami lepiej jest policzyć skinning na CPU, bo nie tylko odciążasz GPU, ale wtedy również możesz policzyć krawędzie do cieni na stencilu.

Offline mINA87

  • Użytkownik

# Lipiec 02, 2011, 21:42:36
@Esidar: o widzisz, wiedziałem że o czymś zapomniałem, dobrze że przypomniałeś o tych shadow volume'ach.

Mój przykład jest ciut ocenzurowaną sytuacją z życia wziętą. Fakt jest taki, że problemem nie było to, że programista w chwili pisania był przekonany że instancji jego obiektu będzie mało. On miał świadomość że będzie ich dużo. Po prostu sobie machnął kod, wrzucił do repo i tyle.
O takich sytuacjach się właśnie rozpisuję - od początku wiadomo, że dany kod będzie obciążony - w takich sytuacjach po prostu trzeba się zastanowić nad tym co się pisze, warto przeprowadzić testy obciążeniowe a w przypadku najbardziej krytycznego kodu (biblioteki matematyczne, schedulery wątków, niskopoziomowe bebechy renderera, liczenie kolizji itp) warto go wręcz pisać z profilerem w ręku i/lub popatrzeć w wynikowy kod ASM.
Odnośnie takiego podejścia w domu - jasne, że jak będę pisał kółko i krzyżyk to nie będę się przejmował takimi rzeczami, ale jak już pisałbym konkretniejszy silnik, to wpiąłbym sobie CA na stałe, bo wynajdywać koła na nowo po raz 100tny nie mam czasu i nie chciałoby mi się bawić w pisanie ręcznej instrumentacji.

Offline msieradzki

  • Użytkownik

# Lipiec 04, 2011, 18:37:31
Używał ktoś R-drzew, żeby zminimalizować skakanie po pamięci? Znalazłem jeden artykuł:
http://sebastiansylvan.wordpress.com/2010/07/11/r-trees-%E2%80%93-adapting-out-of-core-techniques-to-modern-memory-architectures/
ale zastanawiało mnie czy ktoś mierzył wydajność KD-tree, Octree, R-tree itd. Nie zdziwiłbym się gdyby R-tree porównywalnie dobrze unikało skakania co ta siatka.

Offline wiew

  • Użytkownik

# Lipiec 23, 2011, 12:59:47
Chyba najbardziej wydajną optymalizacją będzie jednak połączyć jednostki w grupy po 200 jednostek, ale postanowiłem odłożyć optymalizację na później i najpierw ukończyć tą grę.
Pierwsze screeny dostępne na tej stronie: http://warsztat.gd/projects.php?x=view&id=2137
« Ostatnia zmiana: Lipiec 23, 2011, 13:01:34 wysłana przez wiew »

Offline mINA87

  • Użytkownik

# Lipiec 23, 2011, 14:15:30
Kurcze - aż bym sobie na to popatrzył pod profilerem ;)