Pengalih layar otomatis

Penting

Beberapa informasi berkaitan dengan produk prarilis yang mungkin dimodifikasi secara substansial sebelum dirilis secara komersial. Microsoft tidak memberikan jaminan, tersurat maupun tersirat, sehubungan dengan informasi yang diberikan di sini.

Artikel ini menjelaskan fitur sakelar tampilan otomatis (ADS) yang menyediakan dukungan agar panel internal laptop dialihkan dengan mulus antara GPU (iGPU) terintegrasi dan GPU diskret (dGPU). ADS adalah fitur WDDM opsional, didukung mulai Windows 11, versi 24H2 pembaruan 2025.01D (WDDM 3.2).

Dalam artikel ini:

GPU0 mengacu pada GPU yang saat ini terhubung dengan panel terintegrasi.
GPU1 mengacu pada GPU yang menjadi target pengalihan panel.

Ikhtisar

Beberapa laptop yang dirilis memiliki perangkat multiplexer (mux) yang memungkinkan panel internal dialihkan antara GPU terintegrasi (iGPU) dan GPU diskrit (dGPU). Driver grafis saat ini memicu dan melakukan peralihan pada laptop ini tanpa campur tangan sistem operasi, yang mengarah ke beberapa pengalaman pengguna yang tidak diinginkan.

ADS memungkinkan OS mengontrol penggunaan perangkat mux dalam sistem untuk beralih antara iGPU dan dGPU saat memindai ke panel internal. Oleh karena itu, OS dapat memberikan pengalaman pengguna yang lebih baik.

Versi awal ADS hanya mendukung pengalihan panel internal antara iGPU dan dGPU. Di masa depan, fitur ini mungkin diperluas untuk mendukung muxing konektor eksternal di laptop juga.

Desain tingkat tinggi

Secara umum, sistem harus memastikan konten panel internal ditampilkan tanpa gangguan visual saat transisi sedang berlangsung. OS tidak membatasi fungsionalitas ini ke protokol tampilan tertentu. Artikel ini berfokus pada cara menerapkan ADS dengan eDP, tetapi ada lebih banyak standar industri yang dapat digunakan (misalnya, MIPI atau DSI). Desain platform gratis untuk menggunakan protokol koneksi tampilan lain jika mereka dapat mencapai pengalaman yang sama tanpa perubahan OS lainnya.

Subbagian dalam bagian ini mengidentifikasi aspek desain fitur dan merinci pendekatan tingkat tinggi untuk setiap aspek.

Kontrol perangkat mux

Untuk mengurangi dependensi antara driver grafis iGPU dan dGPU, mux diekspos sebagai perangkat terpisah yang dapat dikontrol OS secara independen dari driver grafis. Keuntungan dari pendekatan ini adalah:

Ini mengurangi kompleksitas driver grafis karena driver tidak perlu tahu cara mengontrol setiap mux berbeda yang mungkin digunakan OEM.
Ini mengurangi atau menghilangkan dependensi antara driver grafis, yang pada gilirannya mengurangi pembaruan driver dan memudahkan OEM untuk memilih GPU dan multiplexer.
OS dapat mengalihkan mux saat driver grafis tidak tersedia.

Mengekspos perangkat mux

Karena solusi ini untuk muxing antara iGPU internal dan dGPU, masuk akal untuk mengekspos mux melalui ACPI.

Fungsi driver mux

Driver mux harus memenuhi persyaratan fungsional tingkat tinggi berikut:

Ini harus memberikan status mux, target mana yang saat ini mengontrol panel internal, dan batas kemampuan apa pun.
Ini harus menyediakan cara untuk memicu sakelar dan melaporkan status sakelar.

Untuk informasi selengkapnya tentang perangkat ACPI mux dan metodenya, lihat ACPI.

Untuk melakukan peralihan yang lancar, perangkat mux memerlukan kondisi berikut setiap saat selama perpindahan GPU terjadi.

Daya listrik panel Setiap saat, mux membutuhkan kekuatan panel yang harus disediakan oleh salah satu GPU. Tidak apa-apa untuk memiliki kedua GPU menyediakan daya panel secara bersamaan.
Sinyal kontrol yang dipengaruhi kecerahan dari kedua GPU saat berpindah.
Tingkat kecerahan (modulasi lebar pulsa) dari kedua GPU saat berganti.

Mux mengalihkan informasi berikut antara dua GPU dan panel:

Sinyal pengendalian kecerahan
Tingkat kecerahan (modulasi lebar pulsa)
Jalur Aux DisplayPort (DP)
Garis deteksi hot plug (HPD)
Jalur data DP

Mux harus memiliki kemampuan untuk beralih ketika panel tidak aktif. Setidaknya, untuk pengalihan panel internal, mux tidak boleh memicu sinyal HPD apa pun ke GPU saat mengalihkan.

Driver GPU seharusnya tidak pernah memanggil metode-metode ACPI mux.

DDI sakelar tampilan otomatis

Beberapa DDI telah ditambahkan untuk memenuhi persyaratan multiplexer. Ada lima titik berbeda di mana OS memanggil DDI dari driver selama switch mux, menggunakan fungsi berikut. Berbagai panggilan tergantung pada tahapan sakelar dan apakah driver mengontrol GPU yang saat ini memiliki kontrol atas tampilan.

DDI	Deskripsi
DxgkDdiDisplayMuxPreSwitchAway	Hubungi driver yang saat ini tersambung ke tampilan. Panggilan ini memberi tahu driver bahwa sistem berencana untuk mengalihkan layar ke GPU lain (dari GPU0 ke GPU1).
DxgkDdiDisplayMuxPreSwitchAwayGetPrivateData	Panggil untuk mengumpulkan data sakelar privat apa pun dari driver yang saat ini terhubung ke panel (dari GPU0).
DxgkDdiDisplayMuxPreSwitchTo	Panggilan ke sopir yang saat ini tidak terhubung ke layar. Panggilan ini memberi tahu driver bahwa OS berencana untuk mengalihkan tampilan ke GPU ini (ke GPU1).
DxgkDdiDisplayMuxSwitchCanceled	Memberitahu pengemudi bahwa urutan sakelar dibatalkan sebelum sakelar selesai.
DxgkDdiDisplayMuxPostSwitchAway	Saklar mux telah selesai dan driver GPU0 tidak lagi terhubung ke layar.
DxgkDdiDisplayMuxPostSwitchToPhase1	Proses pengalihan mux telah selesai dan driver GPU1 sekarang terhubung ke layar. Driver ini sekarang harus melakukan tugas fase 1.
DxgkDdiDisplayMuxPostSwitchToPhase2	Proses pengalihan mux sudah selesai dan driver GPU1 sekarang terhubung ke layar. Driver ini sekarang harus melakukan tugas fase 2.
DxgkDdiDisplayMuxUpdateState	Dipanggil ketika adaptor mulai beroperasi untuk kembali ke status daya D0 guna memberi tahu driver status mux saat ini.

Ada tindakan eksplisit yang perlu diselesaikan driver pada setiap tahap. Tindakan ini dijelaskan nanti dalam artikel ini.

Untuk daftar lengkap pembaruan DDI yang terkait dengan ADS, lihat perubahan DDI WDDM untuk pengalihan layar otomatis.

Mungkin ada kasus di mana pengalaman pengguna yang lebih baik dapat dibangun ketika:

GPU0 dan GPU1 berasal dari IHV yang sama.
GPU0 dapat meneruskan informasi ke GPU1 mengenai konfigurasi tampilan yang tidak terlihat oleh OS.

Blob data dijelaskan oleh GUID yang dapat diidentifikasi dengan cepat oleh driver GPU1 jika memahami blob data. Pada tingkat tinggi, OS memanggil GPU0 untuk mendapatkan GUID blob dan data sebelum saklar, kemudian meneruskannya ke GPU1 sebelum diminta untuk melakukan HPD di layar.

Driver GPU1 bertanggung jawab untuk:

Memeriksa bahwa sistem memahami GUID dari blob.
Memvalidasi setiap elemen data dalam blob untuk menghindari efek berbahaya dari data yang salah bentuk dalam blob.

Interoperabilitas driver

Jika driver WDDM mendukung ADS, driver perlu mendukung ADS apa pun sistem OEM yang dijalankannya atau apa GPU lain pada sistem.

Urutan pengalih

Meskipun secara teknis mungkin untuk beralih dari GPU ketika driver GPU tersebut dihentikan, skenario ini saat ini tidak didukung. Oleh karena itu, peralihan hanya dilakukan ketika kedua GPU memiliki driver yang sudah dimuat yang mendukung pengalihan DDI.

Urutan berikut adalah tampilan tingkat tinggi dari seluruh urutan sakelar ketika panel aktif, di mana GPU0 dan GPU1 mewakili iGPU dan dGPU, masing-masing. GPU0 saat ini terhubung ke panel internal melalui mux dan kami ingin mengalihkan ke GPU1 untuk menampilkan pada panel.

