Oxide: NVIDIA-GPUs unterstützen Asynchronous Compute/Shaders unter DX12 nicht

[Cryptic]

Nur das die 290X in immer Games vor einer Titan liegt. Das ist worauf ich damit hinaus wollte.

Achso, ok. Ja, da ist sie immer leicht vor einer Titan, das stimmt. Aber zum einen kam sie ja erst nach der Titan auf den Markt (jünger + besser optimiert) und zum anderen war das wirklich nur eine Ausnahme.
Ich meinte ja mit meiner Aussage, dass NV fast immer für Enthusiasten interessanter ist als AMD. Mal sehen ob sich die Kräfteverhältnisse in Zukunft unter DX12 wieder verschieben werden. Je mehr Leistung desto besser. Egal von welchem Hersteller.

 

[Cippoli]

Warten wir einfach mal ab. Ohnehin lässt sich noch kein endgültiges Fazit zu dem Thema ziehen. Wenn NVIDIA es per Treiber irgendwie gemanaged kriegt und am Ende die Leistung stimmt, sollte es uns egal sein wie diese zustande kommt. Ganz so dramatisch wie die Sache in manchen Foren diskutiert wird, könnte es dann am Ende doch nicht werden. Viele stürzen sich einfach in einen rot/grünen-Grabenkampf ohne die eigentliche Sachlage zu verstehen oder zu hinterfragen. Business as usual, könnte man schon sagen.

 

[Cryptic]

Ja, so sehe ich das auch.
Daher warte ich einfach mal ganz entspannt ab. NV scheint ja mit Hochdruck daran zu arbeiten.
Ob es dann am Ende zufriedenstellend gelöst wurde wird sich zeigen.

 

[[HOT]]

NV hat die eigentlich stark auf FL11_0 optimierte Maxwell-Architektur mit der heißen Nadel so umgestickt, dass sie FL12_1 dranschreiben konnten. Jetzt haben sie den Salat. Aber es wird wohl so laufen, dass die fehlenden Teile durch Softwareemulation so hingebogen werden können, dass immerhin kein Performancenachteil dabei rumkommt, sodass die Studios ohne Probleme das volle 12_0 Featurelevel implementieren können. Ohne Async Compute gibts übrigens kein Featurelevel über 11_0, also ur-Maxwell, das mal als Hinweis. Async Compute ist offenbar schon für FL11_1 notwendig, AMD unterstützt bislang nämlich nur FL11_1 mit ALLEN GCN-Karten. FL12_0 für GCN ab 1.1 wird offenbar erst später fertiggestellt. AMD scheint momentan sehr konzentriert am DX12-low-level-Treibercode zu stricken um den Fehler nicht zu wiederholen, den man bei DX11 gemacht hat.
Momentan scheinen die Radeon-Modelle bei AoS mit FL11_1 zu laufen, während alle NV-Karten nur mit 11_0 laufen, auf NVs Wunsch, weil die FLs darüber auf Maxwell2 zu langsam liefen. Momentan schein Oxide NV aktiv bei der Treiberentwicklung zu helfen, dass AsyncCompute demnächste auf Maxwell ohne Leistungseinbußen genutzt werden kann.

 

[fdsonne]

Für mich sind die dann doch schon eher als Zeitgleich zu sehen. Titan Classic gehörte zu GTX780 und co und AMD stellte dem die R9 290(X) gegenüber, auch wenn ein halbes Jahr später.

Neja, die erste Titan ist eher ein Zwitter für Gamer und Profimarkt-Software User (weil mit DP Performance). Die etwas langsamere 780er ist der Gamerpart. Mit Hawaii hat AMD leistungstechnisch aufgeholt und NV minimal später mit der 780TI gekontert. Zwischen der 780er/Titan classic und einer 780TI liegen gut und gerne 20%. (erste Versionen der GK110 GPU vs. letzte Versionen mit neuerem Chip) Vor allem wenn man Custom Modelle vergleicht, die schnell mal 10-20% mehr Leistung zeigen zzgl. der mehr Leistung durch mehr Ausführungseinheiten aufgrund des Vollausbaus. Da sieht ne Titan Classic kein Land -> es sei denn, die 3GB VRAM deckeln
Klar ist das alles die gleiche Modellreihe und man hat es dort bei NV ziemlich auf die Spitze getrieben, was die Modellvielfalt angeht. Aber dennoch ist der Vergleich etwas "unfair", weil einfach erstes Modell mit einer ganz neuen Marktausrichtung vs. ein mehr oder weniger reines Gamermodell mit einem halben Jahr Zeitversatz -> obwohl es für dieses Modell dediziert einen Gegenspieler gibt...

