Tearing in kmscube on Pi4

[Daniel Gessel]

I modeled some kms based page flipping code on kmscube which I cloned from:

https://gitlab.freedesktop.org/mesa/kmscube.git

and see tearing on my Pi4 at the top of the screen.

So I went back to kmscube and modified the beginning of draw_cube_smooth (in cube-smooth.c) to draw a moving vertical red line and see tearing there too.

The beginning of draw_cube_smooth now looks like:

Code: Select all

static void draw_cube_smooth(unsigned i)
{
	ESMatrix modelview;

	/* clear the color buffer */
	glClearColor(0, 0, 0, 1.0);
	glClear(GL_COLOR_BUFFER_BIT);

	glEnable(GL_SCISSOR_TEST);
	glClearColor(1.0, 0, 0, 1.0);
	glScissor(i * 10 % (wd - 10), 0, 10, ht);
	glClear(GL_COLOR_BUFFER_BIT);
	glDisable(GL_SCISSOR_TEST);

Can anyone confirm this, or has anyone seen other issues with tearing, before I try to figure out how to post a bug report? Thanks!

PS: I see tearing on a Pi3 as well, but it disappears after a few seconds.

[6by9]

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.

[dividuum]

There is an implementation issue in FKMS at present that means we're reporting frame flip completition early. It's being investigated.

That's great to hear. This tearing issue was driving me crazy and I tried a lot of variations of my vsync code to make it work. None did so far :-O

Happy to test this once it's available.

[Daniel Gessel]

Thanks for this info. Btw, does anybody know if Kms ioctl setcrtc waits for a vblank? I was trying to use setcrtc only to have a non-vsync path but I still seem to be limited to refresh rate.

[dividuum]

There is an implementation issue in FKMS at present that means we're reporting frame flip completition early. It's being investigated.

Any hint which issue to track? Or should I open one? I guess this is an issue in the kernel, not Mesa?

[jamesh]

There is an implementation issue in FKMS at present that means we're reporting frame flip completition early. It's being investigated.

Any hint which issue to track? Or should I open one? I guess this is an issue in the kernel, not Mesa?

It could be in the VC firmware, but @6by9 would need to confirm.

[dom]

It could be in the VC firmware, but @6by9 would need to confirm.

Yes, raspberrypi/firmware is best (it is the interface between firmware and kernel, so a fix is likely to affect both).
It doesn't appear to be a mesa issue (problem not observed on vc4-kms-v3d on Pi3).

[dividuum]

It could be in the VC firmware, but @6by9 would need to confirm.

Yes, raspberrypi/firmware is best (it is the interface between firmware and kernel, so a fix is likely to affect both).
It doesn't appear to be a mesa issue (problem not observed on vc4-kms-v3d on Pi3).

Thanks dom.

[dividuum]

Any update on this issue? I didn't notice any commit comment that looked related, but I might have missed them.

[6by9]

Any update on this issue? I didn't notice any commit comment that looked related, but I might have missed them.

Most of the effort is being expended on the fully ARM-side vc4-kms-v3d driver. That's merged on 5.4 branch, although there are still a few stability issues lurking in there.

[dividuum]

vc4-kms-v3d

In contrast to the fake-kms I guess? Is that not going to get any attention going forward?

[6by9]

vc4-kms-v3d

In contrast to the fake-kms I guess? Is that not going to get any attention going forward?

In contrast to vc4-fkms-v3d, yes.
We may come back to fkms, but full KMS is probably the better bet.
I spent a long time staring at FKMS trying to work out exactly where updates were coming from, and whilst I could solve the update timing for 99% of events, there were some events that just didn't tickle DispmanX in a way that caused it to produce an update, or updates completed in a different order. It ended up being sticky tape everywhere and rather icky.

[alanbork]

I modeled some kms based page flipping code on kmscube which I cloned from:

https://gitlab.freedesktop.org/mesa/kmscube.git

and see tearing on my Pi4 at the top of the screen.

So I went back to kmscube and modified the beginning of draw_cube_smooth (in cube-smooth.c) to draw a moving vertical red line and see tearing there too.

Was the tearing in a consistent location? I think I might be seeing the same thing, and it's very repeatable but depends semi-randomly on resolution (720p gives a different vertical location of the artifact than 480p does).

[Daniel Gessel]

I modeled some kms based page flipping code on kmscube which I cloned from:

https://gitlab.freedesktop.org/mesa/kmscube.git

and see tearing on my Pi4 at the top of the screen.

So I went back to kmscube and modified the beginning of draw_cube_smooth (in cube-smooth.c) to draw a moving vertical red line and see tearing there too.

Was the tearing in a consistent location? I think I might be seeing the same thing, and it's very repeatable but depends semi-randomly on resolution (720p gives a different vertical location of the artifact than 480p does).

Tearing was pretty consistent, yes. I don’t think I tried different resolutions, just different test code.

[alanbork]

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.