GF104 - Q2/2010 - und andere GF10x

[aylano]

GF104 ist kein kastrierter 100 sondern offensichtlich ein von Grund auf entwickelter performance chip.
Wenn der GF104 von Grund auf neu entwickelt ist und GF 106 und GF108 sich dann von GF104 abgeleitet wird, dann müsste GF100 ein Server-GPU sowie Extrem-Gamer-GPU (zusätzliche Shader für PhsyX & Tesselation; extremer Stromverbrauch egal) sein.
Hingegen GF104 so der "Massen-High-End"-GPU wie G80 oder GTX285 wird. Also, bei Leuten, denen der Stromverbrauch nicht unwichtig ist bzw. gute Performance-pro-Watt haben, aber dafür nicht das letzte Stück an Zusatz-Performance brauchen.

[Gipsel]

Ob ich jetzt mit 8 oder 16SMs spiele bei vollem Ausbau laesst sich jegliches wohl schwer durch 3 teilen oder? Bei hypothetischen 9 bzw. 15SMs spielt meine Vorstellung fuer 3 noch mit; bei 8/16 fehlt meiner primitiven Logik aber doch etwas.
Wenn man annimmt, dass die Rastereinheiten stur zu einem Block an SMs gehören wäre es wirklich seltsam. Wenn allerdings jeder Raster in Wirklichkeit jeden SM mit Input versorgen kann spricht auch nichts gegen 3 von der Sorte.
Genau, ich vertrete ja schon seit geraumer Zeit, daß das wahrscheinlich geht. Ansonsten wären die Deaktivierungen der SMs und den dann notgedrungen unbalancierten GPCs wohl nicht ganz so möglich. Ich halte die GPCs daher eher für Erfindungen des Technical Marketing Departments, und das gibt eher einfach die Anzahl der Raster-Einheiten an, die allerdings entkoppelt von den SMs sind.
Ich sehe zwar ein dass Damien's These komplizierter ist als nur der zusaetzliche ("wiedererfundene") MUL, aber ich habe es extrem schwer ein 1/2 MADD eine SP zu nennen.
Die These klingt gar nicht so blöd, auch wenn ich daran auch noch nicht so ganz glaube. Aber wie ich bei B3D gerade schrieb, spricht eigentlich auch nicht viel dagegen, daß nvidia im Notfall noch ein paar Addierer in die SFUs packt (das ist transistormäßig ziemlich billig, ATI macht es ja auch). Aber da muß man mal sehen.
Also GF100 hat 4*16 SIMDs, also 4*16*8 SPs. GF104 hat 6*8 SIMDs, also 6*8*8 SPs. GF100 hat 4 GPCs, GF104 nur 2.
Ich glaube, da mußt Du mal kurz erklären, was Du mit was da multipliziert. Bei GF100 würde ich z.B. 16*2*16 SPs = 512 SPs verstehen, oder meinetwegen auch 4*4*2*16, aber 4*16*8? Was ist denn da was?

[Gast]

GF100 hat 4 GPCs, GF104 nur 2.


Wer sagt das? Es wäre möglich, aber es könnten genauso gut 4, oder (wenn auch extrem unwwahrscheinlich) 3 sein.

[LuXon]

Ich glaube, da mußt Du mal kurz erklären, was Du mit was da multipliziert. Bei GF100 würde ich z.B. 16*2*16 SPs = 512 SPs verstehen, oder meinetwegen auch 4*4*2*16, aber 4*16*8? Was ist denn da was?

Am ehesten hätte ich auf 4*4*32 getippt.

[Nakai]

Ich glaube, da mußt Du mal kurz erklären, was Du mit was da multipliziert. Bei GF100 würde ich z.B. 16*2*16 SPs = 512 SPs verstehen, oder meinetwegen auch 4*4*2*16, aber 4*16*8? Was ist denn da was?

GT100 hat 16 Cluster mit 32 Cudacores. Die Cudacores sind wohl in 4 SIMD-Blöcke je Cluster angeordnet. Ergo sind es 4*8 SPs.
Je 4 Cluster sind in einem CPC.
Also eigentlich 4*4*4*8 SPs, da aber immer 16 SIMDs genau in einem GPC drin sind und auf Rasterizer und Tesselator kommen, sollten es 4*16*8 SPs sein.
Ich gehe auch davon aus, dass man immer 4 Vec8-SIMDs in einerm Clusterunterbringt.

Also 4GPC*16 SIMDs*8SIMD-Breite = 512 SPs

Wenn der GF104 also 48SPs pro Cluster hat, dann sind pro Cluster wohl 6 SIMDs enthalten. Ergo 192 SPs pro GPC, wenn der Grundaufbau sich auch nicht geändert hat. Also nur zwei GPCs.
Außer man hat pro GPC nur zwei Cluster reingesetzt, dann wäre man wieder bei 4 GPCs.


mfg

[LovesuckZ]

Es sind zwei Vec16 Einheiten pro SM.

[Gast]

GT100 hat 16 Cluster mit 32 Cudacores. Die Cudacores sind wohl in 4 SIMD-Blöcke je Cluster angeordnet. Ergo sind es 4*8 SPs.

Bei GF100 sind es 2 16-way SIMDs pro SM, wobei jeder 16x-SIMD auch als DP 8xSIMD agieren kann.

Vorher waren es bei Nvidia immer 8-way-SIMDs, bis G200 2 pro SM, danach 3.

Nach den Spekulationen könnte GF104 wieder den G200-Weg mit 3 8x-SIMDs pro SM gehen.

Ich denke das ist auch gar nicht so unwahrscheinlich, wenn man DP rauswerfen will, kann man eigentlich die gleichen ALUs wie schon bei G200 verwenden (diese können ja auch bei G200 kein DP, der hat dafür noch extra ALUs) und auf 2x16 dürfte man in erster Linie wegen der schnellen DP-Leistung umgestiegen sein.

[Gast]

