Antrean balik perangkat keras

Artikel ini menjelaskan fitur "hardware flip queue" yang didukung mulai dari Windows 11 (WDDM 3.0). 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 penimpaan flip yang belum terselesaikan yang akan ditampilkan pada VSync berikutnya. Driver miniport tampilan (KMD) mengindikasikan dukungan ini melalui nilai MaxQueuedMultiPlaneOverlayFlipVSync dalam DXGK_DRIVERCAPS. Fitur ini berguna untuk mengurangi latensi dalam skenario game frame rate tinggi di mana beberapa bingkai dirender berturut-turut tanpa jeda, bertujuan hanya menampilkan bingkai terbaru.

Dalam skenario pemutaran video, konten beberapa bingkai di masa mendatang yang akan ditampilkan secara berurutan diketahui sebelumnya dan dapat diantrekan ke GPU. Antrean awal ini memungkinkan CPU memasuki status daya rendah saat frame dalam antrean diproses, sehingga mengakibatkan penghematan daya yang signifikan. 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 Flip Perangkat Keras Dasar memperkenalkan solusi yang memungkinkan CPU memasuki keadaan daya rendah dan mengalihkan pemrosesan bingkai yang ada dalam antrean ke GPU.

Dalam skenario game sebelum WDDM 3.0, setelah GPU selesai merender adegan ke buffer belakang rantai swap, ada proses pengiriman ulang ke CPU untuk mengirimkan permintaan untuk menampilkan 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 rendah. Antrean balik perangkat keras tingkat lanjut memerlukan antrean balik perangkat keras dasar dan fungsionalitas penjadwalan perangkat keras GPU tahap 2 untuk hadir.

Antrean flip perangkat keras dasar

Diagram berikut mengilustrasikan kasus penyajian tiga bingkai, masing-masing tetap di layar selama satu interval VSync.

Diagram yang mengilustrasikan tiga frame berada di layar selama 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 memberikan notifikasi kepada OS tentang pergantian tampilan yang telah selesai, dan OS harus mengajukan permintaan pergantian berikutnya. Aplikasi ini juga harus bangun pada setiap VSync dan mengkueri statistik sajian untuk akhirnya mengetahui kapan bingkai terakhir dari tiga bingkai 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-bagian dari GPU beralih ke keadaan daya yang lebih rendah saat pengontrol tampilan memproses beberapa bingkai yang diantrekan. Transisi ini 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 perangkat keras antrean balik, komponen CPU aplikasi dan Dxgkrnl, sepenuhnya tidak aktif selama dua interval VSync antara waktu v2 dan v4, memungkinkan CPU beralih ke mode daya rendah. CPU hanya diberi tahu ketika bingkai N+2 yang diminta oleh aplikasi untuk ditunggu penyelesaiannya telah selesai.

Antrean flip perangkat keras tingkat lanjut

Dalam skenario game sebelum WDDM 3.0, setelah GPU selesai merender adegan ke buffer belakang rantai swap, ada proses pengiriman ulang ke CPU untuk mengirimkan permintaan untuk menampilkan konten bingkai ke layar. Diagram berikut menunjukkan skenario ini.

Diagram yang menggambarkan penyelesaian frame yang memerlukan perjalanan bolak-balik 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 frame yang terlewatkan akibat proses roundtrip CPU yang diperlukan.

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

Diagram yang menampilkan penyelesaian bingkai layar tanpa harus perjalanan ulang CPU.

Sisa artikel ini membahas fitur antrian flip perangkat keras dasar.

Dukungan DDI

DDI berikut ditambahkan untuk mendukung fitur antrean balik perangkat keras.

Memeriksa ketersediaan fitur

