THG-Test DX10-Chips unter realen Spielen

[Henroldus]

hier der gesamte Artikel:
DirectX-10-Vergleich: Geforce 8x00 und Radeon 2x00 (http://www.tomshardware.com/de/DirectX-10-Vergleich-Geforce-Radeon,testberichte-239832.html)

die Idee ist ja gut aber dabei kommt wieder Schwachsinn raus:
http://media.bestofmicro.com/8/9/48249/original/15-chart_coh_1600_aa_af.png
die 8600GTS 5x so schneller als die 8800GTS 640MB :|

Auch hier merkwürdig, der enorme Abstand der GTX zur GTS:
http://media.bestofmicro.com/8/I/48258/original/24-chart_wic_test1_1600_aa_af.png

[Gast]

Ich würde nicht sagen dass die da scheiße gemessen haben, sondern eher das es da irgendein Problem gibt.

[CompuJoe]

THG halt, die Seite habe ich schon seit ewigkeiten nicht mehr besucht ^^

[Spasstiger]

Scheint wohl eine Anomalie zu sein in dem Fall, evtl. schlägt der VRAM-Bug hier bei einigen Karten zu. Ist natürlich die Frage, ob man sowas als Tester auch der Öffentlichkeit präsentiert. Als mündiger Leser sollte man aber auch in der Lage sein, solche Ausreißerergebnisse weniger stark in seiner Betrachtung zu gewichten.

Aber an anderer Stelle steht wieder mal kompletter Müll (zu Bioshock):
Auf Kantenglättung wird in den Tests verzichtet, die Standardtreiber erlauben keine Aktivierung von Anti Aliasing, im Spielmenü fehlt jegliche Einstellmöglichkeit. Hier muss man sich einfach daran gewöhnen, dass HDR-R-Effekte mit Kantenglättung seltener vorkommen, wenn das Spiel auf der XBox und dem PC erscheinen (Oblivion, Bioshock).

Wie recherchiert THG? Erst einmal geht AA in Bioshock unter DX10, wenn man sich nicht wie der letzte Hirni anstellt, dann hat das eventuelle Nichtfunktionieren von AA in Bioshock rein gar nix mit dem HDRR zu tun und schlussendlich ist die Bemerkung mit Oblivion komplett daneben, da hier AA schon seit Ewigkeiten funktioniert - auch mit HDRR.

[Gast]

Scheint wohl eine Anomalie zu sein in dem Fall, evtl. schlägt der VRAM-Bug hier bei einigen Karten zu. Ist natürlich die Frage, ob man sowas als Tester auch der Öffentlichkeit präsentiert. Als mündiger Leser sollte man aber auch in der Lage sein, solche Ausreißerergebnisse weniger stark in seiner Betrachtung zu gewichten.

Aber an anderer Stelle steht wieder mal kompletter Müll:


Wie recherchiert THG?

Also egal ob das nun THG is, aber die 2900er serie suckt mal total in DX10.
Da mach ich mir für die kommende 8700 keine sorgen.

[Gast]

Aber an anderer Stelle steht wieder mal kompletter Müll (zu Bioshock):
Wie recherchiert THG? Erst einmal geht AA in Bioshock unter DX10
AA geht bei Bioshock problemlos auch mit DX9 und Windows XP, einfach im Control Panel einstellen und funktioniert - wohl immer noch zu kompliziert für Tom's.

[Gast]

Also egal ob das nun THG is, aber die 2900er serie suckt mal total in DX10.

Jaja wieder gegen die 2900xt bashen,

World in Conflict 2900xt 7,0Fps, 8800GTS 640 8,0 Fps

Company of Heroes 2900xt 28,7Fps, 8800GTS 640 2,5Fps

[Gast]

Jaja wieder gegen die 2900xt bashen,

World in Conflict 2900xt 7,0Fps, 8800GTS 640 8,0 Fps

Company of Heroes 2900xt 28,7Fps, 8800GTS 640 2,5Fps

och ein fanboy hat sich verlaufen. Jeder mit hirn weiss das in Company die "kleine" 8800er am ram bug (vllt. noch) hängen.



Geh weiter heulen.

[BlackBirdSR]

THG ;)


Zusätzlich hat der superschnelle Ultra deutlich kürzere Ladezeiten in Bioshock und Lost Planet. Ob GTX und Ultra mit Spielen wie Hellgate London oder Crysis zurechtkommen, da kann man nur spekulieren, allerdings sind die Karten verdammt gut darauf vorbereitet und haben noch Reserven.


Was soll ich dazu sagen?

[Der_Korken]

Was soll das für Test sein? Klar die 8800GTS ist natürlich langsamer als ne 8600GTS oder ne 8400, deswegen heißt die ja auch 8800 :rolleyes:

Und wieso sollten die 800GTS/Ultra so abartig hohe Werte haben? Hatte das Spiel dauerhaft nen VRAM-Verbrauch von 800MB und alle Karten außer der GTX/Ultra sind deswegen untergegangen?

Also für mich sind diese beiden Benches für die Tonne, weil die Zahlen einfach nur total unrealistisch sind, da könnte man dutzende Beispiele aufzählen.

[Mr.Magic]

Aber an anderer Stelle steht wieder mal kompletter Müll (zu Bioshock):


Wie recherchiert THG? Erst einmal geht AA in Bioshock unter DX10, wenn man sich nicht wie der letzte Hirni anstellt, dann hat das eventuelle Nichtfunktionieren von AA in Bioshock rein gar nix mit dem HDRR zu tun und schlussendlich ist die Bemerkung mit Oblivion komplett daneben, da hier AA schon seit Ewigkeiten funktioniert - auch mit HDRR.

Da wüsste dann aber gerne, wie man BioShock unter Vista zur Kantenglättung animieren kann.
Denn bei mir, und nach meinem Wissen auch bei sonst niemandem, funktioniert AA nicht (DX9 und DX10).

[Gast]

och ein fanboy hat sich verlaufen. Jeder mit hirn weiss das in Company die "kleine" 8800er am ram bug (vllt. noch) hängen.



Geh weiter heulen.
Geh mal selber Heulen die 2900xt ist über 1000% schneller als die gleich Teure 8800GTS 640mb in DX10 und ja mit AA und AF.

OWEND hahahahaha

[Gast]

THG ;)



Was soll ich dazu sagen?

hehe, die rulen schon ^^ hatte net mal borsti (rivastation) die graka
tests gemacht? wo is der hin? der hatte doch richtig ahnung :)

[dargo]

Erst einmal geht AA in Bioshock unter DX10, wenn man sich nicht wie der letzte Hirni anstellt...
Nanu, habe ich was verpasst? Wie genau bekomme ich es hin?


Denn bei mir, und nach meinem Wissen auch bei sonst niemandem, funktioniert AA nicht (DX9 und DX10).
Unter DX9 geht AA schon.

Geh mal selber Heulen die 2900xt ist über 1000% schneller als die gleich Teure 8800GTS 640mb in DX10 und ja mit AA und AF.

OWEND hahahahaha
Hast heute was geraucht? Du verbessert das Gäste-Image mal wieder vom allerfeinsten.

[The_Invisible]

naja, die anderen ergebnisse sehen aber nicht so unrealistisch aus.

zumindest wird der einbruch der 2900er durch aa/af schön gezeigt.

mfg

[Gast]

Wiso ist die 8600er schneller als die 8800er? Der Test ist doch nicht normal.....

[Mr.Magic]

Unter DX9 geht AA schon.

Habe es selbst nicht probiert*. Als ich zu DX10+AA recherchierte stolperte ich darüber wie man bei BioShock Vista+DX9+AA hinbekommt. Dort stand eben, dass es nicht fehlerfrei funktioniert (u.a. sporadische Abstürze).
*, weil mich das sowieso nicht juckt. Unter XP reicht es im Profil den gewünschten AA-Modus auszuwählen. Was mich reizen würde ist DX10+AA.

[Gast]

Hast heute was geraucht? Du verbessert das Gäste-Image mal wieder vom allerfeinsten.
Warum es stehen 2,5fps gegen 20,7Fps (o.k. hab mich erst verlesen) macht immernoch über 800% aus.

[Spasstiger]

Nanu, habe ich was verpasst? Wie genau bekomme ich es hin?
Ok, dass es unter Vista nicht geht, wusste ich nicht. Hab halt mal Screens von Bioshock mit AA gesehen, deshalb dachte ich, dass es geht.
Die Begründung von THG, warum kein AA geht, ist dennoch total hirnrissig (HDRR, XBox360-Game).

[James Rayn]

