Diskussion zu: Inside nVidia NV40

[Leonidas]

Link (gültig ab 15 Uhr!): www.3dcenter.org/artikel/nv40_technik/ (http://www.3dcenter.org/artikel/nv40_technik/)

Update: Artikel ist online.

[LovesuckZ]

Werden auch die neuen IQ settings in diesem Artikel besprochen oder nur was sich hinsichtlich der Architektur verändert hat?

[Leonidas]

Wird in dem Artikel ebenfalls mit besprochen. Kommt aber auch im Benchmark-Artikel nochmals ins Gespräch.

[ForbiddenSkill]

Hö ? Warum 2 ThreadS ? Was ist der Unterschied ? Beides geht doch um NV40... ???

[Leonidas]

2 Artikel.

[Gast]

:down: Server tot.

[WTC]

ja, nix läuft mehr :(

[FormatC]

Der geht sicher gleich wieder.

[Gnafoo]

jup war wohl doch zu viel :) ..
naja abwarten was solls ..

[mofhou]

Hm, hat jemand schon den Artikel gelesen?

[huha]

Okay, ich fang' einfach mal an, die Fehler hier reinzuposten.
Wird editiert, wenn ich mich durch den Artikel arbeite.

Seite 2:
"Modifyer" -- muß "Modifier" heißen. Vgl. Sg."Party", pl. "Parties"

"Beim NV30 und NV35 waren FP12-Berechnungen" -- muß natürlich FX12 heißen.

Seite 3:
"Quad-basiertes Rendering ist geschieht vor allem aus zwei Gründen" -- "ist" wegmachen.

"eine Technik, die schon im Vorhinein verhindern soll, " -- Komma hinter Technik vergessen.

"und mit der höchsten Auflösung spielen, die der Monitor noch hergibt:" -- ebenfalls ein Komma vergessen, diesmal hinter "die"

"Lange Pixelshader, die heftige arithmetische Rechnungen vornehmen, sind dann wieder Shader-limitiert." -- da müssen zwei Kommas rein, einmal hinter Pixelshader, einmal hinter vornehmen.

"Angedachts, dass der NV40 für zukünftige Spiele gebaut wurde, meinen wir, dass es keinen Grund gibt, sich heute am Bandbreiten-Problem des NV40 zu stören." -- "Angedachts" ist mir nicht bekannt. Hinter "wir" und "gibt" fehlt je ein Komma.

"Vergeudung (obwohl es in Wahrheit keine ist), weil wir scheinbar" -- Komma hinter der Klammer.

"Wir sind ziemlich froh, dass nVidia" -- Komma hinter froh.

"weil FP16-Texturen durch mehr Präzision und höherer Dynamik glänzen" -- sollte "höhere Dynamik" heißen.

"Für Textur-Lookups, die von mathematischen Funktionen" -- Komma.

"sind besser dran, wenn sie FP16-Input" -- Komma hinter dran.

Seite 4:
"Daraufhin gab esviele, oft hitzige Diskussion" -- "es viele" und "Diskussionen"


"Alte Spiele, die für 16 Bit optimiert sind (beispielsweise Thief 2), sehen mit 32 Bit Rendering kaum besser aus" -- Komma hinter "Spiele" und die Klammer.

"- wenn man Glide hat, und " -- Komma durch "-" ersetzen.

"Man muss nicht mehr in FP-Texutren rendern" -- Texturen.

"zu spielen, wir werden abwarten müssen, ob der RAMDAC" -- Komma.

"Isotropic filtering as it should be.


GeForce 6800 Ultra : Lower isotropic quality at angles of about 45°." -- bitte auf deutsch machen.

" haben die schwarzen Linien eingefügt, um zu zeigen, aus welchen Teilen das isotrope 360°-MIP-Muster jeweils besteht." -- Komma.


"Offen gesagt, waren wir völlig geschockt, als wir die neue" -- KOmma nach "gesagt" muß weg, dafür sollte ein Komma nach "geschockt" plaziert werden.

" für eine gegeben Füllratenleistung" -- muß "gegebene" heißen.

"Wir sehen keine Zweck darin," -- "keinen Zweck"

"zwischen Radeon und bisherige GeForce-Karten." -- "bisherigen GeForce-Karten"


Seite... 5
"eine Technik, die das gesamte Bild unscharf macht.)" -- Komma hinter Technik.

"Wir erwarten, dass Pixelshader 3.0 in nicht allzuferner Zukunft eingesetzt wird" -- KOmma hinter "erwarten"

"Auch wenn ATIs neues Werk PS3.0 nicht unterstützen wird, stehen die Chancen gut, dass Pixelshader 3.0" -- zwei Kommas.

"Wie immer, liefert nVidia aber erst mal nur die Features, und dann erst die Leistung." -- beide KOmmas raus.

"Sie versuchen, ihr Produkt zu verkaufen, denn das ist ihr Job." -- Kommahinter"versuchen"bitte. ;)

"und wir danach gieren, es endlich in Spielen zu sehen," -- Komma nach "gieren"


Seite 6... aths, bald bist du erlöst ;)

"Augenhöhe mit einer DX 5950 Ultra" -- FX 5950 Ultra.

"Quad-basierend, nur eben, dass man zwei Takte braucht, um eine Operation auf das ganze Quad anzuwenden" -- Herr Ober, zwei Kommas bitte!

"doch nVidia versprach, das Gamma-Problem sei nun gelöst" -- Komma!

"aber das neue Nview wird " -- "nView"

"Wir hatten zu wenig Zeit, um eine tiefgehende Analyse schon jetzt anzubieten, doch das werden wir weiter untersuchen, sobald wir eine neue Karte haben." -- zwei Kommas.

"GeForce4 die letzte GPU von nVidia, die mit heutigen Treibern" - Koooooommmmmmaaaaaaaaaaaaa.





-huha

[Cow]

Vor einiger Zeit behauptete nVidia, dass NV40 acht Pipelines hätte. Diese Zählweise resultiert aus einem geschickten Trick in den Raster-Operation Units (ROPs.) Seit NV30 kann eine einzelne ROP wie zwei arbeiten, sofern lediglich Z-Werte zu testen sind. Das verdoppelt natürlich nicht die tatsächlichen Pipelines.
Sollte da nicht NV30 stehen?

[aths]

Japp. Ich hoffe, Leo kann diese Sachen fix korrigieren.

[Demirug]

Mehr Details untergebracht als B3d. Nicht schlecht. Wobei ich die Pipeline noch ein bischen anders gezeichnet hätte (aber nur im Detail).

Zwei Sachen benötigen IMHO aber noch einere genaueren Untersuchung:

1. Vorher kommen die Performancegewinne bei FP16 wirklich
2. Wie ist die Branching Performance wirklich. Vorallem getrennt nach dynamischem und statischem.

[Cow]

Seite 1
Wo wir gerade bei "kostenlos" sind: FP16-NRM ist oft "frei". NRM ist eine Instruktion (eigentlich ein Makro) um einen Vektor zu normalisieren (das heißt, seine Länge auf 1 zu setzen.) Das ist die einzige NV40-Instruktion, wo FP16 ist als FP32. Sogar FX12 (ein Fixpoint-Format für DirectX8-Shader) ist nicht mehr schneller als FP32. Beim NV30 und NV35 waren FP12-Berechnungen noch sehr viel schneller als die gleiche Rechnung mit Floating Point.


Zwischen ist und als fehlt ein Wort.

[GloomY]

Seite3:Nehmen wir an, 8 Bit Fixpoint würde genutzt, und nur das letze Bit wäre gesetzt.Da fehlt ein 't'.

Seite 6:wir erwarten die 8-Pipe-Version auf gleicher Augenhöhe mit einer DX 5950Soll wohl FX 5950 heissen. :)

[LovesuckZ]

Original geschrieben von Demirug
Mehr Details untergebracht als B3d. Nicht schlecht. Wobei ich die Pipeline noch ein bischen anders gezeichnet hätte (aber nur im Detail).


Hättes du was anderes von aths erwartet? :)
Muss sagen, der Artikel ist sehr gut verstaendlich, was wohl am lockeren Schreibstil liegt. Auch die Bilder welche eigentlich deplaziert wirken sollten, wecken interesse.
Sehr gut!

[Demirug]

Original geschrieben von LovesuckZ
Hättes du was anderes von aths erwartet? :)
Muss sagen, der Artikel ist sehr gut verstaendlich, was wohl am lockeren Schreibstil liegt. Auch die Bilder welche eigentlich deplaziert wirken sollten, wecken interesse.
Sehr gut!

Ich hätte mehr von Dave Baumann erwartet.

[x-dragon]

Seite 1 Ein Z-ony-Wert hat keine Farbe ... Seite 3 Mann kann ja alles ... Seite 6 ... wenn die Teile erhältlich sind .. Naja ich finde dies paßt vom Schreibstil nicht so ganz :stareup:.

[mofhou]

Seite 2:
Eine einzelne N30-Pipe kann zwei Textur-Operationen,
Sollte NV30 heißen...

[mayo]

Ist eigentlich bekannt, ob die mangelnde AF-Qualität beim NV40 am Chipdesign liegt oder der Treiber schuld ist?

Ich tippe auf das 2. (Damit bei den Reviews die Balken länger sind)

Es ist im Endeffekt egal, aber so könnte man noch auf Besserung hoffen.

[huha]

Denke ich nicht.
nVidia hat einfach die Zeichen der Zeit erkannt und eine schlechtere Texturfilterung eingebaut, dafür aber das AA gründlich aufgemöbelt, denn das wollen (und können!) die Leute ja sehen.
Ich bin schon auf die nächste Generation von ATi gespannt, vielleicht wird dort die Texturfilterqulität etwas höher gesetzt.

-huha

[Tigerchen]

Original geschrieben von mayo
Ist eigentlich bekannt, ob die mangelnde AF-Qualität beim NV40 am Chipdesign liegt oder der Treiber schuld ist?

Ich tippe auf das 2. (Damit bei den Reviews die Balken länger sind)

Es ist im Endeffekt egal, aber so könnte man noch auf Besserung hoffen.

nV hat natürlich auch gesehen daß den Leuten ATI's AF Performance wichtiger ist als die Qualitätsverluste. Diese wurden ja eh nur von Lovesuckz, aths und einigen nV-Fans wahrgenommen. ATI-User haben da ja eher selten was dran rumzumäkeln. Darum hat nV bewußt diesen richtigen Schritt getan.

Dies ist ein Abwägen. Und ich bin mir bewußt daß andere die Waagschaale in die andere Richtung haben ausschlagen sehen. Denen sei ihre Meinung unbenommen.

[RLZ]

Huch
Da steh ich ja in den Danksagungen ;D

Ist ein netter Artikel geworden.
Es gibt aber halt noch einige Fragen die in einem so kurzen Artikel leider nicht behandelt werden können. Vielleicht gibts ja ein paar Ergänzungsartikel in der nächsten Zeit :)


Obwohl Displacement-Mapping eine tolle Technologie ist, und wir danach gieren es endlich in Spielen zu sehen,...

Sieht halt einfach genial aus, wenn sich Schatten von Objekten in die Mauerritzen hineinziehen. Also hoffen wir mal das Normalsterbliche es hoffentlich möglichst bald auch in Echtzeit bewundern können. :D

[robbitop]

@aths

Ich muss sagen dieser Artikel ist mehr als gelungen. Du kannst zu Recht mehr als Stolz auf ihn sein.
Die ganze Zeit des Lesens war ein tolles Gefühl, welches Lückenlos standhielt bis zum Schluss.
Dein Schreibstil, deine Erläuterungen, Infos und dein Fazit waren klar und übersichtlich formuliert, trotz einer enormen Detailfülle. Ich konnte so viel nachvollziehen wie nie zuvor. Du hast tatsächlich einen Schreibstil gewählt, der mehr Leser denn je erfassen kann.
IMO der beste NV40 Artikel.
Gratulation!!! (tut mir leid, ich bin halt einfach total positiv überrumpelt von dem Artikel =) )

