Bagikan melalui

Pelacakan penggunaan alokasi

  • Artikel

Dengan daftar alokasi yang hilang, manajer memori video (VidMm) tidak lagi memiliki visibilitas ke dalam alokasi yang dirujuk dalam buffer perintah tertentu. Akibatnya, VidMm tidak lagi dalam posisi untuk melacak penggunaan alokasi dan untuk menangani sinkronisasi terkait. Tanggung jawab ini sekarang termasuk dalam driver mode pengguna (UMD). Secara khusus, UMD perlu menangani sinkronisasi sehubungan dengan akses CPU langsung ke alokasi dan penggantian nama.

VidMm secara asinkron menunda penghancuran alokasi dengan cara yang aman yang tidak diblokir untuk utas panggilan dan performan. Karena itu UMD tidak perlu khawatir harus menunggak penghancuran alokasi. Ketika VidMm menerima permintaan penghancuran alokasi, ia mengasumsikan secara default bahwa perintah yang diantrekan sebelum permintaan penghancuran mungkin berpotensi mengakses alokasi yang dihancurkan. VidMm dengan demikian menangguhkan operasi penghancuran sampai perintah antrean selesai. Jika UMD tahu bahwa perintah yang tertunda tidak mengakses alokasi yang dihancurkan, itu dapat menginstruksikan VidMm untuk memproses permintaan tanpa menunggu dengan mengatur bendera AssumeNotInUse saat memanggil Deallocate2 atau DestroyAllocation2.

Lock2

UMD bertanggung jawab untuk menangani sinkronisasi yang tepat sehubungan dengan akses CPU langsung. Secara khusus, UMD diperlukan untuk:

  1. Mendukung semantik tanpa timpa dan membuang kunci, yang menyiratkan bahwa UMD perlu menerapkan skema penggantian namanya sendiri.

  2. Untuk operasi peta yang memerlukan sinkronisasi (yaitu, bukan yang di atas tanpa timpa atau buang):

    • Kembalikan WasStillDrawing jika upaya dilakukan untuk mengakses alokasi yang saat ini sibuk dan pemanggil telah meminta agar operasi Penguncian tidak memblokir utas panggilan (D3D11_MAP_FLAG_DO_NOT_WAIT).
    • Atau, jika bendera D3D11_MAP_FLAG_DO_NOT_WAIT tidak diatur, tunggu hingga alokasi tersedia untuk akses CPU. UMD perlu menerapkan penantian nonpolling. UMD akan menggunakan mekanisme pemantauan konteks baru.

Untuk saat ini, UMD terus perlu memanggil LockCb/UnlockCb untuk meminta VidMm menyiapkan alokasi untuk akses CPU. Dalam kebanyakan kasus, UMD dapat menjaga alokasi dipetakan selama masa pakainya. Namun, di masa mendatang, LockCb dan UnlockCb tidak akan digunakan lagi demi panggilan Lock2Cb dan Unlock2Cb baru. Tujuan dari panggilan balik yang lebih baru ini adalah untuk memberikan implementasi bersih yang segar dengan serangkaian argumen dan bendera baru.

Rentang menggeser dihapus dari WDDM versi 2. Pengembang driver bertanggung jawab untuk menghapus dependensi pada rentang menggeser dari panggilan ke LockCb saat mereka bergerak menuju implementasi yang didasarkan pada Lock2Cb.

Lock2Cb diekspos sebagai metode sederhana untuk mendapatkan alamat virtual ke alokasi. Ada beberapa pembatasan berdasarkan jenis alokasi dan segmen saat ini tempatnya tinggal.

Driver menunjukkan apakah segmen dapat diakses CPU melalui bendera CpuVisible , yang ada di anggota Bendera struktur DXGK_SEGMENTDESCRIPTOR .

Untuk alokasi yang dapat diakses CPU:

  • Alokasi yang dapat diakses CPU yang di-cache harus berada dalam segmen aperture atau tidak menjadi penduduk untuk dikunci. Kami tidak dapat menjamin koherensi cache antara CPU dan segmen memori pada unit pemrosesan grafis (GPU).
  • Alokasi yang dapat diakses CPU yang terletak di segmen memori yang sepenuhnya dapat diakses CPU (diubah ukurannya menggunakan BAR yang dapat diubah ukurannya) dijamin dapat dikunci dan dapat mengembalikan alamat virtual. Tidak ada batasan khusus yang diperlukan dalam skenario ini.
  • Alokasi yang dapat diakses CPU yang terletak dalam segmen memori yang tidak dapat diakses CPU (dengan atau tanpa akses ke CpuHostAperture) dapat gagal dipetakan ke alamat virtual CPU karena berbagai alasan. Jika CpuHostAperture kehabisan ruang atau alokasi tidak menentukan segmen aperture, alamat virtual tidak mungkin diperoleh. Untuk alasan ini, semua alokasi yang dapat diakses CPU di segmen memori yang tidak dapat diakses CPU harus berisi segmen aperture dalam set segmen yang didukung. Persyaratan ini menjamin bahwa VidMm dapat menempatkan alokasi dalam memori sistem dan memberikan alamat virtual.
  • Alokasi yang dapat diakses CPU yang sudah berada dalam memori sistem (dan/atau dipetakan ke segmen aperture) dijamin berfungsi.

