Poglavlje 41: Eksterni Profiling Alati
← Prethodno Sledeće →

Poglavlje 41: Eksterni Profiling Alati

"Unreal Engine vam kaze STA je sporo. Eksterni alati vam kazu ZASTO je sporo."

Zasto ovo poglavlje menja pravila igre

U prethodnom poglavlju (Poglavlje 40) naucili ste kako da koristite sve sto vam UE5 pruza -- Stat komande, Unreal Insights, GPU Visualizer, Console Variables. To su mocni alati i trebali biste ih koristiti svakodnevno. Ali postoji granica onoga sto vam engine moze reci.

Zamislite sledeci scenario. Imate materijal koji je "skup" -- UE5 GPU Visualizer vam kaze da BasePass traje 4ms i da je taj materijal glavni krivac. Odlicno, znate gde je problem. Ali zasto je taj materijal skup? Da li je problem u broju instrukcija? U texture fetch-u koji promasi kes? U niskom occupancy-ju koji sprecava latency hiding? U branch divergenciji koja ubija pola warp-a?

UE5 vam to nece reci. Ne moze. Engine radi na nivou apstrakcije koji je iznad hardvera -- on zna koliko vremena GPU trosi na odredjeni pass, ali ne zna sta se desava unutar GPU-a dok taj pass radi.

Za to su vam potrebni eksterni profiling alati -- alati koji komuniciraju direktno sa GPU drajverima i GPU hardverom, i koji vam daju uvid u ono sto se zaista desava na silicijumu.

Ovo poglavlje pokriva cetiri glavna alata:

Svaki od ovih alata vam pruza informacije koje su nemoguce dobiti iz UE5. I svaki od njih je besplatan.

Ako ste procitali Poglavlje 08 o GPU arhitekturi, ovde cete konacno videti te koncepte -- warp-ove, occupancy, cache hit rate, memory bandwidth -- kao realne brojeve iz vaseg konkretnog frame-a.

Hajde da pocnemo.

41.1 Zasto Su Eksterni Alati Neophodni

Nivo apstrakcije -- kljucna razlika

Svaki alat za profiling radi na odredjenom nivou apstrakcije. Evo kako to izgleda za rendering:

Nivo 4 (Najvisi):  UE5 Stat komande
                    "BasePass: 4.2ms, Translucency: 1.8ms"
                    
Nivo 3:            UE5 GPU Visualizer / Unreal Insights
                    "Draw call #247 (SM_Building): 0.3ms"
                    
Nivo 2:            RenderDoc, PIX
                    "Draw call #247: VS inputs, PS outputs, 
                     bound textures, shader source, mesh data"
                    
Nivo 1 (Najnizi):  Nsight Graphics, RGP
                    "Draw call #247: 2048 warps, 62% occupancy,
                     L2 cache hit rate 78%, 340 GB/s bandwidth,
                     shader instruction hotspot at line 47"

Vidite hijerarhiju? Svaki nivo nize vam daje detaljniji uvid, ali zahteva vise znanja da biste protumacili podatke.

Nivo 4 (UE5 Stat komande) vam kaze: "GPU je spor u BasePass-u." Ovo je dovoljno da znate gde da gledate.

Nivo 3 (GPU Visualizer) vam kaze: "Konkretno, ovaj mesh sa ovim materijalom trosi najvise vremena." Sada znate koji objekat je problem.

Nivo 2 (RenderDoc/PIX) vam kaze: "Evo tacno sta se salje GPU-u za taj draw call -- ovi vertex-i, ove teksture, ovaj shader kod, ovaj output." Sada mozete da vidite sta GPU radi.

Nivo 1 (Nsight/RGP) vam kaze: "Evo kako GPU fizicki izvrsava taj shader -- ove instrukcije su bottleneck, occupancy je nizak jer shader koristi previse registara, L2 cache ima 40% miss rate jer su texture fetch-evi nekoherentni." Sada znate zasto je sporo i kako da popravite.

Sta UE5 built-in alati NE mogu da vam kazu

Hajde da budemo konkretni. Evo liste informacija koje su kriticne za duboku optimizaciju, a koje UE5 built-in alati jednostavno ne pruzaju:

Informacija Zasto je vazna Dostupna u UE5?
Per-draw-call GPU timing (tacan) Znati koliko tacno svaki draw call kosta Delimicno (GPU Visualizer, ali grupisano)
Shader instruction hotspots Koja linija shader koda je najskuplja Ne
Cache hit/miss rate (L1, L2) Da li su texture fetch-evi efikasni Ne
Occupancy po shaderu Koliko dobro GPU sakriva latenciju Ne
Memory bandwidth utilizacija Da li je VRAM bandwidth bottleneck Ne
Warp/wavefront divergencija Koliko efikasno warp-ovi koriste sve niti Ne
Register pressure po shaderu Koliko registara shader koristi (utice na occupancy) Ne
Stall razlozi Zasto GPU ceka (memory, execution, sync) Ne
Actual vs theoretical throughput Koliko ste blizu maksimuma hardvera Ne
Pipeline stage overlap Kako se vertex i pixel processing preklapaju Ne
Mesh topology na GPU Kako su trouglovi zaista raspordjeni posle transformacije Ne
Render target sadrzaj Sta tacno svaki G-Buffer kanal sadrzi za svaki piksel Ne

Ovo nisu ezotericne metrike za GPU inzenjere. Ovo su informacije koje vam direktno govore sta da promenite da biste poboljsali performanse.

Na primer, ako znate da vas shader ima 62% occupancy zato sto koristi 48 registara, mozete da smanjite broj registara (pojednostavite matematiku, koristite half precision) i podignete occupancy na 80%, sto moze da donese 20-30% poboljsanje bez ikakve vizuelne promene.

Bez eksternog alata, nikada ne biste znali da je occupancy problem. Videli biste samo "ovaj shader je spor" i mozda biste nasumicno pokusavali razne optimizacije.

Profiling workflow -- gde se eksterni alati uklapaju

Ispravan workflow za duboku optimizaciju izgleda ovako:

1. UE5 Stat komande / Unreal Insights
   -> Identifikujete da je GPU bottleneck
   -> Identifikujete koji pass je najskuplji

2. UE5 GPU Visualizer
   -> Identifikujete koji draw call / materijal je najskuplji

3. RenderDoc
   -> Inspektirate draw call u detalju
   -> Vidite tacno koje teksture, shadere, state-ove koristi
   -> Vizuelno verifikujete output svakog pass-a

4. Nsight Graphics / RGP
   -> Dobijete hardverske metrike za taj draw call
   -> Identifikujete tacan razlog zasto je spor
   -> Donosite informisanu odluku o optimizaciji

5. Implementirate promenu u UE5

6. Ponovite korake 1-4 da verifikujete poboljsanje

Ovaj workflow je iterativan i svaki korak suzava fokus. Pocinjete od "GPU je spor" i zavrsavate sa "linija 47 u pixel shaderu ima stall zbog L2 cache miss-a za anisotropic texture sample na kanalu Normal mape koja ima los mipmap streaming priority."

To je razlika izmedju nasumicne optimizacije i informisane optimizacije. I ta razlika moze da ustedite sate, dane, pa i nedelje rada.

41.2 RenderDoc -- GPU Debugger Koji Svaki Developer Treba da Poznaje

Sta je RenderDoc?

RenderDoc je besplatan, open-source GPU debugger koji vam omogucava da uhvatite jedan frame vaseg renderinga i zatim ga inspektirate u potpunom detalju -- svaki draw call, svaka tekstura, svaki shader, svaki vertex, svaki piksel.

Zamislite da mozete da "zamrznete vreme" u vasem renderingu. Jedan frame -- 16.67 milisekundi -- se zaustavi, i vi mozete da hodate kroz njega korak po korak. Vidite kako se scena gradi od praznog ekrana do finalne slike, draw call po draw call. Za svaki draw call mozete da vidite tacno sta je GPU primio kao input i sta je proizveo kao output.

RenderDoc je razvio Baldur Karlsson (bivsi programer u Crytek-u), i od tada je postao industrijski standard. Koriste ga razvojni timovi u Epic Games-u, Ubisoft-u, CD Projekt RED-u, i bezbroj drugih studija.

Kljucne cinjenice o RenderDoc-u:

Kako RenderDoc radi -- Frame Capture

Osnovna operacija u RenderDoc-u je frame capture (hvatanje frame-a). Kada pokrenete capture, RenderDoc presrece sve GPU komande koje vasa aplikacija izdaje tokom jednog frame-a:

  1. Sve draw call-ove (DrawIndexed, DrawInstanced, itd.)
  2. Sve dispatch call-ove (za compute shadere)
  3. Sve promene state-a (blending, depth stencil, rasterizer state)
  4. Sve bind operacije (teksture, buffer-i, shaderi)
  5. Sve clear operacije
  6. Sve copy/resolve operacije
  7. Sve barrier/transition operacije (za DX12/Vulkan)

Sve ove komande se snimaju zajedno sa svim podacima koje koriste -- vertex buffer-i, index buffer-i, constant buffer-i, teksture, shaderi. Rezultat je kompletna reprodukcija jednog frame-a.

Ovo znaci da posle capture-a mozete da zatvorite igru. Capture fajl (.rdc) sadrzi sve sto je potrebno za analizu. Mozete ga otvoriti sutra, mozete ga poslati kolegi, mozete ga otvoriti na drugom racunaru.

Integracija sa UE5 -- Korak po korak

UE5 ima ugradenu podrsku za RenderDoc, sto cini ceo proces veoma jednostavnim.

Korak 1: Instalacija

