Sollte man die nutzen oder muss man das? Gesunder Menschenverstand sagt mir zumindest, dass unabhängig davon, ob das irgendwo in alle Nuancen niedergeschrieben steht oder nicht, man sich u.U. in bestimmten Grenzen bewegen sollte.
Vielleicht sollten sich Programmierer auch einfach mal hinterfragen, warum ihr Spiel im Menü die GPU an die TDP-Grenze bringt. Muss das denn sein? Ist das irgendwie sinnvoll?
Nochmal ne klare Ansage:
Ich als Entwickler habe darauf NULL Einfluss. Keinen. Gar keinen. Absolut null.
Ich kann die Bilder einfügen. Die Assets adden, die Settings in der Engine einstellen.... das war es.
Wie die GPU das verarbeitet, kann ich als Entwickler nicht steuern. Nicht im Geringsten. GAR NICHT. Ob sie da 100 Watt nimmt, oder 500 Watt,... kann ich nicht mal abschätzen, geschweige den beeinflussen.
Zumal jede GPU / Generation / Hersteller, dass auch noch anders regelt. Auf ihre Art halt.
Soweit nun klar?
Engines lassen aktuell deutlich mehr zu, als moderne GPUs packen.
Lasse ich in Unreal alle Settings on, macht ne 3090 noch so 10-30 Frames die Minute. MINUTE nicht Sekunde.
Also ist so richtig Spielraum nach Oben, was die Settings angeht. Ich kann da also nicht "sparsamer" umgehen und damit irgendwas Tolles erreichen. Das IST bereits sparsam.
Alles, was die GPU macht, ist für den Entwickler komplett außen vor. Er hat einfach keinen Einfluss darauf.
Und er sollte auch keinen Einfluss darauf haben, weil er kein Ingenieur ist! Darum ist es ja eine Blackbox.
Wenn New World das einzige Spiel ist, bei dem das passiert,... dann liegt das NICHT an den Entwicklern von New World, sondern an:
A: Der API, die irgendwas zulässt, dass nicht zugelassen werden sollte (unwahrscheinlich, weil dann ja B oder C trotzdem noch zutreffen müssten)
B: Grafiktreibern, die irgendwas falsch berechnen und der GPU falsche Anweisungen geben, die irgendwie die Sicherheitsmechanismen deaktivieren oder umgehen (möglich)
C: Ein Hardwaredefekt / fehlender Begrenzer von "irgendwas", der aufgrund der speziellen Last aber nötig wäre und so zu einem Defekt führt. (sehr wahrscheinlich)
Hardware, die sich selber killt mit ihrer Arbeit, hat schlicht einen fehlenden Begrenzer für was auch immer das Problem auslöst.
Zwei Beispiele für die Bilderliebhaber:
* Wir hatten das Thema Auto,... schon mal probiert im ersten Gang 200 zu fahren? Geht nicht? Wieso? Weil die Drehzahl begrenzt. Man kommt, je nach Motor, auf 90, evtl. 100.... bei den meisten aber eher 30-50. Und dann geht das Auto nicht kaputt, sondern es verhindert den Schaden.
* Wie viel Einfluss hat man als Kunde einer Pizzeria auf das Ergebnis? Viel! Man sagt, was man haben möchte. Das kommt dann normalerweise auch an. Aber WIE diese Pizza gebacken wird, beeinflusst der Kunde nicht. Das passiert in einer Blackbox, der Küche. Man sagt dem Kellner (API) was man will (Bild) und bekommt das Ergebnis (Bild x Frames) in der Küche (Blackbox mit GPU) gebacken, ohne dass man weiß wie, was, warum.
Natürlich kann man dem Kellner (API) sagen, dass man möchte, dass der Koch (Blackbox) dabei nen Handstand macht. Aber ob der Kellner (API) so was überhaupt annimmt UND an den Koch (Blackbox) überhaupt weitergibt, ist unwahrscheinlich. Eine API kann optionale Parameter nehmen, muss das aber nicht. Diese optionalen Parameter führen aber nicht zu defekten, weil nur garantiert machbare Dinge von der API akzeptiert werden. Der Kellner kann also den Sonderwunsch "bitte etwas mehr Käse" annehmen, aber ob der Koch das macht, entscheidet der Koch, wenn er sich das zutraut.
Also TLDR:
Ein Software-Entwickler KANN da nichts falsch / richtig / besser machen.
Wenn die API mehr erlaubt, als die Hardware aushält, dann ist die API daran schuld, nicht der Entwickler.
Wenn die Hardware mehr Last annimmt, als sie selber aushält, dann ist die Hardware daran schuld, nicht der Entwickler.
Wenn der Treiber Hardwarelimits umgeht, dann ist der Treiber schuld, nicht der Entwickler.
Der Entwickler kann diese drei Stellen nicht beeinflussen, hat keine Einsicht und hat auch null Chance, da auf dem Laufenden zu bleiben, WENN es überhaupt gehen würde.