Nvidia ständiges Mitglied im OpenGL ARB

[Richthofen]

hab ich ausm NVNews Forum.

SANTA CLARA, CA—OCTOBER 8, 2003—NVIDIA Corporation (Nasdaq: NVDA), the worldwide leader in visual processing solutions, is pleased to announce that it has been elected by its peers in the technology industry as a permanent voting member of the OpenGL Architecture Review Board (ARB). Formed in 1992, the OpenGL® ARB is an independent consortium that governs the OpenGL specification. Composed of many of the industry's leading graphics vendors, the ARB defines conformance tests and approves new OpenGL features and extensions. The ARB has nine permanent voting members, including industry luminaries such as IBM, HP, Apple, and its founder, SGI.
The ARB’s unanimous vote comes as a result of NVIDIA’s continuous dedication and commitment to the evolution of OpenGL. For many years, NVIDIA has been an active participant in the OpenGL ARB, and has contributed resources, technologies, and support to many working groups.
“We are very proud to have been elected a permanent voting member of the OpenGL ARB,” said Kurt Akeley, co-inventor of OpenGL and a 3D graphics architect at NVIDIA. “NVIDIA is committed to the OpenGL specification and we look forward to helping the ARB respond quickly and flexibly to evolutionary changes in computer graphics technology.”
OpenGL has become the industry's most widely used and supported 2D and 3D graphics application programming interface (API), bringing thousands of applications to a wide variety of computer platforms. OpenGL fosters innovation and speeds application development by incorporating a broad set of rendering, texture mapping, special effects, and other powerful visualization functions.
“Promotion from auxiliary to permanent member status recognizes NVIDIA’s major contributions to OpenGL 1.3, 1.4, and 1.5 as well as its efforts at leading or participating in the development of many ARB-approved OpenGL extensions,” said Jon Leech, OpenGL ARB secretary at Silicon Graphics, Inc. “Silicon Graphics welcomes NVIDIA as a permanent member in the OpenGL Architectural Review Board.”

OpenGL enables visual computing applications, from markets such as computer-aided design and digital content creation, to exploit modern graphics hardware. This capability allows developers catering to sectors including auto manufacturing, medical imaging, and film production to create compelling graphics. NVIDIA has been driving several of the key new features of the upcoming OpenGL® 1.5 release such as vertex buffer objects and occlusion queries. NVIDIA was also one of the primary contributors to the new OpenGL® Shading Language extension. In addition, NVIDIA contributed technology and expertise toward the development of multi-texturing, vertex and fragment programming, cube mapping, point sprites, and non-power-of-two textures to OpenGL.

[Exxtreme]

Persönliche Angriffe und Sticheleien werden hier im Forum nicht geduldet!!

[Achill]

http://www.opengl.org/developers/about/arb.html

- ich verstehe den sinn dieses threads nicht -

[Richthofen]

Original geschrieben von Exxtreme
Persönliche Angriffe und Sticheleien werden hier im Forum nicht geduldet!!

?????????????????

[Winter[Raven]]

Original geschrieben von Richthofen
?????????????????

Da meinte ein Gast er müsse dich etwas dumm anmachen !

Exxtreme hat den Posting halt dann gelöscht ... !

Also ich komme jetzt auch ned weiter was Nvidia jetzt davon hat !

[Exxtreme]

Original geschrieben von Richthofen
?????????????????
Ich habe da was getrasht. :)

[The_Invisible]

Original geschrieben von Winter[Raven]
Da meinte ein Gast er müsse dich etwas dumm anmachen !

Exxtreme hat den Posting halt dann gelöscht ... !

Also ich komme jetzt auch ned weiter was Nvidia jetzt davon hat !

+++++++

was hat jetzt nvidia davon bzw können die davon profitieren?

mfg

[DrumDub]

Original geschrieben von The_Invisible
+++++++

was hat jetzt nvidia davon bzw können die davon profitieren?

mfg

keine ahnung. eigene extensions haben se ja schon vorher gehabt, genau wie ati.

sind nicht grad viele members, aber matrox ist auch dabei:

http://www.opengl.org/developers/about/arb.html

[Richthofen]

Original geschrieben von Exxtreme
Ich habe da was getrasht. :)

