Mantieni tutto organizzato con le raccolte
Salva e classifica i contenuti in base alle tue preferenze.
AGI Frame Profiler ti consente di esaminare i tuoi mesh selezionando una chiamata di disegno da una delle nostre pass di rendering e passando per la sezione Vertex Shader o la sezione Fragment Shader del riquadro Pipeline.
Qui troverai statistiche utili derivanti dall'analisi statica del codice dello mesh, nonché dall'assemblaggio Standard Portable Intermediate Representation (SPIR-V) a cui è stato compilato il nostro GLSL. C'è anche una scheda per visualizzare una rappresentazione del GLSL originale (con nomi generati dal compilatore per variabili, funzioni e altro) che è stato decompilato con SPIR-V Cross, per fornire ulteriore contesto per SPIR-V.
Analisi statica
Figura 1. Sottotitoli codificati??
Utilizza i contatori dell'analisi statici per visualizzare le operazioni di basso livello nello mesh.
Istruzioni ALU: questo conteggio mostra il numero di operazioni ALU (somma, moltiplica, divisioni e altro) in esecuzione all'interno dello Shader ed è un buon indicatore della complessità dello mesh. Prova a ridurre al minimo questo valore.
Il refactoring dei calcoli comuni o semplificare quelli eseguiti nello Shader può aiutare a ridurre il numero di istruzioni necessarie.
Istruzioni per le texture: questo conteggio mostra il numero di volte in cui il campionamento delle texture viene eseguito nelloshadowr.
Il campionamento delle texture può essere costoso a seconda del tipo di texture
da cui viene campionato, quindi eseguire un controllo incrociato del codice dello mesh con le texture associate presenti nella sezione Set di descrittori può fornire ulteriori
informazioni sui tipi di texture utilizzate.
Evita l'accesso casuale durante il campionamento delle texture, poiché questo comportamento non è ideale per la memorizzazione nella cache delle texture.
Istruzioni per i rami: questo conteggio mostra il numero di operazioni relative ai rami nello Shader. La riduzione al minimo della diramazione è ideale sui processori parallelizzati come la GPU e può persino aiutare il compilatore a trovare ulteriori ottimizzazioni:
Utilizza funzioni come min, max e clamp per evitare di dover suddividere i valori numerici.
Testa il costo del calcolo sulla diramazione. Poiché entrambi i percorsi di un ramo vengono eseguiti in molte architetture, ci sono molti scenari in cui eseguire sempre il calcolo è più veloce che saltare il calcolo con un ramo.
Registri temporanei: si tratta di registri veloci on-core utilizzati
per conservare i risultati delle operazioni intermedie richieste dai calcoli sulla GPU. Esiste un limite al numero di registri disponibili per i calcoli prima che la GPU debba sondare utilizzando altra memoria off-core per archiviare i valori intermedi, riducendo così le prestazioni complessive. (Questo limite varia a seconda del modello di GPU).
Il numero di registri temporanei utilizzati potrebbe essere maggiore del previsto se il compilatore Shader esegue operazioni come lo svolgimento dei loop, quindi è consigliabile eseguire un controllo incrociato di questo valore con SPIR-V o un GLSL decompilato per vedere cosa sta facendo il codice.
Analisi del codice Shader
Esamina il codice dello mesh decompilato per determinare se sono possibili eventuali miglioramenti.
Figura 2. Sottotitoli codificati??
Precisione: la precisione delle variabili dello smartwatch può influire sulle prestazioni della GPU della tua applicazione.
Se possibile, prova a utilizzare il modificatore di precisione mediump sulle variabili, poiché le variabili a 16 bit con precisione media (mediump) sono in genere più veloci ed efficienti in termini di potenza rispetto alle variabili a 32 bit a precisione massima (highp).
Se nello mesh non sono presenti qualificatori di precisione nelle dichiarazioni
delle variabili o nella parte superiore dello mesh con un
precision precision-qualifier type, il valore predefinito è la precisione completa
(highp). Assicurati di controllare anche le dichiarazioni delle variabili.
L'utilizzo di mediump per l'output di Vertex Shaper è preferito anche per gli stessi motivi descritti sopra e offre anche il vantaggio di ridurre la larghezza di banda della memoria e l'utilizzo potenzialmente temporaneo del registro necessario per eseguire l'interpolazione.
Buffer uniformi: cerca di ridurre il più possibile le dimensioni di Uniform Buffer (mantenendo al contempo le regole di allineamento). Ciò consente di rendere i calcoli più compatibili con la memorizzazione nella cache e di consentire potenzialmente la promozione di dati uniformi a registri on-core più veloci.
Rimuovi gli output di Vertex Shader inutilizzati: se gli output di Vertex Shader sono inutilizzati nello Shader frammento, rimuovili dallo Shader per liberare larghezza di banda di memoria e registri temporanei.
Sposta il calcolo da Fragment Shader a Vertex Shader: se il codice di shadowing dei frammenti esegue calcoli indipendenti dallo stato specifici del frammento ombreggiato (o che può essere interpolato correttamente), l'ideale è spostarlo nel Vertex Shader. Il motivo di ciò è che nella maggior parte delle app, Vertex Shader viene eseguito con una frequenza molto minore rispetto allo Shader dei frammenti.
I campioni di contenuti e codice in questa pagina sono soggetti alle licenze descritte nella Licenza per i contenuti. Java e OpenJDK sono marchi o marchi registrati di Oracle e/o delle sue società consociate.
Ultimo aggiornamento 2025-07-27 UTC.
[null,null,["Ultimo aggiornamento 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."]]
