NV-Infomaterial zu CG

[seahawk]

http://www.cs.utexas.edu/users/billmark/pubs/cgpaper.pdf

Ist ganz interessant was NV da über CG erzählt.

[zeckensack]

Kernproblem:
In contrast, if the high-level language is the only interface to
the hardware then the compiler must be integrated into the driver.
This approach allows graphics architects to change the hardware
instruction set in the future. Also, by forcing the user to compile via
the driver, the system can guarantee that old applications will use
compiler updates included in new drivers. However, the application
developer loses the ability to guarantee that a particular pre-tested
version of the compiler will be used. Since optimizing compilers
are complex and frequently exhibit bugs at higher optimization
levels, we considered this issue to be significant. Similarly, if
the developer cannot control the compiler version, there is a risk
that a program’s use of non-virtualized resources could change and
trigger a compilation failure where there was none before.Paraphrasiert:
"We do not believe we'll be able to write a compiler you'd want to rely on, because that's so damn f*ckin' hard to do. Note that because of our weasling about, we willingly forfeit all benefits of runtime compiled high level languages: automatic use of improvements incorporated into new compiler versions, and accordingly, automatic optimum use of all runtime detected hardware features. Hell, as it stands now, there's really no reason why Cg couldn't be used in-house only. You actually don't need to ship it with applications, because we recommend you to use the compiler version you developed with anyway."

[zeckensack]

:schlag:
It would be possible to take the opposite approach to supporting
short vector hardware, by omitting short vector data types from the
language, and relying on the compiler to automatically combine
scalar operations to form vectorized assembly code [Larsen and
Amarasinghe 2000; Codeplay Corporation 2003]. This approach
requires sophisticated compiler technology to achieve acceptable
vectorization and obscures from the programmer the difference
between code that will run fast and code that will not. At best, this
fully automatic approach to vectorization can only hope to match
the performance of languages such as Cg that allow both manual
and automatic vectorization.

"Automatic vectorization is damn f*ckin' hard. So we chose to not give our compiler this ability right now. Instead, we encourage programmers to use explicit vector types, so they may continue to miss optimization benefits from simple compiler updates. There are optimization opportunities that a human brain may simply not catch, yet a machine may. You won't see any of these, if you opt for Cg.

Oh, my PR rep tells me that I need to denounce auto-vecting, to make our kindergarten compiler technology look better. Automatic vectorization stinks."

[zeckensack]

*eg*
Our remaining choice was to expose major architectural
differences as differences in language capabilities. To minimize the
impact on portability, we exposed the differences using a subsetting
mechanism. Each processor is defined by a profile that specifies
which subset of the full Cg specification is supported on that
processor.
"Profiles do not incorporate descriptions for instruction scheduling and register allocation rules. This way, Cg will never achieve optimum performance on any competitors' hardware, because we are NVIDIA, and we do not care."

[Demirug]

zeckensack, und was machen wir in diesem Zusammenhang mit OpenGL 2.0?

Dort haben wird doch genau das gleiche Problem und ich glaube nicht das die anderen IHVs (gerade die kleinen) dort nicht das gleiche Problem wie nVidia haben.

Deiner "Übersetzung" kann ich mich aber nicht in allen Punkte anschliessen. Ich lesse das zuerst mal nur als eine Gegenüberstellung der Vor und Nachteile eines Compilers als Teil des Treibers.

IMHO hat hierbei das zwei Stufen Prinzip von Cg (Hochsprache -> Bytecode -> Interner Chipcode) schon seine Vorteilen. Das Übersetzten von Bytecode in den Internen Chipcode sollte sehr zuverlässig und sicher machbar sein. Der Knackpunkt ist ja die Hochsprache. Wenn man neben dem Shadercode als Hochsprache entweder eine sicher lauffähige Bytecode variante oder einen Compiler mit dem es definitive geht hat befindet man sich auf einem sicheren Boden. Man kann dann einen eventuel neureren Compiler zur Laufzeit benutzten und wenn das ganze fehlschlägt auf den sicheren Boden zurück gehen. Gegen Compilerfehler die "nur" fehlerhafte Shader erzeugen aber den Compiler nicht zum abbruch bewegen kann man so natürlich automatisch nichts machen aber eine option nicht den aktuellen Compiler zu benutzten bringt auch hier das Spiel zurück auf den sicheren Boden.

[Demirug]

Original geschrieben von zeckensack
*eg*

"Profiles do not incorporate descriptions for instruction scheduling and register allocation rules. This way, Cg will never achieve optimum performance on any competitors' hardware, because we are NVIDIA, and we do not care."

Ja die anderen IHVs sollen sich eben selber ein Backend schreiben oder eben gleich einen Syntaxcompatiblen compiler. :D

Woher soll nv auch im Detail wissen wie man am besten auf die Chips der Konkurrenz optimiert?

[zeckensack]

Original geschrieben von Demirug
Ja die anderen IHVs sollen sich eben selber ein Backend schreiben oder eben gleich einen Syntaxcompatiblen compiler. :D

Woher soll nv auch im Detail wissen wie man am besten auf die Chips der Konkurrenz optimiert? Ein Profil zu schreiben wäre wohl einfacher gewesen ;)
Dem Cg-Compiler die Möglichkeit zu unterschiedlichem Scheduling zu geben, wäre IMO auch für gewisse NV-Hardware (NV2x vs NV30) vorteilhaft gewesen.

Handfest ist das nicht, aber ich habe ein keiner Stelle in diesem PDF etwas dazu gelesen. Ich habe auch noch mal nach Reo(rder), order, Schedule, Arrange, Shuffle gesucht, und diese Begriffe nicht im gewünschten Kontext gefunden.

So, und jetzt nochmal (ernsthaft interessiert) zu meinem ersten Snippet:
Wozu soll Cg überhaupt mit der Applikation ausgeliefert werden, wenn 'statische' Compilerversionen als Feature, statt als Designfehler angepriesen werden?

Fehler im Compiler sind ja nicht mein Problem, darum haben sich die Herren Compiler-Entwickler zu kümmern. Wenn dagegen ein Shader so verbuggt ist, daß er nur mit einem identisch verbuggten Compiler quasi zufällig ein brauchbares Ergebnis liefert, dann ist das wiederum nicht NV's Problem. Spiele werden ja sowieso desöfteren gepatcht :D
Die Zuteilung von Zuständigkeit und Verantwortung gefällt mir nicht, und ist IMO nur vorgeschoben.

[nggalai]

LOL

