Koleksiyonlar ile düzeninizi koruyun
İçeriği tercihlerinize göre kaydedin ve kategorilere ayırın.
AGI Frame Profiler, oluşturma geçişlerimizin birinden bir çizim çağrısı seçip Vertex Shader (Vertex Gölgelendirici) bölümünden ya da Pipeline (Pipeline) bölmesinin Fragment Shader (Parça Gölgelendirici) bölümünden yararlanarak gölgelendiricilerinizi araştırmanıza olanak tanır.
Burada, gölgelendirici kodunun statik analizinden ve GLSL'mizin derlendiği Standart Taşınabilir Ara Gösterim (SPIR-V) derlemesinden elde edilen yararlı istatistikleri bulabilirsiniz. SPIR-V için ek bağlam sağlamak amacıyla SPIR-V Cross ile ayrıştırılan orijinal GLSL gösterimini (değişkenler, işlevler ve daha fazlası için derleyici tarafından oluşturulan adlarla) görüntülemek için de bir sekme bulunur.
Statik analiz
Şekil 1. Başlık??
Gölgelendiricideki alt düzey işlemleri görüntülemek için statik analiz sayaçları kullanın.
ALU Talimatları: Bu sayı, gölgelendirici içinde yürütülmekte olan ALU işlemlerinin (ekleme, çarpma, bölme vb.) sayısını gösterir ve gölgelendiricinin ne kadar karmaşık olduğunu iyi bir şekilde gösterir. Bu değeri en aza indirmeye çalışın.
Yaygın hesaplamaları yeniden düzenlemek veya gölgelendiricide yapılan hesaplamaları basitleştirmek, gereken talimat sayısını azaltmaya yardımcı olabilir.
Doku Talimatları: Bu sayı, gölgelendiricide doku örneğinin kaç kez gerçekleştiğini gösterir.
Doku örneklemesi, örneklenen dokuların türüne bağlı olarak pahalı olabilir. Bu nedenle, gölgelendirici kodu ile Açıklayıcı Kümeleri bölümündeki sınırlanmış dokulara çapraz referans alınması, kullanılan doku türleri hakkında daha fazla bilgi sağlayabilir.
Doku önbelleğe alma için bu davranış ideal olmadığından, dokuları örnekleme sırasında rastgele erişimden kaçının.
Dal Talimatları: Bu sayı, gölgelendiricideki dal işlemlerinin sayısını gösterir. Dallandırmayı en aza indirmek, GPU gibi paralel işlemcilerde idealdir ve hatta derleyicinin ek optimizasyonlar bulmasına yardımcı olabilir:
Sayısal değerleri kollara ayırma ihtiyacını ortadan kaldırmak için min, max ve clamp gibi işlevleri kullanın.
Kollara ayırma üzerinden hesaplama maliyetini test etme. Bir şubenin her iki yolu da birçok mimaride yürütüldüğünden her zaman hesaplamayı bir dal kullanarak atlamaktan daha hızlı olduğu birçok senaryo vardır.
Geçici Kayıtlar: GPU'daki hesaplamaların gerektirdiği ara işlemlerin sonuçlarını tutmak için kullanılan hızlı ve çekirdekli kayıtlardır. GPU'nun ara değerleri depolamak için diğer çekirdek dışı belleği kullanmanıza gerek kalmadan hesaplamalar için kullanılabilecek kayıt sayısının bir sınırı vardır. Bu da genel performansı düşürür. (Bu sınır, GPU modeline göre değişir.)
Gölgelendirici derleyicisi, döngüleri açma gibi işlemler gerçekleştiriyorsa kullanılan geçici kayıt sayısı beklenenden yüksek olabilir. Bu nedenle, kodun ne yaptığını görmek için bu değeri SPIR-V veya derlenmiş GLSL ile çapraz referans olarak yapmak iyi bir fikirdir.
Gölgelendirici kodu analizi
Olası iyileştirmelerin mümkün olup olmadığını belirlemek için derlenmiş gölgelendirici kodunun kendisini araştırın.
Orta hassasiyete sahip (mediump) 16 bit değişkenler genellikle tam hassasiyete (highp) (highp) 32 bit değişkenlerden daha hızlı ve güç açısından daha verimli olduğundan, mümkün olduğunda değişkenlerde mediump hassasiyet değiştiricisini kullanmayı deneyin.
Değişken bildirimlerde gölgelendiricide veya gölgelendiricinin üst kısmında precision precision-qualifier type ile birlikte herhangi bir hassasiyet niteleyici görmüyorsanız varsayılan olarak tam hassasiyet (highp) kullanılır. Değişken bildirimlerine de baktığınızdan emin olun.
Köşe gölgelendirici çıkışı için mediump kullanılması da yukarıda açıklanan nedenlerle tercih edilir. Bu ayrıca, interpolasyon yapmak için gereken bellek bant genişliğini ve geçici olarak kayıt kullanımını azaltma avantajına da sahiptir.
Tek Tip Arabellekler: Tek Tip Arabelleklerin boyutunu mümkün olduğunca küçük tutmaya çalışın (hizalama kurallarını koruyarak). Bu da hesaplamaları önbelleğe almayla daha uyumlu hale getirmeye yardımcı olur ve tek tip verilerin daha hızlı çekirdek üzerindeki kayıtlara tanıtılmasını sağlar.
Kullanılmayan Vertex Shader Çıkışlarını kaldırın: Köşe gölgelendirici çıkışlarının, parça gölgelendiricide kullanılmadığını fark ederseniz bellek bant genişliğinde yer açmak ve geçici kayıtlarda yer açmak için bunları gölgelendiriciden kaldırın.
İşlemi Parça Gölgelendirici'den Köşe Gölgelendirici'ye taşıma: Parça gölgelendirici kodu, gölgelenen parçaya özel durumdan bağımsız hesaplamalar yapıyorsa (veya düzgün bir şekilde interpolasyon yapabiliyorsa) tepe gölgelendiricisine taşımak en iyi seçenektir. Bunun nedeni, çoğu uygulamada tepe gölgelendiricisinin, parça gölgelendiriciye kıyasla çok daha az çalıştırılmasıdır.
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 shader performance\n\nAGI Frame Profiler allows you to investigate your shaders by\nselecting a draw call from one of our render passes, and going through either\nthe **Vertex Shader** section or **Fragment Shader** section of the **Pipeline**\npane.\n\nHere you'll find useful statistics coming from static analysis of the shader\ncode, as well as the [Standard Portable Intermediate Representation](https://en.wikipedia.org/wiki/Standard_Portable_Intermediate_Representation)\n(SPIR-V) assembly that our GLSL has been compiled down to. There's also a tab\nfor viewing a representation of the original GLSL (with compiler generated names for variables, functions, and more) that was decompiled with SPIR-V Cross, to provide additional context for the SPIR-V.\n\nStatic analysis\n---------------\n\n**Figure 1.**Caption??\n\nUse static analysis counters to view low-level operations in the shader.\n\n- **ALU Instructions**: This count shows the number of ALU operations\n (adds, multiplies, divisions, and more) are being executed within the\n shader, and is a good proxy for how complex the shader is. Try to minimize\n this value.\n\n Refactoring common computations or simplify computations done in the\n shader can help reduce the number of instructions needed.\n- **Texture Instructions**: This count shows the number of times texture\n sampling occurs in the shader.\n\n - Texture sampling can be expensive depending on the type of textures being sampled from, so cross-referencing the shader code with the bound textures found in the **Descriptor Sets** section can provide more information on the types of textures being used.\n - Avoid random access when sampling textures, because this behavior is not ideal for texture-caching.\n- **Branch Instructions**: This count shows the number of branch operations\n in the shader. Minimizing branching is ideal on parallelized processors such\n as the GPU, and can even help the compiler find additional optimizations:\n\n - Use functions such as `min`, `max`, and `clamp` to avoid needing to branch on numeric values.\n - Test the cost of computation over branching. Because both paths of a branch are executed in many architectures, there are many scenarios where always doing the computation is faster than skipping over the computation with a branch.\n- **Temporary Registers**: These are fast, on-core registers that are used to\n hold the results of intermediate operations required by computations on the\n GPU. There is a limit to the number of registers available for computations\n before the GPU has to spill over into using other off-core memory to store\n intermediate values, reducing overall performance. (This limit varies\n depending on the GPU model.)\n\n The number of temporary registers used may be higher than expected if the\n shader compiler performs operations such as unrolling loops, so it's good\n to cross-reference this value with the SPIR-V or decompiled GLSL to see what\n the code is doing.\n\n### Shader code analysis\n\nInvestigate the decompiled shader code itself to determine if there any\npotential improvements are possible.\n**Figure 2.**Caption??\n\n- **Precision** : The precision of shader variables can impact the GPU performance of your application.\n - Try using the `mediump` precision modifier on variables wherever possible, since medium precision (`mediump`) 16-bit variables are usually faster and more power efficient than full precision (`highp`) 32-bit variables.\n - If you don't see any precision qualifiers in the shader on variable declarations, or at the top of the shader with a `precision precision-qualifier type`, it defaults to full precision (`highp`). Make sure to look at variable declarations as well.\n - Using `mediump` for vertex shader output is also preferred for the same reasons described above, and also has the benefit of reducing memory bandwidth and potentially temporary register usage needed to do interpolation.\n- **Uniform Buffers** : Try to keep the size of **Uniform Buffers** as small as possible (while maintaining alignment rules). This helps make computations more compatible with caching and potentially allow for uniform data to be promoted to faster on-core registers.\n- **Remove unused Vertex Shader Outputs**: If you find vertex shader outputs\n being unused in the fragment shader, remove them from the shader to free up\n memory bandwidth and temporary registers.\n\n- **Move computation from Fragment Shader to Vertex Shader**: If the fragment\n shader code performs computations that are independent of state specific to\n the fragment being shaded (or can be interpolated properly), moving it to\n the vertex shader is ideal. The reason for this is that in most apps, the\n vertex shader is run much less frequently compared to the fragment shader."]]
