Czy istnieje ograniczenie liczby kontekstów renderowania OpenGL, które można jednocześnie utworzyć?

Question

Moja aplikacja .Net Winforms tworzy w moim głównym oknie trzy konteksty renderowania OpenGL, a następnie pozwala użytkownikowi na wyskakiwanie innych okien, w których każde okno ma dwa dodatkowe konteksty renderowania (za pomocą splittera). W około 26 kontekście renderowania, rzeczy zaczynają NAPRAWDĘ powolne. Zamiast poświęcić kilka milisekund na renderowanie ramki, nowy kontekst renderowania zajmuje od 5 do 10 sekund. Nadal działa, po prostu NAPRAWDĘ SLOW! A OpenGL NIE zwraca żadnych błędów (glGetError).

Pozostałe okna działają poprawnie. Tylko nowe konteksty renderowania po zwolnieniu określonej liczby. Jeśli zamykam te okna, wszystko jest w porządku - dopóki nie otworzę wystarczająco dużo okien, aby przekroczyć limit. Każdy kontekst renderowania ma własny wątek, a każdy używa prostego modułu cieniującego. Zwolnienie wydaje się mieć miejsce, gdy przesyłam teksturę. Ale rozmiar tekstury nie ma wpływu na to, ile kontekstów mogę utworzyć, ani na rozmiar okna OpenGL.

Używam kart nVidia i widzę to na różnych procesorach graficznych z różnymi ilościami pamięci i różnymi wersjami sterowników. O co chodzi? Czy istnieje ograniczenie liczby kontekstów renderowania, które aplikacja może utworzyć?

Czy ktoś jeszcze ma aplikację z wieloma kontekstami renderowania działającymi w tym samym czasie?

Answer 1

Najlepszym rozwiązaniem jest brak realnej odpowiedzi na to pytanie. Prawdopodobnie zależy to od wewnętrznych ograniczeń sterownika, sprzętu nawet systemu operacyjnego. Coś, co możesz chcieć sprawdzić, to liczba dostępnych jednostek teksturowych przy użyciu glGet(GL_MAX_TEXTURE_UNITS), ale to może być lub nie być orientacyjne.

Powszechnym rozwiązaniem tego problemu jest tworzenie wielu rzutni w ramach jednego kontekstu zamiast wielu kontekstów w jednym oknie. Nie powinno być zbyt trudno zjednoczyć dwa konteksty, które współdzielą okno z pojedynczym kontekstem z dwoma rzutniami i widżetem interfejsu, który służy jako rozgałęźnik. Wiele okien to zupełnie inna historia i warto rozważyć całkowite przemyślenie projektu interfejsu użytkownika, jeśli istnieje potrzeba 26 oddzielnych okien OpenGL.
Trudno mi teraz wyobrazić sobie rzeczywisty przypadek użycia interfejsu, który wymagałby jednocześnie 26 różnych okien OpenGL działających jednocześnie. może inną opcją jest stworzenie puli powiedzmy 5-10 kontekstów i ponowne użycie ich tylko w oknach (kartach?), które są obecnie widoczne dla użytkownika. Nie próbowałem tego, ale powinno być możliwe utworzenie kontekstu wewnątrz zwykłego okna, które nie zawiera niczego innego, a następnie przeniesienie tego okna z okna nadrzędnego do okna nadrzędnego do dowolnego okna najwyższego poziomu, w którym jest potrzebne.

EDIT -
Cóż, właściwie nie jest tak trudno o tym myśleć. Najnowszy Chrome (9.x.x), obsługujący WebGL, może chcieć otworzyć wiele zakładek z kontekstem WebGL ... Zastanawiam się, czy w jakikolwiek sposób sobie z tym poradzą. Po prostu wypróbowałem to i zabrakło pamięci po 13 kartach ... To byłby dla ciebie dobry sprawdzian, żeby sprawdzić, czy to coś, co robisz źle, czy też chrome i firefox (4.0.x-beta) mają to samo problem

