Ati stellt Rendermonkey vor

[askibo]

http://www.siggraph.org/s2002/conference/exhibit/index.html

ATI introduces RenderMonkey, a development tool designed to solve many of the problems encountered in writing and using real-time, programmable shaders on mainstream graphics hardware. This session provides tools for developers and animators to take advantage of next-generation shading hardware. In addition, Right Hemisphere, an ATI strategic partner, introduces various tools to take advantage of hardware shaders and demonstrates how users can efficiently share 3D content across a wide variety of media.

Auf genaueres müssen wir wohl noch ein paar Tage warten.


Aber "rendermonkey" klingt schon mal viel besser als "Cg" :D

[Quasar]

Na, da bin ich ja mal auf die Kommentare der "cg"-Skeptiker gespannt....

[StefanV]

siehe meine Kommentare zu cg...

[Ceiser Söze]

So, jetzt noch Matrox und alles ist wieder im Gleichgewicht :D
Wird hoffentlich darauf hinauslaufen, dass keine der Tools wirklich genutzt wird und die Entwickler stattdessen auf die "offizielle" DX9 HLSL von M$ und auf die Sprache von OpenGL 2.0 setzen werden...

[Exxtreme]

Originally posted by Ceiser Söze
Wird hoffentlich darauf hinauslaufen, dass keine der Tools wirklich genutzt wird und die Entwickler stattdessen auf die "offizielle" DX9 HLSL von M$ und auf die Sprache von OpenGL 2.0 setzen werden...
Und das wäre auch gut so. Ich glaube fast, daß ATi das Teil nur aus diesem Grund veröffentlicht hat, damit die Entwickler nicht auf das NV-Teil anspringen. Fehlt nur noch Matrox und die Macht ist wieder im Gleichgewicht.
;)

Gruß
Alex

[nggalai]

Hi there,

sieht für mich momentan nach einem Pissing-Contest aus. Und echt schade, wieviel Energie für das drauf geht . . . aber ich warte noch auf die Veröffentlichung des Papers; die Vorankündigung war doch eher mager.

ta,
-Sascha.rb

[Richthofen]

Nvidia wird sein CG Programm durchziehen darauf könnt ihr euch einstellen und die werden auch einige Entwickler dazu bringen das zu nutzen. Ist doch prima. Dann nutzen die ganzen Features evtl auf der GF4 mal was :)

[StefanV]

Originally posted by Richthofen
Nvidia wird sein CG Programm durchziehen darauf könnt ihr euch einstellen und die werden auch einige Entwickler dazu bringen das zu nutzen. Ist doch prima. Dann nutzen die ganzen Features evtl auf der GF4 mal was :)

Die Spiele Entwickler nutzen auch alle Intel Compiler, damit es aufm P4 so gut läuft...

[Pussycat]

Originally posted by Richthofen
Nvidia wird sein CG Programm durchziehen darauf könnt ihr euch einstellen und die werden auch einige Entwickler dazu bringen das zu nutzen. Ist doch prima. Dann nutzen die ganzen Features evtl auf der GF4 mal was :)

Hat die R200 ncht mehr features? Ist dann Rendermonkey nicht noch mehr wilkommen als Cg?

[HOT]

Originally posted by Richthofen
Nvidia wird sein CG Programm durchziehen darauf könnt ihr euch einstellen und die werden auch einige Entwickler dazu bringen das zu nutzen. Ist doch prima. Dann nutzen die ganzen Features evtl auf der GF4 mal was :)

NV kann sich da 2-3 Objekte Keisten, wie damals Gianst und evolva. Aber die Kracher werden 100% nicht in cg geschrieben. Spieleentwickler achten auf Hardwareunabhängigkeit, da das Business einfach zu schnellebig ist.

[Demirug]

@Pussycat:

Das wird davon abhängig sein in wie weit sich Rendermonkey mit NVIDIA und anderer Hardware verträgt. Cg kann man unter DX auch für ATi Chips nutzen allerdings ohne die zusätzlichen fähigkeiten der ATi.

@HOT:
Ich will dir nicht zu nahe treten aber das Konzept von Cg hast du dir nicht so genau angeschaut, oder? Unter DX ist Cg Hardwareneutral (auf dem kleinsten gemeinsamen Nenner). Sobald DX9 dann Final ist werden sich die Entwickler dann eben entscheiden müssen ob sie DX9-HSL, Cg, Rendermonkey oder was ganz anderes zur Shader programmierung benutzen.

