Diskussion zum Artikel "Matrox Parhelia: Theoretische Benchmarks"

[Leonidas]

http://www.3dcenter.org/artikel/parhelia_theoretische_benchmarks/


Ich habe bewußt nix kommentiert, da ich das den Freaks und Profis überlassen wollte. Just the benches ...


Update 29.6. 22:26
Benchmarks GF4Ti mit 220/275 Taktraten hinzugefügt


Update 1.7. 22:18
Templemark 1.0.6 hinzugefügt

[StefanV]

Naja, für 220MHz Core nicht schlecht.

Nur eins hätte ich gern gesehen:

Eine GF4 mit den gleichen Takten wie die Parhelia (220/275)...

[Leonidas]

Ich muß sehen, wie ich mir den Rest der Zeit genau einteile, welche ich die Parhelia noch habe.

[Birdman]

die GL Extreme Werte sind wirklich interessant....

Overdraw factor 3, back to front (fps) 240,03 / 315,56 (MGA/Nv)
Overdraw factor 3, front to back(fps) 240,15 / 514,32 (MGA/Nv)
Overdraw factor 3, random order(fps) 240,03 / 405,60 (MGA/Nv)

[Exxtreme]

Originally posted by Birdman
die GL Extreme Werte sind wirklich interessant....

Jupp, finde ich auch. Sie müssten zumindest bei Front2Back grösser ausfallen da Z-Buffering auch schon eine primitive Art von HSR darstellt.

Gruß
Alex

[Demirug]

Originally posted by Exxtreme

Jupp, finde ich auch. Sie müssten zumindest bei Front2Back grösser ausfallen da Z-Buffering auch schon eine primitive Art von HSR darstellt.

Gruß
Alex

Nur wenn die Speicherbandbreite der limitieren Factor ist. Ansonsten ist das wegspeichern der Frabwerte ja nur ein weiterer Schritt in der Pipeline der parralel ausgeführt wird.

[Quasar]

Was hast du denn mit GL_Extreme angestellt? Ich habe dort bei fast allen Teiltests deutlich höhere Werte? Sicher, daß nicht VSync oder AF(Die Füllrate sieht mir stark danach aus) angeschaltet war?

edit:
Auch der Templemark fällt um 50% zu niedrig aus....soo schlecht kann ein Pentium4 doch nicht sein....???

edit2:
Egal, was jetzt auch noch folgen mag: SUPERDANKESCHÖN, daß du für uns noch einen Nachschlag bereitgestellt hast!!!

[Exxtreme]

Originally posted by Demirug


Nur wenn die Speicherbandbreite der limitieren Factor ist. Ansonsten ist das wegspeichern der Frabwerte ja nur ein weiterer Schritt in der Pipeline der parralel ausgeführt wird.
Die Werte müssten sich trotzdem leicht ändern, spätestens bei Overdraw-faktor 8. Sie tun es aber nicht. Bei der GF4Ti ist es klar da ihr HSR mit Front2Back-Rendering am besten funktioniert. Der Nachteil bei F2B-Rendering ist, daß die Texturcaches nicht mehr so effizient abeiten können.

Gruß
Alex

[Leonidas]

Es folgen heute Abend noch Werte der GF4Ti auf 220/275, die recht interessant sind. Leider wurde diese Idee erst sehr spät geäußert :-).

[Leonidas]

Originally posted by Quasar
Was hast du denn mit GL_Extreme angestellt? Ich habe dort bei fast allen Teiltests deutlich höhere Werte? Sicher, daß nicht VSync oder AF(Die Füllrate sieht mir stark danach aus) angeschaltet war?

edit:
Auch der Templemark fällt um 50% zu niedrig aus....soo schlecht kann ein Pentium4 doch nicht sein....???




Nicht unmöglich. Wenn ein Programm stark auf P2/3 optimiert ist, performt es unter P4 teilweise katastrophal. Entweder muß es auf 486/P1 optimiert sein oder gleich ein extra P4 Pfad.

[Xmas]

Originally posted by Exxtreme
Die Werte müssten sich trotzdem leicht ändern, spätestens bei Overdraw-faktor 8. Sie tun es aber nicht. Bei der GF4Ti ist es klar da ihr HSR mit Front2Back-Rendering am besten funktioniert. Der Nachteil bei F2B-Rendering ist, daß die Texturcaches nicht mehr so effizient abeiten können.
Wieso sollten sich die Werte ändern? Die Parhelia ist klar füllratenlimitiert, die Bandbreite ist überdimensioniert. Und ohne Early-Z muss eben jeder Pixel durch die Pipeline, egal ob er verdeckt ist oder nicht. Die Tiefensortierung macht da keinen Unterschied.
Das mit den Texturcaches versteh ich jetzt nicht ganz. GL_Extreme benutzt doch hier nur eine einzige Textur AFAIK.

[Exxtreme]

Originally posted by Xmas
Das mit den Texturcaches versteh ich jetzt nicht ganz. GL_Extreme benutzt doch hier nur eine einzige Textur AFAIK.
Das habe ich mal gelesen, daß beim B2F-Rendering die Texturcaches besser ausgenutzt werden können als beim F2B-Rendering.

Gruß
Alex

[Quasar]

Originally posted by Leonidas
Nicht unmöglich. Wenn ein Programm stark auf P2/3 optimiert ist, performt es unter P4 teilweise katastrophal. Entweder muß es auf 486/P1 optimiert sein oder gleich ein extra P4 Pfad.

