Hitman (2016) Episode 2: DX12 mit bis zu 60 Prozent Leistungsplus - und Problemen

Das DX12 bei weniger Details besser dasteht das verwundert mich nicht. Aber Highend Karten werden niemals so betrieben. Ihr versteht worauf ich hinaus will, oder?

Laggy.NET schrieb:

Man sieht halt, dass AMD die Rohleistung nicht auf die Straße bekommt bzw. sie nicht in viele FPS umwandeln kann.

Die Leistung zeigt sich erst, wenn die Framerates sinken und die Karten durch höhere Auflösungen stark ausgelastet werden.
Deswegen zeigt Async Compute ja so viel Wirkung bei AMD. Durch dieses Feature können sie auch bei geringeren Auflösungen gut ausgelastet werden. Nvidia hat das vermutlich nicht nötig, sonst würden die Karten in 1440p nicht so stark einbrechen. Für mich ein deutlicher Beweis, dass die Karten immer gut ausgelastet sind. Die Zeigen eben schon von anfang an, was sie können. Bei AMD ist das halt Treiber und Spielabhängig.

Das ist sehr interessant, aber für mich sagt das folgendes: AMDs karten haben mehr Rohleistung und mehr potenzielle leistung, als die Nvidia Gegenstücke, müssen aber erstmal gut ausgelastet werden.
Vielleicht ist der Treiber einfach nicht gut genug, um konstant maximale Leistung abrufen zu können. Irgendwo hakts einfach.

Nvidia spart dagegen an Rohleistung, bringt dafür aber die Leistung von anfang an konstant auf "die Straße". Großartige Optimierung, um die Karten besser auszulasten scheint nicht nötig zu sein.


Und eigentlich hat man das ganze schon immer gesehen. Bewegen sich die Framerates im oberen Bereich, dann ist oft nVidia vorne. Werden die Karten älter bzw. die Spiele fordernder, dann werden die AMD Karten schon in FullHD stärker belastet und schaffen nur noch 30-40 FPS, sind dann aber vor den Nvidia Gegenstücken.

Manche nennen es Langlebigkeit, was nicht unbedingt falsch ist. Aber letzten Endes ist es einfach nur eine Frage der Auslastung.


Wenn man jetzt böse ist, könnte man sagen, die Nvidia Karten schaffen anfangs tendenziell höhere Framerates in FullHD, als AMD, und wenn dann irgendwann die leistung eh zu knapp wird, dann ist AMD vorne. Aber wer will schon mit 40 statt 30 FPS Spielen? Beides ist mist, man reduziert also wieder die Grafiklast, um mehr FPS zu erreichen und hat wieder die Situation, dass die AMD Karten nicht voll ausgelastet werden.
Man muss die Karten einfach in die Knie zwingen, damit sie gut dastehen.

Mich würde in Anbetracht dieser These wirklich mal interessieren, wie sich eine R9 280X gegen eine GTX 770 schlägt, wenn man die Details sowiet reduziert, dass beide im 60er Bereich landen. Vermutlich erlischt der Vorteil der AMD Karte, den man bei Ultra Details (also niedrigen Framerates bei hoher Auslastung) sieht wieder komplett.


Klar, hört sich jetzt wieder nach Fanboy Gelaber an. Aber seid doch mal ehrlich. Ist es nicht so? Gegenargumente sind natürlich willkommen. Aber ich bin überzeugt, dass sowohl die vermeintliche Langlebigkeit der AMD Karten, als auch der Zugewinn bei Async Compute darauf zurückzuführen ist, dass die allgemeine Auslastung der Karten einfach mangelhaft ist. Die Auslastung steigt durch höhere Auflösungen, fordernden Spielen (mit zunehmenden Alter) und Async Compute. Vermutlich schenken sich z.B: die 280x und die GTX 770 überhaupt nichts, wenn man 60 FPS anvisiert.

Zum Vergrößern anklicken....

