Aracılığıyla paylaş

Otomatik ekran anahtarı

Önemli

Bazı bilgiler, ticari olarak piyasaya sürülmeden önce önemli ölçüde değiştirilebilen yayın öncesi bir ürünle ilgilidir. Microsoft, burada sağlanan bilgilerle ilgili olarak açık veya zımni hiçbir garanti vermez.

Bu makalede, dizüstü bilgisayarın dahili panelinin tümleşik GPU (iGPU) ile ayrık GPU (dGPU) arasında sorunsuz bir şekilde geçiş yapma desteği sağlayan otomatik ekran anahtarı (ADS) özelliği açıklanmaktadır. ADS, Windows 11, sürüm 24H2 güncelleştirme 2025.01D 'den (WDDM 3.2) başlayarak desteklenen isteğe bağlı bir WDDM özelliğidir.

Bu makalede:

  • GPU0, tümleşik panelin şu anda bağlı olduğu GPU'ya karşılık gelir.
  • GPU1, panelin bağlanacağı GPU'yu temsil eder.

Genel bakış

Bazı dizüstü bilgisayarlarda dahili panelin tümleşik GPU (iGPU) ile ayrık GPU (dGPU) arasında geçiş yapmasına olanak tanıyan bir çoklayıcı (mux) cihazı vardır. Grafik sürücüsü şu anda işletim sisteminin bilgisi olmadan bu dizüstü bilgisayarlarda geçişi tetikler ve gerçekleştirir, bu da bazı istenmeyen kullanıcı deneyimlerine yol açar.

ADS, işletim sisteminin dahili panele tarama yaparken iGPU ile dGPU arasında geçiş yapmak için sistemde bir mux cihazının kullanımını denetlemesini sağlar. Bu nedenle işletim sistemi daha iyi bir kullanıcı deneyimi sağlayabilir.

ADS'nin ilk sürümü yalnızca iç paneli iGPU ve dGPU arasında değiştirmeyi destekler. Gelecekte bu özellik, dizüstü bilgisayarlardaki dış bağlayıcıların muxing özelliğini de destekleyecek şekilde genişletilebilir.

Üst düzey tasarım

Genel olarak sistem, geçiş sürecindeyken iç panelin içeriğinin titreme veya bozulma olmadan görüntülendiğinden emin olmalıdır. İşletim sistemi bu işlevselliği belirli bir görüntü protokolüyle kısıtlamaz. Bu makalede, eDP ile ADS'nin nasıl uygulanacağı ele alınmaktadır, ancak kullanılabilecek daha fazla endüstri standardı vardır (örneğin, MIPI veya DSI). Platform tasarımı, başka bir işletim sistemi değişikliği olmadan aynı deneyimi elde edebilirse başka bir görüntü bağlantısı protokolü kullanabilir.

Bu bölümdeki alt bölümler, özelliğin tasarım yönlerini tanımlar ve her yönü için üst düzey yaklaşımı ayrıntılı olarak açıklar.

Mux cihazının denetimi

iGPU ve dGPU grafik sürücüleri arasındaki bağımlılıkları azaltmak için mux, işletim sisteminin grafik sürücülerinden bağımsız olarak denetleyebileceği ayrı bir cihaz olarak kullanıma sunulur. Bu yaklaşımın avantajları şunlardır:

  1. Grafik sürücüsü, bir OEM'in kullanabileceği her farklı mux'un nasıl denetlendiğini bilmesi gerekmediğinden, karmaşıklığını azaltır.
  2. Grafik sürücüleri arasındaki bağımlılıkları azaltır veya ortadan kaldırır; bu da sürücü güncelleştirmelerini azaltır ve OEM'lerin GPU'ları ve müsleri seçmesini kolaylaştırır.
  3. Grafik sürücüsü kullanılamadığında işletim sistemi mux'ı değiştirebilir.

Mux cihazını açığa çıkarma

Bu çözüm iç iGPU ve dGPU arasında muxing için olduğundan, ACPI aracılığıyla mux'ı kullanıma sunmanız mantıklıdır.

Mux sürücüsünün işlevselliği

Mux sürücüsünün aşağıdaki üst düzey işlevsel gereksinimleri karşılaması gerekir:

  1. Mux'un durumunu, şu anda hangi hedefin iç paneli kontrol ettiğini ve herhangi bir yetenek sınırını sağlamalıdır.
  2. Anahtarı tetiklemenin ve anahtarın durumunu raporlamanın bir yolunu sağlaması gerekir.

mux ACPI cihazı ve yöntemleri hakkında daha fazla bilgi için bkz. ACPI.

Sorunsuz bir geçiş gerçekleştirmek için, mux cihazı, GPU geçişi sırasında her zaman aşağıdaki koşulları gerektirir:

  1. Panel gücü. Herhangi bir zamanda, panel gücünün GPU'lardan biri aracılığıyla mux'a sağlanması gerekir. Her iki GPU'nun da panel gücünü aynı anda sağlaması sorun değildir.
  2. Parlaklık kontrol sinyalleri, geçiş sırasında her iki GPU'dan etkinleştirilir.
  3. Geçiş sırasında her iki GPU'dan parlaklık düzeyi (darbe genişliği modüle edilmiş).

Mux, aşağıdaki bilgileri iki GPU ile panel arasında değiştirir:

  1. Parlaklık özellikli denetim sinyali
  2. Parlaklık düzeyi (darbe genişliği modüle edilmiş)
  3. DisplayPort (DP) Aux satırı
  4. Sıcak takma algılama (HPD) hattı
  5. DP veri satırı

Mux, panel etkin olmadığında geçiş yapabilme özelliğine sahip olmalıdır. En azından dahili panelde mux'un değiştirilmesi, geçiş sırasında GPU'ya herhangi bir HPD sinyali tetiklememelidir.

GPU sürücüsü hiçbir zaman mux ACPI yöntemlerini çağırmamalıdır.

Otomatik görüntü değiştirici DDI

Mux gereksinimlerini karşılamak için çeşitli DDI'ler eklenir. İşletim sistemi, bir multiplex (mux) anahtarlama sırasında sürücünün DDİ'lerini (Sürücü Arabirim Tanımlamaları) çağıran beş farklı noktada aşağıdaki işlevleri kullanır. Çeşitli çağrılar, değiştiricinin hangi aşamada olduğuna ve ekranın kontrolünü şu anda elinde tutan GPU'nun sürücü tarafından denetlenip denetlenmediğine bağlıdır.

