NV30 Shader (Split aus: Mehr Leistung beim R350 nur durch Treiber?)

[Demirug]

Originally posted by ShadowXX
So wie ich es auf der Erklärungsgrafik dazu gesehen habe (war glaube ich bei hartware.de) ist dem nicht so, aber genaues weiss wohl keiner.

Was mir allerdings wirklich auf den Senkel geht, ist das viele, die sich die fx (unsere Grafikprogrammierer auf 3DCenter) nur wegen der längeren shader kaufen wollten, auf einmal meinen das die "unbegrenzten" Shader der r350 kein tolles Argument zum Kaufen sind.

J.S.Shadow

Moment. Ich sagte immer nur das die FX wegen der Shader für micht interesanter ist. Shader schliesst hier alles und nicht nur die Länge ein. Die Länge ist sogar das Feature dem ich am wenigsten Bedeutung beimesse (was ich auch schon im Vorfeld geschrieben habe) und unter DX nützt mir unlimitiert sowieso nichts weil die PS 2.0+ implementierungen auf maximal 1024 Instruktionen beschrängt sind. Wenn der R350 nicht auch erweiterungen im Befehlsumfang mit sich bringt nützt mir der Chip reichlich wenig. Und da ATI zu dem Thema nichts gesagt hat gehe ich mal ganz schwer davon aus das ausser der möglichen Länge alles beim alten bleibt.

[Virtual]

Originally posted by Demirug


Moment. Ich sagte immer nur das die FX wegen der Shader für micht interesanter ist. Shader schliesst hier alles und nicht nur die Länge ein. Die Länge ist sogar das Feature dem ich am wenigsten Bedeutung beimesse (was ich auch schon im Vorfeld geschrieben habe) und unter DX nützt mir unlimitiert sowieso nichts weil die PS 2.0+ implementierungen auf maximal 1024 Instruktionen beschrängt sind. Wenn der R350 nicht auch erweiterungen im Befehlsumfang mit sich bringt nützt mir der Chip reichlich wenig. Und da ATI zu dem Thema nichts gesagt hat gehe ich mal ganz schwer davon aus das ausser der möglichen Länge alles beim alten bleibt.

@Demirug - Von Natur aus zutiefst neugierig habe ich eine Frage zu Deiner Antwort(unten). Was die Länge der PS betrifft, so stimme ich Dir zu. Die Anzahl der in Games eingesetzten PS2.0 Instruktionen pro Shader sollte sich wohl im Rahmen von 10-50 bewegen. Ich gehe dabei schlicht davon aus, daß Du weder an einer Diashow noch an einem "Daumenkino" arbeitest, was deutlich längere Shader für bildschirmfüllende Effekte wohl als Konsequenz hätten. Zusammenfassend zum F-Buffer kann man guten Gewissens sagen: Der F-Buffer hat für Zocker keinen praktischen Nutzen, da er kaum zum Einsatz kommen wird. Lange Shader sind auf DCC beschränkt. Dies gilt natürlich auch für die FX.

Nun meine Frage:
Welche Features/Befehle/Mechanismen der FX-Shader-Implementation hälst du für so bedeutsam, daß ihr Fehlen im R300/R350 eine entscheidende Einschränkung bei der Shader-Entwicklung (10-50 Instruktionen) darstellt? Ich berücksichtige bei dieser Frage den wirtschaftlichen Standpunkt, von dem aus betrachtet Dein Entwicklungsziel bei PS2.0 liegen sollte. Chip-spezifische Pfade sind aufgrund der zusätzlichen Entwicklungskosten sicherlich nicht wirklich eine Option?!

G.
V.

[Unregistered]

Originally posted by Virtual


Welche Features/Befehle/Mechanismen der FX-Shader-Implementation hälst du für so bedeutsam, daß ihr Fehlen im R300/R350 eine entscheidende Einschränkung bei der Shader-Entwicklung (10-50 Instruktionen) darstellt?

G.
V.

Waren da nicht so ein paar unwichtige allseits bekannte Funktionen die in der FX-Shader direkt zur Verfügung stehen, ohne grosse Berechnungen?
Damit mein die unbekannten und in der Grafik nicht benutzten trigonometrischen Funktionen wie Sinus und Cosinus :P

Wenn ich mich da vertue berichtigt mich bitte ;)

[Demirug]

Originally posted by Virtual
Nun meine Frage:
Welche Features/Befehle/Mechanismen der FX-Shader-Implementation hälst du für so bedeutsam, daß ihr Fehlen im R300/R350 eine entscheidende Einschränkung bei der Shader-Entwicklung (10-50 Instruktionen) darstellt? Ich berücksichtige bei dieser Frage den wirtschaftlichen Standpunkt, von dem aus betrachtet Dein Entwicklungsziel bei PS2.0 liegen sollte. Chip-spezifische Pfade sind aufgrund der zusätzlichen Entwicklungskosten sicherlich nicht wirklich eine Option?!

G.
V.

Unsere zusätzlichen Entwicklungskosten für die erweiterten Shader belaufen sich auf 0. Das kommt daher das wir zum Programmieren unserer Shader ausschliesslich Hochsprachen benutzten. Daraus werden dann über den Compiler die am besten zum Chip passened Shader erzeugt.

Die zusätzlichen Fähigkeiten lassen sich dabei vom Compiler dahingehend nutzen das gewüschte Ergebniss mit weniger Takten zu erreichen weil man diese Fähigkeiten nicht mit den normalen mitteln nachbilden muss (was zusätzliche Takte kostet). Und wenn man einen solchen Shader erzeugt muss man in eben auch mal testen und dafür braucht man die passende Hardware.

[Virtual]

Originally posted by Demirug


Unsere zusätzlichen Entwicklungskosten für die erweiterten Shader belaufen sich auf 0. Das kommt daher das wir zum Programmieren unserer Shader ausschliesslich Hochsprachen benutzten. Daraus werden dann über den Compiler die am besten zum Chip passened Shader erzeugt.

Du meinst damit sicher NVidia's Cg. Ob das "voreingenommen" ist oder nicht, sei jeztz mal dahingestellt. (Wird wirklich der zum Chip am besten passende Shader erzeugt?! - Für die FX ja, aber für die Konkurrenz? ...)

