Wie shaderlastig ist eigentlich die DOOM III Engine?

[Demirug]

Da JC und seine Leute ja wohl noch ein bischen brauchen bis sie fertig sind starten ich hier mal eine kleine technische Diskusssion zum Thema DOOM III Pixelshading.

Fassen wir zuerst einmal zusammen was uns bekannt ist.

Wir wissen das der standardpfad der DOOM III Engine 6 Texturen benutzt und draus 7 unterschiedliche Samples erzeugt. 2 der Samples werden aus einer Cubemap zum normalisieren gewonnen.

Weiterhin wissen wir das die Pixel mit diffussem und spekularem Licht beleuchtet werden. Das Bumpmapping wollen wir nicht vergessen und Umgebungesreflektionen (Enviroment Mapping) haben wir ja auch schon in den veröffentlichten Videos gesehen. Zu diesem sagt JC das es normalerweise Per-Vertex durchgeführt wird auf neuer Hardware (R(V)3XX und NV3X) aber auch eine per Pixel option besteht.

Bei der neuren Hardware kann ebenfall die Cubemap für das normalisieren durch Berechnungen ersetzt werden.

Versuchen wir und nun an einer Spekulation wie sich die 6 Texturen zusammensetzten und wie diese von den Shader miteinander verrechnet werden könnten.

Texturen:
Tex1: Die Normalisierungscubemap (NormCube)
Tex2: Eine Normalmap fürs Bumpmapping (Normal)
Tex3: Eine Diffusemap für die diffuse Beleuchtung (Diffuse)
Tex4: Eine Spekualrmap für die spekulare Beleuchtung (Spekular)
Tex5: Eine Cubemap welche die Umgebung für das Enviromentmapping enthällt. (Enviroment)
Tex6. Eine Lichtmaske um Lichtquellen darzustellen welche nicht linear über ein Dreieck verlaufen. (Lightmask)

Um das ganze nun zu verechen müsste folgende Formel zum einsatz kommen:

Diffuse = (NormCube[Lichtvektor] dot Normal[]) * Diffusemap[] * Diffuselichtfarbe(nur wenn die Lichtmaske nicht die entgültige Lichtfarbe enthält)
Spekular = (NormCube[halbvektor] dot Normal[]) * Spekularmap[] * Spekularlichtfarbe(nur wenn die Lichtmaske nicht die entgültige Lichtfarbe enthält)

Licht = (Diffuse + Spekular) * Lightmask

Pixel = Licht + Enviroment[]

Das wir 7 Texturesamples (3*Cube, 4*2D) brauchen war uns ja schon bekannt. Dazu kommen dann noch zwischen 7 und 9 Rechenoperationen. Alle Rechenoperationen (dot, *, +) sowie die Texturesamples sollten problemloss jeweils in einem Takt ausfürbar sein. Damit liegt der standardpfad sehr nahe bei einem 1:1 (genauer 1:1,29) Verhältniss von Textur Anweisungen und Rechenoperationen. Da eine relative grosse Anzahl von Texturesamples (7) pro Shader gebraucht wird die Fillrate spätestens ab 1xAF (tri) bzw 2xAF(bi) zum dominierenden Faktor.

Die angesprochenen Änderungen für die neuren Karten ändern aber nun etwas das Verhältniss.

1. Normalisierungscube durch Berechnungen ersetzten.
die beiden Texturezugriffe auf den Cube müssen durch jeweils 3 Anweisungen zum normalisieren ersetzt werden. Damit verändert sich das Verhältniss auf 5:15 oder 1:3. Der Shader wird also rechenlastiger bei 2xAF(tri) bzw 4xAF(bi) bei allen 5 Texturen holt die Fillrate aber den Shader wieder ein. Da aber nicht jeder Pixel immer das volle AF bekommt könnte hier durchaus schon mal der Shader die Bremse sein.

2. Per Pixel Enviroment Mapping.
Da ich mir nicht sicher bin welches Verfahren hier JC nun genau einsetzten möchte enthalte ich mich mal weitgehend. Auf jeden Fall wird der Shader dadurch rechenlastiger. Wenn wir mal von verschwenderischen 15 Anweisungen ausgehen (was viel zu viel sein dürfte) kommen wir dadurch auf 5:30 bzw 1:6. Die Fillrate würde dann ab 4xAF (tri) bzw 8xAF (bi) dominieren. Aber wie auch schon vorher erwähnt nur wenn jeder Pixel mit vollem AF durchgefiltert würde was ja aber nicht der Fall ist.