DDI Açıklama
DxgkDdiDisplayMuxPreSwitchAway Ekrana bağlı olan sürücüyü arayın. Bu çağrı, sürücüye sistemin ekranı başka bir GPU'ya (GPU0'dan GPU1'e) değiştirmeyi planladığını bildirir.
DxgkDdiDisplayMuxPreSwitchAwayGetPrivateData Panele bağlı olan sürücüden (GPU0'dan) herhangi bir özel anahtar verisi toplamak için arayın.
DxgkDdiDisplayMuxPreSwitchTo Şu anda ekrana bağlı olmayan sürücüye çağrı. Bu çağrı, sürücüye işletim sisteminin ekranı bu GPU'ya (GPU1) değiştirmeyi planladığını bildirir.
DxgkDdiDisplayMuxSwitchCanceled Anahtar dizisinin anahtar tamamlanmadan önce iptal edilmiş olduğunu belirtmek için sürücüye çağrı yapın.
DxgkDdiDisplayMuxPostSwitchAway Mux anahtarı tamamlandı ve GPU0'un sürücüsü artık ekrana bağlı değil.
DxgkDdiDisplayMuxPostSwitchToPhase1 Mux anahtarı tamamlandı ve GPU1'in sürücüsü artık ekrana bağlı. Bu sürücü artık 1. aşama görevlerini gerçekleştirmelidir.
DxgkDdiDisplayMuxPostSwitchToPhase2 Mux anahtarı tamamlandı ve GPU1'in sürücüsü artık ekrana bağlı. Bu sürücü artık 2. aşama görevlerini gerçekleştirmelidir.
DxgkDdiDisplayMuxUpdateState Bağdaştırıcı başlatma sırasında çağrılır ve sürücüye geçerli mux durumunu bildirmek için D0 güç durumuna dönün.

Sürücünün her aşamada tamamlaması gereken açık eylemler vardır. Bu eylemler bu makalenin devamında açıklanmıştır.

ADS ile ilgili DDI güncelleştirmelerinin tam listesi için bkz. otomatik görüntü değiştirme için WDDM DDI değişiklikleri.

GPU0 ile GPU1 arasında veri paylaşma

Aşağıdaki durumlarda daha iyi bir kullanıcı deneyimi oluşturulabilir:

  • GPU0 ve GPU1 aynı IHV'dendir.
  • GPU0, işletim sistemi tarafından görülemeyen ekran yapılandırmasıyla ilgili bilgileri GPU1'e iletebilir.

Veri blobu, GPU1 sürücüsünün veri blobunu anlayıp anlayamayacağını hızla belirleyebileceği bir GUID ile açıklanır. Genel bir bakışla, işletim sistemi, geçişten önce blob GUID'sini ve verilerini elde etmek için GPU0'ı çağırır ve bu verileri ekranda HPD'ye gerek kalmadan önce GPU1'e iletir.

GPU1'in sürücüsü şu işlemlerden sorumludur:

  • Blobun GUID'sini anlayıp anlamadığını kontrol etme.
  • Blobdaki hatalı biçimlendirilmiş verilerden kaynaklanan zararlı etkileri önlemek için blobdaki her veri öğesini doğrulama.

Sürücü birlikte çalışabilirliği

WDDM sürücüsü ADS'yi destekliyorsa, hangi OEM sisteminde çalıştırıldığına veya sistemdeki diğer GPU'nun ne olduğuna bakılmaksızın ADS'yi desteklemesi gerekir.

Şalter sırası

Gpu'nun sürücüsü durdurulduğunda bir GPU'dan uzaklaşmak teknik olarak mümkün olsa da, bu senaryo şu anda desteklenmemektedir. Bu nedenle, anahtarlama yalnızca iki GPU'da da DDI geçişini destekleyen sürücüler yüklü olduğunda gerçekleştirilir.

Panel etkin olduğunda, GPU0 ve GPU1 sırasıyla iGPU ve dGPU'yu temsil ederken, aşağıdaki sıra tüm anahtar dizisinin genel bir görünümünü sunar. GPU0 şu anda çoklayıcı (mux) üzerinden dahili panele bağlı ve GPU1'in panele çıkış yapmasını sağlamak istiyoruz.

  1. API seviyesinde bir anahtarlama çağrısı yapılır.
  2. İşletim sistemi, geçerli iç panel durumunun (HDR, mod, yenileme hızı vb.) özniteliklerini toplar ve geçici ekran modunu denetler.
  3. İşletim sistemi, sistemdeki herhangi bir GPU'dan gelen HPD'ler nedeniyle herhangi bir görüntü topolojisi gerçekleştirilmesini devre dışı bırakır.
  4. İşletim sistemi, GPU1 sürücüsünün DxgkDdiDisplayMuxPreSwitchToçağrısını yaparak geçerli parlaklık düzeyini iletir. Sürücü yalnızca kapak açıksa aşağıdakileri yapmalıdır:
    • Panelin gücünü açın.
    • Parlaklığı etkinleştirme sinyalini ayarlayın.
    • İşletim sisteminin geçtiği parlaklık düzeyini ayarlayın.
  5. İşletim sistemi, kapak HPD'sinin mux anahtarından sonraya kadar işlenmemesini sağlamak için GPU0'da DxgkDdiQueryConnectionChange çağırmayı devre dışı bırakır.
  6. İşletim sistemi, etiketli GPU0 sürücüsünün DxgkDdiDisplayMuxPreSwitchAway DDI çağrısını yapar. Sürücü şunları yapmalıdır:
    • Kapak etkinse panelde PSR1'i (panel kendi kendine yenileme 1) etkinleştirin ve işletim sistemi daha sonra devre dışı bırakılmasını isteyene kadar devre dışı bırakılmadığından emin olun.
    • DXGK_CONNECTION_CHANGE'ın ConnectionStatus monitorStatusDisconnected ve MonitorConnect.MonitorConnectFlags.DisplayMuxConnectionChange 1 olarak ayarlanmış bağlantı değişikliği listesine bir paket ekleyin.
    • GPU0, kapak hedefi için herhangi bir bağlantı değişikliği paketi kuyruğuna ekleyemez. İşletim sistemi hatası, bunu yapıp yapmadığını kontrol eder.
    • Herhangi bir özel ADS veri blobunun (GUID ve veri) boyutunu işletim sistemine döndür. GPU0 sürücüsü bu çağrıda başarısız olursa, kuyruğa yerleştirdiği herhangi bir ADS bağlantı durumu paketinin dönmeden önce kaldırıldığından emin olması gerekir.
  7. GPU0'un sürücüsü sıfır olmayan bir özel veri boyutu döndürdüyse, işletim sistemi bu boyutu ayırır ve özel geçiş verilerini almak için DxgkDdiDisplayMuxPreSwitchAwayGetPrivateData geri çağırmasına GPU0'un geçirir.
  8. İşletim sistemi, GPU0'dan GPU1'e geçmek için mux'un ACPI yöntemini çağırır.
  9. İşletim sistemi, GPU0'un DxgkDdiQueryConnectionChange yeniden çağrılmasına imkan verir.
  10. İşletim sistemi, GPU0'un DxgkDdiQueryConnectionChanges çağrısını, MonitorStatusDisconnected bağlantı paketini işlemek üzere DisplayMuxConnectionChange 1 olarak ayarlanmış şekilde gerçekleştirir.
  11. İşletim sistemi, geçiş yapılan ekranın yolunu devre dışı bırakmak için GPU0'un DxgkddiSettimingsfromvidpn'sini çağırır. GPU0'ın sürücüsü şunu yapmalıdır:
    • Panelin gücünü kapatın.
    • Parlaklık sinyalini devre dışı bırakın.
    • Parlaklık düzeyini mux'a göndermeyi durdurun.
  12. İşletim sistemi, ekranın kalkışını işler. Gereksiz topoloji değişikliklerini önlemek için topoloji değişikliği tetiklemez.
  13. İşletim Sistemi, GPU0'dan elde ettiği herhangi bir ADS özel blobunu ileterek, GPU1'in DxgkDdiDisplayMuxPostSwitchToPhase1 geri çağrısını yapar. Sürücü şunları yapmalıdır:
    • Kapağın açık mı yoksa kapalı mı olduğunu belirleyin.
    • Paketi DXGK_CONNECTION_CHANGEbağlantı değişikliği listesine ekleyin:
      • MonitorConnect.MonitorConnectFlags.DisplayMuxConnectionChange bit kümesi.
      • ConnectionStatus, kapağın açık olması durumunda MonitorStatusConnected veya kapak kapalıysa MonitorStatusDisconnected olarak ayarlanır.
    • Kapak kapalıysa, güç ve parlaklık sinyalini panele kapatın.
  14. İşletim sistemi henüz GPU1'in iç hedefi için DXGKQAITYPE_INTEGRATED_DISPLAY_DESCRIPTOR2 ile DxgkDdiQueryAdapterInfo çağırmadıysa, bunu yapar. Bu çağrının sonucu olarak, işletim sistemi DxgkDdiQueryDeviceDescriptor çağırır.
  15. İşletim sistemi, olayı bağlantı değişikliği listesinde işlemek için GPU1'in DxgDdiQueryConnectionChange'ü çağırdı. Bu çağrı, yeni takılan monitör için DxgkDdiQueryDeviceDescriptor çağrısının yapılmasını sağlar.
  16. İşletim sistemi, HPD'ler nedeniyle görüntü topolojisi değişikliklerini etkinleştirir.
  17. İşletim sistemi, DisplayMuxConnectionChange 1 olarak ayarlandığında, GPU0 ve GPU1'den gelen bağlantı paketlerini asenkron olarak işler.
  18. GPU1 MonitorStatusConnected kuyruğa alındıysa:
    • İşletim sistemi, modları numaralandırmak için GPU1'in DWM işlevlerini çağırır.
    • DxgkddiSettimingsfromvidpn, ekran yolunu etkinleştirmek için GPU1'de çağrılır.
    • DWM, çerçeveyi işler ve GPU1 üzerindeki görüntü yoluna sunar.
    • İşletim sistemi, ilk çerçevenin görünür olmasını bekler.
  19. İşletim sistemi, GPU1'in DxgkDdiDisplayMuxPostSwitchToPhase2 geri çağırmasını çağırır. Bu geri çağırma sırasında, eğer MonitorStatusConnected GPU1 tarafından kuyruğa alındıysa, sürücünün ekran için PSR1'i kapatması gerekir; aksi takdirde sürücü hiçbir işlem yapmamalıdır.
  20. İşletim sistemi GPU0'un DxgkDdiDisplayMuxPreSwitchAwayçağırır. Sürücüden beklenen bir eylem olmasa da, bu çağrı geçişle ilgili tüm sürücü temizleme veya kayıt işlemleri için kullanışlıdır.
  21. İşletim sistemi, geçerli iç panel durumunun özniteliklerini toplar. Panel durumu daha önce kaydedilenden farklıysa işletim sistemi telemetriyi tetikler.

Bu anahtar dizisi iGPU->dGPU ve dGPU->iGPU için aynıdır. Panel devre dışıyken mux'ı değiştirme durumları olabilir. Bu durumda, bu dizi gerekli değildir ve işletim sistemi geçiş yapmak için mux üzerinde ACPI yöntemlerini çağırabilir.

İşletim sisteminin çoğu sürücünün PSR modunda olduğunu bilmiyor. Sonuç olarak, kullanıcının bu olayları görmemesine rağmen sürücünün yine de Vsync eşitlemeleri oluşturması, geçişleri tamamlandı olarak rapor etmesi ve benzerlerini yapması gerekir.

Kurtarma işlemi

Anahtar dizisinin herhangi bir aşamasında bir arıza olursa, aşağıdaki düzeltici işlem gerçekleştirilir:

  1. Eğer GPU0'un DxgkDdiDisplayMuxPreSwitchAway başarıyla çağrıldıysa ancakDxgkDdiDisplayMuxPostSwitchAway çağrılmadıysa, işletim sistemi GPU0'un DxgkDdiDisplayMuxSwitchCanceled'ü çağırır.
  2. İşletim sistemi, GPU1'in DxgkDdiDisplayMuxPreSwitchTo başarıyla çağrıldıysa ancak DxgkDdiDisplayMuxPostSwitchToPhase2 çağrılmadıysa, GPU1'in DxgkDdiDisplayMuxSwitchCanceled işlevini çağırır.
  3. İşletim sistemi devre dışı bırakılırsa görüntü topolojisi değişikliklerini yeniden etkinleştirir.
  4. İşletim sistemi, devre dışı bırakılırsa GPU0'da DxgkDdiQueryConnectionChange çağırmayı yeniden etkinleştirir.
  5. İşletim sistemi, kapağın bağlı olduğu GPU'da kapak bağlantısını kontrol eder.
  6. İşletim sistemi, belirlenmiş bir ekran yapılandırması (SDC) sıfırlaması tetikler. Mux üzerinden panelin bağlandığı sürücü (-DxgkDdiDisplayMuxSwitchCanceled döndürüldü) PSR'nin devre dışı olduğundan emin olmalıdır.

Geçiş sırasında gerçekleşebilecek olağan dışı olaylar

  • Kullanıcı monitörü takar veya çıkarır

    Anahtar dizisinin bir parçası olarak işletim sisteminin HPD olaylarını işlemesini devre dışı bırakırız. Bu şekilde, herhangi bir HPD, kapakla birlikte kuyruğa alınır ve tek bir atomik işlemle işlenir.

  • Başka bir uygulama, geçiş sırasında SDC'yi çağırır

    Geçiş sırasında, SDC'ye yapılan çağrılar engellenir ve geçiş tamamlandıktan sonra yürütülür.

  • Sürücü geçiş sırasında devre dışı bırakılır

    Bir sürücü durdurulduğunda, anahtar dizisindeki çağrılar başarısız olur ve kurtarma dizisi etkinleştirilir. PnPStop bölümü ekranın her zaman görünür olmasını nasıl sağladığını da açıklar.

Kapak kapatma senaryoları

Sürücü genellikle kapak açma/kapatma olaylarını algılamak için aşağıdaki yaklaşımlardan herhangi birini kullanabilir:

  • Kapak durumunu DxgkDdiNotifyAcpiEventolayından izle (DxgkPowerStateEvent, PO_CB_LID_SWITCH_STATE)
  • PoRegisterPowerSettingCallback(GUID_LIDSWITCH_STATE_CHANGE) geri çağırımından kapak durumunu izleyin.
  • Farklı, platforma bağımlı bir yol.

Ancak genel olarak WDDM için sürücülerin DxgkDdiNotifyAcpiEvent yaklaşımını kullanması gerekir çünkü Dxgkrnl durumu ve sürücü durumu senkronize olur. Hem iGPU hem de dGPU'nun bir anahtar dizisinde GPU1 olabileceği göz önüne alındığında, tüm ADS sürücülerinin kapak başka bir duruma geçirildiğinde bile kapak durumunu izlemesi mantıklıdır.

İşletim sistemi DisplayMuxConnectionChange olayını GPU0'dan işledikten sonra, GPU0'un artık kapak durumunu kontrol etmediğini ve bu nedenle kapak geri açılana kadar GPU0'un bu hedef için daha fazla bağlantı durumu paketi raporlayamayacağını düşünür. GPU0 bunu yaparsa işletim sistemi hata denetimi yapar. İşletim sistemi, GPU1'den DisplayMuxConnectionChange işlemini gerçekleştirdiğinde, GPU1'in kapak durumunu kontrol eden birim olduğunu kabul eder. GPU1'in kapak durumunu bilmesi ve doğru DisplayMuxConnectionChange paketini bildirmesi beklendiğinden, bu iki olay arasında gerçekleşen kapak açma veya kapama olayları göz ardı edilebilir.

İşletim sistemi panele sürücünün sahip olduğunu göz önünde bulundurduğunda

Aşağıdaki tabloda işletim sisteminin panele sahip olacak bir GPU olarak değerlendirdiği sıra aşamaları açıklanmaktadır. Sahip olan GPU, anahtar sırasını kullanarak bağlanma değişikliklerini bildirebilir. Adım numaraları, daha önce açıklanan anahtar dizisinden alınır.

'dan Aşaması Aşama Panel hangi GPU'nun denetlediği
Düğmeden önce 5. Adım GPU0
6. Adım 12. Adım GPU yok
Adım 13 Anahtardan sonra GPU1 (Grafik İşleme Birimi 1)

İşletim sistemi hatası tespiti, GPU paneli kontrol etmediğinde sürücü kuyruğunda çoklamalı hedef için bir bağlantı değişikliği paketi görüp görmediğini kontrol eder.

Kontrol paneli kendi kendini yenileme (PSR)

ADS özelliği, geçiş sırasında oluşan hataları önlemek için PSR kullanır. Özellikle, GPU0 ve GPU1'in hangi PSR modunun kullanılacağı konusunda anlaşmaya varmaması için PSR1 (tam ekran güncelleştirme modu) kullanılır.

PSR1'de bile panelin desteklemesi gereken isteğe bağlı özellikler vardır:

Emilim yeteneği Ayrıntıları Lavabo aracılığıyla kullanıma sunuldu
DPCD & eDP sürümü eDP v1.3 veya üzerini kullanıma sunma. DPCD
PSR Özelliği ve Sürümü Lavabo sürüm 1'i destekleyecektir. DPCD 00070h bit 7:0
PSR durumunu iletmek için VSC SDP desteği Yalnızca PSR için; alıcı, PSR durumunu ve CRC değerini iletmek için en az 2. revizyonu ve en fazla 8 geçerli baytı desteklemelidir. DPCD 170
Lavabo PSR ile ilgili durumu düzgün bir şekilde bildirecektir Alıcı durumu açığa çıkaracaktır; örneğin, bağlantı CRC hatası, RFB depolama hatası, alıcı cihazın kendi kendini yenileme durumu, maksimum yeniden eşitleme çerçevesi sayısı, alıcıdaki son gerçek eşitleme gecikme süresi ve son alınan PSR SDP. DPCD 2008h, 2009h, 200Ah lavabonun doğru durumunu yansıtacaktır.

GPU1, işletim sisteminden DxgkddiSettimingsfromvidpn çağrısının parçası olarak bağlantı eğitimi gerçekleştirdiğinde, sürücü GPU0 tarafından kullanılan DP şeridini ve bant genişliği ayarını bilmez, bu nedenle hızlı bağlantı eğitimi yerine tam bağlantı eğitim dizisi gerçekleştirmesi gerekir. İşletim sistemi GPU'lar arasında herhangi bir PSR ilkesi anlaşması yapmayacaktır, bu nedenle panelin GPU'ların kullanacağı tüm PSR sürümlerini ve özelliklerini desteklemesi gerekir. Örneğin, panelin GPU0'un bazı belirli özelliklerle PSR2 kullanabileceği, ardından anahtar için PSR1'in kullanılacağı, ardından GPU1'in farklı özelliklere sahip PSR2 kullanabileceği bir senaryoyu desteklemesi gerekir.

Geçiş sırasında panelin PSR'de kalmasını sağlama

GPU1 panelde bir mod ayarladığında, panel PSR'deyken GPU1 tarafından ayarlanan bağlantı özniteliklerinin PSR giriş moduyla eşleşeceğinin garantisi yoktur. Örneğin, yenileme hızı veya etkin boyut değişebilir. Bugün DP veya diğer sektör standartlarının, bağlantı öznitelikleri değiştirilirken paneli PSR'de tutabileceğini bildirmesi için bir yolu yoktur. Uzun vadede, bu özelliği DP belirtimine eklemek için çalışmak istiyoruz. Bu gerçekleşene kadar, ADS özellikli bir sistem için, OEM'in EDID'de gösterilen iki birleşim arasında bağlantı öznitelikleri (örneğin, yenileme hızı, etkin boyut) değişirken PSR'da kalabilen bir TCon/panel/Mux bileşimi seçmesi gerekir. Bu yaklaşım, PSR'nin geçiş sırasında etkin tutulmasını sağlar.

işte ADS HLK testinin, değiştirme işlemi sırasında PSR'nin korunduğunu doğrulaması için, işletim sisteminin GPU1 modunu test ettikten sonra PSR'nin etkin olmadığını anlaması için bir yol istiyoruz. Bir zorluk, bağlantı eğitimi boyunca PSR'yi destekleyemezse panelin nasıl tepki vereceklerini tanımlamamasıdır.

DxgkDdiDisplayMuxPostSwitchToPhase2kapsamında, sürücü pWasPanelInPSR'de bir Boole değeri döndürerek işletim sistemine panelin PSR'de olmadığını algılayıp algılamadığını bildirir.

İç panelin EDID'i

İşletim sisteminin bağlı farklı monitörlere sahip görüntü modlarını ve topolojileri seçerken beklenen davranışı sağlaması için, dahili ekran için EDID/DisplayId'yi raporlamak için her iki GPU da gereklidir. Bu gereksinim, görüntü modlarını ve topolojileri depolayan CCD veritabanının dahili ekranı denetleyen GPU'ya bakılmaksızın aynı ayarları seçmesini sağlar.

Sürücülerin işletim sistemine bildirdiği EDID, herhangi bir değişiklik yapılmadan aux komutu kullanılarak panelden sorgulanan EDID olmalıdır.

şu an itibariyle işletim sistemi, bir iç panel bildiren bir sürücü başlatıldığında DxgkDdiQueryAdapterInfo(DXGKQAITYPE_INTEGRATED_DISPLAY_DESCRIPTOR2) çağıracaktır. Mux, bu tümleşik hedeften farklı bir şekilde değiştirilirse, sürücü gerekli bilgileri toplamak için panelle iletişim kuramaz. Çözüm, bir sürücü başlatıldığında ve mux iç hedefinden uzaklaştığında işletim sisteminin DxgkDdiQueryAdapterInfo(DXGKQAITYPE_INTEGRATED_DISPLAY_DESCRIPTOR2) çağrısını mux ilk kez iç hedefe geçene kadar geciktirmesidir.

İşletim sistemi bir sistemde ADS özelliğinin etkin olup olmadığını ve anahtar dönüşümüne izin verilip verilmeyeceğini nasıl belirler?

İşletim sistemi, ADS'nin bir sistemde kullanılabilir olup olmadığını belirlemek için aşağıdaki denetim listesini gerçekleştirir. ADS'in desteklenmesi için tüm denetimlerin geçerli olması gerekir.

  1. Tümleşik hibrit (DXGK_DRIVERCAPS.HybridIntegrated) olarak işaretlenmiş bir GPU vardır ki:
  2. Ayrık hibrit (DXGK_DRIVERCAPS.HybridDiscrete) olarak sınıflandırılmış bir GPU vardır ki:
  3. 1. ve 2. adımlardan ACPI DMID yöntemiyle döndürülen mux ACPI isimleri eşleşiyor.
  4. ACPI mux cihazında ACPI DMQU, DMCF ve DMSL yöntemleri vardır.
  5. Mux ACPI DMQU yöntemi, GPU'lardan birinden iç panel hedefinin ACPI adını döndürdü.
  6. ADS şu anda yalnızca tek bir dahili panele sahip sistemleri destekler.
  7. İki durumdan biri:
    1. GPU0, GPU1 ve Mux ACPI, tam ADS desteği sağladıklarını rapor ediyor.
    2. GPU0, GPU1 ve Mux ACPI'nin tümü deneysel veya tam ADS desteği sunar ve EnableMDMExperimentalFeature kayıt defteri anahtarı ayarlanır.

1. ve 2. koşullar, mux'un değiştirilmesi için her iki bağdaştırıcının da başlatılması gerektiğini ifade eder.

ADS özellik dağıtımının kalitesini denetleme

ADS'nin iyi bir kullanıcı deneyimi sunabilmek için aşağıdaki bileşenlerin tümünün kusursuz bir şekilde birlikte çalışması gerekir:

  1. İşletim sistemi, mux işlevini görüntüler.
  2. Mux geçişi için platform ACPI yöntemleri.
  3. iGPU ve dGPU sürücülerinde görüntü mux değiştirme işlevi.

IHV/OEM'lerin sürümlerde sevk edilebilir olmayan kalite koduna sahip olmalarına yardımcı olmak için, aşağıdaki ADS desteği düzeylerinden herhangi birini sunabilirler:

  • Destek yok: Sürücü herhangi bir ADS işlevini desteklemez.
  • Geliştirme desteği: Sürücü ADS'yi destekler, ancak sürücünün uygulaması hala geliştirme aşamasındadır ve bu amacın ötesinde kullanılmamalıdır.
  • Deneysel destek: Sürücü ADS'yi destekler ancak henüz gemi kalitesinde değildir. İşletim sistemi ADS'yi varsayılan olarak etkinleştirmez, ancak etkinleştirmek üzere yapılandırılabilir.
  • Tam destek: Sürücü, sevkiyat kalitesinde ADS desteği sağlar. İşletim sistemi, sürücünün ADS'yi desteklediğini dikkate alır.

Ekran değişikliğinden sonra aynı kalması gereken görüntüleme öznitelikleri

Görüntü anahtarı aşağıdaki görüntü özniteliklerinden hiçbirini değiştirmemelidir:

  1. Masaüstü çözünürlüğü
  2. VidPn yolu (VidPn kaynak modu, hedef modu, ölçeklendirme vb.)
  3. DPİ
  4. Gece ışığı ayarı
  5. Gama
  6. Görüntü topolojisi
  7. HDR açık/kapalı
  8. SDR beyaz düzeyi
  9. Renk profili
  10. Monitörün OPM hedef türü
  11. Ekran parlaklığı

Sorunsuz geçiş deneyimi için GPU ayarlarıyla eşleştirme

Kullanıcıya sorunsuz bir geçiş deneyimi sunmak için ekran, geçişten öncekiyle aynı şekilde yapılandırılmalıdır. Bu davranışı elde etmek için her iki GPU'da da aynı desteğe ihtiyaç duyan bazı GPU özellikleri vardır. Örneğin, bir GPU HDR'yi destekliyorsa ve diğeri desteklemiyorsa, birinde HDR etkinleştirilmişken diğerine geçiş sorunsuz olmayacaktır.

Aşağıdaki tabloda GPU görüntüleme işlevleri ve özellikleri listelenmektedir ve iki GPU arasındaki hizalama gereksinimleri açıklanmaktadır.

Özellik için sorunsuz destek sağlaması gereken GPU'lar
HDR Panel HDR'yi destekliyorsa, her iki GPU'da da fp16 HDR'yi desteklemesi veya HDR'yi desteklememesi gerekir.
Donanım imleci Hayır. İşletim sistemi, kullanıcıya görünür bir kesinti olmadan farklı imleç özelliklerine uyum sağlar.
MPO Hayır. İşletim sistemi, kullanıcıya görünür bir kesinti olmadan farklı MPO özelliklerine uyum sağlar.
PSR Her iki GPU'da da bu özelliği desteklemesi gerekir.
EDID/DisplayID Her iki GPU da aynı EDID/DisplayId'yi kullanıma sunmalı.
Parlaklık üst sınırı Her iki GPU da aynı parlaklık arabirimini ve parlaklık üst çizgilerini desteklemeli.
Parlaklık düzeyleri Her iki GPU'nun da aynı parlaklık seviyelerini ve aralıklarını sunmaları gerekir.
Çözünürlük Her iki GPU'da da aynı kaynak modlarını ve hedef çözünürlüğü desteklemesi gerekir.
Yenileme hızları Bknz. Sorunu, eğer GPU1, GPU0'un paneli'de çalıştırdığı yenileme hızını desteklemiyorsa, ayrıntılar için.
Dinamik Yenileme Hızı Hayır. İşletim sistemi farklı sanal yenileme hızı desteğine uyarlanır.
Değişken Yenileme Hızı Bknz. Sorunu, eğer GPU1, GPU0'un paneli'de çalıştırdığı yenileme hızını desteklemiyorsa, ayrıntılar için.

GPU1, GPU0'un paneli çalıştırdığı yenileme hızını desteklemiyorsa sorun

GPU1, GPU0 ile aynı modu desteklemiyorsa azaltılmış mod büyük olasılıkla ekran topolojisi veritabanında depolanır. Ardından sistem GPU0'a geri döndüğünde azaltılmış mod ayarlanır. Örneğin, GPU0 120 Hz'i destekliyorsa ancak GPU1 yalnızca 60 Hz'i destekliyorsa aşağıdaki sıra gerçekleşebilir:

  1. Sistem, GPU0'un ekranı denetleyebilmesi ve modun 120 Hz olması için yapılandırılır.
  2. Kullanıcı el ile GPU1'e geçer.
  3. Ekran topolojisi veritabanında ekran için 120 Hz depolanır, ancak GPU1 bunu desteklemez, bu nedenle işletim sistemi 60 Hz'i seçer.
  4. 60 Hz ayarlanır ve görüntü topolojisi veritabanında depolanır.
  5. Kullanıcı el ile GPU0'a geri döner.
  6. Görüntü topolojisi veritabanı veritabanından 60 Hz okur.

En iyi deneyimi sağlamak için OEM, iç panelin maksimum yenileme hızını destekleyen bir iGPU ve dGPU seçmelidir. Bu mümkün değilse ve bir GPU panelin en yüksek yenileme hızını destekleyemiyorsa, panelin yenileme hızını destekleyen GPU'nun aşağıdaki aralıkları içeren Windows Dinamik Yenileme Hızı (DRR) özelliğini desteklemesi gerekir:

  • Diğer GPU'nun en yüksek yenileme hızı.
  • İç panelin en yüksek yenileme hızı.

Örneğin, panel 300Hz'i destekleyebilirse ve iGPU yalnızca 60Hz'i destekleyebilirse dGPU'nun en az 60 Hz ile 300 Hz aralığında VRR'yi desteklemesi gerekir.

Özetlemek gerekirse, yenileme oranı için ADS gereksinimi şu şekildedir:

  1. iGPU ve dGPU, iç panelin maksimum yenileme hızını destekler.
  2. İç panelin maksimum yenileme hızını destekleyen GPU, diğer GPU'nun destekleyebileceği en yüksek yenileme hızından dahili panelin maksimum yenileme hızına kadar bir aralıkla DRR'yi desteklemesi gerekir.

HDR ve Dolby Vision

İşletim sistemi, geçişten önce GPU0'daki iç panelde ayarlandığı gibi, geçişten sonra GPU1 üzerindeki iç panelde aynı HDR/Dolby görüntü durumunu ayarlar. Kullanıcının herhangi bir değişiklik fark etmemesi gerekir.

Gece işığı

Gece ışığı, WDDM gamma veya renk matrisleri ile uygulanır. Her iki durumda da işletim sistemi, geçişten önce GPU0 ile yaptığı gibi, geçişten sonra GPU1 aracılığıyla aynı gece lambası düzeylerini ayarlar.

Renk profili

İşletim sistemi, geçişten önce hangi renk profili uygulanmışsa, geçişten sonra da panele aynı renk profilini uygular.

Hata denetimi ekranını görüntüleme

İşletim sistemi şu anda POST olmayan cihazlarda hata denetimi ekranının görüntülenmesini desteklemektedir. Bir hata denetimi gerçekleştiğinde işletim sistemi:

  • Mux'un değiştirilmesine neden olmaz.
  • Hata denetimi ekranını görüntülemek için geçerli işletim sistemi desteğini kullanır.

Hata denetimini görüntülemek için olası hedefleri değerlendirirken, işletim sistemi başka bir hedefe yönlendirilmiş bir mux'a bağlı hedefleri atlar.

GPU0'dan uzak HPD'nin işlendiği ancak GPU1'den gelen HPD'nin henüz tam olarak işlenmediği kısa bir an vardır. Bu süre boyunca bir hata denetimi gerçekleşirse, kullanıcı hata denetimini görmez. PSR'nin hala etkin olduğu küçük bir süre içinde bir hata denetimi gerçekleşirse, işletim sistemi DxgkDdiSystemDisplayEnableçağırdığında ekranı denetleten sürücü panelin PSR modunda olmadığından emin olmalıdır.

İçerik Uyarlamalı parlaklık algoritması

İdeal bir dünyada, her iki GPU tarafından kullanılan içerik uyarlamalı algoritması da aynı etkiyi üretmelidir. Ancak, büyük olasılıkla aynı etki olmayacaktır ve iç panel değiştirildiğinde kullanıcı bir fark edebilir.

Parlaklık verileri

Kullanıcının, geçişten kaynaklanan bir parlaklık değişikliğini fark etmediğinden emin olmak için, GPU0 ve GPU1 tarafından sunulan tüm parlaklık özniteliklerinin aynı olması gerekir. Bu gereksinim, değiştirme işleminden önce GPU0 üzerindeki herhangi bir parlaklık düzeyinin değiştirme işleminden sonra GPU1'de destekleneceğini garanti eder.

Bunu yapmak için GPU0 ve GPU1 sürücülerinin şunları yapması gerekir:

  1. DXGK_BRIGHTNESS_INTERFACE_2 veya DXGK_BRIGHTNESS_INTERFACE_3aynı parlaklık arabirimini kullanın; burada sürüm 3 kesinlikle önerilir.
  2. Parlaklık v3 arabirimi için her iki sürücünün de nit tabanlı veya ayarlanmamış parlaklığı kullanıma sunmaları gerekir.
  3. Parlaklık v2 arabirimi için, iki sürücünün de GetPossibleBrightnessfonksiyonundan tam olarak aynı parlaklık düzeylerini döndürmesi gerekir.
  4. Parlaklık v3 arabirimi için her iki sürücünün de tam olarak aynı aralıkları döndürmesi gerekir; yani, her sürücü GetNitRangesçağrısından aynı DXGK_BRIGHTNESS_GET_NIT_RANGES_OUT yapıları döndürmelidir.
  5. Sürücünün işletim sistemi tarafından sağlanan parlaklık düzeylerini panele özgü ayarlara dönüştürmek için kullandığı iç tablolar aynı olmalıdır.

Çoğu dizüstü bilgisayarda GPU sürücüsü bu parlaklık düzeyi verilerinin bir kısmını veya tümünü platformdan standart olmayan bir şekilde alır. Bu gereksinimlerin karşılanması için bu platformdan GPU'ya veri değişiminin genişletilmesi gerekebileceğini tahmin ediyoruz.

Parlaklık arabirimi, bağdaştırıcı çalıştırıldığında sorgulansa da, iç panel HPD yapılana kadar işletim sistemi parlaklık arabirimlerinin DDI'lerinden hiçbirini çağırmaz. HPD, mux GPU'ya geçtikten sonra oluşur, böylece sürücü o sırada dahili panelin EDID'sine erişebilir.

Sürücünün PWM'yi desteklemeyen paneller için panel parlaklığını ayarlaması için IHV'ye özgü yollar olduğunu anlıyoruz. Ancak bu yöntem, parlaklığı mux üzerinden hangi GPU'ya bağlı olduğuna bağlı olarak farklı bir IHV'ye özgü şekilde alma desteği gerektirebileceğinden TCon için karmaşıklık ekler.

Mux'un önyükleme yapılandırması

Sistem üretici yazılımı, sistem başlangıç zamanında iç panele hangi GPU'nun bağlı olduğunu denetler. İşletim sistemi, panelin denetiminde en son hangi GPU'nun olduğunu depolar. Ardından, önyükleme sırası sırasında işletim sistemi gerekirse mux'u değiştirir, böylece paneli doğru GPU kontrol eder.

Bir mux anahtarı gerektiğinde önyükleme görüntüsünü korumak için, anahtar yalnızca aşağıdaki durumlarda gerçekleştirilir:

  • Her iki GPU da çalışır durumdadır.
  • İşletim sistemi, çıkışı denetleyen önyükleme grafiklerinden çıkışı denetleyen DWM/shell'e geçiş yaptı.

Bu nedenle, iç paneli kontrol eden GPU'da DxgkddiSettimingsfromvidpn çağrısından sonra geçiş gerçekleşir ve geçiş sırasında panel PSR modundayken, kullanıcı donmuş bir ekranla karşılaşır.

Sürücüye mux bilgileri sağlama

Bu özellik, sürücünün istediği zaman çağırabileceği bir geri arama sağlamak yerine bilgileri sağlamak için işletim sisteminin sürücüyü çağırmasını sağlamak için kasıtlı olarak tasarlanmıştır. Bu yöntem, geçiş sırası sırasında işletim sistemi durumunu sorguladığında, sürücünün kafasının karışmasını önler.

İşletim sistemi, aşağıdaki durumlarda sürücüye geçerli mux durumunu sağlamak için sürücünün DxgkDdiDisplayMuxUpdateState DDI'yi çağırır:

  1. Sürücü başladığında, panel bağlı olmadığında sürücünün sürekli yoklama dizilerinden kaçınmasını sağlar.
  2. Dx'dan D0'ye geri döndüğünüzde. Bazı güç durumlarından dönerken (örneğin hazırda bekletme), üretici yazılımının mux'u sıfırlaması gerekebilir; bu nedenle sürücü durumu bilmiyor.

Bu durumlar ve anahtar dizisinde yer alan normal DDI'ler, sürücünün GPU'nun etkin olduğu herhangi bir zamanda bir mux'un hangi yolla değiştirileceğini belirleyebilmesini sağlar.

Bu özelliğin ilk sürümünde, iç panel etkin olmadığında mux'u değiştirme planı yoktur, bu nedenle tüm anahtarlar aynı sırayla geçer.

Bağdaştırıcı başlangıç zamanı

Bir sürücü başlatıldığında işletim sisteminden gelen yoklama isteklerine yanıt vermesi gerekir. Sürücü, iletişim kurmaya çalışarak mux'un kendilerine geçip geçmediğini keşfetmeye çalışabilir, ancak bu zaman alıcı veya güvenilir olmayabilir. GPU başlangıç dizisinin bir parçası olarak, işletim sistemi mux'a bağlı her bir hedef için önce DxgkDdiDisplayMuxUpdateState DDI'yi çağırır ve ardından bu hedefe geçiş yapılıp yapılmadığını belirtir.

Bir sürücü başlatıldığında işletim sisteminden gelen yoklama isteklerine yanıt vermesi gerekir. Sürücü, işletim sistemiyle iletişim kurarak mux'un GPU'ya geçirilip geçirilmediğini bulmaya çalışsa da bu zaman alıcı veya güvenilir olmayabilir.

Bunun yerine, GPU başlatma dizisinin bir parçası olarak işletim sistemi, mux'a bağlı her bir hedef için DxgkDdiDisplayMuxUpdateState'yi çağırır ve mux'ın o hedefe geçirildiğini belirtir. İşletim sistemi, yoklama DDI'lerini çağırmadan önce mux'un sürücünün GPU'suna geçilip geçilmediğini sürücüye bildirir.

ADS sürücüsü iç paneli işletim sistemine aynı şekilde bildirmeye devam eder ve işletim sistemi iç panel ayrıntılarını sorgulamak için DxgkDdiQueryAdapterInfo(DXGKQAITYPE_INTEGRATED_DISPLAY_DESCRIPTOR2) çağırır. Sürücünün, bir mux'a bağlı herhangi bir hedef için DXGK_CHILD_CAPABILITIES'ndeki HpdAwareness'ün hpdAwarenessInterruptible olarak ayarlanmış olmasını sağlaması gerekir.

D0 geçişi

Bağlı bir mux içeren bir GPU düşük güç durumundan güç kaynağına döndürülürse, işletim sistemi DxgkDdiDisplayMuxUpdateState çağrısı sürücüye mux'un hedefine bağlı olup olmadığını veya diğer GPU'ya geçiş yapıp yapmadığını bildirir.

Önyükleme sırası

Aşağıdaki önyükleme dizisi ADS'e özgü özellikleri vurgular. Bu sıralamada sistem şu şekilde başlatılır:

  • Mux'a bağlı iGPU.
  • Kullanıcının yeniden başlatmadan önceki son yapılandırması mux'un dGPU'ya bağlı olmasıydı.

Önyükleme dizisi doğası gereği zaman uyumsuzdur, bu nedenle bu dizi sadece örnek vermek amacıyla sağlanmıştır.

  1. Sistem açıktır ve iGPU mux üzerinden panele bağlanır.
  2. iGPU, panelde önyükleme ekranını görüntüler.
  3. Windows, iç kapakta önyükleme animasyonunu yükler ve görüntüler.
  4. Hem iGPU hem de dGPU üzerindeki _DEP nedeniyle işletim sisteminin mux sürücüsü iki GPU sürücüsünden önce başlatılır. Mux sürücüsü, mux'un doğru yapılandırıldığından emin olmak için ACPI çağrılarını kullanır. Mux sürücüsü ACPI mux uygulamasının ADS gereksinimlerini karşıladığını doğrular.
  5. Dxgkrnl iGPU için DxgkDdiAddDevice çağırır.
  6. Dxgkrnl, iGPU için DxgkDdiQueryInterface(DXGK_DISPLAYMUX_INTERFACE) çağırır. Geçerli sistem ADS'yi desteklemese bile, sürücü ADS'yi destekliyorsa arabirimini döndürür.
  7. Dxgkrnl, sürücünün ADS destek düzeyini almak için DxgkDdiDisplayMuxGetDriverSupportLevel çağırır.
  8. DxgkrnlDxgkDdiDisplayMuxReportPresence(TRUE) çağrısı yaparak iGPU'ya sistemin işlevsel bir ADS mux içerdiğini bildirir.
  9. DxgkrnlDxgkDdiStartDeviceçağırır. iGPU sürücüsü, iç panel için VidPn hedefi dahil olmak üzere çocukların sayısını döndürür.
  10. DxgkrnlDxgkDdiDisplayMuxGetRuntimeStatus çağırır ve iGPU'nın ADS'yi destekleyip desteklemediğini ve sürücünün sistemden tüm gerekli bilgileri alıp almadığını denetler.
  11. Dxgkrnl, iGPU'nun ortaya çıkardığı her alt öğe için DxgkDdiQueryChildStatus çağırır.
  12. Dxgkrnl, çoklayıcıya bağlı iGPU tarafından bildirilen alt öğeyi bulduğunda, iGPU'ya bu çoklayıcının ilgili hedefe bağlı olduğunu bildirmek için DxgkDdiDisplayMuxUpdateState fonksiyonunu çağırır.
  13. iGPU, bağlı bir dahili monitörü gösterdiği için, Dxgkrnl, DxgkddiSettimingsfromvidpnkullanarak iGPU'da bir mod ayarlar.
  14. Dxgkrnl dGPU sürücüsünü başlatır, ardından dGPU için 5-12 arası adımları yineler.
  15. Dxgkrnl iGPU, dGPU ve mux'un doğru yapılandırıldığını algılar, bu nedenle bir mux çifti ve bu çift için PnP Cihaz Arayüzü özellikleri oluşturur.
  16. Dxgkrnl kayıt defterinden son mux yapılandırmasını okur. Önceki yapılandırma dGPU olduğu için, Dxgkrnl şimdi daha önce açıklanan ve mux’u dGPU’ya geçirmek için tasarlanan mux anahtar dizisini başlatır.

Panel sürücüleri

monitör paneli sürücüleri, EDID'den oluşturulan PnP donanım kimliğine göre yüklenir. EDID'nin aynı kaldığı varsayıldığında, hangi GPU iç paneli kontrol ediyorsa, panel sürücüsü yüklenir. Her iki sürücü de aynı parlaklık işlevselliğini kullanıma sunar. Bu nedenle yükleme herhangi bir soruna neden olmamalıdır ve panel sürücüsünün mux'un denetiminde hangi GPU'nun olduğunu bilmesi gerekmez.

Bir mux denetimlerinin hedeflerini belirleme

İşletim sistemi sürücüyü başlattığında, sürücüden bildirilen alt öğelerle ilgili bilgileri sorgulamak için DxgkDdiQueryChildRelations çağırır. Sürücü, her alt öğe için DXGK_CHILD_DESCRIPTOR yapısını doldurur. AcpiUid üyesi, ACPI ad alanında bu alt öğe altında _ADR yöntemi tarafından döndürülen değer olarak tanımlanır ve bu da işletim sisteminin söz konusu alt öğe için ACPI adını bulmasını sağlar.

ADS için hedef için alt ACPI ad alanı altında olması gereken bir ACPI DMID yöntemi tanımladık. Bu DMID yöntemi, mux cihazının ACPI adını döndürür. İşletim sisteminin hedef için mux ACPI adını bulmasını sağlar.

PnP, hedefe doğru tarama yapmak için bağdaştırıcıyı durduruyor

İç panele giden GPU durdurulduğunda işletim sistemi mux'ı değiştirmez. Aşağıdaki senaryolarda GPU durdurulduğunda farklı durumlardan geçilir.

  1. GPU0 gönderidir. Dahili panele bağlanır ve durdurulur.

    Bu durumda, Temel Görüntü Sürücüsü (BDD) GPU0'da şu anda etkin olan modu devralır ve ekranı güncelleştirmeye devam eder.

  2. GPU0 gönderidir ancak GPU1 dahili panele bağlıdır. GPU0 durduruldu.

    Geçerli işletim sistemi tasarımı nedeniyle BDD, GPU0 üzerinde başlatılır ve bu da görünmez bir monitörün rapor edilmesine ve ekran denetim panelinde görünmesine neden olur.

  3. GPU1 gönderi değildir ve dahili panele bağlıdır. GPU1 durduruldu.

    Geçerli işletim sistemi tasarımı nedeniyle BDD GPU1'de başlatılmaz ve bu nedenle kullanıcı paneli göremez.

  4. GPU1 gönderi değildir. GPU0 dahili panele bağlanır ve GPU1 durdurulur.

    Hiçbir değişiklik olmaz ve hiçbir şey gerçekleşmez. GPU0 panelde görüntülenmeye devam eder.

Senaryo 2 ve 3, kullanıcı için kötü bir deneyim oluşturur. ADS özelliği, bu iki durumu düzeltmek için davranışı değiştirir.

Eklenti/dış GPU'lar desteklenmez

Eklenti GPU'ları ile bu özellik için herhangi bir kullanım örneği olduğunu düşünmüyoruz.

ADS yalnızca tek iç paneller ile sınırlıdır

ADS'in ilk sürümü yalnızca tek iç panelleri destekler. Ancak bu özellik, gelecekte işletim sistemi tarafından desteklendiğinde, minimum sürücü değişikliği ile harici ve birden fazla dahili ekranı destekleyebilecek şekilde tasarlanmıştır.

Geçerli POST bağdaştırıcı politika değişiklikleri

İşletim sisteminde daha önce POST bağdaştırıcısıyla ilgili bazı ilkeler vardı. Örneğin, iç hedefleri kullanıma sunabilen tek bağdaştırıcı POST bağdaştırıcısıydı. Bu tür kısıtlamalar, ADS'nin kullanıma sunulmasıyla işletim sisteminden kaldırılır.

Monitör varış görsel efektlerini devre dışı bırak

Windows 11'de bir monitör bağlandığında, kabuk ve DWM animasyon dizisiyle tepki verir. Bu animasyon, ekran değiştirme senaryolarında devre dışı bırakılmıştır.

PnP bonk'ı devre dışı bırakma

Bir monitör eklendiğinde veya kaldırıldığında, PnP sistemi kullanıcıya bildirmek için bir 'bonk' sesi çalar. Bu 'bonk' ekran değişimi senaryolarında devre dışıdır.

Uygulama bildirimleri

Bir ekran değişimi gerçekleştiğinde, sistem normal HPD kaldırma ve HPD varış kod yollarından geçer. Bu nedenle, tüm normal uygulama bildirimleri normal şekilde tetiklenir; örneğin, HPD çıkışı için PnP bildirimi, HPD içeri girerken ve WM_DISPLAYCHANGE pencere iletileri.

Anahtar tetikleme API'si

Plan, işletim sistemi ve Bağımsız Donanım Üreticisi denetim masasının geçişi devreye sokabilmesi için bir genel API'ye sahip olmaktır.

İç panelin yalnızca tek bir GPU'ya bağlı olduğu göz önünde bulundurulduğunda, görüntü API'leri Win+P işlevselliğiyle birlikte beklendiği gibi çalışır.

HLK testi

GPU sürücüsü veya ACPI üretici yazılımı tam ADS desteği bildiriyorsa ADS HLK testlerini ADS özellikli bir sistemde geçirmesi gerekir.

Mux bu GPU'dan uzaklaştığında GPU HPDing iç paneli

İşletim sistemi, bir sürücünün iç paneli bağlı olarak bildirdiği ancak mux'un o sürücüden uzaklaştırıldığı bir durumda bir hata denetimi tetikler.

AC/DC geçişi

ADS özelliğinin ilk sürümü için işletim sistemi AC ve DC mux ayarını depolamaz ve AC <-> DC geçişinde bir mux anahtarı tetiklemez.

Sistem güç geçişleri

Güç geçişlerindeki asıl endişe, üretici yazılımı mux durumunu sıfırladığında (örneğin, hazırda bekletme modu) ve hibarnasyondan devam edildiğinde mux'un geçişten önceki panele geri dönmemesidir.

İlk yaklaşım, hem iGPU hem de dGPU'yi etkinleştirdikten sonra mux'ı dGPU'ya geri döndürmekti. Bu yaklaşımın sorunu, farklı zaman uyumsuz olaylara bağlı olarak sonucun birden çok mod değişikliği olabileceğidir.

Kullanıcı deneyimini kolaylaştırmaya yardımcı olmak için güncelleştirilmiş yaklaşım, sistemin hem iGPU hem de dGPU uykudayken mux'ı beklenen hedefe geri döndürmesi ve böylece birden çok mod değişikliğini önlemesi içindir.

Güç geçişi sırası

Aşağıdaki örnekte, ADS sisteminde hazırda bekleme güç geçişi açıklanmaktadır.

  1. Sistem, dGPU'ya bağlı mux ile yapılandırılır.
  2. Sistem hazırda bekleme moduna girer.
  3. Hem iGPU hem de dGPU, D3 gücüne geçirilir.
  4. Sistem kapanır.
  5. Kullanıcı sistemi çalıştırır.
  6. Üretici yazılımı, dahili panelde mux'ı iGPU ve iGPU ekran başlatma sırasına göre yapılandırıyor.
  7. Dxgkrnl son mux yapılandırmasını (bu örnekte dGPU) okur ve ACPI (bu örnekte iGPU) kullanarak geçerli mux konumuyla karşılaştırır. Dxgkrnl ardından ACPI'yi çağırarak mux'ı dGPU'ya geçirdi.
  8. Dxgkrnl iGPU'nun D0'ye geçişini sağlar, ardından sürücüye mux'un bağlı olmadığını bildirmek için iGPU'nunDxgkDdiDisplayMuxUpdateState çağırır.
  9. Dxgkrnl dGPU'yu D0 durumuna geçirir ve ardından dGPU'nun DxgkDdiDisplayMuxUpdateState çağrısını yaparak sürücüye mux'un bağlı olduğunu bildirir.
  10. Dxgkrnl dGPU'da bir mod ayarlar.

Tümü Bir Arada sistemler (AIO)

ADS'yi desteklemek isteyen herhangi bir AIO sistemi, iç panelin her iki GPU'da da dahili bir hedef türü olarak açıklanmış olmasını sağlamalıdır.

Mux ACPI cihazı

OEM, mux cihazını ACPI ad alanına eklemekten ve mux'ı çalıştırmak için gerekli yöntemleri sağlamakla sorumludur.

Mux cihazı ACPI ağacının herhangi bir yerinde bulunabileceğinden GPU sürücüsü asla mux'un ACPI yöntemlerini çağırmamalıdır. Öneri, her iki GPU'nun en yakın ortak ata noktasının altında mux'u yerleştirmektir.

Geçerli mux cihazları yalnızca iki girişi destekler ve gelecekteki müx'lerin bundan daha fazlasını desteklemesini beklemiyoruz, bu nedenle tasarım her bir mux için iki giriş ve tek bir çıkış varsayabilir.

Sistem çalışırken mux cihazı hiçbir zaman durdurulamıyor. Gizli bir sistem cihazı.

Mux cihaz ACPI yöntemleri

Yalnızca bir ACPI cihazının sürücü yığını, cihazdaki ACPI yöntemlerini değerlendirmek için çağırabilir. Bu nedenle, mux'u değiştirmek için mux cihaz yöntemlerini çağırmak için işletim sisteminin mux cihazı için yüklü bir sürücüye sahip olması gerekir. Bu nedenle, işletim sistemi artık tüm ekran anahtarı mux'ları için sürücü olarak bir ekran mux sürücüsü sağlar.

Bir mux cihazının aşağıdaki yöntemlere sahip olması gerekir:

  • _HID, mux cihazını donanım kimliğine göre tanımlar. ACPI monitör mux için 'MSFT0005' ayırdık.
  • DMQU (Görüntüleme Mux Sorgusu) mux'un geçerli durumunu döndürür.
  • DMCF (Görüntü Mux Yapılandırması) mux'ı yapılandırıyor.

Yöntem _HID (Donanım Kimliği)

Argümanlar:

Hiç kimse

İade:

'MSFT0005' olan donanım kimliğini içeren bir ASCII dizesi.

DMQU Yöntemi (Mux Sorgusunu Görüntüle)

Gelecek bir sürümde sorguya ek bilgiler eklemeyi bekliyoruz. Gelecekte ek sorguları etkinleştirmek için sorgu türünü belirtmek için Arg0 kullanılır. DMQU yöntemi bir sorgu türünü anlamıyorsa, yöntemi desteklenmeyen olarak başarısız olmalıdır.

Argümanlar:

Arg0: Sorgu türünü belirten bir tamsayı. Aşağıdaki tabloda sorgu türü değerleri ve anlamları listelenmiştir.

Sorgu türü değeri Anlam
1 Geçerli anahtar durumunu sorgula
2 Mux ADS destek düzeyini sorgulama
3 Mux'un bağlı olduğu ilk GPU alt öğesini sorgula
4 Mux'un bağlı olduğu ikinci GPU alt öğesini sorgulama

İade:

Yöntem belirtilen sorgu türünü anlarsa, aşağıdaki tabloda açıklandığı gibi uygun verileri döndürmelidir. Yöntem belirtilen sorgu türünü anlamıyorsa boş bir dize döndürmelidir.

Sorgu türü değeri Veri iade etme
1 Mux'un şu anda geçiş yaptığı GPU alt cihazının ACPI adını belirten ASCII dizesi.
2 ADS destek düzeyini temsil eden tamsayı. Ayrıntılar için sonraki tabloya bakın.
3 Mux'un bağlı olduğu ilk GPU alt cihazının ACPI adını içeren ASCII dizesi.
4 Mux'un bağlı olduğu ikinci GPU alt cihazının ACPI adını içeren ASCII dizesi.

Aşağıdaki tabloda ADS destek düzeyi değerleri ve sorgu türü 2 olduğunda anlamları listelenmiştir.

Döndürülen veriler Anlam
0 Destek yok
1 Geliştirme desteği. Ads müşteri sistemlerinde varsayılan olarak devre dışı bırakılacağından, sistemler HLK testlerinden herhangi birini geçirmeden bu ayar ile gönderilebilir.
2 Deneysel destek. Ads müşteri sistemlerinde varsayılan olarak devre dışı bırakılacağından, sistemler HLK testlerinden herhangi birini geçirmeden bu ayar ile gönderilebilir.
3 Tam destek. Ads, desteklenen tam grafik sürücüleriyle eşleştirilmişse bu sistemde varsayılan olarak etkinleştirilir. Sistemin göndermek için ADS HLK testlerini geçmesi gerekir.

DMCF Yöntemi (Görüntü Mux Yapılandırması)

Argümanlar:

Arg0: Mux'un geçiş yapması gereken ACPI GPU alt cihazının ASCII adı.

İade:

0 tamsayısı başarı anlamına gelir; sıfır olmayan hata gösterir. OEM, daha iyi tanılama için sıfır olmayan değeri tanımlayabilir.

GPU cihazı ACPI yöntemleri

GPU için bir grafik sürücüsü başlatılmadan önce sistemin mux ACPI cihazının çalışıp çalışmadiğini ve geçerli durumunu bilmesi gerekir. Bunun için ACPI mux cihazının sürücüsünün zaten başlatılması gerekir. Sistem, cihaz ilişkisini garanti etmek için her GPU'nun ACPI ad alanı altındaki ACPI _DEP yöntemini kullanır.

Gpu'nun zaten bir _DEP yöntemi varsa, mux cihazının ACPI adını döndürülen bağımlılık listesine eklemelidir. GPU'da henüz bir _DEP yöntemi yoksa, bir tane eklemelidir.

ACPI üretici yazılımının yalnızca işletim sistemi ADS'yi destekliyorsa GPU'nun mux'a bağımlılığını bildirmesi için bir ACPI _OSI sorgusu eklenir. ACPI üretici yazılımı, ADS desteğini denetlemek için bu sorguyu kullanabilir. ADS'yi destekleyen işletim sistemi sürümleri, _OSI(“DisplayMux”) ACPI komutuna true döndürerek destek bildirecektir.

GPU alt cihaz ACPI yöntemleri

Bir mux'a bağlı her hedef için, bu çocuğun ACPI cihazı bağlı olduğu mux cihazının ACPI adını döndüren bir ACPI yöntemini kullanıma sunar. Ayrıntılar için bkz. , bir mux'un denetlediği hedefleri belirleme,.

Yöntem DMID (Görüntü Mux Tanımlayıcısı)

Argümanlar:

Hiç kimse

İade:

Bu çıkışın bağlı olduğu ACPI mux cihazının ACPI adını içeren ASCII dizesi

Örnek

Aşağıdaki örnek, iki GPU (GPU0 ve GPU1) ve bir mux içeren bir sistemin ACPI çerçevesi içinde nasıl ayarlandığını ve yönetildiğini gösterir.

  • Mux cihazının ACPI adı 'SB.MUX1'dir.

  • GPU0 için:

    • GPU0'un ACPI adı 'SB'dir. PCI0. GFX0'.
    • VidPn hedefi 0x40f04'ü ortaya çıkarır ve bu, bir DXGK_CHILD_DESCRIPTOR.AcpiUid değerini ile 0x400 olarak bildirir.
    • Mux'a bağlı hedefe karşılık gelen ACPI alt cihaz adı 'SB.PCI0.GFX0.DD1F' şeklindedir.
    • ACPI yöntemi 'SB.PCI0.GFX0.DD1F' altında _ADR 0x400 döndürür. Bu dönüş değeri, işletim sisteminin bu ACPI cihazının VidPn hedef 0x40f04 karşılık olduğunu nasıl bildiğidir.
    • 'SB.PCI0.GFX0.DD1F' altındaki ACPI yöntemi DMID, 'SB.MUX1'i döndürür.

  • GPU1 için:

    • GPU1'in ACPI adı 'SB'dir. PCI0. PEG0. PEGP'.
    • VidPn hedefi 0x1103, 0x100 değeriyle bir DXGK_CHILD_DESCRIPTOR.AcpiUid bildiren birimi açığa çıkarır.
    • Mux'a bağlı hedefe karşılık gelen ACPI alt cihaz adı 'SB.PCI0.PEG0.PEGP.EDP1'dir.
    • 'SB.PCI0.PEG0.PEGP.EDP1' altındaki ACPI yöntemi _ADR 0x100 döndürür. Bu dönüş değeri, işletim sisteminin bu ACPI cihazının VidPn hedef 0x1103 karşılık olduğunu nasıl bildiğidir.
    • 'SB.PCI0.PEG0.PEGP.EDP1' altındaki ACPI yöntemi DMID, 'SB.MUX1'i döndürür.

  • İşletim sistemi, ACPI adı 'SB.MUX1' olan aynı çoklayıcıya bağlı olan GPU0 hedef 0x40f04 ve GPU1 hedef 0x1103'ü bilir.

  • GPU1 şu anda panele bağlıysa, işletim sistemi 'SB.MUX1' üzerinde 'SB.PCI0.GFX0.DD1F' parametresini geçirerek DMCF yöntemini çağırarak mux'u GPU0'a değiştirebilir.

Aşağıdaki ACPI makine dili kodu, örneğin ilgili bölümlerine yöneliktir. Platform mantığı için psödo kod, <>ile sarılmıştır.


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")
            }
        }
    }
}

