Condividi tramite

TDR in Windows 8 e versioni successive

  • Articolo

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

Per altre informazioni sul TDR, vedere Rilevamento e ripristino del timeout .

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

Interfaccia del driver di dispositivo TDR (DDI)

Per soddisfare questa modifica di comportamento, visualizzare i driver miniport implementano queste funzioni:

Un driver miniport di visualizzazione indica il supporto per queste funzioni impostando il DXGK_DRIVERCAPS. Membro SupportPerEngineTDR , nel qual caso deve implementare tutte le funzioni precedenti.

Nota

Un driver che supporta queste funzioni deve supportare anche la sincronizzazione del livello zero per la funzione DxgkDdiCollectDbgInfo . Ciò consente di garantire che le chiamate miniport di livello zero non interessate dall'operazione di reimpostazione possano continuare. Vedere la sezione Osservazioni di DxgkDdiCollectDbgInfo.

Le strutture seguenti sono associate alle funzioni precedenti:

Nodi

Come usato nelle funzioni TDR precedenti, un nodo è una delle 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 un valore ordinale del nodo separato nel DXGKARG_QUERYDEPENDENTENGINEGROUP. Membro NodeOrdinal in una chiamata a DxgkDdiQueryDependentEngineGroup.

Il numero di nodi nell'adattatore fisico viene segnalato dal driver miniport di visualizzazione 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 TDR precedenti, un motore è uno di più adattatori fisici (o GPU) che insieme fungono da una scheda logica. Il sottosistema kernel della grafica DirectX 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 in fase di creazione del contesto

Quando viene creato un contesto, un singolo bit corrispondente al valore ordinale del motore viene impostato nel membro EngineAffinity della struttura DXGKARG_CREATECONTEXT . Il membro EngineOrdinal di questa e di 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

Il driver potrebbe essere richiesto dall'utilità di pianificazione GPU di inviare di nuovo 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: il driver verrà richiesto dall'utilità di pianificazione GPU di inviare di nuovo pacchetti di paging con i relativi ID di recinto originale e nello stesso ordine in cui sono stati originariamente inviati. Qualsiasi pacchetto di questo tipo verrà inviato di nuovo prima dell'aggiunta di nuovi pacchetti alla coda hardware.
  • Pacchetti di rendering: l'utilità di pianificazione GPU assegnerà i pacchetti di rendering nuovi ID di isolamento e quindi li invia di nuovo.

Sequenza di chiamata 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 un ID di isolamento esistente nella coda hardware o all'ultimo ID limite completato nella GPU. Quest'ultima situazione può verificarsi quando la coda hardware viene svuotata dopo il timeout della GPU, ma prima che venga richiamato il callback del motore.

L'ultimo valore ID di isolamento completato nella GPU deve essere mantenuto sempre dal driver perché è necessario anche impostare il membro DmaPreempted.LastCompletedFenceId di una struttura di notifica di interruzione DXGKARGCB_NOTIFY_INTERRUPT_DATA . L'ultimo ID di isolamento completato deve essere avanzato solo in queste situazioni:

  • Quando un pacchetto viene completato (non preceduto), 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. Uno snapshot dell'ultimo ID di isolamento inviato e completato viene acquisito dall'utilità di pianificazione della GPU e le interruzioni dal motore di timeout vengono ignorate. Si tratta di un'operazione atomica a livello di interrupt del dispositivo.

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

  5. Tutti i DPC in coda vengono scaricati.

  6. Preparare 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, il sottosistema del kernel grafico DirectX causa un controllo degli errori di sistema. In un file di dump di arresto anomalo del sistema, l'errore è indicato dal messaggio BugCheck 0x119, che ha questi quattro parametri:

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

  9. Se il valore LastAbortedFenceId è valido, procedere con il ripristino del motore come indicato di seguito. Se un pacchetto di paging è stato interessato dalla reimpostazione del motore, l'utilità di pianificazione GPU segue la reimpostazione del motore con una reimpostazione a livello di scheda. Anche tutti i dispositivi a cui fa riferimento tale pacchetto di paging vengono inseriti nello stato di errore. Tuttavia, 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 nella GPU tra i passaggi 3 e 7 descritti in precedenza. In questo caso, LastAbortedFenceId deve essere impostato dal driver sull'ID di isolamento 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, apparirà che tale pacchetto è stato interrotto e il dispositivo corrispondente verrà inserito in uno stato di errore anche se il pacchetto è stato completato.

Se il driver non può eseguire un'operazione di reimpostazione perché l'hardware è in uno stato non valido o perché l'hardware non è in grado di reimpostare i nodi, il driver deve restituire un codice di stato di errore. Se l'utilità di pianificazione GPU riceve un codice di stato di errore, esegue un'operazione di reimpostazione e riavvio a livello di adattatore seguendo il comportamento TDR prima di Windows 8.

Anche se un driver ha scelto il comportamento di Windows 8 e TDR successivo, ci saranno casi in cui l'utilità di pianificazione GPU richiede un ripristino e il 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 Windows mostra che il valore TdrReason del contesto di ripristino TDR è impostato su un nuovo valore TdrEngineTimeoutPromotedToAdapterReset = 9.