Poglavlje 40: UE5 Profiling Alati

"Ne mozes popraviti ono sto ne mozes izmeriti." -- Stara inzenjerska mudrost

Uvod

U prethodnom poglavlju (Poglavlje 39) razgovarali smo o filozofiji optimizacije -- o tome kako razmisljati o performansama, zasto je premature optimization opasna, i kako pristupiti problemu sistematski. Sada je vreme da zasucemo rukave i uronimo u konkretne alate koje nam Unreal Engine 5 stavlja na raspolaganje.

Ovo poglavlje je izuzetno prakticno. Necemo pricati o teoriji -- pricacemo o dugmicima, komandama, brojevima i grafikonima. Svaki alat koji ovde pokrijemo, trebalo bi da isprobas odmah. Otvori svoj projekat, ukucaj komandu, pogledaj rezultate. Profiling je vestina koja se uci praksom, ne citanjem.

Hajde da krenemo od najjednostavnijeg alata i postepeno idemo ka slozenijim.

40.1 stat unit -- Prva Komanda Koju Treba Pokrenuti

Ako ikada imas performansni problem u UE5, ovo je uvek prva stvar koju treba da uradis. Bez izuzetka. Otvori konzolu (tilda taster ~) i ukucaj:

stat unit

Sta se prikazuje?

Na ekranu ce se pojaviti overlay sa nekoliko kljucnih brojeva:

Frame:    16.67 ms
Game:      4.20 ms
Draw:      3.10 ms
GPU:      12.50 ms
RHIT:      0.80 ms
DynRes:    ---

Hajde da objasnimo svaku od ovih vrednosti:

Frame -- Ukupno vreme jednog frame-a. Ovo je "konacni odgovor" -- koliko dugo je jedan frame trajao od pocetka do kraja. Za 60 FPS, ova vrednost treba da bude ispod 16.67 ms. Za 30 FPS, ispod 33.33 ms. Ovo je jednostavna matematika:

Game -- Vreme koje Game thread (glavni thread igre) trosi na obradu. Ovo ukljucuje svu logiku igre: Blueprints, C++ Tick funkcije, fiziku, animacije, AI, navigaciju, i sve ono sto "misli" u tvojoj igri. Ako je ova vrednost najveca, imas CPU game thread bottleneck.

Draw (ili Render) -- Vreme koje Render thread provodi pripremajuci draw call-ove za GPU. Render thread je odgovoran za prolazak kroz scenu, odredjivanje sta je vidljivo (visibility/occlusion), pripremu mesh draw command-ova, sortiranje transparentnih objekata, i slanje svega toga GPU-u. Ako je ova vrednost najveca, imas CPU render thread bottleneck.

GPU -- Vreme koje GPU (graficka kartica) provodi renderujuci frame. Ovo ukljucuje vertex processing, rasterizaciju, pixel/fragment shadere, post-processing, i sve sto se desava na samoj grafickoj kartici. Ako je ova vrednost najveca, imas GPU bottleneck.

RHIT -- RHI Thread time. RHI (Rendering Hardware Interface) thread je posrednik izmedju render thread-a i samog grafickog API-ja (DirectX 12, Vulkan). Obicno je ova vrednost mala i retko je bottleneck, ali moze narasti ako imas previše state change-ova.

DynRes -- Dynamic Resolution informacije. Prikazuje se samo ako koristis dynamic resolution scaling.

Kako citati stat unit -- Zlatno pravilo

Pravilo je jednostavno: koji god broj je najveci, to je tvoj bottleneck. Hajde da vidimo primere:

Primer 1: GPU Bound

Frame:    25.00 ms  (40 FPS)
Game:      5.00 ms
Draw:      3.00 ms
GPU:      22.00 ms  <-- OVAJ JE KRIV

GPU je daleko najveci. To znaci da graficka kartica ne stize da zavrsi renderovanje na vreme. Resenja ukljucuju smanjenje rendering load-a: manja rezolucija, jednostavniji shaderi, manje svetala, agresivniji LOD, Nanite podesavanja, smanjenje post-processing efekata.

Primer 2: Game Thread Bound

Frame:    28.00 ms  (35 FPS)
Game:     24.00 ms  <-- OVAJ JE KRIV
Draw:      6.00 ms
GPU:      14.00 ms

Game thread dominira. Nesto u logici igre je previše skupo. Mogucnosti: preskupi Blueprint Tick-ovi, previse fizickih tela, AI koji radi previse posla svaki frame, Garbage Collection koji traje predugo.

Primer 3: Render Thread Bound

Frame:    20.00 ms  (50 FPS)
Game:      4.00 ms
Draw:     17.00 ms  <-- OVAJ JE KRIV
GPU:      10.00 ms

Render thread je bottleneck. Ovo se obicno desava kada imas previše objekata u sceni koji generisu previse draw call-ova, ili kada visibility/occlusion sistem ima previse posla. Resenja ukljucuju instancing, merging mesheva, smanjenje broja objekata vidljivih istovremeno, koristenje HLOD-a.

Primer 4: Balanced (Idealan slucaj)

Frame:    16.00 ms  (62 FPS)
Game:      8.00 ms
Draw:      7.00 ms
GPU:      14.00 ms

Ovde su svi thread-ovi relativno blizu. GPU je jos uvek najveci, ali nije dramaticno. Ovo je zdrav profil -- svi delovi sistema rade otprilike podjednako.

Vazna napomena o paralelizmu

Game, Draw i GPU ne moraju da se sabiraju da bi dali Frame time. Ovi thread-ovi rade paralelno -- Game thread radi na frame N+1 dok Render thread radi na frame N, dok GPU radi na frame N-1. Frame time je odredjen najsporijim od ova tri, ne njihovim zbirom.

Dakle, ako imas:

Game:   10 ms
Draw:    8 ms
GPU:    15 ms

Frame time ce biti oko 15 ms (plus mali overhead), a ne 33 ms.

stat unit -- Kada koristiti

• Uvek prvo. Pre bilo kog drugog profiling alata, pokreni stat unit.
• Tokom razvoja. Navikni se da ga drzis ukljucenim dok radis na sceni.
• Na svim platformama. Pokreni ga na target hardware-u, ne samo na razvojnom PC-ju.
• Pre i posle promena. Napravi screenshot pre nego sto optimizujes nesto, pa uporedi posle.

40.2 stat gpu -- GPU Timing Breakdown

Kada stat unit pokaze da je GPU tvoj bottleneck, sledeci korak je da saznas sta tacno GPU radi toliko dugo. Tu ulazi stat gpu:

stat gpu

Sta se prikazuje?

Ova komanda prikazuje breakdown svih render pass-ova na GPU-u, sa vremenima u milisekundama:

BasePass                    4.20 ms
ShadowDepths                2.80 ms
Lighting                    1.50 ms
HZB                         0.30 ms
PrePass                     1.10 ms
Translucency                0.80 ms
PostProcessing              2.40 ms
  Bloom                     0.60 ms
  MotionBlur                0.40 ms
  Tonemap                   0.30 ms
  DOF                       0.50 ms
  TSR                       0.60 ms
VolumetricFog               0.90 ms
ReflectionEnvironment       0.40 ms

Objasnjenje kljucnih render pass-ova

PrePass (Depth Prepass) -- Prvi prolaz koji renderuje samo dubinu (depth) scene. Ovo pomaze kasnijim prolazima da izbegnu nepotrebno racunanje za piksele koji su skriveni iza drugih objekata (early-z rejection). Ako je ovo skupo, imas previse geometrije ili slozene mesheve.

BasePass -- Glavni rendering prolaz. Ovde se renderuju svi materijali -- boja, normali, roughness, metallic, i sve ostale Material property-je. Ovo je cesto najskuplji prolaz. Ako je prevelik, razlozi mogu biti:

• Previse slozeni materijali (previse instrukcija u shader-u)
• Previse texture sample-ova po materijalu
• Visoka rezolucija ekrana bez koristenja dynamic resolution ili screen percentage
• Previše overdraw-a (transparentni ili masked materijali)