Antrian flip perangkat keras membutuhkan negosiasi pengaktifan/pematian 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 tahap pengenalan antrean balik perangkat keras dan tahap uji coba.


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 pemunculan driver, meskipun dimungkinkan untuk mengaktifkan antrean putar balik perangkat keras tanpa mengaktifkan penjadwalan perangkat keras GPU, kombinasi ini tidak didukung secara resmi. Windows saat ini mengharuskan penjadwalan perangkat keras GPU diaktifkan agar antrian pengalihan perangkat keras dasar dapat diaktifkan pada driver yang dirilis secara resmi.

Menunjukkan kemampuan pengantrean 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 tampilan mendukung hingga MaxHwQueuedFlips frame masa depan yang dapat diantrekan untuk ditampilkan pada VidPnSource tertentu di GPU. Sistem operasi menghormati pembatasan yang diberikan oleh pengemudi pada jenis flip yang bisa diantrekan sebelumnya.

HwQueuedFlipCaps juga ditambahkan ke DXGK_DRIVERCAPS. Item ini saat ini dicadangkan untuk penggunaan sistem; pengemudi tidak boleh menggunakannya.

Balikkan waktu target dan format tanda waktu target

Saat sistem operasi mengirimkan permintaan flip ke antrean flip perangkat keras, sistem operasi juga mengirimkan waktu flip target. Flip dapat dibuat terlihat oleh pengguna setelah waktu balik target tercapai.

OS menggunakan unit penghitung jam CPU, yang diperoleh dari KeQueryPerformanceCounter, untuk menyampaikan waktu bingkai target dan menginterpretasikan waktu bingkai aktual.

Mengirimkan antrean flips

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 OutputFlags struktur DXGK_SETVIDPNSOURCEADDRESS_OUTPUT_FLAGS. Untuk detail tentang anggota ini, lihat kasus ulang dan kegagalan DxgkDdiSetVidPnSourceAddressWithMultiPlaneOverlay3.

    • HwFlipQueueDrainNeeded
    • HwFlipQueueDrainAllPlanes
    • HwFlipQueueDrainAllSources

  • Anggota TargetFlipTime ditambahkan. TargetFlipTime menjelaskan waktu balik target di unit QPC. Ketika jam mencapai nilai ini, frame dapat dikirim ke tampilan dengan tetap memperhatikan VSync dan parameter tearing. Di hadapan flip tertunda yang sudah diantrekan, OS menjamin bahwa untuk setiap bidang MPO yang dirujuk oleh permintaan flip, TargetFlipTime lebih besar dari atau sama dengan setiap 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.

DxgkDdiSetVidPnSourceAddressWithMultiPlaneOverlay3 mencoba kembali dan kasus kegagalan

Gagal mengantrekan permintaan ke perangkat keras karena penundaan proses.

Ada beberapa kasus khusus yang mungkin mencegah KMD mengantre permintaan flip saat permintaan flip lainnya tertunda. Dalam kasus seperti itu, KMD harus mengembalikan STATUS_RETRY dari DxgkDdiSetVidPnSourceAddressWithMultiPlaneOverlay3 dan mengatur HwFlipQueueDrainNeeded ke nilai 1. OS akan mencoba mengirimkan permintaan flip lagi setelah semua flip yang tertunda pada plane yang terpengaruh oleh flip selesai dan setelah waktu target tercapai.

Dalam beberapa kasus, perangkat keras tampilan mungkin memerlukan penyelesaian pergantian yang tertunda pada semua bidang, bukan hanya yang direferensikan oleh permintaan pergantian yang masuk. Dalam hal ini, flag HwFlipQueueDrainNeeded dan HwFlipQueueDrainAllPlanes harus diatur ke 1, dan KMD harus mengembalikan STATUS_RETRY.

Demikian pula, perangkat keras tampilan mungkin memerlukan penyelesaian flip tertunda pada semua sumber VidPn untuk melakukan realokasi sumber daya internal. Dalam situasi ini, bendera HwFlipQueueDrainAllSources dan HwFlipQueueDrainNeeded perlu diaktifkan, dan KMD harus mengembalikan STATUS_RETRY.

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

