Condividi tramite


Funzionalità aggiunte nelle versioni precedenti di WDDM 2.X

Questa pagina descrive le funzionalità dei driver di visualizzazione e grafica aggiunte nelle versioni precedenti di WDDM 2.X per Windows 10. Per visualizzare le funzionalità aggiunte per la versione più recente di WDDM 2.X, vedi Novità per i driver di visualizzazione e grafica di Windows 10.

WDDM 2.6

Inchiostro super bagnato

L'input penna super-wet è una funzionalità che ruota intorno al rendering del buffer anteriore. I driver IHV possono supportare la creazione di trame "visualizzabili" di formati o modalità non supportati dall'hardware. A tale scopo, è possibile allocare la trama richiesta dall'app, insieme a una trama "ombreggiatura" con un formato/layout che può essere visualizzato e quindi copiando tra i due al momento. Questa "ombreggiatura" potrebbe non essere necessariamente una trama nel modo normale, ma può essere semplicemente dati di compressione. Inoltre, potrebbe non essere necessario esistere, ma potrebbe essere un'ottimizzazione.

Il runtime si evolverà per comprendere questi aspetti delle superfici visualizzabili:

  • Indica se deve esistere o meno un'ombreggiatura per la visualizzazione in un particolare piano VidPnSource/.

  • Se è più ottimale per l'esistenza di un'ombreggiatura.

  • Quando trasferire il contenuto dalla superficie dell'applicazione alla superficie di ombreggiatura. Il runtime sarà esplicito su questa operazione, anziché essere implicito all'interno di Present.

  • Come richiedere l'impostazione di una modalità o il capovolgimento dinamico tra le superfici originali e ombreggiature.

Scanout può iniziare poco dopo una VBlank, analizza verticalmente dall'alto verso il basso dell'immagine e viene completato poco prima della successiva VBlank. Questo non è sempre il caso, a seconda della tempistica dell'orologio in pixel e del layout dei dati nella trama; soprattutto se è effettivamente disponibile la compressione.

Sono state aggiunte nuove DDI per separare e comprendere le trasformazioni che si verificano prima dell'analisi, al fine di abilitare (quando possibile) il rendering del buffer front-buffer. Vedere D3DWDDM2_6DDI_SCANOUT_FLAGS e PFND3DWDDM2_6DDI_PREPARE_SCANOUT_TRANSFORMATION.

Ombreggiatura frequenza variabile

L'ombreggiatura a frequenza variabile o l'ombreggiatura in pixel grossolana è un meccanismo per abilitare l'allocazione delle prestazioni/potenza del rendering a velocità variabili tra le immagini sottoposte a rendering.

Nel modello precedente, per usare MSAA (anti-aliasing multi-sample) per ridurre l'aliasing geometrico:

  • La quantità in base alla quale ridurre l'aliasing geometrico deve essere nota in anticipo quando viene allocata la destinazione.
  • La quantità in base alla quale ridurre l'aliasing geometrico non può essere modificata una volta allocata la destinazione.

In WDDM 2.6 il nuovo modello estende MSAA nella direzione opposta e grossolana dei pixel aggiungendo un nuovo concetto di ombreggiatura grossolana. Questo è il punto in cui è possibile eseguire l'ombreggiatura a una frequenza grossolana di un pixel. Un gruppo di pixel può essere ombreggiato come una singola unità e il risultato viene quindi trasmesso a tutti i campioni del gruppo.

Un'API di ombreggiatura grossolana consente alle app di specificare il numero di pixel che appartengono a un gruppo ombreggiato. Le dimensioni del pixel grossolano possono essere variate dopo l'allocazione della destinazione di rendering. Quindi, parti diverse dello schermo o passaggi di disegno diversi possono avere velocità di ombreggiatura del corso diverse.

Un'implementazione a più livelli è disponibile con due limiti di query utente. Per i livelli 1 e 2, l'ombreggiatura grossolana è disponibile per le risorse a campione singolo e MSAA. Per le risorse MSAA, l'ombreggiatura può essere eseguita per pixel grossolano o per campione come di consueto. Tuttavia, nei livelli 1 e 2, per le risorse MSAA, il campionamento grossolano non può essere usato per ombreggiatura a una frequenza tra per pixel e per campione.

Livello 1:

  • La velocità di ombreggiatura può essere specificata solo in base al disegno; niente di più granulare di quello

  • La velocità di ombreggiatura si applica in modo uniforme a ciò che viene disegnato indipendentemente da dove si trova all'interno della destinazione di rendering

