G-/Free-/A-Sync: framesynchronisierter Displayrefresh per variablem vblank-Intervall

[Grestorn]

Nochmal zum Verständnis: Stabile 60+ fps mit Vsync sind auf einem 60hz Bildschirm identisch mit Free/G Sync. Richtig oder Denkfehler?

Danke:)
Ja, so ist es.

Der Unterschied beginnt, so bald die 60 fps nicht mehr gehalten werden können.

[dargo]

Nochmal zum Verständnis: Stabile 60+ fps mit Vsync sind auf einem 60hz Bildschirm identisch mit Free/G Sync. Richtig oder Denkfehler?

Danke:)
Nicht ganz. Der große Vorteil ist auch, dass du den hohen Input-Lag durch Vsync On dank Freesync/G-Sync nicht mehr hast.

[SamLombardo]

Alles klar, danke euch:wink:

[Kriton]

Die Vergleichbarkeit gilt auch nur, wenn man eine Vielzahl von 60 fps hat (bzw. sonst kommt der Inputlag hinzu), oder?

[Grestorn]

Nicht ganz. Der große Vorteil ist auch, dass du den hohen Input-Lag durch Vsync On dank Freesync/G-Sync nicht mehr hast.

Wenn die maximale Framerate des Monitors erreicht ist, stimmt das nicht. Dann hat man immer den selben Lag, der eben bei 60 Hz / fps auftritt, egal ob GSync oder nur VSync.

Nur bei AMDs Freesync, bei der VSync ja abgeschaltet wird, so bald die Framerate des Monitors erreicht wird, ist das anders. Dafür hat man dann wieder Tearings.

Die Vergleichbarkeit gilt auch nur, wenn man eine Vielzahl von 60 fps hat (bzw. sonst kommt der Inputlag hinzu), oder?
Was meinst Du mit "Vergleichbarkeit"? Wenn Du damit meinst, dass sich GSync/Freesync genau wie ein herkömmlicher Monitor verhält, dann hast Du recht: Sobald die Framerate die maximale Wiederholfrequenz des Monitors überschreitet, bringen diese Technologien keinerlei Vorteile mehr.

[fondness]

Nur bei AMDs Freesync, bei der VSync ja abgeschaltet wird, so bald die Framerate des Monitors erreicht wird, ist das anders. Dafür hat man dann wieder Tearings.


Man kann bei FreeSync einstellen ob Vsync bei überschreiten der max Refreshrate on oder off ist.

[Grestorn]

Man kann bei FreeSync einstellen ob Vsync bei überschreiten der max Refreshrate on oder off ist.
Ja, das weiß ich schon. Die Konsequenzen sind aber genau die, die ich beschrieben habe. Dass es optional ist hätte ich wohl noch klarstellen sollen...

Ich finde es gut, dass AMD diese Option anbietet (für die Lag-Fetischisten), ich würde sie aber nie nutzen, da ich kaum etwas schlimmer finde als Tearing.

[aufkrawall]

Also am besten Limiter nutzen.
Nur doof, dass NVs noch nie zuverlässig funktionierte und AMDs noch nicht existiert.
Wenn man glück hat geht also Limit im Spiel selber, oder man muss 3rd Party Tools nutzen. Was bei Mantle nicht geht.

[Grestorn]

So weit ich das verstanden habe (ich nutze den Limiter selbst nicht), ist es nur eine Frage des richtigen Werts, den man ggf. im Inspector manuell setzen muss, da die Vorgaben immer eine etwas zu geringe oder zu hohe Framerate zulassen, oder nicht?

Wobei ich nie verstanden habe, wo der Unterschied des Limiters bei 60 fps und einem aktiven VSync bei 60 Hz ist. Beides limitiert die Framerate in dem der Treiber ein entsprechendes Delay im Present() Call einfügt, oder?

Nur wenn man das im Spiel selbst limitieren kann, hat das Spiel auch die Chance das Timing und die Steuerung darauf anzupassen.

[robbitop]

Das ist eine der vielen tollen Vorteile bei einem 144 Hz G-Sync Monitor. Darüber muss man sich eigentlich nie Gedanken machen. :D

[Kriton]

Was meinst Du mit "Vergleichbarkeit"? Wenn Du damit meinst, dass sich GSync/Freesync genau wie ein herkömmlicher Monitor verhält, dann hast Du recht: Sobald die Framerate die maximale Wiederholfrequenz des Monitors überschreitet, bringen diese Technologien keinerlei Vorteile mehr.

Vergleichbarkeit bezogen auf SamLombardos ursprüngliche Frage.

[aufkrawall]

Eventuell schaltet NV mit Gsync im Refreshratenlimit ja alle unnötigen Buffer ab, ähnlich wie mit dem AFR-Vsync.
Ansonsten müsste der Input Lag auch mit Treiber-Limiter niedriger sein als mit normalem DB Vsync, wenn das mit Gsync dann griefe.

Der Treiber-Limiter glänzte Zeit Lebens leider immer mit diversen Ausfällen. Ist nicht NVs Ruhmesblatt.
Die müssten das mal ein für alle Mal in den Griff bekommen, momentan sind etwa die fps viel höher als die eingestellten Werte (ob das für alle gleichermaßen zutrifft, weiß ich nicht). Auch erkennt man im Frostbite-Grahpen eine gewisse Varianz. Keine Ahnung, was das soll.

[Kriton]

Ja, das weiß ich schon. Die Konsequenzen sind aber genau die, die ich beschrieben habe. Dass es optional ist hätte ich wohl noch klarstellen sollen...

Ich finde es gut, dass AMD diese Option anbietet (für die Lag-Fetischisten), ich würde sie aber nie nutzen, da ich kaum etwas schlimmer finde als Tearing.

Ich spiele z.B. immer mit V-Sync off und sehe in der Realität selten Tearing (oder ich nehme es nur nicht bewusst wahr).

[aufkrawall]

Ich spiele z.B. immer mit V-Sync off und sehe in der Realität selten Tearing (oder ich nehme es nur nicht bewusst wahr).
Kommt nur auf die gerenderte Szene an. Meist ist seitlich an irgendwelchen Zäunen in ungünstigem Abstand entlanglaufen ganz schlimm, oder flackernde Lichtquellen.

[dargo]

Wenn die maximale Framerate des Monitors erreicht ist, stimmt das nicht. Dann hat man immer den selben Lag, der eben bei 60 Hz / fps auftritt, egal ob GSync oder nur VSync.

Meine Güte... die Leute im 3DC werden wohl doch noch in der Lage sein einen Framelimiter zu nutzen oder? :)

[aufkrawall]

Ich frage mich allerdings, warum der Treiber dann nicht einfach automatisch 0,xHz unterhalb der Refreshrate limitiert.

[fondness]

Ich spiele z.B. immer mit V-Sync off und sehe in der Realität selten Tearing (oder ich nehme es nur nicht bewusst wahr).

zB mit einem 144Hz Monitor würde ich nie VSync anschalten, da braucht man IMO schon ein verdammt geübtes Auge um noch Tearing zu sehen, ich sehe es nicht mehr. Bei 60hz kann man bzw ich es je nach Szene meist schon noch wahr nehmen.

[dargo]

Ich frage mich allerdings, warum der Treiber dann nicht einfach automatisch 0,xHz unterhalb der Refreshrate limitiert.
Gute Frage. Vielleicht ist einfach noch keiner auf die Idee gekommen.

[Grestorn]

Gute Frage. Vielleicht ist einfach noch keiner auf die Idee gekommen.

Mal wirklich eine dumme Frage, weil ich das wirklich nie verstanden habe:

Wenn ich einen Limiter, sagen wir, auf 59,5 fps einstelle. Dann wirkt das doch nicht anders, als würde die Grafikkarte für diese Szene eben maximal 59,5 fps erreichen, d.h. ein Frame braucht immer minimal 16,8 ms um berechnet zu werden. Wird es schneller berechnet, wird eine künstliche Pause eingefügt, damit die 16.8 ms erreicht werden.

VSync setzt bei 60 Hz ja eine konstante Frametime von 16,67 ms voraus. Führt der Framelimiter nicht dazu, dass alle 130 frames (16,8 / 0,13) ein kurzer Schlucker auftritt, also für ein Frame die Frametime auf 33,33 ms erhöht wird, weil Monitor und Berechnung eben nicht im Gleichtakt sind?

[aufkrawall]

Mit Vsync ist das natürlich so, weshalb ich hier des öfteren versucht habe, Leuten diese Lösung auszureden. ;)
Aber mit variablem Vlank refresht ja der Monitor entsprechend und es ruckelt nichts.

[mironicus]

Ich bin gespannt was für einen variablen Refresh-Bereich künftige Freesync-Monitore haben werden. Stellt euch mal folgendes vor: Ein Samsung 4K-Display mit einem Bereich von 48-60 Hz. Das wäre doch wirklich was für die Tonne! :D

Die LG 21:9 mit 48-75 Hz sind bei 2580x1080 noch brauchbar für eine Single-Grafikkarte wie die R290/x. Ein IPS/VA-Panel mit 30-120 Hz wäre perfekt. Da hoffe ich auf Hersteller wie Asus.

[Kartenlehrling]

Das ist eine der vielen tollen Vorteile bei einem 144 Hz G-Sync Monitor. Darüber muss man sich eigentlich nie Gedanken machen. :D
Ich spiele z.B. immer mit V-Sync off und sehe in der Realität selten Tearing (oder ich nehme es nur nicht bewusst wahr).


Das ist doch quatsch, 120Hz bzw. 144Hz halbiert nur die "Möglichkeit" von Tearing zu einem 60Hz Monitor.
Da und auch wahrnehnbar bleiben sie trotzdem. :rolleyes:
Tearing beseitigen kann nur vsync, freesync, g-sync und mein liebgeworde VirtualVsync.

[fondness]

Stellt euch mal folgendes vor: Ein Samsung 4K-Display mit einem Bereich von 48-60 Hz. Das wäre doch wirklich was für die Tonne! :D


Selbst wenn ist es besser als nichts (also kein FreeSync), man kann damit immerhin noch relativ schön mittels Framelimiter ein gesynctes Bild erreichen. Allerdings wäre es natürlich schöner wenn 30Hz oder weniger gingen.

[mironicus]

Könnte AMD mit dem Treiber einem limitierten (z.B. 48-75 Hz) Freesync-Monitor auf die Sprünge helfen, also z.B. bei 35 FPS gibt der Monitor 70 Hz aus, bei 30 FPS 60 Hz, bei 24 FPS 72 Hz, bei 12 FPS 72 Hz. Fraglich ist halt wie lange wir warten müssen bis es Panels gibt die von 9-144 Mhz ansteuerbar sind. Perfekt wäre natürlich wenn das der Monitor von sich aus könnte und stets ein flackerfreies Bild dabei liefert.

[dargo]

Ich bin gespannt was für einen variablen Refresh-Bereich künftige Freesync-Monitore haben werden. Stellt euch mal folgendes vor: Ein Samsung 4K-Display mit einem Bereich von 48-60 Hz. Das wäre doch wirklich was für die Tonne! :D

Die LG 21:9 mit 48-75 Hz sind bei 2580x1080 noch brauchbar für eine Single-Grafikkarte wie die R290/x. Ein IPS/VA-Panel mit 30-120 Hz wäre perfekt. Da hoffe ich auf Hersteller wie Asus.
Ein Bereich von 48-60Hz wäre zwar verdammt klein, aber immer noch besser als gar kein Freesync. Mir gehts auch nicht unbedingt darum, dass ich 100% der Spielzeit absolut flüssig genießen kann (klar, wäre der Optimalfall). Mit größer 90% wäre ich schon zufrieden. Zu dem LG... so langsam glaube ich, dass der Scaler nur minimum 48Hz bietet weil er im oberen Bereich bis 75Hz geht. Sprich... hat man max. 60Hz dürften auch die min. 40Hz drin sein. Oder bin ich da auf dem Holzweg? Wobei... daran kanns auch nicht liegen wenn die Scaler im TN zwischen 40 und 144Hz bieten. :uponder:

[mironicus]

Man muss das einfach testen, ob man die Monitore über die Spezifikationen hinaus noch tweaken kann. Da sollte was über die Treiber möglich sein. Stellt euch vor, es wäre möglich den Refreshbereich zu forcieren über den Treiber, z.B. 35-85 anstatt 48-75.

[Troyan]

Die Informationen sind im EEID EDID abgelegt. Du müsstest es dort ändern. Dann sollte vorallem nach unten mehr gehen.

[Unicous]

Es heißt im Übrigen EDID. Ich dachte das erste Mal war ein Versehen.

[Troyan]

Ah, danke. Man lernt nie aus.

[Kartenlehrling]

[Acer XB270HU.AddReg]
HKR,"MODES\2560,1440",Mode1,,"30.0-210.0,30.0-150.0,+,+"
HKR,,MaxResolution,,"2560,1440"
HKR,,DPMS,,1
HKR,,ICMProfile,0,"Acer XB270HU.icm"


[XG270HU.AddReg]
HKR,"MODES\2560,1440",Mode1,,"50.0-145.0,223.0-223.0,+,+"
HKR,,ICMProfile,0,"XG270HU.icm"



Wer kann uns dazu was sagen ?

[Unicous]

Say whuat?

Der neue Acer G-Sync IPS Monitor "ghosted"?:eek:

Das kann doch gar nicht sein, es ist doch G-Sync?:freak:

Und wie wir alle wissen gibt es bei G-Sync kein Ghosting.

[allyn]malventano