Achso wusst ich nicht bzw. konnte ich nicht sehen.


was hat jetzt nvidia davon bzw können die davon profitieren?


vorher waren sie kein ständiges Mitglied jetzt sind sie es schon. Ich weiss nicht genau wie die Abstimungsverfahren laufen aber als nicht ständiges Mitglied hast du entweder nur temporär Stimmrechte wenns ans Eingemachte geht oder gar keine.
Als ständiges Mitglied hast wie im UN Sicherheitsrat auch immer 1 Stimme. Du kannst also für bestimmte Dinge stimmen und auch gegen bestimmte Dinge.
Insofern ist das in jedem Fall ein Gewinn für Nvidia, da ATI beispielsweise vor knapp 1 Jahr aufgenommen wurde als ständiges Mitglied.
Mich würde nur mal interessieren, wie die Mehrheitsverhältnisse beim ARB sein müssen, denn ich kann mir kaum vorstellen dass ATI für eine Aufnahme von Nvidia als ständiges Mitglied gestimmt hat.
Jetzt dürften beide wieder die selben Rechte haben.

[egdusp]

NV wurde nicht reingewählt im letztem Jahr, da sie gerade Cg so pushen wollten und noch marktbeherrschend waren, der R300 war ja gerade erst kurz draußen.

Jetzt wurden sie reingewählt, weil von NV keine unmittelbare "Gefahr" ausgeht. ATI ist momentan domminant, aber hauptsächlich in DX.

Ich folgere: NV wird auch von den OpenGL Board Mitlgiedern "belächelt".

mfg
egdusp

[Gast]

Original geschrieben von Richthofen
Mich würde nur mal interessieren, wie die Mehrheitsverhältnisse beim ARB sein müssen, denn ich kann mir kaum vorstellen dass ATI für eine Aufnahme von Nvidia als ständiges Mitglied gestimmt hat.
Jetzt dürften beide wieder die selben Rechte haben.

http://www.opengl.org/developers/about/arb/legal/arb_bylaws.pdf

[Mordred]

Original geschrieben von DrumDub
keine ahnung. eigene extensions haben se ja schon vorher gehabt, genau wie ati.

sind nicht grad viele members, aber matrox ist auch dabei:

http://www.opengl.org/developers/about/arb.html

Naja ist doch alles wichtige dabei ^^.

[Xmas]

Ändert im Prinzip nichts, aber doch längst überfällig.

[Desti]

Ich hoffe OpenGL wird nun von nVidia den Spiele Entwicklern wieder mehr ans Herz gelegt, dieser DX9 Hype ist ja total ausgeleiert und langweilig.

[Mordred]

Original geschrieben von Desti
Ich hoffe OpenGL wird nun von nVidia den Spiele Entwicklern wieder mehr ans Herz gelegt, dieser DX9 Hype ist ja total ausgeleiert und langweilig.

Joar aber diesollen vorallem beim Entwickeln von Open Source mal etwas dampf machen ^^

Früher war DirectX nen witz gegenüber OpenGL heute hinkt OpenGL schon hinterher. Das muss doch echt net sein.

[The_Invisible]

Original geschrieben von [KoC]Mordred
Joar aber diesollen vorallem beim Entwickeln von Open Source mal etwas dampf machen ^^

Früher war DirectX nen witz gegenüber OpenGL heute hinkt OpenGL schon hinterher. Das muss doch echt net sein.

tja, man braucht nur vergelichen weiviele spiele DX sind und wieviele OpenGL

mfg

[Mordred]

Original geschrieben von The_Invisible
tja, man braucht nur vergelichen weiviele spiele DX sind und wieviele OpenGL

mfg

ja es waren schon mehr DirectX als Open GL nioch haus hoch überlegen war... Leider.

Wird sich hoffetlich mal wieder ändern. Frag mich nur woran das leigt...

Krigen wohl kohle von MS damit sie DirectX nehmen oder sowas ^^

[ShadowXX]

Original geschrieben von [KoC]Mordred
ja es waren schon mehr DirectX als Open GL nioch haus hoch überlegen war... Leider.

Wird sich hoffetlich mal wieder ändern. Frag mich nur woran das leigt...

Krigen wohl kohle von MS damit sie DirectX nehmen oder sowas ^^

Der Stil in dem OpenGL programmiert werden muss, gefällt manchen Leuten nicht.....zum Beispiel mir.
Dazu kommt, dass der DX-Stil mit dem der restlichen Proggen von Windows sehr konform ist...auch deshalb wird DX häufig bevorzugt....

J.S.Shadow

[StefanV]

Original geschrieben von [KoC]Mordred
ja es waren schon mehr DirectX als Open GL nioch haus hoch überlegen war... Leider.

Wird sich hoffetlich mal wieder ändern. Frag mich nur woran das leigt...

Krigen wohl kohle von MS damit sie DirectX nehmen oder sowas ^^

ok, kurzform:

die OGL Entwicklung ist aufwendiger und teurer als die DX Entwicklung, da du bei OGL für jeden Hersteller und u.U. für jede Karte einen eigenen Renderpfad schreiben 'darfst'...

Bei DX ist das eigentlich nicht nötig, da brauchst nur einmal DX7, ein(-zwei) mal DX8 und halt DX9...

[Razor]

Original geschrieben von Stefan Payne
Bei DX ist das eigentlich nicht nötig, da brauchst nur einmal DX7, ein(-zwei) mal DX8 und halt DX9...
Ähm...
"und halt DX9 ein, zwei, dreimal..."
:D

Razor

[Demirug]

Viele Entwickler füheren als Grund für DX auch auf das die D3D Treiber meist besser als die OpenGL Treiber des gleichen Herstellers sind.

Stefan Payne hat es ja auch schon gesagt das der Aufwand für die Entwickler geringer ist. ES ist sogar noch etwas extremer als Stefan geschríeben hat. D3D kennt nur zwei Modele Fixed Function und Programierbare Shader. Unterstützt man beide Modele so das man die genaue Details in Konfigurationsfiles ablegt muss man für unterschiedliche Chips/Karten nur noch dieses Dateien anpassen und nichts mehr am Code ändern. Für ganz faule hat MS sogar schon Funktionen für das arbeiten mit solchen Files beigelegt. Dort kann man dann für FF und Shader sogar die gleichen Funktionen benutzen.

Was man auch nicht vergessen darf ist das MS natürlich Werbung für DX macht indem MS-Mitarbeiter auf Entwicklerkonferenzen Vorträge halten.

[StefanV]

Original geschrieben von Razor
Ähm...
"und halt DX9 ein, zwei, dreimal..."
:D

Razor

Toll, das ist ja auch sooo aufwendig mal den Compiler zu starten und ein anderes Compiler Profil zu wählen, meinst nicht??

Arbeitsaufwand dürfte sich auf 1h begrenzen, wenn man die Shader schonmal durch hat.

Bei OGL hingegen 'darf' man alle Shader nochmal schreiben, toll, nicht wahr??

[Mordred]

Wie ihr sicher gemerkt hab bin ich etzt net grade das was man nen Shaderprofi nennt, aber mir tut sich da eine Frage auf:

Atm sind die ganzen LowEnd Karten doch nur abgespeckte Versionen der dicken Chips (ich meine jetzt natürlich nur die neuste generation)

Also hätte man im Endeffekt zur Zeit doch nur den Aufwand die Shader 2x zu schreiben oder sehe ich da jetzt was falsch?

Weil Kyros usw. gut und schön aber die würden die Spiele sowieso nicht ans laufen kriegen...

Gut NQAchteil wäre maybee man müsste Patches schreiben wenn auf einmal der Volari einschlägt aber ansonnsten wärs doch nicht son riesen Aufwand oder she ich da jetzt was falsch?

[zeckensack]

Original geschrieben von Stefan Payne
Bei OGL hingegen 'darf' man alle Shader nochmal schreiben, toll, nicht wahr?? Codepfade Schreiben ist wirklich nur halb so schlimm wie es immer dargestellt wird.

Bei meinem allseits beliebten Abfallprojekt zB hat mich der ARB_fragment_program-Pfad ca acht Stunden gekostet, von Null über Debuggen/Testen bis hin zur Optimierung und letztlich 'Marktreife' alles inklusive. Und ich sitze hier ganz alleine.

Dieses Backend (wie man es treffender nennen sollte, IMO) erzeugt dynamisch Shadercode, und es gibt ca 5000~10000 relevante Permutationen, theoretisch eher 50000~100000.

Andere Pfade dauern ca genauso lange, wenn man nicht gerade unerfahren an ein völlig neues Interface herangeht. Ist IMO wirklich albern, da so einen riesigen Aufriß zu machen.

Algorithmische/logische Optimierungen dauern viel länger, und die braucht man sowieso, ob jetzt für einen Pfad, oder für fünf verschiedene. In letzterem Fall braucht man die Arbeit auch nur einmal zu machen (halbwegs vernünftiges Design vorausgesetzt).

[Razor]

Original geschrieben von Stefan Payne
Bei OGL hingegen 'darf' man alle Shader nochmal schreiben, toll, nicht wahr??
Nicht, wenn man Cg benutzt...
:D

Razor

[Aquaschaf]

Original geschrieben von Razor
Nicht, wenn man Cg benutzt...
:D



CG ist doch tot?

[StefanV]

Original geschrieben von Aquaschaf
CG ist doch tot?

mausetot

[del_4901]

Original geschrieben von Stefan Payne
ok, kurzform:

die OGL Entwicklung ist aufwendiger und teurer als die DX Entwicklung, da du bei OGL für jeden Hersteller und u.U. für jede Karte einen eigenen Renderpfad schreiben 'darfst'...

Bei DX ist das eigentlich nicht nötig, da brauchst nur einmal DX7, ein(-zwei) mal DX8 und halt DX9...

na so ein Quatsch, OpenGL ist eine Schnittstelle, wie auch DX, wo ein Renderpfad aussreicht. Man programmiert nur gern mehrere Pfade, weil sich so die Grakas besser auslasten lassen (Bei Dx, wie auch bei OGL immer Pro Generation, und nicht pro Hersteller). Der Carmack schreibt nur für jede Grake nen eigenen Pfad weil er geil drauf is, und aus jeder Hardware 110% Leistung quetschen will.

Nur wenn man Herstellerspezifische Erweiterungen von OGL benutzen will, möchte man schon deren im Treiber verankerten Codepath nehmen. Das wird sich mit OGl2.0 aber auch Grundlegend ändern.

[Demirug]

Original geschrieben von AlphaTier
na so ein Quatsch, OpenGL ist eine Schnittstelle, wie auch DX, wo ein Renderpfad aussreicht. Man programmiert nur gern mehrere Pfade, weil sich so die Grakas besser auslasten lassen (Bei Dx, wie auch bei OGL immer Pro Generation, und nicht pro Hersteller). Der Carmack schreibt nur für jede Grake nen eigenen Pfad weil er geil drauf is, und aus jeder Hardware 110% Leistung quetschen will.

Nur wenn man Herstellerspezifische Erweiterungen von OGL benutzen will, möchte man schon deren im Treiber verankerten Codepath nehmen. Das wird sich mit OGl2.0 aber auch Grundlegend ändern.

Dir ist aber schon bewusst das es bei OpenGL in der Regel immer relative lange dauert bis sich die Hersteller auf eine gemeinsame Extension für neue Features einigen?

[Razor]

Original geschrieben von Aquaschaf
CG ist doch tot?
Nö, nur für D3D.

Wer allerdings plattformübergreifende Proggi's schreiben will, wird an Cg (und für D3D den M$-SDK-Compiler ;-) nicht vorbei kommen...

Razor

[StefanV]

Original geschrieben von Razor
Nö, nur für D3D.

Wer allerdings plattformübergreifende Proggi's schreiben will, wird an Cg (und für D3D den M$-SDK-Compiler ;-) nicht vorbei kommen...

Razor

DAS denke ich eher weniger...

[Exxtreme]

Original geschrieben von Razor
Nö, nur für D3D.

Wer allerdings plattformübergreifende Proggi's schreiben will, wird an Cg (und für D3D den M$-SDK-Compiler ;-) nicht vorbei kommen...

Razor
Wieso muss man den CG-Compiler nutzen um plattformunabhängig zu programmieren? OpenGL hat seit Neuestem auch eine HLSL. CG braucht's dazu nicht wirklich.

Oder meinst du plattformunabhängig UND DX-HLSL-kompatibel? :???:

[Quasar]

Nö, klar, du nimmst einfach einmal GL-Slang und dann den DX9-Compiler...

Und wenn die Syntax mal wo nicht passt, fummelst du nochc ein paar Stunden/Tage an deinem Codegerüst.

[Demirug]

Original geschrieben von Exxtreme
Wieso muss man den CG-Compiler nutzen um plattformunabhängig zu programmieren? OpenGL hat seit Neuestem auch eine HLSL. CG braucht's dazu nicht wirklich.

Oder meinst du plattformunabhängig UND DX-HLSL-kompatibel? :???:

Cg hat unter OpenGL immerhin noch eine grössere Hardwareabdeckung als glslang.

[zeckensack]

Original geschrieben von Demirug
Cg hat unter OpenGL immerhin noch eine grössere Hardwareabdeckung als glslang. Richtig.

Zusatz:
Das mit den Hochsprachen ist IMO ganz derbe schiefgelaufen (weil runtime-Kompilation - der Grund für Hochsprachen - nicht sauber geplant wurde).
Unter GL auf <=R200/NV2x braucht man keine Hochsprache, um die Hardware auszureizen. Maximal 16 Ops pro Shader lassen sich noch von Hand bändigen.
Eine Hochsprache wäre eine Erleichterung, dafür braucht's aber auch einen vernünftigen Ansatz. Und das ist Cg nun wirklich nicht.
Der Compiler hat gefälligst autark zu sein (am besten Treiber-intern), und soll zur Laufzeit für die gerade vorhandene Hardware das Optimum liefern, und nicht für irgendein Profil, das man irgendwie vorher ausgesucht hat. Das kann weder Cg, noch der DX9-Compiler, denn dafür wurden sie garnicht erst designt. Darauf verzichte ich gern.

[Demirug]

Da kommt wie üblich meine Standardfrage.

Wie gewährleistet man in einem offenen System (glslang) das ein Shader auf allen Chips einer Generation lauffähig ist?

[zeckensack]

1)Sich informieren (http://www.delphi3d.net/hardware/index.php), welche Karte was kann
2)'kleinere' Versionen der kritischen Shader schreiben. Dabei orientiert man sich sinnvollerweise an den Ressourcen-Limits der gängigen Hardware, die man in Punkt 1 gesichtet hat.
(zB "<=1 Indirektion, <=8 Operationen" wäre angemessen als Fallback für NV2x und R200; das lässt sich auch in der Hochsprache noch nachzählen)
Ganz penibel: 10% Sicherheitsabstand beim instruction count einhalten.
3)Wenn ein Shader nicht kompiliert werden kann, den nächstkleineren nehmen, bis man am minimalen Level angekommen ist. Wenn auch dort die Kompilation scheitert => Fehler; "Hardware nicht ausreichend für dieses Spiel(TM)".

Das DX9-Modell kann 'Treiberversagen' btw auch nicht ausschließen. Sincos ahoi. Oder hier (http://www.ati.com/developer/Dark_Secrets_of_shader_Dev-Mojo.pdf).

[Demirug]

Original geschrieben von zeckensack
1)Sich informieren (http://www.delphi3d.net/hardware/index.php), welche Karte was kann

Und wo finde ich dort DeltaChrome oder die neuen XGI Chips?

2)'kleinere' Versionen der kritischen Shader schreiben. Dabei orientiert man sich sinnvollerweise an den Ressourcen-Limits der gängigen Hardware, die man in Punkt 1 gesichtet hat.
(zB "<=1 Indirektion, <=8 Operationen" wäre angemessen als Fallback für NV2x und R200; das lässt sich auch in der Hochsprache noch nachzählen)
Ganz penibel: 10% Sicherheitsabstand beim instruction count einhalten.

Shader schreiben = Zeit = Geld. Also rein auf Verdacht schreibt man doch keine Shader. Wer soll den sowas bezahlen?

