AMD kontrar Nvidia G-Sync med Freesync

Permalänk
Medlem
Citat:

Nvidia sees no need and has no plans to approach VESA about a new standard for G-Sync-style functionality—because it already exists.

och sedan säger de efter det att

Citat:

That said, Nvidia won't enable G-Sync for competing graphics chips because it has invested real time and effort in building a good solution and doesn't intend to "do the work for everyone.

Dubbelmoral?
Tycker det visar rätt tydligt nvidias inställning till saker och ting.
Ta något som redan finns, men be inte paneltillverkare stödja det så det går att använda utan tillverka en egen liten modul som ger panelerna stöd och tvinga paneltillverkare att licensiera den och lås kunder till an handfull kort. Hmmmmmmm.... Inte övertygad om att de är good-guys for bringing this

Visa signatur

Huvudriggen är en Gigabyte Aorus Xtreme | 128gb DDR5 6000 | Ryzen 7950X | 3080Ti
Utöver det är det för många datorer, boxar och servar för att lista :P

Permalänk
Medlem
Skrivet av inquam:

Då nVidia inte gått ut med information om hur G-Sync egentligen jobbar så kan det mycket väl vara så att det gör i princip samma sak som AMD's lösning, men det spekuleras i att nVidia i sina nuvarande kort inte byggt in stöd för en del av det som krävs i hårdvaran och därför kräver extern hårdvara. Om detta stämmer eller inte får framtiden utvisa då fler och fler börjar pressa nVidia för ett svar på hur G-sync fungerar och vad som skiljer mot att använda denna eller en liknande lösning.

I sin egen FAQ är de extremt vaga i hur teknologin arbetar

Sedan nämner de att det krävs ett av följande kort

Men de nämner inte varför något av dessa kort skulle krävas.Inget om någon speciell hårdvara som sitter i dem. Så det kan lika gärna vara något de bara begränsar i drivrutinerna för att få folk att uppgradera äldre kort. Något som tyvärr skett förut.

Det som börjar bli svårt för nVidia att försvara är den höga prislappen på G-sync enheter om FreeSync ens visar sig vara i närheten av ett alternativ, då detta är i princip gratis.

Det som förvånade mig när nVidia började prata om G-sync var att de inte valt att sätta sig med VESA och lägga fram en universell lösning.

Jag tror att G-sync mycket väl kan vara en "robustare" lösning i dagsläget. Men det kommer inte vara något som folk kommer betala det höga premium för som nVidia vill ta ut idag. Finns intresset kommer det komma andra lösningar som kommer standardiseras i VESA (som exempelvis FreeSync eller ett vidare arbete på detta) och nVidia kommer få svårt att förklara för användare varför de skall betala x antal tusen extra för en monitor bara för att det står G-sync på den eller varför tillverkare skall behöva licensiera G-sync och stoppa in extra hårdvara i sina skärmar.

Så G-sync generation 1 kan mycket väl vara något som säljer lite och folk får upp ögonen för detta. Men sedan kommer det vara kört för G-sync.

Skrivet av Ratatosk:

Så här har jag uppfattat det.
En kombinationa av Tripple buffering och variabel frekvens på monitorn.

Tripple buffering.
Tre buffrar, en som ligger ute, en som beräknas och en i reserv.
Om den beräknade bufferten är klar innan den kan användas, vilket ofta är fallet vid hög fps, kastas den som låg i reserv och ny beräkning påbörjas.
Om det är dags att lägga ut en ny bild, skickas en synksignal och den senaste reservbuffern läggs ut.

Variabel frekvens
Vad som avgör vad som anses vara dags att lägg ut ny bild, avgörs av monitorns min fps och max frekvens.

Om Tripple buffering.
http://www.anandtech.com/show/2794/2

Era kommentarer är rimliga, det är mycket möjligt att AMD's är lika bra som G-sync, men det ska bli kul att se vart allt tar vägen. Mitt 480 gick precis sönder och jag lutar åt 780Ti, men det är bara pga sättet man kan recorda med (insert name here då jag glömt det) med deras senaste drivrutiner, och att man simpelt kan "klocka" skärmen, G-sync är bara en bonus. Sen får man inte glömma att 780Ti har en del råstyrka.

Vad jag tycker är lite intressant i det här är att det har tagit väldigt lång tid för båda parterna att få fram ett bra alternativ som löser detta. Jag menar, jag Tearing och vsync är något vi har haft problem med länge länge.

Visa signatur

Gaming: RTX 2070 & 3770k
Studier: MacBook pro retina 13
Ljud: QH-1339 & ett par rackans smidiga AirPods
Telefon: iPhone 6s plus
Skärm: ASUS 27" ROG Swift PG279Q med sån där g-sync

Permalänk
Avstängd

öppet FTW

Visa signatur

Jag har aldrig fel

Permalänk
Entusiast
Skrivet av MuLLvaD3n:

Nu har jag inte läst igenom alla kommentarerna så det är mycket möjligt att någon redan har svarat på detta, men är det någon på plats som kan berätta hur det fungerar? Fungerar det lika bra som G-sync, för när jag kollade på G-sync i verkligheten var det enorm skillnad.

Väldigt svårt att säga eftersom det bokstavligt talat bara verkar finnas ett enda test och de är de där två laptopparna på CES. Verkar inte som om några av de större sidorna har vågat yttra sig så mycket om prestandan eftersom de inte kunnat testa något själva. De flesta verkar vara försiktigt positiva och säga att det fungerar, i alla fall i det demot som AMD visat upp. Så vi vet inte hur de presterar än. Vi vet inte ens exakt hur de olika teknikerna fungerar exakt heller. Speciellt inte G-Sync som vi i princip inte vet ett piss om.

Visa signatur

Q9450, HD4850, 8 GB DDR2 800 MHz, 3x750 GB, Antec 300, Dell 2408WFP, U2410, Qnap TS-419p+ 4x2 TB Samsung F4, Asus UL30A-QX056V, Logitech Z-680, Sennheiser HD380pro, M-Audio FastTrack Pro, Ibanez sa160qm, Ibanez TB 15R, Zoom 505II, Ibanez GSR 200, Ibanez SW 35, Cort AC-15, Squier SD-3 BBL, Yamaha PSR 270, Røde NT1-A, Nikon D200, Nikkor 18-70/3,5-4,5, 70-300VR, 50/1,8, 28/2,8, Tamron 17-50/2,8, 90/2,8, Sigma 30/1,4, SB-800, SB-25, SB-24

Permalänk
Medlem

Tripple buffering ger input lag, något som är extremt irriterande. så detta verkar absolut inte vara någon g-sync dödare.
Dessutom så funkar det ju bara på vissa monitorer, så det lär ju dröja innan monitortillverkarna får ut modeller som stödjer detta, och antagligen också har stöd för g-sync, så det ser ut som att det blir en slant för en ny monitor i vilket fall som helst i slutändan.

Permalänk
Hjälpsam
Skrivet av Lordsqueak:

Tripple buffering ger input lag, något som är extremt irriterande. så detta verkar absolut inte vara någon g-sync dödare.
Dessutom så funkar det ju bara på vissa monitorer, så det lär ju dröja innan monitortillverkarna får ut modeller som stödjer detta, och antagligen också har stöd för g-sync, så det ser ut som att det blir en slant för en ny monitor i vilket fall som helst i slutändan.

Läs på lite innan du snackar smörja.

"In other words, with triple buffering we get the same high actual performance and similar decreased input lag of a vsync disabled setup while achieving the visual quality and smoothness of leaving vsync enabled."

http://www.anandtech.com/show/2794/2

Visa signatur

AMD Ryzen 7 1700 | Saphire RX 5700 Pulse XT (Silent Mode) | 64 GB Kingston ECC | https://valid.x86.fr/z2ljhr | Stockkylaren | Bitfenix Whisper M 750W.
AMD Ryzen 9 5900X | AMD RX 5700 | 64 GB Micron ECC | https://valid.x86.fr/5krwxf
HTPC | https://valid.x86.fr/uuzli0 |

Permalänk
Medlem
Skrivet av Ratatosk:

Läs på lite innan du snackar smörja.

"In other words, with triple buffering we get the same high actual performance and similar decreased input lag of a vsync disabled setup while achieving the visual quality and smoothness of leaving vsync enabled."

http://www.anandtech.com/show/2794/2

"similar"

Permalänk
Medlem
Skrivet av Ratatosk:

Läs på lite innan du snackar smörja.

"In other words, with triple buffering we get the same high actual performance and similar decreased input lag of a vsync disabled setup while achieving the visual quality and smoothness of leaving vsync enabled."

http://www.anandtech.com/show/2794/2

Synd att det inte fins ens ett korn av sanning i det där dock.
Med triple buffering får man input lag, det är teoretiskt omöjligt att inte få det med extra buffers.
Det blir dessutom INTE mjukt som vsync med bara triple buffering utan vsync.
Enkelt att testa: slå på triple buffering med vsync off, sätt igång ett spel, blir det mjukt som med vsync på? nej.

Permalänk
Entusiast
Skrivet av JBE:

Synd att det inte fins ens ett korn av sanning i det där dock.
Med triple buffering får man input lag, det är teoretiskt omöjligt att inte få det med extra buffers.
Det blir dessutom INTE mjukt som vsync med bara triple buffering utan vsync.
Enkelt att testa: slå på triple buffering med vsync off, sätt igång ett spel, blir det mjukt som med vsync på? nej.

Jag tror inte du läste artikeln. Det verkar som om du tänker på en render ahead queue och inte tripple buffering. Tyvärr råder viss språkförbistring där vissa kallar en kö med tre rutor för tripple buffering vilket blir fel. Läs igenom hela artikeln så får du se hur det faktiskt fungerar. Det verkar lite lätt arrogant att säga att en artikel på Anandtech är helt fel. Det är en av de bättre sidorna för lite djupare analys av datorer.

