News 3DMark für Mantle: DirectX 12 und Mantle sollen gleich schnell sein

Nun das Treibertrimmen muss aber von Hand für jedes Spiel extra gemacht werden. Nvidia hat jetzt hier nicht einfach einen Schalter umgelegt, dass muss für die Spiele und Benches extra angepasst werden und ja das macht Nvidia bisher recht gut. Ist halt aufwendig.
 
@smilefaker

Ich bezog mich insbesondere auf Starswarms und alle Anwendungen mit Mantle-Umsetzung.
AMD wird hier keine Resourcen in die DX11-Optimierung des Treibers verschwenden, weil sie keinen Vorteil dadurch haben (ganz im Gegenteil: man würde ja den Mantle-Vorteil ad absurdum führen, wenn man zeigt, dass man mit DX11 genauso schnell sein kann). Nvidia bleibt da natürlich nichts anderes übrig als diese Optimierung durchzuführen.
 
Gibts von Mantles Veröffentlichung schon etwas neues?
Ich würde gerne mal die Specs durchlesen, aber AMD hinkt obwohl es von vielen als Open-Source-Heiland gesehen wird seinem Versprechen schon nem Monat hinterher.
 
kisser schrieb:
Zwei Dinge kann man aus dem Test herauslesen:
1. Nvidia hat die DX11 Treiber auf hohe Draw-Call Last getrimmt, AMD nicht (das ist beides ja schon länger bekannt)
2. DX12 und Mantle performen ungefähr gleich

Beides falsch. Siehe Update bei Anand:
http://www.anandtech.com/show/8962/the-directx-12-performance-preview-amd-nvidia-star-swarm/6
Update: Oxide Games has emailed us this evening with a bit more detail about what's going on under the hood, and why Mantle batch submission times are higher. When working with large numbers of very small batches, Star Swarm is capable of throwing enough work at the GPU such that the GPU's command processor becomes the bottleneck. For this reason the Mantle path includes an optimization routine for small batches (OptimizeSmallBatch=1), which trades GPU power for CPU power, doing a second pass on the batches in the CPU to combine some of them before submitting them to the GPU. This bypasses the command processor bottleneck, but it increases the amount of work the CPU needs to do (though note that in AMD's case, it's still several times faster than DX11).

This feature is enabled by default in our build, and by combining those small batches this is the likely reason that the Mantle path holds a slight performance edge over the DX12 path on our AMD cards. The tradeoff is that in a 2 core configuration, the extra CPU workload from the optimization pass is just enough to cause Star Swarm to start bottlenecking at the CPU again. For the time being this is a user-adjustable feature in Star Swarm, and Oxide notes that in any shipping game the small batch feature would likely be turned off by default on slower CPUs.
Somit sind die Benchmarks wertlos da falsch eingestellt. Die vorhandenen 2 Core Optimierung ist hier wohl auch ein Vorteil für Mantle. Vor allem da als Option vom User auswählbar.

71461.png
 
Zuletzt bearbeitet:
Mantle hat eine zusätzliche Optimierung eingeschaltet, welche durch Mehrarbeit der CPU die GPU Leistung erhöht. Daher hat ist Mantle auch leicht schneller als DX12. Im Falle des 2-Kern Prozessors ist das aber zu viel Arbeit für die CPU, welche daraufhin den Flaschenhals darstellt. Kann man aber ausschalten.

Mantle und DX12 sind sich sehr sehr ähnlich. Ich frag mich ob bis auf die Offenheit und Platformunabhängigkeit noch ein Vorteil für Mantle bleibt. Ich weiß nicht ob DX12 auch Split-Frame-Rendering unterstützt was ja der heilige Gral der Crossfire/SLI Technik ist.
 
Dieser Benchmark hat nur leider nichts mit der Spiel Realität zu tun. Ihr könnt froh sein,wenn ein Spiel später 10% schneller läuft. :o
 
Geil ist, wie AMD weiter Craptle als "offene" API verkaufen will. Das ist schon an Lächerlichkeit nicht mehr zu überbieten:

"Wir sind gegen Vendor-Lockin... Außer wir machen das. :evillol:"
 
Wollte AMD nicht das SDK frei geben und haben es nicht schon? Ich bin da nicht auf dem aktuellsten Stand.
AMD Mantle hat Microsoft mit Directx12 allerdings unter Druck gesetzt, ich finde es daher seltsam immer dagegen zu schießen und sich drüber lustig zu machen.
 
März ist aktuelles Datum laut dem Blogpost. Also 3 Monate später als eigentlich angekündigt . . .

