Diskussion zum Artikel "CineFX (NV30) Inside"

[Leonidas]

Hier ist der Link. (http://www.3dcenter.org/artikel/cinefx/)


Dank vor allem an Demirug und die vielen Korrekturleser.




/edit 1.9.2003 01:40
Schreibfehler gefixt. Thx betareverse!

[LovesuckZ]

Viel Spass bei der englischen Übersetzung *eg*

Auf den ersten Blick sieht es schonmal sehr gut aus!

[betasilie]

Liest sich wie ein Krimi. :)

[Leonidas]

Original geschrieben von LovesuckZ
Viel Spass bei der englischen Übersetzung *eg*



Läuft schon.

[betasilie]

"Wie kann der NV30 von speziell für ihn programmierten Shadern profitieren?"

[betasilie]

Jeder der 4 Skalare (s,t,r,q) aus einer der 8 Textur(e)koordinaten, die Pixeltiefe (Z-Wert) und 1/W, welches für die perspekti(f/v)?ische Korrektur benötigt wird.

Edit:
Scheinbar schreibst Du immer Texturekoordinaten, dann muss das wohl so sein.

Edit2:
Mal schreibst Du "Textureanweisungen", mal "Texturanweisung". Du solltest den ganzen Artikel noch mal bzgl. aller Wörter mit "Textur(e)" untersuchen und dich dann für die richtige Form entscheiden. ;)

[Karümel]

Liest sich eigentlich sehr interessant, nur leider verstehe ich, aufgrund meines nicht vorhandenen Wissens, die Hälfte nicht :(

[betasilie]

Original geschrieben von Karümel
Liest sich eigentlich sehr interessant, nur leider verstehe ich, aufgrund meines nicht vorhandenen Wissens, die Hälfte nicht :(
Geht mir auch so. ;)

...


"In der Backend-Einheit werden die unterschiedlichem Datenpfade wieder synchronisiert,..."

"Nach erfolgter Synchronis(t)ation werden noch ..."

"den Shader Core gemeldet, damit dieser weiß, dass das Quad"

[MadManniMan]

Wo bleibt die Verlinkung auf der HP? "Nur" oben und rechts irritiert mich...

[Demirug]

Original geschrieben von MadManniMan
Wo bleibt die Verlinkung auf der HP? "Nur" oben und rechts irritiert mich...

Du bist zu ungeduldig

[MadManniMan]

Original geschrieben von Demirug
Du bist zu ungeduldig

...und du ein Meister des trockenen Humors :| ;)

[mapel110]

hui, ganz schön trocken. *waszutrinkenhol*

gibt zwar nen einblick, aber verstehen is nich. da fehlen dann doch die grundlagen. zumindest bei mir :(

ich wart da lieber mal nen paar ordentliche vergleichstests mit dem detonator50 ab.
solche diagramme kann ich eher deuten :)

[betasilie]

"Vergleicht man nun die bisher gewonnenen Erkenntnisse mit den realen Ergebnissen, welche ein NV30 bei Pixelshadertests erzielt ..."

"nVidia wird also sich dieser Probleme annehmen müssen..." - sollte besser "nVidia wird sich also dieser Probleme annehmen müssen..." heißen. ;)

[nggalai]

Hola,

Leute, denen das alles etwas zu kompliziert ist, sollten sich den Artikel ab "Leistungsbetrachtung" hier http://www.3dcenter.org/artikel/cinefx/index4.php genauer durchlesen. Da stehen die Schlussfolgerungen drin. Und die Diagramme mit den Rohleistungsvergleichen sind eigentlich sehr ansehlich. ;)

93,
-Sascha.rb

[betasilie]

"...da hierfür in Summe eine viel kleinere(r) Transistorenanzahl anzusetzen ist als für eine reine fp32 FPU und eine Int12 ALU.

[Demirug]

Original geschrieben von nggalai
Hola,

Leute, denen das alles etwas zu kompliziert ist, sollten sich den Artikel ab "Leistungsbetrachtung" hier http://www.3dcenter.org/artikel/cinefx/index4.php genauer durchlesen. Da stehen die Schlussfolgerungen drin. Und die Diagramme mit den Rohleistungsvergleichen sind eigentlich sehr ansehlich. ;)

93,
-Sascha.rb

Ja, wobei ich hier nocheinmal ausdrücklich darauf hinweisen möchte das die es sich bei den Rohleistungsvergleichen um die theoretisch mögliche Peak-Leistung bei den angegeben Fällen ohne spezielle Tricks handelt. Was davon in der Praxsis übrig bleibt bestimmen weitere Nebenbedingungen (und die sind vielfälltig) sowie der Treiber.

[betasilie]

"...auch in ungünstigen Situationen in der Lage, den R350 zu schlagen." ... Da kommt kein Komma hin.

"Die zum Vergleich eingefügte R300 Kurve zeigt, dass sogar dieser im Bereich um das 1:1 Verhältniss den NV35 ..."

"Um aber dennoch eine Aussage in diese Richtung zu treffen, so? gehen wir davon aus, dass alle neuen Chips der NV3X Serie..."

"ob man für diese Sache bereit ist, auf die Hälfte der Shaderleistung zu verzichten ..." Dort kommt auch kein Komma hin.

"Interessant dabei ist sicherlich noch die Frage, ob der Texturencache auch für Pixelshaderprogramme benutzt wird?" Da kommt ein Punkt hin, denn es handelt sich ja nicht um eine Frage. ;)

PS
Es fehlen an einigen Stellen Kommata und an einigen anderen sollten keine sein, inbesondere auf Seite 7, aber das würde jetzt wohl etwas zu weit führen. ;)

[MechWOLLIer]

Sicher ein klasse Artike( wie alle hier:D ), nur ich verstehe so ungefähr gar nichts

[Ailuros]

Ausgezeichneter Artikel. http://www.slackercentral.com/forums/images/smilies/nanner.gif

**edit:

Jetzt mal zum Thema und zukuenftigen Aspekten:

Trotz der durchaus dünnen Informationslage zu diesem Thema darf mit hoher Wahrscheinlichkeit angenommen werden, dass man Pixelshader 3.0 Konformität erreichen möchte. Im wesentlichen fehlt CineFX dafür die Möglichkeit, den Programmablauf bedingt durch aktuelle Rechenwerte (oder Konstanten) zu verändern.

