Share via

Residensi

  • Artikel

Objek dianggap residen ketika dapat diakses oleh GPU.

Anggaran residensi

GPU belum mendukung kesalahan halaman, sehingga aplikasi harus menerapkan data ke dalam memori fisik sementara GPU dapat mengaksesnya. Proses ini dikenal sebagai "membuat sesuatu residen", dan harus dilakukan untuk memori sistem fisik dan memori video diskrit fisik. Di D3D12, sebagian besar objek API merangkum beberapa jumlah memori yang dapat diakses GPU. Memori yang dapat diakses GPU itu dibuat residen selama pembuatan objek API, dan dikeluarkan pada penghancuran objek API.

Jumlah memori fisik yang tersedia untuk proses ini dikenal sebagai anggaran memori video. Anggaran dapat berfluktuasi secara nyata saat proses latar belakang bangun dan tidur; dan berfluktuasi secara dramatis ketika pengguna beralih ke aplikasi lain. Aplikasi dapat diberi tahu ketika anggaran berubah dan polling baik anggaran saat ini maupun jumlah memori yang saat ini dikonsumsi. Jika aplikasi tidak tetap dalam anggarannya, proses akan dibekukan secara terputus-putus untuk memungkinkan aplikasi lain berjalan dan/atau API pembuatan akan mengembalikan kegagalan. Antarmuka IDXGIAdapter3 menyediakan metode yang berkaitan dengan fungsionalitas ini, khususnya QueryVideoMemoryInfo dan RegisterVideoMemoryBudgetChangeNotificationEvent.

Aplikasi didorong untuk menggunakan reservasi untuk menunjukkan jumlah memori yang tidak dapat mereka gunakan tanpanya. Idealnya, pengaturan grafis "rendah" yang ditentukan pengguna, atau sesuatu yang bahkan lebih rendah, adalah nilai yang tepat untuk reservasi tersebut. Menetapkan reservasi tidak akan pernah memberi aplikasi anggaran yang lebih tinggi daripada yang biasanya diterima. Sebaliknya, informasi reservasi membantu kernel OS dengan cepat meminimalkan dampak situasi tekanan memori besar. Bahkan reservasi tidak dijamin tersedia untuk aplikasi ketika aplikasi bukan aplikasi latar depan.

Sumber daya timbunan

Meskipun banyak objek API merangkum beberapa memori yang dapat diakses GPU, tumpukan & sumber daya diharapkan menjadi cara paling signifikan aplikasi mengkonsumsi dan mengelola memori fisik. Timbunan adalah unit tingkat terendah untuk mengelola memori fisik, jadi ada baiknya untuk memiliki beberapa keakraban dengan sifat residensi mereka.

  • Timbunan tidak dapat dibuat sebagian penduduk, tetapi solusi ada dengan sumber daya yang dipesan.
  • Timbunan harus dianggarkan sebagai bagian dari kumpulan tertentu. Adaptor UMA memiliki satu kumpulan, sementara adaptor diskrit memiliki dua kumpulan. Meskipun benar bahwa kernel dapat menggeser beberapa tumpukan pada adaptor diskrit dari memori video ke memori sistem, itu melakukannya hanya sebagai upaya terakhir yang ekstrem. Aplikasi tidak boleh mengandalkan perilaku anggaran kernel yang berlebihan, dan harus fokus pada manajemen anggaran yang baik sebagai gantinya.
  • Tumpukan dapat dikeluarkan dari residensi, yang memungkinkan konten mereka di-page out ke disk. Tetapi, penghancuran tumpukan adalah teknik yang lebih andal untuk membebaskan residensi di semua arsitektur adaptor. Pada adaptor di mana bidang D3D12_FEATURE_DATA_GPU_VIRTUAL_ADDRESS_SUPPORT MaxGPUVirtualAddressBitsPerProcess mendekati ukuran anggaran, Evict tidak akan mengklaim kembali residensi dengan andal.
  • Pembuatan timbunan bisa lambat; tetapi dioptimalkan untuk pemrosesan utas latar belakang. Disarankan untuk membuat timbunan pada utas latar belakang untuk menghindari glitching utas render. Di D3D12, beberapa utas dapat dengan aman memanggil membuat rutinitas secara bersamaan.