ShadowDepths -- Renderovanje shadow map-ova. Svako svetlo koje baca senke zahteva poseban render pass iz perspektive tog svetla. Ako je ovo skupo:

• Imas previse svetala sa senkama
• Shadow map rezolucija je previsoka
• Shadow distance (Cascaded Shadow Maps distance) je prevelika
• Previse objekata baca senke

Lighting -- Proracun osvetljenja na osnovu svih svetala u sceni. Ovo ukljucuje deferred lighting prolaz, Lumen GI (ako je ukljucen), i sky lighting.

PostProcessing -- Svi post-process efekti: Bloom, Tone Mapping, Motion Blur, Depth of Field, Temporal Super Resolution (TSR), anti-aliasing, color grading, itd. Svaki efekat je naveden posebno, sto je izuzetno korisno.

Translucency -- Renderovanje transparentnih objekata. Ovo je odvojeno od BasePass-a jer transparentni objekti zahtevaju posebno sortiranje i ne koriste deferred rendering pipeline.

VolumetricFog -- Volumetrijska magla i atmosferski efekti. Moze biti skup ako je rezolucija volumetrijske magle visoka ili ako imas mnogo svetala koja doprinose magli.

HZB (Hierarchical Z-Buffer) -- Izgradnja hijerarhijskog Z-buffer-a koji se koristi za occlusion culling na GPU-u i screen-space efekte.

ReflectionEnvironment -- Reflection captures i screen-space reflections.

Kako citati stat gpu

1. Nadji najskuplji pass. Ako BasePass trosi 8 ms od ukupnih 15 ms, fokusiraj se na materijale i geometriju.
2. Uporedi sa ocekivanjima. Za tipicnu igru, BasePass, Shadows i PostProcessing su obicno top 3.
3. Trazi anomalije. Ako VolumetricFog trosi 5 ms, to je verovatno previse i treba ga optimizovati ili iskljuciti.

Tipicni rezultati i sta znace

Napomena o preciznosti

stat gpu koristi GPU timestamps, ali ovi timestamps nisu uvek savrseno precizni na svim GPU-ovima. Na nekim starijim karticama, vremenski intervali mogu biti neprecizni zbog GPU pipeline-a i paralelnog izvrsavanja. Za najpreciznije merenje, koristi GPU Visualizer (sekcija 40.6) ili Unreal Insights (sekcija 40.5).

40.3 stat scenerendering -- Statistike Renderovanja Scene

Dok nam stat gpu govori koliko dugo GPU radi, stat scenerendering nam govori koliko posla engine salje GPU-u. Ukucaj:

stat scenerendering

Sta se prikazuje?

Ova komanda prikazuje kljucne statistike o sceni koja se renderuje:

Mesh draw calls:           2,847
  Static:                  1,234
  Dynamic:                   613
  Total triangles:     4,521,000
Mesh draw commands:        3,460
RHI draw calls (approx):  1,890
Visible static mesh elements: 2,100
Static mesh triangles:   3,200,000
Dynamic primitives:          450
Translucent primitives:       89

Kljucni brojevi i njihovo znacenje

Mesh Draw Calls -- Ovo je broj pojedinacnih poziva ka GPU-u za renderovanje mesheva. Svaki draw call ima overhead na CPU strani (render thread), tako da veci broj draw call-ova znaci veci CPU render thread cost. Grubo pravilo za savremene igre:

Napomena: Ovi brojevi su okvirni i zavise od platforme. Moderna desktop graficka kartica moze podneti vise draw call-ova nego mobilni GPU.

Static vs Dynamic -- Static mesh draw calls dolaze od staticnih objekata u sceni (zgrade, teren, dekoracija). Dynamic draw calls dolaze od objekata koji se krecu (likovi, vozila, projektili). Dynamic draw calls su skuplji jer se ne mogu unapred batching-ovati.

Total Triangles -- Ukupan broj trouglova koji se renderuju u jednom frame-u. Ovo ukljucuje sve sto je vidljivo na ekranu, plus shadow pass geometriju. Za savremene igre:

Sa Nanite-om u UE5, broj trouglova moze biti drasticno veci jer Nanite automatski upravlja LOD-om na per-cluster nivou i renderuje samo ono sto je zaista potrebno na pixel nivou.

Mesh Draw Commands -- Ovo je interni engine koncept -- broj komandi koje render thread generise. Razlikuje se od draw calls jer jedan mesh draw command moze rezultirati u vise draw call-ova (npr. za razlicite shadow cascade-ove).

Visible Static Mesh Elements -- Broj staticnih mesh elemenata koji su prosli visibility test i koji ce se renderovati. Ako je ovaj broj mnogo manji od ukupnog broja mesh elemenata u sceni, to znaci da tvoj occlusion culling radi dobro.

Translucent Primitives -- Transparentni objekti. Ovi su uvek skuplji od opaque objekata jer zahtevaju posebno sortiranje i ne koriste prednosti depth pre-pass-a. Drzi ih na minimumu.

Kako koristiti ove informacije

1. Previse draw call-ova? Razmotriti:

   • Merge actors (vise mesheva u jedan)
   • Hardware instancing (za ponovljene objekte)
   • Hierarchical LOD (HLOD) za udaljene objekte
   • Nanite (koji drasticno smanjuje draw call overhead)

2. Previse trouglova? Razmotriti:

   • LOD sistem -- da li su LOD-ovi pravilno podešeni?
   • Nanite -- koristis li ga za staticne mesheve?
   • Distance culling -- da li se udaljeni mali objekti culuju?
   • Occlusion culling -- da li je efikasan?

3. Previse transparentnih objekata? Razmotriti:

   • Zameni transparentnost sa masked materijalima gde je moguce
   • Koristi dithered opacity za fade efekte
   • Smanji velicinu transparentnih povrsina

Povezane stat komande za scene

Pored stat scenerendering, korisne su i:

stat initviews    -- Statistike o visibility/occlusion culling-u
stat particles    -- Statistike o particle sistemima
stat foliage      -- Statistike o foliage sistemu
stat landscape    -- Statistike o Landscape terenu

Svaka od ovih pruza detaljnije informacije o specificnom aspektu renderovanja scene.

40.4 stat memory -- Analiza Memorije

Memorijski problemi su podmukli -- ne manifestuju se uvek kao nizak FPS, ali mogu dovesti do stutter-a, crash-ova, i sporih loading time-ova. Ukucaj:

stat memory

Sta se prikazuje?

Physical Memory Used:       3,847.00 MB
Physical Memory Free:       4,153.00 MB
Virtual Memory Used:        5,200.00 MB
Peak Physical Memory Used:  4,102.00 MB
Platform Memory:
  Textures:                 1,240.00 MB
  Meshes:                     680.00 MB
  Audio:                      120.00 MB
  Animation:                   85.00 MB
  Physics:                    145.00 MB

Kljucne memorijske metrike

Physical Memory Used -- Koliko fizicke RAM memorije tvoja igra trenutno koristi. Ovo je najvazniji broj za konzole gde je memorija fiksna (npr. PlayStation 5 ima 16 GB ukupno, od cega je oko 12-13 GB dostupno igrama).

Virtual Memory Used -- Ukljucuje i fizicku memoriju i stranicu na disku (page file). Ako je ovo znatno vece od Physical Memory Used, to znaci da se deo memorije swapuje na disk, sto je veoma sporo i moze uzrokovati stutter.

Peak Physical Memory Used -- Maksimalna kolicina fizicke memorije koja je bila koriscena od pokretanja igre. Ovo je korisno za nalazenje memory spike-ova -- cak i ako je trenutna upotreba niska, peak moze pokazati da je u nekom momentu memorija bila kriticno visoka.

Textures -- Memorija koju zauzimaju teksture. Ovo je obicno najveca kategorija. Teksture su "gladne" -- jedna 4K tekstura u nekompresovanom formatu moze zauzeti 64 MB ili vise. Sa kompresijom (BC7, ASTC), to pada na 16-32 MB, ali i dalje je znacajno.

