News GeForce RTX 50: Nvidia veröffentlicht technisches Whitepaper für Blackwell

[DevPandi]

Das stimmt so nicht: Sowohl auf Ada als auch auf Blackwell gibt jede "Shader-Partition" pro Taktzyklus eine Vektorinstruktion heraus.

Was du schreibst ist weitgehend falsch und deckt sich auch nicht mit den Informationen, die in den Whitepapern zu finden ist.

Kannst du das bitte mit einer Quelle belegen?

Bereits Kepler sowie Maxwell hatten die Möglichkeit zwei Instruktionen pro Warp in die SM abzugeben. In Maxwell-Whitepaper wird hier auch explizit von Dual-Issue geschrieben.

Ab Turing kann eine INT und eine FP Instruktion pro Tile/Kachel ausgeführt werden zur gleichen Zeit. Auch das wird entsprechend Prominent in Whitepaper benannt.

Und der Punkt den ich hier in der News beschreibe steht so im Whitepaper auf Seite 12.

Im Turing Whitepaper wiederum findet man auf Seite 11 den Hinweis, dass eben FÜR und INT Instruktionen ZUR gleichen Zeit auf der Tile ausgeführt werden können.

Kurz um, das was du hier schreibst passt nicht zudem, was NVIDIA selbst kommuniziert.

Blackwell ist mit den Änderungrn aber wieder bei dem, was Maxwell/Pascal war: die Kachel kann entweder FP oder INT, nicht mehr beides zur gleichen Zeit.

 

[Pheenox]

Ich frage mich, weswegen Nvidia die 5080 so unattraktiv macht. Trotz zwei Jahren Entwicklungszeit, neuerem Speicher, der ggü. der 5090 sogar noch hoch getaktet ist, kommt ein mageres Leistungsplus von 10% zu einem höheren Preis, den man auch für den Vorgänger bezahlt hat.
Wer zur Hölle soll die Karten kaufen? Das bisschen Effizienzsteigerung wird nicht das Verkaufsargument sein. Erwartet Nvidia, dass sie die Hardware über die Software verkaufen können? Denn zumindest auf der Softwareseite hat Nvidia geliefert.
Ansonsten ist die Generation Blackwell eine Enttäuschung auf ganzer Linie. Da haben die Meisten etwas anderes erwartet.

 

[Falc410]

Dann würde ich dir mal dringlich anraten dich mit der Thematik Latenz (Frametime) zu beschäftigen

Das sind zwei komplett verschiedene Dinge und kein Synonym.
Aber du hast deine Quellen (irgendwelche Influencer) ja bereits genannt. Ich würde dir anraten die Definition der beiden Begriffe nachzulesen und nicht nur YouTube zu konsumieren.

Und bitte, wenn du deine Argumentation mit Zitaten und ähnlichem belegen möchtest, dann benutze die Zitierfunktion im Forum und kopier nicht einfach wahllos Videos von irgendwelchen „Experten“ rein. Sollen wir jetzt 1h Video gucken um herauszufinden auf was Du Dich beziehst?

 

[Nai]

@DevPandi

Ich wäre mit den Whitepapern etwas vorsichtig, da versucht NVIDIA seinen Kunden gerne weiß zu machen, dass seine GPUs 10 000de von Kernen haben und 10 000de von Threads ausführen können, was gar nicht so stimmt. Auch verheimlicht es gerne, dass ein Multiprozessor sehr ähnlich zu einem modernen regulären CPU-Kern mit SIMD-Einheiten ist. Überhaupt verwendet NVIDIA in seinen Whitepapern den Begriff SIMD sehr sparsam bzw. dann auch noch irreführend. Imho, muss man bei diesen NVIDIA Whitepapern deswegen auch stark zwischen den Zeilen lesen.

Zwecks der Anzahl an Instruktionen pro Takt siehe hier https://en.wikipedia.org/wiki/CUDA#Multiprocessor_architecture unter "Max number of new instructions issued each cycle by a single scheduler". Alternativ kannst du ein Compute-Bound FP-Kernel auf einer Ada GPU profilen, und schauen, ob du einen IPC von 4 oder 8 misst. Vielleicht mache ich das auch später einmal....

