CPU ve GPU darboğazı (bottleneck)

Her karede motor; sahneyi günceller, komutları üretir ve GPU’ya iletir. Bu zincirin herhangi bir adımı yavaşladığında, kare süresi (frame time) uzar ve FPS düşer.

Pratik kural: «Nerede vakit harcanıyor?» sorusunu cevaplamadan «poligon kırp» veya «doku sıkıştır» demek, çoğu zaman yanlış sıraya optimizasyon yapmak demektir.

İşlemci, sahnenin «beyni»dir: animasyonu ilerletir, sahne ağacını dolaşır, görünürlük / seçim mantığını çalıştırır ve GPU’ya iletilecek çizim komutlarını üretir. FPS sorununuz CPU kaynaklıysa, yalnızca poligonları azaltmak çoğu zaman hiçbir işe yaramaz — çünkü tavan genelde «kaç üçgen var?» değil, «kare başına CPU kaç ms harcıyor?» sorusudur.

Aşağıdaki belirtiler, §4 tablosundaki «çözünürlük testi» ile aynı yönde okunur; fark şudur: burada neden ve hangi iş yükü tipi olduğunu netleştiriyoruz.

Belirtiler

• Kamera sabitken bile düşük FPS: Görüntüleme yükünü değiştirmeden kare süresi uzuyorsa, iş çoğu zaman hâlâ CPU tarafında (mantık, komut üretimi, sahne güncellemesi) demektir.
• Çözünürlük düşürünce belirgin iyileşme yok: 1080p → 480p gibi adımlar piksel sayısını azaltır; GPU bağlı bir tavanda genelde fark edilir. Fark yoksa, darboğaz büyük olasılıkla CPU veya GPU’dan bağımsız bir «sabit maliyet» (ör. ağır betik, aşırı GC, senkron ağ) da olabilir — yine de ilk adım CPU profilidir.

Olası nedenler

• Aşırı draw call: Her çağrı; durum değişimi, kayıt hazırlığı ve sürücüye iletim maliyeti taşır. GPU hızlı olsa bile «komut üretmek» CPU’da tıkanır. Pratik çözüm yönü: materyal / çağrı disiplini, birleştirme, instancing, gereksiz materyal çeşitliliğini azaltmak.
• Karmaşık sahne grafiği: Çok derin parent–child hiyerarşilerinde her karede dünya matrislerinin yayılması (matrix propagation) pahalıdır. Özellikle dinamik objeler çoğaldıkça, «görünmeyen» dallarda bile güncelleme yapılıyorsa maliyet büyür.
• Fizik ve mantık: Çarpışma çiftleri, sürekli raycast, ağır AI karar ağaçları veya tek iş parçacığında bloklayan işler kare süresini uzatır; grafik ayarından bağımsız görünür.
• Traversing (ağacı tarama): Her karede tüm sahneyi koşulsuz gezmek, culling / dirty bayrakları olmadan yapılırsa CPU’da sabit bir vergi oluşturur. Hedef: «değişmeyen dalı yeniden işleme» disiplinidir.

Ekran kartı, sahnenin «işçisi»dir: CPU’nun verdiği çalışmayı piksel piksel üretir. Sorun GPU kaynaklıysa, kod kalitesi yükselse bile donanımın doldurma ve hesap hızı tavanına çarparsınız; yani «daha iyi yazdım» ile «daha hızlı boyadı» aynı şey değildir.

Bu bölümdeki belirtiler, §4 tablosunda özellikle «çözünürlük / sahne yoğunluğu» satırlarıyla örtüşür; burada amaç, GPU tarafında hangi alt tür (vertex vs fragment vs bellek) ihtimalinin öne çıktığını ayırmaktır.

Belirtiler

• Çözünürlük düşünce FPS sıçraması: Piksel sayısı azalınca yükün ciddi şekilde düşmesi, fill rate ve/veya piksel başına shader maliyeti ihtimalini güçlendirir.
• Sahne içeriğine duyarlı dalgalanma: Boş alana bakınca raharlama, yoğun geometri + ağır materyal + doku kombinasyonuna dönünce tekrar sıkışma genelde GPU’nun «ne kadar şey boyuyorum?» sorusuna bağlıdır (bazen saf geometri, bazen piksel ağırlığı).

Olası nedenler

• Yüksek poligon (vertex bound): Çok fazla üçgen; vertex shader ve vertex verisi taşıma maliyeti. Zemin okuma: geometri karmaşıklığı ve LOD stratejileri.
• Ağır shader (fragment bound): Işık sayısı, gölge haritaları, PBR zinciri veya pahalı efektler; piksel başına matematik patlar. Zemin: materyal optimizasyonu.
• Büyük / çok sayıda doku: VRAM baskısı, anizotropik örnekleme, filtreleme ve bant genişliği. «Diskte küçük» olup «GPU’da geniş» olabilen durumlar da vardır — doku stratejisini ayrı ele alın.
• Overdraw: Aynı pikselin üst üste defalarca boyanması; poligondan bağımsız olarak fill rate tüketir. Şeffaf katmanlar ve partiküller tipik tetikleyicidir.

HoloDepth projelerinde sorunu bulmak için aşağıdaki hızlı testleri uygulayın. Sonuçlar kesin profil değildir; ama «önce hangi tarafı ölçelim?» sorusunda yön verir.

Birçok geliştirici sahne kasıldığında hemen «poligonları azaltalım» der. Oysa sahnede örneğin 2.000 adet düşük poligonlu (ör. 10 tris) küp varsa, sorun çoğu zaman poligon değil, 2.000 ayrı draw call yüküdür. Bu durumda poligon azaltmak neredeyse hiçbir şeyi değiştirmez; çözüm instancing, birleştirilmiş geometri veya batching ile çizim kimliği sayısını düşürmektir.

Poligon bütçesi için zemin: Geometri karmaşıklığı sayfası.