NVIDIA Open Sources Cg Compiler Technology

[nggalai]

Hi there,

Link: http://biz.yahoo.com/prnews/020723/sftu012_1.html

Auszug:SAN ANTONIO, July 23 /PRNewswire-FirstCall/ -- SIGGRAPH 2002, NVIDIA® Corporation (Nasdaq: NVDA - News), the worldwide leader in visual processing solutions, today announced that it is open sourcing the NVIDIA Cg Compiler technology under a nonrestrictive, free license. Available in August for download from the developer.nvidia.com and www.cgshaders.org Web sites, this code will contain the parser that reads the language and creates intermediate code for compilation, as well as a generic back-end. Together, these components provide everything required to create optimized Cg compilers for other platforms and architectures. In addition to the NVIDIA Cg Compiler, NVIDIA has provided full source code for example shaders in the NVIDIA Cg Toolkit.

ta,
-Sascha.rb

[Richthofen]

jo hab ich auch gelesen heute schon.

Jetzt wirds langsam interessant :)
Ne gute Möglichkeit jedenfalls mehr aus den eigenen Grakas rauszuholen sofern einige Entwicklerd das nutzen aber davon bin ich überzeugt weils unter Umständen ne Menge Zeit erspart.

[Demirug]

Zeit spart das auf jeden Fall. Und das es jetzt wie versprochen Opensource wird macht die Sache noch interesanter.

Ich bin allerdings auch auf ATi's Rendermonkey gespannt. Vorallem das Renderman Parsing interesiert mich.

[nggalai]

Hi there,

klingt gut. Ein paar Sachen, jedoch:

- nur der Compiler-Sourcecode wird (vorerst?) freigegeben. Die Sprach-Spezi bleibt IP von NV.

- Damit steht NV gegen Microsofts eigener HLSL (DX9) und dem Vorschlag von 3DLabs (OGL2).

- RenderMonkey ist eigentlich keine direkte Konkurrenz zu Cg, sondern eher ein Entwicklungs-Framework als eine Programmiersprache, wenn ich das paper richtig verstanden habe. Muss aber nochmals drüber.

Aber ja, sieht gut aus. Alias|Wavefront, Pixar (RenderMan) und Softimage sind bereits im Boot. Der einzige wirklich grosse Name, der fehlt, ist id Software. ;)

ta,
-Sascha.rb

[Demirug]

Hi nggalai,

wenn ich die sache richtig verstanden habe läst sich der Compiler aber mit verschiedenen Profilen anpassen. Aber warten wir mal auf den Sourcecode.

MS HLSL soll ja weitgehend identisch sein.

OGL2 ist ja wieder eine ganz andere Geschichte. Da sehe ich erst mal viele nicht richtig funktionieren Treiber auf uns zukommen.

RenderMonkey selbst ist wohl keine Sprachedefinition. Allerdings soll dieser Framework z.B. Renderman scripte in Shaderprogramme umsetzten können.

Ich vermute mal das sich id Software bereits ein eigenes Shader System geschrieben hat. Wobei ich fast denke das es da nicht viele Variationen gibt. Sind ja auch eigentlich nicht notwendig da ja immer nur 1 Lichtquelle auf eine Bumpmap Fläche gerendert wird (etwas vereinfacht).

[aths]

Verstehe ich das richtig, dass Rendermonkey Renderman-Scripte für PixelShader 2.0 aufbereitet? Oder wird es gar eine Möglichkeit geben, diese mit PS.1.4 zu rendern? (Was mir natürlich auch nichts nützt, ich bräuchte schon einen Parser, der höchstens PS.1.3-kompatiblen Code erzeugt, zur Not halt mit deutlich mehr Passes.)

Warum orientiert sich nV nicht an bestehenden Standards, sondern versucht mit aller Gewalt, etwas eigenes (und wohl kaum besseres) zu schaffen?

[Mad-Marty]

Originally posted by aths
...
Warum orientiert sich nV nicht an bestehenden Standards, sondern versucht mit aller Gewalt, etwas eigenes (und wohl kaum besseres) zu schaffen?

Tja, weils halt nv ist, die kriegen Komplexe wenn mal was tolles nicht von ihnen ist .... (Und wollen halt mit solchen mitteln
den Markt kontrollieren / beherrschen / lenken.

NV = :asshole:

:asshole: :asshole:

:-(

[Richthofen]

eventuell weil die NV3x Architektur weiter geht als bisher angenommen?
Oder weil man neue Märkte erschliessen will?

Keine der Sprachen ist Plattform und Schnittstellenüvergreifend.
OGL2.0 nicht da, die MS Version auch nicht, CG ist da wenn auch noch sehr beta.
Eventuell hat Nvidia keine Lust darauf zu warten das sich Gremien wie die Jungs für OGL zusammensetzen?
Soweit ich weiss ist NV nicht in dem Gremium ATi aber schon.

Ich kann den Schritt verstehen und Microsoft wird gegen CG gar nix haben. Das Ganze ist unter derren Aufsicht abgelaufen. Wenn die CG als Gefahr einschätzen würden, hätte es das nie gegeben in der Form. Da hätten die nen Riegel vorgeschoben.

Ich würde sagen hier spielen mehere Dinge zusammen und schauen nach einer reichlich langfristigen Strategie aus.

1. neue Märkte (neue Company gekauft - rendering???)
2. Features eigener Karten
3. x-Box (nicht gerade unwichtig und wohl ein Grund wieso MS mitmacht) wahrscheinlich auch x-Box2
4. Mit 44% Marktanteil sollte es möglich sein Standards zu setzen, was für ATI und andere Konkurenten ausser im OGL Gremium eher nicht möglich ist. Wenn man mal die wirklichen Marktbereiche sich anschaut wo 3D Grafik wichtig ist dürfte der Anteil sogar über 44% liegen und zwar deutlich.

Wie gesagt ist nix für die nächsten Monate sondern eher eine langfrisig angelegte Strategie.
In jedem Fall ist CG in meinen Augen nicht mehr der PR Gag für den es vor wenigen Wochen noch viele gehalten haben. Des scheint mir doch bissl was ernsteres zu sein.

[Demirug]

aths,

wie das mit den Renderman scripten genau abläuft weiss ich leider auch noch nicht.

[egdusp]

Originally posted by Richthofen
eventuell weil die NV3x Architektur weiter geht als bisher angenommen?
Oder weil man neue Märkte erschliessen will?


Ich finde die DX8 Unterstützung von Cg eher wichtig. Da momentan DX8 Mainstream wird und MS HLSH (oder so änlich:) ) keine DX8 code erzeugt, werden viele Entwickler Cg nutzen.
Aktuell ist die Durchschnittshardware eines Onlinepsielers ja GF2MX (laut Half Life Survey). D.h. eine 2 Jahre alte Technologie ist Duechschnitt und jetzt erst wird damit begonnen diese Technologie auszureizen (UT2003).

Jeder Spieleentwickler der jetzt dabei ist ein Spiel zu entwickeln, das in 1-2 Jahre rauskommen soll, wird sicher nicht nur auf DX9 setzen, sondern höchstens auf DX8 (selbst Doom 3 hat ja noch DX6 Fallback AFAIK).
Diese Entwickler werden Cg lieben, da es auf DX9 Karten ja auch automatisch neue Effekte anzeigt.

mfg
egdusp

[Demirug]

@egdusp:

Nach dem derzeitigen Stand wird MS HLSL auch Support für Pre 2.0 Shader haben.

Das mit dem "automatisch neue Effekte" wird nichts. Programmieren muss die immer noch jemand. Mit Cg und MS HLSL geht das aber schneller. Hab gestern ein paar PS 2.0 in native gesehen :kotz:. Das ist was für Wahnsinnige.

[nggalai]

Originally posted by Demirug
Hab gestern ein paar PS 2.0 in native gesehen :kotz:. Das ist was für Wahnsinnige. LOL

wenn das so aussah wie die Beispiele in der Cg-Doku, dann kann ich deine Magenreaktion gut nachvollziehen. :)

ta,
-Sascha.rb

P.S. auf alle Fälle sollten die Zeiten von Assembler-mässiger Shaderprogrammierung jetzt echt vorbei sein.rb

[Demirug]

Originally posted by nggalai
LOL

wenn das so aussah wie die Beispiele in der Cg-Doku, dann kann ich deine Magenreaktion gut nachvollziehen. :)

ta,
-Sascha.rb

P.S. auf alle Fälle sollten die Zeiten von Assembler-mässiger Shaderprogrammierung jetzt echt vorbei sein.rb

Das wars:


ps.2.0
def c0, 2.0f, -1.0f, 0.5f, 0.5f // scale, bias, half, X
def c1, 1.0f, 1.0f, 0.1f, 0.0f // X, X, 0.1, zero
dcl t0.xyzw // xyz == Pshade (shader-space position), w == X
dcl t1.xyzw // xyz == Perturbed Pshade, w == X
dcl t2.xyzw // xyz == Perturbed Pshade, w == X
dcl t3.xyzw // xyz == { Pshade.z, 0, 0}, w == X
dcl t4.xyzw // xyz == { Pshade.z + 0.5, 0, 0}, w == X
dcl t6.xyzw // xyz == P_eye, w == X
dcl t7.xyzw // xyz == N_eye, w == X
dcl_volume s0 // Luminance-only Volume noise
dcl_2d s1 // 1D smooth step function (blend factor in x, specular exponent in y,
texld r3, t0, s0 // Sample dX from scalar volume noise texture at Pshade texld r4, t1, s0 // Sample dY from scalar volume noise texture at perturbed Pshade texld r5, t2, s0 // Sample dZ from scalar volume noise texture at perturbed Pshade texld r6, t3, s0 // Sample trunkWobble.x from scalar volume noise at { Pshade.z, 0, 0}
texld r7, t4, s0 // Sample trunkWobble.y from scalar volume noise at { Pshade.z + 0.5, 0, 0}
mov r3.y, r4.x // Put dY in y
mov r3.z, r5.x // Put dZ in z
mov r6.y, r7.x // Move to get { trunkWobble.x, trunkWobble.y, 0}
mad r6, r6, c0.x, c0.y // Put { trunkWobble.x, trunkWobble.y, 0} in -1..+1 range
mad r3, r3, c0.x, c0.y // Put noise in -1..+1 range
mad r7, c3.w, r3, t0 // Scale noise by amplitude and add to Pshade to warp the domain
mad r7, c4.w, r6, r7 // Scale { trunkWobble.x, trunkWobble.y, 0} by amplitude and add in
dp2add r0, r7, r7, c1.w // x2 + y2 + 0
rsq r0, r0.x // 1/ sqrt(x2 + y2)
rcp r0, r0.x // sqrt(x2 + y2)
mul r0, r0, c2.w // sqrt(x2 + y2) * freq
texld r0, r0, s1 // Sample from 1D pulse train texture
mov r1, c3
lrp r2, r0.x, c2, r1 // Blend between light and dark wood colors
sub r4, c4, t6 // Compute normalized vector from vertex to light in eye space (L_eye)
dp3 r5.w, r4, r4 //
rsq r5.w, r5.w //
mul r4, r4, r5.w // L_eye
dp3 r6.w, t7, t7 // Normalize the interpolated normal
rsq r6.w, r6.w //
mul r5, t7, r6.w // N_eye
dp3 r3.w, t6, t6 // Compute normalized vector from the eye to the vertex
rsq r3.w, r3.w //
mul r3, -t6, r3.w // V_eye
add r6, r3, r5 // Compute Eye-Space HalfAngle (L_eye+V_eye)/|L_eye+V_eye|
dp3 r6.w, r6, r6
rsq r6.w, r6.w
mul r6, r6, r6.w // H_eye
dp3_sat r6, r5, r6 // N.H
mad r0.z, r0.z, c5.z, c5.w // scale and bias wood ring pulse to specular exponent range
pow r6, r6.x, r0.z // (N.H)^k
dp3 r5, r4, r5 // Non-clamped N.L
mad_sat r5, r5, c0.z, c0.z // "Half-Lambert" trick for more pleasing diffuse term
mul r6, r6, r0.y // Gloss the highlight with the ramp texture
mad r2, r5, r2, r6 // N.L * procedural albedo + specular
mov oC0, r2


Der Effekt sieht ja nicht schlecht aus:

[Legende]

"Nvidia hat gestern angekündigt, den Quelltext für die Compilertechnik seiner Grafikchip-Programmiersprache CG zu veröffentlichen. CG hilft Spieleprogrammieren, Pixel- und Vertex-Shader-Effekte zu erstellen. Mit der Freigabe des Quelltextes könnten auch andere Hersteller wie ATI oder Matrox CG an ihre Grafikkarten anpassen."

Für uns ATI Besitzer kann das nur vom vorteil sein ;)

[Tigershark]

Also ich glaube eigentlich nicht dass ATI die Sprach vom Konkurrenten NV anpasst oder weiterentwickelt. Werbewirksam für NV isses, wenn man zeigt, dass man der Konkurrenz was gutes tut, indem man sowas freigibt, aber dass es jemand benutzt bezweifle ich.

[Richthofen]

Das wird sich alles zeigen.
Im Prinzip werden die Entwickler entscheiden ob ATI auf den CG Zug aufspringt oder nicht.

Eventuell gibts noch andere Entwicklungen in Sachen CG? Da läuft doch grad was beim ARB.

Anyway wenn Entwickler von Games CG nutzen wird ATI mitmachen. Das wäre zumindest in ihrem eigenen Interesse ansonsten könnten sie Nachteile bei zukünftigen Games haben, die sie ja ohnehin schon haben weil bei vielen NV Hardware Entwicklungsbasis ist und weil NV sich um Developer schon immer deutlich mehr und vor allem viel länger gekümmert hat als ATI. Wenn die Entwickler CG nicht nutzen dann wird ATI nicht mit aufspringen.

Wird sich also erst mit zunehmender Zeit abzeichnen wie es da weitergeht.

[Unregistered]

also wenn cg wirklich nur eine abstammung von Hd was weis ich was aus direct x9ist, glaub ich ned dass ein einziger diese Sprache benutzt. Ausser Demoprogramierer..

Wenn sie natürlich Vorteile haben sollte sieht es anders aus.... Im Prinuzip ist das ganze doch eine verkappte API

[Richthofen]

du meinst die HLSL von MS für DX9.
Die kann aber nunmal kein OGL und ist wohl auch nur für Windoof.

CG ist sowohl für OGl als auch DX geeignet und zudem OS unabhängig.
Da sind schon ein paar Vorteile auf der CG Seite + der Zeitvorteil vor den anderen Sprachen.

[Unregistered]

aber wie es in den news schon steht ist es vermutlich zu herstellerspezifisch. Somit wird es sich im moment bei spielen nicht durchsetzen können.

[GUNDAM]

Es wird bestimmt sehr lange dauern bis sich CG durchsetzen wird;D

[Demirug]

Originally posted by Luke Skywalker
Es wird bestimmt sehr lange dauern bis sich CG durchsetzen wird;D

Da wäre ich mir nicht so sicher. Solange die Runtime nicht benutzt wird merkt es sowieso keiner was zur Erstellung der Schader benutzt wird. Und Cg ist im Moment für die meisten die einzige Möglichkeit eine Higher Level Sprache für VS und PS zu benutzten.

[Richthofen]

so ist es.

Die bisher vorzüglichen Developer Relations bei Nvidia, der Zeitvorteil mit CG und nicht zu letzte der Marktanteil bei 3D relevanter Grafik, damit meine ich nicht die ganzen Low Cost Chipsätze wie die von Intel sondern die, mit denen der Gamer auch wirklich daddelt können CG zu nicht geringer Akzeptanz verhelfen.

Die Frage für den Entwickler wird sein, wieviele Leute spielen auf ATI Karten (Matrox und PowerVR lass ich mal weg weil die im Gamermarkt zu klein sind) und wieviele von denen merken obs Performancenachteile gibt.
Viele meinen ja das ein Developer es sich nicht leisten kann wenns nur auf einer Hardware gescheit läuft. Das stimmt aber auch nur teilweise, denn der Gamer wird die Schuld nicht dem Developer sondern dem Grakahersteller geben und next time ne andere Graka kaufen wenn sich nix ändert.

Insofern wär ich mir nicht so sicher, das CG keine Beachtung erfährt.
Mit ein bisschen Glück und prima Timing seitens Nvidia muss ATI mit aufspringen ob sie wollen oder nicht.

[Demirug]

Was den DX Bereich angeht ist Cg ja hardware neutral. Die damit erstellten Shader laufen auch auf allen Karten mit VS 1.1 (notfalls CPU) und PS 1.1. Und das Gejammer das PS 1.4 nicht unterstützt wird ist sinnloss da ohne Cg auch so gut wie kein Entwickler PS 1.4 nutzt.

Und OpenGL entwicklung ist sowieso sehr Herstellerspezifisch da macht eine properitäre Lösung eh nichts aus.

[zeckensack]

Habe mal den Merge-Knopf gedrückt.

[nggalai]

Zum Thema "Entwickler-Akzeptanz":

http://developer.nvidia.com/view.asp?IO=cg_companies

Wenn davon auch nur die Hälfte bei Cg bleiben wird, kann man die Sprache wohl wirklich schon fast als "Industrie-Standard" bezeichnen.

ta,
-Sascha.rb

Edit: Link korrigiert

[bendel]

Originally posted by nggalai
Zum Thema "Entwickler-Akzeptanz":

http://developer.nvidia.com/view.asp?IO=cg_companies

Wenn davon auch nur die Hälfte bei Cg bleiben wird, kann man die Sprache wohl wirklich schon fast als "Industrie-Standard" bezeichnen.

ta,
-Sascha.rb

Edit: Link korrigiert

Das scheint mir aber eine reine Marketing-Liste. Nach dem Motto: Ihr wart mal bei NVidia und habt es euch deshalb auch angeschaut. Ich denken nicht, dass es in den meisten Firmen zum jetzigen Zeitpunkt aktiv eingesetzt wird.

Steffen Bendel

[Demirug]

Auf OpenGL.org führt man gerade eine Umfrage durch:

Thema:

Welche HLSL soll bei OpenGL 2.0 benutzt werden ?

Zwischenstand:

I prefer 3Dlabs' HLSL as the OpenGL HLSL 23.9%
I prefer NVIDIA's Cg as the OpenGL HLSL 17.2%
The ARB should combine the best elements of both HLSLs 26.9%
The exact language details don't matter, so long as there's a single HLSL for use in OpenGL 26.3%
I prefer another HLSL 0.8%
I don't care about HLSL 0.9%
What's a HLSL? 4.1%

[Crushinator]

Originally posted by nggalai
http://developer.nvidia.com/view.asp?IO=cg_companies

Wenn davon auch nur die Hälfte bei Cg bleiben wird, kann man die Sprache wohl wirklich schon fast als "Industrie-Standard" bezeichnen.



Du vergisst dabei, daß die wichtigste Firma nämlich "id Software"
nicht auf der Liste steht. Carmack hält nichts von Monokulturen
was wiederum bedeutet, daß CG nur dann was wird, wenn nVidia die
Sprache komplett offenlegt in die Hände eines Gremiums übergibt.