In dem Patent wird der Pipeline nun die Fähigkeit zugesprochen, das einzelne Quads zu jeder Zeit die Pipeline verlassen können und durch neue ersetzt werden. Im Zusammenhang damit wird auch erwähnt, dass für unterschiedliche Quads unterschiedliche Programme oder unterschiedliche Teile des gleichen Programms gerade aktiv sein können. Es scheint nur noch eine Möglichkeit zu fehlen, an einer Stelle innerhalb der Pipeline die Programmzeiger gezielt zu verändern. Damit würden Sprünge innerhalb des Programms möglich.

Ein solcher bedingter Programmsprung stellt dabei die Grundlage für die von der Pixelshader 3.0 Spezifikation geforderten Möglichkeiten zur Schleifenbildung, Entscheidungen und Unterprogrammaufrufen dar. Da aber unter diesen Bedingungen nicht mehr gewährleistet werden kann, dass alle 4 Pixel eines Quads den gleichen Weg durch den Programmcode nehmen, wird man sich wohl von dem SIMD Ansatz lösen und für jeden Pixel eine unabhängige Pipeline benutzen.

Die technische Machbarkeit ist also durchaus gegeben, aber der Begriff CineFX wird in Verbindung mit dem NV40 wohl trotzdem nicht mehr genutzt werden. Die Grundtechnik hat aber nach unserer Meinung eine gute Chance, es in die nächste Runde zu schaffen.

Es ist wohl kein Geheimnis mehr dass technisch gesehen NV sehr gute Vorraussetzungen schom im NV3x fuer PS/VS3.0 hat. Ob sie es aber schaffen ohne grosse Aenderungen auch noch gleichzeitig alle Schwaechen bis jetzt zu korrigieren ist ein ganz anderes Kapitel.

Dabei gab es auch vor der NV35 Vorstellung die Verprechung dass alles wieder seinen richtigen Platz finden wird. Ich unterschaetze bei weitem NVIDIA nicht, eher das Gegenteil, aber wenn wir vom letzten Jahr etwas gelernt haben, ist es dass wir und NV deren Konkurrenz bei weitem nicht unterschaetzen sollten.

Man muesste ja nur naiv sein zu glauben dass die Konkurrenz nicht schon seit einiger Zeit auf solches oder um einiges ausfuehrliches Material verfuegt. Aus den Fehlern der anderen kann man auch lernen, wenn man nur rechtzeitig genug darauf kommt.

[betasilie]

Ganz netter Artikel und einiges habe ich sogar verstanden. :) Trotzdem ganz schön schwieriger Stoff.

[Xmas]

Original geschrieben von LovesuckZ
Viel Spass bei der englischen Übersetzung *eg*
Die ist zu 2/3 fertig. Demirug hätte aber schon etwas kürzer schreiben dürfen ;) *ächz*

[Cadmus]

Ich musste den Artikel zwar 3 Mal lesen, um ihn einigermaßen zu verstehen, aber dennoch danke und Respekt an Demirug.

[betasilie]

Original geschrieben von Leonidas
Dank vor allem an Demirug und die vielen Korrekturleser.
Also zu korrigieren ist da doch noch einiges, trotz der vielen Korrekturleser. ;)

[Benedikt]

Ahaaa, deshalb also die vielen "Andeutungen" in letzter Zeit speziell im Speku-Forum.... soso... :)

Aber echt, solche Artikel findet man im deutschsprachigen Web sonst wohl nirgendwo... (im englischen wohl auch nicht so bald)!
Einzigartige Seite, weiter so!

Grüße,

BW

[Quasar]

Jo, sehr guter Artikel!!

Ich bin schon sehr gespannt, was evtl. neue Treiber und TWIMTBP-Games richten werden.
Wenn die wirklich stark von nV gesponsort werden, könnte ich mir durchaus vorstellen, dass es da durchaus Ergebnisse diametral entgegengesetzt zu den TRAOD-Benches gibt.

[Demirug]

Original geschrieben von Quasar
Jo, sehr guter Artikel!!

Ich bin schon sehr gespannt, was evtl. neue Treiber und TWIMTBP-Games richten werden.
Wenn die wirklich stark von nV gesponsort werden, könnte ich mir durchaus vorstellen, dass es da durchaus Ergebnisse diametral entgegengesetzt zu den TRAOD-Benches gibt.

Merci beaucoup

Also ein totales umkippen würde ich bei DX Titeln nicht erwarten. Die Rohleistung ist ja wie gezeigt durchaus vorhanden aber nicht unbedingt einfach auf die Benchmarkstrasse zu bringen. Wenn nVidia die Shader "inhouse" baut sind sie ja scheinbar in der Lage ein konformes Ergebniss bei guter Leistung zu erreichen aber aufgrund der hohen komplexität des Pixelprozessors scheint man diesen Vorgang schwer automatisieren zu können.

Beim NV35 muss man ja den Shader auf zwei unterschiedliche Rechenwerke (Shader Core; Combiner) verteilen und das ganze auch noch Taktgenau syncroniseren. Und dabei mit den begrenzten Register Resourcen auskommen.

[Piffan]

Klasse! Durch diesen Artikel wird 3Dcenter zu internationalem Ruhm gelangen ;)....Auf die Idee mit dem Patentamt muß man erst mal kommen.

Habe natürlich nix verstanden.....Aber wenn ich das richtig peile, dann hatte NV ja eigentlich auch vor, den 3dMarkt (Hardware/Spiele) ziemlich monopolistisch zu betreiben. Wenn dann die Spieleentwickler alles für NV mundgerecht servieren würden, dann wäre die "alternative" Architektur ja auch kein Thema....Tja, Pech für NV, dass Ati mit dem R300 gerade noch zur rechten Zeit in die Parade fahren konnte.

Was war eigentlich mit dem Permedia 10? Sollte der nicht auch mal so universal wie eine CPU programmierbar sein? Wenn ich mich entsinne, wollte man da auch den Consumer- und Profimarkt bedienen......

[Benedikt]

Habe natürlich nix verstanden.....Aber wenn ich das richtig peile, dann hatte NV ja eigentlich auch vor, den 3dMarkt (Hardware/Spiele) ziemlich monopolistisch zu betreiben. Wenn dann die Spieleentwickler alles für NV mundgerecht servieren würden, dann wäre die "alternative" Architektur ja auch kein Thema....Tja, Pech für NV, dass Ati mit dem R300 gerade noch zur rechten Zeit in die Parade fahren konnte.

Tja, einige Frage, die mich "drücken":