Eine Frage hätte ich jedoch noch an Dich:
ist die Winkelabhängigkeit Hardwareseitig (gesparte Transistoren) oder eine softwareseitige Implementation?
Ich habe gehofft, dass man in Zukunft über coolbits oder den aTuner das gute alte AF wiederbekommt.
Denn ich kann es wirklich verstehen, dass man den Reviewern soetwas vorenthällt. Ich fande das zu Zeiten der NV3x sehr unangemessen. Schön wäre es wenn es eben später wieder erhältlich wäre, zumal bei dieser Füllrate keine Optimierung notwendig ist.

[ForbiddenSkill]

Sag mal isses nicht egal ob es jetzt nen kleinen RechtschreibFehler hat ? Mein Gott...

[mayo]

Original geschrieben von Tigerchen

nV hat natürlich auch gesehen daß den Leuten ATI's AF Performance wichtiger ist als die Qualitätsverluste. Diese wurden ja eh nur von Lovesuckz, aths und einigen nV-Fans wahrgenommen. ATI-User haben da ja eher selten was dran rumzumäkeln. Darum hat nV bewußt diesen richtigen Schritt getan.


hast du nicht die ironie-tags vergessen?

Im professionellen Markt wäre die Winkelabhängigkeit sicher nicht beliebt. Und der NV40 soll bestimmt nicht nur im Heimusermarkt verkauft werden.

@aths

Sehr hübscher Arktikel, übersichtlich und verständlich.

[x-dragon]

Original geschrieben von ForbiddenSkill
Sag mal isses nicht egal ob es jetzt nen kleinen RechtschreibFehler hat ? Mein Gott... Nein, Leonidas wie auch Aths möchten gerne möglichst fehlerfreie Artikel online haben, da diese ja schliesslich auch von seeehr vielen Leuten gelesen und auch später immer noch als Grundlagenartikel immer wieder neu verlinkt werden. Ausserdem gibts ja schliesslich auch viel Konkurrenz und da ist es natürlich immer besser das ein Artikel möglichst wenig Fehler enthält (Rechtschreib-, Grammatik- wie auch Technische-Fehler).

[Darkstar]

Original geschrieben von huha
Seite 2:
"Modifyer" -- muß "Modifier" heißen. Vgl. Sg."Party", pl. "Parties"Wobei im Deutschen auch „Partys“ korrekt ist. :)

Auf Seite 6 ist noch was, Abschnitt „Video-Beschleunigung“, 2. Satz:Das heißt, die GPU entlastet die CPU wenn Video-Daten dekomprimiert, und sogar wenn wie komprimiert werden.Das Komma hinter „dekomprimiert“ kann weg und das „wie“ sollte wahrscheinlich „sie“ heißen.

[robbitop]

wie siehts nun eigentlich mit dem Videoencoding aus?
Habe nirgendwo davon gelesen (gut ich knabber gerad noch am Review von Leo...)

[KingZer0]

Interpunktionsfehler mal außen vor empfinde ich den Artikel zwar als eine zweifellose Kompetenzdemonstration des Autors hingegen geht nach meinem dafürhalten eine allgemeine Verständlichkeit durchaus verloren.

Und ich bezweifle auch sehr stark das nur annähernd soviele Leute hier den Artikel in einer derartigen Art und Weise transparent und verständlich finden wie sie es vorzugeben versuchen
wie könnte es auch
schließlich scheinen Autor und sein Gefolge die ihm kooperativ zur Seite standen über immense Kenntnisse zu verfügen die nur innerhalb eines Studiums vermittelt werden können.

Deshalb würde mich persönlich auch mal interessieren welchen Tätigkeiten demirug und aths (stimmt das?) beruflich nachgehen :) oder welche Quelle des Wissens sie anzapfen auf das auch andere daraus schöpfen können ;)

[Tigerchen]

Original geschrieben von mayo
hast du nicht die ironie-tags vergessen?

Im professionellen Markt wäre die Winkelabhängigkeit sicher nicht beliebt. Und der NV40 soll bestimmt nicht nur im Heimusermarkt verkauft werden.

@aths

Sehr hübscher Arktikel, übersichtlich und verständlich.

Der nV40 ist für Gamer und er ist für Gamer und er ist für Gamer. Hab ich was vergessen? Ah ja! Er ist für Gamer!!!

[Tigerchen]

Original geschrieben von KingZer0
Interpunktionsfehler mal außen vor empfinde ich den Artikel zwar als eine zweifellose Kompetenzdemonstration des Autors hingegen geht nach meinem dafürhalten eine allgemeine Verständlichkeit durchaus verloren.

Und ich bezweifle auch sehr stark das nur annähernd soviele Leute hier den Artikel in einer derartigen Art und Weise transparent und verständlich finden wie sie es vorzugeben versuchen
wie könnte es auch
schließlich scheinen Autor und sein Gefolge die ihm kooperativ zur Seite standen über immense Kenntnisse zu verfügen die nur innerhalb eines Studiums vermittelt werden können.

Deshalb würde mich persönlich auch mal interessieren welchen Tätigkeiten demirug und aths (stimmt das?) beruflich nachgehen :) oder welche Quelle des Wissens sie anzapfen auf das auch andere daraus schöpfen können ;)

Ich lese da Schwächen bei der Bandbreite und bei den TMU's raus.

[Xmas]

Original geschrieben von Tigerchen

Der nV40 ist für Gamer und er ist für Gamer und er ist für Gamer. Hab ich was vergessen? Ah ja! Er ist für Gamer!!!

Und du glaubst nicht an einen NV40GL (in Ermangelung eines Produktnamens für die nächste Quadro-Generation nenne ich sie einfach mal so)?

Ich denke du unterschätzt die Anzahl derer, die sich über die Qualitätsverluste beim AF ärgern.

[Demirug]

Original geschrieben von KingZer0
Deshalb würde mich persönlich auch mal interessieren welchen Tätigkeiten demirug und aths (stimmt das?) beruflich nachgehen :) oder welche Quelle des Wissens sie anzapfen auf das auch andere daraus schöpfen können ;)

Softwarentwickler und meine Quellen stehen mehr oder minder jedem offen. Die Entwicklerbreiche der Hardwarehersteller sind sehr ergiebig wenn man sie mit entsprechenden Patentschrifen in Verbindung setzt.

Aber auch die Vortragsfolien von Veranstaltungen im Graphikbereich findet man oft interesantes.

[Madkiller]

:up:
Sehr gute Arbeit aths, gefällt mir.

[KingZer0]

@Demirug

Zweifellos sicherlich richtig jedoch muss man diese Informationen auch zu interpretieren wissen und genau diese Fähigkeit kann man sich nur mittels eines Studiums aneignen denkst du nicht?

Wie ihr dieses Niveau erreicht habt übt auf mich eine große Faszination und zugleich auch reges Interesse aus.

[Demirug]

Original geschrieben von KingZer0
@Demirug

Zweifellos sicherlich richtig jedoch muss man diese Informationen auch zu interpretieren wissen und genau diese Fähigkeit kann man sich nur mittels eines Studiums aneignen denkst du nicht?

Wie ihr dieses Niveau erreicht habt übt auf mich eine große Faszination und zugleich auch reges Interesse aus.

Ob ein Studium da was bringt kann ich nicht sagen. Ich habe nicht studiert.

[KingZer0]

Das ist allerdings spektakulär hätte ich doch vermutet das im Hinblick auf Dein scheinbar weitreichendes Wissen ein Studium essentieller Bestandteil gewesen ist.

Würdest Du mir dennoch verraten wie der Werdegang Deiner anfänglichen Affinität für 3-Dimensionales hin zum etabilierten 3D-Entwickler verlaufen ist?

[zeckensack]

Anmerkungen/Korrekturen:
Seite 2, ~Mitte
"Jede Pipe hat seine beiden Shader Units. Das gute ist, dass jede einzelne Unit bis zu zwei unabhängige Befehle pro Takt ausführen kann. Das geschieht per Split. Ein voller Pixel-Vektor besteht aus 4 Einzelwerten (und zwar: rot, gründ und blau für die Farbe, umd Alpha für Transparenz oder andere Spezialeffekte.) Jede Einheit kann in 3:1 splitten (seit Radeon 9500 beherrscht ATI das auch, was wir erwähnen sollten) oder in 2:2 (das ist NV40-exklusiv.)"

Das beherrschen auch schon Radeon 8500 und Geforce 3, und wenn man weiter zurückgeht ins Land der "fixed function texture stages" auch schon wesentlich ältere Chips ala Riva TNT und Rage 128.

Ein 3:1 Split ist seit vielen Jahren quasi Industriestandard. KA wie man das formulieren sollte, meine Variante (die möglicherweise nicht jedem gefallen wird) wäre eben dass ausschliesslich NV30, sozusagen als historischer Schluckauf in der HW-Entwicklung, diesen Split nicht immer beherrschte.

Keine Einwände bezüglich 2:2-Split, das ist wahrhaftig neu.

Weiter unten:
"Wo wir gerade bei "kostenlos" sind: FP16-NRM ist oft "frei". NRM ist eine Instruktion (eigentlich ein Makro) um einen Vektor zu normalisieren (das heißt, seine Länge auf 1 zu setzen.) Das ist die einzige NV40-Instruktion, wo FP16 ist als FP32."
Wurde bereits angemerkt, es fehlt ein Wort.

[zeckensack]

Seite 3, ~Mitte, Kategorie "nitpick" ;)
"Das Schöne bei Floating Point ist, dass die feine Auflösung in jenen Bereichen ist, wo man sie braucht. Verallgemeinert gesagt sind alle unsere menschlichen Sinne "logarithmisch", somit können wir einen sehr großen Bereich von Energie-Leveln wahrnehmen. Bei kleiner Musik-Lautstärke ist leises Rauschen leicht zu hören, während volle Phonstärke solch leises Rauschen "rausmaskiert". Den gleiche Effekt gibt's auch bei unterschiedlichen Lichtbedingungen: In dunkler Umgebung sehen wir noch sehr schwache Unterschiede, während in einer hellen Umgebung nur größere Helligkeits-Differenzen noch wahrnehmbar sind."

Eher nicht. Das Hörorgan ist so ein Kandidat, die visuelle Wahrnehmung ist IMO weitgehend linear, dabei wird lediglich der Wertebereich ("gain") von der Pupille nachgeregelt. Um es mal ganz platt zu formulieren, erfüllt die menschliche Pupillenausregelung die gleiche Funktion wie die "Kontrast"-Einstellung an gängigen PC-Monitoren.

</nitpick> :)

[Leonidas @ Mozilla]

Alle bisher gefundenen Fehler gefixt.


Thx @ huha, Cow, Gloomy, x-dragon, mofhou & Darkstar.



/Update: Wegen Server-Ausfall wurden die neuen Dateien erst soeben upgeloaded.

[RLZ]

Original geschrieben von zeckensack
Seite 3, ~Mitte, Kategorie "nitpick" ;)
"Das Schöne bei Floating Point ist, dass die feine Auflösung in jenen Bereichen ist, wo man sie braucht. Verallgemeinert gesagt sind alle unsere menschlichen Sinne "logarithmisch", somit können wir einen sehr großen Bereich von Energie-Leveln wahrnehmen. Bei kleiner Musik-Lautstärke ist leises Rauschen leicht zu hören, während volle Phonstärke solch leises Rauschen "rausmaskiert". Den gleiche Effekt gibt's auch bei unterschiedlichen Lichtbedingungen: In dunkler Umgebung sehen wir noch sehr schwache Unterschiede, während in einer hellen Umgebung nur größere Helligkeits-Differenzen noch wahrnehmbar sind."