Geil, Z-Bag. Aber ein kleiner Fehler:
Original geschrieben von zeckensack
"Automatic vectorization is damn f*ckin' hard. So we chose to not give our compiler this ability right now. Instead, we encourage programmers to use explicit vector types, so they may continue to miss optimization benefits from simple compiler updates. There are optimization opportunities that a human brain may simply not catch, yet a machine may. You won't see any of these, if you opt for Cg.

Oh, my PR rep tells me that I need to denounce auto-vecting, to make our kindergarten compiler technology look better. Automatic vectorization stinks." Stimmt so nicht:
It would be possible to take the opposite approach to supporting
short vector hardware, by omitting short vector data types from the
language, and relying on the compiler to automatically combine
scalar operations to form vectorized assembly code [Larsen and
Amarasinghe 2000; Codeplay Corporation 2003]. This approach
requires sophisticated compiler technology to achieve acceptable
vectorization and obscures from the programmer the difference
between code that will run fast and code that will not. At best, this
fully automatic approach to vectorization can only hope to match
the performance of languages such as Cg that allow both manual
and automatic vectorization.
"Voll-automatisierte Vektorisierung im Treiber ist aus Gründen XYZ weniger toll, aber mit Cg kann man sowohl als auch machen, in performance-kritischen Situationen also immernoch problemlos von Hand nachhelfen. Automatic Vectorization wird aber unterstützt."

93,
-Sascha.rb

[zeckensack]

Original geschrieben von Demirug
zeckensack, und was machen wir in diesem Zusammenhang mit OpenGL 2.0?

Dort haben wird doch genau das gleiche Problem und ich glaube nicht das die anderen IHVs (gerade die kleinen) dort nicht das gleiche Problem wie nVidia haben. Selbst entwickeln, lizensieren, kaufen, was auch immer. Hauptsache nach vorn blicken.
Deiner "Übersetzung" kann ich mich aber nicht in allen Punkte anschliessen. Ich lesse das zuerst mal nur als eine Gegenüberstellung der Vor und Nachteile eines Compilers als Teil des Treibers.Ich bin mittlerweile nach wirklich gründlichem Überlegen ein entschlossener Verfechter von 'Runtime'-Compilern aus Hochsprachen. Und zwar aus Gründen, die Cg explizit nicht bietet. In der Tat spielt es mit Cg nun überhaupt keine Rolle, ob ich die Hochsprache 'runtime' kompiliere, oder so wie gehabt Assembler-Shader schreibe (wozu man natürlich auch Tools benutzen kann, siehe NVparse). Thema verfehlt, setzen, sechs.
IMHO hat hierbei das zwei Stufen Prinzip von Cg (Hochsprache -> Bytecode -> Interner Chipcode) schon seine Vorteilen. Das Übersetzten von Bytecode in den Internen Chipcode sollte sehr zuverlässig und sicher machbar sein. Der Knackpunkt ist ja die Hochsprache. Wenn man neben dem Shadercode als Hochsprache entweder eine sicher lauffähige Bytecode variante oder einen Compiler mit dem es definitive geht hat befindet man sich auf einem sicheren Boden.Ack. Ich sehe nur keinen konzeptionellen Unterschied zwischen Bytecode und Assembler. Bleibt noch der Compiler.
Man kann dann einen eventuel neureren Compiler zur Laufzeit benutzten und wenn das ganze fehlschlägt auf den sicheren Boden zurück gehen. Gegen Compilerfehler die "nur" fehlerhafte Shader erzeugen aber den Compiler nicht zum abbruch bewegen kann man so natürlich automatisch nichts machen aber eine option nicht den aktuellen Compiler zu benutzten bringt auch hier das Spiel zurück auf den sicheren Boden.Also was nun? Ist es denn machbar, auf dem gleichen System parallel einen 'aktuellen', und einen 'altbekannten, getesteten' Cg-Compiler zu haben? Ich schätze, wenn, dann durch eine eigens mitgebrachte DLL, die diejenige im System-Verzeichnis brachliegen lässt.

Wenn ja, siehe oben, dann gibt es keinen Bedarf für eine Cg-Runtime. Wenn ich auf eine alte Version zurückfallen will, dann brauche ich keinen aktuellen Compiler zu haben. Und Fehler im kompilierten Shader sind durch die Applikation nicht feststellbar, also will ich entweder, und falle immer zurück, oder ich nehme halt das neueste, in der Hoffnung daß es nicht kaputt ist. In keinem Fall würde es irgendwas ändern.

Es gibt übrigens durchaus Linux-Distris, die GCC 2.95.3 ausliefern, weil sich der (modifizierte) Kernel des Anbieters nicht mit GCC 3.3 kompilieren lässt. Gleiches Problem: läuft garantiert, aber suboptimale Performance. Bringt mir nix den Kernel neu zu kompilieren, weil in der Form ist er ja schon vom Hersteller geliefert worden.

edit: wobei Linux wohl kein gutes Beispiel ist, weil der User hier ja wenigstens noch Kernelparameter ändern kann.

[Demirug]

Original geschrieben von zeckensack
Ein Profil zu schreiben wäre wohl einfacher gewesen ;)
Dem Cg-Compiler die Möglichkeit zu unterschiedlichem Scheduling zu geben, wäre IMO auch für gewisse NV-Hardware (NV2x vs NV30) vorteilhaft gewesen.

Backend = Profil

Handfest ist das nicht, aber ich habe ein keiner Stelle in diesem PDF etwas dazu gelesen. Ich habe auch noch mal nach Reo(rder), order, Schedule, Arrange, Shuffle gesucht, und diese Begriffe nicht im gewünschten Kontext gefunden.

Dazu stand glaube ich mal was in dem Readme zum Cg-Sourcecode.

So, und jetzt nochmal (ernsthaft interessiert) zu meinem ersten Snippet:
Wozu soll Cg überhaupt mit der Applikation ausgeliefert werden, wenn 'statische' Compilerversionen als Feature, statt als Designfehler angepriesen werden?

Fehler im Compiler sind ja nicht mein Problem, darum haben sich die Herren Compiler-Entwickler zu kümmern. Wenn dagegen ein Shader so verbuggt ist, daß er nur mit einem identisch verbuggten Compiler quasi zufällig ein brauchbares Ergebnis liefert, dann ist das wiederum nicht NV's Problem. Spiele werden ja sowieso desöfteren gepatcht :D
Die Zuteilung von Zuständigkeit und Verantwortung gefällt mir nicht, und ist IMO nur vorgeschoben.

Fehler im Compiler sind leider schon dein Problem den dein Kunde kauft ein Produkt von dir und wenn dieses Produkt nicht richtig läuft dann bist erst mal du als Hersteller der Dumme auch wenn eigentlich eine Komponeten mist baut welche gar nicht von dir ist. Ich kenne das leider aus eigener schmerzvoller Erfahrung.

Versuch mal einem DAU zu erklären das ein Spiel aufgrund seiner Grafikkarte nicht läuft welche doch bei seinen anderen Spielen keine Probleme macht.

Aber zurück zum Ausgangspunkt. Was heist Cg mit ausliefern? Man hat hier ja primär zwei Möglichkeiten:

1. Als Applikationsgebundene Komponeten, Die DLLs in ein Verzeichniss welches nur die Applikation was nageht.

Vorteil: Man kann sicher sein das der Compiler alle Shader auch wirklich richtig umsetzt

Nachteil: nv kann den Compiler noch so sehr verbessern man hat nichts davon.

2. Als gemeinsame Komponente. Die DLLs in ein allgemeines verzeichniss:

Vorteil: Compilerverbesserungen bringen auch "Altanwendungen" etwas.

Nachteil: Baut der compiler Schrott dann hat man ein echtes Problem wenn deswegen Altanwendungen nicht mehr laufen (aka DLL-HELL).

Man kann sich den ganzen Hickhack natürlich auch sparen und gleich nur fertig compilierte Shader mit ausliefern und wenn es neue Grafikkartenchips gibt bei Bedarf eben noch ein paar neue Dateien mit den passenden Shadern nachliefern (patchen).

Wie man es aber macht ist es irgendwie blöd weil man sich immer irgendwelche Nachteile einhandelt. Bei OpenGL 2.0 bekommt man die Wahl mehr oder minder abgenommen und die Nachteile die man in kauf nehmen muss vorgeschrieben. Ob das nun besser ist soll jeder für sich selbst entscheiden.

Da mir keiner der oben aufgeführten Wege wirklich gefallen hat habe ich mir eine eigene Lösung entwickelt welche die Vorteile soweit wie möglich vereint und die Nachteile ausschaltet.

1. Die Engine selbst arbeitet nur mit Vorkomplierten Shadern/Effekten. Pro Chip(Familie) gibt es dann eine entsprechende Datei zusätzlich auch noch mehr oder minder Chipneutrale Dateien.

2. Das Spiel/Engine wird mit einem Tool ausgeliefert welches es erlaubt aus einer Hochsprachenbeschreibung neue Effektdateien zu erzeugen. Dieses Tool erlaubt die Verwaltung von mehreren Compilerversionen (auch von unterschiedlichen Herstellern). Damit kann sich dann bei bedarf oder wenn es einen neuen Compiler gibt neue Shaderdateien kontrolliert erzeugen. Der von mir angesprochene DAU wird dazu natürlich nicht in der Lage sein aber der dieser ist ja in der Regel auch nicht so FPS hungrig.

[Demirug]

Original geschrieben von zeckensack
Selbst entwickeln, lizensieren, kaufen, was auch immer. Hauptsache nach vorn blicken.

Und wie lössen diese Vorschläge das Problem ???

Ich bin mittlerweile nach wirklich gründlichem Überlegen ein entschlossener Verfechter von 'Runtime'-Compilern aus Hochsprachen. Und zwar aus Gründen, die Cg explizit nicht bietet. In der Tat spielt es mit Cg nun überhaupt keine Rolle, ob ich die Hochsprache 'runtime' kompiliere, oder so wie gehabt Assembler-Shader schreibe (wozu man natürlich auch Tools benutzen kann, siehe NVparse). Thema verfehlt, setzen, sechs.

Könntest du mir bitte genauer erklären welche Gründe du meinst? Ich habe da irgendwo den Faden verloren.

Ack. Ich sehe nur keinen konzeptionellen Unterschied zwischen Bytecode und Assembler. Bleibt noch der Compiler.

Ich schon wenn auch nur einen kleinen. Assemblercode ist direkt von einer CPU/GPU ausfürbar. Für Bytecode braucht man immer noch einen Compiler.

Also was nun? Ist es denn machbar, auf dem gleichen System parallel einen 'aktuellen', und einen 'altbekannten, getesteten' Cg-Compiler zu haben? Ich schätze, wenn, dann durch eine eigens mitgebrachte DLL, die diejenige im System-Verzeichnis brachliegen lässt.

Wenn ja, siehe oben, dann gibt es keinen Bedarf für eine Cg-Runtime. Wenn ich auf eine alte Version zurückfallen will, dann brauche ich keinen aktuellen Compiler zu haben. Und Fehler im kompilierten Shader sind durch die Applikation nicht feststellbar, also will ich entweder, und falle immer zurück, oder ich nehme halt das neueste, in der Hoffnung daß es nicht kaputt ist. In keinem Fall würde es irgendwas ändern.

Klar kann man mehrer Versionen haben. Erfodert allerdings etwas Erfahrung mit dem DLL System von Windows. Fehler die zu falschen Anzeigen führen sind nur sehr schwer feststellbar. Theoretisch aber durchaus möglich. Aber Fehler die zum Abbruch des Compilers ohne ergebniss führen kann man so durchaus umgehen.

Es gibt übrigens durchaus Linux-Distris, die GCC 2.95.3 ausliefern, weil sich der (modifizierte) Kernel des Anbieters nicht mit GCC 3.3 kompilieren lässt. Gleiches Problem: läuft garantiert, aber suboptimale Performance. Bringt mir nix den Kernel neu zu kompilieren, weil in der Form ist er ja schon vom Hersteller geliefert worden.

edit: wobei Linux wohl kein gutes Beispiel ist, weil der User hier ja wenigstens noch Kernelparameter ändern kann.

Wenn es aber irgendwann mal einen neuen GCC gibt der auch diesen Kernel wieder kompilieren kann hat man wieder die Performances. Und genau darauf will ich ja hinaus. Ein sicherer Hafen mit der Option für mögliche Performancesteigerungen.

[zeckensack]

Original geschrieben von Demirug
Backend = Profil

Dazu stand glaube ich mal was in dem Readme zum Cg-Sourcecode.Ah so :-)
Den Quellcode im Bezug auf Möglichkeiten der Profile muß ich mir dann nochmal anschauen, bei Bedarf nehme ich diesen Punkt dann zurück.