Meshes -- Memorija za vertex i index buffer-e svih mesheva. Sa Nanite-om, ovo moze biti vece nego obicno jer Nanite cuva vise LOD nivoa u memoriji istovremeno (mada u kompresovanom formatu).

Audio -- Zvucni fajlovi u memoriji. Veliki zvucni fajlovi (muzika, ambijentalini zvuci) treba da se stream-uju sa diska, a ne da se drze celi u memoriji.

Dodatne memory stat komande

stat memoryplatform     -- Platform-specificne memorijske informacije
stat memorystatic       -- Staticne memorijske alokacije
stat textures           -- Detaljne informacije o teksturama
stat streaming          -- Texture streaming statistike
stat streamingdetails   -- Jos detaljnije streaming informacije

Posebno je korisna stat streaming:

stat streaming

Ovo pokazuje koliko tekstura se trenutno stream-uje, koliko ih je u memoriji u punoj rezoluciji vs. nizoj rezoluciji, i koliko je texture streaming pool zauzet. Ako je pool pun (100%), igra ne moze da ucita teksture u punoj rezoluciji i koristicete blurry teksture -- fenomen poznat kao "texture pop-in".

Identifikovanje memorijskih problema

Problem: Igra koristi previse memorije

1. Pokreni stat memory i pogledaj koja kategorija dominira
2. Ako su teksture krivac:
   • Smanji Max Texture Size za teksture koje ne moraju biti 4K
   • Koristi texture compression (nikad ne koristi nekompresovane teksture u igri)
   • Proveri da nemas dupliranih tekstura
   • Podesi Texture Streaming Pool Size (r.Streaming.PoolSize)
3. Ako su meshevi krivac:
   • Koristi LOD-ove da smanjis memoriju za udaljene objekte
   • Nanite kompresuje mesh podatke, ali i dalje zauzima memoriju
4. Ako je audio krivac:
   • Stream-uj dugacke audio fajlove umesto da ih drsis u memoriji
   • Koristi kompresovane audio formate

Problem: Stutter koji nije vezan za FPS

Ovo moze biti Garbage Collection (GC). UE5 koristi GC za upravljanje UObject memorijom. Kada GC treba da ocisti vise objekata, moze "zamrznuti" igru na kratko. Koristi:

stat gc

Ovo ce pokazati koliko cesto GC radi i koliko dugo traje svaki GC ciklus. Ako vidis GC pause od 5+ ms, to moze biti izvor stutter-a. Resenja:

• Smanji kolicinu "smeca" koje nastaje (ne kreiraj i unistaj objekte nepotrebno)
• Koristi Object Pooling za cesto koriscene objekte (projektile, efekte)
• Podesi GC parametre (gc.TimeBetweenPurgingPendingKillObjects)
• Koristi incremental GC gde je moguce

Memreport -- Detaljan izvestaj

Za potpunu sliku memorije, koristi konzolnu komandu:

memreport -full

Ovo generise detaljan tekstualni izvestaj o svim memorijskim alokacijama i cuva ga u Saved/Profiling/MemReports/ direktorijumu tvog projekta. Izvestaj sadrzi:

• Listu svih ucitanih objekata sa njihovim velicinama
• Breakdown po klasi (koliko memorije trose svi StaticMesh-evi, koliko svi Material-i, itd.)
• Informacije o texture pool-u
• Detalje o memory allocator-u

Ovaj fajl moze biti velik (desetine megabajta), ali je izuzetno koristan za identifikovanje pojedinacnih "kradljivaca" memorije.

40.5 Unreal Insights -- Sveobuhvatni Profiling Alat

Unreal Insights je UE5-ov najnapredniji profiling alat. Dok su stat komande korisne za brzi pogled, Insights ti daje potpunu sliku svega sto se desava u engine-u, frame po frame, sa microsekundnom preciznoscu.

Sta je Unreal Insights?

Unreal Insights je standalone aplikacija (odvojena od editora) koja moze snimati i analizirati "trace" podatke iz UE5 igre ili editora. Mozes ga zamisliti kao "crnu kutiju" aviona -- snima sve sto se desava, a ti posle mozes da prevrtis snimak i analiziras svaki detalj.

Insights podrzava vise tipova trace-ova:

• CPU Trace -- Svaka funkcija, svaki event, svaki task na svim CPU thread-ovima
• GPU Trace -- GPU render pass-ovi sa preciznim vremenima
• Memory Trace -- Sve memorijske alokacije i dealokacije
• Network Trace -- Mrezni paketi i replication podaci
• Asset Loading Trace -- Ucitavanje asset-a sa diska

Kako pokrenuti Unreal Insights

Metod 1: Iz editora

1. Idi na Tools > Trace > Unreal Insights u glavnom meniju
2. Editor ce pokrenuti Insights aplikaciju automatski

Metod 2: Iz komandne linije

Insights se nalazi u UE5 instalaciji:

Engine/Binaries/Win64/UnrealInsights.exe

Mozes ga pokrenuti direktno.

Metod 3: Snimanje trace-a pri pokretanju igre

Dodaj command line argumente pri pokretanju igre ili editora:

-trace=cpu,gpu,frame,bookmark,memory -statnamedevents

Parametar -statnamedevents je vazan jer ukljucuje citljiva imena za sve event-e. Bez njega, videces samo numericke ID-jeve.

Za snimanje u fajl:

-trace=cpu,gpu,frame,bookmark -tracefile=MyTrace.utrace

Kako snimiti trace iz editora

Najlaksi nacin za brzo snimanje:

1. Pokreni Play in Editor (PIE) ili Standalone igru
2. U konzoli ukucaj: trace.start cpu,gpu,frame,bookmark
3. Igraj scenu koju zelis da profilises (10-30 sekundi je dovoljno)
4. U konzoli ukucaj: trace.stop
5. Trace fajl (.utrace) ce biti sacuvan u Saved/TraceSessions/ direktorijumu

Alternativno, u editoru postoji i Trace Controller panel koji pruza graficki interfejs za pokretanje i zaustavljanje trace-ova.

Insights korisnicko okruzenje (UI)

Kada otvoris .utrace fajl u Insights-u, videces nekoliko glavnih panela:

Timing Panel (Timeline View)

Ovo je najvazniji panel. Prikazuje horizontalnu vremensku liniju sa svim thread-ovima:

GameThread:     [Tick][Physics][AI      ][Anim]
RenderThread:   [        VisibilityCalc         ][DrawCalls    ]
RHI Thread:     [                                ][Submit       ]
GPU:            [PrePass][BasePass     ][Shadows   ][PostProcess]
Worker 0:       [Task1][Task2]
Worker 1:       [         Task3        ]
Worker 2:       [Task4][Task5][Task6]

Svaki pravougaonik predstavlja jedan "scope" -- jednu funkciju ili jedan zadatak. Sirina pravougaonika je proporcionalna vremenu izvrsavanja. Mozes zoomirati (scroll wheel), pomerati (middle mouse drag), i kliknuti na bilo koji pravougaonik da vidis detalje.

Kako citati Timeline

1. Horizontalna osa je vreme (u milisekundama ili mikrosekundama)
2. Vertikalne trake oznacavaju granice frame-ova
3. Boje razlikuju razlicite tipove rada
4. Dubina (nesting) pokazuje hijerarhiju poziva -- funkcija A je pozvala funkciju B koja je pozvala funkciju C

Frame View

Prikazuje histogram gde svaka vertikalna linija predstavlja jedan frame. Visina linije je frame time. Ovo ti omogucava da brzo vidis:

• Prosecni frame time
• Spike-ove (frame-ove koji traju mnogo duze od proseka)
• Paterne (da li se spike-ovi ponavljaju periodicno)

Klikni na bilo koji frame u histogramu da "uskocis" u taj frame u Timeline View-u.

Analiza: Pronalazenje skupih funkcija

