Hvornår/Hvilken skærm? Det er ikke været uden sync?
--

Jeg har en 144hz og spiller 1440p. I warzone ligger mine fps omkring 100 i avg og spillet føles total flydent.
--

Hej Mads, Screen tearing er et fænomen der optræder når skærmen refresher mens grafikkortet er ved at skrive næste frame til den buffer, skærmen læser fra. Så modtager skærmen et billede, der indeholder dele af både næste og forrige frame samtidig, hvilket kan se "skåret" ud hvis spillet har bevæget sig i mellemtiden. Der findes 2 løsninger. 1: VSYNC: Tvinger grafikkortet til at synkronisere skrivningen til bufferen med skærmens refresh rate, dvs. hvis skærmen kører 60 Hz, men computeren ikke nåede at blive færdig med næste frame indenfor 1/60 s ~ 16ms, så må grafikkortet vente yderligere 16ms indtil næste gang skærmen refresher med at levere framen, og så falder FPS'en brat til 30. 2: GSYNC (NVidia) eller FreeSync (AMD) Nyere teknologi, der dynamisk, med dedikeret hardware i skærmen og på grafikkortet, lynhurtigt synkroniserer skærmens refresh rate til præcis den FPS maskinen er i stand til at yde på ethvert givent tidspunkt. Det er den bedste af to verdener, da det eliminerer screen tearing uden at tvinge grafikkortet til at vente, fordi skærmen bare kan tilpasse sin refresh til grafikkortets FPS løbende. Når du skriver du oplever screen tearing får det mig til at tænke det er fordi du spiller uden VSYNC, på en skærm eller med et grafikkort, der ikke understøtter enten GSYNC eller FreeSync.
--

#3 Som du skriver, så burde screen tearing kun opstå når gpu spytter flere fps ud end end skærmen kører hz. Men i de højder vi er i dag, så er det minimalt hvor meget man når at opleve. At OP dog har det modsat, forstår jeg ikke. Burde ikke være screen tearing når hans fps er under hans hz. Problemet med vsync og gsync er at det giver forfærdelig input lag.
--
[email protected]@TC14PE- 16GB(2x8)LP CAS8@1600 - EVGA 980Ti Hybrid - z97 Ranger- 3x240GB FSeries3- 2x XL2411t - QF TK Red - EC2-A - G930

#4 For at være helt præcis: Screen tearing opstår når skærmens refresh divideret med grafikkortets FPS ikke er et heltal. Det er ligegyldigt om det er fordi grafikkortet kører hurtigere eller langsommere. Hvis du har en 60Hz skærm og kører 50 FPS (VSYNC disabled), så får du også screen tearing.
--

... Okay, det var noget sludder. ;) Undskyld. Det største tal, divideret med det mindste, skal være et heltal, for at undgå screen tearing. Det er for så vidt screen tearing angår også ok at køre FPS 120 på en 60Hz skærm, fx.
--

#1 Hvornår - det stod på i længere tid men 1-2 år siden, egentlig fra da jeg gik over til 144 Hz Skærm - ASUS VG248QE Sync - nope, uden sync... #2 Godt at høre - tak for input! #3 #4 #5 #6 Jeg har ikke haft nogle problemer, når fps fx har været 280 i CS:GO. Så det har været, når den nærmede sig 150 fps og så ellers derunder. Måske har jeg forvekslet screen tearing og stuttering? Hvis jeg fx stod i en smoke eller en molo i CS:GO, så ville pc'en nogle gange ramme 150 og også nogle gange ned på 120 el.lign. I de tilfælde var der ekstremt meget input lag og dét, der så måske er stuttering i stedet for screen tearing. Giver det mere mening? Og ændrer det på svaret mht. Warzone og fps og Hz?
--
Gæstebruger, opret dit eget login og få din egen signatur.

#7 Mit bud er du har oplevet høje frame tider. Du kan sagtens have 1000 FPS, men hvis ét frame pludselig tager 100ms, så vil det være et meget tydeligt. #6 Der vil ALTID være tearing uden Vsync eller anden synkroniserings teknologi. Det er jo derfor det hedder sync, dett er jo ikke blot en ‘cap ved 60 fps’.
--

