Early Z beim NV20, NV25

[aths]

Sehe ich das richtig?

- Beide Chips machen Early Z im Triangle Setup. GeForce3 nutzt die Z-Test-Units, die ansonsten fürs FSAA verwendet werden, um überhaupt nur sichtbare Pixel in die Pipeline reinzulassen.

Was ich jetzt nicht verstehe ist, was sie geändert haben, so dass Early Z beim NV25 nun auch mit FSAA funktionobelt. Denn wenn ohnehin nur Fragments in die Pipeline kommen, die am Ende in den Framebuffer geschrieben werden, braucht man beim FSAA die Z-Test-Units auch nicht mehr, so dass ich keinen Grund sehe wieso GF3 beim MSAA aufs Early Z Culling verzichten muss?!

[micki]

könntest nen link dazu bieten woher du die infos hast?

gracias

MfG
micki

[StefanV]

Originally posted by micki
könntest nen link dazu bieten woher du die infos hast?

gracias

MfG
micki
Schau mal im Techforum nach, der Ellenlange Thread müsste es sein *eg*

[Demirug]

Zur ersten Frage:

Ja. Jede Art von Early Z die mehr Pixel pro Takt verwerfen kann als Pipelines vorhanden sind muss im TriSetup durchgeführt werden.

Zu deiner zweiten Frage:

Das ist etwas kompliziert und ich kann da auch nur raten.

Eine GF3 hat 4*4 Z-Compare einheiten. Jede dieser Einheiten kann ein AA-Sample pro Takt prüfen. Je mehr AA-Samples pro Pixel gebraucht werden desto schlechter wird die Early-Z Leistung bezogen auf Pixel/Takt.

Die GF4 macht nun defintive etwas anderes. Die Tatsache das AA die EarlyZ Leistung nicht mehr direkt beeinflust deutet darauf hin das es dort zusätzliche Z-Compare einheiten im Trisetup gibt. Denn man braucht pro AA-Sampel weiterhin einen Z-Compare einheit. Der Grund dafür ist das man für einen Pixel ja nicht nur wissen muss ob er in den Framebuffer geschrieben werden muss sonder beim MSAA auch noch die Information in welche der Multisamplebuffer der Pixel muss.

Die Grundsätzliche Idee die ich habe ist folgende: Der Z-Buffer ist ja komprimiert gespeichert. Beim einladen und entpacken wird gleichzeitig ein Referenzwert für die Tile ermittelt. Beim Trisetup wird nun für eine Deckungsgleiche Tile ebenefalls ein Refrenz-Z Wert berechnet und mit dem berechneten Referenzwert aus dem Buffer verglichen. Kommt dabei heraus das alle Pixel der Tile verdeckt sind wird die ganze Tile verworfen. Ich muss das ganze aber noch ein bischen durchrechnen. Du könntest hier nochmal deine Ergebnisse von meinem Overdrawtest posten (wenn du sie gerade zur Hand hast) dann muss ich sie nicht suchen. ;)

[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 3884 7769 3706 14825 | 1122 2243 591 2266
|
2x AA 3002 6003 3030 12120 | 569 1120 556 2228
|
4x AA 2854 5708 2572 11497 | 318 636 317 1268

[Demirug]

Bei 4xAA und 4 Texturen kann was nicht stimmen. Entweder ist die Pixel oder die Texel fillrate falsch.

Überschlagen kann das Trisetup wohl 16 Pixel/Takt verwerfen. Jetzt müsste man nur noch wissen ob es wirklich ein Tileverfahren ist.

[ow]

Originally posted by Demirug
Bei 4xAA und 4 Texturen kann was nicht stimmen. Entweder ist die Pixel oder die Texel fillrate falsch.



Tippfehler? Sind bestimmt 2572Mpix/s.

[aths]

Ich wiederhole den Bench mal. ow, du müsstest doch auch so eine Messreihe mit GF4 Ti haben?

[ow]

Originally posted by aths
Ich wiederhole den Bench mal. ow, du müsstest doch auch so eine Messreihe mit GF4 Ti haben?

Ja, hab ich. Komme auf ~2300 MPix/s bei 4Tex/F2B in 4xAA.


btw. haben wir aktuelle Benches mit einem 40er Deto und aktivem Z-Culling auf GF3?

Z-Culling ist per Default NICHT (oder nur in wenigen Apps) aktiv auf den GF4 mit den 40er Detos.

[aths]

Habe den Wert für 4x AA, 4 Texturen F2B, korrigiert.

Die Füllraten sind übrigens erstaunlicherweise durchaus etwas auflösungsabhängig. Je größer das Fenster, umso mehr Füllrate. Wahrscheinlich, weil dann ein gewisser Verwaltungs-Overhead pro Pixel sinkt.