What I'm seeing isn't tearing - I'm getting odd buffer flip behavior. I think it might be vsync related as you mentioned. sometimes frames are rendered out of order or at odd times relative to SwapBuffers(). it only happens when there's moderate out of thread load (specifically, I'm writing ~10k of data to disk, but fflush() is called before swapbuffers. worked fine on the pi zero, which is a single core, slower cpu...).
specifically I expect to see
1 2 3 4 5
but sometimes I see
2 1 3 4 5
the fflush is actually called something like 10-15 frames before this, so I guess it's just taking the kernel that long to get around to flushing it to SD card. It's almost as if swapbuffers is failing to block until vsync, and is swapping the buffer twice before refresh starts. This is all using raylib so I don't actually know the precise lower-level functions called (aka swapbuffers or equivalent) nor do I know what buffer model (2 or 3) raylib uses, though empirically it looks a lot like triple buffering on the pie zero, and definitely less on the pi4.
this seems compatible with the issue reported in this thread (I can't find a actual bug report on it anywhere though):
There is an implementation issue in FKMS at present that means we're reporting frame flip completition early. It's being investigated.
vc4-kms-v3d on a Pi3 should be clean.
retired neuroscientist. raspberry pi hacking and monitor input lag methods: https://alantechreview.blogspot.com/