AMD kontrar Nvidia G-Sync med Freesync

Permalänk
Medlem
Skrivet av JBE:

Det är inte delayen den lägger på i timing-syfte som ger skillnad i input lag, den biten blir identisk om vi förutsätter identisk framerate och identisk funktion.
Det är det att freesync måste buffra en hel frame lokalt i gpu och inte skicka den förrän det är dags att visa den som ger 1 frame extra input lag i bästa fall (gsync kan spruta iväg alla frames direkt och inte få tearing, freesync måste buffra minst en hel frame innan den skickas och timas för att inte få tearing). Och det är i bästa teoretiska fall, om man bara buffrar en frame, men man buffrar 2-3.
Som nämnt ovan, så skulle man kunna tänka sig en option till freesync "[x] disregard tearing" Som ger 0 input lag och perfekt v-sync-flyt, men ger tearing. Detta tycker jag vore fantastisktt bra för 120hz+ personligen, då jag inte stör mig alls på tearing i hög refresh.

Så förstår jag det, iaf.

Man buffrar inte 2-3 frames man buffrar en frame fast man använder triple buffering istället för double buffering för att CPU och GPU ska få sträcka på benen och arbete så snabbt de kan. Läs gärna Anandtechs artikel om triple buffering.

edit: stavfel.

Permalänk
Medlem
Skrivet av Azodan:

Man buffrar inte 2-3 frames man buffrar en frame fast man använder triple buffering

Hoppas du ser att det där ser lite galet ut
Och återigen, det fungerar inte som det står i den artikeln när du använder directx. Triple buffering i directx är rakt av 3 frames buffrade i kö som alltid används vilket ger tydligt kännbart input lag.
Man kan klyva hår och säga att det som står där är rätt och directx är fel, men det är så det är hur man än vrider och vänder på det i nästan alla spel.

Om man kör den "korrekta" implementationen av triple buffering så får man ändå upp till 3 frames input lag VID FPS DROPS (då alla frames i buffern måste användas), som ju är då gsync/freesync har sin viktigaste uppgift.

Permalänk
Medlem
Skrivet av JBE:

Hoppas du ser att det där ser lite galet ut
Och återigen, det fungerar inte som det står i den artikeln när du använder directx. Triple buffering i directx är rakt av 3 frames buffrade i kö som alltid används vilket ger tydligt kännbart input lag.
Man kan klyva hår och säga att det som står där är rätt och directx är fel, men det är så det är hur man än vrider och vänder på det i nästan alla spel.

Om man kör den "korrekta" implementationen av triple buffering så får man ändå upp till 3 frames input lag VID FPS DROPS (då alla frames i buffern måste användas), som ju är då gsync/freesync har sin viktigaste uppgift.

Men när AMD pratar om att använda triple buffering så menar dom med stor sannolikhet en korrekt implementation av triple buffering så hur de gör i DirectX är väldigt ointressant.
Triple buffering syftar ju på att man har tre bufferts för buffring men det är ju ingenting som säger att alla tre används sekventiellt.
Sedan så används inte tre frames ibufferten vid FPS drops utan bara en eftersom det skulle bli tearing om den andra ej färdigrenderade bilden används. G-sync lider ju av liknade problem eftersom den måste refresha bilden om den hamnar under 30Hz då kommer G-Sync 'chippet' att visa den senaste bilden igen.

Permalänk
Medlem
Skrivet av JBE:

Hoppas du ser att det där ser lite galet ut
Och återigen, det fungerar inte som det står i den artikeln när du använder directx. Triple buffering i directx är rakt av 3 frames buffrade i kö som alltid används vilket ger tydligt kännbart input lag.
Man kan klyva hår och säga att det som står där är rätt och directx är fel, men det är så det är hur man än vrider och vänder på det i nästan alla spel.

Om man kör den "korrekta" implementationen av triple buffering så får man ändå upp till 3 frames input lag VID FPS DROPS (då alla frames i buffern måste användas), som ju är då gsync/freesync har sin viktigaste uppgift.

vad azodan sa ovan, tror nog drivrutinerna kan trumfa DirectX när det kommer till hur bilderna leveras.
Hur som helst: g-sync är gjort för att kringgå begränsningarna i dp 1.2 standarden, dom har valt att skicka timing signalerna via någon ljudlina eller vad den nu är och DÄRFÖR har dom fått bygga hela sin g-sync bräda, med minne, för att sedan plocka ihop dessa timing signaler med bildrutorna och köa dom rätt, SAMT för att kringgå den inbyggda scalern som annars omöjliggör variabel vblanc. (varför vi ens har scaler i monitorer för datorer vettefasen, känns väldigt onödigt)