Zwei SIMD-Recheninstruktionen pro Takt macht auf Ada auch keinen Sinn, da die physikalische SIMD-Breite bei Ada ja 16 ist, während die logische SIMD-Breite (aka Warpgröße) 32 ist, d.h. eine SIMD-Einheit besitzt nur einen Durchsatz von einer halben Instruktion pro Takt. Auf Grund von Pipelining gibt Ada dann (sehr wahrscheinlich) in einem Takt eine Instruktion heraus, die an die reine FP-Einheit geht, und im nächsten Takt dann eine Instruktion, die an die FP/INT-Einheit geht. Allerdings wäre es prinzipiell auch möglich (sogar wenn sehr unwahrscheinlich), dass Ada nur alle zwei Takte zwei SIMD-Recheninstruktionen herausgibt, wovon eine an die reine FP-Einheit und die andere an die FP/INT-Einheit geht.

Auf Maxwell und Kepler wurden in der Tat zwei Instruktionen pro Takt herausgegeben. Auf Maxwell diente dies nur dazu, dass man unter Auslastung der FP/INT-Einheiten noch zusätzlich herausgegebene Instruktionen für LSUs und SFUs übrig hatte. (Auf Ada hat man bei einer herausgegebenen LSU- oder SFU-Instruktion auch automatisch eine Blase in den Pipelines seiner FP/INT-Einheiten, wodurch hier Rechenleistung verloren geht.) Und Kepler war ein Kuriosum: Dort gab es, neben der privaten FP/INT-Einheit jeder Shaderpartition, eine zusätzliche FP/INT-Einheit, welche jeweils zwischen zwei Shader-Partitionen geteilt wurde. Eine Instruktion pro Takt konnte dort an die private FP/INT-Einheit gehen, während die andere Instruktion an die geteilte FP/INT-Einheit gehen konnte. Dies hat in der Praxis allerdings nicht so gut funktioniert, da die geteilten FP/INT-Einheiten auf Grund von zu wenig Registerbandbreite meist nur sehr schlecht ausgelastet werden konnten.

 

[Lolliedieb]

Dennoch, doppelte Int32-Leistung ist hammer gut. Also müssten Algorithmen zum Sortieren, Komprimieren, Verschlüsseln, Hashing oder irgendwas mit Strings schneller laufen. Nur halt keine Spiele, weil die Gleitkommazahlen nutzen.

Absolut richtig. Was noch nicht ganz klar ist, wie weit der Scheduler umgebaut werden wird. Bisher war es so, dass immer Threads 0-15 und 16-31 auf einem Sub-Block der SM in zwei aufeinander folgenden Takten bearbeitet wurden, weil 16 baugleiche ALUs dort waren. In dem Zwischentakt konnte dann die andere Alu angesprochen werden, wenn es passende Arbeit gab, die halt einen anderen Workload-Typ hatte und die unabhängig war von der bestehenden Aufgabe. Man brauchte also immer zwei unabhängige Arbeitsstänge - besser eigentlich 4, denn fast alle Instruktionen haben eine gewisse Latenz dann in der Pipeline.

Was noch nicht klar ist, ist ob die Alu sich nun wie bei Ampere und Ada mit fp32 verhält, also das man mehr oder weniger je Thread 4 Arbeitspakete braucht, die unabhängig laufen können um die Int32 Alu auszulassen, oder ob man auch da Hand angelegt hat und nun derer 2 reichen.

Insgesamt ist aber zu erwarten, dass bei Integer-Workload wir den doppelten Durchsatz erreichen können.
Das war in der Crypto-Szene im übrigen ganz niedlich, als die ersten "Benchmarks" von Blackwell aufkamen, wo Leute die 4090 Ergebnisse mit pauschal 30% Aufschlag gedropt haben ... was ziemlicher Unfug ist bei 70% mehr Speicherbandbreite und 100% mehr Integer Alus wird da schon mehr bei rum kommen. Aber wollten sich halt einige drauf profilieren ohne zu wissen, womit sie es da zu tun haben xD

 