Wie schliesse ich vom Hochprachencode sicher auf die Anzahl der Instruktionen? Die Schnittstelle sagt mir ja nur ob der Shader in der Hardware läuft oder nicht. Keine Angaben wie viel Luft noch wäre. Aber selbst wenn es eine solche Angabe gäbe nutzt das null weil man es ja nicht übertragen kann.

3)Wenn ein Shader nicht kompiliert werden kann, den nächstkleineren nehmen, bis man am minimalen Level angekommen ist. Wenn auch dort die Kompilation scheitert => Fehler; "Hardware nicht ausreichend für dieses Spiel(TM)".

Ja, klar mit dem Level heruntergehen ist immer eine Lösung aber wirklich eine gute. Wie gesagt Shaderschreiben auf Verdacht ist nicht drin.

Das DX9-Modell kann 'Treiberversagen' btw auch nicht ausschließen. Sincos ahoi. Oder hier (http://www.ati.com/developer/Dark_Secrets_of_shader_Dev-Mojo.pdf).

Bei DX kann ich zumindestens dem IHV in den Arsch treten wenn ein Shader nicht korrekt läuft. Aber bei glslang bin ich gekniffen. Es gibt ja keinen Zwang das ein Shader laufen muss. Ich meine dabei in der Hardware und nicht eine Softwareemu.

Stell dir mal vor das es kein DX gäbe was ein bestimmtes Featureset fordert. Jeder Hersteller baut seine Hardware wie es im beliebt und ob ein Shader sich von Hardware A auf Hardware B übertragen lässt ist ein reines Glücksspiel.

Eine Lösung die mir gefallen könnte wäre die folgende.


Schadercode (Hochsprache)
|
Treiber (Compiler)
|
Erfolg -> JA -> Zurück (OK)
|
| (Nein)
|
Runtime (Compiler)
|
Erfolg -> Nein -> Zurück (nicht OK)
|
| (JA)
|
Schadercode (Assembler)
|
Treiber
|
Erfolg -> JA -> Zurück (OK)
|
| (Nein)
|
Zurück (nicht OK)


Die Assembler schnittstelle ist dabei genau definiert un verplichtent. Wenn man also einen Shader mit dem Runtime Compiler compilieren kann muss er mit jedem Chip laufen welche den Techlevel unterstützt.

[zeckensack]

Original geschrieben von Demirug
Und wo finde ich dort DeltaChrome oder die neuen XGI Chips?Die Information wird schon noch auftauchen, wenn die Hardware auf dem Markt aufschlägt. Wenn S3/VIA und XGI ein Interesse daran haben, daß ihre Hardware auch genutzt wird, dann steht es ihnen völlig frei, bereits jetzt Reports mit internen Beta-Treibern zu erzeugen.
Das fällt IMO unter Dev-Support.
Shader schreiben = Zeit = Geld. Also rein auf Verdacht schreibt man doch keine Shader. Wer soll den sowas bezahlen?Exakt die gleichen Leute, die es sich leisten können, DX7 Stage-Setups, PS1.x, PS2.0 und womöglich noch PS2.0a zu unterstützen.
Wie schliesse ich vom Hochprachencode sicher auf die Anzahl der Instruktionen? Die Schnittstelle sagt mir ja nur ob der Shader in der Hardware läuft oder nicht. Keine Angaben wie viel Luft noch wäre.Aussagekräftige Fehlermeldungen. Es ist wohl nicht zu viel verlangt, daß der Treiber im Problemfall zurückmeldet, was denn nun klemmt (icount, Indirektionen, temps, etc).
Aber selbst wenn es eine solche Angabe gäbe nutzt das null weil man es ja nicht übertragen kann.Wenn ich einen Shader schreibe, bei dem ich weiß daß er mit 2 Indirektionen auskommt, und eben dieser Shader dann von einem Treiber mit "zuviele Indirektionen" abgelehnt wird obwohl angeblich 2 Indirektionen unterstützt werden ... dann trete ich eben dem Dev-Support in den Hintern.
Ja, klar mit dem Level heruntergehen ist immer eine Lösung aber wirklich eine gute. Wie gesagt Shaderschreiben auf Verdacht ist nicht drin.Hängt - wie bei DXG auch - alles nur davon ab, wieviele Techlevels man unterstützen will. Der alte Kompromiß Hardwarenutzung <> Budget.

Wenn der Chip A für den Shader xy nicht die nötigen Ressourcen hat, dann muß er eben eine Stufe runter.
Oder läuft auf Xabre I mittlerweile auch PS1.4? AFAIK nicht.

Bei DX kann ich zumindestens dem IHV in den Arsch treten wenn ein Shader nicht korrekt läuft. Aber bei glslang bin ich gekniffen. Es gibt ja keinen Zwang das ein Shader laufen muss. Ich meine dabei in der Hardware und nicht eine Softwareemu."Das mit den Hochsprachen ist IMO ganz derbe schiefgelaufen" <- bezog sich nicht exklusiv auf HLSL. GLslang ist auch nicht ganz zu Ende gedacht.

Gerade der erlaubte/erwünschte Software-Fallback ist eine große Schwäche.
Stell dir mal vor das es kein DX gäbe was ein bestimmtes Featureset fordert. Jeder Hersteller baut seine Hardware wie es im beliebt <...>DX, chronologische Abfolge:
1a)'großer' IHV A plant seinen nächsten Chip
1b)'großer' IHV B plant seinen nächsten Chip
2)MS schaut sich beides an und kratzt sich am Kopf. Rücksprache erfolgt.
3)MS hat fertig gedacht, und veröffentlicht eine Spezifikation, die ab sofort alle sechs Monate revidiert und ergänzt wird.
4)'kleiner' IHV C steigt erst später in das Spiel ein, schaut sich an was Sache ist, und orientiert sich daran. Ziel: möglichst nicht den vorhandenen kleinsten gemeinsamen Nenner unterbieten.

