Treiberentwickler gesteht alte "Cheating" Sünde

[Demirug]

Tom Forsyth war zu den Zeiten von 3dWinbench Treiberentwickler bei 3DLabs.

In Zusammenhang einer Disskussion über den Sinn von Standard Functions Benchmarks (z.b. einen Pixelshaderbenchmark) machte er folgende Aussage:

As a driver writer at exactly that time (3DWB98 and 99) I know precisely how trivial it was to detect those benchmarks. The most we ever did was to rearrange textures in memory to get better access patterns (which is borderline, but IMHO just about acceptable :-), but the same detection methods would have let us do anything we liked, including all the current list of accusations - ignoring drawing calls, adding clip planes, turning off features for some tests but not all, etc.

Most of the cheats seen around that time were bodging in approximations to stuff that cards couldn't actually do. For example, if you couldn't do AA, you dropped a load of points because that test wouldn't run at all. So IHVs added all sorts of crazy AA approximations - many no better than rendering the scene and blurring some bits of it. Naturaly these methods didn't have a hope of working in other games.

At least these days they're slightly more subtle (but only slightly!).

Sorry für die etwas reisserische überschrift aber nach der Definition von Futuremark (mit der ich nicht einverstanden bin) ist das was Tom damals bei 3DLabs gemacht hat ein Cheat.

[zeckensack]

Original geschrieben von Demirug
Tom Forsyth war zu den Zeiten von 3dWinbench Treiberentwickler bei 3DLabs.

In Zusammenhang einer Disskussion über den Sinn von Standard Functions Benchmarks (z.b. einen Pixelshaderbenchmark) machte er folgende Aussage:



Sorry für die etwas reisserische überschrift aber nach der Definition von Futuremark (mit der ich nicht einverstanden bin) ist das was Tom damals bei 3DLabs gemacht hat ein Cheat. Die Verwaltung des Texturspeichers gehört ja wohl klar in den Zuständigkeitsbereich des Treibers. Ebenso wie die optimale Ausnutzung von Registern und Ausführungseinheiten Aufgabe des Treibers sein sollte.

Ich kann hier keine Sünde erkennen.

ATI's Fehler (den du hier ansprichst) ist nicht, daß sie Shadercode umsortieren, sondern daß sie es statisch, mit dem Datenbank-Ansatz getan haben.

[Demirug]

Original geschrieben von zeckensack
Die Verwaltung des Texturspeichers gehört ja wohl klar in den Zuständigkeitsbereich des Treibers. Ebenso wie die optimale Ausnutzung von Registern und Ausführungseinheiten Aufgabe des Treibers sein sollte.

Ich kann hier keine Sünde erkennen.

ATI's Fehler (den du hier ansprichst) ist nicht, daß sie Shadercode umsortieren, sondern daß sie es statisch, mit dem Datenbank-Ansatz getan haben.

Für mich fällt das in die gleiche Schublade. Ob man jetzt einen Shadercode im Treiber hinterlegt oder das Shema wie die Texturen für einen Benchmark am besten im Speicher abgelegt werden sollten kommt doch auf das gleiche heraus. Es ist eine programmspezifische Optimierung die nur für diese spezielle Programm wirkt.

[zeckensack]

Original geschrieben von Demirug
Für mich fällt das in die gleiche Schublade. Ob man jetzt einen Shadercode im Treiber hinterlegt oder das Shema wie die Texturen für einen Benchmark am besten im Speicher abgelegt werden sollten kommt doch auf das gleiche heraus. Es ist eine programmspezifische Optimierung die nur für diese spezielle Programm wirkt. Ja, aber wenn es eine generische Optimierung gäbe, die das gleiche Resultat automatisch erzeugen kann, dann wäre es doch gut.

Und die muß es IMO geben (auch wenn sie noch nicht programmiert wurde, es muß sie geben). Irgendjemand hat bereits ein paar Dinge für die Hardware speziell angepaßt. Die Vorgehensweise dazu ist also (zumindest in Ansätzen) bekannt, man kann ein Regelwerk dazu erstellen und es durchgehen. Das ganze muß 'nur' noch automatisiert werden, dann haben wir alle gewonnen.

Diese Texturspeicher-Optimierung ist ja nun auch unter DX nicht mehr nötig, weil man sich dort nicht mehr mit applikationsverwalteten Surfaces rumschlägt, so weit ich das mitbekommen habe.

[aths]

Ich denke, das beste wäre, wenn die Entwickler gleich im Spiel verschiedene Shader haben, die je nach Hardware genommen werden.

[zeckensack]

Original geschrieben von aths
Ich denke, das beste wäre, wenn die Entwickler gleich im Spiel verschiedene Shader haben, die je nach Hardware genommen werden. Das führt dann dazu, daß das Spiel auf nicht voll unterstützter Hardware nicht optimal läuft.

Das kann zum einen Hardware eines 'zu kleinen' IHVs sein, zum anderen aber durchaus auch 'zu neue' Hardware. IMO keine gute Lösung.

[Kampf Ameise]

ich finds eh fraglich was man so als cheat bezeichnet, jede graka ist etwas anders und darf dann meiner meinung nach auch so angepasst werden so wie es der graka a´m besten passt, ABER NUR wenn die bildqualität darunter keinesfalls leidet

z.b. werden die treiber ja auch auf verschiedene spiele optimiert sagen wir mal ut2003 dann sagt auch keiner ati cheatet weil ihre neuen treiber 5 prozent schneller laufen... solange die bq gleich bleibt its gut, nun weiss ich nicht wie schlecht/gut die bildqualität it in 3dmark2003 mit den "cheat" treibern...

wenn natürlich die bq leidet dann würde ich es als cheat einstufen..

[Demirug]

Original geschrieben von zeckensack
Ja, aber wenn es eine generische Optimierung gäbe, die das gleiche Resultat automatisch erzeugen kann, dann wäre es doch gut.

Full Ack.

Und die muß es IMO geben (auch wenn sie noch nicht programmiert wurde, es muß sie geben). Irgendjemand hat bereits ein paar Dinge für die Hardware speziell angepaßt. Die Vorgehensweise dazu ist also (zumindest in Ansätzen) bekannt, man kann ein Regelwerk dazu erstellen und es durchgehen. Das ganze muß 'nur' noch automatisiert werden, dann haben wir alle gewonnen.

Bei Shadern gebe ich dir recht. Wobei man natürlich nicht weiss wie lange es dauert das komplette Regelwerk für einen Chip umzusetzen und wie lange dann dieser Code an einem einzigen Shader arbeitet.

Bei dem Speicherlayout stelle ich mir aber die IMO berechtigte Frage welche Informationen zu genau dem Layout geführt haben das dann beim erkennen des 3DWinbench hergestellt wurde. Wenn es die Rheienfolge war mit welcher die Chips die Sampels beim Durchlauf des Benchmarks erzeugt werden so wird man hier definitive keinen generische Weg finden.

Diese Texturspeicher-Optimierung ist ja nun auch unter DX nicht mehr nötig, weil man sich dort nicht mehr mit applikationsverwalteten Surfaces rumschlägt, so weit ich das mitbekommen habe.

Das stimmt so nicht ganz. Für Texturen welche als Rendertarget benutzt werden sollen gelten nach wie vor besondere Regeln. Bei "normale" Texturen kann man die Verwaltung der DX-Runtime und dem Treiber überlassen. Diese entscheiden dann gemeinsam wo sich welche Texture gerade befindet (Grafikkarte, AGP-Speicher, Hauptspeicher). Da aber die Grafiktreiber da auch noch ein Wörtchen mitzurenden haben kann man da immer optimierend eingreifen. Ich gehe auch davon aus das durch Veränderungen am Speicherlayout nach wie vor Performance gewinne möglich sind.

[Wishnu]

Hm, ich werde einmal wagen, dem allegemeinen Konsens zu widersprechen, denn für mich bedeutetet in diesem Zusammenhang bspw. das Hinzufügen von clip planes eindeutig cheaten.
Für mich geht dies über einfaches optimieren hinaus, denn:

Der Benchmark - so sinnig oder unsinnig er auch sein mag - gibt ein festes Szenario vor, an das man sich auch gefälligst zu halten hat. Punkt. Und dabei ist es völlig egal, daß das Ergebnis nicht beeinflußt wird. Wenn ich bswp. die Leistungsfähigkeit einer Rechnerarchitektur über die Laufzeit einer Sortierung mittels Bubble-Algorythmus ermitteln soll, dann kann ich dafür auf einem einzelnen System nicht einfach Quicksort nehmen, obwohl ich ja damit am Ergebnis nichts ändere.

Ein Workaround im Treiber - der speziell nur auf dieses Szenario ausgerichtet ist - stellt meiner Ansicht nach einen direkten Eingriff in die Rahmenbedingungen dar. Ein Bench soll alle Kandidaten vor die gleiche Aufgabe stellen, doch genau dies wird damit nicht mehr gewährleistet.
Stattdessen wird die Fähigkeit der Treiberentwickler getestet, sich im Nachhinein den Umständen anzupassen.

Und jenes geschieht sowieso nicht im Interesse des Kunden, da dies mit Sicherheit keine gängige Praxis im normalen Spielealltag darstellt. Ich kann mir kaum vorstellen, daß hier an Workarounds für jedes erscheinende Spiel gestrickt wird, sondern lediglich die Titel bedacht werden, die gerne als Benchmarkreferenzen herangezogen werden.
Letzendlich bedeutet dies eine Verzerrung des Wettbewerbes.

Das war einmal die Ansicht eines Nicht-3D-Cracks. So, und jetzt könnt ihr versuchen mich vom Gegenteil zu überzeugen... ;)

[aths]

Original geschrieben von Wishnu
Ein Workaround im Treiber - der speziell nur auf dieses Szenario ausgerichtet ist - stellt meiner Ansicht nach einen direkten Eingriff in die Rahmenbedingungen dar. Ein Bench soll alle Kandidaten vor die gleiche Aufgabe stellen, doch genau dies wird damit nicht mehr gewährleistet.Das sehe ich ganz ähnlich. Das Ersetzen von Shadern aus einer Datenbank ist für mich ein Cheat. Falls der Treiber i.A. Shader performancemäßig verbessern kann, ist es ein Feature. Wenn der 3DM03 PS.1.4 und 2.0 (ohne "+") testet, hat NV nicht das Recht, durch speziell für diesen Bench geschriebene 2.0+Shader zu nutzen.

NV bleiben andere Möglichkeiten, sich zu wehren. Zum Beispiel, einen 2.0+-Shader-Benchmark zu entwickeln.

[Quasar]

Original geschrieben von Wishnu
Der Benchmark - so sinnig oder unsinnig er auch sein mag - gibt ein festes Szenario vor, an das man sich auch gefälligst zu halten hat. Punkt. Und dabei ist es völlig egal, daß das Ergebnis nicht beeinflußt wird. Wenn ich bswp. die Leistungsfähigkeit einer Rechnerarchitektur über die Laufzeit einer Sortierung mittels Bubble-Algorythmus ermitteln soll, dann kann ich dafür auf einem einzelnen System nicht einfach Quicksort nehmen, obwohl ich ja damit am Ergebnis nichts ändere.

Ein Workaround im Treiber - der speziell nur auf dieses Szenario ausgerichtet ist - stellt meiner Ansicht nach einen direkten Eingriff in die Rahmenbedingungen dar. Ein Bench soll alle Kandidaten vor die gleiche Aufgabe stellen, doch genau dies wird damit nicht mehr gewährleistet.
Stattdessen wird die Fähigkeit der Treiberentwickler getestet, sich im Nachhinein den Umständen anzupassen.


aths,
IMO hast du unvollständig und sinnverzerrend gequotet. Ich denke, Wishnus Absicht war es vielmehr, allgemein die Optimierung eines vorgegebenen Szenarios als Cheat darzustellen.

So, wie du es gequotet hast, entsteht der Eindruck, nur nV wäre von dieser Art der Cheaterei betroffen.

[Razor]

Original geschrieben von zeckensack
Das führt dann dazu, daß das Spiel auf nicht voll unterstützter Hardware nicht optimal läuft.
Geht denn das überhaupt ?`
I.e. dass nicht voll unterstützte Hardware 'optimal' angesprochen werden kann ?
???
Original geschrieben von zeckensack
Das kann zum einen Hardware eines 'zu kleinen' IHVs sein, zum anderen aber durchaus auch 'zu neue' Hardware. IMO keine gute Lösung.
Welcher Lösungsansatz wäre dann Deiner Meinung nach besser ?
Hmmm...

Razor

[Razor]

Original geschrieben von aths
Das sehe ich ganz ähnlich. Das Ersetzen von Shadern aus einer Datenbank ist für mich ein Cheat. Falls der Treiber i.A. Shader performancemäßig verbessern kann, ist es ein Feature. Wenn der 3DM03 PS.1.4 und 2.0 (ohne "+") testet, hat NV nicht das Recht, durch speziell für diesen Bench geschriebene 2.0+Shader zu nutzen.

NV bleiben andere Möglichkeiten, sich zu wehren. Zum Beispiel, einen 2.0+-Shader-Benchmark zu entwickeln.
Das stellt sich IMO anders dar...
ATI und nVidia haben mit Ihren neuen DX9-Chips gänzlich unterschiedliche Architekturen geschaffen, die man einfach in Ihrer Arbeitsweise nicht vereinheitlichen kann. Das "+" bei nVidia bedeutet einfach nur, dass diese Chips mehr können, aber das steht auf einem anderen Blatt.

Es geht hier um unterschiedliche Architekturen, die nicht homogen angesprochen werden können. Wenn Du also sagst, dass mit dem Murks03 nur ATI-Hartware 'bemessen' werden kann, dann gebe ich Dir recht. Wenn aber FM selbst 'unabhängigkeit' propagiert und es defakto nicht ist, dann haben sie ein Problem und nVidia recht.

Bis denne

Razor

P.S.: Und merke... PS2a != PS2.0+
:D

[Wishnu]

Original geschrieben von Razor

Es geht hier um unterschiedliche Architekturen, die nicht homogen angesprochen werden können. Wenn Du also sagst, dass mit dem Murks03 nur ATI-Hartware 'bemessen' werden kann, dann gebe ich Dir recht. Wenn aber FM selbst 'unabhängigkeit' propagiert und es defakto nicht ist, dann haben sie ein Problem und nVidia recht.


Aber gibt es da vielleicht nicht so etas wie eine allgemein anerkannte Referenz, der man dann guten Gewissens zustimmen kann. Z.B. wenn Mickysoft sagt, bei Directx müsse das so und so sein... ;)

Aber mal Scherz beiseite: Mir dünkt FM hätte das in ihrer Verteidungsschrift bezüglich des 3DM so begründet, als daß sie nur die gebräuchlichsten Techniken einsetzen würden. So würde z.B. im DX7-Teil nur Single-Texturing anstatt Multitexturing eingesetzt, weil dies in diesem speziellen Szenario am sinnvollsten sei und auch in der Praxis so gemacht werden würde. Das Problem stecke also mehr in Nvidias weiterentwickelter Hardware, die damit - offensichtlich im Gegensatz zu bisher - nicht mehr optimal zurecht käme.
Ich sehe da ehrlich gesagt auch überhaupt keine andere Möglichkeit, als sich auf den größten gemeinsamen Nenner zu einigen. Wobei die Diskussion um diesern natürlich wieder kontrovers laufen würde. Irgendwie schreit das alles nach Dilemma, finde ich.

Tja, wenn man nun wirklich konsequent sein wollte, dürfte man entweder überhaupt keine Benches mehr entwickeln oder es ausdrücklich allen Herstellern genehmigen, den Code speziell auf ihre Hardware zu optimieren. Wobei sich natürlich ebenso die Frage stellt, welchen Beitrag ein Benchmark überhaupt liefern kann. Aber das ist ja an sich nichts neues... ;)

[Razor]

Original geschrieben von Wishnu
Aber gibt es da vielleicht nicht so etas wie eine allgemein anerkannte Referenz, der man dann guten Gewissens zustimmen kann. Z.B. wenn Mickysoft sagt, bei Directx müsse das so und so sein... ;)
Auch wenn das ein Scherz sein sollte... ;-)

M$ richtet sich i.d.R. nach den IHV's und nicht umgekehrt.
Wär ja auch echt ein Hammer, wenn M$ die Technologie-Entwicklung beeinflüssen würde.
(obwohl sie es gerade in anderen Bereichen deutlich tun ;-)
Original geschrieben von Wishnu
Aber mal Scherz beiseite: Mir dünkt FM hätte das in ihrer Verteidungsschrift bezüglich des 3DM so begründet, als daß sie nur die gebräuchlichsten Techniken einsetzen würden. So würde z.B. im DX7-Teil nur Single-Texturing anstatt Multitexturing eingesetzt, weil dies in diesem speziellen Szenario am sinnvollsten sei und auch in der Praxis so gemacht werden würde. Das Problem stecke also mehr in Nvidias weiterentwickelter Hardware, die damit - offensichtlich im Gegensatz zu bisher - nicht mehr optimal zurecht käme.
Ich sehe da ehrlich gesagt auch überhaupt keine andere Möglichkeit, als sich auf den größten gemeinsamen Nenner zu einigen. Wobei die Diskussion um diesern natürlich wieder kontrovers laufen würde. Irgendwie schreit das alles nach Dilemma, finde ich.
Na ja... im Speku-Forum findet derzeit eine sehr interessante Diskusion zu diesem Thema statt...
http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&threadid=71297

Ich will es hier nicht nochmals aufrollen, aber im Kern geht es darum, dass M$ mit ihrem neuesten SDK die Möglichkeit bietet, dem Compiler alternative Zielplattformen zu nennen, um damit unterschiedliche Architekturen in ihren Eigenheiten zu berücksichtigen und empfiehlt es auch, dies so zu tun. Und wenn FM damals den M$-Compiler bei FM zum Einsatz kam, haben sie damit mehr oder weniger unwissentlich auf ATI optimiert (die einzige DX9-Plattform bei Release von DX9, welches nach Meinung einer Forumsteilnehmer sogar 'nur' eine Beta-version war, die dann veröffentlicht wurde).
Original geschrieben von Wishnu
Tja, wenn man nun wirklich konsequent sein wollte, dürfte man entweder überhaupt keine Benches mehr entwickeln oder es ausdrücklich allen Herstellern genehmigen, den Code speziell auf ihre Hardware zu optimieren. Wobei sich natürlich ebenso die Frage stellt, welchen Beitrag ein Benchmark überhaupt liefern kann. Aber das ist ja an sich nichts neues... ;)
Vor allem wenn man von synthetischen Benchmarks spricht...
Unter dieser Voraussetzung also: Full Ack !

Razor

[aths]

Original geschrieben von Quasar
So, wie du es gequotet hast, entsteht der Eindruck, nur nV wäre von dieser Art der Cheaterei betroffen. Im Gegensatz zu Demirug halte ich das Shaderaustauschen von ATI für klaren Betrug, und das habe ich im Forum mehrfach geäußert. Ebenso, dass NVs Betrug aus meiner Sicht deutlich ernster ist. Soll ich denn jedes mal einen Roman oder zumindest eine komplette Erörterung schreiben?

[AlfredENeumann]

Original geschrieben von aths
Im Gegensatz zu Demirug halte ich das Shaderaustauschen von ATI für klaren Betrug, und das habe ich im Forum mehrfach geäußert. Ebenso, dass NVs Betrug aus meiner Sicht deutlich ernster ist. Soll ich denn jedes mal einen Roman oder zumindest eine komplette Erörterung schreiben?

Da schließe ich mich an. Wenn treiber das überall machen würde wäre das OK und eine funktione des Treibers. Aber das es "nur" beim Murks vorkommt ist es ein "Cheat".

[Demirug]

Original geschrieben von AlfredENeumann
Da schließe ich mich an. Wenn treiber das überall machen würde wäre das OK und eine funktione des Treibers. Aber das es "nur" beim Murks vorkommt ist es ein "Cheat".

Ich weiss noch mindestens ein anderes Programm wo das auch gemacht wird. ;)

[AlfredENeumann]

Original geschrieben von Demirug
Ich weiss noch mindestens ein anderes Programm wo das auch gemacht wird. ;)

Da gibts bestimmt mehrere von und ich denke nicht nur bei ATI.

[Demirug]

Original geschrieben von AlfredENeumann
Da gibts bestimmt mehere von und ich denke nicht nur bei ATI.

Sicherlich es würde mich wundern wenn es nicht so wäre.

[Wishnu]

Schwacher Trost: Nach Leibniz (hoffe mal , ich bringe jetzt keine Namen durcheinander) leben wir ja immer noch in der besten aller möglichen Welten... ;)

[zeckensack]

Original geschrieben von Razor
Geht denn das überhaupt ?`
I.e. dass nicht voll unterstützte Hardware 'optimal' angesprochen werden kann ?
???Gegenfragen:
Wieviele Entwicklerstudios haben Kyro-Karten im Haus?
Und wieviele Spiele laufen auf Kyro-Karten?