dp 1.3 standarden som färdigställs i månaderna som kommer skall hantera dessa timingsignaler inbakade i bildrutorna, och AMDs kort kan i alla fall leverera dom på detta sätt redan, kanske nvidia kan också, vad vet jag.
Det som då återstår är att själva monitorn, som utöver att allmänt stödja dp 1.3 signaler också skall ha en scaler som kan hantera detta eller en möjlighet att kringgå denna, vilket är något som redan finns på några laptop monitorer, och är alltså en teknik som redan finnes.
En minnesbuffert finns alltid inbyggd i skärmar, om dom låter grafikkortet sköta bufferten eller inte vet jag inte. g-sync lagrar senaste bilden för att jämföra med nya för att göra overdrive beräkningar iaf.

Allt som behövs är ett uttryckt konsumentönskemål om detta för att detta skall komma, sedan vad skärmmakarna väljer att kalla detta återstår att se, detta är ju inte AMDs uppfinning, inte heller nvidias för den delen (men en eloge för att ha drivit upp ha begäret).
freesync kommer det antagligen heta i kontrolpanelen dock.

just nu finns det något polling lagg i g-sync som dom tänkt lösa till nästa generation, så laggfritt är det inte. inte heller så sprutar pixlarna magiskt ut ur grafikkortet direkt till skärmen, utan en bild ritas aldrig ut innan den är klar även med g-sync, annars blir det tearing (eller risk för flashbacks till hur det såg ut när man laddade ner en gif-bild på gamla modemtiden), så jag kan verkligen inte se hur nividias lösning skulle vara snabbare alls, bortsett från snabbare till marknaden då...

.. med reservation för att jag har hel och hållet fel....

edit: Enabling G-Sync does have a small but measurable performance impact on frame rate. After the GPU renders a frame with G-Sync enabled, it will start polling the display to see if it’s in a VBLANK period or not to ensure that the GPU won’t scan in the middle of a scan out. The polling takes about 1ms, which translates to a 3 - 5% performance impact compared to v-sync on. NVIDIA is working on eliminating the polling entirely, but for now that’s how it’s done.
http://www.anandtech.com/show/7582/nvidia-gsync-review

Permalänk
Medlem

Det är ju möjligt att de kan överstyra directx sämre buffering, men vi kan då fundera på varför varken nvidia eller amd någonsin har gjort det och låtit vsync+triple buffering vara så katastrofalt laggigt i onödan i alla år (50ms i 60fps) - det kanske inte är så enkelt eller alls möjligt (har ingen aning).

Permalänk

Nästan för klockrent. nVidia fanboy citerar och länkar en text från nVidia. Nästa gång kan du länka till nVidias pressrelease?

Angående resten av artikeln så "As a result, a feature like variable refresh is nearly impossible to implement on a desktop monitor as things now stand."

Sedan stoppar det inte att tillverkarna får upp detta och implementerar det i nästa version av deras skärmar iom att allt finns redan klart i standarden och kräver ingen extra proprietär hårdvara.

Nej jag tror de bör istället titta på sina egna lösningar och kanske sluta stänga av funktioner i sina drivrutiner bara för att.

Permalänk
Medlem
Skrivet av Commander:

Nästan för klockrent. nVidia fanboy citerar och länkar en text från nVidia. Nästa gång kan du länka till nVidias pressrelease?

Angående resten av artikeln så "As a result, a feature like variable refresh is nearly impossible to implement on a desktop monitor as things now stand."

Sedan stoppar det inte att tillverkarna får upp detta och implementerar det i nästa version av deras skärmar iom att allt finns redan klart i standarden och kräver ingen extra proprietär hårdvara.

Nej jag tror de bör istället titta på sina egna lösningar och kanske sluta stänga av funktioner i sina drivrutiner bara för att.

Ja, denna Petersen på nVidia är slipad i sina uttalanden, vrider och vänder på det mesta till sin fördel, svårt att se detta om man inte har läst på själv.
men bara vetskapen om vilka funktioner vesa planerar att implementera i sin nya standard och det faktum att nvidia är med i vesa i kombination med att han verkar helt oförstående till vad komma skall säger det mesta..
Nu tror jag personligen vi inte kommer se skärmar som AMD kommer kunna stödja detta på i år, jag hoppas dock även om jag inte själv sitter och väntar. Men vetskapen om att det kommer komma förr eller senare borde förhoppningsvis hjälpa folk att slippa låsa upp sig mot nvidia dom närmaste 5 åren (antar att det är ungefär så länge man behåller en skärm)