"Wir sind gegen Vendor-Lockin... Außer wir machen das. "

Sehe ich genauso bei einem solchen "Uboot" :)
 
Sontin schrieb:
"Wir sind gegen Vendor-Lockin... Außer wir machen das. :evillol:"

33apu13_dice.png

@smilefaker: Mantle sollte noch 2014 offen für alle sein. Das wurde jedoch verschoben, da Mantle sich noch in einer "Beta-Phase" befand.
 
Zuletzt bearbeitet:
Sontin schrieb:
Geil ist, wie AMD weiter Craptle als "offene" API verkaufen will. Das ist schon an Lächerlichkeit nicht mehr zu überbieten:

"Wir sind gegen Vendor-Lockin... Außer wir machen das. :evillol:"

In Vulkan steckt wohl viel von mantle. Und ist Vulkan offen?
 
@OiOlli

Ich denke mal sobald alles fertig ist wird es offen sein.
 
Vulkan ist schon offen. Alle Khronos-Mitglieder haben da vollen Zugriff darauf und haben auch schon Änderungen und Verbesserungen eingebracht. Alles was die Khronos von Mantle übernehmen wollte durften sie in vollem Umfang übernehmen und was AMD spezifisch war durften sie weglassen. Das hat AMD angekündigt und auch erfüllt. Warum muss AMD eine API unter dem Namen Mantle selber weiter pflegen um sein Wort zu halten? Somit ist Mantle offener geworden als es jemals anders sein konnte - man kann sogar alles ändern was man ändern will.
 
Zuletzt bearbeitet:
http://forums.anandtech.com/showthread.php?t=2422223

War ja Heute Nacht unter anderem Thema bei MS - (wo doch so einiges Cherry Picked wurde, die PDF auf alle Fälle dazu lesen, wieso.) - Im Stream.

Screen: http://s29.postimg.org/hsmlfnv7b/rbt.jpg
und die PDF: https://intel.lanyonevents.com/sf14...96E33739827241E4DD51A76/SF14_GVCS005_101f.pdf
Ab Seite 39


But if you want more technical detail, than here is it:
NV Fermi: Max UAV is limited to 8 -> TIER1
NV Kepler: Max UAV is limited to 8 -> TIER1
NV Maxwellv1: Max UAV is limited to 8 -> TIER1
NV Maxwellv2: SRVs/stage is limited to 2^20 -> TIER2
Intel Gen7dot5/Gen8: the universal hardware binding table is limited to 255 slot -> TIER1
AMD GCN v1/v2/v3...: GCN is designed to a simplified resource model, so this architecture works more like a CPU than a GPU. This will allow unlimited resource binding -> TIER3

Wer das pdf und den Stream komplett gesehen hat, wird bei der Liste auf eine kleine Ungereimtheiten stoßen... das hat wiederum mit der Auswahl, womit dies ermittelt wurde zutun, und was das mit Cherry Pick zutun hat. Die Antwort findet dann jeder schnell heraus, wieso - denn um es genauer sagen zu können, fehlen die Dokus. die der Hersteller halt nicht raus gibt bzw. generell nicht in dieser Beziehung.


Auch vlt. für den einen oder anderen interessant, im späten Verlauf:




The GCN revs are not so different. The base 1.0 version is also good for the most D3D12 features, and for the best binding tier.
The 1.1 version is mostly brings efficiency updates, like multi queue compute with upgraded ACEs. Also device unified addressing is a huge deal, because it will allow the kernel to view the LDS and the device memory as a single addressable space.
The 1.2 version ISA manual is under NDA, so I can't talk about what possible with Tonga. This GPU has some very interesting unannounced capabilities focused to reduce latency (good for VR)

Auf die Frage ^^:
Could you please elaborate?? I didn't think GCN v1.0 or even v.1.1 could support ALL features in DX12 with hardware-only (no emulation!!!). Are you saying even GCN v1.0 supports ALL features in DX12 with hardware-only, no need for emulation?


Und bzgl. der ( good for VR ) im Zusammenhang mit den ACEs ( Siehe GCN pdf s.6 & 40) fehlt von CB halt leider die News zu Liquid VR - also hier weiter lesen, wem es interessiert.
 
Zuletzt bearbeitet:
Danke für die Zusammenfassung BlauX. Hier könnte es mit dem Release der Fiji-GPU einen großen Knall geben denke ich, wo die einzelnen Defizite sich für Nvidia als ein deutlicher technologischer Rückstand erweisen könnten.
 
Zurück
Oben