Strategi Manajemen Memori
Manajer memori untuk Direct3D 12 bisa menjadi sangat rumit dengan cepat dengan semua tingkat dukungan yang berbeda, untuk adaptor UMA atau diskrit (non-UMA), dan dengan berbagai perbedaan arsitektur yang cukup besar antara adaptor GPU.
Strategi yang direkomendasikan untuk manajemen memori Direct3D 12 , yang dijelaskan di bagian ini, adalah "mengklasifikasikan, anggaran, dan aliran".
Jenis sumber daya
Konsep dasar "sumber daya yang diterapkan" (membuat ruang alamat virtual dan fisik yang diinisialisasi dalam memori fisik terkelola) telah ada sejak Direct3D 9, meskipun alamat virtual (VA) dan alamat fisik dapat digoda di Direct3D 12 untuk memungkinkan aplikasi mengelola memori fisik dengan hati-hati.
Selain sumber daya yang berkomitmen, konstruksi tumpukan Direct3D 12 memungkinkan dua jenis sumber daya lainnya: "ditempatkan" dan "dicadangkan". Di Direct3D 11, sumber daya "dicadangkan" dikenal sebagai "sumber daya ubin".
Sumber daya yang dipesan berbeda dari sumber daya yang ditempatkan dalam sumber daya yang dipesan tersebut memiliki ruang alamat virtual GPU unik mereka sendiri. Ini memungkinkan alokasi besar ruang VA di depan dan kemudian memungkinkan pemetaan halaman VA ke bagian tertentu dari tumpukan nanti, dan aplikasi mengonfigurasi ulang pengaturan dengan cepat. Ruang VA berdampingan, dan dapat dipetakan secara jarang.
Sumber daya yang dipesan dapat dibuat untuk wilayah referensi di tumpukan dengan panggilan API seperti UpdateTileMappings dan mereka dapat dibuat residen oleh aplikasi dengan memperbarui tabel halaman dengan cepat. Ketika rentang VA dipetakan ke NULL atau timbunan non-residen, bagian sumber daya tersebut dianggap bukan penduduk. Ketika rentang VA dipetakan ke tumpukan penduduk, bagian sumber daya tersebut dianggap sebagai penduduk. Tumpukan adalah residen setelah penciptaan.
Sumber daya yang ditempatkan adalah desain yang jauh lebih sederhana, hanya menjadi penunjuk ke wilayah tertentu dari timbunan (misalnya, wilayah 1Mb untuk tekstur dalam tumpukan 5Mb). Hambatan alias memungkinkan penggunaan sumber daya yang ditempatkan tumpang tindih (lihat CreatePlacedResource dan ResourceBarrier).
Sumber daya yang dipesan tidak tersedia di semua perangkat keras Direct3D 12, dan sumber daya yang ditempatkan adalah fallback yang wajar, meskipun sumber daya yang ditempatkan harus berdekatan dan tidak dapat sebagian penduduk.
Anggaran memori
Di Direct3D 12 saat Anda mengalokasikan timbunan, Anda membuat aspek memori fisik dari sumber daya yang diterapkan. Pilihan segmen memori yang lebih eksplisit tersedia di Direct3D 12 (memilih antara memori video dan sistem). Adaptor UMA hanya memiliki satu segmen memori, memori sistem.
GPU tidak mendukung kesalahan halaman, sehingga pengembang harus sadar bahwa mereka tidak terlalu berkomitmen, terutama untuk sistem yang mengatakan hanya dengan memori sistem 1Gb. Jika aplikasi melakukan penerapan, maka OS menggunakan penjadwalan proses yang lebih kasar berdasarkan permintaannya pada memori fisik. Penjadwal akan membekukan proses latar depan dan pada dasarnya halaman beberapa dari itu keluar, untuk halaman-dalam proses latar belakang yang ingin berjalan. Memori fisik yang tersedia dapat sangat bervariasi tergantung pada apa yang dilakukan pengguna di latar belakang (seperti menjalankan browser atau menonton video).
API untuk anggaran memori adalah QueryVideoMemoryInfo. Untuk adaptor diskrit "lokal" adalah memori video, "non-lokal" adalah memori sistem. Untuk adaptor UMA non-lokal selalu nol. Salah satu pertanyaan desain adalah apakah mesin Anda akan mengelola anggaran atau hanya anggaran lokal. Mengelola hanya anggaran lokal yang lebih sederhana tetapi memiliki beberapa peringatan; misalnya mengatakan ada anggaran lokal maksimum 1Gb, maka semua timbunan akan berasal dari 1Gb itu dalam sistem UMA dan tidak ada luapan ke memori sistem (jelas, karena tidak ada).
Karena memori terkelola Direct3D11 untuk aplikasi, sumber daya yang tidak digunakan pada dasarnya akan di-page out.
Pilih dimensi sumber daya yang paling tepat. Pertimbangkan apakah ukuran sumber daya sesuai untuk situasi aplikasi benar-benar berjalan. Beberapa pengguna dapat menjalankan aplikasi di jendela atau dengan resolusi layar 800x600.
Strategi klasifikasi
Untuk mengelola sumber daya secara efektif dalam skenario terikat memori, pertimbangkan untuk mengklasifikasikan sumber daya ke dalam hal berikut:
| Klasifikasi | Contoh | Fitur Objek dan API | Catatan manajemen |
|---|---|---|---|
| Kritis | UI Permainan | Alokator perintah, antrean perintah, timbunan kueri, sumber daya, dan timbunan sumber daya. | Elemen-elemen ini harus masuk dalam memori yang tidak dapat di-pageable/selalu berkomitmen. |
| Diskalakan/Opsional | Model dan tekstur khusus tingkat, rantai pertukaran, kotak langit, model karakter pemutar orang pertama | Sumber daya dan timbunan. Sumber daya yang berkomitmen, tetapi juga sumber daya yang ditempatkan dan dipesan mungkin juga berfungsi. | Integrasikan penganggaran residensi memori ke dalam algoritma penyajian. Pilih tingkat detail yang tersedia dan evaluasi ulang kurang dari sekali per bingkai. Teknik termasuk menggunakan sumber daya berukuran variabel dan penskalaan rantai pertukaran. |
| Sumber Daya yang Digunakan Kembali | Buffer bayangan, sumber daya rendering yang ditangguhkan, sumber daya pasca-pemrosesan, cache data pencahayaan | Sumber daya dan timbunan. Sumber daya yang ditempatkan tumpang tindih pada tumpukan dan hambatan alias. | Gunakan kembali sumber daya besar atau wilayah tumpukan dalam bingkai untuk mengurangi persyaratan untuk seluruh bingkai. Gunakan teknik penggunaan kembali memori intra-frame. Di Direct3D 11, aplikasi hanya dapat menggunakan kembali sumber daya dengan jenis yang sama dan dimensi yang berpotensi cukup besar. Timbunan Direct3D 12 memungkinkan sumber daya yang tumpang tindih untuk penggunaan kembali yang jauh lebih sederhana dan lebih besar. |
| Sumber Daya Streaming | Medan, tekstur dan geometri dunia terbuka | Sumber daya dan timbunan. Pembuatan utas bebas, utas CPU latar belakang, dan antrean dan daftar perintah salin latar belakang. | Residensi parsial, biasanya didasarkan pada visibilitas (menggunakan evaluasi view-frustum atau berbasis jarak) dan mengevaluasi ulang kebutuhan residensi setiap bingkai. Teknik menggunakan manajemen residensi parsial per petak peta dan penggunaan kembali antar bingkai tersedia ketika adaptor GPU mendukung sumber daya yang dipesan dalam timbunan. Dengan menggunakan teknik penggunaan kembali memori antar bingkai, residensi sub sumber daya parsial dapat dicapai, tetapi kurang optimal. Sumber daya yang ditempatkan dengan timbunan harus memungkinkan daur ulang yang lebih cepat, tetapi sumber daya yang berkomitmen dapat digunakan sebagai fallback. |
Semakin banyak aplikasi yang memahami sumber daya streaming untuk sebagian besar pekerjaan, semakin banyak aplikasi akan memanfaatkan sumber daya yang ditempatkan dan dipesan, yang akan memaksimalkan penggunaan kembali memori di antara keempat klasifikasi ini. Semakin banyak aliran aplikasi, semakin banyak yang dianggarkan dan diprioritaskan bandwidth.
Biasanya dengan mesin grafis Direct3D 12 perlu menghormati anggaran yang lebih beragam dan dinamis, dan melakukannya lebih ketat daripada yang mereka lakukan di masa lalu. Aplikasi terbaik akan menemukan keempat kategori ke dalam anggaran yang diberikan untuk proses, menskalakan permainan dari aplikasi seluler latar belakang ke anggaran diskrit layar penuh. Tetapi, banyak aplikasi kemungkinan akan berjuang dengan memulai dengan terlalu banyak jenis sumber daya kategori kritis. Sumber daya yang diaktifkan Direct3D 11 dibuat secara anonim dan menempati status kritis tanpa memengaruhi performa. Namun, untuk Direct3D 12, pengembang harus rajin mencari sumber daya yang dibuat secara acak di seluruh mesin dan middleware mereka dan menetapkannya kembali ke salah satu kategori lainnya.
Area masalah lainnya adalah komponen middleware, kontrol pengguna, dan streaming intra-frame. Komponen middleware mungkin tidak terpapar anggaran, juga tidak harus bekerja sama erat. Komponen middleware kemungkinan dapat mengekspos fitur sebagai teknik penyajian; dan aplikasi dapat mengandalkan mengekspos middleware dan pengaturan mesin. Pengembang dapat mengandalkan Direct3D 11 untuk melakukan paging dan mencapai kecepatan bingkai yang tepat. Dalam beberapa kasus, aplikasi Direct3D 11 mungkin telah memasukkan konten sumber daya ke dalam dan ke luar setiap bingkai; dan menghasilkan kecepatan bingkai yang dapat diterima untuk pengguna. Sebagian besar mesin hanya mengalirkan data sumber daya sebagai aktivitas latar belakang, di mana ia tidak memiliki fallback yang anggun ke streaming intra-frame prioritas tinggi. Meminta mesin untuk mengimplementasikan yang akan mengikis beberapa keuntungan overhead CPU yang mereka cari dengan pindah ke Direct3D 12. Pengembang mesin dapat mempertimbangkan untuk menggoda bingkai mereka ke dalam fase untuk memberikan lebih banyak kesempatan untuk sumber daya yang dapat digunakan kembali; dan kemungkinan bekerja dengan vendor middleware untuk mendukung sumber daya dan timbunan yang ditempatkan untuk penggunaan kembali memori intra-frame.