Ich würde mir als Entwickler gut überlegen, ob ich mich in
eine Abhängigkeit begeben würde. Es kann ja auch sein, daß
demnächst irgendwer eine Karte auf den Markt schmeisst, die
ATI und nVidia zusammen um das doppelte schlägt. Außerdem wäre
mir das lieber wenn mein Game auf mehrere (mehr als 2) Karten
flüssig und stabil läuft.

Ich hoffe, daß entweder CG von allen Herstellern als Standard
angenommen wird oder etwas vergleichbares beim OGL Gremium
rausspringt.

[Demirug]

D3D:

Wer die Cg Specs gelessen hat weis das der D3D pfad von CG mit jeder DX8 Hardware funktioniert. Da für DX8 derzeit ausser CG keine andere HLSL gibt ist Cg die beste Wahl wenn man sich nicht mit den native VS\PS Code rumschlagen will. Für DX9 ändert sich die lage ebenfalls nicht.

OpenGL:

Es gibt für OpenGL keine spezifizierte HLSL bevor es (irgendwann) OpenGL 2.0 gibt. Und so wie es aussiehter ist Cg in der Lage 1.4 Kompatible Vertex Programme zu erzeugen also funktioniert Cg auch in diesem Bereich für alle Karten mit OpenGL 1.4 Treibern.

EDIT: Tonfall

[Richthofen]

"
Du vergisst dabei, daß die wichtigste Firma nämlich "id Software"
nicht auf der Liste steht. Carmack hält nichts von Monokulturen
was wiederum bedeutet, daß CG nur dann was wird, wenn nVidia die
Sprache komplett offenlegt in die Hände eines Gremiums übergibt.
"

Du vergisst hierbei wiederum das Herr Carmack es sich nicht nehmen lässt für eventuelle technische Möglichkeiten eines Chips die über die normalen Specs hinausgehen gewisse Dinge in die Engine zu implementieren.
Will sagen wenn der NV3x mehr kann als DX9 vorgibt, dann würde Herr Carmack auch ohne CG das ausnutzen. Er schreibt sowohl für ATI als auch für NV extra Renderpfade.
Die meissten Entwickler nehmen sich aus Kostengründen, Zeitgründen, Faulheit diese Zeit nicht.
Will sagen sie könnten dann nicht alles ausreizen und von denen werden einige über CG nachdenken.
Zumal CG ja nicht heisst das es auf anderen nicht läuft. Es läuft genauso wie es sonst mit normal DX9 zb auch laufen würde nur das CG die Möglichkeit bietet, das NV einen besseren Support erfährt der über Standards hinausgeht. Wenn andere sich dem anschließen geht das dann natürlich auch.
Da der Anteil von NV Karten bei Gamern deutlich über 60% liegen dürfte, ist es auch kein Problem weiter.
Denn das Game läuft ja deswegen nicht schlechter auf anderen Karten.
Zudem musst du dir überlegen was der Spieler macht, wenn er sieht das bei nem Kumpel das Game auf NV doch nen tick fixer läuft weils über DX9 oda OGL default hinaus optimiert ist.
Er gibt ganz sicher nicht dem Entwickler die Schuld sondern dem Hardwarehersteller.

Insofern befindet sich der Spieleentwickler in trockenen Tüchern.
Das J.C. nicht zwingend CG braucht ist mir vollkommen klar. Der nutzt die Möglichkeiten so oder so aus ob nun mit oder ohne CG. 90% der Developer nehmen sich diese Zeit aber nicht und können es auch nicht.

[Demirug]

@Richthofen:

Du vergisst hier etwas. JC benutzt OpenGL deshalb bleibt im gar nichts anderes übrig als für jede Karte einen eigenen Renderpfad zu schreiben.

