Antworten:
Als jemand mit ein paar Jahren Treiberentwicklung sehe ich dies als zwei getrennte Probleme.
Ein Grafiktreiber ist ein sehr kompliziertes Biest. Alles optimal umzusetzen, wäre eine schlichtweg unmögliche Aufgabe; Es ist eine Hürde, die groß genug ist, um einen Fahrer so zu machen, dass er tatsächlich den Spezifikationen folgt - und die Spezifikationen werden immer komplexer. Sie entwickeln also Ihren Treiber basierend auf der Spezifikation und einer Handvoll Testanwendungen (da es in vielen Fällen noch keine echte Software gibt).
Damit einher geht ein echtes Spiel (oder ein Benchmark oder ein anderer Anwendungsfall für den Treiber, z. B. die Videodekodierung), der einen Engpass im Treiber aufdeckt. Finden Sie heraus, wie Sie Dinge glätten und diesen Anwendungsfall beschleunigen können. Sie können leicht melden, dass das Spiel XYZ 27,3% schneller ist, aber in Wirklichkeit wird jede Anwendung, die den Anwendungsfall (z. B. dynamisches Textur-Update) verwendet, schneller.
Dann gibt es die hässliche Seite, echte Optimierungen pro Anwendung, bei denen der Treiber erkennt, welche Anwendung ausgeführt wird (oder welcher Shader kompiliert wird) und etwas anderes unternimmt. Es gibt eine Menge publizierter Fälle, in denen beispielsweise das Umbenennen von ausführbaren 3dmark-Dateien die Ergebnisse plötzlich verändert.
Ich halte Optimierungen dieser Art für eine Zeitverschwendung für jedermann - Sie belügen Ihre Kunden im Falle von Benchmarks und können das Verhalten eines Shaders gegenüber dem ändern, was der Entwickler tatsächlich wünscht. Ich erinnere mich an einen Fall, in dem ein Shader von einer Textur-Suche zu einer In-Shader-Berechnung (die nur für die Hardware des Herstellers funktionierte) geändert wurde, die nahe beieinander lag, aber nicht genau dasselbe Ergebnis hatte und der Entwickler dem widersprach, dass dies nicht legal war Optimierung.
In einer idealen Welt würden sie nicht.
Dies ist jedoch keine ideale Welt. Daher können Verbesserungen der spielspezifischen Leistung auf eine oder mehrere der folgenden Ursachen zurückzuführen sein (keine vollständige Liste):
Das Spiel führt eine Kombination der Operationen A, B und C aus, wobei die Zustände X, Y und Z gesetzt sind. Der Fahrer kann auf dieser Grundlage Annahmen treffen und die Dinge auf einen optimaleren Codepfad verschieben.
Das Spiel führt die Operationen I, J oder K niemals aus. Wiederum kann der Fahrer möglicherweise einen optimaleren Codepfad auswählen, da er davon ausgehen kann, dass diese Operationen niemals ausgeführt werden.
Das Spiel macht einige Dinge auf eine leicht (oder nicht so leicht) suboptimale Art und Weise. Der Fahrer weiß das, fängt die Anrufe ab und wandelt sie in etwas (hoffentlich!) Äquivalentes um, das damit besser funktioniert.
Es können spielspezifische Kompromisse eingegangen werden. ZB ist es in Ordnung, wenn diese Kombination von Renderzuständen langsam ist, weil es wichtiger ist, dass diese Kombination schneller ist. Optimieren wir sie also entsprechend.
Hierbei ist zu beachten, dass keines dieser Elemente tatsächlich "erforderlich" sein sollte. Solange sowohl der Treiber als auch die API-Nutzung des Spiels konform sind, sollten die Dinge funktionieren. Manchmal werden jedoch Kompromisse in Sonderfällen als angemessen erachtet, um die maximale Leistung zu erzielen. Ich werde es unterlassen zu kommentieren, ob das eine gute Sache ist oder nicht.
Spieleentwickler erweitern die Grenzen von GPUs. Wir können eine Analogie zu einem Spiel und einer Spiel-Engine herstellen. Je fortgeschrittener die Anforderungen des Spiels sind, desto fortgeschrittener muss die Spiel-Engine sein, um es zu unterstützen. Dies gilt auch für Grafikkarten.
Computerspiele und GPU-Hersteller sind gute Bettgenossen. Es ist in ihrem besten Interesse, zusammenzuarbeiten, um die GPU und damit das Spiel zu verbessern. Dies ist der klassische Software-Typ, der mit der Hardware-Typ-Beziehung arbeitet. Bei der Gestaltung der Schnittstelle zwischen Software und Hardware müssen beide Parteien etwas hinzufügen. Diese Schnittstelle ist der Treiber.
Diese Updates können Fehlerbehebungen, die die Software-Entwickler gefunden haben, oder Verbesserungen der Hardware-Entwickler enthalten, um die Anforderungen der Software-Entwickler zu erfüllen. Sie werden diese Beziehung überall finden.
Wahrscheinlich ist die Begründung für die Aufnahme der spezifischen Spiele in die Versionshinweise für Treiber-Updates PR. Es zeigt nicht nur, dass der Kartenhersteller X sehr gut mit Spiel Y zusammenarbeiten wird, sondern auch, dass Spiel Y noch besser sein wird als zuvor.
Es ist plausibel, dass das Spieleentwicklungsteam auf einen GPU-Treiberfehler gestoßen ist, der dazu führen würde, dass das Spiel nicht richtig funktioniert, wenn der Treiberfehler nicht behoben worden wäre.
Es ist auch manchmal ein Marketing-Gag . Zum Beispiel hat ATI / AMD kürzlich eine Kopie von Dirt 3 mit den neueren GPUs gebündelt und die Idee, bei diesem Spiel mit 3 Monitoren mit Eyefinity zu spielen, vorangetrieben.
Es ist also eine Symbiose.
GPU-Anbieter: Hey! Diese neue Funktion! Niemand benutzt es!
Spieleentwickler: Wir könnten es gebrauchen! Kombinieren Sie unser Spiel mit Ihrer GPU, die diese Funktion nutzt?
GPU-Anbieter: Hölle ya!
Die Wahrheit ist, dass GPUs keine spielspezifischen Treiber benötigen .
Spielspezifische Treiber sind Teil der Marketingbemühungen der GPU-Hersteller, um einen Vorsprung gegenüber anderen GPU-Herstellern zu erzielen. Wenn sie in beliebten Spielen eine bessere Leistung zeigen können, indem sie ihre Treiber auf diese spezifischen Spiele abgestimmt haben, ziehen sie (so die Theorie) mehr Spieler dieser Spiele an.
Das ist so ziemlich alles.