AMDs Mantle zeigt in Civilisation: Beyond Earth fast perfekte Frametimes bei Multi-GPU Betrieb

[Rollora]

AMDs Mantle ist ja nun schon seit einiger Zeit draußen, einige Male konnte man schon eindrucksvoll zeigen, was es bringt, den CPU Overhead zu beseitigen.
Viel beeindruckender ist jedoch bislang immer folgendes gewesen: Beim Verbund zweier Grafikkarten oder GPUs (Crossfire) sank zwar die Durchschnittliche Framerate etwas ein, doch das Mikroruckeln war quasi völlig ausgelöscht.
Jüngstes Beispiel ist das im Titel genannte "Civilisation: Beyond Earth" (der aktuellste Treiber wird dazu benötigt: AMD Catalyst 14.9.2 Beta - Mantle-Support für Civilization: Beyond Earth ).
Hier hat Extreme Tech sich die Skalierung angesehen. Während Crossfire in Direct X bzw SLI massive Mikroruckler hat, hat Mantle eine absolut stabile Framerate und die gefühlten Frames sind somit deutlich höher:
http://www.extremetech.com/wp-content/uploads/2014/10/r9295x2.png


Extreme Tech, Anandtech und viele weitere Tech-Websites haben sich das genauer angesehen und haben, neben Temposteigerungen durch Reduzierung des CPU Overheads einen weiteren Nutzen Mantles ausgemacht.
Der, ganz nebenbei mit dem Mythos aufräumt, dass die PCIe-Verbindung oder die Verbindung zwischen zwei GPUs schneller sein muss, damit Mikroruckeln nicht mehr auftritt.

Gerade die Reduzierte CPU Last ist bei Civilisation ja eine Wohltat, hängt dieses Spiel ja doch sehr an der CPU. Die reduzierung des Overheads führt nicht nur dazu, dass die Minimalen FPS deutlich besser sind (siehe Anandtech Link), auch die Ladezeiten werden dabei reduziert.


Investigating AMD Mantle’s superb multi-GPU scaling in Civilization: Beyond Earth | ExtremeTech
AnandTech Portal | Benchmarked - Civilization: Beyond Earth

Fast perfekte Skalierung ist falsch, denn genau die gibt's mit SFR nicht. Dafür sind die Frametimes top.

Danke Marc
Für perfekte Skalierung ist der Performanceoutput etwas zu niedrig

Edit:
Unser lieber Kollege: CD LABS: Radon Project hat außerdem einige deutschsprachige Mantle-Benchmarks ausgegragen. Die sind, Computerbase-typisch, interaktiv wenn man mit der Maus "drüberfährt":

Mantle, CPU-Skalierung, DSR und 4K in Civilization: Beyond Earth - ComputerBase

 

[PCGH_Marc]

AW: AMDs Mantle zeigt in Civilisation: Beyond Earth fast perfekte Multi-GPU Skalierung

Fast perfekte Skalierung ist falsch, denn genau die gibt's mit SFR nicht. Dafür sind die Frametimes top.

EDIT
Average ist Mantle mit SFR gerade in hohen Auflösungen etwas langsamer als DX11 mit AFR, in niedrigen profitieren die Karten vom angehobenen CPU-Limit unter Mantle. Die minimale Framerate ist durchweg besser bei dem was ich gemessen habe, zudem top Frametime - sprich keine Mikroruckler und zudem geringerer Lag. Das ganze optimiert mit mehr Skalierung? Schick!

 

[CD LABS: Radon Project]

Kommt es nur mir so vor oder zeigen bisher alle Civ: BE-Benches hauptsächlich, dass die allgemeine DirectX Performance eher weniger berauschend ist?
Klar, die Benches auf ComputerBase und Co zeigen alles andere als BestCase---aber bei der Optik hätte man doch eher 60+ FPS in 1080P auf ner Karte wie ner 750TI erwarten können, oder?
Mantle, CPU-Skalierung, DSR und 4K in Civilization: Beyond Earth - ComputerBase
Edit: Ok, gerade das Video angeguckt, da wird wirklich schon einiges auf dem Bildschirm gezeigt! Ändert aber nichts daran, dass ich es als optisch ziemlich mau empfinde und daher die Anforderungen insgesamt für reichlich überzogen halte...

Naja, SFR scheint auf jeden Fall brilliant gut zu greifen und die Radeons schneiden alle ziemlich gut ab!
Wie auch schon bei allem zuvor erzeugt Mantle bei mir sehr viel Vorfreude auf OpenGL V und DirectX 12...

 

[Rollora]

