PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : Zusammenhang CPU/GPU


Hänschen
2003-03-24, 19:41:54
Hi Folks,

hab mal ne Frage!

Weil GTA3 auf meiner G3 nicht so richtig lief, habe ich mir kurz vor Weihnachten eine kl. 9700er geschenkt.

GTA3 läuft jetzt schon recht ordentlich. Aber, nur bei einer Auflösung von 1024x768x16 kommt ein bischen NFS-Feeling auf. Sobald ich AA aktiviere od. mit der Auflösung ein bischen hochgehe, brechen die Frameraten ein. Auch wenn ich die Farbtiefe auf 32Bit setze gehen die Frameraten merklich herunter.

So als Laie würde ich sagen, da ist zu wenig Speicherbandbreite vorhanden. Aber kann das bei ner 9700er sein? Und das schon bei 1200x1024x16.

Ich kann mir auch folgendes vorstellen:

Höhere Auflösung od. AA benötigen auch mehr CPU Power.

Mein System ist eigentl. für ne 9700er schon sehr "leistungsschwach".
XP1600 - KT266a - 512 DDR CL2.

Gibt es einen Zusammenhang zwischen Auflösung und CPU bzw. AA u. CPU?
Bekomme dazu unterschiedliche Aussagen:

- einige sagen ja, es gibt einen Zusammenhang
- andere wiederum nein

Deshalb möchte ich hiermit die Frage an Euch weiter reichen.

Thx

mapel110
2003-03-24, 19:53:09
AA schlägt nur auf die graka !
Auflösung auch !

dein prozzi ist etwas schwach für heutige verhältnisse.

Hänschen
2003-03-24, 20:06:59
Du meinst also, es liegt an der Graka?

Lt. Fraps habe ich, wenn ich mit der Stoßstangenkamera fahre, bei 1024x768x16 zwischen 25-67 Frames. Ab 60 Frames ist scho sehr schön.

Bei 1600x1200x16 hab ich zwischen 15-40 Frames. Wo bei es im Schnitt nur so 20 Frames sind = unspielbar.

Ich dachte gerade bei hohen Auflösungen punktet die Karte - was sie auch bei den anderen Games macht.

Wie schaut es denn bei Dir aus? GTA3 gezockt?

Aquaschaf
2003-03-24, 22:25:32
GTA3 ist meiner meinung nach recht schlecht auf den pc portiert , soweit ich weiß läufts eigentlich nirgendwo immer 100% flüssig .
Auf meinem System (XP2100 ,512MB PC2100, 9700 Pro ) läufts auf 1280x1024 32bit 8xAF annehmbar , zwischen 50 und 20fps , jedenfalls ist es gut spielbar .

mapel110
2003-03-24, 22:30:49
Originally posted by Hänschen

Wie schaut es denn bei Dir aus? GTA3 gezockt?

jup, allerdings noch auf alten system. athlon c 1400 mhz, 512 mb sd-ram und radeon 8500. lief okay, hier und da mal ein ruckler, aber das ist bei dem game normal, wie aquaschaf schon sagte.

Jasch
2003-03-25, 11:49:33
und unbedingt 32bit einstellen die neuren treiber sind alle darauf optimiert normalerweise solltest du zw. 16. und 32 bit keinen geschw. unterschied merken im gegenteil

Hänschen
2003-03-25, 20:41:47
Danke für Eure Antworten.

Hab mal meinen xp1600 von 133 Mhz auf 100 Mhz FSB runtergetaktet und a bisserl mit fraps gemessen.

Auflösung 1600x1200x32

Neues Spiel gestartet und erste Ansicht:

133 Mhz = 38 Frames
100 Mhz = 30 Frames

Ins Autoeingestiegen u. auf Stoßstangenkamera gewechselt:

133 Mhz = 45 Frames
100 Mhz = 35 Frames

Oops, was vergessen! Muss noch in 1024x768x32 vergleichen....

Hänschen
2003-03-25, 20:56:39
So bei 1024x768x32

Erste Ansicht:

133 Mhz = 68 Frames
100 Mhz = 55 Frames

Stoßstange:

133 Mhz = 65 Frames
100 Mhz = 55 Frames


Oha, das Bild zeigt, dass hier eine Abhängigkeit zwischen Systemleistung u. Auflösung anscheinend vorhanden ist.

Jemand ne Erklärung?

Börk
2003-03-25, 21:08:27
Originally posted by Hänschen
Jemand ne Erklärung?
Anscheinend limitier hier die graka ;)
Das spiel ist afaik sehr schlecht importiert, da kann es sein, dass selbst ne 9700er nen 1700+ ausbremst.
Versuchs aber trotzdem mal lieber mit AA vielleicht läufts dann smoother als in 1600.
2xAA sollten auf jeden fall drin sein...

Hänschen
2003-03-25, 21:30:56
Wenn die Graka so stark limitieren würde, dürfte ich keine 20% Unterschied haben. Diese 20% entsprechen in etwa der Reduzierung der Systemleistung - von 133 Mhz auf 100Mhz FSB.

Somit gibt es anscheinend einen Zusammenhang zwischen Systemleistung, Auflösung und Graka. Nur die Beziehung Graka - Auflösung sehe ich an meinem pseudo Test nicht.

Aquaschaf
2003-03-25, 21:56:57
deine benchmarkwerte beweisen doch nicht das der Performanceverlust bei höheren Auflösungen mit der CPU Leistung etwas zu tun hätte

mapel110
2003-03-25, 22:10:56
Originally posted by Aquaschaf
deine benchmarkwerte beweisen doch nicht das der Performanceverlust bei höheren Auflösungen mit der CPU Leistung etwas zu tun hätte

eben. wenn du eine höhere auflösung einstellst, dann geht das immer nur auf die graka, genau wie AA und AF !

Demirug
2003-03-25, 22:15:16
Beim Rendern von 3d Grafik gibt es primär 3 Operationsebenen:

1. Object:
Testen ob das Object sichtbar ist
Rendereinstellungen (Texturen, Shader, ...) für diese Object übertragen
....
Anstossen des Renders über die GrafikAPI (OpenGL oder D3D)

2. Vertex
Berechnungen auf Vertexebene

3. Pixel/Fragment
Berechnen der Pixel/Fragmentfarbe mit dem Shaderprogramm und den Texturen.

Punkt 3 wird immer von der Grafikkarte durchgeführt

Punkt 1 wird derzeit immer noch vollständig von der CPU durchgeführt.

Punkt 2 wird abhängig vom Grafikchip/Engine auf der CPU, der GPU oder im Teamwork durchgeführt.

Wenn die CPU also zu schwach ist bekommt man einfach nicht genügend Objekte bearbeitet und zur Grafikkarte durchgeschoben. Dafür kann man dann bei nahezu gleichbleibender Framerate die Pixelqualität (AA/AF) erhöhen bis die Grafikkarte zum engpass wird.

Ist die Grafikkarte zu schwach wirkt sich das ändern der Pixelqualität sofort auf die Framerate aus.

Wie sich änderungen am Detailgrad (Verticen) auswirkt hängt davon ab wie diese arbeiten zwichen CPU und GPU verteilt wurde.

MadManniMan
2003-03-25, 22:40:04
nun, in der unreal-engine-bild aus unreal 1 zeiten gabs nen cpu-occlusion-check, der mit zunehmender auflösung mehr cpu gefressen hat -> vielleicht bei gta3 genauso?

aths
2003-03-25, 23:10:20
Originally posted by mapel110
AA schlägt nur auf die graka !
Auflösung auch ! Stimmt nicht ganz. Dinge wie geometrisches LOD und folgende Transformierungs-Arbeits usw. fressen mit steigener Auflösung mehr CPU-Zeit.

MadManniMan
2003-03-25, 23:13:05
Originally posted by aths
geometrisches LOD

*zustimm*

wer mal sacrifice wireframes gesehen hat, wird das glauben...

BlackArchon
2003-03-26, 12:52:06
Sacrifice... erinner mich nicht daran. Gibt es überhaupt ein System, bei dem dieses Spiel (mit max. Details) in großen Kämpfen flüssig läuft? Damals hab ich das auf nem 800er Duron mit Voodoo5 angefangen zu spielen, da hatte ich das Ruckeln auf mein System geschoben. Jetzt mit XP 2400+ und GF4 Ti4200 ist es zwar besser, aber in Massenschlachten immer noch etwas ruckelig. Und das für ein Spiel, welches 1999 rauskam. :bonk:

MadManniMan
2003-03-26, 13:26:19
Originally posted by BlackArchon
1999

wuss? :| eigentlich nennt man das jahr offiziel 2001

BlackArchon
2003-03-26, 17:27:36
Originally posted by MadManniMan
wuss? :| eigentlich nennt man das jahr offiziel 2001 Öhm, ich wollte dich nur mal testen. :stareup:

Hier steht als Erscheinungstermin 1.12.2000: http://www.pcgames.de/?product_id=16036

Also 2000? Ist das ein Kompromiss? :D

MadManniMan
2003-03-26, 17:35:39
Originally posted by BlackArchon
Also 2000? Ist das ein Kompromiss? :D

:D

...aber man muß schon zugeben, daß das spiel auch heute noch konkurrenzfähige optik bietet! ?-)

Hänschen
2003-03-26, 20:26:09
Originally posted by Aquaschaf
deine benchmarkwerte beweisen doch nicht das der Performanceverlust bei höheren Auflösungen mit der CPU Leistung etwas zu tun hätte

Denke doch schon:

Wenn bei der ersten Ansicht bei 1024x768x32 bei einem FSB von 100 MHz
das System Daten für 55 Frames zur Graka schickt und die Graka ausschliesslich der Flaschenhals wäre, müssten bei der max Auflösung die gleichen Frameraten rauskommen. Aber:

1600x1200x32

100 MHz = 30 Frames
133 MHz = 38 Frames

Dies dürfte ja nicht sein, da ja bei 1024x768x32 und FSB von 100 MHz ja die Systemleistung für 55 Frames ausreichend war.

Hänschen
2003-03-26, 20:43:55
Originally posted by Demirug
Beim Rendern von 3d Grafik gibt es primär 3 Operationsebenen:

1. Object:
Testen ob das Object sichtbar ist
Rendereinstellungen (Texturen, Shader, ...) für diese Object übertragen
....
Anstossen des Renders über die GrafikAPI (OpenGL oder D3D)

2. Vertex
Berechnungen auf Vertexebene

3. Pixel/Fragment
Berechnen der Pixel/Fragmentfarbe mit dem Shaderprogramm und den Texturen.

Punkt 3 wird immer von der Grafikkarte durchgeführt

Punkt 1 wird derzeit immer noch vollständig von der CPU durchgeführt.

Punkt 2 wird abhängig vom Grafikchip/Engine auf der CPU, der GPU oder im Teamwork durchgeführt.

Wenn die CPU also zu schwach ist bekommt man einfach nicht genügend Objekte bearbeitet und zur Grafikkarte durchgeschoben. Dafür kann man dann bei nahezu gleichbleibender Framerate die Pixelqualität (AA/AF) erhöhen bis die Grafikkarte zum engpass wird.

Ist die Grafikkarte zu schwach wirkt sich das ändern der Pixelqualität sofort auf die Framerate aus.

Wie sich änderungen am Detailgrad (Verticen) auswirkt hängt davon ab wie diese arbeiten zwichen CPU und GPU verteilt wurde.


Äh was??

Ich glaub, ich hab ne gute Ahnung - aber nicht mehr -, was Du geschrieben hast.

UT2k3 verhält sich in etwa auch so. Da bei meinem XP1600 hier das Game klar Prozessor limiert ist, hab ich unter Zuschaltung von 4 AA keinen großen Geschwindigkeitsverlust. Aber es sind doch 10% bei einer Auflösung von 1024x32.

BM 52 ohne AA
46 mit4x AA

Analog dazu AA aus und dafür ne höhere Auflösung. Die höhere Auflösung 1280x1024 bekomme ich auch nicht for free. Hier hab ich auch nen Frame Abschlag.

Demirug
2003-03-26, 20:49:54
Das könnte ein nebeneffekt eines LOD Verfahrens sein. Wenn man die Auflösung erhöht erreichen Objekte früher die Schwelle an der auf eine bessere LOS-Stuffe geschaltet werden muss. In Abhängigkeit davon wie die Engine programmiert ist entsteht dadurch mehr arbeit auf Objektebene und eventuel auch auf der Vertexebene für die CPU.

Die Auswirkung der Auflösung auf die CPU Belastung hängt also stark davon ab in wie weit die Verfahren zum bestimmen von sichtabren Objekten auf der Bildschirmauflösung aufbauen oder vollkommen unabhängig davon sind.

MadManniMan
2003-03-26, 20:53:47
Originally posted by Demirug
Die Auswirkung der Auflösung auf die CPU Belastung hängt also stark davon ab in wie weit die Verfahren zum bestimmen von sichtabren Objekten auf der Bildschirmauflösung aufbauen oder vollkommen unabhängig davon sind.

jop! insbesondere bei outdoor-engines afaik ziemlich aufwendig

Demirug
2003-03-26, 20:56:27
Originally posted by Hänschen



Äh was??

Ich glaub, ich hab ne gute Ahnung - aber nicht mehr -, was Du geschrieben hast.

UT2k3 verhält sich in etwa auch so. Da bei meinem XP1600 hier das Game klar Prozessor limiert ist, hab ich unter Zuschaltung von 4 AA keinen großen Geschwindigkeitsverlust. Aber es sind doch 10% bei einer Auflösung von 1024x32.

BM 52 ohne AA
46 mit4x AA

Analog dazu AA aus und dafür ne höhere Auflösung. Die höhere Auflösung 1280x1024 bekomme ich auch nicht for free. Hier hab ich auch nen Frame Abschlag.

Willkommen in der wunderbaren Welt der Grafikkartenflaschenhälse.

Deswegen habe ich ja auch "nahezu" geschrieben weil sich durch das verändern von AA/Auflösung/AF zu leichten verschiebungen bei den Flaschenhälsen in der Grafikkarte kommt. So führt zum Beispiel AA dazu das es immer mal wieder kurz zu einem Bandbreitenengpass kommen kann der vorher nicht da war. Durch diesen Engpass verliert man dann FPS.

Hänschen
2003-03-26, 21:10:25
Originally posted by Demirug
Das könnte ein nebeneffekt eines LOD Verfahrens sein. Wenn man die Auflösung erhöht erreichen Objekte früher die Schwelle an der auf eine bessere LOS-Stuffe geschaltet werden muss. In Abhängigkeit davon wie die Engine programmiert ist entsteht dadurch mehr arbeit auf Objektebene und eventuel auch auf der Vertexebene für die CPU.

Die Auswirkung der Auflösung auf die CPU Belastung hängt also stark davon ab in wie weit die Verfahren zum bestimmen von sichtabren Objekten auf der Bildschirmauflösung aufbauen oder vollkommen unabhängig davon sind.

Thx,

kleines Fazit:

die Pauschalaussage, höhere Auflösungen gehen nur zu Lasten der Graka ist nur bedingt richtig. Je nach Anwendung hat es auch einen kl. od. grösseren Einfluss auf die Gesamtleistung.

Das entspricht schon eher meiner Ahnung von dem Zusammenspiel der Komponenten.

Aquaschaf
2003-03-26, 21:14:07
ich würd sagen , GTA3 ist einfach eine ausnahme ;)
es gibt keinen ersichtlichen grund warum so ein spiel , welches im grunde nichts besonders grafik oder cpu intensives zu tun scheint auf aktuellen kisten so schlecht läuft .
Aber das ist so ne Sache mit Spielen die irgendwie von der PS2 auf den PC "portiert" werden , die PS2 hat ja eine vollkommen andere Architektur , und das erklärt meiner ansicht nach das ganze .

Hänschen
2003-03-26, 21:51:34
Originally posted by Aquaschaf
ich würd sagen , GTA3 ist einfach eine ausnahme ;)
es gibt keinen ersichtlichen grund warum so ein spiel , welches im grunde nichts besonders grafik oder cpu intensives zu tun scheint auf aktuellen kisten so schlecht läuft .
Aber das ist so ne Sache mit Spielen die irgendwie von der PS2 auf den PC "portiert" werden , die PS2 hat ja eine vollkommen andere Architektur , und das erklärt meiner ansicht nach das ganze .

Ja, sehe ich auch so. Aber besser schlecht konvertiert als nicht für den PC herausgebracht. Na ja, mal sehen wie Vice City wird. Vielleicht hat ja Rockstar dazu gelernt.

Aquaschaf
2003-03-26, 22:11:36
hoffe ich auch :)

zeckensack
2003-03-27, 09:19:37
Ich muß jetzt mal motzen :nono:

*motz* @ Demi :D

Es ist bei 'timedemos' eben nicht durch die Bank eine CPU- oder Grafiklimitierung beobachtbar, weil diese Dinger aus einer Abfolge unterschiedlicher Frames bestehen.

Ich behaupte, für ein einzelnes Frame kann man immer entweder CPU- oder Grakalimitierung feststellen.

... wobei man CPU-Limitierung vielleicht besser mit 'Rest-System-Limitierung' oder sowas umschreiben sollte, denn dort spielen auch Chipsatz, Speicher, Sounkarte und ähnliches mit hinein :|

PS: aus eigener Erfahrung finde ich Grakalimitierung wesentlich angenehmer als CPU-Limitierung. Radeon7200 auf XP1800+ ist schon irgendwie smoother als 'ne Radeon8500LE auf Duron 1.2GHz. Die durchschnittlichen fps sind zwar viel niedriger, dafür schwankt's nicht so stark.

Demirug
2003-03-27, 10:11:04
Originally posted by zeckensack
Ich muß jetzt mal motzen :nono:

*motz* @ Demi :D

Es ist bei 'timedemos' eben nicht durch die Bank eine CPU- oder Grafiklimitierung beobachtbar, weil diese Dinger aus einer Abfolge unterschiedlicher Frames bestehen.

Ich behaupte, für ein einzelnes Frame kann man immer entweder CPU- oder Grakalimitierung feststellen.

... wobei man CPU-Limitierung vielleicht besser mit 'Rest-System-Limitierung' oder sowas umschreiben sollte, denn dort spielen auch Chipsatz, Speicher, Sounkarte und ähnliches mit hinein :|

PS: aus eigener Erfahrung finde ich Grakalimitierung wesentlich angenehmer als CPU-Limitierung. Radeon7200 auf XP1800+ ist schon irgendwie smoother als 'ne Radeon8500LE auf Duron 1.2GHz. Die durchschnittlichen fps sind zwar viel niedriger, dafür schwankt's nicht so stark.

Dann motz doch. OK hast du ja schon getan :D

Theoretisch gebe ich dir recht. Die Daten eines Frames brauchen auf der CPU x ms bis sie durch die Engine und den Treiber für die Grafikkarte aufbereitet sind. Die Grafikkarte braucht dann abhängig von AA/AF und Auflösung y ms bis die Daten in ein Bild umgewandelt sind.

x > y -> CPU limitiert
x < y -> GPU limitiert
x = y -> Good Job

Also genau das was du gesagt hast. Limitierung pro Frame

Nur dürften wir das ganze in der Praxsis wirklich auf Framebasis betrachten? Wohl kaum, den die Prerender Buffer führen ja dazu das man die Summe von mehrern Frames betrachten muss.

Trotzdem kann es natürlich wie du schon gesagt hast auch in einem sehr CPU limitierten Spiel auch mal Phasen geben in denen die Grafikkarte limitiert. Wenn man die Vielzahl an Messungen bedenkt die während eines Durchlaufs gemacht werden muss nur ein Wert der am Ende herauskommt ja zwangsläufig sehr stark gemittelt sein. Aus diesem Grund bin ich ja eigentlich ein Freund von Benchmarks die eine Kurve mit dem Verlauf der FPS rauswerfen. Dort sieht man viel besser ob die höhrer Durchschnitts FPS nun daher kommt das die gesammte kurve sich nach oben verschoben hat oder es sich lediglich um kurze hohe Peaks handelt aber die Grundlinie die selbe ist.

Aber gegen eine CPU limiterung kann der Endkunde ausser dem Kaufen einer schnelleren CPU sowieso nichts machen. Und was der Entwickler dagegen tun soll haben wir ja schon in einem anderen Thread behandelt.

MadManniMan
2003-03-27, 16:08:55
Originally posted by Demirug
die Prerender Buffer führen ja dazu das man die Summe von mehrern Frames betrachten muss

was ist eigentlich dieser ominöse prerender buffer? :|

Demirug
2003-03-27, 16:58:59
Originally posted by MadManniMan


was ist eigentlich dieser ominöse prerender buffer? :|

Der primäre Datenaustausch zwischen der CPU und der GPU erfolgt über einen Komando und Datenbuffer. Der Treiber schreibt dort Daten und Kommandos hinein und der Grafikchip holt sie dort wieder heraus und führt sie aus. Hat man nun die letze Anweisung eines Frames in den Buffer geschrieben ist der Grafikchip zu diesem Zeitpunkt natürlich noch nicht fertig mit diesem Frame. Um jetzt aber nicht unnötig CPU-Zyklen mit dem warten auf die Grafikkarte zu verschwenden teilt der Treiber der API mit das der Frame eigentlich fertig ist und das man schon mal mit dem Anweisunge für den nächsten Frame anfangen kann. Hat man nun Situationen in denen die Grafikkarte besonders stark limitiert könnte sich im Buffer natürlich viele Frames aufstauen. Um das zu verhindern gibt es ein Prerenderlimit. Diese sagt aus wie viele Frames im Buffer abgelegt sein dürfen bevor der Treiber schluss sagt und die Engine so blockiert das sie keine weiteren Frames mehr übergeben kann.

Da im den Buffer also auch schon Daten und Kommandos für mehrer frames die als nächstes folgen gespeichert sein können spricht man auch von einem prerender buffer.

Der Vorteil dieser Methode ist das die CPU besser ausgelastet wird. Der Nachteil ist das zwischen dem Zustand den man gerade sieht und dem Zustand von dem die Engine glaubt das man in sieht ein unterschied besteht und dieser ist um so grosser je weiter der Grafikchip der CPU hinterherhinkt.

MadManniMan
2003-03-27, 17:03:34
Originally posted by Demirug
Der Vorteil dieser Methode ist das die CPU besser ausgelastet wird. Der Nachteil ist das zwischen dem Zustand den man gerade sieht und dem Zustand von dem die Engine glaubt das man in sieht ein unterschied besteht und dieser ist um so grosser je weiter der Grafikchip der CPU hinterherhinkt.

die nachteile sprechen gegen eine nutzung, zumindest mich als pickelfettgesicht(TM) sprechen sie nicht an :|