Evo prakticnog workflow-a za nalazenje performance problema u Insights:

Korak 1: Identifikuj los frame

U Frame View-u, nadji frame koji traje duze nego sto bi trebalo. Klikni na njega.

Korak 2: Pogledaj thread-ove

U Timeline View-u, pogledaj koji thread je najduzi (najsiri) za taj frame:

• Ako je Game Thread najduzi -- problem je u logici igre
• Ako je Render Thread najduzi -- problem je u rendering pripremi
• Ako je GPU track najduzi -- problem je na grafickoj kartici

Korak 3: Zumiraj i nadji krivca

Zumiraj u najduzi thread. Nadji najveci pravougaonik (najduzu funkciju). Klikni na nju da vidis:

• Puno ime funkcije
• Vreme izvrsavanja (inclusive -- sa svim pod-funkcijama, i exclusive -- samo ta funkcija)
• Broj poziva (call count)

Korak 4: Analiziraj kontekst

Cesto ce "krivac" biti genericki (npr. UWorld::Tick), pa treba da zumirani dublje -- da vidis sta unutar tog tick-a trosi najvise vremena. Mozda je to AMyActor::Tick, mozda je UPhysicsSimulation::Step, mozda je FNavigationSystem::Update.

Analiza: Pronalazenje hitch-ova (stutter-a)

Hitch-ovi su frame-ovi koji traju mnogo duze od proseka. Insights ih pravi veoma vidljivim:

1. U Frame View-u, nadji spike (visoku liniju)
2. Klikni na nju
3. U Timeline View-u, pogledaj sta se desava u tom frame-u sto se ne desava u normalnim frame-ovima
4. Cesti uzroci hitch-ova:
   • Garbage Collection -- videces CollectGarbage scope na Game Thread-u
   • Asset Loading -- videces LoadObject ili AsyncLoading scope-ove
   • Shader Compilation -- videces CompileShader scope-ove (cesto u editoru)
   • Level Streaming -- videces StreamLevel scope-ove
   • Texture Streaming -- GPU stall dok se tekstura uploaduje

Memory Trace

Ako si ukljucio memory trace (-trace=memory), Insights prikazuje poseban panel sa:

• Allocation Timeline -- Grafik koji pokazuje ukupnu memorijsku upotrebu tokom vremena
• Allocation Call Stack -- Za svaku alokaciju, mozes videti koja funkcija je alocirala memoriju
• Allocation Size Distribution -- Histogram velicina alokacija

Ovo je izuzetno korisno za nalazenje memory leak-ova: ako grafik memorije konstantno raste tokom vremena bez da opada, imas leak.

Poredjenje sa stat komandama

Preporuka: Koristi stat komande za svakodnevno pracenje i brzu dijagnostiku. Koristi Insights kada treba da duboko analiziras konkretan problem.

Saveti za efikasno koristenje Insights-a

1. Snimaj kratke trace-ove. 10-30 sekundi je obicno dovoljno. Duzi trace-ovi su veci i tezi za analizu.

2. Koristi bookmarks. U kodu mozes dodati TRACE_BOOKMARK(TEXT("MojEvent")) da oznacis interesantne momente u trace-u. Ovo ti pomaze da nadjes tacne trenutke koje zelis da analiziras.

3. Filtriraj thread-ove. Nemoj gledati sve thread-ove istovremeno -- fokusiraj se na Game Thread ili Render Thread zavisno od problema.

4. Poredi frame-ove. Nadji "dobar" frame (brz) i "los" frame (spor) i uporedi ih -- sta je drugacije?

5. Ukljuci -statnamedevents. Bez ovoga, mnogi scope-ovi nece imati citljiva imena, sto dramaticno otezava analizu.

40.6 GPU Visualizer (ProfileGPU)

GPU Visualizer je specijalizovani alat za analizu GPU rendering pipeline-a. Dok stat gpu daje tekstualni pregled, GPU Visualizer daje vizuelni waterfall chart sa hijerarhijom.

Kako pokrenuti GPU Visualizer

Metod 1: Precica na tastaturi

Pritisni Ctrl+Shift+, (Ctrl+Shift+Comma) u editoru. Ovo ce snimiti jedan frame i prikazati rezultate.

Metod 2: Konzolna komanda

ProfileGPU

ili

r.ProfileGPU 1

Sta se prikazuje?

GPU Visualizer otvara poseban prozor (ili tab u editoru) sa waterfall chart-om koji izgleda otprilike ovako:

Scene (16.2 ms)
+-- PrePass (1.8 ms)
|   +-- Static (1.2 ms)
|   +-- Dynamic (0.6 ms)
+-- BasePass (5.4 ms)
|   +-- Opaque (4.8 ms)
|   +-- Masked (0.6 ms)
+-- ShadowDepths (3.2 ms)
|   +-- WholeScene CSM (2.4 ms)
|   |   +-- Cascade 0 (0.8 ms)
|   |   +-- Cascade 1 (0.7 ms)
|   |   +-- Cascade 2 (0.5 ms)
|   |   +-- Cascade 3 (0.4 ms)
|   +-- Per-Object Shadows (0.8 ms)
+-- Lighting (2.1 ms)
|   +-- Direct Lighting (1.2 ms)
|   +-- Global Illumination (0.9 ms)
+-- PostProcessing (3.7 ms)
    +-- TSR (1.2 ms)
    +-- Bloom (0.6 ms)
    +-- DOF (0.8 ms)
    +-- Tonemapping (0.4 ms)
    +-- Other (0.7 ms)

Kako citati waterfall chart

1. Hijerarhija -- Svaki element moze imati pod-elemente. Ovo ti pokazuje tacno gde unutar svakog prolaza se trosi vreme.

2. Horizontalne trake -- Svaka traka predstavlja jedan GPU task. Duzina trake je proporcionalna vremenu. Trake su organizovane hronoloski -- prvi prolaz je na vrhu, poslednji na dnu.

3. Boje -- Razlicite boje oznacavaju razlicite tipove prolaza (geometry, lighting, post-process, itd.).

4. Procenat -- Pored svakog elementa je prikazan procenat ukupnog GPU vremena koji taj element koristi.

Prakticna upotreba GPU Visualizer-a

Scenario 1: BasePass dominira

Ako BasePass zauzima vise od 40% ukupnog GPU vremena, pogledaj pod-elemente:

• Ako je "Opaque" deo velik -- imas previse geometrije ili preslozene materijale
• Ako je "Masked" deo velik -- masked materijali su skuplji od opaque (ne mogu koristiti early-z rejection efikasno). Razmisli da li mozes zameniti masked sa opaque.

Scenario 2: ShadowDepths dominira

Pogledaj koliko cascade-ova imas i koliko svaki trosi:

• Cascade 0 (najblizi igracu) je obicno najskuplji jer sadrzi najdetaljniju geometriju
• Razmisli o smanjenju broja cascade-ova ili njihovog dometa
• Pogledaj Per-Object Shadows -- da li je previse objekata konfigurisano za per-object senke?

Scenario 3: PostProcessing dominira

Pogledaj koji konkretni efekat je najskuplji:

• TSR (Temporal Super Resolution) -- probaj r.ScreenPercentage da smanjis input rezoluciju
• DOF (Depth of Field) -- probaj nizi kvalitet ili ga iskljuci na nizim quality settings-ima
• Bloom -- obicno nije skup, ali moze biti na niskim rezolucijama sa velikim kernel-om

Ogranicenja GPU Visualizer-a

• Prikazuje samo jedan frame. Ne mozes videti varijacije tokom vremena.
• Na nekim GPU-ovima, timestamps mogu biti neprecizni za veoma kratke prolaze.
• Ne pokazuje shader-level breakdown (za to ti trebaju vendor-specificni alati koje pokrivamo u Poglavlju 41).
• U editoru, GPU Visualizer ukljucuje i editor UI renderovanje, sto moze "zagaditi" rezultate. Za najpreciznije merenje, koristi Standalone igru.