Kommt es nur mir so vor oder zeigen bisher alle Civ: BE-Benches hauptsächlich, dass die allgemeine DirectX Performance eher weniger berauschend ist?
Klar, die Benches auf ComputerBase und Co zeigen alles andere als BestCase---aber bei der Optik hätte man doch eher 60+ FPS in 1080P auf ner Karte wie ner 750TI erwarten können, oder?
Mantle, CPU-Skalierung, DSR und 4K in Civilization: Beyond Earth - ComputerBase
Edit: Ok, gerade das Video angeguckt, da wird wirklich schon einiges auf dem Bildschirm gezeigt! Ändert aber nichts daran, dass ich es als optisch ziemlich mau empfinde und daher die Anforderungen insgesamt für reichlich überzogen halte...

Naja, SFR scheint auf jeden Fall brilliant gut zu greifen und die Radeons schneiden alle ziemlich gut ab!
Wie auch schon bei allem zuvor erzeugt Mantle bei mir sehr viel Vorfreude auf OpenGL V und DirectX 12...

Tatsächlich wunder mich die Optik, die nur wenig besser als die alte 2D ISO Optik ist (also von der Übersichtlichkeit mal ganz abgesehen auch im Detailgrad) bzw der Hardwarehunger. Man sollte meinen JEDE 3D Karte sei dafür ausreichend.
Ich meine selbst meine Voodoo 2 hat früher ordentlich schöne Welten mit vielen Tausend Polygonen gezaubert... Also man sieht schon, je weniger ein Spiel am Limit der Hardware arbeiten muss, desto weniger wird optimiert

Fast perfekte Skalierung ist falsch, denn genau die gibt's mit SFR nicht. Dafür sind die Frametimes top.

Habs rausgenommen bzw editiert

 

[marvinj]

Wow, das klingt echt fantastisch. Das gibt der Branche Multi-GPU den Ruck. Wenn Mantle überall sein kkönnte, wäre das TOP

 

[Jan565]

Ein Schritt da in die richtige Richtung! Da zeigt Mantle mal, dass es nicht nur für dafür da ist die Auslastung zu verbessern sondern auch bei Multi GPU helfen kann.

Nur schade das es so lange gedauert hat bis man mal versucht Multi GPU zu obtimieren. Wobei ich ehrlich sagen muss, ich hatte nie Probleme mit 2 Karten.

Damals hatte ich 2 8800GTS G80 und selbst bei denen hatte ich nur selten MR oder ähnliches und auch fast alle Spiele die ich da gezockt habe liefen ohne Probleme.

Bei einem bekannten durfte ich auch damals mal Crysis 1 mir ansehen mit 2 4870 und es lief wunderbar. Gut das ist jetzt nur ein Spiel, aber es lief auf jeden Fall wirklich gut.

Hatte selber auch schon einmal für 2 Wochen CF mit 2 5850 und selbst mit denen hatte ich nie Probleme, da war nur mein 955BE der limitierende Faktor.

Bin mal gespannt was die Zukunft bringt, auf jeden Fall ist Crossfire und SLi eine Feine Sache!

 

[MfDoom]

Großartige Neuigkeiten, wenn das jetzt auch für Shooter gilt.
Wer zur Hölle braucht mehr als 30 Frames bei Civ?

 

[M4xw0lf]

Die SFR-Implementierung in Civ löst endlich mal das Versprechen von Multi-GPU ein: besseres Spielgefühl durch höhere Durchschnitts-FPS und Minimum-FPS, noch dazu verringerter Inputlag (statt wie bei AFR grundsätzlich erhöht).
Noch schöner wäre es natürlich, SFR-CF in Spielen zu sehen, wo diese Vorteile auch gebraucht werden können, d.h. vor allem Shooter - BF4, PvZ, Sniper Elite, etc.

 

[Multithread]

Die SFR-Implementierung in Civ löst endlich mal das Versprechen von Multi-GPU ein: besseres Spielgefühl durch höhere Durchschnitts-FPS und Minimum-FPS, noch dazu verringerter Inputlag (statt wie bei AFR grundsätzlich erhöht).
Noch schöner wäre es natürlich, SFR-CF in Spielen zu sehen, wo diese Vorteile auch gebraucht werden können, d.h. vor allem Shooter - BF4, PvZ, Sniper Elite, etc.

Das wäre natürlich noch schöner

Aber nur schon so kann AMD vielleicht dem ein oder anderen 2 Karten aufdrücken, mit dem aufgebohrten front end, sinkt auch die zeit der Poligonberechnung, ergo mehr FPS.
AMD scheint durchaus zu wissen was Sie da machen.

 