Preuzmite RenderDoc sa renderdoc.org i instalirajte ga. Zapamtite putanju instalacije -- UE5 ce je trebati.

Korak 2: Aktiviranje u UE5

  1. Otvorite vas UE5 projekat
  2. Idite na Edit > Project Settings
  3. U search bar upisite "RenderDoc"
  4. Omogucite RenderDoc plugin ako vec nije omogucen
  5. Restartujte editor

Alternativno, mozete omoguciti RenderDoc plugin kroz Edit > Plugins, potrazite "RenderDoc" u listi.

Korak 3: Konfiguracija

Posle restarta, u UE5 viewport-u ce se pojaviti nova ikonica -- mali logo RenderDoc-a u toolbar-u. Kliknite desnim klikom za opcije:

- Capture Frame: Uhvati sledeci frame
- Capture Settings:
  - Capture All Activity: Hvata sve, ukljucujuci editor UI
  - Capture Only Viewport: Hvata samo rendering viewport-a

Za vecinu slucajeva, Capture Only Viewport je ono sto zelite.

Korak 4: Hvatanje frame-a

  1. Postavite kameru na poziciju koja vas zanima
  2. Kliknite na RenderDoc ikonicu ili pritisnite predefinisani shortcut
  3. Frame se hvata -- primeticete kratak "freeze" od par stotina milisekundi
  4. RenderDoc se automatski otvara sa uhvacenim frame-om

Alternativno, mozete pokrenuti igru (Play in Editor ili Standalone) i koristiti tastere za capture. Podrazumevano, F12 ili PrintScreen ce triggerovati RenderDoc capture ako je plugin aktivan.

Vazna napomena: Kada koristite RenderDoc, UE5 mora da radi u odredjenom rendering mode-u. RenderDoc radi sa DirectX 11, DirectX 12, Vulkan, i OpenGL. Za DX12, uverite se da imate najnoviju verziju RenderDoc-a jer DX12 podrska stalno napreduje. Mnogi developeri za RenderDoc debugging koriste DX11 ili Vulkan backend jer je podrska najstabilnija.

Da promenite rendering backend:

1. Edit > Project Settings > Platforms > Windows
2. Default RHI: DirectX 11 (ili Vulkan)

Ili pokrenite editor sa command-line argumentom:

UE5Editor.exe MyProject.uproject -dx11
UE5Editor.exe MyProject.uproject -vulkan

Event Browser -- Vasija Mapa Frame-a

Kada otvorite capture u RenderDoc-u, prva stvar koju vidite je Event Browser -- hijerarhijski prikaz svih GPU dogadjaja u frame-u.

Za tipican UE5 frame, struktura izgleda otprilike ovako:

Frame #12847
├── BeginFrame
├── Scene
│   ├── PrePass (Depth Only)
│   │   ├── DrawIndexed (SM_Building_01) [Mesh, Material]
│   │   ├── DrawIndexed (SM_Building_02) [Mesh, Material]
│   │   ├── DrawIndexed (SM_Character) [Mesh, Material]
│   │   └── ... (stotine draw call-ova)
│   │
│   ├── BasePass
│   │   ├── DrawIndexed (SM_Building_01) [Mesh, Material]
│   │   ├── DrawIndexed (SM_Building_02) [Mesh, Material]
│   │   └── ...
│   │
│   ├── Lighting
│   │   ├── DirectionalLight
│   │   ├── PointLight_01
│   │   └── ...
│   │
│   ├── Translucency
│   │   ├── DrawIndexed (Particle_Smoke)
│   │   └── ...
│   │
│   └── PostProcessing
│       ├── TemporalAA / TSR
│       ├── Bloom
│       ├── Tonemapping
│       └── ...
│
└── EndFrame

Svaki od ovih dogadjaja je klikabilan. Kada kliknete na draw call, RenderDoc vam prikazuje sve o tom draw call-u:

Ovo je neverovatno mocno. Umesto da pogadjate koji materijal koristi koji shader, vi vidite tacno sta se desava.

Texture Viewer -- Inspekcija Svake Teksture

Texture Viewer je mozda najkoriscenija komponenta RenderDoc-a za rendering programere. Omogucava vam da vidite:

Input teksture:

Output render target-i:

G-Buffer A (GBufferA): World Normal (RGB) + Per-Object Data (A)
G-Buffer B (GBufferB): Metallic (R) + Specular (G) + Roughness (B)
G-Buffer C (GBufferC): Base Color (RGB) + AO (A)  
G-Buffer D (GBufferD): Custom Data
Scene Depth: Depth buffer
Velocity:    Motion vectors

Mozete da kliknete na bilo koji piksel u output-u i vidite:

Prakticni primer -- Debugging materijala:

Recimo da imate mesh cija Normal mapa izgleda cudno u igri. U RenderDoc-u:

  1. Uhvatite frame
  2. Nadjite draw call za taj mesh u Event Browser-u
  3. U Texture Viewer-u pogledajte bound Normal mapu
  4. Proverite da li je ispravna tekstura uopste bound-ovana
  5. Proverite kanale -- da li su R i G ispravni? Da li je format ispravan (DirectX Normal mapa vs OpenGL Normal mapa)?
  6. Pogledajte output u GBufferA -- da li su normali ispravno transformisani u world space?
  7. Mozda vidite da je Tangent space pogresan, ili da Normal mapa nije podesnea za UE5 format

Bez RenderDoc-a, ovaj problem biste resavali nasumicno -- menjali setovanja, menjali teksture, nadali se da ce nesto pomoci. Sa RenderDoc-om, vidite tacno gde stvar krene naopako.

Mesh Viewer -- Geometrija Pod Lupom

Mesh Viewer vam omogucava da vidite geometriju na bilo kojoj tacki u pipeline-u:

Pre vertex shadera (Input):

Posle vertex shadera (Output):

Posle rasterizacije:

Prakticna primena: ako imate mesh koji "treperi" (z-fighting), u Mesh Viewer-u mozete da vidite tacne depth vrednosti dva mesh-a koji se preklapaju i utvrdite kolika je razlika (ili nedostatak razlike) u depth-u.

Shader Viewer i Debugger

Ovo je gde RenderDoc postaje zaista mocan za rendering programere.

Shader Viewer vam prikazuje:

Shader Debugger vam omogucava da:

Ovo je kao da imate printf debugging za GPU -- ali bolji, jer vidite sve odjednom.

Primer koriscenja Shader Debugger-a:

Recimo da imate materijal koji na odredjenom mestu na mesh-u daje pogresnu boju. U UE5, vi vidite samo krajnji rezultat -- pogresna boja. Sa RenderDoc Shader Debugger-om:

  1. Uhvatite frame
  2. U Texture Viewer-u kliknite desnim klikom na piksel sa pogresnom bojom
  3. Izaberite "Debug this pixel"
  4. RenderDoc otvara Shader Debugger za taj piksel
  5. Prolazite instrukciju po instrukciju i vidite gde vrednost postane neocekivana:
Korak 1: UV = (0.73, 0.28)                    -- OK
Korak 2: BaseColor = Sample(tex0, UV) = (0.8, 0.2, 0.1)  -- OK
Korak 3: Normal = Sample(tex1, UV) = (0.5, 0.5, 1.0)     -- OK  
Korak 4: DetailUV = UV * DetailTiling = (7.3, 2.8)        -- OK
Korak 5: DetailNormal = Sample(tex2, DetailUV) = (0.0, 0.0, 0.0) -- PROBLEM!

Aha! Detail Normal mapa vraca crnu boju na tim koordinatama. Mozda je UV wrapping pogresan, mozda je tekstura corrupted, mozda je mipmap nivo los. Bez Shader Debugger-a, nikada ne biste znali da je detail normal sample problem -- samo biste videli "pogresna boja na tom mestu."

Pipeline State Viewer

Pipeline State Viewer vam daje kompletan pregled stanja GPU pipeline-a za odabrani draw call:

Input Assembler:
  Topology: Triangle List
  Vertex Buffer 0: stride 32, offset 0 (position, normal)
  Vertex Buffer 1: stride 16, offset 0 (UV, tangent)
  Index Buffer: R32_UINT, 14256 indices

Vertex Shader:
  Shader: BasePassVertexShader (hash: 0xABCD1234)
  Constants: ViewProjection matrix, WorldTransform, PrevWorldTransform

Rasterizer:
  Fill Mode: Solid
  Cull Mode: Back
  Depth Bias: 0
  Viewport: (0, 0) -> (1920, 1080)

Pixel Shader:
  Shader: BasePassPixelShader (hash: 0xEFGH5678)
  Textures: 6 bound (BaseColor, Normal, ORM, Detail, LightMap, ShadowMap)
  Samplers: 3 (Aniso16, Trilinear, Point)

Output Merger:
  Render Targets: 4 (GBufferA, GBufferB, GBufferC, Velocity)
  Depth: R32_FLOAT, Depth Test: Less, Write: Enabled
  Stencil: Read/Write
  Blend: None (opaque)

Ovo vam na jednom mestu prikazuje sve sto GPU zna o tom draw call-u. Ako nesto nije ispravno -- pogresna tekstura bound-ovana, pogresan blend mode, pogresan cull mode -- videcete to ovde.

Sta RenderDoc Govori Sto UE5 Ne Moze

