Czy potrafisz wstępnie zdekonfigurować moduł cieniujący na wątku tła z własnym kontekstem?

Question

Zajmuję się tworzeniem dużej gry, która strumieniuje dane poziomu (w tym shadery) podczas poruszania się po świecie gry. Nie chcę mieć haków w mojej liczbie klatek na sekundę, ponieważ shadery są kompilowane/połączone lub po raz pierwszy są używane.

Mam kompilację shaderów i łączenie działające na osobny wątek z własnym kontekstem otwartym. Ale nie udało mi się uzyskać wstępnego podgrzewania shaderów do pracy nad oddzielnym wątkiem (tak, że nie ma żadnej wydajności, gdy używany jest moduł cieniujący).

Podgrzewanie naprawdę nie jest wspomniane w dokumentach iOS i OpenGL. Jest to jednak wspomniane w OpenGL ES Analyzer (jeden z instrumentów dostępnych podczas profilowania z xcode). W tym narzędziu otrzymuję ostrzeżenie "Shader Compiled Outside Prewarming Phase" za każdym razem, gdy coś jest renderowane za pomocą modułu cieniującego, który nie był wcześniej używany do renderowania czegoś. "Rozszerzony szczegół" mówi:

"OpenGL ES Analyzer wykrył kompilację shaderów, która nie jest częścią fazy wstępnego podgrzewania, a kompilacja shaderów może być czasochłonną operacją, aby ich uniknąć, przedwzmacnij wszystkie shadery używane do renderowania. Aby to zrobić, wykonaj wstępne podgrzewanie po uruchomieniu aplikacji i wykonaj wywołanie rysunku przy użyciu każdego z programów cieniujących, które będą używane, przy użyciu dowolnych ustawień stanu glosu, w których program cieniujący będzie używany w połączeniu z. Stany takie jak mieszanie, maska ​​kolorów, logika ops, multisamping, formaty tekstur i prymitywny stan mogą mieć wpływ na kompilację shaderów. "

Termin "kompilacja" jest tu nieco mylący. Szczyty wierzchołków i fragmentów zostały już skompilowane, a program został połączony. Ale za pierwszym razem, gdy coś jest renderowane z danym stanem OpenGL, robi trochę więcej pracy nad shaderem, aby zoptymalizować go do tego stanu, jak sądzę.

Mam kod do wstępnego rozgrzania shaderów, renderując trójkąt o rozmiarze zerowym przed pierwszym użyciem.

Jeśli kompiluję, łączę i wstępnie rozgrzewam shadery głównego wątku z tym samym kontekstem OpenGL, co normalne renderowanie, to działa. Jednak jeśli zrobię to w wątku tła z jego oddzielnym kontekstem Open GL, to nie działa (nadal otrzymuje ostrzeżenie Analyzera przy pierwszym użyciu).

A więc ... może być tak, że wstępne rozgrzewanie cieniowania w oddzielnym kontekście nie ma wpływu na inne konteksty. Lub może być tak, że nie mam tego samego stanu, który ustanowił oddzielny kontekst. Istnieje wiele potencjalnych stanów Open GL, które mogą wymagać konfiguracji. Używam bufora renderowania poza ekranem w wątku tła, aby można było uznać go za część stanu.

Czy ktoś zdołał wykonać wstępne podgrzewanie działające na wątku tła?

Answer 1

Szczerze mówiąc, do tej pory nie znałem się na tej sprawie, chociaż przez jakiś czas pracowałem nad optymalizacją silnika. Przede wszystkim więc dziękuję za cynk :).

Studiowałem od tego czasu temat ocieplający cieniowanie i nie znalazłem wiele wokół.

znalazłem wzmiankę oficjalnej dokumentacji AMD w dokumencie zatytułowanym „ATI OpenGL programowanie i optymalizacja Guide”:

http://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=6&ved=0CEoQFjAF&url=http%3A%2F%2Fdeveloper.amd.com%2Fmedia%2Fgpu_assets%2FATI_OpenGL_Programming_and_Optimization_Guide.pdf&ei=3HIeT_-jKYbf8AOx3o3BDg&usg=AFQjCNFProzLiXf5Aqqs4jZ2jOb4x0pssg&sig2=6YV7SVA97EFglXv_SX5weg

jest to fragment, który odnosi się do ocieplenia shaderów:

żądanie:

Podczas R500 natywnie umożliwia regulację przepływu w jednostce cieniowania fragmentu, R300 i R400 asics nie. Sterowanie przepływem statycznym dla R300 i R400 jest emulowane przez sterownik, który kompiluje nieużywane warianty i pętle rozwijania w oparciu o ustawione stałe. Mimo że rodzina asics R500 natywnie obsługuje kontrolę przepływu, sterownik nadal będzie próbował skompilować statyczne warunki przepływu, umożliwiając zmianę instrukcji modułu cieniującego w celu lepszego planowania instrukcji. Sterownik będzie także próbował buforować od kompilowanego modułu cieniującego pod kątem określonego warunku przepływu statycznego ustawionego w oczekiwaniu na jego ponowne użycie. Więc kiedy pisze program fragmentów, który używa statycznej kontroli przepływu, zaleca się "rozgrzanie" pamięci podręcznej modułu cieniującego przez renderowanie pozornego trójkąta na pierwszej klatce, która korzysta z powszechnych permutacji statycznych, odpowiednich dla okresu działania modułu cieniującego.

Najlepszym wyjaśnieniem znalazłem wokół jest następujący:

http://fgiesen.wordpress.com/2011/07/01/a-trip-through-the-graphics-pipeline-2011-part-1/

Cytat:

Nawiasem mówiąc, jest to również powód, dla którego będziesz często zobaczyć opóźnienie czasu pierwszego użycia nowy moduł cieniujący lub zasoby; wiele prac związanych z tworzeniem/kompilacją jest odroczonych przez kierowcę i wykonywane tylko wtedy, gdy jest to rzeczywiście konieczne (nie uwierzysz, ile nieużywanych bzdur niektóre aplikacje tworzą!). Programiści graficzni znają drugą stronę tej historii - jeśli chcesz się upewnić, że coś jest faktycznie tworzone (w przeciwieństwie do zarezerwowania pamięci), musisz wywołać fałszywe wywołanie, które używa go do "rozgrzania". Brzydka i denerwująca, ale tak było, odkąd pierwszy raz zacząłem używać sprzętu 3D w 1999 roku - co oznacza, że ​​w tym momencie jest to faktem, więc przyzwyczaj się do tego. :)

W tej prezentacji jest mowa o tym, jak silnik cryteck wykonał go na silniku dalekim, choć jest on głównie związany z DirectX.

http://www.powershow.com/view/11f2b1-MzUxN/Far_Cry_and_DirectX_flash_ppt_presentation

Mam nadzieję, że te linki pomóc w jakiś sposób.