Könntest du beim Re-Test mit Parhelia-Frequenzen trotzdem nochmal genau gucken, ob da nicht irgendwas falsch eingestellt ist? So sehr ist der Templemark imho nicht optimiert, schließlich ist er für eine Graka, nicht für eine CPU.

[Quasar]

Hier (http://www.forum-3dcenter.org/vbulletin/showthread.php?s=&threadid=22727) nochmal im Posting von VoodooJack zu sehen, daß auch ein (zugegeben) sehr hoch getakteter P4 gute Templemarks erreichen kann.

[Xmas]

Originally posted by Exxtreme
Das habe ich mal gelesen, daß beim B2F-Rendering die Texturcaches besser ausgenutzt werden können als beim F2B-Rendering.

Gruß
Alex
Also davon habe ich noch nix gehört, und kann mir auch keinen plausiblen Grund dafür vorstellen, weil die Z-Sortierung ja auf das Rendern vor dem Z-Test überhaupt keinen Einfluss hat.

Die beste Ausnutzung der Texturcaches erreicht man natürlich mit Textursortierung (und das wird auch oft gemacht)


Die Ergebnisse der D3D-SDK-Tests deuten darauf hin, dass Matrox noch einiges an Treiberarbeit vor sich hat (und dass noch einiges am Potential drin ist), denn die teilweise 6-7fachen Frameraten der Ti4600 bei manchen Tests (und das bei höherer Texelfüllrate) sind nur mit der Hardware kaum zu erklären.

Wahrhaft erstaunlich finde ich aber auch diese Zahlen.
Pure transform
(Mill. Vertikel/sec) 2,999 17,937
2 point lights
(Mill. Vertikel/sec) 3,767 13,202
8 point lights
(Mill. Vertikel/sec) 3,768 5,365
2 directional lights
(Mill. Vertikel/sec) 3,767 15,399
8 directional lights
(Mill. Vertikel/sec) 3,768 7,708
Lustig, dass mit Lichtern die T&L-Leistung sogar steigt ;)
Im 3DMark siehts ganz anders aus.

[Quasar]

Ein Savage-Bug? Immerhin unterstützt Parhelia 12 HW-Lights...

Nur den Abfall mit 2 Point Lights würde das nicht erklären.

[Demirug]

Nachdem ich die ergebnisse der runtergetaktenden GF4 gesehen habe bin ich sogar langsam bereit zu glauben das ein 256 bit interface für NVidia wirklich ein unnötiger technischer overkill ist.

[Quasar]

Leo, irgendwas muss bei deinem Templemark vermurkst sein. 2,2fps mehr bei +80MHz Chiptakt (auf den's hier ankommt) KANN nicht sein.

Wenn ich meine GF4 um 20MHz übertakte habe ich schon fast 10 fps Zugewinn...

Welche Treiber benutztest du nochmal?

[Leonidas]

29.42

[Quasar]

Irgendwas läuft da schief, mit denselben Treibern krieg ich so um 130-140 fps....

[Leonidas]

Originally posted by Quasar
Leo, irgendwas muss bei deinem Templemark vermurkst sein. 2,2fps mehr bei +80MHz Chiptakt (auf den's hier ankommt) KANN nicht sein.




Hab es nochmal in beiden Takungen nachgemessen: Ergebnis stimmt.


Eventuell blockiert die CPU-Leistung.

[Leonidas]

Originally posted by Quasar
Irgendwas läuft da schief, mit denselben Treibern krieg ich so um 130-140 fps....



Hast einen Athlon XP ... doppelte theoretische FPU-Power.

[StefanV]

Originally posted by Quasar
Leo, irgendwas muss bei deinem Templemark vermurkst sein. 2,2fps mehr bei +80MHz Chiptakt (auf den's hier ankommt) KANN nicht sein.

Wenn ich meine GF4 um 20MHz übertakte habe ich schon fast 10 fps Zugewinn...

Welche Treiber benutztest du nochmal?

Quasar:

Wenn alles Glatt geht, dann sollte ich nächsten Mittwoch eine Radeon 8500 haben, dann kann ich den Templemark auch mal auf meinen beiden P4 Systemen laufen lassen und dir das Ergebnis mitteilen.

Mußt mir nur Mittwoch oder Donnerstag 'ne PM schicken.

[Quasar]

So, jetzt hab ich mal meinen AXP etwas runtergetaktet (100MHz extern/1300MHz intern).
Ergebnis:

Auf 300/325: 110,6
Auf 220/275: 103,6

So heftig kann der Unterschied zum P4 mit OC'ed FSB nicht sein...NIE! ;)

@SP:
Danke für das Angebot, ich hoffe, meine Radeon Montag zu bekommen, dann können wir nochmal schauen, wie sich das "apples 2 apples" verhält.

[Birdman]

wie misst man die Frames im Templemark?
habe da nirgends ne Anzeige, und wenn ich sie mit meinem Lineal messe, kommen keine FPS raus, sondern nur cm... ?-)

btw. als ich das ding beim ersten mal gestartet habe, ruckelte es an vielen stellen, auch beim zweiten und dritten durchlauf.
beim zweiten mal starten liefs dann aber flüssig....iss das normal ?

[zeckensack]

Danke, Leo. Guter Stoff :)

[Ancillius]

Mir ist etwas interessantes aufgefallen:
Total AGP Memory: 16 MB

Habt ihr in eurem 3dBench Test stehen. Auf diese einstellung reagiert ab Windows 2000 aufwärts schon die G400Max (mein Schätzchen) beleidigt. Warum das so ist, da setzt euch mit Matrox auseinander, aber es empfiehlt sich hier mindestens 32 besser 64 MB zu nehmen, so ist es jedenfalls bei meiner. Das soll vorallem abstürzen vorbeugen. Achja da fällt mir noch etwas zu ein. Kennt einer von euch eine Möglichkeit, wie man die Lockups der G400 bei vielen neuen Spielen umgehen könnte? (Und... neue Karte kaufen ist als Antwort sinnlos...)+
:)