[Gerithos]

Im Westen nichts neues, ist also im Kern wie turing zu betrachten mit deutlich weniger upside im Vergleich

 

[CDLABSRadonP...]

@SP-937-215 Das Posting ist leer...

 

[DevPandi]

Ich wäre mit den Whitepapern etwas vorsichtig, da versucht NVIDIA seinen Kunden gerne weiß zu machen, dass seine GPUs 10 000de von Kernen haben und 10 000de von Threads ausführen können

Allgemein muss man an der Stelle "aufpassen", weil AMD, Nvidia und Intel hier teilweise auch unterschiedliche Thermini für das gleiche Problem benutzen. Da passt ganz gut das nächste Zitat:

dass ein Multiprozessor sehr ähnlich zu einem modernen regulären CPU-Kern mit SIMD-Einheiten ist. Überhaupt verwendet NVIDIA in seinen Whitepapern den Begriff SIMD sehr sparsam bzw. dann auch noch irreführend. Imho, muss man bei diesen NVIDIA Whitepapern deswegen auch stark zwischen den Zeilen lesen.

Nvidia spricht seit einigen Jahren nicht mehr wirklich von SIMD, sondern von SIMT. Single-Instruction-Multiple-Threads. AMD und Intel wiederum sprechen von SIMD. Dazu kommt, dass Nvidia Threads und Warps verwendet, während AMD hier Threads und Waves als begriffe nennt. Ein Wave wiederum ist nicht direkt mit einem Warp vergleichbar und doch schon, während ein Thread bei AMD in den Whitepapers für das steht, was Nvidia mit Warps meint und nicht unbedingt für das, was Nvidia mit Threads meint.

und im nächsten Takt dann eine Instruktion, die an die FP/INT-Einheit geht. Allerdings wäre es prinzipiell auch möglich, dass Ada alle zwei Takte zwei SIMD-Recheninstruktionen herausgibt, wovon eine an die reine FP-Einheit und die andere an die FP/INT-Einheit geht.

Wenn ich die Whitepapers seit Kepler durchgehe, dann spricht man bei Kepler, Maxwell und Pascal davon, dass ein Warpsheduler - 32 Threads/Clock - entweder eine oder zwei Operationen absetzen kann an die ALUs. Im Maxwell-Paper steht dazu, dass die "Dual-Issue"-Fähigkeit pro Warp erhalten bleibt, die man aus Kepler bereits kennt und bei Bedarf und wenn es möglich ist, zwei Operationen auf den 32 Rechenkernen ausgeführt werden können. Also entweder eine Operation oder zwei Operationen - wobei hier mit Operationen jetzt die "Instruktion" gemeint ist. Es waren also 2 Operationen nach 2 Takten, oder eine Operation nach einem Takt.

Bei Turing wurde das beibehalten. Nur, dass es jetzt eben ein Datenpfad für Int und ein Datenpfad für FP-Operationen/Instruktionen gibt. Womit mit eben aufgelöst wurde, dass die Sub-Kachel eben auf einen Datentyp festgenagelt wurde.

Blackwell ist an der Stelle also ein "Rückschritt" zu Pascal, denn 32 INT-Werte konnte auch bereits Pascall berechnen, wird im Whitepaper nun nur als Neuerung verkauft.

Und Kepler war ein Kuriosum: Dort gab es, neben der privaten FP/INT-Einheit jeder Shaderpartition, eine zusätzliche FP/INT-Einheit, welche jeweils zwischen zwei Shader-Partitionen geteilt wurde.

Kepler ist im ganzen relativ "seltsam", weil 192 Shader-Kerne auf 6 4 Warp-Scheduler getroffen ist, die alle Dual-Issue beherrschten. Wodruch es auch bei Kepler dazu kommen konnte, dass sich da was "gegenseitig" blockiert, was sie mit Maxwell aufgelöst haben.

Das ganze Thema ist am Ende jedoch sehr komplex und durch das Marketing-Material und das, was Nvidia teilweise in Interviews sagt und das was dann in Whitepapers und auch in den ISA-Dokumentationen steht, gibt es so einiges an Verwirrung.

 