API değişiklikleri

ADS özelliği aşağıdaki genel API işlevselliğini ekler:

  1. Sistemdeki mux cihazlarını numaralandırın.
  2. Mux hakkındaki sorgu bilgileri; örneğin, bağlı olduğu hedefler ve şu anda hangi hedefe geçtiği.
  3. Bir mux anahtarını tetikle.
  4. Mux'un ne zaman değiştirildiğini algılama.

Sistemdeki mux cihazlarını numaralandırma

Uygulamalar, genel tak çalıştır API'lerini kullanarak işlevli bir görüntü mux'unu temsil eden cihaz arabirimlerini bulabilir. Kullanıcı modu bileşenleri Windows.Devices.Enumeration.DeviceInformationkullanabilir. Mux cihazları listelemek için bu API'lerle C# veya C++ kullanılabilir.

// 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);

IDisplayMuxDevice arabirimi

IDisplayMuxDevice arabirimi, mux cihazını temsil etmek için eklenir.

Aşağıdaki kod, Windows Çalışma Zamanı API'lerini kullanarak görüntü mux cihazlarını numaralandırmayı, durumlarını sorgulamayı, etkin görüntüleme hedefini değiştirmeyi ve durum değişikliklerine tepki göstermeyi gösterir.

#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);
    }
}