40.7 Frame Profiler

Frame Profiler je stariji UE profiling alat koji je i dalje koristan za brzu analizu pojedinacnih frame-ova. On se razlikuje od Insights-a po tome sto je integrisan direktno u editor i ne zahteva snimanje trace-a.

Kako koristiti Frame Profiler

Korak 1: Ukljuci snimanje

U konzoli ukucaj:

stat startfile

Ovo pocinje snimanje profiling podataka u .ue4stats fajl.

Korak 2: Igraj scenu

Reprodukuj situaciju sa performance problemom. Snimaj 5-15 sekundi.

Korak 3: Zaustavi snimanje

stat stopfile

Fajl ce biti sacuvan u Saved/Profiling/ direktorijumu.

Korak 4: Otvori u Session Frontend-u

Idi na Window > Developer Tools > Session Frontend (ili Tools > Session Frontend u nekim verzijama UE5). U tabu Profiler, ucitaj sacuvani fajl.

Sta mozes videti u Frame Profiler-u

Graph View

Grafik koji pokazuje frame time tokom vremena. Mozes identifikovati spike-ove i kliknuti na bilo koji frame za detalje.

Call Tree

Za izabrani frame, vidis hijerarhiju svih funkcija sa:

• Inclusive Time -- Vreme funkcije ukljucujuci sve funkcije koje ona poziva
• Exclusive Time -- Vreme samo te funkcije, bez pod-poziva
• Call Count -- Koliko puta je funkcija pozvana u tom frame-u

Ovo je izuzetno korisno za identifikovanje:

• Funkcija koje se pozivaju previse puta (npr. neka Tick funkcija koja poziva nesto u petlji)
• Funkcija koje su same po sebi skupe (visok exclusive time)
• Neocekivanih poziva (zasto se ova funkcija uopste poziva?)

Flat View

Lista svih funkcija sortirano po vremenu. Ovo ti brzo pokazuje "top 10" najskupljih funkcija bez da moras da navigiras kroz hijerarhiju.

Prakticni saveti

1. Sortiraj po Exclusive Time da nadjes funkcije koje su same po sebi skupe.
2. Sortiraj po Call Count da nadjes funkcije koje se pozivaju previse cesto.
3. Uporedi spike frame sa normalnim frame-om -- sta se razlikuje?
4. Filtriraj po thread-u -- fokusiraj se na Game Thread ili Render Thread.

Frame Profiler vs Insights

Za vecinu savremenih workflow-ova, Unreal Insights je superiorniji alat. Medjutim, Frame Profiler ima prednost sto je integrisan u editor i ne zahteva dodatan setup. Ako ti treba brza analiza i ne zelis da se bakces sa Insights-om, Frame Profiler je i dalje validan izbor.

Imaj na umu da je Insights aktivno razvijan od strane Epic-a i dobija nove feature-e sa svakom verzijom UE5, dok je Frame Profiler vise u "maintenance" modu. Na duze staze, investiraj vreme u ucenje Insights-a.

40.8 Vizualizacioni Modovi (Visualization Modes)

UE5 editor ima mnostvo vizualizacionih modova koji ti omogucavaju da vidis razlicite aspekte renderovanja. Umesto da gledas brojeve, mozes videti probleme direktno na ekranu -- obojene, istaknute, ocigledne.

Vizualizacioni modovi se nalaze u Viewport-u, u padajucem meniju View Mode (gde obicno pise "Lit").

Shader Complexity

Gde: View Mode > Optimization Viewmodes > Shader Complexity

Sta pokazuje: Koliko je shader (materijal) svake povrsine skup za renderovanje. Boje idu od zelene (jeftin) preko crvene (skup) do bele (veoma skup):

Kada koristiti: Kada stat gpu pokaze da je BasePass ili Translucency skup. Shader Complexity ti pokazuje gde tacno na ekranu je problem.

Sta traziti:

• Velike oblasti crvene/bele boje -- ovi materijali treba da se pojednostave
• Transparentni objekti koji se preklapaju (svaki sloj se racuna!) -- ovo cesto dovodi do bele boje
• Foliage sa complex materijalom na svakom listu

Saveti za optimizaciju na osnovu rezultata:

• Smanji broj texture sample-ova u skupim materijalima
• Zameni kompleksne matematicke operacije sa lookup teksturama (LUT)
• Koristi Material Quality Switch za razlicite platforme
• Koristi Material LOD (Simplify materijal na vecoj udaljenosti)

Quad Overdraw

Gde: View Mode > Optimization Viewmodes > Quad Overdraw

Sta pokazuje: Koliko puta se svaki piksel na ekranu renderuje. GPU obradjuje piksele u grupama od 2x2 (quad). Kad malu geometriju (tanke linije, sitni trouglovi) renderujes, mnogi pikseli u quad-u se "bacaju" jer ne pripadaju tom trouglu -- ali GPU je ipak morao da ih obradi.

Kada koristiti: Kada sumnjam da imas previse slojeva transparentnosti ili previse finih detalja (foliage, grass, hair) koji uzrokuju pixel waste.

Sta traziti:

• Oblasti sa crvenim/belim overdraw-om -- ovo su "vruce tacke" za GPU
• Transparentni efekti (dim, vatra, cestice) koji se preklapaju
• Foliage sa mnogo malih listova

Light Complexity

Gde: View Mode > Optimization Viewmodes > Light Complexity

Sta pokazuje: Koliko svetala utice na svaku povrsinu u sceni. Boje idu od tamne (malo svetala) do svetle (mnogo svetala):

Kada koristiti: Kada je Lighting pass skup u stat gpu. Previse svetala koje se preklapaju stvara veliki GPU load.

Sta traziti:

• Oblasti gde se mnogo svetala preklapa (svetle boje)
• Point Light-ovi sa prevelikim radius-om koji pokrivaju vise nego sto treba
• Svetla koja su nepotrebno blizu jedan drugog

Saveti:

• Smanji Attenuation Radius svetala da pokrivaju samo oblast koju zaista treba da osvetle
• Koristi "Max Draw Distance" na svetlima da se ne renderuju kada su daleko
• Razmotriti baked lighting za staticna svetla

Stationary Light Overlap

Gde: View Mode > Optimization Viewmodes > Stationary Light Overlap

Sta pokazuje: Gde se preklapaju Stationary svetla. UE5 podrzava maksimalno 4 stationary svetla koja se preklapaju na istoj povrsini. Ako se vise od 4 preklapa, dodatna svetla postaju potpuno dinamicna (mnogo skuplja).

Kada koristiti: Kada koristis Stationary svetla i primetis da su neka svetla neocekivano skupa ili da senke ne izgledaju dobro.

Sta traziti:

• Crvene oblasti -- tu imas previse Stationary svetala. Prebaci neka u Baked (Static) ili Dynamic.

Texture Streaming Accuracy

Gde: Dostupno kroz show TextureStreamingAccuracy ili View Mode > Optimization Viewmodes

Sta pokazuje: Koliko dobro texture streaming radi. Da li su teksture prikazane u odgovarajucoj rezoluciji za datu udaljenost kamere?

Kada koristiti: Kada primetis blurry teksture u igri ili kada zelis da optimizujes texture memory usage.

Sta traziti:

• Crvene oblasti -- ove teksture nemaju dovoljno memorije za punu rezoluciju. Povecaj Texture Streaming Pool.
• Plave oblasti -- ove teksture zauzimaju vise memorije nego sto treba. Mozes smanjiti njihov Streaming LOD Bias.

Nanite Vizualizacioni Modovi

UE5 donosi posebne vizualizacione modove za Nanite:

Nanite Visualization > Triangles

Prikazuje stvarne trouglove koje Nanite renderuje. Svaki trougao je obojen drugom bojom, sto ti pokazuje koliko detalja Nanite zaista renderuje na razlicitim udaljenostima. Korisno za verifikaciju da Nanite pravilno uprosti geometriju u daljini.

Nanite Visualization > Clusters