Fehler im Compiler sind leider schon dein Problem den dein Kunde kauft ein Produkt von dir und wenn dieses Produkt nicht richtig läuft dann bist erst mal du als Hersteller der Dumme auch wenn eigentlich eine Komponeten mist baut welche gar nicht von dir ist. Ich kenne das leider aus eigener schmerzvoller Erfahrung.Ich kenne das eigentlich nur so:
if (problem)
{
if (graphics_vendor==ati) blame(ati);
else
if (graphics_vendor==nv)
{
if (mobo_vendor==ecs) blame(ecs);
else
if (cpu_vendor==amd) blame(amd);
else
blame(nv);
}
else
blame(graphics_vendor);
}
Versuch mal einem DAU zu erklären das ein Spiel aufgrund seiner Grafikkarte nicht läuft welche doch bei seinen anderen Spielen keine Probleme macht.Hmmm, Treiberupdate? Ich kann mir schon vorstellen daß es da harte Nüsse gibt. Aber ich habe buchstäblich hunderte Readmes gelesen, in denen ausdrücklich drinsteht, daß man bei Problemen bitte als aller erstes die Treiber aktualisieren soll. Heutzutage steht das auch meistens direkt im Support-Abschnitt, strategisch plaziert vor den Kontaktaddressen und Telefonnummern :D
Aber zurück zum Ausgangspunkt. Was heist Cg mit ausliefern? Man hat hier ja primär zwei Möglichkeiten:

1. Als Applikationsgebundene Komponeten, Die DLLs in ein Verzeichniss welches nur die Applikation was nageht.

Vorteil: Man kann sicher sein das der Compiler alle Shader auch wirklich richtig umsetzt

Nachteil: nv kann den Compiler noch so sehr verbessern man hat nichts davon.In diesem Fall wäre es sinnvoller, gleich in-house zu kompilieren - es sei denn die fertigen Shaderkompilate belegen abzüglich des Quellcodes deutlich mehr Platz als die Cg-Runtime :|

Was ich oben nicht erwähnt habe: ich habe nichts dagegen, daß NV einen Shader-Compiler herausgibt. Aber er wird nunmal als Runtime-Lösung beworben.
2. Als gemeinsame Komponente. Die DLLs in ein allgemeines verzeichniss:

Vorteil: Compilerverbesserungen bringen auch "Altanwendungen" etwas.

Nachteil: Baut der compiler Schrott dann hat man ein echtes Problem wenn deswegen Altanwendungen nicht mehr laufen (aka DLL-HELL).Die Möglichkeit besteht, aber nur ein lausiger Compiler-Entwickler würde das als Argument verwenden. Java 1.4 zB ist mit Sicherheit viel schwieriger zu bändigen als Cg-Shader. Und trotzdem funktioniert's. Bugs werden durch neue Runtimes gefixt, wenn man sie findet, der ganz normale Gang eben.
Man kann sich den ganzen Hickhack natürlich auch sparen und gleich nur fertig compilierte Shader mit ausliefern und wenn es neue Grafikkartenchips gibt bei Bedarf eben noch ein paar neue Dateien mit den passenden Shadern nachliefern (patchen).Exakt, dann braucht man auch keine Runtime.
Wie man es aber macht ist es irgendwie blödJa, ist es! =)
weil man sich immer irgendwelche Nachteile einhandelt. Bei OpenGL 2.0 bekommt man die Wahl mehr oder minder abgenommen und die Nachteile die man in kauf nehmen muss vorgeschrieben. Ob das nun besser ist soll jeder für sich selbst entscheiden.Ich habe die Hoffnung, daß je mehr und je eher Entwickler auf eine Schnittstelle gezwungen werden, desto besser ist es für die Entwicklung (Bugfixes, Optimierungen) eben dieser Schnittstelle. Schau mal was innerhalb von ein paar Jahren aus Direct3D 5 geworden ist :D
Da mir keiner der oben aufgeführten Wege wirklich gefallen hat habe ich mir eine eigene Lösung entwickelt welche die Vorteile soweit wie möglich vereint und die Nachteile ausschaltet.

1. Die Engine selbst arbeitet nur mit Vorkomplierten Shadern/Effekten. Pro Chip(Familie) gibt es dann eine entsprechende Datei zusätzlich auch noch mehr oder minder Chipneutrale Dateien.

2. Das Spiel/Engine wird mit einem Tool ausgeliefert welches es erlaubt aus einer Hochsprachenbeschreibung neue Effektdateien zu erzeugen. Dieses Tool erlaubt die Verwaltung von mehreren Compilerversionen (auch von unterschiedlichen Herstellern). Damit kann sich dann bei bedarf oder wenn es einen neuen Compiler gibt neue Shaderdateien kontrolliert erzeugen. Der von mir angesprochene DAU wird dazu natürlich nicht in der Lage sein aber der dieser ist ja in der Regel auch nicht so FPS hungrig. Ausgezeichnet :)

[zeckensack]

Original geschrieben von Demirug
Und wie lössen diese Vorschläge das Problem ???

Könntest du mir bitte genauer erklären welche Gründe du meinst? Ich habe da irgendwo den Faden verloren.*leiseseufz*
Einheitliche Schnittstellen ohne Kompromisse. Zeitloser Shadercode, der nicht mehr im Jahresrhytmus veraltet, sondern ungefähr so lange haltbar ist wie C. Zentralisierte Updates bei dem, den es interessiert, und der dafür auch zuständig ist.

Nicht zu vergessen:
Original geschrieben von Demirug
Vorteil: Compilerverbesserungen bringen auch "Altanwendungen" etwas.

Und natürlich kann es nicht schaden, das Know-How jetzt aufzubauen, wo Shader-HW noch vergleichsweise simpel ist.



Ich schon wenn auch nur einen kleinen. Assemblercode ist direkt von einer CPU/GPU ausfürbar. Für Bytecode braucht man immer noch einen Compiler.Da hast du auch wieder recht. Was ich meinte, war Bytecode vs Assembler-Quellcode. Bytecode muß, wenn er gut sein soll, hinreichend viel Ausdruckskraft besitzen (=> Java). Wenn durch den Zwischenschritt auf Bytecode Optimierungen erschwert werden, dann bin ich dagegen.
Gängige Assembler sortieren Instruktionen nicht um, weil ihnen dafür die Logik fehlt. Beim eigentlichen Backend des Cg-Compilers, nämlich dem Assembler-Interface des Treibers, gilt offenbar das gleiche. Ein Bytecode als Zwischenschritt bringt nicht unbedingt eine neue Motivation, diesen Zustand zu ändern ;)

