Bericht Doom mit Vulkan: Benchmarks zeigen bis zu 66 Prozent mehr FPS

Sicher, dass du dem Nvidia-Control-Panel sagst, es soll die Anwendungseinstellungen verwenden?

Wenn ich VSync aktiviere, habe ich Inputlag und die bekannte Begrenzung auf 60fps. Mit adaptive VSync habe ich die Begrenzung nicht und keinen Inputlag. Vielleicht ist das tatsächlich ein Treiberbug (ich habe eine AMD-Karte).
 
Ich glaube eher, dass es an der API liegt.
In sonst KEINEM anderen game, in KEINER anderen API probleme, wenn ich VSync einschalte. Perfekt flüssig (naja, soweit, wie 60 fps halt flüssig ist...). NUR bei Doom krieg ich es nicht sauber hin, auch unter OpenGL.
Vll liegt es auch nur an der Engine....


Edit: https://www.reddit.com/r/nvidia/com..._stealthily_added_official_fast_sync/d6ko491/
Schade, nicht kompatibel zu OpenGL. Und Vulkan ebenso.

Die hätten Doom lieber in DX11 programmieren sollen, als OpenGL ^^

Naja, gut dass ich so oder so mit dem gedanken spiele, nen GSync 144+ Hz Monitor zu kaufen, völlig unabhängig von Doom^^

foxio schrieb:
Sicher, dass du dem Nvidia-Control-Panel sagst, es soll die Anwendungseinstellungen verwenden?

Wenn ich VSync aktiviere, habe ich Inputlag und die bekannte Begrenzung auf 60fps. Mit adaptive VSync habe ich die Begrenzung nicht und keinen Inputlag. Vielleicht ist das tatsächlich ein Treiberbug (ich habe eine AMD-Karte).

Ganz sicher^^

Das mit dem Treiber kann sein. Hab kurz etwas gegoogelt in nem Doom-Thread im steam forum. Dort wird das Adaptive VSync von Doom genau so beschrieben, dass es VSync deaktiviert, sobald man unter die Refreshrate des Monitors fällt.
 
Zuletzt bearbeitet:
Grausam was hier schon wieder für Müll verteilt wird.

@foxio: Versuch mal das: https://www.forum-3dcenter.org/vbulletin/showpost.php?p=11115085&postcount=3301

Inspector herunterladen und dann dreh mal am swap-interval. Auch wenn da OGL steht hatte es eine Auswirkung auf Vulkan. Aber bei dir ist irgendwas nicht richtig, denn ich kenne es so wie Darkseth88 es sagt: Ist adaptive V-sync an wird unterhalb der refresh rate nicht synchronisiert und ab 60 wird synchronisiert (in deinem Fall halt). Meine Empfehlung für tearingfreies Spielen mit geringst möglich input lag ohne G-Sync: V-Sync im Spiel und auf 58 fps begrenzen. Soviel ich weiß hat Doom triple buffer in Vulkan. Sonst forcier das mal im Treiber, der hat wie gesagt einen Einfluss auf Vulkan.
 
Warum sollte ich etwas verändern? Bei mir läuft es flüssig - ohne Inputlag und ohne Tearing. Und wie bereits gesagt: Das Ingame-"adaptive VSync" arbeitet bei mir offensichtlich anders (AMD-Karte) als das was Nvidia mit adaptive VSync bezeichnet. Wäre mal interessant, wie sich die Option bei anderen AMD-Nutzern auswirkt.
 
Ich bin jetzt verwirrt.
Was genau soll das Adaptive Vsync IN DOOM genau machen?
Hab die Demo in meinem 2. PC mit einer 380x gezockt und via Vulcan @Ultra 60-120fps jenach Szene. Die Demo ist das komplette erste Level.
Aber ich sehe 0 unterschied zwischen Vsync Adaptiv und Vsync Aus Oo
Fps sind immernoch unbegrenzt und Tearing ist auch vorhanden
 
