Starfield-Tuning: Szene 2, CPU-Tod New Atlantis
In diesem Artikel
- Seite 1 Starfield-Tuning: Einleitung
- Seite 2 Starfield-Tuning: Mit dem Privat-PC ins All
- Seite 3 Starfield-Tuning: Szenen und Messungen
- Seite 4 Starfield-Tuning: Szene 1, Vectera und die Tücken beim Benchen
- Seite 5 Starfield-Tuning: Szene 1, Vectera ist ein Mischling
- Seite 6 Starfield-Tuning: Szene 2, CPU-Tod New Atlantis
- Seite 7 Starfield-Tuning: Szene 3, Kein Krawall im All
- Seite 8 Starfield-Tuning: Szene 4 - Piazzi I, der Ritt auf dem Vulkan
- Seite 9 Starfield-Tuning: Szene 5 - Abendstimmung in Akila
- Seite 10 Starfield-Tuning: Finales Tuning und Fazit
- Seite 11 Bildergalerie
Nachdem wir bei der ersten Szene relativ viele Umstände und Eigenheiten erklärt haben, die gewissermaßen Besonderheiten bei Starfield darstellen er- und die Herangehensweise bei den Messungen und Einstellungen geklärt haben, können wir uns im Folgenden wohl etwas kürzer fassen. Sie, liebe Leser, sollen den bereits jetzt schon sehr ausführlichen Artikel ja nicht nur lesen und begreifen, ich muss ihn schließlich erst einmal schreiben. Es folgen noch eine ganze Reihe weiterer Szenen. Doch für diese können wir das Wissen, dass wir mit der ersten Szene auf Vecera erarbeitet haben, zurückgreifen.
Die zweite Szene für das Tuning-Vorhaben entführt uns nach New Atlantis auf dem erdähnlichen, von dichter Vegetation bedeckten Planeten Jemison. Jawohl, hier findet sich auch unser mörderischer GPU-Benchmark, allerdings in einer zufällig generierten Umgebung. In diese, aus mehreren Stadtteilen bestehende und von tropischer Vegetation umgebene Stadt gelangen Sie in den ersten Spielstunden. Sie werden im Verlauf außerdem mehrfach in das schick anzusehende, futuristisch-urbane und für Starfield dichtbevölkerte Szenario zurückkehren. Neben Auftragsgebern finden sich hier eine Reihe Geschäfte und Läden. Die Last ist, ob dem detaillierten Stadtszenario, völlig anders als in der ersten Szene, die eher grafiklastig ausfiel. Für unseren Benchmark laufen wir die Strecke im Video ab, die Messung geht in diesem Fall 55 Sekunden.
Im Video ist es bereits zu erahnen, nicht nur sind die Bildraten mit Ultra-Details und voller WQHD-Auflösung nochmals niedriger. Nein, es lassen sich auch mehrere, heftigere Stocker ausmachen (und an der Maus außerdem deutlich fühlen). Diese zeigen sich in Messungen mit allen Settings - ein sehr unschöner Umstand, denn das bedeutet, dass ich kaum eine Chance haben werde, diese Ruckler mit Tuning-Eingriffen im Optionsmenü zu beheben. Es handelt sich um irgendeine Form von Traversal- oder Streaming-Ruckler, der (auch) auf die CPU zurückfällt.
Eventuell würde es helfen, Starfield auf eine DDR4-NVME zu installieren. Ein schnellerer Porzessor, schnellerer RAM, all dies könnte abhelfen, würde auf meiner Seite allerdings auch ein Hardware-Upgrade erfordern. Mit einem stärkeren System wären diese Ruckler eventuell weniger ausgeprägt, den Xboxen hilft an dieser Stelle eventuell außerdem Direct Storage aus der Klemme. Ich habe aktuell weder das eine noch das andere, also muss ich mit zuckeligen Frametimes leben. Die einzige Alternative wäre ein 30-Fps-Lock, doch nur für eine oder einige wenige derart anspruchsvolle Szenen verzichte ich nicht im restlichen Spiel auf (zumindest annähernd) 60 Fps.
Grafisch halten sich die Unterschiede bei den Presets in Grenzen. Ab "Mittel" fällt die Auflösung der Schatten sichtbar deutlich ab, die Effekte wie Umgebungsverdeckung und GI werden ungenauer, die Reflexionen sind optisch undeutlicher und werden mit sichtbar zusätzlicher Verzögerung plus temporalem Verwischen gerendert und das NPC-Aufkommen wird merklich dünner. Wirklich hässlich ist indes im Direktvergleich nur das Preset "Niedrig" (bei voller WQHD-Auflösung wohlgemerkt!), hier nimmt ab mittlerer Distanz die gesamte Bildschärfe ab, Details zerkrümeln.
Wenn wir nun die dazugehörigen Performance-Metriken ins Auge nehmen, wird schnell klar, dass ich wenig an den minimalen Frameraten respektive den Ausreißern in den Frametimes tun kann. Diese gehen auf die CPU, respektive einen Thread zurück, der stets nahezu auf 100 % Last geht und somit auch die Grafikkarte ausbremst. Dies geschieht mit allen Grafikvoreinstellungen, kein einziges Setting wird mich vor dem Gezuckel bewahren können. Setze ich außerdem den Detailgrad herab, haben wir das altbekannte Problem: Die Last auf der GPU sinkt zusammen mit dem Detailgrad, die Fps erhöhen sich nur minimal und erhöhen wiederum die Last auf der CPU, die darauf noch mal schneller rechnen muss. Wenn die Fps steigen, muss auch die CPU mehr und vor allem schneller Arbeit leisten.
| Preset: | Fps/P1 | CPU load (%, min/avg/max) | CPU max thread load (%, min/avg/max) | CPU clock (MHz, min/avg/max) | CPU Power (Watt, min/avg/max) | GPU load (% min/avg/max) | Time in GPU load limit (%) | GPU clock (MHz, min/avg/max) | GPU power (Watt, min/avg/max) | GPU VRAM usage (GiByte, avg) |
|---|---|---|---|---|---|---|---|---|---|---|
| Ultra, native | 46,8/32,2 Fps | 34/46/71 % | 66/85/100 % | 4.000/4.041/4.100 MHz | 71/79/93 Watt | 72/95/98 % | 83 % | 1.650/1.691/1.740 MHz | 251/301/316 Watt | 6,2 GiByte |
| High, native | 52,2/33,2 Fps | 38/51/71 % | 71/87/100 % | 3.775/4.014/4.075 MHz | 56/82/94 Watt | 58/95/98 % | 69 % | 1.650/1.696/1.740 MHz | 231/292/309 Watt | 5,84 GiByte |
| Medium, native | 56,3/34,7 Fps | 40/54/74 % | 60/85/96 % | 3.975/3.990/4.025 MHz | 60/85/96 Watt | 52/91/98 % | 44 % | 1.635/1.698/1.740 MHz | 221/288/301 Watt | 5,67 GiByte |
| Low, native | 60,2/35,5 Fps | 47/55/72 % | 73/88/100 % | 3.975/3.988/4.025 MHz | 62/86/98 Watt | 50/84/97 % | 7 % | 1.680/1.729/1.740 MHz | 203/275/297 Watt | 5.61 GiByte |
Die Konsequenz ist, dass ich mit dem Absenken des Detailgrades die Last ein wenig von GPU zur CPU verschieben kann, die aber sowieso schon einen limitierenden Faktor darstellt. Nicht einmal zum Stromsparen eignet sich der optische Verzicht bei den Details in meinem Fall, dies würde erst mit einem begrenzenden Framelimit gelingen. Doch hier stehen nicht einmal wirkliche 60 Fps auf der Uhr, der Erfolg wäre selbst mit einem solchen eingeschränkt.
Es gibt also kaum etwas, was ich in diesem Fall tun kann, um die Performance deutlich zu verbessern. Ich kann allerdings versuchen, das Optimum aus dem System zu quetschen, die CPU so stark ausnutzen, wie es nur geht, ohne dabei die Grafikkarte bis ins Delirium zu langweilen. Bei vollen Ultra-Details ist diese zudem - trotz nahezu limitierender CPU - nahezu voll ausgelastet, Teile der Messung sind also tendenziell im Grafiklimit. Hier sollten sich ein paar Fps gut machen lassen.
| Maxed | Recommended (Ultra, FSR) | Tuned (scene 2) | |
|---|---|---|---|
| Dyamic Resolution | off | on | off |
| Render Resolution Scale | 100 | 75 (dynamic) | 75 (static) |
| Shadow Quality | Ultra | Ultra | High |
| Indirekt Lighting | Ultra | Ultra | High |
| Reflections | High | High | Medium |
| Particle Quality | High | High | Medium |
| Volumetric Lighting | Ultra | Ultra | Medium |
| Crowd Density | High | High | Medium |
| Motion Blur | High | High | High |
| GTAO Quality | Ultra | Ultra | Ultra |
| Grass Quality | Ultra | Ultra | High |
| Contact Shadows | Ultra | Ultra | Ultra |
| Upscaling | off | FSR 2 | FSR 2 |
| Enable VRS | off | off | on |
Wir nutzen die in der ersten Szene ausgearbeiteten, optimierten Grafik-Settings und reduzieren obendrein die Bevölkerungsdichte, die einer der wenigen Optionen ist, die merklich Auswirkungen auf die Prozessorlast haben, auf "Mittel". Obendrein verringern wir die Grasqualiät um eine Stufe, in der Hoffnung, mit nur "Hoch" durch weniger benötigte Renderansweisungen den Verwaltungsaufwand für die CPU minimal zu entlasten.
Gleiches versuchen wir mit der indirekten Beleuchtung sowie den Reflexionen. Zumindest theoretisch könnten Teile der Frametime-Spikes auf neu erstellte Cube Maps oder Daten für die Light Probes zurückfallen. Die Ruckler entstehen auffällig nahe bei Spiegelungen auf Wasser oder Fensterscheiben. Auch könnte das sichtbare Überblenden der GI beim Betreten der U-Bahn für eine erneute Berechnung verantwortlich sein, auch hier entsteht bei jeder Messung an immer der gleichen Stelle ein merklicher wie störender Ruckler.
Viel mehr bleibt uns nicht zu tun, wir haben nahezu das Optimum aus dem System herausgekitzelt. Sind 1-2 Fps mehr den zusätzlichen Detailverzicht wert? Das werden wir hoffentlich später besser entscheiden können. Kommen wir zur nächsten Szene. Dieses Mal geht es ins All, mit der weiten Leere wird es etwas simpler.
- Seite 1 Starfield-Tuning: Einleitung
- Seite 2 Starfield-Tuning: Mit dem Privat-PC ins All
- Seite 3 Starfield-Tuning: Szenen und Messungen
- Seite 4 Starfield-Tuning: Szene 1, Vectera und die Tücken beim Benchen
- Seite 5 Starfield-Tuning: Szene 1, Vectera ist ein Mischling
- Seite 6 Starfield-Tuning: Szene 2, CPU-Tod New Atlantis
- Seite 7 Starfield-Tuning: Szene 3, Kein Krawall im All
- Seite 8 Starfield-Tuning: Szene 4 - Piazzi I, der Ritt auf dem Vulkan
- Seite 9 Starfield-Tuning: Szene 5 - Abendstimmung in Akila
- Seite 10 Starfield-Tuning: Finales Tuning und Fazit

Mein niedrigstes war 36 FPS. Wir haben ja fast gleiches System nur dein VRAM taktet noch etwas höher und CPU hat x3D.
Argh, ich seh mein VRAM lief da gar nicht auf 2100 Mhz..
[Ins Forum, um diesen Inhalt zu sehen] Wie stellt man eigentlich die Auflösung für den CPU-Bench auf 720p? Ist immer grau. Ich kann nicht glauben, dass ich unter 30 falle. Vielleicht macht mein Ram was aus.
Manchmal habe ich mir einen Textbaustein schon so genau im Kopf zusammengebaut, dass ich vergesse, ihn zu schreiben.
Keine HDD mehr. Das OS liegt auf einer PCI-E-3.0-SSD, das Spiel ist auch auf einer NVME, aber die ist nur via SATA6 angebunden, nicht PCI-E. Dazu sind noch ein paar "normale" SATA-SSDs verbaut.
Ich ergänz das gleich mal. (Und fixe noch ein paar andere Dinge.)
War eigentlich halb so wild, aber ich hätte mir eventuell ein bisschen Auszeit gönnen sollen. Das hat mich wohl ein wenig umgehauen. Ansonsten hab ich's gut überstanden. Und allzu überrascht war ich auch nicht, ich hab mich ja kurz zuvor international mit tausenden anderen gedrängelt...
Gruß,
Phil
Argh, ich seh mein VRAM lief da gar nicht auf 2100 Mhz..
Argh, ich seh mein VRAM lief da gar nicht auf 2100 Mhz..