Compartilhar via

Teste do modo kernel de recursos do WDDM

Este artigo descreve o design da infraestrutura de teste do modo kernel no WDDM que foi adicionada no Windows 11 versão 24H2 (WDDM 3.2). Essa infraestrutura permite testar e validar drivers que não dão suporte a runtimes D3D, como drivers para alguns dispositivos de NPU. Ele também pode ser usado para validar drivers que dão suporte a runtimes D3D sem envolver o runtime D3D.

Visão geral

Há cenários em que novos dispositivos de computação baseados em WDDM ou MCDM são introduzidos e drivers para esses dispositivos não dão suporte a runtimes D3D. Para ajudar a validar esses drivers, uma funcionalidade é adicionada ao Dxgkrnl para realizar a validação usando somente thunks no modo kernel; isto é, sem envolver o runtime D3D e o UMD (driver de modo de usuário).

Essa infraestrutura também permite testar o recurso WDDM usando configurações precisas sem precisar passar por um runtime D3D ou um UMD, o que pode complicar as coisas.

Os DDIs são introduzidos para criar um buffer de comando no modo kernel para um determinado conjunto de comandos. Os comandos são simples, portanto, quase qualquer nó de execução deve ser capaz de executá-los usando sombreadores pré-compilados ou outros meios.

Para dar suporte a essa funcionalidade, o KMD (driver no modo kernel) deve fornecer o seguinte suporte:

  • Informe que o recurso DXGK_FEATURE_KERNEL_MODE_TESTING está habilitado.
  • Implemente a interface de recurso DXGKDDI_KERNELMODETESTINGINTERFACE.
  • Forneça informações sobre qual nó de execução suporta a criação e execução dos buffers de comando de teste.
  • Suporte à criação de uma fila de contexto/hardware sem dados de driver privados. Normalmente, o formato de comandos de driver privado é necessário para enviar uma carga de trabalho para um dispositivo. A interface de teste permite o envio de cargas de trabalho sem dados de controlador privados.
  • Suporte à execução de buffers de comando criados pelo pfnBuildTestCommandBuffer em qualquer nó do dispositivo que dê suporte ao recurso.
  • Dê suporte a um identificador de alocação NULL na paginação de DDIs (TRANSFER, FILL, etc.).

Esse recurso é usado somente quando a assinatura de teste está habilitada no computador.

Os testes HLK que usam esse recurso serão desenvolvidos.

Alterações de DDI

As seguintes estruturas e enumeração foram atualizadas para dar suporte a testes no modo kernel:

Os seguintes DDIs, estruturas e enumeração são adicionados para dar suporte a testes no modo kernel:

Suporte de relatório para o recurso de teste no modo kernel

O sistema operacional chama a função DxgkDdiQueryFeatureSupport do KMD com a ID de recurso DXGK_FEATURE_KERNEL_MODE_TESTING adicionada para verificar se o driver dá suporte a testes no modo kernel. O KMD precisa informar que o recurso tem suporte.

Em seguida, o sistema chama DxgkDdiQueryFeatureInterface com o mesmo ID de funcionalidade para obter o ponteiro de função da interface para pfnBuildTestCommandBuffer. O KMD deve implementar essa função e fornecer seu ponteiro para a interface DXGKDDI_KERNELMODETESTINGINTERFACE .

Relatar nós de execução que dão suporte a testes no modo kernel

SupportBuildTestCommandBuffer é adicionado à estrutura DXGK_NODEMETADATA_FLAGS. O KMD precisa definir este flag para indicar que o nó pode executar buffers de comando criados pelo pfnBuildTestCommandBuffer. É recomendável que o maior número possível de nós ofereça suporte ao recurso.

Criando um contexto sem dados privados

TestContext é adicionado a DXGK_CREATECONTEXTFLAGS para indicar que um contexto é um contexto de teste. Esse flag só tem efeito quando a assinatura de teste está habilitada.

DxgkDdiCreateContext da KMD deve dar suporte à criação de um contexto sem dados privados para cada nó que suporte a execução de buffers de comando produzidos pelo pfnBuildTestCommandBuffer. Para indicar esse suporte, defina o sinalizador TestContext em Sinalizadores durante a criação do contexto.

Criando uma fila de hardware sem dados privados do driver

TestQueue é adicionado a D3DDDI_CREATEHWQUEUEFLAGS para indicar que uma fila de hardware é uma fila de teste. Esta flag tem efeito apenas quando a assinatura de teste está habilitada.

DxgkDdiCreateHwQueue do KMD deve dar suporte à criação de uma fila de hardware sem dados privados do driver.

Criando um buffer de comando

O pfnBuildTestCommandBuffer do KMD cria um buffer de comando com instruções específicas do dispositivo para um conjunto de comandos simples. KMD retorna um ponteiro para essa função a partir de DxgkDdiQueryFeatureInterface(DXGK_FEATURE_KERNEL_MODE_TESTING).

Um único comando de teste é enviado para pfnBuildTestCommandBuffer. No momento, há suporte para os seguintes comandos:

Comando Descrição
D3DDDI_TESTCOMMAND_COPY Copia bytes usando endereços virtuais da GPU de origem e de destino.
D3DDDI_TESTCOMMANDBUFFER_FILL Preenche um local de memória com um padrão.

Os comandos de teste são baseados no uso de endereços virtuais de GPU. O sistema operacional garante que os VAs da GPU sejam mapeados para alocações criadas com um tipo de alocação padrão de D3DKMT_STANDARDALLOCATIONTYPE_EXISTINGHEAP ou D3DKMT_STANDARDALLOCATIONTYPE_INTERNALBACKINGSTORE.

O buffer de comando gerado e os dados privados são retornados de volta ao modo de usuário. Quando o buffer de comando é enviado para execução, a chamada vem do modo de usuário. Um aplicativo mal-intencionado pode alterar o conteúdo do buffer e dos dados privados. É responsabilidade do KMD validar o buffer de comando e os dados do driver privado para evitar verificações de bugs.

O buffer de comando gerado não deve conter instruções privilegiadas.

Um driver cliente no modo de usuário (por exemplo, Cuda) envia o buffer de comando gerado para execução usando D3DKMTSubmitCommand ou D3DKMTSubmitCommandToHwQueue. No futuro, o conteúdo do buffer será enviado como parte do envio do modo de usuário.

Quando um buffer de comando gerado é enviado para execução, é garantido que o buffer de comando contém instruções de dispositivo para um único comando de teste.

O buffer de comando gerado é enviado para o nó que corresponde ao hContext passado para pfnBuildTestCommandBuffer.

O tamanho do buffer DMA (pDmaBuffer) é limitado a 4 KB e o tamanho dos dados de driver privado do DMA (pDmaBufferPrivateData) é limitado a 1 KB.

  • Last updated on