Partilhar via

Atualizações para as versões 1.5, 1.6 e posteriores do IddCx

  • Artigo

As atualizações a seguir nas versões 1.5 e 1.6 do IddCx se aplicam aos IDDs (drivers de exibição indireta) remotos e de console.

Versão atualizada do IddCxGetVersion

A versão do IddCx retornada por IddCxGetVersion foi atualizada para 0x1500 para a versão 1.5 e 0x1600 para a versão 1.6. Consulte Versões do IddCx para obter uma lista completa das informações de versão relacionadas ao IddCx.

Informações do WPP em símbolos IddCx públicos

A partir da versão 1.5 do IddCx, os arquivos de símbolos públicos do IddCx contêm todas as informações do processador de rastreamento de software do Windows (WPP). Essa alteração significa que o comando do depurador !wmitrace.logdump decodifica e exibe a mensagem WPP no depurador de kernel.

Capacidade de acessar buffers alocados na memória do sistema

Em determinados cenários, os buffers de cadeia de troca residem na memória do sistema; por exemplo, quando WARP (Windows Advanced Rasterization Platform, o renderizador de software fornecido pelo sistema) é o adaptador de renderização que está sendo usado. O IddCx 1.5 adiciona os seguintes retornos de chamada do sistema operacional que permitem que o driver acesse buffers na memória do sistema, evitando assim uma cópia de sub-recurso:

  • O IddCxSwapChainInSystemMemory permite que um IDD verifique se os buffers de uma cadeia de troca são residentes na memória do sistema. O resultado desse retorno de chamada permanece constante durante todo o tempo de vida da cadeia de troca. O driver deve verificar o valor desse retorno de chamada em seu retorno de chamada EvtIddCxMonitorAssignSwapChain e configurar o estado para liberar e adquirir buffers.

  • IddCxSwapChainReleaseAndAcquireSystemBuffer permite que um IDD libere e adquira um buffer, bem como obtenha informações para acessar o buffer (como um ponteiro de memória do sistema, pitch/stride do buffer e formato e dimensões de superfície). O buffer retornado é válido até a próxima chamada bem-sucedida para essa função.

    No ponto de atribuição de uma nova cadeia de troca, o driver deve decidir qual variante de IddCxSwapChainReleaseAndAcquireBuffer/IddCxSwapChainReleaseAndAcquireSystemBuffer ele chamará para a cadeia de troca específica e deve continuar usando essa variante pelo resto do tempo de vida dessa cadeia de troca. Para decidir, o driver deve considerar seus requisitos específicos e o resultado da chamada para IddCxSwapChainInSystemMemory. Um driver faz com que o sistema operacional verifique o processo UMDF se:

    • Chama a outra variante de IddCxSwapChainReleaseAndAcquireSystemBuffer/IddCxSwapChainReleaseAndAcquireBuffer.
    • Chama IddCxSwapChainReleaseAndAcquireSystemBuffer quando IddCxSwapChainInSystemMemory retorna falso.

Os drivers são recomendados, mas não são necessários para usar essas funções de retorno de chamada. O comportamento antes do IddCx 1.5 continua com suporte.

Capacidade de acessar buffers na memória fisicamente contígua

Observação

IddCxSwapChainGetPhysicallyContiguousAddress não é suportado em nenhum sistema Windows 10 e provavelmente será descontinuado no futuro.

A partir do IddCx 1.6, o sinalizador IDDCX_ADAPTER_FLAGS_PREFER_PHYSICALLY_CONTIGUOUS e função de retorno OS de IddCxSwapChainGetPhysicallyContiguousAddress foram adicionados para que os buffers possam ser acessados na memória fisicamente contígua.

Os drivers de exibição podem solicitar que as superfícies primárias sejam alocadas na memória do sistema fisicamente contígua, definindo o sinalizador IDDCX_ADAPTER_FLAGS_PREFER_PHYSICALLY_CONTIGUOUS em IDDCX_ADAPTER_CAPS. Esse recurso permite que um driver digitalize diretamente uma superfície sem uma cópia intermediária.

Não há garantia de que a solicitação do driver durante a inicialização será bem-sucedida. Se a solicitação não for bem-sucedida, a chamada para IddCxAdapterInitAsync não falhará. Em vez disso, depois que o driver executa um IddCxSwapChainReleaseAndAcquireBuffer (ou IddCxSwapChainReleaseAndAcquireSystemBuffer), ele deve chamar IddCxSwapChainGetPhysicallyContiguousAddress para recuperar o endereço físico da superfície. IddCxSwapChainGetPhysicallyContiguousAddress primeiro aguardará todos os comandos de renderização pendentes e, em seguida, liberará e invalidará os caches de CPU associados ao intervalo de endereços em que a superfície está armazenada. No entanto, se a solicitação inicial para que as superfícies sejam alocadas na memória fisicamente contígua falhar IddCxSwapChainGetPhysicallyContiguousAddress retorna E_NOINTERFACE.