[split] GPU-Architekturen über die Zeit

[gravitationsfeld]

Die 7970 war ihrer Zeit dafuer aber auch Jahre voraus. Das ist immer noch die Basis bis hoch zur Xbox One X.

split von hier (https://www.forum-3dcenter.org/vbulletin/showthread.php?p=11557340#post11557340)

[Ex3cut3r]

Guten Morgen.

Ja sicher, der Highend Chip von AMD kam am Performance Chip von Nvidia (GTX 680 eigentlich eine unbenannte GTX 660) nicht vorbei. Heute sind beide Krüppel. Aber warte mal das ist leider schon wieder der Fall, Vega Highend vs Pascal Performance Chip. Traurig. AMD ist imo mittlerweile 2 Jahre zurück, allein der Effizienz Unterschied ist gewaltig.

[robbitop]

Wenn die 7970 einen anständigen Shadercompiler bekommen hätte, wäre gk104 toast gewesen. Man sieht ja was GCN kann, wenn man den compiler umgeht. Siehe doom oder wolfenstein 2. Außerhalb vom vram Limit (6 gb version zB) hat Kepler bei vergleichbarer Transistorzahl unter dieser Bedingung vermutlich kaum eine Chance.
Die xbox one x packt mit sehr ähnlicher mArch und Rechenleistung die modernen Titel in 1440p oder gar 4K oder 4K Checkerboard.

Die HW war schon ziemlich krass für 2011. Leider war es die Software nie. Bei einer Konsole relativ egal, da man hw spezifisch optimieren kann.

[Hübie]

Ohne Frage war und ist die µArch flexibel sowie leistungsfähig, aber mittlerweile erfährt Kepler eben keine Optimierungen mehr, weshalb man eine Vergleichbarkeit der Leistung nicht richtig anstellen kann sondern lediglich die Situation vergleichen kann (GCN sind jeweils kleinere Iterationen vom Aufbau als NVIDIA's Modelle). Hat mit dem Thema hier allerdings wenig zu tun (auch wenn es spannend ist).

[robbitop]

Das mit dem Treiber stimmt. Kepler ist altuell auch schon zu krass in aktuellen Titeln abgesunken. Keine langfristige Treiberliebe.

Aber: Auch ggü MXW und Pascal beweist GCN in diesen Titeln (die Offenbar die Unzulänglichkeiten des Shadercompilers aushebeln) relativ nahe rohleistungsnormierte Performance. Pro gflop liegt man ~auf mxw Niveau. Und jeder weiss, dass mxw grob 30% oberhalb Kepler lag rohleistungsnormiert. Tahitii hätte folglich 2011 bereits mit anständiger SW (shadercompiler) ein gutes Stück oberhalb gk104 kämpfen können. -gk100 Niveau wäre nicht undenkbar gewesen. Wenn nichts die mArch zurückgehalten hätte.
Ich nehme an, dass das soziemlich mit der Kernaussage von gravitationsfeld einhergehen sollte.
Er sollte gcn und auch maxwell sehr gut einschätzen können. Vermutlich auch Kepler... ;)

Aber gut - ist tatsächlich OT

[VooDoo7mx]

Sorry der vergleich hinkt.

Tahiti hat 33% mehr Recheneinheiten, 33% dickeres Speicherinterface und 50% mehr Speicher standardmäßig als ein GK104.
Und jetzt kommt die Überrraschung das der Chip schneller ist. Unglaublich.

Das liegt nicht daran, dass nVidia den Kepler Treiber schlecht pflegt, sondern das der Treiber wie bei nVidia üblich schon vom Start her fast alles aus der Karte rausgeholt hat. AMD Treiber ist wie immer crap am Start und kann erst über die Jahre die Rechenleistung der Karte freilegen.

Das hat also rein gar nichts mit schlechter Treiberpflege seitens nVidia zu tun sondern eher damit das AMD ihren Treiber über die Jahre auf das gleiche Niveau wie nVidia gebracht haben.

[=Floi=]

Das mit dem Treiber stimmt. Kepler ist altuell auch schon zu krass in aktuellen Titeln abgesunken. Keine langfristige Treiberliebe.

beweise?!

Es laufen aktuelle spieler super auf kepler. Es gibt keine grafikfehler oder abstürze!
Der vram wird zum problem und die architektur ist einfach ineffizient. Das kann auch der beste treiber nicht retten. Angesichts des alters der karte noch immer ganz gut.

kepler bringt die shaderleistung nicht auf den boden.

[robbitop]

DF/hwunboxed (?) hatte ein Video dazu. Habe aktuell aber ein zu schlechtes Inet zum suchen. Man sah in dem Video dass gk100 ggü maxwell in der Mehrzahl der neuen AAA Titel immer stärker abrutscht.
edit: UE4 mag eine Ausnahme ein - aber wie viele AAA Titel nutzen die UE4?

@voodoo
Nichts anderes habe ich gesagt. Nur im „Ton“ etwas anders.
Ich würde schon sagen, dass gcn pro gflop in doom/wolfenstein (also ohne limitierung durch compiler) oberhalb von Kepler - eher Richtig Maxwell liegt. Dass AMDs SW Abteilung hier die HW zurück hält wurde mehr als 1x konstatiert. Das ist auch bis heite der Grund, warum ich privat zur Geforce greife. Immer sehr guter Treiber - sofort. Meistens. Und ich rüste zur Nachfolgegegenerqtion immer auf, so dass ich nicht von langfristiger Treiberliebe hätte. Kann aber auch andere Perspektiven verstehen und abwägen. Ich hoffe, dass AMD da auch hinkommt. Ein ausgewogener Wettbewerb ist für den Kunden das beste.
Ich halte es für das Beste alle Seiten differenziert zu beleuchten. Dazu gehört es auch anzuerkennen, welches Potenzial AMD mit GCN 2011 hatte (aber dank sw nicht voll heben konnte damals). Gut für Langzeitkäufer jedoch. Eine 7970 scheint selbst heute (mit etw reduzierten Texturdetails) eine immernoch ganz passable 1080p Karte zu sein. Bei einer 680 müssten vermutlich mehr Abstriche getan werden.

Aber genug davon - wir sind OT.

[aufkrawall]

Stimmt so pauschal aber nicht, UE4 etwa liegt Kepler auch in der neusten Version immer noch gut.

[Hübie]

Wir reden nicht von einer Rosine sondern eine Tüte Rosinen. Und da ist Kepler eben schlechter geworden, da Spiele (-engines) nicht mehr mit Kepler im Hinterkopf vom Treiberteam optimiert werden. Selbst bei Maxwell hört es langsam aber sicher auf.

[robbitop]

@huebie
zu dem Thema passendes FYI:
Coda hatte iirc mal erwähnt, wie es mit der Optimierung läuft: es wird seitens nv kaum die march dokumentiert sondern um pre-release code (frühestmöglich) gebeten mit der Aussage, dass NV das per Treiber geradebiegt. Das Studio hat also offenbar weniger Einsicht und somit Optimierungsmöglichkeiten auf eine spezifische nv mArch, als man denken könnte. :)

