Zusammenfassung: NV3x und die dx9 probleme...

[Hamster]

hi,

hier gibt es schon viele threads dazu, doch leider sind die relevanten info stets auf viele threads verteilt, oder diese sind ellenlang, oder aber die nötige info geht durch b45h1ng oder spam unter.

ich möchte hier versuchen nochmal alles zusammenzufassen. dies wird nicht komplett sein, deswegen hoffe ich auf eure mithilfe.


vorneweg: bitte versaut den thread nicht durch "fanboy" gehabe. mir geht es hier nur noch einmal um die gesammelten fakten, soweit dies möglich ist.
-----------------------------------------------------------


wie sich leider rausgestellt hat, sind die aktuellen nvidia karten (nv3x aka FX karten) bei der verwendung von dx9 ultralangsam. unter dx7 und dx8 als auch opengl performen diese aber superb und sind in diesem bereich vor ati führen oder zumindest gleichauf.
doch gerade dx9 bekommt immer weitere bedeutung. tragisch für all diejenigen die eine fx karte ihr eigen nennen (zb ich :)), und auf die akuell anstehenden dx9 kracher warten.
besitzer aktueller ati karten sind hier fein raus, da diese unter dx9 in einigen benchmarks weit das doppelte eine fx karte bei niedrigerem takt erreichen. mittlerweile dürfte jedem bekannt sein, dass die pixelshader 2.0 leistung der fx karten tatsächlich den radeon karten unterlegen ist. damit dürfte sich wohl jeder fx karten besitzer mit abfinden. jedoch ist der abstand teilweise so enorm, dass man das gar nicht glauben mag. allerdings werfen die aktuellen dx9 benchmarks (bzw die bekannten benchmark ergebnisse) einige fragen auf.
im aktuellen tomb rider 6 und in half-life 2 sehen die fx karten (auch nicht nvidias flagschiff fx5900ultra 256)gegenüber den radeons kein licht, und werden selbst von der kleinsten dx9 radeon (9500) teilweise kassiert. in anderen benchmarks wie dem aquamark3 und 3dmark2003 sind zwar die fx'en ebenfalls unterlegen allerdings nicht ganz so weit von radeons entfernt, so dass hier jeder fx besitzer noch zufrieden sein kann.

frage ist jetzt, kann und wird nvidia die leistung erhöhen können, so dass der leistungsunterschied vielleicht nur noch 20% ausmachen, und nicht mehr 80%, wie teilweise schon geschehen?

mögliche verbesserungen die den fx karten wiederfahren könnten um sie in einem besseren licht zu sehen:

1. spieleentwickler nutzen nvidias cg und/oder spendieren der fx einen eigenen renderpfad.
2. nvidia bringt einen neuen offiziellen treiber der 50er deto reihe heraus, die explizit erstmals die fx karten voll unterstützen.
3. microsoft integriert die eigenschaften der cinefx(II) in ihr dx9 kit.
4. unabhängige und "gute" benchmarks! tb6 scheint wohl sehr verbuggt zu sein, da stellt sich die frage ob er als benchmark was taugt. aquamark3 nutzt zu wenig ps 2.0 um als reinerdx9 bench annerkannt zu werden. 3dmark03 ist zu überoptmiert (oder wie andere sagen würde: hier wird gecheatet). und hl2 ist ebenfalls mit vorsicht zu geniessen, da ati technologiepartner ist, und es noch wirklich keine richtigen unabhängigen tests gibt (ganz abgesehen von den ungereimtheiten, dass eine fx5600 eine fx5900ultra kassiert)....


wie man sieht, viele wenn und abers. leider kann man imo z.zt. noch nicht wirklich die tatsächliche dx9 performance der nvidia karten beurteilen. dies wird sich hoffentlich bald mit der rausgabe von dem hl2 benchmark und dem neuen deto ändern. falls sich die zur zeit kursierenden halbwahrheiten als richtig herausstellen sollten, kann man jeden fx kartenbesitzer nur bemitleiden, da diese teilweise bis zu 800euro je nach ausführug kosten.

ich persönlich glaube, neine eher hoffe, dass nvidia leistungstechnisch noch etwas aufholen kann, so dass der leistungsabstand nicht mehr so krass ausfällt. denn bis auf die dx9 leistung sind die fx'en wirklich tolle karten (stichwot runtertakten, lüfterregelung, tempüberwachung dx7/8 und opgl leistung)



ps: korrigiert mich falls ich was vergessen oder falsch formuliert habe.
ps2: ich hoffe euch interessiert überhaupt mein geschwaffel :)

[Demirug]

Keine Ergänzungen/Korrekturen:

Unter OpenGL bricht die Performance auch ein sobald man die FP only Extensions (ARB2) nutzt oder die nVidia eigene Extension "falsch" benutzt.

Der nVidia compiler nennt sich Cg nicht cgi.

[nagus]

Original geschrieben von Hamster
... unter dx7 und dx8 als auch opengl performen diese aber superb und sind in diesem bereich vor ati führen oder zumindest gleichauf.
...

eher umgekehrt:

die leistung ist ganz ok, meistens hinter ati, manchmal gleich auf und praktisch nie schneller bei vergleichbarer bildqualität.

[Crushinator]

@nagus
Es ist schon einwenig übertrieben, was Du schreibst. Unter DX7 und 8 sind nämlich zumind. die Highend-Karten - diplomatisch ausgedrückt - meist mind. gleich schnell. =)

[nagus]

Original geschrieben von crushinator
@nagus
Es ist schon einwenig übertrieben, was Du schreibst. Unter DX7 und 8 sind nämlich zumind. die Highend-Karten - diplomatisch ausgedrückt - meist mind. gleich schnell. =)


nähhh.... egal jetzt. diese diskussion hatten wir schon 1000 mal.

fest steht, wenn nvidia so wieter macht und die NV40 wieder CineFX-elemente beinhaltet bzw. nur eine aufgebohrte version davon ist, könnte es ihnen 2004 schlecht ergehen.

[seahawk]

und da der NV40 anscheinend wieder mixed precision sein soll (laut Uttar)erwarte ich keine grundlegenden Verbesserungen, besonders nicht im Hinblick auf Loki.

[Andre]

Original geschrieben von nagus
nähhh.... egal jetzt. diese diskussion hatten wir schon 1000 mal.

fest steht, wenn nvidia so wieter macht und die NV40 wieder CineFX-elemente beinhaltet bzw. nur eine aufgebohrte version davon ist, könnte es ihnen 2004 schlecht ergehen.

"vorneweg: bitte versaut den thread nicht durch "fanboy" gehabe. mir geht es hier nur noch einmal um die gesammelten fakten, soweit dies möglich ist."

[Demirug]

Original geschrieben von seahawk
und da der NV40 anscheinend wieder mixed precision sein soll (laut Uttar)erwarte ich keine grundlegenden Verbesserungen, besonders nicht im Hinblick auf Loki.

Die Mixed Precisions sind nicht wirklich das Problem solange sie dafür sorgen das der Chip in der höchsten Genauigkeit genauso schnell wie die Konkurrenz ist und bei niedriger Genauigkeit schneller wird.

Die NV3X kranken aber daran das einfach zuviel rechneleistung den Bach runter geht sobald man in der höchten Genauigkeit mal ein paar Temp-Register nutzt.

[seahawk]

Dann müssten sie also in FP32 genauso schnell sein wie ATI in FP24.

Kann man die FP32 Einheiten eignetlich auch für FP16 nutzen oder liegen die in der Zeit wo mit FP16 gearbeitet wird brach. Könnte man die Transistoren nicht lieber in eine FP24 Einheit stecken ??

Ich hoffe das ist noch nicht zu OT.

[r@w]

Original geschrieben von nagus
nähhh.... egal jetzt. diese diskussion hatten wir schon 1000 mal.

fest steht, wenn nvidia so wieter macht und die NV40 wieder CineFX-elemente beinhaltet bzw. nur eine aufgebohrte version davon ist, könnte es ihnen 2004 schlecht ergehen.
Das wurde ihnen auch schon für 2003 'prophezeit'...
:D

Razor

[Demirug]

Original geschrieben von seahawk
Dann müssten sie also in FP32 genauso schnell sein wie ATI in FP24.

Genau

Kann man die FP32 Einheiten eignetlich auch für FP16 nutzen oder liegen die in der Zeit wo mit FP16 gearbeitet wird brach. Könnte man die Transistoren nicht lieber in eine FP24 Einheit stecken ??

Da sie jetzt schon mal mit dem FP32 angefangen haben sollen sie auch dabei bleiben.

Derzeit (NV3X) scheint es so das die unterschiede zwischen FP32 und FP16 wirklich nur durch die unterschiedliche Speichermenge im Registerfile kommen. Benutzt man nur ein Tempregister macht es keinen unterschied ob nun FP16 oder FP32 zum einsatz kommt. Es mag möglichweise ein oder zwei Befehle geben wo es dann noch einen unterschied macht aber das sind nicht die wirklich häufig gebrauchten Multiplikationen und Additionen.

Die Rechenwerke in den FPUs bestehen zu grossen Teilen als 1Bit Volladdieren und durch entsprechenden Verschaltung wäre es durchaus möglich aus der gleichen Anzahl von VA eine FP32 ALU zu bauen die alternativ auch 2 FP16 Befehle oder 2 FX16 Ops ausführen kann.

[betasilie]

Original geschrieben von r@w
Das wurde ihnen auch schon für 2003 'prophezeit'...
:D

Razor
Aha. NV ergeht es also gerade gut. Ich glaube das sieht das Managment der Firma anders, als die Fans.

[seahawk]

@ Demi.

Erstmal danke für die Antwort. Wenn ich Dich richtig verstehe ist es möglich, dass NV eine Einheit erstellt die sozusagen mal als 2xFP16 oder FX16 oder 1xFP32 arbeitet.

Wenn die also auch die Probleme mit dem Tempregistern in den Griff kriegen sollten sie eine ATI ähnliche Performance erreichen können. Unter PS/VS 2.0 müßten sie also mithalten können. (alles FP32, bzw. Vorteile haben wenn mixed Mode genutzt wird)

Wie sieht es im Hinblick auf PS/VS 3.0 aus. Ich habe eigentlich immer vermutet, dass die flexiblere Struktur der NV Chips unter 3.0 einen Vorteil haben müßte. Ist der Gedankengang falsch ? (Außerdem bin ich mir noch gar nicht klar wie PS/VS 3.0 bei einer R300 ähnlichen Chipstruktur ohne Performanceverluste laufen soll)

[Al-CAlifAX]

Zum Topicc ;)
Auch wenn Demirug mal sagte das Cg noch nicht ausgereift ist, habe ich die beta version drauf. Speedmäßig bringts derzeit null, was wohl an den treibern liegt. wobei das einzige spiel ja glaube ich TRAOD ist was Cg unterstützt. Was ich aber feststellen konnte und was mir zeigt das Cg doch net so schlecht werden kann. Das fehler die im Spiel TRAOD vorkamen mit dem 45er und 51 treiber bei AA oder besser gesagt im Spiel nachrednern an vorkamen, damit weg waren und ein sauberes ordentliches bild mit konstanter framrate gezeigt wurde. Und das ist für mich gesehen viel Wert. ;)

@Demirug, das mit den Tempregister macht mir schon sorgen. Weil wie will NV das lösen wenn ein spiel davon viel benutzt? Scheint mir fast unmöglich :(

[Al-CAlifAX]

Original geschrieben von seahawk
@ Demi.

Erstmal danke für die Antwort. Wenn ich Dich richtig verstehe ist es möglich, dass NV eine Einheit erstellt die sozusagen mal als 2xFP16 oder FX16 oder 1xFP32 arbeitet.

Wenn die also auch die Probleme mit dem Tempregistern in den Griff kriegen sollten sie eine ATI ähnliche Performance erreichen können. Unter PS/VS 2.0 müßten sie also mithalten können. (alles FP32, bzw. Vorteile haben wenn mixed Mode genutzt wird)

Wie sieht es im Hinblick auf PS/VS 3.0 aus. Ich habe eigentlich immer vermutet, dass die flexiblere Struktur der NV Chips unter 3.0 einen Vorteil haben müßte. Ist der Gedankengang falsch ? (Außerdem bin ich mir noch gar nicht klar wie PS/VS 3.0 bei einer R300 ähnlichen Chipstruktur ohne Performanceverluste laufen soll)

Jau das hatte ich auch die ganze zeit im Hinterkopf. War da nicht mal was das NV schon weg richtung 3.0 mit dem NV3x geebenet hat und ATi noch auf der alten Struktur aufbaut. Was für Ati ein komplett neues Design bedeuten müsste? Fragen über Fragen, der arme Demirug :P

[Demirug]

Original geschrieben von seahawk
@ Demi.

Erstmal danke für die Antwort. Wenn ich Dich richtig verstehe ist es möglich, dass NV eine Einheit erstellt die sozusagen mal als 2xFP16 oder FX16 oder 1xFP32 arbeitet.

Ja sowas ist machbar und zumindestens das 1*FP32/2*FP16 habe ich schon einmal in einem "Medien Prozessor" gesehen.

Wenn die also auch die Probleme mit dem Tempregistern in den Griff kriegen sollten sie eine ATI ähnliche Performance erreichen können. Unter PS/VS 2.0 müßten sie also mithalten können. (alles FP32, bzw. Vorteile haben wenn mixed Mode genutzt wird)

Ja wobei das Problem nicht wirklich gross ist und relative einfach durch einsatz von genügend Transitoren aus der Welt zu schaffen ist. Ich hoffe allerdings das man bei nv auch die Pipeline kürzer macht.

Wie sieht es im Hinblick auf PS/VS 3.0 aus. Ich habe eigentlich immer vermutet, dass die flexiblere Struktur der NV Chips unter 3.0 einen Vorteil haben müßte. Ist der Gedankengang falsch ?

Nein, die CineFX-Struktur ist nach wie vor auf PS 3.0 vorbereitet und VS 3.0 haben sie ja schon so gut wie.

Das einzige Problem das noch bleibt ist das sich PS 3.0 nicht so gut mit dem SIMD verträgt.

(Außerdem bin ich mir noch gar nicht klar wie PS/VS 3.0 bei einer R300 ähnlichen Chipstruktur ohne Performanceverluste laufen soll)

Da habe ich ehrlich gesagt auch keine Ahnung aber man weiss ja nicht wie viel wirklich für den R420 übernommen wurde. Ich habe ja schon mal gesagt das die Lösung möglicherweise der F-Buffer sein könnte.

[Demirug]

Original geschrieben von Al-CAlifAX
Zum Topicc ;)
Auch wenn Demirug mal sagte das Cg noch nicht ausgereift ist, habe ich die beta version drauf. Speedmäßig bringts derzeit null, was wohl an den treibern liegt. wobei das einzige spiel ja glaube ich TRAOD ist was Cg unterstützt. Was ich aber feststellen konnte und was mir zeigt das Cg doch net so schlecht werden kann. Das fehler die im Spiel TRAOD vorkamen mit dem 45er und 51 treiber bei AA oder besser gesagt im Spiel nachrednern an vorkamen, damit weg waren und ein sauberes ordentliches bild mit konstanter framrate gezeigt wurde. Und das ist für mich gesehen viel Wert. ;)

Bei TRAOD wurde bisher festgestellt das wenn man die "Orginalshader" benutzt diese an vielen stellen nur mit FP16 rechnen die Cg schader rechnen dagegen alles mit FP32.

@Demirug, das mit den Tempregister macht mir schon sorgen. Weil wie will NV das lösen wenn ein spiel davon viel benutzt? Scheint mir fast unmöglich :(

Die Tempregister werden immer nur pro Shader bestimmt und der MS-Compiler versucht sich da beim 2.0 Profil nicht unbedingt gross im sparen. Der Treiber hat da durchaus noch etwas Einsparungs Potenial. Allerdings gibt es da für jeden Shader ein limit unter das man nicht kommt und wenn das zu gross ist kann man auch nichts mehr machen.

[micki]

wäre es also die lösung jeglichen performanceproblems für NV wenn sie mehr register für tempvalues einbauen?... das kann doch nicht so einfach sein, oder? sonst hätten die das schon längst gemacht.

MfG
micki

[Al-CAlifAX]

Original geschrieben von Demirug
Bei TRAOD wurde bisher festgestellt das wenn man die "Orginalshader" benutzt diese an vielen stellen nur mit FP16 rechnen die Cg schader rechnen dagegen alles mit FP32.

Jo TRAOD ist durch den Cg Compiler fehlerfrei in der Darstellung im verhältnis zum normalen. begrüße ich schonmal ;)

Original geschrieben von Demirug
Die Tempregister werden immer nur pro Shader bestimmt und der MS-Compiler versucht sich da beim 2.0 Profil nicht unbedingt gross im sparen. Der Treiber hat da durchaus noch etwas Einsparungs Potenial. Allerdings gibt es da für jeden Shader ein limit unter das man nicht kommt und wenn das zu gross ist kann man auch nichts mehr machen.

Sag mal könnte NV nicht ne Softwarebasis (emu oder so) basteln womit man die tempregister auslagern könnte? oder wird das am ende noch mehr leistung verbrauchen? oder zu sehr CPU lastig werden?

[Demirug]

Original geschrieben von micki
wäre es also die lösung jeglichen performanceproblems für NV wenn sie mehr register für tempvalues einbauen?... das kann doch nicht so einfach sein, oder? sonst hätten die das schon längst gemacht.

MfG
micki

Es würde zumindestens einiges am Hauptproblem beseitigen. Denn wenn man fragt wie man seine Shader schneller bekommt gibt es immer die gleichen Tipps (in dieser Reihenfolge):

- So wenig wie möglich Temp-Register.
- FP16 nutzen wenn möglich
- Wenn möglich Berechnugen durch Texturen ersetzten.
- Shader an nv schicken zur Begutachtung.

was sie nun Abgehalten hat das Registerfile grösser zu machen kann ich aber auch nicht sagen. Aber der Hund ist definitive an dieser Stelle begraben wie einige Tests beweisen.

[Demirug]

Original geschrieben von Al-CAlifAX
Sag mal könnte NV nicht ne Softwarebasis (emu oder so) basteln womit man die tempregister auslagern könnte? oder wird das am ende noch mehr leistung verbrauchen? oder zu sehr CPU lastig werden?

Nein das würde noch langsamer werden. Sie können nur versuchen die Variablen in so wenig speicher zu drücken wie nur irgendwie möglich.

[micki]

Original geschrieben von Demirug
- Shader an nv schicken zur Begutachtung.


wenn man denen einen shader schickt, schauen die sich den echt persönlich an und geben eventuell ne optimierte version zurück?

ich hätte gedacht, dass die das nur für größere unternehmen machen...




ich hätte mal aber ne andere frage, wie aufwändig schätz du es ein, ein tool zu schreiben dass "offline" die assemblershader nimmt und optimiert, sodass sie auf NV und ATI karten fix laufen. man müßte bei der NV doch eigentlich nur den code parsen, dann (egal welcher befehl) die dependencies der variablen pro befehl rausfinden und versuchen sie so anzuordnen, dass möglichst wenig temps verbraucht werden... oder macht das der treiber schon??



ich weiß nämlich nicht so ganz, weshalb es ewigkeiten dauert bis derart simple optimierungstools endlich die versprochene performance rauskratzen...

gruesse
micki

[Demirug]

Original geschrieben von micki
wenn man denen einen shader schickt, schauen die sich den echt persönlich an und geben eventuell ne optimierte version zurück?

ich hätte gedacht, dass die das nur für größere unternehmen machen...

Ich habe es noch nicht auspropiert weil meine Shader ja dynamisch erzeugt werden. Sie bieten es aber immer wieder (auch öffentlich) an.

ich hätte mal aber ne andere frage, wie aufwändig schätz du es ein, ein tool zu schreiben dass "offline" die assemblershader nimmt und optimiert, sodass sie auf NV und ATI karten fix laufen. man müßte bei der NV doch eigentlich nur den code parsen, dann (egal welcher befehl) die dependencies der variablen pro befehl rausfinden und versuchen sie so anzuordnen, dass möglichst wenig temps verbraucht werden... oder macht das der treiber schon??

Zum teil macht das die 45er Reihe schon. Ich habe mal extra einen Shader mit 8 Temps programmiert und der Treiber hat mir davon so viel rausgeworfen das es am Schluss genauso schnell war wie die Version mit nur einem Temp-Register.

ich weiß nämlich nicht so ganz, weshalb es ewigkeiten dauert bis derart simple optimierungstools endlich die versprochene performance rauskratzen...

gruesse
micki

Wenn ich die nv-Jungs richtig verstanden habe gibt es da noch Seiteneffekte von den benutzten Texturen und Filtern. Daher ist es erforderlich das man nach einer Grundoptimierung nach dem anlegen des Shaders auch noch eine Detailoptimierung vornimmt. Diese Detailoptimierungen seien mit den 4X.XX nicht möglich gewesen. Mit den 5X.XX hätte man aber nun die Grundlagen dafür geschafen dies zu tun.

[aths]

Original geschrieben von Demirug
Nein das würde noch langsamer werden. Sie können nur versuchen die Variablen in so wenig speicher zu drücken wie nur irgendwie möglich. Zählen dazu eigentlich auch Konstanten?
Original geschrieben von Demirug
- Wenn möglich Berechnugen durch Texturen ersetzten.Die wollen also allen Ernstes lieber, dass man Vektoren per Cubemap normalisiert?

[Demirug]

Original geschrieben von aths
Zählen dazu eigentlich auch Konstanten?

Nein, Nur Temp-Register.

Die wollen also allen Ernstes lieber, dass man Vektoren per Cubemap normalisiert?

Scheint so wobei ich mir nicht sicher bin ob diese Aussage auch schon für solche Berechnungen gilt oder erst für komplexere Sachen.

[egdusp]

Original geschrieben von Demirug
Ich habe es noch nicht auspropiert weil meine Shader ja dynamisch erzeugt werden. Sie bieten es aber immer wieder (auch öffentlich) an.

Wie (Wozu) erzeugt man dynamische Shader? Ich dachte Shader wären dynamisch im Ergebnis aber statisch im Code (von PS30 Schleifen und Bedingungen mal abgesehen).

Dynamisch Shader (im Code) würde dann ja hinauslaufen auf ein Programm welches ein anderes programmiert.

mfg
egdusp

[Demirug]

Original geschrieben von egdusp
Wie (Wozu) erzeugt man dynamische Shader? Ich dachte Shader wären dynamisch im Ergebnis aber statisch im Code (von PS30 Schleifen und Bedingungen mal abgesehen).

Dynamisch Shader (im Code) würde dann ja hinauslaufen auf ein Programm welches ein anderes programmiert.

mfg
egdusp

Es ist mehr ein zusammensetzten von einzelnen vorgefertigten Teilen. Notwendig ist das ganze weil man auf Dauer nur so das Problem mit der Unzahl von möglichen Kombinationen aus Material, Beleuchtung und Geometrie Effekten in den Griff bekommt. Im Moment ginge es auch noch ohne so etwas aber spätestens wenn man anfängt Materialen und Lichtquellen wirklich zu berechnen kommt man um solche Techniken nicht mehr herum.