Condividi tramite

Aggiornamenti per IddCx versioni 1.5, 1.6 e successive

  • Articolo

Gli aggiornamenti seguenti nelle versioni IddCx 1.5 e 1.6 si applicano sia ai driver di visualizzazione della console che ai driver di visualizzazione indiretti remoti (IDD).

Versione aggiornata di IddCxGetVersion

La versione IddCx restituita da IddCxGetVersion è stata aggiornata a 0x1500 per la versione 1.5 e 0x1600 per la versione 1.6. Per un elenco completo delle informazioni sulla versione correlate a IddCx, vedere Versioni iddCx.

Informazioni WPP nei simboli IddCx pubblici

A partire da IddCx versione 1.5, i file di simboli IddCx pubblici contengono tutte le informazioni WPP (Software Trace Processor) di Windows. Questa modifica indica che il comando del debugger !wmitrace.logdump decodifica e visualizza il messaggio WPP nel debugger del kernel.

Possibilità di accedere ai buffer allocati nella memoria di sistema

In alcuni scenari, i buffer swapchain risiedono nella memoria di sistema; Ad esempio, quando WARP (Windows Advanced Rasterization Platform, il renderer software fornito dal sistema) è l'adattatore di rendering in uso. IddCx 1.5 aggiunge i callback del sistema operativo seguenti che consentono al driver di accedere ai buffer nella memoria di sistema evitando così una copia di sottorisorsa:

  • IddCxSwapChainInSystemMemory consente a un IDD di controllare se i buffer per una swapchain risiedono nella memoria di sistema. Il risultato di questo callback rimane costante per tutta la durata della swapchain. Il driver deve controllare il valore di questo callback nelcallback EvtIddCxMonitorAssignSwapChain e impostare lo stato per rilasciare e acquisire buffer.

  • IddCxSwapChainReleaseAndAcquireSystemBuffer consente a un IDD di rilasciare e acquisire un buffer, nonché di ottenere informazioni per l'accesso al buffer (ad esempio un puntatore alla memoria di sistema, passo/stride del buffer e formato e dimensioni della superficie). Il buffer restituito è valido fino alla successiva chiamata riuscita a questa funzione.

    Al momento dell'assegnazione di una nuova porta di scambio, il driver deve decidere quale variante di IddCxSwapChainReleaseAndAcquireBuffer/IddCxSwapChainReleaseAndAcquireSystemBuffer chiamerà per la specifica swapchain e deve continuare a usare tale variante per il resto della durata di tale swapchain. Per decidere, il driver deve considerare i requisiti specifici e il risultato della chiamata a IddCxSwapChainInSystemMemory. Un driver fa sì che il sistema operativo verifichi il processo UMDF se:

    • Chiama l'altra variante di IddCxSwapChainReleaseAndAcquireSystemBuffer/IddCxSwapChainReleaseAndAcquireBuffer.
    • Chiama IddCxSwapChainReleaseAndAcquireSystemBuffer quando IddCxSwapChainInSystemMemory restituisce false.

I driver sono consigliati ma non necessari per usare queste funzioni di callback. Il comportamento prima che IddCx 1.5 rimanga supportato.

Possibilità di accedere ai buffer in memoria fisicamente contigua

Nota

IddCxSwapChainGetPhysicallyContiguousAddress non è supportato in alcun sistema Windows 10 e probabilmente sarà deprecato in futuro.

A partire da IddCx 1.6, sono stati aggiunti il flag di IDDCX_ADAPTER_FLAGS_PREFER_PHYSICALLY_CONTIGUOUS e la funzione di callback iddCxSwapChainGetPhysicallyContiguousAddress del sistema operativo in modo che i buffer possano essere accessibili in memoria fisicamente contigua.

I driver di visualizzazione possono richiedere che le superfici primarie vengano allocate nella memoria di sistema fisicamente contigua impostando il flag IDDCX_ADAPTER_FLAGS_PREFER_PHYSICALLY_CONTIGUOUS in IDDCX_ADAPTER_CAPS. Questa funzionalità consente a un driver di analizzare direttamente una superficie senza una copia intermedia.

La richiesta del driver durante l'inizializzazione non garantisce l'esito positivo. Se la richiesta non riesce, la chiamata a IddCxAdapterInitAsync non avrà esito negativo. Al contrario, quando il driver esegue un IddCxSwapChainReleaseAndAcquireBuffer (o IddCxSwapChainReleaseAndAcquireSystemBuffer), deve chiamare IddCxSwapChainGetPhysicallyContiguousAddress per recuperare l'indirizzo fisico della superficie. IddCxSwapChainGetPhysicallyContiguousAddress attenderà prima di tutto i comandi di rendering in sospeso, quindi scarica e invalida le cache della CPU associate all'intervallo di indirizzi in cui è archiviata la superficie. Tuttavia, se la richiesta iniziale per le superfici da allocare nella memoria fisicamente contigua non è riuscita, IddCxSwapChainGetPhysicallyContiguousAddress restituisce E_NOINTERFACE.