GeForce4 Ti im Verhältnis nicht viel schneller als GeForce3 Ti!

[Unregistered]

Moin Leute,

Eine GeForce4 Ti ist eigentlich gar nicht brauchbar im Verhältnis zur
GeForce3 Ti. Der einzige Unterschied: Es hat einen doppelten Vertex
Shader und ist höher getaktet. Aber die bandbreiteschonenden Maß-
nahmen bringen (fast) keine bessere Leistung! Ein Beispiel:

CHIP hat vor 4-5 Monaten Eine GeForce4 Ti 4600 gegen eine GF3 Ti 500
in Quake3 angetestet.
Bei einer Auflösung von 1600x1200 und Einsatz von 4xAA war die GF4
nur 50% schneller. Das ist natürlich nicht wenig, aber da die Karte
30% getaktet war, konnte sie dieses Ergebnis erreichen. Das zeigt,
das die LMA II der GF4 nur 10-20% mehr Leistung bringt, oder besser
gesagt: bei gleichem Takt wäre die GF4 nur 20% schneller - und ich
glaube nicht das viele Gamer bei 1600x1200x32Bit mit 4xAA spielen...
Insofern kann man bei der GeForce4 nicht wirklich von neuer Technolo-
gie oder Verbesserung sprechen - denn wenn man eine GF3 auf 300MHz
übertaktet, erreicht man das gleiche...

[zaboron]

die gf4 ti stellt auch nicht viel mehr als ein refresh der gf3 serie dar.

[Meta]

Der Sprung von Geforce 2 auf Geforce 3 war noch viel kleiner...

Das ist Nvidia. Aber sie schaffens trotzdem immer wieder der schnellste zu sein.

[KaoS]

Das is ja auch nicks neues ;) GeForce 3.5 halt ;)

Mfg

[GloomY]

Originally posted by Unregistered
Das zeigt, das die LMA II der GF4 nur 10-20% mehr Leistung bringt, oder besser gesagt: bei gleichem Takt wäre die GF4 nur 20% schnellerErwartest du Wunder von LMA-II? LMA-I war ja schon eine recht gelungene Optimierung weg von reinem Brute Force (GF2 Ultra). Viel mehr geht da nicht mehr und auch in Zukunft wird imho der Umstieg von II auf III beim NV30 noch weniger Speedup bringen als von I nach II. Da ist einfach das Potential ausgeschöpft.

[Radeonator]

Mir hat meine GF3Ti200(seufz ;) ) auch bedeutend mehr Spass als die GF4Ti4200er gemacht. Nettes relativ schnelles AF(was man ja bei der GF4 leider versaubeutelt hat) ,Fettes OC Potential und einfach gut.

Hier ein Bild, weil des Teil so geil ausgesehen hat...

http://www.msi-technology.de/images/produkte/8850.jpg

[Unregistered]

unabhängig von der geschwindigkeit finde ich die geforce4 trotzdem einen fortschritt... multimonitoring:-)

[Sesino]

Gerade unter AntiAliasing sollte die GF4 deutlich schneller als die GF3 Karten sein, ich hatte davor eine GF2MX also war ich sehr glücklich mit meinem Umstieg auf eine Ti4400, wie siehts denn unter anderen Auflösungen/Applikationen aus? zB Ut2003 in 1024x769 + 2xFSAA, ob da eine GF3 ebenso gut mithalten kann?

[robbitop]

gerade FSAA ist deutlich schneller als bei der GF3 auch bei gleichen Taktraten..und was heisst hier "nur 10-20%" das is ne ganze menge...

und es is ja auch nur ein GF3 Refresh...der NV30 wird wie der R300 mal wieder ein Quantensprung sein.

Ich errinnere an FSAA 2x OGMS ist die GF4 Ti4200 so schnell wie die GF3 ohne FSAA ....aber das mit dem AF ist natürlich ziemlich schlecht...
aber ich finde es besser als wenn man wie andere Hersteller einfach die Qualli runterstellen und dann ihr AF loben...toll weniger arbeit verrichtet..da is klar dass es schneller ist....naja das neue AF bei der R9700 soll ja ganz brauchbar sein..solange es in den nötigen Applikationen gut genug aussieht ist es okay...aber MipBanding ist echt das letzte...

[aths]

Originally posted by robbitop
gerade FSAA ist deutlich schneller als bei der GF3 auch bei gleichen Taktraten..und was heisst hier "nur 10-20%" das is ne ganze menge...

und es is ja auch nur ein GF3 Refresh...der NV30 wird wie der R300 mal wieder ein Quantensprung sein.

Ich errinnere an FSAA 2x OGMS ist die GF4 Ti4200 so schnell wie die GF3 ohne FSAA ....aber das mit dem AF ist natürlich ziemlich schlecht...
aber ich finde es besser als wenn man wie andere Hersteller einfach die Qualli runterstellen und dann ihr AF loben...toll weniger arbeit verrichtet..da is klar dass es schneller ist....naja das neue AF bei der R9700 soll ja ganz brauchbar sein..solange es in den nötigen Applikationen gut genug aussieht ist es okay...aber MipBanding ist echt das letzte... Das mit dem "mit 2x AA so schnell wie GeForce3 Ti500 ohne AA" stimmt auch nur, weil die Taktfrequenzen mit angehoben wurden. Vom AF abgesehen ist GeForce4 pro Takt aber durchaus effizienter. Gerade bei modernen Spielen kann sie sich mühelos vor GeForce3 plazieren, was sowohl an der Taktsteigerung als auch an der verbesserten Architektur liegt. Von einer neuen Grafikchip-"Generation" würde ich natürlich trotzdem nicht sprechen.

[robbitop]

das habe ich ja auch nicht gesagt (neue Generation)..is halt "nur" ein Refresh kein neues Design...an sich ist bis zur NV25 (GF4Ti) alles NV10 (GF256) Design mit Änderungen (NSR->Vertexshader Pixelshader/LMA mit HSR/2.TMU/Multisamplingfähigkeit).

Aber der NV30 wird AFAIK ein komplett neues Design haben, so wie es bisher immer bei ATi lief ..und neue Designs bringen meist mehr Performance aufgrund grösserem Speicherbus oder neuer Architektur oder mehr Rendering Pipes..und damit is t er ne neue Generation und Performancemässig sowieso)

[MadManniMan]

hm, also ich persönlich sehe eigentlich nicht, daß zwischen nv1x und 2x keine grundlegenden unterschiede sein sollten...

aber eines fällt mir da gerade ein: wie war das mit dem q3-himmel bei der gf1/2?

[ow]

Originally posted by robbitop


Aber der NV30 wird AFAIK ein komplett neues Design haben, so wie es bisher immer bei ATi lief ..und neue Designs bringen meist mehr Performance aufgrund grösserem Speicherbus oder neuer Architektur oder mehr Rendering Pipes..


Neudesigns hat es bei Nv oder ATi schon ewig lange nicht mehr gegeben.
Alle aktuellen Chips sind Weiterentwicklungen ihrer Vorgaenger.

[-error-]

Tja. Verdammt harte Zeiten brechen für Nvidia an. Ich bin gespannt was die Gforce5 im Stande zu leiten ist!

Wird Nvidia die Ati nicht übertrumpfen könnem haben die ein Problem.
Selbst wenn Nvidia schneller sein sollte, braucht Ati nur die Preise der Karten zu senken und schon siehts wieder anders aus.

[Kai]

Originally posted by Powerd by ATI
Tja. Verdammt harte Zeiten brechen für Nvidia an. Ich bin gespannt was die Gforce5 im Stande zu leiten ist!

Wird Nvidia die Ati nicht übertrumpfen könnem haben die ein Problem.
Selbst wenn Nvidia schneller sein sollte, braucht Ati nur die Preise der Karten zu senken und schon siehts wieder anders aus.

Das ist alles Spekulation. Warten wir's doch mal ab. Klar ist es nicht wahrscheinlich das der NV30 für 300 € ab Markteinführung erhältlich sein wird, aber wissen wir denn ob es nicht doch sein könnte das ähnlich wie bei der TI4 - Serie verschiedene Modelle angeboten werden? Sehen wir dann ja.

[AtTheDriveIn]

Originally posted by Meta
Der Sprung von Geforce 2 auf Geforce 3 war noch viel kleiner...



*hust*

[Eusti]

Originally posted by Powerd by ATI
Wird Nvidia die Ati nicht übertrumpfen könnem haben die ein Problem. Selbst wenn Nvidia schneller sein sollte, braucht Ati nur die Preise der Karten zu senken und schon siehts wieder anders aus...Womit ATI dann natürlich kein Problem hätte :).

[Exxtreme]

Originally posted by AtTheDriveIn



*hust*
Naja, als die GF3 auf'm Markt kam, war sie nicht viel schneller als eine GF2U. Erst bei 1600x1200x32 konnte sie sich halbwegs absetzen. Im Laufe der Zeit sind aber die Treiber der GF3 besser geworden und der Umfang der Details in den Spielen stieg an. Und da konnte die GF3 dank LMA immer mehr punkten. Im Endeffekt war die GF3 damals doch eine lohnende Investition auch für die "early adopter" da sie doch lange gehalten hat.

Gruß
Alex

[aths]

Originally posted by Exxtreme
Naja, als die GF3 auf'm Markt kam, war sie nicht viel schneller als eine GF2U.Mit Anti-Aliasing schon. Für das meiste reicht die Rohleistung einer GF2U wohl noch heute aus. Aber man ist ja verwöhnt und will FSAA+AF. (Vielleicht sollte man gewisse Unternehmen wegen "Angewöhnung einer kostenintensiven Grafik, die in den Ruin führt" verklagen...)