Zudem braucht die DOOM III engine überhaupt kein so aufwendiges Shadersystem. Die Engine braucht lediglich für jeden Lichttype einen Shader der leichte Variationen (Weglassen von einzelnen Lichttanteilen [Diffusse, Specular, usw]) zuläst. Da es in der Rendertechnik eingentlich nur 5 Grundtypen für die Beleuchtung gibt wird die Sache sehr einfach.

[Crushinator]

Originally posted by Richthofen
...
Zumal CG ja nicht heisst das es auf anderen nicht läuft. Es läuft genauso wie es sonst mit normal DX9 zb auch laufen würde nur das CG die Möglichkeit bietet, das NV einen besseren Support erfährt der über Standards hinausgeht. Wenn andere sich dem anschließen geht das dann natürlich auch.

Da der Anteil von NV Karten bei Gamern deutlich über 60% liegen dürfte, ist es auch kein Problem weiter.
Denn das Game läuft ja deswegen nicht schlechter auf anderen Karten.
Zudem musst du dir überlegen was der Spieler macht, wenn er sieht das bei nem Kumpel das Game auf NV doch nen tick fixer läuft weils über DX9 oda OGL default hinaus optimiert ist.
Er gibt ganz sicher nicht dem Entwickler die Schuld sondern dem Hardwarehersteller.


Wenn das Wörtchen "wenn" nicht wäre...also, wenn sich Andere
anschliessen würden. Was wenn nicht? Dann gibt's - wie jetzt
schon üblich - meist Games, die trotz bescheidener Grafik
auf NV-Chips "besser" laufen als auf Andere.

Außerdem ist mir die Annahme, daß NV-Software auf anderen Karten
genau so gute Resultate erzielt einfach nur Theorie + Träumerei.
Wenn die Chips sich so ähnlich wären müßten einige heutiger Games
dieselben Raten auf der r85k und der Ti4400 liefern und das tun
sie ja bekannterweise nicht.

BTW: Ich würde als Gamer mir die Grafikdetails eines Games
anschauen, mich informieren und dann beurteilen, ob das Ruckeln
an meiner Grafikkarte und nicht eher an der evtl. Unfähigkeit
oder am (Un)Willen des Entwicklers liegt.

Kurz und bündig: Ich als Verbraucher halte nichts von Software
die mein Lieblingshersteller nicht auf seine Bedürfnisse anpassen
kann und als Entwickler von technischen Anwendungen traue ich
einem Hardwarehersteller was Offenheit angeht soweit wie ich sie
schmeissen kann. ;-)

Entweder komplett offenlegen und sich mit den Anderen einigen
(notfalls Abstriche machen) oder gleich wieder begraben. Ersteres
natürlich wünschenswert.

Gruß

[Demirug]

@crushinator:

Cg erzeugt VS und PS Programme. Wenn das ergebniss damit nicht auf allen Karten gleich aussieht dann hat eine der Karten einen Bug (Hardware/Treiber). Bei DX kann man Cg also bedenkenlos einsetzten.

Das Spiele auf NV Hardware oft besser laufen hängt einfach mit dem weltklasse Entwicklersupport von NVidia zusammen. Wenn das ATi auch so machen würde hatten viele Spiele auf ATi Hardware weniger Probleme.

[Crushinator]

Originally posted by Demirug
Cg erzeugt VS und PS Programme. Wenn das ergebniss damit nicht auf allen Karten gleich aussieht dann hat eine der Karten einen Bug (Hardware/Treiber). Bei DX kann man Cg also bedenkenlos einsetzten.


Das möchte ich ja auch nicht bestreiten. Ich habe mit "besser"
laufen nicht eine fehlerhafte Darstellung gemeint, ich hätte
fixer/schneller schreiben sollen.

Gehe ich recht der Annahme, daß CG z.Z. nur eine bestimmte
PS-Version unterstützt? Wo ist da der Fortschritt, wenn ich
nur das in Games bekomme, was NV-Chips können?

Oder habe ich da was falsch verstanden?