Fudo spekuliert (http://www.fudzilla.com/content/view/19232/1/), dass eine 512-SP-Version kommen wird, jedoch nicht mit dem GF100-Chip, sondern mit der überarbeiteten GF104-Architektur.

Wie realistisch ist das Ganze einzustufen?


512 SPs sind gar nicht möglich, basierend afu GF104 wären das 21,333 SMs

Möglich wären also höchstens 504 oder 528 SPs.

Allerdings nur wenn es keine Abhängigkeit von 4 SMs/GPC gibt, ansonsten käme nur 480SP/80TMU oder als nächstes 576SP/96TMUs in Frage.

[VooDoo7mx]

So ein GF104 Abkömmling mit 576SP/96 TMUs wäre ja immer noch kleiner als der GF100 oder?

So ein Chip dürfte doch mit großen Abstand alles abräumen und für den ATi Refresh gewappnet sein. :|

[Botcruscher]

Nur kann er nicht als Tesla eingesetzt werden. Damit entfällt er als Ersatz für GF100. Für die paar Highend-Heinzel alleine viel zu unwirtschaftlich.

[Gast]

So ein GF104 Abkömmling mit 576SP/96 TMUs wäre ja immer noch kleiner als der GF100 oder?

So ein Chip dürfte doch mit großen Abstand alles abräumen und für den ATi Refresh gewappnet sein. :|

Wie kommst du darauf GF104 soll mit 384SPs/64TMUs noch immer 375mm² groß sein. Und da fehlen die Hälfte der Tesslationseinheiten, man hat nur ein 256-bit SI und DP wurde eingespart. GF104 verwendet keine neue Architektur, einzig durch den wegfall von DP wurden ein paar Transistoren gespart, den großen Effizienzgewinn sehe ich allerdings nicht.

[Nakai]

Es sind zwei Vec16 Einheiten pro SM.

Okay, dann statt 4*8, hald 2*16. Dann sind es beim GF104 3*16 pro Cluster.

Wie kommst du darauf GF104 soll mit 384SPs/64TMUs noch immer 375mm² groß sein. Und da fehlen die Hälfte der Tesslationseinheiten, man hat nur ein 256-bit SI und DP wurde eingespart. GF104 verwendet keine neue Architektur, einzig durch den wegfall von DP wurden ein paar Transistoren gespart, den großen Effizienzgewinn sehe ich allerdings nicht.

Er hat wohl immer noch genug Tesselationsleistung. Wenn man aber nur 2 Cluster pro GPC nimmt, dann sind es immer noch genausoviel Tesselationsleistung.

So ein GF104 Abkömmling mit 576SP/96 TMUs wäre ja immer noch kleiner als der GF100 oder?

Hui, wenn 50% mehr Textureinheiten sind nicht wenig. Ich denke, das frisst den Gewinn durch das Wegfallen der DP-Einheiten wieder auf. Man wird wohl ungefähr gleich mit der Diesize liegen. Aber klar, man wäre locker einige große Prozente stärker. NV braucht nun soetwas gegen SI. Mit 20 bis 30% Mehrperformance wäre man schon sehr gut gewappnet.


mfg

[VooDoo7mx]

Nur kann er nicht als Tesla eingesetzt werden. Damit entfällt er als Ersatz für GF100. Für die paar Highend-Heinzel alleine viel zu unwirtschaftlich.

So ein fiktives Teil soll ja nicht den Tesla ersetzen sondern für den High End Desktop sein.
Der GF104 ist genau das was ATi eigentlich mit RV670/770/870 gemacht hat, ein relativ billiger Chip vom Ballast befreit. Bei gleichen Verkaufspreis waren die Margen für nVidia deutlich geringer.
Und wenn ATi so gegen Herbst bis Ende des Jahres ein Refresh oder was auch immer bringt, ist es allein von logischen Gewinnmaximierungsdenken sinnvoller ein 576 GF104 gegenzustellen als einen noch dickeren GF100 der eh schon arg an den Grenzen des thermisch machbaren nagt.

[VooDoo7mx]

Wie kommst du darauf GF104 soll mit 384SPs/64TMUs noch immer 375mm² groß sein. Und da fehlen die Hälfte der Tesslationseinheiten, man hat nur ein 256-bit SI und DP wurde eingespart. GF104 verwendet keine neue Architektur, einzig durch den wegfall von DP wurden ein paar Transistoren gespart, den großen Effizienzgewinn sehe ich allerdings nicht.

Wie groß der GF104 wriklich ist weiß kein Mensch genau der es öffentlich sagen dürfte. Von daher wäre ich vorsichtig Spekulationen als Faktum hinzustellen.

GF104 ist auch deutlich mehr als ein GF100-DP. Das sollte mitlerweile hinlänglich bekannt sein.
Von Effizirenzgewinn hab ich auch nirgendwo gesprochen.

Wenn ATi größere Performancegewinne erzielen will, wird auch den ihr nächster Chip in Größe anwachsen. Da dürfte auch ein spekulativer GF104-576 nicht viel größer sein. In letzter Zeit waren die nVidia CHips ja eh immer deutlich größer.

[Gast]

Nur kann er nicht als Tesla eingesetzt werden. Damit entfällt er als Ersatz für GF100. Für die paar Highend-Heinzel alleine viel zu unwirtschaftlich.

Das könnte man dann über jeden Highend-Chip sagen.

Nachdem 28nm noch auf sich warten lässt wird NV noch in 40nm einen neuen Highend-Chip brauchen, GF100 wird wohl kaum die Krone gegen die nächste ATI-Generation halten können.

GF100 noch größer zu machen dürfte in 40nm wohl kaum sinnvoll sein, also wäre ein 576/92-Chip auf GF104-Basis keine schlechte Wahl sein. Die DIE-größe dürfte wohl in der Nähe von GF100 liegen, aber mit deutlich höherer Spieleleistung. Dass sich der Chip nicht für Tesla eignet ist auch kein großes Problem, in dem Markt ist man eh mehr oder weniger konkurrenzlos, und der Markt ist auch ein recht langlebiger, da muss man nicht alle 6 Monate mehr Performance nachschießen.

Der überraschend starke GF104 zeigt ja schon, dass NV wohl auf lange Sicht mehr oder weniger zweigleisig fahren wird, einen "normalen" Highend-Chip und Tesla extra, was noch als "Super High-End" natürlich auch auf den Markt geworfen wird.

[Hugo]

vielleicht hat GF104 noch seine DP-Units? oder ist das fix, dass er keine hat?

[Gast]

Dazu gibt es noch keine Informationen. Man kann aber annehmen, dass die GF10x-GPUs um DP beschnitten werden, wie auch GT21x.

[Gast]

Kann man, muss man aber nicht. Und schon gar nicht als gesichert ansehen.

-carsten

[Coda]

vielleicht hat GF104 noch seine DP-Units? oder ist das fix, dass er keine hat?
Wenn es drei Vec16 pro SM sind, dann ist das sehr sicher.

[Gast]

Wenn es drei Vec16 pro SM sind, dann ist das sehr sicher.
Was spräche bei einer solchen Konstellation gegen DP mit verminderten Durchsatz (1/3 SP)?

[Botcruscher]

Das könnte man dann über jeden Highend-Chip sagen.

NV verdient das Geld bei den Teslas und Quadro-Karten. Der Gamingbereich fällt da als Zugpferd für das Marketing und die Treiber nebenbei mit ab.

[Coda]

NV verdient das Geld bei den Teslas und Quadro-Karten.
Quelle?

[=Floi=]

deshalb gibt es auch zumindest kleinere quadros. die margen dürften da ebenfalls sehr hoch sein und warum nicht mal einen anfang machen. Es geht vor allem um maximale marktdurchdringung und dazu wäre DP nicht soooo schlecht. es würde ja reichen, wenn im kleinen auf solchen desktops die programme programmiert würden und dann im großen maßstab auf den großen systemen umgesetzt würden.

[Coda]

Quadros brauchen kein DP.

[Gast]

Quelle?

Quartalszahlen. Dadurch hat NV schon so einigen Verlust ausgeglichen. Gerade zu GT2xx-Zeiten war das Desktopsegment oft defizitär.

[Dural]

das liegt wohl eher an der vergangenen markt lage... auch die desktop sparte ist bei nv in der regel profitabel! da zu sagen NV lebt nur von Tesla und Quadros ist so zimlich daneben...

die high end chips tragen übrigens nie wirklich etwas zum gewinn mit, es sind immer die kleineren GPUs die den grossen gewinn ein bringen. die sicher am anfang bei der GT200 serie gefehlt haben, dafür hatte man immer noch gut laufende G9x chips die quasi schon lange "abbezahlt" waren.

[deekey777]

Quadros brauchen kein DP.
Warum hat OpenGL dann die fp64-Genauigkeit für Shader?

[Botcruscher]

Quelle?

http://phx.corporate-ir.net/External.File?item=UGFyZW50SUQ9NDYxNTV8Q2hpbGRJRD0tMXxUeXBlPTM=&t=1

Proffesional: 189.7 Mio
Consumer: 31.2 Mio

das liegt wohl eher an der vergangenen markt lage... auch die desktop sparte ist bei nv in der regel profitabel! da zu sagen NV lebt nur von Tesla und Quadros ist so zimlich daneben...

Von unprofitabel war nicht die Rede. Grundaussage war, dass kein Extra Highend-Chip für den Consumermarkt entwickelt wird(ohne einen GF100 Nachfolger anbieten zu können). Bei einem Gewinnverhältnis von 1:6 auch verständlich.
Quadros brauchen kein DP.
Sagt wer?

[LovesuckZ]

http://phx.corporate-ir.net/External.File?item=UGFyZW50SUQ9NDYxNTV8Q2hpbGRJRD0tMXxUeXBlPTM=&t=1

Proffesional: 189.7 Mio
Consumer: 31.2 Mio


Und was verkaufen sie dann in der "Geforce" Sparte? :confused:


Von unprofitabel war nicht die Rede. Grundaussage war, dass kein Extra Highend-Chip für den Consumermarkt entwickelt wird(ohne einen GF100 Nachfolger anbieten zu können). Bei einem Gewinnverhältnis von 1:6 auch verständlich.


Richtig. Sie werden nicht extra einen 530mm^2 Chip für das Tegra-Segment produzieren.

[Soundwave1983]

Und was verkaufen sie dann in der "Geforce" Sparte?

Na Produkte für lächerliche 780 Millionen Dollar. Wurde einfach mal ausgeblendet. :D

[Botcruscher]

Und was verkaufen sie dann in der "Geforce" Sparte? :confused:
? Keine Ahnung wenn ich mich gerade vertan habe. Ist ja auch egal da eh ot.

[Coda]

Warum hat OpenGL dann die fp64-Genauigkeit für Shader?
Weil's geht.

Keine CAD-Software verwendet DP (nichtmal für's Offline-Rendering) und wer professionell DP-GPGPU braucht kauft sich ne Tesla oder eben doch ne große Quadro.

Der Markt "wenig Rechenpower DP" existiert einfach nicht - außer für Hobby-Entwickler die damit rumspielen möchten.

Sagt wer?
Sag ich.

[deekey777]

Ich dachte da nicht an CAD, sondern an Offlinerendering. Man hat sich dabei bestimmt was gedacht, dies OpenGL 4.0 hinzuzufügen. Auch ATIs schnelle Mitteilung, dass man fp64-Unterstüzung für kleinere Grafikkarten per Extension nachliefert, spricht dafür, dass fp64-Genauigkeit einen nicht unwichtigen Wert hat.

[Coda]

Offline-Rendering macht man in aller Regel nicht mit DP. Da reicht SP völlig.

Du brauchst mir das nicht glauben, aber gerade DP in Vertex- und Pixelprogrammen ist praktisch völlig nutzlos. Offline-Rendering verwendet auch keins der beiden.

Ich bin mal so frech und behaupte, dass da viel Marketing dahinter steckt.

[Bucklew]

Der Markt "wenig Rechenpower DP" existiert einfach nicht - außer für Hobby-Entwickler die damit rumspielen möchten.
Richtig. Und Hobby-Entwickler können auch ne große GF100-basierende GeForce kaufen.

[Ailuros]

Kann sein dass ich etwas falsch erwischt habe, aber afaik wird es auf Quadros keine DP Unterstuetzung geben.

***edit: da sich NV mit GF10x Quadros ziemlich gelassen zeigt (es gibt auch nichts dergleichen auf ihrer Hauptseite) wuerde es mich kein bisschen wundern wenn sie am Ende den Markt mit GF104-ern bedienen.

[Coda]

DP haben doch sogar die GeForces, nur eben in langsam. Ich denke das ist dann bei den Quadros auch so.

[Ailuros]

DP haben doch sogar die GeForces, nur eben in langsam. Ich denke das ist dann bei den Quadros auch so.

Aber wohl nicht wenn mein edit oben gelten sollte (ie Quadros basieren auf 104).

[Spasstiger]

? Keine Ahnung wenn ich mich gerade vertan habe. Ist ja auch egal da eh ot.
Du hast dich vertan. Lies mal die Erklärungen unter den Zahlen. Die von dir unterschlagene Zeile aus der Tabelle mit der Bezeichnung "GPUs" gibt die Desktop- und Notebook-GPUs an. Der Umsatz in diesem Segment ist mehr als viermal so groß wie im professionellen Segment.

[Triskaine]

Sexy Charlie Time! :ulol:

http://www.semiaccurate.com/2010/06/21/what-are-nvidias-gf104-gf106-and-gf108/

[Coda]

Ich hör mal wieder nur bla bla.

GF104 ist nicht einfach ein 3/4 GF100 wenn die Infos stimmen die durchgesickert sind.

[N0Thing]

Du hast dich vertan. Lies mal die Erklärungen unter den Zahlen. Die von dir unterschlagene Zeile aus der Tabelle mit der Bezeichnung "GPUs" gibt die Desktop- und Notebook-GPUs an. Der Umsatz in diesem Segment ist mehr als viermal so groß wie im professionellen Segment.

Solange man nur den Umsatz der einzelnen Sparten kennt und nicht den Gewinn, macht es keinen Sinn darüber zu diskutieren, man kann nur weiter spekulieren.

[V2.0]

Sexy Charlie Time! :ulol:

http://www.semiaccurate.com/2010/06/21/what-are-nvidias-gf104-gf106-and-gf108/

Nette Einschätzung.

[ShinyMcShine]

Aber auch sehr negativ dargestellt gegenüber nVidia. -> Gerechtfertigt?

VG
Shiny

[Raff]

Du weißt schon, wer Charlie ist, oder? Nvidia-Hasser Nr. 1. Das sieht man auch in jedem Absatz, wo er stets 'nen Flame einbaut. Die Infos seiner oft verlässlichen Quellen mariniert er in krasser Anti-NV-Polemik, von daher ist Filtern angesagt.

MfG,
Raff

[Gast]

Einige filtrierte Häppchen lassen aber darauf schließen, dass er wieder über konkrete Informationen verfügt. Wie du, Raff, aber richtig sagst, interpretiert er sie erneut in der für Nvidia negativsten Weise.

[Gast]

Solange man nur den Umsatz der einzelnen Sparten kennt und nicht den Gewinn, macht es keinen Sinn darüber zu diskutieren, man kann nur weiter spekulieren.


Wie willst du den Gewinn einzelner Sparten ausrechnen? Dazu müsstest du die Entwicklungskosten zuordnen, und das wäre rein willkürlich.

[Iruwen]

Filtern ist ganz schön anstrengend, nach dem Einleitungssatz hat man eigentlich schon keinen Bock mehr... aber konsequent isser ja, vor allem bezüglich der Yields.

[ShinyMcShine]

Du weißt schon, wer Charlie ist, oder? Nvidia-Hasser Nr. 1. Das sieht man auch in jedem Absatz, wo er stets 'nen Flame einbaut. Die Infos seiner oft verlässlichen Quellen mariniert er in krasser Anti-NV-Polemik, von daher ist Filtern angesagt.

MfG,
Raff

Das er nVidia nicht mag habe ich mir beim Lesen schon gedacht. ;D Dass er Hasser Nr.1 ist wußte ich nicht. :freak:

VG
Shiny

[LovesuckZ]

Wow - der typ spekuliert immernoch, wie groß GF100 ist. Das ist jetzt wirklich lustig. Immerhin hätte er sich längst eine Karte kaufen und nachmessen können...

[Iruwen]

Die Kommentare sind lustig, was für Drogen nimmt denn thomasxstewart :D

[Dural]

210watt bei 405mm OK werden wir ja sehen ;)

wird das eigentlich sogar auf die 336SP version bezogen?

[huch]

210watt bei 405mm OK werden wir ja sehen ;)

wird das eigentlich sogar auf die 336SP version bezogen?

"before shaders are fused off": also auf die 384SP Version bezogen. Und vermutlich auch auf den Maximalausbau mit geplantem Takt, also wohl >=1.4GHz

klingt mEn als realer Maximalverbrauch dann durchaus nicht unrealistisch und würde gut zu 2x6pin = 225W max passen

[V2.0]

Es ist sowieo dämlich die TDP einer GPU auf Basis einer anderen GPU zu schätzen.

[AnarchX]

Heise: Endgültige Spezifikationen der GeForce GTX 460 enthüllt (http://www.heise.de/newsticker/meldung/Endgueltige-Spezifikationen-der-GeForce-GTX-460-enthuellt-1026888.html)

Also wohl doch zwei GTX 460 mit unterschiedlichem SI.

[boxleitnerb]

Also dieses elende Durcheinander wird ja immer schlimmer. Die 460 soll schneller als die 465 sein, dann noch zwei Varianten...AMD Lineup ist wenigstens straight forward. ;(

[Spasstiger]

Und die GTX 468 wird womöglich schneller als die GTX 470 (für einen Gleichstand wären bei 384 SPs denke ich 750 MHz Chiptakt und 1,05 GHz Speichertakt notwendig).
Dass die GTX 460 schon in der kleinen Variante in 3DMark Vantage so schnell ist wie die GTX 465, überrascht mich allerdings nicht.
Je nach Organisation des GF104 kann ich mir aber vorstellen, dass die GTX 465 mit aktiver Tessellation in Front liegt. Sollte der GF104 nur 8 Tessellationseinheiten und 2 Raster-Engines haben, dann wird die GTX 465 mit extremer Tessellation vermutlich um 10-20% vorne liegen, was das Namensschema wieder rechtfertigt.

Laut Heise soll die GTX 460 in beiden Varianten mit dem gleichen Speichertakt betrieben werden. Damit dürfte die größere Variante selbst ohne VRAM-Knappheit bei der kleinen Variante rund 10% schneller sein.

Bin mal gespannt, ob es die große GTX 460 mit der HD 5850 aufnehmen kann. Die Zeichen stehen nicht schlecht.

[ShinyMcShine]

Auch mit der Verfügbarkeit scheit es gar nicht sooo schlecht auszusehen. Bin auf die ersten Tests der 1GB-Variante gespannt. Daraus dürfte sich dann grob die Leistung der GTX486 abschätzen lassen. Das wird dann evtl. meine nächste Karte. ;)

VG
Shiny

[y33H@]

Sofern sich nicht weltbewegendes getan hat, hier die Theorie der "großen" GTX 460 vs. GTX 465. Letztere ist im Mittel ja etwa hinter HD5850.

• 336 ALUs @ 1.350 MHz vs. 352 ALUs @ 1.204 MHz
• 907 vs. 855 GFLOPS
• 56 TMUs @ 675 MHz vs. 44 TMUs @ 607 MHz
• 37,8 vs. 26,8 GTex/s
• 256 Bit @ 1,8 GHz vs. 256 Bit @ 1,6 GHz
• 115 GB/s vs.103 GB/s
• 32 @ 675 MHz vs. 32 ROPs @ 607 MHz

Pixelfüllrate hängt an den SMs, ROPs ranziehen bringt's hier nicht. Aber wer weiß, was NV da sonst noch gedreht hat. So hängen SMs und ALUs nicht fest aneinander, bei GF104 ändert sich ja bereits das Verhältnis. Hach wie simpel das früher doch war :ugly:

[Dural]

mir wäre ein voller gf104 x mal lieber als die 460er... die 468 kann wirklich eine gute karte werden, mal schauen!

und ich hoffe ja das NV das problem mit dem MC in den griff bekommen hat... da ist beim GF100 einfach was nicht OK... vieleicht liegt es ja auch nur an der nidrigen Spannung die auf der GPU anliegt, ich glaube es aber nicht ganz!!!

[Coda]

Problem mit dem MC? Niedriger Takt oder wie?

[Soundwave1983]

Problem mit dem MC? Niedriger Takt oder wie?

Zum Beispiel.
Muss doch seine Gründe haben, zumal ja einige Karten außer mit massiven Spannungserhöhungen fast nix am RAM Takt ändern können.

[y33H@]

@ Coda

Es gibt Gerüchte wonach die RAM-Spannung iwie an der VGPU hängt.

[Coda]

Die RAM-Spannung? Bestimmt nicht.

Die Memory-Controller laufen aber wohl mit VGPU.

[y33H@]

Ja, MC :usad:

[Dural]

viele sind der meinung das der MC zu wenig spannung für einen höheren speicher takt hat. fakt ist das sich der speicher höher takten lässt wenn man die vgpu erhöht, ich bin mir aber ziemlich sicher das es nicht nur an der geringen vgpu liegt sonder das eifach irgend was im MC nicht stimmt / zuwenig optimiert wurde!

der GT215 macht zb. mit 1,00Volt auf der GPU auch locker 1200MHz+ speicher takt mit, nur an der spannung kann es also fast nicht liegen... klar die beiden MC sind nicht direkt miteinander vergleichbar...

aber max 1000MHz bei 1,10Volt wie es beim GF100 üblich ist zeigen ja klar das etwas nicht i.O. ist

[Ailuros]

Dumme Frage: kann man irgendwelche verrueckte These auf die Beine stellen die die "Kastrierung" eines GF100 dies und den "zu" rechteckigen 104 die verbindet? Ich kann bei bestem Willen nicht verstehen warum der 104 die so merkwuerdig gestalten wurde und es macht auch keinen besonderen Sinn wenn man an die Anzahl der cores pro wafer denkt; anders "fast quadratisch" ist IMO um einiges idealer auf einem Kreis als "zu rechteckig".

[V2.0]

Nicht die geringste Ahnung. Ich habe zwar ne Idee, warum er diese Form hat, aber das in Verbindung zum Newsblurb von Ccharlie zu bringen gelingt mir dann auch nicht.

[Gast]

Naja, nicht quadratisch bedeutet eine nicht minimale Fläche, woraus sich bei konstantem Wärmeübergangskoeffizienten ein höherer Wärmeübergang und somit ein kühlerer Chip ergibt.

Du hattest nach ner verrückten These gefragt...

[Ailuros]

Nicht die geringste Ahnung. Ich habe zwar ne Idee, warum er diese Form hat, aber das in Verbindung zum Newsblurb von Ccharlie zu bringen gelingt mir dann auch nicht.

Ich bezieh auch nicht auf Charlie's newsblurb. Schiess los mit der Idee egal wie merkwuerdig sie erscheinen mag.

[AnarchX]

Spätestens wenn dann ein ein GF106 mit ~24mm x ~8 mm auftaucht, kann man sagen, dass beim GF10x Floorplaning etwas falsch gelaufen ist. :D

Aber zwei rechteckige GF104 würden wohl besser auf ein Package passen.
Vielleicht kann Nvidia auch die SMs nicht drehen, womit man eine quadratischere Form erreicht hätte.

[Ailuros]

Naja, nicht quadratisch bedeutet eine nicht minimale Fläche, woraus sich bei konstantem Wärmeübergangskoeffizienten ein höherer Wärmeübergang und somit ein kühlerer Chip ergibt.

Du hattest nach ner verrückten These gefragt...

Jegliche verrueckte These fuer so einen merkwuerdigen die ist willkommen.

Spätestens wenn dann ein ein GF106 mit ~24mm x ~8 mm auftaucht, kann man sagen, dass beim GF10x Floorplaning etwas falsch gelaufen ist. :D

Wieso falsch gelaufen? Ich tippe eher auf pure Absicht.

Aber zwei rechteckige GF104 würden wohl besser auf ein Package passen.

Hmmm nicht schlecht.

Vielleicht kann Nvidia auch die SMs nicht drehen, womit man eine quadratischere Form erreicht hätte.

Jetzt versteh ich mal wieder Bahnhof. Was meinst Du genau mit "SMs drehen" und wozu ueberhaupt?

[AnarchX]

http://images.dailytech.com/nimage/13440_GF100die.jpg

Bei GF104 werden die SMs bzw. Cluster wohl auch wie bei GF100 angeordnet sein (in 4er Reihen mit der kürzeren Seite verbunden), wenn man sie aber nun gedreht hätte und sie sich an den Längsseiten berühren würden, hätte man einen gleichseitigeren Die erzielt.


Wieso falsch gelaufen? Ich tippe eher auf pure Absicht.

Ein 24 x 8 mm Die wäre wohl alles andere als optimal für die Fertigung. Aber bei GF106 werden es wohl eher 2x 2 SMs sein.

[Gast]

Kann das nich einfach sein das sich das bei der Entwicklung des Chips so ergab?

Sprich wenn man GF100 auf GF104 schrumpft/weiterentwickelt ergibt sich eine etwas vom quadrat abweichende Form.
Der Aufwand den Chip wieder fast quadratisch zu machen ist einfach teurer als ihn einfach rechteckig zu lassen und ein paar weniger Dies pro Wafer kommen da letztendlich billiger.

[harzer_knaller]

[...] Aber zwei rechteckige GF104 würden wohl besser auf ein Package passen. [...]Interessanter Ansatz.^^ Aber steht das bisher bei irgendeinem IHV auf dem Plan?

[Hugo]

ich tippe auf Signallaufzeiten im Chip

[Coda]

Das ist auch mit großer Wahrscheinlichkeit der Grund.

Bei GF104 werden die SMs bzw. Cluster wohl auch wie bei GF100 angeordnet sein
GF104-Cluster sehen aber wahrscheinlich völlig anders aus (kein DP, 48 ALUs, 2 Quad-TMUs).

[Ailuros]

http://images.dailytech.com/nimage/13440_GF100die.jpg

Bei GF104 werden die SMs bzw. Cluster wohl auch wie bei GF100 angeordnet sein (in 4er Reihen mit der kürzeren Seite verbunden), wenn man sie aber nun gedreht hätte und sie sich an den Längsseiten berühren würden, hätte man einen gleichseitigeren Die erzielt.

Jetzt hab ich es kapiert. Wenn ich mir das Bild aber so ansehe komm ich gleich auf eine andere Schnappsidee: kastrierter cache zu X Prozentual von jeder Seite gibt mir auch etwas "rechteckigeres".....:rolleyes:

Ein 24 x 8 mm Die wäre wohl alles andere als optimal für die Fertigung. Aber bei GF106 werden es wohl eher 2x 2 SMs sein.

Ich hab noch keine die shots von 106 gesehen. Kann durchaus sein dass nur 104 die merkwuerdige Ausnahme hier ist und ein 23*16mm2 die fuer 104 ist ebenso sub-optimal was die Fertigung betrifft.

[V2.0]

http://images.dailytech.com/nimage/13440_GF100die.jpg

Bei GF104 werden die SMs bzw. Cluster wohl auch wie bei GF100 angeordnet sein (in 4er Reihen mit der kürzeren Seite verbunden), wenn man sie aber nun gedreht hätte und sie sich an den Längsseiten berühren würden, hätte man einen gleichseitigeren Die erzielt.


Ein 24 x 8 mm Die wäre wohl alles andere als optimal für die Fertigung. Aber bei GF106 werden es wohl eher 2x 2 SMs sein.

Ich glaube eher das Gegenteil, weil sie die SMs um 90° gedreht haben, war eine lineare Anordnung nötig. Damit würde man nämlich ein recht einfachen Signalweg bekommen und damit ausgeglichene Laufzeiten.

[Coda]

Jetzt hab ich es kapiert. Wenn ich mir das Bild aber so ansehe komm ich gleich auf eine andere Schnappsidee: kastrierter cache zu X Prozentual von jeder Seite gibt mir auch etwas "rechteckigeres".....:rolleyes:
Sehr wahrscheinlich eben nicht.

Ich glaube eher das Gegenteil, weil sie die SMs um 90° gedreht haben, war eine lineare Anordnung nötig. Damit würde man nämlich ein recht einfachen. Signalweg bekommen.
Hallo? Jemand Zuhause?

Die SMs werden höchstens zufällig eine ähnliche Form haben. Ihr könnte nicht von Fermi auf GF104 schließen.

[Ailuros]

GF104-Cluster sehen aber wahrscheinlich völlig anders aus (kein DP, 48 ALUs, 2 Quad-TMUs).

Dem bin ich mir aber noch nicht sicher. Ich tippe momentan eher auf 16 cluster, welches zwar ein merkwuerdiges 8+8+8 oder 16+8 Dilemma pro SM zum Vorschein bringt, aber zumindest erstmal die 4TMU/SM Logik vom GF100 behaelt.

[Coda]

Dem bin ich mir aber noch nicht sicher. Ich tippe momentan eher auf 16 cluster, welches zwar ein merkwuerdiges 8+8+8 oder 16+8 Dilemma pro SM zum Vorschein bringt, aber zumindest erstmal die 4TMU/SM Logik vom GF100 behaelt.
Sorry, aber da ist 3xVec16 + 2 Quad TMUs um Lichtjahre wahrscheinlicher. Das funktioniert einfach nicht.

Wenn dann stimmt schon allein der SM-Count nicht und sie verarschen alle komplett.

Ich glaube aber ziemlich fest an meine Möglichkeit, weil es technisch auf allen Ebenen einfach Sinn ergibt. Soll ich's dir ausführen? :tongue:

[AwesomeSauce]

Hat eigentlich jemand den Artikel von Leonidas gelesen? http://www.3dcenter.org/artikel/die-spezifikationen-zur-geforce-gtx-460
der GF104-Chip verfügt in der Tat über 4 Raster Engines
der GF104-Chip mit 2 Raster Engines,Hier wird wohl der GF106 gemeint sein. 4 Rasters für GF104 spräche aber wieder für 16 SMs (ergo 24 Shader per SM), oder nicht?

[Coda]

Wieso? GF104 hätte 8 SMs. Wer hindern NVIDIA daran einen Rasterizer für zwei SMs zu verwenden?

Allerdings glaube ich auch eher, dass es nur zwei werden.

[AnarchX]

Selbst drei wären denkbar.
Zumal es auch Vermutungen gibt, dass die GPCs nicht so fest verdrahtet sind, wie es NV glauben lassen will.

[AwesomeSauce]

Der Schreibfehler im Artikel wurde korrigiert:up:
Selbst drei wären denkbar.
3 Raster Engines für 8 oder 16 SMs? Sehe nicht, wie das sinnvoll aufgehen könnte:confused:

Wieso ist sich Leonidas seiner Sache so sicher? Er schreibt, als wären die vier Raster Engines für GF104 bereits in Stein gemeisselt. Im Heise-Artikel steht jedenfalls nichts davon...

[V2.0]

Hallo? Jemand Zuhause?

Die SMs werden höchstens zufällig eine ähnliche Form haben. Ihr könnte nicht von Fermi auf GF104 schließen.

Schau Dir eine DieShot von GF100 an und ein Blockdiagramm des GF100 an. Das Blockdiagramm ist rechteckiger.

http://www.techreport.com/r.x/gf100-arch/gf100-block.png

[Coda]

Schau Dir eine DieShot von GF100 an und ein Blockdiagramm des GF100 an. Das Blockdiagramm ist rechteckiger.
Sorry, aber ich kann dir nicht folgen. Was hat das Fermi-Blockdiagramm mit dem echten Chiplayout und vor allem was mit GF104 zu tun?

Vor allem fehlen auf dem Blockdiagram komplett die TMUs.

[Gast]

Die jeweils vier kleinen, dunkelblauen Rechtecke sind die TMUs.
Sinnvoller wäre es da wohl eher die Bestandteile im Die-Shot zu suchen und mit Hilfe von GT200 die GF104-SMs zu projizieren.

[AwesomeSauce]

Vor allem fehlen auf dem Blockdiagram komplett die TMUs.
Nein, es sind die 4 kleinen blauen Kästchen in der SM: http://www.computerbase.de/bildstrecke/28115/20/

EDIT: Zu langsam :)

[Coda]

Die jeweils vier kleinen, dunkelblauen Rechtecke sind die TMUs.
Na klar, sieht man ja auch sofort. Die nehmen auf dem Die natürlich auch so wenig Platz ein :facepalm:

[Spasstiger]

Die TMUs sind in den NV-Blockdiagrammen immer so klein dargestellt. Aber natürlich ist es idiotisch, von einem Blockdiagramm auf das physikalische Chiplayout zu schließen.

[Gast]

Na klar, sieht man ja auch sofort. Die nehmen auf dem Die natürlich auch so wenig Platz ein :facepalm:


Wer redet denn davon, dass ein Blockdiagramm etwas mit den physischen Größenverhältnissen zu tun hat?

[V2.0]

Die TMUs sind in den NV-Blockdiagrammen immer so klein dargestellt. Aber natürlich ist es idiotisch, von einem Blockdiagramm auf das physikalische Chiplayout zu schließen.

Es ging mir auch nur um die Anbindung der einzelnen SM Einheiten an den L2 und untereinander im Vergleich zum Die-Shot.

[Coda]

Wer redet denn davon, dass ein Blockdiagramm etwas mit den physischen Größenverhältnissen zu tun hat?
V2.0, außer ich versteh das hier falsch:
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=8104005&postcount=837

Es ging mir auch nur um die Anbindung der einzelnen SM Einheiten an den L2 und untereinander im Vergleich zum Die-Shot.
Und was soll das mit der Die-Form von GF104 zu tun haben?

[V2.0]

V2.0, außer ich versteh das hier falsch:
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=8104005&postcount=837


Und was soll das mit der Die-Form von GF104 zu tun haben?

Ich rede von der Anordnung, nur von der Anordnung der SP cluster. Denk die Die Cluster des Dieshots so gedreht und angeordnet wie im Blockdiagramm. Also in 2 Reihen entlang einer Mittelachse und es entsteht ein rechteckiger Die.

[AwesomeSauce]

Bilder der GTX460 Referenzkarte:
http://www.expreview.com/img/news/2010/06/24/NVIDIA_GTX460__01.jpg
http://en.expreview.com/2010/06/24/geforce-gtx-460-referenced-original-image-unleashed/7484.html
Sieht etwas ungewöhnlich aus:)

[Gast]

Sieht vor allem aus, dass ein Teil der heißen Luft zurück ins Gehäuse geblasen wird, das ist nicht besonders gut. Vor allem wenn man dabei noch gegen den Luftstrom des vorderen Gehäuselüfters arbeitet.

[V2.0]

Sieht laut und heiss aus. 2x6Pin und Heatpipes.

[Spasstiger]

In den Ausmaßen fast identisch zur Radeon HD 5770:

http://www.abload.de/img/radeon_hd_5770.previewepov.jpg

http://www.abload.de/img/nvidia_gtx460__023puf.jpg

(Hab das Bild der HD 5770 so verkleinert, das die PCIe-Leiste auf beiden Bildern gleich lange ist)

Und mit 2*6 Pin hatte Ailuros tatäschlich recht. Also wohl doch mehr als 130 Watt TDP.

/EDIT: Bildgröße angeglichen.

[AwesomeSauce]

Based on GF104, GTX 460 is set to have 336 CPU Core/4 units GPC Design/192 bit Bus Width /768MB Memory Size, Core/Shader/Memory frequency respectively for 675/1350/1800MHz.
4 GPC = 4 Raster Engines confirmed? Wäre auf jeden Fall cool, aber Overkill:D

[y33H@]

4 GPCs steht seit Wochen :P

[Dural]

sieht doch gut aus, leistung der GTX460 dürfte auf höhe des GT200 / 5830 sein.

[Spasstiger]