Visa signatur

Q9450, HD4850, 8 GB DDR2 800 MHz, 3x750 GB, Antec 300, Dell 2408WFP, U2410, Qnap TS-419p+ 4x2 TB Samsung F4, Asus UL30A-QX056V, Logitech Z-680, Sennheiser HD380pro, M-Audio FastTrack Pro, Ibanez sa160qm, Ibanez TB 15R, Zoom 505II, Ibanez GSR 200, Ibanez SW 35, Cort AC-15, Squier SD-3 BBL, Yamaha PSR 270, Røde NT1-A, Nikon D200, Nikkor 18-70/3,5-4,5, 70-300VR, 50/1,8, 28/2,8, Tamron 17-50/2,8, 90/2,8, Sigma 30/1,4, SB-800, SB-25, SB-24

Permalänk
Medlem
Skrivet av Zotamedu:

Jag tror inte du läste artikeln. Det verkar som om du tänker på en render ahead queue och inte tripple buffering. Tyvärr råder viss språkförbistring där vissa kallar en kö med tre rutor för tripple buffering vilket blir fel. Läs igenom hela artikeln så får du se hur det faktiskt fungerar. Det verkar lite lätt arrogant att säga att en artikel på Anandtech är helt fel. Det är en av de bättre sidorna för lite djupare analys av datorer.

Jag har läst artikeln. Den innehåller fel, som även flera påpekar i kommentarsfältet.
Andra fel man direkt kan se: De skriver att det används minst double buffering även med vsync av, vilket inte är sant heller.

I övrigt mycket enkelt att testa det jag sade: slå på triple buffering i grafikkortets kontrollpanel, lämna vsync off. Ger inte överhuvudtaget samma mjukhet som vsync, som de skriver.
Med vsync på och triple buffering däremot blir det självklart mjukt, med brutalt mycket inputlag som tydligt känns.

Det är möjligt att man i teorin kan implementera triple buffering utan vsync, men vad jag vet existerar det inte i dagsläget.

Permalänk
Entusiast
Skrivet av JBE:

Jag har läst artikeln. Den innehåller fel, som även flera påpekar i kommentarsfältet.
Andra fel man direkt kan se: De skriver att det används minst double buffering även med vsync av, vilket inte är sant heller.

I övrigt mycket enkelt att testa det jag sade: slå på triple buffering i grafikkortets kontrollpanel, lämna vsync off. Ger inte överhuvudtaget samma mjukhet som vsync, som de skriver.
Med vsync på och triple buffering däremot blir det självklart mjukt, med brutalt mycket inputlag som tydligt känns.

Det är möjligt att man i teorin kan implementera triple buffering utan vsync, men vad jag vet existerar det inte i dagsläget.

UPDATE: There has been a lot of discussion in the comments of the differences between the page flipping method we are discussing in this article and implementations of a render ahead queue. In render ahead, frames cannot be dropped. This means that when the queue is full, what is displayed can have a lot more lag. Microsoft doesn't implement triple buffering in DirectX, they implement render ahead (from 0 to 8 frames with 3 being the default).

The major difference in the technique we've described here is the ability to drop frames when they are outdated. Render ahead forces older frames to be displayed. Queues can help smoothness and stuttering as a few really quick frames followed by a slow frame end up being evened out and spread over more frames. But the price you pay is in lag (the more frames in the queue, the longer it takes to empty the queue and the older the frames are that are displayed).

In order to maintain smoothness and reduce lag, it is possible to hold on to a limited number of frames in case they are needed but to drop them if they are not (if they get too old). This requires a little more intelligent management of already rendered frames and goes a bit beyond the scope of this article.

Some game developers implement a short render ahead queue and call it triple buffering (because it uses three total buffers). They certainly cannot be faulted for this, as there has been a lot of confusion on the subject and under certain circumstances this setup will perform the same as triple buffering as we have described it (but definitely not when framerate is higher than refresh rate).

Both techniques allow the graphics card to continue doing work while waiting for a vertical refresh when one frame is already completed. When using double buffering (and no render queue), while vertical sync is enabled, after one frame is completed nothing else can be rendered out which can cause stalling and degrade actual performance.

When vsync is not enabled, nothing more than double buffering is needed for performance, but a render queue can still be used to smooth framerate if it requires a few old frames to be kept around. This can keep instantaneous framerate from dipping in some cases, but will (even with double buffering and vsync disabled) add lag and input latency. Even without vsync, render ahead is required for multiGPU systems to work efficiently.

So, this article is as much for gamers as it is for developers. If you are implementing render ahead (aka a flip queue), please don't call it "triple buffering," as that should be reserved for the technique we've described here in order to cut down on the confusion. There are games out there that list triple buffering as an option when the technique used is actually a short render queue. We do realize that this can cause confusion, and we very much hope that this article and discussion help to alleviate this problem.

Visa signatur

Q9450, HD4850, 8 GB DDR2 800 MHz, 3x750 GB, Antec 300, Dell 2408WFP, U2410, Qnap TS-419p+ 4x2 TB Samsung F4, Asus UL30A-QX056V, Logitech Z-680, Sennheiser HD380pro, M-Audio FastTrack Pro, Ibanez sa160qm, Ibanez TB 15R, Zoom 505II, Ibanez GSR 200, Ibanez SW 35, Cort AC-15, Squier SD-3 BBL, Yamaha PSR 270, Røde NT1-A, Nikon D200, Nikkor 18-70/3,5-4,5, 70-300VR, 50/1,8, 28/2,8, Tamron 17-50/2,8, 90/2,8, Sigma 30/1,4, SB-800, SB-25, SB-24

Permalänk
Hjälpsam
Skrivet av JBE:

Jag har läst artikeln. Den innehåller fel, som även flera påpekar i kommentarsfältet.
Andra fel man direkt kan se: De skriver att det används minst double buffering även med vsync av, vilket inte är sant heller.

I övrigt mycket enkelt att testa det jag sade: slå på triple buffering i grafikkortets kontrollpanel, lämna vsync off. Ger inte överhuvudtaget samma mjukhet som vsync, som de skriver.
Med vsync på och triple buffering däremot blir det självklart mjukt, med brutalt mycket inputlag som tydligt känns.

Det är möjligt att man i teorin kan implementera triple buffering utan vsync, men vad jag vet existerar det inte i dagsläget.

Zotamedu har sagt det mesta, men jag undrar lite med vad menar med "slå på tripplebuffering i kontrollpanelen", den inställningen påverkar bara OpenGL inte DirectX.

edit Att buffering ger lite högre lagg finns ju i bufferingens själva natur och är inget man kan slippa helt, detta gäller även Nvidias lösning med G-sync.
Frågan är hur märkbart det är.

Visa signatur

AMD Ryzen 7 1700 | Saphire RX 5700 Pulse XT (Silent Mode) | 64 GB Kingston ECC | https://valid.x86.fr/z2ljhr | Stockkylaren | Bitfenix Whisper M 750W.
AMD Ryzen 9 5900X | AMD RX 5700 | 64 GB Micron ECC | https://valid.x86.fr/5krwxf
HTPC | https://valid.x86.fr/uuzli0 |

Permalänk
Medlem

Triple buffering är inte bara för openGL nej, det påverkar vsync i directx. Det gör dock ingenting utan vsync, vad jag vet eller kan se vid test.
Det är kanske så att det jag säger bara är sant vad det gäller directx och att triple buffering är implementerat helt annorlunda i openGL och andra standarder, men det verkar ju ganska dumt att skriva en artikel som ignorerar det grafik-API som har nästan total marknadsdominans i spelvärlden. (har nog inte spelat något som använt openGL sedan cs på tidigt 2000-tal).

Permalänk
Medlem
Skrivet av Ratatosk:

Zotamedu har sagt det mesta, men jag undrar lite med vad menar med "slå på tripplebuffering i kontrollpanelen", den inställningen påverkar bara OpenGL inte DirectX.

edit Att buffering ger lite högre lagg finns ju i bufferingens själva natur och är inget man kan slippa helt, detta gäller även Nvidias lösning med G-sync.
Frågan är hur märkbart det är.

Troligtvis sänker båda teknikerna den upplevda inputagget mot tidigare, om än marginellt och troligen inte kännbart, eftersom man kan styra skärmen till att uppdatera precis när ny bild är klar, något som styrdes av slumpen tidigare... Men är man gamer och spelar på 120hz med minst 120fps, som jag skulle säga att alla seriösa gamers gör, så finns det ju andra saker som tar långt mer tid än dessa tider mellan frames. Tex skärmens behandling av input signalen till bild.

Permalänk
Hjälpsam
Skrivet av JBE:

Triple buffering är inte bara för openGL nej, det påverkar vsync i directx. Det gör dock ingenting utan vsync, vad jag vet eller kan se vid test.
Det är kanske så att det jag säger bara är sant vad det gäller directx och att triple buffering är implementerat helt annorlunda i openGL och andra standarder, men det verkar ju ganska dumt att skriva en artikel som ignorerar det grafik-API som har nästan total marknadsdominans i spelvärlden. (har nog inte spelat något som använt openGL sedan cs på tidigt 2000-tal).

Nu när du säger det.
Det finns ett annat sätt att använda tre buffrar som kan ge mer lagg.

Metod 1 och 2; en buffer för att uppdatera skärmen (låt oss kalla den skrivbuffer), en buffer med den senaste räknade bildrutan (väntebuffer), en buffer där bildrutan håller på att räknas ut (beräkningsbuffer).
När en en syncsignal kommer skifftas innehållet i väntebuffern in i skrivbuffern.

Här kommer skillnaden.