Hajde da sumiramo kljucne stvari koje RenderDoc otkriva, a UE5 sam ne moze:

  1. Tacan sadrzaj svakog render target-a posle svakog draw call-a -- Mozete da "premotavate" rendering frame-a i vidite kako se slika gradi. Ovo je neprocenjivo za debugging compositing artefakata.

  2. Tacan shader kod koji se izvrsava -- UE5 vam prikazuje Material Graph, ali ne i finalni HLSL kod sa svim optimizacijama, permutacijama, i engine-dodacim kodom. RenderDoc vam to prikazuje.

  3. Per-pixel shader debugging -- Mozete da prodjete kroz shader kod za tacno onaj piksel koji ima problem. UE5 nema nista slicno.

  4. Kompletno stanje pipeline-a -- Svaki bound resurs, svaki state, svaka konfiguracija. Sve na jednom mestu.

  5. Mesh inspekcija u realnom vremenu -- Vidite geometriju posle vertex shadera, ne samo pre. Mozete da vidite kako World Position Offset zaista pomera vertekse.

  6. Medjurezultati compute shadera -- Ako koristite Niagara ili custom compute, mozete da vidite input/output buffer-e.

RenderDoc -- Ogranicenja

Vazno je znati i sta RenderDoc ne radi:

Uprkos ovim ogranicenjima, RenderDoc je nezamenjiv alat. Svaki rendering programer treba da ga ima instaliranog i da ga koristi redovno.

41.3 NVIDIA Nsight Graphics -- Duboko Ronjenje u GPU Performanse

Sta je Nsight Graphics?

Ako je RenderDoc "rendgenski snimak" vaseg frame-a (pokazuje strukturu), onda je NVIDIA Nsight Graphics "MRI" (pokazuje aktivnost svakog "muskula" na GPU-u).

Nsight Graphics je NVIDIA-in besplatni alat za GPU profiling i debugging. Za razliku od RenderDoc-a koji je fokusiran na debugging (sta se desava), Nsight je fokusiran na profiling (koliko brzo se desava i zasto).

Kljucne karakteristike:

Dva Rezima Rada

Nsight Graphics ima dva osnovna rezima koja se koriste za razlicite svrhe:

1. Frame Debugger (slicno RenderDoc-u)

Nsight ima sopstveni frame debugger koji je funkcionalno slican RenderDoc-u -- mozete da uhvatite frame, inspektirate draw call-ove, pogledate teksture, shadere, pipeline state. Ali Nsight-ov debugger ima neke dodatne mogucnosti specificne za NVIDIA hardver.

2. GPU Trace (ovo je ono sto ga cini posebnim)

GPU Trace je gde Nsight Graphics zaista blista. Ovo je hardverski profiler koji koristi NVIDIA-ine interne performansne brojace (performance counters) da izmeri tacno sta se desava na GPU-u tokom vaseg frame-a.

GPU Trace vam daje:

Za ceo frame:
  - Ukupno GPU vreme
  - Procenat vremena u razlicitim pipeline fazama
  - Ukupan memory bandwidth
  - Procenat iskoriscenosti razlicitih GPU jedinica

Za svaki draw call / dispatch:
  - Tacno GPU vreme (u mikrosekundama)
  - Broj izvrsenih shader instrukcija
  - Occupancy (koliko warps je aktivno vs maksimum)
  - Memory bandwidth za taj draw call
  - Cache hit/miss rates (L1, L2)
  - SM (Streaming Multiprocessor) aktivnost
  - Warp stall razlozi

Ovo su informacije koje dolaze direktno sa hardvera. Nisu procenjene, nisu izracunate -- GPU fizicki broji svaku instrukciju, svaki cache miss, svaki stall, i Nsight cita te brojace.

Kako Koristiti Nsight sa UE5

Korak 1: Instalacija

Preuzmite Nsight Graphics sa NVIDIA Developer sajta. Instalacija je standardna.

Korak 2: Pokretanje

Za razliku od RenderDoc-a koji se integrise u UE5 editor, Nsight se obicno koristi tako sto pokrenete igru kroz Nsight:

  1. Otvorite Nsight Graphics
  2. Izaberite "Connect" za novu sesiju
  3. Application Executable: Putanja do vaseg UE5 projekta (.exe ako je pakovana igra, ili UE5 Editor executable)
  4. Command Line Arguments: Putanja do vaseg .uproject fajla
  5. Working Directory: Folder vaseg projekta
  6. Activity Type: Izaberite "Frame Debugger" ili "GPU Trace"
  7. Kliknite "Launch"

Primer za pokretanje Editor-a:

Application: C:\Epic\UE_5.4\Engine\Binaries\Win64\UnrealEditor.exe
Arguments:   "C:\Projects\MyGame\MyGame.uproject" -game -dx12
Working Dir: C:\Projects\MyGame\

Ili ako imate build igre:

Application: C:\Projects\MyGame\Builds\Windows\MyGame.exe
Arguments:   -dx12

Korak 3: Capture

Kada igra radi pod Nsight-om, pritisnite Ctrl+Z (podrazumevani hotkey) ili F11 za capture.

Za GPU Trace, process capture-a je drugaciji -- Nsight prikuplja podatke kroz vise frame-ova da bi dobio statisticki znacajne rezultate.

Vazna napomena o DX12 i Vulkan:

Nsight GPU Trace radi najbolje sa DX12 i Vulkan. Za DX11, neke napredne metrike (kao detaljni occupancy podaci) mozda nece biti dostupne. Preporuka je da koristite DX12 za Nsight profiling:

Pokretanje UE5 sa DX12:
UE5Editor.exe MyProject.uproject -dx12

GPU Trace -- Detaljno

Kada otvorite GPU Trace capture, Nsight vam prikazuje timeline -- vremenski prikaz svih GPU operacija:

                    Vreme -->
SM Activity:  ████████░░████████████░░░░░████████░░
L2 Cache:     ███░░░███████░░████████░░░░░░████░░░░
VRAM:         ██░░░░░░██████░░░░██████░░░░░░░██░░░░
ROP:          ░░░░░░░░░░░░████░░░░░░████░░░░░░░████

|-- PrePass --|-- BasePass ------|-- Light --|--PP--|

Na ovom timeline-u vidite:

Svaki blok na timeline-u odgovara grupi draw call-ova ili compute dispatch-eva. Kliknite na bilo koji blok za detaljne metrike.

Shader Profiler -- Anatomija Vaseg Shadera

Nsight-ov Shader Profiler je mozda najvrednija karakteristika za rendering programere. Radi ovako:

  1. Izaberite draw call koji vas zanima
  2. Kliknite na "Profile Shader"
  3. Nsight izvrsava taj shader vise puta sa razlicitim hardware counter konfiguracijama
  4. Dobijate detaljnu analizu:
Shader: BasePassPixelShader_v247
Total Instructions: 342
Total Cycles: 1,247

Instruction Breakdown:
  FP32 (float math):     38% (134 instructions)
  FP16 (half math):       0% (shader ne koristi half)
  Texture:               27% (92 instructions)
  Integer:                8% (28 instructions)
  Conversion:             5% (18 instructions)
  Control Flow:           4% (14 instructions)
  Memory:                12% (41 instructions)
  Other:                  6% (15 instructions)

Hotspot Analysis:
  Line 47-52: Parallax Occlusion Mapping loop    -- 34% ukupnog vremena
  Line 78-82: Normal map blending (3 layers)      -- 18% ukupnog vremena
  Line 103-105: Anisotropic BRDF calculation     -- 12% ukupnog vremena

Vidite? Nsight vam tacno kaze koje linije vaseg shadera trose najvise vremena. Ovo je neprocenjivo. Umesto da nasumicno optimizujete, znate tacno gde da fokusirate trud.

U primeru iznad, Parallax Occlusion Mapping loop trosi 34% vremena. To je jasno mesto za optimizaciju -- mozete smanjiti broj koraka u POM loop-u, dodati POM LOD (manji broj koraka na daljini), ili koristiti Parallax samo na blizim objektima.

Occupancy Analiza

Occupancy je jedan od najvaznijih koncepata za GPU performanse (detaljno objasnjeno u Poglavlju 08). Nsight vam daje tacan occupancy za svaki shader:

Shader Occupancy Analysis:
  Theoretical Max Warps per SM: 48
  Active Warps per SM: 32
  Occupancy: 66.7%

  Limiting Factor: Register Usage
  Registers per Thread: 56
  Max Registers for 100% Occupancy: 32
  
  If reduced to 48 registers: Occupancy would be 75%
  If reduced to 32 registers: Occupancy would be 100%

Ova analiza vam tacno kaze zasto je occupancy nizak i sta treba da uradite da ga povecate.

U primeru iznad, shader koristi 56 registara po niti. To je previse -- ogranicava broj aktivnih warps-ova jer svaki SM ima fiksan broj registara za deljenje medju warp-ovima.

Resenja:

Napomena: 100% occupancy nije uvek cilj. Ponekad shader sa 50% occupancy radi brze nego isti shader reorganizovan za 80% occupancy, jer reorganizacija moze uvesti vise instrukcija ili losije cache ponasanje. Occupancy je jedan od faktora -- ne jedini.

Memory Bandwidth Analiza

Nsight vam prikazuje detaljnu analizu memorijskog pristupa:

Memory Throughput Analysis:
  Theoretical Peak Bandwidth: 717 GB/s (RTX 4080)
  Achieved Bandwidth: 412 GB/s (57.5% of peak)
  
  L1 Cache:
    Hit Rate: 82%
    Throughput: 1.2 TB/s
    
  L2 Cache:
    Hit Rate: 71%
    Throughput: 890 GB/s
    
  VRAM:
    Read: 312 GB/s
    Write: 100 GB/s
    
  Texture Unit:
    Texels Sampled: 48M
    Unique Texels (after filtering): 12M
    Cache Efficiency: 75%

Ovo vam govori:

Nizak cache hit rate obicno znaci:

SOL (Speed Of Light) Metrike