D3D12 memperkenalkan lebih banyak fleksibilitas dan ortogonalitas ke dalam model sumber dayanya untuk memungkinkan lebih banyak opsi untuk aplikasi. Ada tiga jenis sumber daya tingkat tinggi di D3D12: berkomitmen, ditempatkan, dan dipesan.

  • Sumber daya yang berkomitmen membuat sumber daya dan timbunan secara bersamaan. Tumpukannya implisit dan tidak dapat diakses secara langsung. Timbunan berukuran tepat untuk menemukan seluruh sumber daya dalam timbunan.
  • Sumber daya yang ditempatkan memungkinkan penempatan sumber daya pada offset bukan nol dalam tumpukan. Offset biasanya harus diselaraskan ke 64KB; tetapi beberapa pengecualian ada di kedua arah. Sumber daya MSAA memerlukan penyelarasan offset 4MB, dan perataan offset 4KB tersedia untuk tekstur kecil. Sumber daya yang ditempatkan tidak dapat direlokasi atau dipetakan ulang ke timbunan lain secara langsung; tetapi mereka memungkinkan relokasi sederhana data sumber daya di antara timbunan. Setelah membuat sumber daya baru yang ditempatkan di timbunan yang berbeda dan menyalin data sumber daya, deskriptor sumber daya baru harus digunakan untuk lokasi data sumber daya baru.
  • Sumber daya yang dipesan hanya tersedia ketika adaptor mendukung sumber daya berjenjang tingkat 1 atau lebih besar. Jika tersedia, mereka menawarkan teknik manajemen residensi paling canggih yang tersedia; tetapi tidak semua adaptor saat ini mendukungnya. Mereka memungkinkan pemecahan ulang sumber daya tanpa memerlukan regenerasi deskriptor sumber daya, residensi tingkat mip parsial, dan skenario tekstur jarang, dll. Tidak semua jenis sumber daya didukung bahkan ketika sumber daya yang dipesan tersedia, sehingga manajer residensi berbasis halaman yang sepenuhnya umum belum layak.

Prioritas residensi

Windows 10 Creators Update memungkinkan pengembang untuk memengaruhi timbunan dan sumber daya mana yang akan lebih disukai untuk tetap tinggal ketika tekanan memori mengharuskan beberapa sumber dayanya diturunkan. Ini membantu pengembang membuat aplikasi berkinerja lebih baik dengan memanfaatkan pengetahuan bahwa runtime tidak dapat menyimpulkan dari penggunaan API. Diharapkan pengembang akan menjadi lebih nyaman dan mampu menentukan prioritas saat mereka beralih dari menggunakan sumber daya yang dilaksanakan ke sumber daya yang direserevasi dan ditingkatkan.

Menerapkan prioritas ini harus lebih mudah daripada mengelola dua anggaran memori dinamis, menurunkan dan mempromosikan sumber daya secara manual, karena aplikasi sudah dapat melakukannya. Oleh karena itu, desain API prioritas residensi tentu saja terperinci dengan prioritas default yang wajar yang ditetapkan ke setiap tumpukan atau sumber daya seperti yang dibuatnya. Untuk informasi selengkapnya, lihat ID3D12Device1::SetResidencyPriority dan enumerasi D3D12_RESIDENCY_PRIORITY.

Dengan prioritas, pengembang diharapkan untuk:

  • Tingkatkan prioritas beberapa timbunan luar biasa untuk mengurangi dampak performa yang berpengalaman dari tumpukan ini yang diturunkan cepat atau lebih sering daripada pola akses alami yang akan diminta. Pendekatan ini diharapkan dapat dimanfaatkan oleh aplikasi yang di-port dari API grafis seperti Direct3D 11 atau OpenGL, model manajemen sumber daya siapa yang secara signifikan berbeda dari Direct3D 12.
  • Mengambil alih hampir semua prioritas timbunan dengan skema bucketisasi aplikasi sendiri, baik tetap, berdasarkan pengetahuan programmer tentang frekuensi akses, atau dinamis; skema tetap lebih mudah dikelola daripada yang dinamis, tetapi bisa kurang efektif dan memerlukan intevensi pemrogram saat pola penggunaan berubah selama pengembangan. Pendekatan ini diharapkan dapat dimanfaatkan oleh aplikasi yang dibangun dengan mengingat manajemen sumber daya gaya Direct3D 12, seperti yang menggunakan pustaka residensi (terutama skema dinamis).