Mit 4 GPCs hätte man eine bessere Tessellations-Effizienz als im High-End. Genau wie bei ATI. Die Radeon HD 5770 bricht mit Tessellation weniger stark ein als die Radeon HD 5870.

[AwesomeSauce]

4 GPCs steht seit Wochen :P
Wirklich? Wenn dem so wäre, wieso haben u.a Coda (2), Ailuros (4) und AnarchX (3) gestern immer noch darüber spekuliert;)

[LovesuckZ]

Mit 4 GPCs hätte man eine bessere Tessellations-Effizienz als im High-End. Genau wie bei ATI. Die Radeon HD 5770 bricht mit Tessellation weniger stark ein als die Radeon HD 5870.

Die 5770 bricht deswegen nicht so stark ein, weil sie die selbe Anzahl an Tessellationseinheiten hat - nämlich eine. Um eine bessere Tessellationseffizienz zu haben, müsste der GF104 um mindesten 16 Geometrieeinheiten verfügen.

/edit: Wobei das in bezug auf GF104 immer noch nciht ganz richtig ist. GF100 hat zuviel Geometrieleistung für die allgemeine Rechenleistung. Das wird beim GF104 noch krasser sein.

[Ailuros]

Wirklich? Wenn dem so wäre, wieso haben u.a Coda (2), Ailuros (4) und AnarchX (3) gestern immer noch darüber spekuliert;)

Weil keiner von uns bis jetzt sicher ist ob es sich um 16 oder 8 SMs am Ende handelt. Ich tippe weiterhin auf 16SMs und 4 GPCs und meine eigene idiotische These ist dass sie hoechstwahrschenlich 8SPs/SM und 2 ROP partitions vom 100-er beschnitten haben u.a.

[AwesomeSauce]

Gab es bei Nvidia eigentlich schon mal Vec8 ALUs? AFAIR beim G80, könnte aber auch total falsch liegen. Ergibt denn eine 16+8 Konfiguration überhaupt Sinn oder ist 8+8+8 the way to go?

[Ailuros]

Gab es bei Nvidia eigentlich schon mal Vec8 ALUs? AFAIR beim G80, könnte aber auch total falsch liegen. Ergibt denn eine 16+8 Konfiguration überhaupt Sinn oder ist 8+8+8 the way to go?

Alles G8x/9x (8+8) und GT21x (8+8+8) hat "Vec8" ALUs wie Du sie nennst. Jedoch ist GF100 eigentlich 16+16; obwohl insgesamt 8+8+8 mehr Sinn macht passt es leider nicht in die GF10x Schachtel und deshalb frage ich mich ob sie DP einfach kastriert haben in dem sie vom einen 16-er einfach die Haelfte beschnitten haben.

[Spasstiger]

Alles G8x/9x (8+8) und GT21x (8+8+8) hat "Vec8" ALUs wie Du sie nennst.
Wenn ich die Architektur richtig auffasse, sind es SIMDs bestehend aus jeweils 8 skalaren ALUs. Korrekt?
Beim GF100 hat man aber tatsächlich für 32 ALUs nur zwei Instruction Ports. Wenn NV nicht alles umbaut, kann es mit 16 SMs nur auf eine 16+8-Konfiguration rauslaufen.

[Bucklew]

http://www.abload.de/img/nvidia_gtx460__023puf.jpg
Ui, vielleicht endlich ein Nachfolger für den legendären 7900GTX Lüfter?

[y33H@]

Wohl eher nicht. Weniger Pipes und höhere TDP ;)

[deekey777]

Mit 4 GPCs hätte man eine bessere Tessellations-Effizienz als im High-End. Genau wie bei ATI. Die Radeon HD 5770 bricht mit Tessellation weniger stark ein als die Radeon HD 5870.
Ob der Einbruch daran liegen würde.

[Coda]

Wie meinen?

[Gast]

Nur 768MB VRAM? Sorry, aber das ist heute einfach zu wenig. Noch dazu ist der Chip ziemlich stark abgespeckt und die Taktraten sind auch relativ niedrig und trotzdem 2x 6P? Sieht schwer danach aus als ob man die selben Probleme hätte wie bei GF100 - hohe Leistungsaufnahme, schlechte Yields.

[dildo4u]

Nur 768MB VRAM? Sorry, aber das ist heute einfach zu wenig.[/b]
Es gibt 2 Versionen mit 768mb und 1GB.

http://www.heise.de/newsticker/meldung/Endgueltige-Spezifikationen-der-GeForce-GTX-460-enthuellt-1026888.html

[Bucklew]

Es gibt 2 Versionen mit 768mb und 1GB.

http://www.heise.de/newsticker/meldung/Endgueltige-Spezifikationen-der-GeForce-GTX-460-enthuellt-1026888.html
Zumal die Auflösungen/AA-/AF-Einstellungen, in denen 1GB limitiert für die Karte sowieso zu hoch sind.

[Fattyman]

Müsste eigentlich nicht auch das Registerfile angepasst werden?

32 K Register für 32 Cores macht ungefähr 1024 Register für einen Core.
Demzufolgende sollte für 24 Cores nur noch 24 K Register im Registerfile stecken...

[y33H@]

Noch dazu ist der Chip ziemlich stark abgespeckt und die Taktraten sind auch relativ niedrig und trotzdem 2x 6P?Niedrig? 675/1.350 MHz sind nicht niedrig für eine Fermi-Karte.

[Coda]

Müsste eigentlich nicht auch das Registerfile angepasst werden?

32 K Register für 32 Cores macht ungefähr 1024 Register für einen Core.
Demzufolgende sollte für 24 Cores nur noch 24 K Register im Registerfile stecken...
Es gibt nicht ein großes Registerfile. Jeder SM hat sein eigens. Und klar skaliert die Gesamtgröße der Registerfiles mit der Anzahl der SMs.

[Fattyman]

Es gibt nicht ein großes Registerfile. Jeder SM hat sein eigens. Und klar skaliert die Gesamtgröße der Registerfiles mit der Anzahl der SMs.
Mir kommt es aber auf die Größe des Registerfiles INNERHALB eines SMs an. Dieses Registerfile sollte mit der Anzahl der Cores innerhalb eines SMs mit der angegebenen Rate von 1 k Register pro Core skalieren.

[ShinyMcShine]

Niedrig? 675/1.350 MHz sind nicht niedrig für eine Fermi-Karte.

Und sollten sich die Übertaktungsgerüchte halbwegs bewahrheiten, dann ist für die "volle" GTX 468 wohl auch ein Chiptakt von 700/1400 und mehr drin! Das wär schon was...

;D

VG
Shiny

[Coda]

Mir kommt es aber auf die Größe des Registerfiles INNERHALB eines SMs an. Dieses Registerfile sollte mit der Anzahl der Cores innerhalb eines SMs mit der angegebenen Rate von 1 k Register pro Core skalieren.
Ja. Steht denn irgendwo was Gegenteiliges?

[Fattyman]

Ja. Steht denn irgendwo was Gegenteiliges?
Schau mal auf 3DCenter - News vom 23.6. - nach. Die haben nur das Layout angepasst, aber das Registerfille immer noch in seiner Größe belassen...

[Coda]

Das kannst du alles getrost vergessen. 24 SPs pro SM sind nicht möglich. Da stimmt einfach gar nichts. Das Bild ist geshoppt und wurde einfach abgeschnitten.

Es sind 3x 16 ALUs und 8 TMUs pro Cluster.

[y33H@]

@ ShinyMcShine

700/1.400 hatte ja schon die GTX 480 - und ein GF100 packt bei Standardspannung fast immer mehr als 800/1.600, oft auch 850/1.700 MHz. Geht halt in den Strom ;D

[Gipsel]

Das kannst du alles getrost vergessen. 24 SPs pro SM sind nicht möglich. Da stimmt einfach gar nichts. Das Bild ist geshoppt und wurde einfach abgeschnitten.

Es sind 3x 16 ALUs und 8 TMUs pro Cluster.
Wäre auch mein Favorit, da es die größten Transistoreinsparungen ermöglicht ohne wesentlich an der Performance zu knausern.

3x16 ALUs
1x16 L/S
1x4 SFUs (oder auch 2x4, um wieder etwas näher an das GT200-Verhältnis zu kommen?)
2x4 TMUs
Das Ganze dürfte von 3 Schedulern gefüttert werden, GP-Cache/local memory bleibt zu GF100 identisch, Texture-L1-Cache könnte sich verdoppeln (16kB pro SM?). Zusammen mit nur noch 2 (oder 3?) Rastereinheiten (wenn nur 2, dann vielleicht auf 16 Pixel/Takt aufgebohrt?), entfernter double precision Fähigkeit, 512kB L2 (4x128Kb), 32ROPs (4x8) an einem 256bit Speichercontroller dürfte das dann deutlich kleiner als GF100 werden, so daß die gerüchteweise herumspukenden 350-375mm² bei 384 ALUs locker drin sein sollten.

Die Alternative wäre vielleicht noch das Sparmodell von Damien (hardware.fr), wobei nv einen 16er ALU-Block entfernt, dafür aber über die SFUs wieder parallele MULs zuläßt und das als 8 zusätzliche "cuda cores" verkauft. Das hätte auch was für sich, da dann eigentlich der komplette Rest unverändert bleiben könnte (4 SFUs, 16 LS, 4 TMUs pro SM). Allerdings wäre der Verwaltungsoverhead immer noch ziemlich groß, das wird nur durch die 8 hingemogelten "SFU-ALUs" gebessert. Es wären immer noch 2 Scheduler pro SM nötig, was im Verhältnis schlechter als die 3 Scheduler für die 3x16 ALU-Variante wäre. Der erhöhte Aufwand für doppelt so viele Raster-Einheiten käme noch hinzu, wobei ich ja immer noch keinen Beleg dafür gesehen habe, daß die GPCs und die feste Zuordnung der Rastereinheiten zu diesen real ist. 3x8=24 Pixel-Raster für 32 ROPs würde doch gar nicht so schlecht passen beim Vergleich mit GF100 (4x8=32 Pixel Raster für 48 ROPs).

Das Argument mit der geringeren Tesselationsleistung sticht in meinen Augen auch nicht wirklich, selbst mit 8 SMs und 2 Setup/Raster-Engines käme man noch auf die etwa vierfache Tess-Leistung des RV870. Das würde für das Performancemodell doch schon reichen, oder nicht? Und wenn dann GF108 bei genau RV870 landet, warum sollte das schlimm sein? Als wenn man bei Low-End-Karten nicht auch den Tessellationsslider in den Optionen runtersetzen könnte, genau wie man das aufgrund der begrenzten Leistung bei Auflösung/AF/AA usw. doch sowieso macht :rolleyes:

[AwesomeSauce]

Mit nur 8 SMs, also 8 PolymorphEngines, hätte GF104 für mich viel von seiner Attraktivität verloren...

[Coda]

Wieso das denn?

[Gipsel]

Mit nur 8 SMs, also 8 PolymorphEngines, hätte GF104 für mich viel von seiner Attraktivität verloren...
Warum? Weil die Tess-Leistung von "Overkill" auf "der Konkurrenz weit überlegen" (Faktor 4!) zurückgeht?

[AnarchX]

Würden die Polymorph-Engines den Hot-clock-Takt vertragen?

Die von Expreview gezeigte GTX 460 hat übrigens das 256-Bit SI. Eine native 192-Bit Version ist dann vielleicht etwas kürzer und kommt mit 1x 6-Pin aus.

[Coda]

Warum? Weil die Tess-Leistung von "Overkill" auf "der Konkurrenz weit überlegen" (Faktor 4!) zurückgeht?
Wer sagt denn, dass man die Tesselationseinheiten überhaupt anhand der Anzahl vergleichen kann? Das halte ich für sehr gewagt.

Wenn ATI vier Tesselatoren hätte und weiterhin nur einen Rasterizer (jaja, "zwei") würde sich auch nichts verbessern. Bin echt mal gespannt, ob SI daran was ändern wird.

Würden die Polymorph-Engines den Hot-clock-Takt vertragen?
Die laufen doch wohl mit Core-Clock.

[LovesuckZ]

Wer sagt denn, dass man die Tesselationseinheiten überhaupt anhand der Anzahl vergleichen kann? Das halte ich für sehr gewagt.


8x1/6 ist das vierfache von 1x1/3

[Coda]

Das ist eine mathematisch korrekte Aussage. Und weiter?

[AwesomeSauce]

Wieso das denn?
Weil ich auf einen GF104 im Vollausbau gehofft hatte, der mit 4 Setups/Rasterizer und 16 PEs wohl eine GTX470 in jeglicher Hinsicht in die Tasche gesteckt hätte.

[y33H@]

GF104 full kommt aber (noch) nicht.
Die von Expreview gezeigte GTX 460 hat übrigens das 256-Bit SI.Das PCB? Oder die Bilder der Referenzkarte von NV, welche ursprünglich von PC-inLife kamen?

[deekey777]

Wie meinen?
Ist der Einbruch zB Unigine Heaven dadurch verursacht, weil die HD5800 nur einen Tessellator hat, oder weil der Datenfluß vom Tessellator zum Domainshader stockt (bei der ganzen HD5000-Serie)?
Edit: Ich habe Fußball gekuckt und nicht aktualisiert.
Wer sagt denn, dass man die Tesselationseinheiten überhaupt anhand der Anzahl vergleichen kann? Das halte ich für sehr gewagt.

Wenn ATI vier Tesselatoren hätte und weiterhin nur einen Rasterizer (jaja, "zwei") würde sich auch nichts verbessern. Bin echt mal gespannt, ob SI daran was ändern wird.