Ich würde das nicht auf den Treiber schieben, sondern auf die Architektur. Ich glaube ja sowieso, dass Treiber etwas überbewertet werden (wieso z. B. muss für ein Spiel Day1 ein Treiber rauskommen? Kann eigentlich nur den Grund haben, dass die Entwickler was falsch gemacht haben, wo die GraKa Hersteller verbessern müssen). AMD hat viel Rohleistung in Form von Shadern, das was die Shader füttern soll, das Front-End, ist dafür aber zu klein (besonders bei der Fury X). Zumindest hab ich das so mal auf ner englischen Seite gelesen, glaub es war wccftech, finde den Artikel auf die schnelle aber nicht. Hier kann man es aber ganz gut sehen: http://images.anandtech.com/doci/9390/FijiBlockDiagram.png?_ga=1.101328833.1787895756.1461942217 währenddessen die 980 Ti: http://cdn.wccftech.com/wp-content/...eForce-GTX-980-Ti-GM200-310-Block-Diagram.png Die 980 Ti hat dabei nur 2816 Shader, währenddessen die Fury X 4096. Aber es mangelt am Front-End: (Fiji’s Layout - The AMD Radeon R9 Fury X Review: Aiming For the Top)

Along those lines, while shading performance is greatly increased over Hawaii, the rest of the front-end is very similar from a raw, theoretical point of view. The geometry processors, which as we mentioned before are organized to 1 per shader engine, just as was the case with Hawaii. With a 1 poly/clock limit here, Fiji has the same theoretical triangle throughput at Hawaii did, with real-world clockspeeds driving things up just a bit over the R9 290X. However as we discussed in our look at the GCN 1.2 architecture, AMD has made some significant under-the-hood changes to the geometry processor design for GCN 1.2/Fiji in order to boost their geometry efficiency, making Fiji’s geometry fornt-end faster and more efficient than Hawaii. As a result the theoretical performance may be unchanged, but in the real world Fiji is going to offer better geometry performance than Hawaii does.

Zum Vergrößern anklicken....

Geht man jetzt davon aus, dass das Front-End wie der Prozessor unabhängig von der Auflösung ist, kann man schlussfolgern, dass die Fury X unter Full HD im "Front-End-Limit" läuft und erst bei UHD gleichmäßig ausgelastet werden kann. Würde das jetzt nicht auf den Treiber schieben. Ich denke, wir müssen lernen, dass sich Performance nicht mehr nur durch Shaderanzahl und Takt einschätzen lässt, sondern Dinge wie ACEs, Front-End, Tesselations- und Dreiecksberechnung, Speichergeschwindigkeit und Cache Größe auch eine Rolle spielen, anstatt alles auf die Treiber zu schieben. Das wäre dann doch zu einfach. Ich hoffe jedenfalls, das AMD das Problem mit Polaris löst.

Treiber werden niemals überbewertet. nVidia hat Shader Cache eingeführt. Und das war und ist genial.

Treiber sind der Treibstoff einer Graka. Da gibts immer was zu verbessern. Plus Ideen der Programmierer. Kostet halt.

Shader Cache bringt bei nVidia soviel das DX12 nichts mehr bringt. Bei nVidia. Bei AMD bringt DX12 was denn deren DX11 Treiber sind ********.

***** ist jetzt relativ, aber so gut wie bei Nvidia sind sie definitiv nicht.
AMD bietet seitdem Crimson aber auch einen Shader-Cache an.

Deswegen sieht zur Zeit AMD besser aus. Weil deren DX11 Treiber zum Vergessen sind. FAKT!

nVidia hat den Job mit DX11 erledigt.

Und Crimson ist trotzdem nicht sogut wie nVidia in DX11 Games.

Aber schaut mal drauf und ihr werdet es sehen. Das sind Zahlen und Fakten.

In dem gleichen Artikel stand auch, dass das an der Architektur liegt. NV hat so gute DX11 Treiber weil sie ihre Karten für serielle Fütterung ausgelegt haben. Die Treiber recompilen irgendwas (^^den Artikel hat hier selbst mal jemand verlinkt, ich wünschte ich wüsste wie er heißt) und dadurch entstehen die "Lücken" wie sie bei AMD entstehen nicht. AMD löst das Problem, in dem sie ACEs einbauen, die die Aufgaben auf die verschiedenen Teile der GraKa, um sie dadurch optimal auszulasten. Allerdings müssen diese speziell angesprochen werden. Die Möglichkeit wie bei NV soll nicht gehen, da die Architektur dafür nicht gemacht ist (lt. Artikel).

