The Latest GNOME Performance Issue Being Addressed Are OpenGL Pipeline Stalls

[sp82]

Vulkan won't help here, avoiding using glReadPixels() and the like will. When drawing you want to put all assets in gpu ram at startup and then only send drawing commands, not read data from gpu to system ram for some reason.

You are right, vulkan is not necessary, the best way to optimize this compositors is debugging, tracking and profiling the graphics stack and find flaws in the system, something no one did on gnome (and other compositors) in a deep way or the right way until now.
but I think Vulkan is the way to go not only because of the API is modern but because the drivers are much simpler to implement and in just few years they are all conformant to the standard, much more than opengl drivers anyway. The other advantage of Vulkan is that the driver is transparent and is not doing stupid things to optimize performance in a non-transparent way (like opengl and directx drivers do). Perfect for desktop compositors.

[AsuMagic]

sp82 Yes, then sysprof happened. Profilling on GNOME is super easy now.

There are a shit-ton of profiling tools... I've tried most of them and sysprof is not particularly special.

[Britoid]

boxie please stir somewhere else. Why would anyone care about how you feel when you can go read about what a handful of GNOME developers measure?

VanVugt is not the only one working on compositor performance. Counting the last week:

Niels de Graef

https://gitlab.gnome.org/GNOME/mutter/merge_requests/703

Carlos Garnacho

https://gitlab.gnome.org/GNOME/mutter/merge_requests/698

Georges Neto

https://gitlab.gnome.org/GNOME/mutter/merge_requests/409

Marco Trevisan

https://gitlab.gnome.org/GNOME/mutter/merge_requests/682

Jasper StPierre (extensive review)
https://gitlab.gnome.org/GNOME/mutte...e_requests/189

Don't forget https://gitlab.gnome.org/GNOME/mutte...e_requests/677

This one made a pretty massive difference for just a couple of lines of code.

[AsuMagic]

AsuMagic Only the very recent sysprof can do magic like this.
https://www.phoronix.com/scan.php?pa...-Sysprof-Lands

Right, I haven't tried it after that update.
Always found out that TUI perf and intel's vtune amplifier were the best tools for profiling.
I don't really care about GTK/Gnome specific measurements but I'll give it a go.

[cl333r]

Vulkan won't help here, avoiding using glReadPixels() and the like will. When drawing you want to put all assets in gpu ram at startup and then only send drawing commands, not read data from gpu to system ram for some reason.

Vulkan is exactly the tool to help here, it's specifically designed to address the kind of issues described in this article as it leaves a lot less room for drivers to add unexpected lags. Let me guess, you didn't learn Vulkan yet. Vulkan is OpenGL done right, even when it comes to stuff like glReadPixels, read the answer:
https://stackoverflow.com/questions/...-buffer-object

[V1tol]

I still cannot imagine when you would need to do glReadPixel every frame when moving a mouse. Make a window screenshot for Alt-Tab - thats acceptable. But when mouse moved - why??

[miskol]

It will be nice if they test mutter on slowdevices like raspberry pi or odroid-s
as it is really not ready on that devices. And for example android is working supper fine
but it is really funny that it is same with weston

weston and mutter have like really low cpu load but output isn't good, some v-sync problems and others.

[bregma]

I still cannot imagine when you would need to do glReadPixel every frame when moving a mouse. Make a window screenshot for Alt-Tab - thats acceptable. But when mouse moved - why??

Well, that is the point of the patch -- that it's not necessary.

Using glReadPixels is a naive approach to picking -- which is effectively reverse ray-tracing: given a point on the screen where the mouse is, project a ray through world space until you intersect an object. That sort of projection math (and a reverse projection is just a projection, but in reverse) is what GPUs are designed for, so your first go-to is a GL call. Turns out, though, if you do the algebra, that all you need is an inverse of the projection matrix you used to render the current frame, the scenegraph, some clipping info, and a simple loop entirely on the CPU side. Not only that, but if the rendered frame hasn't changed (like when you're sitting staring at your PowerPoint presentation trying to spiffulate some lie for management, or whatever you dear readers of Phoronix do), you don't even need to traverse the whole scenegraph and you can just cache the objects hit on the last traversal to minimize the number of comparisons to find the hit.

Anyway, using glReadPixels is the textbook way to do picking that most beginners would be familiar with. It's good enough but it's not best. It lets you get your compositor up and running within your constrained development schedule. Once you have something running, then you can make it run better. If you expect perfection out of the gate, you're never going to reach the gate.

[johnc]

Ten years after the introduction of GNOME 3, developers are starting to take performance seriously. That's good news. I got tired of waiting and moved back to Windows, but from the outside it looks like it won't be long until we finally reach the year of the Linux desktop. Well, unless they scrap everything and start a GNOME 4 from square one again.