[zeckensack]

Originally posted by ow
Neudesigns hat es bei Nv oder ATi schon ewig lange nicht mehr gegeben.
Alle aktuellen Chips sind Weiterentwicklungen ihrer Vorgaenger. Na! :)

NV15->NV20
Neuerungen
Fixed funtion T&L wird ersetzt durch Vertex Shader. Großer Umbau.
Hinzu kommt der Mechanismus für Dependant Texture Reads, der der Geforce 3 zur Pixel Shader-'Qualifikation' verhilft.
Triangle Setup modifiziert (für Multisampling).
Speichercontroller überarbeitet (CMBC, führt zum Marketingbegriff LMA1).

Recycling
Register Combiners wurden identisch übernommen, abgesehen davon, daß es jetzt mehr davon gibt.

NV20->NV25
Neuerungen
Early Z rejection (verringert massiv den Bandbreiten-/Füllratenbedarf bei verdeckten Dreiecken, führt zur Marketingbezeichnung LMA2)
Mehrfachauslegung der 'final combiners', um gleichzeitig mehrere Subpixel zu erzeugen (Multisampling)
Teilweise Verlagerung des AA-Downfilters in den RAMDAC
leicht aufgebohrte Möglichkeiten beim Dependant Read
Pixel Pipes können jetzt den Z-Wert modifizieren

Recycling
Trisetup unverändert
Register combiners unverändert
Vertex Shader weitgehend unverändert (verdoppelt)


R100->R200
Neuerungen
Combiner/Texturaddressierung komplett weggeworfen, Umstellung auf frei programmierbare Pixel Shader
Vertex Shader
TriSetup verändert (für die in ein paar frühen Treibern mögliche freie Anordnung der Subpixel-Erzeugung)

Nix neu
Texturfilter-Einheiten (sieht man 'schön' am Bi-AF)
Speichercontroller

R200->R300
Neuerungen
Pixel Shader 'DX9-fähig' gemacht (Fließkomma, längere Programme)
Vertex Shader das gleiche.
Texturfilter-Einheiten aufgebohrt ('Tri-AF' ala ATI)
Early Z reject
Multisampling, alles was man dafür so braucht.

Übernommen
Programmierbares TriSetup der R200 lässt sich IMO auch für Multisampling unverändert nutzen
???

[Exxtreme]

@ zeckensack
Öhhmmm, AFAIK hat der NV20 auch schon eine Z-Rejection-Einheit. Ohne die würde MSAA gar nicht funktionieren.

Gruß
Alex

[ow]

MSAA funzt auch so, ohne sonst irgendwas.

[zeckensack]

Jo, da bin ich mir ziemlich sicher.

Early-Z ist nur eine Verlagerung des Z-Tests vor die Pixelpipeline, um die dafür gebrauchten Ressourcen (Texturbandbreite und Taktzyklen) einsparen zu können.

Spätestens wenn ein Pixel-Shader den Z-Wert ändert (geht auf Gf4 und Radeon 8500), muß Early-Z sowieso abgeschaltet werden, da der Test dann auf das Ergebnis der Pixelpipe angewiesen ist.
Dann muß die Einheit entweder doppelt ausgeführt, oder kreativ beschaltet werden :)

[aths]

Originally posted by zeckensack
Na! :)
NV20->NV25
Neuerungen
Early Z rejection (verringert massiv den Bandbreiten-/Füllratenbedarf bei verdeckten Dreiecken, führt zur Marketingbezeichnung LMA2)
Mehrfachauslegung der 'final combiners', um gleichzeitig mehrere Subpixel zu erzeugen (Multisampling)Na!

Das hat NV20 auch schon alles. (Early Z rejection und MSAA spielen übrigens zusammen. Jede Pipeline hat 4 Z-Test-Units, die im AA-Fall den Z-Test der Subpixel übernehmen. So dass bei 4x MSAA praktisch kein Early Z rejection mehr vorhanden ist.)

LMA2 hat halt die "Quad Cache Architecture" und eine verbesserte Z-Kompression (erhöhte Wahrscheinlichkeit, einen 32-Bit-Z-Wert auf 8 Bit komprimieren zu können. Schlägt die Komprimierung fehl, da 8 Bit nicht ausreichen, wird unkomprimiert übertragen.) Angeblich wurde auch eine vorausschauende Speicherbaustein-Initialisierung für den lokalen RAM-Zugriff eingebaut.

[aths]

Originally posted by ow
MSAA funzt auch so, ohne sonst irgendwas. Damit es mit möglichst geringem Füllratenverlust und ohne Grafikfehler arbeiten kann, sind mehrere Z-Test-Units pro Pipeline erforderlich. Hierfür werden die Early Z Units verwendet.

[Demirug]