Ich rede auch nicht von Treiber allgemein, sondern Spielabhängigen Treibern. Aber trotzdem denke ich, dass zu viel auf Treiber und zu wenig auf Architektur begründet wird. Aber im Endeffekt haben weder du noch ich genug Einsicht (& Verständnis) in Architektur und Treiber von AMD und NV, so kann man nur (begründet) spekulieren.

Auf Hardwareluxx wird das thematisiert. DX11 und AMD. Steht weit vorne.

Unter Grafikkarten. Einfach mal durchlesen. Das sind User die testen.

9Strike schrieb:

Ich würde das nicht auf den Treiber schieben, sondern auf die Architektur.

Zum Vergrößern anklicken....

Why not both? Yeaaaahh

Ich glaube ja sowieso, dass Treiber etwas überbewertet werden

Zum Vergrößern anklicken....

Das alleinige Problem sind sie natürlich nicht, aber wenn man sich einige Ergebnisse anschaut, dann denke ich nicht das überbewertet zutrifft.

(wieso z. B. muss für ein Spiel Day1 ein Treiber rauskommen? Kann eigentlich nur den Grund haben, dass die Entwickler was falsch gemacht haben, wo die GraKa Hersteller verbessern müssen).

Zum Vergrößern anklicken....

Teils, teils und API abhängig.
Zum einem können und machen Spiele einige Dinge nicht optimal, zum anderem gibt es aber auch Stellen wo es die Spiele auch nur begrenzt besser machen können, weil der Rest vom Job vom Treiber erledigt wird und je nachdem ist eine andere Ausführung besser oder schlechter, die Kontrolle darüber hat aber der IHV und nicht der ISV.

Ich denke, wir müssen lernen, dass sich Performance nicht mehr nur durch Shaderanzahl und Takt einschätzen lässt, sondern Dinge wie ACEs, Front-End, Tesselations- und Dreiecksberechnung, Speichergeschwindigkeit und Cache Größe auch eine Rolle spielen, anstatt alles auf die Treiber zu schieben. Das wäre dann doch zu einfach. Ich hoffe jedenfalls, das AMD das Problem mit Polaris löst.

Zum Vergrößern anklicken....

Das meiste davon wird aber ständig bei Artikel und Tests angegeben und diskutiert.
Später dann auch mit Polaris, welcher jedenfalls zwei große Front-End-Probleme von AMD anpacken wird, Geometrie-Durchsatz und Command-Processor.

Treiber sind der Treibstoff. Das sagt der Name schon. Die Wirtschaft setzt deswegen NICHT auf AMD.

Marktanteile sagen alles aus. Muss man nicht drüber diskutieren.

Treiber kosten Geld. Die werden nicht einfach so dahingerotzt.

Das nennt man auch SUPPORT.

Ich denke, die Marktanteile spiegeln eher das Konsumverhalten der Nutzer wieder. Weil Apple mehr Smartphones als jeder andere Hersteller verkauft sind sie nicht zwingend besser, oder?

Und wieso sollte die Wirtschaft auf NV setzen? Wegen besseren DX11 Treibern? Wohl kaum, da kommt OpenCL oder CUDA zum Einsatz.

Das was du von dir gibts klingt schon nach fanboy geblubber. Wenn du meinst, AMD würde Treiber hinrotzen, dann mach es doch selbst besser. Weder du noch ich verstehen was davon. Und zum Thema hingerotzte Treiber: Lieber Treiber, die eine etwas schlechtere Performance haben (was sich durch den Kaufpreis aber wieder ausgleicht) als Treiber, die mein PC nicht mehr booten lassen. (mir ist klar, dass das eine Ausnahme war und man das nicht auf alle kommende Treiber wiederspiegeln kann, aber es zeigt, dass es nicht gute Treiber schlechte Treiber gibt, sondern dass das sehr komplexe fehleranfällige Programme sind)



Was den Treiber angeht, klar spielt beides eine Rolle. Aber ich glaube manche machen so grob Shader * Takt = Leistung, jede Abweichung liegt am Treiber. Aber Treiber sind halt nicht:
bugs = 0;
performance = 1.2;

Deswegen finde ich sie überbewertet. Also nicht, dass sie nicht wichtig sind, aber überbewertet im Vergleich zur Architektur.

9Strike schrieb:

In dem gleichen Artikel stand auch, dass das an der Architektur liegt. NV hat so gute DX11 Treiber weil sie ihre Karten für serielle Fütterung ausgelegt haben. Die Treiber recompilen irgendwas (^^den Artikel hat hier selbst mal jemand verlinkt, ich wünschte ich wüsste wie er heißt) und dadurch entstehen die "Lücken" wie sie bei AMD entstehen nicht. AMD löst das Problem, in dem sie ACEs einbauen, die die Aufgaben auf die verschiedenen Teile der GraKa, um sie dadurch optimal auszulasten. Allerdings müssen diese speziell angesprochen werden. Die Möglichkeit wie bei NV soll nicht gehen, da die Architektur dafür nicht gemacht ist (lt. Artikel).

Zum Vergrößern anklicken....

Nvidia hat nicht so gute DX11 Treiber, weil sie ihre GPUs für eine serielle Fütterung ausgelegt haben, sondern weil sie wirklich viele Ressourcen in die Code-Analyse stecken.
Der Treiber ist ein unglaublich komplexes Stück Software und ebenso sind es die Befehle der Spiele, die aus abertausenden Codezeilen folgen.
Es ist unmöglich das irgendeine Seite hier einen optimalen Job erledigen kann und deswegen gibt es immer Patches und neue Treiber.

Der Treiber erledigt eine große Anzahl an Dingen. Die API-Kommandos werden übersetzt (compiliert) und analysiert, welche Daten stehen in welchem Verhältnis, wo könnten mögliche Konflikte auftreten, nach welchem Stück muss das andere folgen.
Und hier gibt es immer soviel Potential etwas besser zu machen.
Der Shader-Compiler im Treiber ist dafür zuständig die Shader zu übersetzen, die Übersetzung ist teilweise aber eher eine Interpretation, weil die Shader abstrakte Konstrukte sind, kann man das mal besser, mal schlechter übersetzen.
Eine schlechte Übersetzung wird dazu führen, dass man mehr Instruktionen ausführen wird als nötig oder "schlechtere" und damit folgt ein höherer Register-Verbrauch und damit weniger Threads und weniger Performance insgesamt und natürlich auch möglicherweise ein höherer Stromverbrauch. (Wobei Perf/Watt bei der Software auch ein Thema für sich ist)
Das ist ein Gebiet wo AMD anscheinend sehr viel Potential für Verbesserungen hat.
Ich beziehe mich hier jedes mal auf den armen Sebastian Aaltonen wenn das Thema aufkommt, aber er als Entwickler hat die Compiler-Ergebnisse von AMDs Shader-Compiler und dem Shader-Compiler auf den Konsolen verglichen und da machen Sony/MS einen scheinbar wesentlich besseren Job.

Neben den reinen Übersetzung muss man natürlich schlaue Strategien haben, wie man die ganzen Abhängigkeiten löst und wie man das alles schnell erledigt und da betreibt jeder Treiber Optimierungen im Hintergrund und es gibt auch Driver-Threads und wie die Aufgaben gesplittet und verteilt werden ist auch eine komplizierte Sache.
Hier sieht man dann eindeutig das Nvidia wesentlich besser als AMD dasteht, da Nvidia das Threading in vielen Fällen besser hinbekommt und eine wesentlich bessere Performance heraus schlägt.

DX12 verlagert viele Aufgaben vom Treiber in die Hand des Entwicklers und damit natürlich auch in die Hand der Person, die am Besten und am meisten Bescheid weiß was sein Spiel eig. machen soll.
(Das klappt aber noch nicht bei jedem Entwickler bisher)
Das hilft natürlich besonders AMD, da der Konzern viel weniger Ressourcen hat und in vielen Bereichen bei der Software ständig nachziehen muss.

MultiEngine bzw. gemeinhin als Async Compute oder Async Shader bekannt, ist dann ein neues API-Konstrukt unter DX12 was dem Treiber eine genauere Definition liefert, was gemacht werden soll.
AMD kann das besonders ausnutzen, da ihre Hardware dank den ACE-Schedulern unabhängig und pro Takt Compute-Pakete an die Shader-Arrays verteilen kann und relativ effektiv Blasen in der Pipeline stopfen.
Das hilft AMD 5-15%, aber auf Seiten der GPU, auf Seiten der CPU-Performance gibt es hier nur wenig Einfluss und definitiv nicht den, den man bei AMD vs. Nvidia oder DX11 vs. DX12 Vergleichen sieht.

