Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Alteração no tratamento de erros do EvtIddCxMonitorAssignSwapChain
Nas versões do Windows 10 antes da versão 1903, o restante da composição da área de trabalho não sabia se EvtIddCxMonitorAssignSwapChain falhou. Ele continuou a renderizar e apresentar quadros que o adaptador de exibição indireto não processou, resultando em IddCx encerrando o driver de exibição indireto (IDD) após algum tempo.
A partir do Windows 10 versão 1903 (IddCx 1.4), o tratamento de erros do IddCx para esta callback foi alterado para todas as versões do driver, introduzindo o STATUS_GRAPHICS_INDIRECT_DISPLAY_ABANDON_SWAPCHAIN como um código de status. Consulte EvtIddCxMonitorAssignSwapChain para obter detalhes.
Manipulando erros no loop-thread de processamento de quadros
Depois que o IDD retorna com êxito de EvtIddCxMonitorAssignSwapChain, ele possui o objeto hSwapChain. Se o driver encontrar um erro que o impeça de continuar processando o quadro, ele poderá chamar WdfObjectDelete para liberar a propriedade. O sistema operacional detectará a exclusão e fará com que uma nova cadeia de troca seja criada.
Se o driver souber que não pode se recuperar desse erro, ele deve chamar IddCxReportCriticalError para interromper o dispositivo.
Abordagem sugerida para lidar com erros de swapchain
Há vários motivos para falhas no callback EvtIddCxMonitorAssignSwapChain ou durante o processamento de quadros. As categorizações de falha incluem:
- Problemas transitórios específicos à sua solução, como um problema temporário com o hardware. Esse tipo de problema pode ser corrigido com mecanismos de recuperação leves que não afetarão a experiência do usuário porque a recuperação ocorre rapidamente (normalmente bem abaixo de um segundo no tempo) e não afetará o conteúdo visual na tela (por exemplo, sem movimentos).
- Problemas permanentes específicos à sua solução, como um deadlock no driver ou um problema sério com o hardware. Normalmente, esse tipo de problema não pode ser recuperado rapidamente, se é que é possível.
- Erros de API do DirectX causados por eventos externos ao driver. Por exemplo, seu driver não tem controle sobre eventos como quando o adaptador em que seu dispositivo D3D deve processar a imagem da área de trabalho foi PnpStopped ou houve uma falha em toda a GPU e foi necessário redefini-la.
- Erros de API do DirectX causados pelo seu driver. Os bugs de driver podem fazer com que o dispositivo D3D seja colocado em erro ou travado. Por exemplo, chamar CopySubResource com coordenadas fora do limite da textura colocará o dispositivo em um estado de erro.
- Erros de API do DirectX causados por outro driver de GPU IHV. Esses erros podem ser resultado de padrões de invocação corretos na IDD que disparam problemas de driver de GPU IHV.
É difícil para um driver distinguir com precisão entre os diferentes erros do DirectX. A principal diferença é que os erros causados por componentes externos do DirectX provavelmente serão transitórios e o sistema se recuperará em um estado estável; enquanto que, se o erro for causado pela exibição indireta ou pelo driver de GPU, os bugs provavelmente ocorrerão novamente.
Consulte EvtIddCxMonitorAssignSwapChain para obter mais informações sobre como propagar esses erros de volta para o sistema operacional de modo que o sistema operacional tente novamente.
Veja abaixo algumas diretrizes sobre como lidar com cada tipo de erro em seu driver.
Problemas transitórios específicos à sua solução
O driver deve corrigir o problema enquanto processa o frame. Essa ação pode resultar em um pequeno atraso no processamento do quadro. Se o erro ocorrer regularmente, o driver poderá considerar a preempção do erro para um problema permanente.
Problemas permanentes específicos da sua solução
O driver deve chamar IddCxReportCriticalError usando um código principal igual ou superior a 0x100 e usando códigos principais/menores exclusivos para representar o tipo de erro para ajudar as investigações de cliente/telemetria.
Erro do DirectX
A maneira mais simples de lidar com erros do DirectX é propagar de volta para o sistema operacional para que ele tente novamente. O driver deve retornar STATUS_GRAPHICS_INDIRECT_DISPLAY_ABANDON_SWAPCHAIN de EvtIddCxMonitorAssignSwapChain ou, se o erro ocorrer durante o processamento de um quadro, o driver deve liberar o swapchain chamando WdfObjectDelete.
Essa abordagem simples lida com erros disparados por eventos externos, pois o sistema operacional estabilizará e criará uma nova cadeia de troca (possivelmente em um novo adaptador Dxgi). Se o uso do DirectX pelo driver for limitado, essa abordagem funcionará bem.
Para drivers mais complexos que podem encontrar erros do DirectX causados por bugs na IDD, ou para drivers executando em drivers DirectX antigos ou com defeitos, essa abordagem pode resultar em um loop infinito de falhas no mecanismo de troca de ID (swapchain). Para evitar um loop sem fim, a IDD pode monitorar a frequência desses erros e percorrer estágios de recuperação quando um determinado estágio atingiu ciclos de erro suficientes. Se erros do DirectX forem encontrados, é importante que o driver destrua esse dispositivo DX e crie um novo, pois uma vez que um dispositivo DX está em um estado de erro, ele nunca se recuperará e precisará ser recriado.
| Estágio atual | Se o driver detectar muitos erros consecutivos de DirectX relacionados ao swapchain |
|---|---|
| O adaptador de renderização LUID fornecido em EvtIddCxMonitorAssignSwapChain é um adaptador de hardware | Use o Dxgi para encontrar o LUID do adaptador de software e, em seguida, chame IddCxAdapterSetRenderAdapter para solicitar que o sistema operacional use o adaptador de software para renderizar a área de trabalho. |
| O adaptador de renderização LUID fornecido em EvtIddCxMonitorAssignSwapChain é um adaptador de software | O driver deve chamar IddCxReportCriticalError usando um código principal igual ou superior a 0x100 e códigos principais/menores únicos para representar o tipo de erro, a fim de ajudar nas investigações de cliente/telemetria. |
Por exemplo, o driver pode considerar cinco falhas consecutivas do DirectX em EvtIddCxMonitorAssignSwapChain ou cinco falhas durante o processamento de quadros com 1 minuto como critérios para executar a ação de recuperação do estágio atual na tabela acima.