GF104 - Architektur-Diskussion [Archiv]

Gipsel

2010-07-12, 11:07:41

Ein SM mit 48 ALUs würde wohl eher so aussehen:

http://139.30.40.11/GF104_SM.png

Ich habe dem SM auch gleich noch die doppelte Anzahl SFUs verpaßt, das ALU:SFU Verhältnis ist ja von 4:1 bei allen vorhergehenden nv-GPUs beim GF100 auf 8:1 runtergegangen. Bei 4 zu bleiben, entspräche dann schon 12:1, da halte ich 6:1 als guten Kompromiß.

In der Summe gibt es also 3 Scheduler, die 6 Funktions-Blöcke füttern, 3 mal 16 ALUs (eigentlich dürfte immer nur ein Pfeil in so einen 16er Block reingehen, aber ich habe das Diagramm möglichst nah am Original gelassen), 1 mal 16 L/S und 2 mal 4 SFUs.
Na da lag ich doch gar nicht mal soo schlecht ;)

Okay, die Sache mit den Schedulern und der Größe des Registerfiles war nicht richtig, aber nachdem Ailuros dann was von "Quad-Issue" erzählte, habe ich schon zwei Dual-Issue Scheduler vermutet. So ein GF104-SM hat also praktisch ähnliche Scheduler wie G80 und GT200 (die waren auch dual-issue, was anandtech über erstmalig superskalar erzählt ist also ein wenig Blödsinn, die SFUs konnten bei G80/GT200 bei unabhängigen Instruktionen auch [quasi-]parallel angesprochen werden).

Der Nachteil an der Anordnung (die aber im übrigen wohl recht effizient arbeiten dürfte) ist wahrscheinlich manchmal mangelnde Registerbandbreite. So dürften die Operand Collectors öfter mal Probleme bekommen, alle Operanden heranzuschaffen, da jetzt maximal 4 statt bisher 2 Befehle pro Takt versorgt werden wollen und ich ein wenig bezweifle, daß nv die Anzahl der Ports an den Registerfiles wirklich glatt verdoppelt hat. In dieser Beziehung wäre meine Version mit weniger Problemen verbunden gewesen, da ich jedem der 3 Scheduler seine eigenen 16x1024x32Bit Register verpaßt hätte.

Coda

2010-07-12, 14:19:38

Ich kapier das mit den zwei Warp-Schedulern nicht die Bohne. Da besteht wirklich noch viel Klärungsbedarf.

Spasstiger

2010-07-12, 14:24:20

Ich kapier das mit den zwei Warp-Schedulern nicht die Bohne. Da besteht wirklich noch viel Klärungsbedarf.
Evtl. ist die interne Aufteilung der SMs nicht 3*SIMD16, sondern einmal SIMD16 und einmal SIMD32, wobei der 16er-SIMD Double-Precision-tauglich ist (bei 1/4 des SP-Durchsatzes).

/EDIT: Oder auch nicht. Hier ein Erklärungsversuch von Anandtech, Superskalarität ist das Stichwort: http://www.anandtech.com/show/3809/nvidias-geforce-gtx-460-the-200-king/2.
Wobei im Wesentlichen dann schon ein Warp-Scheduler 32 SPs füttert und der andere nur 16 SPs.

http://www.abload.de/img/gf140smd0yq.png

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.

With the addition of superscalar abilities, GF104 marks the slow-but-steady merger of the CPU and the GPU. GF104 is now just a bit more CPU-like than GF100 was, a particularly interesting turn of events since we’re looking at a waterfall part and not a new architecture today.

Coda

2010-07-12, 14:36:42

Bestimmt nicht. Dann müsste die 32er ALU pro Pipeline-Stage einen WARP in einem statt zwei Takten fertig machen. Das würde bedeuten, dass man die ganze ALU komplett überarbeiten müsste, dazu wäre das ganze dann auch noch sinnlos unorthogonal für den Scheduler.

Meine Vermutung ist immer noch, dass die Grafik nicht stimmt und es einfach tatsächlich doch drei Scheduler sind.

/EDIT: Oder auch nicht. Hier ein Erklärungsversuch von Anandtech, "superskalar" ist das Stichwort:
Das erscheint mir aus zwei Punkten auch nicht plausibel:
- Wenn dann macht man das ganze orthogonal und nicht irgendwie komisch krumm mit einem "fetten" und einem normalen Scheduler
- Drei normale Scheduler wären wohl transistorsparender