[CD LABS: Radon Project]

Großartige Neuigkeiten, wenn das jetzt auch für Shooter gilt.
Wer zur Hölle braucht mehr als 30 Frames bei Civ?

Brauchen? Wahrscheinlich niemand. Genießen? Hoffentlich jeder!
Flüssiges Scrolling und Zooming ist IMMER ein Kompfortgewinn! :teach:

 

[blackout24]

Bloss doof, dass wie wohl bei jeder low-level API die Forwärtskompatibilität flötten geht und bei neuen Architekturen die Performance schlechter ist als mit 0815 Direct3D.

AnandTech Portal | AMD Radeon R9 285 Review: Feat. Sapphire R9 285 Dual-X OC

Nach 6 Monaten haben die Entwickler sicher keine Lust für jede kleine neue Hardware Änderung bei neuen Karten zu optimeiren.

 

[marvinj]

Das wäre natürlich noch schöner

Aber nur schon so kann AMD vielleicht dem ein oder anderen 2 Karten aufdrücken, mit dem aufgebohrten front end, sinkt auch die zeit der Poligonberechnung, ergo mehr FPS.
AMD scheint durchaus zu wissen was Sie da machen.

Und genau das freut mich auch so. Denn AMD muss liefern. Grade auch wenn man das Prozessorgeschäft anschaut. Die Aktionäre wollen Ergebnisse sehen, und in der Graka-Branche sind sie immer noch sehr sehr stark und können mit Innovationen und Exklusiven Dingen Leute für sich gewinnen.
Bitte, so muss das gehen. Verteufelt AMD nicht immer, bitte

 

[Rollora]

Bloss doof, dass wie wohl bei jeder low-level API die Forwärtskompatibilität flötten geht und bei neuen Architekturen die Performance schlechter ist als mit 0815 Direct3D.

AnandTech Portal | AMD Radeon R9 285 Review: Feat. Sapphire R9 285 Dual-X OC

Nach 6 Monaten haben die Entwickler sicher keine Lust für jede kleine neue Hardware Änderung bei neuen Karten zu optimeiren.

Naja das stimmt schon, dass eine Low Level API eher angepasst werden muss als eine andere,
aber die Frage ist ja, ob den Low-Level Teil nicht eh die Entwickler schreiben
Die API selbst lässt einfach mehr Low Lewel Access zu, den muss der Entwickler nutzen. Also hat AMD damit nicht unbedingt mehr Arbeit. Der Entwickler vielleicht schon, aber im Moment ist es eher so, dass bei Mantle funktionen anders genutzt werden die generell in jedem Chip der GCN drin sind (und bestimmt auch Nachfolger) und einfach nur die Draw Calls reduzieren

 

[blackout24]

Naja das stimmt schon, dass eine Low Level API eher angepasst werden muss als eine andere,
aber die Frage ist ja, ob den Low-Level Teil nicht eh die Entwickler schreiben
Die API selbst lässt einfach mehr Low Lewel Access zu, den muss der Entwickler nutzen. Also hat AMD damit nicht unbedingt mehr Arbeit. Der Entwickler vielleicht schon, aber im Moment ist es eher so, dass bei Mantle funktionen anders genutzt werden die generell in jedem Chip der GCN drin sind (und bestimmt auch Nachfolger) und einfach nur die Draw Calls reduzieren

Tja und wenn ein ganz bisschen veränderter Chip heraus gebracht wird (wie bei der AMD Tonga Karte im Benchmark), läuft die ganze Sache langsamer als eine normale HighLevel API. Tolle Wurst. Wie gesagt Spieleentwickler haben sicher kein Bock 1-2 Jahre zu schauen, dass ihr Spiel an jede Grafikkarte angepasst wird nur damit es anständig läuft. Längerfristig ist HighLevel wohl doch eher die bessere Lösung.

 

[Rollora]

Tja und wenn ein ganz bisschen veränderter Chip heraus gebracht wird (wie bei der AMD Tonga Karte im Benchmark), läuft die ganze Sache langsamer als eine normale HighLevel API. Tolle Wurst. Wie gesagt Spieleentwickler haben sicher kein Bock 1-2 Jahre zu schauen, dass ihr Spiel an jede Grafikkarte angepasst wird nur damit es anständig läuft. Längerfristig ist HighLevel wohl doch eher die bessere Lösung.