Danke. Ich habs nochmal getestet und komme jetzt zu dem gleichen Ergebnis. "Adaptive VSync" fühlt sich genauso an wie "VSync aus" (Tearing + keine FPS-Begrenzung). Das Tearing habe ich anscheinend zuvor nur nicht bemerkt in der Demo (am besten sucht man sich ne Szene mit vertikalen Strukturen). Also hat "adaptive VSync" gar keine Funktion (zumindestens auf AMD-Karten)?
 
foxio schrieb:
Warum sollte ich etwas verändern? Bei mir läuft es flüssig - ohne Inputlag und ohne Tearing. Und wie bereits gesagt: Das Ingame-"adaptive VSync" arbeitet bei mir offensichtlich anders (AMD-Karte) als das was Nvidia mit adaptive VSync bezeichnet. Wäre mal interessant, wie sich die Option bei anderen AMD-Nutzern auswirkt.

Hab euch verwechselt. Mea culpa.

Anscheinend ist adaptive V-Sync auf AMD kaputt. Mit älterem Treiber ging es aber wie es sollte. Also Framecap bei Monitor-Refresh weil ab da synchronisiert wird. Wie du es beschrieben hattest macht es überhaupt keinen Sinn. Warum will man bei wenig fps an syncen und alles über dem Schwellwert des Monitors einfach ungebremst darstellen???
 
Kann bestätigen, dass da irgendwas nicht mehr funktioniert. Auch der treiberseitige FPS-Limiter, der bei mir auf 120 FPS steht, scheint in Doom nicht mehr zu greifen, in anspruchslosen Szenen werden auch mal 180 FPS angezeigt. :freak:

Insofern etwas nervig, als dass das Spiel bei maximalen Einstellungen hier und da mal in den 70er-Bereich dropt und sich 70-80 FPS auf nem 60 Hz-Bildschirm unglaublich mies anfühlen, im Vergleich zu stabilen 60 oder 90+. Normales Vsync ist dank extremem Input Lag unbenutzbar.

Wobei ich die Einstellungen ehrlich gesagt auch noch nicht nach nem spielinternen FPS-Limiter durchforstet habe...
 
hübie schrieb:
Hab euch verwechselt. Mea culpa.

Anscheinend ist adaptive V-Sync auf AMD kaputt. Mit älterem Treiber ging es aber wie es sollte. Also Framecap bei Monitor-Refresh weil ab da synchronisiert wird. Wie du es beschrieben hattest macht es überhaupt keinen Sinn. Warum will man bei wenig fps an syncen und alles über dem Schwellwert des Monitors einfach ungebremst darstellen???

Das macht schon Sinn. Fast Sync von Nvidia macht ja das gleiche - die Anzahl der berechneten Bilder wird nicht begrenzt, aber die Bildausgabe erfolgt synchron. So wird die Zeitspanne zwischen Benutzereingabe und Monitorausgabe verringert (geringerer Inputlag) und Tearing verhindert. Ich dachte, es funktioniert ähnlich wie Fast Sync, da ich eben kein FPS-Limit bei mir festgestellt habe. Leider habe ich erst nicht bemerkt, dass es trotzdem Tearing gibt ;)
 
Gut, dachte schon bei mir sei was kaputt xD

VikingGe schrieb:
Kann bestätigen, dass da irgendwas nicht mehr funktioniert. Auch der treiberseitige FPS-Limiter, der bei mir auf 120 FPS steht, scheint in Doom nicht mehr zu greifen, in anspruchslosen Szenen werden auch mal 180 FPS angezeigt.

Wobei ich die Einstellungen ehrlich gesagt auch noch nicht nach nem spielinternen FPS-Limiter durchforstet habe...
Der FPS Limiter von Crimson funktioniert glaube ich unter Vulcan nicht.
Im Spiel selber gibts keine Option fürs begrenzen
 
foxio schrieb:
Das macht schon Sinn. Fast Sync von Nvidia macht ja das gleiche - die Anzahl der berechneten Bilder wird nicht begrenzt, aber die Bildausgabe erfolgt synchron. So wird die Zeitspanne zwischen Benutzereingabe und Monitorausgabe verringert (geringerer Inputlag) und Tearing verhindert. Ich dachte, es funktioniert ähnlich wie Fast Sync, da ich eben kein FPS-Limit bei mir festgestellt habe. Leider habe ich erst nicht bemerkt, dass es trotzdem Tearing gibt ;)

Erzähl keine Märchen! Fast sync ist nichts weiter als Triple Buffering mit prerenderlimit=1. Woher nimmst du deine merkwürdigen Aussagen? Wozu soll es dienen fps nach unten zu begrenzen? Das liegt einzig an deiner Hardware, wenn das Programm nicht gerade verbuggt ist, das sicherzustellen.
 
Ich erzähle keine Märchen. Dass Fast Sync einen Triple Buffer nutzt, weiß ich. Fast Sync führt zu dem Verhalten, das ich beschrieben habe (keine FPS-Begrenzung + synchrone Bildausgabe). Da bei mir die Ingame-Option "adaptive Sync" augenscheinlich zu dem gleichen Verhalten führte, wie es auch Fast Sync tut, habe ich erst angenommen, dass "adaptive Sync" in Doom ähnlich funktioniert wie Fast Sync von NVidia.
Und welche merkwürdigen Aussagen? Dass die FPS nach unten begrenzt werden, habe ich nie gesagt.
 
Blödsinn. Fast-Sync synchronisiert mit triple buffer bis hinauf zu der nativen refresh rate des Monitors (inklusive der Tatsache nur ein Bild im Voraus zu rendern). Ist dies nicht der Fall ist bei dir was kaputt. Wie soll es auch gehen, dass man ohne FPS-Begrenzung noch synchron fahren kann?? Der Monitor kann ja nur bis 60, 120, 144, 165 oder 240 Hertz synchron laufen. Je nach Modell halt. Sind die Frametimes höher als der scanout, kommt das dreifache Puffern zum Tragen.
Adaptive sync in Doom: Sind die Frametimes höher als der Scanout wird nicht synchronisiert. Sind die Frametimes gleich dem Scanout wird synchronisiert. Kommst du auf mehr FPS als dein Monitor an Frequenz hat ist was kaputt, denn dann hat das System (und die Bezeichnung) keine Bedeutung mehr.
Also entweder drückst du dich falsch aus, ich nehme es falsch auf, bei dir ist was kaputt oder du erzählst Märchen. Such dir was aus. Ich erkläre es sonst gerne noch einmal.
 
Du hast offenbar Fast Sync nicht verstanden. Der Begriff FPS kann in dem Kontext aber leicht missverstanden werden. Deshalb habe ich zunächst auch geschrieben "die Anzahl der berechneten Bilder wird nicht begrenzt". Es ist in dem Fall sehr wohl möglich, die Bildausgabe synchron zu halten (was Fast Sync ja auch tut).
Sind die Frametimes höher als der scanout, kommt das dreifache Puffern zum Tragen.
- Nein....
Der Sinn hinter Fast Sync ist es den unter VSync üblichen Inputlag zu reduzieren, gleichzeitig aber auch kein Tearing zuzulassen.
Das wird dadurch erreicht, dass nach der Berechnung eines Bildes nicht etwa auf einen neuen Refresh-Zyklus des Monitors gewartet wird (wie beim bekannten VSync), sondern sofort mit der Berechnung eines weiteren Bildes begonnen wird - deshalb wird auch der Triplebuffer benötigt. Synchronisiert wird dann immer das AKTUELLSTE berechnete Bild am Monitor dargestellt. Deshalb ist es möglich, dass mehr Bilder berechnet werden, als am Monitor dargestellt werden.
 
I sure hope you weren’t tried of technologies that end with “sync” because NVIDIA is releasing another one with the GTX 1080. FastSync is an alternative to Vsync On and Vsync Off states, but is not variable like G-Sync or FreeSync. The idea is straight forward: decouple the render pipe from the display pipe completely and there a lot of interesting things you can do. FastSync tells the game engine that Vsync is OFF, allowing it to render frames as fast as possible. The monitor is then sent frames at its maximum refresh rate but only completely rendered frames, avoiding the tearing artifacts usually associated with Vsync Off states.

