UNREAL ENGINE İLE PERFORMANS PROFILING YAPMAK VE BOTTLENECK BULMAK

Performans profiling, Unreal Engine’de FPS düşüşünün gerçek nedenini ölçerek bulma sürecidir; bu yazıda hedef ve ölçüt kurmayı, CPU/GPU sınırını ayırt etmeyi, Unreal Insights izlerini okumayı, GPU profiler ile render geçişlerini ayrıştırmayı ve hitch kaynaklarını gidermeyi öğreneceksin — çünkü ayardan başlayan ekip çoğu zaman yanlış yeri iyileştirir; GPU sınırlı bir sahnede draw call azaltmak ya da CPU sınırlı bir sahnede gölge düşürmek kazanç getirmez, profiling ise emeği en yüksek getirili noktaya yönlendirir.

1. Profiling hedeflerini belirlemek ve ölçüt kurmak

Sağlıklı bir profiling süreci için ilk adım, ölçmek istediğiniz senaryoyu netleştirmektir. “Menüde FPS düşük” gibi genel bir tanım yerine, hangi harita, hangi kamera açısı, hangi karakter sayısı, hangi efekt yoğunluğu ve hangi cihaz hedeflendiğini yazılı hale getirmek gerekir. Aksi halde farklı koşullarda alınan ölçümler birbirini tutmaz. Konuya daha sistemli hakim olmak isteyen ekipler Unreal Engine eğitim içeriği ile bu akışları tamamlayabilir.

Frame time ve 1% low metriklerine odaklanmak

Burada iki temel metrik vardır: frame time (ms) ve bunun türevi olan FPS. FPS tek başına yanıltıcı olabilir; çünkü 60 FPS ile 16.6 ms, 30 FPS ile 33.3 ms gibi frame time karşılıkları, darboğazı bulmada daha doğrudan ipucu verir. Ayrıca “ortalama FPS” yerine, anlık takılmaları yakalamak için 1% low ve spike davranışına odaklanmak daha değerlidir.

Tekrarlanabilir test senaryosu kurmak ve kilitlemek

Profiling yapılacak koşulları sabitlemek için VSync, dinamik çözünürlük, ölçekleyiciler ve arka plan yükleri kontrol edilmelidir. Aynı rotayı takip eden bir kamera path’i, sabit bir spawn sayısı ve belirli bir süre (ör. 60 saniye) ölçüm almak, sonuçları kıyaslamayı kolaylaştırır. Ayrıca Editor yerine mümkünse packaged build üzerinden ölçüm almak, Editor overhead’ini elimine eder.

Frame time bütçesini hedef platforma göre yazmak

Hedef 60 FPS ise toplam bütçeniz yaklaşık 16.6 ms’dir; bunun CPU ve GPU arasında nasıl paylaşıldığı ise projeye göre değişir. Örneğin GPU ağır bir görsellik hedefliyorsanız GPU tarafında daha fazla bütçe, CPU ağırlıklı simülasyon varsa CPU tarafında daha fazla bütçe planlamak gerekir. Bu bütçe, sonraki adımlarda “hangi işi kısaltmalıyım” kararını hızlandırır.

2. CPU ve GPU sınırını ayırt etmek ve doğrulamak

“CPU bound” ve “GPU bound” ayrımı, optimizasyon önceliğini belirler. CPU sınırlıysanız draw call hazırlığı, oyun mantığı, blueprint, AI, fizik, animasyon güncellemeleri gibi işler öne çıkar. GPU sınırlıysanız shader maliyeti, overdraw, ışıklandırma, post-process ve gölge geçişleri gibi işler baskın olur.

Çözünürlük testiyle ilk işaretçiyi almak

İlk teşhis için hızlı bir yöntem, çözünürlüğü düşürüp yükseltmek ve frame time değişimine bakmaktır. Çözünürlük düşerken frame time belirgin iyileşiyorsa GPU tarafı güçlü adaydır. İyileşme yoksa CPU tarafında sınırlanıyor olabilirsiniz. Bu bir “kesin hüküm” değil, sadece hızlı bir işaretçidir; doğrulama için profiler verileri gerekir.

Stat komutlarıyla ilk teşhisi almak ve notlamak

Unreal’ın stat komutları, sahne içindeyken anlık olarak temel metrikleri görmenizi sağlar. Aşağıdaki komutlar, hızlı bir kontrol turu için iyi bir başlangıçtır:

stat unit
stat unitgraph
stat fps
stat gpu
r.VSync 0
t.MaxFPS 0