Klar kann man mehrer Versionen haben. Erfodert allerdings etwas Erfahrung mit dem DLL System von Windows. Fehler die zu falschen Anzeigen führen sind nur sehr schwer feststellbar. Theoretisch aber durchaus möglich. Aber Fehler die zum Abbruch des Compilers ohne ergebniss führen kann man so durchaus umgehen.*hust*
UT2k3, Readme
3.6 NVIDIA 40.41 Treiber
------------------------

NVIDIA 40.41 Treiber haben bekanntermaßen visuelle Mängel und Leistungs-
Probleme (Rucken) im Zusammenhang mit Unreal Tournament 2003. Da diese
Probleme im 30.82 Treiber nicht vorhanden sind, und spätere Treiber
das Problem behoben haben, bleiben Ihnen zwei Möglichkeiten, wenn Sie
momentan einen 40.41 Treiber verwenden:
1. Downgraden Sie Ihren 40.41 Treiber auf die ältere 30.82 Version, oder
2. installieren Sie einen neuen Treiber sobald er erhältlich ist.

Die neuesten NVIDIA Treiber können unter der folgenden URL gefunden werden:

http://www.nvidia.com/content/drivers/drivers.aspIst es wirklich nötig, deswegen auf irgendetwas zu verzichten?


Wenn es aber irgendwann mal einen neuen GCC gibt der auch diesen Kernel wieder kompilieren kann hat man wieder die Performances. Und genau darauf will ich ja hinaus. Ein sicherer Hafen mit der Option für mögliche Performancesteigerungen. Deine Lösung, die du oben umschrieben hast, gefällt mir auch gut. Nur hast eben dadurch du einen Mehraufwand, und wer weiß wieviele andere Leute sonst noch. Es ist IMO nicht deine Aufgabe, Versäumnisse deiner 'Dienstanbieter' (deren Kunde du in gewissem Sinne bist) auszugleichen. Die können das theoretisch effizienter, und für alle Entwickler gleichzeitig, sie müssen es nur wollen.

Wo kommen wir denn da hin, wenn jeder das Rad neu erfinden muß? "Unser neuer Taschenrechner kann jetzt auch den Sinus berechnen, Multiplikation ist aber fehlerhaft. Wir planen nicht, diese Modellserie zu reparieren oder auszutauschen. Bitte halten sie deswegen stets einen älteren in Reserve." :|

edit: So gesehen beim Pentium FDIV-Bug. Intel hat die Teile AFAIR auf Wunsch ausgetauscht, weil sie ganz klar dafür zuständig waren. Bei Software ist ein Austausch um Größenordnungen einfacher als bei Hardware. Ich verstehe nicht, warum du dich dagegen so sträubst???

[Demirug]

Zeckensack, OK ich denke das wir und auf einige Punkte einigen können:

- Shaderhochsprachen sind grundsätzlich eine gute Sache und zu unterstüzen.

- Hochrachencompiler haben leider die Tendenz mit einer neuen Version teilweise alten Sourcecode nicht mehr richtig zu verstehen.

- Hochsprachendefintionen lassen egal wie genau sie sind leider immer noch stellen die Interpretationen zulassen und es gibt auch immer wieder Dinge die man einfach bei der Definition übersehen hat.

Gehen wir damit konform?

AFAIK gibt es in der ganzen IT-Welt kein grösseres System (>= 10000 Benutzer) welches direkt mit Hochsprachensourcen arbeitet und bei einem Versionwechsel die Garantie hat das alle jemals programmierten Sourcen noch laufen werden. Wenn jemand so etwas kennt bitte melden.

Dagegen gibt es auf Bytecode Basis durchaus solche Systeme die garantieren das der einmal erzeuge Bytecode. Du hast ja schon Java als gutes Beispiel genannt und MS möchte das mit .net ja auch erreichen.

Aus dieser Sicht der Dinge empfinde ich es eben als sehr mutig diesen Schritt (direkter Einsatz von Hochsprachen) zu gehen. Es hat AFAIK bisher nicht funktioniert obwohl CPUs das Ziel waren also warum sollte es dann bei den komplexeren GPUs funktionieren?

Ich plädiere daher eben eher für Bytecode. Der DX Bytecode ist allerdings da nicht das Ideale weil man dort scheinbar den IHVs zu sehr entgegengekommen ist die eben keine aufwändigen Compiler in die Treiber bauen wollten und vorallem geht der Bytecode auch nicht über das hinaus was derzeit eben von den IHVs geplannt wurde (z.b. Keine Noise funktion verfügbar). Oder anders ausgedrückt. Es wurde keine standard biliothek definiert mit häufig gebrauchten höheren Funktionen. Das höchste der Gefühle ist da ein sinus welcher per Default mit einer Taylor Rheie berechnet wird aber der Chip darf diesen auch gegen eine eigene implementierung austauschen weil es dafür einen eigenen Opcode gibt. Der Bytecode müsste also noch so weit von tatsächlichen Chip entfernt sein das man definitive um einen Compiler im Treiber nicht herum kommt. Zudem hätte der Bytecode auch noch den Vorteil das dieser sich in der Regel schneller compilieren läst als Hochsprachenprogramme.

Das ich den faden verloren habe lag wohl daran das du hier das Thema aus dem anderen Thread wieder etwas aufgegriffen hast.

Ich stimme dir was den "Zeitloser Shadercode" angeht zu aber muss auch noch gleich dazu sagen das weder HLSL/CG noch OpenGL 2.0 diese Forderung erfüllen. Renderman shader erfüllen im Prinzip diese Forderung haben allerdings wieder das Problem das nicht jeder Renderer der Renderman shader beherscht auch immer jeden Shader versteht weil diese ja in einer Hochsprache koodiert sind.


Noch etwas zum Thema DAUs.

Der normale Anwender im weltweiten Durchschnitt neigt dazu zuerst denjenigen zu blamen desen Namen auf der Packung steht weil er oft gar nicht weiss welche Hardware er den nun im Rechner hat weil der Rechner komplett gekauft wurde. Aus diesem Grund wird auch ein Treiberupdate schwer. Ich musste mir schon Vorträge zu dem Thema anhören. Zum Beispiel warum es wichtig ist in ein vom Spiel erzeugtem Protokol so viele Hardware informationen wie nur möglich zu speichern weil der normale User gar nicht in der Lage ist diese in endlicher Zeit selbst zu finden. Das sind alles Dinge die man sich so gar nicht unbedingt vorstellen will aber leider der Realität entsprechen. In den USA ist diese Situation aber viel schlimmer als bei uns.

[Exxtreme]

Original geschrieben von Demirug

Noch etwas zum Thema DAUs.