Prikazuje Nanite cluster-e. Nanite deli geometriju u male grupe trouglova (clusters) i odlucuje za svaki cluster koji LOD nivo da koristi. Ova vizualizacija ti pokazuje te cluster-e i njihove LOD nivoe.

Nanite Visualization > Overdraw

Slicno standardnom Quad Overdraw modu, ali specifično za Nanite renderovanje. Pokazuje gde Nanite renderuje vise geometrije nego sto je vidljivo (npr. iza drugih objekata).

Nanite Visualization > Material Complexity

Prikazuje koliko razlicitih materijala Nanite mora da obradi. Previse razlicitih materijala na Nanite meshevima moze biti skupo jer svaki materijal zahteva poseban rendering pass u Nanite pipeline-u.

Kada koristiti Nanite vizualizacije:

• Kada zelis da verifikujes da Nanite radi efikasno
• Kada imas performance probleme sa scenama koje koriste Nanite
• Kada zelis da vidis koliko trouglova Nanite zaista renderuje vs. koliko originalni meshevi imaju

Lumen Vizualizacioni Modovi

Ako koristis Lumen za Global Illumination i refleksije, postoje i vizualizacioni modovi za Lumen:

Lumen Scene -- Prikazuje simplifikovanu scenu koju Lumen koristi za ray tracing. Ako objekti nisu vidljivi u Lumen Scene-u, nece doprinositi globalnom osvetljenju.

Lumen > Surface Cache Coverage -- Prikazuje da li Lumen ima dovoljno podataka o povrsinskim materijalima za tacno globalnom osvetljenju.

Kako efikasno koristiti vizualizacione modove

1. Pocni sa Shader Complexity -- daje ti najsiru sliku problema.
2. Ako vidis vruce tacke, koristi specificni mod (Light Complexity za svetla, Quad Overdraw za transparentnost).
3. Napravi screenshot pre optimizacije, pa uporedi posle -- da li su se vruce tacke smanjile?
4. Koristi vizualizacione modove na target rezoluciji -- performansni problemi zavise od rezolucije.
5. Ne zaboravi na Nanite modove -- ako koristis Nanite, ovo je obavezan korak.

40.9 Konzolne Komande za Profiling

UE5 konzola je "svajcarski noz" za profiling. Pored vec pomenutih stat komandi, postoji citav arsenal komandi za dijagnostiku i testiranje. Hajde da prodjemo kroz najvaznije.

Osnovne stat komande

stat fps

Najjednostavniji prikaz -- pokazuje samo FPS i Frame Time. Korisno za brzi pogled, ali stat unit daje vise informacija.

stat unitgraph

Umesto brojeva, prikazuje grafik Game/Render/GPU vremena tokom vremena. Ovo je odlicno za identifikovanje periodicnih spike-ova ili postepene degradacije performansi.

stat engine

Prikazuje razne engine statistike ukljucujuci frame time, game thread time, i broj objekata u igri.

stat game

Prikazuje statistike specificne za game logiku -- Tick vreme, blueprint vreme, i slicno.

stat slow

Automatski prikazuje samo funkcije cije izvrsavanje prelazi odredjeni threshold. Korisno za nalazenje "krivaca" bez previse informacija.

Screen Percentage za GPU testiranje

r.ScreenPercentage 50

Ova komanda je izuzetno korisna za dijagnostiku. Smanjuje internu rendering rezoluciju na 50% (sto smanjuje GPU load za ~75%, jer je broj piksela proporcionalan kvadratu rezolucije).

Kako koristiti za dijagnostiku:

1. Podesi r.ScreenPercentage 50
2. Ako FPS dramaticno poraste -- tvoj problem je GPU pixel bound (shader cost, post-processing)
3. Ako FPS ostane isti -- tvoj problem nije u pikselima, vec u geometriji (vertex processing) ili na CPU-u
4. Vrati nazad: r.ScreenPercentage 100

Ovo je jedan od najbrzih nacina da utvrdi da li je tvoj bottleneck u pixel shaderima ili negde drugde. Mozes probati i razlicite vrednosti:

r.ScreenPercentage 100   -- Puna rezolucija (default)
r.ScreenPercentage 75    -- 75% rezolucije
r.ScreenPercentage 50    -- 50% rezolucije
r.ScreenPercentage 25    -- 25% rezolucije (sve ce biti blurry, ali performanse ce ti reci mnogo)

FreezeRendering za debugging

FreezeRendering

Ova komanda "zamrzava" renderovanje scene -- kamera prestaje da se azurira, ali igra nastavlja da radi. Ovo ti omogucava da:

1. Pozicioniras kameru na problematicno mesto
2. Ukucas FreezeRendering
3. Pomeras kameru slobodno i gledas scenu iz razlicitih uglova
4. Vidis sta je renderovano i sta je occlusion culling sakrio
5. Ukucas FreezeRendering ponovo da se odmrznes

Ovo je korisno za debugging occlusion culling-a i razumevanje sta GPU zapravo renderuje.

Show komande za selektivno iskljucivanje

show komande ti omogucavaju da selektivno ukljucis/iskljucis razlicite rendering feature-e. Ovo je kljucni alat za sistematsko nalazenje bottleneck-a.

show PostProcessing       -- Toggle svih post-process efekata
show Bloom                -- Toggle samo Bloom-a
show DynamicShadows       -- Toggle dinamickih senki
show Fog                  -- Toggle magle
show Particles            -- Toggle particle efekata
show SkeletalMeshes       -- Toggle skeletal mesheva (karakteri, animirani objekti)
show StaticMeshes         -- Toggle staticnih mesheva
show Translucency         -- Toggle transparentnosti
show Decals               -- Toggle decals-a
show Lighting             -- Toggle osvetljenja
show GlobalIllumination   -- Toggle globalnog osvetljenja (Lumen)
show Reflections          -- Toggle refleksija
show VolumetricFog        -- Toggle volumetrijske magle
show InstancedGrass       -- Toggle instanced trave
show InstancedFoliage     -- Toggle instanced vegetacije
show Landscape            -- Toggle Landscape terena
show BSP                  -- Toggle BSP geometrije

Sistematski pristup sa show komandama

Evo workflow-a za nalazenje rendering bottleneck-a koristeci show komande:

Korak 1: Zabeleži baseline

stat unit

Zabeleži GPU vreme. Na primer: GPU = 22 ms (45 FPS).

Korak 2: Iskljuci post-processing

show PostProcessing

Pogledaj GPU vreme. Ako padne na 15 ms -- post-processing je odgovoran za 7 ms. To je znacajno!

Korak 3: Vrati post-processing, iskljuci senke

show PostProcessing       (vrati nazad)
show DynamicShadows

Pogledaj GPU vreme. Ako padne na 17 ms -- senke trose 5 ms.

Korak 4: Nastavi sa drugim feature-ima

Ponovi za svaki feature koji sumnjas. Na kraju ces imati listu:

PostProcessing:     7 ms
DynamicShadows:     5 ms
VolumetricFog:      3 ms
Particles:          2 ms
Reflections:        1 ms
Ostalo:             4 ms
UKUPNO:            22 ms

Sada tacno znas gde da fokusiras optimizaciju. Kreni od najveceg "krivca" (PostProcessing u ovom primeru).

Vazna napomena: Zbir pojedinacanjih ušteda obicno nece tacno dati ukupan GPU time jer GPU radi paralelno i postoje zavisnosti izmedju prolaza. Ali redosled prioriteta ce biti tacnan.

Dodatne korisne konzolne komande

r.SetRes 1920x1080f       -- Postavi rezoluciju (f = fullscreen, w = windowed)
r.VSync 0                 -- Iskljuci VSync (vazno za precizno merenje!)
t.MaxFPS 0                -- Ukloni FPS cap (vazno za precizno merenje!)
r.AllowOcclusionQueries 0 -- Iskljuci occlusion queries (za debugging)
r.EarlyZPass 0            -- Iskljuci depth prepass