Otomatik görüntü geçişi için WDDM DDI değişiklikleri

Bu bölümde, ADS'yi desteklemek için WDDM DDI'da yapılan eklemeler ve değişiklikler açıklanmaktadır. Bu değişiklikler Windows 11, sürüm 24H2 güncelleştirme 2025.01D (WDDM 3.2) ile başlayarak kullanılabilir.

KMD'nin ADS destek arabirimini sorgulama

DXGK_DISPLAYMUX_INTERFACE_2 arabirim yapısı eklenir. ADS sürüm 2'yi desteklemek için gereken işletim sistemi ile sürücü arasındaki çağrıları içerir. İşletim sistemi, sürücünün başlatılması sırasında sürücünün desteklediği ADS arabirimi için sorgusu yapar, ve Arayüz Tipi, GUID_WDDM_INTERFACE_DISPLAYMUX_2 olarak ayarlanmıştır.

(DXGK_DISPLAYMUX_INTERFACE ADS özelliğinin Sürüm 1'ini desteklemek için gereken işletim sistemi-sürücü çağrılarını içerir. Bu sürüm ADS'in ön sürümü sırasında kullanılmıştır.)

ADS'yi desteklemek için KMD işlevleri

KMD, ADS'yi desteklemek için aşağıdaki işlevleri uygular. Dxgkrnl, KMD'nin ADS işlevsel arabirimini, KMD'nin DxgkddiQueryInterfaceçağrısı yoluyla elde eder.