Eher nicht. Das Hörorgan ist so ein Kandidat, die visuelle Wahrnehmung ist IMO weitgehend linear, dabei wird lediglich der Wertebereich ("gain") von der Pupille nachgeregelt. Um es mal ganz platt zu formulieren, erfüllt die menschliche Pupillenausregelung die gleiche Funktion wie die "Kontrast"-Einstellung an gängigen PC-Monitoren.

</nitpick> :)

Die logarithmische Beziehung zwischen Energie und wahrgenommener Helligkeit stimmt meines Wissens. Allerdings kann kann nur Mensch nur einen sehr kleinen Helligkeitsbereich wahrnehmen und die Pupille passt die aktuelle Helligkeit an das Wahrnehmbare an (zb wenn man Nachts aus dem Haus geht sieht man zuerst garnichts und ein paar Minuten später wieder viel).
Das Auge selbst kann auch keine Absolutwerte bestimmen sondern nur Helligkeitsunterschiede feststellen. Die verminderte Sehfähigkeit im Dunkeln kommt daher, dass das Farbsehen einen gewissen Energielevel benötigt. Darunter kann der Mensch nur in Helligkeiten unterscheiden.
Tonemapping basiert auf dem ganzen Prinzip. Wenn das Auge eh nur entscheiden kann, ob ein Punkt heller oder dunkler ist als der nebendran, kann man auch einfach den Farbbereich so komprimieren, dass diese eigentliche Relation erhalten bleibt. Wenn dies nicht so wäre würde zB Histogrammanpassung ein schreckliches Ergebnis liefern.

[Demirug]

[SIZE=1]Original geschrieben von zeckensack
Ein 3:1 Split ist seit vielen Jahren quasi Industriestandard. KA wie man das formulieren sollte, meine Variante (die möglicherweise nicht jedem gefallen wird) wäre eben dass ausschliesslich NV30, sozusagen als historischer Schluckauf in der HW-Entwicklung, diesen Split nicht immer beherrschte./SIZE]

Passt so schon.

Die FX12 können es die FP16/32 Einheiten nicht. Ausnahme Texturzugriff im Shadercore.

[zeckensack]

Oooch, wo ist die AF-Blume? Keine da? ;(
*schnüff*

[robbitop]

laut B3D ist High Quality ohne Wirkung und Wavey glaubt dass man später damit wieder das NV3x AF bekommt.

[aths]

Original geschrieben von KingZer0
Interpunktionsfehler mal außen vor empfinde ich den Artikel zwar als eine zweifellose Kompetenzdemonstration des AutorsAus Zeitgründen verzichtete ich eigentlich auf Kompetenzdemonstrationen und konzentrierte mich auf eine NV40-Analyse.
Original geschrieben von KingZer0
hingegen geht nach meinem dafürhalten eine allgemeine Verständlichkeit durchaus verloren.Der Artikel setzt zugegebenermaßen einiges voraus, zumindest Durchhaltevermögen. Ziemlich zu Beginn nerve ich den Leser mit irgendwelchen Details zur Pipeline.

Mein Ansatz war: Jeder interessierte Leser liest mindestens 4-5 Artikel gründlich. Ich müsste etwas anbieten, was andere nicht bringen und kann dafür auf Dinge verzichten, die praktisch jeder bringt. Bei mir gibt es z. B. keine Tabellen mit den Features und Zahlen, was beim Shader Model 3.0 jetzt besser ist. Im Gegenteil, im Artikel findet man nur einige herausgepickte Dinge, die mir eben am wichtigsten waren. Das ganze auf "3DCenter-Niveau", wo ich durchaus etwas Verständlichkeit opfere, um bei noch vertretbarer Artikellänge trotzdem hier und da in Details einzusteigen.

[aths]

Original geschrieben von zeckensack
Ein 3:1 Split ist seit vielen Jahren quasi Industriestandard. KA wie man das formulieren sollte, meine Variante (die möglicherweise nicht jedem gefallen wird) wäre eben dass ausschliesslich NV30, sozusagen als historischer Schluckauf in der HW-Entwicklung, diesen Split nicht immer beherrschte.Meine Herangehensweise war, vor allem die DX9-Linie von NV zu betrachten (DX8 und Register Combiner kommen nur am Rande vor.) Ich wollte den Leser relativ schnell zum NV40 führen, ohne z. B. vorher R300-Pipes zu zeigen (im Text wird erwähnt, was sie grob können) und kam auf "Details" wie die Splitmöglichkeit erst später zu sprechen. Bis dahin schusterte ich der R300-Pipe "bis zu" 2 math pro Takt zu, ohne zu sagen, woher das "bis zu" kommt. Das ist eine Folge des Zeitdrucks, eigentlich sollte noch rein:

- Aufbau der Pipe vom R300, NV30 (warum ein DX9-Desaster?), NV35, NV40. (Nur NV40 blieb letztlich.)

- Warum überhaupt Pipelines? (Immer mehrere Quads drin um die Auslastung zu gewährleisten, Beispiel Latenz beim Textursampling.)

- Große Diskussion um die Definition, was trilinear ist, inkl. der interessanten Meinung von David Kirk.

- Irgendein Pixelshader 3.0-Beispiel, was keine Grafik rechnet, und Sprunganweisungen nutzt.

- Was ich von kleinen Chips auf NV40-Basis halte (ist nur kurz drin, vor allem die positiven Sichtweisen, eigentlich wäre das eine längere Diskussion wert.)

- Genaue Analyse der AF-Shots,

und noch etwas mehr.

[aths]

Original geschrieben von zeckensack
Eher nicht. Das Hörorgan ist so ein Kandidat, die visuelle Wahrnehmung ist IMO weitgehend linear, dabei wird lediglich der Wertebereich ("gain") von der Pupille nachgeregelt. Um es mal ganz platt zu formulieren, erfüllt die menschliche Pupillenausregelung die gleiche Funktion wie die "Kontrast"-Einstellung an gängigen PC-Monitoren.

</nitpick> :) Wenn sich die Pupille verkleinert, kann man keine (absoluten) feinen Differenzen mehr sehen, die man mit weiter Pupille in passender Dämmerung noch wahrnimmt. Eine Frage der Sichtweise, denke ich. Ich wollte begründen, warum große absolute Lichthelligkeiten nicht so fein aufgelöst sein müssen, wie geringe Helligkeiten. Wie die Wahrnehmung (bei angepasster Pupille) im wahrnehmbaren Bereich ist (also eher linear oder eher logarithmisch) weiß ich ehrlich gesagt nicht.

[zeckensack]

So, der Server hat mich wieder bedient, und bin jetzt durch. Schöner Artikel, aths :)
Und ... äh, bitteschön X-D

[LovesuckZ]

Original geschrieben von aths
Große Diskussion um die Definition, was trilinear ist, inkl. der interessanten Meinung von David Kirk.


Die wäre? :)

[Muh-sagt-die-Kuh]

@Aths:

Ich hätte da eine Frage zum Artikel, zum Abschnitt " Textur-Filterung mit Floating Point"

Dieser Abschnitt beschreibt wunderbar die Vorteile eines FP16 Formats gegenüber eines FX8 Formats...nur beschreibst du mit keinem Wort, wo und wie das ganze eingesetzt wird.

Besteht bei einer Texturfilterung nicht der Input (bei 32 bit Texturen) aus mehreren RBGA-8-8-8-8 Werten und ist der Output nicht auch ein RBGA-8-8-8-8 Wert? Wo hier ein FX8 oder FP16 Wert Anwendung finden ist mir zumindest im Moment sehr schleierhaft. Aufklärung wäre nett :)

[Demirug]

Original geschrieben von Muh-sagt-die-Kuh
@Aths:

Ich hätte da eine Frage zum Artikel, zum Abschnitt " Textur-Filterung mit Floating Point"

Dieser Abschnitt beschreibt wunderbar die Vorteile eines FP16 Formats gegenüber eines FX8 Formats...nur beschreibst du mit keinem Wort, wo und wie das ganze eingesetzt wird.

Besteht bei einer Texturfilterung nicht der Input (bei 32 bit Texturen) aus mehreren RBGA-8-8-8-8 Werten und ist der Output nicht auch ein RBGA-8-8-8-8 Wert? Wo hier ein FX8 oder FP16 Wert Anwendung finden ist mir zumindest im Moment sehr schleierhaft. Aufklärung wäre nett :)

Der Output des Texturfilters ist immer ein FP32 Wert. Die "normalen" Texturen bestehen aus FX8 Werten. Hat man 4 davon (für RGBA) ergibt sich die bekannte 32 Bit Textur. Anstelle von FX8 Werten kann man nun auch FP16 Werte benutzten. Bei einer Textur mit 4 Elementen ergibt sich dann eine 64Bit Textur.

Nutzen kann man das ganze zum Beispiel für bessere Bumpmaps.

[zeckensack]

msdk,
der Output einer Filteroperation mit 8 Bit pro Kanal im Rohmaterial ist nicht wirklich mit 8 Bit pro Kanal exakt darstellbar. Das gilt eigentlich so gut wie immer, es ist nicht die Ausnahme, sondern vielmehr die Regel.

Vier Texel (8 Bit, ein Kanal der Einfachheit halber)

255 | 254
----+----
254 | 254
Der bilineare Filter kennt nun zwei Gewichte, um diese vier Texel zu einem Sample zu vermischen. Sagen wir mal Wx und Wy. Das Sample ist nur dann mit 8 Bit exakt darstellbar, wenn
Wx=0 oder Wx=1
oder
Wy=0 oder Wy=1
(inklusives oder)

Bei allen anderen Werten passt's nicht mehr hin. Simpelst mögliches Beispiel:
Wx:=0,5
Wy:=0,5
=>
Sample=(255+254+254+254)/4=254,25

[Muh-sagt-die-Kuh]

Original geschrieben von zeckensack
msdk,
der Output einer Filteroperation mit 8 Bit pro Kanal im Rohmaterial ist nicht wirklich mit 8 Bit pro Kanal exakt darstellbar. Das gilt eigentlich so gut wie immer, es ist nicht die Ausnahme, sondern vielmehr die Regel.

Vier Texel (8 Bit, ein Kanal der Einfachheit halber)

255 | 254
----+----
254 | 254
Der bilineare Filter kennt nun zwei Gewichte, um diese vier Texel zu einem Sample zu vermischen. Sagen wir mal Wx und Wy. Das Sample ist nur dann mit 8 Bit exakt darstellbar, wenn
Wx=0 oder Wx=1
oder
Wy=0 oder Wy=1
(inklusives oder)

Bei allen anderen Werten passt's nicht mehr hin. Simpelst mögliches Beispiel:
Wx:=0,5
Wy:=0,5
=>
Sample=(255+254+254+254)/4=254,25 OK....FX 8 als Outputformat pro Kanal macht Sinn, ebenso wie intern FX10 zur Vermeidung von Rundungsfehlern.

Mir hat die simple Information gefehlt, dass hier nur von einem Kanal gesprochen wird ;)

[KingZer0]

Aus Zeitgründen verzichtete ich eigentlich auf Kompetenzdemonstrationen und konzentrierte mich auf eine NV40-Analyse.

Aber genau diese NV40 Analyse wenn sie denn qualitativ hochwertig sein soll impliziert doch eine Kompetenzdemonstration :)

Ich bin wirklich dankbar das ihr die Architektur des NV40 so akribisch zu durchleuchten versucht insbesondere aber aufgrund des Umstandes das alle Informationen in einem ziemlich mathematischen Kontext stehen würde ich mir abseits eures Floting Point Artikels Links wünschen die mir ermöglichen allgemeinere Aspekte des Artikels besser verstehen zu können.

Für konkrete Ideen wär ich sehr dankbar.

[RLZ]

Original geschrieben von KingZer0
Ich bin wirklich dankbar das ihr die Architektur des NV40 so akribisch zu durchleuchten versucht insbesondere aber aufgrund des Umstandes das alle Informationen in einem ziemlich mathematischen Kontext stehen würde ich mir abseits eures Floting Point Artikels Links wünschen die mir ermöglichen allgemeinere Aspekte des Artikels besser verstehen zu können.

Für konkrete Ideen wär ich sehr dankbar.

Es gibt doch neben den FP-Artikeln doch auch ältere Artikel die auf Antialiasing, Filter usw eingehen.
Es ist vielleicht einfacher, wenn du sagst was du nicht verstehst oder wo du mehr wissen willst ;)

[Kilbert]

Leider, leider wurde die isotrope Filterqualität gesenkt

Ich hab jetzt nicht die Bilder vermessen, aber für mich sieht das Ganze so aus, als hätte sich die Filterqualität verbessert, da die Darstellung weniger winkelabhängig geworden ist. Die NV40 ist viel näher dran am Ideal, was konzentrischen Kreisen entsprechen würde. Oder?

[Thomas_B]

Ich bin sehr positiv überrascht, 3Dcenter hat den besten Bericht über den Launch NV40 ONLINE.

Meine Nacht war auch lang und ich habe "ALLE" Berichte:

GeForce 6800 Ultra Review @ AnandTech
GeForce 6800 Ultra Review @ Tom's Hardware Guide.de
GeForce 6800 Ultra Review @ Hardware Analysis.com
GeForce 6800 Ultra Review @ 3DCenter.org
GeForce 6800 Ultra Review @ Nordichardware.com
GeForce 6800 Preview @ Golem.de
GeForce 6800 Preview @ ComputerBase.de
GeForce 6800 Preview @ FiringSquad.com
GeForce 6800 Preview @ Hardwareluxx.de
GeForce 6800 Preview @ Hardwaremag.de

gelesen!

Ich freue mich schon auf den *.* April 2004 wenn das Geheimnis R420 endlich gelüftet wird.

Dann werden so einige blass aussehen!

Sprüche, wie z.B. : Zitat Tomshardware:

Was NVIDIA mit der neuen GeForce 6800 Ultra abliefert, versetzt selbst langjährige Grafikkarten-Redakteure in ungläubiges Staunen. Die Leistung der Karte haut Grafik-Enthusiasten - den Autor mit eingeschlossen - absolut von den Socken und lässt ihn beim Betrachten der Benchmark-Ergebnisse unverständliche Töne von sich geben! Die bisherigen Spitzenmodelle GeForce FX 5950 Ultra und ATIs Radeon 9800XT erscheinen gegenüber der GeForce 6800 Ultra nur noch wie einfache Mainstream-Grafikkarten.
Ende:

...haben mich sehr verwirrt! ;-)

Wird doch zwei Absätze weiter klar gestellt:

Zitat:

Wem es nun bereits in den Fingern juckt, der sei gewarnt: Die Einstiegshürde in Form der Netzteilvorgabe von mindestens 480 Watt ist hoch, wobei die Watt-Zahl das geringe Problem darstellt. Schwieriger ist es, zwei separate Kabelstränge der Spannungsversorgung für die Karte frei zu halten. Einen echten Enthusiasten wird das jedoch wenig stören und Case-Modder erhalten eine neue Herausforderung.

Ende:

Ausblick:

Meine persönliche Glaskugel:

Der *.* April 2004 wird kommen, dann wird klar, das der R420 mit gleichem Strombedarf (Netzteil) wie der R360 und gleicher Baugrösse mehr kann als der NV40 und das wichtigste die Shader-Performance auch unter Spielen wie Farcry erheblich schneller sein wird, bzw. PS 3.0 als ONTOP-Feature nicht über die "Shader-Mogelpackung" NV40 hinwegtäuschen kann.

Trotzdem Glückwunsch an nvidia, das sie zumindestens einige Punkte angepackt hatten die bei der FX-Serie bemängelt wurden.

Beste Grüsse
Thomas_B

[aths]

Original geschrieben von Kilbert
Ich hab jetzt nicht die Bilder vermessen, aber für mich sieht das Ganze so aus, als hätte sich die Filterqualität verbessert, da die Darstellung weniger winkelabhängig geworden ist. Die NV40 ist viel näher dran am Ideal, was konzentrischen Kreisen entsprechen würde. Oder? Auch die Griechen irrten, in dem sie dachten, Perfektion müsse immer auf einen Kreis hinauslaufen. Der NV40 liefert mit diesem Muster bei bestimmten Winkeln weniger Texturschärfe, als möglich.

[ram]

Original geschrieben von aths
Auch die Griechen irrten, in dem sie dachten, Perfektion müsse immer auf einen Kreis hinauslaufen. Der NV40 liefert mit diesem Muster bei bestimmten Winkeln weniger Texturschärfe, als möglich.

Ich bin auch Grieche. Magst du erklären, weshalb beim trilinearen Filtering der bei 45° geknickte konzentrische Kreis "besser" sein soll als der nun fast konzentrische Kreis? Wieso ist es "richtiger", an der 45° Stelle den LoD leicht zu erhöhen, statt diesen konstant bei allen Winkeln gleich zu lassen?

[aths]

Original geschrieben von ram
Ich bin auch Grieche. Magst du erklären, weshalb beim trilinearen Filtering der bei 45° geknickte konzentrische Kreis "besser" sein soll als der nun fast konzentrische Kreis? Wieso ist es "richtiger", an der 45° Stelle den LoD leicht zu erhöhen, statt diesen konstant bei allen Winkeln gleich zu lassen? "Richtig" ist "ein Texel pro Pixel". Wenn man auf ein um 45° gedrehtes Raster sampelt, ist die herkömmliche Blume jenes Pattern, welche am "richtigsten" filtert. Das LOD mag bei 45° lt. diesem Pattern besser sein, allerdings wird auch rotiert gefiltert, so dass man dort nicht wirklich mehr Details unterkriegt. (Ein Pixel ist eben nur ein Pixel.)

[KingZer0]

Gut, ich fang einfach mal an ein paar Fragen in den Raum zu werfen. ;)

Der NV40 soll im Optimalfall ja bekanntlich auf eine "Pipelinepower" von 16T+64M kommen sofern die Reallocation des Treibers gut funktioniert.

Ihr habt geschrieben

Zitat:

Ein voller Pixel-Vektor besteht aus 4 Einzelwerten (und zwar: rot, grün und blau für die Farbe, und Alpha für Transparenz oder andere Spezialeffekte.) Jede Einheit kann in 3:1 splitten (seit Radeon 9500 beherrscht ATI das auch, was wir erwähnen sollten) oder in 2:2 (das ist NV40-exklusiv.)

Zitatende

Die Frage ist was wird gesplitted? Sind es die
4 Einzelwerte die auf beide Shaderunits im Verhöltnis 3:1 oder im neuen 2:2 Verhältnis umsortiert werden können?
also beispielsweise

3:1

Shader Unit 1: rot grün blau
Shader Unit 2: Alpha

2:2

Shader Unit 1: rot grün
Shader Unit 2: blau Alpha

[aths]

Original geschrieben von KingZer0
Die Frage ist was wird gesplitted? Sind es die
4 Einzelwerte die auf beide Shaderunits im Verhöltnis 3:1 oder im neuen 2:2 Verhältnis umsortiert werden können?
also beispielsweise

3:1

Shader Unit 1: rot grün blau
Shader Unit 2: Alpha

2:2

Shader Unit 1: rot grün
Shader Unit 2: blau Alpha So ist es. Wenn eine Instruktion nur mit RGB operiert, kann gleichzeitig eine skalare Instruktion abgearbeitet werden. Es müsste auch möglich sein, zwei Instruktionen gleichzeitig auszuführen, die beide jeweils RG ändern. Dieses Detail kläre ich noch (habe im Moment die Shader-Beispiele nicht zur Hand.)

[KingZer0]

@aths

Danke erstmal dafür

Weitere Frage(n) sofern gestattet:

Zitat:

Normalisierungs-Berechnungen werden oft bei Bumpmapping-Berechnungen genutzt. Bisher gibt es zwei Möglichkeiten, zu normalisieren: Entweder eine vorberechnete Cubemap zu nutzen, oder eine Dot-Operation gefolgt von RSQ und MUL. Gut, dass NRM_PP ("PP" steht für "partial precision", FP16) jetzt so schnell ist. Es wäre schöner, wenn ein full precision NRM ebenso schnell wäre.

Zitatende.

Wenn NRM eine neue Instruktion ist um Vektoren schneller normalisieren zu können müsste es dann oben nicht heißen "Bisher GAB es 2 Möglichkeiten..."

Zitat:

Obwohl eine NV40-Pipe weniger Rohpower hat als NV35-Pipes

Zitatende.

...aber doch nur beim Filtern von bilinearen Textursamples oder nicht? Schließlich scheint jeweils eine Pipeline ungeachtet ob NV35 oder NV40 auf die gleiche Rohpower zu kommen.

- NV35 Pipe 2T + 3M = 5
- NV40 Pipe 1T + 4M = 5

Beim NV35 ist das ja quasi noch der bestmögliche Fall der eintreten kann also doch eigentlich eine Tendenz Richtung NV40 oder nicht?

[zeckensack]

Ährm, AFAIK *hust* ... nein :|

Es sind zwei Shader-Einheiten (pro Pipe), die jeweils dual-issue haben. So kommt man auch auf vier Arithmetik-Ops pro Takt, pro Pipe.

Also nicht
Shader Unit 1: rot grün blau
Shader Unit 2: Alpha

sondern
Shader Unit 1: (rot grün blau) + (alpha)
Shader Unit 2: (rot grün blau) + (alpha)
oder
Shader Unit 1: (rot grün) + (blau alpha)
Shader Unit 2: (rot grün) + (blau alpha)
oder
Shader Unit 1: (rot grün blau) + (alpha)
Shader Unit 2: (rot grün) + (blau alpha)
oder
Shader Unit 1: (rot grün) + (blau alpha)
Shader Unit 2: (rot grün blau) + (alpha)

... natürlich nur dann, wenn nicht irgendwelche Abhängigkeiten oder sonstige Verkrampfungen das verhindern.
:dozey:

[ram]

Original geschrieben von aths
Das LOD mag bei 45° lt. diesem Pattern besser sein, allerdings wird auch rotiert gefiltert, so dass man dort nicht wirklich mehr Details unterkriegt. (Ein Pixel ist eben nur ein Pixel.)

Meinst du, weil bei zusätzlich rotierter Texturfläche durch die auf der horizontalen liegende Texeldiagonalen tendenziel mehrmals dasselbe Texel gelesen würden, was man durch eine höher aufgelöste Mipmap kompensieren will?

[aths]

Original geschrieben von KingZer0
...aber doch nur beim Filtern von bilinearen Textursamples oder nicht? Schließlich scheint jeweils eine Pipeline ungeachtet ob NV35 oder NV40 auf die gleiche Rohpower zu kommen.

- NV35 Pipe 2T + 3M = 5
- NV40 Pipe 1T + 4M = 5

Beim NV35 ist das ja quasi noch der bestmögliche Fall der eintreten kann also doch eigentlich eine Tendenz Richtung NV40 oder nicht? Nee. Beispiel NV35. 2 Textursamples, und bis zu 3x MAD afaik. (Kann sein dass ich mich hier irre, les ich heute abend mal nach.) MAD kann man, auch wenn es eine Instruktion ist, wie zwei Operationen zählen (da Multiply-Add.) Macht 6 "volle" (4-komponentige) Operationen pro Pipe und Takt.

