Respostas:
De um modo geral: as transformações de malha são feitas na GPU. Você envia a matriz de transformação para a GPU e o sombreador a aplica a todos os vértices da malha.
Usar a GPU para calcular a própria matriz é uma questão diferente e, na verdade, é mais lento na GPU, porque existem muitos valores armazenados que mudam de quadro para quadro, necessários para ajudar a determinar a matriz de transformação final. O envio desses dados para a CPU - GPU é lento. Além disso, na CPU, os cálculos são feitos uma vez, enquanto na GPU, eles são feitos para cada vértice.
Muitas transformações geométricas podem ser feitas em processadores que não são de GPU, mas é preciso considerar a plataforma de destino. Sua milhagem variará com base na plataforma que você está segmentando e nos gargalos dessa plataforma.
Uma consideração é a largura de banda do barramento entre o dispositivo que está gerando a geometria e o dispositivo que está renderizando a geometria.
Em um sistema típico de PC moderno, a CPU está em um lado do barramento PCIe (http://en.wikipedia.org/wiki/PCI_Express) e a GPU está no outro. A única maneira de transferir dados gerados por quadro da CPU para a GPU (e vice-versa) é através desse barramento. Isso significa que você pode ser limitado pela velocidade de transferência desse barramento. Se sua plataforma de destino tiver PCIe 2.x com 16 faixas, você terá 8 GB / s de largura de banda. Na prática, as transferências através do PCIe não são 100% eficientes, pois parte da largura de banda é consumida pelo protocolo durante suas transferências. Dependendo do tamanho das suas transferências, você poderá perder de 5 a 10% da sua largura de banda apenas na sobrecarga por pacote.
por exemplo. Dada uma plataforma de PC executando o PCIe 2.x com 16 pistas, quantos dados você pode gerar por quadro para alimentar a GPU? Supondo que você queira executar a 60fps, isso se traduz em 8 GB / 60 = 136 MB por quadro para o PCIe 2.x. Multiplicando por algum fator (convidado) de 90% para compensar a sobrecarga de comunicação do driver e a sobrecarga do protocolo de transferência PCIe, você pode gerar cerca de 120Mb de dados por quadro sem ficar limitado pela largura de banda do PCIe 2.x.
Outra pergunta a ser respondida: a geração desses 120Mb de dados será facilmente alcançável em 1/60 de segundo na CPU de destino? Lembrando que você precisa executar várias outras tarefas do jogo em sua CPU, pode ficar com falta de tempo para gerar os dados transformados. Em termos de taxa de transferência pura da ALU, isso pode limitar a CPU. Em termos de CPU para barramentos de sysmem, você também pode ser limitado pela largura de banda (que varia, mas é de cerca de ~ 8,5 GB / s em CPUs recentes).
Tudo bem, então que fatores tornam mais viável fazer em uma GPU? Um fator é a largura de banda da memória da GPU, que é a largura de banda entre a GPU e a memória de vídeo local. Nas GPUs contemporâneas de gama média, essa largura de banda da memória de vídeo pode chegar a 200 GB / s (sim, isso é 25x a largura de banda do PCIe 2.x). Outro fator é que a GPU é massivamente paralela, possui centenas de ALUs e é capaz de ocultar a latência de acesso à memória executando milhares de threads por vez.
Todos esses fatores podem contribuir para a vitória óbvia de colocar mais trabalho na GPU, mas novamente o YMMV, dependendo da plataforma de destino.
O que você quer dizer com "transformações de malha"? Transformando geometria por algum conjunto de matrizes? Atualmente, a maioria dos jogos permite que a GPU lide com transformações simples, aparência, etc. E a maioria deles usará shaders de vértice para fazer isso. Em algumas plataformas, você não tem sombreadores ou há outras vantagens em fazer essas coisas na CPU. Por exemplo, no PS3, você pode aliviar a carga do RSX deixando as SPUs lidar com a aparência e a transformação. Se você estiver realizando iluminação com várias passagens, a cobertura na CPU pode ser vantajosa, pois você só precisa fazer uma vez e enviar os resultados a serem desenhados para cada passagem de renderização. Portanto, há exceções, mas, em geral, a maioria dos jogos faz essas coisas na GPU e nos shaders.
Ou você quis dizer algo mais sofisticado, como usar a GPU para matemática geral de vetores? Atualmente, temos GPUs de uso geral que podem executar código C bastante genérico por meio de sistemas como CUDA. É possível tirar proveito disso para matemática vetorial pesada, e eu sei que existem programas por aí que fazem isso. Eu não tenho nenhuma experiência com isso pessoalmente.
Existem situações em que ter tudo processado na GPU pode fazer sentido, mas você não pode definir constantes dentro de um sombreador e realmente não há outro lugar para configurá-las, exceto no lado da CPU antes de uma chamada de empate.
Mesmo se você pudesse calcular suas constantes, como as matrizes de transformação óssea, na GPU com um programa de inicialização personalizado, provavelmente não desejaria. a GPU é realmente boa em execução paralela, mas tem uma velocidade de clock muito mais lenta.
Transformar uma hierarquia não é trivialmente paralelelizável, porque os nós filhos dependem dos pais, mas transformar todos os vértices de uma malha é, porque os vértices são computacionais independentes um do outro.
A regra geral é: