Ut2003- über 128 Mb Grafikspeicher benötigt?

[RealBierchen]

Guten Morgen !

Ich habe gehört das man für Ut2003 mehr als 128Mb Grafikkartenspeicher braucht (auf UltraHigh Grafiksettings, weil die Maps so groß und texturreich sind (>180Mb).
Da ich Kerninformatik and der Uni-Dortmund studiere und mich mit graphischen Systemen beschaeftige (Opengl,Directx,etc.), kann ich mir das gar nicht vorstellen, da ja die Texturen und Objekte über den Agp-Bus ausgelagert werden und zur Laufzeit (=das was man sieht) über den Backbuffer angezeigt werden...Dadurch sollte man doch Grafikstreams über 128Mb pro Frame selbst bei 64bit Texturen (siehe ID) vermeiden können.

Daher meine Frage, ob dieses Problem nur Epic-Games(UT2003) auftritt ? "Programmierfehler" oder mißverstehe ich da was ?

PS:
Microsoft DirectX 8.0 (C++)
Architectural Overview for Direct3D
There are two programmable sections of the Microsoft® Direct3D® architecture: vertex shaders and pixel shaders. Vertex shaders are invoked prior to vertex assembly and operate on vectors. Pixel shaders are invoked after any DrawPrimitive calls and operate on pixels.
The following simplified diagram illustrates the Direct3D architecture. It is a subset of the architecture, as Direct3D supports eight sets of textures and texture coordinates.

(Sorry,Diagramm missing..)

As shown in this diagram, vertex buffers stream vertex data into the vertex shader. The vertex shader performs geometry operations using the instructions defined by the Direct3DX vertex shader assembler.
The data streamed to the vertex shader does not have to be contained in vertex buffers, but this is the ideal case. After vertex assembly, the assembled vertex data is drawn using DrawPrimitive methods. At this point, each pixel of the drawn primitive is routed to the pixel shader, including its position, color, texture, and texture coordinate. The pixel shader performs pixel operations using the instructions defined by the Direct3DX pixel shader assembler.
The inputs to the pixel processing pixel shader stage include texture surfaces and the associated texture coordinates controlling the sampling of surfaces. The output pixel is routed to the frame buffer.
For more information on the architecture of the programmable sections of the Direct3D, see Vertex Shader Architecture and Pixel Shader Architecture.
For more information on how vertex and pixel shaders fit into the rendering pipeline, see the Direct3D Rendering Pipeline.

[Kai]

Originally posted by RealBierchen
da ja die Texturen und Objekte über den Agp-Bus ausgelagert werden und zur Laufzeit

Soweit ich informiert bin ist gerade das das Problem. Sobald die Texturen nämlich über den AGP-Bus ausgelagert werden, kracht die Performance derbst weg. Das ist aber nicht nur bei Epic-Games so. Ich schiebe den Thread mal da hin wo man Dir helfen kann.

[RealBierchen]

Guten Morgen nochmal !

Ich hab mich nochmal schlau gemacht über den Agp-Bus und bei Agp 8* hat man 2,1 GB/s (4* ca 1GB) Bandbreite zur verfügung. Da UT2003 geradeeinmal >180Mb (von mir aus auch 500Mb)an Texturen und Objecten lädt, müssten diese theoretischen 2.1Gbs doch locker reichen!
Ich hab bei anderen Spieleherstellern nachgeschaut, aber ich bin nicht wirklich fündig geworden.

RealBierchen

PS:

http://www.de.tomshardware.com/graphic/02q4/021008/nv18_nv28-02.html

Aktuelle Computerspiele kommen mit AGP 4x prima zurecht. Selbst mit dem nochmals halb so schnellen AGP 2x laufen viele Grafikkarten kaum langsamer. Die Gründe dafür sind vielfältig. Neben dem Aufbau der Engine spielt auch die Leistung des 3D-Chips auf der Grafikkarte eine große Rolle, denn er muss die Datenmengen schließlich verarbeiten können. Seitens der Kartenhersteller spricht man von immensen Mengen an Texturen und Polygondaten komplexer 3D-Modelle, die über den Bus übertragen werden müssen. Aber ein GeForce4-MX-Chip mit einer Polygonleistung von theoretisch 34 Megatriangles/s wird kaum in der Lage sein, derart große Polygonmodelle oder Texturen darzustellen. Aus diesem Grund kommen derart komplexe Szenen in Computerspielen auch nicht vor. Auch für das Auslagern von Texturen vom Kartenspeicher über den AGP-Bus in den Systemspeicher des Rechners ist AGP 8x keine große Hilfe, denn mit den verfügbaren 2,1 GB/s ist man meilenweit von der Speicherbandbreite auf den Karten selber entfernt. Eine MX440-8x und Ti4200-8x verfügt beispielsweise über eine Speicherbandbreite von 8 GB/s. Die neue Radeon 9700 PRO kann sogar rund 20 GB/s bewältigen. Würde ein Spiel also derart viel Texturen verwenden, das über den AGP ausgelagert wird, resultiert das auch mit AGP 8x noch in einem merklichen Einbruch in der Performance. Da derzeit kaum noch Karten mit weniger als 64 MB Speicher erhältlich sind, tritt dieses Problem selbst bei der Verwendung von speicherhungriger Kantenglättung (FSAA) in aktuellen Spielen praktisch nicht auf – und bei Karten mit 128 MB sowieso nicht. Erst die nächste oder übernächste Generation von echten DirectX-9-Spielen wird 128 MB Speicher überhaupt ausreizen.

[nggalai]

Passt hier wohl besser rein. ;)

*verschieb*

ta,
-Sascha.rb

[Demirug]

RealBierchen,

Texturieren über den AGP ist definitive mit ehrheblichen Leistungseinbrüchen verbunden.

Dafür sind mehrer Faktoren verantwortlich.

1. Bandbreitenunterschiede: aktuelle Grafikkarten haben > 7 GB/s Bandbreite zum lokalen Videomemory aber nur ca 1 (bzw 2) GB/s über den AGP.

2. Zugriffsrechte: Der lokale Videospeicher gehört nur dem Grafikchip. Wird aber über den AGP aus dem Hauptspeicher ausgelessen muss dieser ja immer noch mit der CPU geteilt werden. Die Auswirkung dieses Problem hängt aber stark von der benutzen CPU, Chipsatz und Speicher ab.

3. Latenz: Der Zugriff auf den lokalen Videospeicher verursacht natürlich wesentlich weniger verzögerungen als wenn über den AGP auf den Hauptspeicher zugeriffen werden muss.

Aus diesem Gründen werden Texturen vorzugsweise immer im Lokalen Videospeicher abgelegt. D3D hat als Option einen Resourcemanager welcher versucht alle für einen Frame erforderlichen Texturen in den Lokalen Videospeicher zu verlagern. Das Ergebniss davon ist solange noch alle Daten die für einen Frame benutzt werden in dem Speicher passen in der Regel besser als wenn man über den AGP texturiert. Allerdings neigen D3D Anwendungen bei der Verwendung des Resourcemanager zu etwas stärkeren Schwangungen in der Framerate.

Deine Überlegung bezüglich der 180MB Daten zu der AGP Bandbreite enthält einen kleinen Denkfehler. Du hast vergessen das man ja mehr als einen Frame pro Sekunde haben will. Für jeden Frame fallen im Prinzip zwei Arten von Daten an.

1. Steuerdaten: Diese werden von Treiber erzeugt und sagen dem Chip was er überhaupt tuen soll. Die Datenmenge läst sich schlecht abschätzen da die meisten Hersteller dieses Protokoll nicht offenlegen

2. Content-Daten. Alles was an Geometrie, Texturen usw. nicht vom vorhergehenden Frame im Grafikkartenspeicher ist muss übertragen werden.

[chicki]

naja das speicher interface von ut2k3 ist in jedem fall noch buggy...
habe ne 128mb graka, 512mb ddr ram (ok war auf failsave timings und 266mhz, desweiteren habe ich die cachesize megs noch nicht von 192 auf 256 oder mehr gestellt).
Sobald man sich schnell durch eine grosse map bewegt (translocator + jumppads, irgendwo runterfallen oder einfachrespawnen) droppen die fps massiv (so um 10-20) einfach nur, weil ut2k3 sachen nachläd (sollte ja bei dieser hardware auch ohne gehen)

[RealBierchen]

/**Deine Überlegung bezüglich der 180MB Daten zu der AGP Bandbreite enthält einen kleinen Denkfehler. Du hast vergessen das man ja mehr als einen Frame pro Sekunde haben will. Für jeden Frame fallen im Prinzip zwei Arten von Daten an.
**/


Morgen Demirug,

