Koleksiyonlar ile düzeninizi koruyun
İçeriği tercihlerinize göre kaydedin ve kategorilere ayırın.
Çerçeve profili kullanarak tepe noktasıyla ilgili birkaç olası performans sorununu teşhis edebilirsiniz. Oyununuzun belirli bir karede gerçekleştirdiği tüm çizim çağrılarını ve çizim çağrısı başına çizilen temel öğe sayılarını görüntülemek için Komutlar bölmesini kullanın. Bu, tek bir karede gönderilen toplam köşe noktası sayısına yaklaşık bir değer verebilir.
Şekil 1. 2.718 temel üçgenin çizildiği tek bir glDrawElements çağrısı için çerçeve profili oluşturma görünümü
Köşe özelliği sıkıştırma
Oyununuzda karşılaşabileceğiniz yaygın sorunlardan biri, büyük bir ortalama tepe boyutudur. Yüksek bir ortalama köşe boyutuyla gönderilen çok sayıda köşe noktası, GPU tarafından okunduğunda büyük bir köşe belleği okuma bant genişliğine neden olur.
Belirli bir çizim çağrısının köşe biçimini gözlemlemek için aşağıdaki adımları tamamlayın:
İlgi çeken bir çizim çağrısı seçin.
Bu, sahne için tipik bir çizim çağrısı, çok sayıda köşe noktası içeren bir çizim çağrısı, karmaşık bir karakter modeli için bir çizim çağrısı veya başka bir tür çizim çağrısı olabilir.
Ardışık düzen bölmesine gidin ve giriş düzeneği için IA'yı tıklayın.
Bu, GPU'ya gelen köşelerin köşe biçimini tanımlar.
Bir dizi özelliği ve biçimlerini gözlemleyin. Örneğin, R32G32B32_SFLOAT, 3 bileşenli 32 bit imzalı bir kayan değerdir.
Şekil 2. Sıkıştırılmamış özelliklerle 56 bayt köşe boyutuna neden olan bir çizim çağrısı için giriş derlemesi
Sık sık, tepe noktası özellikleri çizilen modellerin kalitesinde çok az bir düşüşle sıkıştırılabilir. Özellikle şunları yapmanızı öneririz:
Köşe konumu yarı duyarlı 16 bit kayan öğelere sıkıştırılıyor
UV doku koordinatlarını 16 bit imzasız tamsayı ushort'lere sıkıştırma
Kuternyonlar kullanarak normal, teğet ve binormal vektörleri kodlayarak teğet alanını sıkıştırma
Düşük hassasiyetli türler için duruma göre diğer çeşitli özellikler de değerlendirilebilir.
Köşe akışı bölme
Köşe özelliği akışlarının düzgün şekilde bölünüp bölünmediğini de araştırabilirsiniz. Mobil GPU'lar gibi parçalı oluşturma mimarilerinde köşe konumları, ilk olarak her bir parçada işlenen temel öğe kutuları oluşturmak için toplama geçişinde kullanılır. Köşe özellikleri tek bir arabelleğe yerleştirilirse yalnızca köşe konumları kullanılsa bile tüm köşe verileri, birleştirme için önbelleğe okunur.
Köşe okuma belleği bant genişliğini ve önbellek verimliliğini artırmak ve böylece, bağlama geçişinde harcanan süreyi azaltmak için tepe noktası verileri, biri köşe konumları, diğer tüm köşe özellikleri için olmak üzere iki ayrı akışa bölünmelidir.
Köşe özelliklerinin uygun şekilde bölünüp bölünmediğini araştırmak için:
İlginizi çeken bir çizim çağrısı seçin ve çizim çağrısı numarasını not edin.
Bu, sahne için tipik bir çizim çağrısı, çok sayıda köşe noktası içeren bir çizim çağrısı, karmaşık bir karakter modeli için bir çizim çağrısı veya başka bir tür çizim çağrısı olabilir.
Ardışık düzen bölmesine gidin ve giriş düzeneği için IA'yı tıklayın. Bu, GPU'ya gelen köşelerin köşe biçimini tanımlar.
Köşe özelliklerinizin bağlamalarını inceleyin. Genellikle bunlar doğrusal olarak artış gösterebilir (0, 1, 2, 3 vb.) ancak bu durum her zaman geçerli değildir.
Köşe konumu genellikle listelenen ilk köşe özelliğidir.
State (Durum) bölmesinde, LastDrawInfos değerini bulun ve eşleşen çizim çağrısı numarasını genişletin. Ardından, bu çizim çağrısı için BoundVertexBuffers öğesini genişletin.
Belirtilen çizim çağrısı sırasında bağlı köşe arabelleklerini, önceki köşe özellik bağlamalarıyla eşleşen dizinleri gözlemleyin.
Çizim çağrınızın köşe özellikleri için bağlamaları ve arabellekleri genişletin.
Köşe verilerinin kaynağı olan temel belleği temsil eden arabellekler için VulkanHandle gözlemleyin. VulkanHandle değerleri farklıysa bu, özelliklerin temel alınan farklı arabelleklerden kaynaklandığı anlamına gelir. VulkanHandle değerleri aynıysa ancak ofsetler büyükse (örneğin, 100'den fazla) özellikler yine de farklı alt arabelleklerden kaynaklanabilir ancak bunun için daha fazla araştırma yapılması gerekir.
Şekil 3. Çizim çağrısı için giriş düzeneği. Sağdaki durum paneli, bağlama 0 ve 1, köşe konumu ve normal özelliklerinin tek bir temel arabelleği paylaştığını gösteriyor.
Köşe akışı bölme ve bunun çeşitli oyun motorlarında nasıl çözüleceği hakkında daha fazla ayrıntı için konuyla ilgili blog yayınımıza bakın.
Bu sayfadaki içerik ve kod örnekleri, İçerik Lisansı sayfasında açıklanan lisanslara tabidir. Java ve OpenJDK, Oracle ve/veya satış ortaklarının tescilli ticari markasıdır.
Son güncelleme tarihi: 2025-07-27 UTC.
[null,null,["Son güncelleme tarihi: 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."]]
