Vertex shader des R300 ineffektiv?

[Demirug]

http://www.ixbt.com/video2/images/r9500/sdk-mesh.png

Edit: Falls das bild nicht angezeigt wird: http://www.ixbt.com/video2/images/r9500/sdk-mesh.png In einem neuen fenster öffnen.

für alle die sich jetzt denken,

"Was schreibt der da? Ist er jetzt ganz durchgedreht? die R300 Chips sind doch schneller!"

folgende erklärung:

Die absoluten Zahlen sind natürlich besser aber wenn wir mal die Zahlen auf 100 MHz bei 1 Vertexshader normaliesieren ergibt sich folgendes Bild.


Optimized

GF TI 4200 9,36
GF TI 4600 9,33
R 9500 5,48
R 9700 5,51
R 9700 Pro 5,43

Unoptimized

GF TI 4200 3,46
GF TI 4600 3,50
R 9500 1,42
R 9700 1,43
R 9700 Pro 1,41

Strip

GF TI 4200 7,30
GF TI 4600 7,30
R 9500 5,48
R 9700 5,51
R 9700 Pro 5,46


Im Optimized Fall ereichen die R300 VS nicht mal 60% der NV25 VS. Bei unoptimierten Vertexdaten sind es nicht mal mehr 45%. Bei einem unoptimierten Strip erreichet der R300 etwas mehr als 75%. Das zudem die R300 ergebnisse beim strip und Optimized gleich sind läst natürlich die frage aufkommen ob der R300 überhaupt einen Vertexcache hat?

Schlussfolgerung:

Selbst wenn NVIDIA beim NV30 nur 3 Vertexshader mit der gleichen Qualität wie beim NV25 verbaut wird sie schon bei gleichem Coretakt genauso gut oder besser als die R300 Lösungen darstehen. Weil

NV: 9,34 * 3 = 28.02
ATI: 5.48 * 4 = 21.92

NV: 3.48 * 3 = 10.44
ATI: 1.42 * 4 = 5.68

NV: 7.30 * 3 = 21.9
ATI: 5.48 * 4 = 21.92

In diesem Sinne:

Die Anzahl der Vertexshader sagt also nichts über die mögliche Vertexshaderleistung aus.

[Dunkeltier]

Könntest du mir mal erklären, was die Zahlen zu bedeuten haben bzw. worauf sie sich beziehen?

[Unreal Soldier]

Originally posted by Dunkeltier
Könntest du mir mal erklären, was die Zahlen zu bedeuten haben bzw. worauf sie sich beziehen?

Das ist eine gute Frage. Aber wenn das obige stimmt warum ist es denn so bei den Atis ????
WElche Grund macht sie langsamer???

MfG
Unreal Soldier

[Demirug]

Originally posted by Dunkeltier
Könntest du mir mal erklären, was die Zahlen zu bedeuten haben bzw. worauf sie sich beziehen?

Die Zahlen geben die Ergebnisse an die erreicht würden wenn nur ein VS benutzt würde und die Chips jeweils nur mit 100 MHz Coretakt laufen würden.

Die Rechnung unten spiegelt eine NV-Chip mit 3 VS (meine vermutung bzg NV30) im vergleich zum R300 (4 VS) bei 100 MHz Coretakt wieder.

[Unregistered]

fehlende Caches oder sonst was. Irgendeine Designentscheidung bzw ein Kompromiss wird da schon gefallen sein.

@Demi
Wäre es dir möglich noch Werte zur Radeon8500 hinzuzufügen?
Dann könnte man sich ein noch besseres Bild machen.

[Höhnangst]

Mich würde viel eher interessieren, woher die Zahlen der Leistungsfähigkeit der einzelnen VS überhaupt kommen bzw. wo sie stehen?

Und welche Einheit ist das?

[Unregistered]

Originally posted by Demirug


Die Zahlen geben die Ergebnisse an die erreicht würden wenn nur ein VS benutzt würde und die Chips jeweils nur mit 100 MHz Coretakt laufen würden.

Die Rechnung unten spiegelt eine NV-Chip mit 3 VS (meine vermutung bzg NV30) im vergleich zum R300 (4 VS) bei 100 MHz Coretakt wieder.

In welchem Programm/ welcher Anwendung wurden diese Ergebnisse unter welchen Umständen erreicht? Links bitte.

[daflow]

Die Ursrungszahlen stammen von hier : http://www.digit-life.com/articles2/radeon/r9500-9700.html

[Demirug]

Danke PeTa, irgendwie mag es digit life wohl nicht wenn man von extern verlinkt.

[Demirug]

Originally posted by Unregistered
@Demi
Wäre es dir möglich noch Werte zur Radeon8500 hinzuzufügen?
Dann könnte man sich ein noch besseres Bild machen.