So wie es also für mich aussieht steht die DOOM III Engine durchaus schon an der schwelle ab der die Shaderleistung eine grössere Rolle als die Fillrate übernimmt. Wir dürfen allerdings nicht übersehen das sich die überlegeungen nur auf die Lichtpasses bezogen haben. Der Z-Pass sowie die Schattenpasses sind ohne zweifle vollständig von der Fillrate dominiert.

Jeder der mehr informationen hat oder Fehler in meinen Überlegungen entdeckt hat möge sich bitte melden. Natürlich sind auch sonstige Fragen zu meiner verworren Niederschrift erwünscht.

[Kant]

Hmmm,
JC sagte zwar selbst irgendwo das er 6 Texturen verwendet, aber wenn ich mir die Liste jetzt so ansehe....
Würde es sich nicht anbieten Tex2 und Tex4 in einer Textur zusammenzufassen, also Tex4 als alpha in Tex2 abzulegen ?
Wenn ich die D3-alpha richtig in Erinnerung habe, waren specular-map, und normal-map immer in der gleichen Grösse vorhanden.

Aber was wäre dann die 6. ? ;)

[Demirug]

Original geschrieben von Kant
Hmmm,
JC sagte zwar selbst irgendwo das er 6 Texturen verwendet, aber wenn ich mir die Liste jetzt so ansehe....
Würde es sich nicht anbieten Tex2 und Tex4 in einer Textur zusammenzufassen, also Tex4 als alpha in Tex2 abzulegen ?
Wenn ich die D3-alpha richtig in Erinnerung habe, waren specular-map, und normal-map immer in der gleichen Grösse vorhanden.

Aber was wäre dann die 6. ? ;)

Das Zusammenlegen dürfte aus zwei Gründen problematisch sein. Wenn das ganze mit Multipass berechnet wird braucht man das ganze vorzugweise sowieso getrennt. Zum anderen unterstüzt die Engine AFAIK auch farbige Spekluar Highlights man bräuchte also die RGB kanäle.

[Kant]

Original geschrieben von Demirug
Das Zusammenlegen dürfte aus zwei Gründen problematisch sein. Wenn das ganze mit Multipass berechnet wird braucht man das ganze vorzugweise sowieso getrennt. Zum anderen unterstüzt die Engine AFAIK auch farbige Spekluar Highlights man bräuchte also die RGB kanäle.

Mit farbigen Specular-Effekten hätte sich die Sache natürlich erledigt, allerdings waren die entspr. Texturen der Alpha monochrom.
Ansonsten sehe ich da eigentlich keine Probleme bei Multipass...
Ganz im Gegenteil : Ich kann es mir auf Hardware mit nur 2 Texturen pro Pass kaum ohne vorstellen.. ? Oder habe ich da jetzt einen Denkfehler... ?

[Demirug]

Original geschrieben von Kant
Mit farbigen Specular-Effekten hätte sich die Sache natürlich erledigt, allerdings waren die entspr. Texturen der Alpha monochrom. Sicher? ;)

Ansonsten sehe ich da eigentlich keine Probleme bei Multipass...

Wenn man nicht beide Anteile Alpha und RGB im gleichen Pass braucht kann es durchaus etwas bringen das ganze dann auch in zwei Texturen zu speichern. Natürlich mit den entsprechenden Textureformat. So passt dann unter umständen mehr in den Texturecache. Wenn man natürlich beides in einem Pass braucht sollte man es um Texelfillrate zu sparen zusammenfassen. Da es aber AFAIK zwei RGB Texturen sind kommt das hier sowieso nicht in Frage.

Ganz im Gegenteil : Ich kann es mir auf Hardware mit nur 2 Texturen pro Pass kaum ohne vorstellen.. ? Oder habe ich da jetzt einen Denkfehler... ?

JC sagt das der NV10 den standardpfad komplett beherscht in AFAIR 5 Passes.