Die laufen doch wohl mit Core-Clock.
In Unigine Heaven limitiert der Rasterizer nicht, wenn ich den Artikel von B3D richtig verstehe:
http://www.beyond3d.com/content/reviews/54/9
Moving onwards from the domain shader, we find that, on average, for 15% of the render time the pipeline is stalled by rasterisation (setup included here), meaning that the domain shader can output processed vertices and the primitive assembler can assemble them faster than they can be setup and rasterised. This is a consequence of having numerous small triangles in the scene (just look at something like the dragon's leg or the roof), and is one of the cases where upping setup rate beyond 1 triangle/clock could have helped (we're pretty sure the rasteriser itself isn't the one causing the stalls, given pixel/triangle ratios). ... .

[Gast]

Es sind 3x 16 ALUs und 8 TMUs pro Cluster.

Wieso nicht 3x8 + 4TMUs pro Cluster?

[ShinyMcShine]

@ ShinyMcShine

700/1.400 hatte ja schon die GTX 480 - und ein GF100 packt bei Standardspannung fast immer mehr als 800/1.600, oft auch 850/1.700 MHz. Geht halt in den Strom ;D

Ich bin ja schon damit zufrieden, wenn nVidia das Referenzdesign einer GTX 468 mit 700/1400 rausbringt. Ist ja immer eine Sache, was der Chip wirklich verträgt, und was nVidia ihm für den Endkunden mit auf den Weg gibt.

Wenn aber das Referenzdesign mit 700/1400 läuft, gibt es ein wenig später hoffentlich leckere Custom-Designs mit leiser(er) Kühllösung, mehr Chiptakt (750/1500 wäre super!) und 2GB RAM... :eek: Ich muss mich nun erstmal zügeln. Noch gibt's ja nichtmal 'ne Ankündigung der Karte. ;D

VG
Shiny

[harzer_knaller]

Wenn ich jetzt mal so als Laie die Frage stellen darf: warum meint ihr alle, dass hot clock (immer?) doppelt so hoch sein soll wie der normale core clock?
Ich mein, bei G92(A2/B1) liegt der beim 2.44x-fachen des core clocks. Macht es nur keinen Sinn, die Shader über das 2-fache zu takten?

[V2.0]

Warum freut ihr euch auf die Karte? Vor Gf100 herrschte auch freudige Erregung und was kam war wenig begeisternd. Warten wir es doch erst einmal ab.

[IVN]

Warum freut ihr euch auf die Karte? Vor Gf100 herrschte auch freudige Erregung und was kam war wenig begeisternd. Warten wir es doch erst einmal ab.
Vorfreude ist die schönste Freude. ;)

[y33H@]

Vor Gf100 herrschte auch freudige Erregung und was kam war wenig begeisternd.Bis auf den Stromverbrauch und die Lautheit rockt der GF100 ja. Beste BQ, massig Features und sehr flott - überall in Front. Und was die beiden Kritikpunkte anbelangt, die lassen sich beheben. Problemlos.

[Botcruscher]

Problemlos wird das maximal in vollklimatisierten Räumen. Der große Rest dürfte sich derweil eher an gehobenen Raumtemperaturen erfreuen. Schon die 150W Schleudern der alten Generation sind da ätzend genug.

[y33H@]

Du willst ernsthaft behaupten, eine GTX480 erhöht die Raumtemperatur? Vll bei 15 m² und nach 6h Furmark ...

[Coda]

GF104 dürfte auch pro Rechenleistung auch weniger Strom verbrauchen, allein schon weil schon einige Feature entfernt würde die nur für den Compute-Markt relevant sind.

Ich wäre nicht überrascht, wenn das Ding nur CUDA-Compute-Capability 1.x hat anstatt 2.0

[Botcruscher]

Der Rechner wärmt bei mir die Bude deutlich auf, da reicht normales zockn über 2h. Im Winter spart das die Heizung im Sommer nervt es einfach nur. Dabei wohne ich nicht mal im Dachgeschoss, noch wäre der Verbrauch von der Kiste wirklich hoch.
EDIT: Der Verbrauch bleibt einfach der Haupt Kritikpunkt. 100 bis 150W wären schon nett.

[y33H@]

Ich mess mal bei mir nach :ulol:

[Botcruscher]

Du, als dekadentes, europäisches Wohlstandskind in deiner 300m² Loft.;D

PS: Steht Mitte Juli den nun als Termin fest?
PSS: 12. also. 2 Karten ein Name sind ja wieder ganz großes Kino. NV bleibt sich treu. Eigentlich seit gestern bekannt.

[OgrEGT]

NVIDIA bringt tatsächlich zwei Versionen der GTX 460 - Eckdaten bekannt

http://ht4u.net/news/22281_nvidia_bringt_tatsaechlich_zwei_versionen_der_gtx_460_-_eckdaten_bekannt/

Edit: Unterscheiden sich wohl nur bzgl. des Speicherinterfaces 256 vs 192bit

[y33H@]

Alt ;)

@ Botcruscher

Ey, unter 100 m²! :biggrin:
Steht Mitte Juli den nun als Termin fest? Könnte man meinen.

[aylano]

Mit 4 GPCs hätte man eine bessere Tessellations-Effizienz als im High-End. Genau wie bei ATI. Die Radeon HD 5770 bricht mit Tessellation weniger stark ein als die Radeon HD 5870.
Was meinst du mit Tessellations-Effizienz?
Die Tesselation-Engine im Polymorph braucht AFAIK doch die Shader-Cores.
Und mit 4GPCs & 16 Tessel-Engines hätten zwar ein höheres Tesselation vs. Shader Verhältnis (ich glaube du meinst das so), aber andererseits haben der GF104 eigentlich weniger Shader-Cores für Tesselation zu verfügung, weil die Shader ja auch so fürs Spiel gebraucht werden.

Bis auf den Stromverbrauch und die Lautheit rockt der GF100 ja. Beste BQ, massig Features und sehr flott - überall in Front. Und was die beiden Kritikpunkte anbelangt, die lassen sich beheben. Problemlos.
Und wie soll das problemlos gelöst werden?
Als, einzige Maßnahme fällt mir nur die Reduktion der Tesselation-Leistung ein.
Verbesserungen in der Fertigung führen auch beim Konkurrenten zu Verbesserungen.

[Gast]

Vollausbau is interessanter ^^ Aber die Speicherbandbreite... das Baby wird knappern, hoffe da lässt sich die Taktschraube gut drehen (1920@4xaa muss drin sein).

[Gast]

Du willst ernsthaft behaupten, eine GTX480 erhöht die Raumtemperatur? Vll bei 15 m² und nach 6h Furmark ...

Schon die alte Generation erhöht die Raumtemperatur massiv.

[Spasstiger]

Was meinst du mit Tessellations-Effizienz?
Ich meine damit, wie gut der Chip die Framerate halten kann, wenn Tessellation ins Spiel kommt. Natürlich hat der GF100 weiterhin die beste Performance mit Tessellation. Aber wenn z.B. der GF100 um 30% mit Tessellation einbricht, bricht der GF104 vielleicht nur um 25% ein. Im Idealfall kommt der GF104 dann sogar an einen gleichgetakteten GF100 ran, was die absoluten Frameraten angeht.

Schon die alte Generation erhöht die Raumtemperatur massiv.
Selbst mein PC, der im Schnitt weniger Abwärme erzeugt als eine GTX 480, erhöht die Zimmertemperatur bei mir (11 m²) um 2-3°K, wenn Zimmertüre und Fenster geschlossen sind.

[y33H@]

@ aylano

Für den Enduser meinte ich. Das AMP!-Design etwa: Lüfter 2D auf 30% und 3D bis 45% hoch gehen lassen, dazu nur 0,95V - fertig =)
Schon die alte Generation erhöht die Raumtemperatur massiv. Mir wurde nicht bewusst wärmer, als ich meine 8800 Ultra gegen eine GTX280 getauscht habe. Und es wurde aufgrund der HD5870 auch nicht wieder kühler.

[AwesomeSauce]

Die Tesselation-Engine im Polymorph braucht AFAIK doch die Shader-Cores
Nein! Nur die Hull- und Domain-Shader werden in den Shader-Einheiten abgearbeitet (wo denn sonst;)), genau wie bei den AMD-Modellen. Der eigentliche Subdivision-Prozess (das Tessellieren) findet bei beiden in Fixed-Function-Einheiten statt. So schreibt es die DX11-Pipeline vor. Lektüre gefällig? http://www.nvidia.com/content/nvision2008/tech_presentations/Game_Developer_Track/NVISION08-Direct3D_11_Overview.pdf

Dass Tessellation bei NV in komplett in den Shadern laufen soll, ist ein Furz von Charlie, der, wie so oft, null Wahrheitsgehalt enthält.

[Spasstiger]

Trotzdem spielt die Shaderleistung natürlich eine wichtige Rolle für den Einsatz von Tessellation, weil man Tessellation nur mit den beiden Shader-Stages sinnvoll einsetzt. Bei adaptiver Tessellation ist eine Radeon HD 5870 z.B. näher dran an einer GTX 480 als bei reiner Tessellation ohne programmierten Anteil.

[Coda]

Es gibt keine reine Tesselation ohne programmierten Anteil. Schon allein für das LOD muss man rechnen.

Der Aufwand kann natürlich schwanken.

[LovesuckZ]

Bei adaptiver Tessellation ist eine Radeon HD 5870 z.B. näher dran an einer GTX 480 als bei reiner Tessellation ohne programmierten Anteil.

Nö, das stimmt nicht.

[y33H@]

@ Spasstiger

Was ist "adaptive Tessellation" und was "reine Tessellation ohne programmierten Anteil"? :redface:

[Schlammsau]

Bis auf den Stromverbrauch und die Lautheit rockt der GF100 ja. Beste BQ, massig Features und sehr flott - überall in Front. Und was die beiden Kritikpunkte anbelangt, die lassen sich beheben. Problemlos.

Überall in Front? :freak:
Redest du jetzt von der GTX480 oder der gesamten Serie?

[y33H@]

Rate mal :P ;D

[Schlammsau]

Rate mal :P ;D

Sag du es mir!

[y33H@]

Nur die GTX480 ist overall ("überall") in Front.

[Gast]

Beide raus hier!

[Spasstiger]

@ Spasstiger

Was ist "adaptive Tessellation" und was "reine Tessellation ohne programmierten Anteil"? :redface:
Ich hatte diese Benchmarks im Hinterkopf: http://www.behardware.com/articles/787-8/report-nvidia-geforce-gtx-480-470.html.
Runterscrollen bis zum Abschnitt "Displacement mapping".
Im Benchmark "Tessellation Ultra" sind es 571 fps gegen 259 fps, im Benchmark "Adaptive Tessellation Ultra" dagegen 769 fps gegen 525 fps. Die Radeon HD 5870 rückt also deutlich näher an die GTX 480 ran. Kann aber natürlich auch daran liegen, dass die Geometrielast sinkt.

Mit meiner Äußerung "ohne programmierten Anteil" hab ich natürlich daneben gelegen. Aber die adaptive Tessellierung dürfte mehr Aufwand für die programmierbaren Einheiten bedeuten als die normale Tessellierung, weil man ja dynamisch den Tessellationsgrad für jedes "Patch" ermitteln muss.

[Gast]

Wieso beruft sich PCGH als einzige Webseite fälschlicherweise auf nen asiatischen Thread, was die GTX-460-Ergebnisse angeht, und nicht auf die Quelle bei Heise? Die waren es doch, die von den 6000 Punkten und 830/900er OC-Taktraten sprechen.

[y33H@]

Hatten die das übernommen oder hatte Heise das von den Asiaten?

[Gast.3]

Hatten die das übernommen oder hatte Heise das von den Asiaten?

Da reicht allein schon ein Blick auf das Datum.

[y33H@]

:usad:

[ShinyMcShine]

Wenn ich jetzt mal so als Laie die Frage stellen darf: warum meint ihr alle, dass hot clock (immer?) doppelt so hoch sein soll wie der normale core clock?
Ich mein, bei G92(A2/B1) liegt der beim 2.44x-fachen des core clocks. Macht es nur keinen Sinn, die Shader über das 2-fache zu takten?

Beim GF100 ist es eben so, dass bisher die Hot Clock das 2-fache der Core Clock beträgt. Dies ist, bisherigen Gerüchten zufolge, auch bei der GTX 460 mit dem GF104 so. Darum spinnen wir das Spielchen einfach so weiter... :wink:

VG
Shiny

[Gast]

So schreibt es die DX11-Pipeline vor.
Nö, tut sie nicht. Es ist allerdings das sinnvollste, was man momentan machen kann.

[harzer_knaller]

Okee. Danke, ShinyMcShine. :) Also gibt's, bis auf aktuelle Gewohnheit, keinen wirklichen Grund dafür.

[Gast]

Der Grund ist(oder war) eine Limitierung im Design. 1:2 ist dabei das Minimum. Es darf auch mehr sein.

[aylano]

Für den Enduser meinte ich. Das AMP!-Design etwa: Lüfter 2D auf 30% und 3D bis 45% hoch gehen lassen, dazu nur 0,95V - fertig =)

Das sind aber nur kurzfristige Lösungen, was im Notebook-Bereich mit kleineren Fermi-Modell nichts bringt.


Nein! Nur die Hull- und Domain-Shader werden in den Shader-Einheiten abgearbeitet (wo denn sonst), genau wie bei den AMD-Modellen. Der eigentliche Subdivision-Prozess (das Tessellieren) findet bei beiden in Fixed-Function-Einheiten statt.
Aha, interessant.
Was Hull- & Domain-Shader machen weiß ich zwar nicht, aber naja.
Und wenn man schon dabei sind. GT200 hatte AFAIK fixe DP-Einheiten und der GF100 nicht mehr, ist das korrekt???

Welche Leistung geht dann beim GF104 zurück, wenn der GF104 nur 384 Shader-Cores & 64 TMUs statt 512 Shader-Cores & 64 TMUs hätte??????????

[AnarchX]

A1 wird wohl das Produktionsstepping. Hier ein A1-Die (22. Woche 2010) auf einem Custom-PCB:
http://img340.imageshack.us/img340/2638/43224481277402294391102.jpg
http://itbbs.pconline.com.cn/diy/11549111.html

Die 256-Bit 460 soll wohl GF104-350 sein.

[Dural]

A1 überrascht aber schon etwas... :rolleyes: sicher?

man stelle sich vor NV hätte ein A2 oder sogar A3 benötigt...