Das kommt nur in Frage, wenn schon Fermi mehr in diese Richtung tut als wir bisher wussten. Und in einer GPU superskalar passt einfach nicht. Das hat Gipsel auch schon mehrfach angesprochen. Es wäre total sinnlose Transistor- und Stromvergeudung.

AnarchX

2010-07-12, 14:41:55

Noch ein paar interessante synthetische Tests:
http://www.ixbt.com/video3/gf104-part2.shtml
http://techreport.com/articles.x/19242/6

Bei iXBT sind teilweise ein paar Werte dabei, wo sich die GTX 460 nur wie ein 256SPs GF100 verhält.
Hier wird die 768MB Version wohl von ihrer Bandbreite limitiert.

Coda

2010-07-12, 14:46:50

So wie Anandtech das darstellt ist es wohl einfaches Scoreboarding und beide Warp-Scheduler sind orthognal an jeweils zwei Dispatch-Ports angeschlossen. Das könnte tatsächlich sein.

Edit: Noch was. Die "nächste Instruction" in einem Warp-Scheduler ist i.A. von einem anderen Warp, nicht vom gleichen. D.h. sie wäre immer ILP-Safe.

AnarchX

2010-07-12, 15:29:13

http://www.hardware.fr/articles/795-4/dossier-nvidia-geforce-gtx-460.html
Hier sieht man, dass die TMUs nun FP16 und RGB9E5 in Fullspeed filtern.

Zudem hat sich Damien, das mit den Schedulern wohl genauer erklären lassen:
http://translate.google.de/translate?u=http%3A%2F%2Fwww.hardware.fr%2Farticles%2F795-2%2Fdossier-nvidia-geforce-gtx-460.html&sl=fr&tl=en&hl=&ie=UTF-8

Pinoccio

2010-07-12, 15:47:15

