Also wenn ich es richtig verstehe, laufen viele Funktionen über ne Art White- bzw. Blacklisting.
Ist sowas üblich?
Und wie läuft das ab, muss da vorab jedes Szenario manuell gestestet und hinterlegt werden oder läuft für die Abfrage ne Art Routine ab, die dann entscheidet ob aktiv setzen oder nicht?
Und wieviel Handhabe haben dabei die Softwareentwickler?
Ist üblich.
Die Treiber besitzen mehrere optimierte Pfade, die entweder durch eine Heuristik, je nach Fall benützt werden oder durch explizite Profile verwendet werden.
So gibt es auch Fälle, wo die einfache Umbenennung der Dateien Softwareoptimierungen für ein Spiel aktiviert, weil der Treiber sich dann anders verhält.
CS:GO hatte unter Linux z.B. kein optimiertes Profil, wenn man dann die binary in hl2 umbenannt hat, lief das Spiel deutlich schneller:
How To Make Counter-Strike: Global Offensive Run Much Faster On AMD Catalyst For Linux - Phoronix
Softwareentwickler haben nur indirekt Handhabe, indem Sie Empfehlungen bekommen, wie entsprechende Compiler- oder Treiberroutinen getriggert werden können und ihren Code entsprechend strukturieren und schreiben.
Wobei ich auf Twitter auch Beschwerden gehört habe, über unterschiedliche slow/fast-paths bei den Herstellern, die öffentlich und auch privat kaum kommuniziert und dokumentiert sind.
Das macht es natürlich nicht leicht dem Treiber und letztendlich der Hardware entgegen zu kommen, wenn man nicht genau weiß, worauf man achten sollte oder welche Funktion welchen Trigger umlegt.
Das stimmt, ähnlich wie bei Chill gibt es eine Gamewhitelist. Wahrscheinlich will AMD garantieren das es auch funktioniert. Die Entwickler haben auf alles Zugriff. Meine frühere These das AMD wahrscheinlich mit hardwareimplementierten (LL-selbstverwaltenden) Funktionen (HBCC) die Entwickler ausschließt, haben sich nicht bestätigt und dürften falsch argumentiert sein (Asche auf mein Haupt...). Der Entwickler muss z.B. den HBCC Zugriff zulassen.
[...]
Der Entwickler hat darüber gar keine Kontrolle, er programmiert nur seine Anwendung und der Treiber bzw. HBCC setzt das um, wie er es möchte.
Wie das geregelt wird kann nur AMD sagen was bekannt ist das die Primitive Shader eigentlich in den spielen implementiert werden müssen das ist aber noch nicht passiert also geht AMD den Weg wie es Nvidia bei vulcan macht dem über die Software.
[...]
Aktuell ist AMD damit bemüht die Funktion automatisch im Treiber zu implementieren, die explizite Kontrolle für Entwickler ist vorerst nicht geplant und befindet sich eher in einer Evaluationsphase.
Ryan Smith ist ein Redakteur von Anandtech:
Ryan Smith schrieb:
Quick note on primitive shaders from my end: I had a chat with AMD PR a bit ago to clear up the earlier confusion. Primitive shaders are definitely, absolutely, 100% not enabled in any current public drivers.
The manual developer API is not ready, and the automatic feature to have the driver invoke them on its own is not enabled.
AMD Vega Hardware Reviews | Page 59 | Beyond3D Forum
Ryan Smith schrieb:
AMD is still trying to figure out how to expose the feature to developers in a sensible way. Even more so than DX12, I get the impression that it's very guru-y. One of AMD's engineers compared it to doing inline assembly. You have to be able to outsmart the driver (and the driver needs to be taking a less than highly efficient path) to gain anything from manual control.
AMD Vega Hardware Reviews | Page 59 | Beyond3D Forum
Wer es von einem AMD-Mitarbeiter hören möchte:
No plans to expose them programatically today, but we do review the state of play periodically so that might change. No plans rn though
The driver takes care of it for you. Just render as normal.
Yep. From your perspective we made a more efficient GPU and you don't do anything different. Might change later but no promises.
Rys Sommefeldt auf Twitter: "@bobvodka No plans to expose them programatically today, but we do review the state of play periodically so that might change. No plans rn though"