Technisch müsste es so ablaufen
1: FB.Alpha = (NormCube[Lichtvektor] dot Normal[])
2: FB.Color = FB.Color + FB.Alpha * (Diffusemap[] * Diffuselichtfarbe * Lightmask[])
3: FB.Alpha = (NormCube[halbvektor] dot Normal[])
4: FB.Color = FB.Color + FB.Alpha * (Spekularmap[] * Spekularlichtfarbe * Lightmask[])
5: FB.Color = FB.Color + Enviroment[]

EDIT PS: Zumindestens meint mein Shadersplitter das man die Shaderformel so zerlegen muss damit sie auf einer Hardware mit dem NV10 Profil gerechnet werden kann.

[Kant]

Original geschrieben von Demirug
Sicher? ;)

Ja ziemlich.. Ich habe mir zum Testen ein paar der netten maps für eigene Spielereien ..aehh.. "geliehen". Wo findet man schon sonst brauchbare normalmaps im optimalen Format um die eigene Engine zu testen ? ;)

Original geschrieben von Demirug

Technisch müsste es so ablaufen
1: FB.Alpha = (NormCube[Lichtvektor] dot Normal[])
2: FB.Color = FB.Color + FB.Alpha * (Diffusemap[] * Diffuselichtfarbe * Lightmask[])
3: FB.Alpha = (NormCube[halbvektor] dot Normal[])
4: FB.Color = FB.Color + FB.Alpha * (Spekularmap[] * Spekularlichtfarbe * Lightmask[])
5: FB.Color = FB.Color + Enviroment[]

Yep, mein Denkfehler war, das ich die Lightmask[] nicht einberechnet hatte. Dann hätte man einen Pass einsparen können. Mit der Mask spielt es dann keine Rolle mehr.

[micki]

das nrm auf eine gffx5900 ist langsammer als aus einer cubemap zu lesen. also wird man das nicht berechnen sondern aus der cm auslesen denk ich mir. natürlich kann sich das mit anderen treibern ändern... aber zur zeit braucht diese berechnung mehr zeit bzw. liefert wenigetr fps in meinen benches.
(hab es noch net auf meiner ATI getestet, wäre da ein unterschied zu erwarten?)

MfG
micki

[Demirug]

Original geschrieben von micki
das nrm auf eine gffx5900 ist langsammer als aus einer cubemap zu lesen. also wird man das nicht berechnen sondern aus der cm auslesen denk ich mir. natürlich kann sich das mit anderen treibern ändern... aber zur zeit braucht diese berechnung mehr zeit bzw. liefert wenigetr fps in meinen benches.
(hab es noch net auf meiner ATI getestet, wäre da ein unterschied zu erwarten?)

MfG
micki

Ist klar das es langsamer ist. ein nrm ist eine Macroanweisung für dp3, 1/sqrt, mul und braucht noch einzusätzliche Register als Zwischenspeicher. Die Sample-Anweisung ist bei den NV3X aber nur eine halb-Anweisung. Ein neuer Treiber wird ndie nrm Varianten möglicherweise zwar schneller machen können aber nicht so schnell wie die cm Version.

Bei R300 sieht es da auch nicht unbedingt besser aus. Allerdings ist dort die Sachelage komplizierter weil er ja immer noch Textur und Arithmetikanweisungen getrennt und blockweise berechnet. Wenn dein Shader dependent reads hat ist eine Vorhersage besonders kompliziert. Ohne dependet Reads ist es relative einfach. Zähle die Texture und Arithmetikanweisungen Anweisungen. Die grössere Zahl bestimmt die Geschwindigkeit. Pixel/s = (Anzahl der Pipelines * Takt)/Max (Textur-Anweisungen, Arithemetik-Anweisungen). Läuft die Sache schneller hat der Treiber ein paar Anweisungen entfernt oder zusammengeschoben (Paarweises Ausführen von Vec3 und Skalar Ops).

Wenn du also derzeit einen 1:1 Shader hast (Ideal für alls R(V)3XX Chips) und die cm durch einen nrm ersetzt verschiebt sich das ganze.

Beispiel:

5Tex:5Arithmetik mit cm = 8*380/Max(5,5) = 608
4Tex:8Arithmetik mit nrm = 8*380/Max(4,8) = 380