Livello 2:

  • La velocità di ombreggiatura può essere specificata in base al disegno, come nel livello 1. Può anche essere specificato da una combinazione di base per disegno e di:

    • Semantica dal vertice per-provoking e
    • Immagine dello spazio dello schermo
  • Le frequenze di ombreggiatura delle tre origini vengono combinate usando un set di combinatori

  • Le dimensioni del riquadro dell'immagine dello spazio sullo schermo sono 16x16 o inferiori. La frequenza di ombreggiatura richiesta dall'app è garantita esattamente (per la precisione dei filtri temporali e di altri filtri di ricostruzione)

  • SV_ShadingRate input PS è supportato. La frequenza dei vertici provocante, detta anche frequenza per primitiva, è valida solo quando viene usato un viewport e SV_ViewportIndex non viene scritto in .

  • La frequenza dei vertici provocante, detta anche frequenza per primitiva, può essere usata con più di un viewport se il limite SupportsPerVertexShadingRateWithMultipleViewports è contrassegnato come true. Inoltre, in tal caso, può essere usato quando SV_ViewportIndex viene scritto in .

Vedere PFND3D12DDI_RS_SET_SHADING_RATE_0062 e D3D12DDI_SHADING_RATE_0062.

Raccogliere informazioni di diagnostica

Raccogliere informazioni di diagnostica consente al sistema operativo di raccogliere dati privati dai driver per le schede grafiche costituite sia dal rendering che dalle funzioni di visualizzazione. Questa nuova funzionalità è un requisito in WDDM 2.6.

La nuova DDI dovrebbe consentire al sistema operativo di raccogliere informazioni in qualsiasi momento in cui viene caricato un driver. Attualmente il sistema operativo usa la funzione DxgkDdiCollectDebugInfo implementata dal miniport per eseguire query sui dati privati del driver per i casi correlati al rilevamento e al ripristino del timeout. La nuova DDI verrà usata per raccogliere i dati per diversi motivi. Il sistema operativo chiamerà questa DDI quando è necessaria la diagnostica per fornire un tipo di informazioni richieste. Il driver deve raccogliere tutte le informazioni private importanti per analizzare il problema e inviarlo al sistema operativo. DxgkDdiCollectDebugInfo verrà deprecato e sostituito con DxgkDdiCollectDiagnosticInfo.

Vedere DXGKDDI_COLLECTDIAGNOSTICINFO.

Elaborazione in background

L'elaborazione in background consente ai driver in modalità utente di esprimere il comportamento di threading desiderato e il runtime per controllarlo/monitorarlo. I driver in modalità utente attivano thread in background e assegnano i thread il più basso possibile e si basano sull'utilità di pianificazione NT per garantire che questi thread non interrompano i thread di percorso critico, in genere con esito positivo.

Le API consentono alle app di modificare la quantità di elaborazione in background appropriata per i carichi di lavoro e quando eseguire il lavoro.

Vedere PFND3D12DDI_QUEUEPROCESSINGWORK_CB_0062.

Aggiornamento frequente driver

L'aggiornamento rapido del driver riduce il tempo di inattività del server il più possibile quando è necessario aggiornare un componente del sistema operativo.

La patch ad accesso frequente del driver viene usata per applicare una patch di sicurezza al driver in modalità kernel. In questo caso viene chiesto al driver di salvare la memoria dell'adattatore, l'adattatore viene arrestato, il driver viene scaricato, viene caricato un nuovo driver e l'adattatore viene avviato di nuovo.

VedereDXGKDDI_SAVEMEMORYFORHOTUPDATE e DXGKDDI_RESTOREMEMORYFORHOTUPDATE.

WDDM 2.5

Carichi di lavoro rilevati

I carichi di lavoro monitorati sono una funzionalità sperimentale che offre un maggiore controllo sul compromesso tra l'esecuzione del processore più rapida e il consumo di energia inferiore e non è disponibile fino a un ulteriore preavviso. L'implementazione è stata rimossa da Windows 10 versione 2003; e deprecati dalle versioni precedenti del sistema operativo come parte di una correzione di sicurezza.

Il contenuto cambia

Argomento Data Descrizione
Estensione EDID (VSDB) per HMD e display specializzati 03/12/2018 Specifica per i produttori di display
Sottosistema kernel grafica DirectX (Dxgkrnl.sys) 12/04/2018 Interfacce in modalità kernel implementate dal sistema operativo Windows tramite il sottosistema kernel della grafica Microsoft DirectX (Dxgkrnl.sys).
Funzionalità di WDDM 2.1 01/10/2019 Descrive le funzionalità nuove e aggiornate per WDDM 2.1

Raytracing

I nuovi DDI Direct3D sono stati creati in parallelo con l'API Direct3D, per supportare il raytracing accelerato dall'hardware. Le DDI di esempio includono:

Per altre info sul raytracing, vedi:

Visualizzare la sincronizzazione

Il sistema operativo verificherà la presenza di funzionalità per la sincronizzazione della visualizzazione quando lo schermo viene esposto dal driver al sistema operativo, quindi prima di abilitare la visualizzazione. Per i dispositivi figlio TypeIntegratedDisplay, questo viene segnalato tramite una chiamata a DxgkDdiQueryAdapterInfo con type DXGKQAITYPE_INTEGRATED_DISPLAY_DESCRIPTOR2 durante l'inizializzazione dell'adattatore. Per i dispositivi figlio TypeVideoOutput, supportati a partire da WDDM 2.5, le funzionalità vengono segnalate come parte dell'elaborazione del plug-hot tramite DxgkDdiUpdateMonitorLinkInfo in modo che le funzionalità possano cambiare in base al monitor di destinazione o connesso.

Il sistema operativo specifica la sincronizzazione dello schermo nella chiamata DxgkDdiSetTimingsFromVidPn nel campo Input della struttura per percorso DXGK_SET_TIMING_PATH_INFO .

WDDM 2.1

WDDM 2.1 consente nuovi scenari e offre miglioramenti significativi nelle aree di prestazioni, affidabilità, resilienza degli aggiornamenti, miglioramenti di diagnostica e miglioramenti futuri del sistema per il sotto system grafico windows. Il modello di driver WDDM 2.0 è un prerequisito per D3D12. WDDM 2.0 e DirectX12 sono disponibili solo in Windows 10 e versioni successive.

Di seguito è riportato un elenco di aggiunte e aggiornamenti delle funzionalità per WDDM 2.1.

  • Miglioramento delle prestazioni grafiche riducendo il tempo di overhead impiegato nella gestione della memoria e un utilizzo più efficiente della memoria grafica insufficiente. I miglioramenti delle prestazioni della grafica sono:

    • Offrire e recuperare risorse: offrono e recuperano miglioramenti per ridurre il footprint di memoria delle applicazioni in esecuzione in modalità in background.
    • Supporto per la codifica della voce di tabella di pagine 2 MB: in WDDM 2.1 la codifica PTE (Large Page Table Entry) in VRAM è abilitata. Questa modifica aumenta le prestazioni nei sistemi che lo supportano.
    • Supporto per pagine di memoria da 64 KB: le allocazioni di memoria virtuale che usano una granularità di 64 KB sono supportate anche in WDDM 2.1. Questa modifica offre vantaggi in particolare alle API e ai soC riducendo il sovraccarico per l'accesso alle pagine di memoria virtuale.
  • Miglioramenti del contenuto protetto basato su hardware con l'invio in batch (PlayReady 3.0)

  • Installazione di Driver Store per i driver grafici per migliorare la resilienza dell'aggiornamento dei driver.

  • DXIL, un nuovo linguaggio conforme allo shader

  • Miglioramenti delle prestazioni e dell'ottimizzazione D3D12

  • Opzioni di diagnostica migliorate per gli sviluppatori

Per altre informazioni, vedere Funzionalità di WDDM 2.1.

WDDM 2.0

WDDM 2.0 include aggiornamenti di gestione della memoria.

Memoria virtuale GPU

  • Tutta la memoria fisica viene astratta in segmenti virtuali che possono essere gestiti dal gestore di memoria dell'unità di elaborazione grafica (GPU).
  • Ogni processo ottiene il proprio spazio di indirizzi virtuali GPU.
  • È stato rimosso il supporto per gli intervalli di scorrimento.

Per altri dettagli, vedere Memoria virtuale GPU in WDDM 2.0.

Residenza dei conducenti

  • Gestione memoria video garantisce che le allocazioni si trovino in memoria prima di inviare buffer dei comandi al driver. Per facilitare questa funzionalità, sono state aggiunte le interfacce DDI (Driver driver driver) in modalità utente (MakeResident, TrimResidency, Evict).
  • L'elenco di percorsi di allocazione e patch viene eliminato gradualmente perché non è necessario nel modello WDDM 2.0.
  • I driver in modalità utente sono ora responsabili della gestione del rilevamento delle allocazioni. Sono state aggiunte diverse DDI per abilitare questa funzionalità.
  • Ai driver vengono assegnati budget di memoria e si prevede di adattarsi sotto pressione di memoria. In questo modo i driver di Windows universali possono funzionare tra le piattaforme dell'applicazione.
  • Le DDI sono state aggiunte per la sincronizzazione dei processi e il monitoraggio del contesto.

Per altri dettagli, vedere Residenza dei driver in WDDM 2.0.