Three.js · Profiling · Fizik ve donanım
CPU ve GPU: görev dağılımı ve iş yükü
Fizik entegre bir uygulamada iki farklı orkestra çalar: biri sıralı karar ve çözüm (CPU), diğeri paralel piksel ve köşe işi (GPU). Biri diğerinden belirgin şekilde geri kalırsa, kare süresi yavaş olan tarafa mahkûm olursunuz — fakat «hangi taraf?» sorusunu tahminle değil, ölçümle yanıtlamak gerekir.
Genel kare bütçesi, çözünürlük testi ve frame time split görselleştirmesi CPU / GPU darboğazı sayfasında ayrıntılı anlatılır; burada aynı fikri fizik simülasyonu bağlamında yeniden düzenliyoruz — formülleri kopyalamak yerine, motorun hangi aşamasının hangi işlemcide yaşadığını sabitliyoruz.
Roller: karar verici ve uygulayıcı
CPU — merkezî karar
Fizik motorunun «kalbi» çoğu web yığınında hâlâ CPUdadır: temas adaylarının süzülmesi, kısıtların çözülmesi, ivme entegrasyonu ve uyku politikası gibi adımlar birbirine bağlıdır. A nesnesi B'ye çarptığında B'nin C'yi itmesi gibi sıralı hikâyeler, dallanması bol komut akışına uygundur.
GPU'ya giden yol da buradan geçer: hangi mesh'in hangi materyalle çizileceğini belirleyen komut zinciri (draw calls ve durum değişimleri) CPU üzerinde hazırlanır. Fizik ağırken, bu hazırlık bile gecikebilir; oyuncu bunu «düşük FPS» olarak okur ama kök neden çizimden önce gelebilir.
GPU — görsel ve paralel
Gölgeleme, ışık hesapları ve post-processing piksel başına paralel yürür; ekran çözünürlüğü arttıkça bu bant şişer. Fizik tarafı CPU'da kalsa da, bazı motorlar ağır doğrusal cebir paketlerini compute benzeri yollarla GPU'ya itebilir — bu, altyapı ve sürüm sözleşmesine bağlı bir istisnadır, varsayılan beklenti değildir.
Darboğazı fizik gözlüğüyle okumak
Aşağıdaki belirtiler, darboğaz sayfasındaki tabloyla aynı yönde okunur; fakat burada vurgu «çözünürlük düşürdüm, ne oldu?» yerine «fizik adımı, çarpışma şekli veya aktif gövde sayısı değişince ne oldu?» sorusudur.
CPU baskınlığı
Çok sayıda dinamik gövde, ağır trimesh temasları veya sıkı temaslı küme patlamaları CPU süresini uzatır. Grafik kalitesini düşürmek FPS'i iyileştirmiyorsa, şüphe çoğu zaman CPU tarafındadır — özellikle fizik adımı bütçesini Fizik ve FPS sayfasındaki gibi ölçtüğünüzde netleşir.
GPU baskınlığı
Ağır gölgeler, geniş post-processing zinciri veya yüksek çözünürlüklü dolgu doku setleri GPU'yu doyurur. Çözünürlük düşürünce FPS sıçraması görüyorsanız, kare süresinin görüntüleme bandında tıkandığına işaret eder — fakat fizik hâlâ CPU'yu meşgul ediyorsa iyileşme «tavanlı» kalabilir; bu yüzden iki ölçümü birlikte taşıyın.
Holodepth denge stratejileri
Instancing (GPU tarafı)
Binlerce benzer parçacık veya enkaz parçası görsel olarak ayrı draw call ile çizilirse CPU komut üretiminde boğulursunuz. Instancing, aynı geometriyi tek komutla binlerce örnekle çoğaltır; fizik hâlâ her gövde için ayrı hesaplanabilirken, görüntüleme maliyeti dramatik biçimde düşer. Görsel yoğunluk ile fizik gövdesi sayısını karıştırmamak gerekir.
Sade collider (CPU tarafı)
Görsel model ne kadar detaylı olursa olsun, simülasyonda basit prizmalar kullanmak dar faz maliyetini düşürür; şekil ailesi için Çarpışma şekilleri, gerekçe için Her yüzeye tam fizik mi? başlıklarına bakın. Amaç tek bir yüzde rakamı değil, ölçülebilir adım süresi kazanmaktır.
Asenkron fizik (Worker)
Fizik dünyasını ana iş parçacığından ayırmak, UI ve giriş gecikmesini azaltır; dünya durumunu kopyalama ve senkron sınırı ise ayrı bir faturadır. Uygulama deseni için Fizik ve FPS · Web Worker bölümüyle hizalanın.
Holodepth teknik notu
Darboğaz avında önce frame time'ı bölün; sonra fizik adımını ayrı sayaçla ölçün. Aksi halde GPU'yu güzelleştirirken CPU'da gizlenen fizik borcunu taşımaya devam edersiniz.