Panggilan pengalihan dilakukan di tingkat API.
OS mengumpulkan atribut status panel internal saat ini (HDR, mode, laju refresh, dan sebagainya) dan memeriksa mode tampilan sementara.
OS menonaktifkan melakukan topologi tampilan apa pun karena HPD dari GPU apa pun dalam sistem.
OS memanggil driver GPU1 DxgkDdiDisplayMuxPreSwitchTo, melewati tingkat kecerahan saat ini. Driver harus melakukan hal berikut hanya jika tutupnya terbuka:
- Hidupkan aliran listrik ke panel.
- Atur sinyal yang mengaktifkan kecerahan.
- Atur tingkat kecerahan yang dilewati OS.
OS menonaktifkan panggilan DxgkDdiQueryConnectionChange pada GPU0 untuk memastikan bahwa penutup HPD tidak dapat diproses hingga setelah perubahan sakelar mux.
OS memanggil driver GPU0 DxgkDdiDisplayMuxPreSwitchAway DDI. Pengemudi harus:
- Jika tutup berfungsi, aktifkan PSR1 (penyegaran mandiri panel 1) pada panel dan pastikan PSR1 tetap aktif hingga OS meminta penonaktifan dalam urutan selanjutnya.
- Tambahkan paket ke daftar perubahan koneksinya dengan DXGK_CONNECTION_CHANGEyang memiliki ConnectionStatus diatur ke MonitorStatusDisconnected dan MonitorConnect.MonitorConnectFlags.DisplayMuxConnectionChange diatur ke 1.
- GPU0 tidak dapat menambahkan paket perubahan koneksi untuk target tutup ke dalam antreannya. Bug OS memeriksa apakah sistem operasi melakukannya.
- Mengembalikan ukuran blob data privat ADS (GUID dan data) apa pun ke sistem operasi. Jika driver GPU0 gagal dalam panggilan ini, driver perlu memastikan paket status koneksi ADS apa pun yang ditempatkannya ke dalam antrean dihapus sebelum kembali.
Jika driver GPU0 mengembalikan ukuran data privat nonzero, OS mengalokasikan ukuran tersebut dan meneruskannya ke GPU0 DxgkDdiDisplayMuxPreSwitchAwayGetPrivateData panggilan balik untuk mendapatkan data sakelar privat.
Sistem Operasi memanggil metode ACPI dari mux untuk beralih dari GPU0 ke GPU1.
OS memungkinkan DxgkDdiQueryConnectionChange GPU0 dipanggil lagi.
OS memanggil GPU0 DxgkDdiQueryConnectionChanges untuk memproses paket koneksi MonitorStatusDisconnected dengan DisplayMuxConnectionChange diatur ke 1.
OS memanggil DxgkddiSettimingsfromvidpn GPU0 untuk menonaktifkan jalur tampilan yang sedang dialihkan. Driver dari GPU0 harus:
- Matikan daya panel.
- Nonaktifkan sinyal kecerahan.
- Berhenti mengirim tingkat kecerahan ke mux.
OS memproses penutupan layar. Ini tidak memicu perubahan topologi untuk menghindari perubahan topologi yang tidak perlu.
OS memanggil fungsi balik milik GPU1 DxgkDdiDisplayMuxPostSwitchToPhase1, menyampaikan blob privat ADS apa pun yang diperoleh dari GPU0. Pengemudi harus:
- Tentukan apakah tutupnya terbuka atau tertutup.
- Tambahkan paket ke daftar perubahan koneksinya dengan DXGK_CONNECTION_CHANGE:
  - MonitorConnect.MonitorConnectFlags.DisplayMuxConnectionChange bit disetel.
  - ConnectionStatus diatur ke MonitorStatusConnected jika tutup terbuka atau MonitorStatusDisconnected jika tutup ditutup.
- Jika penutup tertutup, matikan daya dan sinyal aktivasi kecerahan ke panel.
Jika OS belum memanggil DxgkDdiQueryAdapterInfo dengan DXGKQAITYPE_INTEGRATED_DISPLAY_DESCRIPTOR2 untuk target internal GPU1, OS akan melakukannya. Sebagai hasil dari panggilan ini, OS juga memanggil DxgkDdiQueryDeviceDescriptor.
OS memanggil GPU1 DxgkDdiQueryConnectionChange untuk memproses peristiwa tersebut dalam daftar perubahan koneksinya. Panggilan ini menghasilkan DxgkDdiQueryDeviceDescriptor dipanggil untuk monitor baru yang di-HPD.
OS memungkinkan perubahan topologi tampilan karena HPD.
OS akan memproses paket koneksi secara asinkron dari GPU0 dan GPU1 dengan DisplayMuxConnectionChange diatur ke 1.
Jika GPU1 mengantre MonitorStatusConnected:
- OS memanggil fungsi DWM GPU1 untuk menghitung mode.
- DxgkddiSettimingsfromvidpn dipanggil pada GPU1 untuk mengaktifkan jalur tampilan.
- DWM merender dan menyajikan bingkai ke jalur tampilan pada GPU1.
- OS menunggu bingkai pertama dibuat terlihat.
OS memanggil callback DxgkDdiDisplayMuxPostSwitchToPhase2 pada GPU1, tempat driver mematikan PSR1 pada tampilan jika MonitorStatusConnected diantrekan oleh GPU1; jika tidak, tidak perlu melakukan apapun.
OS memanggil DxgkDdiDisplayMuxPreSwitchAway GPU0. Meskipun tidak ada tindakan yang diharapkan dari pengandar, panggilan ini berguna untuk pembersihan atau pembukuan pengandar yang terkait dengan peralihan.
OS mengumpulkan atribut dari status panel internal saat ini. Jika status panel berbeda dari apa yang disimpan sebelumnya, OS akan memicu telemetri.

Urutan sakelar ini sama untuk iGPU->dGPU dan dGPU->iGPU. Mungkin ada kasus untuk mengubah mux ketika panel tidak aktif. Dalam hal ini, urutan ini tidak diperlukan dan OS hanya dapat memanggil metode ACPI pada mux untuk beralih.

Sebagian besar OS tidak tahu driver berada dalam mode PSR. Akibatnya, driver masih perlu menghasilkan sinkronisasi Vsync, melaporkan flip selesai, dan sebagainya, meskipun pengguna tidak melihat hal ini terjadi.

Proses pemulihan

Jika kegagalan terjadi selama tahap urutan sakelar apa pun, pembersihan berikut dilakukan:

OS memanggil GPU0's DxgkDdiDisplayMuxSwitchCanceled jika GPU0's DxgkDdiDisplayMuxPreSwitchAway berhasil dipanggil tetapiDxgkDdiDisplayMuxPostSwitchAway belum dipanggil.
OS memanggil DxgkDdiDisplayMuxSwitchCanceled dari GPU1 jika DxgkDdiDisplayMuxPreSwitchTo berhasil dipanggil tetapi DxgkDdiDisplayMuxPostSwitchToPhase2 belum dipanggil.
OS mengaktifkan kembali perubahan topologi tampilan jika dinonaktifkan.
OS mengaktifkan kembali panggilan DxgkDdiQueryConnectionChange pada GPU0 jika dinonaktifkan.
OS memeriksa konektivitas tutup pada GPU yang terhubung dengan tutup tersebut.
OS mengaktifkan pengaturan ulang konfigurasi tampilan (SDC). Driver yang memiliki panel terhubung melalui mux (yang dikembalikan dari DxgkDdiDisplayMuxSwitchCanceled) perlu memastikan bahwa PSR dinonaktifkan.

Peristiwa tidak biasa yang dapat terjadi selama pengalihan

User menghubungkan atau mencabut monitor eksternal

Sebagai bagian dari rangkaian pengalihan, kami menonaktifkan pemrosesan peristiwa HPD oleh OS. Dengan cara ini, HPD apa pun diantrekan dan diproses bersamaan dengan kedatangan tutup dalam satu operasi atomik.
Aplikasi lain memanggil SDC selama pengalihan

Saat pergantian sakelar berlangsung, panggilan ke SDC ditahan dan akan dieksekusi setelah pergantian tersebut selesai.
Driver dinonaktifkan selama penggantian

Ketika driver dihentikan, panggilan dalam urutan pemindahan gagal, dan urutan pemulihan diaktifkan. Bagian PnPStop juga merinci bagaimana ia memastikan layar selalu terlihat.

Skenario penutupan tutup

Driver umumnya dapat menggunakan salah satu pendekatan berikut untuk mendeteksi peristiwa buka/tutup tutup:

Lacak status penutup dalam DxgkDdiNotifyAcpiEvent(DxgkPowerStateEvent, PO_CB_LID_SWITCH_STATE)
Lacak status penutup dari fungsi callback PoRegisterPowerSettingCallback(GUID_LIDSWITCH_STATE_CHANGE).
Cara yang berbeda, tergantung pada platform.

Namun, untuk WDDM secara umum, driver harus menggunakan pendekatan DxgkDdiNotifyAcpiEvent karena memungkinkan status Dxgkrnl dan status driver untuk sinkron. Mengingat bahwa iGPU dan dGPU dapat menjadi GPU1 dalam suatu urutan pergantian, masuk akal bagi semua driver ADS untuk mengawasi status penutup bahkan ketika penutup tersebut dialihkan dari driver tersebut.

Setelah OS memproses peristiwa DisplayMuxConnectionChange dari GPU0, GPU0 menganggap bahwa GPU0 tidak memiliki status tutup lagi dan oleh karena itu GPU0 tidak dapat melaporkan paket status koneksi lagi untuk target tersebut sampai tutupnya dialihkan kembali. Jika GPU0 melakukannya, OS akan memeriksa bug. Setelah OS memproses DisplayMuxConnectionChange dari GPU1, OS menganggap GPU1 sebagai pemilik status penutup. Setiap peristiwa buka atau tutup tutup boleh diabaikan di antara kedua peristiwa tersebut karena GPU1 diharapkan mengetahui keadaan tutup dan melaporkan paket DisplayMuxConnectionChange yang benar.

Saat OS menganggap bahwa driver menguasai panel

Tabel berikut menjelaskan tahapan urutan di mana OS mempertimbangkan GPU untuk memiliki panel. GPU pemilik dapat melaporkan perubahan konektif menggunakan urutan sakelar. Nomor langkah berasal dari urutan sakelar yang dijelaskan sebelumnya.

Tahap dari	Tahap ke	GPU mana yang mengontrol panel
Sebelum beralih	Langkah 5	GPU0
Langkah 6	Langkah 12	Tidak ada GPU
Langkah 13	Setelah penggantian	GPU1

Bug OS memeriksa apakah ada paket perubahan koneksi dalam antrean driver untuk target yang telah dimultiplex ketika GPU tidak mengendalikan panel.

Mengendalikan penyegaran mandiri pada panel (PSR)

Fitur ADS menggunakan PSR untuk menghindari gangguan selama transisi. Secara khusus, PSR1 (mode pembaruan layar penuh) digunakan sehingga GPU0 dan GPU1 tidak perlu menegosiasikan mode PSR mana yang akan digunakan.

Bahkan dalam PSR1, ada fitur opsional yang perlu didukung panel:

Kapabilitas Sink	Detail	Washtafel diekspos melalui
DPCD & versi eDP	Mengekspos eDP v1.3 atau lebih tinggi.	DPCD
Kemampuan dan Versi PSR	Sink akan mendukung versi 1.	DPCD 00070h bit 7:0
Mendukung VSC SDP untuk menyampaikan status PSR	Hanya untuk PSR; sink harus mendukung setidaknya revisi 2 dengan hingga 8 byte yang valid untuk menyampaikan status PSR dan nilai CRC.	DPCD 170
Sink harus melaporkan status terkait PSR dengan benar	Sink akan mengekspos status; misalnya, kesalahan CRC tautan, kesalahan penyimpanan RFB, status refresh mandiri perangkat sink, jumlah bingkai sinkronisasi ulang maksimum, latensi sinkronisasi aktual terakhir di perangkat sink, dan PSR SDP yang terakhir diterima.	DPCD 2008h, 2009h, 200Ah akan mencerminkan keadaan wastafel yang benar.

