GPUs são muito boas tarefas paralelas. O que é ótimo ... se você estiver executando tarefas paralelas.
Os jogos são sobre o tipo de aplicativo menos paralelizável. Pense no loop principal do jogo. A IA (vamos supor que o jogador seja tratado como um caso especial da AI) precisa responder a colisões detectadas pela física. Portanto, ele deve ser executado posteriormente. Ou, no mínimo, a física precisa chamar rotinas de IA dentro dos limites do sistema de física (o que geralmente não é uma boa ideia por muitas razões). Os gráficos não podem ser executados até que a física seja executada, porque é a física que atualiza a posição dos objetos. Obviamente, a IA também precisa ser executada antes da renderização, pois pode gerar novos objetos. Os sons precisam ser executados após a IA e os controles do jogador
Em geral, os jogos podem se alinhar de muito poucas maneiras. Os gráficos podem ser desmembrados em um thread; o loop do jogo pode empurrar um monte de dados no segmento de gráficos e dizer: renderize this. Ele pode fazer alguma interpolação básica, para que o loop principal do jogo não precise estar sincronizado com os gráficos. O som é outro segmento; o loop do jogo diz "play this" e é reproduzido.
Depois disso, tudo começa a ficar dolorido. Se você tiver algoritmos de processamento complexos (como os de RTS), poderá encadear esses. Pode levar alguns quadros para que os algoritmos sejam concluídos, mas eles serão simultâneos pelo menos. Além disso, é bem difícil.
Então, você está analisando quatro tópicos: jogo, gráficos, som e possivelmente processamento de AI a longo prazo. Isso não é muito. E isso não é suficiente para GPUs, que podem ter literalmente centenas de threads em execução ao mesmo tempo. É isso que dá às GPUs seu desempenho: poder utilizar todos esses threads de uma vez. E os jogos simplesmente não podem fazer isso.
Agora, talvez você possa ir "longe" em algumas operações. As IAs, por exemplo, geralmente são independentes uma da outra. Assim, você pode processar várias dezenas de IAs ao mesmo tempo. Até que você realmente precise torná-los dependentes um do outro. Então você está com problemas. Objetos de física são igualmente independentes ... a menos que haja uma restrição entre eles e / ou colidem com alguma coisa. Então eles se tornam muito dependentes.
Além disso, há o fato de que a GPU simplesmente não tem acesso à entrada do usuário, o que, pelo que entendi, é meio importante para os jogos. Então isso teria que ser fornecido. Também não possui acesso direto a arquivos ou qualquer método real de comunicação com o sistema operacional; então, novamente, teria que haver algum tipo de maneira de fornecer isso. Ah, e todo esse processamento de som? GPUs não emitem sons. Então eles precisam voltar para a CPU e depois para o chip de som.
Ah, e a codificação para GPUs é terrível. É difícil acertar, e o que é "certo" para uma arquitetura de GPU pode estar muito, muito errado para outra. E isso não é apenas mudar da AMD para a NVIDIA; isso pode estar mudando de uma GeForce 250 para uma GeForce 450. Essa é uma mudança na arquitetura básica. E poderia facilmente fazer com que seu código não funcionasse bem. C ++ e até C não são permitidos; o melhor que você obtém é o OpenCL, que é parecido com o C, mas sem alguns detalhes. Como recursão . É isso mesmo: sem recursão nas GPUs.
Depurando? Ah, espero que você não goste dos recursos de depuração do IDE, porque esses certamente não estarão disponíveis. Mesmo se você estiver usando GDB, dê um beijo de despedida. Você terá que recorrer à printf
depuração ... espere, não há printf
GPUs. Portanto, você terá que gravar nos locais da memória e fazer com que seu programa de stub da CPU os leia novamente.
É isso mesmo: depuração manual . Boa sorte com isso.
Além disso, essas bibliotecas úteis que você usa em C / C ++? Ou talvez você seja mais do tipo .NET, usando XNA e assim por diante. Como queiras. Não importa, já que você não pode usar nenhum deles na GPU. Você deve codificar tudo do zero. E se você já possui uma base de código, é difícil: é hora de reescrever todo esse código.
Então sim. É horrível fazer qualquer tipo de jogo complexo. E nem funcionaria, porque os jogos simplesmente não são paralelos o suficiente para ajudar.