News Next-Gen-APIs: AMD will neben der CPU auch die GPU besser auslasten

[Musicon]

AMD muss zusehen, dass die neuen Karten bald lieferbar sind. Da werden die neuen Optimierungen wohl erst später kommen, als kostenloses, nachträgliches Upgrade sozusagen.

nur solange man nix sieht wird keiner zur AMD greifen...
erst wenn das versprochene eintrifft wird gekauft...
das wäre nen fail von AMD

 

[BlauX]

@deo
Nachträglich, nein. Es hängt von den Entwicklern ab, welche Erfahrungen damit bereits bei den Konsolen gemacht wurden.
Mit DX12 sind Treiber nicht mehr so wichtig. Die Entwickler dürfen sich nun quasi deutlich mehr austoben.

Ergänzung (31. März 2015)

nur solange man nix sieht

http://www.anandtech.com/show/9124/amd-dives-deep-on-asynchronous-shading


Die richtige, weil im Artikel genannte ist falsch. Der Schreiberling des Artikels ist nicht imstande die Folien zu interpretieren ... naja, watt solls

AMD GCN 1.2 (285) 1 Graphics + 64 Compute / 64 Compute
AMD GCN 1.1 (290 Series) 1 Graphics + 64 Compute / 64 Compute
AMD GCN 1.1 (260 Series) 1 Graphics + 64 Compute / 64 Compute
AMD GCN 1.0 (7000/200 Series) 1 Graphics + 2 Compute / 2 Compute

 

[berkeley]

Finde ich stark von AMD! Die DX12 API scheint ja bzgl. der DrawCalls besser auf GCN abgestimmt zu sein als auf Maxwell.

 

[PiPaPa]

Witzig wenn man bedenkt das Leute wie "kisser" behauptet haben das ja nvidia mit Microsoft so eng an DX12 gearbeitet haben das sie AMD mit Mantle platt machen würden, und nvidia ja soviel in Treiber investiert.

Das der derzeitige Stand ist das nvidias derzeitiger DX12 Treiber doch eher schwachbrüstig ist, ist doch eine gewisse Ironie.
Aber man kann sich nut wünschen das nvidia ihren Treiber noch entsprechend optimiert. Konkurrenz und so.

 

[kl31]

Wird langsam Zeit das ich AMD Aktien ins Portfolio packe, denke AMD ist auf einem guten Weg

genau das ist der falsche weg...

weil die betriebe durch diese art immer wachsen müssen und somit alles zerstören oder selbst zugrunde gehen
aktionäre wollen nur gewinn maximierung....

 

[oldmanhunting]

Ich glaube solche Sachen erst, wenn es verfügbar ist und auch getestet wurde. Irgendwelche Marketing Folien (egal vom wem) sind schön zu lesen aber mehr auch nicht.

AMD sollte sich besser darauf konzentrieren jetzt mal zügig Neue GPU's zu bringen die frisches Geld in die leeren Kassen spülen als seinen alten Kram schneller zu machen. Der Kunde hat das Geld und ist auch bereit es auszugeben um sich neue und bessere Hardware zu kaufen aber wo nichts ist kann man auch nichts kaufen.

 

[kl31]

AMD sollte sich besser darauf konzentrieren jetzt mal zügig Neue GPU's zu bringen die frisches Geld in die leeren Kassen spülen

ich frage mich immer woher wisst ihr das alles.

ich glaube nvidia hat leere kassen, weil die ihre (ausführ-sklaven) marionetten alle bezahlen muss .....

 

[majistik]

Werden den die 7000 GPUs mit dx 12 versorgt, und wenn dann mit welcher featureversion ?
Ansonten kann AMD ja Mantle entsprechend anpassen.

 

[Nai]

muss ich als Coder eig aktiv was für optimieren oder geht der Krams @ News vollautomatisch @ DX12 & GPU intern einher?

Ohne die news selbst beziehungsweise ihre Auswirkungen 100 \% verstanden zu haben (ich muss mir irgendwann mal die Specs durchlesen wenn ich Zeit habe und sie draußen sind): Das grundlegende Problem, die asynchrone Programmierung der GPU mit mehreren Streams, muss vom Programmierer selbst gemacht werden. Das ist wiederum relativ hässlich und umständlich, gerade bei komplexeren Problemen.

Gegenüber Nvidia sieht sich AMD in diesem Aspekt im Vorteil. Maxwell von Nvidia sei nicht in der Lage, mehrere parallele Kommandoströme zu erstellen. Belege gibt es dafür bisher nicht.

NVIDIA kann bereits seit Jahren mehrere parallele Kommandoströme erstellen. Die Kommandoströme erlauben:
-Parallele Ausführung von unterschiedlichen GPGPU-Kernels
-Parallele Ausführung von Kopieren und GPGPU-Kernels
-Parallele Ausführung von Kopieren und Draw-Calls
Das einzige was afaik nicht geht und was in der News angesprochen wurde sind die Prioritäten und das gleichzeitige Ausführen von GPGP-Kernels und Draw-Calls.