Sürücü raporlama ADS özelliği

Sürücü, işletim sistemi DxgkDdiDisplayMuxGetDriverSupportLevel DDI'yi çağırdığında ADS desteği düzeyini bildirir. Sürücü DXGK_DISPLAYMUX_INTERFACE arabirimini uygulamazsa işletim sistemi destek düzeyinin DXGK_DISPLAYMUX_SUUPORT_LEVEL_NONE olarak kabul eder.

Sürücü, hangi sistemde çalışıyor olursa olsun, ADS destek düzeyini bildirmelidir. Sürücü tarafından bildirilen destek düzeyi yalnızca sürücüye dayanmalıdır. Sürücü, ADS destek düzeyini bildirirken aşağıdaki ölçütlerden hiçbirini dikkate almamalıdır:

  1. Sistem OEM'i.
  2. Sistemdeki diğer GPU'lar.
  3. ACPI mux cihazının varlığı veya olmaması.
  4. GPU'nun ACPI düğümü altındaki ACPI girişlerinin varlığı veya olmaması.

Bağdaştırıcının başlatıldığı zaman için raporlama hedeflerini güncelleme

Bağdaştırıcı başlatıldığında, DDI DxgkDdiQueryChildRelations aracılığıyla tüm alt cihazlarını bildirir. Rapor, bir mux'a bağlı tüm iç hedefleri içerir. Bir iç hedef, DXGK_CHILD_CAPABILITIES.Type.IntegratedDisplayChild.DescriptorLength alanını içerir.