stat unit ile Game, Draw, GPU sürelerini ms cinsinden izleyin. GPU süresi en yüksek ve sabitse GPU sınırlaması olasıdır. Game/Draw süreleri yükseliyorsa CPU işi büyüyor demektir. Unitgraph ile spike anlarını yakalayıp hangi tarafta zıpladığını görmek ayrıca faydalıdır.

Çözünürlük ve ölçek testini kontrollü yapmak ve yorumlamak

Çözünürlük ölçeğini değiştirirken aynı sahne akışını korumak önemlidir. Örneğin ScreenPercentage ile 100’den 70’e inip sonra 120’ye çıkmak, GPU yükünü hızla değiştirir. Eğer GPU bound iseniz değişim net görünür; CPU bound iseniz daha sınırlı etkiler görürsünüz. Bu testi tek başına yeterli saymayın; Insights ve GPU profiler ile doğrulayın.

3. Unreal Insights izlerini yakalamak ve okumak

Unreal Insights, CPU iş parçacıkları, task graph, asset yükleri, async işler, hitch anları ve event sürelerini okumak için güçlü bir araçtır. Özellikle “arada bir takılıyor” gibi şikayetlerde, spike anına denk gelen event’i bulmak, rastgele optimizasyon denemelerinden çok daha hızlı sonuç verir.

Az kanalla başlayıp kısa pencerede toplamak

İz toplama sırasında gereksiz kanalları açmak dosyayı şişirebilir; az kanalla başlayıp ihtiyaç oldukça genişletmek iyi bir pratiktir. Ayrıca ölçüm süresi çok uzun olursa, analiz zorlaşır. Bu yüzden hedef senaryoyu kısa ama temsil edici bir pencereye sığdırmak idealdir.

Trace oturumunu başlatmak ve doğru kanalı seçmek

İz toplama yaklaşımı projeye göre değişir; ancak CPU event’leri, loading ve frame hitches genellikle ilk bakılan yerlerdir. Aşağıdaki örnek, iz toplama sürecini otomasyonlaştırmak için pratik bir başlangıç örneğidir:

Trace.Start cpu,frame,loading
stat startfile
// Senaryoyu 30-60 saniye çalıştır
stat stopfile
Trace.Stop

Bu akış, hem anlık stat ölçümlerini hem de iz verisini daha sistemli toplamanıza yardımcı olur. Editor içi testte farklı overhead’ler olabileceğini unutmayın; mümkünse build üzerinde de aynı akışı uygulayın.

Game thread ve render thread ilişkisini çözmek ve ayıklamak

Insights içinde Game Thread ve Render Thread sürelerini karşılaştırın. Game Thread’de blueprint tick’leri, AI kararları veya fizik update’leri baskın olabilir. Render Thread’de draw call hazırlığı ve render komutlarının kuyruğu büyüyebilir. Darboğazı “tek bir fonksiyon” gibi aramak yerine, zincir etkisini izlemek daha doğru olur: örneğin blueprint tarafındaki gereksiz component güncellemeleri, Render Thread’i de dolaylı olarak şişirebilir.

4. GPU profiler ile render geçişlerini ayrıştırmak ve azaltmak

GPU tarafında sorun varsa, “hangi pass pahalı” sorusu öne çıkar. Gölge pass’leri, translucency, post-process zinciri, SSAO, Lumen, Nanite yoğunluğu ve shader karmaşıklığı GPU süresini yükseltebilir. GPU profiler kullanarak hangi geçişin süreyi yediğini görmek, optimizasyonu hedefe kilitler.

ProfileGPU çıktısını okumak ve geçişe odaklanmak

GPU profiler çıktısında en üstte toplam GPU süresi, altında ise pass bazında kırılım görürsünüz. Eğer ShadowDepths veya Translucency gibi bir başlık öne çıkıyorsa, önce o alanda hızlı kazanç sağlayacak ayarlara yönelin. Örneğin gölge çözünürlüğünü ve distance ayarlarını düşürmek, çok sayıda küçük ışığı sınırlamak veya translucency kullanılan materyalleri sadeleştirmek hızlı etkiler yaratabilir.

Shader karmaşıklığını kontrol etmek ve materyali sadeleştirmek

Materyal tarafında dallanma (branch), pahalı node’lar ve aşırı texture sample sayısı, özellikle mobil ve zayıf GPU’larda ciddi yük getirir. Shader complexity görünümleri ile yoğun bölgeleri işaretleyin. Sonra materyal instance’larında parametreleri düzleştirmek, gereksiz normal detaylarını azaltmak ve tek pass’e indirgemek gibi adımlarla ilerleyin. Burada amaç “her şeyi düşürmek” değil; oyuncunun fark edeceği alanlara bütçe ayırıp arka plandaki maliyeti kısmaktır.

