XWayland Lands Another Performance Fix
Red Hat engineer Michel Dänzer has uncovered and addressed another performance shortcoming within X.Org's XWayland code.
While our (X)Wayland Linux gaming testing has shown GNOME and KDE to be in good shape with the Wayland session versus X.Org performance, there are more optimizations still that can be made.
Dänzer today merged to the X.Org Server / XWayland codebase a new performance fix. He noticed that the XWayland code was storing the pointer to the GLAMOR context struct but GLAMOR was storing an EGLContext pointer since a commit made in 2017. The problem arises from the fact that the two values would never be equal and would result in "constant superfluous eglMakeCurrent calls" and that in turn needlessly triggering excessive glFlush calls.
That regression impacting the performance was merged in 2017 and in turn found in X.Org Server 1.20 series a year later as well as up through the recent XWayland 21.x releases.
Now with the latest code there is this small fix to avoid the excessive eglMakeCurrent calls.
While our (X)Wayland Linux gaming testing has shown GNOME and KDE to be in good shape with the Wayland session versus X.Org performance, there are more optimizations still that can be made.
Dänzer today merged to the X.Org Server / XWayland codebase a new performance fix. He noticed that the XWayland code was storing the pointer to the GLAMOR context struct but GLAMOR was storing an EGLContext pointer since a commit made in 2017. The problem arises from the fact that the two values would never be equal and would result in "constant superfluous eglMakeCurrent calls" and that in turn needlessly triggering excessive glFlush calls.
That regression impacting the performance was merged in 2017 and in turn found in X.Org Server 1.20 series a year later as well as up through the recent XWayland 21.x releases.
Now with the latest code there is this small fix to avoid the excessive eglMakeCurrent calls.
30 Comments