(Im Artikel zähle ich Instruktionen, nicht Operationen.)

NV40 schafft bei 4 Komponenten pro Operation nur 3 Operationen: Einmal MUL und einmal MAD. Und nur ein Textursample pro Takt. Nun sollte man aber Samplingpower und arithmetische Leistung nicht einfach aufaddieren. Das "+" deutet nur ein "und" an, es soll nicht heißen dass man das einfach addieren kann.

Die NV40-Pipe hat mit ihren Mini-ALUs aber die Möglichkeit, doch etwas mehr zu leisten, als es hier den Anschein hat. Außerdem, wann braucht man schon 3x MAD pro Takt?

Der NV40 kann nun (endlich) auch die Units splitten, und pro Shader Unit 2x MUL (Unit #1) bzw. 2x MAD (Unit #2) machen, aber jede Unit kann nur vier Komponenten gleichzeitig behandeln.

Betrachten wir das noch mal anders: NV35 kann pro Takt bis zu 3 Instruktionen á 4 Komponenten berechnen, sind bis zu 12 Komponenten pro Takt. Der NV40 schafft nur bis zu 8 pro Takt. Diese Sichtweise stimmt aber auch nicht so ganz, weil die Mini-ALUs hier und da was beisteuern und kostenlos machen. Ich weiß jetzt nich, inwieweit der NV35 Extra-Logik für solche Modifier hat.

Das gute ist eben, dass der NV40 bis zu zwei "schmale" Instruktionen (schmal heißt hier, dass von den Registern weniger als alle 4 Komponenten genutzt werden) pro Unit und Takt verarbeiten kann.

[aths]

Original geschrieben von ram
Meinst du, weil bei zusätzlich rotierter Texturfläche durch die auf der horizontalen liegende Texeldiagonalen tendenziel mehrmals dasselbe Texel gelesen würden, was man durch eine höher aufgelöste Mipmap kompensieren will? Wenn ich das richtig verstanden habe (vermutlich habe ich es nicht wirklich richtig verstanden) könnte man es so sehen: Bei 45° sehen wir das Pixel aus diagonaler Sicht. Aus dieser Sicht ist es sqrt(2) mal so breit, wie aus "seitlicher" Sicht. Demzufolge kriegen wir sqrt(2) mal so viele Texel unter, können das LOD also entsprechend erhöhen.

edit: Hm nee, so ist es falsch erklärt. Große Pixel können ja weniger Details darstellen, als kleine. Irgendwann komme ich hoffentlich zum Artikel "Isotrope Texturfilterung im Detail", da wird die Frage des LODs eine Rolle spielen.

[KingZer0]

@aths

Danke dafür

@Zeckensack

Hmm wie kann das harmonieren?

Dann wäre jede Shader Unit einer Pipe dazu in der Lage 4 unabhängige Befehle auszuführen anstatt derren 2 wie sie im Artikel verwendet werden.

[zeckensack]

Original geschrieben von KingZer0
@Zeckensack

Hmm wie kann das harmonieren?

Dann wäre jede Shader Unit einer Pipe dazu in der Lage 4 unabhängige Befehle auszuführen anstatt derren 2 wie sie im Artikel verwendet werden. aths hat es gerade auch nochmal geschrieben, nur anders formuliert:
Du kannst, pro Pipe, acht Vektorkomponenten pro Takt einer Operation unterziehen.

Du hast zwei Rechenwerke die jeweils "aus der Ferne betrachtet"(TM) Vier-Komponenten-Vektoren verrechnen. Du musst aber nicht auf alle vier Komponenten die gleiche Operation anwenden, sondern du kannst eben splitten. 3:1 oder 2:2, oder 4:0 (du kannst wenn du willst ja auch auf beiden Seiten des Splits die exakt gleiche Operation ausführen).

Also zwei Operationen pro Rechenwerk, allerdings höchstens vier Vektorkomponenten pro Rechenwerk. Zwei Rechenwerke pro Pipe.
Macht je nach Weltanschauung entweder
2 Ops pro Pipe pro Takt (wenn man Vektoren zählt)
oder
4 Ops pro Pipe pro Takt (wenn man gesplittete Operationen doppelt zählt)
oder
8 Ops pro Pipe pro Takt (wenn man die berechneten Vektorkomponenten zählt)

:freak2:

[KingZer0]

Oooookay ;)
Ist zwar nicht so als ob ich jetzt ein Gefühl von Erleuchtung verspüre aber trotzdem sei Dir an dieser Stelle mein Dank sicher. :D

[aths]

Vielleicht gibt es zum Split noch mal einen Folge-Artikel. In der nächsten Zeit habe ich allerdings viel anderes zu tun.

[Tigerchen]

Original geschrieben von Xmas
Und du glaubst nicht an einen NV40GL (in Ermangelung eines Produktnamens für die nächste Quadro-Generation nenne ich sie einfach mal so)?

Ich denke du unterschätzt die Anzahl derer, die sich über die Qualitätsverluste beim AF ärgern.

Da dir in den Sinn gekommen ist diese Frage zu stellen und da ich mich das auch gefragt habe darfst du davon ausgehen daß sich die Jungs von nV auch gefragt haben wessen Bedürfnisse jetzt wichtiger sind.
Wie richtig diese Entscheidung war dürftest du in dem Augenblick bemerken wenn die schwächeren Derivate des nV40 erscheinen. Gerade die Käufer dieser schwächeren Varianten dürften froh sein endlich AF nutzen zu können ohne daß ihre Grafikkarte direkt in die Knie geht.

[robbitop]

@Xmas und Tigerchen

in Punkto AF sind die Würfel noch nicht gefallen.
Wavey meint, dass der HQ Modus später einmal (evl mittels verstecktem Registry Tweak) zu aktivieren sei, und damit das alte AF wieder verfügbar wäre.
Man will eben nur die Reviewer daran hindern, eine Chancenungleichheit zu erstellen.
Etwas ähnliches sagte NV bei einem Interview mit withingames.
Ich würde da erstmal abwarten, bevor wir das ganze abstempeln. Der NV40 hat dermaßen viel Füllrate, dass ein althergebrachtes AF noch immer schnell genug wäre.

[ram]

Original geschrieben von aths
Wenn ich das richtig verstanden habe (vermutlich habe ich es nicht wirklich richtig verstanden) könnte man es so sehen: Bei 45° sehen wir das Pixel aus diagonaler Sicht. Aus dieser Sicht ist es sqrt(2) mal so breit, wie aus "seitlicher" Sicht. Demzufolge kriegen wir sqrt(2) mal so viele Texel unter, können das LOD also entsprechend erhöhen.

edit: Hm nee, so ist es falsch erklärt. Große Pixel können ja weniger Details darstellen, als kleine. Irgendwann komme ich hoffentlich zum Artikel "Isotrope Texturfilterung im Detail", da wird die Frage des LODs eine Rolle spielen.

Dann hab ich das glaub noch nicht verstanden. Was hat denn diese rotierte Filterung für einen Einfluss auf den LoD, wenn nicht den obigen?

[aths]

Original geschrieben von Tigerchen

Da dir in den Sinn gekommen ist diese Frage zu stellen und da ich mich das auch gefragt habe darfst du davon ausgehen daß sich die Jungs von nV auch gefragt haben wessen Bedürfnisse jetzt wichtiger sind.
Wie richtig diese Entscheidung war dürftest du in dem Augenblick bemerken wenn die schwächeren Derivate des nV40 erscheinen. Gerade die Käufer dieser schwächeren Varianten dürften froh sein endlich AF nutzen zu können ohne daß ihre Grafikkarte direkt in die Knie geht.
Ein Argumgent, das nicht zieht. Denn die zusätzliche Leistung kommt durch verringerte BQ. Da kann man dann z. B. gleich mit 2x oder 4x AF (statt 16x) arbeiten.

[aths]

Original geschrieben von ram
Dann hab ich das glaub noch nicht verstanden. Was hat denn diese rotierte Filterung für einen Einfluss auf den LoD, wenn nicht den obigen? Ich denke mein Gedankengang geht in die richtige Richtung, ist aber falsch erklärt. Dazu muss man sich aufmalen, wie das in den Texture Space transformierte Pixel aussieht (und sich frage, was die LOD-Formel eigentlich liefern sollte.) Jedenfalls bin ich der Meinung, dass die herkömmliche TF-Blume besser als, als das an den Kreis angenäherte neue Muster im NV40. Bei gegeneinander rotierten Grids läuft das optimale LOD eben nicht auf einen Kreis hinaus.

Mein Problem ist, in diesem Bereich über etwas Halbwissen zu verfügen, ohne den vollen Durchblick zu haben. Aber irgendwann kommt der entsprechende Artikel =)

[Tigerchen]

Original geschrieben von aths
Ein Argumgent, das nicht zieht. Denn die zusätzliche Leistung kommt durch verringerte BQ. Da kann man dann z. B. gleich mit 2x oder 4x AF (statt 16x) arbeiten.

Du siehst die Sache mit der Winkelabhängigkeit einfach zu negativ. Mein Argument zieht sehr wohl. Es passt dir einfach nicht.
+

[aths]

Original geschrieben von Tigerchen
Du siehst die Sache mit der Winkelabhängigkeit einfach zu negativ. Ich sehe sie beinahe täglich, auf meiner Radeon 9600.

Original geschrieben von Tigerchen
Mein Argument zieht sehr wohl. Es passt dir einfach nicht.
+ Nein, es zieht nicht :) Ich erkläre es noch mal :)

- Die bessere AF-Leistung bei Radeon / beim NV40 kommt durch abgesenkte BQ.

- Man erreicht ebenso bessere AF-Leistung, wenn man den AF-Grad senkt.

- In der Natur ist diese Winkelabhängigkeit im ATI-Style nicht zu beobachten.

- Man erhält das natürlichere Bild, wenn man den bestmöglichen AF-Modus hat, und den AF-Grad senkt, um die Leistung zu verbessern, als den AF-Grad partiell und winkelabhängig zu senken.

- Der ATI-Style ist ja nur dann schneller, wenn es auch viele Winkel ungleich 45° und 90° gibt. Ansonsten muss genauso viel gefiltert werden, wie bei nicht-winkelabhängigen AF.

Daraus folgt doch, dass es nicht sinnvoll ist, mit solchen Winkelabhängigkeiten AF "endlich nutzbar" zu machen. Das ist es ja schon lange. Nur kostet z. B. 8x AF in alter GeForce-Qualität entsprechend Leistung – weil die Qualität so gut ist. Daraus folgt allerdings, dass man mal auf die tatsächliche BQ gucken sollte und nicht nur auf die Zahl vor dem "x".

[aths]

Ich bekam inzwischen einige Rückmeldungen, mein NV40-Artikel sei zu positiv aufgefallen. Dazu mal ein Statement:

Der Artikel in der jetzigen Version enthält weder die schärfsten Formulierungen was die Kritikpunke angeht, noch die höchsten Lobpreisungen.

In den beiden Stellen, wo es Kritik hagelt, löschte ich kurz vor der Abgabe zwei oder drei Sätze raus, die nur noch mal mit anderen Worten sagten, was bereits gesagt wurde.

Was das Lob angeht, so war das Kapitel "An architecture to scale" geplant als "An architecture to deliver". Dort wollte ich die NV40-Skaliermöglichkeiten mit einer Multichip-Variante vergleichen. Und ich hatte mal die Überlegung, dass der R300 (demzufolge auch R360) für "echte" DX9-Spiele zu rechenschwach wäre. 8 Vector4-Instruktionen pro Takt – bah. 32 müssten es sein! NV40 kann (unter bestimmten Umständen, nämlich wenn ein gewisser "Mix" eingehalten wird) diese 32 Instruktionen pro Takt liefern.

