Antrean balik perangkat keras

  • Artikel

Artikel ini menjelaskan fitur antrean balik perangkat keras yang didukung mulai dari Windows 11 (WDDM 3.0). Fitur antrean balik perangkat keras memungkinkan beberapa bingkai di masa mendatang dikirimkan ke antrean pengontrol tampilan. CPU dan bagian GPU dapat beralih ke status daya yang lebih rendah saat pengontrol tampilan memproses beberapa bingkai antrean, meningkatkan efisiensi daya skenario pemutaran video pada perangkat keras yang mampu.

Model antrean balik Pra-WDDM 3.0

Banyak pengontrol tampilan modern mendukung kemampuan untuk mengantrekan beberapa bingkai yang akan ditampilkan secara berurutan. Mulai dari WDDM 2.1, OS mendukung beberapa permintaan timpa balik yang luar biasa yang akan disajikan pada VSync berikutnya. Driver miniport tampilan (KMD) menunjukkan dukungan ini melalui nilai MaxQueuedMultiPlaneOverlayFlipVSync dalam DXGK_DRIVERCAPS. Kemampuan ini berguna untuk mengurangi latensi dalam skenario game kecepatan bingkai tinggi di mana beberapa bingkai dirender secara berurutan dengan interval 0, dengan niat untuk hanya menampilkan bingkai terbaru.

Dalam skenario pemutaran video, konten beberapa bingkai di masa mendatang yang akan ditampilkan secara berurutan diketahui terlebih dahulu dan dapat diantrekan ke GPU. Antrean lanjutan ini memungkinkan CPU memasuki status daya rendah saat bingkai antrean diproses, menghasilkan penghematan daya yang besar. Namun, sebelum WDDM 3.0 tidak ada mekanisme bagi OS untuk mengirimkan lebih dari satu bingkai yang perlu tetap berada di layar untuk setidaknya satu interval VSync tanpa intervensi CPU lebih lanjut. Bagian Antrean balik perangkat keras Dasar memperkenalkan solusi yang memungkinkan CPU memasuki status daya rendah dan pemrosesan bingkai antrean offload ke GPU.

Dalam skenario game sebelum WDDM 3.0, setelah GPU selesai merender adegan ke buffer swap chain back, ada perjalanan pulang pergi ke CPU untuk mengirimkan permintaan untuk menyajikan konten bingkai ke layar. Untuk beban kerja GPU berat yang selesai dekat dengan VSync, perjalanan pulang-pergi ini dapat menyebabkan bingkai tertunda dan melewatkan waktu target yang dimaksudkan, yang mengakibatkan gangguan bingkai yang dapat diamati. Bagian Antrean balik perangkat keras tingkat lanjut memperkenalkan mekanisme untuk menghindari perjalanan pulang pergi CPU ini dan menyajikan bingkai lengkap ke layar dengan latensi yang sangat rendah. Antrean balik perangkat keras tingkat lanjut memerlukan antrean flip perangkat keras dasar dan fungsionalitas penjadwalan perangkat keras GPU tahap 2 untuk hadir.

Antrean balik perangkat keras dasar

Diagram berikut mengilustrasikan kasus menyajikan tiga bingkai, masing-masing tetap berada di layar untuk satu interval VSync.

Diagram yang mengilustrasikan tiga bingkai tetap berada di layar untuk masing-masing satu interval VSync.

Pola isian dalam diagram menunjukkan waktu ketika perangkat lunak Dxgkrnl membalik pemrosesan antrean dan utas aplikasi harus bangun dan melakukan pekerjaan CPU. Pada setiap VSync, pengontrol tampilan harus mengeluarkan pemberitahuan CPU ke OS untuk flip yang telah selesai, dan OS harus mengirimkan permintaan balik berikutnya. Aplikasi ini juga harus bangun pada setiap VSync dan kueri menyajikan statistik untuk akhirnya belajar ketika bingkai terakhir dalam batch tiga ditampilkan.

DDI antrean balik perangkat keras yang dapat mengirimkan beberapa bingkai di masa mendatang ke antrean pengontrol tampilan tersedia mulai dari WDDM 3.0. Seperti yang dinyatakan sebelumnya, mekanisme ini memungkinkan CPU dan bagian GPU beralih ke status daya yang lebih rendah saat pengontrol tampilan memproses beberapa bingkai antrean, meningkatkan efisiensi daya skenario pemutaran video pada perangkat keras yang mampu.

