GPU-Design [Archiv] - 3DCenter Forum

Archiv verlassen und diese Seite im Standarddesign anzeigen : GPU-Design

lingua

2011-01-29, 22:02:19

An alle Gurus hier im Forum:

Ich habe bis heute nicht kapiert, wie Nvidia / AMD ihre Chips designt.

Warum hat GF110 512 Shader / 64 TMUs / 48 ROPS und nicht in irgend einer Weise weniger / mehr?

Ich meine: Wenn ein Chip grundsätzlich designt wird, um DX11 Compliance zu haben, dann ist das doch nur die halbe Miete.
Gibt es einen Rechenansatz, um den "umgekehrten" Weg zu gehen, auf die gewünschten FPS zu kommen?
Also z.B.: Ich will in dieser Szene (InGame, Annahme) mind. 45 FPS haben. Also habe ich X Dreiecke, X Pixel, X Subpixel, XYZ Daten ?? zu verarbeiten.
Wer sagt nun: Ja da brauche ich 512 Shader, die 1x MADD / Takt mit xMHz Takt können und soundsoviele GB/s Speicherbandbreite. Dazu noch eine Brise Rops und ein paar TMUs und schon ist es gut.

Oder macht man einfach das maximal technisch (Herstellungsprozess) mögliche?

Danke schon mal für Licht in mein Dunkel

Spasstiger

2011-01-29, 22:20:13

Man hat ein bestimmtes Transistorbudget, das durch verfügbare Prozesstechnologien und die angepeilte Marktpositionierung des Chips vorgegeben wird. Dieses Transistorbudget versucht man durch Skalierung des entwickelten Grunddesigns optimal zu füllen. Viele Möglichkeiten gibts meist eh nicht, das Design zu skalieren. Unterstützt wird der Entscheidungsfindungsprozess durch Logiksimulation. Hier kann man auf Basis eines Logikmodells des künftigen Chips quasi Benchmarks durchführen.
Bei der Auslegung des Speicherinterfaces ist außerdem noch relevant, wie komplex man das PCB halten möchte und ob man genug Diefläche für die Kontaktierung der ganzen Speicherleitungen hat. Einen Budget-Chip sieht man nie mit einem 256-Bit-Speicherinterface, weil man dort nicht genügend Kontaktpunkte für die vielen Leitungen unterbringen kann.

lingua

2011-01-30, 10:10:06

Vielen Dank!

Das heißt, der Hersteller simuliert mit Hilfe von Software - der Chip entsteht zuerst in Software?

Geht man dabei den Weg, vorher ein Design ohne "Flaschenhälse" zu konstruieren, um dann - falls das Transistorbudget gesprengt wird - "abzuspecken" und bewusst Schwächen in Kauf zu nehmen? Und wenn ja - nach welchen Kriterien?

Welches Design (AMD / nVidia) ist eurer Meinung nach das "ausgeglichenste" der GPU - Geschichte (vom Standpunkt Shaderleistung/TMUs/ROPs/Speicherbandbreite bzw. deren effektive Leistung)?

Captain Future

2011-01-30, 11:06:18

Bezogen auf "ihre" Zeit: Radeon 9600.

Gaestle

2011-01-30, 11:34:56

Kannst Du das näher ausführen?

Lightning

2011-01-30, 16:44:56

Das heißt, der Hersteller simuliert mit Hilfe von Software - der Chip entsteht zuerst in Software?

Das gilt ganz generell für Hardware. Selbst kleinere Mikrochips sind heute viel zu komplex und fehleranfällig, als dass man ohne Simulation und Automatisierung auskommen könnte (und selbst so kriegt man die Hardware in der Regel nie 100% bugfrei - bei komplexeren Designs kann man nicht jeden einzelnen Fall simulieren). Das bedeutet insbesondere auch: Ohne die Rechenleistung von heute wäre es in der Praxis unmöglich, die CPU- oder GPU-Generation von morgen zu entwickeln. Das baut stark aufeinander auf.

Black-Scorpion

2011-01-30, 17:11:54

Bezogen auf "ihre" Zeit: Radeon 9600.
Wenn schon eine Karte dann die 9700Pro. Ansonsten der R300.

Coda

2011-01-30, 19:19:54

Das heißt, der Hersteller simuliert mit Hilfe von Software - der Chip entsteht zuerst in Software?
Klar. Am Anfang macht man High-Level-Modelierung der einzelnen Komponenten und je weiter die Entwicklung voranschreitet desto mehr Low-Level wird es. Am Ende muss dann eh Gate-Level (oder sogar Transistor-Level) simuliert werden zur Verifikation.

Die Hardwarebeschreibungssprachen haben für diese Zwecke explizit auch die Möglichkeit nichtsynthetisierbaren Code als Platzhalter zu verwenden. Bei SystemC kann dabei beispielsweise beliebiger C++ Code eingesetzt werden.

lingua

2011-01-30, 19:35:12

Bezogen auf "ihre" Zeit: Radeon 9600.

Wieso?

Wenn schon eine Karte dann die 9700Pro. Ansonsten der R300.

Auch hier: Wieso?

Klar. Am Anfang macht man High-Level-Modelierung der einzelnen Komponenten und je weiter die Entwicklung voranschreitet desto mehr Low-Level wird es. Am Ende muss dann eh Gate-Level (oder sogar Transistor-Level) simuliert werden zur Verifikation.

Die Hardwarebeschreibungssprachen haben für diese Zwecke explizit auch die Möglichkeit nichtsynthetisierbaren Code als Platzhalter zu verwenden. Bei SystemC kann dabei beispielsweise beliebiger C++ Code eingesetzt werden.

Danke - das ist mal echt ein Ansatz!

Mann. Woher weißt Du denn das alles? Vorstellen kann ich mir darunter echt wenig.....
High-Level-Modellierung: Grobe Einteilung der Funktionseinheiten?
Low-Level: Umsetzung von Software in Hardware?
Gate-Level / Transistor-Level: ???

Bin dankbar für alles weitere...

lingua

2011-01-30, 19:46:47

..... Dieses Transistorbudget versucht man durch Skalierung des entwickelten Grunddesigns optimal zu füllen. Viele Möglichkeiten gibts meist eh nicht, das Design zu skalieren. Unterstützt wird der Entscheidungsfindungsprozess durch Logiksimulation......

Und das Grunddesign kommt woher? Ich meine eine GF256 war komplett anders aufgebaut als die TNT. Und eine NV40 Karte anders als G80+.

Gibt es "Hausinterne" Design-Wettbewerbe, bei denen die Techniker ihrem Chief mal eben vorlegen, was sie zu tun gedenken und dieser entscheidet dann, was entwickelt wird und wo das Geld hineinfließt?

Gab (gibt) es vielleicht also immer alternative Designs parallel zu den auf den Markt geworfenen?

Und wenn ein Design in die "Hose" geht (z.B. NV30 - wieso eigentlich?) fängt man "neu" an, oder strickt man um?

Abschließend hier: Wenn die Entwicklung einer GPU Jahre beansprucht - woher wissen denn die Ingenieure, welche Direct3D-Spezifikationen in, sagen wir mal, 5 Jahren gefragt sind?

Danke

seaFs

2011-01-30, 20:55:30

[...]
Abschließend hier: Wenn die Entwicklung einer GPU Jahre beansprucht - woher wissen denn die Ingenieure, welche Direct3D-Spezifikationen in, sagen wir mal, 5 Jahren gefragt sind?
[...]

Microsoft und die Kronos Group legen die Spezifikationen schon übere jahre hinweg fest (Roadmap?), sodass sich die Hardwarehersteller frühzeitig daran halten können. Ohne Standards läuft es (zum Glück) nunmal nicht mehr.

lingua

2011-01-30, 21:07:11

Microsoft und die Kronos Group legen die Spezifikationen schon übere jahre hinweg fest (Roadmap?), sodass sich die Hardwarehersteller frühzeitig daran halten können. Ohne Standards läuft es (zum Glück) nunmal nicht mehr.

unter
http://www.khronos.org/
finde ich nur openCL, openGL etc.
Was ist mit Direct3D? Nur von Microsoft?

Lightning

2011-01-30, 21:45:42

High-Level-Modellierung: Grobe Einteilung der Funktionseinheiten?

Das ist schon der richtige Ansatz. Das Level ist die Abstraktionsebene. Je niedriger also das Level, desto mehr betrachtet man die interne funktionsweise der Funktionseinheiten. Gate-Level geht schon auf die rein logische Ebene runter, d.h. die "Bausteine" sind dann logische Verknüpfungen wie AND oder OR. Auf Transistor-Level werden auch diese Bausteine nochmal aufgedröselt. Es gibt dann also praktisch nur noch Transistoren, Leiterbahnen, Stromversorgung.. ist also ziemlich nah an dem dran, wie der Chip dann tatsächlich physikalisch aussieht und verhält.
Das grundsätzliche Design entwirft man also erstmal auf einem hohen Level und modelliert es dann schrittweise immer genauer.

Zu den GPU-spezifischen Fragen äußere ich mich lieber nicht. Ich habe keine Ahnung. ;)

VinD

2011-01-31, 00:41:54

VHDL und design von Microchips (http://astro.uni-tuebingen.de/groups/electronics/VHDL.pdf)

Es gibt mehrere Teams in einem Projekt und immer sind Ingenieure und Physiker am Werke.
Das erste Team besteht aus Physikern und Ingenieuren die leistungsfähige Halbleitertechnologien innerhalb der Zielstruckturgrößen und deren Einschränkungen entwickeln.
Ein zweites Team beschäftigt sich mit der groben Architektur, also den Funktionseinheiten und deren Verknüpfungen, die spezifiziert werden müssen.
Ein drittes Team beschäftigt sich mit Placing und Routing innerhalb und außerhalb des Chips.
Ein viertes Team entwickelt softwareseitig Treiber und Testprogramme.

Zudem ist es ein kontinuierlicher Prozess, die eine Generation baut auf die andere auf. Im Grunde entscheidet hier nur das zweite Team und der Rest ist nur am verbessern ihrer Bereiche.

LG

zappenduster

2011-01-31, 03:51:18

Senior Sanchez

2011-01-31, 09:50:12

Das grundsätzliche Design legt man also entwirft man also erstmal auf einem hohen Level und modelliert es dann schrittweise immer genauer.

Da muss ich mal einen Einwurf machen, auch wenn ich mich eher mit FPGAs ein wenig auskenne. Geht man wirklich heute im Entwurf (damit meine ich den Ingenieur der einen Chip entwirft) noch auf die logische Ebene runter? Ich dachte, dass man das durch Hardwarebeschreibungssprachen (VHDL, Verilog... you name it ;) ) abfackelt, sodass man gar nicht auf diese low-level Ebene kommt.
Der Einzige, der sich dann mit der konkreten Realisierung mit Gattern beschäftigt ist dann derjenige, der den Synthetisierer und die Place & Route Algorithmen entwirft/implementiert/verbessert.

VinD

2011-01-31, 10:42:47

Da muss ich mal einen Einwurf machen, auch wenn ich mich eher mit FPGAs ein wenig auskenne. Geht man wirklich heute im Entwurf (damit meine ich den Ingenieur der einen Chip entwirft) noch auf die logische Ebene runter? Ich dachte, dass man das durch Hardwarebeschreibungssprachen (VHDL, Verilog... you name it ;) ) abfackelt, sodass man gar nicht auf diese low-level Ebene kommt.
Der Einzige, der sich dann mit der konkreten Realisierung mit Gattern beschäftigt ist dann derjenige, der den Synthetisierer und die Place & Route Algorithmen entwirft/implementiert/verbessert.

Der eine macht nen Entwurf und beschreibt ihn in VHDL und der Andere gibt wärend der Syntese die Physikalischen Module an, die verwendet werden sollen.
Dazu wird also einer gebraucht der Gattergruppen auf Physikalischer ebene entwirft. Das ist nötigt da in jeder Struckturgröße leichte änderungen notwendig sind.

Senior Sanchez

2011-01-31, 11:09:57

Der eine macht nen Entwurf und beschreibt ihn in VHDL und der Andere gibt wärend der Syntese die Physikalischen Module an, die verwendet werden sollen.
Dazu wird also einer gebraucht der Gattergruppen auf Physikalischer ebene entwirft. Das ist nötigt da in jeder Struckturgröße leichte änderungen notwendig sind.

Ja, so meinte ich das auch.
Für mich klang es bei Lightning dagegen so, als das derjenige, der den Schaltkreise entwirft bis hinunter zur physikalisch-logischen Ebene geht. Aber ich hab ihn da gerade etwas fehltinterpretiert, denke ich.

deekey777

2011-01-31, 12:30:25

G A S T

2011-01-31, 13:11:36

Welches Design (AMD / nVidia) ist eurer Meinung nach das "ausgeglichenste" der GPU - Geschichte (vom Standpunkt Shaderleistung/TMUs/ROPs/Speicherbandbreite bzw. deren effektive Leistung)?

Bezogen auf NVidia ist das für mich unzweifelhaft der G92/G92b-Chip.
Der bietet bzw. bot ein geradezu optimales Verhältnis von ROPs (16), Shadern (128) und TMUs (64).
Die Speicherbandbreite lag am Ende bei fast 75 GB/s.
Wobei es bei der Bandbreite tatsächlich noch ein bisschen mehr hätte sein dürfen.

Ailuros

2011-01-31, 13:42:14

Bezogen auf NVidia ist das für mich unzweifelhaft der G92/G92b-Chip.
Der bietet bzw. bot ein geradezu optimales Verhältnis von ROPs (16), Shadern (128) und TMUs (64).
Die Speicherbandbreite lag am Ende bei fast 75 GB/s.
Wobei es bei der Bandbreite tatsächlich noch ein bisschen mehr hätte sein dürfen.

Bei verschiedenen Architekturen selbst vom selben IHV ist aber leider "shader" != "shader", TMU != TMU, ROP != ROP usw.

Schoen waere es wenn sterile Einheits-zahlen alles beschreiben wuerden auf verschiedenen GPUs, was aber dann auch heissen muesste dass es zu totalem Technologie-Stillstand kommt und sich nie die Effizienz oder Faehigkeiten einer jeglichen Einheit aendern.

Uebrigens wenn die G92 mehr Bandbreite gehabt haette, haette sie auch wahrscheinlich einen breiteren Bus gehabt (ergo mehr ROPs, was erstmal die "goldene" Analogie oben bricht denn 20 sind mehr als 16) und mehr Speicher was auch wieder auf den Preis gedruckt haette und der Abstand zur G80 waere kleiner gewesen.

Dummerweise hat uebrigens GF114 genauso viele SMs wie auch G92 und beide haben einen 256bit breiten Bus. Neben all den anderen Unterschieden hat 114 eine gewaltig groessere Effizienz was Geometrie, Shading etc betrifft und dank den doppelt so vielen ROPs eine um einiges hoehere 8xMSAA Leistung als einfache Beispiele. Wenn's jetzt um "Einzelheiten" geht dass in GF1xx die TMUs im SM quasi integriert sind und den cache relevanten texturing Aenderungen wird der Tag lang....

=Floi=

2011-01-31, 15:06:22

der G92 war sicherlich nicht ausgewogen. mit TAA geht der karte ganz schnell die luft aus.
shaderpower ohne ende und viel zu wenig bandbreite und vram. die 16 rops gleicht er zum G80 imho durch den mehrtakt aus.
der G80 war eher ausgewogen.

ailuros
meinst du nicht einen anderen GF chip? der 114er hat 384 SMs.

lingua

2011-01-31, 20:28:09

anandtech hatte vor einiger zeit einen sehr guten artikel mit hintergrund wissen zum design bzw. zu den entscheidungen die jahre vor dem erscheinen der chips gefaellt werden glaub das muessten die passenden links sein

r770
http://www.anandtech.com/show/2679
r870
http://www.anandtech.com/show/2937

DANKE! Da ist echt was rauszuholen.....

Das ist schon der richtige Ansatz. Das Level ist die Abstraktionsebene. Je niedriger also das Level, desto mehr betrachtet man die interne funktionsweise der Funktionseinheiten.

Wenn also in einem niedrigen Level Schwierigkeiten auftreten, das zu realisieren, was weiter "oben" vorgegeben ist umzusetzen, dann wird wieder gegengerudert?
Bei GF100 wusste man ganz "unten" vor dem Auflegen der ersten Chips anscheinend nicht gut genug, dass irgend etwas im Interconnect nicht so funktioniert, wie gedacht? (Und musste dem großen Druck nachgeben und trotzdem die Revision A3 verkaufen?)

Bezogen auf NVidia ist das für mich unzweifelhaft der G92/G92b-Chip.
Der bietet bzw. bot ein geradezu optimales Verhältnis von ROPs (16), Shadern (128) und TMUs (64).
Die Speicherbandbreite lag am Ende bei fast 75 GB/s.
Wobei es bei der Bandbreite tatsächlich noch ein bisschen mehr hätte sein dürfen.

Hatten G80 (viel stärker)/ G92 nicht beide letztendlich ein Problem mit der Speicherverwaltung?

Bei verschiedenen Architekturen selbst vom selben IHV ist aber leider "shader" != "shader", TMU != TMU, ROP != ROP usw.

Schoen waere es wenn sterile Einheits-zahlen alles beschreiben wuerden auf verschiedenen GPUs, was aber dann auch heissen muesste dass es zu totalem Technologie-Stillstand kommt und sich nie die Effizienz oder Faehigkeiten einer jeglichen Einheit aendern.

Uebrigens wenn die G92 mehr Bandbreite gehabt haette, haette sie auch wahrscheinlich einen breiteren Bus gehabt (ergo mehr ROPs, was erstmal die "goldene" Analogie oben bricht denn 20 sind mehr als 16) und mehr Speicher was auch wieder auf den Preis gedruckt haette und der Abstand zur G80 waere kleiner gewesen.

Danke - das sehe ich ähnlich, weswegen ich - unabhängig von der Leistungsklasse - nach dem "ausgeglichensten" Chip fragte.....

Nach Deiner Erläuterung kann man aber leider nicht so einfach die Rechenleistung / Filterleistung zu Speicherdurchsatz setzen und vergleichen?
(z.B. G80 verglichen mit G86 oder GF110 mit GF114)
Die Theoretischen Leistungsdaten und die, die abrufbar sind, sind wohl verschiedene Paar Schuhe - aber gibt es da keinen Weg....?

VHDL und design von Microchips (http://astro.uni-tuebingen.de/groups/electronics/VHDL.pdf)

Es gibt mehrere Teams in einem Projekt und immer sind Ingenieure und Physiker am Werke.
Das erste Team besteht aus Physikern und Ingenieuren die leistungsfähige Halbleitertechnologien innerhalb der Zielstruckturgrößen und deren Einschränkungen entwickeln.
Ein zweites Team beschäftigt sich mit der groben Architektur, also den Funktionseinheiten und deren Verknüpfungen, die spezifiziert werden müssen.
Ein drittes Team beschäftigt sich mit Placing und Routing innerhalb und außerhalb des Chips.
Ein viertes Team entwickelt softwareseitig Treiber und Testprogramme.

Zudem ist es ein kontinuierlicher Prozess, die eine Generation baut auf die andere auf. Im Grunde entscheidet hier nur das zweite Team und der Rest ist nur am verbessern ihrer Bereiche.

LG

Danke! Frage wie oben: und der Physiker kann am Ende zu den Ingenieuren sagen - no way guys - you have to start again?

Am Rande noch eine weitere Frage, die vielleicht mit dem Thema zu tun hat:

Wenn man sich das Abschneiden von GeForce GTX465 gegen GTX460 (@Stock) ansieht (beide 256 Bit Varianten), dann kommt es des öfteren vor (TechpowerUP, CB, etc.), dass die GF100 Variante die auf dem Papier mächtigere GF104 Variante (weniger Funktionseinheiten, aber mehr Takt, d.h. die vermeintliche bessere serielle Skalierung verliert gegen die parallele Variante!?) schlägt (natürlich nur in Einzeltests, das Gesamtergebnis geht Zugunsten der GF104 Version aus).
Wieso ist das so? Designunterschiede, die sich so bemerkbar machen?
Wo gibt es da Flaschenhälse?

Und ist letztlich das "ausgewogendste" Design jenes mit den wenigsten Flaschenhälsen?

Fragen über Fragen.....

lg

VinD

2011-01-31, 23:05:56

Danke! Frage wie oben: und der Physiker kann am Ende zu den Ingenieuren sagen - no way guys - you have to start again?

Richtig. Aber er kann es einschrenken. So nach dem Motto "Nicht mit diesem Prozess" oder "nicht mit diesen Timings".

Am Rande noch eine weitere Frage, die vielleicht mit dem Thema zu tun hat:

Wenn man sich das Abschneiden von GeForce GTX465 gegen GTX460 (@Stock) ansieht (beide 256 Bit Varianten), dann kommt es des öfteren vor (TechpowerUP, CB, etc.), dass die GF100 Variante die auf dem Papier mächtigere GF104 Variante (weniger Funktionseinheiten, aber mehr Takt, d.h. die vermeintliche bessere serielle Skalierung verliert gegen die parallele Variante!?) schlägt (natürlich nur in Einzeltests, das Gesamtergebnis geht Zugunsten der GF104 Version aus).
Wieso ist das so? Designunterschiede, die sich so bemerkbar machen?
Wo gibt es da Flaschenhälse?

Und ist letztlich das "ausgewogendste" Design jenes mit den wenigsten Flaschenhälsen?

Fragen über Fragen.....

lg

Serielle Befehle sind besser zu verteilen als parallele. Man beiden allerdings mit Taktanhebung entgegenwirken.... einzelne Ausreißer wird es dennoch geben, wenn eine Anwendung leicht besser auf seriell/parallel ausgelegt ist. Meist kommt es aber auch darauf an was sonst noch so im Chip passiert.

Ailuros

2011-02-01, 08:35:22

ailuros
meinst du nicht einen anderen GF chip? der 114er hat 384 SMs.

Wieso? Ich sagte dass sowohl G92 und GF114 8SMs haben. Der Unterschied ist eben dass G92 [8*(2*8)] und GF114 [8*(3*16)] und genau deshalb sagte ich auch dass "shader" != "shader" sind bei verschiedenen Architekturen. Natuerlich kommt es drauf an was man mit "shader" genau meint, aber es ist auch Bloedsinn auf SP Nivaeu zu vergleichen da man unter 8SPs/G9x und 32SPs/GF1xx keine low end GPU damit bestuecken kann.

Wenn also in einem niedrigen Level Schwierigkeiten auftreten, das zu realisieren, was weiter "oben" vorgegeben ist umzusetzen, dann wird wieder gegengerudert?
Bei GF100 wusste man ganz "unten" vor dem Auflegen der ersten Chips anscheinend nicht gut genug, dass irgend etwas im Interconnect nicht so funktioniert, wie gedacht? (Und musste dem großen Druck nachgeben und trotzdem die Revision A3 verkaufen?)

Was jetzt genau nicht stimmte beim GF100 ist weniger wichtig (koennte eine Kombination an Problemen sein) als dass sie tatsaechlich keine andere Wahl als den chip kastriert (ein SM weniger und leicht niedrigere Frequenz als projeziert) auf die Regale unter Konkurrenz-druck bringen mussten.

Hatten G80 (viel stärker)/ G92 nicht beide letztendlich ein Problem mit der Speicherverwaltung?

Das Treiberteam muss sich lediglich etwas mehr anstrengen das Ganze pro Produkt anzupassen. Aber da die Masche sich schon seit G80/2006 existiert ist heutzutage kein besonderes Problem mehr IMHO.

Nach Deiner Erläuterung kann man aber leider nicht so einfach die Rechenleistung / Filterleistung zu Speicherdurchsatz setzen und vergleichen?
(z.B. G80 verglichen mit G86 oder GF110 mit GF114)
Die Theoretischen Leistungsdaten und die, die abrufbar sind, sind wohl verschiedene Paar Schuhe - aber gibt es da keinen Weg....?

GPUs sind eben leider komplizierte Tiere. Eine einfache Formel der Art so und so und viel Einheiten * Frequenz bringt eben zu nichts. Neben den jeweiligen Faehigkeiten jeglicher Einheit pro Generation kommen auch oefters DX bedingte Aenderungen rein wie z.B. im Fall von GF1x0/DX11.

Wenn Du jetzt einen GT200 und einen GF100/110 vergleichst dann hast Du auf dem ersten 1 rasterizer/trisetup wobei der erste bis zu 32 pixels/clock bearbeiten kann. Beim zweiten hast Du dann 4 rasterizer/trisetups wobei jeder raster ueber 8 pixels/clock faehig ist. Ohne Tessellation macht es dann auch keinen Unterschied in heutigen Applikationen, mit Tessellation (worueber die GT200 erstmal gar nicht faehig ist) geht der Spass bei GF1x0 erstmal los.

GF100/110 haben zwar 48 ROPs aber dass sollte nicht heissen dass diese durch ihre raster units bis zu 48 pixels/clock bearbeiten koennen. Wie gesagt pro raster/8 pixels/clock und insgesamt 32 pixels/clock rasterizing. Der "Ueberschuss" an 16 ROPs ist fuer zusaetzlichen 8xMSAA oder anderen high sample AA Schnickschnack den NV hier etwas umstaendlich eingebaut hat im Vergleich zu Radeons aber es ist auch nicht besonders wichtig fuer die Beispiele hier.

Eine sehr wichtige Aenderung auf GF1x0 im Vergleich zu GT200/G8x/9x was TMUs betrifft, ist dass diese diesmal in die SMs quasi "integriert" wurden und die relevanten caches fuer texturing so erweitert dass sich die Effizienz um einiges gesteigert hat. In dem Fall und wie man in heutigen Applikationen sieht fehlen den GF100/110 nicht wirklich TMUs obwohl 4 TMUs/SM im Gegensatz zu 8 TMUs/SM.

GF104/114 sind dann natuerlich andere Tiere da sie tatsaechlich 8 TMUs/SM haben aber es ist eine generell Ausnahme fuer die gesamte Fermi/GF1xx Familie da die kleineren GF1xx als 104/114 auch nicht die gleiche Logik folgen. NV brauchte einen mainstream chip der sich stark unterhalb vom high end Bereich behaupten kann und deshalb moebelten sie auch die SMs auf (3*16) 48SPs/SM auf.

Eine perfekte Balance zwischen Einheiten/Effizienz/Leistung wird man wohl schwer finden. IHVs versuchen lediglich von ihrem jeweiligen groessten chip eine Kombination von Fuellraten, Bandbreite, Geometrie und weiss der Geier was noch zu finden damit man eventuell quasi 70, 50, 30% usw von diesem fuer kleinere Modelle zu erreichen. Je flexibler die unterliegende Architektur desto einfacher ist dann auch die Skalierung nach unten.

Ein guter Punkt waere bei heutigen GPUs an clusters bzw. SMs zu denken und was jeglicher dieser haben koennte (so und so viele SPs/SM, so und so viele TMUs usw.) da die Anzahl von clusters auch in der Zukunft hoechstwahrscheinlich nicht so radikal wachsen wird. In der DX11 era haben wir auch eine Art "mega-clusters" wobei sie NV "GPCs" nennt; jeglicher GPC (welches wohl eher eine virtuelle Aufteilung ist) auf GF100/110 hat bis zu 4 SMs/1 rasterizer/1 trisetup. Bei einem Cayman koennte man virtuell auch seine 24 clusters auf 2*12 mit je einem raster/trisetup/Tessellations-Einheit aufteilen. IMHO werden diese beiden Aufteilungen auch fuer kommende Architekturen wichtig sein.

Was jetzt ROPs am unteren Ende betrifft, NV setzt seit G80 auf einem breiteren Bus (384bit, 512bit, 384bit) mit jeweils 4 oder 8 ROPs/partition je nach Fall. Jede partition gleicht 64bit ergo bei 512bit/GT200 8*64bit = 8*4ROPs= 32 ROPs, bei GF110/110 dann 6*64bit = 6*8ROPs= 48 ROPs.

Am Rande noch eine weitere Frage, die vielleicht mit dem Thema zu tun hat:

Wenn man sich das Abschneiden von GeForce GTX465 gegen GTX460 (@Stock) ansieht (beide 256 Bit Varianten), dann kommt es des öfteren vor (TechpowerUP, CB, etc.), dass die GF100 Variante die auf dem Papier mächtigere GF104 Variante (weniger Funktionseinheiten, aber mehr Takt, d.h. die vermeintliche bessere serielle Skalierung verliert gegen die parallele Variante!?) schlägt (natürlich nur in Einzeltests, das Gesamtergebnis geht Zugunsten der GF104 Version aus).
Wieso ist das so? Designunterschiede, die sich so bemerkbar machen?
Wo gibt es da Flaschenhälse?

Und ist letztlich das "ausgewogendste" Design jenes mit den wenigsten Flaschenhälsen?

GTX465 war eine Schnappsidee seitens NV IMO, da es ein zu kastrierter GF100 war der zu kurz vor dem GF104/GTX460 erschien.

Wie gesagt NV brauchte einen mittleren chip der eventuell an die untere Grenze von high end chips reichen kann. 465 fiel einfach viel zu tief mit seinen wenigen aktiven SMs und Frequenz (ergo auch IMHO = Schnappsidee).

GF100/110 sind als chips ungefaehr 530/520mm2 gross, waehrend GF104/114 um die 370/360mm2 jeweils liegen. Je kleiner die die area desto billiger die Herstellung und desto konkurrenzfaehiger gegen die performance chips der Konkurrenz (Cypress/Cayman) die ohnehin schon verdammt klein sind. NV brauchte also etwas dass nicht allzu viel mehr kostet herzustellen als die konkurrierenden chips und bis zu einem Grad vergleichbare Leistung liefert (siehe 6950 1GB vs. GTX560Ti als Beispiel).

Man hilt sich eben nur auf 8SM Nivaeu, 2 rasterizer/2 trisetups (ergo die Haelfte von GF100/110), versorgte aber jeglichen SM erstmal mit 3*16 anstatt 2*16 SPs und natuerlich anstatt 4TMUs/SM mit 8TMUs/SM. Und natuerlich wie erwaehnt ist 104/114 im Vergleich zu den grossen und kleineren chips der Familie eine Ausnahme. Jegliche diesbezuegliche Design-Entscheidung fuer 104/114 hat seine tradeoffs; eine konstante win-win Situation wird es nie sein. Hauptsache ist aber dass der chip das erreicht fuer das was er entwickelt und angepasst wurde.

Coda

2011-02-01, 14:06:28

GF100/110 haben zwar 48 ROPs aber dass sollte nicht heissen dass diese durch ihre raster units bis zu 48 pixels/clock bearbeiten koennen. Wie gesagt pro raster/8 pixels/clock und insgesamt 32 pixels/clock rasterizing. Der "Ueberschuss" an 16 ROPs ist fuer zusaetzlichen 8xMSAA oder anderen high sample AA Schnickschnack den NV hier etwas umstaendlich eingebaut hat im Vergleich zu Radeons aber es ist auch nicht besonders wichtig fuer die Beispiele hier.
Es gibt keinen Überschuss. Die ROP-Leistung hat nichts mit dem Rasterizing zu tun.

Das hab ich dir auch schon mindestens einmal erklärt.

Ailuros

2011-02-01, 14:16:59

Es gibt keinen Überschuss. Die ROP-Leistung hat nichts mit dem Rasterizing zu tun.

Das hab ich dir auch schon mindestens einmal erklärt.

Dann formuliere ich es anders: wenn NV nicht auf einen so breiten Bus setzen wuerde und anstatt an hoeher getakteten Speicher, wuerden sie theoretisch auch nicht mehr als 32 ROPs auf einem GF100/110 brauchen. Besser so? Anfuehrungs-striche werden uebrigens aus gutem Grund verwendet. Nit-picker :P

Compared to 8 in the GT200 the GF100 has 6 ROP partitions – this is linked to its 384-bit memory bus. There are now 8 ROPs in each partition instead of 4 however, which brings the total to 48 as against 32 for the GT200. They have exactly the same specificities except that the GF100 implements 32x CSAA (8x MSAA + 24 coverage samples). NVIDIA has also introduced driver support for the use of CSAA coverage samples for surfaces rendered with alpha-to-coverage to give better quality transparency antialiasing.

Without antialiasing the 48 ROPs won’t be fully used however. You can therefore expect a fillrate that correspons to about 32 ROPs. NVIDIA aren’t trying to trick us with respect to the spec however. Remember the 4 rasterizers together produce 32 pixels per cycle and it isn’t therefore possible to store 48 per cycle to memory. Note we say “about” because the rasterizers and ROPs don’t run at the same clock.

Why 48 ROPs then? As well as providing for the 384-bit memory bus (without which it would be limited to a 256-bit bus), they also guarantee good performance with antialiasing. As its compression can’t be maximised (it would then mean that antialiasing is useless) antialiasing adds an additional load to the ROPs which will have more data to write to memory.

http://www.behardware.com/articles/782-5/nvidia-geforce-gf100-the-geometry-revolution.html

=Floi=

2011-02-01, 18:11:49

Ailuros

2011-02-01, 21:03:51

sorry
ich habe SM mit SPs verwechselt.

so ganz verstehe ich das immer noch nicht. mit den 48 ROPs. Das könnte mal bitte jemand wirklich ausführlich erklären. Umgedreht macht das fixieren auf 1xAA auch keinen wirklichen sinn.

Nochmal jegliche ROP partition ist fuer jegliches 64bit von der Busbreite. Da es ein 384bit Bus auf GF100 ist sind es 6 partitions. Jegliche partition hat 8 ROPs, ergo 6*8 = 48 ROPs.

Coda's Haarspalterei zur Seite hat GF100 nicht eine Pixel-Fuellrate von 48*675MHz = 32.4 GPixels/s (wenn die ROPs wirklich auf so viel takten, ich weiss nicht mehr wo der Takt hier genau liegt) sondern 32*675MHz = 21.6 GPixels/s. Wie Damien im vorigen Link erwaehnt GF100 kann keine 48 pixel/clock im Speicher unterbringen.

Die 48 ROPs sind da wegen dem 384bit bus und um gleichzeitig die AA Effizienz zu erhoehen. Einfacher geht es nicht.

Sonst wenn Du noch tiefer reinlesen willst:

http://www.behardware.com/articles/787-7/report-nvidia-geforce-gtx-480-470.html

In spite of having 48 ROPs the GeForce GTX 480 is limited to 32 pixels per cycle, or less. Strangely, at a higher clock, it is generally a hair’s breadth behind the GeForce GTX 285, with two exceptions. The first of these is with a single 32-bit channel surface where the GF100 does better. The second is with 128-bit blending that is very demanding in terms of bandwidth.

Strangely, while it is to be expected that the GeForce GTX 400s be limited upstream of their ROPs, this is a limitation lower down than we would have expected. What’s more, they can’t use all their ROPs at 64 and 128-bit formats. Nvidia told us that the reason for this extra limitation we noticed is linked to the datapath between SMs and ROPs. I can only accommodate for 32x 32-bit pixels per cycle. With any higher format it becomes a bottleneck. Overall 48, and even 40 ROPs, are a bit of a waste with such a design and gets useful only when there's extra work to do when antialiasing compression is not working.

lingua

2011-02-01, 22:10:05

Serielle Befehle sind besser zu verteilen als parallele. Man beiden allerdings mit Taktanhebung entgegenwirken.... einzelne Ausreißer wird es dennoch geben, wenn eine Anwendung leicht besser auf seriell/parallel ausgelegt ist. Meist kommt es aber auch darauf an was sonst noch so im Chip passiert.

Danke.
Die GF104 Variante (GTX460) hat hier aber den viel höheren Takt als die GF100 (GTX465) Variante. Konkret performt aber die vielleicht leichter auszulastende serielle Variante manchmal langsamer, als die parallel Stärkere. Wenn hier die Rede von der Rolle der Anwendung ist - hat hier der Treiber nicht vorher noch ein Wörtchen mitzureden (und welche)?

Was jetzt genau nicht stimmte beim GF100 ist weniger wichtig (koennte eine Kombination an Problemen sein) als dass sie tatsaechlich keine andere Wahl als den chip kastriert (ein SM weniger und leicht niedrigere Frequenz als projeziert) auf die Regale unter Konkurrenz-druck bringen mussten.
.
.
.
Man hilt sich eben nur auf 8SM Nivaeu, 2 rasterizer/2 trisetups (ergo die Haelfte von GF100/110), versorgte aber jeglichen SM erstmal mit 3*16 anstatt 2*16 SPs und natuerlich anstatt 4TMUs/SM mit 8TMUs/SM. Und natuerlich wie erwaehnt ist 104/114 im Vergleich zu den grossen und kleineren chips der Familie eine Ausnahme. Jegliche diesbezuegliche Design-Entscheidung fuer 104/114 hat seine tradeoffs; eine konstante win-win Situation wird es nie sein. Hauptsache ist aber dass der chip das erreicht fuer das was er entwickelt und angepasst wurde.

Danke. Uff. Da habe ich je erstmal was zu verdauen......

Das Stichwort "Balance" habe ich mir besonders herausgestrichen: Das kommt im Kontext am ehesten zu dem von mir als "ausgeglichen" gesuchten Chip.

Dazu habe ich am Anfang des Threads mal die Frage gestellt: Gibt es keinen Rechenweg, der mir aus einer realen Szene heraus (=Game) bestimmen kann, wie viele Einheiten ich brauche, um mindestens xFPS zu erhalten?
Wenn bekannt ist, welche Gesamtlast ich bei bestimmer Auflösung und Shaderlast/Dreiecken/Z-Last/Auslastung Speicherbandbreite etc. erhalte, könnte ich doch das Design daraufhin ausrichten?
So könnte man in Kooperation mit den Spiele-Publishern schon im Vorhinein eingrenzen: das könnt ihr machen, das macht die Hardware mit....

Welche Rolle spielt den der Treiber insgesamt?

Btw: Die GTX 465 "Schnappsidee" brachte wenigstens eine Sache: weiteren Einblick in die Skalierbarkeit / Effizienz des GF100-Designs.

lg

=Floi=

2011-02-02, 00:35:32

mir geht es mehr um die AA effizienz. den link gucke ich mir morgen mal an.

edit
die spiele sind viel zu unterschiedlich. das sah man recht schön am R600 von ati, weil der mal richtig gut und dann wieder richtig schlecht war und diese schwankungen eher negativ wie positiv waren. der G80 dagegen war überall schnell und das macht ein gutes design auch aus. das ist eigentlich noch wichtiger wie die relative performance imho.

Ailuros

2011-02-02, 07:59:40

Das Stichwort "Balance" habe ich mir besonders herausgestrichen: Das kommt im Kontext am ehesten zu dem von mir als "ausgeglichen" gesuchten Chip.

Dazu habe ich am Anfang des Threads mal die Frage gestellt: Gibt es keinen Rechenweg, der mir aus einer realen Szene heraus (=Game) bestimmen kann, wie viele Einheiten ich brauche, um mindestens xFPS zu erhalten?
Wenn bekannt ist, welche Gesamtlast ich bei bestimmer Auflösung und Shaderlast/Dreiecken/Z-Last/Auslastung Speicherbandbreite etc. erhalte, könnte ich doch das Design daraufhin ausrichten?
So könnte man in Kooperation mit den Spiele-Publishern schon im Vorhinein eingrenzen: das könnt ihr machen, das macht die Hardware mit....

IHVs koennen solche Aspekte intern ausrechnen bzw. simulieren. Bei der DX11 (und auch jeglicher neuen DX-Generation) haben die IHVs es generell etwas schwerer denn man muss sowohl alle API Vorraussetzungen in hw unterstuetzen koennen und auch gleichzeitig fuer sagen wir mal eine bis zu 2x Mal so hohe Leistungs-steigerung im Vergleich zur vorigen Architektur erreichen. Das Problem ist dann eben dass X die area fuer Y Herstellungs-prozess nicht unendlich ist.

Hier kommt es oefters vor dass Funktionalitaeten vom neuen API zwar unterstuetzt werden, aber man sich wirklich auf hoehere Leistung dieser in zukuenftigen Refreshes kuemmert (wo auch ein kleinerer Herstellungs-prozess eingesetzt werden kann und man daher auch mehr Luftraum hat mehr Transistoren bzw. mehr die area zu benutzen).

Bei einem jeglichen Refresh einer Architektur ist es dann um einiges leichter. Der IHV hat in der Zwischenzeit sehen koennen an welchen Stellen es noch Luftraum von Verbesserungen gibt und auch wo die Konkurrenz besser punkten kann. Es kommt aber dann auch auf die eigentliche Flexibilitaet jeglicher Architektur an, die leider auch nicht unendlich ist.

Bloedes Beispiel: angenommen Du hast heute eine Architektur X mit jeweils 4 TMUs pro cluster. Analysen zeigen dass Y mehr Fuellrate brauchen koennte diese aber eher analog zu 5 oder 6 TMUs/cluster sind. Da TMUs von Grund auf mit quads arbeiten gibt es keinen anderen Ausweg als an 8 TMUs/cluster zu denken. Man hat zwar in solch einem Fall die zusaetzliche Fuell-rate von den der chip profitieren kann garantiert, aber ein gewisser Grad an Redundanz steckt wohl auch drin.

Das Ziel sollte sein dass eine jegliche "pipeline" so balanciert wie moeglich ist fuer all die Faelle an die sie fuer ihre Lebenszeit in Echtzeit stossen koennte. Damit aber IHVs eine solche Balance erreichen koennen muessen sie eine Unzahl an Faktoren und Moeglichkeiten mitberechnen und es darf der pipeline eben nicht an arithmetischer Effizienz, Fuell-rate, Bandbreite usw. fehlen.

Eben weil chips heutzutage viel zu kompliziert sind und jeglicher mm2 verdammt wichtig ist, halten sich heutzutage IHVs auch davon fern irgendwelchen proprietary Schnickschnack der nicht vom API unterstuetzt wird einzubauen. Hier sind beide IHVs mit diversen Ideen in der Vergangenheit auf die Nase gefallen.

Welche Rolle spielt den der Treiber insgesamt?

Eine verdammt wichtige. Gute hw braucht auch gute sw und umgekehrt. Es darf weder beim einen noch beim anderen Bereich hapern.

Btw: Die GTX 465 "Schnappsidee" brachte wenigstens eine Sache: weiteren Einblick in die Skalierbarkeit / Effizienz des GF100-Designs.
lg

Fermi ist ein ziemlich ambitionsreiches Projekt was Geometrie bzw. Tessellation betrifft. Haette NV anstatt dem GF104/114/8 SM einen alternativen chip mit 12 SMs als Beispiel gebaut, haetten sie zwar die gleiche Leistung erreichen koennen wie beim vorigen, aber da die GPCs bzw. raster/trisetups/tessellation units pro SM und die ganze Verdrahtung dieser nicht umsonst sind haette es vielleicht mehr die area eingenommen als heute bei 104/114. Teurer herzustellen als der direkte Konkurrent und womoeglich auch hoeheren Stromverbrauch.

Sie haben sich einfach eine Zwischenloesung zusammengeschustert die den Marktbereich den so ein chip anspricht decken kann. Uebertriebene Tessellations-raten braucht man auf so einem performance chip sowieso nicht und es lassen sich auch einige Stellen durch hoehere Frequenzen (114) ueberbruecken. Und so einen chip kann NV dann eventuell ueber zukuenftige die shrinks (siehe 28nm und co.) mit grosszuegigen Frequenz-Steigerungen bis zum geht nicht mehr ausmelken.

Beim G92 war es ja auch nicht anders, die es immer noch heute als lower end Angebot gibt.

mir geht es mehr um die AA effizienz. den link gucke ich mir morgen mal an.

Wie Damien sagt die 48 ROPs (oder sogar 40 ROPs bei 320bit) auf GF100/110 eine der Faelle wo sie Sinn machen ist wenn AA Kompression versagt (gibt es ueberhaupt solche Faelle heutzutage?). Sonst eben wohl auch obszoene sample-Anzahlen u.a. auch 32x CSAA.

Ausser ich hab irgend etwas verpasst ist die hw zwar darueber faehig diesmal coverage samples auf transparency AA samples zu "uebertragen" (anders man sollte bei 32xCSAA auch 32xTMAA zuschalten koennen egal ob 32xCSAA im Grund nur 8x sample MSAA enthaelt), wurde aber nie im Treiber eingeschaltet. Als ich NV fragte ob etwas mit der hw nicht stimmt das es nie eingeschaltet wurde, war die Antwort trocken dass die hw kein Problem hat aber sich das Treiberteam sich nicht damit beschaeftigt hat weil kein Schwein mit CSAA bencht (*mitdemKopfgegendieWandrenn*).

edit
die spiele sind viel zu unterschiedlich. das sah man recht schön am R600 von ati, weil der mal richtig gut und dann wieder richtig schlecht war und diese schwankungen eher negativ wie positiv waren. der G80 dagegen war überall schnell und das macht ein gutes design auch aus. das ist eigentlich noch wichtiger wie die relative performance imho.

R600 war von einigen bloeden Design-Entscheidungen und ein paar hw bugs geplagt. NV hat durch ihre Geschichte auch solche (nicht direkt vergleichbare) Leichen in ihrem Keller. Solche Faelle sind aber generell eher Aussnahmen als die Regel.

Reaping_Ant

2011-02-03, 08:14:54

Die GF104 Variante (GTX460) hat hier aber den viel höheren Takt als die GF100 (GTX465) Variante. Konkret performt aber die vielleicht leichter auszulastende serielle Variante manchmal langsamer, als die parallel Stärkere.

Die GTX 465 mag zwar insgesamt mehr SPs haben als die GTX 460, allerdings sollte man auch beachten, dass letztere 3x16 statt 2x16 SPs pro SM hat, innerhalb der SMs also sogar staerker parallelisiert ist. Es ist daher tendenziell schwieriger einen der 7 SMs der GTX 460 voll auszulasten als einen der 11 SMs der GTX 465.
Ich meine sogar gelesen zu haben, dass von den 3x16 SPs im worst case tatsaechlich nur 2x16 SPs ausgelastet werden, ein GF104 SM also u.U. nicht schneller als ein GF100 SM ist. Scheint aber in der Realitaet nur selten aufzutreten.

lingua

2011-02-03, 21:57:17

@ all: Danke.
Schön langsam kann ich mir etwas mehr darunter vorstellen.....(obwohl das Thema nicht erschöpft ist...:rolleyes:)

Ich meine sogar gelesen zu haben, dass von den 3x16 SPs im worst case tatsaechlich nur 2x16 SPs ausgelastet werden, ein GF104 SM also u.U. nicht schneller als ein GF100 SM ist. Scheint aber in der Realitaet nur selten aufzutreten.

Echt?
Hab ich noch nie gehört. Hast Du Unterlagen?

lg

Reaping_Ant

2011-02-04, 06:53:18

Hab ich noch nie gehört. Hast Du Unterlagen?

Das war bei Anandtech (http://www.anandtech.com/show/3809/nvidias-geforce-gtx-460-the-200-king/2). Im zweitletzten Absatz auf der Seite:
The ability to extract ILP from a warp will result in GF104’s compute abilities performing like a 384 CUDA core part some of the time, and like a 256 CUDA core part at other times.

Ailuros

2011-02-04, 09:02:55

Das war bei Anandtech (http://www.anandtech.com/show/3809/nvidias-geforce-gtx-460-the-200-king/2). Im zweitletzten Absatz auf der Seite:

Ja aber dass die 104/114 SMs nicht insgesamt schneller sind als 100/110 SM stimmt auch nicht. Ich befuerchte dass der gesamte Text im Abschnitt im Anand Artikel etwas mehr helfen koennte:

Ultimately superscalar execution serves 2 purposes on GF104: to allow it to issue instructions to the 3rd CUDA core block with only 2 warps in flight, and to improve overall efficiency. In a best-case scenario GF104 can utilize 4 of 7 execution units, while GF100 could only utilize 2 of 6 execution units.

The upside to this is that on average GF104 should be more efficient per clock than GF100, which is quite a remarkable feat. The downside to this is that now NVIDIA has a greater degree of best and worst case scenarios, as requiring superscalar execution to utilize the 3rd CUDA core block means that it’s harder to use that 3rd block than the previous 2. The ability to extract ILP from a warp will result in GF104’s compute abilities performing like a 384 CUDA core part some of the time, and like a 256 CUDA core part at other times. It will be less consistent, but on average faster than a pure 256 CUDA core part would be.

http://www.anandtech.com/show/3809/nvidias-geforce-gtx-460-the-200-king/2

Das obrige gilt aber auf einer gleichgetakteten Basis. GTX560 ALUs sind momentan auf >1.6GHz getaktet, waehrend die GTX580 ALUs auf >1.5GHz liegen. Wunder sollte man keine erwarten, aber gewisse tradeoffs hat diese Loesung fuer einen performance chip with GF114 schon. Ueberhaupt im Vergleich zu einer hypothetischen 256SP (2*16/SM) Loesung bei wieder 8SMs.

Insgesamt duerfte die GF114 Loesung effizienter sein (auch dank hoeherer Taktung) als ein hypothetischer 12SM chip bei niedrigerer Taktung.

Captain Future

2011-02-04, 09:45:38

Ailuros

2011-02-04, 10:35:27

Hier gibt es auch noch einige Low-Level-Werte:
http://www.gpu-tech.org/content.php/139-Is-GF104-106s-superscalar-design-really-an-improvement

Offenbar macht das neue Design erst bei längeren Shadern Sinn, kurze Instruktionsfolgen brechen stark ein.

Sehr interessant. Zwar waere es noch schoen zu wissen wo schaetzungsweise der Durchschnitt von shader Instruktionen in heutigen Spielen liegt, aber wie der Author selber notiert ist die Tendenz hier wohl steigend in Richtung laenger. Eine pipeline utilization von bis zu 99% ist wirklich sehenswert.

Captain Future

2011-02-04, 19:41:54

Kannst Du das näher ausführen?
Wieso?

Weil der RV360 ein schlanker, günstiger Chip war, der mindestens in seiner schnellsten Bauform, der 9600 XT, durchweg alles spielbar machte, dabei sparsam und leicht zu kühlen war.

Er hatte nicht ein solches Überangebot an Leistung, dass man die Hälfte der Zeit im CPU-Limit hing usw.

Welches Design (AMD / nVidia) ist eurer Meinung nach das "ausgeglichenste" der GPU - Geschichte (vom Standpunkt Shaderleistung/TMUs/ROPs/Speicherbandbreite bzw. deren effektive Leistung)?
Wenn schon eine Karte dann die 9700Pro. Ansonsten der R300.

Der R300 war der Panzer, der RV360 ein schlanker Killer.

Gipsel

2011-02-04, 20:02:03

Eine pipeline utilization von bis zu 99% ist wirklich sehenswert.
Bekommst Du mit solchem Testcode aber eigentlich meist recht gut hin. Auf allen GPUs. Und auch bei CPUs kannst Du solche Tests fahren und bekommst meist praktisch exakt den Durchsatz aus dem Datenblatt.

Interessant wird es im Prinzip erst, wenn es mal nicht klappt (wie bei den "missing MULs" des G80/G92/GT200). Das kann dann helfen, Flaschenhälse oder Beschränkungen zu identifizieren, die in den Datenblättern und Manuals "vergessen" wurden.

Ailuros

2011-02-05, 10:12:45

Bekommst Du mit solchem Testcode aber eigentlich meist recht gut hin. Auf allen GPUs. Und auch bei CPUs kannst Du solche Tests fahren und bekommst meist praktisch exakt den Durchsatz aus dem Datenblatt.

Interessant wird es im Prinzip erst, wenn es mal nicht klappt (wie bei den "missing MULs" des G80/G92/GT200). Das kann dann helfen, Flaschenhälse oder Beschränkungen zu identifizieren, die in den Datenblättern und Manuals "vergessen" wurden.

Dass es ein "best case scenario" ist ist mir schon klar. In dem Fall ist der imposante Teil dann halt dass sie um nur ein paar Prozente besser dastehen als bei einem GF1x0 SM.

Natuerlich wird Echtzeit und dessen Durchschnitt ein ganz anderes Bild malen aber NV hat ja auch lediglich fuer eine Loesung mit tradeoffs gesucht fuer GF104/114 um ca. 2/3 der GF100/110 Leistung in nur 8SMs quetschen zu koennen.

Gaestle

2011-02-05, 11:31:45

Weil der RV360 ein schlanker, günstiger Chip war, der mindestens in seiner schnellsten Bauform, der 9600 XT, durchweg alles spielbar machte, dabei sparsam und leicht zu kühlen war.

Er hatte nicht ein solches Überangebot an Leistung, dass man die Hälfte der Zeit im CPU-Limit hing usw.

Ah, danke.

davidzo

2011-02-05, 17:53:40

zum chipdesign:
http://www.youtube.com/watch?v=z47Gv2cdFtA

man sieht, es ist eigentlich ganz einfach und ein künstlerischer Beruf: Schließlich geht es um Artwork!
Here's a fullscale 30 by 30 inches piece of typical integrated Circuit Artwork!
Silicon costs about like diamond
The Package is now revealed in its magnificient beauty

Lass uns das doch mal eben diskutieren, ja nicht wenn wir schonmal dabei sind einen kleinen modell grafikchip entwickeln. wieso nicht?
das video zeigt ja beinahe nach anleitung wie das geht. so ein paar hundert millionen transistoren kriegen wir hier im 3dcenter forum doch mit vereinten kräften doch wohl kreirt, kann doch nicht sein, dass man für sowas studieren muss und auch noch außergewöhnlich hohe IQs und Abschlüsse braucht um bei firmen wie nvidia und intel an vorderster front arbeiten zu dürfen. das kann doch Jedermann!

VinD

2011-02-12, 10:19:47

OpenSourceHardware:

http://wiki.opengraphics.org/tiki-index.php

ist ja kein Aufwand ;)

ENKORE

2011-02-14, 21:47:57

Hier gings aber um - sozusagen ASICs - (ja ich weiss, dass das noch etwas leicht anderes ist, hier aber nicht von Interesse) und nicht unbedingt darum einen FPGA mit einem DVI Ausgang zu versehen ;) Das ist zwar wesentlich effizienter, weniger fehleranfällig, reusable und einfacher, kostet aber auch keine 60k USD.

G A S T

2011-02-16, 16:09:07

Bei verschiedenen Architekturen selbst vom selben IHV ist aber leider "shader" != "shader", TMU != TMU, ROP != ROP usw.

Ja stimmt. Und?

Uebrigens wenn die G92 mehr Bandbreite gehabt haette, haette sie auch wahrscheinlich einen breiteren Bus gehabt (ergo mehr ROPs, was erstmal die "goldene" Analogie oben bricht denn 20 sind mehr als 16) und mehr Speicher was auch wieder auf den Preis gedruckt haette und der Abstand zur G80 waere kleiner gewesen.

Nö, doch nicht zwangsläufig. Höhere Bandbreite geht (neben dem Bus) entweder über höheren GDDR-Takt oder eben über effektiveres "Rüberscheffeln" mit GDDR 4 oder 5.
Abgesehen davon geht es doch auch gar nicht darum -> siehe Frage des TE!
Ich machte diese Bemerkung ja nur, da ich ebenso wie =Floi= die Einschätzung bezüglich der Bandbreite Teile. Von nichts anderem habe ich geschrieben.
Hatten G80 (viel stärker)/ G92 nicht beide letztendlich ein Problem mit der Speicherverwaltung?
Ja. Allerdings war der RAM am Ende trotz suboptimalem Speichermanagement absolut ausreichend. Da gehe ich mit =Floi= nicht konform. Denn er kann so auf keinen Fall behaupten, dass der G80 mit seinen 768 MB gegen die 1024 MB des G92(b) ausgewogener sein kann.
Die "Uraltfassung" 8800 GTS war zweifelsohne eine Speicherkrüppel, ja. Aber um diese Betrachtung geht es doch nicht. Wir wissen doch alle warum er als Krüppel zur Welt kam - damit er die GTX und Ultra nicht vernascht. Und zudem hat der quantitative RAM-Ausbau erst mal überhaupt nichts mit dem Chip bzw. dessen Ausgewogenheit zu tun. :P

Dummerweise hat uebrigens GF114 genauso viele SMs wie auch G92 und beide haben einen 256bit breiten Bus. Neben all den anderen Unterschieden hat 114 eine gewaltig groessere Effizienz was Geometrie, Shading etc betrifft und dank den doppelt so vielen ROPs eine um einiges hoehere 8xMSAA Leistung als einfache Beispiele. Wenn's jetzt um "Einzelheiten" geht dass in GF1xx die TMUs im SM quasi integriert sind und den cache relevanten texturing Aenderungen wird der Tag lang....

SMs??? What? Meinst du jetzt Shadereinheiten oder Shadercluster?
Bei Shadereinheiten wäre es ein harter ein Epic-Fail, da der GF114 exakt 3x so viele wie der G92(b) hat.
Bei Shaderclustern hättest du recht -> 8:8

Allerdings interessiert doch auch keine Sau die Organisation der Shadereinheiten (nicht anderes sind die Cluster!) sondern eher deren Anzahl.
Clusterzahlenvergleiche sind jedenfalls noch tausendmal unsinniger als ein Shaderanzahlvergleich, den du mir ja vorwirfst.

Und nein, um andere "Einzelheiten" soll es jetzt nicht gehen, sonst wird es wirklich lang...

Um das ganze nun abzuschließen und nochmal auf die Einheiten (Shader, TMU...) zurückzukommen. Natürlich ist "Einheit" != "Einheit" von Generation zu Generation. Völlig unbestritten!

Aber das war alles nicht die Frage des TE.

Diese lautete:
Welches Design (AMD / nVidia) ist eurer Meinung nach das "ausgeglichenste" der GPU - Geschichte (vom Standpunkt Shaderleistung/TMUs/ROPs/Speicherbandbreite bzw. deren effektive Leistung)?

Ich gab exakt hierauf meine (historische) Antwort.
In der jüngeren GPU-Geschichte ist und bleibt das der G92(b).
In seiner Generation bzw. in seinen Genrationen von GF 8 (wie bereits weiter oben ausgeführt wegen RAM-Ausbau 8800 GTS nur eingeschränkt) bis GTS 250 war das definitiv der ausgeglichenste Chip. Ansonsten wäre er wohl außerdem kaum so ein Erfolg geworden.

Heute würde ich übrigens zweifelsohne den GF114 als "ausgeglichensten Chip" am Markt bezeichnen. Aber da meine 1. Antwort auf 2011-01-31, 13:11:36 datiert, sollte man mir das auch nicht zum Vorwurf machen... :wink:

Edit:
Danke - das sehe ich ähnlich, weswegen ich - unabhängig von der Leistungsklasse - nach dem "ausgeglichensten" Chip fragte.....
Also habe ich die Frage doch richtig aufgefasst oder nicht?

Nach Deiner Erläuterung kann man aber leider nicht so einfach die Rechenleistung / Filterleistung zu Speicherdurchsatz setzen und vergleichen?
(z.B. G80 verglichen mit G86 oder GF110 mit GF114)
Natürlich kann man das nicht. Es würde gar keinen Sinn ergeben, deine Frage Chipgenerationenübergreifend beantworten zu wollen.
Hier scheitert man zwangsläufig an der (oft mangelnden) Vergleichbarkeit. Man kann also nur versuchen intragenerationell eine Antwort zu geben. Das heißt ich schaue mir die einzelnen Serien an und suche da den "optimalen" Chip.
Zwischen GT200(b) (und kleiner) und G92(b) sind die Unterschiede außerdem marginal.
Was man vor allem auch daran sehr gut sieht, dass hier die Proportionen des erfolgreichen G92(b) beinahe übernommen worden sind
G92(b) 16 128 8 64 64
GT200(b) 32 240 10 80 80
[ROPs, SE, SC, TMUs, TAUs]

@ Ailuros: Komm mir jetzt bloß nicht wieder mit der anderen Clusterorganisation [240 : 10] sonst :ubash2: !!!