Ketika GPU1 melakukan pelatihan tautan sebagai bagian dari DxgkddiSettimingsfromvidpn panggilan dari OS, driver tidak tahu pengaturan jalur DP dan bandwidth yang digunakan oleh GPU0 sehingga harus melakukan urutan pelatihan tautan penuh daripada pelatihan tautan cepat. OS tidak akan menegosiasikan kebijakan PSR apa pun antara GPU, sehingga panel perlu mendukung semua versi dan fitur PSR yang akan digunakan GPU. Misalnya, panel harus mendukung skenario di mana GPU0 mungkin menggunakan PSR2 dengan beberapa fitur tertentu, lalu PSR1 akan digunakan untuk peralihan, kemudian GPU1 mungkin menggunakan PSR2 dengan serangkaian fitur yang berbeda.

Memastikan panel tetap berada di PSR selama pengalihan

Ketika GPU1 mengatur mode pada panel, tidak ada jaminan bahwa atribut tautan yang ditetapkan oleh GPU1 saat panel berada di PSR akan cocok dengan mode entri PSR. Misalnya, laju refresh atau ukuran aktif mungkin berubah. Saat ini, DP atau standar industri lainnya tidak memiliki cara untuk panel melaporkan bahwa ia dapat mempertahankan panel dalam PSR saat atribut tautan diubah. Jangka panjang, kami ingin bekerja untuk menambahkan kemampuan ini ke spesifikasi DP. Sampai itu terjadi, untuk sistem yang mendukung ADS, OEM harus memilih kombinasi TCon/panel/Mux yang dapat tetap berada di PSR sementara atribut tautan (misalnya, kecepatan refresh, ukuran aktif) berubah di antara dua kombinasi yang ditampilkan dalam EDID. Pendekatan ini memastikan bahwa PSR dapat tetap aktif selama pengalihan.

Agar pengujian ADS HLK memverifikasi bahwa PSR dipertahankan selama proses pengalihan, kami ingin cara bagi OS untuk mengetahui apakah PSR tidak aktif setelah GPU1 menguji mode. Tantangannya adalah bahwa tidak ditentukan bagaimana panel akan bereaksi jika tidak dapat mendukung PSR selama pelatihan tautan.

Sebagai bagian dari DxgkDdiDisplayMuxPostSwitchToPhase2, driver mengembalikan nilai Boolean dalam pWasPanelInPSR untuk menginformasikan OS apakah terdeteksi bahwa panel tidak ada di PSR.

EDID panel internal

Agar OS memberikan perilaku yang diharapkan saat memilih mode tampilan dan topologi dengan monitor yang berbeda yang terhubung, kedua GPU diperlukan untuk melaporkan EDID/DisplayId untuk tampilan internal. Persyaratan ini memastikan bahwa database CCD yang menyimpan mode tampilan dan topologi akan memilih pengaturan yang sama terlepas dari GPU mana yang mengontrol tampilan internal.

EDID yang dilaporkan driver ke sistem operasi harus EDID yang diambil dari panel menggunakan perintah aux tanpa modifikasi apa pun.

Saat ini OS akan memanggil DxgkDdiQueryAdapterInfo(DXGKQAITYPE_INTEGRATED_DISPLAY_DESCRIPTOR2) saat memulai driver yang melaporkan panel internal. Jika mux dialihkan dari target terintegrasi tersebut, driver tidak dapat berkomunikasi dengan panel untuk mengumpulkan informasi yang diperlukan. Solusinya adalah bahwa ketika driver dimulai dan mux dialihkan dari target internalnya, OS menunda memanggil DxgkDdiQueryAdapterInfo(DXGKQAITYPE_INTEGRATED_DISPLAY_DESCRIPTOR2) sampai mux pertama kali dialihkan ke target internal.

Bagaimana OS memutuskan apakah fitur ADS diaktifkan pada sistem dan pengalihan diizinkan

OS melakukan daftar pemeriksaan berikut untuk menentukan apakah ADS tersedia di sistem. Semua pemeriksaan harus benar agar ADS bisa didukung.

Ada GPU yang ditandai sebagai hibrid terintegrasi (DXGK_DRIVERCAPS. HybridIntegrated) yang:
- Driver-nya mengimplementasikan antarmuka DXGK_DISPLAYMUX_INTERFACE.
- Memeriksa tingkat dukungan ADS yang dihasilkan oleh DxgkDdiDisplayMuxGetDriverSupportLevel.
- Memeriksa status ADS runtime dari DxgkDdiDisplayMuxGetRuntimeStatus.
- Driver harus mendukung DDIs (Driver Development Interfaces) berikut:
- Mengekspos target untuk monitor internal dengan DXGK_CHILD_CAPABILITIES.HpdAwareness disetel ke HpdAwarenessInterruptible dan DXGK_CHILD_DESCRIPTOR.ChildDeviceType disetel ke TypeIntegratedDisplay.
- Di bawah namespace ACPI untuk monitor internal, ada metode DMID yang berhasil mengembalikan nama ACPI mux.
- Perangkat GPU ACPI memiliki metode ACPI '_DEP' yang mengembalikan nama ACPI mux yang benar sebagai dependensi.
Ada GPU yang ditandai sebagai hibrid diskrit (DXGK_DRIVERCAPS.HybridDiscrete ) yang:
- Driver-nya mengimplementasikan antarmuka DXGK_DISPLAYMUX_INTERFACE.
- Memeriksa tingkat dukungan ADS yang dihasilkan oleh DxgkDdiDisplayMuxGetDriverSupportLevel.
- Driver harus mendukung DDIs (Driver Development Interfaces) berikut:
- Mengekspos target untuk monitor internal dengan DXGK_CHILD_CAPABILITIES.HpdAwareness disetel ke HpdAwarenessInterruptible dan DXGK_CHILD_DESCRIPTOR.ChildDeviceType disetel ke TypeIntegratedDisplay.
- Di bawah namespace ACPI untuk monitor internal, ada metode DMID yang berhasil mengembalikan nama ACPI mux.
- Perangkat GPU ACPI memiliki metode ACPI '_DEP' yang mengembalikan nama ACPI mux yang benar sebagai dependensi.
Nama ACPI mux yang dikembalikan dari metode ACPI DMID pada langkah 1 dan 2 sesuai.
Perangkat mux ACPI memiliki metode ACPI DMQU, DMCF, dan DMSL.
Metode DMQU ACPI mux mengembalikan nama ACPI dari target panel internal dari salah satu GPU.
ADS saat ini hanya mendukung sistem dengan satu panel internal.
Salah satu:
1. GPU0, GPU1, dan Mux ACPI semuanya melaporkan dukungan ADS lengkap.
2. GPU0, GPU1, dan Mux ACPI semuanya melaporkan dukungan ADS yang bersifat eksperimental atau penuh dan kunci registri EnableMDMExperimentalFeature telah diatur.

Kondisi 1 dan 2 menyiratkan bahwa kedua adaptor harus dinyalakan agar multiplexer dialihkan.

Mengontrol kualitas peluncuran fitur ADS

Agar ADS memberikan pengalaman pengguna yang baik, semua komponen berikut harus bekerja sama dengan sempurna:

Fungsionalitas mux tampilan OS.
Metode platform ACPI untuk pengalihan mux.
Fungsionalitas pengalihan multipleks tampilan pada driver iGPU dan dGPU.

Untuk membantu IHV/OEM memiliki kode kualitas non-pengiriman dalam rilis, mereka dapat menyediakan salah satu tingkat dukungan ADS berikut:

Tidak ada dukungan: driver tidak mendukung fungsionalitas ADS apa pun.
Dukungan pengembangan: driver mendukung ADS tetapi implementasi driver masih dalam pengembangan dan tidak boleh digunakan di luar tujuan ini.
Dukungan eksperimental: Driver mendukung ADS tetapi belum berada pada kualitas siap diluncurkan. OS tidak akan mengaktifkan ADS secara default tetapi dapat dikonfigurasi untuk mengaktifkannya.
Dukungan penuh: Pengemudi mendukung ADS dalam kualitas kapal. OS menganggap bahwa driver mendukung ADS.

Tampilkan atribut yang harus tetap sama setelah penggantian tampilan

Sakelar tampilan tidak boleh mengubah salah satu atribut tampilan berikut:

Resolusi desktop
Jalur VidPn (termasuk mode sumber VidPn, mode target, penskalaan, dan sebagainya)
DPI (titik per inci)
Pengaturan cahaya malam
Gamma
Tampilkan topologi
HDR aktif/nonaktif
Tingkat putih SDR
Profil warna
Jenis target OPM untuk monitor
Kecerahan tampilan

Pengaturan Kompatibilitas GPU yang cocok untuk pengalaman beralih yang mulus

Untuk memberi pengguna pengalaman beralih yang mulus, tampilan harus dikonfigurasi sama setelah pengalihan seperti sebelum pengalihan. Ada fitur GPU tertentu yang memerlukan dukungan yang sama untuk mencapai perilaku ini. Misalnya, jika satu GPU mendukung HDR dan yang lainnya tidak, maka beralih saat HDR diaktifkan pada satu GPU tidak akan berjalan dengan mulus.

Tabel berikut mencantumkan fungsionalitas dan fitur tampilan GPU, dan menjelaskan persyaratan perataan antara dua GPU.

