Usar o DRED para diagnosticar falhas de GPU
DRED significa Dados Estendidos Removidos pelo Dispositivo. DRED é um conjunto em evolução de recursos de diagnóstico projetados para ajudá-lo a identificar a causa de erros inesperados de remoção de dispositivo. No hardware que dá suporte aos recursos necessários (conforme definido abaixo), o DRED fornece trilhas automáticas, bem como relatórios de falhas de página de GPU.
Crumbs de pão automático
Para definir a cena para trilhas automáticas, vamos primeiro menção a variedade manual. Em antecipação à eventualidade de uma TDR (Detecção e Recuperação de Tempo Limite), você pode usar o método ID3D12GraphicsCommandList2::WriteBufferImmediate para colocar barras de pão no fluxo de comando de GPU, a fim de acompanhar o progresso da GPU.
Essa é uma abordagem razoável se você quiser criar uma implementação personalizada e de baixa sobrecarga. Mas pode não ter parte da versatilidade de uma solução padronizada, como extensões de depurador ou relatórios por meio de Relatório de Erros do Windows (WER) (também conhecido como Watson).
Portanto, as trilhas automáticas do DRED chamam WriteBufferImmediate para colocar contadores de progresso no fluxo de comandos de GPU. DRED insere uma trilha após cada operação de renderização, o que significa que todas as operações que resultam no trabalho de GPU (por exemplo, Desenhar, Expedir, Copiar, Resolver e outras). Se o dispositivo for removido no meio de uma carga de trabalho de GPU, o valor de trilha DRED será essencialmente uma coleção das operações de renderização concluídas antes do erro.
O buffer do anel do histórico de trilhas mantém operações de até 64KiB em uma determinada lista de comandos. Se houver mais de 65536 operações em uma lista de comandos, somente as últimas operações de 64KiB serão armazenadas, substituindo as operações mais antigas primeiro. No entanto, o valor do contador de trilha continua a contar até UINT_MAX. Portanto, LastOpIndex = (BreadcrumbCount - 1) % 65536.
O DRED 1.0 foi disponibilizado pela primeira vez em Windows 10, versão 1809 (Atualização de outubro de 2018 para o Windows 10) e expôs migalhas automáticas rudimentares. No entanto, não havia APIs para isso e a única maneira de habilitar o DRED 1.0 era usar o Hub de Feedback para capturar uma reprodução de TDR (reprodução) paraDesempenho e Compatibilidade de Jogos > de Aplicativos&. A principal finalidade do DRED 1.0 era ajudar a analisar falhas de jogo por meio de comentários do cliente.
Advertências
- Como uma GPU é muito pipelineada, não há garantia de que o contador de trilha indica a operação exata que falhou. Na verdade, em alguns dispositivos de renderização adiada baseados em bloco, é possível que o contador de trilha seja um recurso completo ou uma barreira UAV (exibição de acesso não ordenada) por trás do progresso real da GPU.
- Um driver de exibição pode reordenar comandos, fazer a busca prévia da memória do recurso bem antes de executar um comando ou liberar memória armazenada em cache bem após a conclusão de um comando. Qualquer um deles pode produzir um erro de GPU. Nesses casos, os contadores de trilha automática podem ser menos úteis ou enganosos.
Desempenho
Embora as migalhas automáticas sejam projetadas para serem de baixa sobrecarga, elas não são gratuitas. As medidas empíricas mostram a perda de desempenho de 2 a 5% em um mecanismo de jogo de gráficos AAA Direct3D 12 típico. Por esse motivo, as barras automáticas estão desativadas por padrão.
Requisitos de hardware
Como os valores do contador de trilha devem ser preservados após a remoção do dispositivo, o recurso que contém barras de pão deve existir na memória do sistema e deve persistir em caso de remoção do dispositivo. Isso significa que o driver de exibição precisa dar suporte a D3D12_FEATURE_EXISTING_HEAPS. Felizmente, esse é o caso da maioria dos drivers de exibição do Direct3D 12 no Windows 10, versão 1903.
Relatório de falhas de página de GPU
Um recurso novo para DRED 1.1 é o relatório de falhas de página de GPU dred. Uma falha de página de GPU geralmente ocorre em uma dessas condições.
- Um aplicativo executa erroneamente o trabalho na GPU que faz referência a um objeto excluído. Esse é um dos principais motivos para uma remoção inesperada do dispositivo.
- Um aplicativo executa erroneamente o trabalho na GPU que acessa um recurso removido ou um bloco não residente.
- Um sombreador faz referência a um descritor não inicializado ou obsoleto.
- Um sombreador indexa além do final de uma associação raiz.
O DRED tenta resolver alguns desses cenários relatando os nomes e tipos de quaisquer objetos de API existentes ou recentemente liberados que correspondam ao VA (endereço virtual) da falha de página relatada pela GPU.
Ressalva
Nem todas as GPUs dão suporte a falhas de página (embora muitas o façam). Algumas GPUs respondem a falhas de memória por: gravações de bucket de bits; lendo dados simulados (por exemplo, zeros); ou simplesmente enforcando. Infelizmente, nos casos em que a GPU não trava imediatamente, uma TDR (Detecção e Recuperação de Tempo Limite) pode ocorrer posteriormente no pipe, tornando ainda mais difícil localizar a causa raiz.
Desempenho
O runtime do Direct3D 12 deve coletar ativamente uma coleção de objetos de API existentes e excluídos recentemente indexáveis por VA (endereço virtual). Isso aumenta a sobrecarga de memória do sistema e introduz um pequeno impacto de desempenho na criação e destruição de objetos. Por esse motivo, esse comportamento está desativado por padrão.
Requisitos de hardware
Uma GPU que não dá suporte a falhas de página ainda pode se beneficiar do recurso de trilhas automáticas.
Configurando DRED no código
As configurações de DRED são globais para o processo e você deve configurá-las antes de criar um dispositivo Direct3D 12. Para fazer isso, chame a função D3D12GetDebugInterface para recuperar um ID3D12DeviceRemovedExtendedDataSettings.
CComPtr<ID3D12DeviceRemovedExtendedDataSettings> pDredSettings;
VERIFY_SUCCEEDED(D3D12GetDebugInterface(IID_PPV_ARGS(&pDredSettings)));
// Turn on auto-breadcrumbs and page fault reporting.
pDredSettings->SetAutoBreadcrumbsEnablement(D3D12_DRED_ENABLEMENT_FORCED_ON);
pDredSettings->SetPageFaultEnablement(D3D12_DRED_ENABLEMENT_FORCED_ON);
Observação
As modificações nas configurações de DRED não têm efeito nos dispositivos já criados. Mas as chamadas subsequentes para D3D12CreateDevice usam as configurações de DRED mais recentes.
Acessando dados DRED no código
Depois que a remoção do dispositivo for detectada (por exemplo, Apresentar retorna DXGI_ERROR_DEVICE_REMOVED), use os métodos da interface ID3D12DeviceRemovedExtendedData para acessar os dados DRED do dispositivo removido.
Para recuperar a interface ID3D12DeviceRemovedExtendedData , chame QueryInterface em uma interface ID3D12Device (ou derivada), passando o identificador de interface (IID) de ID3D12DeviceRemovedExtendedData.
void MyDeviceRemovedHandler(ID3D12Device * pDevice)
{
CComPtr<ID3D12DeviceRemovedExtendedData> pDred;
VERIFY_SUCCEEDED(pDevice->QueryInterface(IID_PPV_ARGS(&pDred)));
D3D12_DRED_AUTO_BREADCRUMBS_OUTPUT DredAutoBreadcrumbsOutput;
D3D12_DRED_PAGE_FAULT_OUTPUT DredPageFaultOutput;
VERIFY_SUCCEEDED(pDred->GetAutoBreadcrumbsOutput(&DredAutoBreadcrumbsOutput));
VERIFY_SUCCEEDED(pDred->GetPageFaultAllocationOutput(&DredPageFaultOutput));
// Custom processing of DRED data can be done here.
// Produce telemetry...
// Log information to console...
// break into a debugger...
}
Acesso do depurador ao DRED
Os depuradores têm acesso aos dados dred por meio do d3d12! Exportação de dados D3D12DeviceRemovedExtendedData .
Para usuários do WinDbg, consulte o repositório GitHub DirectX-Debugging-Tools para uma extensão WinDBG que facilita muito a depuração do estado de DRED do Direct3D 12.
Telemetria DRED
Seu aplicativo pode usar as APIs DRED para controlar os recursos de DRED e coletar telemetria para ajudar a analisar problemas. Isso oferece uma rede muito mais ampla para capturar esses TDRs difíceis de reproduzir.
A partir de Windows 10, versão 1903, todos os eventos removidos pelo dispositivo no modo de usuário são relatados para Relatório de Erros do Windows (WER), também conhecido como Watson. Se uma combinação específica de aplicativo, GPU e driver de exibição gerar um número suficiente de eventos removidos pelo dispositivo, é possível que o DRED seja temporariamente habilitado para clientes que iniciam o mesmo aplicativo em uma configuração semelhante.