Locuza schrieb:

DX12 verlagert viele Aufgaben vom Treiber in die Hand des Entwicklers und damit natürlich auch in die Hand der Person, die am Besten und am meisten Bescheid weiß was sein Spiel eig. machen soll.

Zum Vergrößern anklicken....

Der Entwickler weiß aber nicht, wie er eine bestimmte GPU Architektur am effizientesten auslastet. Dafür muss er zwangsläufig mit dem GPU Hersteller eng zusammenarbeiten, besonders wenn er es mit einer Low Level API zu tun hat.
AMD hat hier auch keinen signifikanten Vorteil. Die Engines werden weiter für DX12 und bestimmte GPU Architekturen optimiert werden und die GPU Hersteller geben den Entwicklern DX12 optimierte Frameworks für einige grafische Effekte.
Wenn alles etwas standardisierter ist, dann kann der Hersteller noch etwas über den Shader Compiler rausholen. Mit der Zeit nimmt an den Entwickler so wieder Optimierungsarbeit ab und auch die Möglichkeit, dass er etwas falsch macht.

Locuza schrieb:

MultiEngine bzw. gemeinhin als Async Compute oder Async Shader bekannt, ist dann ein neues API-Konstrukt unter DX12 was dem Treiber eine genauere Definition liefert, was gemacht werden soll.
AMD kann das besonders ausnutzen, da ihre Hardware dank den ACE-Schedulern unabhängig und pro Takt Compute-Pakete an die Shader-Arrays verteilen kann und relativ effektiv Blasen in der Pipeline stopfen.

Zum Vergrößern anklicken....

Diese Blasen in der Render Pipeline kann man auch ohne Async Compute stopfen, indem die man die Pipeline besser auslastet, falls möglich.
Klar wenn man es wirklich nicht schafft die GPU auszulasten, dann macht Async Compute Sinn.
Die GPUs haben in Zukunft nicht mehr Ressourcen frei, sondern eher weniger, dank immer mehr "Rendering Instructions" durch die WQHD mit 144Hz und 4K Monitore. Async Compute hat wenige Möglichkeiten deutlich bessere Ergebnisse zu liefern, außer in Spezialfällen natürlich.

Wie es aussieht wird DX12 für FX-CPUs in Zukunft Pflicht sein. Kann mir nur recht sein da ich dann meinen 8350 noch 2-3 Jahre weiter verwenden kann. Jetzt nur noch eine Polaris rein und gut ist.

Framinator schrieb:

Treiber werden niemals überbewertet. nVidia hat Shader Cache eingeführt. Und das war und ist genial.

Treiber sind der Treibstoff einer Graka. Da gibts immer was zu verbessern. Plus Ideen der Programmierer. Kostet halt.

Shader Cache bringt bei nVidia soviel das DX12 nichts mehr bringt. Bei nVidia. Bei AMD bringt DX12 was denn deren DX11 Treiber sind ********.

Zum Vergrößern anklicken....

Shader Cache arbeitet am optimalsten dann, wenn es die Entwickler in der Engine implementieren. So war es eigentlich auch gedacht.
Dies im Treiber zu implementieren ist nur ein Notbehelf weil viele Entwickler dies nicht machten.

Mit der Treiber "Optimierung 4 only one Game" wird im wesentlich, neben Multithreading, eine DX schwäche ausgebügelt in dem der Treiber Ressourcen im VRam behält auf die immer wieder zugegriffen wird die aber von DX gelöscht würden/werden. Und genau dies wird mit DX12 nicht mehr nötig sein.

Das Nvidias Shader Cache soviel bringt das DX12 nichts mehr bringt ist Stuss.

Außerdem hat man ja gesehen, dass auch NV Karten im CPU Limit zunehmen. DX12 beinhaltet ja nicht nur neue Grafikkarten Features.

Und Locuza für den ausführlichen Post.

Zum Thema ACEs gab es von AMD mal so eine Folie, die ziemlich gut das Prinzip gezeigt hat. Da die ACEs selbst keine Aufgaben übernehmen sondern nur zuteilen, kann keine Fütterung einer seriellen Pipeline so gut sein wie ACEs. Man kann versuchen die Aufgaben so reinzuschieben, dass kein Teil der GraKa im Leerlauf ist, aber wenn du einfach alle Aufgaben siehst gleichzeitig siehst und dann den Teilen der GraKa im Leerlauf sagst was sie machen sollen, ist das nicht nur effizienter, der Treiber muss auch nicht eine so optimale Fütterung ausarbeiten.

Ist ungefähr so wie wenn du auf einer Baustelle bist und viele Arbeiter hast. Die Aufgaben kommen nacheinander zu dir und du gibst sie weiter an einen Teil der Arbeiter, immer schön nacheinander. Siehst du aber alle Aufgaben gleichzeitig kannst du sie viel besser verteilen. Sind gerade ein paar Arbeiter frei, gibst du ihnen eine kleine Aufgabe, siehst du aber immer nur Aufgabe für Aufgabe hintereinander, musst du warten bis wieder genug Arbeiter für die nächste Aufgabe da sind.
Außerdem kann es ja sein, dass gerade alle den Kran aufbauen, die Betonmischer das aber nicht machen können. Jetzt guckst du einfach was die machen können und musst nicht warten bis die Aufgabe mit dem Kran fertig ist.
Treiber können das ausbügeln, aber es ist halt viel komplizierter sich eine ausgeklügelte Reihenfolge zu überlegen.
(Asynchrone Shader für unnötig zu halten, sich aber bei der CPU Entwicklung über zu wenig Kerne aufzuregen ist übrigens paradox.)

Das ist ein kompliziertes Thema und wird häufig in Schwarz/Weiß-Manier dargestellt.
Vor Vulkan/DX12 gibt es nur eine 3D Queue, dass heißt ein Befehlsstrom.
In der 3D Queue ist alles enthalten, Pixel-Shader, Vertex-Shader, Compute-Shader, dass ist ein großer Salat.
Der Treiber kümmert sich dann darum aus diesem Befehlsstrom die Parallelität so gut es geht auszunutzen.

Hier spielt die Hardware natürlich eine große Rolle, da jede Architektur mit anderen Thread-Größen arbeitet und auch die Verteilungsmechanismen sind sehr unterschiedlich.
AMD arbeitet z.B. mit 64 Threads pro Arbeitspaket, wenn du keine 64 Threads effizient zusammenbekommst, verschwendest du Ressourcen.
Gerade AMD hat mehr Leerlauf als die Konkurrenz, Nvidia arbeitet mit 32 Threads, Intel hat sehr flexible Hardware, dort sind 8-32 Threads möglich, wobei Intel meistens mit 16 arbeitet und für gewisse Aufgaben 8 verwendet.
Hier gibt es dann bei allen Vor- und Nachteile was die durchschnittliche Effizienz angeht und wo der beste Kompromiss auf Seiten der Hardware liegt.
AMD verliert mit der großen Breite im Schnitt Effizienz, braucht aber auch nur einen Verteiler pro 64 Threads, spart Platz und Strom wenn der Workload entsprechend breit ist.

Die ACEs von AMD sind gerade dann gut, wenn es verschiedene Flaschenhälse in der Ausführung gibt, z.B. sind einige Aufgabenbereiche mehr Front-End limitiert (Rasterizer/Geometry-Engines) andere hängen mehr am Back-End (ROPs, Shadow-Mapping).
Hier bietet Vulkan und DX12 die Möglichkeit an extra Compute-Ströme zu definieren, die während der Ausführung genutzt werden können.
AMD ist bisher der einzige Hersteller der 3D Threads und Compute-Threads gleichzeitig laufen lassen kann auf den Shadern.
So kann die Hardware bei 3D Flaschenhälsen Compute-Shader währenddessen einordnen und insgesamt Zeit sparen.
Dieses Konstrukt muss aber definiert werden und braucht Synchronisationspunkte, bei AMD kommt insgesamt ein Plus heraus, bei den anderen nicht, weil es egal ist ob der Befehlsstrom getrennt ist oder nicht, es muss so oder so abwechselnd berechnet werden und das wechseln zwischen 3D-State und Compute-State kostet, schlecht gemacht kann es bei allen drei Herstellern Performance kosten.
Hier wird es auch kompliziert, da jede Hardware unterschiedlich viele Leerphasen hat, unterschiedlich schnell den Arbeitsmodus wechseln kann und der ist bei der Hardware auch unterschiedlich.
Was ein 3D-State bei AMD in der Hardware ist, muss nicht exakt dem von Nvidia oder Intel entsprechend.

Super danke nochmal für die Erklärung
Also ist ist unter anderem die große Anzahl an Threads pro Arbeitspaket an der geringeren Leistung von AMD Karten trotz der theoretisch höheren (Shader) Leistung schuld am "schlechten" Abschneiden, wenn ich das richtig verstehe. Weißt du wie es da mit P & P aussieht, ob sich da was ändert?

Nur eins hab ich jetzt noch nicht so richtig verstanden: Hilfen ACEs jetzt bei der Lösung des oben genannten Problems oder geben sie Leistung unabhängig davon frei?
Wenn ich das richtig verstanden habe, können ACEs also Shadern "schnell" einem anderen Arbeitsbereich zuordnen, der gerade limitiert.

Woher weißt du das eigentlich? Mich interessiert das Thema echt und überlege mir auch irgendwas in die Richtung zu studieren, aber bis auf mehr oder minder informative Artikel von Tech Seiten bzw Kommentare habe ich bisher nichts gefunden (zugegebenermaßen hab ich auch noch nicht intensiv danach gesucht).

Es ist immer ein möglicher Teilgrund und nie steht etwas ganz für sich allein.
Die Thread-Group-Size von 64 hat AMD mindestens seitdem R600 (2900) und Nvidia auch mindestens seitdem G80 (8800) und mit P&P bleiben beide dabei.
Die ALU-Anzahl pro Cluster und die Scheduler haben sich allerdings immer verändert und auch wie viele Ressourcen pro Cluster zur Verfügung stehen, also Register und Cache.
Das alles hat Auswirkungen auf die praktische Performance.
Daneben ist nicht alles ALU limitiert, das Front-End und Back-End spielt natürlich auch eine wesentliche Rolle beim 3D Rendering.
Ich habe wo anders entsprechende Beiträge geschrieben:
http://extreme.pcgameshardware.de/n...070-angeblich-abgelichtet-11.html#post8173063
http://extreme.pcgameshardware.de/n...070-angeblich-abgelichtet-11.html#post8173109

Pascal verbessert auf jeden Fall die Granularität (Feinheit) beim Wechseln vom Arbeitsmodus, bisher musste Kepler und Maxwell immer warten bis ein ganzer Thread-Block bearbeitet wurde, bis er was anderes machen konnte.
Bei Pascal kann Nvidia es dann auf dem Instruktionslevel machen.
Ansonsten weiß man seit der Vorstellung vom P100 das Nvidia pro Cluster 64 ALUs hat, 256 KB Vector-Register und 64 KB shared-memory, dass wird dann die praktische Performance der Shader verbessern.
Darüber hinaus gibt es aber keine Informationen, was z.B. das Front-End und Back-End angeht.
Ist die Tessellation-Leistung besser geworden? Unterstützt der Rasterizer jetzt auch Conservative Rasterization Tier 3?
Wo hält die Architektur ihre Daten und wie frei können diese verwendet werden?
Das müssen wir noch etwas abwarten, aber der GP104 scheint nur noch wenige Monate entfernt zu sein.

Bei Polaris hat AMD wenigstens ein paar grobe Stichwörter ausgespuckt. AMD hat den Instruction-Buffer vergrößert, dass erhöht dann die praktische Leistung der Shader.
AMD unterstützt anscheinend auch das vorladen von Instruktionen, dass verbessert dann natürlich auch die Performance.
AMD verbaut einen neuen Command-Processor, dass verbessert, man kann es kaum glauben, auch die Performance.
AMDs bisheriger Command-Processor ist etwas zu schwach, wenn sehr viele Anweisungen verwendet werden.
Bei den Geometry-Engines hat AMD new hingeschrieben, man darf wesentlich bessere Tessellation-Performance erwarten und ebenso einen höheren Dreiecksdurchsatz, wichtig für Vertex-Shader, Geometrie in der Spielwelt.
Dazu noch ein überarbeiteter L2$, bessere Speicherkompression und damit eine bessere Bandbreitenausnutzung.


