glDrawElements z GL_LINES wymusza gleRunVertexSubmitARM? (lub: dlaczego rysowanie szkieletów jest powolne na iOS?)

Question

podczas wykonywania niektórych testów dla małego projektu na iPhone/iPad, nad którym pracuję, zauważyłem, że w rysowaniu modeli szkieletowych za pomocą glDrawElements za pomocą GL_LINES występuje duże obniżenie wydajności procesora .

Jest to scenariusz:

• model z 640 wierzchołków (4 pływaków na położenie, 3 pływaków do normalnych, żadnych problemów wyrównanie ... wszystko na 4 bajty granice)
• 3840 indeksów (unsigned short)
• oba wierzchołki i indeksy użyciu VBOs (bez VAO)
• powyższy wzór narysowany glDrawElements z GL_TRIANGLES działa dobrze

Następnie:

• sam model z 640 wierzchołkach
• 2560 indeksów
• VBOs i bez vào
• narysowany glDrawElements z GL_LINES wyzwala ciągłych połączeń do gleRunVertexSubmitARM wykorzystanie procesora niebo rakiety ...

W obu przypadkach modele wyglądają tak, jak powinny i brak śladów po błędzie ...

Wygląda na to, że problem jest zależny od urządzenia. Doświadczam tego na iPhone 3GS i iPhone 4, a nie na iPadzie 2 ani na symulatorze. Na iPadzie 2 frame-time CPU = 1ms i bez wywołań dla gleRunVertexSubmitARM, na kliencie iPhone 4 frame-time CPU = 12ms i ciągłym wywołaniu metody gleRunVertexSubmitARM.

Czy ktoś może wyjaśnić to zachowanie lub wskazać, jakie błędy mogę popełnić?

Każdy wgląd jest bardzo cenny. Dzięki z góry,

Francesco

Answer 1

nie

łatwa odpowiedź na nie jest łatwe pytanie chciałbym powiedzieć.

W każdym razie powód, dla którego 2 urządzenia tej samej "rodziny" zachowują się w różny sposób, może zależeć od wielu czynników.

Przede wszystkim zamontować one różne GPU (Jestem pewien, że już wiem, że to tak, przepraszam, to oczywiste), która przynosi następujące różnice:

• iPhone 4 i iPhone 3GS zamontować sam GPU The PowerVR SGX535
• IPAD 2 korzysta z PowerVR SGX543MP2

Przede wszystkim, ten ostatni jest ewolucją pierwsza z zupełnie innej przepustowości i nowszej architektury.

Samo to nie wyjaśnia wszystkiego, powód, dla którego zauważasz znacznie więcej połączeń z gleRunVertexSubmitARM, można wyjaśnić implementacji sterownika OpenGL wykonanej przez PowerVR na jego GPU, prawdopodobnie sterownik GPU SGX535 wykonuje operacje wymagane przez zaczepić o tę funkcję.

Ostatni, ale nie najmniej, wydajność mądry, rysunek z GL_LINES jest przez większość czasu bardzo nieefektywne z kilku powodów:

• Nie wykonuje żadnych ukrytych wykrywanie geometrii
• nie wykonuje żadnej twarzy uboju
• Przeczytanie (i moje własne doświadczenia sprzed 2-3 lat), użycie GL_LINE_WIDTH lub GL_LINE_SMOOTH powoduje, że sterownik wykonuje "programistyczny" rendering bez użycia przyspieszenia sprzętowego. Zależy to od GPU i jego implementacji sterownika OpenGL
• Po wypełnieniu wielokąta, sterownik może zoptymalizować operacje za pomocą "Hierarchicznego bufora głębi", przy czym GL_LINES to niemożliwe (znowu to zależy w dużej mierze od sterownika, ale jest to bardzo powszechny aspekt)
• Niektórzy kierowcy tłumaczą twoją sieć GL_LINES w trójkąty w momencie renderowania. To jest coś, czego nie mogę udowodnić, ale bardzo często poruszany temat z przyjaciółmi twórców gier z przeszłości.

Mam nadzieję, że pomogłem ci w pewien sposób.

Ciao Maurizio

Answer 2

Jestem na PC, ale czuję, że to jest istotne. Zauważyłem liczbę klatek na sekundę w trybie siatkowym: glPolygonMode (GL_FRONT_AND_BACK, GL_LINE) ...

był 10 razy wolniejszy, jeśli glEnable (GL_LINE_SMOOTH);

Możesz wyłączyć to za pomocą tego polecenia: glDisable (GL_LINE_SMOOTH);