Die zusätzlichen Fähigkeiten lassen sich dabei vom Compiler dahingehend nutzen das gewüschte Ergebniss mit weniger Takten zu erreichen weil man diese Fähigkeiten nicht mit den normalen mitteln nachbilden muss (was zusätzliche Takte kostet). Und wenn man einen solchen Shader erzeugt muss man in eben auch mal testen und dafür braucht man die passende Hardware.
Ich hatte unlängst in einer Diskussion mit Dir dir RISC/CISC Auseinandersetzung der 90er erwähnt, in der es um den Austausch von Komplexen Befehlssätzen gegen vereinfachte Befehlsätze ging. Welche Ziele damit verfolgt wurden, muß ich hier bestimmt nicht erklären. In meiner Frage bezog ich mich eigentlich eher auf die Shader(10-50Ins) die in den next-gen Spielen zum Einsatz kommen, nicht auf DCC Apps. Du hast mich nicht davon überzeugen können, daß der zugegeben weitaus mächtigere Befehlssatz der FX eine Rolle für next-gen Games spielen wird bzw. daß er wirklich Performance-Vorteile aufgrund mehr/komplexerer Befehle bieten kann. Ich bin nun nicht im Detail über die Laufzeiten aller Behfehle in der FX und im R350 informiert, aber ist nicht insbesondere die R350-Architektur in Hinblick auf kleine Shader effizienter in der Ausführung? Ich bleibe zunächst dabei: CineFX ist nur bei DCC wirklich überlegen. Die "RISC-"Architektur des R350 sollte bei einfacheren Shader nach PS2.0 mit 10-50Inst einfach effizienter sein. Damit müßte eigentlich der R350 das Maß der Dinge für dich sein, nicht die FX. Wo steckt also mein Denkfehler?!

G.
V.

[Demirug]

Originally posted by Virtual

Du meinst damit sicher NVidia's Cg. Ob das "voreingenommen" ist oder nicht, sei jeztz mal dahingestellt. (Wird wirklich der zum Chip am besten passende Shader erzeugt?! - Für die FX ja, aber für die Konkurrenz? ...)

Ich habe mich wohl missverständlich ausgedrückt. Man nimmt den Hochsprachenshader gibt in dem Compiler (NVIDIA oder MS) übergibt noch die Angaben für welchen Shaderversion man aus dem Quellcode einen Shader braucht und bekommt den entsprechenden Shader als Rückgabe. Mit zum Chip passend meinte ich also für eine zum Chip passendes Shaderversion. Der Compiler kennt also nicht den Chip sondern nur die Shaderversion für die er Code erzeugen soll.

Ich hatte unlängst in einer Diskussion mit Dir dir RISC/CISC Auseinandersetzung der 90er erwähnt, in der es um den Austausch von Komplexen Befehlssätzen gegen vereinfachte Befehlsätze ging. Welche Ziele damit verfolgt wurden, muß ich hier bestimmt nicht erklären. In meiner Frage bezog ich mich eigentlich eher auf die Shader(10-50Ins) die in den next-gen Spielen zum Einsatz kommen, nicht auf DCC Apps. Du hast mich nicht davon überzeugen können, daß der zugegeben weitaus mächtigere Befehlssatz der FX eine Rolle für next-gen Games spielen wird bzw. daß er wirklich Performance-Vorteile aufgrund mehr/komplexerer Befehle bieten kann. Ich bin nun nicht im Detail über die Laufzeiten aller Behfehle in der FX und im R350 informiert, aber ist nicht insbesondere die R350-Architektur in Hinblick auf kleine Shader effizienter in der Ausführung? Ich bleibe zunächst dabei: CineFX ist nur bei DCC wirklich überlegen. Die "RISC-"Architektur des R350 sollte bei einfacheren Shader nach PS2.0 mit 10-50Inst einfach effizienter sein. Damit müßte eigentlich der R350 das Maß der Dinge für dich sein, nicht die FX. Wo steckt also mein Denkfehler?!

G.
V.

Ich verstehe jetzt zugegebenermassen nicht was du mir hier mit RICS und CICS sagen möchtest. Ich vermute mal das du den Eindruck hast R3xx = RICS und NV3x = CICS. Das stimmt nicht. Was die Ausrichtung der Befehle bezüglich der Codelänge zur Ausführungkomplexität angeht liegen beide auf dem gleichen Level. Die Mächtigkeit (und damit die möglichkeit zum einsparen von Takten) kommt zum Beispiel daher das im NV30 zusätzliche Befehle zur Flusskontrolle (diese nur im Vertexbereich) vorhanden sind. Im Pixelshader Bereich hat man mit Predication und Arbitrary Swizzle die möglichkeit Instruktionen einzusparen. Natürlich darf man da keine Wunder erwarten aber jede Instruktion die nicht ausgeführt werden muss bringt etwas. Und wenn man diese Einsparung defakto umsonst bekommt ist es IMO blöd sie nicht zu nutzen. Ich habe auch kein Problem zum Beispiel für die erweiterten Shader Möglichkeiten des DeltaChromes entsprechend optimierte Shader erzeugen zu lassen (wobei ich mir da derzeit keine alzu grossen einsparungs möglichkeiten ausrechnen). Letzen endes kostet mich das einmalig nur etwas Rechenzeit und ein paar KB zusätzlich im Datenverzeichniss.

Was die Laufzeiten angeht so halten sich sowohl NVIDIA wie auch ATI bei den neuen Shadern (>= 2.0) sehr bedeckt. Von NVIDIA gibt es für die GF4 die Aussage das die Vertexshader linear mit der Länge skalieren. Bei den Pixelshader gilt im Prinzip das gleiche. Ein nicht bestätigtes Gerücht sagt aber das der Treiber in der Lage ist bestimmte PS Sequenzen unter ausnutzung der Register Combiner mit einem besseren Instruktion/Takt Verhältniss als andere umzusetzten. ATI hält sich aber auch beim R200 bedeckt und sagt einfach kürzer ist schneller.

Was nun die reale Ausführungsgeschwindigkeit angeht so ist mir das relative egal. Wenn man einen bestimmten Effekt erreichen will ergibt sich daraus zwangsläufig das dieser Effekt nach dem compilieren eine bestimmte Shaderlänge (Vertex und Pixel) hat. Diese kann wie ich oben aufgeführt habe für unterschiedliche Shaderversionen durchaus unterschiedlich sein. Wenn nun ein 2.0+ Shader auf einem NV3x Chip langsamer läuft als ein 2.0 Shader auf einem R3xx dann ist davon auszugehen das auf dem NV3x auch der 2.0 Shader langsamer ist. In solchen Fällen können wir dann sowieso nichts mehr machen und NVIDIA hat eben Pech gehabt. Das gleiche gilt aber auch im umgekehrten Fall. Wenn es dem Spieler dann eben zu langsam wird heist es Details runterschrauben das weniger anspruchsvolle Effektsets benutzten oder was auch immer die Performances erhöht. Ich fange defintive nicht an Shader auf Assembler ebene von Hand zu optimieren und werde das auch von keinem unserer Designer verlangen (die sollen andere Dinge tun). Ich bin gerne bereit von jedem IHV einen Compiler in unsere Produktionspipeline einzubauen welcher aus einer HLSL kompatiblen Hochsprache jeweils für seine Chips ideale DX Shader erzeugt. Bekommen wir keinen wird der Compiler von MS benutzt oder falls wir merke das ein Compiler eines anderen IHV auch für die Chip des Mitbewerbers besseren Code als der MS Compiler erzeugt wird alternativ eben dieser Compiler benutzt.

[Virtual]

Originally posted by Demirug


Ich habe mich wohl missverständlich ausgedrückt. Man nimmt den Hochsprachenshader gibt in dem Compiler (NVIDIA oder MS) übergibt noch die Angaben für welchen Shaderversion man aus dem Quellcode einen Shader braucht und bekommt den entsprechenden Shader als Rückgabe. Mit zum Chip passend meinte ich also für eine zum Chip passendes Shaderversion. Der Compiler kennt also nicht den Chip sondern nur die Shaderversion für die er Code erzeugen soll.


Zu blöd, daß ich gleich weg muß.:( Deshalb werde ich nur kurz auf den ersten Teil eingehen. Später dann widme ich mich dem zweiten Teil.

Zu 1:
Als Ausgangspunkt hast Du einen fertigen Hochsprachenshader und läßt ihn vom Compiler(NV/MS) unter Angabe der Zielversion übersetzen. OK - Welche Angaben kannst du hier machen? Ich habe es nicht überprüft (ließe sich wohl machen), aber ich vermute sehr:
Beim MS-Compiler: PS2.0/PS3.0
Beim NV-Compiler: PS2.0/PS3.0 UND NV30 (UND NV35 UND ...)

Sollte meine Annahme korrekt sein (ist sie's?), dann kann man mit dem NV-Compiler sehr wohl abseits des definierten Standards PS2.0/PS3.0 (optimierten)Code mit dem Target NV30 erzeugen. Der Code für Target NV30(/NV35...) könnte dabei maximal effizient sein und Code für Target PS2.0/PS3.0 (Konkurrenz) von durchschnittlicher Qualität. Selbst wenn der gegenwärtig erzeugte PS2.0 Code effizient wäre, so könnte dies NV zu jedem Zeitpunkt in der Zukunft mit einem Release-Update des Compilers ändern! Ist diese Abhängigkeit von NV für Entwickler wirklich wünschenswert?!

So, und jetzt muß ich weg... Bis später!

G.
V.

[Demirug]

Originally posted by Virtual
Zu 1:
Als Ausgangspunkt hast Du einen fertigen Hochsprachenshader und läßt ihn vom Compiler(NV/MS) unter Angabe der Zielversion übersetzen. OK - Welche Angaben kannst du hier machen? Ich habe es nicht überprüft (ließe sich wohl machen), aber ich vermute sehr:
Beim MS-Compiler: PS2.0/PS3.0
Beim NV-Compiler: PS2.0/PS3.0 UND NV30 (UND NV35 UND ...)

Sollte meine Annahme korrekt sein (ist sie's?), dann kann man mit dem NV-Compiler sehr wohl abseits des definierten Standards PS2.0/PS3.0 (optimierten)Code mit dem Target NV30 erzeugen. Der Code für Target NV30(/NV35...) könnte dabei maximal effizient sein und Code für Target PS2.0/PS3.0 (Konkurrenz) von durchschnittlicher Qualität. Selbst wenn der gegenwärtig erzeugte PS2.0 Code effizient wäre, so könnte dies NV zu jedem Zeitpunkt in der Zukunft mit einem Release-Update des Compilers ändern! Ist diese Abhängigkeit von NV für Entwickler wirklich wünschenswert?!

So, und jetzt muß ich weg... Bis später!

G.
V.

Der MS Compiler im offiziellen SDK kann vs 1.1, vs 2.0, PS 1.1, PS 1.2, PS 1.3, PS 1.4 und PS 2.0.
NVIDIA hat Profile für VS 1.1, VS 2.0, VS 2.0+, PS 1.1, PS 1.2, PS 1.3, PS 2.0 und PS 2.0+.

Die 3.0 Versionen kann noch keiner und MS arbeit derzeit an dem Compiler für 2.0+

Bei den 2.0+ Shader muss man natürlich noch Angaben machen was das + bedeutet und 2.0+ ist nicht abseits des definierten DX-Standards ergibt sich schon daraus das die IHV bei DX keine eigenen Sache dazu erfinden dürfen.

Klar könnet sich NVIDIA irgendwann entscheiden die Profile für die reinen 2.0 Versionen zu verschlechtern aber das würde sehr schnell aufallen weil man sich genau anschauen kann was für Shader der Cg Compiler erzeugt. Dann wäre das Geschrei gross.

Zudem kann ich wie schon gesagt keine Abhängkiet erkennen. Wenn der Cg Compiler für ein bestimmtes Profil schlechten Code erzeugt nimmt man eben den MS-Compiler für diese Profil und die Sache hat sich erledigt.

Der einzige Fall in dem man sich die Hand von NVIDIA begibt ist wenn man auch den Effektframework (CgFX) benutzt und selbst dann gibt es noch die möglichkeit Shader die mit einem anderen Compiler erzeugt wurden einzubinden. Aber auf diesem Gebiet setzten die meisten Studios sowieso eine Eigenentwicklung ein.

[Unregistered]

>Ich fange defintive nicht an Shader auf Assembler ebene von Hand zu optimieren
> und werde das auch von keinem unserer Designer verlangen

darf man fragen wo du arbeitest? :D
ahnung von der materie hast du ja offensichtlich jede menge ;D

[Demirug]

Originally posted by Unregistered
>Ich fange defintive nicht an Shader auf Assembler ebene von Hand zu optimieren
> und werde das auch von keinem unserer Designer verlangen

darf man fragen wo du arbeitest? :D
ahnung von der materie hast du ja offensichtlich jede menge ;D

Fragen darfst du natürlich. Aber ich muss dich mit der gleichen Antwort abspeisen wie alle anderen auch die mir diese Frage in einer öffentlichen Umgebung stellen. Ich bin derzeit nicht befugt über irgendwelche Namen oder spezifischen Projekte zu sprechen die nicht offiziel von unserer PR freigegeben sind.

[Henrik]

langweiler!
;)

[Virtual]

Originally posted by Unregistered


Waren da nicht so ein paar unwichtige allseits bekannte Funktionen die in der FX-Shader direkt zur Verfügung stehen, ohne grosse Berechnungen?
Damit mein die unbekannten und in der Grafik nicht benutzten trigonometrischen Funktionen wie Sinus und Cosinus :P

Wenn ich mich da vertue berichtigt mich bitte ;)


Beim NV30 gibt es die OP-Codes sin/cos. Beim R300/R350 nicht und sie werden über Makros implementiert. Nichtsdestotrotz müssen diese auch erst im NV30 Microcode ausgeführt werden, was letztlich auch Zeit kostet. Dabei ist aber die Genauigkeit festgelegt, welche man ansonsten nach Bedarf auslegen könnte.

Grundsätzlich hast du also recht. Über die praktische Bedeutung der PS2.0+ Befehle in "Game"-Shadern sagst das aber nichts aus!

G.
V.

[MegaManX4]

Originally posted by Demirug


Fragen darfst du natürlich. Aber ich muss dich mit der gleichen Antwort abspeisen wie alle anderen auch die mir diese Frage in einer öffentlichen Umgebung stellen. Ich bin derzeit nicht befugt über irgendwelche Namen oder spezifischen Projekte zu sprechen die nicht offiziel von unserer PR freigegeben sind.

Bei welcher Firma arbeitest du denn?

[StefanV]

Originally posted by MegaManX4
Bei welcher Firma arbeitest du denn?

Vergiss es, das wird Demi nicht sagen ;)

[MegaManX4]

Originally posted by Stefan Payne


Vergiss es, das wird Demi nicht sagen ;)

Warum nicht? Verbietet das auch die PR-Abteilung?

[2B-Maverick]

Originally posted by MegaManX4


Warum nicht? Verbietet das auch die PR-Abteilung?

jop.. du noob ;D

[Virtual]

Originally posted by Demirug


Der MS Compiler im offiziellen SDK kann vs 1.1, vs 2.0, PS 1.1, PS 1.2, PS 1.3, PS 1.4 und PS 2.0.
NVIDIA hat Profile für VS 1.1, VS 2.0, VS 2.0+, PS 1.1, PS 1.2, PS 1.3, PS 2.0 und PS 2.0+.

Die 3.0 Versionen kann noch keiner und MS arbeit derzeit an dem Compiler für 2.0+

Bei den 2.0+ Shader muss man natürlich noch Angaben machen was das + bedeutet und 2.0+ ist nicht abseits des definierten DX-Standards ergibt sich schon daraus das die IHV bei DX keine eigenen Sache dazu erfinden dürfen.

Klar könnet sich NVIDIA irgendwann entscheiden die Profile für die reinen 2.0 Versionen zu verschlechtern aber das würde sehr schnell aufallen weil man sich genau anschauen kann was für Shader der Cg Compiler erzeugt. Dann wäre das Geschrei gross.

Zudem kann ich wie schon gesagt keine Abhängkiet erkennen. Wenn der Cg Compiler für ein bestimmtes Profil schlechten Code erzeugt nimmt man eben den MS-Compiler für diese Profil und die Sache hat sich erledigt.

Der einzige Fall in dem man sich die Hand von NVIDIA begibt ist wenn man auch den Effektframework (CgFX) benutzt und selbst dann gibt es noch die möglichkeit Shader die mit einem anderen Compiler erzeugt wurden einzubinden. Aber auf diesem Gebiet setzten die meisten Studios sowieso eine Eigenentwicklung ein.

(Wieder kurz Zeit)

Danke für die Zusammenstellung der Target-Optionen! :)

Mit "abseits des definierten" Pfades meinte ich die PS-Instruktion des NV30, die über PS3.0 hinausgehen. Damit hat der der IHV eine Erweiterung eingeführt, die auch ein MS-Compiler deshalb nicht nutzen können wird, weil diese eben nicht in PS3.0 Befehlssatz enthalten sind. Auch hier fehlen mir nähere Informationen, aber PS2.0+ müßte doch eigentlich nur Befehle aus der Komplementmenge zu PS2.0 enthalten?! Native Erweiterungen (NV30) sollten somit in den PS2.0+ keinen Einzug halten können. Der NV-Compiler wäre somit verpflichtend einzusetzten, möchte man den NV30 vollständig ausreizen, da er das Target PS2.0+ einzig korrekt/vollständig verstünde. Bis auf die Möglichkeit NV30-Code mit dem NV-Compiler erzeugen zu können sehe ich keinen Grund für die Existenz des NV-Compilers. Warum hat ihn NV entwickelt? Der alte Hang zum Monopol? Das es HLSL geben wird, war NV doch schon vorher bekannt. Ist der Sinn und Zweck des Compiler vielleicht doch eher DCC und nicht Game-Engines?!

Zusammenfassung:
Außer wenn Du mehrere Render-Pfade pro Engine einsetzen möchtest (wirtschaftlich sinnvoll?), kann ich noch keinen wirklich Grund erkennen, weshalb Game-Developer den NV-Compiler anstelle des MS-Compilers einsetzen sollten.

Wir sind ein wenig vom Thema abgekommen: Weshalb Du nun unbedingt den NV30 statt des R3x0 einsetzen mußt? Oder ob der R3x0 nicht vielleicht doch näher an Games läge... -> Muß ja noch Teil 2 beantworten ... Muß wieder weg...

G.
V.

Sorry! - Gerade den move gesehen - Bitte auch verschieben! - Danke!

[Demirug]

Originally posted by Virtual


(Wieder kurz Zeit)

Danke für die Zusammenstellung der Target-Optionen! :)

Kein Problem :)

Mit "abseits des definierten" Pfades meinte ich die PS-Instruktion des NV30, die über PS3.0 hinausgehen. Damit hat der der IHV eine Erweiterung eingeführt, die auch ein MS-Compiler deshalb nicht nutzen können wird, weil diese eben nicht in PS3.0 Befehlssatz enthalten sind. Auch hier fehlen mir nähere Informationen, aber PS2.0+ müßte doch eigentlich nur Befehle aus der Komplementmenge zu PS2.0 enthalten?!

2.0+ stellt eine variable Übergangsmenge zu 3.0 dar. Das heist ein Chip der die 3.0 Shader beherscht wird jeden jemals erstellten 2.0+ Shader ohne Probleme laufen lassen können. Daraus ergibt sich auch das nicht alles was der NV30 kann mit DX benutzt werden kann. Wenn man die NV30 Shader vollständig nutzen will muss man unter OpenGL die Entsprechende Extension nutzen.


Native Erweiterungen (NV30) sollten somit in den PS2.0+ keinen Einzug halten können. Der NV-Compiler wäre somit verpflichtend einzusetzten, möchte man den NV30 vollständig ausreizen, da er das Target PS2.0+ einzig korrekt/vollständig verstünde.

Es sind ja auch keine speziellen NV30 Dinge enthalten. Wie gesagt kann der NV30 sogar mehr als 2.0+ zuläst. Einen zum NV30 passenden 2.0+ Shader wird auch der MS Compiler erzeugen können (sobald MS damit fertig ist). DX verbietet jedem Hersteller etwas eigenes zu definieren das ist nur bei OpenGL erlaubt.

Bis auf die Möglichkeit NV30-Code mit dem NV-Compiler erzeugen zu können sehe ich keinen Grund für die Existenz des NV-Compilers. Warum hat ihn NV entwickelt? Der alte Hang zum Monopol? Das es HLSL geben wird, war NV doch schon vorher bekannt. Ist der Sinn und Zweck des Compiler vielleicht doch eher DCC und nicht Game-Engines?!

für DCC gibt es zum Beispiel Renderman. HLSL und Cg sind primär schon für Echtzeit Anwendungen gedacht. Die Entwicklung hatte meherer Gründen. Die zwei primären waren:

- Bei den Entwickler fand die Assemblersprache für die Shadererstellung nicht so richtig anklang. Also musste eine Hochsprache her. MS kann einen solche Änderung aber nur in Verbindung mit einer neuen DX Version durchführen (wie auch geschen). NVIDIA konnte da viel schneller reagieren. Die ersten Betas gab es schon zu DX8 Zeiten.

- Für MS macht es keinen Sinn einen Compiler für OpenGL Shader zu schreiben. NVIDIA möchte aber auch die Entwickler welche OpenGL benutzten in den Genuss einer Shaderhochsprache bringen.

Natürlich wusste NVIDIA das es HLSL geben wird. MS und NVIDIA haben ja HLSL und Cg in gegenseitiger Absprache entwickelt um sicherzustellen das die Grundsyntax identisch ist.

Zusammenfassung:
Außer wenn Du mehrere Render-Pfade pro Engine einsetzen möchtest (wirtschaftlich sinnvoll?), kann ich noch keinen wirklich Grund erkennen, weshalb Game-Developer den NV-Compiler anstelle des MS-Compilers einsetzen sollten.

Nicht Render-Pfade sondern Shadersets. Ich bestehe hier auf dieser Unterscheidung. Ein zusätzlicher Renderpfad muss programmiert werden. Ein zusätzliches Shaderset wird aus einer sowieso vorhandnen Datenbasis erzeugt. Und einen Multishaderset Engine brauchen wir auf jeden Fall weil wir sonst entweder auf dem DX8 Level hängen bleiben oder alle DX8 Karten aussperren. Das ist dann wirtschaftlich nicht sinnvoll.

Warum man den NV Compiler nimmt? Weil er einfach den kompakteren (=kürzer) Shader-Code erzeugt als der von MS. Und selbst ATI sagt ja kürzer gleich besser.


Wir sind ein wenig vom Thema abgekommen: Weshalb Du nun unbedingt den NV30 statt des R3x0 einsetzen mußt? Oder ob der R3x0 nicht vielleicht doch näher an Games läge... -> Muß ja noch Teil 2 beantworten ... Muß wieder weg...

G.
V.

Die R3xx kann shader technisch nichts was die NV3x Chips nicht auch können (die unlimitierte Shaderlänge kann ich unter DX nicht nutzen). Dafür können die NV3x Chips aber Dinge die auf den R3xx Chips nicht laufen. Mit dem NV3x kann ich also alles testen mit einem R3xx nicht.

[Crazytype]

Lol JC hat Deutsch gelernt und ist in wahrheit Demi ;)

[zeckensack]

Originally posted by Crazytype
Lol JC hat Deutsch gelernt und ist in wahrheit Demi ;) Ich habe schon englische Postings von Demirug gesehen und kann dir versichern, daß John Carmack deutlich besseres Englisch* kann ;)

(oder alles nur Tarnung? :| )

*nicht bös gemeint @ Demirug :)

[Demirug]

Originally posted by zeckensack
Ich habe schon englische Postings von Demirug gesehen und kann dir versichern, daß John Carmack deutlich besseres Englisch* kann ;)

(oder alles nur Tarnung? :| )

*nicht bös gemeint @ Demirug :)

Ich weiss das mein Englisch grausam ist. Aber ich vermute mal das mein Englisch besser ist als das Deutsch von JC. :)

[zeckensack]

Originally posted by Demirug


Ich weiss das mein Englisch grausam ist. Aber ich vermute mal das mein Englisch besser ist als das Deutsch von JC. :) Auch wahr :)

[egdusp]

Es soll ja möglich sein, den Shadercode erst während der Laufzeit zu compilieren (oder bei Programmstart), also auf jeden Fall nur den Sourcecode mit dem Programm ausliefern.

Da, wie ich hier rausgelesen habe, die Syntax (der Sourcecode) von Cg und HLSL unabhängig von der Shaderversion ist, könnten damit auch zukünftige Shaderversionen (3.0 und höher) automatisch unterstützt werden, sofern MS in DirectX oder NV per externem Programm diese Compiler (praktisch unsichtbar für den Gamer) zur Verfügung stellen.

Wäre es auch möglich eine Compiler zu schreiben, der je nach unterstützen PS/VS Features einen entsprechenden Code erzeugt? Also keinen exra Compiler für PS 2.x sondern einen PS3.0 Compiler, der auch automatisch alle PS2.x Shader ausnutzen könnte.

mfg
egdusp

P.s.: @ Demirug: Wie weit ist deines Wissens nach Cg bzw. HLSL unter Entwicklern verbreitet?

[Demirug]

Originally posted by egdusp
Es soll ja möglich sein, den Shadercode erst während der Laufzeit zu compilieren (oder bei Programmstart), also auf jeden Fall nur den Sourcecode mit dem Programm ausliefern.

Ja kann man machen. Sowohl vom Cg wie auch von HLSL Compiler gibt es jeweils eine Kommandozeilen Version und eine Version zum einbinden in eigene Programme.

Da, wie ich hier rausgelesen habe, die Syntax (der Sourcecode) von Cg und HLSL unabhängig von der Shaderversion ist, könnten damit auch zukünftige Shaderversionen (3.0 und höher) automatisch unterstützt werden, sofern MS in DirectX oder NV per externem Programm diese Compiler (praktisch unsichtbar für den Gamer) zur Verfügung stellen.

Korrekt. Dabei gilt das Prinzip der Aufwärstkompatibilität. Soll heisen das ein Sourcecode welcher sich zu einem 1.1 Shader compileren läst auch in einen Shader mit höherer Versionsnummer übersetzen läst. (Ausnahmen bestätigen die Regel, aber das ginge jetzt wohl zu sehr ins Detail)

Wäre es auch möglich eine Compiler zu schreiben, der je nach unterstützen PS/VS Features einen entsprechenden Code erzeugt? Also keinen exra Compiler für PS 2.x sondern einen PS3.0 Compiler, der auch automatisch alle PS2.x Shader ausnutzen könnte.

mfg
egdusp

Im Prinzip funktioniert das jetzt schon so. Man sagt dem Compiler beim Aufruf für welche Shaderversion er code erzeugen soll. Die derzeitigen Compiler unterstützen aber maximal 2.0+. Aber 3.0 support wird sicher bald kommen.

P.s.: @ Demirug: Wie weit ist deines Wissens nach Cg bzw. HLSL unter Entwicklern verbreitet?

Es gibr da durchaus einiges Statements. Aber in wie weit den Worten Taten folgen kann man nicht sagen bevor die entsprechenden Titel herauskommen. Und selbst dann sieht man nicht unbedingt ob einen Shaderhochsprache zum Einsatz kamm.

Da aber sowohl ATI und NVIDIA dazu raten die Hochsprachen zu benutzen dürfte sich die Sache wohl mittel bis langfristig durchsetzen.

[Unregistered]

demi wie alt biste denn??

ich hoffe dass du uns das sagen kannst.
ausserdem würde mich gerne interessieren wie du denn zu diesem job gekommen bist und wleche qualifikationen du hast :)
thx

[Demirug]

Originally posted by Unregistered
demi wie alt biste denn??

ich hoffe dass du uns das sagen kannst.
ausserdem würde mich gerne interessieren wie du denn zu diesem job gekommen bist und wleche qualifikationen du hast :)
thx

26. Wer ein bischen im Forum sucht bekommt sogar meinen Geburstag raus.

Wie ich an den Job gekommen bin? Ich habe mich einfach selbst eingestellt. ;)

qualifikationen? Auf meinem letzten Abschluss steht "Technischer Assitent für Informatik" der rest ist viel Praxsis und ein paar Kubikmeter Bücher.

Ich bin aber nicht unbedingt als gutes Vorbild zu gebrauchen. Denn ich hatte teilweise einfach das Glück zum richtigen Zeitpunkt am richtigen Ort zu sein.

[Virtual]

Originally posted by Demirug



Kein Problem :)



2.0+ stellt eine variable Übergangsmenge zu 3.0 dar. Das heist ein Chip der die 3.0 Shader beherscht wird jeden jemals erstellten 2.0+ Shader ohne Probleme laufen lassen können. Daraus ergibt sich auch das nicht alles was der NV30 kann mit DX benutzt werden kann. Wenn man die NV30 Shader vollständig nutzen will muss man unter OpenGL die Entsprechende Extension nutzen.




Es sind ja auch keine speziellen NV30 Dinge enthalten. Wie gesagt kann der NV30 sogar mehr als 2.0+ zuläst. Einen zum NV30 passenden 2.0+ Shader wird auch der MS Compiler erzeugen können (sobald MS damit fertig ist). DX verbietet jedem Hersteller etwas eigenes zu definieren das ist nur bei OpenGL erlaubt.



für DCC gibt es zum Beispiel Renderman. HLSL und Cg sind primär schon für Echtzeit Anwendungen gedacht. Die Entwicklung hatte meherer Gründen. Die zwei primären waren:

- Bei den Entwickler fand die Assemblersprache für die Shadererstellung nicht so richtig anklang. Also musste eine Hochsprache her. MS kann einen solche Änderung aber nur in Verbindung mit einer neuen DX Version durchführen (wie auch geschen). NVIDIA konnte da viel schneller reagieren. Die ersten Betas gab es schon zu DX8 Zeiten.

- Für MS macht es keinen Sinn einen Compiler für OpenGL Shader zu schreiben. NVIDIA möchte aber auch die Entwickler welche OpenGL benutzten in den Genuss einer Shaderhochsprache bringen.

Natürlich wusste NVIDIA das es HLSL geben wird. MS und NVIDIA haben ja HLSL und Cg in gegenseitiger Absprache entwickelt um sicherzustellen das die Grundsyntax identisch ist.



Nicht Render-Pfade sondern Shadersets. Ich bestehe hier auf dieser Unterscheidung. Ein zusätzlicher Renderpfad muss programmiert werden. Ein zusätzliches Shaderset wird aus einer sowieso vorhandnen Datenbasis erzeugt. Und einen Multishaderset Engine brauchen wir auf jeden Fall weil wir sonst entweder auf dem DX8 Level hängen bleiben oder alle DX8 Karten aussperren. Das ist dann wirtschaftlich nicht sinnvoll.

Warum man den NV Compiler nimmt? Weil er einfach den kompakteren (=kürzer) Shader-Code erzeugt als der von MS. Und selbst ATI sagt ja kürzer gleich besser.




Die R3xx kann shader technisch nichts was die NV3x Chips nicht auch können (die unlimitierte Shaderlänge kann ich unter DX nicht nutzen). Dafür können die NV3x Chips aber Dinge die auf den R3xx Chips nicht laufen. Mit dem NV3x kann ich also alles testen mit einem R3xx nicht.

Wieder da für Teil 2 ... Schließe nun für Teil 1 ab - Wir sind wohl am Ende dieses Parts angekommen.

Ich stelle fest:
Ich verstehe deine Darstellung und stimme mit ihr weitgehend überein. Du hast die Dinge mit Hilfe Deines Detailwissens präzise(r) dargelegt. Von nicht entscheidender Bedeutung ist für mich, ob nun verschiedene Shadersets mit oder ohne zusätzlichen Code, oder ob der NV30 sich besser als der R300 als "DCC-Preview-Device" eignet (Renderman wollte ich nicht ersetzen ;) )

Zusammenfassung:
Recap - Es ging um die Frage, ob und weshalb du unbedingt den NV30 anstelle des R300 als Entwicklungsplatform für Games einsetzen möchtest? Aus dieser grundlegenden Frage hat sich die Diskussion entwickelt. (In Teil 2 würde ich gerne auf die Ausführungsgeschwindigkeit von PShadern auf NV3x/R3x0 eingehen)

Deine Antwort steht im letzten Satz und deckt sich, falls ich mich recht erinnere, mit JC's Begründung. Shadersets, die native(nur OpenGL) bzw. PS2.0+(nur DX) NV30-Unterstützung zum Ziel haben, können zusätzlich zu PS2.0(R300) mit NV-Compiler erzeugt und getested werden. Das wäre die fachliche Begründung.

Mein persönlicher Eindruck, ohne Dir Dabei zu nahe treten zu wollen!:
Beim gegenwärtigen Verbreitungsgrad der NV3x-Chips sollte eigentlich die sachliche Begründung nicht ein KO-Kriterum für den Einsatz von R3x0-Chips in deinen Rechnern sein. Neben deiner sachlichen Begründung müßte eigentlich eine persönliche Präferenz für den NV30 zusätzlich vorliegen, welche den Einsatz des NV30-Referenzboards erst wirklich "zwingend" für Dich macht. Dabei siehst du über die bereits in anderen Threads hinlänglich diskutierten Nachteile der NV30-Referenzboards hinweg. Über eine der Nachteile hat sich sogar JC "verärgert" gezeigt, und dies sogar trotz bekundeter Unempfindlichkeit: Die nervige Geräuchkulisse der Referenzboards.

G.
V.

PS.
War mir bisher eine angenehme Diskussion! :)

[Demirug]

Originally posted by Virtual

Wieder da für Teil 2 ... Schließe nun für Teil 1 ab - Wir sind wohl am Ende dieses Parts angekommen.

Ich stelle fest:
Ich verstehe deine Darstellung und stimme mit ihr weitgehend überein. Du hast die Dinge mit Hilfe Deines Detailwissens präzise(r) dargelegt. Von nicht entscheidender Bedeutung ist für mich, ob nun verschiedene Shadersets mit oder ohne zusätzlichen Code, oder ob der NV30 sich besser als der R300 als "DCC-Preview-Device" eignet (Renderman wollte ich nicht ersetzen ;) )

Zusammenfassung:
Recap - Es ging um die Frage, ob und weshalb du unbedingt den NV30 anstelle des R300 als Entwicklungsplatform für Games einsetzen möchtest? Aus dieser grundlegenden Frage hat sich die Diskussion entwickelt. (In Teil 2 würde ich gerne auf die Ausführungsgeschwindigkeit von PShadern auf NV3x/R3x0 eingehen)

Deine Antwort steht im letzten Satz und deckt sich, falls ich mich recht erinnere, mit JC's Begründung. Shadersets, die native(nur OpenGL) bzw. PS2.0+(nur DX) NV30-Unterstützung zum Ziel haben, können zusätzlich zu PS2.0(R300) mit NV-Compiler erzeugt und getested werden. Das wäre die fachliche Begründung.

Ja die Begründung ist ähnlich wie die von JC. Er sprach von alle NVIDIA Chips ab dem NV10 und den standard OpenGL Pfaden die er mit dem NV30 testen konnte gegenüber den standard Pfaden und dem R200 Pfad mit einer R300 Karte. Dank DX habe ich es da etwas einfacher da ich mit einem NV3x Chips alles vortesten kann. Detailtests müssen dann sowieso auf der entsprechenden Hardware ablaufen. Aber das ist die primäre Aufgabe der Qualitätskontrolle.

Mein persönlicher Eindruck, ohne Dir Dabei zu nahe treten zu wollen!:
Beim gegenwärtigen Verbreitungsgrad der NV3x-Chips sollte eigentlich die sachliche Begründung nicht ein KO-Kriterum für den Einsatz von R3x0-Chips in deinen Rechnern sein. Neben deiner sachlichen Begründung müßte eigentlich eine persönliche Präferenz für den NV30 zusätzlich vorliegen, welche den Einsatz des NV30-Referenzboards erst wirklich "zwingend" für Dich macht. Dabei siehst du über die bereits in anderen Threads hinlänglich diskutierten Nachteile der NV30-Referenzboards hinweg. Über eine der Nachteile hat sich sogar JC "verärgert" gezeigt, und dies sogar trotz bekundeter Unempfindlichkeit: Die nervige Geräuchkulisse der Referenzboards.

G.
V.

PS.
War mir bisher eine angenehme Diskussion! :)

Verbreitungsgrade sollte man wenn man sich auf der Ebene des Technologie Designs befindet besser nicht berücksichtigen. Wenn es darum ginge dürfte ich rein von der kaufmännischen Seite her noch nicht mal DX8-Karte als technologisches minimum ansehen und einen DX9 Karten support sollte ich besser ganz sein lassen. Da wir die Engine aber längerfristig einsetzten möchte ist es für uns sinnvoll auf einem hohen Technologielevel zu arbeiten. Ja die Teile sind laut und aus diesem Grund versuche ich auch derzeit eine nicht ultra mit einer alternativen Kühllösung zu bekommen. Ich bin da aber glücklicherweise auch nicht so empfindlich was Lautstärke angeht.

[Virtual]

Originally posted by Demirug
Verbreitungsgrade sollte man wenn man sich auf der Ebene des Technologie Designs befindet besser nicht berücksichtigen. Wenn es darum ginge dürfte ich rein von der kaufmännischen Seite her noch nicht mal DX8-Karte als technologisches minimum ansehen und einen DX9 Karten support sollte ich besser ganz sein lassen. Da wir die Engine aber längerfristig einsetzten möchte ist es für uns sinnvoll auf einem hohen Technologielevel zu arbeiten. Ja die Teile sind laut und aus diesem Grund versuche ich auch derzeit eine nicht ultra mit einer alternativen Kühllösung zu bekommen. Ich bin da aber glücklicherweise auch nicht so empfindlich was Lautstärke angeht.

Eine vertretbare Haltung. Auf wirtschaftliche (Detail-)Gesichtspunkte möchte ich in einem Tech-Forum nicht näher eingehen. Ich habe keine Erfahrung mit Shader-Entwicklung und könnte somit deutlich daneben liegen. Alledings, eine kleine Anmerkung sei aber erlaubt! :)

Meine Annahme ist gewesen:
Je weniger Targets, desto weniger Shadersets, desto kostengünstiger. Allerdings gilt dies nur sofern erforderliche/gewünschte/benötigte Effekte und Effizienz(R200/NV30) es zulassen. Hier ist gute Planung gefragt, und liegt sie vor, dann sollte es sich nicht lohnen, für vom (gemeinsamen) Standard (PS1.3/PS2.0/PS3.0) abweichende Caps zu entwickeln. Die Idee ist der Entwicklung für Konsolen-Spiele entliehen.

Außerdem: Bis PS1.3 bzw. PS2.0 Caps vollständig in Bezug auf die Möglichkeiten ausgereizt worden sind und entsprechend leistungsfähige Hardware für den breiten Einsatz vorhanden ist, vergeht nach bisheriger Erfahrung ohnehin viel Zeit, die man zu Perfektionierung der eigenen Fertigkeiten hinsichtlich dieser Targets nutzen sollte.

Aber vielleicht sieht es ja in der PC-Praxis anders aus...

G.
V.

[Demirug]

Originally posted by Virtual
Meine Annahme ist gewesen:
Je weniger Targets, desto weniger Shadersets, desto kostengünstiger. Allerdings gilt dies nur sofern erforderliche/gewünschte/benötigte Effekte und Effizienz(R200/NV30) es zulassen. Hier ist gute Planung gefragt, und liegt sie vor, dann sollte es sich nicht lohnen, für vom (gemeinsamen) Standard (PS1.3/PS2.0/PS3.0) abweichende Caps zu entwickeln. Die Idee ist der Entwicklung für Konsolen-Spiele entliehen.

Konsolen und PC entwicklung (Ich sage lieber für geschlossene und offenen Systeme) sind zwei Paar Schuhe. Die Entwicklung für ein geschlossenes System ist viel einfacher. Das ich hier die unterschiedung mache hängt damit zusammen das es auch im Konsolenbereich immer mehr in die Richtung der übergreifenden Entwicklung geht. Man schreibt also Titel für mehr als eine Konsole gleichzeitig. Hierbei treten dann ähnliche (eher noch schlimmere) Probleme wie beim PC auf.

Wie gesagt erzeugen wir die Shadersets halbautomatisch. Bei 2.0 und 2.0+ gibt es von der Entwicklungsseite her wie gesagt keinen Unterschied solange man mit 2.0+ keine zusätzlichen (mit 2.0 nicht möglichen) Effekte programmieren will. Das Endtesten muss sowieso auf unterschiedlichen Karten durchgeführt werden wodurch auch hier kein zusätzlicher Aufwand entsteht.

Das Prinzip das hinter unserem Shadersystem steht ist einfach das man aus einem Datenpool welcher die Effekte beschreibt die zur Verfügung stehende Hardware zum umsetzten dieser Effekte optimal nutzt. So werden zum Beispiel bei einem R200 Set die PS als 1.4 Shader erzeugt. Dem Designer ist das aber egal weil er nur den Effekt beschreibt um die genaue umsetzung in die Shader (VS und PS) sowie den benötigten Rendersettings kümmert sich der Framework.

Außerdem: Bis PS1.3 bzw. PS2.0 Caps vollständig in Bezug auf die Möglichkeiten ausgereizt worden sind und entsprechend leistungsfähige Hardware für den breiten Einsatz vorhanden ist, vergeht nach bisheriger Erfahrung ohnehin viel Zeit, die man zu Perfektionierung der eigenen Fertigkeiten hinsichtlich dieser Targets nutzen sollte.

Aber vielleicht sieht es ja in der PC-Praxis anders aus...

G.
V.

Wie gesagt wir optimieren nicht direkt auf Targets sondern wir optimieren nur den Shaderframework darauf für unterschiedliche Targets eine optimale umsetzung der Effekte durchzuführen. Das ist aber auch eine Aufgabe des lernen und verstehens. Nur wollen wir dieses Wissen das dabei gewonnen wird nicht nur in den Köpfen der Leute die Shader erstellen sondern in einem Automatischen System so das auch bereits fertiggestellte Effekte von den neuen Erkenntnissen profitieren können ohne das die Leute mit dem Wissen diese Effekte noch einmal neu schreiben müssen. Das alles macht natürlich nur in Verbindung mit einer Langfristigen Plannung sinn. Wenn wir jetzt nur mal schnell eine Engine für nur einen Title bräuchten hätte ich einfach festgelegt das alles mit VS 1.1 und PS 1.1 (oder sogar nur DX7 Pixelpipeline) gemacht wird.

[Virtual]

Originally posted by Demirug


Konsolen und PC entwicklung (Ich sage lieber für geschlossene und offenen Systeme) sind zwei Paar Schuhe. Die Entwicklung für ein geschlossenes System ist viel einfacher. Das ich hier die unterschiedung mache hängt damit zusammen das es auch im Konsolenbereich immer mehr in die Richtung der übergreifenden Entwicklung geht. Man schreibt also Titel für mehr als eine Konsole gleichzeitig. Hierbei treten dann ähnliche (eher noch schlimmere) Probleme wie beim PC auf.

Wie gesagt erzeugen wir die Shadersets halbautomatisch. Bei 2.0 und 2.0+ gibt es von der Entwicklungsseite her wie gesagt keinen Unterschied solange man mit 2.0+ keine zusätzlichen (mit 2.0 nicht möglichen) Effekte programmieren will. Das Endtesten muss sowieso auf unterschiedlichen Karten durchgeführt werden wodurch auch hier kein zusätzlicher Aufwand entsteht.

Das Prinzip das hinter unserem Shadersystem steht ist einfach das man aus einem Datenpool welcher die Effekte beschreibt die zur Verfügung stehende Hardware zum umsetzten dieser Effekte optimal nutzt. So werden zum Beispiel bei einem R200 Set die PS als 1.4 Shader erzeugt. Dem Designer ist das aber egal weil er nur den Effekt beschreibt um die genaue umsetzung in die Shader (VS und PS) sowie den benötigten Rendersettings kümmert sich der Framework.



Wie gesagt wir optimieren nicht direkt auf Targets sondern wir optimieren nur den Shaderframework darauf für unterschiedliche Targets eine optimale umsetzung der Effekte durchzuführen. Das ist aber auch eine Aufgabe des lernen und verstehens. Nur wollen wir dieses Wissen das dabei gewonnen wird nicht nur in den Köpfen der Leute die Shader erstellen sondern in einem Automatischen System so das auch bereits fertiggestellte Effekte von den neuen Erkenntnissen profitieren können ohne das die Leute mit dem Wissen diese Effekte noch einmal neu schreiben müssen. Das alles macht natürlich nur in Verbindung mit einer Langfristigen Plannung sinn. Wenn wir jetzt nur mal schnell eine Engine für nur einen Title bräuchten hätte ich einfach festgelegt das alles mit VS 1.1 und PS 1.1 (oder sogar nur DX7 Pixelpipeline) gemacht wird.

Danke für die Einsicht! :) Verstanden habe ich es wie folgt:
Das Shaderframework als Effekte-Abstraktionslayer reduziert die Entwicklungskosten für mehr Targets. Der Mehraufwand besteht darin, die Umsetzung von Effekten durch das Shaderframework auf die Targets zu optmieren. Neue/alte Effekte können anschließend von Detailverbesserungen profitieren. Der NV30 dient bis zu einem würdigen Nachfolger (R400/NV40) als ("Alpha"/"Beta")Test-Basis für Umsetzung aller Effekte des Frameworks, da er sämtliche Hardware-Shaderversionen in sich vereint. Abschließende Tests(z.B. in der Qualitätskontrolle) erforden den Einsatz von Karten mit den unterstützten Chips. Der NV30 ist gegenwärtig also zurecht in Deiner Entwicklungsmaschine. Und ich bin geneigt, dem NV30 zuzugestehen, daß er diese besondere Position "verliehen" bekam, ohne daß persönliche Vorlieben auf Deiner Seite hauptsächlich als Ursache zu werten sind! :)

Jetzt aber zurück zu den Shadern und Part 2 ... (später)

G.
V.