Permalänk
Medlem
Skrivet av Commander:

Nästan för klockrent. nVidia fanboy citerar och länkar en text från nVidia. Nästa gång kan du länka till nVidias pressrelease?

Angående resten av artikeln så "As a result, a feature like variable refresh is nearly impossible to implement on a desktop monitor as things now stand."

Sedan stoppar det inte att tillverkarna får upp detta och implementerar det i nästa version av deras skärmar iom att allt finns redan klart i standarden och kräver ingen extra proprietär hårdvara.

Nej jag tror de bör istället titta på sina egna lösningar och kanske sluta stänga av funktioner i sina drivrutiner bara för att.

Här var vi trevliga

Permalänk
Skrivet av Orici:

Här var vi trevliga

Tycker inte att jag var otrevlig utan bara påpekade det tydliga. Det är som när man diskuterar nya grafikkort om deras prestanda och folk postar slides från AMD eller nVidia och tar det som heliga bibeln att korten är 4x snabbare mot tidigare på y arbete och visar fina rödasvarta grön/svarta grafer. Sedan slänger på en "Made for gamers logga" som får tonåringar att bli vattniga.

I slutändan handlar det om källkritik och inte ta saker utan salt och försöka vara lite objektiv istället för att i varje tråd heja på nVidia och sitta och skriva dumma saker om andra tillverkare.

Religösa frälsta användare oavsätt av märke saknar detta och du har visat tydligt på det gång på gång enligt mig.

OT så är jag trött på att behöva köpa x brandad skärm för att sedan förlora en funktion för att jag köpte ett annat grafikkort eller för att utvecklaren kände för sig att stänga av funktionen bara för att.

Skall det vara så svårt att komma igång och faktiskt enas och använda VESA standarden där nVidia själva sade att VESA stödjer funktionen. Detta är inte första gången och säkert inte sista gången de gör detta och jag blir trött på det. Listan på vad nVidia låser ner bara för att de vill växer varje år och jag tycker detta leder mot en dålig utveckling.

Sedan så har jag nVidia kort för att AMD's drivrutiner på Linux är under all kritik och det har jag tidigare sagt också, jag håller mig inte till ett visst märke utan jag ser vad som är bäst just då. Tyvärr kommer nog AMD aldrig förbi nVidia där, iaf inte på stängda sidan. OpenSource drivrutinerna är helt för Intel och AMD.

nVidia saknar dock KMS vilket får en att gråta när man byter virtuella terminaler och det tar nästan 10 sekunder när alla öppna drivrutiner fixar det på ett naffs.

Just tearing har plågat nVidia användare väldigt mycket sedan fermi och freesync eller någon standard för att slå mot tearing och stuttering skulle vara guld. Men även också att jag slipper köpa 6 skärmar för att sedan byta till 3 andra bara för att jag valde annan färg på grafikkortet.

Permalänk
Medlem
Skrivet av Commander:

Tycker inte att jag var otrevlig utan bara påpekade det tydliga. Det är som när man diskuterar nya grafikkort om deras prestanda och folk postar slides från AMD eller nVidia och tar det som heliga bibeln att korten är 4x snabbare mot tidigare på y arbete och visar fina rödasvarta grön/svarta grafer. Sedan slänger på en "Made for gamers logga" som får tonåringar att bli vattniga.

I slutändan handlar det om källkritik och inte ta saker utan salt och försöka vara lite objektiv istället för att i varje tråd heja på nVidia och sitta och skriva dumma saker om andra tillverkare.

Religösa frälsta användare oavsätt av märke saknar detta och du har visat tydligt på det gång på gång enligt mig.

OT så är jag trött på att behöva köpa x brandad skärm för att sedan förlora en funktion för att jag köpte ett annat grafikkort eller för att utvecklaren kände för sig att stänga av funktionen bara för att.

Skall det vara så svårt att komma igång och faktiskt enas och använda VESA standarden där nVidia själva sade att VESA stödjer funktionen. Detta är inte första gången och säkert inte sista gången de gör detta och jag blir trött på det. Listan på vad nVidia låser ner bara för att de vill växer varje år och jag tycker detta leder mot en dålig utveckling.