Bağdaştırıcı başlatıldığında mux diğer GPU'ya geçirilirse bir sorun oluşur. Bu durumda, sürücü EDID/DisplayId boyutunu sorgulamak için iç panelle iletişim kuramaz. Bu nedenle, GUID_WDDM_INTERFACE_DISPLAYMUX_2 arabirimini kullanıma sunan bir sürücü, şu anda Mux sürücünün GPU'suna geçiş yapmamışsa, bağdaştırıcı başlatıldığında DXGK_CHILD_CAPABILITIES.Type.IntegratedDisplayChild.DescriptorLength'i sıfıra ayarlamalıdır. Aksi takdirde, işletim sistemi bağdaştırıcının başlatılmasında başarısız olur.

İşletim sistemi, ilk mux anahtar işlemindeki iç tanımlayıcının boyutuyla ilgili iç bilgilerini güncelleştirir.

Bağlantı değişikliği için güncelleştirme

Daha önce belirtildiği gibi, otomatik ekran değiştirme süreci sırasında dahili panel durumunu raporlamanın ADS'e özgü bir yöntemi mevcuttur. Bir bağlantı değiştirme paketinin ADS anahtar dizisinin parçası olduğunu belirtmek için DisplayMuxConnectionChange bayrağı, DXGK_CONNECTION_MONITOR_CONNECT_FLAGS'e eklenir. DisplayMuxConnectionChange ayarlandığında, MonitorStatusConnected veya MonitorStatusDisconnectedbağlantı durumu otomatik görüntü geçişiyle ilişkili olduğunu belirtir.