VAZNO: Pre svakog profiling session-a, obavezno iskljuci VSync i FPS cap:

r.VSync 0
t.MaxFPS 0

Ako je VSync ukljucen, FPS ce biti zakljucan na refresh rate monitora (obicno 60 Hz), i neceg moci da vidis koliko bi igra zapravo brza bila bez tog ogranicenja. Slicno, t.MaxFPS moze vestacki ograniciti frame rate.

GPU Debugging komande

r.RHICmdBypass 1           -- Bypass RHI command list za debugging
r.ShaderPipelineCache.Enabled 0  -- Iskljuci shader pipeline cache
r.Nanite.Visualize.OverdrawComplexity 1  -- Nanite overdraw vizualizacija
r.Lumen.Visualize.Mode 1   -- Lumen debug vizualizacija

Profiling u razlicitim scenarijima

Ponekad zelis da profilises specifican deo igre. Evo nekih korisnih kombinacija:

Za profiling UI:

stat slate               -- Slate UI framework statistike
stat widgetreflector      -- Otvara Widget Reflector za debug UI hijerarhije

Za profiling fizike:

stat physics              -- Fizika statistike
stat collision            -- Collision detection statistike
p.VisualizeSimulation 1   -- Vizualizacija fizicke simulacije

Za profiling animacija:

stat anim                 -- Animacioni sistem statistike
a.VisualizeAllSkeletalMeshLODs 1  -- Prikaz LOD nivoa skeletal mesheva

Za profiling AI:

stat ai                   -- AI sistem statistike
stat navmesh              -- Navigation mesh statistike
ai.debug.nav 1            -- Vizualizacija NavMesh-a

40.10 Prakticni Profiling Workflow

Sada kada znamo sve alate, hajde da ih spojimo u prakticni workflow. Zamislimo realan scenario:

Scenario: "Moja scena radi na 40 FPS, a treba mi 60 FPS"

Evo korak-po-korak procesa za nalazenje i resavanje problema:

Korak 1: Priprema

Pre svega, osiguraj da profiling rezultati budu tacni:

r.VSync 0
t.MaxFPS 0

Takodje, zatim probaj da pokrenes igru u Standalone modu umesto u PIE (Play in Editor), jer editor troši znacajne resurse koji mogu iskriviti rezultate. Koristi Launch dugme ili pokreni igru sa command line.

Korak 2: Identifikuj bottleneck (stat unit)

stat unit

Pogledaj brojeve. Recimo da vidis:

Frame:   25.00 ms  (40 FPS)
Game:     6.00 ms
Draw:     4.00 ms
GPU:     22.00 ms

Zakljucak: GPU je bottleneck. Moramo smanjiti GPU load sa 22 ms na ispod 16.67 ms (za 60 FPS).

Korak 3: Razumi GPU breakdown (stat gpu)

stat gpu

Rezultat:

BasePass:          8.00 ms
ShadowDepths:      5.00 ms
PostProcessing:    4.00 ms
Lighting:          2.50 ms
Translucency:      1.50 ms
Other:             1.00 ms
Total:            22.00 ms

Zakljucak: Top 3 krivca su BasePass (8 ms), ShadowDepths (5 ms), i PostProcessing (4 ms).

Korak 4: Screen Percentage test

r.ScreenPercentage 50

Rezultat: GPU pada na 12 ms.

Zakljucak: Znacajan deo GPU load-a je pixel-bound (shader cost na velikom broju piksela). Ovo nam govori da su materijali i/ili post-processing skupi.

Vrati nazad:

r.ScreenPercentage 100

Korak 5: Vizualizacioni modovi

Prebaci na Shader Complexity mod. Vidis da:

• Veliki deo poda je crvene boje (skup materijal sa mnogo slojeva)
• Vegetacija u pozadini je narandzasta (complex foliage shader)
• Nebo je zeleno (jeftino, OK)

Zakljucak: Materijal poda i vegetacije treba pojednostaviti.

Korak 6: Show komande za potvrdu

show DynamicShadows

GPU pada na 17 ms. Znaci senke trose 5 ms -- poklapa se sa stat gpu.

show DynamicShadows       (vrati)
show PostProcessing

GPU pada na 18 ms. Post-processing trosi 4 ms -- takodje se poklapa.

Korak 7: Prioritizuj optimizacije

Na osnovu analize, evo plana optimizacije po prioritetu:

1. BasePass (8 ms -> cilj 4 ms)

   • Pojednostavi materijal poda (smanji texture sample-ove sa 12 na 6)
   • Koristi Material LOD za vegetaciju (jednostavniji materijal na > 50m)
   • Razmotriti koristenje Nanite-a za staticne mesheve

2. ShadowDepths (5 ms -> cilj 2.5 ms)

   • Smanji Shadow Distance sa 20,000 na 10,000 jedinica
   • Smanji broj cascade-ova sa 4 na 3
   • Iskljuci senke na malim objektima (dekoracija, kamenje)

3. PostProcessing (4 ms -> cilj 2 ms)

   • Smanji Bloom kvalitet
   • Iskljuci Motion Blur (ili ga postavi na nizak kvalitet)
   • Razmotriti koristenje TSR na nizoj input rezoluciji

Korak 8: Implementiraj i meri

Implementiraj prvu optimizaciju (materijal poda). Ponovo pokreni stat unit i stat gpu.

Frame:   21.00 ms  (47 FPS)
Game:     6.00 ms
Draw:     4.00 ms
GPU:     18.00 ms

BasePass je pao sa 8 na 5 ms. Napredak! Nastavi sa sledecim stavkama.

Korak 9: Ponovi dok ne postignes cilj

Posle svih optimizacija:

Frame:   15.50 ms  (64 FPS!)
Game:     6.00 ms
Draw:     4.00 ms
GPU:     13.50 ms

Cilj postignut -- igra radi iznad 60 FPS.

Korak 10: Verifikuj na target hardware-u

Tvoj razvojni PC je verovatno jaci od target hardware-a. Uvek verifikuj performanse na najslabijem hardveru koji planiras da podrzis. Ovo moze biti:

• Steam Deck za PC igre
• Najslabija konzola (npr. Xbox Series S vs Series X)
• Entry-level GPU za minimum specifikacije

Profiling Checklist

Evo kompletne checklist-e za profiling session:

[ ] Iskljuci VSync i FPS cap
[ ] Pokreni igru u Standalone modu (ne PIE)
[ ] stat unit -- identifikuj bottleneck thread
[ ] stat gpu -- identifikuj najskuplji render pass
[ ] stat scenerendering -- proveri draw calls i triangle count
[ ] r.ScreenPercentage 50 -- testira da li je problem pixel-bound
[ ] Shader Complexity mode -- vizuelna identifikacija skupih materijala
[ ] show komande -- selektivno iskljucuj feature-e za potvrdu
[ ] Napravi plan optimizacije po prioritetu
[ ] Implementiraj jednu optimizaciju, izmeri rezultat
[ ] Ponavljaj dok ne postignes cilj
[ ] Verifikuj na target hardware-u

Ceste greske pri profiling-u

Greska 1: Profiling u editoru umesto u igri

Editor trosi znacajne resurse za UI, outliner, content browser, itd. Uvek profiliši u Standalone modu za tacne rezultate.

Greska 2: Profiling sa ukljucenim VSync-om

VSync ogranicava FPS na refresh rate monitora. Ako tvoja igra moze da radi na 55 FPS, VSync ce je zakljucati na ~30 FPS (jer ne moze da dostigne 60). Uvek iskljuci VSync pre profiling-a.

Greska 3: Optimizovanje bez merenja

Nikad ne optimizuj "na slepo". Uvek izmeri pre i posle. Ponekad optimizacija koja "logicki" treba da pomogne zapravo nema nikakav efekat (ili cak pogorsava performanse).

Greska 4: Fokusiranje na pogresan bottleneck

Ako je GPU bottleneck, optimizovanje CPU koda nece pomoci (i obrnuto). Uvek prvo identifikuj bottleneck sa stat unit.

