PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : GFFX nur eine schnellere GF4 ?


Virtual
2003-03-02, 21:27:21
"the inquirer" soll man zwar grundsätzlich mit Vorbehalt genießen, aber wenn http://www.theinquirer.net/?article=8067 zutrifft, dann ist die GFFX nur eine Kombination aus beschleunigter GF4 und CineFX Einheit, die für PS2.0 zu langsam ist. Zum Zocken wirklich nutzbar scheint nur die beschleunigte GF4 in der GFFX. Ist die GFFX damit aus Zocker-Sicht streng genommen nur eine DX8-Karte, da im Vergleich mit R3xx-Karten bei FP-Verarbeitung (PS2.0) einfach zu langsam?

Andere bereits bekannte Hinweise:
GFFX-AA ist in Hardware scheinbar weitestgehend identisch zur GF4 implementiert und AF vermutlich "nur" durch einen vom "Application"-Algorithmus abgeleitetes Verfahren erweitert. Übrig bleibt einzig die Colour-Compression für weniger Last auf dem Speicher-Interface.

Weiterhin:
Mann könnte spekulieren, ohne sich dabei besonders aus dem Fenster zu lehnen, daß der NV30-Pfad bei DOOM3 bis auf die Optimierungen für die "NV30/GF4-Einheit" identisch mit dem NV25-Pfad ist?! Der Qualitätsunterschied zum ARB2, egal ob mit R300(24-Bit) oder CineFX(32-Bit), ist ohnehin nur minimal, da DOOM3 für Integer-Genauigkeit (DX8) optimiert ist. JC's Aussagen bezüglich Geschwindikeit deuten dies an.

Oder, daß sich die sagenhaften 50% mehr Performance in 3D-Mark2003 durch PS1.4 Integer-Verarbeitung anstelle von Fließkomma Genauigkeit in den Floating-Point Pipes ergeben?!

Was ist eure Meinung dazu?

G.
V.

Demirug
2003-03-02, 21:30:36
Darüber läst sich do hervoragend spekulieren ;)

*move*

Eusti
2003-03-02, 21:53:39
Originally posted by Virtual

Zum Zocken wirklich nutzbar scheint nur die beschleunigte GF4 in der GFFX. Ist die GFFX damit aus Zocker-Sicht streng genommen nur eine DX8-Karte?Aus Zockersicht sind beide Chips/Karten nur DX8, da in der Lebenszeit beider Chips/Karten keine DX9-Spiele erscheinen werden. Lediglich für die 4 folgenden Gruppen ist die DX9-Zugehörigkeit von Interesse:

1) Entwickler, welche mit der DX9-Einheit programmieren (bzw. testen)können.
2) Demo-Liebhaber, welche sich damit DX9-Demos/Präsentationen reinziehen können.
3) 3DMark2003-Benchmark-Lienhaber, die sich über jeden Punkt freuen.
4) Personen wie Nagus, Tarkin oder Radonator, die sich einfach freuen, wenn ATI besser ist.

Für den "Zocker" ist es unrelevant, ob DX8 oder DX9. Mit DX8 wurden Pixel-/Vertexshader eingeführt, welche mit DX9 verbessert wurden. Spiele-Programmierer werden sich somit auf den kleinsten gemeinsamen Nenner beziehen und das sind nunmal DX8 (mit Millionen von installierten 8500 und GF4Ti).

Bis die Spezifikationen von DX8 bei den Shadern überschritten werden, vergehen (so denke ich) noch mindestens 2 (vielleicht sogar 3) Jahre. Zu diesem Zeitpunkt wird dann aber keine heute erhältliche Karte aus Zocker-Sicht interessant sein. Bis dahin geht es "theoretisch" nur darum, einen möglichst schnellen DX8-Chip zu haben.

Demirug
2003-03-02, 22:12:54
Virtual,

jeder neue Chip hat immer teile und ideen seiner vorgänger verbaut. Das ist bei ATI auch nicht anders.

Zu deinen Vermutungen bezüglich des NV30 Renderpfads muss ich dich etwas enttäuschen. Denn gewisse behauptungen von JC decken sich damit nicht. Der NV30 Pfad schafft alle in einem Pass. Das ist mit den Register Combiner (NV2x Technologie) nicht machbar. Aus diesem Grund müssen hier die neuen FP-ALUs zum Einsatz kommen.

Etwas ähnliches ergibt sich für die PS 1.4. Die Register Combiner sind technisch nicht in der Lage PS 1.4 auszuführen. Der plötzliche Performancessprung beim 3dmark dürfte daher kommen das NVIDIA die benutzten PS genau analysiert hat und im Treibercode der optimale (von Hand optimiert) Microcode für die ALUs hinterlegt ist. Sobald der Treiber dann erkennt das dieser Shader gebraucht wird benutzt man den optimierten. Für die DX7 Pipelines sind so auch ein paar Shader hinterlegt die es schaffen einen 4 oder 5 Stages Shader mit nur 2 Register combiner auszuführen. Alles nur eine Frage der Treiberprogrammierung.

Unregistered
2003-03-02, 22:25:21
Originally posted by Demirug

Etwas ähnliches ergibt sich für die PS 1.4. Die Register Combiner sind technisch nicht in der Lage PS 1.4 auszuführen. Der plötzliche Performancessprung beim 3dmark dürfte daher kommen das NVIDIA die benutzten PS genau analysiert hat und im Treibercode der optimale (von Hand optimiert) Microcode für die ALUs hinterlegt ist. Sobald der Treiber dann erkennt das dieser Shader gebraucht wird benutzt man den optimierten. Für die DX7 Pipelines sind so auch ein paar Shader hinterlegt die es schaffen einen 4 oder 5 Stages Shader mit nur 2 Register combiner auszuführen. Alles nur eine Frage der Treiberprogrammierung.

Na wenns da mal hackt haben wir die nächste Nvidia3dMarkTreiber-Diskussion. :D

Könnte das zum Teil merkwürdige Verhalten von einigen Nvidia-Karten nach bestimmten Benchmarks auch damit zusammen hängen?

Unregistered
2003-03-02, 22:29:32
Originally posted by Demirug
Virtual,

jeder neue Chip hat immer teile und ideen seiner vorgänger verbaut. Das ist bei ATI auch nicht anders.

Zu deinen Vermutungen bezüglich des NV30 Renderpfads muss ich dich etwas enttäuschen. Denn gewisse behauptungen von JC decken sich damit nicht. Der NV30 Pfad schafft alle in einem Pass. Das ist mit den Register Combiner (NV2x Technologie) nicht machbar. Aus diesem Grund müssen hier die neuen FP-ALUs zum Einsatz kommen.

Etwas ähnliches ergibt sich für die PS 1.4. Die Register Combiner sind technisch nicht in der Lage PS 1.4 auszuführen. Der plötzliche Performancessprung beim 3dmark dürfte daher kommen das NVIDIA die benutzten PS genau analysiert hat und im Treibercode der optimale (von Hand optimiert) Microcode für die ALUs hinterlegt ist. Sobald der Treiber dann erkennt das dieser Shader gebraucht wird benutzt man den optimierten. Für die DX7 Pipelines sind so auch ein paar Shader hinterlegt die es schaffen einen 4 oder 5 Stages Shader mit nur 2 Register combiner auszuführen. Alles nur eine Frage der Treiberprogrammierung.

Was sagst du eigentlich zum R350, wirst du dir jetzt doch keine Geforce FX kaufen? Du pochst ja immer auf ein möglichst großes "Featureset", und da soll laut Newsmeldung die nicht erhältliche R350 den nicht erhältlichen NV35 schlagen.

Virtual
2003-03-02, 22:32:30
Originally posted by Eusti
Aus Zockersicht sind beide Chips/Karten nur DX8, da in der Lebenszeit beider Chips/Karten keine DX9-Spiele erscheinen werden. Lediglich für die 4 folgenden Gruppen ist die DX9-Zugehörigkeit von Interesse:

1) Entwickler, welche mit der DX9-Einheit programmieren (bzw. testen)können.
2) Demo-Liebhaber, welche sich damit DX9-Demos/Präsentationen reinziehen können.
3) 3DMark2003-Benchmark-Lienhaber, die sich über jeden Punkt freuen.
4) Personen wie Nagus, Tarkin oder Radonator, die sich einfach freuen, wenn ATI besser ist.

Für den "Zocker" ist es unrelevant, ob DX8 oder DX9. Mit DX8 wurden Pixel-/Vertexshader eingeführt, welche mit DX9 verbessert wurden. Spiele-Programmierer werden sich somit auf den kleinsten gemeinsamen Nenner beziehen und das sind nunmal DX8 (mit Millionen von installierten 8500 und GF4Ti).

Bis die Spezifikationen von DX8 bei den Shadern überschritten werden, vergehen (so denke ich) noch mindestens 2 (vielleicht sogar 3) Jahre. Zu diesem Zeitpunkt wird dann aber keine heute erhältliche Karte aus Zocker-Sicht interessant sein. Bis dahin geht es "theoretisch" nur darum, einen möglichst schnellen DX8-Chip zu haben.

Die Vergangenheit wird sich vermutlich wiederholen und die Bedeutung von DX9 in Games zur Lebenszeit der NV3x/R3xx Chips geht damit gegen 0. ->Zustimmung signalisiert für die praxisbezogene Perspektive! Aber technisch gesehen ...

Demirug
2003-03-02, 22:48:05
Originally posted by Unregistered


Na wenns da mal hackt haben wir die nächste Nvidia3dMarkTreiber-Diskussion. :D

Könnte das zum Teil merkwürdige Verhalten von einigen Nvidia-Karten nach bestimmten Benchmarks auch damit zusammen hängen?

Sicherlich. Aber ATI ist da auch nicht besser. Das man versucht auf Benchmarks/Spiele zu optimieren die gerne benutzt werden gibt man zwar offiziel nicht unbedingt zu aber gemacht wird es trotzdem. Mit etwas Glück fallen dabei ja auch ein paar Dinge ab von denen andere Spiele profitieren.

Demirug
2003-03-02, 22:56:34
Originally posted by Unregistered


Was sagst du eigentlich zum R350, wirst du dir jetzt doch keine Geforce FX kaufen? Du pochst ja immer auf ein möglichst großes "Featureset", und da soll laut Newsmeldung die nicht erhältliche R350 den nicht erhältlichen NV35 schlagen.

Das Problem das ich derzeit damit habe ist das alles was man bei the inquirer als Feature für das ++ sieht einen

"virtually unlimited" pixel shader length

ist. Da die FX aber schon an der grenze der maximalen Länge von 2.0+ Shader liegt kann ich daraus leider keinerlei nutzen ziehen. (Der FX Chip mit hat mit 1024 da sowieso schon mehr als man wirklich nutzen kann) Sollte sich allerdings herausstellen das es noch mehr Features gibt wird der Chip interesant. Ich glaube allerdings nicht wirklich daran weil der dafür notwendige umbau der Shaderpipelines für einen Refresh-Chip eigentlich zu gross ist.

Ansonsten habe auch hier schon was dazu gesagt http://www.forum-3dcenter.de/vbulletin/showthread.php?s=&threadid=58002

Und ich wäre froh wenn wir die Diskussion bezüglich des R350 und DX9++ dort führen könnten.

Unregistered
2003-03-02, 22:58:51
Originally posted by Demirug


Sicherlich. Aber ATI ist da auch nicht besser. Das man versucht auf Benchmarks/Spiele zu optimieren die gerne benutzt werden gibt man zwar offiziel nicht unbedingt zu aber gemacht wird es trotzdem. Mit etwas Glück fallen dabei ja auch ein paar Dinge ab von denen andere Spiele profitieren.


Sollte ja auch keine Schuldzuweisung sein.:eyes: Die Frage hatte mehr einen technischen Hintergrund.

nagus
2003-03-02, 23:02:09
Originally posted by Demirug


Sicherlich. Aber ATI ist da auch nicht besser. Das man versucht auf Benchmarks/Spiele zu optimieren die gerne benutzt werden gibt man zwar offiziel nicht unbedingt zu aber gemacht wird es trotzdem. Mit etwas Glück fallen dabei ja auch ein paar Dinge ab von denen andere Spiele profitieren.

der große unterschied zwischen ati und nvidia ist, dass bei ATI die leistung nicht nur beim 3dmark oder codecreature-benchnmark steigt. nvidia gibt bei seinen treiberreleases eigentlich immer nur an: "up to 50% increase" ... stimmen tut das aber wirklich nur in den seltesten fällen (nature-szene z.b. )

ati hingegen gibt IMMER genau an, welche spiele schneller geworden sind und die %-angaben ati stimmen auch meistens. z.b.: http://pdownload.mii.instacontent.net/ati/drivers/Catalyst_31_Release_Notes.html

Demirug
2003-03-02, 23:08:20
Originally posted by Unregistered



Sollte ja auch keine Schuldzuweisung sein.:eyes: Die Frage hatte mehr einen technischen Hintergrund.

Habe ich auch nicht unbedingt so verstanden ich wollte nur einen möglicherweise daraus entstehenden Flamewar etwas eindämen.

Das beste an der Geschichte mit den 5 Stages in 2 Combiner war ja noch das der Treiberentwickler der das ganze entwickelt hat davon ganz stolz den Spieleentwicklern berichtet hat. Wenn dieses 5 Stages Setup in irgendeinem Benchmark benutzt würde hätte er sicher einen Maulkorb bekommen weil sonst gleich wieder Cheat geschrien worden währe. Ich wollte damit auch nur aufzeigen das je flexibler eine Hardware wird desto mehr kann und muss man auch über die Treiber machen. Deswegen müssen plötzliche Performances sprünge auch nicht unbedingt ein Cheat sein sonder können ganz einfach darauf beruhen das einer der Treiberprogrammier eine geniale Idee hatte wie man die Möglichkeiten des Chips in einer bestimmten Rendersituation besser nutzen kann.

Virtual
2003-03-02, 23:19:52
Originally posted by Demirug
Virtual,

jeder neue Chip hat immer teile und ideen seiner vorgänger verbaut. Das ist bei ATI auch nicht anders.

Zu deinen Vermutungen bezüglich des NV30 Renderpfads muss ich dich etwas enttäuschen. Denn gewisse behauptungen von JC decken sich damit nicht. Der NV30 Pfad schafft alle in einem Pass. Das ist mit den Register Combiner (NV2x Technologie) nicht machbar. Aus diesem Grund müssen hier die neuen FP-ALUs zum Einsatz kommen.

Etwas ähnliches ergibt sich für die PS 1.4. Die Register Combiner sind technisch nicht in der Lage PS 1.4 auszuführen. Der plötzliche Performancessprung beim 3dmark dürfte daher kommen das NVIDIA die benutzten PS genau analysiert hat und im Treibercode der optimale (von Hand optimiert) Microcode für die ALUs hinterlegt ist. Sobald der Treiber dann erkennt das dieser Shader gebraucht wird benutzt man den optimierten. Für die DX7 Pipelines sind so auch ein paar Shader hinterlegt die es schaffen einen 4 oder 5 Stages Shader mit nur 2 Register combiner auszuführen. Alles nur eine Frage der Treiberprogrammierung.

Diese Form der "Treiber-Optimierung" leuchtet ein und wird garantiert bei NV und ATI zur Beschleunigung von häufig gebenchten Spielen Verwendung finden. Allerdings bezog ich mich in der Fragen auf die in "the register"-Artikel aufgeführten Hardware-Gegebenheiten, welche der FX nur 4 FloatOps/Clock zugestehen. PS1.4 läßt sich aus Integer PS1.0-1.3 kombinieren oder in der Float ALU als PS2.0 Subset ausführen. Meine Vermutung war, daß NV's erster Ansatz, PS1.4 in der Float-Teil der Pipe auszuführen, für NV nicht haltbar war, weil 3DMark2003 zu viel PS1.4 Code einsetzt. Sicher ist die Rechnung so zu einfach, jedoch sagt der Artikel aus, daß 16-Bit bzw. 32-Bit gleichermaßen schnell verarbeitet werden können, was bei 4 ALUs (NV30) gegen 8 ALUs (R300) zu halber Performance bei gleichem Takt führt. Unabhängig von der individuallen Optimierung der Shader, fehlt es dem NV30 damit an ALUs/Pipes für Fließkomma-PS1.4. Ein Rückstand, den man auf Grundlage des Artikels vermutlich nur schwerlich durch eine bessere Befehlswahl/-Codierung kompensieren können sollte. Der höhre Takt von knapp 50% kann den "ALU-Mangel" nicht vollständig ausgleichen, was in speziellen PS2.0-Benches unmittelbar ersichtlich war. Zusätzlich war die Überlegenheit von NV's PS1.0-1.3 Implementation zu sehen. Bei PS1.4 mit Integer ergibt sich damit ungefähr ein Patt, bei Fließkomma ist der NV30 vermutlich hoffungslos abgeschlagen. Was die Passes betrifft, so sind diese doch lediglich eine Mindestforderung für die jeweilige PS Version und eigentlich eine Eigenschaft der gesamten Pipe. Ich könnte mir vorstellen, daß der 16fache Loopback von DX9 auch für die Interger-Komponente der Pipe gilt. Damit hätten ich auch bereits eine mögliche NV30/GF4-Optimierungen für den NV30-Pfad benannt.

Liege ich mit dieser Einschätzung wirklich grundsätzlich falsch?

Leider stört der höhere Takt der FX beim direkten Vergleich ein wenig :(

Salvee
2003-03-02, 23:38:11
Originally posted by Demirug
Das beste an der Geschichte mit den 5 Stages in 2 Combiner war ja noch das der Treiberentwickler der das ganze entwickelt hat davon ganz stolz den Spieleentwicklern berichtet hat. Wenn dieses 5 Stages Setup in irgendeinem Benchmark benutzt würde hätte er sicher einen Maulkorb bekommen weil sonst gleich wieder Cheat geschrien worden währe.

Nochmal für die langsamen unter uns :)

Ist das bereits eingetreten, was Zeckensack in diesem (http://www.forum-3dcenter.de/vbulletin/showthread.php?threadid=54674&pagenumber=6) Thread prophezeit hat, oder nicht (in Bezug auf 3DM03) ?

Zitat:
'Klartext:
Die beste mögliche Treiber-Optimierung für 3DM03 ist - laut Matt Craighead, c/o NVIDIA; Treiber-Abteilung - zu erkennen daß 3DM03 läuft, und die 'wischi-waschi'-Algorithmen einfach nicht auszuführen, sondern es ganz anders zu machen. Dh daß der Treiber nicht mehr, wie es seine eigentlich Aufgabe ist, Schritt für Schritt die Anweisungen der App ausführt, sondern etwas völlig anderes macht, was zum gleichen visuellen Ergebnis führt, aber schneller läuft.'

Demirug
2003-03-02, 23:38:57
Virtual, du wirfst hier ein paar sachen durcheinader.

1. Die Frage ob der NV30 nun 8 oder 4 Pipes und vorallem wie viele ALUs pro Pipe verfügbar sind ist bis heute noch nicht entgültig geklärt.

2. Das man einen PS 1.4 Shader im Multipass verfahren aus mehren PS 1.1 Shader zusammen setzten kann ist zwar prinzipiel richtig funktioniert aber nicht mit allen 1.4 PS ohne Probleme. Zudem müsste man dafür dann auch noch im Treiber aus einen Singelpass auftrag einen Multipass Renderauftrag machen. Das wäre nun des gute wirklich zu viel.

3. Das mit den Loopbacks vergessen wir mal ganz schnell wieder. Eine solche Forderung gibt es in DX nicht. Es ist lediglich festgelegt wie viele Texturen bei einer bestimmten Shaderversion zur verfügung stehen müssen. Wie ein Chip das nu realisiert ist Sache der Hersteller. Und die 16 Texturen bei PS >= 2.0 ändern nichts daran das die Integer PS 1.1-1.3 nur 4 Texturen haben können und die 1.4 mit maximal 6 Texturen (mit jeweils bis zu 2 Sampels) auskommen müssen.

Demirug
2003-03-02, 23:40:25
Originally posted by Salvee


Nochmal für die langsamen unter uns :)

Ist das bereits eingetreten, was Zeckensack in diesem (http://www.forum-3dcenter.de/vbulletin/showthread.php?threadid=54674&pagenumber=6) Thread prophezeit hat, oder nicht (in Bezug auf 3DM03) ?

Zitat:
'Klartext:
Die beste mögliche Treiber-Optimierung für 3DM03 ist - laut Matt Craighead, c/o NVIDIA; Treiber-Abteilung - zu erkennen daß 3DM03 läuft, und die 'wischi-waschi'-Algorithmen einfach nicht auszuführen, sondern es ganz anders zu machen. Dh daß der Treiber nicht mehr, wie es seine eigentlich Aufgabe ist, Schritt für Schritt die Anweisungen der App ausführt, sondern etwas völlig anderes macht, was zum gleichen visuellen Ergebnis führt, aber schneller läuft.'

Nein, so weit ist NVIDIA wohl noch nicht. Sonst hätten sie noch viel mehr Punkte bekommen.

Virtual
2003-03-03, 00:56:05
Originally posted by Demirug
Virtual, du wirfst hier ein paar sachen durcheinader.

1. Die Frage ob der NV30 nun 8 oder 4 Pipes und vorallem wie viele ALUs pro Pipe verfügbar sind ist bis heute noch nicht entgültig geklärt.

2. Das man einen PS 1.4 Shader im Multipass verfahren aus mehren PS 1.1 Shader zusammen setzten kann ist zwar prinzipiel richtig funktioniert aber nicht mit allen 1.4 PS ohne Probleme. Zudem müsste man dafür dann auch noch im Treiber aus einen Singelpass auftrag einen Multipass Renderauftrag machen. Das wäre nun des gute wirklich zu viel.

3. Das mit den Loopbacks vergessen wir mal ganz schnell wieder. Eine solche Forderung gibt es in DX nicht. Es ist lediglich festgelegt wie viele Texturen bei einer bestimmten Shaderversion zur verfügung stehen müssen. Wie ein Chip das nu realisiert ist Sache der Hersteller. Und die 16 Texturen bei PS >= 2.0 ändern nichts daran das die Integer PS 1.1-1.3 nur 4 Texturen haben können und die 1.4 mit maximal 6 Texturen (mit jeweils bis zu 2 Sampels) auskommen müssen.

Zu 1) Alle Vermutungen auf der Grundlage des Artikels

Zu 2) NVidia sagte seinerzeit zu PS1.4 sinngemäß: Es gibt nichts, was PS1.4 kann, was wir(NV) nicht auch mit der GF4 (PS1.1) machen können.

Zu 3) Kombiniere ich nun deine und die Aussagen von JC's richtig, dann muß der NV30-Pfad in Doom3 PS2.0 nutzen, weil sonst "single pass" nicht immer! eingehalten werden kann. PS1.4 im R200-Pfad reicht dazu laut JC nicht! immer aus. Schlußfolgerung: Nach dem Artikel hat die FX nur vier Float-ALUs bzw. Pipes mit einer OP/Takt(egal ob 16-Bit oder 32-Bit). Der R300 hat acht Float-OPs/Takt. Bei ca. 50% höherem Takt FX-Ultra/R9700Pro und nur halber tatsächlicher Geschwindigkeit bei ARB2 müßte die FX-Ultra nun mit drei mal weniger Float-OPs(Befehlen) im NV30-Pfad zum gleichen visuellen Ergebnis kommen. In diesem Fall kann man den NV Treiberingenieuren nur gratulieren! Irgendwie bin ich aber davon noch nicht ganz überzeugt, denn die Konsequenz daraus wäre, daß ATI's Treiberingenieure ziemlich Dilettanten wären. Nein, bei NV kocht man auch nur mit Wasser -> Kommt die wundersame Performance-Steigerung nicht doch aus der Integer-Ecke oder gibt es doch einen Geschwindigkeits-Unterschied zwischen 16-Bit und 32-Bit Genauigkeit bei der FX?

G.
V.

RyoHazuki
2003-03-03, 01:18:27
Also,

von meiner sicht aus ist der NV30 überhaupt GARNICHT vergleichbar mit der Radeon 9700 Pro !

Begründung :

DAS SPEICHERINTERFACE

irgendjemand sollte mal sich die mühe machen und die GF FX auf 275/540 takten (Radeon 9500 Pro)

Geforce FX vs. Radeon 9500 Pro

LMA III vs. HyperZ III
128bit vs. 128bit

das wäre für mich ein akzeptabler vergleich ! Ich bin zwar kein Nvidia Fanatiker, aber ich muss echt dieses kleine Stück Wunder was Nvidia vollbracht hat bewundern !!!

Es fehlt allerdings DIE ECHTE HIGH END karte !

Denn zu zeiten wie diesen, ist eine "Variable" Pipeline Architektur und "nur" 128bit Speicherinterface nicht genug !

Und ich behaupte, wenn der NV30,

- ein 256bit Speicherinterface bekommt

dann könnte der NV30 auf 400/800 laufen, er würde Radeon 9700 Pro "DEUTLICH WEG FEHGEN" !

Ende der vorstellung

Salvee
2003-03-03, 01:33:09
Es ging hier aber Hauptsaächlich um die Pixelshader bzw. deren Speed oder Aifbau, und da ist die FX nicht bandbreitenlimitiert bzw. die Bandbreite spielt nicht die massgebliche Rolle.
(Was aber lustig ist, ist deine Formulierung vom 'kleinen Wunder'-kennst du den Slogan von Fairy Ultra von Dawn ?? :rofl: )

Radeonator
2003-03-03, 01:52:09
Originally posted by RyoHazuki
Also,

von meiner sicht aus ist der NV30 überhaupt GARNICHT vergleichbar mit der Radeon 9700 Pro !

Begründung :

DAS SPEICHERINTERFACE

irgendjemand sollte mal sich die mühe machen und die GF FX auf 275/540 takten (Radeon 9500 Pro)

Geforce FX vs. Radeon 9500 Pro

LMA III vs. HyperZ III
128bit vs. 128bit

das wäre für mich ein akzeptabler vergleich ! Ich bin zwar kein Nvidia Fanatiker, aber ich muss echt dieses kleine Stück Wunder was Nvidia vollbracht hat bewundern !!!

Es fehlt allerdings DIE ECHTE HIGH END karte !

Denn zu zeiten wie diesen, ist eine "Variable" Pipeline Architektur und "nur" 128bit Speicherinterface nicht genug !

Und ich behaupte, wenn der NV30,

- ein 256bit Speicherinterface bekommt

dann könnte der NV30 auf 400/800 laufen, er würde Radeon 9700 Pro "DEUTLICH WEG FEHGEN" !

Ende der vorstellung

Ja, ich "wunder" mich auch, wie so mancher auf PR abfährt und sich so einfach manipulieren lässt...Wenn und hätte hat noch nie jemanden geholfen!
NV muss nachbessern und das möglichst fix!

mapel110
2003-03-03, 01:58:48
Originally posted by RyoHazuki
Also,

von meiner sicht aus ist der NV30 überhaupt GARNICHT vergleichbar mit der Radeon 9700 Pro !

Begründung :

DAS SPEICHERINTERFACE

irgendjemand sollte mal sich die mühe machen und die GF FX auf 275/540 takten (Radeon 9500 Pro)

Geforce FX vs. Radeon 9500 Pro

LMA III vs. HyperZ III
128bit vs. 128bit

das wäre für mich ein akzeptabler vergleich ! Ich bin zwar kein Nvidia Fanatiker, aber ich muss echt dieses kleine Stück Wunder was Nvidia vollbracht hat bewundern !!!

Es fehlt allerdings DIE ECHTE HIGH END karte !

Denn zu zeiten wie diesen, ist eine "Variable" Pipeline Architektur und "nur" 128bit Speicherinterface nicht genug !

Und ich behaupte, wenn der NV30,

- ein 256bit Speicherinterface bekommt

dann könnte der NV30 auf 400/800 laufen, er würde Radeon 9700 Pro "DEUTLICH WEG FEHGEN" !

Ende der vorstellung

schau dir den speed unterschied zwischen radeon 9700 und radeon 9500 pro an. da ist nicht viel.
das interface macht sich erst bei hohen auflösungen mit AA bemerkbar.

ausserdem halte ich zumindest einen höheren ram-takt für effektiver als ein breiteres interface.

zeckensack
2003-03-03, 02:04:40
Originally posted by Virtual


Zu 1) Alle Vermutungen auf der Grundlage des Artikels

Zu 2) NVidia sagte seinerzeit zu PS1.4 sinngemäß: Es gibt nichts, was PS1.4 kann, was wir(NV) nicht auch mit der GF4 (PS1.1) machen können.Ad 2: Das ist nicht ganz die Wahrheit, um es mal diplomatisch auszudrücken :)

Zu 3) Kombiniere ich nun deine und die Aussagen von JC's richtig, dann muß der NV30-Pfad in Doom3 PS2.0 nutzen, weil sonst "single pass" nicht immer! eingehalten werden kann. PS1.4 im R200-Pfad reicht dazu laut JC nicht! immer aus. Schlußfolgerung: Nach dem Artikel hat die FX nur vier Float-ALUs bzw. Pipes mit einer OP/Takt(egal ob 16-Bit oder 32-Bit). Der R300 hat acht Float-OPs/Takt. Bei ca. 50% höherem Takt FX-Ultra/R9700Pro und nur halber tatsächlicher Geschwindigkeit bei ARB2 müßte die FX-Ultra nun mit drei mal weniger Float-OPs(Befehlen) im NV30-Pfad zum gleichen visuellen Ergebnis kommen. In diesem Fall kann man den NV Treiberingenieuren nur gratulieren! Irgendwie bin ich aber davon noch nicht ganz überzeugt, denn die Konsequenz daraus wäre, daß ATI's Treiberingenieure ziemlich Dilettanten wären. Nein, bei NV kocht man auch nur mit Wasser -> Kommt die wundersame Performance-Steigerung nicht doch aus der Integer-Ecke oder gibt es doch einen Geschwindigkeits-Unterschied zwischen 16-Bit und 32-Bit Genauigkeit bei der FX?

G.
V. Der Vergleich ist schön, aber hinkt schon ganz zu Beginn: es gibt unter OpenGL (ergo für Doom 3) keine PS1.4.

Unter DX9 ist gefordert, daß ein Chip der PS2.0 beherrscht, auch PS1.4 kann. Daher vielleicht dieser Gedanke.
Aber NVIDIA bietet auf keiner Karte, auch nicht auf der FX, die passende Extension an, die man am ehesten als das Äquivalent zu PS1.4 bezeichnen kann: ATI_fragment_shader.

Es ist im Grunde viel einfacher als du es dir überlegt hast. Die FX muß ihre ganz ureigene Extension benutzen um wirklich schnell zu sein. Das Ausweichen auf den herstellerübergreifenden ARB_fragment_shader führt zu Geschwindigkeitsverlusten, wobei noch ungeklärt ist warum.
Theorie 1)ARB_fp nutzt derzeit automatisch höhere Präzision, was auf der FX ordentlich einbricht
Theorie 2)Das Treiberteam hat ARB_fp erstmal nur so eingebaut, daß es überhaupt funktioniert, und die Optimierungsarbeit auf die (für die Launch-Demos wichtige) proprietäre Extension konzentriert

IMO ist's eine Mischung aus beidem, und da kann und wird sich in den nächsten Monaten noch einiges bewegen.

aths
2003-03-03, 07:22:38
Originally posted by Virtual
Zu 2) NVidia sagte seinerzeit zu PS1.4 sinngemäß: Es gibt nichts, was PS1.4 kann, was wir(NV) nicht auch mit der GF4 (PS1.1) machen können.So kam es rüber. Aber Dr. D. Kirk sagte nur, dass er (persönlich) noch kein Bild auf einer Radeon 8500 gesehen hätte, was GeForce3 nicht genauso gut oder besser rendern könnte. Der Chefentwickler David "Father of Architecture" Kirk muss dabei übersehen haben, dass seine GeForce mit nur 9 Bit pro Farbkanal rendert und nur 4 Texturen pro Pass verarbeiten kann, während die Radeon 8500 gleich 12 Bit zur Verfügung stellt und mit 6 Texturen klar kommt.

Demirug
2003-03-03, 08:05:21
Originally posted by aths
So kam es rüber. Aber Dr. D. Kirk sagte nur, dass er (persönlich) noch kein Bild auf einer Radeon 8500 gesehen hätte, was GeForce3 nicht genauso gut oder besser rendern könnte. Der Chefentwickler David "Father of Architecture" Kirk muss dabei übersehen haben, dass seine GeForce mit nur 9 Bit pro Farbkanal rendert und nur 4 Texturen pro Pass verarbeiten kann, während die Radeon 8500 gleich 12 Bit zur Verfügung stellt und mit 6 Texturen klar kommt.

Übersehen hat er das nicht. ;) Mit viel mühe und Aufwand bekommt jeden PS 1.4 Effekt auch mit einem PS 1.1 hin. Vom Speed reden wird dann aber besser nicht mehr.

skampi
2003-03-03, 10:13:27
Originally posted by RyoHazuki
Also,

von meiner sicht aus ist der NV30 überhaupt GARNICHT vergleichbar mit der Radeon 9700 Pro !

Begründung :

DAS SPEICHERINTERFACE

irgendjemand sollte mal sich die mühe machen und die GF FX auf 275/540 takten (Radeon 9500 Pro)

Geforce FX vs. Radeon 9500 Pro

LMA III vs. HyperZ III
128bit vs. 128bit

das wäre für mich ein akzeptabler vergleich ! Ich bin zwar kein vidia Fanatiker, aber ich muss echt dieses kleine Stück Wunder was Nvidia vollbracht hat bewundern !!!

Es fehlt allerdings DIE ECHTE HIGH END karte !

Denn zu zeiten wie diesen, ist eine "Variable" Pipeline Architektur und "nur" 128bit Speicherinterface nicht genug !

Und ich behaupte, wenn der NV30,

- ein 256bit Speicherinterface bekommt

dann könnte der NV30 auf 400/800 laufen, er würde Radeon 9700 Pro "DEUTLICH WEG FEHGEN" !

Ende der vorstellung

In den NV30 musste Nvidia so viel vom der GF4 drinlassen, damit sie nicht in ihrer eigene Kompatibilitäts-Falle laufen. Da weiss man auch, wozu die 125Mio Trans draufgegangen sind.

Nvidia hat einmal mehr gezeigt, das auch sie nur mit Wasser kochen, und das war diesmal nichtmal besonders heiss.

Unregistered
2003-03-03, 10:41:23
Originally posted by RyoHazuki
Also,

von meiner sicht aus ist der NV30 überhaupt GARNICHT vergleichbar mit der Radeon 9700 Pro !

Begründung :

DAS SPEICHERINTERFACE

irgendjemand sollte mal sich die mühe machen und die GF FX auf 275/540 takten (Radeon 9500 Pro)

Geforce FX vs. Radeon 9500 Pro

LMA III vs. HyperZ III
128bit vs. 128bit

das wäre für mich ein akzeptabler vergleich ! Ich bin zwar kein Nvidia Fanatiker, aber ich muss echt dieses kleine Stück Wunder was Nvidia vollbracht hat bewundern !!!



Lame...

ist doch schon längst passiert. Eine franz. Webseite (Link:...??) hat die GFFx mit der R9500Pro bei 275MHz/540MHz verglichen. Das entsprechende Chart wurde sogar mehrmals im Forum gepostet.

Ergebnis :

ohne AF+AA sind beide nahezu gleich (GFFx ca. 5% schneller)
incl. AF+AA ist die R9500Pro deutlich schneller gewesen.

Also nix mit GFFx so super toll.

Virtual
2003-03-03, 12:01:41
Originally posted by zeckensack
Ad 2: Das ist nicht ganz die Wahrheit, um es mal diplomatisch auszudrücken :)
Naja, "sinngemäß" läßt sich eben dehnen :) Es ging mir um die Bestätigung durch NV, daß mein Integer-Ansatz für mehr Performance in Bezug auf die Bildqualität zumindest tragbar ist.

Der Vergleich ist schön, aber hinkt schon ganz zu Beginn: es gibt unter OpenGL (ergo für Doom 3) keine PS1.4.


Unter DX9 ist gefordert, daß ein Chip der PS2.0 beherrscht, auch PS1.4 kann. Daher vielleicht dieser Gedanke.
Aber NVIDIA bietet auf keiner Karte, auch nicht auf der FX, die passende Extension an, die man am ehesten als das Äquivalent zu PS1.4 bezeichnen kann: ATI_fragment_shader.

Mein Fehler. Ich springe zwischen zwei guten "guten Kandidaten" für wundersame Performance-Steigerungen, also Doom3 und 3DMark2003, zu wirr hin und her und meine eigentlich mit PS1.4 die Hardware-Resourcen Anforderung für die Verarbeitung von Pixel Shader auf dem Komplexitäts-Niveau von PS1.4 aus DX8.1. Das NV keine Äquivalent zu ATI's PS1.4 OpenGL-Extension anbietet, ist verständlich aus verschiednen Gründen.

Es ist im Grunde viel einfacher als du es dir überlegt hast. Die FX muß ihre ganz ureigene Extension benutzen um wirklich schnell zu sein. Das Ausweichen auf den herstellerübergreifenden ARB_fragment_shader führt zu Geschwindigkeitsverlusten, wobei noch ungeklärt ist warum.
Theorie 1)ARB_fp nutzt derzeit automatisch höhere Präzision, was auf der FX ordentlich einbricht

Möglicherweise - Allerdings trifft der Artikel die zugegeben gewagte Aussage, es gäbe hier keinen Unterschied in der Ausführungeschwindigkeit.

Theorie 2)Das Treiberteam hat ARB_fp erstmal nur so eingebaut, daß es überhaupt funktioniert, und die Optimierungsarbeit auf die (für die Launch-Demos wichtige) proprietäre Extension konzentriert

IMO ist's eine Mischung aus beidem, und da kann und wird sich in den nächsten Monaten noch einiges bewegen.
Wenn ich mich recht entsinne, ist ARB2 maßgeblich von ATI beeinflußt worden. Hier könntest du recht haben...

...oder aber meine Vermutung trifft zu, und NV "schaltet" zurück auf die GF4 für die gemachten Performance-Sprünge:
Sowohl D3 als auch 3DM03 nutzen offensichtlich Pixel Shader, die in ihrer Komplexität in beinahe allen Fällen nicht PS 2.0 Hardware-Resourcen erfordern. NVidia nahm beim Design der FX in Anlehung an die bisherige Entwicklung an, daß dies auch für Spiele in 2002/3/4 gelten sollte. In Hinblick auf eine vorteilhaft schnelle Verarbeitung der in 2k2/3/4 "üblichen" Pixel Shader Komplexität auf DX8(.1) Niveau integrierte NV die Register Combiner aus der GF4, die wohl Shader der Komplexität PS1.1 (PS1.4 mit Integer Emulation) wesentlich schneller verarbeiten können, als daß dies mit CineFX (Fließkomma) Shader-Äquivalenten möglich wäre. Der GF4-Combiner-Anteil in den Pipes ist offensichtlich noch aufgebohrt worden, um einen deutlichen Abstand zur TI4x00-Reihe gewährleisten zu können.

Um es nochmals zu verdeutlichen, worum es mir geht: Wird die FX aufgrund ihrer Hardware-Resourcen in 2003/2004 ausschließlich als beschleunigte GF4 eingesetzt werden, also auch in Doom3 und Games auf Basis dieser Engine, oder werden wir noch in den Genuß der CineFX Fließkomma-Genauigkeit kommen? Der R300 scheint bei 2.0 Pixel Shader nur unwesentlich langsamer (R200-Pfad/ARB2) zu sein als bei 1.4 Integer. Nach dem Register-Artikel erscheint die NV30-CineFX-Architektur (nur 4 Float ALUs) zu Leistungssschwach für 2.0 Spiele, gesehen im Vergleich zum R300. Dies gilt insbesondere für die niedriger getakteten Varianten NV31/34 (sogar nur 2 oder 1 Pipe?) Damit ist die CineFX-Architektur IM NV30! ausschließlich für Demos, DCC und zum Experimentieren sinnvoll und es bleibt für NV zu hoffen, daß die Entwickler nicht vorzeitig auf den PS2.0 Geschmack kommen! ;)

Sagenhafte "Treiber-Performance"-Sprünge durch geschicktere Programmierung bei PS1.4 in Fließkomma, welche Demirug und Du selbst, wenn ich es richtig interpretiere, weiterhin für wahrscheinlicher haltet, erscheinen mir anhand der im Artikel aufgeführten Hardware-Limitation ziemlich unwahrscheinlich, wenngleich nicht unmöglich. Pixel Shader, bei der die Komplexität des CineFX-Design endlich durch weniger passes Wirkung zeigen könnte, dürften, von Demos und DCC abgesehen, für Zocker noch in weiter Ferne sein. Der Register-Artikel zeigt deutlich die Einschränkungen von PS1.4 über Fließkomma, und Multi-Pass über PS1.1 könnte deutlich günstiger sein, wenn man die beschleunigte "GF4-Einheit" im NV30 bedenkt. Um hier eine genaue Aussage treffen zu können, müßte man schon detaillierten Einblick in die verwendeten Shader haben, bzw. deren Anforderungen an die Resourcen der GPU-Hardware. Mit dem R300 und dessen 8 Float-Pipes scheint zumindest theoretisch deren Nutzung für Games möglich. Die Erklärung, warum der NV30 Single-Texturing und deshalb Game-Test1 im 3DM03 nicht mag, liegt bei einer 4-Pipes Architektur ziemlich nahe. Drei Texture Layer sind schon weniger schmerzhaft und bei fünf tuen nur vier Pipes kaum noch weh.

Der R300 erscheint mir als DX9-GPU für Shader auf dem kleinsten gemeinsamen Nenner 2.0 weitaus geeigneter zu sein als dies der NV30 ist. NVidia sollte eigentlich froh sein, daß Futuremark nicht mehr PS2.0 Shader verwendet hat. Richtig gut weggekommen wären NV eigenlich nur bei einem 3DMark2003 mit nativer Shader-Segmentierung nach PS1.1 anstelle PS1.4 (mehr passes für R300) bzw. bei Shader-"Futter" für die CineFX-Architektur (weniger passes). Die PS1.4/2.0 Mitte wird somit dem R300 und dessen Abklömmlinge vorbehalten bleiben.

Ach, da wäre noch...
Der NV35/40 mit mehr ALUs könnte bei DX9 zu wahren Performance-Sprüngen ansetzen! Wenn man diese GPUs kaufen können wird, spielt die DX9-Fähigkeit nach PS2.0 mit Sicherheit eine größere Rolle. ;)

G.
V.

robbitop
2003-03-03, 19:02:00
" Nach dem Artikel hat die FX nur vier Float-ALUs bzw. Pipes mit einer OP/Takt(egal ob 16-Bit oder 32-Bit). Der R300 hat acht Float-OPs/Takt."

@ Unreg
nein der NV30 hat 32 FP-ALUs. Wir nennen sie Micro ALUs.
Sie werden nur noch nicht effektiv genutzt (obs am treiber oder HW liegt ist unklar, klar ist, dass dies wohl spätestens zum NV35 gefixt ist..oder per Treiber wenn es nich in der Pipe hakt).

Immo sehen die Spekus das Pipeline Design als recht fleixbel an.
Die gesamte pipeline ist neu und flexibel wie auch die VS Array, d.h der Chip ist bis auf einige sachen grösstenteils neu..nix NV2x.
Im Trisetup und den AA Samplern und das Speicherinterface..sonst nirgendwo.
Das Manko ist, dass das flexible pipedesign noch nich so läuft, wie es sollte und einfach hohe Takte brauch um genug Speed zu haben.

Das gute dabei ist die einsparung von vielen Transistorn auch in zukunft und die höher werdende flexibilität.
Man braucht um mehr speed zu gewinnen nicht nach dem alten Pipelinestrukturprinzip, diese zu duplizieren, sondern hat mehrere Endpipelines. Wenn man mehr füllrate benötigt kommen ein paar TMUs in weitere Endpipes. AA Sampler sollen sowieso unterausgelastet sein, waarum also duplizieren? PS Leistung ist sowieso immo overkill, also kann man auch hier minimieren.
Also mehr kleine ALU. Somit hat jede TMU eine ALU und die Füllrate steigt linear ohne grosse aufwände. NAchteil im Singletexturing.

Momentan läuft das alles noch nich so wie sie wollten, aber ich denke in diesem Design steckt viel Potential wie in dem des 3DLabs P10 und auch hier müssen Refreshes viel ausbügeln. Auch ATi wird zu flexiblerer Struktur übergehen. Und der NV30 war bereits vor über einem Jahr fertig, NV hatte einfach Pech und muss damit leben.
Schuld daran sind die Bauarbeiter von TSMC die ständich bei die Maurer ein trinken ;-) ...

Ich denke der Ansatz ist technologisch nicht schlecht, ist aber noch nicht reif, wie auch das VS Array...ATi erreicht mit konventionellen Methoden einfach immo mehr, aber das wird sich ändern und auch ATi wird ihr Design ändern, bestimmt mit der nächsten Revolution (R400??).
Und jedenfalls ist der NV30 wesendlich schneller bei gleichem Takt als ein NV25 und das wird sicher noch besser...
Ich bin kein NV Fan sondern mag eifach die Technologie dahinter und die Technologie des R300 ist im gegensatz zu seiner leistungsfähigkeit
eben grundlegend noch etwas konservativer.

Der R300 zieht seine enorme leistung wie man dank benches sieht kaum aus dem 256bit DDR Interface, wobei ich nicht sagen möchte, es sei ineffektiv. Ich denke der R300 ist so wie er ist zu "klein" für das 256bit Interface, da dieser bei OC wirklich schön mit dem Chiptakt skalliert und speichertakt fast egal ist. Ein R9500PRO kommt fast an eine R9700 ran. Erst bei hohem FSAA kommen 30% unterschiede hervor..

Ich denke dieses Jahr wird wirklich schön im Bereich Revolution und Evolution im 3DBereich.

Zum Thema 3DMark brauch ich eigendlich seit dem 2001 besonders dem 2003 nix zu sagen. Als bench einfach nur quark und realitätsfern...

Ich denke wir brauchen eine neue Referenz. Ein selbst zusammengestellten vieleicht? Vieleicht mit Doom3 Engine oder Doom3 Teilen, wo bestimmte Limitationen zum ausdruck kommen und anderen Gameausschnitten mit derselben sache..


we will see...


alles IMHO bitte aber ;-)

AlfredENeumann
2003-03-03, 21:20:10
Originally posted by RyoHazuki
Also,

von meiner sicht aus ist der NV30 überhaupt GARNICHT vergleichbar mit der Radeon 9700 Pro !

Begründung :

DAS SPEICHERINTERFACE

irgendjemand sollte mal sich die mühe machen und die GF FX auf 275/540 takten (Radeon 9500 Pro)

Geforce FX vs. Radeon 9500 Pro

LMA III vs. HyperZ III
128bit vs. 128bit

das wäre für mich ein akzeptabler vergleich ! Ich bin zwar kein Nvidia Fanatiker, aber ich muss echt dieses kleine Stück Wunder was Nvidia vollbracht hat bewundern !!!

Es fehlt allerdings DIE ECHTE HIGH END karte !

Denn zu zeiten wie diesen, ist eine "Variable" Pipeline Architektur und "nur" 128bit Speicherinterface nicht genug !

Und ich behaupte, wenn der NV30,

- ein 256bit Speicherinterface bekommt

dann könnte der NV30 auf 400/800 laufen, er würde Radeon 9700 Pro "DEUTLICH WEG FEHGEN" !

Ende der vorstellung

Mein Vorschöag. MAch anschließend ne gegenprobe. Takte die 9500pro auf über 400MHz und mess dann erneut.

Virtual
2003-03-03, 21:43:28
Originally posted by robbitop
" Nach dem Artikel hat die FX nur vier Float-ALUs bzw. Pipes mit einer OP/Takt(egal ob 16-Bit oder 32-Bit). Der R300 hat acht Float-OPs/Takt."

@ Unreg
nein der NV30 hat 32 FP-ALUs. Wir nennen sie Micro ALUs.
Sie werden nur noch nicht effektiv genutzt (obs am treiber oder HW liegt ist unklar, klar ist, dass dies wohl spätestens zum NV35 gefixt ist..oder per Treiber wenn es nich in der Pipe hakt).


Interessant! - Wo hast du die Info her und wie offiziell ist die Info. Könnte mir vorstellen, daß NVidia zum jetzigen Zeitpunkt nichts zu den Internas aussagen möchte.


Immo sehen die Spekus das Pipeline Design als recht fleixbel an.
Die gesamte pipeline ist neu und flexibel wie auch die VS Array, d.h der Chip ist bis auf einige sachen grösstenteils neu..nix NV2x.
Im Trisetup und den AA Samplern und das Speicherinterface..sonst nirgendwo.
Das Manko ist, dass das flexible pipedesign noch nich so läuft, wie es sollte und einfach hohe Takte brauch um genug Speed zu haben.

Die Register-Combiner des NV25 trifft man im Fragment Shader des NV30 doch wieder an, gemäß NV-Docu zur OpenGL Fragment Extension. Sicher ist die Shader Architektur "flexibler" als im NV25, die Frage ist eben nur, in welcher Beziehung.

Das gute dabei ist die einsparung von vielen Transistorn auch in zukunft und die höher werdende flexibilität.
Man braucht um mehr speed zu gewinnen nicht nach dem alten Pipelinestrukturprinzip, diese zu duplizieren, sondern hat mehrere Endpipelines. Wenn man mehr füllrate benötigt kommen ein paar TMUs in weitere Endpipes. AA Sampler sollen sowieso unterausgelastet sein, waarum also duplizieren? PS Leistung ist sowieso immo overkill, also kann man auch hier minimieren.
Also mehr kleine ALU. Somit hat jede TMU eine ALU und die Füllrate steigt linear ohne grosse aufwände. NAchteil im Singletexturing.

ALU-Sharing ist im NV30 bestimmt vorhanden, trägt aber nicht zur Performance bei, sondern hilft nur Gatter sparen. Von denen hat der NV30 ja genug. Außerdem: Viel Konfigurierbarkeit geht immer auf Kosten der Effizienz. Ich würde zu gerne wissen wie's im Frament Processor im Detail aussieht.

Momentan läuft das alles noch nich so wie sie wollten, aber ich denke in diesem Design steckt viel Potential wie in dem des 3DLabs P10 und auch hier müssen Refreshes viel ausbügeln. Auch ATi wird zu flexiblerer Struktur übergehen. Und der NV30 war bereits vor über einem Jahr fertig, NV hatte einfach Pech und muss damit leben.
Schuld daran sind die Bauarbeiter von TSMC die ständich bei die Maurer ein trinken ;-) ...

Ein grundlegend neues Design hat immer viel Verbesserungspotential.

Ich denke der Ansatz ist technologisch nicht schlecht, ist aber noch nicht reif, wie auch das VS Array...ATi erreicht mit konventionellen Methoden einfach immo mehr, aber das wird sich ändern und auch ATi wird ihr Design ändern, bestimmt mit der nächsten Revolution (R400??).
Und jedenfalls ist der NV30 wesendlich schneller bei gleichem Takt als ein NV25 und das wird sicher noch besser...
Ich bin kein NV Fan sondern mag eifach die Technologie dahinter und die Technologie des R300 ist im gegensatz zu seiner leistungsfähigkeit
eben grundlegend noch etwas konservativer.

Wir werden sehen, was die Zukunft bringt. Ich sehe die Dinge auch positiv, aber es gab auch mal einen Steit zwischen RISC und CISC, wobei CISC bald tot sein sollte. Wie es tatsächlich ausgegangen ist, wissen wir jetzt ja. Und auch die VLIW-Technik des Itanium muß sich erst noch beweisen.
Außerdem: NV-Fan zu sein oder eben auch nicht ist bei der technischen Frage nach dem NV30-Aufbau hoffentlich nicht wichtig! ;)

Der R300 zieht seine enorme leistung wie man dank benches sieht kaum aus dem 256bit DDR Interface, wobei ich nicht sagen möchte, es sei ineffektiv. Ich denke der R300 ist so wie er ist zu "klein" für das 256bit Interface, da dieser bei OC wirklich schön mit dem Chiptakt skalliert und speichertakt fast egal ist. Ein R9500PRO kommt fast an eine R9700 ran. Erst bei hohem FSAA kommen 30% unterschiede hervor..

Ich denke dieses Jahr wird wirklich schön im Bereich Revolution und Evolution im 3DBereich.

Zum Thema 3DMark brauch ich eigendlich seit dem 2001 besonders dem 2003 nix zu sagen. Als bench einfach nur quark und realitätsfern...

Ich denke wir brauchen eine neue Referenz. Ein selbst zusammengestellten vieleicht? Vieleicht mit Doom3 Engine oder Doom3 Teilen, wo bestimmte Limitationen zum ausdruck kommen und anderen Gameausschnitten mit derselben sache..
we will see...

Nichts gegen neue Benches! -> Her damit!
- Die eine Sorte Bench für die Praxis-Test in Games (entscheident für Zocker)
- Die andere Sorte sollte eher synthetischer Natur sein, um den Aufbau der GPUs besser verstehen zu können, welcher bis zu einem gewissen Grad gerne Geheim gehalten wird. Ich möchte mehr zu Bottlenecks, Gesamtabstimmung, ... erfahren können.



alles IMHO bitte aber ;-)

Ich mache keinen Streß! - Will nur mehr wissen :)

Bin übrigens kein "Unreg" ;)


G.
V.

Demirug
2003-03-03, 22:01:01
Das mit den 32 micro ALUs habe ich verbrochen. Diese Summe ergibt sich aus Angaben die NVIDIA zur Rechenleistung des NV30 rausgerückt hat. Darüber wie diese ALUs nun miteinader verschalten sind und welche Leistung in Shaderops/s sich daraus ergibt ist nach wie vor unbekannt.

Aus einer API Dokumentation auf den Aufbau eines Chips zu schliessen ist gefährlich. Denn wenn es danach ginge müsste im FX auch noch eine komplette TNT verbaut sein :D Die Register Combiner könnte man durchaus mit den FP-ALUs emulieren aber ich glaube derzeit auch das zumindestens nicht unwesentliche Teile der Register Combiner noch im Chip sind.

ALU-Sharing kann auch die Leistung erhöhen. Als Beispiel möchte ich hier mal das Hyperthreading des P4 aufführen.

Jaja die gute alte RISC gegen CISC Diskussion. Am Ende hat ja keiner gewonnen. Aber das ist eine andere Geschichte.

Virtual
2003-03-04, 00:10:24
Originally posted by Demirug
Das mit den 32 micro ALUs habe ich verbrochen. Diese Summe ergibt sich aus Angaben die NVIDIA zur Rechenleistung des NV30 rausgerückt hat. Darüber wie diese ALUs nun miteinader verschalten sind und welche Leistung in Shaderops/s sich daraus ergibt ist nach wie vor unbekannt.

Aus einer API Dokumentation auf den Aufbau eines Chips zu schliessen ist gefährlich. Denn wenn es danach ginge müsste im FX auch noch eine komplette TNT verbaut sein :D Die Register Combiner könnte man durchaus mit den FP-ALUs emulieren aber ich glaube derzeit auch das zumindestens nicht unwesentliche Teile der Register Combiner noch im Chip sind.

ALU-Sharing kann auch die Leistung erhöhen. Als Beispiel möchte ich hier mal das Hyperthreading des P4 aufführen.

Jaja die gute alte RISC gegen CISC Diskussion. Am Ende hat ja keiner gewonnen. Aber das ist eine andere Geschichte.

Im Prinzip stimme dir bei vielen Aussagen zu, doch beim P4 konstruiere ich dir gerne zwei Threads, die immer auf der gleichen Funktionseinheit eintrümmern werden. Das Performance-Verdict für einen HT-P4 im Vergleich zu einem !HT-P4 kannst du dir sicher vorstellen :) Von entscheidender Bedeutung über Wohl und Weh ist offensichtlich der auszuführende Code. Falls sich NV nun eine derart komplexe Aufgabe schon selbst stellen mußte, so sollen sie sie auch im Treiber zeitnah nach dem Produktrelease lösen!

Hat NV sich einfach nur übernommen?

ATI macht's vermutlich konventioneller, hat sich dabei aber auf's Wesentliche beschränkt.

Demirug
2003-03-04, 07:30:33
Das mit dem P4 war ja auch nur als Beispiel gedacht weil die meisten inzwischen mit dem Begriff Hyperthreading was anfangen können.

Wie gut der Verteilung funktioniert hängt in gewisser Weisse ja auch davon ab wie gleichwertig die zur verfügung stehende Rechenzellen sind. Beim P4 ist das eben nicht der Fall. Bei einem Grafikchip könnte das schon anders ausehen. Und solange es am ende funktioniert soll es mir recht sein.

Ailuros
2003-03-04, 13:09:41
Etwas OT: entweder verpatzen unausgereifte Treiber die wahren Faehigkeiten der FX, oder NV25 kann tatsaechlich in einem theoretischen clock for clock Vergleich besser overdraw behandeln:

http://www.beyond3d.com/previews/nvidia/gffxu/index.php?p=21#overdraw


Wer vergleichen will:

http://www.beyond3d.com/reviews/ati/radeon9700pro/index.php?page=page17.inc#overdraw

Demirug
2003-03-04, 14:02:24
Originally posted by Ailuros
Etwas OT: entweder verpatzen unausgereifte Treiber die wahren Faehigkeiten der FX, oder NV25 kann tatsaechlich in einem theoretischen clock for clock Vergleich besser overdraw behandeln:

http://www.beyond3d.com/previews/nvidia/gffxu/index.php?p=21#overdraw


Wer vergleichen will:

http://www.beyond3d.com/reviews/ati/radeon9700pro/index.php?page=page17.inc#overdraw

Das der R200 und erst recht der R300 beim Rauswerfen von Overdraw recht gut sind ist ja bekannt.

Was mich bei den FX Zahlen allerdings viel mehr verwundert ist die Skalierung.

400/400 Als Basis


Overdraw Takt B2F F2B Rand
3 125% 136% 131% 134%
8 125% 136% 128% 132%


Die Steigerung beim B2F ist schon etwas heftig. Wobei ich mich sowieso frage was der gute Humus da genau macht.

Unregistered
2003-03-04, 14:48:36
Originally posted by Ailuros
Etwas OT: entweder verpatzen unausgereifte Treiber die wahren Faehigkeiten der FX, oder NV25 kann tatsaechlich in einem theoretischen clock for clock Vergleich besser overdraw behandeln:

http://www.beyond3d.com/previews/nvidia/gffxu/index.php?p=21#overdraw


Wer vergleichen will:

http://www.beyond3d.com/reviews/ati/radeon9700pro/index.php?page=page17.inc#overdraw


Angeblich ist die Latency des 500MHZ-RAM's so hoch, das die Karte mit 400MHz-RAM (und dadurch reduziertem Latency) in einigen Bereichen schneller wird.
Ich dachte aber bisher, das nur OC-RAM eine zu hohe Latency hat, weil dann einfach Takte ausgelassen werden müssen, um überhaupt noch Daten über den Bus zu bekommen ohne das sich der Chip "verschluckt".

Demirug
2003-03-04, 15:04:36
Die 500 MHz DDR-II Chips von Samsung haben einen CL von 7 die 400 MHz kommen mit CL 5 aus.

Das könnte natürlich ein Grund sein das man bei der 500 MHz Version die Daten für den Early-Z Test nicht mehr schnell genug ranschaufeln kann.

Labberlippe
2003-03-04, 17:21:21
Originally posted by RyoHazuki
Also,

von meiner sicht aus ist der NV30 überhaupt GARNICHT vergleichbar mit der Radeon 9700 Pro !

Begründung :

DAS SPEICHERINTERFACE

irgendjemand sollte mal sich die mühe machen und die GF FX auf 275/540 takten (Radeon 9500 Pro)

Geforce FX vs. Radeon 9500 Pro

LMA III vs. HyperZ III
128bit vs. 128bit

das wäre für mich ein akzeptabler vergleich ! Ich bin zwar kein Nvidia Fanatiker, aber ich muss echt dieses kleine Stück Wunder was Nvidia vollbracht hat bewundern !!!

Es fehlt allerdings DIE ECHTE HIGH END karte !

Denn zu zeiten wie diesen, ist eine "Variable" Pipeline Architektur und "nur" 128bit Speicherinterface nicht genug !

Und ich behaupte, wenn der NV30,

- ein 256bit Speicherinterface bekommt

dann könnte der NV30 auf 400/800 laufen, er würde Radeon 9700 Pro "DEUTLICH WEG FEHGEN" !

Ende der vorstellung

Hi

Leider hast Du hier einen Denkfehler.
Der NV 30 (FX) verwendet DDR II Speicher.

Ein Direkter Vergleich mit einer 9500er Pro wäre nicht fair, da der DDR II somit eine viel höher Bandbreite hätte.

Um wirklich vergleichen zu können müssten die Karten.
Das gleiche Speicher Interface z.B. 128 Bithaben und die gleiche Speicherart. DDR 1 oder DDR II.

Würde der NV 30 auch eine 256er Anbindung verwenden würde dieser vermutlich auch normale DDR Speicher verbaut haben.
Ansonsten würde die Karte kosten ohne Ende.
Die Speicherbandbreite wäre allerdings mit DDR2 absolut fett.

Gruss Labberlippe

Demirug
2003-03-04, 17:27:03
Originally posted by Labberlippe


Hi

Leider hast Du hier einen Denkfehler.
Der NV 30 (FX) verwendet DDR II Speicher.

Ein Direkter Vergleich mit einer 9500er Pro wäre nicht fair, da der DDR II somit eine viel höher Bandbreite hätte.

Um wirklich vergleichen zu können müssten die Karten.
Das gleiche Speicher Interface z.B. 128 Bithaben und die gleiche Speicherart. DDR 1 oder DDR II.

Würde der NV 30 auch eine 256er Anbindung verwenden würde dieser vermutlich auch normale DDR Speicher verbaut haben.
Ansonsten würde die Karte kosten ohne Ende.
Die Speicherbandbreite wäre allerdings mit DDR2 absolut fett.

Gruss Labberlippe

DDR-II hat bei gleichem Takt eine höhre Bandbreite??? Wer hat dir das erzählt?

DDR-II hat bei gleichem Takt die gleiche Bandbreite und wesentlich mehr Einschränckungen als DDR-I Speicher. Bei gleichem Takt ist DDR-II Speicher in der Praxsis daher sogar eher benachteiligt.

ShadowXX
2003-03-04, 17:29:25
@Labberlippe

soweit ich weiss haben DDR I & DDR II genau die gleiche Bandbreite wenn sie das gleiche Interface benutzen (128 vs. 128 / 256 vs. 256).

Die "höhere" Geschwindigkeit kommt nur daher das man DDR II höher Takten kann als DDR I.
Wobei manche auch schon sagten, dass bei gleichem Takt der DDR I theoretisch einen hauch schneller sein müsste, da geringere Latenzzeiten.

MfG
J.S.Shadow

Virtual
2003-03-04, 21:04:18
@Demirug

Wie bei beyond3d zu lesen ist, hatte ich mit meinen Vermutungen weitgehend recht gehabt. Die FX ist in Bezug auf DX8 eine beschleunigte GF4! Die FX schreibt nur 4 Pixel nach "klassischer" Defintion pro Takt in den Puffer!

Wo kommen nun die Performance-Sprünge her?
PS1.4 über PS1.1 Integer-Emuliert scheint sinnvoll machtbar aus Performance-Sicht. Vermutlich haben sie im 3DMurks03 PS1.4 über FP gegen Integer über PS1.1 ersetzt.
Allerdings sollte man nicht die von dir und Zeckensack vertretene Meinung optimierter Shader außer acht lassen. Vielleicht war deshalb der von Zeckensack aufgetriebene Treiber-NVidianer derartig ungehalten, weil sein Treiber-Compiler einfach bis dato schrottig optimiert und man vielleicht häufiger als gewünscht mit Hand-Optmierung ;) die PS-ALUs unter Dampf halten muß.

Möglicherweise ist der NV30-Pfad in Doom3 tatsächlich nur DX8-Integer, es sei denn, NV hätte es geschafft FP16 für Doom3 effektiv zu nutzen. Gegenwärtig ist wohl beides möglich und der Kollege von NV (Beyond3D-Q&A) hat diesbezüglich auch nicht zur Klärung beitragen wollen.

G.
V.

Demirug
2003-03-04, 21:32:34
Virtual,

Das die FX nur 4 Farbwerte pro Takt rausschreiben kann ist ja inzwischen ein alter Hut. Diese Limitierung wirkt sich aber nur auf bi-lineares Single-Texturing aus.

PS 1.4 über die PS 1.1 Integer Einheiten laufen zu lassen mag sich aus Performances gründen verlockend anhören. Das Problem ist nur das die Register combinder (so nennt NVIDIA die Einheiten welche zumindestens bis zur GF4 die PS ausgeführt haben) technisch nicht in der Lage sind PS 1.4 Programme ablaufen zu lassen. Damit das doch funktioniert hätte NVIDIA diese Einheiten komplett ändern müssen und wenn man weiss was NVIDIA von den PS 1.4 hält ist das sehr unwahrscheinlich.

Matt war nicht wirklich ungehalten. Er hat sich wohl eher über die unfähigkeit von Futuremark lustig gemacht. (IMHO)

Das die Treibercompiler noch nicht gut sind hat NVIDIA ja schon JC gegenüber zugegeben.

Der NV30 Pfad für DOOM III kann kein reiner Integerpfad sein. Laut JC rendert der NV30 alles in einem Pass. Das ist mit der Extension für die Integer Pixelpipline nicht machbar dafür braucht man die neue NV30 Fragment Extension. Diese Extension ist primär auf die Verwendung von FP ausgelegt und hat aus diesem Grund auch nur FP-Register. Es lassen sich damit zwar auch manche (nicht alle)Berechnungen nur mit Integer genauigkeit durchgeführt werden aber die ergebnisse müssen wieder in FP umgewandelt werden weil die Register keine Integer werte speichern können. Über die geschwindigkeit bezüglich bei der benutzung von Integergenauigkeit in den NV30 Fragment Programmen gibt es aber keine richtigen Informationen.

Virtual
2003-03-04, 23:05:17
Originally posted by Demirug
Virtual,

Das die FX nur 4 Farbwerte pro Takt rausschreiben kann ist ja inzwischen ein alter Hut. Diese Limitierung wirkt sich aber nur auf bi-lineares Single-Texturing aus.

PS 1.4 über die PS 1.1 Integer Einheiten laufen zu lassen mag sich aus Performances gründen verlockend anhören. Das Problem ist nur das die Register combinder (so nennt NVIDIA die Einheiten welche zumindestens bis zur GF4 die PS ausgeführt haben) technisch nicht in der Lage sind PS 1.4 Programme ablaufen zu lassen. Damit das doch funktioniert hätte NVIDIA diese Einheiten komplett ändern müssen und wenn man weiss was NVIDIA von den PS 1.4 hält ist das sehr unwahrscheinlich.

Matt war nicht wirklich ungehalten. Er hat sich wohl eher über die unfähigkeit von Futuremark lustig gemacht. (IMHO)

Das die Treibercompiler noch nicht gut sind hat NVIDIA ja schon JC gegenüber zugegeben.

Der NV30 Pfad für DOOM III kann kein reiner Integerpfad sein. Laut JC rendert der NV30 alles in einem Pass. Das ist mit der Extension für die Integer Pixelpipline nicht machbar dafür braucht man die neue NV30 Fragment Extension. Diese Extension ist primär auf die Verwendung von FP ausgelegt und hat aus diesem Grund auch nur FP-Register. Es lassen sich damit zwar auch manche (nicht alle)Berechnungen nur mit Integer genauigkeit durchgeführt werden aber die ergebnisse müssen wieder in FP umgewandelt werden weil die Register keine Integer werte speichern können. Über die geschwindigkeit bezüglich bei der benutzung von Integergenauigkeit in den NV30 Fragment Programmen gibt es aber keine richtigen Informationen.

Sorry! - Bin leider nicht so up-to-date, wegen allgemein wenig Zeit (nur diese Woche mehr)...

... und auch ein wenig bei drei Schichten ohne trilinear. Hatte ich auch vorher schon angemerkt.

... Die Combiner sind natürlich weiterhin 1.1 und können nicht 1.4, was NVidia hauptsächlich veranlasst haben sollte, die Nutzung von 1.4 im 3DMurks03, gerechtfertigt oder nicht, anzugreifen. Mir geht es hier einzig um's visuelle Ergebnis. Matt C. gab doch (ich weiß, natürlich nur scherzend) zu bedenken: Man identifiziere die laufende App und setze an der richtigen Stelle die passenden Shader ein. Ein paar 1.1, die (fast) das gleiche visuelle Ergebenis von 1.4 im 3DMurks erziehlen... Es bietet sich an, denn CineFX-1.4 scheint im Vergleich zu einer Integer-1.1 Kombination deutlich langsamer zu sein. Hinweis: Der Advanced Shader Test im 3DMurks01SE. Und außerdem: In jedem Scherz steckt ein Stückchen Wahrheit (ode so ähnlich) ;)

Sich über Futuremark grundlos lustig zu machen?! - Hat er es wirklich nötig, oder steckt doch mehr dahinter? Meine Meinung dazu hast du bestimmt schon überflogen im 3DMurks03-Thread mit M.C. als unfreiwilligen Gastschreiber ;)

Werden sie denn in Kürze gut werden? - Das Problem ähnelt in mancherlei Hinsicht der Itanium Compiler-Frage. Hier geht es um den Ruf der Treiber...

Ich stimme zu. Doom3 bleibt eine Spekulation. Fest steht wohl: Nicht alles im NV30-Pfad geschieht mit FP32. Wieviel davon FP16 oder gar Integer bleibt zunächst ungeklärt. Viel Spielraum für NV wäre hier sicherlich vorhanden. Spielt vermutlich visuell keine Rolle. Dafür ist Doom3 noch zu sehr für Integer-PS ausgelegt.

Nun IMHO:
Die FX ist in vielerlei Hinsicht der GF4 ähnlicher als der R300 dem R200!
NV gibt quasi selbst zu(Quelle Beyond3D Q&A), daß für DX8(PS1.1) eine schnelle GF4 (meine Worte) zum Einsatz kommt. Der R300 hingegen beißt sich immer mit mind. FP24 durch! ohne dabei gegenüber Int 1.4(R200) wesentlich zu schwächeln!

R.
V.

ShadowXX
2003-03-05, 07:45:19
Soweit ich weiss hat JC gesagt das alles im nv30-Path mit FP16 läuft, nix FP32....(jetzt von deiner Integer-Vermutung mal abgesehen.)

Ich bin übrigens auch schon länger deiner Meinung das die fx nur eine gf4 mit cineFX-Einheit ist. (Der gf4 Teil ist natürlich angepasst und verändert/verbessert worden....).

Den 50% Performancesprung der fx bei 3DMurks2003 lässt sich meiner Meinung nach nicht mit verbesserten Shadern erklären, allerdings auch nicht mit PS1.4 über Integer (glaub auch nicht das nv die Register Combiner so verändert hat.....).

Ich würde gerne mal sehen wie sich eine "verbesserte" gf4 auf 500/1000Mhz beim Futuremark machen würde....

Wenn ich D.Kirk richtig einschätze gibt es im gffx sehr wahrscheinlich möglichkeiten von "aussen" zu bestimmen mit welcher genauigkeit die fp-Einheiten rechnen sollen, egal was der Treiber/Programmierer antwortet.(incl. eines in HW-Emulierten int-pfades.)
Zweite möglichkeit:
Die cineFX-Engine kann zusätzlich zu den fp-Einheiten auch die (immer noch verbauten) intergereinheiten benutzen....
Also Dx9 nach Dx8 berechnen.....hmmmmmm

@Demirug
wenn die fp-Einheiten tatsächlich integerrechnung beherschen, dann wird das definitiv schneller gehen als die fp-berechnungen und die Zeit zum Konvertieren kannst du dir schenken speziell wenn dies in HW geschiet.

MfG
J.S.Shadow

Demirug
2003-03-05, 07:48:50
Virtual, das es mit 3 Texture-Schichten auch was ausmacht ist nicht offiziel bestätigt. Und es gibt ja durchaus eine Technische Lösung die sich wirklich nur beim Singletexturing auswirkt. Aber dieser Punkt bedarf durchaus noch einer genauen Analyse.

Matts komentar mal wieder. Er meinte damit nicht das man einfach mal schnell die 1.4 Shader gegen 1.1 Shader austauscht sonder das ganze Renderverfahren umstellt soll heisen komplett andere Vertex und Pixelshader benutzt.

Wenn es nur darum ginge das der Test nur die 1.1 Shader benutzten soll müssten sie dem Test ja nur vormachen das sie mehr als 1.3 können. Beim 4 test ginge das aber nicht mehr weil dieser kein Fallback hat. Ansonsten ist das umbiegen von einem Singlepass Renderlauf in einen Multipass lauf gar nicht so einfach zu machen wenn man am ende möchte das es auch wirklich schneller wird.

Die Wahrheit in dem Scherz liegt darin das Matt wirklich recht hat. Um den Test auf jeden Fall zu gewinnen muss man das Renderverfahren ändern.

Wie schnell die Treiber bessere interne Compiler bekommen kann ich natürlich nicht sagen. Für die Spieler wird das aber auch erst dann relevant wenn es Spiele gibt welche die neuen FP-Shader auch benutzten. Ich vermute mal das NVIDIA im Moment fleisig Shader aus Betaengines analysiert.

Demirug
2003-03-05, 08:00:16
Originally posted by ShadowXX
Wenn ich D.Kirk richtig einschätze gibt es im gffx sehr wahrscheinlich möglichkeiten von "aussen" zu bestimmen mit welcher genauigkeit die fp-Einheiten rechnen sollen, egal was der Treiber/Programmierer antwortet.(incl. eines in HW-Emulierten int-pfades.)
Zweite möglichkeit:
Die cineFX-Engine kann zusätzlich zu den fp-Einheiten auch die (immer noch verbauten) intergereinheiten benutzen....
Also Dx9 nach Dx8 berechnen.....hmmmmmm

Nach dem durchlaufen der fp-Einheiten kann man bis zu 4*32 Bit Farbwerte noch durch 8 Register combiner States laufen lassen. Das steht aber schon lange in der OpenGL Spec zu CineFX.

@Demirug
wenn die fp-Einheiten tatsächlich integerrechnung beherschen, dann wird das definitiv schneller gehen als die fp-berechnungen und die Zeit zum Konvertieren kannst du dir schenken speziell wenn dies in HW geschiet.

MfG
J.S.Shadow

Bei einer CPU macht die Konvertierung (int2fp und fp2int) auch direkt die Hardware und sie ist nicht wirklich schnell dabei.

Wenn die Integerberechung in den FP-Einheiten abläuft wie soll man da schneller werden? IMHO läuft das ganze einfach so ab das man eben nur mit der Mantisse rechnet und den Exponent nicht berücksichtigt aber schneller muss es dadurch nicht werden. Wenn es wirklich schneller als fp16 währe hätte man das den Entwicklern gegenüber schon durchblicken lassen.

ShadowXX
2003-03-05, 08:45:57
@Demirug

bei letzterer Annahme setze ich vorraus, das nv die cineFX-Einheit speziell auf diesen Fall vorbereitet hat =
eine in HW verbaute "Speed"-Lösung zur Nutzung von int stat fp.
Für den Programmierer nach aussen sieht es weiter wie fp16/32 aus.
(besser gesagt er merkt es einfach nicht)

Werbung würde nv damit bestimmt nicht machen, auch nicht bei den Programmierern, denn nv will ja das die gffx als Krone der Grafikkartenschöpfung angesehen wird.(und es würde bestimmt nicht nv ruhm mehren wenn Ihre Geschwindigkeitszuwächse über so was zustandekommen....)

MfG
J.S.Shadow

Demirug
2003-03-05, 09:39:19
ShadowXX,

Früher oder später bekommen die Entwickler fast alles gesagt was auswirkungen auf die Performances hat.

Es ist aber auf Beyond3d ein neues Interview aufgetaucht:

http://www.beyond3d.com/previews/nvidia/gffxu/index.php?p=24

Dort gibt es wieder mal ein paar neue Details um andere Sache drückt man sich leider immer noch um eine klare Aussage.

Zusammengefasst:

Die maximal 4 Farb-Pixel pro Takt (in einem 2x2 Raster) werden bestätigt. Ebenso bestätigt man die 8 Z/Stencil Pixel (2* 2x2 Raster).

Um die Aussage ob es für das Shading nun 4 Pipelines a 2 TMUs oder 8 Pipelines a 1 TMU sind hat man sich wieder gedrückt in dem man es vermieden hat von einer ungeraden Anzahl von Texturen zu sprechen. (sehr verdächtig ;))

Der wohl interesanteste Teil sind die Aussagen welche mehr Details über die Pixelpipelines enthalten. Es werden zwar nach wie vor keine richtigen Zahlen genannt aber man bestätigt das es im NV30 eigenständige Integer Rechenwerke gibt. Es wird ebenfalls bestätigt das ein Mix aus FP und Int Anweisungen in einem "neuen" Shader die Performances erhöht. Man spricht von "twice the throughput". Das läst aber eigentlich nur den schluss zu das die FP und Int Rechenwerke gleich schnell sind. Wer aber die alten Register Combiner kennt weiss das diese in der Lage sind auch komplexere Aufgaben in einem "virtuellen" Takt zu erledigen. Diese Fähigkeiten lassen sich aber im Moment wohl nur begrenzt in Verbidnung mit den neuen Shadernprogrammen nutzen. Die alten Extension haben aber wohl schon vollen Zugriff auf diese Funktionen.

Meine Vermutung ist also das die integer Einheiten nicht einfach hinter die FP Einheiten gesetzt wurde sondern parrallel zu den FP einheiten sitzen und sich mit diesen die Register und den Programmspeicher teilen. Bei dieser Konstruktion kann ich mir auch jetzt gut vorstellen was es so kompliziert macht die Shader dafür umzusetzten.

Auch bei Virtual muss ich jetzt wohl abbitte leisten. Wenn man die Integer Rechenwerke in die neue Pipeline integriert hat fallen mit hoher wahrscheinlichkeit viele der Begrenzungen (Programmelänge, Texturesampler, freies rechnen mit Texturecoordinaten) die verhindert haben das der NV25 PS 1.4 beherscht einfach weg. Und wenn die Treiber jungs gut waren haben sie für den 3dmark wohl schnell von Hand ein paar Shader gebaut die sowohl die FP wie auch die Int Einheiten einer Pipeline gleichzeitig nutzen können.

Virtual
2003-03-05, 15:54:31
Originally posted by Demirug
Virtual, das es mit 3 Texture-Schichten auch was ausmacht ist nicht offiziel bestätigt. Und es gibt ja durchaus eine Technische Lösung die sich wirklich nur beim Singletexturing auswirkt. Aber dieser Punkt bedarf durchaus noch einer genauen Analyse.

Dann lies dir mal in Beyond3D's-Preview den Abschnitt "Theoretical Throughput" durch. Eine ungerade Anzahl bei zwei Texture-Sampling Unit pro pipe und bilinearen Filtering ist vermutlich nicht vorteilhaft für die FX. Ebenso gilt: Je mehr Schichten desto geringer die Auswirkung. Sicher ist bei bilinear Single-Texturing die Wirkung am deutlichsten zu sehen. Hier stimmen wir überein. Bei drei Layern/bilinear möchtest du aber erst einen Beleg dafür, obwohl die Theorie es nahe legt!
Streng genommen müßtest du dann auch fordern, daß für jede allgemein anerkannte Theorie in der Physik sämtliche denkbaren Experimente als Beweis der Korrektheit durchgeführt werden müßten. Mir persönlich reicht eine sinnvolle Anzahl an bestätigenden Experimenten zur Bestätigung der Theorie (TheInquirer/Beyond3D). Anschließend sind die Folgerungen auch als Korrekt anzunehmen: 3-Layer/bilinear->immer noch merkbar? ungünstig!

Matts komentar mal wieder. Er meinte damit nicht das man einfach mal schnell die 1.4 Shader gegen 1.1 Shader austauscht sonder das ganze Renderverfahren umstellt soll heisen komplett andere Vertex und Pixelshader benutzt.

OK! - Mein letzter Kommentar hierzu: Beides ist möglich und dazu wahrscheinlich in nicht näher bekanntem Ausmaß geschehen! - Er(repräsentativ) hat das Renderingverfahren ausgetauscht(diplomatisch->optimiert) UND die grotten-langsamen 1.4 Shader über CineFX-Fließkomma ALUs gegen Int 1.1 Shader mit guter Näherung ausgetauscht. Beides ist möglich und steht NICHT im Widerspruch zueinander. Wir haben beide keinen Beweis für die eine oder anderer Variante als einzigen Weg! - Also einigen wir uns am besten salomonisch auf den Mittelweg. ;)

Wenn es nur darum ginge das der Test nur die 1.1 Shader benutzten soll müssten sie dem Test ja nur vormachen das sie mehr als 1.3 können. Beim 4 test ginge das aber nicht mehr weil dieser kein Fallback hat. Ansonsten ist das umbiegen von einem Singlepass Renderlauf in einen Multipass lauf gar nicht so einfach zu machen wenn man am ende möchte das es auch wirklich schneller wird.

Der 4. Test nutzt eine Mischung aus 2.0 und 1.4! 2.0 muß über CineFX(FP16?) laufen und was Multipass betrifft, so werden die Mitarbeiter der Treiber-Abteilung von NV sicher nicht zu unrecht so hoch gerühmt!

Die Wahrheit in dem Scherz liegt darin das Matt wirklich recht hat. Um den Test auf jeden Fall zu gewinnen muss man das Renderverfahren ändern.

Betreite ich nicht. Nur die Art und Weise wie der "Scherz" und wie sich NV generell über den Murks ausläßt, ist nicht akzeptabel. Grundsätzlich liegt hier ein allgemeineres Problem vor: Synthetische Tests sind nicht zum Gewinnen oder Verlieren geeignet, sondern sollten etwas über die Architektur aussagen bzw. deren Stärken/Schwächen aufzeigen und sie sagen grundsätzlich gar nichts über die tatsächliche Performance einer GPU in Spielen aus. Insbesondere NV hat sich in der Vergangenheit diesbezüglich falsch verhalten und den 3DMurks01 zum Performance-Maßstab erkoren. Nun verliert man beim Murks03 den vorgegebenen Renderpfad und schon ist der Test nur noch Dreck. Erkennst du die Doppelzüngigkeit?!

Wie schnell die Treiber bessere interne Compiler bekommen kann ich natürlich nicht sagen. Für die Spieler wird das aber auch erst dann relevant wenn es Spiele gibt welche die neuen FP-Shader auch benutzten. Ich vermute mal das NVIDIA im Moment fleisig Shader aus Betaengines analysiert.
Und hoffentlich einen Compiler baut, der ohne individuelle und manuelles Anpassen pro Game den (fast) optimalen Shader zusammensetzt. Falls dies NV nicht zufriedenstellend gelingt, so könnte sein "Scherz" doch noch schmerzliche Wahrheit werden!

G.
V.

Demirug
2003-03-05, 17:04:18
Virtual, was die Texturen angeht denke ich können wir uns darauf einigen das der FX Chip eine ungerade anzahl von bi-Texturen pro Pixel in Verbindung mit einem einfachen Shader (nur Texturen blenden) nicht mag. Warum das so ist will ich jetzt mal noch offenen lassen.

Meine neueste Vermutung bezüglich der 3dmark optimierung steht im 3dmark thread.

Ja der Test 4 benutzt 2.0 Shader (2 von ingesamt 10) bei den anderen 8 könnte wieder die PS 1.4 3dmark optimierung greifen.

Beim 2001 wurde wenigstens noch eine Game engine benutzt und die Verfahren waren nicht ganz so abwägig. In als Performancesmassstab zu sehen was aber nicht OKund aus diesem Grund finde ich es auch OK das NVIDIA sich jetzt davon distansiert. Wenn es auch primär aus den falschen gründen geschen sein wird.

Zum Thema Synthetische Tests:Ich liebe solche Tests wenn sie gut gemacht sind. Allerdings sind die Tests im 3dmark davon weit entfernt weil sie zu viele Dinge aufeinmal machen.

Ja der Compiler ist wichtig aber bei den PS 1.1-1.3 sowie der DX7 Pipeline hat man da gute arbeit geleistet und man wird das bis die ersten Spiele kommen die mit diesen Shadern arbeiten sicherlich noch einiges rausholen.

Virtual
2003-03-05, 21:41:41
Originally posted by Demirug
Virtual, was die Texturen angeht denke ich können wir uns darauf einigen das der FX Chip eine ungerade anzahl von bi-Texturen pro Pixel in Verbindung mit einem einfachen Shader (nur Texturen blenden) nicht mag. Warum das so ist will ich jetzt mal noch offenen lassen.

Meine neueste Vermutung bezüglich der 3dmark optimierung steht im 3dmark thread.

Ja der Test 4 benutzt 2.0 Shader (2 von ingesamt 10) bei den anderen 8 könnte wieder die PS 1.4 3dmark optimierung greifen.

Beim 2001 wurde wenigstens noch eine Game engine benutzt und die Verfahren waren nicht ganz so abwägig. In als Performancesmassstab zu sehen was aber nicht OKund aus diesem Grund finde ich es auch OK das NVIDIA sich jetzt davon distansiert. Wenn es auch primär aus den falschen gründen geschen sein wird.

Zum Thema Synthetische Tests:Ich liebe solche Tests wenn sie gut gemacht sind. Allerdings sind die Tests im 3dmark davon weit entfernt weil sie zu viele Dinge aufeinmal machen.

Ja der Compiler ist wichtig aber bei den PS 1.1-1.3 sowie der DX7 Pipeline hat man da gute arbeit geleistet und man wird das bis die ersten Spiele kommen die mit diesen Shadern arbeiten sicherlich noch einiges rausholen.

Das kann ich so stehen lassen!
Weiter an anderer Stelle ...

G.
V.