Was mich in dieser Hinsicht etwas beschäftigt: Können AMD-GPUs mehrere Draw-Calls "gleichzeitig" mit unterschiedlichen Shadern bzw. Rasterpipelinestates ausführen?


Hier ist etwas kaputt an der News:

Die Technik soll nicht nur in der klassischen 3D-Grafik, sondern ebenso bei Virtual Reality Verwendung finden. So soll beispielsweise Asynchronous Time Warp, also das Rendern der Bilder aus verschiedenen Perspektiven, massiv beschleunigt werden können. Auch die auftretenden Latenzen sollen geringer ausfallen. In diesem Fall werden Rendering und Compute parallelisiert.

Denn asynchronous Timewarp ist:

TLDR: Asynchronous timewarp (ATW) is a technique that generates intermediate frames in situations when the game can’t maintain frame rate, helping to reduce judder.

Quelle: https://www.oculus.com/blog/asynchronous-timewarp/

 

[Faust2011]

Steht doch im Text, es ist ein Feature der API (Mantle, Vulcan, DX12), die die bessere Parallelisierung ermöglicht. Die AMD Karten der GCN könnten das schon lange nutzen, wenn es die Software hergeben würde. Aber das wird jetzt erst mit DX12 möglich. Wird daher kein 12.1 oder sonst was Feature werden, alle GCN Karten werden das unterstützen können.

Es ist so, dass sobald eine API (DirectX12, Vulcan, Mantle) per multiplen Queues mit der Grafikkarte kommunizieren, dann kann das Hardware-Feature der ACE ausgespielt werden. Das sieht man schön bei OpenCL (nicht OpenGL!), denn dort haben GCN-basierende Grafikkarten einen Sprung nach vorne gemacht (und OpenCL ist Queue-basiert).

Wieso warten? Mantle und DX12 sind auf Augenhöhe und Spiele mit Mantle zeigen das es (zum Teil deutlich) was bringt. Wenn jetzt noch der GPU Auslast im Limit effizienter wird

Wieso wird der Vorteil der ACEs in den GCN-Chips von AMD erst bei Benutzung von DX12 genutzt? Eigentlich hätte sich doch bereits mit Mantle sowohl das GPU- als auch das CPU-Limit nach hinten schieben müssen, wenn man eine GCN-basierende Grafikkarte einsetzt, oder?

 

[pipip]

echt? Gibts da ne Quelle? Abgesehen davon treffen die DX11 Limits ja heute schon nicht auf die PS4 / XB1 zu.

Das erste Beispiel. Ich spreche seit Monaten nur von Asynchronen Computing, Shader Computing, SFR ect. Und was ist, jetzt muss CB eine News schreiben, sogar von Liquid VR und auf einmal ist jeder hier überrascht ?

Ich habe vor längerer Zeit schon gesagt, dass AMD's Grafikkarten offensichtlich auf die neuen API abgestimmt sind. Anders bei NV offensichtlich, deren Maxwell GPU scheinbar eine für DX11 rein optimierte GPU ist (alles weg, was unter DX11 und 1080p nichts bringt).
Jetzt darf gespannt sein, ob Hawaii unter DX 12 an Performance gewinnt. Besonders interessant wird dann Games mit GPGPU Compute Shader, denn unter GPGPU sind die Maxwell GPUs nicht mehr so "effizient".

http://www.redgamingtech.com/playst...eon-volcanic-island-gpu-compute-similarities/
Hier kannst du alles schön nachlesen, was man im Falle der PS4 auf Bezug ACE verbessert hat.

Nai
Geht es nicht in der News darum, dass AMD mit den ACE Einheiten automatisch den Code asynchron optimiert. Das heißt, wird DX12 zum Beispiel genützt, macht das die ACE-Einheit selbst und der Programmierer selbst muss sich hier nicht einschalten.

NVIDIA kann bereits seit Jahren mehrere parallele Kommandoströme erstellen

Ja, das muss aber wie du eben sagst der Programmierer machen und bei AMD soll dass die ACE-Einheit über die API machen.

Ich glaube solche Sachen erst, wenn es verfügbar ist und auch getestet wurde. Irgendwelche Marketing Folien (egal vom wem) sind schön zu lesen aber mehr auch nicht.

Eh klar. Dass NV das SI über den L2 Cache verbessern konnte, sowas ist für dich gleich innovation. Wenn man aber den Code über ACE-Einheiten effizienter gestalten kann, da denkt man auch an Out of Order was bei CPUs schon seit Ewigkeiten gibt, dann bist du skeptisch. Aber anders habe erwartet man das von dir nicht, wenn es um eine AMD News geht.