Metod 1 som ger mindre lagg; när en bildruta räknats klart, kommer beräkningsbuffern skiftas in i väntebuffern, oberoende om denna tömts eller inte och en ny beräkning påbörjas.

Metod 2 som ger mer lagg; när en bildruta räknats klart, kommer beräkningsbuffern tömmas till väntebuffern, om denna är tom, är den inte tom kommer grafikkortet vänta tills en syncsignal kommer, då kommer väntebuffern skiftas in i skribuffern, beräkningsbuffern in i väntebuffern och en ny beräkning påbörjas.

Fördel med metod 1 är mindre lagg, metod 2 gör att grafikkortet inte behöver jobba lika hårt.

Visa signatur

AMD Ryzen 7 1700 | Saphire RX 5700 Pulse XT (Silent Mode) | 64 GB Kingston ECC | https://valid.x86.fr/z2ljhr | Stockkylaren | Bitfenix Whisper M 750W.
AMD Ryzen 9 5900X | AMD RX 5700 | 64 GB Micron ECC | https://valid.x86.fr/5krwxf
HTPC | https://valid.x86.fr/uuzli0 |

Permalänk
Medlem
Skrivet av Zotamedu:

Väldigt svårt att säga eftersom det bokstavligt talat bara verkar finnas ett enda test och de är de där två laptopparna på CES. Verkar inte som om några av de större sidorna har vågat yttra sig så mycket om prestandan eftersom de inte kunnat testa något själva. De flesta verkar vara försiktigt positiva och säga att det fungerar, i alla fall i det demot som AMD visat upp. Så vi vet inte hur de presterar än. Vi vet inte ens exakt hur de olika teknikerna fungerar exakt heller. Speciellt inte G-Sync som vi i princip inte vet ett piss om.

Nae okej, jag testade ju som sagt G-sync och det var verkligen enorm skillnad. Det var fortfarande bara ett litet demo dock.

Visa signatur

Gaming: RTX 2070 & 3770k
Studier: MacBook pro retina 13
Ljud: QH-1339 & ett par rackans smidiga AirPods
Telefon: iPhone 6s plus
Skärm: ASUS 27" ROG Swift PG279Q med sån där g-sync

Permalänk
Medlem

Jag tror att g-sync fungerar exakt så här, logiskt sett behövs ingen mer info än detta:
Skillnaden och den stora fördelen med g-sync är att buffern sitter i monitorn.
Detta medför att man i datorn inte behöver buffra lokalt alls, bara spruta ut färdiga frames så snabbt som möjligt och märka dem med en ganska exakt timestamp från renderingsmotorn. (detta är antagligen orsaken till att det bara fungerar med displayport, för att displayport kan skicka paketdata med varje frame som innehåller en timestamp).
När det är dags att visa nästa frame, kollar processorn i monitorn timestamp på nästa frame i buffern, väntar exakt så länge som behövs för att det skall bli perfekt timing i förhållande till förra bildens renderingstimestamp från motorn (dvs får man ett tillfälligt fps-drop får man kanske skippa en frame som kom försent, och tima nästa perfekt istället, på det sättet ser det fortfarande helt mjukt ut vid fps-drops som inte är extrema).
Detta kallar man variabel refreshrate, i själva verket kör man alltid den maximala refreshraten och lägger på en perfekt timad delay, i praktiken blir det variabel refreshrate.

Freesync gör ju exakt samma sak förutsatt att det fungerar (det är inget superkomplicerat, föutsätter bara att variabel vertical blanking fungerar och är precist så att man kan tima), men då den inte har någon extern buffer eller möjlighet att kommunicera med monitorn, så måste allt skötas lokalt på datorn i buffers som sedan timas på exakt samma sätt.

Resultatet blir exakt samma förutom inputlag (ingen tearing, perfekt mjukt flyt), fast med ~0ms input lag i g-sync, och ganska mycket inputlag i freesync pga buffering (mer inputlag när det är fps-drops, och den tredje buffern faktiskt används och inte bara kastas som vid högre framerates).

Permalänk
Entusiast
Skrivet av MuLLvaD3n:

Nae okej, jag testade ju som sagt G-sync och det var verkligen enorm skillnad. Det var fortfarande bara ett litet demo dock.

Ja vi vet ju att G-Sync fungerar vi vet bara inte hur det fungerar. Vi vet mer om hur Free-Sync fungerar i teorin men finns inga riktiga test i praktiken mer än de där två laptoparna. Så vi får se hur det blir.

Personligen väljer jag hellre en lite sämre teknisk lösning som är en del av VESA än en komplicerad stängd lösning som kräver speciell hårdvara i både skärm och dator.

Visa signatur