Penting bahwa nilai MaxHwQueuedFlips tetap mencerminkan jumlah maksimal flip perubahan alamat yang hanya 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 karena parameter tidak valid

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

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

Menentukan perilaku interupsi VSync

Untuk mencapai penghematan daya dalam skenario antrean flip, sistem operasi sering menangguhkan gangguan VSync reguler untuk menjaga CPU dalam keadaan daya rendah. Namun, beberapa transisi ditandai sebagai memerlukan interupsi agar aplikasi dapat mengamati kelompok penyajian yang telah selesai dan mengantri tugas selanjutnya. Ada juga kasus ketika aplikasi meminta untuk bangun pada setiap gangguan VSync terlepas dari apakah ada permintaan balik yang tertunda. Dan sebaliknya, pada sistem yang sepenuhnya tidak aktif, interupsi VSync ditangguhkan sampai aktivitas presentasi baru atau pendengar VSync baru muncul.

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

KMD menyediakan penunjuk ke fungsi DxgkDdiSetInterruptTargetPresentId di DRIVER_INITIALIZATION_DATA

OS memanggil DxgkDdiSetInterruptTargetPresentId untuk menentukan target PresentId yang akan mengakibatkan interupsi VSync yang terjadi ketika flip terkait selesai. Fungsi ini dipanggil pada tingkat interupsi perangkat (DIRQL) untuk menyinkronkan dengan DxgkDdiSetVidPnSourceAddress dan interupsi VSync.

Interaksi dengan DxgkDdiControlInterrupt

Ketika gangguan VSync dinonaktifkan sepenuhnya melalui DxgkDdiControlInterrupt/DxgkDdiControlInterrupt2/DxgkDdiControlInterrupt3, mereka tetap dinonaktifkan terlepas dari nilai PresentId target interupsi. KMD harus menyimpan ID target interupsi terbaru yang hadir sehingga dapat dipenuhi ketika VSync diaktifkan lagi.

Ketika interupsi VSync diaktifkan melalui DxgkDdiControlInterruptXxx, ID target present interupsi (pSetInterruptTargetPresentId) menyediakan kontrol lebih rinci seperti berikut:

  • Ketika ID target present diatur ke UINT64_MAX, tidak ada gangguan VSync yang diperlukan ke depannya hingga ID target present tersebut diganti lagi. Interupsi VSync dinonaktifkan, namun KMD harus menerapkan perilaku DXGK_VSYNC_DISABLE_KEEP_PHASE untuk mengaktifkan kembali interupsi.

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

  • Untuk nilai ID yang saat ini berbeda, interupsi terjadi jika PresentId yang tengah dipindai >= InterruptTargetPresentId.

Ketika beberapa lapisan MPO tersedia, gangguan VSync harus dikeluarkan jika salah satu lapisan memerlukannya.

Nonaktifkan VSync 2-Tahap dengan DxgkDdiSetInterruptTargetPresentId