Stichwort ACEs.
Die ACEs kümmern sich einzig und allein um Compute-Queues, die Aufgaben der Compute-Shader enthalten.
Der Vorteil ist einfach das du mehrere Befehlsströme hast und das dann etwas effizienter mixen kannst.

Wissen häuft man sicher über die Zeit von Seiten (Computerbase, PCGH, Anandtech), Artikeln und Foren (3DCenter, Beyond3D) an, andere beschäftigen sich natürlich beruflich damit.
Wenn dich das Thema interessiert, Studienplan anschauen, es kann mehr Richtung Hardware-Design, Mikroelektronik gehen oder mehr Richtung Programmierung.
Je nachdem studierst du dann eben Elektrotechnik, Informationstechnologie oder eher Informatik.
Einige Studiengänge bietet auch Chemie und Physik als Hauptfächer an, wo du später Wahlfächer mit Informatik kombinieren kannst.
Ein Duales-Studium oder eine Ausbildung ist natürlich praktischer und weniger wissenschaftlich orientiert.

9Strike schrieb:

Mich interessiert das Thema echt und überlege mir auch irgendwas in die Richtung zu studieren, aber bis auf mehr oder minder informative Artikel von Tech Seiten bzw Kommentare habe ich bisher nichts gefunden (zugegebenermaßen hab ich auch noch nicht intensiv danach gesucht).

Zum Vergrößern anklicken....

Der eine Weg ist ein Informatikstudium auf einer Universität:
Z.B. kannst du ein Informatik Studium machen und dich während des Studiums auf "technische Informatik" bzw. Hardware Engineering fokusieren (das geht teilweise im Bachelor und wird im Master vertieft).
Dazu kann man die Fächer belegen die in die Richtung Computer Grafik und Visualization gehen. Ich habe z.B. in meinem Master Studium ein Fach belegt, in dem wir ein 3D Strategiespiel entwickelt haben mit der JMonkey Engine. So hättest du ein sehr breites Spektrum abgedeckt: Die mathematischen Grundlagen, wissenschaftliche Herangehensweise, Software und Hardware Entwicklung. Das kann man dann mit einem Nebenfach verbinden um sich noch weiter zu bilden...

Ein anderer Weg wäre ein Studium in Richtung "Elektrotechnik-" Engineering, wenn man sich wirklich auf Halbleiter- Engineering spezialisieren möchte (was Locuza bereits erwähnt hatte).

9Strike schrieb:

Nur eins hab ich jetzt noch nicht so richtig verstanden: Hilfen ACEs jetzt bei der Lösung des oben genannten Problems oder geben sie Leistung unabhängig davon frei?
Wenn ich das richtig verstanden habe, können ACEs also Shadern "schnell" einem anderen Arbeitsbereich zuordnen, der gerade limitiert.

Zum Vergrößern anklicken....

Die ACEs haben nur dann einen wirklichen Mehrwert, wenn die GPU mit der Berechnung von Rendering Instruktionen nicht voll ausgelastet ist. Dann kann man parallel non Rendering (Compute) Instruktionen durch die Pipeline schieben, die von den Shadern berechnet werden. Doch wenn die GPU voll ausgelastet ist, dann bleiben kaum Ressourcen die man parallel für Compute Instruktionen nutzen könnte. Und wenn die GPU noch Ressourcen frei hat, dann könnte der Grund dafür sein, dass die Rendering Instruktionen ineffizient abgearbeitet werden. Im Resultat ist das Ergebnis dann zwar besser mit Async Compute, doch wenn die Konkurrenz ihre GPU einfach besser mit Rendering- Instruktionen auslasten kann, dann hat sie auch mehr Luft um einen context switch für Compute Befehle auszuführen. Doch so ein context switch kann unterschiedlich hohe Kosten haben, abhängig von der Architektur. Dies erwähnte Locuza im Zusammenhang mit Pascal Spekulationen die aktuell kursieren, dass man die context switch Kosten eventuell reduzieren konnte.

Soweit klar? Weißt du was ein task switch bzw. context switch ist?

DX12 funktioniert bei Hitman nun nicht mehr.
Gab zwar ein Steam Update mit dieser Info: News - All News
Aber DX12 ist nun komplett hinüber. Wenn man das Spiel in DX12 öffnen startet es halt Hintergrundprozess und nichts weiter passiert.
Langsam wirds lächerlich.