Was Shader Model 3.0 angeht, geht mir persönlich die Spieletauglichkeit am Hintern vorbei – mit 2.0 sind noch so viele tolle Effekte möglich, die wir mangels Performance noch nicht zu sehen kriegen. Aber sowohl die weitgehende Vereinheitlichung des Instruction Sets, als auch die Möglichkeit zu bedingten Sprüngen (was den Begriff "programmierbar" erst so richtig mit Sinn erfüllt) gefällt mir.

Ich bin eben nicht nur Spieler, sondern auch Techniker :) und schätze gewisse Dinge, auch ohne sofort Nutzen davon zu haben; einfach weil sie "schön" sind. Das klingt im Artikel vergleichsweise wenig durch.

Was AF angeht, so halte ich AF auf S3 Deltachrome-Niveau eigentlich für eine Selbstverständlichkeit bei einem "guten" Chip. Trilinear ist lange nicht mehr gut genug, und ich will nicht bei einigen Winkeln auf 2x AF limitiert sein. AF ist (sofern man eben auf herkömmlicher isotroper Filter-Basis arbeitet) der richtige Weg zu möglichst richtig gefilterten Texturen. Da sollte man alles bekommen, was man kriegen kann – für mich der Sinn eines BQ-Features. Auch Pixelshader greifen auf Texturen zu, auch Pixelshader können anisotrop gefilterte Samples nehmen. Ich will hier einfach das beste!! :motz:

[deekey777]

Ehrlich gesagt hatte ich Angst diesen Artikel zu lesen, da meine technischen Kenntnisse zu gering sind.
Mein Lieblingsabsatz:
"Kurzgefasst wird die GeForce 6800 Ultra keine gute Wahl sein, um "echte Shader 3.0-Spiele" zu spielen. Nun ist es im Moment das einzige Produkt mit Shader Model 3.0-Support, aber die nächsten Generationen (NV50+) werden 3.0-Shader sehr viel schneller laufen lassen" (Seite 5.) (http://www.3d-center.de/artikel/nv40_technik/index5.php)

Ich wusste es!!! Der NV40 ist "nur" ein R300/R420 Killer.

Edit:
@aths: Wer hat sich denn beschwert? Unfähige Schreiberlinge?

[aths]

Original geschrieben von deekey777
@aths: Wer hat sich denn beschwert? Unfähige Schreiberlinge? Nein, normale Leser. Richtig "beschweren" kann man das auch nicht nennen.

[Endorphine]

Hi aths, ein bischen Kritik zu deinem schönen Artikel musst du dir von mir leider anhören ;). Die beanstandeten Stellen sind halbfett markiert.

Seite 1, Absatz 3: Wir werden über Pixel- und Vertexshader 3.0 (Shader Model 3.0) reden, das neuen Antialiasing und anisotrope Filtern, aber auch die Bandbreiten-Limitierung, und auf Dinge zu sprechen kommen, die vielleicht nicht erwartet wurden.

Seite 1, ziemlich am Schluss: Das gesamte Quad wird gerendert, auch wenn nur ein einziges Pixel vom Quad teil des Dreiecks ist.

Seite 1, letzter Absatz: Um zusammenzufassen: Wir müssen wissen wie viel der Chip arbeitet, nicht aus wie vielen "Pipes" er gemacht ist. Nein. Wie viel ein Chip im Laufe seiner Lebenszeit arbeitet interessiert niemanden, da dies individuell verschieden ist. Es kauft niemand Grafikkarten mit einer bestimmten Arbeit über ihre Lebensdauer ein, sondern nur Arbeit pro Zeiteinheit, gennannt Leistung. Richtig müsste es also heissen:
Um zusammenzufassen: Wir müssen wissen wie viel der Chip zu leisten vermag, nicht aus wie vielen "Pipes" er gemacht ist. Ich kann auch mit einer reinen 2D-Grafikkarte wie einer Tseng Labs ET3000, einem PII und einem Softwarerenderer mehr Arbeit verrichten als mit der leistungsfähigsten 3D-Grafikkarte.

Später im Text hast du es dann aber wieder richtig beschrieben: "Da wir 16 Pipes ingesamt haben, erreichen wir als maximale Gesamt-Chipleistung 16T+64M." An der Stelle auch mal ein Lob für diese neue Art der theoretischen Leistungsbetrachtung. Ich wünsche es mir, dass sich das durchsetzt.

Seite 2, zweiter Absatz:Eine einzelne NV30-Pipe kann zwei Textur-Operationen, oder (jede) arithmetische Instruktion ausführen. Diese ganze Arbeit wird im Shader Core gemacht. Hmm, "to do work"? :D Denglisch, aths, Denglisch... Arbeit "verrichtet" man für gewöhnlich.
Eine Textur-Operation liefert das fertige Textursample nicht sofort, wenn man besser als bilinear filtert, muss die Pipe ihre beiden TMUs nutzen, in einigen Fällen sind auch interne Loops notwendig. Meiner Meinung nach sollte die Rate an englischen Fachbegriffen in einem deutschen Artikel auf ein Minimum reduziert werden, wenn es ebenso gut verständliche verbreitete deutsche Fachausdrücke mit gleicher Bedeutung gibt. Warum also "Loop" und nicht einfach nur "Schleife"? Das stört nur den Lesefluss.

Seite 2, Absatz 4:Man sollte aber bedenken, dass wir den logischen Pipeline-Aufbau besprechen, die tatsächliche Hardware arbeitet wohlmöglich ganz anders. Das Wort gibt's in meinem Wortschatz gar nicht. Oder meinst du eher "womöglich"? :D

Seite 2, Bildunterschrift: Jeder NV40-Pipe besteht aus zwei Shader Units. Alle mir bekannten Bedeutungen (http://dict.leo.org/?search=pipe&searchLoc=0&relink=on&spellToler=standard&sectHdr=on&tableBorder=1&cmpType=relaxed&lang=en) von "pipe" sind entweder weiblich oder sächlich &rArr; "die Pipe".

Seite 2, irgendwo in der Mitte: Ein voller Pixel-Vektor besteht aus 4 Einzelwerten (und zwar: rot, gründ und blau für die Farbe, umd Alpha für Transparenz oder andere Spezialeffekte.)

Seite 2, letztes Drittel: Normalisierungs-Berechnungen werden oft bei Bumpmapping-Berechnungen genutzt. Normalisierungsberechnungen. Lang, aber richtig und weniger stockend im Lesefluss. Statt "Bumpmapping-Berechnungen" würde ich eher "Normalisierungsberechnungen werden oft für die Berechnung von Bumpmaps genutzt." schreiben.

Wenn es um die "Real World Performance" geht, bleibt der NV40 mit FP16 insgesamt schneller. Warum nicht einfach nur "Praxisleistung", "Leistung in der Praxis" oder "praktisch erzielte Leistung"? Denglisch ist nicht wirklich schön. Wenn ich Englisch lesen möchte kann ich die entsprechende Version des Artikels abrufen. Gleiches gilt für folgenden Satz: nVidia versprach, dass es kein hand-optimiertes Shader-Replacement mehr für Benchmark geben würde. Und auch Benchmarks ;).

Seite 3, Absatz 1: Ein Pixel-Block von 2x2 Pixeln wird oft "Quad" genannt. Quad-basiertes Rendering geschieht vor allem aus zwei Gründen: Erstens, [um] etwas Logik und damit Transistoren zu sparen. Sowie Man spiele Quake3 in geringer Auflösung mit aktivierten MIP-Map-Colors. :eyes: Warum nicht einfach nur "aktivierter MIP-Map Einfärbung"? Zudem auch missverständlich, der uninformierte Leser kann auch denken, dass sonst die Chrominanz im Bild fehlt (Graustufen). Oder hast du den englischen Artikel zuerst geschrieben?

Seite 3, erstes Viertel: Mit den verbesserten ROPs seit NV32 [...] NV32? Hab ich was verpasst, oder meinst du den NV31?

Seite 3, zweites Viertel:
"Memory Controller" ... Ich denke dass kaum jemand sagt "Hey Kumpel, wie geht's, weisst du was, ich habe mir ein neues Memory Module gekauft, toll, oder?". Warum nicht einfach nur Speicher-Controller (wg. Mix mit geläufigem Fremdsprachausdruck) oder Speichercontroller? Die Kritik könnte ich jetzt an noch viel mehr Stellen anbringen. Ich würde es begrüssen, wenn zukünftige deutsche Artikel für übliche deutsche Begriffe weniger englische Worte enthalten. Ich hab das früher auch oft gemacht, meiner Meinung nach ist es jedoch einfach nur schlechter Stil. In Deutschland spricht auch in Fachkreisen kaum jemand von Memory Controllern. Wenn ich zum nächsten Computerkistenschieber gehe und dort ein "Memory Module" kaufen möchte schaut der Verkäufer mich erst mal dumm an.

Seite vier, adaptive TF: ("Isotroper Filter" heißt Texturierung ohne anisotrope Verbesserungen.) Naja, Isotropie heisst eigentlich nur Richtungsunabhängigkeit :-). Wer nicht weiss was Isotropie ist kann mit "anisotropen Verbesserungen" auch nichts anfangen :-D. Die Erklärung dreht sich um sich selbst und schafft keine Klarheit für den, der den Begriff nicht versteht. Die Bildunterschriften sind übrigens noch in Englisch.

Seite vier, AF: Für Liebhaber von bester Texturqualität war GeForce immer die erste Wahl. Diese Zeiten sind vorbei. Wenn du mal ein Update für den Artikel schreiben solltest und inzwischen (siehe NV40 AF-Thread (http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&threadid=137166) neue Erkenntnisse zu den HQ-Schieberversprechen gefunden worden würde ich an deiner Stelle noch ein paar Worte dazu verlieren.

Seite fünf, MSAA:
Du hättest betonen können, dass nVidia diesen Quincunx-Unsinn endlich streichen soll. Wenn niemand kritisiert wird NV auch nix ändern.

Seite 5, VS 3.0:
Eine n00b-Frage: wozu wird die GPU erst logisch in die spezialisierten Teile VS und PS aufgeteilt, wenn jetzt die Spezialisierung durch die TMU-light im VS 3.0 wieder verwässert wird? Und wozu ist diese TMU da? Könnte man damit bei in bestimmten Situationen leerlaufendem VS die FÜllrate erhöhen (geht das überhaupt)?

Seite 6, skalierbare Architektur: Diesen Punkt mögen wir wirklich beim NV40: Eine Architektur, um sie alle zu finden und ewig zu binden. Diesen Satz hätte ich bei der derzeitigen Fanboyverteilung (ATI vs. NV) so nicht geschrieben ;-).

Natürlich kann man das nicht mehr von einer hypothetischen Version mit nur 2 Pipes erwarten. Eine 2-Pipe-GPU ist übrigens noch immer Quad-basierend, nur eben, dass man zwei Takte braucht, um eine Operation auf das ganze Quad anzuwenden. Zwei Pipes können nicht die Leistung bringen, die auch nur selten spielende Leute brauchen. Hab ich's überlesen oder ist der NV40 (wieder) der erste Quad-basierte 3D-Spielebeschleuniger? Und selbst wenn, ich denke dass auch PCI-Express den NV17 und die NV3x-Karten nicht sofort aufs Altenteil schicken wird.

Sonst ein prima Artikel, wie gewohnt (y).