Fitur	GPU harus memiliki dukungan yang lancar
HDR	Jika panel mendukung HDR, kedua GPU harus mendukung fp16 HDR atau tidak mendukung HDR.
Kursor Hw	Tidak. OS beradaptasi dengan fitur kursor yang berbeda tanpa gangguan yang terlihat pada pengguna.
MPO	Tidak. OS beradaptasi dengan fitur MPO yang berbeda tanpa gangguan yang terlihat pada pengguna.
PSR	Kedua GPU perlu mendukung fitur ini.
EDID/DisplayID	Kedua GPU harus mengekspos EDID/DisplayId yang sama.
Batas kecerahan	Kedua GPU harus mendukung antarmuka kecerahan dan batas kecerahan yang sama.
Tingkat kecerahan	Kedua GPU perlu mengekspos tingkat kecerahan dan interval yang sama.
Resolusi	Kedua GPU perlu mendukung mode sumber dan resolusi target yang sama.
Frekuensi Penyegaran	Lihat masalah jika GPU1 tidak mendukung laju refresh yang digunakan oleh GPU0 pada panel. Lihat untuk detailnya.
Laju Penyegaran Dinamis	Tidak. OS beradaptasi dengan dukungan kecepatan refresh virtual yang berbeda.
Laju Penyegaran Variabel	Lihat masalah jika GPU1 tidak mendukung laju refresh yang digunakan oleh GPU0 pada panel. Lihat untuk detailnya.

Masalah jika GPU1 tidak mendukung laju penyegaran yang dijalankan oleh GPU0 pada panel tersebut.

Jika GPU1 tidak mendukung mode yang sama dengan GPU0, maka mode yang dikurangi kemungkinan akan disimpan dalam database topologi tampilan. Kemudian, ketika sistem beralih kembali ke GPU0, mode yang dikurangi akan diatur. Misalnya, jika GPU0 mendukung 120Hz tetapi GPU1 hanya mendukung 60Hz maka urutan berikut dapat terjadi:

Sistem dikonfigurasi sehingga GPU0 mengontrol tampilan dan modenya adalah 120Hz.
Pengguna secara manual beralih ke GPU1.
Database topologi tampilan memiliki 120Hz yang disimpan untuk layar tetapi GPU1 tidak mendukungnya sehingga OS memilih 60Hz.
60Hz diatur dan disimpan dalam database topologi tampilan.
Pengguna secara manual beralih kembali ke GPU0.
Membaca frekuensi 60Hz dari database topologi.

Untuk memberikan pengalaman terbaik, OEM harus memilih iGPU dan dGPU yang keduanya mendukung laju refresh maksimum panel internal. Jika itu tidak memungkinkan dan satu GPU tidak dapat mendukung laju refresh maks panel, maka GPU yang mendukung laju refresh panel harus mendukung fitur Windows Dynamic Refresh Rate (DRR) dengan rentang yang mencakup:

Laju refresh tertinggi dari GPU lainnya.
Laju refresh tertinggi panel internal.

Misalnya, jika panel dapat mendukung 300Hz dan iGPU hanya dapat mendukung 60Hz maka dGPU harus mendukung VRR dengan rentang setidaknya 60Hz hingga 300Hz.

Untuk meringkas, persyaratan ADS untuk laju refresh adalah:

iGPU dan dGPU mendukung laju refresh maksimum panel internal.
GPU yang mendukung laju refresh maksimum panel internal harus mendukung DRR dengan rentang dari kecepatan refresh tertinggi yang dapat didukung GPU lainnya hingga laju refresh maksimum panel internal.

HDR dan Dolby Vision

OS mengatur status HDR/Dolby Vision yang sama pada panel internal di GPU1 setelah pengalihan seperti yang diatur pada panel internal di GPU0 sebelum pengalihan. Pengguna tidak boleh melihat perubahan apa pun.

Cahaya malam

Cahaya malam diimplementasikan melalui gamma WDDM atau DDI matriks warna. Dalam kedua kasus ini, OS mengatur tingkat cahaya malam yang sama melalui GPU1 setelah pengalihan seperti yang dilakukan dengan GPU0 sebelum pengalihan.

Profil warna

OS menerapkan profil warna yang sama ke panel setelah pengalihan seperti yang diterapkan sebelum pengalihan.

Menampilkan layar pengecekan bug

Saat ini OS mendukung menampilkan layar pemeriksaan bug pada perangkat non-POST. Ketika pemeriksaan bug terjadi pada OS:

Tidak mengganti mux.
Menggunakan dukungan OS saat ini untuk menampilkan layar pemeriksaan bug.

Saat mengevaluasi target potensial untuk menampilkan hasil pemeriksaan bug, OS melewati target apa pun yang terhubung ke mux yang dialihkan ke target lain.

Ada periode waktu kecil ketika HPD menjauh dari GPU0 diproses tetapi HPD masuk dari GPU1 belum sepenuhnya diproses. Jika pemeriksaan bug terjadi selama periode ini, pengguna tidak akan melihat pemeriksaan bug. Jika pemeriksaan bug terjadi dalam jangka waktu kecil ketika PSR masih diaktifkan, driver yang mengontrol layar harus memastikan panel tidak dalam mode PSR ketika OS memanggil DxgkDdiSystemDisplayEnable.

Algoritma kecemerlangan adaptif berdasarkan konten

Dalam dunia yang ideal, algoritma adaptif konten yang digunakan oleh kedua GPU harus menghasilkan efek yang sama. Namun, efek yang sama kemungkinan tidak akan terjadi dan pengguna mungkin melihat perbedaan ketika panel internal dialihkan.

Data kecerahan

Untuk memastikan pengguna tidak menyadari perubahan kecerahan akibat perpindahan, semua atribut kecerahan yang diekspos oleh GPU0 dan GPU1 harus identik. Persyaratan ini memastikan bahwa tingkat kecerahan apa pun sebelum pengalihan pada GPU0 akan didukung pada GPU1 setelah pengalihan.

Untuk melakukannya, driver untuk GPU0 dan GPU1 harus:

Gunakan antarmuka kecerahan yang sama, baik DXGK_BRIGHTNESS_INTERFACE_2 atau DXGK_BRIGHTNESS_INTERFACE_3, di mana versi 3 sangat disarankan.
Untuk antarmuka brightness v3, kedua driver harus mengekspos kecerahan berbasis nits atau tidak terkalibrasi.
Untuk antarmuka kecerahan v2, kedua driver harus menghasilkan tingkat kecerahan yang sama persis dari GetPossibleBrightness.
Untuk antarmuka brightness v3, kedua driver harus mengembalikan rentang yang sama persis; artinya, setiap driver harus mengembalikan struktur DXGK_BRIGHTNESS_GET_NIT_RANGES_OUT yang identik dari GetNitRanges.
Tabel internal yang digunakan driver untuk mengonversi tingkat kecerahan yang disediakan OS ke pengaturan khusus panel harus sama.

Di sebagian besar laptop, driver GPU mendapatkan beberapa atau semua data tingkat kecerahan ini dari platform dengan cara yang tidak biasa. Kami mengharapkan pertukaran data platform-ke-GPU ini mungkin harus diperluas untuk mencapai persyaratan ini.

Meskipun antarmuka kecerahan dikueri pada waktu mulai adaptor, OS tidak akan memanggil DDI antarmuka kecerahan apa pun hingga panel internal di-HPD. HPD terjadi setelah mux dialihkan ke GPU sehingga driver memiliki akses ke EDID panel internal pada saat itu.

Kami memahami bahwa ada cara khusus IHV bagi driver untuk mengatur kecerahan panel untuk panel yang tidak mendukung PWM. Namun, metode ini menambah kerumitan pada TCon karena mungkin harus mendukung pengaturan kecerahan dengan cara khusus IHV tergantung pada GPU mana yang terhubung melalui mux.

Konfigurasi boot mux

Firmware sistem mengontrol GPU mana yang terhubung ke panel internal pada waktu mulai sistem. OS menyimpan GPU mana yang terakhir mengontrol panel. Kemudian, selama urutan boot, OS mengalihkan mux jika perlu sehingga GPU yang benar mengontrol panel.

Untuk mempertahankan gambar boot apa pun saat sakelar mux diperlukan, sakelar hanya dilakukan saat:

Kedua GPU dinyalakan.
OS telah beralih dari grafik boot yang mengontrol output ke DWM/shell yang mengontrol output.

Dengan demikian, perubahan terjadi setelah panggilan DxgkddiSettimingsfromvidpn pada GPU yang mengontrol panel internal, dan pengguna akan mengalami layar beku ketika panel berada dalam PSR selama perubahan terjadi.

Memberikan informasi mux kepada driver

Fitur ini sengaja dirancang agar OS memanggil driver untuk memberikan informasi daripada memberikan panggilan balik yang dapat dipanggil driver kapan saja. Metode ini menghindari driver menjadi bingung jika menanyakan status sistem operasi selama urutan sakelar.

OS memanggil DxgkDdiDisplayMuxUpdateState DDI driver untuk menyediakan driver dengan status mux saat ini dalam kasus berikut:

Ketika driver dimulai, ini memungkinkan driver untuk menghindari urutan polling ketika panel tidak tersambung.
Saat kembali ke D0 dari Dx. Saat kembali dari beberapa status daya (misalnya, hibernasi), firmware mungkin harus mengatur ulang multiplexer; sehingga driver tidak mengetahui keadaan.

Kasus-kasus ini bersama dengan DDI normal yang terlibat dalam urutan sakelar memastikan bahwa driver dapat menentukan cara muks dialihkan kapan saja GPU aktif.

Pada versi pertama fitur ini, tidak ada rencana untuk mengalihkan mux ketika panel internal tidak aktif, sehingga semua peralihan akan melalui urutan yang sama.

Waktu mulai adaptor

Ketika driver dimulai, driver perlu menanggapi permintaan polling dari OS. Driver dapat mencoba menemukan apakah mux dialihkan kepada mereka dengan mencoba berkomunikasi tetapi itu bisa memakan waktu atau tidak dapat diandalkan. Sebagai bagian dari urutan mulai GPU, OS memanggil DxgkDdiDisplayMuxUpdateState DDI untuk setiap target yang terhubung ke mux dan menunjukkan apakah itu dialihkan ke target tersebut.

Ketika driver dimulai, driver perlu menanggapi permintaan polling dari OS. Driver dapat mencoba menemukan apakah mux dialihkan ke GPU mereka dengan berkomunikasi dengan OS, tetapi itu bisa memakan waktu atau tidak dapat diandalkan.

Sebagai gantinya, sebagai bagian dari urutan mulai GPU, OS memanggil DxgkDdiDisplayMuxUpdateState untuk setiap target yang terhubung ke mux dan menunjukkan apakah mux dialihkan ke target tersebut. OS melaporkan kepada driver apakah mux dialihkan ke GPU driver sebelum memanggil DDI polling apa pun.