Diagram berikut mengilustrasikan arsitektur yang diusulkan.

Diagram yang menunjukkan mekanisme antrean balik perangkat keras dasar.

Dengan pendekatan antrean balik perangkat keras, komponen CPU aplikasi dan Dxgkrnl sepenuhnya menganggur untuk dua interval VSync antara kali v2 dan v4, memungkinkan CPU memasuki status daya rendah. CPU hanya diberi tahu ketika bingkai N+2 bahwa aplikasi meminta tunggu selesai.

Antrean balik perangkat keras tingkat lanjut

Dalam skenario game sebelum WDDM 3.0, setelah GPU selesai merender adegan ke buffer swap chain back, ada perjalanan pulang pergi ke CPU untuk mengirimkan permintaan untuk menyajikan konten bingkai ke layar. Diagram berikut menunjukkan skenario ini.

Diagram yang menggambarkan penyelesaian bingkai yang memerlukan roundtrip CPU.

Biaya pulang-pergi ini dapat menyebabkan bingkai meleset dari targetnya jika render selesai terlalu dekat dengan VSync, seperti yang ditunjukkan pada diagram berikut.

Diagram yang mengilustrasikan bingkai yang terlewat karena perjalanan pulang pergi CPU yang diperlukan.

Beberapa pengontrol tampilan secara asli mendukung kondisi tunggu yang memungkinkan tampilan mengirimkan permintaan balik setelah GPU selesai merender bingkai tanpa pulang-pergi CPU. Karena antrean balik perangkat keras dapat mengirimkan bingkai N yang baru saja selesai ke layar tanpa roundtrip CPU, hal ini dapat menghindari bingkai yang terlewat seperti yang ditunjukkan pada diagram berikut.

Diagram yang menampilkan penyelesaian bingkai tanpa perlu pulang-pergi CPU.

Sisa artikel ini membahas fitur dasar antrean flip perangkat keras.

Dukungan DDI

DDI berikut ditambahkan untuk mendukung fitur antrean balik perangkat keras.

Memeriksa ketersediaan fitur

Antrean balik perangkat keras memerlukan negosiasi aktifkan/nonaktifkan OS. KMD yang mendukung antrean balik perangkat keras harus terlebih dahulu memanggil DXGKCB_QUERYFEATURESUPPORT selama waktu mulai perangkat dengan FeatureIdDXGK_FEATURE_HWFLIPQUEUE untuk menentukan apakah OS memungkinkan antrean balik perangkat keras diaktifkan.

Antrean balik perangkat keras hanya dapat digunakan jika panggilan balik berhasil dan Aktifkan diatur ke TRUE.

KMD dapat menggunakan kode sampel berikut selama memunculkan antrean flip perangkat keras dan tahap eksperimental.


DXGKARGCB_QUERYFEATURESUPPORT HwFlipQueueEnabledArgs = {};
HwFlipQueueEnabledArgs.DeviceHandle = DeviceHandle;
HwFlipQueueEnabledArgs.FeatureId = DXGK_FEATURE_HWFLIPQUEUE;
HwFlipQueueEnabledArgs.DriverSupportState = DXGK_FEATURE_SUPPORT_EXPERIMENTAL;

if (!NT_SUCCESS(pDxgkInterface->DxgkCbQueryFeatureSupport(&HwFlipQueueEnabledArgs)) ||
    !HwFlipQueueEnabledArgs.Enabled)
{
    // Disable hardware flip queue because the OS didn't allow it.           
}
else
{
    // Enable hardware flip queue because the OS allowed it.
}

Selama pembukaan driver, meskipun dimungkinkan untuk mengaktifkan antrean balik perangkat keras tanpa mengaktifkan penjadwalan perangkat keras GPU, kombinasi ini tidak didukung secara resmi. Windows saat ini memerlukan penjadwalan perangkat keras GPU untuk diaktifkan agar antrean balik perangkat keras dasar diaktifkan pada driver yang dirilis secara resmi.

Menunjukkan kemampuan antrean perangkat keras

