@endofGodot'nun render ekibinden profiler ile darboğaz avı: 35 ms'den 13 ms'ye inen kare süresi
Godot'nun render tarafını yürüten Clay John, 15 Eylül'de motorun CPU tarafındaki iki optimizasyonu adım adım anlattığı bir yazı yayınladı. Godot kullanmasanız bile okumaya değer, çünkü asıl anlattığı şey bir yöntem: darboğazı bul, neden orada olduğunu anla, çözüm dene, tekrar ölç, başa dön.
İlk örnek animasyonlu Polygon2D. Köşe noktaları her karede değişen bir poligonda motor her karede mesh'i silip baştan oluşturuyormuş. Düzeltme basit: köşe sayısı değişmiyorsa mevcut mesh'in verisini yerinde güncelle. Sonuç kare süresinde 35 ms'den 13 ms'ye düşüş, yazarın test sahnesinde 28 FPS'ten 83 FPS'e çıkış. İkinci örnek Windows'ta SPIR-V'den DXIL'e shader çevirisi. İş parçacıkları işletim sisteminden bellek isterken tek bir ortak heap'i bekliyormuş; her iş parçacığına kendi heap'i verilince TPS demosunun yüklenme süresinden 11 saniye gitmiş.
Kullanılan araçlar da ilginç: harici örnekleme profiler'ı olarak Superluminal, yanında Godot'nun kendi GDScript ve render profiler'ları, istenirse Tracy. Zaman çizelgesinde iş parçacıklarının boşta beklediği kırmızı bölgeler, çağrı grafiğinde pahalı fonksiyonlar. Ben otomasyon işlerinde backend servislerini aynı mantıkla inceliyorum, oyun motorunda da tablonun aynı olduğunu görmek bir yerde rahatlatıcı.
En çok aklımda kalan kısım sezginin çoğu zaman yanıldığı tespiti. Araya eklenen bir if vektörizasyonu engelleyebiliyor, önbellek eklemek bellek okumasının darboğaz olduğu yerde işi yavaşlatabiliyor. Ölçmeden yapılan optimizasyon tahminden ibaret. Bir de motor ekibinin ciddi bir performans sorununu çoğu zaman ancak biri hata bildirdiğinde öğrendiğini yazması dikkat çekici. Oyununuzda açıklayamadığınız bir yavaşlık varsa küçük bir örnek proje hazırlayıp bildirmek hem size hem herkese yarıyor.
İlk örnek animasyonlu Polygon2D. Köşe noktaları her karede değişen bir poligonda motor her karede mesh'i silip baştan oluşturuyormuş. Düzeltme basit: köşe sayısı değişmiyorsa mevcut mesh'in verisini yerinde güncelle. Sonuç kare süresinde 35 ms'den 13 ms'ye düşüş, yazarın test sahnesinde 28 FPS'ten 83 FPS'e çıkış. İkinci örnek Windows'ta SPIR-V'den DXIL'e shader çevirisi. İş parçacıkları işletim sisteminden bellek isterken tek bir ortak heap'i bekliyormuş; her iş parçacığına kendi heap'i verilince TPS demosunun yüklenme süresinden 11 saniye gitmiş.
Kullanılan araçlar da ilginç: harici örnekleme profiler'ı olarak Superluminal, yanında Godot'nun kendi GDScript ve render profiler'ları, istenirse Tracy. Zaman çizelgesinde iş parçacıklarının boşta beklediği kırmızı bölgeler, çağrı grafiğinde pahalı fonksiyonlar. Ben otomasyon işlerinde backend servislerini aynı mantıkla inceliyorum, oyun motorunda da tablonun aynı olduğunu görmek bir yerde rahatlatıcı.
En çok aklımda kalan kısım sezginin çoğu zaman yanıldığı tespiti. Araya eklenen bir if vektörizasyonu engelleyebiliyor, önbellek eklemek bellek okumasının darboğaz olduğu yerde işi yavaşlatabiliyor. Ölçmeden yapılan optimizasyon tahminden ibaret. Bir de motor ekibinin ciddi bir performans sorununu çoğu zaman ancak biri hata bildirdiğinde öğrendiğini yazması dikkat çekici. Oyununuzda açıklayamadığınız bir yavaşlık varsa küçük bir örnek proje hazırlayıp bildirmek hem size hem herkese yarıyor.
5 2 yorum
