Weil ein Frame IMMER aus einem Teil CPU rechenarbeit und einem Teil GPU Rechenarbeit besteht. Die Summe beider Zeiten ist die "Frametime", welche über mehrere Frames hinweg pro Sekunde zusammengefasst angegeben wird. (FPS halt)
Von einem GPU Limit spricht man, wenn die Zeit, die die GPU benötigt, viel länger ist als die, welche die CPU benötigt (und umgekehrt für ein CPU Limit). Warum? Weil während die GPU rechnet, die CPU schon das nächste Frame berechnen kann. Kommt die GPU dann nicht hinterher, entsteht Leerlauf auf der CPU. Andersrum, wenn die CPU nicht hinterher kommt, entsteht Leerlauf auf der GPU.
Bei der CPU kommt aber erschwerend hinzu, wenn der Thread (bis DX11), der für die API-Calls zuständig ist, durch Hintergrundtasks NICHT volle Leistung aufrufen KANN, dann flacht die Skalierung ab, bzw. es brechen die Frames ein. (Beispiele sind hohe CPU Last bei CPUs mit SMT, also 50%. Oder/Und ungünstige Threadverteilung)
Man sollte allerdings nicht unterschätzen, dass hier dynamische Szenen gemessen werden. Das heist, schon das nächste Frame der (idR schon sehr kurzen) Benchszene könnte völlig andere Anforderungen haben. Damit gibt es idR immer mal ein hin und her zwischen GPU und CPU Wartezeit.
Im Unterschied zu den Anfängen der 3D Grafik/den Anfängen der avg. FPS Balkendiagramme sind heute FPS und Game-Backend weitestgehend voneinander gelöst, aber gewisse Beziehungen sind trotzdem vorhanden. Bspw. wenn es auf der Backend-Seite ZU langsam ist/wird, so dass die KI/Physik/Sound/whatever Geschichten nicht fertig sind. Denn dann wartet sowohl der CPU-Part für die API (denn der braucht Input vom Backend) als auch der GPU Part (der braucht Input von der API). Die Game-Backend Tasks sind aber weitestgehend auf MT ausgelegt. Die Grafik-API nur bedingt. Der NV-MT-Aufsatz erzeugt höheren Overhead, es fällt also mehr Arbeit an, dafür gibt es ein Stück weit MT Skalierung. Wenn ein Spiel also unter DX11 und älter auch mit einer AMD GPU über die CPU Breite halbwegs skaliert, dann kommt diese Skalierung idR NICHT von der API, sondern, weil das Backend skaliert. Was aber auch zeigt, DX12/Vulcan ist gar nicht zwangsweise notwendig für eine MT Skalierung (krasses Beispiel ist hier Crysis3 im Graslevel!). Der Fehler, der allerdings immer begannen wird -> man versucht MT-Skalierung über die CPU Breite nach OBEN zu ermitteln. Das Problem ist aber, der API-Part skaliert nicht endlos... Ab einem gewissen Punkt ist idR. schluss. -> wenn die CPU schnell/breit genug ist, um das C3 Graslevel zu stemmen, dann skaliert das auch nicht mehr! Das wird erst DX12/Vulcan wohl ändern. Das heist aber auch, ein Spiel, was heute am Markt ist, wird kaum bis gar nicht deutlich über 4-8 Threads skalieren können, es sei denn, es ist Vulcan/DX12 (denn wenn das API-Limit einsetzt, dann kann der Spaß noch so gut auf MT aufgebaut sein. Mehr Zeichenaufrufe sind irgendwann einfach nicht drin.) oder das Backend ist extrem breit und hochanfordernd (weit über dem aktuellem Marktschnitt von 2-4C Prozessoren).
Um so älter also das Spiel, desto höher die Warscheinlichkeit ins API-Limit zu rennen, weil die CPUs idR schnell genug sind, den Backend Stuff zu bewältigen, die API aber obenraus nur mit pro Thread Performance wirklich zieht...
Ehrlich gesagt sollte man so langsam mal anfangen, den Spaß zu trennen. Ein Grafik-API Limit (DrawCall Limit) ist was anderes als ein Limit durch das Spielebackend, KI, Physik (abseits von GPU-PhysX) usw. usf.
Leider halten die meisten Redaktionen das nichtmal auseinander mit deren "Belegen" man hier umsich schmeißt, obwohl es eigentlich getrennt gehört... Denn ein API Limit wirkt sich völlig anders aus als ein Spiele-Backend Limit. Es ensteht ein anderes Bild bei der Skalierung über IPC/Takt/Kerne und über verschiedene GPUs. Irgendwie wird aber immer alles in einen Topf geschmissen und alle wundern sich
So sieht man bspw. dass heute ein Phenom II X6 gern auch mal alt ausschaut, weil völlig ins API Limit laufend oder auch die Bulldozer FXen, obwohl eine gewisse CPU Breite aber vorhanden ist und auch gewissen Backend-Stuff abfedern kann. Das gleiche gilt auch für andere, pro Thread-leistungsschwache Konstellationen mit viel CPU Breite (und damit immernoch brauchbarer MT Performance) -> wie ältere Dual/Multi-CPU Maschinen.
Warum ist auch letzteres wichtig zu verstehen? Solange man weiterhin DX11 und älter einsetzt wird es zwar eine gewisse CPU-MT Skalierung in aktuellen Titeln geben. (das ist ja das, worauf man hier im Thread ein Stück weit abzielt -> Zukunftssicherheit Ryzen 8C) Aber da die pro Takt Performance stagniert seit geraumer Zeit, wird es in Zukunft dann auch nicht (viel) schneller als heute gehen... Ergo Messungen mit einer Skalierung nach OBEN sind eigentlich kappes, weil dann sehr schnell am Ende. -> falsches Bild entsteht, nämlich keine Skalierung. Auf der anderen Seite -> dann später neuere CPUs mit mehr pro Thread Performance werden wohl wieder in den Titeln die Nase vorn haben, als breite CPUs älterer Bauart, weil pro Thread einfach wieder der Bumms fehlt.
Aber macht mal. Diskusionen über technische Details sind idR ja nicht gewünscht...