Wieviele Entwicklerstudios hatten vor zwei Jahren R300 oder GeforceFX-Karten?
Wieviele zwei Jahre alte Spiele laufen auf R300/NV30-Karten?
Welcher Lösungsansatz wäre dann Deiner Meinung nach besser ?
Hmmm...

Razor Die Anpassung denen überlassen, die sich damit auskennen: den IHVs, im Treiber.

[Demirug]

Original geschrieben von zeckensack
Gegenfragen:
Wieviele Entwicklerstudios haben Kyro-Karten im Haus?
Und wieviele Spiele laufen auf Kyro-Karten?

Wieviele Entwicklerstudios hatten vor zwei Jahren R300 oder GeforceFX-Karten?
Wieviele zwei Jahre alte Spiele laufen auf R300/NV30-Karten?

Das ist jetzt aber irgendwie ein Apfel und Birnenvergleich. Bei den Kyrokarten ging es ja darum neue unbekannte Spiele zum laufen zu bringen. Bei den R3xx/NV3x Karten sind ja sowohl die Spiele und die Techniken bekannt. IMHO also zwei vollkommen unterschiedliche Problemstellungen.

Die Anpassung denen überlassen, die sich damit auskennen: den IHVs, im Treiber.

Im Prinzip gebe ich dir recht. Aber was spricht dagegen das die Spieleentwickler die in Zukunft zur Verfügung stehende Unterstützung für Chipspezifische Shadererzeugung benutzten? Das grosse Problem das ich sehe ist das es bei den Shadern >= 1.4 keine Architekturneutralle form der Beschreibung gibt. Ich weiss das OpenGL 2.0 dieses Problem durch die direkte Übergabe von Hochsprachencode umgeht aber dort sehe ich ja andere Probleme. ;) Das Assemblerartige Konzept von DX stösst hier klar an eine Grenzen in dem es den Eindruck vermittelt man würde damit direkt einen genormten Prozessor (ala x86 CPUs) programmieren.

Für die IHVs gibt es aus diesem Dileam nur zwei Wege die IMHO möglichist gleichzeitig gegangen werden sollten.

1. Aus dem einfachen Assembler der sich im Moment im Treiber befindete einen vollwertigen optimierenden Compieler zu machen.

2. Den Entwickler direkt oder besser über MS diese Compilertechnik zukommen zu lassen damit diese den Treibern schon soweit es die Ausdrucksmitteln der Shader-Assemblersprache erlauben voroptimierte Shader liefern können was dann die Startupzeiten verringern dürfte und unter umständen lassen sich auf dieser höhren Ebene noch Optimierungsmöglichkeiten entdecken welche später nicht mehr so einfach zu sehen sind. Zudem könnten die Compiler durch die Benutzung bestimmter Anweisungsfolgen für den Treiber Hinweisse hinterlassen.

Grafikchip haben derzeit einfach noch nicht den Reifegrad erreicht bei den die unterschiede in der Architektur keine grossen Auswirkungen mehr auf die Performance haben. Normungsversuche wie DX und allgemeine ARB Extensions sind eine gute und notwendige Sache um eine breitflächige Nutzung neuer Technologien für die die Entwickler intteresant zu machen und dabei die Gefahr zu minimieren das kleinere Hersteller dabei übersehen werden weil die Entwickler den aufwand scheuen auch bei den kleinen die propertieren Schnittstellen zu benutzten. Auf dem Gebiet der Shader >= 1.4 muss man diesen Normungsversuch im ersten Anlauf als gescheitert ansehen da diese Shader einen bestimmten Komplexitätsgrad erreicht haben die Hardwarearchitekturen aber im Gegenzug aber noch sehr spezifisch sind. Bei beiden grossen APIs (D3D oder OpenGL) sehe ich dabei im ersten Anlauf keinen grossen Unterschied da auf beiden Seiten versucht wurde mit einfachen Assembler Sprachen zu arbeiten. Man scheint aber auf beiden Seiten sich des Problems bewusst zu sein und sucht das Heil in einer höheren Abstraktionsebene den Shaderhochsprachen. Bei DirektX ist die Verwendung der Hochsprache aber vorerst noch eine Option bei OpenGL 2.0 dagegen wird sie Pflicht werden. Beide Wege haben ihrer Vor und Nachteile.

Bei DX kann man auch weiterhin die Hochsprache umgehen und einen Shader schreiben der nicht auf jeder Hardware gut läuft solange die IHVs keine complexen optimierenden Compiler in die Treiber bauen. Gerade den kleineren IHVs dürften dafür die Spezialisten fehlen. Im Gegenzug stellt der zwischenschritt über den Shaderbytecode aber sicher das ein Shader auf einer bestimmten Hardware-Klasse auch defintive auf der Hardware laufen wird.

Bei OpenGL 2.0 entfällt die Gefahr des für einzelnen Chips unoptimalen Shadercodes. Die Hochsprache ist noch so allgemein das dort keine Probleme zu erwarten sind. Im Gegenzug erkauft man sich aber auch bestimmte Probleme. Der IHV muss jetzt einen Hochsprachencompiler in den Treiber einbauen von desen qualität viel abhängt gerade auf die kleinen IHVs sehe ich das Schwierigkeiten zukommen. Das zweite Problem ist das es keine möglichkeit gibt am Shadercode im Vorfeld zu erkennen auf welchen Chips er laufen wird und auf welchem nicht. Hier brauchen gerade die Spieleentwickler mehr Planungssicherheit. Eine Testsuit zu der jeder IHV ein Module beisteuert welche die Lauffähigkeit von Shadern prüft wäre da sicherlich ein guter Schritt aber was soll man tun um die Lauffähigkeit auch auf Hardware sicherzustellen welche es noch gar nicht gibt. In Fällen wo das dann nicht funktioniert werden wohl nur noch die Fallbackshader helfen können was wenn es nur an einer kleinigkeit liegt schade um den Eyecandy wäre.

In beiden Fällen müssen sich aber alle beiteiligiten Parteien darum bemühen die ISVs davon zu überzeugen das Shaderhochsprachen eine gute Sache sind. Und wenn ich mich da so gerade bei den Entwicklerkollegen etwas umsehe dürfte das ein sehr mühevoller Weg werden.

[Razor]

Original geschrieben von zeckensack
Gegenfragen:
Wieviele Entwicklerstudios haben Kyro-Karten im Haus?
Und wieviele Spiele laufen auf Kyro-Karten?

Wieviele Entwicklerstudios hatten vor zwei Jahren R300 oder GeforceFX-Karten?
Wieviele zwei Jahre alte Spiele laufen auf R300/NV30-Karten?
Ich würde Dich doch bitten, zuerst auf meine Frage zu antworten...
Original geschrieben von zeckensack
Die Anpassung denen überlassen, die sich damit auskennen: den IHVs, im Treiber.
Du meinst also, dass zuerst ein ATI-optimierter Shader-Code erzeugt werden soll, der dann via nVidia-Treiber zu einem nVidia-optimierten code umgesetzt werden muss. Ist das wirklich Dein ernst ? Schließlich würde das ja nicht nur für nVidia gelten, sondern für alle Hersteller, die mit Ihrer DX9-Hardware auf den Markt kommen. nVidia würde ich das ja vielleicht noch zutrauen, aber SiS, ImgTech etc ? Hmmm...

Ich denke, dass man das Problem eher an der Wurzel packen und nicht dazu übergehen sollte, die Symptome zu bekämpfen. M$ als Initiator hat ja nun einen solchen Weg eingeschlagen und entsprechende Verfahrensweisen empfohlen.

Razor

[StefanV]

Original geschrieben von Razor
Du meinst also, dass zuerst ein ATI-optimierter Shader-Code erzeugt werden soll, der dann via nVidia-Treiber zu einem nVidia-optimierten code umgesetzt werden muss. Ist das wirklich Dein ernst ? Schließlich würde das ja nicht nur für nVidia gelten, sondern für alle Hersteller, die mit Ihrer DX9-Hardware auf den Markt kommen. nVidia würde ich das ja vielleicht noch zutrauen, aber SiS, ImgTech etc ? Hmmm...

Ich denke, dass man das Problem eher an der Wurzel packen und nicht dazu übergehen sollte, die Symptome zu bekämpfen. M$ als Initiator hat ja nun einen solchen Weg eingeschlagen und entsprechende Verfahrensweisen empfohlen.

Razor

1. warum denn nicht??
Was spricht dagegen??
Bisher durfte sich ATI auch mit 3DFX und NV optimiertem Code rumschlagen, wobei nV sich auch zuerst mit 3DFX optimiertem Code rumschlagen durfte...

Abgesehen davon:

Wie gut die anderen Architekturen mit dem Standard M$ Compiler Profil (von dir 'ATI Code' genannt) zurechtkommen weiß bisher noch keiner, vielleicht fressen die anderen Chips den ATI wie NV Code sehr gut...

Außerdem hätte man das gleiche Recht für alle, da so alle die gleichen Probleme haben, die einen mehr (NV), die anderen weniger (ATI)...

2. siehe Zeckes ausführung...
Und was machen wir dann in 5 Jahren, wenn die Architekturen noch komplexer sind usw...

Wäre es da nicht besser lieber JETZT einen Compiler in den Treiber einzubaen denn später??
Früher oder Später wird man das eh machen müssen, warum nicht früher damit anfangen, damit man später weniger Probleme hat??

[zeckensack]

Original geschrieben von Demirug
Das ist jetzt aber irgendwie ein Apfel und Birnenvergleich. Bei den Kyrokarten ging es ja darum neue unbekannte Spiele zum laufen zu bringen. Bei den R3xx/NV3x Karten sind ja sowohl die Spiele und die Techniken bekannt. IMHO also zwei vollkommen unterschiedliche Problemstellungen.Die Anpassung der Spiele auf Kyro verlief so erfolgreich, weil sich jemand darum gekümmert hat, den es auch interessiert: die Treiberentwickler bei PowerVR.
Ebenso dürfte es ATI/NV am Herzen liegen, daß aktuelle Spiele auch in Zukunft gut auf ihrer dann aktuellen Hardware laufen.
Der Vergleich ist IMO so quer nicht, es ist einfach die Frage wem man die Verantwortung für diese Anpassungen geben soll. Geschätzten 5000 aktiven Entwicklerhäusern, oder einem halben dutzend mehr oder weniger aktiven IHVs?
Das löst btw auch elegant die 'Schuldfrage', wenn mal etwas nicht so gut klappt.

Im Prinzip gebe ich dir recht. Aber was spricht dagegen das die Spieleentwickler die in Zukunft zur Verfügung stehende Unterstützung für Chipspezifische Shadererzeugung benutzten?Dagegen spricht, daß man durch die Programmierung auf zu tiefer Ebene dem Treiber wertvolle Semantik vorenthält. Wenn sich die Architekturen nochmal ändern, ist der heute noch 'optimale' Code eben nicht mehr optimal. Von den Unterschieden zwischen den einzelnen Herstellern ganz zu schweigen.
Ich werde in meiner Antwort auf Razor's Post noch ein paar Beispiele bringen, was ich mit 'Semantik' meine.

Das grosse Problem das ich sehe ist das es bei den Shadern >= 1.4 keine Architekturneutralle form der Beschreibung gibt. Ich weiss das OpenGL 2.0 dieses Problem durch die direkte Übergabe von Hochsprachencode umgeht aber dort sehe ich ja andere Probleme. ;) Die Herausforderungen sind hochDu meinst sicher die Schwierigkeit, eben den Compiler zu bauen. Wie Stefan in seinem Schlußsatz absolut treffend schrieb: Warum nicht gleich jetzt, wenn es auf lange Sicht sowieso unvermeidbar ist? Wenn es nach mir ginge, hätte ich gerne schon vor zwei Jahren Hochsprachen gesehen. Und am besten gleich eine Empfehlung dazu an die Softwareschmieden, nichts anderes mehr zu benutzen.
Wie ein solches Interface auszusehen hat, kann ich gerne an anderer Stelle aufdröseln, vom Design her kann man das IMO durchaus bombenfest lösen.

Zur Begründung, ähnlich wie oben: sollen die ISVs sicherstellen, daß ihre Software auf allen existierenden und nicht extistierenden Chips das Optimum herausholt (ein Shaderset für NV2x, eins für NV3x, eins für R200, eins für R300, eins für SiS Xabre, ... ad nauseum), oder ... ???

Wenn ich dich in der Vergangenheit korrekt gelesen habe, dann bist du selbst der Meinung daß dieser Weg nicht gangbar ist. Es kostet einfach zu viel Manpower und zu viel Geld, und dazu ist die Motivation dafür aufgrund der Marktverhältnisse sowieso extrem gering.

Das Assemblerartige Konzept von DX stösst hier klar an eine Grenzen in dem es den Eindruck vermittelt man würde damit direkt einen genormten Prozessor (ala x86 CPUs) programmieren.DirectX lebt zu einem Großteil von der Illusion, es mache alles überall gleich. Diese Meinung ist viel zu weit verbreitet, traurigerweise nicht nur bei den Endanwendern. Bei x86 hat sich wenigstens herumgesprochen, daß einige CPUs SSE beherrschen, wieder andere 3DNow!, und wieder andere SSE2, und daß dies bei entsprechender Softwareanpassung vorteilhaft genutzt werden kann.

Bei Entwicklern sollte sich herumgesprochen haben, daß wenn man keine Zeit hat selbst SSE2-Code in Assembler zu basteln, man sich den Intel-Compiler schnappen kann, und dieser dies recht akzeptabel alleine hinbekommt.

Für die IHVs gibt es aus diesem Dileam nur zwei Wege die IMHO möglichist gleichzeitig gegangen werden sollten.

1. Aus dem einfachen Assembler der sich im Moment im Treiber befindete einen vollwertigen optimierenden Compieler zu machen.

2. Den Entwickler direkt oder besser über MS diese Compilertechnik zukommen zu lassen damit diese den Treibern schon soweit es die Ausdrucksmitteln der Shader-Assemblersprache erlauben voroptimierte Shader liefern können was dann die Startupzeiten verringern dürfte und unter umständen lassen sich auf dieser höhren Ebene noch Optimierungsmöglichkeiten entdecken welche später nicht mehr so einfach zu sehen sind. Zudem könnten die Compiler durch die Benutzung bestimmter Anweisungsfolgen für den Treiber Hinweisse hinterlassen.Ich behaupte, die Analyse von Anweisungsfolgen auf den 'höheren Sinn' hin ist Zeitverschwendung (sowohl bei den Entwicklern, als auch auf den Rechnern der Anwender). Hochsprachen jetzt, sofort, dann braucht man sich um dieses Problem nicht mehr zu kümmern. Ein halbwegs geschlossener 'industry push' in diese Richtung wäre insofern hilfreich, als daß er die Entwicklung der nötigen Compilerlogik forcieren würde.

Wie genau das gelöst wird, ist mir ehrlich gesagt wurscht, dann performt das Produkt eben schlecht, zumindest obliegt die 'Schuld' dann dem IHV. Von mir aus können sich da auch mehrere Firmen zusammenschließen, oder sie können die Teile aus dem GCC-Projekt abgreifen, oder sie lizensieren im vollen Wissen daß sie Performance verschenken einfach den MS-Compiler. Mir egal, Hauptsache es wird mit der nötigen Priorität angegangen.
<snip>
Man scheint aber auf beiden Seiten sich des Problems bewusst zu sein und sucht das Heil in einer höheren Abstraktionsebene den Shaderhochsprachen. Bei DirektX ist die Verwendung der Hochsprache aber vorerst noch eine Option bei OpenGL 2.0 dagegen wird sie Pflicht werden. Beide Wege haben ihrer Vor und Nachteile.Wobei IMO die Vorteile der Hochsprachen den Nachteil deutlich aufwiegen. Aber das hast du inzwischen sicher gemerkt :)
Bei DX kann man auch weiterhin die Hochsprache umgehen und einen Shader schreiben der nicht auf jeder Hardware gut läuft solange die IHVs keine complexen optimierenden Compiler in die Treiber bauen. Gerade den kleineren IHVs dürften dafür die Spezialisten fehlen. Im Gegenzug stellt der zwischenschritt über den Shaderbytecode aber sicher das ein Shader auf einer bestimmten Hardware-Klasse auch defintive auf der Hardware laufen wird.Ab jetzt Kurzform:
Was ist schwieriger, ein optimierender Hochsprachencompiler, oder eine Semantikanalyse und ein optimierender Recompiler?
Bytecode ist schlecht, da er Semantik zerstört.
<snip>
Das zweite Problem ist das es keine möglichkeit gibt am Shadercode im Vorfeld zu erkennen auf welchen Chips er laufen wird und auf welchem nicht.<snip>
aber was soll man tun um die Lauffähigkeit auch auf Hardware sicherzustellen welche es noch gar nicht gibt.
Shadersets. Du übergibst der API den Shader, und erhältst die Rückmeldung "Sorry, läuft nicht". Du versuchst also einen einfacheren Shader. Im Unterschied zur aktuellen Bedeutung von Shadersets ist diese Vorgehensweise absolut Herstellerneutral und kann in die Zukunft wachsen (mehr dazu an Razor).

In beiden Fällen müssen sich aber alle beiteiligiten Parteien darum bemühen die ISVs davon zu überzeugen das Shaderhochsprachen eine gute Sache sind. Und wenn ich mich da so gerade bei den Entwicklerkollegen etwas umsehe dürfte das ein sehr mühevoller Weg werden. Dann frage die Kollegen doch vielleicht einfach mal, warum sie nicht konsequent ihre kompletten Programme in Assembler schreiben ;)

[Demirug]

@zeckensack: Ich bin ein Absoluter Fan von Shaderhochsprachen aber ich habe eben doch gerne noch etwas Planungssicherheit in der Hinterhand.

Bezüglich der "Chipspezifische Shadererzeugung" glaube ich das wir uns da missverstanden haben. Ich meinte damit das man seine Shader in der Hochsprache schreibt und dann mit dem Compiler chipsezifisch umsetzten läst. Die ISV sollen auf keine Fall anfangen für jeden Chip von Hand shader zu bauen. Was aber einige leider tun werden. :(

In dieser Beziehung ist OpenGL 2.0 besser da es den Entwickler keine wahl mehr läst. Aber wenn ich mir anschaue was auf den letzten Sitzungen des ARB los war sehe ich da auch wolken am Himmel. Es gibt auch hier kräfte (von Seiten der ISV) die versuchen die bestehenden Shaderextensions zum bestandteil des Cores zu machen um weiterhin die gesicherte möglichkeit zu haben ihere Shader in "Assembler" zu schreiben.

Deine Idee mit den Shadersets löst natürlich das primäre Problem der Lauffähigkeit aber wenn die Chips in den Möglichkeiten zu weit streuen wird es kompliziert wenn sie einmal den Minimumlevel erreichen und irgendwann muss man aufhören Alternativen für einen Effekt einzubauen sont ist der Vorteil der Hochsprache ja wieder dahin.

Was ich eben hier gerne hätte wäre eine festlegung eines Featuresets und ein Prüfprogramm welches Shader auf konformität prüft. Bei DX habe ich hier den Vorteil das jeder Hochsprachenshader welcher sich zu einem 2.0 Shader compilieren läst sich auch sicher für jede DX9 Karte compilieren läst.

Ich brauche ja auch für DX Effektsets (ich benutze lieber diesen Begriff weil man ja für einen Effekt im Multipassverfahren mehrer Shader braucht) aber die Menge der Varianten läst sich im Vorfeld genau und sicher bestimmen.

Zum Thema Assembler und Spieleentwickler. Es gibt da wirklich noch welche die würde am liebsten alles in Assembler programmieren. Sie dürfen es aber nicht tun weil sie das Buget dafür nicht haben. Bei den Shadern ist aber der primäre Zeitgewinn durch Hochsprachen shader nicht so gross als das man das Buget als Druckmittel benutzten kann. Die Entwickler die unbedingt alles in Assmbler machen wollen sind der Meinung das sie dadurch die volle Kontrolle hätte. Bei Shadern ist das ein absoluter Irrglaube aber mach das denen einmal klar. Es gibt da einfach zu viele die das nicht einsehen wollen. Langfristig haben sich aber bisher immer die Hochsprachen durchgesetzt und so habe ich auch hier Hoffnung das MS auch irgendwann in DX die Assemblerschnittstelle tot legen kann. Im Moment geht das noch nicht weil sie sich damit zu viele Feinde machen würden.

[zeckensack]

Razor,
ich hab's mal umgedreht.
Original geschrieben von Razor
Du meinst also, dass zuerst ein ATI-optimierter Shader-Code erzeugt werden soll, der dann via nVidia-Treiber zu einem nVidia-optimierten code umgesetzt werden muss. Ist das wirklich Dein ernst ? Schließlich würde das ja nicht nur für nVidia gelten, sondern für alle Hersteller, die mit Ihrer DX9-Hardware auf den Markt kommen. nVidia würde ich das ja vielleicht noch zutrauen, aber SiS, ImgTech etc ? Hmmm...Nein, das wollte ich natürlich nicht sagen. Ich will überhaupt keinen auf irgendeine Zielarchitektur runterkompilierten Shadercode mehr sehen. Es ist Der Falsche Weg (TM), und es überträgt die Bürde der optimalen Ausnutzung jeder Zielarchitektur ausgerechnet denen übertragen, die sich damit nicht beschäftigen können oder wollen (=> von Deadlines und knausigeren Publishern gepeinigte Software-Entwickler), oder gar noch schlimmer, einem Politmonster-Moloch ohne gleichen (welcher der Anwesendenen ist bereit, die Möglichkeit einzuräumen, daß der 'schlecht für NV'-Code des MS-Compilers eine Retourkutsche für die recht unerfreulichen XBox-Verhandlungen war? Andererseits steht NV ja auch im IMO durchaus verdienten Ruf, brutal gute OpenGL-Treiber zu machen ... ist das wirklich in Microsoft's Interesse?).
Ich denke, dass man das Problem eher an der Wurzel packen und nicht dazu übergehen sollte, die Symptome zu bekämpfen. M$ als Initiator hat ja nun einen solchen Weg eingeschlagen und entsprechende Verfahrensweisen empfohlen.

Razor MS hat versagt, und wird wieder versagen. Wer vertritt denn die Interessen derjenigen, die NV-Chips ab Geforce 1 unter DX vollständig ausreizen möchten? Oder die Interessen der R200-Besitzer, die vernünftige Performance in DX8-Spielen haben wollen? Microsoft sicher nicht, diese beiden Züge sind längst abgefahren. Und weitere werden folgen, so lange Microsoft darauf besteht, Architekturen die unterschiedlicher nicht sein können aus politischen Gründen ("DX funktioniert überall gleich") in eine eindimensionale Ordnung zu zwängen (=> bis in alle Ewigkeit, beziehungsweise bis DX keine Sau mehr interessiert).

Ich würde Dich doch bitten, zuerst auf meine Frage zu antworten...Deine Frage habe ich IMO irgendwie schon beantwortet :)
Hardware kann dann optimal ausgereizt werden, wenn der IHV sich darum kümmert, die Software zu untersuchen und die Flaschenhälse im Treiber zu eliminieren. Dazu muß der Treiber aber zunehmend wissen, was die Software denn nun will.

Bisherige erfolgreiche Arbeiten in diesem Bereich waren immer nur retrospektiv (zB läuft Battlefield 1942 jetzt ganz ausgezeichnet auf Kyro-Karten, nicht aber beim Release).
Uralte Spiele laufen auch löblich auf R300, obwohl dieser keinerlei 'fixed function'-Einheiten mehr für Dinge enthält, die sich auch über Shader lösen lassen. Im Ergebnis muß man folgern, daß es ATI wohl gelungen ist, die (vergleichsweise simplen) Möglichkeiten von DX5-DX7 in optimale Shaderprogramme umzuwandeln. Wenn das so weitergehen soll, dann muß die 'Beschreibungssprache' aber auf eine höhere Ebene gehen.

Semantik :)

Beispiele, von simpel nach extrem sortiert: buffer clears
hört sich jetzt unglaublich dämlich an, aber im Grunde sind diese Operationen überflüssig. Man kann einen beliebigen Puffer auch löschen, indem man einfach ein bildfüllendes Viereck zeichnet.
Macht man aber nicht. Man sagt dem Treiber was man vorhat, und dieser tut es so effizient wie es ihm möglich ist. Dadurch erzeugt man einen Ansatzpunkte, wo der IHV Optimierungen anlegen kann. Gut so!
Eine Radeon 8500LE erreicht beim löschen des Z-Buffers 25 Gigapixel/s. Würde man diese 'nutzlose' Semantik des buffer clears streichen, müßte man sich mit 1 GP/s begnügen.
trilinearer Texturfilter
Die olle Voodoo 2 kam mit einer eigenen API daher, und diese nannte sich Glide. Glide 'kennt' den trilinearen Texturfilter nicht wirklich, ebenso beherrscht die Voodoo 2 diesen Filter nur bei Single-Texturing. Dann muß die Applikation 'zu Fuß' die beiden Textureinheiten verschalten, zudem werden durch diese Verschaltung 'Opcodes' belegt, die nicht mehr für gewünschte Blending-Operationen verfügbar sind. Macht ja nichts, braucht man ja nicht so oft. Ha!
NVIDIA hat dagegen auf eine API gesetzt, die das explizite Anfordern von tri-fi erlaubt. Ein simpler Hardware-Tweak (Rezirkulation aka loop back) machte dies auf Geforce 2 auch im Multitexturing verfügbar, obwohl sie ebenso wie die Voodoo 2 (pro Pipeline) nur zwei Bilinear-fähige Textursampler besitzt. Gäbe es die Semantik nicht, hätte es damals auch keinen Grund für diesen Architektur-Tweak gegeben.
Sinus/Cosinus
Wenn ich in meiner Funktion als Programmierer einen Sinus will, dann schreibe ich das auch hin, ob's jetzt in einem C-Programm ist, oder in einem Shader. Es gibt aber durchaus Prozessoren, die überhaupt keinen Opcode für 'berechne Sinus' haben. Dort ist es dann die Aufgabe des Compilers das zu wissen, und beim Kompilieren den Sinus in eine Approximationsreihe (Taylor-Serie) umzuwandeln. Das ist mir dann egal, weil's ja doch funktioniert(TM).
Wenn ich allerdings selbst auf einem solchen Rechner arbeiten würde, und darüberhinaus daran Interesse hätte, daß das ganze auch auf 'besseren' Rechnern optimal läuft, dann würde ich den Teufel tun selbst die Taylor-Serie zu schreiben. Das würde nur den Job des Compilers erschweren, weil dieser dann in der Lage sein müßte, zu erkennen daß ich eigentlich nur einen Sinus will. Das ist natürlich einfacher wenn ich das auch so hinschreibe.
Extrem vertex shading, und features die's noch garnicht gibt
Angenommen, wir haben das Jahr 2000, und die Grafik-Welt sei in Ordnung. Ich setze mir in den Kopf, einen Vertex Shader zu schreiben, der eine skeletal animation für ein Modell mit 57 Knochen berechnet. Ich schreibe ihn in einer Hochsprache, und benutze natürlich eine Schleife, der Übersicht wegen (dabei weiß ich ganz genau, daß kein verfügbarer Grafikchip VS in Hardware kann, ganz zu schweigen von flow control). Ist Job des Treibers, da etwas draus zu machen. Ich kriege zwar von meinem Graka-Treiber höflich mitgeteilt, daß ich doch wohl einen an der Klatsche habe, so einen fetten Shader zu schreiben, aber ich bleibe stur, weil ich keine Zeit/kein Geld/keine Lust habe, das Vertex Processing von Hand zu machen.
Ein Jahr später, der Treiber meiner Firma der Wahl kennt sich jetzt auch mit SSE2 aus, was kräftig für die Kompilierung der Vertex Shader eingesetzt wird. Mein Programm verzeichnet einen Speedgewinn von ungefähr 80%. Dabei habe ich nie einen P4 besessen :|
Noch ein Jahr später, ein Grafikchip erscheint, der in der Lage ist Vertex Shader mit bis zu 128 Instruktionen in Hardware auszuführen. Die Schleife muß natürlich abgerollt werden, da er kein flow control kann. Außerdem reicht die Hardware nur für 23 Knochen. Macht ja nichts, die ersten 34 kann ja der Treiber machen, und den Rest die Hardware.
Schon wieder ein Jahr später, alle Limits fallen. Mein Shader läuft komplett in Hardware.
Noch ein Jahr später, das neueste und beste kann jetzt auch flow control, der kompilierte Shadercode wird um Faktor 57 kompakter.


Zum letzten: Wäre ich jetzt 'blöd' gewesen, hätte ich das Vertex Processing in handgebasteltem Assembler geschrieben, und dadurch alle Zugewinne durch noch nicht verfügbare Features verschenkt.
Wäre diese Geschichte wahr, dann hätte ich keine andere Wahl gehabt. Und das liegt ausschließlich daran, daß die vorhandenen APIs dieser Zeit keine Hochsprachen forciert haben, sondern sich schick 'low level' um das wesentliche herumgedrückt haben.

Uff :)

[Piffan]

Tolles Niveau hier :laola:

Zum Topic: Ein Bench wird ad absurdum geführt, wenn ich einen Erkennungsmechanismus einbaue und darauf hin den Treiber Dinge machen lasse, die er ohne die Erkennung nicht tut. Bei BENCHES man sowas nicht machen tut! :finger:

Bei Spielen hingegen ist die Sache ok, wenn die Darstellung nicht verändert wird. Da kann sich der Spieler ja nur freuen, wenn sein Lieblingsspiel noch besser funzt als vorher. Danke an die fleissigen Treiberprogger, Aua wegen der immer größeren Downloads der Treiber...

Bei Benches wäre eine dynamische Anpassung kein Cheat, eine statische Anpassung, welche nach Erkennung des Benches dann eigene fixe Shader bringt, ist klar Beschiss....

Ich habe für meinen Teil keine Probleme, zwischen echter Mogelei und erlaubten Optimierungen zu unterscheiden...

[Piffan]

Original geschrieben von zeckensack
Razor,
ich hab's mal umgedreht.
Nein, das wollte ich natürlich nicht sagen. Ich will überhaupt keinen auf irgendeine Zielarchitektur runterkompilierten Shadercode mehr sehen. Es ist Der Falsche Weg (TM), und es überträgt die Bürde der optimalen Ausnutzung jeder Zielarchitektur ausgerechnet denen übertragen, die sich damit nicht beschäftigen können oder wollen (=> von Deadlines und knausigeren Publishern gepeinigte Software-Entwickler), oder gar noch schlimmer, einem Politmonster-Moloch ohne gleichen (welcher der Anwesendenen ist bereit, die Möglichkeit einzuräumen, daß der 'schlecht für NV'-Code des MS-Compilers eine Retourkutsche für die recht unerfreulichen XBox-Verhandlungen war? Andererseits steht NV ja auch im IMO durchaus verdienten Ruf, brutal gute OpenGL-Treiber zu machen ... ist das wirklich in Microsoft's Interesse?).
[SIZE=1]MS hat versagt, und wird wieder versagen. Wer vertritt denn die Interessen derjenigen, die NV-Chips ab Geforce 1 unter DX vollständig ausreizen möchten? Oder die Interessen der R200-Besitzer, die vernünftige Performance in DX8-Spielen haben wollen? Microsoft sicher nicht, diese beiden Züge sind längst abgefahren. Und weitere werden folgen, so lange Microsoft darauf besteht, Architekturen die unterschiedlicher nicht sein können aus politischen Gründen ("DX funktioniert überall gleich") in eine eindimensionale Ordnung zu zwängen (=> bis in alle Ewigkeit, beziehungsweise bis DX keine Sau mehr interessiert).

Deine Frage habe ich IMO irgendwie schon beantwortet :)
Hardware kann dann optimal ausgereizt werden, wenn der IHV sich darum kümmert, die Software zu untersuchen und die Flaschenhälse im Treiber zu eliminieren. Dazu muß der Treiber aber zunehmend wissen, was die Software denn nun will.

Bisherige erfolgreiche Arbeiten in diesem Bereich waren immer nur retrospektiv (zB läuft Battlefield 1942 jetzt ganz ausgezeichnet auf Kyro-Karten, nicht aber beim Release).
Uralte Spiele laufen auch löblich auf R300, obwohl dieser keinerlei 'fixed function'-Einheiten mehr für Dinge enthält, die sich auch über Shader lösen lassen. Im Ergebnis muß man folgern, daß es ATI wohl gelungen ist, die (vergleichsweise simplen) Möglichkeiten von DX5-DX7 in optimale Shaderprogramme umzuwandeln. Wenn das so weitergehen soll, dann muß die 'Beschreibungssprache' aber auf eine höhere Ebene gehen.

Semantik :)

Beispiele, von simpel nach extrem sortiert: buffer clears
hört sich jetzt unglaublich dämlich an, aber im Grunde sind diese Operationen überflüssig. Man kann einen beliebigen Puffer auch löschen, indem man einfach ein bildfüllendes Viereck zeichnet.
Macht man aber nicht. Man sagt dem Treiber was man vorhat, und dieser tut es so effizient wie es ihm möglich ist. Dadurch erzeugt man einen Ansatzpunkte, wo der IHV Optimierungen anlegen kann. Gut so!
Eine Radeon 8500LE erreicht beim löschen des Z-Buffers 25 Gigapixel/s. Würde man diese 'nutzlose' Semantik des buffer clears streichen, müßte man sich mit 1 GP/s begnügen.
trilinearer Texturfilter
Die olle Voodoo 2 kam mit einer eigenen API daher, und diese nannte sich Glide. Glide 'kennt' den trilinearen Texturfilter nicht wirklich, ebenso beherrscht die Voodoo 2 diesen Filter nur bei Single-Texturing. Dann muß die Applikation 'zu Fuß' die beiden Textureinheiten verschalten, zudem werden durch diese Verschaltung 'Opcodes' belegt, die nicht mehr für gewünschte Blending-Operationen verfügbar sind. Macht ja nichts, braucht man ja nicht so oft. Ha!
NVIDIA hat dagegen auf eine API gesetzt, die das explizite Anfordern von tri-fi erlaubt. Ein simpler Hardware-Tweak (Rezirkulation aka loop back) machte dies auf Geforce 2 auch im Multitexturing verfügbar, obwohl sie ebenso wie die Voodoo 2 (pro Pipeline) nur zwei Bilinear-fähige Textursampler besitzt. Gäbe es die Semantik nicht, hätte es damals auch keinen Grund für diesen Architektur-Tweak gegeben.
Sinus/Cosinus
Wenn ich in meiner Funktion als Programmierer einen Sinus will, dann schreibe ich das auch hin, ob's jetzt in einem C-Programm ist, oder in einem Shader. Es gibt aber durchaus Prozessoren, die überhaupt keinen Opcode für 'berechne Sinus' haben. Dort ist es dann die Aufgabe des Compilers das zu wissen, und beim Kompilieren den Sinus in eine Approximationsreihe (Taylor-Serie) umzuwandeln. Das ist mir dann egal, weil's ja doch funktioniert(TM).
Wenn ich allerdings selbst auf einem solchen Rechner arbeiten würde, und darüberhinaus daran Interesse hätte, daß das ganze auch auf 'besseren' Rechnern optimal läuft, dann würde ich den Teufel tun selbst die Taylor-Serie zu schreiben. Das würde nur den Job des Compilers erschweren, weil dieser dann in der Lage sein müßte, zu erkennen daß ich eigentlich nur einen Sinus will. Das ist natürlich einfacher wenn ich das auch so hinschreibe.
Extrem vertex shading, und features die's noch garnicht gibt
Angenommen, wir haben das Jahr 2000, und die Grafik-Welt sei in Ordnung. Ich setze mir in den Kopf, einen Vertex Shader zu schreiben, der eine skeletal animation für ein Modell mit 57 Knochen berechnet. Ich schreibe ihn in einer Hochsprache, und benutze natürlich eine Schleife, der Übersicht wegen (dabei weiß ich ganz genau, daß kein verfügbarer Grafikchip VS in Hardware kann, ganz zu schweigen von flow control). Ist Job des Treibers, da etwas draus zu machen. Ich kriege zwar von meinem Graka-Treiber höflich mitgeteilt, daß ich doch wohl einen an der Klatsche habe, so einen fetten Shader zu schreiben, aber ich bleibe stur, weil ich keine Zeit/kein Geld/keine Lust habe, das Vertex Processing von Hand zu machen.
Ein Jahr später, der Treiber meiner Firma der Wahl kennt sich jetzt auch mit SSE2 aus, was kräftig für die Kompilierung der Vertex Shader eingesetzt wird. Mein Programm verzeichnet einen Speedgewinn von ungefähr 80%. Dabei habe ich nie einen P4 besessen :|
Noch ein Jahr später, ein Grafikchip erscheint, der in der Lage ist Vertex Shader mit bis zu 128 Instruktionen in Hardware auszuführen. Die Schleife muß natürlich abgerollt werden, da er kein flow control kann. Außerdem reicht die Hardware nur für 23 Knochen. Macht ja nichts, die ersten 34 kann ja der Treiber machen, und den Rest die Hardware.
Schon wieder ein Jahr später, alle Limits fallen. Mein Shader läuft komplett in Hardware.
Noch ein Jahr später, das neueste und beste kann jetzt auch flow control, der kompilierte Shadercode wird um Faktor 57 kompakter.


