Tetap teratur dengan koleksi
Simpan dan kategorikan konten berdasarkan preferensi Anda.
Anda dapat mendiagnosis beberapa kemungkinan masalah performa terkait vertex melalui
penggunaan pembuatan profil frame. Gunakan panel Commands untuk melihat semua panggilan gambar
yang dilakukan game Anda dalam frame tertentu dan jumlah primitif yang digambar per panggilan
gambar. Ini dapat memberikan perkiraan jumlah keseluruhan verteks yang dikirimkan
dalam satu frame.
Gambar 1. Tampilan pembuatan profil frame untuk satu
panggilan glDrawElements, yang menampilkan 2.718 primitif segitiga yang digambar
Kompresi atribut vertex
Salah satu masalah umum yang mungkin dihadapi game Anda adalah ukuran verteks rata-rata yang besar. Sejumlah besar verteks yang dikirimkan dengan ukuran verteks rata-rata yang tinggi menghasilkan bandwidth pembacaan memori verteks yang besar saat dibaca oleh GPU.
Untuk mengamati format verteks untuk panggilan gambar tertentu, selesaikan langkah-langkah berikut:
Pilih panggilan gambar yang diinginkan.
Ini dapat berupa panggilan gambar standar untuk scene, panggilan gambar dengan
sejumlah besar verteks, panggilan gambar untuk model karakter kompleks, atau jenis
panggilan gambar lainnya.
Buka panel Pipeline, lalu klik IA untuk assembly input.
Ini menentukan format verteks untuk verteks yang masuk ke GPU.
Amati serangkaian atribut dan formatnya; misalnya,
R32G32B32_SFLOAT adalah float bertanda 32-bit 3 komponen.
Gambar 2. Assembly input untuk panggilan gambar, dengan atribut
yang tidak dikompresi menghasilkan ukuran verteks 56 byte
Sering kali, atribut verteks dapat dikompresi dengan pengurangan minimal pada
kualitas model yang digambar. Secara khusus, kami merekomendasikan:
Mengompresi posisi vertex ke float 16-bit presisi setengah
Mengompresi koordinat tekstur UV ke ushorts bilangan bulat tanpa tanda tangan 16-bit
Mengompresi ruang tangen dengan mengenkode vektor normal, tangen, dan binormal menggunakan tanda empat
Atribut lain-lain juga dapat dipertimbangkan untuk jenis presisi lebih rendah berdasarkan kasus per kasus.
Pemisahan aliran vertex
Anda juga dapat menyelidiki apakah aliran atribut verteks telah dipisahkan
dengan tepat. Pada arsitektur rendering bersusun seperti GPU seluler, posisi verteks
pertama kali digunakan di tahap pengelompokan untuk membuat kumpulan primitif yang diproses di setiap
kartu. Jika atribut verteks disisipi menjadi buffer tunggal, semua data verteks
akan dibaca ke dalam cache untuk pengelompokan, meskipun hanya posisi verteks yang digunakan.
Untuk mengurangi bandwidth memori pembacaan verteks dan meningkatkan efisiensi cache, serta
mengurangi waktu yang dihabiskan pada tahap pengelompokan, data verteks harus dibagi menjadi dua
aliran terpisah, satu untuk posisi verteks, dan satu untuk semua atribut
verteks lainnya.
Untuk menyelidiki apakah atribut verteks telah dipisahkan dengan tepat:
Pilih panggilan gambar yang diinginkan, dan catat nomor panggilan gambar tersebut.
Ini dapat berupa panggilan gambar standar untuk scene, panggilan gambar dengan
sejumlah besar verteks, panggilan gambar untuk model karakter kompleks, atau jenis
panggilan gambar lainnya.
Buka panel Pipeline, lalu klik IA untuk assembly input. Tindakan ini
menentukan format verteks untuk verteks yang masuk ke GPU.
Amati binding atribut verteks Anda; biasanya ini mungkin
meningkat secara linear (0, 1, 2, 3, dll.), tetapi tidak selalu demikian.
Posisi verteks biasanya adalah atribut verteks pertama yang tercantum.
Di panel State, temukan LastDrawInfos dan luaskan nomor panggilan
gambar yang cocok. Lalu, luaskan BoundVertexBuffers untuk panggilan gambar ini.
Amati buffer vertex yang terikat selama panggilan gambar yang diberikan, dengan indeks
yang cocok dengan binding atribut vertex dari sebelumnya.
Perluas binding untuk atribut verteks panggilan gambar Anda, dan perluas
buffer.
Amati VulkanHandle untuk buffer, yang mewakili memori
dasar yang menjadi sumber data vertex. Jika VulkanHandle
berbeda, ini berarti atribut berasal dari buffer dasar
yang berbeda. Jika VulkanHandle sama, tetapi offsetnya besar (misalnya, lebih besar dari 100), atribut mungkin masih berasal dari sub-buffer yang berbeda, tetapi hal ini memerlukan penyelidikan lebih lanjut.
Gambar 3. Perakitan input untuk panggilan gambar, dengan panel
status di sebelah kanan menunjukkan bahwa atribut pada binding 0 dan 1, posisi
verteks dan normal, berbagi satu buffer yang mendasarinya
Untuk detail selengkapnya tentang pemisahan aliran verteks dan cara menyelesaikannya di berbagai
mesin game, lihat postingan blog kami mengenai subjek tersebut.
Konten dan contoh kode di halaman ini tunduk kepada lisensi yang dijelaskan dalam Lisensi Konten. Java dan OpenJDK adalah merek dagang atau merek dagang terdaftar dari Oracle dan/atau afiliasinya.
Terakhir diperbarui pada 2025-07-27 UTC.
[null,null,["Terakhir diperbarui pada 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."]]