Der normale Anwender im weltweiten Durchschnitt neigt dazu zuerst denjenigen zu blamen desen Namen auf der Packung steht weil er oft gar nicht weiss welche Hardware er den nun im Rechner hat weil der Rechner komplett gekauft wurde. Aus diesem Grund wird auch ein Treiberupdate schwer. Ich musste mir schon Vorträge zu dem Thema anhören. Zum Beispiel warum es wichtig ist in ein vom Spiel erzeugtem Protokol so viele Hardware informationen wie nur möglich zu speichern weil der normale User gar nicht in der Lage ist diese in endlicher Zeit selbst zu finden. Das sind alles Dinge die man sich so gar nicht unbedingt vorstellen will aber leider der Realität entsprechen. In den USA ist diese Situation aber viel schlimmer als bei uns.
Da gebe ich dir recht. Ich habe viele Bekannte, die zwar Tag und Nacht was zocken, Treiberupdates, Sicherheitsupdates etc. aber nicht einspielen weil sie nicht wissen, was man da machen muss.

[zeckensack]

Original geschrieben von nggalai
LOL

Geil, Z-Bag. Aber ein kleiner Fehler:
Stimmt so nicht:

"Voll-automatisierte Vektorisierung im Treiber ist aus Gründen XYZ weniger toll, aber mit Cg kann man sowohl als auch machen, in performance-kritischen Situationen also immernoch problemlos von Hand nachhelfen. Automatic Vectorization wird aber unterstützt."

93,
-Sascha.rb Jein ;)
Die Gründe XYZ sehen nun leider so aus (Interpretation in []):This approach
[is bad because it] requires sophisticated compiler technology to achieve acceptable
vectorization and obscures from the programmer the difference
between code that will run fast and code that will not.Die Interpretation ist nicht ganz eindeutig, aber IMO im Kontext haltbar. 'Obscures' ist negativ besetzt, was den gesamten Satz färbt. Im Gesamtkontext kann der erste Satzteil auch eigentlich nicht positiv gemeint sein, schließlich haben sie sich ja gegen 'sophisticated compiler technology' entschieden.

Was danach kommt, ist eine glatte Lüge:At best, this
fully automatic approach to vectorization can only hope to match
the performance of languages such as Cg that allow both manual
and automatic vectorization."At best" ist technisch betrachtet falsch. "Sophisticated compiler technology" kann theoretisch (und auch praktisch, ich habe vor das bei Gelegenheit zu bele (http://sourceforge.net/forum/forum.php?thread_id=882112&forum_id=167169)gen ...) jeden Vektorfall erkennen. Nun gilt die gleiche Theorie natürlich für den Cg-Compiler. Dann wäre diese Aussage natürlich glatt überflüssig.
Ich gehe davon aus, daß dieser Satz aus einem bestimmten Grund so da steht :naughty:

[Demirug]

zeckensack, ich glaube du vergisst hier etwas. Um bei einem Grafik chip den Vektor komplett auszunutzen muss man die Daten ja entsprechend zusammen kopieren. Ein mov kostet aber auch einen Slot und so könnte am ende das vorbreiten für eine Vektoroperation teurer sein wie das ganze mit getrennten Operationen durchzuführen.

3dlabs hat mit dem P10 wohl die beste Lösung für das Problem gefunden.

[zeckensack]

Original geschrieben von Demirug
Zeckensack, OK ich denke das wir und auf einige Punkte einigen können:

- Shaderhochsprachen sind grundsätzlich eine gute Sache und zu unterstüzen.

- Hochrachencompiler haben leider die Tendenz mit einer neuen Version teilweise alten Sourcecode nicht mehr richtig zu verstehen.

- Hochsprachendefintionen lassen egal wie genau sie sind leider immer noch stellen die Interpretationen zulassen und es gibt auch immer wieder Dinge die man einfach bei der Definition übersehen hat.

Gehen wir damit konform?Ja.

AFAIK gibt es in der ganzen IT-Welt kein grösseres System (>= 10000 Benutzer) welches direkt mit Hochsprachensourcen arbeitet und bei einem Versionwechsel die Garantie hat das alle jemals programmierten Sourcen noch laufen werden. Wenn jemand so etwas kennt bitte melden.Ich melde mich jedenfalls nicht ;)
Dagegen gibt es auf Bytecode Basis durchaus solche Systeme die garantieren das der einmal erzeuge Bytecode. Du hast ja schon Java als gutes Beispiel genannt und MS möchte das mit .net ja auch erreichen.Liegt das denn am Bytecode-Konzept?
Bytecode kann so ziemlich alles sein, theoretisch kann Bytecode auch einfach nur gestutzter (nicht mehr menschenlesbarer) Quellcode sein, der den ersten Typcheck-Durchlauf überstanden hat, in dem Namen und Operatoren durch kurze Codes erzetzt wurden, der aber anderweitig nicht geändert wurde. Auf der anderen Seite kann man fertige, optimierte x86-Programme auch als Bytecode verstehen, denn das sind sie: eine Folge von Bytes, die Instruktionen kodieren.
=> der Begriff ist mir irgendwie viel zu schwammig :-)

(wobei ich Bytecode als solchen nicht ablehne, aber ich will daß ein sauberes Konzept dahinter ist)
Aus dieser Sicht der Dinge empfinde ich es eben als sehr mutig diesen Schritt (direkter Einsatz von Hochsprachen) zu gehen. Es hat AFAIK bisher nicht funktioniert obwohl CPUs das Ziel waren also warum sollte es dann bei den komplexeren GPUs funktionieren?Ich sehe (noch) nicht, daß GPUs komplexer sind als CPUs. Der Befehlssatz ist viel kleiner, auch sind die aktuell zu bewältigenden Programme geradezu winzig. Fehler lassen sich IMO viel leichter eingrenzen.

