O DirectX 12 expõe filas de comandos para tarefas gráficas (chamadas "Diretas"), de computação ou cópia. Em termos de funcionalidade fornecida, cada um é um superconjunto do seguinte. A especificação afirma que as filas de comandos podem ser executadas simultaneamente pelo dispositivo. No entanto, a API não limita o número de filas de comandos de forma alguma (pelo menos não conheço nenhuma limitação).
Aparentemente, diferentes fornecedores lidam com isso de maneira muito diferente:
- A Intel declarou em uma apresentação recente (slide 23) que atualmente suas GPUs não conseguem lidar com gráficos e computação em paralelo e que o mecanismo de cópia tem uma taxa de transferência fraca. Eles desaconselham o uso de várias filas de gráficos / computação.
- A AMD começou há muito tempo para anunciar o uso de filas / "sombreadores assíncronos" começando com Mantle e os atuais consoles gen. Existem também alguns desenvolvedores ( exemplo ) que confirmam ganhos significativos de desempenho executando tarefas de computação e gráficos em paralelo.
- Recentemente, houve alguns problemas com a Nvidia que não suporta shader assíncrono no hardware: o uso de filas Gráficas e de Computação separadas ao mesmo tempo parece tornar as coisas mais lentas, o que indica emulação de driver. As operações de cópia paralela, por outro lado, são suportadas pela CUDA há muito tempo, o que deixa claro que o mecanismo DMA pode funcionar de forma independente.
Existe alguma maneira de decidir em tempo de execução se é significativo confirmar CommandLists para vários CommandQueues em vez de um único? (considerando que o caso anterior não envolve muita sobrecarga de engenharia)
Embora eu possa ver facilmente como é útil executar operações de memória paralelamente às operações de computação / gráficos, parece-me desnecessariamente complicado executar vários processos de computação e gráficos em paralelo (a menos que não haja grande benefício em desempenho). Também não está claro para mim como isso pode levar a um desempenho significativamente melhor; exceto em casos patológicos em que muitas pequenas tarefas seqüenciais não conseguem gerar carga GPU suficiente.
Respostas:
Envie seu aplicativo com uma sequência de benchmarking testando a plataforma real. (Possível resposta para muitas perguntas, eu acho ...)
Eu suspeito que o desempenho depende muito de como você usa o hardware. Como é improvável que o hardware, de alguma forma, instrumente seu aplicativo de trás para a frente, dizendo o que você deve fazer, eu aceitaria o que parecer bem em seu design.
A palavra-chave é CAN. Não vejo razão para que algum fornecedor estrague tudo isso. No final, é o provedor da plataforma (Intel / AMD / Nvidia) quem é responsável por torná-lo um driver suficientemente bom para você não considerar a possibilidade de trocar de fornecedor. Se eles tiverem um "problema de conhecimento" com essa funcionalidade (que, a propósito, não tem significado funcional, apenas desempenho), eles também deverão resolvê-lo usando o que sabem. Quero dizer, pelo amor de Deus, o fallback é algo que eles já implementaram; execução sincronizada.
O hardware é vodu suficiente, pois é para nós desenvolvedores.
fonte