Test Mikroruckler bei Grafikkarten

Iscaran schrieb:
Das müsstest du mal bitte genauer ausführen warum der "in Hardware" ausgeführte Frame Versatz um +delta t (milisekunden) weniger frame lag erzeugt als ein entsprechender frame versatz in software ????

Die Nvidia GPUs seit G80 haben u.A. einen sehr genau Echtzeittimer damit die Deltas exakt hinzugefügt werden können. Nutzt man nur eine Treiber/Softwarelösung muß man sich auf den Windows-Timer verlassen, der eine Auflösung von ~12ms hat.
Ergänzung ()

Adler-Wolf schrieb:
Wie kommt der Sinneswandel ?
Schon merkwürdig kommt ein NV Tool und auf einmal gibt es diese Framelatenz Problematik nicht mehr
bei Singel GPU´s ?

Der Sinneswandel kommt durch neue AMD Treiber die schon vor Monaten das Problem gefixt haben. Wurde von AMD angekündigt und dann gebracht. Es gab viele News zu dem Thema.
 
Zuletzt bearbeitet:
Die Nvidia GPUs seit G80 haben u.A. einen sehr genau Echtzeittimer damit die Deltas extaxt hinzugefügt werden können. Nutzt man nur eine Treiber/Softwarelösung muß man sich auf den Windows-Timer verlassen, der eine Auflösung von ~12ms hat.

Das ist völliger Bulls....

Was RadeonPro ja eindeutig zeigt...die Framelatenzen sind bis auf ausnahmen +-wenige ms (so 1-5). Sieh dir einfach mal die diagramme mit radeon pro an. Somit verwendet RadeonPro also ganz offensichtlich etwas das wesentlich genauer als 12ms timed.

Der windows timer wird von jedem nur halbwegs fähigen programmierer sicherlich nicht verwendet werden wenn man die möglichkeit hat die latenz in CPU cycles zu messen ;).

Wo hast du denn deine Infos her ??? aus einem nVidia werbebroschürchen ?
EDIT: Kannst du vielleicht quellen nennen ?
 
Too long, didn't read.

Aber das Video ist suboptimal. Da gehört irgendwas reineditiert, an dem man nachvollziehen kann, dass das Video an sich flüssig dargestellt wird. Denn: Ich schau mir das auf meinem Schlepptop an. C2D P8600, Intel-Kotzgrafik X4500, und ab der Hälfte des Videos kommt ein starkes WTF-Gefühl auf. Davor fallen immer mal wieder ein paar Frames aus. Dann kommt das Radeon-Gespann mit dem sinngemäßen Kommentar: "Radeon ist dagegen kacke, damit ist BF völlig unspielbar". Gleichzeitig kommt endlich mal fast ruckelfreie Grafik dran. Kurz darauf dann 50 FPS, Kommentar "ja, damit schauts schon besser aus", wobei man wieder auf der Ruckelorgie von zuvor ist. Und dann 100 FPS, was völlig unspielbar erscheint.... "joa, 100 FPS sind nicht optimal, aber immerhin ansehnlich". Is klar :freak:

Bietet doch ne runtergerechnete 720p-Version o.ä. an, dann klappts vielleicht auch mit Systemen, die zwar normales 1080p hinkriegen, aber eben nur bei typischen Videoframeraten.
 
Sharky99 schrieb:
Ergänzung ()

Der Sinneswandel kommt durch neue AMD Treiber die schon vor Monaten das Problem gefixt haben. Wurde von AMD angekündigt und dann gebracht. Es gab viele News zu dem Thema.


Okay das habe ich im Artikel zum Singel-GPU Teil nicht gelesen.

EDIT:

Und was ist dann mit NV ?
Auch die Nvidia-Karte ist nicht frei von jeglichen Problemen, diese sind aber weit weniger ausgeprägt als bei der Konkurrenz

Das Problem müsste dann ja magischer Weise einfach verschwunden sein ?

Oder hat NV jetzt ein größeres Problem damit als AMD den
Mit am auffälligsten sind zwei ziemlich große „Aussetzer“ in Crysis 3 auf der GeForce GTX 770 sowie mehrere Unregelmäßigkeiten derselben Art bei der Radeon HD 7970 GHz Edition in Metro: Last Light, die man im Spielverlauf aber nicht bemerkt und die damit ignoriert werden können.

Ich kann da jetzt echt den Sinn nicht hinter verstehen. Kommt mir wie ein Problem vor das gar
nicht richtig existiert aber NV-Karten das auf alle fälle besser machen.

PS: Es geht bei mir nur um Singel-GPU
 
Zuletzt bearbeitet:
Bei CB gabs keine News dazu:

https://www.computerbase.de/suche/?q=AMD+framelatenz&bereich=news

https://www.computerbase.de/suche/?q=AMD+frame&bereich=news

Einzig in einem Nebensatz zu einem Treiber wurde dies in einem Nebensatz erwähnt:

https://www.computerbase.de/2013-04/amd-liefert-catalyst-13.4-whql-und-13.5-beta-2/

"Ferner soll die „Latenz-Performance“ in „Skyrim“, „Borderlands 2“, „Guild Wars 2“, „Tomb Raider“ und „Hitman Absolution“ „signifikant“ verbessert worden sein."

Das is aber auch schon alles. News dazu sehen imo anders aus. Naja zumindest ist jetzt der Nachweis erbracht auch wenns gedauert hat.
 
Zuletzt bearbeitet:
Hi

sry, aber so einen Test zu fahren wissend das eine deutliche Verbesserung
in 20 Tagen kommt ist nicht nur unproffesionell sondern auch Meinungsmache.
Mehr konnte man Hier und Heute nicht lernen.

Gruss Digger
 
Sharky99 schrieb:
Nutzt man nur eine Treiber/Softwarelösung muß man sich auf den Windows-Timer verlassen, der eine Auflösung von ~12ms hat.

Maximum timer interval: 15,600 ms
Minimum timer intervall: 0,500 ms

---

Zum Test:

Im Anhang (14) ist ein Fehler: Bei Tomb Raider fehlt das klassische Frameverlaufsdiagramm, da nochmal das von Metro: LL gezeigt wird.
 
Es wäre mal interessant den Frame-Lag zu testen. Es kann doch nich wahr sein. Erst werden die FPS geschönt, um bei den Benches besser auszusehen... dann fliegt es auf und man gibt die Bilder gleichmäßiger aus, wobei aber ganz sicher der "Input-Lag" höher wird.

Man sollte unbedingt mal ein Interview mit John Carmack führen, der hat dies schon vor langer Zeit kritisiert.
Dass das Messtool von Nvidia stammt, stimmt mich auch ein wenig skeptisch.

Achja: Ich finde es sehr interessant, dass endlich auch mal Single-GPU getestet wurde. Ich habe bei mir auch schon öfter kleine Hänger feststellen können, die wirklich nur Sekundenbruchteile lang waren. Aber sie sind vorhanden und sie nerven. Vielleicht könnte man ja auch mal andere Architekturen von AMD testen und sehen, wie sie sich untereinander verhalten. (VLIW4 + 5 und GCN)
 
Zuletzt bearbeitet:
bigot schrieb:
Tut mir leid das sagen zu müssen, aber ich bin von dem Artikel enttäuscht, da überhaupt nicht auf die Rolle der CPU eingegangen wird bzw. da nicht mit einer AMD-CPU oder einer Intel NON-HT CPU gegengetestet wird. Das wird schlichtweg von nahezu allen Magazinen totgeschwiegen. Afaik hat den Einfluss der CPU bisher nur ein ausländisches (asiatisches?) Magazin untersucht.

nicht nur das, ich hatte bei meinem SLI system mit einem framelimiter einfach die mikroruckler weggemacht, ich weiss garnicht was die problematik die es nicht gibt soll, und der stromverbrauch sinkt auch enorm wenn dauernd nur 40-45 fps angezeigt werden sollen

jemand der sein SLI CF system nicht mikrorucklerfrei kriegt der ist selber schuld
 
CH4F schrieb:
Mir geht es ähnlich, in Spielen heißt meine Grafikkarte immer HD4000!

.... Moment, unter dem Decknamen tarnt sich ja meine 7970M :lol:
Und ich meine tatsächlich die Intel 4600er - von einem Intel Core i5 4670. Die Spiele (z.B. Assassins Creed III) laufen ruckelfrei - so, wie es sein soll.
 
Ulukay schrieb:
(...)
In Bereichen wo du mit MGPU Mikroruckler bemerkst (nicht nur theoretisch misst), bist du mit einer GPU schon laengst im unspielbaren Bereich.

Das hängt stark von der Engine bzw. dem MultiGPU-Profil ab. Bei Far Cry 3 hab ich selbst bei 50-60 fps noch Mikroruckler, da hilft mir nur ein Framelimiter der alles auf 40 fps begrenzt (weil max Details und AA packen selbst zwei übertaktete 780er nicht mit permament 60 fps auf 6048x1200). Aber mit dem Limiter im RivaTuner läufts dann super geschmeidig und Input-Lag spüre ich auch nicht (bin da eher empfindlich, von daher...). Und mit meinem 5870er CF damals hatte ich übers ganze Spektrum und teils sogar selbst bei 60 fps noch Ruckler, die man besonders bei gleichmäßigen Vorwärtsbewegungen sehr schön sehen konnte. Mit dem SLI Setup spür ich je nach Spiel dagegen selbst bei niedrigen 25-30 fps noch keine Ruckler, wie gesagt einzig FC3 hat sich bisher auffällig verhalten.


Haldi schrieb:
(...)
btw meine persönliche Wunschliste wäre noch:
3GPU Benchmarks
Eyefinity /Surround Benchmarks.

gerade da ein AMD Mitarbeiter iwo mal erwähnt hat das Eyefinity völlig anders funktioniert als Einzel Monitor und daher der Wundertreiber gar nichts bringen wird.
Multimonitor-Benchmarks wären natürlich nice - denn mal ehrlich für Full-HD muss man sich keine zwei High-End-Karten in den Rechner packen, außer man will aus irgendwelchen Gründen 500 fps haben (die dann eh nicht angezeigt werden können). So richtig "notwendig" wird MultiGPU erst bei Multimonitor-Gaming wo einer einzelnen Karte ziemlich schnell die Firepower ausgeht. Und wenn dann gerade dort der AMD-Treiber nix bringen soll das wäre natürlich enorm bitter. Wobei ich von diesem Umstand bisher nichts gehört habe... denn eigentlich muss ja nur ein größeres Bild berechnet und dann entsprechend zerstückelt auf die unterschiedlichen Ausgänge verteilt werden.


Sebbi schrieb:
hmmmm sry .... aber solange "Mess - Tool" oder Test - HW nicht von einen Unparteiischen Dritthersteller kommt, ist dieser Test nonsens.
(...)
Nun ja direkt nach der Engine werden die Bilder mit einem Farbcode bestückt und anschließend wird mit einer externen Karte gemessen, welches Bild wie lange angezeigt wird bzw. wie viel % eines Bildes tatsächlich dargestellt werden bevor das nächste Bild kommt. Ich seh da nicht so viele Möglichkeiten zu cheaten. Dass die FRAPS-Messungen mit ihren ingame-FPS nur die halbe Wahrheit sagen ist schon länger bekannt. Wobei man sich durch das ganze Frame-Metering und irgendwelche künstlichen Delays natürlich wieder einen ganz anderen Satz an Problemen schafft: evtl. mehr input-lag, und es bringt ja auch nix wenn zwei Bilder nahezu gleichzeitig fertig sind mit der Berechnung, daher fast den gleichen Inhalt zeigen, aber eines der Bilder halt stark verzögert ausgegeben wird. Das wird dann auch als ruckeln empfunden, trotz der regelmäßigen Ausgabe. Um das zu quantifizieren, müsste man zB ein Objekt mit einer konstanten Geschwindigkeit über den Bildschirm bewegen und dann mit einer Capture-Karte die tatsächliche Bewegung messen, die auf dem Bildschirm ausgegeben wird.
 
Morrich schrieb:
Ich verstehe auch nicht, warum hier solch ein Test gebracht wird, der zwar den entsprechenden Treiber von AMD erwähnt, aber eben nicht beinhaltet.
Er ist doch getestet, nur eben in der Alpha-Version. Der finale wird nachgetestet. Was ist daran verwerflich?


So stellt der Artikel doch aktuell nur wieder dar, dass AMD in diesem Bereich noch Nachholbedarf hat und rückt NVidia mal wieder schön ins bessere Licht.

Aber nö, lieber bringt man nen halben Monat vorher so einen pro NVidia Artikel und lässt AMD nochmal richtig schön alt aussehen.
Nvidia ist auf dem Gebiet nun mal aktuell und die letzen Jahre besser und AMD hat hier nun mal Nachholbedarf. Was ist daran verwerflich dies zu zeigen? Ist AMD ne heilige Kuh die man nicht kritisieren darf?
Warum sollte man ein Problem erst dann untersuchen wenn sich der Hersteller mal irgendwann bequemt hat dies zu lösen?
Zumal der neue Treiber doch in einer frühen Version mitgetestet wurde und er zeigt das das Problem angegangen wird. Was will AMD mehr?

Den Vorher/Nachher Vergleich mit und ohne Frame Pacing Treiber hätte man auch nach dem 31. bringen können und hätte somit dann auch gleich gezeigt, ob es dann bei AMD oder NVidia besser läuft.
Und wenn man jetzt nen zweiten Test in ein paar Wochen bringt kann man das nicht mehr zeigen?

Hier sollte sich mal einige Fragen ob sie nicht selber ne farbige Brille aufhaben und das ganze sehr subjektiv angehen.


Man kann an dem Test sicher manches kritisieren. zB das Tools wie Radeon Pro nicht getestet wurden. Die werden ja jetzt hier auf CB nicht das erste mal erwähnt. Das das Equipment von Nvidia kommt ist sicher auch nicht optimal. (andererseits muss man Nvidia zu gute halten, dass sie sich der Sache annehmen)

Aber den Zeitpunkt zu kritisieren ist echt schon lächerlich.
 
