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

hübie · 25. November 2016

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...

Das schrieb ich ebenfalls ("[...] während back buffer und last rendered munter weiter swappen[...]"). Offenbar haben foxio und ich uns hier missverstanden. Per Definition meinerseits sind Bilder pro Sekund die Bilder welche ich sehe (bzw. dessen Wirkung ich sehe: schießen, laufen, springen usw.), nicht Bilder die berechnet und dann ohne hin verworfen werden.

foxio schrieb:
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.

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.

Wie oben bereits gesagt haben wir uns offenbar missverstanden. Sehr hohe FPS mögen zwar den input lag verringern, aber führen dafür auch mal zu einem Sprung in der Bewegung, was die kognitive Wahrnehmung irritiert. Ich schätze optimal wäre die Begrenzung der berechneten Bilder vom vielfachen der Puffer. Also 90 oder 180 Frames pro Sekunde. Keinesfalls darüber. Aber das muss ich mal eben durchdenken.

Adaptive sync ist dagegen nur ein abschalten der Synchronisation unterhalb der refresh rate des Monitors und aktivieren beim erreichen selbiger. Ob double oder triple buffered weiß ich gerade nicht. Ich meine das Axel Gneiting da was von triple buffer sagte.

ps: Tut mir leid dass ich so schroff rüber kam.

Jesterfox · 26. November 2016

Ich denke auch dass die Diskussion eher aufgrund von Missverständnissen so entstanden ist. In denn Fall muss man nicht nur zwischen den Hz vom Monitor und den ausgegebenen FPS sondern auch noch den im Hintergrund berechneten FPS unterscheiden.

Das Problem mit dem Begrenzen ist dass du das eigentlich nur so machen kannst das du erst berechnest und dann wenn das Limit erreicht ist aufhörst. Damit hast du aber immer das Problem dass du eigentlich veraltete Frames in den Puffern hast. An sich sollte da aber auch kein wirklicher Sprung auftreten, denn es wird ja der Frame ausgegeben dessen Entstehungszeitpunkt am besten im dem Ausgabezeitpunkt zusammenpasst.

Bei Adaptive Sync würde ein Tripple Buffering keinen Sinn ergeben, denn es würde zu jeder Zeit das schlechteste Verhalten bevorzugen... unterhalb der Monitorfrequenz hat man Tearing und Oberhalb den Input-Lag durch den Tripple-Buffer (ohne FastSync). Deswegen hab ich bisher Tripple-Buffer + VSync + FPS Limiter bevorzugt (Adaptive Tripple-Buffer ;-)

hübie · 26. November 2016

Wenn du das prerenderlimit auf 1 setzt hast du bei 60 Hz oder mehr auch nicht wesentlich mehr input lag. Das ist nämlich CPU-seitige Begrenzung. Leider hat das noch niemand getestet / empirisch nachgewiesen.

Jesterfox · 26. November 2016

Deaktiviert das nicht den Tripple Buffer komplett? (ich dachte zumindest immer dass das Prerender Limit unter D3D die zusätzlichen Buffer steuert)

hübie · 26. November 2016

Nein. Das sagt der CPU im Grunde nur ob schon neue Daten (Batches) für den nächsten Frame gesendet werden sollen. Standardmäßig nimmt die Graka drei 'Datensätze' für die nächsten drei Frames an. Senkst du das auf eins wird immer nur am aktuellen Bild gearbeitet. In Skyrim und BF4 bspw. konnte ich es teils deutlich spüren. Ich bemerkte zumindest den Unterschied zwischen 1 und 3. Bin mir nun aber auch nicht mehr sicher ob es schon für alle APIs funktioniert. Doom fühlte sich so gut an, dass ich da nach dem zweiten Patch nix mehr einstellen musste.

Jesterfox · 26. November 2016

Ist das nicht irgendwie das selbe? Es wird nur am aktuellen gearbeitet... es gibt also nur den FrontBuffer und den BackBuffer, keinen dritten für ein Bild das nur auf Ausgabe wartet.

Aber was ist wenn das noch nicht fertig ist und der Monitor ein neues braucht? Ich sprech also jetzt vom Fall das die GPU aktuell weniger FPS berechnet als der Monitor Hz hat.

hübie · 26. November 2016

Nein. Die Grafikpipeline ist ja recht 'lang'. Zuerst hast du ja Raster-Setup, Culling (Z-Test) und so etwas. Das ist sozusagen der Beginn, nachdem die CPU Daten übermittelt hat. Wenn du die vorgerenderten Frames auf 1 setzt, nimmt die DMA-Engine immer nur ein Bild an, nicht auch mal zwei bzw. drei (je nach CPU eben).