MaxHwQueuedFlips ditambahkan ke DXGK_DRIVERCAPS untuk menunjukkan dukungan antrean balik perangkat keras. Jika OS mengizinkan dukungan antrean balik perangkat keras seperti yang dijelaskan sebelumnya, KMD yang mendukung antrean balik perangkat keras harus mengatur MaxHwQueuedFlips ke nilai yang lebih besar dari 1. Ketika MaxHwQueuedFlips lebih besar dari 1, KMD menunjukkan bahwa perangkat keras layar mendukung hingga MaxHwQueuedFlips bingkai masa depan yang dapat diantrekan untuk ditampilkan untuk VidPnSource tertentu pada GPU. OS akan menghormati pembatasan yang disediakan driver pada jenis flip yang dapat diantrekan terlebih dahulu.

HwQueuedFlipCaps juga ditambahkan ke DXGK_DRIVERCAPS. Anggota ini saat ini dicadangkan untuk penggunaan sistem dan tidak boleh digunakan oleh driver.

Balikkan waktu target dan format tanda waktu target

Ketika OS mengirimkan permintaan balik ke antrean balik perangkat keras, OS juga mengirimkan waktu balik target. Flip dapat dibuat terlihat oleh pengguna setelah waktu balik target tercapai.

OS menggunakan unit penghitung jam CPU, yang diperoleh dari KeQueryPerformanceCounter, untuk melewati waktu kerangka target dan menginterpretasikan waktu jangka waktu aktual.

Mengirimkan flip yang diantrekan

Struktur DXGKARG_SETVIDPNSOURCEADDRESSWITHMULTIPLANEOVERLAY3 , yang diteruskan ke fungsi panggilan balik DxgkDdiSetVidPnSourceAddressWithMultiPlaneOverlay3 KMD, dimodifikasi sebagai berikut untuk memungkinkan pengiriman flip yang diantrekan:

  • Tiga anggota berikut ditambahkan ke struktur DXGK_SETVIDPNSOURCEADDRESS_OUTPUT_FLAGSOutputFlags. Lihat kasus coba lagi dan kegagalan DxgkDdiSetVidPnSourceAddressWithMultiPlaneOverlay3 untuk detail tentang anggota ini.

    • HwFlipQueueDrainNeeded
    • HwFlipQueueDrainAllPlanes
    • HwFlipQueueDrainAllSources

  • Anggota TargetFlipTime ditambahkan. TargetFlipTime menjelaskan waktu balik target dalam unit QPC. Ketika jam mencapai nilai ini, bingkai dapat dikirim ke tampilan sambil menghormati VSync dan merobek bendera. Di hadapan flip tertunda yang diantrekan sebelumnya, OS menjamin bahwa untuk setiap bidang MPO yang dirujuk oleh permintaan balik, TargetFlipTime lebih besar dari atau sama dengan salah satu waktu target flip yang tertunda untuk bidang ini. Dengan kata lain, mungkin ada urutan flip dengan tanda waktu yang sama atau meningkat, tetapi tidak mungkin ada urutan yang kembali ke masa lalu.

Kasus coba lagi dan kegagalan DxgkDdiSetVidPnSourceAddressWithMultiPlaneOverlay3

Gagal mengantrekan permintaan ke perangkat keras karena flip yang tertunda

Ada beberapa kasus khusus yang dapat mencegah KMD mengantre permintaan balik sementara permintaan balik lainnya tertunda. Dalam kasus seperti itu, KMD harus mengembalikan STATUS_RETRY dari DxgkDdiSetVidPnSourceAddressWithMultiPlaneOverlay3 dan mengatur HwFlipQueueDrainNeeded sama dengan 1. OS akan mencoba mengirimkan permintaan balik lagi setelah semua flip yang tertunda pada bidang yang terpengaruh oleh flip ini selesai dan setelah waktu target tercapai.

Dalam beberapa kasus, perangkat keras tampilan mungkin memerlukan penyelesaian flip yang tertunda di semua bidang, bukan hanya yang dirujuk oleh permintaan balik masuk. Dalam hal ini, bendera HwFlipQueueDrainNeeded dan HwFlipQueueDrainAllPlanes harus diatur ke 1, dan KMD harus mengembalikan STATUS_RETRY.

