Les mises à jour des pilotes de GPU PC citent souvent des améliorations apportées aux performances de jeux spécifiques récemment publiés. Pourquoi cette mise à jour spécifique au jeu est-elle nécessaire? Comment les modifications spécifiques au jeu interagissent-elles avec le code du jeu?
Réponses:
En tant que personne ayant quelques années de développement de pilotes, je vois cela comme deux problèmes distincts.
Un pilote graphique est une bête très compliquée. Tout mettre en œuvre de manière optimale serait une tâche tout simplement impossible; c'est un obstacle assez grand pour créer un pilote qui respecte réellement les spécifications - et les spécifications deviennent de plus en plus complexes. Donc, vous développez votre pilote en fonction des spécifications et d'une poignée d'applications de test (car, dans de nombreux cas, il n'y a pas encore de vrai logiciel).
Vient ensuite un vrai jeu (ou benchmark, ou un autre cas d'utilisation pour le pilote, comme le décodage vidéo) qui expose un goulot d'étranglement dans le pilote. Vous allez découvrir comment lisser les choses et rendre ce cas d'utilisation plus rapide. Vous pouvez facilement signaler que le jeu XYZ est 27,3% plus rapide, mais en réalité, chaque application qui a un tel cas d'utilisation (par exemple, une mise à jour de texture dynamique) devient plus rapide.
Ensuite, il y a le côté laid, de réelles optimisations par application, dans lesquelles le pilote détecte quelle application est exécutée (ou quel shader est en cours de compilation) et fait quelque chose de non générique. Il y a eu beaucoup de cas publicisés de cela, où, par exemple, renommer l'exécutable 3dmark change soudainement les résultats.
Je pense que ce type d'optimisations est une perte de temps pour tout le monde - vous mentez à vos clients dans le cas des benchmarks, et vous pouvez changer la façon dont un shader se comporte par rapport à ce que le développeur veut réellement. Je me souviens d'un cas où un shader était passé d'une recherche de texture à un calcul dans le shader (qui ne fonctionnait que pour le matériel dudit fabricant) qui était proche, mais pas exactement le même résultat, et le développeur a rétorqué que ce n'était pas légal optimisation.
Dans un monde idéal, ils ne le feraient pas.
Cependant, ce n'est pas un monde idéal, donc les améliorations des performances spécifiques au jeu peuvent provenir d'un ou plusieurs des éléments suivants (qui ne sont pas censés être une liste exhaustive):
Le jeu fait une combinaison des opérations A, B et C avec les états X, Y et Z définis. Le pilote peut faire des hypothèses sur cette base et pousser les choses vers un chemin de code plus optimal.
Le jeu ne fait jamais d'opérations I, J ou K. Encore une fois, le pilote peut être en mesure de choisir un chemin de code plus optimal basé sur la possibilité de supposer que ces opérations ne sont jamais effectuées.
Le jeu fait certaines choses de manière légèrement (ou pas si légèrement) sous-optimale. Le conducteur le sait, intercepte les appels et les convertit en quelque chose (espérons-le!) Qui fonctionnera mieux avec.
Des compromis spécifiques au jeu peuvent être effectués; par exemple, c'est OK si cette combinaison d'états de rendu va lentement parce qu'il est plus important que cette combinaison aille plus vite, alors optimisons en conséquence.
Il est important de noter ici qu'aucun de ces éléments ne devrait en fait être "requis". Tant que le pilote et l'utilisation de l'API du jeu sont conformes, les choses devraient fonctionner. Mais parfois, des compromis dans des cas particuliers pour pouvoir extraire les performances maximales peuvent être considérés comme appropriés. Je m'abstiendrai de dire si c'est une bonne chose ou non.
Les développeurs de jeux repoussent les limites des GPU. Nous pouvons faire une analogie avec un jeu et un moteur de jeu. Plus les exigences du jeu sont avancées, plus le moteur de jeu doit être avancé pour le prendre en charge. C'est la même chose avec les cartes graphiques.
Les jeux informatiques et les fabricants de GPU sont de bons compagnons de lit. Il est dans leur intérêt de travailler ensemble pour améliorer le GPU, améliorant ainsi le jeu. Il s'agit des types de logiciels classiques qui travaillent avec la relation des types de matériel. Les deux parties ont quelque chose à ajouter en ce qui concerne la conception de l'interface entre le logiciel et le matériel. Cette interface est le pilote.
Ces mises à jour peuvent inclure des corrections de bogues que les gars du logiciel ont trouvées ou des améliorations que les gars du matériel ont apportées pour prendre en charge les exigences des gars du logiciel. Vous trouverez cette relation partout.
Le raisonnement derrière l'inclusion des jeux spécifiques dans les notes de mise à jour du pilote est probablement PR. Cela montre non seulement que le fabricant de cartes X va très bien fonctionner avec le jeu Y, mais cela montre que le jeu Y sera encore meilleur qu'avant.
Il est plausible que l'équipe de développement du jeu ait rencontré un bogue de pilote GPU qui empêcherait le jeu de fonctionner correctement si le bogue du pilote n'était pas corrigé.
C'est aussi parfois un gadget marketing . Par exemple, ATI / AMD a récemment fourni une copie de Dirt 3 avec leurs nouveaux GPU et a poussé l'idée de jouer avec Eyefinity avec 3 moniteurs sur ce jeu.
C'est donc un peu de symbiose.
Vendeur de GPU: Hé! Cette nouvelle fonctionnalité! Personne ne l'utilise!
Développeur du jeu: nous pourrions l'utiliser! Bundle notre jeu avec votre GPU qui utilise cette fonctionnalité?
Vendeur de GPU: Hell ya!
La vérité est que les GPU ne nécessitent pas de pilotes spécifiques au jeu.
Les pilotes spécifiques au jeu font partie d'un effort marketing des fabricants de GPU pour essayer de prendre l'avantage sur les autres fabricants de GPU. S'ils peuvent montrer de meilleures performances dans les jeux populaires en ayant personnalisé leurs pilotes pour ces jeux spécifiques, alors (selon la théorie), ils attirent plus de joueurs de ces jeux.
C'est à peu près tout ce qu'il y a à faire.