Hier is Schmuh am Werk...

[MadManniMan]

da ich mir n neuen prozzi besorgen will, hab ich nochmal mit meiner ti200 @215/472 und meinem duri 700 aufm abit kt7a den 3dm2k1 getestet. soll heißen, einmal auf standarttakt, dann mit anderen timings oder ram-geschwindigkeiten... aber darum solls nicht gehen.

wesentlich interessanter mutet der interessante leistungsgewinn von 700(7*100) auf 933(7*133) mhz an, aber seht selbst:


btw: unterschiede bei ram und timings gabs nicht, ansonsten lagen die schwankungen dort bei bis zu 20%. hier nun greift dennoch die cpu - mit sage und schreibe mehr als 70%!

[Horus]

hmm da stimmt irgendwas nicht
da wird der natur benchmark ja fast schneller als die andren :)

[MadManniMan]

keiner mehr, den das alles wundert? der es erklären könnt?

[Quasar]

Frag' mal Razor, der hat da so eine Theorie dazu....

Insgesamt würd' ich aber eher mal nach einem Fehler im 3DMark suchen. Der scheint mit übertakteten Systemen so seine Problemchen zu haben...

[MadManniMan]

danke, riesiger klumpen von schwarzen löchern!

werd onkel razor mal frag0rn. aber die 70 fps mehr sind real, der counter spuckts aus und ich empfinde sie... seltsam :|

/edit: soll natürlich "70 % mehr fps" heißen :D

[Quasar]

Bei 100MHz FSB hat's afaik noch keiner probiert, kann sein, dass es da nicht aktiv ist, aber Razor und ich spekulieren schon seit einiger Zeit von einem Load-Balancing im Vertex-Shader speziell der GeForce3, deswegen auch die extremen Unterschiede, die sich bei ihm mit unterschiedlichen Treiberrevisionen im VS-Test und teils auch im Nature-Bench ergeben haben.
Gut möglich, dass das erst mit 133MHZ-FSB CPUs aktiviert wird...

Auch wenn der Leistungsgewinn etwas viel klingt, aber allein, dass in den internen Caches mehr Platz ist, kann bei solchen Dingen schon viel ausmachen, IMO.

[MadManniMan]

Originally posted by Quasar

Quasar



huppala, da wars doch nur eins und nich viele... aber is doch relativ, da viele = ein großes :D

[MadManniMan]

load-balancing... hm. ich verstehe grob, was gemeint is, sehe aber noch keinen zusammenhang zwischen fsb und caches

[Quasar]

Naja, ist alles reine Spekulation (und ich muss auch gleich in die Heia....):

Stichwort Load-Balancing
Gibt's schon 'ne Weile auf High-End Profi-Karten, die Teile, insbesondere der Geometrie-Berechnung bei Bedarf auf die CPU auslagern können. Sinnvoll kann das sein, wenn der Treiber "erkennt", dass nicht die Geometrie das begrenzende Element in einer gegebenen Applikation darstellt.
Auch wenn die Geometrie auf einer vorhandenen CPU nichtmal schneller berechnet werden könnte, als auf der GPU, kann es, durch den sinkenden Verkehr auf den internen Bussen, sowie möglicherweise Einsparungen bei den Latenzen beim Schreiben/Lesen ins Graka-RAM, trotzdem am Ende schneller sein, wenn dadurch die (begrenzende) Pixelpipeline schneller arbeiten kann.

Sehr hilfreich FÜR diese These wäre natürlich, wenn nV die internen Caches für Primitive, Vertex-Daten, Texturen und "Pixel" nicht wirklich aufgeteilt, sondern dynamisch in einem Pool zusammengefasst hat. Dann würde der Platz für den Pixelshader deutlich anwachsen und er könnte effektiver arbeiten.

Es gab da mal jemanden, der wollt entdeckt haben, dass einige Chips von nV (ich weiss jetzt nicht genau, um welche es sich handelte, AFAIR ging's aber hauptsächlich um TNT-GF2 Chips) einen einzigen internen Cache von gigantischen Ausmassen (AFAIR sprach er von der Größenordnung von 1 MB) hätten. Dies wollte er durch ein eigenes Messprogramm nachgewiesen haben, nach dem die Chips irgendwelche Funktionen deutlich schneller ausführten, als sie es eigentlich dürften. Leider hab ich den Link zu dieser Spekulation (!!!) nicht mehr...

Neu an "deinem" Ergebnis ist, zumindest für mich, dass dieser Synergie-Effekt zumindest auf deinem unübertakteten System nicht aufzutreten scheint (oder extrem unnütz ist). Daher meine Vermutung, dass der Treiber eventuell eine Erkennung integriert hat, die diese Optimierung nur bei 133MHz-CPUs anspringen lässt, in der kurzsichtigen Annahme, diese würden automatisch über höhere Leistung verfügen (oder in der weitsichtigen Annahme, dass bei 100MHz FSB der Systembus eh schon viel zu vollgestopft ist...)

Wie gesagt, alles nur AFAIK, AFAIR, IMO und IIRC, ohne Gewähr!

edit:
Und jetzt entscheide, ob das für dich wahrscheinlicher klingt, als ein Bug im 3DMark *eg*

[StefanV]

@Quasar

Gibt noch 'ne andere Möglichkeit:

Das Load Balancing springt erst ab einer gewissen Taktfrequenz an...

[MadManniMan]

bug im 3dmark hab ich eigentlich ausgeschlossen, da die frames ja kamen, daher gefällt mir diese theorie...

btw, was heißt eigentlich iirc?

[Quasar]

iirc = if i remember correctly :)

[MadManniMan]

pfui hört sich das doof an

[Razor]

Sach'e mal, Mannilein, was für einen Treiber(OS) hast Du dafür benutzt ?

Würd' mich mal sehr interessieren, allerdings ist die Steigerungen beim Nature... sagen wir mal... sehr ungewöhnlich.

Also hier noch mal das Gesamtwerk etwas lesbarer, sorry ;-)
(wenn ich's korrekt 'erkannt' hab')
CPU Speed 700 933 +33%
FSB 100 133 +33%
AGP 66 89 +33% ?

Game1 LD 68,3 84,9 +24%
Game1 HD 17,7 24,2 +37%

Game2 LD 84,4 92,9 +10%
Game2 HD 45,4 50,3 +11%

Game3 LD 72,4 86,5 +19%
Game3 HD 30,3 37,8 +25%

Game4 24,6 42,5 +73%
Tja, die Werte liegen eigentlich alle im Rahmen...
(Game 1&3 sind reichlich CPU-Limitiert)

Aber die Werte beim Nature-Murks sind eindeutig zu hoch !
Wie der AGP bei Dir getaktet wär auch noch ganz interessant.

Und by the way: das nächste mal bitte mit PNG komprimieren !
Das kann man ja nun überhaupt net lesen...
:D

Bis denne

Razor

[Razor]

So mal als Beispiel:
(besser wär natürlich das Orginal, größer wär's dadurch auch net ;-)

[Haarmann]

Das is ned neu Manni...

Das gabs schon im alten 2000er Zwiebelmark mit den Polygonen bei ner GF - plötzlich gabs so ein Sprung. Wenn den Multi ungelockt hättest, würdest so nen Spruch bei bereits einer Stufe, also 50 MHz CPU bemerken.

[Demirug]

Quasar: http://www.theinquirer.net/?article=5107 Also mit vorsicht geniessen.

Was nun das "Load Balancing" angeht.

1. NVIDIA verfügt über den code um Vertexshader Programme auf CPUs ausführen zu lassen. Dieser Code ist Teil der OpenGL Treiber.

2. Liegen die Vertexdaten im Grafikkartenspeicher müssten die Daten erst wieder über den AGP zurück zu CPU dort berechnet werden und dann wieder zu Grafikkarte zurück. Das Rücklesen von Daten von der Grafikkarte ist bei allen Treibern vor 40.xx sehr langsam und CPU lastig. Ergo wenn die Vertexdaten im Grafikram liegen dürfte dieser effekt frühstens mit > 40.xx Treibern zu erkennen sein.

3. Aufgrund einer Vertex und Indexliste läst sich ohne aufwendige Analyse nicht feststellen in welcher Komponete des Chips es zu limitierungen kommt. Also ist eine Entscheidung pro Primitive nicht möglich. Da der Grafikchip und die CPU auch noch versetzt arbeiten liesse sich also im besten Fall am Ende eines Frames festellen in wie weit es zu überlastungen einer Komponete gekommen ist. Aufgrund der Daten vom vorhergehenden Frame einzelne Primitives von der CPUs berechnen zu lassen halte ich für eine zu risikoreiche sache den in ungünstigen Fällen macht man die sache eher langsamer als schneller.

Das Nature nicht linear skaliert kann durchaus auch im Bench selbst begründet sein. Das Problem beim gesamten 3dMark ist das die Messzeit konstant ist aber die Datenmenge variert. Es kann aber nun niemand sagen in welchem verhältniss die zusätzlichen Frames (bei 933) zu den ursprünglichen (bei 700) stehen.

[MadManniMan]

Sach'e mal, Mannilein, was für einen Treiber(OS) hast Du dafür benutzt ?

>tach razorle: w98 mit 40.72

Würd' mich mal sehr interessieren, allerdings ist die Steigerungen beim Nature... sagen wir mal... sehr ungewöhnlich.

>rat mal, warum ich den thread aufgemacht hab :D

Also hier noch mal das Gesamtwerk etwas lesbarer, sorry ;-)
(wenn ich's korrekt 'erkannt' hab')
CPU Speed 700 933 +33%
FSB 100 133 +33%
AGP 66 89 +33% ?

Game1 LD 68,3 84,9 +24%
Game1 HD 17,7 24,2 +37%

Game2 LD 84,4 92,9 +10%
Game2 HD 45,4 50,3 +11%

Game3 LD 72,4 86,5 +19%
Game3 HD 30,3 37,8 +25%

Game4 24,6 42,5 +73%
Tja, die Werte liegen eigentlich alle im Rahmen...
(Game 1&3 sind reichlich CPU-Limitiert)

>...obwohl CC HD auch schon etwas hoch is

Aber die Werte beim Nature-Murks sind eindeutig zu hoch !
Wie der AGP bei Dir getaktet wär auch noch ganz interessant.

> isn Abit KT7A, dürfte also dennoch bei 66MHz liegen :)

Und by the way: das nächste mal bitte mit PNG komprimieren !
Das kann man ja nun überhaupt net lesen...
:D

> ma gucken. wenn sich denn der 3dmurks2k3 bei meinem 1,7er(?) XP aufregt, denk ich vielleicht dran... ;)

Bis denne

> a jo, bisch denn dann, wa? ich hasse württembergisch :D

[MadManniMan]

Originally posted by Haarmann
Das is ned neu Manni...

Das gabs schon im alten 2000er Zwiebelmark mit den Polygonen bei ner GF - plötzlich gabs so ein Sprung. Wenn den Multi ungelockt hättest, würdest so nen Spruch bei bereits einer Stufe, also 50 MHz CPU bemerken.

multi unlocken... tja, is lange her, außerdem hab ich zwar x bleistifte, aber null komma gar keinen anspitzer(proletenluxus!) im haus...

aber danke für die info, is interessant... *riecht verschwörung* :|

[MadManniMan]

Quasar: http://www.theinquirer.net/?article=5107 Also mit vorsicht geniessen."

hm... :|

"Was nun das "Load Balancing" angeht.

1. NVIDIA verfügt über den code um Vertexshader Programme auf CPUs ausführen zu lassen. Dieser Code ist Teil der OpenGL Treiber."

indiz nr. eins für quasars idee

"2. Liegen die Vertexdaten im Grafikkartenspeicher müssten die Daten erst wieder über den AGP zurück zu CPU dort berechnet werden und dann wieder zu Grafikkarte zurück. Das Rücklesen von Daten von der Grafikkarte ist bei allen Treibern vor 40.xx sehr langsam und CPU lastig. Ergo wenn die Vertexdaten im Grafikram liegen dürfte dieser effekt frühstens mit > 40.xx Treibern zu erkennen sein."

den 40.72er hab ich wie gesagt. bisher wars bei nature immer um die 23~24.

"3. Aufgrund einer Vertex und Indexliste läst sich ohne aufwendige Analyse nicht feststellen in welcher Komponete des Chips es zu limitierungen kommt. Also ist eine Entscheidung pro Primitive nicht möglich. Da der Grafikchip und die CPU auch noch versetzt arbeiten liesse sich also im besten Fall am Ende eines Frames festellen in wie weit es zu überlastungen einer Komponete gekommen ist. Aufgrund der Daten vom vorhergehenden Frame einzelne Primitives von der CPUs berechnen zu lassen halte ich für eine zu risikoreiche sache den in ungünstigen Fällen macht man die sache eher langsamer als schneller."

also "optmieren" die zwiebeln pauschal ab ner gewissen Hertz-zahl...

"Das Nature nicht linear skaliert kann durchaus auch im Bench selbst begründet sein. Das Problem beim gesamten 3dMark ist das die Messzeit konstant ist aber die Datenmenge variert. Es kann aber nun niemand sagen in welchem verhältniss die zusätzlichen Frames (bei 933) zu den ursprünglichen (bei 700) stehen."

murks(tm) war schon immer seltsam, aber heute is murks(tm) besonders fraglich

[Quasar]

Originally posted by Demirug
Quasar: http://www.theinquirer.net/?article=5107 Also mit vorsicht geniessen.

1. [...]2.[...]3.[...] ´

Das Nature nicht linear skaliert kann durchaus auch im Bench selbst begründet sein. Das Problem beim gesamten 3dMark ist das die Messzeit konstant ist aber die Datenmenge variert. Es kann aber nun niemand sagen in welchem verhältniss die zusätzlichen Frames (bei 933) zu den ursprünglichen (bei 700) stehen.

Danke für den Link, ist doch lustig, die Theorie, oder? ;)

Naja, was deine Argumente angeht, so sind die sicherlich stichhaltig, aber andererseits ist der Performance-Schub recht schwer zu erklären. CC HQ wäre noch innerhalb des CPU-Taktes plus des höheren FSBs erklärbar, imo. Aber 70% Zuwachs sind entweder ein Bug, oder was gaaanz komisches...

[aths]

Der Nature-Bench ist in der Tat ein Kapitel für sich - hier stelle ich mit der Taktrate ebenfalls überproportionalen Geschwindigkeitszuwachs fest. (Die genauen Zahlen müssten noch in einem anderen Thread stehen. (Und das wurde imo bei dem 3DMark-Titlescreen-Bug schon mal diskutiert?)