NV3x und die schlechte PS 1.4 und 2.0 Leistung.

[Demirug]

Wie ich schon an andere Stelle erwähnt habe kommt die NV3x Rheie nicht sonderlich gut mit PS 1.4 und PS 2.0 Code zurecht. Dagegen haben die R3xx Chips der Konkurrenz kaum Probleme damit. Der Grund dafür ist in der unterschiedlichen Architektur der Pixelshader zu suchen.

ATI benutzt ein "Doppelloopback Sequenz" Verfahren welches auch schon beim R200 zum einsatz kamm. nVidia dagegen hat ein "Singelloopback Parallel" Verfahren welches im Consumergrafikbreich neu ist.

Das ATI Verfahren:

Im wesentlichen verfolgt ATI immer noch den alten Weg allerdings mit entsprechenden Erweiterungen (Loopbacks) um den Anforderungen von PS 1.4/2.0 gerecht zu werden.


Tri Setup
|
-->-->--
| |
| -->--
| | |
| | TMU
| | |
| --<--
| |
| -->--
| | |
| | ALU
| | |
| --<--
| |
--<--<--
|
AA-Einheiten


Wie man sieht befinden sich sowohl um die TMU wie auch die ALU eine Loopbackeinheit und eine zusätzliche Loopbackeinheit umschliesst die beiden anderen. Diese Struktur entspricht genau den Anforderungen die für PS 1.4 und 2.0 gelten. Dort wird ja gefordert das eine Anzahl von x Texturesampels aus dem Speicher erzeugt wird danach sollen y ALU-Instruktionen ausgeführt werden. Diese beiden Aktionen sollen dann noch mehrfach wiederholt werden. Die unterschiede zwischen 1.4 und 2.0 liegen im wesentlichen darin das die maximalen Loopbackdurchläufe bei 2.0 wesentlich grösser sind, die ALUs mehr unterschiedliche Befehle verstehen und mit Fliesspunktzahlen rechnen.

Vom Shadercode her sind die Unterschide ein bischen grösser aber das ist jetzt hier nicht so wichtig weil sich damit die Shaderprogrammier herumschlagen sollen. Es soll nur soviel gesagt werden das sich in einem guten 1.4 und 2.0 Shadercode Blöcke von Texturesampleanweisungen und Blöcke von ALU-Anweisungen sich immer abwechseln. Und genau solchen Code erzeugt zum Beispiel der Shadercompiler von MS den ATI gerne empfiehlt.

Ein letzer abschliessender Absatz bevor wir zum Mitbewerber kommen. Um die TMU und die ALU auch wirklich wie von ATI angeben parralel zu betreiben ist es erforderlich das in der TMU und der ALU an zwei verschiedenen Pixel gearbeitet wird. So wechseln sich also immer zwei Pixel in der benutzung von TMU und ALU ab. Die maximale Performance wird erreicht wenn der Texturesampleblock genauso viele Takte zur Ausführung braucht wie der folgende Block mit den ALU-Anweisungen. Da man aber ja gerne mit viel AF arbeitet brauchen die TMUs gerne viel mehr Takte als die ALU-Anweisungen danach.

Das nVidia Verfahren:

Der Ansatz von nVidia ist einer CPU ähnlicher.



Tri Setup

|
-->-->-->--
| |
| --------
| | |
| TMU(s) ALU(s)
| | |
| --------
| |
--<--<--<--
|
AA-Einheiten


Es gibt nur eine Loopbackeinheit die alle TMUs und ALUs einer Pipeline umschliesst. Die Einheiten arbeiten alle am gleichen Pixel. Man sollte also schnell erkennen das wenn man diese Architecktur mit einem für 1.4 oder 2.0 optimierten Shader füttert wechselweise immer nur die TMUs oder die ALUs arbeiten können wenn man sich genau an die im Shadercode vorgebenen Rheienfolge hält. Das gleiche Problem kennt man bei den CPUs ja auch seit es die u und v Pipeline gibt. Aus diesem Grund muss nVidia die Shaderprogramme so umsortieren das sie möglichst alle parallen Einheiten bei jedem Pixeltakt auch mit Daten und Arbeit versorgen können. Derzeit gibt es dafür noch keine gute und allgemeine Lösung im Treiber. Deshalb greift man auf eine Datenbank zurück die für bekannte 1.4 und 2.0 Shader die für den Chip passende Codefolge enthält die den Shader mit der geringsten Anzahl von Pixeltakten ausführen kann. Nimmt man jetzt dem Treiber die Möglichkeit die Datenbank einzusetzen (wie mit dem Patch 330 des 3dmark geschehen) fällt die Leistung natürlich rapide ab.

Ich hoffe die Unterschiede einigermasse Verständlich erklärt zu haben.

EDIT: Die NV3x Chips sind wohl doch etwas anderaufgebaut. Update: http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&postid=991735#post991735

[LovesuckZ]

Gibt es eine plausible Erklaerung, warum Nvidia den deutlichen komplexeren Weg gegangen ist, und wie koennte sich das Positiv in Zukunft fuer alle FX Karten auswirken?

[Demirug]

Originally posted by LovesuckZ
Gibt es eine plausible Erklaerung, warum Nvidia den deutlichen komplexeren Weg gegangen ist, und wie koennte sich das Positiv in Zukunft fuer alle FX Karten auswirken?

Ja man braucht eigentlich diese CPU artige Architektur um die PS 3.0 noch effektiv abarbeiten zu können. Wäre NV nicht schon jetzt darauf umgeschwenkt hätten sie erst die für die PS 2.0 notwendige Architektur entwickeln müssen um diese dann gleich wieder bei der nächsten Generation wegzuwerfen. Doppelte arbeit.

Bei den 1.4 und 2.0 Shader wird sobald man einmal das Codeumsetzung problem im Griff hat die Ausnutzung der vorhandnen Resourcen relative gut sein soweit die Shader das zulassen.

[mapel110]

woher hast du diese chipinternas ?

[Chris Lux]

Originally posted by Demirug
Das gleiche Problem kennt man bei den CPUs ja auch seit es die u und v Pipeline gibt.

was sind nach deiner bezeichnung diese u und v einheiten?

[Demirug]

Originally posted by Hans Ohlo


was sind nach deiner bezeichnung diese u und v einheiten?

Ich meine die u und v Pipeline beim Pentium.

In diesem Blockdiagram zu sehen: http://www.wiwi.uni-rostock.de/~vwi-hro/dokumente/vwi/Rechnerarchitektur/KAP6.PDF

[Demirug]

Originally posted by mapel110
woher hast du diese chipinternas ?

Aus den Entwicklerunterlagen der Chips. Man muss dafür nur zwischen den Zeilen lesen können.

[LovesuckZ]

Originally posted by Demirug
Bei den 1.4 und 2.0 Shader wird sobald man einmal das Codeumsetzung problem im Griff hat die Ausnutzung der vorhandnen Resourcen relative gut sein soweit die Shader das zulassen.

Bedeutet das, dass Nvidia ne kleine KI in den Treiber steckt, der den COde erkennt und dann umsetzt?

[Exxtreme]

Originally posted by LovesuckZ


Bedeutet das, dass Nvidia ne kleine KI in den Treiber steckt, der den COde erkennt und dann umsetzt?
So ähnlich. Es wird "so eine Art optimierender Compiler"[TM] sein.

[Demirug]

Originally posted by LovesuckZ


Bedeutet das, dass Nvidia ne kleine KI in den Treiber steckt, der den COde erkennt und dann umsetzt?

Als KI würde ich das nicht bezeichen. Eher als Crosscompiler welcher die für nv ungünstigen Shader so umbaut das sie besser hamonieren. Grosse Teile des dafür notwendigen Codes kommen dabei vom Cg Projekt.

[LovesuckZ]

Originally posted by Demirug
Als KI würde ich das nicht bezeichen. Eher als Crosscompiler welcher die für nv ungünstigen Shader so umbaut das sie besser hamonieren. Grosse Teile des dafür notwendigen Codes kommen dabei vom Cg Projekt.

Inwieweit kann dieses Vorgehen bei einen Shader wirken, der nicht durch Cg hervorgerufen wurde?

[Demirug]

Originally posted by LovesuckZ


Inwieweit kann dieses Vorgehen bei einen Shader wirken, der nicht durch Cg hervorgerufen wurde?

Das spielt dabei keine Rolle. Cg benutzt einen 3 Phasen Compiler.

1. Phase: Cg Sourcecode wird in einen zwischencode übersetzt.
2. Phase: Der Zwischencode wird allgemein optimiert und für Phase 3 vorbereitet.
3. Phase: Der Zwischencode wird in das gewüschte Profil übersetzt und nocheinmal Profilspezifiach optimiert.

Wird das ganze jetzt ihm Treiber benutzt werden die 1 und 3 Phase ausgetauscht. Der Zwischencode wird also aus dem übergeben Shadercode erzeugt (das ist sehr einfach) und das Profil in Phase 3 ist dann eben kein Shaderprofil mehr sondern ein Chipprofil.

EDIT: PS: Bei einem vorher mit Cg erstellten Shader der ja schon voroptimiert ist geht das ganze etwas schneller.

[LovesuckZ]

Danke, dass macht die Sache viel klarer.

[egdusp]

Bedeutet das, dass ATI bei ihrem PS 3.0 Chip eine komplett neue Architektur benutzen müssen, während NV die NV3x Architektur nur aufbohren muss? (würde auch die Verschiebung/Änderung des R400 erklären)
Hat ATI bei ihren PS 3.0 dann auch die Probleme die NV momentan hat?

Besteht nicht die Gefahr, dass ATI und M$ durchsetzten den HLSL Shadercode zu benutzen, und ATI dann bei Umsteig auf PS 3.0 alt aussieht, da sie keine dynamische Optimierung im Treiber haben?
Oder kann ATI vom Cg Projekt benötigte Teile mibenutzen? Ist ja teilweise OpenSource. Ich bezweifle das aber.

mf
egdusp

[robbitop]

" wechselweise immer nur die TMUs oder die ALUs arbeiten können wenn man sich genau an die im Shadercode vorgebenen Rheienfolge hält."
@Demi
sollten TMU und ALU nicht ab NV35 entkoppelt sein und dadurch deutlich mehr geschwindingkeit in punktio 1.4/2.0 Intruktionen haben?



Diese Architektur hat eben auch den Vorteil, dass man nicht soviele Transistoren benötigt, wenn man die Rechenleistung erhöhen möchte.
Um 16 biTexel/Takt hinzubekommen bräuchte NV 8 Pipelines ATi 16. Ich denke hier dürfte sich das recht stark bemerkbar machen...vorher nicht unbedingt.

[Demirug]

Originally posted by egdusp
Bedeutet das, dass ATI bei ihrem PS 3.0 Chip eine komplett neue Architektur benutzen müssen, während NV die NV3x Architektur nur aufbohren muss? (würde auch die Verschiebung/Änderung des R400 erklären)
Hat ATI bei ihren PS 3.0 dann auch die Probleme die NV momentan hat?

Besteht nicht die Gefahr, dass ATI und M$ durchsetzten den HLSL Shadercode zu benutzen, und ATI dann bei Umsteig auf PS 3.0 alt aussieht, da sie keine dynamische Optimierung im Treiber haben?
Oder kann ATI vom Cg Projekt benötigte Teile mibenutzen? Ist ja teilweise OpenSource. Ich bezweifle das aber.

mf
egdusp

Viele Fragen ;)

Ja ATI wird wenn sie eine effektiven PS 3.0 Pipeline haben möchten auch zu einer CPU ähnlicheren Architekture übergehen müssen.

nVidia kann mit der NV3x Basis weiterarbeiten.

Mit der Verschiebung hat das aber IMHO nichts zu tun.

Ja auf ATI kämmen dann ähnlich Problem zu. Diese "Problem" müssen sie aber zum Teil auch schon für den R3xx in Verbindnung mit OpenGL 2.0 lösen.

echtes HLSL ist dabei weniger gefährlich solange man es erst beim Kunden kompiliert. Dann kann man dort in abhängigkeit des Chip einen entsprechenden Shader zur Laufzeit erzeugen. Kritisch sind im Vorfeld kompiliert oder von Hand geschriebene Shader. Bei denen müsste dann der Treiber ran.

Das die Cg Sourcen da ATI gross was helfen würde bezweifle ich mal.

[Demirug]

Originally posted by robbitop
" wechselweise immer nur die TMUs oder die ALUs arbeiten können wenn man sich genau an die im Shadercode vorgebenen Rheienfolge hält."
@Demi
sollten TMU und ALU nicht ab NV35 entkoppelt sein und dadurch deutlich mehr geschwindingkeit in punktio 1.4/2.0 Intruktionen haben?

In wie fern entkoppelt?

[Haarmann]

Demirug

Also soweit ich mir das mal zurechtlege definiert M$ eigentlich die Shader (Das liegt an deren Definitionsgewalt über DX9)... Wenn nun M$ sagte, dass idealer Shadercode so aussieht, dann ist NVs Weg zwar fortschrittlich, aber schlicht dumm, da diese Zwiebelbenchcodes offenbar so geschrieben sind, wie M$ das wollte.

Oder habe ich da etwas falsch gelesen in Deinen Postings?

[Demirug]

Original geschrieben von Haarmann
Demirug

Also soweit ich mir das mal zurechtlege definiert M$ eigentlich die Shader (Das liegt an deren Definitionsgewalt über DX9)... Wenn nun M$ sagte, dass idealer Shadercode so aussieht, dann ist NVs Weg zwar fortschrittlich, aber schlicht dumm, da diese Zwiebelbenchcodes offenbar so geschrieben sind, wie M$ das wollte.

Oder habe ich da etwas falsch gelesen in Deinen Postings?

MS hat zwar im Prinzip das letzte Wort was nun in eine DX Version aufgenommen wird und was nicht. Was die Details angeht so hört sich MS die Vorschläge der einzelnen IHVs an arbeitet dann mit den IHVs etwas einheitliches aus. Die IHVs müssen sich aber einig werden. Das Verfahren ist nicht unüblich dem was bei OpenGL gemacht wird um einheitliche Extension zu definieren. Da bei DX die IHVs aber keine möglichkeit mit eigenen Extensions ihrer Funktionalität auf jeden Fall unterzubringen ist bei DX der Druck sich zu einigen höher.

Die kleinste Shaderversion darf logischerweise der Hersteller mit der Hardware welche die meisten Einschränkungen hat bestimmen. Die anderen IHVs dürfen dann da auch noch ein bischen was wegstreichen lassen und so kommen dann die Shaderversionen zu standen. Im fallen von DX9 wurde die Spezifikation für die 2.0 Shader im wesentlichen von ATI geschrieben. Aus oben genannten Gründen braucht ATI diese Blockstruktur und NV musste in den saueren Apfel beissen und dem ganzen zustimmen.

MS hat aber inzwischen eingesehen das ihr Compiler ATI beim erzeugen von DX9 Shadern bevorzugt und das sie diesen Zustand so nicht beibehalten können ohne die Entwickler und vorallem NV zu verärgern. Die Anwort von MS auf das Problem nennt sich vs_2_a und ps_2_a. Ich darf da allerdings nicht viel dazu sagen weil der grossteil dieser Information noch nicht öffentlich ist. Nur soviel:

-MS schlägt vor für Shader HLSL zu benutzen und die Shader Chipspezifisch zu kompilieren. Entweder zur laufzeit oder schon im Vorfeld.
-das a bei ps_2_a steht nicht für ATI.

[robbitop]

@Demi
so genau blicke ich da nicht durch
Aber ich habe gehört, dass wenn die TMU arbeitet, die ALU nicht verwendet werden kann ..und das ist durch die Entkopplung nun anders.
nVidia gibt auch die PS Performance als 2x so hoch wie vorher an

[Haarmann]

Demirug

Tragischerweise hätte man dies doch am Besten gleich im Vorfeld erledigt... Nur da hat wohl keiner soweit gedacht ;).

P.S. War wohl ne Managertagung...

[Demirug]

Original geschrieben von robbitop
@Demi
so genau blicke ich da nicht durch
Aber ich habe gehört, dass wenn die TMU arbeitet, die ALU nicht verwendet werden kann ..und das ist durch die Entkopplung nun anders.
nVidia gibt auch die PS Performance als 2x so hoch wie vorher an

Jetzt weiss ich was du meinst.

Beim NV30 gibt es die Spekulation (welche durch einige Messungen untermauert wurde) das der Registerspeicher in den Pixelshader zu wenige Readports hat um gleichzeitig für die FP-ALU(s) und für die TMUs Daten bereit zu stellen. Dieses Problem soll beim NV35 nicht mehr ganz so exxtrem vorhanden sein (= mehr Readports).

[Xmas]

Original geschrieben von Haarmann
Demirug

Tragischerweise hätte man dies doch am Besten gleich im Vorfeld erledigt... Nur da hat wohl keiner soweit gedacht ;).

P.S. War wohl ne Managertagung...
Haarmann, ATI und NVidia haben ein gewisses Interesse daran, ihre Entwicklungen nicht frühzeitig der Konkurrenz bekannt zu geben. Gewisse Grundlagen werden zwar ausgemacht, aber solche Details der Pipeline werden nicht ausgetauscht.

[Demirug]

Original geschrieben von Haarmann
Demirug

Tragischerweise hätte man dies doch am Besten gleich im Vorfeld erledigt... Nur da hat wohl keiner soweit gedacht ;).

P.S. War wohl ne Managertagung...

Im Bezug auf DX9 ist sowieso einiges sehr merkwürdig abgelaufen.

Ursprünglich sollten ja nur die Shaderversionen 2.0 enthalten sein. Da es da aber schon die Festlegung kein neues DX vor Longhorn gab und MS sich wohl schon bewusst war das Longhorn doch etwas länger dauert musste eben noch alles was einigermassen fertig geplannt war schnell ein gebaut werden. Was die Shader über 2.0 angeht so ist man damit ja genaugenommen immer noch nicht fertig.

[Haarmann]

Xmas

Klaro, aber gegenüber M$ sollte man Tacheles reden, wenn man weiss, dass man sonst am Arsch is wie NV nun...

Demirug

Eindeutiger Fall von Managerismus eben aus meiner Sicht. Aber durchaus interessant, dass sogar M$ langsam mit anfängt... ich würde M$ Aktien verkaufen ;).

[mapel110]

fehlt nurnoch, dass m$ anfängt, selber graka chips zu bauen ;)

[betasilie]

Original geschrieben von Demirug
-MS schlägt vor für Shader HLSL zu benutzen und die Shader Chipspezifisch zu kompilieren. Entweder zur laufzeit oder schon im Vorfeld.
-das a bei ps_2_a steht nicht für ATI.
Sehr interessant.

[betasilie]

Original geschrieben von mapel110
fehlt nurnoch, dass m$ anfängt, selber graka chips zu bauen ;)
Wer weiß ob NV dazu nicht irgendwann gezwungen ist. Bei der X-Box2 ist das letzte Wort noch nicht gesprochen und spätestens bei der X-Box3 wäre imo das garnicht unwahrscheinlich.

[Demirug]

Original geschrieben von mapel110
fehlt nurnoch, dass m$ anfängt, selber graka chips zu bauen ;)

Grafikkarten (oder besser Multimediakarten) haben sie schon mal gebaut. Zumindestens der Prototyp war fertig. Die Technik war hochgradig Interesant und deshalb teilte sie wohl das Schicksal mit anderen Interesanten Technicken.

[Exxtreme]

Original geschrieben von Demirug
Die Technik war hochgradig Interesant und deshalb teilte sie wohl das Schicksal mit anderen Interesanten Technicken.
Talisman?

P.S.
Haarmann,

traust du dich auch wieder in die Hardware-Ecke?

;)

[Demirug]

Original geschrieben von Exxtreme
Talisman?

Genau.

[Exxtreme]

Hmmm, wieviele Renderpipelines werden benutzt beim Einsatz von Pixelshader-Programmen?

[Demirug]

Original geschrieben von Exxtreme
Hmmm, wieviele Renderpipelines werden benutzt beim Einsatz von Pixelshader-Programmen?

Alle die zur Ausführung des Programms in der Lage sind. Mehr weiss ich auch nicht. Es gibt bisher noch keine Chipspezifischen Performanceguides für die FX Rheie.

[Hauwech]

Kann man so Pi mal Auge sagen was dieser hmm 'Patch' seitens MS fuer nVidia-Karten an Leistung unter P1.4 und 2.0 bringen wird? Fuer 2% mehr Leistung werden die das doch wohl nicht bringen (koennte ich mir vorstellen), aber 10 bis 20% (oder noch mehr?) schon.

[ow]

Original geschrieben von Hauwech
Kann man so Pi mal Auge sagen was dieser hmm 'Patch' seitens MS fuer nVidia-Karten an Leistung unter P1.4 und 2.0 bringen wird? Fuer 2% mehr Leistung werden die das doch wohl nicht bringen (koennte ich mir vorstellen), aber 10 bis 20% (oder noch mehr?) schon.


Ich denke mal eher so ab 30% mehr, wenn demi mit seiner 'Architektur-Prognose' nicht zuweit daneben liegt.
Die derzeitig vom MS-Compiler erzeugten Shader duerften einen NV3x auf kaum mehr als halber Kraft laufen lassen.
Inwiefern NV allerdings jetzt schon treiberintern die Shader erkennt und sie auf die NV3x Architektur umbastelt duerfte unbekannt sein.

[Haarmann]

Exxtreme

Technologie lese ich immer gerne mit... Muss ja ned immer was dazu sagen ;).

Die Graka Ecke lasse ich aber weg, da werd ich nie schlau aus Leuten, die noch immer an NV glauben ;).

[123]

Was hat es eigentlich mit den 3 PS-Operationen *Takt*Pipe auf sich. Die Nv-Karten können angeblich nur 2 Ops. Ist da nicht schon ein Performanceunterschied wahrscheinlich?!

[Demirug]

Original geschrieben von 123
Was hat es eigentlich mit den 3 PS-Operationen *Takt*Pipe auf sich. Die Nv-Karten können angeblich nur 2 Ops. Ist da nicht schon ein Performanceunterschied wahrscheinlich?!

Die 3 PS Operationen pro Takt / Pipe beim R300 setzten sich wie folgt zusammen.

1. 1 Texturesampleanweisung (nur bilinear bessere Filter brauchen mehr Takte)
2. 1 Vector3 Operation
3. 1 Skalar Operation.

Alternativ kann auch folgendes ausgeführt werden.
1. 1 Texturesampleanweisung
2. 1 Vector4 Operation.

Diese Zahlen stellen allerdings das maximal mögliche dar. In der Praxsis gibt es noch Randbedingungen die eine ständige maximale Auslastung verhindern.

Bei den NV3x Chips ist das ganze nun eine Spur komplexer. Das Hauptproblem ist das nVidia bis zum heutigen Tag noch keine Zahlen bezüglich der Anzahl der Recheneinheiten und der der möglichen parallen Nutzung veröffentlicht hat. Daher gibt es dazu auch eine Vielzahl von Spekulationen.

Für den NV35 geht man momentan von folgendem aus:

1. 2 Texturesampleanweisungen
2. 2 Vector4 Operationen

oder alternativ

1. 3 Vector4 Operationen

In wie weit das wirklich den Tatsachen entspricht ist aber bisher nicht bekannt.

Das Hauptproblem der NV3x Chips scheint auch nicht unbedingt die Rechenleistung zu sein. Aller Untersuchungen die bisher gemacht wurden deuten auf ein Chip Interenes Bandbreiten problem hin. Die Verbidnung zwischen dem Registerfeld und den TMU/ALUs scheint nicht in der Lage zu sein alle Einheiten bei jedem Takt mit genügend fp32 Werten zu versorgen. Bei den unterschiedlichen Chips scheint diese Problem unterschiedlich stark vorhanden zu sein.

[aths]

Demirug,

ich dachte bisher, PS.3.0 seien praktisch PS.2.0, nur eben mit allen Caps? Was ist denn von der Idee (bzw. "Philosophie") beim 3.0-er anders? Mit 2.0 kann man doch schon beliebig im Shader sampeln oder verrechnen, was bringt 3.0 als neuen Vorteil?

[Demirug]

Original geschrieben von aths
Demirug,

ich dachte bisher, PS.3.0 seien praktisch PS.2.0, nur eben mit allen Caps? Was ist denn von der Idee (bzw. "Philosophie") beim 3.0-er anders? Mit 2.0 kann man doch schon beliebig im Shader sampeln oder verrechnen, was bringt 3.0 als neuen Vorteil?

Ja PS 3.0 sind PS 2.0 mit allen Caps. Aber das sind eben eine ganze Menge Caps.

Das mit dem beliebig sampeln ist nur die halbe wahrheit. In Wirklichkeit gibt es bei den reinen 2.0 Shader noch eine Einschränkungen. Ich schrieb ja oben das ein guter 2.0 Shader immer aus einem Block Sampelanweisungen und dann einem Block Rechenanweisungen besteht. Das ganze dann immer im wechsel. Und genau diese Wechsel sind das Problem. Bei den 2.0 Shadern ist dieser Wechsel nur 4 mal erlaubt bei 3.0 unendlich oft (solange man eben noch anweisungsslots hat).

Der Hauptunterschied zwischen den 2.0 und den 3.0 Shadern ist aber das dynamische Branching und das wird sehr wichtig in Verbindnung mit prozeduralen Texturen.

Die 2.0 Shader erlauben den Einsatz von Prozeduralen Texturen allerdings mit einem grossen Nachteil. Wenn ein Gegenstand aus mehreren Materialen besteht muss man entsprechen in mehrere Teile zerlegen und getrennt rendern das bedeutet mehr DrawCalls (=Schlecht). Mit den 3.0 Shadern kann man nun das zu verwendende Material in die Vertexdaten packen und dann im PS aufgrund dieser Information dynamisch die richtigen prozeduralen Texture benutzten. Das ganze Objekt kann dann mit einem einzigen DrawCall übergeben werden (=gut).

[aths]

Demi,

ich verstehe noch immer nicht, wieso die NV-Shader für die Zukunft besser sein sollen :bonk: und warum, was für 2.0 noch schnell ist, für 3.0 nicht mehr brauchbar sein soll.

[Gästle]

Original geschrieben von Demirug

Für den NV35 geht man momentan von folgendem aus:

1. 2 Texturesampleanweisungen
2. 2 Vector4 Operationen

oder alternativ

1. 3 Vector4 Operationen



Bei einem 4-Pipe-Design wie dem NV/35 ist das doch auch nicht der Hit, oder?

Sieht doch schon in der Theorie so aus, als wären die Karten mit R300 durch ihre 8 Pipes schneller bei Pixelshadern, wenn auf beide Architekturen anepasst würde.

[Demirug]

Original geschrieben von Gästle
Bei einem 4-Pipe-Design wie dem NV/35 ist das doch auch nicht der Hit, oder?

Sieht doch schon in der Theorie so aus, als wären die Karten mit R300 durch ihre 8 Pipes schneller bei Pixelshadern, wenn auf beide Architekturen anepasst würde.

Die Angaben bezogen sich wie beim R300 auf jeweils eine Pipeline.

Wenn du die Theorie bemühen möchtest musst du aber auch noch alles andere in betracht ziehen und nicht nur auf die maximale Anzahl von möglichen Operationen schauen.

[Demirug]

Original geschrieben von aths
Demi,

ich verstehe noch immer nicht, wieso die NV-Shader für die Zukunft besser sein sollen :bonk: und warum, was für 2.0 noch schnell ist, für 3.0 nicht mehr brauchbar sein soll.

Versuchen wir es einmal so:

Bei der ATI Architekture befindet sich ein Pixel immer in einem von zwei Modies.
1. Texture Read
2. Calculate.

Beim R300 kann jeder dieser Modies 5 mal eingenommen werden. Begonnen wird immer mit "Texture Read". Damit die Einheiten möglichst effektiv genutzt werden können befinden sich immer 2 Pixel in einer Pipeline und zwar mit gegensätzlichem Modus. Dadurch ergibt sich aber das sich die beiden Pixel gegenseitig blockieren können.

Als einfaches Beispiel lassen wir folgenden Shader auf die Pipeline loss.

4 Texture Read
2 Calulate
2 TextureRead
6 Calculate

Wenn ich nun den ATI Performanceguide richtig interpretiere bestimmt der grösste Block die Anzahl von Takten die zwischen den Modie Wechsel liegen.

In unserem Fall also 6. Der Shader würde demnach 4 * 6 Takte für 2 Pixel brauchen gleich 12 Takte pro Pixel.

Wenn der Treiber einigermassen Trickreich ist könnte er den Shader etwas umbauen:

4 TR
2 Calc
2 TR
4 Calc
0 TR
2 Calc

6*4 sind immer noch 12 Pixel pro Takt. bringt aber nichts

Aber wir können ja noch ein bischen weiter aufteilen

2 TR
0 Calc
2 TR
2 Calc
2 TR
2 Calc
0 TR
2 Calc
0 TR
2 Calc

10*2 = 10 Takte pro Pixel. 2 Takte gespart.

Man erkennt aber das bei einer ungleichmässigen Verteilung von Texture Read und Calculate Lücken entstehen solange man das Limit von 10 Blöcken noch nicht erreicht hat kann man da noch ein bischen was verteilen um ein bessere Verhältnis zu erhalten.

Bei einem linaren Programfluss mit maximal 10 Blöcken kann man die noch einigermassen überschauen. Haben wir es aber nun mit einem dynamischem Branching zu tun werden zum einen die Wechsel zwischen den beiden Modies häufiger (= mehr Blöcke). Die Wahrscheinlichkeit das diese Blöcke alle eine unterschiedliche Länge haben steigt. Problematisch wird es auch wenn die beiden Pixel die gleichzeitig durch die Pipline laufen bei einem Branch jeweils einem anderen Zweig folgen müssen und diese unterschiedliche viele Blöcke haben. Probleme über Probleme.

Diese Dinge sind bei einer Anordnung wie sie nv verwendet völlig unproblematisch. Ein Handycap hat nv derzeit aber noch. Dadurch das sie mehrer Einheiten von einem Typ parallel pro Pipeline haben kann der Verschnitt höher sein aber verschnitt hat ATI wie ich oben gezeigt habe ja auch.

[aths]

Danke. Ich habe zwar noch nicht alles verstanden (muss ich später noch mal lesen) doch offenbar sind die PS-Logiken heute entweder schnell, oder flexibel, aber nicht beides.

[Quasar]

Original geschrieben von aths
Danke. Ich habe zwar noch nicht alles verstanden (muss ich später noch mal lesen) doch offenbar sind die PS-Logiken heute entweder schnell, oder flexibel, aber nicht beides.

Wenn du bereit bist, das "PS" mal einzuklammern: War das je anders?

[aths]

Original geschrieben von Quasar
Wenn du bereit bist, das "PS" mal einzuklammern: War das je anders? Jupp. Eine Athlon-CPU z.B. ist beides.

[Quasar]

Original geschrieben von aths
Jupp. Eine Athlon-CPU z.B. ist beides.
Nöpe. Guck dir mal an, wie langsam so ein Dingelchen im Vergleich zu aktuellen P4 ist, wenn (P4-)optimierter Code zum Einsatz kommt.

[aths]

Original geschrieben von Quasar
Nöpe. Guck dir mal an, wie langsam so ein Dingelchen im Vergleich zu aktuellen P4 ist, wenn (P4-)optimierter Code zum Einsatz kommt. Athlon und P4 sind ja auch keine gemeinsame "Tech-Stufe". Es liegen Jahre zwischen dem Athlon und dem P4.

[Quasar]

Zwischen dem Barton und dem P4-c nicht. Beide von diesem Jahr.

AMD konnte oder wollte wohl nicht früher aufsteigen.

[aths]

Original geschrieben von Quasar
Zwischen dem Barton und dem P4-c nicht. Beide von diesem Jahr.

AMD konnte oder wollte wohl nicht früher aufsteigen. Vom Barton rede ich nicht, sondern vom klassischen Athlon. Der war in seiner Zeit sowohl schnell, als auch vielseitig, hatte also weder deutliche Integer- noch FP-Schwächen.

[Quasar]

Original geschrieben von aths
Vom Barton rede ich nicht, sondern vom klassischen Athlon. Der war in seiner Zeit sowohl schnell, als auch vielseitig, hatte also weder deutliche Integer- noch FP-Schwächen.

Du meinst den klassischen Athlon? 0,25µ; 512kB off-die Cache; Slot A?
(nur um weiteren Mißverständnissen vorzubeugen).

Da gab es mal einen interessanten Vergleich zum K6 und Cyrix 6x86. Beide hatten eine höhere Effizienz, der Cyrix besonders im RC5-cracking, wenn ich mich recht erinnere. Und das in einer niedrigeren "Tech-Stufe"...

Schnell ist also relativ. Selbst beim Athlon musste AMD Kompromisse eingehen um eine hohe Taktfrequenz zu erreichen, die dann die Geschwindigkeit sicherstellte.

BTW, der Athlon Classic kann nichts mit SSE und SSE2/3Dnow Pro anfangen. Nur Integer, FPU und 3DNow. Flexibel? Jein.

[aths]

Original geschrieben von Quasar
Du meinst den klassischen Athlon? 0,25µ; 512kB off-die Cache; Slot A?
(nur um weiteren Mißverständnissen vorzubeugen). Genau den.
Original geschrieben von Quasar
Da gab es mal einen interessanten Vergleich zum K6 und Cyrix 6x86. Beide hatten eine höhere Effizienz, der Cyrix besonders im RC5-cracking, wenn ich mich recht erinnere. Und das in einer niedrigeren "Tech-Stufe"...

Schnell ist also relativ. Selbst beim Athlon musste AMD Kompromisse eingehen um eine hohe Taktfrequenz zu erreichen, die dann die Geschwindigkeit sicherstellte.

BTW, der Athlon Classic kann nichts mit SSE und SSE2/3Dnow Pro anfangen. Nur Integer, FPU und 3DNow. Flexibel? Jein. Soweit ich weiß, kann 3DNow SSE weitgehend "ersetzen". SSE2 etc. waren damals noch nicht entwickelt, gab es zumindest nicht zu kaufen. K6 (inkl. K6-2 und K6-III) und der Cyrix hatten eklatante FPU-Schwächen, damit waren sie eher für Office-PCs gut. Der Athlon war ein genialer Allrounder, und soweit ich weiß, effizienter als der damalige PIII.

Bei den PixelShadern wird es, keine Frage, auch mal Hardware geben, die 3.0-er (bzw. 2.0+-) Shader sehr schnell ausführen kann, aber mit 2.0-er und 1.4-er (usw.) ebenfalls problemlos klar kommt. Von einer zukunftsweisenden Shaderlogik erwarte ich, "straffrei" zwischen Sampling und Alu-Ops mischen zu können. Dafür wird es wohl erforderlich sein, Sampling (resp. Filterung) und Alu über die gleiche Logik zu machen. Damit das noch hinreichend schnell genug ist, müssen die Grundbausteine in hoher Anzahl vorhanden und flexibel verschaltbar sein.

[Quasar]

Original geschrieben von aths
Genau den.
Soweit ich weiß, kann 3DNow SSE weitgehend "ersetzen". SSE2 etc. waren damals noch nicht entwickelt, gab es zumindest nicht zu kaufen. K6 (inkl. K6-2 und K6-III) und der Cyrix hatten eklatante FPU-Schwächen, damit waren sie eher für Office-PCs gut. Der Athlon war ein genialer Allrounder, und soweit ich weiß, effizienter als der damalige PIII.

Ersetzen kann es den Funktionsumfang weitgehend, klar. Aber die Geschichte hat gezeigt, daß die meisten Optimierungen eher SSE als 3DNow bevorzugten, so daß AMD sich zum umschwenken mit dem Palomino veranlasst sah.

Willst du mit " K6 und der Cyrix hatten eklatante FPU-Schwächen, damit waren sie eher für Office-PCs gut" etwa sagen, es wäre eine Voraussetzung für Office PCs eine FPU-schwache CPU zu haben? ;)

Der Athlon war schon gut, aber er war als Allrounder (in der Summe vor dem Coppermine die "beste" CPU) in einigen Spezialdisziplinen eben auch schwächer, als z.B. seine direkten Vorgänger.


Original geschrieben von aths
Bei den PixelShadern wird es, keine Frage, auch mal Hardware geben, die 3.0-er (bzw. 2.0+-) Shader sehr schnell ausführen kann, aber mit 2.0-er und 1.4-er (usw.) ebenfalls problemlos klar kommt. Von einer zukunftsweisenden Shaderlogik erwarte ich, "straffrei" zwischen Sampling und Alu-Ops mischen zu können. Dafür wird es wohl erforderlich sein, Sampling (resp. Filterung) und Alu über die gleiche Logik zu machen. Damit das noch hinreichend schnell genug ist, müssen die Grundbausteine in hoher Anzahl vorhanden und flexibel verschaltbar sein.

Hoffen wir's.

[ram]

Original geschrieben von Demirug
Was die Shader über 2.0 angeht so ist man damit ja genaugenommen immer noch nicht fertig.

Inwiefern?

[Demirug]

Der offiziele HLSL Compiler kann im Moment nur maximal 2.0 Shader und der Beta Compiler zusätzlich noch das 2_a Profil für die FX Chips. 2_X oder gar 3_0? Fehlanzeige

[ram]

Original geschrieben von Demirug
Der offiziele HLSL Compiler kann im Moment nur maximal 2.0 Shader und der Beta Compiler zusätzlich noch das 2_a Profil für die FX Chips. 2_X oder gar 3_0? Fehlanzeige

Na schon, aber die Fähigkeiten des Compilers haben ja recht wenig mit der Spezifikation der Shader zu tun. Compiler sind i.d.R. nie richtig fertig entwickelt und können immer weiter verbessert werden.

[Demirug]

OK wir haben das ganze von einer unterschiedlichen Warte aus betrachtet.

[nggalai]

Hi Demiurg,

danke für deine ausführlichen Postings--einer der besten Threads hier im Forum der letzten Zeit, IMO.

Eine Frage an dich als Entwickler: Wird euer Projekt auf MS HLSL setzen und den "Empfehlungen" der beiden Profile folgen, oder bedeutet das für euch unannehmbaren Mehraufwand?

93,
-Sascha.rb

[Demirug]

Original geschrieben von nggalai
Hi Demiurg,

danke für deine ausführlichen Postings--einer der besten Threads hier im Forum der letzten Zeit, IMO.

Eine Frage an dich als Entwickler: Wird euer Projekt auf MS HLSL setzen und den "Empfehlungen" der beiden Profile folgen, oder bedeutet das für euch unannehmbaren Mehraufwand?

93,
-Sascha.rb

Auf diese Frage gibt es 3 Antworten:

1. Ja wir benutzten den HLSL Compiler und seine unterschiedlichen Profile. Was den Aufwand angeht so schlage ich mich lieber einmal durch die Technik als mich mit Horden von unzufriedenen Kunden zu streiten.

2. Ja wir benutzten den HLSL Compiler und zusätzlich auch noch den Cg Compiler.

3. Nein, unsere Engine baut nicht auf HLSL auf wir machen etwas ganz anderes.

So jetzt dürfte entgültig jeder verwirrt sein ?-) ;D

[nggalai]

;D

Danke für die Antwort! ;D

93,
-Sascha.rb

[LovesuckZ]

Original geschrieben von Demirug
2. Ja wir benutzten den HLSL Compiler und zusätzlich auch noch den Cg Compiler.


Muss man hier irgendwas beachten oder harmonieren beide perfekt zusammen?

[Demirug]

Original geschrieben von LovesuckZ
Muss man hier irgendwas beachten oder harmonieren beide perfekt zusammen?

Im Prinzip muss man nichts grossartig beachten ausser das der Cg-Compiler teilweise eine genauere Typprüfung hat.

[Xmas]

Original geschrieben von Demirug
So jetzt dürfte entgültig jeder verwirrt sein ?-) ;D
Nene, so schnell geht das mit dem Verwirren dann doch nicht ;)

[Chris Lux]

Original geschrieben von LovesuckZ
Muss man hier irgendwas beachten oder harmonieren beide perfekt zusammen?

man muss nichts beachten so lange man nur für D3D Profile entwickelt, da Cg und HLSL zusammen von MS und NV entwickelt wurden sind sie quasi identisch.

[Demirug]

Sorry das ich den Thread wieder hochhole aber ich halte es für wichtig.

Irgendjemand hätte doch auffallen müssen das mein Model der NV30 Pipeline so nicht ganz stimmen kann und mir einen Tritt verpassen können.

Nach der Sichtung von unzähligem Shadercode den der Cg Compiler produziert und einigen Blicken auf 2.A Shadern bin ich der Sache wohl näher gekommen und es wurde alles viel komplexer.


Tri Setup
|
Registerwrite------->>------------|
| |
-->-->-- |
| | |
| Waitpoint 1 |
| | |
| Registerread--------<<------------|
| | |
| Sampler1-<<->>| |
| | -<<->>TMU(s) |
| Sampler2-<<->>| |--<<-->>--Registerspeicher (ohne Konstanten)
| | |
| Waitpoint 2 |
| | |
| -->-- |
| | | |
| | ALU(s) |
| | | |
| --<-- |
| | |
| Registerwrite------->>------------|
| | |
--<--<-- |
| |
Registerread--------<<------------|
|
|
AA-Einheiten

>> und << stellen nur einen Datenfluss da.

ALU(s) steht für eine nicht näher definierte Anzahl von ALUs mit
möglicherweise unterschiedlichen Datentypen die wahrscheinlich in
Rheie angeordnet sind.

Um die Sampler 1 und 2 befindet sich wahrscheinlich auch noch ein
Loop der aber nur in Verbindung mit 1.1-1.3 Shadern sowie DX7
Texturesetups mit <= 4 Texturen zum Einsatz kommt. Dieser Loop kann
dann auch nur einmal durchlaufen werden.



Die Pipeline ist also lang (sehr lang). An diesem überarbeiteten Model erkennt man sehr schön erkennen warum die NV3x Chips die Shader so haben wollen wie sie der Cg-Compiler bzw das 2.A Profil erzeugt.

Wegen den beiden Samplern werden Texturen möglichst immer paarweise ausgelesen. Sie sind hintereinader angeordnet damit das ergebniss des ersten Reads sofort vom zweiten benutzt werden kann. Nach den zwei Texturesamples erfolgt immer ein Block mit einer variablen Anzahl von ALU anweisungen. Daher ist der Loop um die ALUs auch unbedingt erforderlich. Wie wir ja auch erfahren haben mögen es die NV30 Chips überhaupt nicht wenn man grosszügig mit Temporären Registern um sich wirft. Der Grund dafür ist nun auch ersichtlich. Die Pipelines selbst können nur eine begrenzte Anzahl von Registern (Konstanten zählen nicht mit) gleichzeitig halten (wahrscheinlich 4 aber das bedarf noch näherer Untersuchungen). Werden nur für einen Durchlauf (2 Sampels + x Ops) mehr Werte gebraucht als zur Verfügung stehen muss der Durchlauf auf mehrer aufgeteilt werden. Die zwei Waitpoints sind erforderlich um die Pipe syncron zu halten wenn das Sampeln und die Operationen eine unterschiedliche Anzahl von Takten brauchen.

Ein normaler 2.0 Shader ist also wie in meiner ursprünglichen Analyse festgestellt absolute Kontraproduktiv für diese Art der Pipeline.

Die Frage die es noch zu klären gibt ist was passiert wenn die Pipeline einmal durchlaufen wurde. Wird der gleiche Pixel wieder an den Anfang geschickt oder holt sich die Pipeline einen anderen aus dem Registerspeicher auf den der gleiche Durchlauf ausgeführt wird. Die zweite Variante sollte die bessere sein. Es wird zwar ein grösseren Registerspeicher (On Chip F-Buffer?) benötigt aber dadurch das auf eine grosse Menge von Pixel der gleiche Teil des Shaderprogramms ausgeführt wird ergeben sich Vorteile. Da nur auf zwei Texturen dabei zugegriffen müssen sich auch nur diese beiden Texturen den Texturecache teilen die Hitrate sollte steigen. Wenn nur ein Teil des Shaderprogramm gebraucht wird muss auch nur dieser teil in den Chip geladen sein der Rest belegt dann keinen Platz. NV3x Chips können Pixel Shaderprogramme ja im Grafikkartenspeicher hinterlegen. Zudem kommt es wenn man eine grössere Menge von Pixel mit dem gleichen Programmteil bearbeitet nicht zu einem Verschnit der entsteht wenn die einzelnen Teile unterschiedlich lang sind (ein Problem das die R3xx Chips kennen).

Kommen wir nun noch zu der Frage die einigen wohl schon auf den Fingern brennt. Wie sieht es denn nun mit PS 3.0 aus? Die Situation hat sich da gar nicht mal so sehr verändert. Bei den NV3x Chips ist eine Ausführungseinheit nach wie vor recht klein (0-2 Sampels + x Ops; X >= Anzahl ALUs) was ein effektives Verhalten bei den Schleifen und den Bedingungen (ifs) erlaubt. Setzt man dann noch auf das Verfahren das man möglichst viele Pixel zwischen speichert wird die Sache noch effektiver.

Dafür das man das Speicherverfahren wirklich benutzt spricht IMHO auch die Tatsache das die Shadercompiler nicht nur die Registeranzahl innerhalb eines Blocks zu gering wie möglich halten sondern auch die Gesamtzahl. Je weniger Register man benutzt desto mehr Pixel bekommt man in den Registerspeicher.

Soweit zum update meiner überlegungen. Ich entschuldige mich hiermit nochmal dafür das ich am Anfang diese Threads möglicherweise Fehlinformationen verbreitet habe und auch meine jetzigen überlegungen immer noch nicht korrekt sein müssen. nv sagt einfach zu wenig zu den Thema.

Sollte jemand offensichtliche oder auch nicht offensichtliche Fehler finden möge man mich bitte darauf hinweisen.

[egdusp]

Wieviel Performance dürfte es ATI kosten trotzdem PS und VS 3.0 einzubauen. Es gibt momentan vermehrt Gerüchte, dass Loki ja auch PS und VS 3.0 haben soll. Somit würde eines der "Killerfeatures" des NV40 Wegfallen. Dass bis zum Erscheinen von PS3.0 Spielen die Leistung von NV40 und Loci bestenfalls Mainstream sein dürfte, ist es zwar eigentlich irrelevant, aber ich kann mir gut vorstellen, dass NV dann ein D3D Demo rausgibt, dass PS3.0 only Effekte benutzt die supergeil aussehen (Spekulation: verschwitzte Dusk :D, man denke nur an die ganzen Glänz-und Transparenzeffekte), aber auf der PS 3.0 Notlösung des Locis grottenlangsam laufen.
(@Nagus: Ich sehe schon die Threads: "Sweating Dusk sleeps with ATI, however, their Passion seems to have slown down" ;D )

mfg
egdusp

[Demirug]

egdusp, das Problem ist das wohl kein Mensch ausserhalb von ATI weiss wie sie PS 3.0 realisieren wollen. Aus diesem Grund ist jede performance Spekulation nur Makulatur solange man nicht mal den Hauch einer Ahnung hat. Im anderen Thread habe ich zwar eine möglichkeit erwähnt aber auch da kann ich nicht sagen wie sich das ganze verhalten würde weil mir Performance Daten zum F-Buffer fehlen.

[zeckensack]

Drehen wir die Betrachtung doch nochmal um :naughty:
Was wäre denn ein optimaler Shader für diese Architektur?

//gaaaaanz schlecht
//Inputs liegen in r0 ... r3

//der Shader beginnt _nicht_ mit Textur-Sampling

//alle Ops sind von der direkt vorangegangenen abhängig
//außerdem benutzen wir mal ein paar mehr Register ...
sin r4,r0 //diese op ist fürchterlich teuer ...
mul r5,r4,r1
mad r6,r1,r4,r2
tex r2,tex0,r6 //überschreibt einen gerade erst benutzten input. schlimm oder nicht?
tex r3,tex0,r2 //direkt abhängig vom vorangegangenen Textursample.
//läuft auch noch auf dem gleichen Sampler. ganz schlimm, nehme ich an?
<...>

So oder ähnlich stelle ich mir worst case-Shadercode vor ;)

Jetzt aber zur eigentlichen Fragestellung:
//guter Shader?
//inputs im Konstantenspeicher und r0

//genau zwei unabhängige Textursamples
tex r1,tex0,tex_c0
tex r2,tex1,tex_c1

mad r1,r1,r0,r2 //kein Problem mit Zielregister=Quellregister?
//kein Problem, gerade erst erzeugte Samples direkt zu verwenden?
mul r0,r0,r0 //kein Problem, im Zusammenspiel mit der vorhergehenden Op (ein Quellregister wird modifiziert)?

//war dieser Instruktionsblock 'zu kurz'?

//Samples
tex r0,tex7,r0 //'nicht-linearer' Zugriff auf die gebundenen Texturen (r0, r1, r7)
//Scheduling okay? (ganz frischer Schreibzugriff auf r0)
tex r1,tex5,r2

//Ops
<...>

Tja :)

[Demirug]

Eins vorweg ich gehe jetzt von meinem derzeigtem Theoretischen Model aus das ich nicht bis in Detail gegen die Hardware verifiziert habe.

//gaaaaanz schlecht
//Inputs liegen in r0 ... r3

//der Shader beginnt _nicht_ mit Textur-Sampling

//alle Ops sind von der direkt vorangegangenen abhängig
//außerdem benutzen wir mal ein paar mehr Register ...
sin r4,r0 //diese op ist fürchterlich teuer ...
mul r5,r4,r1
mad r6,r1,r4,r2
tex r2,tex0,r6 //überschreibt einen gerade erst benutzten input. schlimm oder nicht?
tex r3,tex0,r2 //direkt abhängig vom vorangegangenen Textursample.
//läuft auch noch auf dem gleichen Sampler. ganz schlimm, nehme ich an?
<...>

sin ist auf den FX nicht teuer. Frag mich nicht warum aber auf einem NV30 gibt es keine unterschied ob man nun einen Sinus oder eine Mulitplikation ausrechnen läst.

Aber schauen wir uns mal den rest an. Mal abgesehen davon das die Temps alle eigentlich 0 enthalten. und du Werte berechnets du dann nicht mehr benutzt werden. :D


Zeile Data1 Data2 Data3 Data4

Read r0 r1 r2

1 In r0 r1 r2
1 Out r4 r1 r2
2 In r4 r1 r2
2 Out r4 r1 r2 r5
3 In r4 r1 r2 r5
3 Out r6 r1 r2 r5

Write R6

// Loopback

Read R6

4 In r6
4 Out r2
5 In r2
5 Out r3

Write R3



Also wenn der optimzier wengisten ein bischen schon funktioniert und erkennt das er werte im gleichen Durchlauf nicht mehr braucht sollte das ganze relative gut laufen. Direkte abhängikeiten sind kein Problem (das hat schon jemand ausprobiert) und beim zweimal aus dem gleichen Sampler lesen sehe ich eigentlich auch kein Problem. Aber das müsste man mal austesten. Das vor dem Sampelteil ein Rechenteil kommt ist aber generel nicht schön.

Dem R300 würde das ganze aber wohl auch nicht sonderlich schmecken. Ist immerhin ein 2 Phasen Shader mit einem eher schlechten Gleichgewicht {(0|2+Sinus),(2|0)}. Wobei man einmal prüfen müsste wie teuer der Sinus auf dem R300 ist.

//guter Shader?
//inputs im Konstantenspeicher und r0

//genau zwei unabhängige Textursamples
tex r1,tex0,tex_c0
tex r2,tex1,tex_c1

mad r1,r1,r0,r2 //kein Problem mit Zielregister=Quellregister?
//kein Problem, gerade erst erzeugte Samples direkt zu verwenden?
mul r0,r0,r0 //kein Problem, im Zusammenspiel mit der vorhergehenden Op (ein Quellregister wird modifiziert)?

//war dieser Instruktionsblock 'zu kurz'?

//Samples
tex r0,tex7,r0 //'nicht-linearer' Zugriff auf die gebundenen Texturen (r0, r1, r7)
//Scheduling okay? (ganz frischer Schreibzugriff auf r0)
tex r1,tex5,r2

//Ops
<...>

Warum sampelt man mit Constanten? Ich nehme mal an du meinst die Texturekorrdinatenregister? Wenn meine überlegung stimmt macht das NV3x Model eigentlich keinen direkten unterschied zwischen Textkoordinatenregistern und tempregistern.


Zeile Data1 Data2 Data3 Data4

Read t0 t1 r0

1 In t0 t1 r0
1 Out r1 t1 r0
2 In r1 t1 r0
2 Out r1 r2 r0
3 In r1 r2 r0
3 Out r0 r2
4 In r0 r2
4 Out r0 r2

Write R0 R2

// Loopback

Read R0 R2

5 In R0 R2
5 Out R0 R2
6 In r0 r2
6 Out r0 r1

// ops



Das Prinzip ist das es innerhalb der Pipelines keine Register mehr gibt sondern nur noch Datenpfade (wahrscheinlich 4) Jede Einheit kann nun mit den eingehenden datepfaden rechnen oder diese einfach nur durchschieben. wenn die Einheiten nun hintereinadern angebracht sind stellt das direkte weiterrechnen mit einem Ausgangswert der vorherigene Anweisung kein Problem dar. Das es funktioniert wurde schon nachgebrüft.

[zeckensack]

Original geschrieben von Demirug
Aber schauen wir uns mal den rest an. Mal abgesehen davon das die Temps alle eigentlich 0 enthalten. und du Werte berechnets du dann nicht mehr benutzt werden. :D
Hrrrr :D
Den Code habe ich nicht auf Sinnhaftigkeit hin überprüft ;)
Außerdem ist die Syntax frei erfunden. Mit dem 'Inputs in r0 ... r3' meinte ich daß dort (interpolierte) Werte aus dem VS liegen sollen. 'Inputs im Konstantenspeicher ...' habe ich nicht benutzt, aber ich habe extra jeden 'Shader mit "<...>" ausgeblendet, um anzuzeigen daß es noch irgendwie weitergehen soll.

Warum sampelt man mit Constanten? Ich nehme mal an du meinst die Texturekorrdinatenregister? Wenn meine überlegung stimmt macht das NV3x Model eigentlich keinen direkten unterschied zwischen Textkoordinatenregistern und tempregistern.Siehe oben, Syntax frei erfunden, und Konstanten wurden in meinem Schnipsel nicht verwendet.

Da muß ich jetzt nochmal erklären:
tex r0,tex0,tex_c3

Soll heißen, man nehme Textursampler 0, und hole ein Sample aus der dort gebundenen Textur. Die verwendeten Texturkoordinaten dafür holt man sich aus tex_c3, was ein interpolierter Input ist. Das Sample wird abgelegt im r0-Register.

Diese Syntax sollte also lediglich die logische Trennung zwischen Sampler und Koordinatensatz berücksichtigen, nichts weiter.

Zum Rest schonmal Dankschee, werd's mir nochmal genauer anschauen müssen :)

[Demirug]

Ein bischen Pseudocode:


class PixelPipelineJob
{
int[] InputRegister = new int[4];
int[] OutputRegister = new int[4];

TextureJob[] TexJobs = new TextureJob[2];
AritemetikJob[] ALUJobs = new AritemetikJob[variable];

void Execute ()
{
Vector4[] Data = new Vector4[4];

for (int Index = 0 ; Index < Data.Length ; ++Index)
Data[Index] = ReadRegister(InputRegister[Index]);

TexJobs[0].Execute (Data);
TexJobs[1].Execute (Data);

int jobid = 0;

while (jobid < ALUJobs.Length)
{
ALUJobs[jobid++].Execute (Data); // Diese Zeile so oft wie es ALUs gibt
}

for (int Index = 0 ; Index < Data.Length ; ++Index)
WriteRegister(OutputRegister[Index], Data[Index]);
}
}

[zeckensack]

Ah, der ist gut :)

Wenn das Programm länger ist, dann wird Execute mehrfach aufgerufen, gell?

[Demirug]

Original geschrieben von zeckensack
Ah, der ist gut :)

Wenn das Programm länger ist, dann wird Execute mehrfach aufgerufen, gell?

Jaein. Wenn man nach dem Rechenteil (AritemetikJob) wieder Sampeln will (TextureJob). Dann gibt es ein weiteres PixelPipelineJob Object weil der zweite Job ja anders aufgebaut ist.

Also in etwa so:


PixelPipelineJob[] jobs = new PixelPipelineJob[5];

LoadShader (jobs);

foreach (PixelPipelineJob job in jobs)
job.execute ();


wobei ich ja wie gesagt davon ausgehe das der Jobwechsel nicht sofort erfolgt sonder das ganze so abläuft.


PixelPipelineJob[] jobs = new PixelPipelineJob[5];

LoadShader (jobs);

foreach (PixelPipelineJob job in jobs)
foreach (Pixel pix in pixelcache)
{
pix.select ();
job.execute ();
}


Der Pixelcache wird dabei vom Trisetup gefüllt und von den AA-Samplern wieder geleert.

[Gast]

hab da mal ne frage!!!
wird nvidia ps 2.0 verbessern können oder bleiben die jetzt langsamer??? ohne eine neue karte herzustellen!
die hatten damals ja auch den flaschenhals bei 1.4 beseitigt bekommen und man hatte aufeinmal nicht 30 sondern 90 fps!!(Gf 4 Ti)
oder muss man beim nv 35 mit der schlechteren ps 2.0 leben??

bye
DarKShadoW

P.S. mein kopf dempt ganz schön nach dem ich das alles gelesen ahben =) =)

[Aquaschaf]

Die Shader sind nicht "schlechter", Shaderprogramme müssen nur aufgrund der anderen Pipelinestruktur anders angeordnet werden, um möglichst viel pro Pipelinedurchlauf zu erledigen. Und das wird sich bei zukünftigen Karten nicht ändern, allerdings könnte es sein, dass zukünftige Treiber die Anweisungen der Shaderprogramme so umsortieren, wie es der Karte am besten liegt.

[micki]

Original geschrieben von egdusp
dass NV dann ein D3D Demo rausgibt, dass PS3.0 only Effekte benutzt die supergeil aussehen (Spekulation: verschwitzte Dusk :D, man denke nur an die ganzen Glänz-und Transparenzeffekte), aber auf der PS 3.0 Notlösung des Locis grottenlangsam laufen.


bisher hat nvidia immer openGL tech-demos gemacht, sogar in früheren zeiten als sie schneller als ati waren, alleine schon aus dem grund um sagen zu können, dass ATIkarten garnicht die NVidia demos laufen lassen können... das ist wohl für denkende egal (bei ATI heißen die extension dann nur anders:), aber für viele amis ist das ein beweis dass nv besser ist und man ne gf kaufen muss...

:massa: marketing


Mfg
micki

[micki]

Original geschrieben von Gast
die hatten damals ja auch den flaschenhals bei 1.4 beseitigt bekommen und man hatte aufeinmal nicht 30 sondern 90 fps!!(Gf 4 Ti)
oder muss man beim nv 35 mit der schlechteren ps 2.0 leben??


wen immer du mit "die" meinst, sie haben sicherlich keine performanceoptimierung auf der gf4ti gemacht, dass pixelshader 1.4 schneller laufen
sie laufen garnicht!
nur bis 1.3 und falls etwas auf der gf4ti läuft, dass 1.4 nutzt, wird es auf der geforce mit den 1.3 pixelshadern emuliert

MfG
micki

[monstar-x]

Würde mich auch Interessieren, ob Sie die Shaderleistungen mit Treibern verbessern können...?

Wenn JA in absehbarer Zeit?

[Demirug]

Original geschrieben von monstar-x
Würde mich auch Interessieren, ob Sie die Shaderleistungen mit Treibern verbessern können...?

Theoretisch ja. Es gibt da mehrer Angriffspunkte die allerdings ein unterschiedliches Mass an Aufwand erfordern.

Wenn JA in absehbarer Zeit?

Angeblich soll ja der Deto 50 schon was bringen.

[monstar-x]

Original geschrieben von Demirug
Theoretisch ja. Es gibt da mehrer Angriffspunkte die allerdings ein unterschiedliches Mass an Aufwand erfordern.



Angeblich soll ja der Deto 50 schon was bringen.
Aha, Du sagst Angeblich, was denkst du ja oder nein und wenn mit wieviel % mehrleistung ist zu rechnen? DEINER MEINUNG NACH???

[Demirug]

Original geschrieben von monstar-x
Aha, Du sagst Angeblich, was denkst du ja oder nein und wenn mit wieviel % mehrleistung ist zu rechnen? DEINER MEINUNG NACH???

Eine Steigerung wird es geben aber da jetzt mit Prozenzzahlen zu kommen wäre der falsche weg. Es wird sehr stark vom jeweiligen Shader abhängen in wie weit man dort die Performances steigern kann.

[aths]

Original geschrieben von micki
wen immer du mit "die" meinst, sie haben sicherlich keine performanceoptimierung auf der gf4ti gemacht, dass pixelshader 1.4 schneller laufen
sie laufen garnicht!
nur bis 1.3 und falls etwas auf der gf4ti läuft, dass 1.4 nutzt, wird es auf der geforce mit den 1.3 pixelshadern emuliert

MfG
micki Wenn kein 1.4-er HW-Support da ist, wird gar nichts emuliert. GF4 Ti ist nicht in der Lage, den 1.4-er zu "emulieren", das muss dann schon die CPU machen, was sehr, sehr, sehr langsam ist.

[aths]

Original geschrieben von Aquaschaf
Die Shader sind nicht "schlechter", Shaderprogramme müssen nur aufgrund der anderen Pipelinestruktur anders angeordnet werden, um möglichst viel pro Pipelinedurchlauf zu erledigen. Und das wird sich bei zukünftigen Karten nicht ändern, allerdings könnte es sein, dass zukünftige Treiber die Anweisungen der Shaderprogramme so umsortieren, wie es der Karte am besten liegt. Sie sind insofern schon "schlechter", dass die Spitzen-Rechenleistung unter dem liegt, was ATI bietet (im Falle NV30 sogar sehr deutlich.) Andererseits sind die NV-Shader auch besser, weil sie durch zusätzliche Befehle einiges effizienter erledigen können als die Radeons.

[zeckensack]

Jetzt mal ganz im Ernst, bestimmte Konsorten warten jetzt schon ein ganzes Jahr lang darauf, daß NV30 den R300 in den Boden stampft. Inklusive zwischenzeitlichem Wechsel auf NV35, um die Hoffnung nicht ganz sterben zu lassen.

Wenn das keine Loyalität ist ... dann ist es zumindest irrational :|

[Aquaschaf]

Das Warten auf den "Endsieg" von NVidia würde ich das nennen :smash:

[Gast]

Original geschrieben von zeckensack
Jetzt mal ganz im Ernst, bestimmte Konsorten warten jetzt schon ein ganzes Jahr lang darauf, daß NV30 den R300 in den Boden stampft. Inklusive zwischenzeitlichem Wechsel auf NV35, um die Hoffnung nicht ganz sterben zu lassen.

Wenn das keine Loyalität ist ... dann ist es zumindest irrational :|

Wieso warten. Seit dem NV35 Launch ist ATI nur noch 2.
Übrigens auch nach firmeneigenen Aussagen.
Mehr muss man nicht wissen dazu.
Das ist der Fakt und alles andere ist irrelevant.

[Exxtreme]

Original geschrieben von Gast
Wieso warten. Seit dem NV35 Launch ist ATI nur noch 2.
Übrigens auch nach firmeneigenen Aussagen.
Mehr muss man nicht wissen dazu.
Das ist der Fakt und alles andere ist irrelevant.
Also für diese "firmeneigenen Aussagen" hätte ich gerne einen Link oder eine URL. :D

Ist das machbar?

[Iceman346]

Original geschrieben von Exxtreme
Also für diese "firmeneigenen Aussagen" hätte ich gerne einen Link oder eine URL. :D

Ist das machbar?

Danach hab ich ihm in dem Thread zu meinem FX Test auch schon gefragt. Nachdem ich das getan hab hat Richti nicht mehr in dem Thread gepostet...

[StefanV]

Original geschrieben von Exxtreme
Also für diese "firmeneigenen Aussagen" hätte ich gerne einen Link oder eine URL. :D

Ist das machbar?

Nö, da keine Firma so blöd ist und offiziell verkündet, daß die Konkurenz schneller ist *eg*

Aber nV hat sicher mal wieder behauptet, daß sie schneller sind, das wirds wohl sein :naughty:

[Ailuros]

Original geschrieben von Gast
Wieso warten. Seit dem NV35 Launch ist ATI nur noch 2.
Übrigens auch nach firmeneigenen Aussagen.
Mehr muss man nicht wissen dazu.
Das ist der Fakt und alles andere ist irrelevant.

Ze Witz of ze week :D

[Dunkeltier]

Original geschrieben von ow
Ich denke mal eher so ab 30% mehr, wenn demi mit seiner 'Architektur-Prognose' nicht zuweit daneben liegt.
Die derzeitig vom MS-Compiler erzeugten Shader duerften einen NV3x auf kaum mehr als halber Kraft laufen lassen.
Inwiefern NV allerdings jetzt schon treiberintern die Shader erkennt und sie auf die NV3x Architektur umbastelt duerfte unbekannt sein.

Bringt dies auch den schon erschienenden PS/VS 2.0 Spielen was?

[Demirug]

Original geschrieben von Dunkeltier
Bringt dies auch den schon erschienenden PS/VS 2.0 Spielen was?

Der neue MS-Compiler bringt nur was wenn es dann einen Patch fürs Spiel gibt. Wenn nVidai die Shader im Treiber auch umbauen kann bringt es für alle Spiele was.

@ow: Ein "Dead Code remove" ist im 45.23 schon vorhanden und eine merkwürdige erkennung das Int12 reicht gibt es scheinbar auch schon.

[tb]

die 45.23'er NVIDIA Treiber scheinen recht immun gegen die Anordnung der Shaderinstruktionen (dx9 sdk update rc0) zu sein:



(shadermark v2.0 beta 1)
geforce fx 5900 ultra (45.23)
ps2_0

Per Pixel Diffuse Lighting: 113 fps 8.8810 mspf 563 rendered frames
Per Pixel Directional Light Shader (Phong): 82 fps 12.1255 mspf 413 rendered frames
Per Pixel Spot Light Shader (Phong): 55 fps 18.2482 mspf 274 rendered frames
Per Pixel Anisotropic Lighting: 79 fps 12.6582 mspf 395 rendered frames
Per Pixel Fresnel Reflections: 129 fps 7.7340 mspf 647 rendered frames
Per Pixel Car Surface Shader: 40 fps 25.1649 mspf 199 rendered frames
Per Pixel Veined Marble Shader: 44 fps 22.9537 mspf 218 rendered frames
Per Pixel Wood Shader: 60 fps 16.6373 mspf 301 rendered frames
Per Pixel Environment Mapping: 142 fps 7.0181 mspf 713 rendered frames
Per Pixel Environment Bump Mapping: 125 fps 8.0191 mspf 624 rendered frames
Fur Shader With Anisotropic Lighting: 5 fps 198.7680 mspf 26 rendered frames
Per Pixel Bump Mapping: 49 fps 20.2085 mspf 248 rendered frames
Per Pixel Shadowed Bump Mapping: 46 fps 21.8511 mspf 229 rendered frames
Per Pixel Refraction and Reflection Shader with Phong Lighting: 34 fps 29.2287 mspf 172 rendered frames


ps2_a
Per Pixel Diffuse Lighting: 118 fps 8.4956 mspf 589 rendered frames
Per Pixel Directional Light Shader (Phong): 79 fps 12.6582 mspf 395 rendered frames
Per Pixel Spot Light Shader (Phong): 58 fps 17.3281 mspf 289 rendered frames
Per Pixel Anisotropic Lighting: 80 fps 12.5195 mspf 400 rendered frames
Per Pixel Fresnel Reflections: 129 fps 7.7340 mspf 647 rendered frames
Per Pixel Car Surface Shader: 42 fps 23.6402 mspf 212 rendered frames
Per Pixel Veined Marble Shader: 49 fps 20.2429 mspf 247 rendered frames
Per Pixel Wood Shader: 61 fps 16.5274 mspf 303 rendered frames
Per Pixel Environment Mapping: 142 fps 7.0181 mspf 713 rendered frames
Per Pixel Environment Bump Mapping: 125 fps 8.0128 mspf 624 rendered frames
Fur Shader With Anisotropic Lighting: 5 fps 196.6647 mspf 26 rendered frames
Per Pixel Bump Mapping: 49 fps 20.3728 mspf 246 rendered frames
Per Pixel Shadowed Bump Mapping: 44 fps 22.7805 mspf 220 rendered frames
Per Pixel Refraction and Reflection Shader with Phong Lighting: 29 fps 34.1199 mspf 147 rendered frames



ps2_0 + partial precision

Per Pixel Diffuse Lighting: 127 fps 7.8926 mspf 634 rendered frames
Per Pixel Directional Light Shader (Phong): 105 fps 9.5569 mspf 524 rendered frames
Per Pixel Spot Light Shader (Phong): 82 fps 12.1845 mspf 411 rendered frames
Per Pixel Anisotropic Lighting: 109 fps 9.1984 mspf 544 rendered frames
Per Pixel Fresnel Reflections: 133 fps 7.5360 mspf 664 rendered frames
Per Pixel Car Surface Shader: 60 fps 16.8047 mspf 298 rendered frames
Per Pixel Veined Marble Shader: 62 fps 16.0382 mspf 312 rendered frames
Per Pixel Wood Shader: 86 fps 11.6641 mspf 429 rendered frames
Per Pixel Environment Mapping: 143 fps 7.0028 mspf 714 rendered frames
Per Pixel Environment Bump Mapping: 134 fps 7.4516 mspf 671 rendered frames
Fur Shader With Anisotropic Lighting: 9 fps 113.8021 mspf 45 rendered frames
Per Pixel Bump Mapping: 78 fps 12.8967 mspf 388 rendered frames
Per Pixel Shadowed Bump Mapping: 66 fps 15.2332 mspf 329 rendered frames
Per Pixel Refraction and Reflection Shader with Phong Lighting: 55 fps 18.1159 mspf 276 rendered frames


ps2_a + partial precision

Per Pixel Diffuse Lighting: 133 fps 7.5188 mspf 665 rendered frames
Per Pixel Directional Light Shader (Phong): 103 fps 9.7352 mspf 514 rendered frames
Per Pixel Spot Light Shader (Phong): 84 fps 11.9711 mspf 418 rendered frames
Per Pixel Anisotropic Lighting: 111 fps 8.9928 mspf 556 rendered frames
Per Pixel Fresnel Reflections: 133 fps 7.5360 mspf 664 rendered frames
Per Pixel Car Surface Shader: 66 fps 15.1752 mspf 330 rendered frames
Per Pixel Veined Marble Shader: 78 fps 12.8635 mspf 389 rendered frames
Per Pixel Wood Shader: 85 fps 11.8296 mspf 423 rendered frames
Per Pixel Environment Mapping: 143 fps 7.0028 mspf 714 rendered frames
Per Pixel Environment Bump Mapping: 134 fps 7.4516 mspf 671 rendered frames
Fur Shader With Anisotropic Lighting: 7 fps 133.4293 mspf 38 rendered frames
Per Pixel Bump Mapping: 76 fps 13.1682 mspf 380 rendered frames
Per Pixel Shadowed Bump Mapping: 66 fps 15.1175 mspf 331 rendered frames
Per Pixel Refraction and Reflection Shader with Phong Lighting: 56 fps 18.0137 mspf 278 rendered frames

Radeon 9800 pro (cat 3.7)
ps2_0 (partial precision bring beim r3xx nix)
Per Pixel Diffuse Lighting: 231 fps 4.3215 mspf 1157 rendered frames
Per Pixel Directional Light Shader (Phong): 181 fps 5.5270 mspf 905 rendered frames
Per Pixel Spot Light Shader (Phong): 144 fps 6.9210 mspf 723 rendered frames
Per Pixel Anisotropic Lighting: 181 fps 5.5371 mspf 903 rendered frames
Per Pixel Fresnel Reflections: 216 fps 4.6296 mspf 1080 rendered frames
Per Pixel Car Surface Shader: 126 fps 7.9270 mspf 631 rendered frames
Per Pixel Veined Marble Shader: 99 fps 10.1373 mspf 494 rendered frames
Per Pixel Wood Shader: 142 fps 7.0423 mspf 710 rendered frames
Per Pixel Environment Mapping: 254 fps 3.9385 mspf 1270 rendered frames
Per Pixel Environment Bump Mapping: 225 fps 4.4422 mspf 1126 rendered frames
Fur Shader With Anisotropic Lighting: 14 fps 72.0424 mspf 70 rendered frames
Per Pixel Bump Mapping: 149 fps 6.7076 mspf 746 rendered frames
Per Pixel Shadowed Bump Mapping: 104 fps 9.5785 mspf 522 rendered frames
Per Pixel Refraction and Reflection Shader with Phong Lighting: 126 fps 7.9491 mspf 629 rendered frames


Thomas

[Exxtreme]

Original geschrieben von tb
die 45.23'er NVIDIA Treiber scheinen recht immun gegen die Anordnung der Shaderinstruktionen (dx9 sdk update rc0) zu sein:



*wegen Übersichtlichkeit rausgemacht*


Thomas
Hmmm, also entweder modelt der Treiber die eigentlich optimierten PS2_a-Shader wieder in eine unoptimierte Version um oder das PS2_a-Profil bringt bei Weitem nicht so viel wie einige Leute hier im Forum eigentlich hoffen. :|

P.S. Partial precision scheint viel mehr zu bringen als das PS2_a-Profil.

P.P.S

Thomas,

kannst du bitte mal die Ergebnisse der Radeon mit dem PS2_a-Profil posten? Vorausgesetzt natürlich, daß die Radeon das PS2_a-Profil in diesem Test ausführen kann.

[tb]

Leider läuft ps2_a auf der Radeon nicht richtig, was vorallem am D3DPS20CAPS_ARBITRARYSWIZZLE liegt. Hier die Shader, welche funktionierten:




ps2_a
Per Pixel Diffuse Lighting: 225 fps 4.4444 mspf 1125 rendered frames
Per Pixel Directional Light Shader (Phong): 157 fps 6.3857 mspf 783 rendered frames
Per Pixel Point Light Shader (Phong): 156 fps 6.3989 mspf 782 rendered frames
Per Pixel Spot Light Shader (Phong): 130 fps 7.6865 mspf 651 rendered frames
Per Pixel Anisotropic Lighting: 166 fps 6.0096 mspf 832 rendered frames
Per Pixel Fresnel Reflections: 201 fps 4.9741 mspf 1006 rendered frames
Per Pixel Environment Mapping: 238 fps 4.1946 mspf 1192 rendered frames
Per Pixel Veined Marble Shader: 83 fps 12.1056 mspf 414 rendered frames
Per Pixel Wood Shader: 123 fps 8.1497 mspf 614 rendered frames
Fur Shader With Anisotropic Lighting: 13 fps 74.6269 mspf 67 rendered frames


ps2_0

Per Pixel Diffuse Lighting: 232 fps 4.3178 mspf 1158 rendered frames
Per Pixel Directional Light Shader (Phong): 160 fps 6.2657 mspf 798 rendered frames
Per Pixel Point Light Shader (Phong): 163 fps 6.1350 mspf 815 rendered frames
Per Pixel Spot Light Shader (Phong): 130 fps 7.6865 mspf 651 rendered frames
Per Pixel Anisotropic Lighting: 170 fps 5.8893 mspf 849 rendered frames
Per Pixel Fresnel Reflections: 201 fps 4.9702 mspf 1006 rendered frames
Per Pixel Environment Mapping: 238 fps 4.2088 mspf 1188 rendered frames
Per Pixel Environment Bump Mapping: 206 fps 4.8544 mspf 1030 rendered frames
Per Pixel Veined Marble Shader: 86 fps 11.6914 mspf 428 rendered frames
Per Pixel Wood Shader: 124 fps 8.0645 mspf 620 rendered frames
Fur Shader With Anisotropic Lighting: 13 fps 74.7435 mspf 67 rendered frames



Thomas

[Exxtreme]

Original geschrieben von tb
Leider läuft ps2_a auf der Radeon nicht richtig, was vorallem am D3DPS20CAPS_ARBITRARYSWIZZLE liegt. Hier die Shader, welche funktionierten:




*wegen Übersichtlichkeit... ihr wisst schon*


Thomas
Danke. :wink:

[Gast]

Hallo tb;

hast du die PS2_a Shader auch einmal mit den neuen deto's 51.75 ausprobiert?

Ändert sich dann was?


So wie es jetzt aussieht sind die PS2_a ja nicht gerade der Bringer. Einige Shader werden beschleunigt, andere sind sogar langsamer.

Ich hab das ganze mal in eine Tabelle gebracht und den Mittelwert ermittelt :

FX5900-U PS2.0 = 100%

FX5900-U PS2_a = 100,5% (!!!)

FX5900-U PS2.0-pp = 136,9%

FX5900-U PS2_a-pp = 138,2%


R9800Pro PS2.0 = 242,8%

R9800Pro PS2.0 = 171,5% ( Im Vergleich mit dem jeweils schnellsten Shader unter PS2.0-pp oder PS2_a-pp )


IMHO ist das ganze ziemlich enttäuschend. Kein Wunder, das Gabe so angefressen war. Weder der neue PS2_a HLSL-Pfad noch -PP bringen wirklich viel.

Was muss man eigentlich noch machen, um den FX'en Speed einzuhauchen? Der neue Treiber? Bringt der noch was? Und wenn ja, wieviel???

[Demirug]

das 2.A mit 4X.XX Treibern nur in Ausnahmefällen was bringt wurde von nv inzwischen öffentlich bestätigt. Mit dem 5X.XX soll es besser sein.

[LovesuckZ]

Original geschrieben von Demirug
das 2.A mit 4X.XX Treibern nur in Ausnahmefällen was bringt wurde von nv inzwischen öffentlich bestätigt. Mit dem 5X.XX soll es besser sein.

was funktioniert eigentlich im 4x.xx bezueglich der Shader?
(rhetorische Frage)
...

[Exxtreme]

Original geschrieben von Demirug
das 2.A mit 4X.XX Treibern nur in Ausnahmefällen was bringt wurde von nv inzwischen öffentlich bestätigt. Mit dem 5X.XX soll es besser sein.
Auf einmal?

D.h. also auch wenn Futuremark schon bei der Veröffentlichung des 3DMark03 das PS2_a-Profil in das Teil eingebaut hätten, dann wäre die Wahrscheinlichkeit sehr gering gewesen, daß es mit damaligen Treibern was gebracht hätte?

[Demirug]

Original geschrieben von Exxtreme
Auf einmal?

Bisher haten sie ja nichts dazu gesagt und offiziel ist 2.A ja auch kein NV3X Chip Profil.

D.h. also auch wenn Futuremark schon damals das PS2_a-Profil zur Verfügung gestanden hätte, dann wäre die Wahrscheinlichkeit sehr gering gewesen, daß es mit damaligen Treibern was gebracht hätte?

Keine Ahnung. Wenn es schon damals vorhanden gewessen wäre hätte man sich vielleicht früher darum gekümmert.

[Exxtreme]

Original geschrieben von Demirug
Bisher haten sie ja nichts dazu gesagt und offiziel ist 2.A ja auch kein NV3X Chip Profil.



Keine Ahnung. Wenn es schon damals vorhanden gewessen wäre hätte man sich vielleicht früher darum gekümmert.
Naja, also bei dem Aufstand, den NV gemacht hat damals wundert mich das schon, daß sie jetzt plötzlich sagen, daß es erst ab den Deto 5x.xx richtig klappt. :kratz:

[Gast]

Original geschrieben von Demirug
das 2.A mit 4X.XX Treibern nur in Ausnahmefällen was bringt wurde von nv inzwischen öffentlich bestätigt. Mit dem 5X.XX soll es besser sein.

Hört sich nach einer guten Begründung an. Hoffentlich ist es nicht wieder nur eine Ausrede. Langsam wird das ganze zur "Warten auf Godot" - Schau. Zuerst sollten der PS2.0_a - Pfad das "heil" bringen, jetzt die Deto 50er. Mal schauen wie lange wir auf wirklich aussagekräftige Benches warten müssen.

Außerdem: was haben die ach so hervorragenden Treiber-Schreiber bei Nvidia denn in den letzten 8 Monaten gemacht. Kaffee getrunken, die Füsse hochgelegt, gepennt, oder haben 95% von denen Urlaub gemacht.

[tb]

Original geschrieben von Gast
Hallo tb;

hast du die PS2_a Shader auch einmal mit den neuen deto's 51.75 ausprobiert?

Ändert sich dann was?


So wie es jetzt aussieht sind die PS2_a ja nicht gerade der Bringer. Einige Shader werden beschleunigt, andere sind sogar langsamer.

Ich hab das ganze mal in eine Tabelle gebracht und den Mittelwert ermittelt :

FX5900-U PS2.0 = 100%

FX5900-U PS2_a = 100,5% (!!!)

FX5900-U PS2.0-pp = 136,9%

FX5900-U PS2_a-pp = 138,2%


R9800Pro PS2.0 = 242,8%

R9800Pro PS2.0 = 171,5% ( Im Vergleich mit dem jeweils schnellsten Shader unter PS2.0-pp oder PS2_a-pp )


IMHO ist das ganze ziemlich enttäuschend. Kein Wunder, das Gabe so angefressen war. Weder der neue PS2_a HLSL-Pfad noch -PP bringen wirklich viel.

Was muss man eigentlich noch machen, um den FX'en Speed einzuhauchen? Der neue Treiber? Bringt der noch was? Und wenn ja, wieviel???

Hab leider keine gffx mehr (Testboard ging zurück) aber Leonidas kümmert sich mal drum.

Thomas

[aths]

Original geschrieben von Gast
ußerdem: was haben die ach so hervorragenden Treiber-Schreiber bei Nvidia denn in den letzten 8 Monaten gemacht. Kaffee getrunken, die Füsse hochgelegt, gepennt, oder haben 95% von denen Urlaub gemacht. Demirug hat's ja schon anklingen lassen: Man kann nicht so einfach einen Shader optimieren. Außerdem hat NV-Hardware "rechentechnisch" ohnehin Nachteile. Ich erwarte nicht, dass die 5900U in DX9 jemals auf 9800-Niveau kommt. NV braucht neue, leistungsfähigere Hardware. Den NV40.

[Razor]

Original geschrieben von LovesuckZ
was funktioniert eigentlich im 4x.xx bezueglich der Shader?
(rhetorische Frage)
...
Funktionieren tut doch eigentlich alles, oder ?
Ist halt derzeit nicht sonderlich schnelle, gelle ?
:D

Und die FX5900 wird mit ihren erweiterten Möglichkeiten wohl noch gar nicht unterstützt.
(auf die Shader bezogen ;-)

Razor

[Exxtreme]

Original geschrieben von Razor
Und die FX5900 wird mit ihren erweiterten Möglichkeiten wohl noch gar nicht unterstützt.
(auf die Shader bezogen ;-)

Razor
Anscheinend doch... zumindest was das PS2_A-Profil angeht. Thomas sagte doch, daß die R9800 einige PS2_A-Shader nicht ausführen kann.

[Razor]

Original geschrieben von Gast
Außerdem: was haben die ach so hervorragenden Treiber-Schreiber bei Nvidia denn in den letzten 8 Monaten gemacht. Kaffee getrunken, die Füsse hochgelegt, gepennt, oder haben 95% von denen Urlaub gemacht.
Nun ja...
Die neue Architektur läuft nun 100% kompatibel... das ist doch schon mal was !

Und auch die DX9-Proggi's laufen alle (inkl. 95% der ATI-Demo's ;-), wenn auch nicht sonderlich performant. Hätte man die R300'er mit ihren ersten Treibern beurteilen müssen, wäre wohl kaum was besseres raus gekommen, als jetzt bei nVidia.

Ergo: Abwarten !
nVidia muss jetzt zeigen, dass die neue Architektur auch mit ATI-optimierten Shadern zurecht kommt.

Razor

[Razor]

Original geschrieben von Exxtreme
Anscheinend doch... zumindest was das PS2_A-Profil angeht. Thomas sagte doch, daß die R9800 einige PS2_A-Shader nicht ausführen kann.
Das hat doch nix mit dem NV35 zu tun, sondern ganz allgemein mit den erweiterten Fähigkeiten der NV3x-Architektur. Es werden halt Features benutzt, die ein R3x0 schlicht und ergreifend nicht unterstützt. Die zukünftige PS3.0-Hardware wird dies aber können (müssen).

Razor

[Demirug]

Original geschrieben von Exxtreme
Anscheinend doch... zumindest was das PS2_A-Profil angeht. Thomas sagte doch, daß die R9800 einige PS2_A-Shader nicht ausführen kann.

Die Funktionen die 2.A nutzt haben alle NV3X Chips aber wie ich inzwischen erfahren habe hat jeder NV3X eine leicht modifizierte CineFX I oder II Einheit und der interne Shadercompiler muss darauf Rücksicht nehmen.

[ow]

.

[mayo]

Original geschrieben von ow
Macht das irgendwelchen Sinn oder wollte nV sich nur das Leben absichtlich so schwer wie möglich machen?

Das hat sich sicherlich mit den Verbesserungen zur CineFX II Architektur so ergeben. Ich denke nicht, dass NVIDIA sich noch selbst ausbremsen möchte.

[ow]

.

[Demirug]

Original geschrieben von ow
Macht das irgendwelchen Sinn oder wollte nV sich nur das Leben absichtlich so schwer wie möglich machen?

Frag mich doch nicht was nvidia sich so denkt. Ich nehme mal an das es unterschiede im Stageing sind.

Die Information ist jedenfalls von Sim Dietrich:

For one, the various chip flavors all differ in small ways in the shader that makes the driver want to do things a bit differently.

[Gast]

Original geschrieben von Gast
Hört sich nach einer guten Begründung an.

Ich noch mal. Hab über das Argument eine Nacht geschlafen und finde es überhaupt nicht mehr gut.

Warum sollten Nvidia und M$ ein neues Shaderprofil speziell für die NV3x-Architektur rausbringen, wenn es dann doch nicht für die NV3x-Architektur optimiert ist? ??? ???
Und kommt mir jetzt nicht mit den kleinen Unterschieden zwischen den einzelnen Chips. 1. siehe unten, und 2. erwarte ich das dieser speziell angepasste Compiler dann trotzdem min. 75-90% der max. möglichen Leistung erreicht. Sonst würde das ganze ja keinen Sinn machen.

Vor allem, warum der ganze Aufwand, wenn man dann doch wieder einen Treiber braucht, der den Shader wiederum komplett umstellt, damit es für die NV3x passt.

Irgendwie passt da was nicht zusammen. Vor allem hätte ich erwartet, das der PS2.0_a Pfad bereits für den NV35 optimiert ist, da das ja der Chip ist, der das Flagschiff ist und am meisten gebencht wird. Es macht für mich einfach wenig Sinn, was da im Moment abläuft.

[Demirug]

Ich kann hier nur das wiederholen was Sim Dietrich gesagt hat.

Der Compiler erzeugt ein sehr gutes Ergebniss kann aber nicht das optimale ergebniss erzielen weil er nicht über genügend Informationen verfügt.

Der eigene Compilerpfad ist aber erforderlich weil der 2.0 Pfad beim Compilieren von HLSL zu ASM ein paar Informationen vernichtet welche beim NV3X nutzbringend eingesetzt werden können.

[LovesuckZ]

Demirug bist du nicht schon in der Lage, den 51.75 zu begutachten?

[Demirug]

Original geschrieben von LovesuckZ
Demirug bist du nicht schon in der Lage, den 51.75 zu begutachten?

Leider nicht. Der Devsupport scheint gerade schwer im Stress zu sein. Die müssen sich scheinbar um einige Titel kümmern die noch vor Weihnachten raus müssen.

[nggalai]

Original geschrieben von Demirug
Leider nicht. Der Devsupport scheint gerade schwer im Stress zu sein. Die müssen sich scheinbar um einige Titel kümmern die noch vor Weihnachten raus müssen. Schau mal aufm Developers-Server von nvidia vorbei. Vor ein paar Tagen war der Treiber noch im Dev-Extranet.

93,
-Sascha.rb

[LovesuckZ]

Original geschrieben von nggalai
Schau mal aufm Developers-Server von nvidia vorbei. Vor ein paar Tagen war der Treiber noch im Dev-Extranet.
93,
-Sascha.rb

Da kommt ohne weiteres nicht ran, oder? :)

[x-dragon]

Original geschrieben von LovesuckZ
Da kommt ohne weiteres nicht ran, oder? :) Zumindest mußt du wohl diese Webseite überwinden :)

https://nvdeveloper.nvidia.com/login.asp

[Gast]

gut dass es den Gast Account gibt, da hef ich doch gern..

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

dort gibts den Link zum Treiber

10.10 MB gross, natürlich Beta, man beachte das bekannte:
laut Valve IQ reduzierende Wirkung in HL2(beta)
laut Driverheaven starker IQ Verzerrung(Verlust) bei Aquamark3: http://www.driverheaven.net/articles/aquamark3/index3.htm

so dann mal viel Spass

sollte der Link nich mehr funzen ich hab's auf Platte und kann's per ICQ verschicken, Nummer geb ich lieber nur auf Anfrage preis..

[Gast]

gerade gelesen :

However, for me Gabes presentation at Shader Day wasn't actually the most eye opening - it was Eric's presentation that really interested me because his R300 shader diagram actually shows that for some operations the R300 shader core can handle twice as many ops per cycle as we had previously thought. To put this in context: with the changes from NV30 to NV35 this puts the float performance of one of NV35 pipes at its best to more or less the number ops at R300 at its worst, and R300 has twice as many pipes (this is over simplified).


DaveBaumann meint hier die Rohleistung. Also ohne die ganzen Register/Treiber-Probleme die die NV3x haben.
In Summe : pro MHz unter den besten Umständen 50% der Leistung der R300/R350 - Karten.
Kein Wunder das nicht einmal die NV35 auf einen grünen Zweig kommt.

[Quasar]

Original geschrieben von Demirug
Frag mich doch nicht was nvidia sich so denkt. Ich nehme mal an das es unterschiede im Stageing sind.

Die Information ist jedenfalls von Sim Dietrich:

Das würde so einiges erklären, u.a. auch die unterschiedliche gerenderten Shader beim nV34 in Aquanox und Splinter Cell.... tststs... sowas dämliches aber auch.

[Gast]

man könnte es wohl zum Gesetz erklären, dass eine Grafikkartenfirma die Marktführer ist es irgendwann nicht mehr sein wird, weil Hybris sie bemannte.. bzw. "Faulheit"

[Gast]

Resultiert eigentlich die teils niedrige Performancediskrepanz, zwischen Radeon 9800Pro und 9600Pro daraus, das die Rohleistung der ShaderCores bei beiden Modellen nahezu äquivalent ist?

Bei der FX fungiert der Shader-Core als universal FPU während ATI dedizierte ALU und FPU Einheiten implementiert hat.
Wenn der Shader-Core der 9600Pro also nicht kastriert wurde, wäre das vielleicht ein Indikator für die teils überragenden Results der 9600Pro im H² Prebench, oder?

[Aquaschaf]

Die Shaderleistung der 9600 Pro ist gegenüber der 9800 Pro ziemlich genau halbiert, imo liegt da wohl bei der 9800 Pro eine CPU Limitierung vor.

[Gast]

Kann das mal jemand etwas genauer aufschlüsseln?

Wie sind diesbezüglich die Meinungen der anderen?

[Gast]

Original geschrieben von Aquaschaf
Die Shaderleistung der 9600 Pro ist gegenüber der 9800 Pro ziemlich genau halbiert, imo liegt da wohl bei der 9800 Pro eine CPU Limitierung vor.

Das würde, wie schon öfter angesprochen, aber nicht den nicht vorhandenen Abfall von 1024 zu 1280 bei der R9600p erklären. Zumal sich in 1024 ja die R9800 deutlich über diese CPU-Limitierung hinwegsetzen könnte.

Dem Rest stimme ich zu.

[Gast]

Original geschrieben von Aquaschaf
Die Shaderleistung der 9600 Pro ist gegenüber der 9800 Pro ziemlich genau halbiert, imo liegt da wohl bei der 9800 Pro eine CPU Limitierung vor.

Stimmt !!

Schaut euch einfach den entsprechenden Artikel auf Beyond3D an. Da sieht man dies sehr gut. Die "Bechmarklinie" der R9800Pro ist nahezu ein gerader Strich => CPU-limitiert. Sieht man sehr schön mit den MPixel/sec - Grafiken bei denen.
Deshalb ist bei der R9800Pro AA+AF meistens frei, bzw fast frei.

Ach ja, die haben auch noch ein Excel-Sheet mit allen Benchmarks, die an diesem Tag gemacht wurden.

Außerdem wurde das Missverständnis FX5600 / FX5600-Ultra geklärt. Gebencht wurde eine FX5600-Ultra.

[Gast]

Original geschrieben von Gast
Stimmt !!

Schaut euch einfach den entsprechenden Artikel auf Beyond3D an. Da sieht man dies sehr gut. Die "Bechmarklinie" der R9800Pro ist nahezu ein gerader Strich => CPU-limitiert. Sieht man sehr schön mit den MPixel/sec - Grafiken bei denen.
Deshalb ist bei der R9800Pro AA+AF meistens frei, bzw fast frei.

Ach ja, die haben auch noch ein Excel-Sheet mit allen Benchmarks, die an diesem Tag gemacht wurden.

Außerdem wurde das Missverständnis FX5600 / FX5600-Ultra geklärt. Gebencht wurde eine FX5600-Ultra.

heißt das die 9800pro könnte sich mit schnelleren cpus noch viel weiter absetzen in hl2 von der fx5900U als jetz schon ? :krank:

[Exxtreme]

Original geschrieben von Gast
heißt das die 9800pro könnte sich mit schnelleren cpus noch viel weiter absetzen in hl2 von der fx5900U als jetz schon ? :krank:
Theoretisch ja... wenn tatsächlich eine CPU-Limitierung vorliegt.

[Gast]

Hallo Exxtreme;

also, wenn man sich die folgenden Benchmark-Ergebnisse anschaut, dann sieht man sehr schön, das die R9800Pro meistens CPU-Limitiert ist :

http://www.beyond3d.com/misc/hl2/index.php?p=6

e3-techdemo : hier sollte keine CPU-Limitierung vorliegen, da die Füllrate-Kurve ab 1024x768 abknickt. Die R9800Pro ist hier aber auch wesentlich schneller als die FX-5900-U

e3-bugbait + e3 c17_02 : hier liegt ganz klar eine CPU-Limitierung vor, da die R9800Pro bei keiner Auflösung "einknickt" sondern immer so schnell läuft wie irgend möglich. Man kann im Excel-Sheet dann auch sehr gut sehen, das es bei diesen beiden Settings fast keine Auswirkung von AA+AF auf die Framerate gibt. Ergo ganz klar CPU-limitiert.


The e3 techdemo test is actually the least of the CPU limited test for the 9800 PRO, as this does contain lots of different shaders. Both the 9600 PRO and 5900 Ultra show that they are very limited by their shader performance, although the 9600 PRO less so than the 5900. The next two demos are much more representative of levels from within the game, and although the 9800 PRO is more or less completely CPU bound in all tested resolutions and the 9600 PRO a little less shader bound, the 5900 is still showing that it is much more limited by its shader performance.


In HL2 wird die R9800Pro also meistens CPU-Limitiert sein. Bei 1024x768 zu 100% ( auch bei einer P4 3.2GHz; A64 vielleicht nicht ); und bei 1280x1024 bei den meisten Rechnern da draußen. Das heißt fast alle da draußen kriegen AA+AF for free (solange sie eine R9800Pro haben)

Ich bin schon auf die ersten Screenshots in 1600x1200 mit 4xAA + 16xAF + HDR gespannt. Vor allem auf HDR, das die FX-Karten ja nicht können, da sie die entsprechende Funktion unter DX9 nicht unterstützen bin ich gespannt.

[Exxtreme]

Hmmm, laut Eric Dremers (aka sireric) ist der PS-Compiler in den Catalyst-Treibern nur spärlich optimiert. :o

"We are working hard on improving our current PS compiler, so that it can map PS ops to our HW in an optimal way. The current stuff is pretty simple. The HW is naturally very fast and executes well. However, it will get better. That's also why one should be careful when trying to determine our internal architecture based on shader code."


Ich möchte nicht wissen, wie das Teil abgeht wenn ATi das Teil optimiert.

http://www.beyond3d.com/forum/viewtopic.php?t=8005&postdays=0&postorder=asc&start=0

^^ Da gibt es auch noch andere gute Informationen über die Shader-Units der beiden Kontrahenten.

[del_4901]

Original geschrieben von Gast
Hallo Exxtreme;

also, wenn man sich die folgenden Benchmark-Ergebnisse anschaut, dann sieht man sehr schön, das die R9800Pro meistens CPU-Limitiert ist :

http://www.beyond3d.com/misc/hl2/index.php?p=6

e3-techdemo : hier sollte keine CPU-Limitierung vorliegen, da die Füllrate-Kurve ab 1024x768 abknickt. Die R9800Pro ist hier aber auch wesentlich schneller als die FX-5900-U

e3-bugbait + e3 c17_02 : hier liegt ganz klar eine CPU-Limitierung vor, da die R9800Pro bei keiner Auflösung "einknickt" sondern immer so schnell läuft wie irgend möglich. Man kann im Excel-Sheet dann auch sehr gut sehen, das es bei diesen beiden Settings fast keine Auswirkung von AA+AF auf die Framerate gibt. Ergo ganz klar CPU-limitiert.



In HL2 wird die R9800Pro also meistens CPU-Limitiert sein. Bei 1024x768 zu 100% ( auch bei einer P4 3.2GHz; A64 vielleicht nicht ); und bei 1280x1024 bei den meisten Rechnern da draußen. Das heißt fast alle da draußen kriegen AA+AF for free (solange sie eine R9800Pro haben)

Ich bin schon auf die ersten Screenshots in 1600x1200 mit 4xAA + 16xAF + HDR gespannt. Vor allem auf HDR, das die FX-Karten ja nicht können, da sie die entsprechende Funktion unter DX9 nicht unterstützen bin ich gespannt.

lol

Da liegt ein Fehler vor.

[Demirug]

Original geschrieben von Exxtreme
Hmmm, laut Eric Dremers (aka sireric) ist der PS-Compiler in den Catalyst-Treibern nur spärlich optimiert. :o

"We are working hard on improving our current PS compiler, so that it can map PS ops to our HW in an optimal way. The current stuff is pretty simple. The HW is naturally very fast and executes well. However, it will get better. That's also why one should be careful when trying to determine our internal architecture based on shader code."


Ich möchte nicht wissen, wie das Teil abgeht wenn ATi das Teil optimiert.

http://www.beyond3d.com/forum/viewtopic.php?t=8005&postdays=0&postorder=asc&start=0

^^ Da gibt es auch noch andere gute Informationen über die Shader-Units der beiden Kontrahenten.

Viel Optimieren müssen sie ja auch nicht mehr da MS schon einen grossen Teil dieses Job übernimmt. Der neue Compiler versucht inzwischen sogar Vec3 und Skalar-Ops paarweise anzuordnen.

Den Pipelinezeichnungen von Dave schenke ich ehrlich gesagt nicht allzuviel glauben. NV30 stimmt aber bei NV35 und R300/R350 bin ich anderer Meinung. Wenn es sich beim R300 auch nur um eine darstellungssache handelt.