Partilhar via

TDR no Windows 8 e posterior

A partir do Windows 8, o comportamento TDR (deteção e recuperação de tempo limite da GPU) permite que partes de adaptadores físicos individuais sejam redefinidas, em vez de exigir uma redefinição em todo o adaptador.

Para obter mais informações, consulte Deteção e recuperação de tempo limite (TDR).

Requerimentos

  • Versão mínima do WDDM: 1.2
  • Versão mínima do Windows: 8
  • Implementação de driver — somente gráficos completos e renderização: obrigatório
  • Requisitos e testes do WHLK: Device.Graphics... TDRResiliency

Interface de driver de dispositivo TDR (DDI)

Para acomodar essa alteração de comportamento, os drivers de miniporta de exibição de modo kernel (KMD) podem implementar estas funções:

KMD indica suporte para essas funções definindo o DXGK_DRIVERCAPS.SupportPerEngineTDR membro, caso em que o KMD deve implementar todas as funções listadas.

Um driver que suporta essas funções também deve oferecer suporte à sincronização de nível zero para a função DxgkDdiCollectDbgInfo . Esse requisito garante que as chamadas KMD de nível zero possam continuar se a operação de redefinição não as afetar. Ver Observações de DxgkDdiCollectDbgInfo.

As seguintes estruturas estão associadas às funções acima:

Nodos

Conforme usado nas funções TDR listadas, um nó é uma das várias partes de um único adaptador físico que podem ser agendadas independentemente. Por exemplo, um nó 3D, um nó de decodificação de vídeo e um nó de cópia podem existir no mesmo adaptador físico e cada um pode receber um nó ordinal separado. Esta atribuição é armazenada no DXGKARG_QUERYDEPENDENTENGINEGROUP. membro NodeOrdinal numa chamada para DxgkDdiQueryDependentEngineGroup.

O número de nós no adaptador físico é indicado pelo driver de miniporta de vídeo no membro NbAsymetricProcessingNodes do DXGK_DRIVERCAPS.GpuEngineTopology.

O valor ordinal do nó é passado no membro NodeOrdinal da estrutura DXGKARG_CREATECONTEXT quando um contexto é criado.

Furgão

Como usado nas funções TDR DDI, um motor é um dos vários adaptadores físicos (ou GPUs) que, juntos, atuam como um adaptador lógico. O Dxgkrnl suporta tais configurações, mas requer que cada mecanismo tenha o mesmo número de nós.

Como exemplo, o agendador da GPU considera o mecanismo 0 como correspondendo ao adaptador físico 0. O motor 0 deve ter o mesmo número de nós que o motor 1, que corresponde ao adaptador 1.

Valor ordinal do motor durante a criação do contexto

Quando um contexto é criado, um único bit correspondente ao valor ordinal do mecanismo é definido no membro EngineAffinity da estrutura DXGKARG_CREATECONTEXT . O membro EngineOrdinal desta e de outras estruturas relacionadas ao agendador é um índice baseado em zero. O valor de EngineAffinity é 1 <<EngineOrdinal, e EngineOrdinal é a posição de bit mais alta em EngineAffinity.

Pacotes não afetados pela reinicialização do motor

O agendador da GPU pode pedir ao driver para reenviar pacotes que foram enviados tarde demais para a fila de espera de hardware do motor para serem totalmente processados antes que o reinício do motor seja concluído. O driver deve seguir estas diretrizes para reenviar tais pacotes:

  • Pacotes de paginação: o agendador de GPU solicita que o driver reenvie pacotes de paginação com seus IDs de cerca originais e na mesma ordem em que foram enviados originalmente. Esses pacotes são reenviados antes que novos pacotes sejam adicionados à fila de hardware.
  • Pacotes de renderização: o agendador da GPU atribui novos IDs de sincronização aos pacotes de renderização e, em seguida, reenviá-los.

Sequência de chamadas para reiniciar um motor

Quando DxgkDdiResetEngine é bem-sucedido, o agendador da GPU garante que o valor LastAbortedFenceId retornado da chamada de reposição do motor corresponda a:

  • Um ID de cerca existente na fila de hardware.
  • O último ID de cerca concluído na GPU. Essa situação pode acontecer quando a fila de hardware esvazia depois que o tempo limite da GPU é detectado, mas antes que a função de retorno de redefinição do mecanismo seja invocada.

