Funktion der Early Z Units...

[aths]

Ich bin ja Anhänger der nggalaischen These, dass die 4 Z-Test-Units für die 4 AA-Samples den Early Z Test machen. Bei nVidia (http://www.nvidia.com/view.asp?IO=feature_lmaii) findet sich folgende Bemerkung:
A visibility subsystem:
Determines whether or a not a pixel will be visible in a scene. If it determines a pixel will not be visible, the pixel is not rendered, saving valuable frame buffer bandwidth.
Die sprechen also von gesparter Bandbreite, nicht von gesparter Füllrate.

Meine Frage ist nun: Untermauert dieses Marketing-Blabla die Vermutung, dass Early Z nicht im Triangle Setup gemacht wird, sondern eben die AA-Z-Test-Units dafür eingesetzt werden? Oder sind Triangle Setup und Pipeline bereits soweit mit einem Cache entkoppelt, dass sich da keine exakte Zuordnung mehr treffen lässt?

[Demirug]

Originally posted by aths
Ich bin ja Anhänger der nggalaischen These, dass die 4 Z-Test-Units für die 4 AA-Samples den Early Z Test machen. Bei nVidia (http://www.nvidia.com/view.asp?IO=feature_lmaii) findet sich folgende Bemerkung:
Die sprechen also von gesparter Bandbreite, nicht von gesparter Füllrate.

Meine Frage ist nun: Untermauert dieses Marketing-Blabla die Vermutung, dass Early Z nicht im Triangle Setup gemacht wird, sondern eben die AA-Z-Test-Units dafür eingesetzt werden? Oder sind Triangle Setup und Pipeline bereits soweit mit einem Cache entkoppelt, dass sich da keine exakte Zuordnung mehr treffen lässt?

Der Satz sagt nicht wirklich viel aus weil:

"Determines whether or a not a pixel will be visible in a scene" Das ist ja die Aufgabe des Z-Tests egal an welcher stelle er durchgeführt wird.

"If it determines a pixel will not be visible, the pixel is not rendered" Das sagt nun aus das der Test durchgeführt wird bevor man die Pixelfarbe bestimmt über den Ort der Prüfung kann man allerdings nur sagen vor dem Pixelshader.

"the pixel is not rendered, saving valuable frame buffer bandwidth" Das ist wieder ein Wischiwaschi Satz weil das auf jede Art des Z-Buffer Test zutrifft. Den ein damit verworfener Pixel wird nicht geschrieben.

[Demirug]

Es gibt aber ja auch aussage die etwas mehr Substanz habe:

http://www.extremetech.com/article2/0,3973,36882,00.asp

Although not entirely new to GF4, this part has an improved Z culling sub-system which is part of the visibility sub-system that also helps recover bandwidth and fill rate. Dave Kirk put it this way, "If you compress your memory transactions and make your memory granularity more efficient, that's basically free bandwidth. The same holds true for occlusion culling. Every percentage point you can increase your efficiency of culling, is free fill rate in a real application. There's a lot of improvement in these areas in NV25."

In addition to getting rid of non-visible pixels early and avoiding unnecessary rendering work on them, the new Z culling technology brings with it an additional bandwidth savings. Again, Dave Kirk:

"NV20 Z-Cull had culling information that was maintained in the frame buffer, and had to be continually read and updated. There are some observations about occlusion culling that allow us to read information less often. If you remember a little bit more as data is going by, you don't have to actually access the structure that keeps track of things. The other piece of it is that if you can cull things that are not visible, you can also trivially accept things that you know are in front, so you don't have to do the Z comparison later."


Because Z comparisons are an expensive memory operation (read/modify/write), each one you eliminate recovers bandwidth and fill-rate that would otherwise be wasted. The other upside to this approach is that once a pixel has been trivially accepted, it's only written to the Z and color buffers once, and since no additional compares or changes will occur, you've eliminated all unnecessary reads and modify-writes for that pixel in that particular frame of animation. One of the key rules of 3D performance is, don't do anything you don't have to.

Man erkennt das Kirk sehr viel Wert darauf legt das man mit dem Z-Culling Speicherbandbreite sparen kann. Einen möglichen Hinweis das das man das Culling vor dem Pipelines macht kann man aber nur an zwei stellen erkennen und beide sind nicht unbedingt als wasserfest zu bezeichnen.

"Every percentage point you can increase your efficiency of culling, is free fill rate in a real application" Scheint eher eine theoretische aussage zu sein.

"The other piece of it is that if you can cull things that are not visible, you can also trivially accept things that you know are in front, so you don't have to do the Z comparison later." Auch etwas problematisch, da hier nur steht das man den Z-Test teilweise durch einen triviale Test ersetzten kann. Da dieser Test nicht auf die Z-Werte des Pixel/AA-Sample angewissen ist könnte er früher in der Pipeline durchgeführt werden wie weit aber Pixel die durch den trivialen Test verworfen werden in der Pipeline laufen bevor sie entgültig entfernt werden kann man nicht sagen.

[zeckensack]

Originally posted by Demirug
"The other piece of it is that if you can cull things that are not visible, you can also trivially accept things that you know are in front, so you don't have to do the Z comparison later." Auch etwas problematisch, da hier nur steht das man den Z-Test teilweise durch einen triviale Test ersetzten kann. Da dieser Test nicht auf die Z-Werte des Pixel/AA-Sample angewissen ist könnte er früher in der Pipeline durchgeführt werden wie weit aber Pixel die durch den trivialen Test verworfen werden in der Pipeline laufen bevor sie entgültig entfernt werden kann man nicht sagen. Widerspruch!

IMO bedeutet 'trivially accept' lediglich, daß man zB beim 'üblichen' less-or-equal-Test auch bei aktiviertem Z-Test auf den Lesezugriff verzichten kann, wenn Fragmente reinkommen, die einen Z-Wert von 0 haben.

Egal was im Z-Buffer steht, 0 ist immer kleiner oder gleich :)
Deswegen auch "trivially accept <...>".

edit: Satzkrampf

[Xmas]

Ich versteh nicht ganz was "im Triangle Setup" hier meinen soll. Hierarchical Z (was ATI schon lange und nun auch NVidia nutzt) wird angewendet, nachdem das Dreieck vom Tri-Setup in Tiles zerlegt wurde, und verwirft auch ganze Tiles/Subtiles. Early Z prüft danach Pixel für Pixel (oder Sample) auf Sichtbarkeit, und nur die sichtbaren werden auch berechnet. Die nicht berechneten kosten keine Füllrate.

[Demirug]

zeckensack, die Frage dabei ist nur wie viele Pixel (AA-Sample) haben in einer durchschnittlichen Szene eine Z-Wert von 0? HUD, Konsolen und sowas zählt nicht da diese in der Regel ohne Z-Test gerendert werden. Da dürfte kaum was hängen bleiben und lohnt es sich für diesen ausgesprochen seltenen Fall wirklich extra Logik einzubauen?

Xmas, wenn man von der vereinfachten Renderpipeline (Vertex-TriSetup-Pixel) ausgeht wird jeder Piel der niemals die Pixelpipeline erreicht schon im Trisetup entfernt. Nach dieser Definition wäre also Hierarchical Z eine Methode die Pixel im Trisetup entfernt.

[Xmas]

Originally posted by Demirug
Xmas, wenn man von der vereinfachten Renderpipeline (Vertex-TriSetup-Pixel) ausgeht wird jeder Piel der niemals die Pixelpipeline erreicht schon im Trisetup entfernt. Nach dieser Definition wäre also Hierarchical Z eine Methode die Pixel im Trisetup entfernt.
Nach dieser Definition ist auch Early Z á la NVidia "im Trisetup".

[Demirug]

Originally posted by Xmas

Nach dieser Definition ist auch Early Z á la NVidia "im Trisetup".

Das ist ja die Frage. Wenn die Prüfung pro Pixel/AA-Sample gemacht wird dann kann man eigentlich nicht mehr von einer Prüfung im Trisetup sprechen. In der vereinfachten Pipeline entspricht Pixel nicht Pixelshader. Die Pixelpipeline beginnt an der Stelle an der die Daten pro Pixel vorliegen. aths geht ja davon aus das lediglich die 4 Z-Tests der AA-Sample vorgezogen werden was ja eine Prüfung in der Pixelpipeline wäre.

[Xmas]

Originally posted by Demirug
Das ist ja die Frage. Wenn die Prüfung pro Pixel/AA-Sample gemacht wird dann kann man eigentlich nicht mehr von einer Prüfung im Trisetup sprechen. In der vereinfachten Pipeline entspricht Pixel nicht Pixelshader. Die Pixelpipeline beginnt an der Stelle an der die Daten pro Pixel vorliegen. aths geht ja davon aus das lediglich die 4 Z-Tests der AA-Sample vorgezogen werden was ja eine Prüfung in der Pixelpipeline wäre.
Natürlich erfolgt der Test pro Pixel, aber ein Pixel der vom Early-Z verworfen wird belegt nicht den PS, kostet also auch keine Füllrate sofern der PS dadurch nicht leerläuft.

[Demirug]

Originally posted by Xmas

Natürlich erfolgt der Test pro Pixel, aber ein Pixel der vom Early-Z verworfen wird belegt nicht den PS, kostet also auch keine Füllrate sofern der PS dadurch nicht leerläuft.

Ja so sehe ich das auch. Early-Z dürfte demnach aber nur dann etwas bringen (Im Bezug auf die Fillrate) wenn der Pixelshader mehr als 2 biSample oder 2 Register-Combiner braucht. Wobei es NVIDIA ja scheinbar mehr darum ging Bandbreite einzusparen.

[Xmas]

Originally posted by Demirug


Ja so sehe ich das auch. Early-Z dürfte demnach aber nur dann etwas bringen (Im Bezug auf die Fillrate) wenn der Pixelshader mehr als 2 biSample oder 2 Register-Combiner braucht. Wobei es NVIDIA ja scheinbar mehr darum ging Bandbreite einzusparen.
Nö, deswegen gibt es doch insgesamt 16 Z-Check-Units, so dass die Pipelines auch dann ausgelastet sind wenn ein paar Pixel verworfen werden.

[aths]

Originally posted by Xmas
Nö, deswegen gibt es doch insgesamt 16 Z-Check-Units, so dass die Pipelines auch dann ausgelastet sind wenn ein paar Pixel verworfen werden. Diese 16 Units sind afaik fest auf die 4 Pipelines verteilt, so dass jede Pipeline 4 Z-Test-Units hat. Ohne FSAA können durch aus ein paar Pixel verworfen werden, und die Pipeline bleibt ausgelastet. Mit 4x FSAA würde dann reineweg nur noch Bandbreite gespart, pro Pixel wäre hier immer mindestens 1 Takt erforderlich.

[Demirug]

Das Tri-Setup kann pro Takt 4 Pixelshaderinputs und 16 Z-Werte erzeugen. Ohne FSAA könnte man also rein theoretisch 16 Z-Werte prüfen aber für welche 4 Pixel soll man die Daten erzeugen?

Rein Schaltungstechnisch wäre es sicher möglich die Z-Test Einheiten so zu verschalten das sie dann Rückwirkung auf das Trisetup haben. Aber einfach ist das nicht. Deswegen gehe ich da durchaus mit aths konform das ohne AA nur 4 der 16 Einheiten zum Einsatz kommen. Ausser die Einheiten sind Schaltungstechnisch direkt im Trisetup verankert.

wobei das mit dem sparen der reinen Bandbreite nicht ganz stimmt. Wenn ein Pixel nicht in einem Takt berechenbar ist ergibt sich auch ein Fillrate gewinn. Das läst sich aber Testen. Einfach einen Fillratetest schreiben der Front to Back rendert und dabei 4 tri Texturen aufträgt.

[Xmas]

Originally posted by Demirug
Das Tri-Setup kann pro Takt 4 Pixelshaderinputs und 16 Z-Werte erzeugen. Ohne FSAA könnte man also rein theoretisch 16 Z-Werte prüfen aber für welche 4 Pixel soll man die Daten erzeugen?

Rein Schaltungstechnisch wäre es sicher möglich die Z-Test Einheiten so zu verschalten das sie dann Rückwirkung auf das Trisetup haben. Aber einfach ist das nicht. Deswegen gehe ich da durchaus mit aths konform das ohne AA nur 4 der 16 Einheiten zum Einsatz kommen. Ausser die Einheiten sind Schaltungstechnisch direkt im Trisetup verankert.
Das glaube ich nicht. Ich bin mir sicher dass Early-Z auch beim Single-Texturing Füllrate spart. Und IIRC hat NVidia auch irgendwo erwähnt dass das Early-Z 16 Pixel pro Takt verwerfen kann.

[aths]

Originally posted by Xmas
Das glaube ich nicht. Ich bin mir sicher dass Early-Z auch beim Single-Texturing Füllrate spart. Und IIRC hat NVidia auch irgendwo erwähnt dass das Early-Z 16 Pixel pro Takt verwerfen kann. Bei 4 Pipelines stimmt das ja auch :)

16 Pixel pro Pipeline zu verwerfen kann afaik nur R200+.

[Demirug]

Ich glaube so kommen wir nicht weiter. Wenn ich morgen etwas Zeit finde schreibe ich ein kleines Testprogramm.

Wer stellt seine GF4 zur Verfügung?

[aths]

Originally posted by Demirug
Wer stellt seine GF4 zur Verfügung? *Meld* :D

[Xmas]

Originally posted by aths
Bei 4 Pipelines stimmt das ja auch :)

16 Pixel pro Pipeline zu verwerfen kann afaik nur R200+.
?
Ich habe doch gar nicht von 16 Z-Checks pro Pipeline geschrieben.

Und von 16Pixel/Pipeline bei R200+ hab ich noch nix gehört. Nur dass da Hierarchical Z 64Pixel pro Takt (8x8 Tiles, Pipeline-unabhängig) verwerfen kann.

[aths]

Originally posted by Xmas
Ich habe doch gar nicht von 16 Z-Checks pro Pipeline geschrieben.Insgesamt 16 Tests pro Takt ist kein Widerspruch zu meiner "Arbeits-These", dass jede Pipeline 4 Herr über 4 Units ist. (Allerdings auch keine Bestätigung.)
Originally posted by Xmas
Und von 16Pixel/Pipeline bei R200+ hab ich noch nix gehört. Nur dass da Hierarchical Z 64Pixel pro Takt (8x8 Tiles, Pipeline-unabhängig) verwerfen kann. Habe ich vielleicht in den falschen Hals gekriegt.

[Xmas]

Originally posted by aths
Insgesamt 16 Tests pro Takt ist kein Widerspruch zu meiner "Arbeits-These", dass jede Pipeline 4 Herr über 4 Units ist. (Allerdings auch keine Bestätigung.)
Ich nehme ja auch an, dass jeweils 4 Z-Units zu einer Pipeline "gehören". Nur Demirug meint ja dass ohne AA nur 4 dieser Einheiten genutzt werden.

[aths]

Originally posted by Xmas
Ich nehme ja auch an, dass jeweils 4 Z-Units zu einer Pipeline "gehören". Nur Demirug meint ja dass ohne AA nur 4 dieser Einheiten genutzt werden. Hm, genau das meine ich ja eben nicht. Imo werden bei 2x AA 2 Pixel pro Takt und Pipeline getestet, und bei 4x AA nur noch 1 Pixel.

[Demirug]

Testprogramm ist fertig

http://free.fchost.us/demirug/ZOverdraw.zip

Overdraw von 1 bis 200 frei wählbar. Overdraw ist die Anzahl der Rechtecke die gerendert werden.

Anzahl der Texturen/Pass von 0 bis 8 wählbar. Limit ist allerdings die benutzte Grafikkarte.

Front to Back oder Back To Front.

Window oder Fullscreen Modus.

AA-Support.

Edit: Download geändert

[ow]

.

[aths]

"Dieser Ordner ist momentan leer."

??

[Demirug]

Ich arbeite gerade an dem Problem. Die Datei ist dort wird nur irgendwie nicht angezeigt.

[aths]

Originally posted by Demirug
Ich arbeite gerade an dem Problem. Die Datei ist dort wird nur irgendwie nicht angezeigt. Sende es zur Not mir per Mail und ich stelle es dann online :D

[aths]

(Posting ist obsolet)

[aths]

Hö? Ich habe nur 400 MP Füllrate?

[Demirug]

Mit welchen Einstellungen?

PS: Mein Download geht jetzt auch

[aths]

Originally posted by Demirug
Mit welchen Einstellungen?1152x854 Fullscreen No AA, 1 Textur

Jetzt hab ich sogar nur 100 MP... seltsam...

... und nun hab ich wieder 400 MP :rolleyes:

[ow]

.

[Demirug]

Originally posted by aths
1152x854 Fullscreen No AA, 1 Textur

Und Overdraw 1???

Falls ja sind die 400 gar nicht so schlecht. Die GF2 MX die ich hier im Officerechner habe kommt gerade mal auf 75. Das hängt damit zusammen das bei nur 2 Dreiecken pro Frame der Overhead für den Frame recht hoch ist. Erhöhe einfach mal den Overdraw (+).

[ow]

.

[Demirug]

Originally posted by ow


Also meine macht 150 (Takt 200/200) wie du oben siehst. Overdraw 1.

Ich habe hier nur eine mit SDR-RAM. Deine dürfte DDR-RAM haben, oder?

PS: Textur auf 0 macht auch was. Dabei wird dann nur die Vertex Color benutzt.

[ow]

.

[aths]

Demirug, bau doch mal bitte eine zusätzliche Anzeige ein, welche die MP und MT der letzten 16 Sekunden mittelt, damit man nicht mehr solche Schwankungen hat.

[ow]

.

[aths]