Algoritma prioritas default

Aplikasi tidak dapat menentukan prioritas yang berguna untuk tumpukan apa pun yang coba dikelolanya tanpa terlebih dahulu mendasar algoritma prioritas default. Ini karena nilai menetapkan prioritas tertentu ke tumpukan berasal dari prioritas relatifnya ke tumpukan lain yang diprioritaskan yang bersaing untuk memori yang sama.

Strategi yang dipilih untuk menghasilkan prioritas default adalah mengategorikan tumpukan ke dalam dua wadah, mendukung (memberikan prioritas yang lebih tinggi ke) timbunan yang diasumsikan sering ditulis oleh GPU di atas tumpukan yang tidak.

Wadah berprioritas tinggi berisi timbunan dan sumber daya yang dibuat dengan bendera yang mengidentifikasinya sebagai target render, buffer stensil kedalaman, atau Tampilan Akses Tidak Berurut (UAV). Ini adalah nilai prioritas yang ditetapkan dalam rentang mulai dari D3D12_RESIDENCY_PRIORITY_HIGH; untuk lebih memprioritaskan di antara timbunan dan sumber daya ini, 16-bit terendah dari prioritas diatur ke ukuran timbunan atau sumber daya yang dibagi 10MB (menjenuhkan ke 0xFFFF untuk timbunan yang sangat besar). Prioritas tambahan ini mendukung timbunan dan sumber daya yang lebih besar.

Wadah berprioritas rendah berisi semua timbunan dan sumber daya lainnya, yang diberi nilai prioritas D3D12_RESIDENCY_PRIORITY_NORMAL. Tidak ada prioritas lebih lanjut di antara timbunan dan sumber daya ini yang dicoba.

Manajemen residensi pemrograman

Aplikasi sederhana mungkin dapat diperoleh hanya dengan membuat sumber daya yang berkomitmen hingga mengalami kegagalan di luar memori. Setelah kegagalan, aplikasi dapat menghancurkan sumber daya atau objek API berkomitmen lainnya untuk memungkinkan pembuatan sumber daya lebih lanjut berhasil. Tetapi, bahkan aplikasi sederhana sangat disarankan untuk mengawasi perubahan anggaran negatif dan menghancurkan objek API yang tidak digunakan kira-kira sekali bingkai.

Kompleksitas desain manajemen residensi akan naik ketika mencoba mengoptimalkan arsitektur adaptor atau menggabungkan prioritas residensi. Menganggarkan dan mengelola dua kumpulan memori diskrit secara diskrit akan lebih kompleks daripada hanya mengelola satu, dan menetapkan prioritas tetap dalam skala luas dapat menjadi beban pemeliharaan jika menggunakan pola berkembang. Meluapkan tekstur ke dalam memori sistem menambahkan lebih banyak kompleksitas, karena sumber daya yang salah dalam memori sistem dapat sangat memengaruhi kecepatan bingkai. Dan, tidak ada fungsionalitas sederhana untuk membantu mengidentifikasi sumber daya yang akan mendapat manfaat dari bandwidth GPU yang lebih tinggi atau mentolerir bandwidth GPU yang lebih rendah.

Desain yang lebih rumit akan mengkueri fitur adaptor saat ini. Informasi ini tersedia di D3D12_FEATURE_DATA_GPU_VIRTUAL_ADDRESS_SUPPORT, D3D12_FEATURE_DATA_ARCHITECTURE, D3D12_TILED_RESOURCES_TIER, dan D3D12_RESOURCE_HEAP_TIER.

Beberapa bagian aplikasi kemungkinan akan berakhir menggunakan teknik yang berbeda. Misalnya, beberapa tekstur besar dan jalur kode yang jarang dilakukan dapat menggunakan sumber daya yang diterapkan, sementara banyak tekstur dapat ditunjuk dengan properti streaming dan menggunakan teknik sumber daya ditempatkan umum.

ID3D12Heap

Manajemen Memori