|
|
|
|
|
|
|
Das wären 60fps.
Das wäre mein Wunschwert, auf dem die Spiele laufen sollten.
|
|
|
|
|
|
|
|
|
|
|
Um's gaaaanz simpel zu halten:
Schafft dein Rechner in einer bestimmten Situation keine 60fps, wirst du durch VSync effektiv auf 30fps limitiert.
|
|
|
|
|
|
|
|
|
|
|
|
Und bei nem Benchmark springt er dann quasi immer hin und her und das Benchmark bildet den Mittelwert, oder?
|
|
|
|
|
|
|
|
|
|
|
|
Da bin ich mir nicht sicher, ob die doppelt angezeigten Frames mitgezählt werden. Zusätzlich entsteht aber durch VSync noch ein mehr oder weniger starker Inputlag.
|
|
|
|
|
|
|
|
|
|
|
|
Darum macht man das ja auch aus in der Regel.
|
|
|
|
|
|
|
|
|
|
|
|
Wenn da nicht dieses Tearing wäre...
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von DJDeath
Schafft dein Rechner in einer bestimmten Situation keine 60fps, wirst du durch VSync effektiv auf 30fps limitiert.
| |
nein!
| | Zitat von Bregor
Und bei nem Benchmark springt er dann quasi immer hin und her und das Benchmark bildet den Mittelwert, oder?
| |
nein.
| | Zitat von DJDeath
Da bin ich mir nicht sicher, ob die doppelt angezeigten Frames mitgezählt werden. Zusätzlich entsteht aber durch VSync noch ein mehr oder weniger starker Inputlag.
| |
nein und nein.
| | Zitat von Bregor
Darum macht man das ja auch aus in der Regel.
| |
das gilt nur für die leute, die keine qualität haben wollen.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von DeeJay
Wenn da nicht dieses Tearing wäre...
| |
Das ist mit dass hässlichste überhaupt. Lieber Opfer ich was anderes als das ich auf VSync verzichte.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Traxer
| | Zitat von DJDeath
Schafft dein Rechner in einer bestimmten Situation keine 60fps, wirst du durch VSync effektiv auf 30fps limitiert.
| |
nein!
| |
| | | Essentially this means that with double-buffered VSync, the framerate can only be equal to a discrete set of values equal to Refresh / N where N is some positive integer. That means if you're talking about 60Hz refresh rate, the only framerates you can get are 60, 30, 20, 15, 12, 10, etc etc. You can see the big gap between 60 and 30 there. Any framerate between 60 and 30 your video card would normally put out would get dropped to 30. | |
Ist das dann falsch? Und wenn ja: Warum?
|
|
|
|
|
|
|
|
|
|
|
|
Das wäre in der Tat ziemlich uncool. :/
|
|
|
|
|
|
|
|
|
|
|
Die restliche Erklärung dort: http://hardforum.com/showthread.php?t=928593 ist gespickt mit komischen/falschen Vergleichen und Details, was nicht gerade für gute Verständnis des Themas spricht. (z.B. scheint er nicht zu wissen, wie die Kommunikation Graka<->Monitor abläuft, sonst würde er nicht ständig sowas wie "Whenever the monitor grabs a frame to refresh with, it pulls it from the frame buffer." oder "the LCD must still poll the video card at a certain rate for new frames" schreiben - das ist aber nicht gerade unwichtig bei dem Thema).
/e: Die Erklärung an sich ist (Integer-N effektive Framerate) nicht falsch bei dem einfachen Schema. Aber ich glaube nicht, dass das noch benutzt wird... Traxer?
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von csde_rats am 10.08.2014 15:37]
|
|
|
|
|
|
|
|
|
Ich such jetzt auch schon ne Zeit lang nach einer guten technischen Erklärung, aber das ist gar nicht so einfach, was Handfestes zu finden.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Traxer
| | Zitat von Bregor
Darum macht man das ja auch aus in der Regel.
| |
das gilt nur für die leute, die keine qualität haben wollen.
| |
Wenn ein Spiel unspielbar wird, durch das behinderte Mausmovement durch VSync muss man es einfach ausmachen.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Bregor am 10.08.2014 15:53]
|
|
|
|
|
|
|
|
|
| | Zitat von DJDeath
| | Zitat von Traxer
| | Zitat von DJDeath
Schafft dein Rechner in einer bestimmten Situation keine 60fps, wirst du durch VSync effektiv auf 30fps limitiert.
| |
nein!
| |
| | | Essentially this means that with double-buffered VSync, the framerate can only be equal to a discrete set of values equal to Refresh / N where N is some positive integer. That means if you're talking about 60Hz refresh rate, the only framerates you can get are 60, 30, 20, 15, 12, 10, etc etc. You can see the big gap between 60 and 30 there. Any framerate between 60 and 30 your video card would normally put out would get dropped to 30. | |
Ist das dann falsch? Und wenn ja: Warum?
| |
weil lesen und so. 
| | | Essentially this means that with double-buffered VSync | |
dabei ist das korrekt. lässt du das ohne double buffering laufen, dann ist das nicht der fall. lässt du es in tripple buffering laufen, ist es ebenfalls nicht korrekt.
hast du eine synchronisierte page-flip implementation, dann ist das auch nicht der fall.
der sinn hinter vsync (vertical synchronisation) stammt aus der CRT zeit, wo du halt den elektronenstrahl hattest, der die phosphorschicht zeilenweise abgearbeitet hat. wurde während so einem scan (so nennt man das zeilenweise abarbeiten) ein neues bild direkt in den front-buffer (der speicher in dem das bild liegt, welches gerade zum monitor geschickt wird) geschrieben, dann hast du zwei bzw. teilweise sogar drei teile von verschiedenen bildern auf dem monitor gehabt. das ist das gute tearing.
aktuelle (so seit ca. 2000-2004) LCD monitore sollten, wenn richtig umgesetzt und nicht analog angeschlossen (ja, das kann man leider auch via DVI), ein bild nicht mehr zeilenweise, sondern blockweise aufbauen oder aber wie im falle von höherwertigeren als atomare operation aufbauen. dafür haben LCD monitore selber intern einen gewissen speicher um mind. 1 meist aber zwei frames zwischen zu speichern. von daher sollten(!) LCD monitore eigentlich kein tearing mehr produzieren können.
ABER, leider ist und war es lange so, dass der monitor und die grafikkarte mit unterschiedlichen timings arbeiten. das wiederum führt dazu, dass es auch hier möglich ist halbe frames in den monitor puffer zu schreiben, die dann irgendwann dargestellt werden.
das ist einer der gründe, warum nvidia G-Sync "erfunden" hat bzw. AMD ihre "FreeSync" variante.
(das könnte man / ich jetzt noch weiter ausführen, ich erspare euch das jetzt mal)
das problem mit dem input lag bei LCD monitoren - erinnert ihr euch noch an die zeit, wo ihr mit einem CRT gespielt hattet und dort bei eingeschaltetem VSYNC input lag hattet? - ist, dass die monitore intern selber bilder zwischenspeichern müssen, damit sie diese darstellen können. hat der monitor jetzt selber zwei interne puffer (betreibt also selber eine art double buffering, meisst als page flip umgesetzt), dann hast du hier einfach den doppelten bis vierfachen overhead, wenn das nicht sauber synchronisiert ist. ist es sauber synchronisiert, dann hast du effektiv genau einen (1) frame lag. den hättest du allerdings in jedem fall, da der monitor den selber erzeugt. dazu kommt dann noch, dass nahezu alle spiele die heute auf dem markt sind selber noch einen frame lag erzeugen, weil es engine technisch kaum anders möglich ist, wenn du alles rechenwerke eines aktuellen computers nutzen willst bzw. musst.
hast du ein vernünftiges setup (was die allerwenigsten haben, mich eingeschlossen), dann hast du genau einen frame input lag und damit bei einem 60 Hz spiel, 16.66 ms. das liegt in einem bereich, den du als mensch nur sehr sehr marginal wahrnehmen kannst. das sind bei einer drehung um die eigene achse in einem FPS ein paar pixel.
effektiv reden wir hier bei einem normalen setup, durchschnittlich guter LCD und vernünftiger grafikkarte von einem input lag von weniger als 60 ms. bewege mal bitte deine finger oder deine hand in der geschwindigkeit. 
nebenei, ich hoffe ihr nutzt alls PS/2 mäuse und tastaturen. die USB teile produzieren einen fast > 100 ms lag zwischen tastenanschlag und event im OS!  
das ganze vsync / input lag problem fliegt übrigens zur tür raus, wenn das input system nicht an das rendering system geknüpft ist. in dem fall kann die grafikkarte so viele oder wenige frames produzieren wie ihr lustig ist. das input system wird immer mit einer festen frequenz abgerufen.
hast du eine game logic die ebenfalls mit einer "target" frequenz von sagen wir mal 60 FPS läuft, dann kannst du den input auch entsprechend auswerten und in den zumindest übernächsten frame integrieren.
damit hat man dann zumindest auf seiten des rechners einen maximalen input lag von einem frame.
das was dir (zur wiederholung) keiner genau sagen kann ist, was der monitor da für eine latenz drauf packt.
hier wird es übrigens ganz besonders schön, wenn man einen LCD fernseher verwendet und der nicht im "game mode" läuft. die können da schonmal so zwischen 200 und 1500 ms an latenz drauflegen, da die intern noch ein bischen post processing betreiben. daher sollte man eine konsole auch niemals in einem nicht "game mode" betreiben.
ergo, das ganze input lag und vsync zeugs ist einfach nicht mehr so einfach wie es mal war. es gibt inzwischen so viele irrwitzige sachen, die das beeinflussen, dass man selber besser damit bedient ist sich da keine gedanken mehr drüber zu machen.
wie gesagt die folgenden komponenten spielen eine rolle, wenn es um input lag und vsync geht:
- betriebssystem
- grafiktreiber
- game engine (render - input kopplung?)
- grafikkarte
- grafikkarten double buffer implementation (page flip vs. richtigem double buffering)
- monitor anschluss (VGA vs. digital) (btw. display port erhöht die latenz zusätzlich gegenüber DVI)
- monitor (display controller)
im weiteren sinne:
- USB (ja, usb ist lahm, sehr lahm. das zeugs muss durch tonnen von systemen durch, bis es beim spiel oder gar bei OS angelangt ist. PS/2 war damals simpler und schneller)
- multi monitor setups
- multi GPU setups
- kombinationen aus allen diesen punkten
jetzt mal ganz ehrlich, so als spieler.
sollte man so einen oder zwei frames lag nicht eher als herausforderung ansehen, als als handicap? das ist so der unterschied zwischen den "normalen" spielern und den leuten die einfach gut spielen können.
- - -
wer eine weit technischere erklärung haben will, schreibt bitte nicht mich an, ich hab gerade keine lust einen noch längeren text zu schreiben.
|
|
[Dieser Beitrag wurde 1 mal editiert; zum letzten Mal von Traxer am 10.08.2014 16:25]
|
|
|
|
|
|
|
|
|
| | Zitat von Bregor
| | Zitat von Traxer
| | Zitat von Bregor
Darum macht man das ja auch aus in der Regel.
| |
das gilt nur für die leute, die keine qualität haben wollen.
| |
Wenn ein Spiel unspielbar wird, durch das behinderte Mausmovement durch VSync muss man es einfach ausmachen.
| |
dann haben die leute die das spiel gebaut haben schläge auf ihren kopf verdient, aber nicht das vsync. (siehe langen text)
|
|
|
|
|
|
|
|
|
|
|
man vergebe mir, aber:
| | | The basic idea is that synchronizes your FPS with your monitor's refresh rate. | |
ich schliess das mal ganz schnell wieder. 
das ist nicht der sinn hinter vsync und das das passiert ist lediglich ein nebeneffekt.
aber ist halt auch schon von anno 2005. da war die welt noch einfacher und nicht so grausam.
|
|
|
|
|
|
|
|
|
|
|
|
Kann man das Double-Buffering denn irgendwo abstellen? Und wenn ja, mit welchen Nebeneffekten?
|
|
|
|
|
|
|
|
|
|
|
kannst du so ohne weiteres nicht, weil das ganze dann ein paar technische delikatessen mit sich bringt.
du würdest dafür eine engine bzw. grafikkarte brauchen die eine konstante anzahl an fps liefern kann und einen monitor der damit umgehen kann und sich entsprechend damit synchronisieren kann.
das ganze ist effektiv das mit dem G-Sync und FreeSync.
die alternative zu dem ganzen ist halt einfach tripple buffering zu verwenden.
hier muss die grafikkarte nicht drauf warten, dass der back buffer / front buffer flip passiert, da sie einen zweiten (der dritte) backbuffer hat in den sie zeichnen kann.
hier kann es dir dann höchstens passieren, dass dir mal nen frame oder so verloren geht. der bzw. die frames wären dann allerdings eh uninteressant, da sie keine neuen relevanten informationen im vergleich zum nachfolgenden bzw. vorhergehenden frame enthalten hätten.
wenn euch das mit dem double buffering nicht schmeckt und euch kein tripple buffering erlaubt wird, dann versucht es mit adaptive vsync. (vermutlich allerdings nur bei OpenGL / Mantle spielen verfügbar)
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Traxer
nebenei, ich hoffe ihr nutzt alls PS/2 mäuse und tastaturen. die USB teile produzieren einen fast > 100 ms lag zwischen tastenanschlag und event im OS!
| |
|
|
|
|
|
|
|
|
|
|
|
|
Und wieso ist der Schrott dahinter noch nicht entsorgt?
|
|
|
|
|
|
|
|
|
|
|
Liegt unterm Bett als Ersatztastatur. 
TAKKA TAKKA TAKKA!!!!
Ich geh dann mal weiter benchmarken...
|
|
|
|
|
|
|
|
|
|
|
PS/2 <-> USB: USB erlaubt - theoretisch (freier Bus) - bis zu 1 kHz Polling, was schneller als PS/2 ist, weil PS/2 vielleicht so 10 kHz Taktfrequenz hat, was ungefähr 1 kbyte/s ist. USB kann dagegen tausend mal pro Sekunde alle Änderungen übertragen, in der Praxis ist das aber egal, weil die Scangeschwindigkeit von nem Tastaturcontroller viel langsamer ist (Größenordnung: 100 Hz). Zu größeren Problemen kommt es bei USB eigentlich nur, wenn über den gleichen Upstream-Pfad gleichzeitig größere Bulktransfers laufen und die Hubs nix taugen.
Der alte Tipp bei USB-Eingabegeräten diese an einen extra Hub, der für sonst nix benutzt wird, oder direkt an den PC zu stöpseln, ist also durchaus begründet.
|
|
|
|
|
|
|
|
|
|
|
Wer ist eigentlich für die Partikel zuständig?
Macht das die Graka oder CPU?
Gerade bei Nebel, Staub, Einschusslöchern und Ähnlichem brechen die FPS bei mir ein.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von Abtei*
| | Zitat von FoB
Hab ich nie
1280*1024 ist meine Auflösung.
| |
Gut, dan solltest du da auch mal ein Auge drauf haben und etwas von deinem Budget reinblättern.
| |
Kommt später irgendwann.
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von GandalfDerPinke
Wer ist eigentlich für die Partikel zuständig?
Macht das die Graka oder CPU?
Gerade bei Nebel, Staub, Einschusslöchern und Ähnlichem brechen die FPS bei mir ein.
| |
Engineabhängig. Mit neueren Techniken kann man fast alles auf der GPU machen...
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| | Zitat von GandalfDerPinke
Wer ist eigentlich für die Partikel zuständig?
Macht das die Graka oder CPU?
Gerade bei Nebel, Staub, Einschusslöchern und Ähnlichem brechen die FPS bei mir ein.
| |
wie rats schon sagte hängt das von der engine ab und wie die entwickler das skalierungstechnisch gelöst haben. historisch gesehen wurden partikelsysteme durch die CPU berechnet und dann "nur" noch von der GPU als point oder imposter (quad / triangle) geometry gerendert.
inzwischen geht das sowohl via compute als auch direkt via vertex/geometry/pixel shadern.
CUDA, Stream oder OpenCL sind hier eher nicht im einsatz, da das context switchen zwischen dem compute context und dem grafikkontext zu viel zeit und ressourcen benötigt. das würde zu sehr merkbaren rucklern führen. mit ausnahme der aktuellen GCN 1.1 chips kann nämlich aus dem desktop bereich keine karte zwei oder generell mehrere kontexte parallel fahren.
das wird übrigens eines der lustigen features sein, die wir speziell der PS 4 zu verdanken haben.
bei den angesprochenen effekten gilt allerdings auch noch zu unterscheiden zwischen decals (einschusslöcher) und so sachen wie staub, nebel und nebel.
decals sind nichts anderes als ein spezielles stück geometrie, welches texturiert ist und an der stelle der szene, wo es auftauchen soll vor bzw. auf die eigentliche geometrie gesetzt wird.
staub ist in aller regel tatsächlich ein partikelsystem, wie z.b. auch die partikel die von einem einschussloch wegfliegen, wenn es entsteht.
nebel ist hier etwas mit vorsicht zu sehen, da es hier mehrere möglichkeiten gibt. sprechen wir von nebel in der entfernung (grosse entfernung) der nicht animiert ist, dann wird das eher kein partikelsystem sein, sondern der seit anbeginn der zeit vorhandene fadeout fog sein. der wird genutzt um das bild weich auszublenden, wenn die geometrie einfach so weit weg ist, dass sie keinen nennenswerten beitrag zum bild mehr leisten kann.
ist es nebel in form von nebel volumen bzw. animierter nebel, dann ist es sehr wohl ein partikelsystem. hier kommt es dann aber noch drauf an, ob und wie das ganze gebaut ist. hast du ein system mit impostern, dann sind das einfach so genannte screen aligned quads, die mit einer transparenten texture versehen sind. das ganze ist dann zwar geometrietechnisch einfach zu rendern, allerdings braucht man dafür in nahezu allen fällen alpha blending, was wiederum sehr teuer ist. das ist das wohl am meisten genutzte system.
andere ansätze sind hier direkt point geometry zu verwenden oder etwas abstraktere sachen. in aller regel ist hier allerdings die transparenz das, was die sache langsam macht.
generell gilt, nicht alles was nach partikelsystem bzw. partikel aussieht ist auch ein partikelsystem und nicht alles was nach statischer geometrie aussieht ist zwangsläufig kein partikelsystem.
es ist teilweise sehr irritierend, wenn man mal sieht wie viele partikelsysteme und generell partikeleffekte man gar nicht als solche erkennt bzw. wahrnimmt. das gilt auch für CG kram in filmen und co.
|
|
|
|
|
|
|
|
|
|
|
1. Arbeitest du auf der Schiene?
2. Hast du meine PM von vor ein paar Tagen gelesen?
|
|
|
|
|
|
|
|
|
|
|
Man möge mir die unwissenheit vergeben aber wie passt die denn bitte ins System? Der Zahl nach sollte sie schneller sein als die 280, hat aber im Vergleich ein beschnittenes Speicherinterface und weniger VRAM. 
|
|
|
|
|
|
|
|
|
|
|
|
Anderer Chip = auch mit weniger hohen Zahlen schneller
|
|
|
|
|
|
|
|
| Thema: Hardware-Kaufberatung ( Achtung, Kompetenz! ) |