Greska 5: Profiling samo jedne scene

Razlicite scene imaju razlicite bottleneck-e. Open world scena moze biti GPU bound, dok je menu screen CPU bound. Profiliši svaku scenu posebno.

Greska 6: Merenje samo prosecnog FPS-a

Prosecni FPS moze biti 60, ali ako imas spike-ove od 100 ms svake 2 sekunde, igra ce se osecati lose. Obraca paznju na frame time konzistentnost, ne samo na prosek. Koristi stat unitgraph ili Insights za identifikaciju spike-ova.

Greska 7: Profiling u Debug build-u

Debug build je znatno sporiji od Development ili Shipping build-a. Uvek profiliši barem u Development build-u. Za najrealisticnije rezultate, koristi Shipping build sa profiling instrumentacijom:

-trace=cpu,gpu,frame,bookmark -statnamedevents

Napredni scenario: Render Thread Bottleneck

Sta ako stat unit pokaze:

Frame:   25.00 ms
Game:     5.00 ms
Draw:    20.00 ms  <-- RENDER THREAD!
GPU:     12.00 ms

Render thread je bottleneck, sto je manje uobicajeno ali se desava. Evo kako da ga analiziras:

1. stat scenerendering -- Proveri draw call count

   • Ako imas > 5000 draw calls, to je verovatno problem
   • Resenje: Merge mesheve, koristi instancing, HLOD

2. stat initviews -- Proveri visibility/occlusion vreme

   • Ako je Visibility cull vreme visoko, imas previse objekata u sceni
   • Resenje: Koristi distance culling, HLOD, smanji broj malih objekata

3. Unreal Insights -- Snimi trace i pogledaj Render Thread

   • Nadji najskuplju funkciju na render thread-u
   • Cest krivac: FDeferredShadingSceneRenderer::Render sa mnogo pod-poziva za draw call pripremu

4. Resenja za render thread:

   • Smanji broj vidljivih objekata (distance cull, HLOD, occlusion volumes)
   • Koristi Nanite (koji drasticno smanjuje render thread overhead)
   • Merge staticne mesheve u vece grupe
   • Koristi instanced static meshes za ponovljene objekte

Napredni scenario: Game Thread Bottleneck

Frame:   30.00 ms
Game:    25.00 ms  <-- GAME THREAD!
Draw:     5.00 ms
GPU:     10.00 ms

Game thread je bottleneck. Evo pristupa:

1. stat game -- Pogledaj opste game thread statistike

2. stat slow -- Automatski prikazuje skupe funkcije

3. Unreal Insights -- Ovo je najkorisniji alat za game thread probleme

   • Snimi trace
   • Pogledaj Game Thread timeline
   • Nadji najskuplju funkciju
   • Cesti krivci:
     • UWorld::Tick > TickActors -- previse Actor-a sa skupim Tick-ovima
     • UPhysicsEngine::Simulate -- fizicka simulacija je preskupa
     • UNavigationSystem::Tick -- AI navigation je skupa
     • GarbageCollect -- GC traje predugo
     • BlueprintVM -- Blueprint visual scripting je spor

4. Resenja za game thread:

   • Smanji Tick rate za Actor-e koji ne moraju da tick-uju svaki frame
   • Prebaci Blueprint logiku u C++ za kriticne sisteme
   • Koristi Tick Groups i Tick Dependencies za bolji paralelizam
   • Smanji broj fizickih tela ili koristi simplifikovane collision mesheve
   • Optimizuj AI (smanjuj navigacione query-je, koristi LOD za AI)
   • Koristi Object Pooling umesto stalnog kreiranja/unistenja objekata
   • Razmisli o async task-ovima za posao koji ne mora biti na game thread-u

Kljucni Pojmovi (Glosar)

Preporuceno Citanje i Resursi

Zvanicna dokumentacija

• Unreal Engine Performance and Profiling -- Glavni hub za profiling dokumentaciju na Unreal Engine sajtu: docs.unrealengine.com/5.0/en-US/performance-and-profiling-in-unreal-engine/

• Unreal Insights Documentation -- Detaljno uputstvo za koristenje Insights alata: docs.unrealengine.com/5.0/en-US/unreal-insights-in-unreal-engine/

• GPU Profiling -- Specificna dokumentacija za GPU profiling: docs.unrealengine.com/5.0/en-US/gpu-profiling-in-unreal-engine/

• Stat Commands -- Kompletan spisak svih stat komandi: docs.unrealengine.com/5.0/en-US/stat-commands-in-unreal-engine/

Epic Games prezentacije i blogovi

• "Maximizing Your Game's Performance in Unreal Engine" -- GDC prezentacija od Epic Games koja pokriva profiling workflow od pocetka do kraja

• "Performance Budgets and Profiling in UE5" -- Inside Unreal livestream koji demonstrira prakticnu upotrebu profiling alata

• Unreal Engine Blog -- Redovno objavljuje clanke o performansama i optimizaciji: unrealengine.com/blog

Community resursi

• UE5 Performance Guide -- Community wiki sa prakticnim savetima: Pretraziti "Unreal Engine 5 Performance Guide" na community wiki

• Unreal Slackers Discord -- Aktivan Discord server sa kanalima za performanse i optimizaciju

• YouTube kanali -- Razni kreatori prave detaljne video tutorijale o UE5 profiling-u. Posebno preporucujem pretraziti "UE5 profiling workflow" i "Unreal Insights tutorial"

Vendor-specificni alati (vise u Poglavlju 41)

• NVIDIA Nsight Graphics -- Za detaljan GPU profiling na NVIDIA karticama
• AMD Radeon GPU Profiler (RGP) -- Za detaljan GPU profiling na AMD karticama
• Intel Graphics Performance Analyzers (GPA) -- Za Intel GPU profiling
• PIX -- Microsoft-ov GPU debugger za DirectX 12
• RenderDoc -- Open-source GPU debugger (cross-platform)

Ovi eksterni alati su pokriveni u Poglavlju 41, gde cemo videti kako se koriste u kombinaciji sa UE5 internim alatima.

Veza sa Drugim Poglavljima

• Poglavlje 39 (Optimizaciona filozofija) -- Razumevanje zasto i kada optimizovati, pre nego sto krenes da koristis alate iz ovog poglavlja
• Poglavlje 41 (Eksterni profiling alati) -- Vendor-specificni GPU alati (Nsight, RGP, PIX, RenderDoc) koji pruzaju dublje informacije od UE5 internih alata

Rezime

U ovom poglavlju smo prosli kroz ceo arsenal profiling alata u UE5:

1. stat unit je tvoja prva i najvaznija komanda -- govori ti koji thread je bottleneck
2. stat gpu razbija GPU vreme po render pass-ovima
3. stat scenerendering ti govori koliko posla saljes GPU-u (draw calls, triangles)
4. stat memory i memreport ti pomazu da razumes memorijsku upotrebu
5. Unreal Insights je najmoćniji alat za duboku analizu -- snima sve, pokazuje sve
6. GPU Visualizer daje vizuelni waterfall chart GPU rendering-a
7. Frame Profiler pruza per-frame analizu sa hijerarhijom funkcija
8. Vizualizacioni modovi ti omogucavaju da vidis probleme na ekranu
9. Konzolne komande (show, r.ScreenPercentage, FreezeRendering) su alati za sistematsku dijagnostiku
10. Prakticni workflow povezuje sve ove alate u koherentan proces

Kljucna poruka ovog poglavlja: profiling nije tajna vestina -- to je sistematski proces. Kreni od stat unit, identifikuj bottleneck, koristi specijalizovane alate da ga suzis, optimizuj, izmeri ponovo. Ponavljaj dok ne postignes cilj.

U sledecem poglavlju (Poglavlje 41) cemo pogledati kako eksterni alati (Nsight, RGP, PIX, RenderDoc) dopunjuju UE5 interne alate i pruzaju jos dublji uvid u performanse tvoje igre.

Srećno profilisanje!