Wusste NV rechtzeitig, was ATI da in Petto hat (die Entwicklung des NV30 geht ja wohl lange zurück), und viel mehr: Warum entschied man sich, mit einem Produkt, dass ja von der Rohleistung von vorn herein so schwächer ist, auf den Markt zu kommen?

Hatte man keine Wahl mehr, oder war's einfach ein gewaltiger "Griff ins Klo" von NV?

Könnte es auch sein, dass man sein eigenes Produkt überschätzt hat? Aber wenn ja, müsste es doch jedem Insider (hoffentlich sind das die bei NV relevanten Leute) auffallen, dass hier der Technologielevel nicht gegen den R300 ausreicht...

Viele Fragen, hoffentlich einige Antworten :) ...

Grüße,
BW

---edit: möchte nicht wissen, wieviele Köpfe da bei NV gerollt sind... :asshole:

[[dzp]Viper]

ein grüner daumen für den Artikel ! Hab zwar auch sogut wie nix verstanden aber es macht denoch lust auf mehr (nur is das so kompliziert ;D)

[Leonidas]

Original geschrieben von Leonidas
Hier ist der Link. (http://www.3dcenter.org/artikel/cinefx/)


Dank vor allem an Demirug und die vielen Korrekturleser.


/edit 1.9.2003 01:40
Schreibfehler gefixt. Thx betareverse!

[Ailuros]

Original geschrieben von Benedikt
Tja, einige Frage, die mich "drücken":

Wusste NV rechtzeitig, was ATI da in Petto hat (die Entwicklung des NV30 geht ja wohl lange zurück), und viel mehr: Warum entschied man sich, mit einem Produkt, dass ja von der Rohleistung von vorn herein so schwächer ist, auf den Markt zu kommen?

Hatte man keine Wahl mehr, oder war's einfach ein gewaltiger "Griff ins Klo" von NV?

Könnte es auch sein, dass man sein eigenes Produkt überschätzt hat? Aber wenn ja, müsste es doch jedem Insider (hoffentlich sind das die bei NV relevanten Leute) auffallen, dass hier der Technologielevel nicht gegen den R300 ausreicht...

Viele Fragen, hoffentlich einige Antworten :) ...

Grüße,
BW

---edit: möchte nicht wissen, wieviele Köpfe da bei NV gerollt sind... :asshole:

Soweit ich weiss gar keine Koepfe bis jetzt.

Meiner Ansicht nach war es eine Kombination von beiden; ergo ein Problem bei der Umsetzung vom Design ins Silizium und zur gleichen Zeit die Unterschaetzung der Konkurrenz.

Vor den low k 13nm Problemen bei TSMC, war NV30 tatsaechlich nur fuer 400/800MHz ausgelegt; danach kamen noch ein paar Transistoren dazu um auf 500MHz zu steigen und mit hoeherer Fuellrate kompensieren zu koennen. Dazu bezweifelt man auch dass es ATI nach dem R2xx/MSAA Flop es doch noch schafft innerhalb einer Generation Multisampling und immer noch mehr alles andere als ordered grid schaffen wird.

Ebenso wuerde ich genauso die Aufhaltungen vor 2002 fuer den NV2A chip auch noch mitberechnen und auch dass eine gute Anzahl von sehr erfahrenen Senior-engineers zurueckgezogen haben, kurz nach NV25 (gesunde Anzahl ist frei interpretierbar; grosse Erfahrung ueberreitet schneller Quantitaet ueberhaupt beim engineering).

Meine 2 cents
-AiL

[aths]

Ich finde den Artikel sehr gut. Endlich mal kein Tappen im Dunkeln mehr, sondern konkrete Aussagen. Schön, dass die Profis à la Demirug ihr Wissen nicht nur für sich behalten, sondern sich die Zeit nehmen, andere daran teilhaben zu lassen. Den Artikel habe ich förmlich aufgesogen (wenn auch nicht bis in letzte Detail verstanden.)

Imo sind Artikel, bei denen man nicht gleich alles versteht, besser als Artikel, die man komplett versteht aber weniger in die Tiefe gehen.

Erinnert sich noch wer an 3dconcept? Als 3D-Newbie habe ich fast nichts verstanden, doch brachten diese Technik-Artikel viel mehr, als das allgemeine Blabla der meisten anderen Seiten.

[Gast]

Argg:::


bitte bereinigt das erste Diagramm auf Seite 7. Der R300 und der NV30 wurden sowieso bereits im ersten Diagramm behandelt.

so wie das Diagramm mit Linien voll gekxxxx ist erkennt man gar nix mehr.


Danke.


Ansonsten ein klasse Artikel !!

[Gast]

Noch ein paar Fragen zu:

Auch CineFX II wurde bereits berücksichtigt, indem auf 2 Texturinstruktionen nach Möglichkeit mindestens immer eine Arithmetikinstruktion folgt. Von dieser Vorgehensweise profitiert aber auch so wie es scheint die CineFX I Einheit.

könnt Ihr dazu auch noch ein Diagramm machen mit der Fragestellung "Wie verhält sich die CineFX I Architektur bei für CineFX II optimierten Shadern". aus euren kurzen Erklärungen kann ich mir das leider nicht selbst zusammenreimen. Die CineFX I - Chips müssen dann doch eine Art "Mini-Loopback" ausführen um hier auf Leistung zu kommen.


Danke.

[ram]

Ich fand das sehr interessant!

Einige Unklarheiten sind aber noch geblieben.

Die maximale Anzahl von gleichzeitig in der Pipeline vorhandenen Quads ergibt sich, wenn man die Größe des Speichers für die Register (siehe Shader Backend) durch die durch einen Quad beanspruchte Speichermenge teilt. Die Speichermenge pro Quad berechnet sich aus der Anzahl und dem Datenformat der Temp-Register im Shader.

Bestimmt sich nicht die ingesamnt für Quads zur Verfügung stehende Speichermenge durch die # und das Format der Temp-Register? Also