G94 kamm zwar auch im A1, aber auch nicht wirklich vergleichbar da es beim GF104 doch änderungen gibt.

[Spasstiger]

Aha, interessant.
Was Hull- & Domain-Shader machen weiß ich zwar nicht, aber naja.
In den Hull- und Domain-Shader-Stages werden die erforderlichen Berechnungen und Veränderungen der Geometrie vorgenommen, um überhaupt einen sichtbaren Einfluss der Tessellation auf die Szene zu haben.
Ohne Verschiebung der Eckpunkte in der Domain-Shader-Stage sieht man lediglich in einer Wireframe-Ansicht Unterschiede: http://www.forum-3dcenter.org/vbulletin/showpost.php?p=7924503&postcount=100.

[Gast]

Kann aber natürlich auch daran liegen, dass die Geometrielast sinkt.

Natürlich sinkt die Geometrielast, dass ist ja der Zweck von adaptiver Tesellation und dass damit der relative Abstand zwischen ATI und NV schrumpft ist auch logisch.

[Gast]

Beim GF100 ist es eben so, dass bisher die Hot Clock das 2-fache der Core Clock beträgt. Dies ist, bisherigen Gerüchten zufolge, auch bei der GTX 460 mit dem GF104 so. Darum spinnen wir das Spielchen einfach so weiter... :wink:



Die Frage ist, ob man bei GF100 mit overclocking das Verhältnis ändern kann oder nicht.

[Spasstiger]

Natürlich sinkt die Geometrielast, dass ist ja der Zweck von adaptiver Tesellation und dass damit der relative Abstand zwischen ATI und NV schrumpft ist auch logisch.
Allerdings steigt auch die arithmetische Last.
Man müsste mal einen Vergleich anstellen:
- GTX 480 gegen HD 5870 mit adaptiver Tessellation und hohem Tessellationsfaktor
- GTX 480 gegen HD 5870 mit statischer Tessellation aber nur mittlerem Tessellationsfaktor, so dass der Polycount gleich ist wie im ersten Benchmark

Wenn dann die HD 5870 im ersten Benchmark näher dran ist an der GTX 480 als im zweiten Benchmark, weiß man, dass die HD 5870 ihre höhere Shaderleistung auch für die bei der Tessellation beteiligten Shader-Stages vorteilhaft einsetzen kann.

[AwesomeSauce]

@Spasstiger
Bei "statischer" Tessellation (nicht adaptiv) sind die weit entfernten Dreiecke viel kleiner als bei adaptiver Tessellation, wo die Grösse der Dreiecke ungefähr gleich bleibt. Rein auf den Polycount kommt es meiner Meinung also auch nicht an, sondern auch auf deren Grösse. GF100 dürfte bei vielen kleinen Tris viel schneller sein...

[V2.0]

Schön, dass die Customdesigns dann wohl früh kommen werden. Aber hoffentlich taugt auch der Referenzkühler was.

[Gast]

Wenn dann die HD 5870 im ersten Benchmark näher dran ist an der GTX 480 als im zweiten Benchmark, weiß man, dass die HD 5870 ihre höhere Shaderleistung auch für die bei der Tessellation beteiligten Shader-Stages vorteilhaft einsetzen kann.

Nein, durch die adaptive Tessellation sind entfernte Polygone nicht mehr so klein, wodurch natürlich der Flaschenhals beim Rasterizing natürlich deutlich kleinere Auswirkungen hat.

[Gast]

Wie findet ihr das Design der GTX 460?

Dürfte da eine leisere Kühlung möglich sein? Größer als die Megalauten Radial-Lüfter der aktuellen G100-Serie ist er ja schonmal.

Aber immer noch 2x6-Pin Stromanschluss. Der Fermi scheint also selbst abgespeckt noch ein richtiger Stromschluckspecht zu sein.

-> http://www.hardwareluxx.de/index.php/news/hardware/grafikkarten/15764-erste-nvidia-geforce-gtx-460-gesichtet.html

[Dural]

eine 5830 oder 5850 hat auch zwei 6-Pin Stecker... scheinen hier einige zu vergessen :P

es gibt auch 130Watt Karten mit zwei 6-Pin Stecker, die Stecker sagen noch lange nichts aus!!!

[AwesomeSauce]

Wenn sich die Karte laut NVidia so gut takten lässt, ergibt es Sinn, eine etwas grosszügigere Stromversorgung zu spendieren. Heisst ja noch lange nicht, dass die vollständig ausgenutzt wird...

[Gast]

Okee. Danke, ShinyMcShine. :) Also gibt's, bis auf aktuelle Gewohnheit, keinen wirklichen Grund dafür.
Doch, es gibt einen. Fermi, zumindest GF100 setzt laut Nvidia nahezu nur noch auf die bekannten Caches, kaum noch oder gar keine Fifos. Da ist es natürlich sinnvoll, wenn die Clocks synchron laufen.

-carsten

[AwesomeSauce]

Hier stand ot...

[Coda]

Allerdings steigt auch die arithmetische Last.
Sehr vernachlässigbar. Die Hull-Stage wird ja nur einmal pro nicht-tesseliertes Primitive ausgeführt.

Der Domain-Shader ist der, der Leistung zieht.

[harzer_knaller]

Ah, Danke Carsten. Dann bringt zumindest beim GF100 (und dem GF104?) eine asynchrone Taktung beider Domänen keinerlei Vorteil, wenn ich das jetzt richtig verstehe. Was wiederum heißt, dass eine unabhängige Taktung beider Clocks nicht mehr nützlich is, oder?

Das finde ich ein wenig Schade, da das beim G92 immerhin ein wenig Leistungssteigerung brachte...

[|MatMan|]

Ich würde behaupten es ist ab Fermi gar nicht mehr möglich Core und Shader unabhängig zu takten - eben aus Synchronisierungsgründen (wie Carsten schon beschrieben hat). Hier hat man anscheinend Transistoren gespart und/oder die "Leistung" erhöht (z.B. Latenzen von den Fifos verringert?)...

Bei G8x/9x hatte ich mich ohnehin etwas gewundert, warum man ein unabhängiges Takten ermöglicht hat (da erste Generation der neuen Architektur). War das vom Design her nötig oder wollte man explizit diese Flexibilität weil man dachte man kommt mit der Zeit mit dem Shader-Takt so viel weiter hoch im Vergleich zum Core-Takt?

[Spasstiger]

eine 5830 oder 5850 hat auch zwei 6-Pin Stecker... scheinen hier einige zu vergessen :P
Die HD 5850 hat auch eine TDP von 170 Watt.

es gibt auch 130Watt Karten mit zwei 6-Pin Stecker, die Stecker sagen noch lange nichts aus!!!
Welche denn? Ich kenne erst in der 140-Watt-Klasse Karten mit zwei 6-Pin-Steckern. Aber vielleicht läufts ja bei der GTX 460 wie bei der GTX 480. Realverbrauch in Furmark 165 Watt, aber TDP von 130 Watt.

[Dural]

ja eben und die leistung der GTX460 dürfte 5830 + sein

wie so darf den eine GTX460 nur max 130Watt verbrauchen.......... :P

[Rampage 2]

Steht es eigentlich fest, dass es einen GF104 im Vollausbau geben wird? Also 384SPs, 64TMUs, 32ROPs und 256Bit SI?

R2

[mapel110]

Steht es eigentlich fest, dass es einen GF104 im Vollausbau geben wird? Also 384SPs, 64TMUs, 32ROPs und 256Bit SI?

R2
Laut Charlie eher nicht. Ansonsten spricht nichts dagegen, aber wohl nicht von Anfang an.

[Spasstiger]

Die GTX 460 256 Bit wird vermutlich von der Performance her knapp unter der HD 5850 liegen und vom realen Stromverbrauch her knapp unter der HD 5870.
Die GTX 465 und die HD 5830 werden dann als Schweinekarten stark an Attraktivität verlieren.

[Gast]

Die HD 5850 hat auch eine TDP von 170 Watt.

151W: http://www.forum-3dcenter.org/vbulletin/showthread.php?t=465762

Und mit 2x 6-Pin haben wir bisher nur die 256-Bit Karte gesehen.

[Rampage 2]

Laut Charlie eher nicht. Ansonsten spricht nichts dagegen, aber wohl nicht von Anfang an.

Was "spräche" denn dagegen? Wäre es für Nvidia profitabel einen Vollausbau-GF104 rauszubringen? Wenn ja, wann könnte man (ungefähr) mit einer Markteinführung rechnen?

R2

[Dural]

das problem beim vollen gf104 dürfte wohl eher sein das man zufest an der gtx470 dran wäre und somit kokurenz im eigenen haus hat und ich denke nv ist auf die gtx470 angewissen um die 448sp chips los zuwerden!

vieleicht werden wir den vollen gf104 erst mit gf100b sehen der eine stärkere "470" erlaubt zb. 480sp mit 650mhz und "480" mit 512sp @ 750mhz... oder so...

das problem wo sie den mit den ganzen 448sp gpu hingehen wäre dann für nv aber immer noch vorhanden...

nv könnte den vollen gf104 preislich natürlich nicht so aktrativ gestalten wie es die 470 jetzt ist...

dürfte eine komisch situation für NV sein, den so ein problem gab es glaub noch nie! ;)

wird spannend wie sie das lösen, vieleicht wird es drezeit auch keine volle gf104 version geben und die guten chips wandern auf die GTX490, wer weisch schon! obwohl ja schon länger eine 468 im gespräch ist...

[AnarchX]

448SPs mit Taktupgrade für eine 475 und 512SPs ohne Takterhöhung für eine 485, beide mit gesenkter TDP wären doch auch denkbar.
Bei der GTX 468 wäre es nicht verwunderlich, wenn es bei den 675/1350MHz GPU bleibt, dazu dann eben noch alle 384SPs und ein Speichertakt zwischen 900 und 1000MHz.

Wie dann aber alles konkret aussehen wird, hängt wohl auch nicht unerheblich von den finalen Spezifikationen von Southern Islands ab.

[Leonidas]

Schau mal auf 3DCenter - News vom 23.6. - nach. Die haben nur das Layout angepasst, aber das Registerfille immer noch in seiner Größe belassen...


Das Bild wurde nur von mir aus einem GF100-Bild bearbeitet. Ich wollte da nur 24+4 darstellen (was sich inzwischen als falsch erwiesen hat), insbesondere alles drumherum ist nach wie vor vakant. Ich kann nicht sagen, ob die Caches und Register alle gleich groß sind wie bei GF100.

[Rampage 2]

448SPs mit Taktupgrade für eine 475 und 512SPs ohne Takterhöhung für eine 485, beide mit gesenkter TDP wären doch auch denkbar.
Bei der GTX 468 wäre es nicht verwunderlich, wenn es bei den 675/1350MHz GPU bleibt, dazu dann eben noch alle 384SPs und ein Speichertakt zwischen 900 und 1000MHz.

Wie dann aber alles konkret aussehen wird, hängt wohl auch nicht unerheblich von den finalen Spezifikationen von Southern Islands ab.

675MHz dürfte bei 384SPs aber als "künstlich niedrig gehalten" betrachtet werden, oder? Mit Luftkühlung hat der Chip sicher OC-Freiraum bis 850/1700MHz...

Oder wie denkst du darüber?

R2

[deekey777]

Verstehe ich das richtig: Der GF104 ist der zweite Chip von Nvidia, wo die darauf basierenden Produkte nur mit teildeaktivierten GF104 auf den Markt kommen?

Nein, durch die adaptive Tessellation sind entfernte Polygone nicht mehr so klein, wodurch natürlich der Flaschenhals beim Rasterizing natürlich deutlich kleinere Auswirkungen hat.
Ist das Rasterizing wirklich ein Flaschenhals oder nur ein theoretischer?
Sehr vernachlässigbar. Die Hull-Stage wird ja nur einmal pro nicht-tesseliertes Primitive ausgeführt.

Der Domain-Shader ist der, der Leistung zieht.
Das erklärt aber nicht den Einbruch bei der HD5800 im Vergleich zur HD5700, es sei denn, dort limitiert immer die gleiche Stufe. Ideen?
(Ja, ich nerve)

[Gast]

Ist das Rasterizing wirklich ein Flaschenhals oder nur ein theoretischer?

Bei sehr kleinen Dreiecken ist es sogar ein sehr großer Flaschenhals, je größer die Dreiecke werden desto weniger.


Das erklärt aber nicht den Einbruch bei der HD5800 im Vergleich zur HD5700, es sei denn, dort limitiert immer die gleiche Stufe. Ideen?
(Ja, ich nerve)

Beide sind gleich stark beim Rastern, wenn das nun genug limitiert, kann die 5800 ihre Überlegenheit nach dem Rastern nicht oder nur mehr teilweise ausspielen.

[Gast]

Verstehe ich das richtig: Der GF104 ist der zweite Chip von Nvidia, wo die darauf basierenden Produkte nur mit teildeaktivierten GF104 auf den Markt kommen?



Genau, da der volle GF104 wohl "zu gut" für die momentante Marktsituation ist, man muss erstmal die GTX470 GPUs abverkaufen.

[AnarchX]

Mit >350mm² @ 40nm wird man wohl immer noch keine Yields auf hohem Niveau erwarten können.

[LovesuckZ]

Sagt wer?

[AnarchX]

Ausgehend von der Liefersituation von Cypress und der Preisstabilität kann man das wohl annehmen.
Und auch die 768MiB GTX 460 für $230 spricht noch für eine entsprechend hohe BOM.

[LovesuckZ]

Und was hat nVidia mit AMD zu tun?

[Expandable]

Zu den heutigen News:

Ein SM entspricht der ganzen Abbildung, was hier mit 48 vs 24 vs 32 gemeint ist, sind CUDA Cores (pro SM).

Was aus meiner Sicht noch gegen 24 spricht: Ein Warpscheduler schedult eine Instruktion für 16 CUDA Cores - das geht bei 24 nicht mehr. Bei 48 hingegen könnte man "einfach" einen 3. Scheduler und Instruction Dispatch Unit einbauen. Wobei ich das irgendwie schon seltsam finde alles. Sicher, dass Nvidia nicht wieder auf 16 CUDA Cores und 1 Warp Scheduler runtergeht?

