C++/aplikacja opengl działa płynniej z dołączonym debugerem

Question

Czy napotkaliście sytuację, w której aplikacja C++ opengl działa szybciej i płynniej, gdy jest wykonywana z visual studio? Gdy wykonywany normalnie, bez debuggera, uzyskuję mniejszą liczbę klatek na sekundę, 50 zamiast 80, i dziwne opóźnienie, gdzie fps nurkuje do około 25 klatek na sekundę w każdej 20-30 klatce. Czy istnieje sposób, aby to naprawić?

Edytuj: Używamy również wielu list wyświetlania (utworzonych za pomocą glNewList). A zwiększenie liczby list wyświetlania wydaje się zwiększać opóźnienie.

Edytuj: Problem prawdopodobnie wynika z błędów stronicowania. Dostosowywanie zestawu roboczego procesu za pomocą metody SetProcessWorkingSetSizeEx() nie pomaga.

Edit: przypadku niektórych dużych modeli problem jest łatwy do wykrycia z wykorzystaniem GPU pamięci procexp użytkowych za. Wykorzystanie pamięci jest bardzo niestabilne, gdy istnieje wiele wywołań glCallList na klatkę. Nie dodano nowej geometrii, nie załadowano tekstur, ale alokacja pamięci gpu waha się w granicach -20 MB. Po chwili staje się jeszcze gorsza i może za jednym razem przydzielić około 150 Mb.

Answer 1

To prawdopodobnie wątek lub priorytet procesu. Visual Studio może uruchomić twój proces z nieco wyższym priorytetem, aby upewnić się, że debugger reaguje. Spróbuj użyć SetPriorityClass() w kodzie aplikacji:

SetPriorityClass(GetCurrentProcess(), ABOVE_NORMAL_PRIORITY_CLASS); 

do „normalnej” klasy wyżej tylko trąca go przed wszystkim innym z „normalnej” klasy. Jak mówi dokumentacja, nie uderzaj w super wysoki priorytet lub możesz zepsuć harmonogram systemu.

W aplikacji działającej z szybkością 60 klatek na sekundę uzyskuje się tylko 16 ms, aby narysować ramkę (mniej przy 80 fps!) - jeśli trwa to dłużej, należy opuścić ramkę, co może spowodować niewielki spadek liczby klatek na sekundę. Jeśli twoja aplikacja ma taki sam priorytet jak inne aplikacje, jest prawdopodobne, że inna aplikacja może tymczasowo ukraść procesor dla jakiegoś zadania, a opuścisz kilka klatek lub przynajmniej przegapisz 16 ms dla bieżącej ramki. Pomysł polega na zwiększeniu priorytetu, co nieznacznie oznacza, że ​​system Windows częściej wraca do Twojej aplikacji, aby nie upuścić tylu klatek.

Answer 2

Wierzę, że to, co widzisz jest debugger blokowanie niektórych stron, tak że nie mogą być zamienione być natychmiast dostępne dla debuggera. To przynosi pewne zastrzeżenia dla systemu operacyjnego w momencie przełączania procesów i ogólnie nie jest polecane.

Prawdopodobnie nie będzie chciał słyszeć mnie mówiąc to, ale nie jest dobrym sposobem, aby to naprawić, nawet jeśli nie.

Używaj VBO lub przynajmniej tablic werteksów, można oczekiwać, że można zoptymalizować optymalizację w sterowniku (spójrzmy prawdzie w oczy - listy wyświetlania stają się przestarzałe). Listy wyświetlania można łatwo zawijać w celu wygenerowania buforów wierzchołków, więc tylko niewielka część starego kodu wymaga modyfikacji. Można również użyć "bezbłędnej grafiki", która została zaprojektowana w celu uniknięcia błędów strony w sterowniku (GL_EXT_direct_state_access).

Answer 3

Czy masz kartę graficzną nVidia przypadkiem? nVidia OpenGL wydaje się używać innej implementacji, gdy jest dołączony do debuggera. Dla mnie wersja bez debuggera przecieka pamięć z szybkością do 1 MB/s w niektórych sytuacjach, w których rysuję do bufora przedniego i nie wywołuję glClear dla każdej ramki. Wersja debuggera jest absolutnie w porządku.

nie mam pojęcia, dlaczego to musi przeznaczyć i (czasami) deallocate tyle pamięci na scenie to nie zmienia.

I nie używam list wyświetlania.