Archiv verlassen und diese Seite im Standarddesign anzeigen : nVidia - geforce 8800gts mit mauslag bei vert. sync.?!?!?!
riotkid
2008-03-21, 02:37:01
hallo, eigentlich is alles ok mit der gpu, aber wenn ich vertical sync aktiviere habe ich mauslag, was mich wahnsinning macht, da die verzögerung mindestens gefühlte 30 sekunden ist. ist das normal und wenn ja warum nicht? kann mich an meine ati gpus erinnern, da war das nicht so oder ich war unempfindlicher, was ich aber nicht glaube. ich hoffe jedenfalls, das es für dieses phänomen zumindest eine erklärung gibt, und so möglich auch eine lösung, oder wenigstens einen kompromiß.
in froher erwartung euer rk
Falls die gefühlten 30 Sekunden - ähm - dezent *hüstel* übertrieben sind liegts am erzwungenen TB (macht NV seit einiger Zeit immer bei aktivem Vsync, egal, was man im Spiel einstellt). Der bringt aber nur einen Frame Lag ein. Wenn der dann auf den Lag durch Overdrive-TFT und Funkmaus oben drauf kommt kann es schon sein, dass dieser eine zusätzliche Frame Lag den Unterschied ausmacht ob man das Gefühl hat "wie am Gummiband" zu spielen oder nicht.
Wenn der Lag durch TB für dich den Unterschied ausmacht wäre es eine Überlegung wert, wieder zu ATI zurückzukehren. Bei denen kann man TB erzwingen, kann es aber auch lassen. Nur lass die Finger von SLI/CF und den Doppel-GPU-Karten. Durch AFR hast du den gleichen Effekt wie durch TB, nur noch schlimmer.
Schon probiert, per Rivatuner oder nHancer das Prerenderlimit auf 1 zu setzen?
danke für den tipp. bei prerender limit 0 hängt sich der rechner auf! bei 1 ist es etwas besser aber trotzdem noch spürbar, ohne meine ganze konzentration darauf zu fixieren. das mit dem gummiband ist übrigens 'ne gute beschreibung für dieses phänomen. tja, es nervt zwar ohne vert. sync. zu spielen - wegen meines tfts, aber wat will man machen, dann muss ich bei shootern eben ohne spielen. zum glück habe ich keine funkmaus, ansonsten wäre das gummiband wohl eher ein ausgelutschter kaugummi. da ich aber leider nicht krösus bin oder senil, werde ich mir deswegen jetzt keine neue ati gpu kaufen, werde dies aber bei der nächsten gpu in betracht ziehen, jedensfalls so oder so ähnlich.
p.s.was tb und afr ist, liegt weit ausserhalb meines gedanklichen horizonts, vermutlich wäre es aber nicht der mühe wert, mir auch noch darüber gedanken zu machen - vsync, sli/cf und windows reicht schon vollkommen - denn ich will ja eigentlich auch nur spielen. ;-)
TB ist die Abkürzung von Triple Buffering. Dabei wird ein zusätzlicher Backbuffer benutzt um zu vermeiden, dass die FPS wie bei aktivem Vsync und Double Buffering immer auf ganze Teiler der Hz einbrechen. Dadurch können mehr Bilder pro Sekunde berechnet werden weil Wartezeiten für die GPU wegfallen, die berechneten Bilder werden allerdings verspätet und unregelmäßiger ausgegeben.
AFR (Alternate Frame Rendering) ist der Modus, in dem MultiGPU-Systeme meist laufen. Dabei berechnet jede GPU ein vollständiges Bild ohne Hilfe der anderen im System befindlichen GPUs. Allerdings erzeugt jede zusätzliche mit AFR betriebene GPU einen zusätzlichen Frame Lag, zudem kommen die Frames noch unregelmäßiger als mit TB.
da ich aber leider nicht krösus bin oder senil, werde ich mir deswegen jetzt keine neue ati gpu kaufen, werde dies aber bei der nächsten gpu in betracht ziehen, jedensfalls so oder so ähnlich.
vsync ohne triple-buffer ist auch eine sehr schlechte idee, die unregelmäßigen frameraten würden wesentlich mehr stören als der zusätzliche lag.
ich würde vsync nur aktivieren wenn die grafikkarte konstant frameraten oberhalb der refreshrate des monitors liefern kann, dann kannst du auch ruhig TP aktivieren, das ergibt dann keine zusätzliche verzögerung.
Spasstiger
2008-03-23, 21:13:38
VSync mit Triplebuffering bringt leider auch Mikroruckler, nur nicht ganz so schlimm wie bei SLI oder Crossfire.
mike49
2008-03-24, 00:04:20
VSync mit Triplebuffering bringt leider auch Mikroruckler, nur nicht ganz so schlimm wie bei SLI oder Crossfire.
Gibt es da auch Frametime-Messungen zu?
Das Triple-Buffering sollte eigentlich 'nur' einen kleinen Timelag bringen.
Johnny Rico
2008-03-24, 01:49:57
Heutzutage ist mal halt gefickt, egal was man macht.
Overdrive + SLI/CF + AA + TB-VS + Prerender = Gummiband³³³³³³ (wer weis wieviel genau?)..
Nen TFT ohne Overdrive und 1 GPU mit viiiiiel Powa wär was schönes, dazu ein TFT ohne Tearing *achja*
Ein reaktionsschneller (=Overdrive wird nicht benötigt) TFT mit >= 100Hz und nativem Kontrast von >10000:1 würde schon reichen um quasi perfekt ohne Vsync und Lags zu zoggn! :)
Die einzige andere Lösung wäre, das der TFT variabel mit 0-60Hz direkt an die Graka gekoppelt wäre. Quasi Bildausgabe auf Nachfrage.
vsync ohne triple-buffer ist auch eine sehr schlechte idee, die unregelmäßigen frameraten würden wesentlich mehr stören als der zusätzliche lag....weswegen man entweder auf Vsync verzichten sollte oder das Spiel so einstellen, dass es konstante FPS liefert. Konstante 30 FPS sind zumindest mir lieber als die flatterhafte Verteilung von 50 FPS auf 60 an den Monitor geschickte Bilder. Ob man TB einsetzen möchte oder nicht sollte dem Spieler überlassen bleiben, denn sowohl dafür als auch dagegen gibt es ein ansehnliches Häuflein vernünftiger Argumente.
ich würde vsync nur aktivieren wenn die grafikkarte konstant frameraten oberhalb der refreshrate des monitors liefern kann, dann kannst du auch ruhig TP aktivieren, das ergibt dann keine zusätzliche verzögerung.Genau andersrum. Wenn die FPS den ausgegebenen Hz entsprechen hast du den Zusatzlag durch TB garantiert, nur wenn die FPS unter die ausgegebenen Hz fallen kann man Fälle konstruieren, in denen durch TB kein Zusatzlag entsteht.
Spasstiger
2008-03-27, 14:32:11
Gibt es da auch Frametime-Messungen zu?
Das Triple-Buffering sollte eigentlich 'nur' einen kleinen Timelag bringen.
Die Frametimes brauchst du da nicht zu messen, die kann ich dir vorhersagen. Angenommen, deine Framerate liegt stets zwischen 30 und 60 fps. Dann sehen die Zeitabstände zwischen den einzelnen Frames z.B. so aus:
16 ms - 33 ms - 33 ms - 16 ms - 16 ms - 16 ms - 33 ms - 33 ms - 33 ms -16 ms - 33 ms - 16 ms - 33 ms - 33 ms etc.
Eine verzögerte Ausgabe ist bei Triple-Buffering prinzipiell übrigens nicht erforderlich, zumindest nicht in der Theorie. Obs in der Praxis dennoch gemacht wird, weiß ich nicht.
Die Frametime-Sprünge sorgen auf jeden Fall für das indirekte Gefühl bei aktivem VSync + Triple-Buffering.
Mr. Lolman
2008-03-27, 14:42:13
16 ms - 33 ms - 33 ms - 16 ms - 16 ms - 16 ms - 33 ms - 33 ms - 33 ms -16 ms - 33 ms - 16 ms - 33 ms - 33 ms etc.
Das ist Doublebuffering.
EDIT: Doch nicht. Hoppla :eek:
Wobei TB bei halbwegs konstanten fps mehr so aussieht (als ein eher frameweises Auftreten der Spitzen):
16 ms - 16 ms - 33 ms - 16 ms - 16 ms - 16 ms - 33 ms - 16 ms - 16 ms -16 ms - 33 ms - 16 ms - 16 ms - 16 ms
Eine verzögerte Ausgabe ist bei Triple-Buffering prinzipiell übrigens nicht erforderlich, zumindest nicht in der Theorie. Obs in der Praxis dennoch gemacht wird, weiß ich nicht.
Die Frametime-Sprünge sorgen auf jeden Fall für das indirekte Gefühl bei aktivem VSync + Triple-Buffering.
Naja, ne Verzögerung von 1 Frame gibts ggü Doublebuffering schon...
Spasstiger
2008-03-27, 14:48:15
Naja, ne Verzögerung von 1 Frame gibts ggü Doublebuffering schon...
Das wird gerne behauptet, weil sich das Gezocks damit indirekter anfühlt, was aber imo an den Frametimes liegt.
Ich hab VSync + TB mal theoretisch durchgespielt und keinen Grund dafür gefunden, warum man die Ausgabe um einen weiteren Frame verzögern müsste. Bisher hab ich auch keine offizielle Aussage gefunden, dass TB definitiv die Ausgabe verzögert. Wenn ich mit VSync + TB zocke, fühlt es sich ab 60 fps genauso flüssig und direkt an wie ohne VSync und ohne TB, nur dass ich kein ekliges Tearing hab.
Wobei TB bei halbwegs konstanten fps mehr so aussieht (als ein eher frameweises Auftreten der Spitzen):
16 ms - 16 ms - 33 ms - 16 ms - 16 ms - 16 ms - 33 ms - 16 ms - 16 ms -16 ms - 33 ms - 16 ms - 16 ms - 16 ms
Das hängt von der durchschnittlichen Framerate ab. Mein obiges Szenario tritt genauso auf bei schwankenden Frameraten.
Mr. Lolman
2008-03-27, 14:59:02
Das wird gerne behauptet, weil sich das Gezocks damit indirekter anfühlt, was aber imo an den Frametimes liegt.
Ich hab VSync + TB mal theoretisch durchgespielt und keinen Grund dafür gefunden, warum man die Ausgabe um einen weiteren Frame verzögern müsste. Bisher hab ich auch keine offizielle Aussage gefunden, dass TB definitiv die Ausgabe verzögert. Wenn ich mit VSync + TB zocke, fühlt es sich ab 60 fps genauso flüssig und direkt an wie ohne VSync und ohne TB, nur dass ich kein ekliges Tearing hab.
Naja, die zusätzlichen 16ms merkt man wohl nicht so(fort). Bei TB ist ja so, dass noch 1 Backbuffer dazukommt. D.h. es müssen vorm Pageflip erstmal beide Backbuffer gefüllt sein damit man die Vorteile des dritten auch nutzen kann. Flipt man gleich nach dem ersten fertigen Frame bräuchte man ja den 3. Puffer garnicht.
Das hängt von der durchschnittlichen Framerate ab. Mein obiges Szenario tritt genauso auf bei schwankenden Frameraten.
Das stimmt natürlich. Nur spricht das wohl nicht sehr für die jew. Engine wenn die Frametimes regelmässig innerhalb einer Sekunde so schwanken.
Naja, ne Verzögerung von 1 Frame gibts ggü Doublebuffering schon...Schätze mal er meinte, dass man TB auch anders implementieren könnte. Dann hätte man den Lag nicht mehr, die FPS könnten auch über die Hz des Monitors steigen. Und ich habe ehrlich keine Ahnung, warum TB nicht so umgesetzt wird, weil mir irgendwie keine Nachteile dafür einfallen, beim Bufferswap statt in einer festen Reihenfolge vorzugehen einfach den neuesten vollständig berechneten Backbuffer zum Frontbuffer zu machen.
Spasstiger
2008-03-27, 15:05:41
Naja, die zusätzlichen 16ms merkt man wohl nicht so(fort). Bei TB ist ja so, dass noch 1 Backbuffer dazukommt. D.h. es müssen vorm Pageflip erstmal beide Backbuffer gefüllt sein damit man die Vorteile des dritten auch nutzen kann. Flipt man gleich nach dem ersten fertigen Frame bräuchte man ja den 3. Puffer garnicht.
Man flippt halt dann, wenn irgendwo ein Frame fertig ist, die Reihenfolge ist doch egal. Siehe Gast. Aber wenn es wirklich in einer festen Reihenfolge implementiert ist, dann kann ich das mit dem Lag nachvollziehen. Dann scheine ich halt nur relativ unempfindlich dafür zu sein (wobei ich den Lag durch TFT-Overdrive im Direktvergleich zum CRT schon wahrnehme).
Das stimmt natürlich. Nur spricht das wohl nicht sehr für die jew. Engine wenn die Frametimes regelmässig innerhalb einer Sekunde so schwanken.
Wirf halt mal Fraps an. ;)
/EDIT: Ich stelle gerade fest, dass Fraps die TB-Mikroruckler gar nicht festhalten kann. Es werden wohl brav die Zeiten gespeichert, zu denen ein Frame fertig in den Framebuffer geschrieben wird, aber nicht die Zeiten, zu denen der Frame tatsächlich auch ausgegeben wird.
Man flippt halt dann, wenn irgendwo ein Frame fertig ist, die Reihenfolge ist doch egal. Siehe Gast.Fast. Bei jedem Vsync würde man checken, welcher der drei Buffer (also beide Backbuffer + Frontbuffer) der neueste ist und diesen zum Frontbuffer machen.
Aber wenn es wirklich in einer festen Reihenfolge implementiert ist, dann kann ich das mit dem Lag nachvollziehen. Dann scheine ich halt nur relativ unempfindlich dafür zu sein (wobei ich den Lag durch TFT-Overdrive im Direktvergleich zum CRT schon wahrnehme).Ist halt nur ein Frame Lag, nicht bis zu 4 Frames Lag wie durch manche Overdrive-TFTs...
Zur Messung...
Ich sage schon seit einer kleinen Ewigkeit, dass man andere Testmethoden braucht, bei denen nicht das zu testende Gerät gleichzeitig die Messgerätschaft darstellt. Z.B. mit einer HDMI-Capturing-Karte (nicht billig, aber bezahlbar) sollte dies wenigstens für größere Seiten und Printmagazine möglich sein.
Man flippt halt dann, wenn irgendwo ein Frame fertig ist, die Reihenfolge ist doch egal.
Das musst du mir jetzt erklären.
Spasstiger
2008-03-27, 15:51:27
Das musst du mir jetzt erklären.
Natürlich zum VSync. War etwas salopp formuliert, sorry.
Ich versteh immer noch nicht wie du Triple-Buffering ohne weiteres Framelag machen willst.
Da ist auch nix zu verstehen, weil es nicht geht.
Spasstiger
2008-03-27, 16:01:53
Ich versteh immer noch nicht wie du Triple-Buffering ohne weiteres Framelag machen willst.
Ich frage mich eher, warum man TB mit Framelag macht.
Mit TB stellt man drei statt zwei Buffer zur Verfügung. Diese werden in zufälliger Reihenfolge gefüllt, je nachdem, welcher gerade frei ist. Zum VSync wird einfach der zuletzt fertig gewordenen Buffer an den Ausgang gelegt. Wo müsste man da warten?
Wieviele Prerender-Frames brauch ich denn, um TB nutzen zu können? Beantworte das und du weisst, wo der Lag herkommt.
Spasstiger
2008-03-27, 16:17:13
Wieviele Prerender-Frames brauch ich denn, um TB nutzen zu können?
Keinen?!
Angenommen, alle Frames brauchen zur Berechnung 20 ms, der Bildschirmrefresh kommt alle 16,6 ms. Die Buffer heißen A, B und C. Alle Buffer sind leer. Nach 20 ms ist Buffer A (Backbuffer) voll, nach 33,3 ms wird dieser zum Frontbuffer. Derweil hat die Grafikkarte schon 13,3 ms lang in Buffer B gerendert. Nach 40 ms ist B voll, es wird in C gerendert (der bis 33,3 ms noch Framebuffer war). Nach 50 ms kommt ein weiterer Refresh, B wird zum Frontbuffer, A zum Backbuffer. Nach 60 ms ist C voll, es wird in A gerendert. Nach 66,6 ms wird C zum Frontbuffer und B wieder zum Backbuffer. Usw.
Keinen?!
Nach 20 ms ist Buffer A (Backbuffer) voll, nach 33,3 ms wird dieser zum Frontbuffer. Derweil hat die Grafikkarte schon 13,3 ms lang in Buffer B gerendert.
Wie soll die Graka schon 13,3 ms in Buffer B rendern, wenn sie keine Daten zum Rendern bekommen hat, weil du ja der Meinung bist, dass man keine Prerender-Frames braucht?
Also, nächster Versuch: wieviel Prerender-Frames braucht man für TB?
Ich frage mich eher, warum man TB mit Framelag macht.
Mit TB stellt man drei statt zwei Buffer zur Verfügung. Diese werden in zufälliger Reihenfolge gefüllt, je nachdem, welcher gerade frei ist. Zum VSync wird einfach der zuletzt fertig gewordenen Buffer an den Ausgang gelegt. Wo müsste man da warten?
Man muss warten, weil man sonst die gleichmäßige Verteilung der Frametimes wieder nicht hat.
Spasstiger
2008-03-27, 16:32:45
Wie soll die Graka schon 13,3 ms in Buffer B rendern, wenn sie keine Daten zum Rendern bekommen hat, weil du ja der Meinung bist, dass man keine Prerender-Frames braucht?
Wie meinen? Die Graka braucht doch keine 16,6 ms, um einen Rendervorgang zu starten.
Man muss warten, weil man sonst die gleichmäßige Verteilung der Frametimes wieder nicht hat.
Die hat man doch eh nicht.
Also, nächster Versuch: wieviel Prerender-Frames braucht man für TB?Prerenderlimit ist eine andere Baustelle. Wie das "Pre" bereits andeutet bezieht es sich auf eine Latenz, die vor dem Beginn des Renderings anfällt. Ob die gerenderten Frames vor der Darstellung jetzt bei TB noch einen weiteren Frame zwischengelagert werden oder nicht ist für das Prerenderlimit vollkommen irrelevant.
Die hat man doch eh nicht.
Also erstmal, man implementiert Triple-Buffering wirklich immer als Chain.
Ich hab mal nochmal darüber nachgedacht und es liegt wohl daran, dass man keine Frames verlieren darf wenn diese kürzer sind als ein Monitor-Frame.
So ganz trivial wie du dir das vorstellst ist es in dem Fall nämlich nicht mehr.
Spasstiger
2008-03-27, 16:58:39
Ich hab mal nochmal darüber nachgedacht und es liegt wohl daran, dass man keine Frames verlieren darf wenn diese kürzer sind als ein Monitor-Frame.
So ganz trivial wie du dir das vorstellst ist es in dem Fall nämlich nicht mehr.
Ich hab immer gedacht, dass in dem Fall (Renderdauer kürzer als Monitorframe) einfache beide Backbuffer voll sind und die Renderpipeline angehalten wird.
Ok, die IHVs werden ihre Gründe haben, warum sie bei Triple-Buffering gegenüber Double-Buffering ein zusätzliches Framelag einbauen, aber ich denke, dass man theoretisch auch ohne auskommt. Niemand hier, der sich mal im Rahmen seines Studiums oder beruflich mit Triple-Buffering-Implementierungen auseinandersetzen musste? Ich bin leider nicht direkt vom Fach (E-Technik-Student mit Vertiefung Telekommunikation) und hab in solchen Dingen nur Laienwissen.
Keinen?!
Angenommen, alle Frames brauchen zur Berechnung 20 ms, der Bildschirmrefresh kommt alle 16,6 ms. Die Buffer heißen A, B und C. Alle Buffer sind leer. Nach 20 ms ist Buffer A (Backbuffer) voll, nach 33,3 ms wird dieser zum Frontbuffer. Derweil hat die Grafikkarte schon 13,3 ms lang in Buffer B gerendert. Nach 40 ms ist B voll, es wird in C gerendert (der bis 33,3 ms noch Framebuffer war). Nach 50 ms kommt ein weiterer Refresh, B wird zum Frontbuffer, A zum Backbuffer. Nach 60 ms ist C voll, es wird in A gerendert. Nach 66,6 ms wird C zum Frontbuffer und B wieder zum Backbuffer. Usw.
stimmt schon, nur woher kommen die informationen wie das 3. frame auszusehen hat?
diese kommen von eingaben die du auf der basis von mindestens 2 frames (je nach prerendering auch mehr) in der vergangenheit getätigt hast.
die idee einfach immer das neueste frame zu nehmen ist auch nicht gerde toll, das würde zwar den lag reduzieren, dafür aber zu auffälligen rucklern führen, da der abstand zwischen den frames 1 und 3 eben länger ist als jener zwischen 1 und 2 bzw. 2 und 3.
andererseits tritt der fall, dass im 2. backbuffer zum zeitpunkt des vsync bereits ein fertiges frame ist nur dann auf wenn die framerate über der bildwiederholfrequenz liegt, dann dürfte sie hoch genug sein, um keine sichtbaren lags zu produzieren.
Ich hab mal nochmal darüber nachgedacht und es liegt wohl daran, dass man keine Frames verlieren darf wenn diese kürzer sind als ein Monitor-Frame.
So ganz trivial wie du dir das vorstellst ist es in dem Fall nämlich nicht mehr.Wie siehts dann mit deaktiviertem Vsync aus? Wenn das OK ist, wieso sollte dann an einer anderen TB-Variante was auszusetzen sein?
Spasstiger
2008-03-27, 17:32:07
Wie siehts dann mit deaktiviertem Vsync aus? Wenn das OK ist, wieso sollte dann an einer anderen TB-Variante was auszusetzen sein?
Mit deaktiviertem VSync landet alles im Framebuffer und Front- und Backbuffer werden mit jedem Refresh getauscht, egal ob ein Bild fertig ist oder nicht. Es wird einfach über das alte Bild drübergerendert (auch mehrfach innerhalb eines Refreshs, wenn die Frameraten entsprechend hoch sind).
(auch mehrfach innerhalb eines Refreshs, wenn die Frameraten entsprechend hoch sind).Genau das meinte ich. Mit deaktiviertem Vsync kannst du nicht garantieren, dass ein berechnetes Bild auch dargestellt wird. Daher kann dies doch eigentlich kein Argument dafür darstellen, TB nur als Chain zu implementieren.
Mr. Lolman
2008-03-27, 17:39:15
stimmt schon, nur woher kommen die informationen wie das 3. frame auszusehen hat?
diese kommen von eingaben die du auf der basis von mindestens 2 frames (je nach prerendering auch mehr) in der vergangenheit getätigt hast.
Genau das ist der Punkt. Man sieht immernoch das Bild vom Buffer A, während schon in den Buffer C gerendert wird.
Spasstiger
2008-03-27, 18:01:19
Genau das ist der Punkt. Man sieht immernoch das Bild vom Buffer A, während schon in den Buffer C gerendert wird.
Ohne Triple Buffering dreht die Graka in der Zeit Däumchen (bei aktivem VSync, bei nicht aktivem VSync überschreibt sie halt den gleichen Frame nochmal). Kein Unterschied in Bezug auf Zeitverzögerungen.
Mr. Lolman
2008-03-27, 18:18:24
bei nicht aktivem VSync überschreibt sie halt den gleichen Frame nochmal)
Nicht komplett. Ja nach Monitorverhalten und Frequenz ist das Tearing imo weniger störend, als Nachteile die Tripplebuffering mitsich bringt (unregelmässigere Frametimes und eben den Lag von 1 Frame vgl zu VsyncOFF)
Bei 60fps wohl alles nicht so schlimm. Aber bei 30fps hätt ich schon gern alle berechneten Frames möglichst schnell am Schirm.
Kein Unterschied in Bezug auf Zeitverzögerungen.
Ich denk mir, dass es bei geringen fps durchaus irritieren kann, wenn zw. Ein- und Ausgabe 3 Frames liegen.
Spasstiger
2008-03-27, 18:34:54
Ich denk mir, dass es bei geringen fps durchaus irritieren kann, wenn zw. Ein- und Ausgabe 3 Frames liegen.
Ist ja auch bei vielen Spielen der Fall.
Die Frage, warum bei Triple-Buffering gegenüber Double-Buffering ein zusätzlicher Framelag erzeugt wird, obwohl theoretisch nicht notwendig, wurde leider immer noch nicht zufriedenstellend beantwortet.
Mr. Lolman
2008-03-27, 18:39:47
Ist ja auch bei vielen Spielen der Fall.
Eben, warum dann noch ein Frame zusätzlichen Lag inkauf nehmen?
Die Frage, warum bei Triple-Buffering gegenüber Double-Buffering ein zusätzlicher Framelag erzeugt wird, obwohl theoretisch nicht notwendig, wurde leider immer noch nicht zufriedenstellend beantwortet.
Mit VSyncOff ist bei Tripplebuffering ist einfach ein Frame mehr in der Pipe. VsyncOn zwar auch, aber das wiegt sich wohl mit den besseren Frametimes auf...
Die Frage, warum bei Triple-Buffering gegenüber Double-Buffering ein zusätzlicher Framelag erzeugt wird, obwohl theoretisch nicht notwendig, wurde leider immer noch nicht zufriedenstellend beantwortet.
das wurde schon mehrfach beantwortet.
wenn die grafikkarte beginnt ein frame zu berechnen muss bereits feststehen wie es aussieht. vsync ohne TP wäre natürlich noch schlimmer, da die framerate dann ständig schwankt.
wenn die berechnung des frames beginnt siehst du aber noch 2 frames früher am monitor. wenn die framerate über der bildwiederholfrequenz liegt kommt es natürlich nie so weit (der 3. buffer wird dann nie benutzt), aber wenn die framerate unter die bildwiederholfrequenz sinkt gibt es die verzögerung.
deshalb würde ich vsync nur aktivieren wenn die framerate hoch genug ist, dann allerdings mit TP, da dieser einbrüche knapp unter die bildwiederholfrequenz noch ganz gut abfangen kann, während die framerate mit DB sofort auf die halbe bildwiederholfrequenz einbricht.
das wurde schon mehrfach beantwortet.Leider nicht. Wenn man TB auf zwei Arten implementieren kann, wobei die eine die Latenz erhöht, während die andere die Latenz unverändert belässt bzw. sogar minimal senkt... Warum zum Geier nimmt man dann die Variante mit dem unangenehmen Nebeneffekt?
wenn die grafikkarte beginnt ein frame zu berechnen muss bereits feststehen wie es aussieht. vsync ohne TP wäre natürlich noch schlimmer, da die framerate dann ständig schwankt.Mit TB schwankt die Framerate ständig, mit DB hingegen ist sie recht konstant, aber eben auch niedriger.
wenn die berechnung des frames beginnt siehst du aber noch 2 frames früher am monitor. wenn die framerate über der bildwiederholfrequenz liegt kommt es natürlich nie so weit (der 3. buffer wird dann nie benutzt), aber wenn die framerate unter die bildwiederholfrequenz sinkt gibt es die verzögerung.Da ist ja eben das klassische Missverständnis: Alle drei Buffer werden immer genutzt, speziell wenn die FPS an der Hz-Mauer kleben.
deshalb würde ich vsync nur aktivieren wenn die framerate hoch genug ist, dann allerdings mit TP, da dieser einbrüche knapp unter die bildwiederholfrequenz noch ganz gut abfangen kann, während die framerate mit DB sofort auf die halbe bildwiederholfrequenz einbricht.Das ist IMHO der einzige sinnvolle Einsatzzweck für TB, kurze Einbrüche abfangen. Wenn aber nicht der gelegentliche Absturz (Nachladeruckler u.ä.) verhindert werden soll sondern die Framerate sich ständig in den Zwischenbereichen befindet, dann hat man durch TB eher Flüssigkeit eingebüßt als gewonnen.
Prerenderlimit ist eine andere Baustelle. Wie das "Pre" bereits andeutet bezieht es sich auf eine Latenz, die vor dem Beginn des Renderings anfällt. Ob die gerenderten Frames vor der Darstellung jetzt bei TB noch einen weiteren Frame zwischengelagert werden oder nicht ist für das Prerenderlimit vollkommen irrelevant.
Aber um die Renderbuffer (Backbuffer) überhaupt rendern zu können braucht der Chip schon die Parameter aus den Pre-render-Buffern, oder nicht?
Mit deaktiviertem VSync landet alles im Framebuffer und Front- und Backbuffer werden mit jedem Refresh getauscht, egal ob ein Bild fertig ist oder nicht. Es wird einfach über das alte Bild drübergerendert (auch mehrfach innerhalb eines Refreshs, wenn die Frameraten entsprechend hoch sind).
Nein, es ist umgekehrt.
Unabhängig vom Refresh (ohne Sync also) werden die Buffer Front und Back geswappt, wenn das Bild im Backbuffer fertig berechnet ist.
Bei deiner Variante würdest du nur unfertig gerenderten Müll auf dem Bildschirm sehen.
Aber um die Renderbuffer (Backbuffer) überhaupt rendern zu können braucht der Chip schon die Parameter aus den Pre-render-Buffern, oder nicht?Natürlich braucht die GPU alle Daten daraus früher oder später, sie müssen aber nicht zwangsläufig in diesem Ausmaß (ganze Frames, die jeweils aus Unmengen von Drawcalls bestehen) zwischengespeichert werden. Die heutigen GPUs sind ja keine Deferred Renderer, wo wirklich alle Daten vor Beginn der Arbeit vorhanden sein müssen.
Ohne Triple Buffering dreht die Graka in der Zeit Däumchen (bei aktivem VSync, bei nicht aktivem VSync überschreibt sie halt den gleichen Frame nochmal). Kein Unterschied in Bezug auf Zeitverzögerungen.
Siehe auch oben.
Mit Vsync: Buffer Swap synchron zur Bildausgabe
Ohne VSync: Karte swappt so schnell wie sie kann, bei 600 fps (=Swap-Rate der Buffer) und 60Hz Refresh hast du 10 Tearing-Linien im angezeigten Bild.
Spasstiger
2008-03-27, 21:16:47
Ohne VSync: Karte swappt so schnell wie sie kann, bei 600 fps (=Swap-Rate der Buffer) und 60Hz Refresh hast du 10 Tearing-Linien im angezeigten Bild.
Sicher? Kann der Buffer swappen, auch wenn kein Refresh erfolgt? Die 10 Tearing-Linien würde ich gern mal auf einem Foto sehen.
Ja natürlich, der Refresh sagt doch nur, wie oft das Bild das du auf dem Monitor sieht aktualisiert wird. Und wenn das langsamer geschieht ist als die Buffer swappen, siehst du eben den Inhalt von je 10% der 10 Buffer die geswappt werden währed des einen Refreshs.
Natürlich braucht die GPU alle Daten daraus früher oder später, sie müssen aber nicht zwangsläufig in diesem Ausmaß (ganze Frames, die jeweils aus Unmengen von Drawcalls bestehen) zwischengespeichert werden. Die heutigen GPUs sind ja keine Deferred Renderer, wo wirklich alle Daten vor Beginn der Arbeit vorhanden sein müssen.
die API muss alle daten kennen bevor mit dem render begonnen werden kann. du könntest ja durchaus auch einen deferred-renderer bauen ohne die API zu ändern.
die API muss alle daten kennen bevor mit dem render begonnen werden kann.Alle benötigten Daten. Also alle zu einem Drawcall zugehörigen, nicht alle für einen kompletten Frame.
du könntest ja durchaus auch einen deferred-renderer bauen ohne die API zu ändern.Natürlich. Der würde sich dann den für seinen Betrieb nötigen Buffer im Treiber nachstellen und/oder einen IMR-Modus als Fallback beherrschen. Ist aber für das konkrete Thema nicht sonderlich relevant. Es gibt nunmal unvermeidbare Latenzen und vermeidbare. So braucht ein Deferred Renderer zwar erst alle für einen Frame benötigten Daten, kann allerdings nicht nur auf TB, sondern sogar auf DB verzichten, was bei einem IMR absolut unmöglich ist.
Die momentanen TB-Implementationen fügen eine vermeidbare Latenz ein, keine technisch notwendige. Nichtmal eine vernünftige. Außer natürlich, man bedenkt, dass man bei einer höheren Latenz mehr FPS braucht, um die gleiche Spielbarkeit zu erhalten...
Alle benötigten Daten. Also alle zu einem Drawcall zugehörigen, nicht alle für einen kompletten Frame.
und wie soll die engine die drawcalls erstellen, wenn sie noch nicht weiß wie das fertige frame aussehen soll?
So braucht ein Deferred Renderer zwar erst alle für einen Frame benötigten Daten, kann allerdings nicht nur auf TB, sondern sogar auf DB verzichten, was bei einem IMR absolut unmöglich ist.
natürlich braucht auch ein deferred renderer buffer zum rendern, je nach umsetzung sogar deutlich mehr.
und wie soll die engine die drawcalls erstellen, wenn sie noch nicht weiß wie das fertige frame aussehen soll?Natürlich muss an mindestens einer Stelle das "Gesamtwerk" verfügbar sein, diese "Lagerhaltung" sollte aber auch auf das absolute Minimum beschränkt werden. In der Praxis wird leider an zu vielen Stellen zu viel gelagert, bevor es in die Weiterverarbeitung geht. An einigen Stellen mag dies sinnvoll sein, um Optimierungen (ausnahmsweise mal nicht in Anführungszeichen :D) durchführen zu können. Wenn man aber z.B. für 10% FPS-Gewinn eine verdoppelte Latenz hinnehmen muss, dann hat man nichts gewonnen sondern eher die 90% verloren, die man an Tempo nachlegen muss um wieder bei der gleichen Spielbarkeit zu landen.
natürlich braucht auch ein deferred renderer buffer zum rendern, je nach umsetzung sogar deutlich mehr.Ein TBDR kann mit einem einzelnen Buffer auskommen, der gleichzeitig Front- und Backbuffer ist. Ein IMR kann das nicht, er würde so lediglich Datenmüll produzieren.
Spasstiger
2008-03-27, 23:23:43
Ja natürlich, der Refresh sagt doch nur, wie oft das Bild das du auf dem Monitor sieht aktualisiert wird. Und wenn das langsamer geschieht ist als die Buffer swappen, siehst du eben den Inhalt von je 10% der 10 Buffer die geswappt werden währed des einen Refreshs.
Stimmt, so schreibts auch Wikipedia. Hab mal ne 3D-Demo mit 400 fps @ 60 Hz laufen lassen, konnte aber beim besten Willen nicht mehr als einen Tearingstreifen gleichzeitig wahrnehmen. Auf Foto konnte ich auch nur 2 Tearingstreifen bannen, wobei meine Handycam für solche Experimente viel zu träge ist.
Ein TBDR kann mit einem einzelnen Buffer auskommen, der gleichzeitig Front- und Backbuffer ist. Ein IMR kann das nicht, er würde so lediglich Datenmüll produzieren.
Wie soll das denn gehen?
Wie soll das denn gehen?Die Kyros könnens jedenfalls. Man hat dann Tearing wie mit DB ohne Vsync, aber nur den halben Speicherverbrauch. Funktionieren tuts, weil bei einem TBDR ja nichts gerendert wird, was nicht sichtbar wäre. Also z.B. die Skybox nirgendwo durchscheinen kann, weil das sie verdeckende Gebäude noch nicht gerendert wurde, wie es auf einem IMR ohne DB/TB wäre.
Das gibt dann aber sehr eigenwilliges "Tearing", wenn mitten im Bild dann plötzlich Blöcke vom nächsten Bild auftauchen.
Also soweit ich weiß machen Kyros ganz normales Double-Buffering.
Sie können es jedenfalls. Soll im Grunde stinknormales Tearing sein, nur dass man wegen der größeren zusammenhängenden Blöcke auch das horizontale Tearing sehen kann, während man es bei IMRs meist nur in der Vertikalen wahrnimmt.
Die Kyros könnens jedenfalls. Man hat dann Tearing wie mit DB ohne Vsync, aber nur den halben Speicherverbrauch.
naja, nicht wirklich tearing, man sieht dann die tiles mehrerer frames gemixt.
man kann übrigens auch mit einem IMR prinzipiell mit einem einzigen buffer rendern (beispielsweise in 3dmark01 konnte man das einstellen), auf dem bildschirm kommt natürlich ein ziemliches geflacker an ;)
Natürlich muss an mindestens einer Stelle das "Gesamtwerk" verfügbar sein,
und zwar bevor mit dem rendern begonnen wird. das einzige was du "vorrendern" könntest sind dinge die sich garantiert nicht von einem frame aufs nächste ändern können.
das sind aber leider recht wenige und noch dazu recht "unwichtige" dinge, denn die wichtigen, auf die man als spieler reagieren muss, ändern sich ja ständig.
ein spiel kann immer nur frames zu einem zeitpunkt x rendern. jedes frame muss natürlich in sich konsistent sein, jedes objekt im frame muss also den gleichen zeitpunkt repräsentieren.
wäre dsa nicht der fall würde am bildschirm ein kompletter müll zu sehen sein, objekte würden ineinander gerendert werden etc.
Mr. Lolman
2008-03-28, 14:05:50
Stimmt, so schreibts auch Wikipedia. Hab mal ne 3D-Demo mit 400 fps @ 60 Hz laufen lassen, konnte aber beim besten Willen nicht mehr als einen Tearingstreifen gleichzeitig wahrnehmen. Auf Foto konnte ich auch nur 2 Tearingstreifen bannen, wobei meine Handycam für solche Experimente viel zu träge ist.
Falls du Bioshock hast - in der Szene am Anfang nachdem man durch die Unterwasserstadt gegondelt ist und dann in der Tauchglocke wartet: Das Lichtflackern sieht ohne VSync sehr übel aus. Vll. sieht man da mehr als einen Tearingstreifen.
Grestorn
2008-03-28, 14:10:09
Falls du Bioshock hast - in der Szene am Anfang nachdem man durch die Unterwasserstadt gegondelt ist und dann in der Tauchglocke wartet: Das Lichtflackern sieht ohne VSync sehr übel aus. Vll. sieht man da mehr als einen Tearingstreifen.
Ganz genau! Sehr gutes Beispiel. Dieses Stroboskop Blitzen ist echt übel. Durch die extrem kurzen Blitze sieht man deutlich mehr Tearing-Linien als eigentlich durch die Framerate zu erwarten wäre.
Ganz genau! Sehr gutes Beispiel. Dieses Stroboskop Blitzen ist echt übel. Durch die extrem kurzen Blitze sieht man deutlich mehr Tearing-Linien als eigentlich durch die Framerate zu erwarten wäre.
nicht mehr aber sie sind deutlich auffälliger, weil einfach der helligkeitsunterschied zwischen 2 frames extrem ist.
um möglichst viele tearingstreifen zu sehen kann ich C&C-Renegade empfehlen ;)
dort gibt es bildschirme auf denen irgendein bildrauschen gezeigt wird. an einigen stellen kann man an diese bildschirmfüllend rangehen, bei einigen 100fps gibt es da extrem viele tearingstreifen ;)
vBulletin®, Copyright ©2000-2024, Jelsoft Enterprises Ltd.