O driver deve sempre manter o valor do último ID de cerca concluído na GPU, pois esse ID de cerca é necessário para definir o membro DmaPreempted.LastCompletedFenceId numa estrutura de notificação de interrupção de preempção DXGKARGCB_NOTIFY_INTERRUPT_DATA. O último ID de vedação concluído deve ser avançado apenas nestas situações:

  • Quando um pacote é concluído (não antecipado), o ID da última barreira concluída deve ser definido como o ID da barreira do pacote concluído.
  • Quando DxgkDdiResetEngine é concluído com sucesso, o último ID da barreira concluída deve ser atribuído o valor do membro LastCompletedFenceId retornado pela chamada de redefinição do mecanismo.
  • Para redefinição em todo o adaptador, a última ID de fence concluída em todos os nós deve ser atualizada para a última ID de fence submetida no momento da redefinição.

Aqui está uma sequência cronológica de uma reinicialização bem-sucedida do motor, conforme visto pelo agendador da GPU.

  1. É emitida uma tentativa de preempção.

  2. Foi detetado um timeout da GPU.

  3. O agendador de GPU tira um instantâneo dos últimos IDs de cerca enviados e concluídos, e as interrupções do mecanismo de tempo limite são ignoradas. Esta combinação é uma operação atómica ao nível da interrupção do dispositivo.

  4. Se não houver pacotes na fila de hardware neste momento, saia. Essa situação pode acontecer quando um pacote foi concluído na janela de tempo entre as etapas 2 e 3.

  5. Todos os DPCs enfileirados são liberados.

  6. Prepare-se para a reinicialização do motor.

  7. Chame DxgkDdiResetEngine.

  8. Se o membro LastAbortedFenceId for menor que o último ID de cerca concluído ou maior que o último ID de cerca enviado, o Dxgkrnl fará com que ocorra uma verificação de bug do sistema. Num ficheiro de despejo de falha, o erro é observado pela mensagem BugCheck 0x119, que tem os seguintes quatro parâmetros:

    • 0xA, o que significa que o motorista relatou um documento de identificação de cerca abortado inválido
    • LastAbortedFenceId valor retornado pelo driver
    • Última identificação da vedação concluída
    • Um parâmetro interno do sistema operacional

  9. Se o valor LastAbortedFenceId for válido, prossiga com a recuperação da redefinição do motor da seguinte maneira. Se a redefinição do motor afetou um pacote de paginação, o agendador da GPU segue a redefinição do motor com uma redefinição em todo o adaptador. Todos os dispositivos que possuem alocações referenciadas por esse pacote de paginação também são colocados no estado de erro. O dispositivo do sistema em si não é colocado no estado de erro e retoma a execução após a conclusão da redefinição.

Casos especiais

Uma situação especial pode ocorrer quando um pacote é concluído na GPU entre as etapas 3 e 7. Nesse caso, o driver deve definir LastAbortedFenceId para o ID de barreira do último pacote concluído se não houver pacotes na fila de hardware do ponto de vista do driver. Do ponto de vista do agendador, parece que tal pacote foi abortado. Assim, o agendador colocará o dispositivo correspondente em um estado de erro, mesmo que o pacote eventualmente seja concluído.

Se o driver não puder executar uma operação de redefinição por um dos seguintes motivos, ele deverá retornar um código de status de falha:

  • O hardware está em um estado inválido.
  • O hardware é incapaz de redefinir os nós.

Se o agendador da GPU receber um código de status de falha, executará uma operação de redefinição e reinício em todo o adaptador, de acordo com o comportamento TDR anterior ao Windows 8.

Mesmo que um driver opte pelo comportamento TDR do Windows 8 e posterior, há casos em que o agendador da GPU solicita uma redefinição e reinicialização de todo o adaptador lógico. Portanto, o driver ainda deve implementar as funções DxgkDdiResetFromTimeout e DxgkDdiRestartFromTimeout , e sua semântica permanece a mesma que antes do Windows 8. Quando uma tentativa de redefinir um adaptador físico com DxgkDdiResetEngine leva a uma redefinição do adaptador lógico, o comando !analyze do depurador do Windows mostra que o valor TdrReason do contexto de recuperação TDR é definido como um novo valor de TdrEngineTimeoutPromotedToAdapterReset = 9.

  • Last updated on