Originally posted by ow
Also bei mir schwankt da praktisch nix. Bei hohem Overdraw schwankt´s ein wenig, aber nur um etwa 2-3%. Nicht der Rede wert. Eine Messung über 16 Sekunden ist 4x genauer als über 1 Sekunde, und ich möchte schon recht genaue Zahlen haben.

[Quasar]

Vielleicht können wir uns auf Standard-Settings zum testen einigen?

[aths]

Originally posted by Quasar
Vielleicht können wir uns auf Standard-Settings zum testen einigen? Vorschlag: 64x Overdraw, 2 Texturen, 1024x768 Fullscreen?

[Quasar]

Von mir aus gern. Obwohl ich 64fach ein wenig viel fände, aber es streicht die Unterschiede sicher besser heraus, als wenn man realitätsnähere Werte von 8 oder 16 nähme. :)

Inkl. stark schwankenden Werten komme ich auf gemittelte 500Mpix und ein knappes GigaTex/s mit R9000Pro.

[aths]

Originally posted by Quasar
Inkl. stark schwankenden Werten komme ich auf gemittelte 500Mpix und ein knappes GigaTex/s mit R9000Pro. Ich hoffe, dass Demi meine Bitte nach einer "geglätteten" Ausgabe erhört :) damit wir mal genaue Zahlen haben. Anders macht imo eine Testreihe mit unterschiedlichem RAM-Geschwindigkeiten keinen Sinn.

[Demirug]

Originally posted by aths
Ich hoffe, dass Demi meine Bitte nach einer "geglätteten" Ausgabe erhört :) damit wir mal genaue Zahlen haben. Anders macht imo eine Testreihe mit unterschiedlichem RAM-Geschwindigkeiten keinen Sinn.

Ja ist schon in Arbeit. Eine zusätzliche Zeile mit den Daten gemittelt über 16 Sekunden. Ändern der Einstellungen setzt den Zähler zurück. Nach 4 Sekunden gibt es den ersten Mittelwert.

Zudem erhöhe ich noch die Priorität des Programms.

[Xmas]

GF3Ti200 @ 175MHz, 1024x768x32 Fullscreen, NoAA, NoAF, VSync off, 64x Overdraw, 2 Texturlayer
Back To Front: 679 MPix/s
Front To Back: 2572 MPix/s

Ist IMHO eindeutig, dass 16 Pixel pro Takt verworfen werden können.

[Xmas]

:D

[aths]

Originally posted by Xmas
Ist IMHO eindeutig, dass 16 Pixel pro Takt verworfen werden können. Die Frage ist, ob 4 pro Pipeline oder 16 insgesamt :) Mit AA wirds ja erst richtig interessant...

[aths]

Originally posted by Demirug
Zudem erhöhe ich noch die Priorität des Programms. Bitte nicht "realtime".

[Demirug]

Originally posted by aths
Bitte nicht "realtime".

Natürlich nicht realtime.

Aber knapp darunter. Die Maus geht aber noch ohne Probleme. :D

EDIT: Da ist es http://free.fchost.us/demirug/ZOverdraw.zip

[Xmas]

Originally posted by aths
Die Frage ist, ob 4 pro Pipeline oder 16 insgesamt :) Mit AA wirds ja erst richtig interessant...
Wahrscheinlich 4 pro Pipeline, wobei der Unterschied wirklich gering sein sollte.


Mit AA sinds nur noch 4 Pixel pro Takt, egal ob 2x (8 Samples/Takt) oder 4x (16 Samples/Takt)

Edit: Anhand des Bildes sieht man natürlich, dass der vorangehende Satz völliger Quark ist. Mit aktiviertem AA funktioniert Early-Z gar nicht mehr, sonst würde sich die Füllrate bei 4 Texturen nicht generell halbieren.

[Demirug]

Xmas, kannst du auch mal mit nur 2 Texturen messen? Bei 4 kommt ja bei Early-Z noch das einsparen des Loopbacks hinzu.

[Quasar]

Fein, dann hat mein "Schuss ins Blaue", meine "Schätzung" (Pille zu Spock in ST IV) ja ganz gut hingehauen.

BTW; ist das F2B/B2F-Switchen irgendwie kaputt oder ist meine R9000pro ein Tiler? Ich bekomme identische Werte...

[Quasar]

4xQuality-Smoothvision(tm):

[Demirug]

Das das F2B/B2F-Switchen geht. Bei Xmas macht es ja einen Unterschied und auf einer GF2 MX auch.

Und GF1:

B2F 285.19 MT/s
F2B 417.13 MT/s

Ohne Early-Z bringt es allerdings nur was wenn man an der Bandbreite hängt. Hat die 9000 Pro was in der Richtung? Wenn nicht hat deine 9000 Pro wohl genug Bandbreite.

Edit: Quasar was mir gerade auffällt. Wird bei dir aus dem schwarz beim erhöhen des Overdraws kein Blau???

[Quasar]

Doch, mit der Zeit schon. Beim durch"rutschen" durch die OD-Stufen sieht mans auch, aber aufm Screenie eben noch nicht. Ist aber schon weit weniger schwarz, als bei OD:1

edit:
Overdraw/HSR:
-------------
Overdraw factor 3, back to front: 346.26 fps
Overdraw factor 3, front to back: 428.82 fps
Overdraw factor 3, random order: 390.34 fps

Overdraw factor 8, back to front: 125.45 fps
Overdraw factor 8, front to back: 166.77 fps
Overdraw factor 8, random order: 154.71 fps

Bei GL_extreme macht's auch 'nen Unterschied...

[Demirug]

Originally posted by Quasar
Doch, mit der Zeit schon. Beim durch"rutschen" durch die OD-Stufen sieht mans auch, aber aufm Screenie eben noch nicht. Ist aber schon weit weniger schwarz, als bei OD:1

Gut. Ich dachte schon da stimmt was nicht. Hängt wohl irgendwie mit den Gama einstellungen Zusammen.

[Quasar]

*staun*
(sry 4 schlecht IQ...ist halt 'ne Radeon ;))

edit:
Hier scheint der B2F-Umschalter auch zu greifen: ohne AA nur noch 1280/2576 Füllrate

[aths]

800x600 Fenstermodus, 64x Overdraw, erst 2, dann 4 Texturen, erst Front-to-Back, dann Back-to-Front



/---------- F2B ----------\ /---------- B2F ----------\
/---- 2 ----\ /---- 4 ----\ /---- 2 ----\ /---- 4 ----\
Single Multi Single Multi | Single Multi Single Multi
|
No AA 1173 2191 593 2371 | 1173 2343 593 2371
|
2x AA 1131 2261 584 2336 | 710 1419 584 2337
|
4x AA 665 1328 572 2291 | 362 724 362 1451

Hier mal meine Messreihe. Folgendes fällt mir erst mal so auf:

1. AA senkt also die Füllrate bei B2F zusätzlich.
2. 4x AA senkt die Füllrate ganz erheblich.

Frage: Würde es Sinn machen, mal mit deutlich niedrigerem Chip-Takt zu benchen, um die Bandbreiten-Effekte zu minimieren?

[Demirug]

Quasar, das nennen ich mal ein Early-Z. Hast du auch B2F Zahlen?

[Quasar]

Ja, hab' ich oben schon reineditiert....ohne AA sind's 1280/2576, mit 2xAA 106x/213x, 4xAA 65x/132x und 6xAA 60x/122x (folgt noch).
Mit 8 Texture-Layern krieg ich beinahe 200GTex/s :D

[Demirug]

Quasar: 200 GTex/s :o sagt das bloss nicht nagus :D

aths: ja ein kleinere Coretakt könnte die Sache eindeutiger machen.

[ow]

.

[Exxtreme]

Originally posted by Xmas
GF3Ti200 @ 175MHz, 1024x768x32 Fullscreen, NoAA, NoAF, VSync off, 64x Overdraw, 2 Texturlayer
Back To Front: 679 MPix/s
Front To Back: 2572 MPix/s

Ist IMHO eindeutig, dass 16 Pixel pro Takt verworfen werden können.
Radeon9700Pro @ 325/310 MHz, 1024x768x32 Fullscreen, NoFSEAA, NoAF, VSync off, 64xOD, 2 Texturen:

BtF: 1259 MPix, 2517,5 MTex
FtB: 3776 MPix, 7552,6 MTex

[Demirug]

Originally posted by ow
Kurze Frage von mir:

Was ist denn D24X8 für ein Tiefenformat?

Und mein Kyro läuft auf D24X4S4?

D24X8 ist 24 Bit Z Kein Stencil (8 Bit unbenutzt)
D24X4S4 ist 24 Bit Z 4 Bit unbenutzt 4 Bit Stencil. <-- AFAIK nur bei Kyros möglich.

Das ist wichtig wenn man direkt auf den den Z-Buffer zugreifen will.

[Xmas]

800x600 Fenstermodus, 64x Overdraw, erst 2, dann 4 Texturen, erst Front-to-Back, dann Back-to-Front



/---------- F2B ----------\ /---------- B2F ----------\
/---- 2 ----\ /---- 4 ----\ /---- 2 ----\ /---- 4 ----\
Single Multi Single Multi | Single Multi Single Multi
|
No AA 2316 4632 2210 8840 | 660 1320 343 1373
|
2x AA 648 1296 338 1353 | 382 765 337 1348
|
4x AA 375 750 330 1320 | 192 385 192 769




Zum Vergleich:
Originally posted by aths


/---------- F2B ----------\ /---------- B2F ----------\
/---- 2 ----\ /---- 4 ----\ /---- 2 ----\ /---- 4 ----\
Single Multi Single Multi | Single Multi Single Multi
|
No AA 1173 2191 593 2371 | 1173 2343 593 2371
|
2x AA 1131 2261 584 2336 | 710 1419 584 2337
|
4x AA 665 1328 572 2291 | 362 724 362 1451

[aths]

800x600 Fenstermodus, 64x Overdraw, erst 2, dann 4 Texturen, erst Front-to-Back, dann Back-to-Front



/---------- F2B ----------\ /---------- B2F ----------\
/---- 2 ----\ /---- 4 ----\ /---- 2 ----\ /---- 4 ----\
Single Multi Single Multi | Single Multi Single Multi
|
No AA 590 1181 297 1190 | 590 1181 297 1190
|
2x AA 580 1160 294 1177 | 580 1160 294 1177
|
4x AA 564 1128 292 1168 | 359 718 292 1167

Taktung: 150 / "702". Relativ zur Füllrate gibts Speicherbandbreite im Überfluss. (Also genau halber Core-Takt im Vergleich zu meinen anderen Werten, der Rest blieb.)

Was ich auf den ersten Blick sehe: B2F oder B2F spielt eigentlich nur bei 4x MSAA eine Rolle.

[ow]

.

[Xmas]

Offensichtlich ist nur die GF3 ohne AA in der Lage, 16 Pixel pro Takt zu verwerfen, GF4 kann das nicht.

[ow]

.

[aths]

Demirug, nggalai, auch zecki: möchte jemand von euch das nicht auch mal kommentieren?

[Demirug]

aths, was soll man da noch gross kommentieren?

Wie Xmas schon sagt kann die GF3 wohl 16 Z-Werte pro Takt prüfen und verwerfen. Das geht aber wohl nur wenn die AA-Sampler nicht für das FSAA gebraucht werden.

Der GF4 ist diese Fähigkeit wohl genommen worden da sie nicht über das theoretisch mögliche Limit hinauskommt.

Die Frage nach dem warum ist jetzt aber schon schwerer zu beantworten.

Ich hätte da allerdings eine mögliche erklärung anzubieten.

Bei der GF3 befinden sich die 16 (4 Gruppen a 4) Z-Units im Trisetup vor den Einheiten welche die Datensätze für die Pixelpipes erzeugt. Das Trisetup zerlegt die Dreicke in einem 1 Schritt zu Blöcken a 4 Pixel. 2*2 als OG. Pro Takt können maximal 4 solcher Blöcke erzeugt werden und geprüft werden. Fällt die Prüfung eines solchen Blocks komplett negativ aus kann im nächsten Takt der nächste Block getestet werden. Alle positiv gebrüften Pixel werden in einen FIFO geschoben. aus diesem kann dann pro Takt maximal ein Pixel entnommen werden. Wenn ein FIFO zu voll ist wird die Prüfung gestoppt.

Beim FSAA funktioniert das nicht mehr da in diesem Fall die Blocklogik zum Erzeugen der Positionen für die AA-Sample benötigt wird. Also ein Block entspricht dann einem Pixel.

Beim NV25 geht das aber wohl etwas anders. Da es dort auch erlaubt ist den Z-Wert im Pixelshader zu ändern müssen die 16 Z-Prüfungen optional auch nach dem Pixelshader vorgenommen werden. Die Logic um die Prüfung wahlweise am Anfang oder am Ende der Pipeline durchzuführen ist eigentlich recht einfach, da man nur ein paar Datenleitungen umlegen muss. Das läst sich mit 2 Transitoren pro Leitung leicht machen. Eine Umschaltmöglichkeit zwischen einer Prüfung im Trisetup und am Ende der Pipeline müsste um einiges komplizierter sein. Ich denke mal da haben wieder mal die Transitoren nicht gereicht.

Ich hoffe die Erklärung war verständlich. Ich hätte ja noch ein paar Bilder dazu gemacht aber irgendwie habe ich gerade keine Lust zum zeichnen.

P.S: Könnte jemand mal noch mit ein paar ATI Chips messen. R300 haben wir ja schon und dort funktioniert das das Early Z ja ganz gut.

[zeckensack]

Originally posted by Demirug
P.S: Könnte jemand mal noch mit ein paar ATI Chips messen. R300 haben wir ja schon und dort funktioniert das das Early Z ja ganz gut. On my way (R200).

Resultate folgen in Kürze.

[Exxtreme]

Originally posted by ow


Kyro1 @ 115MHz, selbe Einstellungen

Back To Front: 1738 MPix/s
Front To Back: 1747 MPix/s

Hehe, da funktioniert das HSR ja gar nicht.
:D

[zeckensack]

Auf Basis von ow's Resultaten:
Radeon 8500LE@250MHz/250MHz

800x600 Fenstermodus, 64x Overdraw, erst 2, dann 4 Texturen, erst Front-to-Back, dann Back-to-Front



/---------- F2B ----------\ /---------- B2F ----------\
/---- 2 ----\ /---- 4 ----\ /---- 2 ----\ /---- 4 ----\
Pixel Texel Pixel Texel | Pixel Texel Pixel Texel
|
No AA 8200 16400 7150 28600 | 762 1524 483 1932
2x AA 4020 8040 3436 13744 | 373 746 242 968
4x AA 615 1230 388 1522 | 188 376 120 480


Dumme Frage: unter Single/Multi habt ihr Pixel-/Texelfüllrate angegeben, richtig?

[ow]

.

[Demirug]

zeckensack, danke

das dürften dann 32 Pixel pro Takt sein. Nicht schlecht.

[ow]

Wie rechnet man das aus?

Und wieso ist der F2B Wert bei 4xAA auf der 8500 so niedrig?

/edit: und was für ein Problem hat meine Kyro bei B2F und 4xAA bei 2 Texturen?

[Demirug]

Originally posted by ow
Wie rechnet man das aus?

Pixelfillrate / Takt


Und wieso ist der F2B Wert bei 4xAA auf der 8500 so niedrig?

Gute Frage. Möglicherweise das Memoryinterface.



/edit: und was für ein Problem hat meine Kyro bei B2F und 4xAA bei 2 Texturen?

Da gibt es kein Problem. Exxtreme fand es wohl amüsant das F2B etwas besser war als B2F. Das ist aber im Bereich der Messtolleranz.

[ow]

.

[Demirug]

Originally posted by ow

Schau dir mal meine Kyro-Werte an.
4xAA B2F mit 2Tex ist langsamer als mit 4Tex.

Das sollte nun bei einem TBDR wirklich nicht passieren. Und deshalb bin ich da auch überfragt. Ist wohl ein Fall für Kristof.

[zeckensack]

Originally posted by aths
Demirug, nggalai, auch zecki: möchte jemand von euch das nicht auch mal kommentieren? Dieser Füllratenbenchmark scheint einige der Probleme des 3DMurx zu erben (hohe Abhängigkeit von Bufferclears). Zumindest kann man das durch hohen Overdraw kompensieren, das muß man aber erstmal wissen.

Programmen hohe Priorität zu geben ist immer schlecht. Ich weiß nicht was das soll ...

Eine Report-Funktion, die ein paar Messungen bei interessanten Settings automatisch erzeugt, wäre schön.

Alles in allem werde ich aus dem Programm leider noch nicht so recht schlau.

Ging es dabei nicht ursprünglich um Kyro+extrem hohen transparenten Overdraw, ie Blending?

[Demirug]

Originally posted by zeckensack
Dieser Füllratenbenchmark scheint einige der Probleme des 3DMurx zu erben (hohe Abhängigkeit von Bufferclears). Zumindest kann man das durch hohen Overdraw kompensieren, das muß man aber erstmal wissen.

Das Problem haben alle Fillrate tests gemeinsam. Wobei ich den Framebuffer ja schon gar nicht lösche sondern nur den Z-Buffer.

Programmen hohe Priorität zu geben ist immer schlecht. Ich weiß nicht was das soll ...

Verringern der Messschwankungen. Bei einem gewöhlichen Programm würde ich sowas auch nicht machen bei einem Bench ist es IMO aber OK.

Eine Report-Funktion, die ein paar Messungen bei interessanten Settings automatisch erzeugt, wäre schön.

Ist eine Überlegung wert.

Alles in allem werde ich aus dem Programm leider noch nicht so recht schlau.

Ging es dabei nicht ursprünglich um Kyro+extrem hohen transparenten Overdraw, ie Blending?

Nein, das ist ein anderes Programm (ist fast fertig). Bei diesem Programm ging es ursprünglich darum festzustellen wie viele Pixel eine GF4 pro Takt im Early-Z verwerfen kann und dadurch einen Fillrate gewinn erziellen kann.

[aths]

Originally posted by Demirug
Beim NV25 geht das aber wohl etwas anders. Da es dort auch erlaubt ist den Z-Wert im Pixelshader zu ändern müssen die 16 Z-Prüfungen optional auch nach dem Pixelshader vorgenommen werden.Falls nachträgliches Ändern von Z für Z-Correct Bumpmapping Voraussetzung ist, kann GeForce3 das auch (zumindest in OpenGL.)

nVidia beansprucht nach wie vor, dass LMA2 Z Occlusion Culling vornimmt. Stimmt das denn nun, oder nicht?

[Demirug]

Originally posted by aths
Falls nachträgliches Ändern von Z für Z-Correct Bumpmapping Voraussetzung ist, kann GeForce3 das auch (zumindest in OpenGL.)

In D3D geht es nicht. Da fehlt dann wohl was anderes um die PS 1.3 zu erreichen. Das Zerstört jetzt aber meine Theorie warum das Prüfen von 16 Pixel beim NV25 nicht mehr geht. Die Theorie bezüglich des AA/no AA halte ich aber erst mal noch aufrecht.

nVidia beansprucht nach wie vor, dass LMA2 auf Pixelbasis Occlusion Culling vornimmt. Stimmt das denn nun, oder nicht?

Gute Frage. Auf jeden Fall kann die GF4 wohl daraus keinen Fillrate vorteil ziehen. Also ist bestenfalls noch ein Einsparen von Bandbreiten drin. Da die Texuren aber sehr klein sind kann man das nicht testen. Du kannst aber gerne mal die Texturdateien tauschen um evntl. die Bandbreite stärker zu belasten.

[Quasar]

Hab' ich grade mal probiert. Mit 2000x2000-Texturen (1024 Fullscreen, OD:64, 2 Layer) krieg ich auf der R9000Pro nur noch 25Mpix/50MTex hin, und der zweite Texturlayer hat fiese Bildfehler....

[zeckensack]

Originally posted by Demirug
Das Problem haben alle Fillrate tests gemeinsam. Wobei ich den Framebuffer ja schon gar nicht lösche sondern nur den Z-Buffer.Durch Umkehren des Z-Tests muß man nichtmal den Z-Buffer löschen :)
Am allerschönsten wäre das ganze natürlich ganz ohne Z-Buffer/-Test, das wäre dann aber ein reiner Füllratenbenchmark, der nicht mehr dazu taugen würde, Early-Z-Mechanismen zu untersuchen.

Natürlich muß man auch aufpassen nicht von einem Tiler veräppelt zu werden. (EndScene(); BeginScene() einsetzen)

[Demirug]

Originally posted by Quasar
Hab' ich grade mal probiert. Mit 2000x2000-Texturen (1024 Fullscreen, OD:64, 2 Layer) krieg ich auf der R9000Pro nur noch 25Mpix/50MTex hin, und der zweite Texturlayer hat fiese Bildfehler....

Die Layer werden addiert und dann kommt noch das Blau von der Grundfläche dazu welches vom Overdraw abhängt. Bist du sicher das die "Bildfehler" nicht dadurch entstehen?

[aths]

Was ich noch nicht so ganz verstanden habe:

Kann GeForce4 Ti wenigstens bei PixelShadern (mit 2 oder mehr Takten) denn nun "Füllrate" sparen oder auch nicht?

[Demirug]

Originally posted by aths
Was ich noch nicht so ganz verstanden habe:

Kann GeForce4 Ti wenigstens bei PixelShadern (mit 2 oder mehr Takten) denn nun "Füllrate" sparen oder auch nicht?

Ich fürchte nein. Denn wenn dem so wäre hätte bei wechsel von 2 auf 4 Texturen die Pixel-Fillrate fast gleich bleiben müssen und die Texel Fillrate sich verdoppeln. Zu sehen beim R200, Kyro, GF3.

Also:

Early-Z hat beim NV25 keine Auswirkung auf die Fillrate.

Ist da was kaputt?

Hat NVIDIA sich da noch eine Leistungsreserve über die Treiber übrig gelassen?

Oder war das so beabsichtigt?

[aths]

Originally posted by Demirug
Ich fürchte nein. Denn wenn dem so wäre hätte bei wechsel von 2 auf 4 Texturen die Pixel-Fillrate fast gleich bleiben müssen und die Texel Fillrate sich verdoppeln. Zu sehen beim R200, Kyro, GF3.

Also:

Early-Z hat beim NV25 keine Auswirkung auf die Fillrate.

Ist da was kaputt?

Hat NVIDIA sich da noch eine Leistungsreserve über die Treiber übrig gelassen?

Oder war das so beabsichtigt? Bedenkt man die Schwäche beim AF, so hat man kein gutes Gefühl bei der Sache.

[Pussycat]

Treiberreserven könnte ich mir nicht vorstellen. Für den 9700 braucht man alles, was sich ja mit den überhasteten treiber ohne control panel, mit point sampling etc. gezeigt hat.

[StefanV]

Hm, wenn das stimmt, was Demirug vermutet, dann hatte NV wohl große Probleme mit dem GF4...

Auch die AF Schwäche der GF4 ist ein Anzeichen dafür, daß bei der GF4 wohl einiges kaputt sein müsste...

Möglich, daß NV 'dank' der Radeon 8500 überhastet reagiert hat und die GF4 erst für Ende 2002 geplant war...

DAS dürfte auch die 'verspätung' der NV30 erklären...

just my 2 cent...

[Quasar]

Originally posted by Demirug
Die Layer werden addiert und dann kommt noch das Blau von der Grundfläche dazu welches vom Overdraw abhängt. Bist du sicher das die "Bildfehler" nicht dadurch entstehen?

Eigentlich schon, denn ich habe einfach deine Texturen aufgebläht, so dass das Endresultat dasselbe bleiben sollte....

[Demirug]

Originally posted by Quasar


Eigentlich schon, denn ich habe einfach deine Texturen aufgebläht, so dass das Endresultat dasselbe bleiben sollte....

Das sieht wirklich nicht schön aus. Kannst du mal die Texturen 1 und 2 tauschen und schauen ob die BildFehler dann auch wandern?

[Quasar]

Werd' ich gleich mal machen, aber zwischenzeitlich hab ich's auf 'ner GF4 Ti4200 probiert, die liefert IQ-Mäßig dasselbe Resultat, Füllrate liegt bei 147/295...

Update folgt...
Update:
Bildfehler bleibt unabhängig vom Texturlayer in der unteren rechten Ecke, mal gucken, was passiert, wenn ich alle Texs aufblähe...

Update2:
Wenn ich auffer R300 alle 8 Texturen auf 2000x2000 aufpuste (91,5MB Texturen ;)) beginnen die Bildfehler mit der zweiten Texturschicht, sind aber unten links am stärksten und nehmen von unten links nach rechts und unten nach oben ab, unabhängig davon, in welchem Layer die entsprechende Textur gerendert wird. Weiterhin sind nur 7 Layer möglich, beim Zuschalten des 8. Layers krieg ich nur noch den Hintergrund zu sehen.....

[Xmas]

Originally posted by Stefan Payne
Hm, wenn das stimmt, was Demirug vermutet, dann hatte NV wohl große Probleme mit dem GF4...

Auch die AF Schwäche der GF4 ist ein Anzeichen dafür, daß bei der GF4 wohl einiges kaputt sein müsste...

Möglich, daß NV 'dank' der Radeon 8500 überhastet reagiert hat und die GF4 erst für Ende 2002 geplant war...

DAS dürfte auch die 'verspätung' der NV30 erklären...

just my 2 cent...
Kaum. NV30 stammt nicht vom selben Designteam wie NV25. Und NV20 für 20+ Monate als Topmodell? So naiv ist NVidia wohl kaum, und eine echte Überraschung war die R8500 nun wirklich nicht.

[StefanV]

Originally posted by Xmas

Kaum. NV30 stammt nicht vom selben Designteam wie NV25. Und NV20 für 20+ Monate als Topmodell? So naiv ist NVidia wohl kaum, und eine echte Überraschung war die R8500 nun wirklich nicht.

Schon klar...

Dennoch scheint es so, als hätte NV ziehmliche Probleme mit dem NV25 gehabt, sonst wäre die sicher nicht so schrottig und sicher 'etwas' schneller, insbesondere bei AF...

[Demirug]

Quasar, ich kann es reproduzieren weiss allerdings noch nicht an was es liegt. Mit dem RefRast ist es OK.

Wenn der Texturspeicher nicht mehr reicht gibt es müll das ist mir bekannt.

[Exxtreme]

Originally posted by Stefan Payne


Schon klar...

Dennoch scheint es so, als hätte NV ziehmliche Probleme mit dem NV25 gehabt, sonst wäre die sicher nicht so schrottig und sicher 'etwas' schneller, insbesondere bei AF...
Für mich sieht's nach einer "Wie-spare-ich-am-besten-Transistoren-ein"-Aktion aus. Vielleicht ist da was schief gelaufen. Ansonsten hätte NV dann doch lieber das GF3-Design etwas tunen und höher getaktet rausbringen können.

[ow]

@Demi

Könntest du die Priorität des Progs wieder etwas verringern?
Es ist mir nahezu unmöglich, meinen Rechner zu bedienen, wenn das Prog läuft.

[Demirug]

ow, kein Problem: http://demirug.bei.t-online.de/ZOverdraw.zip

[aths]

Demi, kannst du den Füllratentest auch für OpenGL erstellen?

Ich hoffe btw noch immer, irgendwas falsch gemacht zu haben. Eine Karte ohne vernünftiges Z Occlusion - da kommt einem ja die Galle hoch.

[Quasar]

aths,
Ist das bei dir auch so, dass, wenn du die zwei zusätzlichen Texturschichten zuschaltest, für einen Sekundenbruchteil die Texel-Füllrate um ca. 1GTex pro Layer hochschnellt?

[zeckensack]

Bei Problemen mit OpenGL ...
bitte minimal kommentierten Quellcode an mich :)

Ansonsten backe ich auch schon an einem Konkurrenzprodukt :naughty:

[Quasar]

So, der Vollständigkeit halber....

Radeon 9700pro@325MHz/310MHz
800x600 Fenstermodus, 64x Overdraw, erst 2, dann 4 Texturen, erst Front-to-Back, dann Back-to-Front
mit jeweils Neustart des Programms, Multisample über App eingestellt.


/---------- F2B ----------\ /---------- B2F ----------\
/---- 2 ----\ /---- 4 ----\ /---- 2 ----\ /---- 4 ----\
Pixel Texel Pixel Texel | Pixel Texel Pixel Texel
|
No AA 24000 48000 18500 73950 | 1280 2500 650 2550
2x AA 18900 37750 15400 61500 | 1100 2200 640 2550
4x AA 13150 26350 13400 53700 | 620 1250 630 2500
6x AA 11450 22900 11450 45750 | 610 1220 620 2450


Damn impressive, I'd say :D

[Demirug]

aths, ich wüsste nicht was du falsch gemacht haben könntest. Um OpenGL kümmert sich ja zeckensack wenn ich es richtig verstanden habe.

Quasar, das mit hochschnellen kommt daher das noch ein Teil der letzten Sekunde mit den alten Einstellungen gemessen wurde.

[Quasar]

Das verstehe ich nicht, Demirug. Wieso schnellt der Wert von knapp 2000MTex auf knapp 4000MTex hoch, obwohl noch ein Teil der letzten Sekunde mit 2 Texturen und ein Teil mit 4 Texturen gemessen wurde?

[Demirug]

Die Fillrate wird einfach über die FPS berechnet und da diese ja noch ganz kurz auf dem alten Wert ist verdoppelt sich beim Umschalten von 2 auf 4 Texturen kurz die Fillrate.

[Kennung Eins]

Ich hab mir jetzt auch mal den Spass gemacht, und ne Testreihe aufgestellt.

GeForce3 (keine Ti) bei 200/480MHz
1024x768 Vollbildmodus, 64x Overdraw, erst 2, dann 4 Texturen, erst Front-to-Back, dann Back-to-Front

/---------- F2B ----------\ /---------- B2F ----------\
/---- 2 ----\ /---- 4 ----\ /---- 2 ----\ /---- 4 ----\
Pixel Texel Pixel Texel | Pixel Texel Pixel Texel
|
No AA 1888 3770 1888 7552 | 755 1508 377 1510
2x AA 755 1488 377 1510 | 472 943 377 1510
4x AA 419 839 377 1510 | 188 377 188 755
8xS AA 179 359 97 386 | 78 157 75 302

[loewe]

Hier mal die KYRO II. Sieht zwar F2B teilweise etwas lächerlich aus, aber Serie5 wird sicher ein ähnliches Verhalten zeigen und dann die entsprechenden Füllraten mitbringen.

KYRO II 185 MHz 64x Overdraw

/---------- F2B ----------\ /---------- B2F ----------\
/---- 2 ----\ /---- 4 ----\ /---- 2 ----\ /---- 4 ----\
Pixel Texel Pixel Texel | Pixel Texel Pixel Texel
|
No AA 2732 5472 2701 10803 | 2776 5552 2740 10958
2x AA 1376 2751 1359 5436 | 1396 2792 1379 5514
4x AA 690 1380 684 2733 | 701 1401 693 2772

[ow]

@Demi

Lässt sich das Prog auch zur Geschwindigkeit von AF missbrauchen? Die Werte des Kyro reagieren sehr stark auf Einschalten von AF.

btw. mein obiges Kyro-Prob war keines, hab´s nochmal nachgemessen.

[Demirug]

Originally posted by ow
@Demi

Lässt sich das Prog auch zur Geschwindigkeit von AF missbrauchen? Die Werte des Kyro reagieren sehr stark auf Einschalten von AF.

btw. mein obiges Kyro-Prob war keines, hab´s nochmal nachgemessen.

Eher nicht da ja keine Tiefenneigung vorhanden ist. Ich kann zwar noch eine Option für den AF-Level hinzufügen aber es dürfte nicht viel ausmachen.

[aths]

Originally posted by Demirug
Eher nicht da ja keine Tiefenneigung vorhanden ist. Ich kann zwar noch eine Option für den AF-Level hinzufügen aber es dürfte nicht viel ausmachen. Ist egal, solange die Texturen nicht im 1:1 Aspekt ausgegeben werden. Da sie bei dir ungleich skaliert sind, wirkt auch AF. (Jedenfalls bei mir.)

[ow]

Originally posted by aths
Ist egal, solange die Texturen nicht im 1:1 Aspekt ausgegeben werden. Da sie bei dir ungleich skaliert sind, wirkt auch AF. (Jedenfalls bei mir.)

Bei mir auch. Man erkennt deutlich, dass die Texturen gefiltert werden. Und der Kyro reagiert auch mit einem heftigen Fillrate-Einbruch darauf.

[aths]

Demirug,

inwiefern nützt bei GeForce4 dann noch der Z-Pass in Doom3?

[Demirug]

Originally posted by aths
Demirug,

inwiefern nützt bei GeForce4 dann noch der Z-Pass in Doom3?

Der Z-Pass muss auf jeden Fall gemacht werden sonst funktionieren gewisse andere Dinge nicht richtig (Schatten, Alphablending).

Die GF4 könnte noch Bandbreite sparen wenn das Texturfetchen durch das Early-Z deaktiviert wird.

[ow]

@Demi:

Ist zwar leicht OT, aber was macht denn die Kyro mit dem Z-only pass?
Schatten konnte ich mit ihr nämlich keine entdecken.:D

[Demirug]

Originally posted by ow
@Demi:

Ist zwar leicht OT, aber was macht denn die Kyro mit dem Z-only pass?
Schatten konnte ich mit ihr nämlich keine entdecken.:D

Nemen wir mal an ein Pixel wird von zwei Lichtquellen beleuchtet.

Dann ergibt sich für die entgültige Pixelfarbe:

P.Color = P.Color Licht1 + P.Color Licht2

Da die beiden Lichter getrennt gerendert werden (müssen) kann die Addition nur über den Framebuffer (sprich Alphablending) laufen. DOOM III rendert also jeden Lichtpass mit aktiviertem Alphablending (Destionation*1+Source*1). Beim Rendern haben wir nun aber einen gewissen overdraw. Gehen wir mal von einem Overdraw von 2 aus.

Liegt nun der erste Pixel in der renderfolge vor dem 2. passiert folgendes wenn man keinen Z-Pass hat.

1. 1 Pixel wird mit dem hintergrund (schwarz) addiert und im Framebuffer abgelegt
2. 2 Pixel mit dem Wert von Pixel1 addiert und wieder gespeichert.

Ergebniss: die Farbe im Framebuffer ist falsch weil dort ja nur die Farbe des zweiten Pixel sein dürfte.

Ist die Rheienfolge anders:

1. 2 Pixel wird mit dem hintergrund (schwarz) addiert und im Framebuffer abgelegt
2. 1 Pixel wird durch die Z-Prüfung abgelent.

Ergebniss: Die Farbe ist richtig.

Kommt jetzt noch die zweite Lichtquelle ins Spiel wird es noch komplizierter.

Der Z-Pass ist das einfachste und sicherste Mittel das Problem zu umgehen. Alternativ kann man auch einen Pass mit dem Ambient Light zuerst durchlaufen lassn. Bei diesem Licht muss dann natürlich das Alphablending aus sein.

Es geht auch noch anders. Dabei muss für jedes Object beim rendern der ersten Lichtquelle welche auf das Object einfluss hat das Alphablending deaktiviert werden. Da man aber wie gesagt DOOM III den Z-Pass für die Schatten braucht wäre es unnötigt eine solche Technik zu implementieren.