Ich plädiere daher eben eher für Bytecode. Der DX Bytecode ist allerdings da nicht das Ideale weil man dort scheinbar den IHVs zu sehr entgegengekommen ist die eben keine aufwändigen Compiler in die Treiber bauen wollten und vorallem geht der Bytecode auch nicht über das hinaus was derzeit eben von den IHVs geplannt wurde (z.b. Keine Noise funktion verfügbar). Oder anders ausgedrückt. Es wurde keine standard biliothek definiert mit häufig gebrauchten höheren Funktionen. Das höchste der Gefühle ist da ein sinus welcher per Default mit einer Taylor Rheie berechnet wird aber der Chip darf diesen auch gegen eine eigene implementierung austauschen weil es dafür einen eigenen Opcode gibt. Der Bytecode müsste also noch so weit von tatsächlichen Chip entfernt sein das man definitive um einen Compiler im Treiber nicht herum kommt. Zudem hätte der Bytecode auch noch den Vorteil das dieser sich in der Regel schneller compilieren läst als Hochsprachenprogramme.Also Bytecode als sanfte Optimierung? Der Tokenizer/Parser wird dadurch natürlich einfacher. Hmmmm.
Das ich den faden verloren habe lag wohl daran das du hier das Thema aus dem anderen Thread wieder etwas aufgegriffen hast.Entschuldige, wenn dir das Thema lästig ist :D
Ich habe meine Meinung zum Cg-Whitepaper geäußert, wobei ich mir die Rosinen zuerst rausgepickt habe ;)
Ich stimme dir was den "Zeitloser Shadercode" angeht zu aber muss auch noch gleich dazu sagen das weder HLSL/CG noch OpenGL 2.0 diese Forderung erfüllen. Renderman shader erfüllen im Prinzip diese Forderung haben allerdings wieder das Problem das nicht jeder Renderer der Renderman shader beherscht auch immer jeden Shader versteht weil diese ja in einer Hochsprache koodiert sind.Dann gibt es wohl 'gute' und 'weniger gute' Renderman-Renderer. Ist Renderman deswegen ein schlechtes Konzept?
Ich will mich eigentlich nicht auf HLSL und GLslang im speziellen einlassen. Nur so weit: solange an und mit diesen Sprachen niemand (oder zu wenige) arbeiten, wird es kaum möglich sein, die Schwächen zu erkennen, und weiter vorwärts zu kommen. Software-Evolution kann eine feine Sache sein, nur wenn es niemanden interessiert, dann passiert auch nichts. Gäbe es Cg nicht, dann würde ich nicht hier sitzen und darüber schreiben :)

Noch etwas zum Thema DAUs.

Der normale Anwender im weltweiten Durchschnitt neigt dazu zuerst denjenigen zu blamen desen Namen auf der Packung steht weil er oft gar nicht weiss welche Hardware er den nun im Rechner hat weil der Rechner komplett gekauft wurde. Aus diesem Grund wird auch ein Treiberupdate schwer. Ich musste mir schon Vorträge zu dem Thema anhören. Zum Beispiel warum es wichtig ist in ein vom Spiel erzeugtem Protokol so viele Hardware informationen wie nur möglich zu speichern weil der normale User gar nicht in der Lage ist diese in endlicher Zeit selbst zu finden. Das sind alles Dinge die man sich so gar nicht unbedingt vorstellen will aber leider der Realität entsprechen. In den USA ist diese Situation aber viel schlimmer als bei uns. Traurig das zu hören. Komischerweise schaffen es diese Leute immer wieder, die CD richtig herum ins Laufwerk zu legen, und die Installation zu starten ?-)

[Demirug]

Original geschrieben von zeckensack
Liegt das denn am Bytecode-Konzept?

Bytecode kann so ziemlich alles sein, theoretisch kann Bytecode auch einfach nur gestutzter (nicht mehr menschenlesbarer) Quellcode sein, der den ersten Typcheck-Durchlauf überstanden hat, in dem Namen und Operatoren durch kurze Codes erzetzt wurden, der aber anderweitig nicht geändert wurde. Auf der anderen Seite kann man fertige, optimierte x86-Programme auch als Bytecode verstehen, denn das sind sie: eine Folge von Bytes, die Instruktionen kodieren.
=> der Begriff ist mir irgendwie viel zu schwammig :-)

OK der Begriff ist schwammig. Ich meine mit Bytecode etwa auf der ebene von MSIL. Im Bezug auf shader würde das bedeuten das zum Beispiel die Lokalen Variablennamen alle bereits durch nummern ersetzt wurden aber noch keine Zuweisung der einzelen Variablen auf interne Register erfolgt ist. Genauso sollten die eigentlichen Datentypen (Vector3, Matrix, RGBFarbe, usw) noch vorhanden sein allerdings auch nur als Verweiss.

Vom Java Bytecode kenne ich leider zu wenig um zu sagen wie viele Metadaten da noch enthalten sind.

(wobei ich Bytecode als solchen nicht ablehne, aber ich will daß ein sauberes Konzept dahinter ist)
Ich sehe (noch) nicht, daß GPUs komplexer sind als CPUs. Der Befehlssatz ist viel kleiner, auch sind die aktuell zu bewältigenden Programme geradezu winzig. Fehler lassen sich IMO viel leichter eingrenzen.

nun ja für GPUs gelten aber viel mehr regeln als für CPUs. Wenn mir zum Beispiel bei einer CPU die Register nicht mehr reichen weiche ich eben auf den Stack aus bei einer GPU habe ich da verloren. Gleiches Problem mit der Programmlänge und die ganzen anderen Kleinigkeiten. Das wird zwar IMHO im laufe der Zeit immer weniger ein Problem aber im Moment ist es eben noch vorhanden.

Also Bytecode als sanfte Optimierung? Der Tokenizer/Parser wird dadurch natürlich einfacher. Hmmmm.

Ich glaube wir verstehen uns. Eine genbau definierten Satz von einfachen Befehlen mit genügend Metadata im Hintergrund das auch noch optimierungen möglich sind. Auf der Bytecode ebene lässt sich eben alles viel genauer definieren als auf Hochsprachenebene. Wie gesagt empfehle ich hier gerne die MSIL-Norm als Lektüre.

Entschuldige, wenn dir das Thema lästig ist :D
Ich habe meine Meinung zum Cg-Whitepaper geäußert, wobei ich mir die Rosinen zuerst rausgepickt habe ;)

Nein mir ist das Thema nicht lästig ich hatte wir gesagt nur den Sprung vom einem zu anderen Thread nicht geschaft.

Dann gibt es wohl 'gute' und 'weniger gute' Renderman-Renderer. Ist Renderman deswegen ein schlechtes Konzept?
Ich will mich eigentlich nicht auf HLSL und GLslang im speziellen einlassen. Nur so weit: solange an und mit diesen Sprachen niemand (oder zu wenige) arbeiten, wird es kaum möglich sein, die Schwächen zu erkennen, und weiter vorwärts zu kommen. Software-Evolution kann eine feine Sache sein, nur wenn es niemanden interessiert, dann passiert auch nichts. Gäbe es Cg nicht, dann würde ich nicht hier sitzen und darüber schreiben :)

Nein, Renderman als Konzept ist gut nur leidet es eben auch etwas an dem "Hochsprachenproblem".

Natürlich muss man mal irgendwo anfangen nur habe ich für mich da schon eine bestimmte Sachen gefunden die mir nicht gefällt und deswegen einen anderen (leider sehr aufwendigen) Weg eingeschlagen.

