Test Test: Sapphire Radeon HD 4850 1.024 MB

Also ich hatte mal für ein anderes Forum was zusammengeschrieben als es um 4 GB und Windows ging. Ohne Garantie das alles stimmt, vielleicht kennt sich ja jemand aus und korrigiert mich da wo es hakt. ;)
Vielleicht wird ja doch hier und da was klarer. Ich quote mein Zeug mal hier rein, hoffe es ist verständlich. ;)

Brunftzeit als Erklärbär schrieb:
Wer des englischen mächtig ist:

http://www.codinghorror.com/blog/archives/000811.html

XP und Vista 32 sind aus Kompatibilitätsgründen auf 4 GB Adressraum beschränkt.

Als Möglichkeit das zu umgehen kommt PAE (Physical Address Extensions) ins Spiel. Ab dem Pentium Pro wurd das so langsam eingeführt das die CPUs 36 Bit zum adressieren des Speichers haben. Soweit so gut. Natürlich muss auch das Mainboard das Spielchen mitmachen.

Beim virtuellen Speicherlimit von XP und Vista hilt auch PAE nicht weiter. Die Zeiger auf den Speicher damit man die Adressen auch findet sind weiterhin 32 Bit. Dank PAE können zwei oder mehr Prozesse verschiedene 4 GB Speicherbereiche ansprechen. Mit entsprechendem Support durch Windows (AWE) erlaubt PAE einem Prozess sich zusätzlichen Speicher ausserhalb des normalen Adressraums zu greifen und dann teile des zusätzlichen Speichers in den eigenen Adressraum zu schaufeln.

Ist halt noch das Problemchen das der Chipsatz entsprechend das remapen von RAM unterstützen. Gibt da einen entsprechenden Punkt im BIOS.

Weiter im Text. Man hat also 4 GB. Davon sind um die 600 MB als IO-Bereich reserviert (alte Hasen erinnern sich vielleicht an das Spielchen früher mit den 640K -> 1MB und dem reservierten Bereich dazwischen. Ist das gleiche wie damals, ist halt hardwareseitig reserviert da kann Windows nix für. Ist ein x86-Problem). Damit man diesen Bereich nutzen kann muss man also Remaping aktivieren damit diese reservierten Bereiche in den Adressraum oberhalb der 4 GB verschoben werden. Allerdings unterstützt das nicht jeder Chipsatz und es kann auch schon mal zu problemen kommen.

Nun haben die ganz schlauen Leute immer mehr auf dieses PAE gesetzt und ihre 4GB zu nutzen und MS bemerkte eine steigende Zahl von Problemen und blue screens. Diese waren auf Treiberprobleme zurückzuführen da diese oft 64-bit physikalische Adressen nicht korrekt handhaben konnten. Mit XP Service Pack 2 und eben bei Vista wurde daher eingeführt das nur die unteren Bereich des Adressraums genutzt werden. Da hilft auch PAE nicht weiter. Daher diese Grenze bei 3,2 GB rum.

Will man seine vollen 4 Gigabyte nutzen kommt man um ein 64Bit-Betriebssystem nicht herum. Ausserdem muss das Bios bzw. das Mainboard Memory-remapping unterstützen denn auch bei 64 Bit sind die Reservierungen erstmal da und müssen verschoben werden.

Nächster Punkt:
Natürlich muss jeder Speicher der im System ist mit dem 32Bit die verfügbar sind adressiert werden. Also z.B. auch der auf der Grafikkarte, der Cache auf der Festplatte, das bissl Speicher der Soundkarte, etc. Das alles wird reserviert. Bei einer Grafikkarte mit 512 MB werden diese natürlich reserviert, ergo bleibt nur der restliche Adressraum für den System-RAM übrig.

Daneben gibts noch eine vielzahl an anderen Reservierungen. Von den ganz alten im 640k-1MB-Bereich (jaja, der ist auch heut noch reserviert. z.B. für CGA und EGA Grafik deiner Grafikkarte, fällt blos nicht mehr ins Gewicht die paar KB...). Kann jeder auch nachsehen.

siehe: http://www.dansdata.com/images/askdan00015/memmap_full.png

Das sind die ganzen reservierten Bereiche. Was danach noch übrig bleibt, das kann dann der System-RAM haben. 256 für Grafikkarte weg, 256 für Platine weg (in diesem Fall vermutlich die AGP Aperture Size) und noch unzählige kleinere Happen welche die Platine für Datentransfer benötigt.

Der Bereich zwischen 3 und 4 GB ist voll mit Reservierungen. Daher geht da viel davon weg und daher machen normalerweise mehr als 3 GB RAM in einem 32Bit Windows keinen großen Sinn.
 
Zuletzt bearbeitet:
wow vielen dank für die erklärung!

soweit ich das jetzt verstanden habe, hat man auch mit einer 1gb-vram-graka seine vollen 2 gb ram, da die 2 gb ram+1gbvram+der rest die 4 gb, die das 32 bit windows adressieren kann, nicht übersteigen.

ist das so korrekt?

mfG
 
Okay vielen Dank für die Diskussion Leute. Ich will noch mal kurz zusammenfassen:

2x2GB - Kits ist die einzige Alternative wenn man den vollen Adressraum unter Vista/XP 32Bit nutzen möchte, da ja auch die 1024MB der Graka auf dem physikalischen Adressbereichs des Systems adressiert werden müssen, von daher gilt die Regel: SyS-RAM (~3.3GB) - VRAM (1GB) = nutzbarer Restspeicher (2.3GB). Wenn man dann noch den REST(XP/Vista & Co so 500/700MB) abzieht bleibt nicht so viel übrig für die hungrigen Mäuler :D die gestopft werden wollen, wenn man hohe Auflösungen spielen möchte. 2GB Adressraum pro Programm (Spiel) kann von XP/Vista maximal zugewiesen werden. (Daraus zieh ich dann meine Schlussfolgerung: Wer kein XP/Vista 64Bit fährt braucht auch keinen 1024 MB Speicher in der Graka, da es sonst zum Engpass für den physakilischen Adressspeicher für das Spiel selbst kommt, fährt man wohl besser mit einer HD 4870 512MB DDR5 Karte. Daher möchte ich mich entschuldigen, für meine zuvor getätigte Aussage.

EDIT: Abgesehen davon wird die HD 4870 wohl auch noch zu langsam sein um die 1024 MB optimal zu nutzen, von daher kann man wohl kaum von einem hohen Performancegewinn ausgehen.
 
Zuletzt bearbeitet:
Irgendwie ist der Test unbefriedigend.

Warum? Es fehlt ein Exkurs, der zum Beispiel einen Vergleich zwischen der 512MB under 1024MB Version aufzeigt, wenn man etwa bei Oblivion das Ultra High Texture Pack installiert.
Die Vergangenheit hat gezeigt dass hier bei wenig VRAM die Performance extrem einbricht.

Manch einer mag sagen, ja, aber das ist ja nicht das Spiel im Auslieferungszustand. Stimmt. Aber, die Entwickler optimieren ja für weit verbreitete Hardware, und wenn jeder immer nur bei 512MB VRAM bleibt, werden nie mehr als 512MB VRAM sinnvoll genutzt...
 
Wolfgang schrieb:
Weil wir zu dem Treiber Vergleichswerte haben, deswegen. Bei einem TEst innerhlab derselben Architektur zwischen unterschiedlichen Kartenmodellen spielt der Treiber eh keine Rolle. Zudem entspricht der Catalyst 8.6 Release5 ziemlich genau dem Cat 8.7, so alt ist der also gar nicht.

Es gibt doch schon einige Zeit den 8.8. Habe ihr getestet ob der 8.8 das mehr an VRAM besser unterstützt?
 
Brunftzeit schrieb:
Auch der VRAM der Grafikkarte muss adressiert werden und das macht nicht die Grafikkarte selbst.
Ja und nein. Auch der VRAM der Grafikkarte muss adressiert werden, jedoch trixt der Treiber dazu etwas rum. Es werden immer nur 256 MB adressiert, unabhängig, wie groß der VRAM ist.

Es gibt doch schon einige Zeit den 8.8. Habe ihr getestet ob der 8.8 das mehr an VRAM besser unterstützt?
Warum sollte er? Halte ich für unwahrscheinlich, dass sich da noch etwas ändert? Von ATi kam diesbezüglich auch nichts.
 
@ Wolfgang

Wie schaut es mit dem von einigen anderen und mir angesprochenen Kritikpunkt aus?
Seppuku schrieb:
@ Wolfgang

Man könnte auch die FPS-Werte in Klassen einteilen.
Nur die Minimum-FPS oder die Minimum-FPS mit den Avarage-FPS sind zwar auch nicht total aussagekräft, man könnte aber z.B. angeben, wieviele % der FPS sich z.B unter einem bestimmten Wert befinden.
Natürlich ist das alles auch nicht 100 prozentig, jedoch 1000x besser als nur die Avarage-Frames anzugeben.
Und zu den Nachladerucklern von der Festplatte: Ihr werdet ja sowieso bei den Tests nicht nur einen Durchlauf machen. Von daher wiegt ein Aureißer nicht mehr so schwer oder wenn er denn offensichtlich ist, dass es ein Artefakt in der Messreihe ist, kann die Messreihe auch weggelassen werden (wird in der Wissenschaft ständig so gemacht).

Ich versteh irgendwie nicht so ganz, auf welche Zielgruppe diese Art von Tests zugeschnitten sind. Die Einleitung und die Hintergründe erwecken den Eindruck, dass man an sich schon einen etwas wissenschaftlichen Anspruch stellt, die Auswertung der Daten ist (sofern man überhaupt von einer Auswertung sprechen kann) eher auf Kindergartenniveau!
Es gab ja auch schon Ausnahmen (Grid), die gezeigt haben, was man aus den Messwerten auch herausholen kann.
Ich finde es immer wieder amüsant, wie sehr du dich auf die "nutzlosen" Minimum-FPS einschießt, sobald jemand diese erwähnt. Trotzdem würden selbst die Angabe der Spannweite den Test schon aufwerten (wenn auch diese Angabe sehr fehleranfällig für Ausreißer ist oder gib doch wenigstens die Standardabweichung an)! Mit der aktuellen Darstellung kann jemand, der ernsthaft Interesse an der Auswertung der Ergebnisse hat, nicht ansatzweise zufrieden sein!
Aber wie in dem von mir zitierten Teil ersichtlich wird: Es gibt relativ einfache Möglichkeiten (die ja teilweise auch schon im Grid-Test angewandt wurden), wie man wenigstens "etwas" mehr aus den Daten herausholen könnte...
 
Wolfgang schrieb:
Ja und nein. Auch der VRAM der Grafikkarte muss adressiert werden, jedoch trixt der Treiber dazu etwas rum. Es werden immer nur 256 MB adressiert, unabhängig, wie groß der VRAM ist.

Ah ja? Ok, das war mir noch neu. Darüber hatte ich noch keine Infos gefunden. Thx. ;)

Muss jedenfalls auch nochmal Falcon zustimmen. Die Zielgruppe die Grafikkarten mit extra viel Speicher anspricht sind nicht allein diejenigen welche ihre Spiele im Auslieferungszustand lassen. Es wäre echt schön wenn man hier mal einen Test (mit verschiedenen Grafikkarten die "Extra viel RAM" haben) mit bekannteren Texturmods machen könnte. :)
 
Ich wäre an so einem Test auch sehr interessiert, da ich selber solche Spiele spiele (Sims 2 mit Downloads z. Bsp.).
 
Seppuku schrieb:
@ Wolfgang

Wie schaut es mit dem von einigen anderen und mir angesprochenen Kritikpunkt aus?

Ich finde es immer wieder amüsant, wie sehr du dich auf die "nutzlosen" Minimum-FPS einschießt, sobald jemand diese erwähnt. Trotzdem würden selbst die Angabe der Spannweite den Test schon aufwerten (wenn auch diese Angabe sehr fehleranfällig für Ausreißer ist oder gib doch wenigstens die Standardabweichung an)! Mit der aktuellen Darstellung kann jemand, der ernsthaft Interesse an der Auswertung der Ergebnisse hat, nicht ansatzweise zufrieden sein!
Aber wie in dem von mir zitierten Teil ersichtlich wird: Es gibt relativ einfache Möglichkeiten (die ja teilweise auch schon im Grid-Test angewandt wurden), wie man wenigstens "etwas" mehr aus den Daten herausholen könnte...
Einfach? Einfach war das beim Grid nun wirklich nicht. Alleine die reine Menge an Daten die man da hatte, das war echt schon übel. Und das bei ienem Spiel und nur ein paar Daten. Es wird sich mit dem neuen Benchmarkparcours (when it's done, bevor erste Fragen dazu aufkommen ;)) etwas ändern, aber nein, Min-FPS-Werte werden es nicht werden.
Aber was meinst du mit "teilweise in Grid angewendet"? Noch mehr Infos kann man wohl nicht anbieten.
 
@ Wolfgang

Was hat sich bei der Auswertung genau als schwierig gestaltet?
Mit den entsprechenden Programmen (z.B. GraphPad aber selbst Excel ist da völlig ausreichend) sollte doch die Auswertung kein Problem darstellen (egal wieviele Messwerte man hat).
Wenn einmal die Daten in das ensprechende Programm importiert wurden (das sind ja nur ein paar Klicks) ist der Rest doch auch schnell gemacht.
Oder macht die Darstellung der ausgewerteten Daten im Artikel selbst so viel Arbeit (das kann ich jetzt natürlich nicht beurteilen)?

Mit dem letzten Satz meinte ich, dass es relativ einfach Methoden gibt (wie zum Beispiel die Angabe der Minimum und Maximum-Frames + Avarage Frames wie eben (unteranderem) in dem Grid-Artikel) um mehr als nur die Avarage-Frames als Resultat zu prästentieren und so das Ergebnis ein bisschen aussagekräftiger zu gestalten.
Weitere Beispiele wären die Angabe der Standardabweichung (das dauert keine 2 Minuten in Excel inklusive Datenimport und sie könnte gleich, so wie in wissenschaftlichen Papern üblich, zu den Balken hinzugefügt werden) oder die Angabe, wieviel % der Frames sich z.B. unter einem bestimmten Wert befunden haben. Dazu wäre z.B. eine sinnvolle Einteilung in Klassen auch interessant (wie es z.B. dem integrierten Benchmark von FEAR schon zu sehen war), da sich viele Balken besser vergleichen lassen als viele Kurven.
Es gibt noch viele andere Möglichkeiten, etwas aus einer stupiden Messreihe herauszuholen (aber man muss es ja nicht übertreiben ;))

Welche Darstellung der Daten habt ihr euch für die Zukunft überlegt?
 
In zukünftigen Grafikkartenartikeln (damit meine ich jetzt aber nicht den nächsten, sondern dann wamnn (auch immer) wir auf den modifizierten Benchmarkparcours umsteigen) wird der Haupteil immer noch die gewohnten Average-Werte sein.

Jedoch ist derzeit geplant, dass es einen speziellen Abscnhitt mit einigen wenigen Spielen und einigen wenigen Karten geben wird, der die Ergebnisse genauso handhaben wird wie in dem Grid-Artikel, also Min-, Avg-, Max-FPS sowie ein Verlaufsdiagramm. Somit bieten wir dann eine Kombi aus beiden "Welten" an. Jedoch müssen wir mal schauen, wie sich das effektiv realisieren lässt.
 
Das würde, glaube ich, sehr viele User erfreuen.
Zudem dürften dann auch kritische Speichergrenzen vielleicht eher sichtbar werden.
 
@ Wolfgang

Und was ist jetzt konkret der Punkt, der so extrem viel Arbeit bei einer genaueren Analyse der Daten macht bzw. gemacht hat?

Es spricht ja nichts dagegen, dass der Hauptteil weiterhin aus dem Vergleich der Avarage-Frame-Raten besteht. Diese haben den großen Vorteil der guten Vergleichbarkeit! Ein Wert ist halt einfach leichter zu vergleichen als mehrere Werte bzw. Verlaufsdiagramme.
Könnte man nicht wenigstens die Standardabweichung jedes Mal mit den Durchschnittswerten mit angeben?
Die meisten von euch sind ja Studenten bzw. haben studiert und haben wissenschaftliche Arbeiten gelesen. Von daher wird dir ja die Darstellung von entsprechenden Graphen ja bekannt sein.
Oder einfach noch zusätlich die Angabe, wieviel % der Werte z.B. unter einem Bestimmten wert liegen (sozusagen Einteilung in 2 Klassen. Das würde ich favorisieren, da ja meist entscheidend ist, wie oft die Frames z.B. unter 25 fps fallen).
Das ist wirklich fast kein Mehraufwand (pro Test keine 2 Minuten und eine einzige Zahl ist ja auch schnell in den Artikel eingefügt) und würde wenigstens etwas mehr Informationen über die Daten geben.

Mal ein Beispiel, das ich auf die Schnelle gefunden habe, das zeigt, wo die Grenzen von den Avarage-Frames sind: http://www.pcgameshardware.de/aid,6...839048&article_id=647693&page=1&show=original
Das soll jetzt kein Plädoyer für die Minimum-Frames sein. Jedoch zeigt dieser Test deutlich, wie unsinnig und wenig aussagekräftig nur die Angabe der Avarage Frames ist!
Oder welche Aussage würdest du aus den Ergebnissen nur mit "euren" Avarage-Frames machen können, und welche inklusive der (in diesem Fall) Minimum-Frames?

Auch wenn ihr teilweise einen ausführlichen Teil plant, lasst bitte, bitte die anderen Werte, die keiner so aufwändigen Analyse wie Verlaufsdiagramme unterzogen werden, nicht wieder so verkommen wie bisher, sondern wertet diese durch die Angabe von zumindest einem zusätzlichen Parameter auf ;).
 
Zu deinem letzten Satz: Welchen zusätzlichen Parameter meinst du dann?

Und nun zu deinem oberen Teil: Das ganze lässt sich mit dem aktuellen Testparcours fast nie machen. Das hat aber nicht den Grund, dass wir das nicht wollen, sondern das wir fast immer nur die Momentsituation in einem Spiel zeigen und nie den FPS-Bereich über einen längeren Zeitraum. Sprich, wir stehen meistens an einer STelle und bewegen uns nicht. Zwar nicht immer, aber meistens. Und das ist einfach deswegen so, da ich es aus gründen der Vergleichbarkeit als etwas kritisch ansehe, in der "Gegen herum zu spatzieren". Da kann sich einfach ganz schnell ganz viel ändern. In dem neuen Benchparcours wird sich das dann teilweise aber logischerweise ändern.
 
Damit meinte ich bestimmte Streuungsparamter wie die Standardabweichung (wobei diese natürlich auch nicht so gut einzelne wenige Ausreißer aussagekräftig einfängt).

Wie macht ihr das dann konkret? Wird ein Savegame geladen und schaut ihr euch ein entsprechendes Szenario eine definierte Zeit an? Wie schauen dann die Frameverteilungen aus? Sind die eher konstant oder weisen die große Streuungen auf?
Ich habe immer gedacht, dass meistens irgendwelche Timedemos zum Einsatz kämen, sofern möglich und dass bei den anderen Spielen ein möglichst konstanter Weg abgeschritten würde.

Ich habe einmal ein Diagramm gemacht, so wie es in meinen Augen nicht viel Arbeit macht und trotzdem aussagekräftiger ist (Bild im Anhang):

Normalerweise würde ich bei einem Test, bei dem nur die Avarage-Frames angegeben sind, bei diesen 3 Karten folgendes Fazit ziehen:
Die Karten bewegen sich im Bereich der Messtoleranz auf dem gleichen Niveau. Es ist egal, welche man nimmt.

Wenn jetzt aber noch die Standardabweichung gegeben ist, fällt das Fazit ein wenig anderes aus:
Von den Durchschnittsframeraten nehmen sich die Karten nicht viel, jedoch ist bei der schnelleren Karte 1 die Standardabweichung geringer und bei der langsamsten Karte 3 höher.
Das zeigt uns also, dass die Karte 3 nicht im Schnitt gleichmäßig minimal langsamer ist als die Karte 1, sondern mit ihrem Werten weiter um den Mittelwert herumspringt.
Die Logik (zumindest meine ;)) würde mich sogar vermuten lassen, dass die höhere Standardabweichung eher durch niedrigere Frame-Raten zustande gekommen ist.
(natürlich könnte es sein, dass die Karte 3 zwar meist niedrigere FPS erreicht und dann durch ein paar höhere Ausreißer den Schnitt wieder annähernd auf das Niveau der Karte 1 bringt und die Standardabweichung eben durch die hohen Ausreißer zustande kommen. Aber das erscheint mir nicht wirklich logisch, da die Testsettings ja so gewählt sind, dass die Karte zu jeder Zeit des Benchmarks genügend zu Rechnen hat (also nicht in den Himmel oder gegen eine Wand geschaut wird)).
In diesem Fall würde die Wahl und Empfehlung ganz klar auf die Grafikkarte 1 fallen!

Ich habe für die Balken einfach 10 verschiedene Messwerte zwischen 20 und 40 genommen und diese dann verzehnfacht.
Bei der Grafikkarte 2 habe ich 5 von den 20er Werten auf 10 gesetzt und bei der Grafikkarte 3 5 der 20er Werte auf 5 gesetzt.
Mir gings nicht darum, ob das realtistisch ist, sondern ob man Ausreißer mit der Standardabweichung zumindest halbwegs bewerten kann.


Aber wie gesagt: Die Standardabweichung ist nur eine von vielen Möglichkeiten!
 

Anhänge

  • Clipboard01.png
    Clipboard01.png
    13,4 KB · Aufrufe: 583
Ah, danke, jetzt weiß ich was du meinst.

Eigentlich eine nette Idee, aber wie bereits gesagt, würde das bei den meisten von uns durchgeführten Benchmarks nicht funktionieren. Und zwar deswegen, da wir uns aus Gründen der Vergleichbarkeit eigentlich nicht in den benchmarks gewegen, sondern uns nur eine, immer dieselbe, Szene anschauen (bei Savegames, die wir mittlerweile zu, ich sage mal 70-80 Prozent, benutzen). Deswegen sind die Framerates sehr konstant.

Im zukünftigen Benchmarkparcours wird das aber etwas anders aussehen und dort wollen wir dann die Benchmark-Darstellung ja auch ändern. Nur bitte ich bis dahin einfach noch für etwas Geduld, wir warten noch auf einige Spielerelease (letztes Release wird wohl Far Cry 2) werden.
 
Zurück
Oben