Driver ADS terus melaporkan panel internal ke OS dengan cara yang sama, di mana OS memanggil DxgkDdiQueryAdapterInfo(DXGKQAITYPE_INTEGRATED_DISPLAY_DESCRIPTOR2) untuk mengajukan kueri detail panel internal. Driver perlu memastikan bahwa DXGK_CHILD_CAPABILITIES.HpdAwareness disetel ke HpdAwarenessInterruptible untuk target apa pun yang terhubung ke multiplexer.

Transisi D0

Setiap kali GPU dengan mux yang terhubung diaktifkan kembali dari keadaan daya rendah, OS memanggil DxgkDdiDisplayMuxUpdateState untuk memberi tahu driver apakah mux terhubung ke targetnya atau beralih ke GPU lainnya.

Urutan proses booting

Urutan boot berikut menyoroti aspek khusus ADS. Dalam urutan ini, sistem memulai dengan:

iGPU terhubung ke mux.
Konfigurasi terakhir pengguna sebelum boot ulang adalah bahwa mux terhubung ke dGPU.

Urutan boot bersifat asinkron, jadi urutan ini hanya untuk tujuan contoh saja.

Sistem menyala dan iGPU terhubung ke panel melalui mux.
iGPU menampilkan layar boot pada panel.
Windows memuat dan menampilkan animasi boot pada tutup internal.
Karena _DEP pada iGPU dan dGPU, driver mux OS dimulai sebelum salah satu driver GPU. Driver mux menggunakan panggilan ACPI untuk memastikan mux dikonfigurasi dengan benar. Driver mux memverifikasi bahwa implementasi mux ACPI memenuhi persyaratan ADS.
Dxgkrnl memanggil DxgkDdiAddDevice untuk iGPU.
Dxgkrnl memanggil DxgkDdiQueryInterface(DXGK_DISPLAYMUX_INTERFACE) untuk iGPU. Bahkan jika sistem saat ini tidak mendukung ADS, driver mengembalikan antarmukanya jika mendukung ADS.
Dxgkrnl memanggil DxgkDdiDisplayMuxGetDriverSupportLevel untuk mendapatkan tingkat dukungan ADS dari driver.
Dxgkrnl memanggil DxgkDdiDisplayMuxReportPresence(TRUE) untuk memberi tahu iGPU bahwa sistem memiliki mux ADS yang berfungsi di dalamnya.
Dxgkrnl memanggil DxgkDdiStartDevice. Driver iGPU mengembalikan jumlah anak termasuk target VidPn untuk panel internal.
Dxgkrnl memanggil DxgkDdiDisplayMuxGetRuntimeStatus untuk memeriksa apakah iGPU mendukung ADS dan apakah driver mendapatkan semua informasi yang diperlukan dari sistem.
Dxgkrnl memanggil DxgkDdiQueryChildStatus untuk setiap anak yang diekspos iGPU.
Setelah Dxgkrnl menemukan anak yang dilaporkan iGPU yang terhubung ke mux, ia memanggil DxgkDdiDisplayMuxUpdateState untuk memberi tahu iGPU bahwa mux terhubung ke target tersebut.
Karena iGPU mengungkapkan monitor internal yang terhubung, Dxgkrnl mengatur mode pada iGPU dengan menggunakan DxgkddiSettimingsfromvidpn.
Dxgkrnl memulai driver dGPU, lalu mengulangi langkah 5-12 untuk dGPU.
Dxgkrnl mendeteksi bahwa iGPU, dGPU, dan mux semuanya dikonfigurasi dengan benar, sehingga membuat pasangan mux dan properti Antarmuka Perangkat PnP untuk pasangan mux.
Dxgkrnl membaca konfigurasi mux terakhir dari registri. Karena konfigurasi terakhir adalah dGPU, Dxgkrnl sekarang memulai urutan pengalihan mux yang telah dijelaskan sebelumnya untuk mengalihkan mux ke dGPU.

Panel pengemudi

Driver panel monitor dimuat berdasarkan ID perangkat keras PnP yang dihasilkan dari EDID. Mengingat bahwa EDID tetap sama, driver panel dimuat ketika salah satu GPU mengontrol panel internal. Kedua driver akan menampilkan fungsionalitas kecerahan yang sama. Dengan demikian, pemuatan tidak boleh menyebabkan masalah apa pun dan driver panel tidak perlu mengetahui GPU mana yang memegang kendali atas mux.

Mengidentifikasi target yang dikendalikan oleh multiplexer

Ketika OS memulai driver, OS memanggil driver DxgkDdiQueryChildRelations untuk mengkueri informasi tentang anak-anak yang dilaporkan. Driver mengisi struktur DXGK_CHILD_DESCRIPTOR untuk setiap anak. Anggota AcpiUid didefinisikan sebagai nilai yang dikembalikan oleh metode _ADR di dalam namespace ACPI pada anak tersebut, yang memungkinkan OS menemukan nama ACPI untuk anak tersebut.

Untuk ADS, kami mendefinisikan metode ACPI DMID yang perlu berada di bawah ruang nama ACPI turunan untuk target. Metode DMID ini mengembalikan nama ACPI perangkat mux. Ini memungkinkan OS untuk menemukan nama ACPI mux untuk target.

PnP menghentikan adaptor yang memindai ke target

OS tidak akan mengalihkan mux ketika GPU yang memindai ke panel internal dihentikan. Skenario berikut melalui berbagai kasus ketika GPU dihentikan.

GPU0 adalah pos. Ini terhubung ke panel internal dan dihentikan.

Dalam hal ini, Driver Tampilan Dasar (BDD) mengambil alih mode aktif saat ini pada GPU0 dan terus memperbarui layar.
GPU0 adalah pos tetapi GPU1 terhubung ke panel internal. GPU0 dihentikan.

Karena desain OS saat ini, BDD dimulai pada GPU0, yang menyebabkan monitor tak terlihat dilaporkan dan muncul di panel kontrol tampilan.
GPU1 bukan postingan dan terhubung ke panel internal. GPU1 dihentikan.

Karena desain OS saat ini, BDD tidak dimulai pada GPU1 dan karenanya pengguna tidak akan dapat melihat panel.
GPU1 bukan postingan. GPU0 terhubung ke panel internal dan GPU1 dihentikan.

Tidak ada pergantian yang terjadi dan tidak ada apapun yang terjadi. GPU0 terus muncul pada panel.

Skenario 2 dan 3 menciptakan pengalaman buruk bagi pengguna. Fitur ADS mengubah perilaku untuk memperbaiki kedua kasus ini.

GPU plugin/eksternal tidak didukung

Kami tidak percaya ada kasus penggunaan untuk fitur ini dengan GPU plugin.

ADS terbatas pada panel internal tunggal saja

Versi pertama ADS hanya mendukung satu panel internal. Namun, fitur ini direkayasa sedemikian rupa sehingga memungkinkannya mendukung muxing tampilan eksternal dan beberapa internal di masa depan (jika didukung oleh OS) dengan perubahan driver yang minimal.

Perubahan kebijakan adaptor POST saat ini

OS sebelumnya memiliki beberapa kebijakan mengenai adaptor POST. Misalnya, adaptor POST adalah satu-satunya adaptor yang dapat mengekspos target internal. Jenis pembatasan ini dihapus dari OS ketika ADS diperkenalkan.

Nonaktifkan efek visual saat monitor terhubung

Ketika monitor tersambung di Windows 11, shell/DWM memiliki urutan animasi. Animasi ini dinonaktifkan dalam skenario sakelar tampilan.

Menonaktifkan bonk PnP

Saat monitor ditambahkan atau dihapus, sistem PnP memutar suara 'bonk' untuk memberi tahu pengguna. "bonk" ini dinonaktifkan dalam skenario sakelar tampilan.

Pemberitahuan aplikasi

Ketika sakelar tampilan terjadi, sistem melalui jalur kode penghapusan HPD dan kedatangan HPD yang teratur. Oleh karena itu, semua pemberitahuan aplikasi normal berfungsi seperti biasa; misalnya, pemberitahuan PnP untuk HPD out dan HPD in serta pesan window WM_DISPLAYCHANGE.

API untuk memicu saklar

Rencananya adalah memiliki API publik sehingga panel kontrol OS dan IHV dapat memicu pengalihan.

Mengingat bahwa panel internal hanya pernah terhubung ke satu GPU, API tampilan berfungsi seperti yang diharapkan bersama dengan fungsionalitas Win+P.

Uji HLK

Jika driver GPU atau firmware ACPI melaporkan dukungan ADS penuh, driver GPU perlu melewati pengujian ADS HLK pada sistem yang mendukung ADS.

Panel internal GPU HPDing saat mux dialihkan dari GPU tersebut

OS memicu pemeriksaan bug ketika panel internal dilaporkan terhubung dari driver ketika mux tersebut saat ini dialihkan dari driver tersebut.

Transisi AC/DC

Untuk versi pertama fitur ADS, OS tidak akan menyimpan pengaturan mux AC vs DC dan tidak akan memicu sakelar mux pada transisi <AC -> DC.

Transisi daya sistem

Kekhawatiran utama mengenai transisi daya adalah ketika firmware mereset status mux (contohnya, saat hibernasi), dan pada saat melanjutkan dari daya, mux tidak dialihkan kembali ke panel yang digunakan sebelum transisi daya.

Pendekatan awal adalah mengalihkan mux kembali ke dGPU setelah menyalakan iGPU dan dGPU. Masalah dengan pendekatan ini adalah bahwa, tergantung pada peristiwa asinkron yang berbeda, hasilnya mungkin beberapa perubahan mode.

Pendekatan yang diperbarui untuk membantu menyederhanakan pengalaman pengguna adalah agar sistem mengalihkan mux kembali ke target yang diharapkan saat iGPU dan dGPU tertidur, sehingga menghindari beberapa perubahan mode.

Urutan transisi kekuatan

Contoh berikut menjelaskan transisi daya hibernasi pada sistem ADS.

