Diskussion zu: Tweaktool "Radeon Pro": Mit Frameraten-Limitierung gegen die Mikro...

[Leonidas]

Link zur News:
http://www.3dcenter.org/news/tweaktool-radeon-pro-mit-frameraten-limitierung-gegen-die-mikroruckler-problematik-bei-amd

[aufkrawall]

Ich denke nicht, dass das Frame Metering bei Nvidia der große Bringer ist.
Ohne Limit und astronomische fps, gibt es immer irgendwo Mikroruckler.
Deshalb sollte das mGPU ja auch möglichst schnell sein, sodass man ohne wirkliche Nachteile Vsync/fps-Limit nutzen kann.

Zum Artikel von Tom's Hardware kann ich eigentlich nur noch anmerken, dass er totaler Quark ist.

[boxleitnerb]

Passt bloß auf, gleich kommen gewisse Elemente und beschweren sich, dass Leonidas die tolle AMD-News schlechtredet...

Ich hab anfangs Framelimiter mit Begeisterung eingesetzt, jetzt tue ich das abseits von Bereichen um VSync herum (59-60fps), wo sowieso eine Begrenzung stattfindet, nicht mehr - exakt aus den in der News genannten Gründen.

Für die VSync-Fraktion ist es eine gute Lösung. Beim Rest muss man pro Spiel abwägen. Wobei ich in den meisten Spielen bei 60fps keine Mikroruckler mehr feststellen kann - die sind eher bei niedrigeren fps und hoher GPU-Last ausgeprägt. Ich nutze den Limiter hauptsächlich zur Inputlag-Reduzierung.

[Gipsel]

Da RadeonPro auch die Änderung des Limits während des Spiels (über Hotkeys) und das Monitoring der GPU-Last ermöglicht, müßte man doch jetzt mal beides über einen (schnellen) Regelmechanismus koppeln können. So ungefähr:
If (GPU-Last>95%) Framelimit-=5fps;
If (GPU-Last<85%) Framelimit+=5fps;

Okay, ein bißchen ausgefeilter könnte man das schon noch machen, aber nur mal so als Idee, wie das im Prinzip aussehen könnte.

[ENKORE]

Eigentlich hat das nix mit der GPU-Last zu tun, sondern mit der FPS-Historie. Das Tool müsste also lediglich die reale (!) Renderzeit über die letzten paar hundert Frames ermitteln. Daraus ergibt sich dann die durchschnittlichen FPS, wenn nicht gebremst worden wäre. Damit kann man dann mittels eines festen Faktors eine neue Schranke berechnen. Diese Berechnung müsste jeden Frame gemacht werden, außerdem wäre es sinnvoll die Schranken zu glätten. Durch die Anzahl von "paar hundert Frames" ergibt sich die Regelungsverzögerung...

[Gipsel]

Zu kompliziert und zu langsam. Die paar hundert Frames dauern ja im Zweifelsfall ein paar Sekunden. Die Sache mit der GPU-Last ist zwar im Prinzip nur ein Hack, dürfte aber sehr schnell halbwegs gut funktionieren.

Und man kann es ja verbessern, in dem man keine festen Schwellen und Schrittweiten hernimmt, sondern das Framelimit so anpaßt, daß man möglichst auf 95% oder meinetwegen auch 97% GPU-Last kommt (und damit nur ~5% bzw. 3% Performance verliert). Das kann man jeden Einzelframe machen und aus der GPU-Last während des Frames direkt die vermutlich benötigte Renderzeit für den nächsten Frame schätzen und so das Limit anpassen. Je nach Spielengine sollte man vielleicht noch einen gleitenden Durchschnitt über 2 oder 3 Frames machen, aber das dürfte so gut sein, wie es je mit AFR werden kann.

Edit:
Im Prinzip können Spiele- bzw. Engine-Entwickler sowas direkt ins Spiel integrieren (auch ohne GPU-Last, einfach aus den Renderzeiten der einzelnen Frames). DX erlaubt eigentlich Kontrolle darüber. Aber der Markt ist offensichtlich zu klein, so daß sich keiner die Mühe macht.

[Gast]

Das Tool hört sich interessant an. Wie stabil läuft es denn mit den neusten Treibern? Ich könnte es für einige ältere Spiele gebrauchen bei denen frames jenseits von 1500fps anliegen, da gibt es dann gut und gerne das ein oder andere Spulenfiepen.