Auch sehe ich den Vergleich unter dem Gesichtspunkt, dass es nunmehr eine Nachfolgegeneration gibt (bei NV) nicht für ganz trivial an. Bei AMD gibt es diese nicht. Unter der Haube ist das ziemlich gleich... Rein was die Optimierungen auf die Hardware betrifft, hat AMD hier klar einen Vorteil. NV kümmert sich nicht mehr um Kepler. Die Karten sind deswegen nicht automatisch langsam. Das nicht, aber sie sind bei einigen Titeln eher nicht so schnell, wie sie sein müssten bzw. die neue Gen. wird stark optimiert und zieht somit davon...

 

[[HOT]]

Die eigentliche Power von Hawaii liegt offenbar noch brach, AMD spricht von bis zu 46% Performancegewinn durch AsyncCompute im GPU-Limit. Damit könnten die Shader von GCN bald genauso effizient werden wie die Maxwell-Shader. Zudem verschwindet bei DX12 ja auch das Drawcall-Limit, dass GCN unter DX11 offenbar auch des öfteren mal trifft, besonders in niedrigen Auflösungen natürlich. Nur in Sachen Tesselation ist GCN definitiv nicht konkurrenzfähig und die kann man, wenn man will, im Treiber begrenzen.

Kepler scheint von DX12 kaum zu profitieren i.Ü., da diese nur FL11_0 beherrschen und der Treiber unter DX11 schon sehr effizient ist.


Edit: sollte eigentlich nicht so negativ klingen. Danke für den Hinweis. Und der Teil mit Tahiti war schlicht falsch.

 

[fdsonne]

Und Kepler-Besitzer sind aufgrund der Tatsache, dass sie nur FL11_0 beherrschen, ganz schön angeschissen bei DX12. Bei Kepler wird DX12 kaum oder keine Leistungssteigerungen bringen, da NV bei DX11 ja auch im CPU-Limit sehr effizient ist.
Besonders gut ist die Entwicklung witzigerweise für Tahiti-Besitzer, denn die können FL11_1 und haben mit 3GB sogar genug Speicher für die meisten Anwendungen an Bord.

Das ließt sich wie eine Marketingantwort... Ganz ehrlich, was interessiert es bitte ernsthaft, wie viel DX12 zulegt?? Gerade unter dem Gesichtspunkt den du mit NV ansprichst? Es kommt doch darauf an, was hinten bei rum kommt. Und wenn NV da nur minimal oder gar nicht zulegt mit DX12 (aufgrund guter DX11 Basis), AMD aber stark zulegt, aufgrund nicht so guter DX11 Basis, ist das doch völlig OK?

 

[Schaffe89]

Mich beschleicht ja immernoch der Verdacht, dass Effizienz bzw. niedriger Verbrauch (wenn es auch oftmals total zu vernachlässigen ist) einfach punktet anstatt nur Features oder nur Leistung oder nur Preis. -> die Mischung muss stimmen. Und selbst mit Speicherproblem ist die 970er ne solide Karte mit sehr niedrigem Verbrauch.

Ich erinnere mich noch an die GTX 480, GTX 470, GTX 460 Zeiten, wo AMD in noch deutlicherer Form effizienztechnisch vorne war und trotzdem wurde Nvidia mehr als von der Hälfte der Käufer gekauft.
Und womöglich war es lediglich der Grund weil Nvidia so spät mit den Karten kam und AMD gut vorlegte.
Die aktuelle Misere sehe ich weniger in den Produkten, die zwar effizienztechnisch Seit Kepler marginal und jetzt Seit Maxwell teilweise weit und teilweise marginal zurückliegen, vielmehr sehe ich die Probleme in dem Branding AMD.
Was würde passieren, wenn AMD einen sehr schnelleren Prozessor ala Zen auf den Markt bringt? Die Grafikkartenkäufe würden wieder ansteigen.
Bei ATI damals hat es immer funktioniert bei schlechten oder schlechteren Produkten einfach demenstsprechend den Preis zu senken und gut war.
Aber das geht imho heute nicht mehr so einfach und ich vermute es liegt einfach schlicht am Branding.

 

[Cippoli]