SOL metrike su NVIDIA-in nacin da vam kazu koliko ste blizu teorijskog maksimuma hardvera. Prikazuju se kao procenat:

SOL Analysis for BasePass:
  SM Throughput:      45% SOL   [!] Room for improvement
  Texture Throughput: 78% SOL   [!!] Near limit
  L2 Throughput:      62% SOL   
  VRAM Throughput:    51% SOL
  ROP Throughput:     23% SOL
  
  Primary Bottleneck: Texture Unit
  Secondary Bottleneck: L2 Cache

SOL analiza vam u jednom pogledu pokazuje gde je bottleneck. U primeru iznad:

Ovo je klasican primer texture bound shadera (videli smo ovu kategorizaciju u Poglavlju 21). Optimizacija bi trebalo da se fokusira na smanjenje broja texture sample-ova ili poboljsanje cache efikasnosti, a ne na smanjenje ALU instrukcija.

Warp Stall Analiza

Kada warp "stoji" (ne izvrsava instrukcije), Nsight vam kaze zasto:

Warp Stall Reasons:
  Long Scoreboard (memory dependency):    42%   ████████████
  Wait:                                   18%   ██████
  Short Scoreboard (execution dependency): 15%  █████
  Not Selected (scheduler):                12%  ████
  Barrier:                                  8%  ███
  Other:                                    5%  ██

Ovo vam tacno govori sta GPU ceka:

Ako je "Long Scoreboard" dominantan (kao u nasem primeru), resenje je:

  1. Poboljsajte cache koherentnost (bolja UV rasporedjenost, manje teksture)
  2. Smanjite broj texture sample-ova
  3. Povecajte occupancy (da GPU moze da prebaci na drugi warp dok jedan ceka)

Ako je "Short Scoreboard" dominantan, shader je compute-bound:

  1. Koristite half precision (FP16) gde je moguce
  2. Pojednostavite matematiku
  3. Eliminsite redundantne kalkulacije

Nsight Systems -- Komplementarni Alat

Vredi pomenuti i Nsight Systems, koji je odvojen alat u Nsight porodici. Dok Nsight Graphics analizira unutar GPU-a, Nsight Systems analizira interakciju izmedju CPU-a i GPU-a:

Nsight Systems Timeline:
  
CPU Thread 0: ████░░██░░████░░░████░░██░░
CPU Thread 1: ░░████░░██░░████░░░████░░██
GPU:          ░░░░████████░░░░████████░░░░

             |--CPU radi--|GPU radi|-- CPU--|-- GPU --|

Nsight Systems vam pomaze da identifikujete:

Za UE5, ovo je posebno korisno za dijagnozu problema kao sto su:

41.4 AMD Radeon GPU Profiler (RGP) -- Profiling za AMD Kartice

Sta je RGP?

AMD Radeon GPU Profiler (RGP) je AMD-ov ekvivalent NVIDIA Nsight Graphics-a. Besplatan je, radi sa AMD Radeon karticama (GCN i RDNA arhitekture), i pruza detaljne hardverske metrike.

Kljucne cinjenice:

RGP je deo sire porodice AMD alata:

Wavefront Occupancy Timeline

Najprepoznatljivija karakteristika RGP-a je Wavefront Occupancy Timeline -- vizuelni prikaz koliko je GPU aktivan tokom frame-a:

Wavefront Occupancy:

100%|         ████
    |    █████████████
 75%|  ███████████████████
    | █████████████████████████
 50%| ███████████████████████████
    | ████████████████████████████████
 25%| ██████████████████████████████████
    | ████████████████████████████████████
  0%|_____________________________________
    |  PrePass  |  BasePass  | Light | PP |

Ova vizualizacija vam na prvi pogled pokazuje:

"Rupe" u occupancy timeline-u su zlato za optimizaciju. One vam govore:

Pipeline Stages Breakdown

RGP vam prikazuje koliko vremena GPU provodi u svakoj fazi pipeline-a:

Pipeline Stage Breakdown:
  Input Assembler:     2%   ░░
  Vertex Shader:       8%   ████
  Hull Shader:         0%   
  Tessellation:        0%   
  Domain Shader:       0%   
  Geometry Shader:     0%   
  Rasterizer:          5%   ███
  Pixel Shader:       52%   ██████████████████████████████
  Output Merger:       8%   ████
  Compute Shader:     18%   ██████████
  Copy/Clear:          7%   ████

U tipicnom UE5 frame-u, Pixel Shader je obicno dominantan (40-60% ukupnog vremena). Ali postoje scenariji gde je drugacije:

Cache Analiza

RGP pruza detaljne podatke o cache performansama AMD GPU-a:

Cache Performance:
  L0 (Vector Cache):
    Hit Rate: 88%
    Requests: 2.4M
    
  L1 (Scalar Cache):
    Hit Rate: 95%
    Requests: 0.8M
    
  L2 Cache:
    Hit Rate: 72%
    Requests: 1.1M
    Read Bandwidth: 340 GB/s
    Write Bandwidth: 85 GB/s
    
  MALL (Infinity Cache - RDNA 2/3):
    Hit Rate: 64%
    Size: 96 MB
    Bandwidth: 2.1 TB/s

AMD-ove RDNA 2/3 kartice imaju dodatni nivo cache-a -- Infinity Cache (MALL -- Memory Access Last Level). Ovo je veliki cache (64-96 MB na RDNA 2, 96-128 MB na RDNA 3) koji drasticno smanjuje potrebu za pristupom sporom VRAM-u.

Nizak Infinity Cache hit rate (ispod 60%) znaci:

Instruction Timing

RGP daje podatke o broju i tipu izvrsenih instrukcija:

Instruction Mix for Selected Event:
  VALU (Vector ALU):        45%   ████████████████
  VMEM (Vector Memory):     28%   ██████████
  SALU (Scalar ALU):         8%   ███
  SMEM (Scalar Memory):      4%   ██
  Export:                     5%   ██
  LDS (Local Data Share):    6%   ███
  Branch:                    2%   █
  Other:                     2%   █
  
  Total Instructions: 1,247
  Total Cycles: 3,891
  IPC (Instructions Per Cycle): 0.32

AMD GPU ima odvojene Vector ALU (VALU) i Scalar ALU (SALU) jedinice. VALU obradjuje podatke za ceo wavefront paralelno (ono sto biste ocekivali -- pozicije, boje, UV-ovi). SALU obradjuje podatke koji su isti za ceo wavefront (uniform vrednosti, adrese, kontrolni tok).

IPC (Instructions Per Cycle) od 0.32 je relativno nizak. Idealna vrednost zavisi od shadera, ali ako je IPC konstantno ispod 0.5, shader je verovatno memory-bound -- vecinu vremena provodi cekajuci podatke.

Razlike Izmedju RGP i Nsight -- Prakticni Vodic

Ako razvijate za obe platforme (NVIDIA i AMD), korisno je znati kljucne razlike u tome sta vam svaki alat pruza:

Karakteristika Nsight Graphics RGP
GPU proizvodjac NVIDIA only AMD only
Shader profiling (per-line) Da, detaljan Ograniceniji (instrukcijski mix)
Occupancy vizualizacija Da Da (Wavefront Occupancy)
Cache analiza L1, L2 L0, L1, L2, Infinity Cache
Warp/Wavefront stall analiza Da (detaljan) Da
Memory bandwidth Da Da
SOL metrike Da Ne (ali ima ekvivalentne metrike)
Pipeline stage timing Da Da
Frame comparison Da Da
Offline shader analiza Ogranicena RGA (odvojen alat, radi i bez AMD GPU!)
Cena Besplatan Besplatan
Cross-vendor Ne Ne

Prakticna preporuka: Ako razvijate igru koja cilja obe platforme, testirajte na obe. NVIDIA i AMD GPU-i imaju razlicite bottleneck-ove za isti shader. Nesto sto je brzo na NVIDIA (npr. branching) moze biti sporo na AMD (razlicite arhitekture obrade divergencije), i obrnuto.

RGA -- Radeon GPU Analyzer (Bonus)

Vredi posebno pomenuti RGA (Radeon GPU Analyzer) jer ima jedinstvenu prednost: ne zahteva AMD GPU. RGA je offline kompajler koji uzima vas HLSL/GLSL shader i prikazuje:

Mozete da koristite RGA na racunaru sa NVIDIA karticom da vidite kako bi vas shader performirao na AMD hardveru. Ovo je korisno za cross-platform optimizaciju.

Instalacija: Deo AMD GPUOpen alata, dostupan na gpuopen.com/rga/

41.5 PIX -- Performance Investigator for Xbox (i Windows)

Sta je PIX?

PIX (Performance Investigator for Xbox) je Microsoftov alat za profiling i debugging DirectX aplikacija. Ime dolazi od Xbox razvoja, ali PIX radi i na Windows-u za DirectX 12 aplikacije.

Kljucne cinjenice:

Dva Tipa Capture-a

PIX ima dva fundamentalno razlicita rezima:

1. GPU Capture (Frame Capture)

Slicno RenderDoc-u -- hvata jedan frame i omogucava inspekciju svih draw call-ova, resursa, shadera. Ovo je debugging rezim.

PIX GPU Capture sadrzaj:
├── Event List (svi GPU dogadjaji)
├── Pipeline State (za svaki dogadjaj)
├── Resource Viewer (teksture, buffer-i)
├── Shader Debugging (korak-po-korak)
├── Mesh Viewer
└── Pixel History (istorija jednog piksela)

Pixel History je posebno mocna funkcionalnost. Za bilo koji piksel na ekranu, PIX vam prikazuje svaki draw call koji je ikada pisao na taj piksel tokom frame-a, ukljucujuci:

Ovo je fantastican alat za debugging overdraw-a, z-fighting-a, i artefakata u kompozitingu.

2. Timing Capture

Timing Capture je gde PIX pokazuje svoju pravu snagu. Za razliku od GPU Capture-a koji hvata podatke, Timing Capture hvata performanse -- tacne trajanja svih CPU i GPU operacija.

PIX Timing Capture:

CPU Timeline:
Thread 0 (Game):   ████░░░░████░░░░████░░░░
Thread 1 (Render): ░░████░░░░████░░░░████░░
Thread 2 (RHI):    ░░░░████░░░░████░░░░████

GPU Timeline:
Queue 0 (3D):      ░░░░░████████░░░████████
Queue 1 (Copy):    ██░░░░░░░░░░██░░░░░░░░░░
Queue 2 (Compute): ░░░░░░██░░░░░░░░██░░░░░░

Memory:
VRAM Usage:        2.4 GB / 8.0 GB
Upload Heap:       128 MB
Readback Heap:     64 MB

Na ovom timeline-u mozete da vidite:

PIX i UE5 -- Prakticno Koriscenje

UE5 koristi DirectX 12 kao primarni rendering backend na Windows-u, sto znaci da PIX moze da uhvati svaki aspekt renderinga.

Pokretanje UE5 pod PIX-om:

  1. Otvorite PIX
  2. Izaberite "Launch Win32" za pokretanje aplikacije
  3. Unesite putanju do UE5 executable-a: 
    Path: C:\Epic\UE_5.4\Engine\Binaries\Win64\UnrealEditor.exe
Arguments: "C:\Projects\MyGame\MyGame.uproject" -game
  4. Kliknite "Launch"
  5. Kada igra radi, koristite "GPU Capture" ili "Timing Capture" dugmice

Alternativno, za Timing Capture, mozete koristiti Attach mode -- pokrenete igru normalno, a zatim poveze PIX na vec pokrenut proces. Ovo je korisno kada ne zelite da restartujete igru.

Vazna napomena za DX12 debugging:

PIX zahteva da DirectX 12 debugging sloj bude aktivan. UE5 to moze da omoguci kroz command-line argument:

-d3ddebug    (ukljucuje DX12 debug sloj)
-gpuvalidation  (ukljucuje GPU-based validation -- VEOMA sporo, koristite samo za debugging)

Memory Analiza u PIX-u

PIX ima odlicne alate za analizu memorije, sto je posebno vazno za UE5 projekte koji imaju tendenciju da koriste mnogo GPU memorije:

PIX Memory Analysis:
  
Committed Memory by Category:
  Textures:        1.8 GB   ██████████████████
  Buffers:         0.4 GB   ████
  Render Targets:  0.6 GB   ██████
  Depth Stencil:   0.1 GB   █
  Shaders:         0.2 GB   ██
  Other:           0.3 GB   ███
  ─────────────────────────
  Total:           3.4 GB

Top 10 Resources by Size:
  1. SceneColor RT (HDR):     32 MB  (3840x2160 RGBA16F)
  2. GBufferA:                16 MB  (3840x2160 RGBA8)
  3. GBufferB:                16 MB  (3840x2160 RGBA8)
  4. DepthBuffer:             16 MB  (3840x2160 D32F)
  5. VirtualShadowMap:        64 MB  (virtual texture pages)
  6. LightMap Atlas:          24 MB  (mixed resolution)
  7. T_Building_BaseColor:     8 MB  (4096x4096 BC7)
  8. T_Landscape_Splat:       16 MB  (8192x8192 BC1)
  9. HZB (Hi-Z Buffer):       4 MB  (mip chain)
  10. Velocity Buffer:         8 MB  (1920x1080 RG16F)

Ova analiza vam tacno govori gde vasa GPU memorija odlazi. Ako imate VRAM pressure na nizim karticama (4-6 GB), ovo je jedini nacin da znate sta da smanjite.

PIX vs RenderDoc -- Kada Koristiti Koji

Scenario Preporucen alat
Debugging shader output-a RenderDoc (bolji shader debugger)
DX12-specifican debugging PIX (bolji DX12 support)
CPU/GPU timing korelacija PIX (jedinstven Timing Capture)
Memory analiza PIX (detaljnija)
Vulkan debugging RenderDoc (PIX ne podrzava Vulkan)
Xbox development PIX (jedina opcija)
Cross-platform (Linux) RenderDoc (PIX je Windows-only)
Pixel History PIX (bolja implementacija)
Besplatni alat bez ogranicenja Oba su besplatni

Mnogi rendering programeri koriste oba alata. RenderDoc za brzi debugging, PIX za detaljnu timing i memory analizu na DX12.

41.6 Sta Vidite u Eksternim Alatima, a Ne Vidite u UE5

Hajde da ovo sistematski prodjemo. Ovo je mozda najvazniji deo poglavlja za razumevanje zasto treba koristiti eksterne alate.

1. Per-Draw-Call GPU Timing

UE5 vam kaze: "BasePass: 4.2ms" (grupisano za ceo pass)

Eksterni alat vam kaze:

BasePass Draw Calls (sortirano po GPU vremenu):
  #247  SM_Building_Main    0.42ms  ████████
  #312  SM_Landscape_01     0.38ms  ████████
  #145  SM_Character_Body   0.31ms  ██████
  #289  SM_Vehicle_01       0.28ms  ██████
  #401  SM_Props_Barrels    0.22ms  █████
  ...
  #892  SM_SmallRock_03     0.002ms ░
  
  Total: 847 draw calls, 4.2ms combined

Vidite razliku? UE5 vam kaze da BasePass trosi 4.2ms. Ali eksterni alat vam kaze da jedan building mesh trosi 10% tog vremena. To je drasticno korisnija informacija.

2. Shader Instruction Hotspots

UE5 vam kaze: "Material Instruction Count: 287"

Nsight/RGP vam kaze:

Shader Profile - M_Building_Main:
  
Line  23:  float3 worldPos = ...         -- 0.2% time
Line  24:  float3 normal = ...           -- 0.3% time
...
Line  47:  float height = POM_Loop(...)  -- 31.4% time  ★ HOTSPOT
Line  48:  float2 newUV = ...            -- 0.1% time
...
Line  82:  float3 blended = lerp(...)    -- 0.5% time
Line  83:  float wet = WetMask(...)      -- 12.7% time  ★ HOTSPOT
...
Line 127:  return finalColor;            -- 0.1% time

287 instrukcija je apstraktan broj. Ali kada znate da linije 47 i 83 trose skoro 45% ukupnog vremena, imate actionable informaciju. Mozete da:

3. Cache Hit/Miss Rates

UE5 vam kaze: (nista o cache-u)

Nsight/RGP vam kaze:

Draw Call #247 Cache Analysis:
  L1 Texture Cache:
    Requests: 2,400,000
    Hits: 1,920,000 (80%)
    Misses: 480,000 (20%)
    
  L2 Cache:
    Requests: 480,000 (L1 misses)
    Hits: 336,000 (70%)
    Misses: 144,000 (30%)
    
  Total VRAM Fetches: 144,000
  Estimated Extra Latency: ~0.15ms

20% L1 miss rate sa 30% L2 miss rate znaci da 6% svih texture fetch-ova ide direktno u VRAM. Za scenu sa milionima texture fetch-ova, to je znacajan overhead.

Moguca resenja bazirana na ovim podacima:

4. Occupancy Po Shaderu

UE5 vam kaze: (nista o occupancy-ju)

Nsight/RGP vam kaze:

Shader Occupancy Breakdown:
  M_Building_Main:     62% occupancy (48 regs, limiting factor: registers)
  M_Landscape:         45% occupancy (64 regs, limiting factor: registers)
  M_Character_Skin:    75% occupancy (36 regs, limiting factor: none significant)
  M_Water:             38% occupancy (72 regs, limiting factor: registers + LDS)
  M_Foliage:           81% occupancy (32 regs, limiting factor: none)
  M_Particle_Smoke:    94% occupancy (16 regs, limiting factor: none)

Odmah vidite da M_Water sa 38% occupancy je problem. Shader koristi 72 registra -- to je ogromno. I koristi LDS (Local Data Share / Shared Memory), sto dodatno smanjuje occupancy.

M_Landscape sa 45% je takodje problematican -- 64 registra ukazuju na veoma kompleksan shader (verovatno mnogo layera sa blendingom).

M_Particle_Smoke sa 94% je odlican -- jednostavan shader koji maksimalno koristi GPU. Sto je posebno vazno jer se cestice cesto renderuju sa overdraw-om pa je nizak cost-per-pixel kritican.

5. Memory Bandwidth Utilizacija

UE5 vam kaze: (nista o bandwidth-u)

Nsight/RGP vam kaze:

Per-Pass Bandwidth Analysis:
  PrePass:       45 GB/s  (6% of peak)    -- Samo depth, mali bandwidth
  BasePass:     380 GB/s  (53% of peak)   -- Mnogo tekstura, G-Buffer writes
  Lighting:     290 GB/s  (40% of peak)   -- G-Buffer reads, light volumes
  Translucency: 420 GB/s  (59% of peak)   -- Overdraw! Mnogo reads/writes
  PostProcess:  310 GB/s  (43% of peak)   -- Fullscreen reads/writes
  
  Peak Theoretical: 717 GB/s (RTX 4080)

Translucency na 59% bandwidth-a -- i to za tipicno manji deo scene -- ukazuje na ozbiljan overdraw problem. Translucent objekti ne koriste depth buffer za early-Z rejection, pa svaki sloj mora da procita pozadinu, izracuna boju, i upise rezultat. Sa mnogo slojeva (dim, vatra, staklene povrsine), bandwidth brzo postaje bottleneck.

6. Warp Divergence

UE5 vam kaze: (nista o divergenciji)

Nsight/RGP vam kaze:

Warp Efficiency Analysis for M_Landscape:
  Average Active Threads per Warp: 24.3 / 32 (75.9%)
  
  Divergence Hotspots:
    Line 34: if (LayerWeight0 > 0.01)     -- 22% inactive threads
    Line 45: if (LayerWeight1 > 0.01)     -- 31% inactive threads
    Line 56: if (LayerWeight2 > 0.01)     -- 43% inactive threads
    Line 67: if (LayerWeight3 > 0.01)     -- 52% inactive threads

Landscape material sa 4 layera koristi if blokove za svaki layer (cest pattern -- "ako weight layera nije nula, racunaj taj layer"). Problem je sto razliciti pikseli u istom warp-u imaju razlicite aktivne layere, pa nastaje divergencija.

Sa 4 if bloka, efektivni SIMD utilization pada na 76% -- skoro cetvrtina GPU snage se trosi uzalud.

Resenje: umesto if blokova, koristiti multiply-by-zero pristup:

// Umesto ovoga (divergentno):
if (LayerWeight0 > 0.01)
    color += Layer0Color * LayerWeight0;

// Koristiti ovo (bez divergencije):
color += Layer0Color * LayerWeight0;  // Ako je weight 0, rezultat je 0

Da, ovo znaci da GPU racuna i layere sa weight-om 0, ali je to brze od branch divergencije jer nema maskiranje niti.

7. Actual vs Theoretical Throughput

UE5 vam kaze: "Frame time: 14.2ms" (ali ne koliko je to blizu hardverskog limita)

Nsight SOL analiza vam kaze:

Speed Of Light Summary:
  Your frame: 14.2ms
  
  If GPU were 100% efficient:
    SM Throughput limited frame: ~8.5ms
    Bandwidth limited frame: ~6.2ms
    ROP limited frame: ~11.8ms
    
  Your primary bottleneck: SM (compute)
  You are at 60% of theoretical SM throughput
  
  Potential improvement with perfect optimization: ~40%
  Realistic improvement estimate: ~15-25%

Ovo vam kaze ne samo koliko je frame spor, vec i koliko prostora za poboljsanje postoji. Ako ste vec na 95% theoretical throughput, nema mnogo sta da se uradi bez smanjenja vizuelnog kvaliteta. Ako ste na 60%, postoji znacajan prostor za optimizaciju.

41.7 Prakticni Primeri -- Od Problema do Resenja

Primer 1: Koriscenje RenderDoc-a za Analizu Skupog Materijala

Scenario: Imate materijal M_StoneWall koji prema UE5 GPU Visualizer-u trosi 0.8ms po frame-u na jednom mesh-u. To je mnogo za jedan materijal.

Korak 1: RenderDoc capture

Uhvatite frame sa kamerom usmerenom ka tom mesh-u.

Korak 2: Pronalazenje draw call-a

U Event Browser-u nadjite draw call za taj mesh. U UE5, draw call-ovi su obicno oznaceni sa imenom mesh-a ili materijala u debug markups:

BasePass
  └── DrawIndexed(14256) [SM_StoneWall_01]

Korak 3: Inspekcija bound resursa

Kliknite na draw call i pogledajte Pipeline State:

Pixel Shader Resources:
  t0: T_StoneWall_BC      (4096x4096, BC7)      -- Base Color
  t1: T_StoneWall_Normal   (4096x4096, BC5)      -- Normal
  t2: T_StoneWall_ORM      (4096x4096, BC7)      -- Occlusion/Roughness/Metallic
  t3: T_StoneWall_Height   (4096x4096, BC4)      -- Height map (za POM)
  t4: T_StoneWall_Detail_BC (2048x2048, BC7)     -- Detail Base Color
  t5: T_StoneWall_Detail_N  (2048x2048, BC5)     -- Detail Normal
  t6: T_StoneWall_Macro    (4096x4096, BC7)      -- Macro variation
  t7: T_WetMask            (2048x2048, BC4)      -- Wet/dry mask
  t8: T_Noise              (1024x1024, BC4)      -- Noise za variation

9 tekstura! To je vec nagovestavaj problema. Svaka tekstura zahteva sample, a svaki sample zahteva texture unit i potencijalno memorijski pristup.

Korak 4: Pregled shader koda

U Shader Viewer-u vidite HLSL kod. Pretraziete i nalazite:

// Parallax Occlusion Mapping -- 32 koraka!
float height = 1.0;
float2 currentUV = uv;
for (int i = 0; i < 32; i++)  // <-- 32 iteracije!
{
    height -= step;
    float sampledHeight = HeightTexture.Sample(Sampler, currentUV).r;
    if (sampledHeight > height)
    {
        // Interpolate exact hit point
        ...
    }
    currentUV += uvStep;
}

32 koraka POM-a! To je 32 texture sample-a samo za height mapping. Zajedno sa ostalih 9 tekstura i svim normal blending kalkulacijama, ovaj shader je ogroman.

Korak 5: Donosenje odluke

Na osnovu RenderDoc analize, mozete zakljuciti:

  1. POM sa 32 koraka je glavni krivac -- Smanjite na 16 koraka za blize rastojanje, 8 za srednje, 0 (flat) za daljinu
  2. 9 tekstura je previse -- Razmotrite channel packing: Detail BC i Detail N mogu da se pakuju. Noise i WetMask mogu da budu manji (512x512 je dovoljno za noise).
  3. Sve teksture su 4096x4096 -- Za mesh koji nije ekstra blizu kamere, 2048x2048 bi bio sasvim dovoljan

Primer 2: Koriscenje Nsight-a za Identifikaciju Bandwidth Bottleneck-a

Scenario: Vasa scena na RTX 3060 (sa 192 GB/s bandwidth-om -- znacajno manje od RTX 4080) radi na 22ms umesto zeljenih 16.67ms. UE5 kaze da je GPU bottleneck.

Korak 1: Nsight GPU Trace capture

Pokrenete igru pod Nsight-om i uhvatite GPU Trace.

Korak 2: SOL analiza

SOL Analysis:
  SM Throughput:      35% SOL
  Texture Throughput: 42% SOL
  L2 Throughput:      88% SOL  ★★★ NEAR LIMIT
  VRAM Throughput:    91% SOL  ★★★ BOTTLENECK
  ROP Throughput:     28% SOL

VRAM Throughput na 91% SOL! GPU je bukvalno na granici svog memorijskog propusnog opsega. Ne moze da cita/pise podatke brze.

Korak 3: Identifikacija krivca

Nsight vam pokazuje bandwidth po pass-u:

Pass Bandwidth:
  BasePass:      82 GB/s   (43% of peak)
  VSM Rendering: 45 GB/s   (23% of peak)
  Lumen GI:      38 GB/s   (20% of peak)
  PostProcess:   22 GB/s   (11% of peak)
  Other:          5 GB/s   (3% of peak)
  ──────────────────────────
  Total:        192 GB/s   (100% -- saturated!)

BasePass trosi 43% bandwidth-a. To je mnogo. Dalja analiza:

Korak 4: Analiza BasePass bandwidth-a

BasePass Memory Operations:
  Texture Reads:      54 GB/s  (66% of BasePass bandwidth)
    - Highest: T_Landscape (8K textures): 18 GB/s
    - Second: T_Building materials: 12 GB/s
    
  G-Buffer Writes:    22 GB/s  (27% of BasePass bandwidth)
    - GBufferA: 5.5 GB/s
    - GBufferB: 5.5 GB/s  
    - GBufferC: 5.5 GB/s
    - Velocity: 5.5 GB/s
    
  Buffer Reads:        6 GB/s  (7% of BasePass bandwidth)

Korak 5: Resenje

Na osnovu Nsight podataka, jasno je da su texture reads glavni krivac (66% BasePass bandwidth-a). A unutar toga, 8K landscape teksture trose 18 GB/s same.

Akcioni plan:

  1. Smanjiti landscape teksture sa 8K na 4K -- 4x manje bandwidth. Vizuelna razlika ce biti minimalna na tipicnom rastojanju kamere.
  2. Aktivirati Virtual Texturing za landscape -- UE5 ce streamovati samo potrebne tile-ove, drasticno smanjujuci memory footprint i bandwidth.
  3. Proveriti mipmap streaming -- Mozda su teksture ucitane na previse detaljan mip level za datu distancu kamere.
  4. Razmotriti BC1 umesto BC7 za neke teksture -- BC1 je duplo manji od BC7 (0.5 vs 1 bajt po pikselu). Za roughness/metallic mape, BC1 je cesto dovoljan.

Posle ovih promena, ponovo pokrenite Nsight GPU Trace i verifikujte da je VRAM throughput pao ispod 75% SOL.

Primer 3: Sistematski Pristup -- Od UE5 do Eksternog Alata i Nazad

Hajde da prodjemo kroz kompletan workflow za realan scenario.

Problem: Frame time je 18ms (55 FPS) na ciljnom hardveru. Cilj je 16.67ms (60 FPS). Treba da nadjete 1.33ms.

Faza 1: UE5 Stat komande

stat unit:
  Frame: 18.0ms
  Game: 5.2ms
  Draw: 3.1ms
  GPU: 16.8ms    <-- GPU je bottleneck

stat gpu (ukupno):
  BasePass: 6.2ms
  Shadows: 3.4ms
  Lighting: 2.8ms
  Translucency: 2.1ms
  PostProcess: 1.5ms
  Other: 0.8ms