[Coda]

Ist das Rasterizing wirklich ein Flaschenhals oder nur ein theoretischer?
Meinen Rechnungen nach muss das z.B. bei Shadow Maps durchaus ein Flaschenhals sein. Da kommen viele Dreiecke auf wenig Shaderinstructions. Ich muss endlich mal das schon ewig praktisch schon fertige Technlet dazu vollenden.
Selbst bei Heaven mit recht langen Shadern stallt Cypress ja schon 15% der Zeit durch den Rasterizer. Das ist viel.

Das erklärt aber nicht den Einbruch bei der HD5800 im Vergleich zur HD5700, es sei denn, dort limitiert immer die gleiche Stufe. Ideen?
(Ja, ich nerve)
Ich weiß es auch nicht genau, aber meiner Meinung nach ist das Frontend eben für das Breite Design allgemein zu schwachbrüstig.

Die 15% könnten bei Juniper schon gegen 0% gehen.

[AwesomeSauce]

Sicher, dass Nvidia nicht wieder auf 16 CUDA Cores und 1 Warp Scheduler runtergeht?
Pro SM? Wieviele TMUs pro SM? Bei 16 CCs / SM ergäbe das für die GTX460 ganze 21 SMs, das ist ganz einfach unrealistisch, wenn man die alte Konfiguration beibehält (u.a 1 PolymorphEngine / SM). Die 3*16 Konfig ergibt viel mehr Sinn...

[Gast]

Gab es von der Computex außer bei PCGH noch andere Seiten die von einer GTX490 auf Basis des GF104 gesprochen haben? Frage mich wie die "Quelle" auf 3GB RAM gekommen ist, würde ja darauf hindeuten das die Sparversion des GF104 mit 192Bit als Dualkarte kommt, keine andere kann ja sonst 3GB ansprechen.

[Coda]

Wobei ich das irgendwie schon seltsam finde alles.
Ich nicht, denn Fermi hat für den Gaming-Markt ein zu hohes ALU/Texureinheiten-Verhältnis.

Ein Vec16-SIMD halte ich für Quatsch. Dann gleich 32 und zwei Quad-TMUs. Das wäre effizienter.

[AwesomeSauce]

@Coda
Anscheinend stehen 4 GPCs für GF104 fest, also dürfte auch mit 4 Raster/Setups zu rechnen sein. Sollte es Nvidia bei einer GF100-Polymorph-Engine per SM belassen (ergo deren 8 bei GF104), fiele das Frontend des GF104 doch viel zu stark aus?! Das 4Raster/16PEs des GF100 schien doch ziemlich optimal...

[Gast]

Mit 64TMUs... was haben sie dann weggelassen, außer ROP/SI Einheiten und die DP-Single Cycle Fähigkeit.

[Coda]

Wahrscheinlich Cache, und vielleicht CUDA Compute Capability 2.0.

Da kann man schon einiges entschlanken. Ich vermute mal dass die drei SIMDs pro SM von GF104 ohne DP nicht viel mehr Platz einnehmer als die zwei von Fermi.

[Iruwen]

Werden solche Chips eigentlich grob entworfen und anhand von Simulationen entschieden wie genau das finale Design aussieht und dann hat man bei "echten" Spielen Glück oder Pech oder gibt es Samples mit verschiedenen Ansätzen und man nimmt dann den besten? Oder wie läuft so eine Entwicklung?

[Coda]

Simulationen. Ein 40nm-Tapeout kostet Millionen.

[Spasstiger]

Ich weiß von IBM, dass dort große Rechencluster als Logiksimulatoren eingesetzt werden, um das Verhalten eines Entwurfs zu simulieren. Vor ~5 Jahren konnte man dort eine CPU der Komplexität eines Pentium 4 mit ~50 Mio. Transistoren in Echtzeit simulieren (bei welchem virtuellen Takt weiß ich allerdings nicht).
Ich denke, dass auch bei AMD/ATI und Nvidia solche großangelegten Logiksimulatoren zum Einsatz kommen (oder man mietet irgendwo Rechenzeit).
Die Simulation einer CPU ist übrigens eine sehr gut parallelisierbare Aufgabe. Man hat sehr viele nebenläufige Prozesse.

[Gipsel]

Übrigens sieht der spekulierte GF104-SM aus den News immer noch sehr verquer aus. Die Registeranzahl stimmt wohl genauso wenig, wie die 6 SFUs. 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.

[Coda]

8 SFUs. Hm. Stimmt, ich hatte noch gar nicht beachtet, dass die ja an einem eigenen Port hängen bei Fermi und nicht an die SIMDs gekoppelt sind.

Die Issue-Rate wäre dann wohl drei. Meinst du es ist jede beliebige Kombination möglich?

Aber wirklich gute Analyse. Ich teile deine Einschätzungen.

[Gipsel]

Die Issue-Rate wäre dann wohl drei. Meinst du es ist jede beliebige Kombination möglich?
Mir fällt spontan kein Grund ein, warum das nicht möglich sein sollte. GF100 kann es doch auch (bis auf DP oder 64bit MULs, aber da müssen auch je 2 ALUs gepaart werden, dieser special case entfällt ja höchstwahrscheinlich bei GF104). Und da die Scheduler immer mit verschiedenen Warps arbeiten, gibt es auch keine Abhängigkeiten, die da was durcheinander bringen könnten.
Allgemein finde ich es aber schon erstaunlich, daß nvidia doch so recht große Änderungen macht.
Ich teile deine Einschätzungen.
Jetzt muß es bloß noch stimmen. Irgendwie finde ich es schon ein wenig komisch, daß es noch keine weiterführenden Informationen dazu gibt, immerhin sollen die Karten doch schon in wenigen Wochen zu kaufen sein.
Nicht das nachher noch Damien mit seiner Streichidee recht behält und nvidia sich die Anzahl der ALUs sozusagen schönrechnet. Aber zumindest wäre das wohl vom Designaufwand wohl niedriger anzusetzen, solange die SFUs im GF100 immer noch MULs können und die Möglichkeit nur mangels Issue-Ports nicht genutzt wird. Mit 2 Schedulern, 16 ALUs, 16 L/S, 4 SFUs (als 8 ALUs gezählt, da 16 flops/Takt möglich) und 4 TMUs würde mir persönlich das aber auch nicht wirklich gefallen. Was nvidia da mit dem L1/local memory machen würde (64kB sehen ein wenig nach Verschwendung aus), ist mir auch nicht ganz klar (bei der 48 ALU-Variante sollte das identisch zum GF100 bleiben). Vielleicht könnte das auf 32kB (Mindestanforderung von DX11 SM5) halbiert werden, allerdings wäre das unschön und nvidia müßte dann auf jeden Fall eine eingeschränkte ComputeCapability definieren, welches (außer dem fehlenden DP) auch das local memory kleiner als bei CC 2.0 definiert (48kB). Oder sie bringen dann doch irgendwie 48kB unter, keine Ahnung. Insofern wäre so ein 48 ALU-SM zwar die aufwendigere (vom Design) Lösung, aber auch die bessere.

[Coda]

Wie gesagt, ich glaube eh dass GF104 nur Compute Capatibility 1.x definiert bekommt, da kein DP-Support. Und ich vermute auch, dass der globale Adressraum rausfällt.

Wenn das alles so stimmt hat NVIDIA sich schon im Vorfeld viel Gedanken gemacht und GF100 ist wirklich mehr als wir dachten für die Compute-Strategie ausgelegt worden.

Im Prinzip kann man eine Architektur ja auch schön in Verilog skalierbar und konfigurierbar auslegen. Man muss es halt beim Design berücksichtigen.

[BlackBirdSR]

Wenn das alles so stimmt hat NVIDIA sich schon im Vorfeld viel Gedanken gemacht und GF100 ist wirklich mehr als wir dachten für die Compute-Strategie ausgelegt worden.



Vorsicht, sonst kommt gleich wieder jemand und grräbt Charlies Posting über Fermi als LRB-Only Konkurrent in Form einer Add-In-Karte aus ;)

Aber wäre schön zu sehen, wenn Nvidia für den Consumer-Bereich ohne prof. Anwendungsbereiche einiges an Arbeit reinsteckt um das Angebot attraktiver gestalten zu können.

[Byteschlumpf]

Es wird ja gemunkelt, dass Fermi im Grunde nie als Gamer-Karte gedacht war! ;)
nVidia scheint IMO den Konsumermarkt "fast" vor lauter lukrativer Profihardware vergessen zu haben.

[=Floi=]

beides geht hald schlecht mit einer neuen generation. (der g100 ist schon ein sehr sehr wegweisendes design und hat wirklich viele neuerungen und features) imho werden die spieler schon wieder zum zuge kommen, wenn der refresh ansteht. eigentlich wäre ja auch der G100 ein guter gamer chip geworden, wenn die probleme bei tsmc nicht gewesen wären.

[Gast]

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.
Je nachdem, ob GF104 wirklich als "Fermi, Gaming Edition" (FGE) ausgelegt ist oder aber schon sowas wie Fermi 1.2 sein soll, würde ich meine Triple-Warp-Scheduler, die ich jetzt mal so stehen lasse, aber anders einsetzen.

Wenn es FGE werden sollte, dann würde ich mal - auch als Designträger für die Zukunft - versuchen, meine SFUs so umzubauen, dass sie Atis T-Units ähneln, dafür aber die L/S weglassen, die eh fast nur für Compute und Atomics gebraucht werden. Das dürfte für Gaming gegenüber den obigen Änderungen eher nachrangig sein.

Leider habe ich überhaupt keine Ahnung, wie "fett" die SFUs derzeit im Vergleich zu einem ALU-Block sind, ob sich der Umbau also lohnen würde, ob's fast kein Unterschied ist, die noch mitzuschleppen.

Der Cache pro SM kann bleiben, denn 48 kiB durch drei kommt pro Warp-Gondel auf's selbe heraus wie 32 durch zwei, dazu haben wir 16 kiByte Scratchpad, die sich aber per Definition nur auf die Performance auswirken dürfen, also die Compute Caps und das Programmiermodell nicht ändern.

ECC kann auch raus, wenn's FGE wird.

-carsten

[Gipsel]

Wenn es FGE werden sollte, dann würde ich mal - auch als Designträger für die Zukunft - versuchen, meine SFUs so umzubauen, dass sie Atis T-Units ähneln, dafür aber die L/S weglassen, die eh fast nur für Compute und Atomics gebraucht werden. Das dürfte für Gaming gegenüber den obigen Änderungen eher nachrangig sein.

Leider habe ich überhaupt keine Ahnung, wie "fett" die SFUs derzeit im Vergleich zu einem ALU-Block sind, ob sich der Umbau also lohnen würde, ob's fast kein Unterschied ist, die noch mitzuschleppen.
L/S wegzulassen geht nicht, da jeder Speicherzugriff darüber läuft. Auch Texturzugriffe werden wohl im Moment darüber abgewickelt, das zu ändern würde weitere Umbauten nötig machen (Tex-Instruktionen müßten direkt von den Schedulern zu den Tex-Einheiten abgesetzt werden können, man benötigt einn zusätzlichen Pfad von den TMUs zu den Registerfiles).

Die SFUs auszubauen, paßt übrigen besser in Damiens 16/24 ALU Version. Da schrieb ich ja schon, daß es nicht sehr teuer wäre, den SFUs noch ein paar Adder zu spendieren, so daß sie zumindest MADD können (und dann die 24 ALU-Zählung für 16 ALUs und 4 SFUs [2 MADD pro SFU pro Takt] vielleicht sogar gerechtfertig wäre). Was dagegen spricht, ist eigentlich nur der größere Verwaltungsaufwand der dann erforderlichen doppelten Anzahl der SMs und das 16 L/S für 16/24 ALUs ein wenig nach Overkill aussieht, aber vielleicht reduzieren sie ja auf 8 L/S (was für 4 GF100 TMUs mit ihrem verbessertem 4 offset_gather4 genau ausreichen würde).

Ein Vorteil ATIs bei der Komplexität der Shader (und Latenz der Operationen) ist, daß die Registerfiles für alle Einheiten lokal sind (jede VLIW-Einheit hat ein eigenes Registerfile mit 1024x128bit Einträgen, die Einheit greift nur auf dieses eine Registerfile zu). Bei nvidia gibt es ein umfängliches Operand Collector Netzwerk, da es keine ganz so enge Kopplung zwischen Registern und darauf zugreifenden Einheiten gibt. Bei GF100 können die Operanden für jede ALU aus (mindestens) 2 verschiedenen Registerfiles kommen, bei den SFUs sogar aus 8 verschiedenen (dies trägt maßgeblich zur höheren Latenz der SFU-Operationen bei, auch schon bei G80 und GT200, da benötigt ein MUL aus den SFUs ja auch 50% länger als aus den ALUs).
Im Prinzip ist das alles unschön für die Scheduler, ist es doch aufwendiger, Instruktionen unterschiedlicher Latenz zu verwalten, als wenn alle die gleiche Anzahl von Takten benötigen würden (wie bei ATI).

Ohne VLIW-Bundles kann nv eigentlich wirklich nur mit einer engeren Kopplung der ALUs und SFUs eine ähnliche Richtung einschlagen (mit dem 48 ALU-SM ist die Anbindung der SFUs sogar noch etwas komplizierter als bei GF100), also mit festen Blöcken aus 16 ALUs und 4 SFUs (analog den G80/GT200 SMs mit 8 ALUs und 2 SFUs). Das hieße, das Sharing der SFUs durch verschiedene Scheduler wieder abzuschaffen. Das wäre dann wohl ein Hybrid aus GT212 und GF100.

Der Cache pro SM kann bleiben, denn 48 kiB durch drei kommt pro Warp-Gondel auf's selbe heraus wie 32 durch zwei, dazu haben wir 16 kiByte Scratchpad, die sich aber per Definition nur auf die Performance auswirken dürfen, also die Compute Caps und das Programmiermodell nicht ändern.
So funktioniert die Rechnung nicht. Wie viele "Warp-Gondeln" in einem SM hängen, hat genau 0 Auswirkungen auf das Programmiermodell. CC2.0 definiert 48kB local memory pro SM. Wieviel man davon in einer Workgroup benutzt (bei nv heißt das glaube ich Threadblock), bestimmt nur, wie viele Threadblocks (die aus mehreren Warps bestehen können) maximal gleichzeitig auf dem SM laufen können, die maximal nutzbare Menge an local memory pro Threadblock ist immer 48kB. Nutz man das aus, kann nur noch ein einziger Threadblock auf einem SM laufen, was natürlich total auf die Performance durchschlägt.

Prinzipiell erfüllt man also mit den 64kB GP-L1/local memory die CC2.0 Anforderungen unabhängig von der Anzahl der ALUs im SM. Mit mehr ALUs bricht bloß die Performance früher ein, wenn man die Menge des genutzten local memories steigert. Insofern wäre die 48 ALU-Variante für GPGPU etwas schlechter geeignet, ohne die nominellen Anforderungen für 2.0 (außer DP) zu verletzen.

Bei der 16/24 ALU-Variante müßten allerdings ebenfalls mindestens 48kB local memory verbaut werden, was es dann im Endeffekt sogar besser für GPGPU machen würde (mit nur 8 L/S-Einheiten, würde man aber die Geschwindigkeit wieder etwas einbremsen).

[Gast]

Bin etwas knapp, sorry.
L/S wegzulassen geht nicht, da jeder Speicherzugriff darüber läuft. Auch Texturzugriffe werden wohl im Moment darüber abgewickelt, das zu ändern würde weitere Umbauten nötig machen (Tex-Instruktionen müßten direkt von den Schedulern zu den Tex-Einheiten abgesetzt werden können, man benötigt einn zusätzlichen Pfad von den TMUs zu den Registerfiles).
Dachte ich auch, Nvidia sagte aber was anderes.

-carsten

[LovesuckZ]

Es wird ja gemunkelt, dass Fermi im Grunde nie als Gamer-Karte gedacht war! ;)
nVidia scheint IMO den Konsumermarkt "fast" vor lauter lukrativer Profihardware vergessen zu haben.

Deswegen ist man unter Tessellation auch 8x so schnell als die Konkurrenz, gell?
GF100 ist weiterhin ein Gamerchip.
Es ist erstaunlich, dass die Konkurrenz viele dieser "Profihardwareigenschaften" schon weitaus früher hatte, man aber nie davon sprach, dass es sich nicht um Spielekarten handeln würde.
Anscheinend müssen sich Lügen nur oft genug wiederholen, um als Wahrheit angenommen zu werden.

[Gast]

Bloß ist das leider ein sehr theoretischer Vorteil. Fermi wird oft genug durch seine geringe Texturfüllrate limitiert. Bestenfalls gibt es Tessellation mit einem sehr geringen Performance-Hit - solange die Hull- und Domainshader mit den Berechnungen hinterherkommen. Kein AMDler reitet so auf der hohen Rechenleistung des R870 rum wie du auf der Tessellationleistung von Fermi - die im Großen und Ganzen in der breiten Palette von Spielen, wie wir sie heute haben, ziemlich gar nichts bringt.

[Coda]

L/S wegzulassen geht nicht, da jeder Speicherzugriff darüber läuft. Auch Texturzugriffe werden wohl im Moment darüber abgewickelt, das zu ändern würde weitere Umbauten nötig machen (Tex-Instruktionen müßten direkt von den Schedulern zu den Tex-Einheiten abgesetzt werden können, man benötigt einn zusätzlichen Pfad von den TMUs zu den Registerfiles).
Das will man gar nicht haben, denn Tex und Alu sind unterschiedliche Threads.

[OgrEGT]

Deswegen ist man unter Tessellation auch 8x so schnell als die Konkurrenz, gell?
GF100 ist weiterhin ein Gamerchip.
Es ist erstaunlich, dass die Konkurrenz viele dieser "Profihardwareigenschaften" schon weitaus früher hatte, man aber nie davon sprach, dass es sich nicht um Spielekarten handeln würde.
Anscheinend müssen sich Lügen nur oft genug wiederholen, um als Wahrheit angenommen zu werden.

Als ob nur die Tesselation Performance definieren würde, ob es sich um eine Spielerkarte handelt oder nicht. DX10(.1) Spielerkarten gab es auch schon vor DX11 und Tesselation.

Wir haben es alle gerafft, Fermi ist der Tess-Overruler. Punkt für NV.

Zum Glück für uns alle bleibt der Fortschritt sowohl bei NV als auch bei ATI nicht stehen.

[Bucklew]

Es wird ja gemunkelt, dass Fermi im Grunde nie als Gamer-Karte gedacht war! ;)
nVidia scheint IMO den Konsumermarkt "fast" vor lauter lukrativer Profihardware vergessen zu haben.
Quatsch. Es ist der erste GPU-Chip, der die GPGPU-Funktionen nicht nur als Anhängsel enthält, sondern als integrativen Bestandteil. Daher sind viel mehr Transistoren/Funktionen enthalten, die man bei einem Gamerchip eigentlich nicht brauchen würde. Es ist eben ein Chip-Zwitter aus GPGPU und Gaming. Vorher waren es Gaming-Chips, die zum GPGPU missbraucht wurden.

[Gast]

Das will man gar nicht haben, denn Tex und Alu sind unterschiedliche Threads.
Nö, das sind Aufrufe innerhalb von Shaderprogrammen.

[Coda]

Nö, das sind Aufrufe innerhalb von Shaderprogrammen.
Das hast du fein erkannt. Innerhalb des Chips laufen Texturfetches trotzdem als nebenläufige Threads.

[Gast]

Nö, für eine Anweisung wird garantiert kein eigener Thread aufgemacht - wie kommst du auf sowas?

Der Thread, innerhalb dessen der Tex-Fetch aufgerufen wird, wird geparkt, bis das Ergebnis vorliegt und dann mit diesem Wert weitergerechnet werden kann.

[Coda]

Die Texture-Fetches sind auch Threads die von einem separaten Scheduler an die TMU gegeben werden. Keine Rechenthreads auf den ALUs natürlich.

The threaded nature extends to data fetch and filtering too, the chip running fetch threads asynchronously from threads running on the clusters, allowing the hardware to hide fetch and filter latency as much as possible, very much in order to keep the chip working as close to maximum efficiency as possible.

Das war schon bei ATIs R5xx so.

[Gast]

Die Texture-Fetches sind auch Threads die von einem separaten Scheduler an die TMU gegeben werden. Keine Rechenthreads auf den ALUs natürlich.



Das war schon bei ATIs R5xx so.
Das interpretier ich etwas anders:
Fetch-Threads -> Threads, bei denen gerade ein Fetch als nächstes ansteht.
Threads running on the cluster -> Threads, die als nächste eine ALU-Instruktion haben.

Die Threads kommen doch fertig in Maschinensprache vom Treiber. Woher soll die dumme GPU wissen, welcher "Tex-Thread" an welcher Stelle in welche "ALU-Thread" reingehört? Dazu bräuchtest du dann Rückmeldung an den Treiber, der aus diesen Infos ("Hey, mein Tex-Thread ist fertig") dann neue Threads erstellt, bei denen die dann bekannten Werte übergeben werden.

[Coda]

Ich sagte doch dass die Threads intern auf der GPU erzeugt werden und keine Threads mit normalen ALU-Instructions sind. Die Texture-Fetches laufen völlig nebenläufig und sind natürlich anderer Natur.

Natürlich informieren der Tex-Scheduler entsprechend den SIMD-Scheduler, dass die Texturdaten für den entsprechenden Thread im Registerfile abgelegt wurden. Dass das ganze nicht so trivial ist sollte klar sein.

Nenn es von mir aus "anstehende Texturfetches" anstatt Texture-Threads. Ist mir egal. Das ändert nichts daran, dass man nicht vom SIMD-Scheduler die TMUs ansteuern kann ohne die Nebenläufigkeit und damit viel Performance aufzugeben.

[Gast]

Entweder wir reden gerade massiv aneinander vorbei, oder einer von uns beiden hat einen ziemlichen Denkfehler oder wir meinen mit "Threads" etwas völlig anderes.

[Coda]

Vermutlich letzteres. Texture-Threads sind keine Rechenthreads die WARP-Instructions enthalten, sondern nur solche, die lokal in einem SM auf den TMUs ausgeführt werden.

Wie gesagt, nenn es von mir aus auch irgendwie anders, aber ich habe diese Terminologie jetzt schon öfters gelesen.

Spielt aber auch alles überhaupt keine Rolle für das Thema, wie ich auch schon gesagt habe. Die TMUs können nicht direkt von den WARP-Schedulern angesteuert werden.

[Gipsel]

Dachte ich auch, Nvidia sagte aber was anderes.
Wo sagt nvidia was genau? Häufig beschreiben die einige Sachen in einer Weise, daß man den Eindruck haben muß, daß nv will, daß man das mißversteht ;)

@Coda:
Nun, Fetches gehören schon zu einem Thread und stellen keinen eigenen "Fetch Thread" dar. Immerhin muß zuerst die Adresse für den Zugriff in den ALUs bestimmt und schließlich das Ergebnis wieder zurück an die ALUs (bzw. die Register) geliefert werden.

Das Zitat, welches Du anbringst, beschreibt mit "asynchron" nur, daß ein Texturefetch den SM und auch den Warp nicht blockiert, sprich, daß andere Instruktionen (des gleichen Threads) während des Fetches weiter ausgeführt werden können, natürlich nur, solange sie nicht vom Wert des Fetches abhängen. Ansonsten macht der SM wie der Gast schon schrieb mit einem anderen Warp weiter.

Außerdem kann man sich überlegen, was die Integration der TMUs in die SMs eigentlich bedeutet. Vorher wurden die TMUs in einem TPC von mehreren SMs gemeinsam genutzt. Hier war wirklich eine übergeordnete Struktur notwendig, die die Zugriffe von mehreren SMs organsiert und dann an die TMUs schickt. Dies ist bei Fermi allerdings anders (und nv betonte die Umstellung der internen Architektur auf eine streng orthogonalisierte Struktur mit getrennten Load und Execute, anders als bei G80/GT200). Warum sollte man die schon vorhandene Infrastruktur zum Schreiben von aus Local/Global Memory gelesenen Werten in die Register für die TMUs nochmal duplizieren und damit eine zusätzliche Synchronisation oder gar einen zusätzlichen Port erforderlich machen?

Auch ATI hat die Organisation der TMUs ab der RV7xx-Generation umgestellt und sie in die SIMDs integriert. Der gleiche Scheduler schickt dort definitiv beides, ALU- und TEX-Clauses, auf die Reise und auch dort laufen TEX-Instruktionen asynchron zu ALU- (oder auch Controlflow-) Instruktionen. Etwas anderes wäre aus meiner Sicht bei der Organisation auch ziemlich widersinnig.
Vorher (bis RV6xx) gab es einen eigenen "TMU-Cluster", der vom globalen Scheduler (UTDP) ähnlich wie die SIMDs selber mit den TEX-Instruktionen versorgt wurde, dort paßt also die von Dir gegebene Beschreibung ganz gut.

[Gipsel]

Texture-Threads sind keine Rechenthreads die WARP-Instructions enthalten
Texture-Fetches werden auch immer mindestens mit einer Granularität eines Halbwarps ausgeführt, also mindestens 16 auf einmal (davon können aber natürlich mit Predicates beliebig viele verworfen werden), die sind genau so in Warps organisiert, wie ALU-Instruktionen. Und wenn Du mal den CUDA-Disassembler anschmeißt, wirst Du auch sehen, daß im binären Instruktionsstrom (der auf der GPU nicht mehr geändert wird!), die TEX-Instruktionen immer schön neben ALU-Instruktionen stehen, da ist gar nichts getrennt.

[Fetter Fettsack]

Wie wird es eigentlich mit dem Strombedarf aussehen? Im gleichen Verhältnis wie beim GF100 (also GF100 100% Fläche --> 100% Stromverbrauch, GF104 50% Fläche --> 50% Verbrauch) oder dank der "Entschlackung" merkbar weniger? Wenn letzteres der Fall ist, wäre man in der Lage der RV8XX Architektur in diesen Belangen Konkurrenz zu machen?

[Coda]

Texture-Fetches werden auch immer mindestens mit einer Granularität eines Halbwarps ausgeführt, also mindestens 16 auf einmal (davon können aber natürlich mit Predicates beliebig viele verworfen werden), die sind genau so in Warps organisiert, wie ALU-Instruktionen. Und wenn Du mal den CUDA-Disassembler anschmeißt, wirst Du auch sehen, daß im binären Instruktionsstrom (der auf der GPU nicht mehr geändert wird!), die TEX-Instruktionen immer schön neben ALU-Instruktionen stehen, da ist gar nichts getrennt.
Natürlich sind sie im selben Instruktionsstrom. Das ist mir schon klar. Die Tex-Instructions werden aber nebenläufig(er) ausgeführt, denn wie du schon sagst werden solange das Tex läuft schon wieder andere WARPs ausgeführt.

Dass das der WARP-Scheduler macht kann ich mir nicht vorstellen. Tex-Instructions haben ja Latenzen von potentiell mehreren 100 Takten. Das muss andere Logik sein die das verwaltet. Sprich eine Tex-Instructions bringt einen Texture-Fetch-"Thread" (jaja) auf den Weg, der dann auf dem Scheduler der lokalen TMUs ausgeführt wird - und dann hoffentlich fertig ist bis der WARP wieder an der Reihe ist.

[Gast]

Wo sagt nvidia was genau? Häufig beschreiben die einige Sachen in einer Weise, daß man den Eindruck haben muß, daß nv will, daß man das mißversteht ;)

Ich habe schon das ein oder ander Mal PR gefiltert, danke. :) Ich suche den Wortlaut morgen mal raus, wenn ich wieder Zugriff auf meine Mails habe.

-carsten