Jika panggilan OS ke DxgkDdiSetInterruptTargetPresentId mengatur InterruptTargetPresentId pada plane yang akan mematikan VSync sepenuhnya pada VidPnSource ini (yaitu, plane ini adalah lapisan terakhir yang mempertahankan VSync, dan sekarang plane ini juga mematikan VSync), KMD harus menonaktifkan interupsi VSync tetapi mempertahankan fase VSync tetap diaktifkan pada perangkat keras (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 nonhardware.

Pembatalan balik antrean

Dalam kasus seperti transisi status layar penuh atau keluar dari aplikasi, operasi tampilan yang sudah dijadwalkan di masa yang akan datang mungkin perlu dibatalkan. Untuk menangani kasus ini, fungsi panggilan balik driver berikut dan struktur terkait diperkenalkan:

KMD menyediakan pointer ke fungsi DxgkDdiCancelFlips dalam DRIVER_INITIALIZATION_DATA.

OS menentukan rentang flip yang dijadwalkan untuk dibatalkan ketika memanggil DxgkDdiCancelFlips, dan KMD melaporkan kembali ke OS rentang flip yang berhasil dibatalkan secara sinkron.

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

  • PresentId N
  • time 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, KMD menentukan bahwa:

  • Balik N+2 sudah dikirim ke perangkat keras tampilan dan tidak dapat dibatalkan pada saat panggilan.
  • Balikkan N+3 dan N+4 dapat dihapus secara sinkron dari antrean balik perangkat keras tanpa efek samping.

Akibatnya, KMD menetapkan PresentIdCancelled ke N+3 dan menyelesaikan N+2 seperti biasa.

OS menandai N+3 dan N+4 sebagai dibatalkan, dan memperlakukan N, N+1, N+2 sebagai sedang dalam penerbangan. Ketika interupsi VSync berikutnya terjadi, 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 terhubung pada berbagai bidang

Flip yang terhubung dikirimkan dengan memanggil DxgkDdiSetVidPnSourceAddress dengan beberapa lapisan dan PresentIds. Kontrak antara OS dan KMD adalah sebagai berikut:

  • Kumpulan pesawat harus diperlihatkan pada VSync yang sama.
  • Perangkat keras tampilan tidak diizinkan untuk hanya menampilkan kelompok bidang tampilan ini pada satu VSync, dan sisanya pada VSync berikutnya.

Dalam model antrian flip perangkat keras, pergantian yang saling mengunci dibatalkan dengan melewati beberapa bidang dan PresentIds dalam panggilan ke DxgkDdiCancelFlips. Sekumpulan pesawat yang diteruskan dalam kasus tersebut harus sesuai dengan permintaan pembalikan yang saling mengunci dan tertunda, dan keputusan KMD mengenai semua PresentId yang saling mengunci harus sama:

  • Jangan batalkan, atau
  • Batalkan secara sinkron

DxgkDdiCancelFlips dipanggil pada tingkat interupsi perangkat (DIRQL) untuk menyinkronkan dengan DxgkDdiSetVidPnSourceAddress dan interrupt VSync.

Mendapatkan statistik saat ini untuk flip antrean

Karena pendekatan antrean flip perangkat keras adalah menghindari mengaktifkan CPU pada setiap VSync, perlu ada mekanisme untuk menyimpan waktu tampilan bingkai untuk beberapa flip yang ada dalam antrean terakhir.

Driver grafis yang mendukung antrean putar balik perangkat keras harus menulis informasi ke buffer log antrean putar balik yang disediakan OS untuk setiap putaran yang selesai atau dibatalkan untuk pesawat MPO tertentu untuk setiap VidPnSource aktif.

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

Setelah satu set flip dalam antrean selesai, KMD harus menjamin bahwa log antrean balik untuk flip yang selesai diperbarui pada salah satu dari dua titik waktu ini yang lebih awal.

  • Pengelola interupsi VSync untuk flip yang memerlukan interupsi untuk diaktifkan.
  • Menanggapi permintaan DxgkDdiUpdateFlipQueueLog eksplisit dari OS.

Ubah urutan log antrean DDI

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 interupsi VSync untuk model antrian flip perangkat keras.

  • Nilai enum DXGK_INTERRUPT_CRTC_VSYNC_WITH_MULTIPLANE_OVERLAY3 ditambahkan sebagai InterruptType.
  • Struktur CrtcVSyncWithMultiPlaneOverlay3 ditambahkan ke penggabungan. Semantik CrtcVSyncWithMultiPlaneOverlay3 mirip dengan struktur CrtcVSyncWithMultiPlaneOverlay2 yang ada, kecuali bahwa daripada satu PresentId terakhir yang selesai 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 pMultiPlaneOverlayVSyncInfo dari CrtcVSyncWithMultiPlaneOverlay3.

Menggunakan diagram contoh Basic hardware flip queue lagi:

Diagram yang menunjukkan mekanisme antrean balik perangkat keras dasar.

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

Setelah konfigurasi bidang tunggal menyelesaikan tiga PresentIds N, N+1, dan N+2 pada masing-masing kali v2, v3, v4, KMD telah menulis tiga entri baru dalam buffer log antrean baliknya dengan indeks 40, 41, dan 42. KMD melaporkan nilai FirstFreeFlipQueueLogEntryIndex 43 dalam struktur CrtcVSyncWithMultiPlaneOverlay3 . OS mengamati bahwa FirstFreeFlipQueueLogEntryIndex berubah dari 40 menjadi 43, dan membaca dari entri log 40, 41, dan 42. KMD perlu mengatur nilai buffer log flip queue 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 flip queue eksplisit

Ada kasus ketika OS perlu mendapatkan informasi tentang batch flip terakhir yang selesai tanpa harus menunggu interupsi VSync. Dalam kasus seperti itu, OS melakukan panggilan eksplisit ke DxgkDdiUpdateFlipQueueLog untuk meminta KMD membaca dari struktur data perangkat keras tampilan miliknya dan menulis informasi balik sebelumnya ke log antrean balik. 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.

Perubahan mode tampilan dan transisi daya di hadapan flip antrean dalam antrean flip perangkat keras

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

Pemetaan permintaan saat ini ke tanda waktu antrean balik perangkat keras

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

OS 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 tanda, Durasi, dan tanda waktu yang diterima oleh KMD.

Semantik pembalikan robek dan tidak robek

Semantik dari tearing flip secara konseptual tetap sama ketika antrean flip 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 bertindak seolah-olah OS mengirimkan flip tepat pada TargetFlipTime dengan flag dan parameter balik yang sama.

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

Dukungan FlipOverwrite dan antrean balik perangkat keras

Antrean balik perangkat keras adalah superset ketat dari fitur flip overwrite yang dikontrol oleh nilai MaxQueuedMultiPlaneOverlayFlipVSync dalam DXGK_DRIVERCAPS.

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

Beberapa kali flip dengan TargetFlipTime yang sudah kedaluwarsa

Ketika ada beberapa flip antrean 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 flip yang telah kedaluwarsa harus dipandang sebagai dibatalkan, dan entri log daftar antrian 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 lapisan. Dalam rilis WDDM 3.1 dan Windows Server 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 saat ini ke TargetFlipTime

Interval pemetaan saat laju penyegaran tetap

Untuk mempertahankan semantik interval saat ini yang ada, OS harus menghitung waktu balik target menggunakan interval saat ini dan laju refresh. Namun, menyetel waktu balik target persis pada waktu VSync yang diharapkan di mana pemutaran harus mengenai layar mengakibatkan terjadi gangguan yang sering. Kerusakan ini disebabkan oleh VSync yang terlewat ketika waktu VSync yang sebenarnya bergeser sedikit. Untuk mencegah gangguan, OS mengurangi setengah dari interval VSync dari waktu pembalikan target yang telah dihitung.

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

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

Interval pemetaan saat ada fitur WDDM 2.9 tingkat penyegaran virtual

Fitur kecepatan refresh virtual mungkin untuk sementara meningkatkan laju refresh tampilan ke kelipatan bilangan bulat dari laju refresh saat ini (yaitu, 24 Hz dapat didorong ke 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 nonmultiple

Ketika laju refresh diubah ke bukan kelipatan dari laju refresh saat ini (misalnya, dari 24 Hz ke 60 Hz), OS perlu memeriksa pergantian di antrean untuk menentukan apakah waktu target yang telah dihitung masih berlaku untuk laju refresh baru. Jika waktu flip target perlu diubah, sistem operasi membatalkan flip yang sedang antre dan mengantrekannya kembali dengan waktu flip target yang baru dihitung.

  • Last updated on