[Quasar]

Originally posted by Birdman
wie misst man die Frames im Templemark?
habe da nirgends ne Anzeige, und wenn ich sie mit meinem Lineal messe, kommen keine FPS raus, sondern nur cm... ?-)

btw. als ich das ding beim ersten mal gestartet habe, ruckelte es an vielen stellen, auch beim zweiten und dritten durchlauf.
beim zweiten mal starten liefs dann aber flüssig....iss das normal ?

"D:\Benchmarks\TempleDemo-v1-0-6\Temple demo v1-0-6.exe" -benchmark

[nggalai]

Originally posted by Birdman
wie misst man die Frames im Templemark?
habe da nirgends ne Anzeige, und wenn ich sie mit meinem Lineal messe, kommen keine FPS raus, sondern nur cm... ?-)

btw. als ich das ding beim ersten mal gestartet habe, ruckelte es an vielen stellen, auch beim zweiten und dritten durchlauf.
beim zweiten mal starten liefs dann aber flüssig....iss das normal ? Ja, ist normal, so. Und zu den FPS: Templemark gibt die Ergebnisse in einer Text-Datei aus.

ta,
-Sascha.rb

[Leonidas]

Originally posted by Birdman
wie misst man die Frames im Templemark?
habe da nirgends ne Anzeige, und wenn ich sie mit meinem Lineal messe, kommen keine FPS raus, sondern nur cm... ?-)

btw. als ich das ding beim ersten mal gestartet habe, ruckelte es an vielen stellen, auch beim zweiten und dritten durchlauf.
beim zweiten mal starten liefs dann aber flüssig....iss das normal ?


Verknüpfung auf das Teil machen mit
-benchmark -width=1024 -height=768 -bpp=32

[Leonidas]

Originally posted by Ancillius
Mir ist etwas interessantes aufgefallen:
Total AGP Memory: 16 MB




Im BIOS sind 128MB eingestellt, 3DMark2001 zeigt das auch so an.

[Quasar]

Originally posted by Leonidas
Verknüpfung auf das Teil machen mit
-benchmark -width=1024 -height=768 -bpp=32

Das kursive ist überflüssig, da der Templemark eh nur in dieser Res läuft.

[ow]

Originally posted by Demirug


Nur wenn die Speicherbandbreite der limitieren Factor ist. Ansonsten ist das wegspeichern der Frabwerte ja nur ein weiterer Schritt in der Pipeline der parralel ausgeführt wird.


Bist du da ganz sicher?

Meine MX bei 640x480x32 (dürfte hier kaum Bandbreitenlimitiert sein):

Overdraw factor 3, back to front: 170.50 fps
Overdraw factor 3, front to back: 227.38 fps
Overdraw factor 3, random order: 200.36 fps

Overdraw factor 8, back to front: 64.69 fps
Overdraw factor 8, front to back: 97.20 fps
Overdraw factor 8, random order: 86.57 fps

[ow]

Originally posted by Leonidas




Hab es nochmal in beiden Takungen nachgemessen: Ergebnis stimmt.


Eventuell blockiert die CPU-Leistung.



Nicht den 1.0.2 Templemark verwenden.
AFAIK swapt der auf der HDD und liefert schlecht reproduzierbare Ergebnisse. Nimm den 1.06.

[ow]

Originally posted by Birdman
wie misst man die Frames im Templemark?
habe da nirgends ne Anzeige, und wenn ich sie mit meinem Lineal messe, kommen keine FPS raus, sondern nur cm... ?-)

btw. als ich das ding beim ersten mal gestartet habe, ruckelte es an vielen stellen, auch beim zweiten und dritten durchlauf.
beim zweiten mal starten liefs dann aber flüssig....iss das normal ?

s.o.. Den 1.0.6 verwenden.

Benchen: "-benchmark" als Option an die Verknüpfung zum Templemark.

[ow]

Mein Kommentar zu den benches:

Die T&L Leistung ist sehr mässig. Da funktioniert irgendwas noch nicht beim Parhelia.

Hier mal die T&L Werte der Radeon1 im GL_Extreme (1024x768x32):

T&L/High polygon count static display list:
-------------------------------------------
Pure transform: 8023707 vertices / s
2 point lights: 7184507 vertices / s
8 point lights: 5617654 vertices / s
2 directional lights: 7330460 vertices / s
8 directional lights: 7267012 vertices / s

und hier eine RivaTNT PCI in 640x480x32:

T&L/High polygon count static display list:
-------------------------------------------
Pure transform: 5469604 vertices / s
2 point lights: 3049747 vertices / s
8 point lights: 1601912 vertices / s
2 directional lights: 3728492 vertices / s
8 directional lights: 2513624 vertices / s


/edit:

zum SDK VertexBlend:

mein Kyro1 erreicht hier etwa 160fps (1024x768x32), der Parhelia 336, der gf4 (220/275) 1337.


/edit2:

Die nur 16MB AGP Mem lassen mich vermuten, dass es mit dem AGP noch klemmt, das könnte auch die schwache Polygonleistung erklären. Wenn dem so ist, dann wäre bei funktionierendem AGP Support der Karte mit einer erheblichen Leistungssteigerung zu rechnen (>30% IMO).

[Leonidas]

Originally posted by ow




Nicht den 1.0.2 Templemark verwenden.
AFAIK swapt der auf der HDD und liefert schlecht reproduzierbare Ergebnisse. Nimm den 1.06.


Hab mir die extra neu bei PowerVR gezogen *wunder*.

[Leonidas]

> Die nur 16MB AGP Mem lassen mich vermuten, dass es mit dem AGP noch klemmt,


Dies wäre eine Möglichkeit. Sollte eventuell doch mal die Benmark-Werte rauskramen: 1400 MB/sec Vertex Traffic auf GF4 gegen 500 MB bei Parhelia.



Leider weiss ich immer noch nicht, was der Benmark da genau bencht ... es hängt stark von der AGP-Rate ab, aber es nicht die AGP-Transfer, da es teilweise über 1 GB/sec hinausgeht.

[ow]

Originally posted by Leonidas



Hab mir die extra neu bei PowerVR gezogen *wunder*.


Die PVR Hauptseite ist nicht ganz aktuell.
Nimm den hier (ist auch wesentlich kleiner als der 1.0.2):

http://www.pvrdev.com/extra/h/Temple.htm

[Demirug]

@ow:

Bei einem Fillratetest spielt die Bildschirmauflösung eigentlich nur eine untergeordnete Rolle. Wenn die Limitierung wirklich durch die Speicherbandbreite entsteht kann man mit höheren auflösungen sogar besser Texelfillrates erhalten wenn die Textur kleiner als die bildschirm Auflösung ist. Um die Corefillrate zu finden sollte man sogar eine ganz kleine Textur benutzen die komplett in den Cache passt.

[Quasar]

Der BenMark ist dafür eher weniger aussagekräftig, imho. Er ist extrem (logischerweise) auf nV zugeschnitten und nutzt natürlich auch Fastwrites zum Anschlag aus, aus dem andere Karten angeblich bis heute kaum einen Vorteil ziehen können....

[Quasar]

Also, ich hab mir nochmal 'nen Bench von einem P4 Northwood mit 2,2GHz(110MHz extern) organisiert. Graka war eine GF3 Ti 500, nicht OC'ed.

Damit kommt man in der 1.06-Version auf sportliche 131,2fps.
edit: Irgendwie hat er's hinbekommen, den Bench auf 640 laufen zu lassen, also wenigsten limitiert nicht die Graka....(ist wohl aber keine Absicht gewesen, beim ihm startet das Teil per Default auf 640

Der Templemark scheint dem P4 also ziemlich gut zu liegen, besser anscheinend als dem AthlonXP.

[Demirug]

@Quasar:

Also ich kann beim Benmark im Quellcode nichts endecken was extra auf NV zugeschnitten wäre.

[ow]

Originally posted by Demirug
@ow:

Bei einem Fillratetest spielt die Bildschirmauflösung eigentlich nur eine untergeordnete Rolle. Wenn die Limitierung wirklich durch die Speicherbandbreite entsteht kann man mit höheren auflösungen sogar besser Texelfillrates erhalten wenn die Textur kleiner als die bildschirm Auflösung ist. Um die Corefillrate zu finden sollte man sogar eine ganz kleine Textur benutzen die komplett in den Cache passt.


Erklärt das jetzt, warum die Scores beim Parhelia unabhängig von der Sortierung identisch sind?

Sowas zeigt nur meine Kyro und (eingeschränkt) meine Radeon1.

Und bei F-to-B sorting werden ja alle Pixel (FB und Z-Buffer) mehrfach beschreiben, als sollte doch ein Unterschied zu B-to-F sorting sein?
Bei allen Chips ohne HSR/early Z check.

[Quasar]

Nein?? Das erstaunt mich jetzt aber wirklich, da das Teil offiziell von der nV-Homepage kommt.

tststs....ich und meine Vorurteile ;)

[ow]

Originally posted by Demirug
@Quasar:

Also ich kann beim Benmark im Quellcode nichts endecken was extra auf NV zugeschnitten wäre.


Hätte ich auch nicht angenommen, das ist ja nur ein recht primitiver Test der Bus-Transferrate.

[ow]

Originally posted by Quasar
Nein?? Das erstaunt mich jetzt aber wirklich, da das Teil offiziell von der nV-Homepage kommt.

tststs....ich und meine Vorurteile ;)


tststs :nono:

immer diese Vorurteile;)

[Demirug]

Originally posted by Quasar
Nein?? Das erstaunt mich jetzt aber wirklich, da das Teil offiziell von der nV-Homepage kommt.

tststs....ich und meine Vorurteile ;)

Du must bedenken zu welchem Zeitpunkt und zu welchem Zweg der BenMark geschaffen wurde. Er sollte die überragende T&L Leistung der GF1 zeigen. Darum werden bei dem Test einfach viele kleine Dreiecke in großen Baches über den Bus gejagt.

Das Teil ist absolute simple.

[Quasar]

Stimmt, aber ich hätte eigentlich gedacht, daß man auch dabei bestimmt Eigenarten des Chips berücksichtigen könnte, aber von Programmierung hab ich ja nun wirklich Null Ahnung (mehr).

[Demirug]

Originally posted by ow



Erklärt das jetzt, warum die Scores beim Parhelia unabhängig von der Sortierung identisch sind?

Sowas zeigt nur meine Kyro und (eingeschränkt) meine Radeon1.

Und bei F-to-B sorting werden ja alle Pixel (FB und Z-Buffer) mehrfach beschreiben, als sollte doch ein Unterschied zu B-to-F sorting sein?
Bei allen Chips ohne HSR/early Z check.

Der Parhelia hat wie wir ja alle bereits wissen für seine rissige Speicherbandbreite zuwenig Pixelfillrate (Die Textfillrate ist ja nicht schlecht) zur verfügung. Für Chips ohne early Z gibt ist der einzige unterschied zwischen F2B und B2F das im zweiten fall für jeden Pixel 8 Byte zusätzlich geschrieben werden müssen. Also nur eine Frage der Speicherbandbreite. Und damit Speicherlatenzen nicht die Pipeline bremsen wird der Speicher über den Memorycontroler entkoppelt. Wäre das nicht der Fall könnte man den Speicher ja auch nur Taktsyncron zum Chip betreiben.

[Demirug]

Originally posted by Quasar
Stimmt, aber ich hätte eigentlich gedacht, daß man auch dabei bestimmt Eigenarten des Chips berücksichtigen könnte, aber von Programmierung hab ich ja nun wirklich Null Ahnung (mehr).

Bei Opengl könnte man das durchaus. Bei DX hast du bei so simplen sachen fast keine Möglichkeit. Das einzige was man varieren könnte wäre die größe der einzelnen Jobs. Das dumme dabei ist nur das die Chips da alle in etwa die gleichen vorlieben haben.

[zeckensack]

Originally posted by ow
Bist du da ganz sicher?

Meine MX bei 640x480x32 (dürfte hier kaum Bandbreitenlimitiert sein):

Overdraw factor 3, back to front: 170.50 fps
Overdraw factor 3, front to back: 227.38 fps
Overdraw factor 3, random order: 200.36 fps

Overdraw factor 8, back to front: 64.69 fps
Overdraw factor 8, front to back: 97.20 fps
Overdraw factor 8, random order: 86.57 fps ow, mit Verlaub, aber die MX ist in 32bit Farbtiefe immer bandbreitenlimitiert. Erst bei 16bit geht's, der hohe Z-Buffer-Traffic durch künstlich hohen Overdraw haut aber auch dann noch rein. Spätestens mit aktivem Blending rennt sie total vor die Wand.

[zeckensack]

Originally posted by Leonidas
Dies wäre eine Möglichkeit. Sollte eventuell doch mal die Benmark-Werte rauskramen: 1400 MB/sec Vertex Traffic auf GF4 gegen 500 MB bei Parhelia.

Leider weiss ich immer noch nicht, was der Benmark da genau bencht ... es hängt stark von der AGP-Rate ab, aber es nicht die AGP-Transfer, da es teilweise über 1 GB/sec hinausgeht. Das dürfte daran liegen, daß die Geforce zwar Vertex-Daten im lokalen RAM speichert, Indizes aber immer über den AGP laufen. Index-Traffic beläuft sich im Worst Case (2D-Float-Vertices, 32bit Integer-Indizes) auf 33% des Gesamtdurchsatzes.

[Leonidas]

Originally posted by Quasar
Der BenMark ist dafür eher weniger aussagekräftig, imho. Er ist extrem (logischerweise) auf nV zugeschnitten und nutzt natürlich auch Fastwrites zum Anschlag aus, aus dem andere Karten angeblich bis heute kaum einen Vorteil ziehen können....


Jo, ich lass den lieber raus, der ist zu wenig validiert.

[aths]

Originally posted by ow
Meine MX bei 640x480x32 (dürfte hier kaum Bandbreitenlimitiert sein):Bei entsprechend starker CPU ist sie auch hier bandbreitenlimitiert. Wäre sie das nicht, dann wäre der Test heftig CPU-limitiert, und das kann ja nicht der Sinn eines Graka-Vergleiches sein.

[aths]

Originally posted by ow
Und bei F-to-B sorting werden ja alle Pixel (FB und Z-Buffer) mehrfach beschreiben, als sollte doch ein Unterschied zu B-to-F sorting sein?
Bei allen Chips ohne HSR/early Z check. Hat Xmas schon erklärt: Auf herkömmlichen IR spart F2B-Sorting nur Bandbreite, wovon Parhelia aber genug hat.

[aths]

Leo: Coole Idee, Parhelia gegen Ti@220/275 zu benchen. Das hat glaube ich bislang noch keine Seite gemacht und ist recht interessant.

[Birdman]

Brrrrr, ist die GTS sooo schlecht?
Ich krieg mit der beim templemark 38.8fps mit den defaultsettings (1024x32bit)
dat ganze mit nem Northwood 2266...

[StefanV]

Originally posted by Birdman
Brrrrr, ist die GTS sooo schlecht?
Ich krieg mit der beim templemark 38.8fps mit den defaultsettings (1024x32bit)
dat ganze mit nem Northwood 2266...

Ja, die GTS ist so schlecht.

Die Radeon 1 hat AFAIK eine höhere Bandbreite...

[Xmas]

Originally posted by Stefan Payne
Die Radeon 1 hat AFAIK eine höhere Bandbreite...
Die "normale" Radeon DDR hat dieselbe Bandbreite.

[Quasar]

...aber nur die Radeon mit Retailtaktung.

Birdman,
Die GTS hat weder HSR-Techniken, noch kann sie ein Loopback, so daß sie für den Templemark drei Passes braucht, inkl. der zusaätzlichen Anforderungen an Füllrate und Speicherbandbreite.

Der Wert ist normal, auch wenn man ihn schon auf 'nem Duron mit 900MHz erreicht ;)

[zeckensack]

Originally posted by Quasar
...aber nur die Radeon mit Retailtaktung.Ich weiß zwar nicht, wie bei der GTS die Standardtakte aussehen und weiß auch nicht, was das hiermit zu tun haben soll ;) , aaaber die Radeon 32MB taktet mit 166MHz, die 64MB-Version mit 183MHz. OEM? Gab's sowas damals überhaupt schon bei ATi ???

[Quasar]

GF2 GTS taktete mit 200/166MHz.

Radeons afaik mit 166/166MHz in der 32MB-Version und der 64MB-OEM-Version, sowie 183MHz in der 64MB-Retail-Version.

[Birdman]

so, nun noch mit einer ti500 auf nem celli 1.1@1.45Ghz getestet....
respektable 90.2fps, verglichen zur GTS sind das ja wirklich Welten.

[StefanV]

Originally posted by Xmas

Die "normale" Radeon DDR hat dieselbe Bandbreite.

Theoretisch schon, praktisch hat die Radeon HyperZ, die GTS nicht :D

[Birdman]

Originally posted by Stefan Payne
Theoretisch schon, praktisch hat die Radeon HyperZ, die GTS nicht :D
Deswegen gewinnt sie imho auch diesen test recht klar, die taktfrequenz hat einen geringeren Einfluss, und soweit ich das sehen konnte, hat die CPU gar keinen :D

[Axel]

Danke an Leonidas für die vielen Zahlen.

Einige kann ich zwar persönlich nicht einordnen, da ich nicht weiß welche Funktion getestet wurde, finde aber auch genügend selbsterklärende Benchmarks. Es zeigt sich, daß der GF4 meist deutlich höhere Zahlen bietet, aber der Parhelia punktuell hervoragende Werte ermöglicht.
Die Werte der Parhelia sind aber für mich nicht immer logisch und habe deshalb folgende Fragen:
Wieso ist der PixelShader langsamer als der Advanced-PS bei 3Dmark2001SE ?
Was wird bei "BumpWaves" gemessen? Warum ist die Matroxkarte in diesem Benchmark deutlich schneller ? Welche Chipteile sind dafür verantwortlich ?
Warum sind die Frames der Parhelia bei PointSprite im SDK höher, der MSprites/sec-Wert im eigentlichen Benchmark niedriger als bei der GF4 ?
Bei GLExtreme werden Benchmarks mit 2 und 8 Lichtquellen gefahren. Warum sind sämtliche Werte bei der Parhelia gleich ? Ist es egal ob 2 oder 8 (bzw. 12) Lichtquellen genutzt werden, weil diese parallel bearbeitet werden ? Was macht die Geforce anders ?

Gruß Axel

[Xmas]

Originally posted by Stefan Payne
Theoretisch schon, praktisch hat die Radeon HyperZ, die GTS nicht :D
Theoretisch sollte die Radeon die GTS deswegen fast überall ausperformen, praktisch tut sie es nicht :D

[StefanV]

Originally posted by Xmas

Theoretisch sollte die Radeon die GTS deswegen fast überall ausperformen, praktisch tut sie es nicht :D

Jep, weil sie enorm Fillrate Limitiert ist...

[Quasar]

"enorm" ist ein wenig übertrieben, findest du nicht? Wie wäre es mit "...da sie Füllraten-, Bandbreiten- und Treiberlimitiert ist?"

[Xmas]

Wieso ist der PixelShader langsamer als der Advanced-PS bei 3Dmark2001SE ?

Weil es ein ganz anderer Test ist.

Was wird bei "BumpWaves" gemessen? Warum ist die Matroxkarte in diesem Benchmark deutlich schneller ? Welche Chipteile sind dafür verantwortlich ?

EMBM, eine große Wasserfläche mit Wellen, in der sich eine Hintergrundtextur spiegelt. (Die bekannte G400-EMBM-Szene)

Bei GLExtreme werden Benchmarks mit 2 und 8 Lichtquellen gefahren. Warum sind sämtliche Werte bei der Parhelia gleich ? Ist es egal ob 2 oder 8 (bzw. 12) Lichtquellen genutzt werden, weil diese parallel bearbeitet werden ? Was macht die Geforce anders ?
Wenn man mit den 3DMark-Ergebnissen vergleicht, sieht man dass irgendetwas den Geometriedurchsatz in GLExtreme stark limitiert, schon bevor T&L überhaupt zum Zuge kommt.

[StefanV]

Originally posted by Quasar
"enorm" ist ein wenig übertrieben, findest du nicht? Wie wäre es mit "...da sie Füllraten-, Bandbreiten- und Treiberlimitiert ist?"

1. hm, stimmt ist ein wenig übertrieben, laß es jetzt aber stehen...

2. nö...

[Demirug]

Originally posted by Xmas
Wenn man mit den 3DMark-Ergebnissen vergleicht, sieht man dass irgendetwas den Geometriedurchsatz in GLExtreme stark limitiert, schon bevor T&L überhaupt zum Zuge kommt.

Ja OpenGL ist der limitierende factor.

[Quasar]

???
Aber nur Treiberbedingt, oder wie meinst du das?

[Demirug]

Originally posted by Quasar
???
Aber nur Treiberbedingt, oder wie meinst du das?

In gewisser Weisse (wie bei DX auch) natürlich Treiber bedingt. Wenn du aber bei OpenGL die Geometrie über die ganz normale API übergibts bekommst du immer nur eine mäsige Performancen egal wer den Treiber geschrieben hat. Das ist technisch durch das Verfahren bedingt.

Oder warum glaubst du hast jeder Hersteller eine eigene Extension für die Geometrieübergabe. Und OpenGL 2.0 geht das Problem ja auch an.

[Quasar]

Hm...Ich habe jetzt zwar keine Vergleichswerte für ATi-Karten, aber afair performen die nicht so schlecht unter GL-Excess, auch nicht (mehr) in den Hi-Poly-Teilen. Matrox nutzt doch eine ganze Menge Geometrie-Extensions und trotzdem sind sie deutlich hinter der GF4 hinterher, obwohl sie doppelt soviele Vertexshader haben, über die wohl auch hier die Geometrieverarbeitung läuft...

Irgendwie kapier ich's immer noch nicht.

[Xmas]

Also diese Ergebnisse erstaunen mich auch ein bisschen:

BumpWaves(fps) 500 348 263 320
PointSprite(fps) 107 73 65 50
Die kursiven Werte sind das, was ich auf meinem System (Duron 850, Ti200, WinXP, Deto29.42) erreiche. Irgendwie passt dazu die Leistung der Ti4600 nicht...

[Demirug]

@Quasar:

Hups du hast recht. Wo ich mir die Zahlen das erste mal angeschaut habe wollte mein Gehirn woll nicht wahrhaben das die werte so schlecht sind.

Wobei die Geometrie-Extensions damit nicht zu tuen haben da AFAIK GL-Excess keine benutzt.

Die 4 Vertexshader nutzen nichts wenn sie nicht schnell genung gefütert werden und da scheint das Problem zu liegen.

[Xmas]

Korrektur:

BumpWaves(fps) 500 348 263 358
PointSprite(fps) 107 73 65 52

Die vorherigen Ergebnisse waren mit D3D Debug-DLL und Winamp im Hintergrund.

Edit: A propos Debug-Version... Leo, bist du sicher dass du bei deinem Test die Retail-DLLs ausgewählt hast als du das DXSDK installiert hast? Oder hast du nur die Demos kopiert?

[Quasar]

Originally posted by Xmas
Edit: A propos Debug-Version... Leo, bist du sicher dass du bei deinem Test die Retail-DLLs ausgewählt hast als du das DXSDK installiert hast? Oder hast du nur die Demos kopiert?

Daran musste ich auch grad denken. Ist mir auch mal passiert....

edit:
Konnte die Werte mit RETAIL-DX8 reproduzieren....hier scheint Parhelia wirklich einfach schneller zu sein

[zeckensack]

Das Thema "Ist der Pentium 4 wirklich schnell genug für Graka-Benchmarks?" ist gerade in Arbeit (http://www.forum-3dcenter.org/vbulletin/showthread.php?threadid=24849) ...

[Xmas]

Originally posted by Quasar
edit:
Konnte die Werte mit RETAIL-DX8 reproduzieren....hier scheint Parhelia wirklich einfach schneller zu sein
Aber wieso ist dann meine GF3Ti200 schneller als die Ti4600 beim BumpWaves?

[Quasar]

Tja, das weiss ich auch nicht. Aber vielleicht setzen GF3 und GF4 unterschiedliche Verfahren für Bump-Mapping ein und genau dieser Test deckt eine Schwachstelle dieses Unterschiedes auf....wie gesagt, keine Ahnung.

[StefanV]

Originally posted by zeckensack
Das Thema "Ist der Pentium 4 wirklich schnell genug für Graka-Benchmarks?" ist gerade in Arbeit (http://www.forum-3dcenter.org/vbulletin/showthread.php?hreadid=24849) ...

'no Thread specifided...

[zeckensack]

Originally posted by Stefan Payne


'no Thread specifided... Link ist korrigiert. Es fehlte ein banales "t". Hat bestimmt das böse große T geklaut, das hier im Forum sein Unwesen treibt ...

Das Thema hat sich aber wie's aussieht in der Zwischenzeit beinahe erledigt.

[aths]

.

(hat sich erledigt.)

[Quasar]

Hab' Dank, aths. Als Stefan das vorhin gepostet hat, habe ich es nicht verstehen können, aber deine eloquente Ausführung machte es mir klar wie Postingschinden.

edit:
Hat sich wohl auch erledigt, da dieser Post jetzt allein im luftleeren Raum steht. Eigentlich war er auf aths' erneute Erwähnung von HyperZ der Radeon I bezogen.

[StefanV]

Originally posted by Stefan Payne

Theoretisch schon, praktisch hat die Radeon HyperZ, die GTS nicht :D

@aths ;-)

[Leonidas]

Originally posted by Xmas
Edit: A propos Debug-Version... Leo, bist du sicher dass du bei deinem Test die Retail-DLLs ausgewählt hast als du das DXSDK installiert hast? Oder hast du nur die Demos kopiert?



Ich hab die Retail-Version installiert, nix mit der Debug-Version.


Allerdings hab ich die nur unter Win98 installiert !!!!!!!!! Die Tests wurden dann aber unter Win2k ausgeführt, in dem Sinne habe ich die Demos nur "kopiert" (bei beiden Karten), d.h. ohne Installation benutzt (war nur ein kleiner Reg-Eingriff nötig). Wo wäre da der Unterschied?

PS: Das SDK lies sich sowieso nicht unter 2k installieren, ich hatte hier keine größere Wahl.

[Quasar]

Originally posted by Xmas
Korrektur:

BumpWaves(fps) 500 348 263 358
PointSprite(fps) 107 73 65 52

Die vorherigen Ergebnisse waren mit D3D Debug-DLL und Winamp im Hintergrund.

Xmas,
zu der Geschichte mit den Point Sprites, die ja offenbar nicht linear mitzuskalieren scheinen auf dem höheren Takt einer GF4, habe ich hier (http://www.extremetech.com/print_article/0,3428,a%253D22391,00.asp) etwas interessantes gelesen:
As mentioned, NV25 inherits NV2A's particle engine, although it turns out that parts of that particle engine were actually in NV20, but weren't exposed to Direct3D. On the OpenGL side, particle effects will go faster due to the higher vertex throughput rate, according to Kirk.

So, wie sich das liest, scheint die GF4 eine gesonderte Particle-Engine zu haben, die den Rest des 3D-Kerns nicht belastet, während die GF3 dies wohl noch per Shader oder FF-TnL erledigt, die Pipe aber dann logischerweise für alles andere blockiert wäre, in Real-World Tests also deutlich schlechter performen würde.

[Thowe]

Originally posted by zeckensack
Link ist korrigiert. Es fehlte ein banales "t". Hat bestimmt das böse große T geklaut, das hier im Forum sein Unwesen treibt ...


:|

:...( meine Kinder, meine Kinder ;)

[Leonidas]

Habe soeben Zahlen des Templemark 1.0.6 hinzugefügt (in Klammern 1.0.2):


MGA: 57,5 (54,3)
GF4Ti4600: 100,7 (86,6)
GF4 @ 220/275: 90,7 (84,4)

[Quasar]

Naja, zumindest dreistellig bei der GF4. IMHO aber immer noch zuwenig. ;)

Aber Matrox gewinnt ja noch deutlich weniger, als nV.....

[StefanV]

Originally posted by Leonidas
Habe soeben Zahlen des Templemark 1.0.6 hinzugefügt (in Klammern 1.0.2):


MGA: 57,5 (54,3)
GF4Ti4600: 100,7 (86,6)
GF4 @ 220/275: 90,7 (84,4)

Radeon 8500LE auf P4@1737MHz, 128MB RAM->44,9fps

HAL, Trilinear, Texture Compression -> ON
FSAA -> OFF

Treiber ist 6102 Catalyst, i850 Chipset Driver ist NICHT Installiert, Performance ist also höher ;)

Anscheinend

[ow]

*gruebel*


Was will und Stefan hiermit sagen?? Weiss das jemand?

[Quasar]

Was SP uns sagt, ist, daß eine Radeon trotz HSR durch Hyper-Z II, trotz 6x Single-Pass MT und trotz 250/250MHz Taktung auf seinem Rechner nur so schnell läuft wie bei mir damals eine GF2 GTS auf einem T-Bird@1500.

Unmöglich!!!

[StefanV]

Originally posted by ow
*gruebel*

Was will und Stefan hiermit sagen?? Weiss das jemand?

Ja, schau mal weiter vorne im Thread (weiß nicht, obs dieser war oder der andere)...

[StefanV]

Originally posted by Quasar
Was SP uns sagt, ist, daß eine Radeon trotz HSR durch Hyper-Z II, trotz 6x Single-Pass MT und trotz 250/250MHz Taktung auf seinem Rechner nur so schnell läuft wie bei mir damals eine GF2 GTS auf einem T-Bird@1500.

Unmöglich!!!

Naja, das letzte mal hab ich den Templemark auf meinem Athlon 1000C am Laufen gehabt, da hab ich über 60fps geschafft, liegt also nicht an der Radeon...

Wie gesagt, ich sollte wohl endlich mal den i850 AGP 'Treiber' installieren...

BTW: ich hab allerhand an den Einstellungen gefummelt, mit 2X Qualaty AA bekomm ich immer noch 33fps...

[Birdman]

52fps mit 2xFSAA und 8xAF :D
27fps mit 4S FSAA und 8xAF..und dazu gesellen sich darstellungsprobleme bei den berüchtigten flammen *eg*

------------
2.26Ghz
ti6400
512MB
------------

[StefanV]

Originally posted by Leonidas
Habe soeben Zahlen des Templemark 1.0.6 hinzugefügt (in Klammern 1.0.2):


MGA: 57,5 (54,3)
GF4Ti4600: 100,7 (86,6)
GF4 @ 220/275: 90,7 (84,4)

Ich schaffe mit meinem 1,737GHz P4 (Willamette, 13x133Mhz, 400MHz, 128MB RDRAM) 97,8 fps beim Templemark.

mit 2X (Qualaty) FSAA: 60,4 fps *eg*

Ach und mit 2x Perf und 16x AF (k/a obs an ist): 73,8fps...

Hm, interessant, ich kassiere hier mit einem lahmen 1,737GHz P4 und Radeon 8500LE Birdie mit seinem 2,26GHz P4 und TI4200, und das MIT FSAA...

[Birdman]

mit "nur" 2x FSAA, hab ich 105.2fps, und dabei habe ich meine Graka noch underclocked auf 280/650. (muss zur Zeit testen wie das ganze mit dem zalman passiv so tut)
tja, da muss deine Ati früher aufstehen um meinem gefrosch das Müsli wegfressen zu können :D

btw. mit 2xAF dazu sind es noch 77.8fps, mit 4xAF 59.3fps und bei 8xAF noch 52fps.
kannst du die 16AF benches mal mit 2xQ machen, denn 2x performance sieht ja schon fast schlechter aus als ganz ohne FSAA. ;)