ATi und 3DLabs Allianz gegen nVidias CG ?

[Salvee]

ATI and 3Dlabs announce collaboration to accelerate advancement of shaders

ATI Technologies, Inc. and 3Dlabs, Inc. Ltd., a wholly-owned subsidiary of Creative Technology Ltd., today announced a cooperative
initiative to accelerate the development of the RenderMonkey shader development tool suite, which is available free of charge
from both ATI and 3Dlabs. Under the terms of this agreement, ATI will continue to evolve the core RenderMonkey framework, and both
companies will develop plug-in modules that support the industry standard Microsoft DirectX HLSL and OpenGL 2.0 GLslang high-level shading languages. RenderMonkey will be distributed, free of charge, by both companies.
The latest generation of programmable graphics devices – called Visual Processing Units (VPUs) – is creating the biggest revolution
in graphics architecture in over a decade. VPUs can be programmed to undertake sophisticated cinematic quality graphics rendering
as well as general-purpose imaging, graphics and vector processing. High-level shading languages will be the preferred way for ISVs
to program these powerful devices – but there will need to be a new generation of tools to enable programmers to code, visualize,
debug and manage shader programs.
RenderMonkey is a hardware-independent tool suite created to advance the development and use of shader programs in 3D applications.
It is currently being used by game developers and content creators to speed their shader development.
ATI and 3Dlabs will work together to further develop RenderMonkey, and work closely with tool vendors to integrate
RenderMonkey functionality into digital content creation applications.
“Industry standard shading languages and flexible, developer-friendly toolsets are the key enablers of the cinematic revolution,” said Rick Bergman,
Senior Vice President of Marketing and General Manager, Desktop, ATI Technologies Inc.
“ATI initiated the development of RenderMonkey to ensure that software developers and content creators are able to fully realize the potential
of our cinematic VPUs. We are delighted that 3Dlabs shares our vision and philosophy of working collaboratively with the industry
through non-proprietary initiatives.” “3Dlabs and ATI both believe that industry standards and cooperation are the most efficient way
to cultivate and develop the necessary industry infrastructure and market opportunities for next generation programmable VPUs,”
said Neil Trevett, Senior Vice President Market Development, 3Dlabs, Inc. “We applaud ATI for creating RenderMonkey and look forward to
working together to provide a sophisticated, hardware independent development environment used to catalyze
the widespread deployment of DirectX and OpenGL shaders.”


Alles nur PR-Geschreibsel oder kann sich nV zukünftig die Kosten und Mühen für CG sparen ?

Falls es nichts in diesem Forum verloren hat, weg damit :) )

[Demirug]

Ich habe das ganze mal nach Technologie verschoben. Passt dort etwas besser.

Bei RenderMonkey handelt es sich ja um einen Framework zum entwickeln von Shadern. Bei Cg um eine Shaderprogrammiersprache. Es ist also ein Apfel und Birne Vergleich.

HLSL und GLslang sind beides recht gute Shadersprachen (IMO geht das aber alles nicht weit genug) haben aber den Nachteil das sie DX only (HLSL) bzw OpenGL 2.0 only (gslang) sind. Der Cg Compiler hat Zielprofile für DX und OpenGL 1.x (NVIDIA spezifische und allgemeine). Wenn man also plant eine multi API Engine zu schreiben ist Cg derzeit die beste wahl. Da Cg sich zudem sehr kompatibel zur HLSL zeigt (Cg scheint eine genauerer typenprüfung zu haben) bekommt man fast jeden HLSL Shader auch problemloss mit Cg compiliert. Bei meinen Tests war dabei der CG Compiler mindestens genauso gut oder besser als der MS-Compiler was die ergebnisse angeht. Ich muss den Test aber mit den jeweils neusten Versionen der Compiler noch mal wiederholen.

IMO hat Cg also durchaus noch eine Berechtigung

Was mir an RenderMonkey derzeit noch fehlt ist eine Integration in die Design Tools (3d Max, Maya, ...) und die Möglichkeit die mit RenderMonkey erstelten Effekte im DX Effekt File Format abzuspeichern. Alternative könnte ich auch mit einem eigenen Format und einer entsprechenden Runtime leben. Im Moment läst sich RenderMonkey leider nicht gut in den Workflow einbauen.

[Salvee]

Originally posted by Demirug
Wenn man also plant eine multi API Engine zu schreiben ist Cg derzeit die beste wahl.

Kann es sein, dass es in jüngster zeit eigentlich kaum noch Multi API Games gibt? Vor einiger Zeit hatten doch etliche Games mehr OpenGL Support, aktuell fällt mir nur UT2003 ein (und da ist OGL ja fast schon inoffiziell).

Originally posted by Demirug
Bei meinen Tests war dabei der CG Compiler mindestens genauso gut oder besser als der MS-Compiler was die ergebnisse angeht. Ich muss den Test aber mit den jeweils neusten Versionen der Compiler noch mal wiederholen.


Ist schon eine starke Leistung seitens nV, dass ihr Compiler bessere Ergebnisse liefert als der von M$, obwohl die eigentlich mehr Ahnung von DirectX haben müssten ;) Bezieht sich das 'Besser' eigentlich nur auf nV-Hardware, oder auch auf eure 9500 (falls die schon eingetroffen ist)?
Irgendwie habe ich das Gefühl, dass nV sich langsam mehr zu einer Software- denn zu einer Hardwarefirma entwickelt ...^^

Originally posted by Demirug
Was mir an RenderMonkey derzeit noch fehlt ist eine Integration in die Design Tools (3d Max, Maya, ...) und die Möglichkeit die mit RenderMonkey erstelten Effekte im DX Effekt File Format abzuspeichern.

Zumindest an der Integration in die digital content creation applications scheinen sie ja jetzt zu arbeiten.

[Sphinx]

IMO hat Cg also durchaus noch eine Berechtigung




*** Niemals ***

Gründe gibts viele wenn man zwischen den Zeilen liest...
Und das mein ich ernst.

Würden alle Spieleentwickler auf dieses Pferd setzen währe es fatal... Für alle.

[x-dragon]

Originally posted by Sphinx
IMO hat Cg also durchaus noch eine Berechtigung




*** Niemals ***

Gründe gibts viele wenn man zwischen den Zeilen liest...
Und das mein ich ernst.

Würden alle Spieleentwickler auf dieses Pferd setzen währe es fatal... Für alle. Eine nähere Erläuterung wäre nicht schlecht, zwischen den Zeilen lesen ist nicht unbedingt jedermanns Sache :).
Auch wenn es an sich klar ist, das damit natürlich in erster Linie für Nvidia-Karten optimiert wird.

[ow]

Originally posted by X-Dragon
Auch wenn es an sich klar ist, das damit natürlich in erster Linie für Nvidia-Karten optimiert wird.

Nein, cg ist unabhängig von irgendwelchen Chips. Man kann damit genausogut auf ATi optimieren wie auf NV oder sonstige.

cg wird imo DAS Entwicklungstool für kommende Games sein und das ist auch gut so. MS-Kompiler haben noch nie viel getaugt.:D

[Demirug]

Originally posted by Salvee
Kann es sein, dass es in jüngster zeit eigentlich kaum noch Multi API Games gibt? Vor einiger Zeit hatten doch etliche Games mehr OpenGL Support, aktuell fällt mir nur UT2003 ein (und da ist OGL ja fast schon inoffiziell).

Ja bei den "grossen" Engines wird kaum noch auf Multi-API gesetzt. Die gründe dafür sind recht einfach. Moderne Engines brauchen Shadersupport oder besser gesagt die Shader stellen den zentralen Teil dar. Multitexturing ala DX7 war noch relative einfach sowohl auf DX wie auch auf OpenGL oder sonst eine API (Konsolen) abzubilden. Aber bei den Shader wird das ohne das man sich selbst eine neue Shadersprache ausdenkt die sich sowohl auf DX wie auch auf OpenGL umsetzten läst schon etwas kompliziert.

Im Hobby und semi profesionellen Bereich gibt es durchaus noch ein paar Engines die beides können. Allerdings sieht es da mit Shader recht schwach aus. Ich kenne nur einen Ausnahme und die baut auf Cg auf.

Ist schon eine starke Leistung seitens nV, dass ihr Compiler bessere Ergebnisse liefert als der von M$, obwohl die eigentlich mehr Ahnung von DirectX haben müssten ;) Bezieht sich das 'Besser' eigentlich nur auf nV-Hardware, oder auch auf eure 9500 (falls die schon eingetroffen ist)?
Irgendwie habe ich das Gefühl, dass nV sich langsam mehr zu einer Software- denn zu einer Hardwarefirma entwickelt ...^^

Ich habe die Shader nicht gebencht (macht bei dem vielen Debugcode den ich im Moment in der Engine habe sowieso nicht viel Sinn). Ich habe lediglich die erzeugten Shader disassembliert und verglichen und der Cg Compiler hat dabei öfter mal Code erzeugt der weniger Instructionsslots als das Ergebniss des HLSL Compiler braucht. Und bei Shader gilt in Regel immer: weniger Slots = schneller.

[Demirug]

Originally posted by ow


Nein, cg ist unabhängig von irgendwelchen Chips. Man kann damit genausogut auf ATi optimieren wie auf NV oder sonstige.

cg wird imo DAS Entwicklungstool für kommende Games sein und das ist auch gut so. MS-Kompiler haben noch nie viel getaugt.:D

Cg hat leider kein PS 1.4 Profil und im Moment habe ich auch noch etwas Probleme den Cg Compiler richtig in unsere Engine einzupassen weil ich nur den Compiler aber nicht den Effektframework (CgFX) will.

Da ich aber den HLSL und Cg Compiler parrallel benutzten kann könnte ich sogar jeweils beide Compieler darauf ansetzten und mir jeweils das bessere Ergebniss nehmen. Bisher war es aber immer unentscheiden oder pro Cg. Ausser bei den PS 1.4 die ich nur über den HLSL laufen lassen kann.

[Desti]

Wer was zu glslang lesen will :)


http://www.opengl.org/developers/documentation/gl2_workgroup/ShaderSpecV1.05.pdf

[x-dragon]

Originally posted by ow


Nein, cg ist unabhängig von irgendwelchen Chips. Man kann damit genausogut auf ATi optimieren wie auf NV oder sonstige.

cg wird imo DAS Entwicklungstool für kommende Games sein und das ist auch gut so. MS-Kompiler haben noch nie viel getaugt.:D Achso, dann habe ich wohl da:
Originally posted by ow
... Der Cg Compiler hat Zielprofile für DX und OpenGL 1.x (NVIDIA spezifische und allgemeine). ... zuviel reininterpretiert :).

[ow]

Originally posted by X-Dragon
Achso, dann habe ich wohl da:
zuviel reininterpretiert :).


Soweit ich das seinerzeit verstanden habe ist Cg modular aufgebaut und durch entsprechende Plug-ins erweiterbar.

Wie Demirug oben schon sagte, fehlt derzeit aber die Möglichkeit PS1.4 mit Cg zu erzeugen. Von NV erwarte ich da auch keine Erweiterung für Cg, da ist dann schon eher ATi gefragt, ein solches Plugin zu entwickeln.
Ob ATi das tun wird ist ungewiss, die werden imo eher ganz auf HLSL setzen.

Auch für OGL unter Cg müsste ATi schon selbst das Plugin für seine Extensions (GL_ATI_...) schreiben.

[Demirug]

Ja jeder der möchte kann eigene Profile schreiben. Diese werden in Form von DLLs eingebunden. ATI setzt aber voll auf HLSL von MS. Bei Direkt X ist das auch nicht so schlimm man kann ja trotzdem (mit ausnahme von PS 1.4) den Cg Compiler benutzten und bekommt shader die ohne probleme auf den ATI Chips laufen.

Unter OpenGL fehlt leider eine möglichkeit für den R200 (und derivate) Pixelshader aus einer Hochsprache zu erzeugen. Gerade dort würde man aber viel mehr davon profitieren als bei den NV2x Chips.

[Sphinx]

CG ist für´n ARSCH weil..

http://www.elite-marines.com/gallery/root/1/Bild2.jpg

[zeckensack]

Interessant :|

Bei mir läuft das Cg-Toolkit, und zwar auf 'ner Radeon 8500.
Außerdem, die genannten Extensions sind bis auf 'NV_primitive_restart' bereits ab Geforce 1 verfügbar - Vertex Shader nur in Software-Emu, aber immerhin. (edit: ist falsch, siehe unten)

Vielleicht hast du einfach das falsche Paket runtergeladen. Das sieht mir nach einer Variante aus, für die du eine FX haben, oder die entsprechenden Emulationstreiber benutzen mußt.

[Demirug]

Sphinx, wenn man einen Shader mit einem NV30 only Profil compiliert läuft es auch nur mit einer Karte welche die NV30 Extension (bzw Caps bei DX) zur verfügung stellt. Ich kann man HLSL auch einen Shader für PS 1.4 compilieren und mich dann beschweren das er nicht auf einer GF4 läuft. Das gleiche Spiel funktioniert auch mit einem 2.0+ Shader als Ziel. Dann heist es für R300 Karten wir müssen drausen bleiben.

Meine persönliche Entscheidung ist eben das ich beides HLSL und Cg benutzten werden sollange der Quellcode identisch bleibt. Welchen der beiden Compiler ich dann allerdings per Default für nicht NVIDIA Karten einsetze weiss ich noch nicht zu 100%. Im Moment sieht es aber so aus das ich vorzugsweise den Cg Compiler benutzen (aussnahme PS 1.4 für R200 und derivate) weil er derzeit den kompakteren Code erzeugt.

@zeckensack: NV_fragment_program ist aber auch neu.

[zeckensack]

Stimmt :)
edit: Und NV_register_combiner2 gibt's auch erst ab Geforce3 (mehr Konstanten).
Mein Fehler ;)

[ow]

Originally posted by Sphinx
CG ist für´n ARSCH weil..



....du vielleicht einfach nicht in der Lage bist es zu bedienen, kann das sein?

[aths]

Originally posted by ow
cg wird imo DAS Entwicklungstool für kommende Games sein und das ist auch gut so. MS-Kompiler haben noch nie viel getaugt.:D Woher nimmst du diese Weisheit?

Es ist doch ein offenes Geheimnis, dass Cg vor allem zum nV-Marketingfeldzug für "CineFX" da ist, bzw. Entwickler (fester) an nV-Hardware binden soll.

[Demirug]

Originally posted by aths
Woher nimmst du diese Weisheit?

Es ist doch ein offenes Geheimnis, dass Cg vor allem zum nV-Marketingfeldzug für "CineFX" da ist, bzw. Entwickler (fester) an nV-Hardware binden soll.

Das mag ja alles stimmen. Aber es fehlt nun mal eine gute Alternative.

[ow]

Originally posted by Demirug


Das mag ja alles stimmen. Aber es fehlt nun mal eine gute Alternative.


Eben. ATi und Matrox scheinen ja die Ärsche nicht hochzukriegen, um sowas zu entwickeln.

Und MS-Kompiler.......in der aktuellen c't haben sie mal C++ Kompiler von MS und Intel verglichen. Man lese es nach, um wieviel Intel MS da voraus ist.
Ich traue NV durchaus zu, den besseren Shader-Kompiler zu entwickeln als MS.

Und von Chipbindung kann bei Cg ja keine Rede sein.

[Desti]

Originally posted by Demirug


Das mag ja alles stimmen. Aber es fehlt nun mal eine gute Alternative.


hmm...JC nutzt doch nen eigenes Programm oder?

[Demirug]

Originally posted by Desti



hmm...JC nutzt doch nen eigenes Programm oder?

Du meinst für DOOM III?

Falls ja. DOOM III benutzt soweit mir bekannt einen Art scriptbares Multitexture System. Von einer Hochsprache ist das noch ein stück weg.

Füe seine nächste Engine möchte er eine richtige Shaderhochsprache benutzten.

[Legolas]

Originally posted by Demirug


Du meinst für DOOM III?

Falls ja. DOOM III benutzt soweit mir bekannt einen Art scriptbares Multitexture System. Von einer Hochsprache ist das noch ein stück weg.


Wir wohl eine Weiterentwicklung der 'Shadersprache' der Quake III Engine sein.

[Demirug]

Originally posted by Legolas


Wir wohl eine Weiterentwicklung der 'Shadersprache' der Quake III Engine sein.

Ja so schaut das ganze aus. Die Erweiterung sind im wesentliche für das Bumpmapping.

[aths]

Originally posted by ow
Eben. ATi und Matrox scheinen ja die Ärsche nicht hochzukriegen, um sowas zu entwickeln.Wozu auch, wenn man HLSL bzw. GLSlang hat?
Originally posted by ow
Und MS-Kompiler.......in der aktuellen c't haben sie mal C++ Kompiler von MS und Intel verglichen. Man lese es nach, um wieviel Intel MS da voraus ist.
Ich traue NV durchaus zu, den besseren Shader-Kompiler zu entwickeln als MS.Darf ich fragen, wieviel C++ bzw. Cg du kannst?

[Richthofen]

"
Wozu auch, wenn man HLSL bzw. GLSlang hat?
"

Das dürften sie recht bald merken. Ich sag nur "the way it's meant to be played"

Die Software ist der Schlüssel zur erfolgreichen Hardware. Bei Nvidias ausgesprochen guten Beziehungen zu den Entwicklern, dürfte CG mehr zum tragen kommen als das anderen gefallen kann.

[Salvee]

Und deswegen wird ausser nV niemand jemals Cg supporten.
ATi wird auf keinsten Fall ein spezifisches R200/R300 Plugin dafür basteln, weil sie sonst indirekt nV in die Ärmchen spielen.

Sorry, das Bild passt hier so 'schön' ;)
(stammt aus einem zugegebenermassen miesen Test)

http://www.3dvelocity.com/reviews/gffx5800u/gffx_9.htm

http://www.3dvelocity.com/reviews/gffx5800u/screenshots/meant_to_be_played.jpg

[Demirug]

Originally posted by Salvee
Und deswegen wird ausser nV niemand jemals Cg supporten.
ATi wird auf keinsten Fall ein spezifisches R200/R300 Plugin dafür basteln, weil sie sonst indirekt nV in die Ärmchen spielen.

Für Profile die Cg nicht unterstützt nimmt man dan eben den MS-HLSL Compiler. Die Syntax der beiden Sprachen ist sowieso identisch. Und da GLslang vom syntax auch nicht so weit weg ist wird sicherlich jemand einen Cross-Compiler dafür schreiben.

[betasilie]

Ich hoffe, dass sich HLSL etablieren wird, denn dieser Versuch von NV eine eigene S-Hochsprache bei den Entwicklern zu installieren gefällt mir irgendwie nicht.

[Demirug]

Originally posted by betareverse
Ich hoffe, dass sich HLSL etablieren wird, denn dieser Versuch von NV eine eigene S-Hochsprache bei den Entwicklern zu installieren gefällt mir irgendwie nicht.

Cg ist kompatibel mit HLSL. Das ist genauso wie wenn man zwei C Ompiler hat. Der HLSL Compiler kann dabei nur für die DX Seite Shader aus dem Hochsprachencode erzeugen. Der Cg Compiler beherscht sowohl die Erzeugung von DX wie auch OpenGL Shader.

Der eigentliche Unterschied beginnt erst wenn man den jeweiligen Effektframework einsetzt. Aber das muss man ja nicht tun.

[betasilie]

Interssant ist, dass Cg auch OGL Shader erzeugen kann. Das will MS wohl nicht? Ist Cg denn aus HLSL entstanden oder andersherum? ... Oder ist eine ganz andere Sprache Grundlage der beiden gewesen?

[zeckensack]

Originally posted by betareverse
Interssant ist, dass Cg auch OGL Shader erzeugen kann. Das will MS wohl nicht?Eben deswegen finde ich daß Cg wesentlich mehr Daseinsberechtigung hat als MS' HLSL.

