Closed qrp73 closed 1 year ago
Some additional info. Just tried to test it with using KMS/DRM/GBM and EGL and it runs very stable with no tearing and no frame drops.
Any idea how WM/X11 can affect driver so it fails to perform vblank synchronization and can drop some frames?
Note that the display driver (vc4-kms-v3d) does not involve the firmware at all - it's a kernel side driver, so this isn't the right repo. Your comment that it works as desired with KMS/DRM/GBM and EGL suggests it's not a linux (kernel) issue either.
The Pi4 may use mutter as WM/compositor in some circumstances. I think it needs 2GB or more of RAM, and not to have enabled VNC server. Your logs suggest a 4GB part, but I can't say if you have enabled VNC.
Can you confirm if mutter is running. ps aux | grep mutter
should confirm.
I have tested your code on a pi4 running bookworm (currently in beta testing). The good news is this seems to behave as desired. No visible tearing. "60.0 fps" is solidly displayed.
Note: bookworm is very different. It uses wayfire/wlroots for WM/compositor.
Note that the display driver (vc4-kms-v3d) does not involve the firmware at all - it's a kernel side driver, so this isn't the right repo. Your comment that it works as desired with KMS/DRM/GBM and EGL suggests it's not a linux (kernel) issue either.
Where is the code which waiting for vblank flag from hardware and performs page switch? Is that code is not a part of kernel/firmware?
As I know nvidia uses spinlock for vblank event waiting in fullscreen mode, it allows to get perfect sync with vblank event, perform buffer switch and return CPU to user code as fast as possible, it helps games to look very responsive and smooth with no tearing. Spinlock waste CPU time during vblank waiting, but since app working in fullscreen mode it working in exclusive mode and can do it in order to guarantee better performance for the rendering app and other processes can wait. May be such approach can be used to avoid these issues for RPI GPU?
The Pi4 may use mutter as WM/compositor in some circumstances. I think it needs 2GB or more of RAM, and not to have enabled VNC server. Your logs suggest a 4GB part, but I can't say if you have enabled VNC.
Can you confirm if mutter is running.
ps aux | grep mutter
should confirm.
Yes, mutter is running, I know about VNC issue, and yes - with mutter it works more stable, in window mode with mutter it has no screen tearing. But in fullscreen mode it still have screen tearing even with mutter.
The bad thing is that even the most stable configs with mutter still dropping some frames even when CPU load is almost zero and render loop is very simple and lightweight.
The interesting finding is that using EGL through KMS/DRM/GBM works very stable even if I run some heavy process in parallel. It seems that possible reason why it works unstable with X11 is that vblank waiting code works with low priority and fails to switch video buffers in time.
vblank is realtime event which processing is critical and cannot be delayed, it should be processed within guaranteed time interval, so I'm not sure - why it's processing is not handled on kernel/firmware side?
vblank is realtime event which processing is critical and cannot be delayed, it should be processed within guaranteed time interval, so I'm not sure - why it's processing is not handled on kernel/firmware side?
It's handled by kernel (as I said, firmware is not involved in the display pipeline these days): https://github.com/raspberrypi/linux/blob/fad58933544bb2a7b7db92847c25c79a83171fa6/drivers/gpu/drm/vc4/vc4_crtc.c#L845
And these is nothing wrong with how vsync is handled in the kernel (evidenced by the fact that KSM/DRM/GBM works as desired, and also wayland in new bookworm image).
But I believe on bullseye without mutter the framebuffer is single buffered so tears by design. With mutter it should be tear-free, but I think that relies on composition running fast enough.
But mutter is not used going forward, so there it is not going to get any fixes.
But I believe on bullseye without mutter the framebuffer is single buffered so tears by design. With mutter it should be tear-free, but I think that relies on composition running fast enough.
if it really single buffer, it explains screen tearing issues. But why it doesn't use double buffers? Is there any plans to add support for double buffered rendering?
But the strange thing is that X11 reports visuals which supporting double buffering and it allows to use it for rendering and screen tearing happens on visual with double buffer flag enabled...
not relevant anymore
Describe the bug Screen tearing and frame drops happens in the GPU driver. Tested on LXDE, KDE, Xfce, GNOME and default raspi OS image - all have screen tearing and frame dropping issue. Some of them don't have screen tearing issue in window mode, but still have in fullscreen mode.
All have frame drops (some frames just don't appears on the display, but accounted as displayed, it just shows previous frame image despite the fact that a new frame is properly updated).
Frame dropping pattern is random and is changed from time to time even with no visible reason. It looks like some kind of race condition in the driver.
All OS configs have unstable vblank synchronization despite the fact that CPU load is almost zero and rendering scene is very simple.
Just compare how test code works on any other GPU driver (for example AMD/Nvidia/Intel/Mali-T/etc), it works very stable with no screen tearing, with no frame drops and with ideally stable vblank synchronization. This is expected behavior.
Attached test code can be used as sanity test for the firmware/driver testing.
To reproduce Steps to reproduce: 1)
Expected result: the whole window should stable flashing with different colors, no screen tearing, no frame drops, very stable vblank sync
Actual result: the window flashing is not stable, screen tearing happens at some window positions, sometimes it fails vblank synchronization (can be noticed by changed flashing pattern and fps value jumps)
2) Move window across screen Expected result: the whole window should stable flashing with different colors, no screen tearing, no frame drops, very stable vblank sync
Actual result: the window flashing is not stable, screen tearing happens at some window positions, sometimes it fails vblank synchronization (can be noticed by changed flashing pattern and fps value jumps)
3) Press space to switch between windowed and fullscreen mode Expected result: the whole window should stable flashing with different colors, no screen tearing, no frame drops, very stable vblank sync
Actual result: the window flashing is not stable, screen tearing happens at some window positions, sometimes it fails vblank synchronization (can be noticed by changed flashing pattern and fps value jumps)
Notice that raspi OS armhf and arch64 images don't have visible screen tearing in window mode, but have it in fullscreen mode.
Notice that fullscreen mode shows almost correct image first several seconds, but after that something happens in the driver and screen tearing appears on the scree, with KDE driver just stops to update display at all in fullscreen mode. With LXDE frame rate drops down to 25-30 fps after 3-4 seconds in fullscreen mode. With all WM you can notice frame drops and unstable vblank sync.
Please fix that bug.
Sanity test code test-vblank.c:
System
Model: Raspberry Pi 4 rev 1.5
I cut some network, USB and GPIO output to fit comment into 65536 limit
Logs There is no errors related to this bug in the logs
Additional context Can be reproduced with different window manager, but some of them works more stable than other. But all have frame drops and unstable vblank synchronization issue.