Originally posted by aths
Jede Pipeline hat 4 Z-Test-Units, die im AA-Fall den Z-Test der Subpixel übernehmen. So dass bei 4x MSAA praktisch kein Early Z rejection mehr vorhanden ist.)

Weist du das gesichert oder ist das eine Spekulation?

[aths]

Originally posted by Demirug
Weist du das gesichert oder ist das eine Spekulation? Da hast du mich kalt erwischt :) Das ist nicht gesichert, aber imo der vernünftigste Weg. Irgendwo müssen die Z-Units ja herkommen, und bei LMA hat nun jede Pipeline zufällig gerade 4 Stück davon. Außerdem hat mich nggalai mal auf sinkende Effizienz beim AA aufmerksam gemacht, und er äußerte dann auch diese Idee mit dem Zusammenhang zwischen LMA und MSAA.

[Demirug]

aths,

zum einem könnten diese Schaltungstechnisch ja so gebaut sein das man sie wahlweise am Anfang oder Ende der Pipeline benutzt und falls am Anfang der Pipe alle 4 Test fehlschlagen wird diese Pipe für das nächste Fragment freigegeben. Wäre immer noch ein Early Z.

Was aber IMO viel wahrscheinlicher ist:

Ein Grossteil des Early Z wird schon vom Trisetup erledigt. Laut NVIDIA ist dieser Chipteil in der Praxsis sowieso unterbelastet. Und wenn das Trisetup und die Pipelines über einen Warteschlange entkoppelt sind macht es noch mehr sinn den Test im Trisetup durchzuführen. Und spätestens bei einem hierarchie Z-Test muss man es im Trisetup machen.

Edit:
Das die Effizienz beim AA sinkt ist klar. Da selbst beim MSAA in Verbindung mit Early Z in Summe mehr Fragmente von den Pipelines bearbeitet werden müssen. Ist nur ein AA-Sample sichtbar muss die Pipeline durchlaufen werden. Und je mehr Sample pro Pixel gespeichert werden desto höher ist die Wahrscheinlichkeit das am Dreiecksrand Fragmente berechnet werden die ohne AA vom Early Z verworfen werden. Dazu kommt noch die steigende Zahl Pixel an den Dreieckskanten (aus dem gleichen Polygon) für die zweimal gerechnet wird weil sie von einem Dreieck nicht komplet abgedeckt werden.

[aths]

Originally posted by Demirug
Und spätestens bei einem hierarchie Z-Test muss man es im Trisetup machen.Ach ja, zu LMA2 gehört als Neuheit auch Fast Z Clear, was imo nur mit hierarchischem Z-Buffer zu machen ist.

Über den Rest denke ich erst mal nach.

[aths]

Originally posted by Demirug
Das die Effizienz beim AA sinkt ist klar. Da selbst beim MSAA in Verbindung mit Early Z in Summe mehr Fragmente von den Pipelines bearbeitet werden müssen. Ist nur ein AA-Sample sichtbar muss die Pipeline durchlaufen werden. Und je mehr Sample pro Pixel gespeichert werden desto höher ist die Wahrscheinlichkeit das am Dreiecksrand Fragmente berechnet werden die ohne AA vom Early Z verworfen werden. Dazu kommt noch die steigende Zahl Pixel an den Dreieckskanten (aus dem gleichen Polygon) für die zweimal gerechnet wird weil sie von einem Dreieck nicht komplet abgedeckt werden. Ich stelle mir das so vor, dass das Triangle Setup (Beispiel 4x MSAA) all diejenigen Fragmente erzeugt, die das Dreieck belegt. Das sind in der Regel 4. (Da mehr Polygoninnenfläche als Kantenpixel vorkommen.) Für jedes Fragment muss jetzt noch der Sichtbarkeits-Test erfolgen. Ist mindestens einer "erfolgreich", geht das Pixel in die Pipeline, ansonsten wird es verworfen. Jedenfalls braucht man 4 parallele Z-Test-Units, sofern ich das richtig überblicke.

Ohne AA können pro Takt und Pipeline bis zu 4 Pixel verworfen werden. (R200 kann afaik 16 Pixel pro Pipeline und Takt verwerfen. Ich denke, dass NV2X hier ähnlich arbeitet.) Das weist ja auf die Entkoppelung von Triangle Setup und Texturierung hin. Bei 4x MSAA sind nun imho alle 4 early Z-Test-Units im Beschlag und werden für den Sichtbarkeitstest beim FSAA verwendet. Das senkt dann auch die Effizienz vom vorgezogenem Z-Test. Davon, dass Early Z schon im Triangle Setup gemacht wird, habe ich bislang noch nichts gehört.

[aths]

