Diskussion zu: Hardware- und Nachrichten-Links des 22. Juli 2021

[Leonidas]

Link zur News:
https://www.3dcenter.org/news/hardware-und-nachrichten-links-des-22-juli-2021

[Dorn]

Wäre ich ein Amerikaner und meine Grafikkarte wäre wegen New World abgeraucht würde ich jetzt gegen Amazon (mit Erfolg) klagen. :biggrin:

Man stelle sich nur vor es würden deswegen viel mehr Grafikkarten kaputt gehen und das in der angespannten Lage.

[Gast]

" insofern nVidia beim Ansatz des GA100-Chips bleibt und die FP32-Einheiten nicht (wie bei Gaming-Ampere) verdoppelt"
Ist es nicht so, dass bei GA100 die Tensor Kerne auch volle FP32 Fähigkeit haben und bei den kleineren Amperes nicht? NVidia versucht im HPC Segment meiner Meinung nach immer mehr Workload von den klassischen Shadern zu den TCs zu verlagern. Insofern ist es da einfach nicht nötig, die Shader zu verdoppeln.

[Leonidas]

Richtig, da ergeben sich die Ansätze dazu, warum nVidia dies bewußt nicht macht. Und wenn man es bewußt nicht macht, wird es auch bei Hopper nicht kommen. Der Weg nVidias bei diesen HPC-Chips geht wo anders hin.

[Gast]

Wäre ich ein Amerikaner und meine Grafikkarte wäre wegen New World abgeraucht würde ich jetzt gegen Amazon (mit Erfolg) klagen. :biggrin:



Nein, eine Software darf niemals die Hardware killen, das muss in jedem Fall die Hardware vorher abfange, außer natürlich es ist irgendwelche Übertaktungssoftware welche extra dafür geschaffen wurde die Limits der Hardware zu umgehen.

Es gibt keine Regel die besagt dass man maximal X FPS rendern darf weil ansonsten die Hardware kaputt geht.

Und auch die versuchte Erklärung von Igorslab halte ich für unwahrscheinlich.
Es ist ja nicht so, dass die Powerregelung der Karte in irgendeiner Form mit den FPS synchronisiert wäre.

Wäre das der Fall wären höhere FPS ja sogar besser, weil wenn die Regelung nur 1x pro Frame eingreifen dürfte hätte diese ja mit 1000FPS wesentlich mehr Chancen die Hardware zu retten als mit nur 100FPS.

Insofern macht es überhaupt keinen Sinn, falls die Regelung mit einer Granularität von 1ms Arbeitet, dass dann plötzlich 1001 FPS zu viel wären. Nur weil innerhalb eines Regelungsschrittes mehr als ein Frame beginnt heißt es ja nicht dass innerhalb dieses plötzlich mehr Powerbudget zur Verfügung steht. Es ist ja nicht so, dass für 1 Frame eine bestimmte Menge an Joule zur Verfügung steht, und wenn innerhalb eines Regelungsschrittes ein 2. Frame beginnt dann plötzlich doppelt so viel verwendet wurden.

Was auch immer es ist, die bisherigen Erklärungsversuche machen nicht wirklich Sinn, und wenn man Igor glaubt haben ja selbst EVGA+NV nicht wirklich eine Ahnung was die Ausfälle verursacht.

Einen direkten Zusammenhang mit den FPS kann es jedenfalls nicht geben, die hohen FPS sind höchstens ein Resultat.

[Leonidas]

Ich dachte, das könnte man so auslegen:

Der komplette Frame wird in weniger als 1ms erzeugt. Das dürfte sicherlich mit einer gewissen Stromschwankung einhergehen, je nachdem was gerade gemacht wird. Im Punkt der höchsten Last ist dann das Abfrage-Intervall der Schutzsteuerung zu groß und es wird ungezügelt Energie durchgejagt, deutlich mehr als der durchschnittliche Verbrauch. Irgendwann steigt dann eines der Bauteile aus. Wieviel da in den Peaks verbraucht wird, das dürfte der Killer sein.

[hate destroys the world]

Das gesamte MCM-Konstrukt beläuft sich somit auf 288 Shader-Cluster (SM) – was 18432 FP32-Einheiten ergibt, insofern nVidia beim Ansatz des GA100-Chips bleibt und die FP32-Einheiten nicht (wie bei Gaming-Ampere) verdoppelt
Die Paired-ALUs von "Gaming Ampere" bringen bei normalen Shadern nur ca 30%, weil normaler Quellcode vom Compiler nur schwer bzw. kaum "verpaart" werden kann. Selbes Funktionsprinzip wie Rapid Packed Math bei AMD und entsprechend dasselbe Problem.
Deswegen sind bei HPC die Transistoren/Fläche/Hitze woanders viel besser angelegt.

Bei RT kann Pairing besser ausgenutzt werden.

[iamthebear]

Es handelt sich bei Gaming Ampere nicht und eine einfache Verdopplung der FP32 Einheiten.

