Generowanie terenu na GPU

W moim silniku tworzę nieskończony teren z wykorzystaniem algorytmu szumu Perlina obliczonego na procesorze.

Tworzenie terenu przebiega następująco:

Jeśli kamera znajduje się w pobliżu rozładowanej łatki, utwórz ją
Oblicz tablicę szumów 513 x 513 z podanymi granicami
Obliczanie normalnych, stycznych, dwumianowych, indeksów
Przekaż dane do vbo

Plusy:

Trzeba je renderować tylko w razie potrzeby
Łatwa do zderzenia

Kon

Powolne 64 łatki 513x513 są tworzone w 3,1s (jeden wątek). Dla każdej płytki ~ 20ms wytwarzanie szumu, ~ 25ms wierzchołki, normalne, styczna, bitangent, indeksy. Gdy kamera porusza się szybko, użytkownik może zauważyć ładowanie płytek.
pamięć zużywa ???

Teraz zastanawiałem się, jak to przyspieszyć, generując teren całkowicie na GPU. Istnieją jednak pewne wątpliwości:

Jeśli moduły cieniujące działają w każdej ramce, to czy ta moc obliczeniowa nie jest marnowana na obliczanie hałasu w kółko? Można tego uniknąć, zapisując wynik do tekstury RBGA i wykorzystując go później w module cieniującym wierzchołki do przemieszczania, ale zwiększając zużycie pamięci. Z drugiej strony, jeśli stworzenie byłoby super szybkie, tylko widoczne kafelki powinny pozostać w pamięci. Jednak odłączenie bufora powoduje synchronizację gpu-cpu, co może spowolnić aplikację (mam rację?)
Jeśli teren jest tylko płaską siatką przesuniętą przez moduł cieniujący wierzchołki, należy wykonać tę samą pracę na CPU, aby obliczyć wysokość i normalne w danym punkcie kolizji.
To tylko koncepcja, ale aby przyspieszyć wszystko, myślałem o rzutowaniu siatki na rzutnię, tak aby używana była tylko minimalna liczba wierzchołków. Myślisz, że to zadziała?

Moje ostatnie pytanie brzmi:

Jaka jest najlepsza / najszybsza / szeroko stosowana technika tworzenia nieskończonego terenu na GPU?

terrain

— użytkownik1075940
źródło

Należy pamiętać, że utworzenie terenu na GPU utrudni wykrywanie kolizji, wykrywanie wyborów lub prawie dowolną interakcję z terenem.

— MichaelHouse

Moduł obliczający (DX10 lub 11) może być użyty do wygenerowania terenu na GPU. Ale jak stwierdził Byte56, będziesz musiał wyciągnąć wartości z GPU, aby móc z nim współdziałać. msdn.microsoft.com/en-us/library/windows/desktop/…

— UnderscoreZero

tworzenie terenu na GPU wydaje mi się złym pomysłem. Może to działać, ale myślę, że prawdopodobnie działałoby to trochę lepiej, jeśli po prostu wygenerujesz teren po stronie procesora i wyślesz standardowe elementy rysunkowe do GPU.

— Benjamin Danger Johnson

Tylko moje doświadczenie; Zrobiłem to właśnie za pomocą aparapi i udało mi się uruchomić to cholerstwo; ale w rzeczywistości okazało się, że jest wolniejszy niż procesor. Myślę, że z powodu narzutu związanego z wysyłaniem danych do / z GPU. Jeśli dobrze pamiętam, gpu naprawdę działa tylko wtedy, gdy obliczenia są duże w porównaniu do wielkości danych (a także duże w wartościach bezwzględnych)

— Richard Tingle,

Ten artykuł może dać ci kilka pomysłów http.developer.nvidia.com/GPUGems3/gpugems3_ch01.html

— Jeremiah Leslie

Cóż, gdybym miał do tego celu użyć GPU, myślę, że wybrałbym compute / opencl / cuda.

Jednak bez względu na użycie procesora graficznego lub procesora (co tak naprawdę robię) zrobiłbym to w sposób asynchroniczny, uznając, że potrzebujesz trochę nowego terenu dla bieżącej klatki, jest prawdopodobnie zbyt późno (np. Rozważ 1000ms / 60 = 16,666ms, i cała rama chce się do tego zmieścić).

Rozpocznij generowanie (lub ładowanie ze skompresowanych plików) terenu w wątku roboczym i udostępnianie go pozostałej części gry oraz renderowanie po zakończeniu tego procesu roboczego, na ogół będzie to następna klatka, a może później klatka, więc użytkownik tak naprawdę nie zauważy różnicy, ale dzięki temu wszystko będzie gładsze.

— Będzie
źródło