s4ot:
RGB9E5Für alle, die sich so wie ich fragen Was ist denn das? hier ein Link (http://msdn.microsoft.com/en-us/library/ee416413%28v=VS.85%29.aspx).

mfg

Coda

2010-07-12, 16:16:36

http://www.hardware.fr/articles/795-4/dossier-nvidia-geforce-gtx-460.html
Hier sieht man, dass die TMUs nun FP16 und RGB9E5 in Fullspeed filtern.
Das erzeugt bei mir auch ein "what the fuck?"

Spasstiger

2010-07-12, 16:28:15

Warum erreicht die GTX 460 1 GiB bei den Pixelfüllratentests eigentlich partout nicht mehr als 4,6 GPixel/s mit 3*FP10 und 4*FP16? Die GTX 460 768 MiB erreicht denselben Peak-Wert. Normalerweise sollte doch bei der Variante mit den 32 ROPs ein besserer Peak-Wert drin sein. Gerastert werden können 9,45 GPixel/s (2 Pixel pro Takt und SM), das sollte doch nicht zum Flaschenhals werden. Oder gilt dieser Wert nicht für 3*FP10- bzw. 4*FP16-Pixel?

Coda

2010-07-12, 16:29:05

Vielleicht wieder das gleiche Problem wie bei Fermi, dass die Bandbreite zwischen ALUs und ROPs limitiert?

Zudem hat sich Damien, das mit den Schedulern wohl genauer erklären lassen:
http://translate.google.de/translate?u=http%3A%2F%2Fwww.hardware.fr%2Farticles%2F795-2%2Fdossier-nvidia-geforce-gtx-460.html&sl=fr&tl=en&hl=&ie=UTF-8
Okay, damit und zusammen mit Anand ist es wohl klar.

Der Scheduler schaut sich immer die nächsten zwei Instructions an und gibt beide falls unabhängig an seine Dispatch-Ports. Falls das nicht möglich ist nur die erste. Da es vier Dispatch-Ports sind und drei ALUs dahinter wird die Sättigung wohl trotzdem relativ gut sein, vor allem falls es noch einen kleinen FIFO zwischen Schedulern und FUs gäbe.

Der Compiler muss dann aber auch etwas mehr Arbeit machen, denn z.B. ein Skalarprodukt wäre in seiner normalen Form so nicht parallelisierbar. Er muss also schauen dass er unabhängige Operationen verwebt.

Fetter Fettsack

2010-07-12, 17:30:54

Kann sich das in der Praxis irgendwie nachteilig auf etwas auswirken (AA-Leistung oder was es sonst so alles im Zusammenhang ROP/ALU gibt)?

Gast

2010-07-12, 17:53:41

Im Worst-Case liegt die ALU-Leistung nur bei 2/3. Bei AMD ist der Worst-Case 1/5.

Coda

2010-07-12, 19:10:46

Wobei das nicht vergleichbar ist. Bei ATI macht das komplett statisch der Compiler, bei GF104 kann die Auslastung auch zur Laufzeit schwanken, je nachdem was der andere Warp-Scheduler gerade macht.

Ailuros

2010-07-12, 19:11:35

Ok kann man also zusammenfassen dass es 3*16/SM sind mit 2 warp schedulers/SM?

Gipsel,

Man sagte mir vor dem quad issue Zeug dass es ein 192SP 2-way supescalar Ding sei. Deshalb fragte ich auch irgendwo zwischendrin ob 16+8 SPs/SM irgendwelchen Sinn machen. Nachdem aber die 8SM/quad issue Meldung ankam war ich erstmal sicher dass es sich doch um 3*16 handeln muss.

Gipsel

2010-07-12, 19:15:51

Okay, damit und zusammen mit Anand ist es wohl klar.

Der Scheduler schaut sich immer die nächsten zwei Instructions an und gibt beide falls unabhängig an seine Dispatch-Ports. Falls das nicht möglich ist nur die erste. Da es vier Dispatch-Ports sind und drei ALUs dahinter wird die Sättigung wohl trotzdem relativ gut sein, vor allem falls es noch einen kleinen FIFO zwischen Schedulern und FUs gäbe.

Der Compiler muss dann aber auch etwas mehr Arbeit machen, denn z.B. ein Skalarprodukt wäre in seiner normalen Form so nicht parallelisierbar. Er muss also schauen dass er unabhängige Operationen verwebt.
Wie gesagt ist das recht ähnlich zu G80/GT200. Da mußten die Anweisungen nämlich auch unabhängig sein, wenn man das "dual issue" nutzen wollte.

Coda

2010-07-12, 19:21:42

In welchem Fall wären sie denn nicht unabhängig? Die Warp-Scheduler bearbeiten ja nicht gleichzeitig den selben Warp.

Gipsel

2010-07-12, 19:25:05

Wobei das nicht vergleichbar ist. Bei ATI macht das komplett statisch der Compiler, bei GF104 kann die Auslastung auch zur Laufzeit schwanken, je nachdem was der andere Warp-Scheduler gerade macht.
Wobei mir immer noch kein Grund einfallen will, warum nvidia die ALUS/TMUs nicht enger mit den Registerfiles verzahnt (ATI hat das ja ziemlich auf die Spitze getrieben). Das würde die Anzahl der nötigen Registerports senken (sowas ist ziemlich teuer), man könnte die einzelnen Registerfiles noch kleiner machen und im Ergebnis die Latenzen senken bzw. den Takt erhöhen. Und all das bei geringerem Aufwand in den Schedulern, den man dann gegen etwas größere Registerfiles eintauschen könnte (ich "wollte" ja schon 3*16*1024 Register statt jetzt nur 2*16*1024 für GF104).
Ok kann man also zusammenfassen dass es 3*16/SM sind mit 2 warp schedulers/SM?Ja, allerdings zwei "dual issue" Warp Scheduler, die zwei (unabhängige) Instruktionen pro Warp gleichzeitig absetzen können.

Gipsel

2010-07-12, 19:26:00

In welchem Fall wären sie denn nicht unabhängig? Die Warp-Scheduler bearbeiten ja nicht gleichzeitig den selben Warp.
Natürlich nicht, aber dual issue setzt 2 Instruktionen aus einem Warp ab, und das mit nur einem Scheduler (der zwei issue ports hat). Oder was meinst Du?

Gipsel

2010-07-12, 19:33:48

Das erzeugt bei mir auch ein "what the fuck?"
Vor allem FP16 sollte Damien vielleicht nochmal nachmessen. Seine Werte würden bedeuten, daß GF104 doppelt so viel Texture-Cache Bandbreite besitzt, wie es ihn unter normalen Umständen nutzen kann. Allerdings paßt auch da der FP32-Wert nicht dazu (der sieht wieder normal aus). Mein Tipp wären ~18.9 GTexel/s mit 64Bit Farbformaten (4*16Bit) bei der GTX460, nicht 33.3 GTexel/s.

Achja, lustigerweise kommt aber auch die GF104 mit 3*10bit immer noch nicht so gut klar und sacken auf die halbe Pixel-Füllrate ab. Und es sieht immer noch danach aus, daß ein SM nur 2 Pixel/Takt zu den ROPs schicken kann, wenn es INT32-Pixel sind, bei FP16 oder FP10 bricht es auf 1 Pixel pro Takt und SM ein (7 Pixel/Takt für den ganzen Chip), bei 4*FP32 sogar auf ein Pixel alle 2 Takte (3,5 Pixel/Takt für den kompletten Chip). Dort ist ein Cypress fast 4 mal so schnell. Sogar die HD5830 mit den verkrüppelten ROPs hält sich dort locker und sogar ein Juniper schlägt die GTX460 mit dem doppelten Wert.

Gast

2010-07-12, 19:51:06

Coda

2010-07-12, 20:19:34

Natürlich nicht, aber dual issue setzt 2 Instruktionen aus einem Warp ab, und das mit nur einem Scheduler (der zwei issue ports hat). Oder was meinst Du?
Mich irritiert das "recht ähnlich zu G80/GT200". Was ist recht ähnlich?

Gipsel

2010-07-12, 20:40:17

Mich irritiert das "recht ähnlich zu G80/GT200". Was ist recht ähnlich?
Dort hat der Scheduler ja 4 Takte (hotclock) für einen Warp benötigt. In diesen 4 Takten konnte sowohl eine ALU-Anweisung als auch eine SFU-Instruktion abgesetzt werden, solange sie unabhängig sind (irgendwo stand mal, daß im ersten Schedulertakt die ALU-Anweisung rausging, im zweiten dann die SFU-Anweisung, können aber genauso gut auch zwei Issue-Ports gewesen sein, wie jetzt beim GF104). Dies ist doch praktisch das Gleiche wie jetzt, nur ist die Funktionalität eben nicht auf ALU+SFU begrenzt, sondern es können auch ALU+ALU, ALU+L/S, SFU+L/S und wahrscheinlich auch SFU+SFU sein (oder nv hat auch noch die SFUs umgebaut, so daß das nur ein Port mit 8 SFUs am Stück ist, was die Latenzen verringern würde). Und der Mehraufwand dafür sollte recht überschaubar sein.

Zusammengefaßt, daß Dual-Issue des GF104 paßt wieder zum Dual-Issue in G80/GT200, beide arbeiten mit unabhängigen Instruktionen in einem Warp. Bei Fermi hat nvidia schon die Dual-Warp Schedulers alleine als dual issue bezeichnet, was aber deutlich was anderes ist, da die beiden Scheduler immer mit verschiedenen Warps arbeiten.

Achja, weil das aufkam, Instruktionsabhängigkeiten können sehr gut vom Compiler erkannt werden (ATI macht das ja nur so), es könnte also sehr gut sein, daß das "dual issue" unabhängiger Instruktionen schon beim Kompilieren (von PTX in cubin) vorbereitet wird. Dafür reicht ja ein einziges Bit pro Instruktion ("nächste Anweisung kann parallel laufen"), das erspart dem Scheduler dann ein paar Checks (ob beide benötigten Funktionsblöcke frei sind natürlich nicht).

deekey777

2010-07-12, 20:46:29

Irgendwo hier?
http://www.realworldtech.com/page.cfm?ArticleID=RWT090808195242&p=9

Spasstiger

2010-07-12, 21:45:11

http://techreport.com/articles.x/19242/6
Die Texelfüllraten mit 16:1 Tri-AF in Relation zur theoretischen Peak-Texelfüllrate:
HD 5870: 0,381
HD 5850: 0,397
HD 5830: 0,402
HD 5770: 0,491
HD 4870: 0,510
GTX 470: 0,597
GTX 465: 0,595
GTX 460: 0,511 (1024 MiB) bzw. 0,497 (768 MiB)
GTX 260: 0,509
Der GF100 hat also gemessen an der theoretischen Peak-Füllrate die effizienteste Implementierung für 16:1 Tri-AF (INT8-Texturformat). Am Ineffizientesten ist der RV870. Der GT200(b), GF104, RV770 und RV840 liegen ungefähr gleichauf in der Mitte.
Der GF100 haut 50% mehr Texelfüllrate pro TMU und Takt raus als der RV870.

Coda

2010-07-12, 22:10:53

Dort hat der Scheduler ja 4 Takte (hotclock) für einen Warp benötigt. In diesen 4 Takten konnte sowohl eine ALU-Anweisung als auch eine SFU-Instruktion abgesetzt werden
Sorry, natürlich. Hatte ich schon wieder verdrängt.

Der GF100 haut 50% mehr Texelfüllrate pro TMU und Takt raus als der RV870.
Und das, obwohl ATI dabei auch noch schummelt. Sauber filtern tut RV870 nämlich nie.

Gast

2010-07-13, 10:19:54

Vor allem FP16 sollte Damien vielleicht nochmal nachmessen. Seine Werte würden bedeuten, daß GF104 doppelt so viel Texture-Cache Bandbreite besitzt, wie es ihn unter normalen Umständen nutzen kann. Allerdings paßt auch da der FP32-Wert nicht dazu (der sieht wieder normal aus). Mein Tipp wären ~18.9 GTexel/s mit 64Bit Farbformaten (4*16Bit) bei der GTX460, nicht 33.3 GTexel/s.
GF 104 hat, wie der der andere Gast schon verlinkte, Single-Cycle FP16-TMUs. :) Das wurde erst nur gemessen, dann von Nvidia auch direkt gesagt.