DX9 ist doch nicht vom Himmel gefallen. Die Einigung auf ein gewisses Basis-Featureset erfordert keine 'fachfremden Experten', das können die IHVs auch alleine - die kennen sich schließlich damit aus. Und sie treffen sich sowieso regelmäßig.

<...> und ob ein Shader sich von Hardware A auf Hardware B übertragen lässt ist ein reines Glücksspiel.Shader, die das PS2.0a-Profil sowohl nutzen, wie auch erfordern, kann man auch nicht auf beliebige Hardware übertragen.
PS2.0a auf R300 ist ein Glücksspiel. Und PS1.3 auf R200 wohl auch (du hattest da mal was geschrieben von wegen nicht-nativen Addressoperationen).

Eine Lösung die mir gefallen könnte wäre die folgende.


Schadercode (Hochsprache)
|
Treiber (Compiler)
|
Erfolg -> JA -> Zurück (OK)
|
| (Nein)
|
Runtime (Compiler)
|
Erfolg -> Nein -> Zurück (nicht OK)
|
| (JA)
|
Schadercode (Assembler)
|
Treiber
|
Erfolg -> JA -> Zurück (OK)
|
| (Nein)
|
Zurück (nicht OK)


Die Assembler schnittstelle ist dabei genau definiert un verplichtent. Wenn man also einen Shader mit dem Runtime Compiler compilieren kann muss er mit jedem Chip laufen welche den Techlevel unterstützt. Gegenvorschlag:
Der Treiber bietet eine Schnittstelle zur Abfrage eines maximalen 'unoptimierten' icounts, und anderer quantisierbarer Ressourcen.
Das Compiler-Frontend (Parser) ist eine Koproduktion, die erzeugte Instruktionsmenge ist immer gleich (und abfragbar). Der Vergleich mit dem maximalen 'unoptimierten' icount ergibt die Garantie der Lauffähigkeit.
Der Optimierer sitzt dahinter, und gibt sein bestes.

[Demirug]

Original geschrieben von zeckensack
Exakt die gleichen Leute, die es sich leisten können, DX7 Stage-Setups, PS1.x, PS2.0 und womöglich noch PS2.0a zu unterstützen.

Das sind 3 bzw 4 Varianten. Damit kann man aber sicher sein das man alles abgedeckt hat. Bei glslang fehlt mir diese Sicherheit.

Aussagekräftige Fehlermeldungen. Es ist wohl nicht zu viel verlangt, daß der Treiber im Problemfall zurückmeldet, was denn nun klemmt (icount, Indirektionen, temps, etc).