Bei W3 sah man ganz gut, dass Kepler zunächst vernachlässigt wurde und ungewöhnlich schlecht darstand. Später kamen per Treiber Optimierungen nach, die Kepler sehr halfen in W3.

[aufkrawall]

Hab mich schon zig Mal zu W3 geäußert: Es kamen auch Performance-Optimierungen für Kepler via Spielepatch. Aber es bleibt halt nur das hängen, was hängen bleiben will...
Klar ist Kepler nicht mehr frisch, schlechter als er ist muss man ihn aber auch nicht reden.

[robbitop]

Es gab immerhin 1st Hand Erfahrungen von Entwicklern von Crytek hier im Forum die die These erhärten.

Wieviel Performance kam denn bei dem Patch, die rein exklusiv Kepler geholfen hat? (höre/lese ich zum ersten Mal - was nicht heissen soll, dass ich abstreiten will dass du es schon mehrfach irgendwo gepostet hast)
Rein exklusiv durch das Treiberupdate (unabhängig vom Patch) war es jedenfalls iirc ziemlich nennenswert...

[Hübie]

Hab mich schon zig Mal zu W3 geäußert: Es kamen auch Performance-Optimierungen für Kepler via Spielepatch. Aber es bleibt halt nur das hängen, was hängen bleiben will...
Klar ist Kepler nicht mehr frisch, schlechter als er ist muss man ihn aber auch nicht reden.

Das war 2015 - zwei Jahre sind seit dem ins Land gestrichen. Die 780 Ti -
oder generell GK110 - performt deutlich schlechter als diese es noch zu Maxell-Zeiten tat. Tendenz: sinkend. Vergiss nicht dass das Ding 2880 ALUs und n fettes 384 Bit MI hat. Wenn Maxwell momentan mit beschleunigt wird liegt es wahrscheinlich eher daran, dass vieles Pascal ähnelt. Bei Kepler sieht das eben anders aus.

@robbitop: Das kann ich sogar bestätigen und sehen wir ja auch an Christoph's Beiträgen. Man erhält wenig bis keine Infos, aber einen super Support, wenn man Probleme hat. Aber wie die etwas fixen ist Verschlußsache. Skysnake kennt das auch.

[scully1234]

Das mit dem Treiber stimmt. Kepler ist altuell auch schon zu krass in aktuellen Titeln abgesunken. Keine langfristige Treiberliebe.


T

Falsch


https://youtu.be/GBkGu4Wd7vg

[robbitop]

Linustechtips? Ernsthaft? Da glaube ich eher DF.

[HOT]

Von der ganzen Diskussion abgesehen finde ich es aber auch normal, dass ein Hersteller den Support von alten Chips, jedenfalls aus Performancesicht, nicht mehr sonderlich voranbringen möchte. Das lohnt sich einfach nicht. AMD war ja noch krasser und schickte alles vor GCN sehr zügig in den Legacy-Support, auch die grade frisch erschienen Richlands damals :freak:.
Wär Tahiti nicht vom Grundsatz her GCN, würde der heute auch nicht mehr so gut supportet werden. Solange man aber Polaris weiterhin gut supportet werden auch die Vorgängerchips davon profitieren. Wie ich allerdings AMD einschätze ist es damit jäh vorbei, sobald das ganze Lineup nur noch Vega-GCN ist, dann sind die schneller im Legacy als man gucken kann. Kepler hat halt das pech keine aktuelle Architektur zu sein.

[robbitop]

Die Einschätzung kann ich zu 100% teilen. :)
Sollte auch nicht als Vorwurf sondern lediglich als Feststellung gemeint sein. MXW profitiert sicherlich aufgeund seiner Ähnlichkeit von Pascals Optimierungen. Wenn er Glück hat, ist Ampere ähnlich genug um noch weiter zu partizipieren.