genau das meine ich ja !
UT2003 braucht theoretisch >180Mbs and Daten um eine Map darstellen zu können, was die Karte nachher daraus macht (zb 50fps*180Mb =9000Mbs=9Gbs)ist dem Leistungpotential der KartenGPU bzw. des Kartenspeichers überlassen. Das ist der Trick, dem man sich bedient, da ja , wie du schon sagtest, die Bandbreite des Agps in keinem Verhaeltnis zur Bandbreite des G-Kartenspeichers steht.
Selbst wenn innerhalb der Sekunde mehrmals (zb 50mal = 50fps ) neue Texturen übertragen werden, werden nur neue (=noch nicht für das Level im Backbuffer befindlichen Daten) Daten "neu" geladen.
Diese Aufgabe erledigt großteils eh DirectX, bzw. sollte spaetestens die Game-Engine berücksichtigen.
(zb theoretisch 2GBs an Daten ergeben 2GB * 25FPS(MIND. ca.25fps (TV))=50Gbs Backbuffer-Daten intern, die die Karte verarbeiten muss + Steuerdaten etc. :]] )

Mfg
RealBierchen

Ps: Ich werde heute mal bei meinem "Graphische Systeme"-Prof nachfragen, vielleicht weiß der mehr !

[Demirug]

Die 180 MB werden ja nicht für jeden Frame gebraucht sondern entsprechen der gesamten Datenmenge für die Map. Die Engine sortiert da für jeden Frame vor dem Rendern schon eine Menge aus. Ansonsten würde ja von der Bandbreite der Grafikkarte nach dem einlessen der Daten nichts mehr übrig bleiben.

Beim Nachladen der Texturen in den Grafikspeicher verliert man an mehreren Stellen Leistung.

1. AGP Bandbreite: Das ist nicht so schlimm da man davon wie du gesagt hast eigentlich genug hat

2. Grafikspeicher Bandbreite: Das ist schon ärgerlicher da man gerade in den AA/AF Modie doch oft am Bandbreitenlimit hängt.

3. Chipzyklen: Das ist das schlimmste überhaupt. Während die Textur in den Grafikspeicher geladen wird muss der Chip warten. Das läst sich unter umständen aber im Treiber durch preloading etwas abmildern.

[zeckensack]

Sorry, aber was ist eigentlich die Frage ???
bzw worauf willst du hinaus ???

Daß es zu Problemen kommt, wenn der Speicher der Graka für Framebuffer+Texturen+Vertexbuffer nicht mehr reicht (auch wenn die Grenze nur knapp überschritten wurde), sollte j eigentlich einleuchten ...

Textur-Swapping ist auch komplizierter als es sich anhört. Es muß ja nicht nur die neue Textur rein, sondern es muß ja auch sichergestellt werden daß keine andere, aktuell benötigte Textur dadurch verdrängt wird, sonst hat man den ganzen Salat ein paar Takte später gleich nochmal.

(Apropos Verdrängen, theoretisch müssen in solchen Fällen auch Texturen von der Graka zurückgelesen werden, in der Praxis wird einfach von allem eine Kopie im System-RAM oder im Pagefile vorgehalten.)
Außerdem kann es schnell zur Fragmentierung des Graka-Speichers kommen.

Das wirklich dumme daran ist, daß D3D und OpenGL eigentlich nur Rasterizing-APIs sind (im Ggs zu richtigen scene graphs). Dadurch fehlt ihnen der nötige Überblick über die Objekte auf dem Schirm. Solche Entscheidungen, welche Texturen wie wichtig sind, können die APIs (und damit die Treiber) deswegen selbst nur unzureichend pseudo-statistisch, oder über application hints treffen.

[betasilie]

Hi Bierchen

Da hast Du ja schon ein paar Gründe weswegen der AGP-Bus von der Bandbreite her kann, aber in der Praxis nicht. Ich meine es gibt bis heute kein Spiel welches ohne drastische Performanceeinbußen den Haupt-Ram für Texturauslagerung benutzen kann.

P.S. War doch ein guter Tip die Frage mal im 3dcenter-Forum zu Posten.

[Demirug]

Originally posted by zeckensack
Das wirklich dumme daran ist, daß D3D und OpenGL eigentlich nur Rasterizing-APIs sind (im Ggs zu richtigen scene graphs). Dadurch fehlt ihnen der nötige Überblick über die Objekte auf dem Schirm. Solche Entscheidungen, welche Texturen wie wichtig sind, können die APIs (und damit die Treiber) deswegen selbst nur unzureichend pseudo-statistisch, oder über application hints treffen.

Bei DX kann man deswegen über dem Resourcemanager jeder Texture (bei anderen Resourcen auch) eine Priorität vergeben. Zudem kann man noch einen Preload hint geben. Damit sagt man der API das man diese Resource bald braucht. Wenn der Speicher aber nicht für alle in einem Frame benötigten Daten ausreicht nützt der Preload Hint aber leider auch nicht viel.

[zeckensack]

Jau.
Unter OpenGL kann jeder Textur eine Priorität zugewiesen werden. Preload oä gibt's nicht, da die Speichertrennung Grafik/System unter GL ziemlich strikt durchgezogen wird.

Genau das meinte ich oben mit "application hints" :)

[Piffan]

Originally posted by chicki
naja das speicher interface von ut2k3 ist in jedem fall noch buggy...
habe ne 128mb graka, 512mb ddr ram (ok war auf failsave timings und 266mhz, desweiteren habe ich die cachesize megs noch nicht von 192 auf 256 oder mehr gestellt).
Sobald man sich schnell durch eine grosse map bewegt (translocator + jumppads, irgendwo runterfallen oder einfachrespawnen) droppen die fps massiv (so um 10-20) einfach nur, weil ut2k3 sachen nachläd (sollte ja bei dieser hardware auch ohne gehen)

Welches Nachladen meinst Du? Aus dem Arbeitsspeicher in die Graka oder von der Festplatte in den Hauptspeicher?

Ich frage aus folgendem Grund: Die Map "December" ist buggy, wenn die Texturen und Worlddetails auf die maximalen Werte stelle und zusätzlich dynamic lights ankreuze, dann ist die Map nicht spielbar. Bei jeder Drehung und Bewegung oder wenn neue Modelle auftauchen, dann ist die Festplatte am Arbeiten. So als ob der Hauptspeicher komplett auf die Swapfile ausgelagert wurde....

Habe auch ne 128er Graka und 512 mb Systemram....

[Kai]

Originally posted by Piffan


Welches Nachladen meinst Du? Aus dem Arbeitsspeicher in die Graka oder von der Festplatte in den Hauptspeicher?

Ich frage aus folgendem Grund: Die Map "December" ist buggy, wenn die Texturen und Worlddetails auf die maximalen Werte stelle und zusätzlich dynamic lights ankreuze, dann ist die Map nicht spielbar. Bei jeder Drehung und Bewegung oder wenn neue Modelle auftauchen, dann ist die Festplatte am Arbeiten. So als ob der Hauptspeicher komplett auf die Swapfile ausgelagert wurde....

Habe auch ne 128er Graka und 512 mb Systemram....

Diese Map hat scheinbar einschlagende Designfehler. In den beiden Basen sitzt an jeder Ecke ein Bereichsportal. Da sieht man gut das man sich Gedanken wie verrückt gemacht haben muss, weil sie nicht richtig lief. Jetzt gebe ich eben diesen Bereichsportalen mal die Schuld, denn immer wenn Du durch so eins läufst, wird nachgeladen, was zum hakeln führt.

Draussen am Boot ist die Performance sowieso im Eimer -> wobei ich aber nicht so ganz kapiere wieso, denn der Overdraw hält sich in Grenzen. Portale können hier zwar keine gesetzt werden, aber das sollte doch schon gehen. Naja, vielleicht bringt's ein Update.

[vogel]

Hehe, "programmer art" :) Joe Wilcox (DrSin) hat CTF-December erstellt.

-- Daniel, Epic Games Inc.

Originally posted by Kai
Diese Map hat scheinbar einschlagende Designfehler.

[Aragon]

Originally posted by zeckensack
Textur-Swapping ist auch komplizierter als es sich anhört. Es muß ja nicht nur die neue Textur rein, sondern es muß ja auch sichergestellt werden daß keine andere, aktuell benötigte Textur dadurch verdrängt wird, sonst hat man den ganzen Salat ein paar Takte später gleich nochmal.


es gibt doch beim AGP zwei Betriebsmodi:
DMA: Direct Memory Access
DIME: Direct in Memory Execution

Das mit dem überschreiben bereits im lokalen Grafikspeicher vorhandener Texturen tritt dann doch nur auf, wenn der AGP im DMA-Modus arbeitet. Dann müssen die Texturen erst vom Hauptspeicher des PC über AGP ins lokale Grafikkarten-RAM übertragen werden. Die Grafikkarten-GPU hat nur Zugriff auf den lokalen Grafikkartenspeicher.
Wenn der AGP im DIME-Modus funktioniert kann die GPU Texturen aus dem Hauptspeicher des PC laden, ohne Inhalte aus dem lokalen Grafikkarten-RAM zu überschreiben. Die GPU erhält direkten Zugriff auf den PC-Hauptspeicher.

mfG
Helmut

[zeckensack]

Originally posted by Aragon


es gibt doch beim AGP zwei Betriebsmodi:
DMA: Direct Memory Access
DIME: Direct in Memory Execution

Das mit dem überschreiben bereits im lokalen Grafikspeicher vorhandener Texturen tritt dann doch nur auf, wenn der AGP im DMA-Modus arbeitet. Dann müssen die Texturen erst vom Hauptspeicher des PC über AGP ins lokale Grafikkarten-RAM übertragen werden. Die Grafikkarten-GPU hat nur Zugriff auf den lokalen Grafikkartenspeicher.
Wenn der AGP im DIME-Modus funktioniert kann die GPU Texturen aus dem Hauptspeicher des PC laden, ohne Inhalte aus dem lokalen Grafikkarten-RAM zu überschreiben. Die GPU erhält direkten Zugriff auf den PC-Hauptspeicher.

mfG
Helmut Richtig. Meine Ausführungen oben bezogen sich auch ausdrücklich auf Texturswapping, nicht auf den Direktzugriff der GPU auf den (physikalisch im System-RAM liegenden) AGP-Speicher.

DIME (was man meistens AGP-Texturing nennt) funktioniert trotz der geringeren Bandbreite in der Praxis einfach besser, eben weil swapping mit den oben genannten Problemen einhergeht :)

[RealBierchen]

Guten Abend !

Ich habe am Freitag meinen Prof. gefragt, und der meinte, daß die Engine und die graphische Schnittstelle solche Bandbreitenprobleme lösen sollte. Die maximale Darstellungsfähigkeit einer Grafikkarte mit 128 MB beträgt natürlich 128Mb pro frame(z.B. 128Mb*100fps= 12,8GBs).
Dementsprechend wird der Rest der Bandbreite zur "Vorbereitung des nächsten Frames" benutzt (inbegriffen benötigter Texturen etc.).
Daher nehme ich an, daß entweder -wie auch schon bestätigt wurde(ich habe nur eine Geforce 2 mx und kann da nicht mitreden :[[)- einige Level noch zu "buggy" gestalltet wurden, oder was ich eher vermute, daß die Grafik-Engine (incl. der Steuerung der Grafikschnittstelle) noch einige Schönheitsfehler enthalten muss.
Ich bin ja mal gespannt ob bei ID diese Probleme auch auftreten !
Mir ist natürlich klar, daß man mit genügend Details jede Grafikkarte überfordern kann, jedoch doch kluge Steuerung diese Überforderung bei gleicher Darstellungsqualität wettmachen kann -wie auch schon einige hier beschrieben haben, gibt es zig Methoden wie GPU,Speicher,Agp und Cpu die gewalltigen Datenmengen bändigen kann.

Mfg
Bierchen

Ps: Ich sehe da : //* Hehe, "programmer art" Joe Wilcox (DrSin) hat CTF-December erstellt.

-- Daniel, Epic Games Inc. *//
Vielleicht weiß er mehr ?

[RealBierchen]

Hmm,
ich hätte doch nochmal nachlesen sollen, was ich schreibe! :]]
Sorry für die Rechtschreibfehler :]] , aber ich bin mit ein paar Freunden am Saufen und am Proggen :]] hicks....

Mfg
Bierchen

[betasilie]

Prost *hicks*

[Demirug]

Originally posted by RealBierchen
Guten Abend !

Ich habe am Freitag meinen Prof. gefragt, und der meinte, daß die Engine und die graphische Schnittstelle solche Bandbreitenprobleme lösen sollte.

Primär die Aufgabe der Engine, da die Schnittstelle (API) nur das macht was sie gesagt bekommt.


Die maximale Darstellungsfähigkeit einer Grafikkarte mit 128 MB beträgt natürlich 128Mb pro frame(z.B. 128Mb*100fps= 12,8GBs). Dementsprechend wird der Rest der Bandbreite zur "Vorbereitung des nächsten Frames" benutzt (inbegriffen benötigter Texturen etc.).

??? Wie kommst du den darauf?

So was die Darstellungsfähigkeit gibt es nicht. Es gibt Vertexdurchsatz, Füllraten, usw. Die Menge das RAMs hat primär auf die Leistungsfähigkeit eines Chips keinen Einfluss. Der gleiche Chip ist mit 64 MB genauso Leistungsfähig wie bei 128 MB. Die 64 MB mehr erlauben es nur grössere Texturen in den schnellen Grafikram zu legen. Auch auf die Bandbreite hat die Speichermenge keinen Einfluss.

Daher nehme ich an, daß entweder -wie auch schon bestätigt wurde(ich habe nur eine Geforce 2 mx und kann da nicht mitreden :[[)- einige Level noch zu "buggy" gestalltet wurden, oder was ich eher vermute, daß die Grafik-Engine (incl. der Steuerung der Grafikschnittstelle) noch einige Schönheitsfehler enthalten muss.

die Level sind nicht unbeding buggy sonder eher einfach ein bischen zu gross geraten. Das die Engine sowas nicht berücksichtigt kann man natürlich als "Schönheitsfehler" ansehen.


Ich bin ja mal gespannt ob bei ID diese Probleme auch auftreten !
Mir ist natürlich klar, daß man mit genügend Details jede Grafikkarte überfordern kann, jedoch doch kluge Steuerung diese Überforderung bei gleicher Darstellungsqualität wettmachen kann -wie auch schon einige hier beschrieben haben, gibt es zig Methoden wie GPU,Speicher,Agp und Cpu die gewalltigen Datenmengen bändigen kann.

Auch hier wieder nur ein grosses Fragezeichen. Wenn die Grafikkarte am Ende ist nützt dir auch die beste Ansterung nichts mehr. Sobald die Daten nicht mehr in den Speicher der Grafikkarte passen wird es nun mal langsamer weil die anderen Speicher auf die zugegriffen werden kann es nicht mit dem Lokalen Speicher aufnehmen können. Der einzige Ausweg ist dann eben mit den Details runterzugehen.


Hmm,
ich hätte doch nochmal nachlesen sollen, was ich schreibe! :]]
Sorry für die Rechtschreibfehler :]] , aber ich bin mit ein paar Freunden am Saufen und am Proggen :]] hicks....


man kann seine Beiträge auch nachträglich editieren.

[RealBierchen]

Guten Morgen !
1)
Demirug schrieb:
Primär die Aufgabe der Engine, da die Schnittstelle (API) nur das macht was sie gesagt bekommt. //

Das stimmt so nicht ganz, da man auf einer Schnittstelle programmiert und genaue Ablaufregister der GI-Api erstellt(wie was nachher dargestellt wird), die den späteren Datenfluß bestimmen etc...aber hauptsächlich natürlich die Engine.

2)
Demirug schrieb:
Wie kommst du den darauf?
So was die Darstellungsfähigkeit gibt es nicht. Es gibt Vertexdurchsatz, Füllraten, usw. Die Menge das RAMs hat primär auf die Leistungsfähigkeit eines Chips keinen Einfluss. Der gleiche Chip ist mit 64 MB genauso Leistungsfähig wie bei 128 MB. Die 64 MB mehr erlauben es nur grössere Texturen in den schnellen Grafikram zu legen. Auch auf die Bandbreite hat die Speichermenge keinen Einfluss. //

Desto höher die Darstellungsqualität sein soll, desto mehr und natürlich schnellerer Speicher wird benötigt.Eine Ati 9700pro mit 64MB würde nie gleiche Darstellungsfähigkeit besitzen wie eine mit 128 MB ! Mir ist wohl auch klar das mehr Ram nicht mehr Bandbreite heißt (lol), aber die höhere Speichermenge erfordert mehr Bandbreite (um die höhere Speichermenge überhaupt ausnutzen zu können).Außerdem tragen die 64MB mehr speicherprogrammiertechnisch zu höheren Leistungsreserven bei (es muss zb im Vergleich zur 64MB karte bei gleicher Darstellungsqualität viel weniger geladen werden etc...).

3)
Demirug schrieb:
Auch hier wieder nur ein grosses Fragezeichen. Wenn die Grafikkarte am Ende ist nützt dir auch die beste Ansterung nichts mehr. Sobald die Daten nicht mehr in den Speicher der Grafikkarte passen wird es nun mal langsamer weil die anderen Speicher auf die zugegriffen werden kann es nicht mit dem Lokalen Speicher aufnehmen können. Der einzige Ausweg ist dann eben mit den Details runterzugehen. //

Man steuert AGP-Modi,Systemspeicher,Gpu-Speicher und sogar Cpu-Leistung so an. Damit kann man sonst auftretendes "geruckele" umgehen. Nix anderes hat ID mit Quake III zb gemacht !
Nur ein vernünftiges Ansteuern aller für graphische Darstellung wichtigen und nötigen Komponenten lässt ein Spiel gut Aussehen und performant darstellen- das meine ich damit !
Wenn man beim Zusammenspiel aller Komponenten am Limit liegt, bringt natürlich nur ein Herunterstellen der Details noch etwas.

Also ich habe das so gelernt und verstanden :]]


Mfg
Bierchen

Ps:Danke für den Tipp,daß man seine Beiträge nachträglich korrigieren kann :]]

Schöne Grüße @betareverse

[Demirug]

Originally posted by RealBierchen
Das stimmt so nicht ganz, da man auf einer Schnittstelle programmiert und genaue Ablaufregister der GI-Api erstellt(wie was nachher dargestellt wird), die den späteren Datenfluß bestimmen etc...aber hauptsächlich natürlich die Engine.

Jede API kann nur Entscheidungen auf der Basis der Informationen treffen die sie von der Application bekommt. Der Treiber kann durchaus noch was bewirken. Aber niemals die Schnitstelle.

Desto höher die Darstellungsqualität sein soll, desto mehr und natürlich schnellerer Speicher wird benötigt.Eine Ati 9700pro mit 64MB würde nie gleiche Darstellungsfähigkeit besitzen wie eine mit 128 MB ! Mir ist wohl auch klar das mehr Ram nicht mehr Bandbreite heißt (lol), aber die höhere Speichermenge erfordert mehr Bandbreite (um die höhere Speichermenge überhaupt ausnutzen zu können).Außerdem tragen die 64MB mehr speicherprogrammiertechnisch zu höheren Leistungsreserven bei (es muss zb im Vergleich zur 64MB karte bei gleicher Darstellungsqualität viel weniger geladen werden etc...).

Wenn wir von der optischen Darstellungsqualität reden wirkt sich mehr RAM natürlich erst mal positive aus. Mehr RAM erfordert nicht zwangsläufig mehr Bandbreite. Die Datenmenge pro Pixel bleibt primär erst mal die gleiche. Allerdings können grössere Texturen durchaus den Texturecache stärker fordern wodurch man am ende doch etwas mehr Bandbreite braucht um die gleiche Framerate zu ereichen.

Man steuert AGP-Modi,Systemspeicher,Gpu-Speicher und sogar Cpu-Leistung so an. Damit kann man sonst auftretendes "geruckele" umgehen. Nix anderes hat ID mit Quake III zb gemacht !
Nur ein vernünftiges Ansteuern aller für graphische Darstellung wichtigen und nötigen Komponenten lässt ein Spiel gut Aussehen und performant darstellen- das meine ich damit !
Wenn man beim Zusammenspiel aller Komponenten am Limit liegt, bringt natürlich nur ein Herunterstellen der Details noch etwas.

Also ich habe das so gelernt und verstanden :]]

Theoretisch gebe ich dir recht. In der Praxsis kannst du das auf dem PC ganz schnell vergessen (auf einer Konsole geht das noch einigermassen). Die Anzahl der möglichen PC-Konfigurationen ist inzwischen viel zu hoch. Die APIs abstrahieren die Hardware sehr stark. Es ist daher inzwischen vollkommen unmöglich (bzw. unbezahlbar)auf einer so tiefen Ebene zu arbeiten. Aus diesem Grund werden PC-Spiele auch niemals am absoluten Limit der Hardware laufen.

[zeckensack]

@bierchen (und auch an deinen Prof :D)

Ööööhm ...
Da klingelt gerade ganz furchtbar laut mein 'Theoretiker-im-weißen-Turm-mit-meterlangem-Bart'-Alarm :D
*duck*

Das stimmt so nicht ganz, da man auf einer Schnittstelle programmiert und genaue Ablaufregister der GI-Api erstellt(wie was nachher dargestellt wird), die den späteren Datenfluß bestimmen etc...aber hauptsächlich natürlich die Engine.1. Hä???
2. Hat mit Echtzeitgrafik überhaupt nichts zu tun (naja, vielleicht auf 'ner PS2 ...)

Schritt 1: Texturen laden
Schritt 2: while (noch nicht abgestürzt) {vertices rein; pixel raus;}

Desto höher die Darstellungsqualität sein soll, desto mehr und natürlich schnellerer Speicher wird benötigt.Eine Ati 9700pro mit 64MB würde nie gleiche Darstellungsfähigkeit besitzen wie eine mit 128 MB ! Mir ist wohl auch klar das mehr Ram nicht mehr Bandbreite heißt (lol), aber die höhere Speichermenge erfordert mehr Bandbreite (um die höhere Speichermenge überhaupt ausnutzen zu können).Außerdem tragen die 64MB mehr speicherprogrammiertechnisch zu höheren Leistungsreserven bei (es muss zb im Vergleich zur 64MB karte bei gleicher Darstellungsqualität viel weniger geladen werden etc...).Grafikspeicher kann auch brachliegen. Nicht jede Textur wird für jedes Frame benutzt. Liegt vor allem daran, daß Texturswapping nicht stattfindet.

Außerdem hast du elegant vergessen, daß auch Füllrate eine begrenzte Ressource ist, und Z-Buffer und Framebuffer auch noch Bandbreite verschlingen ... was sich in Echtzeit nur sehr begrenzt wegoptimieren lässt.

Man steuert AGP-Modi,Systemspeicher,Gpu-Speicher und sogar Cpu-Leistung so an. Damit kann man sonst auftretendes "geruckele" umgehen. Nix anderes hat ID mit Quake III zb gemacht !Ich programmiere jetzt seit 18 Jahren in vielen verschiedenen Sprachen, aber noch nie habe ich CPU-Leistung 'angesteuert'. Immer nur Befehle ausführen lassen ?-)
Auch meinen Grafikchip betrachte ich als Befehlsempfänger. Was meinst du überhaupt mit 'ansteuern'???

[RealBierchen]

Demirug schrieb :
Jede API kann nur Entscheidungen auf der Basis der Informationen treffen die sie von der Application bekommt. Der Treiber kann durchaus noch was bewirken. Aber niemals die Schnitstelle. //

Ist der Treiber nicht die eigentliche (benutze) Api ?! :]]

Demirug schrieb :
Theoretisch gebe ich dir recht. In der Praxsis kannst du das auf dem PC ganz schnell vergessen (auf einer Konsole geht das noch einigermassen). Die Anzahl der möglichen PC-Konfigurationen ist inzwischen viel zu hoch. Die APIs abstrahieren die Hardware sehr stark. Es ist daher inzwischen vollkommen unmöglich (bzw. unbezahlbar)auf einer so tiefen Ebene zu arbeiten. Aus diesem Grund werden PC-Spiele auch niemals am absoluten Limit der Hardware laufen.//

Also wenn ich zB Quake III laufen lasse schon:]](CPU-Auslastung~100%)
Quake läuft zb auf ner Geforce 2 mit ner 500Mhz Cpu viel langsam als auf einem 2GHZ Rechner!
Die Apis sind so konstruiert, daß man sie auf die verschiede Hardware (Nvidia,ATI,Intel,Amd,...) "perfekt" anpassen kann. Vorausgesetzt die Hardwaretreiber sind nicht fehlerhaft :]] kann das System annähernd zu 100 % ausgelastet sein.

zeckensack schrieb:
@bierchen (und auch an deinen Prof )

Ööööhm ...
Da klingelt gerade ganz furchtbar laut mein 'Theoretiker-im-weißen-Turm-mit-meterlangem-Bart'-Alarm
*duck* //

:]] lass meinen Prof. in Ruhe :]] der ist der Beste!!! :]] und erst knapp über 40 :]] der ist up to date :]]


zeckensack schrieb:
1. Hä
2. Hat mit Echtzeitgrafik überhaupt nichts zu tun (naja, vielleicht auf 'ner PS2 ...)

Schritt 1: Texturen laden
Schritt 2: while (noch nicht abgestürzt) {vertices rein; pixel raus;} //

Für mich ist ne PS2 ein spieleoptimierter PC :]] und wenn man, wie man das eigentlich in jedem BetriebsSystem macht, dann den Hintergrund (das System und dann ganzen Rest) anhält und swapped (so machens Direct3D-Anwendungen) hat man fast 100% der Ressourcen des Systems zur Verfügung !

zeckensack schrieb:
Grafikspeicher kann auch brachliegen. Nicht jede Textur wird für jedes Frame benutzt. Liegt vor allem daran, daß Texturswapping nicht stattfindet.
Außerdem hast du elegant vergessen, daß auch Füllrate eine begrenzte Ressource ist, und Z-Buffer und Framebuffer auch noch Bandbreite verschlingen ... was sich in Echtzeit nur sehr begrenzt wegoptimieren lässt. //

Deswegen sollte man ja Bandbreite von Engine und Api(-Treibern) intelligent steuern lassen(zb JIT etc:]] )...

zeckensack schrieb:
Ich programmiere jetzt seit 18 Jahren in vielen verschiedenen Sprachen, aber noch nie habe ich CPU-Leistung 'angesteuert'. Immer nur Befehle ausführen lassen
Auch meinen Grafikchip betrachte ich als Befehlsempfänger. Was meinst du überhaupt mit 'ansteuern' //

:]] Mit Ansteuern mein ich schon Befehle ausführen,d.h. die Art wie ich verscheiden Befehle in welcher Reihenfolge an die jeweilige Komponente schicke.
Mit Cpu-Leistung "ansteuern" (ich geb zu, ünglücklich gewähltes Wort :]]) meine ich, daß zb. wie bei einigen T&L-Spielen (BF1942etc...) nur ein Teil der Cpu-Leistung in Anspruch genommen wird(z.B. <=30%), jedoch eine höhere in Anspruchnahme der Cpu unter Umständen (wenn die Engine wie Q3 das ünterstützt zb. Multiprozessoring) eine wesentlich höhere Grafikperformance zu läßt !

Daher meine ich , daß eine kluge Steuerung aller Komponenten wohl die bestmögliche Qualität und Performance für ein Spiel möglich macht !

Mfg
Bierchen

[dslfreak]

Wann kommen eigentlich die ersten Grafikkarten (Für nicht Workstations) mit 256 MB Speicher? Die Radeon 9700Pro soll später ja auch mit 256 MB kommen und was wird der NV30 haben 128 oder gleich 256?

[Demirug]

Originally posted by RealBierchen
Ist der Treiber nicht die eigentliche (benutze) Api ?! :]]


Nein der Treiber implementiert die API. Das ist ein grosser Unterschied.

Also wenn ich zB Quake III laufen lasse schon:]](CPU-Auslastung~100%)
Quake läuft zb auf ner Geforce 2 mit ner 500Mhz Cpu viel langsam als auf einem 2GHZ Rechner!
Die Apis sind so konstruiert, daß man sie auf die verschiede Hardware (Nvidia,ATI,Intel,Amd,...) "perfekt" anpassen kann. Vorausgesetzt die Hardwaretreiber sind nicht fehlerhaft :]] kann das System annähernd zu 100 % ausgelastet sein.

Fast alle 3D-Spiele laufen mit 100% CPU auslastung. Das hat aber gar nichts zu heisen sonder hängt damit zusammen das Spiele einen Gameloop haben der grundsätzlich immer läuft. Im Zweifelsfall wird "überschüssige" Leistung in Warteschleifen verheitzt. Gerade dein Beispiel mit Quake zeigt das es wohl nicht perfekt auf die Hardware abgestimmt ist. Denn im Fall schwache CPU gegen starke Grafikkarte zeigt sich doch eindeutig das aus der starken Grafikkarte nicht alles rausgeholt wird.

Eine API dient dazu für unterschiedliche Hardware eine einheitliche schnitstelle zur verfügung zu stellen. Aussnahmen sind dabei Herstellerspezifische APIs wie zum Beispiel Glide oder die Hersteller Extensions für OpenGL. Sowas mag ein Programmierer aber nicht besonders. Eine Abstraktion kostet aber immer Leistung.

Für mich ist ne PS2 ein spieleoptimierter PC :]] und wenn man, wie man das eigentlich in jedem BetriebsSystem macht, dann den Hintergrund (das System und dann ganzen Rest) anhält und swapped (so machens Direct3D-Anwendungen) hat man fast 100% der Ressourcen des Systems zur Verfügung !


Du hast dir noch keine Informationen über den Systemaufbau der PS2 angeschaut, oder?


Deswegen sollte man ja Bandbreite von Engine und Api(-Treibern) intelligent steuern lassen(zb JIT etc:]] )...


Bandbreite kann man nicht steuern. Im Prinzip hat man sogar recht wenig Kontrolle darüber was der Grafikchip und die CPU damit machen.

:]] Mit Ansteuern mein ich schon Befehle ausführen,d.h. die Art wie ich verscheiden Befehle in welcher Reihenfolge an die jeweilige Komponente schicke.
Mit Cpu-Leistung "ansteuern" (ich geb zu, ünglücklich gewähltes Wort :]]) meine ich, daß zb. wie bei einigen T&L-Spielen (BF1942etc...) nur ein Teil der Cpu-Leistung in Anspruch genommen wird(z.B. <=30%), jedoch eine höhere in Anspruchnahme der Cpu unter Umständen (wenn die Engine wie Q3 das ünterstützt zb. Multiprozessoring) eine wesentlich höhere Grafikperformance zu läßt !

Daher meine ich , daß eine kluge Steuerung aller Komponenten wohl die bestmögliche Qualität und Performance für ein Spiel möglich macht !


RealBierchen, ich möchte dir ja jetzt nicht zu nahe treten aber ich habe den Eindruck das du hier stark zum theoretisieren neigst.

In der Theorie würde die Ideale Engine natürlich alle Teile zu 100% auslasten. Man würde die Arbeit dynamisch umverteilen usw.

In der Praxsis kann man nicht die ideale Lösung anstreben sonder sucht den besten Kompromiss für das gesamte Spektrum an Hardware das man unterstützen möchte. Das hängt auch damit zusammen das man gewisse arbeiten nicht einfach von der Grafikkarte zur CPU oder von der CPU zur Grafikkarte verlagern kann.

[RealBierchen]

1) dslfreak schrieb:
Wann kommen eigentlich die ersten Grafikkarten (Für nicht Workstations) mit 256 MB Speicher? Die Radeon 9700Pro soll später ja auch mit 256 MB kommen und was wird der NV30 haben 128 oder gleich 256? //
Soweit ich weiß, soll es zuerst du 128Mb Varianten geben und dann am Ende des Jahres,wenn DDR2 kommt, die 256MB Variante.
Bin mir da aber nicht so sicher :]]



2) Demirug schrieb :
Nein der Treiber implementiert die API. Das ist ein grosser Unterschied. //

Haarspalterei :]]..is schon richtig...

3) Demirug schrieb:
Fast alle 3D-Spiele laufen mit 100% CPU auslastung. Das hat aber gar nichts zu heisen sonder hängt damit zusammen das Spiele einen Gameloop haben der grundsätzlich immer läuft. Im Zweifelsfall wird "überschüssige" Leistung in Warteschleifen verheitzt. Gerade dein Beispiel mit Quake zeigt das es wohl nicht perfekt auf die Hardware abgestimmt ist. Denn im Fall schwache CPU gegen starke Grafikkarte zeigt sich doch eindeutig das aus der starken Grafikkarte nicht alles rausgeholt wird. //

Diese überschüssige" Leistung kann und wird von den Spielen z.b. zum Teil für geometrische Berechnungen, Koordinatenberechnungen etc. verwendet, um der Grafikkarte Arbeit abzunehmen.
Eine schnellere Cpu stellt einer dafür abgestimmten Engine Leistungsreserven für z.b. höhere Grafikqualität zur Verfügung.


4) Demirug schrieb:
Eine API dient dazu für unterschiedliche Hardware eine einheitliche schnitstelle zur verfügung zu stellen. Aussnahmen sind dabei Herstellerspezifische APIs wie zum Beispiel Glide oder die Hersteller Extensions für OpenGL. Sowas mag ein Programmierer aber nicht besonders. Eine Abstraktion kostet aber immer Leistung.

Deswegen implementiert du mit den Treiber die API ja - und hast damit deine speziell-abgestimmt Api.Kannst ja für jede Grafikkartenchipart (sind ja nur 3oder4) ne eigen Api schreiben und dem ensprechend welchen Api-Treiber der User wählt, wird dann halt die spezielle Api benutzt.

5)Demirug schrieb:
Du hast dir noch keine Informationen über den Systemaufbau der PS2 angeschaut, oder? //

Ne, daß einzige was ich weiß,ist das die embedded Grafikspeicher hat !?
Hast du nen paar Infos oder Sites für mich ?

6)Demirug schrieb:
Bandbreite kann man nicht steuern. Im Prinzip hat man sogar recht wenig Kontrolle darüber was der Grafikchip und die CPU damit machen.//

Dementsprechend dem was du denen sagst was die machen sollen kannst du Bandbreite verteilen/steuern !

7)Demirug schrieb:
RealBierchen, ich möchte dir ja jetzt nicht zu nahe treten aber ich habe den Eindruck das du hier stark zum theoretisieren neigst. //

Eigentlich nicht mehr als jeder andere :]]

8)Demirug schrieb:
In der Praxsis kann man nicht die ideale Lösung anstreben sonder sucht den besten Kompromiss für das gesamte Spektrum an Hardware das man unterstützen möchte. Das hängt auch damit zusammen das man gewisse arbeiten nicht einfach von der Grafikkarte zur CPU oder von der CPU zur Grafikkarte verlagern kann.

Da gebe ich dir völlig Recht, aber man sucht bei der Programmplanung ersteinmal "theoretisch":]]den besten Kompromiss für das gesamte Spektrum an Hardware das man unterstützen möchte und wie man Aufgaben intelligent verteilen kann :]]


Mfg
Bierchen

[Demirug]

Originally posted by RealBierchen
Diese überschüssige" Leistung kann und wird von den Spielen z.b. zum Teil für geometrische Berechnungen, Koordinatenberechnungen etc. verwendet, um der Grafikkarte Arbeit abzunehmen.
Eine schnellere Cpu stellt einer dafür abgestimmten Engine Leistungsreserven für z.b. höhere Grafikqualität zur Verfügung.

Durchaus eine nette Idee. Praktisch bringt das aber nicht unbedingt viel da in den wenigsten Fällen die Grafikchips über zuwenig VS Leistung verfügen. Die Flaschenhälse sind in der Regel an anderer Stelle zu suchen.

Deswegen implementiert du mit den Treiber die API ja - und hast damit deine speziell-abgestimmt Api.Kannst ja für jede Grafikkartenchipart (sind ja nur 3oder4) ne eigen Api schreiben und dem ensprechend welchen Api-Treiber der User wählt, wird dann halt die spezielle Api benutzt.

Das ist mit verlaub gesagt Mist. Und dann gibt es einen neuen Chip mit einer neuen API und jeder der sich so eine Karte kauft ist dann angeschmiert weil kein Spiel diesen Chip unterstützt. Das hatte ich schon und brauch ich nicht wieder. Zudem ändert das nichts an der Lage als solches. Wenn man ein Spiel nicht für jeden Chip komplett neu schreibt will muss man sich selbst eine eigene API schaffen und dann für jede Grafikchip-API wiederrum ein Modul schreiben was die Anweisungen der eignen API in die entsprechenden Aufrufe der spezifischen API umsetzt.

Ne, daß einzige was ich weiß,ist das die embedded Grafikspeicher hat !?
Hast du nen paar Infos oder Sites für mich ?

Die sachen hab ich gerade nicht zur hand weil ich eigentlich nichts mit der PS2-Programmierung zu tun haben möchte. Aber im Internet gibt es einges an informationen dazu. Google mal einfach ein bischen.

Dementsprechend dem was du denen sagst was die machen sollen kannst du Bandbreite verteilen/steuern !

Man kann nur die Datenmenge reduzieren wenn man merkt das die Bandbreite nicht reicht.

Da gebe ich dir völlig Recht, aber man sucht bei der Programmplanung ersteinmal "theoretisch":]]den besten Kompromiss für das gesamte Spektrum an Hardware das man unterstützen möchte und wie man Aufgaben intelligent verteilen kann :]]

Ja der gute alte irglauben das Softwareentwicklung planbar wäre. Aus meiner mehrjährigen Praxsis heraus kann ich nur sagen das es nicht geht. Zudem würde der Versuch den Kompromiss zu finden vorraussetzten das man schon vorher weis wie sich die Hardware verhalten wird. Das geht ohne Tests nicht mal bei aktueller Hardware und bei Hardware die es noch gar nicht gibt ist das vollkommen unmöglich. Also schreibt man eine Engine und verbessert sie dann einfach solange bis man zufrieden ist.

[RealBierchen]

Demirug schrieb:
Durchaus eine nette Idee. Praktisch bringt das aber nicht unbedingt viel da in den wenigsten Fällen die Grafikchips über zuwenig VS Leistung verfügen. Die Flaschenhälse sind in der Regel an anderer Stelle zu suchen.//

Wenn man die Engine darauf auslegen würde, wäre der Leistungsgewinn denke ich imens ! Destdo besser die einzelnen Komponenten der Engine zusammenspielen und sich entlasten desto "perfekter" ist die Engine.


Demirug schrieb:
Das ist mit verlaub gesagt Mist. Und dann gibt es einen neuen Chip mit einer neuen API und jeder der sich so eine Karte kauft ist dann angeschmiert weil kein Spiel diesen Chip unterstützt. Das hatte ich schon und brauch ich nicht wieder. Zudem ändert das nichts an der Lage als solches. Wenn man ein Spiel nicht für jeden Chip komplett neu schreibt will muss man sich selbst eine eigene API schaffen und dann für jede Grafikchip-API wiederrum ein Modul schreiben was die Anweisungen der eignen API in die entsprechenden Aufrufe der spezifischen API umsetzt. //

Wäre doch dann ne Art GRAPHICCHIP-API-Bibliothek in der neue und alte Chipsätze vertreten sind, die dann nur noch an die Spieleengine angeglichen werden müßten.Außerdem hatte ich bis vor 3 Monaten noch ne gute alte Voodoo III(dank meinem Arbeitgebers nu Geforce 2mx wenigstens:]]), die großteils auch nicht von den neueren Spielen unterstützt wird und wurde...wäre das dann nicht die bessere Lösung ?
Man hat zwar dann mehr Arbeit, aber den Usern käme es zu gute !

Demirug schrieb:
Ja der gute alte irglauben das Softwareentwicklung planbar wäre. Aus meiner mehrjährigen Praxsis heraus kann ich nur sagen das es nicht geht. Zudem würde der Versuch den Kompromiss zu finden vorraussetzten das man schon vorher weis wie sich die Hardware verhalten wird. Das geht ohne Tests nicht mal bei aktueller Hardware und bei Hardware die es noch gar nicht gibt ist das vollkommen unmöglich. Also schreibt man eine Engine und verbessert sie dann einfach solange bis man zufrieden ist.//

Also ich plane mein Projekt zuerst (meist aufem Blatt Papier und dann in Together 6 ) vollständig durch, dann wird es implementiert, danach beginnt eine lange Testphase und dann erst werden Verbesserungen vorgenommen.:]]
Aber hast schon Recht, denn das perfekte Programm (geschweige denn das perfekt geplante Programm) gibt es wohl nicht. :]]

Dennoch kann man durch einige Tricks Speicherprobleme und Bandbreitenprobleme umgehen, wenn man alles ausnutzten würde, was einem theoretisch zur Verfügung steht.in der Realität wird das wohl kaum umsetzbar sein, aber man kann ja an der Optimierungen zur "Perfektion" arbeiten :]]

Mfg
Bierchen

[Ganon]

Hier ist ein PS2 Bericht:

http://www.tecchannel.de/hardware/314/1.html

Nicht gerade ein PC! Kann zwar alles was ein PC auch kann, aber ganz andere Technik:

[Demirug]

Originally posted by RealBierchen
Wenn man die Engine darauf auslegen würde, wäre der Leistungsgewinn denke ich imens ! Destdo besser die einzelnen Komponenten der Engine zusammenspielen und sich entlasten desto "perfekter" ist die Engine.

Glauben heist leider nicht wissen. Und mit gegenseitiger Entlastung ist eh nicht viel drin weil es in den meisten fällen entweder technisch keinen Sinn macht oder die Stelle kein Flaschenhals ist. Und dann gibt es ja auch noch wirtschaftliche Gründe. Die perfekte Engine könnte niemand bezahlen.

Wäre doch dann ne Art GRAPHICCHIP-API-Bibliothek in der neue und alte Chipsätze vertreten sind, die dann nur noch an die Spieleengine angeglichen werden müßten.Außerdem hatte ich bis vor 3 Monaten noch ne gute alte Voodoo III(dank meinem Arbeitgebers nu Geforce 2mx wenigstens:]]), die großteils auch nicht von den neueren Spielen unterstützt wird und wurde...wäre das dann nicht die bessere Lösung ?
Man hat zwar dann mehr Arbeit, aber den Usern käme es zu gute !

Diese Bibliothek gibt es doch schon. Das ganze nennt sich Direct 3D. Und wenn "alte" Chips von einem D3D Spiel nicht mehr unterschützt werden dürfte das wohl daran liegen das dieser einfach nicht genügend Rohleistung hat. Also warum sollte ich etwas machen was MS und die Chiphersteller für mich erledigen?

@zeckensack: Ja es gibt auch OpenGL. Aber die schönen Features sind dort halt leider gröstenteils nur über die Herstellerspezifischen Extension zu benutzten.

Also ich plane mein Projekt zuerst (meist aufem Blatt Papier und dann in Together 6 ) vollständig durch, dann wird es implementiert, danach beginnt eine lange Testphase und dann erst werden Verbesserungen vorgenommen.:]]
Aber hast schon Recht, denn das perfekte Programm (geschweige denn das perfekt geplante Programm) gibt es wohl nicht. :]]

Versuch sowas mal mit einem Projekt das mehr als 100K Zeilen Code hat und über mehr als 3 Jahre läuft. Sowas kann man nur noch mit der Intergralmethode durchziehen sonst liegt man nach ein paar Monaten auf der Schnauze. Aber das ist ein anderes Thema.

Dennoch kann man durch einige Tricks Speicherprobleme und Bandbreitenprobleme umgehen, wenn man alles ausnutzten würde, was einem theoretisch zur Verfügung steht.in der Realität wird das wohl kaum umsetzbar sein, aber man kann ja an der Optimierungen zur "Perfektion" arbeiten :]]

Tricks sind immer gefährlich da man niemals absehen kann wie eine andere Hardwarekombination als die ursprüngliche auf sowas reagiert. Diese Lektion mussten schon einige Konsolenentwickler die zum erstenmal ein PC-Spiel entwickelten lernen.

Die ganze Kunst beim Optimieren ist primär Datenflussreduktion. Je weniger Daten über die Speicherbusse laufen desto schneller ist die Sache. Sekundär kann man dann noch versuchen die Kernfunktionen zu optimieren.

[betasilie]

Im Endeffekt finde ich läuft die Disskusion, genauso wie ich sie mit Bierchen privat geführt habe, darauf hinaus, dass seine analysen etwas theoretisch bzw. idelistisch sind.
Es gibt zur Zeit einfach kein Spiel welches "offene" 180MB-Maps über AGP-Auslagerung ohne Frameratenverluste darstellen. Bei "geschlossen" Maps, wie sie wahrscheinlich überwiegend in DOOMIII zu finden sein werden, ist das was anderes.
Allerdings könnte es auch sein das Epic das besser gekonnt hätte, aber vieleicht hat da ein Grafikkartenhersteller, an den man bei jedem Programmstart erinnert wird *grrr*, seine Finger im Spiel gehabt. ---> Die GF5 wird halt am Start mit 256MB kommen. ;)
Ich glaube aber trotzdem, dass es da einfach in der Praxis zu viele Probleme gibt. Sicherlich wird auch eine iD-Engine keine Texturauslagerung ohne die benannten Probleme in Maps, wie sie in UT-2003 vorkommen, hinbekommen. ... meine Meinung.


Zum Thema PS2 kenne ich auf deutsch auch nur den alten Tecchannelbericht. Ich habe aber vor ca. einem Jahr mal einige Auszüge aus gameentwickler-Logs gelesen und kann dir nur sagen, dass absolute Profis aus dem PC-Bereich ganz schöne Probleme hatten sich umzustellen. ... die X-box würde deiner Definition der PS2 eigentlich mehr entsprechen. ;)

[Tom Servo]

Die UT2300 Map CTF_December (Slaughterhouse auch) läuft auf einer GF4-128MB bei maximalen Settings und 1024x768 (wegen TFT) mit weniger starkem Stottern wenn FSAA aktiviert wird. Liegt das an D3D oder der Engine?

(Mit stat hardware sieht man, das mit FSAA der Speicherverbrauch nicht so extrem schwankt, also keine Sprünge von z.B. 120MB zurück zu 50MB wonach dann in 10MB Schritten unter starkem Stottern nachgeladen wird)

[Demirug]

Originally posted by Tom Servo
Die UT2300 Map CTF_December (Slaughterhouse auch) läuft auf einer GF4-128MB bei maximalen Settings und 1024x768 (wegen TFT) mit weniger starkem Stottern wenn FSAA aktiviert wird. Liegt das an D3D oder der Engine?

(Mit stat hardware sieht man, das mit FSAA der Speicherverbrauch nicht so extrem schwankt, also keine Sprünge von z.B. 120MB zurück zu 50MB wonach dann in 10MB Schritten unter starkem Stottern nachgeladen wird)

Ob es nun an D3D oder der Engine liegt kann ich so spontan nicht sagen. Aber warum es mit aktiviertem AA weniger stottert ist mir schon klar. Alles was ich bisher gesehen und gelesen habe deutet darauf hin das das ruckeln primär wirklich vom nachladen der Texturen in die Grafikkarte entstehen. Wenn man nun AA aktiviert hat ist natürlich weniger RAM für Texturen übrig. Dadurch kann natürlich auch weniger reingeladen werden nachdem die Engine sich entschlossen hat die Texturen aus dem Speicher zu werfen. Da die Ladegeschwindigkeit eine Konstante im Bezug auf MB/s ist wird die kleinere Menge freien RAMs schneller gefüllt. Ergebniss: weniger Ruckeln.

@Daniel Vogel:
Wenn ich mich recht erinnere hast du mal geschrieben das die Engine wenn sie unbedingt Grafikkarten-RAM braucht erst mal alles was geht aus der Grafikkarte rauswirft. Habt ihr mit der Variante nur die benötigte Menge freizugeben schlechte Erfahrungen gemacht? Oder gibt es andere Gründe für diese doch recht radikale Vorgehensweise?

[Unregistered]

Originally posted by Demirug


Ob es nun an D3D oder der Engine liegt kann ich so spontan nicht sagen. Aber warum es mit aktiviertem AA weniger stottert ist mir schon klar. Alles was ich bisher gesehen und gelesen habe deutet darauf hin das das ruckeln primär wirklich vom nachladen der Texturen in die Grafikkarte entstehen. Wenn man nun AA aktiviert hat ist natürlich weniger RAM für Texturen übrig. Dadurch kann natürlich auch weniger reingeladen werden nachdem die Engine sich entschlossen hat die Texturen aus dem Speicher zu werfen. Da die Ladegeschwindigkeit eine Konstante im Bezug auf MB/s ist wird die kleinere Menge freien RAMs schneller gefüllt. Ergebniss: weniger Ruckeln.


Wobei es laut stat hardware mit FSAA es zu diesem kompletten Freigeben des Speichers erst gar nicht kommt (er sinkt niemals auf so niedrige Werte wie 50MB. vieleicht wird anders gecacht wenn weniger Speicher da ist). Ansonsten würde es m.E. auch ähnlich stark stottern. Es wird ja in Stücken nachgeladen und einige wären sicherlich auch genauso gross. Hatte das mal getestet und in einem anderen Thread geschrieben:


Das ärgste Ruckeln bei December und Slaughterhouse scheint aufzutreten wenn anscheinend der Grafikspeicher für die nächste Aktion nicht mehr ausreicht und dann wie es aussieht die als Cache verwendeten Bereiche komplett freigegeben werden (z.B. von 130MB auf 50MB). Darauf folgen dann viele kurze Freezes wenn der Cache schrittweise wieder gefüllt wird.

Bei 128MB-lokal und 32MB-Aperture passiert das einmal am Anfang von December (hatte es in December auch schon mal ein zweites mal in der gegnerischen base) und mitten in Slaughterhouse. Damit wird dann das Precaching beim Laden der Map scheinbar wieder zunichte gemacht.

Da ich mich da nicht so auskenne, mag ich auch falsch liegen.

Habe es auch mal mit AA-2x und AF-2x probiert und damit tritt das Problem nicht auf. Der verwendete Speicher ist ca 20MB weniger und steigt auch nicht an. Und die kurzen Freezes sind weg.

Es hatte hier auch jemand schon berichtet, dass mit Quincux-AA die Ruckler in Slaughterhouse verschwinden.

[Tom Servo]

Der Unregistered war ich. Ist hier leider so, dass man über den direkten Link aus der Mail-Benachrichtigung immer Unregistered ist.

Wollte nur noch dazu schreiben, dass dieses extreme Stottern das ich meinte jetzt nicht unbedingt mit AGP zu tun hat. Wahrscheinlich wird bei Speichermangel sowohl lokaler als auch AGP Speicher freigeben und das Nachladen erfolgt dann aus dem Hauptspeicher oder der Festplatte.

Die 32MB Aperture Size hatten übrigens den Sinn, den Speicher zu verkleinern um das leerlaufen besser beobachten zu können. Hat aber gegenüber 64MB (der i815 kann leider nur 32 oder 64) gar keinen Unterschied gemacht (habe jedenfalls keinen bemerkt).

Nebenbei: Ich nehme an, schon wegen der maximal 64MB Aperture war die Mehrausgabe für eine 128MB Karte gerechtfertigt, oder irre ich mich da? Ich vermute, dass man den lokalen Speicher nicht irgendwie testweise auf 64 oder 32MB verkleinern kann (Registry oder VGA-BIOS)?

[vogel]

Originally posted by Demirug
Texturieren über den AGP ist definitive mit ehrheblichen Leistungseinbrüchen verbunden.


Hab ich Anfangs auch gedacht, aber dem ist nicht unbedingt so. In der Regel hat man weitaus schlechtere maximale Frameraten aber ein wenig bessere minimale Frameraten wenn man Texturen und Geometrie zwischen AGP und local memory (video memory) aufspaltet. Dass liegt daran, dass in bandbreitenlimitierten Szenarien der jeweils andere Speicherzugriff "frei" ist. D.h. Speicherbandbreite = AGP + local memory Bandbreite im besten Fall und halt min( AGP, local memory) im schlechtesten Fall.

Weitaus besser liegt man wenn man Texturen im local memory laesst und Geometrie im AGP memory da fuer Geometrie AGP x4 ausreicht. Das liefert die besten minimalen Frameraten fuer uns und die besten durchschnittlichen und maximalen Frameraten bietet alles im local memory.

-- Daniel, Epic Games Inc.

[vogel]

Setz CacheSizeMegs wieder auf 32 zurueck - alles andere ist massive Speicherverschwendung und dann darf man sich uebers nachladen nicht wundern ;)

-- Daniel, Epic Games Inc.

Originally posted by chicki
naja das speicher interface von ut2k3 ist in jedem fall noch buggy...
habe ne 128mb graka, 512mb ddr ram (ok war auf failsave timings und 266mhz, desweiteren habe ich die cachesize megs noch nicht von 192 auf 256 oder mehr gestellt).
Sobald man sich schnell durch eine grosse map bewegt (translocator + jumppads, irgendwo runterfallen oder einfachrespawnen) droppen die fps massiv (so um 10-20) einfach nur, weil ut2k3 sachen nachläd (sollte ja bei dieser hardware auch ohne gehen)

[vogel]

Overdraw, Aufloesung, Filterart, ... :)

-- Daniel, Epic Games Inc.

PS: Pro Frame wuerde ich eher auf maximal 40-60 MByte an Daten tippen. Die Texturmenge kann man mit "stat hardware" anschauen, fuer Geometrie muss man raten ;)

Originally posted by RealBierchen
UT2003 braucht theoretisch >180Mbs and Daten um eine Map darstellen zu können, was die Karte nachher daraus macht (zb 50fps*180Mb =9000Mbs=9Gbs)ist dem Leistungpotential der KartenGPU bzw. des

[vogel]

Alle "managed resourcen" == Texturen & statiche Geometrie. Praktisch alles bis auf dynamische Buffer und RenderTargets.

ResourceManagerDiscardBytes(Size) garantiert keinen zusammenhaengenden Speicherblock was Schrott ist. Deshalb benutzen wir RMDB(0) was alle "managed resourcen" aus dem local memory rauswirft.

Ich werde fuer den zweiten Patch sehrwahrscheinlich 'ne Option einbauen mit der man die groebsten Ruckler vermeiden kann wenn man unbedingt auf hoechsten details Spielen will und ein wenig FPS dafuer eintauscht. Ist alles ziemlich kompliziert wenn man Resourcen hat die unbedingt in local memory muessen (RenderTargets) und welche die in AGP Speicher sollen (dynamische Buffer) und man dazwischen zwei Abstraktionstufen hat (D3D runtime und Grafikkarten Treiber).

In DX9 impliziert uebrigens eine fehlgeschlagene "resource allocation" ein ResourceManagerDiscardBytes(0) (was aber anderst heisst ;)). Hat uebrigens Sameer auf der DXDev mailing Liste gesagt bevor jemand jetzt kommt und fragt ob das nicht NDA Information ist.

-- Daniel, Epic Games Inc.

Originally posted by Demirug
@Daniel Vogel:
Wenn ich mich recht erinnere hast du mal geschrieben das die Engine wenn sie unbedingt Grafikkarten-RAM braucht erst mal alles was geht aus der Grafikkarte rauswirft. Habt ihr mit der Variante nur die benötigte Menge freizugeben schlechte Erfahrungen gemacht? Oder gibt es andere Gründe für diese doch recht radikale Vorgehensweise?

[vogel]

Ich gebe Dir vollkommen recht - UT2003 koennte *theoretisch* in hoechster Detailstufe besser auf Karten mit 64 MByte laufen... aber das war nie so gedacht also wurde die Zeit besser verbracht. Der gleiche Grund wieso wir nicht fuer 'nen AMD K5 optimiert haben - verschwendete Zeit/ Resourcen ;)

-- Daniel, Epic Games Inc.

Originally posted by RealBierchen
Dennoch kann man durch einige Tricks Speicherprobleme und Bandbreitenprobleme umgehen, wenn man alles ausnutzten würde, was einem theoretisch zur Verfügung steht.in der Realität wird das wohl kaum umsetzbar sein, aber man kann ja an der Optimierungen zur "Perfektion" arbeiten :]]

[vogel]

Amen :)

-- Daniel, Epic Games Inc.

Originally posted by Demirug
Die ganze Kunst beim Optimieren ist primär Datenflussreduktion. Je weniger Daten über die Speicherbusse laufen desto schneller ist die Sache. Sekundär kann man dann noch versuchen die Kernfunktionen zu optimieren.

[aths]

Originally posted by vogel
Ich werde fuer den zweiten Patch sehrwahrscheinlich 'ne Option einbauen mit der man Meine Wunschliste:

- FSAA einstellen kann
- AF einstellen kann.

[Exxtreme]

Meine Wunschliste:

- eine gescheite Übersetzung.
- Sprachauswahl im Menü

[StefanV]

Originally posted by Exxtreme
Meine Wunschliste:

- eine gescheite Übersetzung.
- Sprachauswahl im Menü

Wozu brauchst 'ne übersetzung??

In Englisch ist das recht brauchbar, dt nehm ich nur äußerst ungern, weil die Übersetzung fast immer für die Tonne ist...

[RealBierchen]

Demirug schrieb :
Diese Bibliothek gibt es doch schon. Das ganze nennt sich Direct 3D. Und wenn "alte" Chips von einem D3D Spiel nicht mehr unterschützt werden dürfte das wohl daran liegen das dieser einfach nicht genügend Rohleistung hat. Also warum sollte ich etwas machen was MS und die Chiphersteller für mich erledigen?
//

Damit die Spiele auch noch alle auf meine Voodoo III laufen , mit weniger Details und viel häßlicher als auf aktuellen Karten zwar, aber wäre dann wenigstens lauffähig. Mir ist klar das jeder diese mehr Entwicklung wegen Kosten und Aufwand scheut, wäre doch aber schön wenn !jede! Karte trotzdem ünterstütz würde, und wenn es -wie ich oben beschrieben habe- soeine Api-Bibliothek für alle Karten spezifisch gäbe und die Befehle der Engine die Details etc. auf die jeweilige spezifische Grafikkarte automatisch runter oder raufstellt, sodaß jeder jedes Spiel noch spielen könnte ! Sowas gibt es leider noch nicht, denn diese Api könnte ja eine Erweiterung der DirectX-Api sein die die Auslastung der Grafikkarte damit dann spezifisch regelt..is ja nur so ne Idee...

Demirug schrieb :
Versuch sowas mal mit einem Projekt das mehr als 100K Zeilen Code hat und über mehr als 3 Jahre läuft. Sowas kann man nur noch mit der Intergralmethode durchziehen sonst liegt man nach ein paar Monaten auf der Schnauze. Aber das ist ein anderes Thema. //

Ich programmiere schon seit fast 3 Jahren in einer Softwarefirma und unsere Warenwirtschaftssysteme zb. laufen ewig :]]

Demirug schrieb :
Die ganze Kunst beim Optimieren ist primär Datenflussreduktion. Je weniger Daten über die Speicherbusse laufen desto schneller ist die Sache. Sekundär kann man dann noch versuchen die Kernfunktionen zu optimieren.
//
Was schreibe ich denn die ganze Zeit ? Das sind alles Bandbreiten- bzw. Datenflußoptimierungstechniken um eine möglichst leistungstarke Engine entwickeln zu können, die möglichst viel mit wenig Resourcen darstellen kann.

vogel schrieb :
PS: Pro Frame wuerde ich eher auf maximal 40-60 MByte an Daten tippen. Die Texturmenge kann man mit "stat hardware" anschauen, fuer Geometrie muss man raten //

Ich meinte da 180MB pro Frame! Eine 128 MB Karte wird als maximales Frame im Backbuffer wohl 128MB and Daten (Texturen,Objekte,etc.) haben, die sie nacher von der Gpu berechnet auf dem Bidlschrim darstellen kann.

vogel schrieb :
Ist alles ziemlich kompliziert wenn man Resourcen hat die unbedingt in local memory muessen (RenderTargets) und welche die in AGP Speicher sollen (dynamische Buffer) und man dazwischen zwei Abstraktionstufen hat (D3D runtime und Grafikkarten Treiber).

//

Hmm, kann man die nicht von vornerein als solche GrafikObjekte definieren ? Oder wird zur Laufzeit ausgewählt wohin damit?

Ich gebe Dir vollkommen recht - UT2003 koennte *theoretisch* in hoechster Detailstufe besser auf Karten mit 64 MByte laufen... aber das war nie so gedacht also wurde die Zeit besser verbracht. Der gleiche Grund wieso wir nicht fuer 'nen AMD K5 optimiert haben - verschwendete Zeit/ Resourcen //

Schade :]], vielleicht sollte eine in DirectX -von mir oben beschriebene- implementierte GraphicCard-Api-Biblithek geben!?, die euch dann die Arbeit damit abnimmt, auf veralteter (geb dir ja Recht) Hardware zu proggen.

Mfg
Bierchen

Ps: English rules the programmers world :]]

[vogel]

FSAA - nein
AF - gibt es schon (LevelOfAnisotropy)

-- Daniel, Epic Games Inc.

Originally posted by aths
Meine Wunschliste:

- FSAA einstellen kann
- AF einstellen kann.

[Börk]

Originally posted by vogel
FSAA - nein
AF - gibt es schon (LevelOfAnisotropy)

-- Daniel, Epic Games Inc.

aber nur in .ini

[Tom Servo]

Originally posted by Tom Servo
Der Unregistered war ich. Ist hier leider so, dass man über den direkten Link aus der Mail-Benachrichtigung immer Unregistered ist.


Achso, es gibt das Forum als .org und .net und man braucht Login-Cookies für beide Domains. Steht sicher in einer FAQ die ich nicht gelesen habe. Sorry.

[Pussycat]

kann man sich überhaupt irgendwo einloggen? Ich mache das immer mit 'change profile' und werde dann gefragt nach passwort... aber das muss doch auch irgendwie auf 'ne schöne Weise gehen, ned?

[Höhnangst]

Originally posted by Pussycat
kann man sich überhaupt irgendwo einloggen? Ich mache das immer mit 'change profile' und werde dann gefragt nach passwort... aber das muss doch auch irgendwie auf 'ne schöne Weise gehen, ned?

[Höhnangst]

Herr Gott im Himmel ...

Was ich eigentlich schreiben wollte:
Ja, das kann man tatsächlich ;). Auf der Forums-Hauptseite besteht rechts unten diese kleine aber feine Möglichkeit =). Das geht allerdings nur, wenn man nicht schon eingeloggt ist.