FastSync creates a virtual buffer system that includes three locations. Front buffer, back buffer and the last rendered buffer. The front buffer is the one that is scanned out to the monitor at the same speed as the display refresh rate. The back buffer is the one that is being rendered to by the GPU and cannot be scanned out until it’s complete. The last rendered buffer will hold all new frames just completed in the back buffer, essentially saving a copy of the most recently rendered frame by the game. When the front buffer is finished scanning to the display, then the last rendered buffer would be copied to the front buffer and scanned out.

Interestingly, because buffer copies would take time and add latency, the buffers are just dynamically renamed. In high frame rate games the LRB and BB would switch positions concurrently at the render rate of the application, and when the FB had completed its most recent scan out, the current LRB would be renamed to the FB, immediately starting its scan out.

The usage model for FastSync is games that are running at very high frame rates (competitive gaming) and thus have to decide between the high input latency of Vsync On or the screen tearing of Vsync off. For CS:Go gamers that are used to hitting 200 FPS, you’ll be able to play the game tear-free with only a very slight increase in latency, about 8ms according to NVIDIA.

This is definitely something that should only be enabled in the NVIDIA Control Panel for those games that are running at frame rates well above the maximum refresh rate of your display. FastSync will be its very nature introduce some variability to the smoothness of your game, as it is “dropping” frames on purpose to keep you time with the refresh of your monitor while also not putting backpressure on the game engine to keep timings lined up. At high frame rates, this variability issue isn’t really an issue as the frame times are so high (200 FPS = 5ms) that +/- 5ms is the maximum frame to frame variance you would see. At lower frame rates, say 45 FPS, you could get as much as a 22ms variance.

Quelle

Soll ich das nun noch ausführen? :rolleyes: Wenn du es jetzt noch nicht begriffen hast dann ist für mich eod. Nichts für ungut. Ich diskutiere gerne. Aber wenn du etwas nicht kennst oder falsch verstehst, ich es dir erkläre und du darauf behaarst es ist wie du sagst, dann will ich irgendwann nicht mehr. Lernresistent nenne ich es dann.

Edit: Zusammengefasst: Durch das Entkoppeln der Puffer und der dynamischen Umbenennung reduziert sich die Eingabeverzögerung. Scanout findet stets mit der maximalen refresh rate statt wenn frametimes niedriger sind als die Freuquenz (1/T). Frametimes als Inverse der FPS, da präziser.
 
Zuletzt bearbeitet:
Er hat es aber - offensichtlich im Gegensatz zu dir - begriffen.
Fastsync begrenzt nicht die Geschwindigkeit mit der die Frames berechnet werden, es begrenzt nur die Ausgabe auf dem Miontor auf dessen Refresh-Rate. Was anderes hat foxio nie geschrieben.
 
A) Stimmt das nicht, denn wenn es eine begrenzte Anzahl an Puffern gibt und ein Scanout nur von fertig gerenderten Bildern statt findet hat man sehr wohl weniger berechnete FPS. Renaming der front und last render buffer findet nur statt wenn der scanout aus dem frontbuffer vollständig ist.
B) Kann man physisch nicht mehr Bilder pro Sekunde darstellen als der Monitor, wenn es kein Tearing geben soll. Ergo hat man weniger dargestellte FPS. Was berechnet wird ist erst mal unerheblich - je größer die Differenz aus Frequenz des Monitors und berechnete Bilder desto hässlicher wird es. Es wird in der swapchain immer das Bild mit der kleinsten Zeitdifferenz aus den Zeitstempeln zwischen last rendered buffer und front buffer zum scanout freigegeben, während back buffer und last rendered munter weiter swappen, was die GPU her gibt.

Wenn du behauptest ich habe etwas nicht begriffen, dann erleuchte mich. :rolleyes:
 
Falsch, ein Buffer-Renaming findet auch während dem Scanout des Front-Buffers statt, aber nur zwischen den 2 Back-Buffern (steht auch in deinem Zitat das LRB und BB wechseln). Und genau dadurch kann ständig ein neuer Frame berechnet werden, eben weil der veraltete Back-Buffer überschrieben wird.