Bei Turing gibt es wie bei Volta und professional Ampere pro SM sowohl 64 INT als auch 64 FP32 Einheiten, also in Summe 128. Zu einer 100% Auslastung kommt es jedoch nur dann, wenn genauso viele FP32 wie INT Befehle abgearbeitet werden.
Im Gaming Betrieb ist das Verhältnis laut Nvidia jedoch ca. 100FP32 zu 36 INT. Das bedeutet in der Praxis im Schnitt, dass 64 FP32 Einheiten arbeiten und 23 INT Einheiten und die restlichen 43 INT Einheiten schlafen.

Bei Pascal und Gaming Ampere gibt es pro SM 128 FP32 Einheiten, die aber auch INT Operationen abarbeiten können. Pro Zyklus können auch bis zu 128 Operationen ausgeführt werden ganz egal ob FP32 oder INT.
Bei Gaming bedeutet das im Schnitt, dass 94 (statt 64) Einheiten mit FP32 Befehlen beschäftigt sind und 34 (statt 23) Einheiten mit INT Befehlen. Der theoretische Durchsatz ist also knapp 50% pro SM höher oder anders gesagt: Man braucht für dieselbe Leistung ca. ein Drittel weniger SMs (siehe 46SM bei der 3070 vs. 68 bei der 2080 Ti).

Der Nachteil der Variante bei Pascal/Ampere ist jedoch, dass FP32 Einheiten deutlich mehr Transistoren bzw. Fläche verschlingen als INT Einheiten und im Schnitt pro SM auch ca. die Hälfte mehr an Platz benötigt wird. Auch die Verlustleistung steigt um 50% mit.

Es ist im Gamingbetrieb also fraglich was von beiden die sinvollere Variante ist, weshalb Nvidia wohl auch schon 2 Mal hin und her gewechselt ist. Im Professional Bereich istbder Anteil der INT Befehle im Schnitt vermutlich höher, weshalb hier Nvidia durchgehend auf die Variante mit den INT Einheiten setzt.

Das was man sich jedoch als Faustregel beim Vergleich merken kann:
Bei einer 128er Konfiguration 50% mehr Performance/SM (bei Gaming)
Bei einer 64+64er Konfiguration 50% mehr SM auf selber Fläche

[iamthebear]

Also so wie ich das verstanden habe gibt es Probleme.

Problem1:
Die EVGA Karten haben einen Bug in ihrem externen Lüftercontroller, der bei Übertemperatur die Notabschaltung durchführt. Dieser wurde aus bisher ungeklärten Gründen gegrillt.

Problem2 (die eigentliche Grundursache):
Das Spielt schafft es eine Last zu erzeugen, die höher ist als bei einem regulären Burn in, wodurch auch die 6800 XT von igor hochdreht und irgendwann abstürzt. Das Problem ist also grundsätzlich bei deutlich mehr Karten (nicht nur Nvidia) vorhanden. Es führt nur nicht zu einem permanenten Defekt. igor hat auch gemeint das Ding heizt extrem was jetzt auch für tatsächlichen Energiebedarf und nicht nur ein fehlerhaftes Verhalten der Lüftersteuerung sprechen würde.

Grundsätzlich darf jedoch Programmcode, der nicht mit Administratorrechten läuft nicht zu einem Systemabsturz führen können.

Also ich sehe hier 2 mögliche Erklärungen (Achtung schwere Spekulation meinerseits)
.) Die kurzzen Framezeiten bzw. schnelle Lastwechsel sorgen dafür, dass sowohl bei Nvidia als auch bei AMD die Boostlogik durcheinander kommt und die Karten mit Spannungen bzw. Taktraten betrieben werden, die das System nicht aushält.
Es könnte z.B. sein wenn das Spiel mit festen 1K fps läuft und die Last alle 1ms abgefragt wird, dass dabei immer eine kurze Idle Phase erwischt wird und die Boostlogik meint "wir fahren schon über 2GHz, Stromverbrauch ist aber noch unter 100W, da geht noch mehr" obwohl die Karte bereits zu 90% mit 500W läuft und nur 10% der Zeit mit 100W.

2.) Eine andere mögliche Erklärung wäre, dass die häufigen schnellen Lastwechsel die Messung der Spannung durcheinander kommt und alle Chips mit zu viel Versorgungsspannung gegrillt werden. Der GPU Die überlebt es und wird nur heiß, der Lüftercontroller ist aber zufällig der erste, der das zeitliche segnet.

Es ist auch möglich, dass die Qualitätskontrollen in der Phase der großen Knappheit elektronischer Bauteile (die Chips die den Verbrauch messen waren ja auch sehr knapp) nicht ausreichend funktioniert hat bzw. man dann in der Not am Markt irgendwelche nur hapb kompatiblen Restbestände gekauft hat ohne diese ausreichend zu testen.

[Gast]

Es ist im Gamingbetrieb also fraglich was von beiden die sinvollere Variante ist, weshalb Nvidia wohl auch schon 2 Mal hin und her gewechselt ist.