Traurig das zu hören. Komischerweise schaffen es diese Leute immer wieder, die CD richtig herum ins Laufwerk zu legen, und die Installation zu starten ?-)

Ja das die Seite mit der Schrift nach oben kommt haben die meisten inzwischen verstanden und eine "normale" Installation bei der man nur ein paar mal auf weiter klicken muss geht auch noch solange sie automatisch startet. Besser wäre es allerdings wenn CD einlegen reicht.

[StefanV]

Original geschrieben von Demirug
Ja das die Seite mit der Schrift nach oben kommt haben die meisten inzwischen verstanden und eine "normale" Installation bei der man nur ein paar mal auf weiter klicken muss geht auch noch solange sie automatisch startet. Besser wäre es allerdings wenn CD einlegen reicht.

Genau hier ist ja das Paradoxon...

Früher, als es noch DOS gab, da haben viele Gamer sich zwangsläufig mit dem System auseinandersetzen _MÜSSEN_, dazu die ganzen Kommandos...
Ich denke, daß mit Windows95 ein Teufelskreis begonnen wurde -> man muß sich nicht mehr mit der HW, die im Rechner auseinandersetzen, wie man es zu DOS Zeiten machen musste...
Das Problem ist also eher, daß man überhauptnix mehr über den Rechner wissen muß, da man es nicht mehr braucht.

Ergo:
Zwingt man die Leute dazu, sich mit dem System zu befassen, dann bleibt der Anteil der DAUs gering, macht man das nicht, steigt der Anteil der DAUs.
Das Problem ist also, daß die Anzahl der DAUs steigt, da man sich, wie schon erwähnt, nicht mehr mit dem Rechner auseinandersetzen muss...

[Xmas]

Original geschrieben von Stefan Payne
Das Problem ist also eher, daß man überhauptnix mehr über den Rechner wissen muß, da man es nicht mehr braucht.
Sehe ich überhaupt nicht als Problem, sondern als Ziel. Wenn ich spielen will, sollte ich nicht wissen müssen wie ein Rechner funktioniert.

[Quasar]

Original geschrieben von Stefan Payne
Genau hier ist ja das Paradoxon...

Früher, als es noch DOS gab, da haben viele Gamer sich zwangsläufig mit dem System auseinandersetzen _MÜSSEN_, dazu die ganzen Kommandos...
Ich denke, daß mit Windows95 ein Teufelskreis begonnen wurde -> man muß sich nicht mehr mit der HW, die im Rechner auseinandersetzen, wie man es zu DOS Zeiten machen musste...
Das Problem ist also eher, daß man überhauptnix mehr über den Rechner wissen muß, da man es nicht mehr braucht.

Ergo:
Zwingt man die Leute dazu, sich mit dem System zu befassen, dann bleibt der Anteil der DAUs gering, macht man das nicht, steigt der Anteil der DAUs.
Das Problem ist also, daß die Anzahl der DAUs steigt, da man sich, wie schon erwähnt, nicht mehr mit dem Rechner auseinandersetzen muss...

Das ist doch kein Paradoxon.... wo ist denn da der Widerspruch oder die "Unmöglichkeit"?

Möchtest du allen Ernstes jedem Rentner, der im Altersheim einen Crash-Kurs "Internet" macht, erstmal ein halbes Jahr binäre Logik, Schaltungstechnik, C++ und ein bisschen Assembler beibringen???

Oder jedem Schüler, der im Schnitt schon Mühe hat, sich mit vollständigen und korrekten Sätzen zu artikulieren erstmal ein oder zwei Jahre CPU-Design beibringen?

Doch wohl nicht, oder?

Wenn dein kleiner Traum nämlich Realität wäre, würden du und ich uns garantiert keinen "richtigen" PC leisten können, weil er immer noch das Spielzeug der oberen Zehntausend oder eben eine internationale Business-Machine wäre.

Manchmal, wenn ich deine Postings lese....

[StefanV]

Original geschrieben von Xmas
Sehe ich überhaupt nicht als Problem, sondern als Ziel. Wenn ich spielen will, sollte ich nicht wissen müssen wie ein Rechner funktioniert.

Nunja, wenn etwas nicht funzt, dann ists ein Problem...

Nur, wenn ich nichts übers System wissen muss, um zu spielen, dann kaufe ich mir gleich 'ne Konsole (womit ich dich vermutlich mehrfach erschlagen könne ;))...

Nur gibts halt einige Games, die man nicht wirklich auf Konsolen spielt...

[zeckensack]

:|

Mal ganz frei zitiert, kann falsch sein:
Software engineering today is race between programmers creating ever bigger and better software, and the universe creating ever bigger and better idiots. So far, the universe is winning.

:schlag: <= ich steh' auf diesen Smilie!

[Xmas]

Original geschrieben von Stefan Payne
Nunja, wenn etwas nicht funzt, dann ists ein Problem...

Nur, wenn ich nichts übers System wissen muss, um zu spielen, dann kaufe ich mir gleich 'ne Konsole (womit ich dich vermutlich mehrfach erschlagen könne ;))...

Nur gibts halt einige Games, die man nicht wirklich auf Konsolen spielt...
Da lieferst du dir ja gerade das Gegenargument. Wieso sollte man ne Konsole kaufen wenn es das gewünschte Spiel nur für PC gibt? Und wieso sollte man sich mit Rechnern auskennen wenn man nur Spielen will?

Außerdem vergisst du auch, dass mit dem Komfort die Problembehebung ebenso einfacher wird.

[TheRealTentacle]

Stefan Payne hat recht (im Bezug auf Dos), nur hat er das richtige Beispiel falsch verwendet.

Früher war es möglich, sich tiefgreifend mit dem System zu befassen, und sehr einfach selbst Programme zu schreiben (siehe das DOS 6.0 mitgelieferte QBasic). Heute dagegen hat man selbst als nicht-DAU nimmer die Möglichkeit sich mit dem System zu beschäftigen. Windows macht alles für einen, selbst die Updates werden einem hinterhereschmissen, wenn man Windows XP benutzt, wodurch kein Anreiz mehr besteht sich überhaupt über den Rechner zu informieren. Leider sind diese Updates auch nicht das wahre, da sie eben nicht alle Probleme lösen. Der User denkt aber, dass alles richtig ist, und wundert sich über Abstürze.

Wenn man heute den PC spielerisch kennen lernen möchte, muss man Linux verwenden, was sich aber langsam ähnlich entwickelt.