GPU je bottleneck. BasePass je najskuplji. Sledeci korak.

Faza 2: UE5 GPU Visualizer

Otvorite ProfileGPU (Ctrl+Shift+, u editoru). Vidite da unutar BasePass-a, 5 mesh-ova trosi 60% vremena. Najskuplji je SM_HeroBuilding sa M_BrickWall_Detailed materijalom.

Faza 3: RenderDoc

Uhvatite frame, nadjete draw call za SM_HeroBuilding. Vidite:

Vec imate uvid u sta je problem. Ali koliko svaka od ovih stvari zapravo kosta?

Faza 4: Nsight Graphics (ili RGP za AMD)

GPU Trace za taj draw call:

Draw Call #312 Analysis:
  GPU Time: 0.85ms
  
  Instruction Mix:
    TEX: 67%  (texture fetch dominira)
    ALU: 28%
    Other: 5%
    
  Hotspots:
    POM Loop (lines 34-58):      38% of time (0.32ms)
    Tri-planar sampling (67-82): 24% of time (0.20ms)
    Detail blending (90-105):    15% of time (0.13ms)
    
  Occupancy: 52% (48 registers, limiting)
  L2 Cache Hit: 65% (LOW)
  
  SOL: Texture Unit at 82% -- texture bound!

Sada znate tacno:

  1. POM Loop kosta 0.32ms
  2. Tri-planar kosta 0.20ms
  3. Detail blending kosta 0.13ms
  4. Shader je texture-bound (ne compute-bound)
  5. Cache hit je nizak (65%)

Faza 5: Informisana optimizacija

Na osnovu podataka:

Optimizacija Procenjena usteda Vizuelni uticaj
POM: 24 -> 12 koraka ~0.16ms Minimalan na vecini uglova
POM: LOD off na >10m ~0.20ms (za daljie instance) Nevidljiv na toj daljini
Tri-planar -> Regular UV ~0.20ms Vidljiv na vertikalnim povrsinama, ali prihvatljiv
Teksture: 4K -> 2K ~0.10ms (bolji cache) Minimalan
Channel packing (7 -> 5 tekstura) ~0.05ms Nula

Ukupna potencijalna usteda: ~0.51ms samo na ovom jednom materijalu. A treba nam 1.33ms ukupno. Ovo je dobar pocetak -- ponovite process za sledecih 4-5 najskupljih materijala i verovatno cete stici do cilja.

Faza 6: Verifikacija

Posle implementacije promena, ponovo prodjite kroz Faze 1-4. Proverite da:

Ovo je profiling-first optimizacija (Poglavlje 39) u praksi, pojacana eksternim alatima za duboku analizu.

41.8 Napredne Tehnike Koriscenja Eksternih Alata

Frame Comparison -- Merenje Efekta Promena

Svi glavni alati (Nsight, RGP, PIX) podrzavaju frame comparison -- mogucnost da uporedite dva capture-a side-by-side:

Frame A (pre optimizacije):          Frame B (posle optimizacije):
  BasePass: 6.2ms                      BasePass: 4.8ms  (-1.4ms, -22.6%)
  Shadows: 3.4ms                       Shadows: 3.4ms   (0, unchanged)
  Lighting: 2.8ms                      Lighting: 2.8ms  (0, unchanged)
  
  Bandwidth: 192 GB/s (saturated)      Bandwidth: 145 GB/s (76% peak)
  L2 Hit Rate: 65%                     L2 Hit Rate: 78%  (+13%)
  Occupancy (avg): 52%                 Occupancy (avg): 68% (+16%)

Ovo je nepobitna potvrda da su vase optimizacije funkcionisale. Nema pogadjanja, nema subjektivnih procena -- imate hardverske brojke pre i posle.

Batch Mode Profiling

Za sistematicno testiranje, mozete da koristite Nsight/RGP u batch mode-u:

  1. Snimite fiksnu putanju kamere u igri (Matinee/Sequencer)
  2. Pokrenite igru sa tom putanjom pod profiler-om
  3. Capture vise frame-ova na razlicitim pozicijama
  4. Analizirajte rezultate

Ovo je posebno korisno za:

Multi-GPU Profiling

Ako razvijate za vise GPU-a (sto bi trebalo, ako ciljate PC platformu), evo preporucenog pristupa:

  1. NVIDIA kartice: Nsight Graphics za detaljne metrike, RenderDoc za debugging
  2. AMD kartice: RGP za hardverske metrike, RenderDoc za debugging, RGA za offline shader analizu
  3. Intel kartice: Intel GPA (Graphics Performance Analyzers) za Intel Arc, RenderDoc za debugging
  4. Xbox: PIX (obavezno za Xbox certification)
  5. PlayStation: Razor (Sony-in interni alat, dostupan kroz DevNet)

Pravilo: uvek profajlirajte na vasem najslabijem ciljnom hardveru. Ako igra cilja GTX 1060 kao minimum, profajliranje na RTX 4090 nece otkriti bottleneck-ove koji ce igraci zaista iskusiti.

Kreiranje Custom Markera za Lakse Snalazenje

UE5 automatski ubacuje debug markere u GPU command stream koji pomazu da se draw call-ovi identifikuju u eksternim alatima. Ali mozete dodati i sopstvene markere za lakse snalazenje.

U C++ kodu:

// Dodaje marker vidljiv u RenderDoc, Nsight, PIX
SCOPED_DRAW_EVENT(RHICmdList, MyCustomPass);
{
    // Vas rendering kod ovde
}

// Ili za ugnjezdene markere:
SCOPED_DRAW_EVENT(RHICmdList, MyOuterPass);
{
    SCOPED_DRAW_EVENT(RHICmdList, InnerStep1);
    {
        // Korak 1
    }
    SCOPED_DRAW_EVENT(RHICmdList, InnerStep2);
    {
        // Korak 2
    }
}

U Blueprint-u mozete koristiti Begin Draw Event / End Draw Event node-ove (dostupne ako imate custom rendering Blueprint setup).

Ovi markeri se prikazuju u Event Browser-u svih eksternih alata, sto drasticno olaksava navigaciju kroz kompleksan frame.

Automatizovani Profiling Pipeline

Za timove koji ozbiljno shvataju performanse, moguce je automatizovati profiling:

Automatizovani Pipeline:
1. Build igre (automated build system)
2. Pokreni igru sa fiksnom kamera putanjom
3. Capture GPU Trace (Nsight CLI ili RGP CLI)
4. Parsiranje rezultata (Python script)
5. Uporedjivanje sa prethodnim rezultatima
6. Generisanje izvestaja
7. Alert ako performanse padnu ispod praga

NVIDIA Nsight ima command-line interface koji omogucava skriptovanje capture-a. AMD RGP takodje podrzava CLI operacije. PIX se moze kontrolisati programski kroz PIX SDK.

Ovo je napredna tema i izlazi iz okvira ove knjige, ali vredi znati da je moguce. Veci studiji (Epic, Ubisoft, EA) imaju ovakve sisteme koji automatski detektuju performansne regresije pre nego sto dodju do igraca.

41.9 Ceste Greske i Zamke

Greska 1: Profajliranje u Debug Build-u

Problem: Debug/Development build ima mnogo veci overhead nego Shipping build. Shaderi su manje optimizovani, CPU overhead je veci, postoje dodatne provere.

Resenje: Uvek profajlirajte u Shipping build-u (ili barem u Test build-u) za tacne GPU metrike. Development build koristite samo za debugging.

Build konfiguracija za profajliranje:
  Development: Za debugging (RenderDoc shader debugging)
  Test:        Za profiling (realisticne performanse, ali sa debugging symbolima)
  Shipping:    Za finalne metrike (ali nema debug markere)

Greska 2: Profajliranje na Pogresnom Hardveru

Problem: Profajlirate na RTX 4090, a ciljate GTX 1660 Super. Bottleneck-ovi su potpuno razliciti.

Resenje: Profajlirajte na najslabijem ciljnom hardveru. Ako nemate pristup, bar koristite r.SetRes da simulirate nizu rezoluciju, i r.ScreenPercentage da smanjite rendering rezoluciju.

Greska 3: Merenje Jednog Frame-a i Donosenje Zakljucaka

Problem: GPU performanse variraju od frame-a do frame-a. Jedan frame moze biti outlier.

Resenje: Za GPU Trace (Nsight/RGP), uvek merite prosek kroz vise frame-ova. Nsight automatski uzima vise sample-ova. Za RenderDoc capture (koji je uvek jedan frame), napravite vise capture-ova i uporedite.

Greska 4: Fokusiranje na Pogresnu Metriku

Problem: Imate 95% occupancy ali je shader spor. Fokusirate se na occupancy optimizaciju jer "nije 100%."

Resenje: Uvek prvo identifikujte primarni bottleneck (SOL analiza u Nsight-u, pipeline breakdown u RGP-u). Optimizujte taj bottleneck, ne random metriku.

Podsecanje iz Poglavlja 08: visok occupancy ne garantuje brz shader. Shader moze imati visok occupancy ali i dalje biti spor ako je instrukcijski tezak. Occupancy pomaze samo kada je shader memory-bound (ceka na podatke), jer vise warpova znaci vise prilika za latency hiding.

Greska 5: Zaboravljanje da Eksterni Alat Utice na Performanse

Problem: Pokrenete igru pod Nsight-om i vidite da je "sporija nego obicno." Brinete se da ste nesto pokvarili.

