Aracılığıyla paylaş

Windows Başlıkları için En Önemli Sorunlar

Microsoft Windows Oyun ve Grafik Teknolojileri Geliştirici İlişkileri grubu, her yıl birçok Windows oyunu için performans analizi gerçekleştirir. Bu oturumlar sırasında, her gün aldığımız geliştirici geri bildirimlerine ve sorgularına bağlanmak için uygulamalı deneyim elde ederiz. Bazen, geliştiricilerin karşılaştığı sorunlarla ilgili daha fazla içgörü sağlayan bir başlıktaki gizemli kilitlenmeyi veya başka bir sorunu izlemeye yardımcı oluruz.

Bu makalede, mevcut nesil bilgisayar oyunlarında gördüğümüz yaygın sorunların birçoğu vurgulanır.

CPU-Limited Performansı

Oyunların büyük çoğunluğu, yüksek performanslı grafik işleme birimlerine (GPU) sahip sistemlerde CPU performansıyla sınırlıdır. Bunun nedeni bazen çizim gönderimleri için toplu iş kullanımının kötü olmasıdır, ancak daha genel olarak bunun nedeni diğer oyun sistemlerinin kullanılabilir CPU döngülerinin büyük bir kısmını kullanmasıdır. Gpu'yu sınırlama olarak gördüğümüz birkaç durumda, bunun nedeni çok yüksek doldurma hızları veya piksel gölgelendirici talebi, yüksek çözünürlüklü ayarlarda veya bir ekran kartı tarafından düşük köşe gölgelendirici performansıdır.

Çoğu oyun CPU sınırlı olduğundan, en büyük performans kazançları YOĞUN CPU kullanan oyun sistemlerini iyileştirmekten gelir. Genellikle yapay zeka veya fizik sistemleri ve ilişkili çarpışma algılama mantığı, düzgün davranan Microsoft Direct3D uygulamalarında CPU döngülerinin birincil tüketicileridir. Bu sistemleri geliştirmeye yönelik herhangi bir çalışma, oyunun genel performansını artırabilir.

Kötü Toplu İş Yönetimi