Originally posted by zeckensack
Spätestens wenn ein Pixel-Shader den Z-Wert ändert (geht auf Gf4 und Radeon 8500), muß Early-Z sowieso abgeschaltet werden, da der Test dann auf das Ergebnis der Pixelpipe angewiesen ist.
Dann muß die Einheit entweder doppelt ausgeführt, oder kreativ beschaltet werden :) Falls du den PixelShader-Befehl für Z-korrektes Bumpmapping meinst, das geht (in OpenGL) auch schon mit GF3.

[Quasar]

Hm,
Wenn ich mir das FSAA (besonders RG vs OG bei 2x und 4x) und diese early-Z Units mal anschaue, dann würde ich am ehesten auf 2 Units per Pipe tippen.

Ist vielleicht ein wenig einfach gedacht, aber imo sprächen folgende Dinge dafür:

1) 2xFSAA (mit 2 unabhängigen, da RG, subsamples) kostet in niedrigen Auflösungen kaum Leistung.

2) 4xFSAA (mit 4 sich nur auf je einer Achse unterscheidenden subsamples) müssen diese 2 Z-Units jeweils 2x ran, deswegen auch der deutlich stärkere Leistungsverlust. Durch das ordered Grid kann man evtl. irgendwelche Werte (Cache-Hitrate oder sowas) aus dem ersten Pass für den zweiten Recyclen...denke ich, so dass die Leistung zumindest etwas geschont wird.

Ob die Effizienz der LMA2 sinkt, kann ich nicht beurteilen, die Werte und wie sie zustandegekommen sind, würden mich interessieren, denn afaik kann man mit Detos, die die GF4 unterstützen nur noch die lossless Z-Compression deaktiviern.

Wo liegt mein Denkfehler?

[aths]

Originally posted by Quasar
2) 4xFSAA (mit 4 sich nur auf je einer Achse unterscheidenden subsamples) müssen diese 2 Z-Units jeweils 2x ran, deswegen auch der deutlich stärkere Leistungsverlust. Der lässt sich auch anders erklären:

1. Spürbar höhere Bandbreiten-Anforderungen. Das Speicherinterface scheint nur bis für 2x FSAA ausreichend optimiert, danach treten offenbar große Engpässe auf.

2. Stark gesunkene Early-Z-Effizenz. Es kann nur noch jeweils das aktuelle Pixel abgewiesen werden, bevor es in die Pipe kommt. Der Takt um das festzustellen ist aber auf jeden Fall verbraucht.
Originally posted by Quasar
Durch das ordered Grid kann man evtl. irgendwelche Werte (Cache-Hitrate oder sowas) aus dem ersten Pass für den zweiten Recyclen...denke ich, so dass die Leistung zumindest etwas geschont wird.Afaik kommt bei 4x das OG-Muster durch die Limitierung des TS zustande, die interne Zeilenzahl nur verdoppeln zu können. Für 4x OG müsste jede Pixelzeile in 4 Zeilen zerlegt werden.

[Quasar]

Spekulation oder Fakt?

BTW, netter neuer Avatar :)

[StefanV]

ähm, mal ein Vorschlag:

Wie wäre es, wenn irgendeiner von den Moderatoren eine 'Legende' von Fachabkürzungen machen würde??

[Demirug]

aths,

Fast Z-Clear wird AFAIK über den Memorycontroller gemacht. Dort wird dann hinterlegt das die entsprechenden Bereiche eben leer sein müssen und deshalb nicht geladen werden und sobald die Kachel wieder rausgeht wird dieser Vermerk gelöscht.

Ansonsten sind das meinerseits natürlich alles nur vermutungen da sich die Chiphersteller natürlich nicht so tief in die Karten schauen lassen. Was man bräuchte wäre ein entsprechendes Testprogramm zum ausmessen der Early-Z Leistung bei verschiedenen AA-Varianten/PS-Situationen. Um dann auf den Aufbau der entsprechenden Einheit im Chip zu schliessen.

Ich bleibe aber denoch bei meiner Meinung das die ganzen Early-Z sachen im Trisetup gemacht werden sollten bzw einen eigene Einheit darstellen die von den Fragmentpipelines entkoppelt ist.

[zeckensack]

Originally posted by Quasar
Ob die Effizienz der LMA2 sinkt, kann ich nicht beurteilen, die Werte und wie sie zustandegekommen sind, würden mich interessieren, denn afaik kann man mit Detos, die die GF4 unterstützen nur noch die lossless Z-Compression deaktiviern.

Wo liegt mein Denkfehler? Wenn aths' These stimmt, dann können statt vier 'normalen' Pixeln bei aktivem 4xAA nur noch vier Subpixel ge-Z-getestet werden. Das steht im Mißverhältnis zur anderweitig 'kostenlosen' Subpixelerzeugung, es wird ja nur ein Farbwert pro vier Subpixel erzeugt.

Dh die Pixelpipe wird genaugenommen pro Subpixel effizienter, der Z-Test nicht, seine Leistungsfähigkeit bleibt konstant.

aths,
Du siehst heute aber gut aus :)

[aths]