Der Vorteil von Cg (und vielleicht auch Rendermonkey) gegenüber MS-HSL ist das es auch schon einen Runtimesupport für DX8 gibt.

[tb]

Originally posted by Ceiser Söze
So, jetzt noch Matrox und alles ist wieder im Gleichgewicht :D
Wird hoffentlich darauf hinauslaufen, dass keine der Tools wirklich genutzt wird und die Entwickler stattdessen auf die "offizielle" DX9 HLSL von M$ und auf die Sprache von OpenGL 2.0 setzen werden...

Ganz Deiner Meinung. Cg oder RenderMonkey machen nur Sinn, wenn man z.B. für die Xbox oder ne Konsole welche nen ATi GPU enthält, programmieren würde, da man dort wirklich nur für einen GPU optimieren muss/kann.

Thomas

[egdusp]

1. Irgendwo hab ich mal gelesen, dass es bereits vor Cg einige DX8 Shader Programme/Compiler/Sprachen gab. Warum haben sich diese nicht durchgesetzt, wenn bei DX9 doch alle auf diese Sprache warten? Mangelnde Qualität? Zu hohe Kosten? Miese Performance?

2. Wird es eigentlich möglich sein, auf DX9 HSL geschriebene Shaderprogramme von Cg/rm Compilern laufen zu lassen?
Oder wird DX9-HSL nur standard DX code abliefern, der für alle GraKa gemäß ihren Fähigkeiten gleich ist (PS 1.x/ VS 1.y), also z.B. spezielle nv/ati/ect.. Register oder caches unberücksichtigt läßt.

3. Eigentlich wäre es doch optimal, wenn die DX9-HSL nur die Syntax (den C-Code) vorgibt und die "Treiber" der GraKa den Assembler code compilieren. Also dass, was nVidia mit Cg will, nur dass eine einheitliche Basis besteht.

[Demirug]

Originally posted by egdusp
1. Irgendwo hab ich mal gelesen, dass es bereits vor Cg einige DX8 Shader Programme/Compiler/Sprachen gab. Warum haben sich diese nicht durchgesetzt, wenn bei DX9 doch alle auf diese Sprache warten? Mangelnde Qualität? Zu hohe Kosten? Miese Performance?


Die bisherigen DX-Tools die mir bekannt sind bauten alle auf der Assembler ähnliche Sprachen auf.


2. Wird es eigentlich möglich sein, auf DX9 HSL geschriebene Shaderprogramme von Cg/rm Compilern laufen zu lassen?
Oder wird DX9-HSL nur standard DX code abliefern, der für alle GraKa gemäß ihren Fähigkeiten gleich ist (PS 1.x/ VS 1.y), also z.B. spezielle nv/ati/ect.. Register oder caches unberücksichtigt läßt.


Was die Compatibilität der Sprachen zueinader angeht kann wohl wirklich noch niemand so genau sagen wie weit das geht. Was das DX9 HSL angeht darf ich leider nicht viel sagen. Bereist allgemein bekannt ist das es ein Programm gibt was aus einer C ähnlichen sprache entsprechende DX Shaderprogramme erzeugt. Also hardware unabhängig.


3. Eigentlich wäre es doch optimal, wenn die DX9-HSL nur die Syntax (den C-Code) vorgibt und die "Treiber" der GraKa den Assembler code compilieren. Also dass, was nVidia mit Cg will, nur dass eine einheitliche Basis besteht.

Im Prinzip wäre das die beste Lösung würde aber die Treiberentwicklung noch komplizierter machen. Der Weg über den Assemblercode ist aber auch nicht so schlecht da der Treiber ja immer noch die möglichkeit hat auf dieser Ebene zu optimieren.

Was Cg angeht so erzeugt man damit für DX auch nur Shaderprogramme die auf jeder Hardware die den entsprechenden Shaderlevel unterstützt auch lauffähig sind.

[Pitchfork]

Originally posted by egdusp
1. Irgendwo hab ich mal gelesen, dass es bereits vor Cg einige DX8 Shader Programme/Compiler/Sprachen gab. Warum haben sich diese nicht durchgesetzt, wenn bei DX9 doch alle auf diese Sprache warten? Mangelnde Qualität? Zu hohe Kosten? Miese Performance?


Stanford Shading Project. Compiliert Shader noch runter auf Singletexturing, wenns sein muß. War wohl einer der Wegbereiter der Echtzeithighlevelshadinglanguages (*bg*), über praktische Relevanz weiß ich leider nichts...


2. Wird es eigentlich möglich sein, auf DX9 HSL geschriebene Shaderprogramme von Cg/rm Compilern laufen zu lassen?
Oder wird DX9-HSL nur standard DX code abliefern, der für alle GraKa gemäß ihren Fähigkeiten gleich ist (PS 1.x/ VS 1.y), also z.B. spezielle nv/ati/ect.. Register oder caches unberücksichtigt läßt.

Bei DX gibt es nur einen Zugang zu den Shadern und das sind die Assemblerversionen (PS1.1-1.4/2.0, VS1.1/2.0). Es gibt bei Pixelshadern nur den Umfang des Wertebereichs als Unterschied und bei Vertexshadern nur die Größe des Konstantenbereichs. Ich *denke* mal, daß DX HSL im Gegensatz zu Cg die unterschiedlich großen Konstantenbereiche bei VS1.1 berücksichtigt, aber sicher bin ich mir da nicht. Ansonsten ist es unter DX wohl scheißegal, ob man DX HSL oder Cg HSL Shader benutzt, solange die Syntax übereinstimmt. Zugang zu speziellen Hardwareeigenschaften bekommt man nicht!

3. Eigentlich wäre es doch optimal, wenn die DX9-HSL nur die Syntax (den C-Code) vorgibt und die "Treiber" der GraKa den Assembler code compilieren. Also dass, was nVidia mit Cg will, nur dass eine einheitliche Basis besteht.
Jeder Compiler erzeugt erstmal eine interne Repräsentation des Codes (Frontend) bevor er optimiert (Backend). Da die DX Assemblersprache (bis auf seltsame PS1.1-1.3 Texturoperationen *g*) sehr einfach strukturiert ist, ist das sowieso der bessere Bereich für Optimizerläufe!

Pitchfork

[aths]

Originally posted by Richthofen
Nvidia wird sein CG Programm durchziehen darauf könnt ihr euch einstellen und die werden auch einige Entwickler dazu bringen das zu nutzen. Ist doch prima. Dann nutzen die ganzen Features evtl auf der GF4 mal was :) Leider nein, da Cg nur PixelShader 1.1 unterstützt (und später noch PS.2.0), PixelShader 1.3 (also "GF4-Feature") wird von Cg leider nicht unterstützt.

[Demirug]

Beta 0.5 jetzt verfügbar:

http://mirror.ati.com/developer/sdk/radeonSDK/html/Tools/RenderMonkey.html

[Hauwech]

Originally posted by aths
Leider nein, da Cg nur PixelShader 1.1 unterstützt (und später noch PS.2.0), PixelShader 1.3 (also "GF4-Feature") wird von Cg leider nicht unterstützt.

Also ist Cg nur dafuer gedacht die Programmierung einfacher zu machen beim kleinst moeglichen Nenner, richtig? Erst wenn sagen wir mal 70% aller installierten Grakas PS 1.3 beherrschen wird dann Cg in einer neuen Version ausgeliefert?
Oder gibt es schon entsprechende *Extensions* so das die Programmierer jetzt schon PS 1.3 damit hmm 'benutzen' koennen und das Ergebnis dann als Option einbauen 'koennten'? Waere zumindest fuer NV bloed wenn die ihre aktuellen Chips (zumindest die 'richtigen' GF4's)nicht beruecksichtigen.
Kann mir vorstellen das aths, Demi und viele andere sich schon mal Cg angeschaut haben. Wieviel Zeit kann man denn damit einsparen?

Das gleiche gilt natuerlich fuer Rendermonkey von ATI.

[aths]

Cg supportet PS.1.1, und wird später auch 2.0 unterstützen. Support für 1.3 wird von nVidia nicht mitgeliefert, ist aber angeblich irgendwie nachrüstbar.

Für PixelShader 2.0 ist eine HLSL schon recht praktisch. Bei DX8-Shadern wage ich zu bezweifeln, dass man mit Cg wirklich Zeit spart.

[Demirug]

Mit der Opensource Version von Cg kann man im Prinzip für jedes gewünschte Profil (PS x.x, VS x.x, OpenGL, XBox, usw) einen passenden Compiler bauen.

Bei den Vertexshader macht Cg auch schon bei DX8 sinn. Bei den PS 1.1 spart man erst mal keine Zeit. Der Vorteil ist nur das man den in Cg geschriebehnen Effekt einfach nochmal durch den Compieler jagt und dann ein PS 2.0 Programm hat.

Aber in dem Thread geht es ja primär um Rendermonkey. Die 0.5 Beta konnte mich bisher nicht wirklich überzeugen.

[Xmas]

Hm, RefRast rult ;)

[Demirug]

Ja die Beispiele sind alle nur R8500 tauglich.

[aths]

Originally posted by Demirug
Ja die Beispiele sind alle nur R8500 tauglich. Einiges läuft auch mit PS.1.3-er (wohl auch 1.1-er) Hardware, ansonsten bleibt, wie Xmas schon sagte, immer noch der Ref :)

[Pitchfork]

Also ich habe mir das Ding mal angeschaut, und ich muß sagen, es sieht verdammt gut aus fürs Prototyping. Wie es sich bei einer Engineintegration verhält, weiß ich nicht, aber um mal ein paar Effekte auszuprobieren, scheint es alles wesentliche mitzubringen und auch gut genug anpaßbar zu sein.
Was besseres in der Richtung ist mir bisher nicht untergekommen!

[Demirug]

aths: hab jetzt auch ein paar PS 1.1 Beispiele gefunden.

Pitchfork: Zum rumspielen ist es wirklich nicht schlecht. Da es aber mehr ein Art Tool ist sollte es als Plugin in Maya, Max usw. integriert sein. So ist es einfach zu umständlich.

Eine Engineintegration ist defakto nicht vorhanden. Das einzige was möglich wäre ist das Laden der Projektfiles und den Inhalt auszuwerten. In diesem Fall müsste man aber einen komplett neuen Effectframework schreiben. Zum anderen ist das Dateiformat für den Endkundeneinsatz eher unbrauchbar.

Und dann bleibt noch die Frage wo die ganzen schönen Features von denen im Vorfeld gesprochen wurden geblieben sind?

[Pitchfork]

Originally posted by Demirug
aths: hab jetzt auch ein paar PS 1.1 Beispiele gefunden.

Pitchfork: Zum rumspielen ist es wirklich nicht schlecht. Da es aber mehr ein Art Tool ist sollte es als Plugin in Maya, Max usw. integriert sein. So ist es einfach zu umständlich.

Eine Engineintegration ist defakto nicht vorhanden. Das einzige was möglich wäre ist das Laden der Projektfiles und den Inhalt auszuwerten. In diesem Fall müsste man aber einen komplett neuen Effectframework schreiben. Zum anderen ist das Dateiformat für den Endkundeneinsatz eher unbrauchbar.

Und dann bleibt noch die Frage wo die ganzen schönen Features von denen im Vorfeld gesprochen wurden geblieben sind?


Das Tool hier ist für Effektautoren. Mittels eines Frameworks könnte ein Plugin in Max/Maya die Artistparameter einstellbar machen.
Engineintegration ist immer etwas heavy, weil die meisten Engineentwickler sich in einem solchen Kernbereich nicht gerne ein externes Framework vorschreiben lassen. Die einzige Ausnahme dürfte am Ende DX3D Effektfiles sein.
Beta 0.5.
Ich habe mich jetzt erstmal drüber gefreut, daß es endlich ein gutes Interaktives Tool gibt, um Shader zu entwerfen. Den resultierenden Code kann man dann in die eigentliche Engine schnell übernehmen.
Ehrlich gesagt, finde ich das Fileformat gar nicht so übel. Schnell mit DOM oder SAX geparset, selbsterklärend, man braucht also nicht unbedingt ne fette DLL von ATI, um die Daten auch direkt übernehmen zu können (auch wenn es helfen würde, eine zu haben).


Yep, das ist der Anfang einer Entwicklung, die ca. 18 Monate dauert, und dann werden Shader genauso selbstverständlich wie Texturen oder Meshes.

Pitchfork

[Demirug]

"Das Tool hier ist für Effektautoren. Mittels eines Frameworks könnte ein Plugin in Max/Maya die Artistparameter einstellbar machen."