[computerfouler]

5090 = Viel Rauch um nichts
5080 = Noch mehr Rauch um gar nichts

 

[pipip]

Pscht, dieses "Konzept" durchbricht aber die Jammertiraden ;-)

Und wir wissen erst seit Monaten, dass das nur 16 Gb VRAM werden. Die MIR auch zu wenig wären. Also zwingt mich Nvidia die 5090 zu kaufen, merke ich gerade. ASUS, bringt die 5090 ASTRAL ran!

Aber nochmal im ernst, bezüglich des Whitepapers:

Die 5080 hat fast den Durchsatz, den die 4090 hatte aber 16 GB Limit.

Das Thema Texturen Kompression steht erst am Anfang, Nvidia hat in den Marketingseiten folgendes:


Im Whitepaper finde ich auf Seite 40:



Es mag sein, dass "demnächst" das VRAM Problem bald keines mehr in der "Form" wie bisher ist.

Nach AI Frames kommt AI Ram, und ich will das (tm) darauf hier im Forum Zwinkersmiley

Sprich auf die nächste. Jahre warten bis die 16 GB vllt kein mehr limit mehr sind, dafür dann die GPU 😜 kleiner Spaß.

Ich wette Nv ist hier nur der erste der neural Shader ankündigt. Im endeffekt arbeitet AMD bereits in die Richtung und ich glaube dass die KI Core bei RDNA4 ein part vom shader sein wird. Es muss einen Grund für dual issue bei rdna 3 geben.

NV hat schon oft erzählt, sie arbeiten mit MS an eine Integration von etwas, und dann hat NV, AMD und MS gemeinsam an eine Schnittstelle gearbeitet.

Ich hoffe nur, dass AMD nicht deshalb die Puffer Cache für RT und KI nich vergrößert hat, somit nicht nur RT und KI Performance, sondern auch die IPC steigert, das SI somit stärker entlastet und somit sich höhere Taktrate erlaubt, die bei RDNA noch wegen dem SI Bausteinen ausgebremst wurden 🥲
Das würde die größere Die-Size Fläche gegenüber dem Vorgänger nicht erklären. Zu viel Spekulation.

 

[DevPandi]

Ich wette Nv ist hier nur der erste der neural Shader ankündigt.

Das die Neural-Shader Teil von DX12 werden ist aber schon bekannt und bestätigt.

Das AMD und Intel hier nachziehen ist also wahrscheinlich.

 

[pipip]

@DevPandi Es geht nicht um nachziehen. Genau das will ich unterstreichen. NV stellt es vermutlich nur wieder so dar…

 

[Sun_set_1]

Das die Neural-Shader Teil von DX12 werden ist aber schon bekannt und bestätigt.

Das AMD und Intel hier nachziehen ist also wahrscheinlich.

Aktuell heißt die route dafür allerdings noch nvapi, oder?

Die 16GB Diskussion halte ich übrigens für stark übertrieben. Wenn, soweit die Leaks stimmen, die nächsten Konsolen auf 16GB VRAM kommen, weit über 90% der aktuellen Desktop GPU 16GB oder weniger bieten, wer glaubt da eigentlich ernsthaft, dass in drei Jahren von jetzt 20GB VRAM Titel DER Standard sind?

Ja, es wird Ausnahmen geben. Ja, es wird Titel geben in denen ich mit Hyper Ultra Texturen auf mehr als 20GB komme. Aber warum man im Standard, bei ‚normalen‘ bis ‚hoch‘ Settings, von mehr als 20GB VRAM ausgehen sollte, während auch 2028 höchstens 5% der am Markt verfügbaren GPU diese Menge VRAM mitbringen, erschließt sich mir leider überhaupt nicht.

Ist irgendjemand ernsthaft der Ansicht es werden Spiele primär für 3% der am Markt verfügbaren GPU entwickelt? Oder wird man sich vllt doch eher an den 97% orientieren, die 16GB oder weniger besitzen. Hm?

 

[nutrix]

Ich wäre mit den Whitepapern etwas vorsichtig, da versucht NVIDIA seinen Kunden gerne weiß zu machen, dass seine GPUs 10 000de von Kernen haben und 10 000de von Threads ausführen können, was gar nicht so stimmt.

Moment bitte, Whitepapers sind doch kein Marketing oder Werbung mit Falschinformationen. Whitepapers dienen doch dazu, Entwicklern und anderen zuverlässige Informationen über die Funktionsweise einer Hard- oder Software zu liefern. Meines Wissens nach werden diese Whitepapers intern wie extern verwendet. Da wäre doch jede bewußte Fehlinformation und falsche Leitung fatal. Das kann ich mir, der selbst solche Doku permanent verfaßt, nicht vorstellen. Üblicherweise werden oder sollten solche Dokumente auch gereviewt bzw. qualitätsgesichert (zumindest bei uns in Deutschland, oder wenn man einer ISO oder sonstwas Norm folgt), weil jede Fehlinformation fatale Folgen nach sich ziehen würde. Ich bin da eher bei DevPandi, daß es eher Mißverständnisse und Probleme wegen anderen Bezeichnungen gibt.

Auch verheimlicht es gerne, dass ein Multiprozessor sehr ähnlich zu einem modernen regulären CPU-Kern mit SIMD-Einheiten ist.

Und auch das bezweifle ich. Warum soll man das tun und etwas "verheimlichen"?

Überhaupt verwendet NVIDIA in seinen Whitepapern den Begriff SIMD sehr sparsam bzw. dann auch noch irreführend. Imho, muss man bei diesen NVIDIA Whitepapern deswegen auch stark zwischen den Zeilen lesen.

Ein Whitepaper ist doch kein Essay oder beliebiger Roman. Sorry, dann verstehst Du den Sinn dieser Art von Doku nicht oder Deine Herangehensweise ist nicht richtig. Ganz im Gegenteil, ein Whitepaper soll eben nicht zwischen den Zeilen gelesen werden, es soll eindeutige und möglichst widerspruchsfreie Informationen zu technischen Aspekten und Implementierungen liefern, nichts anderes.

Das ein Whitepaper Fehler enthält oder Dinge nicht erwähnt, weil vergessen etc. kann ich mir ja noch vorstellen. Aber wenn ich Deinen Behauptungen folgen würde, könnte ich keinem Whitepaper weltweit mehr vertrauen. Sorry, das halte ich für sehr gewagt bis absurd.

@rest
Es haben alle verstanden, daß es hier explizit um die Whitepapers geht, und nicht das Alltagsblabla und -diskussionen der aktuellen GPUs?

 

[Nai]

@DevPandi

Nvidia spricht seit einigen Jahren nicht mehr wirklich von SIMD, sondern von SIMT. Single-Instruction-Multiple-Threads. AMD und Intel wiederum sprechen von SIMD. Dazu kommt, dass Nvidia Threads und Warps verwendet, während AMD hier Threads und Waves als begriffe nennt. Ein Wave wiederum ist nicht direkt mit einem Warp vergleichbar und doch schon, während ein Thread bei AMD in den Whitepapers für das steht, was Nvidia mit Warps meint und nicht unbedingt für das, was Nvidia mit Threads meint.

Geht weniger darum, dass NVIDIA von SIMT spricht (wenn es SIMT als eine Erweiterung von SIMD sehen würde), sondern, dass es versucht, SIMD sehr geschickt in seiner Nomenklatur zu verbergen. So ist z.B. (fast) jede Instruktion einem GPU Kernel eigentlich eine SIMD-Instruktion (skalare Instruktionen (aka Nvidias Uniform Instruktionen) gibt es zwar auch seit Volta(?), aber die werden nur für den Kontrollfluss und Schleifenvariablen verwendet); Speicherzugriffe werden per SIMD-Gather- und SIMD-Scatter-Instruktionen abgewickelt, und mehrere scheinbar voneinander unabhängige Kontrollflüsse in einem Hardware-Thread (aka Warp) werden per Predication bzw. per Masking simuliert. All diese Funktionalitäten gibt es so auch in anderen SIMD-Architekturen, wie z.B. x86 mit AVX-512.