p.s. Ich empfehle niemandem, längere Postings zu schreiben ohne angemeldet zu sein. Wenn ihr zwischendurch über den Postingdialog das Passwort eingebt und dann weitereditiert verschluckt das Forum dann beim Klick auf den "Antworten"-Button das Posting und wenn man den Text mit dem Browsercache zurückholt fehlt auf einmal die Hälfte. Argh 8-(.

[Demirug]

Später im Text hast du es dann aber wieder richtig beschrieben: "Da wir 16 Pipes ingesamt haben, erreichen wir als maximale Gesamt-Chipleistung 16T+64M." An der Stelle auch mal ein Lob für diese neue Art der theoretischen Leistungsbetrachtung. Ich wünsche es mir, dass sich das durchsetzt.

Im Prinzip gebe ich dir recht. Leider ist die Aache aber auch etwas problematisch. Diese Angabe stellt ja einen Max Wert da. Max Werte haben genau wie Min Werte das Problem nicht unbedingt Representativ zu sein. Desweiteren kommt hinzu das ein M auf einem Chip nicht genau einen M auf einen anderen Chip entsprechen muss. Schlimmer noch selbst auf dem gleichen Chip gibt es unterschiede.

Es ist also IMHO durchaus ein Schritt in die richtige Richtung aber die entgültige Lösung kann es nicht sein.

Eine n00b-Frage: wozu wird die GPU erst logisch in die spezialisierten Teile VS und PS aufgeteilt, wenn jetzt die Spezialisierung durch die TMU-light im VS 3.0 wieder verwässert wird? Und wozu ist diese TMU da? Könnte man damit bei in bestimmten Situationen leerlaufendem VS die FÜllrate erhöhen (geht das überhaupt)?

Die TMUs im VS sind zu schwach dafür. Keine Filter, keine LOD Berechnung. Zudem müsste man in dem Fall ja auch noch zusätzliche Datenpfade haben. Vom Rasterisiere zurück zu den VS und von den VS direkt zu den ROPs. Will man dann auch noch die Pixelfüllrate erhöhen bräuchte man noch zusätzliche ROPs. Wobei das letztere kaum Sinn macht wegen der Bandbreite. Zudem sind die VS im NV40 alles Solokämpfer und die PS arbeiten immer als 4er Team zusammen. Es gibt also schon noch eine Reihe unterschiede.

[Endorphine]

Original geschrieben von Demirug
Die TMUs im VS sind zu schwach dafür. Keine Filter, keine LOD Berechnung. Zudem müsste man in dem Fall ja auch noch zusätzliche Datenpfade haben. Vom Rasterisiere zurück zu den VS und von den VS direkt zu den ROPs. Will man dann auch noch die Pixelfüllrate erhöhen bräuchte man noch zusätzliche ROPs. Wobei das letztere kaum Sinn macht wegen der Bandbreite. Zudem sind die VS im NV40 alles Solokämpfer und die PS arbeiten immer als 4er Team zusammen. Es gibt also schon noch eine Reihe unterschiede. Und wozu hat nVidia dann überhaupt dem Vertexshader TMUs spendiert? Ich habe trotz extremem GPU-Halbwissen irgendwie den Verdacht, dass dies nur eine logische Anordnung ist und die TMUs nicht wirklich im Vertexshader sitzen. Der Sinn erschliesst sich mir gar nicht. Wozu dieser Aufwand?

Danke für deine Erklärungen :).

[Demirug]

Original geschrieben von Endorphine
Und wozu hat nVidia dann überhaupt dem Vertexshader TMUs spendiert? Ich habe trotz extremem GPU-Halbwissen irgendwie den Verdacht, dass dies nur eine logische Anordnung ist und die TMUs nicht wirklich im Vertexshader sitzen. Der Sinn erschliesst sich mir gar nicht. Wozu dieser Aufwand?

Danke für deine Erklärungen :).

Für VS3 braucht man sie eben. Die VS haben im NV40 schon jeweils ihere eigene TMU. Physikalisch sind die aber wahrscheinlich nicht direkt dort untergebracht. Das trifft aber auch auf die TMUs in den PS zu. In der Regel verushct man die TMUs so dicht wie möglich an das Speicherinterface zu bekommen. Das kommt daher das zwischen den Shadern und den TMUs viel weniger Daten übertragen werden wie zwischen dem Speicher und den TMUs.

Der Aufwand die Architektur auf universelle Shadereinheiten umzustellen wäre noch grösser gewesen. Deswegen dieser Zwischenschritt.

[Endorphine]

Original geschrieben von Demirug
Für VS3 braucht man sie eben. Die VS haben im NV40 schon jeweils ihere eigene TMU. Physikalisch sind die aber wahrscheinlich nicht direkt dort untergebracht. Das trifft aber auch auf die TMUs in den PS zu. In der Regel verushct man die TMUs so dicht wie möglich an das Speicherinterface zu bekommen. Das kommt daher das zwischen den Shadern und den TMUs viel weniger Daten übertragen werden wie zwischen dem Speicher und den TMUs.

Der Aufwand die Architektur auf universelle Shadereinheiten umzustellen wäre noch grösser gewesen. Deswegen dieser Zwischenschritt. Danke, das ergibt Sinn.

[aths]

Danke Endorphine, die meisten deiner Bemerkungen werde ich in die nächste Korrektur-Charge einfließen lassen.

[zeckensack]

Original geschrieben von Endorphine
Warum also "Loop" und nicht einfach nur "Schleife"? Das stört nur den Lesefluss.Loop stand hier IMO nicht wirklich für Schleife, sondern war eine Kurzform von Loopback, wofür im deutschen kein verbreiteter Begriff existiert. "Rezirkulation" halte ich für angebracht, ich bin mir aber nicht sicher, ob dass allgemeinverständlich wäre :|
Seite 3, Absatz 1:
Warum nicht einfach nur "aktivierter MIP-Map Einfärbung"? Zudem auch missverständlich, der uninformierte Leser kann auch denken, dass sonst die Chrominanz im Bild fehlt (Graustufen).Gegenvorschlag: eingefärbte Mip-maps. Nicht richtiger, aber kürzer.
Seite vier, adaptive TF: Naja, Isotropie heisst eigentlich nur Richtungsunabhängigkeit :-). Wer nicht weiss was Isotropie ist kann mit "anisotropen Verbesserungen" auch nichts anfangen :-D. Die Erklärung dreht sich um sich selbst und schafft keine Klarheit für den, der den Begriff nicht versteht.Anders rum. Der Satz richtet sich an Leute, die wissen was Anisotropie bedeutet, bzw die den Begriff kennen, und halbwegs wissen was passiert, wenn man im Treiber auf den entsprechenden Knopf drückt.
Isotropie als "keine Anisotropie" zu definieren halte ich für durchaus leserfreundlich. Es ist natürlich keine technische Definition, aber es erfüllt den Zweck: ein unbekannter Begriff wird eingeführt, und anhand eines bekannten Begriffs mit Sinn gefüllt.
Hab ich's überlesen oder ist der NV40 (wieder) der erste Quad-basierte 3D-Spielebeschleuniger?Quad-basiert ist IMO alles ab Geforce 1, respektive Radeon 8500, eventuell auch schon früher. Die einzigen bei denen ich mir halbwegs sicher bin, dass sie nie mit Quads gearbeitet haben sind 3dfx.