Zum letzten: Wäre ich jetzt 'blöd' gewesen, hätte ich das Vertex Processing in handgebasteltem Assembler geschrieben, und dadurch alle Zugewinne durch noch nicht verfügbare Features verschenkt.
Wäre diese Geschichte wahr, dann hätte ich keine andere Wahl gehabt. Und das liegt ausschließlich daran, daß die vorhandenen APIs dieser Zeit keine Hochsprachen forciert haben, sondern sich schick 'low level' um das wesentliche herumgedrückt haben.

Uff :)

Klasse, diese Abhandlung. Willste nicht mal einen Artikel für 3dconcept schreiben? Verständlich und witzig obedrein, so muß ein Insider für seine Fans schreiben....

Ab heute dicker Fan von Zeckensack, von Demi schon länger :up:

[Exxtreme]

zecki,

ein super Posting, welches die derzeitige Situation sehr gut beschreibt.

[Demirug]

zeckensack, ich sehe das wir im Grunde ja das gleiche wollen.

Dumnerweise gab und gibt es da von allen Seiten wiederstände.

Du schiebst ja den schwarzen Peter gerne MS zu. Natürlich ist bei DX nicht alles perfekt bei weitem nicht aber generel die Normierungbemühungen von MS zu verdamen erscheint mir jetzt von dir ein wenig zu eindimensional gedacht. Wozu die absolute kontrolle bei gleichzeitigem verzicht auf Normierung führen kann haben wir in der Vergangenheit ja auch schon gesehen. Eines der jüngeren Beispiele ist hier ja NWN und die per Pixel Effekte.

Aber zurück zu den Wiederständen.

Die IHVs haben leider wenig interesse daran Features die irgendwann mal in ihrer Hardware vorhanden sein werden jetzt schon in Form einer Softwareemulation zur Verfügung zu stellen. Dadurch wird es natürlich schwer das heutige Spiele von den neuen Features der Grafikkarten von morgen profitieren könnten. Das die IHVs das nicht tun wollen kann ich schon verstehen da es ja nur Geld kostet und nicht unbedingt die Verkaufszahlen erhöht.

Aber auch die Softwareentwickler sind zu gerne noch eine Bremse indem sie sich weigern eine höhere Abstraktion überhaupt anzunehmen. Sie bestehen auf eine absolute Kontrolle aber gleichzeitig wollen sie natürlich nicht für jeden Chip die gleiche Arbeit mehrfach machen. Ein Wiederspruch in sich aber die meisten scheinen das denoch nicht zu merken. Anders kann ich mir zum Beispiel viele Argumente bei der gerade in der DXDevList heftig diskutierte Forderung nach einem Low-Level Shadertest nicht erklären.

Wie schon richtig gesagt wurde konzentiert sich die heutige 3d programmierung noch viel zu sehr auf die Frage nach dem WIE und nicht nach dem WAS. Einer idealen 3D API sollte man IMHO nicht sagen müssen wie sie einen Szene rendern soll sondern man sollte ihr einfach nur die Szene beschreiben müssen. Die profanen Dinge wie das Aufteilen eines Effekts auf mehrer Passes oder das richtige anordnen der Renderjobs für Dinge wie Transparenz sollten alle automatisch ablaufen. Aber das bleibt wohl ein schöner Traum von mir.

So muss man nun mit den Realitäten leben wie sie nun vorhanden sind und für DX9 scheint mir der beste Weg nun folgenden Vorgehensweise zu sein.

Man schreibt die Shader nur in HLSL und stellt sicher das sie sich mit den 2.0 Profil fehlerfrei kompilieren lassen. Da wie Zeckensack schon gesagt hat jede Compilerstufe die semantik reduziert ist es nun aber nicht wirklich sinnvoll den als 2.0 Shader kompilierten Shader direkt in die Daten des Programms zu packen und dann dem Treiber zu übergegebn. Es erscheint viel sinnvoller den HLSL Code mit auszuliefern und erst beim Endkunden gezielt das am besten zu der Kundenhardware passende Zielprofil zu benutzen. Zwar wird auch in diesem Fall der Treiber nicht die vollständige Semantik erhalten aber es ist IMHO immer noch der beste derzeit mögliche Weg dem Treiber so viele Informationen wie möglich zukommen zu lassen. Allerdings sollte MS in diesem Punkt noch dringend etwas nachbessern indem sie den IHVs erlauben den standard MS Compiler für bestimmte Profile durch einen eigenen zu ersetzten welcher dann Bestandteil des Treibers wäre.

Ein vollständiger Verzicht auf die Assmblershaderschnitstelle wäre natürlich auch schön aber in diesem Fall braucht man auf jeden Fall ein neues Verfahren zum Sicherstellen der Kompatibilität. Desweiteren dürfte derzeit der Versuch die Möglichkeit Shader in "Assmbler" zu schreiben zu entfernen noch auf zuviel Wiederstand stossen.

[Piffan]

Original geschrieben von Demirug
zeckensack, ich sehe das wir im Grunde ja das gleiche wollen.

Aber auch die Softwareentwickler sind zu gerne noch eine Bremse indem sie sich weigern eine höhere Abstraktion überhaupt anzunehmen. Sie bestehen auf eine absolute Kontrolle aber gleichzeitig wollen sie natürlich nicht für jeden Chip die gleiche Arbeit mehrfach machen. Ein Wiederspruch in sich aber die meisten scheinen das denoch nicht zu merken. Anders kann ich mir zum Beispiel viele Argumente bei der gerade in der DXDevList heftig diskutierte Forderung nach einem Low-Level Shadertest nicht erklären.



Und dann wäre da noch die Kooperation zwischen Spielefirmen und den Chipherstellern, die auch für Widerstand sorgt...da wird das Fummeln auf niedrigem Niveau bzw. eng an der Hardware gern als Argument für die Überlegenheit der Treiber/Hardware gewisser Firmen verwendet...der Kunde hat ja keine Ahnung bzw. ihm es es egal, warum das Spiel X auf der Hardware Y besser läuft, er kauft halt die "bessere" Hardware. *eg*

[zeckensack]

Original geschrieben von Demirug
zeckensack, ich sehe das wir im Grunde ja das gleiche wollen.Schön :)
Dumnerweise gab und gibt es da von allen Seiten wiederstände.

Du schiebst ja den schwarzen Peter gerne MS zu. Natürlich ist bei DX nicht alles perfekt bei weitem nicht aber generel die Normierungbemühungen von MS zu verdamen erscheint mir jetzt von dir ein wenig zu eindimensional gedacht. Wozu die absolute kontrolle bei gleichzeitigem verzicht auf Normierung führen kann haben wir in der Vergangenheit ja auch schon gesehen. Eines der jüngeren Beispiele ist hier ja NWN und die per Pixel Effekte.Ich verdamme MS, weil sie mich immer mal wieder schwer enttäuschen, und gleichzeitig heftiges Kopfkratzen auslösen.
Normierung ist eine feine Sache, aber ich habe oft den Eindruck, daß die sich nicht die nötige Mühe geben, das 'richtige' zu tun. Man hebt sich dort anscheinend gerne Dinge für die nächste Version auf, was (Paranoia ahoi!) sicher auch ein günstiges Instrument für die nächste erwünschte Welle von 'Upgrades' ist. DX7 gibt es nicht für Windows 95 ... ;)

Zu NWN: ich weiß warum du dieses Beispiel gewählt hast :D
Ich halte OpenGL für eine exzellent designte API, mir fällt ganz ehrlich nichts ein, was man an der grundlegenden Architektur ändern müßte. Natürlich fehlt auch hier die konsequente Durchdringung mit Hochsprachen. Das ist eine Feature-Frage, die mit dem nötigen Willen lösbar ist, dank des wohl oft verkannten Extension-Mechanismus müßte man dafür die API an sich nicht umwerfen.
Aber zurück zu den Wiederständen.