Untuk alokasi yang tidak dapat diakses CPU:

  • Alokasi yang dapat diakses CPU didukung oleh objek bagian yang tidak dapat menunjuk langsung ke buffer bingkai GPU. Untuk mengunci alokasi yang tidak dapat diakses CPU, alokasi harus mendukung segmen aperture di set segmen yang didukung, atau sudah berada dalam memori sistem (tidak boleh berada di perangkat).

Jika alokasi berhasil dikunci saat alokasi tidak berada di perangkat, tetapi tidak mendukung segmen aperture, alokasi tidak boleh dilakukan ke segmen memori selama durasi kunci.

Lock2 saat ini tidak berisi bendera, dan bit bendera cadangan semuanya harus 0.

CpuHostAperture

Untuk mendukung penguncian dengan lebih baik dengan segmen memori yang tidak dapat diakses CPU saat mengubah ukuran BAR gagal, CpuHostAperture disediakan di bukaan PCI. CpuHostAperture bersifat sebagai manajer berbasis halaman, yang kemudian dapat dipetakan langsung ke wilayah memori video melalui fungsi antarmuka driver perangkat (DDI) DxgkDdiMapCpuHostAperture. VidMm kemudian dapat memetakan berbagai ruang alamat virtual langsung ke rentang CpuHostAperture yang tidak bersebelahan, dan memiliki CpuHostAperture kemudian memetakan ke memori video tanpa perlu rentang yang menggelegar.

Jumlah maksimum memori yang dapat dikunci yang dapat dirujuk CPU dalam segmen memori yang tidak dapat diakses CPU terbatas pada ukuran CpuHostAperture. Detail untuk mengekspos CpuHostAperture ke kernel grafis DirectX dapat ditemukan di bukaan host CPU.

Koherensi I/O

Pada x86/x64 hari ini, semua GPU harus mendukung koherensi I/O melalui PCIe untuk memungkinkan GPU membaca atau menulis ke permukaan memori sistem yang dapat di-cache dan mempertahankan koherensi dengan CPU. Ketika permukaan dipetakan sebagai cache yang koheren dari sudut pandang GPU, GPU perlu mengintip cache CPU saat mengakses permukaan. Bentuk koherensi ini biasanya digunakan untuk sumber daya yang diharapkan dibaca CPU, seperti beberapa permukaan penahapan.

Pada beberapa platform Arm, koherensi I/O tidak didukung langsung dalam perangkat keras. Pada platform ini, koherensi I/O perlu ditiru dengan membatalkan hierarki cache CPU secara manual. VidMm melakukannya dengan melacak operasi ke alokasi yang berasal dari GPU (operasi baca/tulis daftar alokasi) dan CPU (Operasi peta, baca/tulis). VidMm memancarkan invalidasi cache ketika menentukan cache mungkin berisi:

  • Data yang perlu ditulis balik (tulis CPU, baca GPU)
  • Data kedaluarsa yang perlu dibatalkan (tulis GPU, baca CPU).

Pada platform tanpa koherensi I/O, tanggung jawab untuk melacak akses CPU dan GPU ke alokasi jatuh ke UMD. Kernel grafis mengekspos DDI SinggahanTidak Valid baru yang dapat digunakan UMD untuk menulis ulang dan membatalkan rentang alamat virtual yang terkait dengan alokasi yang dapat di-cache. Pada platform yang tidak memiliki dukungan untuk koherensi I/O, UMD diperlukan untuk memanggil fungsi ini setelah CPU menulis dan sebelum GPU membaca serta setelah menulis dan sebelum CPU dibaca. Yang terakhir mungkin tampak tidak intuitif pada awalnya. Tetapi, karena CPU dapat secara spekulatif membaca data sebelum penulisan GPU membuatnya ke memori, perlu untuk membatalkan semua cache CPU untuk memastikan CPU membaca ulang data dari RAM.