Hi,
Kannst du mir mal spezifisch sagen, was genau du meinst? Mir ist natürlich klar, dass beispielsweise ein hoher Polygoncount nicht gleichzeitig auch eine hohe Anzahl Drawcalls bedeutet, sonst wären wir ja wahrscheinlich schon längst alle in Drawcalls ersoffen
Wenn du das auf den abgebildeten Schutthaufen beziehst, ich wollte nicht, dass man da einen Bezug von Polycount auf Drawcalls herstellt, so wollte ich das nicht verstanden haben - aber das habe ich vielleicht nicht gut genug formuliert. Mir ist eben an ein paar anderen Stellen aufgefallen, dass bei solchen Gebilden häufig auch ein hoher Drawcall-Count vorliegt, das war einfach nur eine Feststellung.
Beim Culling hingegen sehen ich kaum eine andere Erklärung, als dass dieses offenbar massiv mit der Anzahl Drawcalls zusammenhängt. Ich lass mir da aber gern auf die Sprünge helfen
Mir ist auch bewusst, dass es bezogen auf den API-Overhead eher unerheblich ist, was die Drawcalls eigentlich bewirken. Aber offenbar ist das ganze bei Fallout 4 nicht sonderlich geschickt gemacht - Wenn ich mir die Szenen so ansehe, muss ich davon ausgehen, dass die dafü+r nötigen Renderanweisungen alles andere als geschickt gebündelt werden. Ich wage mal zu behaupten, in einer anderen Engine würde man für eine ähnliche Szene weitaus weniger Drawcalls benötigen. Vielleicht wäre das auch mit der Creation Engine möglich, falls dem so wäre, hat das Bethesda aber offenbar nicht hinbekommen oder für nicht erheblich eingestuft. Das kann ich aber nicht beurteilen, dafür fehlt mir die nötige Einsicht und/oder Ahnung.
Wie gesagt, ich lass mich gern belehren, falls sich dazu jemand im Stande hielte.
.gif "sm_=) =)")
EDIT: Btw, die Szene ist, wie ihr schon richtig erahnt habt, kein Worst Case. Meine Steam-Cloud wollte mir gestern aus irgendeinem Grund nicht meine daheim erstellten Saves herunterladen, da hatte ich ein paar noch deutlich heftigere Szenarien. Aber die hier ist schon mal ganz gut, vor allem lässt sie sich reproduzierbar ablaufen und so für Benchmarks nutzen, das klappt leider nicht so einfach mit jeder stark limitierenden Szene.
Gruß,
Phil
Gerne würde ich dir in 3 Zeilen die Holy Grail Antwort geben, aber wie du sicher weißt ist die Materie ein verdammt harter Knochen...
Sollte im Übrigen keine Kritik darstellen und Hut ab vor der journalistischen Leistung, die Charts zu erstellen
Die Poly- Drawcall Geschichte hast du ja schon selbst erwähnt. Zum Thema Culling, die Arbeitsweie stimmt so weit auch, wie dus erklärt hast.
Man muss/kann aber schaun wo diese Optimierung beginnt.
Die gesamten Informationen, die in den Framebuffer geschrieben werden, konkret( vereinfacht
) die Objekte( Position der Vertices, Textur- , Farbkoordinaten, ...) werden in einem Szenengraphen abgelegt. Hier kann man vorberechnen ob bei Objekten in der Tiefe( abhängig vom ViewFrustum) eine Verdeckung besteht. In diesem Fall wird der Zeichenbefehl vom verdeckten Knotenpunkt nicht an die GPU (Graphic Pipeline
) übergeben.
Was an Objekten übergeben wurde, wird für den weiteren Gebrauch vorerst im VRam gecached. Stichwort Speicherverwaltung....
Kurzes Rechenbeispiel zu den Größen: Um einen Punkt in homogenen Koordinaten repräsentieren zu können braucht man einen vertex; vector<float> der länge 4.
Für ein "polygon" sind wir also schon bei einem Speicherbedarf von 4Byte. Dazu kommen noch Texturkoordinaten, Normalenposition, etc, ....
Das ganze muss nun erstmal zB. von der Festplatte zur GPU. Genau das ist der Punkt, wo normalerweise der Drawcall overhead entsteht - "wenns Datenstau auf dem Bus gibt".
Das ist zum einen ein Drawcall, oder wenn von der CPU der Befehl kommt: "Actor1 bewege dich so und so"(leider nicht so trivial...) -> mehr Animationen mehr Drawcalls....(anm.: Ragdoll Physik zB, wird (normalerweise...)auf der GPU berechnet, da schneller)
Backface Culling ist auch so ne Geschichte für sich... sobald ein fortgeschrittenres Belechtungsmodell, bzw Shadertechniken benutzt werden, kann man auch nicht einfach pauschal ne Flag auf true setzen...
... ist nicht so ganz einfach das ganze Thema... Optimierung würde Bethesda und auch vielen anderen Studios nicht schaden, dennoch sollte man sie deshalb nicht unbedingt schlecht reden, ehr andere die dies besser machen Loben. (zumindest rein aus technischer Sicht, alles andere sei dahin gestellt, u.a Entwicklungsbudget...)
Mal am Rande.. die Auflösung beeinflusst das Ganze kein Bisschen, da diese nur die Abtastrate bestimmt, bzw alles ab dem Fragment, bzw PixelShader.
Bei diesem Artikel fehlen mir persöhnlich vorallem leider die Busgeschwindigkeiten und deren Anbindung. Interessant fänd ich vorallem, wie sich die IGpus schlagen.
hoffentlich hat die Erklärung dem ein oder anderen gefallen, Korrerkturen gerne, aber alles was Tiefer geht, wird mir grad zu ausschweifend
EDIT: soll natürlich nicht verteidigen, dass die Optimierung teilweise unter aller Sau ist. Aber Bethesdas miese QA ist ja leider nichts neues
(Liegt oft bei 800-900, jedoch eben nie auf 1010 mhz) 
