Framinator
Software-Overclocker(in)
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?
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.
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.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.
Why not both? YeaaaahhIch würde das nicht auf den Treiber schieben, sondern auf die Architektur.
Das alleinige Problem sind sie natürlich nicht, aber wenn man sich einige Ergebnisse anschaut, dann denke ich nicht das überbewertet zutrifft.Ich glaube ja sowieso, dass Treiber etwas überbewertet werden
Teils, teils und API abhängig.(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).
Das meiste davon wird aber ständig bei Artikel und Tests angegeben und diskutiert.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.
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.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).
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.
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.
Shader Cache arbeitet am optimalsten dann, wenn es die Entwickler in der Engine implementieren. So war es eigentlich auch gedacht.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 ********.
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).
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.