AW: AMD Radeon R9 290X im Test: Der langersehnte Titan-Killer für 479 Euro?
Nein. Dafür brauchst du Kenntnisse, was auf der GPU in Zukunft vorgehen wird. Und es liegt nicht so ganz an den GPU-Entwicklern, dass diese Daten immer noch nicht zur Verfügung gestellt werden, sondern an den blöden Physikern, die ihre Zeitmaschienen immer gleich in Raumgröße bauen, weswegen diese nicht integriert werden können...
Das einzige, was Nvidia&AMD liefern könnten, wäre eine Info darüber, wie lange das Rendering der letzten Frames dauerte. Aber wenn man daraus Rückschlüsse ziehen könnte, wie lange der nächste dauern wird, hätte man das Problem nicht. Das hat man, weil die Intervalle unregelmäßig und unvorhersagbar sind.
Natürlich kannst du sowas interpolieren. Du brauchst halt gescheite Heuristiken darüber, wie lange was ungefähr dauert. Daraus kannste dann schnell interpolieren, wie lange es etwa dauern wird. Genau solche Sachen werden zumindest meines Wissens nach ja auch bereits gemacht in einigen Engines. Den Spieleentwicklern fehlen nur eben teils die nötigen Informationen darüber, wie lange denn jetzt etwas wirklich genau dauert, und wie wo was genau ausgelastet ist, um ein gescheites Profiling zu machen.
Sprich das was bei CPUs schon seit zich Jahren standard ist...
Klar ist profiling ein gewisser Aufwand, aber wenn man das einmal gescheit implementiert hat, am besten über eine API, dann kann man es auch leicht und schnell nutzen.
Das derzeitige Framepacing wurde entwickelt, um Probleme, die aus dem Hardwaresetup entstehen, zu lindern. Dinge, um die sich ein Gamedeveloper weder kümmern müssen sollte noch in der Praxis kann, wovon die GPU-Hersteller aber Gerüchten zu Folge ein bißchen Ahnung haben.
Natürlich sollte der Programmierer davon am Besten so viel Information wie möglich bekommen. Vor allem wenn er z.B. gezielt auch noch der Hardware mitteilen könnte, dass das kommende Bild z.B. mehr/weniger Aufwand ist, als im Durchschnitt. Dann könnte er z.B. gezielt den Turbo ausnutzen, um die Frameausgabe weiter zu glätten, und genau dann wenn er die Power braucht auch wirklich die voller Power möglichst zu haben.
Natürlich, Hardware-Hersteller sind immer der total falsche Ort, um ein Hardware-Problem zu lösen. Viel besser ist, es eine spezielle API zu entwickeln, mit der diverse Informationen zu einem sehr komplexen Problem an die Anwendung übergeben werden können. Dann können gottgleiche Softwareentwickler in jedes Spiel eine perfekte Lösung integrieren, auf jede nur erdenkliche heutige und zukünftige Hardwarekonfiguration perfekt optimiert ist, während die unwissenden Ingenieure ihre Kinnladen einsammeln gehen.
Es ist eben kein reines Hardwareproblem. Die Hardware kann nie wissen, ob ein Bild aufwändig oder einfach ist. Da wir heute nur noch GPUs mit Boost haben, und sich das auch in Zukunft nicht mehr ändern wird, wirst du immer die Situation haben, dass jedwede Implementierung die vom GPU-Hersteller kommt, nicht optimal arbeiten kann und es immer Cornercases gibt, in denen man genau das Falsche macht.
Wenn man die Dauer eines Renderingvorganges vorhersagen könnte, wäre es das leichteste auf der Welt, einen Frame vom Treiber zum richtigen Zeitpunkt initiieren zu lassen. Der ist praktischerweise auch recht gut über die vorhandene Hardware informiert, ebenso wie seine Entwickler. Da muss sich kein Engine-Entwickler den Kopf drüber zerbrechen.
Problem ist eben nur: Man kann die Dauer nicht vorhersagen.
Nur blöd, dass der Gamedeveloper genau das machen kann
Also nicht in absoluten Zeiten, aber in Relationen. Er braucht "nur" gescheite Heuristiken und eben genug Infos darüber, was denn gerade auf der HArdware abgeht. Also z.B. wieviel clock hatte die Karte, wieviel CUs wurden wirklich verwendet, wie hoch war die Auslastung des SI, hat irgendwas anderes dazwischengefunkt, oder nicht, wie war die auslastung der FFUs usw usw. Daraus kann man sehr gute Heuristiken bauen.
Schau dir Fortran an. Warum ist es noch immer so geschätzt?
Richtig, wegen seinen sehr sehr mächtigen Bibliotheken, die eben auch selbstoptimierend sind! Das war zwar einmal richtig richtig viel Arbeit, aber danach eben nicht mehr, so lange sich nichts an der grundlegenden Architektur ändert, wie eine neue Cachestufe usw, wobei man das auch dynamisch erkennen kann. Man muss es halt "nur" parametrisieren.
Und Hardwarearchitekturen ändern sich, im Grunde nicht soo stark. Das meiste ist Implementierunsspezifisch, aber eben transparent für den Entwickler. Ob er jetzt einen oder zwei Cachestufen hat ist entscheiden, weil man mir einer keine Parametrisierung einführen muss. Ob er aber 3, 5 oder 10 hat ist völlig egal, wenn man mal parametrisiert hat.
Das erfordert aber eine gute Zusammenarbeit der Hardwarehersteller, denn man muss das über eine gemeinsame API machen, die für >10 Jahre vom Grund her ausgelegt ist. Dann lohnt der Aufwand nämlich, und die Softwarebranche wird sich dann auch über die Implementierung mitteles Middlewears kümmern. Das ist ja vor allem der Witz daran. Das sind völlig grundlegende Sachen, die realtiv wenig mit dem konkreten Problem zu tun haben. Man könnte genau wie PhysX(CPU) was aufbauen, dass die Spieleentwickler einfach nur noch nutzen. Der Knackpunkt ist halt die Kenntnis über das Gesamtsystem.
Es ist innerhalb der ATX-Specs (bis 11,4 V wäre okay), aber da viele Netzteile zum Übersteuern neigen (weil Tester das unerklärlicherweise positiv bewerten und weil man halt schlechtere Qualität verbauen kann, ohne nach unten aus dem Bereich zu fallen), könnte es bereits ein Zeichen für grenzwertige Belastung sein. Auf alle Fälle empfiehlt es sich für ambitioniertes OC nicht, an die spezifizierten ATX-Stabilitätsgrenzen zu gehen. Denn da ist Hardware ggf. ohne OC schon hart an der Grenze.[/QUOTE]
) verabschiedet 
. Ergo durchschnittlichen Chip, grottigen RAM erwischt. Elpida. Eigentlich schade, denn bei solch niedrigen Frameraten ist jeder einzelne durch Übertaktung erhaltene Frame/sec. goldwert (die höheren Taktraten haben sich durchaus bemerkbar gemacht beim Spielen.).gif "sm_=) =)")
.
