[BUG] EGL readback mem spikes on Intel (4:4:4 cpu encoding on accelerated session)

[thelamer]

When running an accelerated session and we are doing readbacks (4:4:4 encoding with intel) we seem to be doing the readback regardless of smithay pacing or active encoding needed.

Need to investigate.

[thelamer]

I am not sure this is solvable on low end systems, basically how it works the GL buffers get backed up trying to remove free themselves from shm and balloon the stack. It is a side effect of reading back GL buffers from an iGPU sharing the same memory pool.

[thelamer]

Just to update, this seems to occur on iGPU setups, it is specifically filling up /dev/shm by tracing the heap.

It is actually not our data it is coming from the pixel dump operations from rust gl and smithay crates. When dumping the pixels from the GPU back to the CPU for jpeg, striped, 4:4:4, or forced CPU rendering to avoid vaapi encoding it looks like they can quickly build up and these are raw RGB at this point so they are large and resolution matters.

You have the new frame dumping fighting with the garbage collection for memory bandwidth and it spikes, on most systems this causes an OOM either by using too much shm or the systems limit on ram.

One thought is because we can actually get this information we could technically watch for it happening and roll back the frame pacing to stop dumping the pixels all together until garbage collection is complete. Some kind of hard threshold based on the current resolution being rendered.

[thelamer]

Got this nipped with linuxserver/pixelflux@4463936 will waterfall this weekend.