"cg" c-like shadersprache von nvidia

[tEd]

http://pc.ign.com/articles/361/361823p1.html

die diskussion ist hiermit eröffnet. :)

[zeckensack]

Was'n das für'n Link? Pacman-Review?

Komme in 15 Minuten wieder, wenn's dann nix sinnvolles ist, kommt's in die Tonne.

[tEd]

der link wurde gekappt. die nda läuft wohl erst am donnerstag ab darum haben sie es weggenommen.

sorry

[zeckensack]

Dann lassen wir den Thread doch einfach mal bis Donnerstag stehen :)

[Unregistered]

Im b3d Forum wird schon heftig darüber diskutiert. Scheint eine Art Hochsprache zu sein.
Den Thread mit Zitaten aus dem Artikel gibts hier:
http://www.beyond3d.com/forum/viewtopic.php?t=1242

[Leonidas]

C&P within3d
http://www.within3d.net/index.php?show=news&type=shownews&id=449


Eine Meldung der etwas beunruhigenderen Sorte hat IGN zu vermelden: Demnach wird nVIDIA in Kürze eine Software namens Cg veröffentlichen. Ein nVIDIA-Mitarbeiter beschreibt das Produkt als eine High-Level Programmiersprache, welche den Spielentwicklern das Programmieren von Vertex- und Pixel-Shadern erleichtern soll. Momentan können diese ja nur über Assembler genutzt werden. Diese Beschreibung weckt jedoch sofort die Befürchtung, dass sich dahinter möglicherweise ein proprietäres API à la GLide verbirgt - was natürlich sehr schlecht für die Industrie und somit auch den Kunden wäre. Angeblich soll Cg aber mit DirectX und OpenGL "kompatibel" sein. Was dies bedeutet, lässt sich aus den wenig technischen Angaben von IGN nur schlecht beurteilen. Möglicherweise ist Cg kein eigenständiges API, sondern nur ein Tool, um Shader-Programme für DirectX und OpenGL auf einer höheren Abstraktionsebene zu entwickeln. Allerdings fragen wir uns, wozu so eine Software überhaupt nötig ist, wenn doch bereits in DirectX 9 bereits eine komfortablere High-Level Shading-Sprache implementiert wird. Ebenfalls unbeantwortet bleibt natürlich auch die Frage zur Kompatibilität von Cg zu Chips der Konkurrenz - wir haben da nämlich so unsere Zweifel.

[ow]

*lol*

was hat denn eine high-level Programmiersprache mit einem propritaeren API zu tun?

Das ist sicher nix anderes als ein Tool, um irgendwelche VS/PS Makros zu bauen, die ich zu viele Zwecken dann nutzen kann.

So hoert sich das fuer mich an und nicht anders.

Und das diese Makros auf anderer HW laufen steht IMO ausser Frage, weil NV ja nur max. PS1.3 unterstuetzt und die Konkurrenz dies auch tut.

[Richthofen]

das übliche die Panik startet bevor der Tanz erst richig losgeht.
Im Beyond3D spinnen einige schon wieder voll ab obwohl die Leute wirklich nix aber auch gar nix wissen.

[Ceiser Söze]

Die Leute bei nVIDIA sind nicht gerade für Altruismus bekannt und wenn sie es wollen, können sie dieses Cg-Zeug trotz gleicher Grundlagen problemlos inkompatibel zur Konkurrenz machen - wenn's technisch nicht geht, dann halt mit wesentlich wirkungsvolleren rechtlichen Mitteln...

[zeckensack]

Oh Gott, das Sommerloch! :o

[Richthofen]

ach und die Konkurenz ist da anders?

Ich muss doch wohl sehr bitten. Niemand weiss was also isses auch sinnlos jetzt schon wieder große Alarmglocken zu leuten.
Aber erstmal wird kategorisch draufgehaun bevor auch nur irgendwas klar ist.

[Ceiser Söze]

Die Konkurrenz ist anders. Siehe OpenGL-Extensions...

[ow]

???

Versteh ich nicht, erklaere mir das bitte mal.

[zeckensack]

Originally posted by zeckensack
Oh Gott, das Sommerloch! :o Das sollte lediglich bedeuten, daß ich das nicht unbedingt für Newswürdig, schon garnicht NDA-Bruch-würdig halte, wenn am Donnerstag irgendeine ominöse Software rauskommt, von der die Newsautoren offenstichtlich überhaupt nichts wissen.

Wer da eine Pro- oder Anti-Haltung in irgendeiner Form herauslesen will, ähh, der ... soll das nicht tun :)

[Ceiser Söze]

Schau dir mal die OpenGL ARB Meeting-Notes an. nVIDIA hat 2000/2001 im ARB mit ziemlich happigen IP-Forderungen bezüglich Shader-Extensions für einigen Missmut gesorgt und sich innerhalb des ARBs keinen allzu guten Ruf geschaffen. Microsoft konnte man bei DirectX 8 damit noch über den Tisch ziehen, was man in Redmond im Nachhinein aber nicht so lustig fand und daher bei DX9 den R300 als Referenz nahm. Beim ARB klappte es aber nicht und am Ende (September 2001) ist sogar David Kirk persönlich am Meeting erschienen, um den angeschlagegen Ruf wieder geradezubiegen (die IP-Forderungen hat man kleinlaut zurückgezogen).
ATi zeigt sich generell liberaler bezüglich IP-Angelegenheiten - kann man auch wunderbar in den ARB Meeting-Notes nachlesen. Die Tatsache, dass ATi ausserdem Ende 2001 im ARB zum "permanent member" aufgestiegen ist, während der gleiche Antrag von nVIDIA abgelehnt wurde, spricht ebenfalls für sich.

Seitdem bin ich daher eher skeptisch gegenüber Allem eingestellt, was mit nVIDIA und IP zu tun hat (und 'Cg' wird wohl eindeutig in diese Kategorie fallen). nVIDIA hat durch diese Geschichte ganz klar an Einfluss bei der Entwicklung von zukünftigen APIs (DX9, OGL 2.0) verloren - evt. will man ja jetzt mit Cg ein eigenes Süppchen kochen. Dass nVIDIA ja überhaupt keine Angst hat, sich mit den Grossen der IT-Branche anzulegen, hat die Vergangenheit ja auch gezeigt...

[Wuzel]

Originally posted by Ceiser Söze
Schau dir mal die OpenGL ARB Meeting-Notes an. nVIDIA hat 2000/2001 im ARB mit ziemlich happigen IP-Forderungen bezüglich Shader-Extensions für einigen Missmut gesorgt und sich innerhalb des ARBs keinen allzu guten Ruf geschaffen. Microsoft konnte man bei DirectX 8 damit noch über den Tisch ziehen, was man in Redmond im Nachhinein aber nicht so lustig fand und daher bei DX9 den R300 als Referenz nahm. Beim ARB klappte es aber nicht und am Ende (September 2001) ist sogar David Kirk persönlich am Meeting erschienen, um den angeschlagegen Ruf wieder geradezubiegen (die IP-Forderungen hat man kleinlaut zurückgezogen).
ATi zeigt sich generell liberaler bezüglich IP-Angelegenheiten - kann man auch wunderbar in den ARB Meeting-Notes nachlesen. Die Tatsache, dass ATi ausserdem Ende 2001 im ARB zum "permanent member" aufgestiegen ist, während der gleiche Antrag von nVIDIA abgelehnt wurde, spricht ebenfalls für sich.

Seitdem bin ich daher eher skeptisch gegenüber Allem eingestellt, was mit nVIDIA und IP zu tun hat (und 'Cg' wird wohl eindeutig in diese Kategorie fallen). nVIDIA hat durch diese Geschichte ganz klar an Einfluss bei der Entwicklung von zukünftigen APIs (DX9, OGL 2.0) verloren - evt. will man ja jetzt mit Cg ein eigenes Süppchen kochen. Dass nVIDIA ja überhaupt keine Angst hat, sich mit den Grossen der IT-Branche anzulegen, hat die Vergangenheit ja auch gezeigt...

Jop, hab die Sache auch nebenher verfolgt, da sind noch ganz andere Sachen gelofen, aber egal ..
Ich will keinesfalls alarmglocken schlaqen, schon gar nich wenn weiters noch nich so bekannt iss.
Aber aufgrund der letzten ereignisse schon etwas beunruhigend.

[Quasar]

Ich würd' mich echt schlapplachen, wenn's CG nur als proprietäre Sprache gäb'. Der größte Aufschrei käme dann sicher aus den Tastaturen derjenigen, die Glide-Games noch für etwas Gottgegebenes halten.

Trotzdem wird nVidia sicher nicht so unschlau sein, einen völligen Alleingang zu wagen. Ich könnte mir eher vorstellen, daß durch cg und den wohl enthaltenen Compiler hochoptimierter Code für nV-Chips ausgespuckt wird, der zweierlei bewirkt:

1) Aus jedem damit entwickelten Code wird das Optimum von der Hardware herausgeholt und

2) Die Entwickler sparen Zeit, Arbeit und Geld und werden nV dafür lieben!

Beide Konsequenzen sehe ich als durchaus positiv an, andere könnten sich ja mal ein Scheibchen abschneiden....

edit:
Die "Befürchtungen" klingen imho mal wieder etwas paranoid. Wäre interessant, wie diese ausgesehen hätten, wenn ATi oder Matrox CG vorgelegt hätten...."

[Labberlippe]

Originally posted by Quasar
Ich würd' mich echt schlapplachen, wenn's CG nur als proprietäre Sprache gäb'. Der größte Aufschrei käme dann sicher aus den Tastaturen derjenigen, die Glide-Games noch für etwas Gottgegebenes halten.

Trotzdem wird nVidia sicher nicht so unschlau sein, einen völligen Alleingang zu wagen. Ich könnte mir eher vorstellen, daß durch cg und den wohl enthaltenen Compiler hochoptimierter Code für nV-Chips ausgespuckt wird, der zweierlei bewirkt:

1) Aus jedem damit entwickelten Code wird das Optimum von der Hardware herausgeholt und

2) Die Entwickler sparen Zeit, Arbeit und Geld und werden nV dafür lieben!

Beide Konsequenzen sehe ich als durchaus positiv an, andere könnten sich ja mal ein Scheibchen abschneiden....

edit:
Die "Befürchtungen" klingen imho mal wieder etwas paranoid. Wäre interessant, wie diese ausgesehen hätten, wenn ATi oder Matrox CG vorgelegt hätten...."

Na was habe ich schon einmal gesagt. :)
Komisch 3dfx wurde wegen Glide verteufelt.
Dann sagte ich das wenn nVIDIA so etwas ähnliches vorhat einige klatschn werden.
Anscheinend bestätigt sich dieses.

Wobei ich dieses nicht als eine Arte eigene API sehe.
Auf der einen Seite Frage ich mich warum nVIDIA solche "Tools" erstellt wenn über D3D ja alles vereinheitlicht ist.

Enige werden jetzt sicher die Gefahr sehen das nVIDIA mit solchen Tools versucht mit Gewalt die Position zu halten.
Wenn die Herstller nur noch die "Shader-Tools" von nVIDIA nehmen, dann kann passieren das die anderen Karten ohne Tools nur noch halbherzig unterstützt werden.
Das könnte in meine Augen zu einen Problem für die anderen Hersteller werden.


Aber ich schliesse mich Dir an ich glaube auch eher an Deiner Variante.

Gruss Labberlippe

[Demirug]

Ich verstehe gar nicht warum sich einige hier so aufregen. Zu DX8/OpenGL gibt es von NVidia auch einige zusätzliche Tools.

Bei CG wird es sich sehr wahrscheinlich um das neue Toolset für DX9 handeln. Ich weis zwar sehr wohl das DX9 eine eigene höhere Schadersprache hat aber schon bei DX8 waren die NVidia Tools den MS Tools überlegen und die meisten waren von der Karte unabhängig.

[Unregistered]

Hier gibts einen Bericht mit einigen Nvidia-Folien

http://www.bjorn3d.com/_preview.php?articleID=22

Sieht nach mehr aus als bloß einem DX9 Toolset

[ow]

Ist doch Klasse.
Anstatt irgendwelchen assembler code zu proggen generiert das Tool entsprechenden Code aus einer c-aehnlichen Sprache.
Das koennte die Entwicklungszeit fuer Engines stark verkuerzen.

[askibo]

Schaut mal hier:
http://www.cgshaders.org/
http://developer.nvidia.com/view.asp?IO=cg_toolkit

Viel Spaß beim testen

[ow]

Ist wohl ein unified compliler, laeuft mit allen GPUs ab DX8, OGL1.4.

Hier ein Bild aus oben zitierter Quelle:

[ow]

bild vergessen:D

[Xmas]

Toll, der Cg-Browser stürzt bei mir immer ab... ("Abnormal Program Termination" direkt beim Start)

[Demirug]

ow,

der fragment anteil bei openGL geht aber im Moment nur für NV2x Karten. Mal sehen ob Ati über seinen Schatten springt und ein Plugin für CG bereit stellt.

[aths]

Bei mir funzts :)

[egdusp]

Soweit ich es bisher verstanden habe, ist der Pixelshader 2.0 inkompatibel mit 1.x. Cg könnte ein Ausweg daraus sein, da es den Code ja gemäß dem Chip, bzw. der DX Version compiliert.

Täusche ich mich da? Vor allem bezüglich der PS 2.0 und PS1.x Kompatibilität.

mfg
egdusp

P.s.: Wenn dem so ist, wie sollen DX8 games dann auf DX9 Hardware laufen.

[Demirug]

Originally posted by egdusp
Soweit ich es bisher verstanden habe, ist der Pixelshader 2.0 inkompatibel mit 1.x. Cg könnte ein Ausweg daraus sein, da es den Code ja gemäß dem Chip, bzw. der DX Version compiliert.

Täusche ich mich da? Vor allem bezüglich der PS 2.0 und PS1.x Kompatibilität.

mfg
egdusp

P.s.: Wenn dem so ist, wie sollen DX8 games dann auf DX9 Hardware laufen.

PS 2.0 sind hardwaremäsig anders als PS 1.x es ist aber die aufgabe der Treiber sicherzustellen das PS 2.0 Hardware auch mit PS 1.x klarkommt. Das schreibt Direct X bindent vor.

[jedi]

Hier gibt's jede Menge Infos zu Cg:

http://www.nvnews.net/articles/cg_toolkit/cg_toolkit.shtml
http://www.extremetech.com/article/0,3396,s=1017&a=28051,00.asp
http://www.hothardware.com/hh_files/S&V/nvcg.shtml
http://www.3dgpu.com/previews/cglanguage.php
http://www.nvidia.com/view.asp?IO=cg
http://www.cgshaders.org/

[aths]

Mir ist eigentlich alles recht, was dazu führt, dass sich die Shader-Technik endlich durchsetzt. Wenn 'Cg' dazu beitragen sollte, gut...

[Salvee]

Originally posted by aths
Mir ist eigentlich alles recht, was dazu führt, dass sich die Shader-Technik endlich durchsetzt. Wenn 'Cg' dazu beitragen sollte, gut...

Mir ist eigentlich alles recht, wenn das Gameplay besser wird (ein Gameplay-Forum gibt es ja leider nicht). Also, wenn den Developern durch Zeit- und Kostenersparnis mehr Zeit für Spieltiefe und KI bleibt, sollte das in Ordnung sein.

[stefan42]

Den ersten Test finde ich sehr ernüchternd (Dabei habe ich mir nach den negativen Stimmen auf www.opengl.org advanced vorgenommen, das ganze objektiv anzugucken :) ):

Pixel Shader werden z.Z. nur für Direct X unterstützt - obwohl die OpenGL Shader leistungsfähiger sind!

Der Browser zeigt mir den größten Teil ausgegraut an (trotz GF 3 TI 200). Ich verstehe ja zum Teil, dass CG 1.1 und CG 2.0 noch nicht funktionieren, aber warum Hardware Shadow Maps nicht wollen, das verstehe ich nicht! Klappt's bei Euch?

Ja und warum sind die ganzen Bump Mapping Effekte erst für CG 2.0? DX8 und NV-OpenGL können das doch!

[zeckensack]

Originally posted by stefan42
... nach den negativen Stimmen auf www.opengl.org advanced ...Dann weißt du ja auch schon, was ich davon halte. Ich war nämlich der erste, der in dem Thread da drüben geantwortet hat *eg*

[stefan42]

Ja, das habe ich gesehen. So richtig neidisch bin ich aber, dass Du genau um 0:00 Uhr gepostet hast - Absicht?

Ich habe noch ein bisschen mehr gelesen und bin noch mehr enttäuscht: Der Sinn einer Hochsprache ist ja Unabhängigkeit von der darunterliegenden Schicht zu erhalten. Wenn ich mir die Einschränkungen bei den Profilen anschaue, dann glaube ich nicht, dass dieses Ziel erreicht wird. Es gibt zur Zeit keinerlei Emulation. Unterstützt die Hardware ein Feature nicht, dann wird das Programm halt nicht ausgeführt. Daher muß man wieder ganz genau wissen, was die Hardware kann - und die Abstraktion war völlig umsonst!

[aths]

Originally posted by stefan42
Der Browser zeigt mir den größten Teil ausgegraut an (trotz GF 3 TI 200).Ich kann alle Effekte aus dem Effects-Browser des 86-MB-Downloades sehen. (GF4 Ti)

[aths]

Originally posted by ow
Ist doch Klasse.
Anstatt irgendwelchen assembler code zu proggen generiert das Tool entsprechenden Code aus einer c-aehnlichen Sprache.
Das koennte die Entwicklungszeit fuer Engines stark verkuerzen. Das wage ich doch stark zu bezweifeln. Die Entwicklungszeit für Engines wird höchstens ein klein wenig verkürzt. Ehe man sich in Cg eingearbeitet hat, kann man den Effekt auch gleich direkt in "asm" schreiben. Der Vorteil von Cg könnte sein, dass sich Shader für DX8 (nach dem Update auf Cg2.0) dann auch für DX9 neu kompilieren lassen. nVidia übertreibt, was die Anwendung betrifft. Wie gesagt sehe ich forward compatibility als größtes Plus.

[Ceiser Söze]

Cg ist nun offiziell ein PR-Stunt (ZSack hatte wohl recht mit dem "Sommerloch" ;) ). Zitat von SA aus dem Beyond3D-Forum:

CG is simply Nvidia's tool kit and compiler implementation of the Microsoft DX9 standard HLSL High Level Shader Language. They just announced their implementation before the other 3d vendors and called it CG. Of course they (and other 3d vendors) played a key role in its development, but it is a DX9 open standard.

Verdammt, bin auch darauf reingefallen und habe geglaubt, dass nVIDIA diese Sprache mit Unterstützung von Microsoft entwickelt hat und nicht umgekehrt :D Naja, es wird wohl nichts so heiss gegessen, wie es gekocht wird :)

[Demirug]

@Ceiser Söze:

Wobei HLSL noch nicht entgültig ist und cg wohl in einigen Punkten etwas weiter geht. Ansonsten finde ich es aber trotzdem gut das man aus einer High Level sprache sowohl die OpenGL wie auch die DX Shader ableiten kann.

Mit OpenGL 2.0 wird zwar auch dort einen eigene Shadersprache eingebunden aber bei es ausreichend Karten mit OpenGL 2.0 unterstützung gibt ist eine Zwischenlösung erforderlich.

Wie bereits gesagt müssten sich eben nur die anderen Hersteller (ATi, Matrox, usw.) überwinden und cg unterstützen. Damit wäre eine bessere Unterstützung von Fragmentshader unter OpenGL möglich.

[Unregistered]

Weil die Diskussion im Cg-Thread im anderen Forum (http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&threadid=23167) von aths geschlossen wurde, kopiere ich das mal hier rein:

----------------------------

Ich hab grad die 3DCenter News gelesen und den Komentar zu Cg.

Ich persönlich würde Cg nicht so negativ sehen, vorallem nicht gegenüber Microsoft HLSL.

Unmöglich (sorry) fand ich folgenden Satz:
Die große Frage ist nur, ob ATi & Co. einen nVidia-Standard unterstützen werden, wenn es gleichzeitig alternativ einen freien Microsoft-Standard gibt.

Tschuldigung aber Microsoft is ja wohl NICHT frei und schon gar nicht alternativ.

Vergleich:
HLSL: NUR DirectX und NUR Windows
Cg: DirectX UND OpenGL sowie Windows, MacOS und Linux

Welche Programmiersprache bietet nun bitte mehr alternativen und ist freier ?

Natürlich wird es für ATi und Co komisch aussehen für ein nVidia Produkt etwas zu tun, aber nVidia ist, so glaube ich, nicht mit dem Ziel angetreten ein Monopol bei Programmiersprachen zu erlangen sondern mit dem Ziel neue Technologienen möglichst schnell in Spiele einfliesen zu lassen, und das egal auf welchem Betriebssystem und welche Schnittstelle. Und was man lobenswert hervorheben muss: egal welcher Graphikchip !!! (das ihr eigener momentan etwas bevorzugt wird ist klar, aber der Vorteil ist dahin sobald ATi und Matrox ihre eigenen Optimierungen herausgebracht haben) Und nVidia legt keinem einen Stein in den Weg: alles was ATi und Co brauchen ist (oder wird) Open Source sein.

Ich finde das Klasse.

Microsoft versucht nur wieder mit HLSL Windows als EINZIGE Spieleplattform zu positionieren.

Und ehrlich gesagt: Ich mag nVidia NICHT. Aber Cg verdient sich meiner Meinung nach ein extra Log und nVidia konnte damit bei mir sehr viele Sympatipunkte sammeln.

Gruß DATA

----------------------------

Ganz Deiner Meinung. 3DCenter möchte eben gern besonders "nVidia-kritisch" sein, aber schiesst dabei leider oft übers Ziel hinaus. Als ich die 3DCenter-Statements über den angeblich "freien Microsoft-Standard" gelesen habe, konnte ich wirklich nur noch den Kopf schütteln.

Microsofts DirectX-Monopol setzt nVidia die offene Unterstütztung für OpenGL, DirectX, MacOS, Windows und Linux entgegen.
Und das sogar mit Open Source.

Das muss man nVidia hoch anrechnen. Respekt, nVidia!

----------------------------

[tb]

Originally posted by Unregistered
Weil die Diskussion im Cg-Thread im anderen Forum (http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&threadid=23167) von aths geschlossen wurde, kopiere ich das mal hier rein:

----------------------------

Ich hab grad die 3DCenter News gelesen und den Komentar zu Cg.

Ich persönlich würde Cg nicht so negativ sehen, vorallem nicht gegenüber Microsoft HLSL.

Unmöglich (sorry) fand ich folgenden Satz:
Die große Frage ist nur, ob ATi & Co. einen nVidia-Standard unterstützen werden, wenn es gleichzeitig alternativ einen freien Microsoft-Standard gibt.

Tschuldigung aber Microsoft is ja wohl NICHT frei und schon gar nicht alternativ.

Vergleich:
HLSL: NUR DirectX und NUR Windows
Cg: DirectX UND OpenGL sowie Windows, MacOS und Linux

Welche Programmiersprache bietet nun bitte mehr alternativen und ist freier ?

Natürlich wird es für ATi und Co komisch aussehen für ein nVidia Produkt etwas zu tun, aber nVidia ist, so glaube ich, nicht mit dem Ziel angetreten ein Monopol bei Programmiersprachen zu erlangen sondern mit dem Ziel neue Technologienen möglichst schnell in Spiele einfliesen zu lassen, und das egal auf welchem Betriebssystem und welche Schnittstelle. Und was man lobenswert hervorheben muss: egal welcher Graphikchip !!! (das ihr eigener momentan etwas bevorzugt wird ist klar, aber der Vorteil ist dahin sobald ATi und Matrox ihre eigenen Optimierungen herausgebracht haben) Und nVidia legt keinem einen Stein in den Weg: alles was ATi und Co brauchen ist (oder wird) Open Source sein.

Ich finde das Klasse.

Microsoft versucht nur wieder mit HLSL Windows als EINZIGE Spieleplattform zu positionieren.

Und ehrlich gesagt: Ich mag nVidia NICHT. Aber Cg verdient sich meiner Meinung nach ein extra Log und nVidia konnte damit bei mir sehr viele Sympatipunkte sammeln.

Gruß DATA

----------------------------

Ganz Deiner Meinung. 3DCenter möchte eben gern besonders "nVidia-kritisch" sein, aber schiesst dabei leider oft übers Ziel hinaus. Als ich die 3DCenter-Statements über den angeblich "freien Microsoft-Standard" gelesen habe, konnte ich wirklich nur noch den Kopf schütteln.

Microsofts DirectX-Monopol setzt nVidia die offene Unterstütztung für OpenGL, DirectX, MacOS, Windows und Linux entgegen.
Und das sogar mit Open Source.

Das muss man nVidia hoch anrechnen. Respekt, nVidia!

----------------------------

Naja wirklich frei ist man bisher nicht:

"HLSL: NUR DirectX und NUR Windows "

- alle GPU Hersteller, leider nur Windows

"Cg: DirectX UND OpenGL sowie Windows, MacOS und Linux"

- viele Betriebssysteme, aber nur NVIDIA GPU's

Cg bietet kaum Vorteile, wenn man es mit Microsofts's DirectX 9.0 High Level Shader Language vergleicht, es bietet momentan nichtmal den gleichen Funktionsumfang. NVIDIA Hauptziel ist die Bindung vieler Entwickler an ihre GPU's nichts weiter, leider...

Erst mit OpenGL 2.0 ist man Betriebssystem und GPU unabhängig.

Thomas

[Demirug]

Originally posted by tb


Naja wirklich frei ist man bisher nicht:

"HLSL: NUR DirectX und NUR Windows "

- alle GPU Hersteller, leider nur Windows

"Cg: DirectX UND OpenGL sowie Windows, MacOS und Linux"

- viele Betriebssysteme, aber nur NVIDIA GPU's



Das ist so nicht ganz richtig. Wenn man Cg in Verbidnung mit DirectX benutzt kann man jede PS 1.1 fähige Karte benutzen. Desweiteren hat NVidia zugesichert das sie jederzeit bereit sind einen Allgemeinen OpenGL standard für Vertex und Fragmentshader zu unterstützen.

Bei den Vertexshadern ist das ja schon in sicht. Bei den Fragmentshadern wird es wohl etwas länger dauern.



Cg bietet kaum Vorteile, wenn man es mit Microsofts's DirectX 9.0 High Level Shader Language vergleicht, es bietet momentan nichtmal den gleichen Funktionsumfang. NVIDIA Hauptziel ist die Bindung vieler Entwickler an ihre GPU's nichts weiter, leider...



Mit Cg kann man auch Pixel/Fragmentshader schreiben bei DX HLSL ist das im Moment wohl nicht vorgesehen. Das mit dem Binden kann ich leider nicht ganz nachvollziehen.

Bei DX ist so etwas ja nicht möglich. Es werden im Moment zwar nur PS 1.1 unterstützt aber niemand hindert ATi daran sobald der Parsercode freigeben ist für PS 1.4 ein AddOn zu schreiben.

Bei OpenGL ist das ebenfalls nicht möglich da man im Moment sowieso für jede Karte die Vertex und Fragmentshader mit anderen Extensions programmieren muss. Wenn die andern Chiphersteller von Cg nichts wissen wollen bleibt halt alles beim alten mit dem Unterschied das es für die NVidia Karten eben bessere Entwicklertools gibt. Als Einschrägung erkenne ich natürlich an das damit die Bevorzugung von NVidia als primären Entwicklungskarte ausgebaut wird. Dies führt dann dazu das die Spiele dort am besten laufen.


Erst mit OpenGL 2.0 ist man Betriebssystem und GPU unabhängig.
Thomas

Die Betriebssystem unabhängigkeit ist im Spielesektor uninteresant. Bei Linux und Mac sind keine Umsätze zu erwarten. Bei der GPU/VPU unabhängigkeit stimme ich dir mit Einschrägungen zu. OpenGL setzt einen Hardwarelevel vorraus der etwa auf DX9 ebene liegt. Alle vorhergehenden Karte dürften nicht in der Lage sein OpenGL 2.0 ausreichend zu unterstützen. Bevor der Markt also nicht ausreichend mit entsprechender Hardware durchsetzt ist kann man keinen OpenGL 2.0 only Engine schreiben. Diesen Zustand wird wahrscheinlich noch mindestens 4 Jahre anhalten und deshalb wird für diesen Zeitraum eine Lösung benötigt. Und diese könnte Cg heissen.

[tb]

Originally posted by Demirug


Das ist so nicht ganz richtig. Wenn man Cg in Verbidnung mit DirectX benutzt kann man jede PS 1.1 fähige Karte benutzen. Desweiteren hat NVidia zugesichert das sie jederzeit bereit sind einen Allgemeinen OpenGL standard für Vertex und Fragmentshader zu unterstützen.

Bei den Vertexshadern ist das ja schon in sicht. Bei den Fragmentshadern wird es wohl etwas länger dauern.


Zu Punkt eins meinte ich ja auch nur, dass es nur unter Microsoft läuft, dass alle Karten mit HW-PS dies können hab ich nie anders gemeint.



Mit Cg kann man auch Pixel/Fragmentshader schreiben bei DX HLSL ist das im Moment wohl nicht vorgesehen. Das mit dem Binden kann ich leider nicht ganz nachvollziehen.

Bei DX ist so etwas ja nicht möglich. Es werden im Moment zwar nur PS 1.1 unterstützt aber niemand hindert ATi daran sobald der Parsercode freigeben ist für PS 1.4 ein AddOn zu schreiben.



Leider kann ich nicht genauer ins Detail gehen (NDA), PS und VS (alle Versionen!) werden von Microsofts HLSL unterstützt, somit gibt es dann wirklich keine Grund, NVIDIA's Lösung zu verwenden.


Bei OpenGL ist das ebenfalls nicht möglich da man im Moment sowieso für jede Karte die Vertex und Fragmentshader mit anderen Extensions programmieren muss. Wenn die andern Chiphersteller von Cg nichts wissen wollen bleibt halt alles beim alten mit dem Unterschied das es für die NVidia Karten eben bessere Entwicklertools gibt. Als Einschrägung erkenne ich natürlich an das damit die Bevorzugung von NVidia als primären Entwicklungskarte ausgebaut wird. Dies führt dann dazu das die Spiele dort am besten laufen.


Da stimme ich Die voll zu.


Die Betriebssystem unabhängigkeit ist im Spielesektor uninteresant. Bei Linux und Mac sind keine Umsätze zu erwarten. Bei der GPU/VPU unabhängigkeit stimme ich dir mit Einschrägungen zu. OpenGL setzt einen Hardwarelevel vorraus der etwa auf DX9 ebene liegt. Alle vorhergehenden Karte dürften nicht in der Lage sein OpenGL 2.0 ausreichend zu unterstützen. Bevor der Markt also nicht ausreichend mit entsprechender Hardware durchsetzt ist kann man keinen OpenGL 2.0 only Engine schreiben. Diesen Zustand wird wahrscheinlich noch mindestens 4 Jahre anhalten und deshalb wird für diesen Zeitraum eine Lösung benötigt. Und diese könnte Cg heissen.

Naja 4 Jahre halte ich für ein wenig lang, jedenfalls von Standpunkt eines Softwareentwicklers, doch hier kann man nur abwarten, was die Zeit bringt.

Gruß
Thomas

[zeckensack]

Ich muß jetzt auch nochmal meinen Senf dazu ablassen:

Unter DX gibt's die passenden Schnittstellen bereits. Alles sehr Assembler-artig, wie ich höre ( *eg* ).

Unter OpenGL zeigt sich, wie großer Schrott NV's fragment shader ist. Wenn NV ähnliche Funktionalität wie ATi anbieten würde, bräuchten sie diese 'neue Sprache' - zumindest unter OpenGL - nicht. Außerdem gibt's für GL das Tool 'nvparse', welches bereits seit der Geforce 3 das gleiche leistet.

Es ist idiotisch anzunehmen, daß die Portabilität zwischen DX und OpenGL irgendjemanden praktisch vorwärts bringen wird. Entweder ich schreibe eine DX-Engine, oder ich schreibe eine OpenGL-Engine. Ausnahme mag hier die Unreal-Engine sein. Doch auch hier beschränken sich die Unterschiede wohl kaum auf die Shader, da muß wesentlich mehr gemacht werden.

MacOS und Linux? Wird wieder "OpenGL only". NVIDIA (all caps!) sollten lieber ihre OpenGL-Extensions für Fragment Shader aufmöbeln.

Ich kann - mit jeder Menge gutem Willen - nur ein Argument für CG (was witzigerweise Standardabküzung für computer generated (graphics) ist :bonk: ) erkennen:

1)Man will Seppeln, die nicht in der Lage sind, das Programmiertechnische Konzept von Shadern zu erfassen, trotzdem ermöglichen, ebendiese zu benutzen.

IMO sollte ein Programmierer nichts machen, was er nicht auch versteht.

[tb]

Originally posted by zeckensack
Ich muß jetzt auch nochmal meinen Senf dazu ablassen:

Unter DX gibt's die passenden Schnittstellen bereits. Alles sehr Assembler-artig, wie ich höre ( *eg* ).


eben, deswegen mach höhere Sprachen auch Sinn


Unter OpenGL zeigt sich, wie großer Schrott NV's fragment shader ist. Wenn NV ähnliche Funktionalität wie ATi anbieten würde, bräuchten sie diese 'neue Sprache' - zumindest unter OpenGL - nicht. Außerdem gibt's für GL das Tool 'nvparse', welches bereits seit der Geforce 3 das gleiche leistet.

Es ist idiotisch anzunehmen, daß die Portabilität zwischen DX und OpenGL irgendjemanden praktisch vorwärts bringen wird. Entweder ich schreibe eine DX-Engine, oder ich schreibe eine OpenGL-Engine. Ausnahme mag hier die Unreal-Engine sein. Doch auch hier beschränken sich die Unterschiede wohl kaum auf die Shader, da muß wesentlich mehr gemacht werden.

MacOS und Linux? Wird wieder "OpenGL only". NVIDIA (all caps!) sollten lieber ihre OpenGL-Extensions für Fragment Shader aufmöbeln.

Ich kann - mit jeder Menge gutem Willen - nur ein Argument für CG (was witzigerweise Standardabküzung für computer generated (graphics) ist :bonk: ) erkennen:

1)Man will Seppeln, die nicht in der Lage sind, das Programmiertechnische Konzept von Shadern zu erfassen, trotzdem ermöglichen, ebendiese zu benutzen.

IMO sollte ein Programmierer nichts machen, was er nicht auch versteht.

Je komplexer und leistungsfähiger die Shader werden, desto aufwendiger (sprich kostet mehr Zeit -> Zeit == Geld) wird auch deren Programmierung. Keiner würde heute mehr Windows XP in Assembler schreiben - die Codemassen wären kaum noch zu bewältigen, weswegen eine höhere Sprache sinnvoll ist, mit steigender Komplexität sollte sich auch der Abstraktionsgrad der Sprache erhöhen, da der normale Mensch sonst an ihr zerbricht. Wem nützen Shader, die keiner verwendet...

Gruß
Thomas

[aths]

Was zeckensack sagt ist hart, aber gerecht. Jedenfalls, wenn ich meine persönliche Erfahrung zur Beurteilung heran ziehen darf: Seit einiger Zeit überlege ich, wie sich EMBM mit PS.1.3 (oder halt 1.1) realisieren lassen würde. Cg hat mich der Lösung keinen Schritt näher gebracht.

[tb]

Okay, da geb ich Dir recht. Zu Deinem Problem, vielleicht hilft Dir Wolfgang Engels Code:

<snip>
Ok, I got it. Here is the solution:

First of all, there is a difference in the usage of the texture stages
between environment mapping with a pixel shader (means texbem, texbeml
or bem) and environment mapping with the DX 6/7 multitexturing unit.
texbem (texbeml or bem) needs the matrix data connected to the texture
stage that is sampled. This is the environment map. Environment mapping
with the DX 6/7 multitexturing unit needs the matrix data connected to
the texture stage used by the bump map:

// texture stages for environment mapping
// with the multitexturing unit:
// color map
SetTexture( 0, m_pEarthTexture );
SetTextureStageState( 0, D3DTSS_TEXCOORDINDEX, 1 );
SetTextureStageState( 0, D3DTSS_COLOROP, D3DTOP_SELECTARG1);
SetTextureStageState( 0, D3DTSS_COLORARG1, D3DTA_TEXTURE );
// bump map
SetTexture( 1, m_psBumpMap );
SetTextureStageState(1, D3DTSS_TEXCOORDINDEX, 1);
SetTextureStageState(1, D3DTSS_COLOROP, D3DTOP_BUMPENVMAP );
SetTextureStageState( 1, D3DTSS_COLORARG1, D3DTA_TEXTURE );
SetTextureStageState( 1, D3DTSS_COLORARG2, D3DTA_CURRENT );
SetTextureStageState( 1, D3DTSS_BUMPENVMAT00, F2DW(0.5f) );
SetTextureStageState( 1, D3DTSS_BUMPENVMAT01, F2DW(0.0f) );
SetTextureStageState( 1, D3DTSS_BUMPENVMAT10, F2DW(0.0f) );
SetTextureStageState( 1, D3DTSS_BUMPENVMAT11, F2DW(0.5f) );
// environment map
SetTexture(2, m_pEnvMapTexture );
SetTextureStageState(2, D3DTSS_TEXCOORDINDEX, 0 );
SetTextureStageState(2, D3DTSS_COLOROP, D3DTOP_ADD);
SetTextureStageState(2, D3DTSS_COLORARG1, D3DTA_TEXTURE );
SetTextureStageState(2, D3DTSS_COLORARG2, D3DTA_CURRENT );

// texture stages for environment mapping
// with a pixel shader:
SetRenderState(D3DRS_WRAP0,D3DWRAP_U|D3DWRAP_V);
// color map
SetTexture( 0, m_pEarthTexture );
SetTextureStageState(0, D3DTSS_TEXCOORDINDEX, 1);
// bump map
SetTexture(1, m_psBumpMap);
SetTextureStageState(1, D3DTSS_TEXCOORDINDEX, 1);
// enviroment map
SetTexture(2, m_pEnvMapTexture);
SetTextureStageState(2, D3DTSS_TEXCOORDINDEX, 0);
SetTextureStageState(2, D3DTSS_BUMPENVMAT00, F2DW(0.5f));
SetTextureStageState(2, D3DTSS_BUMPENVMAT01, F2DW(0.0f));
SetTextureStageState(2, D3DTSS_BUMPENVMAT10, F2DW(0.0f));
SetTextureStageState(2, D3DTSS_BUMPENVMAT11, F2DW(0.5f));

And here are the ps.1.1 and ps.1.4 shaders:

; t2 environment map
; (t2) texture coordinates environment map
; t1 du/dv perturbation data
ps.1.1
tex t0 ; color map
tex t1 ; bump map
texbem t2, t1 ; Perturb and then sample the
; environment map.
add r0, t2, t0

ps.1.4
; r2 environment map texture coordinates
; r1 du/dv perturbation data
def c0, 0.0, 0.0, 0.0, 0.0
texld r1, t1 ; bump map
texcrd r2.rgb, t2
; (Given n == dest register #)
; dest.r = src0.r + D3DTSS_BUMPENVMAT00(stage n)
; * src1.r + D3DTSS_BUMPENVMAT10(stage n)
; * src1.g
; dest.g = src0.g + D3DTSS_BUMPENVMAT01(stage n)
; * src1.r + D3DTSS_BUMPENVMAT11(stage n)
; * src1.g
bem r2.rg, r2, r1 ; perturb
; r2.rg = tex coordinates to sample environment map
phase
texld r0, t0 ; color map
texld r2, r2 ; environment map
add r0, r0, r2

I appreciate any comment.

- Wolf
<snip>

Gruß
Thomas

[Demirug]

Originally posted by tb
Naja 4 Jahre halte ich für ein wenig lang, jedenfalls von Standpunkt eines Softwareentwicklers, doch hier kann man nur abwarten, was die Zeit bringt.


Aus der Sicht der Softwareentwicklung sind es aber auch noch mindestens 2 Jahre für die eine Lösung gefunden werden muss. Natürlich könnte man bei DX Engines auch die HLSL von DX benutzen da aber Cg ja dazu kompatibel gehalten werden soll ist es im Prinzip egal was man benutzt.

[Demirug]

Originally posted by zeckensack
Es ist idiotisch anzunehmen, daß die Portabilität zwischen DX und OpenGL irgendjemanden praktisch vorwärts bringen wird. Entweder ich schreibe eine DX-Engine, oder ich schreibe eine OpenGL-Engine. Ausnahme mag hier die Unreal-Engine sein. Doch auch hier beschränken sich die Unterschiede wohl kaum auf die Shader, da muß wesentlich mehr gemacht werden.


Da ja Cg zu der HLSL von DX kompatibel gehalten werden soll macht es Cg möglich auch in OpenGL bassierender Designsoftware die gleichen Shader einzusetzen um zu überprüfen ob das Ergebniss stimmt.


MacOS und Linux? Wird wieder "OpenGL only". NVIDIA (all caps!) sollten lieber ihre OpenGL-Extensions für Fragment Shader aufmöbeln.


Niemand hält ATi davon ab ebenfalls einen Compiler zu schreiben der die HL-Fragmentshader für die ATi Schaderextensions aufbereitet. Deinem Argument mit den Extensions kann ich nicht ganz folgen. Die Extensions bilden doch nur die Shaderarchitektur der NVidia Karten ab. Was sollten sie da aufmöbeln??? Mit den derzeitigen Extensions hat man wahscheinlich die grösst mögliche kontrolle über die Hardware und solange eine Extension Karten/Hersteller spezifisch ist sollte sie IMO genau das erlauben.


Ich kann - mit jeder Menge gutem Willen - nur ein Argument für CG (was witzigerweise Standardabküzung für computer generated (graphics) ist :bonk: ) erkennen:

1)Man will Seppeln, die nicht in der Lage sind, das Programmiertechnische Konzept von Shadern zu erfassen, trotzdem ermöglichen, ebendiese zu benutzen.

IMO sollte ein Programmierer nichts machen, was er nicht auch versteht.

Diese "Seppeln" sind Grafiker und Designer. Die im Moment ständigen Rücksprachen zwischen dieser Gruppe und den Programmieren kostet eine Menge zeit (=Geld). Gibt man aber nun den Grafikern eine einfache Sprache mit der sie ihere Effekte selbst erstellen können müssen sie nicht ständig zu den Programmieren rennen um nachzufragen ob ihere vorstellungen realisiert werden können und ob nicht jemand mal schnell einen solchen shader schreiben kann. Dieser muss dann oft noch ein paar mal geändert werden. Dies hält die Entwickler von der Arbeit die sie eigentlich tuhen sollen ab.

[Leonidas]

Originally posted by Unregistered

Vergleich:
HLSL: NUR DirectX und NUR Windows
Cg: DirectX UND OpenGL sowie Windows, MacOS und Linux

Welche Programmiersprache bietet nun bitte mehr alternativen und ist freier ?



Sorry, aber sowohl das Wort "frei" als auch das Wort "alternativ" waren meinerseits nicht in dieser harten Bedeutung gesehen.

Zur Aufklärung:

1. Für ATi ist Cg eine Alternative zu HLSL und HLSL eine Alternative zu Cg. Es geht hier nicht um mehr Alternativen, sondern um die Alternative an sich.

2. Für ATi ist das Angebot eines Nicht-Marktteilnehmers, mit dem man sowieso auf anderen Ebenen zusammenarbeiten muß (DirectX), mit Sicherheit freier als das Angebot eines direkten Mitkonkurrenten. Auch wenn die anfänglichen Bedingungen gleich wären.

[Leonidas]

Originally posted by Unregistered
Als ich die 3DCenter-Statements über den angeblich "freien Microsoft-Standard" gelesen habe, konnte ich wirklich nur noch den Kopf schütteln.




Sorry, schießt Du nicht über das Ziel hinaus? Ich hab keine Statements über HLSL bezüglich seiner Freiheit abgelassen. Und wie schon ausgeführt: Man kann HLSL als freien Standard bezeichnen, denn er steht jedem offen.

Wenn ich "freier Standard" schreibe, meine ich nicht, daß dieser keine Einschränkungen hat, sondern das er jedem offen steht. Es gibt meines Erachtens gar keine andere Definition eines "freien Standards". Dieser bedeutet doch nicht, daß man alles machen kann - ein Standard ist immer eine Einschränkung. Deine Interpretation von "frei = muß OpenGL können" ist schlicht Nonsens. "Frei" heißt, jeder darf mitmachen, nichts anderes. So gesehen ist HLSL definitiv ein freier Standard, womit Deine komplette Argumentation zusammenbricht. PS: Cg ist damit natürlich auch ein freier Standard.

[Unregistered]

Originally posted by Leonidas PS: Cg ist damit natürlich auch ein freier Standard.

Interessanter Thread dazu bei Beyond3d: http://64.246.22.60/~admin61/forum/viewtopic.php?t=1259

Kristof (PowerVR):

... all that NVIDIA has given is a definition of the syntax of which they have full control (so don't count on seeing functionality that NVIDIAs hardware does not support).

From posts on the cgshaders.org forums I get the impression that Cg is a subset of something bigger, being the Microsoft Higher Level Shading Language which will, I assume, be introduced at some time. This Microsoft language will not be NVIDIA controlled, the syntax wil be Microsoft controlled meaning that there is a bigger chance of getting new functionality in, no matter who might support or not support it. So Cg seems to be NVIDIAs specific version of this, if this is indeed how it is then why push developers to support the subset of funtionality that Cg is? Developers should support the bigger thing, granted Cg seems to be released first which given developers something to play and try with, but definitely not something they should stick to.

[Quasar]

Kristof ist natürlich diesbezgl. eine absolut objektive und unvoreingenommene Quelle, oder?

[StefanV]

Originally posted by Quasar
Kristof ist natürlich diesbezgl. eine absolut objektive und unvoreingenommene Quelle, oder?

Klar *eg*

[tb]

Er hat aber recht. Wenn DX9 verfügbar ist, wird man sehen, wieviel Cg bringt, oder eben auch nicht...

Thomas

[StefanV]

Originally posted by tb
Er hat aber recht. Wenn DX9 verfügbar ist, wird man sehen, wieviel Cg bringt, oder eben auch nicht...

Thomas

Denke ich auch.

Soganz traue ich NV nicht.
Und wenn man berücksichtigt, daß sich M$ bei DX9 mehr an MGA/ATI orientiert hat auch daß ATI ständiges Mitglied in der OGL Versammlung wurde, NV wurde es nicht, dann frage ich mich, was NV mit cg bezweckt.

Aus 'gutem Willen' macht man sowas sicher nicht...

[Razor]

Hmmm... ich weiß nicht, was die leutz hier haben...

Ist doch ein Technologie-Forum oder etwa nicht ?
Wieso wird hier dann (vereinzelt) GEFAHR gerufen ?
nVidia kommt jetzt mit eigener API !
GEFAHR !!!!

Sorry, Leute, aber wenn ich das richtig verstanden habe, dann handelt es sich bei CG um etwa Folgendes:

Es ist schlicht eine Hochsprach zur Programmierung von Shader-Effekten.
Nicht mehr und auch nicht weniger !

Sie kann benutzt werden oder eben auch nicht, da es ja noch die M$-Alternative gibt.

Wo ist also das Problem ?
???

Wenn das Zeug besser ist, als das von M$, dann muß sich M$ eben mehr anstrengen. Wenn es gut ist und den Proggern Arbeit abnimmt - gut - wenn es schlecht ist und die Progger es deswegen nicht nutzen - auch gut - wenn das Ganze dann auch nch OpenSource ist - noch besser -.

Warum sollte sich ATI nicht daran beteiligen ?
Sie hätten dadurch erstmalig die Möglichkeit, direkt von den Engine-Proggern unterstützt zu werden, weil sie selber dafür sorgen können Ihre Hardware (via Plugin) dortin vernünftig einzubinden.

Ich frage also nochmal:
WO IST DAS PROBLEM ?

Und was zum Geier hat das Ganze mit 'ner neuen API zu tun ?
(ich weiß, nur wenige sind damit gekommen, aber trotzdem...)

In diesem Sinne

Razor

[aths]

tb,

vielen Dank für den Ausschnitt zu EMBM. (Das werde ich nach den Prüfungen mal eingehend studieren.)

[tb]

Probleme seh ich mit Cg eigentlich keine - es wird ja keiner gezungen - hier ging es mehr um das WARUM?

Warum entwicklet NVIDIA ne eigene abgespeckte Version von MS DX9 HLSL?

Um die Entwickler langsam daran zu gewöhnen, bis DX9 fertig ist?

Einfach nur als kurzzeitige Übergangslösung?

Um die Shader populärer zu machen, damit sie endlich heufiger eingesetzt werden?

Will man andere Hersteller "ärgern"?

Fragen über Fragen...

Thomas

[Quasar]

Naja, wie lange kann's noch dauern, bis die HLSL von MS endlich verabschiedet ist? Da wurschteln mit Sicherheit noch eine Menge mehr Firmen mit drin rum, und die wollen genauso sicher alle Eigenheiten ihrer Next-Gen Chips berücksichtigt sehen.

Herbst? Winter? Nächstes Jahr?

Was zum Geier ist daran verwerflich, ein Toolkit anzubieten, daß es den Entwicklern einfacher macht, gewünschte Effekte zu implementieren?

Hier drängt sich wirklich mal wieder der Eindruck auf, diese Geschichte würde nur so kritisch betrachtet, weil sie von nV kommt.

AFAIK gibt es von einer Menge anderer Firmen auch Toolkits um Entwickler zu unterstützen, ohne das die gesamte Computerindustrie nun unter deren Joch steht.

tststs....

[Unregistered]

[SIZE=1]Originally posted by Razor
Es ist schlicht eine Hochsprach zur Programmierung von Shader-Effekten. Nicht mehr und auch nicht weniger !

Eben, und damit kontrolliert NVIDIA, was für Möglichkeiten diese Sprache hat, nicht mehr und nicht weniger!


Warum sollte sich ATI nicht daran beteiligen ?


Weil sie mit Cg ihre Hardware nicht voll nutzen können, weil NVIDIA durch die Kontrolle der Shader-Syntax bestimmt, was man mit der Sprache tun darf und was nicht? Microsoft baut in die API auch ATI-spezifische Dinge ein, die NVIDIA nicht hat, NVIDIA wird dies bei Cg nicht zulassen.

Und was zum Geier hat das Ganze mit 'ner neuen API zu tun ?

In Zukunft besteht der 3D-Teil einer API fast nur noch aus dieser Shader-Sprache, die Teil der API ist. Alles andere der API (veraltete Funktionen für festverdrahtete Funktionen) wird innerhalb von ein bis zwei Jahren völlig unwichtig, nur noch die Fähigkeiten der Shader-Sprache der API sind wichtig. Und da NVIDIA eine neue Sprache erfunden und die Rechte dazu hat, ist dies wie eine dritte proprietäre API zusätzlich zu den herstellerunabhängigen Hochsprachen MS HLSL und OpenGL2.0 SL.

Nur das andere DX8-Karten diese Cg-Shader auch im langsamen "Kompatibilitätsmodus" nutzen könnten macht Cg noch lange nicht zur "offenen" und "freien" Shader-Sprache. Das ist fast so wie wenn NVIDIA Glide veröffentlichen würde, aber im Gegensatz zu 3dfx eben die dazu passenden Glide-D3D-Wrapper nicht verbietet, sondern gleich mitliefert.

[tb]

MS HLSL kommt mit DX9, so etwa im August....

Es ist nichts verwerfliches an NVIDIAs's Handlungen - jedoch sollte man bei allem PR Hype vorsichtig sein und auch ein wenig zwischen den Zeilen lesen.

Thomas

[aths]

Originally posted by Quasar
Hier drängt sich wirklich mal wieder der Eindruck auf, diese Geschichte würde nur so kritisch betrachtet, weil sie von nV kommt.Das klingt so, als wenn das ungerechtfertigt wäre.

[Quasar]

Originally posted by aths
Das klingt so, als wenn das ungerechtfertigt wäre.

Nein, aber es klingt so, als würden hier wieder seltsame Unterstellungen betrieben...

Ein Toolkit, nicht mehr und nicht weniger. Und dargestellt wird es, als wäre das der Versuch die Weltherrschaft an sich zu reissen...

[Unregistered]

Originally posted by Quasar
Ein Toolkit, nicht mehr und nicht weniger.

Nein. Wäre es nur ein Toolkit, so hätte man die MS HLSL als Sprache gewählt und ein paar Tools drum rum gestülpt. Hat man aber nicht. Cg bringt aber eine EIGENE Sprache, mit einer eigenen Spezifikation, die unter der vollen Kontrolle von NVIDIA liegt.

[Quasar]

So sieht's aber laut den Aussagen einiger, die mehr vom Programmieren verstehen als ich, beileibe nicht aus...

[aths]

Ich denke, dass keine der beiden "Extrem"-Seiten vollständig Recht hat.

[Unregistered]

Der Codeplay-Gründer versteht sicher genug vom Programmieren:

http://www.theregus.com/content/54/25251.html


Why Nvidia's Cg won't work
By Andrew Richards, Codeplay
Posted: 06/14/2002 at 12:06 EST


Andrew Richards, founder of Codeplay, the London based designer cutting-edge computer and console games development tools responds to yesterday's Nvidia Cg - 'C for graphics' - launch.

Nvidia produces capable graphics hardware which, since the introduction of the GeForce 3, contains a degree of programmability. It is programmable in the powerful but low-level pixel and vertex shader level, these being hardware-specific features of their products.

Nvidia now advocates a simplified cut-down language, known as Cg, which allows programming of those low level pixel and vertex shaders. It is promoting this as an open standard, being suitable to programme all 'GPUs' or graphics processor units.

However, not all GPUs are created equal, and differences will become ever greater. With the PlayStation 2, SCEI demonstrated a programmable graphics pipeline from higher up in the rendering process, which has different demands of a graphics programming language.

In the future, graphics hardware will incorporate both low level pixel and vertex shaders as demonstrated by Nvidia and higher-level general programmability as demonstrated in the PlayStation2. The Cg language is not sufficiently well specified for such hardware, particularly with reference to:


No break, continue, goto, switch, case, default. These are useful features that can be used without penalty on other vector processors.


No pointers. This is Cg's most serious omission. Pointers are necessary for storing scene graphs, so this will quickly become a serious omission for vector processors that can store and process the entire scene or even sections of it.


No integers. This may be appropriate to NVIDIA, but is not a universal design decision.


Arrays use float indices. This is an odd design decision, relevant to DirectX 8 and Nvidia only.

Nvidia has introduced Cg as a standard, fully backward- and forward-compatible. However, the existence of reserved keywords (such as break and continue, mentioned above) is a clear indication that functions will be added when Nvidia hardware supports it. This is not conducive to future compatibility.

Codeplay believes that Cg is inadequate for some current, and more future, GPUs. Most importantly, standard rendering code needs to move onto graphics processors, and Cg is not sufficiently flexible for this type of code.

Overall, Cg is not a generic language for graphics programming; it is a language for NVIDIA's current generation of graphics card. It has a different set of goals from what’s required to design computer graphics at the heart of the successful computer games of tomorrow.”

Instead, the right approach is to use standard C/C++, and to make the compiler sufficiently advanced to be able to produce high quality code for dedicated hardware. This facilitates programming of advanced hardware at both the low-level of shaders and the higher level of the rendering pipeline, and is the language familiar to millions of programmers.

Codeplay has demonstrated the implementation of a C/C++ compiler for a specialist graphics co-processor in their VectorC {VU} compiler for PlayStation 2. This approach will be extended to embrace emerging new hardware features without the need of proprietary ‘standards’.

Computer games are an intricate blend of immersive graphics and creative gameplay programming. With cross-platform standards and development tools that work as programmers demand, game developers can continue to produce radical-looking games beyond the vision of hardware engineers, thanks to creative talented software engineering. ®

[Quasar]

Bedenken zur Kenntnis genommen, aber es wäre ja auch zu blöde für die Firma Codeplay, wenn ihre Engine nun aufgrund mächtiger Toolkits kaum noch gebraucht würde, oder?

Und das ein Toolkit eines Chipherstellers besonders gut mit den eigenen Produkten zurechtkommt, ist doch einleuchtend, oder?

BTW, die noch fehlenden Dinge, die Mr. Richards bemängelt, sollten sich durch Plug-ins realisieren lassen, oder liege ich da falsch?

[aths]

Quasar, was er bemängelt hat lässt sich kaum durch Plugins regeln. Er ging z.B. auf fehlende Sprachkonstrukte ein.

[Quasar]

Wer sagt denn, daß cg nicht weiterentwickelt wird? Wär' doch blöd für zukünftige nV-GPUs, wenn sich ihre Funktionalität nicht nutzen liesse...

However, the existence of reserved keywords (such as break and continue, mentioned above) is a clear indication that functions will be added when Nvidia hardware supports it.

[Demirug]

Für diese Marketing Leistung haben sich Andrew Richards und Codeplay abplaus verdiehnt. Man benutzt die Vorstellung einer Technologie (die kostenloss abgegeben wird) um für ein eigenes Produkt (VectorC) Werbung zu machen.

Andrew Richards fordert das man für die Shaderprogrammierung den kompletten C/C++ standard zur verfügung hat. Wenn er sich mit Grafikkarten auskennt (sollte er eigentlich) müsste er wiesen das es im Moment maximal einen Chip (P10) gibt der als Ziel für eine solche Sprache geeignet wäre.

Das derzeitige BETA von Cg enthält lediglich Sprachelemente die sich in Verbindung mit DX8 Karten auch einsetzten lassen. Mit der Final sollen weitere Elemente hinzugefügt werden.

Am besten finde ich aber den indirekten Vergleich der VU Einheit der PS2 mit einer PC Grafikkarte. Wenn Codeplay der Meinung ist das Cg nicht weit genung geht hält sie niemand davon ab ein VectorC für GPUs zu schreiben. Nur kaufen würde es wahrscheinlich keiner da man dann zwar die ganzen schönen C sprachelemente hätte aber sie nicht benutzen kann weil die Ziel GPU zum Beispiel überhaupt keine Schleifen unterstützt.

IMO sind sowohl Cg (NVidia) als auch HLSL (MS) zwar schönne Arbeitserleichterungen aber wirklich nicht der Weisheit letzter Schluss sonder höchstens ein Schritt in die richtige Richtung.

[Unregistered]

Originally posted by Quasar
Wer sagt denn, daß cg nicht weiterentwickelt wird? Wär' doch blöd für zukünftige nV-GPUs, wenn sich ihre Funktionalität nicht nutzen liesse...

Die Dinge werden erst dann eingeführt, wenn NVIDIA GPUs die Fähigkeiten dazu haben. NVIDIA kontrolliert so, welche Fähigkeiten von GPUs zu welchem Zeitpunkt genutzt werden können und welche nicht. Entwickler die Cg nutzen würden, würden immer an die (beschränkten) Fähigkeiten von NVIDIA GPUs gebunden sein. Und findet NVIDIA ein Feature oder eine Design-Philisophie schlecht, kommt es gar nie in Cg rein, obwohl andere Shader-Sprachen dies können.

Cg ist eigentlich völlig überflüssig, denn es gibt die Microsoft High Level Shading Language und bald die OpenGL 2.0 Shading Language. Es gibt einfach keinen Grund, eine proprietäre Sprache zusätzlich zu zwei Standards einzuführen, abgesehen von den Vorteilen für NVIDIA selbst. Den Vorteil von OpenGL und DirectX als mögliche gleichzeitige low-level-API-Platform erreicht man auch, indem man einfach einen OpenGL-Compiler für die Microsoft Shading-Language schreibt. Dazu bräuchte man keine neue proprietäre Shader-Sprache.

[Quasar]

Originally posted by Unregistered
Die Dinge werden erst dann eingeführt, wenn NVIDIA GPUs die Fähigkeiten dazu haben. NVIDIA kontrolliert so, welche Fähigkeiten von GPUs zu welchem Zeitpunkt genutzt werden können und welche nicht. Entwickler die Cg nutzen würden, würden immer an die (beschränkten) Fähigkeiten von NVIDIA GPUs gebunden sein. Und findet NVIDIA ein Feature oder eine Design-Philisophie schlecht, kommt es gar nie in Cg rein, obwohl andere Shader-Sprachen dies können.

Liesse sich bis hierhin 1:1 auf MS´ HLSL übertragen...


Cg ist eigentlich völlig überflüssig, denn es gibt die Microsoft High Level Shading Language und bald die OpenGL 2.0 Shading Language. Es gibt einfach keinen Grund, eine proprietäre Sprache zusätzlich zu zwei Standards einzuführen, abgesehen von den Vorteilen für NVIDIA selbst. Den Vorteil von OpenGL und DirectX als mögliche gleichzeitige low-level-API-Platform erreicht man auch, indem man einfach einen OpenGL-Compiler für die Microsoft Shading-Language schreibt. Dazu bräuchte man keine neue proprietäre Shader-Sprache.

Weder MS´ HLSL noch das Zeug für oGL 2.0 ist verfügbar, und auch ein vernünftiger Compiler will erstmal geschrieben sein.
Deine zwei Standards sehe ich auch nicht so richtig, denn der eine existiert bisher nur unter NDA (bzw. ist im Falle der HLSL noch nicht durch) und der andere ist noch nichtmal in seiner Spezifikation festgelegt, von der Shading Language erstmal abgesehen.

Und unter "proprietär" scheinen wir wohl etwas grundsätzlich anderes zu verstehen...

edit:
Eine runde Klammer durch eine eckige ersetzt...

[Unregistered]

[SIZE=1]Originally posted by Quasar
Liesse sich bis hierhin 1:1 auf MS´ HLSL übertragen...


Wieso? Microsoft bringt Features in die API, welche NVIDIA zum jeweiligen Zeitpunkt jeweils nicht in ihrer Hardware hat (DXTC, EMBM, Multisample Buffer, Pixel Shader 1.4, PN-Triangles nur als Beispiele).


Deine zwei Standards sehe ich auch nicht so richtig, denn der eine existiert bisher nur unter NDA (bzw. ist im Falle der HLSL noch nicht durch) und der andere ist noch nichtmal in seiner Spezifikation festgelegt, von der Shading Language erstmal abgesehen.
[QUOTE]

Die DX9 Beta ist bereits seit Wochen drausen, die Final wird für August erwartet. 30-60 Tage bei einer Spieleentwicklungszeit von zwei und mehr Jahren rechtfertigen die Veröffentlichung einer eigenen proprietären Shading-Sprache, die derzeit ebenfalls nur Beta ist?

[QUOTE]Und unter "proprietär" scheinen wir wohl etwas grundsätzlich anderes zu verstehen...

NVIDIA dagegen hält die IP an der Cg Shading Language und definiert selbst, wie diese auszusehen hat. Ausserdem ist man Enwickler der dazu passenden Hardware. Ein klassischer Fall von proprietär.

[Quasar]

Trotzdem entscheidet MS, was reinkommt, und was nicht. Also auch hier eine einseitige Entscheidungsfindung, nicht wie bei einem Komittee à la OpenGL-Board.

Proprietär bedeutet für mich so etwas wie exklusiv. Bestes Beispiel war anno dazumal die 3fdx-Glide Schnittstelle. Lief ohne (damals illegalen) Wrapper nur auf 3dfx Hardware.

cg dagegen läuft auf PS 1.1 (oder gar 1.3?) Hardware, also auch ATi und SiS.

[Unregistered]

Originally posted by Quasar
Proprietär bedeutet für mich so etwas wie exklusiv. Bestes Beispiel war anno dazumal die 3fdx-Glide Schnittstelle. Lief ohne (damals illegalen) Wrapper nur auf 3dfx Hardware.

Proprietär bedeutet nicht exklusiv, sondern "eigen", bei IT-Dingen und bei Cg bedeutet es rechtlich geschützt. Dass daraus Exklusivität folgt ist nur optional und bei Cg vorerst nicht der Fall.

[Quasar]

proprietary

1. In marketroid-speak, superior; implies a product imbued with exclusive magic by the unmatched brilliance of the company's own hardware or software designers.

2. In the language of hackers and users, inferior; implies a product not conforming to open-systems standards, and thus one that puts the customer at the mercy of a vendor who can inflate service and upgrade charges after the initial sale has locked the customer in.

Source: The Free On-line Dictionary of Computing, © 1993-2001 Denis Howe

In diesem Sinne magst du recht haben, aber so wie ich es verstanden habe, scheint es jedem freizustehen, cg zu benutzen und Plug-Ins zu schreiben, oder?

[StefanV]

Originally posted by Quasar


In diesem Sinne magst du recht haben, aber so wie ich es verstanden habe, scheint es jedem freizustehen, cg zu benutzen und Plug-Ins zu schreiben, oder?

Schon, aber solange NV den Quellcode nicht 100%ig frei gibt, ist das nur eine theoretische möglichkeit...

[ow]

???

Seit wann brauchst du die Quellen eins Progs, um Plugins dafür zu schreiben?

[Quasar]

Originally posted by Stefan Payne


Schon, aber solange NV den Quellcode nicht 100%ig frei gibt, ist das nur eine theoretische möglichkeit...

Komisch, ich dachte bislang, auch für Windows gäb's sowas wie Treiber und Zusatzprogramme....oder habe ich nur verpasst, daß MS den Quellcode freigegeben hat?

[zeckensack]

Erst die Gründe, dann die Beuhauptung:
1)DirectX
1a)DX8-Shader sind aufgrund ihres begrenzten Funktionsumfangs gut zu überschauen, eine Hochsprache ist und bleibt dafür Overkill
1b)DX9-Shader mit erweitertem Funktionsumfang kommen (später) mit eigener Hochsprache
1c)DX8/9 laufen bei allen Herstellern über das gleiche Programmiermodell (Ausnahme: PS1.4, der sowieso weitgehend irrelevant ist)
2)OpenGL
2a)Für den derzeitigen Funktionsumfang der Gf3/4Ti-Serien gibt's 'nvparse', was auch eine Art Hochsprache für (die derzeit machbaren, kurzen) Shader zur Verfügung stellt
2b)ATi braucht sowas eh nicht, die Shader-Extension ist sehr übersichtlich und einfach zu erlernen (straightforward, wie der Nordeuropäer zu sagen pflegt).
2c)Der Funktionsumfang der GL2-Sprache wird irgendwann nächstes Jahr beide Ansätze überflüssig machen
3)Portabilität DX/OpenGL ist nutzlos

Behauptung: Cg ist eine Lösung für ein nicht-existentes Problem. Daher erscheint es mir nur fair, NVIDIA (all caps!) hier zu unterstellen, daß sie es nur auf eigene Marktinteressen abgesehen haben. Im Austausch für eine nicht vorhandene Gegenleistung sollen sich Entwickler noch stärker als bisher an NVIDIA binden.

[aths]

Originally posted by zeckensack
Erst die Gründe, dann die Beuhauptung:
1)DirectX
1a)DX8-Shader sind aufgrund ihres begrenzten Funktionsumfangs gut zu überschauen, eine Hochsprache ist und bleibt dafür OverkillIch stimme zu. PixelShader 1.1 erlaubt nur eine handvoll Befehle pro Shader, wobei diese Befehle für Insider überschaubar sind. Ehe man sich in Cg eingearbeitet hat, kann man sich auch PS.1.1 direkt beibringen.

Positiv sehe ich allerdings nVidias Aufruf "Unterstützt endlich Shader!" Vielleicht bringt das einige noch unentschlossene Entwickler auf Trab.

[Demirug]

Für die PS 1.1 braucht man wirklich nicht unbedingt eine höhere Sprache bei den VS 1.0/1.1 sieht das IMO aber schon anders aus.

MS und NVidia haben beiden die intention die sprachen kompatibel zu halten. Mehr darf ich dazu aber nicht sagen.

Es ist also keine Zeitverschwendung wenn man jetzt Cg benutzt um VS/PS für eine DX8 engine aus einer Hochsprache zu erzeugen. Dadurch das man jetzt eine Hochsprache zur verfügung hat kann mal auch mal die Designer/Grafiker einen Shader schreiben lassen mit der Assembler sprache von DX8 ist das in den meisten Fällen undenkbar.

Natürlich ist Cg keine reine freundlichkeit von NVidia. Der Grund wird wohl sein das sich die Entwickler fortwährend beschwert haben das die Shader (sowohl in DX und auch in OpenGL) zu umständlich zu programmieren sind. MS hat mit DX9 abhilfe versprochen. NVidia hat sich an die MS Sprache angehängt und auch für OpenGL einen Compiler geschrieben. Damit dürften die Beschwerden weniger werden.

Es wird hier immer wieder gerne OpenGL 2.0 als Allheilmittel angepriessen. Dabei ist der Standard noch nicht einmal verabschiedet. Spiele müssen aber auf lange sicht auch noch nicht OpenGL 2.0 Karten unterstützen und deshalb wird für diese Zeit eben auch eine Lösung gebraucht.

[Richthofen]

zumal du wohl mit OpenGL2.0 Schwierigkeiten haben dürftes das ganze dann zu DX9 zu portieren.
Das ist der Gag an der Sache.

CG rein und flux das Ganze gemacht für DX oder OGL.
Wenn man bedenkt, das man ganz gerne PC Spiele für x-box haben will und umgekehrt sehe ich die Sache mit CG doch ganz optimistisch.
Naja und wenn NV Graks gut drauf laufen ist mir das auch Recht.
ATI und CO können ja gerne Plugins machen und sich mit drann hängen.

Wenn sie es nicht tun mei ihr Problem.

[Exxtreme]

Also so wie ich das sehe, ist Cg mehr oder weniger eine Übergangslösung bis DX9 richtig auf der Bildfläche erscheint. Dann wird Cg wohl überflüssig werden. Und ich glaube nicht, daß ATi irgendwelche PlugIns anbieten wird/muss da der PS1.4 eh' von keinem Hersteller unterstützt werden wird da die Spiele-Hersteller zu marktführerhörig sind.

Gruß
Alex

[Quasar]

Nö, das schöne daran ist ja, daß cg "vorwärtskompatibel" sein soll, wie in den 3DC-News zu lesen ist. Alle Shader lassen sich von DX8 nach DX9 portieren und auch nach oGL...

Klingt imho recht praktisch.

[Unregistered]

Man wird keine Profile, Plug-Ins und Compiler für das proprietäre Cg schreiben können:

http://64.246.22.60/~admin61/forum/viewtopic.php?t=1259&start=50

When I asked Kirk if they would allow othere vendors to create their own compilers the answer was basically "why confuse things even further".

[Quasar]

So wie ich das lese, bezieht sich das auf die Compiler. Und das aus dem Zitat, einer zusammengefassten Aussage abgeleitet.

Außerdem hindert doch niemand ATi, Matrox, 3dlabs und die BitBoys daran, eigene HLSL-Toolkits zu entwickeln.

Nochmal: Niemand wird gezwungen, cg zu verwenden. Warum versucht ihr, ein Entwicklertoolkit dauernd schlecht zu machen?

Daß andere Firmen sich eben nicht um die Bereitstellung solcher Tools und der entsprechenden Hardware kümmern, ist der Grund, warum zumeist primär auf nV-HW entwickelt und getestet wird. Wer das nicht begreift, der sollte sich später auch nicht mehr beschweren, wenn Neuerscheinungen auf nV Hardware besser laufen, als auf den Produkten der Konkurrenz.

[Exxtreme]

Originally posted by Quasar
Wer das nicht begreift, der sollte sich später auch nicht mehr beschweren, wenn Neuerscheinungen auf nV Hardware besser laufen, als auf den Produkten der Konkurrenz.
Err, wenn ich ein Spiel für 45€ kaufe, dann erwarte ich, daß es _sofort_ funktioniert und nicht erst zwei Patches später. Und wenn eine Spieleschmiede zu blöde ist um ein Spiel auf Nicht-NV-HW zum Laufen zu bringen, dann sollen sie einen Hinweis auf der Schachtel drauftun damit man das Game von der Einkaufsliste streichen kann. Nach dem Debakel mit Morrowind werde ich dazu übergehen müssen mir die Games erst dann zu holen, wenn mind. zwei Patches erschienen sind.

Gruß
Alex

[Quasar]

Ach so, ich verstehe. Das möchtest du auch nV anlasten?

BTW, was für ein Debakel mit Morrowind?

[Exxtreme]

Originally posted by Quasar
Ach so, ich verstehe. Das möchtest du auch nV anlasten?
Nicht wirklich, btw. wo versuche es NV anzulasten? Ich will es den Entwicklern der Spiele und den Publishern, die die Entwickler unter Druck setzen, anlasten.
Originally posted by Quasar
BTW, was für ein Debakel mit Morrowind?
Schaue mal ins Spiele-Forum. Miese Performance auch mit HighEnd-Rechnern, oft CTDs, falsche PixelShader-Reflexionen usw. Da es für das Game noch keinen Patch gibt und es verbuggt ohne Ende ist, ist es IMHO ein Debakel.

Gruß
Alex

[Quasar]

Originally posted by Exxtreme

Nicht wirklich, btw. wo versuche es NV anzulasten? Ich will es den Entwicklern der Spiele und den Publishern, die die Entwickler unter Druck setzen, anlasten.[/SIZE]

Naja, ausm Zusammenhang klang es so, als sollte alles mal wieder auf cg geschoben werden....wunder' dich nicht, du weisst sicher, warum.

Ich habe im Übrigen kein Debakel mit Morrowind gefunden, auch wenn es bei mir ein- oder zweimal am Tag einen CTD hinlegt, damit kann ich leben.

Und daß neue Games eben nicht mehr so gut auf uralt-Computern laufen, noch durchgehen 100fps+ bieten, kann ich anhand der grafischen Qualität von MW nur begrüßen. Das PS-Wasser habe ich eh abgeschaltet, weil es mir zu aufgesetzt wirkt.

[nocturne]

Originally posted by Exxtreme

Err, wenn ich ein Spiel für 45€ kaufe, dann erwarte ich, daß es _sofort_ funktioniert und nicht erst zwei Patches später. Und wenn eine Spieleschmiede zu blöde ist um ein Spiel auf Nicht-NV-HW zum Laufen zu bringen, dann sollen sie einen Hinweis auf der Schachtel drauftun damit man das Game von der Einkaufsliste streichen kann.


Um es mal mit Deinen Worten zu sagen:
Wenn ATI zu blöd sind, den Entwicklern bessere Treiber und Entwicklungsmöglichkeiten zukommen zu lassen, dann brauchen sie sich nicht zu wundern, dass die Entwickler primär auf nVidia-Karten entwickeln und dass sich die meisten Spieler dann lieber nVidia-Karten kaufen.

[Exxtreme]

Originally posted by nocturne
dass die Entwickler primär auf nVidia-Karten entwickeln und dass sich die meisten Spieler dann lieber nVidia-Karten kaufen.
Mir ist es egal ob die Entwickler auf nVidia-HW entwickeln oder auch warum es so ist. Wenn ich ein Game kaufe, dann soll es gefälligst funktionieren. Ich habe schliesslich für eine Leistung bezahlt und diese soll eingehalten werden. Wenn die Entwickler diese Leistung nicht einhalten können, dann sollen sie es vorher auf ihre Schachtel schreiben: "Diese Software funktioniert nur mit nV-HW einwandfrei."

Gruß
Alex

[ow]

Exxtreme

Die Entwickler halten aber die Leistung ein. Das ist der Punkt.
Wenn kein anderer Hersteller ausser NV in der Lage ist, saubere Treiber zu proggen ist das nicht das Problem der Entwickler.

[Exxtreme]

Originally posted by ow
Exxtreme

Die Entwickler halten aber die Leistung ein. Das ist der Punkt.
Wenn kein anderer Hersteller ausser NV in der Lage ist, saubere Treiber zu proggen ist das nicht das Problem der Entwickler.
Sicher? Warum erscheinen dann tausende von Patches? Warum laufen Games von id oder Epic meistens ohne Patch auf allen GraKas vernünftig? Warum hatten auch Besitzer einer NV-HW Probleme mit AquaNox? Fragen, Fragen, Fragen...
;)

Gruß
Alex

[zeckensack]

... warum muß Rockstar Games als "Erklärung" zu den Problemen in GTA3 in einem halboffiziellen Statement von sich geben, eine Radeon8500 wäre nunmal langsamer als eine Geforce2MX ...

[ow]

Nur zur Erinnerung:

Ich game nicht, sondern sammle 3D Szene Demos. Und dafuer gibt's keine Patches. Und diese Demos laufen grundsaetzlich auf JEDER 3D HW, die vernuenftige Treiber hat.

[nocturne]

Originally posted by Exxtreme

Mir ist es egal ob die Entwickler auf nVidia-HW entwickeln oder auch warum es so ist. Wenn ich ein Game kaufe, dann soll es gefälligst funktionieren. Ich habe schliesslich für eine Leistung bezahlt und diese soll eingehalten werden. Wenn die Entwickler diese Leistung nicht einhalten können, dann sollen sie es vorher auf ihre Schachtel schreiben: "Diese Software funktioniert nur mit nV-HW einwandfrei."


Um es erneut mit Deinen Worten zu sagen:

Mir ist es egal, warum die ATI-Treiber oder -Entwicklungsmöglichkeiten schlechter sind als bei nVidia. Wenn ich eine Karte kaufe, dann soll sie gefälligst funktionieren. Ich habe schliesslich für eine Leistung bezahlt und diese soll eingehalten werden. Wenn ATI diese Leistung nicht einhalten können, dann sollen sie es vorher auf ihre Schachtel schreiben: "Diese ATI-Karte funktioniert nicht mit allen Spielen einwandfrei."

[Richthofen]

haha der war ja wieder gut!

Ehrlich gesagt ist mir des schnuppe. Ich hab NV Hardware und hab die auch noch in den nächsten 12 Monaten.
Ob nun ATI Hardware gut läuft oder nicht - mei ist mir doch scheiss egal.
Hauptsache die Games rochen auf der Hardware die ich habe - Punkt!

Mir ist alles an Compilern etc.. Recht das meine Hardware gut ausnutzt.
Intels großer + Punkt bestand auch oft in diesem Punkt. AMD hat da aufgeholt aber ATI....
Naja wir kennen die ja.
Großes Tamm Tamm in Sachen Hardware was ja auch in etwa hinkommt aber Softwaremäßig sind die wohl gerade dazu in der Lage nen Moorhuhn zu coden.

[jedi]

Originally posted by nocturne


Um es erneut mit Deinen Worten zu sagen:

Mir ist es egal, warum die ATI-Treiber oder -Entwicklungsmöglichkeiten schlechter sind als bei nVidia. Wenn ich eine Karte kaufe, dann soll sie gefälligst funktionieren. Ich habe schliesslich für eine Leistung bezahlt und diese soll eingehalten werden. Wenn ATI diese Leistung nicht einhalten können, dann sollen sie es vorher auf ihre Schachtel schreiben: "Diese ATI-Karte funktioniert nicht mit allen Spielen einwandfrei."

Zustimmung. Wie heisst es doch so schön:

"Man kauft sich die Hardware für die Software und nicht umgekehrt."

[Unregistered]

Sim Dietrich (nVidia Developer Support) spoke in a public mailing list:

The point of the CG toolkit is certainly not to lock people into anything.
The point of the whole program might be summed up like so :

1) Cg is really useful *now* for vertex shaders ( not so much for pixel,
yet... )

2) Cg is cross-API, compile to dx8, dx9, ogl, etc

3) CgFX is cross-API - use Dx renderstate syntax & vs/ps for ogl

4) CgFX is compatible with Microsoft's FX format

5) Anyone can write profiles & back-ends for it ( ati, xbox, ps2, gameboy,
etc. )

6) The language is general and complete, the profiles are always limited by
the HW. BTW, more profiles are forthcoming ( like fp20 )

7) The language is compatible with Microsoft's HLSL

8) We getting *real* dcc support for vs/ps through Cg & CgFX for the first
time

9) Cg & CgFX are great shader interchange formats

For the immediate future, #8 is the huge win for developers. I understand
some people are skeptical of NVIDIA, but this is being developed and put out
there in good faith. We are trying to solve real developer & tool provider
problems.

The theory is not :

If people use Cg they will be somehow locked in to NVIDIA GPUs.

but :

If people use Cg, CgFX and/or the Cg DCC support, they can spend less time
reinventing the wheel and more time exploiting GPUs in general, and thus
NVIDIA's GPUs as well.

It's the same as many of our tools, such as the .dds photoshop plugin,
nvasm, nvmeshmender, etc, they help all GPUs, and make generating stunning
graphics more practical for everyone.


Pitchfork

[aths]

Originally posted by jedi
"Man kauft sich die Hardware für die Software und nicht umgekehrt." Wo hast du denn diesen Spruch her? Ich kaufe jedenfalls des öfteren Software extra für meine Hardware.

[jedi]

Originally posted by aths
Wo hast du denn diesen Spruch her? Ich kaufe jedenfalls des öfteren Software extra für meine Hardware.

Wenn alle so wie Du denken würden, dann würden sie den ganzen Tag nur 3DMark spielen. ;)

Ich bleibe dabei:

Man kauft sich die Hardware für die Software und nicht umgekehrt.

Der Spruch ist ja inzwischen schon ein geflügeltes Wort. Die meisten Spieler wollen eben einfach optimal zocken und suchen sich dafür die optimale Grafikkarte. Erst definiert man seine Ansprüche und dann erst kauft man sich die passende Hardware. Nicht umgekehrt.

Die wenigsten werden wohl irgendeine Hardware blind kaufen und sich dann erst überlegen, was sie damit überhaupt machen wollen.

[Thowe]

Originally posted by jedi
Die wenigsten werden wohl irgendeine Hardware blind kaufen und sich dann erst überlegen, was sie damit überhaupt machen wollen.

Grob geschätzt 98% +/- 1%, wobei hier mein Schätzung eher in +1 % gehen würde. Ansonsten hätte MM ab morgen genau 0 Kunden :D

99% aller aktuellen Spiele, laufen für ein Grossteil aller Kunden zufriedenstellend. Genau wie 96% aller Kunden mit ihrem Neurechner zufrieden sind. Etwas 93% aller Rechner passen nicht zu den Anforderungen die an diese gestellt werden, wobei hier ein Grossteil überdimensioniert ist, der Rest ist einfach falsch zusammengestellt.


Ich für meinen Teil kaufe mir eine Grafikkarte einzig nach den Featureset und Performance/Preisverhältnis. Woher weiss ich denn was ich morgen spielen will, oder was die Spiele die kommen für Anforderungen stellen. Es sei denn, ich suche mal Stefans Kristallkugel wieder :)



Zum Thema der Treiber, wenn sich die Spiele als auch die Treiber an den Anforderungen halten, dann gibt es de facto auch keinerlei Probleme. Aber irgendwas ist immer, billig ist es allerdings die Schuld irgendjemanden pauschal zuweisen zu wollen. Ich denke sowas zeugt von einer gewissen Engstirnigkeit die sehr "ungesund" fürs Leben ist. Einseitiges denken deformiert den Geist, IMHO.

[Thowe]

Hallo Pitchfork,

lange nicht mehr gelesen :)



Zum Text von Sam Dietrich, mal die einzelnen Punkte aussen vor gelassen, stört mich persönlich, das hier zu einen gesagt wird, ich soll keine Bedenken haben und zum anderen mir sogar noch gesagt wird was ich denken soll. Ich leide zwar nicht unter Paranoia, allerdings denk ich mir dann schon, das es doch wohl besser ist mir meine Gedanken zu machen.

[Unregistered]

4) CgFX is compatible with Microsoft's FX format


8) We getting *real* dcc support for vs/ps through Cg & CgFX for the first
time


(dcc = Digital Content Creation = 3dMax, Maya etc)

Die beiden Punkte stimmen mich wirklich optimistisch. Man muß weiterschauen als nur einfach Cg, sondern CgFX ist der wegweisende Ansatz (genauer gesagt, die DX Effect Files sind es, die gibt es schließlich schon seit 2 Jahren, und jetzt wohl ernsthaft brauchbar werden).
Dadurch daß (more or less):

Cg == HSL
CgFX == DX Effects

bekommt man ein Standardshadersystem, daß

1) Crossplattform/CrossAPI ist!
2) Von Cutting Edge bis hin zu Uralt alles unterstützt
3) Mechanismen für verschiedene Hardware von vornherein in einer Datei berücksichtigt
4) Höchstwahrscheinlich breiten Support aller Hersteller hat (wobei die Frage, ob PS1.3/PS1.4 wirklich von Cg direkt unterstützt wird, noch nicht so das Problem ist, da kann man mit Assembler noch gut die Übersicht behalten; VS1.1/2.0 und PS2.0 sind die wichtigen Gebiete). Das garantiert MS mit DX9.
5) Und von 3dmax bis hin zur Engine funktioniert! Weil hier hapert es mit der Toolpipe bisher.

Pitchfork

[aths]

Originally posted by jedi
Wenn alle so wie Du denken würden, dann würden sie den ganzen Tag nur 3DMark spielen. ;)Das ist schon deshalb Unsinn, weil ich den 3DMark nicht gekauft habe.

Originally posted by jedi
Ich bleibe dabei:
Man kauft sich die Hardware für die Software und nicht umgekehrt.Ich meine, dein "man" ist fehl am Platze. Du verallgemeinerst von dir ausgehend zu sehr. Beispielsweise kaufte ich damals Ultima IX in erster Linie, um den neuen PC auszunutzen.

Originally posted by jedi
Der Spruch ist ja inzwischen schon ein geflügeltes Wort.Mir ist dieser Spruch neu. Dass man HW kauft, um überhaupt SW laufen lassen zu können ist trivial und bedarf keiner Erwähnung. Wenn es darum geht welche HW? richtet sich das nach der SW; aber steht die Frage nach der SW sollte man zunächst auf seine HW gucken. Im Prinzip ist das genauso trivial.

[aths]

Wie kann es sein, dass Thowes Antwort vor Pitchforks Posting erfolgte?

[Thowe]

Originally posted by aths
Wie kann es sein, dass Thowes Antwort vor Pitchforks Posting erfolgte?

Schau etwas weiter oben, darauf bezog es sich.

[zeckensack]

Originally posted by nocturne


Um es erneut mit Deinen Worten zu sagen:

Mir ist es egal, warum die ATI-Treiber oder -Entwicklungsmöglichkeiten schlechter sind als bei nVidia. Wenn ich eine Karte kaufe, dann soll sie gefälligst funktionieren. Ich habe schliesslich für eine Leistung bezahlt und diese soll eingehalten werden. Wenn ATI diese Leistung nicht einhalten können, dann sollen sie es vorher auf ihre Schachtel schreiben: "Diese ATI-Karte funktioniert nicht mit allen Spielen einwandfrei." Unsinn! Karten gibt es wenige, die Produktzyklen sind lang. Applikationen (Spiele, Christbaum-Simulatoren, etc) gibt es viele, jeden Tag neu. Die Forderung nach Kompatibilitätstests Graka/App muß an den 'nutzenden', also die Applikation gestellt werden, nicht an die 'Infrastruktur' Graka/Treiber.

Die Grafikkarte und deren Treiber müssen die API-Spezifikationen erfüllen, mehr nicht. Diese liegen offen. Was Rockstar Games und andere da treiben, das wissen dagegen nur sehr alte, sehr bärtige Männer auf sehr hohen Bergen. Ich kann auch gaaanz schnell ein Programm schreiben, daß auf einer Geforce4Ti nicht läuft. Uuups, das habe ich ja bereits mehrfach getan ...

Zu dem, was du da forderst, möchte ich eine Parallele anbieten:
Wenn mein Satellitenfernsehen nicht läuft, liegt's garantiert an den doofen Satelliten, die sollen gefälligst zu meinem Receiver kompatibel gemacht werden :P

[StefanV]

Originally posted by zeckensack
Zu dem, was du da forderst, möchte ich eine Parallele anbieten:
Wenn mein Satellitenfernsehen nicht läuft, liegt's garantiert an den doofen Satelliten, die sollen gefälligst zu meinem Receiver kompatibel gemacht werden :P

Du wirst mir von Tag zu Tag sympatischer, Zeckensach ;)

Erst Final Fantasy Fan, dann auch noch SAT Fernseh gucker ;)

Aber ich stimme dir absolut zu!!

Die Developer haben dafür soge zu Tragen, daß ihre Produkte auf möglichst breiter HW läuft, wenn das nicht so ist, dann haben sie Mist gebaut.

[Quasar]

Die Software-Developer haben dafür zu sorgen, daß ihre Software fehlerfrei die jeweilige Schnittstelle anspricht. Der Rest ist Sache der Treiber. IMHO.

[AlfredENeumann]

Originally posted by Quasar
Die Software-Developer haben dafür zu sorgen, daß ihre Software fehlerfrei die jeweilige Schnittstelle anspricht. Der Rest ist Sache der Treiber. IMHO.


Ist nur komisch das Scene-Demos i.d.R. auf so ziemlich jeder Grafikkarte Problemlos/Fehlerlos laufen. Nur Games schaffen das nicht.

[Quasar]

Tja, mit steigender Komplexität des Programmes wird auch die QC ein wenig schwieriger, meinste nicht AEN?

Ich kenne nur wenige Games, die bsw. mit 6kB für die Engine auskommen...

[Exxtreme]

@ Quasar
Komplexität ist trotzdem keine Entschuldigung. Daß es nicht unmöglich ist Spiele halbwegs bugfrei zu schreiben beweisen ja Epic und id. Die Spiele der beiden Schmieden laufen auf Anhieb, egal mit welcher GraKa. id macht z.B. öffentliche Beta-Tests. Damit decken die Tausende von möglichen HW-Konfigutrationen incl. Treiber ab. Diese Möglichkeit hat man in einem internen Beta-Test überhaupt nicht. Deswegen frage ich mich warum es nur so wenige Entwickler-Studios machen.

Gruß
Alex

[Quasar]

Hihihi....

Du gehst vom heutigen Stand aus, Exxtreme.

Guck dir mal den desolaten Zustand der ersten D3D und oGL-Renderer für Unreal an. Sicher lags auch daran, daß damals die Treiber noch etwas schwächer waren, aber von fehlerfrei laufen würde ich da nicht sprechen.

Auch Quake3 lief eigentlich nur auf nV (ICD) und 3Dfx (Mini-ICD) zum Erscheinungszeitpunkt richtig rund....trotz öffentlichem Beta-Test.

edit:
Egal, sollte trotzdem ein vernünftiges QC bei den Entwicklern geben. Und wenn das durch Tools etc. einer Firma unterstützt wird, sieht man ja, das es auch was bringt.

[ow]

Originally posted by AlfredENeumann



Ist nur komisch das Scene-Demos i.d.R. auf so ziemlich jeder Grafikkarte Problemlos/Fehlerlos laufen. Nur Games schaffen das nicht.


Also meine Radeon1 und fehlerfrei in Szene Demos wuerde ich mal nicht bestaetigen. Fuer alle anderen Karten schon.

[Leonidas]

Originally posted by zeckensack

Behauptung: Cg ist eine Lösung für ein nicht-existentes Problem. Daher erscheint es mir nur fair, NVIDIA (all caps!) hier zu unterstellen, daß sie es nur auf eigene Marktinteressen abgesehen haben. Im Austausch für eine nicht vorhandene Gegenleistung sollen sich Entwickler noch stärker als bisher an NVIDIA binden.



Dös ist der einzige Grund für Cg: Es geht nicht gleich um die Weltherrschaft, sondern um Nuancen. Man bietet ein Toolkit ein paar Monate früher als MS und hofft so, noch mal zu dem einen oder anderen Entwickler eine bessere Beziehung hinzubekommen. Der Knackpunkt war wohl, daß die Erstellung von Cg nVidia wahrscheinlich so gut wie gar nix gekostet hat. Warum also sollte nVidia das nicht machen, wenn es nix kostet und eventuell was bringt?

[Leonidas]

Originally posted by ow
Exxtreme

Die Entwickler halten aber die Leistung ein. Das ist der Punkt.
Wenn kein anderer Hersteller ausser NV in der Lage ist, saubere Treiber zu proggen ist das nicht das Problem der Entwickler.


Jein. Auf die Verpackung gehört trotzdem ein entsprechender Hinweis. Der Entwickler kann sicher nix für, wenn es ATi net packt. Aber seine Kunden drauf hinweisen muß er trotzdem.

[ow]

@Leo

Ich denke, jedem Spiel liegt ein Readme bei, in dem auch erklaert ist, mit welchen Chips/Treibern es derzeit Probleme gibt.

Auf der Verpackung wirst du sowas nicht finden, ist ja auch nicht im Interesse der Spielhersteller.

[Richthofen]

aber echt.
Wo komm mer denn dann hin???
Da kannst ja gleich jedem ein riesen Poster hinhalten unser Game ist super toll und das Beste aber läuft nur auf der und der Hardware 100% fehlerfrei.
Also da wär man schon selten dämlich.
Ich möchte den hier mal sehen, von denen die auf ebay versteigern oder in Foren oder wo auch immer, der auf Unzulänglichkeiten (nicht beschädigungen gemeint) seiner Hardware hinweist, welche Nachteile sie gegenüber anderen hat etc...

ROFL.

Alter wenn ich was verkaufen will dann ist mir scheiss egal wie ich es verkaufe. Hauptsache ich verkaufe es zu dem bestmöglichen Preis.
Dumme gibts immer und die wollen halt beschissen werden.
So läuft das Gott sei Dank nunmal.
Sonst könnten die meissten großen Firmen einpacken, weil keiner mehr ihr überteuertes Zeug kaufen würde und wahrscheinlich billige Ost oder Asienprodukt vorziehen würde, oder seine gekauften Produkte länger behält und nicht mehr ständig neues kauft.

Mängel und Unzulänglichkeiten werden grundsätzlich im Kleingedruckten angegeben oder über versteckte Hinweise.
Schließt mal nen Versicherungsvertrag ab oder schaut euch Werbeangebote über neue Tagesgeldkonten an :)
Wie oft steht ganz winzig klein irgendwo "Zinsatz variabel" *hust*

50% der Leute haben das sicher überlesen :=)

[aths]

Originally posted by Richthofen
Dumme gibts immer und die wollen halt beschissen werden.
So läuft das Gott sei Dank nunmal.Das ist völlig ot, Richthofen.