Pekka Paalanen authored Nov 06, 2018 and Ray Strode committed Dec 19, 2018

This function gets hit even today on relatively modern Intel systems (I
have a Haswell Desktop with Mesa 18.2.4) if the pixel format is right.
Presumably it makes things slower for no longer a reason.

According to cb146dc5, this
functionality was refactored into a workaround path in 2012. The commit
message mentions the problem existing before Mesa 8.0.2. The number
refers to https://bugs.freedesktop.org/show_bug.cgi?id=46631 .

The use case where I hit this is when improving support for DisplayLink
video outputs. These are used through a "secondary GPU", and since
DisplayLink does not have a GPU, Mutter uses the CPU copy path with Cogl
read-pixels[1]. If the DisplayLink framebuffer was allocated as
DRM_FORMAT_XRGB8888 (the only format it currently handles correctly),
mesa_46631_slow_read_pixels_workaround would get hit. The render buffer is
the same format as the framebuffer, yet doing the copy XRGB -> XRGB ends
up being slower than XRGB -> XBGR which makes no sense.

This patch is not sufficient to fix the XRGB -> XRGB copy performance,
but it is required.

This patch reverts CoglGpuInfoDriverBug into what it was before
cb146dc5.

[1] This is not actually true until
    GNOME/mutter!278 is
    merged.

GNOME/mutter!313