Demikian pula, perangkat keras tampilan mungkin memerlukan penyelesaian flip yang tertunda pada semua sumber VidPn untuk merealokasi sumber daya internal, dalam hal ini bendera HwFlipQueueDrainAllSources dan HwFlipQueueDrainNeeded harus diatur, dan KMD harus mengembalikan STATUS_RETRY.

Selain itu, KMD dapat menunjukkan kepada OS apakah pengiriman ulang harus dilakukan di perangkat IRQL (PrePresentNeeded diatur ke 0), atau jika OS harus melakukan panggilan ini di PASSIVE_LEVEL (PrePresentNeeded diatur ke 1). Jika KMD masih mengembalikan STATUS_RETRY meskipun tidak ada lagi flip yang tertunda pada VidPnSourceId tersebut, kondisi ini akan diperlakukan sebagai kegagalan parameter yang tidak valid.

Penting bahwa nilai MaxHwQueuedFlips masih mencerminkan jumlah maksimum flip perubahan hanya alamat sederhana yang dapat diantrekan ke bidang MPO. Mekanisme STATUS_RETRY harus digunakan untuk permintaan balik yang lebih kompleks yang tidak dapat diantrekan secara mendalam, seperti perubahan konfigurasi bidang.

Kegagalan parameter tidak valid

Dalam model antrean balik perangkat keras, penanganan OS terhadap permintaan flip yang gagal dikerjakan ulang untuk memungkinkan debuggabilitas yang lebih baik. Ketika KMD tidak dapat memproses permintaan balik, KMD harus mengembalikan STATUS_INVALID_PARAMETER dari DxgkDdiSetVidPnSourceAddressWithMultiPlaneOverlay3. Bergantung pada pengaturan OS, OS akan melakukan salah satu tindakan berikut:

  • Pemutusan Kernel Debugger dan pemeriksaan bug: Perilaku ini akan sering diaktifkan pada build pengembangan/prarilis untuk hak debuggabilitas yang lebih baik saat kondisi kegagalan terjadi.
  • Live Kernel Dump diikuti oleh TDR: Perilaku pengguna akhir ritel.

Menentukan perilaku interupsi VSync

Untuk mencapai penghematan daya dalam skenario flip yang diantrekan, OS akan sering menangguhkan gangguan VSync reguler untuk menjaga CPU dalam keadaan daya rendah. Namun, beberapa flip akan ditandai sebagai memerlukan interupsi untuk dinaikkan agar aplikasi mengamati batch hadiah yang selesai dan untuk mengantre pekerjaan lebih lanjut. Ada juga kasus ketika permintaan aplikasi bangun pada setiap gangguan VSync terlepas dari apakah ada permintaan balik yang tertunda. Dan sebaliknya, pada sistem yang benar-benar menganggur, gangguan VSync ditangguhkan sampai aktivitas presentasi baru atau listener VSync muncul.

Untuk menangani semua kasus ini, panggilan balik driver dan struktur panggilan balik berikut diperkenalkan:

KMD menyediakan pointer ke fungsi DxgkDdiSetInterruptTargetPresentId di DRIVER_INITIALIZATION_DATA

OS memanggil DxgkDdiSetInterruptTargetPresentId untuk menentukan PresentId target yang seharusnya mengakibatkan gangguan VSync yang dimunculkan ketika flip yang sesuai selesai. Ini disebut pada tingkat interupsi perangkat (DIRQL) untuk disinkronkan dengan DxgkDdiSetVidPnSourceAddress dan gangguan VSync.

Interaksi dengan DxgkDdiControlInterrupt

Ketika gangguan VSync dinonaktifkan sepenuhnya melalui DxgkDdiControlInterrupt/DxgkDdiControlInterrupt2/DxgkDdiControlInterrupt3, mereka tetap dinonaktifkan terlepas dari nilai PresentId target interupsi. KMD diperlukan untuk menyimpan ID ada target interupsi terbaru sehingga dapat dihormati setelah VSync diaktifkan lagi.

Ketika gangguan VSync diaktifkan melalui DxgkDdiControlInterruptXxx, ID target interupsi present (pSetInterruptTargetPresentId) memberikan kontrol berbutir yang lebih halus sebagai berikut:

  • Ketika ID saat ini target diatur ke UINT64_MAX, tidak ada gangguan VSync yang diperlukan ke depannya sampai ID saat ini target diubah lagi. Gangguan VSync dinonaktifkan, tetapi KMD diperlukan untuk menerapkan perilaku DXGK_VSYNC_DISABLE_KEEP_PHASE untuk mengaktifkan kembali gangguan.

  • Ketika ID saat ini target diatur ke 0, gangguan diperlukan untuk setiap VSync.

  • Untuk nilai ID saat ini lainnya, gangguan dinaikkan jika PresentId >yang saat ini dipindai = InterruptTargetPresentId.