[aths]

Originally posted by Demirug
Die GF4 könnte noch Bandbreite sparen wenn das Texturfetchen durch das Early-Z deaktiviert wird. Ich find's ziemlich blöde.

Absichtliche Kastration, um den Abstand zur GF FX zu vergrößern?

[Quasar]

Originally posted by aths
Ich find's ziemlich blöde.

Absichtliche Kastration, um den Abstand zur GF FX zu vergrößern?

Und noch etwas mehr gegen die R9500 abzulosen?

[aths]

Originally posted by Quasar
Und noch etwas mehr gegen die R9500 abzulosen? Bei der Entwicklung der GF4 Ti wusste nV wohl kaum was vom R9500 bzw. dessen Power.

Hast du eine bessere Theorie anzubieten (warum dann damit hinter dem Berg halten?)

[Quasar]

Einfach ein Fehler, der übersehen wurde? Du siehst ja, wie lange es gedauert hat, bis man dem auf die Spur kam.

BTW, meinst du ernsthaft, dass die GF4Ti so nahe an die FX rankommt, dass man sich solcher Tricks bedienen müsste?

[aths]

nV gibt 100 Mio USD aus um die GF4-Reihe zu entwickeln und übersieht, dass Early Z nicht mehr richtig funktioniert? Daran glaube ich nicht, zumal die neuen White Papers die LMA2 betreffen hier die Bandbreiten-Ersparnis so hervorheben und die Füllraten-Sache unter den Tisch fallen lassen, dass sich nV dieser neuen Eigenschaft offenbar voll bewusst ist.

Und: Nach dem AF-"Bug" nun noch so ein Fehler, denn man - hoppla - übersehen hat? Ich glaube nicht, dass bei nV nur solche Stümper arbeiten.

Als der NV25 geplant wurde, waren für GFFX wahrscheinlich noch keine 500 MHz angepeilt. Klingt letztlich auch nicht so richtig überzeugend, aber der NV25 wurde ja nun wirklich nicht unter Zeitdruck gefertigt, und dann gleich 2 Bugs (AF, LMA2) - für so unfähig halte ich nV-Ingenieure nicht.

[Demirug]

Zeitdruck ist ein gutes Stichwort. OK das ist jetzt eine ganz wilde Spekulation

der NV25 war so wie wir in heute kaufen können in der Roadmap nicht vorgesehen. NVIDIA wollte einen NV30 (nicht den NV30 den wir jetzt bekommen) schon viel früher rausbringen aber als man merkte das ATI nicht hinterherkommt entschloss man sich kurzfristig noch einen Chip auf NV2x Basis zu bringen.

[aths]

Originally posted by Demirug
Zeitdruck ist ein gutes Stichwort. OK das ist jetzt eine ganz wilde Spekulation

der NV25 war so wie wir in heute kaufen können in der Roadmap nicht vorgesehen. NVIDIA wollte einen NV30 (nicht den NV30 den wir jetzt bekommen) schon viel früher rausbringen aber als man merkte das ATI nicht hinterherkommt entschloss man sich kurzfristig noch einen Chip auf NV2x Basis zu bringen. ... und dann rutschten da AF-Bug und LMA2-Bug rein? Eben weil ATI zu dieser Zeit nichts "gefährliches" hatte, hätten sie den Chip auch retour schicken und fixen können, oder nicht?

[Demirug]

Originally posted by aths
... und dann rutschten da AF-Bug und LMA2-Bug rein? Eben weil ATI zu dieser Zeit nichts "gefährliches" hatte, hätten sie den Chip auch retour schicken und fixen können, oder nicht?

In wie fern das nun Bugs oder bewusste Entscheidungen waren kann ich nicht sagen. Aber retour war nicht drin denn liefern musste man ja trotzdem was. Aber das ist ja wie gesagt eine wilde Spekulation.

[ow]

Mich würde viel eher interessieren, woher der GF4 seine enorme Rohpower (ti4600 min. auf R9700 Niveau) hat, wenn schon das LMA2 keine Füllrate spart.
Wieso ist eine 4ti4200 einer 3ti500 leistungsmässig so überlegen trotz kaputter Füllrateneinsparung?

[Demirug]

Rohpower? Ich denke du meinst die effektivität mit der die Rohpower umgesetzt wird.

Ich denke mal das die Fillrate Einsparung durch Early-Z in vielen Spielen derzeit gar nicht richtig greifen kann. bzw die Pixel damit zwar verworfen werden und Fillrate gespart werden kann. Diese Fillrate aber gar nicht genutzt werden kann weil verwerfbare Pixel nicht gleichmäsig sonder eher gehäuft auftreten. Also zu den Zeitpunkten wenn man durch Early-Z Fillrate bekommt hat meine keine Pixel um sie auch zu nutzen.

[ow]

Originally posted by Demirug
Rohpower? Ich denke du meinst die effektivität mit der die Rohpower umgesetzt wird.



Ich meine ganz einfach die Leistung ohne AA/AF.
Ich kann mich nicht an Benches erinnern, in denen eine 9700 eine GF4 darin geschlagen hätte (ausser vielleicht bei 2048x1536 Auflösung:D).

[aths]

Originally posted by ow
Wieso ist eine 4ti4200 einer 3ti500 leistungsmässig so überlegen trotz kaputter Füllrateneinsparung? "Quadcache", verbesserte Z-Compression, ...

[aths]

Originally posted by Demirug
Also zu den Zeitpunkten wenn man durch Early-Z Fillrate bekommt hat meine keine Pixel um sie auch zu nutzen. Hm. Wenn ich das richtig verstehe, würden dann aber pro Takt gleich 16 dieser unsichtbaren Pixel verworfen. Die nicht sichtbaren Pixel würden dann sehr schnell abgearbeitet, und man bräuchte nicht für jeweils 4 Pixel einen Takt (sondern kann wie gesagt 16 Pixel pro Takt verwerfen, solange der Triangle-Setup-Cache nicht leer läuft.)

Im GF4-Launch-Video sprechen sie zumindest bei der GeForce4 MX davon, dass sie nur das rendern würde was sichtbar sei (man erinnere sich an die Bugs-Demo.)

Hat hier jemand mal eine GF4MX, um dort Demis Prog laufen zu lassen...?

[Demirug]

aths, ja bei der GF3 funktioniert das mit den 16 Pixel pro Takt ja scheinbar auch (solange das AA aus ist). Die mehrzahl der verdeckten Pixel dürften aber wie gesagt immer in grosser Menge gefolgt von vielen Sichtbaren Pixel auftreten. Der VertexShader der GF3 ist noch nicht so gut wie das Model in der GF4. Daraus könnte sich ergeben das im Trisetup die Pixel schneller verworfen werden als der Vertexshader daten nachschieben kann. Zudem vermute ich auch noch das die 16 Z-Tests nicht frei einsetztbar sind sonder das zumindestens immer 4 Pixel in einer OG Anordnung geprüft werden müssen. Am Rand ergibt das zwangsläufig Verschnitt.

Möglicherweise hat man bei der GF4 auch auf diese 16 Pixel-Technik verzichtet um den Einbruch bei aktivieren des AA nicht noch grösser werden zu lassen. Warum aber bei Shadern die mehr als einen Takt brauchen diese zusätzlichen Takte nicht gespart werden ist schwerer zu sagen. Möglicherweise ist aber der Vorteil wenn man alle Pipelines immer syncron laufen läst höher als der Gewinn den man macht wenn man die Übername von Pixeln Asyncron gestaltet. Bleibt nur noch der Fall das alle 4 Pixel verworfen werden.

Die IMO einfachste Erklärung für all die ungereimtheiten in der GF4 ist das man gemerkt hat das der Chip zuviel Fillrate im Verhältniss zur Bandbreite hat. Und das ein besseres Nutzen der Fillrate aufgrund von Limitierungen in der Bandbreite gar nichts bringen würde.

[aths]

Originally posted by Demirug
aths, ja bei der GF3 funktioniert das mit den 16 Pixel pro Takt ja scheinbar auch (solange das AA aus ist). Die mehrzahl der verdeckten Pixel dürften aber wie gesagt immer in grosser Menge gefolgt von vielen Sichtbaren Pixel auftreten. Der VertexShader der GF3 ist noch nicht so gut wie das Model in der GF4. Daraus könnte sich ergeben das im Trisetup die Pixel schneller verworfen werden als der Vertexshader daten nachschieben kann. Zudem vermute ich auch noch das die 16 Z-Tests nicht frei einsetztbar sind sonder das zumindestens immer 4 Pixel in einer OG Anordnung geprüft werden müssen. Am Rand ergibt das zwangsläufig Verschnitt.

Möglicherweise hat man bei der GF4 auch auf diese 16 Pixel-Technik verzichtet um den Einbruch bei aktivieren des AA nicht noch grösser werden zu lassen. Warum aber bei Shadern die mehr als einen Takt brauchen diese zusätzlichen Takte nicht gespart werden ist schwerer zu sagen. Möglicherweise ist aber der Vorteil wenn man alle Pipelines immer syncron laufen läst höher als der Gewinn den man macht wenn man die Übername von Pixeln Asyncron gestaltet. Bleibt nur noch der Fall das alle 4 Pixel verworfen werden.

Die IMO einfachste Erklärung für all die ungereimtheiten in der GF4 ist das man gemerkt hat das der Chip zuviel Fillrate im Verhältniss zur Bandbreite hat. Und das ein besseres Nutzen der Fillrate aufgrund von Limitierungen in der Bandbreite gar nichts bringen würde. Das klingt natürlich vernünftiger als meine "Abstand zur NV30-These" als auch, dass es sich um einen Bug handelt.

Was ich allerdings nicht glaube, ist, dass sie auf den Abstand zum aktivierten FSAA geachtet haben. Denn die Rohbenches, auch und gerade 3DMark2001, werden ja in aller Regel ohne FSAA durchgeführt.

Dass der Chip "zuviel Füllrate" hat, nunja. Immerhin, bei FSAA-Benchmarks, wo die GF3 Early Z auch nicht richtig nutzen kann, ist GF4 ja nicht im Nachteil.

Inwiefern profitiert GF4 Ti noch von Early Z? nVidia beansprucht Bandbreiten-Ersparnis, aber wo könnte diese anfallen?

BTW, Verhältnis schreibt man nicht mit ss hinten :) http://www.boardy.de/images/smilies/uniprof.gif

[Quasar]

Originally posted by aths
Was ich allerdings nicht glaube, ist, dass sie auf den Abstand zum aktivierten FSAA geachtet haben. Denn die Rohbenches, auch und gerade 3DMark2001, werden ja in aller Regel ohne FSAA durchgeführt.


Einspruch, hast' dir mal die "Benchmarker's Guidelines" oder wie auch immer die hiessen, zur GF4 angeschaut?

nVidia "empfiehlt" darin, nur in Auflösungen ab 1280x0124 zu testen und/oder (kann mich nicht genau erinnern & bin zu faul nachzusehen) mit aktiviertem FSAA....

[aths]

Originally posted by Quasar
Einspruch, hast' dir mal die "Benchmarker's Guidelines" oder wie auch immer die hiessen, zur GF4 angeschaut?

nVidia "empfiehlt" darin, nur in Auflösungen ab 1280x0124 zu testen und/oder (kann mich nicht genau erinnern & bin zu faul nachzusehen) mit aktiviertem FSAA.... nVidia kann noch so viel empfehlen, die wissen, dass oftmals nur 3dmark in den Standard-Einstellungen gebencht wird, bzw. No-FSAA-Benches auf absehbare Zeit noch eine wichtige Rolle spielen. Ich kann mir nicht vorstellen dass sie die No-AA-Leistung senkten, um den Einbruch zum AA zu verringern.

[Quasar]

Gerade im "NoFSAA"-Bereich sind Benches wie der 3DMark aber recht stark CPU-limitiert, wie du ja weisst.

Da ist dann wieder die Kosten-/Nutzenabwägung, ob sich's lohnt, "ohne" ggü. der R8500 noch etwas weiter vorn zu sein, als ohnehin schon, oder sie "mit" vollends in Grund und Boden zu rammen, so wie's jetzt die R300 mit der GF4Ti macht.

[aths]

Originally posted by Quasar
Gerade im "NoFSAA"-Bereich sind Benches wie der 3DMark aber recht stark CPU-limitiert, wie du ja weisst.

Da ist dann wieder die Kosten-/Nutzenabwägung, ob sich's lohnt, "ohne" ggü. der R8500 noch etwas weiter vorn zu sein, als ohnehin schon, oder sie "mit" vollends in Grund und Boden zu rammen, so wie's jetzt die R300 mit der GF4Ti macht. Dadurch dass sie ohne FSAA wohlmöglich langsamer wird, wird sie ja mit AA nicht schneller. Ob nun mit oder ohne "richtigem" Early-Z, die 8500 rammen sie mit AA nicht mehr oder weniger in den Boden.

Zumal AA-seitig schon die Radeon 8500 schon einer GF3 kaum gefährlich werden konnte.

Ich nehme mal an, dass (basierend auf Demis Gedankengängen) das Early Z der GF3 nicht besonders hoch entwickelt ist. Um es "vernünftig" zu machen fehlte entweder die Zeit, oder der Wille, oder der Grund. Um bestimmte Probleme zu umgehen, cancelte man das dann gleich komplett.

Ich wäre allerdings ziemlich sauer, wenn sich herausstellt, dass lange Shader tatsächlich auch bei Unsichtbarkeit komplett ausgeführt werden, wie Demirug es annimmt.


Demi, könntest du da nicht auch ein Tool schreiben? Statt Multitexturing einfach einen Pixelshader, der wahlweise 2 oder 4 Texturen nutzt, und wahlweise 2, 4 oder 8 Befehle ausführt?http://www.clanintern.de/extern/smile/Hail.gif

(Immerhin behauptet nVidia:A visibility subsystem:
Determines whether or a not a pixel will be visible in a scene. If it determines a pixel will not be visible, the pixel is not rendered, saving valuable frame buffer bandwidth. gelesen auf http://www.nvidia.com/view.asp?IO=feature_lmaii. Wenn die das mit der Framebuffer-Bandbreite nur so meinen, dass unsichtbare Pixel nicht in den Framebuffer geschrieben werden, ist das ja nichts was extra anzupreisen wäre.)

[Kennung Eins]

Originally posted by aths
Hat hier jemand mal eine GF4MX, um dort Demis Prog laufen zu lassen...? Hab eine, brauchst du noch die Ergebnisse?

[ow]

Originally posted by Kennung Eins
Hab eine, brauchst du noch die Ergebnisse?

Klar, immer her damit;)

[aths]

Originally posted by Kennung Eins
Hab eine, brauchst du noch die Ergebnisse? Japp!

[Kennung Eins]

Rechner: 800MHz Pentium3, 384MB SDRam

GeForce4 MX 440 bei 270/400MHz
1024x768 Vollbildmodus, 64x Overdraw, erst 2, dann 4 Texturen, erst Front-to-Back, dann Back-to-Front

/---------- F2B ----------\ /---------- B2F ----------\
/---- 2 ----\ /---- 4 ----\ /---- 2 ----\ /---- 4 ----\
Pixel Texel Pixel Texel | Pixel Texel Pixel Texel
|
No AA 2139 4278 - - | 267 535 - -
2x AA 755 1488 - - | 133 267 - -
4x AA 419 839 - - | 72 144 - -Warum geht das nicht mit 4 Texturen?!

[Demirug]

Originally posted by Kennung Eins
Warum geht das nicht mit 4 Texturen?!

Weil die MX nur 2 Texturen pro Pass kann und das Testprogramm deswegen auf 2 limitiert.

[Kennung Eins]

Originally posted by Demirug


Weil die MX nur 2 Texturen pro Pass kann und das Textprogramm deswegen auf 2 limitiert. ah! :)

[aths]

Originally posted by Kennung Eins
Rechner: 800MHz Pentium3, 384MB SDRam

GeForce4 MX 440 bei 270/400MHz
1024x768 Vollbildmodus, 64x Overdraw, erst 2, dann 4 Texturen, erst Front-to-Back, dann Back-to-Front

/---------- F2B ----------\ /---------- B2F ----------\
/---- 2 ----\ /---- 4 ----\ /---- 2 ----\ /---- 4 ----\
Pixel Texel Pixel Texel | Pixel Texel Pixel Texel
|
No AA 2139 4278 - - | 267 535 - -
2x AA 755 1488 - - | 133 267 - -
4x AA 419 839 - - | 72 144 - -Warum geht das nicht mit 4 Texturen?! Hm.

Sehe ich das richtig, dass GeForce4 MX noch "richtiges" Early Z beherrscht?

[Demirug]

aths,

ich komme beim F2B auf fast 8 Pixel pro Takt. Da muss also schon eine Early-Z Einheit sein.

[Indiana]

[SIZE=1]Originally posted by aths
Sehe ich das richtig, dass GeForce4 MX noch "richtiges" Early Z beherrscht?

Warum nicht? Die GF4MX ist ja auch eher ein GF2-Abkömmling, denn ein GF4-Produkt.

[ow]

Originally posted by aths
Hm.

Sehe ich das richtig, dass GeForce4 MX noch "richtiges" Early Z beherrscht?

Das musss sie, ansonsten ist mit den 2 Pipes die doch recht hohe Leistung nicht zu erklären.
Frag mal 'Loewe' von Mitrax. Ich glaube, der hat sich schon ein paar Mal begeistert von der Effizienz der Gf4MX geäussert. Ich denke, du weisst, was das heisst.;)

[ow]

Originally posted by Indiana


Warum nicht? Die GF4MX ist ja auch eher ein GF2-Abkömmling, denn ein GF4-Produkt.

