Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Vous pouvez diagnostiquer certains problèmes de performances liés aux sommets à l'aide du profilage des frames. Utilisez le volet Commandes pour afficher tous les appels de dessin effectués par votre jeu dans un frame donné, ainsi que le nombre de primitives dessinées par appel de dessin. Cela peut donner une approximation du nombre total de sommets soumis dans un seul frame.
Figure 1 Vue du profilage de frame pour un seul appel glDrawElements, montrant 2 718 primitives de triangle dessinées
Compression des attributs de vertex
Un problème courant que votre jeu peut rencontrer est une taille moyenne de vertex élevée. Un grand nombre de sommets envoyés avec une taille de sommet moyenne élevée entraîne une grande bande passante de lecture de la mémoire des sommets lorsqu'ils sont lus par le GPU.
Pour observer le format des sommets pour un appel de dessin donné, procédez comme suit :
Sélectionnez un appel de dessin qui vous intéresse.
Il peut s'agir d'un appel de dessin typique pour la scène, d'un appel de dessin avec un grand nombre de sommets, d'un appel de dessin pour un modèle de personnage complexe ou d'un autre type d'appel de dessin.
Accédez au volet Pipeline, puis cliquez sur IA pour l'assemblage des entrées.
Cela définit le format des sommets entrant dans le GPU.
Observez une série d'attributs et leurs formats. Par exemple, R32G32B32_SFLOAT est un float signé de 32 bits à trois composants.
Figure 2. Assemblage d'entrée pour un appel de dessin, avec des attributs non compressés entraînant une taille de vertex de 56 octets
Les attributs de vertex peuvent souvent être compressés avec une réduction minimale de la qualité des modèles dessinés. En particulier, nous vous recommandons de :
Compression de la position des sommets en valeurs à virgule flottante 16 bits de demi-précision
Compression des coordonnées UV de texture en ushorts (entiers non signés de 16 bits)
Compression de l'espace tangent en encodant les vecteurs normaux, tangents et binormaux à l'aide de quaternions
D'autres attributs divers peuvent également être pris en compte pour les types de précision inférieure, au cas par cas.
Fractionnement du flux de sommets
Vous pouvez également vérifier si les flux d'attributs de vertex sont correctement fractionnés. Sur les architectures de rendu par blocs, telles que les GPU mobiles, les positions des sommets sont d'abord utilisées dans une passe de binning pour créer des bins de primitives traitées dans chaque bloc. Si les attributs de vertex sont entrelacés dans un seul tampon, toutes les données de vertex sont lues dans le cache pour le binning, même si seules les positions de vertex sont utilisées.
Pour réduire la bande passante de la mémoire de lecture des sommets et améliorer l'efficacité du cache, et donc réduire le temps passé sur la passe de binning, les données de sommet doivent être divisées en deux flux distincts : un pour les positions des sommets et un pour tous les autres attributs de sommet.
Pour vérifier si les attributs de vertex sont correctement fractionnés :
Sélectionnez un appel de dessin qui vous intéresse et notez son numéro.
Il peut s'agir d'un appel de dessin typique pour la scène, d'un appel de dessin avec un grand nombre de sommets, d'un appel de dessin pour un modèle de personnage complexe ou d'un autre type d'appel de dessin.
Accédez au volet Pipeline, puis cliquez sur IA pour l'assemblage des entrées. Cela définit le format des sommets entrant dans le GPU.
Observez les liaisons de vos attributs de vertex. Elles peuvent généralement augmenter de manière linéaire (0, 1, 2, 3, etc.), mais ce n'est pas toujours le cas.
La position du sommet est généralement le premier attribut de sommet listé.
Dans le volet État, recherchez LastDrawInfos et développez le numéro d'appel de tirage correspondant. Développez ensuite le BoundVertexBuffers pour cet appel de dessin.
Observez les tampons de vertex liés lors de l'appel de dessin donné, avec des index correspondant aux liaisons d'attributs de vertex précédentes.
Développez les liaisons pour les attributs de vertex de votre appel de dessin, puis développez les tampons.
Observez VulkanHandle pour les tampons, qui représentent la mémoire sous-jacente à partir de laquelle les sources de données de vertex sont issues. Si les VulkanHandle sont différents, cela signifie que les attributs proviennent de différents tampons sous-jacents. Si les VulkanHandle sont identiques, mais que les décalages sont importants (par exemple, supérieurs à 100), les attributs peuvent toujours provenir de différents sous-tampons, mais cela nécessite une analyse plus approfondie.
Figure 3. Assemblage d'entrée pour un appel de dessin, avec le panneau d'état à droite montrant que les attributs à la liaison 0 et 1, la position et la normale du vertex, partagent un seul tampon sous-jacent
Pour en savoir plus sur la division des flux de vertex et sur la manière de résoudre ce problème sur différents moteurs de jeu, consultez notre article de blog sur le sujet.
Le contenu et les exemples de code de cette page sont soumis aux licences décrites dans la Licence de contenu. Java et OpenJDK sont des marques ou des marques déposées d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/07/27 (UTC).
[[["Facile à comprendre","easyToUnderstand","thumb-up"],["J'ai pu résoudre mon problème","solvedMyProblem","thumb-up"],["Autre","otherUp","thumb-up"]],[["Il n'y a pas l'information dont j'ai besoin","missingTheInformationINeed","thumb-down"],["Trop compliqué/Trop d'étapes","tooComplicatedTooManySteps","thumb-down"],["Obsolète","outOfDate","thumb-down"],["Problème de traduction","translationIssue","thumb-down"],["Mauvais exemple/Erreur de code","samplesCodeIssue","thumb-down"],["Autre","otherDown","thumb-down"]],["Dernière mise à jour le 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."]]
