Mesa 23.3 Lands Optional Support For Allowing Game Tearing On Wayland

[oiaohm]

oiaohm I don't know why you are still arguing with me, its basically a fact that higher FPS/refresh rate leads to better performance in games and people do care about that in games.

No again people just read the head lines.

https://evatech.com.au/news/studies-show-gamers-have-better-k-d-ratio-with-higher-fps/

They need the smoothest animations, lowest latency, and the least amount of distracting effects to achieve the best results.

Proper studies have all come to the same result that higher FPS/refresh rates alone don't in fact lead to best performance out of all players.

Higher refresh rates by introducing tearing causes problems. Tearing is distracting effects. How bad distracting effects harm you play is different human to human sometimes it a lot other times it not much.

mdedetrich there is reason for "G-sync/Adaptive sync/VRR" bits. The demand for VRR bits is more important than allowing tearing for best player performance.

Remember this feature being added to Mesa is not about FPS as such this is about allowing tearing at the same FPS. Gaming tearing is not universally beneficial.

Yes teared output here and there might give a player a part frame information sooner but it also part frame that can be conflicting information the player is seeing.

Remember not every human handles getting part frames of information equally well.

https://www.techspot.com/article/2546-dlss-3/ DLSS is another case where getting higher FPS/refresh rate does not end up with a better latency. So its not a basic fact that higher FPS/refresh rate is in fact better performance. How you get the higher FPS/refresh rate is very important. There are ways to get higher FPS/refresh rate that don't end up giving you better performance really. DLSS is simple to measure and show it stuffed.

Tearing is not as simple to measure and since not every human responds the same to part frames of information makes it a per human thing.

mdedetrich basically stop repeating myth the important value is totally latency including the human player reaction time.

More FPS/refresh rate is not always better simplest example prove that this is false with DLSS and systems like it because the Nvidia's LDAT tool and tools like it. The effects on tearing on human are a lot harder to show.

How you got more FPS/refresh rate is just as important as having more FPS/refresh rate.

[user556]

Until every display fully supports VRR then that stays as a nice to have only. Allowing tearing is important simply because of the time it takes to process a frame. Remove the processing time and you remove the need for tearing.

Also, it is only an adjustable user preference after all.

[rabcor]

Lol, why is this a feature in Mesa? It should be a feature in wayland...

And it shoulda been here back in 2008 too. lol. yeah. this useless crap of a protocol from 2008 is just now maybe useable sometimes, finally, thanks to mesa, not the wayland devs themselves, bravo...

The one promise of Wayland to never show imperfect frames... broken.

They could have focused their efforts into making triple buffering work really well, as well as dynamic refresh such as freesync.

But no, they instead settle for the usual mediocrity.

Mediocrity is forcing vsync on systemwide for some arbitrary promise that they didn't even fulfill themselves (not like they invented vsync, not like vsync wasn't already available in x, not like there haven't been created superior alternatives to vsync since, no thanks to these wayland devs that couldn't innovate if their lives depended on it...)

You show me perfect frames without a major hit to the framerate and high risk of lotsa input lag and i'll be a happy camper. freesync for instance, freesync would be ok to have systemwide. Not forced on mind you, being able to disable features is just good sense. Vsync though? blegh, It's an ok solution if you're working in 2d, 2d as in videos, or 2d games. If you're working in any way with 3d be that a game or just cad, there's a decent chance you will want vsync off.

[oiaohm]

Lol, why is this a feature in Mesa? It should be a feature in wayland...

Here is a good question. Please name the last GPU to have vsync less output? Its been over a 2 decades since such a desktop GPU has existed. Lot of people will get this wrong and say current GPUs.

Current GPU tearing is half done frames this is why with current GPU you can have inverted tearing. That where the top of the frame is newer than the bottom of the frame under the tear.

The vsync less GPU you would always have the bottom tear being newer content than the top also you could have in vsync less GPU multi tears on a single frame from a single buffer..

You can think of current GPU tearing as if this buffer is not complete render it anyhow and fill in the missing bits with the past frame.

https://www.phoronix.com/news/Wayland-Tearing-Control-Proto

Wayland did in 2022 extra option to allow applications to say this buffer should allow to be rendered in tearing. But when this is a GPU thing in reality there is a big question if this should have just been a DMABUF feature all along.

https://gitlab.freedesktop.org/xorg/proto/xorgproto/-/blob/master/presentproto.txt

Also it interesting when you read into PresentOptionAsyncMayTear that Mesa has just added it for bare metal X11 as well. This should allow X11 on bare metal to have vsync forced on by the X11 server tearfree option yet have application still render with tearing when the application has particularly requested it. This change is not only for Wayland.

Lot of cad users don't particularly like vsync off. There is advantage to vsync of not over rendering. Yes cad is not like a first person shooter you can have your GPU in background doing like fluid dynamics and material stress calculation and so on spending time rendering what you are looking at takes time from the GPU it can be using for other things. Sometimes input lag is not your only problem. Making choices on how you alter a design with cad how current the stress modeling and the like is equally important.

rabcor the concept that working anyway in 3d that you want vsync off is not true. There are cases where you absolutely want vsync support on.

Lot of 3d workflows Ideal place is halfway between vsync off and vsync on before freesync and the like. To not over render you need to know when the last vsync was and how long to the next vsync. The historic vsync off software implementation problem is you lose when the vsync was so leading to rendering between vsync a frame that was going to be completed so far before the next vsync that it was never going to get displayed so wasting all that GPU time on something the operation never going to be used.

Think about it all the 2d menus when using a CAD rebcor name a valid reason for any of those to render with tearing? (there is not one really other than stupid software limitations) Most 3d software is not pure 3d rabcor you forgot that. Reduced tearing reduces mental strain so allowing operating of a bit of software to maintain focus longer. 2d parts of interface that tearing provides no advantage should not be rendered with tearing.

Users and application developers have had to pick between no tearing and tearing when in reality we need a middle ground where some parts of applications are tear free and other parts have tearing where it makes logical sense.

[rabcor]

rabcor the concept that working anyway in 3d that you want vsync off is not true. There are cases where you absolutely want vsync support on.

I said a decent chance, not an absolute.

Lot of 3d workflows Ideal place is halfway between vsync off and vsync on before freesync and the like.

Thank you for re-iterating my exact point.