NV hat die eigentlich stark auf FL11_0 optimierte Maxwell-Architektur mit der heißen Nadel so umgestickt, dass sie FL12_1 dranschreiben konnten. Jetzt haben sie den Salat. Aber es wird wohl so laufen, dass die fehlenden Teile durch Softwareemulation so hingebogen werden können, dass immerhin kein Performancenachteil dabei rumkommt, sodass die Studios ohne Probleme das volle 12_0 Featurelevel implementieren können. Ohne Async Compute gibts übrigens kein Featurelevel über 11_0, also ur-Maxwell, das mal als Hinweis. Async Compute ist offenbar schon für FL11_1 notwendig, AMD unterstützt bislang nämlich nur FL11_1 mit ALLEN GCN-Karten. FL12_0 für GCN ab 1.1 wird offenbar erst später fertiggestellt. AMD scheint momentan sehr konzentriert am DX12-low-level-Treibercode zu stricken um den Fehler nicht zu wiederholen, den man bei DX11 gemacht hat.
Momentan scheinen die Radeon-Modelle bei AoS mit FL11_1 zu laufen, während alle NV-Karten nur mit 11_0 laufen, auf NVs Wunsch, weil die FLs darüber auf Maxwell2 zu langsam liefen. Momentan schein Oxide NV aktiv bei der Treiberentwicklung zu helfen, dass AsyncCompute demnächste auf Maxwell ohne Leistungseinbußen genutzt werden kann.

Verwechselst du da nicht etwas? Die DX12-API und die Direct3D Feature-Levels sind zwei unterschiedliche Dinge. Die DX12-API ist quasi nur der Untersatz, der grundsätzlich asynchrone Shader unterstützt, was aber nichts mit dem Feature-Level zu tun hat. AMDs letzte GCN-Iteration (GCN 1.2) unterstützt das Feature-Level 12_0, während NVIDIA mit Maxwell 2.0 das Feature-Level 12_1 unterstützt. Wie die jeweiligen Architekturen nun mit asynchronen Shadern umgehen, ändert an der FL-Einstufung nichts. AMDs Chipdesign scheint einfach nur besser hinsichtlich der asynchronen Shaderfähigkeiten optimiert zu sein, was ihnen nun unter DX12 natürlich zu Gute kommt.

 

[[HOT]]

Fermi war aber auch technisch um Längen besser als der VLIW-Kram. Leider konnten die Features der Architektur auch nie so richtig ausgenutzt werden.

- - - Updated - - -

Verwechselst du da nicht etwas? Die DX12-API und die Direct3D Feature-Levels sind zwei unterschiedliche Dinge. Die DX12-API ist quasi nur der Untersatz, der grundsätzlich asynchrone Shader unterstützt, was aber nichts mit dem Feature-Level zu tun hat. AMDs letzte GCN-Iteration (GCN 1.2) unterstützt das Feature-Level 12_0, während NVIDIA mit Maxwell 2.0 das Feature-Level 12_1 unterstützt. Wie die jeweiligen Architekturen nun mit asynchronen Shadern umgehen, ändert an der FL-Einstufung nichts. AMDs Chipdesign scheint einfach nur besser hinsichtlich der asynchronen Shaderfähigkeiten optimiert zu sein, was ihnen nun unter DX12 natürlich zu Gute kommt.

- FL11_0 -> kein AsyncCompute
- FL11_1, 12_0, 12_1 -> AsyncCompute = essenzieller Bestandteil

Ohne AsnycCompute, kein FL über 11_0 um das andersherum zu formulieren. DX12 ist das alles. Wenn ein Entwickler Featurelevel 11_1 implementiert, wird er auch AsnycCompute nutzen. Das wird auch auf Maxwell2 demnächst gehen, nur sind die Performancevorteile nicht so groß.

 

[Cippoli]

- FL11_0 -> kein AsyncCompute
- FL11_1, 12_0, 12_1 -> AsyncCompute = essenzieller Bestandteil

Ohne AsnycCompute, kein FL über 11_0 um das andersherum zu formulieren. DX12 ist das alles. Wenn ein Entwickler Featurelevel 11_1 implementiert, wird er auch AsnycCompute nutzen. Das wird auch auf Maxwell2 demnächst gehen, nur sind die Performancevorteile nicht so groß.

Gibt es dafür denn eine Quelle, wo für die höheren Feature-Levels Async Compute ein essenzieller Bestandteil sein muss? Ich schließe es nicht aus, wäre mir aber neu. Würde mich deshalb schon interessieren.

 

[free-server]

https://msdn.microsoft.com/en-us/library/windows/desktop/ff476876(v=vs.85).aspx

 

[Cippoli]