Sistem dikonfigurasi dengan mux yang tersambung ke dGPU.
Sistem memasuki hibernasi.
Baik iGPU maupun dGPU dialihkan ke daya D3.
Sistem mati.
Pengguna menyalakan sistem.
Firmware mengonfigurasi mux ke urutan boot tampilan iGPU dan iGPU pada panel internal.
Dxgkrnl membaca konfigurasi mux terakhir (dGPU dalam hal ini), dan membandingkannya dengan posisi muks saat ini menggunakan ACPI (iGPU dalam hal ini). Dxgkrnl kemudian memanggil ACPI untuk mengalihkan mux ke dGPU.
Dxgkrnl mentransisikan iGPU ke D0, lalu memanggilDxgkDdiDisplayMuxUpdateState iGPU untuk memberi tahu driver bahwa mux tidak terhubung padanya.
Dxgkrnl transisi dGPU ke D0, lalu memanggil DxgkDdiDisplayMuxUpdateState untuk memberi tahu driver bahwa mux terhubung padanya.
Dxgkrnl mengatur mode pada dGPU.

Sistem All In One (AIO)

Setiap sistem AIO yang ingin mendukung ADS harus memiliki panel internal yang diekspos sebagai jenis target internal pada kedua GPU.

Perangkat MUX ACPI

OEM bertanggung jawab untuk menambahkan perangkat mux di namespace ACPI dan menyediakan metode yang diperlukan untuk mengoperasikan mux.

Driver GPU tidak boleh memanggil metode ACPI mux karena perangkat mux dapat terletak di mana saja di pohon ACPI. Rekomendasinya adalah menemukan mux di bawah leluhur bersama terdekat dari kedua GPU.

Perangkat mux saat ini hanya mendukung dua input dan kami tidak mengharapkan muks di masa depan mendukung lebih dari itu, sehingga desain dapat mengasumsikan dua input dan satu output untuk setiap mux.

Perangkat mux tidak pernah dapat dihentikan saat sistem sedang berjalan. Ini adalah perangkat sistem tersembunyi.

Metode ACPI perangkat Mux

Hanya tumpukan driver untuk perangkat ACPI yang dapat memanggil untuk mengevaluasi metode ACPI pada perangkat. Oleh karena itu, untuk memanggil metode perangkat mux guna melakukan pengalihan, sistem operasi harus memiliki driver yang dimuat untuk perangkat mux. Untuk alasan ini, OS sekarang menyediakan driver multiplexer tampilan sebagai driver untuk semua sakelar multiplexer tampilan.

Perangkat mux diperlukan untuk memiliki metode berikut:

_HID mengidentifikasi perangkat mux berdasarkan ID perangkat keras. Kami telah memesan 'MSFT0005' untuk pengalih tampilan ACPI.
DMQU (Kueri Mux Tampilan) mengembalikan status mux saat ini.
DMCF (Konfigurasi Mux Tampilan) mengonfigurasi mux.

Metode _HID (ID Perangkat Keras)

Argumen:

Tidak

Mengembalikan:

String ASCII yang berisi ID perangkat keras, yaitu 'MSFT0005'.

Metode DMQU (Display Mux Query)

Dalam rilis mendatang, kami berharap untuk menambahkan informasi tambahan ke kueri. Untuk mengaktifkan kueri tambahan di masa mendatang, Arg0 digunakan untuk menunjukkan jenis kueri. Jika metode DMQU tidak memahami jenis kueri, metode harus gagal sebagai tidak didukung.

Argumen:

Arg0: Bilangan bulat yang menentukan jenis kueri. Tabel berikut mencantumkan nilai tipe kueri dan maknanya.

Nilai tipe kueri	Arti
1	Mengkueri status sakelar saat ini
2	Mengkueri tingkat dukungan ADS mux
3	Mengkueri anak GPU pertama yang tersambung dengan muks
4	Mengkueri anak GPU kedua yang terhubung ke mux

Mengembalikan:

Jika metode memahami jenis kueri yang ditentukan, metode tersebut harus mengembalikan data yang sesuai seperti yang diuraikan dalam tabel berikut. Jika metode tidak memahami jenis kueri yang ditentukan, metode tersebut harus mengembalikan string kosong.

Nilai tipe kueri	Mengembalikan data
1	String ASCII yang berisi nama ACPI perangkat anak GPU tempat mux saat ini dialihkan.
2	Bilangan bulat yang mewakili tingkat dukungan ADS. Lihat tabel berikutnya untuk detailnya.
3	String ASCII yang berisi nama ACPI dari perangkat anak GPU pertama yang dihubungkan ke mux.
4	String ASCII yang berisi nama ACPI dari perangkat anak GPU kedua yang terhubung ke mux.

Tabel berikut mencantumkan nilai tingkat dukungan ADS dan maknanya saat jenis kueri adalah 2.

Data yang dikembalikan	Arti
0	Tidak ada dukungan
1	Dukungan pengembangan. Sistem dapat dikirim dengan pengaturan ini tanpa melewati pengujian HLK apa pun karena ADS akan dinonaktifkan secara default pada sistem pelanggan.
2	Dukungan eksperimental. Sistem dapat dikirim dengan pengaturan ini tanpa melewati pengujian HLK apa pun karena ADS akan dinonaktifkan secara default pada sistem pelanggan.
3	Dukungan penuh. ADS akan diaktifkan secara default pada sistem ini jika dipasangkan dengan driver grafis yang didukung penuh. Sistem perlu lulus tes ADS HLK untuk dikirim.

Metode DMCF (Konfigurasi Mux Tampilan)

Argumen:

Arg0: Nama ASCII dari perangkat anak GPU ACPI yang harus dialihkan oleh multiplexer.

Mengembalikan:

Bilangan bulat 0 berarti sukses; nonzero menunjukkan kegagalan. OEM dapat menentukan nilai bukan nol untuk diagnostik yang lebih baik.

Metode ACPI perangkat GPU

Sebelum driver grafis untuk GPU dimulai, sistem perlu mengetahui apakah perangkat ACPI mux berfungsi dan apa statusnya saat ini. Untuk melakukannya, driver dari perangkat mux ACPI harus sudah berjalan. Sistem ini menggunakan metode acpi _DEP di bawah setiap namespace ACPI GPU untuk menjamin hubungan perangkat.

Jika GPU sudah memiliki metode _DEP, GPU harus menambahkan nama ACPI perangkat mux ke daftar dependensi yang dikembalikan. Jika GPU belum memiliki metode _DEP, GPU harus menambahkannya.

Agar firmware ACPI hanya mendeklarasikan ketergantungan GPU pada mux jika OS mendukung ADS, kueri ACPI _OSI ditambahkan. Firmware ACPI dapat menggunakan kueri ini untuk memeriksa dukungan ADS. Versi OS yang mendukung ADS akan melaporkan dukungan dengan mengembalikan true ke perintah _OSI(“DisplayMux”) ACPI.

Metode ACPI perangkat anak GPU

Untuk setiap target yang terhubung ke mux, perangkat ACPI anak tersebut mengekspos metode ACPI yang mengembalikan nama ACPI perangkat mux yang terhubung dengannya. Untuk detailnya, lihat Identifikasi target yang dikontrol oleh mux.

Metode DMID (Pengidentifikasi Mux Tampilan)

Argumen:

Tidak

Mengembalikan:

String ASCII yang berisi nama ACPI dari perangkat mux ACPI yang output ini terhubung dengannya

Contoh

Contoh berikut menunjukkan bagaimana sistem dengan dua GPU (GPU0 dan GPU1) dan mux disiapkan dan dikelola dalam kerangka kerja ACPI.

Nama ACPI perangkat mux adalah 'SB. MUX1'.
Untuk GPU0:
- Nama ACPI GPU0 adalah 'SB. PCI0. GFX0'.
- Ini mengekspos target VidPn 0x40f04, yang melaporkan DXGK_CHILD_DESCRIPTOR.AcpiUid nilai 0x400.
- Nama perangkat anak ACPI yang sesuai dengan target yang terhubung ke mux adalah 'SB. PCI0. GFX0. DD1F'.
- Metode ACPI _ADR di bawah 'SB. PCI0. GFX0. DD1F' mengembalikan 0x400. Nilai pengembalian ini adalah bagaimana OS mengetahui perangkat ACPI ini sesuai dengan target VidPn 0x40f04.
- Metode ACPI DMID di bawah 'SB. PCI0. GFX0. DD1F' mengembalikan 'SB. MUX1'.
Untuk GPU1:
- Nama ACPI GPU1 adalah 'SB. PCI0. PEG0. PEGP'.
- Ini mengekspos target VidPn 0x1103, yang melaporkan nilai DXGK_CHILD_DESCRIPTOR.AcpiUid sebesar 0x100.
- Nama perangkat anak ACPI yang sesuai dengan target yang terhubung ke mux adalah 'SB. PCI0. PEG0. PEGP. EDP1'.
- Metode ACPI _ADR di bawah 'SB. PCI0. PEG0. PEGP. EDP1' mengembalikan 0x100. Nilai pengembalian ini adalah bagaimana OS mengetahui perangkat ACPI ini sesuai dengan target VidPn 0x1103.
- Metode ACPI DMID di bawah 'SB. PCI0. PEG0. PEGP. EDP1' mengembalikan 'SB. MUX1'.
OS tahu bahwa target GPU0 0x40f04 dan target GPU1 0x1103 terhubung ke mux yang sama dengan nama ACPI 'SB. MUX1'.
Jika GPU1 saat ini terhubung ke panel, OS dapat mengalihkan mux ke GPU0 dengan memanggil metode DMCF pada 'SB. MUX1' melewati 'SB. PCI0. GFX0. DD1F'

Kode bahasa mesin ACPI berikut adalah untuk bagian yang relevan dari contoh. Pseudocode untuk logika platform dikelilingi oleh <>.