es war wohl hwunboxed: https://m.youtube.com/watch?v=6eNVv2yhDVE

„GTX 780, How The Mighty Have Fallen!“

Kann das Video wg temporär schlechten Inet nicht prüfen - habe ich per googlesuche gefunden. Ich habe es vor einer ganzen Weile mal gesehen und da sieht man wie schwer sie sich in aktuellen titeln schlägt.

[Ex3cut3r]

https://m.youtube.com/watch?v=6eNVv2yhDVE

„GTX 780, How The Mighty Have Fallen!“


Halte ich für Schwachsinn, 3GB sind für 1440p und auch 1080p in aktuellen Spielen viel zu wenig. Mit angepassten Settings und High oder Medium Texturen die eben den Speicher nicht vollmachnen, läuft das immer noch entsprechenend. Wobei wieder dann wieder beim Thema Ampere sind, ich will bei der 1170/1180 oder 2070/2080 16GB GDDR6 sehen, alles andere ist eine kleine Enttäuschung für mich, eigentlich wirds auch so kommen, GTX 980 - 4GB - GTX 1080 - 8GB.....GTX 2080 - 16GB. (=

m6mQa6LOoPE

Hier sieht eine 780Ti Kepler sehr gut aus. Wie vergleichbar das jetzt runter zur 680 ist, kann sich jeder selbst runterechnen.

[gravitationsfeld]

Das liegt nicht nur am RAM. Kepler hat schon so einige Probleme mit modernen Shadern.

Wenn die 7970 einen anständigen Shadercompiler bekommen hätte, wäre gk104 toast gewesen.
Oh ja. Der AMD-Compiler ist bis heute nur so mittelmaessig.

[scully1234]

es war wohl hwunboxed: https://m.youtube.com/watch?v=6eNVv2yhDVE

„GTX 780, How The Mighty Have Fallen!“

Kann das Video wg temporär schlechten Inet nicht prüfen - habe ich per googlesuche gefunden. Ich habe es vor einer ganzen Weile mal gesehen und da sieht man wie schwer sie sich in aktuellen titeln schlägt.

Aha eine Karte mit 3GB Vram und schlechterer Texturkompression wird also an ihre Kotzgrenze gebracht, gegen die neuere Architektur

Und das soll jetzt was belegen? Die "schlechtere" Treiberpflege, oder wie gut die Kompression mittlerweile bei Pascal funktioniert mit identischem Vram:eek:

Aber Linus kann nix mit seinen weitaus größeren Test, und das hier wird einfach so kommentarlos geschluckt, ohne Nachdenken


Aber der geht wenigstens darauf ein

https://youtu.be/GBkGu4Wd7vg?t=254

[aufkrawall]

Viele vergessen halt, dass die 780 bis zu 30% OC mitmachte. Und wo gibts schon Tests mit 6GB und OC?
Ist halt etwas akademisch, weil kaum jemand so eine Karte hat(te). Akademisch ist aber auch AC: Origins mit max. Details in WQHD auf einer 290X. Und in 1080p ging Hawaii vor ein paar Jahren gegen OC-GK110s in wichtigen Spielen wie BF4 einfach nur unter, das sollte man dann vielleicht auch nicht vergessen...

[gravitationsfeld]

Aha eine Karte mit 3GB Vram und schlechterer Texturkompression wird also an ihre Kotzgrenze gebracht, gegen die neuere Architektur

Und das soll jetzt was belegen? Die "schlechtere" Treiberpflege, oder wie gut die Kompression mittlerweile bei Pascal funktioniert mit identischem Vram:eek:

Aber Linus kann nix mit seinen weitaus größeren Test, und das hier wird einfach so kommentarlos geschluckt, ohne Nachdenken


Aber der geht wenigstens darauf ein

https://youtu.be/GBkGu4Wd7vg?t=254
Die Kompression von der du redest verbraucht mehr VRAM, nicht weniger. Es geht darum Bandbreite zu sparen, nicht Speicher.

Es gibt auch keine "schlechtere Texturkompression". Seit DX11 hat sich an den unterstuetzten Formaten nichts geaendert (ausser ASTC auf den mobilen Chips). Die "Kompression" die du meinst ist fuer color/depth targets.

[robbitop]

@scully
Wo ist die Texturkompression schlechter? DCC hat nichts mit vram Ersparnis zu tun.
In 1080p scheint es kaum einen vram bottleneck mit 3gb zu geben. Die 1060 mit egb laesst sich anscheinend naemlich nicht beirren.

[fondness]

Wir reden nicht von einer Rosine sondern eine Tüte Rosinen. Und da ist Kepler eben schlechter geworden, da Spiele (-engines) nicht mehr mit Kepler im Hinterkopf vom Treiberteam optimiert werden. Selbst bei Maxwell hört es langsam aber sicher auf.

Kepler hat viel zu wenig effektive Rechenleistung, da hilft der Treiber auch nicht mehr.

Man sieht ja was GCN kann, wenn man den compiler umgeht. Siehe doom oder wolfenstein 2.

Wie kommst du darauf, dass Doom oder Wolfenstein 2 den "Kompiler umgeht"?

[gravitationsfeld]

Tun sie nicht. Geht auch gar nicht.

[fondness]

Eben.

[aufkrawall]

Kepler hat viel zu wenig effektive Rechenleistung, da hilft der Treiber auch nicht mehr.

Dafür gibts Takt, und die ALUs skalierten schon besser als bei GCN. Auch deshalb vetrimmt ein voller GK110 ja auch GK104 so. GK104 war echt Banane und profitierte nur davon, dass GCN damals einfach nicht klever ausgelastet wurde.

[robbitop]

Auf einer gdc Praese von id stand mal sinngemaes etwas aehnliches. Vieleicht nicht nicht direkt “umgehen”. Ggf wird er (inkl seiner Schwaechen) besser in Betracht gezogen und sortiert gefuettert. Das kann einer der anwesenden devs sicher besser erklaeren. Die Auslastung der ALUs stieg jedenfalls nennenswert und kam ca an mxw heran statt nur auf Kepler Niveau.

[fondness]

Auf einer gdc Praese von id stand mal sinngemaes etwas aehnliches. Vieleicht nicht nicht direkt “umgehen”. Ggf wird er (inkl seiner Schwaechen) besser in Betracht gezogen und sortiert gefuettert. Das kann einer der anwesenden devs sicher besser erklaeren.

AFAIK hat man sich beschwert, dass der Compiler Mist baut im Vergleich mit der PS4 und so viel Leistung brach liegt. Das heißt aber nicht, dass man das ändern konnte.

[robbitop]

Schau dir die Leistung bezogen auf die vorhandene Rohleistung im Vergleich zu anderen Spielen an. Ganz offensichtlich hat man da etwas tun koennen.

[gravitationsfeld]

Ausser AMD den ganzen Tag zu nerven kann man da nichts machen ;)