DisplayMuxConnectionChange yalnızca ADS anahtarı sırasında kullanılmalıdır ve başka amaçlarla kullanılmamalıdır. Aşağıdaki ADS olaylarında kullanılmalıdır:

  • Sürücü DxgkDdiDisplayMuxPreSwitchAwayişlerken.

    İç panel bağlıysa, sürücü, DXGK_CONNECTION_CHANGE.ConnectionStatusMonitorStatusDisconnected olarak ayarlanmış bir DXGK_CONNECTION_CHANGE paketini bağlantı değişikliği listesine eklemelidir ve DXGK_CONNECTION_CHANGE.MonitorConnect.MonitorConnectFlags.DisplayMuxConnectionChange 1 olarak ayarlanır. Bu ayarlar işletim sistemine sürücünün iç panelin denetimini serbest bırakdığını gösterir.

  • Sürücü DxgkDdiDisplayMuxPostSwitchToPhase1işlerken.

    • Sürücü önce iç panelin bağlı olup olmadığını belirlemelidir.
    • Panel bağlıysa, sürücü, bağlantı değişikliği listesine DXGK_CONNECTION_CHANGE paketi eklemeli ve DXGK_CONNECTION_CHANGE.ConnectionStatus, MonitorStatusConnected ve DXGK_CONNECTION_CHANGE.MonitorConnect.MonitorConnectFlags.DisplayMuxConnectionChange 1 olarak ayarlanmalıdır.
    • Panel bağlı değilse, sürücü DXGK_CONNECTION_CHANGE ile bağlantı değişikliği listesine bir DXGK_CONNECTION_CHANGE paketi eklemelidir. ConnectionStatusMonitorStatusDisconnected ve DXGK_CONNECTION_CHANGE olarak ayarlanır. MonitorConnect.MonitorConnectFlags.DisplayMuxConnectionChange 1 olarak ayarlanır.

  • Sürücü DxgkDdiDisplayMuxSwitchCanceledişlerken.

  • Bir anahtarlama sırasında bir hedef yoklama isteği geldiğinde, DisplayMuxConnectionChange yalnızca DxgkDdiDisplayMuxPreSwitchAway'ten, DxgkDdiDisplayMuxPostSwitchToPhase1'dan veya DxgkDdiDisplayMuxSwitchCanceled'tan eklenen bağlantı değişiklik paketleri için ayarlanmalıdır.

