Autor Wątek: Poszukiwanie silnika (GPGPU + postprocessing)  (Przeczytany 2047 razy)

Offline _OskaR

  • Użytkownik

# Wrzesień 02, 2013, 18:51:27
Od pewnego czasu skaczę sobie po silnikach, szukając czegoś, co pozwoli mi na:
1. Postprocessing z możliwością tworzenia własnych efektów.
2. GPGPU (fizyka cząsteczek).
3. Zabawę z tesselacją.

Na początku podłubałem przy CryEngine 3 - CUDA raczej z tym się nie połączy. Może jakoś to obsłuży Compute Shader, ale jak zobaczyłem tworzenie materiałów, to zwątpiłem - jakieś to trochę zbyt "gotowe".

Unreal Engine 3 - shadery - na początku trochę dziwne, ale nawet mi się spodobało to podejście - zwłaszcza, że można dopisywać swój kod. APEX - już mi się tu podoba. Ale PhysX + cząsteczki - to mnie nie zadowoliło, a żeby policzyć sobie coś na GPU, to musiałbym chyba dłubać w kodzie silnika.

Unity - z GPGPU na razie walczę, bo niby się da, ale mało kto wie jak, niby jest tutek na start - ale szczegółowość zawartych tam informacji jest odwrotnie proporcjonalna do ich ważności. Pojawia się niestety większy problem - rendering do tekstury jest dostępny, ale w wersji Pro.

Moje opinie mogą bazować na trochę powierzchownych informacjach - jak ktoś wie więcej, a ja się mylę - chętnie posłucham. Dysku jeszcze nie czyściłem. :-)
Oczywiście można coś napisać samemu, ale myślę, że fajnie byłoby poznać jakiś istniejący silniczek.

Offline Mr. Spam

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

Offline Xender

  • Użytkownik

# Wrzesień 02, 2013, 22:10:10
Pytanie, czy do particli potrzebny Ci compute shader lub CUDA. Jeśli nie robisz czegoś niestandardowego, to wystarczy fragment shader i render do tekstury lub vertex/geometry shader i transform feedback. Nie wiem, czy/jakie silniki obsługuję któreś z nich, ale zmniejsza to nieco wymagania.

Offline ismu

  • Użytkownik

# Wrzesień 02, 2013, 23:23:05
Hmm... Kiedyś też szukałem czegoś podobnego właśnie typowo do "symulacji naukowych" w dużej mierze do symulacji cząsteczek, no i niestety nie znalazłem nic co by mnie zadowoliło(wszystko było raczej pod gry, proste symulacje, problemy z integracją CUDA, OpenCL). W tej sytuacji postanowiłem napisać swój silnik. Jak chcesz robić jakieś poważniejsze symulacje fizyczne(z wykorzystaniem np. równania Naviera-Stokesa czy równania różniczkowego Poisson) to na pewno będzie potrzebna, same shadery nie dadzą rady w real time. Wystarczy, że co nieco więcej numeryki będzie potrzeba i bez zrównoleglenia na GPU będzie ciężko uzyskać real time przy dobrej dokładności.

Offline _OskaR

  • Użytkownik

# Wrzesień 02, 2013, 23:30:19
Z particli chcę zrobić coś w rodzaju cieczy, więc przydadzą się kolizje. W UDK takie coś da się zrobić - http://www.youtube.com/watch?v=P0sf3NUafO8&list=TLxa5tu4awIlE - ale to trochę szczególny przypadek. Nie zrobimy czegoś w stylu reakcji chemicznej itp. Plus jest taki, że nie trzeba tracić czasu na kombinowaniu przy kolizjach z innymi elementami mapy.

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Wrzesień 02, 2013, 23:40:17
Cytuj
Jak chcesz robić jakieś poważniejsze symulacje fizyczne(z wykorzystaniem np. równania Naviera-Stokesa czy równania różniczkowego Poisson) to na pewno będzie potrzebna, same shadery nie dadzą rady w real time.
Dwie kwestie:

1. Równania Naviera-Stokesa i Poissona to złe przykłady, bo je akurat implementuje się pięknie w pixel shaderach. ;)