Das macht nicht viel sinn den bei der R8500 läuft dieser Test über die Fixed T&L Einheit.

[Dunkeltier]

Also Demirug, du kannst wegen eines Benchmarks nicht auf die gesamte Performance der Radeon 9700 Pro schließen. Das ist schon mal das erste was ich anmerken wollte. Zweitens, dann dürfte die Geforce 4 Ti im Gegensatz zum Vörgänger auch um xx% ineffektiver gewesen sein, ein bißchen Verschnitt gibts immer. Und viertens, geht mir das ewige Gestänkere gegen Ati auf die Nerven. Fünftens, werden momentan die Vertex Shader en másse gebraucht? Nein, man befindet sich immer noch gerade in der sehr zögerlichen Umstellungsphase von DX7 zu DX9 (bzw. OpenGL 1.2 (oder war es nicht 1.3?) zu 2.0). Bis man richtig davon gebraucht macht, gehen Jahre ins Land und bis dahin ist der R300 und der NV30 schon wieder total veraltet.

[Demirug]

Dunkeltier,

ich stänkere doch gar nicht gegen ATI. Wenn ich das tun würde hätte der post ganz anders ausgesehen.

"Also Demirug, du kannst wegen eines Benchmarks nicht auf die gesamte Performance der Radeon 9700 Pro schließen. Das ist schon mal das erste was ich anmerken wollte."

Ich schliesse nicht auf die gesamt Performancens sondern ich frage mich warum in diesem recht einfachen Test die 4 VS Einheiten des R300 eine relativ schlechte Performancens an den Tag legen. Ich will nicht ausschliessen das die Limitierung an einer anderen Stelle liegt und wenn du eine gute Idee hast immer her damit.

"Zweitens, dann dürfte die Geforce 4 Ti im Gegensatz zum Vörgänger auch um xx% ineffektiver gewesen sein, ein bißchen Verschnitt gibts immer."

Der NV20 und NV25 ist in diesem Test leider nicht vergleichbar genauso wie man den R200 und R300 nicht vergleichen kann da dieser Test auf den beiden vorgängermodelen hardwaretechnisch anders realisiert ist.

"Fünftens, werden momentan die Vertex Shader en másse gebraucht? Nein, man befindet sich immer noch gerade in der sehr zögerlichen Umstellungsphase von DX7 zu DX9 (bzw. OpenGL 1.2 (oder war es nicht 1.3?) zu 2.0). Bis man richtig davon gebraucht macht, gehen Jahre ins Land und bis dahin ist der R300 und der NV30 schon wieder total veraltet."

Die neuen DX9 Features (Displacment mapping, Adaptive N-Patches (besseres Truform)) benötigten massiv mehr Vertexpower. Ja ich weis DX9 ist noch nicht releast und es wird lange dauern bis es spiele mit DX9 Features gibt. Aber wenn man sich anschaut auf welchen Karten zum Beispiel UT2K3 noch laufen muss weil es der markt verlangt kann man sich durchaus denken das auch noch die R300 Chips einfluss auf die DX9 spiele haben werden. Und der unterste Level bei der Entwicklung hat auch einen gewiessen einfluss auf den höchsten Level.

[Dunkeltier]

Mit der Umstellungsphase meinte ich von DX7 zu DX8, nicht DX9.

[Unregistered]

Originally posted by Demirug


Das macht nicht viel sinn den bei der R8500 läuft dieser Test über die Fixed T&L Einheit.

Wieso denn das? Das ist doch ein VS-Test aus dem DXSDK?
Der sollte doch auf allen HW-VS-fähigen Karten mit dem HW-VS laufen oder nicht?

[Unregistered]

Originally posted by Dunkeltier
Bis man richtig davon gebraucht macht, gehen Jahre ins Land und bis dahin ist der R300 und der NV30 schon wieder total veraltet.

Was aber nichts an der schlechten VS-Leistung der R300 ändert.

[Demirug]

Originally posted by Unregistered


Wieso denn das? Das ist doch ein VS-Test aus dem DXSDK?
Der sollte doch auf allen HW-VS-fähigen Karten mit dem HW-VS laufen oder nicht?

Es ist ein Vertexprocessing test. Primär wird also die Fixed T&L benutzt und bei Chips die keine fixed T&L Einheit mehr haben muss halt der Vertexshader ran. Bei einem effektivitätsvergleich Fixed T&L gegen Vertex shader verliert in der Regel immer der Vertexshader.

[Unregistered]

Vielleicht ist dann ATi einfach die (Treiber?-)Umsetzung der fixed-T&L Funktionen auf die VS des R9700 noch nicht sonderlich gelungen?

[Demirug]

Originally posted by Unregistered


Was aber nichts an der schlechten VS-Leistung der R300 ändert.

Das würde ich gerne mit Rücksicht auf unsere ATI-Freunde vorerst etwas einschränken.

Die effektive Vertexleistung bei diesem Test ist schlecht.

[Unregistered]

Gibt´s da noch andere Tests, die das bestätigen und/oder auch Vergleichzahlen der Parhelia?

[Demirug]

"Vielleicht ist dann ATi einfach die (TreiberUmsetzung der fixed-T&L Funktionen auf die VS des R9700 noch nicht sonderlich gelungen?"

möglich aber das wäre doch sehr ungewöhlich da die umsetzung der Fixed T&L Funktionen in VS Programme schon seit GF3 Zeiten bekannt ist.

"Gibt´s da noch andere Tests, die das bestätigen und/oder auch Vergleichzahlen der Parhelia?"

Es gibt da noch ein paar Tests:

1.Direct X 8.1 Vertex Shader:

Normalisiert:

TI 4200 = 464 FPS
TI 4600 = 456 FPS
R9500 = 244 FPS
R9700 = 284 FPS
R9700Pro = 290 FPS

Das Problem hier ist der recht grosse unterschied zwischen der 9500 und 9700. Das Programm ist zu stark von der fillrate abhängig um als verlässlich im bezug auf die reinen VS Leistung zu gelten.

2. 3dmark high poly count 1 light bei 1024*768

Normalisiert:

TI 4200 = 10,18 MPol/s
TI 4600 = 9,67 MPol/s
R9500 = 4,86 MPol/s
R9700 = 5,56 MPol/s
R9700Pro = 5,46 MPol/s

Die unterschiede sind zu gross um die Vertexshader als limitierend zu sehen

3. 3dmark high poly count 8 light bei 1024*768

Normalisiert:

TI 4200 = 2,08 MPol/s
TI 4600 = 2,08 MPol/s
R9500 = 1,02 MPol/s
R9700 = 1,16 MPol/s
R9700Pro = 1,15 MPol/s

Auch hier ist der unterschied zwischen der 9500 und 9700 zu gross um das vertexprocessing als limiterend anzusehen

4. 3dmark Vertexshader bei 1024*768

Normalisiert:

TI 4200 = 16,42
TI 4600 = 16,60
R9500 = 12,86
R9700 = 15,34
R9700Pro = 14,49

Hier sieht der R300 viel besser aus (9700 ca 93% des NV25) auch wenn die Zahlen der R300 Chips IMO zu stark schwanken um sicher zu sein was da wirklich limiert.

Resüme: Bei allen Tests die über die DX7 T&L Pipeline laufen ist die R300 Serie nicht in der Lage seine 4 Vertex Shader mit der gleichen effektivität wie die NV25 VS laufen zu lassen. Ein möglicher grund könnte eine bereist angesprochene Treiberschwäche sein. Da die meistens dieser Tests vom vertexprocessing sehr einfach sind wäre eine limitierung im Trisetup denkbar. Da aber auch der aufwendige 8 Light test das gleiche bild zeigt dürfte dort nicht die Ursache zu suchen sein. Bei "echten" DX8 Shader sieht das bild schon etwas besser aus leider zeigen die beiden Tests dafür ein recht unterschiedliches bild. Beim 3d mark haben wir eine recht hohe Effektivität im vergleich zum NV25 aber auch resultate die in frage stellen ob dort wirklich nur die VS Leistung gemessen wird. Auch der DX Test läst ehrhebliche Zweifel an seiner Brauchbarkeit als VS-Test aufkommen.

Vergleiche mit Parhelia, 8500, GF3 mache ich gerne auch noch aber das muss etwas warten.

[aths]

Dem Käufer kommt es ja auf die Gesamt-Leistung pro € und nicht auf die auf einen VS normalisierte Leistung an. Hauptsache, der VertexShader wird nicht zu einer limitierenden Größe.

Demirug, ich hörte mal irgendwo, dass 1 NV20-VS gleichzeitig 3 Befehle abarbeiten können soll. Ist das Unsinn, kannst du das bestätigen oder - noch besser - konkreteres dazu sagen?

[Demirug]

Originally posted by aths
Dem Käufer kommt es ja auf die Gesamt-Leistung pro € und nicht auf die auf einen VS normalisierte Leistung an. Hauptsache, der VertexShader wird nicht zu einer limitierenden Größe.

Natürlich aths, die ganze läuft auf die fragen hinaus.

Ist mit 4 VS einheiten nicht mehr zu machen? braucht mal also für noch mehr Verticens noch mehr VS?

Ist es ein Treiberproblem und dürfen wir noch eine steigerung der Leistung erwarten?

War es eine Designentscheidung (wegen Transitorenlimit) welche in Zukünftiger Hardware mit 4 VS mehr Leistung erwarten läst?

Demirug, ich hörte mal irgendwo, dass 1 NV20-VS gleichzeitig 3 Befehle abarbeiten können soll. Ist das Unsinn, kannst du das bestätigen oder - noch besser - konkreteres dazu sagen?

Ja das Thema hatten wir schon mal. Es ging allerdings um den NV25. Laut einer Aussage von David Krik wurden die VS des NV25 so verändert das sie jetzt jeden Befehl von aussen betrachtet in einem Takt ausführen können. Damit dies möglich ist war es notwendig die Vertexshader zu Pipelinen. Um eine solche Pipeline dann auch wirklich richtig zu nutzen ist es erforderlich mehr als eine Vertices gleichzeitig durchzuschieben. Laut Kirk werden in den VS des NV25 immer 3 Verticens gleichzeitig bearbeitet. Also muss die Pipeline mindestens 3 Stages haben. Jede VS-Op muss also von Treiber in eine oder mehrer VS-microop zerlegt werden.

Technisch ist das sehr einfach zu machen. Allerdings erhöht man damit den transitor count nicht unwesentlich.

[Salvee]

Vielleicht wären ja auch Vergleichwerte einer Radeon 9000 ganz interessant, die meines Wissens nur 1 VS und keine festverdrahtete T&L Unit mehr besitzt.
Man könnte daraus ja ersehen, wieviel ein einzelner ATi-VS zu leisten imstande ist, und eventuell Rückschlüsse auf 4 VS ziehen
(auch wenn es mit Sicherheit Unterschiede zwischen den VS der 9000 und 9700 gibt).
Nur so eine Idee halt :)...

[Razor]

@Demirug

Darf ich mal fragen, mit welchem Treiber die NV25-Benches gemacht wurden ?
Würde mich nicht wundern, wenn dabei die 30.xx zum Einsatz gekommen wären...

Mit den 40.xx könnte das Ganze dann schon ganz anders aussehen !
:D

Bis denne

Razor

P.S.: vermutlich weißt Du, worauf ich hinaus will...

[Demirug]

@Razor: Es war 40.72 deine Theorie geht hier also nicht auf.

@Salvee:

Rohdaten: http://www.digit-life.com/articles/r9000pro/index.html

Radeon 9000 Pro

Optimize: 7,5 MPol/s
Unoptimized: 3,3 MPol/s
Strip: 7,4 MPol/s

DX 8.1 VertexShader: 567,3 FPS
3d mark 1 Light: 7,96 MPol/s
3d mark 8 Light: 1,85 MPol/s
3d mark Vertexshader: 23,42

[HOT]

Hmmm... das ist aber erst seit den neuesten Treibernversionen so...

http://www.de.tomshardware.com/graphic/02q3/020819/radeon9700-15.html

Anscheinend hat man in den neueren Versionen wiedermal Mist gemaht bei ATI. Mal auf die ersten DX9 Treiberversionen warten.

[zeckensack]

Originally posted by HOT
Hmmm... das ist aber erst seit den neuesten Treibernversionen so...

http://www.de.tomshardware.com/graphic/02q3/020819/radeon9700-15.html

Anscheinend hat man in den neueren Versionen wiedermal Mist gemaht bei ATI. Mal auf die ersten DX9 Treiberversionen warten. Bei der doppelten Anzahl VS und höherem Takt sollten die Ergebnisse aber noch drastischer für die 9700Pro ausgehen.

Genau das hat Demirug bemängelt und durch die Normalisierung gezeigt.

[in04]

Originally posted by Demirug
Rohdaten: http://www.digit-life.com/articles/r9000pro/index.html

Radeon 9000 Pro

Optimize: 7,5 MPol/s
Unoptimized: 3,3 MPol/s
Strip: 7,4 MPol/s

DX 8.1 VertexShader: 567,3 FPS
3d mark 1 Light: 7,96 MPol/s
3d mark 8 Light: 1,85 MPol/s
3d mark Vertexshader: 23,42
Demnach ist ATI also in der Lage einen "schnellen" DirectX 7 Vertexshader zu schreiben. Was allerdings offen bleibt warum die R9700 schlechtere Werte hat als die R9000 und die NV25? Mir fallen da ein paar Möglichkeiten ein:

1. R9700 ist für DirectX 9 (!) optimiert
2. VertexShader der Version 2.0 können Loops etc. sind demnach Hardwaremäßig anders als die alten VS 1.1 Versionen (langsamer?)
3. VS 2.0 unterstütz FloatingPoint, demnach muß eine Umsetzung von VS 1.1 nach VS 2.0 im Treiber erfolgen (glaube nicht, das die VS 1.1 Funktionen parallel implementiert sind)
4. Treiber sind nicht so optimiert wie die der NV25
5. u.U. können die 4 VS der R9700 bei diesem Test nicht genutzt werden?

Aber intressant ist das ganze schon, schauen wir mal wenn der NV30 kommt obs der besser kann. Dann hätte ATI wohl gespart falls der auch langsamer ist als NV25 (normalisiert) liegts wohl an Direct X 9.

Gruß

[Demirug]

Originally posted by in04

Demnach ist ATI also in der Lage einen "schnellen" DirectX 7 Vertexshader zu schreiben. Was allerdings offen bleibt warum die R9700 schlechtere Werte hat als die R9000 und die NV25? Mir fallen da ein paar Möglichkeiten ein:

1. R9700 ist für DirectX 9 (!) optimiert

DX9 stellt ja lediglich eine erweiterung von DX8 da deshalb sollte das eigentlich kein problem darstellen. Und wenn das wirklich der grund sein sollte hat sich IMO ATI ein bischen verkalkuliert den in der Mehrzahl werden die R300 Chips wohl als rechenknechte für DX8 spiele dienen.

2. VertexShader der Version 2.0 können Loops etc. sind demnach Hardwaremäßig anders als die alten VS 1.1 Versionen (langsamer?)

Die VS 2.0 stellen zusätzliche Befehle zur Verfügung die natürlich eine Änderung der Hardware erfordern. Der speed sollte das aber nicht alzu abträglich sein.

3. VS 2.0 unterstütz FloatingPoint, demnach muß eine Umsetzung von VS 1.1 nach VS 2.0 im Treiber erfolgen (glaube nicht, das die VS 1.1 Funktionen parallel implementiert sind)

Die Vertexshader unterstützen schon immer FloatingPoint.

4. Treiber sind nicht so optimiert wie die der NV25

Ja das ist immer eine möglichkeit.

5. u.U. können die 4 VS der R9700 bei diesem Test nicht genutzt werden?

Die meisten der Tests könnten die 4 VS wirklich nicht genügend fordern. Aber beim Light 8 Test aus dem 3d mark sollten die 4 VS aufgrund der komplexität der Berechnung auf keinen Fall unterfordert werden.

Aber intressant ist das ganze schon, schauen wir mal wenn der NV30 kommt obs der besser kann. Dann hätte ATI wohl gespart falls der auch langsamer ist als NV25 (normalisiert) liegts wohl an Direct X 9.

Gruß

Ja sobald es NV30 Zahlen gibt kann man vergleiche anstellen.

[Salvee]

Für die Applikation, die die VS benutzt, ist die Anzahl der VS aber immer transparent, oder muss so eine Art 'Multithreading' direkt im Shader-Programm vorhanden sein (sprich, es werden max. 2 VS heutzutage angesprochen, da das bisherige Topmodell nur 2 VS hatte oder DX8 nur mit 2 VS klarkommt oder ähnliches) ?

[zeckensack]

Originally posted by Salvee
Für die Applikation, die die VS benutzt, ist die Anzahl der VS aber immer transparent, oder muss so eine Art 'Multithreading' direkt im Shader-Programm vorhanden sein (sprich, es werden max. 2 VS heutzutage angesprochen, da das bisherige Topmodell nur 2 VS hatte oder DX8 nur mit 2 VS klarkommt oder ähnliches) ? Die Applikation weiß nicht wieviele VS-Einheiten vorhanden sind.
Also wie du sagtest, transparent :)

[Exxtreme]

Hmmm, es gibt anscheinend ein Problem mit irgendwelchen Vertex-Buffern in den Treibern wenn eine D3D-App ausgeführt wird. Das führt dazu, daß einige Spiele zu Stuttering neigen. Thomas von www.tommti-systems.de hat eine Lösung dafür gefunden und hat diese in sein 3DA eingebaut. Und sireric (ATi-Mitarbeiter) im R3D-Forum meinte, daß sich Treiber-Programmierer jetzt um dieses Problem kümmern. Wenn das Problem nicht mehr besteht, dann wird man wohl eine neue Messung durchführen müssen.

[in04]

Originally posted by Demirug


DX9 stellt ja lediglich eine erweiterung von DX8 da deshalb sollte das eigentlich kein problem darstellen. Und wenn das wirklich der grund sein sollte hat sich IMO ATI ein bischen verkalkuliert den in der Mehrzahl werden die R300 Chips wohl als rechenknechte für DX8 spiele dienen.

Erweiterung? Jein, immerhin haben wir jetz vollständig FP auch bei den Pixeln.

Originally posted by Demirug

Die Vertexshader unterstützen schon immer FloatingPoint.


Sorry ja klar, aber ich dachte an solch Neuigkeiten wie 16 Bit FP, oder das 10 Bit Format (ich denke du kennst die entsprechenden Abschnitte der DirectX 9 Specs)

Originally posted by Demirug

Die meisten der Tests könnten die 4 VS wirklich nicht genügend fordern. Aber beim Light 8 Test aus dem 3d mark sollten die 4 VS aufgrund der komplexität der Berechnung auf keinen Fall unterfordert werden.



Ups, ich dachte wir reden vom DirectX 8.1 Test? Beim BenMark 5 (der ist von NVIDIA siehe http://www.de.tomshardware.com/graphic/02q3/020819/radeon9700-15.html) ist die Leistung der R9700 ja dreimal so groß wie die der NV25. Daraus zieht Tom folgenden Schluss:
"In diesem Test erreicht die Radeon rund 3x so hohe Werte wie das NVIDIA-Board - trotz "nur" doppelt so vieler Vertex-Shader-Einheiten. Daraus kann man schließen, dass die Effektivität der einzelnen Einheiten bei der Radeon 9700 PRO trotz praktisch gleichem Chiptakt deutlich höher angesiedelt ist als bei der GeForce4."

Beim Matrox SharkMark (http://www.de.tomshardware.com/graphic/02q3/020819/radeon9700-18.html) ist die Welt auch in Ordnung (doppelte Leistung der R9700 gegen TI4600)

Beim 3dMark mit 8 Lichtern geb ich dir Recht war ich auch überrascht, das die Werte der R9700 nicht wirklich besser sind als bei der R8500. Aber wer weiss woran das wirklich hängt?

Gruß

[Exxtreme]

Originally posted by in04

Beim 3dMark mit 8 Lichtern geb ich dir Recht war ich auch überrascht, das die Werte der R9700 nicht wirklich besser sind als bei der R8500. Aber wer weiss woran das wirklich hängt?

Gruß
Hmm, ich könnte mir vorstellen, daß ATi diese Berechnungen vielleicht gar nicht richtig optimiert hat. Eine GF4Ti4600 schlägt man alle mal aber es werden wohl keine Spiele erscheinen, die Vertex Lighting nutzen.

[Quasar]

Siehst du, Exxtreme, genau das ist der Grund, weshalb manch einer sagt, die Treiber von ATi seien denen von nV meist unterlegen: Es wird hin- und heroptimiert, gerade so, wie es momentan nötig ist. Aber wenn dann mal ein Programm erscheint, welches vorbei am normalen Mainstream-Trend arbeitet, kriegt man mit den Treibern Performance- oder visuelle Problemchen, die dann in einem HotFix oder der nächsten bzw. übernächsten Treiberrevision gefixt werden müssen. Warum kann ATi nicht ein stabiles, performantes Grundgerüst bereitstellen, welches optimiert nach den DX/OGL-Specs arbeitet und wenn dann mal ein Programmierer wirklich Mist baut mit seiner App, kann man immer noch ein Patch bringen, oder eindeutig der App die Schuld zuweisen?

[Demirug]

Originally posted by in04

Sorry ja klar, aber ich dachte an solch Neuigkeiten wie 16 Bit FP, oder das 10 Bit Format (ich denke du kennst die entsprechenden Abschnitte der DirectX 9 Specs)

Die neuen Formate sind nur für die Pixelshader.

Ups, ich dachte wir reden vom DirectX 8.1 Test? Beim BenMark 5 (der ist von NVIDIA siehe http://www.de.tomshardware.com/graphic/02q3/020819/radeon9700-15.html) ist die Leistung der R9700 ja dreimal so groß wie die der NV25. Daraus zieht Tom folgenden Schluss:
"In diesem Test erreicht die Radeon rund 3x so hohe Werte wie das NVIDIA-Board - trotz "nur" doppelt so vieler Vertex-Shader-Einheiten. Daraus kann man schließen, dass die Effektivität der einzelnen Einheiten bei der Radeon 9700 PRO trotz praktisch gleichem Chiptakt deutlich höher angesiedelt ist als bei der GeForce4."


Wir reden primär von allem was mit Vertexprocessing zu tun hat. Wobei sich der Verdacht erhärtet das die Performancen "probleme" sich ganz extrem bei der verwendung von Fixed T&L zeigen. Was den BenMark angeht so kann da irgendwas nicht so ganz stimmen die FPS steigt dramatisch an aber der Traffic im verhältniss dazu nur minimal.

Beim Matrox SharkMark (http://www.de.tomshardware.com/graphic/02q3/020819/radeon9700-18.html) ist die Welt auch in Ordnung (doppelte Leistung der R9700 gegen TI4600)

Ja beim SharkMark sieht die sache aus wie man es erwarten sollte. Die Frage ist allerdings was limitiert beim Sharkmark?

Beim 3dMark mit 8 Lichtern geb ich dir Recht war ich auch überrascht, das die Werte der R9700 nicht wirklich besser sind als bei der R8500. Aber wer weiss woran das wirklich hängt?

Gruß

Wie gesagt möglicherweise eine schlechte unterstützung der Fixed T&L Pipe im Treiber.

[in04]

Originally posted by Demirug

Die neuen Formate sind nur für die Pixelshader.


Danke, da hab ich mal wieder was dazu gelernt.

Originally posted by Demirug

Wir reden primär von allem was mit Vertexprocessing zu tun hat. Wobei sich der Verdacht erhärtet das die Performancen "probleme" sich ganz extrem bei der verwendung von Fixed T&L zeigen. Was den BenMark angeht so kann da irgendwas nicht so ganz stimmen die FPS steigt dramatisch an aber der Traffic im verhältniss dazu nur minimal.

Kannst du mal den BenMark laufen lassen und alle vier Werte posten? Da der Source ja auch dabei ist kann man schnell sehen ob da irgend ein Rechen Fehler oder so auftritt.
BenMark5 findest du hier: http://www.nvidia.co.uk/view.asp?IO=BenMark5

Originally posted by Demirug
Ja beim SharkMark sieht die sache aus wie man es erwarten sollte. Die Frage ist allerdings was limitiert beim Sharkmark?

Gibt es den SharkMark irgendwo zum download? Hab ihn nirgends gefunden (gesucht mit Copernic).

Originally posted by Demirug
Wie gesagt möglicherweise eine schlechte unterstützung der Fixed T&L Pipe im Treiber.
Irgendwie intressiert mich das Thema jetzt mehr und mehr....

Gruß

[Demirug]

in04,

ich habe die Karten nicht also ist da nix mit laufen lassen. Ich kann allerdings noch mal gerne einen Blick auf den Quellcode werfen ob man dort einen Rechen-Fehler erkennen kann

Wo man den SharkMark herbekommt kann ich auch nicht sagen.

[in04]

Ok,
dann muss ich heute Nachmittag zuhause mal ran!
Also in ein paar Stunden lass ich den BenMark laufen und schau mal im Debugger ob da irgendwas komisch berechnet wird.

Hast du zufällig ne Geforce 4? Dann poste doch mal die vier Werte, auch die normalisierten.

Gruß

[Demirug]

Habe keine GF4 zum benchen zur Verfügung.

Was den Benmark angeht so muss sich der Speicherdurchsatz linear zur Framerate bewegen. Es könnte allerdings sind das es da ganz einfach zu einem überlauf kommt. Das Programm war halt für GF1 und GF2 gedacht. In wie fern es als Geometrietest für neue Karten noch zu gebrauchen ist müsste ich noch prüfen.

[in04]

Hab eben meine R9700 Pro getestet und bekomme:
112 MTri/s
112 MVert/s
224 Index/s
1300 effective
Da aber laut Source Code die Effektive Bandbreite 32 * MVert ist müßte 3584 rauskommen.

Ich hab mal die FPS auf 85 limitiert (geht ja mit den neuen Treibern) und der Wert ging runter auf 56 MTri/s dazu passend 1700 bei der Bandbreite.
Demnach sieht es so aus als sind die ersten drei Werte OK und die Bandbreitenberechnung geht schief. Nach Blick auf die Source vermute ich dass einer der drei zur Berechnung verwendeten Werte ein DWORD ist und die Multiplikation der drei Werte im DWORD Werte Bereich überläuft.
Also sieht es für die Vertexshader nur unter MS SDK 8.1 und 3d Mark schlecht aus.

PS: Ich hab nur ein AMD 1800+ deshalb komm ich nicht auf Toms Werte :-(

Gruß

[Achill]

wenn es sich wirklich um ein fehler handelt, um wieviel würde es denn die ergebnisse verfälschen?

[in04]

Originally posted by Achill
wenn es sich wirklich um ein fehler handelt, um wieviel würde es denn die ergebnisse verfälschen?
Das Ergebnis der effektiven Vetex Bandbreite ist u.U. völlig für den Müll.
Da aber der Wert 32*Vert/Sekunde ist kann man den richtigen einfach selbst ausrechnen.

Gruß

[ow]

Also für ein Gf2MX kommt das raus:

19,4 MTri/s
19,4 MVert/s
38,8MB Index/s
620MB/s effectiv

Passt genau auf die Formel.:)

[Quasar]

Originally posted by in04
Also sieht es für die Vertexshader nur unter MS SDK 8.1 und 3d Mark schlecht aus.

Wie meinst du das? Stimmen deiner Ansicht nach die Ergebnisse oder nicht, denn der BenMark5 berechnet ja nur den Traffic falsch, die Tri/s stimmen offenbar.

[in04]

Originally posted by Quasar


Wie meinst du das? Stimmen deiner Ansicht nach die Ergebnisse oder nicht, denn der BenMark5 berechnet ja nur den Traffic falsch, die Tri/s stimmen offenbar.

Ich denke mal das die Ergebnisse des MS 8.1 SDK's und von 3dMark korrekt sind. Warum aber der R300 hier seine doppelt so hohe Vertex Leistung nicht zeigt, weiß ich auch nicht. Da kann man wohl nur spekulieren? Werd mir auf jedem Fall mal im MS SDK das Program ansehen ob man einen Grund für die Vertex Leistung findet.

Gruß

[AlfredENeumann]

Frage: Wie aussagekräftig ist den der Vertexshader-Test in 3D-Mark ?

http://www.ixbt.com/video2/images/r9500/3dm-vertex.png

[Iceman346]

Originally posted by AlfredENeumann
Frage: Wie aussagekräftig ist den der Vertexshader-Test in 3D-Mark ?

http://www.ixbt.com/video2/images/r9500/3dm-vertex.png

Die 9500 ist doch afaik nicht in den Vertexshadern beschnitten. Also warum hat sie dann nicht die gleichen Werte wie die 9700 Pro?
IMO weil der Test nicht wirklich an die Grenzen des Vertex Shaders kommt sondern an die Fillrategrenze (bei 1600 imo sehr deutlich. Die 9500 bei gleicher Taktrate halb so schnell wie ne 9700 Pro). Vielleicht hätte man mal auf 640x480 oder so testen sollen und vielleicht irr ich mich auch ganz ;)

[ow]

@Iceman

Nein, das siehst du schon richtig. Der VS Test des 3DMark zeigt eine komplett gerenderte Szene inkl. Texturen wenn ich nicht irre.

Um die VS-Leistung zu ermitten müsste man aber mit Punkt-, Linien- oder untexturierten Polygonen arbeiten. Dann kann die Pixelberechnung nicht limitieren.

[Iceman346]

Originally posted by ow
@Iceman

Nein, das siehst du schon richtig. Der VS Test des 3DMark zeigt eine komplett gerenderte Szene inkl. Texturen wenn ich nicht irre.

Jepp, die Szene zeigt ca 30-40 rumlaufende "Max Paynes"

[zeckensack]

Originally posted by AlfredENeumann
Frage: Wie aussagekräftig ist den der Vertexshader-Test in 3D-Mark ?

http://www.ixbt.com/video2/images/r9500/3dm-vertex.png IMO ist der Vertex Shader Test im 3DM2k1 komplett wertlos - zumindest sollte man daran nicht die VS-Leistung ablesen wollen.

Für sowas nimmt man besser Nature ... oder gleich was ganz anderes :D

[Achill]

@zecki ... könntest du nicht schnell solch ein programm schreiben? Ich hoffe der aufwand wäre nicht zu groß...

[ow]

Geht unter OGL (das proggt zecki) nicht, da es derzeit keinen einheitlichen Standard für VS gibt sondern nur herstellerspezifische Extensions.

[zeckensack]

Wenn ich recht drüber nachdenke ... auch mitm 3DMark kann man halbwegs sinnvoll VS messen. Das Problem beim VS-Test und auch beim Nature ist der hohe Verbrauch an Füllrate (heftiger Overdraw in beiden Tests), Bandbreite (aktives Blending im VS-Test, Texturen) und PS-Takten (va Nature's Wasseroberfläche).

Vorübergehende Lösung wären Messungen in 640x480x16. Dann verbleibt leider das Problem, daß beide Tests nur fps ausspucken und keinen Vertex-Durchsatz. Immerhin kann man trotzdem noch brauchbare qualitative Vergleiche unterschiedlicher Architekturen fahren.

Und von wg OGL-VS-Tests, ich kann durchaus was bauen was zumindest auf ATI und NV-Chips laufen sollte, nur leider fehlt mir momentan für solche Sachen komplett die Zeit.

[Demirug]

*psst*

wartet einfach noch ein bischen im DX9 SDK ist ein sehr schönes Programm mit dem man die gleichen Effekte einmal mit der fixed T&L und einmal mit VS rechnen lassen kann. man kann damit auch die komplexität der shader leicht verändern.

[zeckensack]

Oder einfach Rendermonkey und Cg benutzen :D