Q9450, HD4850, 8 GB DDR2 800 MHz, 3x750 GB, Antec 300, Dell 2408WFP, U2410, Qnap TS-419p+ 4x2 TB Samsung F4, Asus UL30A-QX056V, Logitech Z-680, Sennheiser HD380pro, M-Audio FastTrack Pro, Ibanez sa160qm, Ibanez TB 15R, Zoom 505II, Ibanez GSR 200, Ibanez SW 35, Cort AC-15, Squier SD-3 BBL, Yamaha PSR 270, Røde NT1-A, Nikon D200, Nikkor 18-70/3,5-4,5, 70-300VR, 50/1,8, 28/2,8, Tamron 17-50/2,8, 90/2,8, Sigma 30/1,4, SB-800, SB-25, SB-24

Permalänk
Medlem
Citat:

He first said, of course, that he was excited to see his competitor taking an interest in dynamic refresh rates and thinking that the technology could offer benefits for gamers. In his view, AMD interest was validation of Nvidia's work in this area.

However, Petersen quickly pointed out an important detail about AMD's "free sync" demo: it was conducted on laptop systems. Laptops, he explained, have a different display architecture than desktops, with a more direct interface between the GPU and the LCD panel, generally based on standards like LVDS or eDP (embedded DisplayPort). Desktop monitors use other interfaces, like HDMI and DisplayPort, and typically have a scaler chip situated in the path between the GPU and the panel. As a result, a feature like variable refresh is nearly impossible to implement on a desktop monitor as things now stand.

http://techreport.com/news/25878/nvidia-responds-to-amd-free-...

Visa signatur

"Maybe one day you will learn that your way, is not the only way"

Permalänk
Hjälpsam
Skrivet av JBE:

Jag tror att g-sync fungerar exakt så här, logiskt sett behövs ingen mer info än detta:
Skillnaden och den stora fördelen med g-sync är att buffern sitter i monitorn.
Detta medför att man i datorn inte behöver buffra lokalt alls, bara spruta ut färdiga frames så snabbt som möjligt och märka dem med en ganska exakt timestamp från renderingsmotorn. (detta är antagligen orsaken till att det bara fungerar med displayport, för att displayport kan skicka paketdata med varje frame som innehåller en timestamp).
När det är dags att visa nästa frame, kollar processorn i monitorn timestamp på nästa frame i buffern, väntar exakt så länge som behövs för att det skall bli perfekt timing i förhållande till förra bildens renderingstimestamp från motorn (dvs får man ett tillfälligt fps-drop får man kanske skippa en frame som kom försent, och tima nästa perfekt istället, på det sättet ser det fortfarande helt mjukt ut vid fps-drops som inte är extrema).
Detta kallar man variabel refreshrate, i själva verket kör man alltid den maximala refreshraten och lägger på en perfekt timad delay, i praktiken blir det variabel refreshrate.

Freesync gör ju exakt samma sak förutsatt att det fungerar (det är inget superkomplicerat, föutsätter bara att variabel vertical blanking fungerar och är precist så att man kan tima), men då den inte har någon extern buffer eller möjlighet att kommunicera med monitorn, så måste allt skötas lokalt på datorn i buffers som sedan timas på exakt samma sätt.

Dold text

Resultatet blir exakt samma förutom inputlag (ingen tearing, perfekt mjukt flyt), fast med ~0ms input lag i g-sync, och ganska mycket inputlag i freesync pga buffering (mer inputlag när det är fps-drops, och den tredje buffern faktiskt används och inte bara kastas som vid högre framerates).

Varför skulle det bli så mycket mer inputlag i Freesync? skillnaden är ju bara om buffern ligger i skärmen eller i grafikkortet.

Visa signatur

AMD Ryzen 7 1700 | Saphire RX 5700 Pulse XT (Silent Mode) | 64 GB Kingston ECC | https://valid.x86.fr/z2ljhr | Stockkylaren | Bitfenix Whisper M 750W.
AMD Ryzen 9 5900X | AMD RX 5700 | 64 GB Micron ECC | https://valid.x86.fr/5krwxf
HTPC | https://valid.x86.fr/uuzli0 |

Permalänk
Medlem
Skrivet av Ratatosk:

Varför skulle det bli så mycket mer inputlag i Freesync? skillnaden är ju bara om buffern ligger i skärmen eller i grafikkortet.

Därför att freesync använder triple buffering (enligt deras egen info), och g-sync bara buffrar frames OM de skall fördröjas för att timas korrekt.
G-sync skickar ju frames direkt med 0 buffer på datorn, sedan kan de visas direkt, om det inte visar sig att de måste fördröjas någon ms eller så för att få perfekt timing, medan freesync måste buffra allra minst en frame på datorn innan den skickas för att inte ge tearing (freesync är ju i praktiken vanlig vsync med triple buffering och delay för korrekt timing, som de har förklarat det).

De skulle säkert kunna göra en variant av freesync utan buffering med lika lite input lag, men då skulle man få tearing istället (men fortfarande lika perfekt flyt), men det de har visat säger de är med triple buffering, då är det input lag.

Sammanfattningsvis, som jag förstår det, så får båda exakt samma delay förutsatt exakt samma framerate pga timing (detta är ju en 100% nödvändig delay för att konceptet alls skall existera), men freesync har som rent pålägg det extra input lag som triple buffering ger, vilket är ganska mycket i 60hz, men inte så extremt i 120hz+
I tillägg krävs det lite mer videominne på grafikkortet för freesync, men jag antar att storleken på ett par stycken färdigrenderade frames inte är så enormt mycket.

Där är bilden nvida visade som illustrerar detta.
Tex frame 1 fördröjs ca 4ms, sedan visas den med prefekt timing vid nästan scan, ingen tearing, helt mjukt spacad etc.
Frame 2 tog längre tid att rendera, så den fördröjs lite mindre tills nästa scan, etc etc. (deras exempel är ju en dator med mycket högre potentiell fps än refreshrate, ligger man på 118 fps@120hz tex, så skulle ju varje frame nästan fylla varje scan).
Utan buffern i monitorn går inte detta utan att buffra minst en hel frame först i vram. Personligen tycker jag det borde räcka med att buffra en frame, och det är säkert möjligt. De kanske valde triple buffering bara för att det var en teknik som existerade och de snabbt ville ha ut proof-of-concept till CES. Sedan kanske vblank är svårare att tima eller inte 100% flexibelt, vem vet.

Permalänk

Annan bra artikel som beskriver ganska bra hur freesync funkar och vad som behövs
http://www.pcper.com/reviews/Graphics-Cards/AMD-Variable-Refresh-FreeSync-Could-Be-Alternative-NVIDIA-G-Sync

Permalänk
Medlem
Permalänk
Medlem

Detta är varför mitt nästa kort antagligen blir ett AMD kort.
Jag bryr mig inte ens speciellt mycket om sync problemen, jag vill bara stödja öppna standarder.

Permalänk
Avstängd
Skrivet av Majora:

Varför blir du så arg över grafikkort? Jag fattar inte... du verkar riktigt upprörd över positiva nyheter om AMD, trots att det inte påverkar dig överhuvud taget. Du har varit i den här nyhetstråden ganska länge nu och verkar riktigt bitter.
Det är grafikkortstillverkare vi pratar om, inte pappa vs pappa.

Arg och bitter ? Jävlar va du kan läsa av en människa på lite text
Nee tycker det är riktigt korkat att alla lyfter AMD till skyarna förrän dom ens visat nått konkret.
Har absolut inget emot amd om dom kunde komma upp i samma kvalite och funktionalitet som Nvidia, men tyvärr är det ju inte så nuförtiden

Visa signatur

Chassi: Coolermaster HAF XB PSU: Silverstone Strider 850W, MB: MSI Z87-G45, CPU: Intel I5-4670K @ 4,2Ghz (Corsair H100i), GPU: MSI GTX 970 Gaming RAM: Kingston HyperX 16Gb DDR3 1600Mhz, HDD: 2x Samsung F3 7200rpm 1TB, SSD: Samsung 830 series 128Gb, OS: Win 8.1, Skärmar: LG 55" FullHD & Dell 23'' UltraSharp U2312HM.

Permalänk
Medlem
Skrivet av Zotamedu:

Ja vi vet ju att G-Sync fungerar vi vet bara inte hur det fungerar. Vi vet mer om hur Free-Sync fungerar i teorin men finns inga riktiga test i praktiken mer än de där två laptoparna. Så vi får se hur det blir.

Personligen väljer jag hellre en lite sämre teknisk lösning som är en del av VESA än en komplicerad stängd lösning som kräver speciell hårdvara i både skärm och dator.

Ja det är det som i längden gynnar alla konsumenter. Fungerar det, men lite sådär, så kommer FreeSync rev 2 eller något fixa till de issues som folk märkt och vi kommer efter ett tag ha ett öppet system som fungerar lika bra som G-Sync..

Visa signatur

Huvudriggen är en Gigabyte Aorus Xtreme | 128gb DDR5 6000 | Ryzen 7950X | 3080Ti
Utöver det är det för många datorer, boxar och servar för att lista :P

Permalänk
Medlem
Skrivet av WongFeiHung:

Arg och bitter ? Jävlar va du kan läsa av en människa på lite text
Nee tycker det är riktigt korkat att alla lyfter AMD till skyarna förrän dom ens visat nått konkret.
Har absolut inget emot amd om dom kunde komma upp i samma kvalite och funktionalitet som Nvidia, men tyvärr är det ju inte så nuförtiden

Det jag ser majoriteten av folk här göra är att applådera AMD för att de völjer ÖPPNA lösningar. I>nte för att detta är 100% bevisat att knäcka G-sync. Hade nVidias G-sync varit ÖPPEN hade detta inte varit en diskussion. Men det är i de två företagens extremt skillda uppfattning i vilka tekniska framsteg användare och det tekniska ekosystemet som helhet skall få ta del av som frustrationen finns.