Resenje: Profiling alati uvek dodaju overhead. RenderDoc za vreme capture-a moze da udvostruci frame time. Nsight dodaje overhead za citanje hardverskih brojaca. Apsolutne brojke iz profiler-a nikada ne koristite za finalne performansne metrike -- koristite ih samo za relativno poredjenje (koji deo je skuplji od drugog, i koliko puta).

Za apsolutne brojke, koristite UE5 stat unit i stat fps bez ikakvih eksternih alata zakacenih.

Greska 6: Zanemarivanje CPU-GPU Interakcije

Problem: Fokusirate se iskljucivo na GPU metrike i ignorisite CPU stranu. Ali vas GPU je idle 30% frame-a jer CPU kasni sa submisijom komandi.

Resenje: Koristite Nsight Systems ili PIX Timing Capture za CPU/GPU korelaciju. Cesto je "GPU bottleneck" zapravo "CPU bottleneck koji izgladnjuje GPU."

Tipicni znaci da CPU gladuje GPU:

41.10 Uporedni Pregled Svih Alata

Matrica Mogucnosti

Mogucnost RenderDoc Nsight Graphics RGP PIX
Cena Besplatan Besplatan Besplatan Besplatan
GPU Vendor Bilo koji NVIDIA only AMD only Bilo koji (DX12)
Frame Debugging Da (primarni fokus) Da Ograniceno Da
GPU Timing Ne Da (GPU Trace) Da Da (Timing Capture)
Shader Profiling Ne (samo debugging) Da (per-line) Da (instruction mix) Ograniceno
Occupancy Ne Da Da Ne
Cache Analiza Ne Da Da Ne
Bandwidth Analiza Ne Da Da Ograniceno
Warp Stall Analiza Ne Da Da Ne
CPU/GPU Korelacija Ne Da (Nsight Systems) Ograniceno Da
Memory Analiza Ograniceno Ograniceno Ograniceno Da
Mesh Viewer Da Da Ne Da
Texture Viewer Da (odlican) Da Ne Da
Shader Debugger Da (odlican) Da Ne Da
Pixel History Ograniceno Ne Ne Da
DX11 Podrska Da Da Da Ograniceno
DX12 Podrska Da (u razvoju) Da Da Da (primarni fokus)
Vulkan Podrska Da Da Da Ne
OpenGL Podrska Da Da Ne Ne
Linux Podrska Da Da Da Ne
Xbox Podrska Ne Ne Ne Da
PlayStation Ne Ne Ne Ne (Razor)

Preporuceni Setup Po Platformi

Razvoj za PC (NVIDIA ciljni GPU):

Primarni: Nsight Graphics (GPU profiling)
Sekundarni: RenderDoc (debugging)
Pomocni: Nsight Systems (CPU/GPU korelacija)

Razvoj za PC (AMD ciljni GPU):

Primarni: RGP (GPU profiling)
Sekundarni: RenderDoc (debugging)
Pomocni: RGA (offline shader analiza na razlicitim AMD GPU-ima)

Razvoj za PC (obe platforme):

Debugging: RenderDoc (radi sa oba vendor-a)
NVIDIA profiling: Nsight Graphics
AMD profiling: RGP
Offline analiza: RGA (radi bez AMD kartice)

Razvoj za Xbox:

Primarni: PIX (jedini alat za Xbox)
Sekundarni: RenderDoc (za Windows debugging)

Razvoj za multi-platform (PC + Xbox):

Debugging: RenderDoc + PIX
GPU profiling: Nsight Graphics + RGP + PIX
CPU/GPU: Nsight Systems + PIX Timing Capture

41.11 Rezime i Kljucni Pojmovi

Kljucne Lekcije

  1. UE5 alati su pocetak, ne kraj -- Koristite ih da identifikujete gde je problem, a zatim koristite eksterne alate da saznate zasto.

  2. RenderDoc je obavezan alat -- Besplatan, jednostavan, i nezamenjiv za debugging. Instalirjte ga danas, koristite ga sutra.

  3. Nsight/RGP su za duboku analizu -- Kada trebate da znate tacno zasto je shader spor, ovi alati vam daju odgovor na nivou instrukcije.

  4. PIX za DX12 i Xbox -- Ako radite sa DirectX 12, PIX je nezaobilazan, posebno za CPU/GPU timing korelaciju i memory analizu.

  5. Profiling workflow ide od sirokog ka uskom -- UE5 Stat komande -> GPU Visualizer -> RenderDoc -> Nsight/RGP. Svaki korak suzava fokus.

  6. SOL metrike su vas kompas -- Koliko ste blizu teorijskog maksimuma vam govori koliko prostora za optimizaciju imate.

  7. Occupancy nije sve -- Visok occupancy ne garantuje brz shader. Najpre identifikujte da li ste compute-bound, texture-bound, ili bandwidth-bound.

  8. Profajlirajte na ciljnom hardveru -- Bottleneck-ovi na RTX 4090 i GTX 1060 su potpuno razliciti. Uvek testirajte na najslabijem ciljnom GPU-u.

  9. Merite pre i posle -- Frame comparison u eksternim alatima daje nepobitne dokaze da je optimizacija funkcionisala.

  10. Cache hit rate je cesto kljucan -- Nizak cache hit rate (ispod 75%) je ozbiljan signal da su vasi texture access patern-i neoptimalni.

Tabela Kljucnih Pojmova

Pojam (EN) Opis
Frame Capture Snimanje svih GPU komandi za jedan frame radi analize
Draw Call Jedna GPU komanda koja renderuje geometriju (DrawIndexed, DrawInstanced, itd.)
Event Browser Hijerarhijski prikaz svih GPU dogadjaja u uhvacenom frame-u
Pipeline State Kompletno stanje GPU pipeline-a (shaderi, teksture, blend mode, itd.) za jedan draw call
Shader Debugger Alat koji omogucava korak-po-korak izvrsavanje shadera za odabrani piksel
GPU Trace Snimanje hardverskih performansnih metrika sa GPU-a tokom izvrsavanja
Occupancy Procenat aktivnih warp-ova u odnosu na maksimalan broj koji GPU moze da drzi
SOL (Speed Of Light) Procenat teorijskog maksimuma hardvera koji je dostignut (100% = savrsena iskoriscenost)
Warp Stall Situacija kada warp ne moze da izvrsava instrukcije jer ceka na nesto (memoriju, sinhronizaciju, itd.)
Long Scoreboard Stall razlog: warp ceka podatke iz memorije (texture fetch ili buffer read)
Short Scoreboard Stall razlog: warp ceka rezultat prethodne aritmeticke instrukcije
Cache Hit Rate Procenat memorijskih pristupa koji su pronadjeni u brzom kesu (sto vise, to bolje)
Memory Bandwidth Kolicina podataka koju GPU moze da procita/upise u memoriju po sekundi (obicno u GB/s)
SM (Streaming Multiprocessor) NVIDIA-ina racunska jedinica koja sadrzi grupu CUDA jezgara, cache, registre
CU (Compute Unit) AMD-ova racunska jedinica, ekvivalent NVIDIA SM-a
Wavefront AMD-ov naziv za grupu niti (obicno 32 ili 64) koje se izvrsavaju zajedno -- ekvivalent NVIDIA warp-a
Register Pressure Situacija kada shader koristi previse registara, sto smanjuje occupancy
Instruction Mix Raspodela tipova instrukcija u shaderu (ALU, TEX, Memory, Branch, itd.)
Per-Line Hotspot Linija shader koda koja trosi neproporcionalno mnogo GPU vremena
Pixel History Lista svih draw call-ova koji su pisali na odredjeni piksel tokom frame-a
Timing Capture Snimanje vremenskih trajanja CPU i GPU operacija za analizu korelacije
Infinity Cache (MALL) AMD-ov veliki poslednji nivo cache-a (64-128 MB) na RDNA 2/3 karticama
Warp Divergence Situacija kada niti u istom warp-u idu razlicitim putevima u if/else bloku
IPC (Instructions Per Cycle) Broj instrukcija izvrsenih po takt ciklusu -- mera efikasnosti izvrsavanja
Texture Bound Stanje kada su texture sample jedinice bottleneck (previse texture fetch-ova)
Compute Bound Stanje kada su ALU/compute jedinice bottleneck (previse matematickih operacija)
Bandwidth Bound Stanje kada je memorijski propusni opseg bottleneck (previse podataka za citanje/pisanje)
GPU Validation Debugging rezim koji proverava ispravnost GPU komandi (veoma spor, samo za debugging)
Performance Counter Hardverski brojac ugradjen u GPU koji meri specificne metrike (cache miss, stall cycles, itd.)
SCOPED_DRAW_EVENT UE5 C++ makro za dodavanje debug markera vidljivih u eksternim profiling alatima

41.12 Reference i Dalje Citanje

Poglavlja u Ovoj Knjizi

Zvanicna Dokumentacija Alata

UE5 Integracija

Prezentacije i Clanci

Video Tutoriali

Sledece poglavlje (42) -- Sada kada imate kompletan arsenal alata -- od UE5 built-in profiler-a do hardverskih GPU profiler-a -- spremni ste da primenite sve sto ste naucili na optimizaciju vaseg projekta u praksi. U sledecem poglavlju cemo sve ovo povezati u koherentan workflow.

Zapamtite: alat je koristan samo onoliko koliko razumete podatke koje vam daje. Zato smo u Poglavlju 08 detaljno objasnili GPU arhitekturu -- da biste znali sta znaci "42% Long Scoreboard stall" ili "62% occupancy limited by registers." Bez tog znanja, eksterni alati su samo prozori puni nerazumljivih brojeva. Sa tim znanjem, oni su najmocanije oruzje u vasem arsenalu za optimizaciju.