Ketika beberapa bidang MPO tersedia, gangguan VSync harus dinaikkan jika salah satu bidang memerlukannya.

Nonaktifkan VSync 2 Tahap dengan DxgkDdiSetInterruptTargetPresentId

Jika panggilan OS ke DxgkDdiSetInterruptTargetPresentId menetapkan InterruptTargetPresentId pada bidang yang akan menyebabkan menonaktifkan VSync sepenuhnya pada VidPnSource ini (yaitu, bidang ini adalah bidang terakhir yang telah mengaktifkan VSync, dan sekarang menonaktifkan VSync juga), KMD harus menonaktifkan gangguan VSync tetapi menjaga fase VSync dalam perangkat keras diaktifkan (DXGK_VSYNC_DISABLE_KEEP_PHASE). Setelah periode waktu tertentu (biasanya setara dengan dua periode VSync), OS akan menindaklanjuti dengan panggilan ke DxgkDdiControlInterruptXxx dengan DXGK_VSYNC_DISABLE_NO_PHASE. Panggilan ini memastikan bahwa KMD mendapatkan kesempatan untuk menonaktifkan fase VSync dan jam VSync untuk menghemat daya maksimum dan untuk mempertahankan paritas performa dengan sistem antrean balik non-perangkat keras.

Pembatalan balik antrean

Dalam kasus seperti transisi status layar penuh atau keluarnya aplikasi, balik antrean di masa mendatang mungkin perlu dibatalkan. Untuk menangani kasus ini, panggilan balik driver berikut dan struktur terkait diperkenalkan:

KMD menyediakan pointer ke fungsi DxgkDdiCancelFlips dalam DRIVER_INITIALIZATION_DATA.

OS menentukan rentang balik antrean untuk dibatalkan ketika memanggil DxgkDdiCancelFlips, dan KMD melaporkan kembali ke OS rentang flip yang dapat dibatalkan secara sinkron.

Contoh berikut menggambarkan mekanisme dan kasus pembatalan balik yang sinkron pada satu bidang. (OS tidak mendukung pembatalan asinkron di Windows 11, versi 22H2.) Bayangkan flip berikut sedang diantrekan ke antrean balik perangkat keras:

  • PresentId N
  • waktu t0 PresentId N+1
  • waktu t1 PresentId N+2
  • time t2 PresentId N+3
  • time t3 PresentId N+4
  • waktu t4

OS kemudian memutuskan untuk membatalkan flip N+2, N+3, dan N+4, sehingga memanggil DxgkDdiCancelFlips dengan PresentIdCancelRequested diatur ke N+2.

Ketika KMD memeriksa status antrean balik perangkat keras, hal ini menentukan bahwa flip N+2 telah dikirim ke perangkat keras tampilan dan tidak dapat dibatalkan pada saat panggilan, tetapi N+3 dan N+4 dapat dihapus secara sinkron dari antrean balik perangkat keras tanpa efek samping. KMD menetapkan PresentIdCancelled ke N+3 dan menyelesaikan N+2 seperti biasa.

OS akan menandai N+3 dan N+4 sebagai dibatalkan, dan akan memperlakukan N, N+1, N+2 sebagai sedang dalam penerbangan. Ketika gangguan VSync berikutnya dinaikkan, log antrean balik akan menunjukkan tanda waktu untuk N, N+1, N+2 seperti biasa.

Rentang flip yang dibatalkan secara sinkron harus berkelanjutan dan, ketika bukan nol, diasumsikan untuk menyertakan ID terakhir yang ada yang dikirimkan ke KMD. Dengan kata lain, tidak ada celah di dalam kedua rentang flip yang dibatalkan secara sinkron.

Membatalkan flip yang saling bertabuh di beberapa bidang