Anzahl gespeichertert Quads = (Speicherplatz Total in Bits - (#Register * Bits/Register) ) / Speicherplatz pro Quad ?

Bevor die Quads einen zusätzlichen Durchlauf durch die Pipeline vornehmen können, ist es aus technischen Gründen notwendig, mindestens ein Leer-Quad durch die Pipeline zu schicken. Dies ist natürlich einen Schmälerung der effektiv nutzbaren Rohleistung.

Was ist der Grund für dieses Leer-Quad?

Bleibt nun noch die Frage, mit welchen Formaten die neue FPU zurecht kommt. Als Basis darf davon ausgegangen werden, dass die FPU für das fp32 Format (s23e8) ausgelegt ist. Die Mantisse von 23 Bit erfordert nun, dass die FPU über ein 23 Bit Addierer und Multipliziere verfügt. Erweitert man diese um 1 Bit auf 24 Bit, und erlaubt eine Auftrennen in der Mitte, erhält man zwei 12 Bit Addierer und Multipipizier. Genau das, was man braucht, um die beiden Integer-ALUs des NV30 zu ersetzten. Dieser Schritt erscheint logischer, als nur eine der beiden Integer-ALUs zu ersetzten, da hierfür in Summe eine viel kleinere Transistorenanzahl anzusetzen ist als für eine reine fp32 FPU und eine Int12 ALU.

Erscheint plausibel. Diese ALU müsste so gebaut sein, dass sie gleichzeitig MUL und ADD durchführen könnte. Die RC des NV30 konnten ja in gewissen Fällen 16 Operationen / Sekunde durchführen. Wie ginge das mit der NV35-Architektur? Oder gehört das nun auch zu jenen Fällen, wie der NV35 nicht mehr die NV30-FX-Performance erreicht?

[Demirug]

Original geschrieben von Gast
Noch ein paar Fragen zu:



könnt Ihr dazu auch noch ein Diagramm machen mit der Fragestellung "Wie verhält sich die CineFX I Architektur bei für CineFX II optimierten Shadern". aus euren kurzen Erklärungen kann ich mir das leider nicht selbst zusammenreimen. Die CineFX I - Chips müssen dann doch eine Art "Mini-Loopback" ausführen um hier auf Leistung zu kommen.


Danke.

CineFX I hat keine Probleme mit den CineFX II Optimierungen und verhält sich genauso wie sonst auch.

Loopbacks gibt es ja einige in der Architektur was ja mit ein Grund für die komplexität ist. Da haben wir den Loopback über den gesamte Pixelprozessor (aka Pipeline) der immer dann notwendig wird wenn man vom Ende daten zurück zum anfang bringen muss. Zudem haben dann die Teileinheiten wiederum loopbacks. Es hängt daher immer stark vom jeweiligen Shaderprogramm ab wann in welcher Einheit wie oft der Loopback benutzt werden kann. Der Treiber entscheidet dann beim umsetzten wie oft er dann wirklich benutzt wird.

[Demirug]

Original geschrieben von ram
Ich fand das sehr interessant!

Einige Unklarheiten sind aber noch geblieben.



Bestimmt sich nicht die ingesamnt für Quads zur Verfügung stehende Speichermenge durch die # und das Format der Temp-Register? Also

Anzahl gespeichertert Quads = (Speicherplatz Total in Bits - (#Register * Bits/Register) ) / Speicherplatz pro Quad ?

Ja, bei der Berechnug der Speichermenge habe ich das ganze etwas vereinfacht. Aber deiner Formel kann ich jetzt nicht so ganz folgen da sich der Speicherplatz pro Quad ja berechnet aus #Register * Bits/Register (* 4). Wobei es dann noch bestimmte Begrenzungen gibt wie man den Speicher dafür addressieren kann.

Der Speicher besteht aus 64Bit Zellen welche immer 4fach ausgelegt sind damit alle Pixel aus einem quad da auch reinpassen. Für das Integer und das FP16 Format braucht man eine solche Zelle für fp32 entsprechend zwei. Es kann nur Zellenweise addressiert werden und dann auch wenn ich es richtig Verstanden haben in bestimmten Granularitäten.


Was ist der Grund für dieses Leer-Quad?

Leer-Quads werden immer dann durch die Pipeline geschickt wenn Statusänderungen erforderlich sind. Der Leerquad zwischen den durchläufen dient dazu den Pipeline zuständ zu sichern und wieder entsprechend zurück zu setzten. Das ganze hängt mit der relative komplexen Sterung zusammen welche es erlaubt das mehr als ein Programm/Zustand gleichzeitig aktiv sein kann. nVidia gibt an das es dadurch möglich ist das sich Quads welche gleichzeitig durch die Pipeline laufen an unterschiedlichen Stellen im gleichen Programm befinden können. IMHO scheint das eine Vorbereitung für PS 3.0 zu sein und/oder man wollte/will damit den Texkill beschleunigen.

Erscheint plausibel. Diese ALU müsste so gebaut sein, dass sie gleichzeitig MUL und ADD durchführen könnte. Die RC des NV30 konnten ja in gewissen Fällen 16 Operationen / Sekunde durchführen. Wie ginge das mit der NV35-Architektur? Oder gehört das nun auch zu jenen Fällen, wie der NV35 nicht mehr die NV30-FX-Performance erreicht?

Meinst du jetzt nur die RCs oder den gesamten Pixelprozessor?

Was nun genau in den neuen FP-Combinern steckt ist schwer zu sagen und daher ist es auch fraglich ob sie wirklich alle PS 2.0 funktionen ausführen können. Es ist durchaus wahrscheinlich das bestimmte operationen nur vom Shadercore übernommen werden können. Mindestens 4 MULs und 4 ADDs (jeweils als 4 SIMD Einheit) müssen aber vorhanden sein. Aber das würde noch nicht für einen vollständigen Combiner reichen. Für einen solchen wären 8 MULs und 10 ADDs notwendig.

[ram]

Ja, bei der Berechnug der Speichermenge habe ich das ganze etwas vereinfacht. Aber deiner Formel kann ich jetzt nicht so ganz folgen da sich der Speicherplatz pro Quad ja berechnet aus #Register * Bits/Register (* 4). Wobei es dann noch bestimmte Begrenzungen gibt wie man den Speicher dafür addressieren kann. Der Speicher besteht aus 64Bit Zellen welche immer 4fach ausgelegt sind damit alle Pixel aus einem quad da auch reinpassen. Für das Integer und das FP16 Format braucht man eine solche Zelle für fp32 entsprechend zwei. Es kann nur Zellenweise addressiert werden und dann auch wenn ich es richtig Verstanden haben in bestimmten Granularitäten.

Speichert man pro Quad denn nur die temporären Register des für das Quad genutzten Shaders?


Leer-Quads werden immer dann durch die Pipeline geschickt wenn Statusänderungen erforderlich sind. Der Leerquad zwischen den durchläufen dient dazu den Pipeline zuständ zu sichern und wieder entsprechend zurück zu setzten. Das ganze hängt mit der relative komplexen Sterung zusammen welche es erlaubt das mehr als ein Programm/Zustand gleichzeitig aktiv sein kann. nVidia gibt an das es dadurch möglich ist das sich Quads welche gleichzeitig durch die Pipeline laufen an unterschiedlichen Stellen im gleichen Programm befinden können. IMHO scheint das eine Vorbereitung für PS 3.0 zu sein und/oder man wollte/will damit den Texkill beschleunigen.


4.23 cycles/pixel: 1 regs, 16 add instr, 1 mov instr
4.23 cycles/pixel: 2 regs, 16 add instr, 1 mov instr
4.66 cycles/pixel: 3 regs, 16 add instr, 1 mov instr
4.66 cycles/pixel: 4 regs, 16 add instr, 1 mov instr
6.08 cycles/pixel: 5 regs, 16 add instr, 1 mov instr
6.08 cycles/pixel: 6 regs, 16 add instr, 1 mov instr
8.52 cycles/pixel: 8 regs, 16 add instr, 1 mov instr
13.67 cycles/pixel: 10 regs, 16 add instr, 1 mov instr
14.36 cycles/pixel: 12 regs, 16 add instr, 1 mov instr
19.74 cycles/pixel: 14 regs, 16 add instr, 1 mov instr
20.64 cycles/pixel: 16 regs, 16 add instr, 1 mov instr

(aus http://www.beyond3d.com/forum/viewtopic.php?t=5150)

Mmm, dann gibt es bereits bei so einfachen Fällen wie 16 ADDS+1 MOV auf 3 FP32 Registern Statusänderungen, auch wenn immer derselbe Shader eingesetzt wird? Oder gibt es da noch einen anderen Grund, eben diese Adressierung? Interessanterweise ist der Gap von 4 auf 5 viel grösser als jener von 2 auf 3.

Meinst du jetzt nur die RCs oder den gesamten Pixelprozessor?

Insgesammt, PP mit RC.

[Demirug]

Original geschrieben von ram
Speichert man pro Quad denn nur die temporären Register des für das Quad genutzten Shaders?

Die Frage ist mir jetzt nicht ganz klar. Was ausser den Temp-Register soll den noch in diesem Speicher hinterlegt werden?



4.23 cycles/pixel: 1 regs, 16 add instr, 1 mov instr
4.23 cycles/pixel: 2 regs, 16 add instr, 1 mov instr
4.66 cycles/pixel: 3 regs, 16 add instr, 1 mov instr
4.66 cycles/pixel: 4 regs, 16 add instr, 1 mov instr
6.08 cycles/pixel: 5 regs, 16 add instr, 1 mov instr
6.08 cycles/pixel: 6 regs, 16 add instr, 1 mov instr
8.52 cycles/pixel: 8 regs, 16 add instr, 1 mov instr
13.67 cycles/pixel: 10 regs, 16 add instr, 1 mov instr
14.36 cycles/pixel: 12 regs, 16 add instr, 1 mov instr
19.74 cycles/pixel: 14 regs, 16 add instr, 1 mov instr
20.64 cycles/pixel: 16 regs, 16 add instr, 1 mov instr

(aus http://www.beyond3d.com/forum/viewtopic.php?t=5150)

Mmm, dann gibt es bereits bei so einfachen Fällen wie 16 ADDS+1 MOV auf 3 FP32 Registern Statusänderungen, auch wenn immer derselbe Shader eingesetzt wird? Oder gibt es da noch einen anderen Grund, eben diese Adressierung? Interessanterweise ist der Gap von 4 auf 5 viel grösser als jener von 2 auf 3.

Die Statusänderungen sind ja nicht verpflichtet aber der Leerquad wird aus Steuerungstechnischen gründen wohl auf jeden Fall gebraucht.

Ich kenne jetzt nicht genau das Shaderprogramm dafür aber ich kann mir durchaus vorstellen das hier beim NV30 die grosse Loopbackeinheit überhaupt nicht benutzt wird. Der Shadercore ist ja intern selbst loopbackfähig hat aber wohl nur ein Scratch-Register (x,y,z,w) zur verfügung. Möglicherweise kann man aber bestimmen auf welches der 3 Loopback Register dieses umkopiert wird.

Eine Erklärung für den Einbruch bei steigender Anzahl von Tempregister sehe ich im Gatekepper. Je mehr Tempregister gebraucht werden desto weniger Quads passen in den Speicher. Ich bin da aber noch am rechnen.

Insgesammt, PP mit RC.

Ja das waren dann wohl 8 Tex + 8 Int12 Operationen. Es sind ja im NV30 noch Integer Regcombiner vorhanden und ich gehe ja wie gesagt davon aus das sich der neue FP32 Combiner im NV35 in 2 Int12 Combiner spliten lässt womit dieser ja auch noch 8Tex + 8Int12 Ops beherscht aber eben nicht bei PS >= 2.0 weil es dort ja nur FP Formate gibt. Ob nun auch 8 FP16 Ops möglich sind ist natürlich eine andere Frage.

[ram]

Original geschrieben von Demirug
Die Frage ist mir jetzt nicht ganz klar. Was ausser den Temp-Register soll den noch in diesem Speicher hinterlegt werden? [...] Die Statusänderungen sind ja nicht verpflichtet aber der Leerquad wird aus Steuerungstechnischen gründen wohl auf jeden Fall gebraucht.[...]Eine Erklärung für den Einbruch bei steigender Anzahl von Tempregister sehe ich im Gatekepper. Je mehr Tempregister gebraucht werden desto weniger Quads passen in den Speicher. Ich bin da aber noch am rechnen.

Mir ist der Zusammenhang zwischen " #Quads in der Pipeline " mit den Registerspeicher und den Leer-Quads noch nicht klar. Werd mir das nochmals überlegen resp. das Patent mal lesen.

Wieso braucht es Leer-Quads, wenn auf einem 2x2-Quad 16 ADDs durchgeführt werden? Sinnvollerweise wird doch in so einem Fall an diesem Quad gearbeitet, bis es fertig ist, also dasselbe Quad gleich 16x geloopt, oder? Oder geht das nicht weil die Zwischenresultate nicht im nächsten Takt an den Inputs wieder zur Verfügung stehen? Was soll das hier sonst bringen, mehrere Quads teilweise zu verarbeiten und zwischen mehreren verarbeiteten Quads zu wechseln?

Können diese Leerquads nicht einfach eine >>Folge<< von aufwendigerer Adressierung sein?

???

Oder diese "Leerquads" (wohl einfach "nops") sind einfach eine Folge davon, dass die Resultate nicht gleich wieder zur Verfügung stehen. (und natürlich auch, dass bei vielen Temps/Shader nicht die Regs mehrerer Quads gespeichert werden können, d.h. es muss in einem solchen Fall gewartet werden, bis die Resultate eines zuvor teilberechneten Quads wieder zur Verfügung stehen)

Original geschrieben von Demirug
Ja das waren dann wohl 8 Tex + 8 Int12 Operationen. Es sind ja im NV30 noch Integer Regcombiner vorhanden und ich gehe ja wie gesagt davon aus das sich der neue FP32 Combiner im NV35 in 2 Int12 Combiner spliten lässt womit dieser ja auch noch 8Tex + 8Int12 Ops beherscht aber eben nicht bei PS >= 2.0 weil es dort ja nur FP Formate gibt. Ob nun auch 8 FP16 Ops möglich sind ist natürlich eine andere Frage. ¨

Ich meine unabhängige MUL, DP3 und DP4 FX12-Operationen. Davon kann NV30 offenbar bis zu 16 / Takt.

[Demirug]

Original geschrieben von ram
Mir ist der Zusammenhang zwischen " #Quads in der Pipeline " mit den Registerspeicher und den Leer-Quads noch nicht klar. Werd mir das nochmals überlegen resp. das Patent mal lesen.

Wieso braucht es Leer-Quads, wenn auf einem 2x2-Quad 16 ADDs durchgeführt werden? Sinnvollerweise wird doch in so einem Fall an diesem Quad gearbeitet, bis es fertig ist, also dasselbe Quad gleich 16x geloopt, oder? Oder geht das nicht weil die Zwischenresultate nicht im nächsten Takt an den Inputs wieder zur Verfügung stehen? Was soll das hier sonst bringen, mehrere Quads teilweise zu verarbeiten und zwischen mehreren verarbeiteten Quads zu wechseln?

Können diese Leerquads nicht einfach eine >>Folge<< von aufwendigerer Adressierung sein?

???

¨

Ich müsste das Programm mal sehen um zu sagen ob man den Quad da wirklich auf einen Schlag durchbekommt. Der Shadercore selbst hat ja laut der Zeichung in dem Patent keinen direkten Zugriff auf den Registerspeicher. Er hat lediglich 3*4 FP32 Loopbackregister und kann von einem durchlauf maximal einen Scratch-Wert (4*fp32) in den nächsten übernehmen. Ob dieses Scratch Register nun auf eines der 3 Loopback Register kopiert wird oder zusätzlich vorhanden ist geht leider nicht klar hervor sowie die ganze Loopback steuerung des Shadercores nicht sehr ausführlich erklärt ist.

Reichen also die interne Registerresourcen innerhalb des Shadercores nicht mehr aus muss er über den grossen Loopback die anderen Werte holen. Die zweite Frage ist wie viele Taktstufen dieser Shadercore überhaupt hat. Daraus ergibt sich dann auch wie viele Quads minimum gleichzeitig in der Pipe sein müssen um sie voll zu nutzen.

Ich meine unabhängige MUL, DP3 und DP4 FX12-Operationen. Davon kann NV30 offenbar bis zu 16 / Takt.

Ja das sind die guten alten Regcombiner. Die können das schon ewig. In wie weit das bei Int12 Operationen aber auch in den NV35 übernommen wurde kann ich derzeit nicht sagen.

[turboschlumpf]

so, bin auch endlich dazu gekommen den artikel zu lesen. hammergeil, beide daumen hoch, respekt.
imo der beste und interessanteste seit langem, das hat keine andere seite zu bieten.

[edit] was nicht heisst dass ich auch verstehe was da steht :D

[edit 2] trotzdem seit langem mal wieder ein artikel für den ich mir viel zeit genommen und den ich komplett gelesen habe.
einfach mal was anderes das man sonst nirgends zu lesen bekommt.

[Ikon]

Nun ... nach den ganzen Komplimenten soll es auch an Kritik nicht mangeln. Dazu möchte einige Zitate von aths kommentieren:

Original geschrieben von aths
Imo sind Artikel, bei denen man nicht gleich alles versteht, besser als Artikel, die man komplett versteht aber weniger in die Tiefe gehen.

Das sehe ich prinzipiell genauso. Aber während aths "nicht gleich alles versteht", verstehe ich noch nicht einmal die Hälfte. Und es ist nicht so, dass mir verwendeten Fachbegriffe nicht bekannt wären. In diesem Fall würde ich einen Artikel der weniger in die Tiefe geht, den ich aber komplett verstehe, vorziehen.

Original geschrieben von aths
Erinnert sich noch wer an 3dconcept? Als 3D-Newbie habe ich fast nichts verstanden, doch brachten diese Technik-Artikel viel mehr, als das allgemeine Blabla der meisten anderen Seiten.

Mit 3DConcept-Niveau komme ich problemlos zurecht, diese Artikel sind auch ansonsten sehr unterhaltsam geschrieben. Beides kann ich von diesem (und einigen anderen) Artikel nicht behaupten, da können die enthaltenen Erkenntnisse noch so bahnbrechend sein. Dieser Artikel setzt IMHO zuviel Fachwissen voraus, ist zu trocken formuliert und mangelhaft illustriert.

Wenn ich lese, dass selbst aths den Inhalt nicht komplett erfassen konnte, dann muss ich ernsthaft fragen ob dieser Artikel nicht seine Zielgruppe verfehlt hat.

Demirug verdient zweifelsohne großen Respekt für den Inhalt (und nicht zuletzt Dank für die investierte Freizeit), ich störe mich allerdings sehr am "Drumherum". Die Art wie man die Informationen vermittelt sollte IMO genausowichtig sein wie der Inhalt selbst. Gerade bei einem derart komplexen Thema sicherlich eine sehr große Herausforderung ...

Diese Kritik trifft auch auf einige der anderen aktuellen Artikel zu. Als positives Beispiel fällt mir z.B. "Anti-Aliasing im Detail" ein -> Vergleicht einfach mal selbst, der Unterschied ist extrem. Das Niveau des Inhalts ist bei den letzten Artikeln in den Himmel geschossen, die Formulierung und Illustration wurde dagegen IMHO stark vernachlässigt, worunter vorallem Verständlichkeit und Unterhaltungswert stark gelitten haben.

Seid mir bitte nicht böse dafür, denn das ist was ich denke. Alles andere wäre eine Lüge.

[Demirug]

Original geschrieben von Ikon
Seid mir bitte nicht böse dafür, denn das ist was ich denke. Alles andere wäre eine Lüge.

Warum sollte ich dir böse sein? Dafür gibt es keinen Grund. Als Pädagoge für die Massen bin ich nicht sonderlich gut. Den beim schreiben von Texten kenne ich leider nur zwei extremen "viel zu technisch" oder "Kleinkinder ebene" (Lass mal bei ein paar anderen Mods das Wort "Pixelfarbrik" in diesem Zusammenhang fallen). Wenn überhaupt bin ich als Pädagoge nur für Einzelpersonen oder kleine Gruppen zu gebrauchen da mir der direkte Feedback hilft mich an den richtigen Level heranzuarbeiten. Man sagt mir nach das ich dabei eine Engelsgeduld hätte wenn es darum geht die gleiche Sache immer wieder aus unterschiedlichen Wegen zu erklären. Nur nutzt mir dieses Talent (falls ich es wirklich habe) nicht sonderlich viel wenn es darum geht einen Text für viele Leser zu schreiben.

Ich habe jetzt zwei Artikel hier geschrieben und in beiden Fällen was die Massentauglichkeit angeht mehr oder minder versagt. Das sollte für mich nun ein klares Zeichen sein das ich die Masse nicht weiter mit meinem schwer verständlichen Texten quälen sollte solange ich nicht fähig bin massentauglicher zu schreiben. Da ich aber wohl auf diesem Gebiet vorerst meine mir derzeit möglichen Limits erreicht habe werde ich also bis auf weiteres besser nichts mehr für die Hauptseite zu schreiben. Ich möchte nicht das das 3dcenter durch mich den Ruf erhält nur für eine kleine Elite zu schreiben.

[Ikon]

Ich fände es schade wenn du mit dem Verfassen von Artikeln für 3DC aufhören würdest, das war nicht der Zweck meiner Kritik :-( . Es ist IMO unsinnig seine Autorenfähigkeiten an nur zwei Artikeln messen zu wollen, da kommt es schließlich auf Erfahrung an. Wie solltest du sonst die "Massentauglichkeit" deiner Artikel steigern, wenn nicht durch das Verfassen selbst?

Die Performance-Analyse und der Vergleich mit dem R300 erscheint mir z.B. wiederum durchaus gelungen -> das Problem ist hauptsächlich der Anfang des Artikels; über die Architektur der Pipeline. Die Balance zwischen leicht und schwer verständlichen Theorieartikeln ist IMHO zurzeit einfach gestört (siehe auch aths' letzte Artikel). Ein paar "harte Nüsse" dazwischen sind nichts schlechtes, aber es müsste dann eben auch wieder etwas "leichte Kost" zum Ausgleich geben.

[Demirug]

@eam: Bezüglich des Leerquads habe ich mir nun noch ein paar Gedanken gemacht und habe eine alternative Interpretation gefunden. Möglicherweise meint man keinen extra Block der durch die Pipeline muss sondern einen normalen Block der extra makiert ist. Da diese Lösung effektiver sein sollte gefällt sie mir je länger ich darüber nachdenke immer besser.

[aths]

Original geschrieben von Ikon
Das sehe ich prinzipiell genauso. Aber während aths "nicht gleich alles versteht", verstehe ich noch nicht einmal die Hälfte. Und es ist nicht so, dass mir verwendeten Fachbegriffe nicht bekannt wären. In diesem Fall würde ich einen Artikel der weniger in die Tiefe geht, den ich aber komplett verstehe, vorziehen.Während der Artikel enstand, hatte ich Gelegenheit, Demi mit Fragen zu löchern. Imo wäre das generell der richtige Weg: Gucken, wo genau die Unklarheiten sind, und dann einfach gezielt fragen.
Original geschrieben von Ikon
Mit 3DConcept-Niveau komme ich problemlos zurecht, diese Artikel sind auch ansonsten sehr unterhaltsam geschrieben. Beides kann ich von diesem (und einigen anderen) Artikel nicht behaupten, da können die enthaltenen Erkenntnisse noch so bahnbrechend sein. Dieser Artikel setzt IMHO zuviel Fachwissen voraus, ist zu trocken formuliert und mangelhaft illustriert."Zuviel Fachwissen" für wen? Sollen Leute à la ich sich immer mit Artikeln auf aths-Niveau zufrieden geben? :naughty:
Original geschrieben von Ikon
Wenn ich lese, dass selbst aths den Inhalt nicht komplett erfassen konnte, dann muss ich ernsthaft fragen ob dieser Artikel nicht seine Zielgruppe verfehlt hat.Wichtig ist, dass das enthaltene Wissen in die Foren sickert, dort kann es ja von anderen auch "einfacher" erklärt werden.
Original geschrieben von Ikon
Diese Kritik trifft auch auf einige der anderen aktuellen Artikel zu. Als positives Beispiel fällt mir z.B. "Anti-Aliasing im Detail" ein -> Vergleicht einfach mal selbst, der Unterschied ist extrem. Das Niveau des Inhalts ist bei den letzten Artikeln in den Himmel geschossen, die Formulierung und Illustration wurde dagegen IMHO stark vernachlässigt, worunter vorallem Verständlichkeit und Unterhaltungswert stark gelitten haben. Auf den Multisampling-Artikel gebe ich mehr, da der AA-Artikel imo zu oft Dinge vereinfacht.

Was verstehst du unter "verstehen"? ram hat auf 3dconcept z.B. Dot3 BM erklärt. Ich könnte bis heute keinen Pixelshader schreiben (obwohl mir die Syntax ein wenig geläufig ist) der Dot3 BM realisiert. Solange ich das nicht kann, und in OpenGL mittels Register Combiner selbst realisiert habe, würde ich nicht behaupten, zu wissen was Dot3 genau ist. Von dieser Warte aus finde ich Demirugs Artikel sogar nicht sehr tiefschürfend.

[Kilbert]

Ein ausgezeichneter Artikel!

Original geschrieben von Demirug Das sollte für mich nun ein klares Zeichen sein das ich die Masse nicht weiter mit meinem schwer verständlichen Texten quälen sollte solange ich nicht fähig bin massentauglicher zu schreiben.

Für mich war das Niveau genau richtig. Ich glaube nicht, dass man dieses komplexe System ohne Minderung des Informationsgehaltes einfacher hätte beschreiben können. Leider findet man solch tiefschürfenden Artikel sehr selten. Deiner kann sich durchaus mit z.B. den CPU-Artikeln von Hannibal (arstechnica (http://arstechnica.com/paedia/c/cpu/part-2/cpu2-1.html)) messen, und das ist ein großes Lob!

Ich möchte nicht das das 3dcenter durch mich den Ruf erhält nur für eine kleine Elite zu schreiben.

Das ist eine zweischneidige Sache. Den Artikel kann in der Tiefe nur ein Entwickler verstehen, der sich schon intensiv mit Shaderprogrammierung auseinandergesetzt hat. Selbst für ambitionierte Spieler ist das einfach eine (eher zwei) Größenordnungen zu hoch. Für diese sollte man eine Zusammenfassung schreiben, die genau das enthält, was sie brennend interessiert: Was kann ein neues Spiel bzw. ein neuer Treiber theoretisch aus der vorhandenen Hardware rausholen.

Und ich glaube nicht, dass ab und zu mal ein eher gehaltvoller Artikel dem Ruf von 3dcenter schadet =)

[Demirug]

Für alle denen der Technikteil aus dem Artikel zu kompliziert war gibt es hier (http://www.forum-3dcenter.de/vbulletin/showthread.php?s=&threadid=91709) ein paar ergänzede Erklärungen an einem vereinfachten NV30 Model. Ist aber noch nicht komplett und eine typische Demi fassung (Rechtschreibung und Gramatik ist was für andere). Ich verspreche aber nicht das es nun für alle verständlicher wird.

[LovesuckZ]

Was ein wenig zu kurz im Artikel kam, ist die doch deutig miserabele PS <2.0 Performance in Spiele. Da es zur Zeit doch schon einige Games gibt, die einen deutlichen Gebrauch von diesen machen.
Gibt es zu diesem Thema eigentlich schon eine pausibele Erklaerung?

[Demirug]

Original geschrieben von LovesuckZ
Was ein wenig zu kurz im Artikel kam, ist die doch deutig miserabele PS <2.0 Performance in Spiele. Da es zur Zeit doch schon einige Games gibt, die einen deutlichen Gebrauch von diesen machen.
Gibt es zu diesem Thema eigentlich schon eine pausibele Erklaerung?

Meinst du jetzt 1.4 oder 1.1 -1.3?

[mapel110]

Original geschrieben von Demirug
Meinst du jetzt 1.4 oder 1.1 -1.3?

1.1-1-3, ich glaube kaum, dass LS behaupten würde, es würde massiv ps1.4 eingesetzt werden in vielen spielen ;)

[Ikon]

Original geschrieben von mapel110
1.1-1-3, ich glaube kaum, dass LS behaupten würde, es würde massiv ps1.4 eingesetzt werden in vielen spielen ;)

Mal überlegen:
1. PS1.1-1.3 läuft bei NV3X* über die Register Combiner, sollte also nicht langsamer als bei NV2X sein
2. Problem bleibt die relativ schlechte PS1.4-Performance bei NV3X*
3. ab NV35 sollte auch die PS1.4-Performance deutlich besser geworden sein, da dieser eine zweite Shader-ALU besitzt (diese übernimmt auch PS1.1-1.3 Anweisungen, ist dabei aber offenbar kaum langsamer als die Combiner).

*<NV35

-> IMO kann LovesuckZ nur PS1.4 meinen (die allgemeine Shader-Performance der NV3X-Architektur wird schließlich im Artikel hinreichend analysiert und in Relation zur Konkurrenz gesetzt)

[LovesuckZ]

Original geschrieben von Ikon
-> IMO kann LovesuckZ nur PS1.4 meinen (die allgemeine Shader-Performance der NV3X-Architektur wird schließlich im Artikel hinreichend analysiert und in Relation zur Konkurrenz gesetzt)

Aquanox 1+2, Splinter Cell, Comanche4, UT2003, U2 etc. benutzen wohl überwiegend PS 1.<4. Und in allen Spielen liegt die Leistung einer 5800 irgendwo zwischen 9600pro und 9700 (9600 <<<<<<<<<<<<>>>>>>9700).
Von dem vergleich 5900U und 9800pro brauchen wir erst garnicht reden.
Daher finde ich diesen Aspekt doch sehr bedeutend.

[Demirug]

also in Aquanox 2 gibt es schon 1.4 und sogar 2.0 Shader (passreduktion) bei U2 halte ich es auch nicht für ausgeschlossen (nicht gegengeprüft).

Wie Ikon schon sagt so ist zumindestens beim NV30 die gleiche Rohleistung pro Takt wie bei einem NV25 vorhanden. Beim NV35 kann man das nicht 100% sicher sagen. Allerdings hat man ja an der Pipeline rumgespielt und das Timeing dieser verändert. Darf man nun einem alten Gerücht glauben schenken so sind alle nVidia Chips seit TNT auf der Ebene der Hardwareansterung abwärtskompatibel. Soll heisen das man einem NV30 eine NV25 Steuercodesequenz senden kann und er wird diese ausführen. Allerdings wird dabei nur auf die Lauffähigkeit geachtet. Es ist also durchaus möglich das der aktuelle Detonator (welcher ja ursprünglich für NV2X geschrieben wurde) immer noch massenhaft NV25 Steuercodes benutzt. Ist aber alles IMHO und AFAIK.

[Ailuros]

..also in Aquanox 2 gibt es schon 1.4 und sogar 2.0 Shader (passreduktion) bei U2 halte ich es auch nicht für ausgeschlossen (nicht gegengeprüft).

Soweit ich weiss benutzt U2 PS1.4.

[Gast]

Eine derart fundierte Betrachtung der NV Architektur habe ich schon lange gesucht,
um meine wissenschaftlichen Vertex-und Fragmentprogramme zu optimieren.
Top!

Gruss,
Jan W.

[robbitop]

soo ich habe damals den Artikel nicht verstanden.
Heute habe ich mich nochmals dran gemacht und ich muss sagen, dass mir nun einiges klarer geworden ist.
Sicher setzt er etwas Wissen voraus, aber wenn selbst ich ihn jetzt verstehe, dann kann es nicht allzuschlimm sein.
Es tut mir leid, dass ich erst jetzt den Wert dieses Artikels erkenne. Beide Daumen hoch Demirug, du hast mein Wissen erweitert!

[aths]

... und meinen kommenden Artikel in dieser Form überhaupt erst ermöglicht :)