Das gilt uebrigens auch fuer gruen, nur bei anderen Sachen.

[fondness]

Schau dir die Leistung bezogen auf die vorhandene Rohleistung im Vergleich zu anderen Spielen an. Ganz offensichtlich hat man da etwas tun koennen.

Das liegt an ganz anders Dinge wie den Shader Intrinsics, der besseren Ausnutzung der Skalar-Unit, Async Compute, etc. Aber sicher nicht an irgendwelche Compiler-Tricks. id schriebt sicher keinen Manschinencode oder gar Microcode.

[robbitop]

Shaderintrinsics bypassen entsprechend Abstraktionsebenen. Dass das nur auf bestimmte Instruktionen zutrifft, ist klar.

[fondness]

Shaderintrinsics bypassen entsprechend Abstraktionsebenen. Dass das nur auf bestimmte Instruktionen zutrifft, ist klar.

Der Compiler wird trotzdem nicht umgangen. Intrinsics sind für den Compiler aber natürlich sehr einfach zu verarbeiten und erlauben eine möglichst optimale Ausnutzung der HW.

[robbitop]

Tomato, Tomato. ;)

[gravitationsfeld]

Nein, er hat voellig recht. Der Grossteil der Probleme beim Compiler ist die Register-Zuteilung und die wird davon nicht beeinflusst. Die Intrinsics machen vielleicht auch nur 1% des Codes aus. Wir schreiben nicht tausende Zeilen in intrinsics :ugly:

Uebrigens geht das auch gar nicht, die Intrinsics am PC sind nur fuer einen Bruchteil des Instruction-Sets, an den man sonst nicht ran kommt.

[robbitop]

Interessant. :) und das ist @Konsole dann komplett in der Hand des Devs?

[gravitationsfeld]

Noe, die Compiler sind halt deutlich besser. Einer der beiden sogar noch mal besser als der andere. Darfst raten welcher.

[Locuza]

Laut Twitter-Dev-Feed generiert der Compiler von Sony die besten Ergebnisse.

[Tesseract]

Kepler hat viel zu wenig effektive Rechenleistung, da hilft der Treiber auch nicht mehr.

die gewichtung war halt anders. über die generationen und alle performanceklassen (inkl. konsolen) hinweg ist die ALU-leistung schneller gewachsen als füllrate oder bandbreite und dementsprechend ändert sich auch die gewichtung in den spielen. da hat die architektur mit weniger ALU-leistung schon prinzipiell einen schweren stand, selbst wenn der treibersupport noch mithalten würde. fermi ist aus ähnlichen gründen noch viel stärker abgestürzt - bandbreite und ROP-durchsatz um saufüttern aber dafür verhungert er in anderen breichen.

[Der_Korken]

Man eine blöde Frage: Wenn die Compiler für die Konsolen so viel besser sind, warum kann man nicht etwas davon auf den PC portieren? Für mich klingt das ziemlich nach low hanging fruits, zumindest für alles bis einschließlich Polaris.

[Locuza]

Microsoft und Sony haben Angestellte die am Compiler für ihre Plattform arbeiten, ebenso wie für den restlichen Software-Stack aus unterschiedlichen APIs usw.
Das ist dann ihr Besitztum und AMD hat natürlich keinen direkten Zugriff auf deren Compiler-Arbeiten.

[gravitationsfeld]

Vor allem haben sie auch kein Interesse daran, dass Spiele auf dem PC besser laufen.

[Der_Korken]

Achso, MS und Sony haben die Compiler geschrieben. Das ist natürlich bitter, wenn fremde Firmen für die eigene Hardware bessere Compiler schreiben. Ist es denn realistisch, dass AMD hier jemals nachlegt, wenn die Probleme im Prinzip schon seit GCN 1.0 bestehen?

[Locuza]