Flip yang saling diblokir dikirimkan dengan memanggil DxgkDdiSetVidPnSourceAddress dengan beberapa bidang dan PresentIds. Kontrak antara OS dan KMD adalah sebagai berikut:

  • Kumpulan bidang harus dibuat terlihat pada VSync yang sama.
  • Perangkat keras tampilan tidak diizinkan untuk hanya menampilkan subset bidang ini pada satu VSync, dan sisanya pada VSync berikutnya.

Dalam model antrean balik perangkat keras, flip yang saling diblokir tersebut dibatalkan dengan melewati beberapa bidang dan PresentId dalam panggilan ke DxgkDdiCancelFlips. Kumpulan bidang yang diteruskan dalam kasus seperti itu harus sesuai dengan permintaan pembatalan yang tertunda, dan keputusan KMD mengenai semua PresentIds yang di-interlock harus sama:

  • Jangan batalkan, atau
  • Batalkan secara sinkron

DxgkDdiCancelFlips dipanggil pada tingkat interupsi perangkat (DIRQL) untuk disinkronkan dengan gangguan DxgkDdiSetVidPnSourceAddress dan VSync.

Mendapatkan statistik saat ini untuk flip yang diantrekan

Karena pendekatan antrean balik perangkat keras adalah untuk menghindari bangun CPU pada setiap VSync, perlu ada mekanisme untuk mempertahankan waktu tampilan bingkai untuk beberapa flip antrean terakhir.

Driver grafis yang mendukung antrean balik perangkat keras diperlukan untuk menulis informasi untuk setiap flip yang selesai atau dibatalkan per bidang MPO tertentu untuk setiap VidPnSource aktif ke buffer log antrean flip yang disediakan oleh OS.

OS menjamin untuk memberikan penunjuk log antrean flip (dalam panggilan ke DxgkDdiSetFlipQueueLogBuffer) sebelum panggilan DxgkDdiSetVidPnSourceAddress pertama untuk bidang MPO tertentu untuk setiap VidPnSource aktif. OS diizinkan untuk menghancurkan buffer log antrean flip ketika antrean flip tidak memiliki permintaan yang luar biasa. Dalam hal ini, ini akan memberikan penunjuk log baru sebelum panggilan DxgkDdiSetVidPnSourceAddress berikutnya. Log antrean balik melingkar. Setelah entri [NumberOfEntries-1] ditulis, entri log berikutnya adalah [0].

Setelah batch flip yang diantrekan selesai, KMD harus menjamin bahwa log antrean balik untuk flip yang selesai diperbarui paling awal dari dua titik waktu ini:

  • Handler interupsi VSync untuk flip yang memerlukan interupsi untuk dinaikkan.
  • Menanggapi permintaan DxgkDdiUpdateFlipQueueLog eksplisit dari OS.

Balikkan DDIs log antrean

Panggilan balik terkait log antrean balik dan struktur terkait berikut ditambahkan:

KMD menyediakan penunjuk ke fungsinya dalam DRIVER_INITIALIZATION_DATA.

Pembaruan struktur interupsi VSync

Perubahan berikut dilakukan pada struktur DXGKARGCB_NOTIFY_INTERRUPT_DATA untuk mengimplementasikan gangguan VSync untuk model antrean balik perangkat keras:

  • Nilai enum DXGK_INTERRUPT_CRTC_VSYNC_WITH_MULTIPLANE_OVERLAY3 ditambahkan sebagai InterruptType.
  • Struktur CrtcVSyncWithMultiPlaneOverlay3 ditambahkan ke union. Semantik CrtcVSyncWithMultiPlaneOverlay3 mirip dengan struktur CrtcVSyncWithMultiPlaneOverlay2 yang ada, kecuali bahwa alih-alih satu PresentId terakhir yang diselesaikan untuk setiap bidang, CrtcVSyncWithMultiPlaneOverlay3.pMultiPlaneOverlayVSyncInfo menunjuk ke rentang PresentId yang sebelumnya tidak dilaporkan dari log antrean flip.
  • Struktur DXGK_MULTIPLANE_OVERLAY_VSYNC_INFO3 ditambahkan untuk anggota pMultiPlaneOverlayVSyncInfoCrtcVSyncWithMultiPlaneOverlayVSyncInfo.

Menggunakan diagram contoh antrean balik perangkat keras Dasar lagi:

Diagram yang menunjukkan mekanisme antrean balik perangkat keras dasar.

