WCM Forum - 18 fps sind möglich (FSX)!

So, Teil 2 - war grad in Schreiblaune und Forum mag keine langen Beiträge.

Zitat:

Und was ist der Rand des Zumutbaren für Direct3D? Magst Du uns da mal einweihen? Faend ich jedenfalls ziemlich spannend.

Dann frag mal Phil vom ACES team, wenn Du es *mir* nicht glauben magst.

Der ist nämlich der gleichen Meinung und von dem stammt auch die Information, dass der FSX Direct3D bzw. den Videotreiber unter XP zu stark belastet (weil einfach viel zu viele draw calls pro frame abgesetzt werden, und *jeder* draw call durch den Kernel an den Treiber geht und dadurch zwangsläufig ein Ring3->Ring0 Wechsel stattfinden muss, sprich der Ausführungskontext wechselt vom usermode in den kernelmode und dann, sobald der Treiber seine Arbeit erledigt hat, natürlich wieder zurück).

Der wirds wissen, hat er doch einen Teil der 3d engine designed. Der kann Dir die Sache mit dem "GPU offloading" sicher auch noch besser erklären und der allgemein vorherrschenden Meinung, "man könne ja einfach einen Teil der Berechnungen auf die GPU schieben" recht schnell den Wind aus den Segeln nehmen. *Wenns* nämlich so einfach wäre, dann wäre es passiert, weil dort sitzen auch keine Idioten, sondern fähige Programmierer. Es ist aber nicht so einfach, genau so wenig wie es einfach ist, eine so komplexe software einfach mal in ein paar threads zu zerlegen, damit sie auf multicore Systemen besser läuft. Das sind alles nichttriviale Probleme und damit kämpfen selbst die großen 3d gurus (carmack, sweeney & co.) seit Jahren und so langsam bekommen sie es hin.

Und laut ihm wird DirectX 10 vor allem deswegen Besserung bringen, weil es Direct3d calls am Kernel vorbei, direkt an die Hardware liefern kann (das allerdings NUR unter Vista und mit dem neuen LDDM Treibermodell - auch einer der Gründe, warum das unter XP vorerst nicht laufen wird, da XP so einen Schnickschnack nicht unterstützt, sondern *jeden* hardwarezugriff über den Kernel abwickeln will).

Der gesamte rendering code läuft aber auf der CPU (auch wenn es Leute gibt, die glauben, er liefe auf der GPU, was völliger Quatsch ist)

Zitat:

Was? Jetzt ist am Ende also doch die GK und nicht die CPU Schuld? Der Memory Bandwith ist es übrigens ganz bestimmt nicht, denn hier nutzt der FSX wesentlich weniger als vorhanden. Kannst ja mal Deinen PCIe Bus von 16 auf 8 unterfahren. Da ändert sich absolut gar nichts.

*seufz*
Die memory bandwidth *auf* der Karte. So schwer zu verstehen? Der bus zwischen VRAM und GPU. Wen interessiert denn der PCIe? Da wandert jede Textur genau *einmal* vom Hauptspeicher auf die Karte - dort wandert sie zigmal zwischen GPU und VRAM hin und her (z.b. beim filtern, rendern usw.).

Zitat:

Auf mein eigentliches Argument bist Du aber gar nicht eingegangen. In deinem ersten Beitrag zum Thema hast Du noch verkündet das Flugmodell und Navigation Schuld seien, an der schlechten Performance des FSX.

Wo genau steht das bitte? Ich sagte ausschließlich, der FSX ist *cpu limited*. Wie jeder andere FS davor, weil eben die CPU Unmengen an Sachen berechnen muss (das Flugmodell ist nur ein Teil davon). Und ja, natürlich hat sich das im FSX nochmal erhöht, denn es gibt nun noch mehr bewegliche Objekte deren Bewegungen natürlich auch irgendwie berechnet werden müssen.

Zitat:

In deinem zweiten Beitrag machst du nun das neue Szenerie Modell verantwortlich. Mal abgesehen davon das sich eben dieses besonders dazu eignet teilweise auf die GPU ausgelagert zu werden,

Nein, eben nicht. Das *rendering" (und auch davon nur gewisse Teile) lässt sich auf die GPU auslagern. Wenn Du nun glaubst, das wäre alles was eine 3d engine tut, um die schönen Bildchen auf den Schirm zu bringen, dann liegst Du ziemlich falsch. Bevor überhaupt erst mal ein einziges byte zur Grafikkarte wandert, ist eine Menge Vorarbeit notwendig, um die Szenerie aufzubauen. Und in dieser Phase hat die GPU Pause. Wie gesagt, quellcode holen, lesen, versuchen zu verstehen. Ist nicht schwer, wenn man mal weiß, worum es geht. Das Prinzip ist bei jeder 3d engine gleich, nur die Art und Weise wie eine Szenerie aus den Ausgangsdaten aufgebaut wird, unterscheidet sich zwischen einem Flusi und einem 3d shooter schon ganz gewaltig.

http://www.flightgear.org - kompletter open source flusi, inkl. mesh terrain- engine. Ist zwar in OpenGL umgesetzt, das tut aber nix zur Sache. Dort mal gucken, wie viele codezeilen nur für den Aufbau des terrains notwendig sind - natürlich pro frame, und wenn Du jetzt die Bildqualität von flightgear mit der vom FSX vergleichst, sollte klar sein, dass der FSX mindestens *5 mal* so viel tut, bevor er auch nur Anstalten macht, das Bild zu rendern.

Zitat:

hast Du uns nicht erklärt warum die Frames sich verdoppeln und verdreifachen wenn man sich mit Texturen, Autogen und Bumpmapping beschäftigt (soll heißen: tweakt).

Hab ich wohl. Lies nochmal die Bemerkungen bezüglich Video RAM und Speicherbandbreite (auf der Videokarte). *Dort* schlägt der FSX ziemlich teuflisch zu und wenn VRAM zu knapp wird, dann werden Texturen ausgelagert und Direct3d muss ständig (u.u. auch zwischen einzelnen frames) Texturen swappen. Das kostet.

Im AVSIM Forum hat jemand einen Test veröffentlicht, der ganz klar zeigte, dass der FSX praktisch IMMER deutlich mehr als 256 MB Grafikspeicher benützt. Das ist, wenn die karte nur 256 hat, sehr schlimm, weil dann ständig Texturen geswappt werden müssen. Reduziert man den Speicherbedarf der Texturen, kann sich das ziemlich signifikant auf die performance auswirken. Sehr einfach zu erklären.

Bumpmaps sind auch nur texturen und erfordern daher einen zusätzlichen renderdurchlauf pro frame.

Lightbloom ist z.b. ein recht komplexer shadereffekt. Auch das killt im FSX evt. die performance, wiederum weil dieser effekt zuätzliche renderpasses benötigt und dadurch wieder massenhaft Daten zwischen GPU und VRAM umhergeschaufelt werden.