Da es "nur" Software darstellt, könnte AMD jeder Zeit nachbessern.
Wie immer steht dem die Kosten/Nutzen-Rechnung gegenüber.
AMD hat begrenzte Ressourcen und es gibt auch nur einen begrenzten Pool an gutem Fachpersonal, entsprechend wird sich dort von Heute auf Morgen sehr unwahrscheinlich etwas tun.

Primär werden wohl AMDs zukünftige Finanzaussichten und ihre Investitionen darüber bestimmen, wie sehr AMD diesen Bereich intern ausbauen kann, dann stellt sich zeitlich aber die Frage, welche Hardware davon profitieren wird und was AMD dann schon in den Legacy-Status "verbannt"?

[gravitationsfeld]

Wobei es AMD eigentlich einfach hat. Die GCN ISA ist seit Tahiti 95% unveraendert. Man hat den FP16-Kram, aber der ist meiner Meinung nach eh oft unbrauchbar (nicht nur bei AMD).

[pixeljetstream]

Das ist natürlich bitter, wenn fremde Firmen für die eigene Hardware bessere Compiler schreiben.

Richtig gute Compilerleute sind sehr rar und es skaliert auch nicht trivial einfach mal manpower drauf zu werfen.

Außerdem kann so ein Team für die Konsolen sich auf genau ein ISA bzw. jetzt zwei, von genau einem frontend voll einschießen. (Eigene Expertise senkt den Preis was man lizensieren muss und macht unabhängiger).

Die Teams der IHVs müssen sich stärker um N Generationen kümmern von unterschiedlichen frontends (sprachen etc. wobei viele wohl llvm nutzen).

[Ex3cut3r]

Auch ein ganz interessantes Video:

BfSi-Z8r12M

Die Überlegenheit der 7970 heute, sehe ich da immer noch nicht.

Das AMD Karten über die Jahre besser werden und die Geforce Konkurrenten der gleichen Leistungsklasse von damals deklassieren, halte ich schon lange für einen immer wieder falsch verbreiteten AMD Foren Mythos. ;)

[robbitop]

Haengt offenbar von der Spieleauswahl ab. Im von mir geposteten Video wird die 780 von Grenada deutlich geschlagen. Und das obwohl die ALU Anzahl praktisch gleich ist. Die Spieleauswahl war größtenteils eine deutlich andere.

[Lehdro]

Bei der ganzen Testerei fehlt folgendes völlig:

- Tests mit aufgebohrten Versionen
Insbesondere Versionen mit verdoppelten RAM könnten hier ein bisschen Licht ins Dunkel bringen: Die Original Titan, Titan Black und die GTX 780 6GB sind heutzutage teilweise spürbar schneller als ihre damaligen Leistungsgenossen (GTX 780, GTX 780 TI). In dem PCGH Artikel über die "GPU Legenden" hat man das mit der vanilla Titan sehr schön gesehen, die holt immer und immer mehr auf die 780 TI auf, trotz niedrigerer Taktraten, weniger Shadern und niedrigerer Bandbreite.
Ansonsten darf man nie vergessen wie gut Kepler mit manuellen OC nach oben skalierte, da die Taktraten sehr konserativ angelegt waren. 30% OC wurde hier ja schon öfters erwähnt, das war keine Seltenheit wenn nicht schon vom Hersteller ans Limit getrieben.

- Tests von GK110 gegen GK104 mit passendem Umfeld
Am besten dort 2 + 4GB GK104 (GTX 770 4GB) gegen 3 + 6GB GK110 (Titan, 780 6GB, Titan Black) um zu sehen ob es generell an der Architektur liegt, oder ob es dort noch woanders hakt. Zum Vergleich eine 7970 + die 6GB Version der 7970 rein. Abrunden mit einer GTX 980 und einer R9 290X. GTX 970 halte ich durch die RAM Eigenheit für eine äußerst schlechte Wahl.

Ansonsten: Mir fallen noch drei weitere NV Architekturen ein die äußerst schlecht gealtert sind:

Geforce FX: Schon Scheisse am Start, unbrauchbar kurz darauf.
Geforce 7: Gegen die 1900er Serie von ATI keinen Stich nach kurzer Zeit, da fehlte einfach Shaderleistung ohne Ende in moderneren Titeln.
GTX 480 & 580: Wurde hier schon erwähnt, da passte später gar nichts mehr. Ging aber der AMD Konkurrenz (pre GCN) genauso - einfach fallen gelassen von allen Seiten.

[HOT]

Achso, MS und Sony haben die Compiler geschrieben. Das ist natürlich bitter, wenn fremde Firmen für die eigene Hardware bessere Compiler schreiben. Ist es denn realistisch, dass AMD hier jemals nachlegt, wenn die Probleme im Prinzip schon seit GCN 1.0 bestehen?
Nein, ich denke nicht. Besserung wird es ab Vega geben. Alles bis Polaris wird man nicht mehr großartig verändern mMn. Ich schrieb ja schon ein paar Seiten weiter vorne, sobald das komplette Lineup Vega/Navi ist (also Mitte 2019 schätzungsweise werdem mMn alle Chips draußen sein), geht alles bis Polaris sowieso legacy.

[Ex3cut3r]

Haengt offenbar von der Spieleauswahl ab. Im von mir geposteten Video wird die 780 von Grenada deutlich geschlagen. Und das obwohl die ALU Anzahl praktisch gleich ist. Die Spieleauswahl war größtenteils eine deutlich andere.

Eine 290 ohne X mit 4GB gegen die GTX 780 wurde wohl eher passen. Leider ist die in deinem verlinkten Video nicht drin. Vlt. ist in 1440p auch schon der Speicher voll, die 390 von AMD wurde in der 8GB Version getestet.