Asumsikan FirstFreeFlipQueueLogEntryIndex diatur ke 40 pada saat flip N dikirimkan lalu N, N+1, N+2 presentasi selesai.

Setelah konfigurasi bidang tunggal menyelesaikan tiga PresentIds N, N+1, dan N+2 pada waktu masing-masing v2, v3, v4, KMD akan menulis tiga entri baru dalam buffer log antrean baliknya dengan indeks 40, 41, dan 42. KMD melaporkan nilai FirstFreeFlipQueueLogEntryIndex 43 dalam struktur CrtcVSyncWithMultiPlaneOverlay3 . OS akan mengamati bahwa FirstFreeFlipQueueLogEntryIndex berubah dari 40 menjadi 43, dan akan membaca dari entri log 40, 41, dan 42. KMD perlu mengatur nilai buffer log antrean balik berikut sebagai berikut:

  • VidPnTargetId: arti yang sama seperti dalam CrtcVSyncWithMultiPlaneOverlay2

  • PhysicalAdapterMask: arti yang sama seperti dalam CrtcVSyncWithMultiPlaneOverlay2

  • MultiPlaneOverlayVSyncInfoCount = 1

  • pMultiPlaneOverlayVSyncInfo[0]. LayerIndex = 0

  • pMultiPlaneOverlayVSyncInfo[0]. FirstFreeFlipQueueLogEntryIndex = 43

  • LogBufferAddressForPlane0[40]. PresentId = N

  • LogBufferAddressForPlane0[40]. PresentTimestamp = v2

  • LogBufferAddressForPlane0[41]. PresentId = N+1

  • LogBufferAddressForPlane0[41]. PresentTimestamp = v3

  • LogBufferAddressForPlane0[42]. PresentId = N+2

  • LogBufferAddressForPlane0[42]. PresentTimestamp = v4

Permintaan pembaruan log antrean balik eksplisit

Ada kasus ketika OS perlu mendapatkan informasi tentang batch flip terakhir yang diselesaikan tanpa harus menunggu gangguan VSync. Dalam kasus seperti itu, OS melakukan panggilan eksplisit ke DxgkDdiUpdateFlipQueueLog untuk meminta KMD membaca dari struktur data perangkat keras tampilan kepemilikannya dan menulis informasi balik sebelumnya ke log antrean flip. Semantik log sama seperti yang dijelaskan sebelumnya; satu-satunya perubahan adalah firstFreeFlipQueueLogEntryIndex dikembalikan ke OS di luar gangguan VSync.

DxgkDdiUpdateFlipQueueLog dipanggil pada tingkat interupsi perangkat (DIRQL), dan berada di kelas sinkronisasi yang sama dengan DxgkDdiSetVidPnSourceAddressWithMultiPlaneOverlay3 DDI.

Tampilkan perubahan mode dan transisi daya saat ada flip antrean dalam antrean balik perangkat keras

Dxgkrnl akan memastikan bahwa flip yang sudah diantrekan dalam antrean flip perangkat keras selesai atau dibatalkan sebelum memulai perubahan mode atau mematikan monitor.

Pemetaan Ada permintaan ke tanda waktu antrean balik perangkat keras

Ketika antrean balik perangkat keras diaktifkan pada adaptor tertentu, semua panggilan balik akan disertai dengan tanda waktu. Dengan kata lain, KMD tidak perlu menangani campuran semantik DxgkDdiSetVidPnSourceAddress lama dan baru.

OS akan secara otomatis mengonversi permintaan Present API berbasis interval yang ada menjadi panggilan balik berbasis tanda waktu ke KMD. Bagian berikut membahas berbagai kasus dan bagaimana mereka dipetakan ke kombinasi bendera, Durasi, dan tanda waktu yang diterima oleh KMD.

Semantik flip yang merobek dan tidak merobek

Semantik flip yang merobek secara konseptual sama ketika antrean balik perangkat keras diaktifkan. Setelah TargetFlipTime tercapai, KMD harus mengirimkan flip untuk ditampilkan sambil tetap menghormati bendera seperti FlipImmediate, FlipImmediateNoTearing, dan FlipOnNextVSync. Dengan kata lain, KMD harus berperilaku seolah-olah OS mengirimkan flip ke persis di TargetFlipTime dengan bendera dan parameter balik yang sama.