Achja, lustigerweise kommt aber auch die GF104 mit 3*10bit immer noch nicht so gut klar und sacken auf die halbe Pixel-Füllrate ab. Und es sieht immer noch danach aus, daß ein SM nur 2 Pixel/Takt zu den ROPs schicken kann, wenn es INT32-Pixel sind, bei FP16 oder FP10 bricht es auf 1 Pixel pro Takt und SM ein (7 Pixel/Takt für den ganzen Chip), bei 4*FP32 sogar auf ein Pixel alle 2 Takte (3,5 Pixel/Takt für den kompletten Chip).
Die Verbindung zwischen Shader und ROP ist nach wie vor 64 Bit breit, kann flexibel genutzt werden.

-carsten

Gast

2010-07-13, 10:22:02

Noch ein paar interessante synthetische Tests:
http://techreport.com/articles.x/19242/6

Auch Techreport schreibt falsche Pixel-Füllraten.
Bei 675 MHz / 7 SMs sind es 9,45 GPix. Das sagt dir auch jeder basic-Füllratentest.

-carsten

AnarchX

2010-07-13, 10:29:00

Ja, bei HW.fr sieht man es sehr gut.
Da wäre es wohl sinnvoll gewesen von 2 auf 4 Pixel pro SM zu erhöhen.
Bei GF106 (voraussichtlich 192 SPs+Bit) sind das dann ja nur grenzwertige 8 Pixel/MHz.

Gipsel

2010-07-13, 13:37:47

Seine Werte würden bedeuten, daß GF104 doppelt so viel Texture-Cache Bandbreite besitzt, wie es ihn unter normalen Umständen nutzen kann. Allerdings paßt auch da der FP32-Wert nicht dazu (der sieht wieder normal aus).
GF 104 hat, wie der der andere Gast schon verlinkte, Single-Cycle FP16-TMUs. :) Das wurde erst nur gemessen, dann von Nvidia auch direkt gesagt.
Wie gesagt, hat GF104 (und wohl auch GF100!) dann pro TMU offensichtlich doppelt so viel Texture-Cache-Bandbreite wie die ATIs. Die Fermis werden damit praktisch immer von der Filterlogik limitiert, aber nicht von der Bandbreite. Bei ATI ist es genau anders herum, die erreichen praktisch exakt das Maximum, was mit der zur Verfügung stehenden Bandbreite (16 Byte pro Takt und TMU, Fermis dann offensichtlich 32Byte/Takt und TMU) drin ist.
Und das, obwohl ATI dabei auch noch schummelt. Sauber filtern tut RV870 nämlich nie.
Was damit dann wohl seine Erklärung gefunden hat, ATIs fehlt die Bandbreite, die bei Fermis im Überfluß existiert. Somit ist trilinear (+AF) der Bereich, in dem die Fermis das ausspielen können.
Die Verbindung zwischen Shader und ROP ist nach wie vor 64 Bit breit, kann flexibel genutzt werden.
Was mir auch in Anbetracht der Bandbreite zu den Textureinheiten immer noch deutlich unterdimensioniert aussieht. Und warum können nicht z.B. zwei FP10-Pixel in diese 64Bit gepackt werden?