https://abload.de/thumb/4a2585d2-ddcd-48ae-a2t2pyg.png (http://abload.de/image.php?img=4a2585d2-ddcd-48ae-a2t2pyg.png)

[robbitop]

Sind aber auch 1080 bnches dabei, an der sich die 1060 mit 3gb nicht zu stören scheint. VRAM kann dort also nicht ganz so kritisch sein. Auch dort schlägt Grenada Gk110.
Ansonsten gebe ich Lehdro Recht.

[Ex3cut3r]

Fuck, das es sich um eine GTX 1060 in der 3GB Version handelt, habe ich gar nicht gesehen, ja dann nimm ich mein Argument natürlich zurück, aber jetzt wirkt das Ergebnis sehr suspekt, GTX 780 schlecht gealtert, GTX 680 nicht... :freak:

[Hübie]

Bei der ganzen Testerei fehlt folgendes völlig:

- Tests mit aufgebohrten Versionen
Insbesondere Versionen mit verdoppelten RAM könnten hier ein bisschen Licht ins Dunkel bringen: Die Original Titan, Titan Black und die GTX 780 6GB sind heutzutage teilweise spürbar schneller als ihre damaligen Leistungsgenossen (GTX 780, GTX 780 TI). In dem PCGH Artikel über die "GPU Legenden" hat man das mit der vanilla Titan sehr schön gesehen, die holt immer und immer mehr auf die 780 TI auf, trotz niedrigerer Taktraten, weniger Shadern und niedrigerer Bandbreite.
Ansonsten darf man nie vergessen wie gut Kepler mit manuellen OC nach oben skalierte, da die Taktraten sehr konserativ angelegt waren. 30% OC wurde hier ja schon öfters erwähnt, das war keine Seltenheit wenn nicht schon vom Hersteller ans Limit getrieben.

- Tests von GK110 gegen GK104 mit passendem Umfeld
Am besten dort 2 + 4GB GK104 (GTX 770 4GB) gegen 3 + 6GB GK110 (Titan, 780 6GB, Titan Black) um zu sehen ob es generell an der Architektur liegt, oder ob es dort noch woanders hakt. Zum Vergleich eine 7970 + die 6GB Version der 7970 rein. Abrunden mit einer GTX 980 und einer R9 290X. GTX 970 halte ich durch die RAM Eigenheit für eine äußerst schlechte Wahl.

Ansonsten: Mir fallen noch drei weitere NV Architekturen ein die äußerst schlecht gealtert sind:

Geforce FX: Schon Scheisse am Start, unbrauchbar kurz darauf.
Geforce 7: Gegen die 1900er Serie von ATI keinen Stich nach kurzer Zeit, da fehlte einfach Shaderleistung ohne Ende in moderneren Titeln.
GTX 480 & 580: Wurde hier schon erwähnt, da passte später gar nichts mehr. Ging aber der AMD Konkurrenz (pre GCN) genauso - einfach fallen gelassen von allen Seiten.

Full ack. Müsste man mal machen. Mir fehlt es aber an Zeit & Geld. :D Bin also raus. Im nächsten Jahr sollte sich das ändern und dann fange ich vielleicht mal mit solchen Sperenzchen an. Hobby ist schließlich dazu da um teuer und zeitraubend zu sein. :naughty:

[robbitop]

Fuck, das es sich um eine GTX 1060 in der 3GB Version handelt, habe ich gar nicht gesehen, ja dann nimm ich mein Argument natürlich zurück, aber jetzt wirkt das Ergebnis sehr suspekt, GTX 780 schlecht gealtert, GTX 680 nicht... :freak:
Das sind schlichtweg andere Spiele in den 2 Videos. Titanfall 2 nutzt die Sourceengine und Gears 4 nutzt UE4. Beides läuft IIRC auf Kepler gut. BF1 hingegen ist eine Überraschung. Ansonsten war ein alter Schinken wie Tomb Raider von 2013 in dem 680er Video dabei. Insofern ist das 680er Video mit 5 z.T alten Spielen (bzw auch neuere Spiele mit etw älteren Engines) nicht vergleichbar mit dem 780er Video (viel mehr Spiele und auch viele neue).

[danarcho]

Oh, da habe ich ja eine richtig interessante Diskussion verpasst :)
Gibt es irgendwo eine Referenz dafür, dass Sony/MS einen eigenen Compiler für GCN geschrieben haben? Ansonsten glaube ich da aufgrund des Aufwands eher weniger dran.
Sony hat natürlich wenigstens ein neues Frontend für ihre shading language geschrieben, aber ansonsten werden die sich auf das gleiche back-end verlassen müssen (meiner Meinung nach).
Auf Konsolen wird offline kompiliert und die Spiele mit binary shader ausgeliefert. Das läasst dann auch aggressivere Optimierungen zu, da die compile time keine Rolle mehr spielt. Gleichzeitig kann man auch inline assembly zulassen.
id schriebt sicher keinen Manschinencode oder gar Microcode.
Über Wolfenstein (und vermutlich ist es bei Doom auch so) weiß ich, dass für PS4 die Shader (erst kompiliert und dann) in assembly handoptimiert wurden. Also doch, die schreiben Maschinencode bzw. assembly. Das machen bei GCN einige. Für die PC Version wurden dann die optimierten assembly Shader wieder in SPIR-V übersetzt (ob automatisch oder auch per Hand weiß ich nicht).
War wohl eine falsche Information, der ich aufsaß.

