GF FX5900Ultra in Tomb Raider AoD

[Gast]

Hallo Leute;

ich poste das ganze einmal hier im (hoffentlich) Flamewars aus dem Weg zu gehen :

von Beyond3D :

http://www.beyond3d.com/forum/viewtopic.php?t=7422&sid=15ece4bb4b5dc60fd1383be9302582ac

http://www.gzeasy.com/ours/cho/nocg.jpg

http://www.gzeasy.com/ours/cho/cg1.1.jpg

http://www.gzeasy.com/ours/cho/nocg_9800p.jpg


Schaut nicht gut aus für die GeforceFX - Reihe.

Hier noch ein Kommentar von DaveBaumann in einem anderen Thread :


With the full PS.20 effects enabled in TR:AOD 9800 PRO currently looks to be about 2.5x-3x faster than 5900 Ultra.


Damit sollte die FX5900Ultra ungefähr so schnell sein wie die R9600Pro. Mein Kommentar dazu : autsch!!


Der Cg-Compiler hilft also (zumindest hier) nicht bei der Performance, schadet aber der R9800. Die Frameraten gehen incl. Cg von 82fps auf 58fps zurück. Das sind 30-40% (je nach dem wie man rechnet ). Cg ist also schon schädlich für ATi, trotzdem ist eine R9800Pro immer noch wesentlich schneller als eine FX5900Ultra

[Aquaschaf]

naja, ich würde die Schuld in dem Fall den Entwicklern von TB AOD zuschieben.

[Demirug]

Das hat aber lange gedauert bis das mal jemand merkt. :D

Für einen FX Chip nimmt man eigentlich nicht das 2.0 Profil sondern das 2.X Profil. Das 2.0 Profil in Cg ist eigentlich total für die Tonne. Es erzeugt die von FX Chips bevorzugte Reihenfolge benutzt aber nicht die erweiterten Möglichkeiten der Chips. Aber wenn die Tonne schon mal auf ist werfen wir das 2.X Profil gleich mal hinterher. Das taugt nämlich auch nichts. DX Pixelshader >= 2.0 kann der Cg Compiler einfach nicht effektiv bauen da er dazu neigt zu viele Anweisungen zu brauchen.

Beispiel: Ein Einfacher HLSL Shader auf 4 Arten erzeugt.

Cg 2.0 35 Ops 4 Temps
Cg 2.X 34 Ops 4 Temps
MS 2.0 31 Slots 6 Temps
MS 2.A 29 Slots 4 Temps

Erschwerden kommt hinzu das eine Op mehr als einen Slot belegen kann. ich habe die Cg Shader aber jetzt nicht in Slots umgerechnet (Zu Faul).

Was lernen wir daraus? Sollte sich nv nicht dazu entschliessen die DX PS-Profile auf vorderman zu bringen lässt man besser die Finger weg.

Bei den Vertexshader dagegen ist komischerweise der Cg Compiler oft etwas besser als der MS-Compiler. Nur an den Vertexshader hängt es ja nicht so oft.

[LovesuckZ]

Anscheinend liegt der massive Performancedrop auch damit zusammen:

We do have a couple of issues with the way the boards handle the DOF effects though - the Radeon boards do it in a very controlled fashion, and its only really seen where you would expect to see it; the FX's are much more indescriminate with it use and blurr the scene all over the place, including areas where it just plain isn't needed.

http://www.beyond3d.com/forum/viewtopic.php?p=154473#154473

[Razor@Work]

Mich würde viel eher interessieren, wie der Poster das gemacht haben will...
Liegen die Shader im Source-Code vor, oder wie soll man so etwas verstehen ?
???

Razor

[Gast]

@Demirug

Warum hat man da wohl nicht den sekundären Zielpfad des Compilers für's DX9-SDK benutzt ?
???

Razor

[Quasar]

Original geschrieben von Razor@Work
Mich würde viel eher interessieren, wie der Poster das gemacht haben will...
Liegen die Shader im Source-Code vor, oder wie soll man so etwas verstehen ?
???

Razor

Wieso? Das kannst du in den Optionen von TRAOD einstellen.

[Razor@Work]

Original geschrieben von LovesuckZ
Anscheinend liegt der massive Performancedrop auch damit zusammen:

We do have a couple of issues with the way the boards handle the DOF effects though - the Radeon boards do it in a very controlled fashion, and its only really seen where you would expect to see it; the FX's are much more indescriminate with it use and blurr the scene all over the place, including areas where it just plain isn't needed.

http://www.beyond3d.com/forum/viewtopic.php?p=154473#154473
Woran das nun hängt, ist nur schwer zu sagen...
Abschalten konnte man dies, wenn man den Nebel deaktiviert.
(blurr weg, PS2.0 da, Perforamnce erträglich ;-)

Razor

[Exxtreme]

Original geschrieben von Gast
@Demirug

Warum hat man da wohl nicht den sekundären Zielpfad des Compilers für's DX9-SDK benutzt ?
???

Razor
Das Teil ist AFAIK noch ziemlich Beta (also in Wirklichkeit Pre-Alpha :D ).

[Razor@Work]

Original geschrieben von Quasar
Wieso? Das kannst du in den Optionen von TRAOD einstellen.
Ich meinte das recompilieren der Shader unter Cg...
;-)

Razor

[Demirug]

Original geschrieben von Razor@Work
Mich würde viel eher interessieren, wie der Poster das gemacht haben will...
Liegen die Shader im Source-Code vor, oder wie soll man so etwas verstehen ?
???

Razor

Das ist der Thread aus dem die Bilder kommen: http://www.beyond3d.com/forum/viewtopic.php?t=7422

Scheinbar reicht es einen Cg-Compiler auf der Platte zu haben um die Option freizuschalten. Die Shader liegen daher wohl als HLSL Code vor.

[Razor@Work]

Original geschrieben von Exxtreme
Das Teil ist AFAIK noch ziemlich Beta (also in Wirklichkeit Pre-Alpha :D ).
Wus ?

[Demirug]

Original geschrieben von Exxtreme
Das Teil ist AFAIK noch ziemlich Beta (also in Wirklichkeit Pre-Alpha :D ).

Beta ist es inzwischen wohl schon aber zu dem Zeitpunkt als TRAOD Gold gegangen ist war das wohl doch zu heiss. Und wenn man dort wirklich den Shadercode zur Laufzeit kompliert dann durfte man den neuen Compiler ja gar nicht nutzen weil er noch nicht an Endkunden gegeben werden darf.

[Gast]

Original geschrieben von Demirug
Das ist der Thread aus dem die Bilder kommen: http://www.beyond3d.com/forum/viewtopic.php?t=7422

Scheinbar reicht es einen Cg-Compiler auf der Platte zu haben um die Option freizuschalten. Die Shader liegen daher wohl als HLSL Code vor.
Habe ich das jetzt richtig verstanden ?
Er reicht, die Cg-Umgebung zu installieren und schon taucht eine zusätzliche Option im Game-Menü auf, die es erlaubt, die Shader unter Cg zu compilieren ?
:kratz:

Wurden die Shader des Games also unter Cg geschreiben ?
Also irgendwie...

Razor

[Exxtreme]

Original geschrieben von Demirug
Die Shader liegen daher wohl als HLSL Code vor.
Also wenn das stimmt, dann dürfte die Qualität des Cg-Compilers mehr als bescheiden sein, oder?

Interessant ist auch wie die Radeon einbricht.

[Quasar]

Original geschrieben von Gast
Habe ich das jetzt richtig verstanden ?
Er reicht, die Cg-Umgebung zu installieren und schon taucht eine zusätzliche Option im Game-Menü auf, die es erlaubt, die Shader unter Cg zu compilieren ?
:kratz:

Wurden die Shader des Games also unter Cg geschreiben ?
Also irgendwie...

Razor

Genau, die Option ist auch ohne cg-Compiler schon da, allerdings ausgegraut, IIRC.

[Demirug]

Original geschrieben von Gast
Habe ich das jetzt richtig verstanden ?
Er reicht, die Cg-Umgebung zu installieren und schon taucht eine zusätzliche Option im Game-Menü auf, die es erlaubt, die Shader unter Cg zu compilieren ?
:kratz:

Wurden die Shader des Games also unter Cg geschreiben ?
Also irgendwie...

Razor

jeder (OK Fast jeder) HLSL Shader lässt sich ohne Probleme durch den Cg Compiler jagen. Auf diese Art habe ich ja auch den Test da oben gemacht. Ein HLSL Shader einfach durch die beiden Compiler mit jeweils unterschiedlichen Profilen gejagt.

[Quasar]

Original geschrieben von Exxtreme
Interessant ist auch wie die Radeon einbricht.

Ja, sowas passiert anscheinend noch anderen Chips, wenn man die Reihenfolge der Instruktionen von "optimal" auf "suboptimal" ändert.

In etwa invers analog zu den Shadern des 3DMark mit und ohne "unerlaubte-Optimierungs-Treiber".

[Demirug]

Original geschrieben von Exxtreme
Also wenn das stimmt, dann dürfte die Qualität des Cg-Compilers mehr als bescheiden sein, oder?

Liest hier eigentlich jemand was ich schreibe? Der lange Text da oben^^.

Interessant ist auch wie die Radeon einbricht.

Nein, das ist eigentlich völlig verständlich.

[Razor@Work]

Original geschrieben von Demirug
jeder (OK Fast jeder) HLSL Shader lässt sich ohne Probleme durch den Cg Compiler jagen. Auf diese Art habe ich ja auch den Test da oben gemacht. Ein HLSL Shader einfach durch die beiden Compiler mit jeweils unterschiedlichen Profilen gejagt.
Das ist mir schon klar...
Meine Frage bezog sich auf TR6.
Kann man dort via Game-Menü die Compiler-Umgebung wählen, oder wie funktioniert das ?
???

Razor

[Quasar]

Original geschrieben von Razor@Work
Das ist mir schon klar...
Meine Frage bezog sich auf TR6.
Kann man dort via Game-Menü die Compiler-Umgebung wählen, oder wie funktioniert das ?
???

Razor

Jaaaaaaa. (s.o.)

[Demirug]

Original geschrieben von Razor@Work
Das ist mir schon klar...
Meine Frage bezog sich auf TR6.
Kann man dort via Game-Menü die Compiler-Umgebung wählen, oder wie funktioniert das ?
???

Razor

Ja in dem riesigen Dialog gibt es eine Option "Use Cg" (oder so ähnlich) die aber erst anwählbar wird wenn man den Cg Compiler nachträglich instaliert.

[Exxtreme]

Original geschrieben von Demirug
Liest hier eigentlich jemand was ich schreibe? Der lange Text da oben^^.

Doch, habe ich getan. Das Lustige ist aber, daß selbst NV es nicht schafft, die GFFX richtig auszunutzen. Wenn die Shader im HLSL-Format vorliegen, dann ist das eigentlich optimal um optimieren zu können.

[Demirug]

Original geschrieben von Exxtreme
Doch, habe ich getan. Das Lustige ist aber, daß selbst NV es nicht schafft, die GFFX richtig auszunutzen. Wenn die Shader im HLSL-Format vorliegen, dann ist das eigentlich optimal um optimieren zu können.

Ja weil die DX9 Profile in Cg einfach nur schwach sind. Aber warum sollte man sich bei nv auch noch gross darum kümmern nachdem man ja schon den Entwicklern rät den MS Compiler für reine DX Projekte zu benutzen. MS bekommt von nv genügend Knowhow und Leute zur Verfügung gestellt um das 2.A Profil für die Fxen anzupassen. Wobei soviel Knowhow muss nv da gar nicht rausrücken.

[Exxtreme]

Original geschrieben von Demirug
Ja weil die DX9 Profile in Cg einfach nur schwach sind. Aber warum sollte man sich bei nv auch noch gross darum kümmern nachdem man ja schon den Entwicklern rät den MS Compiler für reine DX Projekte zu benutzen. MS bekommt von nv genügend Knowhow und Leute zur Verfügung gestellt um das 2.A Profil für die Fxen anzupassen. Wobei soviel Knowhow muss nv da gar nicht rausrücken.
Für was wurde dann Cg eigentlich entwickelt wenn es so obsolet ist?

[Demirug]

Original geschrieben von Exxtreme
Für was wurde dann Cg eigentlich entwickelt wenn es so obsolet ist?

Es ist nicht generell obsolet sondern nur für DX. Und für DX war es eben die Übergangslösung bis der MS-Compiler kommt damit die Entwickler schon mal anfangen konnte Hochsprachenshader zu nutzen.

[Tigerchen]

Original geschrieben von Demirug
Es ist nicht generell obsolet sondern nur für DX. Und für DX war es eben die Übergangslösung bis der MS-Compiler kommt damit die Entwickler schon mal anfangen konnte Hochsprachenshader zu nutzen.

Nur liegt mir Richthofen schon seit vorigem Sommer in den Ohren daß cg die Zukunft sei und ATI-User deshalb in Zukunft auf viel Eye-Candy verzichten müßten.So recht glauben wollte ich das nie,aber daß cg so eine Krückstocklösung ist hätte ich nicht gedacht.

[Quasar]

Original geschrieben von Demirug
Es ist nicht generell obsolet sondern nur für DX. Und für DX war es eben die Übergangslösung bis der MS-Compiler kommt damit die Entwickler schon mal anfangen konnte Hochsprachenshader zu nutzen.

nV-freundlich formuliert könnte man also sagen, dass sie das Erscheinen von echten (ich nenn's mal abstrakt) "Shader"-Spielen um mindestens die Differenz der Erscheinungstermine von cg und dem MS HLSL-Compiler vorangebracht haben, da sie durch dieses Programm den Entwicklern um so viel mehr Zeit gegeben haben.

Schlimme Technologiebremse, die nV immer darstellt...

[Demirug]

Original geschrieben von Quasar
nV-freundlich formuliert könnte man also sagen, dass sie das Erscheinen von echten (ich nenn's mal abstrakt) "Shader"-Spielen um mindestens die Differenz der Erscheinungstermine von cg und dem MS HLSL-Compiler vorangebracht haben, da sie durch dieses Programm den Entwicklern um so viel mehr Zeit gegeben haben.

Schlimme Technologiebremse, die nV immer darstellt...

Auf einen Zeitrahmen würde ich mich da nicht festlegen wollen. Da ganze ist dürfte sehr stark vom jeweiligen Studio abhängig sein. So gibt es ja jetzt noch genügend Entwickler die Shaderhochsprachen für Teufelswerk halten weil sie glauben dadurch die Kontrolle zu verlieren. Diesen Leuten würde ich gerne mal einen TriMedia zum programmieren geben oder noch besser sollen sie die FPU einer CineFX Pixel Pipeline mal direkt ansteuern dann wüsten sie wie viel Kontrolle sie mit DirectX Assembler wirklich haben.

[Exxtreme]

Original geschrieben von Quasar
nV-freundlich formuliert könnte man also sagen, dass sie das Erscheinen von echten (ich nenn's mal abstrakt) "Shader"-Spielen um mindestens die Differenz der Erscheinungstermine von cg und dem MS HLSL-Compiler vorangebracht haben, da sie durch dieses Programm den Entwicklern um so viel mehr Zeit gegeben haben.

Schlimme Technologiebremse, die nV immer darstellt...
Naja, die Entwickler sind schon viele Monate vor dem offiziellen Veröffentlichungstermin von DirectX 9 mit Beta-Versionen versorgt worden. Von daher sehe ich das nicht als kritisch an. Und da Cg angeblich Shader-Quellcode-kompatibel zu der HLSL von DX9 ist, konnte NV auch nicht viel früher damit anfangen.

[Demirug]

Original geschrieben von Exxtreme
Naja, die Entwickler sind schon viele Monate vor dem offiziellen Veröffentlichungstermin von DirectX 9 mit Beta-Versionen versorgt worden. Von daher sehe ich das nicht als kritisch an. Und da Cg angeblich Shader-Quellcode-kompatibel zu der HLSL von DX9 ist, konnte NV auch nicht viel früher damit anfangen.

Was öffentliche Release angeht hat Cg fast ein halbes Jahr gebracht und es gibt Studios die arbeiten grundsätzlich nicht mit DX Betas. Und mit Cg hatte man dann immerhin einen Compiler für DX8 zur Hand. Ich vermute auch das daher noch der Cg Support in TR AOD herrührt.

Aber die Sache ist mühsellig weil wenn man möchtet findet man Argumente für und gegen Cg und in einer Tabelle in der man HLSL, Cg und gslang miteinader vergleicht würde Cg wohl gar nicht so schlecht abschneiden aber das ist eine Frage der persönlichen Situation. Für jemanden der reine DX Projekte schreibt ist Cg kaum sinnvoll.

[Razor]

Ich weiß... das gehört hier zwar nicht hin, aber ich muss das trotzdem mal los werden !

CgSetup (1.1), dann im 'Settings-Menü' VOR dem Start des Games 'Use Cg' angehakt und alles aktiviert, was nicht niet- und nagelfest ist... auch den Fog... und was soll ich sagen ?

Es funzt !

Nix geblurre mehr... nun läuft das Game auch mit Fog (als Beispiel auf dem Dach in der ersten Scenerie sehr, sehr wirkungsvoll ;-). Und schon wieder wurde ein Bug ohne Patch beseitigt...
:D

Und es läuft suuuuuper flüssig mit 2xAA/4xAF !
(mehr hab' i noch net ausprobiert ;-)

Bis denne

Razor

[Salvee]

Original geschrieben von LovesuckZ
Anscheinend liegt der massive Performancedrop auch damit zusammen:

We do have a couple of issues with the way the boards handle the DOF effects though - the Radeon boards do it in a very controlled fashion, and its only really seen where you would expect to see it; the FX's are much more indescriminate with it use and blurr the scene all over the place, including areas where it just plain isn't needed.

http://www.beyond3d.com/forum/viewtopic.php?p=154473#154473

DOF zieht schon mächtig Leistung in dem Game, allerdings dürfte es zumindest in der Szenerie auf den Screenshots wenig bis gar keine Auswirkung haben
(bei der dargestellten Sichtweite von höchstens 3 Metern).

Edit: @ Demirug
Irgendwie kommt es mir vor, als könntest du dich auf einmal 'freier von der Leber weg' über Cg äussern :)

[Demirug]

Original geschrieben von Salvee
Edit: @ Demirug
Irgendwie kommt es mir vor, als könntest du dich auf einmal 'freier von der Leber weg' über Cg äussern :)

Ich darf das schon die ganze Zeit. Die Situation hat sich in den letzten Tagen nur entscheident geändert. Es wurde offentsichtlich das nVidia in Sache Shaderhochsprache und DX die Resourcen jetzt verstärkt direkt bei Microsoft einbringt (Es waren deswegen aber schon immer nv Leute mit MS im ständigen Austausch) und dafür die eigene Produktline "vernachlässigt". Es ist daher vorerst nicht damit zu rechnen das sie die Pixelshader Profile noch verbessern. Ist für mich aber kein Problem da ich in diesem Punkt variable bin und den compiler nehme der die besten ergebnisse bringt. Sollte sich die gemachten Stichproben bestätigen dann könnte es durchaus sein das ich für die Vertexshader den Cg Compiler benutze und für die Pixelshader den von Microsoft. Aber ich warte da erst noch auf die finale Version des neuen MS-Compilers.

[Exxtreme]

Original geschrieben von Razor

Es würde mich nicht wundern, wenn auch der Cg-Compiler den 2.0 und nicht den 2.x zum compilieren nutzte.
Das spielt keine Rolle ob 2.0 oder 2.0+ zum Einsatz kam. Wichtig ist eigentlich die Anweisungsreihenfolge und Registernutzung. Und anscheinend erzeugt der Cg-Compiler einen Code, der weder der R3x0, noch der NV3x schmeckt. Würde nämlich das Shaderprofil PS2_0 zum Einsatz kommen, dann würde die R3x0 nicht einbrechen.

[Demirug]

Original geschrieben von Exxtreme
Das spielt keine Rolle ob 2.0 oder 2.0+ zum Einsatz kam. Wichtig ist eigentlich die Anweisungsreihenfolge und Registernutzung. Und anscheinend erzeugt der Cg-Compiler einen Code, der weder der R3x0, noch der NV3x schmeckt.

Es spielt schon eine Rolle ob man 2.0 oder 2.X benutzt. Mit 2.X lassen sich Instruktionen einparen.

Der Cg Compiler erzeugt in der vorliegenden Version vorzugsweise aber zu langen Code.

Es könnte ja mal jemand der TR6 hat mit 3dA die Shader protokolieren lassen. Einmal die original und einmal die mit Cg erzeugten dann könnte man sicherlich mehr sagen.

[Exxtreme]

Original geschrieben von Demirug
Es spielt schon eine Rolle ob man 2.0 oder 2.X benutzt. Mit 2.X lassen sich Instruktionen einparen.

Ja, aber das erklärt nicht den Einbruch bei der R3x0 wenn da tatsächlich 2.0 zum Einsatz kam.

[Razor]

Original geschrieben von Exxtreme
Ja, aber das erklärt nicht den Einbruch bei der R3x0 wenn da tatsächlich 2.0 zum Einsatz kam.
Natürlich erklärt das den Einbruch... der 2.0-Zielpfad ist einfach... schlecht.
:D

Razor

[Exxtreme]

Original geschrieben von Razor
Natürlich erklärt das den Einbruch... der 2.0-Zielpfad ist einfach... schlecht.
:D

Razor
Halte ich für ein Gerücht.

[Demirug]

Original geschrieben von Exxtreme
Ja, aber das erklärt nicht den Einbruch bei der R3x0 wenn da tatsächlich 2.0 zum Einsatz kam.

Doch :D

Also nochmal etwas aufürlicher.

Benutzt man den Cg Compiler mit dem PS 2.0 oder PS 2.X so erzeugt er immer Code mit möglichst wenigen Temp-Register und in einer bestimmten von NV3X Chips bevorzugten Anweisungsfolge. Dabei braucht er aber für den gleichen Effekt tendenziel mehr Anweisungen als der MS-Compiler. Der Unterschied zwischen 2.0 und 2.X ist nun das 2.0 nur das benutzt was ein normale 2.0 Chip auch kann. Das 2.X Profil nutzt nun die erweiteten Fähigkeiten um Instruktionen zu sparen liegt dabei aber in der Regel auch noch über der Anzahl die der MS-Compiler für 2.0 braucht.

Der R300 bekommt also vom Cg Compiler gleich doppelt eines drauf. Zum einen muss er sich mit der für in ungünstigen Rheienfolge rumschlagen und zum zeiten sind die Shader länger.

Beim NV3X wird der Mehraufwand für die zusätzlichen Instruktionen durch die kleinere Anzahl von Temp Registern ausgelichen wodurch dieser etwa gleich lahm bleibt.

[Demirug]

Original geschrieben von Exxtreme
Halte ich für ein Gerücht.

Nein, die 2.0 und 2.X Profile von Cg sind einfach nur schlecht egal für welchen Chip.

[Exxtreme]

Original geschrieben von Demirug

Der R300 bekommt also vom Cg Compiler gleich doppelt eines drauf. Zum einen muss er sich mit der für in ungünstigen Rheienfolge rumschlagen und zum zeiten sind die Shader länger.

Beim NV3X wird der Mehraufwand für die zusätzlichen Instruktionen durch die kleinere Anzahl von Temp Registern ausgelichen wodurch dieser etwa gleich lahm bleibt.
Und obwohl der R3x0 zweimal eins draufkriegt, bleibt dieser aber trotzdem deutlich schneller als der weniger benachteiligte NV35. :grübel:

Also wenn beide Chips optimerten Shadercode bekommen, dann wird der NV35 zumindest in diesem Spiel wohl nicht die Leistung des R3x0 erreichen... liege ich da richtig?

Denn ich glaube nicht, daß der NV35 durch etwas kürzere Shader plötzlich mehr als Faktor 2 schneller wird.

[Razor]

Original geschrieben von Demirug
Es könnte ja mal jemand der TR6 hat mit 3dA die Shader protokolieren lassen. Einmal die original und einmal die mit Cg erzeugten dann könnte man sicherlich mehr sagen.
Hi Demirug,

das Proggi stürzt zwar ab, wenn die EXE direkt aufgerufen wird, aber die Shader werden trotzdem gespeichert.

Kann man im Header oder ähnlichem erkennen, welcher Code erzeugt wurde ?
Wenn ich das richtig sehe, dann kommen folgende PS zum Einsatz:
(die VertexShader laß ich jetzt mal weg ;-)

PS_1_1 - 53 Stück
PS_1_4 - 8 Stück
PS_2_0 - 14 Stück

Wenn Du die Shader haben möchtest... gerne !
;-)

Der Shader.Out ist zwischen Cg und Standard aber absolut identisch.
(wäre das nicht auch normal ?)

Razor

[Exxtreme]

Original geschrieben von Demirug
Nein, die 2.0 und 2.X Profile von Cg sind einfach nur schlecht egal für welchen Chip.
Ja, aber nicht die PS2.0-Profile generell.. das meinte ich. Der MS-Compiler macht wohl deutlich bessere PS2.0-Profile.

[Razor]

Original geschrieben von Exxtreme
Und obwohl der R3x0 zweimal eins draufkriegt, bleibt dieser aber trotzdem deutlich schneller als der weniger benachteiligte NV35. :grübel:
Jain.
Die erweiterten Möglichkeiten des NV35 werden ja nicht genutzt.
Weder bei nVidia-Karten, noch bei ATI-Karten.

Der Code für nVidia ist etwa gleich 'schlecht', wie das, was der M$-Compiler bei 2.0 'verbricht'. Für ATI aber wird das Ergebnis ungünstiger. Würde ATI jetzt den NV3x-optimierten Code vorgesetzt bekommne, dann würde gar nichts mehr laufen, weil der R300 diesen Code einfach nicht interpretieren kann.
Original geschrieben von Exxtreme
Also wenn beide Chips optimerten Shadercode bekommen, dann wird der NV35 zumindest in diesem Spiel wohl nicht die Leistung des R3x0 erreichen... liege ich da richtig?
Woher willst Du das wissen ?
Er hat weder optimierten Code von Cg, noch vom M$-Compiler bekommen.
Aussagen hierüber könnte nur jemand machen, der die Shader analysiert und mal selbst durch die betroffenen Compiler jagt.
Original geschrieben von Exxtreme
Denn ich glaube nicht, daß der NV35 durch etwas kürzere Shader plötzlich mehr als Faktor 2 schneller wird.
Was abzuwarten bliebe...
Demirug hat soch schon so einige Konsequenzen dargestellt.
"Stay tuned !"
;-)