GPU ile iyi paralellik elde etmek için çizim toplu işlemlerinin yeterli geometri içermesi ve gölgelendiricilerin doğru karmaşıklığa sahip olması gerekir. Bu arada komut arabelleği taşan çok fazla toplu işlem kullanmaz. Geçerli nesil donanımlarda, sürücünün komut arabelleği işlemesinin performans sorunu haline gelmesini önlemek için çerçeve başına yaklaşık 300 veya daha az çizim toplu işlemi göndermesini (düşük performanslı CPU'larda daha az) öneririz. Diğer bazı API durum çağrıları ve sürücü birleşimleri, yüksek maliyetli CPU işlemeye (örneğin gölgelendiricilerin sürücü derlemesine) neden olabilir, bu nedenle rutin performans analizini kesinlikle öneririz.

Aşırı Bellek Kopyalama

Çoğu bilgisayar başlığının geliştirilmesi sırasında geliştiriciler içerik yönetimi için uygun veri yapılarını ve dizelerini kullanır. Dize karşılaştırması, kopyalama ve diğer işlemeler için gereken CPU çalışması genellikle, özellikle önbellek ve bellek alt sistemiyle ilişkili performans isabetleri dikkate alınırken ölçülebilir bir yüke sahiptir. Ürün birincil test ve sürüm aşamalarına girdikten sonra dize işlemeye olan dayanıklılığı kaldırmak veya en aza indirmek için bu sistemleri geliştirirken planlar yapılmalıdır.

Dinamik Çizim Gönderiminin Aşırı Kullanımı

Modern video donanımı, statik verilerle çalışırken iyi performans gösterir. Üst düzey bağdaştırıcılar genellikle çok büyük miktarda video belleğine sahiptir, ancak bu bellek dinamik veriler tarafından etkili bir şekilde kullanılamaz.

Dinamik içerik için dinamik köşe arabelleklerinin/dizin arabelleklerinin makul düzeyde verimli kullanım desenleri uygulanabilir ancak birçok başlıkta bu deyim, diğer statik içerik için aşırı kullanılır. Bunu genellikle ikili alan bölümleme (BSP) ağaçlarında ve geometriyi donanımla eşlenmemiş bir veri yapısında depolayan ve her çerçeve için arabellekler halinde işlenmesi gereken portal tabanlı sistemlerde görürüz. Statik kaynaklara mümkün olduğunca çok içerik eklemek, verileri ekran kartına aktarmanın bant genişliği ek yükünü büyük ölçüde azaltabilir, yerleşik VRAM'den daha iyi yararlanabilir ve bu içeriğin işlenmesinde kullanılan CPU/önbellek ek yükünü azaltabilir.

Dosya İşlemede Yüksek Ek Yük

Bilgisayar oyunları, özellikle katı yükleme süresi gereksinimleri olan konsol başlıklarıyla karşılaştırıldığında uzun yükleme süreleri ile ün kazandı. Birçok başlığın dosya alt sisteminden nasıl yararlandığını çözümlememiz bazı yaygın sorunları ortaya koyuyor.

Dosya açma yükü genellikle geliştiricilerin beklediğinden çok daha yüksektir. İsteğe bağlı virüs tarayıcılarının yaygın kullanımda olması ve NTFS'nin ek işlevselliği sayesinde dosya açmak oldukça pahalı bir işlemdir. Aynı anda birçok dosya açmak veya aynı dosyayı tekrar tekrar açıp kapatmak, bu nedenle dosya yönetimiyle ilgilenmek için kötü bir yöntemdir. Bazı oyunlar, dosyayı açmadan önce var olup olmadığını test ederek bu performans maliyetini azaltmaya çalıştı. Gerçek şu ki, NTFS'de bir dosyanın var olup olmadığını sınamak için dosyanın açılması gerekir, bu nedenle açmadan önce test yapılması maliyetin iki kez ödenmesiyle sonuçlanır.

Eklenti değişikliklerine veya modlara izin veren ya da geçersiz kılma veri dosyalarını denetlemek için geliştirme iskelesi içeren oyunlar, bu dosyalar mevcut olmasa bile bu dosyaların denetlenmesi nedeniyle oyunun yüklenmesinde önemli gecikmeler olabilir. Oyunların yalnızca özel bir komut satırı anahtarı veya başka bir mod göstergesiyle çalıştırıldığında bu dosyaları denetlemesini öneririz, böylece yalnızca bu işlevi kullanan kullanıcılar bu (genellikle kapsamlı) denetimlerin performans maliyetini gerçekten öder.

Dosya sisteminden aşağıdakiler tarafından ek performans elde edilebilir:

  • FILE_FLAG_RANDOM_ACCESS ve FILE_FLAG_SEQUENTIAL_SCAN dosya sistemi ipuçlarının uygun kullanımı
  • İşletim sisteminin okuma/yazma API'lerine büyük miktarda çağrı yapmaktan kaçınmak için boyutlandırma arabellekleri
  • Dosyalara zaman uyumsuz olarak erişme
  • İş parçacıklarını arka planda yükleme

Ayrıca, her kullanıcı için önemli bir performans vergisi getirdiğinden, oyun ilk çalıştırıldığında dönüştürmeye güvenmek yerine verileri çevrimdışı (derleme veya yükleme zamanında) dönüştürmenizi kesinlikle öneririz.

Yavaş ve Sinir Bozucu Yükleme

Gördüğümüz bir diğer yaygın sorun, birçok modern bilgisayar oyunu için gereken çok uzun yükleme süreleridir. Yükleyiciler, bazen kullanıcıya "DirectX'in yüklenmesine gerek yok" gibi bir şey söylemek için kullanıcıya birçok kez soru sorar. Genel olarak, bu rahatsız edici yükleyiciler, oyunun kurulumu başlamadan önce kullanıcının Sonraki'ı seçmesini veya tamam birçok kez seçmesini gerektirir. Başladıktan sonra, kullanıcı oyunu oynama fırsatına sahip olmadan önce bazı başlıkların bir saat veya daha uzun sürdüğünü gördük. Oyun oynama deneyiminin ilk saatinin kurulum olmaması gerektiğini kesinlikle hissediyoruz.

Yüklemeyle ilgilenmek için bir dizi yaklaşım öneririz. İlk olarak, istemleri basit ve en düşük düzeyde tutun. İkinci olarak, oyun verilerinizin mimarisini, veri dosyalarının bir kısmının veya tümünün mümkün olduğunca doğrudan dağıtım diskinden kullanılabilmesini sağlayın; modern DVD sürücüleri çok yüksek bant genişliğine sahiptir. Üçüncüsü, yükleme işlemini azaltmak veya ortadan kaldırmak ve kullanıcıların oyuna mümkün olan en kısa sürede girmelerini sağlamak için başlıklarınıza isteğe bağlı yükleme uygulamayı göz önünde bulundurun. (İsteğe bağlı yükleme hakkında daha fazla bilgi için bkz. Gamesiçin İsteğe Bağlı Yükleme.)

Oyun yükleme hakkında daha fazla öneri için bkz. Oyun Yüklemesini Basitleştirme.

Fiziksel Belleğin Dikkate Alınmaması

Piyasadaki bilgisayar donanımının geniş değişkenliği nedeniyle, başlıklar genellikle grafik ayrıntı düzeyi için varsayılan ayarları seçmek üzere geçici yapılandırma testlerinden yararlanmaktadır. Gördüğümüz başlıklardan bazıları bu testlerde video bellek boyutunu kullanıyor ancak fiziksel bellek boyutuyla bağıntılı değil. Kayıp cihaz durumlarını işlemek için, video belleğinin büyük bölümü (karttaki yerel VRAM ve yerel olmayan AGP bellek diyaframı) yönetilen kaynakların veya özel veri yapılarının kullanımı yoluyla fiziksel bellek tarafından yedeklenmelidir. Bazı üst düzey ekran kartları, düşük uç CPU belleklerinin boyutuna rakip olan VRAM boyutlarına sahiptir. Sistemin ekran kartına kıyasla sınırlı fiziksel belleğe sahip olduğu durumlarda, bu VRAM'in çoğu etkili bir şekilde kullanılamaz ve daha düşük ayrıntı ayarları yapılandırılmalıdır.

Real-Time Ses Örnek Hızı Dönüştürmede Over-Reliance

Gördüğümüz bir diğer yaygın CPU döngüsü yazma kaynağı, karıştırma sırasında kayıttan yürütme hızını donanım arabelleğine dönüştürmek için ses sisteminin gerekli olması durumunda ortaya çıkar. Windows Sürücü Modeli (WDM) sürücüleriyle, çekirdek düzeyinde bir kaynak olduğundan donanım arabellek biçimi doğrudan uygulama denetimi altında değildir; bunun yerine, biçim tüm kaynakların en yüksek kaliteli biçimine ve donanımın özelliklerine göre seçilir. Varsayılan olarak, Windows XP bu işlem için yüksek kaliteli bir örnek hızı dönüştürmesi kullanır ve ses örneklerinin çoğunluğu hız dönüştürmesi gerektiriyorsa, CPU döngülerinin önemli bir kısmı kullanılır.

Tüm DirectSound arabelleklerinizi aynı örnek hızıyla oluşturmanızı öneririz. Microsoft Win32 waveOut işlevlerini kullanıyorsanız, bunlarla da tutarlı bir örnek oranı kullanmanız gerekir. WDM sürücüleriyle arabelleklerin tümü çekirdek tarafından karıştırılır ve bazılarında daha yüksek örnekleme oranı kullanırsanız, kalanların tümünün örnek oranları eşleşecek şekilde dönüştürülür. Bunun, akış ses sıkıştırma arabellekleri de dahil olmak üzere tüm ses örnekleriniz için aynı kayıttan yürütme hızının kullanıldığı anlamına geldiğini unutmayın. Windows 98 veya Windows Millennium Edition'ı hedeflemediğiniz sürece birincil arabellek hızını ayarlamanın hiçbir etkisi olmaz.

Not

windows vista ve işletim sisteminin sonraki sürümlerinde, DirectSound ve waveOut tüm ses çıkışı için Windows Ses Oturumu API'si (WASAPI) kullanır.

 

Sanal Belleğin Parçalanması

İşlem belleği alanında 32 bit sınırıyla ilgili son zamanlarda karşılaşılan bir dizi sorun gördük. Kullanıcı modu işlemleri için 2 GB sanal adres alanı geçmişte fazlasıyla yeterli olsa da, büyük bellek eşlemeli dosyaların, özel bellek ayırıcılarının ve artan VRAM boyutunun (işlem alanına eşlenmesi gerekir) artan kullanımı, sanal bellek alanı ayırmalarının başarısız olduğu durumlara neden olmaya başlamıştır. Bazı Microsoft dışı DLL'ler sanal adres alanının ortasındaki sabit başlangıç konumlarını kullanır ve bu da parçalanmanın başarısız ayırmalara neden olmasıdır.

Bu sorunlar genellikle oyun büyük bir sürekli sanal bellek alanı öbek ayırmaya çalışan özel bir bellek ayırma şemasını kullandığında ortaya çıkar. Önerimiz, gerektiğinde sanal adres alanının daha makul boyuttaki kısımlarını istemeleri için ayırıcılar yazmaktır. Örneğin, bir kerede 64 veya 256 MB isterken 1 GB istemeyin. Ancak, daha fazla parçalanmalara neden olmayacak şekilde dikkatli olunmalıdır. 64 bit işletim sistemlerinin ve donanımın ortaya çıkması gelecekte bu sorunlara büyük ölçüde yardımcı olacaktır, ancak mevcut nesil 32 bit sistemlerde dikkatli olunmalıdır.

Floating-Point Denetimi Word'ün manipülasyonu

Hata ayıklama yardımı olarak, bazı geliştiriciler kayan nokta denetim sözcüğünün düzenlemeleriyle kayan nokta biriminde (FPU) özel durumları etkinleştiriyor. Bunu yapmak son derece sorunludur ve büyük olasılıkla işlemin kilitlenmesine neden olur. Çağrı kuralının ebx yazmaçlarının korunmasını gerektirdiği gibi, sistemin çoğunluğu FPU'nun varsayılan durumda olduğunu, makul sonuçlar vereceğini ve özel durumlar oluşturmayacağını varsayar. Sürücüler ve diğer sistem bileşenleri genellikle hatalı koşullar için kayıtlarda standart hata değerlerinin görüneceği varsayımını temel alarak sonuçları hesaplar, ancak özel durumlar etkinleştirilirse bunlar işlenmemiş duruma gelir ve kilitlenmelere neden olur.

Direct3D, D3DCREATE_FPU_PRESERVE bayrağı kullanılmadığı sürece kayan noktalı birimi çağıran iş parçacığı için başlatmanın bir parçası olarak tek duyarlıklı, en yakına doğru olacak şekilde ayarlar. Bu durumda kayan nokta denetim sözcüğüne dokunulmaz. Denetim sözcüğü iş parçacığı başına bir ayar olduğundan, tüm uygulama iş parçacıklarınızın tek duyarlıklı moda ayarlandığından emin olmak performansı iyileştirir. _control87 çağrısının x64 yerel kodlama için geçerli olmadığını ve bunun yerine yalnızca SSE kullandığını ve Xbox 360 CPU'nun PowerPC tabanlı mimarisinde son derece pahalı olduğunu unutmayın.

Not

Denetim sözcüğünü değiştirirseniz, _controlfp_s kullanın ve x64 platformlarında kayan nokta duyarlığı denetim sözcüğü aracılığıyla değiştiremediğini unutmayın.

 

Farklı yuvarlama kuralları veya yazılım köşesi gölgelendiricileri veya derleme gibi başka davranışlara sahip olmamız gereken tüm kitaplıklarda, denetim sözcüğünü kaydedip geri yükleriz. Bir oyunun standart olmayan yuvarlama veya FPU özel durumlarını kullanması gerekiyorsa kayan nokta denetim sözcüğünü kaydedip geri yüklemelidir ve sistem API'leri de dahil olmak üzere bu sorunlardan güvenli olduğu kanıtlanmamış herhangi bir dış kodu çağırmadığından emin olmalısınız.

DirectX Çalışma Zamanının İsteğe Bağlı Yüklemesi

Bir dizi oyun kullanıcıya DirectX'i yükleyip yüklemeymeyeceğini sorar. Kullanıcı, sistemde en son DirectX yeniden dağıtılabilir sürümünün yüklü olduğunu varsayar ve yüklemeyi atlarsa ve daha sonra yükleme başarıyla devam ederse bu sorunlara neden olabilir. Oyun belirli bir D3DX sürümüne veya yüklenmemiş başka bir güncelleştirilmiş işleve ihtiyaç duyuyorsa, oyun çalışmaz ve kullanıcı çok hayal kırıklığına uğrar.

Oyunun yükleyicisinin, oyunun üzerine inşa edildiği DirectX yeniden dağıtılabilir sürümünü sessizce yüklemesi kesinlikle önerilir. DirectX yükleme işlemi, herhangi bir şeyin güncelleştirilmesi gerekip gerekmediğini doğrulayıp gerekmediği takdirde hızlı bir şekilde döndürülecek şekilde tasarlanmıştır. Bu nedenle, kullanıcıya DirectX'i yükleme hakkında soru sormanız gerekmez.

DirectX'in sessiz yüklemesi, yükleme paketinizden şu komutu çalıştırarak yapılabilir: dxsetup.exe /silent

Ayrıca, yeniden dağıtılabilir klasörün gerçek boyutu yalnızca oyunun hedef platformları ve kullanımı için gereken dolap dosyalarını (.cab) içerecek şekilde yapılandırılabilir.

Not

dxsetupkullanmadan önce Pek De Doğrudan Kurulumokuyun.

 

İş Parçacığı Eşitlemesinin Aşırı Kullanımı

Oyunların profilini oluştururken, en üstteki etkin noktaların genellikle kritik bölümlere girip çıkmakla ilgili olduğu tespit edilir. Çok çekirdekli CPU'ların yaygınlığı ile oyunlarda çoklu iş parçacığı kullanımı önemli ölçüde artmıştır ve birçok uygulama iş parçacığı eşitlemesinin yoğun kullanımına dayanır. Herhangi bir çekişme olmadan bile kritik bir bölüm almak için CPU süresi oldukça önemlidir ve diğer tüm iş parçacığı eşitleme biçimleri daha pahalıdır. Bu nedenle, bu ilkellerin kullanımını en aza indirmek için dikkatli olunmalıdır.

Oyunlarda aşırı eşitlemenin yaygın bir kaynağı D3DCREATE_MULTITHREADEDkullanılmasıdır. Bu bayrak, Direct3D iş parçacığını birden çok iş parçacığından işleme için güvenli hale getirirken çok muhafazakar bir yaklaşım benimser ve bu da yüksek eşitleme yüküne neden olur. Oyunlar bu bayraktan kaçınmalıdır. Bunun yerine, Direct3D ile tüm iletişimin tek bir iş parçacığından olması ve iş parçacıkları arasındaki tüm iletişimlerin doğrudan işlenmesi için altyapının mimarisini yapın. Çok iş parçacıklı oyunlar tasarlama hakkında daha fazla bilgi için Xbox 360 ve Microsoft Windows 'da Birden Çok Çekirdek için Kodlamamakalesine bakın.

RDTSC kullanımı

RDTSC x86 yönergesinin kullanılması önerilmez. RDTSC, CPU sıklığını dinamik olarak değiştiren bazı güç yönetimi düzenlerinde ve döngü sayacının çekirdekler arasında eşitlenmediği birçok çok çekirdekli CPU'da zamanlamayı doğru hesaplayamıyor. Oyunlar bunun yerine QueryPerformanceCounter API'sini kullanmalıdır. RDTSC ve QueryPerformanceCounterile yüksek çözünürlüklü zamanlama uygulama ile ilgili sorunlar hakkında daha fazla bilgi için, Oyun Zamanlaması ve Çok Çekirdekli İşlemcilermakalesine bakın.