Das Einzige, wodurch sich NVIDIA GPUs von "regulären" SIMD-Architekturen (wie z.B. x86 CPUs, AMD GPUs oder Intel GPUs) unterscheiden, ist, dass sie eine Hardware-Beschleunigung für das Masking und das Verwalten eines Mask-Stacks besitzen und dass sie seit Volta bei der Divergenz des Kontrollflusses der SIMD-Lanes in einem Hardware-Thread die dadurch entstehenden Branches out-of-order zueinander ausführen. Aber ich sehe halt nicht, wie diese beiden kleinen Features ein neues Hardware-Modell (mit einer komplett eigenen Terminologie) rechtfertigen, zumal man alles hinreichend mit der gut etablierten SIMD-Terminologie bzw. CPU-Terminologie beschreiben kann.

Auch zerbricht NVIDIAs SIMT-Ansatz wieder an mehreren Stellen, wie z.B. bei Tensor-Instruktionen, da hierfür alle SIMD-Lanes eines Threads zusammenarbeiten müssen, wodurch auch das Masking für Tensor-Instruktionen nicht mehr funktioniert. Zudem musste man z.B. bei GPUs ohne dem Out-Of-Order-Scheduling von Branches immer aufpassen, dass sich die SIMD-Lanes eines SIMD-Threads nicht gegenseitig gedeadlockt haben.

Im Maxwell-Paper steht dazu, dass die "Dual-Issue"-Fähigkeit pro Warp erhalten bleibt, die man aus Kepler bereits kennt und bei Bedarf und wenn es möglich ist, zwei Operationen auf den 32 Rechenkernen ausgeführt werden können. Also entweder eine Operation oder zwei Operationen - wobei hier mit Operationen jetzt die "Instruktion" gemeint ist. Es waren also 2 Operationen nach 2 Takten, oder eine Operation nach einem Takt.

Eine "Shaderpartition" im Maxwell-SM hat eine SIMD-Recheneinheit mit einer physikalischen Breite von 32. Ein Thread (Warp) hat 32 SIMD-Lanes bzw. eine SIMD-Instruktion bezieht sich immer auf alle 32 SIMD-Lanes eines Threads (logische Breite). Dadurch, dass die physikalische Breite gleich der logischen Breite ist, hat diese SIMD-Recheneinheit einen Durchsatz von einer Instruktion pro Takt. Da der Scheduler zwei Instruktionen pro Takt herausgeben kann, kann man diese zusätzliche Instruktion nun noch für etwas anderes verwenden. NVIDIA schreibt selbst dazu im Turing Tuning Guide:

"The power-of-two number of CUDA Cores per partition simplifies scheduling, as each of
SMM's warp schedulers issue to a dedicated set of CUDA Cores equal to the warp width. Each
warp scheduler still has the flexibility to dual-issue (such as issuing a math operation to a
CUDA Core in the same cycle as a memory operation to a load/store unit), but single-issue is
now sufficient to fully utilize all CUDA Cores."

Bei Turing wurde das beibehalten. Nur, dass es jetzt eben ein Datenpfad für Int und ein Datenpfad für FP-Operationen/Instruktionen gibt. Womit mit eben aufgelöst wurde, dass die Sub-Kachel eben auf einen Datentyp festgenagelt wurde.

Auf Turing gibt es dann aber zwei Recheneinheiten mit je einer physikalischen Breite von 16 (wodurch bei einer logischen Breite von 32 eine Einheit nur noch einen Durchsatz von einer halben Instruktion pro Takt besitzt), und eine Shaderpartition kann nur noch eine Instruktion pro Takt herausgeben; "Dual-Issue" wurde entfernt, wodurch sich Blase in den Pipelines der Recheneinheiten bildet, sollte die Shaderpartition eine Instruktion von einem anderen Typ ausführen.

Kepler ist im ganzen relativ "seltsam", weil 192 Shader-Kerne auf 6 4 Warp-Scheduler getroffen ist, die alle Dual-Issue beherrschten. Wodruch es auch bei Kepler dazu kommen konnte, dass sich da was "gegenseitig" blockiert, was sie mit Maxwell aufgelöst haben.