https://msdn.microsoft.com/en-us/library/windows/desktop/ff476876(v=vs.85).aspx

Wenn du mir nun noch den Absatz zeigen könntest, der meine Frage beantwortet, wäre ich dir noch mehr dankbar.

 

[[HOT]]

Ist aber auch klar, da AoS ja AsyncShader bei allen GCN nutzt und AMD bisher nur FL11_1 unterstützt muss Oxide ja FL11_0 und FL11_1 implementiert haben.
Es geht ja hierbei auch immer um Aufwand und Kosten. Die Entwickler werden das implementieren, was am Markt am meisten bringt und am wenigsten Aufwand generiert. Deshalb ist es auch nicht schwer abzuschätzen, wie das demnächst ablaufen wird: Die Hersteller werden sich an der XBox One orientieren und alles, wass FL12_0 mit RessourceBinding Tier2 nicht unterstützt weitestgehend über DX11 erschlagen mMn, da man ja DX11 noch erhalten muss, denn Fermi und VLIW machen ebenfalls noch ca. 10% des Marktes aus und es gibt nen Haufen Win10-Verweigerer - ein Teil den man nicht ignorieren kann. Die XBox One nutzt FL12_0.
NV wird sicherlich, wie ich den Laden kenne, versuchen ihre Gameworks-Effekte demnächst nur noch für FL12_1 freizugeben, damit AMD ausgeschlossen wird und um ein Alleinstellungsmerkmal zu haben.

Passend zum Thema FL die News:
http://www.3dcenter.org/news/hardware-und-nachrichten-links-des-56-september-2015

 

[free-server]

Wenn du mir nun noch den Absatz zeigen könntest, der meine Frage beantwortet, wäre ich dir noch mehr dankbar.

ziemlich weit unten
https://msdn.microsoft.com/en-us/li...spx#asynchronous_compute_and_graphics_example

 

[merlinmage]

Bis DX 12 in allen Spielen die auf den Markt kommen Gang und Gebe ist, wird Pascal schon längst released sein. Von daher einfach mal die Füße stillhalten

 

[free-server]

nur scheiße, daß pascal wie es aussieht im aktuellen Stand das gleiche Problem hat

 

[merlinmage]

Da würd ich persönlich wirklich bis zum Release warten. Aber bis zum Vollausbau hab ich ja wieder 1,5-2 Jahre Zeit.

 

[MKfeist]

nvidia kann alles,nur zzt. nichteinmal 11_1?

bin halbwegs gespannt wie es sich entwickelt,
hoffe das spiel wird gut.

 

[Tzunamik]

Lustig, bei nVidia is alles abwarten und es wird gut, wenn aber AMD mal keine Probleme hat, is das nicht so gut...

Ich find es krass, ich war auch mal so... vor ca 6 Monaten.. bevor mir nVidia ins Gesicht gespuckt hat mit meinen zwei 970ern und dem Problem das ich im SLI fast IMMER im Speicherlimit unterwegs war...

 

[[HOT]]

Mit Pascal würd ich nicht vor Ende 2016 rechnen.

 

[merlinmage]

Passt ja. GTX 780 (5/13), GTX 980Ti (7/15), GTX 1080Ti (7/17).

 

[Cryptic]

Ich find es krass, ich war auch mal so...

Wie jetzt? Du warst auch mal ein vernünftiger, sachlicher User der erst klare Fakten abwarten wollte ehe er einen Shitstorm gestartet hat und bist nun ein Fanboy-Troll der lospestet ohne zu lesen was hier bisher so alles geschrieben wurde?
Naja, deine Offenheit ehrt dich natürlich. Aber wenn ich du wäre würde ich das trotzdem nicht an die große Glocke hängen.

 

[MKfeist]

bei nv gibt es selten klare fakten-und das ist fakt...

echt hallo,gehts noch?

 

[Schaffe89]

Die klare Ergebnis wird halt sein, dass AMD, wenn asycnhronous Shaders genutzt werden 10 bis 20% davonzieht.
Das kann man gut an den Ergebnissen in AOS sehen.
Gespannt bin ich wie es in Tombraider, Battlefront, ARK usw.. aussieht.
ARK soll ja auch für die Konsolen kommen.

 

[Cibo]

Wobei man ehrlicher Weise erst einmal überprüfen sollte was der "Normalfall" ist. Das Spiel sieht ziemlich extrem aus ala Supreme Commander. Wenn nvidia mit ihren 32 "wasauchimmer" ein realistischen Normalwert angenommen hat und der Entwickler einfach ins Extreme geht kann auch nvidia nix dafür. Ich will erstmal Fachleute hören wa ssie von diesen 32 halten und ob es ein genereller Flaschenhals darstellt oder der Entwickler einfach schlicht an der Hardware vorbei Entwickelt hat.

 

