Mantenha tudo organizado com as coleções
Salve e categorize o conteúdo com base nas suas preferências.
É possível diagnosticar alguns problemas de desempenho relacionados ao vértice usando
a criação de perfil de frame. Use o painel Commands para ver todas as chamadas de desenho
que o jogo realiza em um determinado frame e a contagem de primitivos desenhados por chamada
de desenho. Isso pode fornecer uma aproximação do número total de vértices enviados
em um único frame.
Figura 1. Visualização de criação de perfil de frame para uma única
chamada glDrawElements, mostrando 2.718 primitivas de triângulos renderizadas.
Compactação de atributos do vértice
Um problema comum que seu jogo pode enfrentar é um tamanho médio de vértice grande. Um grande número de vértices enviados com um tamanho médio de vértice alto resulta em uma largura de banda de leitura de memória de vértice grande quando lido pela GPU.
Para observar o formato do vértice para uma determinada chamada de desenho, siga estas etapas:
Selecione uma chamada de desenho do seu interesse.
Pode ser uma chamada de desenho típica para a cena, uma chamada de desenho com um grande
número de vértices, uma chamada de desenho para um modelo de caracteres complexo ou algum outro
tipo de chamada de desenho.
Navegue até o painel Pipeline e clique em IA para montar a entrada.
Isso define o formato dos vértices que chegam à GPU.
Observe uma série de atributos e os respectivos formatos. Por exemplo,
R32G32B32_SFLOAT é um flutuante assinado de 32 bits de três componentes.
Figura 2. Conjunto de entrada para uma chamada de desenho, com atributos
não compactados, resultando em um tamanho de vértice de 56 bytes
Muitas vezes, os atributos de vértice podem ser compactados com redução mínima na
qualidade dos modelos desenhados. Especificamente, recomendamos:
Compactação da posição do vértice para flutuantes de 16 bits com meia precisão
Compactação de coordenadas de textura UV em ushorts inteiros não assinados de 16 bits
Compactar o espaço tangente codificando vetores normal, tangente e binormal
usando quatérnios
Outros atributos diversos também podem ser considerados para tipos de precisão mais baixa, de acordo com cada caso.
Divisão de fluxo de vértices
Você também pode investigar se os fluxos de atributos do vértice estão divididos corretamente. Em arquiteturas de renderização em blocos, como GPUs para dispositivos móveis, as posições de vértice
são usadas primeiro em um cartão de agrupamento para criar agrupamentos de primitivos processados em cada
bloco. Se os atributos de vértice forem intercalados em um único buffer, todos os dados do vértice serão lidos no cache para agrupamento, mesmo que apenas posições de vértice sejam usadas.
Para reduzir a largura de banda da memória de leitura do vértice e melhorar a eficiência do cache, reduzindo o tempo gasto na passagem de agrupamento, os dados de vértice precisam ser divididos em dois streams separados, um para posições de vértice e outro para todos os outros atributos de vértice.
Para investigar se os atributos de vértice estão divididos corretamente:
Selecione uma chamada de desenho e anote o número dela.
Pode ser uma chamada de desenho típica para a cena, uma chamada de desenho com um grande
número de vértices, uma chamada de desenho para um modelo de caracteres complexo ou algum outro
tipo de chamada de desenho.
Navegue até o painel Pipeline e clique em IA para montar a entrada. Isso
define o formato de vértice para vértices que entram na GPU.
Observe as vinculações dos atributos de vértice. Normalmente, elas podem
aumentar linearmente (0, 1, 2, 3 etc.), mas esse nem sempre é o caso.
A posição do vértice normalmente é o primeiro atributo de vértice listado.
No painel State, encontre o LastDrawInfos e expanda o número da chamada de desenho
correspondente. Em seguida, expanda a BoundVertexBuffers para essa chamada de desenho.
Observe os buffers de vértice vinculados durante a chamada de desenho determinada, com índices
correspondentes às vinculações de atributo de vértice anteriores.
Expanda as vinculações dos atributos de vértice da chamada de desenho e amplie os
buffers.
Observe o VulkanHandle para os buffers, que representam a memória
de origem dos dados do vértice. Se os VulkanHandles forem
diferentes, isso significa que os atributos se originam de diferentes
buffers. Se os VulkanHandles forem os mesmos, mas os deslocamentos forem grandes
(por exemplo, maiores que 100), os atributos ainda poderão se originar de
diferentes subbuffers, mas isso exige uma investigação mais aprofundada.
Figura 3. Conjunto de entrada para uma chamada de desenho, com o painel de estado à direita mostrando que os atributos na vinculação 0 e 1, posição do vértice e normal, compartilham um único buffer subjacente
Para mais detalhes sobre a divisão de fluxo de vértices e como resolver isso em vários
mecanismos de jogos, consulte nossa postagem do blog (link em inglês) sobre o assunto.
O conteúdo e os exemplos de código nesta página estão sujeitos às licenças descritas na Licença de conteúdo. Java e OpenJDK são marcas registradas da Oracle e/ou suas afiliadas.
Última atualização 2025-07-27 UTC.
[[["Fácil de entender","easyToUnderstand","thumb-up"],["Meu problema foi resolvido","solvedMyProblem","thumb-up"],["Outro","otherUp","thumb-up"]],[["Não contém as informações de que eu preciso","missingTheInformationINeed","thumb-down"],["Muito complicado / etapas demais","tooComplicatedTooManySteps","thumb-down"],["Desatualizado","outOfDate","thumb-down"],["Problema na tradução","translationIssue","thumb-down"],["Problema com as amostras / o código","samplesCodeIssue","thumb-down"],["Outro","otherDown","thumb-down"]],["Última atualização 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."]]