Compartilhar via


Atualizações para versões 1.6 e posteriores do IddCx

As atualizações a seguir no IddCx versão 1.6 se aplicam a IDDs (drivers de exibição indireto) de console e remotos.

A versão anterior ao IddCx versão 1.6 era a versão 1.4. O IddCx versão 1.5 contém apenas alterações internas que não afetam os IDDs (drivers de exibição indiretos) externos. Para obter mais informações sobre a versão 1.4, consulte Atualizações do IdCx 1.4.

Versão atualizada do IddCxGetVersion

A versão IddCx retornada por IddCxGetVersion no Windows 10, versão 20H2 foi atualizada para IDDCX_VERSION_MANGANESE (0x1600). Consulte Versões do IddCx para obter uma lista completa de informações de versão relacionadas ao IddCx.

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

A partir do IddCx versão 1.6, os arquivos de símbolo IddCx públicos contêm todas as informações do WPP (processador de rastreamento de software) do Windows. Isso significa que o comando de 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 troca são residentes na memória do sistema; por exemplo, quando o adaptador de renderização que está sendo usado é WARP (Plataforma de Rasterização Avançada do Windows, o renderizador de software fornecido pelo sistema). O IddCx 1.6 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:

  • IddCxSwapChainInSystemMemory permite que uma IDD marcar 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 marcar o valor desse retorno de chamada em seu retorno de chamadaEvtIddCxMonitorAssignSwapChain e configurar o estado para liberar e adquirir buffers.

  • IddCxSwapChainReleaseAndAcquireSystemBuffer permite que uma 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, formato de superfície e dimensões). O buffer retornado é válido até a próxima chamada bem-sucedida para essa função.

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

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

É recomendável, mas não é necessário que um driver use essas funções de retorno de chamada. O comportamento anterior ao IddCx 1.6 permanece com suporte.

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

A partir do IddCx 1.6, o sinalizador IDDCX_ADAPTER_FLAGS_PREFER_PHYSICALLY_CONTIGUOUS e a função de retorno de chamada do so 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. Isso permite que um driver examine 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 tenha êxito. Se a solicitação não for bem-sucedida, a chamada para IddCxAdapterInitAsync não falhará. Em vez disso, depois que o driver tiver executado um IddCxSwapChainReleaseAndAcquireBuffer (ou IddCxSwapChainReleaseAndAcquireSystemBuffer), ele deverá 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 retornará E_NOINTERFACE.