DxgkDdiSystemDisplayEnable kılavuzu güncelleştirildi

Bir ADS sürücüsünün DxgkDdiSystemDisplayEnable(/windows-hardware/drivers/ddi/dispmprt/nc-dispmprt-dxgkddi_system_display_enable) DDI çağrıldığında, sürücü, DxgkDdiSystemDisplayEnable DDI çağrısının sonunda PSR'nin devre dışı bırakıldığından emin olmalıdır.

OEM kılavuzu

ADS özelliğinin çeşitli yönleri, işletim sisteminin platformda denetlediğinin düzeyinin altındadır. OEM'lerin düzgün çalıştığından emin olması önemlidir. Aşağıdaki listede, OEM'lerin dikkate alınması gereken bazı önemli noktalar özetlemektedir:

  • Hem hibrit tümleşik hem de ayrık sürücü ADS'yi desteklemeli.
  • Platform için seçilen mux, ACPI aracılığıyla denetlenebiliyor.
  • mux cihazında _HID, DMQU ve DMCF yöntemleri ile iç hedefler için GPU alt ACPI cihazları uygulanmıştır ve DMID ACPI yöntemine sahiptir.
  • Her iki GPU'nun ACPI cihazlarının mux ACPI cihazına bağımlılıklarını işaretlemek için _DEP olması gerekir.
  • Her iki GPU'nun gösterdiği parlaklık arabirimi, kapsama alanları ve aralıklar tam olarak eşleşmektedir.
  • Parlaklık verileri bölümünde açıklandığı gibi parlaklık v3 arabirimi, parlaklık v2 arabirimi üzerinde şiddetle tavsiye edilir.
  • Monitör paneli sürücüsü kullanılıyorsa kodun GPU'dan bağımsız olması gerekir; yani panelin kontrolü hangi GPU'da olursa olsun aynı mantık kullanılabilir.
  • En azından bir iç mux için, mux'u değiştirme eylemi bir HPD etkinliği oluşturmamalıdır.
  • OEM bir sistemde mux'ı devre dışı bırakmak istediyse, DMQU ACPI yöntemi Arg0 2 olarak ayarlandığında çağrıldığında 0 döndürmelidir.
  • Mux, sürücüler düşük güçte olsa bile GPU'lar arasında geçiş yapabilmelidir. Bu durumda PSR kullanılmaz.
  • Mux bir GPU'dan diğerine geçtiğinde, panelin parlaklığı herhangi bir parlaklık hatası olmadan korunmalıdır. Bunu yapmanın aşağıdaki yollar da dahil olmak üzere birden çok yolu vardır. OEM, sistemin anahtarların parlaklığını korumasından sorumludur.
    • DisplayPort Aux Nits tabanlı parlaklık denetimini kullanın.
    • Herhangi bir parlaklık aksaklığını önlemek için PWM yeniden yapılandırmalı bir Tcon kullanın.
  • Kullanılan panel ve Tcon, geçiş öncesi ve geçiş sonrası bağlantı yapılandırması EDID tarafından kullanıma sunulduğunda ve hem iGPU hem de dGPU tarafından desteklendiğinde, eDP için PSR1 kendi kendini yenileme modunda kalabilir. Buna şunlar dahildir ancak bunlarla sınırlı değildir:
    • Yenileme hızı
    • Etkin boyut
    • Kullanılan eDP şerit sayısı ve şerit bant genişliği
    • eDP DSC ayarı
    • kullanılan eDP VSC SDP sürümü
    • Geçiş gerektirmeyen senaryolar için kullanılan PSR sürümü ve özellikleri