Como alguém com alguns anos de desenvolvimento de drivers, vejo isso como dois problemas separados.
Um driver gráfico é uma fera muito complicada. Implementar tudo da maneira ideal seria uma tarefa simplesmente impossível; é um obstáculo grande o suficiente apenas para criar um driver que realmente siga as especificações - e as especificações estão ficando cada vez mais complexas. Portanto, você desenvolve seu driver com base nas especificações e em vários aplicativos de teste (como, em muitos casos, ainda não há software real ).
Junto vem um jogo real (ou benchmark, ou algum outro caso de uso para o driver, como decodificação de vídeo) que expõe um gargalo no driver. Você vai descobrir como suavizar as coisas e tornar esse caso de uso mais rápido. Você pode facilmente relatar que o jogo XYZ é 27,3% mais rápido, mas, na realidade, todos os aplicativos que mencionam casos de uso (por exemplo, atualização dinâmica de textura) ficam mais rápidos.
Depois, há o lado feio, as otimizações reais por aplicativo, em que o driver detecta qual aplicativo está sendo executado (ou qual shader está sendo compilado) e faz algo não genérico. Houve muitos casos divulgados disso, nos quais, por exemplo, renomear o executável 3dmark muda repentinamente os resultados.
Eu sinto que esse tipo de otimização é uma perda de tempo para todo mundo - você mente para seus clientes no caso de benchmarks e pode mudar a maneira como um shader se comporta do que o desenvolvedor realmente deseja. Lembro-me de um caso em que um sombreador foi alterado de uma pesquisa de textura para um cálculo dentro do sombreador (que só funcionava para o hardware do fabricante) que estava próximo, mas não exatamente o mesmo resultado, e o desenvolvedor recusou que isso não fosse legal otimização.
Em um mundo ideal, eles não iriam.
No entanto, este não é um mundo ideal; portanto, as melhorias de desempenho específicas do jogo podem vir de um ou mais dos seguintes itens (não destinados a ser uma lista exaustiva):
O jogo está fazendo uma combinação das operações A, B e C com os estados X, Y e Z definidos. O driver pode fazer suposições com base nisso e levar as coisas a um caminho de código mais ideal.
O jogo nunca executa as operações I, J ou K. Novamente, o driver pode escolher um caminho de código mais ideal baseado em poder assumir que essas operações nunca são realizadas.
O jogo faz algumas coisas de uma maneira um pouco (ou não um pouco) subótima. O motorista sabe disso, intercepta as chamadas e as converte em algo (espero!) Equivalente que funcionará melhor com ele.
É possível fazer trocas específicas do jogo; por exemplo, tudo bem se essa combinação de estados de renderização ficar lenta, porque é mais importante que essa combinação seja mais rápida, então vamos otimizar de acordo.
É importante observar aqui que nenhum desses deve realmente ser "necessário". Desde que o driver e o uso da API do jogo sejam compatíveis, as coisas devem funcionar. Às vezes, porém, trocas de casos especiais para extrair o desempenho máximo podem ser consideradas apropriadas. Abster-me-ei de comentar se isso é bom ou não.
fonte
Os desenvolvedores de jogos aumentam os limites das GPUs. Podemos fazer uma analogia com um jogo e um mecanismo de jogo. Quanto mais avançados os requisitos do jogo, mais avançado será o mecanismo do jogo para suportá-lo. É o mesmo com as placas gráficas.
Jogos de computador e fabricantes de GPU são bons companheiros de cama. É do interesse deles trabalhar juntos para melhorar a GPU, melhorando assim o jogo. Este é o pessoal de software clássico que trabalha com o relacionamento de pessoal de hardware. Ambas as partes têm algo a acrescentar quando se trata de projetar a interface entre software e hardware. Essa interface é o driver.
Essas atualizações podem incluir correções de bugs encontradas pelos caras do software ou melhorias feitas pelos caras do hardware para dar suporte aos requisitos dos caras do software. Você encontrará esse relacionamento por todo o lado.
Provavelmente, o raciocínio por trás da inclusão de jogos específicos nas notas de versão da atualização do driver é PR. Isso não apenas mostra que o fabricante do cartão X funcionará muito bem com o jogo Y, mas também mostra que o jogo Y será ainda melhor do que era antes.
fonte
É plausível que a equipe de desenvolvimento do jogo tenha encontrado um bug do driver da GPU que faria com que o jogo não funcionasse corretamente se o bug do driver não fosse corrigido.
Às vezes, também é um truque de marketing . Por exemplo, a ATI / AMD juntou recentemente uma cópia do Dirt 3 com suas GPUs mais recentes e propôs a ideia de jogar com o Eyefinity com 3 monitores neste jogo.
Então é um pouco de simbiose lá.
Fornecedor de GPU: Ei! Este novo recurso! Ninguém está usando!
Desenvolvedor de jogos: nós poderíamos usá-lo! Agrupar nosso jogo com sua GPU que usa esse recurso?
Fornecedor de GPU: Inferno!
fonte
A verdade é que as GPUs não exigem drivers específicos do jogo.
Os drivers específicos do jogo fazem parte de um esforço de marketing dos fabricantes de GPU para tentar obter uma vantagem sobre outros fabricantes de GPU. Se eles podem mostrar melhor desempenho em jogos populares, ajustando seus drivers para esses jogos específicos, então (segundo a teoria) eles atraem mais jogadores desses jogos.
Isso é praticamente tudo o que existe.
fonte