Also um ehrlich zu sein, mir vermitteln die Grafiken, dass die Single Nvidia unrunder läuft als die Single AMD und die 40 FPS der GTX690 waren auch nicht wirklich brauchbar, da bräuchte man schon um die 50-60 bei NV um in einen Angenehmen Bereich zu kommen.
 
Das kann so weit gehen, dass ein Titel unspielbar wird ...

Spätestens an dieser Stelle hab ich aufgehört den Artikel weiter zu lesen.

Das Problem der Mikroruckler wird hier jedes mal so dermaßen übertrieben und überzogen hochgepusht, dass man sich fragt in welchem "Parallel-Universum" der Autor überhaupt lebt.
 
Zuletzt bearbeitet:
bensen schrieb:
Aber den Zeitpunkt zu kritisieren ist echt schon lächerlich.

Den Zeitpunkt zu kritisieren ist mehr als angebracht, da länger bekannt war
wann die finale version kommt.
Den Test vorher zu bringen lässt Absicht vermuten.
Anders kann man sowas nicht deuten


gruss Digger
 
digger66a schrieb:
Hi

sry, aber so einen Test zu fahren wissend das eine deutliche Verbesserung
in 20 Tagen kommt ist nicht nur unproffesionell sondern auch Meinungsmache.
Mehr konnte man Hier und Heute nicht lernen.

Gruss Digger

Exakt! Aber das von Nvidia gesponserte FCAT musste doch noch eingesetzt werden um die richtige "Promotion" zu machen.
Und wenn nicht jetzt, wann dann?

Demnächst hat sich das ganze sowieso künstlich hochgezogene Thema erledigt.
 
Sorry, aber ich traue diesem Test nicht.

"Für Besitzer einer Single-GPU-Karte haben wir am Ende dieses Tests eine ausschließlich positive Nachricht: Nvidia und AMD nehmen sich nichts, Mikroruckler sind bei beiden kein Thema. Hier zeigt sich, wie Optimierungen, die nach dem Messpunkt von FRAPS implementiert werden, bisher nicht gegriffen werden konnten. Unser Bauchgefühl hat uns schon länger gesagt: „Es existiert kein Problem“. FRAPS hatte dem widersprochen. FCAT liefert nun die Bestätigung.“.

Klingt für mich zu sehr auf den "wunden" Punkt.

Soll dieser Test eine Richtigstellung sein gegenüber AMD, ohne die seit einiger Zeit herschende Diskussion und Messungen über "Framedrop" und "Mikroruckler" Probleme ins lächerliche zu ziehen ?

AMD optimiert einen Treiber und das Problem ist nahezu ausgemerzt und somit für zukünftige Messungen nicht mehr erwähnenswert ?
 
Also ich habe über jahre einen Quad Sli system und Microruckler habe ich noch nie gemerkt .
 
Das Problem betrifft mich zwar nicht, aber ich finds technisch sehr interessant. Zwei Fragen(komplexe) hätte ich allerdings noch (hoffe die wurden nicht schon beantwortet)

1. Was passiert, wenn V-Sync und tripple Buffering aktiviert werden? Nach meinem Verständnis sollten dann keine "Runt" sondern nur noch "Dropped" Frames auftreten (wie sieht das quantitativ aus?) und die Framelatenzen sollten nur noch vielfaches von 16,7 ms betragen oder? Wie wirkt sich das ganze auf die subjektive Wahrnehmung aus?

2. Was ist wichtiger: Eine gleichmäßiges T_present oder ein gleichmäßiger Abstand zwischen T_game und T_present?
Zur Erklärung: Angenommen ein Ball bewegt sich gleichmäßig durch die Spielszene und T_game würde (warum auch immer) 0ms,5ms,40,45,80,85 ... betragen und der jeweils zurückgelegte Weg 1,8,9,16,17 px. Wäre es dann besser, wenn T_present
a) 10ms,30,50,70,90,110 .... oder
b) 10ms,15,50,55,90,95....
beträgt?
Im Fall a) hab ich zwar eine gleichmäßige Ausgabe auf dem Bildschirm (wenn man die fixe und limitierte Refreshrate des Bildschirms ignoriert), dafür würde sich der Ball scheinbar abwechselnd schneller und langsamer bewegen (1px/20ms=50px/s, 7px/20ms=350px/s,50,350,50....). Im Fall b) ist die Framerate zwar nicht konstant, aber der Ball scheint sich gleichmäßig zu bewegen (1px/5ms=200px/s, 7px/35ms=200px/s,200,200 ...).

Was ist jetzt subjektiv besser? Wie siehts aus wenn man die Refreshrate nicht ignoriert?
 
Finde den Zeitpunkt auch nicht optimal. Wenn zeitnah zum Erscheinen des Treibers ein Test kommt, ist aber alles in Butter. Wenn nicht, wärs sehr bedenklich.
 
Zurück
Oben