?1: hvis du har fps over hz har du ogsaa screen tearing medmdinre du koere med fast sync ( me nsaa ville du ikke have tearing ved fpz under sync Tearing er til stedet forskellge alt efter fps til hz forhold . men der er kun tilstedet/ikke tilstede alt efter sync 2: screen tearings synbarhed er forskellige fra spil til spil. hvis et spil var 100% vide pixesl ville du aldrig kunne se pixels Detalje grade for de to billeder og hvor meget du har bevages dig imellem dig i den horizontale linine affoere hvor tydelig tearing er ved en given tearings linie 3: Kan vaere at persone har gsynx fressycn eller fast sync slaaet til Det kan gosaa vare du koere med vsync double buffer og de koer med triple buffing og du ikke helt er med paa hvad tearing er ( mange folk er ikke) og du ser paa sutter istedet for tearing Er det en "CS:GO-only ting", eller kan det generelt mærkes, hvis fps er lavere end Hz? dette kommer an paa din sync og framebuffer saetning 2 restende spoersgmaall. Det er individuelt/subjecktivt men proev at slaa fast sync til eller vsync med triplebuffering. du skal have en eller anden form for sync for ikke at have tearing
--
Sven Bent - Dr. Diagnostic www.TechCenter.[...] - Home of Project Mercury

#3 Screen tearing er et fænomen der optræder når skærmen refresher mens grafikkortet er ved at skrive næste frame til den buffer, skærmen læser fra. Dette er ikke helt korrekt Tearing sker naar skaarmen skifter fra at laese fra en framebuffer til en ande framebuffer mens billeder bliver opdateret paaa skaermn der bliver ALDRIG skrevet til den buffer som skaermen lease fra. hele ideen med at bruge doube bufferings ( eller flere) er at der ikke skriver/laeser til samme buffer Der findes 2 løsninger. der findes 3 loesninger Vsync+ double buffering/triple bufferings (ventende) gsync/freesync fastsync (hvilket er en glorificeret vsync med en fult roterende triple buffer som er skjult fra 3D API) #4 Tearing sker naar du ikke har sync hvadc ente FPS eller over, under eller lig med HZ Kun at have sync fjerner tearing. tearing kommer direkte af mangel af sync pga ovenstaaende forklaring om framebuffers #5 ogsaa forkert Du taler muligvis om FPS drops ved vsync og blandet det med tearing Tearing sker saa snart du ikke har sync #6 Det var noget sludder men ikke af den aarsag. arsagen er igen mangel paa sync ikke noget med fps/hz divisioner #7 Du vil altid have scrren tearing uden sync. Det vil dog vise sig anderledes alt after dit fps og hz forhold #8 korrekt omkring sync
--
Sven Bent - Dr. Diagnostic www.TechCenter.[...] - Home of Project Mercury

@op Er du sikker paa du taler om tearing dvs det ser ud som im billed er "revet over " see eksemplet her https://en.wikipedia.org[...]
--
Sven Bent - Dr. Diagnostic www.TechCenter.[...] - Home of Project Mercury

#10 Uden at det skal blive alt for akademisk... Når du siger det hele handler om "sync", hvad forstår du så ved "sync"? Helt præcist hvad er det, der synkroniseres? ... Det er selvfølgelig opdateringsfrekvenserne på henholdsvis skærmen og grafikkortet, og synkronisering finder sted netop når det ene tal er et heltals multiplum af det andet, hvilket er hvad jeg skrev. Det er rigtigt at double-buffering afhjælper problemet en del, men ikke 100%. Du skal stadig sørge for ikke at pille ved front bufferen på noget andet tidspunkt end under skærmens vertical blank, og det er lige meget om din double-buffer er en software implementering (hvor kopiering finder sted) eller hardware, hvor back og front bare flippes nede på grafikkortet. Sker det mens skærmen displayer bufferen, får du tearing.
--

#12 Jeg har også altid forstået det som Sven Bent skriver. At selvom du har 120fps og en 60hz skærm så kan/vil du stadig opleve tearing da skærmen og grafikkort ikke er synkroniseret. Altså feks dit grafikkort spytter 120fps ud og din skærm 60hz men intervallerne rammer ikke hinanden for hvordan skulle de kunne det når de ikke kommunikerer med hinanden, så at sige. Jeg kan tage fejl men sådan har jeg alle dage forstået det.
--
Back in my days the video games were more about the game than the video

#11 Som jeg skrev, så har jeg muligvis forvekslet screen tearing med stuttering. Som sagt har jeg dog ikke oplevet nogen form for problem, hvis jeg fx har kørt med 280 fps på en 144 Hz-skærm i CS:GO, så det er som sagt kun, når fps har været under 144.
--
Gæstebruger, opret dit eget login og få din egen signatur.

#13: Udgangspunktet er, at en frame skal være færdig og ligge uberørt i sin buffer, når skærmen displayer den. Det er basically alt. At ens setup så vælger at pumpe yderligere en frame ud i samme tidsrum, som udviskes igen uden nogensinde at blive vist, er ligegyldigt. Det er spild af kræfter da skærmen aldrig viser den, men at CPU/GPU er hurtige nok til at rendere 2 frames ud i det tidsrum hvor skærmen viser én, ødelægger teknisk set ikke muligheden for at synkronisere front bufferen til 60Hz. Jeg tror I har ret i at det aldrig vil finde sted, da buffer-flippet (ved vsync) synkroniseres til skærmens vertical blank, som er 60Hz dette eksempel, så det vil tvinge FPS'en ned i 60. Men der er ikke teknisk noget til hinder for at man kan smide dobbelt så mange frames ud, så længe man kan gøre det uden at lave en faseforskydning, som du også er inde på med kommentaren om at intervallerne skal ramme hinanden. ;)
--

Jeg må indrømme, at snakken måske er blevet lidt for teoretisk til, at jeg kan følge med... Jeg er i hvert fald ikke sikker på, at jeg har fået svar, eller jeg forstår det i hvert fald ikke... Er det forklarligt, eller giver det ingen mening, med mine oplevelser i CS:GO, og skal jeg være "bekymret" og opmærksom, når jeg skal have en ny pc, som skal kunne køre Warzone (altså SKAL den kunne køre Warzone på +144 fps, for at jeg ikke oplever det samme som i CS:GO - jeg har naturligvis #2 i mente, men alligevel)?
--
Gæstebruger, opret dit eget login og få din egen signatur.

Nu har cs jo altid været mærkelig mht. til fps og hvordan spillet føles.
--

#12 Nej det er ikke ikek paa dne maade du forstarr det Det der synkes helt preacist er frambuffer skift med refresh cyclens. ikke hastighende af denne som i hz of FPS lad mig forklare hvor du er forkert paa den FPS er et gennem snot iver tid 60fps og 60hz er det samme som at vare i sync 60fps kan vare et halvt sekund med 0 fps og et halvt sekudnt med 120fps og alt imellme saa laenge gennemsnittete blive 60 og selv om duhar helt perfect 60ps aka 16.6ms rendering time per frame og en 60hz opdatering frkvens som ogsaa er 16.6ms per rund betyder det ikek der sker samtidigt. den ene ksna ske ved 0ms 16.6ms og 33.3ms hvor dne ande er det ved 8 24.6 og 41.3 begge er 60 men der sker ikke paa samme tid saa de er ikke i sync Sa jaa din forklaring er forkert Hvad der i virkelighende sker Din gpu har 2 eller flere frambuffers i vram den ene bliver brugt til at laese fra af din skaerm den ande bliver brugt til at danne det naeste billed naar gpu er faerdig med at tegne naeste i sin frambeuffer bliver det skiftet rundt eller ratter skaermen laese nu fra den buffer med nyeste billed. hvis det sker inde for dne tid der tager at opdater picels paa skaeme fra tope til bund betyder det ert billeder der visst paa skaermne stammer fra to forskellige frambuffer og dermed to forskellige billed data og derfor har du et tearings punkt hvor det ser ud som om billet er revet over det sker ligemget hvor hurtig din fps eller HZ er det er de afgorende er at det skift sker paa et tidspunkt in operationer. naar du syncer venter dette framebuffer skift til at skaermen har sagt den har faerdig med skarm opdateirng. saa i stedet for at skarmen laeser fra buffer A og saa buffer B midt i opdatering. laeser den faedig i buffer A og naar den er fardig bliver den staet til at laese far buffer B til naeste skaerm opdatering det er derfor at FPS bliver begraent til ZHZ da gpu i denne vente periode ikke har nogle stedat at begynder det nestea billed Buffer A bliver der laest fra lige nu og Buffer B skal bruger til naeste opdatering. so ved double buffering er vi loebe toer lidt mere info triplebuffing tilbuder en 3. buffer som gpu kan tegne vider pga er derved ikek have denn vetner periode. Det er derfor der ikke kommer drops til hele inter ger divsion nar du under vsync har en potntial fps der er laver end din hz. da gpu stadigvaek kan tegne vider desvaer ved stanard tripel buffing stopper gpu nar buffersne er fulde dvs der bliver ikke redner hurtiger end hz alligevels Her kommer fast sync saa ind som giver en skjult 3. buffer til 3d software med kun double buffering den bliver vedmed at roter mellem buffer B og C saa gpu kan koer pa fuld droen. nar skarme er faerdig med at leasefar Buffer bliver den skifter over til den buffer som har det nyeste billed klart i sig Det er derfor at fast sync brigner input ag fra GPU til skaermn under hoej fps lav hz sitautioner Som almindg Vsync gsync og free sync ikke kan goere TLD: Du har misforstaet hvad/hvordan der sync'es og hvordan de tal du henviser til virker rent fysisk i den virkelig verden
--
Sven Bent - Dr. Diagnostic www.TechCenter.[...] - Home of Project Mercury

#14 Stuttering burde ikke veare et et pludselig problem hvis du koere uden sync mht til hz. uden sync har hz intet at sige paa din effektive fps.. Din pontentielle fps har fuld droen til at blive udfoert til effektive fps men stutering er direkte ppavirker af din fps hoejre fps mindre sttuer (alt andet lige) Derudover skal de siges at selvom du har tearing kan det opleves forskelligt alt efter fps/hz forhold eller retter render cycle time til hz forhold hvis f.eks du har 120fps (Helt perfect 8.5ms render cycle time paa alle frames. hvilkent man aldrig har i den virekelig verden) og 60hz skaerm. jamen saa har du noedvendig hvis 2 tearings liner paa din skaerm da du har de vile dele den afstande du baver dig i et given opdaterings intervals saa hvis du drjer kamera 10 pixels til side saa vil de to tearings line dele de 10 pixels ohave f.esk 5 hver eller 6 og 4 pixels tearing hver Du spoerg ind til noget som ret te teknisk go de fleste folk ikke forstaar forid folk tor at 60fps er det samme hastighed som 60hz og ikke forstar forskellen mellem et instant og et maaling intervald Det er for mange ukendt faktore til at give dig et svar du bliver noed til at fortaelle om du har sync eller ej slaaet til og hvilken from
--
Sven Bent - Dr. Diagnostic www.TechCenter.[...] - Home of Project Mercury

#15 Udgangspunktet er, at en frame skal være færdig og ligge uberørt i sin buffer, når skærmen displayer den Din framebuffer er altid fardig med sit billed (Frame) foer skaermen for lov at laese fra den. som skrevet overfor det det hele humlen med multibuffering. Det er sandt om du er i sync eller ej. Det er ikke en ufaerdig frambuffer der giver tearing. Det er spild af kræfter da skærmen aldrig viser den, men at CPU/GPU er hurtige nok til at rendere 2 frames ud i det tidsrum hvor skærmen viser én, ødelægger teknisk set ikke muligheden for at synkronisere front bufferen til 60Hz. Det er ikke spild af kraefter der er latancy involveret som nedgoers ved at senderr et nyt billed afsted strakt fremfor at venter paa det tidliger billed er fardig opdateret. aka input lag Du synkronisre ikke front bufferne. du synkronisere buffer swap dvs naar front buffer bliver til back buffero og backbuffer bliver til front buffer ( med det nye billed) Jeg tror I har ret i at det aldrig vil finde sted, da buffer-flippet (ved vsync) synkroniseres til skærmens vertical blank, som er 60Hz dette eksempel, Har intet med eksempel at gore det er saadan tingen virker. men godt at see du kunen alese op og saa et jeg havde ret Men der er ikke teknisk noget til hinder for at man kan smide dobbelt så mange frames ud lige ud over at vi ikke har noget sted at lave de neaste billed nar begge framebuffers i double buffiers er i brugt. Det virker altsaa ikke helt som om du har forstart hvad frame buffer virker endnu Double buffer Skaerm laeers fra Front buffer (a) - gpu render til back buffer (b) Buffer swap Skaerm laeers fra Front buffer (a) - gpu render til back buffer (b) Buffer swap Lad os atange at du vil smide 120fps ud paa til en 60hz skarmer isync med double buffierng og vi her antager en perfekt verdne for alle frames er lige hurtigt rendered refres Cycle tid er 16.6 ms. fram redner time er sa 8.3 tidslinie: 0ms skarmer laeserfra buffer A. GPU render til Buffer B 8.3ms Skaerm er 50% fardig med at laese fra buffer A. GPU er fardig med at render til Buffer GPU kan ikke render itl buffer A da skaermen laeser fra denne. GPU kan ikke rendered til buffer B da den har det naste billed og skal reserver til buffer swao 16.6 skaerm er fardig og buffer swap sker Skaerm laerr nu billed 2 fra buffer B. og GPU kan reder naste billed til Buffer a Som du kan se der gaar 16.6ms mellem hvergang gpu ren faktisk kan starte en ny frame saa sevl pm gpu har en potential fps paa 120fps via en render tids pa 8.3ms saa bliver der effektivt kun rederere en frame for hvert 16.6 ms hvilket giver en effekit og fysisk rsults af 60FPS Igen bare at matche tal sammen ude at forstaar hvad disse tal repraesenter i den fysiske verden er ikke en god ide. Du siger hvis jeg skal gennemgaa det for triple buffer setup lige saa bad i koo mode (DX eller Roterende mode (openGL/vulcan) eller i fuld rotrende mode (Fast sync) du kan evt ogsaa laese de uttalige tidliger Hol indlaeg om hz og sync hvor jeg linker til min artikel om sync og framebuffers
--
Sven Bent - Dr. Diagnostic www.TechCenter.[...] - Home of Project Mercury
--

Sidst redigeret 18-08-2020 19:11

Skal lige beklager at mine indlaeg nok har en god del flere taste fejl end saedvanligt. men jeg arbejde med AT&T omkring et totalt nedbrudg af telefoner hos en af mine klienter, men jeg skrev "med venstre hand"
--
Sven Bent - Dr. Diagnostic www.TechCenter.[...] - Home of Project Mercury

TLDR: om post #20 Dette fysisk umuligt for et grafikkort at render flere FPS end hz under vsync med double buffering. Det har inte med hvad der bliver sagt i #15 at goere.
--
Sven Bent - Dr. Diagnostic www.TechCenter.[...] - Home of Project Mercury

@MADS Kigger lige over dit original indlaeg igen. Uden at vide dine settings saa er her et totalt litdt et gaet fra min side Antagelser: du forveklser tearing med tutter og oplever i virkeligheden stutter. Antagelse: du har aldrig set tearing Hvis du koer med vsync slaaet til og din potential fps falder til under din opdaterings hastgihed HZ saa sker der en slowdonw under double buffing. det der sker er at du ikek kan opdater imens et billed blier vist paa skaermen saa slevom det nye billedl ige kommer 2 ms for sent til bussne saa skal deraltsaa vente til naeste bus aka refrsh cycles er over staaet Det betyder at du mister din hasighed ned til en hel divisor af din opdaterings hastighed saa .feks kan du kun lave 140fps eller er omkring 7.14 ms om at render billed er det ikek hurtigt nok til at rame hver skaerm opdtering som koere ved 144fps aka 6.94ms du skal saa vente til naeste opdatering hvulket kommer 6.94 ms laenger. dvs du kan kun opdater din skaerm og faa en ny framebuffer hvert 6.94 x 2 =13.8ms 13.8ms vente tide imellem hver frame giver dig en effektiv fps paa 72fps ( hviletk er en divisir ar 2) er du for langsomt til er vare klar hvert ande opdatergins cyckles komem du forst igang ver 3. dvs har du ikke 72fps falder du til 144/3 = 48 med andre ord: hvis du oplever sutter nar din fps falder til under hz kan det avre en indication at du har sync slaaet til hvilket under doublbe buffinerg for din fps til at falde i drastiske hak 144 72 48 36 etc Det er af samme aarsag at det er umulgtg af hvad ChristianHP at have hoejre FPS end hz (under double buffering) siger. Ssimepheltn fordi der ikke er en framebuffer at rendere til loesninger (angivet at mine antagelser er korrekte): slaa vsync fraa slaa tripel buffering til slaa fast sync til
--
Sven Bent - Dr. Diagnostic www.TechCenter.[...] - Home of Project Mercury

P.S. triple buffering under DirectX er rimelig skod mht til input lag da det er en kee baseret triple buffing og roterende triplebuffer
--
Sven Bent - Dr. Diagnostic www.TechCenter.[...] - Home of Project Mercury

Hej igen. Vsync har altid været slået fra i CS:GO ved mig, og jeg tror ikke, jeg har noget sync på min skærm.
--
Gæstebruger, opret dit eget login og få din egen signatur.

Sven Bent, Du har brugt en hel masse ufattelig gebrokkent skrift på at forklare meget tæt på det samme som jeg har, for så, lettere hovent, at fortælle mig jeg ikke har forstået noget som helst, så jeg tænker jeg bare stopper her. Vores diskussion hjælper ikke OP alligevel. Mvh Christian
--

Hvis du kun har oplevet det ved CSGO vil jeg sige det er en CSGO only ting. Jeg taler bare af egen erfaring her og har ikke nogen teori til at forklare noget, men synes altid spillet har opført sig mærkeligt. Jeg har f.eks. oplevet en del stutters hvis jeg bruger begge mine skærme mens jeg spiller. Går jeg fra "Udvid" til "Kun PC-Skærm" altså 1 skærms setup i windows, så har jeg ingen problemer. Derudover har jeg som dig også oplevet at mit spil generelt har meget mere stutter og slet ikke er så flydende som andre spil ved f.eks. 100-150 fps. Generelt skal min fps ligge på 200+ ellers kan jeg tydeligt mærke at det ikke kører "smooth". Ved ikke om det kan hjælpe dig, men det er i hvert fald min egen erfaring.
--

@26 Vi siger absolut ikke det samme. du kommer med en masse forkerte antagelse om hvordan det virker. jeg skal gerne gennemgaa dem igen i #3 Hej Mads,Screen tearing er et fænomen der optræder når skærmen refresher mens grafikkortet er ved at skrive næste frame til den buffer, skærmen læser fra. Helt forkert. jeg har forklaret hvorfor dette ikek er tilfaelde og hvad den virkelig aarsag er Der findes 2 løsninger. ogsaa forkert jeg fremvist 3 Ud over din om gsync/freesync som jeg ikke kigede naermere paa var dine forklaring tekniske forkerte i #5 For at være helt præcis: Screen tearing opstår når skærmens refresh divideret med grafikkortets FPS ikke er et heltal. Det er forkert Det er ligegyldigt om det er fordi grafikkortet kører hurtigere eller langsommere. Hvis du har en 60Hz skærm og kører 50 FPS (VSYNC disabled), så får du også screen tearing. Dette er forkert du har altid screentearing uden sync. Altsa intet I #5 var korrekt af nogen teknisk art I #12 Det er selvfølgelig opdateringsfrekvenserne på henholdsvis skærmen og grafikkortet, og synkronisering finder sted netop når det ene tal er et heltals multiplum af det andet, hvilket er hvad jeg skrev. Igen Helt fokert du vender om paa arsaag og resultat. Det er allerede forklaret hvilke ting du blander sammen her Det er rigtigt at double-buffering afhjælper problemet en del, men ikke 100%. igen forkert Double buffering hjaelper ikke paa tearing. tearing komemr at skifte imellem buffer og antallet af disse har ingen effekt paa tearing. Du skal stadig sørge for ikke at pille ved front bufferen på noget andet tidspunkt end under skærmens vertical blank, Du er halvt forkert paa den hvis du mener pille er buffer swap. me nhvis du menre pilel some i at skrive data er du igen forkert da vi aldrig skriver data til front bufferen og det er lige megetom din double-buffer er en software implementering (hvor kopiering finder sted) eller hardware, hvor back og front bare flippes nede på grafikkortet. Sker det mens skærmen displayer bufferen, får du tearing. igen et mix af termer. med framebbuffer koere med blockmove eller mirroing har intat at goere med om det er i software eller hardware. det har med adressing at goere. blockmove er en langsomt metode. men det har intet med software vs hardware at goere I #15 Udgangspunktet er, at en frame skal være færdig og ligge uberørt i sin buffer, når skærmen displayer den. Det er basically alt. Dette er et korrekt udsagn med total irrelevant da din front buffer alt ligger uberoet naar vi tale om framen. igen det lyder som om du snakker om ksrivning til front bufferen medfore tearing hvilket allerede er forklaret er forkert At ens setup så vælger at pumpe yderligere en frame ud i samme tidsrum, som udviskes igen uden nogensinde at blive vist, er ligegyldigt. Det er spild af kræfter da skærmen aldrig viser den, Dette er igen forkert. og forkrlet tidliger men at CPU/GPU er hurtige nok til at rendere 2 frames ud i det tidsrum hvor skærmen viser én, ødelægger teknisk set ikke muligheden for at synkronisere front bufferen til 60Hz. Jeg tror I har ret i at det aldrig vil finde sted, da buffer-flippet (ved vsync) synkroniseres til skærmens vertical blank, som er 60Hz dette eksempel, så det vil tvinge FPS'en ned i 60. Men der er ikke teknisk noget til hinder for at man kan smide dobbelt så mange frames ud, så længe man kan gøre det uden at lave en faseforskydning, som du også er inde på med kommentaren om at intervallerne skal ramme hinanden. ;) Igen forkert jeg har allerede forkalret hvorfor det er fysisk umulighed at skyder flere FPS afsted under sync ved double buffering at du kommer og siger vi har sagt det samme at altsa ikke korrekt. stoerstedele at det du har sagt er simpelthen forkert. tingen virker ikke paa den maade du tror det og der er mange andre faktore ind en lige at 2 tal passer sammen.
--
Sven Bent - Dr. Diagnostic www.TechCenter.[...] - Home of Project Mercury

#26 at du ikke gider laese min forklaringer paa, hvordan tingene virkerer fint. at du ikke kan forstaa hvad jeg skriver af and ordvalg af fejltasting er fint, du er velkommen til at spoerge in til tingene. Men at side og give folk opdigtede og forkerte information er ikke OK i min bog. Folk har brug for korrekte informationer. Hvis du ikke kan side os ms for ms gaa igennem hvordan dine front og backbuffer bliver brugt mht til forskellige sync metoder. saa har du ikke forstaaet sync paa et teknisk niveau Du kan evt laese min gamle klade til en af mine artikler omkring sync her https://drive.google.com[...] metoder mht til sync og antal buffers bliver gennemgaat foerste i virkemaade og derefer ms for ms desvaere er det en klade saa forvent en del taste fejl ( som altid)
--
Sven Bent - Dr. Diagnostic www.TechCenter.[...] - Home of Project Mercury
--

Sidst redigeret 19-08-2020 04:32

oops fejl link https://drive.google.com[...]
--
Sven Bent - Dr. Diagnostic www.TechCenter.[...] - Home of Project Mercury

#26 Det ham i en nøddeskal. Side op og ned om dit og dat, men aldrig noget brugbart for OP eller hans problemstilling. Når folk så kalder ham ud på det, så får man enten ikke noget svar eller et svar, uden nogen rigtige argumenter.
--
Grafikkort oraklet! Oh, and don't mind the vase.

#31 Jeg har svaret OP mere end dig Beklager hvis en teknisk forklaring overgaar din fokus evne. Men det forklare jo en hel del. Hvis folk ville skrive mindre forkerte "fakta" ville jeg ikke have brug for at skulle rette saa mange fejl forklaringer. Hvilket du jo har en del erfaring med mr " hojere opleosnign giver flere FPS" Tilbage til debatten Anyway for at backe op omkring mine forklaringer https://en.wikipedia.org[...] https://en.wikipedia.org[...] https://en.wikipedia.org[...]
--
Sven Bent - Dr. Diagnostic www.TechCenter.[...] - Home of Project Mercury