Naja man darf das nicht so schwarz/weiß sehen.
Viele Funktionen sind sicher noch in den kommenden GPUs drin. Selbst wenn diese geringfügig anders aussehen, würde man sie übern Treiber kompatibel machen können.
Auch über GLIDE gab es diese Diskussionen, am Anfang war etwa die Voodoo 2 zu manchen Voodoo 1 Spielen nicht kompatibel, das kam dann noch.
Viele Vorteile des Low-Level Ansatzes bleiben darüber hinaus bestehen.

 

[PCGH_Marc]

Golem.de hat im CPU-Limit mit Mantle +73 % gemessen: http://www.golem.de/news/civ-beyond...-geringere-latenz-mit-mantle-1410-110077.html

 

[VikingGe]

Längerfristig ist HighLevel wohl doch eher die bessere Lösung.

Die Frage ist, wie High-Level ein solches API sein soll, das gleichzeitig auch tatsächlich die Fähigkeiten der Hardware effizient nutzt, flexibel einsetzbar ist und wie viel Arbeit der Treiber hinterher erledigen müsste. Anhand der Funktionsnamen lässt sich einigermaßen erahnen, wie Low-Level Mantle tatsächlich ist - wahrscheinlich lässt sich vieles direkt auf OpenGL mappen:

Spoiler

grAllocMemory -> glNamedBufferStorage, ggf. in Verbindung mit GL_ARB_sparse_buffer
grAttachImageViewDescriptors -> ?
grAttachMemoryViewDescriptors -> ?
grAttachNestedDescriptors -> ?
grAttachSamplerDescriptors -> ?
grBeginCommandBuffer -> gibt es so nicht
grBeginDescriptorSetUpdate -> ?
grBindObjectMemory -> ? - möglicherweise glBindBuffer
grClearDescriptorSetSlots -> ?
grCmdBeginQuery -> glBeginQuery
grCmdBindDescriptorSet -> ?
grCmdBindDynamicMemoryView -> ?
grCmdBindIndexData -> glBindBuffer
grCmdBindPipeline -> ggf. glBindProgramPipeline, vielleicht auch Framebuffer
grCmdBindStateObject -> gibt es so nicht
grCmdBindTargets -> ?
grCmdClearColorImage -> glClearTexImage
grCmdClearColorImageRaw -> ?
grCmdClearDepthStencil -> glClear oder glClearTexImage
grCmdCloneImageData -> glCopyTextureSubImage*D?
grCmdCopyImage -> CopyTextureSubImage*D?
grCmdCopyImageToMemory -> glGetTextureImage
grCmdCopyMemory -> glCopyNamedBufferSubData
grCmdCopyMemoryToImage -> glTexSubImage*D
grCmdDbgMarkerBegin -> ?
grCmdDbgMarkerEnd -> ?
grCmdDispatch -> glDispatchCompute
grCmdDispatchIndirect -> glDispatchComputeIndirect
grCmdDraw -> glDrawArrays und co.
grCmdDrawIndexed -> glDrawElements und co.
grCmdDrawIndexedIndirect -> gl(Multi?)DrawElementsIndirect (gibt es in D3D11 nicht)
grCmdDrawIndirect -> gl(Multi?)DrawArraysIndirect
grCmdEndQuery -> glEndQuery
grCmdFillMemory -> glClearNamedBufferSubData
grCmdInitAtomicCounters -> ?
grCmdLoadAtomicCounters -> ?
grCmdMemoryAtomic -> ? - Buffer erlauben atomaren Zugriff.
grCmdPrepareImages -> ?
grCmdPrepareMemoryRegions -> ? - ggf. glNamedBufferPageCommitmentARB
grCmdResetEvent -> ?
grCmdResetQueryPool -> ?
grCmdResolveImage -> ?
grCmdSaveAtomicCounters -> ?
grCmdSetEvent -> ?
grCmdUpdateMemory ? - ggf. glNamedBufferSubData, glFlashMappedNamedBufferRange, Memory Barriers
grCmdWriteTimestamp -> ?
grCreateColorBlendState -> glEnable(GL_BLEND), glBlend***
grCreateColorTargetView -> ?
grCreateCommandBuffer -> Gibt es so nicht
grCreateComputePipeline -> ggf. glCreateProgramPipelines
grCreateDepthStencilState -> glEnable(...), ?
grCreateDepthStencilView -> ? - ggf. Zugriff über Texturen
grCreateDescriptorSet -> ?
grCreateDevice -> GL nicht zuständig
grCreateEvent -> ?
grCreateFence -> glFenceSync
grCreateGraphicsPipeline -> ggf. glCreateProgramPipelines
grCreateImage -> glCreateTextures, glTextureStorage*D
grCreateImageView -> glTextureView
grCreateMsaaState -> ?
grCreateQueryPool -> glCreateQueries
grCreateQueueSemaphore -> kein Queue-Konzept
grCreateRasterState -> ?
grCreateSampler -> glCreateSamplers
grCreateShader -> glCreateShader, glCreateProgram
grCreateViewportState -> ggf. glViewport
grDestroyDevice -> nicht zuständig
grDestroyObject -> ?
grDeviceWaitIdle -> ?
grEndCommandBuffer -> gibt es so nicht
grEndDescriptorSetUpdate -> ?
grFreeMemory -> glDeleteBuffers
grGetDeviceQueue -> kein Queue-Konzept
grGetEventStatus -> ?
grGetExtensionSupport -> glGet
grGetFenceStatus -> glClientWaitSync
grGetFormatInfo -> ?
grGetGpuInfo -> nicht vorhanden
grGetImageSubresourceInfo -> ggf. glGet
grGetMemoryHeapCount -> nicht vorhanden
grGetMemoryHeapInfo -> leider nicht vorhanden
grGetMultiGpuCompatibility -> keine Multi GPU-Fähigkeit
grGetObjectInfo -> ?, ggf. glGet
grGetQueryPoolResults -> so nicht vorhanden, ggf. glGetQuery
grInitAndEnumerateGpus -> nicht Aufgabe von GL
grLoadPipeline -> ?
grMapMemory -> glMapBufferRange, Persistent Mapping (gibt es in D3D11 afaik nicht)
grOpenPeerImage -> ?
grOpenPeerMemory -> ?
grOpenSharedMemory -> ?
grOpenSharedQueueSemaphore -> ?
grPinSystemMemory -> ?
grQueueSetGlobalMemReferences -> kein Queue-Konzept
grQueueSubmit -> kein Queue-Konzept
grQueueWaitIdle -> kein Queue-Konzept
grRemapVirtualMemoryPages -> in der Form wohl nicht vorhanden
grResetCommandBuffer -> nicht vorhanden
grResetEvent -> ?
grSetEvent -> ?
grSetMemoryPriority -> so nicht vorhanden
grSignalQueueSemaphore -> nicht vorhanden
grStorePipeline -> ?
grUnmapMemory -> glUnmapNamedBuffer, Persistent Mapping
grWaitForFences -> glClientWaitSync
grWaitQueueSemaphore -> nicht vorhanden