Ich würde die Rechnung auch mit den NV3X Chips machen allerdings ist da schon die normale Formel dermassen kompliziert (und kann sich mit jedem neuen Treiber ändert) das ich das lieber lasse. Die stark vereinfachte Formel wäre:

Bei PS 2.0 und 2.X unter DX9:

CineFX I: Anzahl der Pixel/Takt * Takt / (Tex/2)+Arithemtik
CineFX II: Anzahl der Pixel/Takt * Takt*2 / (Tex/2)+Arithemtik

Um also unser Beispiel von oben doch nochmal zu nehmen:

5800U 4*500 / (5/2)+5 = 266,66
4*500 / (4/2)+8 = 200,00

5900U 4*450*2 / (5/2)+5 = 480
4*450*2 / (4/2)+8 = 360

Bei den NV3X Chips kommt aber noch ein von der Anzahl und der Registergrösse abhängiger Overhead dazu. Der Treiber könnte aber wohl durchaus durch entfernen und Zusammenlegen von Anweisungen noch etwas herausholen.

Benutzt man die OpenGL Extension von nv sieht das alles aber schon ganz anders aus. Aber die Formel ist noch komplizierter weil sich da die Datenformate direkt auf die Rechenleistung auswirken.

EDIT: PS: Ich habe nochmal nachgeschaut. Die NV3X Chips sollten in der Lage sein einen nrm in 2 Takten zu berechnen weil sich 1/sqrt und mul dort zusammenfassen lassen sollten.

5800U: 4*500 / (4/2)+7 = 222,22
5900U 4*450*2 / (4/2)+7 = 400

[micki]

Original geschrieben von Demirug
Ist klar das es langsamer ist.

so klar ist das nicht, laut dx doc müßte nrm 3 zyklen und texld von einer cm 4 zyklen brauchen.

sicher ist das hardware und nicht sdk abhängig, aber klar ist sowat lange net :)

hmm... aber ich werde wohl das nrm in meinem shader-script präprozessor durch das cubemapladen ersetzen, wieso macht des der treiber nicht automatisch falls eine texture frei ist?

MfG
micki

[Demirug]

Original geschrieben von micki
so klar ist das nicht, laut dx doc müßte nrm 3 zyklen und texld von einer cm 4 zyklen brauchen.

sicher ist das hardware und nicht sdk abhängig, aber klar ist sowat lange net :)

Instructionsslots != Takte und Texturenaweisungen != Arithemetikanweisungen. Ist schon immer so und bei jedem Chip etwas anders. Ich hätte das aber nicht stillschweigend vorraussetzten sollen.

hmm... aber ich werde wohl das nrm in meinem shader-script präprozessor durch das cubemapladen ersetzen, wieso macht des der treiber nicht automatisch falls eine texture frei ist?

MfG
micki

Wenn der Treiber sowas macht gibt es Terrormails von mir. Wenn ich das gerechnet haben will dann soll der Chip auch rechnen. Die Cubemap erreicht nun mal nicht die Genauigkeit.

[micki]

jetzt wissen wir wenigstens wer die würmer gemacht hat ;)

ich finde, dass bei gamerkarten es tollerierbar sein sollte, wenn die mal ungenauigkeiten haben für performance

vielleicht sollte das einstellbar sein.


MfG
micki

[Demirug]

Original geschrieben von micki
jetzt wissen wir wenigstens wer die würmer gemacht hat ;)

Nein die waren zu schlampig die hätte ich nie durch die QC bekommen.


Ich finde, dass bei gamerkarten es tollerierbar sein sollte, wenn die mal ungenauigkeiten haben für performance

vielleicht sollte das einstellbar sein.


MfG
micki

Wenn man es einstellen kann bin ich bei dir. Wobei man ja Fillrate und Bandbreite gegen Rechenleistung tauscht und umgekehrt.

[zeckensack]

Demi,
deine Ausführungen in Ehren, aber du vergißt die brachiale Füllrate, die Doom III verbraucht. Shaderlastig sind die Lichtpasses sicherlich, aber die Engine als ganzes IMO eher nicht.