Mir erschliesst sich der Sinn dieses Postings nicht ganz.
Die GF2 haben kein early-Z, die GF4 angeblich schon.

[Demirug]

Originally posted by ow


Das musss sie, ansonsten ist mit den 2 Pipes die doch recht hohe Leistung nicht zu erklären.
Frag mal 'Loewe' von Mitrax. Ich glaube, der hat sich schon ein paar Mal begeistert von der Effizienz der Gf4MX geäussert. Ich denke, du weisst, was das heisst.;)

Mit 2 Pipes 8 Pixel pro Takt zu verwerfen ist auch nicht schlecht. Hört sich so an als hätte die MX die Early-Z Einheit von der GF3 bekommen.

[ow]

Originally posted by Demirug


Mit 2 Pipes 8 Pixel pro Takt zu verwerfen ist auch nicht schlecht. Hört sich so an als hätte die MX die Early-Z Einheit von der GF3 bekommen.

Ja, wenn ich die F2B Werte der Gf4MX440 mit denen der Gf3ti200 von Xmas vergleiche könnte das hinkommen (ich hab jetzt nix gerechnet:D).

[Indiana]

Originally posted by ow


Mir erschliesst sich der Sinn dieses Postings nicht ganz.
Die GF2 haben kein early-Z, die GF4 angeblich schon.

Das war auch ein Tippfehler, sollte GF3-Abkömmling heißen...

[aths]

Hat der Demirug ein einleuchtende Erklärung, warum die MX über "richtiges" Early Z verfügt, im Gegensatz zur Ti? Mir ist das jetzt nämlich total schleierhaft - denn bei der MX ist mir bekannt, dass brutal auf den Transistor-Count geachtet wurde.

[Demirug]

Aufgrund der Beschrängungen der MX (kein Loopback, kein nachträgliches Ändern von Z) müsste sich besagte Early-Z Einheit sehr leicht und ohne grossen Mehraufwand einbauen lassen.

[aths]

Originally posted by Demirug
Aufgrund der Beschrängungen der MX (kein Loopback, kein nachträgliches Ändern von Z) müsste sich besagte Early-Z Einheit sehr leicht und ohne grossen Mehraufwand einbauen lassen. Hm, ja. (Nur eben, dass GF3 auch nachträgliches Ändern von Z erlaubt, und Loopback oder Pipeline Combining nutzt... ach ist das alles unverständlich.)

[Demirug]

ja aths, die GF3 kann das alles deswegen ist die Early-Z Einheit dort auch komplizierter. Beim der GF4MX hat man davon wohl nur den Teil eingebaut den man auch nutzen kann. Wodurch die Einheit natürlich kleiner als das Gegenstück aus der GF3 sein sollte.

[Quasar]

Und so wie's ausschaut, rächt sich dies wieder bei der Füllrate unter 2xFSAA. aths' Ti4k6 bricht nicht ein, während Kennung Eins' 4MX ziemlich absackt...

[Demirug]

Originally posted by Quasar
Und so wie's ausschaut, rächt sich dies wieder bei der Füllrate unter 2xFSAA. aths' Ti4k6 bricht nicht ein, während Kennung Eins' 4MX ziemlich absackt...

Ja sobald man FSAA einschaltet ist der Early-Z Vorteil komplett weg. Selbst beim 2xFSAA bleibt nichts mehr übrig da man für das 2xRG zwar nur 2 Z-Einheiten des OG braucht die anderen beiden aber nicht mehr anderweitig nutzen kann.

[ow]

Originally posted by Quasar
Und so wie's ausschaut, rächt sich dies wieder bei der Füllrate unter 2xFSAA. aths' Ti4k6 bricht nicht ein, während Kennung Eins' 4MX ziemlich absackt...


Einbrechen ja, aber F2B ist dennoch wesentlich fixer als F2B, was bei der GF4ti ja nicht der Fall ist (bei 150/350 Taktung).

/edit: @Demi: wieso ist der Vorteil komplett weg? F2B ist doch 6x so schnell wie B2F.

[Unregistered]

Nee, ich geh jetzt mal nicht von der ProMHz-Leistung aus, sondern den absoluten Werten, und da ist die Pixelfillrate der GF4Ti im Gegensatz zur MX absolut unbeeindruck von 2xFSAA...

[Quasar]

Grrr....wer hat da meinen Keks gefressen?

[ow]

Originally posted by Unregistered
Nee, ich geh jetzt mal nicht von der ProMHz-Leistung aus, sondern den absoluten Werten, und da ist die Pixelfillrate der GF4Ti im Gegensatz zur MX absolut unbeeindruck von 2xFSAA...

Das schon, aber ich denke, dass early-Z insbesondere im vergleich F2B vs. B2F rendering zu sehen ist.
(Der Kyro macht da eine Ausnahme, ihm ist es in diesem Test hier egal ob B2F oder F2B.)

[Demirug]

ow, ja du hast recht ich habe mit dem GF3 Zahlen gerechnet. Wobei ich die B2F Zahlen gar nicht berücksichtige weil dort in der regel die Bandbreiten eng wird.

mit den richtigen Zahlen ergibt sich bei 2xFSAA immer noch ein Vorteil. Das läst darauf schliessen das die Early-Z Einheit für die MX doch noch etwas modifiziert wurde. IMO wurde bei der GF4MX wohl doch mehr umgebaut wie mancher geglaubt hat.

[ow]

Originally posted by Demirug
ow, ja du hast recht ich habe mit dem GF3 Zahlen gerechnet. Wobei ich die B2F Zahlen gar nicht berücksichtige weil dort in der regel die Bandbreiten eng wird.



Macht die Bandbreite bei B2F soviel aus, wie in den GF4MX Zahlen zu sehen?
Dass Z- und FB-Writes eingespart werden bei F2B ist mir klar, aber auf meiner Gf2MX ist der Unterschied ja wesentlich geringer trotz geringerer Bandbreite im Vergleich zur 4MX.
Oder limitiert hier imer das SDRAM der Gf2MX, also auch bei F2B?

[aths]

Ok, dann ist die nV-Werbung, die MX würde nur rendern was sichtbar sei (dass dazu F2B-Sorting notwendig ist, sagten sie nicht...) im Launch-Video offenbar nicht gelogen :)

[ow]

Originally posted by aths
Ok, dann ist die nV-Werbung, die MX würde nur rendern was sichtbar sei (dass dazu F2B-Sorting notwendig ist, sagten sie nicht...) im Launch-Video offenbar nicht gelogen :)



Ist early-Z nicht ohnehin nur bei F2B-Sorting von Nutzen?
Bei B2F können doch per early-Z gar keine Pixel verworfen werden, oder?

[Kennung Eins]

Oh so eine Shice...ich hatte zwecks NWN mein VSync noch angeschaltet - hier von der GF4MX nochmal die Ergebnisse - diesmal Vsync=off.
(Bei der GF3 hatte ich den selben Fehler gemacht, aber da haben wir ja noch Xmas' Ergebnisse.)

GeForce4 MX bei 270/400MHz
1024x768 Vollbildmodus, 64x Overdraw, erst 2, dann 4 Texturen, erst Front-to-Back, dann Back-to-Front
/---------- F2B ----------\ /---------- B2F ----------\
/---- 2 ----\ /---- 4 ----\ /---- 2 ----\ /---- 4 ----\
Pixel Texel Pixel Texel | Pixel Texel Pixel Texel
|
No AA 3116 6233 - - | 271 542 - -
2x AA 1462 2924 - - | 134 268 - -
4x AA 727 1455 - - | 67 134 - -Macht dann sogar fast 12 Pix / Takt.

[aths]

Originally posted by Kennung Eins
Macht dann sogar fast 12 Pix / Takt. Öhm. Wenn das so weiter geht, verscherbel ich meine Ti bei ebay und kaufe eine MX... :eyes:

[Quasar]

Mich würden jetzt mal Werte mit realistischem Overdraw interessieren. Nicht dass sich am Prinzip etwas ändern würde, aber bei 64x Overdraw und Vernachlässigung der Bandbreite müsste ja nun eine MX schneller als eine Ti sein... :eyes:

[Demirug]

Oh, was habe ich nur wieder angerichtet.

Wenn ich mir vorstellen NVIDIA hätte den ganzen Kremple noch in die TI reinbekommen und es hätte wirklich noch was gebracht. Aber das wird wohl ewig ein Geheimniss bleiben.

[Kennung Eins]

Nur mal um ein bisschen Realismus in die Sache zu bringen:

Neverwinter Nights läuft auf dem PIII 800 mit GF4MX spürbar schneller unter 2x AA (ohne AF) als meine GF3 auf nem XP 1600+ mit 2xAA ...

[ow]

Originally posted by aths
Öhm. Wenn das so weiter geht, verscherbel ich meine Ti bei ebay und kaufe eine MX... :eyes:

:D

Ich glaube, mir ist jetzt auch klar, warum die 4MX nur 2 Pipes hat. Mit vieren käme die ti arg in Bedrängnis.

[StefanV]

Originally posted by aths
Öhm. Wenn das so weiter geht, verscherbel ich meine Ti bei ebay und kaufe eine MX... :eyes:

:rofl:

BTW: warum keine R300?? ;)

[Kennung Eins]

Originally posted by aths
Öhm. Wenn das so weiter geht, verscherbel ich meine Ti bei ebay und kaufe eine MX... :eyes: Vielleicht übernehmen die dann für den NV30 viel mehr vom NV17/18 als vom NV25/28 :D

[Ikon]

Mich würde interessieren, wo sich dieser Vorteil der 4MX in der Praxis zeigt. Offenbar arbeitet 2xAA effizienter als auf GF3/4TI aber ist das alles? (nicht dass das wenig wäre)

[aths]

Originally posted by Ikon
Mich würde interessieren, wo sich dieser Vorteil der 4MX in der Praxis zeigt. Offenbar arbeitet 2xAA effizienter als auf GF3/4TI aber ist das alles? (nicht dass das wenig wäre) Nicht direkt das AA ist effizienter, sondern es funktioniert eben weiterhin noch Early Z vernünftig.

[aths]

Originally posted by aths
Demi, könntest du da nicht auch ein Tool schreiben? Statt Multitexturing einfach einen Pixelshader, der wahlweise 2 oder 4 Texturen nutzt, und wahlweise 2, 4 oder 8 Befehle ausführt?http://www.clanintern.de/extern/smile/Hail.gif... Demi?

[Demirug]

@aths

Sorry habe ich übersehen. Ja kann ich machen.

EDIT:

http://demirug.bei.t-online.de/ZOverdraw.zip

neue Option:

Stages

9 = mehr
3 = weniger

Damit können zusätzlich zum Texturblending weitere Anweisungen hinzugefügt werden. Derzeit werden dafür nur die DX7 Funktionen benutzt. Technisch macht das aber keinen unterschied. Eine "richtige" DX8 Version gibt es wenn ich etwas mehr Zeit habe.

[aths]

*Mit testen anfang...* :)

[aths]

Hm, also mit mehreren Stages sinkt die Füllrate etwas, mehr habe ich nicht beobachten können.

64x Overdraw, 2 Texturen, Stages 1: Ca. 590 MP // 1180 MT
64x Overdraw, 2 Texturen, Stages 4: Ca. 395 MP // 790 MT

Was lehrt uns das nun? Sehe ich das richtig, dass "ein wenig" Early Z zu sehen ist?

[Demirug]

Originally posted by aths
Hm, also mit mehreren Stages sinkt die Füllrate etwas, mehr habe ich nicht beobachten können.

64x Overdraw, 2 Texturen, Stages 1: Ca. 590 MP // 1180 MT
64x Overdraw, 2 Texturen, Stages 4: Ca. 395 MP // 790 MT

Was lehrt uns das nun? Sehe ich das richtig, dass "ein wenig" Early Z zu sehen ist?

Nein, da ist kein Fillrate gewinn zu sehen:

300MHz*4 Pipelines*2 ALUs = 2400 M Ops/s

2 Texturen + 1 Stage = 3 Ops. PS auf dem NV25 werden aber immer auf ein vielfaches von 2 aufgerundet = 4 Ops.

2400 MOps/s / 4 = 600 MPixel/s

2 Texturen + 4 Stages = 6 Ops.

2400 MOps/s / 6 = 400 MPixel/s

Passt also

[aths]

Originally posted by Demirug
Passt also GeForce4 Ti hat also offenbar gar kein Early Z mehr :bonk: Das finde ich ziemlich armselig von nVidia.

[Demirug]

Originally posted by aths
GeForce4 Ti hat also offenbar gar kein Early Z mehr :bonk: Das finde ich ziemlich armselig von nVidia.

Das Early Z der GF4 spart zumindestens keine fillrate ein. Bandbreiten einsparungen sind aber durchaus noch möglich.

[Unregistered]

Originally posted by aths
GeForce4 Ti hat also offenbar gar kein Early Z mehr :bonk: Das finde ich ziemlich armselig von nVidia.


Und ich finde die GF4 Leitung einfach beeindruckend, R9700 Leistung OHNE richtiges early-z, das soll erst mal jemand nachmachen.

[aths]

Originally posted by Demirug
Das Early Z der GF4 spart zumindestens keine fillrate ein. Bandbreiten einsparungen sind aber durchaus noch möglich. An welcher Stelle? Ich darf doch annehmen, dass die Pipelines nicht im Leerlauf arbeiten, wenn sich herausstellt, dass das Pixel ohnehin unsichtbar ist?

Wie könnte man nachmessen, ob Bandbreite gespart wird?

[aths]

Originally posted by Unregistered
Und ich finde die GF4 Leitung einfach beeindruckend, R9700 Leistung OHNE richtiges early-z, das soll erst mal jemand nachmachen. Nur in CPU-limitierten Szenarien.

[MeLLe]

Originally posted by aths
An welcher Stelle? Ich darf doch annehmen, dass die Pipelines nicht im Leerlauf arbeiten, wenn sich herausstellt, dass das Pixel ohnehin unsichtbar ist?
Wenn es kein Early-Z gibt, stellt sich doch IMHO erst am Ende der Pipeline heraus, ob das Pixel sichtbar ist oder nicht. Damit gibt es grundsätzlich keinen Pipe-Leerlauf.

Originally posted by aths
Wie könnte man nachmessen, ob Bandbreite gespart wird?
Bandbreite wird IMHO nur dadurch gespart, weil am Ende der Pipeline beim Z-Test die unsichtbaren Pixel eben nicht in den FB geschrieben werden. Die Einsparung an dieser Stelle halte ich aber für marginal.
Aber wie man das misst? Demiiiiiiiiiiiiiiiiiiiiiiiiiiiii.... ;)

[Demirug]

Die Bandbreiten einsparung ist nur im Bereich des Texturfetchs möglich. Wenn dieser für durch das Early-Z verworfenen Pixel deaktiviert wird läst sich schon etwas einsparen. Messtechnisch ist das ganze aber schwer zu messen weil ja beim B2F und F2B sowieso schon unterschiedliche anforderungen an die Bandbreite gestellt werden. Man müsste also beim F2B rendern einmal mit und einmal ohne Early-Z sowie mit grossen Texturen die nicht in den Cache passen messen.

MeLLe, die einsparungen welche durch das F2B im verhältniss zum B2F erreicht werden sind nicht so gering das man sie nicht berücksichtigen müsste. Pro Pixel und Overdraw-Level fallen immer 8 Byte (Frame+Z) weg.

[MeLLe]

Originally posted by Demirug
MeLLe, die einsparungen welche durch das F2B im verhältniss zum B2F erreicht werden sind nicht so gering das man sie nicht berücksichtigen müsste. Pro Pixel und Overdraw-Level fallen immer 8 Byte (Frame+Z) weg.
Okay, wenn ich nochmal drüber nachdenke muss ich Dir sogar recht geben. Hmpf. Und das am Sonntag Morgen. :| ;)

[aths]

Originally posted by MeLLe
Bandbreite wird IMHO nur dadurch gespart, weil am Ende der Pipeline beim Z-Test die unsichtbaren Pixel eben nicht in den FB geschrieben werden. Das macht ohnehin kein 3D-Beschleuniger.

[aths]

Originally posted by Demirug
Die Bandbreiten einsparung ist nur im Bereich des Texturfetchs möglich. Wenn dieser für durch das Early-Z verworfenen Pixel deaktiviert wird läst sich schon etwas einsparen.Was ich hierbei nicht verstehe ist, wenn schon im Vorhinein erkannt wird dass das Pixel unsichtbar ist, was das Sparen der Texturbandbreite dann noch groß bringen soll. Die Pipelines sind ohnehin die ganzen Takte beschäftigt. Ob es nun effektiver ist, für einige der 4 Pipelines je nach Early Z Test den Texturfetch abzuschalten, als zu prüfen ob alle Pipelines an unsichtbaren Pixeln arbeiten und dann sofort weiter zu machen... Wenn ich das richtig verstehe, nützt der Z-Pass beim Doom3 auch, um die vielen langen Shader rechtzeitig zu canceln. Bei genügend hohem Overdraw müsste dann ja eine GeForce3 (Ti500) eine GeForce4 Ti überholen...

[MeLLe]

Originally posted by aths
Das macht ohnehin kein 3D-Beschleuniger.
Wär ja auch Quatsch. :bonk:
Sorry aber ich glaub ich war heut Morgen noch net richtig munter ;)

[Demirug]