naja, die anderen ergebnisse sehen aber nicht so unrealistisch aus.

zumindest wird der einbruch der 2900er durch aa/af schön gezeigt.

mfg
Und der Vram Bug wird auch sehr schön gezeigt ,sogar bei der Gts mit 640MB Ram ;-)

[pXe]

Würde mich mal interessieren ob die Einbrüche der 8800GTS mit einem aktuellen Nvidia Treiber genauso aussehen. THG benutzt ja den 162.22.



pXe

[Gast]

Jetzt mal unabhängig von den Testergebnissen, aber eins scheint zu stimmen: Die ATI2900XT wird nie in die Leistungsgruppe einer GTX/ULTRA stossen. Die ganzen ATI-Fanboys sollten das mal langsam raffen. Mit Glück kommt sie auf GTS Niveau. Ausserdem sieht man ganz klar das Nvidia in DX10 benches die Nase vorn hat. Gott zum Grusse

[Grindcore]

Genau und dadurch fällt die 8800GTS 640MB auf ein Viertel der Geschwindigkeit einer 8600GTS mit 256MB zurück. Wenn man das mal nicht als repräsentatives Ergebnis betrachten darf.

[The_Invisible]

Und der Vram Bug wird auch sehr schön gezeigt ,sogar bei der Gts mit 640MB Ram ;-)

nicht wirklich, sonst wäre die 8600gts mit 256mb nicht schneller.

mfg

[Grindcore]

Klar, das ist vollkommen logisch und folgerichtig.

[Spasstiger]

nicht wirklich, sonst wäre die 8600gts mit 256mb nicht schneller.

mfg
Ich vermute mal, dass der VRAM-Bug nicht bei allen Tests aufgetreten ist. Die 8800 GTSen waren dummerweise genau in den Tests dabei, wo der Bug auftrat. Und Company of Heroes ist ein Game, wo man den VRAM-Bug geradezu heraufbeschwören kann.

[Gast]

also sollen sie nur benchs machen wo nv besser ist, dass hier in dem forum jeder glücklich ist ;)

[Gast]

also sollen sie nur benchs machen wo nv besser ist, dass hier in dem forum jeder glücklich ist ;)

Die tester sollten nur darauf hinweisen, das da ein Bug besteht und NV evtl. es mit einem Treiber fixen kann und sich dann das blatt wendet. Aber das du das nicht in dein Hirn bekommst ist uns klar. AMD/ATI kann nur hoffen das NV das nicht hinbekommt. Sonst siehts Böse aus. Reicht ja jetz schon oftmals eine 320er 8800 für unter Dx10 tests aus. :P

[Schrotti]

THG halt.

Total für die Tonne der Test.

[Popeljoe]

Hu, hier gehts ja fast so toll ab, wie im PoWi Forum... :uup:
Sollte ein derartiger Müllbench hier mal auf die Hauptseite kommen würde es zu Recht wohl Haue geben! ;)
Das Einzige was man daran ablesen kann ist, daß man den Test nicht ernst nehmen sollte.

[Gast]

Wenn man sieht, was hier zu so einem Test geschrieben wird, da fragt man sich schon, wieviel Emotionen so ein dämliches Stück Hardware in manchen hervorrufen kann. Wie wärs mal mit: bei den Fakten bleiben und die Emotionen für sich selbst daheim ausleben?

[Gast]

Die tester sollten nur darauf hinweisen, das da ein Bug besteht und NV evtl. es mit einem Treiber fixen koennten und sich dann das blatt wenden koennte. Aber das du das nicht in dein Hirn bekommst ist uns klar. AMD/ATI kann nur hoffen das NV das nicht hinbekommt. Sonst siehts Böse aus. Reicht ja jetz schon oftmals eine 320er 8800 für unter Dx10 tests aus. :P
Wie lange ist G80 auf dem Markt? Und wenn der Nachfolger bis da ist sieht es mit einem eventuellen Fix noch uebler aus.

[dargo]

Warum es stehen 2,5fps gegen 20,7Fps (o.k. hab mich erst verlesen) macht immernoch über 800% aus.
Tue mir bitte einen Gefallen und denke erstmal nach bevor du sowas postest. :)
Der Test von THG ergibt einfach keinen Sinn, nicht immer nur ohne nachzudenken auf die Balkenlänge schauen. :wink:

[AMC]

Der Test von THG ergibt einfach keinen Sinn, nicht immer nur ohne nachzudenken auf die Balkenlänge schauen. :wink:

Mal vom verwendeten (162.22) Treiber abgesehen, warum ergibt der Test keinen Sinn? Haben die sich die Werte ausgedacht, oder gefällt vielen einfach nur das Ergebnis nicht? Ich finde es auch schade, dass sie es mal wieder nicht hinbekommen haben, AA in DX9 zu aktivieren und alte Treiber nutzen, aber was genau ist an diesen Tests jetzt "falsch"? Sinnvolle Erklärung bitte.

AMC

P.S. Wie ich schon zum CB-Test schrieb (Treiber, kein AA/AF), dass einzige, was dann völlig sinnbefreit wäre, ist das Fazit.

[Bumsfalara]

Hm.

Was hier einige doch immer wieder vergessen: Wenn der Vram-Bug auftritt, dann tritt er auf. THG kann das quasi egal sein, weil es ist doch eigentlich nicht zu erwarten, dass man solange mit den Treibern rumtestet, bis das Ergebnis passt...


Dass die 8600gts dadurch schneller als die 8800gts ist ist nunmal die Folge daraus. Das ist eher nVidia als THG anzulasten.

[dargo]

Mal vom verwendeten (162.22) Treiber abgesehen, warum ergibt der Test keinen Sinn? Haben die sich die Werte ausgedacht, oder gefällt vielen einfach nur das Ergebnis nicht?
1. Eine G8600GTS (512) kann überhaupt nicht schneller sein als eine G8800GTS (640). Lustigerweise tritt hier der Vram-Bug bei der G8800GTS und der G8600GTS anscheinend nicht (zumindest bis 1280x1024 4xAA/8xAF in CoH). Noch lustiger, die G8600GTS (256) ist sogar schneller als die G8800GTS (640) obwohl sie nur 40% derer Vram besitzt.

2. Eine G8800GTX kann max. ~50-55% schneller sein wie eine G8800GTS (640), natürlich solange wie der Vram der GTS nicht limitiert.

Man hätte wenigstens auf diesen Vram-Bug im Fazit hinweisen können. Das ändert natürlich nichts daran, dass NV was machen muss.

[AMC]

1. Eine G8600GTS (512) kann überhaupt nicht schneller sein als eine G8800GTS (640).

7 zu 6 fps halte ich für einen Auswuchs von entweder a) Messungenauigkeit, b) mögliche Latenzunterschiede im RAM(!), sowie c) möglicherweise einfach auf den Bug selbst zurückzuführen.


Lustigerweise tritt hier der Vram-Bug bei der G8800GTS und der G8600GTS anscheinend nicht (zumindest bis 1280x1024 4xAA/8xAF in CoH). Noch lustiger, die G8600GTS (256) ist sogar schneller als die G8800GTS (640) obwohl sie nur 40% derer Vram besitzt.

Ich schätze, das sieht nur so aus, denn wir wissen nicht, wie der Speicherstatus der einzelnen Karten vor dem Benchmark war. Ich hoffe Du verstehst, was ich meine: Keiner von uns kann exakt sagen, wie sich der Bug bis ins letzte Detail äussert. Möglicherweise ging die 256er mit leerem Speicher, aber die 640er eben nicht mit leerem RAM (vielleicht noch "Reste" vom letzten Test im RAM, wer weiß...?) in den Durchlauf. Ferner müsste geklärt werden, ob die Benchmarks auch wirklich korrekt auf jeder Karte exakt denselben Timeframe, also exakt in Ausführungsdauer von Start und Abbruch des Tests, übereinstimmen.

Mir schwant seit einiger Zeit etwas ganz anderes als Ursache. Ich habe irgendwie den Verdacht, dass es etwas mit der "krummen" RAM-Bestückung (also 640 / 320 MiB) liegen könnte. Vielleicht spielen da mehr Probleme rein, als ein simples: "Wir sagen dem Treiber, er soll nur 320 oder 640 Mb adressieren". Gut möglich, dass sich hier auch die API querstellt und die 320er als 512er zu erkennen glaubt, bzw. die 640er als 512er behandelt, die 768er aber als 1024er.


2. Eine G8800GTX kann max. ~50-55% schneller sein wie eine G8800GTS (640), natürlich solange wie der Vram der GTS nicht limitiert.

Wus? :| Eine GTX hat 25% mehr Recheneinheiten und 575 - 513 Mhz = 62 Mhz mehr ROP-Takt. Da komm ich (unter Vernachlässigung der Speicherbandbreite, ich behaupte dreist, dass diese weder auf GTS noch auf GTX limitiert, zumindest nicht bis 1600*1200 4/16) auf 1.25 * 575 = 718.75 zu 513 * 1.00 = 513. Wenn 718.5 100% darstellen (als eine GTX) dann sind 513 ~ 71.5%, ergo ein Unterschied von 28.6%. Auf 50% mehr Leistung kann eine GTX also schlicht nicht kommen und es würde mich doch sehr wundern, wenn nun plötzlich nochmal 25% nur durch den RAM-Takt hinzukommen würden.


Man hätte wenigstens auf diesen Vram-Bug im Fazit hinweisen können.

Jo, das Fazit ist bla, genau wie das Fazit von CB und das Fazit aus dem Tweaktown Artikel auf der Hauptseite.



Das ändert natürlich nichts daran, dass NV was machen muss.

Naja, sie haben ja schon was getan, die Serie ab dem 163er bringt in einigen Spielen, wenn eben auch nicht durch die Behebung des VRAM Bugs, einiges an Performance. Ich schätze, so oft wie in letzter Zeit beta Treiber released werden, dass der finale Treiber nicht mehr weit ist.

AMC

[dargo]

7 zu 6 fps halte ich für einen Auswuchs von entweder a) Messungenauigkeit, b) mögliche Latenzunterschiede im RAM(!), sowie c) möglicherweise einfach auf den Bug selbst zurückzuführen.

CoH:
1280x1024 4xAA/8xAF
G8600GTS (512) = 15,9fps
G8800GTS (640) = 10,3fps

1600x1200 4xAA/8xAF
G8600GTS (512) = 12,6fps
G8800GTS (640) = 2,5fps


Mir schwant seit einiger Zeit etwas ganz anderes als Ursache. Ich habe irgendwie den Verdacht, dass es etwas mit der "krummen" RAM-Bestückung (also 640 / 320 MiB) liegen könnte. Vielleicht spielen da mehr Probleme rein, als ein simples: "Wir sagen dem Treiber, er soll nur 320 oder 640 Mb adressieren". Gut möglich, dass sich hier auch die API querstellt und die 320er als 512er zu erkennen glaubt, bzw. die 640er als 512er behandelt, die 768er aber als 1024er.

Das erklärt immer noch nicht warum nur bestimmte Spiele betroffen sind. Ich habe so langsam das Gefühl, dass nur bestimmte Software die "krummen" Vram Werte nicht "mag".


Wus? :| Eine GTX hat 25% mehr Recheneinheiten und 575 - 513 Mhz = 62 Mhz mehr ROP-Takt. Da komm ich (unter Vernachlässigung der Speicherbandbreite, ich behaupte dreist, dass diese weder auf GTS noch auf GTX limitiert, zumindest nicht bis 1600*1200 4/16) auf 1.25 * 575 = 718.75 zu 513 * 1.00 = 513. Wenn 718.5 100% darstellen (als eine GTX) dann sind 513 ~ 71.5%, ergo ein Unterschied von 28.6%. Auf 50% mehr Leistung kann eine GTX also schlicht nicht kommen und es würde mich doch sehr wundern, wenn nun plötzlich nochmal 25% nur durch den RAM-Takt hinzukommen würden.

Oje, ich bin zu müde um das wieder auszuführen. Schau dir bitte die technischen Details der GTS und GTX an, dann einige Benchmarks und du wirst sehen, dass die GTX ca. 45-55% schneller ist. Natürlich in Graka-Limits.

[AMC]

CoH:
1280x1024 4xAA/8xAF
G8600GTS (512) = 15,9fps
G8800GTS (640) = 10,3fps

1600x1200 4xAA/8xAF
G8600GTS (512) = 12,6fps
G8800GTS (640) = 2,5fps


Ah ok, ich hatte die anderen Werte im Kopf.


Das erklärt immer noch nicht warum nur bestimmte Spiele betroffen sind. Ich habe so langsam das Gefühl, dass nur bestimmte Software die "krummen" Vram Werte nicht "mag".

Möglich. Vielleicht macht nur DX Probleme und OpenGL kann es besser ab, wer weiß.


Oje, ich bin zu müde um das wieder auszuführen. Schau dir bitte die technischen Details der GTS und GTX an, dann einige Benchmarks und du wirst sehen, dass die GTX ca. 45-55% schneller ist. Natürlich in Graka-Limits.

Dann schau Dir meine Rechnung bitte im wachen Zustand noch mal an. :wink: Es ist unmöglich, die Mathematik lügt nicht! :tongue:

AMC

[Der_Korken]

Mir schwant seit einiger Zeit etwas ganz anderes als Ursache. Ich habe irgendwie den Verdacht, dass es etwas mit der "krummen" RAM-Bestückung (also 640 / 320 MiB) liegen könnte. Vielleicht spielen da mehr Probleme rein, als ein simples: "Wir sagen dem Treiber, er soll nur 320 oder 640 Mb adressieren". Gut möglich, dass sich hier auch die API querstellt und die 320er als 512er zu erkennen glaubt, bzw. die 640er als 512er behandelt, die 768er aber als 1024er.


Interessanter Gedanke ... das ließe sich ja nachprüfen, wenn man ne GTS320 kurzzeitig zu ner GTS256 machen könnte. Ich weiß nicht, ob das zu einfach gedacht ist, aber würde die Karte (falls deine These überhaupt stimmt :) ) dann nicht korrekt als 256MB-Karte erkannt werden und der VRAM-Bug würde nicht mehr auftreten?


Wus? :| Eine GTX hat 25% mehr Recheneinheiten und 575 - 513 Mhz = 62 Mhz mehr ROP-Takt. Da komm ich (unter Vernachlässigung der Speicherbandbreite, ich behaupte dreist, dass diese weder auf GTS noch auf GTX limitiert, zumindest nicht bis 1600*1200 4/16) auf 1.25 * 575 = 718.75 zu 513 * 1.00 = 513. Wenn 718.5 100% darstellen (als eine GTX) dann sind 513 ~ 71.5%, ergo ein Unterschied von 28.6%. Auf 50% mehr Leistung kann eine GTX also schlicht nicht kommen und es würde mich doch sehr wundern, wenn nun plötzlich nochmal 25% nur durch den RAM-Takt hinzukommen würden.


Wieso denn 1,25*575 ? Wenn du eine GTS als 1*513 definierst, wäre die GTX logischerweise 1,33*575. Wenn man das nun ausrechnet und die GTX gleich 100% setzt, kommt die GTS auf einen Wert von 66,9%. Die GTS ist also 33,1% langsamer als die GTX. Aus Sicht der GTS ist die GTX 49,4% schneller. Dargo hatte schon Recht.

[dargo]

Interessanter Gedanke ... das ließe sich ja nachprüfen, wenn man ne GTS320 kurzzeitig zu ner GTS256 machen könnte. Ich weiß nicht, ob das zu einfach gedacht ist, aber würde die Karte (falls deine These überhaupt stimmt) dann nicht korrekt als 256MB-Karte erkannt werden und der VRAM-Bug würde nicht mehr auftreten?

Hmm, normalerweise könnte man doch der GTS 320 per Bios nur 256MB zuweisen können oder? Aber wäre NV nicht schon lange selbst darauf gekommen, wenns daran liegen würde?

[Der_Korken]

Hmm, normalerweise könnte man doch der GTS 320 per Bios nur 256MB zuweisen können oder? Aber wäre NV nicht schon lange selbst darauf gekommen, wenns daran liegen würde?

Jo, eben. Selbst wenn es das wäre, würde ich mich nicht mit weniger VRAM zufrieden geben. 320MB sind schon wenig, wie sollte ich mit noch weniger auskommen ;D

[AMC]

Wieso denn 1,25*575 ? Wenn du eine GTS als 1*513 definierst, wäre die GTX logischerweise 1,33*575. Wenn man das nun ausrechnet und die GTX gleich 100% setzt, kommt die GTS auf einen Wert von 66,9%. Die GTS ist also 33,1% langsamer als die GTX. Aus Sicht der GTS ist die GTX 49,4% schneller. Dargo hatte schon Recht.

Hast recht, aus Sicht der GTS muss es natürlich 1.33 sein, stimmt! Aus Sicht der GTX ist die GTS 33% langsamer, das kommt hin. Mein Gott ist das wieder spät heute, einfach net mehr auf dem Dampfer....:cool:;D Aber danke für die Korrektur.

AMC

[Der_Korken]

Kein Problem :D

[AMC]

Interessanter Gedanke ... das ließe sich ja nachprüfen, wenn man ne GTS320 kurzzeitig zu ner GTS256 machen könnte. Ich weiß nicht, ob das zu einfach gedacht ist, aber würde die Karte (falls deine These überhaupt stimmt :) ) dann nicht korrekt als 256MB-Karte erkannt werden und der VRAM-Bug würde nicht mehr auftreten?

So "ganz" einfach ist das nicht, da eine 8600er mit 256 MiB den Bug ja nun auch hat. Wie hier jemand (dargo?) ja schon ausführte, liegt das Problem darin, den Bug erstmal greifbar zu machen, dazu müsste man mal einige umfangreiche Tests durchführen, was sich mit einigen Usern hier auf 3DC sicher bewerkstelligen liesse.

Zuerst benötigt man einen Test, der definitiv den VRAM Bug nachweislich erzeugt, ohne dabei eine (normale) Verlangsamung durch die schlichte Menge an Texturen und Geometrie/Shaderdaten zu erzeugen. Dann müsste man sich ein Spiel raussuchen, dass durch die schiere Menge an Daten eine Verlangsamung erzeugt, aber nicht durch den VRAM Bug. Das Problem ist, dass mehr als zwei Kombinationen denkbar sind, da es Caching und Prefetching Strategien gibt, den VRAM auch dann sinnvoll zu nutzen, wenn die eigentliche Belastung (der durch das Spiel vorgegebene Content) größer ist, als die Größe des VRAMs. Ein Beispiel sei hier Quake4, dass in der Ultra High Quality nach einer 512 MiB Karte verlangt hat, aber auf 256 MiB Karten trotzdem spielbar war, will sagen, eine X1900XT mit 256 MiB brach dann zwar auch ein, wenn mindestens 512 MiB benötigt worden wären, aber niemals SO stark, wie es die 320er GTS tut, wenn 512 MiB, oder mehr, gefordert sind. Hieraus ergeben sich folgende Kombinationen:


a) Spiel hält VRAM Verbrauch unter 320Mib -> kein Perf. Problem.
b) Spiel hält VRAM Verbrauch über 320MiB -> Perf. Probleme durch Contentgröße, aber ohne VRAM-Bug.
c) Spiel hält VRAM Verbrauch über 320Mib -> Perf. Probleme durch VRAM-Bug
d) Spiel hält VRAM Verbrauch über 320MiB -> Perf. Probleme durch VRAM-Bug und Contentgröße.
e) Spiel hält VRAM Verbrauch über 320Mib -> Einbrüche, aber noch keine "größeren" Perf. Probleme, bleibt mit Abstrichen spielbar -> Cachingstrategien und intelligentes Auslagern funktionieren.

Es ist also gar nicht so einfach, genau zu klassifizieren, was nun wann und wo greift. Wie ich schon mit Q4 ausführte, jede 256MiB Karte brach auf Ultra High Quality zwar ein, aber nie so stark, wie es die GTS nun tut. Dies liegt einfach daran, dass es (genau wie im C2D, P4, K8) intelligente Prefetcher und cache-control Mechanismen gibt. Anders ausgedrückt: Auf einer CPU lässt sich z.B. Cache Pollution (umgangssprachlich: Verkehr auf dem (relativ) kleinen Cache mit vielen Daten, was zu einer erhöhten Anzahl von cache misses und traffic auf dem FSB/Datenpfad führt, da nachgelesen werden muss) durch geschicktes Prefetching (PREFETCHNT(A/H)) zumindest teilweise verbergen, ich bin mir zu 100% sicher, dass sowohl ATI wie auch nV über diverse Algorithmen im Treiber, wie auch in Hardware (Prefetcher) verfügen, die Datenpakete, auch bei nicht mehr ausreichend vorhandenem Speicherplatz intelligent durchreichen, bzw. dem Chip nutzbar machen. Wer jetzt schreit, ich laber Blödsinn, dem Beweise ich mit meinen Assemblerprojekten (SSE2/FPU Load-Balancing -> von mir im Rahmen eines Forschungsprojektes an der Hochschule entwickelt), bei Interesse jederzeit das Gegenteil. Den richtig erfahrenen Programmierer/Chipdesignern bei ATI/nV traue ich allemal zu gute Algorithmen für solche Spielchen im Treiber und auch in der Hardware implementieren zu können.

Der Haken liegt also nicht so einfach in der Größer der alloc-range im VRAM, sondern möglicherweise an sich gegenseitig aufhebenden "Speicherverwaltungsomptimierungen" (ich muss ins Bett ;D)), seitens der API und des Treibers, möglicherweise konträr zu den Hardware-Prefetchern und der Adressberechnung, die der microcode/Treiber vorgibt. Mal eben einfach so int mem_size = 320 im Treiber zu setzen, reicht bei dieser Beschneidung der VRAM Größe einfach nicht aus, den Controllern der Daten-/Adresspfade muss das auch beigebracht werden, sei es eben durch microcode.

Ich könnte das jetzt technisch weiter ausführen, weiß aber nicht, wie vergleichbar die Prefetcher und Speichercontroller der G80 mit einem x86er sind (dort liegen meine Stärken). Hätten wir das Problem auf einem C2D, hätte ich schon einige Ideen, woran es liegen könnte. Auf jeden Fall ist das Problem wohl doch so komplex, dass es sich nicht eben mal so aus der Welt schaffen lässt, was mich dazu bringt, nicht mehr an einen einfach "Fix" auf die Schnelle, zu glauben. (Ich denke nach wie vor, dass ein Treiber hier Abhilfe schaffen wird, aber in welchem Rahmen, dass ist hier die Frage!) Wenn es nämlich nur ein Allokationsproblem wäre, würde ja auch ein Patch für das jeweilige Spiel schon Abhilfe schaffen, was die Karten (so sollte ihr VRAM in der Größe nicht korrekt erkannt werden), korrekt erkennt.

Mir scheint, dass nVidia es sich irgendwo zu einfach gemacht hat und die Rechnung, die Prefetcher oder die Speichercontroller (Addressierer, etc.) mal eben per microcode auf 320 / 640 MiB einzustellen, so einfach nicht aufgeht. Möglicherweise gibt es da unbeabsichtigte Nebeneffekte. Mir würden da spontan die Adressierer einfallen.

AMC

[AMC]

Hihi, nur mal so als Denkanstoss: Der G80 ist ja eigentlich für 768 MiB konzipiert worden, ergo auch die Daten-/Adressrechner, also die Einheiten, die sich um die Generierung der Adressen der zu lesenden und schreibenden Daten im VRAM kümmern. Wenn ich diese nun einen Adressraum von 768 MiB überschauen lasse und ich streiche Ihnen einfach 128 Mb (640er) und 448 MiB weg, ohne sie darüber zu informieren, dann ist das, was passieren dürfte (es ist ja hier wohl allen klar, dass es genau EINEN Chip-typ gibt, den nV vom Band laufen lässt, ja? Das sind in Rohform alles vollwertige G80, die je nach Einsatzgebiet und Qualität gelabelled und notfalls per lasercut auf die jeweilige Klasse "eingestellt" werden, durch deaktivierung der Recheneinheiten) folgendes: Die Adressierer rechnen fröhlich auf einem 768er MiB Adressraum, während der physikalische Speicher bereits randvoll ist. Bei der 640er später, bei der 320er früher, bei der GTX nicht zu beobachten. (Siehe z.B. THG - Review von heute!) Aufgrund der Tatsache, dass die Adressierer auch keinen "Alarm" schlagen, wie: "Hey! Der Content übersteigt unsere VRAM Größe, aktiviert mal zackig ne prefetch/unload-Strategie", kommt es zu diesem mördermäßigen Einbruch, ausgelöst durch korrekte Berechnungen auf einem zu großen Adressraum, bei gleichzeitig nicht mehr vorhandenem Platz im RAM. Lustigerweise dürften die Adressierer hier sogar versuchen, aus Adressbereichen zu lesen, die gar nicht existent sind, was zu einem Fehler führt, der (zumindest unter x86er CPUs) dazu führt, dass der Schreib-/Lesezyklus erneut durchgeführt wird. Hach was wäre das ein Spaß, wenn die Adressierer den Crossbarcontroller pfoppen würden und dadurch Daten weder sinnvoll ein, noch ausgelagert werden könnten. Denkbar ist ein solches Szenario, siehe mein obiges Posting zum Thema Abhängigkeiten. Der C2D hat z.B. pro Kern 6 Prefetcher, 2 nur für die SSE-Einheiten (XMM0 - XMM7), 2 für den FPU Stack (st(0) - st(7)) und 2 für die Allzweckregister. Da steckt ne ganze Ecke Kontrolllogik drin, damit die Prefetcher keine sinnlosen Daten aus dem RAM holen. Beispiel: st(0) möchte einen 8byte real aus dem RAM haben und XMM0 benötigt diesen auch, so sind die Prefetcher so schlau, nicht zwei mal denselben Wert aus dem RAM anzufordern, FSB Bandbreite und MEM/DATA-Zyklen zu verbrauchen und am besten noch die Werte in zwei verschiedenen Cachelines abzulegen. ;D Ich schätze, sowas in der Art wird es auch im G80/R600 geben und möglicherweise liegt da irgendwo auch das Problem.

AMC

P.S. Nu aber wirklich: weg he! :weg:

[Der_Korken]

a) Spiel hält VRAM Verbrauch unter 320Mib -> kein Perf. Problem.
b) Spiel hält VRAM Verbrauch über 320MiB -> Perf. Probleme durch Contentgröße, aber ohne VRAM-Bug.
c) Spiel hält VRAM Verbrauch über 320Mib -> Perf. Probleme durch VRAM-Bug
d) Spiel hält VRAM Verbrauch über 320MiB -> Perf. Probleme durch VRAM-Bug und Contentgröße.
e) Spiel hält VRAM Verbrauch über 320Mib -> Einbrüche, aber noch keine "größeren" Perf. Probleme, bleibt mit Abstrichen spielbar -> Cachingstrategien und intelligentes Auslagern funktionieren.


Um es wirklich nachzuweisen, müssten mehrere Leute das gleiche Ergebnis bestätigen und es sollte vllt auch per Screenshot festgehalten sein.

Für Punkt b) bietet sich vielleicht CoD2 an. VRAM-Bug kann ich beim besten Willen nicht erkennen, VRAM-Verbrauch (laut Rivatuner) von 400MB+ und die niedrigen Frames sprechen für sich.
Bei c) hätte ich Oblivion vorgeschlagen. Wobei ich anmerken muss, dass das Spiel bei arg extremen Auslagerungen tatsächlich schon mal den VRAM bei mir geleert hat. (Dieser Punkt lag bei etwa 500MB ... ob das eventuell damit zusammenhängt, dass das Spiel meiner Karte 512MB zuschreibt, ist erstmal reine Spekulation !)

Jetzt wird es schwierig: Wie unterscheidet man den VRAM-Bug von zu großen Content oder gar von einer Kombination aus beidem?

Wenn man davon ausgeht, dass Oblivion den VRAM-Bug produziert, ließe sich durch einen Texturmod vllt noch eine gleichzeitige Content-Überfüllung erzeugen. Das wäre dann ein Vorschlag für Punkt d).

Punkt e) wird schwierig. Ich würde da eventuell Bioshock in die Runde werfen. Vor dem 163.44 hatte ich dort VRAM-Auslastungen von über 400MB. Trotzdem war es gut spielbar, bis auf ein paar wenige kritische Stellen. Ich hatte damals aber nicht genau protokolliert, ob die 400MB eventuell durch den VRAM-Bug entstanden sind. Seit dem 163.44 hab ich konstant ne Auslastung von ~320MB.

(alle Angaben beziehen sich auf WinXP 32bit, 1680x1050, full detail, 4xAA (außer Bioshock: 1xAA))

[AMC]

Um es wirklich nachzuweisen, müssten mehrere Leute das gleiche Ergebnis bestätigen und es sollte vllt auch per Screenshot festgehalten sein.

Für Punkt b) bietet sich vielleicht CoD2 an. VRAM-Bug kann ich beim besten Willen nicht erkennen, VRAM-Verbrauch (laut Rivatuner) von 400MB+ und die niedrigen Frames sprechen für sich.
Bei c) hätte ich Oblivion vorgeschlagen. Wobei ich anmerken muss, dass das Spiel bei arg extremen Auslagerungen tatsächlich schon mal den VRAM bei mir geleert hat. (Dieser Punkt lag bei etwa 500MB ... ob das eventuell damit zusammenhängt, dass das Spiel meiner Karte 512MB zuschreibt, ist erstmal reine Spekulation !)

Jetzt wird es schwierig: Wie unterscheidet man den VRAM-Bug von zu großen Content oder gar von einer Kombination aus beidem?

Wenn man davon ausgeht, dass Oblivion den VRAM-Bug produziert, ließe sich durch einen Texturmod vllt noch eine gleichzeitige Content-Überfüllung erzeugen. Das wäre dann ein Vorschlag für Punkt d).

Punkt e) wird schwierig. Ich würde da eventuell Bioshock in die Runde werfen. Vor dem 163.44 hatte ich dort VRAM-Auslastungen von über 400MB. Trotzdem war es gut spielbar, bis auf ein paar wenige kritische Stellen. Ich hatte damals aber nicht genau protokolliert, ob die 400MB eventuell durch den VRAM-Bug entstanden sind. Seit dem 163.44 hab ich konstant ne Auslastung von ~320MB.

(alle Angaben beziehen sich auf WinXP 32bit, 1680x1050, full detail, 4xAA (außer Bioshock: 1xAA))

:up: Das Du Dir Gedanken machst! Ich schätze leider, es ist für uns erstmal unentscheidbar, da es kaum eine Möglichkeit gibt, den Fall content + bug zu erkennen, da sich dieser zwar deutlich unter, aber in etwa in ähnlichen Regionen wie Fall b zeigen dürfte. Hinzu kommen noch die CPU Unterschiede. Will sagen, auf meinem 4GHz C2D ist die Performance mit VRAM Bug und Content, alleine durch die hohe Speicherbandbreite (1000 @ 4-4-4-10 D9GMH :cool:) noch deutlich höher, als mit einem A64 6000+ und langsameren 800er DDR2. Ein Beispiel: Obwohl ich in Stalker nachweislich den Bug reproduzieren konnte, fiel es mir oftmals einfach nicht auf, da die fps nur auf etwa ~36 fps fielen, bei Highest Quality @ 3.2 Ghz E6750. Auf 4 Ghz waren es dann noch immer knapp über 40, hier dürfte die Speicherbandbreite ausschlaggebend gewesen sein. Ist also sehr schwer, hier Messwerte mit allgemeiner Gültigkeit zu erhalten.

AMC

[sun-man]

hehe, die rulen schon ^^ hatte net mal borsti (rivastation) die graka
tests gemacht? wo is der hin? der hatte doch richtig ahnung :)
Seit Borsti bei ATI bzw jetzt AMD ist mmacht er leider auf der Station garnix mehr. Leider, denn wir würden die station gerne wieder leben lassen :(

[The_Invisible]

Hihi, nur mal so als Denkanstoss: Der G80 ist ja eigentlich für 768 MiB konzipiert worden, ergo auch die Daten-/Adressrechner, also die Einheiten, die sich um die Generierung der Adressen der zu lesenden und schreibenden Daten im VRAM kümmern. Wenn ich diese nun einen Adressraum von 768 MiB überschauen lasse und ich streiche Ihnen einfach 128 Mb (640er) und 448 MiB weg, ohne sie darüber zu informieren, dann ist das, was passieren dürfte (es ist ja hier wohl allen klar, dass es genau EINEN Chip-typ gibt, den nV vom Band laufen lässt, ja? Das sind in Rohform alles vollwertige G80, die je nach Einsatzgebiet und Qualität gelabelled und notfalls per lasercut auf die jeweilige Klasse "eingestellt" werden, durch deaktivierung der Recheneinheiten) folgendes: Die Adressierer rechnen fröhlich auf einem 768er MiB Adressraum, während der physikalische Speicher bereits randvoll ist. Bei der 640er später, bei der 320er früher, bei der GTX nicht zu beobachten. (Siehe z.B. THG - Review von heute!) Aufgrund der Tatsache, dass die Adressierer auch keinen "Alarm" schlagen, wie: "Hey! Der Content übersteigt unsere VRAM Größe, aktiviert mal zackig ne prefetch/unload-Strategie", kommt es zu diesem mördermäßigen Einbruch, ausgelöst durch korrekte Berechnungen auf einem zu großen Adressraum, bei gleichzeitig nicht mehr vorhandenem Platz im RAM. Lustigerweise dürften die Adressierer hier sogar versuchen, aus Adressbereichen zu lesen, die gar nicht existent sind, was zu einem Fehler führt, der (zumindest unter x86er CPUs) dazu führt, dass der Schreib-/Lesezyklus erneut durchgeführt wird. Hach was wäre das ein Spaß, wenn die Adressierer den Crossbarcontroller pfoppen würden und dadurch Daten weder sinnvoll ein, noch ausgelagert werden könnten. Denkbar ist ein solches Szenario, siehe mein obiges Posting zum Thema Abhängigkeiten. Der C2D hat z.B. pro Kern 6 Prefetcher, 2 nur für die SSE-Einheiten (XMM0 - XMM7), 2 für den FPU Stack (st(0) - st(7)) und 2 für die Allzweckregister. Da steckt ne ganze Ecke Kontrolllogik drin, damit die Prefetcher keine sinnlosen Daten aus dem RAM holen. Beispiel: st(0) möchte einen 8byte real aus dem RAM haben und XMM0 benötigt diesen auch, so sind die Prefetcher so schlau, nicht zwei mal denselben Wert aus dem RAM anzufordern, FSB Bandbreite und MEM/DATA-Zyklen zu verbrauchen und am besten noch die Werte in zwei verschiedenen Cachelines abzulegen. ;D Ich schätze, sowas in der Art wird es auch im G80/R600 geben und möglicherweise liegt da irgendwo auch das Problem.

AMC

P.S. Nu aber wirklich: weg he! :weg:

speicher wird üblicherweise in software allokiert und wieder freigegeben = treibersache. würde die karte dem treiber aber immer sagen: "wir haben 768mb zur verfügung" obwohl es garnicht stimmt, könnte es aufs gleiche hinauskommen. wenn es aber so einfach wäre würde es schon lange einen fix dafür geben. außerdem ist ein treiber mit ein paar millionen zeilen code auch nicht so einfach nach einem bug zu durchsuchen.

mfg

[dargo]

Jetzt wird es schwierig: Wie unterscheidet man den VRAM-Bug von zu großen Content oder gar von einer Kombination aus beidem?

Mit dem Rivatuner den Vram zb. eine Stunde lang aufnehmen. Wenn der Vram-Bug greift müsste der Bedarf kontinuierlich ansteigen. Bei zu großem Content hast du den Vram max. oder mehr in der Regel direkt erreicht.

[Gast]

hehe, die rulen schon ^^ hatte net mal borsti (rivastation) die graka
tests gemacht? wo is der hin? der hatte doch richtig ahnung :)

Der ist jetzt ein hohes Tier bei ATI/AMD.

[Gast]

Seit Borsti bei ATI bzw jetzt AMD ist mmacht er leider auf der Station garnix mehr. Leider, denn wir würden die station gerne wieder leben lassen :(

Das ist doch auch verständlich, dass er da nichts mehr macht zumal man bei Tests immer an der Objektivität zweifeln müsste. Trotzdem ist es schade, denn ich bin auch seit vielen Jahren im RS-Forum. Vielleicht sollte er die Webseite einem anderen, motivierten Hardware-Nerd überlassen und nur noch als Gründer und Cheff a.D. in Erscheinung treten...

[Mr. Lolman]

Da die GTX den VRAM-Bug ja nicht hat, müsste man nur GTS mit GTX vergleichen. Sobald bei der GTS mehr Speicher alloziert wird, als bei der GTX, ist der VRAM-Bug aktiv.

[AMC]

speicher wird üblicherweise in software allokiert und wieder freigegeben = treibersache. würde die karte dem treiber aber immer sagen: "wir haben 768mb zur verfügung" obwohl es garnicht stimmt, könnte es aufs gleiche hinauskommen. wenn es aber so einfach wäre würde es schon lange einen fix dafür geben. außerdem ist ein treiber mit ein paar millionen zeilen code auch nicht so einfach nach einem bug zu durchsuchen.

mfg

So trivial wird der Fehler nun ja nicht sein. ;) (Hoffentlich, wenn doch, geb ich meine G80 zurück :biggrin:) Mir ging es auch weniger um die Allokation, sondern um eine fehlerhafte Adressberechnung! Die wiederum geschieht komplett in HW, da macht goa nüx der Treiber. Selbst wenn nV so schlau war, die Adresspfade korrekt in ihrer Breite zur Adressierung auf den kleineren 320 bit Bus anzupassen und damit automatisch die Größe des Adressraums einzuschränken, bedeutet das nicht, dass in der GPU nach wie vor falsche Adressen generiert werden und auf den Pfad gelegt werden wollen. Allerdings kenne ich mich mit dem G80 nicht gut genug aus, um sagen zu können, wie es dort genau läuft, wie breit der Adressierungsbus ist, oder ob I/O direkt über die 320bit bidirektional gemacht werden. Am möglichen Problem ändert das allerdings nicht, wäre nur eine andere Technik der Adressierung.

AMC

[dargo]

Da die GTX den VRAM-Bug ja nicht hat, müsste man nur GTS mit GTX vergleichen.
Warum sollte die GTX diesen nicht haben? Verstehe den Zusammenhang nicht.

[Mr. Lolman]

Warum sollte die GTX diesen nicht haben?

Ich hab bis jetzt noch nix gegenteiliges gesehen/gelesen.

[AMC]

Interessant wäre es mal herauszufinden, wie der Crossbar derzeit unterteilt ist (ich schätze 12-fach -> 32bit, oder 6-fach -> 64bit), hab dazu hier nix schlüssiges gefunden. Aber selbst wenn sich nV den Adressbus schenkt und alles bidirektional gleichzeitig über den Crossbarcontroller schreibt und liest (also die Adressen direkt auf den Datenbus legt, in 32/64bit Blöcken, je nach geforderter Granularität der Daten, die gelesen und geschrieben werden sollen), so würde es tatsächlich nicht konträr zu meiner Idee mit den zickigen Adressberechnern stehen, was die 320bit Versionen des G80 angeht. Es würde sogar ziemlich gut erklären, warum der Fehler manchmal so schwammig zu reproduzieren ist, alleine daher, weil er nur dann auftritt, wenn der Adressraum ab 320 -> 384 bit angesprochen werden würde. In einem solchen Fall würden die überzähligen bits der Adresse schlicht truncated/ignoriert und nur der Rumpf wäre übrig, was bei Adressen größer 320/640 MiB zum wiederholten auslesen von ein und dem letzten von den Controllern erreichbaren Speicherblock führen würde.....Verdammt interessantes kleines Gedankenspielchen.

AMC

P.S. Sorry for offtopic, das sollte man vielleicht mal in einen neuen Thread packen.

[The_Invisible]

DirectX 10 Performance Update: Is DX10 Really Worth It?
http://www.firingsquad.com/hardware/geforce_radeon_directx_10_performance_update/default.asp

sieht nicht gerade besser aus, ne 2900xt ist etwa auf 320mb gts niveau

mfg

[Gast]

DirectX 10 Performance Update: Is DX10 Really Worth It?
http://www.firingsquad.com/hardware/geforce_radeon_directx_10_performance_update/default.asp



Da kann nur auf die 2. Gen der DX10(10.1) Karten warten, denn das sieht alles nicht sehr gut aus ich will nicht mit 30fps rumtuckern für ein bischen Eyecandy.
Da muß Nvidia und Ati sich aber nochmal richtig auf den Hosenboden setzen und M$ gleich mit.
Ich sehe für Crysis in DX10 ,derzeit sehr Schwarz.

[Tigerchen]

hehe, die rulen schon ^^ hatte net mal borsti (rivastation) die graka
tests gemacht? wo is der hin? der hatte doch richtig ahnung :)

Borsti ist jetzt ATI Pressesprecher.

[Nakai]

Ich hab bis jetzt noch nix gegenteiliges gesehen/gelesen.

Sie hat wohl zuviel VRam dafür...


mfg Nakai

[AMC]

Da muß Nvidia und Ati sich aber nochmal richtig auf den Hosenboden setzen und M$ gleich mit.
Ich sehe für Crysis in DX10 ,derzeit sehr Schwarz.

Ich sehe hier vor allem Vista als (Mit-)Übeltäter. Das man derzeit unter Vista schnell mal bis zu 30% weniger Performance geboten bekommt, ist auch so eine Sache, die DX10 nicht gerade schmackhaft macht, da sehe ich eher schwarz.

AMC

[dargo]

Sie hat wohl zuviel VRam dafür...

Es ist doch völlig egal wieviel Speicher die Karte hat. Bei einem Vram-Bug wird der Vram doch endlos gefüllt. Bei der GTX dürfte es also nur etwas länger dauern bis dieser voll ist.

[DavChrFen]

Gbt es eigentlich irgendwo eine Erklärung, was man unter V-Ram-Bug versteht?

[Gast]

Gbt es eigentlich irgendwo eine Erklärung, was man unter V-Ram-Bug versteht?

schmeiss mal bitte die board suche an...

selbst unter wikepedia gibts nen eintrag dazu

http://de.wikipedia.org/wiki/Nvidia-GeForce-8-Serie

Fehler im Speichermanagement

[Schrotti]

Eigentlich müsste nvidia alle Karten austauschen (wie Intel beim Pentium-FDIV-Bug).

http://de.wikipedia.org/wiki/Pentium-FDIV-Bug

[Schrotti]

Ich hab das ganze nun auch mal getestet (Forceware 163.71 unter Vista 32bit).

Ich mag zwar zu blöd sein einen screen zu machen (die hatten alle nur einen schwarzen Inhalt) aber die Ergebnisse stimmen nicht mit denen von THG überein.

Ich hab dann also zur Digicam gegriffen (sorry).

4xAA im Spiel und 8xAF im Treiber forciert.

http://www.abload.de/img/settings3ab.png (http://www.abload.de/image.php?img=settings3ab.png)

Hier dann einmal meine 8800GTS mit Standard Takt und einmal mit 700/1100.

http://www.abload.de/img/8800gts_standardsea.gif (http://www.abload.de/image.php?img=8800gts_standardsea.gif)

http://www.abload.de/img/8800gts_uebertaktetkz2.gif (http://www.abload.de/image.php?img=8800gts_uebertaktetkz2.gif)

Ich habe die Tests mehrmals laufen lassen und immer vielen die fps im Rahmen aus (+/- 1-2%).

Wo ist da der Vram Bug?

[AMC]

Ich hab das ganze nun auch mal getestet (Forceware 163.71 unter Vista 32bit).

Ich mag zwar zu blöd sein einen screen zu machen (die hatten alle nur einen schwarzen Inhalt) aber die Ergebnisse stimmen nicht mit denen von THG überein.

Ich hab dann also zur Digicam gegriffen (sorry).

4xAA im Spiel und 8xAF im Treiber forciert.

http://www.abload.de/img/settings3ab.png (http://www.abload.de/image.php?img=settings3ab.png)

Hier dann einmal meine 8800GTS mit Standard Takt und einmal mit 700/1100.

http://www.abload.de/img/8800gts_standardsea.gif (http://www.abload.de/image.php?img=8800gts_standardsea.gif)

http://www.abload.de/img/8800gts_uebertaktetkz2.gif (http://www.abload.de/image.php?img=8800gts_uebertaktetkz2.gif)

Ich habe die Tests mehrmals laufen lassen und immer vielen die fps im Rahmen aus (+/- 1-2%).

Wo ist da der Vram Bug?

Hej. Welches Spiel hast Du da getestet?

Ich hab bis jetzt noch nix gegenteiliges gesehen/gelesen.

Ich auch nicht und glaube auch nicht, dass der "Bug" auf der GTX auftritt. Ich bin nach wie vor der Meinung, dass es sich um keinen konkreten Bug im eigentlichen Sinne, also designspezifisch in der Hardware, handelt. Es steht irgendwie direkt im Zusammenhang mit dem Abspecken des Speicherinterface und der Recheneinheiten. (Siehe auch meine Theorie dazu)

AMC

[kahlchen]

Hej. Welches Spiel hast Du da getestet?

Das ist Company of Heroes (CoH).
Ich denke mal der "Bug" tritt nur auf, wenn man etwas quasi hintereinander spielt bzw es über einen längeren Zeitraum spielt (z.B. mehrere Stunden).

[rogard]

HI Schrotti,

danke für den Link. Sieht ja alles soweit normal aus hier. Aber du benutzt ja auch die neueren treiber. Hast Du vielleicht den Fix von MS auch drauf, da soll es doch was geben, was diese Speicherproblematik unter Vista mildert?

Deine Einstellungen sind genau die gleichen, oder hat THG alles auf ULTRA gehabt? Ich habe das Spiel noch nicht, daher kann ich es selbst nicht testen. Außerdem wohl wenig sinnvoll mit meiner ollen 6600er :-(

Gute Arbeit jedenfalls. Ich finde den THG Artikel ein bisschen schlampig, er hätte wenigstens auf die Probleme aufmerksam werden (und machen!) müssen. Aber THG ist sowieso nicht mehr das was sie mal waren, alles sehr schlampig zusammengehämmert heutzutage. Ich könnte mich ständig drüber aufregen...

Cheer,

rogard

[Schrotti]

Laut den Kommentaren bei THG hatten die auch ULTRA eingestellt.


3D Mann 28/09/2007 10:29

3D Mann Erst mal Danke fürs Feedback

Danke an bummelch

Zu den Werten, bitte nicht immer Äpfel mit Birnen vergleichen:
Wenn ich die Texture Details on CoH auf High runternehme, bekomme ich auch über 50 fps.
Die Einstellungen sind auf Ultra (4 Stück). Bitte benutzt auch diese Einstellungen!

Die 1024MB 2900XT ist uns noch nicht angeboten worden, ich versuche mal ein Testsample zu bekommen.

[dargo]

Ich auch nicht und glaube auch nicht, dass der "Bug" auf der GTX auftritt.
http://www.forum-3dcenter.org/vbulletin/showpost.php?p=5886518&postcount=603

[The_Invisible]

ich habe den vram-bug jedenfalls auch noch nie gehabt/bemerkt, siehe auch hier -> http://www.forum-3dcenter.org/vbulletin/showpost.php?p=5878985&postcount=26

vielleicht hängt es auch von der mondkonstelation ab ;)

mfg

[kahlchen]

vielleicht hängt es auch von der mondkonstelation ab ;)

ich hau mich weg ;D

[AMC]

http://www.forum-3dcenter.org/vbulletin/showpost.php?p=5886518&postcount=603

Leider ist dieser Beitrag wenig aussagekräftig, da der Satz "Ich habe nun den VRAM Bug mit meiner GTX", kaum einer wirklich wissenschaftlichen Betrachtung standhält, hier fehlen einfach zuviele weitere Parameter, CPU, RAM, welche Einstellungen und selbst wenn diese Informationen verfügbar sind, so heißt das noch lange nicht, dass es sich um den wirklichen "VRAM-Bug" (ich nenne es in Zukunft besser 'VRAM-Verhalten') oder schlicht um die Verlangsamung durch zuviel content, oder gar um einen Bug im Spiel handelt.

In all den Reviews im Netz (z.B. HardOCP - Bioshock in perversen Auflösungen / THG DX10 Test) war der "VRAM-Bug" nirgends eindeutig auf einer GTX reproduziert worden. Ich bleibe vorerst bei meiner Vermutung, dass durch den Lasercut und das downgraden vollwertiger G80 Chips ein Seiteneffekt in irgendeiner Form (Microcode, Adressierer / Prefetcher / Dirty-bits) aufgetreten ist, der für das nicht-leeren des Speichers verantwortlich zeichnet. Ich hätte sogar noch eine weitere Theorie anzubieten: In den x86er CPUs existiert ein sogenantes "dirty-bit" als Teil eines TSS (Task-State-Segmentes), bzw. besser: als Teil einer Speicherseite (mem-page), dass den verschiedenen Scheduling Algorithmen des OS-Kernels mitteilt, ob ein Speicherbereich (in Pages) eines Prozesses genutzt wurde, oder nicht. Je nach dem wie das dirty-bit ausgewertet wird, kann der Scheduler entscheiden, was mit den Daten eines Prozesses im nächsten Timeslice passiert, also ob z.B. alle Daten eines Prozesse beim nächsten "aufwecken", also in der nächste Zeitscheibe, verfügbar sein sollen. Es gibt verschiedene Strategien, den Speicher mit den richtigen Daten zu füllen, wenn die jeweiligen Prozesse gestartet werden, bzw. wiederaufgenommen werden. Ich könnte mir gut vorstellen, dass so ein 'dirty-bit' auch im GPU-Bereich existiert, als Strategie, um z.B. nicht benötigte Textur-/Geometrie-/Shaderdaten aus dem VRAM zu entfernen.

Ein mögliches, fiktives Beispiel, Oblivion:

Es werden 200MiB an Daten, Texturen, Shader, etc. in den VRAM geladen. Diese enthalten die benötigten Daten der aktuellen Szene, ich befinde mich am Anfang eines Waldes. Ich entscheide mich aber nun eben nicht in den Wald zu gehen (vorsorglich liegen eben diese Daten auch im VRAM), sondern in die Höhle um dem Goblin eines auf die fiese Mütze zu geben. Nun sind in der Höhle Shader für den Wald und Texturen für Blätter aber reichlich unpassend ;) weswegen das 'diry-bit' in den Speicherseiten den I/O Controllern mitteilt, welche Speicherseiten (und damit welche Daten) im VRAM "genutzt" wurden (z.B. allgemeine Shader, allgemeine Daten) und welche nicht mehr genutzt werden, also nicht 'dirty' sind, d.h. bei denen das 'dirty-bit' durch das ein- oder mehrmalige Abrufen dieses Speicherbereichs nicht gesetzt wurde, da die Pages keine für die relevante Szene benötigten Informationen enthielten. Die Frage, die sich nun stellen würde ist, welche Controller der GPU das 'dirty-bits' auswerten. Wenn diese Auswertung durch die Adressierer erfolgen würde, würde bei einer fehlerhaften Adressberechnung das 'dirty-bit', also der Hinweis Teile des VRAMs wieder leeren zu können, auf einer 640/320 GTS schlicht nicht erfolgen, da die Adressberechnungen durch den Bug immer noch von 768 MiB ausgehen. Stattdessen würde der Chip nicht erkennen, dass sein lokaler RAM voll ist und versuchen von Adressen zu lesen, die im VRAM nicht mehr existieren, sondern dann (durch Memory-Mapping) im vergleichsweise langsamen RAM, angesprochen über den PEG, liegen würden.

AMC

[kahlchen]

@AMC

die erste Theorie finde ich besser :)

Bei der Zweiten wären doch folgendes das Problem:
Der VRAM-Bug tritt ja nur auf 8800 auf... warum nicht auf den kleineren 8er-Karten?
Und da er ja nicht auf den kleineren Karten exisitiert, einfach bei denen gucken wie es (z.B. 8600) geregelt ist und Problem beheben.

[Der_Korken]

Der VRAM-Bug tritt ja nur auf 8800 auf... warum nicht auf den kleineren 8er-Karten?
Und da er ja nicht auf den kleineren Karten exisitiert, einfach bei denen gucken wie es (z.B. 8600) geregelt ist und Problem beheben.

Ich weiß zwar jetzt nicht mehr, in welchem Thread es stand, aber ich meine mich zu erinnern, dass auch Besitzer der 8600 an den Folgen des VRAM-Bugs (oder "VRAM-Verhalten :D) litten. Jedenfalls sind wir in diesem Thread bisher davon ausgegangen, dass es so ist.

[kahlchen]

Ich weiß zwar jetzt nicht mehr, in welchem Thread es stand, aber ich meine mich zu erinnern, dass auch Besitzer der 8600 an den Folgen des VRAM-Bugs (oder "VRAM-Verhalten :D) litten. Jedenfalls sind wir in diesem Thread bisher davon ausgegangen, dass es so ist.

Ah ok sry, hatte ich wohl überlesen.

[AMC]

Bei der Zweiten wären doch folgendes das Problem: Der VRAM-Bug tritt ja nur auf 8800 auf... warum nicht auf den kleineren 8er-Karten?

Ähm, er tritt auf den kleinen G80 auf! Schau Dir mal das Review auf THG noch mal an. Zumindest auf den 8600ern wird davon berichtet.

AMC

P.S. LOL! Sorry, hatte nicht gesehen, dass es schon von Der_Korken geschrieben wurde, vergiss meinen Beitrag. ;)

[AMC]

@AMC

die erste Theorie finde ich besser :)

So ganz theoretisch ist das übrigens nicht, denn das der Speicher nicht geleert wird, ist ja nun leider Fakt. Im übrigen sind das nicht zwei komplett verschiedene Ansätze, sie überschneiden, bzw. ergänzen sich halt zum Teil.
Was es auch immer ist, es ist anscheinend nichts, dass sich kurzfristig lösen läßt. Es würde mich aber auch nicht wundern, wenn nVidia auch gar kein so großes Interesse an einer Lösung des Problems hat, da die meisten Reviews ja ein sehr gutes Bild der 320er GTS vermitteln (alleine dadurch, das oftmals nicht lange genug getestet wird, um den Bug zu erzeugen) und die Performance in vielen Fällen ja auch dauerhaft über der einer XT/Pro liegt, vor allem mit AA/AF und bis in eine, je nach Spiel verschieden hohe Auflösungsstufe. Aber ich bin trotzdem hoffnungsvoll, denn der nächste finale und offizielle Treiber soll ja einen Fix bringen. Was mir dabei nur nicht ganz schmeckt: der 163.44 brachte durch andere Verbesserungen ja schon enorme Geschwindigkeitssteigerungen auf der kleinen GTS: Was ist nun, wenn nV hier den dreckigen Weg geht und den Bug als solchen gar nicht behebt, sondern durch andere Tweaks und Veränderungen (siehe 163.44) die Leistung anhebt. Gut, den Nutzern kann es herzlich egal sein, woher die Leistungssteigerung kommt, sofern sie nicht mit "unlauteren" Tricks einher geht. Möglicherweise ist sich nV aber bewußt, dass, so sollten meine Vermutungen stimmen, eine schnelle einfache Lösung gar nicht möglich ist und man nach einem anderen Weg sucht, die Leistung zu erhöhen.

AMC

[kahlchen]

Also ich bin auf jeden Fall sehr überzeugt davon, dass nVidia dieses Problem schon sehr sehr lange kennt und auch daran arbeitet (G80 ist ja schon lange auf dem Markt). Aber recht hast du, wenn die 2900XT stärker gewesen wäre, hätte man bei nVidia mit Sicherheit auch mehr Zeit / Aufwand in die Lösung investiert.

Aber was meinst du mir anderen Tweaks / Veränderungen? Meinst du die tollen "Optimierungen", die ATI / nVidia so oft benutzen?

[AMC]

Aber was meinst du mir anderen Tweaks / Veränderungen? Meinst du die tollen "Optimierungen", die ATI / nVidia so oft benutzen?

Nein. Beim 163.44 haben sie z.B. laut CB den Kompressionsalgorithmus für Daten (imVRAM) geändert, sowie die Texturverwaltung verbessert, daher auch die Leistungssteigerungen in Stalker und CoH/CoD2. Quelle (http://www.computerbase.de/news/hardware/grafikkarten/nvidia/2007/august/forceware_16344_vram-bug_g8x/).

Ich erwarte hier keine Verschlimmbesserungen, könnte mir aber vorstellen, dass sie, statt den eigentlichen Fehler zu beheben, andere Wege der Leistungssteigerungen finden, wie auch immer die aussehen mögen. Z.B. spezielle Anpassungen im Treiber auf die kleine GTS, mit eigenen, extra dafür entwickelten Cachingstrategien. Dies würde dann Sinn ergeben, wenn ein solcher Fix einfacher zu bewerkstelligen ist, als die Lösung des "Bugs" direkt.

Dem User kann das natürlich egal sein, Hauptsache, die Leistung steigt noch weiter.

AMC

P.S. Ich hatte heute die Gelegenheit mit einer GTS 320 WiC auf meinem eigenen Rechner live zu sehen. 1600*1200 / 2AA / 16 AF waren absolut kein Problem. Interessanterweise stieg die Framerate in dem eingebauten Benchmark nur leicht an, als ich die Auflösung auf 1280 und 1024 herunterstellte, ergo: das Spiel scheint fast völlig an der CPU zu hängen. Ok, die ist mit 4 Ghz C2D auch nicht unbedingt mid-end. ;D (3.2 reichten aber auch völlig aus...)

[Gast]

Hallo an alle Spezialisten,
ich lese hier oft und gerne mit und habe schon manche nützliche Anregung erhalten, dafür erst mal danke.
Nun zu meiner Frage, in einem anderen Forum wurde behauptet dass dieser VRAM-Bug nur unter XP und nicht unter Vista auftritt.
Wie ist Euere Erfahrung?

[BeetleatWar1977]

Hier gehts zum Thread VRAM-Bug http://www.forum-3dcenter.org/vbulletin/showthread.php?t=383594

ab Seite 8 wird interressant ;)

[Gast]

Hier gehts zum Thread VRAM-Bug http://www.forum-3dcenter.org/vbulletin/showthread.php?t=383594

ab Seite 8 wird interressant ;)

Herzlichen Dank, jetzt bin ich um Einiges schlauer