Ne @fdsinne das siehst du zu eindimensional. Ja am besten optimieren lassen sich bekannte Abläufe das ist klar, allerdings gerade Grafikkarten brauchen extrem vorbereitetenden Content damit sie schneller sind.
Gerade für das Problem welches du beschreibst wären die Hersteller der Engines zuständig: ID Software, Dice, usw also Frostbite Engine oder Id Tech 5 und so weiter. Das sind die Hersteller die Multithreaded umsetzen müssten.
Da ist zb Dice relativ weit, Frostbite kann bis zu 6 Kerne in Anspruch nehmen und läuft mit weniger als 4 Kernen auch relativ bescheiden.
Marketing ftw
Laut marketingfolien unterstützt die Engine von BF3 bis zu 12 oder sogar mehr Cores. Aber das bringt Null komma überhaupt nichts... Wenn die Sachen sequentiel aufeinander aufbauen.
Und genau das ist in Spielen schlicht sogut wie immer der Fall, den der Dreh und Angelpunkt bleibt der Spieler, der die Eingabe macht, alles baut auf die Eingabe auf. Nichts kann unabhängig der Eingabe berechnet werden. Somit hängt alles in einer sequenziellen Kette von der Eingabe ab.
Und ich sagte bereits was die Hersteller der Engines tun, um mehr Cores zu belastet. Sie optimieren nicht, sondern packen mehr Belastung nebenbei dran. Das sind Beispielsweise KI Berechnungen, das sind Physikberechnungen usw.
Stell es dir bildlich vor. Das Spiel beginnt und zeigt Bild 1. Du hast genau ein Stück Soundberechnung vorzunehmen, du hast ein Stück KI Berechnung vorzunehmen, du hast ein Stück Physikberechnung vorzunehmen usw.
Sagen wir nun, Sound und KI benötigen jeweils exakt 5 Milisekunden. Die Physikberechnung sagen wir benötigt 20 Milisekunden (weil sehr komplex)
Nur ist das Problem nun, der Thread der Soundberechnung sowie der KI Berechnung ist nach in Summe 5ms fertig, die Physik braucht aber 20. Somit warten die anderen beiden Threads auf ein Stückchen Teilberechnungen. Erst nach 20ms kann Sound, KI sowie Physik zusammen genommen werden und man kann aufbauend auf diesem Ergebnis das Bild zusammen setzen. Denn erst wenn die Kiste weis, was die Spieler macht, weil die Kiste auch, was auf dem Monitor zu sehen sein wird. Also werden diese beispielhaften Berechnungen sequenziel nach Eingabe bearbeitet.
Man sieht wunderschön, wenn nicht alles gleich schnell geht (und das geht es schlicht nicht) wartet die Kiste auf sich selbst... An der Stelle hat der Hersteller nahezu gar keinen Einfluss. Er kann die Berechnung nun entschlacken und somit optimieren, mit dem Nachteil, weniger Effekte. Er kann mehr Berechnungen dran packen um die Leerlauflücken zu füllen usw.
Am Grundproblem ändert sich aber gar nix.
Das beste und effizienteste Ergebnis erzielt man schlicht, wenn jegliche Teilarbeit immer exakt gleich lange braucht. Und das lässt sich in Games aber sogut wie nie erreichen. Im Bildhaften Beispiel besteht beispielsweise ein riesiger Unterschied zwischen der Wartezeit auf den Physikeffekte Thread wenn sich auf dem Bild nichts bewegt wie zum Beispiel, wenn eine Explosion zu sehen ist, wo Partikel durch die gegend fliegen.
Bei strikt statischem Content kann man das übrigens auch beobachten. Beispiel Cinebench. Bei sagen wir 8 Threads kann man schön erkennen, wie manche Threads schneller abgearbeitet werden als andere. Nur wird das Gesamtbild eben soweit zerhackt und kann zeitunabhängig bearbeitet werden, das am Ende dort kein signifikanter Nachteil entsteht.
Und wie ich schon sagte, das ist nur ein Teil der Wahrheit. Ein zweiter Teil sitzt bildlich gesehen erst nach der reinen Spieleberechnung.