AMD sollte sich besser darauf konzentrieren jetzt mal zügig Neue GPU's zu bringen die frisches Geld in die leeren Kassen spülen als seinen alten Kram schneller zu machen.

Auch verstehe ich nicht, was das mit den leeren Kassen zu tun hat. ACE Units gibt es seit der ersten HD 7000.
Das heißt, es ist eine bereits vorhandene Technologie und dass sie funktioniert, sollte klar sein, weil das eben besonders für die Sony Konsole ein wichtiges Feature ist.

Der Kunde hat das Geld und ist auch bereit es auszugeben um sich neue und bessere Hardware zu kaufen aber wo nichts ist kann man auch nichts kaufen.

Also ob du ein potentieller Kunde wärst, dass ich nicht lache. Du hast letztens selbst geschrieben, dass dir keine AMD ins Haus kommt.



Bei Compute Shading (GPGPU) wird Hawaii noch mal zeigen, wofür sie gemacht worden ist.

Ersten Test gab es ja schon.


@CB

Die Technik soll nicht nur in der klassischen 3D-Grafik, sondern ebenso bei Virtual Reality Verwendung finden.

Das heißt Liquid VR und wer hier davon noch nichts gehört hat, sollte hier mal nachlesen.
http://www.golem.de/news/virtual-re...zt-eine-grafikkarte-pro-auge-1503-112775.html

Ist dies der Fall, kommen die Asynchronous Compute Engines der Grafikkarte zum Einsatz: Parallel zum Rendering des nächsten Frames geben die ACEs einen Asynchronous Time Warp in Auftrag. Ein früheres Bild wird perspektivisch auf Basis des Tiefenbuffers interpoliert, das der Nutzer als Zwischenschritt für den nächsten echten Frame vorgesetzt bekommt.

Das ist nämlich eine VR Technik von AMD, die auf der GDC vorgestellt wurde und erster Anwendung und Beweis dass die Technik funktioniert, weil diese Demo auf der GDC lief.

 

[Sontin]

Seit Kepler GK110 unterstützt nVidia für Compute 32 Streams zur GPU, die dann von der Grid Management Unit in bis zu 32 Queues auf die SM verteilt werden.

Mit Maxwell v2 kann die GMU einen Stream für Graphics und bis zu 31 für Compute verwenden.

 

[VikingGe]

ein spiel wie thief benötigt nun wirklich keinen mantle support. läuft sowieso nicht im cpu limit.

Gerade Thief ist nicht unbedingt ein Effizienzwunder, siehe auch Techreport. Betrifft aber selbstverständlich keine Intel-CPUs.

Wieso wird der Vorteil der ACEs in den GCN-Chips von AMD erst bei Benutzung von DX12 genutzt? Eigentlich hätte sich doch bereits mit Mantle [...]

Laut Mantle Programming Guide, Seite 36, dürfte Mantle das relativ direkt im API unterstützen. Und irgendwie sehe ich nicht so ganz, warum eine (intelligente) D3D11/OpenGL-Implementierung das nicht nutzen können sollte.

- Compute-Dispatches unterscheiden sich auch API-seitig (deutlich) von Draw Calls
- Parallele DMA-Requests sind prinzipiell mit jedem API möglich, das irgendwie eine glBufferData-Funktion zur Verfügung stellt - und die gibt es IIRC seit OpenGL 1.5, also schon vor dem Dx9-Zeitalter. Das Problem ist eher, dass solche Funktionen enormen CPU-Overhead haben.
- Wenn Compute Shader A, Draw Call B und DMA-Request C nicht gerade auf die gleichen Ressourcen zugreifen, dann können die prinzipiell auch parallel ablaufen.

Die neuen Schnittstellen wälzen die Verantwortung jetzt lediglich auf den Entwickler der Anwendung ab, was ja auch sinnvoll ist (immerhin weiß der noch am besten, was seine Anwendung tun soll), aber mir kommt es doch etwas komisch vor, dass das vorher nicht funktioniert haben soll. Was übersehe ich da?

 

[acc]

ich frage mich immer woher wisst ihr das alles.

es gibt sowas wie geschäftsberichte, um deren veröffentlichung die firmen, die als aktienunternehmen geführt werden, nicht drumrum kommen. von daher ist die finanzielle lage der beiden firmen auch bei aussenstehenden gut bekannt, wenn man ein gewisses interesse dafür entwickelt.

 

[Kreisverkehr]

ich glaube nvidia hat leere kassen, weil die ihre (ausführ-sklaven) marionetten alle bezahlen muss .....