5. Hitch ve stutter kaynaklarını yakalamak ve gidermek

FPS ortalaması iyi olsa bile, tekil hitch’ler kullanıcı deneyimini bozar. Hitch kaynakları sıklıkla asset streaming, shader compilation, garbage collection, disk erişimi veya ani spawn patlamalarıdır. Insights bu anları işaretleyip “hangi anda ne oldu” sorusuna yanıt verir.

Asset streaming baskısını ölçmek ve önbelleklemek

Streaming yoğunluğu yüksek sahnelerde, texture ve mesh yükleri frame ortasına sızabilir. Çözüm olarak streaming pool ayarlarını hedef platforma göre planlamak, kritik asset’leri önceden yüklemek ve level streaming geçişlerini daha kontrollü yapmak gerekir. Özellikle hızlı kamera hareketi olan sahnelerde, mip bias ve LOD stratejisi ile bant genişliğini yönetmek büyük fark yaratır.

Garbage collection davranışını izlemek ve bölmek

GC kaynaklı hitch’ler genellikle belirli aralıklarla gelen büyük spike’lar şeklinde görünür. Object yaşam döngülerini daha kontrollü yönetmek, sık yarat-yok et yapılan nesneleri havuzlamak ve gereksiz referans zincirlerini azaltmak etkili olur. Ayrıca GC ayarları projeye göre düzenlenebilir; fakat bu tür değişiklikleri mutlaka ölçümle doğrulayın.

6. Bottleneck doğrulamak için kontrol listesi oluşturmak

Darboğaz bulmanın en büyük tuzağı, tek bir grafiğe bakıp erken karar vermektir. Sağlam bir yaklaşım, veriyi çapraz doğrulamaktır: stat komutları, Insights izleri, GPU profiler ve sahne koşullarının tutarlılığı birlikte okunmalıdır. Aşağıdaki kontrol listesi, karar hızını artırır:

• Test senaryosu sabit mi, build ve cihaz bilgisi kayıtlı mı?
• Frame time değerleri (Game/Draw/GPU) kaç ms ve spike nerede?
• Çözünürlük ölçeği değişince toplam süre hangi yönde değişiyor?
• Insights’ta en pahalı event’ler ve thread blokajları neler?
• GPU profiler’da en pahalı pass hangisi ve neden pahalı?

Bu listeyle ilerlemek, “bottleneck” dediğiniz şeyin gerçekten darboğaz olduğundan emin olmanızı sağlar. Sonraki adım, çözümü küçük parçalar halinde uygulamak ve her değişiklikten sonra yeniden ölçmektir. Böylece hangi optimizasyonun işe yaradığını kanıtlayarak ilerlersiniz.

Optimizasyon değişimini küçük tutmak ve A/B ölçmek

Aynı anda çok fazla ayar değiştirmek, hangi değişikliğin işe yaradığını belirsizleştirir. Bir değişiklik yapın, aynı senaryoda ölçün, not alın. Eğer iyileşme varsa, bir sonraki adıma geçin; yoksa geri alın ve farklı bir hipotez deneyin. Bu yaklaşım, ekip içinde iletişimi de kolaylaştırır; çünkü kararlar veriye dayanır.

7. Ekip içinde performans kültürü kurmak ve sürdürülebilirleştirmek

Performans, tek seferlik bir “son hafta” işi olmaktan çıkıp üretim sürecine yayılınca daha ucuz ve daha güvenli yönetilir. Kod tarafında ölçüm noktaları eklemek, içerik üretiminde LOD ve ışıklandırma standartları belirlemek ve düzenli profiling seansları yapmak, sürprizleri azaltır.

Profiling raporlarını ortak dilde paylaşmak ve takip etmek

Insights ekran görüntüleri, ms bazlı hedefler, pass kırılımları ve spike örnekleri ekip için ortak bir dil oluşturur. Bir görev açarken “FPS düşük” yerine “Render Thread 9 ms’den 15 ms’ye çıkıyor, sebep draw call artışı” gibi net bir tanım, çözüm süresini kısaltır. Düzenli raporlama, ilerlemeyi görünür kılar ve optimizasyonun değerini somutlaştırır.

Özetle, Unreal Engine’de performans profiling yapmak; doğru senaryoyu sabitlemek, CPU/GPU sınırını ayırt etmek, Insights ve GPU profiler ile veriyi okumak ve değişiklikleri küçük adımlarla doğrulamak demektir. Bu disiplin oturduğunda, darboğaz bulmak “şansa” değil, ölçüme bağlı bir sürece dönüşür.