NV50 / G80?

[reunion]

Gast[/POST]']Der Gast oben wollte sich ja auch eine GT kaufen und keine GTX.

Achso, das habe ich nicht gesehen.

[Fetza]

'Winter[Raven]'[/POST]']Du legst natürlich alles so aus wie es dir passt, gelle? :| :mad: :P

glaube, es ging ihn mehr darum aufzuzeigen, das es wohl auch genug user gibt, die den g70 eben doch etwas entäuschend fanden. Da reiner die-shrink ohne die vorher groß überall herbeigeredeten zusätzliche 2quads pixelpipes usw.

greetz

Fetza

[Gast]

Fetza[/POST]']Da reiner die-shrink ohne die vorher groß überall herbeigeredeten zusätzliche 2quads pixelpipes usw.Tja, das kommt halt dabei raus, wenn man alles glaubt, was man im Internet so liest. Wie war das nochmal mit R520? Fast alle Seiten und sogar Zeitschriften haben es als Tatsache hingestellt, dass der R520 32 Pipelines hat. Am schlimmsten waren die Fanboys hier im Forum, die bis zur letzten Minute steif und fest behauptet haben, dass R520 8 Quads hat. Was letztendlich bei rausgekommen ist, wissen wir ja. Genauso verhält es sich auch mit G71. Nur weil alle von 8 Quads @ 750 MHz gelabert haben, muss das noch lange nicht stimmen.

[Fetza]

Gast[/POST]']Tja, das kommt halt dabei raus, wenn man alles glaubt, was man im Internet so liest. Wie war das nochmal mit R520? Fast alle Seiten und sogar Zeitschriften haben es als Tatsache hingestellt, dass der R520 32 Pipelines hat. Am schlimmsten waren die Fanboys hier im Forum, die bis zur letzten Minute steif und fest behauptet haben, dass R520 8 Quads hat. Was letztendlich bei rausgekommen ist, wissen wir ja. Genauso verhält es sich auch mit G71. Nur weil alle von 8 Quads @ 750 MHz gelabert haben, muss das noch lange nicht stimmen.

genau, nur war der r520 dann doch wenigstens ne neue architektur, beim g71 hingegeben wurde fast garnichts geändert. Und wenn man sich die zeit zwischen g70 und g71 anschaut finde ich, da hätte mehr passieren müssen.

Aber das ganze ist sowieso offtopic, von daher :)

[TheGamer]

SOrry hab mir den Tread nicht ganz durchgelesen bzw. nur ueberflogen. Wann kommt den nun der G80 oder eben die naechste Nvidia Karte der neuen Generation?

[Gast]

TheGamer[/POST]']SOrry hab mir den Tread nicht ganz durchgelesen bzw. nur ueberflogen. Wann kommt den nun der G80 oder eben die naechste Nvidia Karte der neuen Generation?

Das weiß noch keiner ;D

[Ailuros]

Zuerst kommt die *gaehn* 7950GX2 und dann sehen wir weiter.

[The_Invisible]

Paul Brain[/POST]']Sicher?
http://www.forum-3dcenter.org/vbulletin/showthread.php?t=298043

trotzdem kann der chip nix dafür wenns was anderes vermurksen.. die aussage passt schon (ist ja nur auf den chip bezogen)

mfg

[The_Invisible]

Ailuros[/POST]']Zuerst kommt die *gaehn* 7950GX2 und dann sehen wir weiter.

zu dem preis (http://www.pctweaker.de/product_info.php?info=p2530_POINTofVIEW-GF-7950GX2-1024MB-Retail.html) ist die karte alles andere als "gähn" ;)

mfg

[TheGamer]

Das ist krass jo, wie bekommt man diesen Preis fuer 2 Grafikkarten zusammen?

[Der Türke]

hallo,

will kein extra thread deswegen eröffnen...

AA ist ja "abhängig" von der speicherbrandbreite...d.h je höher desto mehr fps...

daher meine frage: gibt es überhaubt eine "grenze" (z.B 1500mhz GDDR4) wo z.B 4xAA "for free" realisierbar ist? oder wird es immer ne begrenzung geben?

und wie sieht es mit AF aus? ist sie von irgendwas abhängig? (vielleicht pipelines?...), sodass auch z.B 8xAF irgenwann mal ab eine bestimmte grenze "for free" ist?

wie ich drauf komme: früher war der 32-Bit Modus sehr performance raubend im gegensatz zum 16-Bit Modus. Heutzutage ist 32-Bit "for free"...

mfg

[Neomi]

FSAA und AF sind nur dann "gratis", wenn selbst bei deren Einsatz die Grafikkarte nicht limitiert, da z.B. die CPU den Flaschenhals darstellt. In grafiklimitierten Szenen werden diese Features nie gratis sein.

[StefanV]

4Free wirds so schnell nicht sein, gleiches bei AF, zumindest auf 'normalen' Renderern.

Das 32bit '4 Free' ist, liegt einfach daran, das man die Grafikchips darauf optimierte, andersrum: Die Bandbreitenschonenden Maßnahmen greifen (teilweise) nicht unter 16bit...
Wobei der Unterschied 16 <-> 32bit auch nur auf pre GF3-nVidia Karten so derb war, auf ATi und MGA HW wars bei weitem nicht so schlimm...

[Ailuros]

The_Invisible[/POST]']zu dem preis (http://www.pctweaker.de/product_info.php?info=p2530_POINTofVIEW-GF-7950GX2-1024MB-Retail.html) ist die karte alles andere als "gähn" ;)

mfg

Zweiter Ansatz und refresh des refresh vom refresh..... :|

[=Floi=]

also gegen einen weiteren refresh des G71 hätte ich garnichs
wenn er dann mit den 32 pipes kommen würde, wäre ich nicht wirklich enttäuscht

zumindest die aktuelle architektur von NV ist schön modular aufgebaut und ddamit ist NV gut im vorteil

ich rede von der normalen 7900GT/GTX und nicht von dem ding
ich will das ganze auf einem chip und nicht zusammengefrickelt
SLI ist gut und schön aber SO nicht

[Ailuros]

=Floi=[/POST]']also gegen einen weiteren refresh des G71 hätte ich garnichs
wenn er dann mit den 32 pipes kommen würde, wäre ich nicht wirklich enttäuscht

zumindest die aktuelle architektur von NV ist schön modular aufgebaut und ddamit ist NV gut im vorteil

Es sind schon 48 "pipes" auf der GX2, obwohl man keine 100% Leistungsteigerung aus dem Ding im Vergleich zu single GPU schiessen kann.

Rein technisch gesehen ist die ganze Geschichte langweilig geworden; wir kauen auf dem Zeug schon seit 2004 rum.

[Gast]

=Floi=[/POST]']also gegen einen weiteren refresh des G71 hätte ich garnichsWas soll man denn so kurz vor Vista/D3D10 bitte mit noch einem weiteren D3D9-Chip? Überflüssig wie ein Kropf und absolute Geldverschwendung sowohl in der Entwicklung als auch für diejenigen, die dumm genug wären, jetzt noch in sehr bald veraltete Technologie zu investieren. Einen R300 sollten sie ziehen, man muss doch nicht auf das jeweilige D3D warten um die passende Hardware rauszubringen. OK, die "Ich behalte keine Graka länger als ein halbes Jahr"-Fraktion hätte was von noch einem Refresh, für alle anderen wäre es Schwachsinn.

[Winter[Raven]]

Ailuros[/POST]']Es sind schon 48 "pipes" auf der GX2, obwohl man keine 100% Leistungsteigerung aus dem Ding im Vergleich zu single GPU schiessen kann.

Rein technisch gesehen ist die ganze Geschichte langweilig geworden; wir kauen auf dem Zeug schon seit 2004 rum.

^_^

Naja, warum auch nicht? ATI servierte uns Jahrelang die selbe Technik und verkaufte diese auch erfolgreich ... in dem Sinne "so what?" Nvidia kann ruhig bis zum G80 das Spielchen weiterspielen.

[=Floi=]

wenn wir ehrlich sind dann kann man den ersten DX10 chip sowieso nicht gebrauchen
in dx9 sicherlich sauschnell aber bei DX10 braucht es dann min 1 generation damit alles anständig läuft

Vista ist (leider) noch weit entfernt und da passt ein refresh schon noch in den zeitplan zumal die ersten spiele auch noch ne weile brauchen
mir reicht DX9 noch ne weile

[Gast]

So wie der erste D3D9-Chip auch nur für D3D8 zu gebrauchen war :confused:
Wer zuerst mit D3D10-Hardware rauskommt wird aller Wahrscheinlichkeit nach wieder den Standard setzen und auf lange Sicht die bessere Wahl sein, nicht zwangsläufig aufgrund der Fähigkeiten der Hardware sondern vielmehr der höheren Erfahrung der Entwickler wegen. Ich hätte R600/G80 lieber gestern als heute auf den Preislisten, das Warten und Spekulieren wird langsam langweilig ohne neue Infos.

[Paul Brain]

"DirectX 10 GPUs to Consume up to 300W"

http://www.anandtech.com/tradeshows/showdoc.aspx?i=2770

[X-Post im R600-Thread] (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=4404505#post4404505)

[Coda]

Neomi[/POST]']FSAA und AF sind nur dann "gratis", wenn selbst bei deren Einsatz die Grafikkarte nicht limitiert, da z.B. die CPU den Flaschenhals darstellt. In grafiklimitierten Szenen werden diese Features nie gratis sein.
Freies MSAA geht aber, wenn die ROPs alle Samples in einem Takt rausschreiben können und die Bandbreite immer reicht. Auch 16xAF ist theoretisch mit entsprechenden TMUs in einem Takt möglich, aber dann eben auch nur wenn man die Bandbreite hat.

[Neomi]

Coda[/POST]']Freies MSAA geht aber, wenn die ROPs alle Samples in einem Takt rausschreiben können und die Bandbreite immer reicht. Auch 16xAF ist theoretisch mit entsprechenden TMUs in einem Takt möglich, aber dann eben auch nur wenn man die Bandbreite hat.

Klar, wenn das nicht limitiert dann kann man das so sehen. Als "generell gratis" (und darauf zielte die Frage ja ab) zähle ich aber nur Features, die entkoppelte Ressourcen nutzen. Also solche, die bei stärkerem Einsatz weder langsamer werden noch andere Sachen verlangsamen und auch keine Ressourcen verwenden, die ansonsten von irgendwas anderem verwendet werden könnten.

Beispiel:
1x AF, 1x FSAA -> 60 fps (CPU-limitiert)
1x AF, 4x FSAA -> 60 fps (CPU-limitiert)
8x AF, 1x FSAA -> 60 fps (CPU-limitiert)
8x AF, 4x FSAA -> 50 fps

In dem Fall sehen zwar AF und FSAA jeweils aus, als wären sie gratis, aber sie sind es offenbar nicht. Immerhin kostet jedes dieser "Gratisfeatures" die Möglichkeit, das jeweils andere auch noch ohne Geschwindigkeitsverlust hinzuzuschalten. Klingt zwar jetzt kleinkariert, aber es ging ja genau darum, ob es irgendwann generell gratis ist.

[Ailuros]

Coda[/POST]']Freies MSAA geht aber, wenn die ROPs alle Samples in einem Takt rausschreiben können und die Bandbreite immer reicht. Auch 16xAF ist theoretisch mit entsprechenden TMUs in einem Takt möglich, aber dann eben auch nur wenn man die Bandbreite hat.

Rein theoretisch wohl schon; nur bezweifle ich dass es wirtschaftlich waere (ueberhaupt momentan) so viele Transistoren in die Richtung zu investieren. Und die Bandbreite haengt ja auch von dem jeweiligen verfuegbaren Speicher ab.

Xenos kann theoretisch "freies MSAA" aber auch nur unter Bedingungen und so "frei" duerfte es nun auch wieder nicht sein wenn man das tiling berechnet.

[aths]

'Winter[Raven]'[/POST]']^_^

Naja, warum auch nicht? ATI servierte uns Jahrelang die selbe Technik und verkaufte diese auch erfolgreich ... in dem Sinne "so what?" Nvidia kann ruhig bis zum G80 das Spielchen weiterspielen."Die haben ja auch ..." ist keine gute Argumentation.


=Floi=[/POST]']wenn wir ehrlich sind dann kann man den ersten DX10 chip sowieso nicht gebrauchen
in dx9 sicherlich sauschnell aber bei DX10 braucht es dann min 1 generation damit alles anständig läuft Die erste DX9-Generation war für die erste DX9-Spielwelle ziemlich gut zu gebrauchen.

[up¦²]

All we could confirm at this time is that the chip will be DirectX 10 compliant of course but it won't have the full implementation of Shader Model 4.0. It won't do the unified Shader but it will be Vista ready. Most of the chips out today are Vista ready at least the high end ones.
http://theinquirer.net/?article=32385

Vielleicht hat Nvidia einfach gelernt aus dem T&L-Flop damals :tongue:
DX9 lebt wohl sehr viel länger als mancher erwartet ...
Vista als "Game-OS" muß sich ja sowieso erstmal durchsetzen und vor allem überzeugen.

[Gast]

but it will be Vista ready

ja das is ne billige dx9 karte auch :D

[Gast]

up¦²[/POST]']http://theinquirer.net/?article=32385

Vielleicht hat Nvidia einfach gelernt aus dem T&L-Flop damals :tongue:
DX9 lebt wohl sehr viel länger als mancher erwartet ...
Vista als "Game-OS" muß sich ja sowieso erstmal durchsetzen und vor allem überzeugen.
Ist Blödsinn. Eine Karte die D3D10 (es gibt immer noch kein DX10) unterstützt muss SM 4.0 haben - und zwar vollständig.

Inq hat mal wieder was mit unified shadern und der API durcheinander gebracht - wie üblich.

[Hvoralek]

Es wäre schon schön, wenn sich die Inquirer- Redakteure wenigstens mal untereinander einig wären, was sie schreiben wollen.

Erstes G80-Tape- Out ungewiss [Fudo, Juni] (http://www.the-inquirer.net/?article=32385)
Erstes G80- Tape- Out verfehlt [Charlie, März] (http://www.the-inquirer.net/?article=30624)

Inq eben... :crazy:

[deekey777]

Ihnen geht es nur auf die Anzahl der Klick auf den eigenen Artikel, der Rest ist für sie uninteressant.
http://img61.imageshack.us/img61/7633/theinq9zh.th.png (http://img61.imageshack.us/my.php?image=theinq9zh.png)

Gast[/POST]']Ist Blödsinn. Eine Karte die D3D10 (es gibt immer noch kein DX10) unterstützt muss SM 4.0 haben - und zwar vollständig.

Inq hat mal wieder was mit unified shadern und der API durcheinander gebracht - wie üblich.

Sehr diplomatisch ausgedrückt. :)
Dafür ist der G80 Vista ready. :| :D

[Janchu88]

was hab ich gelesen(weiss nicht mehr wo), G80 wird keine unfied Shader haben?

[Ailuros]

Janchu88[/POST]']was hab ich gelesen(weiss nicht mehr wo), G80 wird keine unfied Shader haben?

Hoechstwahrscheinlich nicht. Das hat aber nichts im geringsten mit SM4.0 oder D3D10 Komplianz zu tun. Unified shaders sind keine Vorraussetzung fuer D3D10; es steht den IHVs frei wie sie die Hardware bauen und dem API ist es auch egal wie die HW aussieht.

Trotz allem habe ich es momentan etwas schwer zu glauben dass G80 effizienter (rein theoretisch gesehen) sein koennte als R6x0 mit allem >D3D9.0.

[Winter[Raven]]

Ailuros[/POST]']Hoechstwahrscheinlich nicht. Das hat aber nichts im geringsten mit SM4.0 oder D3D10 Komplianz zu tun. Unified shaders sind keine Vorraussetzung fuer D3D10; es steht den IHVs frei wie sie die Hardware bauen und dem API ist es auch egal wie die HW aussieht.

Trotz allem habe ich es momentan etwas schwer zu glauben dass G80 effizienter (rein theoretisch gesehen) sein koennte als R6x0 mit allem >D3D9.0.

Woran machst du das fest? :confused:

[Janchu88]

Ailuros[/POST]']Hoechstwahrscheinlich nicht. Das hat aber nichts im geringsten mit SM4.0 oder D3D10 Komplianz zu tun. Unified shaders sind keine Vorraussetzung fuer D3D10; es steht den IHVs frei wie sie die Hardware bauen und dem API ist es auch egal wie die HW aussieht.
Das sie dadurch D3D10 nicht entspricht hab ich nicht behauptet ;)

Nur dürfte das beim Thema Performance denk ich mal ein guter sprung sein mit US.

[Gast]

Janchu88[/POST]']Nur dürfte das beim Thema Performance denk ich mal ein guter sprung sein mit US.Warum sollte es das?

[AnarchX]

Janchu88[/POST]']
Nur dürfte das beim Thema Performance denk ich mal ein guter sprung sein mit US.

Kann aber auch gehörig in die Hose gehen, wenn man es nicht richtig hinbekommt.

[Hvoralek]

Janchu88[/POST]']Nur dürfte das beim Thema Performance denk ich mal ein guter sprung sein mit US.Ein "guter Sprung" eigentlich nur bei sehr hoher Geometrielast im Verhältnis zum Pixel- Shading.

[Gast]

Ailuros[/POST]']Trotz allem habe ich es momentan etwas schwer zu glauben dass G80 effizienter (rein theoretisch gesehen) sein koennte als R6x0 mit allem >D3D9.0.
Das glaube ich auch nicht. Allerdings interessiert die meisten Kunden ja eher das, was hinten rauskommt und nicht die Effizienz.

Wobei: Welche Effizienz meinst du eigentlich? Fps pro Transistor? Fps pro Watt? Transistor pro Watt? Fps pro mm²? Fps pro €?


Wenn ich mir aktuelle D3D9-GPUs in 90 nm anschaue, dann scheint Nvidia da durchaus einen "Effizienzvorteil" in Sachen Herstellungskosten zu haben (gleiche Konditionen bei TSMC mal vorausgesetzt).

Wenn das Gerücht mit 64 Vec4+Skalar-ALUs für den R600 stimmt, so könnte ich mir angesichts der aktuellen Situation (was sich für 80 oder 65 nm durchaus ändern kann!) auch vorstellen, dass Nvidia im selben Prozess auch 32 PS-ALUs plus X Vertex-ALUs hinbekommt. Klar - im Vertexbereich wären sie dann hintenan, aber außer im 3DMark macht das ja meist wenig aus.

Für den professionellen Einsatz andererseits müssten eine US-Architektur sowas wie der heilige Gral sein.

[robbitop]

NV und ATI verfügen ja jetzt bereits über 48x Vec4 ALUs +8xVec5 ALUs aus dem VS. IMO keine deutliche Steigerung der Roh-aritmetic IPC (auf dem Papier). Vec5 kann man AFAIK eh kaum fürs Pixelshading gebrauchen.

[Gast]

robbitop[/POST]']NV und ATI verfügen ja jetzt bereits über 48x Vec4 ALUs +8xVec5 ALUs aus dem VS. IMO keine deutliche Steigerung der Roh-aritmetic IPC (auf dem Papier). Vec5 kann man AFAIK eh kaum fürs Pixelshading gebrauchen.
Eben.



Vielleicht könnte einer unserer Experten ja mal Beispielhaft vorrechnen, in welchem Größenverhältnis eine aktuelle PS-Quadpipe bei Nvidia zu dem steht, was bei einem ähnlich mächtigen US benötigt würde.

Ati wäre mit ihren stärker entkoppelten Einheiten da sicherlich schon einen Schritt näher dran. Zu welchem Preis sehen wir aktuell: rund 38% mehr Transistoren.

[robbitop]

Das kann man so nicht sagen. ATI trägt im R580 noch viele Altlasten aus vergangenen Serien herum, so dass einiges nicht sonderlich effizient konstruiert werden konnte. Das kostete Transistoren. C1 bsw scheint hingegen sehr effizient konstruiert zu sein. Und das bei ähnlicher Ausführungseinheitenanzahl wie R580. Natürlich fehlen ein paar Dinge, wie Speichercontroller, ROPs (beides im Daughter DIE), man hat keine extra CS und ein 2D Kern. Aber dennoch sehr beachtlich was man mit sowenigen Transistoren hinbekam und praktisch ein USC ist.
Aber man darf

[Gast]

Was genau kann man so nicht sagen? Ich stelle ja keinen 1:1-Vergleich an.

[Ailuros]

Gast[/POST]']Das glaube ich auch nicht. Allerdings interessiert die meisten Kunden ja eher das, was hinten rauskommt und nicht die Effizienz.

Wobei: Welche Effizienz meinst du eigentlich? Fps pro Transistor? Fps pro Watt? Transistor pro Watt? Fps pro mm²? Fps pro €?


Wenn ich mir aktuelle D3D9-GPUs in 90 nm anschaue, dann scheint Nvidia da durchaus einen "Effizienzvorteil" in Sachen Herstellungskosten zu haben (gleiche Konditionen bei TSMC mal vorausgesetzt).

Wenn das Gerücht mit 64 Vec4+Skalar-ALUs für den R600 stimmt, so könnte ich mir angesichts der aktuellen Situation (was sich für 80 oder 65 nm durchaus ändern kann!) auch vorstellen, dass Nvidia im selben Prozess auch 32 PS-ALUs plus X Vertex-ALUs hinbekommt. Klar - im Vertexbereich wären sie dann hintenan, aber außer im 3DMark macht das ja meist wenig aus.

Für den professionellen Einsatz andererseits müssten eine US-Architektur sowas wie der heilige Gral sein.

Effizienz fuer Einzelheit bei denen ein USC Vorteile haben kann. U.a. Geometrie-Shader (wenn eine ALU PS/VS kann, wird wohl noch GS nicht besonders schwer sein), geometry/vertex texturing und die dementsprechende Latenz usw.

Ganz nebenbei sind es hoechstwahrscheinlich mehr ALUs auf G80; Du meinst wohl eher SIMD Kanaele oder quads. Es wuerde mir persoenlich keinen besonderen Eindruck machen wenn sie bei 6 quads bleiben und die Anzahl der ALUs pro SIMD Kanal nochmal erhoeht haben.

Die bisherigen Anzeigen fuer den GS sehen eher =/<befriedigend aus um etwas grosszuegig zu sein ;)

***edit: wenn die R6x0 ALUs nur 8 FLOPs pro Takt rechnen koennen, waere ich verdammt enttaeuscht. Unter theoretischen 500 GFLOPs wuerde ich keine D3D10 GPU erwarten.

[paul.muad.dib]

Der Türke[/POST]']hallo,

will kein extra thread deswegen eröffnen...

AA ist ja "abhängig" von der speicherbrandbreite...d.h je höher desto mehr fps...

daher meine frage: gibt es überhaubt eine "grenze" (z.B 1500mhz GDDR4) wo z.B 4xAA "for free" realisierbar ist? oder wird es immer ne begrenzung geben?

und wie sieht es mit AF aus? ist sie von irgendwas abhängig? (vielleicht pipelines?...), sodass auch z.B 8xAF irgenwann mal ab eine bestimmte grenze "for free" ist?

wie ich drauf komme: früher war der 32-Bit Modus sehr performance raubend im gegensatz zum 16-Bit Modus. Heutzutage ist 32-Bit "for free"...

mfg

Umsonst wird es wohl nie sein. Es ist weniger eine Frage, wie knapp die Speicherbandbreite ist. Wenn du einer Radeon 9600 GDDR4 RAM mit einem 256 bit Interface aufpropfen würdest, wäre AA umsonst, weil der Chip sonst die verfügbare Bandbreite gar nicht abrufen könnte.
Der Bedarf an Speicherbandbreite bzw. die Fähigkeit der Chips, diese abzurufen steigt aber tatsächlich schneller, so dass sich wohl nie eine solche Situation ergeben wird.

Noch schlimmer ist es mit AF. Diese kostet Füllrate und die wird es wohl nie im Überschuss geben. Einziger Sonderfall könnte ein r520 in einem extrem Shaderintensiven Spiel sein. Da er nur relativ wenige ALUs hat, könnten die TMUs dann mit geringem Geschwindigkeitsverlust filtern, wenn die ALUs eh' noch beschäftigt sind.

Generell werden die IHVs aber immer versuchen, ihre Chips so ausgeglichen zu designen, dass an keiner Stelle ein Überangebot besteht.

[paul.muad.dib]

Ailuros[/POST]']Trotz allem habe ich es momentan etwas schwer zu glauben dass G80 effizienter (rein theoretisch gesehen) sein koennte als R6x0 mit allem >D3D9.0.

Wenn es um Leistung/Transistor geht, warum nicht? NV muss nur ein paar Vertex Shader einbauen, Ati muss jedem seiner 64 PS die Fähigkeit geben, VS ausführen zu können + einer Steuereinheit, die sagt, was das jetzt gerade ist.
Ein klarer Vorteil ist es nur, wenn sich ein Entwickler entscheidet, deutlich mehr Shader auf Eckpunkte anzuwenden und weniger pixelgenau.

[Coda]

Du hast eine falsche Vorstellung von einem unified-shader-Design. Die ALUs sind nicht "Pixelshader" sondern einfach nur ALUs. Es werden also keine Vertexshader irgendwie auf Pixelshadern ausgeführt.

[Ailuros]

Coda[/POST]']Du hast eine falsche Vorstellung von einem unified-shader-Design. Die ALUs sind nicht "Pixelshader" sondern einfach nur ALUs. Es werden also keine Vertexshader irgendwie auf Pixelshadern ausgeführt.

Ich wuerde sie GP-ALUs nennen ;)

So und jetzt erklaer ihm bitte mal wie z.B. vertex/geometry texturing Latenz auf einem USC aussieht.

[Ailuros]

paul.muad.dib[/POST]']Wenn es um Leistung/Transistor geht, warum nicht? NV muss nur ein paar Vertex Shader einbauen, Ati muss jedem seiner 64 PS die Fähigkeit geben, VS ausführen zu können + einer Steuereinheit, die sagt, was das jetzt gerade ist.
Ein klarer Vorteil ist es nur, wenn sich ein Entwickler entscheidet, deutlich mehr Shader auf Eckpunkte anzuwenden und weniger pixelgenau.

Woher kommt der Quark genau dass NV "nur" ein paar VS einbauen muss?

Lesen bildet:

http://www.extremetech.com/article2/0,1697,1982041,00.asp

Mit allerhoechster Wahrscheinlichkeit werden GS Faehigkeiten in den Geometrie- bzw. VS Einheiten untergebracht; dass aber dabei GS-Faehigkeiten rauskommen koennten die nicht viel wert sind oder anders eher als Papiertiger dienen ist sicher nebensaechlich.

Und bitte die Tabelle oben im Link auf der zweiten Seite genau durchlesen. "Nur ein paar VS mehr" ist laecherlich im Vergleich zu dem was D3D10 Komplianz genau vorraussetzt. Zur Erinnerung NV4x/G7x haben 4096 PS30 und 544 VS30 instructions slots wenn mich mein Gedaechtnis nicht betruegt.

[Gast]

Ailuros[/POST]']Zur Erinnerung NV4x/G7x haben 4096 PS30 und 544 VS30 instructions slots wenn mich mein Gedaechtnis nicht betruegt.
Ich glaube, das sind schon ein paar mehr - besonders im Pixel-Bereich. Sie werden allerdings nicht durch den Treiber entblößt.

[Gast]

Ailuros[/POST]']Effizienz fuer Einzelheit bei denen ein USC Vorteile haben kann. U.a. Geometrie-Shader (wenn eine ALU PS/VS kann, wird wohl noch GS nicht besonders schwer sein), geometry/vertex texturing und die dementsprechende Latenz usw.

Ganz nebenbei sind es hoechstwahrscheinlich mehr ALUs auf G80; Du meinst wohl eher SIMD Kanaele oder quads. Es wuerde mir persoenlich keinen besonderen Eindruck machen wenn sie bei 6 quads bleiben und die Anzahl der ALUs pro SIMD Kanal nochmal erhoeht haben.

Die bisherigen Anzeigen fuer den GS sehen eher =/<befriedigend aus um etwas grosszuegig zu sein ;)

***edit: wenn die R6x0 ALUs nur 8 FLOPs pro Takt rechnen koennen, waere ich verdammt enttaeuscht. Unter theoretischen 500 GFLOPs wuerde ich keine D3D10 GPU erwarten.
Uh - Sorry. Ich meinte natürlich auch 64 PS-ALUs, also 32 ihrer bisherigen Doppel-ALUs. Ich erwarte noch nicht, dass Nvidia ihr Design soweit umkrempelt, dass sie die TMUs soweit entkoppeln, wie Ati.

Andererseits erwarte ich auch bei Ati, wie ich allerdings schrieb, keine großartige Abkehr von den XBox-360-ALUs, sprich Vec4+ Skalar - mit etwas Glück vielleicht Vec5 inkl. dem m.E. nach potentiell sehr nützlichen 3:2 Split.

Daran, dass sie weiterhin die Mini-ADD-ALU mitschleppen glaube ich nicht, dafür ist bsw. Xenos zu schlank.

[paul.muad.dib]

Coda[/POST]']Du hast eine falsche Vorstellung von einem unified-shader-Design. Die ALUs sind nicht "Pixelshader" sondern einfach nur ALUs. Es werden also keine Vertexshader irgendwie auf Pixelshadern ausgeführt.

So habe ich das auch gar nicht gemeint. Nur wird eine Unified Shader ALU eben mehr Transistoren kosten als ein einfacher PS. Und das muss eben mal 64 gerechnet werden zzgl. der Transistoren für eine komplexe Steuereinheit.
Diesen Aufwand an Transistoren muss man dann eben vergleichen mit dem von Nvidia, VS und GS zu realisieren.

[reunion]

paul.muad.dib[/POST]']So habe ich das auch gar nicht gemeint. Nur wird eine Unified Shader ALU eben mehr Transistoren kosten als ein einfacher PS. Und das muss eben mal 64 gerechnet werden zzgl. der Transistoren für eine komplexe Steuereinheit.
Diesen Aufwand an Transistoren muss man dann eben vergleichen mit dem von Nvidia, VS und GS zu realisieren.

Das lässt sich gewiss nicht so einfach sagen. Xenos bringt 48 vollwertige MAD4-ALUs und 16 TMUs in ~220mio Transistoren unter und ist ein USC. Diese sind voll SM3.0-fähig (und das nicht nur auf dem Papier), und tw. sogar mehr als das. Klar fehlen da noch u.a. die ROPs aus dem Parent-Die, aber trotzdem halte ich das für erstaunlich effizient, speziell, wenn man sich im Vergleich dazu R580 ansieht.

Wenn nV bei G80 wieder nur einen notdürftig aufgebohrten NV40 bringt, da das US-Projekt offensichtlich noch nicht so weit ist, dann kann es ihnen unter Umständen ähnlich ergehen wie ATi derzeit. Nämlich das die Transistoreneffizienz zu wünschen übrig lässt. Hier heißt es wie immer abwarten und Tee trinken.

[Winter[Raven]]

reunion[/POST]']Das lässt sich gewiss nicht so einfach sagen. Xenos bringt 48 vollwertige MAD4-ALUs und 16 TMUs in ~220mio Transistoren unter und ist ein USC. Diese sind voll SM3.0-fähig (und das nicht nur auf dem Papier), und tw. sogar mehr als das. Klar fehlen da noch die ROPs aus dem Parent-Die, aber trotzdem halte ich das für erstaunlich effizient, speziell, wenn man sich im Vergleich dazu R580 ansieht.

Wenn nV bei G80 wieder nur einen notdürftig aufgebohrten NV40 bringt, da das US-Projekt offensichtlich noch nicht so weit ist, dann kann es ihnen unter Umständen ähnlich ergehen wie ATi derzeit. Nämlich das die Transistoreneffizienz zu wünschen übrig lässt. Hier heißt es wie immer abwarten und Tee trinken.

Wenn du paar seiten umdrehen würdest, hättest du schon gesehen, dass der G80 kein "aufgewärmter" NV40, oder G71 wird. Der wird viel mehr Änderungen mit sich bringen als man vielleicht denkt.

[Demirug]

Ailuros[/POST]']Zur Erinnerung NV4x/G7x haben 4096 PS30 und 544 VS30 instructions slots wenn mich mein Gedaechtnis nicht betruegt.

Wobei die 4096 PS Slots eine Limitierung durch den Treiber sind. Da die PS Einheiten keinen Programmspeicher im üblichen Sinn mehr haben geht viel mehr.

[reunion]

'Winter[Raven]'[/POST]']Wenn du paar seiten umdrehen würdest, hättest du schon gesehen, dass der G80 kein "aufgewärmter" NV40, oder G71 wird. Der wird viel mehr Änderungen mit sich bringen als man vielleicht denkt.

Ich sehe momentan nur Spekulationen, und mehr habe ich auch nicht von mir gegeben. Klar wird G80 die Anforderungen von D3D10 unterstützen, und damit sich auch ein paar größere Änderungen verbunden, aber sonst erwarte ich nichts revolutionäres. Das kommt bei nV IMO erst mit G90(?), da wurden ja schon einige vielversprechende Patente angemeldet.

[paul.muad.dib]

reunion[/POST]']Das lässt sich gewiss nicht so einfach sagen. Xenos bringt 48 vollwertige MAD4-ALUs und 16 TMUs in ~220mio Transistoren unter und ist ein USC. Diese sind voll SM3.0-fähig (und das nicht nur auf dem Papier), und tw. sogar mehr als das. Klar fehlen da noch u.a. die ROPs aus dem Parent-Die, aber trotzdem halte ich das für erstaunlich effizient, speziell, wenn man sich im Vergleich dazu R580 ansieht.

Wenn nV bei G80 wieder nur einen notdürftig aufgebohrten NV40 bringt, da das US-Projekt offensichtlich noch nicht so weit ist, dann kann es ihnen unter Umständen ähnlich ergehen wie ATi derzeit. Nämlich das die Transistoreneffizienz zu wünschen übrig lässt. Hier heißt es wie immer abwarten und Tee trinken.

Ist eine Xenos ALU denn so leistungsfähig wie ein r580 PS?

[reunion]

paul.muad.dib[/POST]']Ist eine Xenos ALU denn so leistungsfähig wie ein r580 PS?

Nein, es fehlt die zusätzliche ADD der Mini-ALU - das rechtfertigt allerdings niemals eine solche Transistorendifferenz, zumal selbst R520 die 300mio-Grenze locker sprengt.

[ShadowXX]

reunion[/POST]']Nein, es fehlt die zusätzliche ADD der Mini-ALU - das rechtfertigt allerdings niemals eine solche Transistorendifferenz, zumal selbst R520 die 300mio-Grenze locker sprengt.
Vielleicht fehlt da auch noch ein bisschen mehr als nur die Mini-Add-Alu.....sprich : wie sieht es mit Special Funktion ala SQR & Co. aus?

Ich glaube nicht, dass ATI es sich leisten kann beim r600 einfach um ( wahrscheinlich nötige) Änderungen für den GS Support modifizierte C1-Alus zu benutzen.
Zumindest wären dann 64 davon IMHO etwas zu wenig.

[Aquaschaf]

reunion[/POST]']Nein, es fehlt die zusätzliche ADD der Mini-ALU - das rechtfertigt allerdings niemals eine solche Transistorendifferenz, zumal selbst R520 die 300mio-Grenze locker sprengt.

Ich könnte mir vorstellen, dass die gute Texturfilterung bei R520/R580 einen nicht geringen Anteil an der Transistordifferenz ausmacht.

[Gast]

Aquaschaf[/POST]']Ich könnte mir vorstellen, dass die gute Texturfilterung bei R520/R580 einen nicht geringen Anteil an der Transistordifferenz ausmacht.Kann ich mir kaum vorstellen, dass das so viel ausmacht. Eine Geforce 4 Ti hatte auch einwandfreie Texturfilterung und war trotzdem recht klein.

[ShadowXX]

Gast[/POST]']Kann ich mir kaum vorstellen, dass das so viel ausmacht. Eine Geforce 4 Ti hatte auch einwandfreie Texturfilterung und war trotzdem recht klein.
Ein GF4 hatte aber auch ein paar Pipelines weniger....die "Masse" macht auch was aus.

Ausserdem vermutete mal jemand, das ATI HQAF "extra" mit eingebaut hat, dieses also über andere Transistoren läuft, als das "normale" AF.
Weiß aber nicht, ob das jetzt wirklich stimmt.

ATI wird auch sehr viele Transistoren dafür verschwendet haben SM3.0 irgendwie in die r300 Grundarchitektur reinzubasteln (auch wenn die Lösung im Endeffekt scheinbar sehr gut gelungen ist, galube ich, das diese sehr "teuer" war).

Und wer weiß wieviele Transitoren nur dafür verbaut sind, damit man die GPU auch auf die Takte bekommt, auf denen Sie jetzt läuft.

Davon abgesehen, kann man die Architektur des C1 und des r580 wohl auch nur sehr sehr schlecht miteinander vergleichen.

[Gast]

ShadowXX[/POST]']Ein GF4 hatte aber auch ein paar Pipelines weniger....die "Masse" macht auch was aus.

Naja. Der NV20 hatt nur ca 50Mio Transistoren bei 8 TMUs. R520/R580 haben auch nur 16.

[Coda]

Ja, aber nur 4 Pipelines. Man kann dadurch immer zwischen 2 TMUs auch Logik teilen.

[reunion]

ShadowXX[/POST]']Vielleicht fehlt da auch noch ein bisschen mehr als nur die Mini-Add-Alu.....sprich : wie sieht es mit Special Funktion ala SQR & Co. aus?


Möglich - leider rückt ja ATi kaum Infos raus.


Ich glaube nicht, dass ATI es sich leisten kann beim r600 einfach um ( wahrscheinlich nötige) Änderungen für den GS Support modifizierte C1-Alus zu benutzen.
Zumindest wären dann 64 davon IMHO etwas zu wenig.

Diese 64 sind doch nur von irgendeinem Schlauberger aus der Luft gegriffen, darauf würde ich gar nichts geben.

Aquaschaf[/POST]']Ich könnte mir vorstellen, dass die gute Texturfilterung bei R520/R580 einen nicht geringen Anteil an der Transistordifferenz ausmacht.

Was sagt dir, dass diese "guten Texturfilter" nicht auch in C1 integriert wurden? Zumal ATi bei B3D ein verbessertes AF verkünden ließ.

[Coda]

reunion[/POST]']Was sagt dir, dass diese "guten Texturfilter" nicht auch in C1 integriert wurden? Zumal ATi bei B3D ein verbessertes AF verkünden ließ.
Was spielt das überhaupt für eine Rolle? - Außer dass man eventuell sinnlose Streitgespräche PS3 vs. Xbox damit würzen kann...

Und nein ich glaubs auch nicht - schon allein weil der übliche Konsolenspieler das garantiert nicht sieht.

[Gast]

Gast[/POST]']Kann ich mir kaum vorstellen, dass das so viel ausmacht. Eine Geforce 4 Ti hatte auch einwandfreie Texturfilterung und war trotzdem recht klein.

Ne Geforce 4 hatte ja auch nur 1 Quad

[Gast]

reunion[/POST]']Was sagt dir, dass diese "guten Texturfilter" nicht auch in C1 integriert wurden? Zumal ATi bei B3D ein verbessertes AF verkünden ließ.

Das er nicht verwendet wird sagt doch alles...
Offtopic aber.

In den 3DCenter News wird auch angesprochen das es Scenarios gibt in denen der G80 Nachteile hat, z.b. wenn die VertexShader limitieren. Was aber noch niemals der Fall war und man sogar bei 16Vertex Einheiten stehen geblieben ist beim G70 anstelle auf 24 Einheiten zu erhöhen.

[Gast]

Gast[/POST]']Das er nicht verwendet wird sagt doch alles...
Offtopic aber.

In den 3DCenter News wird auch angesprochen das es Scenarios gibt in denen der G80 Nachteile hat, z.b. wenn die VertexShader limitieren. Was aber noch niemals der Fall war und man sogar bei 16Vertex Einheiten stehen geblieben ist beim G70 anstelle auf 24 Einheiten zu erhöhen.
Eigentlich hat der G70 nur 8 Vertex-Einheiten. Ich glaube das verwechselst du mit den ROPs.

[reunion]

Coda[/POST]']Was spielt das überhaupt für eine Rolle? - Außer dass man eventuell sinnlose Streitgespräche PS3 vs. Xbox damit würzen kann...

Und nein ich glaubs auch nicht - schon allein weil der übliche Konsolenspieler das garantiert nicht sieht.

Es ging um die Transistorendifferenz.

Gast[/POST]']In den 3DCenter News wird auch angesprochen das es Scenarios gibt in denen der G80 Nachteile hat, z.b. wenn die VertexShader limitieren. Was aber noch niemals der Fall war und man sogar bei 16Vertex Einheiten stehen geblieben ist beim G70 anstelle auf 24 Einheiten zu erhöhen.

Hängt vom Verwendungszweck ab; für gewisse Anwendungen wären ALUs, die ggf. alle als Vertexprozessoren fungieren könnten ein Traum. Als Spieler ist das freilich weniger von belangen.

[Ailuros]

Wo limitieren heutzutage Vertex Shader dass ich es verpasst habe?

Uebrigens wurden auf Xenos fuer AF Transistoren gespart; es gibt schon einen guten Grund warum es nicht benutzt wird.

[paul.muad.dib]

Gast[/POST]']Kann ich mir kaum vorstellen, dass das so viel ausmacht. Eine Geforce 4 Ti hatte auch einwandfreie Texturfilterung und war trotzdem recht klein.

Die Geschwindigkeitseinbrüche bei AF waren aber deutlich größer. ATI verliert selbst mit Area-AF prozentual weniger frames als Nvidia mit aktuellen Karten.

[Hvoralek]

Ailuros[/POST]']Wo limitieren heutzutage Vertex Shader dass ich es verpasst habe?In Oblivion- Außengebieten könnte das vlt. mal vorkommen.

[LordDeath]

Hvoralek[/POST]']In Oblivion- Außengebieten könnte das vlt. mal vorkommen.

da legt sich aber die cpu schneller quer!

[Ailuros]

paul.muad.dib[/POST]']Die Geschwindigkeitseinbrüche bei AF waren aber deutlich größer. ATI verliert selbst mit Area-AF prozentual weniger frames als Nvidia mit aktuellen Karten.

Schoen dann schalt aber bitte mal alle Optimierungen zuerst ab und dann koennen wir ueber Prozente reden.

[chrisihamm]

Hallo,

Na dann schalte doch bei Nvidia auch alle Optimierungen ab und du wirst eine Überraschung erleben!


mfg

[Winter[Raven]]

chrisihamm[/POST]']Hallo,

Na dann schalte doch bei Nvidia auch alle Optimierungen ab und du wirst eine Überraschung erleben!


mfg

Erst denken, dann posten! Danke!

[Hvoralek]

LordDeath[/POST]']da legt sich aber die cpu schneller quer!Nicht unbedingt. Sicher fordert Obl. auch die CPU ziemlich, aber z.B. hier (http://www.computerbase.de/artikel/hardware/grafikkarten/2006/test_asus_en7600gt_silent_en7900gt_top/14/#abschnitt_oblivion) scheint überwiegend die GraKa zu begrenzen, trotz eines FX-60 im Testsystem.

[Ailuros]

Hvoralek[/POST]']In Oblivion- Außengebieten könnte das vlt. mal vorkommen.

Vielleicht? :|

[Hvoralek]

Ailuros[/POST]']Vielleicht? :|In dem Fall kann ich es mir gut vorstellen bei der Geometriekomplexität; ist auch die einzige praktische Anwendung, die mir dazu einfällt. Ich habe aber keine genauen Zahlen, deshalb die Einschränkung.

edit:Beim oben verlinkten CB- Benchmark ist ein nennenswerter Einfluss der VS aber wahrscheinlich. Die X1600Pro liegt erheblich vor der X1300 Pro. Die Unterschiede zwischen denen liegen afaik im Wesentlichen in der höheren Fragment- und Geometrieleistung der X1600 (12:4 bzw. 5:2 bei etwas geringerem Takt). An der Stelle scheint erstere aber fast egal zu sein (vgl. X1800XT - X1900XT).

[Ailuros]

Hvoralek[/POST]']In dem Fall kann ich es mir gut vorstellen bei der Geometriekomplexität; ist auch die einzige praktische Anwendung, die mir dazu einfällt. Ich habe aber keine genauen Zahlen, deshalb die Einschränkung.

edit:Beim oben verlinkten CB- Benchmark ist ein nennenswerter Einfluss der VS aber wahrscheinlich. Die X1600Pro liegt erheblich vor der X1300 Pro. Die Unterschiede zwischen denen liegen afaik im Wesentlichen in der höheren Fragment- und Geometrieleistung der X1600 (12:4 bzw. 5:2 bei etwas geringerem Takt). An der Stelle scheint erstere aber fast egal zu sein (vgl. X1800XT - X1900XT).

Und wie waere es damit Daten von mehr als einer Quelle unter Betracht zu nehmen?

http://www.techreport.com/reviews/2006q2/geforce-7950-gx2/index.x?pg=5

Minimum framerate bitte auch beachten.

Ganz nebenbei die GX2 hat 16 VS Einheiten @ 500MHz. Irgend eine Anzeige dass hier die doppelt so viele VS Einheiten einen nennenswerten Unterschied machen?

[Gast]

Ailuros[/POST]']Wo limitieren heutzutage Vertex Shader dass ich es verpasst habe?In den ATI-Techdemos mit Ruby, das wärs dann aber auch schon wieder.

[Ailuros]

Gast[/POST]']In den ATI-Techdemos mit Ruby, das wärs dann aber auch schon wieder.

Erstens ist ein Techdemo und zweitens bezweifle ich dass das neueste demo bei gleichen settings besser auf Xenos laufen wuerde als auf einer R5x0. Noch schlimmer wenn man MSAA und AF dazufuegt.

Bevor Ihr mir mit irgendwelchen feuchten Traeumen ueber so und so viele GP-ALUs in einem USC ankommt (wobei rein theoretisch 48 ALUs nur VS bearbeiten koennten als Beispiel), waere es weiser zuerst die Limitierung des triangle setups zuerst zu bedenken.

[Neomi]

Ailuros[/POST]']Ganz nebenbei die GX2 hat 16 VS Einheiten @ 500MHz. Irgend eine Anzeige dass hier die doppelt so viele VS Einheiten einen nennenswerten Unterschied machen?

Und diese 16 Einheiten brutto berechnen alles schön doppelt, weil jede der beiden Hälften die gleichen Dreiecke braucht, es bleiben also 8 Einheiten netto übrig. AFR ist die einzige Ausnahme.

Ailuros[/POST]']Bevor Ihr mir mit irgendwelchen feuchten Traeumen ueber so und so viele GP-ALUs in einem USC ankommt (wobei rein theoretisch 48 ALUs nur VS bearbeiten koennten als Beispiel), waere es weiser zuerst die Limitierung des triangle setups zuerst zu bedenken.

Das Triangle Setup wird erst dann zum Flaschenhals, wenn man sehr viele VS-Einheiten mit einem sehr kurzen Shader auslasten kann. Man kann aber auch die Komplexität der Shader erhöhen, um mehr Qualität zu bekommen. Bei der Interpolation zwischen Keyframes kann man z.B. jedem Vertex noch einen Bewegungsvektor mitgeben, um an einem Spline entlang (statt linear) zu interpolieren.

Aus logischer Sicht ist es nie verkehrt, mehr Shader einer Sorte (in dem Fall per US und Load Balancing) zu haben. Ob sich das von den Transistoren her lohnt, ist die (vielleicht einzige) Frage.

[Ailuros]

Neomi[/POST]']Und diese 16 Einheiten brutto berechnen alles schön doppelt, weil jede der beiden Hälften die gleichen Dreiecke braucht, es bleiben also 8 Einheiten netto übrig. AFR ist die einzige Ausnahme.

Das ist mir schon klar. Die Mehrzahl der neuesten Spiele kommen mit AFR sowieso gut aus.

Meine Frage war eher auf die Resultate ausgerichtet:

http://www.techreport.com/reviews/2006q2/geforce-7950-gx2/oblivion.gif

http://www.techreport.com/reviews/2006q2/geforce-7950-gx2/index.x?pg=5

Die 7900GT laeuft hier offensichtlich mit 450MHz waehrend die GX2 mit 500MHz; aber ich sehe trotzdem nichts dass mir vorschlaegt dass Oblivion vertex shader limitiert ist.

[Ailuros]

Neomi[/POST]']
Das Triangle Setup wird erst dann zum Flaschenhals, wenn man sehr viele VS-Einheiten mit einem sehr kurzen Shader auslasten kann. Man kann aber auch die Komplexität der Shader erhöhen, um mehr Qualität zu bekommen. Bei der Interpolation zwischen Keyframes kann man z.B. jedem Vertex noch einen Bewegungsvektor mitgeben, um an einem Spline entlang (statt linear) zu interpolieren.

Aus logischer Sicht ist es nie verkehrt, mehr Shader einer Sorte (in dem Fall per US und Load Balancing) zu haben. Ob sich das von den Transistoren her lohnt, ist die (vielleicht einzige) Frage.

Verkehrt ist es sicher nicht nur erstens sind die benutzten VS in heutigen Spielen genau wie lang, zweitens ueberwiegen die PS den VS calls afaik in heutigen Spielen bei weitem (welches heutige oder kommende Spiel ist so vertex setup limitiert wie 3dfart05/06?) und drittens nur weil Xenos als Beispiel rein theoretisch alle 48 ALUs fuer VS einsetzen koennte heisst es bei weitem nicht dass trotz load balancing es fuer sein Lebenszeit je so weit kommen wuerde.

Xenos ist zugegeben ein Exote im Vergleich zu PC GPU Designs, aber ich hab das merkwuerdige Gefuehl dass das letzte Ruby demo mit AA/AF nicht schneller laufen wuerde als auf einer X1x00 und das selbst in 720p. Erstens weil Xenos aus Sparsamkeit nicht die gleichen AF-Leistungsoptimierungen hat wie desktop GPUs und zweitens wird wohl ein guter Happen an Geometrie beim macro tiling fuer 4xMSAA wiederholt.

Was ich nur damit sagen will ist dass Papierfranzen zwar gut klingen in allen Faellen, aber irgendwo wird es immer Limitierungen geben bei jedem Design durch eben den jeweiligen begrenzten Transistoren-budget. Ich sehe keine Not momentan fuer zich mehr VS-throughput in heutigen und zukuenftigen Spielen, eher eine viel groessere Not fuer zich mehr floating point power in Richtung PS. Dass bei einem USC diese FP Staerke effizient auf jeweils PS/VS/GS verteilt werden kann ist mir schon klar.

[Hvoralek]

Ailuros[/POST]']Und wie waere es damit Daten von mehr als einer Quelle unter Betracht zu nehmen?

http://www.techreport.com/reviews/2006q2/geforce-7950-gx2/index.x?pg=5

Minimum framerate bitte auch beachten.

Ganz nebenbei die GX2 hat 16 VS Einheiten @ 500MHz. Irgend eine Anzeige dass hier die doppelt so viele VS Einheiten einen nennenswerten Unterschied machen?Kannts Du mal erläutern, wie Du durch einen Vergleich von zwei Karten, bei der bei einer praktisch *alles* doppelt ist, Rückschlüsse auf die Bedeutung der VS ziehen möchtest? Hier wären mMn Karten sinnvoller, die sich bis auf die Geometrieleistung möglichst geringfügig unterscheiden. Solche sehe ich bei dem Benchmark aber nicht. Was wäre denn "[etwas] dass [D]ir vorschlaegt dass Oblivion vertex shader limitiert ist"?

Des Weiteren habe ich nicht behauptet, dass in Oblvion- Außengebieten stehts v.a. die VS begrenzen, sondern lediglich, dass sie dort in einigen Fällen mal eine nennenswerte Rolle spielen dürften. Zumindest auf dem Screenshot scheinen mir aber für Oblivion- "Wald"gebiete sehr wenige Polygone sehen zu sein. UXGA und 16x AF sind afaik auch nicht gerade Einstellungen, in denen VS allzu sehr gefordert werden.

[Gast]

könnte man evt. schätzen wann der g80 jetzt auf dem Markt kommt? Ich brauche eine neue Graka will aber jetzt nich 400€ für eine graka ausgeben wenn es in 1-2 monaten den G80 zu kaufen gibt. Könnten die insider schätzen wann ungefähr der g80 kommt?

[paul.muad.dib]

Ailuros[/POST]']Schoen dann schalt aber bitte mal alle Optimierungen zuerst ab und dann koennen wir ueber Prozente reden.

Falls du auf die brilineare Filterung anspielst, die ist bei NV auch und trotzdem verlieren sie stärker. Wenn du die AF Blume meinst, die war beim NV20 auch nicht ganz perfekt.
Aber diese BQ Diskussion klärt noch immer nicht die Frage, ob der Hohe Transistorcount beim r580 z.T. auf die schnelle und hochwertige AF zurückzuführen ist, oder ob Transistoren ein die Leistungsfähigkeit der einzelnen ALUs gegenüber dem Xenos investiert wurden.

[reunion]

paul.muad.dib[/POST]']Falls du auf die brilineare Filterung anspielst, die ist bei NV auch und trotzdem verlieren sie stärker.

Dass das AF auf einer ATi-Karte schneller ist, liegt ganz einfach daran, dass die Pipeline nicht blockiert wird, wenn die Texturlast zu hoch wird. Das ist aber schon mindestens seit R300 so.

paul.muad.dib[/POST]']Aber diese BQ Diskussion klärt noch immer nicht die Frage, ob der Hohe Transistorcount beim r580 z.T. auf die schnelle und hochwertige AF zurückzuführen ist, oder ob Transistoren ein die Leistungsfähigkeit der einzelnen ALUs gegenüber dem Xenos investiert wurden.

Natürlich kostet das höherwertige AF Transistoren, aber IMO nicht in dem Ausmaß, den mache hier vermuten. Das primäre Ziel dieses Winkelabhängigem AFs war wohl viel mehr das herausschinden der letzten paar, womöglich entscheidenden fps, denn das sparen von Transistoren.

[aths]

reunion[/POST]']Dass das AF auf einer ATi-Karte schneller ist, liegt ganz einfach daran, dass die Pipeline nicht blockiert wird, wenn die Texturlast zu hoch wird. Das ist aber schon mindestens seit R300 so.Wenn die Texturlast zu hoch wird, stallt natürlich auch die Radeon-Pipeline.

[Gast]

Neomi[/POST]']Und diese 16 Einheiten brutto berechnen alles schön doppelt, weil jede der beiden Hälften die gleichen Dreiecke braucht, es bleiben also 8 Einheiten netto übrig. AFR ist die einzige Ausnahme.Wobei selbst bei den von NV mitgelieferten SLI-Profilen AFR eher die Regel als die Ausnahme ist.

[Ailuros]

Hvoralek[/POST]']Kannts Du mal erläutern, wie Du durch einen Vergleich von zwei Karten, bei der bei einer praktisch *alles* doppelt ist, Rückschlüsse auf die Bedeutung der VS ziehen möchtest?

Es ist lediglich ein weiterer Fall wo es keine einzige Andeutung gibt dass Oblivion VS limitiert ist. Ich hab bis heute noch kein Spiel gesehen dass VS limitiert ist, in Echtzeit sowohl auch in benchmarks dieser Spiele.

Eine These versucht man im Idealfall zu dokumentieren bevor sie erstmal einer standhaften Theorie nahekommen koennte und von solcher Dokumentation sehe ich von Deiner Seite gleich gar nichts.

Hier wären mMn Karten sinnvoller, die sich bis auf die Geometrieleistung möglichst geringfügig unterscheiden. Solche sehe ich bei dem Benchmark aber nicht. Was wäre denn "[etwas] dass [D]ir vorschlaegt dass Oblivion vertex shader limitiert ist"?

Dass 3dmark05/06 vertex setup limitiert ist kann man sehen. Irgendwelche Gemeinsamkeiten dieser beiden synthetischen Benchmarks und Oblivion oder zumindest Anzeigen?

Des Weiteren habe ich nicht behauptet, dass in Oblvion- Außengebieten stehts v.a. die VS begrenzen, sondern lediglich, dass sie dort in einigen Fällen mal eine nennenswerte Rolle spielen dürften. Zumindest auf dem Screenshot scheinen mir aber für Oblivion- "Wald"gebiete sehr wenige Polygone sehen zu sein. UXGA und 16x AF sind afaik auch nicht gerade Einstellungen, in denen VS allzu sehr gefordert werden.

Heutige und zukuenftige Spiele konzentrieren sich bei einem sehr grossen Prozentual auf Pixel Shader.

Zitat:

PS 3.0 utilizes a wide range of optimizations, from 64-bit frame-buffer blending to looping and dynamic conditionals for rendering multiple light interactions in a single pass without requiring a combinatorical explosion of precompiled shaders.

Our pixel shaders in the Unreal Engine 3 demos are typically 50-200 instructions in length, and are composed from a wide range of artist-controlled components and procedural algorithms.

Our vertex shaders are quite simple nowadays, and just perform skeletal blending and linear interpolant setup on behalf of the pixel shaders. All of the heavy lifting is now on the pixel shader side -- all lighting is per-pixel, all shadowing is per-pixel, and all material effects are per-pixel.

Once you have the hardware power to do everything per-pixel, it becomes undesirable to implement rendering or lighting effects at the vertex level; such effects are tessellation-dependent and difficult to integrate seamlessly with pixel effects.

http://www.beyond3d.com/interviews/sweeneyue3/

Zu guter letzt USCs sind tatsaechlich eine logische Richtung die GPUs in kurzer Zeit nehmen werden und natuerlich wird es Vorteile bei diesen geben nur heisst es auch wieder nicht dass jetzt Entwickler ploetzlich um zich hunderte Prozent Geometrie vom einen Tag auf den anderen skalieren werden. Der Geometrie Shader ist eine gute Loesung in die Richtung von HOS, aber es fehlt immer noch an voll programmierbarer Tesselation die entweder in 4-5 Jahren in "D3D11" erscheinen wird oder die IHVs finden in der Zwischenzeit eine bessere Alternative.

USCs sind keine Wunderkisten wie alles andere auch; stinkt der thread scheduler dann wird daraus eher eine GPGPU die nicht viel wert ist.

All DirectX9 applications will automatically take advantage of PCI-Express as soon as it's available.

We're using the GPU for visual effects processing, which includes both the obvious task of rendering visible pixels, and the invisible supporting work of, for example, generating shadow buffers and performing image convolution.

However, given the limitations of the DirectX9 and HLSL programming model, I don't take seriously the idea of running non-visual processes like physics or sound on the GPU in the DirectX9 timeframe. For serious programming work, you need modern data structure features such as data pointers, linked lists, function pointers, random access memory reads and writes, and so on.

GPU's will inevitably evolve to the point where you can simply compile C code to them. At that point a GPU would be suitable for any high-performance parallel computing task.

http://www.beyond3d.com/interviews/sweeneyue3/index.php?p=2

D3D10.1 und D3D10.2 sind dann einen Schritt naeher dran und der naechste grosse Schritt kommt dann selbstverstaendlich mit dem neuen API ein halbes Jahrzeht spaeter.

[Hvoralek]

Ailuros[/POST]']Es ist lediglich ein weiterer Fall wo es keine einzige Andeutung gibt dass Oblivion VS limitiert ist. Ich hab bis heute noch kein Spiel gesehen dass VS limitiert ist, in Echtzeit sowohl auch in benchmarks dieser Spiele.Es gibt im TR- Benchmark keine Hinweise darauf. Das einzige, was ich da erkennen kann, ist eine starke Fragment- Limitierung beim R520. Wie oben schon gesagt, halte ich anhand der Einstellungen und der Stelle, an der getestet wurde, eine VS- Limitierung für unwahrscheinlich, aber ich sehe nicht, dass man anhand der Ergebnisse irgendetwas dazu sagen könnte.

Soll jetzt die Tatsache, dass aus diesem Test keine VS- Limitierung ersichtlich ist, Deine Meinung belegen, dass es in Oblivion keine Stellen gibt, an denen die Geometrieleistung eine Rolle spielt? Ich denke, der CB- Benchmark ziegt ziemlich deutlich, dass es welche gibt, wenn auch natürlich nicht das gesamte Spiel stark an den VS hängt.

Eine These versucht man im Idealfall zu dokumentieren bevor sie erstmal einer standhaften Theorie nahekommen koennte und von solcher Dokumentation sehe ich von Deiner Seite gleich gar nichts.Kannst du kurz erläutern, was für eine Art "Dokumentation" Du Dir vorstellst? Für mich sind die ziemlich großen Mengen an Polygonen in den Wäldern und der CB- Benchmark fürs Erste überzeugend genug, ich arbeite ja nicht an einer Diplomarbeit oder Dissertation zu dem Thema. Jedenfalls bin ich sicherlich schon mal weiter von "Gar nichts" entfernt als Du.

Wenn Du lieber der Meinung bist, dass die VS in Oblivion stets völlig unbedeutend seien, dann bitte. Aber erwarte bitte nicht, dass ich mich dem anschließe, solange Du Deine "Argumentation" nicht ergänzt oder zumindest eine andere Erklärung für die CB- Ergebnisse lieferst. Vlt. gibt es ja Unterschiede zwischen RV515/ 530, die ich nicht kenne oder nicht bedacht habe.

Dass 3dmark05/06 vertex setup limitiert ist kann man sehen. Woran siehst Du das? Natürlich hast Du recht, aber mich würde mal interessieren, was für eine "Dokumentation" Dich davon überzeugen kann. Du meinst wahrscheinlich Vertex Shader und nicht Triangle Setup?

Irgendwelche Gemeinsamkeiten dieser beiden synthetischen Benchmarks und Oblivion oder zumindest Anzeigen?Entschuldige, falls das jetzt zu laienhaft ist: Stellenweise sehr hohe Polygonzahlen. Ich hatte bei Oblivion auch gewisse Déjà- vu- Erlebnisse bzgl. des Glühwürmchen- Benchmarks.

Heutige und zukuenftige Spiele konzentrieren sich bei einem sehr grossen Prozentual auf Pixel Shader.Natürlich begrenzt viel häufiger Fragment- als Geometrieleistung. Es gibt mMn kaum etwas Unwichtigeres an einer Grafikkarte als die Anzahl der VS. Oblivion ist auch das einzige praktische Beispiel für eine Bedeutung der VS, das mir einfällt :wink:

Zu guter letzt USCs sind tatsaechlich eine logische Richtung die GPUs in kurzer Zeit nehmen werden und natuerlich wird es Vorteile bei diesen geben nur heisst es auch wieder nicht dass jetzt Entwickler ploetzlich um zich hunderte Prozent Geometrie vom einen Tag auf den anderen skalieren werden. Der Geometrie Shader ist eine gute Loesung in die Richtung von HOS, aber es fehlt immer noch an voll programmierbarer Tesselation die entweder in 4-5 Jahren in "D3D11" erscheinen wird oder die IHVs finden in der Zwischenzeit eine bessere Alternative.

USCs sind keine Wunderkisten wie alles andere auch; stinkt der thread scheduler dann wird daraus eher eine GPGPU die nicht viel wert ist.

http://www.beyond3d.com/interviews/sweeneyue3/index.php?p=2

D3D10.1 und D3D10.2 sind dann einen Schritt naeher dran und der naechste grosse Schritt kommt dann selbstverstaendlich mit dem neuen API ein halbes Jahrzeht spaeter.Ob sich USCs für 3D- Berechnungen lohnen, kann ich nicht sagen, weil ich nicht weiß, wieviele Transistoren man dafür zusätzlich benötigt. Ich glaube jedenfalls auch kaum, dass es dadurch plötzlich einen Sprung bei der Geometriekomplexität geben wird, aber es ist sicherlich nicht schlecht, den Entwicklern diese Möglichkeit an die Hand zu geben. Die eigentlich strittige Frage war aber doch afair die Rolle der VS in Oblivion?

[Ailuros]

chrisihamm[/POST]']Hallo,

Na dann schalte doch bei Nvidia auch alle Optimierungen ab und du wirst eine Überraschung erleben!


mfg

Die Prozente sind inwiefern unterschiedlich? Im Fall der Radeons koennten die Prozente sogar noch hoeher sein wenn noch anderer irrelevanter Schnickschnack mit AI off abgeschaltet wird.

Im Humus adaptiven Supersampling demo als Beispiel brechen beide Seiten um etwa das gleiche Prozentual ein.

[Ailuros]

Hvoralek[/POST]']Es gibt im TR- Benchmark keine Hinweise darauf. Das einzige, was ich da erkennen kann, ist eine starke Fragment- Limitierung beim R520. Wie oben schon gesagt, halte ich anhand der Einstellungen und der Stelle, an der getestet wurde, eine VS- Limitierung für unwahrscheinlich, aber ich sehe nicht, dass man anhand der Ergebnisse irgendetwas dazu sagen könnte.

Soll jetzt die Tatsache, dass aus diesem Test keine VS- Limitierung ersichtlich ist, Deine Meinung belegen, dass es in Oblivion keine Stellen gibt, an denen die Geometrieleistung eine Rolle spielt? Ich denke, der CB- Benchmark ziegt ziemlich deutlich, dass es welche gibt, wenn auch natürlich nicht das gesamte Spiel stark an den VS hängt.

Was genau schliesst mir aus dass die CPU hier nicht limitiert?

Kannst du kurz erläutern, was für eine Art "Dokumentation" Du Dir vorstellst? Für mich sind die ziemlich großen Mengen an Polygonen in den Wäldern und der CB- Benchmark fürs Erste überzeugend genug, ich arbeite ja nicht an einer Diplomarbeit oder Dissertation zu dem Thema. Jedenfalls bin ich sicherlich schon mal weiter von "Gar nichts" entfernt als Du.

Dann lies die vorigen Posts nochmals durch und fang erstmal an meine Fragen zu beantworten, anstatt dass wir konstant um den Brei reden.

Du hast meine originale Frage versucht zu beantworten und ich fuegte eine weitere Datenquelle zum CB benchmark hinzu der die CB-VS-Limitierungs-These erstmal nicht unterstuetzt.

Wenn Du lieber der Meinung bist, dass die VS in Oblivion stets völlig unbedeutend seien, dann bitte. Aber erwarte bitte nicht, dass ich mich dem anschließe, solange Du Deine "Argumentation" nicht ergänzt oder zumindest eine andere Erklärung für die CB- Ergebnisse lieferst. Vlt. gibt es ja Unterschiede zwischen RV515/ 530, die ich nicht kenne oder nicht bedacht habe.

Eine These waere ganz einfach CPU Limitierung.

Was soll zwischen der X1300 und X1600 genau sein? Die letztere ist in 1280 ohne AA/AF um ca. zweimal so schnell. Wieviele ALUs hat die eine und wieviele die andere?

Noch genauer ein weiteres Beispiel (laut CB):

Oblivion
1280 noAA/AF:

7900GTX = 34,8 fps
X1800XT = 37,2 fps

--------------------------------------------------------------

7900GTX = 8 VS * 700MHz / 4 = 1400 MVertices/s
X1800XT = 8 VS * 650MHz / 4 = 1300 MVertices/s

http://www.computerbase.de/artikel/hardware/grafikkarten/2006/test_asus_en7600gt_silent_en7900gt_top/7/#abschnitt_3dmark05

3dfart05:

7900GTX = 9457
X1800XT = 8090

Und hier machen den Unterschied nicht nur die VS; man kann leicht sehen dass 3dmark05 auch von zusaetzlicher ALU-Staerke profitiert von dem Resultat der X1900XTX.

Woran siehst Du das? Natürlich hast Du recht, aber mich würde mal interessieren, was für eine "Dokumentation" Dich davon überzeugen kann. Du meinst wahrscheinlich Vertex Shader und nicht Triangle Setup?

Ja ich meine vertex setup. An was ich es sehen kann? An zahllosen Ergebnissen seit seiner Vorstellung:

http://www.techreport.com/etc/2004q3/3dmark05/index.x?pg=5


Natürlich begrenzt viel häufiger Fragment- als Geometrieleistung. Es gibt mMn kaum etwas Unwichtigeres an einer Grafikkarte als die Anzahl der VS. Oblivion ist auch das einzige praktische Beispiel für eine Bedeutung der VS, das mir einfällt :wink:

Ob sich USCs für 3D- Berechnungen lohnen, kann ich nicht sagen, weil ich nicht weiß, wieviele Transistoren man dafür zusätzlich benötigt. Ich glaube jedenfalls auch kaum, dass es dadurch plötzlich einen Sprung bei der Geometriekomplexität geben wird, aber es ist sicherlich nicht schlecht, den Entwicklern diese Möglichkeit an die Hand zu geben. Die eigentlich strittige Frage war aber doch afair die Rolle der VS in Oblivion?

Nein ich fragte wo VS in heutigen Spielen limitieren und die Frage war deutlich mit USCs verbunden.

[reunion]

Welcome to the Inquirer:
http://www.the-inquirer.net/default.aspx?article=32769
http://www.the-inquirer.net/default.aspx?article=32769

[reunion]

aths[/POST]']Wenn die Texturlast zu hoch wird, stallt natürlich auch die Radeon-Pipeline.

Aber?
So wie ich das verstanden habe, sind die nV-Chips auf ein bestimmtes ALU/TEX-Verhältnis angewiesen, um ein stallen der Pipeline zu verhindern, während dies bei ATi nicht der Fall sein soll.

[Godmode]

reunion[/POST]']Welcome to the Inquirer:
http://www.the-inquirer.net/default.aspx?article=32769
http://www.the-inquirer.net/default.aspx?article=32769

Da bin ich mal gespannt, ich dachte immer der G80 kommt eher nach dem R600?

[Demirug]

reunion[/POST]']Aber?
So wie ich das verstanden habe, sind die nV-Chips auf ein bestimmtes ALU/TEX-Verhältnis angewiesen, um ein stallen der Pipeline zu verhindern, während dies bei ATi nicht der Fall sein soll.

Das ALU/TEX Verhältnis spielt dabei nur in so fern eine Rolle ob man etwas von den Stalls bemerkt. Solange jedes VLIW einen Tex Befehl enthält spielt es keine Rolle. Sobald man VLIW ohne Tex Anweisungen im Shadercode hat und mehr als ein Sample bei den Texturen braucht bremst der Chip.

[reunion]

Demirug[/POST]']Das ALU/TEX Verhältnis spielt dabei nur in so fern eine Rolle ob man etwas von den Stalls bemerkt. Solange jedes VLIW einen Tex Befehl enthält spielt es keine Rolle. Sobald man VLIW ohne Tex Anweisungen im Shadercode hat und mehr als ein Sample bei den Texturen braucht bremst der Chip.

Mhm, dankeschön. Das habe ich dann wohl falsch verstanden.

[Coda]

reunion[/POST]']Aber?
So wie ich das verstanden habe, sind die nV-Chips auf ein bestimmtes ALU/TEX-Verhältnis angewiesen, um ein stallen der Pipeline zu verhindern, während dies bei ATi nicht der Fall sein soll.
Bei nV stallt ein Texturzugriff immer (wobei stallen eigentlich das falsche Wort ist, weil die TMU eben Bestandteil der Pipeline ist). Bei ATi kann man nebenläufige Sachen machen, aber es ist wohl eher selten der Fall dass man wirklich 16 Takte was zu tun hat im Falle eines vollen AF-Filterings.

[Gast]

Nvidia G80 is taped out

http://www.the-inquirer.net/default.aspx?article=32768

[aths]

Coda[/POST]']Bei nV stallt ein Texturzugriff immer (wobei stallen eigentlich das falsche Wort ist, weil die TMU eben Bestandteil der Pipeline ist).Ein bilineares Sample stallt nicht. Ob trilineare oder anisotrope Samples stallen, hängt nach meiner Information von der Sortierung des Shadercodes ab. Dieser wird allerdings so sortiert, als würde ein Texturzugriff ein bilineares Sample sein, dauert es länger, kommt es zum Stall.

[aths]

reunion[/POST]']Aber?
So wie ich das verstanden habe, sind die nV-Chips auf ein bestimmtes ALU/TEX-Verhältnis angewiesen, um ein stallen der Pipeline zu verhindern, während dies bei ATi nicht der Fall sein soll.Dieser Gedanke kann ja prinzipiell schon nicht richtig sein. Vereinfachen wir mal stark dass wir erstens nur Texturen bilinear isotrop filtern und zweitens, dass wir bei der GF 2 ALUs pro Pixelpipe haben und bei der Radeon 3 ALUs. Vereinfachen wir weiter, dass jede ALU-Op pro ALU nur 1 Takt braucht. Wenn man bei der GeForce einen Shader hat, der dies nutzt:

Tex, Alu, Alu, Tex, Alu, Alu, ...

läuft die Pipe offenbar ohne Stall. Wäre es Tex, Tex, Alu, Alu, Alu, Alu wäre die Effizienz aber geringer. Nicht nur das Verhältnis der Anweisungen spielt eine Rolle, auch die Sortierung im "Micro-Code". (Tatsächlich sitzt die Tex-Unit zwischen zwei ALUs, so weit will ich hier aber nicht ins Detail gehen.)

Wenn man den Tex, Alu, Alu, Tex, Alu, Alu, ... -Shader auf der Radeon laufen lässt, sind die ALUs unterausgelastet. Die Tex-Unit stallt dann praktisch die ALUs. Bei der Radeon muss das Verhältnis zwangsläufig auch eine Rolle spielen. Die Radeon hat aber mehr Möglichkeiten, mit schlecht sortiertem Code noch eine gute Auslastung zu erreichen.

[Gast]

http://www.computerbase.de/news/hardware/grafikkarten/nvidia/2006/juli/hat_nvidias_g80_tape-out/

"Soweit nichts neues. Allerdings soll das Verhältnis der Pixel- und Vertex-Einheiten (hinzu kommt noch der für Direct3D 10 neue Geometry-Shader) bei zwei zu eins liegen. Sprich, wenn beispielsweise 24 Shader-Einheiten Pixelberechnungen ausführen können, sind zwölf Einheiten für Vertex- und Geometrieberechnungen zuständig."

Allerdings nicht Unified Shader....
Was soll das bringen, wenn die Vertex Leistung kaum limitiert ?

[Coda]

aths[/POST]']Ein bilineares Sample stallt nicht.
Ja ok.

aths[/POST]']Ob trilineare oder anisotrope Samples stallen, hängt nach meiner Information von der Sortierung des Shadercodes ab.
Ne tuts nicht. Wie Demirug schon sagte, wenn das TEX eines VLIW-Befehls länger als 1 Takt braucht stallt es.

[aths]

Coda[/POST]']Ne tuts nicht. Wie Demirug schon sagte, wenn das TEX eines VLIW-Befehls länger als 1 Takt braucht stallt es.Das sagt Demirug. Ich kenne zwei Leute die auch nicht dumm sind, die was anderes sagen.

[Coda]

aths[/POST]']Das sagt Demirug. Ich kenne zwei Leute die auch nicht dumm sind, die was anderes sagen.
Der Shaderprofiler von nVIDIA sagt das beim Cycles-Output aber genau so.

[aths]

Coda[/POST]']Der Shaderprofiler von nVIDIA sagt das beim Cycles-Output aber genau so.Der Code wird ja auch so sortiert, als würde jedes Tex nur ein bilineares Sample zur Folge haben. Das ist notwendig, weil die vier Temp-Register nicht üppig sind. Im Texturcache kann man vielleicht ein einzelnes Texel (pro Pixel und Quadbatch) halten. Gehen die Temp-Register aus, stallt die Pipe sowieso da "Blasen" eingeschoben werden müssen.

[Godmode]

Gast[/POST]']http://www.computerbase.de/news/hardware/grafikkarten/nvidia/2006/juli/hat_nvidias_g80_tape-out/

"Soweit nichts neues. Allerdings soll das Verhältnis der Pixel- und Vertex-Einheiten (hinzu kommt noch der für Direct3D 10 neue Geometry-Shader) bei zwei zu eins liegen. Sprich, wenn beispielsweise 24 Shader-Einheiten Pixelberechnungen ausführen können, sind zwölf Einheiten für Vertex- und Geometrieberechnungen zuständig."

Allerdings nicht Unified Shader....
Was soll das bringen, wenn die Vertex Leistung kaum limitiert ?

Vielleicht werden die VS ja als Geometry-Shader missbraucht?

[reunion]

Coda[/POST]']Bei nV stallt ein Texturzugriff immer (wobei stallen eigentlich das falsche Wort ist, weil die TMU eben Bestandteil der Pipeline ist). Bei ATi kann man nebenläufige Sachen machen, aber es ist wohl eher selten der Fall dass man wirklich 16 Takte was zu tun hat im Falle eines vollen AF-Filterings.

Hm, das würde bedeuten, dass die gesamte Pipeline bei 16xAF pro Texel 32 Takte blockiert wird, ehe sie weiterarbeiten kann. Korrekt?

aths[/POST]']Dieser Gedanke kann ja prinzipiell schon nicht richtig sein. Vereinfachen wir mal stark dass wir erstens nur Texturen bilinear isotrop filtern und zweitens, dass wir bei der GF 2 ALUs pro Pixelpipe haben und bei der Radeon 3 ALUs. Vereinfachen wir weiter, dass jede ALU-Op pro ALU nur 1 Takt braucht. Wenn man bei der GeForce einen Shader hat, der dies nutzt:

Tex, Alu, Alu, Tex, Alu, Alu, ...

läuft die Pipe offenbar ohne Stall. Wäre es Tex, Tex, Alu, Alu, Alu, Alu wäre die Effizienz aber geringer. Nicht nur das Verhältnis der Anweisungen spielt eine Rolle, auch die Sortierung im "Micro-Code". (Tatsächlich sitzt die Tex-Unit zwischen zwei ALUs, so weit will ich hier aber nicht ins Detail gehen.)

Wenn man den Tex, Alu, Alu, Tex, Alu, Alu, ... -Shader auf der Radeon laufen lässt, sind die ALUs unterausgelastet. Die Tex-Unit stallt dann praktisch die ALUs. Bei der Radeon muss das Verhältnis zwangsläufig auch eine Rolle spielen. Die Radeon hat aber mehr Möglichkeiten, mit schlecht sortiertem Code noch eine gute Auslastung zu erreichen.

Mhm, das hört sich auch plausibel an.

[Demirug]

reunion[/POST]']Hm, das würde bedeuten, dass die gesamte Pipeline bei 16xAF pro Texel 32 Takte blockiert wird, ehe sie weiterarbeiten kann. Korrekt?

Das man bei 16x AF 32 Samples braucht kommt äusserst selten vor. Aber ansonsten stimmt es und ich konnte bis heute keinen Pixelshader finden bei dem das nicht so wäre.

Solange man an der Texelfüllrate hängt (also pro VLIW ein Tex Befehl hat) merkt man davon nichts.

[aths]

reunion[/POST]']Hm, das würde bedeuten, dass die gesamte Pipeline bei 16xAF pro Texel 32 Takte blockiert wird, ehe sie weiterarbeiten kann. Korrekt?Jede AF-Implementierung ist adaptiv. Bei trilinearem 16xAF und einer Textur, die im 2:1-Verhältnis verzerrt ist, dauert das Sampling nur 4 Takte, da für dieses Quad nur 2x AF zum Einsatz kommt. 16x AF tatsächlich zu nutzen kommt also generell nur selten vor, da es kaum Texturen gibt, die so stark verzerrt gerendert werden. Auf der GeForce6/7 ist es, wie auf älteren ATI-Grakas, ja zusätzlich so, dass der Maximalgrad nur winkelabhängig überhaupt erlaubt wird. Nur bei 90° und 45°-Winkeln wird bis zu 16x AF als Maximalgrad erlaubt.

Dann hat die GeForce 7 vermutlich einen Mechanismus, jedenfalls vermutet Demirug das, dass man AF nach Möglichkeit mit weniger iostropen Samples realisiert wird, als der Grad angibt. Bei 4x AF bräuchte man nach dem Lehrbuch ja 4 isotrope (also bilineare oder trilineare) Samples. Allerdings überdecken sich da fast immer auch Texel. Es ist denkbar, weniger isotrope Samples zu nehmen und sie so anzuordnen, dass sich keine Texel mehr überdecken. Damit kann man also Füllrate sparen, allerdings sind die im Hintergrund stehenden Rechnungen aufwändig.

reunion[/POST]']Mhm, das hört sich auch plausibel an.Man fragt sich natürlich, warum Nvidia nicht auch schon lange auf stärkere TMU-ALU-Entkopplung setzt. Offensichtlich kann Nvidia die Quatchbatch-Pipelines aber vergleichsweise transistorsparend implementieren, und gleicht den Effizienznachteil mit einer breiteren Architektur aus. Die GF kann damit manchmal höhere Spitzenwerte erreichen, die Radeon kann konstantere Leistung bringen. Geht es um ALU-Leistung, ist die Radeon nicht zuletzt der feineren Granularität im Dynamic Branching ohnehin im Vorteil. Gehts um Texelleistung, hat die GF mehr zu bieten – erst recht bei FP16-Filterung, was auf der Radeon im Pixelshader aufwändig nachgestellt werden muss. Ich halte das TMU:ALU-Verhältnis von 1:3 für etwas zu verfrüht, aber wenn man "zu viel" Pixelshader-Leistung hat, gibts keinen Grund zu meckern – zumal die Texturleistung dank "Area-AF" auch sinnvoll in Qualität umgesetzt werden kann.

[Hvoralek]

Ailuros[/POST]']Was genau schliesst mir aus dass die CPU hier nicht limitiert? [Anm.: zum TR- Benchmark]Dort liegt eine 7900 GTX rund 40% vor einer 7900 GT, bei 44% höherem Takt. Da spielt die CPU offensichtlich kaum eine Rolle.

Dann lies die vorigen Posts nochmals durch und fang erstmal an meine Fragen zu beantworten, anstatt dass wir konstant um den Brei reden.Nochmal durchgelesen. Die einzige konkrete Farge Deinerseits an mich, die ich finden konnte, ist (wiederholt), ob in dem TR- Benchmark ein Hinweis auf VS- Limitierung zu finden sei. Antwort erneut: Nein, ich sehe keinen. Vlt. bin ich auch einfach zu blöd; wenn Du auf andere Fragen angespielt hast, sage bitte genauer, was Du meinst :frown:

Ich sehe aber auch nicht ganz, warum Du ständig auf dem (ohnehin nicht umstrittenen) TR- Test herumreitest. Deine Behauptung, die VS seien in Oblivion stets völlig gleichgültig, wäre bereits mit einem einzigen Benchmark mit klarer Geometrielimitierung widerlegt. Und genau dafür sehe ich im CB- Benchmark deutliche Anzeichen (an anderen Stelle als bei TR und mit anderen Einstellungen). Daran ändert sich auch nichts, wenn Du jetzt noch fünf oder sechs Tests findest, in denen nicht eindeutig eine VS- Limitierung vorliegt (Am besten noch mit einem ebenso dürftig zur Beurteilung einer VS- Limitierung geeigneten Testfeld wie bei TR). Daran ändert sich selbst dann nichts, wenn Du einen Benchmark (wieder mit einer anderen Stelle im Spiel) findest, in dem eindeutig nicht eine VS- Limitierung vorliegt. Das würde bloß zeigen, dass Oblivion nicht stets geometrielimitiert ist. Das habe ich aber nicht behauptet und halte es auch für kaum denkbar, auf keinen Fall in Innenräumen.

Du hast meine originale Frage versucht zu beantworten und ich fuegte eine weitere Datenquelle zum CB benchmark hinzu der die CB-VS-Limitierungs-These erstmal nicht unterstuetzt.Deine Quelle liefert in der Tat keine Indizien für eine durchgehende VS- Limitierung in Oblivion - die ich aber auch nie behauptet habe. Ich habe ursprünglich gesagt, das "könne vlt. mal vorkommen", was Du mit einem Benchmark, der meine Ansicht lediglich nicht offensichtlich bestätigt (wobei nicht einmal erkennbar ist, dass die VS in dem Fall keine Rolle spielen), mMn nicht wirklich widerlegt hast.

Eine These waere ganz einfach CPU Limitierung. [Anm.: zum CB- Benchmark]Die CPU spielt ja schon bei den größeren Karten offensichtlich keine nennenswerte Rolle, dafür sind die Abstände zwischen denen zu groß. Und wenn schon bei schnellen Karten die CPU nicht limitiert, tut sie das bei den kleinen Modellen erst recht nicht. Auch dort sprächen sehr kleine Abstände für eine CPU- Limitierung.

Was soll zwischen der X1300 und X1600 genau sein? Die letztere ist in 1280 ohne AA/AF um ca. zweimal so schnell. Wieviele ALUs hat die eine und wieviele die andere?Fragment: 12 bzw. 4
Vertex: 5 bzw. 2

Ansonsten geben sich die Karten afaik nicht viel. Dieselbe Architektur, sehr ähnliche sonstige Eckdaten. Der Unterschied kann afaics nur aus den beiden obigen Punkten resultieren (Nochmal: Falls ich etwas übersehen habe, bitte um Korrektur).

Die X1800XT und X1900XT liegen fast gleichauf. Der einzige wichtige Unterschied zwischen den beiden ist ja die dreifache Fragment- Leistung der letzteren; die spielt hier also keine große Rolle.

Bleibt als Erklärung für den Vorsprung der X1600 noch die Geometrieleistung. Woher soll der sonst kommen (Ernst gemeinte Frage, die Größe des Vorsprungs erstaunt mich nämlich)?

Noch genauer ein weiteres Beispiel (laut CB):

Oblivion
1280 noAA/AF:

7900GTX = 34,8 fps
X1800XT = 37,2 fps

--------------------------------------------------------------

7900GTX = 8 VS * 700MHz / 4 = 1400 MVertices/s
X1800XT = 8 VS * 650MHz / 4 = 1300 MVertices/sDir ist aber klar, dass R520 und G71 völlig unterschiedliche Architekturen sind? Wenn Du aus diesem (auch noch geringen) Unterschied bei der rechnerischen Geometrieleistung auf diese Weise Schlüsse ziehen würdest, könnte man ja HL 2 (http://www.computerbase.de/artikel/hardware/grafikkarten/2006/test_asus_en7600gt_silent_en7900gt_top/13/#abschnitt_hl2_lost_coast) oder Chronicles of Riddick (http://www.computerbase.de/artikel/hardware/grafikkarten/2006/test_asus_en7600gt_silent_en7900gt_top/16/#abschnitt_the_chronicles_of_riddick) als VS- Limitiert betrachten - da liegt ja die 7900 GTX vorne und die hat ja ein paar VS- Takte/s mehr... :rolleyes:


http://www.computerbase.de/artikel/hardware/grafikkarten/2006/test_asus_en7600gt_silent_en7900gt_top/7/#abschnitt_3dmark05

3dfart05:

7900GTX = 9457
X1800XT = 8090

Und hier machen den Unterschied nicht nur die VS; man kann leicht sehen dass 3dmark05 auch von zusaetzlicher ALU-Staerke profitiert von dem Resultat der X1900XTX.Ich kann im Prinzip auf oben verweisen: Ist jeder Benchmark, bei dem eine 7900 GTX vorne liegt, wegen derer 7% höheren rechnerischen Geometrieleistung VS- limitiert?

Im Fall 3DMark05 legen die Ergebnisse eine Geometrielimitierung wirklich nahe - Wie ich finde, aber (neben den in einigen Passagen anscheinend sehr zahlreichen Polygonen) eher der Vergleich X1800 XT - 7800 GTX/ 7900 GT. Die XT liegt da ja deutlich vorne, obwohl sie bis auf die wesentlich höhere Geometrieleistung von den Eckdaten her kaum über Vorteile verfügt.

Auch da bleibt aber das Problem, aus einem Vergleich von Karten deutlich unterschiedlicher Architekturen Rückschlüsse auf die Anforderungen einer Anwendung zu ziehen, was ohne weitere Tests kaum gesichert gehen wird (siehe Oblivion: Von den Eckdaten her liegt die 7900 GTX fast überall vor der 1800XT, ist im Ergebnis aber in dem Fall sogar etwas langsamer).

Was mich am Ende wirklich überzeugt hat, war ein weiterer Test. Eine Seite (ich habe gerade nochmal danach gesucht, finde den Artikel leider nicht mehr) hatte bei einer 7800GTX zwei Quads deaktiviert und diese sowie eine X1800XT auf dasselbe Niveau getaktet. Man hatte also einen G70 und einen R520, beide mit vier Quads und 8 VS @ 430 MHz. Ergebnis: Beide lagen praktisch gleichauf.

Eine X1800 XT@ Standard und eine 7800 GTX @ Standard verfügen nun beide über rund 50% mehr Füllrate/ Fragmentleistung (die XT wegen höherem Takt; die GTX wegen mehr Quads), bei der XT liegt aber zusätzlich die Geometrieleistung 50% höher - mit dem bekannten Vorsprung. Solche Überlegungen finde ich überzeugender als einfach auf Balken zu gucken, ob die Karte, die vorne liegt, nun 7% Geometrieleistung mehr oder weniger hat. Auch das kann funktionieren. Aber nur, wenn

1. Die betreffenden Karten auf derselben oder wenigstens einer sehr ähnlichen Architektur basieren und
2. die sonstigen Eckdaten der Karten entweder gleich oder sehr ähnlich sind oder man andernfalls die Auswirkungen der Unterschiede mitbedenkt. Das setzt natürlich zumindest voraus, dass man deren Auswirkungen abschätzen kann.

R520 und G71 sind nun zwei deutlich unterschiedliche Architekturen, und die weiteren Eckdaten der von Dir angeführten Karten unterscheiden sich deutlich. Die Geometrieleistung ist mit nur 7% rechnerischem Vorsprung für die Geforce sogar noch einer der Bereiche mit den kleinsten Unterschieden (ggü. etwa 50% bei der Füllrate oder noch erheblich mehr bei der Fragmentleistung)

Nein ich fragte wo VS in heutigen Spielen limitieren und die Frage war deutlich mit USCs verbunden.Ich hatte mich nur gewundert, weil es bei uns eigentlich um "VS und Oblivion" ging und weniger um "VS und USC". Aber gut, in dem Bereich scheinen ja keine nennenswerten Meinungsverschiedenheiten zu bestehen.

[Ailuros]

Wobei der letzte Paragraph von aths oben der Schluessel fuer die moegliche G80 und/oder R6x0 Leistung sein koennte.

[Ailuros]

Hvoralek[/POST]']Dort liegt eine 7900 GTX rund 40% vor einer 7900 GT, bei 44% höherem Takt. Da spielt die CPU offensichtlich kaum eine Rolle.

War auf den CB und nicht TR Benchmark bezogen.


Ich sehe aber auch nicht ganz, warum Du ständig auf dem (ohnehin nicht umstrittenen) TR- Test herumreitest. Deine Behauptung, die VS seien in Oblivion stets völlig gleichgültig, wäre bereits mit einem einzigen Benchmark mit klarer Geometrielimitierung widerlegt.

Nirgends sagte ich dass die VS in Oblivion oder irgendeinem anderem Spiel gleichgueltig sind oder nur dumm rumhocken. Heutige Spiele sind einfach nicht VS-limitiert.


Deine Quelle liefert in der Tat keine Indizien für eine durchgehende VS- Limitierung in Oblivion - die ich aber auch nie behauptet habe. Ich habe ursprünglich gesagt, das "könne vlt. mal vorkommen", was Du mit einem Benchmark, der meine Ansicht lediglich nicht offensichtlich bestätigt (wobei nicht einmal erkennbar ist, dass die VS in dem Fall keine Rolle spielen), mMn nicht wirklich widerlegt hast.

Siehe oben. Eine VS Limitierung wuerde bedeuten, dass sich beide IHVs fundamental unterschaetzt haben bei ihren Design-entscheidungen und man koennte dieses auch in heutigen Spielen sehen. Es gibt 48 PS ALUs auf der R580 und "nur" 8 VS Einheiten. Die letzteren werden zwar ausgelastet, aber so wie diese Designs ausgelegt sind (und das trifft fuer G7x genauso zu) sehe ich nichts dass auf besonders unbalanzierte Designs deuten wuerde; und das natuerlich nur im Sinn dass diesen GPUs an VS-Leistung fehlt.

Die CPU spielt ja schon bei den größeren Karten offensichtlich keine nennenswerte Rolle, dafür sind die Abstände zwischen denen zu groß. Und wenn schon bei schnellen Karten die CPU nicht limitiert, tut sie das bei den kleinen Modellen erst recht nicht. Auch dort sprächen sehr kleine Abstände für eine CPU- Limitierung.

Nur 2 fps Abstand zwischen einer X1800XT und einer X1900XTX ist mir ein bisschen zu wenig dass der spezifische Test GPU-limitiert sein koennte.

Fragment: 12 bzw. 4
Vertex: 5 bzw. 2

Ansonsten geben sich die Karten afaik nicht viel. Dieselbe Architektur, sehr ähnliche sonstige Eckdaten. Der Unterschied kann afaics nur aus den beiden obigen Punkten resultieren (Nochmal: Falls ich etwas übersehen habe, bitte um Korrektur).

Die X1800XT und X1900XT liegen fast gleichauf. Der einzige wichtige Unterschied zwischen den beiden ist ja die dreifache Fragment- Leistung der letzteren; die spielt hier also keine große Rolle.

Bleibt als Erklärung für den Vorsprung der X1600 noch die Geometrieleistung. Woher soll der sonst kommen (Ernst gemeinte Frage, die Größe des Vorsprungs erstaunt mich nämlich)?

RV515 und R520 gehoeren zur gleichen Familie, genauso wie RV530 und R580.

RV515 ist sowieso an allen Enden so kastriert weil er eben das absoluteste low-end darstellt.

While RV530 features 3 quads of Pixel Shader processors these are still organised in a "single processing block" so that while the Pixel Shader width is widened in comparison to RV515 it is still operating over 128 pixel "threads". The net result here is that the block size of those threads is also increased from 16 to 48 pixels per thread, which lowers the efficiency of dynamic branching in relation to RV515 and R520, but should never result in a performance that is lower.

Both RV530 and RV515 utilise 128-bit memory buses, given that they are both addressing the lower end of the graphics market, however while the external bus widths are the same, internally they both have different buses. RV530 adopts a similar Ring Bus mechanism as R520, but in this case the alternate direction ring buses are both 128-bit in width as opposed to 256-bit, with 4 memory controllers allowing for 32-bit access granularity. Due to the size of the ring bus requirements, RV515 utilises a more traditional crossbar mechanism, although unlike previous Radeons 4 controllers are used, again giving 32-bit granularity for the 4 memory channels, which allows for more flexibility with HyperMemory configurations. Other memory optimisations featured in R520, such as fully associative caches, Hierarchical Z buffer test, Z compression and anti-aliasing colour compression are all present on both RV530 and RV515.

http://www.beyond3d.com/reviews/ati/rv5xx/

Zwar nicht direkt zu den CB Resultaten verbunden, aber ich ernsthafte Zweifel dass die RV530 hier doppelt so hohe Leistung landet nur wegen der mehr VS Einheiten. Uebrigens heisst das unterm Strich auch dass sowohl RV515 als auch RV530 genug VS Einheiten haben, fuer das was sie sonst leisten koennen.


Dir ist aber klar, dass R520 und G71 völlig unterschiedliche Architekturen sind? Wenn Du aus diesem (auch noch geringen) Unterschied bei der rechnerischen Geometrieleistung auf diese Weise Schlüsse ziehen würdest, könnte man ja HL 2 (http://www.computerbase.de/artikel/hardware/grafikkarten/2006/test_asus_en7600gt_silent_en7900gt_top/13/#abschnitt_hl2_lost_coast) oder Chronicles of Riddick (http://www.computerbase.de/artikel/hardware/grafikkarten/2006/test_asus_en7600gt_silent_en7900gt_top/16/#abschnitt_the_chronicles_of_riddick) als VS- Limitiert betrachten - da liegt ja die 7900 GTX vorne und die hat ja ein paar VS- Takte/s mehr... :rolleyes:

Nein. G7x landen bessere Leistung mit float HDR (stets ohne AA natuerlich) und im gegebenen Fall von Lost Coast dem quasi pseudo float HDR.

Zweitens ist Chronicles ein OpenGL game. Seit den paar Optimierungen fuer AA in R5xx von ATI laufen zwar OGL Spiele deutlich besser als zuvor, aber dass heisst immer noch nicht dass NVIDIA generell mit OGL nicht schneller ist.


Ich kann im Prinzip auf oben verweisen: Ist jeder Benchmark, bei dem eine 7900 GTX vorne liegt, wegen derer 7% höheren rechnerischen Geometrieleistung VS- limitiert?

Nein. 3dmark05 ist eben vertex setup limitiert. Es ist zwar nett sich im Kreis zu drehen mit dieser sinnlosen Diskussion, aber heutige Spiele sind nicht und auch nicht vielleicht VS limitiert.

Die Anzahl der Geometrie-Einheiten in G80 wird hoechstwahrscheinlich ansteigen aber nur weil diese nicht nur ueber VS faehig sein werden. ;)



Was mich am Ende wirklich überzeugt hat, war ein weiterer Test. Eine Seite (ich habe gerade nochmal danach gesucht, finde den Artikel leider nicht mehr) hatte bei einer 7800GTX zwei Quads deaktiviert und diese sowie eine X1800XT auf dasselbe Niveau getaktet. Man hatte also einen G70 und einen R520, beide mit vier Quads und 8 VS @ 430 MHz. Ergebnis: Beide lagen praktisch gleichauf.

Ja und? Der Test war sowieso nutzlos weil GPUs so ausgelegt werden wie sie verkauft werden. Und nein die R520 wurde nicht mit 430MHz vermarktet. Fuer reine synthetische Experimente mag es vielleicht etwas Nutzen haben, aber es sagt mir zum Thema gar nichts aus.

Etwas OT Marketing-Geblubber in der Zwischenzeit:

http://www.elitebastards.com/cms/index.php?option=com_content&task=view&id=69&Itemid=29&limit=1&limitstart=1

In anderen Worten der Zukunft kann man schon mehr Geometrie zuschreiben weil eben auch GPUs faehiger werden in dieser Abteilung. Momentan waren und sind Entwickler immer noch verdammt vorsichtig ihre Spiele mit zu hoher Geometrie nicht zu ueberlasten.

[LordDeath]

Hvoralek[/POST]']Fragment: 12 bzw. 4
Vertex: 5 bzw. 2

Ansonsten geben sich die Karten afaik nicht viel. Dieselbe Architektur, sehr ähnliche sonstige Eckdaten. Der Unterschied kann afaics nur aus den beiden obigen Punkten resultieren (Nochmal: Falls ich etwas übersehen habe, bitte um Korrektur).

Die X1800XT und X1900XT liegen fast gleichauf. Der einzige wichtige Unterschied zwischen den beiden ist ja die dreifache Fragment- Leistung der letzteren; die spielt hier also keine große Rolle.

Bleibt als Erklärung für den Vorsprung der X1600 noch die Geometrieleistung. Woher soll der sonst kommen (Ernst gemeinte Frage, die Größe des Vorsprungs erstaunt mich nämlich)?

es kann gut sein, dass bei der X1600 und der X1300 eben die pixelshaderleistung doch limitiert und ab einem gewissen punkt halt nicht mehr. und dann macht dies zwischen den R520 und den R580 keinen großen unterschied mehr.

[Hvoralek]

Ailuros[/POST]']Nirgends sagte ich dass die VS in Oblivion oder irgendeinem anderem Spiel gleichgueltig sind oder nur dumm rumhocken. Heutige Spiele sind einfach nicht VS-limitiert.Mit "gleichgültig" meinte ich nicht, dass die VS untätig sind oder dumm rumhocken, sondern dass sie bei heutigen GraKaen absolut keinen Einfluss auf die Gesamtleistung haben, weil stets irgendwelche anderen Komponenten komplett limitieren. In Oblivion scheint es aber einige Stellen zu geben, an denen das anders ist.

Siehe oben. Eine VS Limitierung wuerde bedeuten, dass sich beide IHVs fundamental unterschaetzt haben bei ihren Design-entscheidungen und man koennte dieses auch in heutigen Spielen sehen. Es gibt 48 PS ALUs auf der R580 und "nur" 8 VS Einheiten. Die letzteren werden zwar ausgelastet, aber so wie diese Designs ausgelegt sind (und das trifft fuer G7x genauso zu) sehe ich nichts dass auf besonders unbalanzierte Designs deuten wuerde; und das natuerlich nur im Sinn dass diesen GPUs an VS-Leistung fehlt.Ein Design kann immer nur relativ zu einer Anwendung/ konkreten Situation ausgewogen sein oder nicht. Wenn ein Chip an einer bestimmten Stelle in Spiel A ein ideales Verhältnis von TMUs/ VS/ PS bietet, mag bei Spiel B die Füllrate als erstes knapp werden und bei C vlt. die PS. Heutige Chips sind so ausgelegt, dass in aller Regel die VS nicht die anderen Einheiten ausbremsen - Sinnvoll, weil man nicht viele davon braucht und die ziemlich billig sind. Welche Komponenten aber tatsächlich am meisten gefordert werden, hängt davon ab, was die Entwickler genau machen.

Nur 2 fps Abstand zwischen einer X1800XT und einer X1900XTX ist mir ein bisschen zu wenig dass der spezifische Test GPU-limitiert sein koennte.Nur 5% Diff. zwischen den Karten sprechen auf den ersten Blick dafür. Allerdings gibt es noch die 7950, die noch einmal 20% schneller läuft. So ein geringer Vorsprung spricht wieder für eine zwar nicht extreme, aber erhebliche CPU- Limitierung? Würde es normalerweise, allerdings läuft das Teil dabei immer noch 85% schneller als eine einzelne 7900GT, also nicht weit von dem entfernt, was man als realistisches Maximum annehmen kann. Selbst ganz ohne CPU- Einfluss wäre viel mehr nicht erwarten. Der Einfluss der CPU ist an der Stelle also nicht großartig, bei den kleineren Karten ziemlich sicher nicht mehr spürbar.

Den geringen Abstand R580 - R520 erkläre ich über geringe Anforderungen an die PS an der Stelle (siehe Vorposting).

RV515 ist sowieso an allen Enden so kastriert weil er eben das absoluteste low-end darstellt.Welche Einschränkungen habe ich denn vergessen, die hier von Belang sein könnten?

http://www.beyond3d.com/reviews/ati/rv5xx/Das dyn. Branching des RV530 ist also ebenso "schlecht" wie das des R580 und er verfügt ggü. dem RV515 über einen Ring Bus statt einer Crossbar. Inwiefern ist das jetzt hier relevant? Die Fragment- Leistung ist ja anscheinend nicht das große Problem (und das würde sich ja nur auswirken, wenn Oblivion überhaupt von Branching profitieren würde). Der Speicherkontroller dürfte höchstens ein bisschen Bandbreite sparen. Meinst Du, dass sich damit dieser Abstand erklären lässt?

Zwar nicht direkt zu den CB Resultaten verbunden, aber ich ernsthafte Zweifel dass die RV530 hier doppelt so hohe Leistung landet nur wegen der mehr VS Einheiten.In den praktischen Tests würde mich jeglicher Einfluss der VS auf die Leistung erstaunen. Allerdings bleibt eine nahezu dreimal so hohe Fragmentleistung und - hier geht es um die X1600XT - eine knapp doppelt so hohe Bandbreite.

Uebrigens heisst das unterm Strich auch dass sowohl RV515 als auch RV530 genug VS Einheiten haben, fuer das was sie sonst leisten koennen.Bei beiden kommen 2 TMUs (und damit 2 bzw. 6 PS) auf einen VS. Das Verhältnis ist genau dasselbe wie bei R520 bzw. R580.

Wie gesagt reicht das in aller Regel auch völlig aus.

Nein. G7x landen bessere Leistung mit float HDR (stets ohne AA natuerlich) und im gegebenen Fall von Lost Coast dem quasi pseudo float HDR.Du meinst dieses quasi pseudo FX8- float? Ich weiß nicht sicher, was für Lightmaps da verwendet werden. Wenn das FP16 ist, hätten die nVidia- Karten einen Vorteil. Ich meine aber, zumindest auf Hardware, die FP16- Lightmaps per Shader filtern müsste, würde FX16 verwendet.

Zweitens ist Chronicles ein OpenGL game.Interessant, dann ist das Ergebnis klar (ich hatte das immer v.a. auf die Schaltungen für NRM_PP in NV4x zurückgeführt).

Das ist aber auch nicht wirklich wesentlich. Es gibt nun auch andere Fälle, in denen die 7900 GTX bei dem Vergleich vorne liegt und die sich natürlich alle irgendwie erklären lassen. Mir ging es darum, dass Du bei diesen Karten nicht einfach gucken kannst, wie die mit der höheren rechnerischen Geometrieleistung abschneidet, um zu beurteilen, wie wichtig die VS sind.

Nein. 3dmark05 ist eben vertex setup limitiert.Und das siehst Du außer am Vorsprung der 7900 GTX vor der X1800XT woran genau? An sehr vielen Tests, bei denen das Ergebnis immer so ausfällt? Für solche Aussagen habe ich gerne eine logische und präzise Argumentation. Das ist aber vlt. eine Frage der Überzeugung.

Ja und? Der Test war sowieso nutzlos weil GPUs so ausgelegt werden wie sie verkauft werden. Und nein die R520 wurde nicht mit 430MHz vermarktet. Fuer reine synthetische Experimente mag es vielleicht etwas Nutzen haben, aber es sagt mir zum Thema gar nichts aus.Im Gegenteil. Zur Beurteilung gerade der Nutzung bestimmter Komponenten eignen sich, wenn man nicht zufällig geeignete Serienmodelle hat (etwa X1800XT/ 1900XT für Frament- Leistung), derartige Tests ganz gut. Wo wird das Ergebnis dadurch verfälscht, dass beide Modelle im Original eine 50% höhere Textur- und PS- Leistung haben, aber ATI dies durch höheren Takt erreicht, nVidia hingegen durch eine breitere Architektur?

Noch besser wäre es natürlich, dieselbe Karte mehrmals zu testen und dabei Teile der betroffenen Komponente (hier also einen oder mehrere VS) zu deaktivieren.

Etwas OT Marketing-Geblubber in der Zwischenzeit:

http://www.elitebastards.com/cms/index.php?option=com_content&task=view&id=69&Itemid=29&limit=1&limitstart=1

In anderen Worten der Zukunft kann man schon mehr Geometrie zuschreiben weil eben auch GPUs faehiger werden in dieser Abteilung. Momentan waren und sind Entwickler immer noch verdammt vorsichtig ihre Spiele mit zu hoher Geometrie nicht zu ueberlasten.Und meinst Du nicht, dass es bei einem Spiel, das auch für R500 entwickelt wurde, sein könnte, dass die Entwickler sich für verhältnismäßig viele Polygone entschieden haben?

Es ist zwar nett sich im Kreis zu drehen mit dieser sinnlosen Diskussion, aber heutige Spiele sind nicht und auch nicht vielleicht VS limitiert.Du hast recht: Diese Debatte können wir uns eigentlich sparen. Wenn Du ein "zum allergrößten Teil" oder "fast ausschließlich" in Deinen letzten Halbsatz einfügst, könnte ich ihn sogar ohne weiteres unterschreiben. Im Ergebnis ist das aber ohnehin nicht relevant, weil auch nach meiner Auffassung die VS in der Praxis jedenfalls so unerheblich sind, dass Leistungszuwächse durch USC fast nur durch Verschieben in Richtung PS zu erreichen wären - und damit eben nur in eher bescheidenem Umfang.

es kann gut sein, dass bei der X1600 und der X1300 eben die pixelshaderleistung doch limitiert und ab einem gewissen punkt halt nicht mehr. und dann macht dies zwischen den R520 und den R580 keinen großen unterschied mehr.Warum sollte das so sein? Mit der Framerate steigen ja nicht nur die Anforderungen an die PS, sondern an alles andere auch.

[Gast]

Hvoralek[/POST]']Bei beiden kommen 2 TMUs (und damit 2 bzw. 6 PS) auf einen VS. Das Verhältnis ist genau dasselbe wie bei R520 bzw. R580.Nope. Sowohl RV515 als auch RV530 haben 4 TMUs, RV530 aber deutlich mehr Vertex Shader.

[Hvoralek]

Gast[/POST]']Nope. Sowohl RV515 als auch RV530 haben 4 TMUs, RV530 aber deutlich mehr Vertex Shader.Äh, natürlich. :redface: Was ich sagen wollte, ist, dass das TMU- VS- Verhältnis bei RV515, R520 und R580 dasselbe ist (2:1), bei den beiden ersten auch das VS- PS-. Darum, dass RV530 mehr VS hat, geht es ja gerade.

[Quasar]

Hvoralek[/POST]']

Die X1800XT und X1900XT liegen fast gleichauf. Der einzige wichtige Unterschied zwischen den beiden ist ja die dreifache Fragment- Leistung der letzteren; die spielt hier also keine große Rolle.

Daraus kannst du aber nicht ableiten, dass die Fragment-Leistung im Bereich der X1300/X1600 keine entscheidende Rolle spielt. Je nach Fps-Bereich verschieben sich doch auch die jeweiligen Flaschenhälse. Während CPU- und Vertexleistung im Bereich von 10 Fps vielleicht noch kaum eine Rolle spielen, sieht das zumindest für die CPU in Gegenden um 40 Fps schon anders aus.

[Hvoralek]

Quasar[/POST]']Während CPU- und Vertexleistung im Bereich von 10 Fps vielleicht noch kaum eine Rolle spielen, sieht das zumindest für die CPU in Gegenden um 40 Fps schon anders aus.Allzu groß scheint der aber nicht zu sein. Dazu habe ich mich auch schonmal geäußert (http://www.forum-3dcenter.org/vbulletin/showpost.php?p=4519780&postcount=618):

Nur 2 fps Abstand zwischen einer X1800XT und einer X1900XTX ist mir ein bisschen zu wenig dass der spezifische Test GPU-limitiert sein koennte.Nur 5% Diff. zwischen den Karten sprechen auf den ersten Blick dafür. Allerdings gibt es noch die 7950, die noch einmal 20% schneller läuft. So ein geringer Vorsprung spricht wieder für eine zwar nicht extreme, aber erhebliche CPU- Limitierung? Würde es normalerweise, allerdings läuft das Teil dabei immer noch 85% schneller als eine einzelne 7900GT, also nicht weit von dem entfernt, was man als realistisches Maximum annehmen kann. Selbst ganz ohne CPU- Einfluss wäre viel mehr nicht erwarten. Der Einfluss der CPU ist an der Stelle also nicht großartig, bei den kleineren Karten ziemlich sicher nicht mehr spürbar.

Den geringen Abstand R580 - R520 erkläre ich über geringe Anforderungen an die PS an der Stelle (siehe Vorposting).

[Quasar]

Ich sehe da jetzt nicht den Widerspruch zu dem was ich sagte. Dass eine 7950 GX2 85% schneller ist als eine 7900 GT heisst doch nicht, dass man in den Bereichen einer 7900 GT nicht noch weit vom CPU-Limit (oder einem anderen Limit) entfernt wäre.

[Ailuros]

Hvoralek[/POST]']
Und meinst Du nicht, dass es bei einem Spiel, das auch für R500 entwickelt wurde, sein könnte, dass die Entwickler sich für verhältnismäßig viele Polygone entschieden haben?

Mit R500 meinst Du wohl Xenos oder? Wenn ja dann ist die Antwort negativ. Relativ viele Polygone im Vergleich zu vorigen Consolen definitiv ja; im Vergleich zu heutigen high end GPUs dann aber wohl nicht. Wenn die Entwickler dann noch 4xMSAA in einem Spiel haben moechten ist noch vorsicht geboten.

***edit:

hab ich ja schon angedeutet in vorigen Posts:

http://www.forum-3dcenter.org/vbulletin/showpost.php?p=4520342&postcount=487

Du hast recht: Diese Debatte können wir uns eigentlich sparen. Wenn Du ein "zum allergrößten Teil" oder "fast ausschließlich" in Deinen letzten Halbsatz einfügst, könnte ich ihn sogar ohne weiteres unterschreiben. Im Ergebnis ist das aber ohnehin nicht relevant, weil auch nach meiner Auffassung die VS in der Praxis jedenfalls so unerheblich sind, dass Leistungszuwächse durch USC fast nur durch Verschieben in Richtung PS zu erreichen wären - und damit eben nur in eher bescheidenem Umfang.

Mir mangelt es momentan extrem an Zeit; wenn Du die Stellen zusammenfasst wo wir eigentlich uebereinstimmen, geht es hier eigentlich um Haarspalterei.

---------------------------------------------------

Zurueck zum eigentlichen Thema:

nao spekuliert auf B3D auf 16 GS/VS MIMDs und 32 PS SIMDs mit 32 entkoppelten TMUs. Irgend ein Kommentar? ;)

[Gast]

Ailuros[/POST]']Zurueck zum eigentlichen Thema:

nao spekuliert auf B3D auf 16 GS/VS MIMDs und 32 PS SIMDs mit 32 entkoppelten TMUs. Irgend ein Kommentar? ;)
Zu teuer, da sie die alten Einheiten dafür doch etwas aufbohren müssten und zusätzliche Logik für die separate Ansteuerung der TMUs aufwenden. Ich weiß zwar nicht, was ein GS "kosten" würde, aber mit so einem Setup könnte man sicher in den 450-500M-Transistoren-Bereich gelangen.

[ShadowXX]

Ailuros[/POST]']
Zurueck zum eigentlichen Thema:

nao spekuliert auf B3D auf 16 GS/VS MIMDs und 32 PS SIMDs mit 32 entkoppelten TMUs. Irgend ein Kommentar? ;)
Ja....er hat den INQ gelesen....genau diese Specs wurde nämlich von besagten Magazin vor ca. 3-4 Tagen gepostet (OK, da fehlten die entkoppelten TMUs aber irgendwas muss man ja ranhängen damits neu aussieht).

Gast[/POST]']Zu teuer, da sie die alten Einheiten dafür doch etwas aufbohren müssten und zusätzliche Logik für die separate Ansteuerung der TMUs aufwenden. Ich weiß zwar nicht, was ein GS "kosten" würde, aber mit so einem Setup könnte man sicher in den 450-500M-Transistoren-Bereich gelangen.
Es mag zwar vielleicht etwas teurer sein (obwohl ich mir da inzwischen gar nicht mehr so sicher bin, da Demi bei mir auf einen ähnlichen Post eher "negativ" reagierte), aber es ist wohl für nV die einfachere Lösung.

Und das Sie keine vollständige US-Architektur rausbringen kann man inzwischen als so gut wie zu 100% gesichert ansehen (und da bleibt dann nur noch PS + VS/GS übrig).

Ob die TMUs jetzt entkoppelt sind, glaube ich noch nicht ganz....könnte aber vorteilhaft für gewisse Features sein.

[Gast]

ShadowXX[/POST]']
Es mag zwar vielleicht etwas teurer sein (obwohl ich mir da inzwischen gar nicht mehr so sicher bin, da Demi bei mir auf einen ähnlichen Post eher "negativ" reagierte), aber es ist wohl für nV die einfachere Lösung.

Und das Sie keine vollständige US-Architektur rausbringen kann man inzwischen als so gut wie zu 100% gesichert ansehen (und da bleibt dann nur noch PS + VS/GS übrig).

Ob die TMUs jetzt entkoppelt sind, glaube ich noch nicht ganz....könnte aber vorteilhaft für gewisse Features sein.

Mit zu teuer meinte ich das Gesamtpaket aus 16 VS/GS, 32 PS und 32 entkoppelten TMUs.

[Winter[Raven]]

Gast[/POST]']Mit zu teuer meinte ich das Gesamtpaket aus 16 VS/GS, 32 PS und 32 entkoppelten TMUs.

Ist ja ganz witzig... Wie Demirug schon sagte, die Hasen wurden noch nicht erschoßen, geschweige davon, überhaupt gesichtet, ihr versucht Anhand von 0 Infos den Preis abzuschätzen... Respekt!

[ShadowXX]

Gast[/POST]']Mit zu teuer meinte ich das Gesamtpaket aus 16 VS/GS, 32 PS und 32 entkoppelten TMUs.
Ja, das war mir durchaus bewusst (bzw. das habe ich angenommen), aber nV hat ja fast keine andere Wahl.

Sie müssen gegen ATI Techdemos bzw. Messungen ankommen können, bei denen ATI extrem versuchen wird die vorteile Ihrer US-Architektur aufzuzeigen.
Die Dinger sind dann zwar mehr theoretischer Natur, aber wenn nV zuwenig PS oder zuwenig VS/GS implementiert, könnten diese Messungen katastrophal für nV aussehen.....selbst wenn es in Games völlig anders aussieht.

Gehen wir einfach mal davon aus, das nV nicht extra entkoppelte TMUs in den G80 "einhängen wird", sondern die jetzige Struktur beibehält.
Dann müssten Sie ja im Prinzip "nur" die G70/71 Architektur um ein Quad erhöhen und die VS um GS-Fähigkeiten erweitern (+ ein paar andere Änderungen -> Ja, mir ist klar das sich das einfacher anhört, als es gemacht werden kann).

Viel weniger (wenn überhaupt) Transistoren wird ATI für Ihre 64-Unified Shader auch nicht brauchen....speziell wenn man dann solchge Sachen im Vorfeld hört wie "heissester Chip ever" (bezogen auf den r600), was auch nicht unbedingt gerade auf wenig Transistoren schliessen lässt.

ATI benötigt momentan wesentlich mehr Transis für Ihren r580 als nV für Ihren G70....ATI wird (aus schon von Demi angemerkten Gründen) nicht das C1-Design als Grundlagen nehmen können, sondern wohl eher die "größeren" (aber auch leistungsfähigeren) r580 ALUs nehmen.
Dann noch HQAF + neu einzuführendes FP16 Filtering usw.
Ich glaube irgendwie nicht so recht, das sich die Transistormenge zwsichen dem "Gerüchte" r600 und einem hypothetischen G80 mit 32PS Alus + 32 TMUs + 18 VS/GS extrem unterscheiden wird (wobei man über die Anzahl der TMUs sicher reden kann, falls diese entkoppelt sind).

[Gast]

ShadowXX[/POST]']Ja, das war mir durchaus bewusst (bzw. das habe ich angenommen), aber nV hat ja fast keine andere Wahl.

Sie müssen gegen ATI Techdemos bzw. Messungen ankommen können, bei denen ATI extrem versuchen wird die vorteile Ihrer US-Architektur aufzuzeigen.
Die Dinger sind dann zwar mehr theoretischer Natur, aber wenn nV zuwenig PS oder zuwenig VS/GS implementiert, könnten diese Messungen katastrophal für nV aussehen.....selbst wenn es in Games völlig anders aussieht.

Gehen wir einfach mal davon aus, das nV nicht extra entkoppelte TMUs in den G80 "einhängen wird", sondern die jetzige Struktur beibehält.
Dann müssten Sie ja im Prinzip "nur" die G70/71 Architektur um ein Quad erhöhen und die VS um GS-Fähigkeiten erweitern (+ ein paar andere Änderungen -> Ja, mir ist klar das sich das einfacher anhört, als es gemacht werden kann).

Viel weniger (wenn überhaupt) Transistoren wird ATI für Ihre 64-Unified Shader auch nicht brauchen....speziell wenn man dann solchge Sachen im Vorfeld hört wie "heissester Chip ever" (bezogen auf den r600), was auch nicht unbedingt gerade auf wenig Transistoren schliessen lässt.

ATI benötigt momentan wesentlich mehr Transis für Ihren r580 als nV für Ihren G70....ATI wird (aus schon von Demi angemerkten Gründen) nicht das C1-Design als Grundlagen nehmen können, sondern wohl eher die "größeren" (aber auch leistungsfähigeren) r580 ALUs nehmen.
Dann noch HQAF + neu einzuführendes FP16 Filtering usw.
Ich glaube irgendwie nicht so recht, das sich die Transistormenge zwsichen dem "Gerüchte" r600 und einem hypothetischen G80 mit 32PS Alus + 32 TMUs + 18 VS/GS extrem unterscheiden wird (wobei man über die Anzahl der TMUs sicher reden kann, falls diese entkoppelt sind).
Zwei Quads, acht VS/GS-Einheiten dazu und eben einige Änderungen, die vermutlich für D3D10-Komplianz nötig sind.

Wenn ich jetzt mal von G70-NV40 ausgehe, kosten zwei Quads um und bei 70M Transistoren (Nein, G71 ziehe ich nicht heran, da ich davon ausgehe, dass auch NV40 einiges an Massetransistoren hat, daher halte ich den Vergleich zum G70 für passender). Dazu noch 20M für weitere acht VS, eine unbestimmte Anzahl, um die VS auch GS-Fähig zu machen und dazu etliche Millionen, um die Daten so frei im Chip umherzubewegen, wie D3D10 es erfordert. Dazu noch mehrere Millionen, um die Quad-Batch-Size deutlich zu verringern.

Ich denke, Nvidia hat bei ihrer jetzigen Quad-Pipe extrem gespart und diese Sparsamkeit werden sie bei der neuen Architektur nicht hinüberretten können, da einfach zu viele Änderungen nötig sein werden.

[Demirug]

Gast[/POST]']Ich denke, Nvidia hat bei ihrer jetzigen Quad-Pipe extrem gespart und diese Sparsamkeit werden sie bei der neuen Architektur nicht hinüberretten können, da einfach zu viele Änderungen nötig sein werden.

Von der geforderten Funktionalität her ist nVidia dichter an D3D10 als ATI. Die Sparsamkeit hat sich eher auf die Performancecharakteristik ausgewirkt.

[reunion]

aths[/POST]']Jede AF-Implementierung ist adaptiv. Bei trilinearem 16xAF und einer Textur, die im 2:1-Verhältnis verzerrt ist, dauert das Sampling nur 4 Takte, da für dieses Quad nur 2x AF zum Einsatz kommt. 16x AF tatsächlich zu nutzen kommt also generell nur selten vor, da es kaum Texturen gibt, die so stark verzerrt gerendert werden. Auf der GeForce6/7 ist es, wie auf älteren ATI-Grakas, ja zusätzlich so, dass der Maximalgrad nur winkelabhängig überhaupt erlaubt wird. Nur bei 90° und 45°-Winkeln wird bis zu 16x AF als Maximalgrad erlaubt.

Dann hat die GeForce 7 vermutlich einen Mechanismus, jedenfalls vermutet Demirug das, dass man AF nach Möglichkeit mit weniger iostropen Samples realisiert wird, als der Grad angibt. Bei 4x AF bräuchte man nach dem Lehrbuch ja 4 isotrope (also bilineare oder trilineare) Samples. Allerdings überdecken sich da fast immer auch Texel. Es ist denkbar, weniger isotrope Samples zu nehmen und sie so anzuordnen, dass sich keine Texel mehr überdecken. Damit kann man also Füllrate sparen, allerdings sind die im Hintergrund stehenden Rechnungen aufwändig.

Man fragt sich natürlich, warum Nvidia nicht auch schon lange auf stärkere TMU-ALU-Entkopplung setzt. Offensichtlich kann Nvidia die Quatchbatch-Pipelines aber vergleichsweise transistorsparend implementieren, und gleicht den Effizienznachteil mit einer breiteren Architektur aus. Die GF kann damit manchmal höhere Spitzenwerte erreichen, die Radeon kann konstantere Leistung bringen. Geht es um ALU-Leistung, ist die Radeon nicht zuletzt der feineren Granularität im Dynamic Branching ohnehin im Vorteil. Gehts um Texelleistung, hat die GF mehr zu bieten – erst recht bei FP16-Filterung, was auf der Radeon im Pixelshader aufwändig nachgestellt werden muss. Ich halte das TMU:ALU-Verhältnis von 1:3 für etwas zu verfrüht, aber wenn man "zu viel" Pixelshader-Leistung hat, gibts keinen Grund zu meckern – zumal die Texturleistung dank "Area-AF" auch sinnvoll in Qualität umgesetzt werden kann.

Sehr gut erklärt aths, du könntest dich hier ruhig öfter blicken lassen. :)

ShadowXX[/POST]']Dann müssten Sie ja im Prinzip "nur" die G70/71 Architektur um ein Quad erhöhen und die VS um GS-Fähigkeiten erweitern (+ ein paar andere Änderungen -> Ja, mir ist klar das sich das einfacher anhört, als es gemacht werden kann).


Sie sollten vorallem ihre dB-Performance verbessern, und wieder akzeptables AF anbieten. Das, dazu noch zwei Quads, 8VS, entkoppelte TMUs/ALUs, und wir wären vermutlich selbst bei einem SM3-Chip bei weit über 400mio Transitoren. Wenn du das jetzt noch alles D3D10-kompatibel machen willst, sprengst du die Transistorengrenze von nV höchstwahrscheinlich deutlich.


Viel weniger (wenn überhaupt) Transistoren wird ATI für Ihre 64-Unified Shader auch nicht brauchen....speziell wenn man dann solchge Sachen im Vorfeld hört wie "heissester Chip ever" (bezogen auf den r600), was auch nicht unbedingt gerade auf wenig Transistoren schliessen lässt.


Ich sehe bei Xenos 48 US-Einheiten bei etwas über 200mio Transistoren. Natürlich ist diese Zahl relativ nutzlos, da man nicht weiß, wieviel die Einheiten des R600 leisten werden, oder wieviel die Aufrüstung der ALUs zu GS kostet, etc. Deshalb sind solche Spekulationen zurzeit sinnlos IMHO.

Die 64 US-Einheiten für R600 halte ich momentan im übrigen ebenso wie die Aussagen von FUAD was den "hottest chip ever" betrifft für reine Fiktion. R600 hatte mit viel Glück vor kurzem sein erstes Tapeout, bis auf eine Minderheit von ATi-Mitarbeiter weiß da mit Sicherheit noch niemand, wie es um R600 bestellt ist.


ATI benötigt momentan wesentlich mehr Transis für Ihren r580 als nV für Ihren G70....ATI wird (aus schon von Demi angemerkten Gründen) nicht das C1-Design als Grundlagen nehmen können, sondern wohl eher die "größeren" (aber auch leistungsfähigeren) r580 ALUs nehmen.)

Man könnte genauso die C1-ALUs entsprechend upgraden, um ein deaktivieren der einzelnen Einheiten zu ermöglichen. Und selbst wenn man auf die R580-ALUs zurückgreift, wären diese alles andere als teuer, wie der Vergleich R520 zu R580 zeigt. Das Problem der hohen Transitorenanzahl der R5xx-Architektur liegt wie robbitop schon angedeutet hat wo anders.

[reunion]

Demirug[/POST]']Von der geforderten Funktionalität her ist nVidia dichter an D3D10 als ATI. Die Sparsamkeit hat sich eher auf die Performancecharakteristik ausgewirkt.

ATi mit R580 oder mit C1?

[Gast]

Demirug[/POST]']Von der geforderten Funktionalität her ist nVidia dichter an D3D10 als ATI. Die Sparsamkeit hat sich eher auf die Performancecharakteristik ausgewirkt.
Ich meine das starre durchlaufen der Pipe bei Nvidia ggü. Atis Thread-Pool.

[Demirug]

Gast[/POST]']Ich meine das starre durchlaufen der Pipe bei Nvidia ggü. Atis Thread-Pool.

Ja, dieser Unterschied wirkt sich lediglich auf die Performance in speziellen Situationen aus.

[Demirug]

reunion[/POST]']ATi mit R580 oder mit C1?

Das C1 Design ist für den PC ja weniger geeignet und zudem in dem Punkt scheinbar auch nicht besser als R580.

[reunion]

Demirug[/POST]']Das C1 Design ist für den PC ja weniger geeignet und zudem in dem Punkt scheinbar auch nicht besser als R580.

Welchen Punkt meinst du?
Ich dachte du beziehst dich auf das fehlende VT des R580, für welches ja C1 als USC prädestiniert sein sollte.

[Gast]

Demirug[/POST]']Ja, dieser Unterschied wirkt sich lediglich auf die Performance in speziellen Situationen aus.

Aber muss Nvidia nicht diese Starrheit lösen, um den freieren Datenfluß für D3D10 zu gewährleisten? Oder wird der Pixel/das Quad/whatever dann einfach einmal komplett durchgeschleust und kommt dann wieder "oben" rein?

[Gast]

reunion[/POST]']Welchen Punkt meinst du?
Ich dachte du beziehst dich auf das fehlende VT des R580, für welches ja C1 als USC prädestiniert sein sollte.

Keine Skalierbarkeit des Designs, mit 16xSIMD etwas hohe Grobkörnigkeit.?

[ShadowXX]

reunion[/POST]']Das Problem der hohen Transitorenanzahl der R5xx-Architektur liegt wie robbitop schon angedeutet hat wo anders.
Richtig....das sehe ich ja genauso. Nur wird man die anderen Sachen, die schon im r580 mit implementiert sind, ja auch im r600 implementieren müssen.

Das heisst Transistoren kosten diese sachen so oder so.....

Man wird es sehen, wenn die ersten etwas konkreteren Gerüchte über die Transistorenanzahl von G80 & r600 auftauchen.
Und es würde mich nicht wirklich wundern, wenn die Anzahl der Transistoren beider Chips relativ nahe beieinanderliegt, auch wenn nV wirklich 32/32/16 implementiert (was ich ihnen durchaus zutraue, wobei ich selbst allerdings eher an 28/28/12 denke, auch wenn es sich sehr krum anhört).

[Winter[Raven]]

ShadowXX[/POST]'](was ich ihnen durchaus zutraue, wobei ich selbst allerdings eher an 28/28/12 denke, auch wenn es sich sehr krum anhört).

Zutrauen ist gut, wissen ist besser... :biggrin:

Ne, sorry.... konnte es mir nicht verkneifen ... *Wochenende* ;D
Trotzdem muss ein wichtiger Grund existieren, warum Nvidia nicht auf US setzt. Beim erscheinen beider Chips werden wir es bestimmt erfahren.

[reunion]

Gast[/POST]']Keine Skalierbarkeit des Designs, mit 16xSIMD etwas hohe Grobkörnigkeit.?

Ich bezog mich auf das: "Von der geforderten Funktionalität her ist nVidia dichter an D3D10 als ATI."

[reunion]

ShadowXX[/POST]']Richtig....das sehe ich ja genauso. Nur wird man die anderen Sachen, die schon im r580 mit implementiert sind, ja auch im r600 implementieren müssen.

Das heisst Transistoren kosten diese sachen so oder so.....


Welche anderen Sachen?
Die Xenos-ALUs sind technologisch weiter als die von R580.


Man wird es sehen, wenn die ersten etwas konkreteren Gerüchte über die Transistorenanzahl von G80 & r600 auftauchen.
Und es würde mich nicht wirklich wundern, wenn die Anzahl der Transistoren beider Chips relativ nahe beieinanderliegt, auch wenn nV wirklich 32/32/16 implementiert (was ich ihnen durchaus zutraue, wobei ich selbst allerdings eher an 28/28/12 denke, auch wenn es sich sehr krum anhört).

Ich glaube nicht an dieses 2:1-Verhältnis. Die VS limitieren aktuell und wohl auch in näherer Zukunft kaum, und GS wird man zu Lebzeiten des G80 wohl größtenteils nur in Techdemos zu sehen bekommen. Ob mehr als 24 TMUs überhaupt Sinn machen, wenn man diese entkoppelt, halte ich auch für fragwürdig. Das die Transistorenanzahl nicht weit auseinander liegen wird, sollte klar sein, sofern man denselben Fertigungsprozess verwendet, da jeder natürlich möglichst das Maximum herausholen will. Interessant wird die Effizienz.

'Winter[Raven]'[/POST]']Trotzdem muss ein wichtiger Grund existieren, warum Nvidia nicht auf US setzt. Beim erscheinen beider Chips werden wir es bestimmt erfahren.

Es gab auch einen wichtigen Grund, warum ATi erst so spät auf SM3 gesetzt hat.

[ShadowXX]

reunion[/POST]']Welche anderen Sachen?
Die Xenos-ALUs sind technologisch weiter als die von R580.

Weil Sie unified sind? (und da auch nur PS+VS),

Sehe ich nicht unbedingt so.

Weitere Sache: z.B. HQAF, ATI soll beim C1 ziemlich am AF gespart haben.


Ich glaube nicht an dieses 2:1-Verhältnis. Die VS limitieren aktuell und wohl auch in näherer Zukunft kaum, und GS wird man zu Lebzeiten des G80 wohl größtenteils nur in Techdemos zu sehen bekommen. Ob mehr als 24 TMUs überhaupt Sinn machen, wenn man diese entkoppelt, halte ich auch für fragwürdig. Das die Transistorenanzahl nicht weit auseinander liegen wird, sollte klar sein, sofern man denselben Fertigungsprozess verwendet, da jeder natürlich möglichst das Maximum herausholen will. Interessant wird die Effizienz.

Ich sehe noch nicht unbedingt entkoppelte TMUs....

Und zur Menge: Wir brauchen im Prinzip auch kein 8VS....haben Sie aber trotzdem.
12 VS/GS sehe ich durchaus als realistisch an, genauso wie zumindest 28 (Dual-Issue)ALUs.
Wenn die TMUs wirklich entkoppelt werden sollte, könnten es aber tatsächlich weniger TMUs werden.



Es gab auch einen wichtigen Grund, warum ATi erst so spät auf SM3 gesetzt hat.
Ja.....Sie haben den r500 nicht für den Desktop hinbekommen.

[Winter[Raven]]

Ja Geld sparen, SM3 als unwichtig deklarieren und einfach ignorieren ... im Endeffekt ist es Nvidias Verdienst, dass immer mehr SM3 Spiele auf den Markt kommen. Vielleicht wird es diesmal ATI sein, die den Beifall bei den DEV's erntet.

Aber ohne Infos können wir uns sonst was aus den Fingern saugen, was uns bleibt ist das warten.

[Gast]

'Winter[Raven]'[/POST]']
Trotzdem muss ein wichtiger Grund existieren, warum Nvidia nicht auf US setzt. Beim erscheinen beider Chips werden wir es bestimmt erfahren.
Den kann ich dir zweifelsfrei verraten: Nvidia glaubt, ohne US mehr Geld zu verdienen. Dieser simple Grund treibt übrigens die meisten Firmen, besonders die börsennotierten, an. ;)

[Gast]

Es könnte auch sein, dass mehr TMUs und ROPs wieder interessant werden. Besonders letztere dürften dank der oft kolportierten Eignung der GS für Shadow-Volumes und des damit verbundenen, nötigen Z-First-Passes, eine Renaissance erleben. GDDR4 mit 30-50% höherer Frequenz und damit Bandbreite ggü. GDDR3 kann das Mehr an Einheiten dann ja auch wieder versorgen.


Q

[Sunrise]

...und wir wären vermutlich selbst bei einem SM3-Chip bei weit über 400mio Transitoren. Wenn du das jetzt noch alles D3D10-kompatibel machen willst, sprengst du die Transistorengrenze von nV höchstwahrscheinlich deutlich.
Da es >500M sind, sprengt G80 aktuelle Grenzen (in mehrfacher Hinsicht) natürlich mehr als nur deutlich.

...was den "hottest chip ever" betrifft für reine Fiktion. R600 hatte mit viel Glück vor kurzem sein erstes Tapeout, bis auf eine Minderheit von ATi-Mitarbeiter weiß da mit Sicherheit noch niemand, wie es um R600 bestellt ist.
Falls du hiermit implizieren willst, dass man - um das ungefähr nötige Potential der Kühllösung errechnen zu können - einen Tape-Out benötige, dann ist dem nicht so. Siehe unsere damalige G71-Diskussion.

[Gast]

'Winter[Raven]'[/POST]']Ja Geld sparen, SM3 als unwichtig deklarieren und einfach ignorieren ... im Endeffekt ist es Nvidias Verdienst, dass immer mehr SM3 Spiele auf den Markt kommen.
Von denen jetzt ATi Besitzer profitieren mit ihrer SM3.0 Hardware, die nicht nur aus Checklistfeatures besteht.

[reunion]

ShadowXX[/POST]']Weil Sie unified sind?


Auch, aber auch weil sie VT unterstützen (und das mit allen Formaten und verdammt schnell), oder weil sie 16 Interpolatoren besitzen, oder weil sie mehr Instruction Slots für die PS und VS bieten, etc.


(und da auch nur PS+VS),


Als ob R580 einen GS hätte.


Sehe ich nicht unbedingt so.


Das ist keine Frage der Ansicht. Ich kenne keine technologischen Vorteile was die ALUs von R580 betrifft, lasse mich aber natürlich gerne eines besseren belehren.


Weitere Sache: z.B. HQAF, ATI soll beim C1 ziemlich am AF gespart haben.


Das muss natürlich u.a. auch in R600 rein. Sollte sich aber leicht implementieren lassen.


Ich sehe noch nicht unbedingt entkoppelte TMUs....

Und zur Menge: Wir brauchen im Prinzip auch kein 8VS....haben Sie aber trotzdem.
12 VS/GS sehe ich durchaus als realistisch an, genauso wie zumindest 28 (Dual-Issue)ALUs.
Wenn die TMUs wirklich entkoppelt werden sollte, könnten es aber tatsächlich weniger TMUs werden.


Wir werden sehen.


Ja.....Sie haben den r500 nicht für den Desktop hinbekommen.

Richtig. Ursache und Wirkung. Es gibt immer einen Grund - dieser muss allerdings nicht unbedingt aus Performancecharakteristika entstanden sein.

[reunion]

Sunrise[/POST]']Da es >500M sind, sprengt G80 aktuelle Grenzen (in mehrfacher Hinsicht) natürlich mehr als nur deutlich.


Das hört sich ja verdammt sicher an.


Falls du hiermit implizieren willst, dass man - um das ungefähr nötige Potential der Kühllösung errechnen zu können - einen Tape-Out benötige, dann ist dem nicht so. Siehe unsere damalige G71-Diskussion.

Nein, ich wil damit implizieren, dass sich FUAD das ganze aus den Fingern gesaugt hat. Wobei dies natürlich alles andere als verwunderlich wäre, da die Strukturbreite vermutlich nur auf 80nm sinkt, und die Transistorenanzahl gegenüber R580 nochmal deutlich steigen wird.

[Sunrise]

Das hört sich ja verdammt sicher an.
Kommt direkt aus dem Maul des Löwen. Ich dachte eigentlich, dass sich das mittlerweile herumgesprochen hat.

Wobei dies natürlich alles andere als verwunderlich wäre, da die Strukturbreite vermutlich nur auf 80nm sinkt, und die Transistorenanzahl gegenüber R580 nochmal deutlich steigen wird.
Du siehst, "so einfach" gibt man sich manchmal die Antworten selbst. :)

Fuad bezog sich allerdings wahrscheinlich nicht auf Dinge, die wir hier mit eigenem Hirnschmalz selbst entdecken, sondern eher auf diese ominöse "300W"-Angabe.

[Karl19]

WAs glaubt ihr welcher CHip für die SPiele Entwickler intressanter werden wird G80 oder R600 ?

Danke.

[Gast]

Karl19[/POST]']WAs glaubt ihr welcher CHip für die SPiele Entwickler intressanter werden wird G80 oder R600 ?

Danke.

R600 kann besser sein, wenn man jetzt nurmal davon ausgeht das jeder US die gleiche Leistungsfähigkeit hat wie die Shader im G80.

Vorallem sind die Entwickler nicht auf die Begrenzung beschränkt, der R600 könnte daher 32US für Pixeloperationen verwenden und 32US für Geo bzw. Shaderoperationen.

mfg Nakai

[Neomi]

Karl19[/POST]']WAs glaubt ihr welcher CHip für die SPiele Entwickler intressanter werden wird G80 oder R600 ?

Da es keine Caps mehr geben wird (nur noch ganz wenige optionale Formatfeatures), werden beide das gleiche können. Interessanter ist in dem Fall die GPU, die im Sommer das Büro weniger aufheizt und die Ohren verschont.

[Demirug]

Neomi[/POST]']Da es keine Caps mehr geben wird (nur noch ganz wenige optionale Formatfeatures), werden beide das gleiche können. Interessanter ist in dem Fall die GPU, die im Sommer das Büro weniger aufheizt und die Ohren verschont.

Aber unter D3D9 gibt es noch Caps. Das könnte bei der Wahl dann durchaus eine Rolle spielen.

[aths]

Karl19[/POST]']WAs glaubt ihr welcher CHip für die SPiele Entwickler intressanter werden wird G80 oder R600 ?

Danke.Das kann man jetzt noch überhaupt nicht vorhersehen. Letztlich werden alle Titel auf beiden Systemen gut laufen müssen.

[Winter[Raven]]

Sunrise[/POST]']Da es >500M sind, sprengt G80 aktuelle Grenzen (in mehrfacher Hinsicht) natürlich mehr als nur deutlich.


Falls du hiermit implizieren willst, dass man - um das ungefähr nötige Potential der Kühllösung errechnen zu können - einen Tape-Out benötige, dann ist dem nicht so. Siehe unsere damalige G71-Diskussion.

Wie jetzt 500Mio? Bei 0.09µ? Forgett it! Oder?

[Neomi]

Demirug[/POST]']Aber unter D3D9 gibt es noch Caps. Das könnte bei der Wahl dann durchaus eine Rolle spielen.

Das müßte dann aber schon ein sehr schlechter Treiber sein, wenn er die (per D3D9 nutzbaren) Fähigkeiten der Karte nicht nutzen kann. Oder gibt es irgendwelche Caps, die von einer "minimalistischen" D3D10-Karte nicht unterstützt werden müßten?

[Ailuros]

Es sind mehr als 200M fuer Xenos denn der Tochter-die hat ausser eDRAM auch noch die ROPs und etwas Logik.

Die Vergleiche zwischen einem Consolen und PC Design sind sowieso sinnlos, aber R580 hat u.a. erstens mehr ALUs als Xenos und zweitens sind es quasi dual-issue ALUs.

Zurueck zum Thema:

http://www.beyond3d.com/forum/showpost.php?p=787745&postcount=331

Vorsicht man kann es leicht falsch interpretieren. Mit einer etwas verkorksten Logik stimmt es dann schon hoechstwahrscheinlich.

[Ailuros]

'Winter[Raven]'[/POST]']Wie jetzt 500Mio? Bei 0.09µ? Forgett it! Oder?

ROFL das Zeug stammt von einer oeffentlichen Aussage. An das genau Zitat kann ich mich nicht mehr erinnern aber man erwaehnte schon "half a billion transistors".

[Ailuros]

Gast[/POST]']Es könnte auch sein, dass mehr TMUs und ROPs wieder interessant werden. Besonders letztere dürften dank der oft kolportierten Eignung der GS für Shadow-Volumes und des damit verbundenen, nötigen Z-First-Passes, eine Renaissance erleben. GDDR4 mit 30-50% höherer Frequenz und damit Bandbreite ggü. GDDR3 kann das Mehr an Einheiten dann ja auch wieder versorgen.


Q

Es sieht eher danach aus als ob die Geruechte die fuer R6x0 16 TMUs wollen wahr sind.

Bei G80 sind mir 32 viel zu viel, deshalb schob ich mit Absicht nao's Spekulation in den Thread.

[Winter[Raven]]

Ailuros[/POST]']ROFL das Zeug stammt von einer oeffentlichen Aussage. An das genau Zitat kann ich mich nicht mehr erinnern aber man erwaehnte schon "half a billion transistors".

Okai... wie wollen die das Kühlen und erst mit Strom versorgen?

[Gast]

Man hat doch auch 300mio Transistoren in 0.11µ reingequetscht, sollte also machbar sein, vieleicht ists ja auch ein 0.08µ Prozess, NV ist ja für Überraschungen gut.
D3D10 Features sind eh nur die Pflicht, man wirds einbauen oder es muss teilweise über die Pixelshader umständlich emuliert werden, aber zuviel Wind um GS würde ich da nicht machen. Interessanter sind die Umstellungen der Architektur die den Sprung auf US vorbereiten ^^

[Ailuros]

'Winter[Raven]'[/POST]']Okai... wie wollen die das Kühlen und erst mit Strom versorgen?

Gute Frage gilt aber dann fuer beide IHVs ;)

[Coda]

Ailuros[/POST]']Vorsicht man kann es leicht falsch interpretieren. Mit einer etwas verkorksten Logik stimmt es dann schon hoechstwahrscheinlich.
Zählen die FP- und Int-ALUs getrennt?

[Ailuros]

Coda[/POST]']Zählen die FP- und Int-ALUs getrennt?

http://www.beyond3d.com/forum/showthread.php?p=788442#post788442

[Coda]

Hm da steht drin dass sie Transistoren sparen indem sie den Interpolator mit den Higher-Order-Functions zusammenwursteln. Was ist daran jetzt besonders?

[Ailuros]

Coda[/POST]']Hm da steht drin dass sie Transistoren sparen indem sie den Interpolator mit den Higher-Order-Functions zusammenwursteln. Was ist daran jetzt besonders?

Wie soll ich dann demzufolge zaehlen?

[Winter[Raven]]

Updates? Schließlich haben wir mitte JULI ^_^

[tokugawa]

Gast[/POST]']Von denen jetzt ATi Besitzer profitieren mit ihrer SM3.0 Hardware, die nicht nur aus Checklistfeatures besteht.

Von denen jetzt ATI-Besitzer profitieren an Effekten, die Entwickler nur auf NVIDIA-Hardware entwickeln konnten mangels SM3-Alternativen von ATI vor der X1000-Serie.

NVIDIA ebnete mit Sicherheit den Weg dazu dass in Software mehr SM 3.0 unterstützt wird.

ATI dagegen hat halt jetzt davon profitiert und ist zum richtigen Zeitpunkt aufgesprungen auf den Weg der schon von NVIDIA geebnet wurde.

Man muß beide Faktoren sehen.

[Gast]

Ich frag mich immer noch warum Nvidia so mit News spart

[Gast]

Vielleicht halten sie mal dicht, weil sie sich sicher sind, in einer guten Position zu sein und der konkurrenhz keine Angriffsfläche zu liefern.

Je weniger man weiß, desto weniger kann das gegnerische Marketing wieder pöhse PDFs basteln.

[NiCoSt]

hihi, erinnert mich daran dass immer, wenn HL-Firmen was nicht schon monate vorher an die große glocke hängen, es sich idR um einen Flop/eine Fehlkonstruktion handelt ;)

[Ailuros]

Gast[/POST]']Ich frag mich immer noch warum Nvidia so mit News spart

Weil heutige Verkaufszahlen immer noch sehr gut sind ;) Gilt aber genauso fuer ATI.

[Ailuros]

NiCoSt[/POST]']hihi, erinnert mich daran dass immer, wenn HL-Firmen was nicht schon monate vorher an die große glocke hängen, es sich idR um einen Flop/eine Fehlkonstruktion handelt ;)

Die grosse Glocke ist schon da, nur eben nicht fuer die breite Oeffentlichkeit.

[Gast]

Eben. Wenn man jetzt loslegen würde, wie Intel mit dem Conroe, würde kein Schwein mehr die G71/R580-Karten kaufen.

[blade04]

Naja aber sich jetzt ne G71 zu hohlen wär doch auch nicht so schlau.

Bin jetzt hab ich auch immer ne generation übersprungen. von GF 2 zu GF4 zu GF 6 und jetzt will ich GF 8.

[Gast]

Nvidia's G80 has HDCP inside

http://www.the-inquirer.net/default.aspx?article=33174

[Coda]

G80 and the shipping G73, Geforce 7600 generation will have both HDMI and HDCP inside the graphics processor. It will remove the necessity for the highly unavailable Silicon Image 1930 chip.
;D

With this new design Nvidia will remove the need for an external HDMI/HDCP transmitter and all you need to add to a G80/G73 card to have the HDMI and HDCP is the small key Rom that will identify your computer to the copy protection monsters. Usually this Rom key costs around $0.30 when you buy a bunch of them.
;D ;D

Fuad ist immer wieder gut.

[AnarchX]

Coda[/POST]']
G80 and the shipping G73, Geforce 7600 generation will have both HDMI and HDCP inside the graphics processor. It will remove the necessity for the highly unavailable Silicon Image 1930 chip.
;D



http://www.hkepc.com/bbs/attachments_dir/ext_jpg/g73_CwEI9qVFjqdj.jpg

;)

[Coda]

HDMI ist der Anschluss und der Stecker.

[AnarchX]

Coda[/POST]']HDMI ist der Anschluss und der Stecker.

Schon klar, Fuad hatte sich nur etwas unglücklich ausgedrückt, aber etwas wahres war an der Aussage doch dran.

[Coda]

Fuad hat keinen blassen Schimmer von was er schreibt und dann kommt son Müll raus.

Btw. bin ich immer noch dafür dass irgendwann einer den Privat-Key von dem Müll rausfindet indem er das ROM mit Spezialgerät bearbeitet - Ich würd 3 Tage Tränen lachen.

[Anarchy-HWLUXX]

Hmmm ... weiss net ob das scho gepostet wurd, ab egal :D

Today @ the Inq.

G80 -> 90nm

http://uk.theinquirer.net/?article=33260

[Gast]

Hmmm...32Pipes und 12 Vertexshader bei 90Nm.
Das muss ja nichts bedeuten, aber wenn der Chip mit D3D10 umgehen soll und einen dementsprechenden Takt hat, wird er wohl sehr heiß werden.
Das hat man schön beim Nv40 gesehen, er musste um kühl zu bleiben bei den Taktraten gedrosselt werden, was sich negativ auf die Leistung auswirkt.

Der G80 wird vll mit 650Mhz getaktet sein, er wird wahrscheinlich bis zu 60% schneller sein wie die Geforce 7900Gtx, und ungefähr 20% schneller sien wie die Gx2 7950...jedenfall wäre das meine Theorie.

mfg Nakai

[Ailuros]

Gast[/POST]']Hmmm...32Pipes und 12 Vertexshader bei 90Nm.
Das muss ja nichts bedeuten, aber wenn der Chip mit D3D10 umgehen soll und einen dementsprechenden Takt hat, wird er wohl sehr heiß werden.
Das hat man schön beim Nv40 gesehen, er musste um kühl zu bleiben bei den Taktraten gedrosselt werden, was sich negativ auf die Leistung auswirkt.

Der G80 wird vll mit 650Mhz getaktet sein, er wird wahrscheinlich bis zu 60% schneller sein wie die Geforce 7900Gtx, und ungefähr 20% schneller sien wie die Gx2 7950...jedenfall wäre das meine Theorie.

mfg Nakai

Eigentlich schreibt er 16 GS/VS Einheiten, aber das Zeug ist sowieso sinnlos so wie er schreibt. Ein guter spekulativer Anhaltspunkt fuer G80/R6x0 sind hoechstwahrscheinlich 4 ALUs pro ROP ;)

Dein zweiter Paragraph ist eine ziemlich logische und nuechterne Spekulation.

[seahawk]

FUAD geht einem mit seinem R600 Fetisch lansam auf den Sack.

[Gast]

Ailuros[/POST]']Eigentlich schreibt er 16 GS/VS Einheiten, aber das Zeug ist sowieso sinnlos so wie er schreibt. Ein guter spekulativer Anhaltspunkt fuer G80/R6x0 sind hoechstwahrscheinlich 4 ALUs pro ROP ;)

Dein zweiter Paragraph ist eine ziemlich logische und nuechterne Spekulation.

Hehehe....also
4 ALUs pro ROP? Das wäre relativ viel Shaderleistung, aber wie viele TMUs hat dann der G80?
Nehmen wir mal an er hätte 32 ROPs und 32 TMUs, dann hätte er 128 ALUs, die die Shaderinstruktionen verarbeiten...das wäre nach meiner Meinung zu viel.
;)

Bei 16 ROPs wäre es dann schon wesentlich besser, also 64 ALUs...
Obowhl ich mir daa nicht wirklich vorstellen kann, 16 ROPs wären keine Steigerung zum G71, außer es wird mehr Chips auf einer PCB sein.
Dann könnte man auf 32 TMUs schätzen, sodass die alle ALUs entkoppelt sind, also wie beim G70 eine vor und eine nach der TMU...

[aths]

Gast[/POST]']Hehehe....also
4 ALUs pro ROP? Das wäre relativ viel Shaderleistung, aber wie viele TMUs hat dann der G80?
Nehmen wir mal an er hätte 32 ROPs und 32 TMUs, dann hätte er 128 ALUs, die die Shaderinstruktionen verarbeiten...das wäre nach meiner Meinung zu viel.Meiner Meinung nach nicht. Eine ALU kostet weniger, als man denkt. Wenn NV weiterhin einen Ableger von CineFX nutzt, brauchen sie große ALU-Rohleistung, um die Nachteile beim Texturzugriff zu kompensieren.

[Gast]

aths[/POST]']Meiner Meinung nach nicht. Eine ALU kostet weniger, als man denkt. Wenn NV weiterhin einen Ableger von CineFX nutzt, brauchen sie große ALU-Rohleistung, um die Nachteile beim Texturzugriff zu kompensieren.

Ja aber selbst der R580 hat nur 48 ALUs, dann sollte der G80 das dreifache haben?
Okay für die Texturzugriffe wäre das möglich, das macht aber den G80 höchstens 60% schneller, bei gleichem Takt...

[aths]

Gast[/POST]']Ja aber selbst der R580 hat nur 48 ALUs, dann sollte der G80 das dreifache haben?
Okay für die Texturzugriffe wäre das möglich, das macht aber den G80 höchstens 60% schneller, bei gleichem Takt...128 ist nicht das dreifache von 48. ALUs hintereinander zu setzen, wie beim G70 (24 x2 ALUs) ist preiswerter, als sie parallel zu bauen, da man Datenpfade spart. Was NV beim G80 macht, weiß ich nicht. Ich hielte es aber für möglich, dass ALU-mäßig im Pixelteil 128x MAD4 ausgeführt werden könnte, wenn da nicht wieder mal das Registerfile limitieren würde. Reine Spekulation: NV bleibt bei den Quadbatches, verdoppelt die Größe des Registerfiles und die Zahl der MAD-ALUs.

[Gast]

aths[/POST]']128 ist nicht das dreifache von 48. ALUs hintereinander zu setzen, wie beim G70 (24 x2 ALUs) ist preiswerter, als sie parallel zu bauen, da man Datenpfade spart. Was NV beim G80 macht, weiß ich nicht. Ich hielte es aber für möglich, dass ALU-mäßig im Pixelteil 128x MAD4 ausgeführt werden könnte, wenn da nicht wieder mal das Registerfile limitieren würde. Reine Spekulation: NV bleibt bei den Quadbatches, verdoppelt die Größe des Registerfiles und die Zahl der MAD-ALUs.

Okay das ist eine normale Spekulation, aber ist es nicht zukunftsorientiert an die alte Technologie festzuhalten?
Der Nv40 war ja damals zwar gut, aber mittlerweile, denke ich, ist diese Architektur einfach veraltet, unzureichende Shaderleistung, in meinen Augen, 128 ALUs sind zu viele.
96 wären ahnehmbar.
Aber das fallen ja wieder 32 ALUs wegen den Texturkoordinaten weg, also noch 64.
Natürlich sagt das nichts aus, aber NV will einen "kleinen" Chip bauen, solange die Taktraten stimmen.
Also ich schätze Taktraten von 450Mhz für annehmbar, wenn der R600 kommt, wird ein Mini-Refresh kommen, und wahrscheinlich mit 500Mhz+ takten.

[aths]

Gast[/POST]']Okay das ist eine normale Spekulation, aber ist es nicht zukunftsorientiert an die alte Technologie festzuhalten?
Der Nv40 war ja damals zwar gut, aber mittlerweile, denke ich, ist diese Architektur einfach veraltet, unzureichende Shaderleistung, in meinen Augen, 128 ALUs sind zu viele.
96 wären ahnehmbar.
Aber das fallen ja wieder 32 ALUs wegen den Texturkoordinaten weg, also noch 64.
Natürlich sagt das nichts aus, aber NV will einen "kleinen" Chip bauen, solange die Taktraten stimmen.
Also ich schätze Taktraten von 450Mhz für annehmbar, wenn der R600 kommt, wird ein Mini-Refresh kommen, und wahrscheinlich mit 500Mhz+ takten.Auf solche konkreten Spekulationen lasse ich mich nicht ein – aber 128 ALUs, die jeweils MAD4 ausführen können, wären aus meiner Sicht technisch realisierbar. CineFX wurde mit dem NV30 eingeführt und beim NV40 entscheidend verbessert (Die "Praxisleistung" wurde bei CineFX3, ausgehend von CineFX2, etwa um Faktor 2 erhöht.) Für den NV35 wurde CineFX1 etwas verbessert, für den G70 wurde CineFX3 etwas verbessert (die Praxisleistung stieg jeweils um etwa 25%.) Für den G80 könnte wieder eine entscheidende Verbesserung anstehen. Mit der von mir geäußerten Idee (die reine Spekulation ist) wäre eine Verbesserung etwa um Faktor 2 möglich.

Im Überblick:

CineFX 1: 2x Tex, 2 Temp-Register, 1x FP32-MAD4
CineFX 2: 2x Tex, 2 Temp-Register, 1x FP32-MAD4 + 1x FP16-MAD4 (oder 1x FP32-ADD, oder 1x FP32-MUL)
CineFX 3: 1x Tex, 4 Temp-Register, 1x FP32-MUL4 + 1x FP32-MAD4
CineFX 3: 1x Tex, 4 Temp-Register, 1x FP32-MAD4 + 1x FP32-MAD4 (kann jedoch nur bei FP16 voll ausgelastet werden)
CineFX 5: 1x Tex, 8 Temp-Register, 1x FP32-MAD4 + 1x FP32-MAD4 + 1x FP32-MAD4 + 1x FP32-MAD4 (kann jedoch nur bei FP16 voll ausgelastet werden) (reine Spekulation)

[Gast]

aths[/POST]']Auf solche konkreten Spekulationen lasse ich mich nicht ein – aber 128 ALUs, die jeweils MAD4 ausführen können, wären aus meiner Sicht technisch realisierbar. CineFX wurde mit dem NV30 eingeführt und beim NV40 entscheidend verbessert (Die "Praxisleistung" wurde bei CineFX3, ausgehend von CineFX2, etwa um Faktor 2 erhöht.) Für den NV35 wurde CineFX1 etwas verbessert, für den G70 wurde CineFX3 etwas verbessert (die Praxisleistung stieg jeweils um etwa 25%.) Für den G80 könnte wieder eine entscheidende Verbesserung anstehen. Mit der von mir geäußerten Idee (die reine Spekulation ist) wäre eine Verbesserung etwa um Faktor 2 möglich.

Im Überblick:

CineFX 1: 2x Tex, 2 Temp-Register, 1x FP32-MAD4
CineFX 2: 2x Tex, 2 Temp-Register, 1x FP32-MAD4 + 1x FP16-MAD4 (oder 1x FP32-ADD, oder 1x FP32-MUL)
CineFX 3: 1x Tex, 4 Temp-Register, 1x FP32-MUL4 + 1x FP32-MAD4
CineFX 3: 1x Tex, 4 Temp-Register, 1x FP32-MAD4 + 1x FP32-MAD4
CineFX 5: 1x Tex, 8 Temp-Register, 1x FP32-MAD4 + 1x FP32-MAD4 + 1x FP32-MAD4 + 1x FP32-MAD4 (reine Spekulation)

Okay das war etwas weit aus der Luft gegriffen, ich frage mich einfach, wie man soetwas realisieren könnte?
Ich finde einfach das 4 ALUs zu viel wären und noch 8 Temp-Register, antürlich ist es nur Spekulation und für D3D10 braucht man schon dementsprechende Hardware, also von daher wäre dein Vorschlag sogar realisierbar.
Die Frage für mich ist es aber, ob man 4 ALUs unbedingt benötigt...

[aths]

Gast[/POST]']Okay das war etwas weit aus der Luft gegriffen, ich frage mich einfach, wie man soetwas realisieren könnte?
Ich finde einfach das 4 ALUs zu viel wären und noch 8 Temp-Register, antürlich ist es nur Spekulation und für D3D10 braucht man schon dementsprechende Hardware, also von daher wäre dein Vorschlag sogar realisierbar.
Die Frage für mich ist es aber, ob man 4 ALUs unbedingt benötigt...8 Temp-Register sind eine Menge Holz, da man die Register – jedes einzelne 128 Bit breit – für alle Stages der Quadpipe vorhalten muss, und das bei einer vermuteten Länge von 256 Stages, also 1024 Pixel (ein Quad = 4 Pixel, wie bekannt.) Der Texturcache ist speichersplatzmäßig der sprichwörtliche Fliegenschiss gegen die Tempregister.

Man benötigt nicht "unbedingt" 4 MAD4-ALUs pro Pipe. Aber wenn Texturzugriffe, die eine bessere Filterung als bilinear 1x AF erfordern, die Pipeline stallen, wäre viel Roh-ALU-Leistung gut, um in den nicht gestallten Takten die arithmetischen Operationen auszuführen. Die ALU kostet weniger Transistoren als man denkt. Was teuer ist, sind die Crossbars und die Temp-Register. Wegen der Schaltzeiten muss das alles auf engem Raum platziert werden, ansonsten wäre die Taktbarkeit ziemlich schlecht. Die Pipe einfach länger zu machen hieße auch, noch mehr Stages zu haben für die Temp-Register benötigt würden, das wäre auch keine Lösung.

Ich rechne nicht unbedingt mit 4 MAD4-ALUs pro Pipe, aber es wäre aus meiner Sicht eine denkbare Option.

[Coda]

aths[/POST]']Auf solche konkreten Spekulationen lasse ich mich nicht ein – aber 128 ALUs, die jeweils MAD4 ausführen können, wären aus meiner Sicht technisch realisierbar. CineFX wurde mit dem NV30 eingeführt und beim NV40 entscheidend verbessert (Die "Praxisleistung" wurde bei CineFX3, ausgehend von CineFX2, etwa um Faktor 2 erhöht.) Für den NV35 wurde CineFX1 etwas verbessert, für den G70 wurde CineFX3 etwas verbessert (die Praxisleistung stieg jeweils um etwa 25%.) Für den G80 könnte wieder eine entscheidende Verbesserung anstehen. Mit der von mir geäußerten Idee (die reine Spekulation ist) wäre eine Verbesserung etwa um Faktor 2 möglich.

Im Überblick:

CineFX 1: 2x Tex, 2 Temp-Register, 1x FP32-MAD4
CineFX 2: 2x Tex, 2 Temp-Register, 1x FP32-MAD4 + 1x FP16-MAD4 (oder 1x FP32-ADD, oder 1x FP32-MUL)
CineFX 3: 1x Tex, 4 Temp-Register, 1x FP32-MUL4 + 1x FP32-MAD4
CineFX 3: 1x Tex, 4 Temp-Register, 1x FP32-MAD4 + 1x FP32-MAD4 (kann jedoch nur bei FP16 voll ausgelastet werden)
CineFX 5: 1x Tex, 8 Temp-Register, 1x FP32-MAD4 + 1x FP32-MAD4 + 1x FP32-MAD4 + 1x FP32-MAD4 (kann jedoch nur bei FP16 voll ausgelastet werden) (reine Spekulation)
Ahja, und wie willst du 4 Ops/Cycle sinnvoll auslasten? Erzähl mal...

[Gast]

Der Temp und Texturregister wirken dem stallen doch dagegen, oder besser, sie vermindern den Verlust der Leistung pro Stall?
Jedenfalls wäre dies die Pflicht von NV diese Stallverzögerung entgegen zuwirken.
Ich hätte die ALU jetzt wesentlich Größer geschätzt, aber das kommt vom R580, wo die ALUs ja parallel angeordnet sind.


Für mich scheint es wieder mal einen Ableger der alten bzw. neuen CineFx-Architektur zu schaffen.
Die Architektur ist nicht schlecht, hat viele kleine Mankos, aber gute Leistung.
(ich spreche nicht vom NV30^^)

[Gast]

Ich stimme Coda hier zu. Ich denke auch nicht, dass es sinnvoll ist, den Weg weiter in die Tiefe zu wählen.

[aths]

Coda[/POST]']Ahja, und wie willst du 4 Ops/Cycle sinnvoll auslasten? Erzähl mal...Bei Shadern mit einigen Zig Anweisungen kein Problem. Überleg mal ...

Gast[/POST]']Ich stimme Coda hier zu. Ich denke auch nicht, dass es sinnvoll ist, den Weg weiter in die Tiefe zu wählen.Dafür bearbeitet die Quadbatch-Architektur weiterhin einzelne Quads, während R580 immer drei Quads zusammen bearbeitet. Das hat auch Effizenz-Nachteile im Vergleich zur Quadbatch-Lösung. Würde man 128 MAD4-ALUs so organisieren, dass man 64 Pipes à 1x Tex und 2x ALU hat, bekäme man die TMUs praktisch nie ausgelastet. Der Weg in die Breite ist nur begrenzt sinnvoll. Natürlich ist die Zahl "128" reine Spekulation. Wenn man sie realisieren wollte, wäre der Weg über die Tiefe aber transistoreffizienter.

Gast[/POST]']Der Temp und Texturregister wirken dem stallen doch dagegen, oder besser, sie vermindern den Verlust der Leistung pro Stall?
Jedenfalls wäre dies die Pflicht von NV diese Stallverzögerung entgegen zuwirken.
Ich hätte die ALU jetzt wesentlich Größer geschätzt, aber das kommt vom R580, wo die ALUs ja parallel angeordnet sind.


Für mich scheint es wieder mal einen Ableger der alten bzw. neuen CineFx-Architektur zu schaffen.
Die Architektur ist nicht schlecht, hat viele kleine Mankos, aber gute Leistung.
(ich spreche nicht vom NV30^^)Auch NV hält Patente für Threading-artige Shader. Es kann durchaus sein, dass davon schon im G80 Gebrauch gemacht wird. Dass NV weiterhin auf CineFX setzen könnte, ist von meiner Seite eine reine Spekulation. Mit Spekulation meine ich nicht mal "Vermutung", ich stelle in Bezug auf den G80 keine Vermutungen auf weil ich absolut keine Informationen zu diesem Chip habe.

Man kann mit zusätzlichen Temp-Registern dem Stallen begegnen. Aber man braucht sie auch, um ALUs auszulasten. Man hat nichts davon, wenn man Stalls verhindert wenn man auf der anderen Seite nur die halbe ALU-Power nutzt. Lieber lässt man mal die Pipe stallen und nutzt in den anderen Takten so viel von den ALUs, wie möglich.

Wenn man pro Pipe nur eine ALU hat, muss man "oben" die Daten zuführen und "unten" abführen. Das kostet "Leitungen" (also Datenpfade.) Baut man die ALUs hintereinander, speist die erste direkt in die zweite ein (allerdings verbunden über eine Crossbar, damit man Register tauschen kann etc.) Man kann aber nicht direkt von ALU1 in den Framebuffer schreiben, die Daten müssen auch noch durch die zweite ALU durch, selbst wenn diese nichts tut. Andersherum kann die ALU2 nur Daten beziehen, die zuvor in ALU1 waren, selbst wenn sie dort nicht geändert wurden. Man spart pro ALU trotzdem Verteilerlogik. Bei 3 ALUs würde ich folgendes vermuten: MAD+SFU1, Tex, MAD+SFU2 sowie irgendwo noch ein reines MAD. Die Special Functions (SFU) sind aus bestimmten Gründen auf zwei ALUs verteilt. Bei 4 ALUs hielte ich es für unwahrscheinlich, dass es zwei reine MAD-ALUs gibt. Bestimmte SFUs würden dann vermutlich ebenfalls mehrfach implementiert werden.

Bei Shadern, bei denen erst mal zwei Texturen gesampelt werden die dann beide zusammen verrechnet werden (zum Beispiel multiplikativ) würden in den ersten beiden Durchläufen alle ALUs brach liegen, da man ja eben erst mal die Texturen braucht. Dafür hätte man in den darauffolgenden Takten die Möglichkeit, auf massive ALU-Power zurückzugreifen.

[Coda]

aths[/POST]']Bei Shadern mit einigen Zig Anweisungen kein Problem. Überleg mal ...
Es ist ein Problem. Die Instructions in einem VLIW dürfen nicht voneinander abhängig sein.

mad r2, r2, r3, r3
mad r1, r1, r2, r2
mad r0, r0, r1, r1

Läuft auf R580 genau 3x so schnell wie auf R520, aber keinen deut schneller auf G70 als auf NV40.

Und das ist nicht selten. 4 parallelisierbare MADs im Programm sind äußerst unwahrscheinlich.

[Gast]

aths[/POST]']Dafür bearbeitet die Quadbatch-Architektur weiterhin einzelne Quads, während R580 immer drei Quads zusammen bearbeitet. Das hat auch Effizenz-Nachteile im Vergleich zur Quadbatch-Lösung. Würde man 128 MAD4-ALUs so organisieren, dass man 64 Pipes à 1x Tex und 2x ALU hat, bekäme man die TMUs praktisch nie ausgelastet. Der Weg in die Breite ist nur begrenzt sinnvoll. Natürlich ist die Zahl "128" reine Spekulation. Wenn man sie realisieren wollte, wäre der Weg über die Tiefe aber transistoreffizienter.

Vielleicht ist eine der möglichen Lösungen hierzu auch in den angeblich 16 kombinierten GS/VS-Einheiten zu suchen.

[Gast]

Gast[/POST]']Vielleicht ist eine der möglichen Lösungen hierzu auch in den angeblich 16 kombinierten GS/VS-Einheiten zu suchen.

Unwahrscheinlich, warum sollten die 16 VS/GS-Einheiten etwas mit der Lastenverteilung zu tun haben?
Sie müssten um die TMUs zu befüllen sehr rechenstark, also sehr viele Daten verteilen, sein.
Da ist es schon besser, weniger TMUs zu nehmen und Ressourcen zu sparen und den Leistung mittels den Takt zu kompensieren.

[Gast]

Gast[/POST]']Unwahrscheinlich, warum sollten die 16 VS/GS-Einheiten etwas mit der Lastenverteilung zu tun haben?
Sie müssten um die TMUs zu befüllen sehr rechenstark, also sehr viele Daten verteilen, sein.
Da ist es schon besser, weniger TMUs zu nehmen und Ressourcen zu sparen und den Leistung mittels den Takt zu kompensieren.

Schau dir einfach mal ein paar der Patente Nvidias aus der letzten Zeit im B3D-Forum an. Da wurde an weit mehr geforscht, als an "simplen" GS/VS-Einheiten.

[aths]

Coda[/POST]']Es ist ein Problem. Die Instructions in einem VLIW dürfen nicht voneinander abhängig sein.Natürlich. Das Ergebnis vom der ersten Op kann in der zweiten genutzt werden. Die Quadbatch-Pipe ist ja letztlich nur ein FIFO.

[Coda]

Gna. Denkfehler, ich mein immer das Ding sei parallel.

Das Problem bei so ner riesen Pipeline wird eher sein dass der Branch-Overhead noch größer werden würde. Das Zeug bräucht edann ja mindestens 4 Takte bis es durch ist.

[aths]

Coda[/POST]']Gna. Denkfehler, ich mein immer das Ding sei parallel.

Das Problem bei so ner riesen Pipeline wird eher sein dass der Branch-Overhead noch größer werden würde. Das Zeug bräucht edann ja mindestens 4 Takte bis es durch ist.256 Quads brauchen nach wie vor 256 (eigentlich 257) Takte – nur dass hier bis zu 4 ALU-Ops pro Takt ausgeführt werden könnten. Die reale Performance dürfte natürlich darunter liegen. Da pro Takt alle 4 ALUs im Betrieb sind, verlängert sich da nichts auf vier Takte. Es werden nur im Falle eines Stalls 4 (statt wie bei CineFX4 nur 2) MAD-ALUs blockiert. Warum sollte es beim Branchen 4 Takte Overhead geben? Wenn in der Tex-Stage (durch das TMU-Speicherinterface kommen ja auch die Instruktionen rein) gebrancht wird, muss die Pipe zwar geflusht werden, aber dadurch hat man fast keinen zusätzlichen Leerlauf. Es geht lediglich ein neues Control-Quad durch.

Bei einer Quadpipe mit 256 Stages braucht es inkl. Control-Quad 257 Takte, bis etwas "durch" ist – dann aber sind auch 256 Quads abgearbeitet (sofern man keine "Blasen" reinschieben muss, weil die Temp-Register limiteren.) Sofern man nicht ständig brancht und zwischen den Sprungbefehlen einige ALU-Ops hat, ist die Tiefe der Pipe praktisch egal. Selbst wenn zwei Branching-Befehle aufeinanderfolgen, kostet da nichts vier Takte, man hat lediglich die Verschwendung der ALUs in den entsprechenden Takten, da sie dann nicht genutzt werden können. Das ist ja gerade die Idee, dass Nvidia die Ineffizienzen an einigen Stellen (Textursampling bei besserer Filterung als reines bilinear, Branching) durch brutale ALU-Leistung wettmachen könnte. Die Frage ist natürlich, ob 4 ALUs in Reihe tatsächlich besser wären, als 3 ALUs parallel. (Wobei ich nicht weiß, wie unabhängig die 3 ALUs pro R580-Pixelpipe wirklich sind.) Die Planungen für den G80 dürften allerdings schon begonnen haben, bevor NV wusste, wie der R580 aussehen wird.

[Winter[Raven]]

Die Frage ist natürlich, ob 4 ALUs in Reihe tatsächlich besser wären, als 3 ALUs parallel. (Wobei ich nicht weiß, wie unabhängig die 3 ALUs pro R580-Pixelpipe wirklich sind.) Die Planungen für den G80 dürften allerdings schon begonnen haben, bevor NV wusste, wie der R580 aussehen wird.

Nvidia aber auch ATi können mit Sicherheit einschätzen wohin der Hase laufen wird, insbesondere wenn es um Refreshs(R580) geht.

Was mich aber neben der jetzigen Diskus. interessieren würde, was ist mit dem Design passiert das als NV50 entwickelt wurde? Verschoben auf G90 oder ist es in irgendeiner Schublade verschwunden?

[Gast]

Wieso glaubst du, dass G80 nicht NV50 ist?

Zur Pipeline:
Je "breiter" man mit der klassischen Architektur wird, desto mehr schleppt man auch unnütze Transistoren mit sich rum und desto weniger wird der Vorteil wiegen, den Nvidia durch die kompakte, aber anfällige Pipe hat.

IMO ist der kritische Punkt bereits erreicht, G80 noch mehr zu verbreitern ohne andere, sinnvolle Änderungen vorzunehmen, könnte übel enden für Nv. Ganz besonders, wenn Ati die verbliebenen Schwachstellen des R580 mit dem R600 auffangen bzw. beseitigen kann. Andererseits könnte die quasi-Aufhebung des "starren" Einheiten-Denkens auch zu interessanten Ergebnissen im Hinblick auf die Überkreuz-Nutzung verschiedener Einheiten führen.

Genau dort liegt jedoch der Knackpunkt: Wie gut können die neuen Einheiten hüben wie drübern integriert werden und was kostet das.

[Ailuros]

Gast[/POST]']Hehehe....also
4 ALUs pro ROP? Das wäre relativ viel Shaderleistung, aber wie viele TMUs hat dann der G80?
Nehmen wir mal an er hätte 32 ROPs und 32 TMUs, dann hätte er 128 ALUs, die die Shaderinstruktionen verarbeiten...das wäre nach meiner Meinung zu viel.
;)

Bei 16 ROPs wäre es dann schon wesentlich besser, also 64 ALUs...
Obowhl ich mir daa nicht wirklich vorstellen kann, 16 ROPs wären keine Steigerung zum G71, außer es wird mehr Chips auf einer PCB sein.
Dann könnte man auf 32 TMUs schätzen, sodass die alle ALUs entkoppelt sind, also wie beim G70 eine vor und eine nach der TMU...

Ich sehe immer noch keinen besonderen Grund fuer mehr als 16 ROPs; der kleine Haken ist dann eben bei jeder spekulativen Rechnung wie man genau eine ALU definiert und was jegliche genau kann.

***edit: man kann wohl USC mit non-USCs schlecht vergleichen aber das ALU<->ROP Verhaeltnis auf R580 ist insgesamt bei 3.5. Jeweils wie man rechnet ist das Verhaeltinis fuer G7x entweder 1.5 oder 3.5 (mit texture OPs oder ohne z.B. obwohl 1.5 generell zu konservativ gerechnet ist).

Jetzt denk mal an ein Design wo ALU von Tex OPs entkoppelt sind und einem reinem 4:1 Verhaeltnis (wobei man aber VS/GS Einheiten fuer non-USCs mitberechnen muss).

[Ailuros]

'Winter[Raven]'[/POST]']Nvidia aber auch ATi können mit Sicherheit einschätzen wohin der Hase laufen wird, insbesondere wenn es um Refreshs(R580) geht.

Was mich aber neben der jetzigen Diskus. interessieren würde, was ist mit dem Design passiert das als NV50 entwickelt wurde? Verschoben auf G90 oder ist es in irgendeiner Schublade verschwunden?

NV47 = G70.

[Gast]

Ailuros[/POST]']Ich sehe immer noch keinen besonderen Grund fuer mehr als 16 ROPs; der kleine Haken ist dann eben bei jeder spekulativen Rechnung wie man genau eine ALU definiert und was jegliche genau kann.

***edit: man kann wohl USC mit non-USCs schlecht vergleichen aber das ALU<->ROP Verhaeltnis auf R580 ist insgesamt bei 3.5. Jeweils wie man rechnet ist das Verhaeltinis fuer G7x entweder 1.5 oder 3.5 (mit texture OPs oder ohne z.B. obwohl 1.5 generell zu konservativ gerechnet ist).

Jetzt denk mal an ein Design wo ALU von Tex OPs entkoppelt sind und einem reinem 4:1 Verhaeltnis (wobei man aber VS/GS Einheiten fuer non-USCs mitberechnen muss).

Hab ich shcon gesagt.


Da ist es schon besser, weniger TMUs zu nehmen und Ressourcen zu sparen und den Leistung mittels den Takt zu kompensieren.

Schau dir einfach mal ein paar der Patente Nvidias aus der letzten Zeit im B3D-Forum an. Da wurde an weit mehr geforscht, als an "simplen" GS/VS-Einheiten.

Stimmt ja, die Frage ist, was den für Patente genutzt werden.

[Gast]

Ailuros[/POST]']Ich sehe immer noch keinen besonderen Grund fuer mehr als 16 ROPs;

GS zur Shadow-Volumes-Extrusion, Z-First-Pass und deutlich gesteigerte Bandbreite mit GDDR4>1GHz.
Das wären für mich ausreichende Gründe, stark über mehr als 16 ROPs nachzudenken oder die vorhandenen deutlich aufzubohren (4-AA- oder Z-Samples bsw.).

Q

[Ailuros]

Gast[/POST]']GS zur Shadow-Volumes-Extrusion, Z-First-Pass und deutlich gesteigerte Bandbreite mit GDDR4>1GHz.
Das wären für mich ausreichende Gründe, stark über mehr als 16 ROPs nachzudenken oder die vorhandenen deutlich aufzubohren (4-AA- oder Z-Samples bsw.).

Q

Wobei die zweite These momentan (mir) wahrscheinlicher klingt. GS kannst Du sowieso (stets IMHO) fuer die erste D3D10 GPUs erstmal generell vergessen.

[Neomi]

Ailuros[/POST]']GS kannst Du sowieso (stets IMHO) fuer die erste D3D10 GPUs erstmal generell vergessen.

Warum? Weil es die erste Generation mit diesem neuen Feature ist? SM2 war beim R300 (die erste GPU mit SM2) überaus brauchbar, nur mal so als kleines Gegenbeispiel. Für kleinere Dinge (z.B. deutlich bessere Pointsprites mit Rotation usw.) werden sie bestimmt reichen.

[Coda]

Also auf den Entwicklerpapers die ich gelesen lag klang es eher so: Kann man benützen aber vorsichtig sein was man damit macht, z.B. dynamic branching und Geometrie erzeugen is noch nich so toll anscheinend (zumindest auf einer der Architekturen).

[Xmas]

Man sollte aufpassen dass der Output recht klein bleibt und wenig in der Länge variiert. Da man mindestens die bisherige Point-Sprite-Leistung deutlich übertreffen will, muss auch für andere simple Algorithmen genügend Leistung vorhanden sein.

[ShadowXX]

Coda[/POST]']Also auf den Entwicklerpapers die ich gelesen lag klang es eher so: Kann man benützen aber vorsichtig sein was man damit macht, z.B. dynamic branching und Geometrie erzeugen is noch nich so toll anscheinend (zumindest auf einer der Architekturen).

Sowas in der Richtung?? (ist von der ATI Dev-Conference 2006)

GS and DrawAuto()
Talking about the Geometry Shader, Sam was realistic about performance expectations concerning the GS, somewhat hinting that without massive on-chip intermediary space in silicon, building a perfect first-gen GS is largely out of the question for the IHVs. Instead, developers should use the new functionality but be mindful about what they'll be using it for, and consequently asking the hardware to do.

In essence, layering another render stage into the API -- and one that can data amplify geometry, before rasterisation and pixel shading takes place -- does add complexity and another place for a developer to get it wrong, or for the hardware to go slow. Developers should be mindful of the power of the GS, but realistic about its usage. Sam mentioned the 1K of primitives you can possibly output, as a means to think about that further.

He also mentioned the DrawAuto function call for GS programs that doesn't wait for the GS to finish primitive output. Rather it'll send what's done down the pipe at that particular point in time, while letting the GS carry on processing asynchronously so you don't get backed up waiting for data to raster and get shaded further down the pipe.

Quelle: http://www.beyond3d.com/articles/develop-d3d10/

Wobei ich diese Autodraw sehr interessant finde....aber wahrscheinlich gibts auch da einen Pferdefuss.

[Ailuros]

Ich hab den Eindruck dass GS mit =/>D3D10.1 um einiges besser werden koennten, ausser ich hab wieder mal was falsch verstanden.

[Feuerteufel]

Ist Direct3D10.1 eigentlich auch für Vista geplant oder bleibt das dem Nachfolger vorbehalten. Die Veröffentlichungs-Abstände zwischen den Windows Versionen sollen ja verkürzt werden.

[ScottManDeath]

D3D10.1 ist in einem Service Pack für Vista.

[Godmode]

"Bis zu 200 Watt bei den neuen GPUs"
http://www.theinquirer.net/default.aspx?article=33343

Ka ob der Artikel schon gepostet wurde, aber ehrlich gesagt glaube ich nicht daran! Das wäre doch purer Wahnsinn!

[Gast]

Vor kurzem waren's mal 300...
Wie auch immer, ich glaube, das Original, was Charlie netterweise verlinkt hat, wäre aufschlußreicher: http://translate.google.com/translate?u=http%3A%2F%2Fpc.watch.impress.co.jp%2Fdocs%2F2006%2F0727%2Fkaigai291 .htm&langpair=ja%7Cen&hl=en&ie=UTF8

Vor allem: Evtl. wird hier von Dual-GPU-Karten gesprochen!


Q

[AnarchX]

http://img5.pcpop.com/ArticleImages/500x375/0/319/000319105.jpg
http://babelfish.altavista.com/babelfish/trurl_pagecontent?lp=zh_en&trurl=http%3a%2f%2fwww.pcpop.com%2fdoc%2f0%2f149%2f149121.shtml

[Gast]

Was ist daran neu? Das gibts schon ewig im SDK X-D

[Gast]

wann kommt denn jetzt der G80 ..... man hört überhaupt nichts mehr

[Nightspider]

Liebe liebe Gäste, ich mag euch wirklich sehr...aber nur selten weil ihr dauernt dumme Fragen stellt.

1. Hier kann keiner in die Kristallkugel und damit in die Zukunft schauen.

2. Wenn es neue Informationen geben würde, wären sie schon hier.

3. Stellt ihr meistens jede Frage 10 mal ohne zu raffen, das ihr warten müsst.

4. Was bringt es euch, wenn ihr den Thread zum spekulieren anregt und dabei alles schon X-mall durchgekaut wurde und die Spekulationen sowieso von den Tatsachen abweichen.

5. NERVT IHR MICH MIT DIESEN DUMMEN FRAGEN.


So, tschuldigung, musste mal raus ;D :P

[deekey777]

Liebe liebe Gäste, ich mag euch wirklich sehr...aber nur selten weil ihr dauernt dumme Fragen stellt.

1. Hier kann keiner in die Kristallkugel und damit in die Zukunft schauen.

2. Wenn es neue Informationen geben würde, wären sie schon hier.

3. Stellt ihr meistens jede Frage 10 mal ohne zu raffen, das ihr warten müsst.

4. Was bringt es euch, wenn ihr den Thread zum spekulieren anregt und dabei alles schon X-mall durchgekaut wurde und die Spekulationen sowieso von den Tatsachen abweichen.

5. NERVT IHR MICH MIT DIESEN DUMMEN FRAGEN.


So, tschuldigung, musste mal raus ;D :P

Für diesen Spam gibt es eine Verwarnung. Verzichte auf solche Postings.
Diskussionen über Verwarnungen sind bei Bedarf in einem ggf. zu erstellenden Thread im "Diskussionen zu moderativen Entscheidungen - Forum" zu führen bzw. per PN mit dem jeweiligen Moderator, denn hier wären sie OT. Siehe dazu auch: Regeln und Richtlinien für die Moderation

€: Wegen der beiden (jetzt getrashten Postings) und der Meckerei gegen die moderative Entscheidung gibt es einen Tag Auszeit. Per Email benachrichtigt und gesperrt.

[Anarchy-HWLUXX]

wann kommt denn jetzt der G80 ..... man hört überhaupt nichts mehr

Laut Hardwareluxx [printed] interview mit nVidia - SpätHerbst ... immernoch ...

[Gast]

interview mit nvidia kannst du die seite einscannen ?

[deekey777]

interview mit nvidia kannst du die seite einscannen ?
Hier sind keine Scans und Links zu diesen erlaubt.

[Palpatin]

Spätherbst? also im Dezember?

[Ailuros]

Spätherbst? also im Dezember?

Dezember ist in meinem Kalender eher Winter. Spaetherbst ist dann wohl eher October (wenn alles nach Plan laeuft blah blah blah....).

[ShadowXX]

Dezember ist in meinem Kalender eher Winter. Spaetherbst ist dann wohl eher October (wenn alles nach Plan laeuft blah blah blah....).
21. Dezember ist Winteranfang......also ist Spätherbst tatsächlich Ende November / Anfang Dezember.

[Gast]

http://www.k-hardware.de/news.php?s=c&news_id=5630

Laut Aussagen von Nvidia sollen die Shader komplett überarbeitet sein.
Ich gehe mal von 100% Mehrleistung vom G80 zum G71 aus.

[Gast]

[url]...
Ich gehe mal von 100% Mehrleistung vom G80 zum G71 aus.

Aha, und wer bist du? Ich frage nur um solche Aussagen auch einordnen zu können.

[Nightspider]

Aha, und wer bist du? Ich frage nur um solche Aussagen auch einordnen zu können.

Wayne ? - Ich.

Der G80 hat locker 48 Shader, davon kann man schon fast sicher ausgehen und jede Pipeline im G70 brachte, wenn ich mich richtig erinnere, 50% mehr Leistung als bei NV40 alias 6800Ultra.
Der G80 wird sicherlich wie vom NV40 zum G80 die doppelte Leistung haben oder mehr.

Schließlich muss man eine bedeutend schnellere Karte als die 7950GX2 abliefern.

[Iwan]

Schließlich muss man eine bedeutend schnellere Karte als die 7950GX2 abliefern.

muss man? man kann auch eine g80-gx2 bringen ;)

[Gast]

Wayne ? - Ich.

Der G80 hat locker 48 Shader, davon kann man schon fast sicher ausgehen und jede Pipeline im G70 brachte, wenn ich mich richtig erinnere, 50% mehr Leistung als bei NV40 alias 6800Ultra.
Der G80 wird sicherlich wie vom NV40 zum G80 die doppelte Leistung haben oder mehr.

Schließlich muss man eine bedeutend schnellere Karte als die 7950GX2 abliefern.

Oder man baut gleich 2 Chips auf einer Karte.
Nur das es keine Doppelte Leistung vom Nv40 zum G70 gab.
Wenn man bedenkt das gerade mal die Hälfte der Shader zugänglich war und das es warscheinlich 32 PP und 16VS sind, wird es nur eine Leistungsteigerung von höchstens 60% sein.

mfg Nakai

[Nightspider]

Muss man theoretisch schon, wenn man nicht hinterhergesagt bekommen will, das eine einzelne Karten der alten Generation billiger und genauso schnell is wie das neueste vom Markt.

Ich denke eine G80-GX2 Karte kommt wenn auch erst paar Monate später oder ? Sonst würde die ja am Anfang gleich 700€ oder so kosten...

...wobei...naja...hm...dann müsste Nvidia die G80-GX2 Variante gleich an die Leistungsspitze setzen und die 7950 GX2 kostet dann vllt 400, der G80 450-500€ und der G80-GX2 dann 550-600 Euro.
Naja...is wohl doch besser abzuwarten, als zu spekulieren ^^

[Nightspider]

Oder man baut gleich 2 Chips auf einer Karte.
Nur das es keine Doppelte Leistung vom Nv40 zum G70 gab.
Wenn man bedenkt das gerade mal die Hälfte der Shader zugänglich war und das es warscheinlich 32 PP und 16VS sind, wird es nur eine Leistungsteigerung von höchstens 60% sein.

mfg Nakai

Ich errinnere mich da an paar Unreal3 Benchies, wo eine G70 minimal schneller war als 2*6800 Ultra im SLI.
Aber in manchen Spielen war sie wirklich schon bedeutend schneller oder ?
*nichmehr sooo genau weiß*

Srry 4 Doppelpost

[Slipknot79]

g80-X2 wäre zu kompliziert. Der Trend geht (schon immer) in Richtung Zusammenwachsen. Erst ist es eine Graka. Dann SLI. Dann 2 GPUs auf einem Board. Dann Quad-SLI. Nächster logischer Schritt: DualCore-GPU (+SLI)

[Nightspider]

g80-X2 wäre zu kompliziert. Der Trend geht (schon immer) in Richtung Zusammenwachsen. Erst ist es eine Graka. Dann SLI. Dann 2 GPUs auf einem Board. Dann Quad-SLI. Nächster logischer Schritt: DualCore-GPU (+SLI)

DualCore GPUs kommen frühestens 2007.
Ati bestätigte bereits das der R600 Nachfolger Dualcore-GPU wäre.
Nvidia wird wahrscheinlich auch erst 2007-2008 Dualcore-GPUs bringen.
Denn vorher kommen 2007 noch G80 und R600 Refresh und da is Dualcore eher unwahrscheinlicher.

[AnarchX]

DualCore GPUs kommen frühestens 2007.
Ati bestätigte bereits das der R600 Nachfolger Dualcore-GPU wäre.
Nvidia wird wahrscheinlich auch erst 2007-2008 Dualcore-GPUs bringen.
Denn vorher kommen 2007 noch G80 und R600 Refresh und da is Dualcore eher unwahrscheinlicher.

ATI sprach von einer GPU mit 2 Kernen und nicht von einem Die wo zweimal die gleiche Struktur drauf ist...;)
So genannte Dualcore-GPUs wird es nicht geben, da es einfach Unsinn ist soetwas zu fertigen.

[Nightspider]

ATI sprach von einer GPU mit 2 Kernen und nicht von einem Die wo zweimal die gleiche Struktur drauf ist...;)
So genannte Dualcore-GPUs wird es nicht geben, da es einfach Unsinn ist soetwas zu fertigen.

Dualcore heißt 2 Kerne pro GPU, wie du sagst. Es steht ja nirgents, das dies 2 100%ig gleiche Kerne sein müssen oder ?

2 getrennte Kerne, Dual GPU
2 Kerne, die auf einem Package sind sind bei mir Dualcore

Wen interessiert schon, ob das jetzt 2 vers. Kerne sind. Das werden wir dann sehen. Kein Grund jetzt schon über sowas zu Disskutieren, wenn du mich fragst. :)

[Ailuros]

Oder man baut gleich 2 Chips auf einer Karte.
Nur das es keine Doppelte Leistung vom Nv40 zum G70 gab.
Wenn man bedenkt das gerade mal die Hälfte der Shader zugänglich war und das es warscheinlich 32 PP und 16VS sind, wird es nur eine Leistungsteigerung von höchstens 60% sein.

mfg Nakai

NV4x und G7x gehoeren zur gleichen Generation; es sollte wohl klar sein dass in vielen Aspekten der Unterschied zwischen G8x und deren Vorgaengern ziemlich gross ist, das es beim letzteren um eine neue Generation handelt.

Jegliche Anzahl von Einheiten ist sinnlos wenn man nicht weiss wozu jegliche faehig ist; wie Du jetzt auf die angeblichen 60% gekommen bist ist mir fremd. Aber falls Du als Basis G71 + 2 quads und ein paar mehr VS + GS genommen hast, erinnere ich nochmal daran dass eine G7x ALU != eine G8x ALU ist und das nur als Anfang.

Die finale Leistung muss um ein gesundes Prozentual ueber der einer 7950GX2 liegen, sonst hat NV eine Unmenge von Transistoren verplempert.

[Gast]

Ich errinnere mich da an paar Unreal3 Benchies, wo eine G70 minimal schneller war als 2*6800 Ultra im SLI.
Aber in manchen Spielen war sie wirklich schon bedeutend schneller oder ?
*nichmehr sooo genau weiß*

Srry 4 Doppelpost

Nein es war wie 2 6800Gt im SLI.

Ich habe 60%, weil es einfach am schlüssigsten aussieht.
Wenn man beim G80 die gleichen ALUs nimmt, kommt auf 50% Mehrleistung.
Da ich mir aber nicht vorstellen kann, dass die Architektur so sehr geändert wird, also werden die ALUs wahrscheinlich Leistungsfähiger konzipert und vll auch mehr davon, dann kann man sich eine Mehrleistung von etwa 60 bis 70% herausschätzen, und das nur in DX9-Anwendungen.

[Botcruscher]

ATI sprach von einer GPU mit 2 Kernen und nicht von einem Die wo zweimal die gleiche Struktur drauf ist...;)
So genannte Dualcore-GPUs wird es nicht geben, da es einfach Unsinn ist soetwas zu fertigen.

Och laut Intel ist das auch DC.;) Schon aus dem einfachen Grunde das sich 2x300Mio Transistoren besser herstellen lassen als 1x600, wird es bald Dual Core geben.

[Gaestle]

Och laut Intel ist das auch DC.;) Schon aus dem einfachen Grunde das sich 2x300Mio Transistoren besser herstellen lassen als 1x600, wird es bald Dual Core geben.

Hmmm... C1 hat's DIESBEZÜGLICH vorgemacht. Aber ob der Grund bei C1 ein Komplexitätsproblem war, steht woanders. Und ob die spekulierten 500-600Mio Tans. bei den geplanten Prozessen ein Komplexitätsproblem darstellen werden, steht auch woanders.

[Nightspider]

Hm, naja, wenn der G80 erst Ende des Jahres kommt is auch net so schlimm.
Hauptsache der is mindestens 100% schneller als eine 7900 GTX

denn dafür werden wirs wohl dann sehr brauchen: http://www.crysis-hq.de/

Kann man die Geometrie Shader auch für Physik nutzen irgentwie ? ^^