Teste em modo kernel de recursos WDDM
Este artigo descreve o design da infraestrutura de teste de modo kernel no WDDM que foi adicionada no Windows 11 versão 24H2 (WDDM 3.2). Essa infraestrutura permite o teste e a validação de drivers que não oferecem suporte a tempos de execução D3D, como drivers para alguns dispositivos NPU. Ele também pode ser usado para validar drivers que oferecem suporte a tempos de execução D3D sem envolver o tempo de execução D3D.
Visão geral
Há cenários em que novos dispositivos de computação baseados em WDDM ou MCDM são introduzidos e os drivers para esses dispositivos não oferecem suporte a tempos de execução D3D. Para ajudar a validar esses drivers, a funcionalidade é adicionada ao Dxgkrnl para fazer a validação usando apenas thunks no modo kernel, ou seja, sem envolver o tempo de execução do D3D e o driver de modo de usuário (UMD).
Essa infraestrutura também permite testar o recurso WDDM usando configurações precisas sem ter que passar por um tempo de execução D3D ou um UMD, o que pode complicar as coisas.
DDIs são introduzidas para construir um buffer de comandos no modo kernel para um determinado conjunto de comandos. Os comandos são simples, então quase qualquer nó de execução deve ser capaz de executá-los usando sombreadores pré-compilados ou outros meios.
Para oferecer suporte a essa funcionalidade, o driver de modo kernel (KMD) deve fornecer o seguinte suporte:
- Informe que o recurso DXGK_FEATURE_KERNEL_MODE_TESTING está habilitado.
- Implemente a interface de recursos DXGKDDI_KERNELMODETESTINGINTERFACE.
- Forneça informações sobre qual nó de execução oferece suporte à criação e execução dos buffers de comando de teste.
- Suporte a criação de uma fila de contexto/hardware sem dados de driver privado. 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 da carga de trabalho sem dados privados do driver.
- Suporte à execução de buffers de comando criados por pfnBuildTestCommandBuffer em qualquer nó do dispositivo que ofereça suporte ao recurso.
- Suporte a um identificador de alocação NULL em DDIs de paginação (TRANSFER, FILL, etc.).
Esse recurso é usado somente quando a assinatura de teste está habilitada no computador.
Testes HLK que utilizam esse recurso serão desenvolvidos.
Alterações de DDI
As seguintes estruturas e enumeração foram atualizadas para oferecer suporte ao teste de modo kernel:
DXGK_FEATURE_KERNEL_MODE_TESTING é adicionado à enumeração DXGK_FEATURE_ID.
SupportBuildTestCommandBuffer é adicionado à estrutura DXGK_NODEMETADATA_FLAGS.
TestContext é adicionado à estrutura DXGK_CREATECONTEXTFLAGS.
TestQueue é adicionado à estrutura D3DDDI_CREATEHWQUEUEFLAGS.
As seguintes DDIs, estruturas e enumeração são adicionadas para oferecer suporte ao teste de modo kernel:
A interface de recurso DXGKDDI_KERNELMODETESTINGINTERFACE é adicionada, com DXGKDDI_BUILDTESTCOMMANDBUFFER::p fnBuildTestCommandBuffer como o único membro da interface.
Suporte de relatórios para o recurso de teste de modo kernel
O sistema operacional chama a função DxgkDdiQueryFeatureSupport do KMD com o ID de recurso DXGK_FEATURE_KERNEL_MODE_TESTING adicionado para verificar se o driver oferece suporte ao teste de modo kernel. O KMD precisa informar que o recurso é suportado.
Em seguida, o sistema chama DxgkDdiQueryFeatureInterface com o mesmo ID de recurso para obter o ponteiro de função de interface para pfnBuildTestCommandBuffer. O KMD deve implementar essa função e fornecer seu ponteiro para a interface DXGKDDI_KERNELMODETESTINGINTERFACE.
Relatando nós de execução que oferecem suporte a testes no modo kernel
SupportBuildTestCommandBuffer é adicionado à estrutura DXGK_NODEMETADATA_FLAGS. O KMD deve definir esse sinalizador para indicar que o nó pode executar buffers de comando criados por pfnBuildTestCommandBuffer. Recomenda-se 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 sinalizador tem efeito somente quando a assinatura de teste está habilitada.
O DxgkDdiCreateContext do KMD deve oferecer suporte à criação de um contexto sem dados privados para cada nó que ofereça suporte à execução de buffers de comando produzidos por 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. Esse sinalizador tem efeito somente quando a assinatura de teste está habilitada.
O DxgkDdiCreateHwQueue do KMD deve oferecer 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 comandos com instruções específicas do dispositivo para um conjunto de comandos simples. KMD retorna um ponteiro para essa função de DxgkDdiQueryFeatureInterface(DXGK_FEATURE_KERNEL_MODE_TESTING).
Um único comando de teste é enviado para pfnBuildTestCommandBuffer. Os seguintes comandos são suportados atualmente:
| Comando | Descrição |
|---|---|
| D3DDDI_TESTCOMMAND_COPY | Copia bytes usando endereços virtuais de GPU de origem e 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 da GPU. O sistema operacional garante que as VAs da GPU sejam mapeadas 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 ao modo de usuário. Quando o buffer de comando é enviado para execução, a chamada é vinda do modo de usuário. Um aplicativo mal-intencionado pode alterar o conteúdo do buffer e os 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 de cliente de 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 no modo de usuário.
Quando um buffer de comando gerado é enviado para execução, é garantido que o buffer de comando contenha 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 do driver privado DMA (pDmaBufferPrivateData) é limitado a 1 KB.