Dann sollte man vielleicht noch erwähnen, daß der R300 doppelt soviel Texturcache hat wie *hust*, und ihn auch bei komprimierten Texturen voll nutzen kann, im Gegensatz zu *hust*. Bei 6 gleichzeitig gebundenen Texturen ist das IMO sehr wichtig, und arbeitet womöglich gegen deine Analyse der Licht-Passes. Spaßfrage: gibt's bei Texturcaches eigentlich so etwas wie Assoziativität?

Es ist nicht besonders leicht, hier schon die Flaschenhälse identifizieren zu wollen. So interessant Doom III technisch sein mag, solche Voraussagen bewegen sich auf dünnem Eis.

[Demirug]

Original geschrieben von zeckensack
Demi,
deine Ausführungen in Ehren, aber du vergißt die brachiale Füllrate, die Doom III verbraucht. Shaderlastig sind die Lichtpasses sicherlich, aber die Engine als ganzes IMO eher nicht.

Habe ich doch geschrieben:

"Wir dürfen allerdings nicht übersehen das sich die überlegeungen nur auf die Lichtpasses bezogen haben. Der Z-Pass sowie die Schattenpasses sind ohne zweifle vollständig von der Fillrate dominiert."

Dann sollte man vielleicht noch erwähnen, daß der R300 doppelt soviel Texturcache hat wie *hust*, und ihn auch bei komprimierten Texturen voll nutzen kann, im Gegensatz zu *hust*. Bei 6 gleichzeitig gebundenen Texturen ist das IMO sehr wichtig, und arbeitet womöglich gegen deine Analyse der Licht-Passes. Spaßfrage: gibt's bei Texturcaches eigentlich so etwas wie Assoziativität?

Du weist aber auch das *hust* beim sample anders vorgeht als der R300? Was durchaus einen kleineren Cache rechtfertigen kann. Zudem gibt es ja bei nVidia immer noch dieses Gerücht das es im Speicherkontroller einen universal Cache gibt den man für alles nutzen kann. Ich nehme mal an das Archmark mit einem Texturlayer misst und die Textur solange vergrössert bis bis es zum Abfall kommt?

Es ist nicht besonders leicht, hier schon die Flaschenhälse identifizieren zu wollen. So interessant Doom III technisch sein mag, solche Voraussagen bewegen sich auf dünnem Eis.

Es ging mir ja auch gar nicht um Flaschenhälse(die sind sowieso bei jedem Chip anders) sondern eher darum in wie weit man nun DOOM III als Beispiel für eine Shaderlastige Anwendung heranziehen darf.

[zeckensack]

Original geschrieben von Demirug
Habe ich doch geschrieben:

"Wir dürfen allerdings nicht übersehen das sich die überlegeungen nur auf die Lichtpasses bezogen haben. Der Z-Pass sowie die Schattenpasses sind ohne zweifle vollständig von der Fillrate dominiert."Ja, hast du. Aber auch das:
"So wie es also für mich aussieht steht die DOOM III Engine durchaus schon an der schwelle ab der die Shaderleistung eine grössere Rolle als die Fillrate übernimmt."

Irgendwie ein klitzekleiner Widerspruch in sich, IMO :)

Du weist aber auch das *hust* beim sample anders vorgeht als der R300? Was durchaus einen kleineren Cache rechtfertigen kann.Ich wüßte nicht wie. R300 macht einen Sampling-'Block', NV30 eigentlich auch, nur mit kleinerer Granularität (2x vs 4x?).
Die Position der Sampler ändert aber nichts daran, daß der Texturcache zu klein ist. Dazu schreibe ich gleich nochwas, Moment bitte.

Zudem gibt es ja bei nVidia immer noch dieses Gerücht das es im Speicherkontroller einen universal Cache gibt den man für alles nutzen kann. Ich nehme mal an das Archmark mit einem Texturlayer misst und die Textur solange vergrössert bis bis es zum Abfall kommt?Von einem Universal-Cache habe ich bisher nichts gemerkt, und diese Gerüchte sind wesentlich älter als meine Geforce 3 ...
AM benutzt Singletexturing mit bilinear gefilterten Mipmaps. Ich kann später mal das Readme online stellen, dann kann ich dir die Methodik verlinken. Hart nach 'Textureinheit' partitionierte Caches sind damit nicht messbar, ebenso wird ein eventuelles Readport-Limit nicht aufgedeckt. Letzteres ist auch nicht besonders praktikabel, weil das Sampling auf mehrere Takte verteilt wird. Ersteres läuft bei mir unter "Optimierungen die die Welt nicht braucht und auch nicht haben will".