del_4901

2010-07-13, 13:53:49

Was mir auch in Anbetracht der Bandbreite zu den Textureinheiten immer noch deutlich unterdimensioniert aussieht. Und warum können nicht z.B. zwei FP10-Pixel in diese 64Bit gepackt werden?
Warscheinlich findet die Konvertierung FP16->FP10 erst nach dem AlphaBlendig statt, weil man ja noch mit Source Alpha rechnen moechte.

Gipsel

2010-07-13, 14:27:07

Warscheinlich findet die Konvertierung FP16->FP10 erst nach dem AlphaBlendig statt, weil man ja noch mit Source Alpha rechnen moechte.
Die Begrenzung greift immer, nicht nur bei Blending. Die GF104 macht immer 4,6 GPixel/s mit FP10 und FP16, egal ob mit oder ohne Blending.

crux2005

2010-07-13, 14:32:54

Schon gepostet? http://translate.google.com/translate?js=y&prev=_t&hl=en&ie=UTF-8&layout=1&eotf=1&u=http%3A%2F%2Fpc.watch.impress.co.jp%2Fdocs%2Fcolumn%2Fkaigai%2F20100712_380148 .html&sl=auto&tl=en

Spasstiger

2010-07-13, 14:45:00

Schon gepostet? http://translate.google.com/translate?js=y&prev=_t&hl=en&ie=UTF-8&layout=1&eotf=1&u=http%3A%2F%2Fpc.watch.impress.co.jp%2Fdocs%2Fcolumn%2Fkaigai%2F20100712_380148 .html&sl=auto&tl=en
Das hat wohl jemand falsch "estimated", denn es ist ja mehr oder weniger bestätigt, dass der GF104 nur zwei Warp Scheduler hat und nicht vier.

Coda

2010-07-13, 15:41:21

Ich halte es auch nach wie vor für fraglich, dass einer der ALU-Blöcke besonders auf DP abgestimmt ist. Aber ich mag damit unrecht haben.

Meiner Meinung nach wird sowohl bei den Consumer-Fermis als auch GF104 einfach mehrfach über die SP-ALUs geloopt.

del_4901

2010-07-13, 15:56:24

Die Begrenzung greift immer, nicht nur bei Blending. Die GF104 macht immer 4,6 GPixel/s mit FP10 und FP16, egal ob mit oder ohne Blending.
Ich meinte das eher so, dass man da einfach keine Unterscheidung macht und immer erst nach den Raster Operations konvertiert. Die Xbox macht das ja per Design auch nicht anders.

BlackBirdSR

2010-07-13, 19:15:13

Ich halte es auch nach wie für fraglich, dass eine der ALU-Blöcke besonders auf DP abgestimmt ist. Aber ich mag damit unrecht haben.

Meiner Meinung nach wird bei den Consunmer-Fermis als auch GF104 einfach mehrfach über die SP-ALUs geloopt.

Das wäre auch die naheliegenste Lösung.

Die z.B von Anandtech vorgetragene Variante, ist dafür die marketing-technisch klügere. So klingt das ganze Produkt bezüglich Precision noch immer das Fortschritt und was besonderem...

Ich hoffe es zeigt sich bald, was wirklich stimmt. Ich hasse es, wenn Marketingkniffe lange Bestand haben...

crux2005

2010-07-14, 17:47:58

Noch ein paar interessante synthetische Tests:
http://techreport.com/articles.x/19242/6