Originally posted by aths
Was ich hierbei nicht verstehe ist, wenn schon im Vorhinein erkannt wird dass das Pixel unsichtbar ist, was das Sparen der Texturbandbreite dann noch groß bringen soll. Die Pipelines sind ohnehin die ganzen Takte beschäftigt. Ob es nun effektiver ist, für einige der 4 Pipelines je nach Early Z Test den Texturfetch abzuschalten, als zu prüfen ob alle Pipelines an unsichtbaren Pixeln arbeiten und dann sofort weiter zu machen... Wenn ich das richtig verstehe, nützt der Z-Pass beim Doom3 auch, um die vielen langen Shader rechtzeitig zu canceln. Bei genügend hohem Overdraw müsste dann ja eine GeForce3 (Ti500) eine GeForce4 Ti überholen...

Wir haben ja inzwsichen rausgefunden das die GF4 keine Fillrate sparen kann. Darum sind die Pipelines auch beschäftigtaber teilweise nur mit Pixel die definitive nicht rausgeschreiben werden. Wird für solche Pixel die TMU zwar Takttechnisch durchlaufen aber ihr der Speicherzugriff verwehrt verursachen die Texturfetchs für Early-Z Pixel keine Bandbreiten verbrauch. Aufwendig ist das nicht da man nur ein paar Signale umbiegen muss. Die gesparte Bandbreite kann anderweitig genutzt werden. Natürlich nur wenn gerade ein anderer Teil des Chips bandbreite braucht. Aber gerade beim 4x AA braucht man ja durchaus schon eine menge Bandbreite um nur die Z-Werte für den Z-Compare einzuladen. Ich habe auch schon eine Idee wie man den Test dafür ändern könnte um das nachzuprüfen.

Was nun DOOM III angeht so ist der Z-Pass da nicht drin um irgendwas zu beschleunigen. Jede Beschleunigung welche durch Early-Z einheiten erreicht wird ist eine willkommener Nebeneffekt aber nicht beabsichtigt. Der Z-Pass ist für die Schatten einfach notwendig.

[aths]

Originally posted by Demirug
Aber gerade beim 4x AA braucht man ja durchaus schon eine menge Bandbreite um nur die Z-Werte für den Z-Compare einzuladen. Ich habe auch schon eine Idee wie man den Test dafür ändern könnte um das nachzuprüfen.Das wäre toll. Denn da selbst auf GeForce4 Ti 4600 schon 2x AA bis zu 30% Framerate kosten kann (z.B. Quake3 Demo001 @1600x1200) halte ich es "aus dem Bauch" heraus erst mal für unwahrscheinlich, dass die Karte ein Bandbreiten sparendes Early Z hat. Ein Test würde das klären :)

[tb]

Hallo!

Ich habe mir für meine Reviews einen DX9 Overdraw Benchmark geschrieben. Keine Ahnung ob jemand von Euch damit was anfangen kann. Läuft leider nur under DX9, benötigt aber nur DX8.1 HW, sprich Vertex und Pixel Shader der Version 1.1. Es werden bump mapping Objekte(jeweils 2 Durchläufe wegen transparentem Schatten) dargestellt, kann man aber auch deaktivieren. Rendermodi:

back to front
font to back
50 % font to back + 50 % back to front

kombinierbar mit einem 2 Pass Modus, welche fix den Z-Buffer füllt (Objekte ohne Texturen und Beleuchtung rendert) und im zweiten Pass dann die normale Darstellung vornimmt. Overdrawlevel ist einstellbar.
Anzahl der tatsächlich dargestellen Pixel pro Sekunde wird angezeigt (D3DQUERYTYPE_OCCLUSION).

http://www.tommti-systems.de/main-Dateien/TOOLS/Overdraw.sfx.exe

Thomas

[aths]

Bei mir sagt er:

[tb]

Originally posted by aths
Bei mir sagt er:

Hab die Version nochmal optimiert und bessere Texturen verwendet, damit auch die Texelfüllrate nicht zu kurz kommt.
Doch hast doch ne GeForce 4 mit den neuesten Treibern, oder? Sieht so aus, als ob NVIDIA dieses Feature (noch) nicht implementiert hat, obwohl beim Gun Metal Demo (DX8 Demo wirbt für DX9 Features -> Marketing) damit geworben wird.... Auf der Radeon 9500/9700 und möglichweise auch der Radeon 8500 - 9000 sollte es gehen. Gibt's für die Parhelia schon DX9 Treiber? Ich werd das Teil morgen offiziell anbieten. Somit bleiben Dir nur die FPS, je nach Sortierung und mit oder ohne "2 Pass Technik"...

Thomas

[ow]

Originally posted by aths
Bei mir sagt er:


Du musst auch nen DX9 treiber verwenden (also ab 41.80).
Damit geht´s bei mir.

*ow*

[Unregistered]

Originally posted by tb


Hab die Version nochmal optimiert und bessere Texturen verwendet, damit auch die Texelfüllrate nicht zu kurz kommt.
Doch hast doch ne GeForce 4 mit den neuesten Treibern, oder? Sieht so aus, als ob NVIDIA dieses Feature (noch) nicht implementiert hat, obwohl beim Gun Metal Demo (DX8 Demo wirbt für DX9 Features -> Marketing) damit geworben wird.... Auf der Radeon 9500/9700 und möglichweise auch der Radeon 8500 - 9000 sollte es gehen. Gibt's für die Parhelia schon DX9 Treiber? Ich werd das Teil morgen offiziell anbieten. Somit bleiben Dir nur die FPS, je nach Sortierung und mit oder ohne "2 Pass Technik"...

Thomas


s.o.
Das funzt schon auf GF4 Karten, aber der Treiber muss DX9 sein. Bis zum Deto 41.09 wird es nicht unterstuetzt.

[Ikon]

Auf der Radeon8500 läuft's wie am Schnürchen, wie bereits angenommen (mit DX9 & Catalyst 3.0).

[aths]

Originally posted by ow
Du musst auch nen DX9 treiber verwenden (also ab 41.80).
Damit geht´s bei mir.Ok, ich habe im Moment nur 41.09 drauf, daran liegts dann wohl.

[ow]

Originally posted by aths
Ok, ich habe im Moment nur 41.09 drauf, daran liegts dann wohl.

Jep, mit dem 41.09 sagt er bei mir dasselbe wie bei dir. Der 41.09 meldet auch nur ein DX8 Interface (-> dxdiag). Mit dem 41.80 & 42.01 (DX9 treiber) funzt das.

[aths]

Originally posted by ow
Jep, mit dem 41.09 sagt er bei mir dasselbe wie bei dir. Der 41.09 meldet auch nur ein DX8 Interface (-> dxdiag). Mit dem 41.80 & 42.01 (DX9 treiber) funzt das. Hm, ich warte lieber bis diese Treiber offiziell sind.

[ow]

Originally posted by aths
Hm, ich warte lieber bis diese Treiber offiziell sind.

Der 42.01 für Win98 läuft bis jetzt absolut problemlos bei mir (ausser das App-erzwungenes Quincux AA (Einstellung: 3Samples) unter DX9-Apps zu einem 'generic application error' führt (2/4 Samples funzen )).

Im übrigen denke ich, dass es ein offizieller Treiber ist, da Multilanguage-Version.
Die echten inoffiziellen Leaks/Betas können meist nur englisch.


/edit:
also Werte für o.g. Prog kann ich liefern, ich hab aber keine Ahnung, wie man die interpretiert.:D

/edit2:
ausserdem schlage mal jemand ein paar Standard-Einstellungen vor, damit wir hier vergleichbare Resultate mit unterschiedlichen Karten bekommen.

[ow]

OK, also dann leg ich mal vor.:D

GF4ti4200 (Deto 42.01, Win98), AMD XP1700, KT133A

Einstellungen:

window (500x300x32), Overdraw 8 (default), shadow/bump on


b->f: ~51fps 29Mio Pixel/s 21.657.600 tris/s
f->b: ~51.5fps 10Mio Pixel/s 22.090.752 tris/s
50% : ~51fps 29Mio Pixel/s 21.657.600 tris/s
2-pass: ~41fps 27Mio Pixel/s 26.638.848 tris/s


/edit: mit 2xAA


b->f: ~45fps 85Mio Pixel/s 19.491.840 tris/s
f->b: ~46.5fps 19Mio Pixel/s 19.924.992 tris/s
50% : ~46fps 53Mio Pixel/s 19,924.992 tris/s
2-pass: ~37fps 50Mio Pixel/s 24.039.936 tris/s

[tb]

@ow

Ist das Standardfenster nich 400x300 ?

Ich habs mal im default Vollbildmodus laufen lassen.
1024x768x32, Overdraw 8, Shadow & Bump an
Athlon XP 1800+, SiS735, 512 MB PC266, Radeon 9700 PRO, WinXP, 6275'er Treiber

ohne FSAA:

B->F (1 Pass) 35 fps 202 Mio pixel/s 15 Mio tri/s
B->F (2 Pass) 44 fps 282 Mio pixel/s 28 Mio tri/s

50% (1 Pass) 44 fps 155 Mio pixel/s 18,6 Mio tri/s
50% (2 Pass) 45 fps 183 Mio pixel/s 29,2 Mio tri/s

F->B (1 Pass) 60 fps 77 Mio pixel/s 26 Mio tri/s
F->B (2 Pass) 48 fps 90 Mio pixel/s 30 Mio tri/s

2x FSAA:

B->F (1 Pass) 27 fps 174 Mio pixel/s 11 Mio tri/s
B->F (2 Pass) 31 fps 228 Mio pixel/s 19 Mio tri/s

50% (1 Pass) 35 fps 140 Mio pixel/s 14,7 Mio tri/s
50% (2 Pass) 34 fps 160 Mio pixel/s 20,7 Mio tri/s

F->B (1 Pass) 48 fps 70 Mio pixel/s 19 Mio tri/s
F->B (2 Pass) 37 fps 80 Mio pixel/s 22,7 Mio tri/s

Ich probiers jetzt mal im Fenster (400x300)...


400x300x32 Fenster, Overdraw 8, Shadow & Bump an

ohne FSAA:

B->F (1 Pass) 97 fps 87 Mio pixel/s 42 Mio tri/s
B->F (2 Pass) 87 fps 84 Mio pixel/s 57 Mio tri/s

50% (1 Pass) 103 fps 55 Mio pixel/s 44 Mio tri/s
50% (2 Pass) 88 fps 56 Mio pixel/s 57 Mio tri/s

F->B (1 Pass) 112 fps 21 Mio pixel/s 48 Mio tri/s
F->B (2 Pass) 90 fps 26 Mio pixel/s 58 Mio tri/s

2x FSAA:

B->F (1 Pass) 89 fps 108 Mio pixel/s 38 Mio tri/s
B->F (2 Pass) 80 fps 106 Mio pixel/s 51 Mio tri/s

50% (1 Pass) 97 fps 67 Mio pixel/s 42 Mio tri/s
50% (2 Pass) 82 fps 70 Mio pixel/s 53 Mio tri/s

F->B (1 Pass) 108 fps 27 Mio pixel/s 46 Mio tri/s
F->B (2 Pass) 86 fps 32 Mio pixel/s 54 Mio tri/s

Thomas

[Kennung Eins]

Könntest du noch ne Autobench-Funktion mit reinbasteln, die für alle genormte Settings benutzt? Dann muss man nicht immer alles von Hand aktivieren und umschalten.

[tb]

Originally posted by Kennung Eins
Könntest du noch ne Autobench-Funktion mit reinbasteln, die für alle genormte Settings benutzt? Dann muss man nicht immer alles von Hand aktivieren und umschalten.

Bin grad dabei...

[tb]