I personally own a Swift (bought myself, running on SLI 680's), but may sell that for the new IPS Acer that's coming. I sat down with it for an hour on Friday and couldn't get it to flicker at all (light sensor and scope didn't even flinch), but that advantage comes at a cost, since it's IPS, it does ghost (1/2 frame or so). Looked nearly as bad as the BENQ TN FreeSync panel, but I'd probably tolerate that for the far better contrast and viewing angles of IPS glass (I do also write a lot of content on my home system, so that's helpful).

http://www.overclock.net/t/1546934/various-amd-freesync-reviews/750#post_23701918

[Troyan]

Der Acer hat ein AHVA Panel mit 12ms GtG (Acer gibt 4ms an) Reaktionsgeschwindigkeit. Der BenQ hat ein TN Panel mit (angegebenen) 1ms GtG.

Der Acer sollte nicht besser sein als der BenQ. Das wiederrum ist jedoch genau das Problem: Ohne Overdrive ist die Reaktionsgeschwindigkeit soviel schlechter, dass ein "1ms" TN Panel einem 12ms (4ms) "IPS" Panel unterliegt...

[Unicous]

Darum geht es nicht. Hier wurde behauptet, es gäbe mit G-Sync kein Ghosting. Und selbst Allyn Malventano hat das so halb behauptet.

...but FreeSync / adaptive sync *are* introducing it. This is an issue that was corrected years ago in constant refresh rate LCDs, and continued to be corrected with G-Sync. The issue is now re-introduced with current non-G-Sync VRR panels. Whoever's fault it is is not relevant to the fact that ghosting *is* present in the first three FreeSync panels we have looked at so far.
http://www.pcper.com/reviews/Displays/AMD-FreeSync-First-Impressions-and-Technical-Discussion/Gaming-Experience-FreeSync-?destination=node/62595#comment-268002

...um dann später zurückzurudern.

Further - arguing about the cause is naive as the end result is what matters, and the 'firmware and its setting's of the FreeSync panels we have tested are visually ghosting, and the G-Sync panels are not. It is causing FreeSync to fall behind G-Sync in the visual quality of moving scenes. It's something they (panel manufacturers in this case - not AMD) should fix if they want to be competitive.
http://www.pcper.com/reviews/Displays/AMD-FreeSync-First-Impressions-and-Technical-Discussion/Gaming-Experience-FreeSync-?destination=node/62595#comment-268047

Er behauptete auch, dass die Panels beim ROG Swift und BenQ gleich sind. Das stimmt nachweislich auch nicht.

[Troyan]

Es gibt kein zusätzliches Ghosting durch das Aktivieren von G-Sync.
Natürlich haben auch G-Sync Monitore mit langsamen Panels Ghosting.

Der Acer mit Overdrive erreicht 12ms von schwarz auf weiß auf schwarz:
http://www.tftcentral.co.uk/reviews/acer_xb270hu.htm

Der Swift mit Overdrive liegt bei 5,2ms:
http://www.tftcentral.co.uk/reviews/asus_rog_swift_pg278q.htm

Wenn also der Acer mit IPS schneller ist als der BenQ, dann funktioniert Overdrive beim BenQ nicht. Der Swift liegt ohne Overdrive im GtG Test mit 60Hz bei 12ms und bei 144Hz bei 6,9ms. Also auf einem ähnlichen Niveau wie der Acer Monitor mit Overdrive.

/edit: Wir reden hier dann nur von GtG. Farbwechsel können darüber hinaus noch erheblich länger dauern. Und genau dies man auf den Bild und den Videos von PCPer.

[Unicous]

Zusätzliches Ghosting? The Fuck?:freak:

[Troyan]

"Zusätzlich" ist falsch. Stimmt.

Jedenfalls hier die Passage aus dem Swift-Test von TFTCentral über das Verhalten bei 60Hz mit ausgeschaltenen Overdrive:

It is all these variations which lead to the slow response times for many transitions when OD is turned off and you are using a 60Hz refresh rate. This left us with an average G2G response time of 12.2ms which was slow for a TN Film panel like this. The fastest transitions did reach down to around 0.9ms at best which was excellent, but the slower changes up to around 20.4ms were an issue*. On the plus side, there was no overshoot evident at all with AMA turned off, as you might hope.

We saw a very similar pixel behaviour from the BenQ XL2720Z when we tested it as well. Of course none of this is a problem as I doubt anyone is going to use the screen at 60Hz and with OD set to off! We are only including it for completeness and to demonstrate the improvements then made to response times when you boost the refresh rate up as in the next section.
http://www.tftcentral.co.uk/reviews/asus_rog_swift_pg278q.htm

*Anstieg dauert 19ms von 0-255, der Fall 1,4ms von 255-0.

Bei 144hz ist es erheblich besser. Von 20,4ms auf 10ms reduziert sich die Zeit. Deswegen fällt es bei hohen Hz auch nicht so deutlich auf.

[aufkrawall]

Bei niedriger Refreshrate haben hold-type Displays eh sehr starken Motion Blur.
No lunch for free.

[robbitop]

Das ist doch quatsch, 120Hz bzw. 144Hz halbiert nur die "Möglichkeit" von Tearing zu einem 60Hz Monitor.
Da und auch wahrnehnbar bleiben sie trotzdem. :rolleyes:
Tearing beseitigen kann nur vsync, freesync, g-sync und mein liebgeworde VirtualVsync.
Warum quotest du mich? Hast du überlesen, dass ich von einem 144 Hz G-Sync Monitor sprach? (in meinem Fall den ROG SWIFT) Und zwar im Zusammenhang mit dem Framelimiter. Wenn die maximale Frequenz des G-Sync Monitors 144 Hz ist, braucht man keinen Framelimitier, um Mouselags zu reduzieren, weil die Framerate eh nicht über die maximale Frequenz des Monitors hinausgeht. BQ Features sei Dank.

[Kartenlehrling]

Ich habe dich gequoted weil du es auf die hohe Hz des Monitors ableitest und behauptes das man mit Vsync kein FPS-Limiter brauch.

Es gibt einfach zu wenig Test die Maus-Inputlags wirklich testen, weil der Zeitaufwand viel zu gross ist und man die passenden Spiele auch raussuchen muss.
Wenn man von Spiele rede die man mit >144Hz spielen kann, kommt man vielleicht auf 2-5 Spiele die nicht älter als 2 Jahre sind.
Eigentlich wär es am besten man könnte mit der minFPS was das Spiel hergibt spielen,
aber das geht nicht weil es dann oft viel zu niedrig wär und da kommt jetzt g-sync und freesync und hilft uns der Spielraum zu vergrössern und anzuheben.
Und trotzdem muss man auch für ein G-sync/freesync Monitor die FPS optimal einrichten.

Ja du kannst glücklich sein ein >120Hz Gsync Monitor zu haben,
weil nur ein 144Hz Monitor schützt nicht vor Tearing, es erhöht nur die chance weniger zu haben.

[robbitop]

Ich habe dich gequoted weil du es auf die hohe Hz des Monitors ableitest und behauptes das man mit Vsync kein FPS-Limiter brauch.

Du hast mich nicht korrekt verstanden. Mauslags kommen zustande, sobald die Framerate > Refreshrate ist. Egal ob in G-Sync oder in V-Sync. (in dem Fall wird G-Sync zu V-Sync). Eben weil ggf. berechnete Bilder potenziell verworfen werden.

Und jetzt kommt meine Aussage, eben darauf abzielt, dass man mit einer hohen Refreshrate gar nicht in diesen Bereich hineingerät, weil die Framerate immer geringer ist. (schaffe es mal in einem Spiel auf > 100 fps - geschweige denn 144 fps -> > 60 fps ist schon eher möglich)
Und selbst wenn das passieren kann -> Downsampling/SGSSAA. Ich habe nie nie nie fps in dem Bereich. Genau darum gings. Man hat einfach ein größeres fps-Fenster in dem man sich keine Sorgen machen muss. (davon ab, dass 144 Hz Refreshrate noch andere Vorteile bietet)

[derF]

Ja du kannst glücklich sein ein >120Hz Gsync Monitor zu haben,
weil nur ein 144Hz Monitor schützt nicht vor Tearing, es erhöht nur die chance weniger zu haben.
Nein, primär senkt es die Anzeigedauer jedes Risses. Bei 120 Hz wird er nur 8,33 ms angezeigt, während er bei 60 Hz 16,67 ms angezeigt wird.
Das verbessert den Bildeindruck schon so sehr, dass ich vieles auf dem 144 Hz Monitor ohne vSync spielen kann, was auf 60 Hz Augenkrebs verursacht hat..

[Kartenlehrling]

.......... Link war alte Kamelle

[PHuV]

Gibt es hier noch keinen, der sich mal einen Freesync-Monitor gegönnt hat, und mal praktische Erfahrungen postet?

[Isen]

Ich warte was Samsung bringt... Kollege sein Acer ist Heute verreckt ....was Monitore betrifft hat er o-ton: Die Nase voll.

[derF]

Leider hab ich auch von Samsung schon viel Elektroschrott gesehen.

[EPIC_FAIL]

Ich warte was Samsung bringt... Kollege sein Acer ist Heute verreckt ....was Monitore betrifft hat er o-ton: Die Nase voll.

Geht mir ähnlich wie deinem Kollege. Ich trau mich schon nicht mehr Monitore zu bestellen, da diese ohnehin nach 2-3 Tagen wieder zurück gehen. Es gibt immer irgendwas, was einem total auf die Nerven geht. Manches davon ist ertragbar, manches aber eben nicht. Wenn das Teil dann noch kaputt geht....
Jedenfalls hab ich mich bis 2009 gedrückt, bis ich mal nen TFT behalten habe, und dann war die Devise: da eh alles Schrott ist, gewöhn ich mich halt mal an Mist, damit ich später eventuell sparen kann --> http://www.prad.de/new/monitore/test/2009/test-philips-220cw9fb.html wurde also der hier.

Man muss es mal so sehen, im Vergleich zu den meisten hier kann ich tatsächlich ein vollständiges Upgrade in allen relevanten Bereichen bekommen :freak:

[Unicous]

PCM2

I'm not sure why people are 'surprised' to see 'ghosting' on the BenQ XL2730Z. All BenQ XL Series gaming monitors in existence how suffered from inverse ghosting (overshoot) when 'AMA' is enabled. Given the high refresh rate and rapid pixel responses overall this tends to be reasonably faint as far as inverse ghosting goes and very short-lived. As a result it isn't something all users will notice, and many would find it preferable to disabling AMA which brings with it considerable conventional trailing due to some sluggish pixel transitions.

Nvidia carefully optimises the pixel overdrive algorithm on G-SYNC monitors, which they do exceptionally well from what I've seen. With FreeSync the monitor manufacturer is responsible for getting the most out of the monitor and the panel it uses. AMD have no say in how things are optimised and unfortunately BenQ likes to push for strong acceleration on its XL monitors whether there are negative consequences or not. But hey, it's not as bad as the rubbish presets that even visually impaired gamers would find obnoxious.
http://forums.overclockers.co.uk/showpost.php?p=27814590&postcount=369

Well I know that a lot of monitor manufacturers are interested in the technology and will be revealing a range of products in the coming months (mainly starting in the summer). We will see a much broader range of Adaptive-Sync monitors than we have with G-SYNC monitors and the manufacturers seem much more willing to adopt the technology. There isn't the same premium attached (due to not needing special 'G-SYNC scaler' hardware) and they don't have their manufacturer specific OSD functionality/tweaks or extra ports beyond DisplayPort locked off.

I'm also quite confident that BenQ will release their own AHVA ('IPS-type') model with Adaptive-Sync at some point, it would be a bit odd if they didn't given that they're the parent company of AUO who manufacture the panel Acer and ASUS use for their 120Hz+ 'IPS' models. I just wish Nvidia would swallow their pride and support the technology, it would be much better for the consumer that way!
http://forums.overclockers.co.uk/showpost.php?p=27815107&postcount=379

https://pcmonitors.info/

[Kartenlehrling]

APOAoG
The Asus Pixel Overdrive Algorithm on G-SYNC

Ja, neee ist klar! :tongue:

[Troyan]

Nvidia Explains Why Their G-Sync Display Tech Is Superior To AMD's FreeSync (http://www.forbes.com/sites/jasonevangelho/2015/03/23/nvidia-explains-why-their-g-sync-display-tech-is-superior-to-amds-freesync/2/)

Zweite Seite, da die erste uninteressant ist.

[HPVD]

starten eigentlich alle g-sync Monitore bei 30Hz?
Oder gibts da auch Unterschiede zwischen den einzelnen Monitoren wie bei freesync?

Für die freesync min Frequenzen der einzelnen Monitore gibts hier ja eine schöne Übersicht:
http://www.computerbase.de/2015-03/amd-freesync-im-praxistest/2/

=> gibt's sowas ggf auch für G-sync Monitore?

[Unicous]

Attention everybody. Nvidia has

anti-ghost(ing) technology

Who you gonna call?


Das Interview ist super lame und es gibt keinerlei neue Informationen. Aber Tom Peterson darf unwidersprochen seinen Senf bzw. FUD zu Adaptive Sync ablassen.

Part of the reason they have such bad ghosting is because their driver has to specifically be tuned for each kind of panel. They won’t be able to keep up with the panel variations. We tune our G-Sync module for each monitor, based on its specs and voltage, which is exactly why you won’t see ghosting from us.

Für diese Behauptung hätte ich doch gerne mal Beweise.:rolleyes:

@HPVD

Soweit ich weiß liegt bei allen erhältlichen G-Sync Monitore die VRR-Grenze bei 30 Hz. Ist sicherlich eine Spec die Nvidia explizit fordert. Deswegen hat z.B. der ROG Swift auch ein nicht erhältliches Panel von AUO, das sicherlich an diese Anforderungen angepasst wurde.

[Sunrise]

Die werden wir wohl nie bekommen. Rein technisch kann ich mir schon einiges vorstellen was die Vorgehensweise außerhalb der VRR angeht. So falsch ist zumindest ein Teil davon nicht.

Das Problem ist wie er aus allem eine Wissenschaft macht, als wäre es plötzlich annormal, dass ein Monitorhersteller seine Panels selbst optimiert und das im Scaler speichert. G-Sync übernimmt genau diese Aufgabe auch, fügt aber in Abstimmung mit dem Displaycontroller lediglich Intelligenz (außerhalb der VRR) hinzu, sodass sich alles noch im für die Paneleigenheiten problemlosen Bereich abspielt. Aber das ließe sich sicher auch per Treiber und EDID lösen. Und was der Schwachsinn soll, dass AMD die Panelwerte im Treiber haben muss, weiß auch nur Petersen. Meint er damit wirklich das was er sagt?

Warum muss bitte der Treiber wissen, wie die Panel-Firmware das Panel bei den Frequenzen jeweils anspricht. Das sollte das Display schon selbst wissen, klappt bei professionellen Displays doch auch.

Wenn er das nicht genauer ausführt, ist das wertlos.

[Gipsel]

Das Interview ist super lame und es gibt keinerlei neue Informationen. Aber Tom Peterson darf unwidersprochen seinen Senf bzw. FUD zu Adaptive Sync ablassen.

Für diese Behauptung hätte ich doch gerne mal Beweise.:rolleyes:Die Behauptung ist schlicht Bullshit. Der Treiber muß gar nichts vom Panel wissen (außer dem Bereich der unterstützten Refreshraten), die Panelelektronik muß das Panel kennen. Und das finde ich ehrlich gesagt nicht zu viel verlangt.

[Kartenlehrling]

Mein erstes Video das ich gegoogle habe .... soviel dazu.

https://www.youtube.com/watch?v=MFgImCa5UcI
Vsync vs Gsync Asus SWIFT PG278Q - Nvidia Pendulum demo

[HPVD]

@HPVD

Soweit ich weiß liegt bei allen erhältlichen G-Sync Monitore die VRR-Grenze bei 30 Hz. Ist sicherlich eine Spec die Nvidia explizit fordert. Deswegen hat z.B. der ROG Swift auch ein nicht erhältliches Panel von AUO, das sicherlich an diese Anforderungen angepasst wurde.

danke! hmm offizielle Infos dazu kann man aber irgendwie nicht ergoogeln, nur verschiedene Indizien

wie auch
Störend finden wir dafür die minimale Wiederholfrequenz, die bei den bisher verfügbaren Freesync-Monitoren bei 48 bis 40 Hz liegt. Darunter greift Vsync mit allen Nachteilen, weswegen wir uns wünschen, dass AMD wie Nvidia mit den Bildschirmherstellern daran arbeitet, künftig 30 Hz oder weniger als Untergrenze anzubieten.
http://www.golem.de/news/amd-freesync-im-test-kostenlos-im-gleichen-takt-1503-113065-3.html

[samm]

Das mit der Nörgelei über VSync bei Unterbieten der minimalen Wiederholfrequenz ist mir noch nicht ganz klar: Die Leute scheinen ja zu behaupten, der Monitor funktioniere unterhalb der Untergrenze wie ein Monitor mit 40/48Hz maximaler Refreshrate, was doch ein ziemlich blöder Bug im Monitor oder Treiber wäre.
Ich hoffe auf ein baldiges Review einer Seite, die das vertrauenswürdig untersuchen kann.

Dito das Problem mit dem Ghosting (ob die Monitorhersteller bei aktivem Freesync entweder Overdrive auf Maximum und dadurch inverse Ghosting oder auf aus haben). PCPer traue ich es ja zu, das Problems an sich zu entdecken, aber eine korrekte Untersuchung erwarte ich eher von tftcentral, oder Prad hängt sich mal wieder richtig rein.

[Kartenlehrling]

48Hz-75Hz

Da stellt man das Spiel so ein das man vsync-OFF 80-90fps max hat und spielt mit freesync-vsync,
dann hat man ca. 25fps Luft für nötige FPS-Einbrüche, ansonst hat man 75fps festgenagelt.
So würde ich spielen mit dem 21:9 LG.

[aufkrawall]

Ein gewisses A-Sync ist besser als gar keins. Super Erkenntnis, Glückwunsch.

[Troyan]

Das mit der Nörgelei über VSync bei Unterbieten der minimalen Wiederholfrequenz ist mir noch nicht ganz klar: Die Leute scheinen ja zu behaupten, der Monitor funktioniere unterhalb der Untergrenze wie ein Monitor mit 40/48Hz maximaler Refreshrate, was doch ein ziemlich blöder Bug im Monitor oder Treiber wäre.
Ich hoffe auf ein baldiges Review einer Seite, die das vertrauenswürdig untersuchen kann.


Der Treiber lässt den Monitor mit dem unteren Limit als aktuelle Hz laufen.
Heißt beim LG mit 48Hz und beim BenQ/Acer mit 40Hz. Macht das Erlebnis erheblich schlechter, wenn du außerhalb des VRR Bereiches bist, da es nun schlechter ist als bei "oberen Limit" mit V-Sync On oder Off.

Die werden wir wohl nie bekommen. Rein technisch kann ich mir schon einiges vorstellen was die Vorgehensweise außerhalb der VRR angeht. So falsch ist zumindest ein Teil davon nicht.

Das Problem ist wie er aus allem eine Wissenschaft macht, als wäre es plötzlich annormal, dass ein Monitorhersteller seine Panels selbst optimiert und das im Scaler speichert. G-Sync übernimmt genau diese Aufgabe auch, fügt aber in Abstimmung mit dem Displaycontroller lediglich Intelligenz (außerhalb der VRR) hinzu, sodass sich alles noch im für die Paneleigenheiten problemlosen Bereich abspielt. Aber das ließe sich sicher auch per Treiber und EDID lösen. Und was der Schwachsinn soll, dass AMD die Panelwerte im Treiber haben muss, weiß auch nur Petersen. Meint er damit wirklich das was er sagt?

Warum muss bitte der Treiber wissen, wie die Panel-Firmware das Panel bei den Frequenzen jeweils anspricht. Das sollte das Display schon selbst wissen, klappt bei professionellen Displays doch auch.

Wenn er das nicht genauer ausführt, ist das wertlos.

Der Treiber muss die Elektronik steuern. Woher soll das Panel btw. die Elektronik wissen, auf welcher Hz er sich nun einstellen soll? Ist das was ich im Kontext mit G-Sync herauslese.

[Grestorn]

Mein erstes Video das ich gegoogle habe .... soviel dazu.

https://www.youtube.com/watch?v=MFgImCa5UcI
Vsync vs Gsync Asus SWIFT PG278Q - Nvidia Pendulum demo

Der Versuch, GSync in einem fest synchronisierten Video darzustellen, muss prinzipbedingt scheitern.

Das ist wie wenn man versucht, den Vorteil eines Farbfernsehers auf einem schwarz/weiß Fernseher zu zeigen, oder den 3D Effekt auf einem herkömmlichen 2D Monitor zu zeigen.

[mczak]

Der Treiber muss die Elektronik steuern. Woher soll das Panel btw. die Elektronik wissen, auf welcher Hz er sich nun einstellen soll? Ist das was ich im Kontext mit G-Sync herauslese.
Der Treiber der Grafikkarte steuert gar nichts. Der Chip gibt einfach ein neues Bild aus wenn es da ist - bei Displayport ist das ja paketbasiert stellt also keine besonderen Anforderungen an die Grafikkarte. Du könntest allenfalls mitteilen wie lange denn das Bild dargestellt werden soll bis das nächste kommt das geht aber logischerweise nur wenn du das nächste Bild schon hast. Gibt natürlich ein Frame Extra-Latenz. Und gibt überhaupt keinen Grund dass das die Grafikkarte machen sollte sowas wäre viel besser in der Monitorelektronik aufgehoben...

[Gipsel]

Das mit der Nörgelei über VSync bei Unterbieten der minimalen Wiederholfrequenz ist mir noch nicht ganz klar: Die Leute scheinen ja zu behaupten, der Monitor funktioniere unterhalb der Untergrenze wie ein Monitor mit 40/48Hz maximaler Refreshrate, was doch ein ziemlich blöder Bug im Monitor oder Treiber wäre.
Ich hoffe auf ein baldiges Review einer Seite, die das vertrauenswürdig untersuchen kann.
Der Treiber lässt den Monitor mit dem unteren Limit als aktuelle Hz laufen.
Heißt beim LG mit 48Hz und beim BenQ/Acer mit 40Hz. Macht das Erlebnis erheblich schlechter, wenn du außerhalb des VRR Bereiches bist, da es nun schlechter ist als bei "oberen Limit" mit V-Sync On oder Off.Samm hat schon recht. Ich hatte das ja schon mal versucht, das halbwegs anschaulich darzustellen (https://www.forum-3dcenter.org/vbulletin/showthread.php?p=10559973#post10559973). Das von PCPer behauptete Verhalten macht eigentlich keinen Sinn.
Der Treiber muss die Elektronik steuern. Woher soll das Panel btw. die Elektronik wissen, auf welcher Hz er sich nun einstellen soll? Ist das was ich im Kontext mit G-Sync herauslese.Das ist aber schlicht falsch. Der Treiber handhabt alles Mögliche, aber nicht wie die Panelelektronik auf variable Refreshraten reagieren soll. Auch mit dem eigentlichen Betrieb der variablen Refreshraten selber hat der Treiber nicht unbedingt so viel zu tun. Außer die Unterstützung zu erkennen und dann die Display-Engine so zu konfigurieren, daß das entweder an oder aus ist, tut der nicht viel zur Sache.
Im Endeffekt sendet die GPU nur die Daten (also den Bildinhalt) eines Frames zum Monitor (bei variablen Refreshraten wird die eventuelle Wartedauer [falls man nicht am maximalen Refresh hängt] bis zum nächsten Frame mit ein paar Dummy vblank Datenpaketen gefüllt) und der muß damit klar kommen. Das ist nichts Anderes als bei festen Refreshraten. Dafür ist die Panelelektronik da.
Eine vernünftige Overdrive-Lösung vergleicht auch bisher schon das neue Frame mit dem alten und justiert die Steuerspannungen für die Pixel so, daß man möglichst exakt den neu einzustellenden Farbwert erreicht. Das ist ziemlich unabhängig von der Refreshrate (und verursacht auch kein zusätzliches Anzeigedelay). Die instantane Refreshrate würde man nur benötigen, falls man so eine Art "forward convolution" einbauen will, um das Wegdriften der Farbwerte der Pixel zu kompensieren (man berechnet also mit dem bekannten Verhalten der Pixel und der erwarteten Anzeigedauer eines Frames [simpelste Annahme ist einfach genau so lange wie das letzte angezeigt wurde] etwas andere Farbwerte als von der GPU gesendet und durch das Wegdriften der Pixel sind die Farbwerte der Pixel dann im Mittel über die Anzeigedauer eines Frames korrekt). Das ist aber so oder so eine eher schlechte Lösung, weil man dann die Grenzen des Panels überschreitet und es zu Flimmern anfängt.

[Unicous]

Hier gibt es übrigens das Gespräch so gut wie uneditiert. Da kommen ein paar Sachen deutlich anders rüber.

http://thegametechnician.com/2015/03/23/behind-the-scenes-unedited-audio-of-my-g-sync-chat-with-nvidias-tom-petersen/




Edit:
Nanu, was war denn da nicht in Ordnung mit dem Link?

Am Ende sagt er übrigens Folgendes

Tom Peterson

...having a module allows us to have a little bit more control and support older GPUs;)

Dazu kommt noch ein bißchen "the way I understand it" und dann schwadroniert er darüber, dass der Treiber nicht weiß was es für ein Panel ist und gleichzeitig sagt er, dass jedes Panel von AMD extra "getuned" werden muss.

Dazwischen kommt auch ganz viel Zeugs über die Preisgestaltung. Dass die Kosten gar nicht so hoch wären, aber die Hersteller verlangen könnten was sie wollen und deswegen der ROG Swift z.B. 800 Dollar kostet. Und bei FreeSync ist es genau andersrum, da müssen sie natürlich weniger verlangen weil es Kunde so will, oder so ähnlich.

Also ganz schön viel FUD.

[samm]

Gerüchtehalber soll der Asus MG279Q mit AHVA (vermarktet als IPS) ja nun auch 144Hz statt "nur" 120Hz bieten (Quelle SweClockers (http://www.sweclockers.com/nyhet/20244-asus-mg279q-med-ips-panel-och-144-hz-utrustas-med-amd-freesync)). Ich bin mit meinem Arbeits-Asus mit IPS-Panel ja höchst zufrieden, und wenn sie ihr Knowhow vom SWIFT hier mit einfliessen lassen, könnte das das erste für mich richtig attraktive Adaptive Sync Display werden.

Bei den Samsungs ist es ja noch die Frage, ob VA und in welcher Qualität, ausserdem bin ich zwischen Aussicht auf 120/144Hz beim Asus vs. 4K bei den Samsungs noch etwas zwiegespalten...

[Kartenlehrling]

http://forums.guru3d.com/showthread.php?p=5036662
win a BenQ XL2730Z 27" FREESYNC 144Hz monitor

“I want to use FreeSync Technology because…”

[Unicous]

Because...why not?


John Bridgman (AMD)

Remember that GCN versions refer to the GFX block (graphics/shader/compute) but display capabilities like FreeSync are dictated by the display block version, not GFX.

[...]

Keine Ahnung ob das irgendwelche Auswirkungen auf die kolportieren Rebrands hat.

[Emildeon]

Gibt es Eigentlich schon bezahlbare IPS 1440p 144Hz Monitore?

[aufkrawall]

Nein, der asus dürfte erstmal am günstigsten sein.

[Kartenlehrling]

HEHE, Altenate hat 3x Retourware für 690€ (https://www.alternate.de/html/product/listing/relatedProducts.html?productId=1181210), warscheinlich mit Pixelfehler und dem gelben Lichthof in der unteren rechten Ecke.
Vielleicht hat man Glück und sie sind nicht so schlimm.

Altenate hat wohl die ganze Flugzeugladung bekommen, immer noch der einzige Deutsche Lieferant der den Acer Predator XB270Hu auf dem Lager hat.

https://www.alternate.de/html/product/listing/1181210
Acer Predator XB270HUbprz NVIDIA® G-SYNC™ 750€

https://www.alternate.de/html/product/information/ratings/allRatings.html?articleId=1196167
ALTERNATE Produktbewertungen XB270HUbprz (ips, 144hz, g-sync)

[Troyan]

Samm hat schon recht. Ich hatte das ja schon mal versucht, das halbwegs anschaulich darzustellen (https://www.forum-3dcenter.org/vbulletin/showthread.php?p=10559973#post10559973). Das von PCPer behauptete Verhalten macht eigentlich keinen Sinn.


PCPer hat nachgemessen:

From observations and measurements I've taken, the BENQ panel 'sticks' at 40 Hz when game FPS levels drop <40 FPS. For that situation, the BENQ panel behaves like a fixed 40 Hz refresh rate display, and does what you would expect if V-Sync is on or off (judder or tearing). I will say that since it is refreshing at a relatively low rate, that the judder / tearing is more pronounced than it would be on a regular 60 Hz LCD.
http://www.pcper.com/reviews/Displays/AMD-FreeSync-First-Impressions-and-Technical-Discussion/Inside-and-Outside-VRR-Wind

Aber interessanter ist, dass pclab.pl ihren Artikel mit Videos online haben:
http://pclab.pl/art62755.html

Beispielprogramm ist jedoch "worst-case" mit weißem Objekt auf dunklen Hintergrund.
Außerdem scheint Overdrive auch dann deaktiviert zu sein, wenn man außerhalb des VRR-Bereiches ist.

[Gipsel]

PCPer hat nachgemessen:

http://www.pcper.com/reviews/Displays/AMD-FreeSync-First-Impressions-and-Technical-Discussion/Inside-and-Outside-VRR-WindDas ist immer noch der gleiche Artikel. Was haben die denn gemessen? Ich sehe da nichts. Wenn das stimmen würde, müßte mit VSYNC die Framerate bei Unterschreiten von 40fps direkt auf 20fps fallen. Das ließe sich recht einfach sogar mit fraps feststellen. Das wäre dann wie gesagt ein Bug, das sollte nicht so sein.
Aber daß bei der Beschreibung des Vorgangs zum Wiederholen eines Frames so ein paar Fehler drin sind (man benötigt dazu keinen "local frame buffer" und "logic on the display controller to work", das ist schlicht falsch, wie hier im Thread bereits erklärt) stärkt auch nicht gerade das Vertrauen in PCPer.

[Kartenlehrling]

Die Video-Test von der Polnischen Seite sind schon sehr infomativ.

<30fps sind AMD freesync nicht möglich, freesync wird anscheinen abgeschalten, selbst Tearing entsteht und viel Ghosting und Ruckeln.
G-sync hat weniger Ghosting, darüber brauch man wohl nicht diskutieren, ganz weg bekommen sie es aber auch nicht.

G-sync/freesync ist auf jedenfall etwas worauf wir nun schon 20 Jahre gewartet haben.
Jetzt müssen nur noch alle Monitor >120fps können in jeder Auflösung.

[StefanV]

G-sync/freesync ist auf jedenfall etwas worauf wir nun schon 20 Jahre gewartet haben.
...und seit etwa mitte der 80er dran gearbeitet wurde, es sich aber bisher niemand erbarmt hat, das auch zu bringen...

Musst mal nach variable frame rate googeln. Da findest richtig interessante Dinge. Inkl ein Dokument (k/a, obs ein Paper oder Patent war), in dem variable refresh rate mit CRTs erwähnt wurde...

[Gipsel]

<30fps sind AMD freesync nicht möglich, freesync wird anscheinen abgeschalten, selbst Tearing entsteht und viel Ghosting und Ruckeln.Man kann zwischen VSync an oder aus wählen. Mit VSync an gibt es kein Tearing (die polnische 27/35fps-Videos sind mit VSync aus aufgenommen worden). Ghosting gibt es immer eine bestimmte Anzahl von Frames, weil die Pixel nicht auf den korrekten neuen Farbwert gesetzt werden, sondern der reale Farbwert eines Pixels abhängig vom alten Farbwert ist, die schalten schlicht die Pixel nicht vollständig, völlig unabhängig von der Framerate (Dilettanten!). Die nötige Korrektur ist nicht von der Anzeigedauer eines Frames abhängig. Das haben die Monitorhersteller schlicht verbockt.
G-sync hat weniger Ghosting, darüber brauch man wohl nicht diskutieren, ganz weg bekommen sie es aber auch nicht.Das hat erstmal nichts mit Free-/G-Sync zu tun, das hängt von den Overdrive-Settings des Monitors ab, ist also ein Schwäche der momentan erhältlichen Monitore, keine Schwäche von FreeSync.

Ist es denn wirklich so schwer, die Dinge auseinander zu halten?

Edit:
Das 27fps-Video scheint aber zu zeigen, daß da etwas schief läuft. Das sollte eigentlich smooth sein (weil 25ms maximale Zeit zwischen Refreshs + 6,94ms Zeitdauer für einen Refresh bei mir weniger sind als die 37ms für die 27fps; anders als bei 35fps dürfte es also keine Kollision mit dem Retransmit des Frames geben). Die Grafikkarte sollte jedes Frame zweimal senden, einmal wird es 25ms lang dargestellt, das zweite mal nur 12 ms. Da daß das anscheinend nicht funktioniert, hat da wohl irgendwer auf gut Deutsch Scheiße gebaut.

[Kartenlehrling]

Der 34" kommt mir einfach zu gross vor,
vorallem hat der 29"-21:9 mit 320€ für mich einfach das besser P/L Verhältnis für Gamer.

Lieferung im April ... soo soo

https://www.youtube.com/watch?v=o1QKx7IDw6Y
LG 34UM67 Ultrawide FreeSync Monitor

...............

800$ Acer XB270HU (GSYNC, 27", 144Hz, 2560x1440, IPS)
1000$ Acer XR341CK (GSYNC, 34", 144Hz, 3440x1440, IPS)
600$ ASUS MG279Q (Adaptive Sync -unbranded FreeSync-, 27", 120Hz, 2560x1440, IPS

Wurde das eigentlich von Acer bestätigt das der 34" XR341CK 144hz hat?

[samm]

Edit:
Das 27fps-Video scheint aber zu zeigen, daß da etwas schief läuft. Das sollte eigentlich smooth sein (weil 25ms maximale Zeit zwischen Refreshs + 6,94ms Zeitdauer für einen Refresh bei mir weniger sind als die 37ms für die 27fps; anders als bei 35fps dürfte es also keine Kollision mit dem Retransmit des Frames geben). Die Grafikkarte sollte jedes Frame zweimal senden, einmal wird es 25ms lang dargestellt, das zweite mal nur 12 ms. Da daß das anscheinend nicht funktioniert, hat da wohl irgendwer auf gut Deutsch Scheiße gebaut.Aaah, jetzt wird es spannender :) Wenn nun noch anerkannt gute Review-Seiten dies entsprechend aufzeigen können, sollten die Firmware-Coder der Monitore hoffentlich aufwachen. Meine Hoffnung ist ja, dass Asus das mitbekommt und richtig macht, oder sonst einer der künftigen IPS/AHVA oder hoffentlich auch *VA-Monitor-Hersteller.

[mironicus]

GSync arbeitet mit automatischer Frequenz-Vervielfachung, wenn die Bildrate unter 36 fällt (je nach Monitor). Aus 36 Hz werden dann z.B. 72 Hz. GSync kann also bis 1 FPS durchgehend tearingfrei und konstant arbeiten.

http://www.pcper.com/reviews/Graphics-Cards/Dissecting-G-Sync-and-FreeSync-How-Technologies-Differ

[Gipsel]

Aaah, jetzt wird es spannender :) Wenn nun noch anerkannt gute Review-Seiten dies entsprechend aufzeigen können, sollten die Firmware-Coder der Monitore hoffentlich aufwachen.Das mit dem fehlenden Overdrive bzw. dem Ghosting ist ein Problem der Monitorhersteller. Das erwähnte bei 27fps ist eins von AMD. Vermutlich haben die da einen Bug bei der Konfiguration des Verhaltens von VSync an/aus unterhalb des dynamischen Bereichs eingebaut. Wollen wir mal hoffen, daß die nicht Monate benötigen, um das zu fixen.
Irgendwie kapiere ich nicht, wie sowas immer wieder verbockt wird. Ich meine, selbst unter Zeitdruck checke ich doch zumindest das grundlegende Verhalten in ein oder zwei corner cases. :|

@mironicus:
Die naivste FreeSync-Lösung (die AMD aber offenbar im Treiber durch einen Bug "sabotiert" hat) sollte z.B. beim Fall der 27fps auch 54 Refreshes am Monitor produzieren.

[samm]

GSync arbeitet mit automatischer Frequenz-Vervielfachung, wenn die Bildrate unter 36 fällt (je nach Monitor). Aus 36 Hz werden dann z.B. 72 Hz. GSync kann also bis 1 FPS durchgehend tearingfrei und konstant arbeiten.

http://www.pcper.com/reviews/Graphics-Cards/Dissecting-G-Sync-and-FreeSync-How-Technologies-DifferFlackerte nicht zumindest ein GSync-Monitor heftig bei niedrigen fps (als ich das noch verfolgt hatte, sprich bei den ersten paar Bastel- und danach Fertiglösungen) - würde die Technologie wirklich grundsätzlich so funktionieren, wäre das doch nicht der Fall gewesen?


@Gipsel: die Grafikkarte sollte doch einfach die Frames liefern, wenn sie fertig sind und der Bildschirm ready (bei PCPer gezeigten 144Hz wären das dann alle 1/144s, sprich alle knapp 7ms) - sehe ich da etwas falsch? Wenn nein: Wie kann sowas auf Treiber-Ebene verbockt werden, ist das nicht straight-forward (müsste ja schon beim normalen VSync so gemacht werden?)

[Troyan]

Bei 0 FPS, weil plötzlich kein Refresh mehr kommt. Dann wird der Monitor neu"resettet".
nVidia hat das Verhalten vom Kaufmodul zu kaufbaren Monitoren geändert. Verhält sich jetzt so, wie im PCPer Video zu sehen.

Es wurde nicht verbockt bei Freesync. Es wurde einfach nicht eingebaut.

[samm]

Es wurde nicht verbockt bei Freesync. Es wurde einfach nicht eingebaut.Wie gesagt, sie müssen das doch schon bei normalem VSync einbauen. Beim Initialisieren: Treiber: "Monitor, wie ist deine Refreshrate" Monitor: "60Hz" Im Betrieb dann: Treiber: "ok, dann liefere ich dir das nächste Bild, wenn es bereit ist und 16ms vergangen sind, ansonsten bekommst du nochmal das letzte Bild".
Bei 144 Hz müsste der Monitor halt sagen, dass er 144Hz kann und die Grafikkarte müsste dementsprechend alle 7ms das gleiche oder ein neues Bild schicken.
Die gleiche Logik müsste für FreeSync mit VSync on auch gelten ausserhalb des VRR-Windows. Deswegen wundert es mich, wie das Treibersachen sein soll - VSync können die doch seit Jahren.

Danke für den Hinweis bezüglich der 0Hz und der Einbaumodul-Geschichte!

[Gipsel]

die Grafikkarte sollte doch einfach die Frames liefern, wenn sie fertig sind und der Bildschirm ready (bei PCPer gezeigten 144Hz wären das dann alle 1/144s, sprich alle knapp 7ms) - sehe ich da etwas falsch? Wenn nein: Wie kann sowas auf Treiber-Ebene verbockt werden, ist das nicht straight-forward (müsste ja schon beim normalen VSync so gemacht werden?)Eigentlich ist es völlig straightforward, habe ich ja schon weiter vorne im Thread mal erklärt gehabt.
Zusätzlich zum Senden des Bildes, wenn ein Frame fertig ist, muß die Grafikkarte auch sicherstellen, daß die maximale Zeitdauer zwischen zwei Frames nicht überschritten wird (wenn der Monitor also 40Hz als minimale Refreshrate meldet, muß mindestens alle 25ms ein Frame geschickt werden, gibt es kein neues, eben das alte). Genau das muß GSync auch machen, nur das eben das Panel vom internen Speicher des GSync-Moduls refreshed wird (was aber genausoviel Zeit benötigt, da die Daten über ein normales LVDS-Interface ans Panel rausgeschrieben werden, das ist also gehupft wie gesprungen).
Diese Retransmits werden jetzt offenbar verbockt, bzw. das Verhalten nach einer Neuübertragung eines wiederholten Frames. Offenbar sendet die GPU einfach nicht das neue, wenn es fertig ist, auch wenn der Retransmit schon beendet sein sollte. Sprich die Logik des Verhaltens unterhalb des dynamischen Bereiches ist kaputt. Das sollte eine Frage der Programmierung der Display-Engines sein, also wann und unter welchen Bedingungen der Transfer eines Frames gestartet wird und ob ein Bufferflip währenddessen geblockt wird oder nicht. Hoffentlich ist das einfach nur ein Konfigurationsproblem, ich sehe ehrlich gesagt nicht, wie das ein prinzipielle Limitierung der Hardware sein sollte.
Es wurde nicht verbockt bei Freesync. Es wurde einfach nicht eingebaut.Framevervielfachung passiert ganz automatisch, auch schon ohne jegliche variablen Frameraten. Da braucht es keine Frametimevorhersage auf einem GSYNC-Modul dazu ;).
Damit holt man "nur" in ein paar Problemfällen was raus.

[Thomas Gräf]

Mal eine kurze zwischen Frage, kommt das G/Free Sync für Gamer die immer +60 FPS zokken überhaupt sinnvoll zum Arbeiten?

[HPVD]

...Wenn nun noch anerkannt gute Review-Seiten dies entsprechend aufzeigen können...

Vielleicht sollte man das einfach mal anstoßen, und diesem Thema hier auf der Startseite einen kleinen Bericht widmen
-> dafür gibts dann im Web schon genug Multiplier-Seiten :smile:
und schon kommt der Stein ins rollen...

[samm]

Ich glaube, der rollt schon :) Je seriöser, desto länger geht es halt, einen guten Artikel mit nachvollziehbaren Untersuchungen herzustellen.

[Kartenlehrling]

https://youtu.be/VkrJU5d2RfA?t=1560
Dissecting G-Sync and FreeSync - How the Technologies Differ (ab der 26:00min schauen)

Diesen Trick der Nvidia bei Gsync einsetzt sollte doch bei Freesync auch möglich sein.
Dabei wär es doch einfach hätten sie zb. bei LG-21:9 nicht ein 48-75Hz sondern ein 40-80Hz Freesync Fenster und
mit 40Hz verdoppelt sie einfach wieder die Bildwiedergabe auf 80Hz und geben das Bild zweimal aus, das bei 39fps>78Hz sind 38fps> 76Hz und so weiter.
Damit würde man auf 20fps/40Hz kommen und das sollte doch nun wirklich reichen.

AMD hat den Monitorhersteller wohl zuviel "Freiheit" eingeräumt, man hätte wohl mehr Unterstüzung und Richtlinien einbringen sollen, soo kocht jeder sein eigenes Süppchen.
Bin ja gespannt was Samsung abliefert, letzte infos waren ja 60Hz, damit kann man dann warscheinlich gar nichts mit anfangen.

[Grestorn]

Super interessanter Bericht. Danke für den Link!

[fondness]

https://youtu.be/VkrJU5d2RfA?t=1560
Dissecting G-Sync and FreeSync - How the Technologies Differ (ab der 26:00min schauen)

Diesen Trick der Nvidia bei Gsync einsetzt sollte doch bei Freesync auch möglich sein.
Dabei wär es doch einfach hätten sie zb. bei LG-21:9 nicht ein 48-75Hz sondern ein 40-80Hz Freesync Fenster und
mit 40Hz verdoppelt sie einfach wieder die Bildwiedergabe auf 80Hz und geben das Bild zweimal aus, das bei 39fps>78Hz sind 38fps> 76Hz und so weiter.
Damit würde man auf 20fps/40Hz kommen und das sollte doch nun wirklich reichen.

AMD hat den Monitorhersteller wohl zuviel "Freiheit" eingeräumt, man hätte wohl mehr Unterstüzung und Richtlinien einbringen sollen, soo kocht jeder sein eigenes Süppchen.
Bin ja gespannt was Samsung abliefert, letzte infos waren ja 60Hz, damit kann man dann warscheinlich gar nichts mit anfangen.

Jap, das erklärt auch warum NV 30hz Mindestrefreshrate verlangt, denn nur so kann man Bilder zweimal ausgeben und landet trotzdem noch bei 60hz was jeder Monitor darstellen kann. Bei den LG Dingern könnte man diese Technik gar nicht verwenden und AMD müsste damit für jeden Monitor separat den Treiber anpassen.

[mironicus]

Auf den Bericht habe ich schon letzte Seite hingewiesen, vor 2 Tagen. :)

[Gipsel]

Auf den Bericht habe ich schon letzte Seite hingewiesen, vor 2 Tagen. :)Und ich habe auch schon (mehrfach) geschrieben, daß das Senden des alten Frames bei Unterschreiten der minimalen Refreshrate sowieso schon passiert. Und dafür benötigt es natürlich keine Treiberupdates für jedes Panel, das ist schlicht Blödsinn, was die da sagen.

Was momentan verbugt zu sein scheint, ist, daß nach so einem Refresh mit dem alten Frame wegen Überschreitung der maximalen Zeitspanne zwischen zwei Refreshs (bei 40Hz Minimum also 25ms) der nächste Refresh offenbar frühestens erst wieder 25ms später gemacht wird, nicht schon nach 6,9ms (so lange dauert der Transfer des Frames bei einem 40-144Hz Modell). Die Konfigurieren also die Display-Engine der GPU schlicht nicht richtig (vermutlich haben die das mit der VSync an/aus Wahlmöglichkeit verbaselt).

[InsaneDruid]

Nach Unterschreiten der unteren Grenze läuft das Freesync-Panel mit der unteren Grenzfrequenz (40/48Hz in den aktuellen Displays) weiter, im nichtadaptiven Mode. Daher muss man dann wieder auf den Monitor warten, bis der ganzzahlige Framezahlen (im Vsync-Fallback) fertig hat. Bei NV hält man diese Wartezeiten klein, indem man nach Unterschreiten der unteren Grenzfrequenz den Monitor mit der doppelten aktuellen Frequenz betreibt.

Ich skizzier mal einen Fall: zur Einfachheit setz ich die untere Grenzfrequenz mal für beide Seiten auf 40Hz fest.

Game läuft eine Zeit bei x=45fps, beide Systeme laufen im adaptiven Mode mit 1/x=1/45 Frametimes.
Durch eine fiese Szene schnellt die Frametime kurzzeitig auf 1/(x<40) hoch (also 1/39 oder 1/35 oder 1/25, Hauptsache unter die untere Grenze). Bei NV refresht das Panel jetzt aller 1/(x*2) Sekunden, bei AMD aber nur aller 1/40 Sekunden, und zwar unabhingig von der tatsächlichen Größe von x. Daher hat man dann wieder Sync-Verluste und eine größere maximale Latenz bis das Panel auf verkürzte Frametimes reagieren kann.

[Gipsel]

Und gerade die Erklärung ist hanebüchen. Das ist ein Bug.
Der Transfer eines Frames dauert nur 6,9ms. Die Dauer bis zum nächsten Refresh ist dann variabel (weder GPU noch Monitor müssen wissen, wann der kommt) und wird mit vblank aufgefüllt. Wenn ein neues Frame kommt, wird direkt mit dem Refresh angefangen, wenn nicht, erfolgt nach 25ms (bei der 40-144Hz Range) ein Zwangsrefresh seitens der GPU (die sendet also das alte Frame nochmal). Der Transfer ist natürlich wieder nach 6,9ms fertig, waraufhin wiederum eine variable vblank-Dauer bis zum nächsten Refresh folgen kann. Daß da momentan volle 25ms gewartet werden, kann nur ein Bug sein (vermutlich vom Einbau der vsync-on/off Wahlmöglichkeit, was da etwas durcheinander bringt).

Btw., wenn bei G-Sync eine Frametime mal über die Grenze springt, wie funktioniert das dann eigentlich genau? Angenommen man ist zuerst bei konstant 33.3fps, also 30ms Frametime und das nächste Frame benötigt plötzlich 35ms. Das Panel will aber hier nach spätestens 33ms refreshed werden, was auch bei GSync so gute 6ms benötigen dürfte (auch wenn es vom Speicher des GSync-Moduls kommt, muß das Frame immer noch durch das LVDS-Interface des Panels, was einen maximalen Refresh von 144 Hz erlaubt). Er ist dann also auch erstmal blockiert (und kann das neue Frame dann erst nach ~40ms ausgeben, wenn der nach 33.3ms angefangene Zwangsrefresh vorbei ist), weil sich so ein Sprung wohl kaum vorhersagen läßt. ;)

[Grestorn]

Gipsel, wie erklärst Du Dir dann die Ergebnisse der Messung durch das Oszilloskop?

[ndrs]

Gipsel, wie erklärst Du Dir dann die Ergebnisse der Messung durch das Oszilloskop?
Er meint einen Bug im AMD-Treiber, nicht bei der Messung.

[Troyan]

Der Monitor steht auf 40Hz. Die Verbindung zwischen Karte und Monitor ist nicht mehr im AdaptiveSync-Modus. Der nächste Refresh kommt im jetzigen Zustand erst nach 25ms und nicht nach 6,9ms.

[Gipsel]

Der Monitor steht auf 40Hz. Die Verbindung zwischen Karte und Monitor ist nicht mehr im AdaptiveSync-Modus. Der nächste Refresh kommt im jetzigen Zustand erst nach 25ms und nicht nach 6,9ms.Warum sollte man das freiwillig so machen, wenn es gar nicht nötig ist? Man muß bei Verlassen der Range den A-Sync-Modus doch nicht verlassen (und ich vermute auch mal ganz stark, daß das AMD auch nicht macht). Es ist sogar einfacher, da drin zu bleiben (weniger Fallunterscheidungen nötig), so daß die Display-Engine immer stur das Gleiche macht. Völlig unabhängig von der Framerate funktioniert das einfach. Das ist wie gesagt höchstwahrscheinlich schlicht ein Bug, alles Andere wäre aus technischer Sicht schon reichlich komisch.

[InsaneDruid]

Es ist aber nötig. Du kannst das Panel nicht beliebig lange ohne Refresh lassen. Unter der unteren Grenze muss das Panel von den Frames entkoppelt werden, um seine 1/40 oder 1/x Refreshzyklen zu erlauben (die Frames brauchen unter dieser Grenze ja zu lange).

Wie genau gsync alles implementiert weiß ich nicht. Messen, ob nach einer gewissen latenz ein neues Bild vorliegt, wenn nicht ->refreshrate verdoppeln. ab welchem frame das kommt, kp. Deswegen wird das wohl auch schon bei ca 36fps gemacht, nicht erst bei 30. So kann man, wenn nach 1/36 frames kein neues bild da ist noch warten, da man hier noch viel platz bis zum zwangsrefresh hat.

Da das Panel zeilenweise neu aufgebaut wird, nicht im ganzen stimmt deine "addiere 6ms wegen LVDS-übertragung" auch nicht.

[Troyan]

Die 36FPS-Grenze bezieht sich hier auf den Acer IPS Monitor. Beim Swift passiert dies erst unter 30FPS.

[InsaneDruid]

Laut dokumentierten Messungen von PCper (https://www.youtube.com/watch?v=VkrJU5d2RfA) auch beim Swift.

Wie gesagt, ist auch in sich stimmig, das vor dem eigentlichen Panel-Limit zu machen. Wenn man es direkt am Limit macht, ist es für den ersten Frame, der über die Schwelle geht, ansonsten zu spät. Kann ja erst der nächste mit Framedopplung versehen werden.

[robbitop]

Der Acer Predator hat eine untere Schwelle von 36 fps? Ich dachte, dass es auch 30 fps sind? Gibt es dafür eine Quelle? MWn sollte das doch bei allen G-Sync Monitoren gleich sein.

[Grestorn]

Durch das einfügen zusätzlicher Frames spielt das untere Limit doch eh überhaupt keine Rolle. De Fakto ist es damit kleiner als 1 fps

[Troyan]

Laut dokumentierten Messungen von PCper (https://www.youtube.com/watch?v=VkrJU5d2RfA) auch beim Swift.

Wie gesagt, ist auch in sich stimmig, das vor dem eigentlichen Panel-Limit zu machen. Wenn man es direkt am Limit macht, ist es für den ersten Frame, der über die Schwelle geht, ansonsten zu spät. Kann ja erst der nächste mit Framedopplung versehen werden.

Das ist der Acer Monitor. Der Swift geht bis 30Hz runter:

Further, the first transition (passing through 30 FPS on the way down) results in an instantaneous change in refresh rate from 30 to 60 Hz
http://www.pcper.com/reviews/Displays/AMD-FreeSync-First-Impressions-and-Technical-Discussion/Inside-and-Outside-VRR-Wind

Der Acer ist der erste G-Sync Monitor mit IPS Panel. Das Limit ist nie das G-Sync Modul sondern immer nur das verwendete Panel. Deswegen ist der Vergleich von AMD auch ziemlich sinnlos und frech.

[robbitop]

@Grestorn
Bei wechselnder Framerate schon. Den einen Frame musst du 2x so lange anzeigen (2x Refresh) den anderen vieleicht 4x und einen anderen nur 1x. Dadurch sind auch wieder die Frametimes nicht so schön.
Wobei ein Panel mit höherer Refreshrate (z.B. ein 144 Hz Panel) den Refresh schneller aufbauen kann.

Ich finde, dass man es beim Swift in der Praxis merkt.

[Grestorn]

Spätestens nach 7ms (1s/144) kann doch jederzeit ein anderes Frame angezeigt werden, also quasi ohne Zeitverlust. Wieso 2x Refresh?

Nehmen wir an, die Framerate ist gerade 15fps. Er zeigt also 2x das gleiche Frame an, so dass 30 fps draus werden. Wenn jetzt quasi sofort nachdem eines der Frames (egal ob das erste oder zweite) ausgegeben wurde, wieder ein neues zur Verfügung steht (weil die Berechnung sich schlagartig extrem vereinfacht) kann der GSync mit 144 Hz dieses doch jederzeit mit einer maximalen Verzögerung von 7ms darstellen.

[ndrs]

Es ist aber nötig. Du kannst das Panel nicht beliebig lange ohne Refresh lassen. Unter der unteren Grenze muss das Panel von den Frames entkoppelt werden, um seine 1/40 oder 1/x Refreshzyklen zu erlauben (die Frames brauchen unter dieser Grenze ja zu lange).

Das sollte dann aber (wenn es vernünftig implementiert ist) nicht die Aufgabe des Panels sein. Die GPU muss einfach merken "Neuer Frame ist noch nicht fertig. Die maximale Frametime wird gleich überschritten. Also sende ich nochmal schnell den alten Frame raus". Der Monitor macht einfach so lange nichts, bis ein neues Bild kommt. Wann das ist, legt allein die GPU fest.

Das Panel muss also nicht von der GPU entkoppelt werden, sondern (Schlagt mich jetzt nicht, wenn die Begriffe nicht stimmen) der DisplayPort-Controller in der GPU muss vom eigentlichen Renderpfad entkoppelt werden.

Jede andere Implementierung wäre meiner Meinung nach schlicht dumm.

Edit: @Grestorn: Genau so sehe ich das auch. Verdoppeln eines Frames und diesem die gleiche Frametime zu geben würde auch wieder potentiell zu mikroruckeln führen.

[robbitop]

Spätestens nach 7ms (1s/144) kann doch jederzeit ein anderes Frame angezeigt werden, also quasi ohne Zeitverlust. Wieso 2x Refresh?

Nehmen wir an, die Framerate ist gerade 15fps. Er zeigt also 2x das gleiche Frame an, so dass 30 fps draus werden. Wenn jetzt quasi sofort nachdem eines der Frames (egal ob das erste oder zweite) ausgegeben wurde, wieder ein neues zur Verfügung steht (weil die Berechnung sich schlagartig extrem vereinfacht) kann der GSync mit 144 Hz dieses doch jederzeit mit einer maximalen Verzögerung von 7ms darstellen.
Aber eben erst nach 7 ms. Im Worst Case (Framerate ist ja in Spielen selten konstant) verpasst du aber gerade so das nächste Frame und musst erstmal diese 7 ms für das verdoppelte Frame warten, eh du das nächste aufbauen kannst. Wenn diese 7 ms immer mal wieder eingestreut werden, macht das die Frametimes kaputt.

Das ist bei einem 144 Hz Display - da gebe ich dir tendenziell Recht - aber wesentlich weniger schlimm als bei einem 60 Hz Display (16 ms).

[Grestorn]

Diese potentielle Verzögerung von max(!) 7ms bei einem 144 Hz Monitor hast Du aber immer, so lange Du nicht mit Tearing leben willst. Und beim besten Willen, bei 7ms glaub ich nicht mehr daran, dass sich selbst Profis objektiv davon beiinträchtigen lassen.

Mit der Thematik der Vervielfachung der Frames im unteren Bereich hat das doch erst mal überhaupt nichts zu tun!

[robbitop]

Bei G-Sync wird sobald ein Frame fertig ist, dieser aufgebaut (7ms). Wenn man den verpasst und den letzten neu aufbauen muss, kommen weitere 7ms für das gedoppelte Frame dazu.

[Grestorn]

Bei G-Sync wird sobald ein Frame fertig ist, dieser aufgebaut (7ms). Wenn man den verpasst und den letzten neu aufbauen muss, kommen weitere 7ms für das gedoppelte Frame dazu.

Wieso? Wenn das erste Frame der beiden schon ausgegeben ist, kann die zusätzliche Verzögerung ja nur noch . Max 7 ms betragen.

Wenn das erste Frame noch nicht ausgegeben ist, muss der Treiber bzw. das GSync Modul das alte Frame doch keine zweimal mehr ausgeben, also ist auch dann die Verzögerung Max. 7ms.

[InsaneDruid]

Das ist der Acer Monitor. Der Swift geht bis 30Hz runter:

http://www.pcper.com/reviews/Displays/AMD-FreeSync-First-Impressions-and-Technical-Discussion/Inside-and-Outside-VRR-Wind

Der Acer ist der erste G-Sync Monitor mit IPS Panel. Das Limit ist nie das G-Sync Modul sondern immer nur das verwendete Panel. Deswegen ist der Vergleich von AMD auch ziemlich sinnlos und frech.

Kurz nach einer Minute: "What we have hooked up here is a G-Sync display, the ROG Swift" Man sieht auch ganz deutlich den Fuß des ROG, nicht des Acer. Sie sprechen auch von 1ms TN.

Bei 8.30 sind sie dann bei 36fps "something just happened there". Interessant auch dass er dann sagt "if i go up one, it wont..." scheint also eine gewisse Hysterese vorzuliegen.

[robbitop]

Wieso? Wenn das erste Frame der beiden schon ausgegeben ist, kann die zusätzliche Verzögerung ja nur noch . Max 7 ms betragen.

Wenn das erste Frame noch nicht ausgegeben ist, muss der Treiber bzw. das GSync Modul das alte Frame doch keine zweimal mehr ausgeben, also ist auch dann die Verzögerung Max. 7ms.


Wenn Frames > 30:

Frame 1 -> Frame 2 (+ 7 ms)

Wenn Frames < 30:

Frame 1 -> Frame 1 (+7ms) -> Frame 2 (+7ms)

Weil Frame 2 einfach zu spät kam, musste Frame 1 nochmal angezeigt werden. Im worst Case kommt es 1 ms zu spät, um direkt aufgebaut zu werden. Also muss Frame 1 wiederholt werden (Panel degradation) bevor Frame 2 aufgebaut werden kann. (obiges ist nur für stark schwankende Frametimes relevant)

[InsaneDruid]

Das sollte dann aber (wenn es vernünftig implementiert ist) nicht die Aufgabe des Panels sein. Die GPU muss einfach merken "Neuer Frame ist noch nicht fertig. Die maximale Frametime wird gleich überschritten. Also sende ich nochmal schnell den alten Frame raus". Der Monitor macht einfach so lange nichts, bis ein neues Bild kommt. Wann das ist, legt allein die GPU fest.

Das Panel muss also nicht von der GPU entkoppelt werden, sondern (Schlagt mich jetzt nicht, wenn die Begriffe nicht stimmen) der DisplayPort-Controller in der GPU muss vom eigentlichen Renderpfad entkoppelt werden.

Jede andere Implementierung wäre meiner Meinung nach schlicht dumm.

Edit: @Grestorn: Genau so sehe ich das auch. Verdoppeln eines Frames und diesem die gleiche Frametime zu geben würde auch wieder potentiell zu mikroruckeln führen.

Sicher das könnte auch eine Softwarelösung machen. Macht ATI aber offensichtlich nicht, und NV wohl eher im scaler selbst. Spart die Übertragung (wird sicher zwischengespeichert) und ist transparent. Evtl. ein Punkt warum So gut wie jede NV Karte Gsync beherrscht.

Ist auch nicht ganz so wie von dir beschrieben. Wenn das System merkt, dass der neue Frame nicht innerhalb 1/36s fertig wird kann eben nicht der aktuelle "nochmal gesendet (dargestellt whatever) werden. Man merkt es ja erst nach >1/37s. man müsste aber schon nach 1/(36*2)s neu senden.
Wenn man merkt, es kommt das Frame erst nach 1/37s wird das nächste Frame zweimal angezeigt. Möglicherweise auch asymmetrisch lang. Einmal fix 1/(36*2) und dann solange, bis das nächste fertig ist. Genau halbieren kann man es ja nicht da man die Gesamtdauer des aktuell berechneten Frames nicht kennt, es sei denn man verzögert die ganze Kette um eine Frame, was der ROG aber laut Prad nicht macht.

[InsaneDruid]

Wenn Frames > 30:

Frame 1 -> Frame 2 (+ 7 ms)

Wenn Frames < 30:

Frame 1 -> Frame 1 (+7ms) -> Frame 2 (+7ms)

Weil Frame 2 einfach zu spät kam, musste Frame 1 nochmal angezeigt werden. Im worst Case kommt es 1 ms zu spät, um direkt aufgebaut zu werden. Also muss Frame 1 wiederholt werden (Panel degradation) bevor Frame 2 aufgebaut werden kann. (obiges ist nur für stark schwankende Frametimes relevant)

Nope. Wenn man NACH 1/36 (oder 1/30, völlig egal) das erste Bild NOCH mal anzeigen würde, dann wäre die Gesamtanzeigedauer dieses Frames bei 1/(36/2), herzlichen Glückwunsch, du hast grade die gefühlte FPS halbiert.

EDIT: deshalb testet man wohl auch nicht direkt an der Panelgrenze (30Hz) sondern schon bei 36HZ. Denn damit hat man noch Luft, um auf das Frame zu warten, weiß aber schon, das man das nächste doppeln muss.

[Grestorn]

Frame 1 -> Frame 1 (+7ms) -> Frame 2 (+7ms)

Weil Frame 2 einfach zu spät kam, musste Frame 1 nochmal angezeigt werden. Im worst Case kommt es 1 ms zu spät, um direkt aufgebaut zu werden. Also muss Frame 1 wiederholt werden (Panel degradation) bevor Frame 2 aufgebaut werden kann. (obiges ist nur für stark schwankende Frametimes relevant)

Ok, wann genau steht das neue Frame aus der Renderpipeline zur Verfügung? Lass uns mal Szenarien auf einer Timeline anschauen:

Konstante 15 fps (x: Rendering fertig, | Frame am Monitor sichtbar, mit Verdoppelung. Zwei Striche (--) sind 7ms (ohne Rücksicht auf korrektes Verhältnis in der Darstellung)

---x-|-----|---x-|-----|---x-|-----|---x-|-----|---x-|-----|---x-|-----|---x-|-----|---x-|-----|---x-|-----|


So, jetzt machen wir mal ein paar Szenarien, dass das neue Frame y vorzeitig fertig wird. ° soll hier die Anzeige des neuen Frames symbolisieren:

a)
---x-|-----|y-°-- ...

b)
---x-|-y-°-- ...

c)
---xy|-°--...

Bei Szenario a und b sehe ich keine größere Verzögerung als 7 ms.

Nur bei Szenario c, wo das neue Frame innerhalb der 7 ms zwischen des Renderings der vorhergehenden Frames und dessen Darstellung fertig wird, käme es zu einer zusätzlichen Verzögerung von 0-7ms (also insgesamt dann 8-14ms). Das ist aber schon sehr speziell, dass die Frametime schlagartig von 66ms auf unter 7 ms fällt.

Insane: So wie ich GSync verstehe, schickt der Treiber das Bild nicht mehrfach, vielmehr schickt das GSync Modul im Monitor das Bild, wenn nötig, mehrfach an das Panel.

[robbitop]

@insanedruid
Das Panel aktualisiert AFAIK mit Refreshrate des Panels also 1/144 s. Die Bilder werden so lange gehalten, bis das nächste kommt. Jeder Bildaufbau dauert aber nur 1/144s. Nur die Anzahl der Bilder pro Sekunde ändert sich.



Nur bei Szenario, wo das neue Frame innerhalb der 7 ms zwischen des renderings der vorhergehenden Frames und dessen Darstellung fertig wird, käme es zu einer zusätzlichen Verzögerung von 0-7ms (also insgesamt dann 8-14ms). Das ist aber schon sehr speziell, dass die Frametime schlagartig von 66ms auf unter 7 ms fällt.
Genau das Szenario meine ich. Frametimes können häufiger mal sich massiv ändern. Allerdings ist der Effekt bei schnellen Panels natürlich viel kleiner als bei konventionellen 60 Hz Panels.

[InsaneDruid]

Nein, natürlich nicht. Das Panel refresht mit den FPS. Das ist doch grade der Sinn und Zweck von G/Freesync. Von einem angezeigten Frame ausgehen wird der Refresh so lange herausgezögert, bis entweder ein neuer Frame von der Graka geliefert wird, oder die maximale Refreshzeit erreicht ist, und auf feste Refreshzeiten der Länge der maximalen Wartezeit (mit oder ohne Sync) umgeschaltet wird (bei Freesync) oder auf Reffreshzeiten die doppelt, dreifach oder vierfach so kurz wie die maximale Wartezeit sind. (bei Gsync) Bei letzter wahrscheinlich sogar in der Form fix/adaptiv/fix/adaptiv... indem man ein Frame mit 1/72s anzeigt, und dann nochmal bis das nächste Frame vorhanden ist (durch das eingefügte kurze, aber fixe wiederholte Frame hat man die Wartezeit verkürzt, und kann somit auch auf Frames unter der unteren FPS-Grenze warten.
Was du beschreibst ist einfach nur Vsync mit hoher Refreshrate und niedriger FPS.
Letzteres ist mein Schluss aus dem PCPer-Video, das definitiv und nachweislich eine (annähernde) Verdopplung der Refreshzyklen (also Halbierung der Refreshzeit) unterhalb der Grenze von 1/37s Frametime zeigt, gleichzeitig dsichtbar ist, dass die Framezeiten von 2 aufeinandervolgenden (Display)Frames weiterhin adaptiv bleiben (um 11.50 im video sieht man es, wenn er von 24 auf 20Hz runter steppt und dabei die Refreshzyklen nicht konstant bleiben, sondern weiter werden un dem Fakt, dass eine exakte Halbierung nicht möglich ist, da man von einem Event, dessen Gesamtlänge man nicht kennt, bevor diese eingetreten ist nicht die Hälfte ermitteln kann. Genausowenig wie du jemand Hälfte seiner Lebenszeit feiern kann.
In dem Video sieht man das auch bei 20Hz die Refreshzyklen des Monitors adaptiv bleiben. Es ist jedoch nicht perfekt ersichtlich, ob es wirklich 1fix ein adaptiv ist, aber es sieht ziemlich danach aus.

Die feste Zeit für einen Bildaufbau gibts auch nicht, und wenn ist es keinesfalls die Refreshzeit, es wird ja zeilenweise aufgebaut, und jeder Pixel ist abhängig von Ausgangsfarbe und Zielafarbe fertig. Mit einem scanning Backlight kann man die Bildaufbauzeit sogar maskieren, indem in dieser Zeit das Backlight aus ist, und nur dann leuchtet, wenn die Pixel (einer bzw mehrerer Zeile eines Backlightblocks) sich stabilisiert haben. (Sluyterman: What is needed in LCD panels to achieve CRT-like motion portrayal)

[ndrs]

Sicher das könnte auch eine Softwarelösung machen.
Und genau da geht hoffentlich die Reise sehr bald hin. Alles andere wäre dumm.

Ist auch nicht ganz so wie von dir beschrieben. Wenn das System merkt, dass der neue Frame nicht innerhalb 1/36s fertig wird kann eben nicht der aktuelle "nochmal gesendet (dargestellt whatever) werden. Man merkt es ja erst nach >1/37s. man müsste aber schon nach 1/(36*2)s neu senden.

Warum nach halber Frametime und nicht nach 1/36s-1/144s ? Wenn mein Monitor praktisch 144Hz kann, kann es natürlich nicht sein, dass die Übertragung länger als 1/144s dauert. Das entspricht dann 48 Hz. Man würde also bei einer Framerate der GPU von 35,9 FPS bei effektiv 48 Hz landen. Wenn der Monitor 144Hz kann, kann er auch alles 1/144s ein neues Bild annehmen, egal ob das alte länger dargestellt wurde.

[Gipsel]

Es ist aber nötig. Du kannst das Panel nicht beliebig lange ohne Refresh lassen. Unter der unteren Grenze muss das Panel von den Frames entkoppelt werden, um seine 1/40 oder 1/x Refreshzyklen zu erlauben (die Frames brauchen unter dieser Grenze ja zu lange).Du hast offenbar nicht verstanden, was ich beschrieben habe. Am besten liest Du es nochmal! Natürlich wird das maximale Refreshintervall eingehalten und ein Zwangsrefresh (also ein dupliziertes Frame) eingeschoben. Aber dieser dauert eben (wie auch bei GSync) nur wenige Millisekunden. Es besteht also keine Nötigkeit, eine 25ms Zwangspause einzulegen.

Was die da bezüglich einer Treiberlösung in dem Video erzählen, vernachlässigt, daß die Display-Engine sowieso schon feststellt, daß die maximale Refreshintervall erreicht ist und dann eben den Zwangsrefresh einschiebt. Warum soll das Panel nun mindestens 25ms nach so einem Zwangsrefresh bis zum nächsten Refresh warten, auch wenn es vorher schon ein neues Frame gibt? Das ergibt nicht den geringsten Sinn.
Das korrekte Verhalten sollte also ohne Bug gerade nicht das beobachtete sein (sondern relativ ähnlich zu GSync, aber im Zweifelsfall eben ohne Frametime"vorhersage" [was im Prinzip nur bedeutet, daß man die Frametime des vorhergehenden Frames annimmt], die auch schief gehen kann). Bei 30 fps (33,3ms Frametime) sollte ein Frame die maximalen 25ms halten, dann die GPU den Zwangsrefresh einschieben (der ist nach dann insgesamt 31,9ms vorbei), dann 1,4ms vblank-Pakete einschieben, um schließlich mit Fertigwerden des neuen Frames nach exakt 33,3ms den Transfer des nächsten Bildes zu starten. Das funktioniert prinzipiell unabhängig vom genauen Panel, erfordert also auch keine Treiberanpassungen für jedes Panel. Das einzige, was GSync offenbar zusätzlich macht, ist daß wenn die Frametime eines Frames 5/6 der maximalen Frametime überschreitet, beim nächsten Frame ein Refresh (mit einem wiederholten Frame) bereits nach der Hälfte der Frametime des dann vorherigen Frames durchzuführen, um so mögliche Kollisionen mit den Zwangsrefreshes möglichst zu vermeiden. Das hilft vermutlich bei glatten Frametimes relativ passabel, bei stärker springenden (mehr als 16% Frame zu Frame) nicht mehr ganz.

Der Algorithmus für FreeSync kann eigentlich ziemlich einfach ausfallen (C-ähnlicher Pseudocode für das generelle Verhalten):
Wenn neues_Frame_fertig, signalisiert dies die Engine mit einem Befehl zum Bufferflip, der folgende Routine triggert:

on_request_buffer_flip()
{
if vsync_on do while frame_transmit_running; // Bufferflips finden mit angeschaltetem vsync nur statt, wenn gerade keine Übertragung läuft (im vblank-Intervall)
// man wartet mit VSync also, bis das der Fall ist, ohne VSync geht es direkt weiter
do_buffer_flip(); // mache den Bufferflip
do while frame_transmit_running; // bei Kollision mit gerade laufendem Refresh wird gewartet
start_frame_transmit(); // starte durch Bufferflip getriggerte Frameausgabe
}

Zusätzlich gibt ein Timer ein Signal (ich nenne es mal max_refresh_intervall_reached), wenn die maximale Zeitdauer zwischen zwei Refreshes erreicht wurde, was folgende Routine auslöst:
on_max_refresh_intervall_reached()
{
start_frame_transmit();
}

Wie sieht das bei festen Refreshraten aus?
on_request_buffer_flip()
{
if vsync_on do while frame_transmit_running(); // Bufferflips finden mit angeschaltetem vsync nur statt, wenn gerade keine Übertragung läuft (im vblank-Intervall)
// man wartet mit VSync also, bis das der Fall ist, ohne VSync geht es direkt weitergeht es direkt weiter
do_buffer_flip(); // mache den Bufferflip
}

Der Timer muß natürlich immer noch ein Signal generieren, wenn (die jetzt feste) Zeitdauer zwischen zwei Refreshes erreicht wurde, was folgende Routine auslöst:
on_refresh_intervall_reached()
{
start_frame_transmit();
}

Das Rote ist der einzige Unterschied. Sieht für mich eigentlich nicht wahnsinnig kompliziert aus.
So eine einfache Lösung kappt übrigens die Framerate am oberen Ende der Range (garantiert aber schnelle Response auch unterhalb der Range), VSync wird oben durch die Hintertür wieder eingeführt. Die korrekte Behandlung davon ist etwas tricky, weswegen ich denke, daß die genau dort den Bug eingebaut haben, der es dann unten zerschießt.
Da das Panel zeilenweise neu aufgebaut wird, nicht im ganzen stimmt deine "addiere 6ms wegen LVDS-übertragung" auch nicht.Wie lange wird die Übertragung eines Frames vom GSync-Modul zum Panel wohl dauern? :rolleyes:
Und ob das zeilenweise übertragen wird oder nicht, spielt doch keine Rolle. Entscheidend ist, wie lange das dauert (und das sind eben normalerweise knappe 7ms bei einem 144Hz-Panel). Oder glaubst Du, die machen partial Refreshes?
Das wird traditionell synchron zur Refreshrate betrieben und enthält auch die klassischen Synchronisationssignale wie hblank und vblank.

[InsaneDruid]

Bei Gsync dauert der ZWangsrefresh ungefähr 50% der erwartbaren Frametime, also maximal erreichbares flüssiges feeling.

Und ja, möglich wäre es auch, die Wartezeit nicht mit ungefähr 50% Framedauer Zwangsrefreshes zu füllen, sondern mit maximal schnellen. Wobei das auch zu schnell sein kann. Wobei das nicht das schlimmste wär, schiebt man halt noch ne Runde ein. Nur ob das gut aussieht? Es gibt aber auch 48-60 Freesync Panels. Damit würde der maximal schnelle Zwangsrefresh zu lang dauern. Man will 48*2Hz haben, kann aber nur 60. Hat schon einen Grund das NV 30 als niedrigste Panelfrequenz haben will. Damit ist der maximal kurze Refresh eines 60er Panels noch ok für so einen Zwangsrefresh.

Und die siehst: es brucht eben doch Panel-Anpassung. Du kannst bei einem 60Hz IPS nicht mit 144Hz-Frametimes kommen.

[InsaneDruid]

Du hast offenbar nicht verstanden, was ich beschrieben habe. Am besten liest Du es nochmal! Natürlich wird das maximale Refreshintervall eingehalten und ein Zwangsrefresh (also ein dupliziertes Frame) eingeschoben. Aber dieser dauert eben (wie auch bei GSync) nur wenige Millisekunden. Es besteht also keine Nötigkeit, eine 25ms Zwangspause einzulegen.

Was die da bezüglich einer Treiberlösung in dem Video erzählen, vernachlässigt, daß die Display-Engine sowieso schon feststellt, daß die maximale Refreshintervall erreicht ist und dann eben den Zwangsrefresh einschiebt. Warum soll das Panel nun mindestens 25ms nach so einem Zwangsrefresh bis zum nächsten Refresh warten, auch wenn es vorher schon ein neues Frame gibt? Das ergibt nicht den geringsten Sinn.
Das korrekte Verhalten sollte also ohne Bug gerade nicht das beobachtete sein (sondern relativ ähnlich zu GSync, aber im Zweifelsfall eben ohne Frametime"vorhersage" [was im Prinzip nur bedeutet, daß man die Frametime des vorhergehenden Frames annimmt], die auch schief gehen kann). Bei 30 fps (33,3ms Frametime) sollte ein Frame die maximalen 25ms halten, dann die GPU den Zwangsrefresh einschieben (der ist nach dann insgesamt 31,9ms vorbei), dann 1,4ms vblank-Pakete einschieben, um schließlich mit Fertigwerden des neuen Frames nach exakt 33,3ms den Transfer des nächsten Bildes zu starten. Das funktioniert prinzipiell unabhängig vom genauen Panel, erfordert also auch keine Treiberanpassungen für jedes Panel. Das einzige, was GSync offenbar zusätzlich macht, ist daß wenn die Frametime eines Frames 5/6 der maximalen Frametime überschreitet, beim nächsten Frame ein Refresh (mit einem wiederholten Frame) bereits nach der Hälfte der Frametime des dann vorherigen Frames durchzuführen, um so mögliche Kollisionen mit den Zwangsrefreshes möglichst zu vermeiden. Das hilft vermutlich bei glatten Frametimes relativ passabel, bei stärker springenden (mehr als 16% Frame zu Frame) nicht mehr ganz.

Der Algorithmus für FreeSync kann eigentlich ziemlich einfach ausfallen (C-ähnlicher Pseudocode für das generelle Verhalten):
Wenn neues_Frame_fertig, signalisiert dies die Engine mit einem Befehl zum Bufferflip, der folgende Routine triggert:

on_request_buffer_flip()
{
if vsync_on do while frame_transmit_running; // Bufferflips finden mit angeschaltetem vsync nur statt, wenn gerade keine Übertragung läuft (im vblank-Intervall)
// man wartet mit VSync also, bis das der Fall ist, ohne VSync geht es direkt weiter
do_buffer_flip(); // mache den Bufferflip
do while frame_transmit_running; // bei Kollision mit gerade laufendem Refresh wird gewartet
start_frame_transmit(); // starte durch Bufferflip getriggerte Frameausgabe
}

Zusätzlich gibt ein Timer ein Signal (ich nenne es mal max_refresh_intervall_reached), wenn die maximale Zeitdauer zwischen zwei Refreshes erreicht wurde, was folgende Routine auslöst:
on_max_refresh_intervall_reached()
{
start_frame_transmit();
}

Wie sieht das bei festen Refreshraten aus?
on_request_buffer_flip()
{
if vsync_on do while frame_transmit_running(); // Bufferflips finden mit angeschaltetem vsync nur statt, wenn gerade keine Übertragung läuft (im vblank-Intervall)
// man wartet mit VSync also, bis das der Fall ist, ohne VSync geht es direkt weitergeht es direkt weiter
do_buffer_flip(); // mache den Bufferflip
}

Der Timer muß natürlich immer noch ein Signal generieren, wenn (die jetzt feste) Zeitdauer zwischen zwei Refreshes erreicht wurde, was folgende Routine auslöst:
on_refresh_intervall_reached()
{
start_frame_transmit();
}

Das Rote ist der einzige Unterschied. Sieht für mich eigentlich nicht wahnsinnig kompliziert aus.
So eine einfache Lösung kappt übrigens die Framerate am oberen Ende der Range (garantiert aber schnelle Response auch unterhalb der Range), VSync wird oben durch die Hintertür wieder eingeführt. Die korrekte Behandlung davon ist etwas tricky, weswegen ich denke, daß die genau dort den Bug eingebaut haben, der es dann unten zerschießt.
Wie lange wird die Übertragung eines Frames vom GSync-Modul zum Panel wohl dauern? :rolleyes:
Und ob das zeilenweise übertragen wird oder nicht, spielt doch keine Rolle. Entscheidend ist, wie lange das dauert (und das sind eben normalerweise knappe 7ms bei einem 144Hz-Panel). Oder glaubst Du, die machen partial Refreshes?
Das wird traditionell synchron zur Refreshrate betrieben und enthält auch die klassischen Synchronisationssignale wie hblank und vblank.

Ich bin arg müde und habs nur kurz überflogen. Du sagst zweimal do while frame_transmit_running meinst aber unterschiedliche sachen? Außerdem scheinst du immer noch davon auszugehen, dass ein Frame fertig werden kann, während ein refresh läuft?! ("bei Kollision mit gerade laufendem Refresh wird gewartet"). Bei G/Fsync wartet der Monitor mit seinem refresh auf den bufferswap, nicht der swap auf den refresh.

[Gipsel]

Bei Gsync dauert der ZWangsrefresh ungefähr 50% der erwartbaren Frametime, also maximal erreichbares flüssiges feeling.Was? Wir sollten uns vielleicht auf eine Terminologie einigen. Der Refresh (das Übertragen der Bilddaten) selber dauert etwa 1/maximale Refreshrate.
Das Prozedere von GSync bei Annäherung an das maximale Refreshintervall (Zeitdauer zwischen Refreshes) habe ich oben ausführlich beschrieben.
Und ja, möglich wäre es auch, die Wartezeit nicht mit ungefähr 50% Framedauer Zwangsrefreshes zu füllen, sondern mit maximal schnellen.Wozu das? Man macht irgendwann einen Zwangsrefresh und danach kommt wieder ein Frame potentiell variabler Länge (bis maximal zum Zwangsrefresh). Warum sollte man mit Maximalrate refreshen?
Und die siehst: es brucht eben doch Panel-Anpassung. Du kannst bei einem 60Hz IPS nicht mit 144Hz-Frametimes kommen.Die Panels melden ihren maximalen und minimalen Refresh. Danach handelt man stur mit den Timings. Was willst Du da anpassen?
Ich bin arg müde und habs nur kurz überflogen. Du sagst zweimal do while frame_transmit_running meinst aber unterschiedliche sachen?Es bewirkt zwei unterschiedliche Sachen.
Das erste stellt VSync sicher, falls aktiviert, das zweite behandelt Kollisionen mit einem eventuell bereits laufendem Refresh. Steht übrigens im Kommentar! ;)
Außerdem scheinst du immer noch davon auszugehen, dass ein Frame fertig werden kann, während ein refresh läuft?!
("bei Kollision mit gerade laufendem Refresh wird gewartet")Na klar kann das Passieren. Und zwar sowohl bei FreeSync, bei G-Sync, aber natürlich erst recht bei festen Refreshraten.
Bei G/Fsync wartet der Monitor mit seinem refresh auf den bufferswap, nicht der swap auf den refresh.Na klar tut er das. Also beides. Was passiert denn bei Frameraten über 144fps, also wenn ein neues Frame bereits nach 5ms fertig gerendert ist, die Übertragung der Bilddaten aber 6,9ms dauert? Oder wenn es eine Kollision bei einem Zwangsrefresh (der dauert ja ebenfalls so lange) gibt? Bei G-Sync wartet der Bufferswap in den Situationen immer auf den Refresh (VSync immer an, nie Tearing), bei FreeSync kann man das getrennt an oder ausknipsen (wobei es meiner Meinung nach den Bug für den Fall niedriger Frameraten gibt, an der oberen Schwelle funktioniert es dagegen). Meine Pseudocode-Version produziert dagegen ein 144 fps Cap (wie G-Sync). sichert aber schnelle Reaktion an bzw. unter der unteren Grenze mit Unterscheidung von Vsync an oder aus. Das kommt nur bei Kollision eines neuen Frames mit einem Zwangsrefresh z.B. nach 25ms zum Tragen. Ohne VSync wird während der Bildübertragung geflippt (Tearing) aber nach Beenden der laufenden Übertragung sofort das komplette Bild nochmal übertragen (das Tearing wird also so schnell wie bei 144Hz wieder "geheilt" und dürfte kaum sichtbar sein, sichert aber ein wenige Millisekunden schnellere Reaktion für diesen Fall [der einzige Grund, warum man VSync ausmachen würde]).

[fondness]

AnandTech jetzt auch noch mit einem LG Review:
http://www.anandtech.com/show/9118/lg-34um67-ultrawide-freesync-review

[robbitop]

Nein, natürlich nicht. Das Panel refresht mit den FPS. Das ist doch grade der Sinn und Zweck von G/Freesync.
Ich glaube, du hast G-Sync nicht vollständig verstanden.

[blaidd]

Ich hab bisher nichts Entsprechendes gefunden und will hier nicht die Diskussionen zuspammen, also mach ich mal einen entsprechenden Thread auf: G-sync/Freesync (http://www.forum-3dcenter.org/vbulletin/showthread.php?t=562500) Erfahrungen (so sollte das Thema eigentlich heißen, offensichtlich hab ich die Hälfte irgendwie vergessen :rolleyes:)

[InsaneDruid]

Was? Wir sollten uns vielleicht auf eine Terminologie einigen. Der Refresh (das Übertragen der Bilddaten) selber dauert etwa 1/maximale Refreshrate.
.
Ja sollten wir. Wenn ich "der Refresh" sage ist mir eine Übertragungsdauer schnurz. Ich meine das was bei einem CRT die Zeit zwischen 2 vblanks ist.


Ich glaube, du hast G-Sync nicht vollständig verstanden.
Dann lass dein Wissen herabregnen.
Was macht deines Wissens G/FSync anderes, als den Refresh des Panels bis zum nächsten Frame (der Graka) zu verzögern?

[Gipsel]

Ja sollten wir. Wenn ich "der Refresh" sage ist mir eine Übertragungsdauer schnurz. Ich meine das was bei einem CRT die Zeit zwischen 2 vblanks ist.Bei den variablen Frameraten gibt es eben keine so genau definierte "Zeit zwischen zwei vblanks", genau die Dauer des vblank-Signals ist variabel. Zwischen dem Ende von vblank bis zum Anfang des nächsten liegt immer die Zeit, die die Übertragung eines Frames dauert, bei einem 144Hz-Display also etwa 6,9ms ;).
Vblank liegt dann für eine variable Dauer zwischen praktisch Null und mehr als 18ms (bei 40Hz Minimalrefresh) an, dies kann jederzeit (z.B. wenn ein neues Frame fertig wurde) abgebrochen und mit der nächsten Frameübertragung angefangen werden. So funktioniert das.
Und deswegen muß man zwischen Refreshintervall (Zeitdauer zwischen zwei Refreshs bzw. zwischen zwei Übertragungen eines Frames) und Refreshdauer (Dauer der Übertragung eines Frames) unterscheiden, sonst kapiert man nicht, worum es geht.
Dann lass dein Wissen herabregnen.
Was macht deines Wissens G/FSync anderes, als den Refresh des Panels bis zum nächsten Frame (der Graka) zu verzögern?
Das ist schon Alles beschrieben worden, Du mußt es nur noch verstehen, insbesondere was passiert, wenn ein neues Frame der Grafikkarte mit der Übertragung des vorhergehenden (egal ob es ein wiederholtes ist [unter dem variablen Bereich] oder nicht [oberhalb von 144Hz]) ;).

[crux2005]

Wie sieht es jetzt eigentlich mit A-sync aus? Man liest ja nur von G/Free-sync. Gibt es schon Berichte/Erfahrungen oder muss man noch warten?

[aufkrawall]

A-Sync ist ja FS, nur ohne "Zertifikat" von AMD. Da Acer und Co mit den letzten FS-Monitoren ziemlichen Mist gebaut haben, sieht das auch eher nach einem PR-Stunt aus.
Der kommende Asus 144Hz IPS wird "nur" A-Sync sein, dann wird man sehen.

[Kartenlehrling]

Das ist doch Blödsinn jetzt auf der Limiterung rumzureiten.

@blaidd schreibt es in seinem Thread auch,
eigentlich will man doch überhaupt nicht mehr mit 20-50fps spielen wenn man einmal einen Monitor mit >60Hz geteste hat.
Und für Shooter, Rennsimualtion und RTS werden doch 80-144fps angestrebt, für Solo RPGs in 3rd Person reichen auch 50-80fps.
Selbst der 21:9 LG (48-75Hz) bedient in diesem Sinn das Gewünschte.

[dildo4u]

In 4K biste schnell unter 40 selbst mit einer Titan X,und massig Leute spielen sogar mit 30 auf Konsole.SP Game's wie Watch Dogs zocke ich gerne mit DSR und fps um 40,gerade am PC bringt eine hohe Auflösung ne Menge,weil man direkt davor sitzt.

[Schaffe89]

Also das mit den 40 als Limit sehe ich bisher überhaupt nicht als Problem, da wenn ich überhapt schon einen 144 oder 120 Hertzmonitor haben will, schon das ganze Paket will.

Hohe FPS + Freesync.
Slebst in 4K schafft meine TitanX durchaus 60 FPs + , ich hoffe mal Nvidia unterstützt alsblad Freesync, ansonsten steige ich dann auf ne r9 390x um.

[horn 12]

Werden wohl nicht nur du, lieber Schaffe89 umsteigen!
Aber warum eben die Titan X geholt, und nicht diese 1,5 Monate noch auf R9 390X gewartet.
Die Speicherbandbreite wird jener Karte extrem weiterhelfen für 4K.

[dargo]

In 4K biste schnell unter 40 selbst mit einer Titan X,und massig Leute spielen sogar mit 30 auf Konsole.SP Game's wie Watch Dogs zocke ich gerne mit DSR und fps um 40,gerade am PC bringt eine hohe Auflösung ne Menge,weil man direkt davor sitzt.
Ja... und in 8k biste unter 10fps. :rolleyes: Und was genau soll dieses bekloppte Beispiel mit der Konsole? Die Frameraten die dort teilweise erreicht werden sind eh für schmerzfreie Spieler, das ist nicht unbedingt ein Maßstab für andere.

[Red_Bull]

Eine frage zum ASUS MG279Q

hat den jemand von euch schon bestellt?
ist seit kurzem lieferbar.
http://geizhals.de/asus-mg279q-90lm0103-b01170-a1215454.html

Nochmal als verständnissfrage wenn ich zb 80fps ohne tearing und sonstige ruckler will
schalte ich einfach freesync an vsync aus und setze ein frame limit mit einem tool auf 80?

geht das so oder habe ich einen denkfehler gemacht?

[dargo]

Nochmal als verständnissfrage wenn ich zb 80fps ohne tearing und sonstige ruckler will
schalte ich einfach freesync an vsync aus und setze ein frame limit mit einem tool auf 80?

geht das so oder habe ich einen denkfehler gemacht?
Jup.

Wenn der Bildschirm max. 80Hz kann ist man sich afaik noch nicht ganz sicher (oder ich habs nicht richtig verstanden) was genau passiert. Also ob Vsync Off oder On, wobei man das im Treiber bei AMD einstellen kann. Dennoch ist beides ein Nachteil zu Freesync. Ergo kannst du auch zur Sicherheit ein Framelimit von 79fps bei 80Hz setzen.

PS: beim ASUS MG279Q kannst du natürlich auch 80fps setzen, der geht ja bis 144Hz.

[Unicous]

Der Asus ist nicht lieferbar, lediglich gelistet. Es wird wohl noch ein paar Wochen dauern (laut Asus) bis er im Handel erhältlich ist.

[Gipsel]

Nochmal als verständnissfrage wenn ich zb 80fps ohne tearing und sonstige ruckler will
schalte ich einfach freesync an vsync aus und setze ein frame limit mit einem tool auf 80?

geht das so oder habe ich einen denkfehler gemacht?Solange Du im Bereich der variablen Refreshrate bleibst, ist es völlig egal, auf was Du VSync stellst. Das ändert nur das Verhalten außerhalb des variablen Bereichs.
Eigentlich sollte es auch ohne Framelimiter und VSync an (praktisch ein Framelimit bei maximaler Refreshrate) sehr gut laufen, solange Du immer oberhalb der minimalen Refreshrate bleibst. Was außer vielleicht ein wenig Stromersparnis bringt in dem Fall denn ein Limit bei 80fps?

[EPIC_FAIL]

Wie ist das denn bei den aktuellen Implementierungen von G/F-Sync, kann man dort sagen, wenn der Bereich verlassen wird, wo G/F-Sync funktioniert (für diesen Monitor), soll mit V-Sync on ODER V-Sync off gearbeitet werden? Oder wird V-Sync on zwangsläufig verwendet?

[Gipsel]

Wie ist das denn bei den aktuellen Implementierungen von G/F-Sync, kann man dort sagen, wenn der Bereich verlassen wird, wo G/F-Sync funktioniert (für diesen Monitor), soll mit V-Sync on ODER V-Sync off gearbeitet werden? Oder wird V-Sync on zwangsläufig verwendet?Bei G-Sync ist VSync immer an, bei FreeSync kann man es wählen (also ob VSync an oder aus außerhalb des Bereiches), es funktioniert aber nur oberhalb des maximalen Refreshes wie es soll, unterhalb des minimalen Refreshes geht es im Moment nicht richtig (meiner Meinung nach ein Bug, der hoffentlich mit einem zukünftigen Treiber behoben wird).

[Grestorn]

Wie ist das denn bei den aktuellen Implementierungen von G/F-Sync, kann man dort sagen, wenn der Bereich verlassen wird, wo G/F-Sync funktioniert (für diesen Monitor), soll mit V-Sync on ODER V-Sync off gearbeitet werden? Oder wird V-Sync on zwangsläufig verwendet?

Bei Freesync kann man steuern, ob im Bereich außerhalb des Refresh-Bereichs des Panels dann VSync aktiv sein soll oder nicht.

Wenn es aktiv ist, ist die Framerate sowohl nach unten (derzeit, siehe Gipsels Posting) als auch nach oben dann genau auf die Möglichkeiten des Panels limitiert, wie es auch ohne Freesync der Fall ist. Bei der unteren Grenze ist das aber schmerzhaft, da VSync mit z.B. 40 fps echt Mist ist.

Wenn VSync aus ist, dann bekommt man in beiden Fällen Tearing.


Bei GSync kann man das nicht steuern, da ist VSync immer an. Bei Überschreiten der oberen Grenze hat man damit alle VSync Nachteile. Eine untere Grenze gibt es bei GSync de fakto aber dank der Methodik ggf. zusätzliche Frames einzufügen nicht. D.h. GSync kann verlustfrei bis 1 fps Tearing- und Lagfrei nach unten skalieren.

[fondness]

Damit sind auch die 144Hz für den ASUS bestätigt:

http://s18.postimg.org/vg3gh6qg9/asus_mg279_Qtweet_1.jpg (http://postimage.org/)

[M4xw0lf]

Damit sind auch die 144Hz für den ASUS bestätigt:

http://s18.postimg.org/vg3gh6qg9/asus_mg279_Qtweet_1.jpg (http://postimage.org/)
Uninteressant, gib 30Hz lower limit.

[Kartenlehrling]

Freesync+VsyncOFF macht nur Sinn bei Spielen die über 144fps gehen.
Und in den anderen Fällen würde Ich Vsync immer ON haben bzw. sogar noch ein FPS-Limiter aktivieren.

[Unicous]

Uninteressant, gib 30Hz lower limit.

btw. 30Hz limit

Beim Asus ROG liegt wohl die VRR-Grenze eher bei 36 Hz, also hat Nvidia/Asus da gemogelt, man merkt es nur nicht weil G-Sync ab/unter 36Hz ein weiteres frame einschiebt.

Beim BenQ scheint die Grenze u.U. wohl auch geringfügig niedriger bei afair 38 Hz zu liegen.

Quelle: PCPer Video (https://www.youtube.com/watch?v=VkrJU5d2RfA)

Man kann sich also auf niemanden verlassen, echt zum Heulen.

[Grestorn]

Freesync+VsyncOFF macht nur Sinn bei Spielen die über 144fps gehen.
Und in den anderen Fällen würde Ich Vsync immer ON haben bzw. sogar noch ein FPS-Limiter aktivieren.

Beim aktuellen Treiber würde ich VSync insbesondere dann ausschalten, wenn man bei einem Spiel auch schon mal die untere Grenze unterschreitet. Lieber hab ich mal nen Riss im Bild als zusätzlichen Lag und Ruckeln zusätzlich zu dem, was die niedrige Framerate eh schon verursacht.

btw. 30Hz limit

Beim Asus ROG liegt wohl die VRR-Grenze eher bei 36 Hz, also hat Nvidia/Asus da gemogelt, man merkt es nur nicht weil G-Sync ab/unter 36Hz ein weiteres frame einschiebt.

Ich wüsste gar nicht, dass eine untere Grenze offiziell spezifiziert wurde. De Fakto gibt es auch keine untere Grenze bei GSync, da das Einschieben ja keinen Nachteil hat und damit die Framerate frei nach unten fließen kann.

[Gipsel]

De Fakto gibt es auch keine untere Grenze bei GSync, da das Einschieben ja keinen Nachteil hat und damit die Framerate frei nach unten fließen kann.Natürlich gibt es die, man versucht nur, diese nicht hart zu treffen, in dem man bereits 20% oberhalb der Grenze anfängt, einen vorzeitigen Zwangsrefresh einzuschieben. Das geht aber natürlich erst beim nächsten Frame als Reaktion auf die Frametime des vorherigen. Bei schwankenden Frametimes trifft auch GSync die untere Grenze.
Das Problem mit den Blackouts der frühen GSync-Monitore war übrigens auch ein Bug beim Überschreiten der maximalen Dauer zwischen zwei Refreshes, das GSync-Modul hat dann schlicht keinen Zwangsrefresh ans Panel geschickt.

[Grestorn]

Das maximale Delay bis ein neues Frame angezeigt werden kann, ist immer max. 7ms (bei einem 144Hz Monitor), hauptsächlich limitiert durch die Bandbreite von DP und der internen Scaler-Logik. Unterhalb wie oberhalb der unteren Grenze des Panels. Deswegen existiert diese de Fakto nicht.

Der "Bug" war wohl in den ersten Nachrüst-Modulen vorhanden, aber in keinem kaufbaren Monitor. Also ein Prototyp-Problem.

[Kriton]

Ich wüsste gar nicht, dass eine untere Grenze offiziell spezifiziert wurde. De Fakto gibt es auch keine untere Grenze bei GSync, da das Einschieben ja keinen Nachteil hat und damit die Framerate frei nach unten fließen kann.

Nvidia spricht doch selbst von 30 Hz (unten in der Tabelle):

http://www.nvidia.de/object/how-does-g-sync-work-de.html

[dargo]

Was außer vielleicht ein wenig Stromersparnis bringt in dem Fall denn ein Limit bei 80fps?
Ein auf gleichem Niveau bleibender Input-Lag.

[Grestorn]

Nvidia spricht doch selbst von 30 Hz (unten in der Tabelle):

http://www.nvidia.de/object/how-does-g-sync-work-de.html

Das ist scheinbar veraltet! "Nach der Modifizierung mit dem G-SYNC-Selbstbau-Kit" steht in der Tabelle als Überschrift. Die Nachrüstmodule können das dynamische Einfügen von zusätzlichen Frames offenbar nicht, zumindest nach dem was man lesen kann.

[Unicous]

Natürlich wurde die kommuniziert. Von Nvidia höchstpersönlich. Das war vor einem Jahr.

z.B. hier

http://www.pcper.com/reviews/Graphics-Cards/NVIDIA-G-Sync-DIY-Upgrade-Kit-Installation-and-Performance-Review/Impressions

Seitdem spukt durch die gesamte Forenlandschaft, als auch Fachwelt die 30Hz
Grenze. Dass das Blödsinn ist hätte ja mal auffallen können, aber es wurde nie nachgeprüft oder gar korrigiert. Man gibt einfach nicht die untere Grenze für das Panel an.

[aufkrawall]

Eigentlich sollte es auch ohne Framelimiter und VSync an (praktisch ein Framelimit bei maximaler Refreshrate) sehr gut laufen, solange Du immer oberhalb der minimalen Refreshrate bleibst. Was außer vielleicht ein wenig Stromersparnis bringt in dem Fall denn ein Limit bei 80fps?
Eine Garantie, nie unnötigen Input Lag zu haben? Auch DB-Vsync nervt.
Außerdem neigen einige Engines zu geringerem Input Lag mit fps-Limit. Mit dem Frostbite-internen fühlen sich 80fps gelockt direkter an als 100 ungelockt. Bei 75Hz, eine höhere Refreshrate würde natürlich stärker von der höheren Bildrate profitieren.

[Kriton]

Etwas OT, aber kann mir einer sagen warum der Lock einen frame unterhalb der max. Hz gelegt wird? warum nicht auf 120 fps limitieren bei einem 120 Hz Monitor?

[Gipsel]

Das maximale Delay bis ein neues Frame angezeigt werden kann, ist immer max. 7ms (bei einem 144Hz Monitor), hauptsächlich limitiert durch die Bandbreite von DP und der internen Scaler-Logik. Unterhalb wie oberhalb der unteren Grenze des Panels. Deswegen existiert diese de Fakto nicht.Das minimale Delay ist knapp 7ms, das maximale Intervall zwischen zwei Refreshes ist bei den Monitoren mit 30Hz minimaler Refreshrate 33ms. Und diese Grenze existiert. Anders geht es gar nicht. Auch das GSync-Modul kann nicht in die Zukunft schauen.
Frage Dich doch einfach, was passiert, wenn der Monitor (das GSync-Modul) länger als die (gemessenen) 5/6 der maximalen Dauer zwischen zwei Refreshes von 33,3ms (also ~27,8ms = 1/36 fps) kein neues Frame schickt. Sofort einen neuen Refresh starten und riskieren, daß das neue Frame dann mit diesem kollidiert? Das müßte dann verzögert dargestellt werden und würde VSync-Judder bedeuten. Oder einfach warten und hoffen, daß das neue Frame noch in der Zeit bis zum maximalen Refreshintervall kommt (der dann nach spätestens 1/30 Sekunde kommen muß, damit es nicht zu Blackouts kommt, wie noch bei den ersten GSync-Modellen, die den vergessen haben)? Die zweite Möglichkeit ist die bessere, solange die Frametimes relativ glatt aussehen. Es verringert die Wahrscheinlichkeit einer Kollision zwischen einem eingeschobenem Refresh (wiederholter Frame) mit der Übertragung eines neuen Frames. Benötigte das vorhergehende Frame eine Zeit t länger als 1/36 Sekunde, wird im darauffolgenden Frame ein Zwangsrefresh bereits nach 0,5*t ausgeführt. Dieses Vorgehen verhindert Kollisionen nicht, es macht sie nur unwahrscheinlicher.

=====================

Eine Garantie, nie unnötigen Input Lag zu haben? Auch DB-Vsync nervt.Den hast Du bei G-/FreeSync prinzipbedingt nicht, solange Du innerhalb der variablen Refreshrate bleibst. Da beträgt der "Vsync-Lag" genau 0.
Eine Framelimiter exakt auf (konstanter) Refreshrate bringt nicht viel (das Lag springt eventuell seltener [eventuell aber auch ungünstiger], weg sollte es nicht sein). Alles oberhalb oder unterhalb davon ergibt Judder. Ich habe die Tipps mit 59fps Limit mit 60Hz vsynced Refresh noch nie verstanden. Das ergibt genau einmal pro Sekunde einen fetten Judder-Hakler und das Input-Lag verändert sich mit einem Sägezahnmuster mit einer Frequenz von einem Hertz. Das ist ziemlicher Schrott in meinen Augen, auch wenn Einige darauf zu schwören scheinen. Aber einige Leute sehen ja auch Tearing oder ungleiche Frametimes nicht, hier ist es vermutlich ähnlich. Was einer als angenehm empfindet, stört den zweiten.
Bei einem 144Hz Monitor und Frameraten oberhalb davon macht ein Limiter meiner Meinung nach auch kaum noch Sinn. Erreicht das Spiel sagen wir mal 200 fps ohne VSync, beträgt der Lag durch VSync gerade mal 1,9 ms. Ich bezweifle, daß das ein signifikanter Prozentsatz der Leute merkt. Außerdem ist das mit VSync konstant und vorhersagbar (die Zeitdauer vom Anfang des Renderns des Frames bis zur Anzeige am Monitor ist konstant, wenn die fps dauerhaft an der Refreshrate des Monitors kleben), also nach diesen Kriterien für den Spieler recht angenehm (kein Judder mit variabler Zeit zwischen Renderbeginn eines Frames und Anzeige wie bei fps unter Refreshrate und VSync).
Bei einem G-/FreeSync-Monitor, der bis 144Hz geht, spricht meiner Meinung nach nicht viel für einen Limiter (außer, wenn man den Stromverbrauch reduzieren will). Unterhalb von 144Hz gibt es kein VSync-Lag, oberhalb ist er minimal und sozusagen "gutartig".
Außerdem neigen einige Engines zu geringerem Input Lag mit fps-Limit. Mit dem Frostbite-internen fühlen sich 80fps gelockt direkter an als 100 ungelockt. Bei 75Hz, eine höhere Refreshrate würde natürlich stärker von der höheren Bildrate profitieren.Was ich glauben kann, ist daß einige Engines die vom Refresh abgekoppelten Updates der Spielwelt nicht optimal handhaben (ist zugegebenermaßen auch nicht immer einfach), was den Eindruck eines Lags oder eines unrunden Spielgefühls verursachen kann. Aber ob da Framelimiter die optimale Lösung sind, wage ich noch zu bezweifeln.

[Grestorn]

Das minimale Delay ist knapp 7ms, das maximale Intervall zwischen zwei Refreshes ist bei den Monitoren mit 30Hz minimaler Refreshrate 33ms. Und diese Grenze existiert. Anders geht es gar nicht. Auch das GSync-Modul kann nicht in die Zukunft schauen.
Ich rede von dem zusätzlichen Delay, das durch die Verdopplung entsteht, von dem Zeitpunkt in dem das Frame fertig gerendert ist, bis es tatsächlich sichtbar ist.

Ein solches Delay gibt es immer (DP Bandbreite, Scaler-Logik). Dadurch, dass aber das neue Frame gerade in einem ungünstigen Zeitpunkt bereitsteht und das mit einer gerade erfolgten erneuten Einschub des letzten Frames kollidieren kann, kann eben bis zu 7ms zusätzlich vergehen.

Frage Dich doch einfach, was passiert, wenn der Monitor (das GSync-Modul) länger als die (gemessenen) 5/6 der maximalen Dauer zwischen zwei Refreshes von 33,3ms (also ~27,8ms = 1/36 fps) kein neues Frame schickt. Sofort einen neuen Refresh starten und riskieren, daß das neue Frame dann mit diesem kollidiert?`
Genau das, etwas anderes bleibt dem Modul ja nicht, da sonst das Panel das alte Frame nicht mehr halten könnte.

Im schlimmsten Falle schickt das Modul das alte Frame gerade in dem Moment an das Panel wie das neue bereit steht. In genau diesem Falle kommt es zu einer maximalen zusätzlichen Verzögerung von 7 ms (die Übertragung des alten Frames + die Übertragung des neuen. Beides dauert max. 7ms, aber die Übertragung des neuen Frames hätte eh passieren müssen, ist also kein zusätzliches Delay).

Judder gibt es nicht (abgesehen von dem 7ms Delay), da das erneut gesendete Frame ja inhaltlich mit dem Originalframe identisch ist, also kein neues Frame im Sinne der Optik darstellt. Es bleibt eben nur ein maximales Delay von 7ms im schlimmsten Fall. Das Judder dürfte aber kaum je auffallen, zumal der Fall, dass es wirklich die vollen 7 ms sind, ja nur der absolut ungünstigste Fall ist, der in der Praxis eher selten eintreffen sollte.

[Gipsel]

Ich rede von dem zusätzlichen Delay, das durch die Verdopplung entsteht, von dem Zeitpunkt in dem das Frame fertig gerendert ist, bis es tatsächlich sichtbar ist.Das entsteht wie erklärt nur bei Kollisionen eines Zwangsrefreshes mit einem neuen Frame. Das kann bei GSync nicht ausgeschlossen werden, man versucht nur, die Wahrscheinlichkeit zu verkleinern.
Genauso muß auch GSync sicherstellen, daß die untere Refreshgrenze (das maximale Refreshintervall) nicht verletzt wird. Diese Grenze existiert. Man versucht hier aber durch die geschilderten Maßnahmen, diese wenn möglich nicht hart zu treffen. Das funktioniert aber nicht immer. Das kann es gar nicht.

Du hast vom Delay angefangen zu erzählen, als wir bei der unteren Grenze der Refreshrate waren. Nach Deiner Argumentation hat (etwas zugespitzt) ein 144Hz Monitor mit VSync auch keine Probleme mit beliebig niedrigen Frameraten, da ja das maximale Delay zur Anzeige eines neuen Frames auch nur 7ms beträgt. Ich rede von den Grenzen, in denen es ohne jegliches Delay funktioniert ;).
Genau das, etwas anderes bleibt dem Modul ja nicht, da sonst das Panel das alte Frame nicht mehr halten könnte.Doch, es kann es dann noch etwas länger halten (bis 33,3ms um sind, wir waren ja erst bei 5/6 dieser Dauer). Die zweite Variante ist wie gesagt die bessere und die wird wohl auch benutzt.
Im schlimmsten Falle schickt das Modul das alte Frame gerade in dem Moment an das Panel wie das neue bereit steht. In genau diesem Falle kommt es zu einer maximalen zusätzlichen Verzögerung von 7 ms (die Übertragung des alten Frames + die Übertragung des neuen. Beides dauert max. 7ms, aber die Übertragung des neuen Frames hätte eh passieren müssen, ist also kein zusätzliches Delay).Die Funktionsweise mit den Kollisionen habe ich schon vor ein paar Seiten hier im Thread erklärt. ;)
Judder gibt es nicht (abgesehen von dem 7ms Delay), da das erneut gesendete Frame ja inhaltlich mit dem Originalframe identisch ist, also kein neues Frame im Sinne der Optik darstellt.Bei einer Kollision des neuen Frames mit einem Zwangsrefresh gibt es sehr wohl Judder, da das neue Frame verzögert dargestellt wird, das nächste Frame aber höchstwahrscheinlich nicht mehr.
Es bleibt eben nur ein maximales Delay von 7ms im schlimmsten Fall.Ja, Judder bei (hoffentlich seltenen) Kollisionen mit dem Zwangsrefresh, wie ich schon sagte.

[Grestorn]

Ja, Judder bei (hoffentlich seltenen) Kollisionen mit dem Zwangsrefresh, wie ich schon sagte.

Du sprichst immer von einem Delay von 33ms. Das ist aber Quatsch. Das Delay ist maximal (und das sehr selten) 7ms. Und ein seltenes, einmaliges Judder von 7ms (das ich schon vor Seiten beschrieben und eingeräumt habe) ist mit nahezu 100% Sicherheit weder sichtbar noch relevant.

[Gipsel]

Du sprichst immer von einem Delay von 33ms. Das ist aber Quatsch.Ich habe nie von einem Delay von 33ms gesprochen (ich habe noch nicht mal den Begriff in dem Zusammenhang benutzt). Du hast wie gesagt mit dem Begriff Delay angefangen, als es um die untere Grenze des variablen Refreshratenbereiches ging.
Ich habe mich immer um eine konsequent angewandte Terminologie bemüht, siehe den vorhergehenden Seiten.
Das Delay ist maximal (und das sehr selten) 7ms. Und ein seltenes, einmaliges Judder von 7ms (das ich schon vor Seiten beschrieben und eingeräumt habe) ist mit nahezu 100% Sicherheit weder sichtbar noch relevant.Wenn Du ein 7ms Delay nicht siehst, ist Alles was Du benötigst, wie schon gesagt ein 144Hz Monitor ;). Und bei Deiner Beschreibung vor ein paar Tagen hattest Du mögliche Kollisionen mit einem Retransmit/Zwangsrefresh vergessen.
Aber im Prinzip sind wir uns ja fast einig. Ich stimme Dir lediglich nicht zu, daß GSync effektiv keine untere Grenze des Refreshratenbereiches zeigt, weil die maximale Verzögerung zur Anzeige eines neuen Frames 7ms beträgt, wie von Dir formuliert. Dies ist auch bei einem normalen 144Hz-Monitor der Fall (weswegen ich vermutlich Deinen Widerspruch gegen die untere Grenze von GSync zuerst etwas falsch verstanden habe). GSync hat sehr wohl eine Grenze für das maximale Refreshintervall. Bei gleichmäßig bzw. glatt verlaufenden Frametimes trifft man diese Grenze bloß nicht hart, weil nV versucht, clever zu sein (eine Beschreibung des Vorgehens kann man im Thread finden).

[Grestorn]

Ich habe nie von einem Delay von 33ms gesprochen (ich habe noch nicht mal den Begriff in dem Zusammenhang benutzt). Du hast wie gesagt mit dem Begriff Delay angefangen, als es um die untere Grenze des variablen Refreshratenbereiches ging.

In dem Beitrag http://www.forum-3dcenter.org/vbulletin/showthread.php?p=10582596#post10582596 hast Du mein Quote offenbar überhaupt nicht verstanden. Sonst wärst Du da nicht mit Deinen 33ms angekommen.

Und ich hab auch keine Lust mehr mit Dir zu diskutieren, da es Dir ganz offensichtlich gar nicht um die Technik geht, Du hast ganz andere Intentionen. Du bist insgesamt einer der unangenehmsten Diskussionspartner, die ich hier im Forum kennengelernt habe. EOD.

[Gipsel]

In dem Beitrag http://www.forum-3dcenter.org/vbulletin/showthread.php?p=10582596#post10582596 hast Du mein Quote offenbar überhaupt nicht verstanden. Sonst wärst Du da nicht mit Deinen 33ms angekommen.Ich komme da aber nicht mit einem 33ms Delay, sondern mit 33ms als maximalem Intervall zwischen zwei Refreshes als Grenze. Eine Grenze, deren Existenz Du in Deinem vorherigen Post bestritten hast (der Kontext (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=10582498#post10582498)). Es ging doch zu dem Zeitpunkt gar nicht um Verzögerungen bei der Darstellung eines Frames aufgrund von Kollisionen mit Zwangsrefreshes. Deswegen habe ich Deine Antwort (wie bereits oben geschrieben) tatsächlich etwas in den falschen Hals bekommen, da mir nicht bewußt war, daß Du mit dem für diesen Punkt relativ irrelevanten Dauer der Übertragung eines Frames ankommst. Zumal Dein Argument für alle Monitore mit 144Hz Refresh zieht, es somit nicht spezifisch für GSync und dessen Verhalten bei Annäherung an das untere Refreshratenlimit ist.
Und ich hab auch keine Lust mehr mit Dir zu diskutieren, da es Dir ganz offensichtlich gar nicht um die Technik geht, Du hast ganz andere Intentionen.Dummerweise bin ich einer derjenigen im Thread, die die Funktionsweise und die technischen Hintergründe öfter mal erklärt haben. Wenn es Dir unangenehm ist, auch mal Widerspruch zu finden, tut mir das leid.

[aufkrawall]

Den hast Du bei G-/FreeSync prinzipbedingt nicht, solange Du innerhalb der variablen Refreshrate bleibst.

Mit 4k ist derzeit 60Hz die Obergrenze, an die stößt man je nach Spiel recht schnell. Erst recht, wenn sie (bzw. 59fps) das Ziel sind, etwa für MP-Spiele.


Eine Framelimiter exakt auf (konstanter) Refreshrate bringt nicht viel (das Lag springt eventuell seltener [eventuell aber auch ungünstiger], weg sollte es nicht sein). Alles oberhalb oder unterhalb davon ergibt Judder. Ich habe die Tipps mit 59fps Limit mit 60Hz vsynced Refresh noch nie verstanden. Das ergibt genau einmal pro Sekunde einen fetten Judder-Hakler und das Input-Lag verändert sich mit einem Sägezahnmuster mit einer Frequenz von einem Hertz. Das ist ziemlicher Schrott in meinen Augen, auch wenn Einige darauf zu schwören scheinen. Aber einige Leute sehen ja auch Tearing oder ungleiche Frametimes nicht, hier ist es vermutlich ähnlich. Was einer als angenehm empfindet, stört den zweiten.

Ich meinte das nur auf A-Sync bezogen. repeated frames (mit festem Refreshintervall) sind mir ein Dorn im Auge (wortwörtlich).


Bei einem 144Hz Monitor und Frameraten oberhalb davon macht ein Limiter meiner Meinung nach auch kaum noch Sinn. Erreicht das Spiel sagen wir mal 200 fps ohne VSync, beträgt der Lag durch VSync gerade mal 1,9 ms. Ich bezweifle, daß das ein signifikanter Prozentsatz der Leute merkt.

In der Praxis kann es aber offenbar doch zu deutlich erhöhtem Lag kommen auch mit 144Hz, siehe CS:GO mit Gsync:
http://www.blurbusters.com/gsync/preview2/
Ich kann mangels Gsync nicht überprüfen, ob es nicht etwas wie ein Treiber-Bug war.
Womöglich hätte aber auch da ein niedrigeres (~140fps) fps-Limit geholfen.

Wie sieht das eigentlich mit den Gsync-Modul aus: Werden die aktualisiert, oder sind je nach Monitor und dessen Revision mitunter unterschiedliche Versionen verbaut?
Laut Aussagen Grestorns flackert der Asus ROG überhaupt nicht, so lange überhaupt refresht wird.
Mich würde interessieren, ob das ausnahmslos auf alle Gsync-Monitore zutrifft. Und ob 60Hz-Panels bei niedrigen fps (mit Bild-Vorhaltung und Verfielfachung der Refreshrate) ebenfalls genau so smooth laufen.

[Grestorn]

Ich komme da aber nicht mit einem 33ms Delay, sondern mit 33ms als maximalem Intervall zwischen zwei Refreshes als Grenze. Eine Grenze, deren Existenz Du in Deinem vorherigen Post bestritten hast (der Kontext (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=10582498#post10582498)).

Hab ich nicht. Du hast nur nicht verstanden, was ich meinte. Was natürlich auch daran liegen kann, dass ich mich vielleicht nicht für jedermann klar genug ausgedrückt habe.

Aber jetzt wirklich EOD. Ich kann gar nicht in Worte fassen, wie mich das hier gerade nervt.

[Raspo]

Weil? Versuche es doch mal in Worte zu fassen.

[Unicous]

Er kommt einfach nicht auf Widerworte klar.

[Grestorn]

Ich komme nicht mit falschen und absurden Anschuldigungen klar. Ich werde doch wohl selbst am besten wissen, was ich meine und über was ich schreibe.

Wenn ich etwas nicht vertrage, dann dass mich Leute, die mich gar nicht kennen, für dämlich halten.

Gipsel hat sich in seiner Argumentation verrannt, und der einzige Weg für ihn sein Gesicht zu wahren, ist mir zu unterstellen, ich hätte Dinge gesagt, die ich so einfach nie geschrieben und noch weniger gemeint habe.

[Dimitri Mayakovsky]

Unabhängig vom konkreten Delay, solange FreeSync nicht in der Lage ist auch mit Frameraten unterhalb der minimal notwendigen Refreshrate des Panels umzugehen, ist die Technik schlicht nicht gleichwertig zu G-Sync. Ganz einfach.

Dass es einfach nur ein Bug ist, halte ich für ziemlich unwahrscheinlich. So ein massiver Fehler, bei der Haupfunktionalität? Das soll keiner vorher getestet haben?

Zumindest wissen wir jetzt, dass G-Sync eben doch deutlich mehr ist, als uns AMD das immer verkaufen wollte.

[fondness]

Das AMD nicht die Vorzüge von G-Sync verkauft sollte klar sein, mich wundert eher das NV das nicht offensiver erwähnt hat. Zumindest an mir ist das völlig vorbei gegangen. Aber kann natürlich auch sein das man dieses Feature bewusst geheim gehalten hat um dann noch eine Trumpfkarte zu haben wenn AMD kommt.

[Grestorn]

Das AMD nicht die Vorzüge von G-Sync verkauft sollte klar sein, mich wundert eher das NV das nicht offensiver erwähnt hat. Zumindest an mir ist das völlig vorbei gegangen. Aber kann natürlich auch sein das man dieses Feature bewusst geheim gehalten hat um dann noch eine Trumpfkarte zu haben wenn AMD kommt.

Ich glaube nicht an einen "Trumpf" für nVidia. Zumindest kann ich keinen Grund sehen, warum AMD das Verhalten von GSync im Low-FPS Bereich nicht per Treiber nachbilden können sollte. Was auch ein Grund für nVidia wäre, jetzt nicht den hämischen "wir wussten schon immer, dass wir besser sind" raushängen zu lassen.

[Dimitri Mayakovsky]

Besser konnte man AMD ja nicht vorführen. Und deren Marketingtricks waren ja auch schon hart an der Grenze, ich erinnere mich da nur an die Folie mit einem behaupteten Framerate-Spektrum von "9-200Hz" für FreeSync, obwohl das nur in Abstufungen möglich ist, also 9-60, 12-75 usw.

Und du, fondness, wärst doch der Erste gewesen, der NVIDIA unterstellt hätte zu lügen, wenn sie diesen Vorzug prominent präsentiert hätten.

So haben wir es jetzt Schwarz auf Weiß, von unabhängiger Stelle.

Ich glaube nicht an einen "Trumpf" für nVidia. Zumindest kann ich keinen Grund sehen, warum AMD das Verhalten von GSync im Low-FPS Bereich nicht per Treiber nachbilden können sollte.
Weil es z.B. die Hardware nicht hergibt.

NVIDIA hat ja von Anfang an gesagt, dass sie mit dem G-Sync Modul das Master->Slave Verhalten zwischen Monitor und GPU ändern konnten. Das manifestiert sich nun in diesem Unterschied.

[fondness]

Besser konnte man AMD ja nicht vorführen. Und deren Marketingtricks waren ja auch schon hart an der Grenze, ich erinnere mich da nur an die Folie mit einem behaupteten Framerate-Spektrum von "9-200Hz" für FreeSync, obwohl das nur in Abstufungen möglich ist, also 9-60, 12-75 usw.

Also das mit den 9-200Hz nur die FreeSync-Technik an sich und nicht die Monitor-Refresh gemeint war ist und war nun wirklich offensichtlich. Es gibt und gab keinen Monitor der auch nur annähernd eine solche Refreshrate supportet. Ansonsten haben viele so getan als wäre diese Technik ohne dem teuren Modul im Monitor bei G-Sync gar nicht möglich, das wurde klar widerlegt. Das Verhalten bei niedrigen Refresh-Raten wird womöglich auch noch im Treiber nachgebildet, was bleibt dann noch für G-Sync? Für mich ist es ja nach wie vor ein viel zu großer Nachteil das man mit G-Sync nur einen einzige DP-Anschluss am Monitor verbauen kann und sonst nichts, aber okay manchen ist das wohl nicht so wichtig.


Und du, fondness, wärst doch der Erste gewesen, der NVIDIA unterstellt hätte zu lügen, wenn sie diesen Vorzug prominent präsentiert hätten.


Na klar und mal schnell irgend eine Unterstellung unterbringen, das fördert das Diskussionsklima. :rolleyes:

[Troyan]

Das AMD nicht die Vorzüge von G-Sync verkauft sollte klar sein, mich wundert eher das NV das nicht offensiver erwähnt hat. Zumindest an mir ist das völlig vorbei gegangen. Aber kann natürlich auch sein das man dieses Feature bewusst geheim gehalten hat um dann noch eine Trumpfkarte zu haben wenn AMD kommt.

Beide aktuelle Probleme von Freesync hat nVidia mit dem Retail-Produkten schon gelöst. Da war es längst bekannt, dass AMD an einer Alternative arbeitet.

Deutet alles darauf hin, dass man diese Verbesserungen bewusst geheim gehalten hat, um zusehen, was AMD bringen wird.

[Gipsel]

Ich komme nicht mit falschen und absurden Anschuldigungen klar. Ich werde doch wohl selbst am besten wissen, was ich meine und über was ich schreibe.Es ist doch klar, was Du meintest: Daß das maximal 7ms Delay bei Framekollisionen keine Rolle spielt, weil es eben nur 7ms wären (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=10582502#post10582502). Die Argumentation trifft nur auch auf 144Hz Monitore mit festem Refresh zu. Und sie ist relativ unerheblich gegen meinen ursprünglichen Einwand, daß auch GSync eine Grenze für die Zeitdauer zwischen Refreshes hat, die man eben nur versucht, durch cleveres Verhalten selten zu treffen (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=10582498#post10582498) (was aber nicht immer funktionieren kann). Ich redete von den Situationen, in denen man perfekt oder eben nicht perfekt synchronisiert bleibt. Ein 7ms Delay bei einer Kollision eines Zwangsrefreshes mit einem neuen Frame ist nicht perfekt synchronisiert. Daß es nur maximal 7ms sind, ändert was genau am prinzipiellen Punkt?
Gipsel hat sich in seiner Argumentation verrannt, und der einzige Weg für ihn sein Gesicht zu wahren, ist mir zu unterstellen, ich hätte Dinge gesagt, die ich so einfach nie geschrieben und noch weniger gemeint habe.Ich unterstelle Dir gar nichts, ich zitiere bzw. verlinke auf Deine Posts.
Im Prinzip ist es nur eine Kleinigkeit, auf die ich hingewiesen habe und Dein Argument hat es nicht im Geringsten entkräftet.

[Dimitri Mayakovsky]

Ich redete von den Situationen, in denen man perfekt oder eben nicht perfekt synchronisiert bleibt. Ein 7ms Delay bei einer Kollision eines Zwangsrefreshes mit einem neuen Frame ist nicht perfekt synchronisiert.
Hilft nur nicht, dass man nach der Maximalzeit irgendwas anzeigen muss. Alt oder neu? Neu ist nicht da? Dann hilft nur alt. Mit Delay eben. Alles andere hätte Artefakte, so wie man es ja bei FreeSync exakt sieht (Tearing, Stutter etc.).

G-Sync wird hier wahrscheinlich auch den Vorteil einer direkteren Kommunikation GPU->Modul zu haben, so dass besser abgeschätzt werden kann ob der Frame in-time da sein wird oder nicht.

Ansonsten haben viele so getan als wäre diese Technik ohne dem teuren Modul im Monitor bei G-Sync gar nicht möglich, das wurde klar widerlegt.
Das ist leider falsch, da wie oben beschrieben AMD mit FreeSync nicht in der Lage ist ohne das Modul die gleiche Funktionalität wie G-Sync zu bieten. Da hat uns AMD ziemlich an der Nase herumgeführt, in dem so getan wurde, als wäre FreeSync äquivalent zu G-Sync.

[Troyan]

Ich redete von den Situationen, in denen man perfekt oder eben nicht perfekt synchronisiert bleibt. Ein 7ms Delay bei einer Kollision eines Zwangsrefreshes mit einem neuen Frame ist nicht perfekt synchronisiert. Daß es nur maximal 7ms sind, ändert was genau am prinzipiellen Punkt?


Man bleibt immer "perfekt" synchronisiert. Das neue Frame wird maximal mit einer Verzögerung von 7ms angezeigt. In Wirklichkeit wird die Verzögerung erheblich geringer sein, da der zeitliche Unterschied von Frame zu Frame sich kaum unterscheidet.

[Gipsel]

Hilft nur nicht, dass man nach der Maximalzeit irgendwas anzeigen muss. Alt oder neu? Neu ist nicht da? Dann hilft nur alt. Mit Delay eben.Nicht immer mit Delay. Nur bei einer Kollision mit dem neuen Frame. Das kann vorkommen. Das ist genau meine Aussage.
Man bleibt immer "perfekt" synchronisiert. Das neue Frame wird maximal mit einer Verzögerung von 7ms angezeigt.Also nicht mehr perfekt. Wenn irgendwo ein von Frame zu Frame variables Delay dazukommt, ist man raus aus der perfekten Synchronisation. Und sei es nur für ein Frame.

[robbitop]

Bei einem 144Hz Monitor und Frameraten oberhalb davon macht ein Limiter meiner Meinung nach auch kaum noch Sinn. Erreicht das Spiel sagen wir mal 200 fps ohne VSync, beträgt der Lag durch VSync gerade mal 1,9 ms. Ich bezweifle, daß das ein signifikanter Prozentsatz der Leute merkt. Außerdem ist das mit VSync konstant und vorhersagbar (die Zeitdauer vom Anfang des Renderns des Frames bis zur Anzeige am Monitor ist konstant, wenn die fps dauerhaft an der Refreshrate des Monitors kleben), also nach diesen Kriterien für den Spieler recht angenehm (kein Judder mit variabler Zeit zwischen Renderbeginn eines Frames und Anzeige wie bei fps unter Refreshrate und VSync).
Bei einem G-/FreeSync-Monitor, der bis 144Hz geht, spricht meiner Meinung nach nicht viel für einen Limiter (außer, wenn man den Stromverbrauch reduzieren will). Unterhalb von 144Hz gibt es kein VSync-Lag, oberhalb ist er minimal und sozusagen "gutartig".


Wo müsste man denn einen Framelimiter setzen für ein 60 Hz G-Sync Display? Genau auf 60 fps?

[nalye]

Kindergartenscheiße und Beleidigungen gelöscht

[Grestorn]

Es ist doch klar, was Du meintest: Daß das maximal 7ms Delay bei Framekollisionen keine Rolle spielt, weil es eben nur 7ms wären (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=10582502#post10582502). Die Argumentation trifft nur auch auf 144Hz Monitore mit festem Refresh zu. Und sie ist relativ unerheblich gegen meinen ursprünglichen Einwand, daß auch GSync eine Grenze für die Zeitdauer zwischen Refreshes hat, die man eben nur versucht, durch cleveres Verhalten selten zu treffen (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=10582498#post10582498)

Gegen all dies gibt es auch nichts einzuwenden. Deine Postings habe nur etwas ganz anderes enthalten:

Nur ein Beispiel. Du hast geschrieben:

"Das minimale Delay ist knapp 7ms, das maximale Intervall zwischen zwei Refreshes ist bei den Monitoren mit 30Hz minimaler Refreshrate 33ms. Und diese Grenze existiert. Anders geht es gar nicht. Auch das GSync-Modul kann nicht in die Zukunft schauen."

Diese Aussage ist und bleibt in diesem Zusammehang unverständlich. Eine minimale Refreshrate von 33ms gibt es nicht. Bei GSync In keinem Fall, und selbst bei Freesync gehe ich davon aus, dass der Treiber nicht den vollen 33ms Zyklus abwartet, wenn bereits vorzeitig ein neues Frame bereitstehen sollte, sondern dies mit der minimal möglichen Verzögerung (also maximal 16 ms bei einem 60 Hz Monitor) ausgibt.

Es ging in meinen Postings immer nur um den Nachteil, den das Einfügen eines extra Frames im schlimmsten Fall hat. Und das sind eben 7ms (oder 16ms bei 60 Hz). Und selbst das sind nur theoretische maximal Werte, da wir wissen, dass ein 144Hz Monitor in der Lage sein muss, ein Bild in 7ms zu refreshen. In der Praxis wird es - wenn überhaupt - nur sehr selten dazu kommen, dass ein Frame tatsächlich volle 7ms verzögert ausgegeben wird. Für ein 60 Hz Monitor gilt das selbe, eben dann mit 16ms.

Ich habe diesen Effekt nie bestritten, im Gegenteil, ich habe ihn lange vor unserer Diskussion in diesem und einem anderen Thread bereits auf einem simplen Zeitstrahl selbst hergeleitet und erläutert.

Wo müsste man denn einen Framelimiter setzen für ein 60 Hz G-Sync Display? Genau auf 60 fps?

Ich würde sagen: Am besten leicht unterhalb. Wenn man es auf 59 fps setzen, hat man bei GSync/Freesync keinen Nachteil, die Framerate wäre dann konstant bei 59 fps.

Allerdings sollte der Limiter am besten im Spiel selbst sein. Ein Limiter im Treiber oder einem externen Tool kann auch wieder Lag erzeugen!

[Schaffe89]

Besser konnte man AMD ja nicht vorführen.

Ob die aktuelle Situaton G-sync vs. Freesync wirklich ein Vorführen von AMD darstellt, kann ich nicht nachvollziehen.
Die MOnitore sind erheblich günstiger und ja, derzeit besteht bei Freesync noch der Nachteil dass die Frames unter 40 Hertz nicht verdoppelt werden oder Frames zwischengeschoben werden.
Das kann sich aber noch ändern, bzw ist die offene Lösung alleine schon auch mit dem fürm mich persönlich ziemlich unwichtigen Nachteil ( da ich in diesen Regionen eh nicht spiele ) relativ wurscht, wobei sich für meine Titan X dann schon ein G-sync Monitor anbieten würde, werd ich aber aus Prinzip nicht kaufen.

Ich warte bis bessere FReesyncmonitore kommen, vll welche die bis 36 Hertz runtergehen, dann schlag ich zu.

[Dimitri Mayakovsky]

Nicht immer mit Delay. Nur bei einer Kollision mit dem neuen Frame. Das kann vorkommen. Das ist genau meine Aussage.
Es gibt nur keine Alternative. Ganz einfach.

Die Alternative wäre Tearing, weil man mitten im Aufbau zwischen Frame A (alt) und Frame B (neu) wechselt.

Also wie ohne V-Sync. Dann brauche ich aber weder A-Sync noch FreeSync.

Ob die aktuelle Situaton G-sync vs. Freesync wirklich ein Vorführen von AMD darstellt, kann ich nicht nachvollziehen.
Aktuell ist FreeSync ein ziemliches Desaster. Zum Release der Monitore gab es für Endkunden keine Treiber, selbst Hardware-Redaktionen konnte Geräte (die noch dazu mehr als spärlich an selbige verteilt wurden) nicht testen.

Dann zeigte sich, dass sämtliche bisherigen FreeSync-Monitore unter massivem Ghosting leiden. Und jetzt wissen wir auch, dass FreeSync unter 40Hz nutzlos ist.

Geht es NOCH schlechter?

Die MOnitore sind erheblich günstiger
Die Dinger MÜSSEN ja auch günstiger sein, wenn sie schon in Sachen BQ nicht an vergleichbare G-Sync Geräte ran kommen.

und ja, derzeit besteht bei Freesync noch der Nachteil dass die Frames unter 40 Hertz nicht verdoppelt werden oder Frames zwischengeschoben werden. Das kann sich aber noch ändern
Finds ja immer interessant, wie solche unbewiesenen Behauptungen immer wiederholt werden bis ... ja, bis wann denn? Bis jeder User hier im Forum vergessen habt, dass ihr sie getätigt habt?

[aufkrawall]

Allerdings sollte der Limiter am besten im Spiel selbst sein. Ein Limiter im Treiber oder einem externen Tool kann auch wieder Lag erzeugen!
Bei CS:GO fühlte sich der Lag mit dem Limiter von RTSS afair definitiv niedriger an als der des in-game Limiters.

[Grestorn]

Bei CS:GO fühlte sich der Lag mit dem Limiter von RTSS afair definitiv niedriger an als der des in-game Limiters.

Der In-Game Limiter kann auch immer schlecht implementiert sein.

Ein Treiber oder ein Tool kann ja immer nur künstliche Delays einbauen, die dann aber auch wieder potentiell Lags in den Zeitaublauf des Spiels einbauen (sprich: eine weitere Verzögerung in die ganze Pipline von Steuerimpuls bis zur Sichtbarkeit auf dem Schirm einfügen).

Das Spiel hätte die Chance, das interne Timing so abzustimmen, dass notwendige Verzögerungen vor dem Rednering eines neuen Frames eingefügt werden, so dass das tatsächlich ausgegebene Frame zeitlich so nah wie möglich an der internen Zeitachse des Spiels (und damit an den Steuersignalen des Spielers) liegt.

Zumindest ist das meine - an dieser Stelle zugegeben eher laienhafte - Vorstellung.

[aufkrawall]

Gipsel sprach da ja von.
Im Zweifel ist der Lag des Limiters von externen Tools wie Afterburner und hoffentlich auch Treiber aber wahrscheinlich immer noch besser als der Vsync-Lag <100Hz.

[Red_Bull]

Die Dinger MÜSSEN ja auch günstiger sein, wenn sie schon in Sachen BQ nicht an vergleichbare G-Sync Geräte ran kommen.



Was hat BQ mit synchronisierung zum tun?

[Dimitri Mayakovsky]

Die Frage ist doch, wie dieser Limiter nun konkret aufgebaut ist.

Wenn man einfach nur die Übertragung des (fertigen) Bildes an den Bildschirm verzögert, hat man genauso Input-Lag.

Was hat BQ mit synchronisierung zum tun?
Wenn FreeSync unterhalb der minimalen Refreshrate des Panels auf einen V-Sync-Off-Modus verfällt, ergibt das sowohl Tearing, als auch Stutter. Das ist natürlich auch BQ.

[Unicous]

@Dimitri Mayakovsky

Jeder LCD-Monitor "leidet" unter Ghosting. Man kann das mit speziellen Features verbessern. Diese Features wurden entweder nicht oder schlecht implementiert, das hat nichts mit Adapative Sync zu tun(denn das Ghosting tritt mit und ohne Adaptive Sync auf ;)).

Ich werde das so oft wiederholen, bis du und andere das endlich mal zur Kenntnis nehmen.

Die Hardware-Redaktionen haben zum Teil alle drei erhältlichen Monitore (LG ,Acer BenQ) zur Verfügung gestellt bekommen, auch das ist von dir an den Haaren herbeigezogen. Jede größere Redaktion, sei es PCGH, Computerbase, PCPer, Techreport, AT oder auch Leute die YT-Videos machen, z.B. LinusTechTips haben Monitore erhalten. Du lügst also eindeutig.

Dass die Treiber zu spät in die Redaktionen kamen stimmt aber offenbar.


Die Monitore sind wohl unverändert in ihrer Elektronik(zu den Vorgängermodellen), die Panels sind öfter schlechter bzw. anders als in vergleichbaren G-Sync Monitoren. Dafür sind sie aber auch um einiges erschwinglicher, nimmt man mal den überteuerten BenQ außen vor.

Dass die erste Generation von "FreeSync"-Monitoren einen nicht vom Hocker haut, ist nicht Adaptive Sync geschuldet, denn das funktioniert einwandfrei, sondern der zaghaften Implementierung seitens der Hersteller.

Das kann und wird alles besser werden, den ersten "echten" Vergleich kann man beim Asus IPS Monitor anstellen. Denn hier wird endlich mal das gleiche Panel genutzt, wie bei dem Acer IPS Monitor. Und es dauert wohl nur noch etwas mehr als einen Monat bis es zu diesem ersten showdown kommen kann.

[Kartenlehrling]

/em Ignoriert das dumme Gelaber von @Dimi


Ich habe mir nun einen Asus MG279Q bei Hardwareversand.de bestellt obwohl ich mit meinem erst neu gekauften Dell u2515h sehr zufrieden bin und
mit einer HD7970 überhaupt keine freesync taugliche Grafikkarte habe.
Hinzukommt das der Monitor sowieso teurer sein wird, 650€ kosten und soll "nur" bei Alternate.de wieder vorstellbar sein, wie der Acer IPS-gsync.

[Unicous]

Wirst du dich wohl noch min. einen Monat gedulden müssen bis das Ding auf deinem Schreibtisch steht. bei OcUK geht man (optimistisch) von Anfang Mai aus, laut Asus könnte es eher Mitte/Ende Mai sein.

[Dimitri Mayakovsky]

Jeder LCD-Monitor "leidet" unter Ghosting. Man kann das mit speziellen Features verbessern. Diese Features wurden entweder nicht oder schlecht implementiert, das hat nichts mit Adapative Sync zu tun(denn das Ghosting tritt mit und ohne Adaptive Sync auf ;)).
Der Punkt ist nur, dass es eben G-Sync Monitore OHNE schreckliches Ghosting gibt, FreeSync fällt mir keiner ein, dir?

Die Hardware-Redaktionen haben zum Teil alle drei erhältlichen Monitore (LG ,Acer BenQ) zur Verfügung gestellt bekommen, auch das ist von dir an den Haaren herbeigezogen. Jede größere Redaktion, sei es PCGH, Computerbase, PCPer, Techreport, AT oder auch Leute die YT-Videos machen, z.B. LinusTechTips haben Monitore erhalten. Du lügst also eindeutig.
Ich lüge also "eindeutig", wenn du doch selbst am Anfang genau das bestätigst, was ich geschrieben habe ;D

Da vernebelt dir offensichtlich mal wieder der Hass das Gehirn. Davon, dass überhaupt keine Redaktion irgendeinen Monitor erhalte habe, habe ich gar nichts geschrieben.

Steck dir deinen Lügenvorwurf also dahin, wo die Sonne nicht scheint.

[robbitop]

Ich würde sagen: Am besten leicht unterhalb. Wenn man es auf 59 fps setzen, hat man bei GSync/Freesync keinen Nachteil, die Framerate wäre dann konstant bei 59 fps.

Allerdings sollte der Limiter am besten im Spiel selbst sein. Ein Limiter im Treiber oder einem externen Tool kann auch wieder Lag erzeugen!

Mir geht es schon um einen Limiter im Treiber. Ich spiele mit dem Gedanken, den 4K ASUS ROG SWIFT (2015) zu kaufen. Ich will verhindern, dass bei >60 fps dann Lags entstehen. Die Frage ist nur, ob ein Limitier im Treiber sinnvoll ist und wenn ja auf welchen Wert der stehen muss.

Vieleicht kann man den SWIFT ja auch auf 85 Hz übertakten (allerdings ignoriert DSR die 85 Hz der custom resolutions).

[aufkrawall]

Sagtest du nicht genau das Gleiche erst kürzlich an anderer Stelle?

[robbitop]

Ja. Aber hier geht es um den Limiter. Der SWIFT ist nur mein persönlicher Hintergrund zu dieser hier spezifischen Frage.

[nalye]

Können wir das gegenseitige anwichsen mal unterlassen? Ist ja furchtbar...

[Gipsel]

Wo müsste man denn einen Framelimiter setzen für ein 60 Hz G-Sync Display? Genau auf 60 fps?Ich bezweifle ganz allgemein, daß externe Tools da die optimale Lösung sind. Wie Grestorn schon schrieb, wäre ein ins Spiel integrierter Limiter vermutlich die beste Variante, weil der am ehesten wissen kann, wo man die Wartezeit am besten einfügt. Aber schiefgehen kann da auch immer was, da man ja vorher nicht genau weiß, wie lange das Rendern des Frames dauern wird, so daß es genau zum nächsten Refresh fertig wird. Und zusätzlich dauert es optimalerweise auch immer gleich lange vom Anfang des Renderns (unter der Annahme, daß die Spielwelt alle Eingaben bis zu diesem Zeitpunkt berücksichtigt) bis zur Anzeige am Schirm. Das ist recht schwierig, das optimal und mit kurzem Delay umzusetzen.
Insofern gibt es wohl auch kein Patentrezept. Ob komplett ohne Limiter oder ein Limit knapp unter dem maximalen Refresh eines Displays besser ist, könnte sich im Einzelfall unterscheiden.
Im Zweifelsfall hilft nur ein 144Hz Display und eine höhere Framerate.

===============================

Gegen all dies gibt es auch nichts einzuwenden. Deine Postings habe nur etwas ganz anderes enthalten:
Nur ein Beispiel. Du hast geschrieben:
"Das minimale Delay ist knapp 7ms, das maximale Intervall zwischen zwei Refreshes ist bei den Monitoren mit 30Hz minimaler Refreshrate 33ms. Und diese Grenze existiert. Anders geht es gar nicht. Auch das GSync-Modul kann nicht in die Zukunft schauen."

Diese Aussage ist und bleibt in diesem Zusammehang unverständlich.Sie bezieht sich auf das Intervall zwischen zwei Refreshes, also der Grenze, um die es ging und die auch GSync treffen kann. Das 7ms Delay hattest Du reingebracht (in einem Zusammenhang, der sich mir nicht sofort erschloß, weil es für den prinzipiellen Punkt eigentlich irrelevant ist, wie ich schon schrieb).
Eine minimale Refreshrate von 33ms gibt es nicht.Von der schreibe ich auch nicht. Deutsche Sprache, schwere Sprache. Jetzt verstehe ich das Problem. Laß mich den fraglichen Satz farblich strukturieren:
"das maximale Intervall zwischen zwei Refreshes ist bei den Monitoren mit 30Hz minimaler Refreshrate 33ms."

Jetzt verstanden? Alles wieder gut? :)

Bei GSync In keinem FallDas Szenario, in dem GSync volle 33ms wartet, um dann einen Zwangsrefresh einzuschieben, habe ich bereits geschildert. Das kann durchaus vorkommen. Im Endeffekt einfach, weil das GSync-Modul nicht in die Zukunft schauen kann, also nicht weiß, wann das nächste Frame kommen wird. Bei Frametimes z.B. um 25ms (40fps) und einem "Ausreißer" auf 33ms (oder länger), werden die vollen 33ms gewartet (bei den ersten GSync-Modulen offenbar sogar noch länger, der Zwangsrefresh nach 33ms wurde praktisch "vergessen", was zu kurzzeitig schwarzen Bildschirmen führte). Der vorzeitige Zwischenrefresh ("Frameverdopplung") kann erst beim nächsten Frame einsetzen als Reaktion auf eine Frametime oberhalb einer Schwelle (laut Tests offenbar 5/6 des maximalen Refreshintervalls von 33ms) einsetzen (geht gar nicht anders).

[dargo]

/em Ignoriert das dumme Gelaber von @Dimi

*unterschreib*

Kaum hat der hier wieder Ausgang darf man nur dummes Zeug von dem lesen, ähm... blättern.


Ich habe mir nun einen Asus MG279Q bei Hardwareversand.de bestellt obwohl ich mit meinem erst neu gekauften Dell u2515h sehr zufrieden bin und
mit einer HD7970 überhaupt keine freesync taugliche Grafikkarte habe.
Hinzukommt das der Monitor sowieso teurer sein wird, 650€ kosten und soll "nur" bei Alternate.de wieder vorstellbar sein, wie der Acer IPS-gsync.
Eigentlich sollte Tahiti Freesync unterstützen, nur halt mit einer festen Frequenz. Sprich, als Übergang sollte es doch mit einem Framelimiter klappen wenn du die Framerate immer halten kannst. Klar... keine zufriedenstellende Lösung auf Dauer. Halt bis du ne neue Karte kaufst.

[Dimitri Mayakovsky]

Ich bezweifle ganz allgemein, daß externe Tools da die optimale Lösung sind. Wie Grestorn schon schrieb, wäre ein ins Spiel integrierter Limiter vermutlich die beste Variante, weil der am ehesten wissen kann, wo man die Wartezeit am besten einfügt.
Die beste Variante ist es solange wie möglich mit dem Start des Renders zu warten, weil man nur dann den minimalsten Input-Lag hat.

Ist nur leider faktisch nie möglich mit V-Sync.

[Grestorn]

Das Szenario, in dem GSync volle 33ms wartet, um dann einen Zwangsrefresh einzuschieben, habe ich bereits geschildert. Das kann durchaus vorkommen. Im Endeffekt einfach, weil das GSync-Modul nicht in die Zukunft schauen kann, also nicht weiß, wann das nächste Frame kommen wird. Bei Frametimes z.B. um 25ms (40fps) und einem "Ausreißer" auf 33ms (oder länger), werden die vollen 33ms gewartet (bei den ersten GSync-Modulen offenbar sogar noch länger, der Zwangsrefresh nach 33ms wurde praktisch "vergessen", was zu kurzzeitig schwarzen Bildschirmen führte). Der vorzeitige Zwischenrefresh ("Frameverdopplung") kann erst beim nächsten Frame einsetzen als Reaktion auf eine Frametime oberhalb einer Schwelle (laut Tests offenbar 5/6 des maximalen Refreshintervalls von 33ms) einsetzen (geht gar nicht anders).

Das ist alles klar und wurde nie bezweifelt. Aber was Du schreibst klingt zumindest so, als würdest Du meinen, dass GSync - in einigen Fällen oder immer - quasi die vollen 33 ms wartet, bis ein neues Frame angezeigt wird, obwohl ein neues Frame bereits verfügbar ist. Und nur dann sind die 33ms relevant, nur dann wäre das Einschieben eines Zwangsrefresh-Frames ein Problem.

Da aber ein neues Frame quasi jederzeit dargestellt werden kann, spielen diese 33ms überhaupt keine Rolle. Nur in dem Fall, den wir nun schon ausführlich diskutiert haben, dass das neue Frame ungeschickt zeitlich mit dem zusätzlich eingeschobenen Wiederhol-Frame kollidiert, kann es zu einer Verzögerung von max. 7ms kommen.

Um meinen von Dir eben teilzitierten Satz, mit dem Du offenbar nicht einverstanden bist, in voller Länge zu wiederholen:

"Eine minimale Refreshrate von 33ms gibt es nicht. Bei GSync In keinem Fall"

Damit ist gemeint, dass es keine relevante Untergrenze gibt, bei der GSync die Bilder nicht mehr fast immer (*) in genau der Geschwindigkeit ausgeben kann, in der sie von der Karte berechnet werden. Es gibt also de fakto keine minimale Refreshrate. Punkt.

(*) "Fast immer", weil es eben bei dem einen oder anderen Frame zu einer Kollision mit einem eingeschobenen Wiederhol-Frame kommen kann. Das ändert aber nichts grundsätzliches an meiner Aussage. Bei einem einzelnen Frame wird das niemandem auffallen, und selbst wenn mehrere Frames hintereinander in der ungünstigen Framerate von z.B. 35ms kommen, wird GSync nach einer eventuellen Kollision alle darauffolgenden Wiederholframes automatisch in die Mitte des zuletzt gemessenen Intervalls legen (das zeigt das PCPer Video).

Ergo: Ja, man kann bei schwankenden Frameraten im Bereich unterhalb von 35 fps hin und wieder mal einen auf ein Frame beschränkten Mini-Hitch von 1-7 ms haben. Ich behaupte, den kann *niemand* in der Praxis wirklich sehen - insbesondere wenn man eh schon eine schwankende Framerate in diesem niedrigen Bereich hat!

Deswegen bleibe ich bei meiner Aussage: Es gibt bei GSync de fakto keine untere Grenze der Framerate, die noch in Echtzeit ausgegeben werden kann. Das war meine Ursprungsaussage, die ich in voller Kenntnis der Kollisionsproblematik schon vor vielen Seiten so geschrieben habe, und die m.E. vollumfänglich korrekt war und ist. Bei allem, was Du geschrieben hast, habe ich nur den Eindruck, "Hauptsache dagegen und zeigen wir ihm mal, dass er keine Ahnung hat, wovon er da schreibt".

[fondness]

Nur zum Verständnis: Die 7ms gelten nur bei einem 144Hz Monitor, bei 60Hz wären das eher ~17ms korrekt?

[Grestorn]

Nur zum Verständnis: Die 7ms gelten nur bei einem 144Hz Monitor, bei 60Hz wären das eher ~17ms korrekt?

Die Zeit berechnet sich daraus, wie lange es dauert, bis ein Bild über DP vom Framebuffer zum Monitor übertragen, im Scaler verarbeitet und schließlich an das Panel übertragen und dort angezeigt wurde. Die DP Übertragung und die Anzeige im Panel läuft bei einem 60 Hz Monitor halb so schnell wie bei einem 120 Hz Monitor. Also stimmt Deine Aussage grundsätzlich.

Aber das sind so oder so eher theoretische Betrachtungen, wie lange es wirklich minimal und maximal dauert, bis ein Bild vom Framebuffer der Grafikkarte bis alle Pixel davon sichtbar sind, hängt sicher von vielen Faktoren ab. Die 7ms sind nur die absolute Obergrenze bei einem 144Hz Monitor, denn länger darf es bei vollen 144 fps ja auch nicht dauern. Entsprechend dann eben 16,7ms bei einem 60 Hz Monitor.

[maximus_hertus]

Echt witzig, wie hier teilweise "diskutiert" wird ;) Meine 2 cents:

Bisher gibt es nur Bildschirme zum Enthusiast-Preis, wobei imo keiner wirklich überzeugen kann. Egal welcher Bildschirm, irgendeinen gröeren Schnitzer gibt es leider immer.

Die ersten Free-Sync Implementierungen der Bildschirmhersteller ist eher unbefriedigend und das Geld imo nicht Wert. Man kann das sehr gut mit 3DVision vergleichen - ansich eine sehr schöne Sache, aber mangels (guter) Implementierung in Spielen idR nicht (gut) nutzbar.

Es ist eh interessant, dass man G-Sync und Free-Sync / A-Sync als gleiche Produktkategorie vergleicht. Ja, die Idee ist ähnlich / gleich, aber G-Sync wird imo nie eine relevante Marktposition erhalten können, dafür sind die Bildschirme "Lichtjahre" zu teuer. Erst wenn man einen Preispunkt von 199 Euro oder weniger erreicht, wird es zum "Massenphänomen" und da sehe ich G-Sync nahezu chancenlos.

Mal was technisches: Klappt G- bzw. Free-Sync auch mit mehreren Monitoren => Eyefinity / Vision Surround?

[Kartenlehrling]

Mal was technisches: Klappt G- bzw. Free-Sync auch mit mehreren Monitoren => Eyefinity / Vision Surround?


10sec ... google

https://www.youtube.com/watch?v=jTZCBi0h7M8
NVIDIA G-Sync Surround Impressions: Using 3 ASUS ROG Swift Displays

[Grestorn]

Mal was technisches: Klappt G- bzw. Free-Sync auch mit mehreren Monitoren => Eyefinity / Vision Surround?

Sehr gute Frage. Wenn dann nur bei absolut baugleichen Modellen, und selbst dann wage ich es zu bezweifeln. Leider habe ich nicht die Kohle, mir auf Verdacht noch zwei weitere Swifts zu kaufen :)

/edit: Ok, es geht scheinbar doch. Beeindruckend. So, und jetzt ne Bank ausrauben, damit ich die Monitore und drei weitere Titan X kaufen kann :)

[Unicous]

Geht. Bei Freesync braucht es nur den Treiber der im April kommen soll. Bei G-Sync gab es letztes Jahr einen Treiber. Aber es gab glaube ich irgendeine Einschränkung(edit: zu der Zeit brauchte man für jeden Monitor eine Karte. Auch dem Fakt geschuldet, dass man nur einen DP-Port hatte ;)). Kann mich aber nicht mehr erinnern. Tom Peterson war ja seinerzeit extra bei PCPer um das vorzustellen.


Und ja, man braucht bei FreeSync identische Monitore. Bei G-Sync glaube ich auch.

[Kriton]

Unabhängig vom konkreten Delay, solange FreeSync nicht in der Lage ist auch mit Frameraten unterhalb der minimal notwendigen Refreshrate des Panels umzugehen, ist die Technik schlicht nicht gleichwertig zu G-Sync. Ganz einfach.

Dass es einfach nur ein Bug ist, halte ich für ziemlich unwahrscheinlich. So ein massiver Fehler, bei der Haupfunktionalität? Das soll keiner vorher getestet haben?

Zumindest wissen wir jetzt, dass G-Sync eben doch deutlich mehr ist, als uns AMD das immer verkaufen wollte.

Ein AMD-kritischer Post bei gleichzeitigem Lob von Nvidia? Und das von Dir?

EVYYD669t10

Was ist mit der bei Nvida fehlenden Wahlmöglichkeit von VSync on/off oberhalb der dynamischen Refreshrate? Ist (um Deine Wortwahl zu verwenden) G-Sync schlicht nicht gleichwertig zu Freesync?

Besser konnte man AMD ja nicht vorführen. Und deren Marketingtricks waren ja auch schon hart an der Grenze, ich erinnere mich da nur an die Folie mit einem behaupteten Framerate-Spektrum von "9-200Hz" für FreeSync, obwohl das nur in Abstufungen möglich ist, also 9-60, 12-75 usw.

Da war doch was:

Das ist schlicht vom Panel abhängig. A-/Free-Sync an sich unterstützt auch niedrigere Refreshraten.

Wäre schön, wenn die Differenzierung zwischen FreeSync/AdaptiveSync und den Panels beachtet würde bevor man solche (falschen) Aussagen macht (hinsichtlich der Hz-Angaben).


Dann zeigte sich, dass sämtliche bisherigen FreeSync-Monitore unter massivem Ghosting leiden. Und jetzt wissen wir auch, dass FreeSync unter 40Hz nutzlos ist.

Die Dinger MÜSSEN ja auch günstiger sein, wenn sie schon in Sachen BQ nicht an vergleichbare G-Sync Geräte ran kommen.

Siehe meine Aussage zur Differenzierung :rolleyes::

Das mit dem fehlenden Overdrive bzw. dem Ghosting ist ein Problem der Monitorhersteller.



G-Sync wird hier wahrscheinlich auch den Vorteil einer direkteren Kommunikation GPU->Modul zu haben, so dass besser abgeschätzt werden kann ob der Frame in-time da sein wird oder nicht.

Das ist leider falsch, da wie oben beschrieben AMD mit FreeSync nicht in der Lage ist ohne das Modul die gleiche Funktionalität wie G-Sync zu bieten. Da hat uns AMD ziemlich an der Nase herumgeführt, in dem so getan wurde, als wäre FreeSync äquivalent zu G-Sync.

Welche Funktionalität genau? Einen bereits existierenden Frame zu doppeln?

Das erwähnte bei 27fps ist eins von AMD. Vermutlich haben die da einen Bug bei der Konfiguration des Verhaltens von VSync an/aus unterhalb des dynamischen Bereichs eingebaut. Wollen wir mal hoffen, daß die nicht Monate benötigen, um das zu fixen.
Irgendwie kapiere ich nicht, wie sowas immer wieder verbockt wird. Ich meine, selbst unter Zeitdruck checke ich doch zumindest das grundlegende Verhalten in ein oder zwei corner cases. :|

@mironicus:
Die naivste FreeSync-Lösung (die AMD aber offenbar im Treiber durch einen Bug "sabotiert" hat) sollte z.B. beim Fall der 27fps auch 54 Refreshes am Monitor produzieren.

Siehe auch:

Und ich habe auch schon (mehrfach) geschrieben, daß das Senden des alten Frames bei Unterschreiten der minimalen Refreshrate sowieso schon passiert. Und dafür benötigt es natürlich keine Treiberupdates für jedes Panel, das ist schlicht Blödsinn, was die da sagen.

Was momentan verbugt zu sein scheint, ist, daß nach so einem Refresh mit dem alten Frame wegen Überschreitung der maximalen Zeitspanne zwischen zwei Refreshs (bei 40Hz Minimum also 25ms) der nächste Refresh offenbar frühestens erst wieder 25ms später gemacht wird, nicht schon nach 6,9ms (so lange dauert der Transfer des Frames bei einem 40-144Hz Modell). Die Konfigurieren also die Display-Engine der GPU schlicht nicht richtig (vermutlich haben die das mit der VSync an/aus Wahlmöglichkeit verbaselt).

Aber ja, noch nicht durch FreeSync realisiert.

Und zu der direkteren Kommunikation:

http://www.computerbase.de/2013-12/nvidia-gsync-test/4/#abschnitt_benchmarks_mit_gsync

[Dimitri Mayakovsky]

Was ist mit der bei Nvida fehlenden Wahlmöglichkeit von VSync on/off oberhalb der dynamischen Refreshrate? Ist (um Deine Wortwahl zu verwenden) G-Sync schlicht nicht gleichwertig zu Freesync?
Wurde ja schon angekündigt, dass es diese Auswahl mit einem Treiberupdate geben wird.

Wäre schön, wenn die Differenzierung zwischen FreeSync/AdaptiveSync und den Panels beachtet würde bevor man solche (falschen) Aussagen macht (hinsichtlich der Hz-Angaben).
Es ändert ja nichts daran, dass es solch einen Monitor nicht gibt (niemals geben wird?). Das hätte AMD ja durchaus schreiben können.

Wenn eure Interpretation richtig ist, dann hätte bei G-Sync auch z.B. ab 1 Hz angegeben werden. Im Gegensatz zu FreeSync kann G-Sync das sogar tatsächlich ;D

Siehe meine Aussage zur Differenzierung :rolleyes::
Erstmal muss es einen Monitor ohne Ghosting geben, bevor ich diese Schuld zu 100% den Monitorherstellern in die Schuld schiebe.

Welche Funktionalität genau? Einen bereits existierenden Frame zu doppeln?
Synchronisierte Bildausgabe auch unterhalb der minimalen Refreshrate des Panels.

Aber ja, noch nicht durch FreeSync realisiert.
Hat AMD das Treiberupdate schon angekündigt? Wann kommt es?

[dargo]

Bisher gibt es nur Bildschirme zum Enthusiast-Preis, wobei imo keiner wirklich überzeugen kann. Egal welcher Bildschirm, irgendeinen gröeren Schnitzer gibt es leider immer.

Die ersten Free-Sync Implementierungen der Bildschirmhersteller ist eher unbefriedigend und das Geld imo nicht Wert. Man kann das sehr gut mit 3DVision vergleichen - ansich eine sehr schöne Sache, aber mangels (guter) Implementierung in Spielen idR nicht (gut) nutzbar.

Es ist eh interessant, dass man G-Sync und Free-Sync / A-Sync als gleiche Produktkategorie vergleicht. Ja, die Idee ist ähnlich / gleich, aber G-Sync wird imo nie eine relevante Marktposition erhalten können, dafür sind die Bildschirme "Lichtjahre" zu teuer. Erst wenn man einen Preispunkt von 199 Euro oder weniger erreicht, wird es zum "Massenphänomen" und da sehe ich G-Sync nahezu chancenlos.

Hier gebe ich dir absolut recht. Allerdings ist dieser LG:
http://geizhals.at/de/lg-electronics-29um67-p-a1223769.html?hloc=at&hloc=de

imho nicht wirklich teuer. Mit einem billigen TN-Panel wäre man sicherlich im Bereich von 200-250€. Zwei Probleme gibts dennoch... er ist immer noch nicht lieferbar obwohl schon lange gelistet und die Sache mit den min. 48Hz nicht gerade toll.

[Kartenlehrling]

Was ist mit der bei Nvida fehlenden Wahlmöglichkeit von VSync on/off oberhalb der dynamischen Refreshrate? Ist (um Deine Wortwahl zu verwenden) G-Sync schlicht nicht gleichwertig zu Freesync?

Mich würde auch interessieren wieso Vollbild Pflicht und kein Fenstermode funktioniert, und nach Raus-Rein-TAB teilweise nicht mehr funktioniert.

[Grestorn]

Mich würde auch interessieren wieso Vollbild Pflicht und kein Fenstermode funktioniert, und nach Raus-Rein-TAB teilweise nicht mehr funktioniert.

Angeblich soll an einer Lösung im Fenster gearbeitet werden. Aber dabei muss der DWM (Desktop Windows Manager) mitspielen, d.h. es muss möglich sein, und es ist noch unklar, ob das geht.

Mit Tab-Rein Raus hatte ich bisher kein Problem. Es sei denn, das jeweilige Spiel hat damit sowieso ein Problem.

[Kartenlehrling]

http://www.guru3d.com/articles-pages/lg-34um67-amd-freesync-monitor-review.html
LG 34UM67 AMD FreeSync Monitor Review - Tested & Reviewed

[Raspo]

Es gibt nur keine Alternative. Ganz einfach.

Die Alternative wäre Tearing, weil man mitten im Aufbau zwischen Frame A (alt) und Frame B (neu) wechselt.

Also wie ohne V-Sync. Dann brauche ich aber weder A-Sync noch FreeSync.


Aktuell ist FreeSync ein ziemliches Desaster. Zum Release der Monitore gab es für Endkunden keine Treiber, selbst Hardware-Redaktionen konnte Geräte (die noch dazu mehr als spärlich an selbige verteilt wurden) nicht testen.

Dann zeigte sich, dass sämtliche bisherigen FreeSync-Monitore unter massivem Ghosting leiden. Und jetzt wissen wir auch, dass FreeSync unter 40Hz nutzlos ist.

Geht es NOCH schlechter?


Äh, da fällt mir doch spontan die Verarsche einer Firma mit viel grün im Logo ein, die 3,5 auf 4 aufrunden und der CEO das als Feature verkauft.

[Kriton]

Es ändert ja nichts daran, dass es solch einen Monitor nicht gibt (niemals geben wird?). Das hätte AMD ja durchaus schreiben können.

Mal abgesehen von Deiner (aus der Luft gegriffenen Vermutung/Behauptung (http://de.wikipedia.org/wiki/Fear,_Uncertainty_and_Doubt)) differentierst Du noch immer nicht zwischen der Technik und deren Implementierung. AMD hat (logischerweise) nur etwas zu Ihrer eigenen Technik geschrieben.


Wenn eure Interpretation richtig ist, dann hätte bei G-Sync auch z.B. ab 1 Hz angegeben werden. Im Gegensatz zu FreeSync kann G-Sync das sogar tatsächlich ;D

Das ist falsch. Die Framedoppelung von G-Sync ist etwas ganz anderes als ein größerer dynamischer Refreshbereich wie bei FreeSync (der Technik, nicht den verfügbaren Monitoren).


Erstmal muss es einen Monitor ohne Ghosting geben, bevor ich diese Schuld zu 100% den Monitorherstellern in die Schuld schiebe.

Ach so, aber AMD kann man schon mal alles unterschieben, auch wenn das Gegenteil teilweise schon nachgewiesen wurde... :rolleyes:

Synchronisierte Bildausgabe auch unterhalb der minimalen Refreshrate des Panels.

Hat AMD das Treiberupdate schon angekündigt? Wann kommt es?

Lies noch einmal die zitierten Posts von Gipsel (er hatte sogar noch mehr zu dem Thema) - da würde es mich wundern wenn da nichts kommt (auch wenn mir noch keine Ankündigung bekannt ist).

[Grestorn]

Das ist falsch. Die Framedoppelung von G-Sync ist etwas ganz anderes als ein größerer dynamischer Refreshbereich wie bei FreeSync (der Technik, nicht den verfügbaren Monitoren).

Wieso?

[Kriton]

Gleicher Frame ist etwas anderes als ein neu berechneter?

[Grestorn]

Gleicher Frame ist etwas anderes als ein neu berechneter?
Du hast das Prinzip nicht verstanden. Lies nochmal und schau Dir das PCPer Video am besten nochmal an.

[Dimitri Mayakovsky]

Mal abgesehen von Deiner (aus der Luft gegriffenen Vermutung/Behauptung (http://de.wikipedia.org/wiki/Fear,_Uncertainty_and_Doubt)) differentierst Du noch immer nicht zwischen der Technik und deren Implementierung. AMD hat (logischerweise) nur etwas zu Ihrer eigenen Technik geschrieben.
Das haben sie dann aber nicht konsequent gemacht und der Vergleich von ihrer Technik vs. die Implementierung bei G-Sync ist Bullshit.

Das ist falsch. Die Framedoppelung von G-Sync ist etwas ganz anderes als ein größerer dynamischer Refreshbereich wie bei FreeSync (der Technik, nicht den verfügbaren Monitoren).
Falsch, während FreeSync nicht in der Lage ist den dynamischen Refresh unterhalb der minimalen Panelrefreshrate bei zu behalten und auf V-Sync off schaltet, bleibt G-Sync immer noch aktiv. Ob die Frames dann innerhalb des Monitors vervielfacht (werden müssen), ist ja irrelevant - so deine Behauptung es gehe um die Technik - da die Übertragung innerhalb von G-Sync auch runter bis 1 Hz funktioniert.

Also ENTWEDER AMD hat in der Tabelle die TECHNIK aufgezählt - dann war die Angabe in der G-Sync Spalte falsch - oder sie haben die IMPLEMENTIERUNG aufgezählt - dann ist die FreeSync-Spalte falsch.

Ach so, aber AMD kann man schon mal alles unterschieben, auch wenn das Gegenteil teilweise schon nachgewiesen wurde... :rolleyes:
Welchen FreeSync-Monitor ohne Ghosting gibt es denn?

Lies noch einmal die zitierten Posts von Gipsel (er hatte sogar noch mehr zu dem Thema) - da würde es mich wundern wenn da nichts kommt (auch wenn mir noch keine Ankündigung bekannt ist).
Außer Behauptungen von Gipsel sehe ich da nichts relevantes. Die Behauptung das ist ein Bug halte ich für mehr als nur schwammig und trotz der Aufdeckung der Problematik bei FreeSync gibt es immer noch keine Ankündigung von AMD diesen Bug zu fixen.

Ich bleibe daher bei meiner Behauptung, dass es kein Bug ist, sondern einfach technisch nicht anders umsetzbar ist und daher eben NVIDIA den Aufwand mit dem G-Sync Modul treibt.

[Kriton]

Welches Prinzip meinst Du (ernstgemeinte Frage)? Von der Framedoppelung?

[Grestorn]

Welches Prinzip meinst Du (ernstgemeinte Frage)? Von der Framedoppelung?

Du hast geschrieben "Das ist falsch. Die Framedoppelung von G-Sync ist etwas ganz anderes als ein größerer dynamischer Refreshbereich wie bei FreeSync (der Technik, nicht den verfügbaren Monitoren)."

De fakto führt die dynamische Framevervielfachung zu einem freien Refreshbereich bis 1 fps. Es ist also nicht "etwas ganz anderes".

[Kriton]

Falsch, während FreeSync nicht in der Lage ist den dynamischen Refresh unterhalb der minimalen Panelrefreshrate bei zu behalten und auf V-Sync off schaltet, bleibt G-Sync immer noch aktiv. Ob die Frames dann innerhalb des Monitors vervielfacht (werden müssen), ist ja irrelevant - so deine Behauptung es gehe um die Technik - da die Übertragung innerhalb von G-Sync auch runter bis 1 Hz funktioniert.

Also ENTWEDER AMD hat in der Tabelle die TECHNIK aufgezählt - dann war die Angabe in der G-Sync Spalte falsch - oder sie haben die IMPLEMENTIERUNG aufgezählt - dann ist die FreeSync-Spalte falsch.

Wenn Du die Tabelle verlinken könntest damit wir über dasselbe reden?

Und bei G-Sync sehe ich keine Notwendigkeit die Technik von der Implementierung zu trennen, da es nur eine Implementierung gibt, nämlich mittels des propietären Moduls von Nvidia.


Welchen FreeSync-Monitor ohne Ghosting gibt es denn?

Meine Aussage war z.B. auf Deine Hz-Angaben bezogen.


Außer Behauptungen von Gipsel sehe ich da nichts relevantes. Die Behauptung das ist ein Bug halte ich für mehr als nur schwammig und trotz der Aufdeckung der Problematik bei FreeSync gibt es immer noch keine Ankündigung von AMD diesen Bug zu fixen.

Ich bleibe daher bei meiner Behauptung, dass es kein Bug ist, sondern einfach technisch nicht anders umsetzbar ist und daher eben NVIDIA den Aufwand mit dem G-Sync Modul treibt.

Ich sage es mal so: Nach Gipsels Posts vermag ich zu erkennen (im Rahmen meiner Möglichkeiten), dass er weiß wovon er hier grundsätzlich redet (ich beziehe mich hier ausdrücklich auf seine generellen Posts zu diversen Themen) - das habe ich bei Dir in dieser Tiefe noch nicht gesehen. Daher vertraue ich da eher ihm.

[Kriton]

Du hast geschrieben "Das ist falsch. Die Framedoppelung von G-Sync ist etwas ganz anderes als ein größerer dynamischer Refreshbereich wie bei FreeSync (der Technik, nicht den verfügbaren Monitoren)."

De fakto führt die dynamische Frameverfielfachung zu einem freien Refreshbereich bis 1 fps. Es ist also nicht "etwas ganz anderes".

Berichtige mich wenn ich irre:
Bei der Vervielfachung habe ich doch einen größeren Inputlag, oder?

[Grestorn]

Berichtige mich wenn ich irre:
Bei der Vervielfachung habe ich doch einen größeren Inputlag, oder?

Ohne den seitenweisen Text, die ich dazu geschrieben habe, wiederholen zu wollen: Nein. Nur bei seltenen, einzelnen(!) Frames kann es zu einer zusätzlichen Verzögerung von maximal 7ms (16,7ms bei 60 Hz Displays) des einen Frames kommen.

Ausführlich zuletzt hier beschrieben: http://www.forum-3dcenter.org/vbulletin/showthread.php?p=10583692#post10583692

[Dimitri Mayakovsky]

Wenn Du die Tabelle verlinken könntest damit wir über dasselbe reden?
Wie konntest du mir bisher widersprechen, ohne zu wissen, worum es geht? :freak:

Und bei G-Sync sehe ich keine Notwendigkeit die Technik von der Implementierung zu trennen, da es nur eine Implementierung gibt, nämlich mittels des propietären Moduls von Nvidia.
Warum gibt es dann G-Sync Geräte mit 60 Hz maximaler Refreshrate und manche mit 144?

Meine Aussage war z.B. auf Deine Hz-Angaben bezogen.
Dann macht weder das Zitat, noch deine Aussage Sinn.

Ich sage es mal so: Nach Gipsels Posts vermag ich zu erkennen (im Rahmen meiner Möglichkeiten), dass er weiß wovon er hier grundsätzlich redet (ich beziehe mich hier ausdrücklich auf seine generellen Posts zu diversen Themen) - das habe ich bei Dir in dieser Tiefe noch nicht gesehen. Daher vertraue ich da eher ihm.
Ich schaue mir lieber an, was es so an Fakten gibt, statt zu "vertrauen". Du darfst gern auf Gispsels hellseherischen Fähigkeiten vertrauen, bisher sehe ich kein Indiz für die Behauptung. Im Sommer wissen wir ja mehr, wenn der Bug immer noch besteht, dann habe ich Recht mit meiner Vermutung.

[fondness]

Ohne den seitenweisen Text, die ich dazu geschrieben habe, wiederholen zu wollen: Nein. Nur bei seltenen, einzelnen(!) Frames kann es zu einer zusätzlichen Verzögerung von maximal 7ms (16,7ms bei 60 Hz Displays) des einen Frames kommen.

Ausführlich zuletzt hier beschrieben: http://www.forum-3dcenter.org/vbulletin/showthread.php?p=10583692#post10583692

Naja bei einem 60Hz Monitor ist die zusätzliche Verzögerung nicht gerade unwahrscheinlich sondern die Eintrittswahrscheinlichkeit liegt exakt bei 50% nicht (bei einer angenommen minimalen Refresh-Rate von 30hz)?

[Gipsel]

Das ist alles klar und wurde nie bezweifelt. Aber was Du schreibst klingt zumindest so, als würdest Du meinen, dass GSync - in einigen Fällen oder immer - quasi die vollen 33 ms wartet, bis ein neues Frame angezeigt wird, obwohl ein neues Frame bereits verfügbar ist.Du hast also meinen Text falsch interpretiert, denn sowas habe ich nie geschrieben ;).
Um meinen von Dir eben teilzitierten Satz, mit dem Du offenbar nicht einverstanden bist, in voller Länge zu wiederholen:

"Eine minimale Refreshrate von 33ms gibt es nicht. Bei GSync In keinem Fall"

Damit ist gemeint, dass es keine relevante Untergrenze gibt, bei der GSync die Bilder nicht mehr fast immer (*) in genau der Geschwindigkeit ausgeben kann, in der sie von der Karte berechnet werden. Es gibt also de fakto keine minimale Refreshrate. Punkt.Keine Sorge, daß habe ich schon Alles verstanden. Alles was ich in meinem Eingangspost zu dem Thema (http://www.forum-3dcenter.org/vbulletin/showthread.php?p=10582498#post10582498) getan habe, war auf das "fast immer" (und die Bedingungen dafür) hinzuweisen.
Denn es gibt sehr wohl eine untere Grenze bei GSync (es gibt immer eine minimale Refreshrate, die das Panel physikalisch nicht unterschreiten kann), man versucht sich nur etwas drum rum zu mogeln, so daß man diese möglichst nicht trifft. Dies funktioniert aber nicht immer (das kann es nicht), so daß dies in bestimmten Konstellationen sichtbar wird (dann mit der verzögerten Darstellung eines Frames bei Kollision mit einem Zwangsrefresh), wie Du ja auch selber schreibst.

"Fast immer" ist eben nicht "immer". Und wie oft "fast immer" genau bedeutet, hängt wie von mir dargestellt vom Verlauf der Frametimes ab. Für einen sehr glatten Verlauf, klappt es gut, bei eher ungleichmäßigen (mit +-10% Schwankungen oder mehr) wird es erheblich schwieriger. Schon in meinem Eingangsposting dazu habe ich ja gesagt, in welchen Szenarien es gehäuft vorkommt.
Auf mehr wollte ich wie gesagt in meinem ersten Post dazu gar nicht hinweisen. Du hast das bloß offenbar irgendwie in den falschen Hals bekommen ;).

Wie ich bereits sagte, sind wir uns in der Sache doch praktisch einig. Es besteht also gar kein Grund für einen Streit, nachdem die Mißverständnisse ausgeräumt wurden. :)

[derF]

Du laberst also einfach nur Müll, ganz ungeniert und (fast) unwidersprochen.
Das liegt daran, dass wohl viele es wie Kartenlehrling und ich halten und schon nach seinen ersten Posts im Forum beschlossen haben, dass es sich einfach nicht mehr lohnt.

[Grestorn]

Naja bei einem 60Hz Monitor ist die zusätzliche Verzögerung nicht gerade unwahrscheinlich sondern die Eintrittswahrscheinlichkeit liegt exakt bei 50% nicht (bei einer angenommen minimalen Refresh-Rate von 30hz)?

Bei naiver Betrachtung: in 50% der Fälle ist die Verzögerung 0ms, bei den anderen 50% beträgt sie irgendwas zwischen 1 und 16,7 ms (je nachdem wann die Kollision genau stattfindet).

Nach einer Kollision kann der Freesync Treiber den Zeitpunkt des Wiederholframes aber korrigieren. Klar, wenn sich die Frametime ständig ändert, hilft das nicht immer.

Auf jeden Fall ist es deutlich besser, als alle längeren Frametimes auf maximal 30 ms oder so zu fixieren oder Tearing einzuschalten - das sind die beiden Alternativen, die der Freesync Treiber heute bietet. Und so lange ich nicht vom Gegenteil überzeugt wurde, denke ich, dass AMD das nachbessern kann.

[Ephiriel]

De fakto führt die dynamische Framevervielfachung zu einem freien Refreshbereich bis 1 fps. Es ist also nicht "etwas ganz anderes".
Was für einen Vorteil bietet denn die Frame-Vervielfachung? Es reicht doch aus, sollte kein neues Frame innerhalb der Minimalen Refreshrate fertig werden, das alte nochmal anzuzeigen, oder, sollte während des Wartens ein neues Frame fertig werden, dieses Anzeigen. So in etwa (sehr vereinfacht :tongue:):

if (NewFrameReady == True || TimeSinceLastFrame > MinRefreshRate)
Show_frame();

Da sehe ich jetzt nichts, wodurch Frameverdoppelung einen vorteil bekommen sollte, da sich der Bildschirminhalt sowieso nicht ändert bis ein neues Frame da ist.
Oder vergesse ich jetzt (als Laie :biggrin:) etwas grundlegendes?

[fondness]

Bei naiver Betrachtung: zu 50% ist die Verzögerung 0ms, bei den anderen 50% beträgt sie 1-16,7 ms (je nachdem wann die Kollision genau stattfindet).

Genau so war es gemeint. Ob das dann noch gut aussieht wenn statistisch jedes zweite Bild verzögert ist wage ich dann allerdings zu bezweifeln.

[Kriton]

Wie konntest du mir bisher widersprechen, ohne zu wissen, worum es geht? :freak:

Die Tabelle hast Du erst in Deinem letzten Post erwähnt. Daher verstehe ich Deine Aussage nicht. Verlinken derselben wäre übrigens immer noch sinnvoll.

Warum gibt es dann G-Sync Geräte mit 60 Hz maximaler Refreshrate und manche mit 144?

Ok.

Dann macht weder das Zitat, noch deine Aussage Sinn.

Dann solltest Du es noch einmal im Kontext lesen - d.h. Deine von mir zitierte Aussage + meine Antwort.

Ich schaue mir lieber an, was es so an Fakten gibt, statt zu "vertrauen". Du darfst gern auf Gispsels hellseherischen Fähigkeiten vertrauen, bisher sehe ich kein Indiz für die Behauptung. Im Sommer wissen wir ja mehr, wenn der Bug immer noch besteht, dann habe ich Recht mit meiner Vermutung.

Wieder die Fakten, aber das Ghosting ist AMDs Problem, ja?
Ich habe ja nichts dagegen, dass Du gewisse Ansprüche stellst, aber dann bitte auch durchgehend.

[Gipsel]

Berichtige mich wenn ich irre:
Bei der Vervielfachung habe ich doch einen größeren Inputlag, oder?Meist nur wegen der insgesamt längeren Frametimes aufgrund der niedrigen Frameraten. Die zeigen halt allgemein etwas mehr Lag als 60+ fps. Die zusätzliche Verzögerung bei Kollisionen eines Zwangsrefreshes mit einem neuen Frame (maximal 7ms bei einem 144Hz-Monitor, maximal 17ms bei einem 60Hz-Monitor) treten eben auch nur dann auf, wenn es wirklich zu solchen Kollisionen kommt. Das kann je nach Situation extrem selten sein, im Zweifelsfall aber auch etwas häufiger vorkommen.

[Grestorn]

Wie ich bereits sagte, sind wir uns in der Sache doch praktisch einig. Es besteht also gar kein Grund für einen Streit, nachdem die Mißverständnisse ausgeräumt wurden. :)

Friedenspfeife ... :cool:

[Kriton]

Dann ist meine Aussage, dass eine Framevervielfältigung etwas anderes ist als eine (im entsprechenden Bereich angesiedelte) dynamische Refreshrate doch richtig?

@Grestorn: D.h. Dir ging es darum, dass dies in der Praxis nur verhältnismäßig selten aufkommt bzw. nicht bemerkt wird?

[fondness]

Dann ist meine Aussage, dass eine Framevervielfältigung etwas anderes ist als eine (im entsprechenden Bereich angesiedelte) dynamische Refreshrate doch richtig?


Natürlich wäre es besser wenn der Monitor weiter runter syncen könnte. Deshalb ja auch meine Aussagen wenn es einen Monitor gibt der bis 20Hz dynamisch syncen könnte dann wäre mir das mit der Frameverdoppelung auch schon egal, denn damit fährt man im Grenzbereich besser und unter 20fps ist ohnehin nicht mehr spielbar egal mit welchen Tricks.

[Dimitri Mayakovsky]

Die Tabelle hast Du erst in Deinem letzten Post erwähnt. Daher verstehe ich Deine Aussage nicht. Verlinken derselben wäre übrigens immer noch sinnvoll.
Nö, ich hatte mich von Anfang an auf die Folie bezogen:

http://www.forum-3dcenter.org/vbulletin/showpost.php?p=10583286&postcount=2169

Also frage ich mich jetzt tatsächlich, warum du mir widersprichst, ohne überhaupt zu wissen, worum es geht. Machst du das immer so?

Dann solltest Du es noch einmal im Kontext lesen - d.h. Deine von mir zitierte Aussage + meine Antwort.
In dem Teil meines Posting, das du zitiert hattest, ging es um Ghosting, jetzt plötzlich möchtest du mit deiner Antwort darauf dich auf Frequenz zu beziehen.

Wo ist da der Kontext, der Sinn ergeben soll?

Wieder die Fakten, aber das Ghosting ist AMDs Problem, ja?
Ich habe nirgendwo geschrieben, dass es AMDs Problem sein soll. Ich habe nur gesagt, solange es keinen Ghosting-freien FreeSync Monitor gibt, möchte ich nicht direkt die Monitorhersteller als Schuldigen hinstellen.

Das ist eben auch was mit Fakten. Ihr verurteilt die Monitorhersteller, damit AMD besser da steht. Ich verweigere mich dieser schnellen Verurteilung.

Ich habe ja nichts dagegen, dass Du gewisse Ansprüche stellst, aber dann bitte auch durchgehend.
Das tue ich, deswegen vertraue ich hier eben keinem User, sondern hätte gern entsprechende Fakten bzw. zumindest Indizen gesehen.

Dann ist meine Aussage, dass eine Framevervielfältigung etwas anderes ist als eine (im entsprechenden Bereich angesiedelte) dynamische Refreshrate doch richtig?
Nein, der Monitor ist immer noch im dynamischen Bereich (anders eben als bei FreeSync), zeigt aber eben Frames mehrfach an, bevor er gar nichts anzeigen kann.

[maximus_hertus]

Ich habe nirgendwo geschrieben, dass es AMDs Problem sein soll. Ich habe nur gesagt, solange es keinen Ghosting-freien FreeSync Monitor gibt, möchte ich nicht direkt die Monitorhersteller als Schuldigen hinstellen.

Das ist eben auch was mit Fakten. Ihr verurteilt die Monitorhersteller, damit AMD besser da steht. Ich verweigere mich dieser schnellen Verurteilung.


Warum gibt es das Ghosting auch im "normalen" (nicht Sync Modus) mit GeForce und Radeonkarten? Wenn man einen Free-Sync TFT mit einer GF Karte ohne Sync nutzt, ist AMD komplett raus aus der "Schuldfrage". Dennoch gibt es Ghosting.

Umkehrschluß => Egal, wer "Schuld" ist, man kann definitv sagen, dass AMD da nichts machen kann bzw. Free-Sync nichts damit zu tun hat.

[Gipsel]

Naja bei einem 60Hz Monitor ist die zusätzliche Verzögerung nicht gerade unwahrscheinlich sondern die Eintrittswahrscheinlichkeit liegt exakt bei 50% nicht (bei einer angenommen minimalen Refresh-Rate von 30hz)?
Bei naiver Betrachtung: in 50% der Fälle ist die Verzögerung 0ms, bei den anderen 50% beträgt sie irgendwas zwischen 1 und 16,7 ms (je nachdem wann die Kollision genau stattfindet).Bei einer VRR-Range von 30-60Hz wird das schon mächtig eng, da man nicht wie z.B. bei 30-144Hz GSync-Monitoren eine Art "grace period" vorhalten kann also eine Art Puffer zum maximalen Refreshintervall des Panels. Das Problem ist nun, daß man ohne wilkürliche Delays wirklich auf die maximalen 33,3ms zwischen zwei Refreshes hochgehen muß, bevor man das vorzeitige Einschieben eines Refreshes (nach der halben Frametime des vorherigen Frames) anfangen kann (bei den 30-144Hz Monitoren passiert dies ja bereits früher, bei Unterschreitung von 5/6 des maximalen Refreshintervalls, also ~27,8ms). Schwankt es jetzt um die 30fps, ist das praktisch der ungünstigste Fall. Es kann selbst bei beinahe glatten Frametimes im echten worst case bei jedem zweiten Frame zum Zusatzdelay von 16,6ms kommen. Das sollte einen relativ schlechten Eindruck abliefern.

Die Alternativstrategie könnte sein, mutwillig ein Delay einzufügen, so die Framerate bereits oberhalb der 30fps etwas zu limitieren, praktisch immer Zusatzdelays durch Framekollisionen zu haben, diese aber konsistenter und niedrig zu halten.
Beispiel:
Frametimes betragen 30ms (33,3fps). An bzw. unter dieser Schwelle fängt man mit vorzeitigen Refreshes mit wiederholten Frames nach genau 16,7ms an (halbe Frametime=15ms geht nicht, weil das zu schnell wäre). Die Framerate fällt dann auf 30fps, aber die Verzögerungen durch die Kollisionen mit der wiederholten Übertragung des alten Frames betragen dann nur um die 3ms. Man schafft sich also den Puffer auf Kosten einer leicht abgesenkten Framerate im Übergangsbereich, um die 16ms Spikes beim Zusatzdelay zu vermeiden. Das funktioniert natürlich auch am besten bei möglichst glatten Frametimes.
Aber eigentlich ist wirklich ein 30-72/75Hz-Monitor wünschenswert, dann kann man schon vor Erreichen des maximalen Refreshintervalls im jeweils nächsten Frame der vorzeitige Refresh begonnen werden, ohne daß man dadurch Wartezeiten einbaut.

[Kriton]

Nö, ich hatte mich von Anfang an auf die Folie bezogen:

http://www.forum-3dcenter.org/vbulletin/showpost.php?p=10583286&postcount=2169

Also frage ich mich jetzt tatsächlich, warum du mir widersprichst, ohne überhaupt zu wissen, worum es geht. Machst du das immer so?

Manch einer könnte sich ja fragen warum ich gefühlt der einzige bin, der auf Deine Posts noch reagiert, aber na ja.

Da Du Deinen Post verlinkt hast, hier noch einmal der quote:

Besser konnte man AMD ja nicht vorführen. Und deren Marketingtricks waren ja auch schon hart an der Grenze, ich erinnere mich da nur an die Folie mit einem behaupteten Framerate-Spektrum von "9-200Hz" für FreeSync, obwohl das nur in Abstufungen möglich ist, also 9-60, 12-75 usw.

Ich bezog mich eindeutig auf den (durch mich) fett markierten Teil. Warum ich da gefühlte 20 Posts später noch wissen muss, dass Du im selben Atemzug eine Folie erwähnt hast, die die offiziellen Specs erwähnt (die ich aus der Erinnerung sowieso kenne) und was das damit zu tun hat, dass Deine Aussage falsch ist: Keine Ahnung.


In dem Teil meines Posting, das du zitiert hattest, ging es um Ghosting, jetzt plötzlich möchtest du mit deiner Antwort darauf dich auf Frequenz zu beziehen.

Wo ist da der Kontext, der Sinn ergeben soll?

Es geht darum, dass Du mit zweierlei Maß misst - der Frequenzbezug war auch schon in meinem 1. Post da, deswegen auch meine Aussage dort "Siehe meine Aussage zur Differenzierung", die sich offenkundig auf das Frequenzthema bezog.
Aber ich gebe zu, dass Deine Formulierung hinsichtlich der Monitore und dem Ghosting nicht falsch war. Sogar geschickt im Hinblick darauf, dass man dies als Mangel von Freesync und nicht den Monitoren verstehen kann. Aber so einen Eindruck wolltest Du natürlich nicht vermitteln.

Schon gar nicht bei solchen Posts:

Unabhängig vom konkreten Delay, solange FreeSync nicht in der Lage ist auch mit Frameraten unterhalb der minimal notwendigen Refreshrate des Panels umzugehen, ist die Technik schlicht nicht gleichwertig zu G-Sync. Ganz einfach.

Dass es einfach nur ein Bug ist, halte ich für ziemlich unwahrscheinlich. So ein massiver Fehler, bei der Haupfunktionalität? Das soll keiner vorher getestet haben?

Zumindest wissen wir jetzt, dass G-Sync eben doch deutlich mehr ist, als uns AMD das immer verkaufen wollte.

Da kann man ja schon mal Dinge sagen auch ohne die Fakten zu kennen. Oder mißverstehe ich hier "halte ich für"?

Nein, der Monitor ist immer noch im dynamischen Bereich (anders eben als bei FreeSync), zeigt aber eben Frames mehrfach an, bevor er gar nichts anzeigen kann.

Vielleicht reden wir hier aneinander vorbei. Mir geht es darum, dass technisch eine dynamische Refreshrate (also die Ausgabe eines neuen Frames sobald dieser verfügbar ist) anders funktioniert (weil nur tatsächlich neue frames angezeigt werden) als eine Vervielfachung eines bereits gezeigten frames um eine gewisse Bildwiederholrate zu erreichen.

[PHuV]

Aber eigentlich ist wirklich ein 30-72/75Hz-Monitor wünschenswert, dann kann man schon vor Erreichen des maximalen Refreshintervalls im jeweils nächsten Frame der vorzeitige Refresh begonnen werden, ohne daß man dadurch Wartezeiten einbaut.
Dann hätten wir doch aber das Problem, daß permanent Frequenzänderungen nötig wären, und das wäre doch sichtbar. Um dann wirklich flüssige Bilddarstellungen zu haben, müßte man sich vorher auf eine gewisse Frequenz einigen, und dann konsequent diese einhalten. Wie ich bereit mehrfach schrieb, der Mensch reagiert am heftigsten in der Wahrnehmung bei Änderungen, besonders optisch.

[Unicous]

@Dimitri@FUDSpreading

Tom Peterson sagt, dass es kein Limit für (die) Adapative Sync (Spec) gibt (was auch EXTREMVULKANIERLOGISCH ist). Ich wiederhole es gerne und oft. (Ich werde keine Quelle angeben, denn du tust das ja auch nicht.;))

Irgendjemand muss doch gegen deinen FUD antreten.


Und hier noch ein Service für dich.

What is the supported range of refresh rates with AMD FreeSync™ technology and DisplayPort Adaptive-Sync?

​AMD Radeon™​ graphics cards will support a wide variety of dynamic refresh ranges with AMD FreeSync™ technology. Using DisplayPort Adaptive-Sync, the graphics card can detect and set an appropriate maximum and minimum refresh rate based on the capabilities reported by the display. Potential ranges include 36-240Hz, 21-144Hz, 17-120Hz and 9-60Hz.

[aufkrawall]

Und ja, man braucht bei FreeSync identische Monitore. Bei G-Sync glaube ich auch.
Laut den Release Notes des Linux-Treiber r349, soll auch ein Gemischtbetrieb möglich sein.

[Unicous]

Ging es da nicht um "Gemischtbetrieb" G-Sync/Nicht G-Sync?

Kannst du das mal verlinken bzw. zitieren?

[Kriton]

Meine Frage ist, warum du mit mir darüber diskutieren möchtest, was AMD da nun konkret angegeben hat, ohne die konkrete Folie zu kennen. Was du ja offensichtlich nicht tust.

Also kannst du ja auch gar nicht wissen, ob AMD nun ihre Technik erklärt hat, oder die konkrete Implementierung. Du widersprichst mir also per se, ohne überhaupt zu wissen, worum es konkret geht.

Daher hast du mit einer Aussage tatsächlich Recht: Du hast keine Ahnung.

Ok, EoD. Du willst oder kannst es offenbar nicht verstehen. Das war Deine Aussage:

Besser konnte man AMD ja nicht vorführen. Und deren Marketingtricks waren ja auch schon hart an der Grenze, ich erinnere mich da nur an die Folie mit einem behaupteten Framerate-Spektrum von "9-200Hz" für FreeSync, obwohl das nur in Abstufungen möglich ist, also 9-60, 12-75 usw.

Wenn mir jemand anderes erklären kann wozu man die konkrete Folie gesehen haben muss (deren insoweit hier relevanter Inhalt benannt wird) um sagen zu können, das die Aussage mit den Abstufungen falsch ist kriegt ´nen Keks. Und ich verweise in diesem Zusammenhang noch einmal auf die Differenzierung zwischen Technik und Implementierung.
Und für Dich: Ich hatte nach der Folie gefragt, weil ich nicht mehr wusste worauf Du Dich insoweit bezogen hattest (hätte ich Deinen Post wieder rausgesucht hätte ich es gewusst) - weil der wichtige Punkt eben nicht ist, dass Du dich an eine Folie erinnerst (deren Inhalt Du später nicht mehr benannt hast, sondern nur noch "eine" Folie erwähntest), sondern, dass AMD 9-200 Hz angegeben hat (von mir aus auch auf einer Folie die Du gesehen hast).

[aufkrawall]

Ging es da nicht um "Gemischtbetrieb" G-Sync/Nicht G-Sync?

Kannst du das mal verlinken bzw. zitieren?
Added support for G-SYNC monitors when used together with non-G-SYNC monitors. When G-SYNC is enabled, non-G-SYNC monitors will display with tearing.
https://devtalk.nvidia.com/default/topic/821171/unix-graphics-announcements-and-news/linux-solaris-and-freebsd-driver-349-12-beta-/

[Unicous]

@Kriton

Es geht ihm doch gar nicht um die Sache. Es geht ihm ums Stänkern. Substanz suchst du in seinen Posts vergeblich. Wenn man ihn darauf anspricht versucht er einem die Wörter im Mund umzudrehen um als strahlender Troll-Held dazustehen.


@aufkrawall

Aber es ging doch um G-Sync Surround?

[aufkrawall]

Das hab ich wohl automatisch übersehen, weil ich Surround furchtbar für die meisten Spielarten finde. :redface:

[Kriton]

Etwas OT, aber: Warum? Gerade im PvP kann ich mir das doch interessant vorstellen zu wissen von wo ggf. die Geräusche meines Gegners kommen.

[Gipsel]

Dann hätten wir doch aber das Problem, daß permanent Frequenzänderungen nötig wären, und das wäre doch sichtbar. Um dann wirklich flüssige Bilddarstellungen zu haben, müßte man sich vorher auf eine gewisse Frequenz einigen, und dann konsequent diese einhalten. Wie ich bereit mehrfach schrieb, der Mensch reagiert am heftigsten in der Wahrnehmung bei Änderungen, besonders optisch.Solange man halbwegs glatte Frametimeverläufe hat, geht das hinreichend gut. Und Frequenzänderungen (besser ist eigentlich von variablen Frametimes bzw. variablen Zeitspannen zwischen Refreshes zu reden) sollten nur klar sichtbar sein, wenn man außerhalb (oder sagen wir mal am Rand) der Möglichkeiten des Panels ist. Wenn die Pixel die Bildinformationen natürlich nicht 33ms nahezu unverändert halten können (weswegen offenbar die meisten FreeSync-Monitore erst bei 40Hz, also 25ms maximalem Intervall anfangen, bei GSync gibt es ja durchaus Berichte, daß es bei einigen Monitoren sichtbar wird), dann bekommt man Probleme. Mit entsprechend ausgelegten Panels, sollten keine Helligkeits- oder Farbveränderungen über die maximale Dauer des Refreshzyklus sichtbar sein. Vielleicht legen die Panelhersteller ja zukünftig mehr Wert auf längere Haltezeiten. Die Techniken dazu gibt es ja durchaus. Sie müssen nur genutzt werden.

[Gipsel]

Dies ist jetzt die letzte Ermahnung (@Dimitri und seine Gesprächspartner). Nachdem die vorherige (https://www.forum-3dcenter.org/vbulletin/showthread.php?p=10583636#post10583636) offenbar untergegangen ist, werden bei weiterer Mißachtung härtere Maßnahmen ergriffen.

[Troyan]

Genau so war es gemeint. Ob das dann noch gut aussieht wenn statistisch jedes zweite Bild verzögert ist wage ich dann allerdings zu bezweifeln.

Es wird nicht jedes zweite Bild verzögert. Das ganze ist ein dynamischer Prozess basierend auf der "Vorahnung", wie lange das nächste Frame benötigen werde.
Durch die Frameverdopplung erhöht sich auch der Zeitbereich, bevor man neu refreshen muss - z.B. wenn man alle 28ms refreshen muss, dann könnte man 14ms - 14ms - 42ms haben.

[Gipsel]

Es wird nicht jedes zweite Bild verzögert. Das ganze ist ein dynamischer Prozess basierend auf der "Vorahnung", wie lange das nächste Frame benötigen werde.
Durch die Frameverdopplung erhöht sich auch der Zeitbereich, bevor man neu refreshen muss - z.B. wenn man alle 28ms refreshen muss, dann könnte man 14ms - 14ms - 42ms haben.Es ging da spezifisch um einen 60Hz-Monitor (also z.B. 30-60Hz VRR-Range), da kann man nicht mal so nach 14ms refreshen ;). Das muß dann schon im Bereich zwischen 16,7ms und 33,3ms bleiben. Da hat man dann im Zweifelsfall keinen wirklichen Spielraum bei einer Frameverdopplung. Das muß exakt passen. Da gibt es keinen Puffer wie bei den 30-144Hz Versionen (6,9-33,3ms Bereich für Frametime), bei dem die vorzeitige Framewiederholung davon ausgelöst wird, daß der vorherige Frame länger als 27,8ms benötigt hat. Da hat man dann sowohl noch gute 5ms Puffer für den ersten Frame (die Frametimeschwankungen sollten also möglichst nicht größer als das sein) und nach oben trifft man auch kein Limit. Für diese Technik (man könnte den Puffer auch noch etwas größer machen) benötigt man aber einen variablen Bereich, der größer als Faktor 2 ist (also z.B. mindestens 30-72Hz, 60-144 würden im Prinzip aber auch gehen, ein größerer "Puffer" zu den eigentlichen Refreshlimits macht das System etwas unempfindlicher gegenüber Frametimeschwankungen).

[aufkrawall]

Etwas OT, aber: Warum? Gerade im PvP kann ich mir das doch interessant vorstellen zu wissen von wo ggf. die Geräusche meines Gegners kommen.
Ich will meinen Kopf nicht drehen müssen und Lücken und Balken + LCD-Blickwinkelartefakte sind schon eine ziemliche Beeinträchtigung.
Kommen noch hohe Kosten, Renderkosten, Treiber-Bugs und Platzgründe dazu...