Condividi tramite

TDR in Windows 8 e versioni successive

  • Articolo

A partire da Windows 8, il comportamento di rilevamento e ripristino del timeout della GPU consente la reimpostazione di parti di singole schede fisiche, invece di richiedere una reimpostazione a livello di scheda.

Per altre informazioni, vedere Timeout detection and recovery (TDR).For more information, see Timeout detection and recovery (TDR).

Requisiti

  • Versione minima di WDDM: 1.2
  • Versione minima di Windows: 8
  • Implementazione del driver: grafica completa e solo rendering: obbligatorio
  • Requisiti e test WHLK : Device.Graphics... TDRResiliency

TDR Device Driver Interface (DDI)

Per supportare questa modifica del comportamento, i driver miniport in modalità kernel (KMD) possono implementare queste funzioni:

Un kmD indica il supporto per queste funzioni impostando il DXGK_DRIVERCAPS.Membro SupportPerEngineTDR , nel qual caso deve implementare tutte le funzioni elencate.

Un driver che supporta queste funzioni deve supportare anche la sincronizzazione di livello zero per la funzione DxgkDdiCollectDbgInfo. Questo requisito garantisce che il livello zero chiamate KMD possa continuare se l'operazione di reimpostazione non le influisce. Vedere la sezione Osservazioni di DxgkDdiCollectDbgInfo.

Le strutture seguenti sono associate alle funzioni precedenti:

Nodi

Come usato nelle funzioni TDR elencate, un nodo è una di più parti di una singola scheda fisica che può essere pianificata in modo indipendente. Ad esempio, un nodo 3D, un nodo di decodifica video e un nodo di copia possono esistere tutti nella stessa scheda fisica e ognuno può essere assegnato a un ordinale di nodo separato. Questa assegnazione viene archiviata nel DXGKARG_QUERYDEPENDENTENGINEGROUP.Membro NodeOrdinal in una chiamata a DxgkDdiQueryDependentEngineGroup.

Il numero di nodi nella scheda fisica viene segnalato dal driver miniport visualizzato nel membro NbAsymetricProcessingNodes di DXGK_DRIVERCAPS.GpuEngineTopology.

Il valore ordinale del nodo viene passato nel membro NodeOrdinal della struttura DXGKARG_CREATECONTEXT quando viene creato un contesto.

Motori

Come usato nelle funzioni DDI TDR, un motore è uno di più schede fisiche (o GPU) che insieme fungono da una scheda logica. Dxgkrnl supporta tali configurazioni, ma richiede che ogni motore abbia lo stesso numero di nodi.

Ad esempio, l'utilità di pianificazione GPU considera il motore 0 in modo che corrisponda all'adattatore fisico 0. Il motore 0 deve avere lo stesso numero di nodi del motore 1, che corrisponde all'adattatore 1.

Valore ordinale del motore alla creazione del contesto

Quando viene creato un contesto, viene impostato un singolo bit corrispondente al valore ordinale del motore nel membro EngineAffinity della struttura DXGKARG_CREATECONTEXT . Il membro EngineOrdinal di questa e altre strutture correlate all'utilità di pianificazione è un indice in base zero. Il valore di EngineAffinity è 1 <<EngineOrdinal e EngineOrdinal è la posizione di bit più alta in EngineAffinity.

Pacchetti non interessati dalla reimpostazione del motore

L'utilità di pianificazione GPU potrebbe chiedere al driver di inviare nuovamente pacchetti inviati troppo tardi alla coda hardware del motore per essere completamente elaborati prima del completamento della reimpostazione del motore. Il driver deve seguire queste linee guida per inviare di nuovo tali pacchetti:

  • Pacchetti di paging: l'utilità di pianificazione GPU chiede al driver di inviare di nuovo pacchetti di paging con gli ID di isolamento originali e nello stesso ordine in cui sono stati originariamente inviati. Tutti questi pacchetti vengono inviati di nuovo prima dell'aggiunta di nuovi pacchetti alla coda hardware.
  • Pacchetti di rendering: l'utilità di pianificazione GPU assegna i pacchetti di rendering ai nuovi ID limite e quindi li invia di nuovo.

Sequenza chiamante per reimpostare un motore

Quando DxgkDdiResetEngine ha esito positivo, l'utilità di pianificazione GPU garantisce che il valore LastAbortedFenceId restituito dalla chiamata di reimpostazione del motore corrisponda a:

  • ID di isolamento esistente nella coda hardware.
  • ULTIMO ID di isolamento completato nella GPU. Questa situazione può verificarsi quando la coda hardware si svuota dopo il timeout della GPU, ma prima che venga richiamato il callback di reimpostazione del motore.