Overdraw - Z-Reject Tester v1.1 - ToMMTi-Systems (http://www.tommti-systems.com)

video mode / device info
(1024x768), X8R8G8B8 (D24X8)
HAL (pure hw vp): RADEON 9700/9500 SERIES

benchmark info
bump mapping: on
shadows: on
overdraw: 8


back to front
----------------------------------------------------------------------

1-pass: 37.81 fps 218.83 mio pixel/s 16.38 mio triangles/s
2-pass: 42.38 fps 272.52 mio pixel/s 27.53 mio triangles/s


50% back to front and 50% front to back
----------------------------------------------------------------------

1-pass: 44.00 fps 155.64 mio pixel/s 19.06 mio triangles/s
2-pass: 44.93 fps 187.86 mio pixel/s 29.19 mio triangles/s


front to back
----------------------------------------------------------------------

1-pass: 57.92 fps 74.55 mio pixel/s 25.09 mio triangles/s
2-pass: 48.06 fps 92.78 mio pixel/s 31.22 mio triangles/s


video mode / device info
(1024x768), X8R8G8B8 (D24X8) (2x Multisample)
HAL (pure hw vp): RADEON 9700/9500 SERIES

benchmark info
bump mapping: on
shadows: on
overdraw: 8



back to front
----------------------------------------------------------------------

1-pass: 29.94 fps 199.22 mio pixel/s 12.97 mio triangles/s
2-pass: 30.80 fps 226.12 mio pixel/s 20.01 mio triangles/s


50% back to front and 50% front to back
----------------------------------------------------------------------

1-pass: 34.64 fps 140.26 mio pixel/s 15.00 mio triangles/s
2-pass: 33.69 fps 161.11 mio pixel/s 21.89 mio triangles/s


front to back
----------------------------------------------------------------------

1-pass: 45.97 fps 67.76 mio pixel/s 19.91 mio triangles/s
2-pass: 37.07 fps 82.05 mio pixel/s 24.09 mio triangles/s



video mode / device info
(1024x768), X8R8G8B8 (D24X8) (4x Multisample)
HAL (pure hw vp): RADEON 9700/9500 SERIES

benchmark info
bump mapping: on
shadows: on
overdraw: 8



back to front
----------------------------------------------------------------------

1-pass: 22.67 fps 161.52 mio pixel/s 9.82 mio triangles/s
2-pass: 21.63 fps 171.48 mio pixel/s 14.06 mio triangles/s


50% back to front and 50% front to back
----------------------------------------------------------------------

1-pass: 26.22 fps 114.43 mio pixel/s 11.36 mio triangles/s
2-pass: 23.71 fps 122.31 mio pixel/s 15.41 mio triangles/s


front to back
----------------------------------------------------------------------

1-pass: 33.71 fps 53.55 mio pixel/s 14.60 mio triangles/s
2-pass: 26.28 fps 62.65 mio pixel/s 17.08 mio triangles/s



So, neue Version ist fertig. Link bleibt gleich.

Thomas

[ow]

Originally posted by tb
@ow

Ist das Standardfenster nich 400x300 ?


Thomas

Doch, aber da hat die Anzeige der tris/s nicht ganz reingepasst, lso hab ich´s um 100 Pixel verbreitert.:D

Jettz hab ich auch verstanden, wie man da benchen muss, 2-pass ist also nur ein toggle und arbeitet mit b-f, f-b, 50%.
Also erhält man insgesamt 6 Resultate.

Ich werd´s heute abend mal mit den neuen version durchbenchen.

*ow*

[ow]

Ok, mein GF4ti4200 Äquivalent zu Thomas´ Benches:






Overdraw - Z-Reject Tester v1.1 - ToMMTi-Systems (http://www.tommti-systems.com)

video mode / device info
(1024x768), X8R8G8B8 (D24X8)
HAL (pure hw vp): NVIDIA GeForce4 Ti 4200

benchmark info
bump mapping: on
shadows: on
overdraw: 8



back to front
----------------------------------------------------------------------

1-pass: 15.87 fps 91.82 mio pixel/s 6.87 mio triangles/s
2-pass: 14.24 fps 91.56 mio pixel/s 9.25 mio triangles/s


50% back to front and 50% front to back
----------------------------------------------------------------------

1-pass: 15.94 fps 56.39 mio pixel/s 6.90 mio triangles/s
2-pass: 14.29 fps 59.74 mio pixel/s 9.28 mio triangles/s


front to back
----------------------------------------------------------------------

1-pass: 16.26 fps 20.92 mio pixel/s 7.04 mio triangles/s
2-pass: 14.35 fps 27.71 mio pixel/s 9.33 mio triangles/s



video mode / device info
(1024x768), X8R8G8B8 (D24X8) (2x Multisample)
HAL (pure hw vp): NVIDIA GeForce4 Ti 4200

benchmark info
bump mapping: on
shadows: on
overdraw: 8



back to front
----------------------------------------------------------------------

1-pass: 13.15 fps 152.27 mio pixel/s 5.70 mio triangles/s
2-pass: 11.40 fps 146.68 mio pixel/s 7.41 mio triangles/s


50% back to front and 50% front to back
----------------------------------------------------------------------

1-pass: 13.39 fps 94.70 mio pixel/s 5.80 mio triangles/s
2-pass: 11.92 fps 99.71 mio pixel/s 7.75 mio triangles/s


front to back
----------------------------------------------------------------------

1-pass: 14.01 fps 36.08 mio pixel/s 6.07 mio triangles/s
2-pass: 12.50 fps 48.28 mio pixel/s 8.12 mio triangles/s



video mode / device info
(1024x768), X8R8G8B8 (D24X8) (4x Multisample)
HAL (pure hw vp): NVIDIA GeForce4 Ti 4200

benchmark info
bump mapping: on
shadows: on
overdraw: 8



back to front
----------------------------------------------------------------------

1-pass: 10.73 fps 248.43 mio pixel/s 4.65 mio triangles/s
2-pass: 9.30 fps 239.33 mio pixel/s 6.04 mio triangles/s


50% back to front and 50% front to back
----------------------------------------------------------------------

1-pass: 11.35 fps 160.66 mio pixel/s 4.92 mio triangles/s
2-pass: 10.05 fps 168.08 mio pixel/s 6.53 mio triangles/s


front to back
----------------------------------------------------------------------

1-pass: 12.56 fps 64.69 mio pixel/s 5.44 mio triangles/s
2-pass: 10.92 fps 84.32 mio pixel/s 7.09 mio triangles/s



Ich warte auf Interpretationen.:D

[Achill]

Denke man kann es schlecht vergleichen, ist anscheinend sehr CPU-abhänig...

Hier mal meine Werte, Radeon war Standardtakt und P4@2555Mhz.


Overdraw - Z-Reject Tester v1.1 - ToMMTi-Systems (http://www.tommti-systems.com)

video mode / device info
(1024x768), X8R8G8B8 (D24X8)
HAL (pure hw vp): RADEON 9700/9500 Series (Omega 2.3.55) (0xAA)

benchmark info
bump mapping: on
shadows: on
overdraw: 8

back to front
----------------------------------------------------------------------

1-pass: 51.12 fps 295.85 mio pixel/s 22.14 mio triangles/s
2-pass: 47.56 fps 305.87 mio pixel/s 30.90 mio triangles/s

50% back to front and 50% front to back
----------------------------------------------------------------------

1-pass: 54.50 fps 192.77 mio pixel/s 23.61 mio triangles/s
2-pass: 50.03 fps 209.15 mio pixel/s 32.50 mio triangles/s

front to back
----------------------------------------------------------------------

1-pass: 65.10 fps 83.80 mio pixel/s 28.20 mio triangles/s
2-pass: 53.01 fps 102.35 mio pixel/s 34.44 mio triangles/s





Overdraw - Z-Reject Tester v1.1 - ToMMTi-Systems (http://www.tommti-systems.com)

video mode / device info
(1024x768), X8R8G8B8 (D24X8)
HAL (pure hw vp): RADEON 9700/9500 Series (Omega 2.3.55) (2xAA)

benchmark info
bump mapping: on
shadows: on
overdraw: 8

back to front
----------------------------------------------------------------------

1-pass: 30.33 fps 201.12 mio pixel/s 13.14 mio triangles/s
2-pass: 33.50 fps 246.68 mio pixel/s 21.76 mio triangles/s

50% back to front and 50% front to back
----------------------------------------------------------------------

1-pass: 41.79 fps 168.95 mio pixel/s 18.10 mio triangles/s
2-pass: 36.55 fps 174.92 mio pixel/s 23.74 mio triangles/s

front to back
----------------------------------------------------------------------

1-pass: 50.53 fps 74.51 mio pixel/s 21.89 mio triangles/s
2-pass: 40.35 fps 89.06 mio pixel/s 26.21 mio triangles/s





Overdraw - Z-Reject Tester v1.1 - ToMMTi-Systems (http://www.tommti-systems.com)

video mode / device info
(1024x768), X8R8G8B8 (D24X8)
HAL (pure hw vp): RADEON 9700/9500 Series (Omega 2.3.55) (4xAA)
benchmark info
bump mapping: on
shadows: on
overdraw: 8

back to front
----------------------------------------------------------------------

1-pass: 28.99 fps 206.02 mio pixel/s 12.56 mio triangles/s
2-pass: 22.97 fps 182.22 mio pixel/s 14.92 mio triangles/s

50% back to front and 50% front to back
----------------------------------------------------------------------

1-pass: 30.68 fps 133.83 mio pixel/s 13.29 mio triangles/s
2-pass: 25.15 fps 129.73 mio pixel/s 16.34 mio triangles/s

front to back
----------------------------------------------------------------------

1-pass: 36.48 fps 57.94 mio pixel/s 15.80 mio triangles/s
2-pass: 27.94 fps 66.64 mio pixel/s 18.15 mio triangles/s

[tb]

Werd mal schauen, ob ich die CPU-Abhängigkeit veringern kann. Könnte auch am Compiler liegen (Intel C++ 7.0 mit aktivierten Optimierungen für den P4...)

Thomas

[Quasar]

video mode / device info
(1024x768), X8R8G8B8 (D24X8)
HAL (pure hw vp): RADEON 9000 PRO

benchmark info
bump mapping: on
shadows: on
overdraw: 8

back to front
----------------------------------------------------------------------

1-pass: 9.75 fps 56.43 mio pixel/s 4.22 mio triangles/s
2-pass: 8.76 fps 56.36 mio pixel/s 5.69 mio triangles/s


50% back to front and 50% front to back
----------------------------------------------------------------------

1-pass: 9.79 fps 34.63 mio pixel/s 4.24 mio triangles/s
2-pass: 8.79 fps 36.76 mio pixel/s 5.71 mio triangles/s


front to back
----------------------------------------------------------------------

1-pass: 9.96 fps 12.81 mio pixel/s 4.31 mio triangles/s
2-pass: 8.81 fps 17.02 mio pixel/s 5.73 mio triangles/s

Celeron 1,33GHz, W2k, DX9, Cat 3.0

[Quasar]

video mode / device info
(1024x768), X8R8G8B8 (D24X8)
HAL (pure hw vp): RADEON 8500 SERIES

benchmark info
bump mapping: on
shadows: on
overdraw: 8



back to front
----------------------------------------------------------------------

1-pass: 5.46 fps 31.60 mio pixel/s 2.36 mio triangles/s
2-pass: 5.20 fps 33.43 mio pixel/s 3.38 mio triangles/s


50% back to front and 50% front to back
----------------------------------------------------------------------

1-pass: 5.55 fps 19.63 mio pixel/s 2.40 mio triangles/s
2-pass: 5.28 fps 22.08 mio pixel/s 3.43 mio triangles/s


front to back
----------------------------------------------------------------------

1-pass: 5.70 fps 7.33 mio pixel/s 2.47 mio triangles/s
2-pass: 5.37 fps 10.37 mio pixel/s 3.49 mio triangles/s

P4-2,53GHz, WinXP, DX9, Cat3.0

[ow]

Also bei der 8500 klemmt irgendwas.:D

Die 9000er Werte können stimmen.

[tb]

Versuch doch mal den Overdraw zu veringern, so auf 2-3, vielleicht ändern sind die Resultate dann unterschiedlicher...

Thomas

[Quasar]

Leider werden bei mir am Startbildschirm die netten Bedien-Infos gar nicht angezeigt. Ich muss also quasi raten, welche Settings ich grade erwische....

[tb]

Originally posted by Quasar
Leider werden bei mir am Startbildschirm die netten Bedien-Infos gar nicht angezeigt. Ich muss also quasi raten, welche Settings ich grade erwische....

So, hab den Radeon 8500 Fehler beseitigt und möglichst viel CPU-Belastung rausgenommen. Die Vertex Shader haben jetzt etwas mehr Arbeit, aber außer den Treibern dürfte jetzt nix mehr die CPU benötigen. Auf meinem Athlon machen 400 Mhz (100 oder 133'er FSB) mehr oder weniger keinen Unterschied.


Athlon XP ~1100 Mhz

Overdraw - Z-Reject Tester v1.2 - ToMMTi-Systems (http://www.tommti-systems.com)

video mode / device info
(1024x768), X8R8G8B8 (D24X8)
HAL (pure hw vp): RADEON 9700/9500 SERIES

benchmark info
bump mapping: on
shadows: on
overdraw: 8


back to front
----------------------------------------------------------------------

1-pass: 36.56 fps 211.69 mio pixel/s 15.84 mio triangles/s
2-pass: 41.51 fps 267.04 mio pixel/s 26.97 mio triangles/s


50% back to front and 50% front to back
----------------------------------------------------------------------

1-pass: 43.04 fps 152.29 mio pixel/s 18.64 mio triangles/s
2-pass: 44.12 fps 184.54 mio pixel/s 28.67 mio triangles/s


front to back
----------------------------------------------------------------------

1-pass: 57.09 fps 73.51 mio pixel/s 24.73 mio triangles/s
2-pass: 47.13 fps 91.03 mio pixel/s 30.62 mio triangles/s


Athlon XP ~1500 Mhz

Overdraw - Z-Reject Tester v1.2 - ToMMTi-Systems (http://www.tommti-systems.com)

video mode / device info
(1024x768), X8R8G8B8 (D24X8)
HAL (pure hw vp): RADEON 9700/9500 SERIES

benchmark info
bump mapping: on
shadows: on
overdraw: 8



back to front
----------------------------------------------------------------------

1-pass: 36.77 fps 212.91 mio pixel/s 15.93 mio triangles/s
2-pass: 41.68 fps 268.13 mio pixel/s 27.08 mio triangles/s


50% back to front and 50% front to back
----------------------------------------------------------------------

1-pass: 43.07 fps 152.40 mio pixel/s 18.65 mio triangles/s
2-pass: 44.10 fps 184.44 mio pixel/s 28.65 mio triangles/s


front to back
----------------------------------------------------------------------

1-pass: 55.35 fps 71.26 mio pixel/s 23.97 mio triangles/s
2-pass: 47.06 fps 90.89 mio pixel/s 30.58 mio triangles/s



Thomas

[ow]

Hier meine Werte mit der neuen Version.



Overdraw - Z-Reject Tester v1.2 - ToMMTi-Systems (http://www.tommti-systems.com)

video mode / device info
(1024x768), X8R8G8B8 (D24X8)
HAL (pure hw vp): NVIDIA GeForce4 Ti 4200

benchmark info
bump mapping: on
shadows: on
overdraw: 8



back to front
----------------------------------------------------------------------

1-pass: 15.48 fps 89.60 mio pixel/s 6.70 mio triangles/s
2-pass: 13.74 fps 88.42 mio pixel/s 8.93 mio triangles/s


50% back to front and 50% front to back
----------------------------------------------------------------------

1-pass: 15.50 fps 54.84 mio pixel/s 6.71 mio triangles/s
2-pass: 13.88 fps 58.04 mio pixel/s 9.02 mio triangles/s


front to back
----------------------------------------------------------------------

1-pass: 15.76 fps 20.30 mio pixel/s 6.83 mio triangles/s
2-pass: 13.95 fps 26.94 mio pixel/s 9.06 mio triangles/s



Overdraw - Z-Reject Tester v1.2 - ToMMTi-Systems (http://www.tommti-systems.com)

video mode / device info
(1024x768), X8R8G8B8 (D24X8) (2x Multisample)
HAL (pure hw vp): NVIDIA GeForce4 Ti 4200

benchmark info
bump mapping: on
shadows: on
overdraw: 8



back to front
----------------------------------------------------------------------

1-pass: 12.68 fps 146.82 mio pixel/s 5.49 mio triangles/s
2-pass: 11.12 fps 143.11 mio pixel/s 7.23 mio triangles/s


50% back to front and 50% front to back
----------------------------------------------------------------------

1-pass: 12.99 fps 91.96 mio pixel/s 5.63 mio triangles/s
2-pass: 11.62 fps 97.22 mio pixel/s 7.55 mio triangles/s


front to back
----------------------------------------------------------------------

1-pass: 13.61 fps 35.05 mio pixel/s 5.89 mio triangles/s
2-pass: 12.17 fps 46.99 mio pixel/s 7.90 mio triangles/s



Overdraw - Z-Reject Tester v1.2 - ToMMTi-Systems (http://www.tommti-systems.com)

video mode / device info
(1024x768), X8R8G8B8 (D24X8) (4x Multisample)
HAL (pure hw vp): NVIDIA GeForce4 Ti 4200

benchmark info
bump mapping: on
shadows: on
overdraw: 8



back to front
----------------------------------------------------------------------

1-pass: 10.29 fps 238.23 mio pixel/s 4.46 mio triangles/s
2-pass: 9.04 fps 232.71 mio pixel/s 5.88 mio triangles/s


50% back to front and 50% front to back
----------------------------------------------------------------------

1-pass: 10.99 fps 155.59 mio pixel/s 4.76 mio triangles/s
2-pass: 9.77 fps 163.43 mio pixel/s 6.35 mio triangles/s


front to back
----------------------------------------------------------------------

1-pass: 12.14 fps 62.52 mio pixel/s 5.26 mio triangles/s
2-pass: 10.60 fps 81.92 mio pixel/s 6.89 mio triangles/s

[Quasar]

Woran hakte's denn bei der R8500?

edit:
Es hakt immer noch, auch mit der neuen Version ist die Performance so gut wie gleich geblieben!
Ausserdem: Wär's möglich, die Tasten für den Overdraw vom Nummernblock woanders hin zu legen? Ich hab' am R8500-Rechner nur eine Mini-Tastatur ohne Ziffernblock... :(



Hier erstmal neue Werte mit R9000pro, Celli 1,0GHz, W2k, DX9, Cat3.0


video mode / device info
(1024x768), X8R8G8B8 (D24X8)
HAL (pure hw vp): RADEON 9000 PRO

benchmark info
bump mapping: on
shadows: on
overdraw: 8



back to front
----------------------------------------------------------------------

1-pass: 9.65 fps 55.87 mio pixel/s 4.18 mio triangles/s
2-pass: 8.56 fps 55.06 mio pixel/s 5.56 mio triangles/s


50% back to front and 50% front to back
----------------------------------------------------------------------

1-pass: 9.49 fps 33.57 mio pixel/s 4.11 mio triangles/s
2-pass: 8.53 fps 35.69 mio pixel/s 5.54 mio triangles/s


front to back
----------------------------------------------------------------------

1-pass: 9.70 fps 12.49 mio pixel/s 4.20 mio triangles/s
2-pass: 8.58 fps 16.57 mio pixel/s 5.58 mio triangles/s

[Razor]

Falls Ihr das gebrauchen könnt...
(unter Online-Bedingungen)

ASUS A7N8X del/gd (nForce2)
AthlonXP 1800+ @ 2100+ (133@150 FSB)
2x 256MB Corsair PC433 CL2 DDR-SDRAM (@2-2-2-4-1)
ELSA Gladiac 920 (gf3@default)
WindowsXP SP1 DX9 Deto 42.01

Overdraw - Z-Reject Tester v1.2 - ToMMTi-Systems (http://www.tommti-systems.com)

video mode / device info
(1024x768), X8R8G8B8 (D24X8)
HAL (pure hw vp): NVIDIA GeForce3

benchmark info
bump mapping: on
shadows: on
overdraw: 8



back to front
----------------------------------------------------------------------

1-pass: 11.38 fps 48872.50 mio pixel/s 4.93 mio triangles/s
2-pass: 10.29 fps 44176.90 mio pixel/s 6.68 mio triangles/s


50% back to front and 50% front to back
----------------------------------------------------------------------

1-pass: 11.88 fps 51029.13 mio pixel/s 5.15 mio triangles/s
2-pass: 10.59 fps 45484.25 mio pixel/s 6.88 mio triangles/s


front to back
----------------------------------------------------------------------

1-pass: 12.51 fps 53713.55 mio pixel/s 5.42 mio triangles/s
2-pass: 10.83 fps 46496.63 mio pixel/s 7.03 mio triangles/s
Bis denne

Razor

P.S.: Eigentlich find ich das ja 'nen bissel zu viel an Pixeln...
:D

[Achill]

sieht jetzt besser aus bzgl. dem Vergleichen.

also die werte mit der neuen Version:

System:
P4@2555Mhz (18x142Mhz)
512MB Ram (4x142Mhz)
Radeon 9700Pro Standarttakt -> 324Mhz/310.5Mhz, Omega Drivers v2.3.55 Treiber mit eigenen einstellungen (anhang)



Overdraw - Z-Reject Tester v1.2 - ToMMTi-Systems (http://www.tommti-systems.com)

video mode / device info
(1024x768), X8R8G8B8 (D24X8), 0xAA
HAL (pure hw vp): RADEON 9700/9500 Series (Omega 2.3.55)

benchmark info
bump mapping: on
shadows: on
overdraw: 8

back to front
----------------------------------------------------------------------
1-pass: 49.80 fps 288.36 mio pixel/s 21.57 mio triangles/s
2-pass: 47.07 fps 302.80 mio pixel/s 30.58 mio triangles/s

50% back to front and 50% front to back
----------------------------------------------------------------------
1-pass: 53.71 fps 190.06 mio pixel/s 23.26 mio triangles/s
2-pass: 49.47 fps 206.91 mio pixel/s 32.14 mio triangles/s

front to back
----------------------------------------------------------------------
1-pass: 64.00 fps 82.40 mio pixel/s 27.72 mio triangles/s
2-pass: 52.17 fps 100.77 mio pixel/s 33.90 mio triangles/s




Overdraw - Z-Reject Tester v1.2 - ToMMTi-Systems (http://www.tommti-systems.com)

video mode / device info
(1024x768), X8R8G8B8 (D24X8)
HAL (pure hw vp): RADEON 9700/9500 Series (Omega 2.3.55)

benchmark info
bump mapping: on
shadows: on
overdraw: 8

back to front
----------------------------------------------------------------------
1-pass: 38.06 fps 252.38 mio pixel/s 16.48 mio triangles/s
2-pass: 33.04 fps 243.52 mio pixel/s 21.47 mio triangles/s

50% back to front and 50% front to back
----------------------------------------------------------------------
1-pass: 41.39 fps 167.76 mio pixel/s 17.93 mio triangles/s
2-pass: 35.81 fps 171.61 mio pixel/s 23.27 mio triangles/s

front to back
----------------------------------------------------------------------
1-pass: 49.35 fps 72.90 mio pixel/s 21.38 mio triangles/s
2-pass: 39.09 fps 86.62 mio pixel/s 25.40 mio triangles/s




Overdraw - Z-Reject Tester v1.2 - ToMMTi-Systems (http://www.tommti-systems.com)

video mode / device info
(1024x768), X8R8G8B8 (D24X8)
HAL (pure hw vp): RADEON 9700/9500 Series (Omega 2.3.55)

benchmark info
bump mapping: on
shadows: on
overdraw: 8

back to front
----------------------------------------------------------------------
1-pass: 29.29 fps 209.32 mio pixel/s 12.69 mio triangles/s
2-pass: 22.56 fps 179.18 mio pixel/s 14.66 mio triangles/s

50% back to front and 50% front to back
----------------------------------------------------------------------
1-pass: 30.55 fps 133.50 mio pixel/s 13.23 mio triangles/s
2-pass: 24.52 fps 126.66 mio pixel/s 15.93 mio triangles/s

front to back
----------------------------------------------------------------------
1-pass: 35.33 fps 56.20 mio pixel/s 15.30 mio triangles/s
2-pass: 27.17 fps 64.83 mio pixel/s 17.65 mio triangles/s


Kopie meines profils aus dem -Radeonator 2.0-, für bessere vergleichbarkeit.

[Profile]
Game=Select a profile
Author=Select a profile
Comment=Select a profile

[DirectX]
ExportCompressedTex=1
ExportWBuffer=0
PixelCenter=0
VSync=0
FastZClearEnabled=1
DisableHyperZ=0
DisableHierarchicalZ=0
DitherAlpha=-1
ZFormats=15
AnisoDegree=0
ZCompressionMode=3
[DirectX Advanced]
TableFogEnable=0
WFogEnable=0
ZFogEnable=0
VolFogEnable=-1
DiscreteFogEnable=-1
VertexFogEnable=-1
AnisoLinear=-1
ExportBumpMappedTex=-1
ExportSignedVolTex=-1
ColorFill=-1
OptimizeTexStages=-1
ExportMipMapCubeMaps=-1
ZMaskEnable=1
ClipOptimizations=-1
PrimaryTiling=1
BackBufTiling=1
TextureTiling=1
TextureMicroTiling=1
PlainTiling=-1
AGPTextureTiling=-1
AGPTextureMicroTiling=-1
SysMemBlts=-1
RemoveDegenTris=-1
ValidateVertexIndex=-1
FastColorClear=-1
EnablePerformance=-1
FastColorClearPrimary=-1
BlendOpEnable=-1
RasterGuardbandEnable=1
ExportYUVTex=-1
NONPOW2TextureCaps=-1
PointSprites=-1
PureDevice=-1
LVB=1
OptimizePVSCode=-1
EnableRTPatch=-1
AGPTexture=-1
EnablePlaneMaskWorkaround=-1
TCL=1
SwTCL=-1
TclEnableBackFaceCulling=1
TclEnableVertexBlend2Optimize=1
TclEnableVertexBlendUseProjMat=1
NPatchMode=-1
TextureOpt=2
TextureLod=3
AntiAlias=2
AntiAliasSamples=2
[OpenGL]
OGLConvertTextures32To16=0
OGLEnableHWPageFlip=1
OGLEnableKTXBufferRegion=0
OGLWaitVerticalSync=0
OGLEnableTextureCompression=1
OGLTracing=-1
OGLDisableDitherWhenAlphaBlending=-1
OGLLODBias=3
OGLSubPixelPrecision=4
OGLTextureOpt=2
OGLMaxAnisotropy=0
OGLFullSceneAAScale=0
OGLEnableFastFullSceneAA=0
OGLForceZBufferDepth=0
OGLAlphaDitherMethod=0
[OpenGL Private]
enableAALines=-1
enableDynamicDither=-1
enableFastZMaskClear=1
enableHierarchicalZ=1
enableMacroTile=1
enableMicroTile=1
enableMultiTexture=1
use32BitTextures=-1
zFormat9x_32=-1
zFormat9x_16=-1
enablePVSGEN=-1
enableZCompression=1
enableVidMemTextures=-1
tclDlistInAGP=-1
tclDlistInLocal=-1
useFastAALines=-1
waitForIdleAfterSubmit=-1
enableAnisotropicFiltering=-1
ZCompForAllConfigs=1
enableTearFreeSwap=-1
enableDumpShaders=-1
useBlt=-1
enablePointParameters=-1
enablePIOTex=-1
enableAGPTextures=-1
userFastTrilinear=-1
useFastTextureCompression=-1
enableSSE=-1
enableSSE2=-1
enable3DNow=-1
disableScreenSavers=-1
disableHyperZ=0
[DVD]
DisableIDCT=0
DisableHDTVModes=-1
DisableVPE=-1
DisableHotPlugDFP=-1
DisableDrvAlphaBlend=0
DisableDrvStretchBlt=0
DisableBlockWrite=0
DisableUSWC=-1
DisableMMX=-1
TVEnableOverScan=-1
Adaptive De-interlacing=1
VPE Adaptive De-interlacing=1
Adaptive De-interlacing Adj=-1
OvlTheaterMode=-1

[tb]

Originally posted by Razor
P.S.: Eigentlich find ich das ja 'nen bissel zu viel an Pixeln...
:D

Keine Ahnung woran es liegt. Zeigt der On-Screen Counter auch so merkwürdige Werte?

Thomas

[tb]

Originally posted by Quasar
Woran hakte's denn bei der R8500?

edit:
Es hakt immer noch, auch mit der neuen Version ist die Performance so gut wie gleich geblieben!
Ausserdem: Wär's möglich, die Tasten für den Overdraw vom Nummernblock woanders hin zu legen? Ich hab' am R8500-Rechner nur eine Mini-Tastatur ohne Ziffernblock... :(


Als haken meinte ich, dass der Counter nicht angezeigt wurde. Die Performance scheint vom Treiber oder/und Hardware abzuhängen. Hab die Tasten auf die Pfeiltasten umgestellt.

Thomas

[aths]

Originally posted by Demirug
Wird für solche Pixel die TMU zwar Takttechnisch durchlaufen aber ihr der Speicherzugriff verwehrt verursachen die Texturfetchs für Early-Z Pixel keine Bandbreiten verbrauch. Aufwendig ist das nicht da man nur ein paar Signale umbiegen muss. Die gesparte Bandbreite kann anderweitig genutzt werden. Natürlich nur wenn gerade ein anderer Teil des Chips bandbreite braucht. Aber gerade beim 4x AA braucht man ja durchaus schon eine menge Bandbreite um nur die Z-Werte für den Z-Compare einzuladen. Ich habe auch schon eine Idee wie man den Test dafür ändern könnte um das nachzuprüfen. Hallo Demi,

ich bin noch immer heiß auf deinen Test :)

[Demirug]

Originally posted by aths
Hallo Demi,

ich bin noch immer heiß auf deinen Test :)

Ja, das hat nicht so ganz hingehauen. Mit einem PS 1.4 ging es ohne Probleme mit den 1.3 der GF4 ist das ein bischen aufwendiger und vorallem schwer abzuschätzen wie viele Takte dieser Shader dann braucht. Ich denke also noch ein bischen darüber nach ob es keinen besseren weg gibt.

[ow]

hmm.....ich glaub ich brauch nen Cat3.0 (Win98) für meine R8500.:D

Auf dem 2.4 freezt das System beim umschalten auf 2-pass.

/edit:
Ja, mit dem 3.0er Cat läuft´s unter Win98.

Aber die Radeon schlägt sich echt sehr bescheiden:(

Overdraw - Z-Reject Tester v1.2 - ToMMTi-Systems (http://www.tommti-systems.com)

video mode / device info
(1024x768), X8R8G8B8 (D24X8)
HAL (pure hw vp): RADEON 8500 Series

benchmark info
bump mapping: on
shadows: on
overdraw: 8



back to front
----------------------------------------------------------------------

1-pass: 4.86 fps 28.14 mio pixel/s 2.11 mio triangles/s
2-pass: 4.63 fps 29.77 mio pixel/s 3.01 mio triangles/s


50% back to front and 50% front to back
----------------------------------------------------------------------

1-pass: 4.84 fps 17.13 mio pixel/s 2.10 mio triangles/s
2-pass: 4.63 fps 19.35 mio pixel/s 3.01 mio triangles/s


front to back
----------------------------------------------------------------------

1-pass: 5.08 fps 6.55 mio pixel/s 2.20 mio triangles/s
2-pass: 4.83 fps 9.33 mio pixel/s 3.14 mio triangles/s

[tb]

Bringt's was, den Overdraw auf 2-3 zu reduzieren?
Vielleicht limitieren die Shader auf der R8500, oder schalt mal den Schatten aus, der ist ja transparent, wird also immer gezeichnet.

Thomas

[StefanV]

Originally posted by tb
Bringt's was, den Overdraw auf 2-3 zu reduzieren?
Vielleicht limitieren die Shader auf der R8500, oder schalt mal den Schatten aus, der ist ja transparent, wird also immer gezeichnet.

Thomas

Was ist eigentlich mit dem DL Link zu deinem Overdraw Tester los ??

Scheint irgendwie nicht sonderlich lebendig zu sein ;)

[tb]

Danke für den Tipp, hab wohl vergessen ihn upzuloaden. Erst groß ankündigen und dann nur nen toten Link posten.... :)

Wird gleich behoben.

Thomas

[ow]

Originally posted by tb
Bringt's was, den Overdraw auf 2-3 zu reduzieren?
Vielleicht limitieren die Shader auf der R8500, oder schalt mal den Schatten aus, der ist ja transparent, wird also immer gezeichnet.

Thomas


Reduktion des Overdraw bringt nur recht wenig, die Schatten ausschalten recht viel.

Overdraw 3:

Overdraw - Z-Reject Tester v1.2 - ToMMTi-Systems (http://www.tommti-systems.com)

video mode / device info
(1024x768), X8R8G8B8 (D24X8)
HAL (pure hw vp): RADEON 8500 Series

benchmark info
bump mapping: on
shadows: on
overdraw: 3



back to front
----------------------------------------------------------------------

1-pass: 12.50 fps 32.17 mio pixel/s 2.03 mio triangles/s
2-pass: 11.07 fps 35.63 mio pixel/s 2.70 mio triangles/s


50% back to front and 50% front to back
----------------------------------------------------------------------

1-pass: 12.29 fps 23.72 mio pixel/s 2.00 mio triangles/s
2-pass: 11.07 fps 28.50 mio pixel/s 2.70 mio triangles/s


front to back
----------------------------------------------------------------------

1-pass: 12.32 fps 15.86 mio pixel/s 2.00 mio triangles/s
2-pass: 11.09 fps 21.42 mio pixel/s 2.70 mio triangles/s



Overdraw 8, ohne Schatten:

Overdraw - Z-Reject Tester v1.2 - ToMMTi-Systems (http://www.tommti-systems.com)

video mode / device info
(1024x768), X8R8G8B8 (D24X8)
HAL (pure hw vp): RADEON 8500 Series

benchmark info
bump mapping: on
shadows: off
overdraw: 8



back to front
----------------------------------------------------------------------

1-pass: 14.57 fps 75.00 mio pixel/s 6.31 mio triangles/s
2-pass: 12.64 fps 73.18 mio pixel/s 8.21 mio triangles/s


50% back to front and 50% front to back
----------------------------------------------------------------------

1-pass: 14.35 fps 41.55 mio pixel/s 6.22 mio triangles/s
2-pass: 12.67 fps 44.83 mio pixel/s 8.23 mio triangles/s


front to back
----------------------------------------------------------------------

1-pass: 16.79 fps 10.81 mio pixel/s 7.27 mio triangles/s
2-pass: 14.82 fps 19.08 mio pixel/s 9.63 mio triangles/s

[Razor]

Originally posted by tb

Keine Ahnung woran es liegt. Zeigt der On-Screen Counter auch so merkwürdige Werte?

Thomas
Jep...
Aber was sind schon so ein paar milliarden Pixelchen ?
:D

Bis denne

Razor

[tb]

Hmm, dann liefert wohl NVIDIA's D3DQUERYTYPE_OCCLUSION Anfrage bei der GeForce 3 übertiebene Werte zurück. Wird bestimmt mit neuen Treibern behoben, denn auf der GF4, R85-97 stimmen die Werte ja.

Thomas

[Unregistered]

Ha...

"Bestätigung" von anderer Seite :

http://www.digit-life.com/articles2/radeon/r9500-9700-dx9-p2.html

Die early-Z Units der GF4 TI's arbeiten wirklich nicht !

[aths]

Originally posted by Unregistered
Ha...

"Bestätigung" von anderer Seite :

http://www.digit-life.com/articles2/radeon/r9500-9700-dx9-p2.html

Die early-Z Units der GF4 TI's arbeiten wirklich nicht ! nVidia sagt auch nicht, dass Early Z bei GeForce4 Füllrate sparen soll. Die reden nur von Bandbreiten-Ersparnis, was allerdings erst mit FSAA Sinn macht. Demirug wollte da mal so'n Testprogramm schreiben.

[ow]

Originally posted by aths
nVidia sagt auch nicht, dass Early Z bei GeForce4 Füllrate sparen soll. Die reden nur von Bandbreiten-Ersparnis, was allerdings erst mit FSAA Sinn macht. Demirug wollte da mal so'n Testprogramm schreiben.


Könnte hinkommen. Je mehr AA, desto grösser der Unterschied B2F - F2B auf meiner GF4.





Overdraw - Z-Reject Tester v1.3 - ToMMTi-Systems (http://www.tommti-systems.com)

video mode / device info
(1024x768), X8R8G8B8 (D24X8)
HAL (pure hw vp): NVIDIA GeForce4 Ti 4200

benchmark info
bump mapping: on
shadows: off
overdraw: 8



back to front
----------------------------------------------------------------------

1-pass: 39.58 fps 203.69 mio pixel/s 17.14 mio triangles/s
2-pass: 30.08 fps 174.17 mio pixel/s 19.54 mio triangles/s


50% back to front and 50% front to back
----------------------------------------------------------------------

1-pass: 39.51 fps 114.37 mio pixel/s 17.11 mio triangles/s
2-pass: 30.45 fps 107.75 mio pixel/s 19.78 mio triangles/s


front to back
----------------------------------------------------------------------

1-pass: 41.53 fps 26.74 mio pixel/s 17.99 mio triangles/s
2-pass: 30.57 fps 39.36 mio pixel/s 19.86 mio triangles/s



Overdraw - Z-Reject Tester v1.3 - ToMMTi-Systems (http://www.tommti-systems.com)

video mode / device info
(1024x768), X8R8G8B8 (D24X8) (2x Multisample)
HAL (pure hw vp): NVIDIA GeForce4 Ti 4200

benchmark info
bump mapping: on
shadows: off
overdraw: 8



back to front
----------------------------------------------------------------------

1-pass: 29.69 fps 305.61 mio pixel/s 12.86 mio triangles/s
2-pass: 22.11 fps 256.00 mio pixel/s 14.36 mio triangles/s


50% back to front and 50% front to back
----------------------------------------------------------------------

1-pass: 31.16 fps 180.45 mio pixel/s 13.50 mio triangles/s
2-pass: 24.22 fps 171.39 mio pixel/s 15.73 mio triangles/s


front to back
----------------------------------------------------------------------

1-pass: 34.93 fps 44.98 mio pixel/s 15.13 mio triangles/s
2-pass: 26.48 fps 68.21 mio pixel/s 17.21 mio triangles/s



Overdraw - Z-Reject Tester v1.3 - ToMMTi-Systems (http://www.tommti-systems.com)

video mode / device info
(1024x768), X8R8G8B8 (D24X8) (4x Multisample)
HAL (pure hw vp): NVIDIA GeForce4 Ti 4200

benchmark info
bump mapping: on
shadows: off
overdraw: 8



back to front
----------------------------------------------------------------------

1-pass: 19.89 fps 409.40 mio pixel/s 8.61 mio triangles/s
2-pass: 15.65 fps 362.44 mio pixel/s 10.17 mio triangles/s


50% back to front and 50% front to back
----------------------------------------------------------------------

1-pass: 22.67 fps 262.52 mio pixel/s 9.82 mio triangles/s
2-pass: 17.94 fps 253.89 mio pixel/s 11.65 mio triangles/s


front to back
----------------------------------------------------------------------

1-pass: 27.79 fps 71.57 mio pixel/s 12.04 mio triangles/s
2-pass: 20.95 fps 107.90 mio pixel/s 13.61 mio triangles/s



Overdraw - Z-Reject Tester v1.3 - ToMMTi-Systems (http://www.tommti-systems.com)

video mode / device info
(1024x768), X8R8G8B8 (D24X8) (8xSAA)
HAL (pure hw vp): NVIDIA GeForce4 Ti 4200

benchmark info
bump mapping: on
shadows: off
overdraw: 8



back to front
----------------------------------------------------------------------

1-pass: 9.37 fps 385.75 mio pixel/s 4.06 mio triangles/s
2-pass: 7.13 fps 330.21 mio pixel/s 4.63 mio triangles/s


50% back to front and 50% front to back
----------------------------------------------------------------------

1-pass: 10.12 fps 234.43 mio pixel/s 4.38 mio triangles/s
2-pass: 7.96 fps 225.44 mio pixel/s 5.17 mio triangles/s


front to back
----------------------------------------------------------------------

1-pass: 12.66 fps 65.19 mio pixel/s 5.48 mio triangles/s
2-pass: 9.71 fps 100.05 mio pixel/s 6.31 mio triangles/s

[Unregistered]

Hallo,

ich hätte da mal noch 'ne kurze zwischenfrage betreffs der KYRO1-Werte:

Originally posted by Demirug

Das sollte nun bei einem TBDR wirklich nicht passieren. Und deshalb bin ich da auch überfragt. Ist wohl ein Fall für Kristof.


Hat Kristof oder sonst jemand darüber Auskunft gegeben?

Dankeschön!

Gaestle
---
Rock and Roll aint noise pollution...

[aths]

Warum ist der NV25 beim 3DM03 eigentlich so deutlich fixer als der NV20? Wegen der Early-Z-Sache hätte ich gedacht, dass der NV20 hier gut punkten könnte.

[Salvee]

Auf Beyond3D haben die Jungs gemeint, dass beim 3DMark03 auf R8500/R9000->PS1.4 Karten der Pixelshader limitiert, bei GF3/4 der/die VS.
Könnte eine Erklärung für die Differnezen zwischen GF3 und GF4 sein.