edit: Wenn man schon Angst vor einem Shadersprachen-'Monopol' durch NVIDIA hat, dann sollte man wenigstens versuchen, MS nicht als die Lösung solcher Ängste zu sehen. Historisch betrachtet der völlig falsche Gedankengang.

[Demirug]

Originally posted by zeckensack
Eben deswegen finde ich daß Cg wesentlich mehr Daseinsberechtigung hat als MS' HLSL.

edit: Wenn man schon Angst vor einem Shadersprachen-'Monopol' durch NVIDIA hat, dann sollte man wenigstens versuchen, MS nicht als die Lösung solcher Ängste zu sehen. Historisch betrachtet der völlig falsche Gedankengang.



im Moement heist es ja sowieso MS und NVIDIA gegen 3dLabs. Cg und HLSL ist ja eigentlich nur eine Sprache. Da MS ja seine OpenGL Aktivitäten einstellt und der HLSL Compiler teil des DX SDKs ist macht es nicht viel Sinn für MS mit diesem Compiler auch OpenGL Shader zu erzeugen. Also überlässt man das dem Partner NVIDIA. Und glaub mir die Cg und HLSL Jungs kennen sich sehr gut da sie recht eng zusammen arbeiten.

[Richthofen]

"
Interssant ist, dass Cg auch OGL Shader erzeugen kann. Das will MS wohl nicht? Ist Cg denn aus HLSL entstanden oder andersherum? ... Oder ist eine ganz andere Sprache Grundlage der beiden gewesen?
"

Sagen wir mal so. Das war der Deal. MS hat ne x-box mit NV Hardware zu verkaufen und historisch gesehen bietet Nvidia einen sehr guten Entwicklersupport und gute Dokumentation.
Ist doch recht naheliegend, dass auch CG x-Box Spieleentwicklern helfen könnte.
Da nimmt man dann in Kauf, dass CG für den PC auch auf OGL portieren kann, was ja eigentlich MS nicht gefallen dürfte.

Da sie aber CG abgenickt haben, nehme ich mal an dass des abgemachte Sache ist.

"
Und deswegen wird ausser nV niemand jemals Cg supporten.
ATi wird auf keinsten Fall ein spezifisches R200/R300 Plugin dafür basteln, weil sie sonst indirekt nV in die Ärmchen spielen.
"

Brauchen sie auch gar nicht, da ohne Profile und Compiler CG für alle nicht Nvidia Chips Standard DX Code erzeugt, den man auch mit der MS HLSL erhalten würde.
NV Chips bekommen dann eben eine hardwareengere Anpassung und alle anderen Standardkost.

[HOT]

Na ich denk mal, wenn es jemand wirklich drauf anlegt und OpenGL erzeugen möchte nimmt er GLSlang und nicht cg ;)
Wenn der Syntax fast identisch ist, wird vielleicht auch eine Doppellösung seitens der Softwareentwickler angedacht. cg an Sich kann doch keinen OpenGL Code für ATI/Matrox /... Karten ereugen, oder?

[Xmas]

Originally posted by HOT
Na ich denk mal, wenn es jemand wirklich drauf anlegt und OpenGL erzeugen möchte nimmt er GLSlang und nicht cg ;)
Wenn der Syntax fast identisch ist, wird vielleicht auch eine Doppellösung seitens der Softwareentwickler angedacht. cg an Sich kann doch keinen OpenGL Code für ATI/Matrox /... Karten ereugen, oder?
GL2 ist aber noch ein Stückchen weit weg.
Bei den DX-Profiles sowie den ARB Extensions (OpenGL 1.4) generiert der Cg-Compiler PS/VS Assembler Code, der auf jeder Karte mit entsprechendem Featureset läuft.
In OpenGL 2.0 gibt es nun keinen solchen Assemblercode, und der GLslang-Compiler ist Teil des Treibers, d.h. alles nach dem GLslang Code ist Hardwareabhängig. Es wird sich noch zeigen müssen was man da mit Cg anfangen kann, theoretisch könnte der Cg-Compiler auch nur eine Syntaxumwandlung übernehmen.