Razor

[Razor]

Original geschrieben von Exxtreme
Ja, aber nicht die PS2.0-Profile generell.. das meinte ich. Der MS-Compiler macht wohl deutlich bessere PS2.0-Profile.
Und sehr viel bessere 2.A-Profile !
:D

Razor

[Demirug]

Original geschrieben von Exxtreme
Und obwohl der R3x0 zweimal eins draufkriegt, bleibt dieser aber trotzdem deutlich schneller als der weniger benachteiligte NV35. :grübel:

Also wenn beide Chips optimerten Shadercode bekommen, dann wird der NV35 zumindest in diesem Spiel wohl nicht die Leistung des R3x0 erreichen... liege ich da richtig?

Denn ich glaube nicht, daß der NV35 durch etwas kürzere Shader plötzlich mehr als Faktor 2 schneller wird.

Ohne die derzeit vom MS und Cg Compiler erzeugen Shader gesehen zu hahben kann ich da kaum was sagen. Die Formeln zum berechnen der Shaderleistung bei CineFX I und II sind so komplex das man sich da mit einer allgemeinen Aussage schwer tut. Entspricht ein Shader dem R300 Ideal (gleiche Anzahl von Texture und Rechenops bei richtiger Phasenverteilung) hat es ein NV35 sehr schwer da ran zu kommen. Je weiter dieser Shader aber von diesem Ideal abweicht desto besser höher die Wahrscheinlichkeit das der NV35 herankommt und sogar vorbeizieht.

Wobei bei den NV3X Chips der Shadercode nur die erste Stufe ist ein bessere Treiber sollte selbst bei Idealem Code noch was rausholen können. Auch beim R300 soll noch etwas Spiel sein aber weitgehend ist man da wohl schon am optimum angekommen und kümmert sich um einzelne Spezialfälle (wenn ich das richtig verstanden habe).

[Demirug]

Original geschrieben von Razor
Hi Demirug,

das Proggi stürzt zwar ab, wenn die EXE direkt aufgerufen wird, aber die Shader werden trotzdem gespeichert.

Kann man im Header oder ähnlichem erkennen, welcher Code erzeugt wurde ?
Wenn ich das richtig sehe, dann kommen folgende PS zum Einsatz:
(die VertexShader laß ich jetzt mal weg ;-)

PS_1_1 - 53 Stück
PS_1_4 - 8 Stück
PS_2_0 - 14 Stück

Wenn Du die Shader haben möchtest... gerne !
;-)

Der Shader.Out ist zwischen Cg und Standard aber absolut identisch.
(wäre das nicht auch normal ?)

Razor

Eigentlich sollten bei der Verwendung von Cg die Shader anders aussehen und damit auch die Datei. Bist du sicher das das mit der Auswahl funktioniert hat? Zwischen den beiden Versuchen hast du doch sicherlich die Shader.Out umkopiert?

[Demirug]

Original geschrieben von Exxtreme
Ja, aber nicht die PS2.0-Profile generell.. das meinte ich. Der MS-Compiler macht wohl deutlich bessere PS2.0-Profile.

Der MS-Compiler macht kürzer 2.0 Shader die viele Tempvariablen benutzen und nach ATI-Norm sortiert sind. Und der neue kann auch noch 2.A Shader die kaum Tempvariablen benutzen nach nVidia Norm sortiert und noch kürzer sind.

[Demirug]

Original geschrieben von Exxtreme
Naja, vergiss eine Sache nicht. ATi hat 8 Renderpipelines, NV nur 4. Das ist ein nicht zu unterschätzender Vorteil für ATi.

Bei den Shaderlängen die da zum Einsatz kommen spielt das kaum noch eine Rolle.

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

wie ungünstig der Code ist kann man erst sagen wenn man ihn sieht. Absolut ungünstig kann der Cg Compiler aber gar nicht.

@Razor: Wenn es nicht zu viel Arbeit ist schneide mal die 2.0 Shader raus. Bei den anderen lohnt es sich ja nicht.

[Ailuros]

Bei den Shaderlängen die da zum Einsatz kommen spielt das kaum noch eine Rolle.

Auch nicht dass der eine auf nur 4Z/colour writes begrenzt ist?

[Demirug]

Original geschrieben von Ailuros
Auch nicht dass der eine auf nur 4Z/colour writes begrenzt ist?

Wenn die Shader so lang sind das auch der R300 diesen gar nicht in einem Takt berechnen kann spielt das keine Rolle mehr. Und je länger die Shader werden desto weniger relevant wird der Vorteil 8 gegen 4.

[Razor]

Original geschrieben von Demirug
Eigentlich sollten bei der Verwendung von Cg die Shader anders aussehen und damit auch die Datei. Bist du sicher das das mit der Auswahl funktioniert hat? Zwischen den beiden Versuchen hast du doch sicherlich die Shader.Out umkopiert?
Jup, habe ich...

Razor

[Razor]

Original geschrieben von Exxtreme
Naja, vergiss eine Sache nicht. ATi hat 8 Renderpipelines, NV nur 4. Das ist ein nicht zu unterschätzender Vorteil für ATi.
Die Archtekturen beider Chips sind einfach zu unterschiedlich, als das man das auf einen so einfachen Nenner bringen kann.
Original geschrieben von Exxtreme
Wie gesagt, an einem Faktor von fast 2,5 glaube ich nicht, daß da soviel drin ist. Der R3x0 bricht um 40% ein mit dem absolut(!!) ungünstigen Code ein und bleibt immer noch deutlich schneller als der NV35 mit weniger ungünstigen Code.
Der 'weniger ungünstige' Code ist auf meiner FX5900 sogar langsamer, als der Standard-Code. Ich glaube Du verwechselst hier was.

Bevor wie hier keinen NV3x-optimierten Code zu Gesicht bekommen, läßt sich wohl schlicht KEINE Aussage zu diesem Thema machen.

Razor

[Razor]

Original geschrieben von Demirug
@Razor: Wenn es nicht zu viel Arbeit ist schneide mal die 2.0 Shader raus. Bei den anderen lohnt es sich ja nicht.
Echt ?
OK, mach' ich nachher mal...
*hmpf*
;-)

Razor

[Demirug]

Original geschrieben von Razor
Echt ?
OK, mach' ich nachher mal...
*hmpf*
;-)

Razor

Oder schick mir die Datei. Meine Email solltest du ja haben.

[Razor]

Ich kann sie hier auch gerne posten...
Aber wenn Du willst, schick' ich Dir gerne die komplette shader.out.
;-)
///////////////Pixel Shader - start//////////////
ps_2_0


def c0 , -0.500000, 0.000000, 0.500000, 1.010000

dcl v0.xyz
dcl _pp t0.xy
dcl _pp t2.xyz
dcl _pp t3.xyz
dcl _pp t4.xyz
dcl _pp t5.xyz
dcl _pp t6.xyz
dcl_2d s0
dcl_2d s1
dcl_2d s2
dcl_cube s3
texld_pp r0 , t0 , s0
dp3 r7.w , t5 , t5
rsq r9.w , r7.wwww
mul_pp r4.xyz , r9.wwww , t5
add r0.xyz , r0 , c0.xxxx
add_pp r0.xyz , r0 , r0
dp3_pp r11.x , r0 , t2
dp3_pp r11.y , r0 , t3
dp3_pp r11.z , r0 , t4
dp3 r11.w , r11 , r11
rsq r11.w , r11.wwww
mul_pp r0.xyz , r11 , r11.wwww
mul r6.xyz , r0 , c0.wwww
dp3 r4.w , r6 , r4
add r4.w , r4.wwww , r4.wwww
mad_pp r8.xyz , r0 , r4.wwww , -r4
dp3 r8.w , t6 , t6
rsq r8.w , r8.wwww
mul_pp r3.xyz , r8.wwww , t6
dp3_pp r3.w , r3 , r8
dp3_pp r8.w , r3 , r0
cmp_pp r0.y , r3.wwww , r3.wwww , c0.yyyy
cmp_pp r0.x , r8.wwww , r8.wwww , c0.yyyy
texld_pp r10 , r8 , s3
texld_pp r5 , r0 , s1
texld_pp r7 , t0 , s2
mul_pp r0.xyz , r0.wwww , c1
mul r10.w , r0.wwww , c0.zzzz
mul_pp r5.xyz , r5 , r0
mul_pp r2.xyz , r7 , c1
mul_pp r9.xyz , r5.wwww , r2
mov_pp r11.w , r7.wwww
mad_pp r7.xyz , r7 , v0 , r9
add_pp r6.xyz , r5 , r7
mad_pp r11.xyz , r10 , r10.wwww , r6
mov_pp oC0 , r11
///////////////Pixel Shader - end//////////////

///////////////Pixel Shader - start//////////////
ps_2_0


def c0 , -0.500000, 0.000000, 0.000000, 0.500000

dcl v0.xyz
dcl _pp t0.xy
dcl _pp t2.xyz
dcl _pp t3.xyz
dcl _pp t4.xyz
dcl _pp t5.xyz
dcl _pp t6.xyz
dcl_2d s0
dcl_2d s1
dcl_2d s2
texld_pp r0 , t0 , s0
add r0.xyz , r0 , c0.xxxx
add_pp r0.xyz , r0 , r0
dp3_pp r7.x , r0 , t2
dp3_pp r7.y , r0 , t3
dp3_pp r7.z , r0 , t4
dp3 r7.w , r7 , r7
rsq r7.w , r7.wwww
mul_pp r0.xyz , r7 , r7.wwww
mul r2.xyz , r0.yzxw , t3
mad_pp r11.xyz , r0 , t3.yzxw , -r2
mul r1.xyz , r0.zxyw , r11.zxyw
mad_pp r3.xyz , r0.yzxw , -r11 , r1
dp3 r3.w , r3 , r3
rsq r3.w , r3.wwww
mul_pp r10.xyz , r3 , r3.wwww
dp3 r10.w , t5 , t5
rsq r10.w , r10.wwww
mul_pp r5.xyz , r10.wwww , t5
dp3_pp r10.w , r5 , r10
mad_pp r7.y , r10.wwww , c0.wwww , c0.wwww
dp3 r10.w , t6 , t6
rsq r10.w , r10.wwww
mul_pp r2.xyz , r10.wwww , t6
dp3_pp r2.w , r2 , r10
mad_pp r7.x , r2.wwww , c0.wwww , c0.wwww
texld_pp r9 , r7 , s1
texld_pp r4 , t0 , s2
mul_pp r11.xyz , r0.wwww , c1
dp3 r11.w , r0 , r2
mul_pp r9.xyz , r9 , r11.wwww
mul_pp r11.w , r9.wwww , r11.wwww
mul_pp r11.xyz , r11 , r9
mul_pp r6.xyz , r4 , c1
mul_pp r1.xyz , r11.wwww , r6
mov_pp r8.w , r4.wwww
mad_pp r4.xyz , r4 , v0 , r1
add_pp r8.xyz , r11 , r4
mov_pp oC0 , r8
///////////////Pixel Shader - end//////////////

///////////////Pixel Shader - start//////////////
ps_2_0


def c0 , 1.000000, 0.000000, 0.000000, 32.000000

def c2 , -0.500000, 0.000000, -1.000000, 1.010000

dcl v0.xyz
dcl _pp t0.xy
dcl _pp t2.xyz
dcl _pp t3.xyz
dcl _pp t4.xyz
dcl _pp t5.xyz
dcl _pp t6.xyz
dcl_2d s0
dcl_2d s1
texld_pp r0 , t0 , s0
texld_pp r7 , t0 , s1
add r0.xyz , r0 , c2.xxxx
mul_pp r2.xyz , r0.wwww , c1
add_pp r9.xyz , r0 , r0
dp3_pp r4.x , r9 , t2
dp3_pp r4.y , r9 , t3
dp3_pp r4.z , r9 , t4
dp3 r4.w , r4 , r4
rsq r4.w , r4.wwww
mul_pp r11.xyz , r4 , r4.wwww
mul r6.xyz , r11 , c2.wwww
dp3 r6.w , t5 , t5
rsq r6.w , r6.wwww
mul_pp r1.xyz , r6.wwww , t5
dp3 r1.w , r6 , r1
add r1.w , r1.wwww , r1.wwww
mad_pp r10.xyz , r11 , r1.wwww , -r1
dp3_sat r2.w , r11 , r1
dp3 r10.w , t6 , t6
rsq r10.w , r10.wwww
mul_pp r5.xyz , r10.wwww , t6
dp3 r6.w , r5 , r10
dp3_sat r0.w , r11 , r5
log_pp r1.w , r6.wwww
mul r8.w , r1.wwww , c0.wwww
exp_pp r3.w , r8.wwww
min_pp r5.w , r3.wwww , c0.xxxx
mov_pp r11.w , -r0.wwww
cmp_pp r9.w , r11.wwww , c2.yyyy , r5.wwww
mul_pp r2.xyz , r2 , r9.wwww
mul_pp r0.xyz , r7 , c1
add_pp r2.w , r0.wwww , r2.wwww
rcp_pp r2.w , r2.wwww
add_pp r1.w , r2.wwww , c2.zzzz
cmp_pp r2.w , r1.wwww , c0.xxxx , r2.wwww
mul_pp r0.w , r0.wwww , r2.wwww
mul r5.xyz , r7 , v0
mov_pp r3.w , r7.wwww
mad_pp r11.xyz , r0 , r0.wwww , r5
add_pp r3.xyz , r2 , r11
mov_pp oC0 , r3
///////////////Pixel Shader - end//////////////

///////////////Pixel Shader - start//////////////
ps_2_0


def c1 , 0.000000, 0.000000, 0.000000, 0.000000

dcl t0
dp4_pp r0.y , t0 , c0
mov_pp r0.xzw , c1.xxxx
mov_pp oC0 , r0
///////////////Pixel Shader - end//////////////

///////////////Pixel Shader - start//////////////
ps_2_0


def c1 , 0.000000, 0.000000, 0.000000, 0.000000

dcl t0
dcl t1.xy
dcl_2d s0
texld_pp r0 , t1 , s0
mov_pp r0.x , r0.wwww
dp4_pp r0.y , t0 , c0
mov_pp r0.zw , c1.xxxx
mov_pp oC0 , r0
///////////////Pixel Shader - end//////////////

///////////////Pixel Shader - start//////////////
ps_2_0


def c1 , 0.000000, 0.000000, 0.000000, 0.000000

dcl t0
dcl t1.xy
dcl_2d s0
texld_pp r0 , t1 , s0
dp4_pp r0.y , t0 , c0
mov_pp r0.xz , c1.xxxx
mov_pp oC0 , r0
///////////////Pixel Shader - end//////////////

///////////////Pixel Shader - start//////////////
ps_2_0


def c2 , -0.500000, 0.000000, 0.000000, 0.500000

def c3 , 0.000000, 1.000000, 0.000000, 0.000000

dcl v0.xyz
dcl t0.xy
dcl t1
dcl _pp t2.xyz
dcl _pp t3.xyz
dcl _pp t4.xyz
dcl t5.xyz
dcl t6.xyz
dcl_2d s0
dcl_2d s1
dcl_cube s2
texld_pp r0 , t0 , s0
dp3 r7.w , t6 , t6
rsq r9.w , r7.wwww
mul_pp r4.xyz , r9.wwww , t6
add r0.xyz , r0 , c2.xxxx
add_pp r0.xyz , r0 , r0
dp3_pp r6.x , r0 , t2
dp3_pp r6.y , r0 , t3
dp3_pp r6.z , r0 , t4
dp3_pp r11.w , r6 , r4
add r1.xyz , r6 , r6
mad_pp r3.xyz , r1 , r11.wwww , -r4
texld_pp r10 , r3 , s2
texld_pp r5 , t0 , s1
mul r10.w , r0.wwww , c2.wwww
mul r7.xyz , r10 , r10.wwww
dp3 r7.w , t5 , t5
rsq r7.w , r7.wwww
mul_pp r2.xyz , r7.wwww , t5
dp2add_pp r9.x , r0 , t2 , c3.xxxx
dp2add_pp r9.y , r0 , t3 , c3.xxxx
dp2add_pp r9.z , r0 , t4 , c3.xxxx
dp3_pp r7.w , r9 , r2
mad_pp r0.xyz , r7.wwww , c1 , v0
mov_pp r6.w , r5.wwww
mad_pp r5.xyz , r5 , r0 , r7
dp4_sat r1.w , t1 , c4
mul_pp r1.w , r1.wwww , c0.wwww
lrp_pp r6.xyz , r1.wwww , c0 , r5
mov_pp oC0 , r6
///////////////Pixel Shader - end//////////////

///////////////Pixel Shader - start//////////////
ps_2_0


def c2 , -0.500000, 0.000000, 0.000000, 0.500000

def c3 , 0.000000, 1.000000, 0.000000, 0.000000

dcl v0.xyz
dcl t0.xy
dcl t1.xy
dcl t2
dcl _pp t3.xyz
dcl _pp t4.xyz
dcl _pp t5.xyz
dcl t6.xyz
dcl t7.xyz
dcl_2d s0
dcl_2d s1
dcl_2d s2
dcl_cube s3
texld_pp r0 , t0 , s0
dp3 r7.w , t7 , t7
rsq r9.w , r7.wwww
mul_pp r4.xyz , r9.wwww , t7
add r0.xyz , r0 , c2.xxxx
add_pp r0.xyz , r0 , r0
dp3_pp r6.x , r0 , t3
dp3_pp r6.y , r0 , t4
dp3_pp r6.z , r0 , t5
dp3_pp r11.w , r6 , r4
add r1.xyz , r6 , r6
mad_pp r3.xyz , r1 , r11.wwww , -r4
texld_pp r10 , r3 , s3
texld_pp r5 , t0 , s2
texld_pp r7 , t1 , s1
mul r10.w , r0.wwww , c2.wwww
mul r2.xyz , r10 , r10.wwww
dp3 r7.w , t6 , t6
rsq r7.w , r7.wwww
mul_pp r9.xyz , r7.wwww , t6
dp2add_pp r4.x , r0 , t3 , c3.xxxx
dp2add_pp r4.y , r0 , t4 , c3.xxxx
dp2add_pp r4.z , r0 , t5 , c3.xxxx
dp3_pp r7.w , r4 , r9
mad_pp r6.xyz , r7.wwww , c1 , v0
mul_pp r11.xyz , r7 , r6
mov_pp r1.w , r5.wwww
mad_pp r5.xyz , r5 , r11 , r2
dp4_sat r3.w , t2 , c4
mul_pp r3.w , r3.wwww , c0.wwww
lrp_pp r1.xyz , r3.wwww , c0 , r5
mov_pp oC0 , r1
///////////////Pixel Shader - end//////////////

///////////////Pixel Shader - start//////////////
ps_2_0


def c2 , -0.500000, 0.000000, 0.000000, 0.000000

dcl v0.xyz
dcl t0.xy
dcl t1
dcl _pp t2.xyz
dcl _pp t3.xyz
dcl _pp t4.xyz
dcl t5.xyz
dcl_2d s0
dcl_2d s1
texld_pp r0 , t0 , s0
texld_pp r7 , t0 , s1
dp3 r2.w , t5 , t5
rsq r4.w , r2.wwww
mul_pp r11.xyz , r4.wwww , t5
add r0.xy , r0 , c2.xxxx
add_pp r11.w , r0.wwww , r0.wwww
add_pp r6.xy , r0 , r0
mov_pp r6.z , c2.wwww
dp3_pp r1.x , r6 , t2
dp3_pp r1.y , r6 , t3
dp3_pp r1.z , r6 , t4
dp3_pp r8.w , r1 , r11
mad_pp r11.xyz , r8.wwww , c1 , v0
mul_pp r11.xyz , r7 , r11
mov_pp r3.w , r7.wwww
mad_pp r7.xyz , r7 , r11.wwww , r11
dp4_sat r5.w , t1 , c4
mul_pp r5.w , r5.wwww , c0.wwww
lrp_pp r3.xyz , r5.wwww , c0 , r7
mov_pp oC0 , r3
///////////////Pixel Shader - end//////////////

///////////////Pixel Shader - start//////////////
ps_2_0


def c2 , -0.500000, 0.000000, 0.000000, 0.500000

def c3 , 0.000000, 1.000000, 0.000000, 0.000000

dcl v0.xyz
dcl t0.xy
dcl t1
dcl _pp t2.xyz
dcl _pp t3.xyz
dcl _pp t4.xyz
dcl t5.xyz
dcl t6.xyz
dcl_2d s0
dcl_2d s1
dcl_cube s2
texld_pp r0 , t0 , s0
dp3 r7.w , t6 , t6
rsq r9.w , r7.wwww
mul_pp r4.xyz , r9.wwww , t6
add r0.xyz , r0 , c2.xxxx
add_pp r0.xyz , r0 , r0
dp3_pp r6.x , r0 , t2
dp3_pp r6.y , r0 , t3
dp3_pp r6.z , r0 , t4
dp3_pp r11.w , r6 , r4
add r1.xyz , r6 , r6
mad_pp r3.xyz , r1 , r11.wwww , -r4
texld_pp r10 , r3 , s2
texld_pp r5 , t0 , s1
mul r10.w , r0.wwww , c2.wwww
mul r7.xyz , r10 , r10.wwww
dp3 r5.w , t5 , t5
rsq r5.w , r5.wwww
mul_pp r2.xyz , r5.wwww , t5
dp2add_pp r9.x , r0 , t2 , c3.xxxx
dp2add_pp r9.y , r0 , t3 , c3.xxxx
dp2add_pp r9.z , r0 , t4 , c3.xxxx
dp3_pp r5.w , r9 , r2
mad_pp r0.xyz , r5.wwww , c1 , v0
mad_pp r11.xyz , r5 , r0 , r7
dp4_sat r8.w , t1 , c4
mul_pp r8.w , r8.wwww , c0.wwww
lrp_pp r10.xyz , r8.wwww , c0 , r11
mov_pp r10.w , c2.wwww
mov_pp oC0 , r10
///////////////Pixel Shader - end//////////////

///////////////Pixel Shader - start//////////////
ps_2_0


def c2 , -0.500000, 0.000000, 0.500000, 0.900000

def c3 , 0.000000, 1.000000, 0.000000, 0.000000

dcl v0.xyz
dcl t0.xy
dcl t1
dcl _pp t2.xyz
dcl _pp t3.xyz
dcl _pp t4.xyz
dcl t5.xyz
dcl t6.xyz
dcl_2d s0
dcl_2d s1
dcl_cube s2
dcl_2d s3
texld_pp r0 , t0 , s0
dp3 r7.w , t6 , t6
rsq r9.w , r7.wwww
mul_pp r4.xyz , r9.wwww , t6
add r0.xyz , r0 , c2.xxxx
add_pp r0.xyz , r0 , r0
dp3_pp r6.x , r0 , t2
dp3_pp r6.y , r0 , t3
dp3_pp r6.z , r0 , t4
dp3_pp r11.w , r6 , r4
add r1.xyz , r6 , r6
mad_pp r3.xyz , r1 , r11.wwww , -r4
texld r10 , t0 , s3
texld_pp r5 , r3 , s2
texld_pp r7 , t0 , s1
add r2.xyz , r10 , c2.xxxx
add_pp r9.xyz , r2 , r2
dp3_pp r5.w , r9 , r4
add r5.w , -r5.wwww , c2.wwww
cmp_pp r5.w , r5.wwww , c2.yyyy , c2.zzzz
mul_pp r5.w , r0.wwww , r5.wwww
mul_pp r4.xyz , r5 , r5.wwww
dp3 r4.w , t5 , t5
rsq r4.w , r4.wwww
mul_pp r6.xyz , r4.wwww , t5
dp2add_pp r11.x , r0 , t2 , c3.xxxx
dp2add_pp r11.y , r0 , t3 , c3.xxxx
dp2add_pp r11.z , r0 , t4 , c3.xxxx
dp3_pp r4.w , r11 , r6
mad_pp r1.xyz , r4.wwww , c1 , v0
mov_pp r8.w , r7.wwww
mad_pp r7.xyz , r7 , r1 , r4
dp4_sat r10.w , t1 , c4
mul_pp r10.w , r10.wwww , c0.wwww
lrp_pp r8.xyz , r10.wwww , c0 , r7
mov_pp oC0 , r8
///////////////Pixel Shader - end//////////////

///////////////Pixel Shader - start//////////////
ps_2_0


def c6 , 0.285714, 0.000000, 0.000000, 0.000000

dcl v0
dcl _pp t0.xy
dcl_2d s0
dcl_2d s1
add_pp r0.xy , t0 , c0
add_pp r7.xy , t0 , c1
add_pp r2.xy , t0 , c2
add_pp r9.xy , t0 , c3
texld_pp r4 , r0 , s1
texld_pp r11 , r0 , s0
texld_pp r6 , t0 , s1
texld_pp r1 , t0 , s0
texld_pp r8 , r7 , s1
texld_pp r3 , r7 , s0
texld_pp r10 , r2 , s1
texld_pp r5 , r2 , s0
texld_pp r0 , r9 , s1
texld_pp r7 , r9 , s0
mul_pp r6.w , r4.xxxx , c0.zzzz
mul_pp r2 , r11 , r6.wwww
mad_pp r4 , r6.xxxx , r1 , r2
mul_pp r10.w , r8.xxxx , c1.zzzz
add_pp r11.xy , t0 , c4
add_pp r1.xy , t0 , c5
texld_pp r8 , r11 , s1
texld_pp r6 , r11 , s0
texld_pp r2 , r1 , s1
texld_pp r9 , r1 , s0
mad_pp r4 , r3 , r10.wwww , r4
mul_pp r0.w , r10.xxxx , c2.zzzz
mad_pp r10 , r5 , r0.wwww , r4
mul_pp r8.w , r0.xxxx , c3.zzzz
mad_pp r11 , r7 , r8.wwww , r10
mul_pp r2.w , r8.xxxx , c4.zzzz
mad_pp r6 , r6 , r2.wwww , r11
mul_pp r3.w , r2.xxxx , c5.zzzz
mad_pp r4 , r9 , r3.wwww , r6
mul_pp r0 , r4 , v0
mul_pp r5 , r0 , c6.xxxx
mov_pp oC0 , r5
///////////////Pixel Shader - end//////////////

///////////////Pixel Shader - start//////////////
ps_2_0


def c4 , 0.200000, 0.000000, 0.000000, 0.000000

dcl _pp t0.xy
dcl_2d s0
dcl_2d s1
texld_pp r0 , t0 , s1
mad_pp r2.xy , r0.yyyy , c0 , t0
mad_pp r4.xy , r0.yyyy , c1 , t0
mad_pp r1.xy , r0.yyyy , c2 , t0
mad_pp r8.xy , r0.yyyy , c3 , t0
texld_pp r3 , t0 , s0
texld_pp r10 , r2 , s0
texld_pp r5 , r4 , s0
texld_pp r0 , r1 , s0
texld_pp r7 , r8 , s0
add_pp r2 , r3 , r10
add_pp r9 , r5 , r2
add_pp r4 , r0 , r9
add_pp r11 , r7 , r4
mul_pp r6 , r11 , c4.xxxx
mov_pp oC0 , r6
///////////////Pixel Shader - end//////////////

///////////////Pixel Shader - start//////////////
ps_2_0


def c8 , 0.000000, 32.000000, 0.000000, 1.000000

def c9 , 0.000000, 50.000000, -50.000000, 0.700000

def c10 , 2.000000, -1.000000, 0.000000, 0.000000

dcl t0
dcl _pp t1.xyz
dcl _pp t2.xy
dcl _pp t3.xyz
dcl_2d s0
dcl_2d s1
dcl_2d s2
dp4 r0.x , t0 , c0
dp4 r0.y , t0 , c1
dp4 r0.z , t0 , c2
dp4 r0.w , t0 , c3
texld_pp r7 , t2 , s2
texld_pp r2 , r0 , s0
texld_pp r9 , r0 , s1
mad r11.xyz , c10.xxxx , r7 , c10.yyyy
dp3 r11.w , r11 , r11
rsq r11.w , r11.wwww
mul_pp r6.xyz , r11 , r11.wwww
mad_pp r8.xyz , r6 , c9.wwww , t1
dp3 r8.w , r8 , r8
rsq r8.w , r8.wwww
mul_pp r3.xyz , r8 , r8.wwww
mad r7.xy , r3 , c9.yyyy , t0
mov r7.zw , t0
dp4 r4.x , r7 , c0
dp4 r4.y , r7 , c1
dp4 r4.z , r7 , c2
dp4 r4.w , r7 , c3
lrp r8 , r2.wwww , r4 , r0
mad r10.xy , r3 , c9.zzzz , t0
mov r10.zw , t0
dp4 r5.x , r10 , c0
dp4 r5.y , r10 , c1
dp4 r5.z , r10 , c2
dp4 r5.w , r10 , c3
add r7 , -r0 , r5
mad r0 , r7 , r9.wwww , r0
texld_pp r11 , r8 , s0
texld_pp r6 , r0 , s1
add r1.xyz , r3 , r3
dp3_pp r1.w , r3 , c4
mad_pp r5.xyz , r1 , r1.wwww , -c4
dp3 r5.w , t3 , t3
rsq r5.w , r5.wwww
mul_pp r7.xyz , r5.wwww , t3
dp3 r2.w , r5 , r7
dp3_pp r9.w , r3 , r7
log_pp r2.w , r2.wwww
mul r2.w , r2.wwww , c8.yyyy
exp_pp r2.w , r2.wwww
add_pp r11.xyz , r11 , -r2
mad_pp r2.xyz , r11 , r11.wwww , r2
add_pp r8.xyz , r2.wwww , r2
mul_pp r10.xyz , r8 , c7
add_pp r6.xyz , r6 , -r9
mad_pp r9.xyz , r6 , r6.wwww , r9
mad_pp r9.xyz , r9 , c6 , -r10
mad r9.w , -r9.wwww , c5.xxxx , c5.yyyy
mad_pp r0.xyz , r9 , r9.wwww , r10
mov r0.w , c8.wwww
mov_pp oC0 , r0
///////////////Pixel Shader - end//////////////
Zumindest 3-4 davon sind recht kurz...
Ahnung habe ich davon allerdings schlicht gar keine !
:D

Razor

[Demirug]

Was die Tempnutzung und Sortierung angeht ist das Eindeutig ATI Style. Die pp's sind aber immerhin ein netter Zug in Richtung nv wenn es auch bei den vielen Temps nicht viel nutzen bringen dürfte.

Die meisten Shader sind sehr rechenlastig da kann also auch Cg was die Reihenfolge angeht für ATI nicht viel kaputt machen. 2 der Shader würde aber massive anders aussehen.

Nur was macht das "use Cg" überhaupt wenn sich die Shader scheinbar dadurch nicht ändern?

[Exxtreme]

Original geschrieben von Demirug
Was die Tempnutzung und Sortierung angeht ist das Eindeutig ATI Style. Die pp's sind aber immerhin ein netter Zug in Richtung nv wenn es auch bei den vielen Temps nicht viel nutzen bringen dürfte.

Die meisten Shader sind sehr rechenlastig da kann also auch Cg was die Reihenfolge angeht für ATI nicht viel kaputt machen. 2 der Shader würde aber massive anders aussehen.

Nur was macht das "use Cg" überhaupt wenn sich die Shader scheinbar dadurch nicht ändern?
Also heisst das, daß für beide Architekturen noch Luft nach oben ist, oder?

[Demirug]

Original geschrieben von Exxtreme
Also heisst das, daß für beide Architekturen noch Luft nach oben ist, oder?

Was den R300 angeht sind die von der Struktur her perfekt. Möglicherweise findet man hier und da noch eine Anweisung zum rauswerfen aber das war es dann auch schon. Um das guten Verteilen von Vec3 und Skalar Operationen muss man sich ja laut ATI nicht mehr selbst kümmern da diese vom Treiber gemacht wird.

Für die NV3X Chips sind die meisten Shader aufgrund der "hohen" Anzahl von Temps aber das reinste Gift. Und die weniger Rechenlastigen haben eine ungünstige Anweisungssortierung. Allerdings muss man auch noch hinzufügen das alles < NV35 selbst wenn man einen 100% perfeketen Shader und Treiber hat es schwer haben wird an die ATI-Lösungen ranzukommen weil die Rohrechenleistung nicht reichen dürfte.

[Razor]

Original geschrieben von Demirug
Was den R300 angeht sind die von der Struktur her perfekt. Möglicherweise findet man hier und da noch eine Anweisung zum rauswerfen aber das war es dann auch schon. Um das guten Verteilen von Vec3 und Skalar Operationen muss man sich ja laut ATI nicht mehr selbst kümmern da diese vom Treiber gemacht wird.

Für die NV3X Chips sind die meisten Shader aufgrund der "hohen" Anzahl von Temps aber das reinste Gift. Und die weniger Rechenlastigen haben eine ungünstige Anweisungssortierung. Allerdings muss man auch noch hinzufügen das alles < NV35 selbst wenn man einen 100% perfeketen Shader und Treiber hat es schwer haben wird an die ATI-Lösungen ranzukommen weil die Rohrechenleistung nicht reichen dürfte.
Hi Demirug,

hier nun noch ein kleiner Nachtrag:

Default
PS_1_1 - 54 Stück
PS_1_4 - 8 Stück
PS_2_0 - 14 StückDefault ohne PS1.4
PS_1_1 - 54 Stück
PS_2_0 - 14 StückCg
PS_1_1 - 54 Stück
PS_1_4 - 8 Stück
PS_2_0 - 16 StückCg ohne PS1.4
PS_1_1 - 54 Stück
PS_2_0 - 16 StückAuf jeden Fall interessant, dass unter Cg nun 2 PS2.0-Shader mehr erzeugt werden...

Die 'richtigen' Shader.Out solltest Du jetzt schon bekommen haben...
;-)

Hier mal ein Beipsiel.

Default
///////////////Pixel Shader - start//////////////
ps_2_0


def c0 , -0.500000, 0.000000, 0.500000, 1.010000

dcl v0.xyz
dcl _pp t0.xy
dcl _pp t2.xyz
dcl _pp t3.xyz
dcl _pp t4.xyz
dcl _pp t5.xyz
dcl _pp t6.xyz
dcl_2d s0
dcl_2d s1
dcl_2d s2
dcl_cube s3
texld_pp r0 , t0 , s0
dp3 r7.w , t5 , t5
rsq r9.w , r7.wwww
mul_pp r4.xyz , r9.wwww , t5
add r0.xyz , r0 , c0.xxxx
add_pp r0.xyz , r0 , r0
dp3_pp r11.x , r0 , t2
dp3_pp r11.y , r0 , t3
dp3_pp r11.z , r0 , t4
dp3 r11.w , r11 , r11
rsq r11.w , r11.wwww
mul_pp r0.xyz , r11 , r11.wwww
mul r6.xyz , r0 , c0.wwww
dp3 r4.w , r6 , r4
add r4.w , r4.wwww , r4.wwww
mad_pp r8.xyz , r0 , r4.wwww , -r4
dp3 r8.w , t6 , t6
rsq r8.w , r8.wwww
mul_pp r3.xyz , r8.wwww , t6
dp3_pp r3.w , r3 , r8
dp3_pp r8.w , r3 , r0
cmp_pp r0.y , r3.wwww , r3.wwww , c0.yyyy
cmp_pp r0.x , r8.wwww , r8.wwww , c0.yyyy
texld_pp r10 , r8 , s3
texld_pp r5 , r0 , s1
texld_pp r7 , t0 , s2
mul_pp r0.xyz , r0.wwww , c1
mul r10.w , r0.wwww , c0.zzzz
mul_pp r5.xyz , r5 , r0
mul_pp r2.xyz , r7 , c1
mul_pp r9.xyz , r5.wwww , r2
mov_pp r11.w , r7.wwww
mad_pp r7.xyz , r7 , v0 , r9
add_pp r6.xyz , r5 , r7
mad_pp r11.xyz , r10 , r10.wwww , r6
mov_pp oC0 , r11
///////////////Pixel Shader - end//////////////
Cg
///////////////Pixel Shader - start//////////////
ps_2_0


dcl_2d s0
dcl_cube s1
dcl_2d s2
dcl_2d s3
def c0 , 0.500000, 2.000000, 1.010000, 0.000000

dcl v0.xyz
dcl t0.xy
dcl t2.xyz
dcl t3.xyz
dcl t4.xyz
dcl t5.xyz
dcl t6.xyz
texld r0 , t0 , s0
texld r1 , t0 , s2
mov r2.w , r0.wwww
add r0.xyz , r0 , -c0.xxxx
mul r0.xyz , c0.yyyy , r0
mov r2.xyz , r0
dp3 r0.x , r2 , t2
dp3 r0.w , r2 , t3
mov r0.y , r0.wwww
dp3 r0.w , r2 , t4
mov r0.z , r0.wwww
dp3 r0.w , r0 , r0
rsq r0.w , r0.wwww
mul r0.xyz , r0.wwww , r0
dp3 r0.w , t5 , t5
rsq r0.w , r0.wwww
mul r3.xyz , r0.wwww , t5
dp3 r0.w , t6 , t6
rsq r0.w , r0.wwww
mul r4.xyz , r0.wwww , t6
dp3 r0.w , r4 , r0
max r3.w , c0.wwww , r0.wwww
mov r5.x , r3.wwww
mul r6.xyz , c1 , r1
mul r7.xyz , c1 , r2.wwww
mul r0.w , c0.xxxx , r2.wwww
mul r2.xyz , c0.zzzz , r0
dp3 r2.x , r2 , r3
mul r2.x , c0.yyyy , r2.xxxx
mad r3.xyz , r0 , r2.xxxx , -r3
dp3 r0.x , r4 , r3
max r2.x , c0.wwww , r0.xxxx
mov r5.y , r2.xxxx
texld r2 , r5 , s3
texld r3 , r3 , s1
mul r6.xyz , r6 , r2.wwww
mad r6.xyz , v0 , r1 , r6
mad r6.xyz , r7 , r2 , r6
mad r6.xyz , r0.wwww , r3 , r6
mov r0.xyz , r6
mov r0.w , r1.wwww
mov oC0 , r0
///////////////Pixel Shader - end//////////////
Sieht doch schon ganz anders aus, oder ?
;-)

Bin mal gespannt, was Du vielleicht insgesamt zu den unterschiedlichen 'Erzeugnissen' sagst.

Razor

[Demirug]

Original geschrieben von Razor
Hi Demirug,

hier nun noch ein kleiner Nachtrag:

Default
PS_1_1 - 54 Stück
PS_1_4 - 8 Stück
PS_2_0 - 14 StückDefault ohne PS1.4
PS_1_1 - 54 Stück
PS_2_0 - 14 StückCg
PS_1_1 - 54 Stück
PS_1_4 - 8 Stück
PS_2_0 - 16 StückCg ohne PS1.4
PS_1_1 - 54 Stück
PS_2_0 - 16 StückAuf jeden Fall interessant, dass unter Cg nun 2 PS2.0-Shader mehr erzeugt werden...

Die 'richtigen' Shader.Out solltest Du jetzt schon bekommen haben...
;-)

<snip>

Sieht doch schon ganz anders aus, oder ?
;-)

Bin mal gespannt, was Du vielleicht insgesamt zu den unterschiedlichen 'Erzeugnissen' sagst.

Razor

Die zusätzlichen Shader habe ich jetzt noch nicht gesucht. Generel kann man aber folgendes sagen:

- Der Cg Compiler benutzt die von NV bevorzugte sortierung
- Der Cg Compiler reduziert die Tempregister.

Das soll er ja eigentlich auch tun.

- Das Cg Compiler ist bei den 2.0 Profilen einfach nur schlecht da er immer viel mehr (unnötige) Anweisungen braucht.

Was mich aber am meisten überrascht hat:

- Der Cg Compiler benutzt kein pp (Partial Precision) wie der MS-Compiler. Per Default rechnen die NV Chips also das meiste nur mit fp16. Unter Cg aber alles mit fp32(wenn der Treiber nichts daran ändert).

[Razor]

Original geschrieben von Demirug
Was mich aber am meisten überrascht hat:

- Der Cg Compiler benutzt kein pp (Partial Precision) wie der MS-Compiler. Per Default rechnen die NV Chips also das meiste nur mit fp16. Unter Cg aber alles mit fp32(wenn der Treiber nichts daran ändert).
Kann das nicht damit zusammen hängen, dass ja nicht das 2.X, sondern eher das 2.0-Profil benutzt wird ?
Oder wäre pp auch bei Radeon-Karten zulässig, die ja eigentlich kein fp16 unterstützen ?

Der Effekt ist ja auch, dass die Performance unter Cg geringfügig nachgibt. Der M$-Compiler also schon mit dem 2.0-Profil ein wenig schneller ist, als der Cg-Compiler.

Interessant wäre es doch jetzt, was die spezialisierten Compiler raus holen könnten.
Also Cg mit 2.X und M$-SDK mit 2.A...

Razor

P.S.: Thx an Demirug, für das Verschieben... ;)

[LovesuckZ]

Original geschrieben von Demirug
- Der Cg Compiler benutzt die von NV bevorzugte sortierung
- Der Cg Compiler reduziert die Tempregister.
[...]
- Der Cg Compiler benutzt kein pp (Partial Precision) wie der MS-Compiler. Per Default rechnen die NV Chips also das meiste nur mit fp16. Unter Cg aber alles mit fp32(wenn der Treiber nichts daran ändert).

Bedeutet dies, dass die NV3x Karten mit der NV bevorzugten Sortierung und FP32 genauso schnell sind wie mit der ungünstigen Sortiering und vielen FP16 Berechnungen?

[Demirug]

Original geschrieben von Razor
Kann das nicht damit zusammen hängen, dass ja nicht das 2.X, sondern eher das 2.0-Profil benutzt wird ?
Oder wäre pp auch bei Radeon-Karten zulässig, die ja eigentlich kein fp16 unterstützen ?

pp ist immer zulässig da es ja nur einen Hinwweis darstellt das mit fp16 gearbeitet werden darf. Warum Cg diese jetzt aber nicht macht müsste man erst noch prüfen.

Der Effekt ist ja auch, dass die Performance unter Cg geringfügig nachgibt. Der M$-Compiler also schon mit dem 2.0-Profil ein wenig schneller ist, als der Cg-Compiler.

Die meisten Shader sind was die sortierung angeht noch einigermassen OK für NV3X da sie wenige Textureanweisungen enthalten. Da aber Cg jetzt fp32 verwendet und längere Shader erzeugt werden die Gewinne duch die geringere Anzahl von Temps und eine minimal bessere sortierung gleich wieder aufgefressen.

Interessant wäre es doch jetzt, was die spezialisierten Compiler raus holen könnten.
Also Cg mit 2.X und M$-SDK mit 2.A...

Cg mit 2.X ist nur minimal besser als 2.0 aber 2.A kann in der Regel kürzere Shader als MS 2.0 erzeugen welche weniger Temps benutzen und die richtige sortierung haben.

Es soll ja einen Patch geben wenn der neue Compiler offiziel ist. Nur ob man dann auch das 2.A Profil nutzt?

[Demirug]

Original geschrieben von LovesuckZ
Bedeutet dies, dass die NV3x Karten mit der NV bevorzugten Sortierung und FP32 genauso schnell sind wie mit der ungünstigen Sortiering und vielen FP16 Berechnungen?

Nicht ganz.

Es sieht im Moment so:


MS Cg
Temps viele wenige (besser)
Länge kurz länger (schlechter)
Sortierung R3XX NV3X (besser)
Format fp16 fp32 (schlechter)


Es kommt also noch die Länge und die Anzahl von Temps hinzu.

Das besser/schlechter bezieht sich auf einen NV3X.

[Razor]

Original geschrieben von Demirug
pp ist immer zulässig da es ja nur einen Hinwweis darstellt das mit fp16 gearbeitet werden darf. Warum Cg diese jetzt aber nicht macht müsste man erst noch prüfen.
Ah ja, verstehe...
Diese Anweisungen würden von einer ATI-Karte also einfach ignoriert werden ?
Original geschrieben von Demirug
Die meisten Shader sind was die sortierung angeht noch einigermassen OK für NV3X da sie wenige Textureanweisungen enthalten. Da aber Cg jetzt fp32 verwendet und längere Shader erzeugt werden die Gewinne duch die geringere Anzahl von Temps und eine minimal bessere sortierung gleich wieder aufgefressen.
Na das ist doch mal 'ne Erklärung !
Bis dato konnte ich mir nun wirklich nicht erklären, wie der 2.0-Zielpfad der M$-SDK-Compilers 'bessere' (verdaulichere ;-) Shader 'basteln' konnte, als es Cg tut.

Diese Erklärung aber, macht Sinn.
Original geschrieben von Demirug
Cg mit 2.X ist nur minimal besser als 2.0 aber 2.A kann in der Regel kürzere Shader als MS 2.0 erzeugen welche weniger Temps benutzen und die richtige sortierung haben.

Es soll ja einen Patch geben wenn der neue Compiler offiziel ist. Nur ob man dann auch das 2.A Profil nutzt?
Einen Patch für TRAOD ?
Wenn ja: warum einen Patch, wenn sich dadurch nichts verändern würde ?
Hmmm...

Razor

P.S.: So eins, zwei Patches würden TR6 aber wirklich 'gut' tun... *eg*

[Razor]

Und mit dem neuen Compiler-Zielpfad im M$-SDK würde es dann so aussehen ?

MS2.0 Cg MS2.A
Temps viele wenige noch weniger (optimal)
Länge kurz länger noch kürzer (optimal)
Sortierung R3XX NV3X NV3X (optimal)
Format fp16 fp32 fp16/fp32 (optimal)

Wäre dann ja wirklich interessant zu sehen, wie solcherat 'vorbereitete' Shader laufen würden. Wenn dann noch der Treiber das seinige tut...
Hmmm...

Razor

[Demirug]

Original geschrieben von Razor
Ah ja, verstehe...
Diese Anweisungen würden von einer ATI-Karte also einfach ignoriert werden ?

Ja Chips die nur ein Format beherschen ignorieren das pp einfach.

Na das ist doch mal 'ne Erklärung !
Bis dato konnte ich mir nun wirklich nicht erklären, wie der 2.0-Zielpfad der M$-SDK-Compilers 'bessere' (verdaulichere ;-) Shader 'basteln' konnte, als es Cg tut.

Diese Erklärung aber, macht Sinn.


Einen Patch für TRAOD ?
Wenn ja: warum einen Patch, wenn sich dadurch nichts verändern würde ?
Hmmm...

Razor

naja auf jeden Fall wollen sie das Problem beseitigen das Cg nicht ohne zusätzliche Cg-Installation läuft. Eigentlich sollte es auch so gehen aber die haben eine falsche DLL mit ausgeliefert.

[Demirug]

Original geschrieben von Razor
Und mit dem neuen Compiler-Zielpfad im M$-SDK würde es dann so aussehen ?

MS2.0 Cg MS2.A
Temps viele wenige wenige (optimal)
Länge kurz länger kurz (optimal)
Sortierung R3XX NV3X NV3X (optimal)
Format fp16 fp32 fp16/fp32 (optimal)

Wäre dann ja wirklich interessant zu sehen, wie solcherat 'vorbereitete' Shader laufen würden. Wenn dann noch der Treiber das seinige tut...
Hmmm...

Razor

Mach aus dem kurz bei MS2.A ein "noch kürzer" dann stimmt es. Bei den Temps könnte der MS Compiler auch noch etwas besser sein als Cg.

[Razor]

Original geschrieben von Demirug
naja auf jeden Fall wollen sie das Problem beseitigen das Cg nicht ohne zusätzliche Cg-Installation läuft. Eigentlich sollte es auch so gehen aber die haben eine falsche DLL mit ausgeliefert.
Wie ?
Einfach nur ein integrierter Cg-Compiler ?
Hmmm...

Razor

[Razor]

Original geschrieben von Demirug
Mach aus dem kurz bei MS2.A ein "noch kürzer" dann stimmt es. Bei den Temps könnte der MS Compiler auch noch etwas besser sein als Cg.
Hab' ich mal gemacht... ;)

Aber mich würde trotzdem mal interessieren, ob kürzere Shader mit weniger Temps nicht auch ATI zugute kommen würde. Klar, die Sortierung sollte schon auf die jeweilige Architektur angepaßt werden, bei dem Format ist es ja 'eh egal...

Razor

[Quasar]

Werden die kürzeren Shader nicht über die erweiterten Fähigkeiten der nV3x-Shader erreicht? Wenn ja, hülfe das ATi eher nichts, oder?

[Demirug]

Original geschrieben von Razor
Wie ?
Einfach nur ein integrierter Cg-Compiler ?
Hmmm...

Razor

Nein der Cg Compiler bleibt weiterhin extern so das man in auch noch nachträglich austauschen kann. So war das von anfang an auch gedacht. Nur die haben die Cg DLL für DX8 dazugepackt und die für DX9 wird eben gebraucht.

[Demirug]

Original geschrieben von Quasar
Werden die kürzeren Shader nicht über die erweiterten Fähigkeiten der nV3x-Shader erreicht? Wenn ja, hülfe das ATi eher nichts, oder?

Ja genau so ist es. Die 2.A Shader laufen auf einem R300 gar nicht.

[Gast]

Unglaublich

So schlecht sind also die FX-Karten unter DX9. Wenn TombRaider AoD auch nur andeutet wie schlecht die Karten wirklich sind (wenn man nicht speziell für sie programmiert) dann gute Nacht Nvidia.

sollten die Karten unter HL2 ebenso schlecht abschneiden, dann sollte sich Nvidia schon mal auf einen herben Image-Verlust und Verkaufsrückgang gefasst machen.

Link :

TombRaider AoD mit verschiedenen Karten getestet :

http://www.beyond3d.com/misc/traod_dx9perf/

[Razor]

Du hast es nicht verstanden, Gast... oder ?
???

Razor

[aths]

Ich denke er hat schon verstanden, dass die DX9-Power der FX-Karten verglichen mit R300 und R350 vergleichsweise dürftig ist.

[Razor]

Dann muss ich auch Dir nachsagen, dass Du diesen Thread offensichtlich nicht verfolgt hast...

Ja, mit ATI-Optimierten Shadern ist die FX langsamer.
Wie verwunderlich...

Also wirklich.

Razor

P.S.: Zitat von Demirug...

"Die meisten Shader sind was die sortierung angeht noch einigermassen OK für NV3X da sie wenige Textureanweisungen enthalten. Da aber Cg jetzt fp32 verwendet und längere Shader erzeugt werden die Gewinne duch die geringere Anzahl von Temps und eine minimal bessere sortierung gleich wieder aufgefressen."

[aths]

Original geschrieben von Razor
Dann muss ich auch Dir nachsagen, dass Du diesen Thread offensichtlich nicht verfolgt hast...

Ja, mit ATI-Optimierten Shadern ist die FX langsamer.
Wie verwunderlich...

Also wirklich. Auch mit für NV optimierten Shadern erreicht weder NV35, und schon gar nicht NV30 das Niveau des jeweiligen Konkurrenchips (also R350 bzw. R300.) Mehr sage ich hierzu nicht, da es dazu bald genaueres geben wird (was nicht von mir stammt.)

[Gast]

Original geschrieben von aths
Ich denke er hat schon verstanden, dass die DX9-Power der FX-Karten verglichen mit R300 und R350 vergleichsweise dürftig ist.

Jo, und sobald dann mal eine Applikation erscheint, wo nV schneller ist, wird ganz schnell und ganz laut "CHEAT" gebrüllt und schon ist die Welt wieder schön schwarz/weiss.


Die DX9-Power einiger FX-Karten ist, verglichen mit einigen R300/R350 etwas dürftig, aber so, wie du's oben geschrieben hast, ist es schlichtweg genauso unbrauchbar, wie die Aussage, der nV20 wäre 7x schneller als der nV15. ;-)

q@w

[Razor]

Original geschrieben von aths
Auch mit für NV optimierten Shadern erreicht weder NV35, und schon gar nicht NV30 das Niveau des jeweiligen Konkurrenchips (also R350 bzw. R300.) Mehr sage ich hierzu nicht, da es dazu bald genaueres geben wird (was nicht von mir stammt.)
Wo sind denn bitte "NV-optimierte Shader" ?
???

Oder was war an meinem Zitat von Demirugs Feststellung unverständlich ?
Nur zur Erinnerung: MIT Cg ist meine FX5900 LANGSAMER, als ohne Cg !
Ich würde Dich wirklich bitten, den ganzen Thread zu lesen...

Razor

[aths]

Original geschrieben von Gast
Jo, und sobald dann mal eine Applikation erscheint, wo nV schneller ist, wird ganz schnell und ganz laut "CHEAT" gebrüllt und schon ist die Welt wieder schön schwarz/weiss.Cheat wird dann gebrüllt, wenn er nachgewiesen wurde.
Original geschrieben von Gast
Die DX9-Power einiger FX-Karten ist, verglichen mit einigen R300/R350 etwas dürftig, aber so, wie du's oben geschrieben hast, ist es schlichtweg genauso unbrauchbar, wie die Aussage, der nV20 wäre 7x schneller als der nV15. ;-)Insgesamt lässt sich sagen: NV30 kommt lange nicht an den R300 ran, und NV35 kommt nicht ganz an R350 ran, sofern die jeweilige Hardware optimal genutzt wird.

Es lassen sich sicher auch Shader konstruieren, die auf NV-HW schneller laufen, allerdings wie man sieht, sieht es in der momentanen Spiele-Realität genau andersrum aus.

[Demirug]

Der Spruch gefällt mir am besten:

Bear in mind that Cg shaders are being used here for the FX boards, so this should put them on their best footing.

Da frage man sich natürlich ob man das auch auspropiert hat oder einfach mal mit der falschen universallogik gearbeitet hat.

[aths]

Original geschrieben von Razor
Wo sind denn bitte "NV-optimierte Shader" ?
???

Oder was war an meinem Zitat von Demirugs Feststellung unverständlich ?
Nur zur Erinnerung: MIT Cg ist meine FX5900 LANGSAMER, als ohne Cg !
Ich würde Dich wirklich bitten, den ganzen Thread zu lesen... Ich würde dich wirklich bitten, mein Posting zu lesen. Man kann für NV optimieren, was man will — ATI bietet derzeit mehr Shader-Rohpower.

[Razor]

Original geschrieben von aths
Insgesamt lässt sich sagen: NV30 kommt lange nicht an den R300 ran, und NV35 kommt nicht ganz an R350 ran, sofern die jeweilige Hardware optimal genutzt wird.
Und wo wird nVidia-Hardware 'optimal' genutzt ?
Im Murks etwa, weil da ja 'Handoptimiert' ?
Dann ist eine FX5900u definitiv schneller, als eine R9800p256 !
Original geschrieben von aths
Es lassen sich sicher auch Shader konstruieren, die auf NV-HW schneller laufen, allerdings wie man sieht, sieht es in der momentanen Spiele-Realität genau andersrum aus.
Noch gibt es keine "Spiele-Realität".
Derzeit sind ALLE Applikationen ATI-'optimiert'...
(Ausnahme hier die im Treiber hinterlegten Optimierungen)

Insofern eine konkrete Aussage schlicht noch gar nicht möglich ist.

Razor

[Razor]

Original geschrieben von Demirug
Da frage man sich natürlich ob man das auch auspropiert hat oder einfach mal mit der falschen universallogik gearbeitet hat.
Ich habe es ja ausprobiert...
Mit Cg langsamer, als ohne.

DAS dürfte ja wohl wirklich alles sagen, oder ?
;-)

Razor

[Razor]

Original geschrieben von aths
Ich würde dich wirklich bitten, mein Posting zu lesen. Man kann für NV optimieren, was man will — ATI bietet derzeit mehr Shader-Rohpower.
Und das stellst Du einfach so ohne nähere Hintergründe in den Raum ?
Oder hast Du Dir das aus den Fingern gesagt ?
???

Razor

[aths]

Original geschrieben von Razor
Und wo wird nVidia-Hardware 'optimal' genutzt ?
Im Murks etwa, weil da ja 'Handoptimiert' ?
Dann ist eine FX5900u definitiv schneller, als eine R9800p256 !Nvidias Shader liefern nicht exakt das Ergebnis der Original-Shader. Durch schlechtere Grafikqualität schneller zu sein ist keine Kunst.
Original geschrieben von Razor
Noch gibt es keine "Spiele-Realität".
Derzeit sind ALLE Applikationen ATI-'optimiert'... Eben das ist die derzeitige Realität.

[aths]

Original geschrieben von Razor
Und das stellst Du einfach so ohne nähere Hintergründe in den Raum ?
Oder hast Du Dir das aus den Fingern gesagt ?
???

Razor Klar, ich sauge mir einfach mal was aus den Fingern :bonk: Lesen hilft:
Original geschrieben von aths
Mehr sage ich hierzu nicht, da es dazu bald genaueres geben wird (was nicht von mir stammt.)

[Razor]

Original geschrieben von aths
Nvidias Shader liefern nicht exakt das Ergebnis der Original-Shader. Durch schlechtere Grafikqualität schneller zu sein ist keine Kunst.
Zeig mir das bitte an einem einzigen Beispiel mit derzeit aktuellen Treibern (Deto 45.23) !
(und vergiß UT2003 ;-)
Original geschrieben von aths
Eben das ist die derzeitige Realität.
Welche sich recht zügig geben dürfte.

Zumindest haben wir also nun doch die Aussage:
"ATI-optimierte Shader laufen auf nVidia Hardware nicht wirklich gut."
Und noch einmal: "Wie verwunderlich !"
:D

Razor

[Razor]

Original geschrieben von aths
Klar, ich sauge mir einfach mal was aus den Fingern :bonk: Lesen hilft:
Dann laß bitte auch solche Anspielungen, wenn Du sie (noch) nicht belegen kannst.
Oder sind wir hier im Speku-Forum ?

Razor

[aths]

Original geschrieben von Razor
Zeig mir das bitte an einem einzigen Beispiel mit derzeit aktuellen Treibern (Deto 45.23) !Ich habe keine FX.
Original geschrieben von Razor
Welche sich recht zügig geben dürfte.Angesichts der Entwicklungszeit von Spielen glaube ich nicht unbedingt an "recht zügig".
Original geschrieben von Razor
Zumindest haben wir also nun doch die Aussage:
"ATI-optimierte Shader laufen auf nVidia Hardware nicht wirklich gut."
Und noch einmal: "Wie verwunderlich !"
:DAndersherum funktioniert es aber: ATI kann auf Radeon mit "nativem" 1.4-er PS wunderbar 1.0 - 1.3 laufen lassen. Schade, dass Nvidia sowas nicht mit den 2.0-ern à la ATI hinbekommen hat.

[aths]

Original geschrieben von Razor
Dann laß bitte auch solche Anspielungen, wenn Du sie (noch) nicht belegen kannst.
Oder sind wir hier im Speku-Forum ? Das waren keine Spekulationen :) Dir steht frei, zu glauben, was du willst, das wird die Realitäten nicht ändern :) (edit: Bezüglich NV35 muss ich allerdings doch noch mal kurz Nachforschungen anstellen... nicht, dass hier ein grandioser Denkfehler vorliegt. edit2: Nein, da liegt doch kein Denkfehler vor, im Gegenteil, es ist schlimmer als gedacht...)

[Demirug]

Original geschrieben von Razor
Dann laß bitte auch solche Anspielungen, wenn Du sie (noch) nicht belegen kannst.
Oder sind wir hier im Speku-Forum ?

Razor

Können könnte er schon aber er darf es eben noch nicht. ;)

Aber das ganze Kapitel Shaderleistung auf eine solche Kernaussage die durchaus ihrer richtigkeit einzudampfen wird dem Thema nicht gerrecht.

@aths: die meisten TR6 Shader sind rechenlastig und weit weg vom 1:1 Verhältniss. Ich gehe mal zählen.

[Demirug]

Original geschrieben von aths
Andersherum funktioniert es aber: ATI kann auf Radeon mit "nativem" 1.4-er PS wunderbar 1.0 - 1.3 laufen lassen. Schade, dass Nvidia sowas nicht mit den 2.0-ern à la ATI hinbekommen hat.

Das ist aber auch von der Problemstellung schon ein unterschied wie zwischen Kreisliga und 1. Bundesliga.

[aths]

Original geschrieben von Demirug
Das ist aber auch von der Problemstellung schon ein unterschied wie zwischen Kreisliga und 1. Bundesliga. Das stimmt natürlich. Trotzdem begab sich NV sehenden Auges auf diese Straße, auf neue Optimerungs-Regeln angewiesen zu sein. Da ich können könnte, aber noch nicht darf, hebe ich mir den Rest mal für später auf.

[Razor]

Original geschrieben von aths
Das stimmt natürlich. Trotzdem begab sich NV sehenden Auges auf diese Straße, auf neue Optimerungs-Regeln angewiesen zu sein.
Offensichtlich unterscheiden sich die Architekturen zwischen ATI und nVidia doch wohl massivst...
Somit ergeben sich derzeit doch wohl folgende Aspekte:
- ATI's Treiber sind hinsichtlich der PS2.0 gute 6-9 Monate länger am Markt
- Derzeitige Shader-compilate sind eindeutig ATI-Optimiert
- Noch muss nVidia 'handoptimieren', um optimale Performance zu erhalten

Insofern halte ich derzeitige 'Schlußfolgerungen' für einen "Pups im Wind".

Zukünftige Treiber werden zeigen müssen, ob sie dieses 'Ungleichgewicht' ausgleichen können, oder eben nicht. Hinsichtlich Kompatibilität und auch Qualität sind die 45.23 schon mal weit vorne (mal von UT2003 abgesehen ;-). Viele 'Schwachheiten' der ersten Treiber sind ausgeglichen. Insofern man das Thema "Kompatibilität und Qualität" langsam abhaken kann und sich nun dem Thema "Performance" zuwenden kann. Traditionell ist nVidia schon immer so vorgegangen, insofern sich dies auch jetzt wieder bestätigt. Mal schaun', was da noch so kommt, gell ?
;-)

Razor

[Gast]

Original geschrieben von aths
Cheat wird dann gebrüllt, wenn er nachgewiesen wurde.
Dann schau dir mal die Foren-Realität an, Bsp. der Thread von Exxtreme, in dem es um das extremetech-Review mit der IQ geht: Kaum ist nV in MSFS2004 schneller, wird sofort der Verdacht impliziert, es handele sich um Cheats.
Wie ich dort schon schrieb, bei nV ist's halt, daß die "generell scheiss-lahm sind und ihre Kunden verarschen" und bei ATi ist's dann so, daß die Armen nur immer und immer von nV betrogen werden und sich doch irgendwie wehren müssen. :lol:

Original geschrieben von aths
Insgesamt lässt sich sagen: NV30 kommt lange nicht an den R300 ran, und NV35 kommt nicht ganz an R350 ran, sofern die jeweilige Hardware optimal genutzt wird.

Das ist leider genauso falsch oder zumindest unvollständig, wie deine Aussage im ersten Posting. Oder was genau meinst du mit "Hardware optimal nutzen"?


Original geschrieben von aths
Es lassen sich sicher auch Shader konstruieren, die auf NV-HW schneller laufen, allerdings wie man sieht, sieht es in der momentanen Spiele-Realität genau andersrum aus.

Man braucht keine Shader "konstruieren", deine Aussage von oben ist so, wie du sie getroffen hast, nicht vollständig und damit nicht haltbar.

q@w

[aths]

Original geschrieben von Razor
Offensichtlich unterscheiden sich die Architekturen zwischen ATI und nVidia doch wohl massivst...Einerseits das, andererseits bietet ATI mehr an Rohpower.

[aths]

Original geschrieben von Gast
Dann schau dir mal die Foren-Realität an, Bsp. der Thread von Exxtreme, in dem es um das extremetech-Review mit der IQ geht: Kaum ist nV in MSFS2004 schneller, wird sofort der Verdacht impliziert, es handele sich um Cheats.Von mir aber nicht :)
Original geschrieben von Gast
Das ist leider genauso falsch oder zumindest unvollständig, wie deine Aussage im ersten Posting. Oder was genau meinst du mit "Hardware optimal nutzen"?Die Hardware voll auszulasten. Allerdings gibt es hier schon Probleme, weil ATI und NV auf unterschiedliche Sampling/Instruktion-Verhältnisse setzen. Aber für wen man da auch das Optimum wählt, ATIs Hardware leistet mehr pro Takt, meistens so viel mehr, dass der Mehrtakt von NV-Karten das nicht ausgleichen kann. Genauer darf ich derzeit wirklich nicht werden.
Original geschrieben von Gast
Man braucht keine Shader "konstruieren", deine Aussage von oben ist so, wie du sie getroffen hast, nicht vollständig und damit nicht haltbar.Was ich aussagen will, ist, dass die großen NV-Karten weniger Shader-Power als die großen ATI-Karten haben.

[Gast]

Original geschrieben von aths
Das stimmt natürlich. Trotzdem begab sich NV sehenden Auges auf diese Straße, auf neue Optimerungs-Regeln angewiesen zu sein. Da ich können könnte, aber noch nicht darf, hebe ich mir den Rest mal für später auf.

Eben aths;

lass es einfach sein. Razor von seiner vorgefassten Meinung abzubringen ist schwer...sehr schwer. Vielleicht versuchst du einfach mal einem 3jährigen die SRT beizubringen; da hast du wahrscheinlich mehr Erfolg.

[Gast]

Original geschrieben von aths
Was ich aussagen will, ist, dass die großen NV-Karten weniger Shader-Power als die großen ATI-Karten haben.

Fällt mir ein wenig schwer das genau nachzuvollziehen.
Wie willst du den Shaderpower vergleichen, wenn beide nicht die selbe Qualität liefern.
ATI bietet FP24.
Nvidia bietet FP16 und FP32.

Ein genauer Vergleich ist somit nicht möglich. FP16 hat die schlechtere Qualität und FP32 die bessere.

[Demirug]

Original geschrieben von aths
Die Hardware voll auszulasten. Allerdings gibt es hier schon Probleme, weil ATI und NV auf unterschiedliche Sampling/Instruktion-Verhältnisse setzen. Aber für wen man da auch das Optimum wählt, ATIs Hardware leistet mehr pro Takt, meistens so viel mehr, dass der Mehrtakt von NV-Karten das nicht ausgleichen kann. Genauer darf ich derzeit wirklich nicht werden.

aths, höre bitte auf einzelne Teile aus dem Zusammenhang gerissen hier wiederzugeben. Das stimmt ja alles was du schreibst nur fehlen da immer die Angaben unter welchen Umständen das auch so zutrifft.

[aths]

Original geschrieben von Gast
Fällt mir ein wenig schwer das genau nachzuvollziehen.
Wie willst du den Shaderpower vergleichen, wenn beide nicht die selbe Qualität liefern.
ATI bietet FP24.
Nvidia bietet FP16 und FP32.

Ein genauer Vergleich ist somit nicht möglich. FP16 hat die schlechtere Qualität und FP32 die bessere. Es ist dem NV35 egal, ob er mit FP16 oder FP32 rechnet, in beiden Fällen ist seine Rohleistung geringer als die des R350.

[aths]

Original geschrieben von Demirug
aths, höre bitte auf einzelne Teile aus dem Zusammenhang gerissen hier wiederzugeben. Das stimmt ja alles was du schreibst nur fehlen da immer die Angaben unter welchen Umständen das auch so zutrifft. Ich will ja nicht zuviel verraten :naughty:

[Demirug]

Original geschrieben von Gast
Fällt mir ein wenig schwer das genau nachzuvollziehen.
Wie willst du den Shaderpower vergleichen, wenn beide nicht die selbe Qualität liefern.
ATI bietet FP24.
Nvidia bietet FP16 und FP32.

Ein genauer Vergleich ist somit nicht möglich. FP16 hat die schlechtere Qualität und FP32 die bessere.

Shaderleistung misst man in Instruktions/Takt und Instruktionen/Sec.

Die Qualitätsunterschiede zwischen fp16, fp24 und fp32 sind durchaus vorhanden aber in der Regel sehr gering. Möchte man das ganze aber brücksichtigen so muss man eben bei nv Karten einmal mit fp16 und einmal mit fp32 messen soweit das überhaupt möglich ist.

[Gast]

Original geschrieben von aths
Von mir aber nicht :)
Die Hardware voll auszulasten. Allerdings gibt es hier schon Probleme, weil ATI und NV auf unterschiedliche Sampling/Instruktion-Verhältnisse setzen. Aber für wen man da auch das Optimum wählt, ATIs Hardware leistet mehr pro Takt, meistens so viel mehr, dass der Mehrtakt von NV-Karten das nicht ausgleichen kann. Genauer darf ich derzeit wirklich nicht werden.
Was ich aussagen will, ist, dass die großen NV-Karten weniger Shader-Power als die großen ATI-Karten haben.

Dann schreib' es bitte auch so, wie du es meinst und wie es richtig ist.
Denn es gibt auch durchaus R300, die nur die halbe Shaderleistung anderer R300 haben, selbiges soll wohl für den R350 gelten.

Um Shaderleistung direkt zu vergleichen, ist es IMO sinnvoll, aufzutrennen, was "ein einzelner Shader" leistet und was die Gesamtheit der Shader auf einer bestimmten Karte leistet.

AFAIK haben "vollständige" ;) R300/R350-Chips doppelt soviele, DX9-Compliancy-Anforderungen erfüllende Shader an Bord wie nV30/ nV35. ;)

q@w

[aths]

Original geschrieben von Gast
AFAIK haben "vollständige" ;) R300/R350-Chips doppelt soviele, DX9-Compliancy-Anforderungen erfüllende Shader an Bord wie nV30/ nV35. ;)Da ich können könnte, aber noch nicht darf, halte ich vorläufig einfach mal die Schnauze.

[Demirug]

Immer Tex:Arithmetik

1. Spalte der echte Shader
2. Spalte normalisiert

1. 4:32 1:8
2. 3:36 1:12
3. 2:40 1:20
4. 0:3 0:3
5. 1:4 1:4
6. 1:3 1:3
7. 3:27 1:9
8. 4:28 1:7
9. 2:19 1:9,5
10. 3:27 1:9
11. 4:32 1:8
12. 14:22 1:1,57
13. 6:10 1:1,67
14. 5:49 1:9,8


Das sind die 14 PS 2.0 die benutzt werden. Wie man sieht alles rechenlastig. Bis auf 2 Ausnahmen (1:1,57 und 1:1,67) sogar deutlich. Den CineFX I Chips schmeckt sowas auch bei richtiger sortierung nicht sonderlich. Die CineFX II Chips sollte bei entsprechender Sortierung sowie einem entsprechenden Treiber damit aber besser zurecht kommen.

Diese Aussagen werden natürlich in dem Moment hinfällig wenn nVidia wirklich die Drohung wahrmacht und die angeblich zusätzlich Leistung der FPUs (CineFX I und II) freisetzt. Ich schreibe angeblich weil sich das vorhandensein dieser Leistung (mehr als eine Arithmetikop/Takt pro FPU) zwar theoretisch nachweisen lässt und es auch von nVidia entsprechende Andeutungen gibt aber der Beweiss bisher noch nicht erfolgt ist.

EDIT: Eindeutiger gemacht

[Ailuros]

Original geschrieben von aths
Da ich können könnte, aber noch nicht darf, halte ich vorläufig einfach mal die Schnauze.

OT: wie lange ist vorlaeufig? :D

[Razor]

Original geschrieben von aths
Einerseits das, andererseits bietet ATI mehr an Rohpower.
Mag sein... ist aber kein Indikator für die Real-Worl-Performance.
Insofern solltest Du einfach 'faire' Real-World-Vergleiche abwarten...
;-)

Razor

[Razor]

Original geschrieben von aths
Ich will ja nicht zuviel verraten :naughty:
Dann laß es doch einfach ganz.

Razor

[Gast]

Original geschrieben von Demirug
Diese Aussagen werden natürlich in dem Moment hinfällig wenn nVidia wirklich die Drohung wahrmacht und die angeblich zusätzlich Leistung der FPUs (CineFX I und II) freisetzt. Ich schreibe angeblich weil sich das vorhandensein dieser Leistung (mehr als eine Arithmetikop/Takt pro FPU) zwar theoretisch nachweisen lässt und es auch von nVidia entsprechende Andeutungen gibt aber der Beweiss bisher noch nicht erfolgt ist.


Du sprichst doch wohl nicht von unseren Super-Duper-Wundertreibern 50.xx

Da bin ich aber mal gespannt.


Frage : wo ist eigentlich der Unterschied zwischen CineFX und CineFX II. Welche Chips meinst du. NV35/36/38 oder NV4x?

[Gast]

Original geschrieben von Ailuros
OT: wie lange ist vorlaeufig? :D


Wahrscheinlich bis es die PS2_a und VS2_a - Pfade in DX9 offiziell gibt.

[Demirug]

Original geschrieben von Gast
Du sprichst doch wohl nicht von unseren Super-Duper-Wundertreibern 50.xx

Da bin ich aber mal gespannt.

Keine Ahnung ob sich nVidia dieser Optionen schon im Deto 50.XX annimmt. Es ist auf jeden Fall komplex dafür einen automatischen Compiler zu bauen. Hier (http://graphics.stanford.edu/projects/shading/pubs/hwws2001-regcomb/) kann man sich ansatzweise einen Eindruck davon machen. Die NV3X FPUs sind allerdings im Aufbau noch etwas komplizierter als die alten NV2X Reg Combiner auf welche sich diese Papier bezieht.

Frage : wo ist eigentlich der Unterschied zwischen CineFX und CineFX II. Welche Chips meinst du. NV35/36/38 oder NV4x?

CineFX I = NV30/NV31/NV34
CineFX II = NV35 (möglicherweise NV36)

Bei CineFX II wurde die Fliesspunktleistung pro Takt gegenüber CineFX I gesteigert weil CineFX I sich vom Detail-Design her nicht so gut mit den Pixelshadern > 1.4 verträgt weil MS auf durchgängige Fliesspunktberechnungen bestanden hat.

[StefanV]

Original geschrieben von Gast
Frage : wo ist eigentlich der Unterschied zwischen CineFX und CineFX II. Welche Chips meinst du. NV35/36/38 oder NV4x?

1. k/a, wird Demirug schon sagen...
Unter anderem wurden die Integer EInheiten der PS entfernt und durch FP Einheiten ersetzt...

2. NV3x<5 und NV35

[Ailuros]

Original geschrieben von Gast
Wahrscheinlich bis es die PS2_a und VS2_a - Pfade in DX9 offiziell gibt.

Nein. :asshole:

[Gast]

Original geschrieben von Ailuros
Nein. :asshole:

Frechheit...lasst mich nicht dumm sterben ;D

[Benedikt]

Da ich können könnte, aber noch nicht darf, halte ich vorläufig einfach mal die Schnauze.

Also jetz mal Klartext bitte!

Ihr müsst ja nicht das NDA brechen, nur wär's schon recht interessant ob sich für die CineFX I -Architektur noch was ändern könnte !?

Rein auf technischer Basis, wieviel könnte sich denn Shader-Performancemäßig (größer gleich PS 1.4) noch zum Besseren wenden (ob das jetzt Deto50.xx oder sonst was sein soll)?

Solche Aussagen lassen sich ja durchaus ohne NDA-Verletzungen "hinbiegen", oder? :D

Schöne Grüße,

BW

[AlfredENeumann]

Original geschrieben von Razor
Dann muss ich auch Dir nachsagen, dass Du diesen Thread offensichtlich nicht verfolgt hast...

Ja, mit ATI-Optimierten Shadern ist die FX langsamer.
Wie verwunderlich...

Also wirklich.

Razor


Das interessiert den Endkunden recht herzlich wenig, um es mit Richthofens worten zu sagen. Der Endkunde sieht nur die Zahlen, nicht wie sie zustandekommen. Daher sieht er nur ATI=gut, NV=schlecht.

Da sach ich nur Pech für NV.

[Demirug]

Original geschrieben von Benedikt
Also jetz mal Klartext bitte!

Ihr müsst ja nicht das NDA brechen, nur wär's schon recht interessant ob sich für die CineFX I -Architektur noch was ändern könnte !?

Rein auf technischer Basis, wieviel könnte sich denn Shader-Performancemäßig (größer gleich PS 1.4) noch zum Besseren wenden (ob das jetzt Deto50.xx oder sonst was sein soll)?

Solche Aussagen lassen sich ja durchaus ohne NDA-Verletzungen "hinbiegen", oder? :D

Schöne Grüße,

BW

NDA? was für einen NDA? aths weist du was von einer NDA?

Zudem glaube ich kaum das uns nVidia sowas geben würde nicht mal wenn wir eine NDA unterschrieben hätten.

das aths die Schnauze hält hat andere Gründe.

[Demirug]

Original geschrieben von AlfredENeumann
Das interessiert den Endkunden recht herzlich wenig, um es mit Richthofens worten zu sagen. Der Endkunde sieht nur die Zahlen, nicht wie sie zustandekommen. Daher sieht er nur ATI=gut, NV=schlecht.

Da sach ich nur Pech für NV.

Ja in der universelle Sprache der Benchmarkbalken sieht es nicht so gut aus. Die sollen endlich den Arsch hochbekommen.

[aths]

Original geschrieben von Demirug
NDA? was für einen NDA? aths weist du was von einer NDA?Wenn ich eins unterschrieben hätte, dürfte ich es nicht sagen :D Aber ich weiß wirklich nichts von einem NDA.

[aths]

Original geschrieben von Razor
Dann laß es doch einfach ganz.Ich weiß schon, was ich schreibe :)Original geschrieben von Razor
Mag sein... ist aber kein Indikator für die Real-Worl-Performance.
Insofern solltest Du einfach 'faire' Real-World-Vergleiche abwarten...
;-)Nun, ich denke, dass Doom3 auf NV-High-End schneller laufen wird, als auf ATI-High-End. Bislang war ATI bei _Shadern_ deutlich schneller. Ich erwarte da nicht, dass sich die Verhältnisse, auf die Spiele-Masse bezogen, umkehren. Sich wird NV in Zukunft auch stärkere Karten herausbringen, ATI allerdings auch.

[Ailuros]

Frage an Demirug:

Hast Du eine Ahnung wie ATI es geschafft hat die stencil/AA Leistung bei NWN zu erhoehen, oder wenigstens ein szenario dass Sinn machen koennte? Ich wuerde auf eine Art buffer clearing tippen...

Auf jeden Fall wenn ja, waere sowas auch in Doom3 moeglich? (ich wuerde hier auf nein tippen, aber frag nicht warum).

Seitennotiz: ich weiss dass es schon wieder OT ist, aber mir ist sowohl TR:AoD und dessen DOF Implementation (schade dass man es nur mit einem O schreibt) total schnuppe....

[Demirug]

@Ailuros: Tut mir leid aber da habe ich keine Ahnung zudem ich ja nicht mal genau weiss was nwn mit dem Stencilbuffer macht.

[Ailuros]

Na ja es wird ja auch elegant vermeidet relevante Fragen in aller Oeffentlichkeit zu beantworten. Als ein Entwickler das letzte Mal danach fragte bei Rage3D, wurde wohl seine Frage durch PM beantwortet.

[Razor]

Original geschrieben von aths
Ich weiß schon, was ich schreibe :)
Wirklich ?
Ein Scherz...
;-)
Original geschrieben von aths
Nun, ich denke, dass Doom3 auf NV-High-End schneller laufen wird, als auf ATI-High-End.
Ähmm... ja und ?
Original geschrieben von aths
Bislang war ATI bei _Shadern_ deutlich schneller.
Ich formuliere es so: "Bislang war ATI bei [ATI-optimierten-] _Shadern_ deutlich schneller."
Original geschrieben von aths
Ich erwarte da nicht, dass sich die Verhältnisse, auf die Spiele-Masse bezogen, umkehren.
Wie jetzt ?
Bezogen auf Doom3 oder bezogen auf _Shader_ ?
Original geschrieben von aths
Sich wird NV in Zukunft auch stärkere Karten herausbringen, ATI allerdings auch.
Ah ja... war das schon jemals anders ?
???

Also irgendwie...

Razor

[Aquaschaf]

Momentan siehts doch so aus, dass ATI auch mit NV-optimierten Shadern in der Regel schneller ist?

[Demirug]

Original geschrieben von Aquaschaf
Momentan siehts doch so aus, dass ATI auch mit NV-optimierten Shadern in der Regel schneller ist?

Du meinst den Schrott den der Cg-Compiler baut?

[Aquaschaf]

Wird das neue Profile des MS Compilers viel ändern?

Ne, meine Aussage beruht darauf, dass ich an mehreren Stellen hier im Forum gelesen habe die R3xx Karten besäßen einfach mehr Rechenleistung.

[Quasar]

Original geschrieben von Aquaschaf
[...] an mehreren Stellen hier im Forum gelesen habe die R3xx Karten besäßen einfach mehr Rechenleistung.

Wird ja auch gern und undifferenziert immer wieder behauptet...

[Demirug]

Original geschrieben von Aquaschaf
Wird das neue Profile des MS Compilers viel ändern?

Ja der MS-Compiler ist bei 2.X viel besser als der Cg Compiler.

Ne, meine Aussage beruht darauf, dass ich an mehreren Stellen hier im Forum gelesen habe die R3xx Karten besäßen einfach mehr Rechenleistung.

Ja und nein. Ich kann da aber zur Zeit nicht so sehr in die Details gehen. Kurz gesagt: CineFX I Chips (5800/5600/5200) sind etwas schwach was die Fliesspunktrechenleistung angeht. CineFX II Chips (5900) können von der Peak Leistung eine 9700/9800 nicht erreichen. Allerdings wird diese Leistung nur unter ganz bestimmten Umständen erreicht und bei einer Abweichung vom Idealzustand (der nicht für alle Chips der gleiche ist) fallen beiden unterschiedlich stark ab. Bei der 5900 ist dieser Abfall nicht so stark wie bei der 9700/9800.

[Demirug]

Original geschrieben von Quasar
Wird ja auch gern und undifferenziert immer wieder behauptet...

Ich würde gerne noch mehr differenzieren nur sind mir im Moment etwas die Hände gebunden.

[Exxtreme]

Interessanter Kommentar von einem HL2-Entwickler:

http://www.3dgpu.com/modules/news/article.php?storyid=315

[nggalai]

Besonders weh tut in der Hinsicht das hier:

http://www.beyond3d.com/misc/traod_dx9perf/index.php?p=5

Settings für GFFX und R3x0, womit mehr oder weniger dieselbe Geschwindigkeit erreicht wird. Aua, aua, aua. Wenn der Trend wie von Gabe angedeutet auch bei HL2 ziehen wird, werden viele Leute ziemlich heftig rumfluchen, wenn das Spiel kommt.

93,
-Sascha.rb

[Gast]

Original geschrieben von nggalai
Besonders weh tut in der Hinsicht das hier:

http://www.beyond3d.com/misc/traod_dx9perf/index.php?p=5

Settings für GFFX und R3x0, womit mehr oder weniger dieselbe Geschwindigkeit erreicht wird. Aua, aua, aua. Wenn der Trend wie von Gabe angedeutet auch bei HL2 ziehen wird, werden viele Leute ziemlich heftig rumfluchen, wenn das Spiel kommt.

93,
-Sascha.rb

Ouch;

ich hab mir das ganze durchgelesen, aber so genau hab ich mir die Tabelle nicht angeschaut :

[code]
Cubemaps 5800 Ultra 5900 Ultra 9700 PRO 9800 PRO
Number 1 3
Camer Update Occasional Half
Character Update Occasional Sixth
Character Quality Low Average
Projected Shadows 5800 Ultra 5900 Ultra 9700 PRO 9800 PRO
Number 1 6 12
Pixel Shader 2.0 Shadows No Yes
Format N/A 32 bit G32F
Depth N/A 32 bit depth D24S8

[nggalai]

Jup, ist heftig--ich meine nur, damit das Spiel auf der GFFX5900 Ultra in etwa gleich läuft wie auf den ATI-Karten, müssen 16bit-Texturen verwendet werden (ATI: 32bit), nur 1 Cubemap aufs mal (statt 3), nur ein Schattenwurf (9700er: 6, 9800er: 12), niedrige Charakterdetails (ATI: Average), kein PS2.0 für DOF . . .

Und das soll eine High-End-Karte sein?

93,
-Sascha.rb

[Gast]

Upps;

Sorry kann wer das obere editieren oder löschen.

hier ist die bessere Version
Cubemaps 5800 Ultra 5900 Ultra 9700 PRO 9800 PRO
Number 1 3
Camer Update Occasional Half
Character Update Occasional Sixth
Character Quality Low Average

Projected Shadows 5800 Ultra 5900 Ultra 9700 PRO 9800 PRO
Number 1 6 12
Pixel Shader No Yes
2.0 Shadows
Format N/A 32 bit G32F
Depth N/A 32 bit depth D24S8

[Gast]

Original geschrieben von nggalai
Jup, ist heftig--ich meine nur, damit das Spiel auf der GFFX5900 Ultra in etwa gleich läuft wie auf den ATI-Karten, müssen 16bit-Texturen verwendet werden (ATI: 32bit), nur 1 Cubemap aufs mal (statt 3), nur ein Schattenwurf (9700er: 6, 9800er: 12), niedrige Charakterdetails (ATI: Average), kein PS2.0 für DOF . . .

Und das soll eine High-End-Karte sein?

93,
-Sascha.rb

Aber verrückt wirds erst dann wenn du dir die nächste Seite anguckst und die R9600Pro-Werte mit der FX5900-Ultra vergleichst. Sowohl bei den Settings als auch bei den fps. Die FX5900-Ultra hat bei diesem Spiel schlechtere Settings als die R9600Pro. Würde mich nicht wundern, wenn die R9600Pro mit den FX5900-Ultra Settings auch so schnell wie eine FX5900-Ultra wäre. ;D

[Demirug]

Original geschrieben von Gast
Aber verrückt wirds erst dann wenn du dir die nächste Seite anguckst und die R9600Pro-Werte mit der FX5900-Ultra vergleichst. Sowohl bei den Settings als auch bei den fps. Die FX5900-Ultra hat bei diesem Spiel schlechtere Settings als die R9600Pro. Würde mich nicht wundern, wenn die R9600Pro mit den FX5900-Ultra Settings auch so schnell wie eine FX5900-Ultra wäre. ;D

Würde mich schon etwas wundern den in den 5900er setting wurde ja mehr oder minder alles entfernt was der 5900 probleme macht.

Zudem hat beyond3d einen Fehler gemacht. Sie hätten nicht den Cg-Compiler benutzen sollen. In der derzeigten Form ist dieser bei TR6 eher schädlich als nützlich. Es macht zwar nicht viel aus aber es zählt ja jeder Frame mehr.

[Mave@China]

The general performances with Trilinear filtering enabled are much the same as those with Anisotropic filtering enabled. In fact the performance differences for all boards between Trilinear and Anisotropic filtering is quite small - most of the rendering time is spent on the shader execution, so the overhead of the extra texture sampling is relatively small in comparison.

Ich dachte immer es wuerden fuer jedes sample die pixel shader durchlaufen , oder erliege ich hier einem schweren Missverstaendniss ? Kann mich bitte jemand aufklaeren !!!

Oder kann der Effekt daher kommen, das relativ wenig wirklich Anisotropisch gefiltert wird ?

[StefanV]

Original geschrieben von Mave@China
The general performances with Trilinear filtering enabled are much the same as those with Anisotropic filtering enabled. In fact the performance differences for all boards between Trilinear and Anisotropic filtering is quite small - most of the rendering time is spent on the shader execution, so the overhead of the extra texture sampling is relatively small in comparison.

Ich dachte immer es wuerden fuer jedes sample die pixel shader durchlaufen , oder erliege ich hier einem schweren Missverstaendniss ? Kann mich bitte jemand aufklaeren !!!

Oder kann der Effekt daher kommen, das relativ wenig wirklich Anisotropisch gefiltert wird ?

AF geht IIRC bei PS Programmen nicht.

[Demirug]

AF wirkt nur auf die Texturen welche der Pixelshader sampelt. Der Pixelshader selbst wird wie der Name schon sagt nur einmal pro Pixel ausgeführt. Die derzeit einzige Möglichkeit einen Shader mehr als einmal pro Pixel laufen zu lassen ist SSAA.

[Mave@China]

Original geschrieben von Demirug
AF wirkt nur auf die Texturen welche der Pixelshader sampelt. Der Pixelshader selbst wird wie der Name schon sagt nur einmal pro Pixel ausgeführt. Die derzeit einzige Möglichkeit einen Shader mehr als einmal pro Pixel laufen zu lassen ist SSAA.


Also erst AF zum erzeugen der gefilerten Pixel und dann der Pixelshader um diese zu veraendern?

[Demirug]

Original geschrieben von Mave@China
Also erst AF zum erzeugen der gefilerten Pixel und dann der Pixelshader um diese zu veraendern?

AF zum erzeugen von gefilterten Textur-Werten welche dann vom Pixelshader zur entgültigen Pixelfarbe verrechnet werden. Die Texturesampler erzeugen ja direkt keine Pixelfarbe das mancht immer der Pixelshader. Auch bei nicht Pixelshader Anwendungen in diesem Fall läuft dann dort ein entsprechendes PS-Programm welches das gewüschte verhalten nachbildet.

[Mave@China]

Danke fuer die antwort. Ich hatte da einfach einen dreher in meiner
Vorstellung drin

[reunion]

Original geschrieben von nggalai
Jup, ist heftig--ich meine nur, damit das Spiel auf der GFFX5900 Ultra in etwa gleich läuft wie auf den ATI-Karten, müssen 16bit-Texturen verwendet werden (ATI: 32bit), nur 1 Cubemap aufs mal (statt 3), nur ein Schattenwurf (9700er: 6, 9800er: 12), niedrige Charakterdetails (ATI: Average), kein PS2.0 für DOF . . .

Und das soll eine High-End-Karte sein?

93,
-Sascha.rb

Und dabei ist die 9800pro noch immer um ca 10% schneller als die fx 5900Ultra...
Also wirklich: :bonk: :schlag:

[Razor@Work]

Original geschrieben von nggalai
Jup, ist heftig--ich meine nur, damit das Spiel auf der GFFX5900 Ultra in etwa gleich läuft wie auf den ATI-Karten, müssen 16bit-Texturen verwendet werden (ATI: 32bit), nur 1 Cubemap aufs mal (statt 3), nur ein Schattenwurf (9700er: 6, 9800er: 12), niedrige Charakterdetails (ATI: Average), kein PS2.0 für DOF . . .

Und das soll eine High-End-Karte sein?

93,
-Sascha.rb
Und Du meinst nicht, dass dies mit der derzeitigen Optimierung auf ATI-Hardware zusammen hängt ?
???

Razor

[nggalai]

Hi Razor,
Original geschrieben von Razor@Work
Und Du meinst nicht, dass dies mit der derzeitigen Optimierung auf ATI-Hardware zusammen hängt ?
???In DEM Mass? Nein. Selbst wenn eine "Optimierung" auf GFFX 100% Geschwindigkeitszuwachs bringen würde (was kaum zu machen ist), wären die GFFX immernoch deutlich lahmer als die ATI-Produkte.

93,
-Sascha.rb

[reunion]

Original geschrieben von Razor@Work
Und Du meinst nicht, dass dies mit der derzeitigen Optimierung auf ATI-Hardware zusammen hängt ?
???

Razor

*lol* da müsste die Optimierung schon ca. 1000% ausmachen...

[StefanV]

Original geschrieben von Razor@Work
Und Du meinst nicht, dass dies mit der derzeitigen Optimierung auf ATI-Hardware zusammen hängt ?
???

Razor

Nö.

Die FX Serie hat einfach nur miese Shader...

[Razor@Work]

Original geschrieben von nggalai
Hi Razor,
In DEM Mass? Nein. Selbst wenn eine "Optimierung" auf GFFX 100% Geschwindigkeitszuwachs bringen würde (was kaum zu machen ist), wären die GFFX immernoch deutlich lahmer als die ATI-Produkte.

93,
-Sascha.rb
Soooo unrealistisch ist das gar nicht.

Da für nVidia das Cg-Profil genommen wurde, was gegenüber dem M$-Profil nochmal ein paar Prozentchen kostet, der NV35 wohl im NV30-Mode läuft und damit überhaupt keinen Nutzen aus der anders gelagerten Shader-Architektur zieht, dürfte das jetzige Scenario schlicht dem absoluten Worst-Case entsprechen, während bei ATI alles 'optimal' läuft.

So sollte man performance-seitig (natürlich rein spekulativ ;-) noch folgendes zur derzeitigen Situation hinzu rechnen:

1) Optimierung auf die generelle nVidia-Architektur
2) Nutzung der erweiterten Shader-Architektur beim NV35

und wie sehr eine falsche 'Optimierung' eine Auswirkung auf die Performance haben kann, konnte man ja ganz gut daran sehen, was passierte, als man die Cg (Standard) Shader auf der ATI-Karte laufen ließ. Die Performance sank (bei sonst gleichen Einstellungen) von 80 auf 50 fps. Bei nVidia von 36 auf 33 fps (zumindest bei mir, also knappe 10% Performance-Verlust bei nVidia und kanppe 40% Performance-Verlust bei ATI).

Was man also von der 'Qualität' der Cg-PS2.0-Shader halten kann, dürfte damit wohl offensichtlich sein.

-

Zumindest ist bei derzeitigem Stand bezogen auf TRAoD gut zu sehen, was passiert, wenn man diametral entgegengesetzt optimierten code ablaufen läßt. Derzeit liegt in diesem Falle schon mal generell die Hälfte der Shader-Performance des NV35 brach... von der restlichen Hälft wohl ebenfalls nocheinmal ein Großteil... wenn da nicht nochmal ordentlich was heraus zu holen ist, weiß ich es auch nicht.

Razor

[reunion]

Original geschrieben von Stefan Payne
Nö.

Die FX Serie hat einfach nur miese Shader...

:up: genau so siehts aus...

[Razor@Work]

Original geschrieben von Stefan Payne
Die FX Serie hat einfach nur miese Shader...
:lol:

[nggalai]

Hi Razor,
Original geschrieben von Razor@Work
Soooo unrealistisch ist das gar nicht.O.o :|

Eine echte VERDOPPELUNG der Shader-Performance in einer echten Applikation (nicht nur im Idealfall) ist für NICHT unrealistisch?

Da fehlen mir echt die Worte. Sorry. Reality Check? Woher sollen die 100% Mehrleistung queerbeet denn kommen? Wir wissen ja alle, dass sich NV gerne mit "Wundertreibern" brüstet, aber die letzten paar mal hat selbst das Marketing "nur" von 30% Mehrleistung gesprochen. Ich glaube, Du überschätzt die Cine-FX-Architektur ein wenig, oder glaubst, dass kleine Götter in der Treiberentwicklung sitzen.

93,
-Sascha.rb

[Exxtreme]

Razor,

Geschwindigkeitssteigerungen von über 200% nur durch Optimierung der Shader, halte ich für nicht realistisch.

Die R9800 Pro bricht bei Weitem nicht soviel ein wenn man das CG-Profil nutzt und dieses dieser auch nicht schmecken dürfte.

[Gast]

Original geschrieben von Razor@Work
Soooo unrealistisch ist das gar nicht.

Da für nVidia das Cg-Profil genommen wurde, was gegenüber dem M$-Profil nochmal ein paar Prozentchen kostet,

Cg war bei den Beyond3D-Tests schneller als M$; da Beyond3D die neuesten Game-Patches und auch die neuesten Cg-Compiler benutzt hat.
Lies dir einfach das neue FX5900-Review und den Artikel auf Beyond3D durch.

Außerdem das Spiel unter DX9 ein paar Renderfehler ( DOF soweit ich mich jetzt erinnere ) und die traten unter Cg nicht auf.

[Quasar]

Gehen wir einfach mal von nV35= 2xnV30 aus (im worst-case für den nV30. Wenn dies durch den neuen Treiber nutzbar gemacht würde (und die Shader sind rechenlastig, wie wir ja schon gesehen haben, wären wir bei glatten 100% Zuwachs (na gut, ein paar % müsste man dann noch für die nicht-rechenlastigen Shader abziehen, also ~85%?).

DAZU käme noch das optimierte Profil, welches von cg ja momentan nicht so erstellt werden soll...

Ich lass' mich gern überraschen, momentan sieht's allerdings so aus, als hätte kein nV Produkt ausser der FX5200 eine gute Basis gegen die ATi-Shader.

[reunion]

Original geschrieben von Quasar
Gehen wir einfach mal von nV35= 2xnV30 aus (im worst-case für den nV30. Wenn dies durch den neuen Treiber nutzbar gemacht würde (und die Shader sind rechenlastig, wie wir ja schon gesehen haben, wären wir bei glatten 100% Zuwachs (na gut, ein paar % müsste man dann noch für die nicht-rechenlastigen Shader abziehen, also ~85%?).


Da stellt sich natürlich als erstes die Frage warum NV die angeblich vorhandene zusätzliche Leistung nicht freigibt??? Es kann doch nicht sein das der NV35 angeblich doppelt so schnell Shader berechnen kann man aber nicht in der Lage ist diese auch nutzbar zu machen. Also meinermeinung nach ist da was gewaltig faul...

[micki]

weil man es nicht kann, das ist wie ein sportwagen für den du den sprit erstmal erstellen können mußt.

die müssen mit den treibern die shader optimieren, sodass sie optimal verarbeitet werden können und dann geht's ab.

MfG
micki

[Demirug]

Zum Thema Compiler:

Von STMicroelectronics die mit iheren DSPs ein ähnliches Problem haben.

However, the effectiveness of the VLIW approach depends critically on the corresponding compiler technology. A compiler is a software tool that converts a "high level" description of the computer program into the program code that is actually executed by the processor. Almost all application programs today are written in "high level languages", which allow the programming team to focus on what the application actually does rather than the details of how it will be implemented. The role of the compiler is to convert the sequence of high level instructions (typically written in programming languages such as C++) into the machine-specific instruction sequences that will be executed by the target processor.

A conventional compiler largely follows the flow of the high level description but a VLIW compiler must do much more than this. In principle, a VLIW architecture enables a higher level of ILP than would be practical otherwise but the potential benefit can only be realised if the compiler is smart enough to analyse the high level description of the program and extract from it groups of primitive instructions that can be executed in parallel in such a way that all of the parallel processing units are kept as busy as possible.

In effect, the VLIW approach shifts the complexity from the hardware to the compiler. This has the advantage that simplified hardware architectures both run faster and cost less to manufacture. On the other hand, VLIW compilers are considerably more complex to develop than traditional compilers and the difficulty of writing powerful VLIW compilers is increased by an order of magnitude if they are required to work across a wide variety of hardware architectures.

Das ist auch noch ganz interesant zu dem Thema: http://www.semiconductors.philips.com/acrobat/other/vliw-wp.pdf

sowie

http://graphics.stanford.edu/projects/shading/pubs/hwws2001-regcomb/

[Tigerchen]

Original geschrieben von reunion
Da stellt sich natürlich als erstes die Frage warum NV die angeblich vorhandene zusätzliche Leistung nicht freigibt??? Es kann doch nicht sein das der NV35 angeblich doppelt so schnell Shader berechnen kann man aber nicht in der Lage ist diese auch nutzbar zu machen. Also meinermeinung nach ist da was gewaltig faul...

Dieses ewige warten auf die Wundertreiber finde ich auch befremdlich.Erinnert mich irgendwie an das Savage 2000 Fiasko.Da wurde auch ewig auf neue Wundertreiber verwiesen und dann kam der Tag der Wahrheit....

[Razor@Work]

Original geschrieben von nggalai
Da fehlen mir echt die Worte. Sorry. Reality Check? Woher sollen die 100% Mehrleistung queerbeet denn kommen? Wir wissen ja alle, dass sich NV gerne mit "Wundertreibern" brüstet, aber die letzten paar mal hat selbst das Marketing "nur" von 30% Mehrleistung gesprochen. Ich glaube, Du überschätzt die Cine-FX-Architektur ein wenig, oder glaubst, dass kleine Götter in der Treiberentwicklung sitzen.
Deine Polemik in allen Ehren, nggalai, aber ich habe noch ein bissel mehr geschrieben, als nur diese eine Zeile...

Razor

[Razor@Work]

Original geschrieben von Exxtreme
Razor,

Geschwindigkeitssteigerungen von über 200% nur durch Optimierung der Shader, halte ich für nicht realistisch.

Die R9800 Pro bricht bei Weitem nicht soviel ein wenn man das CG-Profil nutzt und dieses dieser auch nicht schmecken dürfte.
In beiden Fällen (i.e. Cg oder M$) wird aber das Standard-Profil benutzt und nicht das 2.X bei Cg (was vermutlich 'eh nicht soviel bringt ;-), oder das 2.A bei M$. So bricht also die ATI schon kräftig ein, wenn einfach nur eine andere Form der Deklaration benutzt wird... hier kann man wirklich sehen, wie sehr der M$-Compiler derzeit auf die ATI-Hardware hin optimiert.

Razor

[Razor@Work]

Original geschrieben von Quasar
Gehen wir einfach mal von nV35= 2xnV30 aus (im worst-case für den nV30. Wenn dies durch den neuen Treiber nutzbar gemacht würde (und die Shader sind rechenlastig, wie wir ja schon gesehen haben, wären wir bei glatten 100% Zuwachs (na gut, ein paar % müsste man dann noch für die nicht-rechenlastigen Shader abziehen, also ~85%?).

DAZU käme noch das optimierte Profil, welches von cg ja momentan nicht so erstellt werden soll...
Danke, Quasar, dass Du dies nocheinmal präzisiert hast...
Irgendwie habe ich wohl ein Problem, mich auszudrücken.
Oder was auch immer...
;-)
Original geschrieben von Quasar
Ich lass' mich gern überraschen, momentan sieht's allerdings so aus, als hätte kein nV Produkt ausser der FX5200 eine gute Basis gegen die ATi-Shader.
Vermutlich meinst Du die FX5900, oder ?
:D

Razor

[Exxtreme]

Original geschrieben von Razor@Work
In beiden Fällen (i.e. Cg oder M$) wird aber das Standard-Profil benutzt und nicht das 2.X bei Cg (was vermutlich 'eh nicht soviel bringt ;-), oder das 2.A bei M$. So bricht also die ATI schon kräftig ein, wenn einfach nur eine andere Form der Deklaration benutzt wird... hier kann man wirklich sehen, wie sehr der M$-Compiler derzeit auf die ATI-Hardware hin optimiert.

Razor
Razor,

glaub mir bitte, daß 250%ige Geschwindigkeitssteigerungen nicht drin sind. Denn schliesslich macht der Shader auch nur einen kleinen Teil der 3D-Szene aus. Da gibt es auch noch Polygone, Texturen etc.

Um solche Steigerungen zu erzielen müsste ausschliesslich der Shader limitieren.

[Razor@Work]

Original geschrieben von reunion
Da stellt sich natürlich als erstes die Frage warum NV die angeblich vorhandene zusätzliche Leistung nicht freigibt??? Es kann doch nicht sein das der NV35 angeblich doppelt so schnell Shader berechnen kann man aber nicht in der Lage ist diese auch nutzbar zu machen. Also meinermeinung nach ist da was gewaltig faul...
Natürlich ist da was faul...

Die Treiber unterstützen diesen Teil der Architektur (weil noch viel zu neu) noch nicht richtig. Auch sind derzeit sämtliche Shader eher auf ATI-Hardware hin optimiert und es würde mich nicht wundern, wenn diese derzeit nur sequentiell und nicht parallel ausgeführt werden können. Da die Shader-Performance zumindest hier bei TRAoD bei NV30 und NV35 gleich sind, darf man beruhigt davon ausgehen, dass die Hälfte der Shader-Kapazität beim NV35 schlicht brach liegt.

Zukünftige Treiber werden das schon richten. Und ich hoffe inständig, dass dort dann auch eine Art Recompiler für PS2.0-Shader zum Einsatz kommt, der den ankommenden - einseitig optimierten - Code in einen etwas 'verträglicheren' Code für die eigene Architektur umsetzen kann. Und wenn dabei dann noch die erweitereten Möglichkeiten des NV35 berücksichtigt würde... wir weden sehen.

Momentan scheinen PS2.0-Programme auf den NV's in einer Art 'Kompatibilitäts-Modus' zu laufen. Für einigen Proggi's wird man per Tabellen-Lookup schon 'passende' Shader implementiert haben (wie z.Bsp. bei Murks03 ;-), für andere wohl aber nicht (definitiv wohl TRAoD).

Wie dem auch sei... wir werden sehen !
Ist doch schön, dass die ATI-Leutz wenigstens noch eine Sache haben, über die sie sich freuen können...
(ebenfalls polemisch gemeint ;-)

Razor

[Razor@Work]

Original geschrieben von Exxtreme
Razor,

glaub mir bitte, daß 250%ige Geschwindigkeitssteigerungen nicht drin sind. Denn schliesslich macht der Shader auch nur einen kleinen Teil der 3D-Szene aus. Da gibt es auch noch Polygone, Texturen etc.

Um solche Steigerungen zu erzielen müsste ausschliesslich der Shader limitieren.
Und Du glaubst nicht, dass dem so ist ?
???

Um es klar auszudrücken:

NIEMAND (also auch Du nicht ;-) kann derzeit sagen, wie es um tatsächlich um die Leistungsfähigkeit der nVidia-Shader bestellt ist. Derzeit läßt sich lediglich sagen, was passiert, wenn ATI-optimierte Shader ohne Veränderung auf nVidia-Hardware ausgeführt werden. Und wenn jetzt noch ins Kalkül zieht, dass es bei den Shadern wichtiger denn je ist, dass die Zielhardware unterstützt wird (siehe die vielen Aussagen unserer sehr kompetenten Leutz hier) und dies im Falle von nVidia noch gar nicht der Fall ist...

Aber was rede ich.
ATI-optimierte Shader laufen auf nVidia Hardware schlecht.
Ist nichts Neues und hinlänglich bekannt.

Dass nun jedes mal wieder davon Aufhebens gemacht wird, wenn etwas neues in dieser Richtung kommt...
Na ja, "wenn's schö macht" ?
;-)

Warten wir doch einfach ab.
NBiemand kann sagen, wie sich die eigentliche Performance entwickeln wird (egal, ob 10% oder 500%). Dazu müsste man einen realen Vergleich machen und nicht herum theoretisieren.

Fakt bleibt:
- die ATI-PS2.0-Shader laufen auf ATI-Hardware optimal
- die ATI-PS2.0-Shader laufen auf nVidia-Hardware richtig mies

Wie verwunderlich...
:D

Razor

[reunion]

Original geschrieben von Razor@Work
Natürlich ist da was faul...

Die Treiber unterstützen diesen Teil der Architektur (weil noch viel zu neu) noch nicht richtig. Auch sind derzeit sämtliche Shader eher auf ATI-Hardware hin optimiert und es würde mich nicht wundern, wenn diese derzeit nur sequentiell und nicht parallel ausgeführt werden können. Da die Shader-Performance zumindest hier bei TRAoD bei NV30 und NV35 gleich sind, darf man beruhigt davon ausgehen, dass die Hälfte der Shader-Kapazität beim NV35 schlicht brach liegt.


Die Karte ist jetzt 6 Monate verfügbar und NV ist immernochnicht in der Lage vernünftige Treiber zu liefern...
Also ich habe sowas noch nie erlebt das einen neue Karte herauskommt mit neue Features doch man mangels Treiber diese nicht nutzen kann.

Wie dem auch sei... wir werden sehen !
Ist doch schön, dass die ATI-Leutz wenigstens noch eine Sache haben, über die sie sich freuen können...
(ebenfalls polemisch gemeint ;-)

Razor

:up: Stimmt *freu*

[Quasar]

Original geschrieben von Razor@Work
Vermutlich meinst Du die FX5900, oder ?
:D

Razor

Nein, ich meinte wirklich die FX5200, da ich ja von der aktuellen Situation sprach und da muss man einfach konstatieren, dass mit den aktuell verfügbaren Shader-Programmen die Radeons einfach besser laufen.

Nur die R9200 hat so, ahem, ihre Probleme, DX9-Shader ausserhalb des DX9-SDK ablaufen zu lassen, wenn du verstehst. *eg*
Da hat nV in der Tat einen Vorteil... ;)

[Quasar]

Original geschrieben von reunion
Die Karte ist jetzt 6 Monate verfügbar und NV ist immernochnicht in der Lage vernünftige Treiber zu liefern...
Also ich habe sowas noch nie erlebt das einen neue Karte herauskommt mit neue Features doch man mangels Treiber diese nicht nutzen kann.


Ich könnt' dir da Sachen von um Weihnachten herum erzählen, was da so an kleinen Nettigkeiten mit der ATi (noch !!) nicht ging. ;)

[Exxtreme]

Original geschrieben von Razor@Work
Und Du glaubst nicht, dass dem so ist ?
???

Um es klar auszudrücken:

NIEMAND (also auch Du nicht ;-) kann derzeit sagen, wie es um tatsächlich um die Leistungsfähigkeit der nVidia-Shader bestellt ist. Derzeit läßt sich lediglich sagen, was passiert, wenn ATI-optimierte Shader ohne Veränderung auf nVidia-Hardware ausgeführt werden. Und wenn jetzt noch ins Kalkül zieht, dass es bei den Shadern wichtiger denn je ist, dass die Zielhardware unterstützt wird (siehe die vielen Aussagen unserer sehr kompetenten Leutz hier) und dies im Falle von nVidia noch gar nicht der Fall ist...

Aber was rede ich.
ATI-optimierte Shader laufen auf nVidia Hardware schlecht.
Ist nichts Neues und hinlänglich bekannt.

Dass nun jedes mal wieder davon Aufhebens gemacht wird, wenn etwas neues in dieser Richtung kommt...
Na ja, "wenn's schö macht" ?
;-)

Warten wir doch einfach ab.
NBiemand kann sagen, wie sich die eigentliche Performance entwickeln wird (egal, ob 10% oder 500%). Dazu müsste man einen realen Vergleich machen und nicht herum theoretisieren.

Fakt bleibt:
- die ATI-PS2.0-Shader laufen auf ATI-Hardware optimal
- die ATI-PS2.0-Shader laufen auf nVidia-Hardware richtig mies

Wie verwunderlich...
:D

Razor
Razor,

klar laufen ATi-optimierte Shader mies auf der GFFX-Architektur. Nur ist es wirklich sehr unwahrscheinlich, daß da 250% Geschwindigkeitssteigerung drin ist... nicht in echten Spielen. In theoretischen Tests kann man mit mir in diesem Punkt verhandeln. :D

Ausserdem dürfte Nvidia genauso lange lauffähiges Silizium von der GFFX haben wie ATi von der R300. Wenn sie nach fast 1,5 Jahren noch immer keine Treiber haben, die das ausgleichen können, dann weiss ich auch nicht mehr, sorry.

[Gast]

Original geschrieben von reunion
Die Karte ist jetzt 6 Monate verfügbar und NV ist immernochnicht in der Lage vernünftige Treiber zu liefern...
Also ich habe sowas noch nie erlebt das einen neue Karte herauskommt mit neue Features doch man mangels Treiber diese nicht nutzen kann.
Ist das was Neues ?
???

Selbst bei ATI konnte man zu Release nicht immer alle Features nutzen. Bei Erscheinen des R300 gab's noch nicht einmal DX9-Unterstützung (welches zu dem Zeitpunkt ja noch nicht einmal offiziell released war ;-)... was da wohl alles 'brach' lag.

Nur zur Erinnerung... auch ATI hat die eigene Hardware erst 6 Monate nach Release 'vernünftig' unterstützt (was auch immer dieses 'vernünftig bedeuten mag). Dort ist das allerdings die Regel...

Und inwiefern ist der NV35 schon 6 Monate verfügbar ?
Und welche Features kann man nicht nutzen ?
???

Razor

[Razor@Work]

Original geschrieben von Quasar
Nein, ich meinte wirklich die FX5200, da ich ja von der aktuellen Situation sprach und da muss man einfach konstatieren, dass mit den aktuell verfügbaren Shader-Programmen die Radeons einfach besser laufen.

Nur die R9200 hat so, ahem, ihre Probleme, DX9-Shader ausserhalb des DX9-SDK ablaufen zu lassen, wenn du verstehst. *eg*
Da hat nV in der Tat einen Vorteil... ;)
Oki doke.
Habe Dich vollständig falsch verstanden...
:bonk:

Razor

[Gast]

Original geschrieben von Exxtreme
klar laufen ATi-optimierte Shader mies auf der GFFX-Architektur. Nur ist es wirklich sehr unwahrscheinlich, daß da 250% Geschwindigkeitssteigerung drin ist... nicht in echten Spielen. In theoretischen Tests kann man mit mir in diesem Punkt verhandeln. :D
Verhandel ?
Auf welcher Basis ?
:D

Siehe vorherigen Post...
Original geschrieben von Exxtreme
Ausserdem dürfte Nvidia genauso lange lauffähiges Silizium von der GFFX haben wie ATi von der R300. Wenn sie nach fast 1,5 Jahren noch immer keine Treiber haben, die das ausgleichen können, dann weiss ich auch nicht mehr, sorry.
Nun laß mal gut sein...
Wie ich schon zu reunion schrieb:
Wo bitte hat ATI immer von Anfang an alles unterstützt ?

Und da DX9 ja wohl kurz vor Release noch 'mutierte' und auch keine Möglichkeit vorsah, andere Hardware - ausser die von ATI - vernünftig zu unterstützen, eine Beta-Version dann ohne Zustimmung der Beta-Tester recht 'überhastet' an den Markt gebracht wurde, hat nVidia jetzt halt den schwarzen Peter.

Sie werden wohl bestimmte Treiber-Konzeptionen umstellenund etwas in die Treiber einbauen müssen, welches diese 'Ungleichbehandlung', welche ja eigentlich komplett gegen das Konzept von DirectX läuft, eleimniert.
Und das wird seine Zeit brauchen...

Abwarten und Tee trinken.
Wenn ich warten kann, wirst Du das ja wohl auch noch hinbekommen, oder ?
:D

Razor

[StefanV]

Original geschrieben von Gast
Ist das was Neues ?
???

Selbst bei ATI konnte man zu Release nicht immer alle Features nutzen. Bei Erscheinen des R300 gab's noch nicht einmal DX9-Unterstützung (welches zu dem Zeitpunkt ja noch nicht einmal offiziell released war ;-)... was da wohl alles 'brach' lag.

Nur zur Erinnerung... auch ATI hat die eigene Hardware erst 6 Monate nach Release 'vernünftig' unterstützt (was auch immer dieses 'vernünftig bedeuten mag). Dort ist das allerdings die Regel...

Und inwiefern ist der NV35 schon 6 Monate verfügbar ?
Und welche Features kann man nicht nutzen ?
???

Razor

Ja und??

Ist das ATIs Versagen??

Siehst du, genau HIER liegt das Problem, die Radeon 9700PRO war weit vor DX9 verfügbar!!

ATI hatte alsod as Problem, daß sie eine sehr gute und Fortschrittliche Karte hatten, man aber nur die Hälfte der Features nutzen kann, da M$ gepennt hat.

WAS zur Hölle hätte ATI machen sollen??
Die R300 wegschmeißen und mitm nächsten Core weitermachen, weil M$ nicht nachgekommen ist??

Oder den R300 zurückhalten und warten bis DX9 verfügbar ist??

[Razor@Work]

Nun mal ruhig Blut, Steffi...
;-)

ATI hat ein Produkt gelauncht, welchem die Basis noch fehlte.
Inwieweit soll M$ daran die Schuld treffen ?

Oder was machen Beta-Test-Programme für einen Sinn, wenn es da gar nichts zu testen gibt ?
Und dass dann eine Beta-Version einfach zu einer Release-Version erhoben wurde, ohne die Aussagen der Beta-Test-Member abzuwarten, jetzt auch noch der XBox-Deal an ATI ging, spricht eine Sprache, bei der sehr tiefgreifende Spekulationen unabänderlich sind.

M$ trifft definitiv die Schuld, dass DX9 zu früh released wurde und gewissermaßen unvollständig war, da ja Shader-seitig lediglich eine einzige Hardware-Basis unterstützt wurde (was dem Sinn einer 'unabhängigen API' zuwieder läuft). nVidia muss dies jetzt ausbaden und sie täten gut daran, das möglichst bald zu tun.

Razor

[Legolas]

Original geschrieben von Razor@Work

M$ trifft definitiv die Schuld, dass DX9 zu früh released wurde und gewissermaßen unvollständig war, da ja Shader-seitig lediglich eine einzige Hardware-Basis unterstützt wurde (was dem Sinn einer 'unabhängigen API' zuwieder läuft). nVidia muss dies jetzt ausbaden und sie täten gut daran, das möglichst bald zu tun.

Razor

MS kann doch nix dafür, daß NV den NV30 nicht produktionsreif bekommen hat. Bei DX8 hat ja auch niemand auf ATI gewartet, sondern das Produkt von ATI wurde später mit DX8.1 unterstützt. Und die erweiterten Fähigkeiten der GFFX werden halt durch neue PS Profile unterstützt. Daß NV über ein halbes Jahr zu spät auf dem Markt war, und deswegen von den Softwareherstellern auf den schon verfügbaren R300 Core und dessen Fähigkeiten optimiert wurde, dafür kann weder MS noch ATI was. FAKT ist im Moment halt einfach, daß es keinen brauchbaren Shadercompiler für NV-Hardware gibt und ATI deswegen im Moment deutlich besser dasteht, was Shaderperformance angeht. DAS ist im Moment ganz einfach die nackte Realität, und wie wirst du auch mit rumlavieren und immer wieder neuem Verweis auf neue Wundertreiber nicht ändern können. Im Moment hat ATI bei der Pixelshaderperformance einfach die Nase vorne.

[Demirug]

Original geschrieben von Legolas
MS kann doch nix dafür, daß NV den NV30 nicht produktionsreif bekommen hat. Bei DX8 hat ja auch niemand auf ATI gewartet, sondern das Produkt von ATI wurde später mit DX8.1 unterstützt.

So war das wohl auch mal für DX9 geplannt. DX9 für R300 und DX 9.1 für alles was dann noch so kommt. Dann wurde aber plötzlich (zwischen Beta 1 und Beta 2) der ganze DX 9.1 kremple plötzlich zu DX 9 dazu geschlagen. Irgendjemand hat da also interveniert.

Und die erweiterten Fähigkeiten der GFFX werden halt durch neue PS Profile unterstützt. Daß NV über ein halbes Jahr zu spät auf dem Markt war, und deswegen von den Softwareherstellern auf den schon verfügbaren R300 Core und dessen Fähigkeiten optimiert wurde, dafür kann weder MS noch ATI was.

Im grossen und ganzen ACK. Es wäre allerdings ein netter Zug von MS gewesen wenn sie von Anfang an darauf hingewissen hätten das der Compiler Code erzeugt welcher nicht für alle Chips ideal ist (Das war MS sicherlich bekannt) und das es Chip spezifische Profile geben wird. Da sie es nicht getan haben sind nun einige Entwickler voll in diese (unbeabsichtigte ?) Falle gelaufen.

[Obligaron]

Ich möchte nochmal an einen Post von Demi erinnern:
Original geschrieben von Demirug
Ja genau so ist es. Die 2.A Shader laufen auf einem R300 gar nicht.
D.h. doch das der 2.A Compiler von MS rein für NV erstellt wurde und scheinbar nichts mit ATi zu tun hat. Deshalb kann der 2.A Compiler garnicht standard für alle sein, weil er nicht bei auf allen DX 9 Karten läuft.

Am besten währe es ja sowieso gewesen wenn ATi und NV ihre eigenen Compiler geschrieben hätten und diese in ihre Treiber integriert hätten. So währen alle bestmöglichst versorgt, währe zwar etwas rechenlastiger als vorcomplierte Shader(muss ja nicht in echtzeit compiliert werden), aber dafür hochoptimiert. Schlecht währe es vll für kleiner Hersteller aka XGI, die müssten dann ihren eigenen Compiler entwickeln oder den von MS verwenden.

Ansonsten kann man nur sagen das ATi vorher da war und deswegen wurden sie 'erstmal' als Referenz genommen. Vll hoffen die Entwickler ja auch das NV mit ihrem schönen Detonater 50.xx ihnen das optimieren der Shader auf NV Hardware abnimmt :D.

MfG,
Obligaron

[Demirug]

Original geschrieben von Obligaron
Ich möchte nochmal an einen Post von Demi erinnern:

D.h. doch das der 2.A Compiler von MS rein für NV erstellt wurde und scheinbar nichts mit ATi zu tun hat. Deshalb kann der 2.A Compiler garnicht standard für alle sein, weil er nicht bei auf allen DX 9 Karten läuft.

Moment. Bevor ich hier wieder aus dem Zusammenhang gerissen zitiert werden. Es gibt keinen 2.A Compiler sondern nur einen Compiler der unterschiedliche Zielprofile hat. 2.A ist dabei ein 2.X Zielprofil. Da man aber bei 2.X immer eine ganze Menge zusätzlicher einstellungen übergeben muss hat nun MS die richtigen Einstellungen für NV3X Chips im Compiler hinterlegt und über das Profil 2.A zugänglich gemacht. 2.A ist primär also sowas wie ein Makro. Solche Makros sollen auch für andere Chips hinterlegt werden. Ein richtiges standard Compiler Profil gibt es im SDK ja leider nicht weil es nicht möglich scheint einen Shader so zu komplieren das er es jeder Hardware recht macht.

Am besten währe es ja sowieso gewesen wenn ATi und NV ihre eigenen Compiler geschrieben hätten und diese in ihre Treiber integriert hätten. So währen alle bestmöglichst versorgt, währe zwar etwas rechenlastiger als vorcomplierte Shader(muss ja nicht in echtzeit compiliert werden), aber dafür hochoptimiert. Schlecht währe es vll für kleiner Hersteller aka XGI, die müssten dann ihren eigenen Compiler entwickeln oder den von MS verwenden.

Das ganze hätte durchaus noch andere Gefahren. Wenn man es erlaubt über eine solche Schnittstelle ungeprüften Klartext bis direkt in den Treiber laufen zu lassen könnte die IHVs sehr schnell anfangen diese Schnittstelle für eigene Zwecke zu missbrauchen zudem wird es dann fast unmöglich einen minimalen Techlevel was Shader angeht vorzuschreiben.

Ansonsten kann man nur sagen das ATi vorher da war und deswegen wurden sie 'erstmal' als Referenz genommen. Vll hoffen die Entwickler ja auch das NV mit ihrem schönen Detonater 50.xx ihnen das optimieren der Shader auf NV Hardware abnimmt :D.

MfG,
Obligaron

Das bleibt abzuwarten. IMHO dürfte aber selbst dann ein entsprechend Compilierter Shader immer noch etwas schneller sein.

[Legolas]

Original geschrieben von Demirug
Es wäre allerdings ein netter Zug von MS gewesen wenn sie von Anfang an darauf hingewissen hätten das der Compiler Code erzeugt welcher nicht für alle Chips ideal ist (Das war MS sicherlich bekannt) und das es Chip spezifische Profile geben wird. Da sie es nicht getan haben sind nun einige Entwickler voll in diese (unbeabsichtigte ?) Falle gelaufen.

Das war vielleicht nicht nett von MS, aber imho sollte ein Entwickler schon die Performance seines Werkes auf mehr als nur einem Hardwaretypus testen, bevor er das Produkt dann auf den Markt bringt.

[Razor@Work]

Original geschrieben von Legolas
MS kann doch nix dafür, daß NV den NV30 nicht produktionsreif bekommen hat. Bei DX8 hat ja auch niemand auf ATI gewartet, sondern das Produkt von ATI wurde später mit DX8.1 unterstützt. Und die erweiterten Fähigkeiten der GFFX werden halt durch neue PS Profile unterstützt. Daß NV über ein halbes Jahr zu spät auf dem Markt war, und deswegen von den Softwareherstellern auf den schon verfügbaren R300 Core und dessen Fähigkeiten optimiert wurde, dafür kann weder MS noch ATI was. FAKT ist im Moment halt einfach, daß es keinen brauchbaren Shadercompiler für NV-Hardware gibt und ATI deswegen im Moment deutlich besser dasteht, was Shaderperformance angeht. DAS ist im Moment ganz einfach die nackte Realität, und wie wirst du auch mit rumlavieren und immer wieder neuem Verweis auf neue Wundertreiber nicht ändern können. Im Moment hat ATI bei der Pixelshaderperformance einfach die Nase vorne.
Ähm... ja. Und ?

"Fakt bleibt:
- die ATI-PS2.0-Shader laufen auf ATI-Hardware optimal
- die ATI-PS2.0-Shader laufen auf nVidia-Hardware richtig mies"

Nichts anderes habe ich behauptet.
Und Dir kommt es nicht merkwürdig vor, dass eine Beta-Version zum Release wurde, ohne dass der Beta-Lauf abgeschlossen war ?
???

Mir schon...
Und das jetzige XBox-Abkommen setzt dem Ganzen dann noch die Krone auf.

Razor

[Demirug]

Original geschrieben von Legolas
Das war vielleicht nicht nett von MS, aber imho sollte ein Entwickler schon die Performance seines Werkes auf mehr als nur einem Hardwaretypus testen, bevor er das Produkt dann auf den Markt bringt.

Das Problem ist eher ein dadurch möglicherweise entstandenes Designproblem. MS hat den Eindruck vermittelt das man seinen Hochsprachenshader compiliert und dann ist gut. Da das compilieren ein Vorgang ist der Zeit kostet ist man dazu geneigt dieses nicht bei jedem Programmstart zu machen sondern nur einmalig und dann nur den fertig complierten Shader zu laden und zu benutzten. Hat man seine Engine nun auf diese Vorgehensweise ausgelegt hat man ein leichtes Problem weil man sie dann verändern muss damit sie der tatsächlichen Situation besser angemessen ist. Ändern = Zeit = Geld

[Demirug]

Original geschrieben von Razor@Work
Ähm... ja. Und ?

"Fakt bleibt:
- die ATI-PS2.0-Shader laufen auf ATI-Hardware optimal
- die ATI-PS2.0-Shader laufen auf nVidia-Hardware richtig mies"

Nichts anderes habe ich behauptet.
Und Dir kommt es nicht merkwürdig vor, dass eine Beta-Version zum Release wurde, ohne dass der Beta-Lauf abgeschlossen war ?
???

Mir schon...
Und das jetzige XBox-Abkommen setzt dem Ganzen dann noch die Krone auf.

Razor

Razor es war ein Realease Canidate der relative schnell zum Release gemacht wurde. Für das ursprüngliche DX 9 war dieser wohl auch wirklich Featurekomplett aber für das was ich als den DX 9.1 teil bezeichne fehlen ja heute noch Teile.

[Legolas]

Original geschrieben von Razor@Work
Ähm... ja. Und ?

"Fakt bleibt:
- die ATI-PS2.0-Shader laufen auf ATI-Hardware optimal
- die ATI-PS2.0-Shader laufen auf nVidia-Hardware richtig mies"


Fakt bleibt aber genauso, daß es bis zum heutigen Tage noch keinen Compiler gibt, der Shader für NV3x passend compiliert. Also bleibt ATI weiterhin in der Praxis im Vorteil, bis es einen Compiler bzw. ein Compilerprofil gibt, daß NV3x-Hardware angemessen ausnutzt.

[Legolas]

Original geschrieben von Demirug
Das Problem ist eher ein dadurch möglicherweise entstandenes Designproblem. MS hat den Eindruck vermittelt das man seinen Hochsprachenshader compiliert und dann ist gut. Da das compilieren ein Vorgang ist der Zeit kostet ist man dazu geneigt dieses nicht bei jedem Programmstart zu machen sondern nur einmalig und dann nur den fertig complierten Shader zu laden und zu benutzten. Hat man seine Engine nun auf diese Vorgehensweise ausgelegt hat man ein leichtes Problem weil man sie dann verändern muss damit sie der tatsächlichen Situation besser angemessen ist. Ändern = Zeit = Geld

Naja, wenn das so ist... Du musst es ja wissen. :)

[Demirug]

Original geschrieben von Legolas
Fakt bleibt aber genauso, daß es bis zum heutigen Tage noch keinen Compiler gibt, der Shader für NV3x passend compiliert. Also bleibt ATI weiterhin in der Praxis im Vorteil, bis es einen Compiler bzw. ein Compilerprofil gibt, daß NV3x-Hardware angemessen ausnutzt.

Und selbst dann braucht nVidia noch einen Treiber welcher die ganze Arbeit auf die unmengen von FP-Einheiten verteilt. In dieser Beziehung hat sich nVidia einen echten Horrorchip gebaut. Langsam glaube ich das die einen iherer Cluster im Moment nur dazu benutzten Shader nach der Brute-Force Methode zu optimieren und einen zweiten Cluster um allgemeine Regeln für einen automatischen Compiler zu finden. Ich sagte ja mal das NV3X eine VLIW Architektur hat das stimmt zwar aber trift es nicht ganz weil eine normale VLIW CPU dagegen noch harmlos ist.

[Gast]

Fakt bleibt:
- die ATI-PS2.0-Shader laufen auf ATI-Hardware optimal
- die ATI-PS2.0-Shader laufen auf nVidia-Hardware richtig mies"


:zzz:
Von dir hört man auch immer nur die selbe Leier.
.... auf ATI optimiert.
.... PS 1.4 hat keine Daseinsberechtigung da die meissten sachen auch mit 1.1 funktionieren wuerden.

Sorry aber wie kann man nur so verbort sein.

[Razor@Work]

Original geschrieben von Legolas
Fakt bleibt aber genauso, daß es bis zum heutigen Tage noch keinen Compiler gibt, der Shader für NV3x passend compiliert. Also bleibt ATI weiterhin in der Praxis im Vorteil, bis es einen Compiler bzw. ein Compilerprofil gibt, daß NV3x-Hardware angemessen ausnutzt.
Du hast ja auch (bedingt ;-) recht...
Derzeit ist ATI praktisch (bei den PS2.0-Shadern) im Vorteil.
Und diesen Compiler gibt es doch schon im M$-SDK... nur ist er eben (noch) nicht offiziell.

Aber es bleibt nVidia trotzdem nichts anderes übrig, als den Worst-Case (ATI-optimierte Shader) mit Ihren Treibern abzufangen und diese so 'umzubauen', dass sie zumindest halbwegs vernünftig auf der eigenen Hardware laufen. Und mir als Endanwender muss es letztlich egal sein, ob dies über im Treiber hinterlegte Shader passiert (derzeit in den 4x-Detos), oder über eine unverselle Lösung (hoffentlich in den 5x-Detos ;-).

Ich vermute mal, dass es eine Kombination daraus wird und ich bin wirklich gespannt, was das bringt.

Razor

[Gast]

Original geschrieben von Gast
:zzz:
Von dir hört man auch immer nur die selbe Leier.
.... auf ATI optimiert.
.... PS 1.4 hat keine Daseinsberechtigung da die meissten sachen auch mit 1.1 funktionieren wuerden.

Sorry aber wie kann man nur so verbort sein.
Und isch werde es auch weiterhin von mir geben, bis es auch der letzte begriffen hat.
Ich persönlich kann ganz gut damit leben...
:D

Razor

[Razor@Work]

Original geschrieben von Demirug
Razor es war ein Realease Canidate der relative schnell zum Release gemacht wurde. Für das ursprüngliche DX 9 war dieser wohl auch wirklich Featurekomplett aber für das was ich als den DX 9.1 teil bezeichne fehlen ja heute noch Teile.
Thx Demirug !
Dieser Teil war mir entfallen...
;-)

Ja klar, ein RC für das ursprüngliche DX9.
Werde mich zukünftig ein wenig präziser ausdrücken...

Razor

[Obligaron]

Original geschrieben von Demirug
Moment. Bevor ich hier wieder aus dem Zusammenhang gerissen zitiert werden. Es gibt keinen 2.A Compiler sondern nur einen Compiler der unterschiedliche Zielprofile hat. 2.A ist dabei ein 2.X Zielprofil. Da man aber bei 2.X immer eine ganze Menge zusätzlicher einstellungen übergeben muss hat nun MS die richtigen Einstellungen für NV3X Chips im Compiler hinterlegt und über das Profil 2.A zugänglich gemacht. 2.A ist primär also sowas wie ein Makro. Solche Makros sollen auch für andere Chips hinterlegt werden. Ein richtiges standard Compiler Profil gibt es im SDK ja leider nicht weil es nicht möglich scheint einen Shader so zu komplieren das er es jeder Hardware recht macht.
Da sollte ich das nächste mal etwas besser aufpassen :).


Original geschrieben von Gast
:zzz:
Von dir hört man auch immer nur die selbe Leier.
.... auf ATI optimiert.
.... PS 1.4 hat keine Daseinsberechtigung da die meissten sachen auch mit 1.1 funktionieren wuerden.

Sorry aber wie kann man nur so verbort sein.

Tja und ihm wird immer wieder das selbe geantwortet :D.
"auf ATi optimiert" - ATi war zuerst da/fertig und deshalb haben alle ATi konforme Shader programmiert. Das ganze spielchen gab es ja auch schon umgedreht, da muss sich halt der anpassen der später mit seiner Lösung kommt und da ist NV ja auch kräftig dabei :).

".... PS 1.4 hat keine Daseinsberechtigung da die meissten sachen auch mit 1.1 funktionieren wuerden." - Naja ich will mich (hoffentlich) kurz äusern, das gabs ja schon häufig genug: Sofern ein Effekt auf 1.4 genauso leicht programmierbar ist und genauso gut funktioniert wie auf 2.0er Shadern (egal ob jetzt Performance gewinn oder ein schönerer Effekt), warum soll man dann nicht 1.4er Shader verwenden? Weil von der reinen Logik her müsste man schon denken das 1.4er Shader nicht langsamer sein können als 2.0er Shader.

MfG,
Obligaron

[Obligaron]

Original geschrieben von Demirug
Das ganze hätte durchaus noch andere Gefahren. Wenn man es erlaubt über eine solche Schnittstelle ungeprüften Klartext bis direkt in den Treiber laufen zu lassen könnte die IHVs sehr schnell anfangen diese Schnittstelle für eigene Zwecke zu missbrauchen zudem wird es dann fast unmöglich einen minimalen Techlevel was Shader angeht vorzuschreiben.
NV hat doch aber bereits ihren eigenen Compiler und sie wollen ja beim Deto 50.xx auch bereits compilierte Shader recompilieren um bessere Shader für die FX Karten zu gewinnen, ist das nicht ein ähnlicher Effekt wie das jeder gleich seine eigenen Compiler schreibt? Ausserdem solange sich alle an die hochsprache halten und keiner für sich spezifischen Funktionen einbaut ist man doch immernoch auf einem einheitlichen Techlevel.
Oder vergess ich irgendwas???

[Exxtreme]

Original geschrieben von Obligaron
NV hat doch aber bereits ihren eigenen Compiler und sie wollen ja beim Deto 50.xx auch bereits compilierte Shader recompilieren um bessere Shader für die FX Karten zu gewinnen, ist das nicht ein ähnlicher Effekt wie das jeder gleich seine eigenen Compiler schreibt? Ausserdem solange sich alle an die hochsprache halten und keiner für sich spezifischen Funktionen einbaut ist man doch immernoch auf einem einheitlichen Techlevel.
Oder vergess ich irgendwas???
Also wenn sich jeder an die Hochsprache hält, dann ist das meist kein Problem. Je "höher" die Sprache ist, desto besser die Optimierungsmöglichkeiten.

Aber Lowlevel-Code zu optimieren ist viel schwieriger. Was man machen kann, ist die Reihenfolge der Anweisungen etwas ändern. Mehr ist nicht wirklich drin.

[Demirug]

Original geschrieben von Obligaron
NV hat doch aber bereits ihren eigenen Compiler und sie wollen ja beim Deto 50.xx auch bereits compilierte Shader recompilieren um bessere Shader für die FX Karten zu gewinnen, ist das nicht ein ähnlicher Effekt wie das jeder gleich seine eigenen Compiler schreibt? Ausserdem solange sich alle an die hochsprache halten und keiner für sich spezifischen Funktionen einbaut ist man doch immernoch auf einem einheitlichen Techlevel.
Oder vergess ich irgendwas???

Der eigene Compiler macht aber nichts anderes als die gleiche Hochsprache in die gleiche Assemblersprache zu übersetzten. Dabei wird lediglich eine andere Verwendung von Registern und Code Rheienfolge angestrebt.

Man kann bei einer Hochsprache zwar die Syntax normen aber wie soll man zum Beispiel festlegen das eine Karte einen shader einer bestimten länge ausführen können muss? Aus der Länge des Sourcecodes kann man schwer ableiten wie viele Anweisungen dieser Shader am ende haben wird. Und so geht es eben weiter. Eine Assemblersprache lässt sich das besser formalisieren und überprüfen.

[Obligaron]

Original geschrieben von Exxtreme
Also wenn sich jeder an die Hochsprache hält, dann ist das meist kein Problem. Je "höher" die Sprache ist, desto besser die Optimierungsmöglichkeiten.

Aber Lowlevel-Code zu optimieren ist viel schwieriger. Was man machen kann, ist die Reihenfolge der Anweisungen etwas ändern. Mehr ist nicht wirklich drin.

Mir ist schon bewusst das das optimieren von Lowlevel-Code um einiges schwieriger ist, als der von einer Hochsparche :D.


Original geschrieben von Demirug
Der eigene Compiler macht aber nichts anderes als die gleiche Hochsprache in die gleiche Assemblersprache zu übersetzten. Dabei wird lediglich eine andere Verwendung von Registern und Code Rheienfolge angestrebt.

Man kann bei einer Hochsprache zwar die Syntax normen aber wie soll man zum Beispiel festlegen das eine Karte einen shader einer bestimten länge ausführen können muss? Aus der Länge des Sourcecodes kann man schwer ableiten wie viele Anweisungen dieser Shader am ende haben wird. Und so geht es eben weiter. Eine Assemblersprache lässt sich das besser formalisieren und überprüfen.

Hmmm... wenn man jetzt z.B. die Anforderungen an eine DX 9 Karte soweit beibehält wie begehabt. Aber den Source in einer Hochsprache vorliegen hat und jeder Hersteller dann selbst dies in Assembler übersetzen lassen und dies dann auch möglichst weit optimiert, das Ergebnis währe das selbe, aber halt jeweilig optimiert (sofern möglich und abhänig davon wie leistungsfähig der Compilier ist).

Btw: Funktioniert nicht cg so ähnlich? Erzeugt ja _theoretisch_ auch optimierten Code für bestimmte GraKa's in Echtzeit.

MfG,
OBligaron

[Demirug]

Original geschrieben von Obligaron
Hmmm... wenn man jetzt z.B. die Anforderungen an eine DX 9 Karte soweit beibehält wie begehabt. Aber den Source in einer Hochsprache vorliegen hat und jeder Hersteller dann selbst dies in Assembler übersetzen lassen und dies dann auch möglichst weit optimiert, das Ergebnis währe das selbe, aber halt jeweilig optimiert (sofern möglich und abhänig davon wie leistungsfähig der Compilier ist).

Btw: Funktioniert nicht cg so ähnlich? Erzeugt ja _theoretisch_ auch optimierten Code für bestimmte GraKa's in Echtzeit.

MfG,
OBligaron

Was macht man aber wenn zum Beispiel zwei Karten die Forderungen bezüglich der Shaderlänge erfüllen aber die einen Karte einen etwas besseren Compiler hat und das Limit einhalten kann die andere aus dem gleichen Sourcecode aber internen Code erzeugt der etwas zu lang ist?

Cg erzeugt DX9-Assemblercode welcher für NV3X Chips optimiert ist.

[Obligaron]

Original geschrieben von Demirug
Was macht man aber wenn zum Beispiel zwei Karten die Forderungen bezüglich der Shaderlänge erfüllen aber die einen Karte einen etwas besseren Compiler hat und das Limit einhalten kann die andere aus dem gleichen Sourcecode aber internen Code erzeugt der etwas zu lang ist?
Dann soll als Referenz der MS Compiler hergenommen werden oder ist das heute anders? Und die Karten die besseren Assemblercode erzeugen sind dafür halt einfach schneller.

Original geschrieben von Demirug Cg erzeugt DX9-Assemblercode welcher für NV3X Chips optimiert ist.
Ja soweit schon klar. Aber man soll ja auch Profile für andere Grafikkarten einfügen können (was die anderen, in dem Fall ATi, natürlich nicht machen, weil es ja nicht von MS ist bzw. nichts offizieles).

MfG,
Obligaron

[ScottManDeath]

Original geschrieben von Demirug
Was macht man aber wenn zum Beispiel zwei Karten die Forderungen bezüglich der Shaderlänge erfüllen aber die einen Karte einen etwas besseren Compiler hat und das Limit einhalten kann die andere aus dem gleichen Sourcecode aber internen Code erzeugt der etwas zu lang ist?

Cg erzeugt DX9-Assemblercode welcher für NV3X Chips optimiert ist.



nichts, einfach auf einen aktuellen treiber warten. unter den ARB_{vertex | fragment}_program extensions ist das so gelöst (dort gibts ja auch unterschiedliche limits für native und api ressourcen):

(20) Should implementations be required to support all programs that
fit within the exported limits on the number of resources (e.g.,
instructions, temporaries) that can be present in a program, even if
it means falling back to software? Should implementations be
required to reject programs that could never be accelerated?

RESOLVED: No and no. An implementation is allowed to fail
ProgramStringARB due to the program exceeding native resources.
Note that this failure must be invariant with respect to all other
OpenGL state. In other words, a program cannot succeed to load
with default state, but then fail to load when certain GL state
is altered. However, an implementation is not required to fail
when a program would exceed native resources, and is in fact
encouraged to fallback to a software path. See issue 21 for a way
of determining if this has happened.

This notable departure from ARB_vertex_program was made as an
accommodation to vendors who could not justify implementing a
software fallback path which would be relatively slow even
compared to an ARB_vertex_program software fallback path.

Two issues with this decision:
1. The API limits become hints, and one can no longer tell by
visual inspection whether or not a program will load on
every implementation.
2. Program loading will now depend on the optimizer, which may
vary from release to release of an implementation. A
program that succeeded to load when an ISV first wrote it
may fail to load in a future driver version, and vice versa.

[Demirug]

Original geschrieben von Obligaron
Dann soll als Referenz der MS Compiler hergenommen werden oder ist das heute anders? Und die Karten die besseren Assemblercode erzeugen sind dafür halt einfach schneller.

Ja aber im Moment gibt es auch eine Schnittstelle zum Treiber über die Shaderassemblercode übertragen wird und da ist genau festgelegt was gehen muss.

Ja soweit schon klar. Aber man soll ja auch Profile für andere Grafikkarten einfügen können (was die anderen, in dem Fall ATi, natürlich nicht machen, weil es ja nicht von MS ist bzw. nichts offizieles).

MfG,
Obligaron

Das ist aber nicht nVidias schuld das ATI kein Profil schreiben will. Ich kann ATI da natürlich verstehen.

[Demirug]

Original geschrieben von ScottManDeath
nichts, einfach auf einen aktuellen treiber warten. unter den ARB_{vertex | fragment}_program extensions ist das so gelöst (dort gibts ja auch unterschiedliche limits für native und api ressourcen):

Du weist aber schon das ARB_{vertex | fragment}_program eine DX ähnliche Assembler Shadersprache benutzt?

Und mit verlaub es ist einfach unbrauchbar wenn man nicht vorher sagen kann ob ein Shader nun auf allen Karten die zu einer Generation gehören laufen wird oder nicht weil man dann nur noch auf Verdacht fallbacks programmiert. Wenn ich einen HLSL Shader habe den der MS-Compiler zu einem PS 2.0 compilieren kann dann ist sichergestellt das dieser Shader am ende auf jeder Karte die sich als DX9 Karte schimpft auch laufen muss und die IHVs haben keine ausrede. Natürlich kann man versuchen mit anderen Profilen den Shader besser auf eine Hardware anzupassen aber wenn das Fehl schlägt geht man eben auf den sicheren Shader zurück der par definition laufen muss.

Was MS machen sollte ist eine Möglichkeit vorsehen den normalen HLSL-Compiler durch einen Herstellerspezifsichen auszutauschen (welcher dann Teil des Treiberpackets sein kann) welcher dann beim Compileren den ersten versuch erhält und wenn dieser es nicht schaft wird eben wieder der normale MS-Compiler benutzt.

[Obligaron]

Original geschrieben von Demirug
Ja aber im Moment gibt es auch eine Schnittstelle zum Treiber über die Shaderassemblercode übertragen wird und da ist genau festgelegt was gehen muss.
Dann scheint die diese Schnittstelle das Maß aller Dinge zu sein.
Ich fass mal zusammen: Der Entwickler programmiert in der Hochsprache einen Shader für DX 9, dann gibt er diesen Quelltext an den Treiber weiter, dieser compiliert ihn und führt ihn somit optimiert für die Karte aus. Sofern kein Compiler vorliegt wird der MS Compiler verwendet. Das Resultat aller verschiedenen Compiler muss aber mit den festgeleten Shaderassmblerschnittstelle übereinstimmen zurechtkommen. Also an sich nichts anderes als ein integriertes CG in DX, dass je nach Profil(in dem Fall Treiber) den Hochsprachen Shader übersetzt.

Original geschrieben von Demirug
Das ist aber nicht nVidias schuld das ATI kein Profil schreiben will. Ich kann ATI da natürlich verstehen.
Ja ich glaub da verstehen wir alle ATI.

MfG,
Obligaron

[ScottManDeath]

Original geschrieben von Demirug
Du weist aber schon das ARB_{vertex | fragment}_program eine DX ähnliche Assembler Shadersprache benutzt?


jupp das ist klar. ich wollte nur als beispiel geben dass man durchaus (in diesem falle für eine pseudo assembler sprache) die lauffähigkeit vom treiber(compiler) (und nicht nur von der hw) abhängig machen kann

IRC ist für glslang es dem treiber erlaubt einzelne shader wegzuwerfen wenn sie gewisse ressourcenlimits überschreiten,oder aber auf sw umzuschalten. man bekommt aber über die api heraus ob der shader "native" läuft.

so kann man aber z.b. solange shader testen (zur laufzeit) bis man einen gefunden hat, der "native" läuft. während der entwicklung weiss man ja die tech-level und kann dann entsprechende shader schreiben die auf den entsprecjenden karten laufen

[Demirug]

Original geschrieben von Obligaron
Dann scheint die diese Schnittstelle das Maß aller Dinge zu sein.
Ich fass mal zusammen: Der Entwickler programmiert in der Hochsprache einen Shader für DX 9, dann gibt er diesen Quelltext an den Treiber weiter, dieser compiliert ihn und führt ihn somit optimiert für die Karte aus. Sofern kein Compiler vorliegt wird der MS Compiler verwendet. Das Resultat aller verschiedenen Compiler muss aber mit den festgeleten Shaderassmblerschnittstelle übereinstimmen zurechtkommen. Also an sich nichts anderes als ein integriertes CG in DX, dass je nach Profil(in dem Fall Treiber) den Hochsprachen Shader übersetzt.

Ja das wäre wohl die beste Lösung. Nur ist es derzeit leider nicht so.

[Demirug]

Original geschrieben von ScottManDeath
jupp das ist klar. ich wollte nur als beispiel geben dass man durchaus (in diesem falle für eine pseudo assembler sprache) die lauffähigkeit vom treiber(compiler) (und nicht nur von der hw) abhängig machen kann

IRC ist für glslang es dem treiber erlaubt einzelne shader wegzuwerfen wenn sie gewisse ressourcenlimits überschreiten,oder aber auf sw umzuschalten. man bekommt aber über die api heraus ob der shader "native" läuft.

Ja es gibt dann eine Performance Warnung.

so kann man aber z.b. solange shader testen (zur laufzeit) bis man einen gefunden hat, der "native" läuft. während der entwicklung weiss man ja die tech-level und kann dann entsprechende shader schreiben die auf den entsprecjenden karten laufen

Und genau hier habe ich ein ganz grosses Problem. Wenn ich in meinem Rechner eine Karte X habe gibt es keine Möglichkeit festzustellen ob sich ein Shader auch für Karte Y oder Z native umsetzten lässt. Ich muss mir also entweder viele Rechner mit unterschiedlicher Hardware hinstellen oder ständig Karten umbauen was letzten Endes beides Geld kostet. Und was ist mit Hardware die es noch gar nicht gibt?

Ich brauche definierte Levels auf die ich einen Hersteller auch festnageln kann und die gibt mir OpenGL 1.5 einfach nicht. Theoretisch ist OpenGL 1.5 es die bessere Lösung aber praktisch gibt es da leider noch ein paar Probleme.

Aber das ist jetzt alles ziemlich OT.

[zeckensack]

Richtig.
Du kannst die IHVs auf ARB_fragment_program festnageln, wenn du willst.(14) What should the minimum resource limits be?

RESOLVED: 10 attributes, 24 parameters, 4 texture indirections,
48 ALU instructions, 24 texture instructions, and 16 temporaries.
Mehr geht derzeit nicht ?-)
Man beachte: es handelt sich hierbei quasi um ein "kleines PS2.0" ?-)

[Demirug]

Original geschrieben von zeckensack
Richtig.
Du kannst die IHVs auf ARB_fragment_program festnageln, wenn du willst.
Mehr geht derzeit nicht ?-)
Man beachte: es handelt sich hierbei quasi um ein "kleines PS2.0" ?-)

Es ging mir bei dem Festnagel um OpenGL 1.5. Das ARB_fragment_program wie die Pixelshader bei DX sehr genau festgelegt ist war mir schon bekannt.

[Xmas]

Wobei es sich mir wirklich nicht erschließt wieso ARB_fragment_program geringere Limits als PS2.0 hat. Als ob irgendjemand auf die Idee kommen könnte einen Chip zu bauen, der ARB_fragment_program, aber nicht PS2.0 unterstützt... :|

[Demirug]

Original geschrieben von Xmas
Wobei es sich mir wirklich nicht erschließt wieso ARB_fragment_program geringere Limits als PS2.0 hat. Als ob irgendjemand auf die Idee kommen könnte einen Chip zu bauen, der ARB_fragment_program, aber nicht PS2.0 unterstützt... :|

sag das mal ATI

ARB_fragment_program unterstützt Dinge welche ATI nicht 1:1 abbilden kann und mehr als einen Takt/Befehl brauchen. Gerade beim swizzle ist das teilweise extrem.

[Xmas]

Original geschrieben von Demirug
sag das mal ATI

ARB_fragment_program unterstützt Dinge welche ATI nicht 1:1 abbilden kann und mehr als einen Takt/Befehl brauchen. Gerade beim swizzle ist das teilweise extrem.
Ach ja, ich vergaß. Im Prinzip kann man sich also nicht mal der 48 Arithmetik-Instruktionen sicher sein.

[Dunkeltier]

Original geschrieben von Demirug
Der MS-Compiler macht kürzer 2.0 Shader die viele Tempvariablen benutzen und nach ATI-Norm sortiert sind. Und der neue kann auch noch 2.A Shader die kaum Tempvariablen benutzen nach nVidia Norm sortiert und noch kürzer sind.


Müssen die Spielehersteller bei der Programmierung beides berücksichtigen oder kommt dann automatisch der richtige Shader (2.0, 2.A) zum Einsatz?

[Demirug]

Original geschrieben von Dunkeltier
Müssen die Spielehersteller bei der Programmierung beides berücksichtigen oder kommt dann automatisch der richtige Shader (2.0, 2.A) zum Einsatz?

Man muss dem Compiler schon sagen ob man nun 2.0 oder 2.A als Profil benutzen möchte. Allerdings kann jeder Shader welcher sich mit 2.0 compilieren lässt auch mit 2.A compilieren. Anders herum geht es nicht immer. Der Aufwand hält sich jedenfalls sehr in Grenzen. Es sind nur ein paar Zeilen Code notwendig.