2. Wydajnościowo pixel shadery są szybsze od compute shaderów. Główną zaletą compute shaderów są ich dodatkowe featury (group shared memory i bariery) i jeżeli korzystasz z algorytmów w których to się przydaje, to może być zysk. Warto jednak zauważyć, że połowa featurów compute shaderów weszła również do pixel shaderów w Shader Model 5 (operacje atomowe i dowolne pisanie/czytanie do/z UAV), więc automatycznie wiele programów compute da się zaimplementować na pixel shaderach. Z drugiej strony pixel shadery mają ekstremalnie szybki z/stencil do dyspozycji pozwalający szybko ubijać piksele w paczkach 2x2 w algorytmach wieloprzebiegowych - czego nie można powiedzieć o compute, gdzie uzyskanie dynamicznego rozmiaru grupy jest znacznie trudniejsze.

Offline Veldrin

  • Użytkownik

# Wrzesień 03, 2013, 02:18:02
@_OskaR: nie szukaj po silnikach gier. Bo wyraźnie nie potrzebujesz funkcjonalność, która stanowi Core typowych systemów dedykowanych pod gry.

Nie wiem jakie masz dokładnie wymaganie swojego projektu/badań/pracy, ale wyraźnie szukasz środowiska do badań i symulacji. Niestety nic gotowego nie mogę polecić, najlepiej poszukaj po nowszych publikacjach naukowych o podobnym temacie, czy choćby nawet GPGPU.

Tam gdzie porządny research to i środowisko testowe na odpowiedniej licencji powinno być dostępne. Albo chociaż informacje o specjalistycznych narzędziach. Prawdopodobnie nie będzie tam wszystkiego, ale w takim wypadku taki np. punkt sobie dorobisz od ręki samemu ;).

Offline mihu

  • Użytkownik
    • mihu

# Wrzesień 03, 2013, 03:27:49
1. Równania Naviera-Stokesa i Poissona to złe przykłady, bo je akurat implementuje się pięknie w pixel shaderach. ;)
(...) Główną zaletą compute shaderów są ich dodatkowe featury (group shared memory i bariery)
Akurat chyba w algorytmach, w których każda komórka liczy coś na danych z kilku sąsiednich komórek, to te featury które wymieniłeś są przydatne - każdy wątek najpierw zasysa "swoją" wartość do pamięci dzielonej, i potem wszystkie się hojnie dzielą tym co zaciągnęły. :) Chociaż nie wiem czy to daje wymierne przyspieszenie.
« Ostatnia zmiana: Wrzesień 03, 2013, 03:29:56 wysłana przez mihu »

Offline Krzysiek K.

  • Redaktor
    • DevKK.net

# Wrzesień 03, 2013, 10:10:45
Akurat chyba w algorytmach, w których każda komórka liczy coś na danych z kilku sąsiednich komórek, to te featury które wymieniłeś są przydatne - każdy wątek najpierw zasysa "swoją" wartość do pamięci dzielonej, i potem wszystkie się hojnie dzielą tym co zaciągnęły. :) Chociaż nie wiem czy to daje wymierne przyspieszenie.
Na tego typu lokalności od dawien dawna bazuje cache samplera tekstur (bo sąsiednie piksele mogą potrzebować podobnych tekseli). Co więcej, tekstury niekoniecznie są ułożone liniowo w pamięci, tylko tak, żeby łapiąc linię do cache złapać coś rzeczywiście przydatnego (czyli np. bloczek 4x4 teksele, zamiast 16 w jednej linii), czego nie można powiedzieć o buforach w compute, gdzie tego typu optymalizacje pozostawione są użytkownikowi (który najczęściej ich nie robi).

Offline _OskaR

  • Użytkownik

# Wrzesień 03, 2013, 17:12:41
@_OskaR: nie szukaj po silnikach gier. Bo wyraźnie nie potrzebujesz funkcjonalność, która stanowi Core typowych systemów dedykowanych pod gry.
Szukam po silnikach, bo chciałbym upiec dwie pieczenie na jednym ogniu - jakiś efektowny ficzer, który niekoniecznie będzie dążył do bycia superrealistycznym (zabawa > naukowość) + do tego trochę wiedzy i doświadczenia.