[slot108]

@Cryptic: well done

 

[unl34shed]

Wobei man ehrlicher Weise erst einmal überprüfen sollte was der "Normalfall" ist. Das Spiel sieht ziemlich extrem aus ala Supreme Commander. Wenn nvidia mit ihren 32 "wasauchimmer" ein realistischen Normalwert angenommen hat und der Entwickler einfach ins Extreme geht kann auch nvidia nix dafür. Ich will erstmal Fachleute hören wa ssie von diesen 32 halten und ob es ein genereller Flaschenhals darstellt oder der Entwickler einfach schlicht an der Hardware vorbei Entwickelt hat.

Es geht nicht darum, ob nvidia nur 32 "wasauchimmer" (du meinst wohl graphic- und compute-queues) in maxwell verbaut hat, sondern dass nvidia diese aktuell nur für reine compute-aufgaben oder die Grafikberechnung nutzen kann.
Das führt im Endeffekt dazu, dass sich die Zeiten für die einzelnen Arbeitsschritte entsprechend addieren.

Mal ein Beispiel brauchst du 10ms für die Grafik und 5ms für compute sind es am Ende 15ms -> 66,6FPS ohne Async Shadern
Mit Async Shadern ist es möglich diese Berechnungen parallel auf der GPU aus zu führen. Anstelle der 15ms könnten dann nur noch 10-12ms -> 83,3-100FPS raus kommen.

Nvidia versucht dies jetzt über den Treiber zu erschlagen, sprich einen Scheduler einzubauen, der die Last auf der GPU steuern soll. Da das ganze im Gegensatz zu AMD, hier ist es in der GPU (Hardware) integriert, in Software abläuft ist das weniger performant und erzeugt darüberhinaus zusätzliche CPU Last. Auch wird es schwer werden die GPU so voll auszulasten, da es auch zu starken Latenzen führt, bis die Auslastung der GPU analysiert ist, der Scheduler berechnet und neue Tasks auf die GPU los gelassen werden können.

Also haben wir mit DX12 vllt. das Gegenteil zu DX11 und Nvidia hat den größeren Treiberoverhead.

 

[Schaffe89]

Wobei man ehrlicher Weise erst einmal überprüfen sollte was der "Normalfall" ist. Das Spiel sieht ziemlich extrem aus ala Supreme Commander. Wenn nvidia mit ihren 32 "wasauchimmer" ein realistischen Normalwert angenommen hat und der Entwickler einfach ins Extreme geht kann auch nvidia nix dafür. Ich will erstmal Fachleute hören wa ssie von diesen 32 halten und ob es ein genereller Flaschenhals darstellt oder der Entwickler einfach schlicht an der Hardware vorbei Entwickelt hat.

Ich bin gespannt wie das in Stretegiespielen sich auswirken wird.
Prinzipiell sind ja Steigerungen bis 46% möglich, da könnte ich mit 10 bis 20 % nicht soweit daneben liegen.
Vorrausgesetzt, man nutzt es auch und ich gehe sehr stark davon aus dass es genutzt, ist vor allem wegen GCN in den Konsolen und den AMD Partnerschaften mit Directx12 Games.
Battlefront, Star Citizen, Tomb Raider, Deus X usw..

 

[pumuckel]

in Konsolen wird es sich auswirken, sehr stark sogar (aber nur in den FPS)

in modernen (1-2 Jahre alt) PCs ab 4 Core eher weniger

........... Viel wichtiger: lernt den gamedevs mal coding .... effizienzes coding ... nicht 0815 geht schon irgendwie emulating

aka ... wozu 4 versionen basteln, wir nutzen einfach ..... (engineconverter run)

aka ... wozu ne verzweigung für Hardware ... wir nehmen einfach den kleinsten gemeinsamen Nenner (auf PCs) ... außer einer der HW vendors zahlt dafür (und AMD hat z.B. dafür kein Geld über)

damals zu 3DFx zeiten (15 Jahre her) sah man noch krasse Unterschiede (1. doom).... wenn ich nun x1, ps4, pc bei je 1080 angucke seh ich nix mehr an offensichtlichen Unterschieden


atm kommen wirkliche Innovationen nur noch von SOC Herstellern (sieht man im Bereich Codecs/4K)