Originally posted by Demirug
Das Spiele auf NV Hardware oft besser laufen hängt einfach mit dem weltklasse Entwicklersupport von NVidia zusammen. Wenn das ATi auch so machen würde hatten viele Spiele auf ATi Hardware weniger Probleme.

Wie kann man davon ausgehen, daß z.B. ATi das nicht genau so gut
tun würde, wenn die Entwickler das nur wollten? Sie (ATi) würden
sich doch sonst ins eigene Fleisch schneiden oder nicht? Mir ist
allerdings auch klar, daß ATi punkto Entwickler-Support
noch dabei ist genügend Resourcen zu schaffen.

Es geht mir auch nicht unbedingt um nur ATi. Was ist denn mit Matrox,
PowerVR und zukünftig 3DLabs? Laufen denn alle Spiele auf Karten
dieser Hersteller vergleichbar so schnell/problemlos wie auf den
Chips von nVidia?

Eher nicht, kenne ich nämlich zu genüge aus eigenem Bekanntenkreis.

Ganz einfach: Ich möchte eine(n) HLSL-IDE/Compiler, der nicht nur
Lizenzfrei ist sondern auch von Herstellern per Plugins oder
ähnlichen Mechanismen erweitert werden kann, ähnlich wie MSVC++
in Verbindung mit dem Intel-Compiler, punkt. ;-)

Gruß

[Demirug]

Originally posted by crushinator


Das möchte ich ja auch nicht bestreiten. Ich habe mit "besser"
laufen nicht eine fehlerhafte Darstellung gemeint, ich hätte
fixer/schneller schreiben sollen.

Gehe ich recht der Annahme, daß CG z.Z. nur eine bestimmte
PS-Version unterstützt? Wo ist da der Fortschritt, wenn ich
nur das in Games bekomme, was NV-Chips können?

Oder habe ich da was falsch verstanden?


Die derzeitige BETA von CG unterstützt VS 1.1 und PS 1.1 das geht mit jeder DX8 Karte. Die Final soll auch VS 2.x und PS 2.x unterstützen.


Wie kann man davon ausgehen, daß z.B. ATi das nicht genau so gut
tun würde, wenn die Entwickler das nur wollten? Sie (ATi) würden
sich doch sonst ins eigene Fleisch schneiden oder nicht? Mir ist
allerdings auch klar, daß ATi punkto Entwickler-Support
noch dabei ist genügend Resourcen zu schaffen.


Sie tun es aber nicht. Dazu muss man nur die öffentlichen Entwicklerbereiche vergleichen.


Es geht mir auch nicht unbedingt um nur ATi. Was ist denn mit Matrox,
PowerVR und zukünftig 3DLabs? Laufen denn alle Spiele auf Karten
dieser Hersteller vergleichbar so schnell/problemlos wie auf den
Chips von nVidia?

Eher nicht, kenne ich nämlich zu genüge aus eigenem Bekanntenkreis.


Könnte es daran liegen das NVIDIA einfach die beste Chip/Treiber kombination hat???


Ganz einfach: Ich möchte eine(n) HLSL-IDE/Compiler, der nicht nur
Lizenzfrei ist sondern auch von Herstellern per Plugins oder
ähnlichen Mechanismen erweitert werden kann, ähnlich wie MSVC++
in Verbindung mit dem Intel-Compiler, punkt. ;-)

Gruß

Geht doch mit Cg. Demnächst gibt es den dafür entscheidenden Teil als OpenSource.

[Crushinator]

Originally posted by Demirug
...
Geht doch mit Cg. Demnächst gibt es den dafür entscheidenden
Teil als OpenSource.


OK, wenn es tatsächlich so käme wie ich Opensource bisher
gewohnt bin, fände ich es eine sehr schöne Sache. Laß es
uns abwarten. Jedenfalls danke ich Dir erstmal für die
objektiven und hilfreichen Erklärungen zu CG. :-)

[Demirug]

So jetzt ist es zum download zu haben:

http://developer.nvidia.com/view.asp?IO=cg_compiler_code