p.s. Ich empfehle niemandem, längere Postings zu schreiben ohne angemeldet zu sein. Wenn ihr zwischendurch über den Postingdialog das Passwort eingebt und dann weitereditiert verschluckt das Forum dann beim Klick auf den "Antworten"-Button das Posting und wenn man den Text mit dem Browsercache zurückholt fehlt auf einmal die Hälfte. Argh 8-(. Opera benutzen. Opera speichert den Inhalt aller Eingabefelder in der History. Vorwärts/Rückwärts-Navigation reicht in dem Fall aus.

[Endorphine]

Original geschrieben von zeckensack
Loop stand hier IMO nicht wirklich für Schleife, sondern war eine Kurzform von Loopback, wofür im deutschen kein verbreiteter Begriff existiert. "Rezirkulation" halte ich für angebracht, ich bin mir aber nicht sicher, ob dass allgemeinverständlich wäre :| Meiner Meinung nach passt Loopback gar nicht für diesen Fall, Loop aber schon. Ein Loopback ist nach meiner Definition eine Art "Rückschleife", wo ein Ausgang eines beliebigen Schaltkreises mit seinem Eingang verbunden wird, um bestimmte Szenarios einfacher durchtesten zu können. Im Falle von Eine Textur-Operation liefert das fertige Textursample nicht sofort, wenn man besser als bilinear filtert, muss die Pipe ihre beiden TMUs nutzen, in einigen Fällen sind auch interne Loops notwendig. wird jedoch nichts getestet (idR), sondern einfach nur eine TMU für eine höherwertigere Filterqualität mehrmals für das selbe Datum genutzt. Ist Haarspalterei, aber meiner Meinung nach ist das eine gewöhnliche Schleife, kein (Test-) Loopback. Original geschrieben von zeckensack
Gegenvorschlag: eingefärbte Mip-maps. Nicht richtiger, aber kürzer. Full ACK. Original geschrieben von zeckensack
Quad-basiert ist IMO alles ab Geforce 1, respektive Radeon 8500, eventuell auch schon früher. Die einzigen bei denen ich mir halbwegs sicher bin, dass sie nie mit Quads gearbeitet haben sind 3dfx. Gibt's den irgendeinen Grund, warum nVidia beim NV3-NV5 den Weg der quadbasierten 3D-Beschleunigung verliess, wo der NV1 nur auf Quads setzte? Für 3d-n00bs wie mich kommt der Quad-Ansatz jetzt wie vom heiteren Himmel im Artikel daher und ich kann ihn neben Dreiecken und infinite planes irgendwie nicht so recht einordnen... Das wird sicher auch anderen Lesern so gehen. Original geschrieben von zeckensack
Opera benutzen. Opera speichert den Inhalt aller Eingabefelder in der History. Vorwärts/Rückwärts-Navigation reicht in dem Fall aus. <ot> Danke, das wäre ein workaround. Opera hab ich ja sowieso immer als Testbrowser für HTML-Seiten installiert. Ich werde in der Mozilla Browser Newsgroup mal einen Flamethread starten, dass manche (closed-source) Konkurrenzprodukte nur wegen dieser kleinen Schwäche die bessere Wahl für www-Foren sind :D. </ot>

[Demirug]

Original geschrieben von Endorphine
Gibt's den irgendeinen Grund, warum nVidia beim NV3-NV5 den Weg der quadbasierten 3D-Beschleunigung verliess, wo der NV1 nur auf Quads setzte? Für 3d-n00bs wie mich kommt der Quad-Ansatz jetzt wie vom heiteren Himmel im Artikel daher und ich kann ihn neben Dreiecken und infinite planes irgendwie nicht so recht einordnen... Das wird sicher auch anderen Lesern so gehen.

Ähm ich glaube hier liegt ein Missverständniss vor.

Quad hat in diesem Fall nichts mit der Geometrie zu tun. Es geht darum das beim Rasterieren der Primitives (Punkte, Linien, Dreiecke) diese nicht in einzelne Pixel zerlegt werden. Es werden immer Blöcke mit 2*2 Pixel erzeugt. Diesen Block nennt man Quad. Ein solcher Quad wird dann immer zusammen bearbeitet.

Die Quads beim NV1 waren echte Geometrie und fallen in den Bereich der Patches.

[Endorphine]

Original geschrieben von Demirug
Ähm ich glaube hier liegt ein Missverständniss vor.

Quad hat in diesem Fall nichts mit der Geometrie zu tun. Es geht darum das beim Rasterieren der Primitives (Punkte, Linien, Dreiecke) diese nicht in einzelne Pixel zerlegt werden. Es werden immer Blöcke mit 2*2 Pixel erzeugt. Diesen Block nennt man Quad. Ein solcher Quad wird dann immer zusammen bearbeitet.

Die Quads beim NV1 waren echte Geometrie und fallen in den Bereich der Patches. Aso, danke. Begriffsverwirrung durch bereits mit anderen Bedeutungen besetzten Begriffen :sick:. Ich glaub', ich muss noch ne Menge Grundlagentexte für 3D-Rendering lesen :stareup:

[zeckensack]

Original geschrieben von Endorphine
Meiner Meinung nach passt Loopback gar nicht für diesen Fall, Loop aber schon. Ein Loopback ist nach meiner Definition eine Art "Rückschleife", wo ein Ausgang eines beliebigen Schaltkreises mit seinem Eingang verbunden wird, um bestimmte Szenarios einfacher durchtesten zu können.Meinst du jetzt nicht feedback?
In Bezug auf Schaltungen ... ja, da gibt's zB bei Operationsverstärkern Gegenkopplung und Mitkopplung, Rückkopplung wäre ein mögliches Ergebnis davon (manchmal erwünscht, manchmal nicht).

Aber Loopback? :|
IMO ist der Begriff in Punkto Grafik-Hardware wirklich anders besetzt.
Im Falle von wird jedoch nichts getestet (idR), sondern einfach nur eine TMU für eine höherwertigere Filterqualität mehrmals für das selbe Datum genutzt. Ist Haarspalterei, aber meiner Meinung nach ist das eine gewöhnliche Schleife, kein (Test-) Loopback.[/i]Oh ja, Haare spalte ich auch gern :freak:
In dem Fall (Texturfilter) wird eben nicht das gleiche Datum benutzt, sondern ein leicht verschobenes Datum zu einem älteren hinzugemischt.

Der Begriff findet btw auch Anwendung, wenn es um die Ausführung von zu langem Code geht. Das was dann "back loopt" sind die von einem Code-Fragment errechneten Registerinhalte, und es loopt so lange, bis der gesamte Code abgearbeitet werden konnte.

Unter einem "normalen Loop" verstehe ich ein Konstrukt einer Programmiersprache, aber keine Ablaufsteuerung von Hardware. Wie gefällt dir folgende Erklärung:
"Der Prozessor loopt sequentiell über alle Befehle, bis er auf einen Branch stösst. Dann wird's kompliziert."
:|

[Endorphine]

Original geschrieben von zeckensack
Oh ja, Haare spalte ich auch gern :freak:
In dem Fall (Texturfilter) wird eben nicht das gleiche Datum benutzt, sondern ein leicht verschobenes Datum zu einem älteren hinzugemischt. Ich erwähnte ja bereits meinen Wissensstand bei 3D-Echtzeitrendering :(. Original geschrieben von zeckensack
Wie gefällt dir folgende Erklärung:
"Der Prozessor loopt sequentiell über alle Befehle, bis er auf einen Branch stösst. Dann wird's kompliziert."
:| :up: Das ist eindeutig eine perfekte Formulierung. *eg*

[aths]

Original geschrieben von Endorphine
Oder hast du den englischen Artikel zuerst geschrieben?Japp, der englische Artikel ist das Original, welches von nggalai überarbeitet und dann von mir ins Deutsche übersetzt wurde.
Original geschrieben von Endorphine
Seite 3, erstes Viertel: NV32? Hab ich was verpasst, oder meinst du den NV31?NV30.

Original geschrieben von Endorphine
Seite vier, adaptive TF: Naja, Isotropie heisst eigentlich nur Richtungsunabhängigkeit :-). Wer nicht weiss was Isotropie ist kann mit "anisotropen Verbesserungen" auch nichts anfangen :-D. Die Erklärung dreht sich um sich selbst und schafft keine Klarheit für den, der den Begriff nicht versteht. Die Bildunterschriften sind übrigens noch in Englisch.Ups.

Von "anisotrop" sollten die meisten, die einen "Inside"-Artikel auf 3DC lesen, schon mal was gehört haben; also nutzte ich das, um isotrop zu erklären. (Ob ich je dazu komme, "Isotrope Texturfilterung im Detail" zu schreiben?)

Original geschrieben von Endorphine
Du hättest betonen können, dass nVidia diesen Quincunx-Unsinn endlich streichen soll. Wenn niemand kritisiert wird NV auch nix ändern.An dieser Stelle scheint Kritik durch: "Seltsamerweise bietet nVidia nach wie vor auch den Quincunx-Modus an (eine Technik, die das gesamte Bild unscharf macht.)" = Eine Technik, die man nicht einsetzen sollte.

Original geschrieben von Endorphine
Eine n00b-Frage: wozu wird die GPU erst logisch in die spezialisierten Teile VS und PS aufgeteilt, wenn jetzt die Spezialisierung durch die TMU-light im VS 3.0 wieder verwässert wird? Und wozu ist diese TMU da? Könnte man damit bei in bestimmten Situationen leerlaufendem VS die FÜllrate erhöhen (geht das überhaupt)?Nein. Die TMUs im VS sind nur im VS nutzbar.
Original geschrieben von Endorphine
Seite 6, skalierbare Architektur: Diesen Satz hätte ich bei der derzeitigen Fanboyverteilung (ATI vs. NV) so nicht geschrieben ;-).Siehe einige Postings weiter oben, ursprünglich waren für das Lob für diese Sache an NV noch höhere Töne geplant.

[Kilbert]

Original geschrieben von aths
Ich denke mein Gedankengang geht in die richtige Richtung, ist aber falsch erklärt. Dazu muss man sich aufmalen, wie das in den Texture Space transformierte Pixel aussieht (und sich frage, was die LOD-Formel eigentlich liefern sollte.) Jedenfalls bin ich der Meinung, dass die herkömmliche TF-Blume besser als, als das an den Kreis angenäherte neue Muster im NV40. Bei gegeneinander rotierten Grids läuft das optimale LOD eben nicht auf einen Kreis hinaus.

Ich denke, du denkst falsch. Aber ganz sicher bin ich mir auch nicht ;)

Egal, ob ich jetzt meine Textur rotiere, oder mein Objekt, solange der Winkel zwischen beiden fest ist, ändert sich das Verhältnis der beiden Flächen nicht. Demzufolge sollte die ideale Grenze der Mipmaplevel in einem Zylinder kreisförmig sein, da wir ja entlang der Achse schauen und alle Flächen unter dem gleichen Winkel sehen.

Eigentlich müsste man das Ganze natürlich mal auf der Signalebene mittels Samplingtheorie und Rekonstruktionsfiltern durchdenken. Ich denke, dass wenn man das tut, man merkt, dass das 1:1 Pixel:Texel Verhältnis sampling-technisch nicht optimal ist, sondern eher zufällig die größte Schärfe ohne Rauschen bietet, solange die Sample-Positionen übereinstimmen. Aber schon wenn die Samples versetzt sind (ein Pixel also "zwischen" zwei Texel fällt), ist der exakt pixel-große Boxfilter nicht mehr ideal, sondern müsste eigentlich größer sein, um Störfrequenzen wirksam fern zu halten. Bis zum bitteren Ende hab ich das allerdings auch noch nicht durchdacht ...

Wie dem auch sei: Bin schon gespannt auf deinen Artikel :)

[aths]

Original geschrieben von Kilbert
Ich denke, du denkst falsch. Aber ganz sicher bin ich mir auch nicht ;)

Egal, ob ich jetzt meine Textur rotiere, oder mein Objekt, solange der Winkel zwischen beiden fest ist, ändert sich das Verhältnis der beiden Flächen nicht. Demzufolge sollte die ideale Grenze der Mipmaplevel in einem Zylinder kreisförmig sein, da wir ja entlang der Achse schauen und alle Flächen unter dem gleichen Winkel sehen.So ähnlich war meine erste Überlegung auch. Aber man muss imo andersrum rangehen, und das Pixel in den Texturespace transformieren und sich dann auf der Textur die Pixel ansehen. Da ein Pixel kein Kreis ist, und demzufolge keinen "Durchmesser hat (bzw. der "Durchmesser" schwankt zwischen Seitenlänge a und Diagonale sqrt(2)*a) ist das LOD-Pattern eben kein Kreis.

So ganz einfach ist die LOD-Bestimmung nicht. Wenn ich mir das aufmale, hätte man bei 45°-Winkeln nämlich weniger LOD (eine geringer aufgelöste MIP) als bei 90°-Winkeln. Irgendwo ist noch ein Haken, den ich übersehe.

BTW wird durch BF und TF eigentlich immer mehr oder weniger überfiltert. Das ist wohl auch der Grund, warum 2x2 Supersampling doch ein wenig mehr Texturqualität bringt: Der Überfilterungsanteil pro finalem Pixel sinkt.
Original geschrieben von Kilbert
Eigentlich müsste man das Ganze natürlich mal auf der Signalebene mittels Samplingtheorie und Rekonstruktionsfiltern durchdenken. Genau. Texturing ist eigentlich nichts anderes, als ein Resampling einer Information. Diverse Theoreme der Filtertheorie spielen da mit rein.
Original geschrieben von Kilbert
Wie dem auch sei: Bin schon gespannt auf deinen Artikel :) Zunächst muss ich einiges schreiben, was Geld bringt. Solche Technikartikel hier sind ja leider eine brotlose Kunst. Und bislang ist es mir noch nicht gelungen, das Thema in Gänze geistig zu durchdringen.

Dass solche isotropen Filter suboptimal sind, wird dann vor allem noch im Folgeartikel "Anistrope Filterung im Detail" thematisiert. Dort will ich dann zeigen, dass man mit aufwändiger AF-Logik jede Menge Füllrate sparen könnte, ohne Qualität einzubüßen. Ganz, ganz vielleicht mache ich daraus auch meine Diplomarbeit :naughty: "Ein neues Verfahren zur anisotropen Texturfilterung" :D

[zeckensack]

Ich würde euch empfehlen, mal in die OpenGL-Spec reinzuschauen. Zu beziehen hier (PDF) (http://www.opengl.org/documentation/specs/version1.5/glspec15.pdf). Relevant dürfte hier die Sektion 3.8.8 sein :)

(ich kann leider keine vernünftigen Auszüge posten, weil da ziemlich viele griechische Buchstaben und sowas drin sind)

[Endorphine]

Original geschrieben von zeckensack
(ich kann leider keine vernünftigen Auszüge posten, weil da ziemlich viele griechische Buchstaben und sowas drin sind) Einfach mit einem Texteditor und suchen & ersetzen die griechichen Zeichen in HTML named entities umwandeln, und schon passt alles wunderbar in dieses ISO-8859-1 Forum =)

Edit: character entities Unicode: http://www.w3.org/TR/REC-html40/sgml/entities.html#h-24.3.1
named entities: http://selfhtml.teamone.de/html/referenz/zeichen.htm#benannte_griechisch

[deekey777]

One of the main features of pixel shader 3.0 is that is supports dynamic branching (also called data dependent branching), something that nVidia of course makes a big deal about. This demo however shows a way to implement dynamic branching without pixel shader 3.0, using basic graphics functionality such as alpha testing and stencil testing. Not only is it doable, but also gives every bit of the performance of real dynamic branching.
One scenario where dynamic branching comes in handy is when you have range-limited lights. Whenever a fragment is outside the range of the light, you can skip all the lighting math and just return zero immediately. With pixel shader 3.0 you'd simply implement this with an if-statement. Without pixel shader 3.0, you just move this check to another shader. This shader returns a truth value to alpha. The alpha test then kills all unlit fragments. Surviving fragments will write 1 to stencil. In the next pass you simply draw lighting as usual. The stencil test will remove any fragments that aren't tagged as lit. If the hardware performs the stencil test prior to shading you will save a lot of shading power. In fact, the shading workload is reduced to the same level of pixel shader 3.0, or in some cases even slightly below since the alpha test can do a compare that otherwise would have to be performed in the shader.
The result is that early-out speeds things up considerably. In this demo the speed-up is generally in the range of two to four times as fast than without early-out. And with more complex lighting, the gain would have been even larger.


Quelle (http://esprit.campus.luth.se/~humus/3D/index.php)