Sollte die Frametime höher sein, als der Scanout-Intervall wird Fast sync obsolet. Konkrete Nachteile sollte man vorerst nicht haben, aber da hab ich ehrlich gesagt keine praktische Erfahrung. Im schlimmsten Fall wird ein Bild zwei mal angezeigt.

kisser · 27. November 2016

Jesterfox schrieb:
Ich denke auch dass die Diskussion eher aufgrund von Missverständnissen so entstanden ist. In denn Fall muss man nicht nur zwischen den Hz vom Monitor und den ausgegebenen FPS sondern auch noch den im Hintergrund berechneten FPS unterscheiden.

Nein, das muss man nicht unterscheiden, weil die angezeigten Frames immer der Refreshrate (Hz) des Monitors entsprechen.
fps bezieht sich immer auf die Berechnungsgeschwindigkeit der GPU.

fps > Hz: es wird immer eine neuer Frame ausgegeben
fps < Hz: es werden Frames mehrfach ausgegeben

hübie · 28. November 2016

Das sehe ich anders. Es gibt einmal berechnete Frames und ausgegebene Frames. Warum soll man dies nicht unterscheiden? Daher rührte ja das Missverständnis. Relevant sind letztendlich nur die, welche man zu Gesicht bekommt. Und das Frames mehrfach ausgegeben werden stimmt so auch nicht bedingungslos. Man darf nicht vergessen, dass es keinen Reset alle 60 Sekunden gibt, sondern dass es ein konstanter Strom ist. Weiterhin gibt es variable Refreshrates mit blank intervallen aka G-Sync und Freesync.

Sanjuro · 7. Januar 2017

Kann mir an dieser Stelle jemand sagen ob es nun mal aktuelle Benchmarks gibt welche Vulkan testen ? Seit Juli /16 gibt
es keine offiziellen Benchmarks mehr im Netz. Ich frage mich ob es noch Perfomance-Verbesserungen durch die neuesten Treiber gibt. Nach letztem stand hat nvidia unter der Vulkan-Api bei den Frametimes schlechtere Werte als OpenGL 4.5.

hübie · 9. Januar 2017

Es schwankt. Vulkan hat hier und da noch Probleme. Es gibt Stellen im Spiel die unerklärlich langsam laufen. Insgesamt wirkt es aber ausgereift. Im Blindtest würde glaub ich keiner feststellen was was ist. Zumindest kann ich das auf meiner 980 Ti so berichten.

Edit: Guck dir diese Stelle z.B. an:

Läuft mit nur 56 fps. Schwenk nach rechts, wo deutlich komplexere Szene ist (Alpha, screenspace reflections etc.) und es sind 61 fps. Da muss also noch nach wie vor Arbeit investiert werden. Ich glaube bei Doom wird aber nix mehr passieren.

Sanjuro · 9. Januar 2017

@hübie

ok danke für deine Erfahrung, wenn ich mir dein screenshot ansehe fällt mir auf das die frametimes sehr gleichmäßig verlaufen. Bei den exakt 56 in ca. 10min hast du keine ausreisser unter 17 und über 18 ms. Wenn das das nur bei Vulkan so ist, wäre das schon für mich ausschlagebend gegenüber OpenGL.

HisN · 14. Februar 2017

Das OSD vom Afterburner geht jetzt auch mit Vulkan.

I Like (noch mehr würde ich 66% Mehrperformance mögen, aber irgendwo muss man mal realistisch bleiben^^), bzw. irgend einer Anzeige muss man mehr Vertrauen^^

VikingGe · 16. Februar 2017

I Like (noch mehr würde ich 66% Mehrperformance mögen, aber irgendwo muss man mal realistisch bleiben^^)

Takte halt deine CPU auf 1.0 GHz oder sowas.

Auf meiner Gurke ist das Spiel teilweise mit Vulkan jedenfalls (zumindest da, wo ich mal nachgesehen habe) mehr als doppelt so schnell, ist allerdings auch AMD-Hardware.

Nai · 16. Februar 2017

@ VikingGe
Schön, dass du wieder da bist, nachdem du deinen Account hast löschen lassen. Ich habe deine Posts zu CPUs immer wieder gerne gelesen

Suche

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

hübie

Lt. Commander

Jesterfox

Legende

hübie

Lt. Commander

Jesterfox

Legende

hübie

Lt. Commander

Jesterfox

Legende

hübie

Lt. Commander

kisser

Admiral

hübie

Lt. Commander

Sanjuro

Lt. Commander

hübie

Lt. Commander

Sanjuro

Lt. Commander

HisN

Fleet Admiral

VikingGe

Lt. Junior Grade

Nai

Lt. Commander

Ähnliche Themen