Ich habe mir den D3D Rightmark mal angeschaut, aber auf die Werte einer GTX 470 im Review komme ich nicht. Kp was er da genaueres eingestellt hatte...
Bekommt jemand mit einer GTX 470 ähnliche Werte wie in der Review? Oder ist der fillrate Test zu sehr CPU-lastig?

Coda

2010-07-17, 05:30:18

Pinoccio

2010-07-17, 10:16:27

Anscheinend tut der Compiler wirklich nichts außer anders sortieren bei der GTX460:
http://forum.beyond3d.com/newreply.php?do=newreply&p=1451522

Das ist recht merkwürdig. Ich habe keine wirklich gute Idee, warum sie unbedingt die ISA gleich halten wollen.Dein Link geht nicht, meintest du diesen Beitrag (http://forum.beyond3d.com/showpost.php?p=1451522&postcount=6257) von Damien?
Nvidia told me that the ISA is the same and for GF104 the compiler just tries to be more careful about instruction ordering.

mfg

Coda

2010-07-17, 13:45:04

Jup, sorry.

deekey777

2010-07-20, 21:07:13

http://forum.beyond3d.com/showthread.php?t=58077
Hm... Ist das lecker. ;(

Coda

2010-07-20, 21:26:27

Du musst bedenken, dass das Extremfälle sind. Die Kernel sind auch extrem kurz. In der Realität hat man ja viel längere Programme und die beiden Warp-Scheduler befinden sich nur zufällig an der gleichen Programmposition.

Ich vermute zudem, dass hinter den Schedulern auch noch ein Buffer ist, der verhindert dass ein lokaler Mangel an parallel zu issuenden (omg) Befehlen sofort zu Stalls führt.

Das System hat gegenüber ATI den Vorteil, dass einer der Warps somit den "freien Slot" des anderen ausfüllen kann und umgekehrt. Wenn bei ATI der Shader-Compiler nur 3 der 5 Slots vollbekommt, kann eine andere Wavefront das nicht ausfüllen. Dafür ist natürlich die Logik um einiges einfacher.

Gipsel

2010-07-20, 21:38:47

http://forum.beyond3d.com/showthread.php?t=58077
Hm... Ist das lecker. ;(
Du musst bedenken, dass das Extremfälle sind. Die Kernel sind auch extrem kurz.
Nun, wie ich das verstehe, stehen die Zeilen 1000 bzw. 500 mal dupliziert hintereinander und werden dann in einer Schleife in jedem Thread noch 100mal durchlaufen. Das sind dann zwar unsinnige, aber doch schon ziemlich lange Kernel, die nur sehr wenige Register belegen. Von der Anlage her ideal für solche Tests.
Ich vermute zudem, dass hinter den Schedulern auch noch ein Buffer ist, der verhindert dass ein lokaler Mangel an parallel zu issuenden (omg) Befehlen sofort zu Stalls führt.Das wäre aber Gift für die Ausführungslatenz, die auch wegen des kleinen Registerfiles sowieso schon kritisch ist.

Ach übrigens, aus dem Startpost:
Der Nachteil an der Anordnung (die aber im übrigen wohl recht effizient arbeiten dürfte) ist wahrscheinlich manchmal mangelnde Registerbandbreite. So dürften die Operand Collectors öfter mal Probleme bekommen, alle Operanden heranzuschaffen, da jetzt maximal 4 statt bisher 2 Befehle pro Takt versorgt werden wollen und ich ein wenig bezweifle, daß nv die Anzahl der Ports an den Registerfiles wirklich glatt verdoppelt hat.:D
Nach den Tests gehen wirklich Operationen mit 3 Quelloperanden (z.B. madd) nicht mit voller Rate, nur mit muls (zwei Quelloperanden) erreicht man die theoretische Leistung (48 flops/Takt und SM). Spricht ganz klar für fehlende Registerfilebandbreite. Offensichtlich kann man pro Takt nicht wirklich mehr als mehr als 96 Operanden fetchen, für madd benötigt so ein SM aber 144 pro Takt.

Und das dürfte auch in der Praxis auftauchen, da ja im Prinzip sogar 4 Blöcke pro Takt von den Schedulern gefüttert werden könnten, wenn man mal noch die SFUs in den Mix wirft (und wie das mit den writeports bei Nutzung der L/S-Einheiten aussieht, wäre auch mal spannend).