Massive shell lag when performing screen recording via the Asahi driver on GLES2 when not using dmabufs
Well, that's certainly a title.
Affected version
Fedora 38, GNOME Shell 44, tested on Wayland, running on a Macbook M1 Max w/ the latest version of the Asahi driver (kernel & mesa). This is not reproducible on GNOME 43.
Bug summary
If I screen record anywhere that doesn't use dmabufs (Ctrl-Alt-Shift-R, ashpd demo, the old screen cast demo script but with glimagesink changed to xvimagesink to force the use of memfd), the entire shell will lag uncontrollably to around 3fps or so.
I used sysprof to take a look at where the lag was coming from and observed that it was due to copying the pixels when recording the frames:
At first I had thought this was a mesa bug, but other apps didn't have this issue when reading the pixel data, e.g. Chromium screencasting works just fine. After some fiddling around, I discovered that this was due to the removal of the legacy OpenGL driver; the asahi driver doesn't support GL3 yet, so now it ended up using the gles2 backend. If I revert this commit, then everything returns to normal. I did try using COGL_DEBUG=disable-pbos
with the gl backend to see if it started lagging, since PBOs don't exist on gles2, but it seemed to still work just fine.
My very limited, probably incorrect understanding of this is that the M1 GPU is significantly more sensitive to the way buffers are set up; buffer objects that are read from need to be mapped as writeback, not write-combine for reads to be fast. This happens in the circumstances shown in the commit, at which point I have absolutely zero idea what's going on. (It seems to be tied to GL_MAP_READ_BIT
, but none of the mapping-related functions are called when glReadPixels
is, and also there appear to be no differences between the gl & gles2 backends here, and also how does OpenGL work I don't know.)
Of course, this could technically be a bug in the asahi driver. However, from what I can infer, this case comes up in circumstances that were always technically incorrect but still happen to work on other drivers. Something like that.
TL;DR: gles2 is doing something different somewhere that causes glReadPixels to be massively slow on Asahi, which is now triggered because the gl backend is gone.
Steps to reproduce
- Light your wallet on fire to purchase an M1 Macbook and install Asahi or some variant thereof
- Trigger a screen recording that does not use dmabufs:
- Ctrl-Alt-Shift-R
- ashpd demo
- the old screen cast demo script but with glimagesink changed to xvimagesink to force the use of memfd
What happened
My shell was Very Slow.
What did you expect to happen
My shell to not be Very Slow.