Nvidia und leere Kassen? MEldungen über Rekordquartale und Marktanteile suggerieren mir, dass es genau andersrum ist. Selbst Tegra und andere Subventionen ruinieren Nvidia nicht... Dazu dann Lizenzgebühren für G-Sync (weiß nicht, inwiefern es sich JETZT dann ggf nicht mehr auszahlt) ... Naja. Im Profimarkt sind die Grünen ja sehr gut vertreten und bei Noobs meistens: Oh, ich hab beide Hersteller zur Auswahl (AMD besserer Preis), ich nehm Nvidia (letztens halt gesehen).

Ohne die news selbst beziehungsweise ihre Auswirkungen 100 \% verstanden zu haben (ich muss mir irgendwann mal die Specs durchlesen wenn ich Zeit habe und sie draußen sind): Das grundlegende Problem, die asynchrone Programmierung der GPU mit mehreren Streams, muss vom Programmierer selbst gemacht werden. Das ist wiederum relativ hässlich und umständlich, gerade bei komplexeren Problemen.

So wie ich das verstanden hab (simpelst runtergebrochen):
Unter DX12 kann der Treiber/Api/Programmierer sein Zeug an die GPU schicken und diese kann - bei AMD - in Hardware entscheiden, wie die Streams aufgeteilt werden.
So eine Art Hyperthreading, bzw. SMT für die Grafikshader durch eben schon seit GCN 1.0 vorhandenen ACEs. Mal mehr und mal weniger kann also jede einzelne Ausbaustaufe der GCN-Architektur profitieren, wenn die neue Api genutzt wird.

Ist eh eine interessante Geschichte und dieses ekelhafte Rebranding hat nur "halben" Einfluss, weil manche mal mehr und mal weniger profitieren können...

 

[Nai]

Nai
Geht es nicht in der News darum, dass AMD mit den ACE Einheiten automatisch den Code asynchron optimiert. Das heißt, wird DX12 zum Beispiel genützt, macht das die ACE-Einheit selbst und der Programmierer selbst muss sich hier nicht einschalten.

Ja, das muss aber wie du eben sagst der Programmierer machen und bei AMD soll dass die ACE-Einheit über die API machen.

Bitte spezifizieren. Die ACEs müssen durch Queues angesteuert werden. Die Queues muss man als Programmierer immer noch selbst *irgendwie* mit der API definieren, indem man die Abhängigkeiten innerhalb der Queues vorgibt und die CPU dementsprechend mit der GPU synchronisiert. Darum führt kein Weg drum herum, weshalb das alle Queue basierten APIs heutzutage so gemeinsam haben. Eben dieses Programmieren von mehreren Queues ist gerade meist recht umständlich. Allerdings ist es den APIs möglich die Queue, sofern diverse Restriktionen, vor allem die Bufferbasiertheit, gegeben sind, automatisch etwas zu optimieren. Diese Optimierungen nehmen zum Beispiel OpenGL und OpenCL automatisch vor.

 

[W4RO_DE]

Warum wird hier so getan als sei das ein spezielles AMD-Ding? Weil das deren Marketingabteilung sagt? Nvidias aktuelles Portfolio kann das ebenso, wie anandtech richtig darstellt.

 

[Faust2011]

Mit Maxwell v2 kann die GMU einen Stream für Graphics und bis zu 31 für Compute verwenden.

Ein Stream? Da ist dann der Engpass. Solche nette Sachen wie das in der News genannte Unschärfeeffekt im Post-Processing, das fast keine Performance kostet, braucht man eben doch mehr als einen Stream (bzw. mehrere Queues, die dann auch tatsächlich über die Shader parallel abgearbeitet werden können, um diese optimal auszulasten).

Gerade Thief ist nicht unbedingt ein Effizienzwunder, siehe auch Techreport. Betrifft aber selbstverständlich keine Intel-CPUs.


Laut Mantle Programming Guide, Seite 36, dürfte Mantle das relativ direkt im API unterstützen. Und irgendwie sehe ich nicht so ganz, warum eine (intelligente) D3D11/OpenGL-Implementierung das nicht nutzen können sollte.

Du meinst, wenn man (der Programmierer) sich Mühe gibt, dann sollte er mit Mantle bereits jetzt auf Hawaii-Chips mehr FPS liefern können (auch in dem Falle, wenn nicht ein CPU-Limit vorliegt)? Selbst mit DX11/OpenGL sollte das heute schon möglich sein?

 

[Sontin]

Es sind 1 Stream für Graphics und bis zu 31 für Compute. AMD hat auch nur einen Command-Prozessor für Grafikberechnungen.

 

[Faust2011]

Ja, da lag ich falsch. Habs grad nochmals im Artikel von anadtech nachgelesen und gesehen, dass der Vorteil dann zum Tragen kommt, sobald man überhaupt mit mehreren Streams umgehen kann. Demnach sollte der Performance-Sprung auch bei Nvidia möglich sein.

Allerdings erst ab einer Titan X