Widzę, że OpenGL w wersji 3 i wyższej eliminuje użycie renderowania po stronie klienta. Tryb natychmiastowy został wyeliminowany, a tablice wierzchołków wydają się przestarzałe. Zamiast tego, jeśli dobrze rozumiem, VBO są głównym sposobem renderowania wierzchołków.
Chociaż widzę logikę kryjącą się za jednolitym sposobem renderowania wszystkiego, to czy przypadkiem VBO nie mają poważnych wad w porównaniu z tablicami wierzchołków? Myślałem, że VBO powinny być dużymi buforami zawierającymi> 1 MB danych. Co jeśli mam scenę, która ma dużo mniejszą geometrię? Mam wykres sceny z dużą liczbą węzłów, z których każdy wymaga własnej transformacji itp. Każdy węzeł powinien mieć możliwość oddzielnego usuwania, dodawania do osobnych itp. Wcześniej używałem tablic wierzchołków. Moje pierwsze pytanie brzmi więc, czy jeśli przejdę na VBO, będzie więcej obciążeń dla obiektów wykresu sceny, ponieważ dla każdego obiektu należy przydzielić VBO.
Innym problemem jest to, że geometria, którą renderuję, może być bardzo dynamiczna. W najgorszym przypadku mogą zdarzyć się chwile, gdy cała geometria będzie musiała zostać ponownie wysłana do każdej klatki przez pewien okres czasu. Czy VBO będą miały gorszą wydajność niż tablice wierzchołków w tym przypadku użycia, czy też VBO w najgorszym przypadku wykonują tyle samo pracy, co tablice wierzchołków, ale nie więcej?
Tak więc, w bardziej zwięzłym formacie, moje pytania są następujące:
1) Czy istnieje znaczny narzut związany z przydzielaniem / zwalnianiem VBO (mam na myśli sam fakt utworzenia bufora)?
2) Jeśli aktualizuję dane z procesora w każdej ramce, czy może to być znacznie gorsze niż w przypadku użycia tablic wierzchołków?
Na koniec chciałbym wiedzieć:
3) Jeśli odpowiedź na którekolwiek z powyższych pytań brzmi „tak”, po co odrzucać inne tryby renderowania, które mogłyby mieć przewagę nad VBO? Czy czegoś mi brakuje, na przykład technik, które powinienem zastosować, aby zmniejszyć niektóre z tych potencjalnych kosztów alokacji itp.?
4) Czy odpowiedzi na którekolwiek z tych pytań ulegają zasadniczej zmianie w zależności od używanej wersji OpenGL? Jeśli zmienię kod mojego kodu na zgodny z OpenGL 3 lub 4, używając VBO w sposób, który jest wydajny, czy te same techniki będą działały dobrze w OpenGL 2, czy też jest prawdopodobne, że niektóre techniki są znacznie szybsze w OpenGL 3 + i inne z OpenGL 2?
Zadałem to pytanie na temat przepełnienia stosu, ale przesyłam ponownie tutaj, ponieważ zdałem sobie sprawę, że ta strona może być bardziej odpowiednia do mojego pytania.
źródło
Odpowiedzi:
Zdefiniuj „znaczny”. Na ogół mądrze jest nie tworzyć ich w środku ramek; należy je skonfigurować podczas inicjalizacji lub gdziekolwiek. Ale dotyczy to większości obiektów OpenGL, takich jak tekstury, bufory renderujące lub shadery.
Czy to możliwe Tak. OpenGL definiuje funkcjonalność, a nie wydajność . Rzeczywiście można znacznie spowolnić. Lub możesz przyspieszyć. Wszystko zależy od tego, jak z niego korzystasz.
Wiki OpenGL ma dobry artykuł na temat prawidłowego przesyłania danych .
Po pierwsze, nie były po prostu przestarzałe. Wycofanie oznacza oznaczenie czegoś jako „do usunięcia” w przyszłych wersjach. Zostały one przestarzałe w wersji 3.0 i usunięte w wersji 3.1 i wyższej.
Po drugie, ARB ogólnie wyjaśnił powód, dla którego usunęli rzeczy z OpenGL. To sprawia, że specyfikacja jest mniejsza i prostsza. To sprawia, że interfejs API jest mniejszy i bardziej usprawniony. Ułatwia to wiedzieć, jakich interfejsów API powinieneś używać; 2.1 miał 4 sposoby dostarczania danych wierzchołków; 3.1+ ma 1. Pozbywa się wielu cruft. Itp.
Mniej więcej nie. Tylko w MacOSX różnica między wersją 3.1 + core i wersjami starszymi niż 3.0 naprawdę widocznie. Profil zgodności jest implementowany przez wszystkie sterowniki dla systemu Linux i Windows, więc można założyć, że profil podstawowy tych sterowników w rzeczywistości dodaje tylko kontrole, aby uniemożliwić wywoływanie funkcji zgodności.
W systemie Mac OSX 10.7 dostępny jest rdzeń GL 3.2, ale nie profil zgodności. To niekoniecznie znaczy nic dla technik wydajnościowych w porównaniu z innymi. Ale to oznacza, że jeśli istnieją różnice, to na tej platformie je zobaczysz.
źródło
Sposób, w jaki działa OpenGL, za każdym razem, gdy używasz danych spoza VBO, sterownik musi wykonać jego kopię - w praktyce tworzenie tymczasowego VBO - ponieważ nic nie powstrzymuje cię przed modyfikowaniem twoich pustych tablic przestrzeni użytkownika między wywołaniami do OpenGL.
Być może istnieją pewne sztuczki po stronie kierowcy, aby przyspieszyć przydzielanie tymczasowe, ale nie można nic zrobić, aby uniknąć kopiowania.
Tak, tak długo, jak ty - i twórcy sterowników - robisz wszystko dobrze, VBO powinny (tm) zawsze po prostu przyspieszać.
źródło
glDrawRangeElementsdo rysowania każdego pojedynczego obiektu, czy jest to nieefektywne tak jak tablice wierzchołków?glDrawRangeElementswiele razy na każdym VBO z kilkoma VBO, zamiast nadawać każdemu obiektowi własne VBO?Nie do końca. Tablice wierzchołków są podstawą obiektów buforów wierzchołków. Przeniesiono tylko pamięć z klienta na serwer.
Scal mniejsze zestawy geometrii w większe VBO. Nie ma potrzeby posiadania jednego VBO na partię geometrii. Możesz doskonale adresować podzbiory VBO do renderowania. Użyj parametru nonzereo dla parametru gl… Wskaźnik danych.
W tym celu dostępne są flagi użycia buforów GL_DYNAMIC_DRAW i GL_STREAM_DRAW.
Ponieważ nie ma żadnych zalet. Dane geometryczne należy w każdym przypadku przesłać do GPU. Używanie zwykłej tablicy wierzchołków po stronie klienta nadal spowoduje przeniesienie DMA do GPU, a tryb natychmiastowy zbuduje również partię do przeniesienia w pierwszej kolejności.
Nie ma absolutnie żadnej korzyści z nieużywania VBO.
źródło