Unterscheide mal zwischen GPU und CPU Limit, das ist scheinbar dein Problem oder das Problem warum wir aneinander Vorbeireden.
Nein, weil es in der Detailbetrachtung viel zu oberflächlich wäre, dies zu tun. Es geht nach wie vor um den Umstand, woher Mantle die Leistung holt. Auch wenn du mittlerweile schon wieder abgekehrt bist und auf einmal Sachen wie "unter anderem dass AMD ihre Treiberarbeit mehr auf Mantle konzentiert hat" als normal angesehen werden. Damit sprichst du direkt die Fähigkeit ab, das Mantle überhaupt schneller sein kann. Denn unter diesem Gesichstspunkt lassen sich Vergleiche von Umsetzungen aufbauend auf eine Schnittstelle nicht ziehen, da eben unter völlig verschiedenen Bedingungen. Du wirst dich sicher nicht mehr dran erinnern, aber das Thema "fehlende Optimierung" hatten wir vor einiger Zeit schonmal... Da galt sowas noch als äußerst problematisch, wenn man es vorsichtig zusammen fasst. Stichwort war seinerzeit NV Gameworks... Nur so nebenbei
Das "Overheadverhalten" habe ich gar nicht gemeint, sondern ausschließlich CPU Overhead, also die Leistungsbremse des Systems im CPU Limit die Mantle behebt.
Nvidia kann diese nicht beheben, das zeigen sie selbst in ihren Skalierungsbenchmarks. Ansonsten hätten die die Balken bei AMD lang gemacht und bei NV kurz.
Was sie beheben können ist der Treiberoverhead ihrer GPU oder die Zusammenarbeit der CPU mit der GPU wenn es kein CPU Limit gibt, siehe das Skalierungsproblem bei NV mit 2 Kernen oder weniger.
Mantle können sie damit nicht schlagen, Mantle entlastet die CPU, das kann Nvidia nicht, zumindest nicht, wenn die CPU limitiert.
Siehst du, hier ist wieder der Punkt, wo dir einfach mal das Wissen im Bereich Programmierung fehlt. Dennoch tätigst du Aussagen und stellst Fakten in den Raum.
Es gibt im Grunde kein generelles CPU Limit wie du es hier gern hättest. Das CPU Limit kann von XX verschiedenen Sachen kommen.
- Wenn ein Spiel beispielsweise durch die KI Berechnung ins "CPU Limit" läuft, nämlich weil die KI Berechnung derart komplex ist, das die CPU zu langsam ist und somit deckelt ist das ein CPU Limit.
- Wenn ein Spiel durch Physikberechnungen derart bedeckelt wird, weil die CPU zu langsam ist, ist es ein anderes CPU Limit.
- Wenn beispielsweise die von AMD mit Mantle genannten "draw calls" nicht schnell genug getätigt werden, ist es wieder was anderes, dennoch limitiert die CPU.
- genau so wie wenn die Treiberoptimierungen auf breite CPUs setzen, die CPU aber nicht breit genug ist und somit Leistung liegen gelassen wird, ist das ein CPU Limit.
Beispiele hierfür kann man noch und nöcher bringen... Es sind grundverschiedene Sachen, die eben nicht mit den gleichen Mitteln bekämpft werden können.
Beispielsweise kann Mantle weder KI noch Physikberechnungen beschleunigen, ebenso wird kein Treiber durch Mantle grundlegend schneller. Wärend die draw call Problematik durch Mantle angegangen wird.
Auch hat bspw. der Hersteller der GPU keinen direkten Einfluss auf die KI oder Physikberechnung (GPU PhysX außen vor), kann aber beim Treiber ansetzen und bei den draw calls ebenso...
Was die Balkenlänge angeht. NV kann nur mit Werten von DX unter AMD vergleichen. Es gibt Mantle nicht frei zugänglich. Lange Balken in Rot auf der NV Folie hätte man mit Mantle. Aber ohne frei zugängliches Mantle keine langen Balken.
Also Nvidia und AMD haben gar keinen Einfluss auf Directx11, die können lediglich das Zeug nehmen was Microsoft programmiert hat und ihre Treiber und Hardware darauf einstellen, das ist auch der Grund warum Nvidia nur das tun kann. Und das heißt nicht, dass sie mehr FPS im CPU Limit bekommen werden, sieh das mal ein.
Wie soll ich etwas einsehen, was nicht stimmt? Und vor allem, wo wir doch eigentlich über den Punkt hinaus sind, das NV und AMD eben doch Einluss auf die DX Leistung haben, es geht schließlich immernoch um Umsetzungen. Auch macht es den Eindruck, als denkst du, das DX selbst irgendwie eine Software ist, die Last erzeugt... Das ist nicht der Fall. DX und auch Mantle sind eher Schnittstellen, bzw. auch Bibliotheken, woraus man sich bedienen kann. Die Last wird aber quasi ausschließlich im Kontext der Anwendung und des Treibers erzeugt...
Du musst dir das Leistungsverhalten sinnbildlich in etwa wie beim Inputlag vorstellen. Dort summiert sich das vom Eingabegerät über die PC Hardware (CPU, GPU usw.) über die Kabelverbindungen bis zum Monitor nebst dessem Verarbeitungsspeed und der Ausgabegeschwindigkeit. Es gibt also eine Kette von Objekten, die maßgeblich an der Leistungsfähigkeit beteiligt sind. Du kannst vorn optimieren und es wird in Summe schneller, ebenso aber auch hinten, oder auch überall. In Summe wird es schneller. Und das ist der Punkt. Mit Mantle gibts nun eine zweite Kette (Mit OpenGL eine dritte), deren einzelne Glieder die Leistungsfähigkeiten anders wichten.
Dennoch ist der Weg, den die Berechnung nimmt im Prozess, wie oben skizziert, identisch. Was anders ist, ist die Zeit, die benötigt wird, bis man von ganz vorn nach ganz hinten gewandert ist.
Nimmt man jetzt als Beispiel mal wieder die draw calls, so kann eine Umsetzung mit Mantle sagen wir 50.000 Cubes zeichnen. Eine Umsetzung mit DX hingegen vielleicht 20.000 Cubes. Kommt nun NV und sagt, wir haben was gefunden, was die Abarbeitungsgeschwindigkeit der draw calls signifikant steigert, kommen womöglich dann 40.000 Cubes mit dem neuen Treiber bei rum.
Hast du jetzt ne Anwendung, die 30.000 Cubes zeichnet bei 60 FPS und definierter Auflösung, wäre die erste DX Umsetzung vor dem Treiberupdate klar CPU limitiert und würde nur um die 40 FPS schaffen, nach dem Treiberupdate hingegen fällt das Limit weg und es stehen ebenso 60 FPS auf der Uhr. Man hat also DX dahingehend stark im Speed gesteigert und diesen Part als CPU Limit beseitigt.
Wie oben schon erwähnt, die Werte von der NV Folie sollten für jederman nachvollziehbar sein, da es sowohl den R331 als auch den R334 schon gibt. Stimmt das in etwa, liegt die Vermutung nahe, das NV mit dem neuen Treiber dort nach eben der Folie zulegen wird.
In dem speziellen Fall dürfte das nur sehr ermüdend sein, du bist am Ende sowieso wieder der Nvidia-Anti-AMD-Moderator für ihn...