Der andere Grund für die vergleichsweise gute Performance von Konsolen dürfte in der API liegen. Die muss ja nicht für ein abstraktes machine model ausgelegt sein, sondern darf direkt die Hardware features exposen.

[robbitop]

Warum kann man auf dem PC nicht auch offline kompilieren? Oder aber vor dem Levelstart.

[danarcho]

Vor dem Levelstart: kein Problem für die Shader, die bekannt sind (es ist oft nicht bekannt, welche gebraucht werden).
Die werden auch (vom Treiber) gecacht, so dass sie beim zweiten Mal nicht mehr kompiliert werden müssen. Vulkan erlaubt prinzipiell auch die kompilierten Shader abzurufen und zu verwenden.
Das Problem, warum nicht precompiled shader ausgeliefert werden ist, dass es zum einen deutlich zu viele verschiedene ISAs gibt (Stell dir nur mal vor, man müsste für jede neue Prozessorgeneration alle Programme neu kompilieren und die alten funktionieren nicht mehr).
Und zusätzlich erlauben die Shader auch "Spezialisierungen", das sind compile-time Konstanten, mit denen man (theoretisch exponentiell viele) unterschiedliche Varianten von einem Shader bauen kann.
Interessanterweise arbeitet Valve aber an einer Datenbank, mit der (unter Linux) precompiled shader runtergeladen werden. Bis jetzt nur mit der Intention, den Cache zu füllen, aber theoretisch ließen die sich auch durch optimierte Shader ersetzen.

[gravitationsfeld]

Über Wolfenstein (und vermutlich ist es bei Doom auch so) weiß ich, dass für PS4 die Shader (erst kompiliert und dann) in assembly handoptimiert wurden. Also doch, die schreiben Maschinencode bzw. assembly. Das machen bei GCN einige. Für die PC Version wurden dann die optimierten assembly Shader wieder in SPIR-V übersetzt (ob automatisch oder auch per Hand weiß ich nicht).
Nein. Nichts davon entspricht der Realität.

[danarcho]

Nein. Nichts davon entspricht der Realität.
Meine Quelle war eigentlich recht solide, aber kann sich natürlich auch irren. Darf ich fragen, woher der Mann nehmen seine Gewissheit?
Es ist ja schon für die PC-Version bekannt, dass Shader-Intrinsics und inline assembly verwendet wird. Wieso also nicht bei den Konsolen das ganze noch weiter treiben? Oder willst du sagen, dass die Konsolen-Versionen auch nur die gleichen Shader sourcen beinhalten?

[pixeljetstream]

Meine Quelle war eigentlich recht solide, aber kann sich natürlich auch irren. Darf ich fragen, woher der Mann nehmen seine Gewissheit?
Es ist ja schon für die PC-Version bekannt, dass Shader-Intrinsics und inline assembly verwendet wird. Wieso also nicht bei den Konsolen das ganze noch weiter treiben? Oder willst du sagen, dass die Konsolen-Versionen auch nur die gleichen Shader sourcen beinhalten?

Hast Du nen Beleg für die Aussage von inline assembly? Hört sich nach Legende an. Zumindest sind seitens AMD keine Wege dafür dokumentiert und für PC klingt das auch nach Selbstmord. https://www.khronos.org/registry/spir-v/extensions/