Auf Kepler war das Problem wie gesagt die Registerbandbreite bzw. Registerbankkonflikte, d.h. man musste sehr viel tricksen, dass die Operanden von den beiden pro Takt herausgegebenen Instruktionen immer passend in unterschiedlichen Registerbänken waren, um wirklich an die Peak-Performance zu kommen. Siehe z.B. https://inria.hal.science/hal-00789958/document .

 

[eastcoast_pete]

Schade, daß Nvidia bei der 5080 mit dem RAM geknausert hat. Bei Ada hatte die 4080 2/3 des VRAMs der 4090, jetzt bei Blackwell ist's genau (nur noch) die Hälfte der großen Schwester (5090). Habe den Eindruck, Nvidia behält sich eine 20 oder 24 GB Variante für eine eventuelle 5080 "Super" vor. Damit können sie sich diesmal aber auch Zeit lassen, denn bis auf weiteres wird es weder von AMD noch von Intel eine GPU geben, die der 5080 ernsthaft Konkurrenz machen kann.

@DevPandi : Was mich auch noch interessieren würde ist, ob und wie gut die 5080 auch auf System RAM zugreifen kann, v.a. für KI Modelle? Denn wenn das gehen würde, wär der Anschluss der Karte über 16 PCIE-5 Bahnen auch irgendwie sinnvoll. Zum Spielen reicht ja nach ersten Tests 16 x PCIE-4 völlig aus.

 

[Nai]

@nutrix

Sie sind nicht direkt voller Falschinformationen, sondern verwenden eine bewusst eine irreführende Terminologie, um NVIDIA-GPUs besser dastehen zu lassen als sie eigentlich sind.