Was ich mich an der Stele nur frage ob das wirklich besser als die andere variante mit dem "normalen" Triple-Buffering und einem FPS-Lock ist. Zumindest dürfte die Grafikkarte mehr Strom verbrauchen...
 
hübie schrieb:
A) Stimmt das nicht, denn wenn es eine begrenzte Anzahl an Puffern gibt und ein Scanout nur von fertig gerenderten Bildern statt findet hat man sehr wohl weniger berechnete FPS. Renaming der front und last render buffer findet nur statt wenn der scanout aus dem frontbuffer vollständig ist.
B) Kann man physisch nicht mehr Bilder pro Sekunde darstellen als der Monitor, wenn es kein Tearing geben soll. Ergo hat man weniger dargestellte FPS. Was berechnet wird ist erst mal unerheblich - je größer die Differenz aus Frequenz des Monitors und berechnete Bilder desto hässlicher wird es. Es wird in der swapchain immer das Bild mit der kleinsten Zeitdifferenz aus den Zeitstempeln zwischen last rendered buffer und front buffer zum scanout freigegeben, während back buffer und last rendered munter weiter swappen, was die GPU her gibt.

Wenn du behauptest ich habe etwas nicht begriffen, dann erleuchte mich. :rolleyes:

Die Bildberechnung (bzw. das Rendern der Bilder) ist bei Fast Sync von der Bildausgabe entkoppelt. Wenn ich in dem Kontext von FPS schreibe, meine ich die Anzahl der berechneten Bilder pro Sekunde.

Wie bereits auch von anderen gesagt: Ein Puffer (Backbuffer) steht der Gameengine immer zur Verfügung - d.h. die Gameengine wird nicht ausgebremst und kann mit voller Geschwindigkeit Frames berechnen. Ist der Frame im Backbuffer fertiggestellt, wird der Backbuffer zum Last-Rendered-Buffer und der LRB zum BB. Somit steht wieder ein "leerer" BB für einen neuen Frame zur Verfügung. Sobald ein neuer Refresh-Zyklus des Monitors beginnt, wird der LRB zum Frontbuffer - das aktuellste Frame wird damit synchronisiert am Monitor ausgegeben.

Das "Umbennen der Puffer" um das Kopieren der Puffer zu vermeiden ist übrigens ein absolutes Standardvorgehen.
Du hast ja angedeutet, dass dies der Clou hinter Fast Sync wäre - ist es nicht.

Jesterfox schrieb:
Falsch, ein Buffer-Renaming findet auch während dem Scanout des Front-Buffers statt, aber nur zwischen den 2 Back-Buffern (steht auch in deinem Zitat das LRB und BB wechseln). Und genau dadurch kann ständig ein neuer Frame berechnet werden, eben weil der veraltete Back-Buffer überschrieben wird.

Was ich mich an der Stele nur frage ob das wirklich besser als die andere variante mit dem "normalen" Triple-Buffering und einem FPS-Lock ist. Zumindest dürfte die Grafikkarte mehr Strom verbrauchen...

Es ist besser im Sinne von "geringerer Inputlag", wenn man sehr hohe FPS hat. Ja, die Grafikkarte dürfte mit Fast Sync mehr Strom verbrauchen als mit VSync an, da bei letzterer Option die Karte auf 60 Bilder begrenzt wird. Bezüglich des Stromverbrauchs sollte es deshalb keinen Unterschied von Fast Sync zu "VSync AUS" geben.
 
Ja, stimmt. Beim nochmaligen drüber Nachdenken wird's klarer. Der FPS Lock verhindert zwar ein Vorausrendern in den dritten Buffer, aber trotzdem wird das Bild im 2. Buffer sofort erzeugt und danach erst mal die Arbeit eingestellt. Die Verzögerung wird durch den FPS Lock zwar geringer (von 2 auf 1 Frames) aber nicht so niedrig wie mit Fast-Sync (0 Frames)
 
Zurück
Oben