Som sagt, nVidia har gjort en massa bra, men mycket av det har aldrig förändrat världen som vi hoppats på då de valt att ha det proprietärt. Hårdvaruaccelererad PhysX är som sagt ett perfekt exempel. Vi HADE kunnat haft spel idag med extremt avancerat fysik som standard om detta var öppet och alla kunde stödja det. Men istället har vi en värld där ett fåtal spel görs med hårdvaruaccelererad PhysX och fungerar på ett fåtal kort. Det gör i det stora hela att de tekniska framstegen inom både hårdvara och mjukvara går mycket långsammare än vad de hade kunnat göra och vi konsumenter är de som i slutändan blir "lidande".

Visa signatur

Huvudriggen är en Gigabyte Aorus Xtreme | 128gb DDR5 6000 | Ryzen 7950X | 3080Ti
Utöver det är det för många datorer, boxar och servar för att lista :P

Permalänk
Medlem
Skrivet av JBE:

Jag tror att g-sync fungerar exakt så här, logiskt sett behövs ingen mer info än detta:
Skillnaden och den stora fördelen med g-sync är att buffern sitter i monitorn.
Detta medför att man i datorn inte behöver buffra lokalt alls, bara spruta ut färdiga frames så snabbt som möjligt och märka dem med en ganska exakt timestamp från renderingsmotorn. (detta är antagligen orsaken till att det bara fungerar med displayport, för att displayport kan skicka paketdata med varje frame som innehåller en timestamp).
När det är dags att visa nästa frame, kollar processorn i monitorn timestamp på nästa frame i buffern, väntar exakt så länge som behövs för att det skall bli perfekt timing i förhållande till förra bildens renderingstimestamp från motorn (dvs får man ett tillfälligt fps-drop får man kanske skippa en frame som kom försent, och tima nästa perfekt istället, på det sättet ser det fortfarande helt mjukt ut vid fps-drops som inte är extrema).
Detta kallar man variabel refreshrate, i själva verket kör man alltid den maximala refreshraten och lägger på en perfekt timad delay, i praktiken blir det variabel refreshrate.

Freesync gör ju exakt samma sak förutsatt att det fungerar (det är inget superkomplicerat, föutsätter bara att variabel vertical blanking fungerar och är precist så att man kan tima), men då den inte har någon extern buffer eller möjlighet att kommunicera med monitorn, så måste allt skötas lokalt på datorn i buffers som sedan timas på exakt samma sätt.

Resultatet blir exakt samma förutom inputlag (ingen tearing, perfekt mjukt flyt), fast med ~0ms input lag i g-sync, och ganska mycket inputlag i freesync pga buffering (mer inputlag när det är fps-drops, och den tredje buffern faktiskt används och inte bara kastas som vid högre framerates).

Om monitorn lägger på en delay på när du får se din bild eller om ditt grafikkort lägger på en delay förändrar inte input lag. Det talas också hela tiden om tre buffrar (som vi är vana vid) men det finns inget som säger att AMD för FreeSync inte kan lägga upp eller hantera buffertarna på något annat sätt. Även G-sync kan ses som att minst ha två buffertar. Även om en eller båda av dem ligger i skärmen. Annars hade du "sett" bilden ritas upp på skärmen. Så även om FreeSync idag "tvingas" köra på lite hack av existerande tekniker så tror jag att det är rätt lite VESA behöver pilla på för att detta skall fungera helt smärtfritt mellan kort och monitor utan något proprietär hårdvara i monitorn. Visst kommer du behöva lite minne på kortet om du inte har en minnesbuffert på skärmen, men det är några tiotal MB vi pratar om.

Vid låga FPS bör båda teknikerna kunna få lite issues.

Visa signatur

Huvudriggen är en Gigabyte Aorus Xtreme | 128gb DDR5 6000 | Ryzen 7950X | 3080Ti
Utöver det är det för många datorer, boxar och servar för att lista :P

Permalänk
Medlem
Skrivet av cfwin:

Är det nya Timberlake-arkitekturen?

Haha klockren!

Permalänk
Medlem
Skrivet av inquam:

Om monitorn lägger på en delay på när du får se din bild eller om ditt grafikkort lägger på en delay förändrar inte input lag. Det talas också hela tiden om tre buffrar (som vi är vana vid) men det finns inget som säger att AMD för FreeSync inte kan lägga upp eller hantera buffertarna på något annat sätt. Även G-sync kan ses som att minst ha två buffertar. Även om en eller båda av dem ligger i skärmen. Annars hade du "sett" bilden ritas upp på skärmen. Så även om FreeSync idag "tvingas" köra på lite hack av existerande tekniker så tror jag att det är rätt lite VESA behöver pilla på för att detta skall fungera helt smärtfritt mellan kort och monitor utan något proprietär hårdvara i monitorn. Visst kommer du behöva lite minne på kortet om du inte har en minnesbuffert på skärmen, men det är några tiotal MB vi pratar om.

Vid låga FPS bör båda teknikerna kunna få lite issues.

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.