Originally posted by Quasar
Spekulation oder Fakt?Weder noch. Zeilenauflösung des TS: Das ist meine Ansicht (Theorie) die ich allerdings für sicher genug halte, sie wie einen Fakt zu präsentieren.

Bei 4x MSAA à la NV braucht man ggü. 2x deutlich mehr Bandbreite (grob über den Daumen gepeilt 60-70% mehr als mit 2x MSAA) so dass ich die Schlussfolgerung, der fps-Einbruch bei 4x resultiert aus den Bandbreitenbedürfnissen für naheliegend halte.
Originally posted by Quasar
BTW, netter neuer Avatar :) Und nur für kurze Zeit :)

[aths]

Originally posted by zeckensack
Wenn aths' These stimmt, dann können statt vier 'normalen' Pixeln bei aktivem 4xAA nur noch vier Subpixel ge-Z-getestet werden. Das steht im Mißverhältnis zur anderweitig 'kostenlosen' Subpixelerzeugung, es wird ja nur ein Farbwert pro vier Subpixel erzeugt."Kostenlos" ist die Generierung der Subpixel, weil das TS entsprechend ausgelegt ist. Wenn die Pipeline dann noch 4 Z-Test-Einheiten hat, könnte man pro Takt bis zu 4 Subpixel gleicher Farbe erzeugen. Oder hab ich da mit meinem "gefährlichem Halbwissen" wieder einen Denkfehler?
Originally posted by zeckensack
aths,
Du siehst heute aber gut aus :) Ich könnte keine Frau sein... ich würde den ganzen Tag in der Ecke sitzen und mit meinen Brüsten spielen :| Naja, bei diesem Fräulein fällt mir nur http://www.plauder-smilies.de/knuddel.gif ein.

[aths]

Originally posted by Demirug
aths,

Fast Z-Clear wird AFAIK über den Memorycontroller gemacht. Dort wird dann hinterlegt das die entsprechenden Bereiche eben leer sein müssen und deshalb nicht geladen werden und sobald die Kachel wieder rausgeht wird dieser Vermerk gelöscht.Jopp, also gekachelter Z-Buffer inkl. Index-Matrix mit der Information über den jeweiligen Zustand der Kachel. Das meinte ich mit hierarchischem Z-Buffer.
Originally posted by Demirug
Ich bleibe aber denoch bei meiner Meinung das die ganzen Early-Z sachen im Trisetup gemacht werden sollten bzw einen eigene Einheit darstellen die von den Fragmentpipelines entkoppelt ist. Bei einem Test-Programm stünde noch die Frage wie man sicherstellt, dass durch 4x MS keine ergebnisverfälschenden Bandbreitenengpässe auftreten.

[Demirug]

So ich hab mir mal ein paar Zahlen besorgt.

NVIDIA gibt die Fillrate der 4200 mit 4M AA-Sample/s an. Wir wissen das eine 4200 eine theoretischen Pixelfillrate von 1M hat. Daraus ergibt sich das pro Pipeline 4 mal der gleiche Farbwert pro Takt geschrieben werden kann.
So jetzt kommt der Knackpunkt:
Gilt das nur bei deaktiviertem Z-Test oder auch mit Z-Test? Falls es nur beim deaktiviertem Test zutrift wäre das schon sehr dreist damit zu werben. Im anderen Fall müssen pro Pipeline auf jeden Fall 4 Z-Compares zur verfügung stehen. Und es ist von der Logicschaltung kein grosse Problem diese so in die Pipe einzubauen das sie entweder am Anfang oder am Ende benutzt werden.

Edit: Allerdings spart ein solches Vorgehen nur Bandbreite durch verhinderte Texturereads ein. Hat mal jemand geprüft ob sich der vorgezogene Z-Test auch auf die Pixelfillrate auswirkt?

[zeckensack]

Originally posted by aths
"Kostenlos" ist die Generierung der Subpixel, weil das TS entsprechend ausgelegt ist. Wenn die Pipeline dann noch 4 Z-Test-Einheiten hat, könnte man pro Takt bis zu 4 Subpixel gleicher Farbe erzeugen. Oder hab ich da mit meinem "gefährlichem Halbwissen" wieder einen Denkfehler?Hört sich doch gut an :)
Man könnte jetzt noch dazusagen, daß der Chip natürlich auch in der Lage sein muß, vier Subpixel gleichzeitig rauszuschreiben. Aber das kann man sich ja denken, also sage ich das jetzt einfach mal nicht.
*pfeif*

Und außer gefährlichem Halbwissen habe ich auch kaum etwas zu bieten :|

[zeckensack]

Originally posted by aths
Bei einem Test-Programm stünde noch die Frage wie man sicherstellt, dass durch 4x MS keine ergebnisverfälschenden Bandbreitenengpässe auftreten. Wenn man die Geschwindigkeit des Early-Z messen will, dann gibt's da keine Probleme.