Answer 2

Biorąc pod uwagę różnorodny charakter sterowników OpenGL, najlepszym rozwiązaniem jest prawdopodobnie sprawdzenie zachowania głównych sterowników (AMD/Intel/NVIDIA/MS Software Render) i na pierwszym starcie uruchomić test. Na przykład. jeśli widzisz, że NVIDIA zawsze zwalnia, tak jak widziałeś, po prostu uruchom szybką pętlę, aż zobaczysz, gdzie jest limit na tym komputerze (lub raczej na karcie). Nie jest to zabawne, ale uważam, że trudno jest niezawodnie przekraczać granice.

Innymi słowy "najlepszy zakład" jest taki, jak wcześniej udzielono odpowiedzi, nie można wcześniej o tym wiedzieć.

Answer 3

Jak słusznie powiedział Nathan Kidd, limit jest zależny od implementacji, a wszystko, co możesz zrobić, to uruchomić testy na wspólnym sprzęcie.

Byłem znudzony na dzisiejszym spotkaniu departamentu, więc próbowałem skomponować trochę kodu, który tworzy kontekst OpenGL i próbuje trochę renderowania. Próbowałem renderowania zi bez tekstur, zi bez kontekstu OpenGL kompatybilnego z do przodu.

Okazało się, że limit jest dość wysoki dla kart GeForce (może nawet bez limitu). W przypadku pulpitu Quadro istniał limit 128 kontekstów, które były w stanie odświeżyć się poprawnie, program był w stanie stworzyć 128 kontekstów bez błędów, ale okna zawierały śmieci.

To było jeszcze ciekawsze w ATi Radeonie 6950, tam przerysowanie zatrzymało się w oknie # 105 i nie powiodło się utworzenie kontekstu renderowania # 200.

Jeśli chcesz spróbować sam, program można znaleźć tutaj: Max OpenGL Contexts test (jest pełny kod źródłowy + pliki binarne win32).

To wynik. Jedna porada - w miarę możliwości unikaj używania wielu kontekstów. Wiele kontekstów można zrozumieć w aplikacjach działających na monitorach mulitple, ale aplikacje na pojedynczym monitorze powinny odwoływać się do jednego kontekstu. Przełączanie kontekstu jest wolne. I to nie wszystko. Aplikacje, w których okna OpenGL nakładają się na inne okna, wymagają regionów przycinania sprzętu. Na karcie GeForce znajduje się jeden obszar przycinania sprzętowego, osiem lub więcej na Quadro (aplikacje CAD często używają okien i menu, które nakładają się na okno OpenGL, w przeciwieństwie do gier). W przypadku, gdy potrzebna jest większa liczba regionów, renderowanie wraca do oprogramowania - więc znowu - posiadanie wielu okien OpenGL (kontekstów) nie jest dobrym pomysłem.

Answer 4

Jeśli napotkasz na wiele problemów, aby ustawić OpenGL w wieloprzekrojowej topologii, możesz równie dobrze z niego skorzystać i rozważyć przejście na Vulkan. Zobacz, zgodnie z projektem, architektura OpenGL przecina wszystkie ciężko wypracowane konteksty/wątki oddzielone operacje rysowania w jeden wątek sterownika, który następnie redystrybuuje wszystkie te połączenia przez wirtualne wątki sprzętowe, które mapują na każdym kontekście. Kierowca jest w istocie ogromnym wąskim gardłem, ponieważ nie jest sam gwintowany, mimo że siedzi w nim glewmx. Po prostu nie jest przystosowany do tego dobrze.

To powiedziawszy, jestem ciekawy, czy użyłeś starszej wersji Glew, czy też wykonasz wszystkie operacje rozszerzenia w jakiś inny sposób, ponieważ najnowsze biblioteki glew nie obsługują już mx. Kolejny powód do zmiany.