Man sieht: Es gibt wohl State-Objekte statt eines globalen Zustands (das ist alles andere als low-level), irgendein Queue-Konzept, Command Buffers (hat AMD irgendwo mal genauer erklärt, ermöglichen wahrscheinlich zusammen mit den State-Objects erst "echtes" Multithreading beim Rendern), irgendwas mit Events und ein paar Dinge, wo ich keine Idee habe, was die machen könnten, darüber hinaus mehr Kontrolle bei der Speicherverwaltung und bei Multi GPU-Rendering. Dazu Support für HLSL-Shader.

Es gibt zwar noch keine öffentliche Dokumentation, die tatsächlich Aufschluss darüber geben würde, und so bleiben das größtenteils Vermutungen, aber viel lower als bei herkömmlichen APIs scheint der Level nicht zu sein, oder anders gesagt, ein glDrawEverythingAndAsFastAsPossible(GL_VERY_NICE) existiert auch nicht mehr. Die klassischen High Level-APIs sind da doch eher OpenGL ≤2.1, und selbst das bot schon generische Vertexattribute und solche Späßchen. Dafür kann man damit aktuelle GPUs auch nicht mehr sinnvoll auslasten.

 

[Rollora]

Ist wohl auch der Grund warum man so bereitwillig OpenGL Next unterstützen möchte und Mantle quasi integrieren will.

 

[Interceptorvtec]

Vielleicht habe ich das nicht mitbekommen aber wie wurde mantle getestet ? Damit meine ich, wurde erst ein paar Stunden gespielt damit ordentlich was los ist oder Spiel an und los ? bei civilization 5 war die Performance am Anfang auch gut . Da würde ich gerne wissen was mantle bringt .

 

[M4xw0lf]

Vielleicht habe ich das nicht mitbekommen aber wie wurde mantle getestet ? Damit meine ich, wurde erst ein paar Stunden gespielt damit ordentlich was los ist oder Spiel an und los ? bei civilization 5 war die Performance am Anfang auch gut . Da würde ich gerne wissen was mantle bringt .

Es gibt einen integrierten Benchmark der eine Szene aus einem recht fortgeschrittenen Spiel zeigt, afaik.