Sedan så har jag nVidia kort för att AMD's drivrutiner på Linux är under all kritik och det har jag tidigare sagt också, jag håller mig inte till ett visst märke utan jag ser vad som är bäst just då. Tyvärr kommer nog AMD aldrig förbi nVidia där, iaf inte på stängda sidan. OpenSource drivrutinerna är helt för Intel och AMD.

nVidia saknar dock KMS vilket får en att gråta när man byter virtuella terminaler och det tar nästan 10 sekunder när alla öppna drivrutiner fixar det på ett naffs.

Just tearing har plågat nVidia användare väldigt mycket sedan fermi och freesync eller någon standard för att slå mot tearing och stuttering skulle vara guld. Men även också att jag slipper köpa 6 skärmar för att sedan byta till 3 andra bara för att jag valde annan färg på grafikkortet.

Jag postade nVIDIA's svar för att jag tycker att den bidrar till diskussionen, det finnas en anledning till extra hårdvara i skärmen som G-Sync innebär.

Permalänk
Medlem
Skrivet av JBE:

Det är inte delayen den lägger på i timing-syfte som ger skillnad i input lag, den biten blir identisk om vi förutsätter identisk framerate och identisk funktion.
Det är det att freesync måste buffra en hel frame lokalt i gpu och inte skicka den förrän det är dags att visa den som ger 1 frame extra input lag i bästa fall (gsync kan spruta iväg alla frames direkt och inte få tearing, freesync måste buffra minst en hel frame innan den skickas och timas för att inte få tearing). Och det är i bästa teoretiska fall, om man bara buffrar en frame, men man buffrar 2-3.
Som nämnt ovan, så skulle man kunna tänka sig en option till freesync "[x] disregard tearing" Som ger 0 input lag och perfekt v-sync-flyt, men ger tearing. Detta tycker jag vore fantastisktt bra för 120hz+ personligen, då jag inte stör mig alls på tearing i hög refresh.

Så förstår jag det, iaf.

Men det är detta jag menar. Även gsync måste buffra men det kommer ske på ett chip i monitorn istäkllet. Annars hade du fått tearing även på en gsync skärm. En bild måste rita klart innan nästa börjar ritas. Och för att skärmen då skall kunna rita en bild och sammtidigt ta emot en annan som den skall rita så fort denna är klar så måste den buffra minst en bild.

Permalänk
Medlem

Freesync verkar ju mest vara ett test/koncept, medans g-sync ju verkar vara en verkligt testad teknik avsedd för produktion.

Rätt så stor skillnad.

Däremot hade jag ju gärna sett att g-sync blev en fritt licensierad eller öppen standard som alla kunde använda.

Gällande Mantle så tycker jag att det är dumt med ytterligare en grafik-API-standard som utvecklare måste stödja eller förhålla sig till. Räcker ju med att det redan finns DX och OpenGL som konkurrerar med varandra på PC, och Xbox och PS som konkurrerar med varandra på konsoll.

Dessutom; skall man ha verkligen ha ett ytterligare nytt API så är det ju lite dumt om standarden drivs av ett enskilt grafikföretag som har intressen av att optimera standarden för sina egna produkter. Klarar man sig verkligen inte med de API:er som finns i dag så tycker jag att det är bättre att man satsar på ett nytt helt neutralt utvecklat grafik-API.

mvh,
martin

Permalänk
Medlem

Det här har ju varit en del av VESA standarden i flera år men har i stort sett bara använts till laptops (eDP/Embedded DisplayPort)pga strömbesparning. Senare i år blir DisplayPort 1.3 färdigställd, och där ingår även denna funktionalitet vilket betyder att även desktop-skärmar som tillverkas med 1.3-standarden kommer stödja detta i hårdvaran.

Så det enda nVidia har gjort är att hitta på en egen icke-standardiserad hårdvara för bildskärmar och försöker klämma ut skiten på marknaden innan VESA-standarden och ta massa extra betalt.

Det bästa är nog att vänta ett tag tills skärmar med DP 1.3 börjar dyka upp, då får man hårdvarustödet i bildskärmen utan att behöva betala extra. AMD's grafikkort har förresten haft stöd för den här standarden sedan Radeon HD 5000-serien.. Och antagligen har nVidia det också..

Permalänk

Fungerar G-sync enbart med Nvidia kort eller är AMD's kort även kompatibla?