Nvidias NV40

[Winter[Raven]]

Bei The Inquirer ist nachzulesen das der NV40 keine 8x2 Architekrut haben wird, sondern viel mehr eine 12x2, und das es ein PCI Express Steckplatzt haben soll.

http://www.theinquirer.net/?article=10601

[Demirug]

:cop: FUAD :cop:

Follow
Up
Advanced
Disinformation

[nggalai]

LOL

der ist gut, Demiurg! Von dir? :D

93,
-Sascha.rb

[Demirug]

Original geschrieben von nggalai
LOL

der ist gut, Demiurg! Von dir? :D

93,
-Sascha.rb

Ja, ist mir gerade eben eingefallen. :D

[Aqualon]

Dass das Teil dann immer noch ne GeForce sein wird, könnte ja sogar stimmen.

In jeder Legende steckt halt ein wahrer Kern ;)

Aqua

[Ailuros]

Original geschrieben von Winter[Raven]
Bei The Inquirer ist nachzulesen das der NV40 keine 8x2 Architekrut haben wird, sondern viel mehr eine 12x2, und das es ein PCI Express Steckplatzt haben soll.

http://www.theinquirer.net/?article=10601

Was nachzulesen ist, ist der folgende Satz:

....whioch leads us to speculate the next Nvidia part will likely use 12 pipelines.

Uebrigens ist bei solchen Architekturen eine Pipeline nicht mehr so ganz was man frueher darunter verstehen konnte (ausser dem back-end natuerlich).

Wie sieht es denn mit der Busbreite aus bei den hypothetischen 12 pipelines hm? Ganz doofe Vereinfachung die nicht unbedingt Sinn macht, aber 12*32*2=768. *gruebel*

[Demirug]

Original geschrieben von Ailuros
Uebrigens ist bei solchen Architekturen eine Pipeline nicht mehr so ganz was man frueher darunter verstehen konnte (ausser dem back-end natuerlich).

Warum? Zwölf Pipelines könnte man gut als 3*4 verwalten. Aber genau hier haben wir das Problem. nv steht nun mal scheinbar auf die Verwendung von 2 TMUs pro Pipe. Aus den 12 Pipes würde dann ganz schnell 6 werden. & Pipes sind aber irgendwie blöd.

Wie sieht es denn mit der Busbreite aus bei den hypothetischen 12 pipelines hm? Ganz doofe Vereinfachung die nicht unbedingt Sinn macht, aber 12*32*2=768. *gruebel* [/SIZE]

Ja man muss aber auch noch das Taktverhältniss zwischen Core und Speicher berücksichtigen. Wenn wir mal von einem 600 MHz Core und 800 MHz Speicher ausgehen haben wir ein verhältniss von 1,33. 768 / 1,33 = 578. Ergo 12 Pixel/Takt sind mit einem 256 Bit Interface eher was fürs Papier als wirklich praktisch.

[Ailuros]

Warum? Zwölf Pipelines könnte man gut als 3*4 verwalten. Aber genau hier haben wir das Problem. nv steht nun mal scheinbar auf die Verwendung von 2 TMUs pro Pipe. Aus den 12 Pipes würde dann ganz schnell 6 werden. & Pipes sind aber irgendwie blöd.

Uhmmm was hat das mit meiner Notiz zu tun dass Pipelines nicht mehr so ganz das gleiche heissen wie frueher? Einfaches Beispiel NV30/5= 4*2 oder 8*1.

Ja man muss aber auch noch das Taktverhältniss zwischen Core und Speicher berücksichtigen. Wenn wir mal von einem 600 MHz Core und 800 MHz Speicher ausgehen haben wir ein verhältniss von 1,33. 768 / 1,33 = 578. Ergo 12 Pixel/Takt sind mit einem 256 Bit Interface eher was fürs Papier als wirklich praktisch.

Ich sagte ja dumme Vereinfachung. Wie man es auch ausrechnet ist das ganze mit 256bit Busbreite eigentlich Schwachsinn.

[RyoHazuki]

wenn das stimmen sollte, dann wirds wieder so ne pipe die nur unter bestimmten bedingungen wie eine 12x2 architektur arbeitet !

ansonsten denke ich an 8x2 (sehe ich für VIIIIEEEEELLLL wahrscheinlicher)

eine 8x4 architektur wäre natürlich (aus meiner sicht) der wahnsinn pur !!!

8 x 500 - 600 takt = 4 GPixel - 4,8 GPixel x 4 = 16 Gtexel - 19,2 Gtexel !

UIIII da schlägt das herz höher !

[bendel]

Ich glaube nicht, dass es im Hinlbick auf hoehere Shadervsersionen Sinn macht, mehr als eine TextureUnit pro Pipe zu verbauen. Zumindest wenn die Pipe dann nicht mehr als eine Arithmetrikoperation pro Takt schafft.

[aths]

Original geschrieben von bendel
Ich glaube nicht, dass es im Hinlbick auf hoehere Shadervsersionen Sinn macht, mehr als eine TextureUnit pro Pipe zu verbauen. Das macht NV aber... NV30 und NV35 haben eine 4x2-Architektur.

[Ailuros]

Hast Du mit Absicht seinen zweiten Satz uebersehen?

[Exxtreme]

Original geschrieben von RyoHazuki
wenn das stimmen sollte, dann wirds wieder so ne pipe die nur unter bestimmten bedingungen wie eine 12x2 architektur arbeitet !

ansonsten denke ich an 8x2 (sehe ich für VIIIIEEEEELLLL wahrscheinlicher)

eine 8x4 architektur wäre natürlich (aus meiner sicht) der wahnsinn pur !!!

8 x 500 - 600 takt = 4 GPixel - 4,8 GPixel x 4 = 16 Gtexel - 19,2 Gtexel !

UIIII da schlägt das herz höher !
Bringt dir aber nix wenn die Spiele keine 4 Texturlayer nutzen und das ist z.Zt. bei den meisten Spielen der Fall.

[robbitop]

wieso 4 Texturlagen?
wenn ich trilinear filtere habe ich nur noch 2 Texturlagen pro Takt, bei 2x tri AF nur noch eine.
Aber ineffektiv ist es sicher. Ich bin für TMUs mit mehr Samples.

Jedoch darf man die CineFX Pipelinestruktur nicht mit konservativen Pipelinestrukturen vergleichen. Aber ich glaube dieses Thema wurde in den letzten Monaten oft genug durchgekaut...

ich bin weiterhin für ein hir Z Verfahren im NV40 und trilineare TMUs

[Exxtreme]

Original geschrieben von robbitop
Jedoch darf man die CineFX Pipelinestruktur nicht mit konservativen Pipelinestrukturen vergleichen. Aber ich glaube dieses Thema wurde in den letzten Monaten oft genug durchgekaut...

So viel anders ist diese Architektur in der Praxis auch nicht. In den meisten Fällen ist es halt dann doch 4x2 bilinear. :)

Die Stencil-Sache ist eine Ausnahme.

[robbitop]

ähm aber nicht was die PS ALUs betrifft. da sieht es eben anders aus.

[Exxtreme]

Original geschrieben von robbitop
ähm aber nicht was die PS ALUs betrifft. da sieht es eben anders aus.
Sie sind zwar anders als die von ATi, ob sie in der Praxis besser sind, das wird sich erst herausstellen müssen. Und einen Nachteil hat die bisherige Implementierung schon, es steht 8 zu 4 für ATi.

[robbitop]

richtig, aber da Shaderperformance nicht ausschlaggebend ist derzeit, kann man Transistoren sparen, weiterhin ist eine so ähnliche Architektur notwendig für effektiven PS3 Einsatz ;)

positiv ist es nicht unbedingt, aber im gegensatz zum Ersparten ist das Defizit nicht so gross und die Deto50 sollen ja durch vernünftige Compilierung die Shaderleistung nach oben bringen

[Exxtreme]

Original geschrieben von robbitop
positiv ist es nicht unbedingt, aber im gegensatz zum Ersparten ist das Defizit nicht so gross und die Deto50 sollen ja durch vernünftige Compilierung die Shaderleistung nach oben bringen
Wenn die Shader aber schon im Pseudo-Assembler-Format vorliegen, dann holt auch der beste Treiber nicht mehr viel raus. :)

Um gescheite Geschwindigkeit rauszuholen müsste man die Shader vor der Kompilierung an den Treiber übergeben.

[robbitop]

tja wer weiss was die 50er mit sich bringen? vieleicht einen shaderoptimizer oder eine entsprechende Datenbank, die sich per klick aktualisiert. Nunja das haben wir aber auch alles schonmal durchgekaut, man darf also gespannt sein.

[Exxtreme]

Original geschrieben von robbitop
tja wer weiss was die 50er mit sich bringen? vieleicht einen shaderoptimizer oder eine entsprechende Datenbank, die sich per klick aktualisiert. Nunja das haben wir aber auch alles schonmal durchgekaut, man darf also gespannt sein.
Also ich erwarte keine Wunder. Höchstens bei applikationsspezifischen Optimierungen sehe ich grössere Verbesserungsmöglichkeiten. Eine generelle Optimierung von Pseudo-Assembler-Code ist nicht so ohne Weiteres möglich.

[Demirug]

Original geschrieben von Exxtreme
Also ich erwarte keine Wunder. Höchstens bei applikationsspezifischen Optimierungen sehe ich grössere Verbesserungsmöglichkeiten. Eine generelle Optimierung von Pseudo-Assembler-Code ist nicht so ohne Weiteres möglich.

Doch es geht. Man wandelt den Shaderassemblercode wieder in HLSL/CG zurück und jagt in dann erneut durch den Compiler. Die Hauptprobleme (ungünstige Anweisungsfolgen, zu viele Temp Variablen) bekommt man damit recht gut in den Griff. Direkt von ursprünglichen HLSL Code wäre zwar noch besser aber man nimmt was man bekommt.

[Exxtreme]

Original geschrieben von Demirug
Doch es geht. Man wandelt den Shaderassemblercode wieder in HLSL/CG zurück und jagt in dann erneut durch den Compiler. Die Hauptprobleme (ungünstige Anweisungsfolgen, zu viele Temp Variablen) bekommt man damit recht gut in den Griff. Direkt von ursprünglichen HLSL Code wäre zwar noch besser aber man nimmt was man bekommt.
Ob das tatsächlich so einfach geht, bezweifle ich. :)
Es würde nur funktionieren wenn man wüsste, mit welchem Compiler der Pseudo-Assembler-Code vorher erzeugt worden ist.

Ich habe schon mal einen Assembler_zu_C-Konverter ausprobiert. Dieser funktionierte nur richtig, wenn der ursprüngliche Code absolut unoptimiert war.


Wobei man sagen muss, daß der Shadercode deutlich primitiver zu sein scheint als der CPU-Code.

[Demirug]

Original geschrieben von Exxtreme
Ob das tatsächlich so einfach geht, bezweifle ich. :)
Es würde nur funktionieren wenn man wüsste, mit welchem Compiler der Pseudo-Assembler-Code vorher erzeugt worden ist.

Ich habe schon mal einen Assembler_zu_C-Konverter ausprobiert. Dieser funktionierte nur richtig, wenn der ursprüngliche Code absolut unoptimiert war.


Wobei man sagen muss, daß der Shadercode deutlich primitiver zu sein scheint als der CPU-Code.

Ich weiss das es geht weil ich selbst sowas in der Art mache.

Wie du schon sagst geht es ja nicht um ein ganzen Programm mit tausenden von Zeilen Code welches wieder in Lessbare form zurück gebracht werden soll. Es sind nur ein paar Zeilen Code. Macht man nun aus einer Zeile Assemblercode wieder eine Zeile HLSL/Cg ist das zwar nicht gut für einen Menschen zu lesen aber der Compiler kommt damit gut zurecht. Zudem ist Shaderassembler eine einfach aufgebaut das gibt es keine grossartiken optimierungstricks. Optimierung beim den Shadern heist ganz einfach:

- Anweisungen sparen
- Register richtig benutzten
- Richtige Rheienfolge (wie beim ersten Pentium)

nvidia kann sich im Treiber natürlich den umweg über HLSL/Cg sparen. Die übersetzten den Assemblercode einfach in die breits geparste und gelexte Interne Struktur welcher der Compiler benutzt.

[Pathfinder]

Original geschrieben von Demirug
Ich weiss das es geht weil ich selbst sowas in der Art mache.

Wie du schon sagst geht es ja nicht um ein ganzen Programm mit tausenden von Zeilen Code welches wieder in Lessbare form zurück gebracht werden soll. Es sind nur ein paar Zeilen Code. Macht man nun aus einer Zeile Assemblercode wieder eine Zeile HLSL/Cg ist das zwar nicht gut für einen Menschen zu lesen aber der Compiler kommt damit gut zurecht. Zudem ist Shaderassembler eine einfach aufgebaut das gibt es keine grossartiken optimierungstricks. Optimierung beim den Shadern heist ganz einfach:

- Anweisungen sparen
- Register richtig benutzten
- Richtige Rheienfolge (wie beim ersten Pentium)

nvidia kann sich im Treiber natürlich den umweg über HLSL/Cg sparen. Die übersetzten den Assemblercode einfach in die breits geparste und gelexte Interne Struktur welcher der Compiler benutzt.

Ich glaube auch, daß es möglich ist, den Code zu optimieren, und diese Optimierung wäre eine zweifelsfrei legale Optimierung verglichen mit mathematisch-/visuell Näherungen in Form von benchmark-/situationsabhängigen, handgeschriebenen Shadern.

Aber wenn es denn so einfach ist, wie du es andeutest, warum hebt sich NVidia den ultimativen 'Shaderperformance-Durchbruch' erst für Monate nach dem Release der DX9-Shaderhardware auf? Marktpolitischen Weitsicht als Grund möchte ich ausschließen, denn zu stark ist die Konkurrenz von ATI, als daß man sie ignorieren hätte können?!

G.
P.

[Demirug]

Original geschrieben von Pathfinder
Ich glaube auch, daß es möglich ist, den Code zu optimieren, und diese Optimierung wäre eine zweifelsfrei legale Optimierung verglichen mit mathematisch-/visuell Näherungen in Form von benchmark-/situationsabhängigen, handgeschriebenen Shadern.

Aber wenn es denn so einfach ist, wie du es andeutest, warum hebt sich NVidia den ultimativen 'Shaderperformance-Durchbruch' erst für Monate nach dem Release der DX9-Shaderhardware auf? Marktpolitischen Weitsicht als Grund möchte ich ausschließen, denn zu stark ist die Konkurrenz von ATI, als daß man sie ignorieren hätte können?!

G.
P.

1. Diese Optimierung setzt vorraus das der Compiler komplett und immer richtig funktioniert. Scheinbar sind da aber stellenweise noch ein paar kleine Fehler enthalten.

2. OpenGL 2.0 (jetzt 1.5): Dort braucht man ja auch noch einen Compiler im Treiber. Möglicherweise wollte nv warten bis die Spec komplett ist um da einen synergieeffekt zu bekommen und die Arbeit nicht doppelt zu machen.

[Exxtreme]

Original geschrieben von Demirug
1. Diese Optimierung setzt vorraus das der Compiler komplett und immer richtig funktioniert. Scheinbar sind da aber stellenweise noch ein paar kleine Fehler enthalten.

Eben. Und deswegen ist es IMHO doch nicht sooo einfach... zumindest nicht wenn es signifikante(!!) Geschwindigkeitssteigerungen bringen soll. Liegt in der Natur der Sache.

Original geschrieben von Demirug
2. OpenGL 2.0 (jetzt 1.5): Dort braucht man ja auch noch einen Compiler im Treiber. Möglicherweise wollte nv warten bis die Spec komplett ist um da einen synergieeffekt zu bekommen und die Arbeit nicht doppelt zu machen.
Naja, damit verspielt man sich marketingtechnisch Vieles. Die CineFX-Architektur hat z.Zt. eher den Ruf, daß sie DX9-Sachen eher gemächlich abarbeitet. ;)

[LovesuckZ]

Original geschrieben von Exxtreme
Naja, damit verspielt man sich marketingtechnisch Vieles. Die CineFX-Architektur hat z.Zt. eher den Ruf, daß sie DX9-Sachen eher gemächlich abarbeitet. ;)

Naja, nur die halben "DX9 - Sachen", da die VS2.0 gut arbeiten (siehe GunMetal).

[Demirug]

Original geschrieben von Exxtreme
Eben. Und deswegen ist es IMHO doch nicht sooo einfach... zumindest nicht wenn es signifikante(!!) Geschwindigkeitssteigerungen bringen soll. Liegt in der Natur der Sache.

Die Geschwindigkeit ist nicht das Problem. Die älteren Compiler (mit dem aktuellen ist mir noch nichts aufgefallen) neigten schon mal dazu fehler einzubauen die dann zu falschen Resultaten führten.

Naja, damit verspielt man sich marketingtechnisch Vieles. Die CineFX-Architektur hat z.Zt. eher den Ruf, daß sie DX9-Sachen eher gemächlich abarbeitet. ;)

IMHO ist die Änderung an dem Coresystem so gross das man das nicht in die aktuellen Detos reinbauen wollte.

[Ailuros]

richtig, aber da Shaderperformance nicht ausschlaggebend ist derzeit, kann man Transistoren sparen, weiterhin ist eine so ähnliche Architektur notwendig für effektiven PS3 Einsatz

Robbi,

Schon mal an einen PR Job fuer einen gewissen IHV gedacht? :D

Na Spass beiseite, das ganze ist bei weitem keine Entschuldigung fuer sehr niedrigere Leistung mit besagten Shadern; wenn es nur eine Software Sache ist bzw. fehlenden Optimierungen, dann hatte man jetzt schon fast ein Jahr (wenn nicht mehr) Zeit dafuer. Zu dem sind Simulatoren da.

[robbitop]

Klar, das war gut oder?
Aber nur eine Kostprobe ^^

Mal ernst, klar hast du Recht, aber für den heutigen Anwender reicht die leistung meist aus, um nicht limitierende Komponente zu sein.
Was fehlt ist Füllrate, aber für zukünftige Anwendungen hast du mit Sicherheit recht. Und wer weiss was der Deto50 rausholt.

Aber die sache mit CineFX ist klar in die Hose gegangen und das kann man natürlich auch nicht schönreden...entschuldigt bitte, wenn es so klang ;)

[Ailuros]

Wenn ich meine Meinung ausdruecke was in heutigen NV Produkten wirklich fehlt, werde ich hoechstwahrscheinlich von den NV-fans wieder sinnlos angebruellt. Und dabei meine ich nur Sachen die man auch wirklich gebrauchen kann. Mipmapping waere ein guter Anfang.

Aber die sache mit CineFX ist klar in die Hose gegangen und das kann man natürlich auch nicht schönreden...entschuldigt bitte, wenn es so klang.

So meinte ich es nun auch wieder nicht. Ich meinte nur dass NV zwar den Vorteil mit der CPU-artigen Logik hat im NV3x, aber dass heisst nun auch wieder nicht dass die Konkurrenz nicht ohne Vorteile dasteht. Es gibt so einige Sachen nach denen NV sich kuemmern muss, zu den die Konkurrenz schon seit Herbst letzten Jahres faehig ist.

Uebrigens zugegeben PS/VS2.0 koennen dem Gamer heute egal sein. Dagegen aber ist es um einige Male schlimmer momentan mit PS/VS3.0. Obwohl ich zugegeben mit meinem begrenzten Wissen die Kombination des VS3.0 und eines PPP hoechst interessant finde. Zwei Jahre nach 3.0 Vorstellung? Na so etwa...leider natuerlich :(

[MadManniMan]

Also für mich persönlich ist für die neuen Pipes von ATi/nV vor allem die TriTMU-Implementierung wichtig.

...nur mal so BTW... :eyes:

[aths]

Original geschrieben von MadManniMan
Also für mich persönlich ist für die neuen Pipes von ATi/nV vor allem die TriTMU-Implementierung wichtig.

...nur mal so BTW... :eyes: Mal keine halben Sachen. Mir ist 16-sample-Filtering wichtig, also TF aus einer MIP-Map. Hat nebenbei die bessere Bildqualität.

[MadManniMan]

Original geschrieben von aths
Mal keine halben Sachen. Mir ist 16-sample-Filtering wichtig, also TF aus einer MIP-Map. Hat nebenbei die bessere Bildqualität.

Wie wa wum? Habs schon öfter gehört, aber was heißt das eigentlich - aus einer Mip?

:kratz:

[Demirug]

Original geschrieben von MadManniMan
Wie wa wum? Habs schon öfter gehört, aber was heißt das eigentlich - aus einer Mip?

:kratz:

Tri aus nur einer Mip ist das beste Tri das man bekommen kann. 16 Texel pro Sample wie aths schon schreibt vorrausgesetzt.

Normalerweise werden zum erzuegen eines tri samples jeweils 4 Texel aus einer Mipmap genommen. Da man zwei Mips benutzt ergibt das 8 Texel.


Mipmap0:

0000
0XX0
0XX0
0000

Mipmap1:

0000
0XX0
0XX0
0000

X = Benutzt
0 = unbenutzt



Beim Tri aus einer Mip sieht das dann so aus:


Mipmap0:

XXXX
XXXX
XXXX
XXXX

Mipmap1:

0000
0000
0000
0000

X = Benutzt
0 = unbenutzt



Da die 4 Texel aus Mipmap1 genau den gleichen Inhalt wie die 16 Texel aus Mipmap0 enthalten braucht man aus dieser nicht mehr zu samplen da ja keine neuen Informationen mehr dazu kommen können. Da die Gewichtung aber pro texelbestimmt wird ist die Qualität bei 16 texel mit 16 Gewichtungen natürlich besser als bei 8 Texel mit 8 Gewichtungen.

[MadManniMan]

Original geschrieben von Demirug
Tri aus nur einer Mip ist das beste Tri das man bekommen kann. 16 Texel pro Sample wie aths schon schreibt vorrausgesetzt...

Hm, klingt schlüssig. Wie siehts eigentlich momentan aus: Lassen die Designer bei den Neuerscheinungen eigentlich die Mips von der API erzeugen, oder liefern sie sie noch immer mit?

[ShadowXX]

@Demirug:

nur mal so als Frage, wenn wir gerade dabei sind:

Wäre auch ein Hardware AF-Filter möglich??

J.S.Shadow

[Aquaschaf]

Wenns jemanden in den Sinn kommen würde, sogar 16x triAF TMU's wären möglich.

[Demirug]

Original geschrieben von MadManniMan
Hm, klingt schlüssig. Wie siehts eigentlich momentan aus: Lassen die Designer bei den Neuerscheinungen eigentlich die Mips von der API erzeugen, oder liefern sie sie noch immer mit?

Keine Ahnung ich habe da keine Untersuchungen angestellt. Ist sowieso eine Frage des persönlichen Geschmacks.

[MadManniMan]

Original geschrieben von Demirug
Keine Ahnung ich habe da keine Untersuchungen angestellt. Ist sowieso eine Frage des persönlichen Geschmacks.

Wenn du auch sonst nix zu deinem Projekt ausplauderst - was ziehst du vor?

[Demirug]

Original geschrieben von MadManniMan
Wenn du auch sonst nix zu deinem Projekt ausplauderst - was ziehst du vor?

Normalerweise beim Laden erzeugen. Komprimierte Texturen können da aber eine Aussnahme darstellen.

[robbitop]

btw für eine zukünftige DX Version ist ein Feature "Pixelshader AF" geplant, somit verliert man dann wohl keine Füllrate beim Aniisotropen Filern

[MadManniMan]

Original geschrieben von robbitop
btw für eine zukünftige DX Version ist ein Feature "Pixelshader AF" geplant, somit verliert man dann wohl keine Füllrate beim Aniisotropen Filern

Öh, ich denke eigentlich eher, daß damit gemeint ist, daß dann auch mal auf PS AF richtig wirkt...

:kratz2:

[robbitop]

nein, ich habe diesen jmd gefragt, ob es das ist was ich vermute, er sagte ja und er muss es wissen ;) (mehr sag ich nich)

[Demirug]

Original geschrieben von robbitop
btw für eine zukünftige DX Version ist ein Feature "Pixelshader AF" geplant, somit verliert man dann wohl keine Füllrate beim Aniisotropen Filern

Dann weisst du mehr als ich. Wenn man im Pixelshader auf eine Texture zugreift dann wird diese laut den einstellungen gefiltert. Möchte man nun einzelne Berechnungen innerhalb eines PS mit Aniso durchführen muss man eben eine Schleife einbauen. Mit den PS 3.0 geht sowas ja.

[robbitop]

tut mir leid ich bin auf diesem Gebiet kein Experte :)
aber das ist eben das was ich erfahren habe

[Demirug]

Original geschrieben von robbitop
tut mir leid ich bin auf diesem Gebiet kein Experte :)
aber das ist eben das was ich erfahren habe

Nicht falsch verstehen. :)

Machbar ist das schon. Mann läst dafür einfach den Pixelshader für unterschiedliche Positionen auf einer gedachten Linie welche in der Neigungrichtung verläuft sampeln.

Was mir nur neu wäre ist das so ein Feature für DX geplannt ist. Weil bisher immer gesagt wurde das man das mit den Schleifen in PS 3.0 machen soll.

Zudem glaube ich an irgendwelche Features nur noch wenn ich das ganze von MS offiziel bekomme. Im Vorfeld gibt es da immer so viele Gerüchte.

[robbitop]

und diese Chance besteht natürlich, dass es eben nur ein Gerücht ist, aber immerhin ein netter Ansatz :D

[strickjackenscheitel]

fuer mich ist die sache ganz klar.

der nv 40 wird ein chip mit ner 8x2 archi. warum? 4x2 soll klasse fuer alte spiele sein und 8x1 fuer neue. der spagat duerfte fuer den neuen chio zutreffen. ausserdem ist ja jetzt schon ziemlich sicher das es (irgend)eine pipelineerweiterung geben wird, alles andere waere ja auch wirklich komisch, ne?

dann kommen noch bandbreitenschonende features hinzu und vorallem deutlich hoehere taktraten. warum das?
schaut man sich den schritt von gf3 ti zu gf4 ti an, dann ist das vorwiegend mehr takt. anders wird das hier nicht. also ein typisches refresh.

viel mehr kann man einfach nicht erwarten.

das nv nicht auf multichiparchitekturen steht, wissen wir mittlerweile.

dieser spezielle ram, der auch auf dem bitboyschip haette draufkommen sollen (name glatt vergessen ... e-dram? eddr??? k.a.), klaut meiner meinung nach einfach zuviel transitoren, vergleicht man dies mit anderen moeglichen features.
und "gerade" 150mill. transistoren sollten es inklusive der neuen pipes dann schon sein, oder?

also ich denke das der nv40 von den features unspektakulaer wird.

[Exxtreme]

[B]Original geschrieben 4x2 soll klasse fuer alte spiele sein und 8x1 fuer neue.
Nö.

8x2 > 8x1 > 4x2. Und das gilt eigentlich für alle Spiele, egal ob alt oder neu. :)

[Razor@Work]

Original geschrieben von Exxtreme
Nö.

8x2 > 8x1 > 4x2. Und das gilt eigentlich für alle Spiele, egal ob alt oder neu. :)
Wo steht das ?
???

Razor

[Exxtreme]

Original geschrieben von Razor@Work
Wo steht das ?
???

Razor
Ich behaupte das mal. :D

[StefanV]

Original geschrieben von Razor@Work
Wo steht das ?
???

Razor

über deinem Posting??

[Gast]

Original geschrieben von Stefan Payne
über deinem Posting??
Sollte das jetzt witzig gewesen sein ?
Stefääään spääääämt !
:D

Razor

[Razor@Work]

Original geschrieben von Exxtreme
Ich behaupte das mal. :D
Ohne es zu belegen ?
OK, als Deine persönliche, nicht belegte Meinung ist dies akzeptiert !
:D

Razor

[Exxtreme]

Original geschrieben von Razor@Work
Ohne es zu belegen ?
OK, als Deine persönliche, nicht belegte Meinung ist dies akzeptiert !
:D

Razor
Wenn du drüber nachdenkst und halbwegs etwas von 3D-Technologie verstehst, dann sollte es dir halbwegs einleuchten.

Natürlich ist es nur eine Theorie da es keine 8x2-GPUs gibt und man es nicht testen kann.

[strickjackenscheitel]

ehm die 4x2 und 8x1 architekturen haben doch etwas mit single-texturing und mutlitexturing am hut.

die eine archtitektur ist besser fuer singletexturing und die andere ... klar.

eine von den beiden "texturverfahren" werden vermehrt in neuen spielen eingesetzt, die andere bei alten.

deswegen meinte ich, dass meiner meinung nach nv mit dem nv40 den spagat zwischen alten und neuen spielen mit einer 8x2 archi. schaffen will.

ich hab das nicht geschrieben, weil ich da so garkeine ahnung habe und niemanden zum lachen bringen wollte. =)

[Aquaschaf]

Ist ja irgendwie logisch,

4*2 -> 8 TMU + 4 Rest der Pipeline oder was auch immer
8*1 -> 8 TMU + 8 Rest der Pipeline
8*2 -> 16TMU + 8 Rest der Pipeline

[Gast]

Original geschrieben von Exxtreme
Wenn du drüber nachdenkst und halbwegs etwas von 3D-Technologie verstehst, dann sollte es dir halbwegs einleuchten.

Natürlich ist es nur eine Theorie da es keine 8x2-GPUs gibt und man es nicht testen kann.
Ich versteh' doch aber rein gar nichts von "3D-Technologie" !
;D

Mir geht es aber um folgende Relation:

8x1 > 4x2Warum sollte das für jeden Fall gelten ?
Wäre es nicht vorstellbar, dass - architektonisch begründet - 4x2 durchaus besser sein kann, als 8x1 ? Und selbst wenn wir derzeitige Implementierungen vegleichen... bis Du der Meinung, dass hier 8x1 grundsätzlich (oder auch "immer" ;-) besser, als 4x2 ist ? Wenn ja, warum ?

Auch ich bin der Meinung, dass 8x1 generell flexibler einzusetzen ist, würde aber niemals wagen, dies in jeder Situation der Fall ist.

Razor

[Razor@Work]

Original geschrieben von Aquaschaf
Ist ja irgendwie logisch,

4*2 -> 8 TMU + 4 Rest der Pipeline oder was auch immer
8*1 -> 8 TMU + 8 Rest der Pipeline
8*2 -> 16TMU + 8 Rest der Pipeline
???

[Exxtreme]

Original geschrieben von Gast
Ich versteh' doch aber rein gar nichts von "3D-Technologie" !
;D

Mir geht es aber um folgende Relation:

8x1 > 4x2Warum sollte das für jeden Fall gelten ?
Wäre es nicht vorstellbar, dass - architektonisch begründet - 4x2 durchaus besser sein kann, als 8x1 ? Und selbst wenn wir derzeitige Implementierungen vegleichen... bis Du der Meinung, dass hier 8x1 grundsätzlich (oder auch "immer" ;-) besser, als 4x2 ist ? Wenn ja, warum ?

Auch ich bin der Meinung, dass 8x1 generell flexibler einzusetzen ist, würde aber niemals wagen, dies in jeder Situation der Fall ist.

Razor
OK, extra für dich:

8x1 >= 4x2.

:)

[zeckensack]

Original geschrieben von Exxtreme
OK, extra für dich:

8x1 >= 4x2.

:) Bei gleichem Takt:
*anschließ*

[StefanV]

Original geschrieben von Gast
Sollte das jetzt witzig gewesen sein ?
Stefääään spääääämt !
:D

Razor

1. nö, eigentlich solltest du jetzt in Tränen ausbrechen und ausm Fenster springen...

2. nö, nicht wirklich :eyes:

3. wenn du dir mal Gedanken über die Fillrate machst, dann wird dir auch einleuchten, welche Architektur die schnellere ist (bei gleicher Schwingung natürlich)...

8x2 sind bei 2 Texturen halt doppelt so viel wie 8x1, bei bi-TMUs steigt auch die Tri-AF Fillrate nicht unerheblich an...

[strickjackenscheitel]

"8x2 sind bei 2 Texturen halt doppelt so viel wie 8x1, bei bi-TMUs steigt auch die Tri-AF Fillrate nicht unerheblich an..." .. ehm gut. ist das nun gut oder schlecht? so wie du das formulierst ist das so garnicht rauszulesen, leider.

[Exxtreme]

Original geschrieben von strickjackenscheitel
"8x2 sind bei 2 Texturen halt doppelt so viel wie 8x1, bei bi-TMUs steigt auch die Tri-AF Fillrate nicht unerheblich an..." .. ehm gut. ist das nun gut oder schlecht? so wie du das formulierst ist das so garnicht rauszulesen, leider.
Also wenn ein Spiel 2 Texturen pro Polygon nutzt, dann kann die 8x2-Architektur dieses Polygon mit einem Durchgang berechnen, die 8x1-Architektur braucht dagegen 2 Durchgänge.

Ein anderes Beispiel ist trilineares Filtern. Wenn diese Architekturen jeweils Textureinheiten einsetzen, die nur bilineare Textursamples auswerfen, dann ist die 8x2-Architektur auch wieder im Vorteil da man 2 Bi-TEs zu einer Tri-TE zusammenschalten kann (in den meisten Fällen).

[Razor]

Tja, SP... nur hast Du leider offensichtlich nicht mitbekommen, um was es mir ging.
Nur zu Erinnerung: 8x1 > 4x2 ? Nein nicht immer und wenn, auch nur bei gleichem Takt...

Razor

[StefanV]

Original geschrieben von Razor
Tja, SP... nur hast Du leider offensichtlich nicht mitbekommen, um was es mir ging.
Nur zu Erinnerung: 8x1 > 4x2 ? Nein nicht immer und wenn, auch nur bei gleichem Takt...

Razor

Tja, Razor, wie wäre es, wenn du dich a) besser ausdrücken würdest und b) höflicher sein würdest??

Allerdings fürchte ich, daß 8x1 ggÜ 4x2 im Vorteil sein dürfte...

[strickjackenscheitel]

also wir wollen uns erstmal doch nicht gegenseitig auf den sack gehen, oder?! =)

dann erst einmal danke fuer die erklaerung exxtreme!

fuer wie wahrscheinlich haltet ihr eine 8x2?

[zeckensack]

Original geschrieben von strickjackenscheitel
fuer wie wahrscheinlich haltet ihr eine 8x2? Ziemlich un- :)

[mapel110]

Original geschrieben von zeckensack
Ziemlich un- :)

aber triTMUs ?! =)

[strickjackenscheitel]

warum forscht man nicht an tmus, die n-fach filtern koennen? das wuerde doch so einige transitorprobleme loesen, oder?

auch frage ich mich wie gut man ein speicherinterface verbessern? irgendwann muss es doch ein "optimierungsoptimum" geben, oder?
wird der nv40 so ziemlich das ende von optimierung an dem interface sein?

[zeckensack]

Das Problem ist, solange bilinear überhaupt noch für irgendwas Sinn macht, will man auch daß es schneller läuft als die 'besseren' Filter.
Deswegen sind bi-TMUs heutzutage die Basiseinheit, und tonnenweise Loopbacks und TMU-Verschaltungen ermöglichen erst mehr.

Dann noch bitte an folgendes denken:
Eine single cycle Bi-TMU frißt pro Takt 4 rohe Texel, also Pi mal Daumen 128 Bit. Derer haben sowohl R350 als auch NV35 acht Stück
=> 1024 Bit pro Takt
Soviele Datenleitungen müssen aus dem Texturcache rauskommen, damit das Teil überhaupt läuft. Zum Vergleich: die Bitboys sind vor ~zwei Jahren an 512 Bit eDRAM gescheitert, Intel krebst derzeit bei 256 Bit rum (aber auch nur im L2), und über AMD schweige ich lieber mal komplett.

Was aths fordert (4096 Bit Cache-Anbindung) ist ja schön und gut, für mich hört sich das aber jetzt schon nach einem extremen Aufwand an.

[strickjackenscheitel]

fuer mcih hoert sich das einfach nur nach sauviel geld an. ich denke, dass das technisch durchaus machbar ist, doch lohn sich preis/leistung dafuer nicht. oder irre ich mich?

[mapel110]

Original geschrieben von strickjackenscheitel
fuer mcih hoert sich das einfach nur nach sauviel geld an. ich denke, dass das technisch durchaus machbar ist, doch lohn sich preis/leistung dafuer nicht. oder irre ich mich?

so wie ichs verstanden habe, ists bei heutigen 8 pipe beschelunigern nicht so ohne weiteres machbar.
es gibt ja tri TMUs bei 3dlabs. aber die haben eben nicht soviele pipes zu füttern. ;)

[Ailuros]

Zum Vergleich: die Bitboys sind vor ~zwei Jahren an 512 Bit eDRAM gescheitert...

Kannst mich ruhig korrigieren wenn mich mein Gedaechtnis betruegt, hab ich den Eindruck es waren 1024bit im letzten Design intern und extern nur 128bit.

Wie effizient oder uneffizient der Design wirklich war, wissen wir ja leider nicht.

[nagus]

http://www.notforidiots.com/GPURW.php

... realistisch IMHO

da passt auch das gerücht mit der 6x2 architektur relativ gut hinein

[Quasar]

Jo, denk' ich auch. Hoffentlich wird's endlich auch ein 8x1-Design mit kompletter FP32-ALU auf jeder Pipe. Dann wird sich der R420 sehr warm anziehen müssen, da nV bei aktuell kompilierten Shadern ja schon mit nur 4 FP32ern an die 8 FP24er von ATi herankommt.


Dass der R420 hundreds of millions transistors hat, glaube ich auch, genauer ca. 1.4-1.6 hundreds of millions transistors. ;)

[Demirug]

Original geschrieben von nagus
http://www.notforidiots.com/GPURW.php

... realistisch IMHO

da passt auch das gerücht mit der 6x2 architektur relativ gut hinein

"gerücht mit der 6x2 architektur" habe ich da was verpasst?

[Demirug]

Original geschrieben von Quasar
Jo, denk' ich auch. Hoffentlich wird's endlich auch ein 8x1-Design mit kompletter FP32-ALU auf jeder Pipe. Dann wird sich der R420 sehr warm anziehen müssen, da nV bei aktuell kompilierten Shadern ja schon mit nur 4 FP32ern an die 8 FP24er von ATi herankommt.


Dass der R420 hundreds of millions transistors hat, glaube ich auch, genauer ca. 1.4-1.6 hundreds of millions transistors. ;)

nVidia wird mit sehr hoher Wahrscheinlichkeit nicht von ?x2 abrücken und sie haben einen sehr guten Grund dafür. ;)

ATI hat sogar 24 fp24 Einheiten. Und was nVidia da so genau hat ...

[Quasar]

Den (einen?) Grund vermute ich auch, aber ich kann das natürlich nicht beweisen....
2x16=32...


Mit 8FP24-Einheiten meinte ich komplette Shader-ALUs.

[LovesuckZ]

Original geschrieben von Demirug
nVidia wird mit sehr hoher Wahrscheinlichkeit nicht von ?x2 abrücken und sie haben einen sehr guten Grund dafür. ;)


warum? Gibt es dafür irgendeinen Grund außer " eine ?x2 Architektur ist für aeltere Spiele zwar etwas langsamer aber für die kommenden die perfekte Loesung" ?

[Demirug]

Den (einen?) Grund vermute ich auch, aber ich kann das natürlich nicht beweisen....
2x16=32...

Ich meinen einen anderen technischen Grund. Es ist aber sinnlos mich jetzt zu löchern weil ich im Moment noch nicht mehr sagen will.

EDIT: Die 2er Potenzen werden unwichtiger.

Mit 8FP24-Einheiten meinte ich komplette Shader-ALUs.

Also die Kombination aus einer Textureinstruktion-, Vector3- und Skalar- FPU?

warum? Gibt es dafür irgendeinen Grund außer " eine ?x2 Architektur ist für aeltere Spiele zwar etwas langsamer aber für die kommenden die perfekte Loesung" ?

Ja, es gibt einen Grund. ;) s.o

[Quasar]

Original geschrieben von Demirug
Also die Kombination aus einer Textureinstruktion-, Vector3- und Skalar- FPU?

Jub.

[Sunrise]

Jo, denk' ich auch. Hoffentlich wird's endlich auch ein 8x1-Design mit kompletter FP32-ALU auf jeder Pipe. Dann wird sich der R420 sehr warm anziehen müssen, da nV bei aktuell kompilierten Shadern ja schon mit nur 4 FP32ern an die 8 FP24er von ATi herankommt.


Das sich der R420 "sehr warm wird anziehen" müssen, halte ich für etwas gewagt. Vor allem wenn bisher keiner so richtig weiss, wie er intern aussieht, und wieviel Pipes (12x1 gerüchteweise) er nun genau hat.

[Razor]

Und was genau will man üner den NV40 'wissen' ?
???

Razor

[strickjackenscheitel]

kann es sein, dass niemand so recht weiss, was nun genau im nv40 steckt?
wann sollte der chip rauskommen?

was wissen wir eigentlich mit hoher wahrscheinlichkeit vom nv 38?
mal genau genommen nen dreck.
wir wissen nicht was der architektonisch besser kann, wie hoch der takt ist, wann genau er rauskommt, oder wo er nun ueberhaupt gebaut wird?! (ibm oder doch tsmc?)

somit ist es infam von uns jetzt schon ueber den nv40 zu "weißlen".

was kommt nochmal mit dem nv45? =D

[Sunrise]

Und was genau will man üner den NV40 'wissen' ?
Nichts! Und deshalb stellt man solche Thesen garnicht erst auf :)

[Demirug]

Original geschrieben von strickjackenscheitel
kann es sein, dass niemand so recht weiss, was nun genau im nv40 steckt?

Es gibt schon leute die was wissen die müssen aber noch die klappe halten.

wann sollte der chip rauskommen?

Da schwanken die Angaben zwischen Ende dieses Anfang nächstes Jahr.

was wissen wir eigentlich mit hoher wahrscheinlichkeit vom nv 38?
mal genau genommen nen dreck.
wir wissen nicht was der architektonisch besser kann, wie hoch der takt ist, wann genau er rauskommt, oder wo er nun ueberhaupt gebaut wird?! (ibm oder doch tsmc?)

Gibt es überhaupt einen NV38?


somit ist es infam von uns jetzt schon ueber den nv40 zu "weißlen".

Hier darf man das.

was kommt nochmal mit dem nv45? =D

Einen Zyklus nach dem NV40.

[LovesuckZ]

Original geschrieben von Demirug
Gibt es überhaupt einen NV38?


Oder wird er einfach unter dem Namen NV35 SE (= 5900 SE) verkauft?!...

[strickjackenscheitel]

wenns von dem nv40 eine guenstige variante gibt (wie viele varianten ist auch nicht klar, irre =), dann werd sicher nicht nur ich mir die holen. so oder so wird es auf jedenfall ein papiertiger.

fasse ich mal flott alles zusammen was ich bisher ueber den naechsten superchip von der westkueste alles weiss:

-8x2 architektur (macht am meisten sinn fuer mich; warum 12x2?)
-256bit-speicherinterface
-600mhz (oder mehr) chip und speicher
-angenehmere kuehlung (denk ich mir, weil bei ibm gebaut)
d.h.: das was man sich eigentlich vom nv 30 so erhofft hat, oder?

[nagus]

Original geschrieben von Razor
Und was genau will man üner den NV40 'wissen' ?
???

Razor


also die 150MIo transis sind "relativ" sicher, oder?

... und zwischen 130mio (NV35) und 150Mio (NV40) ist nicht so viel unterschied IMHO.... was kann sich da schon großartig viel ändern? PS3.0 und VS3.0 + 50% mehr pipes. kann sich das eigentlich ausgehen mit "nur" +20Mio transis mehr?

[betasilie]

Original geschrieben von nagus
also die 150MIo transis sind "relativ" sicher, oder?

... und zwischen 130mio (NV35) und 150Mio (NV40) ist nicht so viel unterschied IMHO.... was kann sich da schon großartig viel ändern? PS3.0 und VS3.0 + 50% mehr pipes. kann sich das eigentlich ausgehen mit "nur" +20Mio transis mehr?
Ok, aber die Anzahl der Transistoren sagt ja nicht alleine was über die Geschwindigkeit aus. Vielleicht hat NV ja auch was Optimierungen geschafft, die der pro-MHZ-Leistung vom NV40 gut tun, abgesehen von dem Mehr an Transistoren. ;)

[nagus]

Original geschrieben von betareverse
Ok, aber die Anzahl der Transistoren sagt ja nicht alleine was über die Geschwindigkeit aus. Vielleicht hat NV ja auch was Optimierungen geschafft, die der pro-MHZ-Leistung vom NV40 gut tun, abgesehen von dem Mehr an Transistoren. ;)

stimmt. aber im vergleich zu ATI kommt nvidia mit ~ 20mio transistoren + höheren takt ~ auf das leistungsniveau von ATI (NV35 vs. R350)... mal abgesehen vom gewaltingen vorspung der PS2.0 leistung des R3x0 chips.

[Demirug]

Man müsste erst mal wissen wie sich die 130 Mio beim NV35 verteilen aber an einen Floorplan ist derzeit nicht heranzukommen.

[betasilie]

Original geschrieben von nagus
stimmt. aber im vergleich zu ATI kommt nvidia mit ~ 20mio transistoren + höheren takt ~ auf das leistungsniveau von ATI (NV35 vs. R350)... mal abgesehen vom gewaltingen vorspung der PS2.0 leistung des R3x0 chips.
Stimmt. Genau deswegen könnte NV imo aber noch Optimierungspotenzial in der Pro-mhz-Leistung haben. ;)

Ich finde es unglaublich Spannend was der R420 und der NV40 leisten werden. Ehrlich gesagt traue ich beiden alles zu; von Flopp bis Top. :D

[Demirug]

Original geschrieben von nagus
stimmt. aber im vergleich zu ATI kommt nvidia mit ~ 20mio transistoren + höheren takt ~ auf das leistungsniveau von ATI (NV35 vs. R350)... mal abgesehen vom gewaltingen vorspung der PS2.0 leistung des R3x0 chips.

Wobei wir ja gerade heute gelernt haben das die R3x0 Chips bei "schlechtem" Shadercode auch mal schnell massiv einbrechen.

Die höhere Rohleitung pro Takt ist sicherlich auf der Seite von ATI nur scheint es dort auch mehr Fallen zu geben die zur Verpuffung dieser führen. nv hat zwar auch solche fallen nur erscheinen diese mir leichter zu umgehen wenn man dazu gewillt ist. Leider führt aber das dann gerade dazu das man in die ATI Fallen läuft. Dummes Problem.

[Demirug]

Original geschrieben von nagus
also die 150MIo transis sind "relativ" sicher, oder?

... und zwischen 130mio (NV35) und 150Mio (NV40) ist nicht so viel unterschied IMHO.... was kann sich da schon großartig viel ändern? PS3.0 und VS3.0 + 50% mehr pipes. kann sich das eigentlich ausgehen mit "nur" +20Mio transis mehr?

So mal überschlagen. Es könnte ganz knapp für 8*2 reichen

[Ailuros]

Original geschrieben von Demirug
So mal überschlagen. Es könnte ganz knapp für 8*2 reichen

8*1*2 oder 8*2*1?

Uebrigens ich werde das Gefuehl nicht los dass so manche denken dass wenn chip A mehr Transistoren hat besser sein wird als B, oder schlechter. Dabei ist nichts garantiert. Tests und Analysen fuer jeden chip abwarten nach der Veroeffentlichung.

[Ailuros]

*aechz* Doppelpost :(

[Demirug]

Original geschrieben von Ailuros
8*1*2 oder 8*2*1?

Uebrigens ich werde das Gefuehl nicht los dass so manche denken dass wenn chip A mehr Transistoren hat besser sein wird als B, oder schlechter. Dabei ist nichts garantiert. Tests und Analysen fuer jeden chip abwarten nach der Veroeffentlichung.

Ach warum den noch mehr ins Detail gehen. Ich habe mich mit den 8*2 doch schon weit aus dem Fenster gelehnt weil das wirklich verdammt knapp ist und die Überschlagsrechnung sehr viele unbestätigten annahmen enthält.

Die letzte Ziffer auf jeden Fall eine 2 (wenn ich die 2 auch nicht als die Anzahl der TMUs in dieser Pipe sehen möchte). Ob es dann davor 8*1, 4*2, 2*4 oder 1*8 ist wage ich nicht zu sagen. 8*1 wäre natürlich das beste aber ob da die Transitoren noch reichen.

Ich hoffe wir reden bei diesen Zahlenspielereien vom gleichen System.

NV30/NV35 = 1*4*2 (das weiss ich genau ;) )
R300/R350 = 2*4*1 (wahrscheinlich)
RV350 = 1*4*1 (wahrscheinlich)

[StefanV]

Original geschrieben von LovesuckZ
Oder wird er einfach unter dem Namen NV35 SE (= 5900 SE) verkauft?!...

Nö, da SE = SLow Edition...

[Demirug]

@Ailuros:

Nur um sicher zu gehen das wir das gleiche meinen

x*y*z

x = Anzahl der unabhängigen Pipelines.
y = Pixel pro Pipeline.
z = Anbindungen an die TMUs pro Pixel.

[LovesuckZ]

Original geschrieben von Stefan Payne
Nö, da SE = SLow Edition...

Hm, und das willst du woher wissen?
Siehe auch 5600 SE.

[Razor]

Original geschrieben von nagus
also die 150MIo transis sind "relativ" sicher, oder?
Nö.
Oder habe ich da irgendeine offizielle Verleutbarung verpaßt ?
Zumindest aber hört sich das nun nicht sehr unrealistisch an.
Original geschrieben von nagus
... und zwischen 130mio (NV35) und 150Mio (NV40) ist nicht so viel unterschied IMHO.... was kann sich da schon großartig viel ändern? PS3.0 und VS3.0 + 50% mehr pipes. kann sich das eigentlich ausgehen mit "nur" +20Mio transis mehr?
Wie gesagt, reine Spekulation Deinerseits, oder ?
Du gehtst von einer Annahme aus und triffst weitere aufgrund dieser.
Und hat einen Aussagegehalt gleich Null.

Ergo:
Wenn ... dann ... vielleicht
Wenn nicht ... dann ... vielleicht nicht oder auch anders herum
:D

Razor

[Razor]

Original geschrieben von nagus
...mal abgesehen vom gewaltingen vorspung der PS2.0 leistung des R3x0 chips.
:lol:

[nagus]

Original geschrieben von Razor
:lol:

ich weis nicht was daran so komisch sein soll.
aber irgendwie hast du auch "recht"...


http://www.beyond3d.com/forum/viewtopic.php?t=7422&highlight=aod

TRAOD with PS2.0
----------------

NV35 ULTRA: 35fps
Radeon 9800PRO: 85fps

... die leistung der schnellsten FX in verbindung mit PS2.0 ist wirklich ein witz

[Aquaschaf]

Original geschrieben von LovesuckZ
Hm, und das willst du woher wissen?
Siehe auch 5600 SE.

Ist denn sicher das die 5600SE wirklich eine neue Bezeichnung für die 400MHZ Variante ist?

[LovesuckZ]

Original geschrieben von Aquaschaf
Ist denn sicher das die 5600SE wirklich eine neue Bezeichnung für die 400MHZ Variante ist?

Entweder dies oder sie wird mit der alten ausgetauscht.

[Ailuros]

Original geschrieben von Demirug
@Ailuros:

Nur um sicher zu gehen das wir das gleiche meinen

x*y*z

x = Anzahl der unabhängigen Pipelines.
y = Pixel pro Pipeline.
z = Anbindungen an die TMUs pro Pixel.

Nein dann wuerden Deine Zahlen von vorigen Generationen weniger Sinn machen im Vergleich zu 8*1*2.

Mit Deiner vorigen Illustration ist es wohl:

1*8*1(*2) *kicher* :D

(pipelines*texture samplers*pixel shader units)

[strickjackenscheitel]

ah ... AAAAHHH ... 300mill transistoren? den neusten news nach soll der nv40 doppelt soviele transistoren haben wie vermutet. das wuerde fuer mich nur eine doppelchiploesung bedeuten, oder eben eine luege. das mann das noch mit 600mhz takten will, finde ich ohnehin ziemlich anmaßend von der quelle.
nein nicht das es mich nicht freuen wuerde, dass es ein damit sicherlich leistungsfaehigen chip geben koennte, sondern vielmehr das es doch recht unwahrscheinlich ist.

also was denkt ihr?

btw: warum ist der eine oder andere hier so auf nv oder ati geeicht? warum versuchen denn diese leute das ganze nicht als sportlichen wettkampf zu sehen? ich "ralle" das nicht, schuldigung.

[Ailuros]

btw: warum ist der eine oder andere hier so auf nv oder ati geeicht? warum versuchen denn diese leute das ganze nicht als sportlichen wettkampf zu sehen? ich "ralle" das nicht, schuldigung.

Gute Frage.

Aehnliche Phaenomene treten auch auf bei Politik z.B.

[Razor]

Original geschrieben von nagus
... die leistung der schnellsten FX in verbindung mit PS2.0 ist wirklich ein witz
Da man meinen anderen Post wohl getrasht hat...
;-)

TR6 hat noch ganz andere Probleme...
Und Dir ist hoffentlich auch aufgefallen, dass auch eine R9800p satt einbricht, wenn der Code nVidia-Optimiert wird. Oder wie ist eine Sekung der fps von 82 auf 53 zu erklären ? Heißt das jetzt dass die PS2.0-Leistung von ATI nun doch nicht so dolle ist ?
???

Razor

[StefanV]

Original geschrieben von Razor
Da man meinen anderen Post wohl getrasht hat...
;-)

TR6 hat noch ganz andere Probleme...
Und Dir ist hoffentlich auch aufgefallen, dass auch eine R9800p satt einbricht, wenn der Code nVidia-Optimiert wird. Oder wie ist eine Sekung der fps von 82 auf 53 zu erklären ? Heißt das jetzt dass die PS2.0-Leistung von ATI nun doch nicht so dolle ist ?
???

Razor

Gibt da allerdings immer noch ein Problem:

Selbst mit bescheidenem Code, dem der R350 nicht schmeckt, ist sie immer noch schneller als die FX...

[Demirug]

Original geschrieben von Ailuros
Nein dann wuerden Deine Zahlen von vorigen Generationen weniger Sinn machen im Vergleich zu 8*1*2.

Immer an PS 3.0 denken. ;)

Mit Deiner vorigen Illustration ist es wohl:

1*8*1(*2) *kicher* :D

(pipelines*texture samplers*pixel shader units)

Wie schon anderweitig erwähnt nehme ich inzwischen die Texture Samplers gerne raus. Diese sind bei weitem nicht mehr so eng mit der Pipeline verbunden wie früher. Dieser Treand hat schon beim NV20 angefangen

[zeckensack]

Original geschrieben von Demirug
Wie schon anderweitig erwähnt nehme ich inzwischen die Texture Samplers gerne raus. Diese sind bei weitem nicht mehr so eng mit der Pipeline verbunden wie früher. Dieser Treand hat schon beim NV20 angefangen Halte ich für gewagt :)
NV20 führt IMO Textur-Lookups (und die allseits beliebten, zum "Pixel Shader" befähigenden DRs) auch nur logisch gesehen vor dem Combiner aus. Der Grund dafür ist so naheliegend: Texturlookups haben eine potentiell riesige Latenz (Speicherzugriff bei Cache-Miss). Es macht Sinn, das erstmal auszusortieren, bevor's ans Rechnen geht. Auf die Weise kann der Chip bei eher rechenlastigen Shadern Wartezyklen einsparen.

Die Pipeline muß trotzdem auf das Eintrudeln der Textursamples warten, sofern sie denn benötigt werden. Das ist ausreichend dokumentiert.
Die Sampler haben also IMO schon einen direkten Draht in die Combiner hinein. Lediglich das 'Antippen' derselbigen wird etwas vorgezogen. Von Trennung würde ich da nicht reden wollen.

[Demirug]

Original geschrieben von zeckensack
Halte ich für gewagt :)
NV20 führt IMO Textur-Lookups (und die allseits beliebten, zum "Pixel Shader" befähigenden DRs) auch nur logisch gesehen vor dem Combiner aus. Der Grund dafür ist so naheliegend: Texturlookups haben eine potentiell riesige Latenz (Speicherzugriff bei Cache-Miss). Es macht Sinn, das erstmal auszusortieren, bevor's ans Rechnen geht. Auf die Weise kann der Chip bei eher rechenlastigen Shadern Wartezyklen einsparen.

Die Pipeline muß trotzdem auf das Eintrudeln der Textursamples warten, sofern sie denn benötigt werden. Das ist ausreichend dokumentiert.
Die Sampler haben also IMO schon einen direkten Draht in die Combiner hinein. Lediglich das 'Antippen' derselbigen wird etwas vorgezogen. Von Trennung würde ich da nicht reden wollen.

Richtig: vor den Combiner aber innerhalb dessen was nVidia beim NV20/NV25 als "Pixelshader" bezeichnet.

Ich zitiere mal aus einer Techpräsentation zum NV25.

Pixel Shading / Texturing
A pixel shader converts texture
coordinates into a color using a shader
program:
-Floating point math
-Texture lookups
-Results of previous pixel shaders
4 stages, 1 texture address op per stage
Compressed, mipmapped 3-D textures
-True reflective bump mapping
-True dependent textures (lookup tables)
-Full 3×3 transform with cubemap or 3-D texture lookup
-16-bit-per-component normal maps
Input: values interpolated across
triangle
IEEE floating point operations
Lookup functions using textures
-Large, multi-dimensional tables
-Filtered
Outputs an ARGB value that
register combiners can read

Zu deinem Cache-Misses wird auch noch was ausgesagt:

Texture
Deeply pipelined cache
- Many hits and misses in flight
Compression
- 4:1 ratio
- Palettes
- Lossy small-grained fixed ratio scheme
Filtering
-Bilinear, trilinear, 8:1 anisotropic

Ich kann dir auch noch gerne das Patent mit den genauen Erklärungen raussuchen das habe ich hier.

Zudem habe ich hier noch einen NV25 Floorplan von Synopsys in dem die "Texture Unit" und "Pixel Shader" zwei völlig getrennte Einheiten sind.

Mittelfirstig (PS 3.0) geht es auch gar nicht mehr anders als die TMU von den Pipelines zu entkoppeln wenn man nicht in Schönheit sterben will.

[strickjackenscheitel]

da haut aber wer auf den putz =)

am ende stellt sich doch nur die frage, wie viel perfomence das bringt, oder?!
was genau bringt denn das (wenn ichs richtig gelesen hab) entkoppeln der tmus von den pipelines nun realperformencetechnisch fuer durchschnittsverbraucher und wann wird das ganze von spielen genutzt (nie, in einem jahr, heut?) ???

[zeckensack]

Original geschrieben von strickjackenscheitel
da haut aber wer auf den putz =)

am ende stellt sich doch nur die frage, wie viel perfomence das bringt, oder?!
was genau bringt denn das (wenn ichs richtig gelesen hab) entkoppeln der tmus von den pipelines nun realperformencetechnisch fuer durchschnittsverbraucher und wann wird das ganze von spielen genutzt (nie, in einem jahr, heut?) ??? Wenn ein Shader viel rechnet, und dabei wenige Texturen benutzt, dann bringt die Entkopplung insofern einen Vorteil, daß die Transistoren des Textur-Samplers nicht unnütz im Weg herumliegen.

Das direkt am lebenden Objekt zu beobachten dürfte schwierig sein, ich kann mir aber gut vorstellen daß die IHVs durch diese Maßnahme mehr Reserven für den Chiptakt bekommen (haben).

[strickjackenscheitel]

warum macht sich ein chipentwickler nicht daran eine multichiploesung zu bringen? das wuerde doch unheimlich bei den gamern beeindrucken, oder? auch wenn es nur 2 5600er (o.ä.) zusammengeschraubt sind, waere das doch mal eine nette sache, oder?

jedes forum wuerde sich doch dann NUR noch mit dem: was kommt noch, warum doch multi, vergangenheit von multi, leistung des einen multi, leistung des multis im vgl mit anderen nonmultis, sinn und unsinn des multis uswuswusw. beschaeftigen,oder?

ich kann mir nicht vorstellen, dass das von den treibern und von dem boardlayout so schwer sein koennte. moment ... nv hat doch quantum3d aufgekauft, womit die doch auf jeden fall superspezialisten fuer den multibereich haben, oder?

naja manchmal traeume ich noch von vergangenen tagen, sorry. =/

[Demirug]

Original geschrieben von zeckensack
Wenn ein Shader viel rechnet, und dabei wenige Texturen benutzt, dann bringt die Entkopplung insofern einen Vorteil, daß die Transistoren des Textur-Samplers nicht unnütz im Weg herumliegen.

Daß direkt am lebenden Objekt zu beobachten dürfte schwierig sein, ich kann mir aber gut vorstellen daß die IHVs durch diese Maßnahme mehr Reserven für den Chiptakt bekommen (haben).

Ich denke da eher in eine andere Richtung. Sobald in Verbindung mit PS 3.0 jeder Pixel einen anderen weg durch ein Programm einschlagen kann kommt es auch zu unterschiedlichen Zietpunkte von unterschiedlichen Pipelines zu Textureanforderungen. Sind dann die TMUs fest den Pipelines zugeordent verliert man Fillrate wenn einzelne Pixel weniger davon brauchen weil ihr Programmpfad weniger Sampleanweisungen enthält. Bei Entkoppelten TMUs kann der Chip die gesamte Fillrate unter alle aktiven Anforderungen entsprechend Aufteilen und so besser nutzen. Bei genauem Nachdenke gilt das aber auch schon heute. Die Filterleistung ist ja immer da nur wenn keine Rohdaten zur verfügung stehen nützt diese ja nichts. Weist man also den Filter dynamisch die Jobs unabhängig von den Pieplines zu steigt die Ausnutzung.

[Aquaschaf]

Original geschrieben von strickjackenscheitel
warum macht sich ein chipentwickler nicht daran eine multichiploesung zu bringen? das wuerde doch unheimlich bei den gamern beeindrucken, oder? auch wenn es nur 2 5600er (o.ä.) zusammengeschraubt sind, waere das doch mal eine nette sache, oder?

jedes forum wuerde sich doch dann NUR noch mit dem: was kommt noch, warum doch multi, vergangenheit von multi, leistung des einen multi, leistung des multis im vgl mit anderen nonmultis, sinn und unsinn des multis uswuswusw. beschaeftigen,oder?

ich kann mir nicht vorstellen, dass das von den treibern und von dem boardlayout so schwer sein koennte. moment ... nv hat doch quantum3d aufgekauft, womit die doch auf jeden fall superspezialisten fuer den multibereich haben, oder?

naja manchmal traeume ich noch von vergangenen tagen, sorry. =/

Erstmal müssen die verwendeten Chips das auch unterstützen, und weder ATI noch NV hat wohl momentan multichipfähige Chips.
Dann ist das mit dem Boardlayout auch nicht so unproblematisch, man käme mit einer 2 Chip-Lösung sicher schon auf 150Watt Leistungsaufnahme mindestens. Eine 5900 kommt von der Größe doch schon an eine Voodoo 5 ran, eine 2-Chip-Lösung wüde kaum noch in nen Tower passen. Und billig wärs auch nicht.
Ich nehme an das man irgendwann an einen Punkt kommt, an dem Multichiplösungen wieder sinnvoll werden, weil ein entsprechender Singlechip von der Transistormenge nicht mehr mit rentabler Ausbeute möglich ist. Aber bis es so kommt, dass kann noch eine Weile dauern.

[Demirug]

Original geschrieben von Aquaschaf
Erstmal müssen die verwendeten Chips das auch unterstützen, und weder ATI noch NV hat wohl momentan multichipfähige Chips.

R300 ist Multichip fähig. Es können mindestens 4 Chips zusammengeschaltet werden (AFAIK bis 64). Auch beim NV30/NV35 ist wahrscheinlich eine Multichip Fähigkeit vorhanden. Allerdings steigern die Lösungen nur die Fillrate/Pixelshader Leistung und skalieren eher schlecht.

Dann ist das mit dem Boardlayout auch nicht so unproblematisch, man käme mit einer 2 Chip-Lösung sicher schon auf 150Watt Leistungsaufnahme mindestens. Eine 5900 kommt von der Größe doch schon an eine Voodoo 5 ran, eine 2-Chip-Lösung wüde kaum noch in nen Tower passen. Und billig wärs auch nicht.

Ack

Ich nehme an das man irgendwann an einen Punkt kommt, an dem Multichiplösungen wieder sinnvoll werden, weil ein entsprechender Singlechip von der Transistormenge nicht mehr mit rentabler Ausbeute möglich ist. Aber bis es so kommt, dass kann noch eine Weile dauern.

Ich denke eher nicht das man im normalen Consumerbreich nochmal auf Multichip gehen wird.

[Razor]

Original geschrieben von Stefan Payne
Gibt da allerdings immer noch ein Problem:

Selbst mit bescheidenem Code, dem der R350 nicht schmeckt, ist sie immer noch schneller als die FX...
Wenn Du meinst...
;-)

Wer sagt übrigens, dass der Code 'bescheiden' war ?

Es würde mich nicht wundern, wenn auch der Cg-Compiler den 2.0 und nicht den 2.x zum compilieren nutzte. Wenn dem so ist, bestätigt sich einerseits zwar das schlechte Resultat des 'Standard'-Compilers, läßt im Gegenzig aber keine Aussage über 'optimierten' Code für den NV3x zu. Und vermutlich fällt das Ergebnis auf dem R300 dann noch viiiiel schlechter aus, wenn der 2.x-Pfad benützt würde...

Ich hoffe Du verstehst, wie ich das meine... ;)

Razor

[Exxtreme]

Original geschrieben von Razor
Würde ATI jetzt den NV3x-optimierten Code vorgesetzt bekommne, dann würde gar nichts mehr laufen, weil der R300 diesen Code einfach nicht interpretieren kann.

Ist klar.
Original geschrieben von Razor
Woher willst Du das wissen ?
Er hat weder optimierten Code von Cg, noch vom M$-Compiler bekommen.
Aussagen hierüber könnte nur jemand machen, der die Shader analysiert und mal selbst durch die betroffenen Compiler jagt.

Naja, vergiss eine Sache nicht. ATi hat 8 Renderpipelines, NV nur 4. Das ist ein nicht zu unterschätzender Vorteil für ATi.
Original geschrieben von Razor
Was abzuwarten bliebe...
Demirug hat soch schon so einige Konsequenzen dargestellt.
"Stay tuned !"
;-)

Razor
Wie gesagt, an einem Faktor von fast 2,5 glaube ich nicht, daß da soviel drin ist. Der R3x0 bricht um 40% ein mit dem absolut(!!) ungünstigen Code ein und bleibt immer noch deutlich schneller als der NV35 mit weniger ungünstigen Code.

[Ailuros]

OT:

Demi,

Ich haette es fast vergessen die Z/stencil units (wenn es sich auch um solche handelt und nicht "Alternativen") sind nicht 8*6 auf R3xx. Es sind entweder 16 oder 32 alle zusammen, wobei ich eher auf die erste Zahl tendiere. Frag nicht wie sie das Ganze anstellen, dafuer bekomme ich immer noch keine Antwort.

[Demirug]

Original geschrieben von Ailuros
OT:

Demi,

Ich haette es fast vergessen die Z/stencil units (wenn es sich auch um solche handelt und nicht "Alternativen") sind nicht 8*6 auf R3xx. Es sind entweder 16 oder 32 alle zusammen, wobei ich eher auf die erste Zahl tendiere. Frag nicht wie sie das Ganze anstellen, dafuer bekomme ich immer noch keine Antwort.

Wie sie es anstellen kann ich mir schon vorstellen. Dynamisches Zuweisen

[Ailuros]

Original geschrieben von Demirug
Wie sie es anstellen kann ich mir schon vorstellen. Dynamisches Zuweisen.

Hmmmm ich hab noch mal schnell fruehe Doom3 Resultate nachgecheckt:

1024*768

R350 noAA/AF ---> 2xAA/8xAF = -28.0%
NV35 noAA/AF ---> 2xAA/8xAF = -17.7%

R350 noAA/AF ---> 4xAA/8xAF = -45.6%
NV35 noAA/AF ---> 4xAA/8xAF = -33.6%

So toll scheint das ganze aber nicht zu sein (ich bezweifle dass daran Leistungs-Optimierungen noch viel aendern koennen), wenn man stencil ops benutzt.

NVIDIA hat ja in der Abteilung keinerlei Sorgen, ueberhaupt wenn da fleissig weiterentwickelt wurde. ;)

[Demirug]

Original geschrieben von Ailuros
Hmmmm ich hab noch mal schnell fruehe Doom3 Resultate nachgecheckt:

1024*768

R350 noAA/AF ---> 2xAA/8xAF = -28.0%
NV35 noAA/AF ---> 2xAA/8xAF = -17.7%

R350 noAA/AF ---> 4xAA/8xAF = -45.6%
NV35 noAA/AF ---> 4xAA/8xAF = -33.6%

So toll scheint das ganze aber nicht zu sein (ich bezweifle dass daran Leistungs-Optimierungen noch viel aendern koennen), wenn man stencil ops benutzt.

NVIDIA hat ja in der Abteilung keinerlei Sorgen, ueberhaupt wenn da fleissig weiterentwickelt wurde. ;)

DOOM III ist mir da irgendwie zu komplex zum testen. Da muss man mit etwas ran was mehr auf Stencilleistung geht. Fabelmark wäre da möglicherweise eine gute Idee.

[Ailuros]

Original geschrieben von Demirug
DOOM III ist mir da irgendwie zu komplex zum testen. Da muss man mit etwas ran was mehr auf Stencilleistung geht. Fabelmark wäre da möglicherweise eine gute Idee.

Nur sind die Resultate bei der R300 zumindest schlimmer als in D3.

Fablemark 1024*768

noAA/noAF = 60.9
noAA/8xAF = 58.9
4xAA/noAF = 28.5
4xAA/8xAF = 28.2 (-53.7%)

[Demirug]

Original geschrieben von Ailuros
Nur sind die Resultate bei der R300 zumindest schlimmer als in D3.

Fablemark 1024*768

noAA/noAF = 60.9
noAA/8xAF = 58.9
4xAA/noAF = 28.5
4xAA/8xAF = 28.2 (-53.7%)

Wenn es nicht zuviel arbeit macht wären 2x und 6x noch interesant. Dann würde man sehen ob es ein bestimmtes Verhältniss beim Abfallen gibt.

[Ailuros]

Original geschrieben von Demirug
Wenn es nicht zuviel arbeit macht wären 2x und 6x noch interesant. Dann würde man sehen ob es ein bestimmtes Verhältniss beim Abfallen gibt.

2xAA = 46.5 (-23.6%)
6xAA = 18.6 (-69.4%)

Jeweils 2 samples -(~23%).

[Pussycat]

Original geschrieben von Demirug

NV30/NV35 = 1*4*2 (das weiss ich genau ;) )


Ich freu mich schon auf die 2*1*4*2 - multichip-lösungen :D.

[Demirug]

Original geschrieben von Ailuros
2xAA = 46.5 (-23.6%)
6xAA = 18.6 (-69.4%)

Jeweils 2 samples -(~23%).

Da muss noch was anderes limitieren. Denn wenn es nur die ROPs wären dürfte der Einbruch eigetlich nicht schon bei 2xAA losgehen ausser es wären sogar nur 8 Stencil Einheiten vorhanden.

[Exxtreme]

Original geschrieben von Demirug
Da muss noch was anderes limitieren. Denn wenn es nur die ROPs wären dürfte der Einbruch eigetlich nicht schon bei 2xAA losgehen ausser es wären sogar nur 8 Stencil Einheiten vorhanden.
Hmm, Speicherbandbreite? Das Teil hat AFAIK 'nen mords Overdraw.

[Demirug]

Original geschrieben von Exxtreme
Hmm, Speicherbandbreite? Das Teil hat AFAIK 'nen mords Overdraw.

Wäre möglich. der Stencilbuffer wird ja AFAIK nicht komprimiert und dort gibt es massenhaft Overdraw.

[Exxtreme]

Original geschrieben von Demirug
Wäre möglich. der Stencilbuffer wird ja AFAIK nicht komprimiert und dort gibt es massenhaft Overdraw.
Und vor allem werden die Stencil-Shadows auch mittels MSAA geglättet. Und da greift die Kompression nicht.

Ich würde gerne sehen wie es mit dem R350 aussieht. Dieser soll einige Verbesserungen in der Richtung haben.

[Razor]

Vielleicht ein paar Ergebnisse einer FX5900 gefällig ?
;-)
0°AF 8°AF Dif 0° Dif 8°

0xAA 69,7 65,4 - -
2xRG 48,0 45,8 -31,1% -30,0%
4xOG 41,5 40,1 -13,5% -12,4%
42,5% Gesamtverlust bei 4xOG/8°AF...
Und was sagt uns das jetzt ?
???

Razor

[zeckensack]

Original geschrieben von Razor
Vielleicht ein paar Ergebnisse einer FX5900 gefällig ?
;-)
0°AF 8°AF Dif 0° Dif 8°

0xAA 69,7 65,4 - -
2xRG 48,0 45,8 -31,1% -30,0%
4xOG 41,5 40,1 -13,5% -12,4%
42,5% Gesamtverlust bei 4xOG/8°AF...
Und was sagt uns das jetzt ?
???

Razor Daß der vergrößerte Stencil-Buffer nicht zum Flaschenhals wird. Im Gegenteil, die 5900 verliert hier - wie bei MSAA mit Kompression in 'klassischen' Renderern erwartet - beim Übergang auf höhere AA-Stufen weniger als beim Übergang von "nix" auf "2x".

edit:
Außerdem sagt uns das, daß du genug Grafikspeicher hast, um die Texturen auch mit 4xAA lokal zu haben.

NV-Chips können außerdem den Stencil-Buffer für sich alleine genommen seit spätestens NV20 in bursts lesen und schrieben. Was für Stencil-Schatten eine tolle Sache ist. Der R300 kann das nicht.

[strickjackenscheitel]

aber mal eine andere frage: wenn man nur scharf auf eine longhornfaehige und aa/af-lose grafikloesung fuer etwas weiter in die zukunft aus ist, kann man sich doch auch eine pny gf fx 5800 ultra bei alternate fuer 300 inkl. versand kaufen, den headspacer abhebeln und eine passivloesung von zalman draufsetzen(auf rams eben revoltek), oder?

das waere dann eine leistungsfaehige, lautlose und zukunftssichere loesung fuer verhaeltnismaessig wenig geld, richtig?

[Razor]

Original geschrieben von strickjackenscheitel
das waere dann eine leistungsfaehige, lautlose und zukunftssichere loesung fuer verhaeltnismaessig wenig geld, richtig?
Und wie willst Du die Hitzeentwicklung des DDR2-Speichers in den Griff bekommen ?
???

Razor

P.S.: Für Longhorn wird wohl auch 'ne (passive) FX5200 reichen...

[Razor]

Original geschrieben von zeckensack
Daß der vergrößerte Stencil-Buffer nicht zum Flaschenhals wird. Im Gegenteil, die 5900 verliert hier - wie bei MSAA mit Kompression in 'klassischen' Renderern erwartet - beim Übergang auf höhere AA-Stufen weniger als beim Übergang von "nix" auf "2x".

edit:
Außerdem sagt uns das, daß du genug Grafikspeicher hast, um die Texturen auch mit 4xAA lokal zu haben.

NV-Chips können außerdem den Stencil-Buffer für sich alleine genommen seit spätestens NV20 in bursts lesen und schrieben. Was für Stencil-Schatten eine tolle Sache ist. Der R300 kann das nicht.
Wirklich interessant...

Aber ob das mit der loken Datenhaltug der Texturen bei 4xAA auch bei höheren Auflösungen und in anderen Situationen noch hinhaut, ist natürlich die Frage...

Razor

[zeckensack]

Ich würde mir keinesfalls eine Karte kaufen, nur um "Sicherheit" für ein frühestens in zwei Jahren marktreifes OS zu verschaffen, das mir zudem noch völlig schnurzpiepe ist. Es gibt viele gute Gründe für Grafikkarten, aber sowas lehne ich ab.

[Ailuros]

Pffff Longhorn ist fuer 2005 hoechstwahrscheinlich. Bis dahin haben wir schon alle wohl nicht einmal, sondern mehrere Male aufgeruestet.

In zwei Jahren ist ne NV34 so gut fuer Spiele wie heute ne SDRAM/GF2MX.

[Ailuros]

Original geschrieben von Razor
Wirklich interessant...

Aber ob das mit der loken Datenhaltug der Texturen bei 4xAA auch bei höheren Auflösungen und in anderen Situationen noch hinhaut, ist natürlich die Frage...

Razor

Wie schwer ist das herauszufinden? Einfach Fablemark in einer hoeheren Aufloesung laufen lassen.

[Razor]

Original geschrieben von Ailuros
Pffff Longhorn ist fuer 2005 hoechstwahrscheinlich. Bis dahin haben wir schon alle wohl nicht einmal, sondern mehrere Male aufgeruestet.
Wir vielleicht schon...
Original geschrieben von Ailuros
In zwei Jahren ist ne NV34 so gut fuer Spiele wie heute ne SDRAM/GF2MX.
Wen interessieren Spiele bei einer Ulra-Low-End-Karte ?
Und 'taugt' eine gf2mx heute etwa nicht für den Desktop-Einsatz ?
???

Razor

[Razor]

Original geschrieben von Ailuros
Wie schwer ist das herauszufinden? Einfach Fablemark in einer hoeheren Aufloesung laufen lassen.
Na dann mal ran da !
;-)

Razor

[Ailuros]

Wen interessieren Spiele bei einer Ulra-Low-End-Karte ?
Und 'taugt' eine gf2mx heute etwa nicht für den Desktop-Einsatz ?

Da ist man sogar mit ner Matrox G400 besser angelegt. Muss ich jetzt erklaeren warum? :D

[Ailuros]

Original geschrieben von Razor
Na dann mal ran da !
;-)

Razor

Ich bezweifle dass es da besser aussieht fuer die R3xx. Ausser allem anderem sind da viel zu wenig Z/stencil Einheiten auf dem chip. Ich schaetze auf 16, Demi schaetzt 8.

[Razor]

Original geschrieben von Ailuros
Da ist man sogar mit ner Matrox G400 besser angelegt. Muss ich jetzt erklaeren warum? :D
Was im Falle einer (Club3d/Albatron ;-) FX5200 definitiv nicht mehr der Fall wäre...
:D

Razor

[Razor]

Original geschrieben von Ailuros
Ich bezweifle dass es da besser aussieht fuer die R3xx. Ausser allem anderem sind da viel zu wenig Z/stencil Einheiten auf dem chip. Ich schaetze auf 16, Demi schaetzt 8.
Ich hab' trotzdem mal 'geschaut'...
0xAA/0°AF 4xAA/8°AF Diff

1024x 768 69,7 40,1 - 42,5%
1280x 960 45,6 26,1 - 42,8%
1600x1200 29,7 17,3 - 41,8%
Zumindest beim FableMark scheint der 128MB FX5900 nicht der Video-Speicher auszugehen...
(was aber nicht unbedingt Rückschlüsse auf andere Appliaktionen zuläßt)

Razor

[StefanV]

Original geschrieben von Razor
Wir vielleicht schon...

Razor

Ja und??
Alle anderen auch, von unglaubnlichen 1-5% abgesehen...
Und die, die das nicht stört, kaufen sich bestimmt kein neues OS!!!

Außerdem solltest DU nicht vergessen, WIE M$ ihre Betriebssysteme an den Mann bringt...

Von daher sind deine Argumente wie 'aber die FX5200 ist gut für LH' völlig für die Hose...

[StefanV]

Original geschrieben von Ailuros
Da ist man sogar mit ner Matrox G400 besser angelegt. Muss ich jetzt erklaeren warum? :D

Ich fürchte, daß du das jetzt an dieser Stelle machen darfst :(

[Ailuros]

Original geschrieben von Razor
Ich hab' trotzdem mal 'geschaut'...
0xAA/0°AF 4xAA/8°AF Diff

1024x 768 69,7 40,1 - 42,5%
1280x 960 45,6 26,1 - 42,8%
1600x1200 29,7 17,3 - 41,8%
Zumindest beim FableMark scheint der 128MB FX5900 nicht der Video-Speicher auszugehen...
(was aber nicht unbedingt Rückschlüsse auf andere Appliaktionen zuläßt)

Razor

Fablemark ist Fuellraten-limitiert, was man eigentlich bei den Resultaten sehen kann.

[Ailuros]

Original geschrieben von Razor
Was im Falle einer (Club3d/Albatron ;-) FX5200 definitiv nicht mehr der Fall wäre...
:D

Razor

Du hast die GF2MX erwaehnt als 2D Loesung fuer heute, und zu der alleine im Vergleich hab ich die G400 erwaehnt. Und dazu gibt es wohl keine aber hm? ;)

[Quasar]

Original geschrieben von Exxtreme
Und vor allem werden die Stencil-Shadows auch mittels MSAA geglättet. Und da greift die Kompression nicht.

Ich würde gerne sehen wie es mit dem R350 aussieht. Dieser soll einige Verbesserungen in der Richtung haben.

Ich hoffe, es wurde noch nicht gepostet. Unten ist zum Vergleich die R9700p (325/310), oben, wie geschrieben, die R9800 (325/290).

Minimale Unterschiede, ebenso, wie beim Speichertakt der beiden Karten.

edit:
AF bewirkt beim Fablemark auf den R300 nur allerkleinste Performance-Einbrüche im Bereich von ca. 1 fps IIRC

[Ailuros]

Ich bezweifle dass es an der Kompression liegt. Es wurde schon oefters bei B3D indirekt angedeutet dass R3xx nicht die gleiche Anzahl von Z/stencil units haben wie AA samples.

Wenn das so waere haetten sie: 8*6= 48 Z/stencil

Ich persoenlich schaetze nicht mehr als 16Z/stencil, wobei jeder pipe dann 2 Z/stencil Einheiten zustehen sollten. Bei mehr als 2xAA wird dann einfach wohl geloopt. Etwa so:

2xAA = ein Durchgang
4xAA = zwei Durchgaenge 2*(2xAA)
6xAA = drei Durchgaenge 3*(2xAA)

Demi,

Doofe Laientheorie: kann es sein dass es nur 8 Z's sind und diese von beiden pipelineblocks geteilt werden?

[zeckensack]

Original geschrieben von Ailuros
Ich bezweifle dass es an der Kompression liegt. Es wurde schon oefters bei B3D indirekt angedeutet dass R3xx nicht die gleiche Anzahl von Z/stencil units haben wie AA samples.

Wenn das so waere haetten sie: 8*6= 48 Z/stencil

Ich persoenlich schaetze nicht mehr als 16Z/stencil, wobei jeder pipe dann 2 Z/stencil Einheiten zustehen sollten. Bei mehr als 2xAA wird dann einfach wohl geloopt. Etwa so:

2xAA = ein Durchgang
4xAA = zwei Durchgaenge 2*(2xAA)
6xAA = drei Durchgaenge 3*(2xAA)
Ich bin leider bandbreitenlimitiert :(
Aber schau mal:
Fillrate: depth only (Pix/s)
noAA 2xAA 4xAA 6xAA
16bpp 1.6G - - -
32bpp 911M 441M 218M 147M

Fillrate: color and depth with depth test
noAA 2xAA 4xAA 6xAA
16bpp 1.2G - - -
32bpp 917M 597M 450M 421M




edit: Tabelle korrigiert :bonk: und ergänzt :dozey:

[Demirug]

Original geschrieben von Ailuros
Ich bezweifle dass es an der Kompression liegt. Es wurde schon oefters bei B3D indirekt angedeutet dass R3xx nicht die gleiche Anzahl von Z/stencil units haben wie AA samples.

Wenn das so waere haetten sie: 8*6= 48 Z/stencil

Ich persoenlich schaetze nicht mehr als 16Z/stencil, wobei jeder pipe dann 2 Z/stencil Einheiten zustehen sollten. Bei mehr als 2xAA wird dann einfach wohl geloopt. Etwa so:

2xAA = ein Durchgang
4xAA = zwei Durchgaenge 2*(2xAA)
6xAA = drei Durchgaenge 3*(2xAA)

Demi,

Doofe Laientheorie: kann es sein dass es nur 8 Z's sind und diese von beiden pipelineblocks geteilt werden?

Dann würde ich eher auf jeweils 4 pro Block tippen weil ich nicht glaube das in diesem Bereich Pipelineübergreifend gearbeitet wird.

Aber wenn wie hier schon im Speku Forum sind stelle ich doch mal eine gewagte Theorie auf. Im R300 gibt es von keinem der 3 ROP-Elemente (Color, Z, Stencil) wirklich 6 Stück pro Pipeline. In den meisten Fällen ist das ja auch nicht notwendig weil alle 6 Samples im Framebuffer und die neuen Werte vom gleichen Dreieck sind. Die Kontrolllogik könnte durchaus weniger Platz brauchen als die ROPs 6 mal zu duplizieren.

[strickjackenscheitel]

Original geschrieben von Razor
Und wie willst Du die Hitzeentwicklung des DDR2-Speichers in den Griff bekommen ?
???

Razor

P.S.: Für Longhorn wird wohl auch 'ne (passive) FX5200 reichen...

ehmjaa ... ich hab was in klamer geschrieben. aber auch bei einem halbleiter halbgott ist nicht immer sonntag im hirn! =)

[strickjackenscheitel]

die frage ist doch wofuer eine 5900 oder nv 40, wenns doch auch eine 9700pro oder eine 5800u bringt?! die kuehlung kann man modifizieren und auch den speicher bekommt an unter den griff. also wer jetzt nicht waaahnsinnig auf aa und af steht, weil es u.a. auch ca. 80-180 euro mehr kostet, dann ist doch eine solche graka nicht zu ungeeignet, korrekt?

ueberhaupt habe ich das gefuehl, dass die neuen karten immer nur die hohen bis sehr hohen aufloesungen peitschen. 1024x768 wird kaum noch "getuned", was fuer mich im moment der grund ist, meine gf 4 ti mit 64mb nicht zu ersetzen. klingt das logisch?

[DrumDub]

ja, das klingt logisch. wer bei 1024x768 zockt, der brauch keine 9800pro/5900ultra...

da reicht auch eine 9600pro/5600ultra rev2...

[Sunrise]

@strickjackenscheitel:

Wer bei 1024x768 spielt, und keinen Wert auf AA/AF legt, der kann sowieso relativ wenig mit einer NV40 oder R420 anfangen...

Du solltest Dir allerdings im Klaren sein, daß Spiele ab DX8 deine Karte stark ans Limit bringen, außer du schaltest wirklich alles auf niedrigste Settings.

Ich selbst "Spiele" noch mit einer GeForce1 DDR, und sehe bisher noch keinen wirklichen Grund aufzurüsten, aber da bin ich wohl einer der Wenigen :)

[Demirug]

Ich habe die PS 2.0 bei TR6 Sache mal verschoben.

http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&threadid=88196

[Razor]

Original geschrieben von Demirug
Ich habe die PS 2.0 bei TR6 Sache mal verschoben.

http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&threadid=88196
Thx !

Razor

[Ailuros]

Original geschrieben von Demirug
Dann würde ich eher auf jeweils 4 pro Block tippen weil ich nicht glaube das in diesem Bereich Pipelineübergreifend gearbeitet wird.

Aber wenn wie hier schon im Speku Forum sind stelle ich doch mal eine gewagte Theorie auf. Im R300 gibt es von keinem der 3 ROP-Elemente (Color, Z, Stencil) wirklich 6 Stück pro Pipeline. In den meisten Fällen ist das ja auch nicht notwendig weil alle 6 Samples im Framebuffer und die neuen Werte vom gleichen Dreieck sind. Die Kontrolllogik könnte durchaus weniger Platz brauchen als die ROPs 6 mal zu duplizieren.

Wieviele ROPs schaetzt koennte R3xx haben?

[Demirug]

Original geschrieben von Ailuros
Wieviele ROPs schaetzt koennte R3xx haben?

Sehr schwer zu sagen. Ich könnte da nur blind raten und das mache ich nicht gerne.

[StefanV]

Original geschrieben von Demirug
Sehr schwer zu sagen. Ich könnte da nur blind raten und das mache ich nicht gerne.

Hm, dann schätz mal bitte =)

[Demirug]

Original geschrieben von Stefan Payne
Hm, dann schätz mal bitte =)

Nein, das ist mir zu heiss. Ich überlege mir da mal lieber wie man das testen könnte.

[Ailuros]

Vielleicht hilft der Link hier:

http://www.beyond3d.com/forum/viewtopic.php?t=7486

[StefanV]

Original geschrieben von Ailuros
Vielleicht hilft der Link hier:

http://www.beyond3d.com/forum/viewtopic.php?t=7486

:O

Teilweise liegen zwischen NV35 und R300 ja Welten, bei den Pixelshadern...

[Razor]

Original geschrieben von Stefan Payne
Teilweise liegen zwischen NV35 und R300 ja Welten, bei den Pixelshadern...
Sowohl in die eine, wie auch in die andere Richtung...
;-)

Razor

[Razor]

@Demirug

Habe mal wieder eine Shader.Out von diesem Proggi gefertigt...
///////////////Pixel Shader - start//////////////
ps_1_1

def c0 , 0.300000, 0.700000, 0.200000, 0.400000

add r0 , c0 , v1
add r0 , r0 , -v0
///////////////Pixel Shader - end//////////////
///////////////Pixel Shader - start//////////////
ps_1_4

def c0 , 0.300000, 0.700000, 0.200000, 0.400000

texcrd r1.xyz , t0
texcrd r2.xyz , t1
add r3.xyz , c0 , r2
add r3.xyz , r3 , -r1
phase

mov r0.xyz , r3
+mov r0.w , c0.wwww
///////////////Pixel Shader - end//////////////
///////////////Vertex Shader - start//////////////
vs_1_1

dcl_position0 v0
dcl_color0 v1
dcl_color1 v2
mov oPos , v0
mov oT0 , v1
mov oT1 , v2
///////////////Vertex Shader - end//////////////
///////////////Pixel Shader - start//////////////
ps_2_0

dcl v0
dcl v1
def c0 , 0.300000, 0.700000, 0.200000, 0.400000

add r0 , c0 , v1
add r0 , r0 , -v0
mov oC0 , r0
///////////////Pixel Shader - end//////////////
///////////////Pixel Shader - start//////////////
ps_2_0

dcl v0
dcl v1
def c0 , 0.300000, 0.700000, 0.200000, 0.400000

add_pp r0 , c0 , v1
add_pp r0 , r0 , -v0
mov_pp oC0 , r0
///////////////Pixel Shader - end//////////////
///////////////Pixel Shader - start//////////////
ps_2_0

dcl v0
dcl v1
def c0 , 0.300000, 0.700000, 0.200000, 0.400000

def c1 , 0.900000, 0.300000, 0.800000, 0.600000

add r0 , c0 , v1
mad r0 , c1 , r0 , -v0
mad r0 , v1 , r0 , c1
mad r0 , v0 , c0 , r0
mov oC0 , r0
///////////////Pixel Shader - end//////////////
///////////////Pixel Shader - start//////////////
ps_2_0

dcl v0
dcl v1
def c0 , 0.300000, 0.700000, 0.200000, 0.400000

def c1 , 0.900000, 0.300000, 0.800000, 0.600000

add_pp r0 , c0 , v1
mad_pp r0 , c1 , r0 , -v0
mad_pp r0 , v1 , r0 , c1
mad_pp r0 , v0 , c0 , r0
mov_pp oC0 , r0
///////////////Pixel Shader - end//////////////
///////////////Pixel Shader - start//////////////
ps_2_0

dcl v0
dcl v1
def c0 , 0.300000, 0.700000, 0.200000, 0.400000

def c1 , 0.900000, 0.300000, 0.800000, 0.600000

add r0 , c0 , v1
mad r1 , c1 , r0 , -v0
mad r2 , v1 , r1 , c1
mad r3 , r0 , r1 , r2
mov oC0 , r3
///////////////Pixel Shader - end//////////////
///////////////Pixel Shader - start//////////////
ps_2_0

dcl v0
dcl v1
def c0 , 0.300000, 0.700000, 0.200000, 0.400000

def c1 , 0.900000, 0.300000, 0.800000, 0.600000

add_pp r0 , c0 , v1
mad_pp r1 , c1 , r0 , -v0
mad_pp r2 , v1 , r1 , c1
mad_pp r3 , r0 , r1 , r2
mov_pp oC0 , r3
///////////////Pixel Shader - end//////////////
///////////////Pixel Shader - start//////////////
ps_2_0

def c0 , 0.000000, 0.000000, 2.000000, 0.000000

def c1 , 0.400000, 0.500000, 0.900000, 16.000000

dcl t0.xy
dcl t1.xyz
dcl t2.xyz
dcl_2d s0
dcl_2d s1
dp3 r1.w , t1 , t1
rsq r1.w , r1.wwww
mul r1.xyz , t1 , r1.wwww
add r0.xyz , c0 , -t2
dp3 r0.w , r0 , r0
rsq r0.w , r0.wwww
mad r0.xyz , r0 , r0.wwww , r1
dp3 r0.w , r0 , r0
rsq r0.w , r0.wwww
mul r0.xyz , r0 , r0.wwww
texld r2 , t0 , s0
dp3 r2.w , r2 , r2
rsq r2.w , r2.wwww
mul r2.xyz , r2 , r2.wwww
dp3 r1.w , r2 , r0
dp3 r1.xyz , r2 , r1
pow r1.w , r1.wwww , c1.wwww
mad r1.xyz , r1 , c1 , r1.wwww
texld r0 , t0 , s1
mul r0 , r1 , r0
mov oC0 , r0
///////////////Pixel Shader - end//////////////
///////////////Vertex Shader - start//////////////
vs_1_1

dcl_position0 v0
dcl_texcoord0 v1
def c0 , 0.000000, 0.000000, 2.000000, 0.000000

mov oPos , v0
mov oT0 , v1
add oT1 , v0 , c0
mov oT2 , v0
///////////////Vertex Shader - end//////////////
///////////////Pixel Shader - start//////////////
ps_2_0

def c0 , 0.000000, 0.000000, 2.000000, 0.000000

def c1 , 0.400000, 0.500000, 0.900000, 16.000000

dcl t0.xy
dcl t1.xyz
dcl t2.xyz
dcl_2d s0
dcl_2d s1
dp3_pp r1.w , t1 , t1
rsq_pp r1.w , r1.wwww
mul_pp r1.xyz , t1 , r1.wwww
add_pp r0.xyz , c0 , -t2
dp3_pp r0.w , r0 , r0
rsq_pp r0.w , r0.wwww
mad_pp r0.xyz , r0 , r0.wwww , r1
dp3_pp r0.w , r0 , r0
rsq_pp r0.w , r0.wwww
mul_pp r0.xyz , r0 , r0.wwww
texld_pp r2 , t0 , s0
dp3_pp r2.w , r2 , r2
rsq_pp r2.w , r2.wwww
mul_pp r2.xyz , r2 , r2.wwww
dp3_pp r1.w , r2 , r0
dp3_pp r1.xyz , r2 , r1
pow_pp r1.w , r1.wwww , c1.wwww
mad_pp r1.xyz , r1 , c1 , r1.wwww
texld_pp r0 , t0 , s1
mul_pp r0 , r1 , r0
mov_pp oC0 , r0
///////////////Pixel Shader - end//////////////
///////////////Vertex Shader - start//////////////
vs_1_1

dcl_position0 v0
dcl_texcoord0 v1
def c0 , 0.000000, 0.000000, 2.000000, 0.000000

mov oPos , v0
mov oT0 , v1
add oT1 , v0 , c0
mov oT2 , v0
///////////////Vertex Shader - end//////////////
Und "Marko's Fillrate Tester" kann man hier downen:
http://www2.arnes.si/~mdolen/FillrateTester.zip

Ist dieses Proggi also wirklich in der Lage, Karten auf diese Weise zu vergleichen ?

-

So, ich muss jetzt die Klamotte packen...
Und dann geht's abbbbbbbbbb !
;D

Razor

[Razor]

Und vielleicht jemand an dem Ergebnis eine 'lahmen' FX5900 interessiert ?
;D
Fillrate Tester
--------------------------
Display adapter: NVIDIA GeForce FX 5900
Driver version: 6.14.10.4523
Display mode: 320x200 A8R8G8B8 75Hz
Z-Buffer format: D24S8
--------------------------

FFP - Pure fillrate 1731.251831M pixels/sec
FFP - Z pixel rate 3341.708252M pixels/sec
FFP - Single texture 452.903259M pixels/sec
FFP - Dual texture 232.947922M pixels/sec
FFP - Triple texture 150.651520M pixels/sec
FFP - Quad texture 108.293358M pixels/sec
PS 1.1 - Simple 885.758545M pixels/sec
PS 1.4 - Simple 833.865906M pixels/sec
PS 2.0 - Simple 419.415131M pixels/sec
PS 2.0 PP - Simple 557.717957M pixels/sec
PS 2.0 - Longer 168.316254M pixels/sec
PS 2.0 PP - Longer 335.796295M pixels/sec
PS 2.0 - Longer 4 Registers 179.985428M pixels/sec
PS 2.0 PP - Longer 4 Registers 419.001434M pixels/sec
PS 2.0 - Per Pixel Lighting 61.004990M pixels/sec
PS 2.0 PP - Per Pixel Lighting 79.146484M pixels/sec
Jetzt aber ab in den Flieger !
:D

Razor

[Ailuros]

Original geschrieben von Razor
Sowohl in die eine, wie auch in die andere Richtung...
;-)

Razor

Wuerde man Richtungen illustrieren sieht es wohl so aus:

R350<<<<<<<<<<<<<<<--->NV35

Oder 15:1 :P

[ShadowXX]

@Ailuros

full ack...(wollte nur nichts sagen....sonst heisst das gleich Flamewar.)

[Demirug]

Sehr Interresant.

1. Der R300 "bescheist" bei diesem Benchmark indem er nicht genau die Shader ausführt die übergeben werden. Ist aber völlig in Ordnung weil da Blind Anweisungen herausoptimiert werden.

Beweis:


ps_2_0

dcl v0
dcl v1
def c0 , 0.300000, 0.700000, 0.200000, 0.400000

add r0 , c0 , v1
add r0 , r0 , -v0
mov oC0 , r0


3 Anweisungen keine Parralleausführung möglich. Der R350 schafft hier 1490,28 MP was 4470,84 MSI/s entspricht. Es sind 8 Instruktionen pro Takt möglich. Der R350 müsste also mit 558,855 MHz gelaufen sein. Wird dagegen die letzte mov Anweisung entfernt kommen wir nur noch auf 2980,56 MSI/s was 372,57 MHz entspricht. Ein bischen verschnitt und wir sind bei 380.

Bei den anderen Shader sieht es ähnlich aus.

2. Beim NV35 hat sich nv wirklich eine Falle eingebaut welche 1.X Shader bremst. Ob sie da noch eine Lösung finden?

3. Das "Per Pixel Light" Ergebniss des R300 scheint doch zu gering. Wir haben 8*380 MSI/s = 3040 MSI/s. Der Test erreicht 111,58 MPixel was einer benötigen rechneleistung von 27,25 Anweisungen pro Pixel entspricht. Der Shader hat aber nur 21 Anweisungen (2 davon tex). Entweder braucht die die pow Anweisung unverhältnissmässig lang oder die beiden Quer eingestreuten Tex-Anweisungen verwiren den eingebauten Optimizer so das er einen Mehrphasen Shader daraus baut was eigentlich gar nicht notwendig sein sollte.

EDIT: PS: Die NV35 PS 2.0 ergebnisse sehen irgendwie so aus als würde das Teil in einem NV30 Modus laufen

[LovesuckZ]

Original geschrieben von Demirug
EDIT: PS: Die NV35 PS 2.0 ergebnisse sehen irgendwie so aus als würde das Teil in einem NV30 Modus laufen

Scheint wohl so:

5800 400/800

PS 2.0 - Simple - 499.868927M pixels/sec
PS 2.0 PP - Simple - 499.765503M pixels/sec
PS 2.0 - Longer - 300.913635M pixels/sec
PS 2.0 PP - Longer - 300.962036M pixels/sec
PS 2.0 - Longer 4 Registers - 241.796982M pixels/sec
PS 2.0 PP - Longer 4 Registers - 300.581818M pixels/sec
PS 2.0 - Per Pixel Lighting - 47.232174M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 54.600693M pixels/sec

[Ailuros]

Original geschrieben von ShadowXX
@Ailuros

full ack...(wollte nur nichts sagen....sonst heisst das gleich Flamewar.)

Ich spekuliere dass ich mit Erwachsenen diskuttiere :)

[Ailuros]

Dave gibt keine Aufloesung an, aber ich schaetze dass er nicht mit 320 gebencht hat, sondern mit 1600*1200.

Nur so als Nebennotiz ist es meiner Meinung besser wenn man Fuellraten in den Aufloesungen bencht, in denen man auch selber spielt (nicht dass sich die Resultate grandios aendern werden...).

[strickjackenscheitel]

na hae? ich spiele auch oft in der aufloesung... habn 21 zoll moni.

"Ich spekuliere dass ich mit Erwachsenen diskuttiere " ja lustig, dass dachte ich auch. ehm moment =)

kann zu den ganzen benches mal mit ner gf 4 ti vgl.? wuerdet mir nen gefallen tun!

[Ailuros]

Errr ich meinte dass es wenig Sinn macht Fuellraten in 320*200 zu messen, da man ja alle moeglichen Aufloesungen im Programm waehlen kann. Oder meintest Du dass Du auf nem 21" in 320 spielst? :shock:

:D

[DrumDub]

9700np bei 375/300

Fillrate Tester
--------------------------
Display adapter: RADEON 9700 PRO (Omega 2.4.74a)
Driver version: 6.14.10.6374
Display mode: 320x200 A8R8G8B8 75Hz
Z-Buffer format: D24S8
--------------------------

FFP - Pure fillrate 1943.827271M pixels/sec
FFP - Z pixel rate 2220.302246M pixels/sec
FFP - Single texture 496.206390M pixels/sec
FFP - Dual texture 373.261261M pixels/sec
FFP - Triple texture 183.103119M pixels/sec
FFP - Quad texture 142.908081M pixels/sec
PS 1.1 - Simple 1289.685303M pixels/sec
PS 1.4 - Simple 1323.355957M pixels/sec
PS 2.0 - Simple 1396.363403M pixels/sec
PS 2.0 PP - Simple 1317.415649M pixels/sec
PS 2.0 - Longer 698.834961M pixels/sec
PS 2.0 PP - Longer 716.751709M pixels/sec
PS 2.0 - Longer 4 Registers 718.260193M pixels/sec
PS 2.0 PP - Longer 4 Registers 694.934814M pixels/sec
PS 2.0 - Per Pixel Lighting 154.221939M pixels/sec
PS 2.0 PP - Per Pixel Lighting 153.034409M pixels/sec

[Demirug]

Original geschrieben von DrumDub
9700np bei 375/300

PS 2.0 - Per Pixel Lighting 154.221939M pixels/sec
PS 2.0 PP - Per Pixel Lighting 153.034409M pixels/sec


Das stimmt jetzt. 19 Takte pro Pixel kommen schon eher hin.

[Keel]

Original geschrieben von strickjackenscheitel
na hae? ich spiele auch oft in der aufloesung... habn 21 zoll moni.

"Ich spekuliere dass ich mit Erwachsenen diskuttiere " ja lustig, dass dachte ich auch. ehm moment =)

kann zu den ganzen benches mal mit ner gf 4 ti vgl.? wuerdet mir nen gefallen tun!

Ja, ich! Deto 43.00:
Fillrate Tester
--------------------------
Display adapter: NVIDIA GeForce4 Ti 4200
Driver version: 6.14.1.4300
Display mode: 1024x768 A8R8G8B8 100Hz
Z-Buffer format: D24S8
--------------------------

FFP - Pure fillrate - 976.333984M pixels/sec
FFP - Z pixel rate - 974.580444M pixels/sec
FFP - Single texture - 819.913086M pixels/sec
FFP - Dual texture - 712.642517M pixels/sec
FFP - Triple texture - 437.558441M pixels/sec
FFP - Quad texture - 356.878540M pixels/sec
PS 1.1 - Simple - 493.084717M pixels/sec
PS 1.4 - Simple - Failed!
PS 2.0 - Simple - Failed!
PS 2.0 PP - Simple - Failed!
PS 2.0 - Longer - Failed!
PS 2.0 PP - Longer - Failed!
PS 2.0 - Longer 4 Registers - Failed!
PS 2.0 PP - Longer 4 Registers - Failed!
PS 2.0 - Per Pixel Lighting - Failed!
PS 2.0 PP - Per Pixel Lighting - Failed!

Oder soll ich andere Einstellungen verwenden? Weil teilweise sagen mir gewisse Einstellungen überhaupt nichts...

[Quasar]

Original geschrieben von Razor
Fillrate Tester
--------------------------
Display adapter: NVIDIA GeForce FX 5900 [5800u]
Driver version: 6.14.10.4523
Display mode: 320x200 A8R8G8B8 75Hz
Z-Buffer format: D24S8
--------------------------

FFP - Pure fillrate 1731.251831M pixels/sec [1945]
FFP - Z pixel rate 3341.708252M pixels/sec [3576]
FFP - Single texture 452.903259M pixels/sec [347]
FFP - Dual texture 232.947922M pixels/sec [196]
FFP - Triple texture 150.651520M pixels/sec [127]
FFP - Quad texture 108.293358M pixels/sec [93]
PS 1.1 - Simple 885.758545M pixels/sec [983]
PS 1.4 - Simple 833.865906M pixels/sec [925]
PS 2.0 - Simple 419.415131M pixels/sec [624]
PS 2.0 PP - Simple 557.717957M pixels/sec [624]
PS 2.0 - Longer 168.316254M pixels/sec [376]
PS 2.0 PP - Longer 335.796295M pixels/sec [375]
PS 2.0 - Longer 4 Registers 179.985428M pixels/sec [302]
PS 2.0 PP - Longer 4 Registers 419.001434M pixels/sec [375]
PS 2.0 - Per Pixel Lighting 61.004990M pixels/sec [46]
PS 2.0 PP - Per Pixel Lighting 79.146484M pixels/sec [52]


Uiha, ich fühle mich mehr und mehr bestätigt, dass die FX5800u (meine Ergebnisse in eckigen Klammern im Quote] doch kein schlechter Kauf war. :D

edit:
Kursiv = pro FX5900
Fett = pro FX5800u

edit2:
Die Texturing-Werte schnellen natürlich geradezu in die höhe, wenn man "normale" Auflösungen nimmt (in 1024: 1571/1303/739/515, ebenso das Perpixel-Lighting (59 / 68) auch wenn ich es hier nicht so selbstverständlich finde.

[DrumDub]

komisch sind die beiden werte im vergleich:

PS 2.0 - Longer 168.316254M pixels/sec [376]
PS 2.0 - Longer 4 Registers 179.985428M pixels/sec [302]

da ist die 5800u einmal mehr als doppelt so schnell und ein anderes mal zwei drittel schneller. und das bei nur einem viertel mehr gpu-takt. :kratz:

[micki]

*vermut*
vielleicht "pasted" der driver an gewissen stellen geschickt pp ein :) (nicht in jedem fall) deswegen könnten die ergebnisse in den eckigen klammern sowenig unterschied zwischen pp und ohne aufweisen.

MfG
micki

[Ailuros]

Original geschrieben von DrumDub
9700np bei 375/300

Fillrate Tester
--------------------------
Display adapter: RADEON 9700 PRO (Omega 2.4.74a)
Driver version: 6.14.10.6374
Display mode: 320x200 A8R8G8B8 75Hz
Z-Buffer format: D24S8
--------------------------

FFP - Pure fillrate 1943.827271M pixels/sec
FFP - Z pixel rate 2220.302246M pixels/sec
FFP - Single texture 496.206390M pixels/sec
FFP - Dual texture 373.261261M pixels/sec
FFP - Triple texture 183.103119M pixels/sec
FFP - Quad texture 142.908081M pixels/sec
PS 1.1 - Simple 1289.685303M pixels/sec
PS 1.4 - Simple 1323.355957M pixels/sec
PS 2.0 - Simple 1396.363403M pixels/sec
PS 2.0 PP - Simple 1317.415649M pixels/sec
PS 2.0 - Longer 698.834961M pixels/sec
PS 2.0 PP - Longer 716.751709M pixels/sec
PS 2.0 - Longer 4 Registers 718.260193M pixels/sec
PS 2.0 PP - Longer 4 Registers 694.934814M pixels/sec
PS 2.0 - Per Pixel Lighting 154.221939M pixels/sec
PS 2.0 PP - Per Pixel Lighting 153.034409M pixels/sec


Wenn's wirklich nicht zu viel Muehe macht, koenntest Du mal die Fuellraten von der hoechsten moeglichen Aufloesung die Dein Bildschirm unterstuetzt posten? (hab momentan keine Zeit sonst wuerde ich's selber machen).

[Quasar]

edit: Stimmte alles nicht :(


Fillrate Tester
--------------------------
Display adapter: NVIDIA GeForce FX 5800 Ultra /Radeon9700 Pro
Driver version: 6.14.10.4524 / Cat 3.6
Display mode: 1600x1200 A8R8G8B8 60Hz
Z-Buffer format: D24S8
--------------------------

FFP - Pure fillrate - 1952M / 2457M pixels/sec
FFP - Z pixel rate - 3632M / 2176M pixels/sec
FFP - Single texture - 1714M / 2336M pixels/sec
FFP - Dual texture - 1554M / 1216M pixels/sec
FFP - Triple texture - 838M / 681M pixels/sec
FFP - Quad texture - 577M / 549M pixels/sec
PS 1.1 - Simple - 989M / 1279M pixels/sec
PS 1.4 - Simple - 932M / 1279M pixels/sec
PS 2.0 - Simple - 628M / 1279M pixels/sec
PS 2.0 PP - Simple - 628M / 1279M pixels/sec
PS 2.0 - Longer - 379M / 643M pixels/sec
PS 2.0 PP - Longer - 378M / 643M pixels/sec
PS 2.0 - Longer 4 Registers - 304M / 643M pixels/sec
PS 2.0 PP - Longer 4 Registers - 378M / 643M pixels/sec
PS 2.0 - Per Pixel Lighting - 60M / 135M pixels/sec
PS 2.0 PP - Per Pixel Lighting - 69M / 135M pixels/sec


P.S.:
Warum wollte der Test auf meiner R9700p einen D16_LOCKABLE Z-Buffer haben, und vor allem: WTF ist das?

[DrumDub]

Original geschrieben von Ailuros
Wenn's wirklich nicht zu viel Muehe macht, koenntest Du mal die Fuellraten von der hoechsten moeglichen Aufloesung die Dein Bildschirm unterstuetzt posten? (hab momentan keine Zeit sonst wuerde ich's selber machen).

bitteschön. :D

9700np bei 375/300

Fillrate Tester
--------------------------
Display adapter: RADEON 9700 PRO (Omega 2.4.74a)
Driver version: 6.14.10.6374
Display mode: 1600x1200 A8R8G8B8 75Hz
Z-Buffer format: D24S8
--------------------------

FFP - Pure fillrate 2378.057129M pixels/sec
FFP - Z pixel rate 2487.952148M pixels/sec
FFP - Single texture 2316.621582M pixels/sec
FFP - Dual texture 1346.508179M pixels/sec
FFP - Triple texture 702.234070M pixels/sec
FFP - Quad texture 575.921692M pixels/sec
PS 1.1 - Simple 1482.908936M pixels/sec
PS 1.4 - Simple 1478.150024M pixels/sec
PS 2.0 - Simple 1477.882080M pixels/sec
PS 2.0 PP - Simple 1478.067749M pixels/sec
PS 2.0 - Longer 743.819275M pixels/sec
PS 2.0 PP - Longer 744.659485M pixels/sec
PS 2.0 - Longer 4 Registers 743.822815M pixels/sec
PS 2.0 PP - Longer 4 Registers 743.832825M pixels/sec
PS 2.0 - Per Pixel Lighting 157.182648M pixels/sec
PS 2.0 PP - Per Pixel Lighting 157.192459M pixels/sec

[strickjackenscheitel]

Original geschrieben von Keel
Ja, ich! Deto 43.00:
Fillrate Tester
--------------------------
Display adapter: NVIDIA GeForce4 Ti 4200
Driver version: 6.14.1.4300
Display mode: 1024x768 A8R8G8B8 100Hz
Z-Buffer format: D24S8
--------------------------

FFP - Pure fillrate - 976.333984M pixels/sec
FFP - Z pixel rate - 974.580444M pixels/sec
FFP - Single texture - 819.913086M pixels/sec
FFP - Dual texture - 712.642517M pixels/sec
FFP - Triple texture - 437.558441M pixels/sec
FFP - Quad texture - 356.878540M pixels/sec
PS 1.1 - Simple - 493.084717M pixels/sec
PS 1.4 - Simple - Failed!
PS 2.0 - Simple - Failed!
PS 2.0 PP - Simple - Failed!
PS 2.0 - Longer - Failed!
PS 2.0 PP - Longer - Failed!
PS 2.0 - Longer 4 Registers - Failed!
PS 2.0 PP - Longer 4 Registers - Failed!
PS 2.0 - Per Pixel Lighting - Failed!
PS 2.0 PP - Per Pixel Lighting - Failed!

Oder soll ich andere Einstellungen verwenden? Weil teilweise sagen mir gewisse Einstellungen überhaupt nichts...

DANKE DANKE!!! ehm mir sagt es zumindest soviel, dass ich mir nicht so schnell eine neue graka kaufen muss, wenn ich bei dieser aufloesung mit keinem oder geringem aa/af spiele.
DANKE!

[Ailuros]

Danke Drumdub.

Moment mal eine nonPRO auf 375MHz? :O Heiliger Bimbam....

[DrumDub]

hehe... ja. :D sie packt auch 388 mhz gpu-takt, wenn es was kälter ist. 375 mhz läuft aber momentan absolut stabil.

hier mal der direkte vergleich. unübertaktet und übertaktet. die gpu skaliert gut mit der übertaktung, würde ich sagen. :D

Fillrate Tester
--------------------------
Display adapter: RADEON 9700 PRO (Omega 2.4.74a)
Driver version: 6.14.10.6374
Display mode: 1600x1200 A8R8G8B8 75Hz
Z-Buffer format: D24S8
--------------------------

Radeon 9700 275/270 375/300 36,36%/11,11%

FFP - Pure fillrate 2110,15772M pixels/sec 2378,05713M pixels/sec 12,70%
FFP - Z pixel rate 1905,63611M pixels/sec 2487,95215M pixels/sec 30,56%
FFP - Single texture 2001,98059M pixels/sec 2316,62158M pixels/sec 15,72%
FFP - Dual texture 1048,91333M pixels/sec 1346,50818M pixels/sec 28,37%
FFP - Triple texture 599,97162M pixels/sec 702,23407M pixels/sec 17,04%
FFP - Quad texture 476,49091M pixels/sec 575,92169M pixels/sec 20,87%
PS 1.1 - Simple 1085,82861M pixels/sec 1482,90894M pixels/sec 36,57%
PS 1.4 - Simple 1085,97192M pixels/sec 1478,15002M pixels/sec 36,11%
PS 2.0 - Simple 1084,46375M pixels/sec 1477,88208M pixels/sec 36,28%
PS 2.0 PP - Simple 1086,03308M pixels/sec 1478,06775M pixels/sec 36,10%
PS 2.0 - Longer 545,84015M pixels/sec 743,81928M pixels/sec 36,27%
PS 2.0 PP - Longer 549,39130M pixels/sec 744,65949M pixels/sec 35,54%
PS 2.0 - Longer 4 Registers 545,84351M pixels/sec 743,82282M pixels/sec 36,27%
PS 2.0 PP - Longer 4 Registers 544,95490M pixels/sec 743,83283M pixels/sec 36,49%
PS 2.0 - Per Pixel Lighting 115,35558M pixels/sec 157,18265M pixels/sec 36,26%
PS 2.0 PP - Per Pixel Lighting 115,27351M pixels/sec 157,19246M pixels/sec 36,36%

[Ailuros]

hier mal der direkte vergleich. unübertaktet und übertaktet. die gpu skaliert gut mit der übertaktung, würde ich sagen.

Es ist ja auch zu erwarten da die Applikation Fuellraten misst.

[LovesuckZ]

Original geschrieben von Demirug
2. Beim NV35 hat sich nv wirklich eine Falle eingebaut welche 1.X Shader bremst. Ob sie da noch eine Lösung finden?


Das hat sich ja mit den Spielen gezeigt, welche vom PS1.x gebrauch machen und dies ist ja keine NV35 Beschraenkung.
Kann es auch sein, dass Nvidia bei diesen Shadern keine Veraenderung vorgenommen hat und sie einfach nur übernahm? Denn so wie es aussieht, hat meine NV30 keine bessere PS1.x (<4) Leistung als eine gleichgetaktete GF4TI.
Das wird ein fest, wenn die naechsten PS1.x Spiele auf den markt kommen und ein benchmarkprogramm intus haben...

[strickjackenscheitel]

ich habe ueberhaupt das gefuehl, dass die r3x0er reihe von nv ein viel besseres promhz-verhaeltnis haben la die nv3x.

man sollte mal alle aktuellen highendgrakas gleich takten und dann durch mehrere test jagen.

auch von dem nv40 erwarte ich mir keine meilenspruenge.
aber was weiss ich schon? ...

[Quasar]

Original geschrieben von strickjackenscheitel
man sollte mal alle aktuellen highendgrakas gleich takten und dann durch mehrere test jagen.


Man sollte IMO vielmehr aktuelle Grafikkarten auf möglichst identische:
- Pixelfüllrate
- Texelfüllrate
- Speicherbandbreite

bringen und dann mal vergleichen (auch mit der vorigen Generation...).

[Demirug]

LovesuckZ, Ja CineFX I sollte bei PS 1.1-1.3 keine bessere pro MHz Leistung als die GF4TI haben. CineFX II (NV35) hat sogar eher eine schlechtere pro MHz Leistung dabei weil dort wohl einige Optimierungsmöglichkeiten weggefallen sind als man die beiden FX12 ALUs gegen eine FP32 FPU mit FX12 Unterstützung getauscht hat.

[zeckensack]

Original geschrieben von Quasar
P.S.:
Warum wollte der Test auf meiner R9700p einen D16_LOCKABLE Z-Buffer haben, und vor allem: WTF ist das? Das ist ein Designfehler in DX ;)
D16_LOCKABLE ist ein Z-Buffer-Format, das dazu gedacht ist, daß Applikation direkt in diesem Speicherbereich (via "Lock") herumpopeln dürfen.
Sämtliche Hardware-Optimierung des Z-Buffers, etwa hierarchische Anordnung, oder gar von 16 Bit Integer 'abweichende' Zahlenformate müssen hierfür abgeschaltet werden.

MS hat es also geschafft, durch das anbieten einer vordergründig nützlichen Schnittstelle Hardware auf eine spezifische Arbeitsweise zu zwingen, die auch heute noch unterstützt werden muß ... was ausgesprochen dämlich ist.

Glide hat übrigens den gleichen Design-Fehler, der mir bis heute (>1.5 Jahre Entwicklungszeit) schwer zu schaffen macht.

[Demirug]

Original geschrieben von zeckensack
Das ist ein Designfehler in DX ;)
D16_LOCKABLE ist ein Z-Buffer-Format, das dazu gedacht ist, daß Applikation direkt in diesem Speicherbereich (via "Lock") herumpopeln dürfen.
Sämtliche Hardware-Optimierung des Z-Buffers, etwa hierarchische Anordnung, oder gar von 16 Bit Integer 'abweichende' Zahlenformate müssen hierfür abgeschaltet werden.

MS hat es also geschafft, durch das anbieten einer vordergründig nützlichen Schnittstelle Hardware auf eine spezifische Arbeitsweise zu zwingen, die auch heute noch unterstützt werden muß ... was ausgesprochen dämlich ist.

Glide hat übrigens den gleichen Design-Fehler, der mir bis heute (>1.5 Jahre Entwicklungszeit) schwer zu schaffen macht.

Intern darf ein Chip machen was er will solange er sich an drei Regeln hält.

-Der Z-Buffer muss sich wie ein 16 Bit Z-Buffer verhalten (deswegen will man ja einen 16 Bit Z-Buffer)
-Nach dem Look muss der Z-Buffer in einem Speicherbreich im definierten 16Bit Format zum auslesen/bearbeiten zur Verfügung stehen. Bei Bedarf muss der Treiber eben eine Konvertierung durchführen
-Nach dem Unlock müssen (die entsprechende Flags vorrausgesetzt) die geänderten Bereiche wieder zurück zur Grafikkarte und dabei bei Bedarf wieder gewandelt werden.

Aber wer zu Hölle benutzt "D16_LOCKABLE" ausser als letzte Rettung oder wenn man wirklich einen auslesbaren Z-Buffer braucht?

[Exxtreme]

Original geschrieben von Demirug
Aber wer zu Hölle benutzt "D16_LOCKABLE" ausser als letzte Rettung oder wenn man wirklich einen auslesbaren Z-Buffer braucht?
Eieiei, unterschätze bitte die ähhhm, "Kreativität" einiger Coder nicht. ;)

Dank solcher "kreativen" Köpfe haben wir immer noch das A20-Gate etc.

[Quasar]

Original geschrieben von zeckensack
Sämtliche Hardware-Optimierung des Z-Buffers, etwa hierarchische Anordnung, oder gar von 16 Bit Integer 'abweichende' Zahlenformate müssen hierfür abgeschaltet werden.

Das bedeutet im Laien-Jargon: Lahmer geht's nimmer?

[zeckensack]

Original geschrieben von Quasar
Das bedeutet im Laien-Jargon: Lahmer geht's nimmer? Gaynau.
Ist quasi ein Voodoo 1-Emulator :D

Demirug hat aber auch Recht, es ist nicht zwingend die Hardware, die das unterstützen muß, es geht auch per Treiber. Nur ist das dann in den Fällen in denen es benutzt wird wirklich furchtbar lahm. Direkter HW-Support für das 'alte' Format ist auf jeden Fall zu bevorzugen.

Bsp:
Du hast einen 640x480er Z-Buffer, die Applikation will auf diesen zugreifen. Du liest also den kompletten Z-Buffer erstmal ins System-RAM aus (gähn ...), konvertierst ihn in das erwartete Format (gähn!) und lässt dann die App daran herumspielen.
Wird der Lock beendet, kovertierst du zurück, und schreibst den kompletten Speicherbereich wieder in den (HW-)Z-Buffer.

Das tückische ist, du kannst aufgrund der Eigenheiten von System-RAM nicht mit letzter Sicherheit wissen, wohin die Applikation eigentlich geschrieben hat. Kann sein, daß nur ein einziger Z-Wert angefaßt wurde, das kann der Treiber aber nicht herausbekommen.
Das 'Markieren' des Z-Buffers mit speziellen Füll-Werten ist nicht generell anwendbar, denn die App kann grundsätzlich alles dorthinein schreiben - eben auch den ultra-speziellen Füllwert. Später kann das nicht mehr unterschieden werden.

Um das ganze sicher zu machen, muß man wirklich immer komplette Puffer durch die Gegend drücken. Kotz-langsam, das.

[Demirug]

Original geschrieben von zeckensack
Gaynau.
Ist quasi ein Voodoo 1-Emulator :D

Demirug hat aber auch Recht, es ist nicht zwingend die Hardware, die das unterstützen muß, es geht auch per Treiber. Nur ist das dann in den Fällen in denen es benutzt wird wirklich furchtbar lahm. Direkter HW-Support für das 'alte' Format ist auf jeden Fall zu bevorzugen.

<Bsp: Snip>


Du weist aber schon das man dem Treiber da etwas helfen kann indem man im beim Lock sagt was man eigentlich will? Aber wie gesagt ist das Format ja primär nur aus Kompatibilitätgründen drin weil es früher mal so üblich war das man direkt in den Buffer rumgefummelt hat. Und wer das heute noch ohen driftigen Grund nutzt gehört eigentlich geschlagen.

[zeckensack]

Original geschrieben von Demirug
Du weist aber schon das man dem Treiber da etwas helfen kann indem man im beim Lock sagt was man eigentlich will? Aber wie gesagt ist das Format ja primär nur aus Kompatibilitätgründen drin weil es früher mal so üblich war das man direkt in den Buffer rumgefummelt hat. Und wer das heute noch ohen driftigen Grund nutzt gehört eigentlich geschlagen. Ich kenne die diesbezüglichen Möglichkeiten von DX nicht. Glide kann entweder READ_ONLY (duh!) oder WRITE_ONLY (duh!!).
Ersteres ist sowieso igitt, letzteres wie angesprochen nicht wirklich performant und sauber lösbar. Schummeln und hoffen daß es trotzdem gut geht kann man immer, aber das sollte nicht das Ziel sein.

Und ja, watschen sollte man die Leute die sowas benutzen. Ich würde aber gerne auch mal mit den entsprechenden API-Designern ein paar Minuten verbringen :naughty:

[Demirug]

Original geschrieben von zeckensack
Ich kenne die diesbezüglichen Möglichkeiten von DX nicht. Glide kann entweder READ_ONLY (duh!) oder WRITE_ONLY (duh!!).
Ersteres ist sowieso igitt, letzteres wie angesprochen nicht wirklich performant und sauber lösbar. Schummeln und hoffen daß es trotzdem gut geht kann man immer, aber das sollte nicht das Ziel sein.

Ja das Festlegen des Datenflussrichtung ist möglich. Zusätzlich kann man das ganze noch auf einzelne Rechtecke begrenzen.

Und ja, watschen sollte man die Leute die sowas benutzen. Ich würde aber gerne auch mal mit den entsprechenden API-Designern ein paar Minuten verbringen :naughty:

Du sagtest ja schon das Glide das auch hatte und MS musste DX ja so bauen das es von Entwicklern die vorher Glide benutzt haben auch angenommen wird.

[Razor]

Original geschrieben von Demirug
Sehr Interresant.

1. Der R300 "bescheist" bei diesem Benchmark indem er nicht genau die Shader ausführt die übergeben werden. Ist aber völlig in Ordnung weil da Blind Anweisungen herausoptimiert werden.

Beweis:


ps_2_0

dcl v0
dcl v1
def c0 , 0.300000, 0.700000, 0.200000, 0.400000

add r0 , c0 , v1
add r0 , r0 , -v0
mov oC0 , r0


3 Anweisungen keine Parralleausführung möglich. Der R350 schafft hier 1490,28 MP was 4470,84 MSI/s entspricht. Es sind 8 Instruktionen pro Takt möglich. Der R350 müsste also mit 558,855 MHz gelaufen sein. Wird dagegen die letzte mov Anweisung entfernt kommen wir nur noch auf 2980,56 MSI/s was 372,57 MHz entspricht. Ein bischen verschnitt und wir sind bei 380.

Bei den anderen Shader sieht es ähnlich aus.

2. Beim NV35 hat sich nv wirklich eine Falle eingebaut welche 1.X Shader bremst. Ob sie da noch eine Lösung finden?

3. Das "Per Pixel Light" Ergebniss des R300 scheint doch zu gering. Wir haben 8*380 MSI/s = 3040 MSI/s. Der Test erreicht 111,58 MPixel was einer benötigen rechneleistung von 27,25 Anweisungen pro Pixel entspricht. Der Shader hat aber nur 21 Anweisungen (2 davon tex). Entweder braucht die die pow Anweisung unverhältnissmässig lang oder die beiden Quer eingestreuten Tex-Anweisungen verwiren den eingebauten Optimizer so das er einen Mehrphasen Shader daraus baut was eigentlich gar nicht notwendig sein sollte.

EDIT: PS: Die NV35 PS 2.0 ergebnisse sehen irgendwie so aus als würde das Teil in einem NV30 Modus laufen
Thx again, Demirug !
Das ist doch mal wirklich aufschlußreich...

Bliebe eigentlich doch nur noch die Frage:

"WTF mißt diese Applikation eigentlich ?"
???
Ich bin ja mal echt auf die Deto50 gespannt, wenn diese tatsächlich eine Art Recompiler enthalten und ob dieser dann auch in der Lage ist, selbst solch vermurkste Anweisungen zu 'optimieren'.

Razor

[Demirug]

Original geschrieben von Razor
Bliebe eigentlich doch nur noch die Frage:

"WTF mißt diese Applikation eigentlich ?"
???
Razor

Die Fillrate unter Verwendung unterschiedlicher Shader.

[Ailuros]

Also ich hab mal das Ding auf 350MHz uebertaktet, weiter wollte ich bei der Hitze Sachen nicht riskieren; im Grunde nur um Drumdub's Resultate bis zu einem Punkt nachzuvollziehen.

Komisch ist bei dem Test aber dass alle Fuellraten bei etwa gleichem Niveau nach oben skalieren ausser der puren Fuellrate. Bei Drumbub und extra 100MHz Taktrate, sind es nur magere +12.7%.

[Demirug]

Original geschrieben von Ailuros
Also ich hab mal das Ding auf 350MHz uebertaktet, weiter wollte ich bei der Hitze Sachen nicht riskieren; im Grunde nur um Drumdub's Resultate bis zu einem Punkt nachzuvollziehen.

Komisch ist bei dem Test aber dass alle Fuellraten bei etwa gleichem Niveau nach oben skalieren ausser der puren Fuellrate. Bei Drumbub und extra 100MHz Taktrate, sind es nur magere +12.7%.

Nein, es ist eigentlich verständlich. Der pure Fillrate-test wird sehr schnell durch das Memoryinterface ausgebremst.

[Razor]

Original geschrieben von Demirug
Nein, es ist eigentlich verständlich. Der pure Fillrate-test wird sehr schnell durch das Memoryinterface ausgebremst.
Das der GPU oder das der CPU ?
???

Razor

[Demirug]

Original geschrieben von Razor
Das der GPU oder das der CPU ?
???

Razor

GPU natürlich. Ich meinte einfach die Bandbreite.

[Ailuros]

*schaut sich um*

Apropos NV40: glaubt immer noch jemand an den 300M Transistoren-Scwachsinn?

[aths]

Original geschrieben von Ailuros
*schaut sich um*

Apropos NV40: glaubt immer noch jemand an den 300M Transistoren-Scwachsinn? Sowas habe ich nie geglaubt :)

[strickjackenscheitel]

was spricht gegen multichip? die entwicklungskosten sollen ja auch reduziert werden, was auch auf eine multichipvariante hindeuted.

okok ich hoffe immernoch auf sowas. das mit der kartengroesse kann man sicher unter kontrolle bringen, mit neuen, weniger platzaufwendigen speichern und leistungsfaehigeren kondis usw.

[ShadowXX]

@strickjackenscheitel

soweit ich weiss ist Multichip teurer als Single-Chip-Lösungen.

[Ailuros]

was spricht gegen multichip? die entwicklungskosten sollen ja auch reduziert werden, was auch auf eine multichipvariante hindeuted.

Entwicklungskosten hin und her (egal welche Loesung), es wird auf jeden Fall NIE billiger sein als heutige normale single chip Loesungen. High end Karten kosten meistens ~400$ und das ist schon hoch genug.

Wie dem auch sei, wer sagt Dir dass fuer heutige Verhaeltnisse mehr oder weniger 150M nicht genug sind?

[Ailuros]

Original geschrieben von ShadowXX
@strickjackenscheitel

soweit ich weiss ist Multichip teurer als Single-Chip-Lösungen.

Ich bin mal davon ausgegangen, dass er vielleicht multichip auf dem selben die meinen koennte oder was aehnliches. Aber ich kann mir trotzdem nicht vorstellen wieso es dann trotzdem noch billiger sein soll.

Multichip Loesungen so wie wir sie heute kennen, kosten doppelt so viel.

[Quasar]

Original geschrieben von Ailuros
*schaut sich um*

Apropos NV40: glaubt immer noch jemand an den 300M Transistoren-Scwachsinn?

*meld*
Hier, ich!

Aber nur, wenn man den RAM und sonstige ICs auf der Karte hinzurechnet ;-)

[Ailuros]

Ich denke es war offensichtlich, dass ich nur den core meinte

[micki]

Original geschrieben von Demirug
Aber wer zu Hölle benutzt "D16_LOCKABLE" ausser als letzte Rettung oder wenn man wirklich einen auslesbaren Z-Buffer braucht?

jemand der für sein lensflare einen einzigen pixel aus dem buffer braucht :D

(z.b. die Unreal 1 engine)

Mfg
micki

[strickjackenscheitel]

nun es ist so:

ein chip wird entwickelt:"ui das bauen wir noch rein, kostet 20mill usd".

oder:"ui das lassen wir weg, sondern bauen lieber fuer das geld was wir in die entwicklung gesteckt haetten, eine multichiplsg. wir rechnen dafuer eben einfach mgl. ein paar mill weniger ein, als gleich xxmill in einen neuen und immer wieder neuen chip zu stecken".

das ding ist, dass es doch klueger waere, einfach ab und an einen weiteren chip draufzuloeten, als gleich wieder und wieder "neue" chips zu entwickeln.

das macht doch sinn, richtig?!

[Demirug]

Original geschrieben von strickjackenscheitel
nun es ist so:

ein chip wird entwickelt:"ui das bauen wir noch rein, kostet 20mill usd".

oder:"ui das lassen wir weg, sondern bauen lieber fuer das geld was wir in die entwicklung gesteckt haetten, eine multichiplsg. wir rechnen dafuer eben einfach mgl. ein paar mill weniger ein, als gleich xxmill in einen neuen und immer wieder neuen chip zu stecken".

das ding ist, dass es doch klueger waere, einfach ab und an einen weiteren chip draufzuloeten, als gleich wieder und wieder "neue" chips zu entwickeln.

das macht doch sinn, richtig?!

Refreshs sind relative einfach zu machen also warum mit der Entwicklung von Multichiplösungen aufhalten? Und die Mios für eine neue Generation fallen ja sowieso an weil man ja nicht nur Leistungsmässig weiterentwickelt sondern auch Featuremässig.

[strickjackenscheitel]

nun wie viel kosten denn diese features, gemessen an multichiplsg? schnurz, ich hab ja keine ahnung. nein ich denke mittlerweile auch nicht mehr recht daran, dass 300mill transitoren den nv 40 ergeben werden, obwohl ja technisch mehr moeglich ist als man manchmal glauben moechte(siehe r350 mit 0,15nm und 1x0 transistoren)

[Aquaschaf]

Original geschrieben von strickjackenscheitel
nun es ist so:

ein chip wird entwickelt:"ui das bauen wir noch rein, kostet 20mill usd".

oder:"ui das lassen wir weg, sondern bauen lieber fuer das geld was wir in die entwicklung gesteckt haetten, eine multichiplsg. wir rechnen dafuer eben einfach mgl. ein paar mill weniger ein, als gleich xxmill in einen neuen und immer wieder neuen chip zu stecken".

das ding ist, dass es doch klueger waere, einfach ab und an einen weiteren chip draufzuloeten, als gleich wieder und wieder "neue" chips zu entwickeln.

das macht doch sinn, richtig?!

so einfach ist das aber nicht, afais muss der Chip erst einmal an sich überhaupt multichipfähig sein.
Abgesehen davon steigen die Kosten pro Karte ziemlich, das Boardlayout wird weitaus komplizierter... außerdem käme man dann sicher schon auf Karten mit >150Watt Leistungsaufnahme, ganz abgesehen davon dass die in einen gewöhnlichen Tower nicht mehr reinpassen würden.

[strickjackenscheitel]

nun 2 5800-chips auf einem board, die mit einer kleinen und leisen fx-flow-variante die warme luft nach aussen blasen ... allerdings hab ich keine ahnung ueber den aufbau eines multichipgrafikboards ... von daher hast du wahrscheinlich recht ...
nun quantum3d macht auch "nonmultichips zu multichips. das unternehmen gehoert ja auch zu nv ...

[Demirug]

Original geschrieben von strickjackenscheitel
nun quantum3d macht auch "nonmultichips zu multichips. das unternehmen gehoert ja auch zu nv ...

Hast du dir aber schonmal angeschaut was die da machen? Für den normalen anwedner ist das uninteresant da es dabei vorallem um massive SSAA Leistung geht

[Ailuros]

Original geschrieben von strickjackenscheitel
nun es ist so:

ein chip wird entwickelt:"ui das bauen wir noch rein, kostet 20mill usd".

oder:"ui das lassen wir weg, sondern bauen lieber fuer das geld was wir in die entwicklung gesteckt haetten, eine multichiplsg. wir rechnen dafuer eben einfach mgl. ein paar mill weniger ein, als gleich xxmill in einen neuen und immer wieder neuen chip zu stecken".

das ding ist, dass es doch klueger waere, einfach ab und an einen weiteren chip draufzuloeten, als gleich wieder und wieder "neue" chips zu entwickeln.

das macht doch sinn, richtig?!

Uhmmm ich versuch es mal anders: IHVs versuchen alles mitzuberechnen wenn ein neuer chip designt wird und dabei spielen Herstellungskosten und finaler Preis auch eine grosse Rolle. Auf jeden Fall wird versucht dass das Resultat nicht die 400$ (oder zumindest nicht um viel mehr) uebertroffen werden als finaler Strassenpreis.

Meistens ist es so dass Transistoren-anzahl fuer Features balanciert werden; heutzutage brauchen dx9.0 Shader-Anweisungen enormen Hardwaren-Platz da kann es sein dass andere Features dafuer sogar leicht reduziert werden (auf jeden Fall nicht weniger als die Konkurrenz wenn man wirklich konkurrieren will).

nun wie viel kosten denn diese features, gemessen an multichiplsg? schnurz, ich hab ja keine ahnung. nein ich denke mittlerweile auch nicht mehr recht daran, dass 300mill transitoren den nv 40 ergeben werden, obwohl ja technisch mehr moeglich ist als man manchmal glauben moechte(siehe r350 mit 0,15nm und 1x0 transistoren)

Multichip-Loesungen wie Du sie meinst verdoppeln Leistung nicht unter allen Situationen wenn ueberhaupt. Man braucht trotz allem fuer jeden chip eine bestimmte Anzahl von Speicher, was die Unkosten ergo finalen Preis nochmal nach oben pumpt, dann kommen die Unkosten um einen bridge-chip zu entwickeln und die chips muessen auch 100% auf multichip ausgelegt sein, sonst ist es Bloedsinn es auch zu versuchen.

Ein grosses Problem des SLI der V5 Linie war dass das triangle-setup zwischen den chips nicht geteilt wurde, also musste jeder chip jedes Dreieck neu berechnen. Deshalb waren die Leistungs-Unterschiede nur mit FSAA doppelt so hoch zwischen V4-->V5 5500-->V5 6000. Natuerlich kann man das ueberwaeltigen, aber warum extra Entwicklungskosten in etwas verschwenden das trotzdem doppelt so teuer sein wird und nicht da einsetzen wo es auch mehr bringt.

nun 2 5800-chips auf einem board, die mit einer kleinen und leisen fx-flow-variante die warme luft nach aussen blasen ... allerdings hab ich keine ahnung ueber den aufbau eines multichipgrafikboards ... von daher hast du wahrscheinlich recht ...
nun quantum3d macht auch "nonmultichips zu multichips. das unternehmen gehoert ja auch zu nv ...

Ein billiges Quantum3D System fuer professionelle Simulatoren hat einen Anfangspreis von ca 10000$; high end Systeme koennen sogar in die >50000$ Region kommen. Quantum3D ist uebrigens eine eigenstaendige Firma, hatte frueher einen exclusiven Vertrag mit 3dfx und heutzutage mit NVIDIA. Quantum3D benutzt uebrigens keine multi-chip Loesungen heutzutage fuer ihre Systeme, sondern multi-board Systeme (mehrere FX-en in einer Box) AFAIK.

Und was bekommst Du von 2-5800 chips auf einem board?

a) 512 PS2.0 extended Anweisungen (pro chip) die alle durchlaufen muessen gegen >512 (bis zu 32768) Anweisungen bei PS3.0 (im NV40), wo man hunderte von Anweisungen benutzen kann und in Realitaet nur ein Bruchteil gerendert wird.

b) Doppelt so viele AA-samples im Vergleich zu einer 5800, ergo 8xOGMS auf dual chip NV30, mit der gleichen Leistung einer NV30 mit 4xOGMS. Wie sieht es dann mit einer Moeglichkeit eines neuen Algorithmus und einem effizienteren Aufbau der AA-pipelines bei NV40 aus. Ein besseren grid und auch mehr Leistung als dual chip NV30.

Theoretisch:
8xOGMS (dual chip NV30) = 4*2 oder 2*4 grid
8xRGMS (single chip NV40) = 8*8 grid

(Warnung: die Zahlen sind rein theoretisch die fuer's Beispiel dienen). Selbst im Falle wo die Leistung zwischen den beiden Methoden gleich sein sollte, ist die Effektivitaet der zweiten um einige Male hoeher.

Reicht das bis jetzt? Solange die Effizienz jeglicher Karte durch bessere und klevere Architekturs-Auslegungen und besseren Algorithmen erhoeht werden kann, macht multichip wenig Sinn. Wenn es mal so weit kommt dass chips mehr Transistoren brauchen als ein Herstellungs-Prozess aufnehmen kann, koennte man eventuell einen multichip entwickeln der aber auf dem gleichem die kommt, wie z.B. einen integriertern aber "selbststaendigen" Geometrie-chip.

***edit:

uebrigens bei den Forecasts fuer R&D bei IHVs, wird eine gesamte Generation vorberechnet. Der Forecast fuer die gesamte NV3x Linie sollte ja ungefaehr bei 400M$ liegen, aber da wurden NV30, NV31, NV34, NV35, NV36, NV34se (wenn nicht auch noch moegliche NV38) mitberechnet. Multi chip sehe ich nur als sehr teure "Notloesung"
wenn man die absolute Leistungs-Krone behalten will (egal mit welchem finalem Preis) und man der Konkurrenz mit single chip Loesungen nicht mehr folgen kann.

[strickjackenscheitel]

oh! danke erstmal fuer die detaillierte ausfuehrung gegen multichip! ich haette nie gedacht, dass das so extrem sei mit dem kosten-leistungverhaeltnisses! danke!

[Ailuros]

Keine Ursache. Ist ja auch alles nur so wie ich es verstanden habe bis jetzt. Im Grunde geht es meistens bei multichip Loesungen bis heute (ob mainstream/desktop oder professioneller Simulatoren Markt) um mehr FSAA samples zu gewinnen ergo sehr hohe AA Qualitaet mit etwa gleicher Leistung.

Theoretisch koennte ein IHV heute z.B. auch einen nur halbwegs entry level dx9.0 Accelerator bauen, trotzdem aber sehr hohe Transistoren-Anzahl haben und eine grosse Mehrheit davon fuer AA-Einheiten und fortschrittliche sampling grids aufopfern. Der Grund weil es keiner wohl machen wird, ist dass man leider den letzten Schrei was DX Komplianz betrifft haben muss, um besser zu konkurrieren. Wuerde z.B. FAA auf Parhelia problemlos laufen und Matrox haette einen schnellen aber effizienten adaptiven Aniso-Algorithmus dahinzugefuegt, waere Parhelia ein mehr oder weniger gutes Beispiel eines solchen chips (naja ein paar fortschrittliche Bandbreiten-schonende Techniken haette ich auch gern auf dem gesehen und eine texture loopback funktion etc.).

[strickjackenscheitel]

obwohl ich davon mittlerweile abgekommen bin das es 300mill transistoren und eine multichiplsg werden wird, waere besseres, bzw. leistungsfaehigeses aa doch bei nv durchaus ein grund FUER eine multichiplsg., richtig? oder koennte das mit dem naechsten chip genauso gut, bzw. noch besser geloest werden als mit den naechsten chipS?

mal abgesehen davon. gibt es ueberhaupt mal wieder ein paar neue geruechte, oder gar wahrscheinliche infos zum nv 40? nur um mal von meinen wunschtraeumen abzulenken. =)

[Ailuros]

AA Methode und Leistung haengt soweit ich weiss von der Anzahl der entsprechenden Einheiten ab und wie diese mit dem der Pipeline(-s) co-operieren.

Normalerweise soll es heissen dass man wohl mehr Transistoren verbraucht bei einem 8xRGMS Verfahren im Vergleich zu einem 16xOGMS Verfahren. Der Vorteil von 8xRGMS ist dass man damit einen 8*8 grid schaffen kann, waehrend 16xOGMS nur einen 4*4 grid erreicht. Dazu spart auch 8xRGMS auch mehr Bandbreite, da es sich nur um die haelfte der samples handelt.

Kleinigkeiten zu dem AA Algorithmus bei NV40 weiss ich nicht, aber ich bin mir fast sicher dass die Transistoren-Anzahl nicht auf die 300Mille gestiegen ist, sondern eher die haelfte dieser wenn nicht ein bisschen mehr.

Wir sind ja im Spekulationsforum also ist es auch erlaubt zu spekulieren: ATI hat es im R3xx bis zu 6xRGMS geschafft und ich gehe davon aus dass sich NV bis zu dem Punkt gleichsetzen wird. Ob jetzt ATI den Pegel hoeher gesetzt hat im R420 mit der Anzahl von AA samples hab ich keine Ahnung. Idealfall fuer NV waere natuerlich 8xRGMS.

Uebrigens so viel hat NV nun auch wieder nicht geaendert zwischen NV25 und NV3x was den AA-Algorithmus betrifft; alle neuen modi laufen ja auch auf NV2x. Das einzige worueber ich mir sicher bin dass geaendert wurde zwischen NV25 und NV3x ist dass der filter on scanout trick von 2xAA/Quincunx auf NV25 nach 4xOGMS bei NV3x erweitert wurde, was so manche Bandbreite sparen kann.

obwohl ich davon mittlerweile abgekommen bin das es 300mill transistoren und eine multichiplsg werden wird, waere besseres, bzw. leistungsfaehigeses aa doch bei nv durchaus ein grund FUER eine multichiplsg., richtig? oder koennte das mit dem naechsten chip genauso gut, bzw. noch besser geloest werden als mit den naechsten chipS?

Nein zur ersten Frage wenn Du zwei NV3x auf einem board meinen solltest und ja zur zweiten Frage.

[zeckensack]

scheitel,
Ein weiterer Faktor sind natürlich die Kosten für's PCB und das Drumherum, wo man mit zwei Chips zwangsläufig mehr Platz, mehr Leiterbahnen (mehr Layer?) und mehr(ere) Kühler braucht.
Auch nicht zu verachten ist, daß bestimmte Teile der Chips immer doppelt vorhanden sein, und daher auch doppelt mit Energie versorgt werden müssen. Daß die Energie-Versorgung von High-End-Schleudern so langsam richtig kompliziert und teuer wird, sieht man ganz gut an FX5900Ultra (besonders schick ist der Vergleich zur FX5900 'normal').

[TheCounter]

*push*

Neue Specs von Uttar:

- Supports FP32, FP16 and FX16 natively. Whether there is any performance difference between FP16 and FX16 is unknown, and whether there are any truly non-FP32 units is also unknown.
- 175M transistors, 600Mhz core clock, 1.5Ghz effective GDDR2 ( Samples already shipped to nV - 16 memory chips per board )
- Not taped-out yet, or if it did, tape-out failed. To tape-out sometime this month.
- 8 pipelines, Speculation: probably 8x2 and no 16 zixel trick ( not worth it with 4x+ AA, which is really a minimum with 48GB/s of bandwidth ) - Maybe such a bypass path for low-end models ( NV42/NV43 )

This means Christmas avaibility has IMO become absolutely out of the question. Best we can hope is for-developer documents for Comdex, or around then. And that's not a certainty.
Finally, Det50s probably are for the 15th, but I doubt that will mean public download - more like previews for AquaMark 3. That's the best case scenario - it might also be launched with the NV36 at Computex ( September 22-26 )

Hört sich garnichtmal so schlecht an, ma gucken was draus wird..

[Ailuros]

So und jetzt wird's so langsam Zeit den Ueberoptimisten hier dass hier nochmal unter die Nase zu reiben:

Not taped-out yet, or if it did, tape-out failed. To tape-out sometime this month.


Und wenn ich schon Grund habe sollte mir sorgen zu machen ist dass hier genug:

175M transistors, 600Mhz core clock, 1.5Ghz effective GDDR2 ( Samples already shipped to nV - 16 memory chips per board )

Das von vorigen 152M, sign off speed at 500MHz, heisst wohl dass wieder nach oben geschraubt wurde durch den Prozess, was wohl mal wieder eine Anzeige sein koennte, dass man schon wieder die Konkurrenz unterschaetzt hat.

Falls er 600MHz sign off speed meinen sollte, muesste das Resultat mit einem Kuehlschrank geliefert werden.


Hört sich garnichtmal so schlecht an, ma gucken was draus wird..

Counter,

Das ganze stinkt genauso wie NV30 und NV35 und ich hoffe dass ich hier nur ein schlechtes Gefuehl habe.

Man sollte den Pipeline Krampf mal vergessen und davon ausgehen dass NV40 mit Sicherheit 2 Pixelprozessoren haben wird.

[TheCounter]

@Ailuros

Naja, es ist besser das sie es jetzt erkannt haben (Wenn sie nach dem R300 & NV30 überhaupt nochmal wagen ATI zu unterschätzen), denn jetzt kann man noch was ändern.

Nen Kühlschrank braucht man sicher nicht.

Mal gucken, FX-Flow war im Grunde nicht schlecht, nur die Umsetzung war ne "Katastrophe".

Also lassen wir uns mal überraschen was kommt ;)

[Ailuros]

Das ganze ist viel zu optimistisch dargestellt und der Punkt mit dem Kuehlschrank bleibt, da ich klar sign off speeds meinte.

Sign off mit den oben erwaehnten Transistoren ist real zwischen 450-500MHz, was natuerlich nach einem erfolgreichen tape-out Platz fuer hoehere Taktraten laesst (bei 500 sign off, sind 550 oder 600MHz durchaus moeglich).

Da aber bis jetzt noch kein erfolgreicher tape-out bestaetigt wird, kann es sich nur um 600MHz sign off halten, was IMHO verrueckt ist. Ausser man glaubt oder hofft dass NV40 mit 700MHz core ankommen wird.

Bleiben wir mal dabei dass momentan Taktrate immer noch hochspekulativ ist.

***edit:

Naja, es ist besser das sie es jetzt erkannt haben (Wenn sie nach dem R300 & NV30 überhaupt nochmal wagen ATI zu unterschätzen), denn jetzt kann man noch was ändern.

Mitte Sommer 2002, ~105M@400MHz auf 120M@500MHz. Hoert sich das bekannt an?

[StefanV]

Original geschrieben von TheCounter
@Ailuros

Naja, es ist besser das sie es jetzt erkannt haben (Wenn sie nach dem R300 & NV30 überhaupt nochmal wagen ATI zu unterschätzen), denn jetzt kann man noch was ändern.

Nen Kühlschrank braucht man sicher nicht.

Mal gucken, FX-Flow war im Grunde nicht schlecht, nur die Umsetzung war ne "Katastrophe".

Also lassen wir uns mal überraschen was kommt ;)

1. FALSCH!!
Wenn sie JETZT erkannt haben, daß der NV40 zu lahm ist, dann ist das Kind schon im Brunnen ersoffen!!
Ein HW Design dauert länger, als du denkst...
Du kannst ungefähr von 1-2 Jahren für ein neues Design ausgehen, davon ausgehen, wäre es jetzt schon VIEL zu spät!!...

2. och, das passt scho...
Wenn nV für die NV30 schon 'ne Turbine brauchte...
Wobei ATI schon immer an allen Ecken und Kanten gespart hat, was man besonders gut im Vergleich zu G400/TNT2 und Voodoo3 zur Rage128 PRO sieht...
Bis auf dem ATI Chip dürften wohl alle ohne Kühler recht schnell abfackeln, nur der Rage128 benötikt nicht wirklich eine Kühlung...
Dafür hat das Teil laut Zeckes Archmark nichtmal Bi TMUs...

3. nein, FX Flow war Müll...
Das Teil hat einfach zu wenig oberfläche und auch der Radialfan is Mies.
Dazu noch der sehr lange Weg, den die Luft zurücklegen muss...

4. nunja, ich fürchte, daß Ailuros durchaus recht haben könnte...

[Ailuros]

Vorsicht Stefan; wenn es zu Spekulationen von ATI's Seite bekommt, sehen die Spezifikationen noch exotischer aus, ausser natuerlich der Taktrate.

Mein Punkt war eher dass man nicht jede spekulierte Verruecktheit einfach so leichthaendig glauben sollte.

R420= ~200M Transistoren, 12*1/6*2, PS/VS3.0, Abart von PPP, 13nm@450MHz (momentan).

Mir erscheint das auch zuviel und zu sehr am Rand. Wenn ATI sich in den Fuss schiessen will koennen sie leicht solche Risikos eingehen, Erfolg ist aber nicht garantiert.

[TheCounter]

Original geschrieben von Stefan Payne
1. FALSCH!!
Wenn sie JETZT erkannt haben, daß der NV40 zu lahm ist, dann ist das Kind schon im Brunnen ersoffen!!
Ein HW Design dauert länger, als du denkst...
Du kannst ungefähr von 1-2 Jahren für ein neues Design ausgehen, davon ausgehen, wäre es jetzt schon VIEL zu spät!!...


Vielleicht wissen sie das aus ner Internen Quelle bei ATI schon mehr über den R420 und wissen das ATI diesemal NVIDIA unterschätz hat, was ich dann machen würde währe aus meinem Chip noch mehr rauszuholen das der "Schlag" am Schluss viel kräftiger wird...

Alles ist möglich...

[Ailuros]

Original geschrieben von TheCounter
Vielleicht wissen sie das aus ner Internen Quelle bei ATI schon mehr über den R420 und wissen das ATI diesemal NVIDIA unterschätz hat, was ich dann machen würde währe aus meinem Chip noch mehr rauszuholen das der "Schlag" am Schluss viel kräftiger wird...

Alles ist möglich...

Hehehe Orton hat Huang nie unterschaetzt; er weiss genau dass er staendig Kampfsbereit und fuer Recherchen aufgelegt ist. Das natuerlich traegt sich auf die Politik der Firmen weiter.

Und wenn Du glaubst dass Uttar gut spekulieren kann, waren die Spezis in meinem vorigen Post von Mufu. Ich bin momentan immer noch vorsichtig mit dem Zeug. Wenn Du fragst wie beide schon Taktraten oder um genauer zu sein sign off speeds einschaetzen koennen, sind Simulatoren dazu da ;)

[Demirug]

Original geschrieben von Ailuros
Hehehe Orton hat Huang nie unterschaetzt; er weiss genau dass er staendig Kampfsbereit und fuer Recherchen aufgelegt ist. Das natuerlich traegt sich auf die Politik der Firmen weiter.

Und wenn Du glaubst dass Uttar gut spekulieren kann, waren die Spezis in meinem vorigen Post von Mufu. Ich bin momentan immer noch vorsichtig mit dem Zeug. Wenn Du fragst wie beide schon Taktraten oder um genauer zu sein sign off speeds einschaetzen koennen, sind Simulatoren dazu da ;)

Nur wenn der Simulator falsche Daten über den Prozess hat gibt es eben GIGO.

[Ailuros]

GIGO?

Also ich fang mal von Anfang an und Du kannst mir leicht sagen wo ich was falsch verstanden habe.

Sign-off speeds sind effektiv was HW sims anzeigen wie hoch man gehen kann basierend auf Modelle. Diese Modelle haben mehrere error bands (fabs geben ja Transistoren Modelle dem IHV mit dem safety margin, die SW hat safety margins, der IHV hat safety margins; alles um sicher zu sein dass das Ganze auch laufen wird). Durch all die safety margins kann es sein dass die finale Taktrate hoeher ist als der sign-off speed.

Bei so vielen Sicherheits-massnahmen sieht es schwer aus das etwas falsch gehen koennte, ausser man ueberschreitet die Margen des Fabs.

Wo haperts hier und was zum Henker ist GIGO? :D

[StefanV]

Original geschrieben von TheCounter
Vielleicht wissen sie das aus ner Internen Quelle bei ATI schon mehr über den R420 und wissen das ATI diesemal NVIDIA unterschätz hat, was ich dann machen würde währe aus meinem Chip noch mehr rauszuholen das der "Schlag" am Schluss viel kräftiger wird...

Alles ist möglich...

1. dazu muss es erstmal Spezis geben und weitere Daten.
Sowas kann es eigentlich nur dann geben, wenn die Entwicklung schon weiter fortgeschritten ist -> viel zu spät für NV!!

2. ATI nV unterschätzen??
NIEMALS!!
ATI ist Numbero2, die habens einfacher oben zu bleiben als nV!!
Siehs mal andersrum: ATI hat nicht wirklich was zu verlieren, nV schon.
Außerdem MUSS ATI keinen alten Müll mitschleppen (z.B. die Reg Combiner usw.)
Außerdem solltest du nicht vergessen, daß nV die letzen Jahre ein wenig gepennt hat, während ATI ein Brikett nach dem anderen nachgelegt hat (Technologisch)...

3. wenn man zuviel möchte, dann kanns auch gewaltig nach hinten losgehen...
Das allerbeste Beispiel dürfte der Rampage sein, bei welchem 3DFX die Deadline für neue Features zu oft und zu weit nach hinten geschoben haben...
Wenn man etwas hat, dann muss man sich mit dem Schrott zufrieden geben, das beste draus machen und sich aufs nächste Projekt konzentrieren, so wie ATI das seit der Radeon gemacht hat...
Wobei ATI die Messlatte mit jeder Generation höher und höher gelegt haben...
Die Radeon >7200 ist z.B. auch ziemlich in der Lage PS1.0 auszuführen, solange das Programm nicht mehr als 3 Texturen nutzt, klappt das auch ganz gut...


@Ailuros

Sehen wir es mal andersrum:

Was wissen wir über den R420??
IMO: GARNIX.

Was wissen wir über die NV40:
Mehr als über die R420.

[Demirug]

Original geschrieben von Ailuros
GIGO?

Also ich fang mal von Anfang an und Du kannst mir leicht sagen wo ich was falsch verstanden habe.

Sign-off speeds sind effektiv was HW sims anzeigen wie hoch man gehen kann basierend auf Modelle. Diese Modelle haben mehrere error bands (fabs geben ja Transistoren Modelle dem IHV mit dem safety margin, die SW hat safety margins, der IHV hat safety margins; alles um sicher zu sein dass das Ganze auch laufen wird). Durch all die safety margins kann es sein dass die finale Taktrate hoeher ist als der sign-off speed.

Bei so vielen Sicherheits-massnahmen sieht es schwer aus das etwas falsch gehen koennte, ausser man ueberschreitet die Margen des Fabs.

Wo haperts hier und was zum Henker ist GIGO? :D

Ich habe dir doch schon recht gegeben. Nur wenn die FAB den IHVs ein zu optimistisches Model für das Chip-Design-Tool gibt dann gibt es eben GIGO (http://www.wikipedia.org/wiki/GIGO).

Um die Sign-off Speed zu berechnen braucht man übrigens keinen Simulator. Das Chip Design-Tool sucht einfach die sogenanten "kritischen Pfade" und berechnet wie lange das Signal braucht um diesen zu durchlaufen. Für diese Rechnung werden die Daten von der Fab gebraucht. Die Taktrate ergibt sich dann aus 1/Max(Pfad laufzeiten). Beim Respin versucht man dann primär diese kritischen Pfade zu verkürzen. wobei es hierbei weniger um die länge als die Anzahl der Transitoren im Pfad geht.

[Demirug]

Original geschrieben von Stefan Payne
Die Radeon >7200 ist z.B. auch ziemlich in der Lage PS1.0 auszuführen, solange das Programm nicht mehr als 3 Texturen nutzt, klappt das auch ganz gut...

Hör bitte damit auf. Da fehlt noch mehr als nur die eine Texture. Solange man die PS nur als Multitexture Einheit missbraucht funktioniert das ja alles noch aber bei PS Programmen die mit komplexen Textureoperationen arbeiten geht da eben nichts mehr.

[Ailuros]

@Ailuros

Sehen wir es mal andersrum:

Was wissen wir über den R420??
IMO: GARNIX.

Was wissen wir über die NV40:
Mehr als über die R420.

*hust* ich weiss genauso viel ueber beide :bäh:

Demi,

Ich habe dir doch schon recht gegeben. Nur wenn die FAB den IHVs ein zu optimistisches Model für das Chip-Design-Tool gibt dann gibt es eben GIGO.

Das war ein gemeiner Entwickler-Trick. Ich haette an alles gedacht als Garbage-In/Garbage-Out grrrrr *kicher*

Um die Sign-off Speed zu berechnen braucht man übrigens keinen Simulator. Das Chip Design-Tool sucht einfach die sogenanten "kritischen Pfade" und berechnet wie lange das Signal braucht um diesen zu durchlaufen. Für diese Rechnung werden die Daten von der Fab gebraucht. Die Taktrate ergibt sich dann aus 1/Max(Pfad laufzeiten). Beim Respin versucht man dann primär diese kritischen Pfade zu verkürzen. wobei es hierbei weniger um die länge als die Anzahl der Transitoren im Pfad geht.

Wird zum restlichen Amateur-knowhow hinzugefuegt. Gracias :D

[MadManniMan]

A Propo Amateur-KnowHow: kann mal einer den Begriff "PPP" klären? ...bitte!

[Demirug]

Original geschrieben von MadManniMan
A Propo Amateur-KnowHow: kann mal einer den Begriff "PPP" klären? ...bitte!

http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&threadid=79771