Der gängige Weg ist dass Entwickler sich das assembly angucken und dann meckern wenn der Compiler suboptimal ist. Man kann den Compiler dann versuchen zu überlisten indem man den Code umstrukturiert. Aber das Problem ist, dass es keine Garantie gibt, dass es nun so bleibt. Der compiler kann sich mit jeder Treiberversion ändern. Ein paar "grundsätzliche patterns" sind meist okay, aber details können schnell fragil werden. Ich glaube bei Konsolen haben die Entwickler etwas mehr Kontrolle über die Version des Compilers und diverse Kontrollparameter. Beim PC ist die Situation deutlich unvorhersehbarer, auch weil der shader den man so testweise kompiliert, nicht derjenige sein muss der dann wirklich läuft (Treiber kann nach Eingangsdaten optimieren, siehe constant folding http://developer.download.nvidia.com/gameworks/events/GDC2016/AdvancedRenderingwithDirectX11andDirectX12.pdf)

[gravitationsfeld]

Meine Quelle war eigentlich recht solide, aber kann sich natürlich auch irren. Darf ich fragen, woher der Mann nehmen seine Gewissheit?
Deine Quelle hat keine Schimmer wovon sie spricht.

[scully1234]

Meine Quelle war eigentlich recht solide, aber kann sich natürlich auch irren. Darf ich fragen, woher der Mann nehmen seine Gewissheit?


Er arbeitet an der Quelle...

[danarcho]

Deine Quelle hat keine Schimmer wovon sie spricht.
Willst du jetzt noch weiter rumka*ken oder sagst du mal was konstruktives? Du wiederholst dich.

Hast Du nen Beleg für die Aussage von inline assembly? Hört sich nach Legende an. Zumindest sind seitens AMD keine Wege dafür dokumentiert und für PC klingt das auch nach Selbstmord. https://www.khronos.org/registry/spir-v/extensions/

Der gängige Weg ist dass Entwickler sich das assembly angucken und dann meckern wenn der Compiler suboptimal ist. Man kann den Compiler dann versuchen zu überlisten indem man den Code umstrukturiert. Aber das Problem ist, dass es keine Garantie gibt, dass es nun so bleibt. Der compiler kann sich mit jeder Treiberversion ändern. Ein paar "grundsätzliche patterns" sind meist okay, aber details können schnell fragil werden. Ich glaube bei Konsolen haben die Entwickler etwas mehr Kontrolle über die Version des Compilers und diverse Kontrollparameter. Beim PC ist die Situation deutlich unvorhersehbarer, auch weil der shader den man so testweise kompiliert, nicht derjenige sein muss der dann wirklich läuft (Treiber kann nach Eingangsdaten optimieren, siehe constant folding http://developer.download.nvidia.com/gameworks/events/GDC2016/AdvancedRenderingwithDirectX11andDirectX12.pdf) Wie gesagt, das bezog sich auf Konsolen. Und meine Aussage war ja, dass die shader dort precompiled ausgeliefert werden. Dann wäre der Compiler im Treiber egal, da umgangen :)
Hier erwähnt Raja Koduri explizit inline assembly für Doom. Kann sein, dass er sich auch vertant hat. (ab ca. min 26)
AMD's Raja Koduri "The P in PC should stand for performance" (https://www.youtube.com/watch?v=FwcUMZLvjYw)
Für den HCC (also GPGPU Kram) wird inline assembly offiziell unterstützt. Vielleicht kann ja jemand was zu den Konsolen shading languages sagen?
Nvidia ist damit nicht wirklich vergleichbar, da ihr (sorry) eure ISA nicht dokumentiert. Bei Konsolen, sofern von der API unterstützt, könnte man seine Shader prinzipiell in Assembly schreiben, wenn man die ISA kennt. Und für z.B. OpenCL und HSA machen das durchaus Leute. Ich kenne sogar Leute, die Cuda mit selbst geschriebenen binaries benutzen und nu?

[gravitationsfeld]

Willst du jetzt noch weiter rumka*ken oder sagst du mal was konstruktives? Du wiederholst dich.
Ich brauch da nichts dazu sagen außer dass es nicht stimmt. Ich kann es nicht ausstehen, wenn an Haaren herbeigezogenes Halbwissen als Fakt dargestellt wird. Nicht mal auf den Konsolen schreibt man GCN assembly.

Kannst du übrigens auch selber überprüfen indem du dir Vulkan Doom mit RenderDoc anschaust. Die Symbole sind nicht gestript.

[pixeljetstream]

Für den HCC (also GPGPU Kram) wird inline assembly offiziell unterstützt.

Und für z.B. OpenCL und HSA machen das durchaus Leute. Ich kenne sogar Leute, die Cuda mit selbst geschriebenen binaries benutzen und nu?

In diesem Bereich stimme ich Dir zu, aber Du hast nun das Thema geändert, von einem Consumer PC titel mit Vulkan API zu HPC. Allerdings spricht AMD auf ihrem blog von einem experimentellen assembler. Auch unter OpenCL extensions gibt es kein inline assembly. https://www.khronos.org/registry/OpenCL/

Du hast Dich im Punkt inline assembly klar auf einen PC Titel bezogen und dann für Konsolen ein zweites Thema eröffnet und nun mit HPC ein weiteres.

[Hübie]

Könnte jemand für einen Laien wie mich kurz umreißen was inline assembly ist / macht? Maschinensprache habe ich mal gesehen und dankend abgelehnt. :D

[Ganon]

Könnte jemand für einen Laien wie mich kurz umreißen was inline assembly ist / macht? Maschinensprache habe ich mal gesehen und dankend abgelehnt. :D

Du schreibst Assembler quasi mitten in deinem regulären C Code. https://de.wikipedia.org/wiki/Integrierter_Assembler

[danarcho]

Ich brauch da nichts dazu sagen außer dass es nicht stimmt. Ich kann es nicht ausstehen, wenn an Haaren herbeigezogenes Halbwissen als Fakt dargestellt wird. Nicht mal auf den Konsolen schreibt man GCN assembly.

Kannst du übrigens auch selber überprüfen indem du dir Vulkan Doom mit RenderDoc anschaust. Die Symbole sind nicht gestript.
Geht doch, habs jetzt editiert. Gib halt einfach eine Begründung, dann wirkt das nicht so arrogant.

In diesem Bereich stimme ich Dir zu, aber Du hast nun das Thema geändert, von einem Consumer PC titel mit Vulkan API zu HPC. Allerdings spricht AMD auf ihrem blog von einem experimentellen assembler. Auch unter OpenCL extensions gibt es kein inline assembly. https://www.khronos.org/registry/OpenCL/

Du hast Dich im Punkt inline assembly klar auf einen PC Titel bezogen und dann für Konsolen ein zweites Thema eröffnet und nun mit HPC ein weiteres.
Naja, es ging um die Aussage, ob assembly von Hand geschrieben wird. Das waren halt Beispiele. Aber wo ich drüber nachdenke: inline assembly ergibt für Shader auf dem PC auch gar keinen Sinn. Daher müsste sich Raja Koduri damit auf die Konsole beziehen oder er verwechselt das mit Intrinsics. Und natürlich haben weder OpenCL noch SPIR-V extensions für inline assembly, da das in der Regel kein Sprach-Feature ist, sondern ein Compiler-Feature. Eben z.B. bei HCC. Und für Konsolen ginge das auch, da offline für eine bestimmte Hardware kompiliert wird.