Ja, zur Laufzeit ist eine solche Meldung aber zu spät. Gerade wenn sie von einer Hardware kommt welche zur Entwicklungszeit noch nicht zur Verfügung stand.

Wenn ich einen Shader schreibe, bei dem ich weiß daß er mit 2 Indirektionen auskommt, und eben dieser Shader dann von einem Treiber mit "zuviele Indirektionen" abgelehnt wird obwohl angeblich 2 Indirektionen unterstützt werden ... dann trete ich eben dem Dev-Support in den Hintern.

Ja, in diesem fall kannst du was machen aber wirklich Druck ausüben kannst du nicht.

Hängt - wie bei DXG auch - alles nur davon ab, wieviele Techlevels man unterstützen will. Der alte Kompromiß Hardwarenutzung <> Budget.

Klar nur bei D3D ist die Anzahl der Techlevels definiert bei glslang bildet im schlimmsten Fall jeder Chip seinen eigenen Techlevel.

"Das mit den Hochsprachen ist IMO ganz derbe schiefgelaufen" <- bezog sich nicht exklusiv auf HLSL. GLslang ist auch nicht ganz zu Ende gedacht.

Gerade der erlaubte/erwünschte Software-Fallback ist eine große Schwäche.

Mit dem Softwarefallback habe ich das kleinste Problem da er ja gemeldet wird. Es wäre aber unter umständen besser gewesen wenn man gleich von Anfang an festlegen kann ob man überhaupt Softwarefallbacks wünscht.

DX, chronologische Abfolge:
1a)'großer' IHV A plant seinen nächsten Chip
1b)'großer' IHV B plant seinen nächsten Chip
2)MS schaut sich beides an und kratzt sich am Kopf. Rücksprache erfolgt.
3)MS hat fertig gedacht, und veröffentlicht eine Spezifikation, die ab sofort alle sechs Monate revidiert und ergänzt wird.
4)'kleiner' IHV C steigt erst später in das Spiel ein, schaut sich an was Sache ist, und orientiert sich daran. Ziel: möglichst nicht den vorhandenen kleinsten gemeinsamen Nenner unterbieten.

DX9 ist doch nicht vom Himmel gefallen. Die Einigung auf ein gewisses Basis-Featureset erfordert keine 'fachfremden Experten', das können die IHVs auch alleine - die kennen sich schließlich damit aus. Und sie treffen sich sowieso regelmäßig.

Ja, natürlich. Aber wir kennen doch beide die Gemeinheiten des Devsupports. Eine offene Schnittstelle wie glslang gibt da viel Spielraum.

Shader, die das PS2.0a-Profil sowohl nutzen, wie auch erfordern, kann man auch nicht auf beliebige Hardware übertragen.

Natürlich. Aber jeder 2.0 Shader lässt sich als 2.A Compilieren und jede 3.0 Hardware kann 2.A benutzten.

PS2.0a auf R300 ist ein Glücksspiel. Und PS1.3 auf R200 wohl auch (du hattest da mal was geschrieben von wegen nicht-nativen Addressoperationen).

2.A sollte man auch nicht auf einem R300 laufen lassen.

Es sind schon 1.1 Shader. Da gibt es zwei Anweisungen die eine Divison brauchen. Man ist sich allerdings bis heute nicht ganz sicher ob der R200 wirklich eine Divison nutzt oder für die gesamte Formel eine Näherung benutzt die meist nicht auffält.

Gegenvorschlag:
Der Treiber bietet eine Schnittstelle zur Abfrage eines maximalen 'unoptimierten' icounts, und anderer quantisierbarer Ressourcen.
Das Compiler-Frontend (Parser) ist eine Koproduktion, die erzeugte Instruktionsmenge ist immer gleich (und abfragbar). Der Vergleich mit dem maximalen 'unoptimierten' icount ergibt die Garantie der Lauffähigkeit.
Der Optimierer sitzt dahinter, und gibt sein bestes.

Wenn man jetzt noch bestimmte Mindestemengen für die Resourcen festlegt hört sich das auch gut an. Allerdings sieht der Treiber so nie den ganzen Hochsprachencode und kann möglicherweise nicht immer die richtigen schlüsse ziehen.