DefinitionBlock
{
    Device (MUX1) // This is _SB_.MUX1
    {
        Name (_HID, "MSFT0007")  // _HID: Hardware ID

        Method (DMQU, 1, Serialized)  // DMQU: Display Mux Query
        {
            Switch (ToInteger(Arg0))
            {
                Case (1)
                {
                    If (<Mux is in error>)
                    {
                        Return ("")
                    }
                    If (<Mux switched to GPU0>)
                    {
                        Return ("_SB_.PCI0.GFX0.DD1F")
                    }
                    Else
                    {
                        Return ("_SB_.PCI0.PEG0.PEGP.EDP1")
                    }
                }
                Case (2) 
                {
                    Return (1)  // Mux only has developmental support
                }
                Case (3)
                {
                    If (<Mux is in error>)
                    {
                        Return ("")
                    }
                    Return ("_SB_.PCI0.GFX0.DD1F")
                }
                Case (4)
                {
                    If (<Mux is in error>)
                    {
                        Return ("")
                    }
                    Return ("_SB_.PCI0.PEG0.PEGP.EDP1")
                }

            }
            // Unknown type
            Return ("")
        }

        Method (DMCF, 1, Serialized)  // DMCF: Display Mux Configure
        {
            If (<Arg0 does not match either of the GPU children this mux is connected to>)
            {
                Return (1) // Failure, use 1 to indicate this particular failure
            }

            // Switch the mux

            If (<Mux switch was successful>)
            {
                Return (0) // Success
            }
            Else
            {
                Return (2) // Failure, use 2 to indicate this particular failure
            }
        }
    }

    Scope (_SB_.PCI0.GFX0) // ACPI Device for GPU0
    {
        Method (_DEP, 0, NotSerialized)  // _DEP: Dependency on Mux device
        {
            If (_OSI(“DisplayMux”))
            {
                Return (Package {"_SB_.MUX1"})
            }
            Else
            {
                Return (Package (0x00){})
            }
        }

        Device (DD1F) // SB.PCI0.GFX0.DD1F which is child of GPU that is connected to the Mux
        {
            Name (_ADR, 0x400)  // _ADR: Matches the AcpiUid driver reports for the target connected to mux
            Method (DMID, 0, NotSerialized)  // DMID: ACPI name of the mux this target is connected to
            {
                Return ("_SB_.MUX1")
            }
        }
    }

    Scope (_SB_.PCI0.PEG0.PEGP) // ACPI Device for GPU1
    {
        Method (_DEP, 0, NotSerialized)  // _DEP: Dependency on Mux device
        {
            If (_OSI(“DisplayMux”))
            {
                Return (Package {"_SB_.MUX1"})
            }
            Else
            {
                Return (Package (0x00){})
            }
        }

        Device (EDP1) // SB.PCI0.PEG0.PEGP.EDP1 which is child of GPU that is connected to the Mux
        {
            Name (_ADR, 0x100)  // _ADR: Matches the AcpiUid driver reports for the target connected to mux
            Method (DMID, 0, NotSerialized)  // DMID: ACPI name of the mux this target is connected to
            {
                Return ("_SB_.MUX1")
            }
        }
    }
}

Perubahan API

Fitur ADS menambahkan fungsionalitas API publik berikut:

Menghitung perangkat mux dalam sistem.
Kueri informasi tentang mux; misalnya, ke target mana saja perangkat ini tersambung dan target mana yang saat ini aktif.
Mulai sakelar multiplexer.
Cara mendeteksi kapan mux telah dialihkan.

Menghitung perangkat mux dalam sistem

Aplikasi dapat menggunakan API plug and play umum untuk menemukan antarmuka perangkat yang mewakili multiplexer tampilan yang berfungsi. Komponen mode pengguna dapat menggunakan Windows.Devices.Enumeration.DeviceInformation. C# atau C++ dapat digunakan dengan API ini untuk menghitung perangkat mux.

// Display Mux device interface
// {93c33929-3180-46d3-8aab-008c84ad1e6e}
DEFINE_GUID(GUID_DEVINTERFACE_DISPLAYMUX, 0x93c33929, 0x3180, 0x46d3, 0x8a, 0xab, 0x00, 0x8c, 0x84, 0xad, 0x1e, 0x6e);

Antarmuka IDisplayMuxDevice

Antarmuka IDisplayMuxDevice ditambahkan untuk mewakili perangkat multipleksor.

Kode berikut menunjukkan cara menghitung perangkat mux tampilan, mengkueri statusnya, mengalihkan target tampilan aktif, dan bereaksi terhadap perubahan status menggunakan API Windows Runtime.

#include <winrt/Windows.Foundation.h>
#include <winrt/Windows.Devices.Enumeration.h>
#include <winrt/Windows.Foundation.Collections.h>
#include <winrt/Windows.Devices.Display.Core.h>

#include <string>
#include <sstream>
#include <iomanip>
#include <windows.h>

namespace winrt
{
using namespace winrt::Windows::Foundation;
using namespace winrt::Windows::Foundation::Collections;
using namespace winrt::Windows::Devices::Enumeration;
using namespace winrt::Windows::Devices::Display;
using namespace winrt::Windows::Devices::Display::Core;
} // namespace winrt

void SwitchDisplayMuxTarget()
{
    // PnP device interface search string for Mux device interface
    std::wstring muxDeviceSelector = L"System.Devices.InterfaceClassGuid:=\"{93c33929-3180-46d3-8aab-008c84ad1e6e}\" AND System.Devices.InterfaceEnabled:=System.StructuredQueryType.Boolean#True";

    // Execute the device interface query
    winrt::DeviceInformationCollection deviceInformations = winrt::DeviceInformation::FindAllAsync(muxDeviceSelector, nullptr).get();
    if (deviceInformations.Size() == 0)
    {
        printf("No DisplayMux devices\n");
        return;
    }
    printf("%ld display mux devices found\n\n", deviceInformations.Size());

    // Only one mux in first release but here is generic code for multiple
    for (unsigned int i = 0; i < deviceInformations.Size(); i++)
    {
        printf("Display Mux device %ld :\n", i);

        // Get the device interface so we can query the info
        winrt::DeviceInformation deviceInfo = deviceInformations.GetAt(i);

        // Get the device id
        std::wstring deviceId = deviceInfo.Id().c_str();
        printf("    Device ID string : %S \n", deviceId.c_str());

        // Create the DisplayMuxDevice object
        auto displayMuxDevice = winrt::DisplayMuxDevice::FromIdAsync(deviceId).get();
        if (!displayMuxDevice)
        {
            printf("Failed to create DisplayMuxDevice object");
            continue;
        }

        // Check if DisplayMux is active
        auto displayMuxActive = displayMuxDevice.IsActive();
        printf("    DisplayMux state : %s \n", displayMuxActive ? "Active" : "Inactive");
        if (!displayMuxActive)
        {
            continue;
        }

        // Register for call back when the state of the DisplayMux changes
        UINT changeCount = 0;
        auto token = displayMuxDevice.Changed([&changeCount](auto, auto Args) -> HRESULT {
            changeCount++;
            return S_OK;
        });

        // Find targets connected to the DisplayMux and the current target
        auto targetsList = displayMuxDevice.GetAvailableMuxTargets();
        winrt::DisplayTarget currentTarget = displayMuxDevice.CurrentTarget();

        // Switch the display mux to the other target
        // NOTE SetPreferredTarget() is a sync method so use .get() to wait for the operation to complete
        printf("\n");
        if (currentTarget == targetsList.GetAt(0))
        {
            printf("DisplayMux currently connected to first target\n");
            displayMuxDevice.SetPreferredTarget(targetsList.GetAt(1)).get();
            printf("Calling SetPreferredTarget to switch DisplayMux to second target\n");
        }
        else if (currentTarget == targetsList.GetAt(1))
        {
            printf("DisplayMux currently connected to second target\n");
            displayMuxDevice.SetPreferredTarget(targetsList.GetAt(0)).get();
            printf("Calling SetPreferredTarget to switch DisplayMux to first target\n");
        }
        else
        {
            printf("Could not find current target in target list\n");
        }

        // Now read the current position
        currentTarget = displayMuxDevice.CurrentTarget();
        targetsList = displayMuxDevice.GetAvailableMuxTargets();
        if (currentTarget == targetsList.GetAt(0))
        {
            printf("DisplayMux is now currently connected to first target\n");
        }
        else if (currentTarget == targetsList.GetAt(1))
        {
            printf("DisplayMux is now currently connected to second target\n");
        }
        else
        {
            printf("Could not find current target in target list\n");
        }

        // Now unregister for change callback and display the
        displayMuxDevice.Changed(token);
        printf("DisplayMux state change callback was called %ld times\n\n", changeCount);
    }
}

Perubahan DDI WDDM untuk pengalihan tampilan otomatis

Bagian ini menjelaskan penambahan dan perubahan yang dilakukan pada WDDM DDI untuk mendukung ADS. Perubahan ini tersedia dimulai dengan Windows 11, versi 24H2 pembaruan 2025.01D (WDDM 3.2).

Mengkueri antarmuka dukungan ADS KMD

Struktur antarmuka DXGK_DISPLAYMUX_INTERFACE_2 ditambahkan. Ini berisi panggilan dari OS ke driver yang diperlukan untuk mendukung ADS versi 2. Kueri OS untuk antarmuka ADS yang didukung oleh driver pada saat inisialisasi driver, dengan InterfaceType diatur ke GUID_WDDM_INTERFACE_DISPLAYMUX_2.

(DXGK_DISPLAYMUX_INTERFACE berisi panggilan dari OS ke driver yang diperlukan untuk mendukung fitur ADS Versi 1. Versi ini digunakan selama prarilis ADS.)

Fungsi KMD untuk mendukung ADS

KMD menerapkan fungsi berikut untuk mendukung ADS. Dxgkrnl memperoleh antarmuka fungsional ADS KMD melalui panggilan ke KMD DxgkddiQueryInterface.

Pelaporan Kemampuan ADS oleh Driver

Driver melaporkan tingkat dukungan ADS saat OS memanggil DxgkDdiDisplayMuxGetDriverSupportLevel DDI. Jika driver tidak mengimplementasikan antarmuka DXGK_DISPLAYMUX_INTERFACE, OS menganggap tingkat dukungan DXGK_DISPLAYMUX_SUUPORT_LEVEL_NONE.

Driver harus melaporkan tingkat dukungan ADS-nya terlepas dari sistem mana yang dijalankannya. Tingkat dukungan yang dilaporkan oleh driver hanya boleh didasarkan pada driver. Driver tidak boleh memperhitungkan salah satu kriteria berikut saat melaporkan tingkat dukungan ADS-nya:

Sistem OEM.
GPU lain mana pun dalam sistem.
Kehadiran atau tidak perangkat mux ACPI.
Kehadiran atau tidak entri ACPI di bawah simpul ACPI GPU.

Pembaruan untuk pelaporan target saat waktu memulai adaptor

Ketika adaptor dimulai, adaptor melaporkan semua perangkat anaknya melalui DxgkDdiQueryChildRelations DDI. Laporan ini mencakup target internal apa pun yang terhubung ke mux. Sasaran internal mencakup DXGK_CHILD_CAPABILITIES.Type.IntegratedDisplayChild.DescriptorLength kolom.