Wäre als zwischenlösung durchaus annehmbar

"Engineintegration ist immer etwas heavy, weil die meisten Engineentwickler sich in einem solchen Kernbereich nicht gerne ein externes Framework vorschreiben lassen. Die einzige Ausnahme dürfte am Ende DX3D Effektfiles sein."

So toll sind die DX3D effektfiles IMO leider auch nicht. Die Cg runtime ist damit durchaus vergleichbar

"Ich habe mich jetzt erstmal drüber gefreut, daß es endlich ein gutes Interaktives Tool gibt, um Shader zu entwerfen. Den resultierenden Code kann man dann in die eigentliche Engine schnell übernehmen."

Welchen Code? Ich will definitive keine Effekte direkt im Programmcode haben.

"Ehrlich gesagt, finde ich das Fileformat gar nicht so übel. Schnell mit DOM oder SAX geparset, selbsterklärend, man braucht also nicht unbedingt ne fette DLL von ATI, um die Daten auch direkt übernehmen zu können (auch wenn es helfen würde, eine zu haben)."

Das Format ist im Produktionsbreich durchaus brauchbar nur auf den Goldmaster würde ich sowas nicht packen.

"Yep, das ist der Anfang einer Entwicklung, die ca. 18 Monate dauert, und dann werden Shader genauso selbstverständlich wie Texturen oder Meshes."

Früher oder später wird es so kommen. Ob allerdings 18 Monate ausreichen werden mag ich wirklich nicht zu sagen.

[Pitchfork]

Originally posted by Demirug
"Das Tool hier ist für Effektautoren. Mittels eines Frameworks könnte ein Plugin in Max/Maya die Artistparameter einstellbar machen."

Wäre als zwischenlösung durchaus annehmbar

Wäre=ist. Wobei für special effekte wohl immer noch der umgebende Code angepaßt werden muß (also die C++ Seite).

"Engineintegration ist immer etwas heavy, weil die meisten Engineentwickler sich in einem solchen Kernbereich nicht gerne ein externes Framework vorschreiben lassen. Die einzige Ausnahme dürfte am Ende DX3D Effektfiles sein."

So toll sind die DX3D effektfiles IMO leider auch nicht. Die Cg runtime ist damit durchaus vergleichbar

Cg Runtime ist mit Effektfiles nicht zu vergleichen, weil zumindest die bisherige (Beta1, Beta2 habe ich noch nicht gesaugt) ja nur Shader spricht. Und Effektfiles vor allen Dingen Effekte, Techniken und Passes transparent zusammenführt und die gesamte Verwaltung übernimmt. Und in DX9 wird die Technik noch weitergeführt und verfeinert (und wahrscheinlich auch verwendbar für Spiele).

"Ich habe mich jetzt erstmal drüber gefreut, daß es endlich ein gutes Interaktives Tool gibt, um Shader zu entwerfen. Den resultierenden Code kann man dann in die eigentliche Engine schnell übernehmen."

Welchen Code? Ich will definitive keine Effekte direkt im Programmcode haben.

Schlecht ausgedrück: in das System, was in der Engine zum Einsatz kommt. Seien es Effektfiles eigener Machart, VS und PS Dateien etc.pp.

"Ehrlich gesagt, finde ich das Fileformat gar nicht so übel. Schnell mit DOM oder SAX geparset, selbsterklärend, man braucht also nicht unbedingt ne fette DLL von ATI, um die Daten auch direkt übernehmen zu können (auch wenn es helfen würde, eine zu haben)."

Das Format ist im Produktionsbreich durchaus brauchbar nur auf den Goldmaster würde ich sowas nicht packen.

Das kleinste Problem, oder? Und welche Engine hat keine Pak Files wo das keine Rolle mehr spielt, ob Teile des Contents in ASCII vorliegen? Könnte man ja eher im MOD Bereich positiv ansehen, so daß Modder eigene Materialien schnell hinzufügen können.

"Yep, das ist der Anfang einer Entwicklung, die ca. 18 Monate dauert, und dann werden Shader genauso selbstverständlich wie Texturen oder Meshes."

Früher oder später wird es so kommen. Ob allerdings 18 Monate ausreichen werden mag ich wirklich nicht zu sagen.

Pitchfork