Misalnya, jika FlipOnNextVSync diatur ke 1 dan TargetFlipTime berada di tengah bingkai, flip ini hanya boleh ditampilkan pada VSync berikutnya.

Dukungan FlipOverwrite dan antrean balik perangkat keras

Antrean balik perangkat keras adalah superset ketat dari fitur timpa balik yang dikendalikan oleh nilai MaxQueuedMultiPlaneOverlayFlipVSync dalam DXGK_DRIVERCAPS.

Oleh karena itu, OS mengabaikan nilai MaxQueuedMultiPlaneOverlayFlipVSync jika driver memilih antrean balik perangkat keras dengan mengatur MaxHwQueuedFlips ke nilai yang lebih besar dari 1.

Beberapa flip dengan TargetFlipTime yang kedaluwarsa

Ketika ada beberapa flip yang diantrekan dengan TargetFlipTime yang kedaluwarsa untuk bidang MPO tertentu, antrean tampilan perangkat keras harus memilih flip kedaluwarsa yang paling baru diantrekan dan mengirimkannya ke tampilan. Sisa balik yang kedaluwarsa harus diperlakukan sebagai dibatalkan, dan entri log antrean balik yang sesuai untuk mereka harus berisi DXGK_HWFLIPQUEUE_TIMESTAMP_CANCELLED sebagai nilai PresentTimestamp .

Interaksi antara Durasi dan TargetFlipTime

Parameter Durasi dalam struktur DXGKARG_SETVIDPNSOURCEADDRESSWITHMULTIPLANEOVERLAY3 harus berlaku ketika flip yang ditentukan dalam struktur ini ditampilkan di layar. Ini menentukan perilaku laju refresh tampilan baru yang diinginkan untuk output yang ditentukan oleh VidPnSourceId di semua bidang. Dalam rilis WDDM 3.1 dan Windows 2022, untuk menyederhanakan implementasi driver untuk perangkat keras yang tidak mendukung perubahan Durasi kustom yang diantrekan, OS hanya mengirimkan permintaan balik dengan parameter Durasi baru setelah permintaan balik sebelumnya selesai.

Pemetaan Interval Sajikan ke TargetFlipTime

Interval pemetaan saat laju refresh diperbaiki

Untuk mempertahankan semantik interval saat ini yang ada, OS harus menghitung waktu balik target menggunakan interval saat ini dan laju refresh. Namun, mengatur waktu balik target persis ke waktu VSync yang dimaksudkan di mana flip harus mengenai layar akan mengakibatkan gangguan yang sering terjadi karena VSync yang terlewat jika waktu VSync yang sebenarnya menyimpang sedikit. Untuk menjaga dari gangguan, OS mengurangi setengah dari interval VSync dari waktu balik target yang dihitung.

Berikut adalah rumus yang disederhanakan untuk memetakan interval saat ini ke waktu balik target:

TargetFlipTime = PreviousFlipStartVSyncTime + (PreviousFlipPresentInterval * FixedRefreshRate) - (FixedRefreshRate / 2)

Interval pemetaan saat fitur WDDM 2.9 kecepatan refresh virtual ada

Fitur laju refresh virtual dapat meningkatkan laju refresh tampilan untuk sementara waktu ke kelipatan bilangan bulat dari laju refresh saat ini (yaitu, 24 Hz dapat didorong hingga 144 Hz atau 192 Hz). Untuk perangkat yang mampu mendukung peningkatan ini, rumus di bagian sebelumnya dimodifikasi untuk menggunakan kelipatan tercepat dari kecepatan refresh saat ini:

TargetFlipTime = PreviousFlipStartVSyncTime + (PreviousFlipPresentInterval * FixedRefreshRate) - (FastestRefreshRate / 2)

Interval pemetaan saat laju refresh diubah ke non-multi

Ketika laju refresh diubah ke non-kelipatan laju refresh saat ini (misalnya, dari 24 Hz hingga 60 Hz), OS harus memeriksa flip antrean untuk melihat apakah waktu target yang dihitung masih valid mengingat kecepatan refresh baru. Jika waktu balik target perlu diubah, OS akan membatalkan pembalikan antrean dan mengantrekannya kembali dengan waktu balik target yang baru dihitung.