Nur zum Beispiel: Was NVIDIA als CUDA-Core bezeichnet, ist eigentlich im klassischen Sinne kein Rechenkern, sondern nur ein Baustein (SIMD-Lane) eines SIMD-Rechenwerks in einem eigentlichen Prozessorkern (aka NVIDIA's Multiprozessor). Ein SIMD-Rechenwerk setzt sich aus mehreren dieser SIMD-Lanes zusammen; jede dieser SIMD-Lanes kann eine Operation pro Takt durchführen. Auch auf SIMD-CPUs (wie x86 mit AVX-512) setzen sich die SIMD-Rechenwerke genauso aus mehreren dieser SIMD-Lanes zusammen. Des Weiteren gibt es auch auf NVIDIA GPUs im klassischen Sinne Prozessorkerne, d.h. weitgehend autonome programmierbare Recheneinheiten mit ihrem eigenen privaten Steuerwerken, Rechenwerken, Registersatz und Caches. NVIDIA bezeichnet diese Prozessorkerne nur als Multiprozessoren.

Dies hat nun zur Folge, dass NVIDIA damit (implizit) werben kann, dass eine Geforce 4090 RTX sage und schreibe 16 384 CUDA-Cores (welche eigentlich ja nur SIMD-Lanes sind) hat, während zum Beispiel ein Ryzen 5950 nur schnöde 16 Cores hat. Und genau solche Vergleiche sah und sieht man sehr oft in Internetforen und auf Newsseiten. Allerdings besitzt beim Ryzen 5950 jeder Kern 4 SIMD-Einheiten mit je 8 SIMD-Lanes, d.h. insgesamt besitzt der Ryzen 5950 512 SIMD-Lanes, wodurch der Ryzen gegenüber den 16 384 SIMD-Lanes der Gefore 4090 RTX deutlich besser dastehen würde. Ebenso besitzt die Geforce 4090 RTX auch nur 128 "echte" Prozessorkerne (aka Multiprozessoren), während der Ryzen 5950 sogar 16 Prozessorkerne hat, d.h. auch bei den echten Prozessorkernen schrumpft der Vorsprung der Geforce 4090 RTX deutlich.

Ein Whitepaper ist doch kein Essay oder beliebiger Roman. Sorry, dann verstehst Du den Sinn dieser Art von Doku nicht oder Deine Herangehensweise ist nicht richtig. Ganz im Gegenteil, ein Whitepaper soll eben nicht zwischen den Zeilen gelesen werden, es soll eindeutige und möglichst widerspruchsfreie Informationen zu technischen Aspekten und Implementierungen liefern, nichts anderes.

Es gibt Whitepaper, die man, ohne zwischen den Zeilen zu lesen, lesen kann. Da erfährt man auch wirklich, wie die GPUs funktionieren. Jedoch gehören die NVIDIA-Whitepaper nicht dazu. Die AMD-Whitepaper sind da deutlich besser, wobei AMD auch etwas Marketing-Terminologie verwendet. Am besten sind immer noch die Intel-Whitepaper, weil diese keinerlei Marketing-Terminologie, sondern nur die reguläre CPU-Terminologie verwenden, um die Intel-GPUs zu beschreiben. Und sowohl bei Intel- als auch bei AMD-Whitepapern taucht der Begriff SIMD sehr häufig auf; nur bei den NVIDIA-Whitepapern fehlt er fast vollkommen, und dies, obwohl die NVIDIA GPUs auch nicht anders funktionieren als die Intel und AMD GPUs. Ansonsten muss man, um mehr über den inneren Aufbau einer NVIDIA-GPU zu erfahren, sich viel bei alternativen Quellen bedienen, die sich allerdings meist nur auf Micro-Benchmarks stützen.

 

[Haldi]

FC....

 

[DevPandi]

Aktuell heißt die route dafür allerdings noch nvapi, oder?

Ob die Neuralsahder bereits per NVAPI genutzt werden können, kann ich dir nicht sagen.

In

Es gibt Whitepaper, die man, ohne zwischen den Zeilen zu lesen, lesen kann.

An der Stelle muss ich dir da soweit zu stimmen, das sie NVIDIA Whitepapera da allgemein etwas mau sind und man vieles nur durch Experimente selbst erfahren kann.

Es wird durch die Namen und Co teilweise aus deutschlich verstärkt.

Ich kann an der Stelle hier aber nur das wiedergeben, was NVIDIA selbst offenlegt.

Ein richtiger Deepdive wäre mal was tolles, aber da braucht man sehr viel Know-How und Zeit.

Deine Aussagen stehen eben gegen die offiziellen von NVIDIA, was die Fähigkeit angeht.

Ich kann nur das verarbeiten was ich sehe und das ist: Maxwell/Pascal: bis zu Zwei Instruktionen mit 32 Threads auf 32 Shader-Kernen, davon entweder Int oder FP.

Ab Turing 2 Instruktionen, eine Int, eine FP mit 32 Threads, ab Ampere/Ada - zwei Instruktionen, eine FP, eine Int oder zwei FP. (Ob auch zwei Int, müsste man mal schauen)

Blackwell ist jetzt wieder bei: 32 Threads, davon entweder INT oder FP. Ob sie weiterhin bis zu zwei Instruktionen ermöglichen oder nur noch eine, das geht aus dem Whitepaper nicht hervor.

Das ist die offizielle „Version“.

 

[Kontrapaganda]

War doch alles erwartbar. NVIDUA befindet sich ein einer Sutuation wie Intel 2018. Ohne Die-Shrink sind sensationelle Effizienzgewinne nun mal nicht drin von einer bereits reifen und stark ausgereuzten Architektur ausgehend. Dafür ist ADA einfach zu gut optimiert. Auch Intel's Skylake war damals in Intel 14nm so ziemlich durchoptimiert. Im gleichen Node geht ausgehend von einer hochoptimierten Architektur eine Leistungssteigerung nur mit der Brechstange (siehe Rocket Lake). Und Brechstangen ziehen bekanntlich Saft und werden heiß.

Ergänzung (Heute um 12:44)

Aufs falsche Pferd gesetzt würde ich da sagen. Kürzlich erst gelesen, dass Samsung einige 4nm-Fabs in den Standby geschickt hat mangels Nachfrage. Währenddessen muss sich NVIDIA jetzt mit TSMC-5nm "begnügen" anstatt auf sparsamere und wahrscheinlich billigere 4nm bei Samsung zu setzen.