Ziemlich sicher die Ampere-Variante, ich habe mich damals bei Turing schon gewundert aarum sie es nicht so gemacht haben, aber vermutlich war mit 12nm das Transistorbudget einfach nicht vorhanden.

Mit Ampere hat man immer eine gute Auslastung von 100% FP32 bis zu 50:50 FP32:INT32.

Mit Turing hat man eigentlich nur mit 50:50 FP32:INT32 eine perfekte Auslastung, was im Gaming so gut wie nie vorkommt, und die meiste Zeit langweilt sich doch ein guter Teil der Hardware.

Mit Ampere kann man mit einem vergleichsweise geringen Hardwareeinsatz, die ALU-Logik für die Mantisse entspricht in einer FP-Unit ja 1:1 einer INT-ALU und es muss nur mehr die Logik für den Exponenten hinzugefügt werden, im besten Fall die FP-Performance bis zu verdoppeln.

[iamthebear]

1.) Transistorbudget ist kein Argument. Dann hat man eben weniger SM.
Ich vermute einfach einmal man hat auf einen höheren INT Anteil durch RT spekuliert.

2.) Der "vergleichsweise geringe" Hardwareeinsatz sind ca. 40% mehr Transistoren bei gleicher SM Anzahl. Das ist schon ein heftiges Investment.
Auf der anderen Seite bekommt man um die 50% mehr FP Leistung im Normalfall, da in der Praxis im Schnitt 96 statt 64FP32 Einheiten am Arbeiten sind.

Ideal wäre meiner Meinung nach wohl eher 128FP32 + 64INT oder vielleicht auch 64FP32 + 32INT aber Nvidia wird wohl seine Gründe haben warum es so aufgeteilt ist.

[Gast]

1.) Transistorbudget ist kein Argument. Dann hat man eben weniger SM.


Um damit im Endeffekt langsamer zu sein? Sehr intelligent.


Ich vermute einfach einmal man hat auf einen höheren INT Anteil durch RT spekuliert.


Raytracing ist kein Neuland, man weiß welche Mathematik man dafür braucht, da braucht es kein Spekulieren.


2.) Der "vergleichsweise geringe" Hardwareeinsatz sind ca. 40% mehr Transistoren bei gleicher SM Anzahl. Das ist schon ein heftiges Investment.
Auf der anderen Seite bekommt man um die 50% mehr FP Leistung im Normalfall, da in der Praxis im Schnitt 96 statt 64FP32 Einheiten am Arbeiten sind.


In den +40% sind deutlich mehr als nur das Upgrade von INT auf FP+INT. Wenn man schaut was sonst noch alles im SM geändert wurde, dürfte das FP-Upgrade <10% in die Gesamtrechnung mit einfließen.


Ideal wäre meiner Meinung nach wohl eher 128FP32 + 64INT oder vielleicht auch 64FP32 + 32INT aber Nvidia wird wohl seine Gründe haben warum es so aufgeteilt ist.

Nachdem der INT-Anteil am Shadercode variiert wird man mit einem flexiblen Ansatz immer mehr Leistung pro Transistor bekommen.
Der einzige Grund warum vielleicht ein fixer Ansatz vielleicht doch ein Comeback feiern könnte, ist die Effizienz, bzw. falls man quasi einen Überschuss an verbaubaren Transistoren im Budget zur Verfügung hat, dabei beim Powerbudget aber schon am Ende ist.
Die FP32/INT32-Kombieinheit hat quasi eine 32bit Mantisse, anstatt nur 23 bit die für FP32 nötig wären und braucht damit etwas mehr Strom als eine dedizierte FP32-ALU.

[hate destroys the world]

Es handelt sich bei Gaming Ampere nicht und eine einfache Verdopplung der FP32 Einheiten.

Ich sagte aber auch explizit, dass das Pairing ist. Das entscheidende ist die Funktionsweise, nicht wie Einheitenzahl!

Wenn du dir das vor Augen hällst:

Im Gaming Betrieb ist das Verhältnis laut Nvidia jedoch ca. 100FP32 zu 36 INT.sollte eine verdopplung der FP32 Einheiten, wie du davon redest, immer noch im FP32 Limit sein, du bekommst jedoch nur 30% der Leistungssteigerung in der Praxis, Pairing eben, NVidia hat einfach nur das bestehende FP16 Pairing auf FP32 aufgebohrt.


Entsprechend ist das

Bei Pascal und Gaming Ampere gibt es pro SM 128 FP32 Einheiten, die aber auch INT Operationen abarbeiten können. Pro Zyklus können auch bis zu 128 Operationen ausgeführt werden ganz egal ob FP32 oder INT. nur für Pascal zutreffend. Bei Ampere hast du nur halb soviele Int Operationen bzw. Einheiten, also 64. Laut NVidia bei 3090 z.B.

FP16 10752
FP32 10752
FP64 168
INT32 5376
TMUs 336
ROPs 112
SM 84
Tensor 336

Wenn du dir das als Pairing verinnerlichst, wird vieles klarer.