Ikamet
Gpu tarafından erişilebilen bir nesnenin yerleşik olduğu kabul edilir.
GPU'lar henüz sayfa hatasını desteklemediğinden, GPU erişirken uygulamaların verileri fiziksel belleğe işlemesi gerekir. Bu işlem "yerleşik bir şey yapmak" olarak bilinir ve hem fiziksel sistem belleği hem de fiziksel ayrık video belleği için yapılmalıdır. D3D12'de ÇOĞU API nesnesi, GPU ile erişilebilir bellek miktarını kapsüller. GPU ile erişilebilir bellek, API nesnesi oluşturulurken yerleşik hale getirilir ve API nesnesi yok edilmesinde çıkarılır.
İşlem için kullanılabilir fiziksel bellek miktarı, video belleği bütçesi olarak bilinir. Arka plan uyandırma ve uyku işlemlerinin sonucunda bütçede belirgin dalgalanmalar olabilir; ve kullanıcı başka bir uygulamaya geçtiğinde önemli ölçüde dalgalanabilir. Bütçe değiştiğinde ve hem geçerli bütçeyi hem de şu anda tüketilen bellek miktarını yokladığında uygulamaya bildirilebilir. Bir uygulama bütçesi içinde kalmazsa, diğer uygulamaların çalışmasına izin vermek için işlem aralıklı olarak dondurulur ve/veya oluşturma API'leri hata döndürür. IDXGIAdapter3 arabirimi, bu işlevle ilgili yöntemleri sağlar; özellikle QueryVideoMemoryInfo ve registerVideoMemoryBudgetChangeNotificationEvent.
Uygulamaların, olmadan gidemeyecekleri bellek miktarını belirtmek için rezervasyon kullanmaları teşvik edilir. İdeal olarak, kullanıcı tarafından belirtilen "düşük" grafik ayarları veya daha da düşük bir şey, böyle bir rezervasyon için doğru değerdir. Rezervasyon ayarlamak, bir uygulamaya normalde alacağı bütçeden daha yüksek bir bütçe vermez. Bunun yerine, rezervasyon bilgileri işletim sistemi çekirdeğinin büyük bellek baskısı durumlarının etkisini hızla en aza indirmesine yardımcı olur. Uygulama ön plan uygulaması olmadığında rezervasyonun bile uygulamanın kullanımına sunulması garanti edilemez.
Birçok API nesnesi BAZı GPU erişilebilir belleği kapsüllese de, yığınlar & kaynaklarının uygulamaların fiziksel belleği kullanma ve yönetme açısından en önemli yolu olması beklenir. Yığın, fiziksel belleği yönetmek için en düşük düzey birimdir, bu nedenle yerleşik özellikleri hakkında bilgi sahibi olmak iyidir.
- Yığınlar kısmen yerleşik hale getirilemez, ancak ayrılmış kaynaklarla geçici çözümler mevcuttur.
- Yığınlar belirli bir havuzun parçası olarak bütçelenmelidir. UMA bağdaştırıcıları bir havuza sahipken, ayrık bağdaştırıcıların iki havuzu vardır. Çekirdeğin ayrık bağdaştırıcılardaki bazı yığınları video belleğinden sistem belleğine kaydırabildiği doğru olsa da, bunu yalnızca aşırı son çare olarak yapar. Uygulamalar çekirdeğin bütçeyi aşan davranışına güvenmemeli ve bunun yerine iyi bütçe yönetimine odaklanmalıdır.
- Yığınlar, içeriklerinin diske çağrılmasını sağlayan yerleşim alanından çıkarılabilir. Ancak yığınların yok edilmesi, tüm bağdaştırıcı mimarilerinde yerleşimi boşaltmak için daha güvenilir bir tekniktir. D3D12_FEATURE_DATA_GPU_VIRTUAL_ADDRESS_SUPPORT MaxGPUVirtualAddressBitsPerProcess alanının bütçe boyutuna yakın olduğu bağdaştırıcılarda Çıkarma güvenilir bir şekilde yerleşimi geri kazanmaz.
- Yığın oluşturma yavaş olabilir; ancak arka plan iş parçacığı işleme için iyileştirilmiştir. İşleme iş parçacığında hata oluşmasını önlemek için arka plan iş parçacıklarında yığınlar oluşturmanız önerilir. D3D12'de, birden çok iş parçacığı oluşturma yordamlarını eşzamanlı olarak güvenli bir şekilde çağırabilir.
D3D12, uygulamalar için daha fazla seçenek sunmak amacıyla kaynak modeline daha fazla esneklik ve ortogonalite getirir. D3D12'de üç üst düzey kaynak türü vardır: kaydedilmiş, yerleştirilmiş ve ayrılmış.
- Kaydedilmiş kaynaklar aynı anda hem kaynak hem de yığın oluşturur. Yığın örtük ve doğrudan erişilemez. Yığın, yığının içindeki kaynağın tamamını bulmak için uygun şekilde boyutlandırılır.
- Yerleştirilen kaynaklar, bir kaynağın yığın içinde sıfır olmayan bir uzaklıkta yerleştirilmesine olanak sağlar. Uzaklıklar genellikle 64 KB'a hizalanmalıdır; ancak bazı özel durumlar her iki yönde de mevcuttur. MSAA kaynakları 4 MB uzaklık hizalaması gerektirir ve küçük dokular için 4 KB uzaklık hizalaması kullanılabilir. Yerleştirilen kaynaklar doğrudan başka bir yığına taşınamaz veya yeniden eşlenemez; ancak kaynak verilerinin yığınlar arasında kolayca yeniden yerleştirilmesini sağlar. Farklı bir yığında yeni bir yerleştirilen kaynak oluşturduktan ve kaynak verilerini kopyaladıktan sonra, yeni kaynak veri konumu için yeni kaynak tanımlayıcılarının kullanılması gerekir.
- Ayrılmış kaynaklar yalnızca bağdaştırıcı kutucuklu kaynaklar katman 1 veya üzerini desteklediğinde kullanılabilir. Kullanılabilir olduğunda, en gelişmiş yerleşim yönetimi tekniklerini sunarlar; ancak şu anda tüm bağdaştırıcılar bunları desteklememektedir. Kaynak tanımlayıcılarının, kısmi mip düzeyi yerleşiminin ve seyrek doku senaryolarının yeniden düzenlenmesine gerek kalmadan bir kaynağın yeniden eşlenmesini sağlar. Ayrılmış kaynaklar kullanılabilir olduğunda bile tüm kaynak türleri desteklenmez, bu nedenle tam genel sayfa tabanlı bir yerleşim yöneticisi henüz uygun değildir.
Windows 10 Creators Update, geliştiricilerin bellek baskısı bazı kaynaklarının indirilmesi gerektiğinde hangi yığınların ve kaynakların yerleşik kalmasını tercih edeceklerini etkilemesini sağlar. Bu, geliştiricilerin çalışma zamanının API kullanımından çıkarılamadığı bilgisini kullanarak daha iyi performans gösteren uygulamalar oluşturmalarına yardımcı olur. Geliştiricilerin, işlenmiş kaynakları kullanmaktan yeniden alınan ve kutucuklanmış kaynaklara geçerken öncelikleri belirtme konusunda daha rahat ve becerikli hale gelmesi bekleniyordu.
Bu öncelikleri uygulamak, iki dinamik bellek bütçesini yönetmekten daha kolay olmalıdır; uygulamalar bunu zaten gerçekleştirebildiğinden kaynakları el ile indirgeme ve yükseltme. Bu nedenle, yerleşim önceliği API'sinin tasarımı, oluşturuldukları her yığına veya kaynağa atanan makul varsayılan önceliklerle elbette ayrıntılıdır. Daha fazla bilgi için bkz. ID3D12Device1::SetResidencyPriorityve D3D12_RESIDENCY_PRIORITY numaralandırması.
Öncelikleri olan geliştiricilerin şunlardan biri olması beklenir:
- Bu yığınların doğal erişim desenlerinden daha erken veya daha sık indirgenmesinin deneyimli performans etkisini daha iyi azaltmak için birkaç olağanüstü yığının önceliğini yükseltin. Bu yaklaşımın Direct3D 11 veya OpenGL gibi grafik API'lerinden taşınabilir uygulamalar tarafından kullanılabilmesi beklenir. Kaynak yönetimi modeli Direct3D 12'den önemli ölçüde farklıdır.
- Programcının erişim sıklığı veya dinamik bilgisine bağlı olarak, uygulamanın kendi demeti oluşturma düzeniyle neredeyse tüm yığın önceliklerini geçersiz kıl; Sabit bir düzenin yönetilmesi dinamik bir şemadan daha basittir, ancak daha az etkili olabilir ve geliştirme sürecinde kullanım desenleri değiştikçe programcı intevention gerektirir. Bu yaklaşımın, yerleşik kitaplığını kullanan uygulamalar (özellikle dinamik düzenler) gibi Direct3D 12 stili kaynak yönetimi düşünülerek oluşturulmuş uygulamalar tarafından kullanılması beklenir.
Bir uygulama, ilk olarak varsayılan öncelik algoritmasını belirlemeden yönetmeye çalıştığı herhangi bir yığın için yararlı öncelikleri belirtemez. Bunun nedeni, bir yığına belirli bir öncelik atama değerinin, göreli önceliğini aynı bellek için rekabet eden diğer önceliklendirilmiş yığınlara türetilmesidir.
Varsayılan öncelikleri oluşturmak için seçilen strateji, yığınları iki demet halinde kategorilere ayırmaktır ve gpu tarafından sık sık yazıldığı varsayılan yığınları desteklemez (daha yüksek öncelik verir).
Yüksek öncelikli demet, bunları işleme hedefleri, derinlik kalıbı arabellekleri veya Sıralanmamış Erişim Görünümleri (UAV) olarak tanımlayan bayraklarla oluşturulan yığınları ve kaynakları içerir. Bunlar, D3D12_RESIDENCY_PRIORITY_HIGHbaşlayan aralıktaki öncelik değerlerine atanır; bu yığınlar ve kaynaklar arasında daha fazla öncelik belirlemek için, önceliğin en düşük 16 bit'i yığın veya kaynağın boyutuna 10 MB'a bölünür (son derece büyük yığınlar için 0xFFFF doygunluğa ayarlanır). Bu ek öncelik belirlemesi daha büyük yığınları ve kaynakları destekler.
Düşük öncelikli demet, D3D12_RESIDENCY_PRIORITY_NORMALöncelik değeri atanmış diğer tüm yığınları ve kaynakları içerir. Bu yığınlar ve kaynaklar arasında başka öncelik belirleme girişiminde bulunulamaz.
Basit uygulamalar, bellek yetersiz hatalarıyla karşılaşana kadar yalnızca kaydedilmiş kaynaklar oluşturarak elde edebilir. Hata durumunda uygulama, daha fazla kaynak oluşturma işleminin başarılı olmasını sağlamak için diğer kaydedilmiş kaynakları veya API nesnelerini yok edebilir. Ancak, basit uygulamaların bile negatif bütçe değişikliklerini izlemesi ve kullanılmayan API nesnelerini kabaca çerçevede bir kez yok etmeleri kesinlikle önerilir.
Bağdaştırıcı mimarileri için iyileştirme yapmaya veya yerleşiklik önceliklerini birleştirmeye çalışırken bir yerleşim yönetimi tasarımının karmaşıklığı artırılır. İki ayrı bellek havuzunu ayrı ayrı bütçelemek ve yönetmek, yalnızca bir tanesini yönetmekten daha karmaşık olacaktır ve kullanım desenleri gelişirse geniş ölçekte sabit öncelikler atamak bakım yükü haline gelebilir. Dokuların sistem belleğine taşması, sistem belleğindeki yanlış kaynak kare hızını ciddi şekilde etkileyene kadar daha fazla karmaşıklık ekler. Ayrıca, daha yüksek GPU bant genişliğinden yararlanabilecek veya daha düşük GPU bant genişliğine tolerans sağlayacak kaynakları belirlemeye yardımcı olacak basit bir işlev yoktur.
Daha da karmaşık tasarımlar geçerli bağdaştırıcının özelliklerini sorgular. Bu bilgiler D3D12_FEATURE_DATA_GPU_VIRTUAL_ADDRESS_SUPPORT, D3D12_FEATURE_DATA_ARCHITECTURE, D3D12_TILED_RESOURCES_TIERve D3D12_RESOURCE_HEAP_TIERiçinde kullanılabilir.
Bir uygulamanın birden çok parçası büyük olasılıkla farklı teknikler kullanılarak ortaya çıkar. Örneğin, bazı büyük dokular ve nadiren uygulanan kod yolları kaydedilmiş kaynaklar kullanabilirken, birçok doku bir akış özelliğiyle belirlenebilir ve genel bir yerleştirilmiş kaynak tekniği kullanabilir.