Masalah muncul jika mux dialihkan ke GPU lain saat adaptor dimulai. Dalam situasi ini, driver tidak dapat berkomunikasi dengan panel internal untuk mengkueri ukuran EDID/DisplayId. Dengan demikian, driver yang mengekspos antarmuka GUID_WDDM_INTERFACE_DISPLAYMUX_2 harus diatur DXGK_CHILD_CAPABILITIES. Type.IntegratedDisplayChild.DescriptorLength ke nol saat adaptor dimulai jika mux saat ini tidak dialihkan ke GPU driver. Jika tidak, OS gagal memulai adaptor.

OS memperbarui informasi internalnya tentang ukuran deskriptor internal pada operasi pengalihan mux pertama.

Pembaruan untuk perubahan koneksi

Seperti yang disebutkan sebelumnya, ada metode khusus yang ditujukan untuk ADS dalam melaporkan status panel internal selama rangkaian pengalihan tampilan otomatis. Untuk menunjukkan bahwa paket perubahan koneksi adalah bagian dari urutan pengalihan ADS, bendera DisplayMuxConnectionChange ditambahkan ke DXGK_CONNECTION_MONITOR_CONNECT_FLAGS. Saat DisplayMuxConnectionChange diatur, ini menunjukkan bahwa MonitorStatusConnected atau MonitorStatusDisconnectedstatus koneksi terkait dengan sakelar tampilan otomatis.

DisplayMuxConnectionChange hanya boleh digunakan selama pengalihan ADS dan tidak boleh digunakan untuk tujuan lain. Ini seharusnya digunakan pada kesempatan ADS yang berikut:

Saat driver memproses DxgkDdiDisplayMuxPreSwitchAway.

Jika panel internal terhubung, driver harus menambahkan paket DXGK_CONNECTION_CHANGE ke daftar perubahan koneksinya dengan DXGK_CONNECTION_CHANGE.ConnectionStatus diatur ke MonitorStatusDisconnected dan DXGK_CONNECTION_CHANGE.MonitorConnect.MonitorConnectFlags.DisplayMuxConnectionChange diatur ke 1. Pengaturan-pengaturan ini menunjukkan kepada OS bahwa driver telah melepaskan kontrol panel internal.
Saat driver memproses DxgkDdiDisplayMuxPostSwitchToPhase1.
- Driver harus terlebih dahulu menentukan apakah panel internal tersambung.
- Jika panel tersambung, driver harus menambahkan paket DXGK_CONNECTION_CHANGE ke daftar perubahan koneksinya dengan DXGK_CONNECTION_CHANGE.ConnectionStatus diatur ke MonitorStatusConnected dan DXGK_CONNECTION_CHANGE.MonitorConnect.MonitorConnectFlags.DisplayMuxConnectionChange diatur ke 1.
- Jika panel tidak tersambung, driver harus menambahkan paket DXGK_CONNECTION_CHANGE ke daftar perubahan koneksinya dengan DXGK_CONNECTION_CHANGE.ConnectionStatus diatur ke MonitorStatusDisconnected dan DXGK_CONNECTION_CHANGE.MonitorConnect.MonitorConnectFlags.DisplayMuxConnectionChange diatur ke 1.
Saat pengemudi memproses DxgkDdiDisplayMuxSwitchCanceled.
- Semua paket perubahan yang ditambahkan oleh driver di DxgkDdiDisplayMuxSwitchCanceled harus diatur sehingga DXGK_CONNECTION_CHANGE.MonitorConnect.MonitorConnectFlags.DisplayMuxConnectionChange bernilai 1.
Dalam kejadian permintaan polling target masuk selama perpindahan, DisplayMuxConnectionChange hanya boleh diatur untuk paket perubahan koneksi yang ditambahkan dari DxgkDdiDisplayMuxPreSwitchAway, DxgkDdiDisplayMuxPostSwitchToPhase1, atau DxgkDdiDisplayMuxSwitchCanceled.

Petunjuk terbaru untuk DxgkDdiSystemDisplayEnable

Saat DDI driver ADS DxgkDdiSystemDisplayEnable(/windows-hardware/drivers/ddi/dispmprt/nc-dispmprt-dxgkddi_system_display_enable) dipanggil, driver harus memastikan bahwa PSR dinonaktifkan di akhir panggilan DxgkDdiSystemDisplayEnable DDI tersebut.

Panduan OEM

Ada beberapa aspek dari fitur ADS yang berada di bawah kendali tingkat sistem operasi pada platform. Sangat penting bahwa OEM memastikannya berfungsi dengan baik. Daftar berikut ini merangkum beberapa poin utama yang perlu dipertimbangkan OEM:

Driver terintegrasi hibrid dan diskrit hibrid harus mendukung ADS.
Mux yang dipilih untuk platform dapat dikontrol melalui ACPI.
Metode _HID, DMQU, dan DMCF yang berada di bawah perangkat mux serta perangkat ACPI bawahan GPU untuk target internal telah diimplementasikan dan memiliki metode DMID ACPI.
Kedua perangkat ACPI GPU harus memiliki _DEP untuk menandai ketergantungannya ke perangkat ACPI mux.
Antarmuka/batas/rentang kecerahan yang diekspos oleh kedua GPU sama persis.
Seperti yang dirinci di bagian data kecerahan, antarmuka kecerahan V3 sangat direkomendasikan atas antarmuka kecerahan V2.
Jika driver panel monitor digunakan, kode harus independen GPU; artinya, logika yang sama dapat digunakan ketika salah satu GPU mengendalikan panel.
Setidaknya untuk mux internal, tindakan mengalihkan muks seharusnya tidak menghasilkan peristiwa HPD.
Jika OEM ingin menonaktifkan mux dalam sistem, metode DMQU ACPI harus mengembalikan 0 ketika dipanggil dengan Arg0 diatur ke 2.
Mux harus dapat beralih antar GPU bahkan ketika driver dalam daya rendah. Dalam hal ini, PSR tidak akan digunakan.
Ketika mux beralih dari satu GPU ke GPU lainnya, kecerahan panel harus dipertahankan tanpa gangguan kecerahan. Ada beberapa cara untuk melakukannya, termasuk cara-cara berikut. OEM bertanggung jawab untuk memastikan sistem mempertahankan kecerahan di seluruh sakelar.
- Gunakan kontrol kecerahan yang berbasis DisplayPort Aux Nits.
- Gunakan Tcon dengan rekonstruksi PWM untuk menghindari anomali kecerahan.
Panel dan Tcon yang digunakan dapat tetap dalam refresh mandiri (PSR1 untuk eDP) ketika konfigurasi tautan pra-switch dan pasca-switch diekspos oleh EDID dan didukung oleh iGPU dan dGPU. Ini termasuk tetapi tidak terbatas pada:
- Frekuensi penyegaran
- Ukuran aktif
- Jumlah jalur eDP yang digunakan dan lebar pita jalur
- Pengaturan eDP DSC
- Versi eDP VSC SDP yang digunakan
- Versi dan fitur PSR yang digunakan untuk skenario yang tidak melibatkan switch

Saran dan Komentar

Apakah halaman ini membantu?

Last updated on 2025-02-06

Bagikan melalui

Pengalih layar otomatis

Ikhtisar

Desain tingkat tinggi

Kontrol perangkat mux

Mengekspos perangkat mux

Fungsi driver mux

DDI sakelar tampilan otomatis

Berbagi data antara GPU0 dan GPU1

Interoperabilitas driver

Urutan pengalih

Proses pemulihan

Peristiwa tidak biasa yang dapat terjadi selama pengalihan

Skenario penutupan tutup

Saat OS menganggap bahwa driver menguasai panel

Mengendalikan penyegaran mandiri pada panel (PSR)

Memastikan panel tetap berada di PSR selama pengalihan

EDID panel internal

Bagaimana OS memutuskan apakah fitur ADS diaktifkan pada sistem dan pengalihan diizinkan

Mengontrol kualitas peluncuran fitur ADS

Tampilkan atribut yang harus tetap sama setelah penggantian tampilan

Pengaturan Kompatibilitas GPU yang cocok untuk pengalaman beralih yang mulus

Masalah jika GPU1 tidak mendukung laju penyegaran yang dijalankan oleh GPU0 pada panel tersebut.

HDR dan Dolby Vision

Cahaya malam

Profil warna

Menampilkan layar pengecekan bug

Algoritma kecemerlangan adaptif berdasarkan konten

Data kecerahan

Konfigurasi boot mux

Memberikan informasi mux kepada driver

Waktu mulai adaptor

Transisi D0

Urutan proses booting

Panel pengemudi

Mengidentifikasi target yang dikendalikan oleh multiplexer

PnP menghentikan adaptor yang memindai ke target

GPU plugin/eksternal tidak didukung

ADS terbatas pada panel internal tunggal saja

Perubahan kebijakan adaptor POST saat ini

Nonaktifkan efek visual saat monitor terhubung

Menonaktifkan bonk PnP

Pemberitahuan aplikasi

API untuk memicu saklar

Menampilkan API terkait dan perilaku Win+P

Uji HLK

Panel internal GPU HPDing saat mux dialihkan dari GPU tersebut

Transisi AC/DC

Transisi daya sistem

Urutan transisi kekuatan

Sistem All In One (AIO)

Perangkat MUX ACPI

Metode ACPI perangkat Mux

Metode _HID (ID Perangkat Keras)

Metode DMQU (Display Mux Query)

Metode DMCF (Konfigurasi Mux Tampilan)

Metode ACPI perangkat GPU

Metode ACPI perangkat anak GPU

Metode DMID (Pengidentifikasi Mux Tampilan)

Contoh

Perubahan API

Menghitung perangkat mux dalam sistem

Antarmuka IDisplayMuxDevice

Perubahan DDI WDDM untuk pengalihan tampilan otomatis

Mengkueri antarmuka dukungan ADS KMD

Fungsi KMD untuk mendukung ADS

Pelaporan Kemampuan ADS oleh Driver

Pembaruan untuk pelaporan target saat waktu memulai adaptor

Pembaruan untuk perubahan koneksi

Petunjuk terbaru untuk DxgkDdiSystemDisplayEnable

Panduan OEM

Saran dan Komentar

Sumber Daya Tambahan: