Würde an einer solchen ShaderIDE dann auch richtiges Interesse bestehen (auch in Sachen Mitarbeit)?
Hab SETH von Grund auf neu geschrieben,und man kann dort bereits erste Shaderexperimente wagen.Evtl. stell ich heute oder morgen mal ne Preview Version ins Netz.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)

Prinzipiell besteht, zumindest bei mir, an einer Shader-IDE Interesse. Dies aber, aus Zeitgründen, eher an der Verwendung. Wobei diese momentan auch eher (noch) auf Vertexshader beruht. FXPascal ansich ist jedenfalls eine feine Sache. Je nach Umfang ließe sich aber bestimmt auch noch mal ein bischen Zeit für die Mitarbeit abdrücken. Aber ganz tolles Gewissen habe ich dabei auch nicht, die Arbeit den anderen aufzuschieben...
Trotzdem hätte so eine Shader-IDE was, vor allem in Zusammenhang mit FXPascal, dass mir gefällt, von mir selbst aber (noch) nicht eingesetzt wird.

_________________
Thunderman
Bei schwierigen Problemen entscheiden wir uns einfach für die richtige Lösung. Klar?

Ein brasilianischer Nutzer von Mcad hat angefragt, ob es das fxPascal Handbuch auch auf Englisch gibt.

Hast du da was in der Richtung auf Lager, bzw. vor?

Ansonsten könnte auch ich eine englische Zusammenfassung der unterstützten Befehle und Datentypen erstellen, das wäre dann halt eher eine Art Stichwortverzeichnis.

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

Wenn da Interesse besteht könnt ich das mal versuchen zu übersetzen.
Die Variablennamen bleiben ja gleich und der Text sollte mit google schnell gemacht sein.

Die Version 0.3 schaut schon sehr reif aus - an sich könntest du locker mit der Versionsnummer 1.0 rausrücken! Ich denke mal so langsam muss man echt auf die OpenGL HLSL warten, bis fxPascal noch weiter ausgebaut werden kann - soll heißen, der OpenGL Shaderassembler wird meiner Ansicht nach perfekt ausgenutzt.
Du könntest jetzt natürlich noch anfangen, zusätzlich zu GL_ATI_DRAW_BUFFERS weitere herstellerspezifische Erweiterungen einzubauen, mir wäre das aber echt zuviel Arbeit - obwohl es schon interessant wäre einfache Fragmentprogramme mit einem Subset der fxPascal Befehle für die ATI 9000 oder Geforce 3 und 4 Karten kompilieren zu können - oder auch auf GeforceFX Karten bedingte Sprünge nutzen zu können.

Folgendes ist mir noch aufgefallen:

- Arrays können nur als Konstante oder Programmparameter deklariert werden, nicht aber als normale Variablen oder varying Definitionen - hat dies einen besonderen Grund?

- wenn man Result-Werte auslesen möchte (z.B. result.position in einem Vertexprogramm) wird dies mit einer Fehlermeldung quittiert. Dies ist zwar völlig korrekt, als diese Variablen im Shaderassembler WriteOnly sind - eine Hochsprache könnte allerdings, wenn auf diese Komponenten lesend zugegriffen werden möchte, transparent eine Hilfsvariable einfügen, diese auslesen, und die Hilfsvariable am Ende des Programmes der entsprechenden Komponente zuweisen.
Dies wäre allerdings reine Kosmetik, als man als Programmierer selbstverständlich selbst Hilfsvariablen verwenden kann, soviel man will (ich glaube in HLSL wird dies allerdings so gehandhabt werden).

Mit SETH gibt es inzwischen einen Editor mit vielen eindrucksvollen Shadern für fxPascal, fehlt eigentlich nur noch die englische Dokumentation um die Bibliothek z.B. auf OpenGL.org präsentieren zu können.
Ach ja: für C/C++ Programmierer könnte man evtl. noch eine entsprechende DLL mit Importheader erstellen - normalerweise ist es ja eher anders herum (an sich müsste man ja nur CompileProgram exportieren, für die TStringList Klasse bräuchte man halt eine Alternative).

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

fxPascal ist für die arb_fp und arb_vp ausgelegt und sehr stark an diese Extensions angelehnt. Das sieht man z.B. auch daran daß man alle Variablen auf arb_vp und arb_fp benutzen kann. Für ältere Karten wie GF3/4 würde das mit den Register Combinern eventuell noch Sinn machen da die RC ja sehr weit verbreitet sind. Allerdings würde die Sprache nicht so recht zu den Combinern passen und es ist ja auch nicht möglich bei dieser Extension ohne Zusatz DLL die Parameter in Textform anzugeben. Für die Extension ATI_draw_buffers wurden nur die neuen Bezeichner hinzugefügt und sonst nichts geändert.
Ja du hast Recht wenn du die Arrays und den Results ansprichts. Eine Hochsprache sollte das eigentlich intern regeln. Der Hintergrund ist das Parameter und Konstanten Arrays auch in der ARB Version direkt existieren. Der Vollständigkeit halber gehört das aber noch rein.
Eine DLL wäre auch möglich aber eventuell besser wäre es statt der unit zu einer obj Datei zu kompilieren und die direkt in das C Programm zu linken. Der C Header könnte dann die Umsetzung der Liste vornehmen.
Das mit der englischen Dokumentation ist geplant aber natürlich auch zeitaufwändig und ich wollte deshalb erstmal die deutsche Version fertig stellen.
@Mars: Da du ja ohne Header kompilieren willst, kannst du trotzdem CompileProgram verwenden und den Header einfach davorhängen.

Stimmt - obwohl ich daran jetzt gar nicht gedacht habe. Indirekt profitieren ja auch die C/C++ Nutzer von Mcad von fxPascal, als halt das fxPascal Kompilat (sprich der Shaderassemblercode) in den entsprechenden Source eingefügt wird, anstelle des Pascalcodes (bzw. steht für die C/C++ Ausgabe die fxPascal Ausgabe nicht zur Verfügung, womit nur der ARB-Shaderassembler übrig bleibt - entwickeln kann man den Code ja dennoch mit dem integrierten fxPascal Editor ).

Dennoch würde eine DLL (oder obj) Sinn machen, als viele C/C++ Programmierer (unabhängig von Mcad) froh sein dürften, eine angenehme Alternative zum CG-Monster zu haben.
Dank Kylix müsste dies sogar unter Linux funktionieren - soweit ich sehe verwendest du ja nichts Win32 Spezifisches.

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

In der GLScene (http://www.glscene.org) NewsGroup ist jemand über FXPascal gestoßen und mittlerweile bekunden viele aus jener Community Interesse an einer Dokumentation auf Englisch. Da ich dort einer der wenigen Deutsch Sprechenden bin, habe ich erst einmal versucht, den Leuten einige (wenige!) Infos bereitzustellen...

Trotzdem sind viele an einer kompletten Englischen Dokumentation interessiert ... ließe sich da etwas machen? Kann ich den ganzen armen Programmierer in der Community Hoffnung machen?

Ein dickes "Respekt" an dieser Stelle von mir noch einmal zu dem Projekt!
FXPascal steht auf den vorderen Rängen meiner ToDo-Liste, dich ich abarbeiten werde, wenn ich wieder etwas mehr Freizeit finde. ^^

mfg
Sebastian

_________________
3D Rollenspiel-Hobbyprojekt von mir.
Guckst du hier:
http://ip-web.ath.cx/superstition/

Wenn da doch noch größeres Interesse besteht, werd ich das mal angehen. Ich werde heute auch noch die Kommandozeilenversion online stellen. Daran kann man die Benutzung auch schön erkennen.

Besten Dank!
Ich werde versuchen, auf dem Laufenden zu bleiben ...

_________________
3D Rollenspiel-Hobbyprojekt von mir.
Guckst du hier:
http://ip-web.ath.cx/superstition/

@"Fehler" in fxPascal,
da das Verhalten nur in {$optimize+} auftritt, ist es kein echter Fehler, vielmehr ist $optimize+ ein Feature - in der nächsten Caradversion wird einfach standardmäßig {$optimize-} gesetzt, und es fällt keinem auf (zumal die meisten Sachen auch in $optimize+ wunderschön kompiliert werden).

Im "Normalbetrieb" habe ich keinerlei Auffälligkeiten bemerkt - und das ist schon sehr viel mehr, als man von sämtlichen jetzigen GLslang Implementationen behaupten kann - jedenfalls ist es ein wirklich schönes Stück Code, das du da produziert hast.

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

Die Anzahl der Anweisungen ist bei diesem Shader bei beiden Einstellungen die gleiche. Es werden jeweils nur Variablen reduziert. Ich habe das bei dem einen Shader mal per Hand durchgeführt und haben den unoptimierten Shader als Ergebnis erhalten. Die Optimierungseinstellungen beziehen sich sowieso nur auf Optimierungen auf Assemblerebene. Auch im Fall von {$optimize-} werden Ausdrücke zusammengefaßt, aber jeweils nur für eine Anweisung.
Ich vermute den Fehler in der Lebendigkeitsanalyse. Das Problem ist das diese Optimierung sehr schwer zu testen ist. Anstelle überhaupt nicht mehr zu optimieren ist es daher sinnvoller in procedure TPascalShader.OptimizeCommandList; die Aufrufe zu OptimizeVarLiveTime (müßte eigentlich Life stat Live heißen) auszukommentieren und immer mit {$regcount+} zu kompilieren.

{$regcount+} sorgt dafür, daß die Register immer sofort wieder freigegeben werden, auch wenn der Wert später nochmal benötigt wird. Bei dem standardmäßigen {$regcount-} werden die Variablen gar nicht freigegeben und später mit der Lebendigkeitsanalyse alle reduziert. Dabei kann dann eine spätere Verwendung berücksichtigt werden. Im Fall von {$regcount-} gibt es daher ohne Optimierung sehr sehr viele Temp Variablen.{$regcount+} ohne Optimierung ist dagegen kein Problem.

Hmm, dann werde ich es so machen, dass man über eine Menüoption die Lebendigkeitsanalyse ausschalten kann (die wird dann über ein globales Flag gesteuert - ob ich es auskommentiere, oder mittels if.. Anweisungen steuere ist ja egal) und standardmäßig den von dir beschriebenen Fall (regcount+, optimize+) zu kompilieren, der in dem Fall den effizientesten Code ergeben müsste.

- eventuell würde es Sinn machen auch die Lebendigkeitsanalyse per Kompilerschalter aus- und einschalten zu können (Registerschalter $lifetimeanalysis+/-), dann könnte man ohne externes Framework, nur mit dem Source, mit den unterschiedlichen Kompilerausgaben experimentieren.

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/

Ich habe den Compilerbefehl {$lifetime+} {$lifetime-}hinzugefügt mit dem man die Lebendigkeitsanalyse von Variablen ein oder ausschalten kann. Standardmäßig bleibt sie eingeschaltet, da es sich ja hier nur um einen Fehler handelt und das doch seine Berechtigung hat. Das ist auch nicht ganz so schnell, da hier ein Interferenzgraph aufgebaut wird. Das suchen der optimalen Belegung entspricht dem Einfärben der Kanten mit verschiedenen Farben, unter der Bedingung, daß nie 2 gleiche Farben an einem Knoten hängen, und ist eins dieser np vollständigen Probleme. Falls man drauf verzichten möchte was eigentlich nie ein großes Problem ist, ist die alternative Einstellung mit fast identischem Code: {$regcount+} {$optimize+} {$lifetime-} Vielleicht setze ich das demnächst auch als Standardeinstellung. Es hat sich gezeigt, daß man gar nicht so viele Register vereinigen kann und gleichzeitig Zwischenergebnisse gut weiterverwenden kann. Die zweite Einstellung ist ein praktischer Kompromiß und für z.B. bei dem bump_vp.pas dazu, daß da Kreuprodukt nicht zweimal ausgerechnet wird, obwohl nicht speziell jedes Funktionsergebnis in einer anderen Variable vorgehalten wird.

Das musste ich jetzt mehrmals durchlesen, bis ich die Sache mit dem Interferenzgraphen verstanden habe .
Ich denke so ist es am Geschicktesten - nun hat man mehrere Möglichkeiten, von denen einige "garantiert" funktionieren, läuft der Shader erst mal, kann man dann versuchen mittels Lebendigkeitsanalyse das ganze etwas gleichmäßig auf die Register zu verteilen - so groß wird der Unterschied ohnehin nicht sein.
Wenn das immer noch nicht reicht, kann man versuchen, den Assemblercode händisch nachzuoptimieren, wobei fxPascal ohnehin weniger triviale Optimierungsmöglichkeiten übersieht, als man selbst .

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/