GNOME Mutter 46 Beta A Win For Gamers & VM Users, Other Last Minute Changes Too

[aufkrawall]

Funny thing is that direct scan-out is increasingly less important the better a compositor is optimized. Doesn't sound good when it is depicted as central for e.g. a good gaming experience.

[Myownfriend]

Funny thing is that direct scan-out is increasingly less important the better a compositor is optimized. Doesn't sound good when it is depicted as central for e.g. a good gaming experience.

This is a compositor optimization. But also no matter how optimized actual composition gets it will never be faster, less latent, or more power efficient than direct scan-out. Direct scan-out of scaled and cropped surfaces is also the only way to use the GPU's hardware scaler or the driver's scaling without changing the display resolution.

There's also an MR for direct scanout of non-fullscreen surfaces using overlay planes so that maximized clients can skip compositing, too.

You can still get a great experience gaming or otherwise without direct scan-out but it's wasteful not to use the capabilities of the GPU's display controller especially when the costs of not using it could be huge on very low-end hardware with limited memory bandwidth like the Pi 4.

[aufkrawall]

This is a compositor optimization. But also no matter how optimized actual composition gets it will never be faster, less latent, or more power efficient than direct scan-out.

That's a tautology. But I'd rather play games on a compositor with direct scan-out off and VRR on than vice versa.
And on a Pi 4, you also mostly have more severe issues with Gnome than the question direct scan-out yes/no.

[Myownfriend]

That's a tautology. But I'd rather play games on a compositor with direct scan-out off and VRR on than vice versa.
And on a Pi 4, you also mostly have more severe issues with Gnome than the question direct scan-out yes/no.

It's not like you'll have to choose between direct scanout or VRR when both are available and for former didn't prevent the other from being merged.

Also direct scanout is going to be useful 100% of the time when playing a full screen game which isn't the case with VRR.

Yea, Pi 4 is still going to have some issues running Gnome completely smoothly but having more ways for it to avoid compositing is obviously going to help.

[aufkrawall]

It's not like you'll have to choose between direct scanout or VRR when both are available and for former didn't prevent the other from being merged.

Also direct scanout is going to be useful 100% of the time when playing a full screen game which isn't the case with VRR.

I'm using VRR 100% of the time in fullscreen games and it's always beneficial. Why would one assume otherwise?
Currently, direct scan-out gets disabled in KWin when using its software gamut mapping features. Thanks to all the compositing performance and latency improvements, the performance impact is 100% unnoticeable and almost not measurable with VRR (and perhaps even without VRR, but can't be bothered to test this).
Most realistic gain of direct scan-out seems to be few minutes of added battery life with fullscreen video on APUs/IGPs, it's not a magic performance wand for gaming (unless compositing is poorly optimized)...

[hsci]

I think people are happy about GNOME3 and its usage (overview, dash, keyboard-driven, no desktop, no tray).
This revolution was necessary

Some of GNOME issues related to the fixed six month cycle. Either they push hard to include feature (somewhat broken, facing harsh critic by users) and cannot change it for six months. Or it is delayed for another six months (somewhat missing, facing also critic). A user-interface belongs together, ships in a coherent state facing the user. The Shell, Mutter, Nautilus and Settings are integrated parts. They need release coordination. Most applications not, especially Evolution, Epiphany, Loupe, Maps and Totem. Especially Epiphany should be free to update, when the web-browser needs it. There are separate maintained versions of WebKitGtk to support this well.

The kernel isn't comparable. The kernel is facing the the userspace as API provided, including various independent subsystems and drivers, providing backward-compatibility for many releases. The argument that developers need see there changes rapidly deployed for feeling progress? I understand it but It doesn't feel good to miss a release by some lines of code and restrict with your imagine viewer by unrelated projects.

Regarding this case. VRR is part of the core with Mutter. If it is close to be production ready, I would appreciate to wait some weeks. If not, next time

[Myownfriend]

I'm using VRR 100% of the time in fullscreen games and it's always beneficial. Why would one assume otherwise?

The majority of monitors are still fixed refresh rate and even VRR displays will work the same as fixed refresh rate monitors if a game can consistently run at the monitor's max refresh rate. Direct scanout will provide a benefit regardless of the refresh rate.

Currently, direct scan-out gets disabled in KWin when using its software gamut mapping features. Thanks to all the compositing performance and latency improvements, the performance impact is 100% unnoticeable and almost not measurable with VRR (and perhaps even without VRR, but can't be bothered to test this).

Sure it's still going to run fine. Compositing isn't heavy of a task on most gaming hardware even though gaming is a scenario where compositing can have the most overhead. Direct scan-out is always going to be preferable though. Just this past week someone on these forums was complaining that they had no way of using their driver's scaling options when playing games at resolutions lower than the monitor's resolution without changing the display resolution. Direct scan-out of scaled and cropped surfaces fixes that exact issue. In that person's case, they didn't want it for performance. They wanted it because a GPU's hardware scaling is often better than the bilinear scaling that a compositor would do.

Most realistic gain of direct scan-out seems to be few minutes of added battery life with fullscreen video on APUs/IGPs, it's not a magic performance wand for gaming (unless compositing is poorly optimized)...

Compositors aren't just for gaming. When doing more day-to-day tasks like writing documents, the overall GPU load is low because so little of the screen is changed per frame that it's just redrawing damaged areas. That means a larger percentage of that load is going to be from compositing. Being able to skip it could result in more noticeable gains in battery life gains in battery life.

[MrCooper]

Funny thing is that direct scan-out is increasingly less important the better a compositor is optimized. Doesn't sound good when it is depicted as central for e.g. a good gaming experience.

Direct scanout is important, especially with amdgpu, because that doesn't support true high-priority GPU contexts yet. So without direct scanout, if the client gets its GPU work for the next frame to the kernel before the compositor does its work for the previous frame, the latter has to wait for the former to finish. This is the fundamental issue behind drm/amd#2516.

[aufkrawall]

and even VRR displays will work the same as fixed refresh rate monitors if a game can consistently run at the monitor's max refresh rate. Direct scanout will provide a benefit regardless of the refresh rate.

Solution: Stay in VRR range and all the idiotic vsync woes just entirely disappear.
Yeah, I know that it won't work for all usecases. But no VRR basically is deeply flawed stone-age garbage anyway when it comes to gaming, so why would I care.

[bachchain]

They actually do want to add proper tiling, it’s just the usual “no one’s actually stepped up to do it”. Here’s a blog post about it. https://blogs.gnome.org/tbernard/202...ow-management/

I don't need some overengineered system to automagically calculate the precise exact optimal positioning for every window. I already know what it is. The position is that quarter of the screen and the size is that quarter of the screen. I just need the WM to not artificially block me from doing that