Il driver deve sempre mantenere l'ultimo valore ID di isolamento completato nella GPU perché è necessario tale ID limite per impostare il membro DmaPreempted.LastCompletedFenceId di una struttura di notifica di interruzione di DXGKARGCB_NOTIFY_INTERRUPT_DATA di annullamento. L'ultimo ID di recinzione completato deve essere avanzato solo in queste situazioni:

  • Quando un pacchetto viene completato (non superato), l'ultimo ID limite completato deve essere impostato sull'ID limite del pacchetto completato.
  • Quando DxgkDdiResetEngine ha esito positivo, l'ultimo ID limite completato deve essere impostato sul valore del membro LastCompletedFenceId restituito dalla chiamata di reimpostazione del motore.
  • Per la reimpostazione a livello di adattatore, l'ultimo ID limite completato in tutti i nodi deve essere avanzato all'ultimo ID limite inviato al momento della reimpostazione.

Ecco una sequenza cronologica di una reimpostazione corretta del motore, come illustrato dall'utilità di pianificazione GPU:

  1. Viene eseguito un tentativo di precedenza.

  2. Viene rilevato un timeout della GPU.

  3. L'utilità di pianificazione GPU acquisisce uno snapshot degli ULTIMI ID di isolamento inviati e completati e interrompe il motore di timeout vengono ignorati. Questa combinazione è un'operazione atomica a livello di interrupt del dispositivo.

  4. Se a questo punto non sono presenti pacchetti nella coda hardware, uscire. Questa situazione può verificarsi quando un pacchetto è stato completato nell'intervallo di tempo tra i passaggi 2 e 3.

  5. Tutti i DPC in coda vengono scaricati.

  6. Prepararsi per la reimpostazione del motore.

  7. Chiama DxgkDdiResetEngine.

  8. Se il membro LastAbortedFenceId è minore dell'ultimo ID limite completato o è maggiore dell'ultimo ID limite inviato, Dxgkrnl causa un controllo dei bug di sistema. In un file di dump di arresto anomalo del sistema, l'errore viene segnalato dal messaggio BugCheck 0x119, che ha questi quattro parametri:

    • 0xA, il che significa che il conducente ha segnalato un ID di recinzione interrotto non valido
    • LastAbortedFenceId valore restituito dal driver
    • ULTIMO ID recinzione completato
    • Parametro del sistema operativo interno

  9. Se il valore LastAbortedFenceId è valido, procedere con il ripristino del motore come indicato di seguito. Se il motore reimposta un pacchetto di paging, l'utilità di pianificazione GPU segue la reimpostazione del motore con una reimpostazione a livello di adattatore. Tutti i dispositivi che possiedono le allocazioni a cui fa riferimento il pacchetto di paging vengono inseriti anche nello stato di errore. Il dispositivo di sistema stesso non viene inserito nello stato di errore e riprende l'esecuzione al termine della reimpostazione.

Casi speciali

Una situazione speciale può verificarsi quando un pacchetto viene completato sulla GPU tra i passaggi 3 e 7. In questo caso, il driver deve impostare LastAbortedFenceId sull'ID limite dell'ultimo pacchetto completato se non sono presenti pacchetti nella coda hardware dal punto di vista del driver. Dal punto di vista dell'utilità di pianificazione, sembra che tale pacchetto sia stato interrotto. Quindi, l'utilità di pianificazione inserisce il dispositivo corrispondente in uno stato di errore anche se il pacchetto è stato completato.

Se il driver non riesce a eseguire un'operazione di reimpostazione per uno dei motivi seguenti, deve restituire un codice di stato di errore:

  • L'hardware è in uno stato non valido.
  • L'hardware non è in grado di reimpostare i nodi.

Se l'utilità di pianificazione GPU riceve un codice di stato di errore, esegue un'operazione di reimpostazione e riavvio a livello di scheda seguendo il comportamento TDR prima di Windows 8.

Anche se un driver sceglie il comportamento TDR di Windows 8 e versioni successive, ci sono casi in cui l'utilità di pianificazione GPU richiede un ripristino e un riavvio dell'intera scheda logica. Pertanto, il driver deve comunque implementare le funzioni DxgkDdiResetFromTimeout e DxgkDdiRestartFromTimeout e la relativa semantica rimane invariata prima di Windows 8. Quando un tentativo di reimpostare una scheda fisica con DxgkDdiResetEngine comporta una reimpostazione della scheda logica, il comando !analyze del debugger di Windows mostra che il valore TdrReason del contesto di ripristino TDR è impostato su un nuovo valore TdrEngineTimeoutPromotedToAdapterReset = 9.