Die IHVs haben leider wenig interesse daran Features die irgendwann mal in ihrer Hardware vorhanden sein werden jetzt schon in Form einer Softwareemulation zur Verfügung zu stellen. Dadurch wird es natürlich schwer das heutige Spiele von den neuen Features der Grafikkarten von morgen profitieren könnten. Das die IHVs das nicht tun wollen kann ich schon verstehen da es ja nur Geld kostet und nicht unbedingt die Verkaufszahlen erhöht.Das leuchtet auf den ersten Blick ein, auf den zweiten Blick frage ich mich aber ernsthaft, wie groß der Aufwand wohl gewesen wäre, die 'damals' limitierte Flexibilität hochsprachlich verfügbar zu machen. Ala Geforce 2-Techlevel:out.rgb=texture0.rgb*texture1.rgb+interpolated_color.alpha
out.alpha=1.0Wäre das wirklich so schwer gewesen?
Ich brauche tatsächlich mehr Code, wenn ich das gleiche 'low level' schreiben will.

Aber auch die Softwareentwickler sind zu gerne noch eine Bremse indem sie sich weigern eine höhere Abstraktion überhaupt anzunehmen. Sie bestehen auf eine absolute Kontrolle aber gleichzeitig wollen sie natürlich nicht für jeden Chip die gleiche Arbeit mehrfach machen. Ein Wiederspruch in sich aber die meisten scheinen das denoch nicht zu merken. Anders kann ich mir zum Beispiel viele Argumente bei der gerade in der DXDevList heftig diskutierte Forderung nach einem Low-Level Shadertest nicht erklären.Dann leuchte denen doch mal bitte ordentlich heim :D
Wie schon richtig gesagt wurde konzentiert sich die heutige 3d programmierung noch viel zu sehr auf die Frage nach dem WIE und nicht nach dem WAS. Einer idealen 3D API sollte man IMHO nicht sagen müssen wie sie einen Szene rendern soll sondern man sollte ihr einfach nur die Szene beschreiben müssen. Die profanen Dinge wie das Aufteilen eines Effekts auf mehrer Passes oder das richtige anordnen der Renderjobs für Dinge wie Transparenz sollten alle automatisch ablaufen. Aber das bleibt wohl ein schöner Traum von mir.Ich weiß noch nicht genau wie ich jetzt argumentieren soll, aber ich bin eher gegen die Integration eines 'scene graph'. Ich denke es gibt genug Überschneidungen in der Datennutzung, um eine zentralisierte Szenenverwaltung (in der Applikation) zu rechtfertigen.
Die klassische Argumentation ist natürlich, daß die Applikation auf Szenenebene idR mehr 'weiß', und die 'besseren' Optimierungen vornehmen kann. Obwohl, Ausnahmen bestätigen wohl die Regel.
Und zu OIP: was wäre wenn ich in einem CAD-Programm ein transparentes Modell in der 'von vorne'-Ansicht zeichne (einer der vier üblichen Viewports), und dadurch genau weiß, daß das Objekt dort immer aus der gleichen Richtung zu sehen ist? Muß dann der Treiber wirklich volles OIP garantieren, oder ist es dann nicht doch einfacher, wenn die Applikation ihr Wissen einsetzen kann?


Zum restlichen (nicht mehr zitierten) sage ich uneingeschränkt "Ja, genau!" :)

[zeckensack]

Original geschrieben von Piffan
Und dann wäre da noch die Kooperation zwischen Spielefirmen und den Chipherstellern, die auch für Widerstand sorgt...da wird das Fummeln auf niedrigem Niveau bzw. eng an der Hardware gern als Argument für die Überlegenheit der Treiber/Hardware gewisser Firmen verwendet...der Kunde hat ja keine Ahnung bzw. ihm es es egal, warum das Spiel X auf der Hardware Y besser läuft, er kauft halt die "bessere" Hardware. *eg* Das ist exakt der Grund, warum mich dieses Thema im Moment so mitreißt :D

Die 3DMark-Debatte(n) hier demonstrieren schön, daß man beim aktuellen System als Außenstehender die Schuldfrage schon garnicht mehr klären kann. Da kommt Razor daher und sagt sinngemäß "Das muß ja schiefgehen, weil da ist zu viel PS1.4 drin", und ja, irgendwie ist das auch richtig. Die Frage ist eben nur, wie weit trägt dieses Argument?

Dann komme ich und schreibe "PS1.4 reicht aus, also warum nicht?", und das ist wohl auch keine ganz verkehrte Einstellung.

Wenn es nur die eine Shader-Sprache gäbe, wo es dem Treiber obliegt das bestmögliche zu machen, dann wären solche fruchtlosen Streitereien überhaupt nicht nötig. Der schwarze Peter (wenn er denn verteilt werden müßte) läge dann immer beim IHV, niemand müßte sich unfair behandelt fühlen.

[Demirug]

Original geschrieben von zeckensack
Schön :)
Ich verdamme MS, weil sie mich immer mal wieder schwer enttäuschen, und gleichzeitig heftiges Kopfkratzen auslösen.
Normierung ist eine feine Sache, aber ich habe oft den Eindruck, daß die sich nicht die nötige Mühe geben, das 'richtige' zu tun. Man hebt sich dort anscheinend gerne Dinge für die nächste Version auf, was (Paranoia ahoi!) sicher auch ein günstiges Instrument für die nächste erwünschte Welle von 'Upgrades' ist. DX7 gibt es nicht für Windows 95 ... ;)

Was das aufheben für die nächste Version angeht habe ich da auch ein wenig die IHVs im Verdacht die einfach nicht rausrücken wollen was sie den nun als nächstest planen und ohne die mitarbeit der IHVs kann man leider nichts normieren.

Zu NWN: ich weiß warum du dieses Beispiel gewählt hast :D
Ich halte OpenGL für eine exzellent designte API, mir fällt ganz ehrlich nichts ein, was man an der grundlegenden Architektur ändern müßte. Natürlich fehlt auch hier die konsequente Durchdringung mit Hochsprachen. Das ist eine Feature-Frage, die mit dem nötigen Willen lösbar ist, dank des wohl oft verkannten Extension-Mechanismus müßte man dafür die API an sich nicht umwerfen.

ich habe NWN gewählt weil es das letzte gute Beispiel in einer lange Kette ist. Ich hätte auch ganz am Anfang beginnen könne als noch jede 3d-Karte sogar noch eine komplett eigene API hatte.

Über das Design einer API kann man sich sicher stundelang streiten aber ich habe mich auch lange gefragt warum es in DX keinen Extension Mechanismus gibt. Bis ich vor kurzem eine Antwort gefunden habe die mir plausibel erscheint. Wenn es für die IHVs keine möglichkeit gibt Extensions einzubauen müssen sie sich wenn sie ihrer Features unterstützt sehen wollen auf eine Norm einigen. Gibt man ihnen die Möglichkeit Extensions einzubauen nimmt man diesen Druck weg.

Das leuchtet auf den ersten Blick ein, auf den zweiten Blick frage ich mich aber ernsthaft, wie groß der Aufwand wohl gewesen wäre, die 'damals' limitierte Flexibilität hochsprachlich verfügbar zu machen. Ala Geforce 2-Techlevel:out.rgb=texture0.rgb*texture1.rgb+interpolated_color.alpha
out.alpha=1.0Wäre das wirklich so schwer gewesen?
Ich brauche tatsächlich mehr Code, wenn ich das gleiche 'low level' schreiben will.

Wenn ich mir wie gesagt die jetzige "Furcht" vor den Shaderhochsprachen anschaue wäre dieser wirklich gute Ansatz damals wohl nicht angenommen worden. Man wollte damals einfach das Low-Level Kontroll Fehling haben. Im Übrigen funktioniert das was du da oben geschrieben hast ganz gut. Da wir ja von einer eigenen Hochsprache aus unsere Shader erzeugen habe ich auch mal ein experimentelles DX7 Backend gebaut.

Ich bin ja was Shader angeht sogar langfristig für eine noch höhere Abstraktion. Eine Programmiersprache ist schön aber IMHO immer noch zu technisch. Ich würde unseren Designern lieber einen graphischen Shadereditor geben mit dem sie sich ihere Materialen einfach zusammenklicken können. So ähnlich wie das in Maya funktioniert für alle die Maya ein bischen kennen. Langfristig werden ich das wohl auch umsetzen.

Dann leuchte denen doch mal bitte ordentlich heim :D

Sinnlos das habe ich aufgegeben.

Ich weiß noch nicht genau wie ich jetzt argumentieren soll, aber ich bin eher gegen die Integration eines 'scene graph'. Ich denke es gibt genug Überschneidungen in der Datennutzung, um eine zentralisierte Szenenverwaltung (in der Applikation) zu rechtfertigen.
Die klassische Argumentation ist natürlich, daß die Applikation auf Szenenebene idR mehr 'weiß', und die 'besseren' Optimierungen vornehmen kann. Obwohl, Ausnahmen bestätigen wohl die Regel.
Und zu OIP: was wäre wenn ich in einem CAD-Programm ein transparentes Modell in der 'von vorne'-Ansicht zeichne (einer der vier üblichen Viewports), und dadurch genau weiß, daß das Objekt dort immer aus der gleichen Richtung zu sehen ist? Muß dann der Treiber wirklich volles OIP garantieren, oder ist es dann nicht doch einfacher, wenn die Applikation ihr Wissen einsetzen kann?

Ich will nicht unbedingt direkt einen Szenengraph mir schwebt da eher sowas wie eine Beschreibungssprache wie sie Renderman benutzt oder auch das MEL Dateiformat von Maya vor.

Die Applikation darf und soll auch nach wie vor ihr wissen einsetzten können aber sie soll sich dann nicht mehr um die Details der Darstellung kümmern müssen.