Man malt einfach bildfüllende Quads hintereinander, und zwar front-to-back, sodaß nur die vorderste Schicht überhaupt gezeichnet wird. Das was dahinter liegt sollte dann vom Early-Z sofort verworfen werden, und belastet somit auch nicht die Bandbreite (bis auf Z-Reads, hmmm, 16bit nehmen).

[Quasar]

Das macht doch GL_Extreme, oder? (Naja, 'ne Textur ist auch drauf...)

[zeckensack]

Originally posted by Quasar
Das macht doch GL_Extreme, oder? (Naja, 'ne Textur ist auch drauf...) Eine blendende Idee ;D

Nein, wirklich :)

Mit Texturen und am besten noch kostspieligen Filtereinstellungen kann man denke ich Early-Z sogar nachweisen =)

Begründung:
Wenn der Chip kein Early-Z beherrscht, dann müssen für verdeckte Pixel Texturen gefiltert werden. Untexturierte Flächen sollten schneller sein als solche auf denen eine mit 8xTri-AF gefilterte Textur klebt.

Einem Chip mit Early-Z sollte es nichts ausmachen, Textur hin oder her, wenn ein Pixel verdeckt ist, wird es in konstanter Zeit verworfen.

:jump1:

[ow]

@ Zecki


Das Problem beim GL_Ext_reme ist, dass er fuer den Savage2k Werte ausspuckt, nach denen der S2k ein HSR-Tiler sein muesste.

Bei back-to-front ist er sogar etwas schneller als bei front-to-back rendering....

Ansonsten stimme ich mal zu.

-ow@work-

[Quasar]

GL_Extreme, 640x480x16, 60Hz
NoFSAA 2xFSAA 4xFSAA

F2B OD8 1224 1032 668
F2B OD3 2060 1593 864

B2F OD8 439 337 222
B2F OD3 1109 834 496

Rnd OD8 852 686 450
Rnd OD3 1515 1151 659


Uiuiui.....wilde Spekulationen machen sich in meinem Kopfe breit....bitte befreit mich davon mit einer korrekten Interpretation der Ergebnisse :)

edit:
Tabelle etwas ergänzt, OD= Overdraw-Faktor, Rnd= Random oder

[Demirug]

@Quasar:

Hast du auch Back to Front Werte zum vergleichen?

[Quasar]

Klar....ich editier' sie oben rein..

[aths]

Originally posted by Demirug
So jetzt kommt der Knackpunkt:
Gilt das nur bei deaktiviertem Z-Test oder auch mit Z-Test? Falls es nur beim deaktiviertem Test zutrift wäre das schon sehr dreist damit zu werben. Im anderen Fall müssen pro Pipeline auf jeden Fall 4 Z-Compares zur verfügung stehen.Der letzte Fall ist meine Vermutung: Jede Pipeline kann pro Takt 4 Z-Tests machen.

[frany]

Ach ja,
da es mal wieder Zeit war Geld in die Kiste zu werfen - fiel die Wahl auf die Graka... Vorraussetzung war mein Duron 750mhz blieb im Rennen ! Bisher werkelte einje Radeon 64MB DDR ViVo drin mit ca. 3000 Punkten im 3dmark 2001 - dann gabs zur Probe einmal eine Geforce 3 TI200 die Dame brachte es auf einen Hauch mehr als 4000 Pünktchen und zuletzt noch ein Durchlauf mit einer Geforce 4 TI4200 jetzt war ich schon bei über 5000 Zählern..... jaja ich weiß angezogene Handbremse aber trotzdem mal interessant. In der Praxis mit meinen Standard-Games war allerdings ab der Geforce 3 nicht mehr viel zusehen - also bliebs bei ihr... super fänd ich mal ein shootout aller aktuellen Grakas auf Low-End Cpu Niveau..

[Unregistered]

;o) Hey. Nvidia hat sich vor/während der Entwicklung des NV25 die GF3(NV20) bzw. die GPU der XBox genau angeschaut und bekannte Fehler beseitigt.-Der Chip wurde an vielen Stellen erweitert und verbessert.
Es kommt doch wohl auch sehr auf die Anwendung, die verwendete CPU+MB,die Treiber-Version usw... an. Bei Software, die DX8 wirklich nutzt, wird die GF4 bei gleichem Takt nicht nur 10-20% schneller sein! Auch das AA ist wesentlch schneller (vor allem die spezielle- QC-Version unter D3D! -Ich finde, dass Grafikboard mit NVs GF4Ti4200 z.Zt. mit Abstand das beste Preis/leistungsverhältnis haben (z.B.128MB Gf4Ti4200 /4ns Speicher ab 170Euro)-Wenn ich da an die Preise von meiner damaligen GF2Pro(ca.250 DM), oder der GF3 am Anfang denke (min. 500 E)!!! Die GF4Ti war von Anfang an billiger! Sogar die 4600er kostete am Anfang nur in Spezialversionen (GS/ViVo ...) über 500 Euro -normal so 400 -450Euro -Davon redet niemad!

[Unregistered]

;o) Sorry -Meinte natürlich ca. 250 Euro für die GF2Pro. Fakt ist, dass die GF4ti4200 bei mir in allen Benches viel schneller als die GF3 Ti 200 (auch wenn auf 235/475 übert.)ist.-Vor allem in hohen Auflösungen und mit aktiviertem AA/AF unter OGL-aber auch unter DX3D -Leider gibt es ja noch kaum Spiele, die DX8 richtig ausnutzen.(Zocke vor allem Shooter mit Q3A-Engine/UT-Engine)Auch bei DX-Titeln wie NOLF/UT2003/Auqanox ist die GF4Ti spürbar schneller. (Athlon 1200B/256MB Pc133/Via KT133 winXP Pro -neueste Treiber/Updates usw...)Bei höherer CPU-Leistung steigt der Abstand natürlich noch an.

[Pussycat]

Und wieso ist nVidia 'voll OK', wenn die GF4 schneller als die gf3 ist?

[ice cool69]

ich geb auf, wenn ich hier die letzte seite lese raucht mir der kopf und ich verstehe nur bahnhof :D

[Rampage 2]

Originally posted by aths

Bei 4x MSAA à la NV braucht man ggü. 2x deutlich mehr Bandbreite (grob über den Daumen gepeilt 60-70% mehr als mit 2x MSAA)

Ähm aths,

ich spiele SoF2 ab und zu mal bei 1600x1200x32Bit mit Quincunx-AA
auf meiner GF4 MX. Da ist mir etwas aufgefallen: Bei 2x-Quincunx
gegen 2x2-Quincunx (macht etwa 4xAA, oder?) gab es etwas Absurdes:

1.) sieht 2x-Quincunx (komischerweise) sehr viel schöner aus, als
2x2-Quincunx, die Kanten werden 100% eliminiert.
2.) zieht 2x-Quincunx (komischerweise) weit mehr Leistung ab als
2x2-Quincunx.

Ist das jetzt wieder eine Nvidia-Anomalie oder hat dein Tuner (benutze
dein "aTuner") oder meine Graka einen Fehler.

BTW, "darf" die GF4 MX nur aus Performance-Gründen nicht mehr als
2xAF filtern?

[aths]

Originally posted by Unregistered
Die GF4Ti war von Anfang an billiger! Sogar die 4600er kostete am Anfang nur in Spezialversionen (GS/ViVo ...) über 500 Euro -normal so 400 -450Euro -Davon redet niemad! Also für meine Ti 4600 (nix Vivo, nur VGA, DVI und TV-out) löhnte ich "am Anfang" 540€.

[Rampage 2]

hey aths,
danke hierfür, aber schau dir bitte mal meinen letzten topic auf
der letzten seite von "GeForce4 Ti im Verhältnis nicht viel schneller
als GrForce3 Ti"

Ach ja: Siehst hübsch aus! :) ([Avatar])

[Quasar]

Rampage, das liegt daran, dass "2x2" Quincunx, also der 4x 9-Tap Modus, wenn ich richtig rate, in wirklichkeit natürlich 4xOGMSAA mit Blur-Filter ist und als solches automatisch bei 1600x1200 abgeschaltet wird, da die 64MB auf deiner Karte nicht ausreichen.

[aths]

Originally posted by Rampage 2
ich spiele SoF2 ab und zu mal bei 1600x1200x32Bit mit Quincunx-AA
auf meiner GF4 MX. Da ist mir etwas aufgefallen: Bei 2x-Quincunx
gegen 2x2-Quincunx (macht etwa 4xAA, oder?) gab es etwas Absurdes:

1.) sieht 2x-Quincunx (komischerweise) sehr viel schöner aus, als
2x2-Quincunx, die Kanten werden 100% eliminiert.
2.) zieht 2x-Quincunx (komischerweise) weit mehr Leistung ab als
2x2-Quincunx.

Ist das jetzt wieder eine Nvidia-Anomalie oder hat dein Tuner (benutze
dein "aTuner") oder meine Graka einen Fehler.2x2 Quincunx = 4x 9 tap. Das ist deutlich langsamer als das normale Quincunx, aber ebenso noch unschärfer. Ich erfahre gerade, dass 4x 9 tap für den NV17 nicht verfügbar ist. Im nächsten aTuner-Update werde ich das dann mal für diesen Chip herausnehmen.

Wie auch Quasar schon sagte, 4x AA bei 1600x1200 können nur Karten ab NV25 mit 128 MB.
Originally posted by Rampage 2
BTW, "darf" die GF4 MX nur aus Performance-Gründen nicht mehr als
2xAF filtern? Die MX-e können nicht mehr als 2x AF filtern.