Und es stimmt: Es gibt sehr wohl Geschwindigkeitsverbesserungen in DirectX. Es gibt ja auch Spiele, die nen neueres DirectX nutzen, nur weil es bessere Performance bringt und nicht unbedingt der neuen Effekte wegen. Es macht z.B. schon nen Unterschied, ob ein Shader 500 Instruktionen benötigt oder nur 10.
Es ist halt eher die Ausnahme denn die Regel, sowas auch in Games anzutreffen.
Bestes Beispiel ist doch Tesselation. -> den Effekt selbst könnte man auch mit DX9 oder 10 umsetzen, nur wäre der Aufwand derart hoch, das es wohl gar nicht lauffähig wäre. Zumal reine DX9 oder 10 Hardware (die kein DX11 kann) dann viel zu schwach wäre, diesen Effekt auch darzustellen. -> in der Öffentlichkeit wird dann der Effekt als DX11 "Feature" verkauft, obwohl es im Grunde eigentlich gar nix neues ist, sondern nur der Aufwand selbst derart gesunken ist, das einen solchen Effekt nun eine Grafikkarte stemmen kann.
Das gleiche gilt an der Stelle auch mit Mantle. Da wir aber aktuell nur ein einziges Game sowie ne mehr oder weniger Techdemo haben, sehen wir auch (noch) keine verbesserten Effekte. Das könnte sich aber mit der Implementation in weiteren Titeln und der weiteren Verbreitung ändern. Und genau dann verpufft auch das Leistungsplus zugunsten von Optik. -> die Frage bleibt nur, wie hoch fällt das Leistungsplus aus, und wie stark schöpft der Entwickler dann dieses Leistungspotential aus um mehr Optik zu generieren. Bspw. 50 FPS durch Mantle gewonnen, aber 60 FPS in Optik investiert heist unterm Strich weniger Performance bei gehobener Optik. Wenn die Optik dann aber nur unwesentlich zur Geltung kommt bleibt am Ende der Gedanke hängen, das es ja doch nix bringt. -> was man häufig den DX10.x Versionen zuschreibt/zuschrieb
Auch wenn das jetzt arg theoretisch ist: Wäre das in diesem konkreten Fall zwingend nötig? Also ich meine die Beseitigung des CPU-Overheads, bei vielen anderen Sachen müsste man das wahrscheinlich vorher spezifizieren. Aber genau diese "Problematik" scheint ja relativ GPU-unabhängig lösbar zu sein.
Neja kommt wohl drauf an, wo sich dort genau Leistung rausholen lässt... Das Problem ist ja doch, die Spezifikationen für DX11 sind fix. -> ändert man daran nun irgendwas und nennt es DX12, muss das nicht zwingend auch gleichsam auch auf jeglicher DX11 Hardware so tuckern. Könnte, muss aber nicht... Die Frage ist, was muss man drehen!?
Mit Mantle geht man den Weg, ein paar Ebenen niedriger anzusetzen und mehr direkt die GPU zu bedienen. Was durchaus wohl auch Leistung bringt, keine Frage... Nur wenn eine DX11 Hardware es nicht zulässt, weil nicht spezifiziert, das man diese in einer tieferen Ebene anspricht, dann wird das auch nicht laufen
Denn genau solche Zusammenhänge sind ja in den DX Spezifikationen auch definiert.
Da aber AMD mit Mantle auf ihre eigene Hardware hin aufsetzt, können diese eben genau diese Zusammenhänge selbst definieren. Also dort, wo MS sagt, mach es so und so rum, kann AMD mit Mantle ganz anders rangehen, weil man sowohl die API baut und auch mit dem GPU Treiber der API die Möglichkeiten dazu bietet.
Ein Microsoft mit einem aufgebohrten DX hingegen hat die Hardware nicht... Sie sagen, so wird/muss es laufen, das und das geht usw. usf. -> dann kommen die GPU Hersteller und bauen ihre Hardware bzw. ihre Treiber den Bedürfnissen der Spezifikationen nach genau dort hin/dran.
Was aber halt aktuell ungeklärt zu sein scheint, wo holt Mantle die Performance überhaupt her? Da gibts nix greifbares aktuell. Wenn die CPU Leistung um über 100% steigt zwischen den Werten, aber sowohl DX als auch Mantle nur unwesentlich im einstelligen Prozentbereich zulegen, Mantle aber dennoch einen größeren Vorsprung vor DX hat, kann es nicht an der CPU liegen. Sondern es muss irgendwo anders her kommen. -> beispielsweise an irgendwelchen starren Konstrukten in der Berechnungsweise, die nicht nach oben hin skaliert, sondern ab einem gewissen Punkt deckelt.
Und hier denke ich, das Mantle nicht nur Performance durch weniger CPU overhead erzeugt, sondern auch einfach gewisse Effekte und Berechnungen (analog zu DX Versionssprüngen) wohl teilweise einfach mal effizienter umsetzbar sind.
Nur gibts dafür aktuell absolut keine Nachweise geschweige denn irgendwas greifbares und nachvollziehbares. Auch wird viel zu viel an den Werten vermischt. Bspw. lese ich äußerst selten von Analysen zur Takt/Core/IPC-Skalierung, was den reinen Grafikkartentreiber angeht. PCGH hatte da mal Messungen parat (aber schon was älter) -> wo eben ein Dualcore (selbst mit SMT) pauschal schon einiges an Performance liegen ließ gegenüber nen Quadcore oder nem Hexacore. (selbst bei einem Game, was nachweislich nicht über die Cores skaliert) Kann man derartiges aber bspw. mit Mantle außen vor lassen, weil es einfach weniger stark von der CPU Technik abhängt, ist Mantle freilich stark schneller und profitiert auch deutlich mehr von kleineren (weniger breiten) CPUs. Böse Zungen würden nun aber behaupten, das liegt nicht primär an Mantle, sondern eher daran, das der DX Part durch die weniger starke CPU einfach mal Boden verliert. Warum und Wieso ist aber ebenso ungewiss...
Beispiele dafür findet man hin und wieder zwischen den Zeilen:
AMDs Kaveri im Dual-Graphics-Test
In Skyrim gewinnt hier der breitere Kaveri mit einer 250er deutlich Performance gegenüber dem X2 und dem i3. Mit der 260er gewinnt der i3 und Kaveri deutlich Boden gegenüber dem X2. Wärend mit der HD7750 keiner der drei CPUs nach oben stark streut. Interessant dabei ist, das die HD7750 irgendwo mittig zwischen der 250 und der 260 steht, was die Performance angeht. -> mit der Theorie, mehr GPU Power benötigt mehr CPU Power lässt sich das Ergebnis da also nicht erklären
Mir ging es auch nur darum, dass es ja möglich wäre, dass es wirklich rein Softwareseitig gelöst wird und das könnte halt unter dem DX12-Banner laufen ohne, dass die Hersteller ihre GPUs anpassen müssen. Ist natürlich auch möglich, dass es notwendig wäre. Aber da kommen wir wieder zu von dir schon ausgeführten Frage wo kommt die Leistung her. Ich finde es etwas schade, dass es dazu keine vernünftigen umfangreichen Tests gibt, irgendwas fehlt immer...