[samm]

Da RadeonPro auch die Änderung des Limits während des Spiels (über Hotkeys) und das Monitoring der GPU-Last ermöglicht, müßte man doch jetzt mal beides über einen (schnellen) Regelmechanismus koppeln können. So ungefähr:
If (GPU-Last>95%) Framelimit-=5fps;
If (GPU-Last<85%) Framelimit+=5fps;

Okay, ein bißchen ausgefeilter könnte man das schon noch machen, aber nur mal so als Idee, wie das im Prinzip aussehen könnte.Keine Ahnung, wie das Tool das wirklich macht - aber anders als es hier beschrieben wird, ist das laut THG nicht der Framelimiter in den Screenshots, den es mit Target-Framerate in RP ebenfalls gibt, sondern adaptives VSync.


@Gast: Wenn RP nicht laufen sollte (ich habe es momentan nicht am Start und kann dir nicht sagen ob/welche Probleme es mit der aktuellen Beta gibt), gibt es immer noch RivaTuner resp. Afterburner, womit du ein fps-Limit setzen kannst für diese Spiele.

[Gipsel]

Keine Ahnung, wie das Tool das wirklich macht - aber anders als es hier beschrieben wird, ist das laut THG nicht der Framelimiter in den Screenshots, den es mit Target-Framerate in RP ebenfalls gibt, sondern adaptives VSync.Ich denke RadeonPro kann beides (DVC= Dynamic VSync Control, DFC = Dynamic Framerate Control, beides über Hotkey an-/ausstellbar und Zielframerate kann auch per Hotkey hoch-/runtergesetzt werden). Und da THG Zielframeraten angeben (50fps, 40fps), die von der Refreshrate abweichen, werden die DFC zum Glätten genutzt haben (auch wenn in ihren Grafiken DVC steht, aber naja) und nicht unbedingt DVC. Aber es spricht ja nichts dagegen, daß sie beides aktiviert hatten.
Und adaptives VSync ist auch eine Art Framelimiter, nur eben bei der Refreshfrequenz des Monitors (und synchronisiert damit). Bzw. kann man bei RadeonPro ja auch einstellen, daß er 2 VSyncs abwartet, bevor er die Buffer tauscht, das ist dann ein Framelimit bei der halben Monitorfrequenz.

[Blaire]

Viel interessanter ist doch , was der Treiber ohne Hilfsmittel macht. Und da sieht es nicht so gut aus. Das man dem mit Vsync-Lags begegnet, ist doch ziemlich fragwürdig. Ich brauch bei SLI z.b. auch keine FPS-Limiter oder Vsync einschalten um ein gutes Spielgefühl zu erreichen.

[Gipsel]

Interessant wäre auch, was passieren würde, wenn Spielentwickler die Framequeue in DirectX sinnvoll (also anders als eine sture Queue) benutzen würden (triple buffering ist ja heutzutage gar kein triple buffering wie früher mehr) bzw. Framemetering betreiben würden (ist ja eigentlich ziemlich simpel). Würde meiner Meinung nach noch besser funktionieren, als wenn das der Treiber macht. Und die ganzen Inputlag-Geschichten würde man im gleichen Abwasch auch minimieren. :weg:

[Gast]

mich wuerde mal interessieren ob die leistungsaufnahme der gpu runtergeht,wenn die fps limitiert werden? wenn man keine schnellen szenen im spiel hat, ists ja egal ob mal 60 oder 100 fps hat, da koennte man ja lieber die extra energie sparen.

[ENKORE]

Ja.

[gnahr]

das bedient nvidia ja genau mit der neuen "target frame rate". ziel 60 zum bsp. heißt dass der boost und notfalls auch grundtakt samt spannung gesenkt wird wenn es trotzdem noch reicht.

der mgpu-lösung steh ich immernoch skeptisch gegenüber. amd ist dazu wie die jungfrau zum kinde gekommen, dass es also voll bereits mit der aktuell in der finalen entwicklung befindlichen dual-karte bedient wird ist nicht anzunehmen. das ist eben der nachteil wenn man erst von der presse auf was hingewiesen werden muss statt innovation selbst anzustoßen. hauptsache sie vergeigen es nicht auch mittelfristig wieder.