Zadbaj o dobrą organizację dzięki kolekcji
Zapisuj i kategoryzuj treści zgodnie ze swoimi preferencjami.
Za pomocą profilowania klatek możesz zdiagnozować kilka możliwych problemów z wydajnością związanych z wierzchołkami. W panelu Polecenia możesz wyświetlić wszystkie wywołania rysowania, które gra wykonuje w danej klatce, oraz liczbę narysowanych elementów pierwotnych w każdym wywołaniu rysowania. Może to dać przybliżoną liczbę wierzchołków przesłanych w jednej klatce.
Rysunek 1. Widok profilowania klatek dla pojedynczegoglDrawElements połączenia, pokazujący 2718 narysowanych prymitywów trójkątnych
Kompresja atrybutów wierzchołków
Jednym z częstych problemów, z jakimi może się zmagać Twoja gra, jest duży średni rozmiar wierzchołka. Duża liczba wierzchołków przesłanych z dużym średnim rozmiarem wierzchołka powoduje dużą przepustowość odczytu pamięci wierzchołków, gdy są one odczytywane przez procesor graficzny.
Aby sprawdzić format wierzchołka dla danego wywołania rysowania, wykonaj te czynności:
Wybierz interesujące Cię losowanie.
Może to być typowe wywołanie rysowania sceny, wywołanie rysowania z dużą liczbą wierzchołków, wywołanie rysowania złożonego modelu postaci lub inny typ wywołania rysowania.
Przejdź do panelu Pipeline (Potok) i kliknij IA (Input Assembly) w przypadku zestawu wejściowego.
Określa format wierzchołków wchodzących do procesora graficznego.
Obserwuj serię atrybutów i ich formatów, np. R32G32B32_SFLOAT to 3-elementowa 32-bitowa liczba zmiennoprzecinkowa ze znakiem.
Ilustracja 2. Zestaw danych wejściowych dla wywołania rysowania z nieskompresowanymi atrybutami, co daje rozmiar wierzchołka wynoszący 56 bajtów
Atrybuty wierzchołków można często skompresować przy minimalnym pogorszeniu jakości rysowanych modeli. Zalecamy w szczególności:
Kompresowanie pozycji wierzchołków do 16-bitowych liczb zmiennoprzecinkowych o połowicznej precyzji
Kompresowanie współrzędnych tekstury UV do 16-bitowych liczb całkowitych bez znaku
Kompresowanie przestrzeni stycznej przez kodowanie wektorów normalnych, stycznych i binormalnych za pomocą kwaternionów.
W przypadku typów o mniejszej precyzji mogą być też rozpatrywane inne atrybuty różne, ale w każdym przypadku indywidualnie.
Dzielenie strumienia Vertex
Możesz też sprawdzić, czy strumienie atrybutów wierzchołków są odpowiednio podzielone. W architekturach renderowania kafelkowego, takich jak mobilne procesory graficzne, pozycje wierzchołków są najpierw używane w procesie dzielenia na koszyki, aby utworzyć koszyki elementów pierwotnych przetwarzanych w każdym kafelku. Jeśli atrybuty wierzchołków są przeplatane w jednym buforze, wszystkie dane wierzchołków są odczytywane do pamięci podręcznej na potrzeby dzielenia na przedziały, mimo że używane są tylko pozycje wierzchołków.
Aby zmniejszyć przepustowość pamięci odczytu wierzchołków i zwiększyć wydajność pamięci podręcznej, a tym samym skrócić czas spędzony na etapie dzielenia na przedziały, dane wierzchołków należy podzielić na 2 osobne strumienie: jeden dla pozycji wierzchołków, a drugi dla wszystkich innych atrybutów wierzchołków.
Aby sprawdzić, czy atrybuty wierzchołka są odpowiednio podzielone:
Wybierz interesujące Cię losowanie i zanotuj jego numer.
Może to być typowe wywołanie rysowania sceny, wywołanie rysowania z dużą liczbą wierzchołków, wywołanie rysowania złożonego modelu postaci lub inny typ wywołania rysowania.
Przejdź do panelu Pipeline (Potok) i kliknij IA (Input Assembly) w przypadku zestawu wejściowego. Określa format wierzchołków wchodzących do procesora graficznego.
Obserwuj powiązania atrybutów wierzchołków. Zwykle rosną one liniowo (0, 1, 2, 3 itd.), ale nie zawsze tak jest.
Pozycja wierzchołka jest zwykle pierwszym atrybutem wierzchołka na liście.
W panelu Stan znajdź symbol LastDrawInfos i rozwiń pasujący numer losowania. Następnie rozwiń BoundVertexBuffers dla tego wywołania rysowania.
Obserwuj bufory wierzchołków powiązane podczas danego wywołania rysowania, z indeksami
pasującymi do powiązań atrybutów wierzchołków z wcześniejszego etapu.
Rozwiń powiązania atrybutów wierzchołków wywołania rysowania i rozwiń bufory.
Zwróć uwagę na VulkanHandle w przypadku buforów, które reprezentują pamięć bazową, z której pochodzą źródła danych wierzchołków. Jeśli VulkanHandle są różne, oznacza to, że atrybuty pochodzą z różnych buforów bazowych. Jeśli VulkanHandle są takie same, ale przesunięcia są duże (np. większe niż 100), atrybuty mogą nadal pochodzić z różnych podbuforów, ale wymaga to dalszego zbadania.
Ilustracja 3. Zestaw wejściowy dla wywołania rysowania, z panelem stanu po prawej stronie pokazującym, że atrybuty w powiązaniu 0 i 1, pozycja wierzchołka i wektor normalny, współdzielą jeden bufor bazowy
Więcej informacji o dzieleniu strumienia wierzchołków i sposobach rozwiązywania tego problemu w różnych silnikach gier znajdziesz w naszym poście na blogu.
Treść strony i umieszczone na niej fragmenty kodu podlegają licencjom opisanym w Licencji na treści. Java i OpenJDK są znakami towarowymi lub zastrzeżonymi znakami towarowymi należącymi do firmy Oracle lub jej podmiotów stowarzyszonych.
Ostatnia aktualizacja: 2025-07-27 UTC.
[[["Łatwo zrozumieć","easyToUnderstand","thumb-up"],["Rozwiązało to mój problem","solvedMyProblem","thumb-up"],["Inne","otherUp","thumb-up"]],[["Brak potrzebnych mi informacji","missingTheInformationINeed","thumb-down"],["Zbyt skomplikowane / zbyt wiele czynności do wykonania","tooComplicatedTooManySteps","thumb-down"],["Nieaktualne treści","outOfDate","thumb-down"],["Problem z tłumaczeniem","translationIssue","thumb-down"],["Problem z przykładami/kodem","samplesCodeIssue","thumb-down"],["Inne","otherDown","thumb-down"]],["Ostatnia aktualizacja: 2025-07-27 UTC."],[],[],null,["# Analyze vertex formats\n\nYou may diagnose a few possible vertex-related performance problems through the\nuse of frame profiling. Use the **Commands** pane to view all of the draw calls\nyour game performs in a given frame and counts of primitives drawn per draw\ncall. This can give an approximation of the overall number of vertices submitted\nin a single frame.\n**Figure 1.** Frame profiling view for a single `glDrawElements` call, showing 2,718 triangle primitives drawn\n\nVertex attribute compression\n----------------------------\n\nOne common problem your game may face is a large average vertex size. A\nlarge number of vertices submitted with a high average vertex size results in a\nlarge vertex memory read bandwidth when read by the GPU.\n\nTo observe the vertex format for a given draw call, complete the following steps:\n\n1. Select a draw call of interest.\n\n This can be a typical draw call for the scene, a draw call with a large\n number of vertices, a draw call for a complex character model, or some other\n type of draw call.\n2. Navigate to the **Pipeline** pane, and click **IA** for input assembly.\n This defines the vertex format for vertices coming into the GPU.\n\n3. Observe a series of attributes and their formats; for example,\n `R32G32B32_SFLOAT` is a 3-component 32-bit signed float.\n\n**Figure 2.**Input assembly for a draw call, with uncompressed attributes resulting in a vertex size of 56 bytes\n\nFrequently, vertex attributes can be compressed with minimal reduction in the\nquality of the models drawn. In particular, we recommend:\n\n- Compressing vertex position to half-precision 16-bit floats\n- Compressing UV texture coordinates to 16-bit unsigned integer ushorts\n- Compressing the tangent space by encoding normal, tangent, and binormal vectors using quaternions\n\nOther miscellaneous attributes may also be considered for lower-precision types\non a case-by-case basis.\n\nVertex stream splitting\n-----------------------\n\nYou can also investigate whether vertex attribute streams are appropriately\nsplit. On tiled rendering architectures such as mobile GPUs, vertex positions\nare first used in a binning pass to create bins of primitives processed in each\ntile. If vertex attributes are interleaved into a single buffer, all vertex data\nis read into cache for binning, even though only vertex positions are used.\n\nTo reduce vertex read memory bandwidth and improve cache efficiency, and thus\nreduce time spent on the binning pass, vertex data should be split into two\nseparate streams, one for vertex positions, and one for all other vertex\nattributes.\n\nTo investigate whether vertex attributes are appropriately split:\n\n1. Select a draw call of interest, and note the draw call number.\n\n This can be a typical draw call for the scene, a draw call with a large\n number of vertices, a draw call for a complex character model, or some other\n type of draw call.\n2. Navigate to the **Pipeline** pane, and click **IA** for input assembly. This\n defines the vertex format for vertices coming into the GPU.\n\n3. Observe the bindings of your vertex attributes; typically these might\n increase linearly (0, 1, 2, 3, etc.), but this is not always the case.\n Vertex position is typically the first vertex attribute listed.\n\n4. In the **State** pane, find the `LastDrawInfos` and expand the matching draw\n call number. Then, expand the `BoundVertexBuffers` for this draw call.\n\n5. Observe the vertex buffers bound during the given draw call, with indices\n matching the vertex attribute bindings from earlier.\n\n6. Expand the bindings for your draw call's vertex attributes, and expand the\n buffers.\n\n7. Observe the `VulkanHandle` for the buffers, which represent the underlying\n memory that the vertex data sources from. If the `VulkanHandle`s are\n different, this means the attributes originate from different underlying\n buffers. If the `VulkanHandle`s are the same but the offsets are large\n (for example, greater than 100), the attributes may still originate from\n different sub-buffers, but this requires further investigation.\n\n**Figure 3.**Input assembly for a draw call, with the state panel to the right showing that the attributes at binding 0 and 1, vertex position and normal, share a single underlying buffer\n\nFor more detail about vertex stream splitting and how to resolve it on various\ngame engines, see our [blog post](/agi/frame-trace/link-to-Omars-blog-post) on the subject."]]