Es ging mir ja auch gar nicht um Flaschenhälse(die sind sowieso bei jedem Chip anders) sondern eher darum in wie weit man nun DOOM III als Beispiel für eine Shaderlastige Anwendung heranziehen darf. Shaderlastige Anwendung? Siehste!? ?-)

[Demirug]

Original geschrieben von zeckensack
Ja, hast du. Aber auch das:
"So wie es also für mich aussieht steht die DOOM III Engine durchaus schon an der schwelle ab der die Shaderleistung eine grössere Rolle als die Fillrate übernimmt."

Irgendwie ein klitzekleiner Widerspruch in sich, IMO :)

Ja, ist etwas missverständlich geschrieben.

[zeckensack]

Stufe 1:
Die Anwesenheit eines minimalen Texturcaches (ca 4~8 Texel pro Textureinheit) kann bereits dafür sorgen, daß pro Sample nur ein bis maximal zwei Texel aus dem externen Speicher gelesen werden müssen. Dadurch werden Mipmapping-Filter quasi bandbreitenfrei (nicht wirklich frei, aber sie werden auf das gleiche Niveau gedrückt wie point sampling). Feine Sache.

Stufe 2:
Wenn der Cache groß genug ist, daß eine komplette 'Scanline' hineinpasst, werden Textur-Repeats auf großen Dreiecken bandbreitenfrei. NV2x/3x rechnen bearbeiten aber immer zusammenhängende 2x2-Blöcke, dadurch wird die länger der vorhaltbaren Scanline halbiert. Bei RGB565 sind's maximal 1024 Texelx2, IMO ganz passabel, wenn auch nicht unbedingt tauglich für konsequentes Multitexturing. DXT1 erhöht die Blockgröße auf 4x4, dann sind wir bei 512x4 Texel. Bei DXT5 sind's gerade noch 256x4 Texel. Bei vernünftig implementierter Dekompression wäre das vierfache möglich.

Stufe 3:
Wenn ein komplettes Mipmap-Level in den Cache passt, dann wird Texturierung weiter entfernter, ganzer Objekte mit ~gleichem Textur-LOD bandbreitenfrei. Das wird bei Singletexturing ab ca 4kiB interessant (32x32xRGB565 und alle kleineren Levels passen).

Stufe 4:
Wenn komplette Mipmaps passen, dann macht's richtig Freude. Kein aktueller Chip kann diese Stufe erreichen. Dafür braucht's schon mindestens 128kiB, eher deutlich mehr.


NV2x/3x erreichen praktisch mit den Texturanforderungen nur Stufe 1. Sechs Texturen wollen gelesen werden, einige davon gut komprimierbar, andere eher nicht. Texturkompression senkt bei NV nur die externe Bandbreite, erhöht im Umkehrzug aber die Last auf den Texturcache, womit wieder mehr externe Bandbreite gebraucht wird.
R300 kann bei komprimierten Texturen das achtfache an Texeln vorhalten, bei unkomprimierten das doppelte.
Ich freue mich schon auf Benchmarks Radeon 9500Pro vs FX5800 ...

[Demirug]

nVidia arbeitet nach einem Sensepoint Verfahren was vom normalen Scanline Verfahren sehr weit weg ist und wesentlich Cachefreundlicher dazu.

Zu den Sampleblöcken. nVidia arbeitet primär nach dem Prinzip viele Pixel aus jeweils 2 Texturen. ATI benutzt eher das Verfahren wenige Pixel aus viele Texturen. Was nun jeweils besser ist dürfte aber wohl sehr von der Situation abhängen.

[zeckensack]

Original geschrieben von Demirug
nVidia arbeitet nach einem Sensepoint Verfahren was vom normalen Scanline Verfahren sehr weit weg ist und wesentlich Cachefreundlicher dazu.Pures Texel-Scanline ist auch ein bisserl dämlich, die 'waagerechte Linie' sollte natürlich im Screen space liegen, und ist in der Textur dann rotiert. Weitere Entropie-Geschichten sind auch nicht zu verachten, vor allem müssen die Blöcke in der Reihenfolge nachgeladen werden, in denen der Rasterizer die Fragmente erzeugt. Stufe 1 ist trotzdem unter kontrollierten Umständen erreichbar ... :naughty:

Zu den Sampleblöcken. nVidia arbeitet primär nach dem Prinzip viele Pixel aus jeweils 2 Texturen. ATI benutzt eher das Verfahren wenige Pixel aus viele Texturen. Was nun jeweils besser ist dürfte aber wohl sehr von der Situation abhängen. Wie gesagt, ich bin gespannt auf Benches von Bandbreiten-limitierten Karten. 9700/9800/5900 haben so viel Bandbreite, daß dort nicht viel interessantes passieren wird.

[Demirug]

Original geschrieben von zeckensack
Pures Texel-Scanline ist auch ein bisserl dämlich, die 'waagerechte Linie' sollte natürlich im Screen space liegen, und ist in der Textur dann rotiert. Weitere Entropie-Geschichten sind auch nicht zu verachten, vor allem müssen die Blöcke in der Reihenfolge nachgeladen werden, in denen der Rasterizer die Fragmente erzeugt. Stufe 1 ist trotzdem unter kontrollierten Umständen erreichbar ... :naughty:

3D-Labs scheint noch mit Scanlines zu arbeiten. Zumindestens haben sie ein Patent angemeldet welches die Effektivität eines Texturecaches steigern soll wenn man im Rasterisirer Scan-Lines benutzt.

Die TMUs in den nv Chips müssen nicht zwangsläufig in der gleichen Rheienfolge die Samples abarbeiten wie sie von Rasterizirer kommen. Spätestens seit NV25 ist dafür entsprechende Technik implementiert.

[PCGH_Thilo]

Original geschrieben von zeckensack
Stufe 1:
Die Anwesenheit eines minimalen Texturcaches (ca 4~8 Texel pro Textureinheit) kann bereits dafür sorgen, daß pro Sample nur ein bis maximal zwei Texel aus dem externen Speicher gelesen werden müssen. Dadurch werden Mipmapping-Filter quasi bandbreitenfrei (nicht wirklich frei, aber sie werden auf das gleiche Niveau gedrückt wie point sampling). Feine Sache.

Stufe 2:
Wenn der Cache groß genug ist, daß eine komplette 'Scanline' hineinpasst, werden Textur-Repeats auf großen Dreiecken bandbreitenfrei. NV2x/3x rechnen bearbeiten aber immer zusammenhängende 2x2-Blöcke, dadurch wird die länger der vorhaltbaren Scanline halbiert. Bei RGB565 sind's maximal 1024 Texelx2, IMO ganz passabel, wenn auch nicht unbedingt tauglich für konsequentes Multitexturing. DXT1 erhöht die Blockgröße auf 4x4, dann sind wir bei 512x4 Texel. Bei DXT5 sind's gerade noch 256x4 Texel. Bei vernünftig implementierter Dekompression wäre das vierfache möglich.

Stufe 3:
Wenn ein komplettes Mipmap-Level in den Cache passt, dann wird Texturierung weiter entfernter, ganzer Objekte mit ~gleichem Textur-LOD bandbreitenfrei. Das wird bei Singletexturing ab ca 4kiB interessant (32x32xRGB565 und alle kleineren Levels passen).

Stufe 4:
Wenn komplette Mipmaps passen, dann macht's richtig Freude. Kein aktueller Chip kann diese Stufe erreichen. Dafür braucht's schon mindestens 128kiB, eher deutlich mehr.


NV2x/3x erreichen praktisch mit den Texturanforderungen nur Stufe 1. Sechs Texturen wollen gelesen werden, einige davon gut komprimierbar, andere eher nicht. Texturkompression senkt bei NV nur die externe Bandbreite, erhöht im Umkehrzug aber die Last auf den Texturcache, womit wieder mehr externe Bandbreite gebraucht wird.
R300 kann bei komprimierten Texturen das achtfache an Texeln vorhalten, bei unkomprimierten das doppelte.
Ich freue mich schon auf Benchmarks Radeon 9500Pro vs FX5800 ...

*gebetsteppich richtung zecki & demi ausricht*